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:

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

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.

.... so, our bug?

I managed to bisect it to this commit: 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 5 months ago

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

  • this upstream change 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.
  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.


There's a new upstream release to address this issue:


This update hosed my system pretty badly due to the presence of a dangling symlink in my home directory. I filed upstream.


Fixes fluidsynth -a pipewire (upstream issue


No more QEMU DHCP fails with this one :) Thanks


Very strong thumbs-down from me. Starting from a clean Fedora 34 install, and running the above dnf upgrade command results in my qemu-kvm VMs with usermode networking not able to get dhcp replies (and failing to configure their networking).

User Icon lis commented & provided feedback on fedora-repos-34-2 3 years ago

archive repo is present...

User Icon lis commented & provided feedback on samba-4.14.3-0.fc34 3 years ago

The upgrade is generally working, and the perl dependency is gone, but I can't follow the "desktop network smb" script because I keep getting messages about

$ smbtree -N
smbc_opendir: No such file or directory

and a very similar message from Nautilus when trying to browse the "Windows Network".

The ENOENT almost certainly refers to this problem, found with strace:

connect(8, {sa_family=AF_UNIX, sun_path="/run/samba/nmbd/unexpected"}, 110) = -1 ENOENT (No such file or directory)

and indeed, nmbd isn't running, and even appears not to be installed in Silverblue by default.

There seem to be some others complaining about that here:

I'm not sure if this should be considered a bug, but in any case, it's not a regression introduced by this update, so +1 overall.

BZ#1949295 Please drop or split out findsmb script
BZ#1951531 samba-4.14.3 is available

Me too.  canonical name =
Address: 2a04:4e42:1b::729

If I do a ping -6 followed by a ping -4 then the second one fails.

Wildly speculating: maybe the cache ends up with a result that only contains the v6 address, and when we try later to lookup the v4 address the cache replies "I know this address and it has no v4!" Or maybe it's something else entirely.