[06:25] <JackFrost> https://github.com/net-ssh/net-ssh/issues/843 sounds like bad news for net-ssh and OpenSSL 3.0. :3
[06:56] <cpaelzer> mwhudson: there is no way to do that yet
[06:57] <cpaelzer> mwhudson: we might add such a feature, but how should it be handled - a list of known special cases maybe
[06:58] <cpaelzer> mwhudson: where is that size a pain, just for the time to clone or for the space on your disk after cloning or are there more problems with that?
[06:59] <cpaelzer> in general - especially given that we close in on EOY - I'd suggest to file a bug here https://bugs.launchpad.net/usd-importer/+bugs to not forget about it
[12:19] <ddstreet> mapreri i approved the u-d-t uploads for h/i
[12:20] <ddstreet> however for debhelper in f (and b), it looks like doko uploaded it to j with a -nc so the .pot file wasn't correctly updated, so the backport has a sizable debdiff (though the backport is *correct* since the debhelper in jammy shouldn't have been uploaded after a -nc source build)
[12:21] <ddstreet> i think doko might be gone for the rest of the year, i don't see him here, so i may just upload a new debhelper to jammy that's correct
[12:24] <ddstreet> techinically i don't think it's really important, so maybe it's something that can just be ignored in the backports
[12:26] <ddstreet> mapreri also, the u-d-t upload in f has the wrong ~bpo suffix, so i rejected that, looks fine otherwise
[13:47] <mapreri> ddstreet: oh, thanks for catching the u-d-t wrong suffix!
[13:47] <mapreri> ddstreet: tbh I didn't notice the .pot not regenerated, I'd probably ignore it tbh
[14:12] <ddstreet> mapreri agreed, the backported one is actually the correct one, so i'll accept that and let foundations fix the one in jammy themselves
[14:13] <mapreri> ddstreet: FYI: my workflow there has been to start from the debian git repo, import the jammy .dsc, --bpo that, build.
[14:19]  * mapreri also finds funny how I can upload debhelper/focal-backports but not debhelper/jammy - luckily this will soon be "fixed" :3
[14:57] <ddstreet> mapreri in the debhelper upload for b, what's the reference "See ##1001403." ?
[15:08] <mapreri_mobile> ddstreet: I guess I copy-pasted an extra #... But regardless, that's a bug number?
[15:08] <mapreri_mobile> (sorry if I'm misunderstanding your question)
[15:08] <ddstreet> mapreri_mobile that was my first assumption, but the bug is from 2012 and doesn't seem related? assuming it's a lp bug...
[15:08] <ddstreet> i didn't think the debian bug numbers were that high yet?
[15:09] <mapreri_mobile> Ah
[15:09] <mapreri_mobile> Yes, it's bugs.d.o
[15:09] <mapreri_mobile> We got to 1M a couple of weeks ago :)
[15:09] <ddstreet> oh wow!
[15:09] <mapreri_mobile> Heh
[15:09] <ddstreet> lol well i see it now, sorry :)
[15:10] <mapreri_mobile> I also didn't see it coming tbh, considering I remember filing bugs on the 7xxk range not so long ago 😵😸
[15:11] <ddstreet> yeah i feel like it jumped very quickly there!
[15:11] <ddstreet> but that's probably just me :)
[15:11] <mapreri_mobile> I blame some pseudo-automated bugs, we didn't have so many bugs few years ago
[15:11] <mapreri_mobile> Go blame autopkgtests, mass rebuilds, etc
[15:12] <mapreri_mobile> Where are the times when we discovered a ftbfs years after it started happening!
[15:36] <ed__> hello, i believe that debian bug #994103 is fixed now. please can someone sync rust-pleaser to confirm?
[16:02] <mapreri> ed__: do you have a lp account I can mark the sync as sponsored for?
[16:02] <mapreri> or i can just do it in my name
[16:15] <ed__> mapreri: yeah, edneville
[16:26] <mapreri> % syncpackage -f -s edneville rust-pleaser
[16:26] <mapreri> Source rust-pleaser -> jammy/Proposed: current version 0.4.1-2ubuntu1, new version 0.5.1-1
[16:26] <mapreri> ed__: .
[16:33] <ed__> thanks mapreri!
[16:38] <mapreri> ed__: btw, you didn't close the debian bug with your upload.  please send the relevant control@ command (or mail -done@, etc)
[17:28] <ed__> mapreri: done, thanks again!
[18:19] <juliank> grub 2.06 has landed in release pocket :party-tux:
[18:19] <juliank> may your system refuse to boot
[19:35] <rbasak> mwhudson, cpaelzer: I'd really prefer not to special case it. If we ship pristine-tar branches in general, I don't want to break that expectation on random packages. That breaks workflows, and part of the point is to unify them from the various different ways Debian maintains VCSs across different packages.
[19:36] <rbasak> If it's not wanted then maybe we could find a way to configure the client to avoid fetching those refs in the cases where you don't want them. Would that work for you?