[13:27] <micahg> is there a reason why all the kernel images since precise's release are still on archive.ubuntu.com?
[13:28] <cjwatson> Why wouldn't they be?
[13:29] <micahg> hrm, I thought only the latest were on archive.ubuntu.com
[13:30] <micahg> and the rest were garbage collected at some point
[13:30] <cjwatson> Oh, I see what you mean.  We don't do NBS removal post-release
[13:30] <cjwatson> Partly because we've never got round to it, but also more importantly because it causes trouble for people who download updated installer images from -updates at some point and then never update them
[13:30] <micahg> oh, ok, I thought kernels were special in that regard, but maybe I'm just misremembering from 5+ months ago
[13:31] <cjwatson> It's easier to just keep the lot
[13:31]  * micahg is used to seeing the kernels not in the archive as a sign of removing them from his system
[14:52] <herton> infinity, I fixed the bot regarding the wrong components it reported in bug 1020100. It now only complains about this: updates-modules-2.6.24-32-lpia-di 2.6.24-32.44 - is in main instead of universe
[14:52] <ubot2> Launchpad bug 1020100 in linux "linux: 2.6.24-32.103 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1020100
[14:53] <herton> infinity, it looks the complaint is correct, since updates-modules-2.6.24-32-lpia-di was in universe in the release pocket
[15:00] <scott-work> skaet: can you approve this blueprint so that it shows on status.ubuntu.com ?  thank you
[15:08] <jbicha> hi, I'd appreciate if someone could help libzapojit through the new queue, it's a new dependency for gnome-documents
[15:15] <skaet> scott-work, blueprint link?
[15:17] <scott-work> skaet: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio
[15:17] <scott-work> i'm sorry, i fully intended to link that earlier
[15:17] <skaet> scott-work,  no worries.   doing.
[15:17] <seb128> jbicha, newed
[15:18] <seb128> jbicha, would it make sense to have new libs multiarched directly? this one is not
[15:19] <jbicha> seb128: thanks, I think something didn't work when I tried multiarching it, I'll give it another look the next time I upload it though
[15:20] <seb128> jbicha, yw, ok
[15:37] <skaet> scott-work,   ok,  have taken a pass and approved them.  Also set the default milestone to my best guess, and all blueprints without a priority were set to medium.   Adjust as appropriate.  ;)
[15:37] <ScottK> skaet: Would it be possible to have the SRU meeting earlier?  That's past EOD for me and I'll be playing father then (two hours would do).
[15:42] <scott-work> skaet: thank you
[15:42] <scott-work> skaet: this one still looks unapproved: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio
[15:43] <skaet> ScottK,  challenge is getting it not too early for Australia...    I'm probably going to set up a second one earlier in the day,  since there are a couple in Europe who can't attend that time as well.
[15:43] <ScottK> OK.
[15:45] <skaet> scott-work,  the topic was approved,  just the direction needed tweaking, so  wouldn't have been a blocker, but... sorted now.  ;)
[15:45] <skaet> next publishing run should show them.     Check back in about an hour
[15:59] <scott-work> sorry, skaet, wasn't meaning to be pedantic, i just wanted to make sure this shows up on status.ubuntu.com under 'flavour' (which it currently does not). thank you :)
[16:00] <skaet> scott-work,  no worries.   :)
[16:01] <herton> infinity, ping
[16:03] <infinity> herton: Yo.
[16:04] <infinity> herton: I'd argue that that one updates-modules override was wrong in the release pocket, since it was for a kernel in main.  I don't much care that it was originally wrong. ;)
[16:04] <infinity> herton: (Thanks for fixing the bot for the rest, btw)
[16:04] <herton> infinity, about that hardy issue, updates-modules-2.6.24-32-lpia-di in main, pitti once told me that you don't change it, but yes, I can override this in the checker
[16:05] <infinity> herton: Well we don't/won't change the release pocket's overrides, but there's no reason to not make the post-release pockets correct.
[16:05] <herton> infinity, no problem. I think for now I can workaround this, and avoid it complaining about this updates-modules package
[16:06] <infinity> herton: Check.  Thanks.
[16:12] <jdstrand> cjwatson: hey, I just noticed the queue command hit ubuntu-archive-tools. anything I should be concerned about when using?
[16:17] <cjwatson> jdstrand: http://irclogs.ubuntu.com/2012/07/06/%23ubuntu-release.html#t20:31
[16:17] <cjwatson> override support is still in the LP deployment queue, but http://lpqateam.canonical.com/qa-reports/deployment-stable.html looks much healthier now so that should happen tomorrow I think
[16:20] <jdstrand> cjwatson: thanks
[16:20] <cjwatson> jdstrand: So I guess the short answer is you may find that some bits don't work yet, but the things that do work should be safe to use
[16:20] <cjwatson> It is at least useful for info, accept, reject
[16:21] <cjwatson> fetch hit a roadblock and will be a few days
[16:23] <jdstrand> cool-- I tried it with info and will be trying accept in a moment
[16:23] <cjwatson> I'm in the process of converting the scripts that we had based around queue
[16:24] <jdstrand> I'm particularly looking forward to override and fetch. the former, just cause you know, its handy and the latter cause I have some scripts I can update to not have to ssh to fetch on cocplum and the scp home :)
[16:24] <jdstrand> (that is *horrible*)
[16:24] <cjwatson> Yeah, sorry for the delay on those, fetch turned out to require learning about more of the LP security infrastructure than I cared to
[16:25] <cjwatson> I was thinking of adding show-urls or something to make it easier to quickly inspect something on chinstrap or whatever
[16:25] <jdstrand> oh no need to be sorry. what I have works, it is just icky
[16:25] <jdstrand> cjwatson: thank you for all your work on this :)
[16:25] <cjwatson> No problem, ultimately it makes my own life easier
[16:26] <jdstrand> I have a feeling show-urls could be generally useful, but I can't quite put my finger on it
[16:27] <cjwatson> Certainly I don't always want to fetch stuff over my home internet connection, but I expect most of us have better-connected systems we can ssh to
[16:28] <jdstrand> personally, while I'd prefer not to pull it over my home connection, I do most of the time since I have tooling and a build vm, etc for doing various review tasks
[16:28] <jdstrand> huge stuff, not always
[16:46] <cjwatson> oh, thanks, I'd been meaning to deal with ddtp-translations
[16:46] <cjwatson> that'll want to go to main sooner or later
[16:47] <cjwatson> (one of the custom uploads it builds was already in main de facto anyway)
[17:16] <ScottK> cjwatson: multiple accepts are WAY easier with queue than with the +queue page.  Thanks.
[17:18] <cjwatson> Oh good.
[17:19] <cjwatson> I was contemplating moving bug closures out to an asynchronous job to improve the timeout situation further.  But (a) I haven't yet learned how to write async jobs so that might take a while and (b) it's possible that cure might be worse than the disease.
[17:19] <Laney> I thought it might get easier to deploy ben if it were in backports. So... there it is
[17:20] <ScottK> It would be nice to be able to accept usuing queue by version number.
[17:20] <ScottK> If I'm doing a (for example) mass accept of a KDE point release, they'll all have the same version number, but there's no common naming scheme.
[17:21] <micahg> ScottK: that seems very prone to accidents unless there's a prompt for each source
[17:21] <ScottK> queue accept will already just accept everything.
[17:21] <ScottK> This won't make it worse.
[17:22] <cjwatson> That's arguably a bug, mind :-)
[17:22] <cjwatson> You can use substrings plus a version number
[17:22] <ScottK> Something like: ./queue --queue=Unapproved --suite=precise-proposed --version=4;4.8.5-0ubuntu0.1" accept
[17:23] <cjwatson> Oh, I never added a version match option, true
[17:23] <cjwatson> Ah, because there was one in there with a weird syntax
[17:23] <cjwatson> queue -Q unapproved -s precise-proposed kde/4:4.8.5-0ubuntu0.1
[17:23] <cjwatson> +accept
[17:23] <cjwatson> Might change that syntax, it's anomalous
[17:23] <infinity> Or, to not worry about package name at all, just "/1.2.3"
[17:23] <infinity> queue -s precise-proposed -Q unapproved info /3.12.2
[17:23] <infinity> ^-- For a current example.
[17:24] <ScottK> Something like that.
[17:24] <infinity> ScottK: That works right now was my point.
[17:24] <ScottK> As you say though it's a bit anomalous.
[17:24] <infinity> It's certainly lacking in the intuitive department.
[17:24] <cjwatson> Might be better to put some kind of confirmation prompt in there in some cases.  Not sure.
[17:25] <infinity> Though, it's faster to type foo/ver than -p foo -v ver.
[17:25] <cjwatson> For the first pass I was just trying to emulate the LP script as closely as possible to make sure I'd got it all right.  But its syntax was pretty awful.
[17:32] <ScottK> Whatever you end up with, please make it painfully clear in the -h how it works for occasional users.
[17:53]  * jdstrand is done fiddling with NEW for the day
[18:19] <stgraber> ogra_: any idea what's going on with the index there: http://cdimage.ubuntu.com/edubuntu/dvd/20120709/ ?
[18:19] <stgraber> ogra_: duplicate headers and wrong oversize check for arm images
[18:21] <stgraber> 2.2G definitely fits on a single-sided single-layer dvd ;) not that the .img will ever be burnt to a dvd though...
[18:22] <infinity> stgraber: I assume the oversized warning is because it's not a "DVD" image, but a "USB" image. Might need some special-casing in there.
[18:22] <infinity> stgraber: Similar issues for he duplicate headers, I'd guess.  It's still thinking it's a "different" image type.
[18:28] <skaet> balloons,  did you and seb128 figure out a plan for getting the accessibility community to help test the new GTK changes?  or is that still pending?
[18:29]  * skaet going through the pending milestones from last week's meeting ... 
[18:30] <skaet> ogra_ - were you able to find out where the arm java plans are written down, and who the lead is?
[18:30] <balloons> skaet, no we haven't synced up
[18:30] <stgraber> infinity: hmm, indeed, looks like we override SIZELIMIT to "1024 * 1024 * 1024" if file -b on the .raw returns "x86 boot sector", which is the case for the arm images
[18:31] <skaet> balloons,  ack.
[18:37] <infinity> skaet: arm java plans, in which regard?
[18:37] <infinity> stgraber: s/which is/which isn't/, I assume.
[18:38] <stgraber> infinity: nope :)
[18:38] <stgraber> /home/stgraber/Desktop/quantal-dvd-armhf+omap4.img: x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 32, 147424 sectors; partition 2: ID=0x83, starthead 0, startsector 147456, 4494080 sectors, code offset 0x0
[18:39] <skaet> infinity,  pending action item from weekly release meeting.    Not finding info from the blueprint scans, but may have missed something.
[18:40] <stgraber> infinity: added an exception for Edubuntu (after the bit of code doing the magic for .raw images) so that SIZELIMIT is set to 4.7GB in all cases. Hopefully I wasn't confused with edubuntu vs edubuntu-dvd this time and it'll just work :)
[18:42]  * stgraber will need to cleanup the edubuntu-dvd vs edubuntu mess at some point, using one for the livefs and the other for debian-cd just makes things confusing...
[18:57] <infinity> stgraber: There's something horribly weird going on if the arm "dvd" image has an x86 boot sector.  Or if it's being detected as such.
[19:02] <stgraber> infinity: well, it boots fine ;)
[19:03]  * stgraber checks the beginning of that .img for weirdness
[19:03] <Laney> apt-cache policy libtiff5-dev
[19:03] <Laney> oops
[19:05] <stgraber> quantal-desktop-armhf+omap4.img: x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 32, 147424 sectors; partition 2: ID=0x83, starthead 0, startsector 147456, 1136000 sectors, code offset 0x0
[19:05] <stgraber> infinity: ^ so not specific to dvd images
[19:41] <infinity> stgraber: No, I assumed it wouldn't be, but still odd.
[19:44] <ScottK> The kolab rejects were me.  I discussed it with the uploader.
[22:25] <Laney> Please keep an eye on lucid NEW; a few rounds will be required to get ben in.