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