[08:26] sergiodj: looking at check-manifest, I'm questioning the usefulness of the autopkg test ... you are using tox which gets everything from pypi, and doesn't test anything which is packaged [08:58] doko: should python depend on ca-certificates? see bug 1879310 [08:58] bug 1879310 in python3.9 (Ubuntu Focal) "python package does not depend on ca-certificates" [Undecided,New] https://launchpad.net/bugs/1879310 [09:09] tjaalton: hmm, how do other languages like ruby and perl handle that? [09:10] dunno [09:14] or maybe apt should depend on it instead of recommending [09:21] I would have thought that if you wanted ca-certs in the container you'd install it. Doesn't seem right for any interpreter or even apt to be deciding what certs the admin wants to trust [09:28] you can configure that using debconf, otoh probably not many people are doing that [09:29] for ruby it's rubygems-integration that pulls in ca-certificates [09:29] so doing 'apt install ruby' installs it [11:22] bdmurray: did you mean install python3-pip?! we have moved on to python3 a long time ago..... [12:01] slyon, xnox: sponsored user-setup again [12:02] thanks for the heads-up! [12:02] the block-proposed tag can be removed now imo [12:02] I will do that [14:56] hi, I'm looking at a (for me) new kind of i386 autopkgtest issue that others might have touched before and wanted to ask for hints or former solutions [14:56] the test I look at uses pkg-config, but due to our "actually amd64 but with i386 arch added" [14:56] pkg-config won't find the .pc file from foo-dev:i386 [14:57] is that a common pattern and if so could one point me to anther package that was affected that I could use to copy the solution from? [15:06] cpaelzer, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946577 [15:06] Debian bug 946577 in libinput "Please make autopkgtests cross-test-friendly" [Minor,Fixed] [15:06] cpaelzer, and yes it's common, I sent a stack of similar reports and patches [15:07] cpaelzer, (email text is copied from one Steve wrote) [15:07] great, thanks seb128 [15:07] np! [15:09] sil2100, hey, could you help unblock the yaru/focal SRU? it's needed to unblock some snap theme fixes to land since the experience needs to be similar accross series [15:10] seb128: ah, it's the one Robie was looking at and had some concerns? I can take a look at that [15:12] sil2100, I think it ended up being blocked on the gnome-shell vs testing extensions in the archive discussion but it isn't linked to gnome-shell so we could let that one in alone, it basically copied gnome-shell uptream fixes to our themes but it's not dependant of code changes [15:12] they apply as well on the current shell version [15:12] I checked with Marco before pinging :) [15:12] sil2100, ideally we would unblock the shell but I'm unsure what is needed ... maybe you have some suggestion? [15:12] sil2100, and thanks :) [15:14] * sil2100 is diving into the backlog to have the full context === acheronuk is now known as RikMills [15:26] xnox: My point was about the strange c-n-f response [15:30] seb128, do you know what broke https://autopkgtest.ubuntu.com/packages/g/gvfs/hirsute/i386 ? [15:31] rbalint, no idea sorry, sounds like python3 not installable, unsure if it's meant to be or if there is another issue [15:33] seb128, thanks, digging further later then [15:33] seb128: ok, so I think I can indeed unblock yaru-theme with all the information - for gnome-shell I wouldn't want to straight away override Robie until all the concerns are resolved [15:35] rbalint: don't, it was a victim of me mis-updating a hack we have in autopkgtest-cloud, it just needs the reset-test hint bumped :( [15:38] GunnarHj, ^ the gtk one you mentioned might be on the same case [15:41] Laney, oh, so the passes were false positive because i386 tests ran with amd64 packages? [15:42] correct [15:42] seb128: It might? It's probably above my head. About to build isenkram in a hirsute PPA. [15:42] you can look for '-a i386' being present or not in the top line [15:42] hey - I'm seeing an odd issue in a focal pbuilder today: when I run `pbuilder-dist focal build ../build-area/nova_21.1.0-0ubuntu1.dsc` on a freshly built package, there are unit test failures like: `FileNotFoundError: [Errno 2] No such file or directory: 'systemctl'`. After the build fails, if I drop into the chroot and `apt install systemctl`, the tests pass. Has there been some change recently that might account for that or is there some odd config [15:42] locally (ie: I should rebuild the environment) [15:42] Laney, i guess the reset test should be converted to badtest, right? [15:43] no, if it does start to work again legitimitely we'd want to consider those results [15:43] icey: if you need systemctl then it sounds like you're missing a build-dep on systemd [15:43] Laney, because we have force-reset-test gvfs/1.46.1-1ubuntu1/i386 and 1.46.1-1ubuntu1 in the archive [15:44] rbalint: I just increased that from some earlier version [15:44] Laney: has something relevant changed? as this is the version that is released in Focal as well [15:44] I dunno, maybe you used to get systemd by some dep chain before and now you don't [15:45] dh-systemd ? [15:47] anyways, going to try with adding systemd directly [15:47] thanks! [15:48] That or the chroot / build environment you used before has systemd in it and this one doesn't now [15:49] but not dh-systemd no, that doesn't depend on systemd [15:56] mhm, no idea what caused it then :-/ [16:12] sil2100, thanks for the yaru review, and ack for the gnome-shell one, I didn't want to ask you to bypass anything, I think we need to address the concerns from the desktop side, probably by doing a round of testing of extensions for that one [16:13] but then we probably should update to .7 directly now that it's available to avoid having to do another around [16:13] Trevinho, ^ [16:13] ack [16:39] o/ [16:58] Are ISO Builds passing? Ubuntu Cinnamon Remix's builds are failing with ca-certificates https://github.com/Ubuntu-Cinnamon-Remix/iso-builder/runs/1375425058 [17:10] what is in the /iso-builder/tmp/amd64/chroot/debootstrap/debootstrap.log ? [17:10] that would have actual errors.... [17:11] also note it does say right that the related package is a different one... "(possibly the package dconf-service is at fault)" [17:19] xnox, have you given a try to backporting riscv64 cgo to 1.15? [17:20] xnox, apparently i can't get systemd migrated without it [17:21] xnox, or i can cheat with hints [17:23] doko: that package has been on my list of "fixes TODO" for a while. you're correct, that autopkgtest is moot. I haven't had the time to fix it yet [17:37] xnox: I'm probably going to locally build it, but I'm wondering if anyone else is having a similar problem. [17:49] xnox, i give it a try to backport the cgo patches [17:54] xnox, i let mwhudson take a look at it first https://github.com/4a6f656c/go/tree/riscv64-cgo-1.15 [18:08] xnox, I think this is what it comes down to: https://paste.ubuntu.com/p/s9SDbFy6fd/ [18:08] I don't have admin access to QA builds or the physical ISO QA builder scripts and all so are those packages in the paste installed? [19:12] bdmurray: hm true. can you open a bug? i wonder if we have a manual hint for it somewhere. [19:15] xnox: yeah [19:54] rbalint: i'd almost prefer to remove golang-defaults from proposed until 1.16 is ready but i don't have strong feelings about it [20:13] mwhudson, this sounds sad a bit [20:14] bdmurray, could you please merge https://code.launchpad.net/~rbalint/britney/+git/hints-ubuntu/+merge/393510 ? [20:14] rbalint: well given you've done the work of backporting, we should probably use that i guess [20:14] rbalint: have you tested this much? [20:15] mwhudson, no, i have not started yet, it just looked not overly complex [20:15] rbalint: if it builds snapd in a ppa i guess that's good enough :) [20:16] mwhudson, and since you uploaded 1.15 i wanted to ask [20:17] rbalint: your branch seems based on 1.15, not the latest point release [20:17] we have 1.15.2 i think, which is also not the latest point release [20:18] so it probably makes sense to update that in debian before any of this (that's usually trivial, gbp import-orig --uscan && upload) [20:21] bdmurray, fixed it up a bit [20:22] mwhudson, thanks for the tips [20:22] rbalint: i can do the debian update if you want [20:23] mwhudson, that would be great because i'm about to file a day off for tomorrow [20:23] rbalint: ok [21:45] (merge)mwhudson@anduril:~/src/pkg/cryptsetup$ git ubuntu lint [21:45] "lint" is not currently available [21:45] what am i missing? [22:25] sil2100, rbalint , the glibc/bionic SRU can probably be unblocked again? I noticed it was still set on 0% but since it turned out to be a lftp issue and that has a fix uploaded now no reason to keep it blocked right? [23:15] rbalint: i've just uploaded golang 1.15.4 to unstable [23:15] rbalint: although 1.15.5 just got pre-announced for three days time... === ebarretto_ is now known as ebarretto