March 2008 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Distribution Branding and Themes
by Stanislav Brabec 06 Mar '08

06 Mar '08

The branding proposal in previous discussion did not cover the whole range of the problem. As I promised, I will continue on it. Branding of applications, which support themes It is applicable for: - Application supports a method to change its look using a system or user configuration and sets of external files (themes). - One of the themes is chosen by default. We want: - The vendor default theme should be chosen by default. - If user of system administrator changed the theme, application should not revert to the vendor branding theme on update. In theory there are three solutions possible: On my opinion, 1. is "possible", 2. is "good", 3. is "no way". Does anybody see any other possibilities? If not, I will extend previous proposal using 2. 1. If system configuration still uses default, change system configuration set the new branding as a default. Pros: + Each theme exists only once + Each theme uses its native name Cons: - Possibly fragile scriptlets must be used. - When changing branding, previous one has to be known to evaluate: "Is it still configured to used default?" 2. Create virtual theme ("default", "branding", "vendor" or so), which is linked (= equal to) another theme. Pros: + No need for scriptlets. + Works with packages, which the default theme name embed into source Cons: - Needs extra symlinks. 3. The same as 2, but the default theme is only available under name "default" or so. Pros: + Each theme exists only once Cons: - Not backward compatible. User selected "Industrial" theme, now it has name "default". - After installing of branding say "Polar Bear", there is no more possible to use Industrial (the default of OpenSUSE branding). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

[opensuse-packaging] [RFC] Proposal: Distribution Branding (RC2)
by Stanislav Brabec 06 Mar '08

06 Mar '08

Hallo. Here is a second candidate for distribution branding proposal. When there are no complains, I will start with creating example packages soon. Proposal: Distribution Branding / Branding-Enabled Packages Purpose of the Distribution Branding To provide a way to change the look of the distribution without rebuilding any of the binary packages at all, we need a way to provide package branding separately. These conventions should allow the following: - Easy replacement of all branding contents - Figuring out which branding is used in a distribution to check that everything is properly branded (e.g. rpm -qa '*-branding-opensuse*' should be empty on an openSUSE distribution) - Joe likes to create his own distribution called "Flocke" on openSUSE and likes to replace everywhere the green SUSE geeko with a white polar bear. - Novell likes to release based on the openSUSE distribution their SUSE Linux Enterprise Server. Thorsten is tasked with changing all occurrences of "openSUSE" with "SUSE Linux Enterprise Server". - Tara prefers the upstream branding of the various openSUSE projects and does not like to see openSUSE and Novell logos everywhere. She wants to change her system and replace the custom branding everything in an easy way. Description of branding-enabled packages Branding-enabled packages provide its branding in a separate package. This technique is useful for: - Providing custom branding images. - Providing custom default bookmarks. Rules for packaging of branding enabled packages - Branding image should exist in a separate file. - No custom branding images are added to the package. Package maintainer should split to two sub-packages - one with core files (foo) and one with branding provided by upstream (foo-branding-upstream). These packages are connected by version dependencies. Conventions Package names All branding packages names should consist from three parts - package core name, string "-branding-" and the branding name. A special branding name is created by default: "upstream". This is a branding provided by upstream. Spec file comments Each file there should contain comment providing sufficient information for the artist. You can expect, that upstream branding will be available to the artist. Each line of these comment should start by "#BRAND: " string followed by these information: - Spec source file name (mandatory). Spec source package file name should be unique for the whole distribution. For example, if the target file name is /usr/share/foo/splash/image.png, source package file name should be foo-splash-image.png and it should be copied to the correct target in %install phase. - use case (mandatory, if it is not part of the file name itself, e. g. "about" - decoration of about dialog, "splash" - image displayed for a short time, when application is launching, "toolbar" - image in toolbar, "initial screen" - displayed when application is started before user starts to use it). - required art, if any (mandatory, if the image should contains program name letters, branch number, required logm comment should say, what exactly has to be included). - overlays, if any (mandatory, if the image is overlayed with any text in image, comment should say its size, color and position). - dependencies, if any (mandatory, if you can customize your look using another file, you must mention it). Examples: "Width of foo-img1.png must be the same as width of foo-bg.png." "You can define overlay text color, size and and position in splash.xml." - allowed file sizes (optional, if not present, artist has to follow upstream size). - allowed file formats (optional, if not present, artist has to follow upstream file format). - For branding of launcher icon it is preferred to create custom icon theme instead of branding. Branding packages version dependencies Defining correct version dependencies >From version to version, package developers may decide to change sizes and types of images. On the other hand, it does not happen on every version update, and it is required not to force update of branding package in such case. Suppose that version n has branding incompatible with previous version n-1 and the currect version is n+1, which is compatible with branding of n. Then dependencies should look as follows: foo.spec: Version: n+1 # Verify, that the branding package is new enough: Requires: foo-branding >= n foo-branding-myvendor.spec: Provides: foo-branding = %{version} # Do not allow to use this branding with incompatible old version: Conflicts: foo < n Package maintainer is responsible for choosing of correct versions. Note that not only upstream changes, but also packaging changes may introduce branding package incompatibility. Branding supplement Each branding package should supplement branding vendor. It allows to choose correct branding package, if more branding packages are available. Branding supplement symbol constist of "branding-" string and symbolic name of the branding. Upstream branding symbolic name is "upstream". Example: Branding-enabled package: foo.spec: Version: 2.5 Requires: foo-branding >= 2.4 %package branding-upstream Supplements: branding-upstream Provides: foo-branding = 2.5 Conflicts: foo < 2.4 #BRAND: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #BRAND: will be displayed in lower 24 pixels. Image should include #BRAND: package name "FOO" and version letters "2.4". #BRAND: foo-info.png: Background of about dialog. Black names will #BRAND: appear in the light stripe in the centre. Branding package: foo-branding-myvendor.spec: Version: 2.5 Supplements: branding-myvendor Provides: foo-branding = 2.5 Conflicts: foo < 2.4 Branding virtual package or pattern provides resolvable branding-myvendor. Problems of branding bundles It is technically possible to create branding bundle packages from particular branding packages. But such bundles cause several important problems: - Branding bundle may lock users to exact version of some packages. - Possible security update which requires branding update will be hard blocked until update of the branding bundle. Possible branding related problems: Orphan branding packages Upper mentioned dependency scheme could cause orphan branding package, if user removes package itself. Possible solutions: - Adding of cyclic dependency to main package in the branding package. - Dedicated code in zypper. Partial branding and selecting package second-in-order Vendor can decide to provide only partial branding. It is not clean, which package from other available packages should be selected as second in order. Possible solution: - Repository order feature in incoming version of libzypp (note that it will not help for update repository with a set of additional brandings for more products). Partial branding and package replacement There is a possible problem when vendor has a limited set of branding packages and then wants to provide branding for a another package. In this moment, second-in-order branding is already installed. Possible solutins: - Use Obsoletes: foo-branding-second-in-order - Wait for distro update and use repository order feature in incoming version of libzypp -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

7 8

[opensuse-packaging] Yet Another Policy: No new packages in STABLE
by Stephan Kulow 06 Mar '08

06 Mar '08

Hi, Many people complain about Factory lacking dependencies on update. Most often this is due to new packages not yet being legally reviewed. So we discussed two policy chances (and will act on it after this email): - package splits / renames won't be reviewed in the future. For this clearly mark the split in the changelog. And do not branch packages that are not subpackages (this is _very_ important!). - new packages won't be checked into STABLE unless the base packagage (the name of the .src.rpm) is already reviewed (state production). Submit those packages to BETA and send a mail to suse-dist and only after your package was approved for distribution, submit it to STABLE. You can also submit it to STABLE too so you do not forget about it, but checkin will be delayed. I hope everyone understands the reasons. If not, check bug 365543. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

[opensuse-packaging] Re: [RFC] libcg: design and plans
by Dhaval Giani 05 Mar '08

05 Mar '08

On Wed, Mar 05, 2008 at 01:56:23PM +0200, Xpl++ wrote: > Hi Dhaval, > > Dhaval Giani ??????: >>> I was wonder if creating such library makes any sense at all, considering >>> the nature of cgroups, the way they work and their possible application? >>> It seems to me that any attempt to create a 'simple' API would actualy >>> result in something that will be much harder to use that just making raw >>> mkdir/open/read/write/close operations. >>> >> >> These simple APIs are nothing but raw mkdir/open/read/write/close >> operations. >> >> > Then why do you have to make the api? Everybody knows how to user these > syscalls :) > If its only this -> why use it? If it's not -> it aint simple anymore? Well, that's just a small subset of the APIs. There are a lot of other things that libcg does. >>> Another thing is suggested config for this lib would be more appropriate >>> for a daemon rather than a library. >>> In general - cgroup is a very flexible subsystem that can be used in a >>> wide variety of ways and modes and trying to create a universal simple >>> API would more likely result in something hard to manage and work with. >>> The idea of having multiple container managers (applications that use >>> libcg) creates a lots of questions and possible issues. Containers are >>> supposed provide a flexible resource management and task grouping >>> ability, which somewhat implies that there cannot be two different >>> resource managers per node without one knowing well the >>> desires/goals/methods of the other and vice versa. And should there be >>> only one manager per node - probably it will be easier for it to use >>> cgroup subsystem directly rather than using a wrapper library? >>> >> >> I disagree. Allowing multiple resource managers allows more flexibility. >> One thing the configuration subsystem aims to do is to allow permissions >> to the groups. With this happening, a resource manager does not need to >> about the existence of other groups, it can control only the resources >> allotted to it. And since the top level is controlled by the >> administrator, he is aware of the groups and their needs. (I've given an >> example of such a scenario in the document as well). >> > Imagine having a shared/joint household savings account with your wife, and > taking money from it without your wife knowing and vice versa .. then at > some point when you thought that you have some $5K to buy the new super > duper laptop you dreamt about your entire life - surprise - no enough > resources :) > This is somewhat the equivalent of multiple independent resourse managers > :) It won't end well :) > Should they be expected to be adequate in doing their job, they cannot be > independent since they manage a shared resource. > I don't quite agree with your analogy here. The point here is that each resource manager operates in its own area, and has already been assigned some resources which it cannot change. Its more like you can take $x at the most from the account and your wife $y with x+y<=total money. -- regards, Dhaval --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] Re: [RFC] libcg: design and plans
by Dhaval Giani 05 Mar '08

05 Mar '08

On Wed, Mar 05, 2008 at 02:41:41AM -0800, Paul Menage wrote: > On Wed, Mar 5, 2008 at 2:33 AM, Dhaval Giani <dhaval(a)linux.vnet.ibm.com> wrote: > > > > So there are two different points, /mem and /cpu. /mem has A and C and > > /cpu has A, B and C. A and B of /cpu correspond to A of /mem and the C's > > are the same. With this is mind, if I say a task should move to B in > > /cpu, it should also move to A in /mem? > > > > Maybe clearer to say that /mem has two cgroups, AB and C. The > abstraction provided by libcg would be of three groups, A, B and C. > Asking libcg to move a process to abstract group B would result it > moving to /mem/AB and /cpu/B > OK. Hmm, I've not really thought about it. At first thought, it should not be very difficult. Only thing I am not sure is the arbitrary grouping of the groups (ok, a bit confusing). If that information is maintained somewhere, it should be pretty straightforward. (Only thing is that I am not sure how it will be done, and where the grouping information should be stored. configuration looks like the logical place, but I am not sure) Thanks, -- regards, Dhaval --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] Re: [RFC] libcg: design and plans
by Dhaval Giani 05 Mar '08

05 Mar '08

On Tue, Mar 04, 2008 at 10:15:20PM -0800, Paul Menage wrote: > Hi Dhaval, > > On Tue, Mar 4, 2008 at 7:23 AM, Dhaval Giani <dhaval(a)linux.vnet.ibm.com> wrote: > > Hi, > > > > We have been working on a library for control groups which would provide > > simple APIs for programmers to utilize from userspace and make use of > > control groups. > > > > We are still designing the library and the APIs. I've attached the > > design (as of now) to get some feedback from the community whether we > > are heading in the correct direction and what else should be addressed. > > There are a few things that it would be nice to include in such a > library, if you're going to develop one: > > - the ability to create abstract groups of processes, and resource > groups, and have the ability to tie these together arbitrarily. E.g > you might create abstract groups A, B and C, and be able to say that A > and B share memory with each other but not with C, and all three > groups are isolated from each other for CPU. Then libcg would mount > different resource types in different cgroup hierarchies (you would > probably tell it ahead of time which combinations of sharing you would > want, in order that it could minimize the number of mounted > hierarchies). When you tell libcg to move a process into abstract > group A, it would move it into the appropriate resource group in each > hierarchy. > I am not very clear about what you are asking for here, so let me try to rephrase it, and if I have understood it correctly, we can move further ahead from there. So there are two different points, /mem and /cpu. /mem has A and C and /cpu has A, B and C. A and B of /cpu correspond to A of /mem and the C's are the same. With this is mind, if I say a task should move to B in /cpu, it should also move to A in /mem? > - an interface for gathering usage stats from cgroups. > Yes, that is a todo. We should get around to it as the functionality gets implemented in kernel. > - support for dynamically migrating processes between groups based on > process connector events (i.e. a finished version of the daemon that > you were working on last year) > libcg is at a lower level than this. The dynamic migration of processes can be based on top of libcg, and exploit it (and be more powerful than the daemon I posted last year) It would be able to utilize the configuration and other capabilities of libcg. Thanks, -- regards, Dhaval --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] Re: [RFC] libcg: design and plans
by Dhaval Giani 05 Mar '08

05 Mar '08

Hi Peter, Thanks for your comments. On Tue, Mar 04, 2008 at 07:15:51PM +0200, Xpl++ wrote: > Hi, > > I was wonder if creating such library makes any sense at all, considering > the nature of cgroups, the way they work and their possible application? > It seems to me that any attempt to create a 'simple' API would actualy > result in something that will be much harder to use that just making raw > mkdir/open/read/write/close operations. These simple APIs are nothing but raw mkdir/open/read/write/close operations. > Another thing is suggested config > for this lib would be more appropriate for a daemon rather than a library. > In general - cgroup is a very flexible subsystem that can be used in a wide > variety of ways and modes and trying to create a universal simple API would > more likely result in something hard to manage and work with. > The idea of having multiple container managers (applications that use > libcg) creates a lots of questions and possible issues. Containers are > supposed provide a flexible resource management and task grouping ability, > which somewhat implies that there cannot be two different resource managers > per node without one knowing well the desires/goals/methods of the other > and vice versa. And should there be only one manager per node - probably it > will be easier for it to use cgroup subsystem directly rather than using a > wrapper library? I disagree. Allowing multiple resource managers allows more flexibility. One thing the configuration subsystem aims to do is to allow permissions to the groups. With this happening, a resource manager does not need to about the existence of other groups, it can control only the resources allotted to it. And since the top level is controlled by the administrator, he is aware of the groups and their needs. (I've given an example of such a scenario in the document as well). Hope this helps answer your question. Thanks, -- regards, Dhaval --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] [RFC] libcg: design and plans
by Dhaval Giani 04 Mar '08

04 Mar '08

Hi, We have been working on a library for control groups which would provide simple APIs for programmers to utilize from userspace and make use of control groups. We are still designing the library and the APIs. I've attached the design (as of now) to get some feedback from the community whether we are heading in the correct direction and what else should be addressed. We have a project on sourceforge.net at https://sourceforge.net/projects/libcg and the mailing list (cc'd here) can be found at https://lists.sourceforge.net/lists/listinfo/libcg-devel Thanks, -- libcg 1. Aims/Requirements 2. Design 3. APIs 4. Configuration Scheme 1. Aims/Requirements 1.1 What are Control Groups Control Groups provide a mechanism for aggregating/partitioning sets of tasks, and all their future children, into hierarchical groups with specialized behaviour [1]. It makes use of a filesystem interface. 1.2 Aims of libcg libcg aims to provide programmers easily usable APIs to use the control group file system. It should satisfy the following requirements 1.2.1. Provide a programmable interface for cgroups This should allow applications to create cgroups using something like create_cgroup() as opposed to having to go the whole filesystem route. 1.2.2. Provide persistent configuration across reboots Control Groups have a lifetime of only one boot cycle. The configuration is lost at reboot. Userspace needs to handle this issue. This is handled by libcg 1.2.3. Provide a programmable interface for manipulating configurations This should allow libcg to handle changing application requirements. For example, while gaming, you might want to reduce the cpu power of other groups whereas othertimes you would want greater CPU power for those groups. 2. Design 2.1 Architecture 2.1.1 Global overview libcg will be consumed in the following fashion --------------------------- | applications | --------------------------- | libcg | --------------------------- | kernel | --------------------------- A more detailed example would be as follows. Consider various applications running at the same time on a system. A typical system would be running a web browser, a mail client, a media player and office software. libcg could be used to group these applications into various groups and give them various resources. A possible example would be three groups, Internet, Entertainment and Office. A daemon could attach tasks to these groups according to some rules and the adminstrator can control the resources attached to each group via the configuration manager.i Internet Office Entertainment ---------------------- -------------- ----------- | firefox mutt | | openoffice | | mplayer | ---------------------- -------------- ----------- \ | / \ | / ------------------------------------------------------ | Some daemon | ------------------------------------------------------ | libcg | ------------------------------------------------------ | kernel | ------------------------------------------------------ 2.1.2 libcg will consist of two main parts. The configuration manager and the library. The configuration manager will used to maintain the configurations, to load and unload the configurations, to set the bootup configurations and so on. This is similar to the network configuration. A configuration file is used to setup the networking at bootup. Similarly a configuration file will be used to setup the default control groups (and maybe the top level control groups) at bootup. The administrator can directly access the configuration files, and applications can access it through the library. The configuration manager is used to provide the persistence. Application Administrator | | V | library APIs | \ / \ / \ / V V libcg configuration files | | V libcg configuration manager The configuration manager has to provide isolation between various users of libcg. That is, if two different users A and B are making use of libcg, then the configuration manager has to ensure that user A does not affect user B's settings/configurations. The top level limits and permissions for A and B are to be provided by the administrator. The permissions are filesystem permissions as cgroup is filesystem based. With this architecure in mind, we expect two levels of configuration files. One would be the global configuration which the administrator would control and setup the groups, and a local configuration which the group owner will control. A simple example could be that the administrator could split the top level according to uid, and then each user could control the resources available to him and group those applications accordingly. root | ------------------------------------------------- | | A B |- browsers |- compilers |- games |- internet |- office |- dev-environment |- entertainment |- others In this example, we have an example cgroup filesystem configuration. The administrator decides the resources available to "A" and "B". Both "A" and "B" have followed grouping according to their usage. They decide the resources availble to their groups (which is dependent of the resources alloted to them by the adminstrator). libcg will be written mainly in C with lex and yacc for parsing the configuration files. 3. APIs The APIs are envisaged to be of two main types 3.1. Manipulating Control Groups 3.1.1. Create Control Group: This API is proposed to create control groups. It should take care of the following scenarios 3.1.1.1 Create non persistent control groups: These groups should exist for just duration of this run. They should not stick across different sessions. 3.1.1.2 Create persistent control groups: These groups should stick across different sessions. 3.1.2 Delete Control Group: This API is proposed to delete control groups. It would have the same scenarios as expected for Create Control Group. 3.1.2 Modify Control Group: This API proposed to modify an already existing group's control files. It too should handle the persistence issue as like Create Control Group does. More details about configuration are available in sections 2 and 4. 3.2. Manipulating Configurations 3.2.1. Generate Configuration File: If a cgroup filesystem hierarchy already exists, it should be possible to generate a configuration file which can create it. This is proposed to be provided by this API. 3.2.2. Change Configuration File: If one configuration is currently loaded in memory, it is possible for it to be replaced with the new file. This API proposes to implement that. 3.2.3. Manipulate Configuration File: This API proposes to allow the configuration file to be modified. We should also plan on taking care of statistics once its available in mainline. 4. Configuration Scheme There are multiple configuration levels. The basic wlm.conf file will provide the mount points and the controller details. This can only be manipulated by the adminstrator. No APIs will be provided to modify this file. There will be group specific configuration files as well. The exact details of the same still need to be worked out. 4.1. Sample configuration files 4.1.1. Sample wlm.conf # # controller file # group ca1 { perm { task { uid = balbir; gid = cgroup; } admin { uid = root; gid = cgroup; } } cpu { cpu.shares = 500; } } mount { cpu = /container; } This is an example of a top level group. The mount{} block is used to provide the mount point of the various controllers. For eg, the cpu controller is mounted at /container. Next we have the group ca1. This is the top level group and its permissions are given by the uid and gid fields for tasks and admin. The next is the individual controller block. For the mount point of cpu, the cpu.shares value is provided. Thus the above file can be represented as the following script mkdir /container mount -t cgroup -o cpu none /container mkdir /container/ca1 /bin/echo 500 > /container/ca1/cpu.shares chown -R root /container/ca1 chgrp -R cgroup /container/ca1 chown balbir /container/ca1/tasks chgrp cgroup /container/ca1/tasks 5. References 1. Documentation/cgroups.txt in kernel sources. -- regards, Dhaval --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] dkim-milter for postfix?
by Guillermo Ballester Valor 03 Mar '08

03 Mar '08

Hello, Last week I made the same question in buildservice list but I'm afraid it was the wrong list because I have no received any reply. Before try to reinvent the wheel, is there any project to build DKIM-milter rpm package for openSUSE which can be used by postfix?. I'm afraid I will need soon to implement DKIM in my postfix sever, and a rpm providing this would make my life easy. I know it is not a trivial package. It includes insserv, init scripts and templates. So is why I'm asking. Till the moment I've been able to build a single rpm with the aid of some sendmail chunks. It still do not have the needed templates for yast, the rcinit scripts and some other post/pre install tasks. But is a start. Ah, I need sendmail-devel to build. Thanks, Guillermo -- Guillermo Ballester Valor gbv(a)oxixares.com http://www.oxixares.com/~gbv Ogijares, Granada - SPAIN --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0