[05:51] <pitti> Good morning
[06:52] <dholbach> @pilot in
[08:33] <xnox> 3 months in, and my irc stopped working, because let's encrypt certificate did not renew *sigh*
[09:05] <cpaelzer> Hi, sorry to ask, but I never touched this before - I'm trying to fix an issue with the GCC& build as reported by https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039448.html
[09:06] <cpaelzer> what is the "right" way to locally reproduce this with e.g. sbuild?
[09:06] <cpaelzer> I've seen the test added http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu
[09:06] <cpaelzer> so should I do like https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs ?
[09:06] <cpaelzer> or is there another preferred method
[09:17] <cpaelzer> it is working, so it can't be too wrong :-)
[09:20] <dholbach> hey seb128 - can you or anyone in your team take a look at https://code.launchpad.net/~jbicha/indicator-session/lp1600502-fix-icon-install/+merge/299625?
[09:21] <seb128> dholbach, hey, I guess I can try having a look, though my cmake foo is weak, might be one rather for charles or ted
[09:21] <seb128> I can try to nag them though
[09:21] <dholbach> thanks a lot
[09:22] <seb128> yw
[09:38] <mwhudson> cpaelzer: you might also be able to use --extra-package pointing at an appropriate gcc-defaults package
[09:42] <cpaelzer> mwhudson: thanks, will try that next time
[09:42] <cpaelzer> would not affect the actual chroot which is nice
[10:20] <infinity> cpaelzer: --extra-repository=spec --extra-repository-key=file.asc
[10:20] <infinity> cpaelzer: Adds the PPA on the CLI instead of in the chroot, so only affects that build.
[10:20] <infinity> cpaelzer: (See sbuild(1))
[10:22] <cpaelzer> infinity: I searched for ppa in there and the web but you never know how it is called ina  given context in advance - of course it is repository not ppa as it is the more generic term
[10:22] <cpaelzer> infinity: thanks a lot!
[10:23] <cpaelzer> as always if you would know before, what you know after doing/realizing sometihng it would have been much easier :-)
[10:23] <cpaelzer> I think I should try to mention that in https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs to not mislead the next
[10:24]  * cpaelzer is checking if he can edit there ...
[10:24] <infinity> cpaelzer: Yeah, the advice to mangle the chroot is certainly not ideal, since one can easily end up with a dirty base chroot and have to start over.
[10:24] <infinity> cpaelzer: +1 for replacing that section with --extra-repo* bits.
[10:25] <infinity> cpaelzer: With a derp-friendly blurb on how to find the public sig for repo.asc, I guess.
[10:26] <infinity> s/sig/key/
[10:29] <mwhudson> infinity: does that actually work? i couldn't make --extra-repository-key behave
[10:30] <mwhudson> but i was probably holding it wrong
[10:31] <mwhudson> also mk-sbuild is pretty fast, i have a collection with various different ppas enabled
[10:33] <infinity> mwhudson: Works for me.
[11:02] <cpaelzer> infinity: mwhudson: I replaced the modding of the chroot with the sbuild options, my gpg key foo was good enough to get them to work - but surely not perfect. If one has a sequence that works without ever touching the local keyreing please feel free to let me know or modify in place https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs
[11:04] <mwhudson> cpaelzer: i have a horrible feeling that involves GNUPGHOME=`mktemp -d` or some such horror
[11:04] <mwhudson> but i'm not really sure :)
[11:09] <cpaelzer> mwhudson: no need for Horror on a Monday :-) what I have written works and is surely less damaging than what the wiki page said before
[11:09] <cpaelzer> just wanted to leave the chance open if one knows an even better way
[11:09] <cpaelzer> if with "horror" it might not be that much better
[11:17] <dholbach> @pilot out
[14:45] <coreycb> infinity, hi, would you be able to review keystone and pythonkeystoneauth1 in the xenial review queue?
[14:59] <LocutusOfBorg> hi folks, quick question
[14:59] <LocutusOfBorg> "what's the file system mounted at /tmp?" <-- buildd/armhf system
[14:59] <LocutusOfBorg> if you want the whole picture: https://github.com/borgbackup/borg/issues/1310
[15:00] <teward> LocutusOfBorg: /tmp/ should be a tmpfs in RAM, is it a qemu-static armhf schroot or a native armhf build env.?
[15:01] <LocutusOfBorg> teward, official buildds
[15:01] <teward> ah, then you'll have to wait for the buildd maintainers to answer that more effectively.
[15:02] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/borgbackup/1.0.5-1
[15:02] <LocutusOfBorg> this is the build
[15:03] <LocutusOfBorg> kishi04 seems owned by infinity
[15:03] <LocutusOfBorg> but it might be a general issue/configuration I think
[15:12] <LocutusOfBorg> they are also asking the result of getconf PAGE_SIZE
[15:14] <ddellav> pitti when you get a second, can you or someone else on the SRU team take a look at https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1592865? It's good to go
[15:14] <ddellav> coreycb ^
[15:15] <bregma> hey folks, is there a formal way to file a remove request for a package in Yakkety?
[15:16] <LocutusOfBorg> bregma, open a bug and subscribe ubuntu-archive
[15:16] <LocutusOfBorg> e.g. 1595485
[15:16] <LocutusOfBorg> LP: #1595485
[15:16] <bregma> LocutusOfBorg, a bug against Ubuntu or a bug against the particular package?
[15:16] <LocutusOfBorg> the second one
[15:16] <bregma> k thanks
[15:17]  * bregma likes easy
[15:17] <LocutusOfBorg> well, if the package disappears in Debian, it is semi-automatically removed from ubuntu too
[15:17] <LocutusOfBorg> unless there are rdeps that needs fixing
[15:17] <bregma> it's a Ubuntu-only package
[15:18] <LocutusOfBorg> so, if you don't want to make things difficult to both you and archive team (like I did in the above bug)
[15:18] <LocutusOfBorg> reverse-depends -r yakkety src:foo; reverse-depends -r yakkety -b src:foo
[15:18] <LocutusOfBorg> and reverse-depends -r yakkety -b libfoo-dev
[15:25] <coreycb> ddellav, I pinged infinity in here a little while ago about keystone and keystoneauth1 since he has Mondays for the sru team:  https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[15:26] <cjwatson> LocutusOfBorg: the log of https://launchpad.net/ubuntu/+source/procenv/0.43-2/+build/8361172 should answer your questions
[15:28] <LocutusOfBorg> cjwatson, can I assume it didn't change in the last months then?
[15:30] <LocutusOfBorg> I don't see any mounts:
[15:30] <LocutusOfBorg>   /tmp:
[15:30] <LocutusOfBorg> so I presume it is under "/" mount
[15:31] <cjwatson> indeed, and yes, you can so assume
[15:31] <LocutusOfBorg> thanks! I'm a little bit confused about a non tmpfs tmp :)
[15:32] <LocutusOfBorg> but I can understand the rationale for that indeed
[15:32] <LocutusOfBorg> thanks!
[15:32]  * LocutusOfBorg leaves
[15:32] <cjwatson> /tmp is an FHS-mandated directory regardless of what filesystem it's on, and on buildds I think it makes sense to leave the memory for compilers to use
[16:18] <Odd_Bloke> slangasek: infinity: https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305 <-- this fixes some major pain points with using Vagrant images (for xenial and later), which we'd like to (a) fix in yakkety, and (b) SRU to xenial
[16:19] <Odd_Bloke> If you could cast your eyes over it, it would be much appreciated.
[16:28] <semiosis> \o/
[16:28] <semiosis> Odd_Bloke: want to talk about the bash -u option now?  or are you OK with it being removed?
[16:29] <Odd_Bloke> semiosis: I'm happy with it being removed; we need to do some clean-up there (to, for example, switch away from bash), so it's a more pervasive change than makes sense for this.
[16:30] <semiosis> Odd_Bloke: sounds good.  curious, what would you use instead of bash?
[16:31] <slangasek> POSIX sh
[16:32] <semiosis> that makes sense.
[20:51] <rharper> slangasek: smoser and I are starting a curtin SRU,  do you prefer a single SRU bug, or can we just use the individual bugs (we've four of them) in the changelog/debdiff ?
[22:09] <slangasek> rharper: if there's been discussion about SRU exception process for curtin, it's not captured on https://wiki.ubuntu.com/StableReleaseUpdates; individual bugs are probably best here
[22:13] <semiosis> slangasek: working on your feedback in https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
[22:13] <slangasek> semiosis: great :)
[22:14] <semiosis> slangasek: can you explain a bit more what you mean in your comment re manage_etc_hosts: localhost... i dont understand
[22:14] <semiosis> "The bug reference for this makes sense in terms of why this is wanted; but why is this a vagrant-specific change? I'm skeptical of this being a delta vs. 999-cpc-fixes.chroot."
[22:14] <slangasek> semiosis: so, you're adding this into a cloud-init userdata that's specific to the vagrant image. the 999-cpc-fixes.chroot hook also creates cloud-image userdata for the generic cloud image
[22:15] <slangasek> semiosis: is there some reason that this change should be made *only* for vagrant, which is the effect of the current change?
[22:17] <semiosis> slangasek: well I'm not an expert on that subject.  not sure if it's generally useful to other cloud images (although I can imagine how it would be!)
[22:18] <slangasek> semiosis: hostname setting and resolution seem applicable for other environments than vagrant, AFAICS
[22:18] <slangasek> maybe Odd_Bloke has a comment here
[22:19] <semiosis> slangasek: however, since the vagrant builder combines the cloud-init stuff into an ISO which gets bundled in the vagrant box, we do need to generate cloud-init config in the vagrant builder.  unless you'd suggest going back and modifying the vagrant box in the 999 step
[22:19] <slangasek> semiosis: I'm saying that if this is a bug affecting multiple images, we shouldn't fix it in just one of the images and close the bug
[22:19] <slangasek> but should fix it in both places
[22:21] <semiosis> slangasek: that makes sense.  but i dont see how that matters for my merge request... even if that change were needed elsewhere, it is still needed in the vagrant builder, no?
[22:21] <slangasek> semiosis: your merge request has a changelog entry which closes that bug ;)
[22:21] <semiosis> OH!
[22:22] <slangasek> and regardless, before merging I would want to be sure we either have a reason not to apply it to the other userdata, or apply it equally in both places
[22:22] <slangasek> so that does probably need Odd_Bloke's expertise
[22:22] <slangasek> or maybe rcj is more likely to be around
[22:22] <semiosis> sounds good.  i can ping Odd_Bloke tomorrow morning if he doesn't get to it first
[22:24] <semiosis> slangasek: i have a xenial ec2 instance and i get the same unable to resolve host there, which supports your idea
[22:24] <semiosis> i had not noticed that on the ec2 instance before so i just checked