[02:09] <babyface> jamespage, hi James,   precise-server-ec2-daily  test are unstable, and some test case failed.    http://10.98.0.1:8080/view/Precise/view/ISO%20Testing/job/precise-server-ec2-daily/ARCH=i386,REGION=us-west-2,STORAGE=instance-store,TEST=proposed,label=ubuntu-server-ec2-testing/170/
[05:36] <ScottK> Anyone using copy-package for PPA to PPA copies that had yesterday's update should update again.
[06:03] <ScottK> cjwatson: copy-package update done.  Found a bug in my work from yesterday that would have resulted in accidental copies to the main archive which I've fixed.  Also added the target archive to the confirmation dialogue so that kind of thing is visible in the future.
[06:03] <ScottK> (plus did the changes we discussed)
[08:11] <cjwatson> ScottK: brilliant, thanks
[08:34] <jamespage> babyface, transient issue - don't worry about it :-)
[08:36] <babyface> jamespage, ack. actually, I'm not watching and triaging the result of the ec2 jobs,  but I think it's good to let you know the status of it, due to maybe you don't watch the job everyday.  ;)
[08:37] <jamespage> babyface, utlemming keeps a closer eye on them
[08:37] <jamespage> babyface, we are going to shift that testing to be part of the image publication process - so Image's won't be made public unless they pass
[08:37] <babyface> jamespage, cool
[08:52] <ev> seb128, slangasek: my intention is not to remove the 3 crash limit as an SRU. It would be a quantal or later thing. I raised removing it only because we were talking about the existence of the limit.
[08:52] <seb128> ev, hey, just replied to your email with my issues
[08:53] <ev> seb128: heh, just replied on #ubuntu-devel
[08:53] <seb128> ev, sorry I though we were on -devel :p
[14:17] <smartboyhw> Hi!
[14:48] <skaet> slangasek,   stgraber -  can manual builds be done today to test out the update fixes rather than waiting for the daily build tonight?
[14:49] <skaet> is it just a matter of waiting a day?  (thought the fix sounded close, based on the meeting)
[14:51] <slangasek> stgraber: before the -7 days> my biggest concern there is whether there will be further SRUs accepted that need to be on the CDs to be fully validated
[14:54] <slangasek> skaet: we can certainly fire them off manually
[14:55] <stgraber> slangasek: I'm not aware of any installer fixes that would still need to land, though we might have some more upgrade related fixes
[14:55] <stgraber> slangasek: can you look at openoffice.org in New?
[15:02] <slangasek> stgraber: accepted
[15:02] <stgraber> jibel: confirmed that it's still blocking on launchpad-intergation, probably because it's missing one package on the alternate media to get the upgrade path
[15:03] <stgraber> I'm going to try and figure out which one as having them all definitely solved the upgrade yesterday
[15:08] <slangasek> jibel: I said to stgraber that these added Breaks: on library packages in SRU needed a regression test of a full jenkins upgrade auto-test for o->p and l->p; does that happen automatically right now using the packages in -proposed, or if not, could you get us one manually?
[15:10] <jibel> slangasek, auto-upgrade tests are currently setup to upgrade with -proposed enabled.
[15:32] <slangasek> jibel: ok cool, thanks
[15:35] <stgraber> slangasek: easiest way out of the remaining launchpad-intergation mess seems to be to seed liblaunchpad-integration1.0-cil and liblaunchpad-integration1. Both are in main, total disk usage would be 26K
[15:42] <slangasek> stgraber: ah, you had added liblaunchpad-integration1.0-cil to your local repo for testing?  Sure, that seems reasonable
[15:42] <stgraber> slangasek, jibel: I have the list of all missing packages on alternate now, most of them are pretty small. I'll now update the seed and respin to confirm that actually works
[15:43] <stgraber> slangasek: yeah, I had all the binary packages for the sources I was messing with, that was obviously a mistake as that's now causing some more failues that I should have seen yesterday...
[15:48] <stgraber> slangasek: hmm, that's interesting. Apparently with my current list of extra packages (libgnome2-0, liblaunchpad-integration1.0-cil and libnspr4-0d) I don't need the new openoffice.org-core
[15:49] <stgraber> will spin a media with just these added, then run the upgrade and see what happens to openoffice/libreoffice, we might still need it to get something kind of reasonable post-upgrade
[16:04] <stgraber> slangasek: hmm, looks like we'll need something more clever... adding the -cil package made germinate bring half of mono with it
[16:04] <stgraber> making the media oversized
[16:04]  * stgraber checks that it at least works
[16:05] <slangasek> ah yuck
[16:05] <slangasek> how did that work for you locally then?
[16:05] <stgraber> apparently the upgrader didn't mind having the new -cli but the old mono
[16:06] <dpm> hi all. So the language packs for 12.04.1 have been signed off and the ones that have been can be moved from -proposed to -updates. I generally give the list onhttps://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA#Test_results_Ubuntu_12.04_.22Precise_Pangolin.22 to pitti and he does the uploads. Who can help me with that in his absence?
[16:07] <skaet> slangasek, ^ can you help?
[16:08] <stgraber> dpm: what happens to these that haven't been tested? do they stay in proposed, get removed from proposed or get copied without explicit sign-off?
[16:08] <stgraber> I'm wondering as the signed off list is much shorter than the list we currently have in proposed
[16:10] <dpm> stgraber, good question. Generally we only get a bunch of people testing langpacks, and we upload only those signed off to -updates. The rest (I believe) remain in -proposed for a while for late-comers, as it's my understanding that it's relatively trivial to copy them to -updated. Otherwise, it should be safe to remove them
=== cjwatson_ is now known as cjwatson
[16:11] <stgraber> cjwatson: welcome back to civilisation!
[16:11] <cjwatson> 14 days
[16:11] <cjwatson> sorry, 16 days
[16:12] <slangasek> heh
[16:12] <slangasek> cjwatson: welcome back ;)
[16:14] <ScottK> me wonders where cjwatson  went?
[16:14] <cjwatson> I've been on mobile internet, coffee shops, etc. for the last two weeks due to a DSL outage.
[16:15] <ScottK> Oh.  Right.  I knew that.
[16:15] <ScottK> Welcome back indeed (said with full irony from a coffee shop.
[16:16] <cjwatson> Judging by my ISP's fault ticket, if it goes down again it's probably because they didn't realise it's up.
[16:19] <ScottK> Nice.
[16:23] <stgraber> slangasek: hmm, just realized I can't seed libnspr4-0d that easily... the binary package is in universe
[16:24] <micahg> what is that package actually needed for?
[16:24] <slangasek> stgraber: er, libnspr4-0d wasn't supposed to be part of it anyway, the Breaks was added to libnspr4 right?
[16:24] <infinity> stgraber: The source is in main, we can certainly promote the binary in post-release pockets.
[16:24] <infinity> stgraber: (Assuming it's needed, which perhaps it's not, from slangasek's comment)
[16:24] <stgraber> micahg: contains compatibility symlinks for libnspr4
[16:25] <stgraber> slangasek: yeah, it's another case that we didn't see as I had all the nspr binaries in my local archive. Let me give you the upgrade log when that one is missing
[16:25] <micahg> oh, hrm, sorry, I thought we inherited that from Debian...I guess it was the main package before
[16:25] <stgraber> slangasek: http://paste.ubuntu.com/1138051
[16:30] <cjwatson> dpm: AFAIK only you, pitti, and maybe one or two other people have access to the system that builds the source packages and does the uploads
[16:30] <cjwatson> dpm: That system should I think have sufficient privilege to do them though?
[16:31] <infinity> cjwatson: They're already in proposed, he's talking about migration to updates... I think.
[16:31] <stgraber> cjwatson: the packages are already in -proposed, the current step is to pocket copy them to updates
[16:31] <stgraber> gah, infinity was faster
[16:31] <skaet> :)
[16:31] <cjwatson> Ah
[16:31] <infinity> stgraber: That time you took to add "-" to proposed cost you precious miliseconds.
[16:31] <dpm> cjwatson, yeah. I can do the uploads for someone to sponsor them to -proposed. Now it's about moving them to -updates
[16:32] <cjwatson> In that case surely it's just a giant sru-release call
[16:33] <cjwatson> http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/doc/operator-guide.txt
[16:33] <cjwatson> linked from ArchiveAdministration
[16:35] <cjwatson> Did pitti really not just copy all the langpacks?  That actually kind of surprises me
[16:35] <cjwatson> I guess not based on https://launchpad.net/ubuntu/+source/language-pack-ja
[16:35] <cjwatson> dpm: Is there a -base refresh in here?
[16:36] <dpm> cjwatson, yeah, it's a full langpack upload
[16:36] <cjwatson> In that case I'm very wary of copying -gnome without -kde or vice versa
[16:36] <cjwatson> In case I end up breaking dependencies
[16:36] <cjwatson> I'd rather copy a whole language at once
[16:38] <dpm> cjwatson, I think pitti copies only the gnome or kde one that has been signed off, but I'm not 100% certain. In any case, I think it should be safe to copy the whole language too
[16:38] <cjwatson> Are you prepared to sign off on me copying language-pack-{gnome-,kde-,}{en,ug,fr,hr,uk,de,sl,nl,zh-hans,zh-hant}{,-base} ?
[16:38] <cjwatson> Think I got all the language codes right
[16:38] <cjwatson> Oops, I read the wrong section
[16:39] <cjwatson> I wish this were listed by code
[16:39] <cjwatson> language-pack-{gnome-,kde-,}{en,ca,fi,uk,sl,es,fr,hu,it,hr,ga,ug,nl}{,-base} ?
[16:40] <dpm> yep, double-checked and the list looks good
[16:41] <cjwatson> Running
[16:42] <dpm> thanks cjwatson
[16:43] <stgraber> slangasek: confirmed that current alternate + libnspr4-0d => resolver happy
[16:43] <slangasek> stgraber: ah, ok
[16:43] <slangasek> infinity: ^^ will you promote this then? :)
[16:44] <stgraber> though I'll still have to revert the launchpad-integration -cli addition and find some other way around that problem as I don't want the alternate to be oversized :)
[16:45] <cjwatson> dpm: Done, pending the next publisher run
[16:45] <dpm> excellent, thanks again cjwatson
[16:46] <infinity> slangasek: Consider it done.
[16:47] <infinity> stgraber: libnspr4-0d will be in main (in proposed) after the next publisher.
[16:48] <seb128> ^ could that d-conf upload be consider for .1?
[16:48] <stgraber> infinity: thanks
[16:48] <seb128> also the compiz is the queue should be reviewed
[16:48] <stgraber> seb128: what's it fixing?
[16:48] <seb128> dconf?
[16:48] <seb128> or compiz?
[16:49] <stgraber> dconf
[16:49] <seb128> compiz is an update of the current proposed one with a fix for the arm* ftfbfs
[16:49] <stgraber> I know that compiz is just the armel/armhf fix
[16:49] <stgraber> and should indeed replace the one currently in proposed
[16:49] <seb128> stgraber, a bug which makes unity-2d just segfault when used on a machine with a dconf profile with multiple databases
[16:55] <stgraber> slangasek: in theory after the next publisher run + respin, alternate should be back to CD-size and work for upgrades
[16:56] <stgraber> slangasek: a quick test showed that I can drop liblaunchpad-integration1-cli and just seed liblaunchpad-integration1, making the resolver happy and avoiding the inclusion of all of the mono packages
[16:56] <slangasek> huzzah
[16:56] <stgraber> I still have no idea what the system will look like post-upgrade though ;)
[17:47] <SpamapS> Sorry for seeming a bit out of touch, but are we only accepting super high-priority stuff into precise-proposed now?
[17:48] <stgraber> SpamapS: yes, only things that got an exception or were uploaded before the 2nd of August 21:00 UTC
[17:49] <SpamapS> ok. d-conf is one of those things then. :)
[17:49] <stgraber> yep
[17:50] <slangasek> bug #1034806 puzzles me
[17:50] <ubot2> Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Medium,New] https://launchpad.net/bugs/1034806
[17:50] <stgraber> SpamapS: mythtv is also one of these and I see was re-uploaded recently
[17:50] <slangasek> it's a top crasher for the day and for the month.  It's also apparently *not* the one cjwatson just fixed in aptdaemon SRU
[17:51] <slangasek> SpamapS: the only diff in the new mythtv upload vs. the old one should be a dropped line from the .install file that fixes a FTBFS
[17:52] <slangasek> SpamapS: provided that's the case, I've already reviewed it and it should be good to go in (but I don't have time to check that myself at the moment)
[18:01] <cyphermox> slangasek: so, if I address the dbus name issue RFN, you think bug 1004775 would be fine for 12.04.1
[18:01] <ubot2> Launchpad bug 1004775 in network-manager "NetworkManager restarts dnsmasq and adds host route on every IPv6 route lookup" [High,Fix released] https://launchpad.net/bugs/1004775
[18:01] <cyphermox> ?
[18:01] <slangasek> cyphermox: yes... I still think the clutter in the kernel table is bad, but that would at least satisfy my concerns of regression
[18:02] <cyphermox> ok
[18:02] <cyphermox> clutter in the routing table: it's not pretty, I agree, but it's not know how to fix this.
[18:03] <cyphermox> there was a patch for the default route that addresses this but it's already in precise. or at least supposed to be
[18:04] <slangasek> ah, ok
[18:04] <cyphermox> yup, it's in 0.9.4.0-0ubuntu4.1
[18:06] <slangasek> stgraber: unassigning bug #1034794; live-initramfs is a universe package not used by any of our builds, the set of affected people is likely to be very small
[18:06] <ubot2> Launchpad bug 1034794 in update-manager "10.04 -> 12.04 upgrade should remove live-initramfs" [Low,New] https://launchpad.net/bugs/1034794
[18:06] <stgraber> slangasek: works for me. jibel raised that one during the 12.04.1 meeting
[18:07] <SpamapS> slangasek: ok, new mythtv reviewed, it is indeed just one removed line
[18:07] <SpamapS> -debian/30-mythtv-sysctl.conf etc/sysctl.d
[18:07] <SpamapS> slangasek: so, thats good to accept, yes?
[18:08] <slangasek> SpamapS: yep
=== kate_ is now known as skaet_
[18:21] <stgraber> slangasek: success! latest alternate build fits on a CD and contains everything needed for the upgrade
[18:22] <stgraber> now checking that the upgrader tarball works too (instead of using my heavily patched copy)
[18:25] <skaet_> :)
[18:27] <stgraber> jibel: confirmed, precise.tar.gz is indeed the one from the release pocket, not from -proposed (or -updates)
[18:27] <stgraber> so we need to fix that too
[18:30] <stgraber> looks like upgrade.sh needs some updating to look at the other pockets
[18:36] <stgraber> infinity, cjwatson: does that look sane to you? http://paste.ubuntu.com/1138274/
[18:37] <slangasek> cjwatson: bug #1034806 on aptdaemon is definitely looking suspicious to me as a possible SRU regression.  errors.u.c says it was "first seen" in 0.43+bzr805-0ubuntu1, but all but one of the crash reports are from today
[18:37] <ubot2> Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Medium,New] https://launchpad.net/bugs/1034806
[18:42] <infinity> stgraber: Why the for loop?  Don't you just want one or the other?
[18:43] <dobey> micahg: i don't see that discussion?
[18:43] <micahg> dobey: not your case specifically, but regressions in general, see above
[18:43] <dobey> oh, more general regressions
[18:44] <dobey> actually, what i'm hitting isn't a regression exactly
[18:44] <stgraber> infinity: I'm breaking after the first it finds. The loop is there because I can't assume we'll always have one in the updates or proposed pocket
[18:45] <stgraber> as a one time trick for precise I could certainly just hardcode -proposed and switch to -updates whenever we change the rest of the images, but there's no good reason not to make that change generic enough that it can be applied to quantal as well
[18:45] <infinity> stgraber: Would make more sense to just set $POCKET based on if it has anything in it, than the convoluted for/break... Though the end result is the same, I suppose.
[18:46] <stgraber> infinity: indeed, I can do that
[18:46] <infinity> Or, rather, set SOURCEDIR based on if there's anything in the descending set of pockets.
[18:46] <infinity> Also, I'm loving the gratuitous use of ls there...
[18:46] <infinity> Not that that's your code. :P
[18:47] <infinity> But if you change the SOURCEDIR setting to be based on walking the possible options, and setting it iff there's something found, then you can drop the ls and use if [ -n "$SOURCEDIR" ]
[18:48] <infinity> That feels a little bit more readable/maintainable to me, but YMMV.
[18:49] <infinity> Unless SOURCEDIR is used later in the script.
[18:49] <stgraber> infinity: http://paste.ubuntu.com/1138303/
[18:50] <stgraber> infinity: full script: http://paste.ubuntu.com/1138304/
[18:53] <infinity> stgraber: How and where does PROPOSED get set?
[18:54] <stgraber> infinity: PROPOSED is an environment variable that's pased when calling for-project, I'm kind of hoping nothing resets it later on (haven't tested that it makes its way to upgrade.sh)
[18:55] <infinity> Kay, you could drop the whole UPGRADER_POCKETS block
[18:56] <infinity> And just do "for POCKET in ${PROPOSED:-$CODENAME-proposed} $CODENAME-updates $CODENAME"
[18:56] <infinity> Err, but inverting the test. :P
[18:57] <infinity> ${PROPOSED:+$CODENAME-proposed}
[18:57] <stgraber> wouldn't that fail if PROPOSED is set to 0?
[18:57] <infinity> Does that happen?
[18:57] <infinity> (But yes, it would)
[18:58] <stgraber> well, all the other places where we test PROPOSED seem to consider 0 as a possible value, so I guess it can happen
[18:58] <infinity> Curious.  I've only ever seen us set it or not, not set it to naught.
[18:58] <infinity> But fair enough.
[19:00] <stgraber> doing a test run on precise, if that works, I'll apply the change to quantal too
[19:01] <infinity> That feels backwards. ;)
[19:01] <infinity> (But makes sense in this case, since quantal has no post-release junk)
[19:01] <stgraber> hehe, yeah, but we're missing an upgrader in -updates for quantal ;)
[19:01] <stgraber> right
[19:16] <jibel> I just confirmed bug 1034668, that's probably something we want fixed for 12.04.1. I'll upload the logs
[19:16] <ubot2> Launchpad bug 1034668 in update-manager "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [Undecided,Incomplete] https://launchpad.net/bugs/1034668
[19:42] <stgraber> bdmurray: ping
[19:42] <seb128> is there any chance http://launchpadlibrarian.net/112345416/ubuntuone-installer_3.0.2-0ubuntu1.1_source.changes gets consider for 12.04.1?
[19:42] <seb128> it fixes the most frequently reported issue on today's errors.ubuntu.com
[19:43] <bdmurray> stgraber: hi
[19:43] <stgraber> bdmurray: your apt-clone change seems to be broken, just found about that now that we have an updated update-manager on the media
[19:43] <stgraber> bdmurray: let me paste you the stack trace
[19:48] <stgraber> bdmurray: http://paste.ubuntu.com/1138397
[19:49] <stgraber> bdmurray: I'm also having a look at it, so if you're too busy I can probably figure it out and fix it
[19:50] <bdmurray> stgraber: i can sort it out
[19:51] <stgraber> bdmurray: my current guess is a python2.6 vs python2.7 syntax change
[19:52] <bdmurray> stgraber: i agree
[19:55] <stgraber> bdmurray: I have a system where I can extremely easily test a fix, so feel free to send the new .py my way for testing
[19:56] <stgraber> I guess using two separate "with" statements should be the easiest
[19:58] <bdmurray> stgraber: I used f = open(sources, 'r') and f.close() after the for loop and it seemed to work
[19:59] <stgraber> yep, that works too
[20:00] <seb128> did anyone from the SRU or .1 team read my comment about ubuntuone-installer's precise SRU?
[20:00] <stgraber> bdmurray: can you upload that to -proposed now (using -v0.2.2 to include the previous changelog entry)?
[20:01]  * stgraber prepares to rebuild update-manager once again
[20:01] <stgraber> seb128: looking at the diff
[20:01] <bdmurray> stgraber: is there a bug report for apt-clone?
[20:01] <stgraber> bdmurray: I don't think so, I'm probably the only person who tried the precise SRU on lucid at this point
[20:02] <stgraber> seb128: gah... I was sort of hoping for a bugfix only release...
[20:03] <seb128> stgraber, talk to dobey if you think only one of the fixes should be backported?
[20:13] <dobey> hrmm?
[20:15] <stgraber> dobey: as you know we're a week past the 12.04.1 upload deadline and your upload includes quite a bit more than just the fix we want for 12.04.1
[20:16] <dobey> stgraber: actually, i didn't know the dates exactly for that; have been a bit out of touch with 12.04.1 info as i've been swamped with stuff for our new version of ubuntu one and shipping it in quantal
[20:25] <bdmurray> stgraber: uploaded apt-clone
[20:25] <Laney> please could somebody move glib2.0 to release?
[20:25] <stgraber> bdmurray: thanks
[20:25] <stgraber> slangasek: can you review apt-clone?
[20:25] <infinity> Laney: Sure.
[20:28] <Laney> cheers boss
[20:28] <dobey> stgraber: also not sure who you mean by 'we' there. 'we' as in 'ubuntu one' want all those fixes in.
[20:29] <slangasek> stgraber: apt-clone> yes
[20:30] <stgraber> dobey: the "we" in there is the 12.04.1 team, only bug 853060 is milestoned, the rest can wait till after 12.04.1
[20:30] <ubot2> Launchpad bug 853060 in ubuntuone-installer/trunk "ubuntuone-installer crashed with GError in function(): Failed to execute child process "ubuntuone-control-panel-gtk" (No such file or directory)" [Critical,Fix released] https://launchpad.net/bugs/853060
[20:30] <slangasek> dobey: we're at the point where we have very little margin for error on SRU verification to get things into 12.04.1
[20:31] <slangasek> so every change not related to the bug seb128 is flagging, and which increases the chance of a regression and a failed SRU verification, likewise increases the chance of that fix missing .1
[20:31] <dobey> slangasek: understandable. and pretty much 100% of the other fixes are all non functional fixes anyway
[20:31] <slangasek> (I haven't looked at the actual upload yet - just providing context here)
[20:37] <slangasek> dobey: interesting that debian/patches/00_system-cache-only.patch updates the test suite, it doesn't appear to actually introduce any unit tests for the corresponding code change
[20:38] <slangasek> (i.e., there's no test here for a broken ppa source)
[20:38] <dobey> right
[20:44] <slangasek> stgraber, bdmurray: apt-clone accepted
[20:45] <stgraber> alright, rebuilding update-manager then
[20:58] <phillw> stgraber: are you mad busy, or do you have 5 minutes for a quick PM?
[21:02] <bdmurray> so what is reviewable in the precise-proposed queue? only items before a certain date or?
[21:05] <stgraber> phillw: pretty busy
[21:08] <phillw> stgraber: okies, when you get chance, let me know if the new drupal QA site should be installed on 12.04 server or if you're happy for it to be on 12.10 so I can set up the VM for it to be tested on.
[21:15] <stgraber> phillw: I'm not aware of any "new" Drupal site. The current Drupal site is iso.qa.ubuntu.com or iso.qa.dev.stgraber.org for the staging version and runs on 10.04 LTS
[21:17] <phillw> stgraber: okies, when you have some free time, I have a small drupal aware team willing to work with you and balloons on it.
=== kate_ is now known as skaet_
[21:47] <stgraber> slangasek: ^ can you review?
[21:47] <slangasek> stgraber: yes
[21:48] <stgraber> slangasek: the diff won't show any change as the embeded apt_clone.py is copied at build time
[21:48]  * slangasek nods
[21:48] <stgraber> slangasek: I checked that the new apt-clone has been published, so we should be good
[21:54] <slangasek> stgraber: accepted
[22:04] <bdmurray> slangasek: are there special constraints on reviewing the precise-proposed queue?
[22:06] <ScottK> bdmurray: Yes.  It should be stuff uploaded before the freeze deadline or stuff that's RC for 12.04.1 only.
[22:08] <stgraber> slangasek, infinity: got to disappear for a few hours, but I have a basic debdiff for the live-build trick. Would like to have someone confirm that it's done at the "right" place though: http://paste.ubuntu.com/1138613/
[22:08] <stgraber> will look when I'm back and if there's agreement upload that hack
[22:11] <infinity> stgraber: Removing just "language-pack-de-base firefox-locale-de" should do the trick, since the other depend on -base.
[22:12] <infinity> stgraber: And avoids the fact that your fancy expansion might not do what you think it does when you're 4 shells deep. :P
[22:15] <slangasek> bdmurray: hmm, you mean the new queue or the unapproved queue?
[22:17] <bdmurray> slangasek: the unapproved
[22:17] <slangasek> bdmurray: right - what ScottK said then, plus unseeded packages can go in anytime
[22:38] <bdmurray> slangasek, ScottK: how do you feel about displaying the last bug comment for "golden" bugs in the sru report on hover of the bugnumber?
[22:38] <ScottK> Purple too.
[22:38] <ScottK> Seems like a nice idea.
[22:38] <slangasek> bdmurray: as long as it doesn't make the report too long to load
[22:38] <bdmurray> slangasek: long to load or long to generate?
[22:39] <slangasek> load
[23:50] <infinity> slangasek / stgraber: So, eglibc uploaded to quantal (want to make sure it builds everywhere and has no test regressions on all 5 arches, since I only tested amd64 heavily here)
[23:50] <infinity> slangasek / stgraber: But, if all goes well, this is pretty much exactly the same delta I'd want to apply to precise: http://launchpadlibrarian.net/112361562/eglibc_2.15-0ubuntu15_2.15-0ubuntu16.diff.gz
[23:51] <slangasek> infinity: quantal or quantal-proposed?
[23:51] <infinity> slangasek / stgraber: The first two patches are trivial and, IMO, "obviously correct".  Sadly, it's the latter mess that's what's actually wanted by the world. :/
[23:52] <slangasek> (did you break my multiarchz‽)
[23:52] <infinity> slangasek: quantal... Thanks for the remindeer than I'm naughty on that score.  I keep forgetting about M-A skew.
[23:52]  * slangasek has a look at the patches
[23:52] <infinity> slangasek: Maybe we should have some sort of testing migration, and send all $suite uploads to $suite-proposed.  I think I'll bring that up at the next UDS. :P
[23:54] <infinity> slangasek: I *probably* could have backported avx-fma4 without avx-fma4-fixups, but those two patchsets are the ones I worked on with Carlos and Adreas upstream, and they're what, ultimately, got well-testing in 2.16 and 2.15.x, so I'm not particularly comfy with mangling them just to try to reduce the size of the backport.
[23:54] <slangasek> I think I'm unlikely to be able to do a good review of this at the moment.  Nothing stands out as "not appropriate for SRU" though
[23:54] <infinity> s/well-testing/well-tested/
[23:55] <infinity> Anyhow.  We'll see how the 4 testsuite runs pan out in quantal, and if that's good, I'll upload the precise one immediately after, since you said it all looks "SRU appropriate".
[23:55] <infinity> Should there be argument later, I can try to mangle, or postpone to .2
[23:58] <slangasek> it's .2 material at this point anyway