[00:25] <RAOF> niedbalski: Do you have any insight into the percona-xtradb-cluster-5.6 autopkgtest failure with diaspora-installer? I'm not confident that it's a false-positive.
[02:12] <Anticom> Hi all. Is there any reason, there are no packages for docker-compose, docker-machine, docker-machine-driver-kvm, kubectl and minikube ?
[02:12] <Anticom> (I'm on Ubuntu 16.04)
[02:33] <mwhudson> Anticom: there is a package for docker-compose i think?
[02:33] <Anticom> mwhudson: oh, my bad, there is indeed
[02:34] <mwhudson> in general dockerish things move fast enough that distributing them via the archive is a pain though
[02:34] <Anticom> mwhudson: so it *should* be up to the project maintainers to provide a CI/CD to a launchpad ppa etc. ?
[02:41] <sarnold> Anticom: hopefully useful, https://conjure-up.io/ https://jujucharms.com/canonical-kubernetes/ and https://www.ubuntu.com/kubernetes
[02:43] <stokachu> Anticom: fwiw kubectl is packaged as a snap
[02:55] <Anticom> stokachu: minikube aswell, but in like v0.8.0 where v0.32.0 or something along those lines is the current one
[06:02] <NewGnuGuy> When a new version of a package (in this case libsdl2) is migrated from Debian unstable to testing, will that package automatically get added the latest Ubuntu stable release (in this case Artful) or does something have to be done manually?
[06:06] <NewGnuGuy> https://launchpad.net/ubuntu/+source/libsdl2 Version 2.0.7 is listed for Bionic, but 2.0.6 is still listed for Artful. 2.0.6 suffers from these crash-inducing bugs: https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1722060 https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1727849
[06:35] <cpaelzer> NewGnuGuy: hi, once a Ubuntu release is released we no more pick up updates/changes by default
[06:35] <Unit193> (Answered in #xubuntu)
[06:35] <cpaelzer> NewGnuGuy: instead it then goes into maintenance which more or less means fixes yes, features no (as they often introduce new issues and could regress)
[06:35] <cpaelzer> oh I see Unit193
[06:35] <cpaelzer> then TL;DR https://wiki.ubuntu.com/StableReleaseUpdates
[06:35] <cpaelzer> but already answered there
[06:38] <Unit193> Would be nicer to have the factoid say more, but ah well.
[07:31] <mwhudson> apw: is https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1692912 really in progress?
[08:16] <apw> mwhudson: pretty sure that was an artful kernel systemd inert
[08:16] <apw> interaction. that got resolved long ago
[08:17] <mwhudson> apw: i'll close it then?
[08:17] <apw> yeah please, sure that was fixed in the kernel config in the end
[08:18] <mwhudson> most docker.io bugs are upgrade failures that i have no idea how to reproduce
[08:18] <mwhudson> might as well try to stay on top of the others :)
[08:20] <apw> good enough :)
[14:58] <xnox> Laney, i'm not happy =( the autopkgtest qemu runner does not work on s390x, as it is waiting for a console that is not available. I think i actually want to use ssh runner, but with the local qemu vm that was created. Has there been any work done to achieve that? e.g. have like a uvt-kvm running?
[14:59] <xnox> i think uvt-kvm + ssh runner might be a better match.
[14:59] <rbasak> I pushed cpaelzer's fix for s390x to uvtool upstream earlier FWIW.
[14:59] <rbasak> Not done an upload to Bionic yet.
[14:59] <Laney> xnox: No, you could probably write an SSH setup script for it though
[15:00] <xnox> Laney, just for myself; or do you think upstreaming / supporting such an option could be useful, in general?
[15:00] <xnox> rbasak, ack, thanks.
[15:00] <Laney> Fine for upstream I think, although I'm not upstream so I can't say for sure
[15:01] <Laney> probably file a bug at Debian to discuss it
[15:04] <cpaelzer> xnox: I think I once fixed it to work on the cloudimg - was some weird mapping of consoles to ttyS
[15:04] <cpaelzer> xnox: but it never worked reliably
[15:04] <cpaelzer> which is why I haven't propsed anything
[15:05] <cpaelzer> All I remember is a morning of ugly details with pitti back then which was just enough to get my test working
[15:05] <cpaelzer> an ssh-runner certainly sounds better if that is doable
[15:05] <cpaelzer> and a more generic solution
[16:22] <juliank> rbalint: hey, congrats. welcome to the core dev world :)
[16:28] <juliank> rbalint: that reminds me that I'd like to hear your thoughts about my latest two comments in bug 1690980 (it's your patch to apt, after all). I'll be playing with what I proposed shortly, but if the broken state is already less broken than the current state, I guess we could mark the SRU as verified and track the "regression" elsewhere.
[16:30] <rbalint> juliank: thanks!
[16:30] <juliank> (The goal of that bug was to give u-u run by apt-daily more time to complete on shutdown, but the process only stops the top-level shell script. systemd considers the unit exited after that apparently, but the processes are still running. I'm not sure if it waits for them on shutdown or not - if it does, that's OK enough, if not, then it's essentially the same state as now)
[16:32] <juliank> I guess we should probably fix it anyway. I'm excited to see if the shell wait trap thing works as expected :)
[16:34] <rbalint> juliank: i just looked at your comment the other day and wanted to pick up the line
[16:34] <rbalint> juliank: u-u-s is also expected to send TERM to u-u which will terminate it gracefully
[16:35] <rbalint> juliank: this needs an sru which i wanted to prepare for a long time but did not get to it and also i was happy with the extended testing in artful
[16:36] <rbalint> juliank: let me add this to the bug, too
[16:37] <juliank> The thing is that systemctl stop apt-daily-upgrade.service currently just terminates the apt-daily script, which is suboptimal. It should also terminate unattended-upgrades. But, yes, I think there's a missing dependency on an u-u that actually supports SIGTERM for graceful canceling
[16:37] <juliank> Though, the two are independent. Without a u-u that properly handles SIGTERM, it's still better than now.
[16:38] <juliank> (where systemd just kills the entire cgroup)
[16:38] <juliank> s/kills/terms/
[16:39] <juliank> rbalint: I guess optimally, we'd now just tell the script to send SIGUSR1 to unattended-upgrade, then you don't need the SIGTERM change for u-u SRUed for the change to be actually useful
[16:39] <rbalint> juliank: i agree that apt-daily-upgrade.service should TERM children but this step missing will not cause problems as long as u-u.service sends the proper signal to u-u when shutting down
[16:40] <juliank> rbalint: I guess it depends on whether systemd waits for that to be terminated or not
[16:40] <rbalint> juliank: it my tests it did
[16:42] <juliank> Then I guess we should mark the bug as verified (though weird interaction with an u-u SRU, I guess), and let the apt SRUs enter, and once there are u-u SRUs, it works better.
[16:42]  * juliank thinks we kind of need verified-done-<distro>-<package> :D
[16:42] <juliank> s/verified/verification/
[16:46] <rbalint> juliank: yes thanks for the apt changes, they are good
[16:46]  * juliank has to leave (or go /away) now, but will be /back shortly (and has a bouncer anyway) :)
[16:47] <Odd_Bloke> rbalint: Congrats!
[16:50] <rbalint> Odd_Bloke: thanks! :-)
[16:54] <juliank> Hmm has anyone considered apt running dpkg in its own systemd scope
[16:54] <juliank> That sounds like it would be fun :)
[16:55] <juliank> Like a dpkg.scope where dpkg and maintscrpts run in. This gets them out of any service unit whatsoever.
[19:33] <jbicha> ricotz: thanks for the Firefox 58 Beta emoji fix, are you going to apply the same fix to Thunderbird?
[19:47] <ricotz> jbicha, probably with the first 58 beta
[19:48] <jbicha> so we'd have to wait for Thunderbird 59 for that to land in regular Ubuntu?
[20:15] <mwhudson> rbalint: congrats!
[20:18] <ricotz> jbicha, it could be added with 52.5.0 though
[20:19] <jbicha> ricotz: are you working on the TB 52.5 update? or do I really just need to ping Chris?
[20:20] <sarnold> rbalint: congratulations on core-dev :)
[20:21] <ricotz> jbicha, I will likely take a look when there are tags available, but reminding chris about it won't hurt
[20:33] <Unit193> ricotz: Are you still working on or interested in esr?
[20:35] <ricotz> Unit193, I am maintaining them in a PPA
[20:35] <Unit193> That's a "yes", then thanks!
[20:36] <ricotz> Unit193, https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/
[20:37] <Unit193> ricotz: I was just unsure if you became disinterested with all the 'snap' talk afterwards, good to know you haven't.
[20:39] <rbalint> mwhudson, sarnold thank you! :-)
[22:19] <jbicha> doko: could you look into this ftbfs: https://launchpad.net/ubuntu/+source/vcdimager/0.7.24+dfsg-0.3 ?
[22:39] <mwhudson> ",  | libc-dev,"
[22:39] <mwhudson> nice
[22:40] <juliank> mwhudson: eww, where did you find this awful thing?
[22:40] <juliank> oh, in the ubild log
[22:43] <nacc> ha
[22:43] <juliank> I mean, it's simply libc6-dev used to provide libc-dev, but does not
[22:43] <nacc> no, it's a buggy change
[22:43] <juliank> hence the first part in LIBCDEV=$(shell dpkg-awk 'Provides:libc-dev' -- Package | sed -ne 's/^Package:[[:space:]]*//p' | head -1) | libc-dev is empty
[22:43] <nacc> http://paste.ubuntu.com/25970523/
[22:43] <nacc> shouldn't that be in the ) ?
[22:44] <nacc> or it's tryign to force a string out? then it should be i quotes, no?
[22:44] <juliank> nacc: That line did not change, it used to become libc6-dev | libc-dev
[22:44] <nacc> juliank: oh i see
[22:44] <juliank> but libc6-dev is not providing libc-dev anymore, hence only the | libc-dev remains
[22:44] <nacc> right
[22:45] <nacc> it seems like an inherently fragile thing
[22:47] <juliank> nacc: though actually libc6-dev seems to privde libc-dev, but I guess it needs to be installed and isn't. In any case detecting it like this is wrong.
[22:47] <juliank> On my debian this would return libc6-dev-sparc64-cross | libc-dev
[22:47] <juliank> that's not right
[22:47] <juliank> :D
[22:48] <juliank> Should just hardcode libc6-dev there
[22:50] <juliank> (obviously not applicable to debian due to kfreebsd and stuff, but a right solution probably is more complicated)
[22:54] <nacc> juliank: yeah, it feels weird to be build-time dependent on runtime state
[22:56] <juliank> nacc: the problematic thing is just Debian kfreebsd and stuff with libc0.1-dev and whatever
[22:56] <juliank> nacc: but one fun fact to realize: The dpkg-awk match matches a substring :D
[22:58] <nacc> heh
[22:59] <juliank> Could go with grep-aptavail -FProvides libc-dev  --and -FBuild-Essential yes -nsPackage | head -1
[22:59] <juliank> but it's also not really multi-arch friendly
[23:00] <juliank> Could add an and --architecture $(shell dpkg-architecture ...) in there
[23:00] <juliank> Or use LANG=C apt-cache showpkg libc-dev | and grep the first line after Reverse Provides.
[23:01] <juliank> My awk is not strong enough for that
[23:03] <juliank> That does the trick: apt-cache showpkg libc-dev | sed -n '/^Reverse Provides/ { n; p; }' | cut -f1 -d\
[23:05] <juliank> You might want to arch qualify libc-dev with whatever you are building for, though, for cross-compilation bonus points