=== _salem is now known as salem_ [01:14] 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] 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] yes, the Ubuntu official Docker image is produced and maintained in collaboration with Canonical ;) [01:21] Bluefoxicy: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes#GCC [01:22] sarnold: wow, that's bold. We were discussing -fstack-protector-strong largely. [01:23] Bluefoxicy: debian did much the same, https://launchpad.net/debian/+source/gcc-6/+changelog see 6.2.0-7 [01:23] Bluefoxicy: oh cool [01:24] 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] indeed [01:24] 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] 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] nod [01:25] modifying the compiler environment catches anything with autoconf, but nothing without it [01:25] I'm uncomfortable modifying the compiler in drastic ways [01:25] although in DEbian/Ubuntu that's no big deal [01:25] well, it wasn't without detractors :) [01:26] 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] kernel git bisect got more difficult.. sigh. [01:26] and then all of alpine-linux developers are pissed [01:27] sarnold: -Wl,-O1 -Wl,--hash-style=both btw ;) [01:27] not sure if that's default now? [01:27] no idea.. [01:27] https://lwn.net/Articles/192624/ [01:29] -Bdirect never went anywhere; the other three are sane [01:30] ... hash style defaults to "sysv", linker optimization defaults to -O0 [01:34] Bluefoxicy: there's so many interesting things in the world. nice comments ten years ago btw :) [01:34] although it looks like at least /bin/ls has dynsym, dynstr, and gnu hash [01:34] so obviously the Ubuntu build servers are doing the right thing [01:34] sarnold: I was a bit brighter ten years ago [01:34] Bluefoxicy: doko takes pride in having the fastest userspace builds around :D [01:34] Bluefoxicy: hehe [01:35] 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] the world's come a long way in ten years [01:36] 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] I'm more surprised that 25 years ago I still had fun on computers that weren't connected to any other computers :) [01:38] apt-get install super-methane-brothers ? [01:39] worse, even qbasic gorillas.bas was fun [01:46] gorillas nothing, what I need is cats [01:47] * Bluefoxicy grumbles at mouse === salem_ is now known as _salem [06:03] nacc: debian/ruby-rmagick/DEBIAN/shlibs won't work because that's for documenting shlibs of libraries that ruby-rmagick ships. [06:05] 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] 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] infinity: ah! ok, that makes more sense, i must have misunderstood that part of the manpage [06:07] infinity: ack on the regex [06:07] infinity: thanks for taking a look! [07:28] Good morning [10:51] 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] (the build log on launchpad isn't helpful) [10:52] 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] https://bugs.launchpad.net/ubuntu/+source/insighttoolkit4/+bug/1595485 ask for the removal [10:54] Launchpad bug 1595485 in ldc (Ubuntu) "packages to remove from zesty" [Undecided,New] [10:54] doko: The latter, see #launchapd-ops [10:55] it failed when installing the package at the end so maybe not that much more is needed [10:55] or if you want to rip it all out, that's fine by me [10:55] there's a lot of rdeps and untangling all of that doesn't seem like much fun :-) [11:02] debian buildds don't like it either ... even on x86 archs: https://buildd.debian.org/status/package.php?p=insighttoolkit4 [11:03] looks like its in progress? [11:03] probably going to build everywhere else in zesty at least [11:03] no, apparently manually uploaded [11:04] Laney: I would try with -g -O2 first /using STRIP/APPEND options [11:05] doko: Just strip O3 and append O2? [11:05] there's already a commented out block for that in rules [11:06] from you ;-) [11:06] ok, I'll try it [11:06] 22 hour build time is not fun [11:10] doko: https://paste.ubuntu.com/23567354/ ok? [11:10] maybe I should turn on compressed debug info by default ... but I'm not sure what else that would break ... [11:11] sure, looks fine [11:11] O2 makes smaller binaries? [11:12] it should with inlining off. [11:14] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2253/+build/11289814 [11:21] seb128, hey, how's that unity8 situation? Closer to being resolved? === _salem is now known as salem_ [11:33] doko: trying a build with -gz -feliminate-dwarf2-dups on ppc64el too [11:33] man gcc -> search "compress" [11:35] I don't need to set anything in LDFLAGS as well do I? [11:37] it should, --compress-debug-sections=... [11:38] you need both? [11:38] I thought -gz would make them compressed in the first place [11:39] ah well, let's see [11:39] all good fun [11:40] Laney: -gz needs to be passed to the linker too, the driver translates that to --compress-debug-sections=zlib for ld [11:41] ah [11:46] hmm, I think that needs a test rebuild, and then be turned on when we open z+1 ... [12:28] 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] 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] Saviq: no, they can't end up in resolv.conf -- it has a too limited syntax for that [12:50] Saviq: you should see them in "systemd-resolved --status" [12:50] Saviq: /etc/resolve.conf should only have 127.0.0.53, unless you have another resolvconf client installed (like unbound or whatnot) [12:51] pitti, ok I see them there, still, resolved doesn't seem to respect them? [12:52] Saviq: hm, mind filing a bug [12:52] pitti, will do [12:52] jgdx, it was resolved yesterday no? [12:52] Saviq: oh, sorry, I misread "additional search domains" as "domain-limited DNS servers" somehow [12:52] Saviq: just curious that this didn't work with NetworkManager/dnsmasq either [12:53] pitti, it worked before zesty - after upgrading my setup was a bit wonky (bug #1637700) [12:53] bug 1637700 in network-manager (Ubuntu) "Caching dnsmasq stops resolving after some time" [Undecided,New] https://launchpad.net/bugs/1637700 [12:54] this might've been a IPv6 issue now I think about it (have disabled v6 for now due to other issues) [12:55] seb128, okay, great! thanks [12:56] jgdx, yw! do you still have issues or did you just ask out of curiosity? [12:56] jgdx, seb128, we've a problem with oxide now [12:56] on xenial+overlay [12:56] seb128, my silo's just not getting published [12:56] a new oxide was released into xenial-security, newer than the one in overlay [12:57] jgdx, k, I don't know what the specific issue is but unity8 migrated yesterday [12:57] so qml-module-ubuntu-web is uninstallable [12:57] oh [12:57] https://bileto.ubuntu.com/#/ticket/2148 [12:57] what Saviq said then === hikiko is now known as hikiko|ln [12:57] this fixes it, but will take a day still to land [12:57] jgdx, which silo, btw? [12:57] Saviq, this is holding up silo 2194? [12:57] ^ [12:58] Saviq: bug 1592721 landed late in yakkety, and IIRC that correlated with several bug reports [12:58] bug 1592721 in network-manager (Ubuntu Xenial) "Don't write search domains to resolv.conf in the case of split DNS" [Medium,Fix released] https://launchpad.net/bugs/1592721 [12:58] Saviq: which at least sounds related to your pre-resolved observations [12:58] could still be that it doesn't send these to resolved either [12:58] ah no, you said that you do see them in --status [12:59] pitti, bug #1636375 sounds even more related [12:59] bug 1636375 in systemd (Ubuntu) "systemd-resolved does not allow you to connect using subdomains using search domains which are in /etc/resolv.conf" [Undecided,Confirmed] https://launchpad.net/bugs/1636375 [13:00] kinda [13:00] Saviq: ah, is it that one? i. e. unqualified names are expanded, but not qualified prefixes? [13:01] pitti, to some extent, yes - but I only have resolved in resolv.conf [13:01] well, that's fine -- and for the most part, /etc/resolv.conf is entirely irrelevant these days [13:01] (except for chromium) [13:01] or if you stop resolved [13:02] sure, I just mean that stopping resolved won't help here (or will it? /me tries) [13:02] ah no, it won't [13:05] 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] Saviq: so can you resolve unqualified names with search expansion? [13:05] i. e. "foo", not "foo.bar" [13:05] pitti, correct [13:05] and it would try "foo.baz" if you have "search baz" [13:05] Saviq: ah good, then it's that bug too [13:07] I have "bar.name" and "name" as search domains, foo resolves, as does foo.bar.name, but not foo.bar [13:11] pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375/comments/5 - let me know if you need more details please [13:11] Launchpad bug 1636375 in systemd (Ubuntu) "systemd-resolved does not allow you to connect using subdomains using search domains which are in /etc/resolv.conf" [Undecided,Confirmed] [13:12] make that https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375/comments/6 [13:12] Launchpad bug 1636375 in systemd (Ubuntu) "systemd-resolved does not allow you to connect using subdomains using search domains which are in /etc/resolv.conf" [Undecided,Confirmed] [13:12] Saviq: ack, thanks; a bit confusing to mix sawicz.net and foo.name in that way, but I know what you mean [13:12] pitti, sorry, fixed the comment now [13:12] or not [13:12] *nod* [13:12] one more try [13:12] well, close enough :) [13:45] doko: I'm stealing your nss merge [13:45] Laney: did you start that insighttoolkit4 build with -gz in both CXXFLAGS and LDFLAGS? [13:45] mdeslaur: it's your's anyway ;p === hikiko|ln is now known as hikiko [14:28] doko: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646064/comments/1 [14:28] Launchpad bug 1646064 in glibc (Ubuntu) "investigate autopkgtest regressions in 2.24-7ubuntu1" [Undecided,New] [15:11] doko: gcc -gz gives an error [15:11] -Wl,--something seemed to work [15:24] [16:17:26] hi, is anybody there console-setup savvy? [15:25] [16:17:44] wrt launchpad bug lp: #1443853 [15:25] [16:17:46] 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] [16:17:54] the fix might be simple [15:25] Launchpad bug 1443853 in console-setup (Ubuntu) "Ubuntu 14.10 ISO live boot in Oracle VirtualBox ends up with a corrupted display" [Critical,Confirmed] https://launchpad.net/bugs/1443853 [15:25] forwarding from -release ^^ maybe better to talk here [15:38] Laney: ok, -gz works in gcc-7, will need to find out why not in 6 ... [15:44] ok, needs a back port [15:45] looked like it was something set up at build time [15:48] found it, both gcc-5 and gcc-6 are missing the backports [15:49] hope it still makes a difference with just the linker option [15:50] sure, it das. checked with the bash binary [15:51] :) [15:51] $ ls -l *essed [15:51] -rwxrwxr-x 1 doko doko 2464104 Dez 2 16:25 bash-compressed [15:51] -rwxrwxr-x 1 doko doko 4691648 Dez 2 15:52 bash-uncompressed [15:51] unstripped binaries [15:52] with -Wl,--compress-debug-section=soemthing? [15:53] nod, that's what I tried too (on a hello world), made some difference [15:54] no, built a binutils defaulting to compressed debug sections [15:55] k [15:57] https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc/+sourcepub/7209526/+listing-archive-extra (still building there) [16:46] 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] nacc: Well, if you insist on specifying it as shlibs. I'd just inject the dep directly, if I were you. [16:49] infinity: ack, that is probably much easier :) [16:49] nacc: So, move that mess from override_dh_shlibdeps to override_dh_gencontrol, and inject the dep there. [16:50] infinity: yep, thanks! [16:50] 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] infinity: ah that was what I was going to test, great! [16:52] nacc: But to answer your question more directly, yes doing what you suggested would be appropriate. :) [16:53] nacc: (Just less code to do it the dep/control way instead of the shlibs way) [16:53] Less code, more readable, and probably more obvious to the next passer-by how it works. [16:54] infinity: agreed! :) [16:55] 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] infinity: do you expect glibc to migrate today, or will it take some more time? [16:56] doko: I expect to be uploading a new one. Is there some urgency? [16:56] ok, then starting the test rebuilds now without it [16:56] (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] well, I did ... [16:57] 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] Anyhow, redoing the merge, since your merge wasn't actually a complete merge. [16:57] And fixing the other bits that were staged for that upload. [16:58] And still investgating weird regressions. [16:58] But I don't think any of it should be relevant to the test rebuild. [16:59] infinity: right, that's what i'm thinking as well -- working on it now === JanC is now known as Guest2425 === JanC_ is now known as JanC [18:08] flexiondotorg: What's the status of bug 1623856? [18:08] bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856 [18:45] infinity: http://paste.ubuntu.com/23568890/ seems to extract the correct value into the resulting binary package [19:13] nacc: Why the eval? [19:13] infinity: I found that without that, the variable wouldn't get defined in the target section [19:13] infinity: as it needs to be resolved at run-time, not parse-time? [19:13] Oh indeed. [19:14] basically, makefile gotcha :) [19:14] nacc: Yeah, not braining well. Haven't slept much. :P [19:14] infinity: np! i hit my head against it for a while until i bothered googling a bit :) [19:14] nacc: Looks sane enough, and if it tested okay too, yay. [19:15] infinity: yep, i'm sending it to debian for comments [19:15] nacc: Could perhaps use a comment explaining why all that evil exists. [19:15] i've bisected the php-imagick failure too, it's an imagemagick change which maybe broke the testcase's assumption [19:15] infinity: yep, agreed :) [19:18] infinity: with a small comment: http://paste.ubuntu.com/23569056/ [19:19] nacc: I'd include a ref to the Debian bug where the imagemagick maintainers told you to piss off. [19:20] infinity: oh good point! [19:20] (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] ) [19:21] infinity: agreed [20:03] * doko watches kees rising from the dead ... [20:04] ;p [20:04] gdb haaaaaack [20:07] kees: please send it upstream [20:08] doko: yeah, that's my intention. I always get the Changelog formatting wrong, but I'll give it a shot. ;) === ahoneybun_ is now known as ahoneybun [21:46] doko, bdmurray: sent upstream! [22:41] Laney: -gz now recognized in 6.2.1-5ubuntu2 [22:57] 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 ;)