On Fri, Dec 10, 2021 at 02:06:27PM -0800, Bryce Harrington wrote:
> * node-ast-types:
> - Single failure on i386, probably flaky test
> - I tried retriggering the i386 run, but probably needs reset
> * node-recast:
> - Depends on node-ast-types (above)
> There are also a bunch that fail on i386-only. I don't know if i386 is
> relevant for node-*; if not then perhaps these fails can be overridden?
> Several are failing on 'code 14' (dunno what that is) or might be flaky
> fails.
> * node-caniuse-db
> * node-json-loader
> * node-unicode-match-property-value-ecmascript
> * node-unicode-property-aliases
> * node-unicode-property-value-aliases
> * node-unicode-property-value-aliases-ecmascript
> * node-unicode-canonical-property-names-ecmascript
> * node-unicode-property-aliases-ecmascript
The vast majority of node packages are Architecture: all, so there's no
value in testing them on i386. We don't even build i386 binaries of nodejs;
we just unfortunately don't have a reliable way to skip testing of all of
these packages.
node-ast-types in the release pocket passed because it's successfully but
uselessly testing against the amd64 build of nodejs in the test environment.
But in -proposed, the package has more test dependencies which are not
cross-installable.
I've gone through update_excuses and added hints to ignore all i386-only
autopkgtest failures for node packages.
> The last piece is "lintian-brush", which I started working on as well,
> but it looks like it's grown additional test failures, and wonder if it
> needs newer breezy changes, yet again. This package sounds like it's
> very specific to Debian package maintenance. Do we use it in Ubuntu
> package maintenance?
I've only ever heard of this package in the context of the breezy ecosystem
being stuck in -proposed. I don't think it's widely used in Debian either.
It's certainly something we could drop from the release if it's broken.
> ### NBS ###
>
> I worked a bit on a script to extract the list of faulty packages for
> NBS and do no-change rebuilds in a PPA. Using the results from that, I
> attempted the following NBS fixes:
>
> * biboumi:
> - d/control needed to specify libidn-dev instead of libidn11-dev
I was puzzled to see this on your list because I had been looking at it and
didn't notice any problems wrt wrong build-deps. It appears libidn11-dev
despite its name depends on libidn-dev (i.e. it's a transitional package)
and biboumi in -proposed is built against the correct version of libidn,
it's just blocked by botan not being migratable - which is a ppc64el build
failure.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
