[00:33] <gmcquillan> Is there any plan to backport changes to beanstalkd from 1.4.6 to 1.4.3 for the lucid repos?
[00:33] <gmcquillan> 1.4.3 suffers from a fairly significant service vulnerability.
[00:38] <persia> gmcquillan, There's little chance that anyone who knows the answer to that is about.
[00:38] <persia> But, I'll happily show you how to find the answer:
[00:38] <gmcquillan> persia: Ah, great, tahnks.
[00:39] <gmcquillan> Beanstalkd's changelog doesn't exist.
[00:39] <persia> 1) https://bugs.launchpad.net/ubuntu/+source/beanstalkd/+bugs shows all the bugs we're tracking for beanstalkd
[00:39] <gmcquillan> Cool. I'll look there.
[00:39] <persia> Since there is nothing listed, there's a good chance that nobody involved in Ubuntu is paying attention to the issues you are talking about.
[00:40] <gmcquillan> That's a distinct possibility.
[00:40] <gmcquillan> I'll file a bug.
[00:40] <gmcquillan> Thank you.
[00:40] <persia> 2) https://bugs.launchpad.net/lucid-backports/+bugs shows all the stuff currently in review for backporting to lucid (as distinct from cherrypicking bugfixes)
[00:41] <persia> Since beanstalk isn't there, it looks like if there are plans to backport, they aren't advanced enough to be public yet (which probably means they don't exist, as the first step in backporting is usually to file a bug)
[00:42] <ebroder> gmcquillan: you said vulnerability right? persia: wouldn't that be more of an issue for MOTU SWAT than backports?
[00:42] <persia> ebroder, I'm just pointing at resources to find out about plans to do stuff.  Yes, if there is a security issue, and nobody else does anything about it, MOTU SWAT tries to deal.
[00:44] <gmcquillan> Well, I'll file a bug and go from there.
[00:44] <persia> gmcquillan, It's worth noting that there's not much history of active Ubuntu interest in beanstalkd, which means that if you want it fixed quickly, you'd do best to be the person fixing it.  Filing a bug (especially a security bug) will get attention, but likely not as much as you can provide directly.
[00:45] <gmcquillan> I'd love to help, but I've never made a deb before, and a cursory look makes it seem really time consuming.
[00:45] <gmcquillan> I can definitely give it a shot, though.
[00:46] <m4t> hey, is there a preferred way to switch versions of gcc? eg. from 4.4 to 4.5? ive got it installed but the symlinks in /usr/bin still point to gcc-4.4. is there something like 'update-alternatives' for this?
[00:46] <kees> m4t: usually you just set CC=gcc-4.4 or whatever and do your build
[00:47] <m4t> will that use cpp-4.5, etc. then?
[00:47] <kees> m4t: yeah, each gcc is versioned to use it's matching tools
[00:47] <m4t> kees thanks
[00:47] <kees> m4t: np
[00:48] <m4t> for background on why i'd even bother... ive tried compiling 2.6.35.8 and 2.6.36, but neither will boot
[00:49] <m4t> didnt see this issue with 2.6.35.7 compiled on 10.04 (which i'm running now)
[00:49] <persia> gmcquillan, The hardest part for that sort of thing is just preparing the cherrypick patch.  There's heaps of folk who can lead you through the process of getting a patch applied.
[01:36] <RoAkSoAx> kirkland: anything that I might be missing? https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-powernap-improvements
[05:08] <m4t> i have been trying for many hours to figure this out; an identical kernel source tree, with identical .config, and identical kernel-package, compiles+boots from lucid. try the same thing on maverick, it compiles, but hangs during boot
[05:08] <m4t> i've tried both gcc 4.4 and 4.5
[05:08] <ebroder> m4t: what kernel version? you can't generally use an older kernel on a newer release
[05:09] <m4t> 2.6.35.8, 2.6.36, and 2.6.35.7 all hang in the same spot
[05:09] <ebroder> interesting. well, that exhausts my expertise on kernel hangs
[05:09] <m4t> right after the first ehci device is setup. if i do things like cmdline=nousb acpi=off pnpbios=off
[05:09] <m4t> it'll just hang in a different place, like after the ps2 keyboard is initialized
[05:10] <m4t> i'm guessing its somewhere in the toolchain
[05:11] <m4t> the 11.04 2.6.36 image boots fine
[05:13] <m4t> i might debbootstrap 10.04
[06:36] <m4t> 2.6.36 compiled inside a lucid debootstrap chroot boots fine
[06:36] <m4t> :/
[06:36] <m4t> i wonder what part of the toolchain is causing that
[06:36] <m4t> binutils?
[07:30] <dholbach> good morning!
[09:42] <cjwatson> ebroder: gfxpayload lists> yes please, perhaps /usr/lib/grub/i386-pc/ would be OK since I think this is only useful for the BIOS port
[09:49] <mdz> cjwatson, kees, pitti, any feedback on the brainstorm list?
[09:53] <cjwatson> I haven't got to it yet, sorry
[09:58] <speakman> Anyone know if there's a Xorg release with this patch available: http://lists.x.org/archives/xorg-devel/2010-October/014150.html
[10:29] <\sh> micahg: zf 1.11.0reallyfinal rdy to be bped
[10:31] <Ian_Corne> what are SRUs?
[10:32] <\sh> Ian_Corne: Stable Release Updates
[11:28] <jelmer> cjwatson: Hi
[11:28] <jelmer> cjwatson: I did some more investigation yesterday; it looks like the branching scheme setting in your configuration was changed for some reason
[11:31] <j1mc> dholbach: how did things turn out at the UDS session about the packaging-guide?
[11:32] <j1mc> i'm about to head out to work, but would like to check-in soon about any reactions/feedback, etc.
[11:32] <dholbach> j1mc, great - I just put up the notes in the blueprint whiteboard, but hope to get to finish the spec today
[11:33] <dholbach> j1mc, as soon as it's on the wiki I'll let you know
[11:33] <j1mc> dholbach: thanks :)
[11:33] <dholbach> j1mc, first week back from UDS was somewhat ... hectic ... to say the least
[11:33] <dholbach> if not today, then Monday morning
[11:33] <dholbach> but I'll definitely keep you in the loop
[11:33] <j1mc> dholbach: no worries.  i totally understand.  i'm sure there is always a lot to process coming out of UDS.
[11:34] <dholbach> yes :)
[11:34] <dholbach> thanks for all your feedback!
[11:34] <j1mc> yw :)
[11:40] <jelmer> cjwatson: setting this in ~/.bazaar/subversion.conf should fix it: branching-scheme = list-QlpoOTFBWSZTWZGF0F4AABPRgAAQABK-bR4AIAAhKgGk0eT0oU0yMTExIMb967Iba8QuvgzkikwSS9mEPH4u5IpwoSEjC6C8
[11:41] <jelmer> cjwatson: I'm not sure what caused that to change.
[11:41] <jelmer> cjwatson: Either way, I would recommend an upgrade to the newer mappings at some point. :-)
[11:57] <cjwatson> jelmer: hm, odd.  ok, thanks, I will do that.  I decided not to upgrade to the newer mappings because d-i is due to move to git in the very near future anyway
[11:58] <cjwatson> that looks more promising, it's saying "copying revision 0/128"
[11:59] <cjwatson> yep, perfect.  thanks!
[12:13] <ScottK> barry: Looks like subversion should be on your python2.7 list if it's not already.
[12:18] <ScottK> pitti: I'd appreciate it if you could review/accept the SRU for Bug 607117 today.  It's from a first time contributor and so I'd like to make sure they have a good first experience.
[12:25] <cjwatson> Daviey: do you have a sample test package for bug 633015 lying around?
[12:25] <cjwatson> Daviey: I want to get a further change to dpkg into lucid-cat, and it would be helpful to clear this one out first, so I'm willing to do some verification work
[12:29] <pitti> Good morning
[12:29] <pitti> mdz: sorry, no time for it during plumber's
[12:30] <pitti> ScottK: lucid? no problem, I'll get to it right away
[13:01] <Riddell> pitti: how do I exclude files from being passed to dh_scour?
[13:06] <pitti> Riddell: the standard -X debhelper option works
[13:07] <Riddell> pitti: how do I get cdbs to pass that on?
[13:09] <pitti> Riddell: ah, I guess I need to introduce a DH_SCOUR_FLAGS
[13:09] <pitti> Riddell: the more interesting question is why it's necessary in the first place; is there a class of images which we sholdn't compress?
[13:11] <Riddell> pitti: no but it's very fussy about valid XML so I now have a shed load of SVG files to work out how to make valid
[13:11] <Riddell> and some of them I can't work out what the error is
[13:11] <ScottK> Riddell: More reason to migrate to dh 7....
[13:11] <ScottK> pitti: Thanks.
[13:11] <pitti> Riddell: it's not supposed to crash on invalid files, does it?
[13:11] <Riddell> pitti: yes
[13:12] <pitti> Riddell: oh, would you please file a bug about it with the details (and perhaps an example svg)?
[13:12] <pitti> Riddell: it should just not touch the file then
[13:13] <Riddell> hum.  launchpad doesn't know about the source package https://launchpad.net/ubuntu/+source/python-scour
[13:13] <pitti>  Riddell: it's "scour"
[13:13] <cjwatson> the source package is scour
[13:13] <ScottK> https://launchpad.net/ubuntu/+source/scour
[13:16] <cjwatson> 2010-11-05 13:14:35 INFO      - <postgresql-9.0_9.0.1.orig.tar.bz2: downloading from http://ftp.debian.org/debian/>
[13:16] <cjwatson> 2010-11-05 13:14:39 INFO      - <postgresql-9.0_9.0.1-1.debian.tar.gz: downloading from http://ftp.debian.org/debian/>
[13:16] <cjwatson> 2010-11-05 13:14:39 INFO      - <postgresql-9.0_9.0.1-1.dsc: downloading from http://ftp.debian.org/debian/>
[13:16]  * Riddell doh
[13:16] <pitti> cjwatson: (just reviewing d-i lucid upload) -- it'll rebuild against 2.6.32-26, I guess that's okay?
[13:16] <cjwatson> E: libpq-dev is in main but its source (postgresql-9.0) is not.
[13:16] <cjwatson> pitti: ^- what should be done with this?
[13:16] <cjwatson> um, d-i hardcodes the kernel version
[13:16] <cjwatson> or ABI anyway
[13:16] <pitti> cjwatson: ah, ok; I'll reject it then?
[13:17] <cjwatson> hang on
[13:17] <pitti> cjwatson: depends on whether we want to make 9.0 the default version in natty
[13:17] <cjwatson> no, please accept it - it will build against -updates
[13:17] <pitti> there are no packaged server-side extensions yet
[13:17] <cjwatson> the current version in -updates is broken, so I'd like to get that through first
[13:17] <pitti> so I'm still a bit hesitant
[13:17] <cjwatson> unless -26 is going to make it to -updates very soon
[13:17] <pitti> cjwatson: -26 will still say in -proposed for a fair while; it's a huge update
[13:18] <pitti> cjwatson: alright, thanks for heads-up
[13:18] <pitti> cjwatson: psql> alternative is to have an ubuntu specific version of 9.0 without the client-side libs
[13:18] <cjwatson> ok, then it should still be possible to build d-i against -25, since it looks at all of -security, -updates, and -proposed and picks the newest for the selected ABI
[13:19] <cjwatson> pitti: psql> ok, I have no strong feelings on it, I was just looking at current failures processing new-source
[13:19] <pitti> I'd rather avoid having two major versions in main
[13:19] <cjwatson> agreed
[13:19] <pitti> cjwatson: can we ignore this one for a bit?
[13:19] <pitti> they are available in my PPA, for people who need it
[13:19] <cjwatson> sure, it's got plenty of company
[13:19] <pitti> I'll talk to the server team about it, but not today
[13:20] <pitti> heh
[13:20] <cjwatson> new-source is pretty manual ...
[13:20] <cjwatson> the Debian FTP team still seems to be doing quite a lot of NEW processing, despite the freeze
[13:21] <azeem> well, there was an announcement that they wouldn't, and some outcry
[13:21] <cjwatson> yeah, though I thought it was meant more as "seriously, we have other priorities right now, stop bugging us"
[13:28] <pitti> cjwatson: do you keep a list of the new-source'd packages to mass-source-NEW them?
[13:29] <cjwatson> pitti: yes, and I'm just doing that now
[13:29] <pitti> thanks
[13:29] <pitti> seb128: do you wait for anything in particular in NEW?
[13:29] <cjwatson> (actually I forgot to keep the list before feeding to flush-syncs, but I reverse-engineered it)
[13:30] <cjwatson> gar, people keep manually uploading duplicates of Debian NEW packages to Ubuntu so I get errors
[13:30] <cjwatson> stoppit
[13:31] <cjwatson> just request the sync instead, it will be done within a working day, you can't possibly be that impatient at this point in the release cycle :-)
[13:32] <pitti> (or use PPAs if you are)
[13:35] <jcastro> mpt: who is in charge of the renaming of package descriptions work? And is there a spec?
[13:37] <ScottK> cjwatson: I think that (gar, people keep manually uploading duplicates of Debian NEW packages ...) is worth a mail to ubuntu-devel.
[13:40] <cjwatson> ScottK: I mailed today's two uploaders directly and CCed ubuntu-archive, but I guess so
[13:40] <ScottK> It's one good answer to "why not just use syncpackage".
[13:41] <mpt> jcastro, no-one, and there's no spec yet
[13:41] <mpt> unfortunately
[13:41] <mpt> jcastro, reporting a bug about it would make me less likely to forget it :-)
[13:42] <jcastro> mpt: ok so other than we think it's a good idea we don't have anyone committed to fixing it?
[13:42] <mpt> jcastro, correct
[13:49] <cjwatson> ScottK: done, thanks
[13:49] <ScottK> You're welcome.
[14:00] <seb128> pitti, not yet I think, mterry has gtk3 on its way though
[14:00] <seb128> not sure if he uploaded yet
[14:00] <mterry> seb128, nope, fixing some gtk3.0-doc issues I just found
[14:17] <Riddell> pitti: can I add DEB_DH_SCOUR_ARGS to cdbs?
[14:17] <Riddell> bug 671407
[14:18] <sladen> roflol
[14:19] <geser> pitti: Hi, do you know if it's planned to get postgresql-9.0 into natty? And if yes, how to resolve that postgresql-9.0 take over some binary packages like libpq5 from postgresql-8.4
[14:19] <ScottK> geser: Look in the scrollback.  he's going to discuss it with the server team next week.
[14:20] <geser> ScottK: ok
[14:20] <ScottK> (this is why it's not in yet)
[14:44] <cjwatson> list-merges: http://paste.ubuntu.com/526341/ (output: http://paste.ubuntu.com/526342/)
[14:44] <cjwatson> useful to anyone else?
[14:44] <cjwatson> it's hideous screen-scraping right now, should probably work on the server side so that it can be done more programmatically
[14:44] <cjwatson> (that output is from 'list-merges "Colin Watson"')
[14:45] <cjwatson> maybe should call it grep-merges, analogous to grep-excuses
[14:45] <ScottK> cjwatson: Yes.  Would save me digging through several pages on MoM.
[14:45] <cjwatson> bdrung: ^- do you think the above would be OK for ubuntu-dev-tools?  it's a new dependency on python-beautifulsoup
[14:45] <cjwatson> might be a good idea to future-proof the scraping first though
[14:47] <cjwatson> perhaps should also list versions or something
[14:47] <soren> cjwatson: I'm surprised nothing in there depends on beautifulsoup already.
[14:51] <ScottK> cjwatson: If you're leary of the depends, just make it a suggests and have the script produce an appropriate error if it's not present.  Devscripts (as I'm sure you know) does this a lot already and I think it's quite reasonable for a tool like this.
[14:56] <pitti> Riddell: DEB_DH_SCOUR_ARGS> sure, please go ahead; otherwise I'll do that on Tuesday
[14:58] <cjwatson> ScottK: *nod*
[15:05] <barry> ScottK: yes, subversion is definitely on my list (i'm working on that one next actually).  fixed in my ppa, it is still broken upstream afaict, but i have a good patch.  stay tuned
[15:06] <ScottK> barry: Cool.  I uploaded numpy this morning to get it rebuilt with pyhton2.7 support.  It still needs you to figure out what to do about the docs/Main Inclusion.
[15:07] <barry> ScottK: please remind me: is there a python27 tagged bug on that?
[15:07]  * ScottK looks
[15:07] <ScottK> It's not actually python2.7 it's numpy picking up new depends.
[15:08] <ScottK> barry: Actually it's tagged that way: Bug #664397
[15:08] <barry> ScottK: cool, that will work
[15:09] <ScottK> Stolen would be more accurate than missing.  I know where they went, just not sure the best way to move forward ...
[15:09]  * barry nods
[15:10] <pitti> Riddell: I don't think it's going to like the typo at the start of debhelper.mk.in
[15:11] <Riddell> pitti: it didn't, fixed
[15:11] <pitti> Riddell: I guess/hope it'll just FTBFS; I committed a fix t obzr
[15:11] <pitti> oh, seems we had a mid-air collision then
[15:11] <pitti> Riddell: ah, thanks
[15:13] <Riddell> this scour thing adds a lot of build times
[15:14] <Riddell> I can't even remember what I'm building it's taken that long
[15:24] <Riddell> pitti: hmm, the way scour is used by cdbs it gets run once for every binary package on the same files
[15:24] <Riddell> no wonder it takes so long
[15:25] <cjwatson> apw: has omap been intentionally dropped from the main linux source package on armel?
[15:25] <pitti> Riddell: oh, I see; it probably ought to be called with -p${cdbs_curpkg} or something like that then?
[15:25] <apw> cjwatson, yes, we are expecting that to come out of linaro in short order
[15:25] <apw> (is that causing you issues?)
[15:26] <Riddell> pitti: yes
[15:26] <Riddell> pitti: let me check if that helps
[15:26] <pitti> Riddell: (I didn't test this at all -- should look at how other dh_* is called)
[15:27] <pitti> Riddell: I have a fixed dh_scour, testing ATM
[15:27] <ScottK> pitti: It would also be nice to have (not this week) an equivalent solution for DH7 packages.
[15:27] <pitti> ScottK: solution for what?
[15:27] <cjwatson> apw: just means I need to point debian-installer at something else
[15:27] <cjwatson> ScottK: i.e. a sequence file?
[15:27] <ScottK> cjwatson: Yes.
[15:27] <pitti> ScottK: you can do dh --with-scour already
[15:27] <cjwatson> --with=scour, right?
[15:27] <pitti> ScottK: I wrote /usr/share/perl5/Debian/Debhelper/Sequence/scour.pm
[15:27] <ScottK> pitti: OK.
[15:27] <pitti> cjwatson: sorry, yes
[15:28] <pitti> tpyos are mien
[15:28] <ScottK> pitti: You're ahead of me once again.  Thanks.
[15:28] <bdrung> cjwatson: what does this tool do?
[15:28] <bdrung> for what is it used?
[15:28] <ScottK> Riddell: We should decide if we want --with-kde to imply --with-scour or not.
[15:29] <Riddell> ScottK: I think we do but only once scour doesn't fail on invalid SVG files
[15:29] <Riddell> else that'll be a lot of files needing fixed
[15:29] <ScottK> Yep.
[15:29] <pitti> give me 10 more mins to ensure that this works, then I'll throw it nattywards
[15:30] <pitti> I confirmed that it works on blue.svg now
[15:30] <pitti> IOW, leaves it untouched
[15:32] <pitti> ok, works; uploaded
[15:32] <pitti> Riddell: ^
[15:32] <pitti> sorry for the hassle
[15:33] <pitti> fixing those SVGs might still make sense at some point; crunching an 800 kB SVG is going to save a lot of space
[15:34]  * pitti &
[15:35] <cjwatson> bdrung: you run 'grep-merges "Benjamin Drung"' and it tells you all the merges you have on merges.ubuntu.com
[15:35] <cjwatson> analogous to grep-excuses for Debian testing propagation
[15:36] <bdrung> cjwatson: that's a tool that fits into ubuntu-dev-tools
[15:36] <cjwatson> sounds good.  I'll get the server side improved first
[15:36] <bdrung> cjwatson: add don't forget to add a manpage
[15:37] <cjwatson> of course
[15:37] <cjwatson> apt-cache show man-db :-)
[16:22] <seb128> does anybody know if there is a legal reason the copyright file needs to have a list of copyright holders?
[16:22] <seb128> or another non legal reason out of having the debian policy saying so?
[16:22] <seb128> or said different, "is there any reason we couldn't stop doing that"?
[16:25] <DktrKranz> seb128: usually, the license text itself (i.e. you are allowed to do stuff if you put the name of the holders)
[16:26] <DktrKranz> this is especially stated in BSD and Expat
[16:27] <seb128> is there anything which stop us to autogenerate them from some grepping?
[16:27] <seb128> that would be accurate compared to the current ones, 99% of packages don't maintain the list of copyright owner
[16:27] <DktrKranz> as long as it's accurate, I don't think so
[16:27] <seb128> they got right on first upload and then nobody cares updating them
[16:27] <seb128> well the point is that what we have now is nowhere to be accurate
[16:28] <DktrKranz> IIRC, cdbs has some kind of check for copyright holders
[16:29] <DktrKranz> it will prevent packages from building, but I'm not sure how it works
[16:29] <seb128> which nobody seems to use, or at least I've never seen it used
[16:29] <DktrKranz> yeah, I've always seen it in cdbs maintainer packages only :)
[16:30] <DktrKranz> other than this, we do some check when some packages need new overrides, but that happens for a very low percentage of packages
[16:31] <cjwatson> I think "99%" is probably wrong.  I'd say considerably more than 1% of packages only ever have one copyright holder. :-)
[16:32] <DktrKranz> maybe it's more than 1%, but indeed it's not so common
[16:32] <seb128> cjwatson, right, make that 60% if you want
[16:32] <DktrKranz> unless you call yourself python*, or kernel*
[16:32] <seb128> still it seems we spend time getting the first list but don't update them
[16:33] <seb128> so either we need it there and accurate and we have an issue
[16:33] <seb128> or we don't and we waste time
[16:33] <mr_pouit> oh, I think it's very often updated for new major releases
[16:33] <DktrKranz> first time is mandatory, or you get reject. subsequent uploads, it depends who uploads what
[16:34] <cjwatson> ISTR this was discussed at painful length on ... was it debian-policy? ... a few months back
[16:34] <cjwatson> might be worth finding and reviewing that
[16:35] <DktrKranz> I'm pretty sure nobody would sue me if I forgot to mention a couple of holders, but that can't be the rule
[16:35] <seb128> well, do you think the current manual outdated list is buggy over what an automatic grep would be?
[16:37] <DktrKranz> most of the times a manual grep/licensecheck is fine, but that won't work for perl packages, I guess (they have license info at the bottom of each file)
[16:37] <DktrKranz> and, sometimes, is not so accurate in case there are more holders, on multiple lines
[16:40] <DktrKranz> cjwatson: <4A2F779F.80104@leat.rub.de>
[16:40] <DktrKranz> probably that one?
[16:41] <cjwatson> DktrKranz: I don't think it was that thread as such, it was something this year I believe
[16:42] <DktrKranz> mh, I remember something from that lenghty DEP-5
[16:42] <DktrKranz> I'll have a better look
[16:43] <cjwatson> it wasn't a DEP-5 thread, I don't think
[16:51] <bdrung> how do i get an item removed from the list http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt ?
[16:52] <cjwatson> file bug, subscribe ~ubuntu-archive
[17:03] <cjwatson> slangasek: would you mind if I merged ttf-indic-fonts?  it would save having to back out a change in debian-installer
[17:03] <slangasek> cjwatson: go right ahead
[17:04] <cjwatson> thanks
[17:20] <geser> are removals from Debian imported regularly?
[17:22] <cjwatson> geser: I think the best answer is "irregularly"
[17:22] <cjwatson> I haven't personally done any this cycle yet, though other admins may have
[17:23] <geser> ok, do they also include packages with Ubuntu delta or do those need seperate removal requests?
[17:24] <cjwatson> it's an option in the script
[17:24] <geser> as I'm never sure when I should file a removal bug or just simply wait for the next removal import
[17:24] <cjwatson> if you care about particular packages, please feel free to file bugs
[17:25] <geser> thanks
[17:31] <segv`> Quick question, trying to figure out the best way to handle this, We're setting up about 50 LTS 10.04 servers and want to create a local repo, but in doing so, we're only going to ever need the 64bit versions of binaries, any of you have a simple solution or recommendation on how to handle this?
[17:31] <segv`> figured the dev guys would know a thing or to, I can redirect that to -server if need be.
[17:36] <cjwatson> you could use debmirror with the --arch=amd64 option
[17:39] <smoser> kees, or cjwatson , if either of you are moderator on technical board mailing list could you let my quarantined messages through ?
[17:39] <segv`> cjwatson: ah
[17:43] <didrocks> barry: hey, any idea what to do when we get an error in executing dh_python2: E: dh_python2:146: you most probably have to build extension for python2.7. (I've tried to tweak debian/pyversions or XS-Python-Version without any luck and don't have a lot of insight for dh_python)
[17:44] <kees> smoser: done
[17:45] <smoser> thanks.
[17:45] <kees> np :)
[17:45] <tumbleweed> didrocks: which package
[17:47] <didrocks> tumbleweed: compiz-config-python
[17:47] <didrocks> tumbleweed: was working well (0.9) on maverick, but since I try to build it on natty…
[17:56] <tumbleweed> didrocks: assuming you mean compizconfig-python, it builds fine for me (and uses dh_pysupport, not dh_python2)
[17:56] <didrocks> tumbleweed: yeah, you're not building 0.9 I guess
[17:57] <tumbleweed> presumably :)
[17:58] <didrocks> tumbleweed: the upstream build system totally changed. So I moved to dh_python2 and now, I have this build issue (which was working fine in maverick, just appeared in natty)
[17:59] <didrocks> so something changed as we have python2.7 in natty as well, but I don't know enough about dh_python2 and my search on the web was unsuccessful to know what's going on with this error
[17:59] <tumbleweed> yeah I see they are now using distutils
[17:59] <tumbleweed> my guess from th eerror is that you aren't building for python2.7, as it says
[17:59] <tumbleweed> can I see your rules?
[17:59] <didrocks> apart that I can skip it with --no-guessing-versions
[18:00] <didrocks> tumbleweed: sure, pushed at lp:~compiz/compizconfig-python/ubuntu
[18:02] <ScottK> didrocks: Are all the build-depends rebuilt for python2.7 already?
[18:02] <tumbleweed> didrocks: I'd drop the pyversions, you have a XS-PV as well. XB-PV can also be dropped.
[18:02] <ScottK> I keep running into that problem.
[18:02] <tumbleweed> didrocks: th eproblem is your override_dh_auto_install, you only install 2.6
[18:02] <tumbleweed> why do you need that override?
[18:03] <ScottK> And we actually prefer X-P-V to XS-P-V now.
[18:03] <tumbleweed> err it overrides build too
[18:03] <didrocks> tumbleweed: you're right, totally forgot about it :)
[18:03] <didrocks> tumbleweed: well, it's needed because dh_auto_install doesn't do the right thing
[18:04] <didrocks> tumbleweed: I guess it's confused as the soft as some c code as well
[18:04] <tumbleweed> didrocks: that's suprising, did they screw up thier setup.py that badly?
[18:04] <didrocks> tumbleweed: well, possibly, but apart from a complicate setup.py, it seems a "normal one"
[18:04] <didrocks> hence the fact I have to tweak it
[18:05] <didrocks> tumbleweed: about pyversion vs XS-PV and XB-PV, is there a doc for dh_python2?
[18:05] <didrocks> I stopped with pycentral :)
[18:05] <tumbleweed> it has a manpage
[18:05] <tumbleweed> (that's about it)
[18:06] <ScottK> didrocks: The current python-policy describes this too.
[18:06] <didrocks> yeah, that doesn't explain if we need to drop pyversion and XB-PV :)
[18:06] <tumbleweed> re XS-PV, XB-PV you'd have to look at debian-python list archives
[18:06] <didrocks> ScottK: oh really? I'll take a look :)
[18:06] <ScottK> tumbleweed: Also in Policy
[18:07] <didrocks> ok, works better once built for python 2.7 :)
[18:07] <tumbleweed> ScottK: the python-policy on www.d.o still says you should have XB-PV etc
[18:07] <didrocks> tumbleweed: ScottK: thanks!
[18:08] <didrocks> tumbleweed: I'll check with upstream and look at the code to see why dh_python2 is confused about the setup.py
[18:08] <ScottK> tumbleweed: Look in the latest package. Not sure how the one on www.d.o gets updated.
[18:08] <tumbleweed> ScottK: yeah now that you mentioned it, I seem to remember it being updated in the package
[18:08] <ScottK> didrocks: We need cases where dh_python2 has trouble to extend it, so please don't work around it.
[18:08] <ScottK> didrocks: barry will be glad to fix it for you.
[18:09] <didrocks> ScottK: yeah, I'll add to my "next week" TODO list
[18:09] <didrocks> just trying to get it updated for now, still not uploaded
[18:18] <tumbleweed> ScottK: cython hasn't been built for 2.7 yet, and debhelper was using th emakefile rather than setu.py. Memoed didrocks
[18:19] <ScottK> Thanks.
[18:33] <cHarNe2> hi, i have a kernel-bug to report, where can i do that? (my NIC wont work with 2.6.32-24-generic)
[18:33] <cHarNe2> second time i have this problem and last time it was a bug
[18:33] <jussi> !bug
[18:33] <cHarNe2> !bug
[18:35] <jussi> cHarNe2: me saying !bug, calls ubottu and she tells you what she just did
[18:37] <cHarNe2> jussi: yeah i realized that 2 secs after i typed it :) ty
[18:37] <jussi> yw
[19:15] <chilicuil> j ubuntu-es
[19:35] <jdstrand> ScottK: hey, so I see boost-mpi-source1.42 patiently waiting to be deNEWd. I read the 'Boost library proposal for Natty' and it seems that it is ok to deNEW (pending review), but I wanted to ask you to be sure
[19:35] <ScottK> jdstrand: Yes.  Please.  I didn't ping anyone since there's no rush, but that's one of the blocker for boost1.40 removal.
[19:36] <jdstrand> cool
[19:36] <jdstrand> I am looking at it now
[19:36] <ScottK> Great.
[19:40] <slangasek> is anyone here able to do SRU verification of bug #658728?  I don't have a Kubuntu install to hand
[19:48] <RoAkSoAx> slangasek: do you have a little bit of time to review a couple package's library splits? :)
[19:50] <slangasek> RoAkSoAx: hi there - maybe, what's up?
[19:51] <RoAkSoAx> slangasek: Remember the split for pacemaker we were talking about few weeks ago?? It has now been split in Debian but I did some improvements: https://launchpad.net/~andreserl/+archive/other/+files/pacemaker_1.0.9.1%2Bhg15626-2ubuntu1.dsc.
[19:52] <slangasek> ok
[19:52] <RoAkSoAx> the same with cluster-glue since our goal is to get the MIR's accepted :) https://launchpad.net/~andreserl/+archive/other/+files/cluster-glue_1.0.6%2Bhg2461-1ubuntu1.dsc
[19:52] <RoAkSoAx> and I'd like a rewview before uploading to universe
[19:52] <RoAkSoAx> slangasek: and thank you :)
[20:02] <ScottK> slangasek: I got a recruit for the bluedevil SRU.
[20:04] <slangasek> ScottK: yay, thanks
[20:04] <slangasek> ScottK: zyga tested and says the translations aren't fixed, but we may have overlooked something
[20:04] <ScottK> OK.
[20:11] <ScottK> slangasek: Confirmed not fixed (bluedevil).  shadeslayer is going to mark it in the bug.
[20:18] <shadeslayer> slangasek: if your free, can you move libutempter-dev to main in lucid? its in main in maverick
[20:26] <slangasek> shadeslayer: er, why would I do that?
[20:26] <slangasek> shadeslayer: we reconcile the archive sections of packages before we release, and don't change them afterwards
[20:26] <shadeslayer> oh.. so it cant be done?
[20:27] <slangasek> well, tell me what problem you're trying to solve :)
[20:28] <shadeslayer> slangasek: im trying to build kde4libs in lucid pbuilder and it complains that it wants libutempter-dev for building, so i can either drop that dep or get it moved to main, id like the latter :D
[20:30] <slangasek> shadeslayer: the kde4libs in lucid didn't build-depend on libutempter-dev
[20:30] <shadeslayer> slangasek: im building kde4libs 4.5.3 :)
[20:30] <shadeslayer> a new release
[20:30] <slangasek> shadeslayer: but that wouldn't be accepted into lucid, it wouldn't fit the SRU policy
[20:30] <slangasek> shadeslayer: so that's not a valid reason for us to move packages between archive sections in a released version of Ubuntu
[20:31] <shadeslayer> ah ok, just wanted to know if its possible :)
[20:31] <slangasek> not possible - sorry :)
[20:37] <slangasek> shadeslayer: btw, do you happen to have a pointer to the kdevelop git tree that needs to be used for SRU verification of bug #656195?
[20:38] <shadeslayer> looking
[20:39] <shadeslayer> slangasek: http://gitorious.org/kdevelop << thats their master
[20:39] <slangasek> shadeslayer: thanks!
[20:40] <slangasek> pitti: please see my follow-up comment on bug #649917; can we dig this SRU back out of the trash for acceptance? :)
[21:40] <james_w> lp:pkgme now has some code and is growing towards a PoC. https://launchpad.net/~pkgme-devs is available for those that want to join the mailing list to discuss it.
[22:15] <ebroder> cjwatson: ping on the grub2 fb stuff when you have a minute