Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Hi, upstream is aware of that. We must treat that library as a reference software for research purposes. I do not plan to invest time to make it better than upstream designed it. cheers, Serge
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Hi, I'll only mention that a viable alternative is to use libsodium in your projects which is API-compatible with libnacl and seems to work on all architectures [1]. Cheers, Tomasz [1] https://packages.qa.debian.org/libs/libsodium.html signature.asc Description: PGP signature
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Sorry for letting this slip off my radar for the best part of a year after uploading the "diagnostic upload". Here is a list of facts i've determined. 1: NACL contains some code for measuring times in CPU cycles, it is not clear to me how important a part of the whole package this is. 2: There are various CPU specific implementations of this code which work using various performance counters. 3: There are also generic implementations which work by measuring time in some unit other than CPU cycles and then measuring 4: The generic implementations need to have a CPU speed CPU speed, they determine this by looking at various files in /sys and /proc . Some kernel/hardware combinations have the CPU speed available in a place where NACL looks, others don't. My investigations didn't reveal any generic way of measuring CPU clockspeed on linux. 5: The build system chooses what implementation to use not by knowlage of what each debian port is supposed to support but by bruteforcing until one is found to build and work. 6: Some of the generic implementations fail to build not because they are incompatible with the system they are being built on but because they aren't being linked correctly by the build system. 7: mips is still failling to build with a timeout Now for some implications of these facts. Point 4 is the issue with the armel and armhf. I'm not sure of any good fixes for this one. The only thing I can propose is using bogomips as a psuedo CPU speed if the true CPU speed can't be read but I don't know how acceptable that would be for this package. IME on boards where none of the CPU speed determining methods used by the program currently work bogomips is very close to CPU clock. If you belive this is a sane way to go i'm happy to whip up a patch implementing it. Point 5 means that builds are unpredictable and the implementation chosen may depend on which buildd happens to build the package and may not work for all users. It seems wrong in much the same way that using -march=native is wrong. Point 6 means that on systems where we need to use the generic implementation we would end up with an inferior implementation using the non-monotonic clock. Point 7 needs more investigation if people want the package on mips but i'm an arm guy not a mips guy. In summary it's a horrible mess. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Sorry, I have not read your patch properly, now I can understand why have you removed cat $(CURDIR)/build/$(SHORTHOSTNAME)/log and I am withdrawing my objections. I am waiting for your decision if you want to upload your patch. Thanks a lot, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Thanks, let me know what is your decision, but IMHO it would be useful to leave cat $(CURDIR)/build/$(SHORTHOSTNAME)/log in place, though, as it is the only available method to read builders output. cheers, Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Hi, I am not able to fix the problem by myself, I have contacted the upstream and I have not received any deployable help. I noticed that that 20110221-3 did build on armhf (on an experimental buildd) while 20110221-4 failed to build on armhf (on an unstable buildd). 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -3: === Fri Feb 3 00:59:57 UTC 2012 === Trying gettimeofday.c with gcc -O3 -fomit-frame-pointer -funroll-loops... gettimeofday 10 1000139805 768 1024 1280 768 1024 1024 1024 1024 1024 1024 768 1024 1280 768 1024 0 1024 1024 1024 1024 1024 768 1024 1280 1024 768 1024 1024 1024 1024 1024 0 1024 768 1280 1024 768 1024 1024 1024 1024 1024 1024 768 1024 1280 1024 0 768 1024 1024 1024 1024 1024 1024 768 1280 1024 768 1024 1024 1280 768 1024 === Fri Feb 3 00:59:58 UTC 2012 === Success. Using gettimeofday.c. -4: === Mon Apr 9 01:42:11 UTC 2012 === Trying gettimeofday.c with gcc -O3 -fomit-frame-pointer -funroll-loops... cpucycles() = 0 === Mon Apr 9 01:42:13 UTC 2012 === Trying gettimeofday.c with gcc -O -fomit-frame-pointer... cpucycles() = 0 === Mon Apr 9 01:42:14 UTC 2012 === Trying gettimeofday.c with gcc -fomit-frame-pointer... cpucycles() = 0 = Giving up. In both cases before that it tries a variety of different variants. Some of them are clearly CPU family specific and fail with cpu family specific errors (even the "coretex" one fails with an illegal instruction error) but others look generic and fail with generic errors, most notablly failing to find clock_gettime. It seems the reason it fails to find clock_gettime is that clock_gettime needs librt to be linked. Unfortunately fixing that issue didn't fix things. It seems at even after fixing the linking issue those implementations just failed in the same way the gettimeofday one did. So then I started looking at the code and determined a couple of things 1: the code in gettimeofday.c calls the code in cpufreq.c which tries a variety of methods to retreive the CPU frequency 2: at least on my beagleboard xm the build succeeds if /sys is available but fails if it isn't. The armel, s390 and s390x builds seem to be failing in the same way as the armhf unstable build did. Which leaves the question of why knowing the CPU frequency is so vitally important (on a modern system you can never know it exactly anyway because it's not a constant) and whether it would be better to assume some hardcoded default rather than failing completely if the CPU frequency cannot be determined. It also leaves the question of whether packages can assume /sys will be mounted in the build environment or not. I intend to bring that up on debian-devel. As for the mips failure it simply seemed to be killed for inactivity. This seems to be the result of a screwy build process that does not echo anything to the console. The debian build process is setup to eventually echo the logs but it seems on mips the build timed out before reaching that point. I have created a patch which adds some tests for the status of /sys (both whether it is mounted and if so what exists) to aid in debugging and fixes the upstream build system to actually output it's progress to the console. I would expect this patch to fix the timeout on mips and shed some more light on the arm[el|hf] and s390(x) problems. Finally I removed some stray spaces from the end of a line in debian/rules. I may or may not NMU this patch in a few days time. Please take this post as notification of my intent to NMU. diff -Nru nacl-20110221/debian/changelog nacl-20110221/debian/changelog --- nacl-20110221/debian/changelog 2012-04-05 07:31:38.0 + +++ nacl-20110221/debian/changelog 2012-09-21 08:44:48.0 + @@ -1,3 +1,13 @@ +nacl (20110221-4.1) unstable; urgency=low + + * Modify the build system to echo stuff to standard output during the build +rather than only at the end. Hopefully this should prevent the timeout +on mips. + * Add some tests for the state of /sys before starting the build to help +debug failures related to being unable to determine CPU frequency + + -- Peter Michael Green Fri, 21 Sep 2012 08:43:21 + + nacl (20110221-4) unstable; urgency=low * Move to unstable. diff -Nru nacl-20110221/debian/patches/output-while-building nacl-20110221/debian/patches/output-while-building --- nacl-20110221/debian/patches/output-while-building 1970-01-01 00:00:00.0 + +++ nacl-20110221/debian/patches/output-while-building 2012-09-21 08:47:59.0 + @@ -0,0 +1,32 @@ +Description: output to standard output while building. + The upstream build system puts all output in a log file rather than to standard + output. This can cause build timeouts on slow architectures and if the build + truely hangs makes it difficult to determine where it hung. Modify the build + system to output to standard output as it goes along. + +Author: Peter Michael Green + +--- +The infor
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Hi, I am not able to fix the problem by myself, I have contacted the upstream and I have not received any deployable help. Unfortunately, I have no such machines on my horizon, so patches are more then welcome. Serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678123: armel, armhf, mips, s390 and s390x unsupported by Debian's libnacl-dev
Package: libnacl-dev Version: 20110221-4 This is ``just for the record'' since Sergiusz might already know about this issue. The source code of libnacl supports at least architectures such as arm and mips (see abiname.c in libnacl). However, the Debian package does not. If possible supporting those architectures in Debian too would be very nice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
