Dear Maintainer,

your package currently (Build-)Depends on fuse - that is fuse 2.x, it
being obsolete. A newer version of fuse, fuse3, is available since at
least buster.

Please migrate your package to the fuse3 library, which is actively
maintained. It would be great if we could remove fuse 2.x in the
forky development cycle.

If you cannot migrate yet, please at least update your Depends: line.
If you currently have:

please update that to:

This allows mount.fuse and fusermount to be provided by fuse3, which
is what the majority of new installs already have [1]. You should
still migrate from libfuse 2.x to libfuse 3.x later.

fuse upstream noted important differences in [2].

[1] compare https://qa.debian.org/popcon.php?package=fuse and
https://qa.debian.org/popcon.php?package=fuse3

[2] https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0

Hi,

I'm raising the severity of the fuse2 -> fuse3 migration bugs to
important. Later in the forky cycle I'll likely raise them once
more.

Please update your package to use fuse3 (incl. the library) and stop
(build-)depending on the old fuse v2.

Thanks,
Chris

I'm attaching a set of patches that I think includes a resolution of
this bug.

I've not yet done more than very basic testing but I'm expecting to
start running this in live from tomorrow backported to bookworm.

The patches are as follows:

fix-race.patch - supplied previously but acng is unusable without this.
fuse3-debian.patch - the changes to the debian directory to resolve this bug.
fuse3.patch - the changes to the source to resolve this bug.
deprecation-debian.patch -  fix to resolve a deprecation warning in the debian directory
deprecation.patch - fix to remove OpenSSL deprecation warnings plus extra runtime tests for SHA256 and SHA512 correctness
buildhelper.patch - trivial change to use cmake if available and generate compile-commands.json

I also spotted some deprecation warnings for ares but I'm not familiar
with that library so I couldn't quickly fix them. I might provide
patches later.

Tim.

I've now been running this for a few days with no issues.

acngfs I don't use. When I tested I could only make it work when it was
run in the foreground (with -f). However, I could only make the previous
version work in the foreground too.

Tim.

I applied all the patches including the race one and the issues with corruption are gone. No other instabilities to report.

Best regards
Paulo Neves

Hi Tim,
host of ci.debian.net, which appeared to me to be related to parallel
downloads of InRelease. Chris only took the fuse3.patch to fix bug
1084459 (the bug where this bug was cloned from) and now I'm wondering
if the race you fixed with fix-race.patch is more likely to occur after
the switch to fuse3. What happens if the race isn't fixed and two
requests for the same file come in?

What I'm seeing is a lot of failures with this error by apt:
503  Cannot allocate memory [IP: 127.0.0.1 3142]

Paul

* Paul Gevers <elbrus@debian.org> [260205 19:20]:

Per my understanding the fuse parts are unused by the acng serving
daemon. Maybe the loong64 runners are just more likely to hit the
races.

Chris

Hi, the fuse3 patch has nothing at all to do with the races. It's only
relevant for acngfs (which probably isn't worth keeping in the code TBH
but I thought a patch to update to fuse3 was more likely to be accepted.)

The data races are down to concurrent downloads. They result in a
corrupted file in acng's cache and the only fix is to delete the corrupt
file and try again. Release files update often enough that wait is also
an option, but a corrupted kernel deb, for example, will stay broken for
ages.

I don't know about memory errors, the common symptom is a hash sum
mismatch. But it's been so long now since I had an issue that I've
forgotten details of the posdible failures. From what I recall, the apt
failures when it happens vary, hangs forever, hash mismatch, 503 errors.

I could believe that acng could run out of memory as a result of this
but I can't say if it's an error I ever saw.

Tim.

This issue is no longer blocking the fuse transition.

Hi Paul,

I'm having very frequent issues with InRelease too, in my case the error
message is different though:

503  Connection closed, check DlMaxRetries [IP: 127.0.0.1 3142]

Relatedly, I see the following in /var/log/apt-cacher-ng/apt-cacher.err:

  Thu Aug 13 07:47:54 2026|Failure to move file /var/cache/apt-cacher-ng/uburep/dists/resolute/InRelease out of the way or cannot create /var/cache/apt-cacher-ng/uburep/dists/resolute/InRelease.1786607274 - errno: File exists
  Thu Aug 13 07:47:54 2026|Error creating file item for uburep/dists/resolute/InRelease -- check file permissions!

This is with apt-cacher-ng 3.7.5-1, hence before the fuse2 -> fuse3
changes.

HTH,
  ema