=== rickspencer3 is now known as rickspencer3_ === rickspencer3_ is now known as rickspencer3 [13:27] is there a reason why all the kernel images since precise's release are still on archive.ubuntu.com? [13:28] Why wouldn't they be? [13:29] hrm, I thought only the latest were on archive.ubuntu.com [13:30] and the rest were garbage collected at some point [13:30] Oh, I see what you mean. We don't do NBS removal post-release [13:30] 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] oh, ok, I thought kernels were special in that regard, but maybe I'm just misremembering from 5+ months ago [13:31] 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] 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] Launchpad bug 1020100 in linux "linux: 2.6.24-32.103 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1020100 [14:53] 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] skaet: can you approve this blueprint so that it shows on status.ubuntu.com ? thank you [15:08] hi, I'd appreciate if someone could help libzapojit through the new queue, it's a new dependency for gnome-documents [15:15] scott-work, blueprint link? [15:17] skaet: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio [15:17] i'm sorry, i fully intended to link that earlier [15:17] scott-work, no worries. doing. [15:17] jbicha, newed [15:18] jbicha, would it make sense to have new libs multiarched directly? this one is not [15:19] 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] jbicha, yw, ok [15:37] 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] 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] skaet: thank you [15:42] skaet: this one still looks unapproved: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio [15:43] 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] OK. [15:45] scott-work, the topic was approved, just the direction needed tweaking, so wouldn't have been a blocker, but... sorted now. ;) [15:45] next publishing run should show them. Check back in about an hour [15:59] 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] scott-work, no worries. :) [16:01] infinity, ping [16:03] herton: Yo. [16:04] 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] herton: (Thanks for fixing the bot for the rest, btw) [16:04] 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] 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] infinity, no problem. I think for now I can workaround this, and avoid it complaining about this updates-modules package [16:06] herton: Check. Thanks. [16:12] cjwatson: hey, I just noticed the queue command hit ubuntu-archive-tools. anything I should be concerned about when using? [16:17] jdstrand: http://irclogs.ubuntu.com/2012/07/06/%23ubuntu-release.html#t20:31 [16:17] 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] cjwatson: thanks [16:20] 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] It is at least useful for info, accept, reject [16:21] fetch hit a roadblock and will be a few days [16:23] cool-- I tried it with info and will be trying accept in a moment [16:23] I'm in the process of converting the scripts that we had based around queue [16:24] 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] (that is *horrible*) [16:24] 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] I was thinking of adding show-urls or something to make it easier to quickly inspect something on chinstrap or whatever [16:25] oh no need to be sorry. what I have works, it is just icky [16:25] cjwatson: thank you for all your work on this :) [16:25] No problem, ultimately it makes my own life easier [16:26] I have a feeling show-urls could be generally useful, but I can't quite put my finger on it [16:27] 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] 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] huge stuff, not always [16:46] oh, thanks, I'd been meaning to deal with ddtp-translations [16:46] that'll want to go to main sooner or later [16:47] (one of the custom uploads it builds was already in main de facto anyway) [17:16] cjwatson: multiple accepts are WAY easier with queue than with the +queue page. Thanks. [17:18] Oh good. [17:19] 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] I thought it might get easier to deploy ben if it were in backports. So... there it is [17:20] It would be nice to be able to accept usuing queue by version number. [17:20] 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] ScottK: that seems very prone to accidents unless there's a prompt for each source [17:21] queue accept will already just accept everything. [17:21] This won't make it worse. [17:22] That's arguably a bug, mind :-) [17:22] You can use substrings plus a version number [17:22] Something like: ./queue --queue=Unapproved --suite=precise-proposed --version=4;4.8.5-0ubuntu0.1" accept [17:23] Oh, I never added a version match option, true [17:23] Ah, because there was one in there with a weird syntax [17:23] queue -Q unapproved -s precise-proposed kde/4:4.8.5-0ubuntu0.1 [17:23] +accept [17:23] Might change that syntax, it's anomalous [17:23] Or, to not worry about package name at all, just "/1.2.3" [17:23] queue -s precise-proposed -Q unapproved info /3.12.2 [17:23] ^-- For a current example. [17:24] Something like that. [17:24] ScottK: That works right now was my point. [17:24] As you say though it's a bit anomalous. [17:24] It's certainly lacking in the intuitive department. [17:24] Might be better to put some kind of confirmation prompt in there in some cases. Not sure. [17:25] Though, it's faster to type foo/ver than -p foo -v ver. [17:25] 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] 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] ogra_: any idea what's going on with the index there: http://cdimage.ubuntu.com/edubuntu/dvd/20120709/ ? [18:19] ogra_: duplicate headers and wrong oversize check for arm images [18:21] 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] 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] stgraber: Similar issues for he duplicate headers, I'd guess. It's still thinking it's a "different" image type. [18:28] 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] ogra_ - were you able to find out where the arm java plans are written down, and who the lead is? [18:30] skaet, no we haven't synced up [18:30] 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] balloons, ack. [18:37] skaet: arm java plans, in which regard? [18:37] stgraber: s/which is/which isn't/, I assume. [18:38] infinity: nope :) [18:38] /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] infinity, pending action item from weekly release meeting. Not finding info from the blueprint scans, but may have missed something. [18:40] 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] 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] infinity: well, it boots fine ;) [19:03] * stgraber checks the beginning of that .img for weirdness [19:03] apt-cache policy libtiff5-dev [19:03] oops [19:05] 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] infinity: ^ so not specific to dvd images [19:41] stgraber: No, I assumed it wouldn't be, but still odd. [19:44] The kolab rejects were me. I discussed it with the uploader. === popey_ is now known as popey [22:25] Please keep an eye on lucid NEW; a few rounds will be required to get ben in.