Due to last week's holidays and Portland on fire (...again), I timeshifted my +1 work a couple days. Here's what I got to:
### kopanocore ### This was blocking openldap, which Sergio is working on getting transitioned. One of this package's extensions is in PHP, and needed updated for PHP 8. Upstream has a patch to add PHP 8 support, but we're a few major releases behind so was not trivial to backport. But with that done now the package successfully builds and is ready to migrate with openldap. ### virtuoso ### This also blocked the openldap migration. The problem was that upstream had IEEE floating point fallback code for unrecognized architectures, and it didn't recognize any of ours. Removing the fallback solved the issue and allowed this to migrate. ### openldap ### Additionally, I did retriggers for some packages that are part of the openldap migration, which should now migrate when openldap does. Sergio indicated that mutter seems to be the last thing blocking Openldap from migrating. He pinged Marco Trevisan on the Desktop Team to investigate. ### gudev-sharp-1.0 ### We have two versions of gudev-sharp-* in the archive, and they both have a binary of the same name so they conflict with each other. Near as I can tell both are dead and unused by anything. I filed LP: #1933887 to remove the -1 package, which should be enough to resolve the problem, though TBH I think both source packages could go. ### movim ### The binaries for movim and its depends were removed due to php 8 issues. It is probably fine if the movim source package were removed as well, though in theory when debian updates to php 8 I expect they'll make the determination whether to update movim to php 8 or drop it themselves. ### pcp ### This was lacking a riscv64 binary for its dependency libbpfcc because libbpfcc intentionally excludes that architecture. I uploaded a change to do similarly for pcp, and requested an AA to remove the risc pcp binary but in checking with debian they opted to instead make python3-bpfcc a B-D conditional. pcp has now migrated successfully. ### libpgjava ### This and libscram-java are wanting to bring in a new package dependency libstringprep-java. It was in Debian new, but they've recently accepted it so now it's waiting in Ubuntu's new queue. Thanks go to LocutusOfBorg for explaining the situation. For tracking purposes on this I've filed LP: #1933555. ### Breezy-debian ### This appears to be ftbfs due to needing the newer breezy to build. breezy is getting investigated via LP: #1932313. I poked a bit but discovered nothing to add to the conversation. ### emscripten ### This is FTBFS due to an LLVM version compatibility issue, which I think may be resolved by syncing in a newer version from Debian experimental. Unfortunately, in building this locally there are new errors during the tests about not finding module 'wasm2c'. The testsuite takes a long time to run so I didn't get very deep on this, but I think this wasm2c module might relate to the wabt package, which also has a new version in experimental. So maybe a next action might be to grab wabt 1.0.21-1, build it, and then build emscripten 2.0.12~dfsg-2ubuntu1 against that. If that works, then sync wabt from experimental into -proposed, wait for it to build and then do the same for emscripten. ### picolibc ### "undefined reference to `__iob'" etc. during autopkgtest for 1.6.2-1. I didn't have a chance to dig into this, but looks to be worth reporting upstream. ### Retriggers / Rebuilds ### In addition to the above, I did the usual bulk retriggers and rebuilds, and got the following packages to migrate: √ bluez √ rbac-client-clojure √ ubiquity √ python-django √ libpfm4 Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
