[01:44] <niedbalski> rbasak: fixed sru templates for lp #1867676 and lp #1867398, if you could please review them again. thank you!
[09:49] <tkamppeter> seb128, My libmtp printer fix made it all the way through to Debian and upstream:
[09:49] <tkamppeter> https://github.com/libmtp/libmtp/issues/24
[09:49] <tkamppeter> https://salsa.debian.org/debian/libmtp/-/commit/01797b1808e5e01115af10d30b557c14d85a8d1b
[10:58] <rbalint> could an archive admin please unblock kodi? LP: #1868499
[11:02] <mantas-baltix> Hi
[11:10] <seb128> rbalint, you have more chance by using ubuntu-archive as an alias on #ubuntu-release, that should highlight the right people. But also it would help if the bug had the anylisis of the rdepends, the list and sign they got checked and they are fine to remove. I would be fine doing removal commands but I don't have the free cycles to do the investigation work atm
[12:38] <ddstreet> it seems like git-remote-bzr has been removed from the archive since eoan, is there some other way to use remote bzr repos locally with git?
[14:01] <rbasak> cpaelzer: uvtool> all sounds good to me. Thanks!
[14:02] <rbasak> I'm also happy to deprecate --host-passthrough
[14:02] <rbasak> With a warning, for eventual removal.
[14:03] <cpaelzer> rbasak: great
[14:05] <cpaelzer> rbasak: we have a bug and I have a card in the roadmpa for next cycle for myself already
[14:05] <cpaelzer> I'll get back to it when it is the right time
[14:05] <rbasak> ack
[14:25] <oSoMoN> how do I suggest/request that a package (jsunit) be added to a package set (mozilla) ?
[15:48] <gQuigs> xnox: are you still running DNSSEC=yes?  would do you expect It to protect you against?  (https://github.com/systemd/systemd/issues/15158)
[15:50] <oSoMoN> sil2100, being on the developer membership board, do you happen to know I can suggest/request that a package (jsunit) be added to a package set (mozilla) ?
[15:50] <oSoMoN> *how
[15:50] <Laney> oSoMoN: email devel-permissions@lists.ubuntu.com with the request
[15:50] <oSoMoN> Laney, thanks!
[15:53] <xnox> gQuigs:  do you have resolved debug log from when the second authenitcated no query happens?
[15:54] <gQuigs> xnox: no, but I could get that trivially.. (I think)
[15:59] <xnox> gQuigs:  please
[15:59] <xnox> gQuigs:  i wonder if badssl.com has like highjacked entries too
[16:04] <gQuigs> xnox: added to GH issue..
[16:07] <gQuigs> xnox: it does the right thing if it partially wrong (aka resolvectl query dnssec.fail
[16:07] <gQuigs> dnssec.fail: resolve call failed: DNSSEC validation failed: no-signature) -   was wondering the same thing if there was a public reproducer for what I did...
[16:34] <niedbalski> rbasak: or sil2100 i've updated again the affected series, description and regression potential sections of LP: #1867676
[16:35] <niedbalski> coreycb: rbasak in my opinion this should be a UCA dependency rather than archive. ^^
[16:37] <sil2100> niedbalski: I guess since rbasak did the review, he's the best one to continue on it
[16:51] <coreycb> niedbalski: anything that lives in uca starts in distro
[17:31] <rbasak> coreycb: IIRC we hit this before. I wish I could remember the package to see what happened then.
[17:32] <rbasak> coreycb: it makes sense in the general case that fixes go into the archive first. But here's a case where a change to a package is required only because of a UCA backport. I think, from the POV of the Ubuntu archive, it's not a bug at all?
[17:36] <rbasak> Ah. Here we are: bug 1829823
[17:37] <rbasak> In that case it was an obviously safe patch to an unused (in the archive) upstart script, so staging it was OK.
[17:37] <rbasak> In this case there's more regression risk I think as it actually changes functionality.
[17:38] <rbasak> So it's the same class of question, but the resolution last time is not necessarily appropriate here.
[17:49] <coreycb> rbasak: niedbalski: ok I just re-read the bug. this releases >= rocky (ie. >= cosmic). we can look at fixing in the cloud archive only for those releases.
[17:49] <coreycb> s/this/this affects/
[17:50] <coreycb> rbasak: niedbalski: this is an odd case where we don't already have barbicanclient in the uca for rocky, stein, and train because the version in bionic satisfied the requirement for those uca's, so it's awkward.
[17:51] <rbasak> I appreciate how it's awkward
[17:52] <rbasak> I think the trade-off is awkwardness for UCA maintenance/tooling vs. an SRU (with its regression risk, etc) that isn't otherwise necessary or wanted for the Ubuntu archive itself
[18:13] <coreycb> niedbalski: are you sure this doesn't affect queens (ie. bionic)? this fix is in the upstream stable/queens branch. the regression potential of backporting barbicanclient to 3 uca releases is much higher than backporting a single patch to the bionic package.
[18:18] <rbasak> coreycb: much higher> how so? Wouldn't users be installing exactly the same patched package whichever way?
[18:18] <rbasak> If you're worried about the binary, you could build the package on the oldest UCA release and copy it forward
[18:19] <coreycb> rbasak: not in this case because we don't have the package in the UCA for rocky, stein, or train. the version in bionic satisfies the min required version for those releases.
[18:20] <rbasak> coreycb: so instead of a bionic SRU you'd add it to rocky, and copy it forward (with binaries) to stein and train. The user experience in terms of which package build is being installed will be identical in all cases.
[18:22]  * rbasak EODs
[19:46] <niedbalski> coreycb: rbasak this is is bionic only; i don'
[19:47] <niedbalski> coreycb: unless you think is worth doing what rbasak just mentioned ^^
[19:50] <coreycb> niedbalski: I was trying to figure out if the bug exists in bionic. do you know if it does?
[19:51] <niedbalski> coreycb: remember this bug triggers only with octavia-api, that's UCA only bionic base + a UCA release
[19:55] <coreycb> niedbalski: maybe, or have we only seen it in that scenario
[19:56] <niedbalski> coreycb: well, yes
[20:11] <coreycb> niedbalski: it does look like the issue exists in bionic. since we can't test it with octavia on bionic we should be able to test it with the steps mentioned at: https://storyboard.openstack.org/#!/story/2003197
[21:44] <arunpyasi> Hi everyone, is it mandatory to debuild -S in order to dput to PPA Launchpad ?
[21:45] <tumbleweed> Launchpad only accepts source uploads, if that's what you're asking
[21:48] <Unit193> arunpyasi: What is it that you don't like about that?
[21:53] <niedbalski> coreycb: the sru is targeting bionic, what do you mean?
[21:59] <coreycb> niedbalski: right but I think we need a case for getting it fixed in bionic
[22:04] <arunpyasi> Unit193, not that I don't like but having an issue. I build packages via sbuild but if I dput it I get the following error :
[22:04] <arunpyasi> https://pastebin.com/iqTJuexA
[22:37] <mwhudson> niedbalski: sorry for not getting to that containerd bug, i'm glad you got it uploaded
[22:37] <mwhudson> niedbalski: this is fixed upstream, right? so if i upload 1.3.4 we won't lose the fix?
[22:38] <mwhudson> niedbalski: (the upstream bug was still open when i last looked)
[22:49] <arunpyasi> Is 'python' package depreciated from the focal repo ?
[22:52] <gQuigs> arunpyasi: short answer, yes it's gone..  if you need python2, install/depend on python2
[22:52] <arunpyasi> gQuigs, oh ok. Thank you very much for quick response.
[22:53] <niedbalski> mwhudson: o/
[22:54] <niedbalski> $ git show --oneline 37b9a34 | head -n1
[22:54] <niedbalski> 37b9a34 Improve host fallback behaviour in docker remote
[22:54] <niedbalski> $ git tag --contains 37b9a34
[22:54] <niedbalski> mwhudson: afak 1.3.4 hasn't been tagged yet, so yes .. that fix is contained in the current 1.3 release branch but not yet tagged afaiu.
[22:54] <mwhudson> niedbalski: ok cool
[22:55] <mwhudson> uh i guess we should fix in focal anyway, release is close
[22:58] <niedbalski> mwhudson: focal and eoan, last time i checked they were on 1.2.X, which doesn't have this particular issue. did you upload 1.3.3 series there recently?, probably uploading 1.3.4 soon-ish would be the way to go.
[22:59] <mwhudson> niedbalski: focal and eoan have 1.3.3
[22:59] <mwhudson> we don't upload newer versions to stable releases than devel usually...
[23:03] <niedbalski> mwhudson: then yes, same patch will have to be promulgated to eoan and focal as well if they have 1.3.3, if you have no other plan (as doing a 1.3.4 upgrade), i can go ahead and propose the backports for both tomorrow morning.
[23:03] <mwhudson> niedbalski: do you happen to know when 1.3.4 will be out?
[23:03] <mwhudson> but yeah, we shold get the patch into f&e, it's my friday but i can upload on monday if not before
[23:05] <niedbalski> mwhudson: amazing, thanks. i'll ping you once the debdiffs are up in the bug report.
[23:05] <niedbalski> mwhudson: asked here for the 1.3.4 release cut dates https://github.com/containerd/containerd/pull/4104#issuecomment-604731418
[23:06] <niedbalski> lets see