[00:00] <bdrung> tumbleweed: libkibi released.
[05:03] <micahg> highvoltage: sorry about calibre, I should've checked with you before updating
[05:03] <micahg> highvoltage: I'll try to get it fixed
[05:03]  * micahg didn't realized it was seeded
[06:19] <mase_wk> i am trying to build a package of dovecot using sudo sbuild --arch=i386 -d lucid dovecot_2.0.9.dsc
[06:20] <mase_wk> E: 10mount: mount: unknown filesystem type 'aufs'
[06:30] <akheron> how do I assign a Launcpad bug to Lucid?
[06:30] <micahg> akheron: nominate for release?
[06:31] <akheron> hmm, I've seen that link but cannot find it in this bug
[06:32] <micahg> akheron: bug #?
[06:32] <akheron> bug 657394
[06:34] <micahg> akheron: we can't sync a new version for security fixes for the stable release, so you might want to update the title to what you want to fix
[06:35] <akheron> true
[06:35] <micahg> akheron: it's now nominate for series, not release
[06:36] <mase_wk> is there another way of building a package for lucid on maverick ?
[06:36] <micahg> mase_wk: pbuilder, sbuild, chroot?
[06:36] <mase_wk> aside from sbuild -d maverick-i386 packaging_dovecot2/dovecot_2.0.9.dsc
[06:36] <akheron> reading the security team update procedures, it seems to me that these vulnerabilities aren't grave enough to get a security update
[06:36] <mase_wk> micahg: having an issue with sbuild not understanding a 'aufs' file system
[06:37] <akheron> mase_wk: pbuilder-dist maverick create; pbuilder-dist maverick build packaging_dovecot2/dovecot_2.0.9.dsc
[06:37] <micahg> akheron: if you provide debdiffs, the security team will be happy to upload
[06:37] <mase_wk> akheron: do i need arch specified at all , i want to make an i386 package on an 64bit install
[06:37] <akheron> micahg: yes but as lucid has 1.5 and the bugs have been fixed in 1.7, I'd have to do lots of patching
[06:38] <akheron> err, backport the patches that fix the security issues
[06:38] <micahg> akheron: right
[06:38] <micahg> akheron: I can give you a lucid task if you want to work on it
[06:39] <akheron> micahg: well, I don't think I have time really :(
[06:39] <akheron> mase_wk: pbuilder-dist maverick i386 create; etc...
[06:40] <mase_wk> thanks   will try that
[06:40] <akheron> micahg: easier for me would be to just use try to use the natty package in lucid or backport 1.7 and build it myself
[06:41] <micahg> akheron: right, that fixes it for you, but not others
[06:41] <akheron> yep :(
[08:16] <dholbach> good morning
[08:29] <Rcart> o/ danniel
[08:36] <Rcart> here's pretty late, good nights ^^
[09:29] <iulian> G'morning dholbach.
[09:30] <dholbach> hiya iulian!
[10:53] <Laney> argh! ghc6 still hasn't finished on armel
[11:10] <ari-tczew> could anyone take a look on bug 702765 and check whether is it a sync?
[11:19] <ari-tczew> geser: ping
[11:20] <ari-tczew> geser: unping, found the information
[12:23] <highvoltage> micahg: no problem! and no reason you should've checked with me either, it's fine :)
[14:28] <ScottK> ari-tczew: No.  Sorry.
[14:43] <ari-tczew> siretart: could look on bug 702765 ? the only remaining change is dirs which you added. can we drop it?
[14:44] <nonix4> ari-tczew: you happen to have time to look at 683337 again?
[14:45] <ari-tczew> bug 683337
[14:45] <ari-tczew> nonix4: did you test your patch?
[14:45] <nonix4> yes, tested the deb built with pbuilder
[14:47] <micahg> err, features normally don't go through SRU, but I guess this is an exception
[14:50] <ari-tczew> micahg: not biggest feature - one button ;)
[14:50] <dholbach> highvoltage, did you hear back from menesis about schooltool?
[14:50] <micahg> ari-tczew: doesn't matter, features are normally done through backports
[15:03] <siretart> ari-tczew: sorry, not before next week
[15:03] <highvoltage> dholbach: the last time we communicated was the email he sent us on 05/01/11
[15:04] <dholbach> highvoltage, ok - I just thought you might know more - it seems like everyhting in the NEW queue was processed and there's just this one package left that bundles some other code
[15:05] <dholbach> it'd be great to get it sorted out soon
[15:15] <menesis> dholbach, highvoltage: hello
[15:15] <menesis> thank you both for uploading all of the packages
[15:15] <menesis> they reached archive last Monday
[15:16] <menesis> there is only one left, zope.html, that bundles both fckeditor and ckeditor
[15:16] <dholbach> menesis, is it possible to rip it out of the source, add dependencies and add symlinks in the zope.html package to make it "just work"?
[15:17] <menesis> it was kind of hard for me to figure when and from where to remove it
[15:17] <dholbach> yeah, doing that is a pain :/
[15:17] <menesis> is it ok to "rm src/whatever" and then dh_install?
[15:18] <dholbach> I'd probably set up a get-orig-source target that sets up a tarball that does not include that source
[15:18] <tumbleweed> if it's redistributable, it may not be necessary to rip it out the source (unless you are already doing a +dfsg)
[15:20] <menesis> license is ok, GPL/LGPL/MPL
[15:26] <menesis> will try to make it work now
[15:26] <menesis> remove is one thing but have to symlink as well, so repackaging alone won't help
[15:31] <tumbleweed> menesis: dh_link makes the symlinks easy enough. Given that it's redistributable, I wouldn't bother repacking, just remove those files before dh_auto_install (assuming dh)
[15:32] <tumbleweed> longer term, it may be worthwhile convincing the upsrteam to bundle less :)
[15:32] <micahg> tumbleweed: usually better to ask for a flag to use system versions of things
[15:33] <micahg> upstreams feel the need to provide everything
[15:33] <menesis> override_dh_auto_install: rm -r src/.../ckeditor ; dh_auto_install
[15:33] <tumbleweed> yeah, een better
[15:33] <menesis> is it ok?
[15:33] <tumbleweed> menesis: sounds good
[15:33] <menesis> to rm from source
[15:33] <menesis> bzr-builddeb builds in temp directory so should be good
[15:34] <tumbleweed> menesis: what build system? will it fail when it tries to install the deleted files?
[15:34] <menesis> dh --with python-central
[15:34] <tumbleweed> menesis: you can't rely on that behavior, but if files aren't needed at any point, that's fine, dpkg-source understands missing files
[15:35] <tumbleweed> menesis: I mean, is it a setup.py?
[15:35] <menesis> yes
[15:35] <tumbleweed> err python-central? I'd avoid that for new packages?
[15:36] <tumbleweed> the setup.py / MANIFEST.in will have a list of files in it to install, if they are deleted, it may not work so well (depending on how the list is implemented)
[15:36] <tumbleweed> in that case, patching setup.py is a reasonable option
[15:39] <highvoltage> menesis: hey there! (sorry for slow response I'm kind of out of action today)
[16:50]  * Laney flaps
[16:50] <Laney> ghc is so close to being built
[16:51]  * DktrKranz encourages Laney 
[16:52] <Laney> encourage the buildd!
[17:17] <Laney> dpkg-deb: building package `ghc6' in `../ghc6_6.12.3-1ubuntu3_armel.deb'.
[17:17] <Laney> `o/
[17:20] <micahg> highvoltage: calibre ended up building fine after retry, it seems like it was a transient build failure
[17:23] <highvoltage> micahg: cool! thanks now I can apply my change :)
[17:53] <stevecrozz> how do I send a package to launchpad for building on a distribution that I'm not running?
[17:55] <stevecrozz> i've been using 'bzr builddeb -S', do I just specify the distro I want in debian/changelog?
[18:03] <micahg> stevecrozz: yes
[18:16] <stevecrozz> micahg: i'm maintaining the package source in launchpad, if I want to build the package for multiple distributions, what do I commit to bzr in my debian/changes to allow that
[18:18] <micahg> stevecrozz: you might want to use Launchpad build recipies for that, or there's a tool someone built called drobotik: https://launchpad.net/drobotik
[18:42] <pabelanger> micahg: Thanks for that link.  I've been wanting to try it for a while now
[19:02] <trinikrono> hey guys i work with the bugsquad and i am seeing a lot of needs-packaging bugs is there anything i can do to help them get noticed or worked on?
[19:04] <micahg> trinikrono: https://wiki.ubuntu.com/Bugs/HowToTriage#Needs%20Packaging%20Bugs
[19:04] <trinikrono> micahg: thats what i was reading
[19:05] <micahg> trinikrono: it says what you can do there
[19:06] <trinikrono> okie will do
[19:24] <trinikrono> micahg: do i have to make the upstream rfp or should the reporter make it?
[19:25] <micahg> trinikrono: not really any point, RFPs are usually ignroed
[19:25] <micahg> *ignored
[19:25] <micahg> or rather, there's not usually people working on them
[19:25] <trinikrono> ok hold on
[19:25] <trinikrono> lets say bug 622185
[19:26] <trinikrono> what should happen before its triaged?
[19:26] <micahg> trinikrono: we should go back to -bugs
[20:21] <pabelanger> Daviey: ping?
[22:59] <matttbe> Hello
[22:59] <matttbe> I'm looking for a sponsor in order to merge my branch lp:~cairo-dock-team/cairo-dock-plug-ins/ubuntu into lp:ubuntu/cairo-dock-plug-ins
[22:59] <matttbe> => https://code.launchpad.net/~cairo-dock-team/cairo-dock-plug-ins/ubuntu/+merge/46668
[23:00] <matttbe> But this is not my main request. I also want to note that this branch "lp:ubuntu/cairo-dock-plug-ins" is not up to date.
[23:00] <matttbe> Who can help me to fix this problem and/or what can I do?
[23:01] <micahg> matttbe: it's a UDD bug
[23:01] <matttbe> Do I have to contact the ubuntu-branches team?
[23:01] <micahg> matttbe: http://package-import.ubuntu.com/status/cairo-dock-plug-ins.html#2010-04-22%2002:11:14.824041
[23:01] <micahg> matttbe: you can file a bug at https://launchpad.net/udd
[23:02] <matttbe> micahg: thank you! :)
[23:02] <stevecrozz> I want to propose this package be included in ubuntu (https://launchpad.net/~uwsgi/+archive/release/+packages), should I go over it with someone first? or should I just make the proposal?
[23:03] <micahg> stevecrozz: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[23:05] <kamal> hello MOTU's ...  its been awhile since I've done a LP/bzr merge proposal.  is this properly queued?:
[23:05] <kamal> https://code.launchpad.net/~kamalmostafa/ubuntu/natty/alarm-clock-applet/lp704659/+merge/46705
[23:05] <kamal> and is it proper that I assigned the bug LP #704569 to ubuntu-sponsors ?
[23:05] <stevecrozz> micahg: the maintainer of the proposed debian package has decided the ubuntu package should be maintained separately to account for separate packaging needs, i think that means I'm in the 'Going through MOTU' section of this document
[23:05] <kamal> oops make that bug LP: #704659
[23:06] <ebroder> kamal: bugs should never be *assigned* to ~ubuntu-sponsors. if you attach a debdiff you should subscribe ~u-s, but if you have a merge proposal you should not
[23:06] <kamal> ebroder: oops -- glad I asked -- who should the bug be assigned to?
[23:06] <ebroder> kamal: nobody
[23:07] <micahg> stevecrozz: shouldn't need to do that
[23:07] <ebroder> kamal: (opening a proposal to merge a branch into one of the lp:ubuntu/ branches automatically causes that to show up on the sponsorship queue; additionally subscribing ~u-s to the bug causes it to show up twice)
[23:07] <stevecrozz> macahg: can you elaborate? do you mean the package should be maintained upstream with debian?
[23:08] <kamal> ebroder: got it, thanks much
[23:08] <micahg> stevecrozz: ideally, yes, do you have a link to where the Debian maintainer said that
[23:08] <kamal> ebroder: oh I see -- I had confused "subscribing" and "assigning" ... *sigh* it has been awhile.
[23:08] <stevecrozz> micahg: he said it in an email to me, i can forward that to you if you like, it was pretty informal
[23:09] <micahg> stevecrozz: no, that's ok, it's not even in Debian yet
[23:09] <micahg> stevecrozz: what changes are necessary?  we can maintain a diff if necessary, but there shouldn't need to be many
[23:10] <stevecrozz> micahg: i'm not entirely sure, maybe i can get leonid in here later and we can discuss the differences
[23:11] <stevecrozz> i want to organize some kind of communication here so we don't miss any more releases, its already been 2 or 3 since i started maintaining a ppa for this package
[23:17] <stevecrozz> micahg: the document says i need this package signed off on by two ubuntu developers, how can I find them?
[23:18] <micahg> stevecrozz: well, we still have a month until feature freeze, but you need to upload to revu, it would be better to sync from Debian and add changes on top
[23:23] <stevecrozz> micahg: ok I'll sync with the owner of the proposed debian package and try to figure out if we can get it included in debian
[23:24] <micahg> stevecrozz: just keep in mind, Feb 24 is the cut off for new packages unless there's a really good reason
[23:27] <stevecrozz> yeah i doubt i'll make the cutoff, i just want to get some forward momentum because this package is useful and its getting nowhere fast as far as official packaging
[23:29] <micahg> stevecrozz: well, if you won't make the cutoff you can try to go through revu, it would just be easier if it's maintained in Debian, once it's in, we can sync from Debian after that
[23:31] <stevecrozz> micahg: so i can propose the package with the thought of maintaining them separately only until it makes it into debian?
[23:31] <micahg> stevecrozz: yes
[23:32] <stevecrozz> sounds reasonable, thanks, i'll get started