[10:03] <pitti> cpaelzer: \o/ thanks for merging https://gitlab.com/libvirt/libvirt/-/merge_requests/140
[10:03] <pitti> 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] <seb128> pitti, hey! how are you? :-)
[10:13] <pitti> bonjour seb128 ! je vais très bien, merci ! trying to fix some AppArmor issue in Debian/Ubuntu 😀
[10:14] <seb128> pitti, I think I saw you on screen monday :)
[10:14] <pitti> et toi ! comment est la terre de desktop ?
[10:15] <seb128> pitti, ça va bien merci! we had our first engineering sprint in 2 years, was nice to see people in real again!
[10:21] <pitti> seb128: right, I saw that on twitter or telegram or so 🍻 nice!
[10:21] <seb128> :)
[10:22] <seb128> pitti, small world, I didn't know you had a team member in Delft!
[10:22] <pitti> seb128: yes, Jelle, since last August
[10:22] <pitti> seb128: ah, that's what you meant with "screen"!
[10:22] <seb128> pitti, he started coming to the coworking I'm going to on mondays
[10:23] <seb128> pitti, right :)
[10:25] <cpaelzer> pitti: yes if you prep it for Debian anyway it is the same structure for d/p/*
[10:32] <pitti> cpaelzer: yep, will send a salsa MP and then upload to jammy
[10:32] <pitti> (and test the backport, of course)
[11:25] <jbicha> pitti: hi, could you take a look at Debian bug 1006465 ?
[11:27] <jbicha> the gnome-bluetooth maintainer is using bleeding edge python-dbusmock features, lol
[11:48] <pitti> jbicha: oops! will do, sure; weird, why didn't I get an email about that
[12:04] <pitti> jbicha: uploaded, I'll sync it to jammy tomorrow; thanks for pointing out!
[12:04] <pitti> (and I subscribed to the PTS now, another "oops")
[12:39] <schopin> 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] <schopin> 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] <schopin> the package in question is virtuoso-opensource, which is a database. Endianness shenanigans could easily mess up the on-disk format
[13:03] <ginggs> schopin: if the s390x binaries were already removed in debian, it makes sense for them just to be removed in ubuntu too
[13:04] <ginggs> same for armhf
[13:04] <schopin> Yeah armhf was going out for sure, upstream explicitly doesn't support 32bit
[13:04] <ginggs> schopin: see recent discussion in #ubuntu-release re: open3d
[13:05] <schopin> Allright, works for me. Thanks!
[13:12] <ginggs> schopin: see debian bug #982800
[13:14] <ginggs> you can refer to that in the ubuntu bug
[13:26] <didrocks> 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:27] <ahasenack> didrocks: you used one of those arm64 boxes?
[13:28] <ahasenack> hah, I see a Sleep() :)
[13:28] <ahasenack> can't be avoided :)
[13:28] <schopin> 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] <didrocks> 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] <didrocks> so a little bit less elegant than the initial test architecture, but unavoidable I guess…
[13:29] <ahasenack> I'm far from judging :)
[13:43] <ginggs> schopin: no, no need to explicitly remove them from the package
[15:00] <pitti> cpaelzer: since I'm a little rusty: https://launchpadlibrarian.net/589804887/libvirt_8.0.0-1ubuntu4_8.0.0-1ubuntu5.diff.gz
[15:00] <pitti> cpaelzer: just tested (and reported on the bug), works fine
[15:21] <cpaelzer> 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] <pitti> cpaelzer: ah, I felt lucky and uploaded already
[15:21] <pitti> happy to do a follow-up of course if something doesn't look right
[15:22] <pitti> (it was mostly about the "quilt refresh" noise, the rest is straightforward)
[15:22] <pitti> reverse dep autopkgtests should do the rest
[15:22] <pitti> (and of course I tested the build)
[15:22] <cpaelzer> fine with me pitti
[19:20] <philroche> 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] <philroche> xypron: Nothing planned as of yet.
[20:58] <sarnold> paride: awesome memory on https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1930921/comments/5   :) that's an excellent suggestion
[21:54] <xypron> 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] <Eickmeyer> mapreri: I confirmed bug 1964390, is this something you're at least peripherally aware of?