[01:21] -queuebot:#ubuntu-release- Unapproved: kexec-tools (yakkety-proposed/main) [1:2.0.10-2ubuntu1.1 => 1:2.0.10-2ubuntu1.2] (core) [01:22] -queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.1 => 1:2.0.10-1ubuntu2.2] (core) [05:38] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.23.1+16.10] [05:40] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.23.1] [05:41] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.23.1~14.04] [08:53] apw: did you have a look at https://bugs.launchpad.net/ubuntu/+source/openmw/+bug/1671129 ? [08:53] Ubuntu bug 1671129 in openmw (Ubuntu) "remove armhf binaries for openmw to unblock mesa" [Undecided,New] [10:16] -queuebot:#ubuntu-release- New sync: genwqe-user (zesty-proposed/primary) [4.0.18-2] [10:23] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-67.88] (core, kernel) [10:23] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-42.45] (core, kernel) === marcusto_ is now known as marcustomlinson [11:16] -queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer [source] (trusty-proposed) [2:15.201.1-0ubuntu0.14.04.1] [11:17] -queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer-updates [source] (trusty-proposed) [2:15.201.1-0ubuntu0.14.04.1] [11:29] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-67.88] [11:29] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-42.45] [12:15] robru: http://people.canonical.com/~ubuntu-archive/~laney/emails.txt [15:04] slangasek: Is the mongodb autopkgtest failure triggered by init-system-helpers ignorable? [15:05] apw, genwqe-user in zesty new queue is a bugfix only point release; to replace genwqe package which is now finally maintained in debian [15:05] also there are two syncs, so one of them can be killed [15:19] bdmurray: since you're doing SRUs today (right?) could you look at accepting ubuntu-gnome-meta (trusty,xenial,yakkety) and chrome-gnome-shell (trusty) even though it's not been 7 days yet [15:23] jbicha: What was / is the rational for waiving the 7 day period? [15:26] -queuebot:#ubuntu-release- Unapproved: accepted backuppc [source] (xenial-proposed) [3.3.1-2ubuntu3.2] [15:31] because these uploads were originally uploaded to the new queue in January but they were delayed because it was hard to find someone willing/able to upload new packages as SRUs [15:32] and Firefox 52 was released to all Ubuntu versions Monday or Tuesday, triggering the regression fixed by these uploads [15:32] jbicha: part 1 doesn't seem like a great reason, but part 2 does [15:33] right, part 1 is not valid except to explain that I tried to do this sooner [15:35] -queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (yakkety-proposed) [14.2.0-0ubuntu0.16.10.1] [15:35] -queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.1-0ubuntu1 => 3:10.0.2-0ubuntu1] (openstack, ubuntu-server) [15:38] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.4-0ubuntu1] [15:42] -queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.0-0ubuntu1 => 2:9.1.1-0ubuntu1] (openstack, ubuntu-server) [15:49] jbicha: sounds reasonable, I'll have a look shortly [15:53] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.2-0ubuntu1] [15:56] -queuebot:#ubuntu-release- New source: ukui-indicators (zesty-proposed/primary) [1.0.0-0ubuntu1] [16:05] Laney: lgtm, you ready to go live yet? [16:07] robru: ha [16:07] was going to, then I noticed that the email text is no longer necessarily correct [16:08] the is_valid days thing [16:09] also it might be nice to say "Hi," and "Regards, Ubuntu Release Team" but maybe that's just me :) [16:09] and maybe make From have a name [16:09] * Laney bikesheds [16:10] Laney: ok, are you asking me to clean that up or are you on it? [16:11] robru: can you do it, if you don't mind? [16:11] I think only the number of days thing is essential and the others just nice to have but ultimately optional [16:12] no need to MP though, just give me a place to grab it from [16:16] Laney: ok, on it [16:17] ♥ [16:27] -queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.5-0ubuntu0.16.10.1 => 10.2.6-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server) [16:28] is there an AA around who can approve the uefi bits for 4.10.0-12.14 in zesty? [16:30] -queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.5-0ubuntu0.16.04.1 => 10.2.6-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) [16:30] * cyphermox saw the magic U word [16:30] sforshee: (but I can't approve) [16:32] bdmurray: mongodb/armhf is ignorable... which one did I not add to the hints? [16:33] Laney: https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?id=d66116d80948d8ff647dabe60e7ca5b83c4695df [16:34] robru: thanks! [16:35] slangasek: I still see mongodb armhf on the pending sru report [16:35] Laney: yw [16:36] bdmurray: which release? [16:36] * Laney doesn't know this **locals() trick [16:36] slangasek: xenial [16:37] Laney: it's so handy that the next version of python bakes it into the string literals ;-) [16:37] bdmurray: looks like I need to hint mongodb instead of morgodb [16:37] Laney: you know what ** does, right? locals() is just a function that returns local vars in the form of a dict. [16:38] slangasek: fork it! :) [16:38] bdmurray: hint fixed [16:39] Laney: https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep498 I'm perhaps too excited for this ;-) [16:40] robru: yeah I get it, just haven't thought about / seen it before [16:40] 498> ah, that looks nice [16:48] robru: ok, pushed, let's see what happens [16:48] exciting [16:48] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.1.2-0ubuntu1] [16:50] yay [16:52] will need to wait for the current run to finish [16:54] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.2-0ubuntu1] [16:55] Laney: you around later? I have another britney branch I'd like to get reviewed once the dust settles on this one [16:56] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.1-0ubuntu1] [16:58] robru: approximately 62 more minutes [16:59] probably have more than 62 minutes of things to do today too, so any review is likely to be tomorrow :-) [16:59] feel free to find someone else [17:00] -queuebot:#ubuntu-release- Unapproved: accepted swift [source] (yakkety-proposed) [2.10.1-0ubuntu1] [17:01] Laney: ok thanks [17:04] coreycb: Have you looked at the autopkgtest failures here? http://autopkgtest.ubuntu.com/packages/n/neutron/yakkety/s390x [17:08] bdmurray, hi, yes they should be fixed by the version of neutron in the yakkety upload queue [17:09] coreycb: ah, cool [17:11] coreycb: is bug 1668578 fixed in Zesty? [17:11] bug 1668578 in neutron (Ubuntu) "Newton package needs to bump dependency on python-pecan" [Undecided,New] https://launchpad.net/bugs/1668578 [17:11] coreycb: that's also missing some SRU info [17:15] zul, you mind answer bdmurray since that's your work? ^ [17:26] coreycb: sure [17:26] robru: meh, no ConnectionRefusedError on python 3.2 :( [17:27] Nooooooo [17:27] Laney: what's the log? [17:28] NameError [17:31] Laney: yeah but like does the full traceback not show what the original error is so i can catch that instead? [17:31] robru: I don't think there was an error, it's just trying to set up the try: block [17:32] Laney: ok let me refer to the smtplib docs from 3.2 then... [17:32] ah well, there is AttributeError: __exit__ actually [17:32] so maybe smtplib isn't a context manager (in 3.2?) either [17:34] Laney: ugh, yeah, looks like smtplib in 3.2 has a totally different API. give me an hour to totally rewrite email policy then, sigh [17:34] >>> with smtplib.SMTP('localhost') as s: [17:34] ... pass [17:34] ... [17:34] Traceback (most recent call last): File "", line 1, in [17:34] AttributeError: __exit__ [17:34] yeah [17:34] doh [17:34] I'll put this back to dry-run for now ;-) [17:34] Laney: hah, ok thanks [17:35] robru: be good to make it speak both versions if possible in a nice way, so this works if/when we upgrade the box [17:36] Laney: I believe the new smtplib is backwards compatible, but I'll double check [17:37] ok, pushed [17:37] robru: at least not wrt. exceptions, or? [17:38] Laney: I mean I believe the newer python added this context manager feature to smtp lib but kept the old behavior so if I just code it the old way it'll still work when snakefruit is upgraded [17:39] Laney: when I say "backwards compatible" I mean "I expect code written for 3.2 will still work in 3.4". the problem we're having now is that code written for 3.4 is breaking in 3.2 [17:40] robru: Right, but if you catch socket.error and the new one never raises it then that's not ideal? [17:40] Laney: all the new exceptions are backwards compatible as far as I know. [17:40] It's both the context manager thing and the NameError [17:40] ok [17:52] Laney: ok this should do it: https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?h=email-fix-smtp-3.2&id=2dec3ded31b0b22ce05cb47286b1d61ac1fb66cb [17:53] robru: we get socket.error on connection refused [17:54] Laney: I was going off the smtplib documentation in 3.2 which claimed SMTPException was the base exception for all the exceptions it raises [17:55] https://docs.python.org/3.2/library/smtplib.html#smtplib.SMTPException [17:55] I tried it in python3 -i [17:55] alright [17:55] https://paste.ubuntu.com/24147191/ [17:56] Laney: ok https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?h=email-fix-smtp-3.2&id=76183583ec9c8a37ef67c04cbe67c45dcd276b9a [17:59] righto [18:01] wheeee [18:05] is it going to use the From header or the parameter to sendmail()? [18:06] looks like send_message existed in 3.2, not sure why you changed that bit [18:14] Laney: I just went with the 3.2 docs example code which shows it this way. [18:15] Laney: it says it doesn't modify the headers, the extra roreply is just for the mta [18:19] I guess so (just the MAIL FROM) thing - that's not straightforward for me to parse as a non-email-expert [18:20] meh, was hoping for this to have started running already [18:20] * Laney needs to go out [18:21] here we go [18:24] yay, the Release Team loves me and sent me email :) [18:24] "stuck in zesty-proposed for 40.184386574074075 days" :) [18:25] oho [18:25] probably could use an int() :) [18:25] feel free to fix that [18:26] but I can leave home a happy human [18:26] laters [18:26] What [18:26] I could have sworn it is an int [18:27] Laney: thanks [18:27] jbicha: can you forward that to me [18:27] robru: age = int(excuse.daysold) or 0 [18:27] robru: ? [18:28] i guess you want to do that after the stuck check [18:28] nacc: i remember being frustrated in my testing because i wanted to inspect daysold for fractional values and they weren't there [18:28] robru: interesting -- all of my e-mails have fractional values [18:30] nacc: eg if you look at excuses html it's all rounded there [18:30] I guess the tests put in ints but the live data is floats [18:31] robru: ("
  • %d days old\n" % self.daysold) [18:31] robru: maybe due to the formatting? [18:31] robru: whereas you are using it as a string (afaict) [18:32] Yeah [18:32] Oh also there's a traceback in production, great [18:34] robru: and i got a second e-mail 10 minutes later? [18:34] robru: but only for one of the two packages i got an e-mail originally for [18:35] nacc: yes sir! There's a traceback preventing it from saving the list of things it emailed to the current situation is that it's going to resend all emails forever. [18:35] robru: :) [18:35] Laney: slangasek: please change email policy back to dry run [18:39] bdmurray/coreycb: updated [18:39] zul: thanks [18:40] slangasek: https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?id=80d363ffcfa4f4e045a17e6647f0df38001d8f6f need this commit pulled into production ASAP as Laney left with britney in a broken state. [18:44] alright well I officially have no power to fix anything so anybody who is simultaneously a hater of spam and has access to production, if you could just go ahead and push that commit in, that'd be great. [18:44] bbl [19:05] https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?h=fix-traceback&id=e7181465a8f67e767f4eda5d73c78b1ba9b93341 [19:13] robru: so Laney did an end-of-day rollout? :) [19:13] yep [19:14] robru: is there an MP in LP for the above? [19:14] it beats doing it on Friday night though, right? [19:14] slangasek: nope I just pushed the commit. you want an MP? [19:14] robru: please [19:15] robru: especially as I can't find that commit after a 'git remote update' [19:15] (the first one you mentioned) [19:16] slangasek: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/319487 [19:17] robru: why are you using a .0f format instead of casting the input to an int? [19:18] slangasek: because casting to an int will cause the value to be rounded up prior to the time that it's used for comparison. This way we get the full fidelity of the data for the comparison and then only round it for display. [19:18] robru: ok. next problem, you're sending emails with *every p-m run* instead of just notifying users once that their packages are stuck [19:19] how do I put this back into dry-run mode? [19:19] slangasek: no no, it's only sending every time because the traceback prevents the cache from being written [19:19] ah [19:19] slangasek: to go back to dry run there's now a setting in britney.conf [19:20] but I think this MP should fix it based on the traceback I saw [19:20] so maybe just roll it out and hope for the best! [19:21] slangasek: another option is to write the cache after every email sent rather than waiting for the end, but that'll slow it down a bit. [19:22] robru: wrt this address_chooser, I thought we had talked about implementing this correctly using python3-launchpadlib and not rolling out until we could rely on that in snakefruit [19:24] (anyway, pushed now) [19:27] slangasek: I never saw a timeline on the migration of snakefruit to xenial so I assumed it was best not to block on that? I'll port it to python3-launchpadlib once snakefruit is running xenial. [19:28] slangasek: anyways thanks for pushing, I'll keep an eye on the logs to make sure there's no more tracebacks [19:31] robru: I know I specifically said that this should be done using the right lp apis; the snakefruit upgrade needs scheduled by precise EOL [19:33] slangasek: the way I recall that conversation, I asked you when it would happen and you said IS gave us an extension on things not being charmed so it wasn't clear to me when the upgrade would happen. [19:34] that extension is the thing that lets us upgrade snakefruit wholesale to xenial rather than having to break it all up into charmable things [19:34] robru: ok, I never said anything about an extension for when the upgrade would happen, I only said it wasn't going to be charmed in the near future; sorry for the confusion [19:35] slangasek: ok, please do let me know when that upgrade will happen, there's lots of python-3.2-isms I'm eager to crush, not just lplib avoidance. [19:36] robru: python-3.2-isms should be a much lower priority than the fact that the new feature is not consistently sending email to the correct LP contact addresses [19:37] slangasek: normally i would agree with you, but in this case I mean specifically we are carrying a large delta against debian because we've had to backport a lot of things to python 3.2, so crushing 3.2isms is going to decrease our delta from debian, which is generally a good thing [19:37] but *not a priority* [19:38] slangasek: right so I'll fix the email thing the first day and then drop half our delta the second day :-P [19:41] robru: I'm still getting emails [19:41] slangasek: Yeah the last run still had old code, the current run is the first run with the new code [19:42] robru: ok, I see that this batch of emails have the rounding code now and also there are more emails, so that seems sound [19:43] oh, excellent. I was just going off timestamps. [19:43] slangasek: at the end of this run, assuming no more tracebacks anywhere else, you should see the EmailPolicy file written for the first time with all the info about what has and hasn't been emailed [19:44] and then next run, no more spam [19:44] robru: e-mail looks better and it made progress to other packages that i have stuick [19:44] *stuck [19:44] * cjwatson is glad LP has transactional email code :) [19:45] cjwatson: yeah I should have wrote it to write the cache after each mail rather than writing the cache all at once. [19:45] nacc: alright sorry for all the spam [19:45] robru: np! easy to filter [19:45] robru: and i knew about all my packages :) [19:46] nacc: fix them then!!! ;-) [19:46] robru: trying :) [19:46] robru: if anyone actually understood liblog4ada or emacs25, mine would all be fixed :) [19:47] good luck! [20:26] infinity: I think xenial daily builds should be re-enabled; any reason against? [20:44] infinity: so from what I can see, current-triggers was never updated for the zesty cycle and needed to be because there's no inheritance in this file? [20:44] infinity: is this missing from the archive opening checklist? [20:56] oh crap, that lvm2 upload absolutely wasn't meant for the archive [20:56] * stgraber removes [20:57] removed [21:00] powersj: slangasek is looking at your ppc64el smoke test gating right now. thinks it is enabled now. [21:00] jgrimm: thanks! [21:00] and slangasek thanks :D [21:02] powersj, i guess watch for future failures and check that its done the right thing [21:02] will do :) [21:03] thanks sir [21:07] oh please, it's not like there weren't other release team members around to help out [21:14] jbicha: what was the rationale for syncing libdrumstick from experimental? I assume you've gotten email about it being stuck for months in -proposed due to kmidimon, which is unported (Debian bug #849862) [21:15] Debian bug 849862 in kmidimon "kmidimon needs updaing to latest libdrumstick (1.0.2-1)" [Wishlist,Open] http://bugs.debian.org/849862 [21:30] sforshee: done [21:52] slangasek: I synced it because clivejo asked me to, bug 1584310 [21:52] bug 1584310 in libdrumstick (Ubuntu) "New upstream release available" [Wishlist,Fix committed] https://launchpad.net/bugs/1584310 [21:53] jbicha, clivejo: ok, perhaps we should un-sync this until it's migrated out of experimental and someone has dealt with the revdep (kmidimon)? [21:54] ack, Kubuntu needs it for KDE Applications [21:54] minuet [21:54] kmidimon? [21:54] thats ancient [21:54] maybe we should have emailed clivejo instead :) [21:55] that's KDE4 and hasnt been maintained in years! [21:56] acheronuk: did we not put in a request for that? [21:57] last release was 0.7.5 on 28-07-2013 - https://sourceforge.net/projects/kmidimon/files/ [21:58] clivejo: we discussed doing so last week. had slipped my mind though. [21:58] clivejo: why does minuet have a Build-Depends on drumstick but doesn't end up depending on drumstick? [22:00] its a library? [22:04] you said that minuet required the new drumstick so I would have expected one of the minuet packages to depend on libdrumstick1 [22:05] clivejo: kmidimon is still in the Ubuntu (and Debian) archive; this needs follow-through [22:05] or depend on/recommend drumstick-tools? [22:10] I cant get on to alioth to check, so I dont know [22:10] from what I remember debian are still on KDE apps 16.04 [22:10] whilst Kubuntu is shipping with Apps 16.12 [22:12] Neon's packaging auto syncs with debian [22:12] https://packaging.neon.kde.org/applications/minuet.git/ [22:13] master branch will be what debian have [22:14] -queuebot:#ubuntu-release- New sync: libosl (zesty-proposed/primary) [0.8.0-1] [22:15] -queuebot:#ubuntu-release- New: accepted libosl [sync] (zesty-proposed) [0.8.0-1] [22:25] -queuebot:#ubuntu-release- New binary: libosl [amd64] (zesty-proposed/universe) [0.8.0-1] (no packageset) [22:26] with Debian in FF looks like they arent going to release minuet [22:34] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-12.14] (core, kernel) [22:36] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-12.14] [22:42] slangasek: can you actually un-sync libdrumstick [22:42] clivejo: no, someone needs to follow through on kmidimon [22:43] with a fixed upload, or a removal bug [22:46] "ok, perhaps we should un-sync this" <-- so no longer applies? [22:47] even with kmidimon 0.7.5-3build1 in proposed? [22:48] and libdrumstick 1.0.2-1 also in proposed? [22:48] + it turns out minuet -devs did a switcheroo on their required backends, sop new drumstick seem to not be needed for that. [22:52] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.2-0ubuntu1] [22:53] clivejo, acheronuk: oh, sorry - I misread you :-) I thought you asked "unstick" rather than "un-sync" [22:54] no, we mean get rid/purge [22:54] clivejo, acheronuk: yes, I can "un-sync" it by deleting libdrumstick and kmidimon from zesty-proposed, and the next time libdrumstick is updated in unstable we can pull that instead [22:54] is that what you want? [22:54] slangasek: ack [22:55] clivejo, acheronuk: done :) [22:55] TY :) [22:56] Ill take great pleasure purging it from KCI too [22:56] lol. I recall how much of a pain that was! [23:03] jbicha: apology's for the run around :/ [23:06] when I opened that bug it looked like minuet needed that package to build [23:07] slangasek: if you're deletinig kmidimon, then there's no reason libdrumstick needs to be deleted [23:08] because kmidimon was what halted the libdrumstick transition [23:09] unless you meant delete kmetronome and libdrumstick from zesty-proposed [23:14] jbicha: I was deleting them from zesty-proposed, not from zesty. The need for the experimental libdrumstick went away [23:16] slangasek: could you delete kmetronome from zesty-proposed then? [23:19] jbicha: gladly - done [23:26] powersj: https://wiki.ubuntu.com/CurtinUpdates - what counts as a change to existing features that is covered by the curtin exception, without breaking backwards compatibility and requiring SRU approval? [23:27] smoser: ^ while I think [23:27] (from my pov it probably makes sense to just list "bugfixes and new features") [23:28] slangasek: what about test changes? [23:28] otherwise I agree, bug and new features should cover everything else [23:28] sounds like a bugfix to me [23:29] at least, I've never had a problem from the SRU team side with changes to tests [23:31] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu1] [23:42] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (xenial-proposed) [2:9.1.1-0ubuntu1] [23:45] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (xenial-proposed) [1:6.1.1-0ubuntu1] [23:46] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (xenial-proposed) [1:6.1.4-0ubuntu1] [23:49] -queuebot:#ubuntu-release- Unapproved: accepted swift [source] (xenial-proposed) [2.7.1-0ubuntu1] [23:54] -queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (xenial-proposed) [2:8.3.0-0ubuntu2] [23:59] -queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (xenial-proposed) [13.3.0-0ubuntu1]