[03:31] blr, wgrant: woo the (somewhat) despecial casing of launchpad in the go tool just landed [03:37] Yay [03:37] mwhudson: nice, progress of sorts! [03:37] yeah [03:38] the last two days' worth of fun is finding out what breaks in the archive with go 1.5... [03:38] vs what's broken already [03:38] Everything and most things? [03:38] Or, on x86, more than everything. [03:38] s/x86/!x86/ [03:39] heh well, poking as few bears as possible [03:39] so not building 1.5 for arm64 or ppc64le yet [03:39] or using shared libs [03:39] 20 packages have failures, about half of which are not my fault [03:40] (already broken with gccgo in archive, or ftbfs on any arch for some reason) [03:40] Ew [03:40] https://docs.google.com/spreadsheets/d/1hsw1qAy0yLAfqUnZ9fVbXKwe7HxwUzpx5kJ72bF6nUE/edit#gid=0 [03:41] wgrant: btw, chdist is super handy, thanks for reminding me about that [03:43] :) [11:37] cjwatson: Is --check-distribution useful given the --check-archive option? [11:37] eg. ubuntu-archive-tools always infers distribution from archive. [11:38] u-a-t provides distribution options too in case you didn't want to specify an archive ... [11:38] Oh, so it does. [11:38] Though in this case it's --check-distribution=ubuntu in place of --archive=ubuntu, which doesn't seem like much of a win. [11:38] I dunno, I was mostly being regular [11:39] Can remove them if you prefer [11:39] s/them/it/ [11:40] I'm not fussed, but it doesn't seem particularly useful. [11:40] Inferring distribution from archive makes sense at least; I'd forgotten that u-a-t did that. [11:40] The non-archive methods only exist on the API for compatibility reasons and for partner. [11:40] In u-a-t it's probably just compatibility. [11:41] -A ubuntu vs -d ubuntu is hardly an ease of use problem. [11:41] Depends on the tool; in e.g. manage-chroot it makes more sense to talk about the distribution. [11:41] Indeed. [11:42] But it's not operating on an archive at all in that case (potentially a misfeature, as we've run into a few times...) [11:48] wgrant: updated MP, how about now? [11:50] cjwatson: Looks good, thanks. [11:52] wgrant: as for https://code.launchpad.net/~cjwatson/launchpad/db-livefs-build-ordering/+merge/265660, the existing index becomes inoperative anyway once the new code is deployed. Since it's a smallish table I decided not to worry too much [11:52] cjwatson: Ah, fair point. [11:54] cjwatson: My main concern was the long-running transaction thing, anyway. [11:54] Don't want to be stuck for a 12 hour backup. [11:54] Remind me of the backup schedule? [11:55] Maybe we should just FDT it shortly after the code update. [11:55] Nah, live is fine. [11:56] I was planning to request the whole thing once sourcherry gets round to applying this one. [11:56] Did you get a chance to look at any of my snap branch stack? [11:58] Was unwell and off yesterday, and not 100% today, so I've merely pondered them with no obvious objections. [11:58] Ah, sorry to hear that. [11:58] I'm still slightly recovering from camping in a field for three days, but my inbox has more than enough to keep me occupied? [11:58] s/\?/!/ [11:58] Oh dear, a field! [11:58] Distressingly outdoors. [11:59] The weather looked nice, though. [11:59] Uh [11:59] Well, the temperature, at least. [11:59] I didn't check the rest :) [11:59] We got pretty wet on Sunday. Traditional festival weather. [12:00] Good fun though [12:00] Excellent. [14:02] wgrant: Hmm, I wonder what to do about stuff like https://launchpad.net/ubuntu/+source/gem2deb/0.20.1/+build/7722524. It's beginning to look like we might be best off copying the entirety of Dpkg::Deps into our backported sbuild package as Sbuild::Deps [14:03] (an approach previously taken in Debian buildd branches ...) [14:05] cjwatson: Hum, what happened there? It just excluded anything with a profile restriction, even when it was a negative? [14:06] DB<2> x deps_parse("ruby-rspec ", reduce_arch => 1, host_arch => "i386", build_arch => "i386", build_dep => 1, reduce_profiles => 1, build_profiles => []) [14:06] 0 Dpkg::Deps::AND=HASH(0x9286abc) [14:06] 'list' => ARRAY(0x90fb1e4) [14:06] empty array [14:06] ^- that happened [14:06] I guess that's a long way of saying "yes" [14:06] Quite. [14:07] How unfortunate. [14:07] I don't know why there were no warnings or anything [14:07] Dpkg::Deps is probably fairly self-contained on top of an otherwise modernish libdpkg-perl. [14:08] I think it just needs Dpkg::BuildProfiles (possibly only on precise). [14:09] In fact on both precise and trusty, since trusty's doesn't have parse_build_profiles or evaluate_restriction_formula. [14:11] Needs Dpkg::BuildEnv on precise, but I think that's the lot. [17:06] wgrant: Proposed sbuild patches: http://paste.ubuntu.com/11954598/ (precise) http://paste.ubuntu.com/11954600/ (trusty) [20:35] cjwatson, o/ how are you? :-) === blr_ is now known as blr [23:19] wgrant: hmm, https://launchpad.net/ubuntu/+archive/test-rebuild-20150722/+build/7682014 looks weird - it's not a non-UTF-8 issue, because the byte reported is the first byte of ö in UTF-8 [23:20] but it seems astonishing that we would still have bugs with UTF-8 .changes [23:20] cjwatson: Oh, interesting. [23:20] cjwatson: I saw a couple of instances of that in the OOPS reports a week or so ago. [23:20] But it wasn't widespread, so I assumed it was legitimate badness. [23:21] It's presumably the maintainer email fixing changes failing to decode it somewhere. [23:22] Regression from r17611, perhaps [23:22] Yeah, must be. [23:22] I'll try to repro. [23:22] Thanks [23:24] I remember there being functions in there that had decoding as kind of a side-effect, and thought I'd managed to disentangle all of that but maybe not totally correctly. [23:25] Ah, it wasn't in OOPS reports, it was in process-upload.py cronspam. [23:25] https://pastebin.canonical.com/136298/ [23:29] Right, reproducible easily. [23:29] Will fix. [23:29] Yay SQLObject compat layer. [23:29] Well [23:30] It's not really sqlobject's fault [23:30] (test suite would have caught this if it were native Storm) [23:30] Ah, OK [23:30] Because Storm whines if you try to put a str in a unicode column. [23:30] It's much more Python 3 about things. [23:30] That value would previously have been ascii_smashed, so still a str but without any non-ASCII [23:30] (And a lot less useful) [23:30] Very annoying for whipping up code quickly, very handy for not writing dodgy code. [23:31] I made it be str for compatibility, but maybe it would have been better to fix all the callers to accept unicode [23:31] ALEFLAMMEIFORGETTHEREST [23:31] Exactly [23:31] Semantics of that value are "the RFC822-encoded version of this field", so you can probably make a case for either octet-stream or text [23:32] Oh in fact it's just the name isn't it [23:32] name = force_to_utf8(name) [23:33] So I guess just .decode [23:33] really? [23:33] All very silly code. [23:33] what on earth [23:33] have you *read* force_to_utf8? [23:34] I have. [23:34] That is certainly the stupidest thing I've seen today. [23:34] It probably sort of made sense with the prevailing common case of pre-UTF-8 control files. [23:34] Kind of. [23:34] No [23:34] Read it [23:34] Oh [23:35] I misread. [23:35] Yes, I know :) [23:35] Oops [23:35] ISO-8859-1 was probably the most common non-UTF-8 encoding for those though [23:35] I misread it as doing something with the decoded UTF-8 value [23:35] So it returned a unicode in one case and not the other. [23:35] Yeah [23:35] Hmmm [23:36] It should arguably be turned into force_to_unicode [23:37] If that doesn't make all the twisty callers explode too badly, and we already know our test coverage is poor ... [23:37] Anyway, I must to bed [23:37] Night.