[00:00] 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] even though i386 binaries were built earlier https://launchpad.net/ubuntu/+source/qtwayland-opensource-src/5.15.2-4/+build/22234712 [00:02] should I do a no-change rebuild? [00:03] I'm surprised we build it at all, it doesn't feel like one of the ones that steam would have needed [00:04] Maybe check the i386-whitelist package set [00:05] Or this discourse post https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598 [00:05] jbicha: I see in my IRC logs that it was removed from the i386 whitelist last October [00:08] https://irclogs.ubuntu.com/2021/10/08/%23ubuntu-release.html [00:08] -queuebot:#ubuntu-release- Packageset: Removed qtwayland-opensource-src from i386-whitelist in impish [00:09] sarnold: it's (apparently optionally) used by https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.19.90-1ubuntu1 [00:10] ahh... that *does* seem like something that steam would use, heh [00:10] it was dropped here https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.18.5-1ubuntu2 [00:11] I guess I'll ask Seb tomorrow then === amurray_ is now known as amurray [11:46] 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] Launchpad bug 1958661 in lxc (Ubuntu) "LXC fails to start container on some arm64 devices" [Undecided, New] [11:46] This would be much appreciated!!! [13:01] xnox, hello, did you work with openssl bundled in nodejs? [13:01] > 51 | hash = require('crypto').createHash(hashType); [13:01] https://launchpadlibrarian.net/583449555/buildlog_ubuntu-jammy-amd64.node-loader-utils_2.0.2-1_BUILDING.txt.gz [13:01] this looks a problem due to use of bundled ssl? [13:24] well, the test wasn't run in previous version, and fails there too === rharper_ is now known as rharper [14:50] rbasak: new packages in main are only seen by git-ubuntu if it's restarted? [14:50] in terms of importing them [14:55] 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] fyi [15:01] ahasenack, ack [15:07] 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] import it by injecting the request, because then it'll keep up with it regardless of component. [15:56] rbasak: ok, thanks, yes, I did just that, requested a normal import [15:57] rbasak: Odd - there's a component_name attribute on source_package_publishing_history that should tell you [15:59] Maybe we missed that [15:59] Or maybe I'm missing some subtlety :) === genii-core is now known as genii [16:00] 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] 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] That's slightly harder to resolve from the Launchpad API, I think. [16:02] 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] 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] vorlon: can you re-enable qtwayland-opensource-src for i386? gst-plugins-good1.0 in jammy-proposed wants it [17:12] LocutusOfBorg: somewhat yes. But i didn't pay attention if we have upgraded node already, or not [17:21] Looking for a sponsor for a rebuild to help with NBS report: LP: #1959700 [17:21] Launchpad bug 1959700 in facter (Ubuntu) "Please upload a rebuild for libssl and libyaml-cpp" [Undecided, Confirmed] https://launchpad.net/bugs/1959700 [17:22] dbungert: a simple rebuild is enough? [17:22] schopin: I think so, yes [17:23] dbungert: allright :) [17:23] schopin: Thanks! [17:41] 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] so just do it? [17:42] or do we need bugs? === mfo_ is now known as mfo [18:05] ahasenack: a merge proposal but no bug would be good [18:06] I filed a bug for myself already, but ok [18:07] 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] lto-disabled-list was at v15 then, but it had frr in its list [18:08] sorry, v16 [18:08] but still there === mfo_ is now known as mfo [19:47] 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] aha === CodeMouse92 is now known as Guest1476 === Guest1476 is now known as CodeMouse92 [21:50] vorlon: can we not build ndctl for i386? It's grown a dependency on libiniparser-dev which is not built on i386: [21:50] ndctl | 71.1-1build1 | jammy | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x [21:50] ndctl | 72.1-1 | jammy-proposed | source, amd64, arm64, armhf, ppc64el, riscv64, s390x [21:50] libiniparser-dev | 4.1-4ubuntu3 | jammy | amd64, arm64, armhf, ppc64el, riscv64, s390x [22:35] ahasenack: we'd have to drop the build-depends from libblockdev first. Maybe Debian will do that with us