[05:07] <acheronuk> is the armhf test queue stalled?
[05:11] -queuebot:#ubuntu-release- New: accepted beets [sync] (bionic-proposed) [1.4.6-2]
[05:21] <acheronuk> yup. looks like armhf test runners are not doing much as far as I can see.
[06:35] <slangasek> acheronuk: thanks for flagging it. I'm not sure what's going on, the runners claim to be running; digging in
[06:39] <slangasek> acheronuk: currently they are working and taking tests from the queue.  Progress was flatlined before that for a couple of hours, for whatever reason
[06:39] <slangasek> but they're running now
[06:50] <estan> infinity: me and the upstream c-blosc author are struggling a bit in trying to reproduce that armhf failure. i've been trying with a recent version of QEMU while he's tried on a real ARM hw. just so i'm clear: you said the ubuntu packages are built on ARMv8 hw?
[06:52] <estan> infinity: i'm asking because i see now that the package build log indicates cmake detected the platform as armv7l (-- Building for system processor armv7l).
[06:52] <estan> are the builds running on ARMv8 hw, but in an ARMv7 VM?
[06:58] <mwhudson> estan: yes
[07:02] <slangasek> ttbomk no; they build in armhf chroots on ARMv8 VMs but lie about the cpu because otherwise lots of software makes bad assumptions at build time
[07:14] <estan> slangasek: hm okay. that's a good piece of info. i'll see if i can get something like that going. problem is i don't have any ARM hw :/
[07:15] <estan> trying to help an upstream author debug this failure: https://launchpadlibrarian.net/360527843/buildlog_ubuntu-bionic-armhf.c-blosc_1.14.0+ds1-1_BUILDING.txt.gz , we suspect it's due to misaligned memory accesses, because the debian build of the same package succeeded, and that's apparently on ARMv7 hw.
[07:15] <estan> (and the alignment requirements are stricter on ARMv8).
[07:16] <estan> but so far i've had no luck in reproducing it on an ARMv8 machine in QEMU, eventhough from what i can tell of the QEMU code, it should do ARMv8 alignment checks.
[07:25] <estan> slangasek: i found https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap now, so is the package building infrastructure using the approach described under "USING SYSCALL EMULATION" for the second stage debootstrap of the chroot?
[07:25] <estan> or is it using QEMU machine emulation?
[07:26]  * estan shudders at the thought of having to do nested full machine emulation to reproduce this.
[07:29] <mwhudson> oh are they only chrrots?
[07:30] <mwhudson> estan: i can try to build it on a porter box and then pastebin bits of syslog at you if that's helpful?
[07:44] <estan> mwhudson: anything would be helpful at this point, and much appriciated. it's the recent upload of c-blosc 1.14.0 to the bionic proposed pocket. i'm not sure where i can get the source package actually.
[07:44] <mwhudson> estan: i built it but accidentally in an arm64 chroot :)
[07:44] <mwhudson> building in armhf now
[07:44] <estan> thanks a lot.
[07:45] <mwhudson> estan: how do the tests run? is there a test binary i can simply run under gdb somehow?
[07:47] <estan> mwhudson: indeed there is. one of the tests that are failing are run with `./bench/bench blosclz` in the build directory.
[07:49] <mwhudson> estan: https://paste.ubuntu.com/p/Wd6sjMxqPG/
[07:50] <mwhudson> estan: er, that's ./blosc/fastcopy.c:452
[07:52] <estan> mwhudson: many thanks! could you paste output of `bt` as well?
[07:52] <mwhudson> estan: one sec
[07:52] <mwhudson> i just deleted the whoe "case 8" bit and am re-running the tests
[07:52] <mwhudson> *whole
[07:57] <estan> ah yes, must be an alignment issue. something around there should probably be protected by an if !defined(BLOSC_STRICT_ALIGN).
[07:58] <estan> mwhudson: i gotto run to the bus, back in ~30 minutes, but it would be great if you could post your findings to https://github.com/Blosc/c-blosc/issues/223
[07:58] <mwhudson> estan: ok
[07:58] <estan> that's the upstream report, @FrancescAlted is the upstream author (i was just trying to help out).
[08:03] <mwhudson> estan: posted
[08:03] <mwhudson> hope that helps
[08:03] <mwhudson> (looks like it should!)
=== _cpaelzer is now known as cpaelzer
[08:26] <infinity> estan: To be clear, alignment isn't stricter on ARMv8, it's that ARMv7 kernels, by default, trap alignment errors and do fixups.  ARMv8 ones don't.
[08:26] <infinity> estan: That behaviour can be turned off on pure ARMv7 systems with a sysctl.
[08:27] <infinity> estan: But I'm guessing from backscroll that mwhudson's experiment helped you find the bug?
[09:32] -queuebot:#ubuntu-release- New source: openjdk-11 (bionic-proposed/primary) [11~4-1]
[09:33] -queuebot:#ubuntu-release- New: accepted openjdk-11 [source] (bionic-proposed) [11~4-1]
[09:42] <estan> infinity: ah thanks for clearing that up. yes indeed, mwhudson was very helpful. the upstream author has already made a fix based on the info (https://github.com/Blosc/c-blosc/issues/223#issuecomment-373314909).
[09:43] <estan> infinity: what do you think, should i nudge the debian package maintainer to make a patched debian package that you can sync again, or should there be made a patched ubuntu package?
[09:44] <mwhudson> how responsive is the debian maintainer to nudges?
[09:44] <mwhudson> that was would be better i think :)
[09:44] <infinity> estan: The bug is entirely valid for Debian too (those alignment traps are *expensive*), but probably sane to get mwhudson to test the patch first, if he still has his built tree.
[09:44] <infinity> s/built/build/
[09:45] <mwhudson> uh yes i do
[09:45] <estan> mwhudson: he was very responsive when i asked him to do the 1.14.0 release in the first place, so i'll go with that then :)
[09:45] <infinity> estan: Since the turnaround time of "get it in Debian, sync, find out it's still broken, repeat" isn't ideal.
[09:45] <estan> indeed.
[09:45] <infinity> estan: But yes, if mwhudson can confirm it's fixed, doing it through Debian is best.
[09:46] <infinity> mwhudson: Sorry to volunteer you, I can do it too, if you prefer. :P
[09:46] <infinity> mwhudson: I assume you did this in the bionic-armhf chroot on porter-arm64?
[09:46] <mwhudson> infinity: i did
[09:46] <mwhudson> building now
[09:46] <infinity> Ta.
[09:47] <mwhudson> assuming i drove quilt correctly which is not always a very good assumption
[09:47] <estan> when i asked for an update, i did so by making MRs to https://salsa.debian.org/debian/c-blosc , but i'm not sure that's the way to contribute to the package, because the debian packager quickly closed my MRs and did the update himself :)
[09:47] <infinity> estan: Just filing bugs in the Debian BTS with debdiffs attached is the general preferred method.
[09:47] <estan> but i'll make an MR there again if the patch turns out good, and he can decide if he rather do the patching himself instead of accepting MRs.
[09:47] <estan> aha.
[09:47] <infinity> estan: I'm sure as salsa becomes more popular, PRs might become more common, but that's certainly not the current Debian Way.
[09:48] <estan> alright. i'll dust off my debdiff making skills then.
[09:48] <mwhudson> estan: thanks for finding a problem with a package that takes 6 minutes, not 6 hours to build :)
[09:48] <infinity> Hahaha.
[09:48] <estan> mwhudson: heh, i was thinking the same thing. especially when i was trying to reproduce in QEMU :)
[09:49] <mwhudson> estan: built ok
[09:50] <estan> *starts drumroll*
[09:50] <mwhudson> fwiw this is what i did:
[09:50] <mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ wget https://github.com/Blosc/c-blosc/commit/8a84d51487eed81431b0fa488805a62c2d8f0163.patch
[09:50] <mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ quilt import 8a84d51487eed81431b0fa488805a62c2d8f0163.patch
[09:50] <mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ rm 8a84d51487eed81431b0fa488805a62c2d8f0163.patch
[09:50] <mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ dpkg-buildpackage
[09:50] <mwhudson> and now i'm going to bed
[09:50] <estan> many thanks mwhudson, sleep tight.
[09:51] <infinity> estan: FWIW, if you need to try to reproduce this in the future, the magic on an ARMv7 kernel to stop doing the traps is "cat 1 > /proc/cpu/alignment"
[09:51] <estan> if you have time to confirm the fix works on the GH issue that would be great, otherwise @FrancescAlted will just have to take my word for it :p
[09:52] <infinity> s/cat/echo/
[09:52] <infinity> I can't brain at 4am.
[09:52] <mwhudson> oh yes
[09:52] <estan> infinity: ah, good to know, thanks. when i was trying to reproduce it i was actually directly on an aarch64 QEMU VM, so i had misunderstood.
[09:53] <infinity> estan: Oh, an aarch64 VM with an armhf chroot would have reproduced it fine.
[09:53] <infinity> Albeit quite slowly, probably.
[09:53] <estan> ah, so i was close then, or well, getting the chroot set up would have taken some time.
[09:54] <infinity> debootstrap --variant=buildd --arch=armhf bionic directory/
[09:54] <infinity> That bit doesn't take long. :)
[09:55] <estan> :)
[09:55] <infinity> Well, this is also assuming the default qemu aarch64 machine supports armv7 (which is an optional add-on for armv8), but I imagine it does.
[09:55] <infinity> It might not.
[09:55] <infinity> Not sure I've ever checked.
[09:57] <estan> yea, i had that worry. i don't know either. i know it's uncommon among hw to not support it.
[09:57] <infinity> Not that uncommon.
[09:57] <infinity> Several server-oriented SoCs don't bother with the armv7 bit.
[09:57] <infinity> And likely more in the future.
[09:58] <infinity> I suspect a future Apple A-series SoC will also drop armv7 on whatever flag day they decide that olds apps don't matter anymore.
[09:58] <infinity> s/olds/old/
[09:59] <estan> alright, "know" was the wrong word. i may have based that off an old answer on askubuntu.com, which may even be wrong (https://askubuntu.com/questions/928249/how-to-run-armhf-executables-on-an-arm64-system).
[09:59] <infinity> (I suspect maybe phone-oriented SoCs will move in that direction, but I'd put money on Apple doing it first, cause they love to draw those lines in the sand and say "we supported your migration path for 2 years, now suck it.")
[09:59] <infinity> s/maybe/many/ ... I can't type.  It's time to not be here. :P
[10:00] <infinity> Actually, Apple may have already done it.  I remember a conversation with my brother recently about newer iOS versions dropping 32-bit support.
[10:00] <infinity> Which only really makes sense if they're also dropping the silicon bits.
[10:03] <infinity> estan: But yeah, the server SoC bit has put us in an irritating position, since our armhf infra is based on the theory that we can get armv8 servers that support armv7.  And in the very first generation of armv8 servers (which we run currently) that was true.  And now, it's not. :P
[10:05] <estan> ah yes.
[10:05] <infinity> I imagine we can get by for a good long while if we make the current armv8 kit armv7-only and buy new armv8-only kit for the future, but eventually, we need to just have the "32-bit is dead" discussion, and consider dropping it on the floor.
[10:05] <infinity> (along with i386, because ick)
[10:05] <estan> yea.
[10:06] <infinity> I intend to propose dropping both for 18.10, making 18.04 the last LTS with 32-bit support, but I also expect a bunch of push-back on one or both. :P
[10:08] <estan> heh. i won't cry any rivers, so you have my support.
[10:31] -queuebot:#ubuntu-release- New binary: openjdk-11 [s390x] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
[10:51] -queuebot:#ubuntu-release- New binary: openjdk-11 [ppc64el] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
=== bashfulrobot_ is now known as bashfulrobot
=== slashd- is now known as slashd
=== Kamilion|ZNC is now known as Kamilion
=== broder_ is now known as broder
[11:28] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-38.43] (core, kernel)
[11:31] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (artful-proposed/multiverse) [5.1.34-0ubuntu1.17.10.1 => 5.1.34-0ubuntu1.17.10.2] (no packageset)
[11:31] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
[11:32] <LocutusOfBorg> sil2100, pleeeeeease ^^
[11:33] <LocutusOfBorg> sigh, you were right, you just pointed at rules, and postinst was bad :/
[11:33] <LocutusOfBorg> (techically not a big problem, that package works as expected anyway, just it is better to have them all at the same version)
[11:40] <sil2100> LocutusOfBorg: actually I did point out both ;)
[11:40] <sil2100> 12:28 < sil2100> LocutusOfBorg: in debian/postinst there's version=5.1.32 while the version of the package is 5.1.34 - is that ok?
[11:40] <sil2100> 12:28 < sil2100> LocutusOfBorg: same for debian/rules
[11:40] <sil2100> Anyway, looking!
[11:41] <apw> that really should be being fixed by the packaging ...
[11:42] <sil2100> LocutusOfBorg: eh, could you re-upload with -v ?
[11:42] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-38.43]
[11:44]  * sil2100 AFK for a bit to get lunch
[11:46] -queuebot:#ubuntu-release- New binary: openjdk-11 [amd64] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New: accepted openjdk-11 [amd64] (bionic-proposed) [11~4-1ubuntu1]
[11:49] -queuebot:#ubuntu-release- New: accepted openjdk-11 [s390x] (bionic-proposed) [11~4-1ubuntu1]
[11:49] -queuebot:#ubuntu-release- New: accepted openjdk-11 [ppc64el] (bionic-proposed) [11~4-1ubuntu1]
[11:55] <LocutusOfBorg> sorry sil2100 I really didn't get that ping :/
[11:55] <LocutusOfBorg> reuploaded with -v
[11:57] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (artful-proposed/multiverse) [5.1.34-0ubuntu1.17.10.1 => 5.1.34-0ubuntu1.17.10.2] (no packageset)
[11:57] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
[11:59] -queuebot:#ubuntu-release- New binary: openjdk-11 [arm64] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
[12:00] -queuebot:#ubuntu-release- New: accepted openjdk-11 [arm64] (bionic-proposed) [11~4-1ubuntu1]
=== tyhicks` is now known as tyhicks
=== tyhicks is now known as Guest65850
[12:04] <estan> infinity1: i submitted a debdiff adding the alignment fix patch to the debian package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893000 , let's hope it'll be a quick affair.
[12:04] <ubot5`> Debian bug 893000 in src:c-blosc "c-blosc: Add upstream patch for unaligned access" [Important,Open]
=== alan_g_ is now known as alan_g
[12:11] -queuebot:#ubuntu-release- New binary: openjdk-11 [i386] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
[12:11] -queuebot:#ubuntu-release- New: accepted openjdk-11 [i386] (bionic-proposed) [11~4-1ubuntu1]
[12:33] -queuebot:#ubuntu-release- Unapproved: murano-dashboard (artful-proposed/universe) [1:4.0.0-0ubuntu1.1 => 1:4.0.0-0ubuntu1.2] (openstack)
[12:34] -queuebot:#ubuntu-release- Unapproved: designate-dashboard (artful-proposed/universe) [5.0.1-0ubuntu1 => 5.0.1-0ubuntu1.1] (no packageset)
[12:35] -queuebot:#ubuntu-release- Unapproved: sahara-dashboard (artful-proposed/universe) [6.0.0-0ubuntu1 => 6.0.0-0ubuntu1.1] (no packageset)
[12:36] -queuebot:#ubuntu-release- Unapproved: trove-dashboard (artful-proposed/universe) [9.0.0-0ubuntu1 => 9.0.0-0ubuntu1.1] (no packageset)
[13:01] <xnox> apw, as per http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html linux-kvm and linux-meta-kvm should be promoted, but it needs bug subscriber. Can you subscribe the right kernel team to those packages?
[13:12] <ginggs> what needs to be done for this bug? LP: #1754843
[13:12] <ubot5`> Launchpad bug 1754843 in gdk-pixbuf (Ubuntu) " gdk-pixbuf version in artful > version in bionic" [Undecided,New] https://launchpad.net/bugs/1754843
[13:16] <cjwatson> that seems like a trivial copy-forward
[13:16] <infinity1> Yup.  Doing.
[13:16] <cjwatson> I just did
[13:16] <infinity1> Well, then.  Not doing.
[13:17] <cjwatson> :)
[13:21] <cjwatson> somebody should do a full scan for that sort of thing though.
[13:21] <ginggs> cjwatson, infinity1: thanks both of you
=== infinity1 is now known as infinity
[13:48] <Guest65850> hello - I'd like to get a release team ack for uploading apparmor 2.12 (merged from Debian's 2.12-3) to bionic
=== Guest65850 is now known as tyhicks
[13:49] <tyhicks> lets try that again :)
[13:49] <tyhicks> I'd like to get a release team ack for uploading apparmor 2.12 (merged from Debian's 2.12-3) to bionic
=== tyhicks is now known as Guest1006
[13:49] <Guest1006> argh... let me sort out irc problems and I'll be back
[14:02] <apw> xnox, ok subscribed ...
[14:11] -queuebot:#ubuntu-release- Unapproved: strongswan (trusty-proposed/main) [5.1.2-0ubuntu2.7 => 5.1.2-0ubuntu2.8] (no packageset)
[14:22] <tyhicks> ok, back to the apparmor-2.12 upload...
[14:22] <tyhicks> here are the upstream release notes: https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.12#highlighted-new-features
[14:22] <tyhicks> well, the features mentioned in the upstream release notes
[14:23] <tyhicks> the last two bullets there are bug fixes to bugs that affect Ubuntu
[14:23] <tyhicks> the first bullet is a new feature but only applies to suse systems as it is yast-specific
[14:24] <tyhicks> I think I'm fine uploading apparmor 2.12 without a FFe but that yast-specific feature is the slight gray area that I wanted release team approval for
[14:25] <tyhicks> the yast-specific feature is only in the python utils (apparmor-utils binary package) which are not seeded
[14:25] <apw> i don't think i would count a feature we do not and can not use as a new feature
[14:26] <apw> also i see that is bringing python 3.6 support, did we not just bump to that
[14:27] <tyhicks> that's how I felt about the yast feature, as well, but I had a conflict of interest since I'm involved in apparmor upstream
[14:27] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (artful-proposed) [5.1.34-0ubuntu1.17.10.2]
[14:27] <tyhicks> oh, did we?
[14:27] <tyhicks> apparmor 2.12 includes additional policy rules that allow for python 3.6 paths
[14:27] <tyhicks> so, that'll be pretty important
[14:28] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (artful-proposed) [5.1.34-0ubuntu1.17.10.2]
[14:28] <tyhicks> I'll also mention that I ran through the entire test plan here: https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
[14:28] <tyhicks> this upload is very well tested
[14:29] <apw> the second of those pulled out ones, i seem to reember is something that snapd was tickling too
[14:29] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
[14:29] <apw> tyhicks, from my niave reading of the changelog in full i don't see anything that sounds dangerous
[14:29] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
[14:29] <apw> tyhicks, or anything which would tip you over the bar to needing an FFe, so i think you are good
[14:30] <tyhicks> apw: I feel the same way but wanted a +1 - thanks for taking a look!
[14:30] <apw> tyhicks, +1
[14:32] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-38.43~16.04.1] (kernel)
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (artful-proposed) [1:20180313.1-0ubuntu0.17.10.1]
[14:34] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180313.1-0ubuntu0.16.04.1]
[14:34] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180313.1-0ubuntu0.14.04.1]
[14:46] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-38.43~16.04.1]
[15:08] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.2-0ubuntu1.3]
[15:19] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu7.1]
[15:57] <nacc> xnox: ok with removing ruby-filepath? (i'll file bug) it seems to hang, and upstream only indicates ruby2.3 compat.
[15:57] <nacc> xnox: leaf package
[15:57] <nacc> xnox: i've got the fix for ruby-grape as well
[16:00] <Laney> stgraber: I'm going to deploy some more arm64 instances in a minute - any chance you could review that MP quickly so they get the new goodness?
[16:00] <xnox> nacc, yes, i was considering removing ruby-filepath too, go ahead
[16:00] <nacc> xnox: ack, thanks
[16:03] <xnox> nacc, if only armhf would finish soon.....
[16:04] <stgraber> Laney: link?
[16:05] <Laney> stgraber: https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/341329
[16:06] <xnox> nacc, there are a couple things that are regressions w.r.t. openssl1.1
[16:07] <xnox> e.g. ruby-net-ssh is a suspect and the http-pipeline
[16:07] <xnox> rpdf is weird
[16:07] <xnox> and yard is fixed
[16:09] <nacc> xnox: good to know on yard
[16:09] <nacc> xnox: i'll trawl through the list today
[16:29] <xnox> nacc, ruby-html-pipeline uploaded; ruby-net-ssh uploaded
[16:29] <xnox> so there is very little left
[16:30] <xnox> nacc, i think we can simply wait for all the results today
[16:30] <xnox> from armhf, and revisit tomorrow
[16:31] <stgraber> Laney: +1ed
[16:31] <Laney> stgraber: thanks
[16:31] <Laney> stgraber: I'll grab you at some point to help me migrate the existing ones if that's OK
[16:31] <Laney> can't exactly remember what we did before
[16:32] <stgraber> Laney: ok. I thought we ended up just deploying a new one, didn't we? But converting an existing one should definitely be possible.
[16:33] <Laney> stgraber: I think we initially played on an existing instance, then tested a modified userdata
[16:33] <stgraber> ah, yeah, that rings a bell
[16:33]  * Laney does the split screen thing
[16:33] <Laney> hoepfully armhf will go down a bit faster
[16:33] <Laney> that or we kill another cloud
[16:36] <Laney> slangasek: ^-- lxd-armhf{11..13} provisioning
[16:36] <Laney> these ones with the new LXD stuff
[16:38] <nacc> xnox: ack
[16:41] <stgraber> tsimonq2: did it join your channel now?
[16:41] <tsimonq2> stgraber: Ah, yes it did.
[16:41] <tsimonq2> stgraber: Thanks!
[16:41] <stgraber> np
[16:55] <slangasek> Laney: cool.  Does this mean a (temporary) increase in the number of runners?
[16:57] <Laney> slangasek: 3x3 more, yeah
[17:13] <Laney> live now
=== kees_ is now known as kees
[17:51] -queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (xenial-proposed) [1:3.3.1-1.1ubuntu1.2]
[18:02] -queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [source] (xenial-proposed) [2.0.7-0ubuntu1]
[18:08] -queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (trusty-proposed) [5.1.2-0ubuntu2.8]
[19:12] <tsimonq2> Any chance I could get an SRU team member to release https://bugs.launchpad.net/bugs/1739955 so it doesn't wait until Monday?
[19:12] <ubot5`> Ubuntu bug 1739955 in qttools-opensource-src (Ubuntu Xenial) "Qt5UiTools.pc Requires: non-existent Qt5UiPlugin" [Medium,Fix committed]
[19:16] <tsimonq2> bdmurray: Seems like you're the person to poke today.
[19:19] <bdmurray> tsimonq2: looking
[19:40] <tsimonq2> bdmurray: Thank you!
[20:24] <slangasek> infinity, sil2100: FFe request LP: #1756177
[20:24] <ubot5`> Launchpad bug 1756177 in e2fsprogs (Ubuntu) "FFe: e2fsprogs 1.44, support for largedir and ea_inode" [Undecided,New] https://launchpad.net/bugs/1756177
[20:30] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1022.24] (kernel)
[20:40] -queuebot:#ubuntu-release- Unapproved: trove-dashboard (xenial-proposed/universe) [6.0.0-1 => 6.0.0-1ubuntu1] (no packageset)
[20:41] -queuebot:#ubuntu-release- Unapproved: murano-dashboard (xenial-proposed/universe) [1:2.0.0-1 => 1:2.0.0-1ubuntu1] (openstack)
[20:41] -queuebot:#ubuntu-release- Unapproved: sahara-dashboard (xenial-proposed/universe) [4.0.0-1ubuntu1 => 4.0.0-1ubuntu1.1] (no packageset)
[20:42] -queuebot:#ubuntu-release- Unapproved: horizon (trusty-proposed/main) [1:2014.1.5-0ubuntu2.1 => 1:2014.1.5-0ubuntu2.2] (ubuntu-server)
[20:43] -queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu4 => 2:9.1.2-0ubuntu5] (openstack, ubuntu-server)
[20:44] <acheronuk> slangasek or infinity: would you have time to take a look at? https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/1756066
[20:44] <ubot5`> Ubuntu bug 1756066 in amarok (Ubuntu Bionic) "[FFe] Amarok 2.9.0 for Bionic" [Undecided,Confirmed]
[20:44] <tsimonq2> +1, it's the last KDE 4 release of Amarok and it'd be really good to get it in for the LTS.
[20:52] <nacc> xnox: fyi, ruby-grape is updated in debian and passes, i'll sync it
[21:07] <sil2100> slangasek: I can take a look at that in some minutes if infinity isn't around
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (artful-proposed) [9.0.0-0ubuntu1.1]
[21:11] -queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [source] (artful-proposed) [5.0.1-0ubuntu1.1]
[21:12] <nacc> xnox: and i think ruby-grape-entity n eeds a uupdate (they are 2.5 compat upstream)
[21:13] -queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (artful-proposed) [1:4.0.0-0ubuntu1.2]
[21:29] -queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (xenial-proposed) [6.0.0-1ubuntu1]
[21:33] -queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (xenial-proposed) [1:2.0.0-1ubuntu1]
[21:37] -queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (xenial-proposed) [4.0.0-1ubuntu1.1]
[21:40] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu5]
[21:44] -queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (trusty-proposed) [1:2014.1.5-0ubuntu2.2]
[21:53] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (trusty-proposed) [1:2014.1.5-0ubuntu2.2]
[21:58] -queuebot:#ubuntu-release- Unapproved: sahara-dashboard (artful-proposed/universe) [6.0.0-0ubuntu1 => 6.0.0-0ubuntu1.2] (no packageset)
[22:15] -queuebot:#ubuntu-release- Unapproved: rejected sahara-dashboard [source] (artful-proposed) [6.0.0-0ubuntu1.1]
[22:30] -queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (artful-proposed) [6.0.0-0ubuntu1.2]
[22:43] <slangasek> xnox: util-linux stole the rfkill binary package from the rfkill source; do you know if the Ubuntu delta from rfkill 0.5-1ubuntu2 is merged?
[22:43] <slangasek> xnox: n/m, "This upgrade fix needs to be kept until after Ubuntu 16.04 LTS", which we are after ;)
[22:44] <xnox> slangasek, my util-linux merging was a bit "i hope not to break anything" type of merge
[22:44] <slangasek> xnox: though we do have some orphaned upstart conffiles now - let me take care of those