[03:16] <MTecknology> !info nginx natty
[03:16] <MTecknology> :D
[04:09] <ScottK> MTecknology: Please play with the bots elsewhere.
[04:10] <MTecknology> ScottK: all i did was looked at the version..
[04:11] <ScottK> OK. Based on the :D, it looked to me like you were messing around.
[04:12] <MTecknology> no, I was excited to know for sure that particular version was pushed through; been busy and never followed up and figured this is the easiest and quickest way to check
[04:12] <ScottK> OK.  rmadison nginx would be another way.
[04:46] <Bachstelze> or !msgthebot
[07:54] <dholbach> good morning
[14:40] <jimqode> What is the procedure for becoming a package maintainer for a package?
[14:40] <tumbleweed> jimqode: Ubuntu doesn't have maintainers for packages. If you care about a package, just start looking after it (i.e. subscribe to its bugs, and trigae the existing ones)
[14:41] <jimqode> tumbleweed, who does the packagin of new versions?
[14:42] <tumbleweed> jimqode: for most packages, the mainatiner in Debian. Otherwise, whoever wants to
[14:44] <jimqode> tumbleweed, I see. The versions on ubuntu are not usually bleeding edge. Is that deliberate?
[14:46] <tumbleweed> the latest released version of most packages are uploaded to Debian unstable as soon as the maintaire thinks they are ready (normally as soon as the maintainer notices)
[14:46] <tumbleweed> we automatically sync whatever appears in Debian, until DebianImportFreeze
[14:46] <tumbleweed> https://wiki.ubuntu.com/UbuntuDevelopment etc.
[14:59] <jimqode> tumbleweed, thank you for the info :)
[14:59] <tumbleweed> jimqode: np
[18:34] <huats> does anybody can refresh me the relationship between files in /usr/share/pyshared and /usr/lib/pymodules/python2.X ?
[18:34] <huats> ScottK, probably :)
[18:36] <ScottK> Probably.
[18:37] <tumbleweed> the python policy describes it, IIRC
[18:38] <ScottK> huats: For python (python3 is different) /usr/share/pyshared is where we want code that's common across python versions installed.  It's then symlinked to /usr/lib/pymodules/python2.X  and the .pyc files (which are python version specific) go there.
[18:38] <huats> ScottK thanks
[18:38] <ScottK> barry will now explain all the ways that explanaition is wrong/incomplete.
[18:39] <huats> that was my understanding
[18:39] <ScottK> huats: Use dh_python2 and it will do the right thing.
[18:39] <tumbleweed> but depending on the python helper used, the symlink could be in the package, or done in postinst
[18:40] <huats> I am working on a package that have some extra .py (not only the __init__.py I mean) in the /usr/share/pyshared
[18:40] <huats> and I couldn't figure out why
[18:40] <huats> :(
[18:40] <barry> if it's new packaging, *please* use dh_python2 :)
[18:40] <huats> it is not a new one :(
[18:41] <huats> well it is a package for a software that is not yet in the distro
[18:41] <huats> it uses python-support
[18:41] <barry> huats: it's very easy to convert from pysupport to dh_python2 :)
[18:41] <ScottK> pysupport does it slightly differently.
[18:42] <ScottK> I lost track on the details.
[18:42] <barry> yeah, i have a hard time keeping it all straight too.  dh_python{2,3} is the new goodness
[18:42] <huats> barry,  then I'll have a look
[18:42] <barry> huats: http://wiki.debian.org/Python/PythonSupportToDHPython2
[18:43] <huats> barry, thanks
[18:44] <huats> and ScottK and tumbleweed thanks too
[19:10] <huats> barry, just as a side note I can't use dh_python2 since I need to have a working release on lucid and afaik the  python needed version as listed on the wiki page is not on lucid
[19:13] <barry> huats: i think there's a backport, but that might not help you.  doko or ScottK might know
[19:13] <ScottK> Not afaik.
[19:13] <ScottK> huats: What I do on lucid is just log into a maverick/natty chroot.
[19:13] <ScottK> (for building the source package)
[19:14] <ScottK> If someone wanted to prepare a dh_python2 backport, it's probably a very safe thing to d.
[19:14] <ScottK> d/do
[19:14] <ScottK> I just haven't gotten round to it (and probably won't)
[19:18] <huats> ok ScottK
[19:18] <huats> thanks !
[20:23] <ari-tczew> does anybody know how to fix following warnings? dpkg-shlibdeps: warning: dependency on libusb-0.1.so.4 could be avoided if "debian/clementine/usr/bin/clementine" were not uselessly linked against it (they use none of its symbols).
[20:23] <ari-tczew> is it important?
[20:25] <paultag> ari-tczew: yeah, it means that you're adding in the library at link-time, so it depends on it, but it's not getting called anywhere in the code
[20:25] <paultag> ari-tczew: it's a good thing(tm) to fix
[20:26] <SpamapS> Would anybody care to review this package for possible upload to natty (I know its very late for NEW ;)  bug #746142
[20:26] <paultag> ari-tczew: e.g. let's say libfoo is uselessly linked against bar. let's say `gcc -o bar ./bar.c' works. the build now is doing `gcc -o bar ./bar.c -lfoo'
[20:27] <micahg> SpamapS: probably better off getting in Debian and backporting from oneiric
[20:27] <SpamapS> micahg: why?
[20:28] <micahg> SpamapS: you need an FFe to get it in at this point
[20:28] <paultag> SpamapS: it closes no bugs and is a new feature :)
[20:28] <paultag> SpamapS: get it in debian :)
[20:28] <SpamapS> I think its warranted. Its a php file, a symlink, and some documentation...
[20:28] <SpamapS> and it was promised in a blueprint
[20:29] <paultag> SpamapS: should have got it done before FFe ;)
[20:29] <paultag> erm, FF
[20:29] <SpamapS> I get two very different messages when I talk to different people about universe.
[20:29] <SpamapS> One side says its ok to add new packages late. The other side says no. ;)
[20:30] <micahg> SpamapS: with good reason, it's easier to get something in universe late than in main, but you still need the release team ACK on it
[20:30] <SpamapS> Ok, so, assuming I'm going to go and get their ACK.. would anyone care to review it with that in mind? ;)