[02:23] <tsimonq2> infinity, slangasek: Can haz merge? :) https://code.launchpad.net/~wxl/debian-cd/ubuntu/+merge/353762
[02:24] <tsimonq2> wxl's not wrong. XD
[04:08] <slangasek> tsimonq2: done
[04:10]  * slangasek frowns at tests being queued in the huge queue that shouldn't be
[04:22] <tsimonq2> slangasek: Does prod have the changes (so I can kick off a respin)?
[04:23] <slangasek> tsimonq2: it does
[04:23] <tsimonq2> slangasek: Awesome, thanks.
[05:35] <slangasek> so are any rust packages installable anywhere? because you wouldn't think so by looking at update_excuses
[06:40] <tsimonq2> pytest is close; python-ulmo just needed a test retry and hovercraft will likely pass soon because it failed on dep problems... I wish I could make pytest migrate but I just can't seem to doit/0.31.1-1 </horrible pun> :D
[06:45]  * acheronuk groans ^^
[07:13] <ginggs> tsimonq2: fwiw, i filed debian bug #907379
[07:13] <ubot5> Debian bug 907379 in src:doit "doit: autopkgtest regression" [Normal,Open] http://bugs.debian.org/907379
[07:15] <tsimonq2> ginggs: You beat me to it! :D
[07:15] <tsimonq2> ginggs: Thanks.
[07:15] <tsimonq2> ginggs: (Was seriously >< this close to submitting my own.)
[07:19] <tsimonq2> ginggs: Do you have a lead on what could be causing this? https://github.com/pytest-dev/pytest/issues/3061 seems to be the closest thing in the upstream changelog.
[07:19] <gitbot> pytest-dev issue 3061 in pytest "ImportWarning: can't resolve package from __spec__ or __package__" [Plugin: Debugging, Plugin: Warnings, Topic: Collection, Closed]
[07:20] <tsimonq2> But there was also rework of that code upstream right before this.
[07:23] <ginggs> tsimonq2: no idea, I thought this looked promising https://github.com/pydoit/doit/commit/b40ad81ae4f2ebec1964c4b0da5ac9146c7ffc03
[07:23] <ginggs> but it is already in the debian packaging
[07:23] <ginggs> tsimonq2: did you try with doit straight from git?
[07:24] <tsimonq2> ginggs: Upstream seems to have Travis set up with an old pytest, so I think it's pytest, but I can try from Git.
[07:24] <tsimonq2> I don't believe there is anything pertinent in there.
[07:27] <tsimonq2> Yeah, I don't think it's the right tree to be barking up.
[07:27] <tsimonq2> If anything I'm very likely to just Git bisect the pytest packaging and find out where the code is that makes it fail.
[07:28] <tsimonq2> Maybe there's some downstream adjustments necessary.
[07:28] <tsimonq2> (s/Maybe/It's very likely that/)
[07:35] -queuebot:#ubuntu-release- New sync: cmake-vala (cosmic-proposed/primary) [1-1]
[09:01] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-158.208] (core, kernel)
=== Guest10613 is now known as RAOF
[09:24] <tsimonq2> Oh noes, I actually uploaded that to the archive /o\
[09:25] <tsimonq2> I shouldn't actually be able to upload something to the archive with ~ppa in the version string... yikes.
[09:26]  * tsimonq2 switches to dput-ng
[09:41] <smb> Could someone here add linux-azure to the "kernel" package set for trusty?
[09:46] <sil2100> smb: on it
[09:46] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-158.208]
[09:46] <smb> sil2100, ah u2 :) thanks
[09:47] <sil2100> smb: hm, I guess I'll also add linux-signed-azure to the xenial packageset, since it seems to be missing there
[09:48] <sil2100> smb: done
[09:48] <smb> sil2100, oh, guess, that and meta, and same for trusty
[09:49] <smb> sil2100, normally we have the tracking bugs only for the kernel package, so won't notice missing nomination abilities for the other ones
[09:49] <smb> sil2100, and uploads are indirect anyway
[09:51] <smb> sil2100, all looking in sync and good now, thanks
[10:05] -queuebot:#ubuntu-release- Packageset: Added linux-azure to kernel in trusty
[10:05] -queuebot:#ubuntu-release- Packageset: Added linux-meta-azure to kernel in trusty
[10:05] -queuebot:#ubuntu-release- Packageset: Added linux-signed-azure to kernel in trusty
[10:05] -queuebot:#ubuntu-release- Packageset: Added linux-signed-azure to kernel in xenial
[11:21] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.2 => 0.130ubuntu3.3] (core)
[11:21] -queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.3]
[11:24] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.3]
[11:28] <mwhudson> tsimonq2: https://gist.github.com/mwhudson/616499edb1191bd99c987bbbd8781ce9
[11:29] <mwhudson> oh wait i made a repo, https://github.com/mwhudson/dput-wrap
[12:30] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2 => 1:0.5.2.1] (desktop-core, ubuntu-server)
[14:30] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.5]
[14:36] -queuebot:#ubuntu-release- New source: kubernetes (cosmic-proposed/primary) [1.0]
[15:00] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (bionic-proposed) [5.2.10-3ubuntu18.04.2]
[15:05] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.4]
[15:16] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.4] (core)
[15:35] -queuebot:#ubuntu-release- Unapproved: openssh (xenial-proposed/main) [1:7.2p2-4ubuntu2.4 => 1:7.2p2-4ubuntu2.5] (core)
[15:39] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.4]
[15:43] -queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (xenial-proposed) [5.4.0-6ubuntu1~16.04.11]
[16:00] -queuebot:#ubuntu-release- Unapproved: accepted yaml-cpp [source] (xenial-proposed) [0.5.2-4ubuntu1~16.04.4]
[16:03] -queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.15-0ubuntu1~18.04.1]
[16:12] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.4] (core)
[16:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.4]
[16:15] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (xenial-proposed) [1:5.1.6~rc2-0ubuntu1~xenial4]
=== bdmurray_ is now known as bdmurray
[16:45] -queuebot:#ubuntu-release- Unapproved: rax-nova-agent (xenial-proposed/universe) [2.1.12-0ubuntu2~16.04.0 => 2.1.15-0ubuntu1~16.04.0] (no packageset)
[17:05] <slangasek> infinity: well then, why does glibc 2.28 cause cminpack to regress its test suite involving numeric operations?
[17:16] <slangasek> retrying all the failed autopkgtests with glibc, both with --no-proposed and without
[17:25] -queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (xenial-proposed) [2.1.15-0ubuntu1~16.04.0]
[17:30] <infinity> slangasek: Either a bug in glibc or a bug in the testsuite?
[17:30] <slangasek> infinity: nothing number-y changed in glibc 2.28 of note?
[17:30] <infinity> slangasek: My bet would be on a testsuite expecting a specific amount of lack of precision, and libm getting more accurate, but let's see.
[17:31] <slangasek> grep uploaded to make it not complain that glibc got better
[17:32] <infinity> slangasek: libm's badness improves pretty much every release, to some degree, but no major noteworthy things, I don't think.
[17:33] <slangasek> alright.  whatever happened, it happened cross-architecture
[17:33] <infinity> Well, except for this, but I read this literally as "added functions", so hard to see how that would break un-rebuilt binaries:
[17:33] <infinity> * <math.h> functions that round their results to a narrower type are added
[17:33] <infinity>   from TS 18661-1:2014 and TS 18661-3:2015:
[17:34] <infinity> Oh, no.  That's now how to read that.
[17:34] <infinity> This may indeed be a case of increased accuracy.
[17:35] <infinity> Except, wow, I have no idea what that testsuite output actually means. :P
[17:36] <infinity> I'll final l2 norm YOUR residuals.
[17:37] <wxl> slangasek: thanks for merging my new lubuntu logos for ubuntu-cdimage.. today's daily shows the boot menu as black though, which is.. perplexing. any ideas?
[17:37] <infinity> slangasek: The "approximat solutions" deltas seem plausibly similar at least.
[17:37] <slangasek> wxl: no, I know almost nothing about this part of the image bot
[17:37] <slangasek> boot
[17:37] <wxl> slangasek: got any suggestions as to who might be good to chat with?
[17:38] <slangasek> wxl: cjwatson?  to be clear, are you saying that it's black where the logo should be instead?
[17:38] <wxl> slangasek: yeah, and the blue background that's part of the image is missing
[17:39] <infinity> slangasek: And cminpack upstream hasn't seen a commit in over a year.  Excellent.
[17:40] <infinity> slangasek: Odd on "Debian Science" actually understanding it well enough to field a bug? :P
[17:40] <slangasek> no idea
[17:41] <infinity> Hrm.  And while it's reasonably leafy, it does have a little bit of an rdep chain.
[17:41] <infinity> Bother.
[17:41] <infinity> Guess I'll file a bug and hope for comments.
[17:41] <infinity> My gut says it's just different rounding and a too-specific testsuite.
[17:42] <infinity> Based on the "solutions" bits.
[18:43] <LocutusOfBorg> anybody, can please tell me if it is ok to drop libxml2-udeb package?
[18:44] <LocutusOfBorg> it breaks migration-assistant, and then it is not migrating
[18:44] <LocutusOfBorg> but somebody is telling that migration assistant is broken because it depends also on other non-udeb packages...
[18:44] <LocutusOfBorg> who is correct? (sorry but I don't speak udeb)
[18:46] <infinity> Err, wat?
[18:50]  * slangasek glares at the completely bogus provides: of libmems1
[18:51] <infinity> LocutusOfBorg: So, err, yeah, why did you drop libxml2-udeb? :P
[18:51] <infinity> LocutusOfBorg: But maybe a rebuild of migration-assistant will just make it drop the dep, lemme see.
[18:51] <slangasek> it won't
[18:51] <slangasek> I already looked
[18:52] <slangasek> it uses libxml extensively, and Debian didn't care because m-a is Ubuntu-specific
[18:52] <infinity> What do you mean "Debian didn't care"?
[18:52] <infinity> libxml2-udeb isn't from Debian.
[18:52] <infinity> You mean "the person who synced over Debian changes didn't care".
[18:52] <infinity> Err, ubuntu changes.
[18:53] <slangasek> infinity: I believe when I looked at the Debian changelog it mentioned dropping the udeb there
[18:53] <infinity> Not in any recent history.
[18:53] <slangasek> ok
[18:53] <slangasek> then yes, why are people dropping udebs?
[18:53] <infinity> I mean, not between 6.1 and 7 which is where we synced and dropped our delta that (re)added the udeb.
[18:55] <infinity> LocutusOfBorg: So, yeah, why that sync, and who told you it was "ok"?
[18:55] <infinity> LocutusOfBorg: And please merge instead of syncing, kthx.
[18:56] <infinity> Although, migration-assistant hasn't been in main forever.  Do we even care anymore?
[18:56] <infinity> It's clearly not used in our installer(s), if it was, it would be seeded still.
[18:58] <infinity> revno: 1748
[18:58] <infinity> committer: Evan Dandrea <evan.dandrea@canonical.com>
[18:58] <infinity> branch nick: platform.quantal
[18:58] <infinity> timestamp: Fri 2012-05-25 15:24:39 +0100
[18:58] <infinity> message:
[18:58] <infinity>   Drop migration-assistant per https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-testing-migration-assistant.
[18:58] <infinity> LocutusOfBorg: Maybe don't merge.
[18:58] <infinity> slangasek: ^-- In light of the above happening in, uhm, 2012, maybe it's time to just delete the package? :P
[18:59] <infinity> slangasek: +/- 1?
[19:00] <slangasek> infinity: ok
[19:00] <infinity> Kay, solving it that way then.
[19:00] -queuebot:#ubuntu-release- New binary: ros-bond-core [s390x] (cosmic-proposed/universe) [1.8.3-1] (no packageset)
[19:00] <infinity> LocutusOfBorg: Alright, deleting migration-assistant instead, but yeah, please actually discuss stuff like this before syncing instead of letting it sit for 2 months. :P
[19:01] <infinity> And gone.
[19:01] -queuebot:#ubuntu-release- New: accepted debian-el [amd64] (cosmic-proposed) [37.6]
[19:01] -queuebot:#ubuntu-release- New binary: ros-bond-core [amd64] (cosmic-proposed/universe) [1.8.3-1] (no packageset)
[19:01] -queuebot:#ubuntu-release- New: accepted ros-bond-core [s390x] (cosmic-proposed) [1.8.3-1]
[19:01] <slangasek> to be fair, it's easy to overlook udeb revdeps, since half the tools don't handle them
[19:01] -queuebot:#ubuntu-release- New binary: ros-bond-core [ppc64el] (cosmic-proposed/universe) [1.8.3-1] (no packageset)
[19:02] <infinity> slangasek: Sure, but "I wonder if I can just drop this Ubuntu delta that generates another package" is a thing that might need review by someone who knows what's what.
[19:02] <infinity> (Teaching reverse-depends(1) about udebs would also be nice, though)
[19:03] <infinity> And I'm not sure why that hasn't been done.  It's trivial, as it's Just Another set of Packages Files.
[19:03] <slangasek> because reverse-depends talks to a service
[19:03] <infinity> Well, yes.  Teaching the service is what I meant.
[19:04] <slangasek> well iirc, when I tried to look into getting it to also give useful annotations for alternative-depends in its output, I found the service implemented in some weird language?
[19:04] <infinity> German?
[19:05] <slangasek> rustubycaml
[19:05] <infinity> My favourite.
[19:05] <slangasek> rustubycamell, rather
[19:22] <LocutusOfBorg> infinity, slangasek I'm pretty sure I discussed it two months ago, but libxml2 was broken because of some failing tests, this is why I spotted the udeb thing only yesterday
[19:22] <LocutusOfBorg> there was a good reason for the sync
[19:22] <LocutusOfBorg> but we discussed this 7 months ago
[19:23] <LocutusOfBorg> in the meanwhile I readded it as ubuntu delta
[19:23] <LocutusOfBorg> https://salsa.debian.org/xml-sgml-team/libxml2/commit/76b5366a78a1439ab31ce8fe3ebefe4fdb8b6212
[19:24] <LocutusOfBorg> we also discussed it with installer team IIRC but meh, who remembers what happened more than one hour ago?
[19:24]  * LocutusOfBorg goes back looking a movie, "memento" is on air :)
[19:24] <LocutusOfBorg> thanks for fixing!
[19:25] -queuebot:#ubuntu-release- New binary: ironic [amd64] (cosmic-proposed/universe) [1:11.1.0-0ubuntu3] (openstack)
[19:26] <tsimonq2> mwhudson: <3
[19:40] <ginggs> would someone please 'force-badtest pymca/5.3.2+dfsg-1/ppc64el pymca/5.3.2+dfsg-1/s390x' - no longer built on those architectures
[19:40] <slangasek> AssertionError: assert nan == 0.3342377271245026
[19:40]  * slangasek looks askance at python-cffi
[19:41] <ginggs> also please 'force-badtest julia/0.7.0-2ubuntu1/i386' not built there either
[19:41] <slangasek> ginggs: looking
[19:43] <slangasek> ginggs: done
[19:43] <ginggs> slangasek: ta!
[19:57] <slangasek> infinity: r-cran-rgenoud will be another "interesting" one
[19:58] <infinity> slangasek: Is that assertion on all arches, or just ppc?
[19:58] <infinity> slangasek: If it's PPC, I know what the bug is (and it's being worked on), if it's all arches, lol?
[19:58] <slangasek> infinity: the python-cffi assertion is i386
[19:58] <infinity> Oh, fun.
[19:59] <infinity> That might be a bad testsuite disapproving of some libm fixes.
[19:59] <infinity> slangasek: Can you start an actual list of stuff like this you find so I can go through them?
[19:59] <infinity> I guess you could card it.
[20:00] -queuebot:#ubuntu-release- New binary: panko [amd64] (cosmic-proposed/universe) [5.0.0-0ubuntu3] (no packageset)
[20:00] <slangasek> infinity: could; but I'm almost to the bottom of the false-positives on update_excuses so you could just use that
[20:00] <infinity> slangasek: Sure, if you've decided reds on excuses are all legit, that works too.
[20:00] <slangasek> nearly there
[20:01] <infinity> Well, legit and/or needs eyeballs.
[20:05] <slangasek> mwhudson: seems there would be fewer packages needing badtesting if python-scipy were able to migrate
[20:14] <slangasek> infinity: unrar-free probably just needs a new valgrind, which I'm uploading now but will obviously take a while to build
[20:18] <slangasek> infinity: for bonus points, the armhf apt autopkgtest regression is reproducible
[20:28] <slangasek> infinity: I do like the fcoe-utils/arm64 regression best of all, though - glibc 2.28 has caused this package to no longer find PCI support on the testbed ;)
[20:44] <infinity> slangasek: Wha?
[20:45] <xnox> slangasek, we appear to migrate things without grouping them with built-using. e.g. go things should be grouped with 'built-using' things, like we group the silo ppa stuff.
[20:46] <xnox> slangasek, cause e.g. prometheus-node-exporter migrated, but only passes with all-proposed things.
[20:53] <mwhudson> slangasek: the backend for reverse-depends is in that super oddball language, python, iirc
[20:54] <slangasek> mwhudson: oh ok ;)
[20:54] <mwhudson> although i am now entirely failing to find the repo again
[20:59] <mwhudson> slangasek: ah https://bazaar.launchpad.net/~stefanor/+junk/reverse-deps/files
[21:00] <infinity> slangasek: That's bizarre.  It looks like the test itself is working the same with both, but upgrading glibc makes it more verbose?
[21:00] <infinity> slangasek: ... and makes it see a qemu PCIe bridge?
[21:00] <infinity> ...how?
[21:02] <slangasek> xnox: we don't block migrations based on build-depends either; this might be something better handled via an audit report at end of cycle, rather than making proposed-migration more brittle
[21:04] <infinity> slangasek: Those two tests also used different kernels (-7 versus -9), maybe that's the real culprit?
[21:04] <LocutusOfBorg> please somebody bump mariadb hint to mariadb-10.1
[21:04] <LocutusOfBorg> ehm 1:10.1.35-1ubuntu1
[21:05] <mwhudson> slangasek: scipy: figuring out scientific software's autopktest fails is always so much fun
[21:05] <slangasek> LocutusOfBorg: I thought I saw mariadb-test being sorted; has that not yet reached Ubuntu?
[21:05] <mwhudson> particularly the ones that only crop up on s390x
[21:06] <mwhudson> something in the stack has picked up an endian bug? hooray
[21:07] <mwhudson> and skimage fails on 32 bit
[21:08] <infinity> slangasek: Ahh, no, -7 failed the same way in an earlier run.  Back to WTF.
[21:10] <infinity> slangasek: FWIW, i386 fails (and has always failed) the same way due to the same stderr message.
[21:10] <infinity> slangasek: So this looks more like a progression on arm64 that leads to a regression due to the test being broken WRT not ignoring that message.
[21:11] <slangasek> righty-o
[21:12] <infinity> slangasek: amd64 passes because it doesn't find a bridge to enumerate to then tell us it can't do PCI caps. :P
[21:12] <slangasek> heh
[21:12] <infinity> slangasek: i386 (and now arm64) find a bridge and tell us it's naughty.
[21:13] <infinity> Still no idea why a glibc upgrade would tickle that, but carefactor there is low.  I think fixing the test to ignore that one stderr message and suddenly make i386 pass is the right option.
[21:13] <slangasek> infinity: then why did the no-proposed retry succeed?
[21:13] <slangasek> ok
[21:13] <LocutusOfBorg> slangasek, what?
[21:14] <slangasek> LocutusOfBorg: I definitely saw that the missing mariadb-test package was being reintroduced in Debian.  And I see it in -proposed as well.  that was the previous rationale for the badtest
[21:15] <xnox> mwhudson, yeah, lets ask ibm to do s390le
[21:15] <slangasek> LocutusOfBorg: so I would not just bump the mariadb-10.1 hint without a specific rationale
[21:15] <infinity> xnox: You're in a timeout.
[21:15]  * xnox 😔
[21:16] <LocutusOfBorg> slangasek, https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mariadb-10.1/873043/log.gz
[21:16] <LocutusOfBorg> does it help to know that the failure is exactly the same?
[21:16] <LocutusOfBorg> I can report a debian bug if you want, or if nobody did it
[21:16] <LocutusOfBorg> https://ci.debian.net/packages/m/mariadb-10.1/unstable/amd64/
[21:16] <slangasek> LocutusOfBorg: knowing that the testsuite fails in the same way in Debian and Ubuntu is not an argument for us ignoring the breakage in Ubuntu
[21:17] <xnox> because debian revert our fixes, and won't put them back - cause they /only/ fix autopkgtests?!
[21:18] <xnox> (that used to be the case, not sure if the current failure is still the same thing or something else)
[21:19] <LocutusOfBorg> https://jira.mariadb.org/browse/MDEV-15096
[21:19] <LocutusOfBorg> https://www.google.it/search?q=CURRENT_TEST%3A+main.mysql_client_test_nonblock&oq=CURRENT_TEST%3A+main.mysql_client_test_nonblock&aqs=chrome..69i57.202j0j7&sourceid=chrome&ie=UTF-8
[21:20] <LocutusOfBorg> seems that upstream is aware since some years, and nobody caring :/
[21:21]  * LocutusOfBorg too tired to look at it today, g'night!
[21:24] <sarnold> heh, I though tyou said "too tired to at it on a friday night".. and got my hopes up.
[21:26] <mwhudson> hm
[21:26] <mwhudson> can we just stop building for i386? :)
[21:27] <mwhudson> and armhf (pushing it now)
[21:30] <sarnold> I'd also be content with "sorry, that package is no longer available on this architecture because it can't be linked"
[21:30] <sarnold> how much time do we spend on chromium-browser, firefox, .. ceph? .. who else takes forever..
[21:31] <mwhudson> i think some underlying numeric package now has precision issues on x87 or something
[21:31] <infinity> x87 is garbage.
[21:31] <mwhudson> yes
[21:32] <infinity> The only way to get accurate math on x86 is to ignore x87.
[21:32] <infinity> Which is slooooow.
[21:32] <mwhudson> or ignore x86!
[21:32] <infinity> Amen.
[21:32] <infinity> Sing it, sister.
[21:32] <mwhudson> does ubuntu assume sse for x86?
[21:32] <mwhudson> wait no i DONT CRE
[21:32] <mwhudson> *CARE
[21:32] <infinity> No.
[21:33] <infinity> We assume base 686 + PAE (and the latter only for the kernel)
[21:33] <mwhudson> imexam + python-astropy: fail only on s390x
[21:33] <mwhudson> skimage: fails on 32 bit
[21:34] <mwhudson> python-scipy itself: fails on i386
[21:34] <mwhudson> (well and armhf but it's never passed there)
[21:34] <mwhudson> oh wait: http://autopkgtest.ubuntu.com/packages/p/python-scipy/cosmic/i386
[21:34]  * mwhudson checks hints
[21:37] <mwhudson> hm was hinted for 0.19.1-2ubuntu1
[21:39] <infinity> slangasek: bash to the rescue: http://paste.ubuntu.com/p/wkQF9X8yXw/
[21:43] <slangasek> infinity: instead of 'run fcoeadm --interface >&4 2>&1 |grep -v "^PCI capabilities are not supported$" >&2 4&>1' ? :)
[21:44] <infinity> slangasek: Yeah, I started down fd shuffling route, then remembered bash could do this readably.
[21:44] <slangasek> jbicha: why did you reintroduce ubuntu-desktop on s390x in ubuntu-meta 1.407?
[21:44] <infinity> slangasek: Also, harder with fd-shuffling to get the rest of stderr to stay on stderr instead of lumping it all in stdout.
[21:44] <infinity> Though, I think yours does that.
[21:44] <infinity> Maybe.
[21:45] <infinity> slangasek: Because it's not unity-based anymore and all the deps actually build?
[21:46] <slangasek> infinity: we deliberately did not ship an ubuntu-desktop package on that architecture because Canonical does not support the desktop on s390x
[21:47] <infinity> slangasek: Canonical doesn't support the desktop on ppc64el either.
[21:47] <slangasek> now the package exists, without even a comment in the changelog as to why the architecture exclusion list was reverted
[21:47] <slangasek> yes, and we shouldn't have it there either
[21:47] <infinity> I heartily disagree. :P
[21:48] <infinity> I don't think having random arch differences based on what Canonical has contracts for is particularly sane.
[21:48] <jbicha> because it makes the changelogs more confusing if we don't build ubuntu-desktop on all architectures
[21:48] <jbicha> see https://launchpad.net/ubuntu/+source/ubuntu-meta/1.406
[21:49] <jbicha> because the update script doesn't actually handle that case very well
[21:49] <slangasek> yes, and such disagreements ought to be discussed, instead of being rendered a fait accompli by changing it and letting it leak into an LTS
[21:49] <jbicha> you could split ubuntu-desktop into its own separate source package if you wanted
[21:49] <slangasek> dude
[21:51] <slangasek> jbicha: that is not grounds for making a unilateral decision about architecture support in ubuntu-meta
[21:51] <infinity> slangasek: How does the presence of a metapackage change anything about any of the packages it depends on?  If we really want to not have GNOME supported on s390x at all, we shouldn't be building it (but, please don't).
[21:51] <slangasek> and if you care so much about changelog readability, why did you not document this change in the changelog?
[21:55] <slangasek> infinity: it makes a significant difference in the kind of awkward conversation you get to have with a user who tries to install ubuntu-desktop and then wants support for it
[21:56] <infinity> slangasek: And if that user installs a bunch of random desktop packages in main and starts up that same conversation, it's less awkward?
[21:57] <slangasek> ideally we wouldn't have any of those packages in main on s390x
[21:57] <slangasek> for this reason
[21:59] <jbicha> ok, I should have mentioned it in the changelog, I guess I just didn't want to have an argument about it but that's not a very good reason
[22:04] <slangasek> that's weird, can't reproduce the telepathy-logger-qt autopkgtest regression in a cosmic chroot
[22:14] <slangasek> LocutusOfBorg: seen the diaspora-installer autopkgtest regressions (openssl)?
[22:29] <slangasek> infinity: looks like mysql-5.7/ppc64el is also fail-y after a rebuild against the new ppc64el
[22:31] <slangasek> infinity: eh, ignore that, looks like 5.7.23 in general has been fail-y on ppc64el
[22:34] <xnox> jbicha, that change only broke release-upgrade from xenial->bionic for everyone on s390x, in addition to being against what was agreed before between ubuntu & ibm.
[22:34] <xnox> (the z side of ibm)
[22:35] <infinity> xnox: How would it have broken release upgrade?
[22:35] <xnox> infinity, because giggles =)https://bugs.launchpad.net/ubuntu-z-systems/+bug/1787668
[22:35] <ubot5> Ubuntu bug 1787668 in ubuntu-release-upgrader (Ubuntu) "ubuntu-release-upgrader crashed with KeyError: "The cache has no package named 'ubuntu-desktop'"" [High,In progress]
[22:36] <slangasek> xnox: I don't think it broke the release-upgrade; I think the release-upgrader itself is just broken for using ubuntu-desktop as a key package on this arch when it shouldn't
[22:36] <infinity> xnox: Unless you're implying we accidentally install a desktop on every server installation on upgrade, I call BS on "broke ... for everyone".
[22:36] <xnox> infinity, it has broken logic for when a key package is in next release; but not current.
[22:36] <xnox> as far as i understand the bug so far.
[22:36] <infinity> Oh.  Well, that's hardly jbicha's fault.
[22:38] <xnox> infinity, re not having ubuntu-desktop. At the time i had more strong opinion about it, given lack of physical displays; lack of stable mir/wayland display manager or ssh forwarding for mir/wayland; now that we are back to just X it is slightly easier to say that X things are possibly useful.
[22:38] <xnox> infinity, but not unless one can watch cat videos on youtube. imho installing ubuntu-desktop should give that ability to the user, and i believe firefox is still broken on s390x.
[22:39] <xnox> infinity, i have not checked, but ppc64el ubuntu-desktop does pass the cat video test i believe.
[22:39] <infinity> I don't think cat videos are a hard requirement for a functional desktop. :P
[22:39] <sarnold> infinity: break them and find out.. :)
[22:39] <infinity> Though, I admit it's a nice-to-have.
[22:40] <infinity> xnox: fwiw, firefox exists on s390x in bionic.  How broken is it?
[22:40] <xnox> infinity, i have made this argument before, i believe re:i386 -> until it can haz cat videos it is a real desktop.
[22:40] <infinity> s/bionic/bionic-updates/
[22:40] <xnox> infinity, it does exist, it does exec, it fails between exec and showing a window; most JS tests fail
[22:40] <xnox> infinity, it compiles into a binary.
[22:40] <infinity> Ahh, so rust is borked.
[22:40] <xnox> that too.
[22:41] <sarnold> qt's not happy on ppc64el either https://bugreports.qt.io/browse/QTBUG-56975
[22:41] <infinity> Which seems like a larger problem for a server/cloud-type system than just firefox JS.
[22:41] <infinity> Given rust is gaining more traction in that space.
[22:42] <xnox> infinity, rust itself is better than all of firefox, i thought the testsuite failures for rust on s390x were small-ish
[22:42] <mwhudson> i'm sure ibm have teams of toolchain engineers just roaming around looking for toolchains to support
[22:42] <xnox> (at least at the time i fleshed it out with chrisccoulson )
[22:42] <infinity> xnox: Well, firefox JS broken == rust broken, these days.
[22:42] <xnox> mwhudson, i have requested that for rust and firefox, it went mia -> not a priority for that subteam.
[22:43] <xnox> infinity, but i do want to put my little paw dawn and show some claws re:cat-video requirement.
[22:43] <infinity> xnox: If the rust testsuite isn't catching what firefox's JS engine does, then one could consider firefox JS a better rust testsuite. :P
[22:43] <sarnold> rust 'tier 1' platforms is mighty small list :(  https://forge.rust-lang.org/platform-support.html
[22:44] <jbicha> xnox: could you try epiphany-browser on s390x?
[22:45] <infinity> People other than masochists run epiphany on purpose?
[22:46] <jbicha> depends on how desperate you are for cat videos, I guess
[22:48] <infinity> I mean, I'll have a friendly vim-vs-emacs style argument about firefox-vs-chromium any day, but bringing epiphany into it is akin to the guy in the corner piping up with "I prefer pico!"
[22:48] <infinity> ie: We all agree that guy's wrong.
[22:51] <slangasek> galeon ftw
[22:51] <xnox> there was an odd browser with an apparmor profile as well
[22:51] <xnox> i spotted recently
[22:51] <xnox> is it galeon?
[22:52] <sarnold> qutebrowser perhaps? https://github.com/qutebrowser/qutebrowser/blob/81b3ef937ebf202670c1561429552874ed51d32a/misc/apparmor/usr.bin.qutebrowser
[22:53] <xnox> sarnold, https://launchpad.net/ubuntu/+source/surf
[22:53] <sarnold> I didn't expect that
[22:54] <xnox> sarnold, an apparmor profile unsuitable for usr-merge to be precise ;-)
[22:54] <sarnold> lol
[22:54] <slangasek> xnox: galeon was a gnome 1.x (?) wrapper around embedded mozilla
[22:55] <xnox> slangasek, there was gnome before 3?
[22:55] <jbicha> "surf is a simple web browser based on WebKit2/GTK+. It is able to display websites and follow links." < https://surf.suckless.org/
[23:07]  * xnox ponders that i should be advocating demoting ubuntu-desktop binary package from main to universe on all arches that fail cat-video test
[23:42] <xnox> slangasek, how do you feel about releasing systemd?
[23:42] <xnox> there is only one assertion on arm64
[23:42] <xnox> subprocess.CalledProcessError: Command '['ps', 'u', '-C', 'gdm-x-session']' returned non-zero exit status 1.
[23:42] <xnox> in a boot-and-services test case
[23:42] <slangasek> xnox: which release?
[23:43] <xnox> cosmic-proposed -> -release
[23:43] <slangasek> xnox: so you want me to badtest it?
[23:43] <xnox> yes please.
[23:43] <xnox> and i'm thinking to debug and file gdm3 bug + mark it expectfailed on arm64 for cosmic
[23:44] <xnox> not sure what the point is, in src:systemd validating ubuntu-desktop on a non-UA arch.
[23:44] <slangasek> xnox: arm64 is desktoppier than some of the others
[23:44] <xnox> sure
[23:44] <xnox> but the arm64 microsoft laptops are not linux supported yet =/
[23:46] <slangasek> xnox: anyway, looks like a fair trade here
[23:47] <slangasek> (since we currently have 3 archs ignored in release pocket instead of 1)
[23:47] <xnox> oh
[23:48] <xnox> it's been baking for a long time, and i had to fix many things yes =/
[23:48] <xnox> v238 and v239 were quite shit
[23:52]  * slangasek gives the idle autopkgtest runners something more to do (mass retry of failed autopkgtests)
[23:52] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.7 => 2.525.8] (desktop-core)