[01:51] waveform: did you get to look at sbuild syncability? === cpaelzer_ is now known as cpaelzer [07:35] mwhudson, I guess the unshare test needs some more tweaking [07:35] but 99% is syncable to me [09:14] mwhudson, yes -- it's *almost* syncable but there's still two remaining changes (both of which have pending upstream MRs so I'm guessing it should be syncable at some point in the relatively near future). Anyway, I've merged those two changes, but ran into an apt issue in trying to run the autopkgtests [11:32] FYI, there's a Python 3.11 deprecation that breaks the dovecot autopkgtest. It seems to affect s390x only at the moment. I have an upload on the way. [11:32] Other archs seem to still be on Python 3.10? [11:32] (even in proposed) [11:33] hm? [11:33] are you sure you are not being confused by no-automatic? [11:38] Oh. Maybe. [11:38] But anyway, if I force python3.11 then it reproduces. [11:38] So it does need fixing in the end. [11:51] Greetings everyone! [11:51] Anyone experienced in Canonistack can help me understand how do I reproduce a lunar-proposed autopkgtest in the cloud if "openstack image list" lists only up to Jammy? [11:52] Greetings MacSlow! [11:52] https://code.launchpad.net/~racb/ubuntu/+source/dovecot/+git/dovecot/+merge/436038 is ready [12:22] rbasak: fyi debian bug #1028513 [12:22] -ubottu:#ubuntu-devel- Debian bug 1028513 in src:dovecot "dovecot: autopkgtest failure with python3.11" [Serious, Open] https://bugs.debian.org/1028513 [12:25] ginggs: ah thanks. I'll send the patch there then once done in Ubuntu. [12:26] I think mine is preferable to the patch there since it stops using crypt entirely, delegating that mess to chpasswd === ejat is now known as fenris [15:29] hm https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/g/golang-gopkg-lxc-go-lxc.v2/20230119_011820_885eb@/log.gz i'm a bit confused about this. My first q: that pkg does not have a debian/tests/exercise - so where is the test script coming from? [15:29] I can reproduce locally with '/usr/bin/autopkgtest -s --apt-pocket=proposed=src:lxc --apt-upgrade golang-gopkg-lxc-go-lxc.v2 -- qemu autopkgtest-lunar-amd64.img', [15:30] but what seems to be happening is liblxc1 is installed, but not its dependencies. apt-cache show liblxc1 shows the dependencies, so how did they (libseccomp-dev, etc) not get installed? [15:44] hallyn: the test is from autodep8(run autodep8 in source dir, it will output the real test) [15:51] hallyn: this package depends on lxc-dev, in debian it has a depend on libseccomp-dev [15:52] zhsj: but how did liblxc1 get installed without its Depends... [15:53] lemme try autodep8, thanks [15:53] hallyn: it complains the missing of libX-dev package, not the libX [15:55] zhsj: "this package depends on lxc-dev" - by "this pkg" do you mean golang-gopkg-lxc-go-lxc.v2 ? [15:55] yes. [16:00] https://packages.debian.org/sid/golang-gopkg-lxc-go-lxc.v2-dev i must b elooking in the wrong place [16:01] hallyn: it uses build-deps for autopkgtest(from autodep8) [16:14] its debian/control lists lxc-dev as a build-dep, and lxc source pkg lists libseccomp-dev, so i'm not getting why it's missing. The source packages for debian and ubuntu golang-gopkg-lxc-go-lxc.v2 are identical. [16:14] I'm sure it's a side effect of the switch to meson for building lxc itself, but i'm failing to see why [16:40] nteodosio: if you have to use canonistack I'd probably start at jammy and get to lunar-proposed by updating /etc/apt/sources.list and upgrading [16:43] I have another autopkgtest question. python3-futurist is failing on i386 due to "python3-openstacksdk : Depends: python3-netifaces (>= 0.10.4) but it is not going to be installed with i386". I think this is because netifaces does not build for i386 - https://launchpad.net/ubuntu/+source/netifaces. thoughts on how to handle that? [16:45] hallyn: lxc in proposed has `Requires.private: libseccomp, libselinux, libcap` [16:45] in /usr/lib/x86_64-linux-gnu/pkgconfig/lxc.pc [16:46] so if i only install liblxc-dev, not libseccomp-dev, `pkg-config --cflags -- lxc` command will fail [16:46] Thanks coreycb. [16:46] hallyn: so i think you need libseccomp-dev in liblxc-dev's Depends? [16:46] and maybe libselinux-dev, libcap-dev [16:50] To any cmake-experts present... [16:51] How can I make cmake actually use ninja as the generator just by stating this very generator in the usual CMakeLists.txt? [16:51] It seems no matter where I place it in the CMakeLists.txt file, it always defaults to Unix Makefiles. [16:51] thanks in advance! [16:52] Of course I can do "cmake -G "Ninja" ..", but that's not the point. [16:53] zhsj: possibly, but older lxc packaging doesn' thave that either. Trying to find what's different, comparing to e.g. 4.0.12 on another machine. [16:53] hallyn: yeah, the difference is `Requires.private` in lxc.pc [16:53] the old version doesn't have such [16:54] as you mention the switch of meson, then that's probably related. [16:57] oh, what is that. The old has: Libs.private: -lcap -lseccomp -lselinux -lpam [16:58] ok thanks, i'll research that tonight. not well versed in *.pc [16:58] * zhsj not expert at pkg-config as well [17:18] yes, those deps need to be added to the -dev === MacSlow is now known as MacSlow|afk [20:03] bluca: zhsj: ok, i'll add hte -dev deps as simple Depends for liblxc-dev. What I'm still confused about is why this is only a problem now, as this hasn't changed from liblxc-dev:4.0.12 === JanC is now known as Guest3686 === JanC_ is now known as JanC === MacSlow|afk is now known as MacSlow