| === _salem is now known as salem_ | ||
| 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:14 |
|---|---|---|
| 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:19 |
| 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:21 |
| Bluefoxicy | sarnold: wow, that's bold. We were discussing -fstack-protector-strong largely. | 01:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| Bluefoxicy | -Bdirect never went anywhere; the other three are sane | 01:29 |
| Bluefoxicy | ... hash style defaults to "sysv", linker optimization defaults to -O0 | 01:30 |
| 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:34 |
| 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:35 |
| 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:36 |
| sarnold | I'm more surprised that 25 years ago I still had fun on computers that weren't connected to any other computers :) | 01:37 |
| Bluefoxicy | apt-get install super-methane-brothers ? | 01:38 |
| sarnold | worse, even qbasic gorillas.bas was fun | 01:39 |
| Bluefoxicy | gorillas nothing, what I need is cats | 01:46 |
| * Bluefoxicy grumbles at mouse | 01:47 | |
| === salem_ is now known as _salem | ||
| infinity | nacc: debian/ruby-rmagick/DEBIAN/shlibs won't work because that's for documenting shlibs of libraries that ruby-rmagick ships. | 06:03 |
| 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:05 |
| 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:06 |
| 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! | 06:07 |
| pitti | Good morning | 07:28 |
| 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:51 |
| 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:52 |
| doko | https://bugs.launchpad.net/ubuntu/+source/insighttoolkit4/+bug/1595485 ask for the removal | 10:54 |
| ubottu | Launchpad bug 1595485 in ldc (Ubuntu) "packages to remove from zesty" [Undecided,New] | 10:54 |
| Laney | doko: The latter, see #launchapd-ops | 10:54 |
| 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 :-) | 10:55 |
| doko | debian buildds don't like it either ... even on x86 archs: https://buildd.debian.org/status/package.php?p=insighttoolkit4 | 11:02 |
| 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:03 |
| doko | Laney: I would try with -g -O2 first /using STRIP/APPEND options | 11:04 |
| Laney | doko: Just strip O3 and append O2? | 11:05 |
| Laney | there's already a commented out block for that in rules | 11:05 |
| Laney | from you ;-) | 11:06 |
| Laney | ok, I'll try it | 11:06 |
| Laney | 22 hour build time is not fun | 11:06 |
| 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:10 |
| doko | sure, looks fine | 11:11 |
| Laney | O2 makes smaller binaries? | 11:11 |
| doko | it should with inlining off. | 11:12 |
| Laney | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2253/+build/11289814 | 11:14 |
| jgdx | seb128, hey, how's that unity8 situation? Closer to being resolved? | 11:21 |
| === _salem is now known as salem_ | ||
| Laney | doko: trying a build with -gz -feliminate-dwarf2-dups on ppc64el too | 11:33 |
| Laney | man gcc -> search "compress" | 11:33 |
| Laney | I don't need to set anything in LDFLAGS as well do I? | 11:35 |
| doko | it should, --compress-debug-sections=... | 11:37 |
| Laney | you need both? | 11:38 |
| Laney | I thought -gz would make them compressed in the first place | 11:38 |
| Laney | ah well, let's see | 11:39 |
| Laney | all good fun | 11:39 |
| doko | Laney: -gz needs to be passed to the linker too, the driver translates that to --compress-debug-sections=zlib for ld | 11:40 |
| Laney | ah | 11:41 |
| doko | hmm, I think that needs a test rebuild, and then be turned on when we open z+1 ... | 11:46 |
| 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:28 |
| 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:31 |
| 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:50 |
| Saviq | pitti, ok I see them there, still, resolved doesn't seem to respect them? | 12:51 |
| 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:52 |
| Saviq | pitti, it worked before zesty - after upgrading my setup was a bit wonky (bug #1637700) | 12:53 |
| ubottu | bug 1637700 in network-manager (Ubuntu) "Caching dnsmasq stops resolving after some time" [Undecided,New] https://launchpad.net/bugs/1637700 | 12:53 |
| Saviq | this might've been a IPv6 issue now I think about it (have disabled v6 for now due to other issues) | 12:54 |
| jgdx | seb128, okay, great! thanks | 12:55 |
| 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:56 |
| 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 |
| === hikiko is now known as hikiko|ln | ||
| 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:57 |
| pitti | Saviq: bug 1592721 landed late in yakkety, and IIRC that correlated with several bug reports | 12:58 |
| ubottu | 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 |
| 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:58 |
| Saviq | pitti, bug #1636375 sounds even more related | 12:59 |
| ubottu | 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 | 12:59 |
| Saviq | kinda | 13:00 |
| pitti | Saviq: ah, is it that one? i. e. unqualified names are expanded, but not qualified prefixes? | 13:00 |
| 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:01 |
| 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:02 |
| 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:05 |
| Saviq | I have "bar.name" and "name" as search domains, foo resolves, as does foo.bar.name, but not foo.bar | 13:07 |
| Saviq | pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375/comments/5 - let me know if you need more details please | 13:11 |
| ubottu | 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:11 |
| Saviq | make that https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375/comments/6 | 13:12 |
| ubottu | 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 |
| 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:12 |
| 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 | 13:45 |
| === hikiko|ln is now known as hikiko | ||
| dobey | doko: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646064/comments/1 | 14:28 |
| ubottu | Launchpad bug 1646064 in glibc (Ubuntu) "investigate autopkgtest regressions in 2.24-7ubuntu1" [Undecided,New] | 14:28 |
| Laney | doko: gcc -gz gives an error | 15:11 |
| Laney | -Wl,--something seemed to work | 15:11 |
| LocutusOfBorg | [16:17:26] <LocutusOfBorg> hi, is anybody there console-setup savvy? | 15:24 |
| 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 |
| ubottu | 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 |
| LocutusOfBorg | forwarding from -release ^^ maybe better to talk here | 15:25 |
| doko | Laney: ok, -gz works in gcc-7, will need to find out why not in 6 ... | 15:38 |
| doko | ok, needs a back port | 15:44 |
| Laney | looked like it was something set up at build time | 15:45 |
| doko | found it, both gcc-5 and gcc-6 are missing the backports | 15:48 |
| Laney | hope it still makes a difference with just the linker option | 15:49 |
| doko | sure, it das. checked with the bash binary | 15:50 |
| 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:51 |
| Laney | with -Wl,--compress-debug-section=soemthing? | 15:52 |
| Laney | nod, that's what I tried too (on a hello world), made some difference | 15:53 |
| doko | no, built a binutils defaulting to compressed debug sections | 15:54 |
| Laney | k | 15:55 |
| doko | https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc/+sourcepub/7209526/+listing-archive-extra (still building there) | 15:57 |
| 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:46 |
| infinity | nacc: Well, if you insist on specifying it as shlibs. I'd just inject the dep directly, if I were you. | 16:48 |
| 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:49 |
| 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:50 |
| nacc | infinity: ah that was what I was going to test, great! | 16:51 |
| infinity | nacc: But to answer your question more directly, yes doing what you suggested would be appropriate. :) | 16:52 |
| 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:53 |
| nacc | infinity: agreed! :) | 16:54 |
| 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:55 |
| * 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:56 |
| 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:57 |
| 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:58 |
| nacc | infinity: right, that's what i'm thinking as well -- working on it now | 16:59 |
| === JanC is now known as Guest2425 | ||
| === JanC_ is now known as JanC | ||
| bdmurray | flexiondotorg: What's the status of bug 1623856? | 18:08 |
| ubottu | bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856 | 18:08 |
| nacc | infinity: http://paste.ubuntu.com/23568890/ seems to extract the correct value into the resulting binary package | 18:45 |
| 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:13 |
| 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:14 |
| 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:15 |
| nacc | infinity: with a small comment: http://paste.ubuntu.com/23569056/ | 19:18 |
| infinity | nacc: I'd include a ref to the Debian bug where the imagemagick maintainers told you to piss off. | 19:19 |
| 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:20 |
| nacc | infinity: agreed | 19:21 |
| * doko watches kees rising from the dead ... | 20:03 | |
| kees | ;p | 20:04 |
| kees | gdb haaaaaack | 20:04 |
| doko | kees: please send it upstream | 20:07 |
| kees | doko: yeah, that's my intention. I always get the Changelog formatting wrong, but I'll give it a shot. ;) | 20:08 |
| === ahoneybun_ is now known as ahoneybun | ||
| kees | doko, bdmurray: sent upstream! | 21:46 |
| doko | Laney: -gz now recognized in 6.2.1-5ubuntu2 | 22:41 |
| 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 ;) | 22:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!