[04:55] <slangasek> hmm, surprised to see that pam was accepted; I'm just taking care of TIL merges, why was this cherry-picked into trusty-proposed while other packages aren't?
[10:33] <cjwatson> doko_: IIRC you said you had an opening mail ready to send?
[10:36] <doko_> cjwatson, yes, let me finish this
[10:41] <doko_> xnox, do you want to upload / sync the bits for boost1.54?
[10:42] <xnox> doko_: boost1.54 and boost-defaults are uploaded into trusty. I'd rather complete transition, once auto-sync is running / archive is open.
[10:50] <cjwatson> doko_: send away :)
[10:51] <Laney> wee
[10:53] <doko_> bye bye catching up on arm64 ...
[10:53] <xnox> doko_: =)
[10:53] <xnox> doko_: i was pondering if it make sense to upscore arm64/trusty-release builds.
[10:55] <doko_> xnox maybe, but then only some at a time, and selected ones.
[10:58] <cjwatson> doko_: arm64'll be fine, it's doing well enough
[10:58] <cjwatson> I don't think we need to worry about it
[11:13] <cjwatson> autosyncs starting
[11:13] <cjwatson> I expect a bunch of stuff will fail due to mid-perl-transition, but it'll clear out in time
[11:37] <cjwatson> sigh, the perl transition doesn't half make p-m take forever
[11:37] <cjwatson> I think I'll just block perl until the transition is a bit further along
[11:50] <doko> still not defaulting to openmpi1.6, there's an open debian report about the transition, left alone ...
[13:23] <cjwatson> aha, I see the auto-sync is building now
[13:31] <psivaa> cjwatson: ( i know there is a lot going on there :)) but autorun.inf and wubi.exe are missing from the desktop images of trusty.. are they still being refined?
[13:32] <xnox> cjwatson: i guess i should add it to the checklist, that symlinks need updating.
[13:33] <cjwatson> psivaa: I ran the cron job with no attention whatsoever :)
[13:33] <cjwatson> xnox: yes please
[13:33] <cjwatson> psivaa: so when xnox sorts out the symlinks, they should return
[13:33] <psivaa> cjwatson: ack, thanks :)
[13:33] <cjwatson> psivaa: is that what's keeping the images in pending?
[13:33] <xnox> cjwatson: well... i don't have access to update them =) i was going to bump wubi + add the steps to the NewReleaseCycleProcess.
[13:34] <cjwatson> xnox: oh, are they in ubuntu-archive or something?
[13:34] <psivaa> cjwatson: yes at least the desktop ones
[13:34] <cjwatson> xnox: can I just symlink saucy/stable to trusty/stable for now?
[13:34] <xnox> cjwatson: yes, please.
[13:35] <cjwatson> xnox: done
[13:35] <cjwatson> psivaa: doing another run now then
[13:39] <xnox> cjwatson: added a step about wubi symlinks before the cdimage cron step, on the NewReleaseCycleProcess.
[13:41] <cjohnston> lool: I've created a config for status.ubuntu.com for ubuntu-t.. I figured leave ubuntu-s running for a little while still?
[13:41] <cjwatson> xnox: thanks
[13:53] <doko> promoting ruby2.0 ...
[13:57] <doko> cjwatson, should we promote all lib*-perl modules needed for 5.18?
[13:58] <cjwatson> doko: I'm going to check that over after the dust has settled
[13:59] <cjwatson> doko: Right now I expect there could be noise and don't really want to spend time sorting it out manually :)
[14:13] <cjwatson> doko: that said, as long as you're aware that c-m-proposed might be lying if there are alternative dependencies involved and check it manually, be my guest
[14:13] <cjwatson> I suspect we should try to avoid that dep on libperl4-corelibs-perl (not for 5.18 as such)
[14:33] <cjwatson> Riddell: Can I sync citadel-client/citadel?  The only diff in citadel is https://launchpadlibrarian.net/142321516/citadel_8.16-1_8.16-1ubuntu1.diff.gz, but any build in >=saucy will build against libical 1.0 anyway, so I think that's probably not worth merging?
[14:33] <cjwatson> this is from auto-sync:
[14:33] <cjwatson> [New] citadel-client_8.20-1
[14:33] <cjwatson> No previous publications in Ubuntu
[14:33] <cjwatson> OK (Y/n)?  y
[14:33] <cjwatson>  * Trying to add citadel-client ...
[14:33] <cjwatson> citadel-client_8.20-1 is trying to override modified binary citadel-client_8.16-1ubuntu1.  OK (y/N)?  n
[14:34] <Riddell> cjwatson: yeah go for it
[14:34]  * Riddell at linuxcon this week, not very responsive
[14:35] <cjwatson> Riddell: responsive enough, thanks :)
[14:35] <cjwatson> enjoy linuxcon
[14:36] <infinity> xnox: Scoring up arm64/trusty-release builds would choke out proposed builds and cause unnecessary arch skew.  It's a feature that proposed builds first in this case.
[14:37] <cjwatson> Laney: you might want to merge your ttf-wqy-zenhei delta into the new fonts-wqy-zenhei package in Debian; it looks like perhaps your fix was never forwarded and Debian applied a less-optimal fix?
[14:37] <cjwatson> at least insofar as I can make it out
[14:38] <bdmurray> cjwatson: could you merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/reversed-releases/+merge/191997
[14:39] <cjwatson> bdmurray: done
[14:40] <bdmurray> thanks
[14:40] <cjwatson> bdmurray: yikes.  is there override damage in the archive to clean up?
[14:40] <Laney> cjwatson: Don't remember, will check it out
[14:40] <Laney> it's on my merge list
[14:40] <cjwatson> ok
[14:40] <cjwatson> thought it might not have been due to the source package name change
[14:40] <bdmurray> cjwatson: I don't believe so but will check the log files.
[14:40] <cjwatson> bdmurray: good stuff
[14:41] <bdmurray> cjwatson: did you add trusty to meta-release?  if not I have a change to make for saucy and can do that too
[14:42] <cjwatson> bdmurray: I didn't, go for it
[14:42] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687156
[14:42] <ubot2> Debian bug 687156 in ttf-wqy-zenhei "fontconfig disjunction syntax incorrect" [Normal,Open]
[14:42] <Laney> With amusing response
[14:48] <cjwatson> now that's a set of build queues and a half
[14:48] <cjwatson> glad we got those extra two x86 builders
[14:49] <stgraber> otherwise it'd have given a pretty funny result with armhf first, then powerpc, then x86 ;)
[14:49] <bdmurray> cjwatson: no phased update percentage changes were made in error, however some packages were in raring weren't incremented when they should have been.
[14:49] <ScottK> slangasek: Bug 1240673 seems to be piling up a fair number of "Me too" responses and seems to be all recentish Dell laptops, so I thought it might be worth mentioning given the Canonical/Dell partnership.
[14:49] <ubot2> Launchpad bug 1240673 in upower (Ubuntu) "Reports 0% charged for fully charged batteries" [High,Confirmed] https://launchpad.net/bugs/1240673
[14:50] <cjwatson> bdmurray: ok, that's presumably not horrible
[14:50] <stgraber> could someone please binNEW lxc? (added lxc-tests)
[14:51] <cjwatson> stgraber: looking
[14:52] <cjwatson> stgraber: "test binaries" - for use by whom?  automatic?
[14:53] <stgraber> cjwatson: I think hallyn's plan was to make use of those in autopkgtest and also help when debugging someone's system (those are test binaries for the liblxc library, basically one small binary per API call)
[14:53] <cjwatson> ah, I see
[14:53] <cjwatson> stgraber: do you plan to seed / depend on it somewhere in main, or should I drop it in universe?
[14:54] <stgraber> I'll add it to one of the supported seeds (though it'd probably be just fine in universe)
[14:55] <cjwatson> ok, accepting then thanks
[14:55] <stgraber> thanks
[15:04] <Laney> Are we SRUing things to teach them about trusty?
[15:06] <arges> Laney: I can help, looking at debootstrap unless soembody else is looking at it
[15:07] <Laney> I guess only if things actually fail
[15:07] <Laney> Just noticed dput-ng (fixed upstream to not hardcode)
[15:07] <arges> Laney: well on my precise box, i'd like to have a trusty sbuilder
[15:08] <Laney> Yes, debootstrap would fall into that class
[15:10] <doko> cjwatson, I see that libparams-validate-perl and libdatetime-perl do need updates. can I upload, or are other moduls first?
[15:12] <infinity> doko: I assume he's going in dependency level order, according to http://people.canonical.com/~ubuntu-archive/transitions/perl5.18.html
[15:12]  * infinity bumps a couple of builds to get level 1 done.
[15:17] <arges> Laney: i'm tracking this with bug 1242747 fyi
[15:17] <ubot2> Launchpad bug 1242747 in debootstrap (Ubuntu Saucy) "Add trusty as known Ubuntu release" [Undecided,New] https://launchpad.net/bugs/1242747
[15:17] <Laney> okay
[15:19] <cjwatson> doko: Yes, I'm going in dependency order as infinity says
[15:20] <bdmurray> could somebody release the SRU fixing bug 1241123?
[15:20] <ubot2> Launchpad bug 1241123 in ubuntu-release-upgrader (Ubuntu) "lubuntu-desktop PostUpgradeRemove rule is unnecessary and problematic" [High,Triaged] https://launchpad.net/bugs/1241123
[15:23] <infinity> bdmurray: Looking.
[15:24] <infinity> bdmurray: Done.
[15:24] <bdmurray> infinity: thanks
[15:26] <infinity> ScottK: debootstrap in precise-backports probably needs more love (shame it was ever backported...)
[15:27] <ScottK> Sigh.  OK.
[15:27] <infinity> I wonder if maybe we should just make the SRU version supersede it.
[15:27] <infinity> And then remove it.
[15:27] <ScottK> I think that's quite reasonable.
[15:27] <ScottK> +1 from me.
[15:28] <arges> ScottK: infinity : fyi, i'm looking at debootstrap now on bug 1242747, just uploaded precise. was planning on doing it for Q/R/S as necessary, let me know if that will be a problem
[15:28] <ubot2> Launchpad bug 1242747 in debootstrap (Ubuntu Precise) "Add trusty as known Ubuntu release" [Medium,In progress] https://launchpad.net/bugs/1242747
[15:29] <infinity> arges: Go ahead with Q/R/S, I'll reject the precise upload and reupload with a different version number.
[15:29] <arges> infinity: ok
[15:29] <lool> cjohnston: Ok; thanks -- we will probably use T starting with next vUDS
[15:29] <infinity> arges: precise (well, and lucid, but no one seems to care about that one) was the only release where someone backported debootstrap to -backports and sort of messed up the world.
[15:35] <cjwatson> I used to dump debootstrap into -backports quite frequently because it was less paperwork
[15:36] <infinity> cjwatson: Yeah, went sideways when people started SRUing it religiously, since people with -backports enabled have a stale version, unless it keeps getting backported.
[15:38] <infinity> People use dput-ng?  Man, I only just switched to dput from dupload.
[15:39] <infinity> ScottK: If you want to do the honors on my debootstrap/precise upload, that should be sufficient for us to just delete (or ignore) the backports one going forward.
[15:46] <ScottK> OK.
[15:46]  * ScottK looks
[15:48] <xnox> infinity: dput-ng is suppose to support the fancy new "grand a DM upload rights" but it fails to work for me =(
[15:50] <arges> can somebody unapprove the raring deboostrap upload? I forgot to add the bug # to the changelog.
[15:50] <infinity> arges: Sure.
[15:50] <arges> thanks
[15:50] <ScottK> arges: Too late.
[15:50] <ScottK> infinity: ^^^
[15:51] <infinity> Hrm?  Not too late.
[15:51] <infinity> I just rejected it...
[15:51] <ScottK> OK.
[15:52] <ScottK> infinity wins.
[15:54] <infinity> And, since the publisher wasn't working hard enough already, it's kernel SRU release day.  Whee.
[15:54] <rtg> infinity, saucy LTS ?
[15:55] <infinity> rtg: I'll check out lts-saucy after I've released the rest of the world here.
[15:59] <ScottK> arges: Accepted the fixed  one.
[16:00] <arges> ScottK: ok cool, I just dput saucy, and that should be it.
[16:15] <seb128> could somebody review the gnome-control-center SRU there ^
[16:16] <seb128> it's part of a round of improvements to a bug about keybinding-to-change-keymaps not working with annoys lots of user
[16:16] <seb128> (we get like 30 comments a day on this bug since release)
[16:49] <doko> infinity, is https://launchpad.net/ubuntu/+source/esys-particle/2.2.u2-2/+build/5137627 going to suceed?
[16:52] <infinity> doko: Yes.
[16:52] <infinity> doko: At least, the previous versions did, I don't see why it wouldn't.
[16:57] <arges> ScottK: Verified debootstrap for P/Q/R, but I can't find the saucy-proposed package to verify.
[16:59] <ScottK> arges: Not sure where it went.  Upload it again.
[16:59] <arges> ScottK: ok
[17:00] <arges> ScottK: actually I see this in my inbox:
[17:00] <arges> File debootstrap_1.0.53ubuntu1.tar.gz already exists
[17:00] <arges> Which is the trusty version
[17:01] <infinity> You want 0.1
[17:01] <arges> Ok, fixing.
[17:16] <ScottK> arges: Did that one too.
[18:15] <slangasek> bdmurray: so there's a new error reported for procps, but I don't seem to be able to get enough info out of the error tracker to confirm whether it's ignorable. https://errors.ubuntu.com/problem/24165ca0a985e6022d9da9a8e438b3e09f163c61
[18:16] <slangasek> I suspect this is a corner case only affecting those users who already had tried to install the previous busted version of procps
[18:22] <bdmurray> slangasek: package install failures for stable releases should still go to Launchpad but I don't see any for procps
[18:25] <bdmurray> slangasek: also one of the problems indicates it is a fresh install - https://errors.ubuntu.com/oops/03a6150c-38c7-11e3-a8a4-e4115b0f8a4a
[18:26] <slangasek> bdmurray: which wouldn't change the behavior of applying the SRU, I think?
[18:26] <bdmurray> ah right, sorry
[18:27] <slangasek> it's still unlikely to be a bug in procps itself, the error is because apt is telling dpkg the wrong thing
[18:27] <slangasek> so I think we should just override
[18:27] <bdmurray> agreed
[18:27] <slangasek> remind me where to do that?
[18:27] <slangasek> I'm sure I have a bzr checkout here somewhere, but don't remember its name
[18:28] <bdmurray>  bzr+ssh://bazaar.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides/
[18:28] <slangasek> thanks
[19:07] <seb128> ^ that gnome-settings-daemon upload is supposed to improve the keyboard layout switching issue I was mentioned earlier for gnome-control-center, would be nice to get in as well
[20:19] <doko> trying to find out why https://launchpad.net/ubuntu/+source/libperl-critic-perl/1.119-1/+build/5139895 fails. works for me in a local chroot
[20:23] <slangasek> doko: the latest failure is listed as a dep-wait on libmodule-pluggable-perl, is that wrong?
[20:24] <slangasek> hmm, looks like it's in the archive now
[20:26] <infinity> "Module::Plaggable Provides a simple ..."
[20:26] <infinity> PLAGGABLE.
[20:28] <stgraber> doko: a local sbuild build gives me the same thing as LP (when building with -proposed and only main+restricted)
[20:28] <infinity> Oh, that probably needs a promotion.
[20:28] <stgraber> right, just checked and the b-d is in universe
[20:28] <stgraber> so that'd explain it
[20:28] <infinity> Yeah, that got split out from perl-modules.  I'll promote.
[20:29] <infinity> (Please, no one else do so, it'll disappear)
[20:29] <infinity> component-mismatches-proposed is an entertaining mess...
[20:29] <stgraber> ;) so speaking of which, has any process been made on fixing the double-override bug?
[20:30] <infinity> stgraber: No, we've had bigger fish to fry.
[20:30] <stgraber> ^ procps is a mini-transition I'll take care of it
[20:30] <stgraber> (as in, it's my upload so need someone to binNEW for me, but I'll take care of the transition after that)
[20:31] <infinity> stgraber: I'll poke the binaries when they all roll in.
[20:32] <stgraber> seems like we have a bit of a java mess going on in -proposed? (looking at c-m)
[20:32] <infinity> stgraber: Yeah, looks like.  Will worry about it after the dust has settled a bit.
[20:34] <infinity> {standard input}:1: Error: junk at end of line, first unrecognized character valued 0x10
[20:34] <infinity> {standard input}:1: Error: unknown mnemonic `€' -- `€'
[20:34] <infinity> {standard input}:1: Error: unknown mnemonic `˜¼s3' -- `˜¼s3'
[20:35] <infinity> Hrm, I wonder if that might be memory corruption.
[20:35] <infinity> Or the world's best assembler...
[20:51] <doko> stgraber, just one package
[20:59] <infinity> stgraber: Accepted.
[21:00] <stgraber> ifnthanks
[21:00] <stgraber> infinity: thanks
[21:00] <stgraber> (works better when I actually press tab apparently)
[21:06] <seb128> infinity, stgraber, slangasek, bdmurray: could one of you review the gnome-control-center/gnome-settings-daemon saucy SRUs today? the "can't switch layout" seems it's sort of really annoying russian and chinese users from the number of angry comments we get
[21:07] <infinity> seb128: saucy?
[21:07] <seb128> infinity, yes
[21:07] <infinity> seb128: Looking.
[21:07] <seb128> infinity, thanks
[21:10] <slangasek> eep, yes, being able to change your keyboard layout is a bit important when your native language and English require mutually exclusive things :P
[21:11] <seb128> slangasek, well, you can change it, but not without a keybinding ... which is sort of inefficient ;-)
[21:11] <seb128> (e.g the indicator works, but it requires going to click there every time)
[21:11] <seb128> infinity, thanks!
[21:12] <infinity> This gsd patch is quite... Extensive.
[21:13] <infinity> seb128: Do you know if this is going or has gone upstream?
[21:14] <seb128> infinity, not going upstream, we are adding code they dropped basically
[21:14] <infinity> :/
[21:14] <infinity> Kay.
[21:15] <infinity> I can follow what it's meant to do, and it seems sane, but hard to audit a patch this large by eyeballing it.
[21:15] <seb128> infinity, they moved the feature to gnome-shell (which makes sense), ideally we would do the same with unity, but unity7 is not having enough manpower for that
[21:15] <seb128> infinity, those patches have been tested in a ppa and got feedback from quite some users for a week
[21:15] <seb128> I'm running it as well
[21:15] <infinity> seb128: Good to hear.
[21:21] <seb128> infinity, thanks
[21:58] <doko> infinity, https://launchpad.net/ubuntu/+source/ruby-rspec-core/2.14.5-1/+build/5142443 probably needs manual intervention. ruby-rspec was already built for the new version
[21:59] <infinity> doko: Erk, annoying.  I'll sort that in the bootstrap repo or something clever.
[22:00] <doko> thanks
[22:06] <stgraber> infinity: someone just filed a bug about that pt_chown change against LXC when running some other distro. So I've spent the time to add all the needed tasks, SRU paperwork, ... bug 1242913 if you want to keep that on a list somewhere for when you do the eglibc security update
[22:06] <ubot2> Launchpad bug 1242913 in lxc (Ubuntu Saucy) "/dev/pts being created with mode=600 by Lxc" [High,Triaged] https://launchpad.net/bugs/1242913
[22:08] <infinity> stgraber: Well, at least I gave you warning. :)
[22:10] <stgraber> infinity: yeah, most of the !ubuntu templates are kind of broken anyway so it's not extremely urgent for us to SRU the upstream fix just yet. It'll get done with our next round of SRU unless the eglibc update hits first (in which case we need it done right before or at the same time to avoid global breakage)
[22:11] <infinity> stgraber: I intend to put a lot more thought into it before doing the glibc switch, but it will be in the next couple of months, I'm sure.
[22:14] <infinity> doko: FWIW, that's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677955
[22:14] <ubot2> Debian bug 677955 in ruby-rspec-mocks,ruby-rspec-expectations,ruby-rspec-core "Circular build dependency ruby-rspec-mocks <-> ruby-rspec-expectations <-> ruby-rspec-core" [Normal,Open]
[22:14] <infinity> doko: I'll do the manual bootstrap here for now, but I sure hope I don't have to do this over and over again.
[22:44] <infinity> Who accepted that walinuxwagent/precise?
[22:45] <infinity> stgraber: When you're doing NEW processing, doing the correct overrides in the queue is nice too...
[22:45]  * infinity fixes.
[22:47] <stgraber> infinity: doh, thanks for fixing. I accepted using the API while doing other SRU reviews so didn't think of the overrides... (those SRUs for packages introduced post-release showing up in New are annoying...
[22:48] <stgraber> )
[22:48] <infinity> stgraber: Yeah, that's a bug, to be sure, but one we need to be aware of for now. :P
[23:03] <infinity> doko: ruby bootstrap loop sorted.
[23:30] <doko> afk now, fixed / did give back about 30 ftbfs today