[10:12] <seb128> waveform, hey, just as a  FYI I triaged https://bugs.launchpad.net/bugs/1973285 and sounds like something we might want to fix one way or another?
[10:17] <waveform> seb128, argh -- I figured the removal of mmal on arm64 was going to bite me sooner or later -- I'll stick it on my list, thanks for the heads-up!
[10:35] <seb128> waveform, thanks!
[12:11] <ahasenack> morning
[12:11] <slyon> vorlon: hey! looking at the libgpg-error/i386 autopkgtest failure (code14). It looks like this fails due to "Restrictions: skip-not-installable" being removed, and replaced by explicitly instructing it to only run on i386 and amd64. So apparently it's supposed to PASS on i386, but never did in the past for Ubuntu (it was always skipped).
[12:11] <slyon> So we can either introduce a delta and revert that change, to skip on i386, or do some i386-whitelist magic, to make gcc-mingw-w64-x86-64:i386 available. What do you think?
[12:48] <seb128> rbasak, hey, could you check the update on bug #1973229 and tell us if you consider that as a reasonable SRU with the provded details?
[12:55] <rbasak> seb128: ack - I had a chat with jbicha about it late on Friday. It's on my list for today.
[12:55] <seb128> rbasak, thanks
[13:00] <ahasenack> vorlon: looks like isc-dhcp (upstream) will switch to carrying a bundled version of the old bind9 libraries: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942502#25
[13:00] <ahasenack> wonder what security thinks of this
[13:04] <ahasenack> and it happened in debian already: https://tracker.debian.org/news/1323159/accepted-isc-dhcp-443-1-source-into-unstable/
[13:34] <xnox> ahasenack:  security is already aware that the unbundled old bind9 libraries are used; and we should notify security to add the old bind9 as vendored one, they have tooling to keep track of these things - such that bind9 cve's trigger alerts to rebuild/patch isc-dhcp as well.
[13:34] <xnox> we do that for a few things.....
[13:34] <xnox> i usually email security@ubuntu.com to notify of such things.
[13:35] <ahasenack> I just pinged them on #security, got an ack
[13:35] <ahasenack> but I could email too
[16:14] <vorlon> slyon: I don't understand what I'm seeing in this libgpg-error autopkgtest log; the test is defined in debian/tests/control to have Architecture: amd64, but the test is being attempted and then failing with badpkg.  Maybe we have wrong filtering on architecture for our i386 autopkgtest env, which runs in a cross-environment? (i386 packages installed on amd64 testbed)
[16:16] <vorlon> slyon: in which case it is perhaps worth fixing this in lp:~ubuntu-release/autopkgtest/+git/development; but if not, we should just ignore the i386 test failure
[16:29] <vorlon> slyon: https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development/+merge/423176
[16:29] <slyon> vorlon: oh, indeed! This test is defined for "Architecture: amd64" only. Thanks for the pointers, I'll have a look at lp:~ubuntu-release/autopkgtest/+git/development tomorrow
[16:30] <slyon> thank you! I'm EOD already, so will do the review tomorrow
[19:35] <kanashiro> vorlon, could you please take a look at my patch here LP #1940077 ? I tried to implement what you proposed
[21:49] <vorlon> kanashiro: looks ok to me!
[22:20] <quidnunc> I'm trying to update the following package from upstream sources which are in Fossil (I don't have any packaging experience) https://salsa.debian.org/debian-gis-team/spatialite/-/tree/master/debian
[22:20] <quidnunc> Is there some function that just pulls the latest sources or a specific commit or tag?
[22:21] <quidnunc> Is that what gbp pull does?
[22:38] <rbasak> gbp can help with that for git if that's the workflow the packager uses already.