[05:20] <arraybolt3> So, I happened to pay attention to the Fedora development mailing lists, and caught wind that QEMU apparently has code changes that automatically assume the machine it is running on supports x86_64-v2. Compiling QEMU for x86_64-v1 may not be possible anymore, and trying to run it on such a system may crash with SIGILL. **I do not know if this is actually a thing or not, I've asked for a link
[05:20] <arraybolt3> to the commit that introduces this change so I can verify it,** but it does raise an interesting question: how should Ubuntu respond if a package (especially a critical one) becomes x86_64-v1-incompatible?
[05:21] <arraybolt3> I don't think we're prepared to handle an extra architecture like that. Theoretically we *could* bump the processor baseline (and make a whole bunch of people very angry in so doing), but that just kicks the can down the road - what happens if we bump to v2 or even v3 and then a package decides it's going v4-only?
[05:21] <arraybolt3> Anyway, something to think about. The time may be upon us to be ready to deal with this, and even if not, we should be ready for this.
[05:22] <luna_> morning
[05:22] <arraybolt3> Anyway here's the thread for those who are curious: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EA6Y5AUE5DQ4WTD225L4UYMVXFTTK5UV/
[05:23] <arraybolt3> luna_: o/
[05:23] <arraybolt3> what do you mean morning, it's half past midnight here :P
[05:23] <luna_> arraybolt3: timezones ;) :p
[05:30] <arraybolt3> Crud, I have verified that the QEMU CPU requirement is indeed real. You can search through the qemu-devel mailing lists for "x86-64-v2" to find it.
[05:30] <arraybolt3> for instance here: https://lists.nongnu.org/archive/html/qemu-devel/2024-06/threads.html Ctrl+F, then "x86-64-v2" and you'll find it.
[05:31] <arraybolt3> though the patch set that did that may have been reverted looking closer
[10:08] <bdrung> vorlon, after your multipath-tools merge: kpartx : Depends: dmsetup (>= 2:1.02.196-1~) but it is not going to be installed. So lvm2 needs to be merged as well.
[13:37] <adrien> fyi, I'm working on the vtk 9.3 transition
[13:51] <nteodosio> How do I find the last archive test rebuild?
[13:52] <seb128> nteodosio, I think it's https://chat.canonical.com/canonical/channels/desktop
[13:52] <seb128> ups sorry
[13:52] <seb128> https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20240502-noble-noble.html
[13:53] <nteodosio> Thanks seb128, in general there is no way to find this without a direct link? E.g. through Launchpad?
[14:06] <seb128> nteodosio, not that I know of but maybe that's a question for the launchpad channel?
[14:06] <nteodosio> I will relay it.
[14:55] <vorlon> bdrung: well I'm not TIL on lvm2 ;)
=== pushkarnk1 is now known as pushkarnk
=== pushkarnk1 is now known as pushkarnk
[18:51] <ahasenack> holmanb: hi, on #2066985, isn't the test you said that is expected to fail exactly the one we want passing?
[18:51] <ahasenack> # tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug is due to https://github.com/canonical/cloud-init/issues/5373
[18:51] -ubottu:#ubuntu-devel- Issue 5373 in canonical/cloud-init "ec2, hotplug: race between udev add event and IMDS data not being available" [Open]
[18:51] <ahasenack> oh, hm, test_hotplug.py::test_multi_nic_hotplug_vpc actually?
[18:51] <ahasenack> _vpc must pass, and the other one is not a regression, and is being tracked in that GH issue?
[18:53] <ahasenack> holmanb: I'm trying to locate the run of "CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc", as per test plan
[20:00] <adrien> can someone sponsor https://code.launchpad.net/~adrien/ubuntu/+source/python-google-api-core/+git/python-google-api-core/+ref/ubuntu ; there's a PPA at https://launchpad.net/~adrien/+archive/ubuntu/oracular-package-python-google-api-core/+packages
[20:02] <adrien> it's a new package and I'm not familiar with some of the consequences it seems: I wasn't able to create a bug in the right project (that will be fixed later on) and I can't do an MR either, and at that point, I'm not looking towards producing all the right artifacts to attach to the bug (but I can do it if wanted, just not tonight)
[20:02] <adrien> thanks :)