[02:17] <mwhudson> mwhudson@ringil:/opt/opensource/deb/golang-github-prometheus-common-0+git20181119.b36ad28$ openssl x509 -enddate -noout -in ./config/testdata/barney.crt
[02:17] <mwhudson> notAfter=Jul 13 04:02:47 2019 GMT
[02:17] <mwhudson> "lol"
[02:18] <mwhudson> also lol https://github.com/prometheus/common/commit/a82f4c12f983cc2649298185f296632953e50d3e
[03:55] <alkisg> vorlon: thank you, I will send a patch later on today
[04:01] <mwhudson> i think i convinced myself at the time that the chown --reference thing is harmless in this context
[04:02] <alkisg> mwhudson: sure, the chmod --reference produces an annoying message but it doesn't hurt much, but the unquoted values do break dns etc
[04:03] <mwhudson> alkisg: yeah that sucks
[04:04] <mwhudson> i presume ipconfig handles it by ignoring all but the first provided nameserver...
[04:04] <alkisg> It supports up to 2
[04:04] <alkisg> I'll do the same in the patch and discard more than 2
[04:04] <mwhudson> ah i see you're right
[04:07] <alkisg> Is apt source from eoan the correct starting point for a diff? Or is there a launchpad tree that I should clone?
[04:09] <alkisg> https://git.launchpad.net/ubuntu/+source/isc-dhcp => Age: 2019-03-13...
[04:27] <mwhudson> alkisg: seems right
[04:28] <alkisg> mwhudson, vorlon, I'm about to propose this in the bug report, unless you see something you don't like: https://termbin.com/w0lf
[04:28] <alkisg> I removed some "ifs" as ipconfig wrote empty values in these cases, so let's do the same
[04:28] <mwhudson> alkisg: er can you paste a diff instead?
[04:29] <alkisg> All the lines have changed, but sure :D
[04:29] <mwhudson> alkisg: ah haha
[04:29] <alkisg> I removed the constant >>file
[04:29] <alkisg> And merged in into a single one
[04:29] <mwhudson> a git merge proposal in launchpad would be even better
[04:30] <alkisg> mwhudson: could you help me with a link there?
[04:30] <alkisg> I can clone and commit to https://git.launchpad.net/ubuntu/+source/isc-dhcp, but where is the merge filed?
[04:31]  * alkisg reads https://dev.launchpad.net/UsingMergeProposals ...
[04:32] <alkisg> (hope it applies to git too)
[04:36] <mwhudson> alkisg: there is also https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow but i think that's mostly focused on merges rather than general bugfixing
[04:36] <mwhudson> alkisg: a diff is also fine, i can always do the proposal bit :)
[04:36]  * mwhudson has to run now
[04:52]  * alkisg doesn't have snapd, can't use git-ubuntu-clone... oh well sending a diff
[07:28] <oSoMoN> mwhudson, are you around? bug #1841191 is breaking firefox/thunderbird builds on eoan, and it would just be a matter of backporting an upstream commit
[07:31] <cjwatson> vorlon: Hm, odd.
[07:44] <seb128> what keyring is syncpackage using? I'm trying to do a sync that give me a "Signature could not be verified" error
[08:02] <cjwatson> It's buried in python-debian, but I think it's debian-keyring
[08:05] <rbasak> alkisg: you don't need the tool. Just clone the repo from the URL directly
[08:06] <alkisg> rbasak: where would I file the merge request? I wasn't able to find the URL for that, in the few minutes I looked for it...
[08:06] <rbasak> alkisg: https://help.launchpad.net/Code/Git#Repository_URLs
[08:07] <alkisg> rbasak: thank you
[08:07] <rbasak> alkisg: once you've pushed, use https://code.launchpad.net/~ to find your branch and file the MP
[08:07] <LocutusOfBorg> hello vorlon I think a cryptsetup merge might be beneficial for 32bit archs?
[08:07] <rbasak> Actually it might need to be https://code.launchpad.net/~/+git
[08:08]  * alkisg tests...
[08:10] <alkisg> Not sure if I read the docs right, but `git clone https://code.launchpad.net/ubuntu/+source/isc-dhcp` didn't work, so I replaced "code.launchpad..." with "git.launchpad..." there
[08:10] <seb128> cjwatson, thx, I just updated that but it doesn't resolve the error, I guess I'm just oging to sync --no-lp
[08:12] <rbasak> alkisg: right - if you go to https://code.launchpad.net/ubuntu/+source/isc-dhcp in your browser, the clone URL is displayed
[08:14] <alkisg> I'm on 100 mbps optical; but at 22 kbps, this will take hours :D Receiving objects:  77% (9576/12352), 45.47 MiB | 22.00 KiB/s
[08:21] <cjwatson> seb128: Uh, I would have expected GPG verification *only* to happen in the --no-lp case ...
[08:22] <seb128> cjwatson, I'm trying to sync iw and it fails, but maybe a bug in the syncpackage code
[08:23] <cjwatson> seb128: It gets as far as the "Sync this package" prompt for me, at least ...
[08:24] <seb128> hum, weird
[08:24] <mwhudson> oSoMoN: it's just needed on eoan?
[08:25] <seb128> cjwatson, http://paste.debian.net/1097563/ for me on eoan
[08:26] <oSoMoN> mwhudson, likely not, but that's where I initially observed it
[08:26] <mwhudson> oSoMoN: well i guess that's where i'll initially fix it :)
[08:26] <oSoMoN> yeah :)
[08:26] <cjwatson> seb128: What version of ubuntu-dev-tools?
[08:27] <seb128> ii  ubuntu-dev-tools 0.171        all          useful tools for Ubuntu developer
[08:29] <cjwatson> seb128: Hm.  Dunno.  I guess you could hack verify_signature=False into the src_pkg.pull_dsc call at syncpackage:355
[08:30] <alkisg> rbasak: it didn't allow me to push to "lp:~alkisg/isc-dhcp" (no such project), so I pushed to lp:~alkisg/+git/isc-dhcp; then I go to the bug report and click "link related branch", but search fails, and manually typing the branch isn't accepted either...
[08:31] <cjwatson> lp:~alkisg/+git/isc-dhcp is wrong and will not work
[08:31] <cjwatson> You wanted lp:~alkisg/ubuntu/+source/isc-dhcp
[08:31] <alkisg> I additionally pushed to lp:~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp, and this shows up in "other repositories" in https://code.launchpad.net/ubuntu/+source/isc-dhcp, but this isn't accepted either
[08:32] <alkisg> *without +git: git+ssh://alkisg@git.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp
[08:32] <cjwatson> And "link related branch" is not used for git
[08:32] <alkisg> cjwatson: I'm failing to find the "merge proposal" UI
[08:32] <cjwatson> You should put "LP: #nnn" (substituting appropriately) in the commit message instead
[08:32] <alkisg> I did
[08:32] <cjwatson> Right, then it will be automatically linked once an MP is created
[08:33] <alkisg> Thank you :)
[08:33]  * alkisg deletes the wrong +git repository...
[08:34] <cjwatson> my internet connection is being slow, but you should be able to go to https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp, go to the branch you want to propose, select "Propose for merging"
[08:34] <mwhudson> oSoMoN: uploaded
[08:34] <alkisg> cjwatson: aaaah, ok, thanks, I wasn't clicking inside the branch
[08:35] <oSoMoN> mwhudson, excellent, thanks!
[08:35] <alkisg> cjwatson: am I supposed to use another branch name? I just committed over ubuntu/devel...
[08:35] <mwhudson> oSoMoN: i only wanted to stab quilt twice!
[08:35] <cjwatson> That will work but is bad style since it's unclear
[08:35] <alkisg> ty
[08:35] <seb128> cjwatson, thx, that did it, I will poke a bit more at the code later to see if I find the issue
[08:36] <oSoMoN> mwhudson, why is that?
[08:36] <mwhudson> oSoMoN: oh just things like running git reset --hard and then quilt being confused because the .pc directory was still there
[08:37] <oSoMoN> ah, right
[08:41] <alkisg> cjwatson, rbasak, mwhudson, vorlon, thanks, I think I managed to do it as a merge proposal: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965
[08:41] <alkisg> (using branch name lp1840965)
[08:42] <mwhudson> alkisg: thanks, can you "request a review" from mwhudson?
[08:42] <alkisg> will do
[08:42] <mwhudson> to tired to review tonight :)
[08:42] <mwhudson> or spell apparently
[09:39] <cjwatson> vorlon: Ah, I see the problem - initramfs-tools is never installed in buildd chroots, so the conditional deconfiguration of the update-initramfs diversion never happens because update-initramfs.REAL doesn't exist
[09:39] <cjwatson> vorlon: Will fix
[09:39] <cjwatson> (by making the deconfiguration more robust)
[10:00] <rbalint> juliank, things did not fully clear up with bileto, i see unfinished tests in https://bileto.ubuntu.com/excuses/3789/eoan.html but http://autopkgtest.ubuntu.com/running shows empty queues
[10:00] <rbalint> juliank, could you please take a look again?
[10:03] <rbalint> juliank, maybe iptables migrating to release made a difference
[10:06] <juliank> rbalint: Let's take mpd, I see results for amd64 and arm64, but no other archs, and none show up in the page
[10:06] <juliank> Laney: ^ Do you have an idea what is happening w/ bileto and autopkgtest?
[10:07] <juliank> Looking at journalctl ADT_PARAMS="{'ppas': ['ci-train-ppa-service/3789'], 'triggers': ['systemd/243~rc1+really241-7ubuntu1~rbalint2']}" ADT_PACKAGE=mpd
[10:07] <juliank> To see mpd runs triggered for example, I only see the amd64 and arm64 ones
[10:07] <juliank> and they have results, but the bileto excuses are empty
[10:08] <juliank> s/empty/in progress/
[10:09] <juliank> oh I should also look for ADT_PARAMS in the other direction with triggers first
[10:09] <juliank> ugh, unsorted output
[10:10] <juliank> I see mpd on amd64, arm64, s390x, i386, ppc64el
[10:10] <juliank> I think that's all
[10:10] <juliank> but the bileto excuses page only sees ppc64el
[10:12] <juliank> sil2100: maybe you have some more input
[10:12] <juliank> ?
[10:13] <juliank> Results are uploaded into swift, but the bileto excuses page does not show any
[10:13] <juliank> no idea how that gets there
[10:13] <juliank> autopkgtest side looks fine afaict
[11:27] <Laney> juliank: I have zero visibility into bileto
[11:44] <juliank> Laney: Yeah, I thought maybe it was an autopkgtest issue you might have heard about, but after figuring out that my PARAMS query was a bit suboptimal, I realized, that autopkgtest seems fine, and it's bileto
[11:44] <Laney> okey
[11:44] <juliank> Laney: I probably should split ADT_PARAMS journal field into ADT_PPAS and ADT_TRIGGERS or something, or print out the dict ordered somehow...
[11:45] <juliank> because right now you have to query both ADT_PARAMS="{'ppas': ['ci-train-ppa-service/3789'], 'triggers': ['systemd/243~rc1+really241-7ubuntu1~rbalint2']}"
[11:45] <juliank> and ADT_PARAMS="{'triggers': ['systemd/243~rc1+really241-7ubuntu1~rbalint2'], 'ppas': ['ci-train-ppa-service/3789']}"
[11:45] <juliank> and that sucks a bit
[11:47] <Laney> writing out that dict isn't great even if it is sorted
[11:47] <Laney> is there some kind of fancy list support there or is it string equality only?
[11:47] <juliank> I guess strign equality only, but not sure
[11:48] <juliank> Laney: Oh I guess the same field can appear multiple times for one entry
[11:48] <juliank> so you could have ADT_PPA and ADT_TRIGGER fields for each ppa/trigger
[11:49] <Laney> makes sense if that works like you say
[11:49] <juliank> should test
[11:49] <Laney> and not for example the last one winning
[11:49] <juliank> systemd.journal-fields just says "n some cases, fields may appear more
[11:49] <juliank>        than once per entry.
[11:50] <cjwatson> vorlon: Could you review https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/371874 ?
[11:51] <juliank> Laney: Ah, but the python api allows you to only specify each key once
[11:51] <juliank> Unless I use sendv I guess
[11:52] <juliank> so this works journal.sendv("MESSAGE=Hello world", "FIELD=value1", "FIELD=value2")
[11:52] <juliank> and I can query both FIELD=value1 and FIELD=value2
[11:52] <juliank> so yeah, this should work
[11:53] <juliank> send() also just does args = ['MESSAGE=' + MESSAGE]
[11:53] <juliank> so no special encoding or stuff needed
[11:54] <xnox> vorlon:  Unit193: xfce4-sensors-plugin => well, there are no sensors on s390x that are meaningful.... even if one is running desktops on them =)
[11:54] <juliank> So I guess I'll do this
[11:54] <juliank> but it might need some rework, because we store the fields as a dict right now
[11:55] <juliank> gotta use a list of tuples instead
[15:27] <rbalint> juliank, Laney: have you fond something about the bileto issue?
[15:27] <juliank> rbalint: No, it looks ok from our side AFAICT
[15:29] <rbalint> juliank, by our side you mean bileto or bileto+autopkgtest are both fine?
[15:29] <juliank> autopkgtest seems fine
[15:29] <juliank> as mentioned it uploads the tests for all archs correctly to swift
[15:29] <juliank> but the results do not appear on bileto
[15:45] <rbalint> so it is sil2100 who could help?
[15:46] <sil2100> uh oh!
[15:52] <vorlon> juliank, rbalint: were the missing bileto test results not the ones where I mentioned they were killing the test runners?
[15:52] <vorlon> which I flushed from the queue so they would stop eating builders
[15:53] <juliank> vorlon: Um, he just started them today, they ran successfully, stored result in swift
[15:53] <juliank> Well, he started them again today
[15:53] <vorlon> oh ok
[16:14] <rbalint> vorlon, juliank: I actually started them yesterday and they were probably killing the runners because it ran all tests for systemd https://bileto.ubuntu.com/#/ticket/3789#audit_log
[16:16] <rbalint> vorlon, so if you flushed the queues yesterday, then it could be the cause for me not seeing the results
[16:18] <rbalint> vorlon, i'd like to test systemd 241 before landing it in proposed because keeping a failing systemd in proposed affect others
[16:20] <juliank> Results were put into swift, so they really should be tehere
[16:21] <rbalint> juliank, all of them are in swift? like do you see results for yder ?
[16:30] <rbalint> sil2100, juliank, vorlon: i may have hit LP: #160312
[16:31] <rbalint>  #1603120
[16:31] <rbalint> LP: #1603120
[16:44] <sil2100> rbalint: let me look at that, but I thought we ripped out the overlay PPA from bileto - might be some place missing tho
[16:46] <rbalint> i now removed iptables from the ppa, so if the tests are triggered again at least i won't hit this bug
[16:47] <rbalint> sil2100, i set the destination to the archive, not to an overlay ppa if that matters
[16:51] <sil2100> rbalint: ok, I guess the overlay PPA needs some more purging, let me get to that tomorrow
[16:57] <fossfreedom> hi all - anyone familiar with the changes in the gtk 3.34 version of gnome-settings-daemon?  budgie-desktop is crashing because it can't find the Clipboard and Mouse components of GSD.
[17:03] <LocutusOfBorg> foka, you there?
[17:03] <LocutusOfBorg> autopkgtest for golang-github-xtaci-smux/1.3.4+ds-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression ♻ , s390x: Pass
[17:04] <LocutusOfBorg> autopkgtest for golang-github-xtaci-kcp/5.4.4-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Regression ♻
[17:04] <LocutusOfBorg> do you have any idea for ppc64el and s390x regressions of the two above? ^^
[17:04] <LocutusOfBorg> https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#golang-github-google-go-cmp
[17:04] <foka> LocutusOfBorg, Hi!
[17:05] <foka> I am not familiar with golang-github-xtaci-{kcp,smux}, but I can try playing with them on Debian porterbox and see if I could find some clues.  :-)
[17:06] <LocutusOfBorg> that would be awesome!
[17:06] <LocutusOfBorg> it is a regression in new releases
[17:06] <LocutusOfBorg> btw I might have fixed notary so lots of others golang packages might migrate
[17:07] <foka> BTW, thank you so much for getting go-cmp and hugo and friends to migrate!
[17:08] <LocutusOfBorg> :)
[17:08] <LocutusOfBorg> it has been a pleasure!
[17:08] <LocutusOfBorg> thanks for the valuable help
[17:08] <LocutusOfBorg> mwhudson, appreciated it too I guess :) (I syncd your notary upload)
[17:44] <alkisg> vorlon: hi there; I commented on your comments in https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/371861; not sure if email notifications are generated for these...
[17:44] <alkisg> I think our differences originate because  I'm thinking "shell sourceable" and you're thinking "yaml or similar"...
[17:45] <alkisg> E.g. VAR=value1 value2 value3 is completely invalid in shell...
[17:48] <alkisg> Meh I needed to globally save the inline comments; I just did so
[18:21] <foka> LocutusOfBorg: The regression of golang-github-xtaci-smux on ppc64el turns out to be an infrequent random error (i.e. a test that is a little bit flaky), that happens about 1 out of 10 times.  I was also able to trigger the same error on my amd64 laptop, but again, very rarely.
[18:22] <foka> I'm using something like "while go test -vet=off -p 4 github.com/xtaci/smux; do rm -rf ~/.cache/go-build ; done" for testing, i.e. loop till it fails.
[18:25] <foka> Hmm... this time it took a bit longer to trigger it... like 24 times before the test fails again.
[18:27] <juliank> rbalint: I only checked mpd, all of which ran, succeeded, and stored the results into swift
[18:28] <juliank> (and only ppc64el showed up on excuses)
[18:29] <foka> I suggest taking the easy way out, i.e. just trigger a rebuild on autopkgtest on both golang-github-xtaci-smux and golang-github-xtaci-kcp, and I suspect it will pass this time.  Meanwhile, I'll gather more test results and report this issue to @xtaci the upstream author.
[18:36] <vorlon> alkisg: I did get the email, yes.  And I understand the question of shell validity.  My point is that adding quotes when it's invalid for the value to ever contain more than one word is unnecessary, and IMHO is unidiomatic
[18:37] <vorlon> alkisg: if a netmask contains a space, something is buggy elsewhere; quoting it changes how the bug manifests, but I don't think that's valuable in itself
[18:37] <alkisg> vorlon: the old code wrote 3 dns values in a single variable; that resulted in initramfs errors
[18:37] <alkisg> (without spaces)
[18:37] <alkisg> Why would a netmask contain a space?
[18:37] <vorlon> alkisg: for *that one variable*.  I was commenting on the use of quotes on all the other variables
[18:38] <vorlon> alkisg: if it wouldn't contain a space, why put single quotes around the value in your output?
[18:38] <alkisg> That's what ipconfig does
[18:38] <vorlon> ok
[18:38] <alkisg> It's normal policy for shell; to quote strings
[18:38] <alkisg> See the examples in my bug description; I'm trying to replicate the output of ipconfig
[18:39] <vorlon> it's normal policy to quote strings that may contain embedded spaces
[18:39] <vorlon> it's not normal policy to quote bare words :)
[18:39] <alkisg> Debatable, but I was trying to replicate ipconfig,
[18:39] <alkisg> for $new_routers or other values it's a problem though; what do we want in this case?
[18:39] <alkisg> *that may contain multiple values
[18:39] <vorlon> right, in that case I am happy to withdraw my objection to the quoting
[18:40] <vorlon> I still don't like it but it shouldn't block on me
[18:40] <alkisg> Does this sound saner?   echo "IPV4GATEWAY='${new_routers%% *}'"
[18:40] <alkisg> This keeps only the first router, if it's a space separated list
[18:41] <vorlon> yes, that does sound saner to me
[18:42] <alkisg> Are there any other variables there that might have multiple space separated values?
[18:42] <alkisg> new_ip_address => can it ever have 2 addresses? etc
[18:42] <vorlon> bryce: I find myself having to repeatedly retry autopkgtests for symphony in response to various php uploads, to test against the version of symfony in -proposed.  This satisfies the proposed-migration policy, but symfony itself is stuck in -proposed long-term because it has reverse-dependencies that are incompatible with the new version (php-nesbot-carbon and its revdeps).  Is this something you
[18:42] <vorlon> could look into?
[18:43] <vorlon> alkisg: I assume by the name alone that new_ip_address is always a single address :)
[18:43] <alkisg> vorlon: great, and about ipv6dns3?
[18:45] <vorlon> alkisg: dns3?
[18:45] <alkisg> You suggested that 3 dns values would go to 3 variables, but ipconfig only supports 2
[18:46] <vorlon> right, I think that should apply to both ipv4 and ipv6
[18:46] <alkisg> vorlon: but scripts that source net-*.conf don't know about those variables, as ipconfig never generated them
[18:46] <alkisg> Are we "extending" the format or are we trying to imitate ipconfig output at this point?
[18:47] <vorlon> alkisg: I think the responsibility of this script is to preserve the information received from the dhcp server and pass it on to userspace, regardless of whether any of the scripts in userspace which currently consume it are prepared to handle this particular value
[18:48] <vorlon> having extra fields that the scripts ignore should be fine
[18:48] <alkisg> Hopefully they'll ignore unknown variables then
[18:48] <alkisg> Thanks, I'll push a commit with those changes
[18:48] <bryce> vorlon, of course, can you point me at more info on the failure?  I'll try to take a look
[18:49] <vorlon> bryce:  php-nesbot-carbon : Depends: php-symfony-translation (< 4~~) but 4.3.3+dfsg-3ubuntu3 is to be installed
[18:49] <vorlon> bryce: you can see a complete list of packages that would be uninstallable with the new symfony in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt; I know the php-illuminate-* depend on php-nesbot-carbon, and I haven't looked at the other revdeps
[18:50] <vorlon> I was surprised to see no bug filed against php-nesbot-carbon in Debian for the uninstallability - that's probably a good start
[18:52] <alkisg> vorlon: "loop over all dns values" is a bit tricky in shell, it either needs eval or set; hardcoding "up to 4 dns servers" is much more readable; is that ok?
[18:53] <vorlon> alkisg: why is my pseudocode not sufficient?  "for word in $list; do"
[18:54] <alkisg> shellcheck complains for unquoted $list; also globs should be unset; but ok I don't mind having shellcheck warnings if you're ok with that
[18:55] <alkisg> I'll also make sure that IPV4DNS0 and 1 are always in the output, even if empty, like ipconfig does it
[18:56] <bryce> vorlon, ok will take a look after I'm through this batch of php uploads.
[19:03] <kees> stgraber, vorlon: tech board meeting! :)
[19:12] <vorlon> alkisg: I don't know shellcheck or have any reason to trust it over my own understanding of shell syntax :)
[19:13] <alkisg> vorlon: the idea is that `for in $list` can loop over filenames if it contains * etc etc; np, pushing the new commit...
[19:15] <alkisg> vorlon: pushed; I guess launchpad supports squashed merges, right?
[19:15] <vorlon> it doesn't, really
[19:15] <vorlon> it doesn't support server-side merges at all, only client-side merges, for git
[19:16] <alkisg> Should I uncommit the 2 last commits and push them as one?
[19:16] <vorlon> but also, these branches are read-only
[19:16] <vorlon> --> rbasak, cpaelzer :)
[19:42] <bdmurray> cpaelzer: I'm going to add the block-proposed tag to bug 1797926 so it can age a bit, remove it when you think its old enough
[20:14] <cpaelzer> thanks bdmurray, I'll give it an extra week I guess
[20:57] <mwhudson> LocutusOfBorg: yeah, i thing grpc should migrate in next britney run
[20:58] <mwhudson> foka: oh nice that you fixed the prometheus common thing, i was just going to get britney to ignore the results
[20:59] <mwhudson> getting go packages to migrate is such a game of whack a mole
[21:02] <foka> mwhudson: Hoho, I got lucky with golang-github-prometheus-common.  At first I thought it had to do with golang/x/net because that was when the failure began, but at closer look that wasn't it, and I was so lucky to have come across that Pull Request on GitHub.
[21:03] <foka> mwhudson: Thank you so much for getting other go packages to migrate!
[21:03] <mwhudson> foka: we're not done yet :)
[21:04] <mwhudson> hm https://launchpad.net/ubuntu/+source/golang-goprotobuf/1.3.2-2 should migrate with sufficient retrying
[21:04] <mwhudson> not sure what's up with golang-google-api on arm64
[21:05] <mwhudson> i think it's just timing out
[21:06] <foka> LocutusOfBorg: I just tested v1.1.0 (i.e. older version) of golang-github-xtaci-smux and was able to reproduce the same errors on my amd64 laptop.  See https://github.com/xtaci/smux/issues/54 and https://github.com/xtaci/smux/issues/55 for follow up.
[21:07] <foka> LocutusOfBorg: As for golang-github-xtaci-kcp, I was unable to reproduce the error on s390x.  Perhaps re-run the autopkgtest a few more times and it may automagically work?  (Or, like mwhudson says, get britney to ignore the results?  Hoho!)
[21:10] <foka> mwhudson: Oh yeah!  golang-google-api on arm64 is still failing autopkgtest.  That reminds me: I was going to experiment on Debian's arm64 porterbox, which I forgot.  I'll get back to it and see if we're lucky again, hoho!
[21:15] <mwhudson> foka: would be good to hear what you find indeed
[21:15] <mwhudson> i can test it too but not right now
[21:20] <foka> Regarding golang-github-xtaci-kcp on s390x, perhaps matching it with the latest 1:0.0+git20190811.74dc4d7+dfsg-1 would help?
[21:22] <foka> LocutusOfBorg: Regarding golang-github-xtaci-kcp on s390x, perhaps matching it with the latest golang-golang-x-net-dev 1:0.0+git20190811.74dc4d7+dfsg-1 would help?  (sorry for the repetition, the last message was missing the package name)
[21:25]  * mwhudson looks at why golang-golang-x-net-dev is not migrating and grimaces
[21:26] <mwhudson> blah syncthing needs a GOCACHE fix?
[21:29] <mwhudson> oh toddy fixed that 4 minutes ago :)
[21:29] <mwhudson> (in debian)
[21:47] <mwhudson> https://launchpad.net/ubuntu/+source/golang-golang-x-sys/0.0~git20190726.fc99dfb-1/+build/17329615 <- i assume this is just the usual "test fails in chroot" thing
[21:47] <mwhudson> did it build in debian i wonder...
[21:49] <mwhudson> yes
[21:49] <mwhudson> hmmm
[22:00] <mwhudson> Works On My Machine (tm)