=== maclin1 is now known as maclin
[08:46] <ackk> hi, can anyone advise on how to debug this issue: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1697450 ?
[08:46] <ubottu> Launchpad bug 1697450 in ubiquity (Ubuntu) "Installer freezes at session startup" [Undecided,New]
[08:46] <ackk> it's actually not an ubiquity-specifc problem
[08:46] <ackk> *specific
[11:31] <chipcha> hello at all
[15:02] <rbasak> !dmb-ping
[15:02] <ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
[16:29] <jbicha> slangasek: should we set python3.6 as the only supported python3 version for artful now?
[16:30] <slangasek> jbicha: I defer to mwhudson who is managing this transition.  Is there urgency?
[16:30] <jbicha> mwhudson deferred to you or doko when I asked him :)
[16:31] <jbicha> no urgency, but I assume we won't be providing python3.5 at all by the time artful is released?
[16:31] <slangasek> correct
[16:32] <jbicha> most of python3.5's rdepends now are because it's still 'supported'
[16:32] <slangasek> "now are" what?
[16:35] <jbicha> because python3.5 is supported, some packages have dependencies on both python3.5 and python3.6 when they are built
[16:36] <jbicha> I think that's all of 'reverse-depends src:python3.5' except for a couple packages that FTBFS
=== alan_g is now known as alan_g|EOD
=== ogra_ is now known as ogra
[17:28] <nacc> dannf: are you still working on LP: #1676884 in debian?
[17:28] <ubottu> Launchpad bug 1676884 in makedumpfile (Ubuntu) "kdump-tools uses the wrong crashkernel command line parameter in ppc64le" [High,New] https://launchpad.net/bugs/1676884
[17:29] <dannf> nacc: i've proposed a fix for it, but it hasn't been merged yet
[17:29] <dannf> nacc: at least, the kdump-tools bit
[17:29] <nacc> dannf: ok, wasn't sure how active you were on it, i just got pinged by the submitter on status
[17:37] <xnox> juliank, apt without unatteded-upgrades --download-only flag is useless for us. Whilst apt update is happening randomly, the heavy download all the debs is still staggered with upgrade at 6am.
[17:38] <xnox> juliank, because apt-get --download-only is not the default
[17:38] <xnox> and --download-only is missing.
[17:38] <xnox> and --download-only is missing from unattened-upgrades
[17:38] <juliank> xnox: Yeah, we need to SRU that as well.
[17:38] <juliank> But then we're done
[17:39] <xnox> but is it in debian, or ubuntu? i don't see where/when download only mode in unattened upgrade was intorduced.
[17:39] <xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863911
[17:39] <ubottu> Debian bug 863911 in unattended-upgrades "unattended-upgrades: Needs a --download-only mode" [Important,Open]
[17:39] <juliank> No, it's not, apparently mvo is really busy. I should pick the commits and upload it myself
[17:39] <juliank> It's in the git
[17:40] <xnox> is this the only bit that is needed? https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=863911;filename=unattended-upgrade.diff;msg=5 ?
[17:40] <xnox> we'd love to keep this minimal, if we must ship it by thursday.
[17:40] <juliank> No, we also need the test suite fix rbalint made
[17:40] <xnox> cause e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=863911;filename=unattended-upgrade.diff;msg=5 is reviewable by slangasek / infinity
[17:41] <xnox> juliank, can you point to where that is? which git repository?
[17:41] <xnox> or rbasak
[17:41] <xnox> unping
[17:41] <xnox> rbasak, unping
[17:41] <xnox> rbalint, ping ^
[17:41] <juliank> That's it: https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91 https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6
[17:41] <juliank> I mentioned these commits a week ago ... ;)
[17:42] <xnox> good you =)
[17:43] <juliank> xnox: In any case, it would be good to coordinate with rbalint so we don't end up with conflicting uploads ;)
[17:43] <juliank> he's working on bug 1690980
[17:43] <ubottu> bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
[17:43] <xnox> yeah i know.
[17:44] <juliank> ok
[17:45] <juliank> xnox: Apparently mvo tagged a new u-u release (0.94) 3 days ago, but did not upload it.
[17:45] <juliank> Slightly odd
[17:49] <rbalint> juliank, xnox: yes, i'm wondering why mvo did not upload it yet
[17:53] <rbalint> juliank, xnox: bdmurray said he would give u-u another round of tests for LP: #1690980
[17:53] <ubottu> Launchpad bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
[17:54] <xnox> juliank, rbalint - i would consider upload /just/ the download-only bits, without the rest of the u-u bits for shutdowns etc.
[17:55] <cjwatson> stgraber: A week or two ago you posted a buildd-chroot-to-LXD-image conversion script, which has been very useful to me, thanks - I'm attempting to integrate it into launchpad-buildd.  However, I'm running into difficulty because the chroot doesn't have any networking tools, so AFAICS the network is never brought up inside the container and there's no way to do so.  Did you get the chroot to ...
[17:55] <cjwatson> ... the point of having working networking?
[17:55] <juliank> xnox: I agree
[17:55] <rbalint> xnox, juliank: i pinged mvo via email
[18:01] <stgraber> cjwatson: yeah, I don't believe I did anything with the network in there after I go the script going.
[18:02] <cjwatson> It's not totally obvious to me what the best way to proceed is :-(
[18:02] <rbalint> xnox, juliank: i would wait for a few hours
=== JanC is now known as Guest68181
=== JanC_ is now known as JanC
[18:05] <bdmurray> rbalint: I will do the test soon
[18:06] <cjwatson> infinity: ^- are you aware of this "make at least some builds use containers rather than chroots" project, and do you have any thoughts about handling it from the chroot management point of view?  It just suddenly got a lot more complicated if we're going to have to munge the chroots in non-trivial ways to make them work as containers.
[18:06] <rbalint> bdmurray: thanks!
[18:07] <stgraber> cjwatson: printf "lxc.network.0.ipv4=10.204.119.2/24\nlxc.network.0.ipv4.gateway=10.204.119.1" | lxc config set test-xenial raw.lxc -
[18:08] <infinity> cjwatson: Err, no.  I'm not aware of this, and why is this happening?
[18:08] <bdmurray> rbalint: given that the fix for the bug will be SRU'ed can you add the test case we discussed on friday to the bug description?
[18:08] <cjwatson> infinity: basically in order to be able to use snaps as build-dependencies for other snaps.  get slangasek to fill you in :)
[18:09] <cjwatson> stgraber: hm, interesting.  how would I pick those addresses?
[18:09] <infinity> cjwatson: Could someone maybe fix snapd to work in chroots?
[18:09] <stgraber> cjwatson: that's a bit of a workaround because LXD doesn't usually let you pre-configure the network namespace (as it's very rarely a good idea), but in this case it's probably your best bet short of adding a bunch of stuff to the chroot
[18:09] <infinity> Sort of a long-standing bug anyway.
[18:10] <stgraber> cjwatson: just needs to be an address in whatever subnet lxdbr0 is using. You can configure lxdbr0 with a fixed subnet to make that easier
[18:10] <cjwatson> infinity: that's a pretty big ask
[18:11] <rbalint> bdmurray: sure
[18:11] <infinity> cjwatson: So is converting the buildd setup to use containers.
[18:11] <cjwatson> infinity: I have that mostly done
[18:12] <cjwatson> apart from this roadblock that I discovered at the eleventh hour
[18:12] <infinity> cjwatson: It also just leaves a bad taste in my mouth to add even more stuff to build-essential.
[18:12] <cjwatson> yeah, I'd prefer to avoid that
[18:12] <infinity> cjwatson: (I mean, not actually build-essential, but "build-cruft")
[18:12] <infinity> cjwatson: And if you're running in full containers with networking and systemd, that's what you get.
[18:12] <cjwatson> if stgraber's gadget works then maybe we can still use basically identical root images
[18:13] <cjwatson> stgraber: heh, "lxd init --auto" in this container apparently gave me an IPv6-only lxdbr0 ...
[18:14] <slangasek> infinity: running any services in chroots is a no-go in systemd land
[18:14] <cjwatson> slangasek: the chroots already ship a policy-rc.d that disables nearly everything
[18:15] <cjwatson> so assuming that works properly in a lxd/systemd context ...
[18:15] <infinity> It does.
[18:15] <cjwatson> (that's a slight tangent, but relevant to the question you asked the other day)
[18:15] <slangasek> cjwatson: yes; my point is that you *can't* run systemd in a chroot, so "make snapd run in a chroot" is very much not a snapd issue
[18:16] <infinity> slangasek: I suppose I could argue it's a snapd issue for implementing everything it does as systemd jobs, but... :P
[18:17] <infinity> The very notion that I can't install snaps in a chroot has always rubbed me the wrong way.  Seems like a step backward.
[18:18] <stgraber> cjwatson: yeah, I'm assuming you're doing all that with LXD 2.0.x rather than the backport (which makes sense). LXD 2.0.x is a bit more annoying to configure due to not having the nice "lxc network XYZ" commands. You likely just want to replace /etc/default/lxd-bridge with some static version of the config, then bounce the lxd-bridge service.
[18:20] <infinity> cjwatson: Anyhow, if container-based buildds become the new hotness, I might look at further optimising by making the root image a squash instead of a tarball, and we can just mount it instead of unpacking.
[18:21] <infinity> cjwatson: Though, I suppose we need to keep both methods alive and well or we have some large hurdles for new arch bootstrapping for that inevitable "we never thought we'd have another, but there it is" port.
[18:21] <cjwatson> infinity: Right, I'm making it switchable
[18:22] <cjwatson> infinity: Not least because I don't want to change .deb builds (yet, anyway)
[18:22] <infinity> Actually, I take that back.  I could make a chroot-based sbuild use a squash base trivially too.  So maybe I'll look into that later.
[18:23] <infinity> (or schroot, given your low prio pending MP)
[18:23] <cjwatson> infinity: The tarball is useful here because we need to munge it a little bit for LXD.  http://paste.ubuntu.com/25119707/ was stgraber's prototype of this
[18:26] <infinity> cjwatson: I could be blind, but I'm missing the bit where that changes anything.
[18:27] <infinity> Oh.  I see.
[18:28] <infinity> So, the hardlink thing would just go away if it was a filesystem instead of a tarball.
[18:28] <cjwatson> infinity: metadata insertion too
[18:28] <infinity> Then you'd just have the metadata thing, which I'd kinda like to hope can live beside an image instead of in it.
[18:28] <infinity> Cause didn't we have a mandate for a "one true rootfs", it would seem silly for that to have to have LXD stuff in it.
[18:28] <infinity> But also, we could just build it that way if we had to.
[18:29] <cjwatson> infinity: and although it's not in that prototype, so far I've in practice needed to insert /etc/{hosts,hostname,resolv.conf} into the image rather than applying it just after starting things up the way we do for chroots (can't do lxc file push until after lxc start, and lxc start does things that look at those files)
[18:30] <cjwatson> oh wait, actually lxc file push does work as long as I do it after lxc init, never mind that bit
[18:31] <stgraber> I was about to say :)
[18:32] <stgraber> infinity: yeah, I'm only stuffing the metadata in the tarball because I needed to repack it anyway
[18:32] <stgraber> infinity: LXD does support taking two tarballs, one which is the rootfs and another that's the metadata bits, but it needs the rootfs tarball to contain the rootfs at its root (which the build chroots don't)
[18:33] <infinity> stgraber: Sure, that's fixable.
[18:33] <infinity> stgraber: Though, as I said, I was tossing around s/tgz/squash/ as an opimisation.
[18:33] <infinity> optimisation, too.
[18:33] <infinity> Typing is hard.
[18:34] <cjwatson> I'd be happy to make launchpad-buildd tolerate either ./ or chroot-autobuild/ if we were planning to change the chroots to match.
[18:35] <infinity> Yeah, that's a trivial change.
[18:36] <cjwatson> I'm tearing all that stuff apart and putting it together differently anyway
[18:36] <infinity> The only reason it's the way it is is Kinnison originally did it that way, and I didn't strip the leading component because I prefer things to not vomit on my FS when I unpack them.
[18:36] <infinity> Though I did ubuntu-core^Wubuntu-base without a leading path, cause it's The Right Way to do a rootfs.
[18:36] <cjwatson> (sbuild-launchpad-chroot might want pre-adjustment too, though.)
[18:38] <cjwatson> Though stgraber's munger doesn't change it to be without a leading path - it changes it to have a leading rootfs/
[18:38] <cjwatson> Unless that's different in the two-tarball case.
[18:39] <infinity> Huh, indeed it does.  That's odd.
[18:40] <infinity> "Guys, you shouldn't hardcode leading paths, cause I hardcode different leading... Oh."
[18:40] <stgraber> haha, no. LXD either takes a single tarball with metadata and rootfs mixed, in which case the rootfs must be under "rootfs/". Or it takes two tarballs, one with the metadata and the other with the rootfs at its root.
[18:41] <rbalint> bdmurray: the plan is back-porting the whole u-u package, not just the targeted fix thus there will be a new bug for that
[18:41] <stgraber> that second format is what we used for the cloud-images for example and what you'd want to use if you want to avoid repacking
[18:41] <cjwatson> ah right
[18:42] <bdmurray> rbalint: ah, got it
[18:42] <infinity> stgraber: Probably a few years late to question the design, but rather than "/metadata and /rootfs/<realstuff>", why not "/<realstuff> and /var/lib/lxd-init/metadata", so it didn't need the leading component?
[18:44] <stgraber> infinity: that'd be putting a file in the container root filesystem which the container user wouldn't otherwise need to see
[18:44] <stgraber> infinity: also, some of our images don't have such a thing as /var :)
[18:44] <infinity> stgraber: Sure.
[18:44] <infinity> stgraber: /lib/lxc-init/poop then. :P
[18:45] <infinity> stgraber: But yeah, I get the urge to make it pristine and poop-free.
[18:46] <infinity> Ever absentmindedly scratch at a limb and, a bit later, look down and realise you're bleeding profusely?
[18:46] <stgraber> it's also possible that someone would publish an image which contains confidential information in the image metadata that needs to be used by the host when creating the container but shouldn't be visible to the user inside the container
[18:46] <infinity> Yeah, me neither...
[18:46] <infinity> (AFK)
[18:52] <slangasek> infinity the leper
[19:55] <slangasek> nacc: does LP: #1700826 have your ack on behalf of server team?  dannf raised all the MPs, but I haven't seen an acknowledgement from the server team that this is wanted on server-ship so I'm not merging it with my core-dev hat
[19:55] <ubottu> Launchpad bug 1700826 in ubuntu-meta (Ubuntu Zesty) "please include numactl on the ubuntu-server iso" [Undecided,In progress] https://launchpad.net/bugs/1700826
[21:09] <nacc> slangasek: let me double-check with the team tmrw AM
[22:08] <mwhudson> jbicha, slangasek, doko: the only reason to not de-support python3.5 would be any entanglement with other transitions i guess
[22:08] <mwhudson> i presume it would be much easier than the "support 3.6" transition
[22:48] <slangasek> mwhudson: in general, the dropping of python3.5 from python3-all* should not entangle anything else and you just get small self-contained transitions of individual dependency trees as they get rebuilt
[22:48] <slangasek> and then eventually we sweep up the remainder with some no-change rebuilds so that we can rip out python3.5
[23:10] <mwhudson> slangasek: so we should aim to do that before feature freeze?
[23:10] <slangasek> mwhudson: yes - and from my side I know of no blockers for doing it immediately, given that 3.5+3.6 has migrated to artful
[23:11] <mwhudson> slangasek: ok, sounds like something i can get on with during my intermittent availability
[23:11] <slangasek> mwhudson: you may want to double-check with doko to be extra-sure there aren't known entanglements I'm overlooking, since gcc is impending
[23:11] <mwhudson> slangasek: start with the python3-defaults update, then gradually work through the things preventing it migrating?
[23:12] <mwhudson> slangasek: ok
[23:12] <slangasek> mwhudson: there should in fact be nothing that prevents it from migrating, IIUC
[23:12] <mwhudson> oh right yes
[23:12] <mwhudson> just things preventing us removing python3.5
[23:13] <slangasek> even things that had a versioned runtime dep on python3-something (<< 3.6) have already been resolved, so yeah
=== mwsb is now known as chu