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:00 |
---|---|---|
jbicha | even though i386 binaries were built earlier https://launchpad.net/ubuntu/+source/qtwayland-opensource-src/5.15.2-4/+build/22234712 | 00:01 |
jbicha | should I do a no-change rebuild? | 00:02 |
sarnold | I'm surprised we build it at all, it doesn't feel like one of the ones that steam would have needed | 00:03 |
bdmurray | Maybe check the i386-whitelist package set | 00:04 |
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:05 |
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:08 |
jbicha | sarnold: it's (apparently optionally) used by https://launchpad.net/ubuntu/+source/gst-plugins-good1.0/1.19.90-1ubuntu1 | 00:09 |
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:10 |
jbicha | I guess I'll ask Seb tomorrow then | 00:11 |
=== amurray_ is now known as amurray | ||
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 |
ubottu | Launchpad bug 1958661 in lxc (Ubuntu) "LXC fails to start container on some arm64 devices" [Undecided, New] | 11:46 |
sunweaver | This would be much appreciated!!! | 11:46 |
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:01 |
LocutusOfBorg | well, the test wasn't run in previous version, and fails there too | 13:24 |
=== rharper_ is now known as rharper | ||
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:50 |
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 | 14:55 |
kanashiro | ahasenack, ack | 15:01 |
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:07 |
rbasak | import it by injecting the request, because then it'll keep up with it regardless of component. | 15:08 |
ahasenack | rbasak: ok, thanks, yes, I did just that, requested a normal import | 15:56 |
cjwatson | rbasak: Odd - there's a component_name attribute on source_package_publishing_history that should tell you | 15:57 |
rbasak | Maybe we missed that | 15:59 |
cjwatson | Or maybe I'm missing some subtlety :) | 15:59 |
=== genii-core is now known as genii | ||
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:00 |
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:01 |
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:02 |
jbicha | vorlon: can you re-enable qtwayland-opensource-src for i386? gst-plugins-good1.0 in jammy-proposed wants it | 16:11 |
xnox | LocutusOfBorg: somewhat yes. But i didn't pay attention if we have upgraded node already, or not | 17:12 |
dbungert | Looking for a sponsor for a rebuild to help with NBS report: LP: #1959700 | 17:21 |
ubottu | Launchpad bug 1959700 in facter (Ubuntu) "Please upload a rebuild for libssl and libyaml-cpp" [Undecided, Confirmed] https://launchpad.net/bugs/1959700 | 17:21 |
schopin | dbungert: a simple rebuild is enough? | 17:22 |
dbungert | schopin: I think so, yes | 17:22 |
schopin | dbungert: allright :) | 17:23 |
dbungert | schopin: Thanks! | 17:23 |
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:41 |
ahasenack | or do we need bugs? | 17:42 |
=== mfo_ is now known as mfo | ||
bdmurray | ahasenack: a merge proposal but no bug would be good | 18:05 |
ahasenack | I filed a bug for myself already, but ok | 18:06 |
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:07 |
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 | 18:08 |
=== mfo_ is now known as mfo | ||
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 | 19:47 |
=== CodeMouse92 is now known as Guest1476 | ||
=== Guest1476 is now known as CodeMouse92 | ||
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 | 21:50 |
jbicha | ahasenack: we'd have to drop the build-depends from libblockdev first. Maybe Debian will do that with us | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!