[02:20] <mwhudson> vorlon: can you kick grub2 along pls
[02:20] <mwhudson> (at some point in the next 24 hrs, no real hurry!)
[03:51] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu5]
[03:51] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu5]
[03:52] <vorlon> mwhudson: ^^
[04:02] <mwhudson> vorlon: thanks
[04:02] <mwhudson> vorlon: why does that happen, is it just so an AA can check there is a grub-signed upload waiting?
[04:02] <vorlon> mwhudson: it's so that objects don't get signed with the UEFI key without an AA signing off on it
[04:03] <mwhudson> vorlon: ah makes sense
[05:12] -queuebot:#ubuntu-release- New binary: r-cran-ica [amd64] (eoan-proposed/none) [1.0-2-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: r-cran-lsei [i386] (eoan-proposed/none) [1.2-0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: r-cran-lsei [amd64] (eoan-proposed/none) [1.2-0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: r-cran-metap [amd64] (eoan-proposed/none) [1.1-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: r-bioc-tximport [amd64] (eoan-proposed/none) [1.12.3+dfsg-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: r-cran-lsei [s390x] (eoan-proposed/none) [1.2-0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-future.apply [amd64] (eoan-proposed/universe) [1.3.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-tsne [amd64] (eoan-proposed/universe) [0.1-3-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-lsei [armhf] (eoan-proposed/universe) [1.2-0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-lsei [arm64] (eoan-proposed/universe) [1.2-0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-lsei [ppc64el] (eoan-proposed/universe) [1.2-0-1] (no packageset)
=== cpaelzer__ is now known as cpaelzer
[08:05] <mitya57> vorlon: Debian actually ships a fork of compiz, while we ship mainstream compiz. We do not need compiz-plugins-* source packages at all because we build the corresponding binaries from compiz source.
[08:08] <mitya57> I think src:compiz-plugins-experimental should be removed from eoan-proposed and added to sync blacklist.
[08:10] <mitya57> To clarify, upstream compiz is https://launchpad.net/compiz, Debian uses https://gitlab.com/compiz aka compiz-reloaded.
[08:39] <infinity> mitya57: Is there a reason we can't move to using the Debian sources and maintain one less thing in Ubuntu?
[09:13] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-26.27] (core, kernel)
[09:13] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-26.27] (core, kernel)
[09:14] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-26.27] (core, kernel)
[09:16] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-26.27]
[09:16] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-26.27]
[09:16] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-26.27]
=== M_hc[m] is now known as _hc
[10:06] <mitya57> infinity: That would mean erasing 10 years work that Canonical did on refactoring Compiz and rewriting it in C++ (compiz-reloaded is based on compiz 0.8). Also Unity won't work with compiz-reloaded.
[10:08] <infinity> mitya57: "Erasing work" is just sunk cost fallacy rearing its ugly head, but the "won't work with Unity" point is the important bit.
[10:09] <infinity> mitya57: Would still be nice to have Debian and Ubuntu shipping vaguely the same code, but maybe the argument needs to be made in the other direction then.
[10:10] <xnox> well compiz is such an overloaded term..... each series and forks of it, should have had a separate name =/
[10:10] <mitya57> Debian tried 0.9 but then reverted to 0.8, unfortunately I don't know their reasons.
[10:12] <mitya57> The only explanation I can find is in Debian #907640
[10:12] <ubot5> Debian bug 907640 in compiz "compiz: Migrating to compiz-reloaded?" [Important,Fixed] http://bugs.debian.org/907640
[10:12] <mitya57> “The launchpad upstream for compiz has switched to light maintenance mode and will not make further development since Ubuntu has stopped using it.”
[10:15] <mitya57> I am not using compiz or unity myself, so I'm not the person to make any decision about their future.
[11:07] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1014.14] (core, kernel)
[11:12] -queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [i386] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
[11:12] -queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [ppc64el] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
[11:12] -queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [s390x] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
[11:12] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1014.14]
[11:14] -queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [armhf] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
[11:15] -queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [amd64] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
[11:15] -queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [arm64] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
[13:11] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-59.66] (core, kernel)
[13:14] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-59.66] (core, kernel)
[13:44] <tjaalton> can we get a newer meson in bionic, please?
[13:45] <seb128> tjaalton, you could be the one doing that SRU if you need it :)
[13:45] <seb128> I don't think we have a specific maintainer for it
[13:49] <tjaalton> I'll try
[13:50] <seb128> tjaalton, is it strictly needed? for fwupdate we patch out the meson build thing to be able to build with an older version which was easier to do
[13:51] <tjaalton> we miss changes like https://github.com/mesonbuild/meson/commit/12bac512f6497e46ada8ed980cbcb1631506691c which result in asserts in DRI drivers, for instance
[13:51] <seb128> :-/
[13:52] <seb128> the problem is that meson updates include some feature and behaviour changes so that's not really trivial to SRU
[13:53] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-59.66]
[13:53] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-59.66]
[13:56] <tjaalton> could be
[15:11] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-26.27~18.04.1] (kernel)
[15:11] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-26.27~18.04.1] (kernel)
[15:12] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-26.27~18.04.1] (kernel)
[15:17] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-26.27~18.04.1]
[15:17] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-26.27~18.04.1]
[15:17] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-26.27~18.04.1]
[15:51] -queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu3 => 1.7.0-5ubuntu4] (core)
[17:01] -queuebot:#ubuntu-release- Unapproved: rejected thermald [source] (bionic-proposed) [1.7.0-5ubuntu4]
[17:04] -queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu3 => 1.7.0-5ubuntu4] (core)
[17:17] -queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (bionic-proposed) [1.7.0-5ubuntu4]
[17:30] -queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu4 => 1.7.0-5ubuntu5] (core)
[17:44] -queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (bionic-proposed) [1.7.0-5ubuntu5]
[17:56] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1014.14~18.04.1] (kernel)
[17:57] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1041.43] (no packageset)
[17:57] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-160.188] (core, kernel)
[18:36] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1041.43]
[18:36] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-160.188]
[18:36] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1014.14~18.04.1]
[19:16] <teward|web> can someone assist me in figuring out where https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/l/lemonldap-ng/20190815_182233_6ab22@/log.gz is failing?  It's being triggered by the nginx upload but I can't find where the failure exactly happens, nor do I think the failure is nginx /
[19:16] <teward|web>  httpd related
[19:25] <vorlon> teward|web: the first thing to do is check whether the failure also happens without the new nginx
[19:25] <vorlon> and if it is, get the release team to add a 'badtest' hint, and decouple resolving this autopkgtest failure from the nginx package migration
[19:26] <vorlon> teward|web: but I also see the arm64 autopkgtest failed in connection with an apache2 upload, so maybe it's just a flaky test
[19:28] <teward|web> vorlon: right that's what i had thought, the headache I have here is, the same i386 tests pass and its only arm and amd64 that failed
[19:28] <vorlon> sure, hence 'flaky'
[19:31] <teward|web> yep.  going to run the amd64 tests locally, if the ubuntu-daily LXD images speed up.  The storm overhead here doesn't help the internet speed at all either, nor does the fact it knocked out my power long enough for my backup UPSes to die out and my infra to shut off
[19:31] <teward|web> at home
[19:32] <vorlon> well, I've already triggered them on the Ubuntu infra; if they pass the second time, nginx gets let through automatically
[19:32] <teward|web> right, i actually triggered the amd64 earlier after i noticed the regression, and it still returned as a failure
[19:32] <teward|web> still want to test it locally too
[19:32] <vorlon> I only see one amd64 failure listed on http://autopkgtest.ubuntu.com/packages/l/lemonldap-ng/eoan/amd64
[19:33] <teward|web> my poke might still be in the queue
[19:33] <teward|web> it's weird though
[19:34]  * teward|web wonders what deps are defined in the autopkgtests, goes to look
[19:37] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1016.17~18.04.1] (kernel)
[19:37] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1016.17] (core, kernel)
[19:38] <teward|web> vorlon: it LOOKS like the only failure now is amd64
[19:38] <teward|web> xnox repoked it for arm and that seems to have succeeded
[19:39] <vorlon> teward|web: both the failure and the repoke listed there are with apache2 as a trigger, not nginx
[19:40] <vorlon> the nginx/arm64 failure doesn't even show up on the report yet (because the report generation sometimes lags the update_excuses generation)
[19:44] <teward|web> hmm
[19:47] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1016.17~18.04.1]
[19:47] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1016.17]
[19:49] <teward|web> vorlon: ***weird*** that amd64 passed now... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/l/lemonldap-ng/20190815_190300_f0da2@/log.gz
[19:50] <teward|web> that test that failed I *think* is a TOTP test that shouldn't be nginx related I don't think...
[20:18] <doko> sforshee, apw: binutils and gcc-9 blocked by linux autopkg test failures
[20:22] <apw> doko, aware, if those are the last issues for those two package let me knwo and i'll hint them out
[20:22] <doko> apw: they are
[20:29] <apw> doko, hinted
[21:22] -queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu2 => 0.09.25-1ubuntu3] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: libinputsynth [amd64] (eoan-proposed/none) [0.12.1-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: kdeplasma-applets-xrdesktop [amd64] (eoan-proposed/none) [0.12.1-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: pylint-flask [amd64] (eoan-proposed/universe) [0.5-3] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: libinputsynth [i386] (eoan-proposed/none) [0.12.1-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: libinputsynth [arm64] (eoan-proposed/universe) [0.12.1-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: volk [i386] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: volk [amd64] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: libinputsynth [s390x] (eoan-proposed/universe) [0.12.1-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: volk [s390x] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: libinputsynth [armhf] (eoan-proposed/universe) [0.12.1-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: volk [armhf] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: volk [arm64] (eoan-proposed/universe) [2.0.0-2] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: libinputsynth [ppc64el] (eoan-proposed/universe) [0.12.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: volk [ppc64el] (eoan-proposed/universe) [2.0.0-2] (no packageset)