=== unixpro1970 is now known as _unixpro1970
[01:04] <mwhudson> oh fun https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1574916
[01:04] <ubottu> Launchpad bug 1574916 in golang-1.6 (Ubuntu) "go test -race os/exec fails on yakkety" [Undecided,New]
[01:09] <mwhudson> is there someway i can temporarily crowbar the pie default off?
[01:12] <slangasek> mwhudson: e.g. export DEB_CFLAGS_MAINT_APPEND=-fno-pie ?
[01:14] <mwhudson> slangasek: not in a package build, but i think i see where to stick that in
[01:16] <mwhudson> nope, doesn't help
[01:17] <slangasek> hmm. is it spelled -no-pie?
[01:17] <slangasek> (manpage suggests it may be, and I don't remember)
[01:18] <mwhudson> ah yes
[01:18] <mwhudson> this is for the linker, not the compiler
[01:18] <mwhudson> go test -race -ldflags='-linkmode=external -v -extldflags=-no-pie' -run='^$' os/exec -> ok
[01:18] <mwhudson> with -fno-pie or with no extldflags, boom
[01:19] <mwhudson> slangasek: while i'm talking to you about horrible things, https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1574904
[01:19] <ubottu> Launchpad bug 1574904 in docker.io (Ubuntu) "Docker compiled with wrong version of Go" [Undecided,New]
[01:19] <slangasek> wut
[01:20] <mwhudson> yes, wut
[01:21] <slangasek> mwhudson: ohhh you've already responded to the bug; missed opportunity to say "haven't you ever used Go before?  golang 1.6 is the only go, get with the program"
[01:21] <slangasek> mwhudson: also, IIRC accommodating this request would mean regressing architecture support
[01:21] <mwhudson> slangasek: somehow i doubt that would work with docker upstream
[01:21] <mwhudson> slangasek: oh yes, that's a good point
[01:21] <sarnold> .. and undoing whatever security fixes may exist in only newer branches
[01:22] <mwhudson> sarnold: go 1.5 has security support until 1.7 is released, fwiw
[01:22] <sarnold> mwhudson: ah, good, that's six weeks longer than I expected :)
[01:23] <sarnold> (sorry, sorry...)
[01:23] <mwhudson> :-)
[01:28] <mwhudson> what does the linker, specifically, do differently when you pass -pie vs -no-pie?
[01:57] <infinity> mwhudson: Hahahahahahaha (re: docker vs go)
[01:58] <mwhudson> infinity: pretty much
[01:58] <infinity> mwhudson: Is there no way to detect compiler version and do sane things regardless?
[01:58] <mwhudson> infinity: not sure what you mean, it's a standard library change that's causing the problem here
[01:58] <mwhudson> infinity: 1.6 validates host: properly, 1.5 didn't
[01:59] <mwhudson> it must be possible to hack things so that it doesn't validate the header properly again but it might not be simple
[01:59] <infinity> mwhudson: Oh, right, because HTTP validation belongs in a standard library.  Check.
[01:59]  * infinity keeps forgetting that Go can't decide if it's C or PHP.
=== _unixpro1970 is now known as unixpro1970
[02:00] <mwhudson> in 2016? yes, i'd say it does
[02:00] <mwhudson> the joke is more on docker here, aiui
=== unixpro1970 is now known as _unixpro1970
[02:05] <infinity> mwhudson: Wow, that ticket is a mess.
[02:06] <infinity> mwhudson: Yes, joke's on docker, but I think they've also neetly proven why the model is crap.
[02:06] <infinity> "I ship an ancient docker in my images so it works with all docker daemons on all hosts, and am thus stuck with every security bug ever, and you have to support every broken behaviour ever."
[02:06] <infinity> Uh huh.
[02:06] <infinity> Dear docker: flag day.
[02:10] <mwhudson> oh yeah
[02:10] <infinity> mwhudson: Not joking here, but perhaps it's time to suggest to docker upstream that this is a perfect opportunity to audit their API, clean up any messes, release a 2.0 that's intentionally backward-incompatible, and migrate the world.
[02:11] <infinity> mwhudson: And, for bonus points, version their APIs going forward, so clients aren't connecting blind to they-don't-know-what.
[02:12] <infinity> All seems a bit ironic, given that the docker crowd seems to intersect very broadly with version fetishists.
[02:12] <infinity> And, yet, run ancient versions because they have to.
[02:18] <infinity> mwhudson: Rather than vendoring the entire module/object/whatever, is there no elegant way in go to just undef on symbol and overload the problematic function with a local copy?
[02:18] <infinity> s/on symbol/one symbol/
[02:18] <mwhudson> no
[02:18] <infinity> Irksome.
[02:18] <mwhudson> yeah
[02:19] <mwhudson> if we had dynamic linking... (but maybe not even then, would depend on $details i suspect)
[02:21] <infinity> mwhudson: Third option, hack go1.6 for "if project == docker { skip host validation }" ... If there's a way to determine that.
[02:21] <infinity> (Ew)
[02:28] <mwhudson> hm my first hack didn't work
[02:28]  * mwhudson afk for a bit
=== salem_ is now known as _salem
[05:46] <cpaelzer> good morning
=== _unixpro1970 is now known as unixpro1970
[06:18] <pitti> Good morning
[06:18] <pitti> doko: yes, I'm going through all regressions on excuses now
[06:23] <RAOF> pitti: Enjoy your shiny new colord.
[06:30] <pitti> slangasek: running (always failed) already does not block a package
[06:30] <pitti> slangasek: I think what doko meant is that the non-failling ones got added too; I had to temporarily disable s390x testing due to getting segfaults in lxc
[06:31] <pitti> xnox: armhf containers have ports.u.c. apt sources; http://autopkgtest.ubuntu.com/packages/b/binutils/yakkety/armhf/ is fine, where did you see this?
=== unixpro1970 is now known as _unixpro1970
=== _unixpro1970 is now known as unixpro1970
=== unixpro1970 is now known as _unixpro1970
=== zyga is now known as zyga_
[08:32] <mwhudson> infinity: i came up with something even more evil https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1574904/comments/3
[08:32] <ubottu> Launchpad bug 1574904 in docker.io (Ubuntu) "Docker compiled with wrong version of Go" [Undecided,New]
=== zyga_ is now known as zyga
[08:39] <zyga> hey mwhudson :)
[08:39] <mwhudson> zyga: hi
[08:39] <zyga> long time no see, how are you doing?
[08:41] <mwhudson> good, doing lots of this crazy packaging stuff now :)
[08:42] <zyga> packaging? are you still working on go toolchain?
[08:42] <mwhudson> the go toolchain stuff is mostly done, now we need to start using it in ubuntu
[08:54] <pitti> tjaalton: please upload the fix for bug 1562033 to yakkety
[08:54] <ubottu> bug 1562033 in xinit (Ubuntu Yakkety) "package xinit 1.3.4-3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,In progress] https://launchpad.net/bugs/1562033
[08:54] <tjaalton> indeed
[08:55] <tjaalton> done
[08:56] <pitti> tjaalton: cheers
[09:15] <caribou> Anything changed with NetworkManager and/or lxd ? containers created yesterday no longer start
[09:24] <apw> caribou, yakkety or xenial ?
[09:24] <caribou> apw: yakkety but looks like it is a dnsmasq problem
[09:24] <apw> with the freeze on i would not expect any of those to have changed as yet
[09:25] <caribou> apw: some dnsmasq process was blocking the correct start of lxd-bridge
[09:25] <apw> nasty
[09:26] <caribou> my syslog has been filled with dnsmasq insults for a while
[09:26] <caribou> I'll soon re-install from scratch anyway
[09:28] <apw> you have metalic cahoonas :)
=== seb128_ is now known as seb128
=== _unixpro1970 is now known as unixpro1970
[09:46] <Mirv> xnox: sorry, no time today either for looking at the png issue. with a quick glance to code.qt.io I don't see png related changes in the tests at least.
[09:47] <Mirv> (qtbase/tests/auto/gui/image/qimagereader)
[09:47] <Mirv> it seems doko disabled the tests in yakkety though for now
[09:53] <xnox> pitti, it was in the log that i saw during running on the autopkgtest debci instance =/
[09:53] <xnox> can't find relevant things in the logs.
[10:20] <doko> Mirv, yes, I did, and it now migrated
=== Malsasa_ is now known as Malsasa
[10:56] <abhinav--> Sorry for the off topic question, but, how are the man pages at manpages.ubuntu.com generated?
[11:00] <mgedmin> the footer links to https://launchpad.net/ubuntu-manpage-repository, which has the scripts
[11:01] <abhinav--> mgedmin, awesome, thanks! :)
[11:32] <nebuchadnezzar> hello, I'm looking for the chan to speak about https://help.ubuntu.com/community/InstallCDCustomization, it looks like configuring gfxboot is not working the same way on 16.04 than 14.04, I tried to rebuild the ISO with “echo fr > isolinux/lang” to preselect the language without success
[11:36] <mitya57> Hi, can someone please reject metacity from yekkety-proposed? I uploaded wrong version…
[11:37] <Laney> mitya57: *flush*
[11:37] <mitya57> Thanks Laney
=== _salem is now known as salem_
[11:48] <seb128> is bug #1575126 a dpkg issue?
[11:48] <ubottu> bug 1575126 in update-manager (Ubuntu) "Upgrade from Wily to Xenial failed : "Could not install gconf2"" [Undecided,New] https://launchpad.net/bugs/1575126
[11:48] <seb128> "dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' failed."
[11:49] <seb128> seems like bug 1551623
[11:49] <ubottu> bug 1551623 in gconf (Ubuntu) "package gconf2 3.2.6-3ubuntu6 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Critical,Triaged] https://launchpad.net/bugs/1551623
[13:06] <yofel> As a Kubuntu Dev, is there any special knowledge I should have if I intend to apply for core-dev?
[13:06] <yofel> I've got 5 years of packaging experience, I know the release process, the package sets, seeds, what MIRs are, how britney works.. anything else I should read up on? (Other than doing the usual application paperwork)
[13:37] <doko> sinzui, fyi, juju-mongodb fails to build in yakkety with new boost
[13:38] <sinzui> :/
[13:38] <sinzui> thank you doko
[13:38] <sinzui> doko: juju-mongodb or juju-mongodb2.6?
[13:38]  * sinzui hopes to drop packages
[13:40] <doko> sinzui, both
[13:40] <sinzui> oh, thank is more dispapointing
[13:40] <sinzui> s/thank/that/
=== zyga_ is now known as zyga
[14:13] <seb128> bdmurray, hey, do you know if there are issues with the changelog server again? http://changelogs.ubuntu.com/changelogs/binary/g/gnome-calendar/3.20.1-1ubuntu1 is missing (unsure if the only one, just happened to hit that one while testing a gnome-software sru candidate)
[14:16] <bdmurray> seb128: I don't know but will try and have a look
[14:32] <seb128> bdmurray, thanks
=== Malsasa_ is now known as Malsasa
[14:53] <xnox> i fail at policykit and udisks2
[15:04] <infinity> mwhudson: That's definitely more evil.
=== infinity 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:
[15:56] <slangasek> infinity, kees, mdeslaur, stgraber: TB meeting, you gluttons for punishment
[15:56] <mdeslaur> \o
[16:00] <pitti> bdmurray: do we merely need to sru-release bug 1560797 as usual, or is there special magic for the release upgrader?
[16:00] <ubottu> bug 1560797 in ubuntu-release-upgrader (Ubuntu) "apt does not configure Pre-Depends: before depending package" [Undecided,Confirmed] https://launchpad.net/bugs/1560797
[16:00] <pitti> bdmurray: I'm inclined to release this ASAP, given how much breakage this causes
[16:02] <bdmurray> pitti: No, we just need to release it. slangasek might really want to test his greek bug though.
[16:02] <slangasek> the SRU team might want to not release it before it's been verified, yes ;)
[16:02] <pitti> bdmurray: right, just wanted to know in general, as I just saw your v-done (thanks!)
[16:53] <jamespage> doko, apologies - I have have inadvertenly backed out your changes to ceph for the boost transition
[16:53] <jamespage> doko, I'll ressurect them with my next upload...
[16:56] <xnox> jamespage, hm?!
[16:57] <xnox> jamespage, i'm sure you didn't =) it was no change rebuild, and we need new ceph, as old ceph doesn't build with new boost =) only new ceph does
[17:03] <jamespage> xnox, which is wierd as that is a RC-> release update only...
[17:03] <jamespage> xnox, I figured I backed out some sort of dependency change for the build
[17:03] <jamespage> but if not then \o/
[17:03] <xnox> jamespage, nah, it was no change rebuild =) so only a pointless changelog entry, from a build that fails to build everywhere, and never migrated ;-)
[17:03] <xnox> jamespage, so just ignore it.
[17:04] <xnox> jamespage, well FTBFS bug-fixes are kosher
[17:04] <xnox> and it had impact too..... e.g. classes were not unwound fully and things were not called at cleanup.
[17:04] <xnox> or some such
[17:04] <xnox> c++ is foreign to me
[17:05] <xnox> i mean i am patching a template over here, for a template not to explode over there, when used in this special way in a random package....
=== ochosi_ is now known as ochosi
=== unixpro1970 is now known as _unixpro1970
=== alvesadrian is now known as Guest76052
=== Guest76052 is now known as adrian-
=== salem_ is now known as _salem
[21:43] <lamont> bdmurray: I just have to say "oops" on that bind9 bug
[21:44] <lamont> bdmurray: I should have -9 uploaded tonight, which fixes it by removing the bad piece of a patch from when I quilted it all.
[21:48] <bdmurray> lamont: okay, great
[21:49] <lamont> fwiw, the assertion failure is named catching a memory leak at shutdown.  Said leak would be bcause of the bad patch which deleted a dst_lib_destroy() call from the shutdown path.
[21:50] <lamont> so it literally is non-affecting in operation, other than (1) the stupid error, and (2) potentially masking something that could be an operational error (e.g. memory leak leading to ENOMEM)
[21:51] <lamont> bdmurray: in fact, -9 is uplaoding to debian at this time
[21:58] <c_korn> when a java app crashes with openjdk-9 but runs with openjdk-8. how can I package that app and be sure it is started with openjdk-8 ?
[22:04] <doko> jamespage, hmm, was this more than a no-change upload?
[22:04] <jamespage> doko, it was
[22:04] <jamespage> doko, RC->release of ceph Jewel
[22:04] <jamespage> the diff was not bug...
[22:06] <lamont> bdmurray: http://paste.ubuntu.com/16071629/ to my shame
[22:06] <jamespage> big rather...
[22:07] <lamont> bdmurray: tbf, lines 10 and 17-65 are not properly needed for the xenial fix
[22:18] <infinity> 17:04 < xnox> c++ is foreign to me
[22:18] <infinity> xnox: ^-- That's what I like to hear from the boost maintainer.
[22:19] <sarnold> hehehe
[22:20] <sarnold> in all fairness there's like a dozen people on the planet who could grok c++ well enough to Maintain Boost, and xnox doesn't have anywhere near enough gray hair. yet.
[22:21] <xnox> sarnold, i maintain boost and btrfs, only to tell people "don't use it"
[22:21] <infinity> sarnold: All the bits of boost I understand are the bits that have been replaced by newer versions of the C++ standard but people are too lazy to switch.
[22:21] <infinity> sarnold: All the OTHER bits should be deleted.
[22:21] <sarnold> infinity: hahaha
[22:21] <sarnold> xnox: that's a dangerous road to start down..
[22:23] <infinity> (I admit that there are vendors who *need* to build on ancient/crap platforms, like MySQL, and boost is at least better than what they used to do, which was reinvent C++ in libmysqld...)
[22:23] <infinity> But for most projects, ick.  Rid thyself of boost.  Free your code.
[22:25] <xnox> they still reinvent c++ in libmysqld..... they subclass templates.
[22:26] <xnox> ¯\_(ツ)_/¯
[22:26]  * xnox bets it has a different term, and it's not "subclass"
[22:26] <infinity> xnox: Well, at least it *is* C++.
[22:26] <xnox> yeah, could be worse c preprocessor + assembly =) glibc all the way
[22:27] <infinity> xnox: Zend rewrote templating in C because they didn't like C++ (again, probably because it predates cross-platform standards that didn't suck)
[22:27] <xnox> ouch
[22:28] <infinity> xnox: Also, don't talk smack about glibc or I'll make you use bionic.
[22:29] <infinity> The C library that stubs out functions to return true, because that's totally the best way to spell ENOSUPP.
[22:29] <xnox> infinity, i had to build bionic toolchain with gcc, and emulator...... i hate bionic
[22:36] <mwhudson> how about musl
[22:37] <mwhudson> everyone loves musl
[23:42] <Unit193> barry: BTW, Debian re-introduced bzr-fastimport, so if that gets merged might be handy to get the fixes I compiled in.