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

Groups > linux.debian.maint.python > #14522 > unrolled thread

pyyaml 6

Back to article view | Back to linux.debian.maint.python

Contents

  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

#14522 — pyyaml 6

pyyaml (aka python3-yaml) is an rdepend for >300 packages. We currently
have 5.4.1, but version 6 was released late last year, which does quite
a lot of cleanup (eg, dropping python 2 support) and disables unsafe
loading (arbitrary python code execution) unless explicitly opted into.

Unfortunately this is a breaking change for any code which uses the
simple `yaml.load(fileobj)` idiom - it now needs to be
`yaml.safe_load(fileobj)` or `yaml.load(fileobj, Loader=yaml.SafeLoader)`.

I uploaded 6.0 to experimental late last year, but time constraints
meant it never got pushed forward. I've recently refreshed the version
in experimental (experimental doesn't get binnmus so it was still only
built for 3.9), and there are relatively few autopkgtest regressions:
https://qa.debian.org/excuses.php?experimental=1&package=pyyaml

However, using codesearch suggests there are quite a few places which
are likely to break:
http://codesearch.debian.net/search?q=yaml%5B.%5Dload%5B%28%5D%5B%5E%2C%5D%2B%5B%29%5D+filetype%3Apython&literal=0&perpkg=1

Some of these are false positives, such as invocations of ruamel.yaml,
that string appearing in documentation, or things regex can't catch -
but that still looks like it leaves a significant number of packages
being potentially broken - and presumably lacking autopkgtest coverage).


So, I'd seek some input on how to move forward.

* 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?

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.


Gordon

[toc] | [next] | [standalone]

#14523

[Multipart message — attachments visible in raw view] — view raw

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.


Cheers
Timo

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#14527

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.


> 
> 
> Cheers
> Timo
> 

[toc] | [prev] | [next] | [standalone]

#14528

[Multipart message — attachments visible in raw view] — view raw

On 2022-10-09 21:39:56 +0200 (+0200), Gordon Ball wrote:
[...]
> gnocchi # confirm, in gnocchi/gendoc

Looks like it was fixed in gnocchi 4.4.2 earlier this year (unstable
still has 4.4.0).

> jeepyb # confirm, in cmd/notify_impact

I'm honestly surprised this is packaged for Debian, since it's just
a pile of random scripts and hacks we use in OpenDev for things like
Gerrit hooks, and that notify_impact tool has been unused for a long
time. I could easily fix the yaml.load() call upstream, but I'm
tempted to just go on a cleaning spree and remove a bunch of unused
stuff like that from the repository.

> refstack-client # confirm, in refstack_client

Fixed in 0.1.0 from February (unstable carries an unreleased
snapshot from last year).
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#14542

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.

[toc] | [prev] | [next] | [standalone]

#14592

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 <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.
> 

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.

[toc] | [prev] | [next] | [standalone]

#14596

On November 2, 2022 8:35:35 AM UTC, Gordon Ball <gordon@chronitis.net> 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 <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.
>> 
>
>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).

Scott K

[toc] | [prev] | [next] | [standalone]

#14619

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, November 2, 2022 5:26:35 AM EST Scott Kitterman wrote:
> On November 2, 2022 8:35:35 AM UTC, Gordon Ball <gordon@chronitis.net> 
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 <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.>
> >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 the Release Team hinted pyyaml to transition, 
so it should go to Testing now.

Scott K

[toc] | [prev] | [next] | [standalone]

#14524

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2022-10-07 at 00:10 +0200, Gordon Ball wrote:

> * Upload to unstable and see what breaks?

The experimental pseudo-excuses already say several packages break:

   https://qa.debian.org/excuses.php?experimental=1&package=pyyaml
   
   autopkgtest for ganeti/3.0.2-1: amd64: Regression, arm64: Regression
   autopkgtest for llvm-toolchain-13/1:13.0.1-7: amd64: Pass, arm64: Regression
   autopkgtest for satpy/0.37.1-1: amd64: Regression, arm64: Regression
   autopkgtest for spades/3.15.5+dfsg-1: amd64: Regression

So at least these issues need to be investigated and maybe bugs filed.

> * Request an archive rebuild with this version and see what breaks?

Definitely.

> * File bugs against all likely affected packages with a fixed date for
> an upload?

Definitely.

I don't know if any packages in Debian have versioned dependencies on
pyyaml, but if they do then it might be worth filing a transition bug.
Probably also a good idea to do that anyway too.

   https://wiki.debian.org/Teams/ReleaseTeam/Transitions

There might also be Debian services broken by pyyaml 6, but they can be
dealt with during the upgrade of the debian.org machines to bookworm.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#14529

[Multipart message — attachments visible in raw view] — view raw

On 2022-10-06 21 h 43, Paul Wise wrote:
> On Fri, 2022-10-07 at 00:10 +0200, Gordon Ball wrote:
> 
>> * Upload to unstable and see what breaks?
> 
> The experimental pseudo-excuses already say several packages break:
> 
>     https://qa.debian.org/excuses.php?experimental=1&package=pyyaml
>     
>     autopkgtest for ganeti/3.0.2-1: amd64: Regression, arm64: Regression
>     autopkgtest for llvm-toolchain-13/1:13.0.1-7: amd64: Pass, arm64: Regression
>     autopkgtest for satpy/0.37.1-1: amd64: Regression, arm64: Regression
>     autopkgtest for spades/3.15.5+dfsg-1: amd64: Regression
> 
> So at least these issues need to be investigated and maybe bugs filed.
> 
>> * Request an archive rebuild with this version and see what breaks?
> 
> Definitely.
> 
>> * File bugs against all likely affected packages with a fixed date for
>> an upload?
> 
> Definitely.

Shameless plug here, but if you do it in time for the DPT sprint 
(December 2-3-4), fixing packages that broke can even be an agenda item 
people can work on!

https://deb.li/2S8U

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#14525

[Multipart message — attachments visible in raw view] — view raw

On 2022-10-07 00:10:21 +0200 (+0200), Gordon Ball wrote:
[...]
> 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.

I have a feeling 5.4 would also work for the latest versions of
OpenStack Horizon. The change which increased the PyYAML minimum for
it to >=6.0 didn't really say why it picked that minimum, other than
for the sake of consistency:

https://review.opendev.org/834053

This can be tested upstream if folks think that would be a helpful
data point, but it's not entirely trivial since I'll have to do some
extra work to override the requirement constraints (otherwise I
would have just done it before replying).
-- 
Jeremy Stanley

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web