[Bug 265651] [NEW PORT] archivers/zpaqfranz: versioned/snapshot archive

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 11 Aug 2022 06:55:50 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265651

--- Comment #18 from Franco Corbelli <franco@francocorbelli.com> ---
> Only restrict them if the software is *known* to be broken on some arch.

AFAIK there aren't "bugs"

BUT    
three+1 kinds of tests are missing, as I physically have no access to non-Intel
machines to run them on  

The first is related to "endianness", in particular for the additional hashes
and even more in particular for xxhash64 (the default one), but also all the
other optional ones (less important, to be selectively disabled)    

The second is about memory alignment, in particular of BLAKE3 (I have
implemented my own specific memory alignment function for run-time creation of
objects that works fine on Intel)

The third, linked to the first, is certify the compatibility of files (and the
hashes created) between machines with different endianness. Translation. If the
files created on the non-Intel machine contain the same data calculated by an
Intel machine (on the same original files)  

The fourth (+1) is checking the non-latin handling of filenames (aka: utf-8,
aka: russian, chinese etc) on internal routines.  I do not think there are
particular problems, but it is not sure (for example in the calculation of the
length of long strings)

**Worst scenarios**  
Case 1: The created files should be restorable on machines with different CPUs,
BUT without checking the stored hashes  
Case 2: (BLAKE3) can prevent this algorithm from being used as a hash saved
within files (the -blake3 optional switch)  
Case 3: Files may not be restorable on machines with different CPUs  

THEN
I "stripped" from the proposed FreeBSD port the NOJIT support altogether, going
back to amd64    

By FreeBSD policy you have to *know* that something is broken, but this goes
against MY policy, which can be read by writing zpaqfranz /?
---
Doveryay, no proveryay;  trust, but verify; fidarsi e' bene, non fidarsi e'
meglio.
---

Some kind of "non-intel" help is needed, it would be even better if I had ssh
access to a non-Intel FreeBSD machine to run my tests directly, but as
mentioned I don't know any non-Intel VPS to rent.  

---
This is not some kind of "hello world" software, which "maybe" can work, but,
if it doesn't, no big deal.

This is a very complex "piece", with some cutting-edge technologies inside,
that must be trusted (or at least, trusted as possible).

Certainly when someone use free software it is HIS problem whether it will work
or not: the moment you "run" something, you accept every risks

But I have a reputation that I intend to keep

I hope to have clearly explained MY policy

-- 
You are receiving this mail because:
You are the assignee for the bug.