Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #14542

Re: pyyaml 6

From Gordon Ball <gordon@chronitis.net>
Newsgroups linux.debian.maint.python
Subject Re: pyyaml 6
Date 2022-10-19 22:40 +0200
Message-ID <Fio13-fmra-1@gated-at.bofh.it> (permalink)
References <FdHxn-cwMm-1@gated-at.bofh.it> <FdIjL-cxg7-1@gated-at.bofh.it> <FeKtb-d9J5-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 09/10/2022 21:39, Gordon Ball wrote:
> On 07/10/2022 01:13, Timo Röhling wrote:
>> Hi Gordon,
>>
>> * Gordon Ball <gordon@chronitis.net> [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.

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

pyyaml 6 Gordon Ball <gordon@chronitis.net> - 2022-10-07 00:30 +0200
  Re: pyyaml 6 Timo Röhling <roehling@debian.org> - 2022-10-07 01:20 +0200
    Re: pyyaml 6 Gordon Ball <gordon@chronitis.net> - 2022-10-09 21:50 +0200
      Re: pyyaml 6 Jeremy Stanley <fungi@yuggoth.org> - 2022-10-09 22:00 +0200
      Re: pyyaml 6 Gordon Ball <gordon@chronitis.net> - 2022-10-19 22:40 +0200
        Re: pyyaml 6 Gordon Ball <gordon@chronitis.net> - 2022-11-02 09:50 +0100
          Re: pyyaml 6 Scott Kitterman <debian@kitterman.com> - 2022-11-02 10:30 +0100
            Re: pyyaml 6 Scott Kitterman <debian@kitterman.com> - 2022-11-13 03:30 +0100
  Re: pyyaml 6 Paul Wise <pabs@debian.org> - 2022-10-07 03:50 +0200
    Re: pyyaml 6 Louis-Philippe Véronneau <pollo@debian.org> - 2022-10-10 17:50 +0200
  Re: pyyaml 6 Jeremy Stanley <fungi@yuggoth.org> - 2022-10-07 16:50 +0200

csiph-web