[00:00] <jbicha> can anyone explain why https://people.canonical.com/~ubuntu-archive/madison.cgi?package=qtwayland-opensource-src&S=on is missing on i386 in jammy?
[00:01] <jbicha> even though i386 binaries were built earlier https://launchpad.net/ubuntu/+source/qtwayland-opensource-src/5.15.2-4/+build/22234712
[00:02] <jbicha> should I do a no-change rebuild?
[00:03] <sarnold> I'm surprised we build it at all, it doesn't feel like one of the ones that steam would have needed
[00:04] <bdmurray> Maybe check the i386-whitelist package set
[00:05] <bdmurray> Or this discourse post https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598
[00:05] <RikMills> jbicha: I see in my IRC logs that it was removed from the i386 whitelist last October
[00:08] <RikMills> https://irclogs.ubuntu.com/2021/10/08/%23ubuntu-release.html
[00:08] <RikMills> -queuebot:#ubuntu-release- Packageset: Removed qtwayland-opensource-src from i386-whitelist in impish
[00:09] <jbicha> sarnold: it's (apparently optionally) used by https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.19.90-1ubuntu1
[00:10] <sarnold> ahh... that *does* seem like something that steam would use, heh
[00:10] <jbicha> it was dropped here https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.18.5-1ubuntu2
[00:11] <jbicha> I guess I'll ask Seb tomorrow then
[11:46] <sunweaver> stgraber: hi. Here comes a request from the UBports team, would you mind fixing LXC for arm64 on Ubuntu focal? See: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1958661
[11:46] <sunweaver> This would be much appreciated!!!
[13:01] <LocutusOfBorg> xnox, hello, did you work with openssl bundled in nodejs?
[13:01] <LocutusOfBorg>         > 51 |     hash = require('crypto').createHash(hashType);
[13:01] <LocutusOfBorg> https://launchpadlibrarian.net/583449555/buildlog_ubuntu-jammy-amd64.node-loader-utils_2.0.2-1_BUILDING.txt.gz
[13:01] <LocutusOfBorg> this looks a problem due to use of bundled ssl?
[13:24] <LocutusOfBorg> well, the test wasn't run in previous version, and fails there too
[14:50] <ahasenack> rbasak: new packages in main are only seen by git-ubuntu if it's restarted?
[14:50] <ahasenack> in terms of importing them
[14:55] <ahasenack> kanashiro: I see you had a repository for lto-disabled-list, I just imported it into git-ubuntu: https://code.launchpad.net/ubuntu/+source/lto-disabled-list
[14:55] <ahasenack> fyi
[15:01] <kanashiro> ahasenack, ack
[15:07] <rbasak> ahasenack: yes - IIRC we couldn't find a way in Launchpad's API to determine if a package belongs to main or universe, so instead we fetch (and gpg verify) the apt indexes when the poller is started. So restarting the poller is necessary if there's a package that's not imported, moved to main, and you want it to be imported on the "all packages in main" criteria. However, an alternative is to just
[15:08] <rbasak> import it by injecting the request, because then it'll keep up with it regardless of component.
[15:56] <ahasenack> rbasak: ok, thanks, yes, I did just that, requested a normal import
[15:57] <cjwatson> rbasak: Odd - there's a component_name attribute on source_package_publishing_history that should tell you
[15:59] <rbasak> Maybe we missed that
[15:59] <cjwatson> Or maybe I'm missing some subtlety :)
[16:00] <rbasak> We are glossing over the main-ness of a package being a per-publication thing, rather than a property of a source package itself.
[16:01] <rbasak> That's a little tricky to resolve, and in git-ubuntu we just ignore it by looking to see if a package is in main in the development release at the time we looked.
[16:01] <rbasak> That's slightly harder to resolve from the Launchpad API, I think.
[16:02] <rbasak> Also, because of the design at the time, we wanted a "list of all packages in main" and that's harder to do without a large number of API calls if we're going to use source_package_publishing_history.component_name
[16:02] <rbasak> It might be easier now that we have a should_this_package_be_imported(pkg_name) function because that could look things up at the time.
[16:11] <jbicha> vorlon: can you re-enable qtwayland-opensource-src for i386? gst-plugins-good1.0 in jammy-proposed wants it
[17:12] <xnox> LocutusOfBorg:  somewhat yes. But i didn't pay attention if we have upgraded node already, or not
[17:21] <dbungert> Looking for a sponsor for a rebuild to help with NBS report: LP: #1959700
[17:22] <schopin> dbungert: a simple rebuild is enough?
[17:22] <dbungert> schopin: I think so, yes
[17:23] <schopin> dbungert: allright :)
[17:23] <dbungert> schopin: Thanks!
[17:41] <ahasenack> I'd like to remove a package from lto-disabled-list, I verified a) it builds fine with lto; b) the failure that got it placed in here was not lto related, but python related
[17:41] <ahasenack> so just do it?
[17:42] <ahasenack> or do we need bugs?
[18:05] <bdmurray> ahasenack: a merge proposal but no bug would be good
[18:06] <ahasenack> I filed a bug for myself already, but ok
[18:07] <ahasenack> I don't understand something, though. frr is in lto-disabled-list, but the build logs of the last upload in launchpad show -lto* flags were used: https://launchpadlibrarian.net/568804185/buildlog_ubuntu-jammy-amd64.frr_8.1-1_BUILDING.txt.gz
[18:08] <ahasenack> lto-disabled-list was at v15 then, but it had frr in its list
[18:08] <ahasenack> sorry, v16
[18:08] <ahasenack> but still there
[19:47] <ginggs> ahasenack: i have seen some packaging that is immune to lto-disabled-list, e.g. https://launchpad.net/ubuntu/+source/ferret-vis/7.6.0-2ubuntu1
[19:47] <ahasenack> aha
[21:50] <ahasenack> vorlon: can we not build ndctl for i386? It's grown a dependency on libiniparser-dev which is not built on i386:
[21:50] <ahasenack> ndctl | 71.1-1build1          | jammy                   | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[21:50] <ahasenack>  ndctl | 72.1-1                | jammy-proposed          | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
[21:50] <ahasenack>  libiniparser-dev | 4.1-4ubuntu3 | jammy           | amd64, arm64, armhf, ppc64el, riscv64, s390x
[22:35] <jbicha> ahasenack: we'd have to drop the build-depends from libblockdev first. Maybe Debian will do that with us