[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 ?
[11:27] <ubottu> bug 1841191 in cargo (Ubuntu Disco) ""error: failed to acquire package cache lock" in sbuild" [Undecided,Fix committed] https://launchpad.net/bugs/1841191
=== ricab is now known as ricab|lunch
=== alan_g_ is now known as alan_g
[15:11] <Odd_Bloke> mwhudson: https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1727751
[15:11] <ubottu> Launchpad bug 1727751 in distro-info (Ubuntu) "ubuntu-distro-info shows the current development series as "latest development" and "supported stable version" at the same time" [Undecided,New]
=== ricab|lunch is now known as ricab
[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] <ubottu> Launchpad bug 1839271 in zsys (Ubuntu) "[MIR] zsys" [Undecided,New]
[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:22] <ubottu> Launchpad bug 1850267 in network-manager (Ubuntu Bionic) "autopkgtest 'nm' fails because it can't find dnsmasq" [Low,In progress] https://launchpad.net/bugs/1850267
[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
=== mwhudson_ is now known as mwhudson
=== DrKranz is now known as DktrKranz
=== Spads_ is now known as Spads
=== themill_ is now known as themill
=== thedac_ is now known as thedac
=== joedborg_ is now known as joedborg
=== lfaraone_ is now known as lfaraone
=== Trevinho_ is now known as Trevinho
=== michagogo_ is now known as michagogo
=== StevenK_ is now known as StevenK