[11:27] <oSoMoN> sil2100, hey, thunderbird 60.9.1 is FTBFS in {xenial,disco}-proposed because of a cargo bug (bug #1841191), I'm wondering if there's a way to do an express SRU for cargo with https://github.com/ehuss/cargo/commit/e46e185e4d007daa1a73f3e99e051d9ad039f5a6 ?
[15:11] <Odd_Bloke> mwhudson: https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1727751
[16:54] <kanashiro> hi didrocks, I've been working on runc MIR and I'd like to do a similar thing you did in zsys MIR to identify a small set of deps embedded in the generated binary: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/comments/11
[16:54] <kanashiro> however, I am not able to reproduce what you did with zsys, to run 'go version -m zsysd' and get that output do I need to build it differently? or just use the binary shipped inside the .deb package should work?
[16:55] <kanashiro> I am using golang from focal-proposed (1.13)
[16:55] <didrocks> kanashiro: I didn't look yet with the package produced binary, but yeah, I know that the module versions are stripped out (probably some linker's flag). The result I'm showing is just running "go build" to build the binary directly
[17:02] <sil2100> oSoMoN: so, those thunderbird uploads - those are to go to -security as the others?
[17:08] <kanashiro> didrocks, sorry for the lack of golang knowledge but what is the exact command you use to build it? just "go build" from the root of the project directory is not generating the binary for me here
[17:09] <ahasenack> rbasak: haproxy is a sync, and we don't want to go beyond the 2.0.x line we are in now, as that is upstream's LTS line
[17:09] <ahasenack> rbasak: do you know how to put a block in place, if that's possible?
[17:11] <didrocks> kanashiro: go build in the binary directory you want to build should be enough. You can try to build all binaries in your project by go build ./... (if ofc, the project can be built directly, without a makefile doing magic)
[17:15] <kanashiro> didrocks, thanks, after entering the zsysd directory worked now :)
[17:15] <kanashiro> I got the same output you reported
[17:18] <didrocks> ;)
[17:22] <ddstreet> connor_k yep i opened lp #1850267 for that
[17:24] <oSoMoN> sil2100, no, those are normal SRUs, there's nothing qualifying them as a security update
[17:26] <connor_k> ddstreet, thank you!
[17:32] <ddstreet> connor_k do you have a n-m upload in progess you can attach the nm test fix to?  if not i can upload just the fix and add the 'block-proposed-bionic' tag to the bug
[17:33] <connor_k> ddstreet, no, I'm just interested in tracking that fix in particular for kernel autopkgtests since we try running n-m
[17:33] <ddstreet> ack, i'll go ahead and put it in the bionic upload queue then, thnx
[17:33] <infinity> oSoMoN, sil2100: Seems like a bit of a moot point when they don't build anyway?
[17:50] <rbasak> ahasenack: you mean in case Debian upload 2.1 to unstable?
[17:50] <rbasak> I'm not sure of a good mechanism :-/
[17:51] <ahasenack> rbasak: exactly
[17:51] <ahasenack> rbasak: because 2.1 is "stable" upstream, but is not an lts stable
[17:51] <rbasak> There is an autosync blacklist
[17:51] <rbasak> Or you could use "ubuntu" in the version number of an upload that is a fakesync
[17:51] <rbasak> Maybe fakesync is the wrong term
[17:52] <rbasak> I mean an upload that is identical to Debian but with an ubuntu1 changelog entry. That would stop an autosync and would have it appear in our merge report etc.
[17:52] <ahasenack> is that the usual? And who would know about the autosync blacklist mechanism?
[17:52] <ahasenack> the usual suspects? :)
[17:53] <rbasak> https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt is the sync blacklist
[17:53] <rbasak> I'm not sure there is a "usual"
[17:53] <rbasak> It's a reasonable enough thing to want though
[17:53] <rbasak> (freezing a specific package in advance of DebianImportFreeze)
[17:54] <rbasak> Given that we already do a merge report with analysis, maybe the sync blacklist is appropriate. We can always manually sync, and we won't miss new versions since our report will tell us.
[17:57] <ahasenack> I would want a new update of the 2.0.x series if it comes from debian, though
[17:58] <ahasenack> let me email ubuntu-devel
[17:59] <rbasak> We'd stop that in the merge report and manually sync it
[17:59] <rbasak> spot
[17:59] <sil2100> oSoMoN: I would say it should be possible to do that, i.e. the cargo SRU, but only of that small change and it would have to be linked in  the bug - and possibly with a separate cargo test-case if possible
[18:44] <oSoMoN> sil2100, that sounds good, I'll prepare the cargo SRUs first thing tomorrow morning then
[18:54] <sil2100> oSoMoN: thanks! Give me a ping once those are uploaded, I might find the cycles to get them in