[08:26] <doko> 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] <tjaalton> doko: should python depend on ca-certificates? see bug 1879310
[09:09] <doko> tjaalton: hmm, how do other languages like ruby and perl handle that?
[09:10] <tjaalton> dunno
[09:14] <tjaalton> or maybe apt should depend on it instead of recommending
[09:21] <themill> 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] <doko> you can configure that using debconf, otoh probably not many people are doing that
[09:29] <tjaalton> for ruby it's rubygems-integration that pulls in ca-certificates
[09:29] <tjaalton> so doing 'apt install ruby' installs it
[11:22] <xnox> bdmurray:  did you mean install python3-pip?! we have moved on to python3 a long time ago.....
[12:01] <rbalint> slyon, xnox: sponsored user-setup again
[12:02] <slyon> thanks for the heads-up!
[12:02] <rbalint> the block-proposed tag can be removed now imo
[12:02] <slyon> I will do that
[14:56] <cpaelzer> 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] <cpaelzer> the test I look at uses pkg-config, but due to our "actually amd64 but with i386 arch added"
[14:56] <cpaelzer> pkg-config won't find the .pc file from foo-dev:i386
[14:57] <cpaelzer> 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] <seb128> cpaelzer, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946577
[15:06] <seb128> cpaelzer, and yes it's common, I sent a stack of similar reports and patches
[15:07] <seb128> cpaelzer, (email text is copied from one Steve wrote)
[15:07] <cpaelzer> great, thanks seb128
[15:07] <seb128> np!
[15:09] <seb128> 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] <sil2100> seb128: ah, it's the one Robie was looking at and had some concerns? I can take a look at that
[15:12] <seb128> 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] <seb128> they apply as well on the current shell version
[15:12] <seb128> I checked with Marco before pinging :)
[15:12] <seb128> sil2100, ideally we would unblock the shell but I'm unsure what is needed ... maybe you have some suggestion?
[15:12] <seb128> sil2100, and thanks :)
[15:14]  * sil2100 is diving into the backlog to have the full context
[15:26] <bdmurray> xnox: My point was about the strange c-n-f response
[15:30] <rbalint> seb128, do you know what broke https://autopkgtest.ubuntu.com/packages/g/gvfs/hirsute/i386 ?
[15:31] <seb128> rbalint, no idea sorry, sounds like python3 not installable, unsure if it's meant to be or if there is another issue
[15:33] <rbalint> seb128, thanks, digging further later then
[15:33] <sil2100> 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] <Laney> 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] <seb128> GunnarHj, ^ the gtk one you mentioned might be on the same case
[15:41] <rbalint> Laney, oh, so the passes were false positive because i386 tests ran with amd64 packages?
[15:42] <Laney> correct
[15:42] <GunnarHj> seb128: It might? It's probably above my head. About to build isenkram in a hirsute PPA.
[15:42] <Laney> you can look for '-a i386' being present or not in the top line
[15:42] <icey> 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] <icey> locally (ie: I should rebuild the environment)
[15:42] <rbalint> Laney, i guess the reset test should be converted to badtest, right?
[15:43] <Laney> no, if it does start to work again legitimitely we'd want to consider those results
[15:43] <Laney> icey: if you need systemctl then it sounds like you're missing a build-dep on systemd
[15:43] <rbalint> Laney, because we have force-reset-test gvfs/1.46.1-1ubuntu1/i386 and 1.46.1-1ubuntu1 in the archive
[15:44] <Laney> rbalint: I just increased that from some earlier version
[15:44] <icey> Laney: has something relevant changed? as this is the version that is released in Focal as well
[15:44] <Laney> I dunno, maybe you used to get systemd by some dep chain before and now you don't
[15:45] <icey> dh-systemd ?
[15:47] <icey> anyways, going to try with adding systemd directly
[15:47] <icey> thanks!
[15:48] <Laney> That or the chroot / build environment you used before has systemd in it and this one doesn't now
[15:49] <Laney> but not dh-systemd no, that doesn't depend on systemd
[15:56] <icey> mhm, no idea what caused it then :-/
[16:12] <seb128> 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] <seb128> but then we probably should update to .7 directly now that it's available to avoid having to do another around
[16:13] <seb128> Trevinho, ^
[16:13] <Trevinho> ack
[16:39] <sil2100> o/
[16:58] <ItzSwirlz> 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] <xnox> what is in the /iso-builder/tmp/amd64/chroot/debootstrap/debootstrap.log ?
[17:10] <xnox> that would have actual errors....
[17:11] <xnox> also note it does say right that the related package is a different one... "(possibly the package dconf-service is at fault)"
[17:19] <rbalint> xnox, have you given a try to backporting riscv64 cgo to 1.15?
[17:20] <rbalint> xnox, apparently i can't get systemd migrated without it
[17:21] <rbalint> xnox, or i can cheat with hints
[17:23] <sergiodj> 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] <ItzSwirlz> xnox: I'm probably going to locally build it, but I'm wondering if anyone else is having a similar problem.
[17:49] <rbalint> xnox, i give it a try to backport the cgo patches
[17:54] <rbalint> xnox, i let mwhudson take a look at it first https://github.com/4a6f656c/go/tree/riscv64-cgo-1.15
[18:08] <ItzSwirlz> xnox, I think this is what it comes down to: https://paste.ubuntu.com/p/s9SDbFy6fd/
[18:08] <ItzSwirlz> 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] <xnox> bdmurray: hm true. can you open a bug? i wonder if we have a manual hint for it somewhere.
[19:15] <bdmurray> xnox: yeah
[19:54] <mwhudson> 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] <rbalint> mwhudson, this sounds sad a bit
[20:14] <rbalint> bdmurray, could you please merge https://code.launchpad.net/~rbalint/britney/+git/hints-ubuntu/+merge/393510 ?
[20:14] <mwhudson> rbalint: well given you've done the work of backporting, we should probably use that i guess
[20:14] <mwhudson> rbalint: have you tested this much?
[20:15] <rbalint> mwhudson, no, i have not started yet, it just looked not overly complex
[20:15] <mwhudson> rbalint: if it builds snapd in a ppa i guess that's good enough :)
[20:16] <rbalint> mwhudson, and since you uploaded 1.15 i wanted to ask
[20:17] <mwhudson> rbalint: your branch seems based on 1.15, not the latest point release
[20:17] <mwhudson> we have 1.15.2 i think, which is also not the latest point release
[20:18] <mwhudson> 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] <rbalint> bdmurray, fixed it up a bit
[20:22] <rbalint> mwhudson, thanks for the tips
[20:22] <mwhudson> rbalint: i can do the debian update if you want
[20:23] <rbalint> mwhudson, that would be great because i'm about to file a day off for tomorrow
[20:23] <mwhudson> rbalint: ok
[21:45] <mwhudson> (merge)mwhudson@anduril:~/src/pkg/cryptsetup$ git ubuntu lint
[21:45] <mwhudson> "lint" is not currently available
[21:45] <mwhudson> what am i missing?
[22:25] <seb128> 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] <mwhudson> rbalint: i've just uploaded golang 1.15.4 to unstable
[23:15] <mwhudson> rbalint: although 1.15.5 just got pre-announced for three days time...