+1 maintenance report

[Bryce Harrington]

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