[05:52] <adrien> hey, can someone re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=ppc64el&package=exim4&trigger=anacron/2.3-36ubuntu2 ? it looks like a failure in the preparation steps
[05:57] <adrien> and unrelated to anacron/exim4, these two for libcamera:  https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=libcamera&trigger=libcamera%2F0.0.4-2ubuntu2 and https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=ppc64el&package=libcamera&trigger=libcamera%2F0.0.4-2ubuntu2
[06:06] <ginggs> adrien: .
[06:16] <adrien> thanks
[07:29] <vpa1977> Hi, would it be possible to retry tests for rust-alloc-stdlib, the issue that was preventing migration was fixed in rust-brotli-decompressor 2.3.4-1 which just got published.
[07:29] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=rust-brotli-decompressor&trigger=rust-alloc-stdlib%2F0.2.2-1
[07:29] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=rust-brotli-decompressor&trigger=rust-alloc-stdlib%2F0.2.2-1
[07:29] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=rust-brotli-decompressor&trigger=rust-alloc-stdlib%2F0.2.2-1
[07:29] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=ppc64el&package=rust-brotli-decompressor&trigger=rust-alloc-stdlib%2F0.2.2-1
[07:29] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=rust-brotli-decompressor&trigger=rust-alloc-stdlib%2F0.2.2-1
[07:29] <vpa1977> Thank you!!!
[07:35] <ginggs> vpa1977: 'rmadison librust-brotli-decompressor-dev' says too soon
[07:43] <vpa1977> ginggs: oh
[08:12] <ginggs> vpa1977: rmadison says yes
[08:13] <ginggs> vpa1977: i did './retry-autopkgtest-regressions --blocks rust-alloc-stdlib'
[08:15] <vpa1977> gings: thanks!!!
[16:21] <lvoytek> mdeslaur: Hi, a few bugs have come up in Samba since the security update two days ago. It seems things are breaking in Focal currently -
[16:21] <lvoytek> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2009858
[16:21] <lvoytek> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2009863
[16:21] -ubottu:#ubuntu-devel- Launchpad bug 2009858 in samba (Ubuntu Focal) "User authentication is broken with 2:4.15.13+dfsg-0ubuntu0.20.04.1 package" [Critical, Confirmed]
[16:21] -ubottu:#ubuntu-devel- Launchpad bug 2009863 in samba (Ubuntu Focal) "Upgrade from Samba 4.13 to 4.15 results in 'dlopen(pam_winbind.so): /lib/security/pam_winbind.so: cannot open shared object file: No such file or directory'" [Critical, New]
[16:21] <mdeslaur> lvoytek: I saw them, and I can't reproduce them
[16:21] <mdeslaur> lvoytek: if anyone has an idea why they are having issues, I'm all ears
[16:22] <mdeslaur> let me ask for more info in the bugs
[16:45] <rbasak> sil2100, vorlon: I did wait for someone to notice and fix it first. But I got fed up of deleting emails from my main inbox by hand, and wasn't keen on spending effort on setting up procmail over fixing it for others too
[16:59] <coreycb> ginggs: thanks, I just built the new jinja2 and I'm not seeing any need for plastex
[17:00] <ginggs> coreycb: plastex 2.1-3's autopkgtests will fail with the new jinja2
[17:01] <coreycb> ginggs: ok
[17:07] <vorlon> rbasak: quite understandable, sorry about that
[17:24] <coreycb> ginggs: they both build successfully. can I sync them over?
[17:58] <danilogondolfo> May I ask someone to retry this test for me, please? https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=cryptsetup&trigger=systemd/252.5-2ubuntu2&trigger=netplan.io/0.106-0ubuntu2&trigger=tinyssh/20230101-1
[18:23] <dbungert> danilogondolfo: done
[18:24] <danilogondolfo> thank you dbungert!
[19:00] <ahasenack> what's the trick to build the python3.11 source package?
[19:00] <ahasenack> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[19:00] <ahasenack> $ update-maintainer
[19:00] <ahasenack> XSBC-Original is managed by 'rules' file. Doing nothing.
[19:00] <ahasenack> just hack d/control* manually?
[19:00] <ahasenack> or is there a build flag I can use to ignore that error?