Hi,
I've checked the current status of our testing Git repository, you can
see the changes here:
http://bit.ly/zsVW6I
Summary:
* Several repos have got additional branch
* yast-dbus-client has been fixed (branches, tags, commits)
* yast-dbus-server has been fixed (branches, tags, commits)
* yast-extra-packages - broken (not used anymore?)
* yast-libyui has been fixed (branches, tags, commits)
* yast-modules - broken (not used anymore?)
* yast-ncurses-pkg - broken
* yast-network - broken
* yast-nfs-client - broken
* yast-nfs-server - broken
* yast-nis-client - broken
* yast-nis-server - broken
* ... and all following modules (sorted alphabetically)
Thanks in advance for fixing the import filters
Bye
Lukas
--
Lukas Ocilka, Appliances Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I've created an overview drawing of two different solutions for Gloves
permissions/roles: low vs high level of roles. See http://bit.ly/Hd20ef
Frankly, it seems that neither of them can fully support roles hierarchy
as it is presented here: http://bit.ly/GQ8pvZ (or it needs quite a
complicated approach how to do that)
Check out the links, please, and comment.
Bye
Lukas
--
Lukas Ocilka, Appliances Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
This is just a note for you in case you came across a strange UTF-8 string problem in
YCP (maybe you already know that but for me it was quite a surprise):
YCP string operator [] takes _byte_ index in the string, while size(string) returns
_number_of_characters_. The problem is when you combine both functions, the result
will be probably buggy, see https://bugzilla.novell.com/show_bug.cgi?id=728588
Example from the bug:
size("áa") => 2,
but
"áa"[1] is not "a" as expected but the second _byte_ of the string which is one
half of the "á" UTF-8 character, if you remove it you'll get garbage in the string...
Keep this in your mind when iterating over YCP strings...
(I'm not sure whether fixing YCPString::[] would be a good idea, it might break
something else. Martin?)
--
Ladislav Slezák
Appliance department / YaST Developer
Lihovarská 1060/12
190 00 Prague 9 / Czech Republic
tel: +420 284 028 960
lslezak(a)suse.com
SUSE
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi hackers,
we've got new texts from YaST proofreading.
I've already done most of the changes in svn. Ommited modules were either
those C++ based, or some ones where I've seen changes that we may not want to
accept (like using the text 'boot loader' instead of 'bootloader').
The modules that were not touched are:
bootloader
control-center
gtk
ncurses-pkg
qt-pkg
storage
apparmour
Please, maintainers of these modules, use the pot files from
http://w3.suse.de/~jsuchome/proofed-2012-03-27/
and patch your code accordingly.
All other hackers: although your modules were already adapted in svn, most
packages were not submitted to autobuild. Please check your modules if they
need it.
Jiri
--
Jiri Suchomel
SUSE LINUX, s.r.o. e-mail: jsuchome(a)suse.cz
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Praha 9, Czech Republic http://www.suse.cz
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
about a week ago I removed usaging libxcrypt from yast2-core. I
also removed the Buildrequires in all YaST packages but did not
make new packages due to time limitations.
Now libxcrypt was dropped in Factory. Please check whether that
makes your packages fail and if so create new ones for the
buildservice.
ciao Arvin
--
Arvin Schnell, <aschnell(a)suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
i just installed openSUSE 12.1 (x86_64). I tried to use Snapper but
using the Yast2 plugin failed as well as "sudo snapper create".
var/log/snapper.log told me: libsnapper(3529)
Snapshot.cc(nextNumber):362 - mkdir failed errno:2 (No such file or
directory)
Using strace i found that snapper needs the directory "/.snapshots".
After creating this directory, everything seems to be fine, i can now
create snapshots, and Yast automatically creates them.
Perhaps snapper could auto-magically create the directory if needed?
Greetings,
--
Marcel Treis
E-Mail: marceltreis(a)gmail.com
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
below you find minutes of the meeting from this monday.
Vlado
yast++
====
https://github.com/yast/yast--
Date:
-----
13-02-2012
Present:
-------
Jiri Srain, Lukas Ocilka, Martin Vidner, Josef Reidinger, Jiri Suchomel,
Vladimir Moravec
Minutes
---------
Vladimir Moravec
ToC:
=======
1. Packaging
2. File structure
3. Name
4. Portability
5. Play & test out of the Git
6. GSoC
7. Logging
8. What's next
1. Packaging
============
Main idea
----------
+ how to distribute the code
Proposals
----------
+ gem directory structure if gem
+ check of local system dependencies
+ native extensions
+ stay with current rpm building and lets make it available for
other distros via buildservice
2. File structure
=================
+ use of gem directory structure conventions
3. Name of the lib
==================
Main idea
---------
+ to use or not to use 'yast' as a part of the name
Pros
----
+ established name and community, descendant of Yast
+ well known and easy to distinguish from others
Cons
----
+ not suitable if we target multiple distros
+ hard to find on google
+ hard to distinguish the name from yast
+ has association with 'suse only'
+ possible problem in the mind, with trademarked work 'yast'
+ makes impression that it is successor of YaST, but it is actually
only extraction of part of YaST ( data processing )
Questions
---------
+ What are the criteria for the name?
Suggestions for the name
------------------------
+ ylib
+ anything with 'y' letter
+ liby
+ libyast
Results
-------
+ use yast++ name as before in the meantime
+ change is however expected in the course of further development
4. Portability
==============
Main idea
---------
+ make the lib available & popular for non-suse developers
What are the means to achieve this
----------------------------------
+ distro specific config / package script calls
+ other distros to be considered: Fedora, Debian, Ubuntu
Random ideas
------------
+ what changes are needed to include other distros as target systems
+ focus on other distros not from the beginning, only later after
some point
in development has been reached
+ focus from the early stage on development; past experience shows
this as reasonable
+ talk/blog about the lib development in the public to make it
aware of the project existence
+ show simple examples for using on other distros
+ currently no check for running distro
+ autodetection as the best way
+ use of plugins would be fine
+ distro autodetection, e.g. `cat /proc/version`
Discussion
--------
+ too wide scope for beginning of such project (too many
specifications,
different needs for various distros)
+ too much work for small team -> rather focus on making happy well
known users
(studio,webyast), then use resources for others
+ imaginary users of debian/fedora as a too blury concept for the
expected change
+ we need a proof of concept that it might run on different distros
anyway
Questions
---------
+ should the portability the a feature of the lib?
+ is the multi-distro focus meaningful?
+ would it be possible running it on Fedora at all?
+ What is needed to make the development focused on more distros?
+ where to implement the distro-specific configuration
+ how to avoid forking the lib from others and keep devs in one
place =>
avoid splitting the community
Suggestions
-----------
+ ylib as ideal level for customizing configuration of the lib for this
5. Play & test out of Github
============================
Main idea
----------
+ make the lib developer friendly from the first touch
How to achieve this
--------------------
+ directory with example files
+ using chroot for not breaking the running system (root needed)
+ scripts for chrooting available
+ alternatives for chroot:
+ good tutorial for developers
+ make appliances available
Random ideas
------------
+ devel-pattern for rpm packaging
+ appliances of other distros to play with the code
+ `git clone` into the pre-build VM
+ project on OBS / install from here
+ ensure modifying the local system (remounting)
+ using testing data (from testsuite) for development
Questions
---------
+ how skilled is the developer who is going to use the lib?
+ how make the repo available for playing for other distros' developers
Proposals
---------
+ look on other projects how they solve the system configuration change
6. GSoC
=======
Main ideas
---------
+ portability feature
+ C binding for Python
+ support of Openstack => not needed currently
+ get in touch with Michal Hrusecky (GSoC/openSUSE wiki)
7. Logging
==========
Main ideas
----------
+ full logging in/out
+ filter passwords => results in slower performance
+ dry run
- diffs in chroot
- scripts
+ conventions for parameters
+ use of the test-suite to avoid wrong using of scripts
+ create/support official API
+ undef methods to block improper use of the lib
8. What's next?
===============
+ finish one or several modules and show the use case:
+ port it to to other distros
+ use it in the webyast
Vladimir Moravec
Appliances Department
SUSE LINUX s.r.o., Praha
Generic Reminders
-----------------
* Keep it simple
* Some parts might be projects for Google Summer of Code
ACLs
----
* Bind to path
* Roles defined as in WebYast
* Check how the others solve this (e.g., KDE)
* AI: jsuchome & jreidinger
New Project Name
----------------
* Ask community
* Code name (maybe something known, easy to remember)
* Package name (might differ to code name, but needn’t)
* AI: everyone
DBUS Optional
-------------
* Depends on ACLs - how we define them
* Anyway, root is always without DBUS already
* Modular - created as plug-in
* To lower the complexity
* AI: jreidinger
YaST-Related Data
-----------------
* Stored in /usr/share/YaST2/data/
* Separate data to a different package? YaST++ must not depend on
Classical YaST
* Discussion WIP
--
Lukas Ocilka, Appliances Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hello everybody!
I'm new to this list and hope that this is the right place for my question.
After an update of one of my machines from OS 11.1 to OS 12.1, I noticed
that Yast's software-installer module does *_not_* run the ldconfig +
suseconfig step after download and installing packages.
Can anybody give me a hint why this could be and how I could track down
this problem?
Norbert
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org