[00:01] 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] can someone also look at oxide-qt? it was approved earlier [00:07] if you tell me to just do it, I can myself [00:12] I don't suppose there's any chance of bug 1297804 being approved? [00:12] Launchpad bug 1297804 in libpipeline (Ubuntu) "FFe: libpipeline 1.3.0" [Wishlist,New] https://launchpad.net/bugs/1297804 [00:14] cjwatson: approved [00:15] oh, that was quick, thanks :) [01:02] stgraber: That sssd exec is icky... [01:05] 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] stgraber: Why not just start it with -D and expect fork? [01:05] Or expect daemon. [01:05] Whatever. [01:05] infinity: because sssd is also buggy in that case [01:06] stgraber: Err, srsly? [01:06] infinity: as in, it'll daemonize before it's done parsing your config [01:06] 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] 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] stgraber: util/server.c seems to imply and attempt to make that not happen. :/ [01:07] clearly failing :) [01:07] Bleh. [01:07] Seems like it would be worth fixing correctly instead of working around weirdly. [01:08] 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] 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] (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] Wow, it actually scans stdin. That explains why /dev/zero drove it nuts. [01:12] And it reads an EOF as an explicit kill. [01:12] WHO WRITES SOFTWARE LIKE THIS. [01:12] Running stuff in the foreground is generally the right answer with modern inits anyway ... [01:12] cjwatson: It is when it's not written by nutters. [01:12] Well yes [01:13] stgraber: With /dev/null as stdin, did you get "EOF on stdin - terminating"? [01:17] Oh, FFS, how do I configure this to run it? :P [01:22] stgraber: Erm. So, I can't make it die with "sssd < /dev/null" ... [01:22] Oh, maybe -D is the default. === FourDollars_ is now known as FourDollars [01:23] Indeed it is. === superm1_ is now known as superm1 [01:37] stgraber: http://paste.ubuntu.com/7228797/ [01:38] stgraber: That makes it stop doing Very Stupid Things with stdin, and 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] 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] jdstrand: Is it identical to what I reviewed in your PPA before? [01:39] yep [01:40] infinity: that'd seem pretty unlikely, but upstream did write those lines and the stdin handler for some reason after all... [01:40] bit for bit [01:40] jdstrand: Then go nuts. [01:40] thanks! :) [01:40] (it was just a binary pocket copy) [01:40] stgraber: I'd guess it's for debugging. Not even the testsuite uses it, can't fathom why a user would. [01:40] stgraber: Besides, Ctrl-C still works. [01:41] 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] 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] 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] tjaalton: ^ [01:43] stgraber: Does either of you have a good relationship with upstream? [01:43] (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] 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] 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] stgraber: And I can honestly see no reason why it does, except for debugging convenience. [01:45] But.. *shrug* [01:46] 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] infinity: I'll file an upstream bug report now so I can forward your grumpiness where it belongs ;) [01:52] 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] And it could just be luck of job timing that they're not seeing the bug you do with -D. [01:53] bug filed upstream [01:53] * infinity washes his hands of it. [02:15] bdmurray: yeah, early release of 1286161 seems ok to me [02:16] hmm, was qtbase-opensource-src auto-accepted, or did someone else review that? [02:18] I think I accepted the symbols changes [02:18] well, not the gles thing if that's been uploaded [02:19] the previous change [02:19] 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] 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] 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] cjwatson: ah, ok - yeah, it's only the gl side that's been uploaded for now [02:20] slangasek: I don't know why the packaging was made this way... pitti may know. [02:20] ok [02:21] the first part seems to have been bug #1156074 [02:21] 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] the second part is a bug introduced in saucy when trying to avoid restarting logind on upgrades [03:47] slangasek: ^ for qtdeclarative [03:49] 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] (just confirming that my understanding of the patch matches your intent)( [03:50] 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] ok [03:51] accepting [03:51] 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] I know in linaro we had a small library that could do runtime detection and decide gl/gles in runtime [03:52] but not so sure why nobody put a lot of more effort on that [03:52] because glue libraries are messy :-) [03:52] 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] yeah :-) [04:52] 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. === SpamapS_ is now known as SpamapS === maclin_ is now known as maclin === knome_ is now known as knome [08:01] hey release [08:02] could somebody review bamf/compiz/nux in the queue? [08:09] good morning, so today i'm trying to land a few things: [08:09] account-plugins [08:09] webbrowser-app [08:09] and libunity-webapps and related (they come from silo 8) [08:20] Laney, so, nobody reviewed that bamf changes during the night :/ [08:21] I imagine it'll get cleared out before final freeze [08:21] * Laney will look at other things now [08:23] k, fair enough [08:42] seb128: I see compiz, nux and bamf still in the queue - any hope those will move out of UNAPPROVED soon? :) [08:42] sil2100, I do as well [08:42] I pinged about that earlier [08:43] seems like the US team didn't get to those during their shift, let's see if the europeans do [08:43] o/ Thanks [08:44] 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] seb128: Did some, but not many. I'll do a few more before I head to bed. [08:49] seb128: Hard freeze tomorrow (well, tomorrow for me) anyway, so it should slow down after that. :P [08:50] infinity, thanks ... and yeah, "should", I don't see that really happening though [08:50] well, a part of the uploads is going to turn into SRU [08:50] but I can see a steady flow of SRUs between release and .1 [08:51] Inevitably, yeah. Seems to be the way with LTSes. [08:55] 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] slangasek, maclin means the FFe bug #1293299. [08:59] Launchpad bug 1293299 in Ubuntu Kylin "[FFe]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299 [09:37] sil2100, ^ things got accepted, we should have some silos we can m&c in the next publisher runs [09:37] (thanks to whoever did the reviews btw!) [09:37] yw [09:38] would be nice if somebody could review libpipeline (it has an approved ffe now) so that I can sync man-db [09:40] ha, gexiv2 was what I was referring to in #ubuntu-devel [09:40] oh, whoops [09:40] sorry [09:40] I was motivated by seeing several things in p-m that were blocked on it ... [09:40] never mind, fixable [09:40] it'll hit NEW anyway, so you have a chance :) [09:42] * cjwatson suppresses his "auto-NEW stuff from Debian" twitch [09:44] \o/ [09:44] Thanks guys! [09:44] Can't wait for those to migrate out of proposed ;) [09:56] libpipeline> thanks [09:56] * infinity tips hat. [09:57] * infinity falls asleep in hat. [10:30] ^-- Can someone do a quick review of that flash-kernel? [10:31] I'm told it's tested to DTRT, and I verified the strings are correct. [10:32] infinity: LGTM [11:55] possible kde-l10n spam ahead [12:03] 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] doko, it's possible, armhf are triggered when x86 tests pass. I'll restart it. [12:06] (when the build is available) [12:06] need to fix the aarch64 build anyway [12:28] Can someone please poke ima-evm-utils through NEW? === Ursinha is now known as Ursinha-afk [13:58] could the neutron upload in proposed be rejected please - I missed a bit [13:58] jamespage: Done. [13:58] infinity, thanks [14:14] 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] Laney: it should be easy enough to review :) [14:14] https://code.launchpad.net/~dbarth/webbrowser-app/notitle/+merge/215166 [14:14] (and there is a new unity8 coming which will need a bump in the fauxpackage) [14:18] didrocks: ok, sec [14:20] thanks man :) === Ursinha-afk is now known as Ursinha === pete-woods1 is now known as pete-woods [14:37] Laney: lost in space and time? :p [14:39] have patience my child [14:42] thanks Laney [14:43] np! [14:50] slangasek: did you want to release ubuntu-release-upgrader to saucy-updates or shall I? [14:50] bdmurray: please go ahead [14:54] infinity, neutron with missing bits included now in the queue [14:55] jamespage: I assume that means you added bits, not that more are missing? :P [14:55] infinity, I did indeed add the missing bits :-) [15:04] Any core-dev around, that could lend us some upload rights? Bug 1291675 [15:04] Launchpad bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675 [15:04] This package has some major improvements to the released one. Has been tested and is pretty much ready to go. [15:15] zequence: Wasn't ScottK asking you about that last night? [15:16] infinity: Yep. He approved it as a FFe. There was a repackaging since [15:24] I probably ought not to review gnome-screensaver since it's my own [15:24] Would appreciate it being looked at [15:26] accepted gnome-screensaver [15:27] Cheers [15:27] happy mostly working lockscreen [15:27] that fixes the double-lock? [15:27] unity mainly, but that has a hand [15:28] 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] (Which is quite a neat facility in D-Bus that I wasn't familiar with) [15:28] right [15:44] 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] roaksoax: why is bug #1294323 private? public bugs only for FFes, please [15:45] slangasek, hi, we don't have the rights to upload it. [15:46] slangasek, and neither happyaron... [15:46] JackYu: understood; so you don't have any sponsor lined up for this? [15:47] slangasek, yep, that's the situation:( [15:47] ok [15:47] let me see what I can do about that [15:47] slangasek, great, thanks. [15:49] 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] JackYu: right. I've uploaded ubuntukylin-keyring, it's in the NEW queue now and should get review from another archive admin [15:50] infinity: ^^ could you slot that in maybe? [15:50] Phrasing. [15:51] slangasek: So, this is the keyring with the agreed-upon generated-by-IS key? [15:51] infinity: that's what I'm claiming [15:52] slangasek: Can I independently validate this key in the DC somewhere? [15:52] slangasek: yeah I filed a different public bug [15:52] infinity: you can check it against the RT [15:52] infinity: RT #69080 [15:52] slangasek: Ta. [15:57] slangasek: Is this just a cargo-cult of ubuntu-keyring? [15:58] infinity: yes, as noted in the linked FFe bug [15:58] Oh, who reads bugs? [15:59] 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] slangasek: Is it expected that installing this keyring makes apt trust it, or will an installer mangle that? === maclin_ is now known as maclin [16:13] infinity: isn't that what the postinst does? (apt-key update) [16:14] slangasek: You'd think. [16:14] slangasek: Maybe it doesn't like ascii armored keys and wants an actual keyring? [16:14] JackYu: xnox is reviewing ubuntu-kylin-software-center now for sponsorship [16:14] infinity: ah; I would think that and did think that, but did not in fact test it [16:15] slangasek, xnox, thanks. maclin and I are here waiting for your questions:). [16:18] JackYu: so far it's ok, one minor dependency is missing which i'll fix up before uploading. [16:19] JackYu: and i'm writting up review comments on the bug report. [16:19] JackYu: no blocking issues found yet, but i'm not done reviewing. [16:19] who do I bribe to push unity8 through to release? ;) [16:19] 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] Saviq: I'll sort it. [16:20] infinity, awesome, thanks, infinity.beer++ [16:20] xnox, got it. [16:21] I'll take a raincheck on the beer. [16:22] the xen and libvirt combination are best viewed together and are a fix for the migration of machine definitions on upgrade [16:26] 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] JackYu: he is reviewing and once he is done reviewing, if there are no blocking problems, he will upload [16:28] slangasek, ah:). [16:30] 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] slangasek: Shipping it in /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg works, though. [16:31] 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] 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] slangasek: Sure, I can do that. [16:39] infinity: do you intend to generate the binary keyring at build time, OOI? [16:40] slangasek: We don't seem to for ubuntu-keyring. [16:42] infinity: yeah; I would argue that this is a bug in ubuntu-keyring too :) [16:42] slangasek: Perhaps, yeah. But I'm not sure it's one I want to fix this instant. [16:42] slangasek: We can do both together some day. [16:42] yep [16:42] slangasek: Not like an .asc is really any more readable than a .gpg, it's just more vi-friendly. [16:42] just makes it a little harder for me to review and make sure you're not MITMing me ;) [16:44] grub2 won't be until early tomorrow morning I suspect, by the time I've built this, uploaded to Debian, and synced [16:47] The grub2 patch will be http://paste.ubuntu.com/7231546/ unless something goes horribly wrong for some reason [16:48] I guess I could hack the .changes and upload the exact same thing to Ubuntu if people think I should [16:48] Would be nicer to have the proper audit trail though [16:49] cjwatson: Letting the sync happen $later seems fine. [16:53] 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] considering Debian was discussing reducing dinstall back down to daily, we should probably think about getting better syncing support from incoming [16:54] Yes, I agree on that [16:56] To sync securely from incoming, all we need is access to the buildd repo. [16:57] Incoming is signed these days, isn't it? [16:57] We probably just have to ask nicely, and retool the LP sync stuff. [16:57] cjwatson: incoming isn't, but incoming/buildd is. [16:57] Oh, right [16:57] Dunno if it would need that much retooling, it could just be another suite? [16:58] slangasek: Okay, try that one on for size. [16:58] I assume incoming/buildd is only private so that the world doesn't add it to their apt sources [16:59] infinity: I have a call now, it'll be a couple hours before I can look at it - is that ok? [16:59] slangasek: Doesn't bug me. [17:00] cjwatson: Yeah, pretty sure that was the reasoning. And so we could unaccept if really, really necessary. [17:00] 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] (or revert manually, or whatever) [17:01] 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] cjwatson: Yeah, that seems ideal to me. [17:01] gina will do its usual tracking of what's in what suites without much trouble AFAICS [17:02] wgrant: ^- any qualms with the above? otherwise I can go ask ftpmaster [17:03] cjwatson: Assuming we poll something not too unfriendly, I can't see that they'd mind. I hope. [17:04] I was thinking hourly [17:04] 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] The queue runs every 15 or 20, doesn't it? [17:04] I always forget. [17:04] And it'd be debmirror, but could be debmirror over HTTP if buildds don't get rsync [17:04] Not sure [17:05] cjwatson: Well, we could check a cached Sources for freshness, then trigger a mirror, I assume. [17:05] Though, I imagine debmirror has such a facility anyway. [17:05] debmirror fetches Packages/Sources and only grabs what it doesn't have [17:05] * infinity nods. [17:05] And we only want Sources, so just that. [17:06] Er right [17:06] So --arch=none [17:07] 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] 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] Could just ask what's reasonable, indeed. [17:09] Possibly also IP limited, now that DSA demands buildds not be on sketchy cable modems. :P [17:10] 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] Ahh, phew. "Good" news. That testsuite regression on POWER8 isn't a regression. Breaks in the old version too. [17:11] xnox, got it, thanks. [17:16] Laney, whoopsie-preferences as requested [17:16] fanx [17:17] xnox, since it is in the NEW queue already, should I request another sponsor to review and accept it? [17:18] JackYu: We'll get to it. [17:19] infinity, wow, great! [17:29] apw: Soz, LP's having a little nap and now I've got to go [17:29] Someone else'll probably get to it [17:29] yep, np === HoloIRCUser is now known as zhangchao [17:30] or me if I come back on later [17:30] see you [17:37] 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] slangasek: In light of your previous verbal agreement on pulling the IBM branch, can you review the above? ^^ [18:54] slangasek: It was tested in a PPA on all arches and then independently on POWER8 as well. [19:05] infinity: will queuediff eventually give me a diff for that or do I need to download the whole schleblottle? [19:05] slangasek: I see a diff in the queue... [19:06] slangasek: Missing -Q unapproved? [19:08] infinity: queuediff doesn't take a -Q [19:09] infinity: ok, diff has shown up now [19:16] cjwatson: Is https://bugs.launchpad.net/maas/+bug/1306164 relevant to partman as well? [19:16] Launchpad bug 1306164 in MAAS "MAAS fast-path EFI install creates ESP that's too small" [Critical,Fix committed] [19:17] slangasek: ^ another simple one (qtlocation-opensource-src) [19:17] rsalveti: ICMP redirect infinity; I have a few reviews on my plate already [19:17] ;) [19:19] slangasek: sure np, just a heads up as this is related with the gl/gles topic [19:24] 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] 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] uninteractively, there's a bug for that I'll try fixing soon [19:30] 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] ci train publishes don't seem to be working atm [19:30] robru: ^ [19:31] I'm currently unable to provide a clearer indication of where this data is supposed to end up though :( [19:33] 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] but that package hasn't shown up anywhere [19:33] cyphermox, also https://ci-train.ubuntu.com/job/landing-019-2-publish/1/console [19:34] basically we're looking for phablet-tools and indicator-keyboard, they should have been published but got lost in the ether [19:34] infinity: people's usual complaint about partman's are that they're too large, so I don't think so [19:35] infinity: partman-auto has the minimum set to 512M [19:35] infinity: although there might be a decimal confusion there ... [19:35] cyphermox: I guess it's /home/ubuntu-archive/cu2d/incoming on snakefruit, which is empty [19:35] cjwatson: Oh, if it's already 512M in partman, then this curtin upload matches that. [19:35] infinity: I think we may be using 512MB rather than 512MiB though [19:36] infinity: but don't have time to investigate tonight [19:36] cjwatson: I think the changelog claimed 100, and I didn't go digging. [19:37] Somebody should check whether we're at least 512MiB rather than just MB. If nobody else does then I will tomorrow. [19:38] Laney: thanks [19:39] Laney: any idea if something appears to be stuck running there, or something? [19:39] cyphermox: only vaguely educated guess though ... [19:39] Laney: it seems reasonable anyway [19:40] sec [19:41] 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] There's eight auto-accepts running, which is kinda odd [19:41] But unrelated [19:41] aye [19:42] snakefruit pulls the files [19:42] Laney: could you check if maybe the crontab got deleted? [19:42] assuming it's as I expect, a cron job running to do this [19:42] it did not [19:42] I think LP had a hiccup and a job got stuck [19:42] LP certainly had a hiccup... [19:42] Just checking, please excuse slow network [19:42] there's an instance of it running [19:42] 20814 17:20:01 \_ /usr/bin/python /home/ubuntu-archive/cu2d/cupstream2distro//copy2distro --no-filter [19:42] elderly [19:42] ah [19:43] could well be that yeah [19:43] I've killed it [19:43] thanks [19:43] cyphermox, so do we have to republish now? [19:43] robru: let's wait, I expect the next run to pick up the files... hopefully [19:43] cyphermox, ok [19:43] please don't republish until we've traced [19:43] unfortunately I'm uploading grub2 over wet string at the same time ... [19:44] 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] cyphermox, it's phablet-tools and indicator-keyboard [19:46] ha, there, it hadn't pulled because an old job was stuck [19:46] yup [19:46] so kill old job -> next one runs and pulls [19:46] good [19:46] thanks! [19:47] cjwatson, Laney, cyphermox: thanks [19:48] 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] (and was half-expecting to have to check the package copy job logs, which are more restricted) [19:48] No worries, glad it was easy enough to sort out [20:00] slangasek: Unsure if thorough review or distracted vorlon. [20:00] ELUNCH [20:00] or maybe that's SIGLUNCH [20:00] back now though [20:00] ELUNCH is so 1998. It's iLunch now. [20:02] 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] Fix "fozen" too [20:02] <3 fozen. [20:02] I'm half asleep. [20:06] There, slightly less typoey. My turn for lunch. [20:12] infinity: aah - good, so we're not releasing Saucy Salamander again then :) [20:13] elfy: We could try. [20:37] cjwatson: That's probably fine. [20:39] slangasek: Oh, there's also the kylin-keyring there that I ping-ponged back to you. [20:39] * infinity lunches harder. [20:39] 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] 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] 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] infinity: debian-archive-keyring installs files directly under /etc, but I don't /like/ that precedent [20:42] infinity: your maintainer scripts aren't set -e [20:42] what happens if ln -s fails! [20:43] (accepting anyway; you can fix it in postproduction :P) [20:43] 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] Well, now I hope it does fail, just to spite you. [20:44] slangasek: If by "MP", you mean "commit directly, because core-dev obviously has rights", sure! [20:44] infinity: or that [20:45] 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] any chance we could get unity, indicator-session, and webbrowser-app in before the freeze? they're all bugfixes [20:46] (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] slangasek: You said you wanted half the base system. [20:55] slangasek: We live to give. === infinity changed the topic of #ubuntu-release to: Released: Trusty Final Beta | Archive: Final Freeze | Trusty Tahr Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis [21:01] infinity: I ship you beer to which address re: this 11-second-late indicator-bluetooth upload? :) [21:02] Looks like you might owe slangasek a beer. [21:02] indeed [21:03] cyphermox: you owe me a beer now, I was the one ignoring the time and clicking accept ;) [21:04] yeah, wasn't me [21:04] stgraber: yeah, but I was obvious telling you about it when it showed up here [21:04] stgraber: next lunch at McKibbins ;) [21:04] sure :) [21:19] slangasek: shouldn't we disable apport sending crash reports to launchpad now? [21:19] 20 minutes ago would have been better, but yes, we should [21:20] I'm sorry I was slow thinking about someone else's thing [21:21] Anyway, shall I upload it? [21:22] 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] uploaded apport [21:30] Noskcaj: that package is seeded and we are in final freeze, so my guess would be, no [21:31] ok [21:31]