On Wednesday, November 2, 2022 5:26:35 AM EST Scott Kitterman wrote:
> On November 2, 2022 8:35:35 AM UTC, Gordon Ball
wrote:
> >On 19/10/2022 22:30, Gordon Ball wrote:
> >> On 09/10/2022 21:39, Gordon Ball wrote:
> >>> On 07/10/2022 01:13, Timo Röhling wrote:
> Hi Gordon,
>
> * Gordon Ball [2022-10-07 00:10]:
> > * Upload to unstable and see what breaks?
> > * Request an archive rebuild with this version and see what breaks?
> > * File bugs against all likely affected packages with a fixed date for
> > an upload?
> > * Wait until after the freeze?
>
> Considering that PyYAML has been issuing a YAMLLoadWarning since
> version 5.1 (i.e. September 2019), I would expect that many (most?)
> reverse dependencies have been fixed, and anything that still breaks
> is probably in dire need of maintenance anyway.
> >>>
> >>> Yes, that's a good point.
> >>>
> >>> I've done some more investigation of reverse-depends and looking for
> >>> likely bad patterns with codesearch.d.n, and the set of packages which
> >>> A) appear to contain plain `yaml.load(f)` or equivalent, where `yaml` is
> >>> pyyaml and B) actually depend or build-depend on `python3-yaml` is
> >>> smaller than I feared. This is what I came up with:
> >>>
> >>> ```
> >>> ansible # confirm - in ansible_collections/community/general/plugins
> >>> buildbot # confirm - in porttostable
> >>> ceph # confirm, in civetweb/third_party/duktape, src/test/crimson
> >>> docker-compose # confirm, in tests
> >>> dose3 # confirm, in scripts
> >>> elasticsearch-curator # confirm, in test/unit
> >>> etm # confirm, in etmTk/data
> >>> ganeti # confirm, in qa, test/py
> >>> gnocchi # confirm, in gnocchi/gendoc
> >>> gr-dab # confirm, in python/app
> >>> jeepyb # confirm, in cmd/notify_impact
> >>> knitpy # confirm, in knitpy
> >>> labgrid # confirm, in remote/coordinator
> >>> lecm # confirm, in lecm/configuration
> >>> lirc # confirm, in lirc/database
> >>> lqa # confirm, in lqa_api/job
> >>> open-adventure # confirm, in tests
> >>> owslib # confirm, in ogcapi
> >>> policyd-rate-limit # confirm, in config, tests
> >>> python-aptly # confirm, in publisher
> >>> python-canmatrix # confirm, in canmatrix/formats/yaml
> >>> python-multipart # confirm, in multipart/tests
> >>> python-pybedtools # confirm, in test, contrib
> >>> python-seqcluster # confirm, in install
> >>> python-tempestconf # confirm, in config_tempest/profile
> >>> qcat # confirm, in adapters
> >>> qcengine # confirm, in config
> >>> refstack-client # confirm, in refstack_client
> >>> relatorio # confirm, in templates/chart
> >>> ripe-atlas-tools # confirm, in tools/settings
> >>> ros-genpy # confirm, in test
> >>> ros-rosinstall # confirm, in test, src/rosinstall
> >>> ros-rosinstall-generator # confirm, in test, src/rosinstall_generator
> >>> spades # confirm, in assembler/src/test/teamcity,
> >>> assembler/src/projects/mts, assembler/src/spades_pipeline
> >>> xrstools # confirm, in WIZARD
> >>> zlmdb # confirm, in _database
> >>> ```
> >>>
> >>> I don't know if all these codepaths are actually ever reached, or tests
> >>> ever run, so the packages won't necessarily break (or the breakage is
> >>> very minor, such as a single community plugin in ansible). I don't
> >>> guarantee there are no omissions from the list though.
> >>>
> >>> There is a significantly longer list of packages which appear to contain
> >>> a use of yaml.load _somewhere_, but it is usually in some
> >>> maintainer/release script, or an optional path somewhere, and the
> >>> package itself doesn't [build-]depend on python3-yaml.
> >>
> >> I've filed bugs for (most) of the packages listed above (some were
> >> dropped on review because they weren't in main, or the affected file
> >> appeared to be unused at build time and not installed). I've had a
> >> couple of acknowledgements/fixes already.
> >>
> >> A number of affected package look very sparsely used and/or maintained,
> >> and I doubt are likely to be fixed. However, of the packages above, only
> >> two have autopkgtests which fail on experimental migration, so I
> >> wouldn't be surprised if some are not already broken by other past
> >> changes.
> >>
> >> I propose to wait ~2 weeks until the beginning of November and upload
> >> pyyaml 6 to unstable then.>
> >pyyaml 6 has now landed in unstable. About half the bugs I filed have been
> >resolved, and there is only one package (ganeti) with autopkgtests
> >blocking migration.
> There were two more, but I retried the migration reference jobs and they
> failed (which makes them no longer block since they are no longer a
> regression).
>
> Ganeti can't currently be fixed since it's unbuildable. It's only due to an
> archive hiccup that it's even in Testing. I was planning on asking the
> Release Team to ignore it, so pyyaml can transition (worst case it's stuck
> until ganeti gets removed from Testing in a week and a half).
Ganeti's removal got delays, but
