Re: Sparc status ?
Le 26/04/2014 22:59, Julien Cristau a écrit : On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote: No, that is not accurate. The main reason is that there are a number of issues with the sparc port currently that are not being addressed because apparently nobody is interested enough in the sparc port to fix the issues. Are you refering to the #731806 ? Going to 64bit userland is a huge leap forward. For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough. I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Cheers, Julien The main problem is that the 2 new buildd are Niagara machines which are not really stable. It left only 2 buildd which seems to be quit old and slow. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). Maybe what's missing is a couple of stable buildd to match the workload. Cheers. Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535e12c3.4070...@nerim.net
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 12:09, Thomas Schmitt a écrit :
Hi,
I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.
Ouch.
I have no Debian of arch sparc in reach.
I may provide you access to a shell account on my machines if needed.
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
... ./tmp/miniiso/cd_tree/
Valgrind on Linux accuses xorriso-1.3.2 of a small memory leak
with such a run, but not of memory problems.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the less efficient way.
Seems to me that there an alignment problem with xorriso.
That would rather be a C compiler problem then.
But given the strange error message of genisoimage, this may
well be a local filesystem peculiarity which causes a chain
of bad memory access with more or less random end.
I traced the problem with debugger, here's the catch:
--
(gdb) c
Continuing.
Breakpoint 3, compare_dirs (rr=0x1e1e60, ll=0x1e1e70) at
/home/seb/dev/cdrkit-1.1.11/genisoimage/write.c:652
652if ((*r)-assoc (*r)-assoc == (*l))
(gdb) p **r
$71 = {next = 0x1ea5b0, jnext = 0x0, isorec = {length = f,
ext_attr_length = , extent = \000\000\000\000\000\000\000,
size = \000\000\000\000\000\000\000, date =
r\004\031\001;\016\b, flags = \002, file_unit_size = , interleave
= ,
volume_sequence_number = \001\000\000\001, name_len = \001,
name = '\000' repeats 207 times}, starting_block = 0,
size = 0, priority = 0, jreclen = 0 '\000', name = 0x1ea948 .,
table = 0x0,
whole_name = 0x1ea958 ./tmp/miniiso/cd_tree/boot/., filedir =
0x1e1470, parent_rec = 0x0, de_flags = 0, inode = 2498532,
dev = 64774, rr_attributes = 0x1ea980 RR\005\001\201PX$\001mA,
rr_attr_size = 67, total_rr_attr_size = 67, got_rr_name = 0,
assoc = 0x0, hfs_ent = 0x0, hfs_off = 0, hfs_type = 0, sort = 0,
udf_file_entry_sector = 0, realsize = 0}
(gdb) p **l
$72 = {next = 0x1e9ba0, jnext = 0x0, isorec = {length = f,
ext_attr_length = , extent = \000\000\000\000\000\000\000,
size = \000\000\000\000\000\000\000, date =
r\004\031\001;\016\b, flags = \002, file_unit_size = , interleave
= ,
volume_sequence_number = \001\000\000\001, name_len = \001,
name = \001, '\000' repeats 206 times},
starting_block = 0, size = 0, priority = 0, jreclen = 0 '\000', name
= 0x1e1548 .., table = 0x0,
whole_name = 0x1e9f10 ./tmp/miniiso/cd_tree/boot/.., filedir =
0x1e1470, parent_rec = 0x0, de_flags = 0, inode = 2498510,
dev = 64774, rr_attributes = 0x1e9f38 RR\005\001\201PX$\001mA,
rr_attr_size = 67, total_rr_attr_size = 67, got_rr_name = 0,
assoc = 0x0, hfs_ent = 0x0, hfs_off = 0, hfs_type = 0, sort = 0,
udf_file_entry_sector = 0, realsize = 0}
(gdb) n
654if ((*l)-assoc (*l)-assoc == (*r))
(gdb)
644rpnt = (*r)-isorec.name;
(gdb)
645lpnt = (*l)-isorec.name;
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
(gdb) n
661errmsgno(EX_BAD,
--
So, strcmp shouldn't have yielded 0 when comparing the strings.
3- Fix the xorriso for alignment problem
I would love to get this done.
Can you get me a stack trace ?
Can you run it with valgrind and send me the message output ?
Hum, unfortunately, valgrind is not available for sparc.
If the failing machine is not the one which compiled xorriso
from the libisoburn source package, can you try with
wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz
tar xzf xorriso-1.3.2.tar.gz
cd xorriso-1.3.2 ./configure make
abs_path=$(pwd)
Without need for superuser or installation try:
cd ...where.appropriate...
$abs_path/xorriso/xorriso -as mkisofs ...above.options...
xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.
I'm compiling at this moment the vanilla xorriso from gnu. Let's see
what it yields.
Have a nice day :)
Thomas
Thanks, you too.
Seb
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e2d72.4070...@nerim.net
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
I may provide you access to a shell account on my machines if needed.
Yes, please.
Plus a directory tree
./tmp/miniiso/cd_tree
which can cause the xorriso crash.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the less efficient way.
I would suspect the habit of my libisofs predecessor developer
to use structs as access frame for byte arrays read from file.
But why then was it possible to produce
debian-7.4.0-sparc-netinst.iso
by xorriso-1.2.6 as can be read from its Preparer Id:
XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6,
LIBBURN-1.2.6
Does debian-cd pull sparc trees onto a non-sparc machine ?
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
Both values match the prescribed names for . and .. in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ., single byte 0x01 is ...
So, strcmp shouldn't have yielded 0 when comparing the strings.
Can this be caused by alignment problems ?
Hum, unfortunately, valgrind is not available for sparc.
Then gdb will have to do.
xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.
If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.
I'm compiling at this moment the vanilla xorriso from gnu.
Let's see what it yields.
It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/22916707656401032...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 01:20:20PM +0200, Thomas Schmitt wrote: Hi, I may provide you access to a shell account on my machines if needed. Yes, please. Plus a directory tree ./tmp/miniiso/cd_tree which can cause the xorriso crash. Sparc architecture is extremely picky about alignement. Bad alignement, yields SIGSEGV whereas intel only do it in the less efficient way. I would suspect the habit of my libisofs predecessor developer to use structs as access frame for byte arrays read from file. But why then was it possible to produce debian-7.4.0-sparc-netinst.iso by xorriso-1.2.6 as can be read from its Preparer Id: XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6 Does debian-cd pull sparc trees onto a non-sparc machine ? Yes. We build all the release images on an amd64 machine, pettersson.d.o -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428113544.ga30...@einval.com
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 13:20, Thomas Schmitt a écrit :
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
Both values match the prescribed names for . and .. in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ., single byte 0x01 is ...
Ok, I got the bug nailed.
Here's a sample session from my sparc:
--
cat test_strcmp.cEOF
#include stdio.h
#include stdlib.h
void main(void) {
char stra[2];
char strb[2];
int result = 0;
stra[0] = 0;
stra[1] = 0;
strb[0] = 1;
strb[1] = 0;
result = strcmp(stra,strb);
printf(result from strcmp('\\','\\0001' is %d)\n,result);
exit(0);
}
EOF
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is 0)
--
Here's the same sample from my intel workstation:
--
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is -1)
--
Typicaly, an endianness error.
If I apply this patch on cdrkit:
--- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
+++ genisoimage/write.c.new2014-04-28 13:31:07.255433923 +0200
@@ -656,7 +656,7 @@
#endif/* APPLE_HYB */
/* If the entries are the same, this is an error. */
-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 rpnt[0] == lpnt[0]) {
#ifdefUSE_LIBSCHILY
errmsgno(EX_BAD,
Error: '%s' and '%s' have the same ISO9660 name '%s'.\n,
Then the iso is correctly generated.
I'll file a bug with cdrkit. I think that genisoimage with that test is
unable to generated any iso at all on big endian machines.
So, strcmp shouldn't have yielded 0 when comparing the strings.
Can this be caused by alignment problems ?
Nope.
Hum, unfortunately, valgrind is not available for sparc.
Then gdb will have to do.
xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.
If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.
I'm compiling at this moment the vanilla xorriso from gnu.
Let's see what it yields.
It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)
I filed a bug with xorriso. Waiting for the number to show up.
Have a nice day :)
Thomas
You too ; ).
Seb
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\0001' is -1)
Typicaly, an endianness error.
But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under no endianness allowed to strcmp() == 0.
Endianness would only be of interest if you compare characters
of more than one byte each. (I.e. sizeof(char) == 2)
But that would be quite an odd environment for a C program.
char is neither guaranteed to be signed nor to be 8 bit.
Nevertheless programs would break in large numbers if that
assumption was not fulfilled.
-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 rpnt[0] == lpnt[0]) {
Are you sure that it does not miscompare other strings too ?
I think that genisoimage with that test is
unable to generated any iso at all on big endian machines.
I cannot agree with this diagnosis.
Not having a big-endian machine at hand now, i can confirm from
my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
a non-zero result with your example char arrays.
strcmp() may well be implemented by word comparisons. But then it
is the duty of the implementation to properly handle the ends of
the strings even if those are not word aligned.
I filed a bug with xorriso. Waiting for the number to show up.
I will hopefully get a notification via the pkg-libburnia-devel
list. Else i will bother you.
Steve McIntyre:
We build all the release images on an amd64 machine, pettersson.d.o
Ok. That explains why there are sparc-bootable ISOs from xorriso.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21777670788974871...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 14:15, Thomas Schmitt a écrit :
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\0001' is -1)
Typicaly, an endianness error.
But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under no endianness allowed to strcmp() == 0.
Ok, you are correct.
strcmp yields a bad result. I wasn't sure strcmp was doing byte comparaison.
However, memcmp function is ok.
-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 rpnt[0] == lpnt[0]) {
Are you sure that it does not miscompare other strings too ?
Basically, the fix is just to check, in case of strcmp() == 0 that the
first byte of each string is the same.
It's should be redundant operation if strcmp == 0 but not in the case of
strcmp is misbehaving.
It's just a workaround. The correct fix is, of course, to fix the strcmp.
Another workaround would be to use :
-if (strcmp(rpnt, lpnt) == 0) {
+if (memcmp(rpnt, lpnt,MAX_ISONAME+1) == 0) {
I think that genisoimage with that test is
unable to generated any iso at all on big endian machines.
I cannot agree with this diagnosis.
Not having a big-endian machine at hand now, i can confirm from
my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
a non-zero result with your example char arrays.
strcmp() may well be implemented by word comparisons. But then it
is the duty of the implementation to properly handle the ends of
the strings even if those are not word aligned.
Indeed, the correct fix is using strcmp. Meanwhile, the package is broken.
I filed a bug with xorriso. Waiting for the number to show up.
I will hopefully get a notification via the pkg-libburnia-devel
list. Else i will bother you.
Hum, still no answer. I'm going to fill it again.
Steve McIntyre:
We build all the release images on an amd64 machine, pettersson.d.o
Ok. That explains why there are sparc-bootable ISOs from xorriso.
I didn't imagine it could be doable.
Have a nice day :)
Thomas
Thanks for your time and dedication.
Seb
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e54ee.6050...@nerim.net
Re: Sparc status ?
The main problem is that the 2 new buildd are Niagara machines which are not really stable. It left only 2 buildd which seems to be quit old and slow. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). Maybe what's missing is a couple of stable buildd to match the workload. Interesting. I have a SB 2500 (2xUltraSPARC III) and I faced some instability when using 'git clone' on a kernel I compiled, but stock debian was OK. I wrote it off since I changed the default memory allocator and enabled a few experimental features, but maybe there is something more to this. Perhaps we should compare some kernel configurations and see where the source of instability might be. Patrick
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard sbern...@nerim.netwrote: Le 28/04/2014 16:05, Patrick Baggett a écrit : strcmp() may well be implemented by word comparisons. But then it is the duty of the implementation to properly handle the ends of the strings even if those are not word aligned. Indeed, the correct fix is using strcmp. Meanwhile, the package is broken. Wow, that's pretty bad. How did that slip? Also, are you building 64-bit or 32-bit code, and what CPU architecture (perhaps some per-CPU implementation is buggy but not others?) This information will help when tracking down the issue. I think this happens in this particular case comparing \000x and \. I had a look at my test_case, the build is 32bit and the called function is dynamic in the glibc. I tried a 64bit build, it's the same problem. I tried various optimization flags and using __builtin_strcmp withtout any change. Could you check this little program test against one of your machine ? Just to be sure ? Yeah sure, no problem -- I'll check it out soon. I'm somewhat comfortable with SPARC assembly, so I'll see if I can dig a little deeper into why it is failing.
Re: Sparc status ?
No, that is not accurate. The main reason is that there are a number of issues with the sparc port currently that are not being addressed because apparently nobody is interested enough in the sparc port to fix the issues. OK, what are the major issues and the bug # assigned to them? I'd like to keep sparc alive, I have working hardware, and I am very knowledgeable in C/C++ and to a lesser extent SPARC assembly. The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. That sounds bad. Suppose I have a kernel that I believe will resolve the issue. What is the process to test and verify that it's OK? Cheers, Julien
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, sorry for mis-posting the first reply for bug 746254 to this bug 731806. Meanwhile it turned out that the SIGBUS vanishes if i do not compile with -O2 or if i replace a-u = by memcpy(). So it seems worth to check whether genisoimage resp. strcmp() work properly if not compiled with -O2. A test with Sebastiens genisoimage options succeeded without error. /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \ -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree It looks ok, SPARC-boot-wise. SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs SUN SPARC secs/head: 640 SUN SPARC heads/cyl: 1 SUN SPARC partmap : N IdTag PermsStartCyl NumBlocks SUN SPARC partition: 1 0x0004 0x0010 0 16940 SUN SPARC partition: 2 0x0002 0x0010 0 16940 ... SUN SPARC partition: 8 0x0002 0x0010 0 16940 An additional option --md5 enabled confirmation that the ISO stream of libisofs was written flawlessly by libburn into the file test.iso. /home/thomas/xorriso-1.3.7/xorriso/xorriso \ -for_backup -indev test.iso -check_media -- xorriso is willing to load the ISO metadata and to compare it with the hard disk tree. /home/thomas/xorriso-1.3.7/xorriso/xorriso \ -indev test.iso -compare_r tmp-iso/miniiso/cd_tree / It only detects the consequences of option -r with directories (see man genisoimage / mkisofs): Permissions are set to r-xr-xr-x, owned by 0, group is 0. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/18128670805771551...@scdbackup.webframe.org
Re: Sparc status ?
Le 28/04/2014 16:12, Patrick Baggett a écrit : The main problem is that the 2 new buildd are Niagara machines which are not really stable. It left only 2 buildd which seems to be quit old and slow. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). Maybe what's missing is a couple of stable buildd to match the workload. Interesting. I have a SB 2500 (2xUltraSPARC III) and I faced some instability when using 'git clone' on a kernel I compiled, but stock debian was OK. I wrote it off since I changed the default memory allocator and enabled a few experimental features, but maybe there is something more to this. Perhaps we should compare some kernel configurations and see where the source of instability might be. Patrick My kernel are plain debian kernel, without modification. I had no issue at all with new kernel. I've been running 3.2 for 1-2 year with no issue. S. Bernard
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt scdbac...@gmx.net wrote: Hi, sorry for mis-posting the first reply for bug 746254 to this bug 731806. Meanwhile it turned out that the SIGBUS vanishes if i do not compile with -O2 or if i replace a-u = by memcpy(). Could you explain the context around this code? Perhaps the source is not really alignment safe and could use some patching upstream? I'd be happy to provide advice or code samples. So it seems worth to check whether genisoimage resp. strcmp() work properly if not compiled with -O2. A test with Sebastiens genisoimage options succeeded without error. /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \ -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree It looks ok, SPARC-boot-wise. SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs SUN SPARC secs/head: 640 SUN SPARC heads/cyl: 1 SUN SPARC partmap : N IdTag PermsStartCyl NumBlocks SUN SPARC partition: 1 0x0004 0x0010 0 16940 SUN SPARC partition: 2 0x0002 0x0010 0 16940 ... SUN SPARC partition: 8 0x0002 0x0010 0 16940 An additional option --md5 enabled confirmation that the ISO stream of libisofs was written flawlessly by libburn into the file test.iso. /home/thomas/xorriso-1.3.7/xorriso/xorriso \ -for_backup -indev test.iso -check_media -- xorriso is willing to load the ISO metadata and to compare it with the hard disk tree. /home/thomas/xorriso-1.3.7/xorriso/xorriso \ -indev test.iso -compare_r tmp-iso/miniiso/cd_tree / It only detects the consequences of option -r with directories (see man genisoimage / mkisofs): Permissions are set to r-xr-xr-x, owned by 0, group is 0. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/18128670805771551...@scdbackup.webframe.org
Re: Sparc status ?
Hi, Sébastien Bernard wrote: I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Not only them. All my Sparcs run Squeeze kernels, too, because neither Wheezy (3.2) nor Sid kernels (3.12 was the last one I tried IIRC) can provide uptimes more than a month. Sometimes they freeze just after a few days of uptime. Since I'm back on 2.6.32, I never had issues again. Current uptime 92 days. Example uprecords: From a Sparc installed with Sid in autumn 2013: # Uptime | System Boot up +--- - 192 days, 20:22:44 | Linux 2.6.32-5-sparc64-s Sat Jan 25 21:38:13 2014 224 days, 09:18:08 | Linux 3.10-2-sparc64-smp Sat Sep 7 16:16:29 2013 3 5 days, 23:12:41 | Linux 3.12-trunk-sparc64 Fri Nov 29 04:12:01 2013 4 4 days, 01:35:01 | Linux 3.12-trunk-sparc64 Sat Dec 7 15:32:05 2013 5 2 days, 22:44:57 | Linux 3.12-trunk-sparc64 Mon Jan 20 21:36:35 2014 6 2 days, 14:21:37 | Linux 3.10-3-sparc64-smp Wed Oct 2 04:16:49 2013 7 1 day , 15:14:57 | Linux 2.6.32-5-sparc64-s Tue Jan 19 04:14:07 2038 +--- From a Sparc running Wheezy since July 2013, stripped to those uptimes since the upgrade to Wheezy: 14 0 days, 00:19:43 | Linux 3.2.0-4-sparc64 Mon Jul 15 12:22:26 2013 15 0 days, 00:53:29 | Linux 3.2.0-4-sparc64 Mon Jul 15 13:14:06 2013 16 0 days, 00:07:17 | Linux 3.2.0-4-sparc64 Mon Jul 15 14:10:26 2013 17 209 days, 21:29:54 | Linux 2.6.32-5-sparc64Mon Jul 15 14:18:30 2013 - 1877 days, 07:11:40 | Linux 2.6.32-5-sparc64Mon Feb 10 10:50:23 2014 The latter has not much load, it's just an NTP server. On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding the gcc package 3 times - 8hours build - without any issue). It's good to hear that there are least some hardware architectures where recent kernels are more stable than on all my UltraSparcs. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428170618.gi6...@sym.noone.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
Patrick Baggett:
Could you explain the context around this code? Perhaps the source is
not really alignment safe and could use some patching upstream? I'd
be happy to provide advice or code samples.
The context was misposted to bug report 731806 as message #87:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
(but not with Cc to debian-sparc list).
Upstream is myself. :))
The code in question is by my unreachable libburn predecessors, though.
It belongs to the preparation of a thread start for one of five
occasions in libburn. SIGBUS happens at
http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149
The caller has a local struct (i.e. on stack) like (#L592, #L692):
struct write_opts write;
...
add_worker(Burnworker_type_writE, d,
(WorkerFunc) write_disc_worker_func, o);
The called function gets its address as parameter data (#L135):
static void add_worker(int w_type, struct burn_drive *d,
WorkerFunc f, void *data)
has a struct on heap (#L102, #L138, #L146):
struct w_list{
...
union w_list_data
{
...
struct write_opts write;
...
} u;
}
...
struct w_list *a;
...
a = calloc(1, sizeof(struct w_list));
The gesture which causes the SIGBUS is (#L149)
a-u = *(union w_list_data *)data;
which is not what i personally would use, but should be fully legal
nevertheless.
The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the a-u = gesture by
memcpy((a-u), data, sizeof(union w_list_data));
which i deem equivalent (and more my personal style).
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20365670802973806...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, i wrote: struct write_opts write; ... add_worker(Burnworker_type_writE, d, (WorkerFunc) write_disc_worker_func, o); Urgh. I copied the wrong struct definition. Line 592 bears of course: struct write_opts o; which is used in the call of add_worker(). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9919670809032917...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt scdbac...@gmx.net wrote:
Hi,
Patrick Baggett:
Could you explain the context around this code? Perhaps the source is
not really alignment safe and could use some patching upstream? I'd
be happy to provide advice or code samples.
The context was misposted to bug report 731806 as message #87:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
(but not with Cc to debian-sparc list).
Upstream is myself. :))
The code in question is by my unreachable libburn predecessors, though.
It belongs to the preparation of a thread start for one of five
occasions in libburn. SIGBUS happens at
http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149
The caller has a local struct (i.e. on stack) like (#L592, #L692):
struct write_opts write;
...
add_worker(Burnworker_type_writE, d,
(WorkerFunc) write_disc_worker_func, o);
The called function gets its address as parameter data (#L135):
static void add_worker(int w_type, struct burn_drive *d,
WorkerFunc f, void *data)
has a struct on heap (#L102, #L138, #L146):
struct w_list{
...
union w_list_data
{
...
struct write_opts write;
...
} u;
}
...
struct w_list *a;
...
a = calloc(1, sizeof(struct w_list));
The gesture which causes the SIGBUS is (#L149)
a-u = *(union w_list_data *)data;
which is not what i personally would use, but should be fully legal
nevertheless.
I'm not sure what the problem is exactly here. 64-bit SPARC will use ldx to
load 64-bit quantities, which can cause problems if the source data is only
4-byte aligned, but that doesn't seem to be the case here. I really need a
disassembly and to be able to probe the runtime stack a bit, so that really
means that I need to build the code. :)
I think as a more meta-problem is this: the code's logic for how much to
copy is wrong. It copies too many bytes on many cases and violates the C
contract that you'll only copy like objects using =.
Imagine:
sizeof(struct erase_ops) == 8 (32-bit ABI)
sizeof(w_list_data) == at least 12 (32-bit ABI).
Suppose: data = some_erase_ops
a-u = *(union w_list_data *)data; // copies 12 bytes from 8 byte area, can
cause crashes if the last 4 bytes are into an unmapped page.
The correct way to do this would be to have add_worker() pass a const
w_list_data* with the appropriate field(s) in '.u' filled out. Otherwise,
you're copying unlike objects *of different sizes* and that's never safe.
---
Patrick
The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the a-u = gesture by
memcpy((a-u), data, sizeof(union w_list_data));
which i deem equivalent (and more my personal style).
Have a nice day :)
Thomas
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, I really need a disassembly and to be able to probe the runtime stack a bit, so that really means that I need to build the code. :) The current example would be a bit too opulent, i guess: -rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso (wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz untar, cd xorriso-1.3.2, ./configure, make, ls -l xorriso/xorriso, crash by: xorriso/xorriso -outdev stdio:/dev/null -map ./xorriso / ) I'll try to reproduce by a smaller program on Sebastien's system. I think as a more meta-problem is this: the code's logic for how much to copy is wrong. It copies too many bytes on many cases and violates the C contract that you'll only copy like objects using =. [...] you're copying unlike objects of different sizes and that's never safe. It's the job of a C union to provide a common hull around objects of different size. One may dispute whether using union is a good idea (like overloading in the OO paradigm). But unions are part of C since KR and they are supposed to be safe. http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions As for the cost: The threads are running big operations of libburn. Even a full MB of copying would not make much difference. Elsewise i agree with you. I would have written it differently, too. But i will try to keep the necessary changes as small as possible. So the union approach will most probably stay unless i get convinced that it is faulty C language. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5941670806243473...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Seb,
Yes, I can reproduce this issue.
{ 1, 0 }
{ 1, 1 }
returns 0, when it should return -1.
Interestingly, if you use:
{ 1, 1, 1, 1, 0 } //i.e. 5 bytes
{ 1, 1, 1, 1, 1 } //i.e. 5 bytes
as the strings, it returns -1. So it clearly has a problem if the string is
exceptionally short. That got me thinking. How short?
{ 1, 1, 1, 0 } //i.e. 4 bytes, returns -1
{ 1, 1, 1, 1 }
{ 1, 1, 0 } //i.e. 3 bytes, returns -1
{ 1, 1, 1 }
{ 1, 0 } //i.e. 2 bytes, return -1
{ 1, 1 }
{ 0 } //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
{ 1 }
So the 1-bye case succeeded, but why? The only difference between that and
the failing case was two null bytes which shouldn't even be examined.
{ 0, 0 } //i.e. original test case. Fails, returns 0
{ 1, 0 }
{ 1, 0, 0 } //fails, returns 0.
{ 1, 1, 0 }
{ 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 0 }
{ 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 0 }
{ 1, 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 1, 0 }
... ok ... ?
So apparently, ending with a null character that shouldn't even be examined
messes things up? Let's try something radically different:
{ 1, 1, 1, 1, 0, 0xaa } //returns -1, OK
{ 1, 1, 1, 1, 1, 0 }
{ 1, 1, 1, 1, 0, 0 } //returns -1, OK
{ 1, 1, 1, 1, 1, 0xaa }
{ 1, 1, 1, 1, 0, 0xaa} //returns -1, OK
{ 1, 1, 1, 1, 1, 0xbb }
On Mon, Apr 28, 2014 at 6:35 AM, Sébastien Bernard sbern...@nerim.netwrote:
Le 28/04/2014 13:20, Thomas Schmitt a écrit :
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
Both values match the prescribed names for . and .. in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ., single byte 0x01 is ...
Ok, I got the bug nailed.
Here's a sample session from my sparc:
--
cat test_strcmp.cEOF
#include stdio.h
#include stdlib.h
void main(void) {
char stra[2];
char strb[2];
int result = 0;
stra[0] = 0;
stra[1] = 0;
strb[0] = 1;
strb[1] = 0;
result = strcmp(stra,strb);
printf(result from strcmp('\\','\\0001' is %d)\n,result);
exit(0);
}
EOF
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is 0)
--
Here's the same sample from my intel workstation:
--
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is -1)
--
Typicaly, an endianness error.
If I apply this patch on cdrkit:
--- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
+++ genisoimage/write.c.new2014-04-28 13:31:07.255433923 +0200
@@ -656,7 +656,7 @@
#endif/* APPLE_HYB */
/* If the entries are the same, this is an error. */
-if (strcmp(rpnt, lpnt) == 0) {
+if (strcmp(rpnt, lpnt) == 0 rpnt[0] == lpnt[0]) {
#ifdefUSE_LIBSCHILY
errmsgno(EX_BAD,
Error: '%s' and '%s' have the same ISO9660 name '%s'.\n,
Then the iso is correctly generated.
I'll file a bug with cdrkit. I think that genisoimage with that test is
unable to generated any iso at all on big endian machines.
So, strcmp shouldn't have yielded 0 when comparing the strings.
Can this be caused by alignment problems ?
Nope.
Hum, unfortunately, valgrind is not available for sparc.
Then gdb will have to do.
xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.
If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.
I'm compiling at this moment the vanilla xorriso from gnu.
Let's see what it yields.
It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)
I filed a bug with xorriso. Waiting for the number to show up.
Have a nice day :)
Thomas
You too ; ).
Seb
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt scdbac...@gmx.net wrote:
Hi,
I really need a disassembly and to be able to probe the runtime
It's the job of a C union to provide a common hull around objects
of different size. One may dispute whether using union is a good
idea (like overloading in the OO paradigm). But unions are part of C
since KR and they are supposed to be safe.
http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions
No, it's plain wrong. Unions are fine, if used properly. You aren't using
them properly. Let me show you how by a more extreme example:
#include stdlib.h
struct small {
int a;
};
struct big {
int b[1024*1024];
};
union both {
struct small imSmall;
struct big imBig;
};
void copy(union both* b, void* data) {
*b = *(union both*)data; //copies 4MB of data.
}
void main() {
struct small smallThing;
union both* bothThings = malloc(sizeof(union both));
copy(bothThings, smallThing); // NOT OK. struct small cannot NOT be
converted to union both.
}
figgles@ghost:~$ ./big
Segmentation fault
The problem is that union can convert to a member (by accessing the field),
but a member CANNOT convert to a union. add_worker() takes a member and
tries to convert it to a union. This is WRONG. Period.
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, No, it's plain wrong. Unions are fine, if used properly. You aren't using them properly. Duh. You convinced me. The callers do it wrong, indeed. They would have to use local union variables instead of their actual structs. The parameter of add_worker() should be a pointer to the union, not a pointer to void. Obviously the bug normally stays withing populated stack area. Three cheers for the picky systems ! I'll stop the attempt to reproduce the problem in a smaller program and rather fix libburn. (That will result in some testing plight on the less picky systems.) Thank you for pointing me to this bug. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16290670797627595...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
On 28/04/2014 18:25, Thomas Schmitt wrote:
has a struct on heap (#L102, #L138, #L146):
struct w_list{
...
union w_list_data
{
...
struct write_opts write;
...
} u;
}
...
struct w_list *a;
...
a = calloc(1, sizeof(struct w_list));
The gesture which causes the SIGBUS is (#L149)
a-u = *(union w_list_data *)data;
The issue is that data needs to be suitably aligned on an appropriate
memory boundary. SPARC requires that int32 accesses are aligned on 4
byte boundaries and that int64 aligns on 8 byte boundaries.
You have to arrange that data is properly aligned or you will get a
SIGBUS due to an address misalignment.
malloc and calloc arrange that the alignment is suitable
(the manpage says)
RETURN VALUE
The malloc() and calloc() functions return a pointer to the allocated
memory that is suitably aligned for any kind of variable.
I'm guessing that your void *data isn't directly allocated by calloc so
it doesn't necessarily have the correct alignment.
which is not what i personally would use, but should be fully legal
nevertheless.
The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the a-u = gesture by
memcpy((a-u), data, sizeof(union w_list_data));
which i deem equivalent (and more my personal style).
The memcpy version will work just fine because memcpy takes
misalignments into account and once the data has been copied into a-u
the calloc'd version of struct w_list will be properly aligned because
calloc guarantees that it will be.
memcpy is the correct thing to use in your case.
Regards
Richard
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ea3fc.8010...@oldelvet.org.uk
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, Sebastien's machine now has a xorriso-1.3.7 (the current development snapshot) with changed libburn/async.c. The callers of add_worker() now declare: union w_list_data o; rather than struct union_member o; The type of the fourth parameter of add_worker has been changed from (void *) to (union w_list_data *). The formerly SIGBUSsing statement became quite elegant a-u = *data; Given that it is a good bug catcher on Debian sparc, and more concise than e.g. memcpy((a-u), data, sizeof(union w_list_data)); i tend to keep it. To Sebastien: Please give /home/thomas/xorriso-1.3.7/xorriso/xorriso a thorough testing with your debian-cd setup. (make dist should even pack it up to a usable tarball) Whatever the outcome will be with that strange strcmp() bug, your original alternatives 1 and 2 have small chances to succeed unless we declare surrender on 3. 1- It has been publicly stated in the past that Debian will not accept a package with original mkisofs. Stated reason was social incompatibility with its author. 2- Steve McIntyre prefers xorriso to take over genisoimage tasks rather than changing genisoimage code. From his view, xorriso is comfortably self-maintaining. :)) I try to give him few reason to regret this strategy. 3- A xorriso candidate (rather stack sanitized than alignment corrected) has now been beamed onto your machine. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1987567089955...@scdbackup.webframe.org
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 22:01, Thomas Schmitt a écrit : Hi, Sebastien's machine now has a xorriso-1.3.7 (the current development snapshot) with changed libburn/async.c. The callers of add_worker() now declare: union w_list_data o; rather than struct union_member o; The type of the fourth parameter of add_worker has been changed from (void *) to (union w_list_data *). The formerly SIGBUSsing statement became quite elegant a-u = *data; Given that it is a good bug catcher on Debian sparc, and more concise than e.g. memcpy((a-u), data, sizeof(union w_list_data)); i tend to keep it. To Sebastien: Please give /home/thomas/xorriso-1.3.7/xorriso/xorriso a thorough testing with your debian-cd setup. (make dist should even pack it up to a usable tarball) Whatever the outcome will be with that strange strcmp() bug, your original alternatives 1 and 2 have small chances to succeed unless we declare surrender on 3. 1- It has been publicly stated in the past that Debian will not accept a package with original mkisofs. Stated reason was social incompatibility with its author. 2- Steve McIntyre prefers xorriso to take over genisoimage tasks rather than changing genisoimage code. From his view, xorriso is comfortably self-maintaining. :)) I try to give him few reason to regret this strategy. 3- A xorriso candidate (rather stack sanitized than alignment corrected) has now been beamed onto your machine. Have a nice day :) Thomas Thomas, I'm trying to rebuild from sid now, since sparc has been removed from jessie. Cheers Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535eb924.5070...@nerim.net
Re: sparc has been pulled from jessie
On Mon, Apr 28, 2014 at 3:40 PM, Sébastien Bernard sbern...@nerim.netwrote: Well, folks, I think this is one step closer to the end. The sparc has been removed from the jessie archive. That's a shame cause the problem with the generation of the debian-installer is about to be fixed. There was no final notice, or maybe I missed it. I don't think they will reconsider. Maybe some debian developper can argue for our case. Bah. I don't even know what the requirements for staying in the cool kids club are or how close/far sparc is from meeting them. I was hearing gcc 4.8 noise, but I've had gcc-4.8 installed on my machine for a long time and never had a problem with it. Not really sure what needs to be done for debian version N+1 to get sparc back in. Anyway, I'll try keep it alive as hard as I'm able to. Yeah, same. Too much sparc HW to quit. :) Patrick
Install debian netboot in sunblade 150 sparc
Hello,
This is my first post hope I do a silly question.
I'm installing Debian on Sun workstation SunBlade150 CDROM does not work as
me, I'm trying to install with netboot.
The OS is Debian 7.
First of all turn off the DHCP of the Router.
The gateway is 192.168.1.1 my touter
The IP 192.168.1.103 Debian server
This is my isc-dhcp-server
gedit /etc/dhcp/dhcpd.conf
option domain-name example.org;
option domain-name-servers 80.148.8.4, 80.148.8.2;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.200 192.168.1.250;
option routers 192.168.1.1;
filename boot.img;
}
This is my tftpd-hpa
#host Oracle {
# filename /boot.img;
# server-name debian;
# next-server debian;
# hardware ethernet 00:03:BA:94:89:97;
# fixed-address 192.168.1.103;
#}
gedit /etc/default/tftpd-hpa
# /etc/default/tftpd-hpa
TFTP_USERNAME=tftp
TFTP_DIRECTORY=/srv/tftp
TFTP_ADDRESS=0.0.0.0:69
TFTP_OPTIONS=--secure
Restart tftpd-hpa and isc-dhcp-server
I do not get to start the installation program on the machine I boot sun
boot net or net boot boot.img.
In gedit /var/log/messages shows me no errors
Where is the fault?
Thanks and regards.
FWIW -- I consider sparc useful, pity if its support ends completely
First of all -- thanks everyone who previously helped to maintain SPARC Debian. IMHO your work was very useful! FWIW -- I have got acquainted with sparc originally solely due to the need to troubleshoot FTBFS of some packages I maintain on this alien to me platform... But probably in a somewhat a masochistic way I got to like sparc -- at times those FTBFS due to e.g. failing unittests I exercise at build time pointed to real problems with the code, which otherwise would have waited possibly for years to be encountered by users consciously, while may be still getting some (incorrect) output without causing the entire program/pipeline to blow. For that I started to maintain now 2 sparc boxes as a part of the test build farm where I provide CI for some popular projects I maintain -- and found it being extremely useful. Developers can easily find access to x86 boxes for testing but not to such boxes of less commodity. I have not been using those two sparc boxes for anything else besides CI, BUT I got to like them -- despite their respectful age they remain quite performant making me consider employing similar retirees to serve as regular 'servers' for occasional local needs. With Debian dropping support for sparc unfortunately I would need to stop providing similar unique testing opportunity for those projects, which would not be the end of the world, but kinda a pity since sparcs seems to be quite nice and which helped to gain more geeky gratitude for Debian being somewhat unique in its spread of support. P.S. I wondered now if somehow we could attract students taking some 'advanced computer architecture' courses at the universities... usually core 'computer architecture' courses are too abstract to promote participating in hands-on experiences such as fixing specific architecture-specific issues in compilers... but may be at more advanced levels Debian's breadth might intrigue some scholars, and hopefully bring at least some fresh blood to Debian. (was more of thinking out loud than anything practically useful I guess). -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429021403.gk8...@onerussian.com
Re: FWIW -- I consider sparc useful, pity if its support ends completely
Are we still able to move on with Debian Sparc64 @ debian-ports.org? Creating a bootable minimal ISO would help? https://wiki.debian.org/Sparc64 Thanks, Frans van Berckel -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20e8e144374438a08d15687453a5dc38.squir...@webmail.xs4all.nl
