[02:14] <psusi> cjwatson, debian is upstream for parted aren't they?  and they released 3.0 back in may.. haven't they fixed d-i to work with it yet?
[02:21] <cjwatson> no
[02:23] <cjwatson> there are Debian developers involved upstream, and I think Debian may provide some hosting; that does not make Debian the upstream
[02:23] <cjwatson> the person in Debian who currently has the baton for adjusting d-i to work with 3.0 is me
[02:23] <psusi> heh... yay ;)
[02:24] <cjwatson> and no, I haven't done it yet :-P
[02:25] <psusi> correct me if I'm wrong, but it sure looks like the fs code in parted could do with most filesystem types is detect that they are there... the handlers for ntfs for instance only register probe function... no resize, and parted itself says resize only works on ext2, so partman must already handle that some other way no?
[02:26] <cjwatson> partman has specific fallbacks for some cases, but I am telling you that it uses libparted resize code in some cases too
[02:26] <cjwatson> er, libparted fs code I mean
[02:27] <cjwatson> and in any case there are long-standing bugs about the lack of good progress bars in cases where partman doesn't use libparted
[02:27] <cjwatson> so this needs to be fixed *anyway*
[02:30] <cjwatson> bed > germinate hacking, I think
[03:52] <jtokarchuk> hello there. anyone around?
[04:20] <broder> oh, huh. the sponsorship queue doesn't show my backports bug that has sponsors subscribed
[04:20] <broder> i will optimistically assume that's the only reason my patch hasn't gotten sponsored yet and fix the queue
[04:21] <broder> ...oh, yeah, that would never pick up my backports bug
[05:52] <EvilResistance> any of the godly helpers around>?
[05:52] <EvilResistance> i.e. motus
[05:52] <EvilResistance> we're (that is to say, me and antother person) are trying to find why this dependency didnt get installed in the build process: https://launchpadlibrarian.net/86480906/buildlog.txt.gz
[05:52] <EvilResistance> pbuilder-satisfydepends-dummy: Depends: yaml-cpp-dev (>= 0.2.7) but it is not going to be installed.  <-- that specifically
[06:48] <Bachstelze> EvilResistance: this package doesn't seem to exist in the archive
[08:27] <broder> pushed out the new backports docs! kees https://help.ubuntu.com/community/UbuntuBackports and https://wiki.ubuntu.com/UbuntuBackports are all shiny, new, and may even be accurate for the next, i don't know, 5 minutes or so :)
[08:28] <broder> kees: uh, sorry about that. irc client got a bit tab-happy for some reason...
[08:51] <tumbleweed> there are two mono uploads with blank lines in the middle of the .changes file http://launchpadlibrarian.net/32316567/mono_2.4.2.3%2Bdfsg-2_source.changes http://launchpadlibrarian.net/38490961/mono_2.4.3%2Bdfsg-1_source.changes
[08:52]  * tumbleweed wonders how those were accepted
[08:53] <broder> ...why aren't they signed? is that auto-sync evil?
[08:53] <tumbleweed> lp strips the signature
[08:53] <broder> eww
[08:53] <tumbleweed> but yes, those look synced
[09:41] <Laney> weird, he admitted that it didn't show syncer and then still said I was wrong
[09:41] <Laney> AAs (used to?) have to hack mono's changesfiles to sync them
[09:42] <bkerensa> =o
[09:42] <Laney> because of a bug in dak which added blank lines
[09:53] <Quintasan> tumbleweed: If I am installing dev headers in another package then I am supposed to remove the soname form the -dev package name, right?
[10:39] <broder> bah. everybody pretend not to notice that i just misspelled "karmick" in my mass close comments!
[11:29] <nigelb> broder: Shame!
[12:17] <fabrice_sp> Hi. I wrongly run a sync for 2 packages on Oneiric (as seen in https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0). Who can I poke to delete them from new?
[12:20] <nigelb> fabrice_sp: Someone from https://launchpad.net/~ubuntu-archive would be your best bet.
[12:20] <fabrice_sp> (by the way, I discovered recently https://launchpad.net/ubuntu/precise/+missingpackages)
[12:20] <fabrice_sp> nigelb, thanks: I'll ask there
[12:21] <nigelb> fabrice_sp: You can also just mention this in #ubuntu-release, someone should notice it eventually.
[12:21] <nigelb> I don't think there'd be anyone around today, but someone should catch it in scrollback on Monday.
[12:22] <fabrice_sp> right: it will be rejected anyway, given that this are new packages :-)
[12:23] <nigelb> :)
[13:08] <tumbleweed> fabrice_sp: be aware that +missingpackages doesn't know about the sync blacklist
[15:01] <ockham_> hi, anyone feel like reviewing http://revu.ubuntuwire.com/p/unity-lens-bliss ?
[15:03] <tumbleweed> ockham_: I can review packaging, but not the unity lens itself (I know nothing about those)
[15:04] <tumbleweed> Laney: I couldn't help myself :/ lp:~stefanor/ubuntu-dev-tools/on-images-876554 lp:~stefanor/+junk/ubuntu-image-contents
[15:04] <ockham_> tumbleweed: fine for me!
[15:05] <tumbleweed> ockham_: whoah, does a simple python script really need autotools?
[15:08] <ockham_> tumbleweed: seems like that's how upstream's packaging unity stuff...
[15:20] <tumbleweed> ockham_: commented on REVU
[15:21] <ockham_> tumbleweed: thx, gonna check it out
[15:22] <ockham_> tumbleweed: about libexec: any clue where that comes from? pdebuild'ing it for precise yields a lib dir instead of libexec
[15:27] <tumbleweed> ah, that's possibly from me mucking around with the package. dh does try to avoid libexec (which is a GNUism)
[15:28] <ockham_> tumbleweed: it's not necessarily you -- if i pdebuild it for oneiric, i also get libexec...
[15:32] <tumbleweed> oh, duh, you are overriding dh_auto_configure
[15:32] <tumbleweed> you shouldn't need to
[16:01] <Laney> tumbleweed: addict
[16:03] <Ampelbein> tumbleweed: I updated the merge branch for ubuntu-dev-tools, it now uses the full bug title as filename and included a check for 450 response code at mail delivery.
[16:05] <tumbleweed> Laney: I know :/ I swear I had more useful and urgent things to do today
[16:05]  * Laney certainly does
[16:05] <Laney> home brewing and soup kitchening
[16:06] <tumbleweed> mmm, brewing
[16:06] <Laney> first attempt...
[16:07] <tumbleweed> Ampelbein: shouldn't you just catch all 400 series errors?
[16:07] <Ampelbein> tumbleweed: It doesn't make sense to give a retry option on 451/452 errors in my opinion.
[16:09] <Ampelbein> tumbleweed: Of course I can catch all those temporary errors, but like I said in my comment, the non-450 errors can't expected to be fixed in a reasonable timeframe and it's better to just error out and send manually at a later time. (Or with a real email client)
[16:10] <tumbleweed> probably reasonable
[16:13] <tumbleweed> Ampelbein: what's the point of the second loop?
[16:13] <tumbleweed> Ampelbein: it'll still try and send to the same recipients, right?
[16:14] <tumbleweed> Laney: what are you brewing?
[16:14] <Ampelbein> tumbleweed: The first catches errors while connecting (i.e. the HELO/EHLO phase), the second loop catches error while sending (MAIL FROM/RCPT TO/DATA)
[16:19] <Laney> tumbleweed: just a kit I found in the shop... Tom Caxton Real Ale - mixed reviews
[16:22] <tumbleweed> Ampelbein: ah, the exception only catches RecipientsRefused
[16:22] <tumbleweed> most of the time 450 means graylisted, and retrying won't work so well, but prints the error, so I guess that's ok
[16:23] <Ampelbein> tumbleweed: Yes, the intent is that the user sees "Greylisted, try again in 5 minutes" and can then hit enter and the mail is gone.
[16:24] <Ampelbein> Of course this only works if the timeout on the smtp server is higher than the greylist time. I should probably add a smtplib.SMTPServerDisconnected exception.
[16:25] <tumbleweed> i'd suggest being more aggressive with the title re.sub('[^a-zA-Z0-9_]', '') or something like that
[16:28] <tumbleweed> Laney: good luck with it. I keep intending to do one of those (but then there'll be pressure to go full-grain...)
[16:36] <Laney> that is the next step :-)
[20:21] <tumbleweed> broder: thanks for picking up that microcode.ctl bug. It was languishingin my should-look-at-again pile in the inbox
[20:22] <broder> not a problem. i was slightly worried that there was some other reason you upload it
[20:23] <tumbleweed> that package seems to break every other day
[20:23]  * broder sighs. why does everybody fix _FORTIFY_SOURCE FTBFS by turning off _FORTIFY_SOURCE?
[20:26] <tumbleweed> it's slightly better than fixing unused-result by storing it in a variable and not doing anything useful with it.
[20:26] <broder> debateable
[20:26] <tumbleweed> :)
[20:26] <broder> at least if you left FORTIFY_SOURCE turned on you'd get all of the buffer overflow protection
[20:31] <broder> ...actually, why does everybody do -U_FORTIFY_SOURCE instead of -Wno-error=unused-result
[22:39] <fmaker> I'm building a new package for revu which requires oneric, but I'm running natty.  Is there a way to create a minimal oneric test environment without create a full VM?
[22:40] <tumbleweed> use a pbuilder chroot (or any other chroot for that matter) ?
[22:50] <jtaylor> https://wiki.ubuntu.com/PbuilderHowto