[01:13] <cjwatson> right, I think that's enough cross-build hacking for tonight
[01:15] <cjwatson> (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] <micahg> cjwatson: if you
[02:07]  * micahg fishes for infinity
[02:27]  * ScottK starts reviewing the queue.
[02:32] <ScottK> OK.  Did the ones I think I understand.  Left a few for whoever's up next.
[06:48] <micahg> infinity: cjwatson: unping
[10:14] <Laney> 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] <tumbleweed> Laney: enjoy
[10:35] <Laney> tumbleweed: http://www.bbc.co.uk/weather/2649463 — hmm :P
[10:36] <stgraber> Laney: isn't that the usual UK weather? :)
[10:37] <tumbleweed> and I thought we'd been having cold weather
[10:38] <Laney> it is a sterotypical british seaside holiday
[10:42]  * Laney heads off
[10:42] <Laney> have a good week, and remember to NACK hard
[11:55] <ScottK> Reviewing qt4-x11.
[11:56] <ScottK> And pushing out unseeded stuff.
[12:07] <ScottK> Now nfs-utils.
[13:45]  * ScottK will review networkmanagement once it gets diffy.
[15:15] <jdstrand> 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] <skaet> thanks jdstrand.  :)
[15:16] <jdstrand> 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] <jdstrand> press
[15:16] <skaet> :)
[16:08]  * skaet ^ wondering who's just done the accepts...
[16:24] <skaet> jdstrand, new version of the spreadsheet has been uploaded,   should be showing up on reports this afternoon.
[16:24] <ScottK> skaet: Did you see the mails on the release team list about the pad?
[16:25]  * skaet looking
[16:25] <ScottK> skaet: I did the Universe ones.
[16:25] <ScottK> Since Unseeded Universe isn't frozen yet, I thought we didn't need to discuss them.
[16:26] <ScottK> The fact that they need approval at all is an artifact of LPs limitations and not policy.
[16:27] <skaet> thanks ScottK for handling.   agree in general,  just wasn't sure if banshee-community-extensions was seeded or not (cli-mono)
[16:27] <ScottK> cli-mono is an uploading packageset, not a seed for a flavor.
[16:28] <skaet> ok,  all good then.
[16:28] <skaet> re: pad
[16:28] <skaet> yes,  I encounter this as well.
[16:28] <skaet> seems to have been happening for at least a month,  I encounter it on the ubuntu-release pad as well.
[16:29] <ScottK> I think it makes the use we've planned for it quite problematic
[16:29] <ScottK> You can check the pad and still not know if you've really checked it or not.
[16:30] <jbicha> 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] <skaet> 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] <skaet> thanks jbicha,  that would explain it.   Do you know if there's an RT ticket about it?
[16:37] <jbicha> skaet: I haven't submitted an rt ticket and rt's not public
[17:02] <bjf> slangasek: when you pocket copied the kernel packages for me last week, everything seems to have gone to universe instead of main
[17:15] <jdstrand> skaet: thanks
[17:45] <skaet> ScottK,  timeout behaviour has been tweeked by the sysadmins,  let them know in #canonical-sysadmin if its still misbehaving for you.
[17:49] <ScottK> skaet: Thanks.
[17:54]  * ScottK looks at akonadi.
[17:55] <skaet> https://blueprints.launchpad.net/ubuntu/+spec/other-q-prior-release-feedback
[18:07]  * ScottK looks at calligra.
[18:10] <Riddell> jings ScottK, you're on the ball today :)
[18:10] <ScottK> :-)
[18:10] <ScottK> Waiting for the diff.
[18:14] <slangasek> 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] <slangasek> skaet: so if it's alright with you, I'll fix that and include both changes when reuploading
[18:15] <ScottK> +1
[18:28] <infinity> slangasek: Sounds reasonable to me.
[18:28]  * infinity goes back to pretending he's not here today.
[18:30] <slangasek> :)
[18:31] <infinity> 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] <skaet> slangasek,  sounds good to me as well.
[18:34]  * skaet thinks leftovers sound like a good idea....    lunch time.
[18:34] <slangasek> ok, update-notifier 0.119ubuntu4 uploaded
[18:35] <bjf> slangasek: did you see my earlier msg?
[18:35] <slangasek> bjf: don't think so; had a power outage here
[18:36] <bjf> slangasek: when you pocket copied the kernel packages for me last week, everything seems to have gone to universe instead of main
[18:36] <slangasek> oh, grr
[18:36] <slangasek> I rather expected the magic script in ubuntu-archive-tools to take care of that for me
[18:36] <slangasek> bjf: remind me which suite we were in? oneiric?
[18:37] <bjf> slangasek: yes, oneiric
[18:37] <slangasek> and it was linux, linux-meta, and linux-backport-which?
[18:37]  * ScottK looks at update-notifier.
[18:38] <bjf> slangasek: bug 974368 has complete list in comment #2
[18:38] <ubot2> Launchpad bug 974368 in linux "linux: 3.0.0-19.32 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/974368
[18:39] <slangasek> 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] <slangasek> bjf: promoted the three source packages to main with all binaries (after checking that they're all in main in oneiric-updates)
[18:41] <bjf> slangasek: thanks
[18:41] <ScottK> Much better.
[18:41] <cnd> skaet, following up from last week, I tracked down the crasher to xserver-xorg-input-synaptics bug 974017
[18:41] <ubot2> 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] <cnd> I've attached a patch that fixes the issue
[18:42] <cnd> I don't know what the process is for getting this handled right now
[18:42] <cnd> in the frozen archive, but not release frozen, state
[18:42] <cnd> do I just upload it and someone on the release team will review?
[18:42] <cjwatson> slangasek: magic script> it should be able to do so after I get queue override API exposed
[18:42] <ScottK> cnd: Yes.
[18:42] <infinity> cnd: 11 fingers?
[18:42] <cnd> ok
[18:43] <cnd> infinity, yes...
[18:43] <cjwatson> slangasek: but, no interface for it just now
[18:43] <slangasek> cjwatson: gotcha
[18:43] <cnd> infinity, I use my nose for testing :)
[18:43]  * infinity snorts.
[18:44] <slangasek> oh, I thought that was a contrived example when someone asked about it :)
[18:45] <slangasek> infinity: since you're declining to go away, do you want to review my eglibc merge proposal that I subscribed you to? ;)
[18:46] <cjwatson> cnd: there's a story about Mozart like that ...
[18:46] <cnd> slangasek, the use of a puppy paw was contrived, but the real issue wasn't :)
[18:46] <infinity> slangasek: Do you need it in today?  Cause I still have eglibc things to fix when I'm back to work anyway.
[18:46] <cnd> cjwatson, that he used his nose?
[18:46] <slangasek> infinity: no, I'm just trying to give you added incentive to make yourself scarce ;)
[18:46] <cjwatson> the story goes that Mozart and Handel challenged each other to write something that the other couldn't play
[18:47] <infinity> slangasek: Har.
[18:47] <infinity> slangasek: Running away, then.
[18:47] <cnd> cjwatson, hmm, interesting..
[18:47] <cjwatson> when Handel attempted Mozart's offering, he found that at one point it required 11 fingers
[18:47] <cjwatson> so declared it impossible
[18:48] <cjwatson> 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] <cnd> heh
[18:48] <cjwatson> I suspect the story is apocryphal :-)
[18:48] <cnd> that would be physically hard to do even by itself
[18:48] <cnd> the length of keys is only so long
[18:48] <cjwatson> it would indeed
[18:48] <cjwatson> pointy nose, maybe
[18:49] <cnd> or you'd have to turn your head sideways
[20:01] <micahg> will the final ISOs be affected by -security uploads?
[20:02] <hallyn> hi - just pushed a workaround for non-accelerated qemu.  not sure if i need to beg for that here?
[20:09] <cjwatson> micahg: by default, and unless we agree otherwise and go to some lengths to make sure of it, yes
[20:10] <micahg> 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] <jdstrand> micahg: in the past we have just queued them up in our various ppas for 0-day updates
[20:11] <jdstrand> micahg: (where it didn't make sense to push earlier)
[20:12] <micahg> 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] <slangasek> micahg: I think you may have misread - packages pushed to -security *will* be seen by the ISO building scripts
[20:13] <jdstrand> 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] <slangasek> so "doesn't matter and don't want to risk" != "push to -security"
[20:13] <micahg> slangasek: ah, yes, I did :)
[20:14] <micahg> that's too bad :(
[20:15] <jdstrand> micahg: is there a particular problem you are trying to solve are is this purely for understanding?
[20:15] <jdstrand> s/are/or/
[20:16] <cjwatson> 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] <cjwatson> I wouldn't want to try it
[20:16] <micahg> 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] <micahg> cjwatson: that's fine, therés a good chance it won't make a difference
[20:16] <micahg> err..rather, wouldn't be necessary in any event
[20:17] <jdstrand> micahg: you are saying you expect 1 or 2 firefox updates between now and precise release?
[20:17] <micahg> jdstrand: for Firefox, therés the planned release on Apr 24
[20:17]  * jdstrand didn't understand the chromium reference
[20:17] <micahg> jdstrand: probably 1 or 2 chromium updates after thursday
[20:18] <jdstrand> micahg: I guess there are isos with chromium on them you are worried about?
[20:18] <micahg> jdstrand: yes, mythbuntu and lubuntu :)
[20:18] <micahg> 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] <jdstrand> 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] <jdstrand> (thems the breaks)
[20:20] <jdstrand> 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] <jdstrand> and by 'do it', I mean do a pocket copy
[20:21] <micahg> jdstrand: ok, sounds good, after Final Freeze, I"ll do precise just like that stable releases for Chromium
[20:21] <micahg> well, save the final copy to -security :)
[20:21]  * jdstrand nods
[20:24] <cjwatson> staging in -proposed is fine, yes
[20:46] <hallyn> stgraber: an lxc including your fix has been pushed (waiting approval) to archive, fwiw
[20:48] <stgraber> hallyn: cool, thanks
[20:58] <hallyn> hm, does Unapproved mean rejected?
[20:59] <hallyn> stgraber: ^ then again maybe not
[21:02] <skaet> hallyn,   Unapproved means its been loaded to the unapproved queue.
[21:02] <skaet> you'll see Unapproved: accepted or Unapproved: rejected after its been reviewed.  :)
[21:03] <hallyn> skaet: ok, thanks.  it sounded scary :)
[21:03] <skaet> :)
[21:04] <ScottK> Looking at update-notifier
[21:05] <ScottK> 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] <slangasek> ScottK: yeah, it's to avoid needlessly calling it again in the trigger case
[21:06] <ScottK> OK.  Thanks.  Accepting.
[21:07] <slangasek> ScottK: thanks
[21:25] <ajmitch> 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] <ajmitch> debdiff of the change at http://paste.ubuntu.com/922496/
[21:28] <joshuahoover> can someone look at this sru for oneiric? bug #869920 ...it's fixed in p already
[21:28] <ubot2> 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] <micahg> 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] <joshuahoover> micahg: ah, ok, thanks :)
[21:55] <micahg> 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] <micahg> oh, and can someone review/release chromium please :)
[22:07] <infinity> micahg: Grr, thanks to the tarball-in-tarball packaging, that's completely unreviewable from the UI.
[22:07]  * infinity downloads...
[22:08] <micahg> infinity: yeah, I would love to get rid of that, but don't have the time right now, maybe for Q
[22:08] <Laney> ajmitch: yes we ask for it for that, but it should be easy to approve
[22:10] <infinity> ajmitch: Looks fine to me.
[22:10] <ajmitch> right, thought I'd clarify since "I suppose so" wasn't very definite :)
[22:11] <infinity> ajmitch: Don't need FFe bugs, per se, just approval.
[22:11] <ScottK> infinity: Thanks to being unseeded universe, it's  not frozen.
[22:11] <infinity> ScottK: Oh, there's also that.
[22:11] <ScottK> Makes it much easier.
[22:11] <ajmitch> infinity: righto, will sync then
[22:11] <infinity> (Looks fine regardless)
[22:11] <infinity> And it doesn't hurt to ask for reviews. :P
[22:12] <ScottK> Never hurts to ask.  Sometimes hurts to do them though.
[22:12] <infinity> Heh.
[22:12] <ScottK> Actually I was wrong.  It's in the Mythbuntu packageset anyway.
[22:13] <infinity> ajmitch: Just remind me what it was when you sync, so I can accept.  I have a short memory.
[22:13] <ScottK> Looking at network-manager-pptp.
[22:14] <ajmitch> infinity: libsamplerate has been synced, queuebot should pick it up soon
[22:14] <ajmitch> there we go
[22:17] <infinity> micahg: FWIW, your debian/rules is broken when run by hand.
[22:17] <micahg> infinity: awesome :)
[22:17] <infinity> 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] <infinity> 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] <infinity> micahg: Nothing is guaranteed when you run it by hand. :P
[22:18] <infinity> micahg: Note that I said "outside of dpkg-buildpackage"
[22:18] <infinity> Or, implied it.
[22:18] <ScottK> infinity: Except the interface with the package build systsem is debian/rules, so assuming dpgk-buildpackage is a bug.
[22:18] <infinity> ScottK: I agree.
[22:18] <infinity> I often use debian/rules clean/build/binary directly for testing purposes.
[22:19]  * ScottK too.
[22:19] <infinity> Though, I'm also in the "if it works on the buildds, it's only a minor bug".
[22:19] <infinity> camp...
[22:20] <micahg> infinity: I assume it works on teh buildds otherwise we'd never get a successful arm* build :)
[22:21] <infinity> Or amd64, in this case. :P
[22:22] <infinity> 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] <infinity> Behaviour shouldn't change because you use a different wrapper (or none at all).
[22:23] <micahg> infinity: ok, but FTR, I didn't write most of that file :)
[22:23] <infinity> Didn't imply that you did.
[22:24] <infinity> Merely that it's your problem now. ;)
[22:24] <infinity> I believe that's known as the "neener neener" principle.
[22:24] <micahg> 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] <micahg> *haven't
[22:25] <infinity> I'm sticking with my neener.
[22:25] <infinity> Holy crap, I just realized that compose+^+2 gives me ².
[22:25] <infinity> neener²!
[22:27] <infinity> I'm a bit embarrassed about that, given that I've been using VT terminals with compose keys since high school.
[22:27] <infinity> Though, that's probably a more recent extension.
[22:29] <ScottK> BTW, someone may want to look into another amd64 builder.  amd64 has fallen significantly behind i386 in the rebuild.
[22:29] <infinity> I can rebalance.
[22:29] <ScottK> Can you resurrect rothera?
[22:29] <infinity> rothera's dead for good.
[22:29] <ScottK> Oh.
[22:29] <infinity> They're replacing it rather than fixing it.
[22:30] <ScottK> That's dead all right.
[22:30] <infinity> Should see about bouncing nasl and shedir, though.
[22:30] <micahg> 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] <infinity> micahg: Meh, rebuild's only a couple more days anyway, I'll just snag a random machine.
[22:30] <infinity> Actually, they're not that far out of whack.
[22:31] <infinity> ARM's going to beat them both. :P
[22:31] <micahg> 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] <infinity> Or you could just give the lpia one to amd64. :P
[22:32] <infinity> That would make slightly more sense.
[22:32] <infinity> Oh.
[22:32] <infinity> But molybdenum's 32-bit.
[22:32] <infinity> Nevermind.
[22:32] <infinity> Derp.
[22:32] <infinity> I can give roseapple to adm64 now.
[22:34] <infinity> micahg: If I bounce molybdenum to i386, can you take responsibility for watching for security uploads needing it?
[22:35] <micahg> 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] <infinity> Ahh, I may as well just do that semi-permanently.
[22:35] <infinity> Until IS kills it.
[22:36] <micahg> right, we only need this for a few more days anyways :)
[22:37] <infinity> 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] <micahg> infinity: yes, exactly :)
[22:37] <infinity> There.  Done.
[22:39] <cjwatson> micahg: sure, if the DMB tells me that's OK
[22:39] <micahg> cjwatson: for the packageset?
[22:40] <micahg> 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] <micahg> infinity: so, getting back to my chromium upload :)
[23:01] <infinity> micahg: Yeah, I'm doing others while yours diffs. :P
[23:01] <infinity> -rw-rw-r-- 1 adconrad adconrad 643232 Apr  9 16:59 chrome.diff
[23:01] <infinity> ...
[23:01] <micahg> 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] <infinity>  121 files changed, 3828 insertions(+), 1654 deletions(-)
[23:02] <infinity> 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] <infinity> Naughty.
[23:06] <micahg> we push major versions and there isn't any hope of manually patching
[23:06] <ajmitch> you just hope that upstream knows what they're doing?
[23:06] <micahg> infinity: I will start looking more closely during Final freeze though :)
[23:07] <micahg> 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] <cjwatson> micahg: mm, ok, I can do an autogenerated packageset with no upload rights.  mail me a reminder?
[23:45] <micahg> cjwatson: sure, thanks
[23:46] <cjwatson> reminds me, I need to sort out the bug in distroseries initialisation miscreating packagesets before we open Q
[23:47] <cjwatson> and figure out if there's any damage from that left in the precise data