[00:01] <stgraber> tjaalton: so the sssd upstart fix ends up taking 100% of CPU... I found an alternative that seems safe, will upload that now...
[00:07] <jdstrand> can someone also look at oxide-qt? it was approved earlier
[00:07] <jdstrand> if you tell me to just do it, I can myself
[00:12] <cjwatson> I don't suppose there's any chance of bug 1297804 being approved?
[00:12] <ubot2> Launchpad bug 1297804 in libpipeline (Ubuntu) "FFe: libpipeline 1.3.0" [Wishlist,New] https://launchpad.net/bugs/1297804
[00:14] <stgraber> cjwatson: approved
[00:15] <cjwatson> oh, that was quick, thanks :)
[01:02] <infinity> stgraber: That sssd exec is icky...
[01:05] <stgraber> infinity: does the trick, though I agree that upstream is just buggy there and should be fixed to not fail or eat all your CPU when using a sane stdin...
[01:05] <infinity> stgraber: Why not just start it with -D and expect fork?
[01:05] <infinity> Or expect daemon.
[01:05] <infinity> Whatever.
[01:05] <stgraber> infinity: because sssd is also buggy in that case
[01:06] <infinity> stgraber: Err, srsly?
[01:06] <stgraber> infinity: as in, it'll daemonize before it's done parsing your config
[01:06] <stgraber> so if your config isn't valid, it daemonized, then exits before the second fork, confusing the hell out of upstart in the process
[01:06] <stgraber> and you end up with upstart thinking it's running when it's not, with the only solution to fix the state being a reboot of the system
[01:06] <infinity> stgraber: util/server.c seems to imply and attempt to make that not happen. :/
[01:07] <stgraber> clearly failing :)
[01:07] <infinity> Bleh.
[01:07] <infinity> Seems like it would be worth fixing correctly instead of working around weirdly.
[01:08] <stgraber> setup sssd to use a krb5 ticket to authenticate, forget to setup said ticket before starting sssd => boom, upstart thinks it's running but sssd exitted
[01:09] <stgraber> totally agree that having sssd be a bit more sane when running in either foreground or background would be nice, though it's not something I have much time to debug and resolve properly right now, so the hackish upstart job at least does the trick and make things work reliably
[01:10] <stgraber> (sssd basically spawns 5-6 sub-daemons, all of which read their part of the config, failure from any of those may cause the main daemon to exit. So making sure that the daemonizing case is sane may be a bit challenging...)
[01:12] <infinity> Wow, it actually scans stdin.  That explains why /dev/zero drove it nuts.
[01:12] <infinity> And it reads an EOF as an explicit kill.
[01:12] <infinity> WHO WRITES SOFTWARE LIKE THIS.
[01:12] <cjwatson> Running stuff in the foreground is generally the right answer with modern inits anyway ...
[01:12] <infinity> cjwatson: It is when it's not written by nutters.
[01:12] <cjwatson> Well yes
[01:13] <infinity> stgraber: With /dev/null as stdin, did you get "EOF on stdin - terminating"?
[01:17] <infinity> Oh, FFS, how do I configure this to run it? :P
[01:22] <infinity> stgraber: Erm.  So, I can't make it die with "sssd < /dev/null" ...
[01:22] <infinity> Oh, maybe -D is the default.
[01:23] <infinity> Indeed it is.
[01:37] <infinity> stgraber: http://paste.ubuntu.com/7228797/
[01:38] <infinity> stgraber: That makes it stop doing Very Stupid Things with stdin, and </dev/null works again.
[01:39] <jdstrand> infinity: hey, shall I approve oxide-qt-- it got the testing and is in unapproved. I'm happy to have someone else do it too of course
[01:39] <stgraber> infinity: well, the question then is whether there's a case where something spawns sssd and actually wants to feed it stuff on stdin or kill it by closing it
[01:39] <infinity> jdstrand: Is it identical to what I reviewed in your PPA before?
[01:39] <jdstrand> yep
[01:40] <stgraber> infinity: that'd seem pretty unlikely, but upstream did write those lines and the stdin handler for some reason after all...
[01:40] <jdstrand> bit for bit
[01:40] <infinity> jdstrand: Then go nuts.
[01:40] <jdstrand> thanks! :)
[01:40] <jdstrand> (it was just a binary pocket copy)
[01:40] <infinity> stgraber: I'd guess it's for debugging.  Not even the testsuite uses it, can't fathom why a user would.
[01:40] <infinity> stgraber: Besides, Ctrl-C still works.
[01:41] <infinity> stgraber: Take it or leave it.  If you think the mangled upstart job is better, I can confirm that also works, I just think it's awful. :P
[01:42] <stgraber> infinity: so I think I'd rather stay away from distro changes to the upstream code at this point and bring this upstream, then hopefully the next point release will contain their fix and we can use that and drop the upstart job hack
[01:42] <stgraber> though tjaalton is the one who does most of the work on sssd in Debian/Ubuntu so he may have a different opinion
[01:43] <infinity> tjaalton: ^
[01:43] <infinity> stgraber: Does either of you have a good relationship with upstream?
[01:43] <infinity> (Given that upstream seems to be very Fedora-centric, I can't see how this hasn't also been an issue with systemd... Does systemd play differently with FDs by default?)
[01:44] <stgraber> yeah, we have a pretty good relationship with upstream and they tend to be pretty quick at fixing issues (like that samba4 crash we reported and got fixed within the hour earlier today)
[01:45] <infinity> stgraber: So, I think they should fix their buggy -D implementation, but I imagine that will take Serious Thought(tm).  But making -i not bugger stdin should be trivial.
[01:45] <infinity> stgraber: And I can honestly see no reason why it does, except for debugging convenience.
[01:45] <infinity> But.. *shrug*
[01:46] <infinity> stgraber: I'll accept your upstart job fix for now, I confirmed that it works.  I'm just going to register my formal grumpiness with it being poop. ;)
[01:48] <stgraber> infinity: I'll file an upstream bug report now so I can forward your grumpiness where it belongs ;)
[01:52] <infinity> Okay, based on commit messages, looks like they're using -D under systemd, which would be why this weird -i behaviour isn't biting them.
[01:53] <infinity> And it could just be luck of job timing that they're not seeing the bug you do with -D.
[01:53] <stgraber> bug filed upstream
[01:53]  * infinity washes his hands of it.
[02:15] <slangasek> bdmurray: yeah, early release of 1286161 seems ok to me
[02:16] <slangasek> hmm, was qtbase-opensource-src auto-accepted, or did someone else review that?
[02:18] <cjwatson> I think I accepted the symbols changes
[02:18] <cjwatson> well, not the gles thing if that's been uploaded
[02:19] <cjwatson> the previous change
[02:19] <slangasek> stgraber: do you know why the logind upstart job is in a Multi-Arch: same pam package instead of in systemd-services - and why the service doesn't get started on install?
[02:19] <slangasek> stgraber: I ask because I happened to have my system in a state affected by bug #1302264 and found myself needing to reboot... NM was unhappy :P
[02:19] <ubot2> Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released] https://launchpad.net/bugs/1302264
[02:20] <slangasek> cjwatson: ah, ok - yeah, it's only the gl side that's been uploaded for now
[02:20] <stgraber> slangasek: I don't know why the packaging was made this way... pitti may know.
[02:20] <slangasek> ok
[02:21] <slangasek> the first part seems to have been bug #1156074
[02:21] <ubot2> Launchpad bug 1156074 in systemd (Ubuntu Raring) "installing systemd-services without libpam-systemd loses device ACLs" [High,Fix released] https://launchpad.net/bugs/1156074
[02:27] <slangasek> the second part is a bug introduced in saucy when trying to avoid restarting logind on upgrades
[03:47] <rsalveti> slangasek: ^ for qtdeclarative
[03:49] <slangasek> rsalveti: so libqt5quick5's exported ABI doesn't change with the gles switch, but two variants need to be built because it will depend on GL-specific symbols when built against it?
[03:49] <slangasek> (just confirming that my understanding of the patch matches your intent)(
[03:50] <rsalveti> slangasek: 2 things, it'll depend on gl directly and will also depend on the packages built with gl by default, but they export the same abi
[03:51] <slangasek> ok
[03:51] <slangasek> accepting
[03:51] <rsalveti> one thing we need to better investigate later is what to do when a package depends on a common set of gl/gles symbols
[03:51] <rsalveti> I know in linaro we had a small library that could do runtime detection and decide gl/gles in runtime
[03:52] <rsalveti> but not so sure why nobody put a lot of more effort on that
[03:52] <slangasek> because glue libraries are messy :-)
[03:52] <rsalveti> but in this qt case, we might just follow directly with qt upstream, as they are doing a similar check in trunk (but currently just on windows)
[03:52] <rsalveti> yeah :-)
[04:52] <tjaalton> stgraber, infinity: heh, so it wasn't just the old upstart job that was buggy.. good to know. And I'm fine with the current workaround
[04:59]  * infinity curses component-mismatches trying to yank random universe kernels in again.
[08:01] <seb128> hey release
[08:02] <seb128> could somebody review bamf/compiz/nux in the queue?
[08:09] <dbarth> good morning, so today i'm trying to land a few things:
[08:09] <dbarth> account-plugins
[08:09] <dbarth> webbrowser-app
[08:09] <dbarth> and libunity-webapps and related (they come from silo 8)
[08:20] <seb128> Laney, so, nobody reviewed that bamf changes during the night :/
[08:21] <Laney> I imagine it'll get cleared out before final freeze
[08:21]  * Laney will look at other things now
[08:23] <seb128> k, fair enough
[08:42] <sil2100> seb128: I see compiz, nux and bamf still in the queue - any hope those will move out of UNAPPROVED soon? :)
[08:42] <seb128> sil2100, I do as well
[08:42] <seb128> I pinged about that earlier
[08:43] <seb128> seems like the US team didn't get to those during their shift, let's see if the europeans do
[08:43] <sil2100> o/ Thanks
[08:44] <seb128> stgraber, infinity, slangasek; did you guys reviewed the queue during your day/kept those on hold for a reason, or it's just that nobody has slots for reviews?
[08:48] <infinity> seb128: Did some, but not many.  I'll do a few more before I head to bed.
[08:49] <infinity> seb128: Hard freeze tomorrow (well, tomorrow for me) anyway, so it should slow down after that. :P
[08:50] <seb128> infinity, thanks ... and yeah, "should", I don't see that really happening though
[08:50] <seb128> well, a part of the uploads is going to turn into SRU
[08:50] <seb128> but I can see a steady flow of SRUs between release and .1
[08:51] <infinity> Inevitably, yeah.  Seems to be the way with LTSes.
[08:55] <maclin> slangasek，hi， I am maclin from Ubuntu Kylin.  I have push new source code of software center to launchpad. All the problems you found have been modified except python2. Could you help to review it?
[08:59] <JackYu> slangasek, maclin means the FFe bug #1293299.
[08:59] <ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFe]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
[09:37] <seb128> sil2100, ^ things got accepted, we should have some silos we can m&c in the next publisher runs
[09:37] <seb128> (thanks to whoever did the reviews btw!)
[09:37] <cjwatson> yw
[09:38] <cjwatson> would be nice if somebody could review libpipeline (it has an approved ffe now) so that I can sync man-db
[09:40] <Laney> ha, gexiv2 was what I was referring to in #ubuntu-devel
[09:40] <cjwatson> oh, whoops
[09:40] <cjwatson> sorry
[09:40] <cjwatson> I was motivated by seeing several things in p-m that were blocked on it ...
[09:40] <Laney> never mind, fixable
[09:40] <cjwatson> it'll hit NEW anyway, so you have a chance :)
[09:42]  * cjwatson suppresses his "auto-NEW stuff from Debian" twitch
[09:44] <sil2100> \o/
[09:44] <sil2100> Thanks guys!
[09:44] <sil2100> Can't wait for those to migrate out of proposed ;)
[09:56] <cjwatson> libpipeline> thanks
[09:56]  * infinity tips hat.
[09:57]  * infinity falls asleep in hat.
[10:30] <infinity> ^-- Can someone do a quick review of that flash-kernel?
[10:31] <infinity> I'm told it's tested to DTRT, and I verified the strings are correct.
[10:32] <cjwatson> infinity: LGTM
[11:55] <Riddell> possible kde-l10n spam ahead
[12:03] <doko> jibel, pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-python3.4-armhf/22/?  looks like the armhf test is run too early. the armhf build is not yet available as you can see from the log
[12:05] <jibel> doko, it's possible, armhf are triggered when x86 tests pass. I'll restart it.
[12:06] <jibel> (when the build is available)
[12:06] <doko> need to fix the aarch64 build anyway
[12:28] <jpds> Can someone please poke ima-evm-utils through NEW?
[13:58] <jamespage> could the neutron upload in proposed be rejected please - I missed a bit
[13:58] <infinity> jamespage: Done.
[13:58] <jamespage> infinity, thanks
[14:14] <didrocks> Laney: sorry to nag you, we have a regression fix from today's landing in webbrowser-app which is really needed for next image
[14:14] <didrocks> Laney: it should be easy enough to review :)
[14:14] <didrocks> https://code.launchpad.net/~dbarth/webbrowser-app/notitle/+merge/215166
[14:14] <didrocks> (and there is a new unity8 coming which will need a bump in the fauxpackage)
[14:18] <Laney> didrocks: ok, sec
[14:20] <didrocks> thanks man :)
[14:37] <didrocks> Laney: lost in space and time? :p
[14:39] <Laney> have patience my child
[14:42] <didrocks> thanks Laney
[14:43] <Laney> np!
[14:50] <bdmurray> slangasek: did you want to release ubuntu-release-upgrader to saucy-updates or shall I?
[14:50] <slangasek> bdmurray: please go ahead
[14:54] <jamespage> infinity, neutron with missing bits included now in the queue
[14:55] <infinity> jamespage: I assume that means you added bits, not that more are missing? :P
[14:55] <jamespage> infinity, I did indeed add the missing bits :-)
[15:04] <zequence> Any core-dev around, that could lend us some upload rights? Bug 1291675
[15:04] <ubot2> Launchpad bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675
[15:04] <zequence> This package has some major improvements to the released one. Has been tested and is pretty much ready to go.
[15:15] <infinity> zequence: Wasn't ScottK asking you about that last night?
[15:16] <zequence> infinity: Yep. He approved it as a FFe. There was a repackaging since
[15:24] <Laney> I probably ought not to review gnome-screensaver since it's my own
[15:24] <Laney> Would appreciate it being looked at
[15:26] <cjwatson> accepted gnome-screensaver
[15:27] <Laney> Cheers
[15:27] <Laney> happy mostly working lockscreen
[15:27] <cjwatson> that fixes the double-lock?
[15:27] <Laney> unity mainly, but that has a hand
[15:28] <Laney> It takes over the D-Bus interface from gnome-screensaver, but g-s needed patching to allow itself to be replaced on the bus
[15:28] <Laney> (Which is quite a neat facility in D-Bus that I wasn't familiar with)
[15:28] <cjwatson> right
[15:44] <slangasek> maclin, JackYu: is someone taking care of sponsoring ubuntu-kylin-software-center?  I doubt I will have time to review it today, the best thing is to get it uploaded and get it reviewed by whoever's available at the time
[15:44] <slangasek> roaksoax: why is bug #1294323 private?  public bugs only for FFes, please
[15:45] <JackYu> slangasek, hi, we don't have the rights to upload it.
[15:46] <JackYu> slangasek, and neither happyaron...
[15:46] <slangasek> JackYu: understood; so you don't have any sponsor lined up for this?
[15:47] <JackYu> slangasek, yep, that's the situation:(
[15:47] <slangasek> ok
[15:47] <slangasek> let me see what I can do about that
[15:47] <JackYu> slangasek, great, thanks.
[15:49] <JackYu> slangasek, we are waiting for ubuntu-kylin-software-center and ubuntukylin-keyring being uploaded. Then we could upgrade the ubuntukylin-default-settings, so that these two packages would be included into the distribution.
[15:49] <slangasek> JackYu: right.  I've uploaded ubuntukylin-keyring, it's in the NEW queue now and should get review from another archive admin
[15:50] <slangasek> infinity: ^^ could you slot that in maybe?
[15:50] <infinity> Phrasing.
[15:51] <infinity> slangasek: So, this is the keyring with the agreed-upon generated-by-IS key?
[15:51] <slangasek> infinity: that's what I'm claiming
[15:52] <infinity> slangasek: Can I independently validate this key in the DC somewhere?
[15:52] <roaksoax> slangasek: yeah I filed a different public bug
[15:52] <slangasek> infinity: you can check it against the RT
[15:52] <slangasek> infinity: RT #69080
[15:52] <infinity> slangasek: Ta.
[15:57] <infinity> slangasek: Is this just a cargo-cult of ubuntu-keyring?
[15:58] <slangasek> infinity: yes, as noted in the linked FFe bug
[15:58] <infinity> Oh, who reads bugs?
[15:59] <infinity> slangasek: I was just going to whine about the lack of build-* targets, but if it's derived, I don't much care.  debdiffing against ubuntu-keyring to see how close they are.
[16:08] <infinity> slangasek: Is it expected that installing this keyring makes apt trust it, or will an installer mangle that?
[16:13] <slangasek> infinity: isn't that what the postinst does? (apt-key update)
[16:14] <infinity> slangasek: You'd think.
[16:14] <infinity> slangasek: Maybe it doesn't like ascii armored keys and wants an actual keyring?
[16:14] <slangasek> JackYu: xnox is reviewing ubuntu-kylin-software-center now for sponsorship
[16:14] <slangasek> infinity: ah; I would think that and did think that, but did not in fact test it
[16:15] <JackYu> slangasek, xnox, thanks. maclin and I are here waiting for your questions:).
[16:18] <xnox> JackYu: so far it's ok, one minor dependency is missing which i'll fix up before uploading.
[16:19] <xnox> JackYu: and i'm writting up review comments on the bug report.
[16:19] <xnox> JackYu: no blocking issues found yet, but i'm not done reviewing.
[16:19] <Saviq> who do I bribe to push unity8 through to release? ;)
[16:19] <xnox> Saviq: as per topic "we accept payment in cash, check or beer" and https://launchpad.net/~ubuntu-release/+members#active for the list of people
[16:20] <infinity> Saviq: I'll sort it.
[16:20] <Saviq> infinity, awesome, thanks, infinity.beer++
[16:20] <JackYu> xnox, got it.
[16:21] <infinity> I'll take a raincheck on the beer.
[16:22] <apw> the xen and libvirt combination are best viewed together and are a fix for the migration of machine definitions on upgrade
[16:26] <JackYu> xnox, sorry for my bad understanding, you mean you will upload it now and review it later, or you just upload it and we should find another sponsor to review it?
[16:27] <slangasek> JackYu: he is reviewing and once he is done reviewing, if there are no blocking problems, he will upload
[16:28] <JackYu> slangasek, ah:).
[16:30] <infinity> slangasek: Okay, so.  Two things.  It does seem to want to be a gpgp keyring, not an ascii art masterpiece.  But, also, I can't seem to get apt-key update to add it to trusted.gpg.  I *think* it only looks at archive.gpg
[16:30] <infinity> slangasek: Shipping it in /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg works, though.
[16:31] <infinity> slangasek: So, perhaps a symlink in postinst from /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg to /usr/share, and skip the other bits?
[16:31] <slangasek> infinity: ok.  Since you've looked at this and understand what's needed, do you want to reject, change, and bounce it back in my direction for counter-review, or do you want me to fix it up and resubmit?
[16:31] <infinity> slangasek: Sure, I can do that.
[16:39] <slangasek> infinity: do you intend to generate the binary keyring at build time, OOI?
[16:40] <infinity> slangasek: We don't seem to for ubuntu-keyring.
[16:42] <slangasek> infinity: yeah; I would argue that this is a bug in ubuntu-keyring too :)
[16:42] <infinity> slangasek: Perhaps, yeah.  But I'm not sure it's one I want to fix this instant.
[16:42] <infinity> slangasek: We can do both together some day.
[16:42] <slangasek> yep
[16:42] <infinity> slangasek: Not like an .asc is really any more readable than a .gpg, it's just more vi-friendly.
[16:42] <slangasek> just makes it a little harder for me to review and make sure you're not MITMing me ;)
[16:44] <cjwatson> grub2 won't be until early tomorrow morning I suspect, by the time I've built this, uploaded to Debian, and synced
[16:47] <cjwatson> The grub2 patch will be http://paste.ubuntu.com/7231546/ unless something goes horribly wrong for some reason
[16:48] <cjwatson> I guess I could hack the .changes and upload the exact same thing to Ubuntu if people think I should
[16:48] <cjwatson> Would be nicer to have the proper audit trail though
[16:49] <infinity> cjwatson: Letting the sync happen $later seems fine.
[16:53] <slangasek> I think it's unfortunate that the better we do at keeping things in sync with Debian, the slower it makes our updates in Ubuntu during critical times
[16:53] <slangasek> considering Debian was discussing reducing dinstall back down to daily, we should probably think about getting better syncing support from incoming
[16:54] <cjwatson> Yes, I agree on that
[16:56] <infinity> To sync securely from incoming, all we need is access to the buildd repo.
[16:57] <cjwatson> Incoming is signed these days, isn't it?
[16:57] <infinity> We probably just have to ask nicely, and retool the LP sync stuff.
[16:57] <infinity> cjwatson: incoming isn't, but incoming/buildd is.
[16:57] <cjwatson> Oh, right
[16:57] <cjwatson> Dunno if it would need that much retooling, it could just be another suite?
[16:58] <infinity> slangasek: Okay, try that one on for size.
[16:58] <cjwatson> I assume incoming/buildd is only private so that the world doesn't add it to their apt sources
[16:59] <slangasek> infinity: I have a call now, it'll be a couple hours before I can look at it - is that ok?
[16:59] <infinity> slangasek: Doesn't bug me.
[17:00] <infinity> cjwatson: Yeah, pretty sure that was the reasoning.  And so we could unaccept if really, really necessary.
[17:00] <infinity> cjwatson: But I don't think the unaccept case matters for Ubuntu syncing, we'd just sync a newer version in that strange case.
[17:00] <infinity> (or revert manually, or whatever)
[17:01] <cjwatson> Right, so auto-sync should still work off unstable, and we could shove it into Debian/incoming and people could use syncpackage -d incoming if they're in a rush
[17:01] <infinity> cjwatson: Yeah, that seems ideal to me.
[17:01] <cjwatson> gina will do its usual tracking of what's in what suites without much trouble AFAICS
[17:02] <cjwatson> wgrant: ^- any qualms with the above?  otherwise I can go ask ftpmaster
[17:03] <infinity> cjwatson: Assuming we poll something not too unfriendly, I can't see that they'd mind.  I hope.
[17:04] <cjwatson> I was thinking hourly
[17:04] <infinity> cjwatson: (And, really, buildds hit those Packages/Sources files constantly, one more buildd-like machine only hitting Sources.gz every 15-60m or something would be nothing)
[17:04] <infinity> The queue runs every 15 or 20, doesn't it?
[17:04] <infinity> I always forget.
[17:04] <cjwatson> And it'd be debmirror, but could be debmirror over HTTP if buildds don't get rsync
[17:04] <cjwatson> Not sure
[17:05] <infinity> cjwatson: Well, we could check a cached Sources for freshness, then trigger a mirror, I assume.
[17:05] <infinity> Though, I imagine debmirror has such a facility anyway.
[17:05] <cjwatson> debmirror fetches Packages/Sources and only grabs what it doesn't have
[17:05]  * infinity nods.
[17:05] <infinity> And we only want Sources, so just that.
[17:06] <cjwatson> Er right
[17:06] <cjwatson> So --arch=none
[17:07] <infinity> If we could get a push trigger, that would be even better, but I won't push my luck.  A shortish poll would still be way ahead of our current situation.
[17:08] <infinity> And unless they've gone high tech since I ran a Debian buildd, if we want to do polling, it's literally just them generating a u/p pair for us in htaccess and letting us loose.
[17:08] <cjwatson> Could just ask what's reasonable, indeed.
[17:09] <infinity> Possibly also IP limited, now that DSA demands buildds not be on sketchy cable modems. :P
[17:10] <xnox> slangasek: JackYu: given the time constraints I have sponsored the package, with a few changes which are proposed for merging back into trunk at https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/14.04-release/+merge/215258
[17:11] <infinity> Ahh, phew.  "Good" news.  That testsuite regression on POWER8 isn't a regression.  Breaks in the old version too.
[17:11] <JackYu> xnox, got it, thanks.
[17:16] <apw> Laney, whoopsie-preferences as requested
[17:16] <Laney> fanx
[17:17] <JackYu> xnox, since it is in the NEW queue already, should I request another sponsor to review and accept it?
[17:18] <infinity> JackYu: We'll get to it.
[17:19] <JackYu> infinity, wow, great!
[17:29] <Laney> apw: Soz, LP's having a little nap and now I've got to go
[17:29] <Laney> Someone else'll probably get to it
[17:29] <apw> yep, np
[17:30] <Laney> or me if I come back on later
[17:30] <Laney> see you
[17:37] <jamespage> please could the neutron upload for trusty be accepted - I'd quite like to cycle that through our test lab with the rest of the rc packages today
[18:54] <infinity> slangasek: In light of your previous verbal agreement on pulling the IBM branch, can you review the above? ^^
[18:54] <infinity> slangasek: It was tested in a PPA on all arches and then independently on POWER8 as well.
[19:05] <slangasek> infinity: will queuediff eventually give me a diff for that or do I need to download the whole schleblottle?
[19:05] <infinity> slangasek: I see a diff in the queue...
[19:06] <infinity> slangasek: Missing -Q unapproved?
[19:08] <slangasek> infinity: queuediff doesn't take a -Q
[19:09] <slangasek> infinity: ok, diff has shown up now
[19:16] <infinity> cjwatson: Is https://bugs.launchpad.net/maas/+bug/1306164 relevant to partman as well?
[19:16] <ubot2> Launchpad bug 1306164 in MAAS "MAAS fast-path EFI install creates ESP that's too small" [Critical,Fix committed]
[19:17] <rsalveti> slangasek: ^ another simple one (qtlocation-opensource-src)
[19:17] <slangasek> rsalveti: ICMP redirect infinity; I have a few reviews on my plate already
[19:17] <infinity> ;)
[19:19] <rsalveti> slangasek: sure np, just a heads up as this is related with the gl/gles topic
[19:24] <tjaalton> slangasek: I'll reply to the mesa sru email in a bit, but another matter is that I pushed a change to pam adding pam-configs/mkhomedir, disabled by default. it's in bzr
[19:26] <tjaalton> slangasek: it's not of much use for any automatic setup, since pam-auth-update doesn't know how to enable such configs
[19:26] <tjaalton> uninteractively, there's a bug for that I'll try fixing soon
[19:30] <cyphermox> could any archive admin check on the archive machine where the cupstream2distro code runs, to see if it has received a file like "packagelist_rsync_landing-018-trusty" recently?
[19:30] <cyphermox> ci train publishes don't seem to be working atm
[19:30] <cyphermox> robru: ^
[19:31] <cyphermox> I'm currently unable to provide a clearer indication of where this data is supposed to end up though :(
[19:33] <robru> cyphermox, the two logs showing publication are https://ci-train.ubuntu.com/job/landing-018-2-publish/7/console and https://ci-train.ubuntu.com/job/landing-018-2-publish/8/console
[19:33] <robru> but that package hasn't shown up anywhere
[19:33] <robru> cyphermox, also https://ci-train.ubuntu.com/job/landing-019-2-publish/1/console
[19:34] <robru> basically we're looking for phablet-tools and indicator-keyboard, they should have been published but got lost in the ether
[19:34] <cjwatson> infinity: people's usual complaint about partman's are that they're too large, so I don't think so
[19:35] <cjwatson> infinity: partman-auto has the minimum set to 512M
[19:35] <cjwatson> infinity: although there might be a decimal confusion there ...
[19:35] <Laney> cyphermox: I guess it's /home/ubuntu-archive/cu2d/incoming on snakefruit, which is empty
[19:35] <infinity> cjwatson: Oh, if it's already 512M in partman, then this curtin upload matches that.
[19:35] <cjwatson> infinity: I think we may be using 512MB rather than 512MiB though
[19:36] <cjwatson> infinity: but don't have time to investigate tonight
[19:36] <infinity> cjwatson: I think the changelog claimed 100, and I didn't go digging.
[19:37] <cjwatson> Somebody should check whether we're at least 512MiB rather than just MB.  If nobody else does then I will tomorrow.
[19:38] <cyphermox> Laney: thanks
[19:39] <cyphermox> Laney: any idea if something appears to be stuck running there, or something?
[19:39] <Laney> cyphermox: only vaguely educated guess though ...
[19:39] <cyphermox> Laney: it seems reasonable anyway
[19:40] <Laney> sec
[19:41] <cyphermox> Laney: I'm trying to figure out what part is breaking that makes the packages not get really published, so if there's nothing in the incoming directory (seems the right one) on snakefruit, then maybe the jenkins instance is unsuccessful at pushing the rsync files
[19:41] <cjwatson> There's eight auto-accepts running, which is kinda odd
[19:41] <cjwatson> But unrelated
[19:41] <cyphermox> aye
[19:42] <Laney> snakefruit pulls the files
[19:42] <cyphermox> Laney: could you check if maybe the crontab got deleted?
[19:42] <cyphermox> assuming it's as I expect, a cron job running to do this
[19:42] <Laney> it did not
[19:42] <cjwatson> I think LP had a hiccup and a job got stuck
[19:42] <robru> LP certainly had a hiccup...
[19:42] <cjwatson> Just checking, please excuse slow network
[19:42] <Laney> there's an instance of it running
[19:42] <cjwatson> 20814 17:20:01      \_ /usr/bin/python /home/ubuntu-archive/cu2d/cupstream2distro//copy2distro --no-filter
[19:42] <cjwatson> elderly
[19:42] <cyphermox> ah
[19:43] <cyphermox> could well be that yeah
[19:43] <cjwatson> I've killed it
[19:43] <cyphermox> thanks
[19:43] <robru> cyphermox, so do we have to republish now?
[19:43] <cyphermox> robru: let's wait, I expect the next run to pick up the files... hopefully
[19:43] <robru> cyphermox, ok
[19:43] <cjwatson> please don't republish until we've traced
[19:43] <cjwatson> unfortunately I'm uploading grub2 over wet string at the same time ...
[19:44] <cyphermox> cjwatson: in the meantime I'm trying to check which packages we're expecting to see published by citrain that haven't made it yet
[19:44] <robru> cyphermox, it's phablet-tools and indicator-keyboard
[19:46] <cjwatson> ha, there, it hadn't pulled because an old job was stuck
[19:46] <cyphermox> yup
[19:46] <cjwatson> so kill old job -> next one runs and pulls
[19:46] <cjwatson> good
[19:46] <cyphermox> thanks!
[19:47] <robru> cjwatson, Laney, cyphermox: thanks
[19:48] <cjwatson> Laney: sorry if I stepped on your toes, I think I took a while to remember that you had access and I was IRC-lagged ...
[19:48] <cjwatson> (and was half-expecting to have to check the package copy job logs, which are more restricted)
[19:48] <Laney> No worries, glad it was easy enough to sort out
[20:00] <infinity> slangasek: Unsure if thorough review or distracted vorlon.
[20:00] <slangasek> ELUNCH
[20:00] <slangasek> or maybe that's SIGLUNCH
[20:00] <slangasek> back now though
[20:00] <infinity> ELUNCH is so 1998.  It's iLunch now.
[20:02] <infinity> HAHAHA.  Such a shameless copy and paste that I forgot to change the name/.
[20:02]  * infinity rejects and resends the u-d-a one.
[20:02] <Laney> Fix "fozen" too
[20:02] <infinity> <3 fozen.
[20:02] <infinity> I'm half asleep.
[20:06] <infinity> There, slightly less typoey.  My turn for lunch.
[20:12] <elfy> infinity: aah - good, so we're not releasing Saucy Salamander again then :)
[20:13] <infinity> elfy: We could try.
[20:37] <wgrant> cjwatson: That's probably fine.
[20:39] <infinity> slangasek: Oh, there's also the kylin-keyring there that I ping-ponged back to you.
[20:39]  * infinity lunches harder.
[20:39] <slangasek> infinity: yah, am reviewing it now; was just comparing to how other things set up shop under /etc/apt/trusted.gpg.d
[20:40]  * slangasek gets very confused by the output of 'mk-build-deps' telling him this package has no build-deps
[20:40] <infinity> slangasek: I'm not sure if there's a precedent here.  There's apt-add-repository which adds keyrings directly to the directory, but that's cause it's only mangling config, not shipping packaged files.
[20:41] <infinity> slangasek: Shipping in /usr/share and having a non-dpkg-owned symlink felt right to me, since deleting the symlink should be preservable configuration IMO.
[20:41] <slangasek> infinity: debian-archive-keyring installs files directly under /etc, but I don't /like/ that precedent
[20:42] <slangasek> infinity: your maintainer scripts aren't set -e
[20:42] <slangasek> what happens if ln -s fails!
[20:43] <slangasek> (accepting anyway; you can fix it in postproduction :P)
[20:43] <slangasek> infinity: if you happen to have a chance to throw a bzr mp at lp:~ubuntukylin-members/ubuntukylin/ubuntukylin-keyring, I'm sure JackYu and maclin would appreciate it
[20:43] <infinity> Well, now I hope it does fail, just to spite you.
[20:44] <infinity> slangasek: If by "MP", you mean "commit directly, because core-dev obviously has rights", sure!
[20:44] <slangasek> infinity: or that
[20:45] <infinity> Hey neat, did someone just upload firefox in my name? :P
[20:45]  * infinity was holding off on that to batch up some porting fixes, but... Whatever.
[20:46] <robru> any chance we could get unity, indicator-session, and webbrowser-app in before the freeze? they're all bugfixes
[20:46] <robru> (published in citrain earlier today)
[20:47]  * infinity really wishes the queue told me who signed uploads, it's disconcerting to see uploads from me that arent.
[20:54]  * slangasek blinks at the linux package in the queue
[20:55] <infinity> slangasek: You said you wanted half the base system.
[20:55] <infinity> slangasek: We live to give.
[21:01] <cyphermox> infinity: I ship you beer to which address re: this 11-second-late indicator-bluetooth upload? :)
[21:02] <infinity> Looks like you might owe slangasek a beer.
[21:02] <cyphermox> indeed
[21:03] <stgraber> cyphermox: you owe me a beer now, I was the one ignoring the time and clicking accept ;)
[21:04] <slangasek> yeah, wasn't me
[21:04] <cyphermox> stgraber: yeah, but I was obvious telling you about it when it showed up here
[21:04] <cyphermox> stgraber: next lunch at McKibbins ;)
[21:04] <stgraber> sure :)
[21:19] <bdmurray> slangasek: shouldn't we disable apport sending crash reports to launchpad now?
[21:19] <stgraber> 20 minutes ago would have been better, but yes, we should
[21:20] <bdmurray> I'm sorry I was slow thinking about someone else's thing
[21:21] <bdmurray> Anyway, shall I upload it?
[21:22] <Noskcaj> Is https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfburn/bugfixes/+merge/215094 safe to upload? it's a new bugfix release for xfburn
[21:29] <bdmurray> uploaded apport
[21:30] <stgraber> Noskcaj: that package is seeded and we are in final freeze, so my guess would be, no
[21:31] <Noskcaj> ok
[21:31] <slangasek> bdmurray: hmm, did we never get to the point where we keep whoopsie enabled throughout the cycle but keep launchpad disabled by default throughout the cycle?
[21:32] <slangasek> this is probably one of those questions I ask every 6 months and then forget the answer
[21:32] <slangasek> so what's the story with the linux in the queue?  Is that for the first SRU?
[21:32] <bdmurray> slangasek: there is still a fair bit of development that needs to happen on errors for that to be the case
[21:33] <slangasek> bdmurray: ok - sounds like something we should talk about immediately after opening unctuous umbrellastand
[21:34] <gilir> any chances to accept lxsession + lubuntu-default-settings ? They fix some annoying bugs on the lubuntu ISO
[21:36] <stgraber> gilir: so lubuntu-default-settings seems to introduce a new package, yet I don't see anything depending/recommending it, what's the purpose of this?
[21:36] <barry> uvular uakari
[21:37] <gilir> stgraber, it's a new binary to add only on the ISO, it should be only on the seed
[21:37] <gilir> stgraber, it only adds a .desktop to disable light-locker on the ISO
[21:42] <stgraber> ok, accepted that one and will binNEW the package to universe when it's built
[21:43] <infinity> slangasek: No, that's for the archive.
[21:43] <infinity> slangasek: Just not bothering to accept until all the binaries roll in.
[21:44] <stgraber> gilir: lxsession is realistically impossible to review because for a bugfix release it's pretty massive. I assume you tested it well before upload?
[21:44] <gilir> stgraber, thanks
[21:45] <gilir> stgraber, yes, sorry about this, I tested it during last days and it's working fine
[21:46] <Riddell> KDE incoming!
[21:47] <stgraber> gilir: ok, the .vala seems vaguely sane, so I'll accept it
[21:47] <gilir> stgraber, if it's easier, you can check the git tree directly, it's the last 7 commits : http://git.lxde.org/gitweb/?p=lxde/lxsession.git;a=shortlog
[21:48] <stgraber> nah, the diff is fine once you ignore all the generated .c files
[21:48] <stgraber> Riddell: you're aware you're past final freeze right? :)
[21:48] <stgraber> Riddell: you'll owe us at least one beer per package
[21:48] <Riddell> stgraber: too late, kde4libs was in before freeze and so the rest must follow
[21:48] <gilir> stgraber, ok, thanks :-)
[21:49] <slangasek> gilir: while we're at it, there's a lubuntu-artwork in the queue; I don't understand the changelog entry, there are no bugs listed, and we're at the deadline - what should be done with this?
[21:49] <slangasek> Riddell: er, how does it follow that they must be accepted because kde4libs was?
[21:50] <slangasek> infinity: ok, *why* is there a new kernel in the queue, post-kernel-freeze?
[21:50] <slangasek> infinity: since when are we playing fast and loose with the kernel freeze deadlines?
[21:51] <infinity> slangasek: You'd have to ask the kernel team why they felt it was appropriate, but it seemed sane enough (well, sane as can be) when I reviewed it, at least.
[21:52] <gilir> slangasek, it's not critical for the release, just moving a directory in the same binary package (from 1 theme to another), it can be SRUed if you prefer
[21:52] <slangasek> infinity: but the kernel freeze doesn't just exist for the benefit of the kernel team, revving the kernel also impacts the rest of the team during a critical window (because we have to futz with d-i etc)
[21:52] <infinity> slangasek: we have to upload d-i anyway, to be fair.
[21:53] <slangasek> gilir: I don't see how "moving a directory in the package" qualifies under either the SRU or freeze guidelines, maybe you could explain this in terms of user-facing impact?
[21:53] <slangasek> infinity: oh, do we?  For grub, or?
[21:53] <infinity> slangasek: eglibc, grub, flash-kernel, kmod...
[21:53] <slangasek> infinity: heh, ok.
[21:53] <infinity> slangasek: There've been a fair few udebs changed since the last build.
[21:54] <infinity> udev...
[22:01] <stgraber> roaksoax: hey, so you know we're past final freeze right?
[22:01] <gilir> slangasek, basically, metacity theme is currently in an inherited theme, not the main artwork theme. This commit moves the metacity theme to the main artwork theme, so both themes have the settings available (main and inherited). It's not critical because we don't use metacity by default on lubuntu.
[22:02] <stgraber> seems to me kinda late to land new maas features
[22:03] <slangasek> stgraber: there was an FFe request before final freeze, with discussion that took until now to converge on an upload
[22:03] <stgraber> slangasek: ok
[22:04] <slangasek> gilir: ok, so if "it's not critical" I would say it's best to reject this and leave it for 14.10 entirely, unless you want to argue otherwise?
[22:04] <stgraber> slangasek: hmm, the FFe was never acked
[22:04] <stgraber> slangasek: bug 1305839
[22:04] <ubot2> Launchpad bug 1305839 in maas (Ubuntu) "FFe: Support for Third Party Driver Installation" [Critical,New] https://launchpad.net/bugs/1305839
[22:04] <gilir> slangasek, no, I'm fine with rejecting it
[22:05] <slangasek> gilir: ok, rejecting - thanks
[22:06] <slangasek> stgraber: not sure if the FFe ack happened outside the bug, but infinity was involved in the discussion
[22:06] <slangasek> (in fact, he was the one driving the changes required)
[22:08] <stgraber> slangasek: ok, I'll let infinity deal with the upload then
[22:26] <jamespage> is anyone in the release team looking at the neutron upload I put in the queue ~8 hrs ago?
[22:30] <xnox> looks like kubuntu will be bug-free rock-solid by thursday =)
[23:03] <slangasek> jamespage: I'm looking at it now
[23:03] <slangasek> xnox: are you cherry-picking bug #1303891 in?
[23:03] <ubot2> Launchpad bug 1303891 in upstart "new initctl should fallback to old reload signal semantics, if pid1 doesn't export reload dbus method" [High,Triaged] https://launchpad.net/bugs/1303891
[23:21] <xnox> slangasek: yes, had a volleyball match, now back to complete upstart upload.
[23:22] <slangasek> xnox: no spiking the packages over the queue
[23:23] <xnox> =))))))))))))))))))))))))
[23:23] <xnox> slangasek: i dig what you did there.
[23:24] <slangasek> jamespage: looking at this neutron upload, I'm concerned you may have some missing Replaces between neutron-common and neutron-*-agent; conffiles have moved between the packages, but neutron-common doesn't Replace the previous owners
[23:38] <slangasek> jamespage: I've reuploaded neutron with proper breaks/replaces, I think I'd like someone else to review it now before it goes in to make sure I didn't screw anything up
[23:40] <roaksoax> s
[23:41] <roaksoax> slangasek: are we good to accept maas too?
[23:41] <slangasek> tjaalton: yes, I saw your mkhomedir commit, launchpad told me ;)  and yeah, there's no noninteractive way to enable profiles, that's been a longtime request and something it would be great to see fixed
[23:42] <slangasek> roaksoax: I think we were going to let infinity review maas since he's already familiar with the pending changes
[23:42] <slangasek> stgraber: if you're around and can review the neutron reupload, I'd appreciate it
[23:44] <xnox> slangasek: i'm treating all uploads from now on as SRUs, thus requiring bug # references and sru template / test-case in good standing. E.g. would help in case an upload doesn't make into "release" but gets re-diverted to be an SRU.
[23:45] <xnox> infinity: "final release of Saucy Salamander in a week." looks like it's not just timezone challenged =)))))
[23:46] <slangasek> xnox: that will certainly make the release team's job easier when reviewing
[23:57] <JackYu> hi, release team, good morning:)
[23:58] <xnox> JackYu: i still didn't sleep yet =)
[23:59] <JackYu> xnox, I see. You are very busy today. Hope you have a nice weekend:)