+1 Maintenace Report

[Bryce Harrington]

On Fri, Dec 10, 2021 at 03:04:18PM -0800, Steve Langasek wrote:
> 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.

Yes, I do think dropping it would be beneficial.  It's not an end-user
tool so if we're not using it either, then there's not much value in
having it relative to the +1 maintenance time it seems to require.

Other rdepends of breezy sound like they do have some plausible use
cases, but in general the ecosystem seems to require a lot of attention
to keeping it untangled.  Dropping a few of the more problematic pieces,
like lintian-brush, may help alleviate this.
 
> > ### 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.

It would be useful to have a way to track next actions like that on the
NBS page itself.  Can LP #'s be associated with it like the excuses page?

Bryce

> 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 at ubuntu.com                                     vorlon at debian.org

> -----BEGIN PGP SIGNATURE-----
> 
> iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmGz3OwACgkQVo0w8yGy
> Ez34WQ//Rue9lbeJAgaYgKewLFrTZIiSYjIZ+KUHOJnbCxLZNir86A+lcFXec8M/
> IArJimWY2WijV9iW4SEmq5tSyByRSGcFZ3MlKS0Y05TLP38KA+FQXE/aF/ZsSkdu
> 2mkqg8DmdRTso85XRw9jel8P8M7OFOWqL63/wXoEUdQ+QfWjX+yqOT21k164EEcV
> fyuvwp8Hn0MMgt+CRL8HaFF+YAfv/Fv2fZ5h/Lzu++RaJkanc2ppkfIGgCS/BcrV
> 6fBR8Jlu0qSyGS5tCzrMFtrjL8wihss/pirsLO53Jd3Vc05380PpnFxpi25eh+lB
> pMDmqXxjPtBQVhMUn10iXmDwepZOtqv1tIjhtejmwYM6EX/cDCVJEcBpDpb7PlHH
> V6eNBgoBoC/iiw+A41sdoy6m8Q1tOeYg1uhDbPw35Bp3u/FWR5HtX+CatyshhBwe
> OJH2r9CnANusbhl5DIBdrY/0SQAhawgTKoY5ACEyXRmU/HqoS/NBm0kC2GJLrXnA
> AUk3fDVg9IJz6mRPGdG59pV+T4MLDRoceEsbKMZW0xb2f4HEcgOWJuFZxovTowP+
> /nD5LXStnH0/uJ17tt+B9uk0bN7AwNwaMtE1v1zLjefesdmgP7VOODcQ5a1KvUdO
> p2DtQLvcfG66tMGsCDONGhClNqFRmX8Eu8tTbYeanIIyAoSW6Mw=
> =NOhd
> -----END PGP SIGNATURE-----