=== _salem is now known as salem_ === funkyHat_ is now known as funkyHat === salem_ is now known as _salem [05:51] Good morning [06:52] @pilot in === udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [08:33] 3 months in, and my irc stopped working, because let's encrypt certificate did not renew *sigh* [09:05] 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] what is the "right" way to locally reproduce this with e.g. sbuild? [09:06] I've seen the test added http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu [09:06] so should I do like https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs ? [09:06] or is there another preferred method [09:17] it is working, so it can't be too wrong :-) [09:20] 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] 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] I can try to nag them though [09:21] thanks a lot [09:22] yw [09:38] cpaelzer: you might also be able to use --extra-package pointing at an appropriate gcc-defaults package === dholbach_ is now known as dholbach [09:42] mwhudson: thanks, will try that next time [09:42] would not affect the actual chroot which is nice [10:20] cpaelzer: --extra-repository=spec --extra-repository-key=file.asc [10:20] cpaelzer: Adds the PPA on the CLI instead of in the chroot, so only affects that build. [10:20] cpaelzer: (See sbuild(1)) [10:22] 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] infinity: thanks a lot! [10:23] as always if you would know before, what you know after doing/realizing sometihng it would have been much easier :-) [10:23] 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] 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] cpaelzer: +1 for replacing that section with --extra-repo* bits. [10:25] cpaelzer: With a derp-friendly blurb on how to find the public sig for repo.asc, I guess. [10:26] s/sig/key/ [10:29] infinity: does that actually work? i couldn't make --extra-repository-key behave [10:30] but i was probably holding it wrong [10:31] also mk-sbuild is pretty fast, i have a collection with various different ppas enabled [10:33] mwhudson: Works for me. [11:02] 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] cpaelzer: i have a horrible feeling that involves GNUPGHOME=`mktemp -d` or some such horror [11:04] but i'm not really sure :) [11:09] 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] just wanted to leave the chance open if one knows an even better way [11:09] if with "horror" it might not be that much better [11:17] @pilot out === udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko === fginther` is now known as fginther === _salem is now known as salem_ [14:45] infinity, hi, would you be able to review keystone and pythonkeystoneauth1 in the xenial review queue? [14:59] hi folks, quick question [14:59] "what's the file system mounted at /tmp?" <-- buildd/armhf system [14:59] if you want the whole picture: https://github.com/borgbackup/borg/issues/1310 [15:00] LocutusOfBorg: /tmp/ should be a tmpfs in RAM, is it a qemu-static armhf schroot or a native armhf build env.? [15:01] teward, official buildds [15:01] ah, then you'll have to wait for the buildd maintainers to answer that more effectively. [15:02] https://launchpad.net/ubuntu/+source/borgbackup/1.0.5-1 [15:02] this is the build [15:03] kishi04 seems owned by infinity [15:03] but it might be a general issue/configuration I think [15:12] they are also asking the result of getconf PAGE_SIZE [15:14] 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] Launchpad bug 1592865 in keystone (Ubuntu Xenial) "[SRU] mitaka point releases" [Undecided,Incomplete] [15:14] coreycb ^ [15:15] hey folks, is there a formal way to file a remove request for a package in Yakkety? [15:16] bregma, open a bug and subscribe ubuntu-archive [15:16] e.g. 1595485 [15:16] LP: #1595485 [15:16] Launchpad bug 1595485 in singular (Ubuntu) "packages to remove from yakkety" [Undecided,New] https://launchpad.net/bugs/1595485 [15:16] LocutusOfBorg, a bug against Ubuntu or a bug against the particular package? [15:16] the second one [15:16] k thanks [15:17] * bregma likes easy [15:17] well, if the package disappears in Debian, it is semi-automatically removed from ubuntu too [15:17] unless there are rdeps that needs fixing [15:17] it's a Ubuntu-only package [15:18] 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] reverse-depends -r yakkety src:foo; reverse-depends -r yakkety -b src:foo [15:18] and reverse-depends -r yakkety -b libfoo-dev [15:25] 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] LocutusOfBorg: the log of https://launchpad.net/ubuntu/+source/procenv/0.43-2/+build/8361172 should answer your questions [15:28] cjwatson, can I assume it didn't change in the last months then? [15:30] I don't see any mounts: [15:30] /tmp: [15:30] so I presume it is under "/" mount [15:31] indeed, and yes, you can so assume [15:31] thanks! I'm a little bit confused about a non tmpfs tmp :) [15:32] but I can understand the rationale for that indeed [15:32] thanks! [15:32] * LocutusOfBorg leaves [15:32] /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] 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] If you could cast your eyes over it, it would be much appreciated. [16:28] \o/ [16:28] Odd_Bloke: want to talk about the bash -u option now? or are you OK with it being removed? [16:29] 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] Odd_Bloke: sounds good. curious, what would you use instead of bash? [16:31] POSIX sh [16:32] that makes sense. [20:51] 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] 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] slangasek: working on your feedback in https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305 [22:13] semiosis: great :) [22:14] slangasek: can you explain a bit more what you mean in your comment re manage_etc_hosts: localhost... i dont understand [22:14] "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] 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] semiosis: is there some reason that this change should be made *only* for vagrant, which is the effect of the current change? === sakrecoer_ is now known as sakrecoer [22:17] 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] semiosis: hostname setting and resolution seem applicable for other environments than vagrant, AFAICS [22:18] maybe Odd_Bloke has a comment here [22:19] 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] 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] but should fix it in both places [22:21] 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] semiosis: your merge request has a changelog entry which closes that bug ;) [22:21] OH! [22:22] 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] so that does probably need Odd_Bloke's expertise [22:22] or maybe rcj is more likely to be around [22:22] sounds good. i can ping Odd_Bloke tomorrow morning if he doesn't get to it first [22:24] slangasek: i have a xenial ec2 instance and i get the same unable to resolve host there, which supports your idea [22:24] i had not noticed that on the ec2 instance before so i just checked === alexisb is now known as alexisb-afk === DzAirmaX_ is now known as DzAirmaX