[01:14] <nacc> infinity: also, i'm realizing (and it may not really matter, since it's zesty only), but the rebuilt ruby-rmagick migrated through, and won't work. I guess that's what you were asying earlier? I think the above debdiff, corrected a bit more, would hvae held it in -proposed until imagemagick also was able to migrate?
[01:19] <Bluefoxicy> I don't know if Ubuntu maintains the official Ubuntu Docker image, but we're having this spirited discussion on the Debian one:  https://github.com/tianon/docker-brew-debian/issues/56#issuecomment-264342985
[01:21] <tianon> yes, the Ubuntu official Docker image is produced and maintained in collaboration with Canonical ;)
[01:21] <sarnold> Bluefoxicy: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes#GCC
[01:22] <Bluefoxicy> sarnold:  wow, that's bold.  We were discussing -fstack-protector-strong largely.
[01:23] <sarnold> Bluefoxicy: debian did much the same, https://launchpad.net/debian/+source/gcc-6/+changelog see 6.2.0-7
[01:23] <sarnold> Bluefoxicy: oh cool
[01:24] <Bluefoxicy> My observation is mainly that lots of official images (nginx, java, apache, anything based on java e.g. tomcat, php, ...) are based on debian:jessie, and publishes upstream releases by compilation mainly with autoconf.  End result is a lot of off-hand compilation without stack protection.
[01:24] <sarnold> indeed
[01:24] <sarnold> that kind of thing is why we changed our gcc dfeaults rather than just dpkg-builflags mechanisms. so much software build outside of our archive...
[01:24] <Bluefoxicy> so the options are A) tell every single upstream to add CFLAGS= to their downstream Dockerfile; B) add the appropriate flags to the upstream image; or C) modify the compiler.
[01:24] <Bluefoxicy> nod
[01:25] <Bluefoxicy> modifying the compiler environment catches anything with autoconf, but nothing without it
[01:25] <Bluefoxicy> I'm uncomfortable modifying the compiler in drastic ways
[01:25] <Bluefoxicy> although in DEbian/Ubuntu that's no big deal
[01:25] <sarnold> well, it wasn't without detractors :)
[01:26] <Bluefoxicy> in GCC upstream, you get oddness like muslc not providing certain facilities, and then you compile stuff with -D_FORTIFY_SOURCE=2 and things magically break
[01:26] <sarnold> kernel git bisect got more difficult.. sigh.
[01:26] <Bluefoxicy> and then all of alpine-linux developers are pissed
[01:27] <Bluefoxicy> sarnold:  -Wl,-O1 -Wl,--hash-style=both btw ;)
[01:27] <Bluefoxicy> not sure if that's default now?
[01:27] <sarnold> no idea..
[01:27] <Bluefoxicy> https://lwn.net/Articles/192624/
[01:29] <Bluefoxicy> -Bdirect never went anywhere; the other three are sane
[01:30] <Bluefoxicy> ... hash style defaults to "sysv", linker optimization defaults to -O0
[01:34] <sarnold> Bluefoxicy: there's so many interesting things in the world. nice comments ten years ago btw :)
[01:34] <Bluefoxicy> although it looks like at least /bin/ls has dynsym, dynstr, and gnu hash
[01:34] <Bluefoxicy> so obviously the Ubuntu build servers are doing the right thing
[01:34] <Bluefoxicy> sarnold:  I was a bit brighter ten years ago
[01:34] <sarnold> Bluefoxicy: doko takes pride in having the fastest userspace builds around :D
[01:34] <sarnold> Bluefoxicy: hehe
[01:35] <Bluefoxicy> sarnold:  still embarrassed by Firefox taking like 47 seconds to load while Firefox built on anything else took 6 seconds to start back in Warty?
[01:35] <Bluefoxicy> the world's come a long way in ten years
[01:36] <Bluefoxicy> how did we ever get from one distribution loading a Web browser extremely-slowly being front-page news for months to a world where half the Internet is down because Dyn is under attack by twelve-year-olds?
[01:37] <sarnold> I'm more surprised that 25 years ago I still had fun on computers that weren't connected to any other computers :)
[01:38] <Bluefoxicy> apt-get install super-methane-brothers ?
[01:39] <sarnold> worse, even qbasic gorillas.bas  was fun
[01:46] <Bluefoxicy> gorillas nothing, what I need is cats
[01:47]  * Bluefoxicy grumbles at mouse
[06:03] <infinity> nacc: debian/ruby-rmagick/DEBIAN/shlibs won't work because that's for documenting shlibs of libraries that ruby-rmagick ships.
[06:05] <infinity> nacc: I'd probably also strip the "-6.Q16" off the end of your regex to avoid having to fiddle with that too much with every libmagickcore bump.  If you really think ruby-rmagick could end up linked to two different libmagickcore libraries, there are bigger issues afoot.
[06:06] <infinity> nacc: Otherwise, looks reasonable enough to me.  If there's a way to divine "RMagick2.so" from other files in debian/ to avoid specifying it in rules (I dunno, a gross grep of debian/foo.install or something) that might be "nice", but also pretty sure that doesn't change often enough for it to be a big deal.
[06:07] <nacc> infinity: ah! ok, that makes more sense, i must have misunderstood that part of the manpage
[06:07] <nacc> infinity: ack on the regex
[06:07] <nacc> infinity: thanks for taking a look!
[07:28] <pitti> Good morning
[10:51] <Laney> doko: Can you help with insighttoolkit4/ppc64el please? You enabled the build for all arches a while ago, and now it gets ENOSPC on ppc64el
[10:51] <Laney> (the build log on launchpad isn't helpful)
[10:52] <doko> Laney: how should I help? filing a bug against the buildds that they run out of disk space, or massage the build to take less disk space, maybe not building with -g?
[10:54] <doko> https://bugs.launchpad.net/ubuntu/+source/insighttoolkit4/+bug/1595485 ask for the removal
[10:54] <Laney> doko: The latter, see #launchapd-ops
[10:55] <Laney> it failed when installing the package at the end so maybe not that much more is needed
[10:55] <Laney> or if you want to rip it all out, that's fine by me
[10:55] <Laney> there's a lot of rdeps and untangling all of that doesn't seem like much fun :-)
[11:02] <doko> debian buildds don't like it either ... even on x86 archs: https://buildd.debian.org/status/package.php?p=insighttoolkit4
[11:03] <Laney> looks like its in progress?
[11:03] <Laney> probably going to build everywhere else in zesty at least
[11:03] <doko> no, apparently manually uploaded
[11:04] <doko> Laney: I would try with -g -O2 first /using STRIP/APPEND options
[11:05] <Laney> doko: Just strip O3 and append O2?
[11:05] <Laney> there's already a commented out block for that in rules
[11:06] <Laney> from you ;-)
[11:06] <Laney> ok, I'll try it
[11:06] <Laney> 22 hour build time is not fun
[11:10] <Laney> doko: https://paste.ubuntu.com/23567354/ ok?
[11:10] <doko> maybe I should turn on compressed debug info by default ... but I'm not sure what else that would break ...
[11:11] <doko> sure, looks fine
[11:11] <Laney> O2 makes smaller binaries?
[11:12] <doko> it should with inlining off.
[11:14] <Laney> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2253/+build/11289814
[11:21] <jgdx> seb128, hey, how's that unity8 situation? Closer to being resolved?
[11:33] <Laney> doko: trying a build with -gz -feliminate-dwarf2-dups on ppc64el too
[11:33] <Laney> man gcc -> search "compress"
[11:35] <Laney> I don't need to set anything in LDFLAGS as well do I?
[11:37] <doko> it should, --compress-debug-sections=...
[11:38] <Laney> you need both?
[11:38] <Laney> I thought -gz would make them compressed in the first place
[11:39] <Laney> ah well, let's see
[11:39] <Laney> all good fun
[11:40] <doko> Laney: -gz needs to be passed to the linker too, the driver translates that to --compress-debug-sections=zlib for ld
[11:41] <Laney> ah
[11:46] <doko> hmm, I think that needs a test rebuild, and then be turned on when we open z+1 ...
[12:28] <Saviq> pitti, hey, re: resolved, I rely on "additional search domains" at home, my dhcp is sending them and they always ended up in resolvconf; I've had trouble with that since upgrading to zesty, and having installed NM from proposed now it doesn't work still - configuring them in the connection editor doesn't seem to work either, any idea how this should work? should the domains end up in resolv.conf?
[12:31] <Saviq> resolved only responds to FQDN, and that's correct, AFAIK - and `ping foo` works, but `ping bar.baz` (bar.baz.search.domain being the FQDN) does not
[12:50] <pitti> Saviq: no, they can't end up in resolv.conf -- it has a too limited syntax for that
[12:50] <pitti> Saviq: you should see them in "systemd-resolved --status"
[12:50] <pitti> Saviq: /etc/resolve.conf should only have 127.0.0.53, unless you have another resolvconf client installed (like unbound or whatnot)
[12:51] <Saviq> pitti, ok I see them there, still, resolved doesn't seem to respect them?
[12:52] <pitti> Saviq: hm, mind filing a bug
[12:52] <Saviq> pitti, will do
[12:52] <seb128> jgdx, it was resolved yesterday no?
[12:52] <pitti> Saviq: oh, sorry, I misread "additional search domains" as "domain-limited DNS servers" somehow
[12:52] <pitti> Saviq: just curious that this didn't work with NetworkManager/dnsmasq either
[12:53] <Saviq> pitti, it worked before zesty - after upgrading my setup was a bit wonky (bug #1637700)
[12:54] <Saviq> this might've been a IPv6 issue now I think about it (have disabled v6 for now due to other issues)
[12:55] <jgdx> seb128, okay, great! thanks
[12:56] <seb128> jgdx, yw! do you still have issues or did you just ask out of curiosity?
[12:56] <Saviq> jgdx, seb128, we've a problem with oxide now
[12:56] <Saviq> on xenial+overlay
[12:56] <jgdx> seb128, my silo's just not getting published
[12:56] <Saviq> a new oxide was released into xenial-security, newer than the one in overlay
[12:57] <seb128> jgdx, k, I don't know what the specific issue is but unity8 migrated yesterday
[12:57] <Saviq> so qml-module-ubuntu-web is uninstallable
[12:57] <seb128> oh
[12:57] <Saviq> https://bileto.ubuntu.com/#/ticket/2148
[12:57] <seb128> what Saviq said then
[12:57] <Saviq> this fixes it, but will take a day still to land
[12:57] <Saviq> jgdx, which silo, btw?
[12:57] <jgdx> Saviq, this is holding up silo 2194?
[12:57] <jgdx> ^
[12:58] <pitti> Saviq: bug 1592721 landed late in yakkety, and IIRC that correlated with several bug reports
[12:58] <pitti> Saviq: which at least sounds related to your pre-resolved observations
[12:58] <pitti> could still be that it doesn't send these to resolved either
[12:58] <pitti> ah no, you said that you do see them in --status
[12:59] <Saviq> pitti, bug #1636375 sounds even more related
[13:00] <Saviq> kinda
[13:00] <pitti> Saviq: ah, is it that one? i. e. unqualified names are expanded, but not qualified prefixes?
[13:01] <Saviq> pitti, to some extent, yes - but I only have resolved in resolv.conf
[13:01] <pitti> well, that's fine -- and for the most part, /etc/resolv.conf is entirely irrelevant these days
[13:01] <pitti> (except for chromium)
[13:01] <pitti> or if you stop resolved
[13:02] <Saviq> sure, I just mean that stopping resolved won't help here (or will it? /me tries)
[13:02] <pitti> ah no, it won't
[13:05] <Saviq> pitti, yeah, I'd have to add the nameserver and search bits into resolvconf manually, but I suppose the real issue is the same as the bug says
[13:05] <pitti> Saviq: so can you resolve unqualified names with search expansion?
[13:05] <pitti> i. e. "foo",  not "foo.bar"
[13:05] <Saviq> pitti, correct
[13:05] <pitti> and it would try "foo.baz" if you have "search baz"
[13:05] <pitti> Saviq: ah good, then it's that bug too
[13:07] <Saviq> I have "bar.name" and "name" as search domains, foo resolves, as does foo.bar.name, but not foo.bar
[13:11] <Saviq> pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375/comments/5 - let me know if you need more details please
[13:12] <Saviq> make that https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375/comments/6
[13:12] <pitti> Saviq: ack, thanks; a bit confusing to mix sawicz.net and foo.name in that way, but I know what you mean
[13:12] <Saviq> pitti, sorry, fixed the comment now
[13:12] <Saviq> or not
[13:12] <pitti> *nod*
[13:12] <Saviq> one more try
[13:12] <pitti> well, close enough :)
[13:45] <mdeslaur> doko: I'm stealing your nss merge
[13:45] <doko> Laney: did you start that insighttoolkit4 build with -gz in both CXXFLAGS and LDFLAGS?
[13:45] <doko> mdeslaur: it's your's anyway ;p
[14:28] <dobey> doko: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646064/comments/1
[15:11] <Laney> doko: gcc -gz gives an error
[15:11] <Laney> -Wl,--something seemed to work
[15:24] <LocutusOfBorg> [16:17:26] <LocutusOfBorg> hi, is anybody there console-setup savvy?
[15:25] <LocutusOfBorg> [16:17:44] <LocutusOfBorg> wrt launchpad bug lp: #1443853
[15:25] <LocutusOfBorg> [16:17:46] <ubot5> Launchpad bug 1443853 in kbd (Ubuntu) "Ubuntu 14.10 ISO live boot in Oracle VirtualBox ends up with a corrupted display" [Undecided,Confirmed] https://launchpad.net/bugs/1443853
[15:25] <LocutusOfBorg> [16:17:54] <LocutusOfBorg> the fix might be simple
[15:25] <LocutusOfBorg> forwarding from -release ^^ maybe better to talk here
[15:38] <doko> Laney: ok, -gz works in gcc-7, will need to find out why not in 6 ...
[15:44] <doko> ok, needs a back port
[15:45] <Laney> looked like it was something set up at build time
[15:48] <doko> found it, both gcc-5 and gcc-6 are missing the backports
[15:49] <Laney> hope it still makes a difference with just the linker option
[15:50] <doko> sure, it das. checked with the bash binary
[15:51] <Laney> :)
[15:51] <doko> $ ls -l *essed
[15:51] <doko> -rwxrwxr-x 1 doko doko 2464104 Dez  2 16:25 bash-compressed
[15:51] <doko> -rwxrwxr-x 1 doko doko 4691648 Dez  2 15:52 bash-uncompressed
[15:51] <doko> unstripped binaries
[15:52] <Laney> with -Wl,--compress-debug-section=soemthing?
[15:53] <Laney> nod, that's what I tried too (on a hello world), made some difference
[15:54] <doko> no, built a binutils defaulting to compressed debug sections
[15:55] <Laney> k
[15:57] <doko> https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc/+sourcepub/7209526/+listing-archive-extra (still building there)
[16:46] <nacc> infinity: in the shlibs.local file, I have to specify the SOVERSION (aiui) -- is it appropriate for me to just extract that from the library version? Since I am using that specific library to determine which package provides it?
[16:48] <infinity> nacc: Well, if you insist on specifying it as shlibs.  I'd just inject the dep directly, if I were you.
[16:49] <nacc> infinity: ack, that is probably much easier :)
[16:49] <infinity> nacc: So, move that mess from override_dh_shlibdeps to override_dh_gencontrol, and inject the dep there.
[16:50] <nacc> infinity: yep, thanks!
[16:50] <infinity> nacc: dpkg-gencontrol is smart enough to reduce "foo (>= 1.0), foo (>= 2.0)" to just "foo (>= 2.0)", so shlibdeps will give you the "right" one, and you'll inject the new one, and it'll sort it out.
[16:51] <nacc> infinity: ah that was what I was going to test, great!
[16:52] <infinity> nacc: But to answer your question more directly, yes doing what you suggested would be appropriate. :)
[16:53] <infinity> nacc: (Just less code to do it the dep/control way instead of the shlibs way)
[16:53] <infinity> Less code, more readable, and probably more obvious to the next passer-by how it works.
[16:54] <nacc> infinity: agreed! :)
[16:55] <infinity> nacc: So, yeah, you can probably ditch the \n from the dpkg-query return, stuff it in a make var, and feed that variable to dpkg-gencontrol, and Bob's your uncle.
[16:56]  * infinity handwaves over the details, since it's too early to be pastebinning examples.
[16:56] <doko> infinity: do you expect glibc to migrate today, or will it take some more time?
[16:56] <infinity> doko: I expect to be uploading a new one.  Is there some urgency?
[16:56] <doko> ok, then starting the test rebuilds now without it
[16:56] <infinity> (And if there was urgency, is there a reason you didn't ask me to merge it instead of just taking it on yourself to do so?)
[16:56] <doko> well, I did ...
[16:57] <infinity> doko: The only thing I have from you is a request to fix the ppc build failure on the next upload.  There wasn't a time limit attached to it. :P
[16:57] <infinity> Anyhow, redoing the merge, since your merge wasn't actually a complete merge.
[16:57] <infinity> And fixing the other bits that were staged for that upload.
[16:58] <infinity> And still investgating weird regressions.
[16:58] <infinity> But I don't think any of it should be relevant to the test rebuild.
[16:59] <nacc> infinity: right, that's what i'm thinking as well -- working on it now
[18:08] <bdmurray> flexiondotorg: What's the status of bug 1623856?
[18:45] <nacc> infinity: http://paste.ubuntu.com/23568890/ seems to extract the correct value into the resulting binary package
[19:13] <infinity> nacc: Why the eval?
[19:13] <nacc> infinity: I found that without that, the variable wouldn't get defined in the target section
[19:13] <nacc> infinity: as it needs to be resolved at run-time, not parse-time?
[19:13] <infinity> Oh indeed.
[19:14] <nacc> basically, makefile gotcha :)
[19:14] <infinity> nacc: Yeah, not braining well.  Haven't slept much. :P
[19:14] <nacc> infinity: np! i hit my head against it for a while until i bothered googling a bit :)
[19:14] <infinity> nacc: Looks sane enough, and if it tested okay too, yay.
[19:15] <nacc> infinity: yep, i'm sending it to debian for comments
[19:15] <infinity> nacc: Could perhaps use a comment explaining why all that evil exists.
[19:15] <nacc> i've bisected the php-imagick failure too, it's an imagemagick change which maybe broke the testcase's assumption
[19:15] <nacc> infinity: yep, agreed :)
[19:18] <nacc> infinity: with a small comment: http://paste.ubuntu.com/23569056/
[19:19] <infinity> nacc: I'd include a ref to the Debian bug where the imagemagick maintainers told you to piss off.
[19:20] <nacc> infinity: oh good point!
[19:20] <infinity> (Not for political reasons, but just so that future ruby-rmagick and/or imagemagick maintainers can easily find the history of the hack.
[19:20] <infinity> )
[19:21] <nacc> infinity: agreed
[20:03]  * doko watches kees rising from the dead ...
[20:04] <kees> ;p
[20:04] <kees> gdb haaaaaack
[20:07] <doko> kees: please send it upstream
[20:08] <kees> doko: yeah, that's my intention. I always get the Changelog formatting wrong, but I'll give it a shot. ;)
[21:46] <kees> doko, bdmurray: sent upstream!
[22:41] <doko> Laney: -gz now recognized in 6.2.1-5ubuntu2
[22:57] <doko> infinity: I'm (mis)using the https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc PPA for the compressed-debug-info test rebuild. please don't change anything in this ppa for zesty (at least you didn't in the last few years ;)