[needs-packaging] libcgroup

[Balbir Singh]

URL: libcg.sourceforge.net

Provides a user space library, initscripts and commands to exploit the new resource management features in the kernel. Hardy and Intrepid enable the CPU controller, it would be nice to provide the user space tooling for exploitation of these features.

License: LGPL

[Ian Weisser (ian-weisser)]

This is a package request for libcg, which seems to be included already with nvidia-cg-toolkit.
Adding NVIDIA-Common in case they have any comments or input.

[Chris Coulson (chrisccoulson)]

IanW - I think you're confusing "control groups" (libcg) with the CG language (for programming graphics), so I'm closing the nvidia-common task.

And adding bug tasks isn't normally the way to get feedback from a particular developer or group of developers. For that, you should subscribe the individual(s) to the bug report.

[Balbir Singh (bsingharora)]

I am not sure which individual(s) to subscribe to this report. I tried asking on the #ubuntu-kernel. I'll try again.

[Chris Coulson (chrisccoulson)]

Sorry for the confusion Balbir, my comment was directed at IanW

[Dustin Kirkland  (kirkland)]

I've declined this for Intrepid, but assigned to myself. I'll try to get this packaged when the Jaunty archive opens.

:-Dustin

[Balbir Singh (bsingharora)]

I know it is sort of late for Intrepid, but it would be a nice feature to have given that we've enabled cgroups and a bunch of other controllers. One way would be to add it to Jaunty and backport it? I don't know if that is acceptable. I would really like to make libcgroup available to Ubuntu Intrepid users.

Balbir

[Balbir Singh (bsingharora)]

I was hoping to get this packaged in Jaunty, but we could not. I have some initial work done for packaging for Ubuntu, should I find the right forum and post it. I'll probably need help and guidance.

Balbir

[Jon Bernard (jbernard)]

Hello Balbir, I'm interesting in getting this packaged up for Karmic (if possible). I'm very interested to see what work you've already completed and hopefully collaborate on the packaging completion. Can you post your current work somewhere public? I'll be happy to fixup any issues still remaining.

[Balbir Singh (bsingharora)]

OK, I am uploading what I have for debian packaging as a tarball (done as a part of libcgroup FOSS.IN workout). The man pages are missing and this was done for old code, please review/update. I'll help out, feel free to use this forum or any other to help drive this to completion.

Thanks,
Balbir

[Jon Bernard (jbernard)]

Ok, I've nearly got it. Here's the only show-stopper issue I've found:

    The cgred initscript looks for /etc/sysconfig/cgred.conf. The sysconfig directory is not standard in Debian/Ubuntu as far as I know, so we'll need to either provide our own initscript or make the location of cgred.conf configurable, perhaps using /etc/default/cgred. What are your thoughts here?

I'm attaching the debc file list output so you can see what files are in the package and their locations. I compared this to the current Fedora 11 packages and their near identical with a few slight differences. I'm also attaching the lintian output, these are all issues that should probably be addressed before upload. Let me know what you think.

If we can get the initscript and lintian issues resolved, I can upload the package and it should get included into Karmic.

--
Jon

[Jon Bernard (jbernard)]

Here's the lintian summary

[Jon Bernard (jbernard)]

And here's the extended lintian summary with explainations

[Jon Bernard (jbernard)]

Also, in the release tarballs it's probably a good idea to not include config.sub, config.guess, and dist/libcgroup.spec since they're all autogenerated at build-time.

[Balbir Singh (bsingharora)]

Yes, you are right we need to change that to /etc/default on debian/ubuntu, we could change the script for debian. What that means for us upstream is the need to have distro specific changes to the scripts. I'll see how to best handle that.

I'd be happy to help resolve any issues. We'll remove the config.sub/guess and libcgroup.spec files in the next release.
Thanks for getting this far. I'll respond to the lintian issues, just started looking at them.

[Jon Bernard (jbernard)]

Hey Balbir, I just wanted to give this bug a nudge. I'm happy to write lsb-compliant init scripts and fix up the manpage lintian issues, but the rpath issue is something you guys will need to address directly. That is all that's really holding me up so let me know how to proceed when you get a moment.

[Balbir Singh (bsingharora)]

Sorry for holding you up Jon, I was in the process of getting debian up and running so that I could try the same build scripts on my machine, but alas migration is very hard. I am trying to setup a virtual machine for it. Thanks for the offer to write lsb compliant scripts, I think that would really help. The rpath is something I've been looking at.

So far, I've seen recommendations at
http://lists.debian.org/debian-devel/2008/09/msg00099.html

rpath is added by libtool and can be stripped using chrpath. I am also looking at other packages to see how this needs to be resolved.

[Jon Bernard (jbernard)]

No problem Balbir, I apologize, I did not mean to suggest you were holding me up, just wondering what the next steps where and how I can help. I shall beging working on the initscripts and manpage issues. I've used chrpath before and I believe (but not positive) that it only allows you to change a defined rpath, but cannot remove the rpath from an ELF file. If I'm wrong then that may be the easiest solution, although I've worked on packages that use libtool in the past and have not come across this issue, so perhaps there's a better way.

[Jon Bernard (jbernard)]

Attached is a diff that will fix the manpage warnings for the existing manpages. I don't have a Fedora box to test on, but I suspect these changes will work across the board. If the tests look good it would be cool to get this into the next upstream release.

[Balbir Singh (bsingharora)]

Thanks, I'll take a look. I was in the process of figuring out how to remove rpath, chrpath looks like a good solution, but I wanted to change automake and libtool to do the right thing.

[Jon Bernard (jbernard)]

Hey Balbir, quick update:

I've added chrpath to my build routine to strip the RPATH from all the ELF files. So at this point, I've got everything I need to complete the package (assuming I get enough free time this week ;) ) A more proper RPATH solution would probably be good, but it's not necessary now. I've found I dont need 'config.sub' and 'config.guess' removed from the release tarball, only 'dist/libcgroup.spec' should be removed and the manpage update I posted earlier -- but even those two changes are not necessary to complete the package so at this point just hang tight and i should have something ready for testing very soon.

[Balbir Singh (bsingharora)]

Hi, Jon

Thanks for all your effort with the entire packaging, I've been starved for bandwidth due to various reasons. I'll take a TODO to fix the rpath issue in the library and work on it. Thanks again!

[Balbir Singh (bsingharora)]

Hi, Jon,

Could you post your changes to libcg mailing list. <email address hidden>. We'll review and make the changes needed and also put a longer term TODO to fix RPATH correctly

Thanks,

[Dustin Kirkland  (kirkland)]

Hey guys-

What's the packaging status on this? Feature Freeze is this week, so
if the package is going to make it into Karmic, it needs to get
uploaded ASAP.

Have you posted the package to revu.ubuntuwire.com yet? If not, I
recommend doing so very soon, getting some feedback, and ideally an
advocate or two.

Thanks,
:-Dustin

[Jon Bernard (jbernard)]

I've just finished the last changes to the initscripts and the package is now complete. I'll upload to REVU in the morning and work on getting it reviewed and advocated. I'll post the REVU link here when the upload is complete.

[Jon Bernard (jbernard)]

Package is in REVU: http://revu.ubuntuwire.com/p/libcgroup

[Balbir Singh (bsingharora)]

Thanks, Jon,

I saw some review comments there, In the beginning I had mentioned the license as LGPL, I wonder why it is being interpreted as GPL or am I missing something?

[Jon Bernard (jbernard)]

All of the source files are licensed under the LGPL (2.1) with 3 exceptions: src/parse.c, src/parse.h, and src/pam/pam_cgroup.c

Those files have licenses in the comment header, parse.[ch] specifies GPL and pam_cgroup.c specifies BSD-3 (or GPL)

The discussion on REVU revolves around properly documenting each file and its associated license in 'debian/copyright'. So nearly all of the source is licensed under the LGPL with the exceptions stated above, the effort is to capture those exceptions in the documentation, not to re-interpret or to change the licensing in any way. Does this make sense? Jump on IRC if you have a sec, we can discuss further.

[Jon Bernard (jbernard)]

Ok, I'm now clear on the licensing after discussing [1] with Dhaval.

[1]: http://pastebin.ubuntu.com/259851/

[Balbir Singh (bsingharora)]

Hi, Jon,

We need to change the licensing of parse.[ch] to LGPL (the copyright says that we can distribute the generated files under a different license if it is a part of a larger program) and we prefer LGPL. Could you please change the copyright to reflect that. In the case of pam_cgroup, I need to clarify from Vivek, he redistributed the code under LGPL (see the last para in the copyright).

Thanks for all your help!

[Jon Bernard (jbernard)]

Yes, I will revisit this in the next day or so and get this all straightened out.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

http://packages.ubuntu.com/source/karmic/libcgroup

[Balbir Singh (bsingharora)]

Hi, Jon, Others

Could someone confirm the license change. I like the split of the packages, we would like the work to LGPL'ed, dpkg --license shows GPL. Am I missing something?

Balbir Singh.

[Jon Bernard (jbernard)]

Confirmed. 'dpkg --license' shows the license for dpkg (the debian package manager) itself, not for packages installed on the system. To verify the copyright of libcgroup, if you have the source you can look into debian/copyright, or if you have the package installed on your system you can look into /usr/share/doc/libcgroup1/copyright. Alternatively you can follow the copyright link from the ubuntu package page at [1]. Let me know if you have any questions.

[1]: http://changelogs.ubuntu.com/changelogs/pool/universe/libc/libcgroup/libcgroup_0.34-0ubuntu2/copyright