[00:09] -queuebot:#ubuntu-release- Unapproved: emacs25 (zesty-proposed/main) [25.1+1-3ubuntu3 => 25.1+1-3ubuntu4] (ubuntu-desktop)
[00:12] -queuebot:#ubuntu-release- Unapproved: subiquity (zesty-proposed/universe) [0.0.28 => 0.0.29] (no packageset)
[00:13] -queuebot:#ubuntu-release- Unapproved: accepted subiquity [source] (zesty-proposed) [0.0.29]
[00:34] <bdmurray> stgraber: even running sync-lp-bugs in debug I don't see 1675210 being proccessed. http://iso.qa.ubuntu.com/qatracker/reports/bugs/1675210
[01:22] -queuebot:#ubuntu-release- Unapproved: multipath-tools (zesty-proposed/main) [0.6.4-3ubuntu2 => 0.6.4-3ubuntu3] (core)
[03:29] -queuebot:#ubuntu-release- Unapproved: rawtherapee (zesty-proposed/universe) [5.0-1 => 5.0-1ubuntu1] (ubuntustudio)
[05:50] -queuebot:#ubuntu-release- Unapproved: golang-go-xdg (zesty-proposed/universe) [0~bzr20140219-1 => 0~bzr20140219-2] (no packageset) (sync)
[05:51] -queuebot:#ubuntu-release- Unapproved: accepted golang-go-xdg [sync] (zesty-proposed) [0~bzr20140219-2]
[07:27] -queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.5 => 1.11.8-0ubuntu0.6] (ubuntu-desktop)
[08:32] -queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (zesty-proposed) [8.2.1-1ubuntu1]
[08:46] -queuebot:#ubuntu-release- Unapproved: nfs-utils (yakkety-proposed/main) [1:1.2.8-9.2ubuntu1 => 1:1.2.8-9.2ubuntu1.1] (core)
[08:54] -queuebot:#ubuntu-release- Unapproved: nfs-utils (xenial-proposed/main) [1:1.2.8-9ubuntu12 => 1:1.2.8-9ubuntu12.1] (core)
[09:24] <LocutusOfBorg> hello, do you want to see something really nice?
[09:24] <LocutusOfBorg> accept emacs25 from zesty unapproved queue then!
[09:24] <LocutusOfBorg> "25.1+1-3ubuntu4"
[09:24] <LocutusOfBorg> :)
[09:25] <LocutusOfBorg> one line changed, ~25 packages migrating
[10:42] <LocutusOfBorg> apw, ^^^ (emacs25) <3
[10:42] <Laney> The queue's all going to get reviewed
[10:43] <apw> LocutusOfBorg, is someone chasing down why -O2 is borked on arm64 ?
[10:44] <LocutusOfBorg> no, but since it stalls the whole imagemagick stuff I prefer to unblock
[10:44] <LocutusOfBorg> imagemagic needs a new upload to fix CVEs
[10:44] <LocutusOfBorg> apw, I did a lot of testing, and IIRC in a local qemu-pbuilder it is not even failing
[10:45] <LocutusOfBorg> might be some sbuild issue, I can try again in a local build if matters
[10:48] -queuebot:#ubuntu-release- Unapproved: less (zesty-proposed/main) [481-2.1ubuntu1 => 481-2.1ubuntu2] (core)
[10:49] <ginggs> apw: barry said he would forward upstream
[10:50] <ginggs> [00:49:09] <barry> i do plan on reporting this to upstream, even though it might be near impossible for them to repro
[10:51] <ginggs> from #-devel
[11:15] <LocutusOfBorg> cjwatson, my daily hero
[11:16] <LocutusOfBorg> (wrt buildinfo, thanks!)
[11:17] <tjaalton> Laney: onscripter test fail can be reproduced by modifying xvfb-run so that it doesn't clean up after a failure (Xvfb left running), but any other X client works fine with the server, just not this test suite
[11:19] <xnox> apw, infinity: are there any wiki docs w.r.t what the Archive Team do? and/or specifically about NEW review process / requirements?
[11:20] <apw> xnox, i imagine there is a documentation, though there is a lot of common sense applied too
[11:20] <apw> xnox, what are you trying to determine
[11:22] -queuebot:#ubuntu-release- Unapproved: accepted ldns [source] (zesty-proposed) [1.7.0-1ubuntu1]
[11:24] -queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (zesty-proposed) [02.18-0.1ubuntu3]
[11:26] -queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (zesty-proposed) [1.30.4-0ubuntu1]
[11:26] <xnox> apw, i am more after documentation jibberish similar to e.g. MIR requirements page to satisfy some enquiries.
[11:28] -queuebot:#ubuntu-release- New binary: ldns [amd64] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
[11:28] -queuebot:#ubuntu-release- New binary: ldns [s390x] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
[11:28] -queuebot:#ubuntu-release- New binary: ldns [ppc64el] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
[11:28]  * apw defers to infinity on that
[11:29] -queuebot:#ubuntu-release- New binary: ldns [i386] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
[11:30] <tjaalton> Laney: so my point is that since neither Xvfb nor xvfb-run changed between 1.18..1.19 the failure is a non-issue which shouldn't block the migration..
[11:30] <Laney> It's a test which fails using the new xorg-server and passes without
[11:31] <tjaalton> not on all archs
[11:31] <tjaalton> go figure that out then
[11:32] <Laney> Don't be rude.
[11:32] <xnox> infinity, apw: At https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages i found the criteria of "In order for a piece of software to be included in Ubuntu, it must meet the Ubuntu License Policy." which is a link to https://www.ubuntu.com/about/about-ubuntu/licensing and imho is good enough.
[11:32] <Laney> On armhf and s390x the test is running using lxd and lxc respectively
[11:32] <tjaalton> the old xserver was last update mid-december
[11:33] <tjaalton> +d
[11:33] -queuebot:#ubuntu-release- New binary: ldns [arm64] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
[11:33] <tjaalton> let me try a rebuild 1.18 then
[11:33] <tjaalton> rebuilt
[11:35] -queuebot:#ubuntu-release- New binary: ldns [armhf] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
[11:35] -queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (zesty-proposed/main) [15.04.1+17.04.20170322-0ubuntu1.1 => 15.04.1+17.04.20170328-0ubuntu1] (ubuntu-desktop) (sync)
[11:37] <tjaalton> so it only fails on qemu, not on lxd or real hw
[12:57] -queuebot:#ubuntu-release- Unapproved: crash (zesty-proposed/main) [7.1.7-1ubuntu2 => 7.1.8-1ubuntu1] (core)
[13:04] <ahayzen> hey, i was wondering if someone from the release team would be able to look at this FFe request? https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1676436   it basically adds the depends for printing support under unity8, and doesn't affect the unity7 session. I have the changes ready in this silo https://bileto.ubuntu.com/#/ticket/2642
[13:05] -queuebot:#ubuntu-release- Unapproved: indicator-sound (zesty-proposed/main) [12.10.2+17.04.20170208-0ubuntu1 => 12.10.2+17.04.20170328.1-0ubuntu1] (ubuntu-desktop) (sync)
[13:27] <dobey> hi, can i get a poke to approve indicator-sound in zesty please? it's a trivial change we need to make our jenkins behave better, and doesn't actually change anything about the build in the archive itself (other than being rebuilt). thanks
[13:55] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.23.6~14.04] (no packageset)
[13:57] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.1 => 2.23.6] (desktop-core, ubuntu-server)
[13:59] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.1+16.10 => 2.23.6+16.10] (desktop-core, ubuntu-server)
[14:00] -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.23.1+17.04 => 2.23.6+17.04] (desktop-core, ubuntu-server)
[14:52] -queuebot:#ubuntu-release- Unapproved: pbuilder-scripts (zesty-proposed/universe) [21 => 22] (no packageset)
[14:53] <tjaalton> more fun testing onscripter; fails on debian qemu too, and the failure only happens when Xvfb is started from the same shell. and of course it works just fine when trying to strace it...
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted pbuilder-scripts [source] (zesty-proposed) [22]
[14:53] <tjaalton> I'm out of ideas and about to give up
[14:57] <LocutusOfBorg> mterry, why pbuilder-scripts aren't in Debian? :)
[14:57] <LocutusOfBorg> mapreri, ^^^
[14:58] <mterry> LocutusOfBorg: heh because they were always sort of an idiosyncratic method of working and I think sbuild and friends is the recommended pattern.  I'm just stuck in my ways  :)
[14:58] <mapreri> LocutusOfBorg: I have no clue what that thing even is
[14:59] <LocutusOfBorg> mapreri, learn, merge into pbuilder :)
[14:59] <LocutusOfBorg> s/learn/steal :D
[14:59] <mapreri> mterry: I'm the pbuilder maintainer, guess there several idiosyncratic individuals around :P
[15:00] <mterry> mapreri: it's just a set of scripts for working with several distro pbuilders.  I think even pbuilder has a better way of doing that these days.  But I use theses scripts because I have muscle memory for them
[15:01] <mapreri> Well, I fear to say that doing nice enough multidistribution/multiarch work is not yet into pbuilder itself.  I mean, once a chroot is setup usually just changing --basetgz is enough to do everything, but in cases of create and `update --override-config` you alwyas need to either have a huge pbuilderrc, or provide tons of options
[15:02] <mapreri> mterry: I fear everybody had to write their own pbuilderrc (or steal pieces from around, like there is one in the ubuntu wiki)
[15:02] <mapreri> I suppose one day the situation will improve
[15:02] -queuebot:#ubuntu-release- Unapproved: udisks2 (zesty-proposed/main) [2.1.8-1git1 => 2.1.8-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
[15:03] <mterry> mapreri: oh well maybe some of what these scripts do is useful to others then.  I quite like 'pget' which goes into the pbuilder, apt-get's source, and then gives you back the result in your project dir.  Helps when you have pbuilders with weird apt sources
[15:03] <mterry> Also calls apt update so you know you have the latest
[15:03] <mapreri> well my chroots don't have deb-src lines, for example…
[15:04] <mterry> Everyone's setup is idiosyncratic I guess :P
[15:04] <mapreri> heh
[15:17] -queuebot:#ubuntu-release- Unapproved: gnupg2 (zesty-proposed/main) [2.1.15-1ubuntu6 => 2.1.15-1ubuntu7] (core)
[15:25] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (zesty-proposed/universe) [17.04.8 => 17.04.9] (ubuntu-mate)
[15:26] -queuebot:#ubuntu-release- Unapproved: xkeyboard-config (zesty-proposed/main) [2.17-1ubuntu1 => 2.19-1ubuntu1] (core)
[15:31] <bdmurray> stgraber: Did you my last comment about sync-lp-bugs?
[15:32] <stgraber> bdmurray: yeah, no idea why the script isn't syncing that particular bug
[15:34] <bdmurray> stgraber: okay, well thanks for the debuggin help
[15:36] -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (zesty-proposed/universe) [0.76 => 0.77] (ubuntugnome)
[15:39] <stgraber> bdmurray: I believe I put some logic in there not to do changes to bug tasks outside of launchpad.net/ubuntu, since that bug has two tasks, maybe the script is getting confused somehow
[15:52] <slangasek> xnox: so are you driving this systemd upload through to devel?
[15:53] <bdmurray> stgraber: its using staging :-(
[15:53] <xnox> slangasek, well the adt bug appeared indepdant of systemd changes; it was already spotted by linux uploads.
[15:53] <bdmurray> stgraber: on the plus side its tagged there
[15:54] <xnox> at the moment we only know that said test hangs thanks to zesty userspace changes for some reason.
[15:54] <xnox> and yes i will want to get systemd changes into the release.
[15:54] -queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.3 => 1:4.2.8p4+dfsg-3ubuntu5.4] (ubuntu-server)
[15:55] <slangasek> xnox: that's the regression for systemd itself?
[15:55] -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (zesty-proposed/universe) [0.76 => 0.77] (ubuntugnome)
[15:56] <jbicha> please reject the older ubuntu-gnome-meta/zesty
[15:57] <xnox> slangasek, regression of the adt test shipped by systemd; and no it started first without any systemd changes (linux upload first triggered to spot the failure; but kernel has already been ruled out)
[15:57] <slangasek> xnox: so does this mean you're still investigating and trying to resolve it, or should the release team set an override?
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (yakkety-proposed) [1.1.1+bzr982-0ubuntu16.2]
[15:58] <xnox> slangasek, i'd rather add that one test to blacklist and reupload systemd such that all the other tests are still executed.
[15:58] <xnox> (something else is already blacklisted as well, e.g. some selinux thing i believe)
[16:02] <slangasek> rbasak, bdmurray: I'm looking at bug #1665436 (because following through on SRUs that have my name on them ;), and I see the bug was marked incomplete due to autopkgtest failures but nobody tried rerunning the failing test?
[16:03] <slangasek> (via http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#pciutils)
[16:03] <stgraber> bdmurray: hmm, what? how comes it's using staging?
[16:04] <bdmurray> stgraber: I don't know why yet
[16:04] <bdmurray> https://bugs.staging.launchpad.net/ubuntu/+source/ubiquity/+bug/1675210
[16:05] <stgraber> bdmurray: that's just weird...
[16:07] <bdmurray> slangasek: is it the SRU team's duty to investigate every autopkgtest failure?
[16:07] <bdmurray> slangasek: I usually review things without failure first then get to the others when I can, so commenting on them so the uploader looks at it seems reasonable to me.
[16:08] <slangasek> bdmurray: if you're looking at the statu, is it a burden to click the 'retry' button?
[16:09] <slangasek> I'm looking at it now, but that means clicking retry on a bunch of linux autopkgtests, so it'll be hours before they're done and days before I context switch back to looking at these packages
[16:10] <slangasek> also, in this case the failures are linux autopkgtests... which the SRU team is in a better position to have context on than a random SRU uploader (the context is: the kernel autopkgtests pull from a code repo outside of the package, so can regress without obvious archive trigger)
[16:10] <bdmurray> slangasek: there is no retry button the the pending-sru page so sort of
[16:11] <slangasek> right
[16:11] <slangasek> I have suggested we should fix that, perhaps that should be a higher priority :)
[16:12] <bdmurray> maybe a bug report would help
[16:13] <bdmurray> should all failures just be retried automatically one time?
[16:28] <slangasek> bdmurray: do you mean server-side, as opposed to when an SRU team member clicks the button?
[16:28] <slangasek> that might be ok
[16:28] <slangasek> Laney: ^^ do you have any opinions on this?
[16:29] <bdmurray> slangasek: yes, I do
[16:29]  * slangasek nods
[16:29] <slangasek> I think we should also have a 'retry' button on the autopkgtest results page itself
[16:30] <slangasek> so if I've already browsed to http://autopkgtest.ubuntu.com/packages/l/linux/yakkety/armhf and see that pciutils is failed, I should be able to just click next to it to retry with the same params
[16:30] <slangasek> instead of having to navigate elsewhere
[16:31] <bdmurray> yeah, that's crazy
[16:41] <slangasek> and does someone remember the name of the project where we track bugs on the autopkgtest infra?  because https://bugs.launchpad.net/autopkgtest is not it :/
[16:42] <slangasek> right, https://bugs.launchpad.net/auto-package-testing
[16:58] -queuebot:#ubuntu-release- Unapproved: accepted emacs25 [source] (zesty-proposed) [25.1+1-3ubuntu4]
[16:58] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-gnome-meta [source] (zesty-proposed) [0.77]
[16:59] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (zesty-proposed) [0.77]
[17:02] -queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (zesty-proposed) [0.6.4-3ubuntu3]
[17:09] -queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (zesty-proposed) [2.1.8-1ubuntu1]
[17:10] -queuebot:#ubuntu-release- Unapproved: accepted cyrus-sasl2 [source] (zesty-proposed) [2.1.27~101-g0780600+dfsg-2ubuntu1]
[17:11] <sergiusens> rbasak: hey, mind letting snapcraft 2.28 into xenial-updates and yakkety-updates please?
[17:12] -queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (zesty-proposed) [15.04.1+17.04.20170328-0ubuntu1]
[17:17] <dobey> anyone mind accepting indicator-sound into zesty-proposed please?
[17:25] -queuebot:#ubuntu-release- Unapproved: libertine (zesty-proposed/main) [1.7+17.04.20170320.1-0ubuntu1 => 1.7.1+17.04.20170328-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
[17:25] -queuebot:#ubuntu-release- Unapproved: ubuntu-app-launch (zesty-proposed/main) [0.11+17.04.20170321-0ubuntu1 => 0.11+17.04.20170328-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
[17:31] <slangasek> bdmurray, Laney: LP: #1677331 filed
[17:39] <sergiusens> slangasek: can I fallback to you for getting snapcraft 2.28 into {xenial,yakkety}-updates ?
[17:47] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.23.6+17.04]
[17:51] <slangasek> sergiusens: sure, looking
[17:55] <bdmurray> infinity: Let me know what you think of the output in bug 1673557 or the linked OOPS on errors.
[17:57] <infinity> bdmurray: Is the limit still 1k?
[17:57] <infinity> bdmurray: If so, it'll still get filtered sometimes.  The fact that your machine is less fancy than mine shouldn't be the deciding factor.
[17:58] <infinity> bdmurray: Otherwise seems fine.
[17:59] <infinity> barry: I accepted it, but building an entire project with -O0 because (presumably) 1 file is being miscompiled is a rather large hammer. :P
[18:01] <barry> infinity: thanks.  i predict the # of people who care about emacs on arm64 to be 3 or 4 and all of those just want the darn thing to not block other packages ;)  fwiw, i did report this upstream so if they suggest a better fix we can do that
[18:03] <infinity> barry: Well, as bug reports go, "the project miscompiles" is a hard one to action.  Narrowing it down to the problematic file is nicer (but yes, lots of work), and may well prove it's a gcc or binutils bug.
[18:03] <barry> infinity: indeed, esp because it seems completely unreproducible in anything but the arm64 buildds (e.g. we cannot repro on the porter box)
[18:04] <infinity> barry: Anyhow, I agree with the general sentiment, though your number is probably off.  arm64 users today are still people moving over from the embedded crow, the idea that any of them would type "emacs" on purpose seems ludicrous. :P
[18:04] <infinity> barry: But as arm64 server become more popular, maybe weirdoes like you will log into them.
[18:04] <barry> infinity: me and rbalint my buddy in arms <wink>.  but yeah, we wouldn't want emacs to be *too* fast on arm64
[18:05] <infinity> (And, for once, that wasn't me knocking emacs, so much as "modern editors" in general... vim is equally bloated on slow/embedded hardware)
[18:06] <barry> +1
[18:06] <infinity> nvi 4 lyf.
[18:06] <barry> what he sed
[18:07] <dobey> how else are you going to run emacs on a modern phone
[18:07] <infinity> dobey: Step 1: Don't do that.
[18:07] <infinity> dobey: Step 2: Rethink the decisions that brought you here.
[18:07] <infinity> dobey: Step 3: Go for ice cream instead.
[18:08] <dobey> it's called "convergence" man
[18:08] <dobey> get used to it :)
[18:08] <barry> 0. type 'emacs'
[18:08] <infinity> :)
[18:08] <barry> 1. rethink the decisions that brought you here
[18:08] <barry> 2. go for ice cream
[18:08] <barry> 3. take a nap
[18:08] <barry> 4. take another nap
[18:08] <barry> 5. watch emacs start
[18:09] <bdmurray> infinity: yeah, the limit is 1k. Would you want this SRU'ed?
[18:09] <dobey> 0. get a tripod to hold your ice cream, because you're going to need both hands for emacs keybindings
[18:09] <infinity> dobey: I wasn't implying at all that emacs shouldn't be performant on arm64 (it very much should be), but that the *current* set of arm64 users are mostly people from a pre-holy-crap-arm-is-fast-now world, and thus probably don't run emacs. :P
[18:10] <infinity> bdmurray: I think we should SRU it, but only after we're pretty sure we'll catch all the data (which a 1k limit won't). :/
[18:10] <dobey> anyway
[18:10] <infinity> bdmurray: Since one of the primary motivators here is 100% coverage for faux metrics about who's running what hardware.
[18:10] <bdmurray> infinity: right
[18:11]  * dobey just wants (his trivial change) to be accepted :-/
[18:11] <infinity> bdmurray: I'm betting your cpuinfo is only a few chars shy of 1k, and last I checked, mine (cut down to a single CPU stanza) was a few chars over.
[18:11] <infinity> bdmurray: So, as limits go, that one's unfortunately in just the wrong place for this. :)
[18:20] -queuebot:#ubuntu-release- Unapproved: qtmir (zesty-proposed/main) [0.5.1+17.04.20170320.1-0ubuntu1 => 0.5.1+17.04.20170328-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
[18:21] -queuebot:#ubuntu-release- Unapproved: qtmir-gles (zesty-proposed/universe) [0.5.1+17.04.20170320.1-0ubuntu1 => 0.5.1+17.04.20170328-0ubuntu1] (ubuntu-qt-packages) (sync)
[18:21] -queuebot:#ubuntu-release- Unapproved: qtubuntu (zesty-proposed/main) [0.64+17.04.20170320-0ubuntu1 => 0.64+17.04.20170328.1-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
[18:21] -queuebot:#ubuntu-release- Unapproved: qtubuntu-gles (zesty-proposed/universe) [0.64+17.04.20170320-0ubuntu1 => 0.64+17.04.20170328.1-0ubuntu1] (ubuntu-qt-packages) (sync)
[18:21] -queuebot:#ubuntu-release- Unapproved: unity8 (zesty-proposed/main) [8.15+17.04.20170321-0ubuntu1 => 8.15+17.04.20170328.3-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
[18:45] -queuebot:#ubuntu-release- Unapproved: pulseaudio (zesty-proposed/main) [1:10.0-1ubuntu1 => 1:10.0-1ubuntu2] (core)
[18:57] -queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu2 => 2.20.4-0ubuntu3] (core)
[19:05] <nacc> infinity: should i mark 12.04, 12.04.1 and 12.04.5 as eol on april 28, 2017 on https://wiki.ubuntu.com/Releases?
[19:05] -queuebot:#ubuntu-release- Unapproved: sane-backends (zesty-proposed/main) [1.0.25+git20150528-1ubuntu2 => 1.0.25+git20150528-1ubuntu3] (desktop-core, ubuntu-server)
[19:07] <nacc> infinity: and should 12.04.2-12.04.4 and 14.04.2-14.04.4 be moved to eol?
[19:09] -queuebot:#ubuntu-release- Unapproved: sane-backends (yakkety-proposed/main) [1.0.25+git20150528-1ubuntu2 => 1.0.25+git20150528-1ubuntu2.16.10.1] (desktop-core, ubuntu-server)
[19:09] -queuebot:#ubuntu-release- Unapproved: sane-backends (xenial-proposed/main) [1.0.25+git20150528-1ubuntu2 => 1.0.25+git20150528-1ubuntu2.16.04.1] (desktop-core, ubuntu-server)
[19:11] <rbalint> barry: since emacs don't have problems on Debian i suspect one of the coming gcc updates will eliminate the workaround
[19:12] <barry> rbalint: that's my suspicion too.  i think we should do a no-change rebuild once aamazing aardvark's toolchain lands
[19:12] <nacc> slangasek: --^ or your opinion on that (releases wiki update)
[19:13] <rbalint> barry: when time permits i would also give a shot to ASAN and UBSAN against emacs if the problem does not go away
[19:14] <infinity> nacc: You can record the exact date if you like.  14.04.2-14.04.4 aren't EOL, however.
[19:14] <barry> rbalint: i also have a couple of hints/questions from upstream worth investigating
[19:14] <infinity> nacc: The kernels they shipped with are, and there's already a link explaining that.
[19:20] <barry> infinity, rbalint, nacc, dannf interestingly, emacs 24.5+1-6ubuntu3 has apparently been in proposed for 47 days.  i didn't notice earlier because i don't use emacs24
[19:21] <infinity> You mean 24.5+1-8ubuntu2?
[19:21] <infinity> It'll migrate when emacs25 is sorted.
[19:21] <barry> infinity: yep, and cool.  upstream is asking about 24.5
[19:24] <rbalint> barry, infinity: I have just tested emacs on an rpi2 and it is perfectly usable, even without daemon mode :-)
[19:24] <rbalint> barry, infinity: it is -O2, however
[19:25] <barry> rbalint: it'd be interesting to see how the -O0 build performs :)
[19:28] <infinity> barry: Based on how much slower the build is going (much of which involves running emacs itself after it's built), I'm guessing -O0 really doesn't perform. :P
[19:28] <infinity> But that's no surprise.
[19:29] <barry> indeed.  and emacs24 was last built in feb.  i don't know if there were any relevant toolchain updates since then, but i'm going to build the current zesty emacs24 in my ppa to see if it now has the same arm64 crash
[19:35] <barry> btw, that traceback is interesting because prev points to ascii "ginning" almost for sure it was "beginning".  so memory corruption
[19:36] <dobey> maybe it just really likes gin
[19:36] <barry> emacs does work better when you're drunk
[19:36] <dobey> indeed
[19:48] -queuebot:#ubuntu-release- Unapproved: whoopsie (zesty-proposed/main) [0.2.54 => 0.2.55] (kubuntu, ubuntu-desktop)
[19:57] -queuebot:#ubuntu-release- Unapproved: python-os-brick (yakkety-proposed/main) [1.6.1-0ubuntu1.1 => 1.6.1-0ubuntu1.2] (openstack, ubuntu-server)
[20:05] -queuebot:#ubuntu-release- Unapproved: python-os-brick (xenial-proposed/main) [1.2.0-2ubuntu0.2 => 1.2.0-2ubuntu0.3] (openstack, ubuntu-server)
[20:32] <nacc> infinity: ack
[20:44] -queuebot:#ubuntu-release- Unapproved: spyder (zesty-proposed/universe) [3.1.3+dfsg1-1 => 3.1.3+dfsg1-2] (no packageset) (sync)
[20:46] -queuebot:#ubuntu-release- Unapproved: accepted spyder [sync] (zesty-proposed) [3.1.3+dfsg1-2]
[20:52] <barry> infinity, rbalint interestingly, i just built zesty's 24.5 in my ppa and arm64 succeeded
[20:52] <barry> i think i'm going to try debian's 25.1 in my ppa just to rule out any ubuntu deltas
[20:54] <infinity> barry: Do we have deltas against the code?  I would have assumed we only had packaging deltas.
[20:55] <barry> infinity: just build-depends differences and the parallel=1.  i honestly can't imagine those make a difference but just want to definitely rule it out
[20:58] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-77-g4a2b2f87-0ubuntu1 => 0.7.9-82-g0e2030ca-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:00] <ginggs> emacs25 has been failing on arm64 since 25.1+1-2ubuntu3 (2016-11-17)
[21:01] <barry> ginggs: that's interesting because 25.1+1-3 is the first one that set REL_ALLOC=no.  but emacs24 also sets REL_ALLOC=no and doesn't crash
[21:02] <ginggs> emcas24 built successfully on arm64 quite a few times since that date
[21:02] <barry> yep
[21:02] <barry> and i *just* built emacs24 again in my ppa and it passed
[21:07] <rbalint> barry: i saw differences in dependencies and buildd config only
[21:11] <barry> rbalint: me too, but upstream was asking so i want to definitively rule that out, even though if it *does* fix things that'll make no sense ;)
[21:20] <nacc> infinity: slangasek: could i get a review of LP: #1671905? now that imagemagick has migrated, this will save us one security update
[21:24] <infinity> nacc: LGTM, go for it.
[21:25] <dobey> infinity: care to poke indicator-sound in zesty unapproved over to proposed? it's a trivial change we need for CI, so roughly no-change rebuild in the archive
[21:25] <infinity> dobey: Looking.
[21:28] -queuebot:#ubuntu-release- Unapproved: accepted indicator-sound [sync] (zesty-proposed) [12.10.2+17.04.20170328.1-0ubuntu1]
[21:30] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu3]
[21:30] -queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (zesty-proposed) [1.0.25+git20150528-1ubuntu3]
[21:30] -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (zesty-proposed) [1:10.0-1ubuntu2]
[21:30] -queuebot:#ubuntu-release- Unapproved: accepted whoopsie [source] (zesty-proposed) [0.2.55]
[21:39] -queuebot:#ubuntu-release- Unapproved: eject (zesty-proposed/main) [2.1.5+deb1+cvs20081104-13.1ubuntu1 => 2.1.5+deb1+cvs20081104-13.2] (core) (sync)
[21:41] <nacc> infinity: thanks
[21:43] <dobey> thanks infinity
[21:46] -queuebot:#ubuntu-release- Unapproved: screen (zesty-proposed/main) [4.5.0-3ubuntu1 => 4.5.0-4ubuntu1] (ubuntu-desktop, ubuntu-server)
[21:54] <barry> well that's a "good" sign.  straight up d/unstable emacs25 also fails on arm64 as expected
[21:54] <nacc> barry: nice :)
[21:56] <barry> same crash
[22:02] <doko> please unblock openjdk-9, nothing uses it, the autopkg test failures are not relevant
[22:10] <infinity> doko: The openjdk-9 that migrated 12 hours ago?
[22:10] <doko> hmm, ok. didn't get an email
[22:10] <doko> ahh, it was a sync
[22:14] <doko> barry: did you identify the file needing O0?
[22:15] -queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:6.9.7.0+dfsg-2ubuntu1 => 8:6.9.7.4+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
[22:15] <barry> doko: no, and i'm not sure how to narrow it down to a single file.  still talking w/upstream tho
[22:16] <doko> barry, having an optimized build, and a -O0 build, and then using half of the O0 built files ... and bisecting ...
[22:16] <doko> but maybe later ... afk now, hopefully 'til early April
[22:17] <barry> doko: that doesn't sound like a lot of fun ;)
[22:17] <barry> doko: okay!  enjoy, ttyl
[22:17] <barry> btw, i do plan on more investigation, including removing -O0 for zesty+1
[22:17] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-84.92] (core, kernel)
[22:17] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-71.92] (core, kernel)
[22:18] -queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-115.162~precise1] (kernel)
[22:18] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-45.48~16.04.1] (no packageset)
[22:18] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-115.162] (core, kernel)
[22:18] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-45.48] (core, kernel)
[22:19] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-71.92~14.04.1] (kernel)
[22:20] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-115.162~precise1]
[22:20] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-115.162]
[22:20] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-71.92~14.04.1]
[22:20] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-84.92]
[22:21] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-45.48~16.04.1]
[22:21] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-45.48]
[22:21] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-71.92]
[22:44] -queuebot:#ubuntu-release- Unapproved: kombu (zesty-proposed/main) [3.0.35-1.1ubuntu1 => 3.0.35+dfsg-2] (ubuntu-server) (sync)
[23:01] <slangasek> robru: hi, you recall LP: #1668353?
[23:02] <slangasek> I have a slew of examples that I just ran across
[23:08] <robru> slangasek: mention them on the bug please. I never fully understood the issue and most of the comments deny it exists
[23:19] <slangasek> robru: already done
[23:19] <robru> slangasek: ok thanks, will take a look
[23:22] -queuebot:#ubuntu-release- Unapproved: python-django (zesty-proposed/main) [1.8.7-1ubuntu9 => 1.8.7-1ubuntu10] (ubuntu-server)