* Upload to unstable and see what breaks?Considering that PyYAML has been issuing a YAMLLoadWarning since
* 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?
* 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?
The only bug requesting it actually be upgraded is https://bugs.debian.org/1008262 (for openstack). I don't know if
that has proved a hard blocker - I _think_ anything designed to
work with 6.x should also work with 5.4.
gnocchi # confirm, in gnocchi/gendoc
jeepyb # confirm, in cmd/notify_impact
refstack-client # confirm, in refstack_client
Hi Gordon,
* Gordon Ball <gordon@chronitis.net> [2022-10-07 00:10]:
* Upload to unstable and see what breaks?Considering that PyYAML has been issuing a YAMLLoadWarning since
* 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?
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.
Cheers
Timo
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?Considering that PyYAML has been issuing a YAMLLoadWarning since
* 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?
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.
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?Considering that PyYAML has been issuing a YAMLLoadWarning since
* 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?
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.
already broken by other past changes.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?Considering that PyYAML has been issuing a YAMLLoadWarning since
* 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?
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
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.
On November 2, 2022 8:35:35 AM UTC, Gordon Ball <gordon@chronitis.net>wrote:
On 19/10/2022 22:30, Gordon Ball wrote: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).
On 09/10/2022 21:39, Gordon Ball wrote: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
On 07/10/2022 01:13, Timo Rhling 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.>
blocking migration.
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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 349 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 116:53:05 |
| Calls: | 7,612 |
| Files: | 12,786 |
| Messages: | 5,683,861 |