[00:15] <infinity> cjwatson: Hrm?  Was this a PPA copy, or you mean my proposed->updates/quantal copies?
[00:15] <infinity> cjwatson: Oh, if it landed in NEW for quantal, yeah, I didn't accept that.
[00:26] <ScottK> ^^^ are security uploads done through -proposed so the -security can deliver a fix to people that don't use -updates.
[00:27] <infinity> ScottK: erm, what?
[00:27] <infinity> ScottK: That sentence didn't make a lot of sense. :)
[00:27] <ScottK> First, they aren't embargoed, so no rush.
[00:28] <ScottK> Since we have 4.x.2 in -release and - 4.x.4 in -updates it's a bit complicated.
[00:28] <infinity> ScottK: Oh, I see what you mean.  There will be a 4.x.2 upload in -security, and this one in updates?
[00:29] <ScottK> Yes.
[00:29] <infinity> Check.
[00:29] <infinity> That made more sense than the first sentence.
[00:29] <ScottK> Assuming mdeslaur doesn't decide to rebuild ~all of KDE in -security.
[00:29] <infinity> That sounds unpleasant.
[00:30] <infinity> And if it's easily backported, unnecessary.
[01:10] <infinity> ScottK / mdeslaur: ^--- proposed ones accepted, happy to push them to updates on a (reasonably) accelerated schedule to match the USN, whenever that happens.
[01:11] <mdeslaur> infinity, ScottK: ok, thanks, I'll build the old versions in the sec ppa tomorrow, and will let you know. Thanks.
[07:51]  * cjwatson aborts the freeze experiment
[07:56] <RAOF> infinity: This is a gentle ping re: the e2fsprogs SRU you promised to review.
[12:09] <popey> could someone please bump a build in a ppa for me? https://launchpad.net/~sil2100/+archive/ppa/+build/3665774  says it has 3 hours before build starts, and I need to get testing on that.
[12:25] <popey> nvm, all done
[13:01] <ScottK> bdmurray: How often is pending-sru.html updated?
[13:04] <ScottK> It looks like it hasn't updated in at least 8, possibly more, so I suspect that's not what's wanted.
[13:20] <stgraber> ScottK: cron is twice an hour IIRC
[13:20] <stgraber> infinity: ^
[13:20] <ScottK> OK.  Then something is 'not good' as I accepted natty/bluez 8 hours ago and it's still on the list.
[13:21] <stgraber> ScottK: infinity changed the cron to update from bzr before running, maybe something went wrong with that bit. AFAICT the script itself is fine (ran it yesterday locally)
[13:21] <ScottK> Right.
[13:22] <ScottK> Eventually he'll wake up.
[13:27] <cjwatson> Corrupt launchpadlib cache again.
[13:27] <cjwatson> Let me fix that for good, at least for sru-report.
[13:29] <ScottK> Thanks cjwatson.
[13:35] <cjwatson> Next run should fix it.  Other reports may break in the same way, though; the real fix is to backport the patch for bug 459418.
[13:35] <ubot2> Launchpad bug 459418 in lazr.restfulclient "Cache is not safe for concurrent use (by processes or threads)" [High,Fix committed] https://launchpad.net/bugs/459418
[13:40] <stgraber> cjwatson: how did you workaround it? set an alternate launchpadib_dir for that Launchpad instance?
[13:40] <cjwatson> More or less
[13:40] <cjwatson> Actually I subclassed Launchpad and fiddled with _get_paths, so that I didn't have to re-credential
[13:40] <cjwatson> Evil to counteract evil really
[13:41] <stgraber> :)
[13:41]  * cjwatson works on the duplicate archivepermission bug now
[13:41] <stgraber> thanks!
[13:42] <cjwatson> http://paste.ubuntu.com/1098315/ - if nothing else working on LP is teaching me weird bits of SQL
[13:43] <stgraber> looks like I'm not yet awake enough to parse that one properly ;)
[13:55] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/garbo-archivepermission-duplicates/+merge/115554 now
[14:03] <balloons> aloha
[14:12] <ScottK> cjwatson: Updating nicely now.  Thanks again.
[14:33] <stgraber> hmm, looks like queuebot is dead
[14:35]  * stgraber will add some serious logging to queuebot after the meeting, should help figure out where it's getting stuck
[15:33] <cjwatson> 16:24 <gnuoy> We need to move move PandaBox01 so that PandaBox02  can be powered up alongside it.
[15:33] <cjwatson> ^- FYI
[15:33] <cjwatson> 16:27 <gnuoy> so were going to loose builders: caph ain celbalrai meissa nihal scheat shedir altais chort heka nasl
[15:33] <cjwatson> 16:27 <gnuoy> Hopefully the work will be completed within an hour of starting
[15:34] <ogra_> celbalrai is indeed bad ...
[15:35]  * ogra_ crosses fingers for the time estimate
[15:37] <cjwatson> we'll be better off once it's back
[15:37] <cjwatson> I mean, since this involves getting the second set
[15:38] <ogra_> indeed
[15:41] <stgraber> the New binaries for openldap are a revert of a delta we were carrying with Debian, I'm not expecting something in main to depend on these, so sending the new binary to universe would be fine
[15:41] <stgraber> (it'll be needed for zentyal-samba4 which will be in universe)
[17:16] <jbicha> cjwatson: ooh, the --no-webcam ubiquity option looks nice
[17:16] <jbicha> I had trouble installing the daily image last week but it did work this Sunday :)
[17:21] <bdmurray> How should I handle the version of apport in the proposed queue for precise that doesn't really fix bug 1006633?
[17:21] <ubot2> Launchpad bug 1006633 in apport "should collect /etc/default/grub from package install failures due to update-grub failing" [High,In progress] https://launchpad.net/bugs/1006633
[17:22] <bdmurray> It doesn't do anything wrong rather it just doesn't do what was intended
[17:35] <infinity> bdmurray: If it doesn't fix the bug referenced in the changelog, reject it and reupload with the correct fix?
[17:36] <bdmurray> infinity: okay, sounds good
[18:39] <stgraber> queuebot update, be back in a sec
[19:14] <stgraber> infinity: do you have a minute to review edubuntu-netboot in New? ideally I'd like to do the seed change and ltsp upload in time for the next daily. It's a repackaged copy of what we had in the ltsp source, so shouldn't be too scary :)
[19:16] <infinity> stgraber: Is "not scary" a promise?
[19:17] <infinity> stgraber: Also, any reason for the brand-specific renaming, rather than going with something one could generically use in Debian as well?
[19:18] <stgraber> infinity: well, it kind of relies on having an Edubuntu media mounted in /cdrom
[19:19] <infinity> Sure, but does that media need to be "edubuntu", or just "some live media built kinda like that"?
[19:20] <infinity> As in, is it inconceivable that one might want to do the same or a similar thing with edudebian (or whatever) and reuse the same tool?
[19:20] <infinity> It would seem to me that ltsp-livecd was a lovely generic name.
[19:20] <stgraber> "not scary" as in a single python script with an icon, a glade file and a bunch of translations, that used to live in debian/scripts/ in the ltsp source (moving them off so we can reduce the delta with Debian for that package, well, eventually get in sync is the plan)
[19:21] <stgraber> it's not completely impossible to see Debian wanting some similar tool eventually, but I'd expect us to scrap it entirely and start from scratch if that was the case
[19:21] <stgraber> as Debian doesn't use nbd, making the whole LTSP setup quite different
[19:21] <infinity> Mmkay.  Still not sure the rename is worth the effort, since you need the transitional package anyway.
[19:22] <stgraber> the rename is mostly because that package will grow support for booting the live media over the network
[19:22] <infinity> (And I'd expect it to just be debian/ubuntu versions of the same concept under the same package name, if Debian did the same thing... In an ideal world)
[19:22] <stgraber> so it won't do only LTSP but do ltsp + casper-netboot
[19:23] <infinity> *shrug*
[19:23] <infinity> Alrighty.
[19:23] <infinity> I suppose if Debian does things differently and a different script is required, one ltsp-netboot source that produced edubuntu-netboot and edudebian-netboot would be slick. :P
[19:24] <highvoltage> infinity: I'd like something like that for debian, but it's far off for now. perhaps something we can discuss next year at debconf (and at least stgraber plans to be there as well)
[19:24] <infinity> I'll stop bikeshedding now.
[19:25] <stgraber> highvoltage: yeah, we'd need to talk with vagrant and figure out how to get something that works for Debian and Ubuntu, but that's going to be once we have LTSP in sync and I don't have to care about it ;)
[19:25] <highvoltage> *nod*
[19:26] <infinity> Well, at least having a branded package name isn't namespace pollution.  Easy to just drop our *buntu specific thingee on the floor later.
[19:27] <infinity> stgraber: Why only compat 7?
[19:28] <infinity> stgraber: Backporty concerns?
[19:29] <stgraber> infinity: sounds like copy/pasting from a package where compat was at 7, suppose I should set it to whatever debhelper is at nowadays (9?)
[19:30] <infinity> stgraber: 9, with a build-dep to match, would be sane.
[19:30] <infinity> stgraber: Okay, and now that I see that this ships a binary and desktop called "ltsp-live", the rename makes even less sense. :P
[19:30] <infinity> At least when the package name and the binary match, it's discoverable.
[19:32] <infinity> stgraber: Also, you could get around the .install file in debian/ and the icky dh_override in rules if you just provided a simple Makefile.
[19:34] <stgraber> infinity: ltsp-live => didn't want to rename without being able to properly test it, so kept the name, planning to rename when I add casper-netboot support in it. Makefile => was lazy so just copy/pasted what we had in the ltsp source, but yeah, now that it's no longer under debian/scripts, it'd make sense
[19:36] <infinity> stgraber: The rename solution is simple.  Instead of making ltsp-live an empty transitional package, make it provide ltsp-live* -> whatever-newname* symlinks, so things that still depend on the old package get the old interface.
[19:37] <infinity> (This may be way too much effort to put into a script that probably only has one major consumer)
[19:38] <stgraber> I was actually considering not even shipping the transitional package. The package has no rdepends and it's only part of a live seed so ubiquity should never have copied it to a target system
[19:39] <infinity> stgraber: Anyhow, all the above faffing aside, it's in good enough shape for me to accept, so I'll do so.  Fix things that annoy me (or you) whenever you feel the urge. :P
[19:40] <infinity> stgraber: Oh, wait, I do see one issue.
[19:40] <infinity> stgraber: If you keep the transitional package, "Provides: ltsp-livecd" is a bit weird.  And if you drop it entirely, it probably still is, if nothing depends on it.
[19:41] <infinity> stgraber: And the replaces should be versioned.  With a versioned breaks.  That should cover the bizarre corner case where someone had it installed locally.
[19:41] <infinity> Or, just a straight up conflict, since we want the old package to go away forever.
[19:45] <stgraber> infinity: ok, please reject, I'll push a new version in a minute
[19:46] <stgraber> (dropping ltsp-livecd entirely, adding Replaces/Breaks, bumping compat/dh, adding Makefile)
[19:48] <stgraber> infinity: one thing that's a bit weird with versioned Breaks/Replaces is that there's no good way to know what version to check against as I don't know what version of LTSP will actually drop it (as I need to merge a few new upstream releases from Debian)
[19:48] <infinity> stgraber: If you're dropping the transitional package, switch that Breaks to a hard Conflicts.
[19:48] <infinity> stgraber: And then you can avoid the breaks entirely.
[19:48] <infinity> stgraber: In fact, you can make it a magical P/C/R
[19:49] <stgraber> unversioned P/C/R sounds good
[19:49] <infinity> stgraber: (This is probably too much thought to put into a package no one will have installed, but whatever)
[19:50] <infinity> stgraber: Unversioned PCR is correct, if ltsp-livecd may live on for a while, and we never ever want the two co-installable.  Which seems to be the case.
[19:53] <stgraber> gah ... why doesn't dh pass DESTDIR to my Makefile...
[19:55] <stgraber> oh, I think I know why...
[19:55] <infinity> It does...
[19:56] <stgraber> yeah, it was my bad. My Makefile only had an install target, so dh_auto_build was killing it ;)
[19:58] <stgraber> binary package looks identical, uploaded.
[20:09] <infinity> stgraber: env?
[20:10] <infinity> stgraber: Is there something strangely broken about your setup that requires that?
[20:10] <infinity> stgraber: (Works fine here without...)
[20:13] <stgraber> doh, no, that was me trying to debug what was going on with my Makefile...
[20:13] <infinity> Hahaha.  Oh, that makes a bit more sense. ;)
[20:13] <infinity> What was broken, BTW?
[20:14] <stgraber> just my Makefile having a single "install:" target, so calling "make" would call the install target
[20:14] <infinity> Ahh.
[20:14] <stgraber> so both dh_auto_build and dh_auto_install were trying to call it, the former without DESTDIR (obviously...)
[20:14] <infinity> Indeed.
[20:15] <stgraber> pushing a new one without that env call (might as well)
[20:15] <infinity> Heh.
[20:21] <infinity> stgraber: Acceptiferated.  Seed mangle at will.
[20:22] <stgraber> infinity: thanks
[20:24] <stgraber> infinity: seed mangled, I'm assuming you'll do the bin Newing soon after it's built? (we still have 4 hours before the daily, so should be fine ;))
[20:28] <infinity> stgraber: Yeah.
[20:32] <infinity> stgraber: And even in time for the publisher run.
[20:33] <highvoltage> yay
[20:33] <stgraber> infinity: yay, thanks!
[20:33] <infinity> Now, do I fix libreoffice or wait for sweetshark to do it.
[20:34] <infinity> Eenie meenie...
[20:34] <highvoltage> Protip: when you start with eenie and there's just two options then the second one will be mo
[20:35]  * skaet goes to look at nusakan to turn on precise dailies for those images participating in 12.04.1
[20:35] <stgraber> well, he doesn't have upload rights, so you might as well, but then you're going to be TIL on libreoffice ;)
[20:35] <infinity> What happened to poor meenie and miney?
[20:35] <infinity> stgraber: *sudder*
[20:36] <infinity> stgraber: He hasn't even gone through the PPU business for libreoffice?
[20:36] <stgraber> infinity: he tried
[20:36] <infinity> stgraber: "tried"... That sounds promising.
[20:37] <infinity> Suddenly, I'm pretty glad I don't use office suites.
[20:42] <stgraber> infinity: http://irclogs.ubuntu.com/2012/03/26/%23ubuntu-meeting.html#t20:46 if you want to see the details. Basically we were concerned by the limited number of reviews and testimonials and by some recent breakage of libreoffice (when his teammates blindly sponsor and break the archive for days...)
[21:45] <stgraber> infinity: speaking of conflicts, break/replaces, ... I'm working on bug 1007314 and I came up with http://paste.ubuntu.com/1099095/ as a fix. Basically re-introducing the transitional package from oneiric and reverting the Conflicts to the Break/Replaces we used to have in Oneiric. Would appreciate a quick sanity check before I push to -proposed.
[21:45] <ubot2> Launchpad bug 1007314 in krb5 "trying to upgrade from 11.10 to 12.04: The package 'postgresql-contrib-8.2' is marked for removal but it's in the removal blacklist" [High,Triaged] https://launchpad.net/bugs/1007314
[21:49] <infinity> stgraber: The transitional package probably doesn't need all the wonky conflicts and breakiness.
[21:49] <infinity> stgraber: Also, the formatting of (<<1.2.3) makes me a sad panda.
[21:51] <stgraber> infinity: yeah, I preferred not to touch these and instead stick to what we had in Oneiric (so that diffing debian/control from oneiric to precise gives something reasonable). But I'm happy to change it if you think that's a problem.
[21:51] <infinity> stgraber: Oh, if it's a cargo-cult from an older version, that makes some sense, I suppose.
[21:52] <stgraber> I basically diffed debian/control from oneiric to precise and reverted the changes related to removing the transitional package
[21:53] <infinity> Let me do the same thing here and see how I feel about this, then.
[21:59] <infinity> stgraber: Kay, looks sane.  I was going to ask if libkadm55 needed a similar treatment, but it looks like it was only in hardy, so we're good.
[22:00] <stgraber> ok, uploading it then. thanks for the sanity check
[22:09] <infinity> stgraber: Re-confirmed the diff from the queue and accepted, so some poor schmuck doesn't have to review it all over again.
[22:13] <stgraber> hehe, yeah, it's the kind of diff that's not exactly trivial to review when you just get the .diff.gz ;) thanks
[22:15] <infinity> So, even after JUST REVIEWING IT, I about had a heart attack when I noticed non-kernel binary new in the proposed queue.
[22:18] <stgraber> ;)
[22:18] <stgraber> that's certainly not very common for non-kernel SRUs to introduce new binaries
[22:20] <infinity> stgraber: Not only uncommon, but generally indicates that You're Doin' It Wrong(tm).
[23:50] <stgraber> cjwatson: for some reason I wasn't using the ircid stuff properly earlier. Using "import random; team = [nick.encode('utf-8') for nick in [([ircid.nickname for ircid in person.irc_nicknames if "freenode" in ircid.network.lower()]+[person.name])[0] for person in lp.people['canonical-foundations'].participants if person.name != "michelle-canonical"]]; random.shuffle(team); print(", ".join(team))" works properly indeed
[23:51] <stgraber> (I know, 3 levels of list comprehension doesn't make it exactly readable, but it works ;))
[23:52] <stgraber> would be a bit shorter if Michelle wasn't part of the LP team and doko had his IRC nickname set on LP ;)