Skip to content

Conversation

@fw-bot
Copy link
Contributor

@fw-bot fw-bot commented Jul 28, 2025

Forward-Port-Of: #220640
Forward-Port-Of: #219270

@robodoo robodoo added forwardport This PR was created by @fw-bot conflict There was an error while creating this forward-port PR labels Jul 28, 2025
@robodoo
Copy link
Contributor

robodoo commented Jul 28, 2025

Pull request status dashboard

@fw-bot
Copy link
Contributor Author

fw-bot commented Jul 28, 2025

@xmo-odoo cherrypicking of pull request #219270 failed.

stdout:

Auto-merging odoo/addons/base/tests/test_expression.py
CONFLICT (content): Merge conflict in odoo/addons/base/tests/test_expression.py

Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?).

In the former case, you may want to edit this PR message as well.

⚠️ after resolving this conflict, you will need to merge it via @robodoo.

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

xmo-odoo added 5 commits July 29, 2025 07:51
`importlib.metadata.version` was made final (non-provisional) in
Python 3.10 which is the minver for odoo 18 so no need for a
conditional.
When 3.11 added PEP 657 fine-grained error locations, squiggles were
already possible[^1] but apparently we missed that in the cleanup
regex because those didn't show up in the messages we cared about.

With Python 3.13's improvements (sic...)[^2] this is not the case
anymore, and the tracebacks from testing the test suite do get a bunch
of squiggles which we need to learn to clean.

[^1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-pep657
[^2]: https://docs.python.org/3/whatsnew/3.13.html#improved-error-messages
Some libraries need to be bumped to be compatible with Python 3.13 (as
used in Trixie). In that case we update the requirements to the Trixie
version if possible, even if a lower version would be compatible with
3.13 itself.

- babel needs to be at least [2.11 to avoid usage of cgi][2] removed
  from 3.13
- freezegun needs to be [at least 1.5.0][3] to not call the
  now-removed `uuid._load_system_functions()`
- trixie ships gevent 24.11.1 and greenlet 3.1.0, but upstream [gevent
  24.11.1 requires greenlet 3.1.1][1] so basing the requirements off
  of trixie doesn't even install
- zeep needs to be [at least 4.3.0][4] to not use the `cgi` module

[1]: https://github.com/gevent/gevent/blob/24.11.1/setup.py#L200-L214
[2]: https://babel.pocoo.org/en/latest/changelog.html#version-2-11-0
[3]: spulec/freezegun#534
[4]: mvantellingen/python-zeep#1364
Need to accept and forward size parameters in `addBlankPage`, used
by a test for some reason.
@xmo-odoo xmo-odoo force-pushed the saas-18.4-17.0-trixie-compat-xmo-452831-fw branch from 15ab2d9 to b2e8335 Compare July 29, 2025 05:55
@C3POdoo C3POdoo requested review from a team, Julien00859, kmagusiak and ryv-odoo and removed request for a team July 29, 2025 05:58
In that case Werkzeug 3.0.4 and later will drop the entire
name (following pallets/werkzeug#2939, cf pallets/werkzeug#3032),
we'll end up with a field named `None` on the python side, and then
dispatching will blow up because `None` is not a valid kwarg.

The exact semantics of that case are unclear (see also
curl/curl#7789), my reading is that [RFC 7578][1] specifies
percent-encoding and thus that should be used when encoding and
decoding, and `\` should be irrelevant because it's neither `%` nor
`"` so it's not a metacharacter for multipart/form-data headers.

However the [whatwg living standard][2] rejects full blown
percent-encoding, and instead uses percent-encoding on just a highly
restricted set of inputs (which includes neither `\` nor `%`).

And while it seems like we should be able to ignore RFC 6266 (the
content-disposition header) who's to say that there are no real-world
deployments which follow its strictures?

Meh.

[1]: https://datatracker.ietf.org/doc/html/rfc7578#section-2
[2]: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data
@xmo-odoo xmo-odoo force-pushed the saas-18.4-17.0-trixie-compat-xmo-452831-fw branch from 92ed0bd to 3de825a Compare July 29, 2025 09:53
@xmo-odoo
Copy link
Collaborator

@robodoo r+

robodoo pushed a commit that referenced this pull request Jul 30, 2025
robodoo pushed a commit that referenced this pull request Jul 30, 2025
`importlib.metadata.version` was made final (non-provisional) in
Python 3.10 which is the minver for odoo 18 so no need for a
conditional.

Part-of: #220858
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <[email protected]>
robodoo pushed a commit that referenced this pull request Jul 30, 2025
When 3.11 added PEP 657 fine-grained error locations, squiggles were
already possible[^1] but apparently we missed that in the cleanup
regex because those didn't show up in the messages we cared about.

With Python 3.13's improvements (sic...)[^2] this is not the case
anymore, and the tracebacks from testing the test suite do get a bunch
of squiggles which we need to learn to clean.

[^1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-pep657
[^2]: https://docs.python.org/3/whatsnew/3.13.html#improved-error-messages

Part-of: #220858
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <[email protected]>
robodoo pushed a commit that referenced this pull request Jul 30, 2025
Some libraries need to be bumped to be compatible with Python 3.13 (as
used in Trixie). In that case we update the requirements to the Trixie
version if possible, even if a lower version would be compatible with
3.13 itself.

- babel needs to be at least [2.11 to avoid usage of cgi][2] removed
  from 3.13
- freezegun needs to be [at least 1.5.0][3] to not call the
  now-removed `uuid._load_system_functions()`
- trixie ships gevent 24.11.1 and greenlet 3.1.0, but upstream [gevent
  24.11.1 requires greenlet 3.1.1][1] so basing the requirements off
  of trixie doesn't even install
- zeep needs to be [at least 4.3.0][4] to not use the `cgi` module

[1]: https://github.com/gevent/gevent/blob/24.11.1/setup.py#L200-L214
[2]: https://babel.pocoo.org/en/latest/changelog.html#version-2-11-0
[3]: spulec/freezegun#534
[4]: mvantellingen/python-zeep#1364

Part-of: #220858
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <[email protected]>
robodoo pushed a commit that referenced this pull request Jul 30, 2025
Need to accept and forward size parameters in `addBlankPage`, used
by a test for some reason.

Part-of: #220858
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <[email protected]>
robodoo pushed a commit that referenced this pull request Jul 30, 2025
In that case Werkzeug 3.0.4 and later will drop the entire
name (following pallets/werkzeug#2939, cf pallets/werkzeug#3032),
we'll end up with a field named `None` on the python side, and then
dispatching will blow up because `None` is not a valid kwarg.

The exact semantics of that case are unclear (see also
curl/curl#7789), my reading is that [RFC 7578][1] specifies
percent-encoding and thus that should be used when encoding and
decoding, and `\` should be irrelevant because it's neither `%` nor
`"` so it's not a metacharacter for multipart/form-data headers.

However the [whatwg living standard][2] rejects full blown
percent-encoding, and instead uses percent-encoding on just a highly
restricted set of inputs (which includes neither `\` nor `%`).

And while it seems like we should be able to ignore RFC 6266 (the
content-disposition header) who's to say that there are no real-world
deployments which follow its strictures?

Meh.

[1]: https://datatracker.ietf.org/doc/html/rfc7578#section-2
[2]: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data

Part-of: #220858
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <[email protected]>
robodoo added a commit that referenced this pull request Jul 30, 2025
closes #220858

Forward-port-of: #220640
Forward-port-of: #219270
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <[email protected]>
@robodoo robodoo closed this Jul 30, 2025
robodoo added a commit that referenced this pull request Aug 4, 2025
closes #221165

Forward-port-of: #220858
Forward-port-of: #219270
Related: odoo/enterprise#91325
Signed-off-by: Xavier Morel (xmo) <[email protected]>
@fw-bot fw-bot deleted the saas-18.4-17.0-trixie-compat-xmo-452831-fw branch August 6, 2025 08:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

conflict There was an error while creating this forward-port PR forwardport This PR was created by @fw-bot

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants