Comments

26 Comments
karma

This kernel contains a known regression to mount behaviour. See https://lore.kernel.org/linux-fsdevel/CAOYeF9UzK=oHCH6UcLgx5g5a_pQhMbnpnwd90oxAjN7LrmDytA@mail.gmail.com/

karma

I verified that this release is generally functional and specifically that --experimental-transform-types is working correctly. Thanks!

We ended up changing our webserver implementation to be more RFC compliant. Strictly speaking, this is not a curl bug (although the error message could certainly be improved...).

More info here: https://github.com/cockpit-project/cockpit/pull/19927

I've done some additional research. It happens when the --head command-line option is used and the server returns a non-empty encoding with Transfer-Encoding: chunked. MDN says:

Warning: A response to a HEAD method should not have a body. If it has one anyway, that body must be ignored

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD

which suggests that the server is behaving in a way it should not, but the bug is with curl for not ignoring it. The MDN article links the RFC which says something else:

The HEAD method is identical to GET except that the server MUST NOT send content in the response.

https://www.rfc-editor.org/rfc/rfc9110#HEAD

.... so, our bug?

I managed to bisect it to this commit: https://github.com/curl/curl/commit/d7b6ce64ce0ad787ad2ed3ee05c94938a6b4f551 which is not included in that PR (which never got merged) but (indeed, curiously) tags it as Closed in the commit message.

User Icon lis commented & provided feedback on curl-8.6.0-1.fc40 a year ago
karma

This breaks two distinct things for us (Cockpit project):

  • this upstream change https://github.com/curl/curl/commit/07dd60c05b5f6b00ff7cc0d65c6b46cb1a6938a2 causes --unix to stop working. OK, fair enough. --unix was never a valid option (the correct spelling is --unix-socket) and the change here is that the "partial match" feature was removed. Easy enough for us to fix, but that's surely going to hit other people as well.
  • worse, though: there's a new "curl: (8) Failed reading the chunked-encoded stream" failure coming from our tests and it's not clear why. I've tried to reproduce this with various versions from upstream git, but have been unable to do so.
karma
  1. Use dbus-broker-34-1.fc39.

  2. Drop a broken symlink in ~/.local/share/dbus-1/services/org.example.service

  3. Logout and login to observe your session is completely broken.

  4. rpm-ostree override replace FEDORA-2023-e664d047ad (ie: this update)

  5. Reboot

  6. Everything working fine again.

karma

There's a new upstream release to address this issue: https://github.com/bus1/dbus-broker/releases/tag/v35

karma

This update hosed my system pretty badly due to the presence of a dangling symlink in my home directory. I filed https://github.com/bus1/dbus-broker/issues/328 upstream.

karma

Fixes fluidsynth -a pipewire (upstream issue https://github.com/FluidSynth/fluidsynth/pull/1230)

karma

No more QEMU DHCP fails with this one :) Thanks