=== genii is now known as genii-meeting === genii-meeting is now known as genii-core === mwhudson_ is now known as mwhudson === genii-core is now known as genii === genii is now known as genii-core [09:49] cpaelzer: thanks for the quick rustc MIR review, I wasn't expecting it so soon after assignment! [09:52] schopin: I knew even with some mental "we want this" pushing power there surely will be quite some work [09:53] schopin: so if I deliver later you have even less chance to complete things - and IMHO this is already super-close [09:55] 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] hehe [09:56] paride: FYI openstack/ceph just replied and the ceph related fuse bug is comitted to be part of the next upload [09:56] oh good! [09:57] 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] paride: do you see any blocker that I'm missing - or do you expect that this should be ok [09:58] 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] 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] 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] cpaelzer, I see no blockers. There are some `Suggests: fuse` in main, libfuse3-dev itself does it, and libpam-mount [10:27] it would be nicer to have fuse3 there, but that's it [11:20] 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] schopin: until then (as long as we vendor it all) the lock file will serve as manifest [11:22] 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] schopin: you are right to ask thou - thanks [11:23] do note that neither rustc nor cargo are built using dh-cargo [12:15] 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:15] Launchpad bug 1959892 in ndctl (Ubuntu) "FTBFS i386: missing libiniparser-dev on i386" [Undecided, New] [12:20] is someone working to unblock the ocaml migration? It is blocking ruby-defaults atm [12:21] the only blocker [13:52] schopin: bluca: to make sure you two can work together on tpm2* for bugs 1959414 1959901 1958439 [13:52] Bug 1958439 in tpm2-tools (Ubuntu) "tpm2-tss: builds against OpenSSL 3.0, but fails on execution" [Undecided, New] https://launchpad.net/bugs/1958439 [13:52] Bug 1959901 in Ubuntu "[needs-packaging] tpm2-openssl" [Undecided, New] https://launchpad.net/bugs/1959901 [13:52] Bug 1959414 in tpm2-tss-engine (Ubuntu) "Please remove tpm2-tss-engine from Jammy" [Undecided, New] https://launchpad.net/bugs/1959414 [13:53] that was uploaded to Debian by now, but is in the new queue [13:53] schopin: you might need to sponsor it ahead of Debian-new to make it into jammy [13:53] schopin: but bluca will be available here for coordination [13:54] cpaelzer: yup, I had the package review on my todo. [13:54] that as well, then you are on top [13:54] thanks schopin [14:08] thanks schopin - I also uploaded to a PPA now, linked in the LP bug [14:08] let me know if I can do anything else [14:09] I will, thanks for your work [14:10] Logan_: hi, are you planning on doing a src:audit merge in ubuntu soon? [14:11] you were TIL ;) [14:11] if not, I can do one, it looks simple [14:25] hm, quilt supports -p n (to strip paths), but debian/patches/series does not? [14:25] 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] is there a nice way to fix this without having to change the upstream patch and remove the extra paths? [14:26] I have "import_abc_from_collections_abc.patch -p4" in d/p/series, but that doesn't work apparently [14:41] I've never tried that hard to avoid changing upstream patches before :) [14:42] I just thought there would be support for it, and I was half right, as quilt supports it [14:42] but then again, the other day I discovered that dpkg-source doesn't even need quilt installed to apply the quilt patches [15:06] is mattermost down for everyone? [15:07] jamesh, wfm [15:08] seb128: thanks, I'll keep trying to fix mine [15:10] is there a way to test reverse-depends on a foreign arch? [15:10] test/check [15:10] foreign as in something else than what my system has [15:15] 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] 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] or maybe I should enable the foreign arch.. [15:18] this ^ :) [15:18] guess that'll do [15:18] reverse-depends -a $myarch should work [15:19] oh? [15:20] ha, exactly what I needed [15:20] thanks [15:21] I thought reverse-depends was somehow deprecated, but no [15:38] How often do we auto-sync from Debian? [15:40] jawn-smith: https://people.canonical.com/~ubuntu-archive/auto-sync/2022-02-02/ suggests four times a day [15:44] rbasak: thanks! [15:56] ahasenack: feel free to grab the audit merge. Thanks for checking! [16:11] any known issues with jammy and crypted zfs? my laptop broke after upgrade from impish [16:11] rollback to older snapshot doesn't seem to boot [16:36] tjaalton: which kernel are you on? and do you have libgcc_s.so in the initramfs? [16:36] tjaalton: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594 [16:36] Launchpad bug 1958594 in initramfs-tools (Ubuntu Jammy) "Boot error: libgcc_s.so.1 must be installed for pthread_exit to work" [Critical, Confirmed] [16:41] xnox: -18 seems to be [16:41] 5.15 [16:41] but it fails booting an older kernel, or an older snapshot [16:42] I'll check again tomorrow from a live session what's going on [16:43] also, i'm using native zfs encryption, not luks [17:48] bdmurray: how would I grep all autopkgtest logs? Downloading it all is not feasable, is it? [17:48] ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib/python3.10/collections/__init__.py) [17:49] I would grep for "cannot import name.*collections" [17:49] oh, actually "Importerror: cannot import name.*collections" [18:12] ahasenack: retry-autopkgtest-regressions --blocks python3-defaults --log-regex 'There is no current event loop' [18:13] ok, but a retry won't fix it, I just need the list [18:14] and retry-autopkgtest-regressions is from https://git.launchpad.net/ubuntu-archive-tools/ [18:16] ahasenack: retry-autopkgtest-regressions only outputs the URLs [18:17] you would need to pipe the out to wget to actually trigger retries [18:20] ah, right [18:20] thanks [18:21] your welcome ;-) [18:24] you're* [18:25] doh [18:31] yeah, got a few hits [18:32] retry-autopkgtest-regressions --blocks python3-defaults --log-regex 'ImportError: cannot import name.*collections' [18:32] the fix is basically from collections.abc import [18:32] instead of "from collections import " [18:33] I'm on my 3rd package where upstream has fixed it already, but debian didn't update the version [18:34] https://github.com/gruns/orderedmultidict/commit/154e2c52a0368715c22e856f0c135e9770365d4d fixed in 2019, for example [18:34] Commit 154e2c5 in gruns/orderedmultidict "Merge pull request #20 from brunns/fix-19-collections-import-warning" [18:36] sweet [18:38] I emailed ubuntu-devel, saying which ones I'm working on atm [18:38] and the list of the others [18:41] ahasenack: I believe mapnik is also affected but I haven't dug into it yet [18:41] maybe the regexp needs some finetuning [18:57] * ahasenack waiting to get back the bug number from debian's bts [18:58] doko: testing a fix for guestfs-tools [18:59] should upload soon [19:31] sergiodj, what's the status of llvm-toolchain-{12,9} regarding ocaml transition? are they fixed already? [19:31] kanashiro: not yet, no [19:31] I think those are the only blockers now [19:31] kanashiro: I filed a bug against Debian (because that's an issue there too), but I'm testing a fix locally meanwhile [19:58] huh, looks like pull-lp-source also needs updating wrt collections and py3.10 :) [19:58] File "/usr/lib/python3/dist-packages/ubuntutools/lp/lpapicache.py", line 174, in __new__ [19:58] if isinstance(fetch, collections.Callable): [19:58] AttributeError: module 'collections' has no attribute 'Callable'. Did you mean: '_spph'? [19:59] ahasenack: fix in git https://git.launchpad.net/ubuntu-dev-tools/commit/?id=0dde3262d175b1c6750bc457cb3bc33aa869f969 [19:59] Commit 0dde326 in ubuntu-dev-tools "ubuntutools/lp: Python 3.10 compatibility" [19:59] \o/ [19:59] can you make a new release? [20:01] Oh! Is downloading fixed now?! Sweet. [20:01] I'm using an old python3-ubuntutools with new ubuntu-dev-tools so backportpackage actually works, and can download things. === genii-core is now known as genii