Bug#1051650: cmake: Problems finding libraries on Alpha

[Michael Cree]

I have tried the suggested script (with a small modification to count
number of failures) running for a few hours on one of the packages
that had failed on the buildd and never saw cmake fail.

But then building a few packages locally with sbuild, apbs failed
first time to build with the cmake failure.  Second try at building
apbs with sbuild succeeded.

So it appears that there is something different about running in sbuild
(or possibly under dpkg-buildpackage) that is triggering this failure
on occassion.

Cheers,
Michael.

Bug#1051900: ohcount: aborts with segfaul or bus error 90% of the time on arm64

[Michael Cree]

Tags: patch

Further to my prior report it is not the use of variable length array
but the overwriting the end of the array that is the problem. This bug
is repeated multiple times throughout the source file src/detector.c.
It appears that there have been attempts to fix a couple of
occurrences of the bug but even that has been cocked up. There does
not seem to be any understanding by the authors of the code that
strlen() returns the length of a string less the terminating zero.

It is astonishing that this code successfully runs on any architecture
whatsoever given the multiple array overruns!

I attach a patch that fixes many occurrences of the bug.  This is
sufficient to get ohcount running on itself on arm64 without crashing.

There are also occurrences of array underruns in the code. For example,
about line 615 of src/detector.c there is the following:

p = line;
while (p < eol) {
  if (islower(*p) && p != bof && !isalnum(*(p - 1)) && *(p - 1) != '_') {

On the first iteration of the while loop in the if statement one byte
before the start of array line can be read.  That is undefined
behaviour.  I have not fixed this in the attached patch, but it should
be reported upstream.  Frankly, the code needs a full audit for issues
such as these.

Regards,
Michael.
--- a/src/detector.c
+++ b/src/detector.c
@@ -46,7 +46,7 @@
   while (isalnum(*pe)) pe++;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[79] = '\0';
   struct LanguageMap *rl = ohcount_hash_language_from_name(buf, length);
   if (rl) return(rl->name);
 }
@@ -63,7 +63,7 @@
 } while (*p == '-'); // Skip over any switches.
 length = pe - p;
 strncpy(buf, p, length);
-buf[length] = '\0';
+buf[79] = '\0';
 struct LanguageMap *rl = ohcount_hash_language_from_name(buf, length);
 if (rl) return(rl->name);
   } else if (strstr(line, "xml")) return(LANG_XML);
@@ -146,7 +146,7 @@
 while (pe < eof) {
   // Get the contents of the first line.
   while (pe < eof && *pe != '\r' && *pe != '\n') pe++;
-  length = (pe - p <= sizeof(line)) ? pe - p : sizeof(line);
+  length = (pe - p <= sizeof(line)-1) ? pe - p : sizeof(line)-1;
   strncpy(line, p, length);
   line[length] = '\0';
   if (*line == '#' && *(line + 1) == '!') {
@@ -166,7 +166,7 @@
   }
   pe = p;
   while (!isspace(*pe) && *pe != ';' && pe != strstr(pe, "-*-")) pe++;
-  length = (pe - p <= sizeof(buf)) ? pe - p : sizeof(buf);
+  length = (pe - p <= sizeof(buf)-1) ? pe - p : sizeof(buf)-1;
   strncpy(buf, p, length);
   buf[length] = '\0';
 
@@ -236,7 +236,7 @@
 if (p && pe) {
   p += 3;
   const int length = pe - p;
-  char buf[length];
+  char buf[length+1];
   strncpy(buf, p, length);
   buf[length] = '\0';
   char *eol = buf + strlen(buf);
@@ -550,7 +550,7 @@
   // If the directory contains a matching *.m file, likely Objective C.
   length = strlen(sourcefile->filename);
   if (strcmp(sourcefile->ext, "h") == 0) {
-char path[length];
+char path[length+1];
 strncpy(path, sourcefile->filename, length);
 path[length] = '\0';
 *(path + length - 1) = 'm';
@@ -572,7 +572,7 @@
   while (pe < eof) {
 // Get a line at a time.
 while (pe < eof && *pe != '\r' && *pe != '\n') pe++;
-length = (pe - p <= sizeof(line)) ? pe - p : sizeof(line);
+length = (pe - p <= sizeof(line)-1) ? pe - p : sizeof(line)-1;
 strncpy(line, p, length);
 line[length] = '\0';
 char *eol = line + strlen(line);
@@ -594,7 +594,7 @@
   while (pe < eol && *pe != '>' && *pe != '"') pe++;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   if (ohcount_hash_is_cppheader(buf, length))
 return LANG_CPP;
   // Is the extension for the header file a C++ file?
@@ -602,7 +602,7 @@
   while (p > line && *(p - 1) != '.') p--;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   struct ExtensionMap *re = ohcount_hash_language_from_ext(buf, length);
   if (re && strcmp(re->value, LANG_CPP) == 0)
 return LANG_CPP;
@@ -619,7 +619,7 @@
 if (!isalnum(*pe) && *pe != '_') {
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   if (strcmp(buf, "class") == 0 ||
   strcmp(buf, "namespace") == 0 ||
   strcmp(buf, "template") == 0 ||
@@ -650,7 +650,7 @@
   if (strstr(p, ".") <= pe) {
 // Only if the filename has an extension prior to the .in
 length = pe - p;
-char buf[length];
+char buf[length+1];
 strncpy(buf, p, length);
 buf[length] = '\0';
 p = ohcount_sourcefile_get_contents(sourcefile);
@@ -741,7 +741,7 @@
   while (pe < eof) {
 // Get a line at a time.
 while 

Bug#1051900: ohcount: aborts with segfaul or bus error 90% of the time on arm64

[Michael Cree]

On Wed, Sep 13, 2023 at 06:52:08PM -0300, Antonio Terceiro wrote:
> ohcount segfaults (and sometimes aborts with a Bus error) on arm64,
> almost 90% of the time. I tried this on an up to date arm64 Debian

Running ohcount under gdb traps on the segfault but can't get a
backtrace due to a corrupted stack.  So I recompiled ohcount with
the address sanitiser which traps on the segfault with the following:

=
==14540==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 
0xeab309b4 at pc 0xacf8bd38 bp 0xeab30960 sp 0xeab30978
WRITE of size 1 at 0xeab309b4 thread T0
#0 0xacf8bd34 in disambiguate_aspx src/detector.c:241
#1 0xacf8ba80 in ohcount_detect_language src/detector.c:221
#2 0xacf87304 in ohcount_sourcefile_get_language src/sourcefile.c:128
#3 0xad1fb5d0 in ohcount_parse src/parser.c:16
#4 0xacf879cc in ohcount_sourcefile_parse src/sourcefile.c:195
#5 0xacf87be0 in ohcount_sourcefile_get_loc_list src/sourcefile.c:239
#6 0xacf88f48 in ohcount_sourcefile_list_analyze_languages 
src/sourcefile.c:404
#7 0xacf8582c in summary src/ohcount.c:210
#8 0xacf86394 in main src/ohcount.c:302
#9 0xa95f777c in __libc_start_call_main 
../sysdeps/nptl/libc_start_call_main.h:58
#10 0xa95f7854 in __libc_start_main_impl ../csu/libc-start.c:360
#11 0xacf840ac in _start 
(/home/mjc/debian/ohcount/ohcount-4.0.0/bin/ohcount+0x240ac)

Address 0xeab309b4 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow src/detector.c:241 in 
disambiguate_aspx
Shadow bytes around the buggy address:
  0x200ffd5660e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd5660f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x200ffd566130: ca ca ca ca 00 00[04]cb cb cb cb cb 00 00 00 00
  0x200ffd566140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566170: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
  0x200ffd566180: 00 00 01 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==14540==ABORTING

The code for disambiguate_aspx() where the segfaults occurs is:


const char *disambiguate_aspx(SourceFile *sourcefile) {
  char *p = ohcount_sourcefile_get_contents(sourcefile);
  char *eof = p + ohcount_sourcefile_get_contents_size(sourcefile);
  for (; p < eof; p++) {
// /<%@\s*Page[^>]+Language="VB"[^>]+%>/
p = strstr(p, "<%@");
if (!p)
break;
char *pe = strstr(p, "%>");
if (p && pe) {
  p += 3;
  const int length = pe - p;
  char buf[length];
  strncpy(buf, p, length);
  buf[length] = '\0';
  char *eol = buf + strlen(buf);
  for (p = buf; p < eol; p++) *p = tolower(*p);
  p = buf;
  while (*p == ' ' || *p == '\t') p++;
  if (strncmp(p, "page", 4) == 0) {
p += 4;
if (strstr(p, "language=\"vb\""))
  return LANG_VB_ASPX;
  }
}
  }
  return LANG_CS_ASPX;
}


Line 241 is the line with: buf[length] = '\0';

We see that buf is declared two lines above as a variable length
array. Being a local variable I assume that it is allocated on the
stack, which is dangerous if its length turns out to be too large
for the stack. Presumably that is the problem.

Cheers,
Michael.

Bug#1051128: pipewire FTBFS on alpha; failure in test suite due to sigfpe

[Michael Cree]

On Fri, Sep 08, 2023 at 11:24:47AM +0200, Dylan Aïssi wrote:
> Le dim. 3 sept. 2023 à 10:45, Michael Cree  a écrit :
> > pipewire FTBFS on Alpha due to test suite failure. From the build
> > log [1]:
> 
> Upstream has pushed two commits to fix the build on alpha:
> - 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/805fbd0b34772fbc4d16bb94317706f2c17cdb59
> - 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/632f532036d3c69ce0aba89a85dbc3a94af7ad0a
> 
> As I don't have access to an alpha machine, can you test to build pipewire
> with these commits?

Tested on alpha.  Yes, with those commits pipewire successfully
builds.

Cheers,
Michael.

Bug#1051128: pipewire FTBFS on alpha; failure in test suite due to sigfpe

[Michael Cree]

Source: pipewire
Version: 0.3.79-1
Severity: important
Reason: fails to build from source but built in the past
User: debian-al...@lists.debian.org
Usertags: ftbfs

pipewire FTBFS on Alpha due to test suite failure. From the build
log [1]:

 8/22 test-resample   FAIL0.19s   killed by signal 8 SIGFPE

Re-running the test under gdb reveals the failure is in:
(gdb) bt
#0  0x020001002b14 in inner_product_c (n_taps=, 
taps=0x2000102e300, s=0x11fcfbb54, d=0x11fcf9cf0)
at ../spa/plugins/audioconvert/resample-native-c.c:13
#1  do_resample_full_c (r=0x11fcfd000, src=, ioffs=0, 
in_len=0x11fcf8eb4, dst=, ooffs=34, 
out_len=0x11fcfcf80) at ../spa/plugins/audioconvert/resample-native-c.c:44
#2  0x020001001cb4 in impl_native_process (r=0x11fcfd000, src=0x11fcfcf78, 
in_len=0x11fcfcf84, dst=0x11fcfcf70, 
out_len=0x11fcfcf80) at ../spa/plugins/audioconvert/resample-native.c:238
#3  0x02000100157c in pull_blocks (r=0x11fcfd000, first=, 
size=1024)
at ../spa/plugins/audioconvert/test-resample.c:89
#4  0x020001000ec8 in test_in_len () at 
../spa/plugins/audioconvert/test-resample.c:123
#5  main (argc=, argv=) at 
../spa/plugins/audioconvert/test-resample.c:154

And disassembling at the failure point reveals:

   0x020001002b10 <+336>:   muls$f14,$f11,$f13
=> 0x020001002b14 <+340>:   sextl   t0,t0

i.e. it is multiplying two single precision floating-point values
together (the location of the failure can be an instruction or
two out due to superscalar execution in the pipeline; it will be
the muls instruction that caused the fault):

f115.2433191122247536e-09 (raw 0x3e3685172000)
f141.6132473000813483e-310 (raw 0x1db28000)

and we see that f14 is a denormalised floating point number. (The
interpretation by gdb that it is 1.613...e-310 is wrong in that gdb
has assumed incorrectly that it is a double precision number for
printing the value.)

The relevant module was compiled with -ffast-math.  The relevant line
in the build log [1] is:

[89/965] cc -Ispa/plugins/audioconvert/libaudioconvert_c.a.p 
-Ispa/plugins/audioconvert -I../spa/plugins/audioconvert -Ispa/include 
-I../spa/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall 
-Winvalid-pch -Wextra -Wpedantic -std=gnu11 -fvisibility=hidden 
-fno-strict-aliasing -Werror=suggest-attribute=format -Wsign-compare 
-Wpointer-arith -Wpointer-sign -Wformat -Wformat-security 
-Wimplicit-fallthrough -Wmissing-braces -Wtype-limits -Wvariadic-macros 
-Wmaybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter 
-Wno-pedantic -Wdeprecated-declarations -Wunused-result -Werror=return-type 
-D_GNU_SOURCE -DFASTPATH -Werror=implicit-function-declaration 
-Werror=int-conversion -Werror=old-style-declaration 
-Werror=old-style-definition -Werror=missing-parameter-type 
-Werror=strict-prototypes -g -O2 -ffile-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Ofast -ffast-math -MD -MQ 
spa/plugins/audioconvert/libaudioconvert_c.a.p/resample-native-c.c.o -MF 
spa/plugins/audioconvert/libaudioconvert_c.a.p/resample-native-c.c.o.d -o 
spa/plugins/audioconvert/libaudioconvert_c.a.p/resample-native-c.c.o -c 
../spa/plugins/audioconvert/resample-native-c.c

But according to the gcc manual:

   This option is not turned on by any -O option besides
   -Ofast since it can result in incorrect output for programs
   that depend on an exact implementation of IEEE or ISO
   rules/specifications for math functions. It may, however,
   yield faster code for programs that do not require the
   guarantees of these specifications.

That's the problem.  The use of -ffast-math "can result in incorrect
output" if "depend on an exact implementation of IEEE" and on Alpha
-ffast-math turns off IEEE support for infinities, NaNs and
denormalised numbers, and the use of any of these results in a
SIGFPE signal being raised.

One wonders why pipewire would even need support for denormalised
numbers given that audio has a much more limited range of values!
Maybe the test suite is testing something that will never occur
in practice, in which case this test should be modified not to
include denormalised numbers.  Or, if there is a good reason to
expect denormalised numbers to be possible then this module should
not be compiled with -ffast-math on Alpha. (Or the input should be
tested and any denormalised numbers set to zero before any further
processing occurs.)

Cheers,
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pipewire=alpha=0.3.79-1=1693346040=0

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[Michael Cree]

On Wed, May 17, 2023 at 11:27:43AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Michael!
> 
> On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > > After a long discussion on IRC and the mailing list, we have agreed to 
> > > raise the
> > > baseline for the alpha architecture to EV56 to improve the generated code 
> > > and fix
> > > a number of issues. The change is already being implemented in the glibc 
> > > packages
> > > which switches to EV56 [1] since hwcaps are no longer available with 
> > > glibc 2.37 [2].
> > > 
> > > Could you raise the baseline for gcc on alpha to EV56?
> > > 
> > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
> > 
> > Yes, please!
> > 
> > I suggest the following in debian/rules2:
> > 
> > ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
> >   CONFARGS += --with-cpu=ev56 --with-tune=ev6
> > endif
> > 
> > (the --with-tune only affects instruction scheduling and better tunes
> > code for ev6 and more recent machines, but allows execution down to
> > ev56.)  I have tested this in the past with a rebuild of most packages
> > that are in the base essential chroot in the past and it works well.
> 
> Doesn't that come with a speed penalty for EV56 machines? I'm asking because 
> EV56 is
> currently the baseline for QEMU when emulating Alpha.

I was under the impression that qemu was ev6/ev67 being machine type
clipper which emulates an ES40.  Am I mistaken?

With regards instruction scheduling EV56 is in-order two-instructions
[1] executed per cycle.  EV6 and EV67 are out-of-order [2]
four-instructions executed per cycle. Hence, for ev6/ev67 it can be
advantageous to bring forward instructions that are data (operand)
ready and delaying by four cpu-instructions those that depend on a
result of a previous instruction instead of placing them immediately
after the previous instruction to guarantee they don't waste an
instruction slot in the same cpu cycle. [3]

The deleterious impact on ev56 of doing this will be very small to
utterly negligible.  It is not worth worrying about.

Regards,
Michael.

[1] Here I am talking about most integer register/register operate
instructions.  Memory, integer multiply and floating-point instructions
have longer latencies.

[2] Note that out-of-order does not mean the cpu can bring forward
data ready instructions that have not yet been seen in the instruction
pipeline.  That is why we ask the compiler to place them earlier.

[3] Even more advantageous on ev6/ev67 is to loop unroll and evaluate
two iterations of the loop in parallel, i.e., intertwine the two
computational pathways.  When I did tests some time ago with gcc (4.6
and earlier versions) the compiler did not do this well, whereas my
manually optimised machine code was getting better than three
instructions executed per cpu cyle on certain code.

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[Michael Cree]

On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> After a long discussion on IRC and the mailing list, we have agreed to raise 
> the
> baseline for the alpha architecture to EV56 to improve the generated code and 
> fix
> a number of issues. The change is already being implemented in the glibc 
> packages
> which switches to EV56 [1] since hwcaps are no longer available with glibc 
> 2.37 [2].
> 
> Could you raise the baseline for gcc on alpha to EV56?
> 
> I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".

Yes, please!

I suggest the following in debian/rules2:

ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
  CONFARGS += --with-cpu=ev56 --with-tune=ev6
endif

(the --with-tune only affects instruction scheduling and better tunes
code for ev6 and more recent machines, but allows execution down to
ev56.)  I have tested this in the past with a rebuild of most packages
that are in the base essential chroot in the past and it works well.

Regards,
Michael.

Bug#1024040: mariadb-10.6: FTBFS on alpha: relocation truncated to fit: GPREL16 against symbol `wsrep_debug'

[Michael Cree]

On Sun, Feb 05, 2023 at 03:35:39PM -0800, Otto Kekäläinen wrote:
> I applied the suggested fix now in
> https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/9e7ac5852d8a0ab96e25c4dd38dbc88354ee1c9e
> and it will be included in next upload. There are so many build
> failures that I don't have time to test each of them. If you have time
> to help, please test this on alpha, 

Yes, I tested a few days ago, and the patch fixes the link error, and
mariadb builds but ultimately failed in the test suite with:

Too many failed: Failed 19/386 tests, 95.08% were successful.

My recollection is that when I first reported this at version 10.6.7-3
only a couple of the tests failed, and were easily worked around, so it
would seem something further has gone wrong in the meantime.  But it
might have been a problem in the host system which had a full system
disk at the time, so I will rerun the test build as it could be quite
some time before the Alpha buildds pick up mariadb for building again
due to the backlog.

Cheers
Michael.

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Michael Cree]

On Thu, Feb 02, 2023 at 12:58:50PM +0400, Dmitry Shachnev wrote:
> Hi Michael!
> 
> On Thu, Feb 02, 2023 at 09:00:07PM +1300, Michael Cree wrote:
> > On Wed, Feb 01, 2023 at 09:13:09AM -0300, Lisandro Damián Nicanor Pérez 
> > Meyer wrote:
> > > It's from Thiago MAciera, qtbase's maintainer. The text says:
> > > 
> > > "Can I ask for a screenshot of a KDE or Qt-based application running on 
> > > Alpha 
> > > as proof that someone is actually using this?"
> > > 
> > > Can you provide us that? That will definitely help us a lot.
> >
> > Like the attached which shows okular running on an Alpha running
> > largely up-to-date Debian unstable?
> 
> This is perfect, thanks a lot!
> 
> Do you have a Qt gerrit account? Or I can forward your screenshot?

You may forward the screenshot.

Regards
Michael.

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Michael Cree]

On Sat, Jan 28, 2023 at 01:55:00PM -0300, Lisandro Damian Nicanor Perez Meyer 
wrote:
> On viernes, 9 de diciembre de 2022 22:19:16 -03 Michael Cree wrote:
> > Source: qt6-base
> > Version: 6.3.1+dfsg-10
> > Severity: important
> > Tags: patch ftbfs
> > Justification: fails to build from source (but built successfully in the
> > past)
> > 
> > The build fails with:
> > /<>/src/corelib/plugin/qelfparser_p.cpp:178:4: error: #error
> > "Unknown Q_PROCESSOR_xxx macro, please update."
> > 
> > Full log at:
> > https://buildd.debian.org/status/fetch.php?pkg=qt6-base=alpha=6.3.1
> > %2Bdfsg-10=1664652510=0
> > 
> > Attached is patch to provide the Q_PROCESSOR defines for Alpha.  With
> > that qt6-base builds successfully.
> 
> This really sounds like a patch that should go upstream. Normally such patchs 
> would need to be sent by the creator. Would you mind doing that? Please ping 
> me if you need help here.

There is already a patch upstream at:
https://codereview.qt-project.org/c/qt/qtbase/+/437349

I have taken that and refreshed against Debian 6.4.2+dfsg-1 and
attach here.

With that qt6-base 6.4.2+dfsg-1 builds to completion on Alpha.

Regards,
Michael.
Index: qt6-base-6.4.2+dfsg~rc1/src/corelib/global/qprocessordetection.h
===
--- qt6-base-6.4.2+dfsg~rc1.orig/src/corelib/global/qprocessordetection.h	2023-01-31 21:33:53.0 +1300
+++ qt6-base-6.4.2+dfsg~rc1/src/corelib/global/qprocessordetection.h	2023-01-31 21:34:47.220042095 +1300
@@ -48,8 +48,8 @@
 
 Alpha is bi-endian, use endianness auto-detection implemented below.
 */
-// #elif defined(__alpha__) || defined(_M_ALPHA)
-// #  define Q_PROCESSOR_ALPHA
+#if defined(__alpha__) || defined(_M_ALPHA)
+#  define Q_PROCESSOR_ALPHA
 // Q_BYTE_ORDER not defined, use endianness auto-detection
 
 /*
@@ -58,7 +58,7 @@
 ARM is bi-endian, detect using __ARMEL__ or __ARMEB__, falling back to
 auto-detection implemented below.
 */
-#if defined(__arm__) || defined(__TARGET_ARCH_ARM) || defined(_M_ARM) || defined(_M_ARM64) || defined(__aarch64__) || defined(__ARM64__)
+#elif defined(__arm__) || defined(__TARGET_ARCH_ARM) || defined(_M_ARM) || defined(_M_ARM64) || defined(__aarch64__) || defined(__ARM64__)
 #  if defined(__aarch64__) || defined(__ARM64__) || defined(_M_ARM64)
 #define Q_PROCESSOR_ARM_64
 #define Q_PROCESSOR_WORDSIZE 8
Index: qt6-base-6.4.2+dfsg~rc1/src/corelib/plugin/qelfparser_p.cpp
===
--- qt6-base-6.4.2+dfsg~rc1.orig/src/corelib/plugin/qelfparser_p.cpp	2023-01-31 21:33:53.0 +1300
+++ qt6-base-6.4.2+dfsg~rc1/src/corelib/plugin/qelfparser_p.cpp	2023-01-31 21:34:47.221018875 +1300
@@ -112,6 +112,8 @@
 static const Elf32_Half ExpectedMachine =
 #if 0
 // nothing
+#elif defined(Q_PROCESSOR_ALPHA)
+EM_ALPHA
 #elif defined(Q_PROCESSOR_ARM_32)
 EM_ARM
 #elif defined(Q_PROCESSOR_ARM_64)
@@ -380,6 +382,7 @@
 switch (r.machine) {
 // list definitely not exhaustive!
 case EM_NONE:   d << ", no machine"; break;
+case EM_ALPHA:  d << ", Alpha"; break;
 case EM_68K:d << ", MC68000"; break;
 case EM_ARM:d << ", ARM"; break;
 case EM_AARCH64:d << ", AArch64"; break;

Bug#1029383: usrmerge fails to make arch specific directory in copy

[Michael Cree]

Package: usrmerge
Version: 35
Severity: normal

Dear Maintainer,

On upgrading Alpha system with the package libc6.1-alphaev67 installed
when installing usrmerge the following occurred:

Setting up usrmerge (35) ...
cp: cannot create regular file '/usr/lib/alpha-linux-gnu/ev67/libc.so.6.1': No 
such file or directory

FATAL ERROR:
cp --no-dereference --preserve=all --reflink=auto --sparse=always 
/lib/alpha-linux-gnu/ev67/libc.so.6.1 
/usr/lib/alpha-linux-gnu/ev67/libc.so.6.1: rc=1

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 usrmerge


On examining the directory /usr/lib/alpha-linux-gnu/ I see ev4 and ev5
directories but no ev67 directory.  Presumably the copy of the ev67
tuned libc6.1 library failed because the target directory did not exist.

I manually made the ev67 directory in /usr/lib/alpha-linux-gnu/ and
reran the usrmerge installation and it then completed successfully.

Regards,
Michael.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: alpha

Kernel: Linux 5.8.18-titan-p1+ (SMP w/2 CPU threads)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS

[Michael Cree]

> I suspect this might be better worked around with -Wl,-no-relax on the
> linking only rather than disabling compiler optimisations.  I intend to
> run a test of that today.

Nice idea, but, it didn't solve the linker errors.  Stick with reducing
compiler optimisation to -O1.

Cheers
Michael.

Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS

[Michael Cree]

On Fri, Jan 13, 2023 at 08:05:43PM +0100, John Paul Adrian Glaubitz wrote:
> libdeflate currently FTBFS on alpha due to linker issues:
> 
> cc -o libdeflate.so.0 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro 
> -Wl,-z,now -fprofile-generate -O2 -fomit-frame-pointer -std=c99 -I. -Wall 
> -Wundef -Wdeclaration-after-statement -Wimplicit-fallthrough 
> -Wmissing-prototypes -Wpedantic -Wshadow -Wstrict-prototypes -Wvla -g -O2 
> -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs 
> -Wformat -Werror=format-security -fprofile-generate -fvisibility=hidden 
> -D_ANSI_SOURCE \
>   -Wl,-soname=libdeflate.so.0 -shared lib/deflate_decompress.shlib.o 
> lib/utils.shlib.o lib/arm/cpu_features.shlib.o lib/x86/cpu_features.shlib.o 
> lib/deflate_compress.shlib.o lib/adler32.shlib.o lib/zlib_decompress.shlib.o 
> lib/zlib_compress.shlib.o lib/crc32.shlib.o lib/gzip_decompress.shlib.o 
> lib/gzip_compress.shlib.o
> lib/deflate_compress.shlib.o: in function `deflate_choose_match':
> ./lib/deflate_compress.c:2185:(.text+0x832c): relocation truncated to fit: 
> GPRELHIGH against `.rodata'

I suspect this might be better worked around with -Wl,-no-relax on the
linking only rather than disabling compiler optimisations.  I intend to
run a test of that today.

Cheers,
Michael.

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Michael Cree]

Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

The build fails with:
/<>/src/corelib/plugin/qelfparser_p.cpp:178:4: error: #error 
"Unknown Q_PROCESSOR_xxx macro, please update."

Full log at:
https://buildd.debian.org/status/fetch.php?pkg=qt6-base=alpha=6.3.1%2Bdfsg-10=1664652510=0

Attached is patch to provide the Q_PROCESSOR defines for Alpha.  With
that qt6-base builds successfully.

Cheers
Michael.

Index: qt6-base-6.3.1+dfsg/src/corelib/global/qprocessordetection.h
===
--- qt6-base-6.3.1+dfsg.orig/src/corelib/global/qprocessordetection.h
+++ qt6-base-6.3.1+dfsg/src/corelib/global/qprocessordetection.h
@@ -82,11 +82,12 @@
 /*
 Alpha family, no revisions or variants
 
-Alpha is bi-endian, use endianness auto-detection implemented below.
+Alpha is bi-endian; use auto-detection below.
 */
-// #elif defined(__alpha__) || defined(_M_ALPHA)
-// #  define Q_PROCESSOR_ALPHA
-// Q_BYTE_ORDER not defined, use endianness auto-detection
+#if defined(__alpha__) || defined(_M_ALPHA)
+#  define Q_PROCESSOR_ALPHA
+#  define Q_PROCESSOR_WORDSIZE 8
+#endif
 
 /*
 ARM family, known revisions: V5, V6, V7, V8
Index: qt6-base-6.3.1+dfsg/src/corelib/plugin/qelfparser_p.cpp
===
--- qt6-base-6.3.1+dfsg.orig/src/corelib/plugin/qelfparser_p.cpp
+++ qt6-base-6.3.1+dfsg/src/corelib/plugin/qelfparser_p.cpp
@@ -141,6 +141,8 @@ struct ElfMachineCheck
 static const Elf32_Half ExpectedMachine =
 #if 0
 // nothing
+#elif defined(Q_PROCESSOR_ALPHA)
+EM_ALPHA
 #elif defined(Q_PROCESSOR_ARM_32)
 EM_ARM
 #elif defined(Q_PROCESSOR_ARM_64)
@@ -407,6 +409,7 @@ Q_DECL_UNUSED Q_DECL_COLD_FUNCTION stati
 switch (r.machine) {
 // list definitely not exhaustive!
 case EM_NONE:   d << ", no machine"; break;
+case EM_ALPHA:	d << ", Alpha"; break;
 case EM_ARM:d << ", ARM"; break;
 case EM_AARCH64:d << ", AArch64"; break;
 #ifdef EM_BLACKFIN

Bug#1024040: mariadb-10.6: FTBFS on alpha: relocation truncated to fit: GPREL16 against symbol `wsrep_debug'

[Michael Cree]

On Sun, Nov 13, 2022 at 02:49:11PM -0800, Otto Kekäläinen wrote:
> Source: mariadb-10.6
> Version: 1:10.6.7-1
> Tags: upstream, confirmed, ftbfs
> User: debian-al...@lists.debian.org
> Usertags: alpha
> X-Debbugs-CC: debian-al...@lists.debian.org
> 
> After upload of mariadb-10.6 1:10.6.7-1 I noticed that alpha builds
> at https://buildd.debian.org/status/package.php?p=mariadb-10.6 were
> failing:

[snip]

> ./builddir/sql/./sql/wsrep_client_service.cc:77:(.text+0x140):
> relocation truncated to fit: GPREL16 against symbol `wsrep_debug'
> defined in .sbss section in ../../sql/libwsrep.a(wsrep_mysqld.cc.o)
> ../../sql/libwsrep.a(wsrep_client_service.cc.o): in function
> `Wsrep_client_service::cleanup_transaction()':

There is a work around for this.  Linking with --no-relax fixes the
problem.  I have a patch for this somewhere.  Ah, yes, add to
/debian/rules the following:

fneq (,$(filter $(DEB_HOST_ARCH_CPU),alpha))
LDFLAGS+=-Wl,--no-relax
endif

Cheers,
Michael.

Bug#1017113: glibc FTBFS on Alpha: segfault in setlocale

[Michael Cree]

Source: glibc
Version: 2.34
Severity: important
User: debian-al...@lists.debian.org
Usertags: ftbfs
Justification: Fails to build from source but built in the past.

glibc 2.34 FTBFS on Alpha with a segfault occuring during building
locales.  From the build log:

Generating locale en_US.UTF-8: this might take a while...
../localedata/gen-locale.sh: line 29: 12551 Segmentation fault  
${localedef_before_env} ${run_program_env} I18NPATH=../localedata 
${localedef_after_env} $flags -f $charmap -i $input 
${common_objpfx}localedata/$out
Charmap: "UTF-8" Inputfile: "en_US" Outputdir: "en_US.UTF-8" failed
/bin/bash: line 4: 
/<>/build-tree/alpha-libc/localedata/en_US.UTF-8/LC_CTYPE.test-result:
 No such file or directory
make[3]: *** [../gen-locales.mk:17: 
/<>/build-tree/alpha-libc/localedata/en_US.UTF-8/LC_CTYPE] Error 1
make[3]: Leaving directory '/<>/iconv'


In the build directory I reran ./debian/rule build-arch to get a
coredump.  Debugging reports:

(sid)mjc@alpha:glibc-2.34$ gdb build-tree/alpha-libc/elf/ld.so 
iconv/core-23033-\!build\!glibc-hXmOs0\!glibc-2.34\!build-tree\!alpha-libc\!elf\!ld.so
 
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "alpha-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build-tree/alpha-libc/elf/ld.so...

warning: core file may not match specified executable file.
[New LWP 23033]

warning: Unexpected size of section `.reg/23033' in core file.

warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
Core was generated by 
`/build/glibc-hXmOs0/glibc-2.34/build-tree/alpha-libc/elf/ld-linux.so.2 
--librar'.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Unexpected size of section `.reg/23033' in core file.
#0  0x020f6384 in sysmalloc (nb=656, av=0x2252908 ) at 
./malloc/malloc.c:2784
2784  set_head (av->top, (snd_brk - aligned_brk + 
correction) | PREV_INUSE);
(gdb) list
2779
2780  /* Adjust top based on results of second sbrk */
2781  if (snd_brk != (char *) (MORECORE_FAILURE))
2782{
2783  av->top = (mchunkptr) aligned_brk;
2784  set_head (av->top, (snd_brk - aligned_brk + 
correction) | PREV_INUSE);
2785  av->system_mem += correction;
2786
2787  /*
2788 If not the first time through, we either have a
(gdb) print snd_brk
$1 = 0x2064000 "\002"
(gdb) print aligned_brk
$2 = 0x2042000 "\177ELF\002\001\001"
(gdb) print correction
$3 = 0
(gdb) print av->top
$4 = (mchunkptr) 0x2042000
(gdb) print *av->top
$5 = {mchunk_prev_size = 282584257676671, mchunk_size = 0, fd = 0x190260003, bk 
= 0x2ce40, fd_nextsize = 0x40, 
  bk_nextsize = 0xb9d550}
(gdb) bt full
#0  0x020f6384 in sysmalloc (nb=656, av=0x2252908 ) at 
./malloc/malloc.c:2784
old_top = 
old_size = 0
old_end = 
size = 
brk = 
correction = 0
snd_brk = 0x2064000 "\002"
front_misalign = 
end_misalign = 
aligned_brk = 0x2042000 "\177ELF\002\001\001"
p = 
remainder = 
remainder_size = 
pagesize = 
tried_mmap = false
__PRETTY_FUNCTION__ = "sysmalloc"
#1  0x020f74d0 in _int_malloc (av=0x2252908 , 
bytes=640) at ./malloc/malloc.c:4290
p = 
iters = 
nb = 656
idx = 42
bin = 0xe000
victim = 0x1fff
size = 
victim_index = 
remainder = 
remainder_size = 
block = 409600
bit = 
map = 
fwd = 
bck = 
tcache_unsorted_count = 
tcache_nb = 
tc_idx = 39
return_cached = 
__PRETTY_FUNCTION__ = "_int_malloc"
#2  0x020f7624 in tcache_init () at ./malloc/malloc.c:3128
ar_ptr = 0x2252908 
victim = 
bytes = 
#3  0x020f8050 in tcache_init () at ./malloc/malloc.c:3124
ar_ptr = 
victim = 0x0
bytes = 640
__futex = 
__atg2_result = 
__prev = 
__cmp = 
__tmp = 
__snew = 
__addr64 = 
__prev = 
__cmp = 
--Type  for more, q to quit, c to continue without paging--
__tmp = 
  

Bug#1007946: glib2.0 FTBFS on alpha; misdetected libutil so name

[Michael Cree]

Source: glib2.0
Version: 2.72.0-1
Severity: important
Justification: fails to build from source when built in past
User: debian-al...@lists.debian.org
Usertags: ftbfs
X-Debbugs-Cc: debian-al...@lists.debian.org

glib2.0 FTBFS on alpha in the test suite with:

GLib-GIO:ERROR:../../../gio/tests/pollable.c:198:test_pollable_unix_pty: 
'handle' should not be NULL
Bail out! 
GLib-GIO:ERROR:../../../gio/tests/pollable.c:198:test_pollable_unix_pty: 
'handle' should not be NULL
――
161/266 glib:gio / pollable FAIL 0.04s  
 killed by signal 6 SIGABRT

The code at line 198 of ../../../gio/tests/pollable.c is:

handle = dlopen (LIBUTIL_SONAME, RTLD_GLOBAL | RTLD_LAZY);

And in the meson configure log at the start of the build we see:

Message: Found libutil as libutil.so.1

This is wrong.  There is no libutil.so.1 on Alpha.  It should
be libutil.so.1.1

The problem seems to me to be at lines 18 to 20 of
gio/tests/meson.build:

libutil = run_command('sh', '-c',
'''ldconfig -p | grep -o "[[:space:]]@0@\.so\(\.[0-9]\+\)\?\b"'''
.format(libutil_name), check: false).stdout().strip().split('\n')

in which a regular expression is used to match the detected libutil.so
version.  That regular expression assumes that there is only one digit
in the so version thus incorrectly detects the libutil.so version on
Alpha.

Changing the "\?" to "*" would probably be the fix.

Regards,
Michael.

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

[Michael Cree]

On Fri, Oct 08, 2021 at 09:00:22PM +0200, John Paul Adrian Glaubitz wrote:
> On 10/8/21 20:52, Rob Browning wrote:
> > Then, once that's uploaded were you planning to handle the reverse dep
> > rebuilds, and/or what coordination might we need there?
> 
> We can just rebuild all of these reverse dependencies, yes. Adrian Bunk is
> probably happy to take care of that job, he has access to wanna-build, too,
> and has recently done a lot of work in this area.

Just to note I have done a test build of guile-3.0 on a UP alpha system
with an up-to-date chroot.  It failed to build with one failure in the
testsuite, namely:

Running 00-repl-server.test
ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32)))

Cheers,
Michael.

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

[Michael Cree]

On Fri, Oct 08, 2021 at 03:03:38AM +0200, John Paul Adrian Glaubitz wrote:
> On 10/8/21 03:00, Rob Browning wrote:
> > If we've never had a 3.0 viable for alpha, for example, then we can of
> > course do whatever we like, with the realization that if we disable
> > threads there now, we may be stuck with that choice until 3.2.

I think guile-3.0 may have been installed on Alpha in the past.  I
recall doing a manual build on a UP system some time ago and uploading
into the archive.

> We can always break the ABI in a controlled manner. That's what binNMUs
> are for. I don't understand the discussion.

I am still of the opinion that we should try in the first instance
to find the real problem in the toolchain and fix it there.  The bug
affects packages other than guile and only on SMP systems.

When I get my hands on Electro I can boot with a generic kernel
and build guile-3.0 there which hopefully will overcome the memory
exhaustion and time-out problems seen on the XP1000s.

Cheers,
Michael.

Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS

[Michael Cree]

On Sun, Oct 03, 2021 at 09:14:04PM +0200, John Paul Adrian Glaubitz wrote:
> On 10/3/21 20:29, Michael Cree wrote:
> > On Sun, Oct 03, 2021 at 11:33:31AM +0200, John Paul Adrian Glaubitz wrote:
> >> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
> >> support. Passing --without-threads to configure disables thread
> >> support and fixes the build.
> > 
> > The issue only appears on SMP systems.  They build correctly on UP
> > systems.  This issue affects a number of package builds including
> > gnutls and autogen.  I often just manually build them on a UP system
> > and upload to the archive, and I could do that with guile-2.2.  As
> > to where the issue really is ... I am not sure.
> 
> The problem is that even the built guile package will crash on SMP systems
> without "--without-threads". So, currently, we have no other choice than
> disabling threads if we want guile and others to not FTBFS on imago and
> electro and other SMP buildds in the future.

Well, we do have choices, and one is to find the actual problem in the
toolchain.  That would be a far better solution!

Cheers
Michael.

Bug#995613: guile-2.2: Please build with --without-threads on alpha to fix FTBFS

[Michael Cree]

On Sun, Oct 03, 2021 at 11:33:31AM +0200, John Paul Adrian Glaubitz wrote:
> Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread
> support. Passing --without-threads to configure disables thread
> support and fixes the build.

The issue only appears on SMP systems.  They build correctly on UP
systems.  This issue affects a number of package builds including
gnutls and autogen.  I often just manually build them on a UP system
and upload to the archive, and I could do that with guile-2.2.  As
to where the issue really is ... I am not sure.

Cheers
Michael.

Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha

[Michael Cree]

On Mon, Aug 17, 2020 at 12:39:27PM +0200, Jonas Smedegaard wrote:
> Hi Michael,
> 
> Quoting Michael Cree (2020-08-17 11:30:52)
> > Ffmpeg does not build on alpha as it currently depends on
> > libpocketsphinx-dev but pocketsphinx does not build on alpha
> > due to long standing test suite failures.  I see the build
> > dependency has been removed on many other arches including
> > some release arches, and it would be nice if the same could
> > be done for alpha.
> 
> Has those test suite failures been investigated?

The test suite failures on mips* and s390x are reported in #812335
and upstream [1], with no comment whatsoever from upstream developers
in almost five years.  I therefore have not bothered to burden them
further with the Alpha test suite failure.

When I investigated the Alpha test suite failure it became clear to
me that I was not going to make any headway in debugging it without
a much better knowledge of the pocketsphinx code base and I did not
have time to invest in doing that.

Cheers
Michael.

[1] https://sourceforge.net/p/cmusphinx/bugs/448/

Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha

[Michael Cree]

Package: ffmpeg
Version: 7:4.3.1-2
Severity: normal

Dear Maintainer,

Ffmpeg does not build on alpha as it currently depends on
libpocketsphinx-dev but pocketsphinx does not build on alpha
due to long standing test suite failures.  I see the build
dependency has been removed on many other arches including
some release arches, and it would be nice if the same could
be done for alpha.

Regards,
Michael

Bug#921717: cyrus-imapd: FTBFS on arm*, i386, mipsel, ppc64el and s390x

[Michael Cree]

On Tue, May 12, 2020 at 01:04:06AM +0200, John Paul Adrian Glaubitz wrote:
> On 5/12/20 1:01 AM, John Paul Adrian Glaubitz wrote:
> > On 5/11/20 11:56 PM, Xavier wrote:
> >> Could someone help us here ? I forwarded this bug to upstream ([1]) but
> >> didn't receive any response for now.
> >>
> >> (Cc to RFH bug)
> > 
> > The problem here is va_list. On some architectures, the calling convention
> > doesn't seem to allow comparing va_list against NULL due to the way va_list
> > is implemented on a particular architecture.
> Correction: The va_list problem seems to affect ARM architectures only

According to the standard va_list is a complete object type.  There is
therefore no guarantee it can be compared to NULL and it is only by
accident (implementation detail) that is possible to do so on some
architectures.

Cheers,
Michael.

Bug#947276: Regarding libspiro: CVE-2019-19847

[Michael Cree]

Hello,

This bug is the reason for the FTBFS of libspiro on Alpha and
presumably on HPPA also.

It is fixed upstream in commit:
35233450c922787dad42321e359e5229ff470a1e

I have verified that building on Alpha with that commit as a
patch in Debian source results in a successful build.

Cheers,
Michael.

Bug#941259: e-antic FTBFS on alpha due to enforced absence of libflint-dev

[Michael Cree]

Source: e-antic
Version: 0.1.3+ds-2
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

e-antic FTBFS on alpha during the configure stage with [1]:

checking flint/flint.h usability... no
checking flint/flint.h presence... no
checking for flint/flint.h... no
configure: error: flint header not found

flint has now been built on Alpha so debian/control can be updated to
build-depend on libflint-dev on Alpha.  Also openmp functions on Alpha
so the disabling of openmp is not necessary in debian/rules.  I attach
a patch that attends to both of these matters.  With the patch e-antic
builds to completion on Alpha.

Cheers,
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=e-antic=alpha=0.1.3%2Bds-2=1565125004=0
diff -urp e-antic-0.1.3+ds/debian/control e-antic-0.1.3+ds_new/debian/control
--- e-antic-0.1.3+ds/debian/control	2019-07-12 03:35:23.0 +1200
+++ e-antic-0.1.3+ds_new/debian/control	2019-09-27 20:16:42.117758125 +1200
@@ -8,8 +8,8 @@ Build-Depends:
  autoconf-archive, gnulib,
  libgmp-dev,
  libmpfr-dev,
- libflint-dev [!alpha !m68k !sh4 !x32],
- libflint-arb-dev [!alpha !m68k !sh4 !x32]
+ libflint-dev [!m68k !sh4 !x32],
+ libflint-arb-dev [!m68k !sh4 !x32]
 Standards-Version: 4.4.0
 Homepage: https://github.com/videlec/e-antic/
 Vcs-Git: https://salsa.debian.org/science-team/e-antic.git
diff -urp e-antic-0.1.3+ds/debian/rules e-antic-0.1.3+ds_new/debian/rules
--- e-antic-0.1.3+ds/debian/rules	2019-06-21 05:20:36.0 +1200
+++ e-antic-0.1.3+ds_new/debian/rules	2019-09-27 20:47:57.992018094 +1200
@@ -7,7 +7,7 @@ export ACLOCAL_PATH=/usr/share/gnulib/m4
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-ifneq (,$(filter $(DEB_HOST_MULTIARCH), alpha-linux-gnu mipsel-linux-gnu))
+ifneq (,$(filter $(DEB_HOST_MULTIARCH), mipsel-linux-gnu))
 DEB_PKG_EANTIC_OPENMP=no
 else
 DEB_PKG_EANTIC_OPENMP=yes

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Michael Cree]

On Mon, Sep 09, 2019 at 10:49:48PM +0200, John Paul Adrian Glaubitz wrote:
> Shortly after typing "root" and pressing enter, the following message is 
> printed to the
> console which seems to be an alpha-specific syscall:
> 
> [  195.414939] do_entUnaUser: 7 callbacks suppressed

No, that is not a syscall, that's the misaligned access by user space
interrupt vector letting you know the kernel fixed up 7 misaligned
memory accesses.

Cheers,
Michael.

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Michael Cree]

On Mon, Sep 09, 2019 at 11:14:50PM +0200, John Paul Adrian Glaubitz wrote:
> On 9/9/19 10:49 PM, John Paul Adrian Glaubitz wrote:
> > Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading 
> > glibc
> > to version 2.29-1 resulted in setuid/getuid breaking in a weird way:
> 
> To reproduce, one can simply run debootstrap with qemu-user-static installed 
> and
> enter the chroot:
> 
> root@epyc:/local_scratch> debootstrap --no-check-gpg --arch=alpha --foreign 
> --variant=minbase unstable sid-alpha-sbuild 
> http://ftp.ports.debian.org/debian-ports
> (...)
> root@epyc:/local_scratch> chroot sid-alpha-sbuild
> bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
> I have no name!@epyc:/local_scratch> ./debootstrap/debootstrap --second-stage
> E: debootstrap can only run as root
> I have no name!@epyc:/local_scratch>
> 
> I assume this would also work on qemu-system-alpha although I haven't tried
> yet. But it should work the same way but without the "--foreign" argument.

What kernel are you running?  Be aware that recent kernels on alpha
(since ecf7e0a4ad15287) now support the getuid and getgid syscalls
that the other arches always have had.  I wonder if glibc has been
updated in anyway for that?  If so, it should be checking kernel
version as to whether to use OSF1 syscall conventions or Linux
syscall conventions.  OSF1 calling conventions should work on any
kernel, whereas Linux calling conventions only on kernels since
v5.1.

Cheers
Michael.

Bug#923650: Bug #923650 in x265 marked as pending

[Michael Cree]

Note that disabling altivec does not fix the baseline issue for
ppc64, namely that x265 is compiling with -mcpu=power8 on ppc64.

The baseline is power5.

Cheers,
Michael.

Bug#920161: openjdk-11 ftbfs on alpha with

[Michael Cree]

On Tue, Jan 22, 2019 at 10:48:16AM +0100, Matthias Klose wrote:
> openjdk-11 ftbfs on alpha, linking libjvm.

The relocation errors can be worked around by linking with
-Wl,--no-relax, i.e., adding the following in debian/rules:

ifeq ($(DEB_HOST_ARCH),alpha)
  export EXTRA_LDFLAGS_ZERO += -Wl,--no-relax
endif

It seems only openjdk-11 needs this as openjdk-12 built fine without
relocation link errors.

The build will then fail in the test suite because since openjdk-10
java on the rare occasion locks up on Alpha, falls to 0% CPU usage
and never terminates.  The test suite seems to reliably trigger that
lock up.

Disabling the test-suite will get us past that (as it did on the build
of openjdk-12) and will still produce a java that for most purposes
works.

Also the install tries to install jhsdb which is not built on Alpha
so that needs to be fixed too.

Cheers,
Michael.

Bug#916504: pulseaudio FTBFS on Alpha; return of the volume-test failure

[Michael Cree]

Source: pulseaudio
Version: 12.2-2
Severity: important
Justification: fails to build from source but built in the past.
User: debian-al...@lists.debian.org
Usertags: alpha
Tags: patch

Pulseaudio FTBFS on alpha due to the volume-test test failing due to
a floating-point exception which in turn is due to an infinity in
floating-point calculations when volume-test is compiled with finite
math options.

This is bug #798248 reappearing but in a subtlely different guise.
There the non-finite math was protected against by checking that the
arguments are finite before performing floating point calculations,
but it now seems that gcc takes the specification of finite math,
being "[a]llow optimizations for floating-point arithmetic that
assume that arguments and results are not NaNs or +-Infs" so
pedantically true, that it is fair game to optimise away any calls
to isfinite() because the argument must be finite: it was said so
on the command line!

Whatever, examination of the object code shows that the calls to
isfinite() are eliminated thus the floating-point arithmetic is no
longer protected.

Fortunately we can work out whether the arguments to the offending
arithmetic are finite by other means and I attach a patch doing
just that.  With this patch pulseaudio builds to completion on
Alpha.

Cheers,
Michael.
Index: pulseaudio-12.2/src/tests/volume-test.c
===
--- pulseaudio-12.2.orig/src/tests/volume-test.c	2018-12-15 14:29:34.0 +1300
+++ pulseaudio-12.2/src/tests/volume-test.c	2018-12-15 16:24:38.303993387 +1300
@@ -114,7 +114,7 @@
 double q, qq;
 
 p = pa_sw_volume_multiply(v, w);
-if (isfinite(db) && isfinite(db2))
+	if (v && w)
 qq = db + db2;
 else
 qq = -INFINITY;

Bug#903758: babl FTBFS on Alpha: misuse of -Ofast with non-finite floating point

[Michael Cree]

Source: babl
Version: 0.1.50-1
Severity: important
Justification: failed to build from source (but built in the past)
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

babl FTBFS on Alpha [1] with what on the surface looks like a linker error
but is actually misuse of the -Ofast compiler option.  babl unconditionally
uses the -Ofast option when compiling with gcc.  This implies
-ffast-math which the gcc manual makes clear is not compliant with
standards and on some architectures may break if used with non-finite
math.  Alpha is one of those architectures. 

If we remove -Wl,-z,defs from the linker flags specified in debian/rules
then the link succeeds on Alpha but the test suite fails with floating
point exceptions, because non-finite math is used.

I attach a patch that adds a --disable-ofast option to the configure
script so it is possible to build without -Ofast.  The second patch
is a change to debian/rules to detect if building with Alpha then
supply the --disable-ofast option when invoking configure. With these
babl builds to completion, with the test suite passing, on Alpha.

Cheers
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=babl=alpha=0.1.50-1=1526902985=0
--- a/configure.ac
+++ b/configure.ac
@@ -136,6 +136,9 @@
 WEBSITE_LOCATION=public_html/babl/
 AC_SUBST(WEBSITE_LOCATION)
 
+AC_ARG_ENABLE([ofast],
+  [  --disable-ofast  disable use of -Ofast (default=no)],,
+  enable_ofast="yes")
 
 if eval "test x$GCC = xyes"; then
   case " $CFLAGS " in
@@ -161,8 +164,13 @@
 BABL_DETECT_CFLAGS(extra_warnings, '-Wold-style-definition')
 CFLAGS="$CFLAGS $extra_warnings"
 
-BABL_DETECT_CFLAGS(extra_warnings, '-Ofast' )
-CFLAGS="$CFLAGS $extra_warnings"
+if test "x$enable_ofast" = xyes; then
+  BABL_DETECT_CFLAGS(extra_warnings, '-Ofast' )
+  CFLAGS="$CFLAGS $extra_warnings"
+else
+  BABL_DETECT_CFLAGS(extra_warnings, '-O3' )
+  CFLAGS="$CFLAGS $extra_warnings"
+fi
 
 fi
 
--- babl-0.1.50/debian/rules	2018-05-21 14:36:01.0 +1200
+++ babl-0.1.50+alpha/debian/rules	2018-07-14 21:14:49.322785083 +1200
@@ -10,6 +10,12 @@
 	sse_flags := --enable-mmx --enable-sse --enable-sse2
 endif
 
+# Disable use of -Ofast (thus -ffath-math) on Alpha
+ofast_flags :=
+ifeq ($(DEB_HOST_ARCH_CPU),alpha)
+	ofast_flags := --disable-ofast
+endif
+
 %:
 	dh $@ --with gnome
 
@@ -20,7 +26,8 @@
 	dh_auto_configure -- \
 		$(sse_flags) \
 		--disable-sse4_1 \
-		--disable-f16c
+		--disable-f16c \
+		$(ofast_flags)
 
 override_dh_install:
 	find debian/tmp -name '*.la' -print -delete

Bug#902105: sip-tester FTBFS on alpha; sipp_socklen_t set to wrong type

[Michael Cree]

Source: sip-tester
Version: 1:3.5.1-2
Severity: important
Justification: Fails to build from source (but built in the past)
User: debian-al...@lists.debian.org
Usertags: ftbfs
Tags: patch

sip-tester FTBFS on Alpha due to the sipp_socklen_t being set to int
instead of socklen_t in the include/socket.hpp header file which
ultimately results in the following build failure [1]:

src/call.cpp: In member function 'char* 
call::createSendingMessage(SendingMessage*, int, char*, int, int*)':
src/call.cpp:2153:63: error: invalid conversion from 'int*' to 'socklen_t* {aka 
unsigned int*}' [-fpermissive]
 (sockaddr *)(void *)_sockaddr, ));

I attach a patch to fix this.

Cheers
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=sip-tester=alpha=1%3A3.5.1-2=1497567454=0
Index: sip-tester-3.5.1/include/socket.hpp
===
--- sip-tester-3.5.1.orig/include/socket.hpp	2016-03-17 21:05:49.0 +1300
+++ sip-tester-3.5.1/include/socket.hpp	2018-06-22 21:20:31.931559588 +1200
@@ -132,7 +132,7 @@
 #define WS_BUFFER 2 /* Buffer the message if there is no room for writing the message. */
 
 
-#if defined (__hpux) || defined (__alpha) && !defined (__FreeBSD__)
+#if defined (__hpux) || (defined (__alpha) && !defined (__FreeBSD__) && !defined (__linux__))
 #define sipp_socklen_t  int
 #else
 #define sipp_socklen_t  socklen_t

Bug#901920: plplot FTBFS on alpha: misdetects compiler as not supporting NaN

[Michael Cree]

Source: plplot
Version: 5.13.0+dfsg-7
Severity: important
Justification: fails to build from source (but built in past)
User: debian-al...@lists.debian.org
Usertags: ftbfs
Tags: patch

plplot FTBFS on Alpha [1] with missing libcsirocsa.so files at the
install stage.  One can trace this back to the cmake configure at
the start which misdetects the compiler as not supporting NaNs
(from the build log):

-- Check for NaN awareness in C compiler
-- Check for NaN awareness in C compiler - not found
-- WARNING: Setting PL_HAVE_QHULL and WITH_CSA to OFF.

In cmake/modules/csiro.cmake is:

  if(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
if(CMAKE_C_COMPILER MATCHES "gcc")
  set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
else(CMAKE_C_COMPILER MATCHES "gcc")
  set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
endif(CMAKE_C_COMPILER MATCHES "gcc")

In the build CMAKE_C_COMPILER gets set to /usr/bin/cc which is gcc
on Debian Linux but does not match "gcc" in the test and thus the
test proceeds with the compiler option "-ieee" intended for the
Compaq C compiler, not for gcc.

A simple fix for Debian Linux would be to eliminate the test for
gcc (as the Compaq C Compiler for Alpha Linux has not been runnable
under Linux for quite a few years so there is no point in testing
for it) and just use the -mieee command line argument, i.e.,

  if(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
 set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
  endif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")

I suspect this fix might not be acceptable to upstream as it
potentially breaks the build on Tru64 Unix with the Compaq C
compiler.

Cheers,
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=plplot=alpha=5.13.0%2Bdfsg-7=1529330311=0

Bug#900885: dump FTBFS on Alpha; no getpid syscall

[Michael Cree]

On Wed, Jun 06, 2018 at 09:43:20PM +1000, Alexander Zangerl wrote:
> On Wed, 06 Jun 2018 22:51:08 +1200, Michael Cree writes:
> >dump FTBFS on alpha with [1]:
> ...
> >Alpha Linux does not have the getpid syscall; it follows OSF1.0
> 
> oh the joy of non-posix environments :-(

I doubt that this has anything to do with posix. Posix specifies
the API and by calling kernel syscalls dump is sidestepping the
standard API.  Syscalls are part of the kernel ABI and is
notably architecture dependent.

The patch that introduced these syscalls was to support a Sparc
idiosyncracy.  Was that for 32-bit sparc (which Debian no longer
supports) or 64-bit sparc (which is a ports architecture)? If the
former the best solution may be to drop the sparc-clone-lockup
patch, which is what introduced dependencies on the syscall ABI
and broke the build on Alpha.  I'll ask on #debian-ports as to
whether anyone knows why the sparc patch was introduced.

Cheers
Michael.

Bug#900885: dump FTBFS on Alpha; no getpid syscall

[Michael Cree]

Source: dump
Version: 0.4b46-4
Severity: important
Justification: Fails to build from source but built in past
User: debian-al...@lists.debian.org
Usertags: ftbfs
Tags: patch

dump FTBFS on alpha with [1]:

gcc -DHAVE_CONFIG_H -I. -I..  -I../dump -I../compat/include -I../common
-Wdate-time -D_FORTIFY_SOURCE=2 -D_USE_BSD_SIGNAL
-D_PATH_DUMPDATES=\"/var/lib/dumpdates\" -D_DUMP_VERSION=\"0.4b46\"
-D_PATH_RMT=\"/etc/rmt\"  -g -O2 -fdebug-prefix-map=/<>=.
-Wformat -Werror=format-security -fPIE -c -o tape.o tape.c
tape.c: In function 'fork_clone_io':
tape.c:748:12: error: 'SYS_getpid' undeclared (first use in this
function); did you mean 'SYS_getxpid'?
syscall(SYS_getpid);
^~

Alpha Linux does not have the getpid syscall; it follows OSF1.0
conventions which has the getxpid syscall returning the PID (and
other info inaccessible via the C ABI).

This problem was introduced in the patch sparc-clone-lockup.  I
attach a fix and that is to be applied on top of
debian/patches/sparc-clone-lockup.

Cheers,
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=dump=alpha=0.4b46-4=1528213679=0
--- a/dump/tape.c
+++ b/dump/tape.c
@@ -745,7 +745,11 @@
getppid();
/* as per clone call manpage: caching! */
getpid();
+#ifdef __alpha__
+   syscall(SYS_getxpid);
+#else
syscall(SYS_getpid);
+#endif
 
/* az: clone manpage doesn't say jack about what the
   child receives, but it's NOT ZERO on sparc. however, it seems the

Bug#896658: qtbase-opensource-src FTBFS on alpha: ambiguous call of atime()

[Michael Cree]

On Tue, May 01, 2018 at 10:21:11AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > qtbase-opensource-src FTBFS on Alpha [1] due to an ambiguous
> 
> Thanks for the very clear explanation! There are two possible ways out here:
> 
> 1) Preferred by us Qt maintainers: file a bug in bugreports.qt.io and send us 
> the link so we can follow it. 

I've tired making an account there to report the bug. What a painful
experience: it tried to solicit information off me for commercial
advertising purposes (which is totally unacceptable), and after many
more painful and unclear steps I finally got to the bug web pages.

But I don't know what to do.  I can't work out the products or
components (none match the Debian source package names or seem
to bear much relationship to them) so I am totally lost.

I now regret attempting to make an account there and wish I could
just completely delete it.

Please, would you file the bug upstream, I'm not having anything
more to do with that obnoxious web site.

Cheers
Michael.

Bug#897067: libserialport FTBFS on Alpha: no BOTHER symbol defined

[Michael Cree]

Source: libserialport
Version: 0.1.1-2
Severity: wishlist
User: debian-al...@lists.debian.org
Usertags: ftbfs
Tags: patch

libserialport FTBFS on Alpha [1] with:

linux_termios.c: In function 'set_termios_speed':
linux_termios.c:90:19: error: 'BOTHER' undeclared (first use in this
function)
  term->c_cflag |= BOTHER;

This is known upstream as bug #363 [2] and is fixed by upstream commit
6c8115820d2eb06ada96a48cdda7dc3467ae90d1 [3]. It does not look like
upstream has made any new formal release, nevertheless is there any
chance of getting an upload to Debian with this commit included?

Cheers,
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libserialport=alpha=0.1.1-2=1502735836=0
[2] https://sigrok.org/bugzilla/show_bug.cgi?id=363
[3] 
https://sigrok.org/gitweb/?p=libserialport.git;a=commit;h=6c8115820d2eb06ada96a48cdda7dc3467ae90d1

Bug#896658: qtbase-opensource-src FTBFS on alpha: ambiguous call of atime()

[Michael Cree]

Source: qtbase-opensource-src
Version: 5.10.1+dfsg-5
Severity: important
Justification: fails to build from source (but built in past)
User: debian-al...@lists.debian.org
Usertags: ftbfs
Tags: patch

qtbase-opensource-src FTBFS on Alpha [1] due to an ambiguous
resolution of the overloaded call to atime() with definitions of
atime() at lines 246, 254 and 299 in
src/corelib/io/qfilesystemengine_unix.cpp. The one at line 299
is declared as:

Q_DECL_UNUSED static typename std::enable_if<(::st_atimensec, true)
...

which I guess (I don't know C++ very well) means that if the field
st_atimensec is present then include that declaration of atime().  On
Alpha Linux this field is present in the struct stat declaration in
the header file (sys/stat.h) inside a union declaration, which looks
to be a unique definition of struct stat amongst the Linicies.  So
this definition of atime() at line 299 applies on Alpha Linux and
conflicts with one of the earlier definitions at lines 246 and 254.

I don't know if this is a bug in the header file (i.e. glibc) or
present for historical reasons (Alpha Linux being the first 64-bit
Linux does have some idiosyncrasies not repeated in later 64-bit
Linicies), nevertheless I attach a patch that disables the second
confounding definition of atime() at line 299 on Alpha only.  With
the patch qtbase-opensource-src builds to completion on Alpha.

Cheers
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src=alpha=5.10.1%2Bdfsg-5=1523222004=0
--- a/src/corelib/io/qfilesystemengine_unix.cpp
+++ b/src/corelib/io/qfilesystemengine_unix.cpp
@@ -292,7 +292,7 @@
 { return timespecToMSecs(statBuffer.st_mtimespec); }
 #endif
 
-#ifndef st_mtimensec
+#if !defined(st_mtimensec) && !defined(__alpha__)
 // Xtimensec
 template 
 Q_DECL_UNUSED static typename std::enable_if<(::st_atimensec, true), qint64>::type

Bug#879248: r-cran-nmf: detecting number of cores

[Michael Cree]

How about the attached patch?  Should detection of number of cores
fail it sets the number of cores to be one.  With this patch
r-cran-nmf builds successfully on Alpha.

Cheers
Michael.
Index: r-cran-nmf-0.21.0/R/options.R
===
--- r-cran-nmf-0.21.0.orig/R/options.R	2018-02-07 02:45:56.0 +1300
+++ r-cran-nmf-0.21.0/R/options.R	2018-03-12 19:42:26.704548354 +1300
@@ -78,7 +78,7 @@
 	, gc=50
 	# define default parallel backend 
 	, parallel.backend= option_symlink('pbackend') # for backward compatibility
-	, pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'
+	, pbackend= if( parallel::detectCores() > 1 && !is.na(parallel::detectCores()) ) 'par' else 'seq'
 	# toogle verbosity
 	, verbose=FALSE
 	# toogle debug mode
Index: r-cran-nmf-0.21.0/R/parallel.R
===
--- r-cran-nmf-0.21.0.orig/R/parallel.R	2018-02-19 06:39:59.0 +1300
+++ r-cran-nmf-0.21.0/R/parallel.R	2018-03-12 19:35:55.337916554 +1300
@@ -17,6 +17,7 @@
 getMaxCores <- function(limit=TRUE){
 	#ceiling(parallel::detectCores()/2)
 	nt <- n <- parallel::detectCores()
+	if( is.na(n) ) n <- 1L
 	# limit to number of cores specified in options if asked for
 	if( limit ){
 		if( !is.null(nc <- getOption('cores')) ) n <- nc # global option

Bug#823133: subversion FTBFS on Alpha: misaligned strings in the test suite

[Michael Cree]

On Fri, Mar 02, 2018 at 11:32:44PM -0500, James McCoy wrote:
> Thanks (again) for the very thorough analysis.  Sorry it's taken so long
> for me to circle back to this.
> 
> If I understand correctly, the easiest fix would be to memcpy()
> tc->source to an appropriately sized apr_uint16_t/apr_int32_t array.
> That could then be used for the svn_utf__utf{16,32}_to_utf8() calls.
> 
> If so, could you try the attached patch?

Yes, with that patch subversion builds successfully on Alpha.

Cheers
Michael.

Bug#890813: faketime does not work correctly on Alpha

[Michael Cree]

Package: faketime
Version: 0.9.7-1
Severity: important
Tags: patch

The faketime package fails to work correctly on the Alpha
architecture. This failure of faketime to work correctly is the
reason for the mbedtls FTBFS, which uses faketime in its test
suite [1].

Consider the following test program (which I call "time-test"):

#include 
#include 
#include 

int main(void)
{
struct timeval tv;

for (int j=0; j<5; j++) {
usleep(1);
gettimeofday(, NULL);
printf("s=%ldus=%ld\n", tv.tv_sec, tv.tv_usec);
}
return 0;
}


When run it produces output like:

s=1519025990us=838219
s=1519025990us=848965
s=1519025990us=859711
s=1519025990us=870456
s=1519025990us=881202

But when run as (with faketime built in its source directory):

LD_PRELOAD=faketime-0.9.7/src/libfaketime.so.1 FAKETIME="-1d" ./time-test

the output is:

s=2199023743604us=0
s=2199023657204us=0
s=2199023570804us=0
s=2199023484404us=0
s=2199023398004us=0

which is definitely not correct.

The reason for the incorrect behaviour is that there are two
gettimeofday symbols in libc on Alpha and the dlsym() call to link
to the gettimeofday() is picking up the function with the wrong ABI.
I attach a patch to fix that.  Faketime built with the attached
patch works correctly and with a fixed faketime the mbedtls source
package builds to completion on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mbedtls=alpha=2.7.0-2=1518727161=0

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: alpha

Kernel: Linux 4.14.10-titan-p1+ (SMP w/3 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Index: faketime-0.9.7/src/libfaketime.c
===
--- faketime-0.9.7.orig/src/libfaketime.c   2018-02-19 07:57:52.0 
+1300
+++ faketime-0.9.7/src/libfaketime.c2018-02-19 08:23:51.592643229 +1300
@@ -1658,7 +1658,11 @@
   real_lstat64 =dlsym(RTLD_NEXT, "__lxstat64");
   real_time =   dlsym(RTLD_NEXT, "time");
   real_ftime =  dlsym(RTLD_NEXT, "ftime");
+#if defined(__alpha__) && defined(__GLIBC__)
+  real_gettimeofday =   dlvsym(RTLD_NEXT, "gettimeofday", "GLIBC_2.1");
+#else
   real_gettimeofday =   dlsym(RTLD_NEXT, "gettimeofday");
+#endif
 #ifdef FAKE_SLEEP
   real_nanosleep =  dlsym(RTLD_NEXT, "nanosleep");
   real_usleep = dlsym(RTLD_NEXT, "usleep");
@@ -1671,7 +1675,11 @@
 #endif
 #ifdef FAKE_INTERNAL_CALLS
   real___ftime =  dlsym(RTLD_NEXT, "__ftime");
+#  if defined(__alpha__) && defined(__GLIBC__)
+  real___gettimeofday =   dlvsym(RTLD_NEXT, "__gettimeofday", "GLIBC_2.1");
+#  else
   real___gettimeofday =   dlsym(RTLD_NEXT, "__gettimeofday");
+#  endif
   real___clock_gettime  = dlsym(RTLD_NEXT, "__clock_gettime");
 #endif
 #ifdef __APPLEOSX__

Bug#888566: vim FTBFS on alpha: vim segfaults in the build

[Michael Cree]

Source: vim
Version: 2:8.0.1401-2
Severity: important
Justification: fails to build from source (but built in the past)
User: debian-al...@lists.debian.org
Usertags: ftbfs

vim FTBFS on Alpha with the following [1]:

make[2]: Entering directory '/<>/src/vim-gtk/po'
../vim -u NONE -e -X -S check.vim -c "if error == 0 | q | endif" -c cq af.po
Segmentation fault
Makefile:153: recipe for target 'af.ck' failed

And, indeed, the built vim in src/vim-gtk3 segfaults when manually
run.  Debugging shows the segfault at:

#0  0x020001173014 in parse_cino (buf=0x200036a83a0) at misc1.c:7047

7047for (p = buf->b_p_cino; *p; )

which sets p to buf->b_p_cino and dereferences it but it is NULL.
Interesting the offset to field b_p_cino in the struct is 5144
bytes.

Going one step up the stack to:

#1  0x0200011b734c in check_buf_options (buf=0x200036a83a0) at
option.c:5672

5671check_string_option(>b_p_cino);
5672parse_cino(buf);

So buf->b_p_cino should be set to an empty string (i.e. "") by
check_string_option() BUT the field b_p_cino in the struct is
5136 bytes from the start of the struct (cf. 5144 bytes for the
same struct in module misc1.o)!

Four of those bytes difference are due to the field b_ino in the
struct (of type ino_t).  And indeed examining the build log [1]
one sees option.c is compiled with -DFILE_OFFSET_BITS=64 but
misc1.c is NOT compiled with that option, hence the difference
in offsets to fields in the buf_T struct.

I am not sure why only some modules are compiled with
-DFILE_OFFSET_BITS=64. Whatever the reason, it leads to a broken
vim on Alpha.

Cheers
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=vim=alpha=2%3A8.0.1401-2=1514134076=0

Bug#829143: Bug #829143: Extending python-demgengeo FTBFS fix to Alpha.

[Michael Cree]

I extend the patch from Dave Anglin to also fix the FTBFS of
python-demgengeo on Alpha.  Attached.

Cheers
Michael
--- a/m4/boost.m4
+++ b/m4/boost.m4
@@ -484,17 +484,17 @@
   possible_paths="${with_boost}/lib ${with_boost}"
 else
   possible_paths="${boost_cv_inc_path%/include}/lib \
-/usr/lib*/x86_64* /usr/lib*/i386* /usr/lib*/aarch64* /usr/lib*/arm* /usr/lib*/mips* \
+/usr/lib*/x86_64* /usr/lib*/i386* /usr/lib*/aarch64* /usr/lib*/alpha* /usr/lib*/arm* /usr/lib*/hppa* /usr/lib*/mips* \
   /usr/lib*/powerpc* /usr/lib*/ppc64* /usr/lib*/s390* /usr/lib*/sh4* /usr/lib*/sparc* /usr/lib* \
-/usr/local/lib*/x86_64* /usr/local/lib*/i386* /usr/local/lib*/aarch64* /usr/local/lib*/arm* \
-  /usr/local/lib*/mips* /usr/local/lib*/powerpc* /usr/local/lib*/ppc64* /usr/local/lib*/s390* \
+/usr/local/lib*/x86_64* /usr/local/lib*/i386* /usr/local/lib*/aarch64* /usr/local/lib*/alpha* /usr/local/lib*/arm* \
+  /usr/local/lib*/hppa* /usr/local/lib*/mips* /usr/local/lib*/powerpc* /usr/local/lib*/ppc64* /usr/local/lib*/s390* \
   /usr/local/lib*/sh4* /usr/local/lib*/sparc* /usr/local/lib* \
-/opt/lib*/x86_64* /opt/lib*/i386* /opt/lib*/aarch64* /opt/lib*/arm* /opt/lib*/mips* \
+/opt/lib*/x86_64* /opt/lib*/i386* /opt/lib*/aarch64* /opt/lib*/alpha* /opt/lib*/arm* /opt/lib*/hppa* /opt/lib*/mips* \
   /opt/lib*/powerpc* /opt/lib*/ppc64* /opt/lib*/s390* /opt/lib*/sh4* /opt/lib*/sparc* /opt/lib* \
-/opt/local/lib*/x86_64* /opt/local/lib*/i386* /opt/local/lib*/aarch64* /opt/local/lib*/arm* \
-  /opt/local/lib*/mips* /opt/local/lib*/powerpc* /opt/local/lib*/ppc64* /opt/local/lib*/s390* \
+/opt/local/lib*/x86_64* /opt/local/lib*/i386* /opt/local/lib*/aarch64* /opt/local/lib*/alpha* /opt/local/lib*/arm* \
+  /opt/local/lib*/hppa* /opt/local/lib*/mips* /opt/local/lib*/powerpc* /opt/local/lib*/ppc64* /opt/local/lib*/s390* \
   /opt/local/lib*/sh4* /opt/local/lib*/sparc* /opt/local/lib* \
-/lib*/x86_64* /lib*/i386* /lib*/aarch64* /lib*/arm* /lib*/mips* \
+/lib*/x86_64* /lib*/i386* /lib*/aarch64* /lib*/alpha* /lib*/arm* /lib*/hppa* /lib*/mips* \
   /lib*/powerpc* /lib*/ppc64* /lib*/s390* /lib*/sh4* /lib*/sparc* /lib* \
 C:/Boost/lib"
 fi

Bug#881031: Please build libkpmcore6 on Alpha.

[Michael Cree]

Source: kpmcore
Version: 3.2.1-2
Severity: important
Justification: was built in the past
User: debian-al...@lists.debian.org
Usertags: alpha

The latest build of kpmcore [1] did not package libkpmcore6 on Alpha,
and contained a comment in the changelog that "kde dependencies has
never been available since inception of this package" which I do
not believe is true in regards to Alpha.  It is true that the build
did fail once at version 3.2.0-1 due to bug #879024 in the
build-deps.  A better response would have been to version the
build-deps so that kpmcore would not build on Alpha until such time
as the build-deps can be fixed.  As it is, an updated version of the
build-deps are now available on Alpha so please re-enable the
packaging of libkpmcore6 in the build of kpmcore on Alpha.

Thanks,
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=kpmcore=alpha=3.2.1-2=1509942961=0

Bug#881028: notmuch FTBFS on Alpha due to broken gdb

[Michael Cree]

Source: notmuch
Version: 0.25.2-1
Severity: important
Justification: fails to build from source (but built in the past)
User: debian-al...@lists.debian.org
Usertags: ftbfs

notmuch FTBFS on Alpha [1] in the test suite due to a broken gdb.
Please build notmuch on Alpha without the gdb build-depends as is
done on some other architectures. With that change notmuch builds
successfully on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=notmuch=alpha=0.25.2-1=1509996972=0

Bug#879020: further info on emacs25 ftbfs on Alpha

[Michael Cree]

I've been investigating this FTBFS of emacs25 on Alpha.  Interestingly
my manual build on one of the buildds built to completion.  Running the
test manually I cannot get it to fail.  I am using invocations such as:

./debian/build-nox/src/emacs-25.2.2 -batch -L 
./debian/build-src/test/automated/ -l ert -l eieio-tests.el -f 
ert-run-tests-batch-and-exit

So I gave back emacs25 for rebuilding on the buildd and it failed there
again on the same test.  Maybe something about building with sbuild?

Cheers
Michael.

Bug#880640: qtwebkit-opensource-src FTBFS on Alpha; missing logic in arch detection

[Michael Cree]

Source: qtwebkit-opensource-src
Version: 5.212.0~alpha2-5
Severity: important
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

qtwebkit-opensource-src FTBFS on Alpha [1] due missing logic in the
cmake architecture detection logic.  I attach a patch that provides
the missing bits.  With that qtwebkit-opensource-src builds to
completion on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-src=alpha=5.212.0%7Ealpha2-5=1509416346=0
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -57,7 +57,9 @@
 else ()
 string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR} LOWERCASE_CMAKE_SYSTEM_PROCESSOR)
 endif ()
-if (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^arm")
+if (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^alpha")
+set(WTF_CPU_ALPHA 1)
+elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^arm")
 set(WTF_CPU_ARM 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
 set(WTF_CPU_ARM64 1)
--- a/Source/JavaScriptCore/CMakeLists.txt
+++ b/Source/JavaScriptCore/CMakeLists.txt
@@ -1277,7 +1277,8 @@
 list(APPEND JavaScriptCore_HEADERS ${DERIVED_SOURCES_JAVASCRIPTCORE_DIR}/JSReplayInputs.h)
 endif ()
 
-if (WTF_CPU_ARM)
+if (WTF_CPU_ALPHA)
+elseif (WTF_CPU_ARM)
 elseif (WTF_CPU_ARM64)
 elseif (WTF_CPU_HPPA)
 elseif (WTF_CPU_PPC)

Bug#879589: mozjs52 FTBFS on alpha; misdetected arch bitsize, etc.

[Michael Cree]

Source: mozjs52
Version: 52.3.1-7
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

mozjs52 FTBFS on alpha because there is a conflict in determining the
arch bitsize [1], and later on in the build an attempt to load libc.so.6
which does not exist in Alpha Linux.

I attach two patches: one to fix the misdetected bitsize and disable the
tests that are problematic on 64-bit arches (as is done on other 64-bit
arches) and the other to load libc.so.6.1 rather than libc.so.6 when
compiling on Alpha Linux.

With these mozjs52 builds to completion on Alpha.

Cheers
Michael

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mozjs52=alpha=52.3.1-7=150
--- a/js/src/tests/js1_5/Array/regress-157652.js
+++ b/js/src/tests/js1_5/Array/regress-157652.js
@@ -1,4 +1,4 @@
-// |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64|aarch64|ppc64|ppc64le|s390x|mips64/)||Android) -- No test results
+// |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64|aarch64|Alpha|ppc64|ppc64le|s390x|mips64/)||Android) -- No test results
 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
 /* This Source Code Form is subject to the terms of the Mozilla Public
  * License, v. 2.0. If a copy of the MPL was not distributed with this
--- a/js/src/tests/js1_5/Array/regress-330812.js
+++ b/js/src/tests/js1_5/Array/regress-330812.js
@@ -1,4 +1,4 @@
-// |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64|aarch64|ppc64|ppc64le|s390x|mips64/)||Android) -- No test results
+// |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64|aarch64|Alpha|ppc64|ppc64le|s390x|mips64/)||Android) -- No test results
 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
 /* This Source Code Form is subject to the terms of the Mozilla Public
  * License, v. 2.0. If a copy of the MPL was not distributed with this
--- a/js/src/tests/js1_5/Regress/regress-422348.js
+++ b/js/src/tests/js1_5/Regress/regress-422348.js
@@ -1,4 +1,4 @@
-// |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64|aarch64|ppc64|ppc64le|s390x|mips64/)) -- On 64-bit, takes forever rather than throwing
+// |reftest| skip-if(xulRuntime.XPCOMABI.match(/x86_64|aarch64|Alpha|ppc64|ppc64le|s390x|mips64/)) -- On 64-bit, takes forever rather than throwing
 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
 /* This Source Code Form is subject to the terms of the Mozilla Public
  * License, v. 2.0. If a copy of the MPL was not distributed with this
--- a/python/mozbuild/mozbuild/configure/constants.py
+++ b/python/mozbuild/mozbuild/configure/constants.py
@@ -40,7 +40,7 @@
 
 CPU_bitness = {
 'aarch64': 64,
-'Alpha': 32,
+'Alpha': 64,
 'arm': 32,
 'hppa': 32,
 'ia64': 64,
--- a/testing/mozbase/mozinfo/mozinfo/mozinfo.py
+++ b/testing/mozbase/mozinfo/mozinfo/mozinfo.py
@@ -150,7 +150,10 @@
 import errno
 PR_SET_SECCOMP = 22
 SECCOMP_MODE_FILTER = 2
-ctypes.CDLL("libc.so.6", use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
+if processor == 'alpha':
+ctypes.CDLL("libc.so.6.1", use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
+else:
+ctypes.CDLL("libc.so.6", use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
 info['has_sandbox'] = ctypes.get_errno() == errno.EFAULT
 else:
 info['has_sandbox'] = True

Bug#879248: r-cran-nmf FTBFS on some arches because of misuse of detectCores()

[Michael Cree]

Source: r-cran-nmf
Version: 0.20.6-1
Severity: wishlist

r-cran-nmf FTBFS on alpha, sparc64 and the non-linux arches, because
it calls R base function parallel::detectCores() and expects the
result to be an integer, however the detectCores() documentation
states that the result is an integer only if the number of CPU cores
is actually detected, and NA otherwise.  On the above mentioned
systems detectCores() fails to detect the number of CPUs thus returns
NA which leads to the failure to build in r-cran-nmf.

The problem is at line 81 of R/options.R which has:

, pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'

Presumably that code should be modified to assign detectCores() to a
variable and test for NA, and if it is NA just go with one core.

Use of detectCores() is also in R/parallel.R and presumably that
also should be checked for an NA returned value.

Cheers
Michael.

Bug#875288: openjdk-9: java/javac/jar lockups on SMP Alpha

[Michael Cree]

Source: openjdk-9
Version: 9~b181-4
Severity: important
Justification: causes random FTBFS in java packages when built on SMP system
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-CC: John Paul Adrian Glaubitz 

Java, javac and jar can all randomly lockup (and never complete) on an
SMP Alpha system and we have a rather large don't take for building
list of various java packages on the SMP Alpha build daemons.

On a hint from John Paul Adrian Glaubitz I think I have narrowed down
the problem to insufficient memory barriers in file:

src/hotspot/src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp

and attach a patch fixing that.  With the patch installed into a build
of openjdk-9 my subsequent test build of openjdk-9 built to completion
on an SMP system, giving encouragement that the patch indeed fixes the
problem.

(I also have a patch for openjdk-8 but it will take a few days to test
first.)

Cheers,
Michael.
--- openjdk-9-9~b181-orig/src/hotspot/src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp	2017-08-01 21:03:05.0 +1200
+++ openjdk-9-9~b181/src/hotspot/src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp	2017-08-30 20:15:31.454293665 +1200
@@ -56,8 +56,15 @@
 
 #else // PPC
 
+#ifdef __alpha__
+
+#define LIGHT_MEM_BARRIER __sync_synchronize()
+
+#else // __alpha__
+
 #define LIGHT_MEM_BARRIER __asm __volatile ("":::"memory")
 
+#endif // __alpha__
 #endif // PPC
 
 #endif // ARM

Bug#856815: kodi FTBFS on Alpha due to Intel assembler that is easily worked around

[Michael Cree]

On Mon, Mar 13, 2017 at 09:04:15PM +0100, Bálint Réczey wrote:
> > kodi FTBFS on alpha due to Intel specific code [1].
> >
> > I attach a patch that enables generic code to be built rather
> > than Intel specific code and with that kodi builds to completion
> > on Alpha.
> 
> Can kodi run on any alpha machine?

Yes, it runs on my XP1000.  Admittedly it was skipping frames on a
standard definition MPEG file, which is interesting because this
machine can play such files without a problem, but on closer
inspection I see that pulseaudio is taking up over 30% CPU time.
If I could point kodi at alsa directly I expect it would work very
nicely.

> The kodi package is quite big. Would building the package worth it
> considering the space needed on snapshot.d.o, on mirrors, etc?

I presume that the managers of debian-ports have already considered
the space resources of the ports building the archive when they
accepted them into debian-ports.  There are some extremely big
packages already built on Alpha (webkit, libreoffice, etc.) and one
more should not be a problem.

Cheers
Michael.

Bug#856815: kodi FTBFS on Alpha due to Intel assembler that is easily worked around

[Michael Cree]

Source: kodi
Version: 2:17.0+dfsg1-3
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

kodi FTBFS on alpha due to Intel specific code [1].

I attach a patch that enables generic code to be built rather
than Intel specific code and with that kodi builds to completion
on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=kodi=alpha=2%3A17.0%2Bdfsg1-3=1487892844=0
Index: kodi-17.0+dfsg1/xbmc/cores/DllLoader/DllLoader.h
===
--- kodi-17.0+dfsg1.orig/xbmc/cores/DllLoader/DllLoader.h
+++ kodi-17.0+dfsg1/xbmc/cores/DllLoader/DllLoader.h
@@ -23,7 +23,7 @@
 #include "coffldr.h"
 #include "LibraryLoader.h"
 
-#if defined(__linux__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__)
+#if defined(__linux__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__) && !defined(__alpha__)
 #define USE_LDT_KEEPER
 #include "ldt_keeper.h"
 #endif
Index: kodi-17.0+dfsg1/xbmc/cores/DllLoader/ldt_keeper.c
===
--- kodi-17.0+dfsg1.orig/xbmc/cores/DllLoader/ldt_keeper.c
+++ kodi-17.0+dfsg1/xbmc/cores/DllLoader/ldt_keeper.c
@@ -19,7 +19,7 @@
  */
 
 //#ifndef __powerpc__
-#if !defined(__powerpc__) && !defined(__ppc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__)
+#if !defined(__powerpc__) && !defined(__ppc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__) && !defined(__alpha__)
 
 #include "ldt_keeper.h"
 
Index: kodi-17.0+dfsg1/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGL.h
===
--- kodi-17.0+dfsg1.orig/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGL.h
+++ kodi-17.0+dfsg1/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGL.h
@@ -293,7 +293,7 @@ protected:
 
 
 inline int NP2( unsigned x ) {
-#if defined(TARGET_POSIX) && !defined(__POWERPC__) && !defined(__PPC__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__)
+#if defined(TARGET_POSIX) && !defined(__POWERPC__) && !defined(__PPC__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__) && !defined(__alpha__)
   // If there are any issues compiling this, just append a ' && 0'
   // to the above to make it '#if defined(TARGET_POSIX) && 0'
 
Index: kodi-17.0+dfsg1/xbmc/threads/Atomics.cpp
===
--- kodi-17.0+dfsg1.orig/xbmc/threads/Atomics.cpp
+++ kodi-17.0+dfsg1/xbmc/threads/Atomics.cpp
@@ -106,7 +106,7 @@ long cas(volatile long *pAddr, long expe
 ///
 long long cas2(volatile long long* pAddr, long long expectedVal, long long swapVal)
 {
-#if defined(__ppc__) || defined(__powerpc__) || defined(__arm__) || defined(__aarch64__) || defined(__s390x__) // PowerPC and ARM
+#if defined(__ppc__) || defined(__powerpc__) || defined(__arm__) || defined(__aarch64__) || defined(__s390x__) || defined(__alpha__)// PowerPC and ARM
 // Not available/required
 // Hack to allow compilation
   throw "cas2 is not implemented";
Index: kodi-17.0+dfsg1/xbmc/threads/Atomics.h
===
--- kodi-17.0+dfsg1.orig/xbmc/threads/Atomics.h
+++ kodi-17.0+dfsg1/xbmc/threads/Atomics.h
@@ -22,7 +22,7 @@
 
 //! @todo Inline these methods
 long cas(volatile long *pAddr, long expectedVal, long swapVal);
-#if !defined(__ppc__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__s390x__)
+#if !defined(__ppc__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__s390x__) && !defined(__alpha__)
 long long cas2(volatile long long* pAddr, long long expectedVal, long long swapVal);
 #endif
 long AtomicIncrement(volatile long* pAddr);
Index: kodi-17.0+dfsg1/xbmc/utils/MathUtils.h
===
--- kodi-17.0+dfsg1.orig/xbmc/utils/MathUtils.h
+++ kodi-17.0+dfsg1/xbmc/utils/MathUtils.h
@@ -37,7 +37,8 @@
 defined(__mips__) || \
 defined(__arm__) || \
 defined(__s390x__) || \
-defined(__aarch64__)
+defined(__aarch64__) || \
+defined(__alpha__)
   #define DISABLE_MATHUTILS_ASM_ROUND_INT
 #endif
 

Bug#856177: lua-sandbox FTBFS on alpha (and hppa) due to test suite failure.

[Michael Cree]

Source: lua-sandbox
Version: 1.2.1-4
Severity: wishlist
User: debian-al...@lists.debian.org
Usertags: alpha

lua-sandbox FTBFS on alpha due to a test-suite failure [1]

The following tests FAILED:
 11 - test_heka_sandbox (Failed)

Running that test manually reveals the failure occurs randomly at
line 376 and sometimes at line 464, both of which are asserts that
the mean or standard deviation in time incurred during running tests
is not zero.

The test suite uses the posix clock (clock_gettime()) but on Alpha
that clock has a resolution of the timer interrupt which is at best
about 1ms.  Since the test runs much faster than this a zero time
delta is often measured which the test suite detects and considers
to be a reason for failure.  On hppa the build fails at the same
test [2] and I presume it is probably for similar reasons.

Upstream is aware that there is an issue [3] however it seems one
cannot comment further there without obtaining a github login.

As an experiment I modified the code in src/util/util.c, function
lsb_get_time(), to be:

unsigned long long lsb_get_time()
{
#if defined(__alpha__) && defined(__linux__)
  return __builtin_alpha_rpcc() & 0xULL;
#elif defined(HAVE_CLOCK_GETTIME)
  struct timespec ts;
  clock_gettime(CLOCK_MONOTONIC, );
  return ts.tv_sec * 10ULL + ts.tv_nsec;
#elif ...

to use the processor cycle counter on Alpha which is a 32 bit register
that is incremented every CPU clock cycle.  With the above the test
suite passes on Alpha when run on a UP system.  However I am not
comfortable to recommend the above as a fix because:

1) It might break on an SMP system where every CPU has its own
cycle counter and there is no guarantee they are in sync, and no
guarantee that the start time is read on the same CPU as the stop
time.

2) The counter wraps back to zero after the 32 bits are exhuasted,
a period of about 7 to 8s on the system I tested, and only 3 to 4s
on the buildds.  If the above is used in any timing test longer than
that it could break.

3) The function might be exported from the library and the above might
break intended uses of the function.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=lua-sandbox=alpha=1.2.1-4=1487927865=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=lua-sandbox=hppa=1.2.1-4=1483652248=0
[3] https://github.com/mozilla-services/lua_sandbox/issues/185

Bug#840817: mpi4py FTBFS on alpha [blah, blah, blah...]

[Michael Cree]

I see that this bug is fallout from trying to fix #817884, which was
also reported as #817988 where it was noted that "Dynamic linking uses
the _abiname_, which is libm.so.6 in this case, but is may be
libm.so.6.1 or libm.so.0.3 in other cases."  I note that the patch
applied to mpi4py in #817884 ignored that last clause therefore
broke the build on arches that do not have libm.so.6 as the
abiname.

Cheers
Michael.

Bug#840817: mpi4py FTBFS on alpha: libm.so.6 does not exist on Alpha (but libm.so.6.1 does)

[Michael Cree]

Source: mpi4py
Version: 2.0.0-2
Severity: important
Justification: fails to build from source (but built in the past)
User: debian-al...@lists.debian.org
Usertags: ftbfs

mpi4py FTBFS on Alpha with the following failure in the test suite [1]:

FAIL: testDL1 (test_dl.TestDL)
--
Traceback (most recent call last):
  File "/<>/test/test_dl.py", line 18, in testDL1
  self.assertTrue(handle != 0)
  AssertionError: False is not true


In tests/test_dl.py is:

def testDL1(self):
if sys.platform == 'darwin':
libm = 'libm.dylib'
else:
libm = 'libm.so.6'

And it proceeds to try to open libm which on Alpha fails because
the C library version is 6.1, not 6.  The code should really be
detecting the CPU and if it is Alpha should use 'libm.so.6.1' as
the math library.  (I presume it should also be checking for the
hurd and kfreebsd as they also have different C library versions,
but those builds don't get far enough to see this problem.)

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mpi4py=alpha=2.0.0-2=1473761717

Bug#836374: marisa FTBFS on Alpha: misdetected architecture word size.

[Michael Cree]

Source: marisa
Version: 0.2.4-8
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

marisa FTBFS on Alpha due a test suite failure:

make[4]: Entering directory '/«PKGBUILDDIR»/tests'
FAIL: base-test

This test suite failure occurs because Alpha is not detected as a
64-bit architecture.

I attach a patch to include support for Alpha.

Cheers
Michael.
Index: marisa-0.2.4/lib/marisa/base.h
===
--- marisa-0.2.4.orig/lib/marisa/base.h
+++ marisa-0.2.4/lib/marisa/base.h
@@ -31,7 +31,8 @@ typedef uint64_t marisa_uint64;
 #if defined(_WIN64) || defined(__amd64__) || defined(__x86_64__) || \
 defined(__ia64__) || defined(__ppc64__) || defined(__powerpc64__) || \
 ( defined(__sparc__) && defined(__arch64__) ) || \
-defined(__mips64) || defined(__aarch64__) || defined(__s390x__)
+defined(__mips64) || defined(__aarch64__) || defined(__s390x__) || \
+defined(__alpha__)
  #define MARISA_WORD_SIZE 64
 #else  // defined(_WIN64), etc.
  #define MARISA_WORD_SIZE 32

Bug#827348: qtscript-opensource-src FTBFS on Alpha; double value incorrect in last bit in test suite

[Michael Cree]

Source: qtscript-opensource-src
Version: 5.6.1+dfsg-2
Severity: important
Justification: fails to build from source but built in past
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

qtscript-opensource-src FTBFS on Alpha due to a test suite failure [1]:

FAIL!  : tst_QScriptJsTestSuite::ecma_2/RegExp(/\B/.lastIndex) Compared values 
are not the same
   Actual   (actual): "1.7976931348623155e+308"
   Expected (expect): "1.7976931348623157e+308"
   Loc: [ecma_2/RegExp/properties-002.js(583)]

This is the result of a double precision calculation that has rounded
the last bit of the calculation in the wrong direction.  That does not
seem sufficient reason to completely fail the build so I attach a
patch that disables this test and hope you would consider including
it in the next upload of qtscript-opensource-src.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=qtscript-opensource-src=alpha=5.6.1%2Bdfsg-2=1465838369
Index: qtscript-opensource-src-5.6.1+dfsg/tests/auto/qscriptjstestsuite/skip.txt
===
--- qtscript-opensource-src-5.6.1+dfsg.orig/tests/auto/qscriptjstestsuite/skip.txt
+++ qtscript-opensource-src-5.6.1+dfsg/tests/auto/qscriptjstestsuite/skip.txt
@@ -7,6 +7,7 @@ regress-322135-03.js | takes forever
 regress-322135-04.js | takes forever
 ecma/Expressions/11.4.7-02.js | Fails on some architectures
 ecma/TypeConversion/9.3.1-3.js | Fails on some architectures
+ecma_2/RegExp/properties-002.js | Fails on Alpha
 ecma_3/Array/regress-387501.js | Produces wrong error message
 ecma_3/RegExp/regress-375715-04.js | bug
 ecma_3/RegExp/regress-289669.js | Can fail due to relying on wall-clock time

Bug#827021: gfarm FTBFS on alpha: conflict in signal names

[Michael Cree]

Source: gfarm
Version: 2.6.11+dfsg-1
Severity: important
Justification: fails to build from source but built in the past
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

gfarm FTBFS on alpha with [1]:

cc -D_REENTRANT -pthread -g -O2 -fPIE -Wformat -Werror=format-security -Wall 
-D_GNU_SOURCE -I../../include -I../../include -DCOMPAT_GFARM_2_3 
-I../../lib/libgfarm/gfutil -I../../lib/libgfarm/gfsl 
-I../../lib/libgfarm/gfarm -I.  -I/usr/include/postgresql  
-DGFMD_CONFIG='"/etc/gfmd.conf"' -Wdate-time -D_FORTIFY_SOURCE=2  -c -o gfmd.o 
gfmd.c
gfmd.c: In function 'sigs_handler':
gfmd.c:1423:3: error: duplicate case value
   case SIGPWR:
   ^
gfmd.c:1399:3: error: previously used here
   case SIGINFO:
   ^


This is because on Alpha SIGPWR is defined by the system headers to
be the same value as SIGINFO.

I attach a patch that conditional includes the SIGPWR case only if
SIGPWR is defined AND (SIGINFO is not defined OR SIGINFO is defined
and not the same value as SIGPWR).  This fixes the FTBFS on Alpha.

Cheers
Michael

[1] 
https://buildd.debian.org/status/fetch.php?pkg=gfarm=alpha=2.6.11%2Bdfsg-1=1465135023
Index: gfarm-2.6.11+dfsg/server/gfmd/gfmd.c
===
--- gfarm-2.6.11+dfsg.orig/server/gfmd/gfmd.c
+++ gfarm-2.6.11+dfsg/server/gfmd/gfmd.c
@@ -1420,8 +1420,10 @@ sigs_handler(void *p)
 		case SIGXCPU:
 		case SIGXFSZ:
 #ifdef SIGPWR
+#if !defined(SIGINFO) || (SIGPWR != SIGINFO)
 		case SIGPWR:
 #endif
+#endif
 			/* terminate gfmd */
 			break;
 		default:

Bug#823133: subversion FTBFS on Alpha: misaligned strings in the test suite

[Michael Cree]

On Mon, May 02, 2016 at 12:01:18AM -0400, James McCoy wrote:
> Thanks for the analysis and working on a patch.  I'll note that
> _Alignas, if it had worked, would likely have been too new a compiler
> feature to use.
> 
> It looks like Debian's ia64 porterbox is still running, so I can try
> reproducing the problem there (using prctl to force SIGBUS) and then
> fiddling around with the code.

Here goes further analysis.  Running utf-test under gdb I set a break
point at line 807 of utf-test.c and after a number of iterations of
the enclosing loop I get:

Breakpoint 1, test_utf_conversions (pool=0x20001018028)
at 
/extra/mjc/debian/subversion/subversion-1.9.4/subversion/tests/libsvn_subr/utf-test.c:807
807   SVN_ERR_ASSERT(0 == strcmp(result->data, tc->result));
(gdb) print tc->source
$20 = 0x120003117 "\330\064\335\036"
(gdb) print result->data
$21 = 0x20001018218 "\360\220\204\236"
(gdb) print tc->result
$22 = 0x12000373c "\360\235\204\236"
(gdb) cont
Continuing.
svn_tests: E235000: In file 
'/extra/mjc/debian/subversion/subversion-1.9.4/subversion/tests/libsvn_subr/utf-test.c'
 line 807: assertion failed (0 == strcmp(result->data, tc->result))
FAIL:  lt-utf-test 9: test svn_utf__utf{16,32}_to_utf8
[Inferior 1 (process 24827) exited with code 01]



On this iteration I believe it has just read line 769 of utf-test.c,
i.e., this line:

{ UTF_16_BE, "\xD8\x34" "\xDD\x1E" "\0\0", "\xf0\x9d\x84\x9e" }, /* 
U+01D11E */

into variable tc, and it passes tc->source (which is at address
0x120003117, i.e., misaligned for apr_uint16_t type) to
svn_utf__utf16_to_utf8() and the result is incorrect and results in
the failed assert.

On previous iterations of the test loop it happened to pass the test
even with misaligned tc->source strings, and it is instructive to
disassemble svn_utf__utf16_to_utf8() to see why this can happen:

1040svn_error_t *
1041svn_utf__utf16_to_utf8(const svn_string_t **result,
1042   const apr_uint16_t *utf16str,
1043   apr_size_t utf16len,
1044   svn_boolean_t big_endian,
1045   apr_pool_t *result_pool,
1046   apr_pool_t *scratch_pool)
1047{
   0x020ed990 <+0>: ldahgp,12(t12)
   0x020ed994 <+4>: lda gp,10976(gp)
   0x020ed998 <+8>: lda sp,-160(sp)
   0x020ed9a0 <+16>:stq s0,8(sp)
   0x020ed9a4 <+20>:mov a1,s0
   0x020ed9a8 <+24>:stq s1,16(sp)
   0x020ed9ac <+28>:mov a2,s1
   0x020ed9b0 <+32>:stq ra,0(sp)
   0x020ed9b4 <+36>:stq s2,24(sp)
   0x020ed9b8 <+40>:stq s3,32(sp)
   0x020ed9bc <+44>:stq s4,40(sp)
   0x020ed9c0 <+48>:stq s5,48(sp)
   0x020ed9c4 <+52>:stq fp,56(sp)
   0x020ed9c8 <+56>:stq a0,152(sp)
   0x020ed9cc <+60>:stq a3,128(sp)
   0x020ed9d0 <+64>:stq a4,144(sp)

1048  static const apr_uint16_t endiancheck = 0xa55a;
1049  const svn_boolean_t arch_big_endian =
1050(((const char*))[sizeof(endiancheck) - 1] == '\x5a');
1051  const svn_boolean_t swap_order = (!big_endian != !arch_big_endian);
1052
1053  apr_uint16_t lead_surrogate;
1054  apr_size_t length;
1055  apr_size_t offset;
1056  svn_membuf_t ucs4buf;
1057  svn_membuf_t resultbuf;
1058  svn_string_t *res;
1059
1060  if (utf16len == SVN_UTF__UNKNOWN_LENGTH)
   0x020ed99c <+12>:lda t0,1(a2)
   0x020ed9d4 <+68>:beq t0,0x20edbd0 


1061{
1062  const apr_uint16_t *endp = utf16str;
1063  while (*endp++)
   0x020edbd0 <+576>:   mov a1,s1
   0x020edbd4 <+580>:   unop
   0x020edbe0 <+592>:   lda s1,2(s1)
   0x020edbe4 <+596>:   lda t1,-2(s1)
   0x020edbe8 <+600>:   ldq_u   t0,-2(s1)
   0x020edbec <+604>:   extwl   t0,t1,t0
   0x020edbf0 <+608>:   bne t0,0x20edbe0 


1064;


In the loop immediately above (lines 1061--1064 of the source code)
we see the code is walking through the utf16 string (register a1 holds
argument 1, i.e., utf16str, which is first copied to register s1 and
used as the pointer incremented in the loop).  The load instructions
to get the utf16 character are the two instructions:

   0x020edbe8 <+600>:   ldq_u   t0,-2(s1)
   0x020edbec <+604>:   extwl   t0,t1,t0

The ldq_u zeroes the lowest three bits of the address and loads the
quadword (64-bit word) from the resultant address, and the extwl
extracts the 16-bit word identified by the lowest three bits of the
address (which are in register t1) from the quadword in register t0,
however this is only correct if the lowest three bits are not 0x7.

If the source string address has the lowest three bits 

Bug#823133: oops, patch is wrong.

[Michael Cree]

Control: tags -1 - patch

Hi,

Sorry, patch I attached for subversion FTBFS is incorrect.  (Thought I
had test built it but got mixed up with some other packages with
similar problem that I had successfully run test builds on.)  The
Alignas does not work at that position in the code, however I am
confident of the analysis I provided in the original bug report.

It's now late here so I will get back with a correct patch maybe
tomorrow (and will make sure that it is indeed subversion that I have
run the test build on!).

Cheers
Michael.

Bug#823133: subversion FTBFS on Alpha: misaligned strings in the test suite

[Michael Cree]

Source: subversion
Version: 1.9.4-1
Severity: important
Justification: fails to build from source (but built in the past)
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

subversion FTBFS on Alpha due to a test suite failure [1]:

START: utf-test
PASS:  lt-utf-test 1: test is_valid/last_valid
PASS:  lt-utf-test 2: test last_valid/last_valid2
PASS:  lt-utf-test 3: test svn_utf_cstring_to_utf8_ex2
PASS:  lt-utf-test 4: test svn_utf_cstring_from_utf8_ex2
PASS:  lt-utf-test 5: test svn_utf__normcmp
PASS:  lt-utf-test 6: test svn_utf__glob
PASS:  lt-utf-test 7: test svn_utf__fuzzy_escape
PASS:  lt-utf-test 8: test svn_utf__is_normalized
svn_tests: E235000: In file 
'/«PKGBUILDDIR»/subversion/tests/libsvn_subr/utf-test.c' line 807: assertion 
failed (0 == strcmp(result->data, tc->result))
FAIL:  lt-utf-test 9: test svn_utf__utf{16,32}_to_utf8
END: utf-test
ELAPSED: utf-test 0:00:00.603655

This failure occurs because the test suite allocates char aligned
strings in function test_utf_conversions() of file
subversion/tests/libsvn_subr/utf-test.c and passes those strings
to functions svn_utf__utf16_to_utf8() and svn_utf__utf32_to_utf8()
which are defined (in file subversion/libsvn_subr/utf.c) to take
apr_uint32_t * and apr_uint16_t * args respectively.  On
architectures with strict alignment requirements this is undefined
behaviour.  On Alpha, gcc likes to add bugs..., I mean, _optimise_
code, when the args are declared to be aligned by using a particular
CPU load instruction that neither traps nor gives correct results
if the args are not actually aligned.

I attach a patch that aligns the test strings in utf-test.c to be
aligned to apr_uint32_t (i.e. 32-bit alignment).  With that patch
subversion builds successfully to completion on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=subversion=alpha=1.9.4-1=1461928473
Index: subversion-1.9.4/subversion/tests/libsvn_subr/utf-test.c
===
--- subversion-1.9.4.orig/subversion/tests/libsvn_subr/utf-test.c   
2016-05-01 21:05:58.763536825 +1200
+++ subversion-1.9.4/subversion/tests/libsvn_subr/utf-test.c2016-05-01 
21:05:58.755722518 +1200
@@ -745,7 +745,7 @@
   {
 svn_boolean_t sixteenbit;
 svn_boolean_t bigendian;
-const char *source;
+const _Alignas(apr_int32_t) char *source;
 const char *result;
   } tests[] = {
 

Bug#822848: mpd FTBFS on Alpha; misaligned arrays in the test suite

[Michael Cree]

Source: mpd
Version: 0.19.14-2
Severity: important
Justification: fails to build form source (but built in the past)
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

mpd FTBFS on Alpha with a failure in the test suite [1]:

FAIL: test/test_byte_reverse


.F...


!!!FAILURES!!!
Test Results:
Run:  4   Failures: 1   Errors: 0


1) test: ByteReverseTest::TestByteReverse2 (F) line: 58 
test/test_byte_reverse.cxx
assertion failed
- Expression: strcmp(result, (const char *)dest) == 0


This occurs because the test suite (in test/test_byte_reversal.cxx)
allocates static char arrays and passes the char arrays to functions
whose respective arguments were declared to be uint16_t *, etc., in
the main code.

This is in the realm of undefined behaviour on architectures with
strict memory alignment requirements.  Although the test only fails
on Alpha (because Alpha has a particular CPU load instruction that
gcc likes to use to add bugs ..., ahem,  optimise the code on the
assumption of alignment) it is potentially a latent bug for other
architectures with strict alignment requirements.

Since the code is compiled with the c++11 standard I attach a patch
that modifies the test suite to align the non-compliant strings with
the alignas() attribute.  The test suite now passes on Alpha with
that patch.

Cheers
Michael

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mpd=alpha=0.19.14-2=1461542099
Index: mpd-0.19.14/test/test_byte_reverse.cxx
===
--- mpd-0.19.14.orig/test/test_byte_reverse.cxx
+++ mpd-0.19.14/test/test_byte_reverse.cxx
@@ -49,9 +49,9 @@ CPPUNIT_TEST_SUITE_REGISTRATION(ByteReve
 void
 ByteReverseTest::TestByteReverse2()
 {
-	static const char src[] = "123456";
+	static const char src[] alignas(uint16_t) = "123456";
 	static const char result[] = "214365";
-	static uint8_t dest[ARRAY_SIZE(src)];
+	static uint8_t dest[ARRAY_SIZE(src)] alignas(uint16_t);
 
 	reverse_bytes(dest, (const uint8_t *)src,
 		  (const uint8_t *)(src + ARRAY_SIZE(src) - 1), 2);
@@ -73,9 +73,9 @@ ByteReverseTest::TestByteReverse3()
 void
 ByteReverseTest::TestByteReverse4()
 {
-	static const char src[] = "12345678";
+	static const char src[] alignas(uint32_t) = "12345678";
 	static const char result[] = "43218765";
-	static uint8_t dest[ARRAY_SIZE(src)];
+	static uint8_t dest[ARRAY_SIZE(src)] alignas(uint32_t);
 
 	reverse_bytes(dest, (const uint8_t *)src,
 		  (const uint8_t *)(src + ARRAY_SIZE(src) - 1), 4);

Bug#822772: vxl FTBFS on Alpha; patch fix_alphacomp.patch needs updating.

[Michael Cree]

Source: vxl
Version: 1.17.0.dfsg2-4
Severity: important
Justification: fails to build from source (but built in past)
User: debian-al...@lists.debian.org
Usertags: alpha

vxl FTBFS on Alpha with [1]:

cd /«PKGBUILDDIR»/obj-alpha-linux-gnu/vcl/tests && /usr/bin/c++   
-DVXL_LEGACY_ERROR_REPORTING -DVXL_WARN_DEPRECATED -DVXL_WARN_DEPRECATED_ONCE 
-I/«PKGBUILDDIR»/obj-alpha-linux-gnu/vcl -I/«PKGBUILDDIR»/vcl 
-I/«PKGBUILDDIR»/obj-alpha-linux-gnu/core -I/«PKGBUILDDIR»/core  -g -O2 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -o 
CMakeFiles/vcl_test_all.dir/test_iterator.o -c 
/«PKGBUILDDIR»/vcl/tests/test_iterator.cxx
In file included from /«PKGBUILDDIR»/v3p/Qv/QvLib.cxx:69:0:
/«PKGBUILDDIR»/v3p/Qv/QvDict.cxx: In member function 'QvDictEntry*& 
QvDict::findEntry(const char*) const':
/«PKGBUILDDIR»/v3p/Qv/QvDict.cxx:97:24: error: 'intptr_t' was not declared in 
this scope
 entry = [ (intptr_t)key % tableSize];

In the file v3p/Qv/QvDict.cxx there is some conditional compilation
depending on the macro __alpha, presumably put there to support
Alpha OSF1 Unix, but is incorrect for Alpha Linux.  The first hunk
in the patch debian/patches/fix_alphacomp.patch attempts to correct
this but botches the fix. The best solution is to entirely remove
the conditional compilation on the macro __alpha and leave Alpha
Linux to use the generic Linux compilation path.  I attach an updated
fix_alphacomp.patch.  With that vxl builds to completion on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=vxl=alpha=1.17.0.dfsg2-4=1460289377
Description: __alpha is a processor, not an OS
Author: Mathieu Malaterre 
Last-Update: 2011-12-12
Forwarded: http://sourceforge.net/mailarchive/message.php?msg_id=28569493
Bug: https://sourceforge.net/apps/trac/vxl/ticket/66

Index: vxl-1.17.0.dfsg2/v3p/Qv/QvDict.cxx
===
--- vxl-1.17.0.dfsg2.orig/v3p/Qv/QvDict.cxx
+++ vxl-1.17.0.dfsg2/v3p/Qv/QvDict.cxx
@@ -8,9 +8,7 @@
 #  include  /* for malloc and friends */
 # endif
 #else
-# if defined(__alpha) /* there is no inttypes.h here */
-   typedef unsigned long intptr_t;
-# elif defined(__CYGWIN__)
+# if defined(__CYGWIN__)
 #  include  /* for intptr_t on Cygwin */
 # elif defined(__BORLANDC__)
 #  if __BORLANDC__ < 0x0560
Index: vxl-1.17.0.dfsg2/core/vil/vil_stream_url.cxx
===
--- vxl-1.17.0.dfsg2.orig/core/vil/vil_stream_url.cxx
+++ vxl-1.17.0.dfsg2/core/vil/vil_stream_url.cxx
@@ -25,7 +25,7 @@
 # include 
 # include// htons()
 # ifdef __alpha
-#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
+//#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
 # endif
 # define SOCKET int
 #elif defined (VCL_WIN32) && !defined(__CYGWIN__)
Index: vxl-1.17.0.dfsg2/core/vil1/vil1_stream_url.cxx
===
--- vxl-1.17.0.dfsg2.orig/core/vil1/vil1_stream_url.cxx
+++ vxl-1.17.0.dfsg2/core/vil1/vil1_stream_url.cxx
@@ -24,7 +24,7 @@
 # include 
 # include// htons()
 # ifdef __alpha
-#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
+//#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
 # endif
 # define SOCKET int
 #elif defined (VCL_WIN32) && !defined(__CYGWIN__)
Index: vxl-1.17.0.dfsg2/core/vul/vul_url.cxx
===
--- vxl-1.17.0.dfsg2.orig/core/vul/vul_url.cxx
+++ vxl-1.17.0.dfsg2/core/vul/vul_url.cxx
@@ -27,7 +27,7 @@
 # include 
 # include// htons()
 # ifdef __alpha
-#  include   // htons() [ on e.g. DEC alpha, htons is in machine/endian.h ]
+//#  include   // htons() [ on e.g. DEC alpha, htons is in machine/endian.h ]
 # endif
 # define SOCKET int
 

Bug#815124: webkit2gtk FTBFS on alpha; configure code not detecting arch properly

[Michael Cree]

On Fri, Feb 19, 2016 at 10:06:35AM +0200, Alberto Garcia wrote:
> On Fri, Feb 19, 2016 at 07:36:38PM +1300, Michael Cree wrote:
> 
> > webkit2gtk FTBFS on alpha due to the configure code not fully
> > configuring the build for the arch.  I attach a patch which fixes
> > the issue.
> 
> Applied, thanks! It will go in the next upload.

Thanks.  Just confirming that the test build of 2.10.6-1 with that
patch I set going has now built to completion.

Michael.

Bug#815124: webkit2gtk FTBFS on alpha; configure code not detecting arch properly

[Michael Cree]

Source: webkit2gtk
Version: 2.10.6-1
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: ftbfs

webkit2gtk FTBFS on alpha due to the configure code not fully
configuring the build for the arch.  I attach a patch which fixes
the issue.

Regards
Michael.
Index: webkit2gtk-2.10.6/CMakeLists.txt
===
--- webkit2gtk-2.10.6.orig/CMakeLists.txt
+++ webkit2gtk-2.10.6/CMakeLists.txt
@@ -89,6 +89,8 @@ if (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MAT
 set(WTF_CPU_ARM 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
 set(WTF_CPU_ARM64 1)
+elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "alpha*")
+set(WTF_CPU_ALPHA 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^mips")
 set(WTF_CPU_MIPS 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "sh4")
Index: webkit2gtk-2.10.6/Source/JavaScriptCore/CMakeLists.txt
===
--- webkit2gtk-2.10.6.orig/Source/JavaScriptCore/CMakeLists.txt
+++ webkit2gtk-2.10.6/Source/JavaScriptCore/CMakeLists.txt
@@ -1152,6 +1152,7 @@ endif ()
 
 if (WTF_CPU_ARM)
 elseif (WTF_CPU_ARM64)
+elseif (WTF_CPU_ALPHA)
 elseif (WTF_CPU_HPPA)
 elseif (WTF_CPU_PPC)
 elseif (WTF_CPU_PPC64)
Index: webkit2gtk-2.10.6/Source/WTF/wtf/Platform.h
===
--- webkit2gtk-2.10.6.orig/Source/WTF/wtf/Platform.h
+++ webkit2gtk-2.10.6/Source/WTF/wtf/Platform.h
@@ -346,7 +346,7 @@
 
 #endif /* ARM */
 
-#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64)
+#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64) || CPU(ALPHA)
 #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
 #endif
 

Bug#800840: ecasound FTBFS on Alpha: use of infinities despite compilation with -ffast-math

[Michael Cree]

Source: ecasound
Version: 2.9.1-7
Severity: important
Justification: fails to build from source but built in the past
User: debian-al...@lists.debian.org
Usertags: ftbfs

Ecasound FTBFS on Alpha due to a test-suite failure [1]:

make  check-TESTS
make[5]: Entering directory '/«PKGBUILDDIR»/libecasound'
make[6]: Entering directory '/«PKGBUILDDIR»/libecasound'
../test-driver: line 107: 22820 Floating point exception"$@" > $log_file 2>&1
FAIL: libecasound_tester

Running the test suite under gdb reveals the place of the floating
point exception to be:

#0  0x000120114d30 in GENERIC_OSCILLATOR::set_parameter (this=0x12022ec10, 
param=, value=0) at osc-gen.cpp:208

which is on the line of code:

loop_length_rep = 1.0f / frequency();

i.e., a division by frequency() after setting frequency to zero, thus
a division by zero.  But ecasound is compiled with -ffast-math, which
according to the gcc manual in turn sets -ffinite-math-only which is
a guarantee to the compiler that all floating point calculations are
finite.  On Alpha abusing that guarantee results in a floating point
exception and program termination.

Assuming it is intended that frequencies can be zero I attach a patch
that protects against the division by zero.  With that ecasound builds
to completion on Alpha.

(In the patch I also assume that frequencies are non-negative thus
there is no possibility of -0.0 as a frequency.)

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ecasound=alpha=2.9.1-7=1440432975
Index: ecasound-2.9.1/libecasound/osc-gen.cpp
===
--- ecasound-2.9.1.orig/libecasound/osc-gen.cpp
+++ ecasound-2.9.1/libecasound/osc-gen.cpp
@@ -205,7 +205,10 @@ void GENERIC_OSCILLATOR::set_parameter(i
   switch (param) {
   case 1: 
 frequency(value);
-loop_length_rep = 1.0f / frequency(); // length of one wave in seconds
+if (frequency() == 0.0)
+  loop_length_rep = INFINITY;   // Protect against div by zero
+else
+  loop_length_rep = 1.0f / frequency(); // length of one wave in seconds
 break;
 
   case 2: 

Bug#800716: freerdp FTBFS on Alpha; misaligned wchar string in test suite

[Michael Cree]

Source: freerdp
Version: 1.1.0~git20140921.1.440916e+dfsg1-5
Severity: important
Justification: fails to build from source (but built in past)
User: debian-al...@lists.debian.org
Usertags: alpha

Freerdp FTBFS on Alpha with a failure in the test suite [1]:

  Start 65: TestUnicodeConversion
65/90 Test #65: TestUnicodeConversion ...***Failed0.00 sec

Running the test suite manually reveals that the results are actually
correct, it is the comparison routine that returns a failure despite
correct results.   This comes about because the comparison routine
(_wcscmp()) expects arguments as WCHAR, however the reference string
is declared BYTE, thus gets byte alignment not wchar alignment.

The attached patch declares all reference strings with the new
C11 _Alignas keyword.  With that freerdp compiles to completion on
Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=freerdp=alpha=1.1.0~git20140921.1.440916e%2Bdfsg1-5=1442015809
Index: freerdp-1.1.0~git20140921.1.440916e+dfsg1/winpr/libwinpr/crt/test/TestUnicodeConversion.c
===
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/winpr/libwinpr/crt/test/TestUnicodeConversion.c
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/winpr/libwinpr/crt/test/TestUnicodeConversion.c
@@ -1,5 +1,6 @@
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,19 +20,19 @@
 /* Letters */
 
 static BYTE c_cedilla_UTF8[] = "\xC3\xA7\x00";
-static BYTE c_cedilla_UTF16[] = "\xE7\x00\x00\x00";
+static _Alignas(WCHAR) BYTE c_cedilla_UTF16[] = "\xE7\x00\x00\x00";
 static int c_cedilla_cchWideChar = 2;
 static int c_cedilla_cbMultiByte = 3;
 
 /* English */
 
 static BYTE en_Hello_UTF8[] = "Hello\0";
-static BYTE en_Hello_UTF16[] = "\x48\x00\x65\x00\x6C\x00\x6C\x00\x6F\x00\x00\x00";
+static _Alignas(WCHAR) BYTE en_Hello_UTF16[] = "\x48\x00\x65\x00\x6C\x00\x6C\x00\x6F\x00\x00\x00";
 static int en_Hello_cchWideChar = 6;
 static int en_Hello_cbMultiByte = 6;
 
 static BYTE en_HowAreYou_UTF8[] = "How are you?\0";
-static BYTE en_HowAreYou_UTF16[] = "\x48\x00\x6F\x00\x77\x00\x20\x00\x61\x00\x72\x00\x65\x00\x20\x00"
+static _Alignas(WCHAR) BYTE en_HowAreYou_UTF16[] = "\x48\x00\x6F\x00\x77\x00\x20\x00\x61\x00\x72\x00\x65\x00\x20\x00"
 		"\x79\x00\x6F\x00\x75\x00\x3F\x00\x00\x00";
 static int en_HowAreYou_cchWideChar = 13;
 static int en_HowAreYou_cbMultiByte = 13;
@@ -39,12 +40,12 @@ static int en_HowAreYou_cbMultiByte = 13
 /* French */
 
 static BYTE fr_Hello_UTF8[] = "Allo\0";
-static BYTE fr_Hello_UTF16[] = "\x41\x00\x6C\x00\x6C\x00\x6F\x00\x00\x00";
+static _Alignas(WCHAR) BYTE fr_Hello_UTF16[] = "\x41\x00\x6C\x00\x6C\x00\x6F\x00\x00\x00";
 static int fr_Hello_cchWideChar = 5;
 static int fr_Hello_cbMultiByte = 5;
 
 static BYTE fr_HowAreYou_UTF8[] = "\x43\x6F\x6D\x6D\x65\x6E\x74\x20\xC3\xA7\x61\x20\x76\x61\x3F\x00";
-static BYTE fr_HowAreYou_UTF16[] = "\x43\x00\x6F\x00\x6D\x00\x6D\x00\x65\x00\x6E\x00\x74\x00\x20\x00"
+static _Alignas(WCHAR) BYTE fr_HowAreYou_UTF16[] = "\x43\x00\x6F\x00\x6D\x00\x6D\x00\x65\x00\x6E\x00\x74\x00\x20\x00"
 		"\xE7\x00\x61\x00\x20\x00\x76\x00\x61\x00\x3F\x00\x00\x00";
 static int fr_HowAreYou_cchWideChar = 15;
 static int fr_HowAreYou_cbMultiByte = 16;
@@ -52,12 +53,12 @@ static int fr_HowAreYou_cbMultiByte = 16
 /* Russian */
 
 static BYTE ru_Hello_UTF8[] = "\xD0\x97\xD0\xB4\xD0\xBE\xD1\x80\xD0\xBE\xD0\xB2\xD0\xBE\x00";
-static BYTE ru_Hello_UTF16[] = "\x17\x04\x34\x04\x3E\x04\x40\x04\x3E\x04\x32\x04\x3E\x04\x00\x00";
+static _Alignas(WCHAR) BYTE ru_Hello_UTF16[] = "\x17\x04\x34\x04\x3E\x04\x40\x04\x3E\x04\x32\x04\x3E\x04\x00\x00";
 static int ru_Hello_cchWideChar = 8;
 static int ru_Hello_cbMultiByte = 15;
 
 static BYTE ru_HowAreYou_UTF8[] = "\xD0\x9A\xD0\xB0\xD0\xBA\x20\xD0\xB4\xD0\xB5\xD0\xBB\xD0\xB0\x3F\x00";
-static BYTE ru_HowAreYou_UTF16[] = "\x1A\x04\x30\x04\x3A\x04\x20\x00\x34\x04\x35\x04\x3B\x04\x30\x04"
+static _Alignas(WCHAR) BYTE ru_HowAreYou_UTF16[] = "\x1A\x04\x30\x04\x3A\x04\x20\x00\x34\x04\x35\x04\x3B\x04\x30\x04"
 		"\x3F\x00\x00\x00";
 static int ru_HowAreYou_cchWideChar = 10;
 static int ru_HowAreYou_cbMultiByte = 17;
@@ -66,14 +67,14 @@ static int ru_HowAreYou_cbMultiByte = 17
 
 static BYTE ar_Hello_UTF8[] = "\xD8\xA7\xD9\x84\xD8\xB3\xD9\x84\xD8\xA7\xD9\x85\x20\xD8\xB9\xD9"
 		"\x84\xD9\x8A\xD9\x83\xD9\x85\x00";
-static BYTE ar_Hello_UTF16[] = "\x27\x06\x44\x06\x33\x06\x44\x06\x27\x06\x45\x06\x20\x00\x39\x06"
+static _Alignas(WCHAR) BYTE ar_Hello_UTF16[] = "\x27\x06\x44\x06\x33\x06\x44\x06\x27\x06\x45\x06\x20\x00\x39\x06"
 		"\x44\x06\x4A\x06\x43\x06\x45\x06\x00\x00";
 static int ar_Hello_cchWideChar = 13;
 static int ar_Hello_cbMultiByte = 24;
 
 static BYTE ar_HowAreYou_UTF8[] = "\xD9\x83\xD9\x8A\xD9\x81\x20\xD8\xAD\xD8\xA7\xD9\x84\xD9\x83\xD8"
 		"\x9F\x00";
-static BYTE ar_HowAreYou_UTF16[] = "\x43\x06\x4A\x06\x41\x06\x20\x00\x2D\x06\x27\x06\x44\x06\x43\x06"
+static _Alignas(WCHAR) BYTE ar_HowAreYou_UTF16[] = 

Bug#798248: [PATCH] Fix test-suite failure on Alpha

[Michael Cree]

Pulseaudio fails to build on the Alpha architecture due to a failure
in the volume-test of the test suite.  I had reported this to the
Debian bug tracker [1] but the maintainer has asked that I forward the
patch to this mail list.  The failure in volume-test occurs because it
is compiled with -ffast-math which implies -ffinite-math-only of which
the gcc manual states that it optimizes for floating-point arithmetic
with the assumption that arguments and results are not NaNs or
+/-infinity, and futher notes that it may result in incorrect output.
On the Alpha platform that is somewhat an understatement as the use of
non-finite floating-point arithmetic with -ffinite-math-only results in
a floating-point exception and the termination of the program.

The volume-test converts volumes into decibels (so a zero volume
becomes a negative infinity) and proceeds to add two volumes (in
decibels), thus does arithmetic with non-finite floating point numbers
despite being compiled with -ffast-math!

I attach a patch that protects against the arithmetic with non-finite
numbers for your consideration.  With that patch the test-suite passes
on Alpha.

Cheers
Michael.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248
Index: pulseaudio-6.0/src/tests/volume-test.c
===
--- pulseaudio-6.0.orig/src/tests/volume-test.c
+++ pulseaudio-6.0/src/tests/volume-test.c
@@ -114,7 +114,10 @@ START_TEST (volume_test) {
 double q, qq;
 
 p = pa_sw_volume_multiply(v, w);
-qq = db + db2;
+	if (isfinite(db) && isfinite(db2))
+		qq = db + db2;
+	else
+		qq = -INFINITY;
 p2 = pa_sw_volume_from_dB(qq);
 q = l*t;
 p1 = pa_sw_volume_from_linear(q);

Bug#798248: pulseaudio FTBFS on Alpha because of volume-test failure in test suite.

[Michael Cree]

Source: pulseaudio
Version: 6.0-5
Severity: important
Justification: fails to build from source but built in the past.
User: debian-al...@lists.debian.org
Usertags: alpha

Pulseaudio FTBFS on alpha due to the volume-test test failing. From
the build log [1]:


FAIL: volume-test
=

Running suite(s): Volume
Attenuation of sample 1 against 32767: -90.3087 dB
Smallest possible attenuation > 0 applied to 32767: 0
0%: Checks: 1, Failures: 0, Errors: 1
tests/volume-test.c:107:E:volume:volume_test:0: (after this point) Received 
signal 8 (Floating point exception)
FAIL volume-test (exit status: 1)


This test fails because of the addition of two infinities is
attempted when compiling volume-test with -ffast-math and on Alpha
any attempt at using a non-finite number when compiled with
-ffast-math results in a floating-point exception.  As the gcc
manual states, using infinities in floating-point arithmetic with
-ffast-math may result in incorrect operation!

For volume-test to work on Alpha one of the two following conditions
must be met:

1) Do not compile volume-test with -ffast-math so that infinities are
supported properly.

2) Don't use infinities in the test suite! (The infinities occur
because a zero volume is converted to dB, i.e. -infinity dB, then
two volumes, both of -infinity dB, are added.  Boom!)

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pulseaudio=alpha=6.0-5=1438647901

Bug#798248: Patch to fix FTBFS on Alpha

[Michael Cree]

Control: tags -1 + patch

Here goes a patch to fix the FTBFS on Alpha.  It protects the
floating point addition of volumes in dB from adding any infinities.
An assumption is made that negative infinity is the only possible
non-finite number since dB are calculated via a logarithm from
volumes and volumes are necessarily non-negative.

Cheers
Michael.
Index: pulseaudio-6.0/src/tests/volume-test.c
===
--- pulseaudio-6.0.orig/src/tests/volume-test.c
+++ pulseaudio-6.0/src/tests/volume-test.c
@@ -114,7 +114,10 @@ START_TEST (volume_test) {
 double q, qq;
 
 p = pa_sw_volume_multiply(v, w);
-qq = db + db2;
+	if (isfinite(db) && isfinite(db2))
+		qq = db + db2;
+	else
+		qq = -INFINITY;
 p2 = pa_sw_volume_from_dB(qq);
 q = l*t;
 p1 = pa_sw_volume_from_linear(q);

Bug#792555: binutils: ld reloc sorting causes segfaults on alpha

[Michael Cree]

Control: reassign -1 binutils 2.25.1-1
Control: retitle -1 binutils: ld reloc sorting causes segfaults on Alpha

This is a binutils bug.  Confirmed that it not only causes segfaults
in the libc6.1-alphaev67 package but is also the reason for aptitude
FTBFS on Alpha.

Fixed upstream on the binutils-2_25-branch branch by:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5fc980cc8be61203db24756e17d87f24c174f1ac

and

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=00b2b5c400e542a436b66989841a2f3b81181e91

It would be marvellous if these could be included in the next upload
of binutils!

Michael.

Bug#792555: libc6.1-alphaev67 issue now reported upstream

[Michael Cree]

Control: tags -1 upstream

The segfaults resulting from installing libc6.1-alphaev67 on an Alpha
ev67 (or better) system have been isolated down to ld reloc sorting
causing crashes in glibc as reported upstream:

https://sourceware.org/bugzilla/show_bug.cgi?id=18867

I'll leave it for the glibc and binutils maintainers to decide
which package the bug should be assigned to.

Cheers
Michael.

Bug#792551: systemd FTBFS on Alpha because of use of wrong syscall.

[Michael Cree]

On Thu, Jul 16, 2015 at 02:03:57PM +0200, Michael Biebl wrote:
 Am 16.07.2015 um 10:05 schrieb Michael Cree:
  Systemd FTBFS on alpha due to missing syscalls.  Build log at:
  http://buildd.debian-ports.org/status/package.php?p=systemdsuite=sid
 
 Looks like systemd has been failing to build for a while now:
 
 http://buildd.debian-ports.org/status/logs.php?pkg=systemdarch=alpha

Indeed.

 Thanks for the explanation and the link to the patch, Michael. Have you
 tested, that systemd builds successfully with this patch?

Not at the time but I have done so now.  I attach an updated patch
as the Gentoo provided patch expected the missing.h file to be in
a different place than where it is located in the Debian source.

As the kernel in unstable (4.0.8) does not have the newest syscalls
wired up on Alpha (the one in experimental does have them) I further
patched systemd to have the Alpha syscall numbers for memfd_create
and getrandom (that patch not attached here as waiting for the upload
of linux 4.1 to unstable is a better solution).  That built
successfully and now installed into an Alpha with a self-compiled 4.1
kernel (to get those latest syscalls).

For some reason systemd can't automount the disks from /etc/fstab (it
wasn't doing that before so this is not new to this systemd version)
and drops into a shell, at which point I can mount the disks and it
continues to boot up fine after that.  So seems to be working.

 Can you file the issue upstream as well at
 https://github.com/systemd/systemd/issues

No.  I do not agree with the github terms and conditions so do not and
will not have an account there.  Unfortunately, it seems one to has to
have an account to file a bug report on github.

Cheers
Michael.
Index: systemd-222/src/basic/missing.h
===
--- systemd-222.orig/src/basic/missing.h
+++ systemd-222/src/basic/missing.h
@@ -945,7 +945,11 @@ static inline int raw_clone(unsigned lon
 }
 
 static inline pid_t raw_getpid(void) {
+#if defined(__alpha__)
+return (pid_t) syscall(__NR_getxpid);
+#else
 return (pid_t) syscall(__NR_getpid);
+#endif
 }
 
 #if !HAVE_DECL_RENAMEAT2

Bug#792551: systemd FTBFS on Alpha because of use of wrong syscall.

[Michael Cree]

On Thu, Jul 16, 2015 at 02:03:57PM +0200, Michael Biebl wrote:
 Am 16.07.2015 um 10:05 schrieb Michael Cree:
  Patch to fix systemd to use the getxpid syscall on Alpha is available
  from the Gentoo bug system:
  https://bugs.gentoo.org/attachment.cgi?id=405976action=diff

Now commit a242a99d42276b6b764f80bd0de70c26e5c5f1d4 upstream.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792551: systemd FTBFS on Alpha because of use of wrong syscall.

[Michael Cree]

Source: systemd
Version: 222-2
Severity: important
Justification: Fails to build from source but built in the past.
Tag: patch
User: debian-al...@lists.debian.org
Usertags: alpha

Systemd FTBFS on alpha due to missing syscalls.  Build log at:
http://buildd.debian-ports.org/status/package.php?p=systemdsuite=sid

When linux 4.1 is uploaded that will fix the missing memfd_create and
getrandom syscalls, but there is one more missing syscall, namely the 
getpid syscall.

Alpha follows OSF1 rather than linux conventions on older syscalls,
thus has the getxpid syscall rather than the getpid/getppid syscalls.

Patch to fix systemd to use the getxpid syscall on Alpha is available
from the Gentoo bug system:
https://bugs.gentoo.org/attachment.cgi?id=405976action=diff

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792555: segfaults occurring when libc6.1-alphaev67 installed on alpha.

[Michael Cree]

Package: libc6.1-alphaev67
Version: 2.19-19
Severity: important
Justification: breaks other software when installed
User: debian-al...@lists.debian.org
Usertags: alpha

Something has gone terribly wrong with the libc6.1-alphaev67 package
with the 2.19-19 upload.  A segmentation violation occurs every time
a shell command is run.  Everything is okay if only libc6.1 installed.
With libc6.1-alphaev67 also installed it appears that commands execute
correctly and the segmentation violation occurs near the end or after
command execution.

Running this in a buildd chroot I install libc6.1-alphaev67 and dpkg
falls over in the postinstall with a segfault.  Then running ls a 
segfault occurs.  It appears that the segfault is actually caused by
iconv rather than ls, so running gdb on the core dump:

(sid)mjc@electro:~/.../glibc/glibc-2.19$ gdb iconv core
[snip]
Core was generated by `iconv -l'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0207ac44 in __GI___call_tls_dtors () at 
cxa_thread_atexit_impl.c:83
83  cxa_thread_atexit_impl.c: No such file or directory.
(gdb) dir stdlib
Source directories searched: /home/mjc/debian/glibc/glibc-2.19/stdlib:$cdir:$cwd
(gdb) bt full
#0  0x0207ac44 in __GI___call_tls_dtors () at 
cxa_thread_atexit_impl.c:83
No locals.
#1  0x0207a3fc in __run_exit_handlers (status=2006560, 
listp=0x21ea020 __exit_funcs, 
run_list_atexit=run_list_atexit@entry=true)
at exit.c:40
No locals.
#2  0x0207a550 in __GI_exit (status=optimized out) at exit.c:104
No locals.
#3  0x000120002ea8 in ?? ()
No symbol table info available.
#4  0x0205ec30 in __libc_start_main (main=0x1200023a0, argc=optimized 
out, 
argv=0x11ff9bbf8, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, 
stack_end=0x11ff9bbe0) at libc-start.c:287
result = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 4831893040, 4830229088, 
4830229097, 
4837948556, 4837948548, -6904472293805735848, 
-6904474492829226072, 
-6904474497599762104, 4650248090236747776, 0, 0, 0, 0, 0, 0, 
0}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = 
{prev = 0x0, 
  cleanup = 0x0, canceltype = 0}}}
not_first_call = optimized out
#5  0x000120002fb8 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) list
78  /* Call the destructors.  This is called either when a thread returns 
from the
79 initial function or when the process exits via the exit function.  */
80  void
81  __call_tls_dtors (void)
82  {
83while (tls_dtor_list)
84  {
85struct dtor_list *cur = tls_dtor_list;
86tls_dtor_list = tls_dtor_list-next;
87  
(gdb) disass /m
Dump of assembler code for function __GI___call_tls_dtors:
82  {
   0x0207abf0 +0: ldahgp,23(t12)
   0x0207abf4 +4: lda gp,27400(gp)
   0x0207abfc +12:lda sp,-48(sp)
   0x0207ac04 +20:stq s0,8(sp)
   0x0207ac08 +24:stq s1,16(sp)
   0x0207ac0c +28:stq s2,24(sp)
   0x0207ac10 +32:stq s3,32(sp)
   0x0207ac1c +44:stq s4,40(sp)
   0x0207ac20 +48:stq ra,0(sp)

83while (tls_dtor_list)
   0x0207abf8 +8: ldq t12,-32328(gp)
   0x0207ac00 +16:lda a0,-30936(gp)
   0x0207ac34 +68:rduniq
   0x0207ac38 +72:addqa0,v0,v0
   0x0207ac3c +76:ldahv0,0(v0)
   0x0207ac40 +80:unop
= 0x0207ac44 +84:ldq s0,72(v0)
   0x0207ac48 +88:bne s0,0x207ac94 
__GI___call_tls_dtors+164
   0x0207ac4c +92:br  0x207ad20 
__GI___call_tls_dtors+304
   0x0207ac74 +132:   ldq t12,-32328(gp)
   0x0207ac78 +136:   lda a0,-30936(gp)
   0x0207ac7c +140:   jsr ra,(t12),0x207ac80 
__GI___call_tls_dtors+144
   0x0207ac80 +144:   ldahgp,23(ra)
   0x0207ac84 +148:   ldahv0,0(v0)
   0x0207ac88 +152:   lda gp,27256(gp)
   0x0207ac8c +156:   ldq s0,72(v0)
   0x0207ac90 +160:   beq s0,0x207ad20 
__GI___call_tls_dtors+304

[snip]

gdb) print /x $v0
$1 = 0x4216920
(gdb) print /x $a0
$2 = 0x21e9e20

The address pointed to by tls_dtor_list which should be in v0 at
the point of the segfault does look wonky.

I not convinced this is actually a glibc fault; the changelog for 
the 2.19-19 upload indicates that the only code change form 2.19-18
is hurd specific, however 2.19-18 was working fine, thus suggestive
this might be a compiler/linker cockup.

Also I had compiled glibc 2.19-18 a month or two ago with a compiler
that had been modified to generate code with the BWX (byte-word
extension giving atomic byte and 16-bit word writes) by default and

Bug#791623: haskell-path-pieces FTBFS on debian-ports arches; missing build-depends.

[Michael Cree]

On Tue, Jul 07, 2015 at 10:13:00AM +0200, Joachim Breitner wrote:
 Hi,
 
 Am Dienstag, den 07.07.2015, 10:09 +1200 schrieb Michael Cree:
  I see build-depends restricted to the official linux arches for
  libghc-hspec-dev and libghc-quickcheck2-dev.  Could we get the
  Debian-Ports arches that have ghc built (alpha, hppa and ppc64)
  added to those build-depends please.
  
 
 the list should only have those architectures that support template
 -haskell, i.e. those where there is a /usr/bin/ghci. Is that really all
 of these three?

Inspecting the ghc binary package it looks like alpha and hppa have
/usr/bin/ghci but ppc64 does not.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791623: haskell-path-pieces FTBFS on debian-ports arches; missing build-depends.

[Michael Cree]

Source: haskell-path-pieces
Version: 0.2.0-1
Severity: important
Justification: Fails to build from source but built in the past.

haskell-path-pieces FTBFS on the Debian-Ports arches (alpha, hppa and
ppc64) with:

Running debian/hlibrary.setup configure --ghc -v2 
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
--libdir=/usr/lib/haskell-packages/ghc/lib --builddir=dist-ghc 
--ghc-option=-optl-Wl\,-z\,relro 
--haddockdir=/usr/lib/ghc-doc/haddock/path-pieces-0.2.0/ 
--datasubdir=path-pieces --htmldir=/usr/share/doc/libghc-path-pieces-doc/html/ 
--enable-library-profiling --enable-tests
Configuring path-pieces-0.2.0...
hlibrary.setup: At least the following dependencies are missing:
HUnit -any, QuickCheck -any, hspec =1.3
make: *** [configure-ghc-stamp] Error 1

I see build-depends restricted to the official linux arches for
libghc-hspec-dev and libghc-quickcheck2-dev.  Could we get the
Debian-Ports arches that have ghc built (alpha, hppa and ppc64)
added to those build-depends please.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789807: [alpha] cmake: testsuite failure: compiler feature c_function_prototypes is not known to C compiler

[Michael Cree]

On Wed, Jun 24, 2015 at 06:52:39PM +0200, Andreas Cadhalpun wrote:
 cmake failed to build on alpha with a testsuite failure:
 CMake Error in CMakeLists.txt:
   The compiler feature c_function_prototypes is not known to C compiler

Yeah, I had noticed this too and had tried to debug it but made no
progress probably due to myself being totally unfamiliar with cmake.
The cmake code for this test appears to me to test for the feature
based on gcc version, but why it should fail on Alpha is mystifying
when we are up to date with gcc version.

 So could you please change the testsuite to not expect these features
 on alpha?  Due to the tight dependency on the arch:all cmake-data,
 the outdated cmake binary is uninstallable on alpha, which blocks a
 bunch of other packages.

I wonder what is the danger of disabling the test suite and uploading
a potentially wayward cmake on Alpha?  Would that particular check for
compiler features failing (when in fact the compiler does support the
feature) during the configure stage of package builds lead to incorrect
builds?  If so, I would rather wait for a real fix and take the hit
we have at the moment on Alpha of not being able to build a significant
part of the archive.

Is the cmake maintainer able to (willing to?) give me some guidance on
debugging this?  I can run the specific test manually and see it fail,
and can find the commit that adds the specific feature and test to
cmake, but am completely befuddled by the cmake code.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#399608: fixed in sysvinit 2.88dsf-59.1

[Michael Cree]

[I've trimmed the CCes a bit.]

On Mon, May 18, 2015 at 07:52:12PM +0100, Luke Kenneth Casson Leighton wrote:
 On Sun, May 17, 2015 at 3:48 PM, Andreas Henriksson andr...@fatal.se wrote:
  Hello Adrian!
 
  Thanks for raising awareness about this issue. If there's anything
  I can do to help please tell me. That the new util-linux version hasn't
  been built yet sounds like it can't be avoided as it was just uploaded
  and unfortunately the sysvinit and util-linux update is a lockstep
  upgrade where both change at the same time as things are moved between
  the packages. There's no intermediate step possible, because the
  moved binaries always needs to be available at all times and thus
  have tight dependencies in both directions. Not sure how dependencies
  affects the build of these packages though They should both be
  able to build on systems with older versions of the packages installed
  and build independently.
 
  that sounds like the kind of thing that would cause nightmare
 circular build dependencies for anyone porting to a new architecture
 [which i'm considering doing: mvp from icubecorp].
 
  would that be correct - that if there *is* no older version it
 would now be impossible to build both [or either] of the packages - or
 am i mistaken?

It's not normally that bad.  Old packages exist in snapshot.d.o.  In
the case of util-linux that the original poster talks about, the old
version of util-linux is still in the chroots of the buildd, its just
that wanna-build no longer knows about that version so does not offer
util-linux for building, so one has to manually schedule a build and
binary upload.

The situation is different for boot strapping a new architecture.
There are quite a number of circular build-dependencies and one breaks
the circle with a variety of techniques, one of which is cross-building.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778748: Please help on build issue on arm64 (and others) (Was: failed arm64 build of vsearch 1.0.16+dfsg-1)

[Michael Cree]

On Thu, Feb 19, 2015 at 07:59:20PM +0100, Andreas Tille wrote:
 the problematic line is:
 
 ...
 g++ -O3 -DHAVE_BZLIB  -Icityhash -Wall -Wsign-compare -g -c -o align.o 
 align.cc
 In file included from align.cc:22:0:
 vsearch.h:30:23: fatal error: x86intrin.h: No such file or directory
  #include x86intrin.h
^
 compilation terminated.

x86intrin.h is a general inlude file to get all x86 SIMD instructions
(i.e. SSE, AVX, etc.) and possibly other x86 specific stuff.  This is
not available on anything but x86_64 hardware (and possibly x86, but
I suspect not).

This would need porting to other architectures to compile it.  How
difficult that is depends on the rest of align.cc and what x86
intrinsics it is using.  It could be quite substantial work, or it
might be possible to write general portable code with not too much
effort.  I haven't looked at align.cc to see ...

Probably easiest to mark the package as amd64 only at this stage until
someone can investigate the porting issues further.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#693581: closed by Joachim Breitner nome...@debian.org (Alpha is removed from Debian)

[Michael Cree]

reopen 693581
found 693581 7.6.3-20
retitle 693581 ghc in unstable FTBFS on alpha; fix is upstream
thanks

On Tue, Dec 09, 2014 at 10:15:05AM +, Debian Bug Tracking System wrote:
 From: Joachim Breitner nome...@debian.org
 To: 693581-d...@bugs.debian.org
 Subject: Alpha is removed from Debian
 X-Mailer: Evolution 3.12.9-1 
 
 so this can be closed.

Well, actually, it was never fixed in unstable.  Would be nice if the
patch could be applied to ghc in unstable (currently 7.6.3-20) then
ghc would build on Alpha at Debian-Ports, but I understand if that
is not possible because of the freeze.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770655: git FTBFS: failure in t9500-gitweb-standalone-no-errors.sh

[Michael Cree]

Source: git
Version: 2.1.3-1
Severity: important
Justification: Fails to build from source but built in the past.

Current git in unstable FTBFS with a failure in the test
t9500-gitweb-standalone-no-errors.sh.  First noticed on alpha at
debian-ports, see:
http://buildd.debian-ports.org/status/package.php?p=git

While debugging on Alpha got suspicious that this is a more general
failure, so ran a test build in a clean sid chroot on amd64 and
discovered it fails on amd64 for the same reason.

The test t9500-gitweb-standalone-no-errors.sh script runs gitweb_run
in ./t/gitweb-lib.sh, and that calls perl to run gitweb_run perl script
and then checks the generated t/trash.../gitweb.log for any lines
starting with '[' and fails if so.

Currently invoking gitweb_run results in the following message to
stdout:

[Sat Nov 22 09:40:09 2014] gitweb.perl: CGI::param called in list
context from package main line 874, this can lead to vulnerabilities.
See the warning in Fetching the value or values of a single named
parameter at /usr/share/perl5/CGI.pm line 436.

which is sufficient to cause the test suite to fail.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756892: ceph FTBFS on alpha due to incorrect check on BLKGETSIZE

[Michael Cree]

Source: ceph
Version: 0.80.5-1
Severity: normal
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

Ceph FTBFS on Alpha with:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -D__CEPH__ -D_FILE_OFFSET_BITS=64 
-D_REENTRANT -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_GNU_SOURCE 
-DCEPH_LIBDIR=\/usr/lib/alpha-linux-gnu\ 
-DCEPH_PKGLIBDIR=\/usr/lib/alpha-linux-gnu/ceph\ -DGTEST_HAS_TR1_TUPLE=0 
-D_FORTIFY_SOURCE=2 -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits 
-Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
-fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 
-Wnon-virtual-dtor -Wno-invalid-offsetof -Wstrict-null-sentinel -g -O2 -Wformat 
-Werror=format-security -c common/blkdev.cc  -fPIC -DPIC -o 
common/.libs/blkdev.o
In file included from /usr/include/alpha-linux-gnu/asm/ioctls.h:4:0,
 from /usr/include/alpha-linux-gnu/bits/ioctls.h:23,
 from /usr/include/alpha-linux-gnu/sys/ioctl.h:26,
 from common/blkdev.cc:3:
common/blkdev.cc:13:7: error: missing binary operator before token int
 #elif BLKGETSIZE
   ^

This error occurs because the value of BLKGETSIZE is tested in a
c-preprocessor conditional compilation test whereas the test should
be for existence.

Patch fixing this attached.

Ceph successfully builds to completion on Alpha with this patch.

Cheers
Michael.
Index: ceph-0.80.5/src/common/blkdev.cc
===
--- ceph-0.80.5.orig/src/common/blkdev.cc
+++ ceph-0.80.5/src/common/blkdev.cc
@@ -10,7 +10,7 @@ int get_block_device_size(int fd, int64_
 {
 #ifdef BLKGETSIZE64
   int ret = ::ioctl(fd, BLKGETSIZE64, psize);
-#elif BLKGETSIZE
+#elif defined(BLKGETSIZE)
   unsigned long sectors = 0;
   int ret = ::ioctl(fd, BLKGETSIZE, sectors);
   *psize = sectors * 512ULL;

Bug#746924: octave FTBFS on alpha: invalid argument -mieee passed to moc-qt4

[Michael Cree]

On Tue, Jul 29, 2014 at 11:11:28PM -0400, Mike Miller wrote:
 On Thu, Jul 24, 2014 at 20:00:44 -0400, Mike Miller wrote:
  On Sun, May 4, 2014 at 12:25:01 +1200, Michael Cree wrote:
   octave FTBFS on alpha, with the following:
  
   ( echo '#ifdef HAVE_CONFIG_H'; echo '#include config.h'; echo '#endif'; 
   moc-qt4 -DHAVE_CONFIG_H -I. -I..   -D_FORTIFY_SOURCE=2 -mieee   
   src/m-editor/file-editor-interface.h )  
   src/m-editor/moc-file-editor-interface.cc-t
   moc: Invalid argument
  
  Thanks for your bug report. Your analysis seems right to me. I have
  reported this upstream, please follow up there if you have additional
  comments (although it may yet go further upstream to gnulib from
  there).
 
 When you get a chance, can you do a test rebuild on alpha using the
 upstream proposed fix for this bug:
 
 http://hg.savannah.gnu.org/hgweb/octave/raw-rev/a5add7b660ac
 
 This will help verify that the proposed fix works as expected.

Done.  Octave builds to completion on Alpha with that patch.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756368: postgresql-9.4 FTBFS on alpha: incorrect pg_read_barrier definition

[Michael Cree]

Source: postgresql-9.4
Version: 9.4~beta2-1
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha

postgresql-9.4 FTBFS on alpha.  From the build log [1]:

cc -g -O2 -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie 
-DLINUX_OOM_SCORE_ADJ=0 -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute 
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g 
-I../../../src/include -I/«PKGBUILDDIR»/build/../src/include 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include/tcl8.6 
 -c -o bgworker.o /«PKGBUILDDIR»/build/../src/backend/postmaster/bgworker.c
/tmp/ccNKo8Fb.s: Assembler messages:
/tmp/ccNKo8Fb.s:764: Error: unknown opcode `rmb'
as: BFD (GNU Binutils for Debian) 2.24.51.20140709 internal error, aborting at 
../../gas/write.c line 603 in size_seg

This occurs because in src/include/storage/barrier.h the definition of
pg_read_barrier() for Alpha maps to the CPU instruction rmb but there
is no such CPU instruction on Alpha!

I attach a patch that fixes the pg_read_barrier() definition to use the
correct CPU instruction for a read memory barrier on Alpha.  With that
postgresql-9.4 builds to completion on Alpha.

Cheers
Michael.

[1] 
http://buildd.debian-ports.org/status/fetch.php?pkg=postgresql-9.4arch=alphaver=9.4~beta2-1stamp=1406489832
Index: postgresql-9.4-9.4~beta2/src/include/storage/barrier.h
===
--- postgresql-9.4-9.4~beta2.orig/src/include/storage/barrier.h
+++ postgresql-9.4-9.4~beta2/src/include/storage/barrier.h
@@ -117,7 +117,7 @@ extern slock_t dummy_spinlock;
  * read barrier to cover that case.  We might need to add that later.
  */
 #define pg_memory_barrier()		__asm__ __volatile__ (mb : : : memory)
-#define pg_read_barrier()		__asm__ __volatile__ (rmb : : : memory)
+#define pg_read_barrier()		__asm__ __volatile__ (mb : : : memory)
 #define pg_write_barrier()		__asm__ __volatile__ (wmb : : : memory)
 #elif defined(__hppa) || defined(__hppa__)		/* HP PA-RISC */
 

Bug#755397: tst-eintr3 test suite failure on alpha might be due to a kernel bug

[Michael Cree]

I am starting to think this tst-eintr3 test suite failure on Alpha
might is a kernel bug.  My reasoning goes as follows.

Nowhere does glibc call the wruniq PALcall thus it is not glibc
setting up the thread pointer for a process.  The thread pointer
is passed as an argument to the clone() syscall and it is the
kernel that initialises the process control block (PCB) for a
process and ensures that it is switched in when a process is
scheduled.  That raises the question of whether it might be the
kernel that is failing to correctly initialise the thread pointer
in the PCB.

I therefore ran tst-eintr3 under strace to check that glibc is
calling the clone() syscall correctly.

When tst-eintr3 works correctly the syscall trace is (after deleting
quite a bit of irrelevancy at the start and at the end)

clone(child_stack=0x2a1eae0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x2a1f2c0, tls=0x2a1f8e0, child_tidptr=0x2a1f2c0) = 
20119
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=20118, si_uid=1000} ---
write(1, ., 1.)= 1
sigreturn() (mask [])   = 20119
mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
-1, 0) = 0x2a2
mprotect(0x2a2, 8192, PROT_NONE) = 0
clone(child_stack=0x2000121eae0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x2000121f2c0, tls=0x2000121f8e0, child_tidptr=0x2000121f2c0) = 
20120


In total, clone() gets called twice, and in both cases it looks like
glibc has passed sensible arguments to clone().


Now, the syscall trace for the case when tst-eintr3 segfaults is
illuminating:

clone(child_stack=0x2a1eae0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x2a1f2c0, tls=0x2a1f8e0, child_tidptr=0x2a1f2c0) = 
20087
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=20086, si_uid=1000} ---
write(1, ., 1.)= 1
sigreturn() (mask [])   = 20087
mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
-1, 0) = 0x2a2
mprotect(0x2a2, 8192, PROT_NONE) = 0
clone(child_stack=0x2000121eae0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x2000121f2c0, tls=0x2000121f8e0, child_tidptr=0x2000121f2c0) = 
? ERESTARTNOINTR (To be restarted)
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=20086, si_uid=1000} ---
write(1, ., 1.)= 1
sigreturn() (mask [])   = -1 ERRNO_312 (Unknown error 312)
clone(child_stack=0x2000121eae0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x2000121f2c0, tls=0, child_tidptr=0x2000121f2c0) = 20089
+++ killed by SIGSEGV +++


The clone() syscall has been tried three times because on the second
time it failed with ERESTARTNOINTR and that particular call has been
retried (the third call to clone() above) with the same arguments except
that the tls argument is now zero!  That error, ERESTARTNOINTR, is a
kernel internal error and should not be visible to userspace.  Indeed,
it is the kernel that retries the clone() syscall as the first try at
running clone() ended up in a mess (something about receiving a signal
right at the worst moment of cloning the process) and the way to
recover is to abandon the clone() function and retry it from the start.

But why is the tls argument zeroed on the retry?  The alpha version of
clone() does not pass the tls argument in the normal way (as a
register). Instead the architecture specific code resorts to finding it
on the stack where the CPU registers were saved on entry to the kernel.
But when an error is returned from a syscall the kernel writes the
stack location for the a3 cpu register with the errno return so that on
final exit from the kernel the a3 cpu register will contain the errno
and then, if appropriate, retries the syscall ensuring the a3 cpu
register has its original contents that it had on entry to the kernel.
But that is no good for the clone() syscall because it ignores the
a3 cpu register (which is the tls argument) and goes to the saved 
register on the stack which is by now been changed to zero.  Voila,
a segmentation fault then results in userspace as the thread pointer
is invalid.

I'll take this to linux-alpha and the lkml for thoughts on my analysis
and to work out a solution.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755397: glibc FTBFS on alpha: tst-eintr3 sometimes fails.

[Michael Cree]

Source: glibc
Version: 2.19-7
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: Fails to build from source but built in the past.

The test tst-eintr3 sometimes fails in the build of glibc on alpha
and has done so twice in a row in attempting to build 2.19-7.

It's an intermittant fault that appears to only occur on a
multiprocessor SMP system (which the buildd imago is).  Running the
test manually 40 or so times never failed when running a UP kernel.

To make testing faster I have used upstream glibc source on the 2.19
branch configuring with --enable-hardcoded-path-in-tests and running
tst-eintr3 with the --direct option.  It occasionally segfaults.
Getting a core dump and analysing with gdb gives the following:

Core was generated by `/home/mjc/toolchain/glibc-build/nptl/tst-eintr3 
--direct'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  start_thread (arg=0x2000121f1f0) at pthread_create.c:243
243   __resp = pd-res;

(gdb) bt full
#0  start_thread (arg=0x2000121f1f0) at pthread_create.c:243
pd = 0x2000121f1f0
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0 repeats 17 times}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x203da00 
start_thread, 
  0x2000121f1f0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 
252416}}}
not_first_call = optimized out
robust = optimized out
pagesize_m1 = optimized out
sp = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#1  0x02177d24 in thread_start ()
at ../ports/sysdeps/unix/sysv/linux/alpha/clone.S:111
No locals.

(gdb) disass /m

Dump of assembler code for function start_thread:
232 {
   0x0203da00 +0: ldahgp,3(t12)
   0x0203da04 +4: lda gp,-14800(gp)
   0x0203da08 +8: lda sp,-240(sp)
   0x0203da14 +20:stq fp,40(sp)
   0x0203da18 +24:mov sp,fp
   0x0203da24 +36:stq s0,8(sp)
   0x0203da28 +40:stq ra,0(sp)
   0x0203da30 +48:stq s1,16(sp)
   0x0203da38 +56:stq s2,24(sp)
   0x0203da3c +60:stq s3,32(sp)
   0x0203da40 +64:stq a0,224(fp)

233   struct pthread *pd = (struct pthread *) arg;
234 
235 #if HP_TIMING_AVAIL
236   /* Remember the time when the thread was started.  */
237   hp_timing_t now;
238   HP_TIMING_NOW (now);
239   THREAD_SETMEM (pd, cpuclock_offset, now);
240 #endif
241 
242   /* Initialize resolver state pointer.  */
243   __resp = pd-res;
   0x0203da0c +12:rduniq
   0x0203da10 +16:ldq t0,-32656(gp)
   0x0203da20 +32:addqv0,t0,t0
   0x0203da2c +44:lda t1,1208(a0)
   0x0203da34 +52:mov v0,s0
= 0x0203da44 +68:stq t1,0(t0)


The __resp variable appears to be a thread local variable being
accessed (well, written) by the initial exec TLS model.  The rduniq
PALcall should put the thread pointer (from the PCB) into register
v0.  Now let's check the address being written to at the point of
the segfault.

(gdb) print /x $t0
$1 = 0x18

That's definitely not a valid memory location since the first page of
memory starting at location 0 should be inaccessible.  Checking the
thread pointer:

(gdb) print /x $v0
$2 = 0x0

Ouch!  That looks like the thread pointer in the PCB has not been
initialised.

Running tst-eintr3 under gdb and setting a break point on line 243
reveals that, in general, the rduniq PALcall does return a valid
memory address (and presumably correctly the thread pointer), but,
occassionaly on an SMP system, it can return 0.  

This is as far as I have got with debugging.  Presumably there is a
wruniq PALcode call somewhere that sets up the thread pointer in the
PCB and that might be the next place to investigate what is going
on.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755232: graphviz FTBFS on Alpha: missing -lm in link of cmd/dot

[Michael Cree]

Source: graphviz
Version: 2.38.0-3
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: fails to build from source but used to build

graphviz FTBFS on Alpha with a failed link of cmd/dot.  From the build
log [1]

/bin/bash ../../libtool  --tag=CC   --mode=link alpha-linux-gnu-gcc  -g -O2 
-Wformat -Werror=format-security -mieee -Wall  -Wl,-z,relro -Wl,--as-needed -o 
dot dot-dot.o dot-no_builtins.o ../../lib/gvc/libgvc.la 
../../lib/cgraph/libcgraph.la 
libtool: link: alpha-linux-gnu-gcc -g -O2 -Wformat -Werror=format-security 
-mieee -Wall -Wl,-z -Wl,relro -Wl,--as-needed -o .libs/dot dot-dot.o 
dot-no_builtins.o  ../../lib/gvc/.libs/libgvc.so 
../../lib/cgraph/.libs/libcgraph.so
/usr/bin/ld: dot-dot.o: undefined reference to symbol 
'feenableexcept@@GLIBC_2.2'
//lib/alpha-linux-gnu/libm.so.6.1: error adding symbols: DSO missing from 
command line

This is a failure to link to feenableexcept() from the standard C maths
library.

Note that there is no -lm in the link command, but quoting from the
manpage for feenableexcept:

  Link with -lm.

I attach a patch that adds the math library into the link of cmd/dot.
With the patch graphviz successfully builds on Alpha.

Interestingly graphviz only failed on Alpha for this reason; I do not
know how it succeeded to build on all other architectures!

Cheers
Michael

[1] 
http://buildd.debian-ports.org/status/fetch.php?pkg=graphvizarch=alphaver=2.38.0-3stamp=1405642711
Index: graphviz-2.38.0/cmd/dot/Makefile.am
===
--- graphviz-2.38.0.orig/cmd/dot/Makefile.am
+++ graphviz-2.38.0/cmd/dot/Makefile.am
@@ -48,7 +48,8 @@ dot_SOURCES = dot.c no_builtins.c
 dot_CPPFLAGS = $(AM_CPPFLAGS) -DDEMAND_LOADING=1
 dot_LDADD = \
 	$(top_builddir)/lib/gvc/libgvc.la \
-	$(top_builddir)/lib/cgraph/libcgraph.la
+	$(top_builddir)/lib/cgraph/libcgraph.la \
+	$(MATH_LIBS)
 
 install-data-hook:
 	(cd $(DESTDIR)$(man1dir); for i in $(linkedman); do rm -f $$i; $(LN_S) dot.1 $$i; done;)

Bug#754524: Bad atomic ops on Alpha cause segfaults and mpi4py FTBFS

[Michael Cree]

Source: openmpi
Version: 1.6.5-8
Severity: important
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: Causes FTBFS in other packages that built in the past.

The atomic operations defined for Alpha in openmpi can cause weird
behaviour including segfaults leading to failures to build packages
that build-depend on openmpi binary packages. This probably only
arises now with a binNMU of openmpi and compilation with a newer gcc
that has tighter requirements of asm constructs.

The current definition of opal_atomic_cmpset_32() in
opal/include/opal/sys/alpha/atomic.h has the following statement:

   __asm __volatile__ (
   1:  ldl_l %0, %1\n\t
   cmpeq %0, %2, %0\n\t
   beq %0, 2f  \n\t
   mov %3, %0  \n\t
   stl_c %0, %1\n\t
   beq %0, 1b  \n\t
   jmp 3f  \n
   2:  mov $31, %0 \n
   3:  \n
   : =r (ret), +m (*addr)
   : r (oldval), r (newval)
   : memory);

however the jmp 3f instruction is an assembler macro and expands to
two CPU instructions that use CPU register t12 ($26) and the global
pointer ($29) to construct the address to label 3 and jump there. This
modification of t12 is not in the clobber list of the asm statement,
and the use of the global pointer is not listed in the asm inputs.

So, for example, in the function orte_plm_base_check_job_completed()
defined in the source file orte/mca/plm/base/plm_base_launch_support.c
a segfault results because the compiler sets up t12 as the pointer
to a struct, inserts the atomic asm code above, then accesses a field
in the structure via t12, which has been corrupted by the included
atomic asm.  This leads to the created executable /usr/bin/orted to
segfault in the test suite of mpi4py, hence the build failure of
mpi4py on Alpha [1].

Further segfaults occur in functions such as opal_atomic_add_32()
defined in the source file opal/include/opal/sys/atomic_impl.h
because the compiler determines that they are leaf functions that
do not make use of the global pointer so does not initialise the
global pointer, but the inserted asm code does in fact use the
global pointer, so, kaboom!

The asm code above is weird anyway.  The mov $31, %0 statement,
which clears the output %0 to zero, is superfluous as %0 must already
be zero because the only entry to label 2 is from the beq %0, 2f
and that statement will only branch to label 2 if the output %0
is zero!  So I recommend the following more efficient version of
the asm code:

   __asm__ __volatile__ (
   1:  ldl_l %0, %1\n\t
   cmpeq %0, %2, %0\n\t
   beq %0, 2f  \n\t
   mov %3, %0  \n\t
   stl_c %0, %1\n\t
   beq %0, 1b  \n\t
   2:  \n
   : =r (ret), +m (*addr)
   : r (oldval), r (newval)
   : memory);

I attach a patch that fixes both opal_atomic_cmpset_32() and
opal_atomic_cmpset_64() on Alpha.  With that openmpi builds to
completion and with the fixed openmpi mpi4py also builds to
completion.

Cheers
Michael.

[1] http://buildd.debian-ports.org/status/package.php?p=mpi4py
Index: openmpi-1.6.5/opal/include/opal/sys/alpha/atomic.h
===
--- openmpi-1.6.5.orig/opal/include/opal/sys/alpha/atomic.h
+++ openmpi-1.6.5/opal/include/opal/sys/alpha/atomic.h
@@ -87,18 +87,16 @@ static inline void opal_atomic_wmb(void)
 static inline int opal_atomic_cmpset_32( volatile int32_t *addr,
  int32_t oldval, int32_t newval)
 {
-   int32_t ret;
+int32_t ret;

-   __asm __volatile__ (
+__asm__ __volatile__ (
 		   1:  ldl_l %0, %1\n\t
 		   cmpeq %0, %2, %0\n\t
 		   beq %0, 2f  \n\t
 		   mov %3, %0  \n\t
 		   stl_c %0, %1\n\t
 		   beq %0, 1b  \n\t
-		   jmp 3f  \n
-		   2:  mov $31, %0 \n
-		   3:  \n
+		   2:  \n
 		   : =r (ret), +m (*addr)
 		   : r (oldval), r (newval)
 		   : memory);
@@ -141,9 +139,7 @@ static inline int opal_atomic_cmpset_64(
 			  mov %3, %0   \n\t
 			  stq_c %0, %1 \n\t
 			  beq %0, 1b   \n\t
-			  jmp 3f   \n
-			  2:  mov $31, %0  \n
-			  3:   \n
+			  2:   \n
 			  : =r (ret), +m (*addr)
 			  : r (oldval), r (newval)
 			  : memory);

Bug#753099: glibc FTBFS on alpha: test suite failures

[Michael Cree]

On Mon, Jun 30, 2014 at 11:02:24PM +0200, Aurelien Jarno wrote:
 On Sun, Jun 29, 2014 at 09:53:30PM +1200, Michael Cree wrote:
  Source: glibc
  Version: 2.19-4
  Severity: important
  User: debian-al...@lists.debian.org
  Usertags: alpha
  Justification: Fails to build from source but built in the past.
  
  Finally the fixed gcc-4.8 arrived, however the rebuild of glibc on alpha
  failed with unexpected test suite failures.  From the log:
 
  Encountered regressions that don't match expected failures 
  (debian/testsuite-checking/expected-results-alpha-linux-gnu-libc):
  badsalttest.out, Error 1
 
 This one looks might be worrying, as it might affect the crypt()
 function, and thus safety of passwords. Do you have more details about
 the failure.

It's one of the string functions reading one byte passed the end
of the string.  The badsalttest very carefully places a short
checksum at the very end of a page and marks the next page of
memory as invalid and the string function used in the bad salt
test (I've forgotten which one it was now) reads one byte too far.
So the worst it can do is result in a spurious segmentation
violation.

  test-double.out, Error 1
  test-float.out, Error 1
  test-snan.out, Error 1
 
 I guess these three are actually due to the new FP tests that have been
 added in 2.19, so it should be relatively fine ignoring them, though it
 might be a good idea to confirm that. 

Interestingly these pass fine in the alphaev67 libc test suite.  The
difference between libc6.1 and libc6.1-alphaev67 is the use of extra
CPU instructions such as the byte-word extension and the extra floating
point instructions for efficient conversion of integer to float and back.
Oh, there might be a special square-root instruction introduced too IIRC.  

  tst-backtrace2.out, Error 1
  tst-backtrace3.out, Error 1
  tst-backtrace4.out, Error 1
  tst-backtrace5.out, Error 1
  tst-backtrace6.out, Error 1
 
 I don't think having the backtrace function working is something
 critical for a system, so yes they can be ignored. It might be
 interesting to see what caused them to stop working though.

Once again they pass in the build of libc6.1-alphaev67 but not in
libc6.1.  Maybe something about the byte-word extension?

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753099: glibc FTBFS on alpha: test suite failures

[Michael Cree]

Source: glibc
Version: 2.19-4
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: Fails to build from source but built in the past.

Finally the fixed gcc-4.8 arrived, however the rebuild of glibc on alpha
failed with unexpected test suite failures.  From the log:

Encountered regressions that don't match expected failures 
(debian/testsuite-checking/expected-results-alpha-linux-gnu-libc):
badsalttest.out, Error 1
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1

The last three are fixed by upstream commit a3df56fcae7
(alpha: Fix __pointer_chk_guard definition for the testsuite).

The others I am inclined to have added to the expected failure list in
debian/testsuite-checking/expected-results-alpha-linux-gnu-libc.  Note
that they only need to be added to the alpha libc library not to 
the alphaev67 variant libary as all of these tests pass correctly
under the latter library.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752284: libreoffice FTBFS on alpha: missing debian/vars.alpha

[Michael Cree]

Source: libreoffice
Version: 1:4.2.5-1
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: Fails to build from source but built in the past.

Thanks for enabling the build of libreoffice on alpha.  It built
successfully at version 1:4.1.6~rc1-1 but has FTBFS ever since the
upload of 1:4.2.4-3 from experimental due to the missing
debian/alpha.vars file.  From the build log of the most recent
build:

touch debian/stampdir/install-arch
make: *** No rule to make target 'debian/vars.alpha', needed by 
'debian/stampdir/maintscripts'.  Stop.

Creating the file debian/vars.alpha with the following:

PLATFORMID=linux_alpha

should fix this.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738155: inkscape FTBFS on alpha

[Michael Cree]

Hi

Actually the special casing of the linker flags with -Wl,--no-relax is
no longer needed on Alpha.  The linker was fixed maybe a month ago and
relaxation is now working fine on large C/C++ programs.

I was just about to downgrade this bug to minor and retitle it to
suggest removing the alpha special casing when I see it is now marked
pending.  I am also wondering whether the addition of the -mieee'
compiler flag (that is currently in debian/rules for Alpha) is
strictly necessary as the Debian gcc should default to -mieee switched
on when run on Alpha, but I have not had a chance to run a test build
of that.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752160: blender FTBFS on alpha: that alpha is a 64bit arch is not fully detected.

[Michael Cree]

Source: blender
Version: 2.70a-2
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: Fails to build from source but built in the past.

blender FTBFS on alpha because it is a 64bit arch but is not listed in
the patch 0011-fix_FTBFS_on_unofficial_64bit_archs.patch thus the build
fails with:

cd /«PKGBUILDDIR»/obj-alpha-linux-gnu/source/blender/makesdna/intern  
../../../../bin/makesdna 
/«PKGBUILDDIR»/obj-alpha-linux-gnu/source/blender/makesdna/intern/dna.c 
/«PKGBUILDDIR»/source/blender/makesdna/
makesdna: /«PKGBUILDDIR»/intern/atomic/atomic_ops.h:265: atomic_add_z: 
Assertion `sizeof(size_t) == 1  2' failed.

Adding || defined(__alpha__) to the test of arches in the patch
0011-fix_FTBFS_on_unofficial_64bit_archs.patch results in a successful
build on alpha.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.

[Michael Cree]

On Wed, Jun 11, 2014 at 02:35:38PM +0200, Aurelien Jarno wrote:
 On Wed, Jun 11, 2014 at 08:55:42PM +1200, Michael Cree wrote:
  Aurelien: I guess I should file bugs against gcc-4.8 and gcc-4.9 to get
  that fix into Debian's gcc as the commit does not seem to have been
  backported into the upstream 4.8 and 4.9 branches.
 
 I have just backported the fix into the gcc-4.8 and gcc-4.9 packages. It
 will be available with the next upload, but I don't know exactly when it
 will happen.

Thanks!

 Have you been able to look at the other issue, concerning
 __ASSUME_FUTEX_CLOCK_REALTIME?

Yes.  Just saw this very timely message on the libc-alpha mail list
which has given me the clue as to what is wrong:
https://sourceware.org/ml/libc-alpha/2014-06/msg00227.html

Patch attached fixing lll_futex_timed_wait_bitset macro on alpha.

I have confirmed that it fixes the tst-rwlock6, tst-rwlock12, etc., test
suite failures on a compile of upstream glibc 2.19 branch.

Cheers
Michael.
diff --git a/ports/sysdeps/unix/sysv/linux/alpha/nptl/lowlevellock.h b/ports/sysdeps/unix/sysv/linux/alpha/nptl/lowlevellock.h
index 361bd342f159..dda2683cb0c6 100644
--- a/ports/sysdeps/unix/sysv/linux/alpha/nptl/lowlevellock.h
+++ b/ports/sysdeps/unix/sysv/linux/alpha/nptl/lowlevellock.h
@@ -90,7 +90,7 @@
 			  __lll_private_flag (__op, private),	  \
 			  (val), (timespec), NULL /* Unused.  */, 	  \
 			  FUTEX_BITSET_MATCH_ANY);			  \
-__ret;		  		  \
+INTERNAL_SYSCALL_ERROR_P (__ret, __err) ? -__ret : __ret; \
   })
 
 #define lll_futex_timed_wait(futexp, val, timespec, private) \

Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.

[Michael Cree]

On Tue, Jun 10, 2014 at 10:08:24PM +0200, Aurelien Jarno wrote:
 On Tue, Jun 10, 2014 at 09:45:30PM +0200, Mark Wielaard wrote:
  On Tue, 2014-06-10 at 21:25 +0200, Aurelien Jarno wrote:
   | Note that the asm in question comes from system tap, which has not been
   | ported to alpha.  So you're probably better off disabling that in your
   | (e)glibc build too.
  
  I asked Richard and he said that mainline GCC now allows the i
  constraint with a symbol, with an asm. So it shouldn't produce an error.
  What error are you seeing?
  
  stap might not know how to interpret such SDT ELF notes. Since systemtap
  is not known to work on alpha (I don't know for other SDT consumers like
  gdb and perf). But that would be independent of building with sys/sdt.h.
  So unless I misunderstood him things should compile fine, even if you
  decided to keep sys/sdt.h enabled for the glibc build on alpha.
  
  Of course, if none of the SDT consumers are known to work on alpha then
  having them might just be a noop and it should also be fine to disable
  them on that platform if you wish. But I don't think that is necessary.
 
 I don't have access to an alpha machine. Michael, could you please
 confirm that the patch from PR61336 does remove the ICE, but in addition
 allow the file to be compiled?

I found a moment earlier today to schedule a gcc build with the patch from
PR61336 and that has completed.

The file (preprocessed source of malloc/malloc.c from glibc with systemtap
headers included) which I have just reconfirmed generates an ICE with
gcc-4.8.3-2 like so:

gcc-4.8 /tmp/ccDghSDC.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline 
-Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe 
-Wstrict-prototypes -mlong-double-128 -mieee -mfp-rounding-mode=d  -fpic
malloc.c: In function ‘__libc_mallopt’:
malloc.c:4830:1: internal compiler error: in print_operand_address, at 
config/alpha/alpha.c:5454


now successfully compiles with gcc with the patch from PR61336, like so:


/home/mjc/toolchain/gcc-build/./gcc/xgcc -B/home/mjc/toolchain/gcc-build/./gcc/ 
/tmp/ccDghSDC.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline 
-Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe 
-Wstrict-prototypes -mlong-double-128 -mieee -mfp-rounding-mode=d  -fpic
In file included from malloc.c:1875:0:
arena.c: In function ‘ptmalloc_unlock_all2’:
arena.c:303:33: warning: right-hand operand of comma expression has no effect 
[-Wunused-value]
arena.c:313:25: warning: right-hand operand of comma expression has no effect 
[-Wunused-value]
In file included from malloc.c:1875:0:
arena.c: In function ‘_int_new_arena’:
arena.c:768:24: warning: right-hand operand of comma expression has no effect 
[-Wunused-value]


Seems I misunderstood RTH's commit comment; I saw the Use
output_operand_lossage bit and thought it meant that it would error out,
but now looking at the patch I see that is only for the default case of
the switch, not the bit handling the operand of the inline asm.

Aurelien: I guess I should file bugs against gcc-4.8 and gcc-4.9 to get
that fix into Debian's gcc as the commit does not seem to have been
backported into the upstream 4.8 and 4.9 branches.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.

[Michael Cree]

On Tue, Jun 10, 2014 at 10:08:24PM +0200, Aurelien Jarno wrote:
 On Tue, Jun 10, 2014 at 09:45:30PM +0200, Mark Wielaard wrote:
  On Tue, 2014-06-10 at 21:25 +0200, Aurelien Jarno wrote:
   On Tue, Jun 10, 2014 at 08:10:00PM +0200, Mark Wielaard wrote:
On Mon, 2014-06-09 at 18:02 +0200, Aurelien Jarno wrote:
 systemtap-sdt-dev was supposed to be something transparent for the
 glibc, but in practice it causes build failure on at least on alpha 
 (see
 above). Looking at the BTS, I see it also causes problems with GCC, 
 so I
 am a bit concerned on other side effects we might haven't seen yet.

Both issues were GCC bugs now fixed on mainline. See
https://gcc.gnu.org/PR61231 and http://gcc.gnu.org/PR61336.
The first one was not really related to sys/sdt.h at all. The second was
indeed a bug in GCC on alpha triggered by the usage of the i
constrained in the sys/sdt.h asm, now fixed.
  
   I doesn't seems to be the case. PR61336 is about the sys/sdt.h code
   triggering an ICE, and it has indeed been fixed. That said it now emits
   an error instead of an ICE, so sys/sdt.h is still not usable on alpha,
   as the last comment says:
   
   | Richard Henderson  2014-06-02 16:47:20 UTC  
   | The ICE has been resolved.
   | 
   | Note that the asm in question comes from system tap, which has not been
   | ported to alpha.  So you're probably better off disabling that in your
   | (e)glibc build too.
  
  I asked Richard and he said that mainline GCC now allows the i
  constraint with a symbol, with an asm. So it shouldn't produce an error.
  What error are you seeing?
  
  stap might not know how to interpret such SDT ELF notes. Since systemtap
  is not known to work on alpha (I don't know for other SDT consumers like
  gdb and perf). But that would be independent of building with sys/sdt.h.
  So unless I misunderstood him things should compile fine, even if you
  decided to keep sys/sdt.h enabled for the glibc build on alpha.
  
  Of course, if none of the SDT consumers are known to work on alpha then
  having them might just be a noop and it should also be fine to disable
  them on that platform if you wish. But I don't think that is necessary.
 
 I don't have access to an alpha machine. Michael, could you please
 confirm that the patch from PR61336 does remove the ICE, but in addition
 allow the file to be compiled?

OK, will do.  Might be a couple of days before I have the answer.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.

[Michael Cree]

Source: eglibc
Version: 2.19-1
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha
Justification: fails to build from source but built in the past
X-Debbugs-CC: debian-al...@lists.debian.org

eglibc FTBFS on alpha for two reasons, firstly, due to the inclusion of
systemtap headers and, secondly, because of what might be broken
FUTEX_CLOCK_REALTIME support in the kernel.

The systemtap header inclusion introduces an invalid unsplit symbol
reference to global_max_fast in inline asm leading to a failure to compile
malloc/malloc.c, which is the reason for the compiler ICE seen in the build
log at:

http://buildd.debian-ports.org/status/fetch.php?pkg=eglibcarch=alphaver=2.19-1stamp=1401942698

The compiler ICE is now fixed in gcc upstream (PR target/61336) to a
graceful error exit which won't help us in getting eglibc built on alpha.

So my question: can we have the systemtap-sdt-dev build-dep removed from
eglibc for a build on Alpha?  (And what are the implications of that?
Presumably nothing since even a number of official arches are not supported
by systemtap?)

With the systemtap headers removed the build gets to the test-suite with
ominous looking failures in tst-rwlock6, tst-rwlock11, tst-rwlock12, etc.
The assumption __ASSUME_FUTEX_CLOCK_REALTIME activated at kernel version
2.6.29 in the eglibc source would appear to be false for Alpha, or maybe the
test suite failures are due to a broken kernel (I tested with kernels 3.10.x
and 3.14.x and the build daemon is still on 3.13.x; all fail).  Whatever,
undefining __ASSUME_FUTEX_CLOCK_REALTIME results in correct behaviour for
the rwlock tests.  I attach a patch for that.

For a successful test build (with a 3.10.x kernel) I used in
debian/testsuite-checking/expected-results-alpha-linux-gnu-libc (and also
for the alphaev67 variant libc) the following:

annexc.out, Error 1 (ignored)
badsalttest.out, Error 1
run-conformtest.out, Error 1 (ignored)
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-cancelx17.out, Error 1
tst-cpuclock2.out, Error 1
tst-eintr1.out, Error 1
tst-mqueue5.out, Error 1
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1
tst-timer.out, Error 139
tst-waitid.out, Error 1
tst-writev.out, Error 1
tst-cputimer1.out, Error 1

In the libc build the test suite failures were

annexc.out, Error 1 (ignored)
badsalttest.out, Error 1
run-conformtest.out, Error 1 (ignored)
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-eintr1.out, Error 1
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1

and the encountered progressions were:

tst-cancelx17.out, Error 1
tst-cpuclock2.out, Error 1
tst-cputimer1.out, Error 1
tst-mqueue5.out, Error 1
tst-timer.out, Error 139
tst-waitid.out, Error 1
tst-writev.out, Error 1


In the alphaev67 build the test suite failures were:

annexc.out, Error 1 (ignored)
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1

so the encountered progressions were:

badsalttest.out, Error 1
run-conformtest.out, Error 1 (ignored)
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-cancelx17.out, Error 1
tst-cpuclock2.out, Error 1
tst-cputimer1.out, Error 1
tst-eintr1.out, Error 1
tst-mqueue5.out, Error 1
tst-timer.out, Error 139
tst-waitid.out, Error 1
tst-writev.out, Error 1

It would seem that the alphaev67 library build leads to a much more robust
library.

Cheers
Michael.

Index: eglibc-2.19/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h
===
--- eglibc-2.19.orig/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h
+++ eglibc-2.19/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h
@@ -93,4 +93,7 @@
 # define __ASSUME_FDATASYNC	1
 #endif
 
+/* Appears to have never worked on Alpha. */
+#undef __ASSUME_FUTEX_CLOCK_REALTIME
+
 #endif /* _KERNEL_FEATURES_H */