[10:03] cpaelzer: \o/ thanks for merging https://gitlab.com/libvirt/libvirt/-/merge_requests/140 [10:03] Merge 140 in libvirt/libvirt "apparmor: Fix QEMU access for UEFI variable files" [Closed] [10:03] cpaelzer: I'll backport the fix and send it to Debian; I can upload it to jammy as well if you want me [10:13] pitti, hey! how are you? :-) [10:13] bonjour seb128 ! je vais très bien, merci ! trying to fix some AppArmor issue in Debian/Ubuntu 😀 [10:14] pitti, I think I saw you on screen monday :) [10:14] et toi ! comment est la terre de desktop ? [10:15] pitti, ça va bien merci! we had our first engineering sprint in 2 years, was nice to see people in real again! [10:21] seb128: right, I saw that on twitter or telegram or so 🍻 nice! [10:21] :) [10:22] pitti, small world, I didn't know you had a team member in Delft! [10:22] seb128: yes, Jelle, since last August [10:22] seb128: ah, that's what you meant with "screen"! [10:22] pitti, he started coming to the coworking I'm going to on mondays [10:23] pitti, right :) [10:25] pitti: yes if you prep it for Debian anyway it is the same structure for d/p/* [10:32] cpaelzer: yep, will send a salsa MP and then upload to jammy [10:32] (and test the backport, of course) [11:25] pitti: hi, could you take a look at Debian bug 1006465 ? [11:25] Debian bug 1006465 in src:python-dbusmock "python-dbusmock: Fails to build from source: README.rst is not README.md" [Serious, Open] https://bugs.debian.org/1006465 [11:27] the gnome-bluetooth maintainer is using bleeding edge python-dbusmock features, lol [11:48] jbicha: oops! will do, sure; weird, why didn't I get an email about that [12:04] jbicha: uploaded, I'll sync it to jammy tomorrow; thanks for pointing out! [12:04] (and I subscribed to the PTS now, another "oops") [12:39] I have a universe package that apparently has big-endian support broken upstream for 7 years without anyone raising the issue. The current version in the release pocket predates the breakage, but the one in -proposed is much more recent. [12:41] I'd like to remove the s390x build for this package as I figure that if a compilation failure went undetected for so long, there's probably other problems down the road. Anyone think it's a bad idea? [12:43] the package in question is virtuoso-opensource, which is a database. Endianness shenanigans could easily mess up the on-disk format [13:03] schopin: if the s390x binaries were already removed in debian, it makes sense for them just to be removed in ubuntu too [13:04] same for armhf [13:04] Yeah armhf was going out for sure, upstream explicitly doesn't support 32bit [13:04] schopin: see recent discussion in #ubuntu-release re: open3d [13:05] Allright, works for me. Thanks! [13:12] schopin: see debian bug #982800 [13:12] Debian bug 982800 in ftp.debian.org "RM: virtuoso-opensource [armel armhf i386 mipsel s390x] -- RoQA; upstream no longer supports 32bit or big endian" [Normal, Open] https://bugs.debian.org/982800 [13:14] you can refer to that in the ubuntu bug [13:26] ahasenack: hey, FYI, I was able to reproduce seldomly the flaky tests on arm64. I did give it a try and I think https://github.com/ubuntu/adsys/pull/297 addresses it. I couldn’t get it after dividing in phases, so crossing fingers :) I’ll upload once I get a review [13:26] Pull 297 in ubuntu/adsys "Try fixing flaky 'pick up config changes' tests" [Open] [13:27] didrocks: you used one of those arm64 boxes? [13:28] hah, I see a Sleep() :) [13:28] can't be avoided :) [13:28] ginggs: if we get the binaries removed from the archive, should I introduce a delta to explicitly remove them from the package? I'll forward a patch to Debian nonetheless. [13:28] ahasenack: yeah, I did use one, thanks for getting me access to it! Yeah, there is a sleep, but still different phases which avoids getting wrong amount of callbacks… [13:29] so a little bit less elegant than the initial test architecture, but unavoidable I guess… [13:29] I'm far from judging :) [13:43] schopin: no, no need to explicitly remove them from the package [15:00] cpaelzer: since I'm a little rusty: https://launchpadlibrarian.net/589804887/libvirt_8.0.0-1ubuntu4_8.0.0-1ubuntu5.diff.gz [15:00] cpaelzer: just tested (and reported on the bug), works fine [15:21] pitti: busy with calls for the rest of the day, but I've opened a window and can try to test more before sponsoring tomorrow [15:21] cpaelzer: ah, I felt lucky and uploaded already [15:21] happy to do a follow-up of course if something doesn't look right [15:22] (it was mostly about the "quilt refresh" noise, the rest is straightforward) [15:22] reverse dep autopkgtests should do the rest [15:22] (and of course I tested the build) [15:22] fine with me pitti [19:20] xypron: RE "Do you know who is responsible for creating the minimal Ubuntu images for Dockerhub? buildkit received RISC-V support last year." yes this is my team. I will see if there is any work ongoing on that front [19:28] xypron: Nothing planned as of yet. [20:58] paride: awesome memory on https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1930921/comments/5 :) that's an excellent suggestion [20:58] Launchpad bug 1930921 in samba (Ubuntu) "Apache 2.4.41 corrupts files from samba share" [Undecided, Confirmed] [21:54] philroche: There actually is already a riscv64 image on Dockerhub: https://hub.docker.com/_/ubuntu Works nice with our docker.io on riscv64 now. [22:47] mapreri: I confirmed bug 1964390, is this something you're at least peripherally aware of? [22:47] Bug 1964390 in inkscape (Ubuntu) "Inkscape will not launch on Ubuntu 22.04" [Undecided, Confirmed] https://launchpad.net/bugs/1964390