| === jgrimm is now known as jgrimm-out | ||
| nacc | rbasak: if you have time, i'd like to pick your brain on a few things tmrw; particularly, it seems like my naive approach doesn't quite work for figuring out what branch should be used for the 'devel' branch for stable releases (possibly even for the ubuntu/devel branch?) e.g. php7.0's latest version is in xenial-security or xenial-updates, but not in xenial-proposed | 01:24 |
|---|---|---|
| pitti | Good morning | 07:30 |
| pitti | slangasek: usually, stop systemd-resolved.service, and run the binary in a terminal with SYSTEMD_LOG_LEVEL=debug, then try to resolve the name | 07:31 |
| pitti | slangasek: or, just temporarily increase the global log level with "systemd-analyze set-log-level debug" and then grab it from journalctl -u systemd-resolved.service | 07:32 |
| Unit193 | infinity: Can't remember what I was going to ask you now, but any chance you'll merge dpkg from Debian for .buildinfo support? | 07:40 |
| pitti | stgraber: could you add zesty to "lxc image list ubuntu:"? I would have thought that even happened automatically (we do import them through simplestreams in scalingstack), but apparently it doesn't? | 07:59 |
| rbasak | pitti: use ubuntu-daily:zesty | 07:59 |
| pitti | stgraber: erk, nevermind -- ubuntu-daily: | 07:59 |
| rbasak | :) | 07:59 |
| pitti | yeah, instance # 2234982 of finding the solution right after you publicly ask | 07:59 |
| pitti | rbasak: .. and good morning to you! | 08:00 |
| rbasak | Good morning! | 08:00 |
| ginggs | hi, src:grunt hasn't sync'd automatically from Debian, should I do it manually? grunt is not in sync-blacklist, but another package with the same name was removed in 2009 | 08:05 |
| rbasak | ginggs: http://people.canonical.com/~ubuntu-archive/auto-sync/current.log suggests it isn't auto-synced because it existed previously in Ubuntu and was deleted manually. So if it now should go in Ubuntu, then I believe it needs a manual sync. | 10:27 |
| rbasak | http://people.canonical.com/~ubuntu-archive/auto-sync/current.log | 10:27 |
| rbasak | 0.5.1 (karmic): Deleted (removed by Steve Langasek: (From Debian) ROM; No upstream release since 2002; UUCP obsolete) | 10:27 |
| ginggs | rbasak: thanks for confirming, sync'd | 10:33 |
| ricotz | doko, barry, hi, it looks like python2.7 in zesty-proposed (2.7.12-7) breaks at least bzr | 11:13 |
| === _salem is now known as salem_ | ||
| Tribaal | Hi all, I *think* I got all I need to ask for sponsorship to push my patch into zesty for https://bugs.launchpad.net/python-jujuclient/+bug/1644153 . Could anybody confirm, maybe? (I attached a debdiff adding a quilt patch to the bug) | 13:02 |
| ubottu | Launchpad bug 1644153 in python-jujuclient (Ubuntu) "SSL handshake fails on xenial" [Undecided,New] | 13:02 |
| caribou | rbasak: arges: Are you taking care of SRU today ? If so, could someone release the Trusty SRU for LP: #1584485 ? | 13:32 |
| ubottu | Launchpad bug 1584485 in samba (Debian) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [Unknown,New] https://launchpad.net/bugs/1584485 | 13:32 |
| caribou | we'll worry about the other releases later | 13:32 |
| === hikiko is now known as hikiko|ln | ||
| rbasak | caribou: yes. I'll take a look. | 13:37 |
| caribou | rbasak: thanks | 13:37 |
| caribou | rbasak: thanks! | 14:06 |
| rbasak | You're welcome! | 14:07 |
| rbasak | juliank: most of your apt SRU bugs seem to be missing SRU information. | 14:08 |
| juliank | rbasak: Yeah, I was asking someone to provide these who actually has these bugs. I just know that they are fixed.... | 14:08 |
| juliank | rbasak: The gdebi one should be easy to rework, the ubiquity one is a bit more complicated, as I'm not sure what exactly the steps are there. | 14:09 |
| rbasak | juliank: if we struggle to find someone impacted, I'm not sure we should be SRUing. | 14:10 |
| juliank | But I know that those are fixed, because the code was generalized. | 14:10 |
| juliank | That is, we abstracted the formatting of the progress logging and made it locale-independent | 14:11 |
| rbasak | zul: your nova-lxd upload in the trusty queue appears to overwrite the previous changelog message. | 14:15 |
| mitya57 | ricotz, doko, barry: FWIW I filed Debian #845335 for bzr breakage | 14:15 |
| ubottu | Debian bug 845335 in bzr "bzr: Broken with python2.7 2.7.12-7" [Grave,Open] http://bugs.debian.org/845335 | 14:15 |
| zul | rbasak: can you reject it please | 14:15 |
| rbasak | zul: are you backporting newer packaging or adding to the existing Xenial packaging? | 14:16 |
| rbasak | Though I suppose if backporting then the changelog should say that. | 14:16 |
| zul | rbasak: backporting newer version of nova-lxd | 14:16 |
| juliank | rbasak: The ubiquity-related one has 422 heat, the other 90. I think people are affected by it. I now added the information based on the initial bug reports, I think that should suffice. And basically all those bugs are fixed by the same commit... | 14:17 |
| rbasak | zul: I think this has come up before, and we concluded that it doesn't matter too much what you base the changelog on. But I think the choices are to base it on what was previously in xenial-updates, or basing it on wherever the backport is coming from please. | 14:19 |
| juliank | bug 1593583 is an odd one: The commit fixing it and the commit causing it are both in the 1.2.16 release. | 14:19 |
| ubottu | bug 1593583 in apt (Ubuntu Yakkety) "Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_yakkety-proposed_InRelease" [Undecided,New] https://launchpad.net/bugs/1593583 | 14:19 |
| juliank | rbasak: Also I should note that 1.2.17 should be hitting the queue in a few hours to fix bug 1642386 | 14:21 |
| zul | rbasak: yeah im going to base the changelog whatever is on xenial-updates, it wasnt in the git tree when i did the upload | 14:21 |
| ubottu | bug 1642386 in apt (Ubuntu Xenial) "At least one invalid signature was encountered." [Undecided,Triaged] https://launchpad.net/bugs/1642386 | 14:21 |
| rbasak | zul: OK, thanks. | 14:22 |
| === hikiko|ln is now known as hikiko | ||
| juliank | I gotta get to work now, though, so I'll be gone for up to 3 hours. | 14:25 |
| rbasak | bdmurray: for bug 1640318, why not use the errno module's symbolic constants rather than hardcoding a number everywhere? Also, that's a whole load of duplication - could that be in a "attempt_print" function or something? | 14:26 |
| ubottu | bug 1640318 in update-notifier (Ubuntu Yakkety) "/usr/lib/update-notifier/package-data-downloader:OSError:process_download_requests:/usr/lib/update-notifier/package-data-downloader@305:process_download_requests:print_exc:print_exception" [High,In progress] https://launchpad.net/bugs/1640318 | 14:26 |
| rbasak | bdmurray: That's more for the development release. I guess it probably doesn't matter too much for an SRU. | 14:26 |
| rbasak | Are errno values the same across all architectures? | 14:29 |
| barry | mitya57: ouch. i'm not sure if i'll get a chance to look at it before usa thanksgiving holiday weekend | 14:35 |
| mitya57 | To me it looked like Bzr doing something crazy (i.e. a bug in Bzr, not in Python) | 14:36 |
| doko | then why file a RC issue for python? | 14:36 |
| mitya57 | I filed it against Bzr | 14:37 |
| mitya57 | Just X-Debbugs-Cced you :) | 14:37 |
| ginggs | so it seems that node-lex-parser needs to be bootstrapped because of a circular dependency with jison | 14:40 |
| doko | ahh | 14:43 |
| === salem_ is now known as _salem | ||
| rbasak | caribou: I'm confused by your makedumpfile upload in the Xenial queue. It seems to be making six changes but you only have one bug? | 14:50 |
| rbasak | caribou: eg. "Support Hyper-V hypervisors" sounds like it should have a bug reference with SRU paperwork. | 14:50 |
| caribou | rbasak: those were Debian bug that got fixed with the Zesty sync | 14:51 |
| caribou | rbasak: i can create new bugs for each one of them if you want | 14:51 |
| caribou | rbasak: so those bugs where never reported as Ubuntu bugs, but rather as Debian bugs | 14:52 |
| rbasak | caribou: we either need one bug per issue being cherry-picked. Or if you want to backport fixes in a new upstream release wholesale, we have a process for that too. | 14:52 |
| rbasak | But as it is now, we'll miss appropriate SRU verification for most of your proposed update. | 14:52 |
| rbasak | caribou: for example, what regressions might "Support Hyper-V hypervisors" accidentally introduce? Right now, that isn't being considered. | 14:53 |
| * juliank basically does apt upstream stable releases, but they only end up in Ubuntu right now which makes SRUs a bit "confusing" :) | 14:54 | |
| caribou | rbasak: then you may want to reject the X & Y SRU; I'll adjust to what can be verified on Ubuntu & respin | 14:54 |
| juliank | doko: Any reason not to upload the fix for bug 1644048 to zesty? I mean, gcc does not detect it there, it only detects the format-security issue in trusty on arm64. | 14:54 |
| ubottu | bug 1644048 in bash (Ubuntu Trusty) "4.3-7ubuntu1.6 FTBFS on arm64 only with format-security error" [Undecided,Confirmed] https://launchpad.net/bugs/1644048 | 14:54 |
| juliank | But the code is the same. | 14:55 |
| rbasak | caribou: OK thanks. | 14:55 |
| juliank | So, I figured, I push the fix to zesty first, and then do the trusty SRU | 14:55 |
| doko | juliank, didn't have time to look at it. but why upload it when it's ok in zesty? | 14:55 |
| === _salem is now known as salem_ | ||
| juliank | doko: Well, it's arguably a gcc bug that it does not detect it there - it's a printf(ngettext(...)) and supposedly bugs have to be fixed in devel first before being SRUed ) | 14:56 |
| doko | well, it is fixed, apparently in gcc-6 | 14:56 |
| juliank | doko: Well, I'd say gcc is broken, and only works correctly for that on trusty arm64. Because printf(ngettext(...)) should really do the format-security warning AFAICT | 14:58 |
| juliank | because ngettext might return stuff with % in it, and passing that as the first argument to printf() is "dangerous" :) | 14:59 |
| juliank | I can only fix that in trusty for now and we can investigate why it does not fail in zesty, as long as rbasak does not come and say: Hey, that bug needs to be fixed in zesty first :D | 15:02 |
| rbasak | If the bug doesn't exist in Zesty, I think that's OK :) | 15:04 |
| juliank | Well, OK, I'll do that after work then together with the apt 1.2.17 SRU | 15:04 |
| rbasak | If it's a latent bug that still exists in Zesty but happens to not trigger right now, then it should probably be fixed in Zesty first though. | 15:04 |
| juliank | rbasak: It's the same line of code, but gcc only fails in trusty on arm64 (and only now, it did not use to with the previous uploads, despite the code being unchanged). So it's like gcc got better at detecting that issue in a trusty SRU but only on arm64, and not in newer releases... | 15:06 |
| juliank | It's rather strange that this happens. | 15:06 |
| juliank | But I don't really care why it happens that way, I just want to get the SRU building everywhere, and already verified a built binary on xenial (on amd64, not on arm64) | 15:09 |
| === JanC_ is now known as JanC | ||
| ginggs | i tried boostrapping node-lex-parser in a PPA, but it fails with npm could not be installed. https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/7156939/+listing-archive-extra any ideas? | 15:18 |
| juliank | rbasak: While you're complaining about SRUs: I don't know how launchpad deals with .changes files, does it make sense to include -v1.2.15 when replacing the 1.2.16 SRU with 1.2.17? | 15:25 |
| rbasak | juliank: I'd say so, because your upload (IIRC) hasn't been published at all yet. Then the changes file will be accurate completely with all relevant bug references. | 15:26 |
| juliank | Alright. | 15:26 |
| juliank | Thanks, I thought that makes sense :) | 15:27 |
| juliank | This week, we'll also see 1.4~beta1 for zesty (bringing about 15% more performance) and In a few weeks we'll have 1.3.2 and 1.2.18 fixing some more issues :) | 15:29 |
| juliank | Anyone here has Description-md5 values containing upper case characters? Dropping support for that gives us another 6% performance increase... | 15:31 |
| juliank | It never worked in cupt, and probably in other tools either | 15:31 |
| rbasak | Laney: your gstreamer-vaapi upload in the Xenial queue makes the version number go backwards wrt. Yakkety. | 15:36 |
| rbasak | Unless I'm missing something? | 15:36 |
| Laney | does it? | 15:36 |
| Laney | It might, I don'ot remember explicitly checking that | 15:36 |
| Laney | DON'OT | 15:36 |
| Laney | rbasak: Correct, I meant to put a ~ there | 15:38 |
| Laney | See the version in -updates | 15:38 |
| rbasak | Did I pass the SRU team newbie test? :-) | 15:39 |
| * rbasak hopes Laney doesn't remember rbasak's screwup with gst-plugins-bad1.0 five minutes ago :-) | 15:40 | |
| Laney | rbasak: What screwup? :P | 15:41 |
| * Laney calls it even | 15:41 | |
| Laney | This gst SRU has come back from the dead lately | 15:41 |
| rbasak | \o/ | 15:41 |
| Laney | I forgot about it, nobody reviewed it and then a security researcher decided to poke gstreamer with a stick | 15:42 |
| Laney | s/reviewed/verified/ | 15:42 |
| rbasak | tjaalton: I'm going to skip reviewing the libdrm SRU since I don't yet know about what you normally do wrt. test plans etc. for HWE, and I expect other SRU team members know more. | 15:43 |
| rbasak | Whatever the plan is should probably be documented somewhere and linked to from the bug though. | 15:44 |
| tjaalton | rbasak: libdrm is always backported as-is | 15:45 |
| tjaalton | it doesn't break, period :) | 15:45 |
| slangasek | pitti: if I run systemd-resolved that way, it spits me a whole lot of output; when I do the lookup that's been failing, it fails (only when systemd-resolved is running) but I see no mention of it in output; if I redirect systemd-resolved output so that I can search it instead of vgrepping the console, I get no output at all... | 15:50 |
| pitti | slangasek: is that on a desktop? i. e. is it actually resolved which does hte lookup, or dnsmasq from NM? | 15:51 |
| slangasek | pitti: aha, finally managed to catch some output in the vgrep | 15:51 |
| slangasek | pitti: it is systemd-resolved; if I take resolve out of nsswitch.conf the bug goes away | 15:51 |
| pitti | ah | 15:51 |
| slangasek | and yes it's on the desktop | 15:51 |
| slangasek | pitti: this appears to be the relevant bits of the log file; systemd-resolved claims a lookup failure, doesn't explain why, everything except systemd-resolved is happy resolving it http://paste.ubuntu.com/23522691/ | 15:58 |
| slangasek | pitti: it's a public hostname if you want to try to reproduce locally | 15:58 |
| pitti | $ systemd-resolve becquer.dodds.net | 15:59 |
| pitti | becquer.dodds.net: 207.224.24.209 | 15:59 |
| pitti | 2001:470:e980::2 | 15:59 |
| pitti | ^ on my bos | 15:59 |
| pitti | box | 15:59 |
| slangasek | pitti: and here, it only returns the IPv4 | 16:00 |
| nacc | rbasak: available for a quick chat today? | 16:04 |
| slangasek | pitti: to be clear, 'dig' against any of the nameservers around me (including against dnsmasq) returns the AAAA record; only resolved for some reason has pruned it. Is there a cache I need to worry about clearing? Is there any verbosity beyond 'debug'? :) | 16:06 |
| shemgp | bzr branch ubuntu:cups cups.dev is not working for me. It says bzr: ERROR: Not a branch: | 16:06 |
| shemgp | I'm trying to follow: http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching | 16:07 |
| nacc | shemgp: udd is deprecated :/ | 16:07 |
| infinity | s/deprecated/dead/ | 16:07 |
| nacc | shemgp: if you need the souce for cups, do `pull-lp-source cups` | 16:07 |
| nacc | infinity: :) | 16:07 |
| pitti | slangasek: it seems you cut out the interesting parts of the lookup from your paste? | 16:07 |
| infinity | nacc: deprecated implies it might still work. :P | 16:08 |
| shemgp | nacc, any pointers to updated docs? | 16:08 |
| infinity | nacc: We stopped imports a long time ago | 16:08 |
| slangasek | pitti: I didn't see anything else in there about it | 16:08 |
| nacc | infinity: yes, good point :) | 16:08 |
| nacc | shemgp: there aren't really any :/ | 16:08 |
| nacc | shemgp: the above will just download the current source package, e.g. | 16:08 |
| slangasek | pitti: which bits are "interesting"? I see a bunch of unrelated messages | 16:09 |
| infinity | shemgp: man pull-lp-source | 16:09 |
| shemgp | so how do I submit a patch? | 16:09 |
| infinity | shemgp: From there, other than the part where it's not a bzr repo, it's pretty much the same. dpkg-buildpackage, etc. | 16:09 |
| slangasek | pitti: in fact, the only messages in between that I cut are other dbus sent/received logs | 16:09 |
| pitti | slangasek: I get this: http://paste.ubuntu.com/23522732/ (on the query above) | 16:09 |
| infinity | shemgp: Make changes, dpkg-buildpackage -S, debdiff old.dsc new.dsc, attach diff to bug. | 16:10 |
| slangasek | pitti: aha - I found it | 16:10 |
| shemgp | Ok. I'll do that. Thanks | 16:10 |
| slangasek | pitti: I had the IPv4 address of that host in my /etc/hosts, for network recovery purposes. The IPv6 was not listed in /etc/hosts. So systemd-resolved didn't bother asking DNS for the IPv6 name | 16:11 |
| slangasek | pitti: that's a systemd-resolved bug, for sure; should I log it? | 16:11 |
| slangasek | or is there already one somewhere? | 16:11 |
| pitti | slangasek: ah, did that actually ask resolved? /etc/hosts is already done by "files" in nsswitch.conf's "hosts:" | 16:12 |
| pitti | slangasek: but yes, if resolved consults /etc/hosts (I wasn't aware of that) and misbehaves there, please file a bug; I'm not aware of an existing one there | 16:12 |
| infinity | pitti: It must have. Note his earlier "if I remove resolve, it works". | 16:12 |
| slangasek | pitti: it did, because 'files' didn't return an ipv6 answer, so it kept looking, so it got to resolved, which asked files, which didn't return an answer ;P | 16:12 |
| pitti | right, sounds plausible | 16:13 |
| pitti | slangasek: confirmed, thus straightforward to reproduce | 16:14 |
| brendand | x | 16:14 |
| * Laney blushes at brendand | 16:15 | |
| brendand | Laney, that was for everyone, because we're all so awesome | 16:16 |
| brendand | Laney, that, or i pressed enter with the wrong window focused. one of the two | 16:16 |
| Laney | I choose to believe it was an outpouring of affection | 16:17 |
| tvoss | rbasak: o/ | 16:28 |
| tvoss | rbasak: thanks for your feedback on https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1640823 | 16:28 |
| ubottu | Launchpad bug 1640823 in util-linux (Ubuntu Trusty) "[trusty] mount -o loop is limited to 8 loop devices" [Undecided,Fix committed] | 16:28 |
| tvoss | rbasak: updated the patch, pitti is handling the upload, diff in my comment | 16:29 |
| tjaalton | hm, noticed that log rotation has been broken for syslog on my laptop since feb 28th 2015.. | 16:40 |
| * pitti fixes a gazillion new "E741 ambiguous variable name 'l'" pycodestyle errors | 16:44 | |
| pitti | barry: ^ that's going to be fun, smells like a bunch of new FTBFS :) | 16:44 |
| pitti | "E987 programmer is too lazy to type for verbatim variable names" | 16:45 |
| pitti | err, "verbose" | 16:45 |
| barry | pitti: i know :( we've been hitting it in several upstreams. we've seen a lot of E301->E306s and probably a bunch more new, split, or renumbered error codes | 16:46 |
| pitti | barry: yeah, the new version now spots "expected 2 blank lines after class or function definition," in places the old one didn't | 16:46 |
| pitti | but that's actually correct | 16:46 |
| barry | yep | 16:47 |
| barry | seen that too ;) | 16:47 |
| pitti | quite an amazing tool :) | 16:47 |
| pitti | (honestly) | 16:47 |
| Laney | Automated testsuites running pep8 make me want to stab | 16:47 |
| rbasak | Is it catch *all* short variable names? | 16:47 |
| pitti | no, I think just 'l' in an expression | 16:48 |
| rbasak | I tend to use them in small scopes or otherwise obvious scenarios. | 16:48 |
| rbasak | Ah, OK. | 16:48 |
| pitti | presumably because it's too similar to '1' | 16:48 |
| pitti | yeah, I use those for two/three line scopes too, like | 16:48 |
| pitti | for l in my_fd: | 16:48 |
| pitti | [.. do something with that line ] | 16:48 |
| rbasak | Right. | 16:48 |
| rbasak | Or def __setattr__(self, k, v) | 16:48 |
| barry | flake8 is better imho, but yeah, it causes pain when they change the error codes | 16:48 |
| rbasak | Or any other k, v pair in a dictionary comprehension, etc. | 16:48 |
| pitti | barry: isn't flake8 just pycodestyle+pyflakes? | 16:49 |
| barry | pitti: yeah, + plugins and better config | 16:49 |
| barry | pitti: https://gitlab.com/warsaw/flufl.testing :) | 16:50 |
| NixkorN | isnt that in poland? | 16:51 |
| barry | among other places :) | 16:51 |
| attente | https://www.irccloud.com/pastebin/Ba3yELUh/ | 17:31 |
| attente | has anyone noticed this problem recently with googletest/google-mock? | 17:31 |
| seb128 | attente, https://launchpad.net/ubuntu/+source/cmake-extras/0.7+17.04.20161123.5-0ubuntu1 ? | 17:37 |
| seb128 | attente, reading the bug seems it needs more work | 17:38 |
| seb128 | mir hits the issue as well | 17:38 |
| attente | seb128: thanks! | 17:38 |
| seb128 | yw | 17:38 |
| attente | yeah... | 17:38 |
| attente | kenvandine: ^ | 17:39 |
| kenvandine | attente, ah | 17:43 |
| slangasek | pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1644330 | 18:36 |
| ubottu | Launchpad bug 1644330 in systemd (Ubuntu) "systemd-resolved assumes that /etc/hosts for one address family means it doesn't ask DNS for another" [Undecided,New] | 18:37 |
| juliank | Uploaded a fixed bash to trusty now to fix the regression-proposed tracked in bug 1644048. It's a simple 6 character fix, changing printf(ngettext(...)) to printf("%s", ngettext()) - I'd really appreciate if someone could take a look at it and accept it to -proposed. | 19:40 |
| ubottu | bug 1644048 in bash (Ubuntu Trusty) "4.3-7ubuntu1.6 FTBFS on arm64 only with format-security error" [Undecided,In progress] https://launchpad.net/bugs/1644048 | 19:40 |
| juliank | And the verification basically consists of checking it builds on arm64, so that's a piece of cake too | 19:42 |
| === salem_ is now known as _salem | ||
| infinity | juliank: The real curiosity there is why only arm64 cared... | 20:51 |
| juliank | infinity: Yep. Probably a compiler bug - That's really deep in doko's area of expertise, though. | 20:52 |
| infinity | juliank: Oh. Perhaps not a compiler bug, but a misfeature, in that maybe arm64 is the only arch without a builtin printf(), thus the only one that throws the error correctly. :P | 20:53 |
| juliank | Well, yeah. | 20:53 |
| infinity | juliank: Though, unless that code is new in the previous SRU, still a mystery. | 20:53 |
| juliank | Right, it's not new. | 20:53 |
| juliank | That really must have regressed in some libc or gcc SRU at some point without someone noticing. | 20:53 |
| infinity | juliank: OOI, is that format bug fixed in X/Y/Z? | 20:53 |
| juliank | It's exactly the same there | 20:54 |
| infinity | https://patchwork.openembedded.org/patch/127967/ | 20:59 |
| infinity | juliank: ^-- Well, you're not alone, at least. :P | 20:59 |
| juliank | Nice | 20:59 |
| infinity | juliank: That being OE may point at it also being ARM-specific. ;) | 21:00 |
| infinity | juliank: Anyhow, in the interest of "bugfixes shouldn't get lost", and "this sure looks like a real bug to me", I'd like to see uploads for at least X and Z. | 21:01 |
| infinity | juliank: And if you're doing those, Y isn't hard. :P | 21:01 |
| infinity | juliank: The gcc behaviour change in trusty is an entirely different bug (and perhaps worth filing for doko), but not relevant to bash itself being obviously buggy. | 21:02 |
| infinity | Hrm. | 21:04 |
| infinity | Or is it? | 21:04 |
| infinity | gettext/ngettext return a string. | 21:05 |
| nacc | mdeslaur: working my way slowly through the imagemagick merge. I am noticing that the debian patches are not all correct. e.g., 0089-Fix-a-buffer-overflow refers to https://github.com/ImageMagick/ImageMagick/commit/78f82d9d1c2944725a279acd573a22168dc6e22a but adds a #define that is not present upstream. And seems unnecessary, as the macro is already called in that file? | 21:06 |
| sarnold | nacc: imagemagick upstream source control is a pile of shit | 21:06 |
| nacc | sarnold: no joke. | 21:07 |
| nacc | sarnold: well, debian's is not much better, tbh :/ | 21:07 |
| sarnold | nacc: they check in unrelated things into checkins, back half of it back out again two commits later, etc. half the checkin comments are "...". At least those aren't misleading. | 21:07 |
| nacc | sarnold: missing parts of backports, i guess it's symptomatic of upstream | 21:07 |
| nacc | sarnold: yeah, i've noticed the '...' | 21:07 |
| sarnold | nacc: yes. upstream's even worse at git than I am. :) | 21:08 |
| sarnold | nacc: I suspect they never once asked "how do I see what I'm about to check in?" | 21:08 |
| nacc | sarnold: yeah :/ | 21:08 |
| infinity | -checking for GNU gettext in libc... yes | 21:09 |
| infinity | +checking for GNU gettext in libc... no | 21:09 |
| infinity | +checking for GNU gettext in libintl... no | 21:09 |
| Unit193 | infinity: I remembered. What's the procedure for something in main to get "auto" updates like firefox, virtualbox, etc? | 21:09 |
| infinity | juliank: That's the real change between the builds. | 21:09 |
| sarnold | infinity: O_o | 21:09 |
| infinity | juliank: It's using a local libintl due to configure failing to find the real one. | 21:09 |
| juliank | infinity: Oh | 21:09 |
| infinity | juliank: And the local libintl probably has a slightly different prototype for ngettext. | 21:09 |
| juliank | weird | 21:09 |
| infinity | So, where the heck did gettext go? :P | 21:10 |
| sarnold | nacc: I'm sorry to say that I don't know what this means for -you- -- just that you ought to be aware that upstream's patches are _terrible_. They include unrelated things and they spread important things across multiple checkins, and the checkin comments are best ignored entirely. | 21:10 |
| infinity | Seems like a glibc SRU almost certainly couldn't have broken this. | 21:10 |
| nacc | sarnold: yeah, i'm not looking at the upstream for that, per se | 21:11 |
| nacc | sarnold: the issue i ran into is that a claimed backport of upstream in a debian srcpkg is adding things | 21:11 |
| infinity | Unit193: An amazingly compelling argument for why that thing should be a unique snowflake. With a 99% chance of you being told no. | 21:11 |
| juliank | sarnold: Oh, I don't know if you noticed it - The apt 1.2.17 upload took one hour longer than the 48 hours max I estimated.... ;) | 21:11 |
| nacc | sarnold: i'm tempted to just fix imagemagick in z-p, but that's just delaying the inevitable pain of this merge | 21:12 |
| sarnold | juliank: ha! I haven't gotten to that yet. nice. :) | 21:12 |
| infinity | Unit193: Firefox has an exception there for all sorts of icky reasons, but it's not an example to be followed. | 21:12 |
| Unit193 | infinity: Figured, thanks. I'll continue with the PPA route. Yeah, know it's not normal at all, thus exceptions, just like tzdata isn't normal (I'm thinking of geoip-database.) | 21:12 |
| juliank | infinity: So, we probably should find out where gettext went on arm64 and really check if that's a bash-only problem. | 21:13 |
| infinity | Unit193: Oh. geoip-database may well qualify for the same sort of exception we use for tzdata. | 21:13 |
| infinity | Unit193: Framing it as "like firefox" is why I responded with "eff off". :P | 21:13 |
| infinity | Unit193: "Like tzdata" is much more compelling argument for "pure data" sorts of packages. | 21:13 |
| Unit193 | Well, "like firefox" does deserve that. :P | 21:13 |
| Unit193 | infinity: And non-static data, at that. | 21:14 |
| infinity | juliank: Indeed. | 21:14 |
| infinity | Unit193: Yep. We've been looking at the same thing for wireless-regdb as well. | 21:14 |
| Unit193 | That's the other one I couldn't think of. | 21:14 |
| infinity | Unit193: And we also do the PCI/USB databases in pciutils/etc occasionally. | 21:15 |
| infinity | juliank: So, I could work around it, perhaps, by copying the SRU to the security PPA and back again. :P | 21:15 |
| infinity | juliank: So it builds without -updates. | 21:15 |
| infinity | *cough* | 21:15 |
| nacc | mdeslaur: so i'm feeling kind of overwhelmed by the merge. I think I have everything but hte upload in z-p merged to the latest Debian. Would you be ok with replaying that on top of a new upload? I can also send you the debdiff from Debian as a base (or point you at the git tree) | 21:16 |
| infinity | juliank: That would unblock 1.6. But the "where the heck did gettext go" thing should still be investigated. | 21:16 |
| juliank | infinity: As long as we get it unblocked, everything is fine with me :) | 21:17 |
| infinity | juliank: Yeah, doing that now. | 21:18 |
| infinity | juliank: And seeing if it helps.. | 21:18 |
| infinity | https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/11247502 | 21:18 |
| * infinity waits with bated breath. | 21:19 | |
| infinity | juliank: So, it's worth noting that your patch is probably still a valid upstream submission. | 21:21 |
| infinity | Since, in the case where the bunldled libintl gets used, then -Wformat-security will indeed explode there. | 21:21 |
| infinity | But in Debian/Ubuntu, the bundled libintl should NEVER be used. | 21:21 |
| infinity | So... | 21:21 |
| infinity | Whee. | 21:21 |
| robert_ancell | slangasek, can you help demote some packages to universe? bug 1643194 | 21:21 |
| ubottu | bug 1643194 in mozc (Ubuntu) "Please demote these binary packages to universe" [Undecided,New] https://launchpad.net/bugs/1643194 | 21:21 |
| robert_ancell | It will unblock a gnome-software update | 21:22 |
| infinity | robert_ancell: Doesn't need a bug (we have reports about it anyway), but fixing. | 21:23 |
| infinity | slangasek: ^-- disregard robert_ancell, I'm fixing it. | 21:23 |
| robert_ancell | infinity, ok, thanks! | 21:23 |
| infinity | robert_ancell: Done. | 21:25 |
| robert_ancell | infinity, ta | 21:25 |
| infinity | checking for GNU gettext in libc... no | 21:26 |
| infinity | #*!*%% | 21:26 |
| infinity | Oh. Because trusty-security has the latest gcc SRU in it, probably. | 21:26 |
| infinity | Grr. | 21:26 |
| infinity | Guess I get to ask a porterbox WTF. | 21:27 |
| robert_ancell | cjwatson, hey I noticed the Launchpad homepage lists the number of Git repos in LP - do we have any data on how fast that is growing? | 21:32 |
| infinity | ARGH. | 21:34 |
| infinity | juliank: Oh wow, the plot thickens. It actually does a configure check *twice* for gettext in libc. The first time passes, the second doesn't. | 21:36 |
| juliank | Wow | 21:36 |
| infinity | I assume the second configure is called in a way that's breaking gcc slightly. :P | 21:37 |
| infinity | But at least I can reproduce in a porter chroot, so should be able to see. | 21:37 |
| infinity | Hah. | 21:42 |
| infinity | It's binutils. | 21:42 |
| cjwatson | robert_ancell: unfortunately not AFAIK | 21:43 |
| robert_ancell | cjwatson, ok, thanks | 21:43 |
| infinity | juliank: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1644363 | 21:45 |
| ubottu | Launchpad bug 1644363 in binutils (Ubuntu) "[trusty/arm64] binutils segfaults on bash gettext configure test" [Undecided,New] | 21:45 |
| juliank | infinity: Aaaaah | 21:45 |
| juliank | :( | 21:46 |
| infinity | juliank: :( indeed. | 21:46 |
| juliank | Bad ld! | 21:46 |
| infinity | Bad bug. :/ | 21:47 |
| infinity | Makes one wonder how many other configure scripts it's silently broken in trusty updates. | 21:47 |
| infinity | This one only breaks due to a mild fluke in bash's being incompatible with its own bundled libintl. | 21:47 |
| cjwatson | robert_ancell: we need to hook some bits of LP up to statsd at some point | 21:48 |
| cjwatson | (we have other graphing infrastructure, but it's pretty awkward to get at) | 21:48 |
| robert_ancell | cjwatson, I was impressed with the number of git repos, it seems like it must be getting good use. | 21:49 |
| infinity | juliank: Though, if it's a bug with -static, I guess that sees such infrequent use that hopefully the issue isn't widespread. | 21:50 |
| infinity | doko: Insight on https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1644363 would be appreciated. | 21:56 |
| ubottu | Launchpad bug 1644363 in binutils (Ubuntu Trusty) "[trusty/arm64] binutils segfaults on bash gettext configure test" [Undecided,Confirmed] | 21:56 |
| infinity | juliank: On the plus side, I'd say this is truly out of your hands now. :P | 21:56 |
| infinity | juliank: Unless you feel like debugging binutils segfaults. | 21:57 |
| * juliank hides | 21:57 | |
| infinity | (Cause isn't that everyone's favourite way to spend an evening?) | 21:57 |
| juliank | I do have arm64 hardware, but I don't have root on it... | 21:57 |
| juliank | (it's my phone) | 21:58 |
| infinity | Heh. | 21:58 |
| infinity | I bootstrapped Ubuntu/armhf on a phone. :P | 21:58 |
| infinity | I wonder if Sledge is aware that the N900 I sold him was node 0 for the armhf port. | 21:58 |
| juliank | pitti: I'm surprised you had to reject the first apt 1.2.17 upload - I'd have suspected it to be incomplete and some queue thing to autoreject it. The second one is exactly the same binaries, I just aborted the first one, but maybe a bit too late. | 23:19 |
| sarnold | juliank: fwiw I can't find any evidence of an apt build anywhere :/ not on the excuses page, not on https://launchpad.net/ubuntu/+source/apt and not on https://launchpad.net/builders/ | 23:23 |
| juliank | sarnold: Sure, it's in the unapproved queue. | 23:23 |
| juliank | sarnold: Not built until someone says: Yes, we can let that go into -proposed.... | 23:24 |
| sarnold | juliank: aha. I'm clearly way undereducated on how The Rest of ubuntu works. :) thanks | 23:24 |
| sarnold | juliank: .travis.yml is using wily? | 23:31 |
| juliank | sarnold: Yep, that's the newest one. shippable.yml also runs the tests on xenial, but only as root right now, not as a normal user. | 23:31 |
| juliank | That is, travis has no newer build environment than wily | 23:32 |
| sarnold | juliank: how very odd. I'd expect them to target ltses before the intermediates.. | 23:32 |
| sarnold | juliank: thanks :) | 23:32 |
| juliank | sarnold: Oh sorry. It's actually running trusty, I'm just pulling some stuff from wily | 23:33 |
| * juliank attributes the slip to it being past midnight now | 23:33 | |
| sarnold | aha | 23:33 |
| nacc | mdeslaur: https://code.launchpad.net/~nacc/ubuntu/+source/imagemagick/+git/imagemagick/+ref/merge | 23:33 |
| juliank | sarnold: On shippable, we build in the standard xenial docker container. | 23:34 |
| nacc | mdeslaur: there are some tags that hopefully help in there, but the tip of that branch is the merged (and successfuly autopkgtest'd) version, excluding the latest security update in z-p | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!