March 2008 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] deprecated %run_ldconfig
by Stephan Binner 11 Mar '08

11 Mar '08

Hello, obviously some autobuild team member is currently in a mood to reject the checkin of packages which contain %run_ldconfig calls. Can we please make this a build failure instead of a warning before this policy is enforced? Bye, Steve --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 9

[opensuse-packaging] Reminder: openSUSE 11.0 Alpha3 deadline this week
by Stephan Kulow 10 Mar '08

10 Mar '08

Hi, To avoid conflicts with RC1 of SLE SP2, we will have the Alpha3 builds earlier (publish date 18th). This means to everyone developing and packaging: your package has to be ready not later than friday, 14th. 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

1 0

[opensuse-packaging] Call for test: open-vm-tools in OBS (and on the lookout for a co-maintainer)
by Dominique Leuenberger 08 Mar '08

08 Mar '08

Hello! Recently, somebody (Sunny) requested some RPMs offering the open-vm-tools in our nice distribution [0]. I opted to create some packages and have a look into this. So here I am, just a few days later with a working (as for me, my house did not burn down) example of those packages. They can be found at http://download.opensuse.org/repositories/home:/dimstar and are currently built for: openSUSE 10.3 stock openSUSE 10.3 updated openSUSE Factory (for factory, i586 fails to compile because of inconsistency within BS... for the moment, the kernel-source matching the kernel-syms can not be found but that will solve itself I guess.. it's just busy). There are two things to be installed in your VM: vmware-kmp-<kernelflavour> and open-vm-tools The KMP contains 5 kernel modules: vmblock vmhgfs mvmemctl vmsync vmxnet open-vm-tools installs the service vmware-guest (get's automatically activated) and the toolbox. In my tests, the mouse was after installation freely going in and out the VM (normally one of the easiest indices that the VM tools work), I could mount a shared host (mount.vmhgfs .host:/test /mnt) and access it and the clipboard was shared between host and guest... so now I have to ask you fellows to help me improve it, to make it undergo a lot of testing so we can convince coolo that he wants to include this package in the upcoming alphas and betas and finals of openSUSE (ups... we still don't have the procedures in place for community maintained packages). so for now that's it from my side... any sort of comment is highly appreciated. A short discussion with coolo revealed that, if there is an internal co-maintainer willing to work with me on this, we could possibly push it inside the Distribution... the time would be great, we did not reach feature freeze yet. Anybody willing to go down this road together with me? Have a good time, Dominique [0] http://lists.opensuse.org/opensuse-factory/2008-03/msg00068.html --------------------------------------------------------------------- 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] Use of icedtea in 11?
by Michal Vyskocil 08 Mar '08

08 Mar '08

Hi, I'm currently working on update of some java packages from OBS project Java:jpackage-1.7 to stable. So I'm also trying to build some of these packages with icedtea. Some of them should be builded (like adaptx) with small patches, some of them currently not (like hsqldb). But the switch to icedtea is not an automated process anymore, so if the autobuild team switches the compiler, majority of java packages will not be builded and needs to do some patches or revert back to the non free compiler. I can update a package and try to build it by icedtea, so I'm be able to switch the BuildRequire to java-1_7_0-icedtea-devel, if it works. The problem is, that the icedtea is only for i386 and a x86_64 available. On ppc or s390 we are using an IBM's compiler only. But a majority of a java packages is noarch, because a Java bytecode is architecture indepentent. I'm not sure, if I should use something like %ifarch %ix86 x86_64 BuildRequires: java-1_7_0-icedtea-devel %else BuildRequires: java-devel %endif in a spec file for noarch packages. May I try to build the most of java packages using icedtea? And if yes, how to do that? Use of the %ifarch in spec? Regards Michal Vyskocil --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 5

[opensuse-packaging] Installation: lightweight VNC server
by Lukas Ocilka 07 Mar '08

07 Mar '08

[ This mail has been originally sent to opensuse-FACTORY] Hi, I just went through the new installation images searching for any huge binaries or libraries (or any other big files). I've found that we use Xvnc server (for remote installation). Only the binary takes 3.8 MB (of course, installation image is compressed). I'm asking here because FACTORY users have often broad knowledge of several alternatives [package maintainers too ;), of course]. Don't you know any 'better' and smaller (binary size, memory consumptions, less libraries) than the current Xvnc? Ideally we have it in build service... Of course, it has to cover the same range of features we currently use. Some hints: * FreeNX http://freenx.berlios.de/ * TightVNC http://myprogs.net/program/44ec3a0569499cc480f1fafabb8aebbb/TightVNC * any other? http://nixbit.com/search/vnc-server/ Any ideas, opinions, experience? Thanks and Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- Ano, ano. Moudry rozkaz. Sam jsem nemel v tech gratulacich jasno.

5 6

[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