[09:49] <schopin> cpaelzer: thanks for the quick rustc MIR review, I wasn't expecting it so soon after assignment!
[09:52] <cpaelzer> schopin: I knew even with some mental "we want this" pushing power there surely will be quite some work
[09:53] <cpaelzer> schopin: so if I deliver later you have even less chance to complete things - and IMHO this is already super-close
[09:55] <schopin> Yup. I was expecting to have this ready for review 2 weeks earlier but disease and unexpected FTBFS happened, I figured the latter was bad form for a MIR -_-'
[09:55] <cpaelzer> hehe
[09:56] <cpaelzer> paride: FYI openstack/ceph just replied and the ceph related fuse bug is comitted to be part of the next upload
[09:56] <paride> oh good!
[09:57] <cpaelzer> paride: if I might ask since you are the one trying to keep track of this with me - I'd next week want to upload the fuse changes for qemu (just the libfuse) and open-vm-tools (fuse itself, which last time caused issues)
[09:57] <cpaelzer> paride: do you see any blocker that I'm missing - or do you expect that this should be ok
[09:58] <paride> cpaelzer, at this point I'd expect it to be OK, but I'll do another check to the reverse-deps of the possibly problematic packages
[09:59] <cpaelzer> thanks, I have done so as well, but want to be a bit more confident - so I appreciate your second pair of eyes
[10:20] <schopin> cpaelzer: regarding the MIR, required TODO #3c, you mention that rustc would need *both* the Cargo.lock and Built-Using. What would be Built-Using used for? All statically-linked deps are vendored in rustc AFAIK
[10:26] <paride> cpaelzer, I see no blockers. There are some `Suggests: fuse` in main, libfuse3-dev itself does it, and libpam-mount
[10:27] <paride> it would be nicer to have fuse3 there, but that's it
[11:20] <cpaelzer> schopin: Built-Using is more to make the toolchain ready that IF non-vndored rust deps are used to have them properly detected and reported
[11:20] <cpaelzer> schopin: until then (as long as we vendor it all) the lock file will serve as manifest
[11:22] <cpaelzer> schopin: initially I'd expect that the .lock file has it all and the Built-Using is empty, but that will still help as a) if something sneaks in the Bult-Using will show us and b) down the road when we switch to a less special mode but then still all old builds have no proper Built-Using that will be a rather messy switch
[11:23] <cpaelzer> schopin: you are right to ask thou - thanks
[11:23] <schopin> do note that neither rustc nor cargo are built using dh-cargo
[12:15] <ahasenack> vorlon: I filed https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1959892 for ndctl ftbfs i386, not sure how to proceed. We either stop building ndctl for i386, or start building iniparser for i386.
[12:20] <kanashiro> is someone working to unblock the ocaml migration? It is blocking ruby-defaults atm
[12:21] <kanashiro> the only blocker
[13:52] <cpaelzer> schopin: bluca: to make sure you two can work together on tpm2* for bugs 1959414 1959901 1958439
[13:53] <cpaelzer> that was uploaded to Debian by now, but is in the new queue
[13:53] <cpaelzer> schopin: you might need to sponsor it ahead of Debian-new to make it into jammy
[13:53] <cpaelzer> schopin: but bluca will be available here for coordination
[13:54] <schopin> cpaelzer: yup, I had the package review on my todo.
[13:54] <cpaelzer> that as well, then you are on top
[13:54] <cpaelzer> thanks schopin
[14:08] <bluca> thanks schopin - I also uploaded to a PPA now, linked in the LP bug
[14:08] <bluca> let me know if I can do anything else
[14:09] <schopin> I will, thanks for your work
[14:10] <ahasenack> Logan_: hi, are you planning on doing a src:audit merge in ubuntu soon?
[14:11] <ahasenack> you were TIL ;)
[14:11] <ahasenack> if not, I can do one, it looks simple
[14:25] <ahasenack> hm, quilt supports -p n (to strip paths), but debian/patches/series does not?
[14:25] <ahasenack> dpkg-source: warning: the series file (python-fysom.orig.HPig4P/debian/patches/series) contains unsupported options ('-p4', line 1); dpkg-source might fail when applying patches
[14:25] <ahasenack> is there a nice way to fix this without having to change the upstream patch and remove the extra paths?
[14:26] <ahasenack> I have "import_abc_from_collections_abc.patch -p4" in d/p/series, but that doesn't work apparently
[14:41] <rbasak> I've never tried that hard to avoid changing upstream patches before :)
[14:42] <ahasenack> I just thought there would be support for it, and I was half right, as quilt supports it
[14:42] <ahasenack> but then again, the other day I discovered that dpkg-source doesn't even need quilt installed to apply the quilt patches
[15:06] <jawn-smith> is mattermost down for everyone?
[15:07] <seb128> jamesh, wfm
[15:08] <jawn-smith> seb128: thanks, I'll keep trying to fix mine
[15:10] <tjaalton> is there a way to test reverse-depends on a foreign arch?
[15:10] <tjaalton> test/check
[15:10] <tjaalton> foreign as in something else than what my system has
[15:15] <schopin> tjaalton: assuming you have the proper upload rights, you can trigger autopkgtests that use a PPA https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA
[15:17] <tjaalton> schopin: maybe I didn't myself clear enough.. I meant something like 'apt-cache rdepends foo' but so that it works for all archs, not just the one I'm running
[15:18] <tjaalton> or maybe I should enable the foreign arch..
[15:18] <schopin> this ^ :)
[15:18] <tjaalton> guess that'll do
[15:18] <schopin> reverse-depends -a $myarch should work
[15:19] <tjaalton> oh?
[15:20] <tjaalton> ha, exactly what I needed
[15:20] <tjaalton> thanks
[15:21] <tjaalton> I thought reverse-depends was somehow deprecated, but no
[15:38] <jawn-smith> How often do we auto-sync from Debian?
[15:40] <rbasak> jawn-smith: https://people.canonical.com/~ubuntu-archive/auto-sync/2022-02-02/ suggests four times a day
[15:44] <jawn-smith> rbasak: thanks!
[15:56] <Logan_> ahasenack: feel free to grab the audit merge. Thanks for checking!
[16:11] <tjaalton> any known issues with jammy and crypted zfs? my laptop broke after upgrade from impish
[16:11] <tjaalton> rollback to older snapshot doesn't seem to boot
[16:36] <xnox> tjaalton:  which kernel are you on? and do you have libgcc_s.so in the initramfs?
[16:36] <xnox> tjaalton:  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594
[16:41] <tjaalton> xnox: -18 seems to be
[16:41] <tjaalton> 5.15
[16:41] <tjaalton> but it fails booting an older kernel, or an older snapshot
[16:42] <tjaalton> I'll check again tomorrow from a live session what's going on
[16:43] <tjaalton> also, i'm using native zfs encryption, not luks
[17:48] <ahasenack> bdmurray: how would I grep all autopkgtest logs? Downloading it all is not feasable, is it?
[17:48] <ahasenack> ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib/python3.10/collections/__init__.py)
[17:49] <ahasenack> I would grep for "cannot import name.*collections"
[17:49] <ahasenack> oh, actually "Importerror: cannot import name.*collections"
[18:12] <ginggs> ahasenack: retry-autopkgtest-regressions --blocks python3-defaults --log-regex 'There is no current event loop'
[18:13] <ahasenack> ok, but a retry won't fix it, I just need the list
[18:14] <ginggs> and retry-autopkgtest-regressions is from https://git.launchpad.net/ubuntu-archive-tools/
[18:16] <ginggs> ahasenack: retry-autopkgtest-regressions only outputs the URLs
[18:17] <ginggs> you would need to pipe the out to wget to actually trigger retries
[18:20] <ahasenack> ah, right
[18:20] <ahasenack> thanks
[18:21] <bdmurray> your welcome ;-)
[18:24] <ginggs> you're*
[18:25] <bdmurray> doh
[18:31] <ahasenack> yeah, got a few hits
[18:32] <ahasenack> retry-autopkgtest-regressions --blocks python3-defaults --log-regex 'ImportError: cannot import name.*collections'
[18:32] <ahasenack> the fix is basically from collections.abc import <thing>
[18:32] <ahasenack> instead of "from collections import <thing>"
[18:33] <ahasenack> I'm on my 3rd package where upstream has fixed it already, but debian didn't update the version
[18:34] <ahasenack> https://github.com/gruns/orderedmultidict/commit/154e2c52a0368715c22e856f0c135e9770365d4d fixed in 2019, for example
[18:36] <bdmurray> sweet
[18:38] <ahasenack> I emailed ubuntu-devel, saying which ones I'm working on atm
[18:38] <ahasenack> and the list of the others
[18:41] <jbicha> ahasenack: I believe mapnik is also affected but I haven't dug into it yet
[18:41] <ahasenack> maybe the regexp needs some finetuning
[18:57]  * ahasenack waiting to get back the bug number from debian's bts
[18:58] <sergiodj> doko: testing a fix for guestfs-tools
[18:59] <sergiodj> should upload soon
[19:31] <kanashiro> sergiodj, what's the status of llvm-toolchain-{12,9} regarding ocaml transition? are they fixed already?
[19:31] <sergiodj> kanashiro: not yet, no
[19:31] <kanashiro> I think those are the only blockers now
[19:31] <sergiodj> kanashiro: I filed a bug against Debian (because that's an issue there too), but I'm testing a fix locally meanwhile
[19:58] <ahasenack> huh, looks like pull-lp-source also needs updating wrt collections and py3.10 :)
[19:58] <ahasenack>   File "/usr/lib/python3/dist-packages/ubuntutools/lp/lpapicache.py", line 174, in __new__
[19:58] <ahasenack>     if isinstance(fetch, collections.Callable):
[19:58] <ahasenack> AttributeError: module 'collections' has no attribute 'Callable'. Did you mean: '_spph'?
[19:59] <ginggs> ahasenack: fix in git https://git.launchpad.net/ubuntu-dev-tools/commit/?id=0dde3262d175b1c6750bc457cb3bc33aa869f969
[19:59] <ahasenack> \o/
[19:59] <ahasenack> can you make a new release?
[20:01] <JackFrost> Oh!  Is downloading fixed now?!  Sweet.
[20:01] <JackFrost> I'm using an old python3-ubuntutools with new ubuntu-dev-tools so backportpackage actually works, and can download things.