[00:19] <a|wen> any revu administrators around that can mark me as reviewer?
[00:25] <nhandler> a|wen: Sure
[00:26] <a|wen> nhandler: it's LP andreas-wenning
[00:27] <nhandler> a|wen: Done
[00:27] <a|wen> nhandler: thx!
[00:41] <stochastic> Does anyone have a free minute to REVU either http://revu.ubuntuwire.com/p/a2jmidid or http://revu.ubuntuwire.com/p/xwax or http://revu.ubuntuwire.com/p/xjadeo
[01:47] <quidnunc> Is emacs-23 being packaged for jaunty?
[01:47] <quidnunc> (apart from snapshot)
[05:32] <AnAnt> Hello, GPL3+ is compatible with BSD-C3, right ?
[05:48] <fabrice_sp> AnAnt, according to http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses and http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licenses, they seem compatible
[05:49] <AnAnt> fabrice_sp: thanks
[05:50] <TheMuso> n/c
[05:54] <DGMurdockIII> Open Source development for the AMD64 architecture - http://www.x86-64.org
[05:54] <DGMurdockIII> Open Source development for the AMD64 architecture - http://www.amd64.org/
[05:54] <AnAnt> ?
[05:55] <DGMurdockIII> it the amd cpu open source code
[05:56] <DGMurdockIII> i thougt you guys could make use of it to improve ubuntu
[05:56] <DGMurdockIII> Intel Open Source - http://software.intel.com/sites/oss/
[05:57] <slytherin> DGMurdockIII: Off topic here
[05:58] <DGMurdockIII> why is it
[05:58] <DGMurdockIII> you cant use it
[05:59] <slytherin> What is there to use?
[05:59] <DGMurdockIII> the code
[05:59] <DGMurdockIII> what else
[05:59] <jmarsden> DGMurdockIII: See https://wiki.ubuntu.com/MOTU/Contributing for an idea of what Ubuntu MOTUs do.  If you want to package that code up for Ubuntu ... go for it :)
[07:40] <slytherin> maxb: I believe now you can ask for syc of libjaudiotagger-java
[08:11] <mac_v> Hi all... why hasnt vuze been upgraded to version 4?
[08:13] <hyperair> ask the debian-java team
[08:13] <hyperair> (or ubuntu-java?)
[08:13] <mac_v> does this request have to be sent to the mailing list?
[08:14] <hyperair> i'm sure someone has it in mind
[08:14] <mac_v> ah... ok, someone in -desktop said ask here... :)
[08:15] <hyperair> slytherin: it appers you merged vuze last. do you know anything about vuze's status?
[08:15] <hyperair> version 4 i mean
[08:17] <mac_v> slytherin: i'v been running vuze4 since jaunty , from the time 4 was released , works fine
[08:18] <slytherin> hyperair: mac_v: Adrian Perez is already working on vuze 4 in Debian. He will probably upload it over weekend.
[08:19] <slytherin> After that I can merge/sync it to Ubuntu.
[08:19] <hyperair> mac_v: well there you've got your answer =)
[08:19] <mac_v> \o/ thanx for the heads up ...
[08:19]  * hyperair goes back to trying to figure emacs out
[08:19] <mac_v> slytherin: so in 2 weeks we can expect it in the repos?
[08:20] <slytherin> mac_v: you mean before FF, sure.
[08:20] <mac_v> ok... thanx
[08:48] <dmentre> hello
[08:49] <dmentre> could a core developer look at bug 406351 and bug 406434. Simple synchronizations are needed. These packages are blocking the remaining of the OCaml transition
[08:49] <dmentre> thanks!
[08:57] <geser> dmentre: usually it's easier to get attention from a core-dev in #ubuntu-devel than here (just as a hint)
[09:06] <maxb> slytherin: yup, read the BTS mail myself
[09:06] <maxb> * _just_ read the BTS mail myself
[09:07] <dmentre> geser: ok. Thank you
[09:14] <maxb> slytherin: The package is not in incoming.debian.org but neither is it in the archive - I guess it's being processed by a currently executing dinstall run. I'll try again later
[09:25] <maxb> slytherin: Once the package does show up in unstable, may I subscribe you directly to the sync request, rather than subscribing u-u-s, since you know all the background info on this one?
[09:37] <slytherin> maxb: sure.
[10:49] <gaspa> Laney: around?
[11:20] <devfil> james_w: ping
[11:21] <kaushal> hi
[11:21] <kaushal> is notify-osd available for hardy ?
[11:22] <slytherin> AFAIK, no.
[11:23] <kaushal> any plans to backport it in Hardy ?
[11:25] <maxb> Ironic. I've just been converting my karmic systems back to notification-daemon
[11:56] <slytherin> python packaging gurus, what is the difference between site-packages and dist-packages?
[12:04] <geser> dist-packages is used by the distribution python interpreter and site-packages by a locally installed one
[12:04] <maxb> slytherin: site-packages is what Python upstream uses. dist-packages was created to clarify an ambiguity  - formerly debian packaged python used to use /usr/local/lib/pythonX.Y/site-packages/ as a place for the local sysadmin to plug in local modules. But this location is also the one which would be used by a vanilla install of python into /usr/local. Hence, rename the debian-packaged dir to dist-packages to distinguish the two
[12:07] <slytherin> geser: maxb: thanks for explanation. Surprisingly reviewboard is installing itself into /usr/local/lib/python2.6/dist-packages. :-)
[12:08] <slytherin> So I guess I need to file a bug in reviewboard.
[12:08] <maxb> If you are attempting to install it using the system python installation, that is correct
[12:08] <maxb> Oh, or do you mean a reviewboard .deb is attempting to install there?
[12:10] <slytherin> There is no .deb. All I am doing is easy_install ReviewBoard
[12:11] <maxb> oh, good
[12:11] <maxb> that's fine then
[12:11] <geser> than it's ok to use dist-packages as it uses /usr/bin/python (the system one)
[12:11] <maxb> If you were to execute /usr/local/bin/easy_install ReviewBoard, then *that* would go to site-packages
[12:13] <slytherin> Ok. I now understand it somehow.
[13:31] <ximion> hi
[13:33] <ximion> I have a CDBS-based package, which is split into one -data and one binary package. If I compile it, I get the lintian warning debian-changelog-file-is-a-symlink, which it is indeed.
[13:33] <ximion> Does anyone know where I can disable the creation of the changelog as symlink?
[13:39] <maxb> I thought it was legitimate and intended that the changelog in all but one package be a symlink - but you also need appropriate dependencies to ensure the symlink's target is installed
[13:42] <ximion> maxb: the symlink is relative... and this is really not useful
[14:13] <devfil> james_w: ping
[14:14] <james_w> hi devfil
[14:14] <devfil> james_w: about the papyon project, what should I write in copyright? "The source tarball embeds a copy of iso8601."?
[14:15] <james_w> well, I believe that is under a different license
[14:15] <james_w> so you need to check that the terms of the license are satisfied, and then include that license in debian/copyright
[14:16] <devfil> james_w: ok, really thanks :)
[14:17] <james_w> devfil: it's MIT I think, which is fairly liberal, so there shouldn't be license compatibility issues
[14:18] <james_w> "The above copyright notice and this permission notice shall be included in
[14:18] <james_w> all copies or substantial portions of the Software."
[14:18] <james_w> that's the obvious one to make sure is followed though
[14:20] <devfil> james_w: it isn't I think
[14:33] <slytherin> ximion: as long as the symlink actually points to the correct changelog file when all packages are installed, you can ignore the warning.
[14:33] <ximion> slytheri: okay, thank you
[14:34] <ximion> another question: If a binary in /usr/bin has no manpage (which results in an lintian warning) should I ovveride the lintian message or just let it be?
[14:42] <slytherin> ximion: Ideally you should write manpage.
[14:42] <e-jat> anyone can check bug 404546 ?
[14:43] <ximion> slytheri: a manpage is useless: It is a complete graphical program without any command-line parameters
[14:52] <ximion_> slytheri: Should I override the lintian error about the changelog-symlink?
[15:05] <slytherin> ximion_: I don't think that is necessary.
[15:12] <slytherin> asac: I was wondering if there is any plan about replacing bluez-gnome with gnome-bluetooth in karmic.
[15:13] <asac> slytherin: that or blueman. decision pending during sprint
[15:15] <slytherin> asac: Personally I would prefer gnome-bluetooth considering that it is fork of bluez-gnome and has got backing from 'Bastien Nocera'. :-)
[15:20] <ximion___> slytheri: Okay. I've found the reason for symlinking files: This is automatically done by CDBS, I had to switch CDBS_NO_DOC_SYMLINKING on.
[15:20] <slytherin> ximion___: What is the effect of that? Does it create copy of changelog in every binary package?
[15:22] <ximion___> slytheri: I think it does exactly this. But so no false symlink will be created.
[15:25] <slytherin> ximion___: Then there is problem. If all the packages have same base directory and also include copy of changelog then there will be trouble while installing those packages.
[15:25] <ximion___> slytheri: okay, I checked it again: The symlink IS correct. Should I fix the lintian warning by adding this flag, override it or let it be?
[15:25] <slytherin> ximion___: ignore the warning. let it be.
[15:26] <ximion___> okay
[15:26] <ximion___> slytheri: I got those as comment for smile (http://revu.ubuntuwire.com/p/smile) Is it necessary to create an empty manpage for a GUI-Qt application?
[15:30] <gaspa> ximion___: manpage: why not?
[15:30] <gaspa> and about the link, in mentors.d.o I've removed the link and hard-copied the changelog in rules.
[15:32] <ximion___> gaspa: Because SMILE is a Qt-GUI application which has absolutely no command-line parameters (except filename to open) A manpage is useless.
[15:33] <gaspa> ximion___: not useless. if you want to see what the program does, even if it's completely graphical.
[15:33] <ximion___> gaspa: The symlink points to the changelog of smile-data. Because they have the same changelog, I think this is not problem. But if you did it for Debian, I will override the CDBS example too.
[15:34] <gaspa> although I'd think it's not *necessary*
[15:34] <ximion___> gaspa: Have you written a manpage for your version?
[15:34] <gaspa> :P not yet.
[15:34] <ximion___> ;-)
[15:34] <gaspa> but I've not found sponsors even for this reason
[15:35] <gaspa> did you say that CDBS_NO_DOC_SYMLINKING works?
[15:36] <gaspa> i mean, cdbs wont do a changelog link, with this variable set?
[15:43] <ximion___> gaspa: It should. But unfortunately it always symlink the changelog. I tried CDBS_NO_DOC_SYMLINKING="yes" and CDBS_NO_DOC_SYMLINKING=true, next I will try to figure out if it is correctly set.
[15:43] <gaspa> lol
[15:43] <gaspa> ok
[15:43] <gaspa> nice to know.
[15:43] <ximion___> gaspa: No, it is not :-P
[15:49] <geser> what is exactly the problem with that?
[15:50] <geser> if it' just the lintian warning ignore it as this a ubuntu change to cdbs and I don't know if lintian knows about it (that it's ok)
[16:20] <ximion___> geser: I think there's actually a CDBS-bug in this.
[16:21] <slytherin> ximion___: Why do you think it is a bug?
[16:24] <ximion___> slytheri: It is impossible to disable the linking feature
[16:24] <slytherin> ximion___: Why do you want to diable it?
[16:25] <ximion___> slytheri: lintian complains about this. And because I'm not a MOTU I need someone to sponsor this package. And to get a sponsor it is better to have no lintian warnings left.
[16:26] <slytherin> ximion___: It is warning, not error.
[16:30] <ScottK> ximion___: This is a reasonably well known Ubuntu change to CDBS, so it should be OK.
[16:30] <ScottK> ximion___: If a sponsor complains about it, feel free to direct them to me and I'll explain it.
[16:32] <ximion___> ScottK: Okay, but first I need to find a sponsor ;-) Now I know the Ubuntu change too. (Only the manpage-problem left, but I think I will ignore it too, because it is also in debian very common (a lot of packages have this warning))
[16:33] <ScottK> And then he left.
[16:33] <ScottK> ximion: Don't ignore the manpage one.
[16:33] <ScottK> It is common in Debian, but one that a significant effort is going into fixing.
[16:34] <ScottK> We don't want new packages with the problem.
[16:34] <ximion> ScottK: No, he didn't He just removed the stupid _ from his username.
[16:34] <ximion> ScottK: Okay. What should I write into the manpage? Should the manpage go to a new package? (smile-man)
[16:34] <ScottK> ximion: Disappeared from my user list for long enough for me to not get tab completion the first time I tried.
[16:35] <ScottK> ximion: Yes.  Write the man page and no it goes in the existing binary package.
[16:36] <ximion> ScottK: Should I write to the page what the application generally does? (Because I can't write detailed instructions how everything works because I use this tool less often)
[16:37] <ScottK> ximion: Yes.  Also if there are any command line options/switches (I have no idea what you're packaging) definitely describe those.
[16:38] <ximion> ScottK: It is a complete GUI application (which uses Qt4) It has no parameters except filnames, so first I was a bit confused about the fact that lintian recommends a manpage.
[16:39] <ScottK> ximion: OK.  Then it can be a short man page.
[16:39] <ximion> ...I packaged various other applications and lintian never complained about this. (No manpage was present, apps had a symlink to /usr/bin)
[16:52] <\sh> siretart: http://www.sourcecode.de/content/django-fai-manager-video-tour :)
[17:44] <maxb> hi, I need a bit of advice - what do you do to disable a patch in a cdbs-simple-patchsys package? There's no series file like quilt
[17:46] <ScottK> maxb: If you don't want to remove it, rename it to a filename with no suffix.  simple-patchsys only looks for certain file endings like .diff, .patch, etc.
[17:47] <maxb> In the interests of the entire content not appearing twice in the Debian<->Ubuntu diff, perhaps I should just remove it?
[17:50] <ScottK> Will we want the patch again in the future?
[17:52] <maxb> Possibly.. it's a patch to the in-tree ltmain.sh to pass through --as-needed, but a different ubuntu-specific patch requires reautotoolizing, so they conflict. However, a second ubuntu change is to drop the use of --as-needed, so the ltmain.sh change is unnecessary
[17:53] <maxb> Now if only I could figure out how to make cdbs redo autoconf and automake but NOT aclocal or libtool, I could just leave it alone.
[18:29] <ximion> Could someone check the package libqt4intf at REVU? http://revu.ubuntuwire.com/p/libqtintf4
[19:07] <geser> ximion: commented
[20:30] <ximion___> geser: Are you there?
[20:31] <ximion___> You reviewed my libqt4intf-package at revu ( http://revu.ubuntuwire.com/p/libqtintf4 ) and I fixed all issues now, except for two.
[20:33] <ximion> geser: I override the issues because they are invalid for the package. Could you check the reasons, please?
[20:33] <ximion> because I'm not 100% sure about that.
[21:39] <geser> ximion: have you tried using dh_makeshlibs (which add the ldconfig call to the postinst and postrm) instead of calling ldconfig in postinst yourself?
[22:00] <ximion> geser: The command does not work with this package...
[22:04] <geser> ok
[23:48] <mrooney|w> gilir: hey, I saw you commented on bug 405591
[23:50] <gilir> mrooney|w: ah I though you was away, so I post directly a comment on the bug :)
[23:50] <mrooney|w> nah |w just means at work
[23:51] <mrooney|w> so, what is that diff.gz that is attached?
[23:53] <gilir> mrooney|w: it's the content of the debian directory, generated by debuild -S -sa
[23:54] <mrooney|w> oh okay, what is that useful for
[23:54] <mrooney|w> applying to upstream?
[23:56] <gilir> it's usefull if you want somebody to sponsor your package :)
[23:57] <mrooney|w> gilir: :) so someone applies that diff to the upstream branch and uploads, is that the idea?
[23:57] <gilir> this + upstream tarball and it can be uploaded
[23:57] <mrooney|w> ah I see, that's easy!
[23:58] <mrooney|w> let me just add a link to the milestone in the changelog
[23:58] <mrooney|w> so anyone interested can see changes
[23:59] <gilir> mrooney|w: the diff I attached is an example, feel free to modify it :)