March 2008 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Some notes from your friendly autobuild team
by Marcus Rueckert 14 Apr '08

14 Apr '08

hi, 1. good ways of doing library policy compatible packages Since quite some time we have some policy for packaging shared libraries. [1] We all had lots of fun and work with it already. There is some way to save some work for all of us. I will use libetpan as an example here. in the current factory package we have libetpan11 and libetpan-devel. and in the queue there is an update that would bump the soname to libetpan.so.13. now it would be renaming a package in autobuild, rename the spec, rename the changes file and check in the new package. To save us all a bit work we slightly change the packaging: we rename the package back to libetpan and let the spec generate an empty main package. Additionally we have 2 subpackages (libetpan13 and libetpan-devel). Of course you should add a provides to the libetpan13 package: Provides: %{name} = %{version} 2. Renaming a package Just a short not how the proper provides/obsoletes should look like in the usual case -> [2] with kind regards darix [1] http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy [2] http://en.opensuse.org/Upgrade_Dependencies#Renaming_a_package -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 6

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

31 Mar '08

Hallo. RC3 of Distribution branding proposal was just released on the Wiki: http://en.opensuse.org/SUSE_Package_Conventions/Branding It is intended as addition to the SUSE Package Conventions Feel free to fix minor issues and discuss major problems or missing issues. Important changes since RC2: - "opensuse" is now consistently "openSUSE" - Self conflict added to branding packages to ensure conflict of one branding with each another (proposed by coolo) - New sections regarding Branding and themes - New sections regarding GNOME packages branding - Branding virtual package specification -- 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

1 0

[opensuse-packaging] Next openSUSE milestone: crypto/base freeze
by Stephan Kulow 31 Mar '08

31 Mar '08

Hi, Just a small reminder - this is the last week to submit changes for the base system and do version updates for crypto related routines. From http://en.opensuse.org/Roadmap/11.0: Mon, Apr 7 Component freeze for beta1, crypto freeze Milestone: We have settled for a KDE branch to go for Milestone: Feature and version freeze for the base system Milestone: Kernel and install works on most targeted machines. Milestone: Packages containing cryptographic routines are frozen (ECR) Preliminary Authoring Deadline for localized doc files (ADL loc prelim) 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] rpm/lzma upgrade issue
by JP Rosevear 29 Mar '08

29 Mar '08

Trying to upgrade to the latest internal rpm this morning (rev 181) from a factory box that hadn't been updated in a couple weeks I received the following error: rpmlib(PayloadIsLzma) <= 4.4.2-1 is needed by rpm-4.4.2-181.x86_64 Presumably because the older rpm could not update itself because of the new payload requirements. Updating to the intermediate rev 179 that was available in the public channel worked around the problem. There are two potential issues: 1) People using zypp to upgrade factory may be halted from upgrades and the more critical: 2) People on older distros may be unable to upgrade to 11.0 when it comes out. Coolo suggested we might need to define some core packages that don't use the new payload system so upgrades work, but it seems like it yast potentially we'd have to upgrade rpm first and then upgrade the packages even if we fix that. -JP -- JP Rosevear <jpr(a)novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

6 12

[opensuse-packaging] Re: commit mozilla-nspr
by Wolfgang Rosenauer 28 Mar '08

28 Mar '08

Hi, h_root wrote: > +- Split out a shared library subpackage. > +Source1: README.SuSE > Patch1: prdtoa.patch > Patch3: pkgconfig.patch > BuildRoot: %{_tmppath}/%{name}-%{version}-build > +Requires: libnspr4 = %{version} > > %description > NSPR provides platform independence for non-GUI operating system > @@ -52,8 +56,26 @@ > -------- > Mozilla Foundation <drivers(a)mozilla.org> > > +%package -n libnspr4 > +Summary: Netscape Portable Runtime > +Group: System/Libraries > +Requires: %{name} >= %{version} I'm wondering about that "split". I understand and support the shared library policy for most cases but I don't support it in this case. The package now consists of mozilla-nspr libnspr4 subpackages where mozilla-nspr only contains README.SuSE (which I have yet to see) and libnspr4 which contains three shared libraries with different names and without SO-versioning. If it's really mandatory that the package name is libnspr4 (while libnspr4.so is only one of the three libs) then please just do a package rename. So to summarize that looks like a split which effectively only is a package rename with some overhead and is only done for the sake of the rename. Personally I think keeping the consistency with older distributions in that special case outweighs the value of that change. Please tell me if I'm wrong and what I don't see. Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] Review Request: themonospot - Avi parser and content descriptor
by hman 27 Mar '08

27 Mar '08

Hi, i dev a cross platform open source (GPLv2) application to scan and edit avi file: http://www.integrazioneweb.com/themonospot dev in C# using MONO and GTK i used OpenSUSE Build Service to build tarball for openSUSE 10.3 and Factory https://build.opensuse.org/project/show?project=home:hmandevteam:themonospot repo: http://download.opensuse.org/repositories/home:/hmandevteam:/themonospot/ i would like to publish it in openSUSE repository. Could you help me ? --------------------------------------------------------------------- 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] Changes in the desktop menu part of the package conventions
by Vincent Untz 20 Mar '08

20 Mar '08

Hi, Starting a new thread with a clear title so everybody reads it :-) I've updated the desktop menu part of the package conventions [1] to fix some errors. See [2] for the discussion. Here's the detail of the changes: + GenericName is not the key used for the tooltip. It's the Comment key. Fixed the examples accordingly. + Make the examples valid .desktop files. Also use StartupNotify and StartupWMClass instead of old KDE-specific keys. + the Encoding key is deprecated, so I removed any mention of it. + Fix the description of the Icon key. The value can be an absolute path. Also link to the icon theme specification to explain where icons should be installed. Thanks, Vincent [1] http://en.opensuse.org/Packaging/SUSE_Package_Conventions/Desktop_Menu [2] http://lists.opensuse.org/opensuse-packaging/2008-03/msg00102.html -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- 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] Fixing package conventions
by Vincent Untz 20 Mar '08

20 Mar '08

Hi, I found several errors on http://en.opensuse.org/SUSE_Package_Conventions/Desktop_Menu What is the process to fix them? I guess it's a bit more complex than just editing the wiki page? Here are the errors: + the xboard example has this line: "Categories=Game;BoardGame" It's missing a ; at the end of the line + Encoding explicitly defines the encoding used in the desktop file. The value “UTF-8” should be used. => the Encoding key is deprecated now, and shouldn't be used any more. The files are always UTF-8 encoded. + Icon defines the icon connected with the application. The value is an icon name without a suffix. Only the .png and .xpm icons are supported. They must be installed either below /usr/share/pixmaps/ or below /opt/gnome/share/pixmaps/. => the value can also be a path to an icon. The icon should be installed according to the guidelines defined in the icon theme specification if possible. + GenericName defines a comment that can be shown in a tool tip. It was defined by the key Comment in old desktop files. => that's wrong. The tooltip is still defined by the Comment key according to the spec. + the emacs.desktop example is not valid: Terminal=0 should be Terminal=false Also, X-KDE-StartupNotify=true should probably be StartupNotify=true and X-KDE-WMClass should be StartupWMClass + I'm confused by the list of categories. Some of them are not defined in the menus spec and shouldn't be used. It's not clear whether the small text above the categories implies that they should be prefixed with "X-SuSE-"? Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 7

[opensuse-packaging] RPM condition
by Bernhard Walle 19 Mar '08

19 Mar '08

Hello, can somebody help me in writing %if %{undefined rhel_version} && %{undefined centos_version} # code %else # code %endif in a way that the build in the OBS / SUSE_Linux_10.0 succeeds? I currently get a parser error. Thanks for your help. Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] Naming of developer snapshot packages
by Ludwig Nussel 18 Mar '08

18 Mar '08

Hi, Suppose I have a package 'foo' for the stable release of that software but also want to package developer snapshots of e.g. the svn repo. I wonder how such a package should be named. Names such as foo-unstable foo-snapshot foo-devx foo-beta foo-experimental come into mind. Is there any established practice for the naming of developer snapshot packages? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

Re: [opensuse-packaging] PySoulSeek and Nicotine
by Jan Matejek 17 Mar '08

17 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pascal Bleser napsal(a): | Christian Morales Vega wrote: | | 2008/3/14, Jan Matejek: | | Nicotine is also dead, nicotine-plus is the project currently alive. | | Pascal Bleser mantains it in Packman (because of legal problems?): | | | | http://packman.links2linux.org/package/nicotine-plus | | Yep. DHT is considered risky by Novell's legal dept. | | I also build ktorrent with DHT on Packman. The ktorrent packages that | ship with openSUSE + the ones in the Build Service repositories are | without DHT (it can be disabled at build time). | | cheers Thanks for the info. Question remains, though: Does Nicotine+ contain DHT or some other technology that is considered risky, AND that is different from original PySoulSeek? ~From what I understood, the SoulSeek protocol has a central server and therefore is "safe". I'd be happy to include Nicotine+ if that's the case. regards, m. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFH3pWnjBrWA+AvBr8RAiDHAJ9XyhlUVneJhuv7kZayB/hVF66IjwCbBlAg swwEitKz96I7NhFAvsS/tFQ= =QqU+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

Re: [opensuse-packaging] New rpm in beta
by Stephan Kulow 17 Mar '08

17 Mar '08

Am Freitag, 14. März 2008 schrieb Stephan Kulow: > Am Donnerstag 13 März 2008 schrieb Stephan Kulow: > > Hi, > > > > If you see build failures in beta, then this is due me trying to > > program C - i.e. support lzma payload in rpm. It's only in BETA. > > OK, beta is through (after several adoptions in build system for that > new payload) and this is a tar of the packages on the current kde cd > built with bzip -9 payload and lzma -2 payload: > > -rw-r--r-- 1 coolo suse 547M 14. Mär 10:44 bzip.tar > -rw-r--r-- 1 coolo suse 491M 14. Mär 10:47 lzma.tar -rw-r--r-- 1 coolo suse 447M 16. Mär 10:13 lzma5.tar lzma -2 compresses 11% better than bzip -9, lzma -5 even 18% And at a pretty impressive price: 2008-03-12 20:41:28: built kernel-source in 4 + 43 + 182 s 2008-03-13 22:03:23: built kernel-source in 5 + 43 + 195 s -> switching from lzma -2 to lzma -5 2008-03-15 05:32:50: built kernel-source in 14 + 50 + 469 s 2008-03-15 18:35:51: built kernel-source in 7 + 42 + 465 s Could be bad luck too of course - especially as the setup times increased too, which is very weired taking my previous measurements with lzma - perhaps the host (the same all the time) was busy. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] PySoulSeek and Nicotine
by Jan Matejek 15 Mar '08

15 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello, there was a mention of Nicotine (a soulseek client, successor to PySoulSeek, http://nicotine.thegraveyard.org/ ) on opensuse mailinglist. I am maintainer of PySoulSeek and would like to drop it in favor of Nicotine. However, contrary to the mention on the opensuse list, it appears that we do not have Nicotine package (yet). Is this true, or was I searching for a wrong name? If we don't have the package, why? Are there some licensing issues i'm not aware of (something along the lines of bittorrent's DHT technology problem), and if yes, how come we can have PySoulSeek (package pyslsk) and not Nicotine? Or is it just that nobody packaged Nicotine yet? regards jan matejek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFH2rjAjBrWA+AvBr8RAkbMAJ4x1BDnT3hsNJCZBYE7KBTd7B4EVgCePDoW 6vWkWGHK7Gg7QAwbK9VvnhI= =Xoh1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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] NetworkManager in alpha 3
by Tambet Ingo 15 Mar '08

15 Mar '08

Hey, There was a pretty frequent crasher in the package I submitted to NetworkManager yesterday. Now, after deadline for alpha 3 packages, I submitted a fix for it. Is it possible to get it to alpha3 still somehow? Tambet --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] Framewave binaries
by Rohit Garg 14 Mar '08

14 Mar '08

Hi, Please provide packages for Framewave library from the oss repos. I really need it. The license is Apache, so that should be no problem. It can be found at http;//framewave.sourceforge.net It's already in the science wishlist. -- Rohit Garg Junior Undergraduate Department of Physics IIT Bombay --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 5

[opensuse-packaging] New rpm in beta
by Stephan Kulow 14 Mar '08

14 Mar '08

Hi, If you see build failures in beta, then this is due me trying to program C - i.e. support lzma payload in rpm. It's only in BETA. 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

3 3

[opensuse-packaging] Request for Co_Maintainer (open-vm-tools)
by Dominique Leuenberger 14 Mar '08

14 Mar '08

Hi everybody (this timeespecially @novell/@suse) I'm on the lookout for a co-maintainer of one of my packages in OBS. The goal actually would be to get the package in the base distribution, out of OBS. As Stephan Kulow told me, this would not be difficult (for him / the project), if some internal packager agrees to co-maintain the package with me. I would say I make the packages in OBS and once ready, you can check them in to your system, if you agree. Any errors in the packages you're welcome to report directly to me (via bugzilla and assign to me or by mail). I'm talking about the open-vm-tools, they can currently be found in home:dimstar project (and were requested by users to be included). I just upgraded (together with an internal dev from vmware, they are quiet supportive) the bundle to support kernel 2.6.25 (tested with rc5). It just does not build for i586 in OBS for the moment (expansion errors on kernel-syms, but that's a Factory owb problem, not of 'my' package). so the question in short: is there anybody that would be willing / ready to work with me on this package, to have it included in openSUSE 11.0? We're still in time before feature freeze and I guess it should be possible to have it integrated. Thank you veyr much for your help! I'm sure the tools would be a great addition to be installed by default on openSUSE on every VMWare installation. We can only support our users with it. Dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

Re: [opensuse-packaging] PulseAudio plans for suse 11.0
by Jan Matejek 13 Mar '08

13 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Morales Vega napsal(a): > 2008/3/11, Wade Berrier <wberrier(a)novell.com>: >> Hello, >> >> >> On Tue, 2008-03-11 at 23:19 +0100, Adrian Schröter wrote: >> > On Tuesday 11 March 2008 19:17:47 wrote Wade Berrier: >> > > Hi, >> > > >> > > I know that PulseAudio is going to be the default sound server for >> > > Gnome. Will it also be for KDE (or better yet, is it going to be a >> > > distribution wide sound server?) >> > >> > I can not tell what is planned, but we were happy to get rid of any extra >> > server process some years ago, because it can hurt sometimes and is not >> > needed anymore, what means it is just overhead (because either alsa does >> > mixing or hardware itself). >> > >> > > The reason I ask is because it would be great if all packages in the >> > > distro were pre-configured to work against pulseaudio. That way no >> > > matter what desktop environment you're using, sound will just work for >> > > all apps. >> > >> > well, it should be no problem if some apps use direct alsa and if some other >> > app gets started later what uses pulseaudio. At least as long pulseaudio >> > daemon gets started automatically (I see no reason why it should run always) >> > and pulseaudio itself is using alsa as well. >> >> >> The idea would be to have pulseaudio go stright to hw:0, and not use >> dmix for either pulseaudio, or anything else. That way the dmix issues >> can be avoided, and all the cool features of pulse can be used. >> Currently, I must stop pulseaudio to run this app, reconfigure alsa to >> run that app, etc... >> > What issues dmix has? You don't need to configure it manually anymore, > and the classic "mixing should be done in kernel" complain isn't > "solved" by PulseAudio. > > Also, would be good to know exactly what are the cool features of > PulseAudio that ALSA hasn't. > - Network transparency? Yes, it's cool, but will not be so much used. > - Per application volumen control? Isn't Phonon going to give us the same? > - ? phonon - um, not really? a) isn't phonon somehow limited to KDE4-based stuff? b) how about legacy applications? (pulse has pulse-oss or whatever it's called) - - how about "every soundcard plays all the sound" ? or precise control of sources/sinks in GUI *and* real-time - let's say i want music to run through my high-end audiophiliac soundcard and stupid icq notification sounds through the built-in piece-of-crud AC97 into tiny speakers in my display? or something (yes, phonon is supposed to do that as well, see above) regards, m. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFH1/k0jBrWA+AvBr8RAh9YAKCz3vuokiyv+F4tidxqYGFAc8s0/gCfZWbi 580D0pXd+IJxCqHM/t5S0E4= =ivpo -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 17

[opensuse-packaging] PulseAudio plans for suse 11.0
by Wade Berrier 12 Mar '08

12 Mar '08

Hi, I know that PulseAudio is going to be the default sound server for Gnome. Will it also be for KDE (or better yet, is it going to be a distribution wide sound server?) The reason I ask is because it would be great if all packages in the distro were pre-configured to work against pulseaudio. That way no matter what desktop environment you're using, sound will just work for all apps. Lennart posted a nice guide of how to package apps so they will work with pulseaudio: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html Wade

4 5

[opensuse-packaging] PAM_SCRIPT
by James Tremblay 12 Mar '08

12 Mar '08

Hey guys, I was wondering about getting pam_script into the default pam_modules RPM what is the reason it isn't already there? Can we include it in openSUSE version? It would certainly help make this solution easier to configure and possibly help write an automated solution around it. http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId… If someone could write an installer for the above solution it would be a huge thing. -- James Tremblay Director of Technology Newmarket School District Newmarket NH 03857 "let's make a difference" http://en.opensuse.org/education --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[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

[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