[01:13] right, I think that's enough cross-build hacking for tonight [01:15] (db4.8, insserv, dpkg, shadow, iproute, doxygen, and gperf are all cross-build fixes, mostly for problems on http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/status.html) [02:04] cjwatson: if you [02:07] * micahg fishes for infinity [02:27] * ScottK starts reviewing the queue. [02:32] OK. Did the ones I think I understand. Left a few for whoever's up next. [06:48] infinity: cjwatson: unping [10:14] FYI, it's very possible that I won't be online this week: going to a caravan which may not have mobile signal to sustain internet. [10:29] Laney: enjoy [10:35] tumbleweed: http://www.bbc.co.uk/weather/2649463 — hmm :P [10:36] Laney: isn't that the usual UK weather? :) [10:37] and I thought we'd been having cold weather [10:38] it is a sterotypical british seaside holiday [10:42] * Laney heads off [10:42] have a good week, and remember to NACK hard === ara_ is now known as ara [11:55] Reviewing qt4-x11. [11:56] And pushing out unseeded stuff. [12:07] Now nfs-utils. [13:45] * ScottK will review networkmanagement once it gets diffy. [15:15] skaet: hi! fyi, with all the MIRs going on, I took the liberty of adjusting the package mappings spreadsheet for of the 'unknown' ones in http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html [15:16] thanks jdstrand. :) [15:16] skaet: I didn't do all of them or anything, but thought I'd mention it so you could prease whatever buttons to apply the spreadsheet to that page [15:16] press [15:16] :) [16:08] * skaet ^ wondering who's just done the accepts... [16:24] jdstrand, new version of the spreadsheet has been uploaded, should be showing up on reports this afternoon. [16:24] skaet: Did you see the mails on the release team list about the pad? [16:25] * skaet looking [16:25] skaet: I did the Universe ones. [16:25] Since Unseeded Universe isn't frozen yet, I thought we didn't need to discuss them. [16:26] The fact that they need approval at all is an artifact of LPs limitations and not policy. [16:27] thanks ScottK for handling. agree in general, just wasn't sure if banshee-community-extensions was seeded or not (cli-mono) [16:27] cli-mono is an uploading packageset, not a seed for a flavor. [16:28] ok, all good then. [16:28] re: pad [16:28] yes, I encounter this as well. [16:28] seems to have been happening for at least a month, I encounter it on the ubuntu-release pad as well. [16:29] I think it makes the use we've planned for it quite problematic [16:29] You can check the pad and still not know if you've really checked it or not. [16:30] it's that Ubuntu SSO proxy they put in front of the pad, I think I've had the timeout problem for months [16:30] I guess I've gotten into the habbit of clicking refresh on it. Although I agree its not ideal (by a long shot) [16:31] thanks jbicha, that would explain it. Do you know if there's an RT ticket about it? [16:37] skaet: I haven't submitted an rt ticket and rt's not public [17:02] slangasek: when you pocket copied the kernel packages for me last week, everything seems to have gone to universe instead of main [17:15] skaet: thanks [17:45] ScottK, timeout behaviour has been tweeked by the sysadmins, let them know in #canonical-sysadmin if its still misbehaving for you. [17:49] skaet: Thanks. [17:54] * ScottK looks at akonadi. [17:55] https://blueprints.launchpad.net/ubuntu/+spec/other-q-prior-release-feedback [18:07] * ScottK looks at calligra. [18:10] jings ScottK, you're on the ball today :) [18:10] :-) [18:10] Waiting for the diff. [18:14] skaet: so I've rejected the update-notifier with the broken source package build; but I've also seen that update-notifier-common is one of the packages leaving stale conffiles around on upgrade from lucid, per https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/lastSuccessfulBuild/artifact/lts-ubuntu-amd64/obsolete_conffiles.lo [18:14] skaet: so if it's alright with you, I'll fix that and include both changes when reuploading [18:15] +1 [18:28] slangasek: Sounds reasonable to me. [18:28] * infinity goes back to pretending he's not here today. [18:30] :) [18:31] I have a sneaking suspicion, I'll be working non-stop from tomorrow until the end of the month, I figure I'll gorge myself on leftover ham and enjoy the holiday. :P [18:34] slangasek, sounds good to me as well. [18:34] * skaet thinks leftovers sound like a good idea.... lunch time. [18:34] ok, update-notifier 0.119ubuntu4 uploaded [18:35] slangasek: did you see my earlier msg? [18:35] bjf: don't think so; had a power outage here [18:36] slangasek: when you pocket copied the kernel packages for me last week, everything seems to have gone to universe instead of main [18:36] oh, grr [18:36] I rather expected the magic script in ubuntu-archive-tools to take care of that for me [18:36] bjf: remind me which suite we were in? oneiric? [18:37] slangasek: yes, oneiric [18:37] and it was linux, linux-meta, and linux-backport-which? [18:37] * ScottK looks at update-notifier. [18:38] slangasek: bug 974368 has complete list in comment #2 [18:38] Launchpad bug 974368 in linux "linux: 3.0.0-19.32 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/974368 [18:39] whoa, why is launchpad offering to let me download the full comment instead of letting me look at it in the browser? :P [18:41] bjf: promoted the three source packages to main with all binaries (after checking that they're all in main in oneiric-updates) [18:41] slangasek: thanks [18:41] Much better. [18:41] skaet, following up from last week, I tracked down the crasher to xserver-xorg-input-synaptics bug 974017 [18:41] Launchpad bug 974017 in xserver-xorg-input-synaptics "Crash when touching Apple trackpad with 11 fingers" [Medium,In progress] https://launchpad.net/bugs/974017 [18:41] I've attached a patch that fixes the issue [18:42] I don't know what the process is for getting this handled right now [18:42] in the frozen archive, but not release frozen, state [18:42] do I just upload it and someone on the release team will review? [18:42] slangasek: magic script> it should be able to do so after I get queue override API exposed [18:42] cnd: Yes. [18:42] cnd: 11 fingers? [18:42] ok [18:43] infinity, yes... [18:43] slangasek: but, no interface for it just now [18:43] cjwatson: gotcha [18:43] infinity, I use my nose for testing :) [18:43] * infinity snorts. [18:44] oh, I thought that was a contrived example when someone asked about it :) [18:45] infinity: since you're declining to go away, do you want to review my eglibc merge proposal that I subscribed you to? ;) [18:46] cnd: there's a story about Mozart like that ... [18:46] slangasek, the use of a puppy paw was contrived, but the real issue wasn't :) [18:46] slangasek: Do you need it in today? Cause I still have eglibc things to fix when I'm back to work anyway. [18:46] cjwatson, that he used his nose? [18:46] infinity: no, I'm just trying to give you added incentive to make yourself scarce ;) [18:46] the story goes that Mozart and Handel challenged each other to write something that the other couldn't play [18:47] slangasek: Har. [18:47] slangasek: Running away, then. [18:47] cjwatson, hmm, interesting.. [18:47] when Handel attempted Mozart's offering, he found that at one point it required 11 fingers [18:47] so declared it impossible [18:48] to prove him wrong, Mozart sat down to play, and when he got to the offending passage, he pecked the extra note with his nose [18:48] heh [18:48] I suspect the story is apocryphal :-) [18:48] that would be physically hard to do even by itself [18:48] the length of keys is only so long [18:48] it would indeed [18:48] pointy nose, maybe [18:49] or you'd have to turn your head sideways === bjf is now known as bjf[afk] === bjf[afk] is now known as bjf === doko_ is now known as doko [20:01] will the final ISOs be affected by -security uploads? [20:02] hi - just pushed a workaround for non-accelerated qemu. not sure if i need to beg for that here? [20:09] micahg: by default, and unless we agree otherwise and go to some lengths to make sure of it, yes [20:10] cjwatson: so, pushing security issues to -security before release is an option (where we don't care if it's on the ISO or not? [20:11] micahg: in the past we have just queued them up in our various ppas for 0-day updates [20:11] micahg: (where it didn't make sense to push earlier) [20:12] jdstrand: yes, I"m aware, but was wondering if we have the option to push out to -security during that last week for stuff that doesn't matter if it makes it on the ISO (and we don't want to risk breaking the ISOs) [20:13] micahg: I think you may have misread - packages pushed to -security *will* be seen by the ISO building scripts [20:13] micahg: we could if we knew there wouldn't be a respin, but we usually don't which is why we need to coordinate. bottom line, when generating isos they pull from -security [20:13] so "doesn't matter and don't want to risk" != "push to -security" [20:13] slangasek: ah, yes, I did :) [20:14] that's too bad :( [20:15] micahg: is there a particular problem you are trying to solve are is this purely for understanding? [20:15] s/are/or/ [20:16] the problem with hacking things to avoid building from -security is that there's a non-trivial risk of building images that never get security updates on installed systems as a result [20:16] I wouldn't want to try it [20:16] jdstrand: well, wéve got the Firefox release 2 days before precise release (no idea how bad the CVEs are), with the frequency of recent chromium releases, therés bound to be one or 2 after final freeze [20:16] cjwatson: that's fine, therés a good chance it won't make a difference [20:16] err..rather, wouldn't be necessary in any event [20:17] micahg: you are saying you expect 1 or 2 firefox updates between now and precise release? [20:17] jdstrand: for Firefox, therés the planned release on Apr 24 [20:17] * jdstrand didn't understand the chromium reference [20:17] jdstrand: probably 1 or 2 chromium updates after thursday [20:18] micahg: I guess there are isos with chromium on them you are worried about? [20:18] jdstrand: yes, mythbuntu and lubuntu :) [20:18] jdstrand: I"m more concerned with not updating the release than the ISOs, keeping the ISOs up to date for CVEs is a losing game [20:19] micahg: I see. well, for firefox it seems easy enough-- we publish firefox with a -2 for precise only on release day (people running precise just have to wait) [20:19] (thems the breaks) [20:20] micahg: for chromium-- it you could stage in proposed I guess and have the people responsible for testing comment on if they want it in a respin. if all do, then you can do it, if not, they wait for a 0 day [20:20] and by 'do it', I mean do a pocket copy [20:21] jdstrand: ok, sounds good, after Final Freeze, I"ll do precise just like that stable releases for Chromium [20:21] well, save the final copy to -security :) [20:21] * jdstrand nods [20:24] staging in -proposed is fine, yes [20:46] stgraber: an lxc including your fix has been pushed (waiting approval) to archive, fwiw [20:48] hallyn: cool, thanks [20:58] hm, does Unapproved mean rejected? [20:59] stgraber: ^ then again maybe not [21:02] hallyn, Unapproved means its been loaded to the unapproved queue. [21:02] you'll see Unapproved: accepted or Unapproved: rejected after its been reviewed. :) [21:03] skaet: ok, thanks. it sounded scary :) [21:03] :) [21:04] Looking at update-notifier [21:05] slangasek: In update-notifier, was moving the removal of /etc/update-motd.d/20-cpu-checker to later in the postinst intentional? It's not mentioned in debian/changelog. [21:06] ScottK: yeah, it's to avoid needlessly calling it again in the trigger case [21:06] OK. Thanks. Accepting. [21:07] ScottK: thanks [21:25] for libsamplerate, I'd like to sync it to fix #969957 which bit me on upgrade, however the changelog says it has hardening build flags, should this get an FFe? [21:25] debdiff of the change at http://paste.ubuntu.com/922496/ [21:28] can someone look at this sru for oneiric? bug #869920 ...it's fixed in p already [21:28] Launchpad bug 869920 in ubuntuone-client "Files in new UDFs are not uploaded due to filtering" [High,Confirmed] https://launchpad.net/bugs/869920 [21:33] joshuahoover: someone just needs to propose a merge into the oneiric-proposed branch and it'll go into the sponsorship queue or add a debdiff and subscribe ubuntu-sponsors [21:33] micahg: ah, ok, thanks :) [21:55] cjwatson: would it be worth making an autogenerated lubuntu packageset since it's an official flavor (and to make it easier to keep track of what failures/uploads affects what images) [21:58] oh, and can someone review/release chromium please :) [22:07] micahg: Grr, thanks to the tarball-in-tarball packaging, that's completely unreviewable from the UI. [22:07] * infinity downloads... [22:08] infinity: yeah, I would love to get rid of that, but don't have the time right now, maybe for Q [22:08] ajmitch: yes we ask for it for that, but it should be easy to approve [22:10] ajmitch: Looks fine to me. [22:10] right, thought I'd clarify since "I suppose so" wasn't very definite :) [22:11] ajmitch: Don't need FFe bugs, per se, just approval. [22:11] infinity: Thanks to being unseeded universe, it's not frozen. [22:11] ScottK: Oh, there's also that. [22:11] Makes it much easier. [22:11] infinity: righto, will sync then [22:11] (Looks fine regardless) [22:11] And it doesn't hurt to ask for reviews. :P [22:12] Never hurts to ask. Sometimes hurts to do them though. [22:12] Heh. [22:12] Actually I was wrong. It's in the Mythbuntu packageset anyway. [22:13] ajmitch: Just remind me what it was when you sync, so I can accept. I have a short memory. [22:13] Looking at network-manager-pptp. [22:14] infinity: libsamplerate has been synced, queuebot should pick it up soon [22:14] there we go [22:17] micahg: FWIW, your debian/rules is broken when run by hand. [22:17] infinity: awesome :) [22:17] micahg: (It uses DEB_BUILD_ARCH, but never sets it, which I assume works under dpkg-buildpackage) [22:17] * micahg thought that was one of the guaranteed var [22:17] Anyhow, only throws warnings in the case I cared about (debian/rules patch), but it was entertaining to see it claim my arch was unsupported. [22:17] micahg: Nothing is guaranteed when you run it by hand. :P [22:18] micahg: Note that I said "outside of dpkg-buildpackage" [22:18] Or, implied it. [22:18] infinity: Except the interface with the package build systsem is debian/rules, so assuming dpgk-buildpackage is a bug. [22:18] ScottK: I agree. [22:18] I often use debian/rules clean/build/binary directly for testing purposes. [22:19] * ScottK too. [22:19] Though, I'm also in the "if it works on the buildds, it's only a minor bug". [22:19] camp... [22:20] infinity: I assume it works on teh buildds otherwise we'd never get a successful arm* build :) [22:21] Or amd64, in this case. :P [22:22] But yes, debian/rules being canonical is one of the reasons for backing out dpkg-buildpackage setting CFLAGS and moving to dpkg-buildflags, for instance. [22:22] Behaviour shouldn't change because you use a different wrapper (or none at all). [22:23] infinity: ok, but FTR, I didn't write most of that file :) [22:23] Didn't imply that you did. [22:24] Merely that it's your problem now. ;) [22:24] I believe that's known as the "neener neener" principle. [22:24] really, it's not my problem, but I have quite got the person's who's problem it is to accept responsibility yet :) [22:24] *haven't [22:25] I'm sticking with my neener. [22:25] Holy crap, I just realized that compose+^+2 gives me ². [22:25] neener²! [22:27] I'm a bit embarrassed about that, given that I've been using VT terminals with compose keys since high school. [22:27] Though, that's probably a more recent extension. [22:29] BTW, someone may want to look into another amd64 builder. amd64 has fallen significantly behind i386 in the rebuild. [22:29] I can rebalance. [22:29] Can you resurrect rothera? [22:29] rothera's dead for good. [22:29] Oh. [22:29] They're replacing it rather than fixing it. [22:30] That's dead all right. [22:30] Should see about bouncing nasl and shedir, though. [22:30] infinity: let me see if we can steal back the lpia builder again, it was supposed to go back for the weekend, but that never happened [22:30] micahg: Meh, rebuild's only a couple more days anyway, I'll just snag a random machine. [22:30] Actually, they're not that far out of whack. [22:31] ARM's going to beat them both. :P [22:31] infinity: yeah, but I figure with the lpia builder, i386 will finish 2 days ahead, then you can throw roseapple at the amd64 builds [22:32] Or you could just give the lpia one to amd64. :P [22:32] That would make slightly more sense. [22:32] Oh. [22:32] But molybdenum's 32-bit. [22:32] Nevermind. [22:32] Derp. [22:32] I can give roseapple to adm64 now. [22:34] micahg: If I bounce molybdenum to i386, can you take responsibility for watching for security uploads needing it? [22:35] infinity: yeah, can you flip rothera to lpia, that should take care of that issue (at least where I can see if therés something needed) [22:35] Ahh, I may as well just do that semi-permanently. [22:35] Until IS kills it. [22:36] right, we only need this for a few more days anyways :) [22:37] Sure, but I mean we can just keep rothera there as a placeholder, and bounce $some_other_machine when security builds are needed. :P [22:37] infinity: yes, exactly :) [22:37] There. Done. [22:39] micahg: sure, if the DMB tells me that's OK [22:39] cjwatson: for the packageset? [22:40] cjwatson: it doesn't have to grant upload rights at present [22:40] * micahg forgets if that toggle was ever implemented or not [22:58] * infinity still loves the 11-finger touchpad bug. [23:01] infinity: so, getting back to my chromium upload :) [23:01] micahg: Yeah, I'm doing others while yours diffs. :P [23:01] -rw-rw-r-- 1 adconrad adconrad 643232 Apr 9 16:59 chrome.diff [23:01] ... [23:01] infinity: what needs to happen also is I need to take an axe to that .orig tarball [23:02] * infinity sighs and has a glance. [23:02] 121 files changed, 3828 insertions(+), 1654 deletions(-) [23:02] This seems like one of those plug my nose and pray reviews. [23:02] * micahg kinds gave up on reviewing the upstream changes [23:04] Naughty. [23:06] we push major versions and there isn't any hope of manually patching [23:06] you just hope that upstream knows what they're doing? [23:06] infinity: I will start looking more closely during Final freeze though :) [23:07] ajmitch: well, that's almost irrelevant, we have a small test suite we run the SRUs through before theýre released to the wild [23:45] micahg: mm, ok, I can do an autogenerated packageset with no upload rights. mail me a reminder? [23:45] cjwatson: sure, thanks [23:46] reminds me, I need to sort out the bug in distroseries initialisation miscreating packagesets before we open Q [23:47] and figure out if there's any damage from that left in the precise data