Date: Thu, 11 Aug 2022 06:55:50 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 265651] [NEW PORT] archivers/zpaqfranz: versioned/snapshot archive Message-ID: <bug-265651-7788-W9bFrPPJ5P@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265651-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-265651-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265651 --- 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=20=20=20=20 three+1 kinds of tests are missing, as I physically have no access to non-I= ntel machines to run them on=20=20 The first is related to "endianness", in particular for the additional hash= es and even more in particular for xxhash64 (the default one), but also all the other optional ones (less important, to be selectively disabled)=20=20=20=20 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)=20=20 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**=20=20 Case 1: The created files should be restorable on machines with different C= PUs, BUT without checking the stored hashes=20=20 Case 2: (BLAKE3) can prevent this algorithm from being used as a hash saved within files (the -blake3 optional switch)=20=20 Case 3: Files may not be restorable on machines with different CPUs=20=20 THEN I "stripped" from the proposed FreeBSD port the NOJIT support altogether, g= oing back to amd64=20=20=20=20 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 s= sh 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.=20=20 --- This is not some kind of "hello world" software, which "maybe" can work, bu= t, 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265651-7788-W9bFrPPJ5P>