This bug was fixed in the package xxhash - 0.8.1-1
---
xxhash (0.8.1-1) unstable; urgency=medium
* New maintainer. Closes: #1003524.
* debian/copyright: Update copyright holder years for debian/*.
* debian/control: Document Rules Requires Root as no.
* Update package to use
> ...so if a user has built against libxxhash for such
> a use case that is supported by upstream, your proposal
> for changing Focal would break them.
*shrug*
I'd rather have my build break now than succeed and get harder to debug
issues with failing cross device communication.
Well, I've done
Thank you for the further investigation.
It sounds like upstream broke ABI between libxxhash0 0.7 and libxxhash0
0.8 but did not bump the soname when they did so. Perhaps that's because
upstream still considers this experimental as it has a version < 1.0, or
perhaps that was a mistake. For a
** Description changed:
+ **NOTE: This ticket has been moved/altered. Original problem referred to
+ rsync behaviour with libxxhash0. New subject is the changed ABI of
+ libxxhash0.**
+
+ Original-Subject: rsync 3.2.x in Groovy depends on broken libxxhash
+ 0.7.x
+
+ Actual problem: libxxhash0
Thanks, Robie, for the excellent response.
> Actually I'm not sure it's a symbol versioning issue now.
Maybe this example can persuade you that there is a problem between
(lib)xxhash in Focal and in Groovy:
focal$ xxh128sum <(echo -n)
07fd4e968e916ae11f17545bce1061f1 /dev/fd/63
groovy$
Anyone who has an rsync that supports the xxh128 hash using the xxhash
0.7 library did something very bad in their build. An rsync compiled
with that library only supports xxh64 & xxh32. Thus, this described
mismatch never occurs in a stock rsync (the 128-bit hash was unstable in
xxhash 0.7, and
To be clear, if you have xxhash 0.7 and "rsync -V" reports xxh128 in the
checksum list, fix the rsync build by getting rid of any patch that
enabled that unsupported hash.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> So I'm going to reassign the bug to that package as it seems likely to
me that this is where the problem lies.
Actually I'm not sure it's a symbol versioning issue now. Looking at
your error, perhaps it's a protocol negotiation issue in rsync? Either
way, it needs further investigation by a
Sorry, the use cases you describe are not supported by Ubuntu.
You're welcome to hack your system as you wish, but that doesn't mean
that we will necessarily make changes in Ubuntu to accommodate that. We
do try to be helpful, of course. And in this case I agree that it is a
bug that rsync
How about this case:
- I make a hypothetical package that depends on libxxhash < 0.8 because
I want the "broken/old" xxh128 support;
- I have libxxhash 0.7.3 (that came with Focal);
- I have rsync 3.1.x (that came with Focal);
- Now I release-upgrade my system from Focal to Groovy;
- I get
Hello Walter,
Thanks for filling the bug and helping in making the Ubuntu server
better.
However, if I get everything right, I think you're mistaken about how it
works and I am sorry but what you're trying to do is not correct! You
cannot just decide to take one of the package from another
Hi Wayne! Thanks for commenting.
> It's only the 128-bit hash that depends on 0.8.0.
> The 0.7 version works fine with rsync, giving it
> the 64-bit and 32-bit hashes.
Yes. Except it seems that if you switch the libxxhash0 from 0.8 to 0.7,
you get different behaviour.
rsync doesn't check what
That said, of course, 0.8.0 is the better choice for the most possible
features (if it is available).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1934992
Title:
rsync 3.2.x in Groovy depends on
You misread my comments. It's only the 128-bit hash that depends on
0.8.0. The 0.7 version works fine with rsync, giving it the 64-bit and
32-bit hashes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
14 matches
Mail list logo
