Re: Sid on ultra1 status

[Romain Dolbeau]

2018-08-14 19:32 GMT+02:00 John Paul Adrian Glaubitz
:

> Are you booting with a serial console? If yes, try adding "console=ttyS0"
> or whatever is your serial device. Although that *should* be added
> automatically.

No, unfortunately I don't have serial-capable hardware (or cable) were
the machine lives at the moment.
I boot graphically - type 5 kbd & mouse, 17" 1280x1024 LCD on the
FFB2+ (Creator 3D serie 2).

At the stage where the systems hangs, linux has already switched the
console AFAICT.
I can interact with the shells spawned by BOOT_DEBUG=3 with no issue
(well, the first two before the hang).

Cordially,

-- 
Romain Dolbeau

Re: Sid on ultra1 status

[John Paul Adrian Glaubitz]

On 08/14/2018 06:05 PM, Romain Dolbeau wrote:
> Trying to install from the 2018-05-18 image doesn't work. The system
> hangs after displaying "starting syslogd, klogd". I tried
> BOOT_DEBUG=3, the first two shells are fine - and it seems the disks
> are seen on the ESP SCSI. Immediately after the second shell, the
> syslogd/klogd line, and then nothing.

Are you booting with a serial console? If yes, try adding "console=ttyS0"
or whatever is your serial device. Although that *should* be added
automatically.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Sid on ultra1 status

[Romain Dolbeau]

2018-08-14 18:11 GMT+02:00 Romain Dolbeau :
> Does it mean that when grub 'search' for the /boot UUID, it gets the
> wrong device entry ? (missing @sd1,0)

There's definitely a bug somewhere, as 'ls' in the grub command line
also generates the errors and hang...

However - when loading, 'grub' sets the $root variable to something
similar, starting with ieee1275 and featuring some escapes.
So if I don't set 'root' at all - grub looks in its own partition, and
everything seems to work fine...

The entry that actually works (minus the root UUID):

#
menuentry 'SIMPLE Debian GNU/Linux' --class debian --class gnu-linux --class gnu
 --class os $menuentry_id_option 'gnulinux-simple' {
load_video
echo  'insmod gzio'
insmod gzio
echo  'insmod part_sun'
insmod part_sun
echo  'insmod ext2'
insmod ext2
echo  'set root'
set root='ieee1275//sbus@1f\,0/SUNW\,fas@e\,880/sd@1\,0,sun1'
echo'Loading Linux 4.17.0-1-sparc64 ...'
linux   /vmlinuz-4.17.0-1-sparc64 root=UUID=X-X-X-X-X ro
echo'Loading initial ramdisk ...'
initrd  /initrd.img-4.17.0-1-sparc64
}
#

So it's the dev name prefixed by ieee1275/, '\' before all ',', and
',sun1' to indicate the partition (no \ on this comma)...

2018-08-14 19:08 GMT+02:00 Gregor Riepl :
> I believe this is 'normal', I got the same with two different video adapters.
> (Creator3D and Mach64)

OK, so it's not the source for the messed up 'search' and 'ls', we can suppose.

> I don't think I can help you, but I did have lots of floppy drive problems on
> my system, so I simply unhooked it. Might be that the Linux floppy driver is
> currently broken, or a hardware problem.

There's a floppy slot but no actual drive in there. 'search' has
--no-floppy by default...
Weird that it tries, but that just may be the same bug twice: grub
uses a wrong dev entry?

Cordially,

-- 
Romain Dolbeau

Re: Sid on ultra1 status

[Gregor Riepl]

> 1) when grub starts, after "GRUB Loading kernel", I have two error lines:
> #
> error: out of memory.
> error: no suitable video mode found.
> #
> then I get the menu just fine anyway.

I believe this is 'normal', I got the same with two different video adapters.
(Creator3D and Mach64)

> 2) after selecting the Debian entry from the menu I get:
> #
> Recalibrate failed. The floppy drive is either missing, improperly
> connected, or defective.
> error: unable to open /sbus/@1f,0/SUNW,fdtwo@f,140.
> #
> and then nothing.
> Sometimes I get a second error, but mentioning a path to a hard drive
> - "/sbus/SUNW,fas@e,880/sd", with the final @0,0 (or @1,0)
> missing. I'm not able to reproduce this second error at the moment,
> don't know why.

I don't think I can help you, but I did have lots of floppy drive problems on
my system, so I simply unhooked it. Might be that the Linux floppy driver is
currently broken, or a hardware problem.

Re: Sid on ultra1 status

[Romain Dolbeau]

> 1) when grub starts, after "GRUB Loading kernel", I have two error lines:
> #
> error: out of memory.
> error: no suitable video mode found.
> #
> then I get the menu just fine anyway.
> 2) after selecting the Debian entry from the menu I get:
> #
> Recalibrate failed. The floppy drive is either missing, improperly
> connected, or defective.
> error: unable to open /sbus/@1f,0/SUNW,fdtwo@f,140.
> #
> and then nothing.
> Sometimes I get a second error, but mentioning a path to a hard drive
> - "/sbus/SUNW,fas@e,880/sd", with the final @0,0 (or @1,0)
> missing. I'm not able to reproduce this second error at the moment,
> don't know why.

I patched the grub.cfg to remove some conditionals and 'echo' every
command. As far I can tell, the 'search' command is failing.
I did get the 2nd error message:

#
Invalid SCSI target number fff9afc8
error: unable to open /sbus/SUNW,fas@e,880/sd.
#

Does it mean that when grub 'search' for the /boot UUID, it gets the
wrong device entry ? (missing @sd1,0)

Cordially,

-- 
Romain Dolbeau

Sid on ultra1 status

[Romain Dolbeau]

Hello,

Quicl status update on running current Sid on my Ultra 1 200E (w/ 1
GiB of RAM and an horizontal FFB2+ in the UPA slot).

Upgrading my old install to what was available august 11, including
kernel 4.6, went just fine. The machine boots with Silo, and
everything is fine.

Trying to install from the 2018-05-18 image doesn't work. The system
hangs after displaying "starting syslogd, klogd". I tried
BOOT_DEBUG=3, the first two shells are fine - and it seems the disks
are seen on the ESP SCSI. Immediately after the second shell, the
syslogd/klogd line, and then nothing.

So I used multistrap again to do another install on a second drive and
try grub2. Booted from the Silo on the first drive, the new install
works fine (with kernel 4.17, though it seems to hand on reboot).
However, I can't get grub2 to boot it :-(
1) when grub starts, after "GRUB Loading kernel", I have two error lines:
#
error: out of memory.
error: no suitable video mode found.
#
then I get the menu just fine anyway.
2) after selecting the Debian entry from the menu I get:
#
Recalibrate failed. The floppy drive is either missing, improperly
connected, or defective.
error: unable to open /sbus/@1f,0/SUNW,fdtwo@f,140.
#
and then nothing.
Sometimes I get a second error, but mentioning a path to a hard drive
- "/sbus/SUNW,fas@e,880/sd", with the final @0,0 (or @1,0)
missing. I'm not able to reproduce this second error at the moment,
don't know why.

This is the same kernel & initrd as with Silo - so it is known to work
on this machine...

Cordially,

-- 
Romain Dolbeau


-- 
Romain Dolbeau

Rust architecture status

[John Paul Adrian Glaubitz]

Please answer to pkg-rust-maintain...@lists.alioth.debian.org. Don't answer
to debian-ports@l.d.o (just let your mail client honor the Reply-To field).

Hello!

I would like to a quick heads-up regarding the architecture status of Rust
after having had at the possibilities to get it bootstrapped for the remaining
architectures in Debian.

This is as of Rust 1.24.

alpha
=

Status:

No port yet. But until around version version 3.1, LLVM used to have an
official port for Alpha. So porting LLVM and consequently to Alpha should
generally feasible if LLVM upstream would be willing to merge an Alpha
port of LLVM back in.

armel
=

Status:

Is generally supported; pre-compiled binaries from the Rust website
work but trying to bootstrap the Debian package results in LLVM
bailing out with:

"LLVM ERROR: Broken function found, compilation aborted!"

Necessary work:

Can be most likely get to work by using the embedded copy of LLVM
instead of Debian's llvm-toolchain-4.0 package. See also powerpc.

hppa
====

Status:

Currently no LLVM port that I know of. mrustc might be an alternative.

ia64
====

Status:

Same as for Alpha. The ia64 port of LLVM was never officially merged
though. But it was done by the original LLVM compiler team though when
ia64 was still cool.

m68k
====

Status:

I started adding the necessary bits and pieces in a branch for the
Rust compiler but since there is no complete LLVM port for m68k yet,
porting Rust to m68k is currently not possible. I'm very confident
it will happen in the future though. We might be able to use mrustc
in the meantime which compiles Rust code to C code which can then
be compiled using gcc.

Necessary work:

- https://github.com/M680x0/M680x0-llvm/blob/M680x0/lib/Target/M680x0/TODO.md
- Finish the work I started on Rust for m68k and get it merged upstream

mips
====

Status:

Both pre-compiled as well as freshly compiled binaries of the Rust
compiler crash quite early when trying to build the Rust compiler
natively on mips. See: http://paste.debian.net/1011381/

Necessary work:

Fix the above crash. Could also be a bug in LLVM.

mips64el
====

Status:

Rust compiler seems generally relatively stable and compiling the compiler
natively on mips64el will progress quite far but the linker will eventually
bail out with "error adding symbols: Bad value" (I accidentally pasted the
full backtrace into a pastebin with an expiration date :().

Necessary:

Fix the above crash. Could also be a bug in LLVM or binutils.

mipsel
==

Not tested. Most likely similar behavior as on mips.

powerpc
===

Status:

Trying to bootstrap the Rust compiler Debian package using Debian's LLVM
compiler through the llvm-toolchain-4.0 package eventually bails out
with:

"LLVM ERROR: Broken function found, compilation aborted!" (same as error
as on armel). Switching the Debian compiler to use the internal LLVM
copy let's the build almost finish. The build eventually fails with
Rust's fabricate tool crashing with an overflow.

powerpcspe
==

Status:

No official port. But since LLVM supports the SPE CPU extensions on
PowerPCSPE adding support for this architecture should be any more
complex than it was to add x32 support to Rust.

Otherwise, the compiler is expected to suffer from the same bugs as
on powerpc.

sparc
=

Status:

Some pieces were missing in Rust upstream which I have opened a pull
request for. Additional small changes will be necessary in packages
like cc-rs and possibly libc (the Rust package).

Otherwise, it should be as usable as Rust on sparc64. I expect Rust
on 32-bit sparc to become usable once the Gentoo folks get around
bootstrapping it. They're currently busy fixing their sparc port.

Necessary work:

Get missing pieces merged upstream. Actually bootstrap the compiler.

sparc64
===

Status:

As of version 1.24, the compiler is very stable and can be used to
compile itself, Cargo and the Rust code in Firefox and Thunderbird.
It has been bootstrapped in Debian.

However, both the testsuites for rustc and cargo do not pass all
tests on sparc64. Although, to be fair, the amount of tests in
both testsuites is crazy and SPARC might simply have some peculiarities
that the Rust people haven't been thinking about. SPARC has always
been the special snowflake of architectures when it comes to otherwise
subtle bugs.

Necessary work:

Fix the testsuites for rustc and cargo and make sure the issues are
resolved for sparc (32-bit) as well.

For the time being, the testsuites for cargo and rustc should be
ignored/disabled on sparc64.

x32
===

Status:

Compiler mostly works and can be used to build cargo but not itself,
crashes with: http://paste.debian.net/1011382/.

Also, crates like "time" and "filetime" still suffer from the fact
that x32 is a 32-bit architecture with a 64-bit kernel interface
(see: https://sourceware.org/bugzilla/show_bug.cgi?id=16437). As
a result, using libc::c_long doesn't work. We

Re: Current status of OpenJDK-9 on sparc64

[John Paul Adrian Glaubitz]

k/hotspot/src/share/vm/runtime/deoptimization.cpp	2014-01-15 10:55:37.031083968 +
@@ -815,7 +815,7 @@
 #ifdef _LP64
   jlong res = (jlong)low->get_int();
 #else
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
   // For SPARC we have to swap high and low words.
   jlong res = jlong_from((jint)low->get_int(), (jint)value->get_int());
 #else
@@ -866,7 +866,7 @@
 #ifdef _LP64
   jlong res = (jlong)low->get_int();
 #else
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
   // For SPARC we have to swap high and low words.
   jlong res = jlong_from((jint)low->get_int(), (jint)value->get_int());
 #else
--- openjdk/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp.old	2014-01-14 21:26:34.0 +
+++ openjdk/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp	2014-01-15 10:55:37.035083997 +
@@ -62,7 +62,7 @@
   }
 #endif
 
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
   if (FLAG_IS_DEFAULT(InlineSmallCode)) {
 FLAG_SET_DEFAULT(InlineSmallCode, 2500);
   }
--- openjdk/hotspot/src/share/vm/runtime/stackValue.cpp.old	2014-01-14 21:26:34.0 +
+++ openjdk/hotspot/src/share/vm/runtime/stackValue.cpp	2014-01-15 10:55:37.023083908 +
@@ -34,7 +34,7 @@
 // Stack or register value
 Location loc = ((LocationValue *)sv)->location();
 
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
 // % Callee-save floats will NOT be working on a Sparc until we
 // handle the case of a 2 floats in a single double register.
 assert( !(loc.is_register() && loc.type() == Location::float_in_dbl), "Sparc does not handle callee-save floats yet" );
--- openjdk/hotspot/src/share/vm/runtime/arguments.cpp.old	2014-01-14 21:26:34.0 +
+++ openjdk/hotspot/src/share/vm/runtime/arguments.cpp	2014-01-15 10:55:37.043084056 +
@@ -1993,7 +1993,7 @@
 
   status = status && verify_object_alignment();
 
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
   if (UseConcMarkSweepGC || UseG1GC) {
 // Issue a stern warning if the user has explicitly set
 // UseMemSetInBOT (it is known to cause issues), but allow
--- openjdk/hotspot/src/share/vm/c1/c1_Runtime1.cpp.old	2014-01-14 21:26:34.0 +
+++ openjdk/hotspot/src/share/vm/c1/c1_Runtime1.cpp	2014-01-15 10:55:37.063084203 +
@@ -1074,7 +1074,7 @@
 RelocIterator iter(nm, (address)instr_pc, (address)(instr_pc + 1));
 relocInfo::change_reloc_info_for_address(, (address) instr_pc,
  relocInfo::none, relocInfo::oop_type);
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
 // Sparc takes two relocations for an oop so update the second one.
 address instr_pc2 = instr_pc + NativeMovConstReg::add_offset;
 RelocIterator iter2(nm, instr_pc2, instr_pc2 + 1);
--- openjdk/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp.old	2014-01-14 21:26:34.0 +
+++ openjdk/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp	2014-01-15 10:55:37.047084085 +
@@ -577,7 +577,7 @@
   monitor_address(op->in_opr()->as_constant_ptr()->as_jint(), op->result_opr());
   break;
 
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
 case lir_pack64:
   pack64(op->in_opr(), op->result_opr());
   break;
@@ -852,7 +852,7 @@
 if (!r->is_stack()) {
   stringStream st;
   st.print("bad oop %s at %d", r->as_Register()->name(), _masm->offset());
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
   _masm->_verify_oop(r->as_Register(), strdup(st.as_string()), __FILE__, __LINE__);
 #else
   _masm->verify_oop(r->as_Register());
--- openjdk/hotspot/src/share/vm/c1/c1_LinearScan.cpp.old	2014-01-14 21:26:34.0 +
+++ openjdk/hotspot/src/share/vm/c1/c1_LinearScan.cpp	2014-01-15 10:55:37.079084322 +
@@ -2128,7 +2128,7 @@
 }
 #endif
 
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
 assert(assigned_reg >= pd_first_fpu_reg && assigned_reg <= pd_last_fpu_reg, "no fpu register");
 assert(interval->assigned_regHi() >= pd_first_fpu_reg && interval->assigned_regHi() <= pd_last_fpu_reg, "no fpu register");
 assert(assigned_reg % 2 == 0 && assigned_reg + 1 == interval->assigned_regHi(), "must be sequential and even");
@@ -2726,7 +2726,7 @@
 
   assert(opr->fpu_regnrLo() == opr->fpu_regnrHi(), "assumed in calculation (only fpu_regnrLo is used)");
 #endif
-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)
   assert(opr->fpu_regnrLo() == opr->fpu_regnrHi() + 1, "assumed in calculation (only fpu_regnrHi is used)");
 #endif
 #ifdef ARM
--- openjdk/hotspot/src/share/vm/c1/c1_LIR.hpp.old	2014-01-14 21:26:34.0 +
+++ openjd

Current status of OpenJDK-9 on sparc64

[John Paul Adrian Glaubitz]

Hi!

I have been working on OpenJDK-9 on sparc64 the past days and managed
to fix some bugs. While the build gets quite far, it's still currently
failing with a linker error:

=== Output from failing command(s) repeated here ===
/usr/bin/printf "* For target
hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n" 
* For target
hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" <
/<>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log
|| true) | /usr/bin/head -n 12 
/<>/build-zero/hotspot/variant-zero/libjvm/gtest/objs/test_memset_with_concurrent_readers.o:
In function `gc_memset_with_concurrent_readers_test_Test::TestBody()':
./src/hotspot/make/./src/hotspot/test/native/gc/shared/test_memset_with_concurrent_readers.cpp:66:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
/<>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:
In function `BlockOffsetSharedArray::fill_range(unsigned long,
unsigned long, unsigned char)':
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
/<>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
more undefined references to `memset_with_concurrent_readers(void*,
int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l <
/<>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log`
-gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi 
/usr/bin/printf "* For target
hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n" 
* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" <
/<>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log
|| true) | /usr/bin/head -n 12 
/<>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:
In function `BlockOffsetSharedArray::fill_range(unsigned long,
unsigned long, unsigned char)':
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
undefined reference to `memset_with_concurrent_readers(void*, int,
unsigned long)'
/<>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
more undefined references to `memset_with_concurrent_readers(void*,
int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l <
/<>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log`
-gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi 
/usr/bin/printf "\n* All command lines available in
/<>/build-zero/make-support/failure-logs.\n" 

* All command lines available in
/<>/build-zero/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n" 
=== End of repeated output ===

To get there, I needed to fix the sparc-linux code in several places,
I'm attaching all my current patches to this bug report.

The above linker error comes from the fact that on SPARC, OpenJDK-9
uses its own implementation of "memset_with_concurrent_readers()"
which resides in memset_with_concurrent_readers_sparc.cpp. Although
the latter source file gets compiled, the linker cannot find it in the
later steps. I tried patching the makefiles myself, but the whole
hand-written set of makefiles is rather obscure and I can't seem to
find the 

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 16/06/16 02:12, Hector Oron wrote:
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
> 
> Please review and comment if required.

That page is now outdated wrt mips concerns (see below). Do we need to duplicate
the information that we already have on r.d.o/stretch/arch_qualify.html ?

>>- s390, ppc64el and all arm ports have DSA concerns.
> 
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.

Sure, that's fine.

> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.

OK. I have removed the DSA concerns for arm64 from arch_qualify due to this.

>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
> 
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]

AIUI armhf/armel needing local admins should still be a concern, even if mild.
Ideally that wouldn't be necessary. I have updated arch_qualify to reflect that.

> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.

I have added you two as armel porters.

>>  * mips64el (NEW)
>>- No DSA buildd (RT blocker)
> 
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.

We now got more hardware. This is no longer a concern.

>>- Rebuild after import not complete (RT Blocker)
> 
> Is there a list of packages that should be rebuilt?

There's just one package missing, which is being worked on. See Aurelien's mail.

>>- Not yet in testing (due to the above).
> 
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.

Once db5.3 is rebuilt, we can enable mips64el in testing.

> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?

Not sure about this one... I don't think anybody has stepped up as a porter.

> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
> 
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.

That's sorted out now.

Cheers,
Emilio

Re: [Stretch] Status for architecture qualification

[Luca Filipozzi]

On Mon, Jun 27, 2016 at 04:35:03PM +0200, Wouter Verhelst wrote:
> (sorry for jumping in late here)
> 
> On Wed, Jun 15, 2016 at 07:51:55AM +0800, Paul Wise wrote:
> > On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:
> > 
> > > At the openmainframeproject EU meetup, it was indicated that SUSE
> > > joined with indication that Open Build Service might be able to use
> > > resources hosted by Marist.
> > > 
> > > I wonder if it makes sense to reach out, and see if there are
> > > resources available to use as porter boxes & build boxes. That way
> > > Debian might be able to get such donated resource available on ongoing
> > > basis and hopefully with some hw support.
> > 
> > Marist already support Debian with an s390x buildd:
> > 
> > ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> > "(sponsor=*marist*)"
> > https://db.debian.org/machines.cgi?host=zani
> > 
> > Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:
> > 
> > ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> > "(architecture=s390*)" sponsor
> 
> Given that we already seem to have three hardware sponsors for the s390x
> port, is this really a concern?

Our standard for buildd / porterboxen of a released architecture is:
- multiple machines (N + 1, N sufficient to handle the buildd / porter load)
- under warranty or post-warranty hardware support for the duration of their
  use as buildds / porterboxen including through the LTS timeframe
- located in multiple geographic locations (EU and NA, ideally)
- hosted by different hosting partners, each providing high availability
  (power, cooling, networking) and intelligent remote hands
- under Debian control and/or ownership; available & affordable 
- redundant disks and power supplies
- out-of-band service processor with power management or equivalent

Not satisfying the fifth bullet is a minor concern in the case of s390x.

> If we were to lose one sponsor, we'd still have two (and it would be
> reasonable to try to ensure that we get a new sponsor to replace the one
> lost).

Indeed.  The more redundnant sponsors, the less worrying is the concern.

> How about making it a requirement that there is some level of redundancy
> in sponsors for ports where hardware cannot be easily bought with Debian
> money? That would cover the s390x port as well as any potential other
> insanely-expensive-hardware port[1] that we might support now or in the
> future.

That is our requirement, effectively.  The mild concern has not blocked the
port from releasing.  That said, the concern should be documented.

> If push comes to shove, we could also talk to IBM. Pretty much all POWER
> hardware we have was sponsored by IBM; it's not unreasonable to assume they
> might be willing to also sponsor s390x time or hardware.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian

Re: [Stretch] Status for architecture qualification

[Geert Uytterhoeven]

On Mon, Jun 20, 2016 at 8:32 PM, Nelson H. F. Beebe  wrote:
> Recent traffic on this list has discussed Debian on PowerPC and
> big-endian vs little-endian.
>
> The next-generation US national laboratory facilities are to be based
> on PowerPC, and one source that I read mentioned little-endian, likely
> for binary file compatibility with files produced on Intel x86 and
> x86-64 CPUs: see

Yeah, apparently it's cheaper to bootstrap a complete new little endian
platform than to fix portability issues in existing software...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Stretch] Status for architecture qualification

[Nelson H. F. Beebe]

Recent traffic on this list has discussed Debian on PowerPC and
big-endian vs little-endian.

The next-generation US national laboratory facilities are to be based
on PowerPC, and one source that I read mentioned little-endian, likely
for binary file compatibility with files produced on Intel x86 and
x86-64 CPUs: see

CORAL/Sierra
https://asc.llnl.gov/coral-info

The size, and budget, for such facilities suggests that there may be
financial support for Linux operating-system work on them.


---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-20 10:29, John Paul Adrian Glaubitz wrote:

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz 
wrote:

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?


Well it is getting there.


The archive rebuild is done and around 11200 packages are up-to-date. 
It's
just the installer that needs work and someone needs to convince the 
release

team that ppc64 is something we want as a release architecture.

Adrian


Just out of curiosity, what's the stipulation with ppc64? Access to 
hardware shouldn't be a problem if ppc64el is a release arch. Maybe i'm 
just weird, but i would pick ppc64 over ppc64el any day. Other than my 
personal affinity for big endian cpu's, ppc64el only has support for one 
generation of cpu's whereas ppc64 should be able to run on everything 
from power4 / ppc970 and up without too much trouble.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
> On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
>> Well, we just did a full archive rebuild of "ppc64" to be able to
>> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?
> 
> Well it is getting there.

The archive rebuild is done and around 11200 packages are up-to-date. It's
just the installer that needs work and someone needs to convince the release
team that ppc64 is something we want as a release architecture.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
> Well, we just did a full archive rebuild of "ppc64" to be able to
> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Well it is getting there.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:05 PM, Lennart Sorensen wrote:
> Also I suspect many users of 64 bit capable freescale chips
> (e5500 and e6500 cores) are running 32 bit powerpc since they
> don't have enough ram to actually really gain anything
> from going to 64 bit, and the ppc64 port isn't done yet.

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Sun, Jun 19, 2016 at 08:35:02PM +0200, Florian Weimer wrote:
> Do they implement the ISA required by the existing Debian port?

Yes.

The only ones that don't are the Freescale 85xx and P10[12]x chips,
which are powerpcspe due to using the e500 core.

All the 83xx and 82xx chips which are still shipping in many current
products are plain old 32bit powerpc.  Also I suspect many users of 64
bit capable freescale chips (e5500 and e6500 cores) are running 32 bit
powerpc since they don't have enough ram to actually really gain anything
from going to 64 bit, and the ppc64 port isn't done yet.  But those
would be a case of running 32 bit on 64 bit.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

> In other words, i don't think a s390x box will ever just die.

I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware.  It's not just about faults with a
piece of equipment.

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

* Lennart Sorensen:

> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today.  They are not going away anytime soon.

Do they implement the ISA required by the existing Debian port?

Re: [Stretch] Status for architecture qualification

[William ML Leslie]

On 19 June 2016 at 02:25, William ML Leslie
 wrote:
>
> In case it isn't clear, the number of users of the architecture is not part 
> of the qualification, it is the amount of maintenance pressure involved. 
> Package maintainers have to put more effort into ensuring builds succeed for 
> release architectures, which detracts from other work that needs to be done. 
> Not being a release architecture is perfectly fine.
>
> And just to bring the topic full circle now, ppc is a release architecture, 
> nobody is suggesting its removal afaict.


Whoops, I just realised that Hector *did* ask if powerpc had active
users.  Sorry for the misguided response to what seemed like off-topic
chatter.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/18/2016 06:25 PM, William ML Leslie wrote:
> In case it isn't clear, the number of users of the architecture is not part 
> of the qualification, it is the amount of maintenance pressure involved. 
> Package
> maintainers have to put more effort into ensuring builds succeed for release 
> architectures, which detracts from other work that needs to be done. Not 
> being a
> release architecture is perfectly fine.

I maintain multiple architectures in Debian Ports, including m68k, powerpcspe, 
sh4, sparc64 and x32 and actually, it's not so much of a burden to maintain an
architecture in Debian. Most of the packages don't need special attention and 
if they do, it's usually just poorly written code like people doing weird 
pointer
arithmetics which provoke unaligned access or abuse C/C++ in other ways.

If upstream developers in these cases cared more about code quality and 
adhering to the C/C++ standards, we would hardly ever have issues with any 
ports. Heck,
even on m68k, most packages still build fine and they actually work. As long as 
an architecture is maintained upstream both in the kernel and the toolchain,
there is absolutely no reason to not keep it in Debian unless there is no 
hardware available that can be used for buildds and porterboxes. Ports like
Debian/GNU Hurd or Debian/kFreeBSD are a different story though as they need 
way more work to be able to make all sorts of packages work there.

In the case of PowerPC, both the kernel and the toolchain are very well 
maintained, many packages like GHC have native support for the architecture and 
even
rather problematic packages like Firefox/Thunderbird are supported. Plus, 
PowerPC packages can be built on the POWER8 virtual machines that IBM provides
for Debian Developers in the cloud for free. We have one such machine set up 
for ppc64, for example.

In any case, if PowerPC should ever be dropped as a release architecture, I 
will be more than happy to adopt it in Debian Ports.

PS: If you see your package failing to build on any of the ports architectures 
and you want to fix it and need help, just let me know :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[William ML Leslie]

In case it isn't clear, the number of users of the architecture is not part
of the qualification, it is the amount of maintenance pressure involved.
Package maintainers have to put more effort into ensuring builds succeed
for release architectures, which detracts from other work that needs to be
done. Not being a release architecture is perfectly fine.

And just to bring the topic full circle now, ppc is a release architecture,
nobody is suggesting its removal afaict.
On 18/06/2016 2:54 am, "Brock Wittrock"  wrote:

I run all sorts of PowerPC machines with various versions of Debian and I
don't see that coming to end anytime soon.  These are excellent and
reliable machines.  Biggest issues/hurdles are just graphics at the moment
for both ATI/AMD and Nvidia cards, but even if that is never resolved/fixed
or performance dwindles to nothing, I will continue to use these machines
in text/console only mode if I have to.  Please do not drop this
architecture!


Brock

On Fri, Jun 17, 2016 at 3:24 AM, Riccardo Mottola <
riccardo.mott...@libero.it> wrote:

> Hi,
>
> Dan DeVoto wrote:
>
>> In addition to the debian powerpc mailing list, powerpc users are active
>> on the Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything
>> works except 3D acceleration.  I don't see a need to drop it.
>>
>
> I hope that my iBook G3 will serve me for years to come! Low power
> consumption fanless with a SSD disk make superquiet and quite nice!
>
> Riccardo
>
>

Re: [Stretch] Status for architecture qualification

[Brock Wittrock]

I run all sorts of PowerPC machines with various versions of Debian and I
don't see that coming to end anytime soon.  These are excellent and
reliable machines.  Biggest issues/hurdles are just graphics at the moment
for both ATI/AMD and Nvidia cards, but even if that is never resolved/fixed
or performance dwindles to nothing, I will continue to use these machines
in text/console only mode if I have to.  Please do not drop this
architecture!


Brock

On Fri, Jun 17, 2016 at 3:24 AM, Riccardo Mottola <
riccardo.mott...@libero.it> wrote:

> Hi,
>
> Dan DeVoto wrote:
>
>> In addition to the debian powerpc mailing list, powerpc users are active
>> on the Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything
>> works except 3D acceleration.  I don't see a need to drop it.
>>
>
> I hope that my iBook G3 will serve me for years to come! Low power
> consumption fanless with a SSD disk make superquiet and quite nice!
>
> Riccardo
>
>

Re: [Stretch] Status for architecture qualification

[Riccardo Mottola]

Hi,

Dan DeVoto wrote:

In addition to the debian powerpc mailing list, powerpc users are active on the 
Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything works 
except 3D acceleration.  I don't see a need to drop it.


I hope that my iBook G3 will serve me for years to come! Low power 
consumption fanless with a SSD disk make superquiet and quite nice!


Riccardo

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Thu, Jun 16, 2016 at 09:04:12AM +0200, Mathieu Malaterre wrote:
> The debian-powerpc@l.d.o mailing list is active so I would say it
> still has some users. I have been using partch.d.o for doing some work
> on PowerPC. I posted a summary of work people have been doing on this
> port lately:
> 
> https://lists.debian.org/debian-powerpc/2016/06/msg00046.html
> 
> However I do agree that true PowerPC hardware is actually
> disappearing, and it is alive mostly thanks to being an ABI using
> 32bits integer for PPC64 CPU(s).

There are a lot of 32bit powerpc chips still going into embedded systems
being built today.  They are not going away anytime soon.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On 2016-06-15 00:37, Dimitri John Ledkov wrote:

There is openmainframe project https://www.openmainframeproject.org/ ,
which I believe offers access to z/VM instances hosted by Marist
colledge.

At the openmainframeproject EU meetup, it was indicated that SUSE
joined with indication that Open Build Service might be able to use
resources hosted by Marist.

I wonder if it makes sense to reach out, and see if there are
resources available to use as porter boxes & build boxes. That way
Debian might be able to get such donated resource available on ongoing
basis and hopefully with some hw support.


Debian already makes use of Marist's resources. The challenge was/is to 
get redundancy as DSA very sensibly insists on.


Kind regards
Philipp Kern

RE: [Stretch] Status for architecture qualification

[luigi burdo]

Here too all new amiga Ng are PPC  with last generations of gpu pcie Amd boards 
and we are using linux  expecially Debian.
Luigi

From: herminio.hernande...@gmail.com
Date: Wed, 15 Jun 2016 22:02:29 -0700
Subject: Re: [Stretch] Status for architecture qualification
To: hector.o...@gmail.com
CC: ni...@thykier.net; debian-ad...@lists.debian.org; t...@security.debian.org; 
debian-rele...@lists.debian.org; debian-po...@lists.debian.org; 
debian-wb-t...@lists.debian.org; r...@debian.org

I know there are still powerpc users who run Debian. I am one of them and love 
to see it continue. How can I help?
Thanks!
On Wed, Jun 15, 2016 at 5:12 PM, Hector Oron <hector.o...@gmail.com> wrote:
[Add to CC debian-wb-team@ and r...@debian.org]



Hello,



2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:

> Hi members of DSA, Security, RT and all porters.

>

> While the freeze still seem far away, I think it is time to start with

> the architecture qualifications.



Excellent! Thanks



I tried to follow the follow-up thread, ended up watching an hour

video which was quite fun and forgot all details. :-)



I have put up the classical wiki page for Stretch at:

  https://wiki.debian.org/ArchiveQualification/Stretch



Please review and comment if required.



> For starters, here are the architectures we are aware of:

>

>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,

>s390x

>- *No* blockers at this time from RT, DSA nor security.

>- s390, ppc64el and all arm ports have DSA concerns.



I understand s390x and ppc64el DSA concerns have been clarified

in-list and those concerns are due to nature of the architecture.



For the ARM ports, which have also been clarified, let me re-confirm:

 * arm64 port has remote power and remote console available, plus

geo-redundancy, hardware is available and there is more hardware

coming in the pipeline. I am unsure why it is listed with multiple DSA

concerns, that surprises me (with DSA and ARM porter hats). The port

currently has 4 machines up, one down waiting to be replaced, in total

5 and more coming.

 * armhf/armel ports share hardware, we currently have 6 machines up

with remote power and remote console (of course that being development

boards is not so nice as server remote management goodies). Some

machines require a button press but local admins are great and always

happy to help.



If none steps up explaining what are DSA concerns on the ARM

architectures, please update status requalification page dropping

those concerns. [DSA hat on]



I see armel has one porter listed, if more are needed, please add

myself and Riku Voipio (armel buildd maints). [ARM hat on]

I see arm64/armhf are covered porterwise however there should be more

porters available if needed.



>- armel has a RT concern about lack of buildds (only 2)



>From the above comment: "armhf/armel ports share hardware, we

currently have 6 machines up"



>  * mips64el (NEW)

>- No DSA buildd (RT blocker)



As far as I can see mips64el is using shared builds with mipsel port

hardware, those machines are DSA.



>- Rebuild after import not complete (RT Blocker)



Is there a list of packages that should be rebuilt?



>- Not yet in testing (due to the above).



Please let's work on getting it in testing ASAP I think the above

blockers can be worked out quite reasonably.



>  * kfreebsd-i386, kfreebsd-amd64

>- Not included in Jessie due to lack of sustainable man-power (RT

>  blocker)

>- No news of the situation having changed

>- If there is no news on the situation after DebConf16, I will

>  assume kfreebsd-* will not target Stretch.



Who has been keeping it up for stretch? (As a side note Stephen

Chamberlain, Christoph Egger and many other people keep working on it)

Not sure if those arches have more or less manpower than powerpc (in

example). I think it would be great to make a call here, we either

move kfreebsd ports to debian-ports infrastructure or go for the

release with it.



While working out ArchitectureQualification/Stretch wiki page I

believe everything is mostly fine for release, however I got a

personal concern on powerpc architecture. Is it well maintained? Does

it have porters? Does it have users? Does it still make sense to carry

along?



Another concern (DSA) which I have added and explained in the wiki

page is the lack of georedundancy for the 'mips' port. Verbatim copy

from wiki follows:

"mips: It has 5 buildds in the same datacenter, current hardware are

routers or development boards which makes it very difficult to ship to

other places. The host providing redundancy (lucatelli) at UBC-ECE

must be decomissioned ASAP, leaving the port in a situation of not

geographic redundancy. However advanced plans exists to deploy mips

hardware in other data centers RSN."



I'll

Re: [Stretch] Status for architecture qualification

[Mathieu Malaterre]

Hi Hector,

On Thu, Jun 16, 2016 at 2:12 AM, Hector Oron  wrote:
[...]
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
[...]

The debian-powerpc@l.d.o mailing list is active so I would say it
still has some users. I have been using partch.d.o for doing some work
on PowerPC. I posted a summary of work people have been doing on this
port lately:

https://lists.debian.org/debian-powerpc/2016/06/msg00046.html

However I do agree that true PowerPC hardware is actually
disappearing, and it is alive mostly thanks to being an ABI using
32bits integer for PPC64 CPU(s).

-M

Re: [Stretch] Status for architecture qualification

[Herminio Hernandez, Jr.]

I know there are still powerpc users who run Debian. I am one of them and
love to see it continue. How can I help?

Thanks!

On Wed, Jun 15, 2016 at 5:12 PM, Hector Oron <hector.o...@gmail.com> wrote:

> [Add to CC debian-wb-team@ and r...@debian.org]
>
> Hello,
>
> 2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> > Hi members of DSA, Security, RT and all porters.
> >
> > While the freeze still seem far away, I think it is time to start with
> > the architecture qualifications.
>
> Excellent! Thanks
>
> I tried to follow the follow-up thread, ended up watching an hour
> video which was quite fun and forgot all details. :-)
>
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
>
> Please review and comment if required.
>
> > For starters, here are the architectures we are aware of:
> >
> >  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
> >s390x
> >- *No* blockers at this time from RT, DSA nor security.
> >- s390, ppc64el and all arm ports have DSA concerns.
>
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.
>
> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.
>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
>
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]
>
> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.
>
> >- armel has a RT concern about lack of buildds (only 2)
>
> >From the above comment: "armhf/armel ports share hardware, we
> currently have 6 machines up"
>
> >  * mips64el (NEW)
> >- No DSA buildd (RT blocker)
>
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.
>
> >- Rebuild after import not complete (RT Blocker)
>
> Is there a list of packages that should be rebuilt?
>
> >- Not yet in testing (due to the above).
>
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.
>
> >  * kfreebsd-i386, kfreebsd-amd64
> >- Not included in Jessie due to lack of sustainable man-power (RT
> >  blocker)
> >- No news of the situation having changed
> >- If there is no news on the situation after DebConf16, I will
> >  assume kfreebsd-* will not target Stretch.
>
> Who has been keeping it up for stretch? (As a side note Stephen
> Chamberlain, Christoph Egger and many other people keep working on it)
> Not sure if those arches have more or less manpower than powerpc (in
> example). I think it would be great to make a call here, we either
> move kfreebsd ports to debian-ports infrastructure or go for the
> release with it.
>
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
>
> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
>
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.
>
> > Beyond mips64el, we are not aware of any new architectures for Stretch.
>
> Could you please check with sparc64 porters? I think some of them
> commented on the follow ups.
>
> Regards,
> --
>  Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
>
>

Re: [Stretch] Status for architecture qualification

[Hector Oron]

[Add to CC debian-wb-team@ and r...@debian.org]

Hello,

2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> Hi members of DSA, Security, RT and all porters.
>
> While the freeze still seem far away, I think it is time to start with
> the architecture qualifications.

Excellent! Thanks

I tried to follow the follow-up thread, ended up watching an hour
video which was quite fun and forgot all details. :-)

I have put up the classical wiki page for Stretch at:
  https://wiki.debian.org/ArchiveQualification/Stretch

Please review and comment if required.

> For starters, here are the architectures we are aware of:
>
>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>s390x
>- *No* blockers at this time from RT, DSA nor security.
>- s390, ppc64el and all arm ports have DSA concerns.

I understand s390x and ppc64el DSA concerns have been clarified
in-list and those concerns are due to nature of the architecture.

For the ARM ports, which have also been clarified, let me re-confirm:
 * arm64 port has remote power and remote console available, plus
geo-redundancy, hardware is available and there is more hardware
coming in the pipeline. I am unsure why it is listed with multiple DSA
concerns, that surprises me (with DSA and ARM porter hats). The port
currently has 4 machines up, one down waiting to be replaced, in total
5 and more coming.
 * armhf/armel ports share hardware, we currently have 6 machines up
with remote power and remote console (of course that being development
boards is not so nice as server remote management goodies). Some
machines require a button press but local admins are great and always
happy to help.

If none steps up explaining what are DSA concerns on the ARM
architectures, please update status requalification page dropping
those concerns. [DSA hat on]

I see armel has one porter listed, if more are needed, please add
myself and Riku Voipio (armel buildd maints). [ARM hat on]
I see arm64/armhf are covered porterwise however there should be more
porters available if needed.

>- armel has a RT concern about lack of buildds (only 2)

>From the above comment: "armhf/armel ports share hardware, we
currently have 6 machines up"

>  * mips64el (NEW)
>- No DSA buildd (RT blocker)

As far as I can see mips64el is using shared builds with mipsel port
hardware, those machines are DSA.

>- Rebuild after import not complete (RT Blocker)

Is there a list of packages that should be rebuilt?

>- Not yet in testing (due to the above).

Please let's work on getting it in testing ASAP I think the above
blockers can be worked out quite reasonably.

>  * kfreebsd-i386, kfreebsd-amd64
>- Not included in Jessie due to lack of sustainable man-power (RT
>  blocker)
>- No news of the situation having changed
>- If there is no news on the situation after DebConf16, I will
>  assume kfreebsd-* will not target Stretch.

Who has been keeping it up for stretch? (As a side note Stephen
Chamberlain, Christoph Egger and many other people keep working on it)
Not sure if those arches have more or less manpower than powerpc (in
example). I think it would be great to make a call here, we either
move kfreebsd ports to debian-ports infrastructure or go for the
release with it.

While working out ArchitectureQualification/Stretch wiki page I
believe everything is mostly fine for release, however I got a
personal concern on powerpc architecture. Is it well maintained? Does
it have porters? Does it have users? Does it still make sense to carry
along?

Another concern (DSA) which I have added and explained in the wiki
page is the lack of georedundancy for the 'mips' port. Verbatim copy
from wiki follows:
"mips: It has 5 buildds in the same datacenter, current hardware are
routers or development boards which makes it very difficult to ship to
other places. The host providing redundancy (lucatelli) at UBC-ECE
must be decomissioned ASAP, leaving the port in a situation of not
geographic redundancy. However advanced plans exists to deploy mips
hardware in other data centers RSN."

I'll keep you posted whenever there is progress on that area. I do not
believe it should be a blocker for release, but we must ensure geo
redundancy first.

> Beyond mips64el, we are not aware of any new architectures for Stretch.

Could you please check with sparc64 porters? I think some of them
commented on the follow ups.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: [Stretch] Status for architecture qualification

[Stephen Powell]

On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote:
> 
> There is openmainframe project https://www.openmainframeproject.org/ ,
> which I believe offers access to z/VM instances hosted by Marist
> colledge.
> 
> At the openmainframeproject EU meetup, it was indicated that SUSE
> joined with indication that Open Build Service might be able to use
> resources hosted by Marist.
> 
> I wonder if it makes sense to reach out, and see if there are
> resources available to use as porter boxes & build boxes. That way
> Debian might be able to get such donated resource available on ongoing
> basis and hopefully with some hw support.
> 

Of course, there's always Hercules.  Real hardware is always better of course.
But then again, strictly speaking, A z/VM instance is a virtual machine,
running under z/VM.  And z/VM is running in an LPAR, which is essentially
a virtual machine running under PR/SM.  And the physical machine behind
those (at least) two levels of virtualization doesn't really have the
same hardware architecture as a virtual machine, such as physical chpids
vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM
or IOCP.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: [Stretch] Status for architecture qualification

[Paul Wise]

On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:

> At the openmainframeproject EU meetup, it was indicated that SUSE
> joined with indication that Open Build Service might be able to use
> resources hosted by Marist.
> 
> I wonder if it makes sense to reach out, and see if there are
> resources available to use as porter boxes & build boxes. That way
> Debian might be able to get such donated resource available on ongoing
> basis and hopefully with some hw support.

Marist already support Debian with an s390x buildd:

ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
"(sponsor=*marist*)"
https://db.debian.org/machines.cgi?host=zani

Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:

ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
"(architecture=s390*)" sponsor

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [Stretch] Status for architecture qualification

[Dimitri John Ledkov]

On 14 June 2016 at 20:22,   wrote:
> On 2016-06-14 03:06, Philipp Kern wrote:
>>
>> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
>>>
>>> Philipp Kern:
>>> > On 2016-06-05 12:01, Niels Thykier wrote:
>>> >>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>> >>s390x
>>> >>- *No* blockers at this time from RT, DSA nor security.
>>> >>- s390, ppc64el and all arm ports have DSA concerns.
>>> > What is the current DSA concern about s390x?
>>> The concern listed as: "rely on sponsors for hardware (mild concern)"
>>>
>>> As I recall the argument went something along the lines of:
>>>
>>> "Debian cannot replace the hardware; if any of the machines dies, we
>>> need a sponsor to replace it.  If all of them dies and we cannot get
>>> sponsored replacements, we cannot support the architecture any longer"
>>>
>>> (My wording)
>>
>>
>> Yeah, but that's unfortunately one of the universal truths of this port.
>> I mean in theory sometimes they turn up on eBay and people try to make
>> them work[1].
>>
>> It also seems true for other ports where we commonly relied on sponsors
>> to hand us replacements. But maybe it's only ppc64el these days, maybe
>> there are useful builds available for the others (including arm64 and
>> mips) on the market now.
>>
>> Kind regards and thanks
>> Philipp Kern
>>
>> [1] https://www.youtube.com/watch?v=45X4VP8CGtk
>> (Here's What Happens When an 18 Year Old Buys a Mainframe)
>
>
> Fun story, i had a client who was considering getting their hands on a Z9,
> they asked me a few others to go with them to see IBM present a demo of it.
> Long story short the IBM guys started a job and literally started pulling
> CPU and Mem boards out of the machine mid job. The error log on the OS/2
> maintenance laptop was going crazy, but the OS kept running the job.
>
> In other words, i don't think a s390x box will ever just die. Really
> interesting machines to say the least, hopefully one day i will get to play
> with one. The other issues with s390x is that  in most cases you don't buy
> them. You essentially lease the CPU usage and IBM charges you based on how
> much CPU usage you've consumed over a given time. It makes me wonder how
> they ever get on eBay. IBM typically takes them back after you stop paying
> for it.
>

In the talk he did say that for that acient machine he was offered
subscription to the upgraded z/OS for some small amount of dollars a
quarter.

There is openmainframe project https://www.openmainframeproject.org/ ,
which I believe offers access to z/VM instances hosted by Marist
colledge.

At the openmainframeproject EU meetup, it was indicated that SUSE
joined with indication that Open Build Service might be able to use
resources hosted by Marist.

I wonder if it makes sense to reach out, and see if there are
resources available to use as porter boxes & build boxes. That way
Debian might be able to get such donated resource available on ongoing
basis and hopefully with some hw support.

-- 
Regards,

Dimitri.

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-14 03:06, Philipp Kern wrote:

On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:

Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
> What is the current DSA concern about s390x?
The concern listed as: "rely on sponsors for hardware (mild concern)"

As I recall the argument went something along the lines of:

"Debian cannot replace the hardware; if any of the machines dies, we
need a sponsor to replace it.  If all of them dies and we cannot get
sponsored replacements, we cannot support the architecture any longer"

(My wording)


Yeah, but that's unfortunately one of the universal truths of this 
port.

I mean in theory sometimes they turn up on eBay and people try to make
them work[1].

It also seems true for other ports where we commonly relied on sponsors
to hand us replacements. But maybe it's only ppc64el these days, maybe
there are useful builds available for the others (including arm64 and
mips) on the market now.

Kind regards and thanks
Philipp Kern

[1] https://www.youtube.com/watch?v=45X4VP8CGtk
(Here's What Happens When an 18 Year Old Buys a Mainframe)


Fun story, i had a client who was considering getting their hands on a 
Z9, they asked me a few others to go with them to see IBM present a demo 
of it. Long story short the IBM guys started a job and literally started 
pulling CPU and Mem boards out of the machine mid job. The error log on 
the OS/2 maintenance laptop was going crazy, but the OS kept running the 
job.


In other words, i don't think a s390x box will ever just die. Really 
interesting machines to say the least, hopefully one day i will get to 
play with one. The other issues with s390x is that  in most cases you 
don't buy them. You essentially lease the CPU usage and IBM charges you 
based on how much CPU usage you've consumed over a given time. It makes 
me wonder how they ever get on eBay. IBM typically takes them back after 
you stop paying for it.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/14/2016 09:06 AM, Philipp Kern wrote:
> Yeah, but that's unfortunately one of the universal truths of this port.
> I mean in theory sometimes they turn up on eBay and people try to make
> them work[1].

Hilarious talk, thanks a lot for the link :).

> It also seems true for other ports where we commonly relied on sponsors
> to hand us replacements. But maybe it's only ppc64el these days, maybe
> there are useful builds available for the others (including arm64 and
> mips) on the market now.

The hardware sponsoring is the main thing that keeps us from making sparc64
an official port, I would say.

The state of the port itself is great: We recently even got LibreOffice running
on sparc64 (patches not yet merged) and the port is quite popular, according
to popcon, sparc64 has already more users than arm64 and some of the mips
ports :). If we were to add sparc64 to Debian, we could rebuild the archive
within a few weeks.

We have one user who has two Sun T2 servers which are new-in-box (NIB),
would those be ok to set up as machines for DSA?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 14/06/16 09:06, Philipp Kern wrote:
> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
>> Philipp Kern:
>>> On 2016-06-05 12:01, Niels Thykier wrote:
  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
s390x
- *No* blockers at this time from RT, DSA nor security.
- s390, ppc64el and all arm ports have DSA concerns.
>>> What is the current DSA concern about s390x?
>> The concern listed as: "rely on sponsors for hardware (mild concern)"
>>
>> As I recall the argument went something along the lines of:
>>
>> "Debian cannot replace the hardware; if any of the machines dies, we
>> need a sponsor to replace it.  If all of them dies and we cannot get
>> sponsored replacements, we cannot support the architecture any longer"
>>
>> (My wording)
> 
> Yeah, but that's unfortunately one of the universal truths of this port.
> I mean in theory sometimes they turn up on eBay and people try to make
> them work[1].
> 
> It also seems true for other ports where we commonly relied on sponsors
> to hand us replacements. But maybe it's only ppc64el these days, maybe
> there are useful builds available for the others (including arm64 and
> mips) on the market now.

AFAIK we rely on sponsors for all ports. The difference is that if we eventually
have to buy things ourselves, we can get mips*, arm* or x86 buildds (for
example), but we can't reasonably get a s390x one.

But that's not something we can change, so as long as there no other concerns,
this shouldn't be a blocker.

Emilio

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
> Philipp Kern:
> > On 2016-06-05 12:01, Niels Thykier wrote:
> >>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
> >>s390x
> >>- *No* blockers at this time from RT, DSA nor security.
> >>- s390, ppc64el and all arm ports have DSA concerns.
> > What is the current DSA concern about s390x?
> The concern listed as: "rely on sponsors for hardware (mild concern)"
> 
> As I recall the argument went something along the lines of:
> 
> "Debian cannot replace the hardware; if any of the machines dies, we
> need a sponsor to replace it.  If all of them dies and we cannot get
> sponsored replacements, we cannot support the architecture any longer"
> 
> (My wording)

Yeah, but that's unfortunately one of the universal truths of this port.
I mean in theory sometimes they turn up on eBay and people try to make
them work[1].

It also seems true for other ports where we commonly relied on sponsors
to hand us replacements. But maybe it's only ppc64el these days, maybe
there are useful builds available for the others (including arm64 and
mips) on the market now.

Kind regards and thanks
Philipp Kern

[1] https://www.youtube.com/watch?v=45X4VP8CGtk
(Here's What Happens When an 18 Year Old Buys a Mainframe)

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
> 
> What is the current DSA concern about s390x?
> 
> Kind regards and thanks
> Philipp Kern
> 

The concern listed as: "rely on sponsors for hardware (mild concern)"

As I recall the argument went something along the lines of:

"Debian cannot replace the hardware; if any of the machines dies, we
need a sponsor to replace it.  If all of them dies and we cannot get
sponsored replacements, we cannot support the architecture any longer"

(My wording)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/11/2016 07:33 PM, alexmcwhir...@triadic.us wrote:
> Haven't given pulseeaudio a test yet as i haven't really focused on sparc 
> desktops. I do believe i have tests passing on util-linux and glibc, i will 
> have to
> double check though. These are probably older versions than the unstable 
> debian repository though.

Unless you are using ancient versions of util-linux and glibc, I do not think 
that
the testsuites are passing on sparc64 on Gentoo. Those packages have actual bugs
which need to be addressed.

Jose Marchesi recently addressed one alignment issue in glibc as mentioned in
another mail, see:

> https://sourceware.org/ml/libc-alpha/2016-05/msg00710.html

> Im sure there's a lot of that amongst the package tree. I haven't worked much 
> on fixing unaligned access type errors, but it's on my todo list.

If you file a sparc64-specific bug in Debian. please add the following below the
keyword list at the top of the bug report mail as generated by the reportbug
utility:

X-Debbugs-CC: debian-sparc@lists.debian.org
User: debian-sparc@lists.debian.org
Usertags: sparc64

This makes sure the bugs are tagged as sparc64 bugs and the list gets informed 
automatically
about the bugs getting filed.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-09 02:58, John Paul Adrian Glaubitz wrote:

Hi Alex!



Sorry, i didn't catch this message before the others...


On 06/09/2016 06:44 AM, Alex McWhirter wrote:

If it helps i have access to a decent amount of gear. E6K, V210, V215,
M4000, T1000, T5120, Netra X1, Blade 150, and a V890.


Thanks for the offer. We don't actually lack any hardware, but what we 
need
is new off-the-shelf hardware that would be used to set up the 
infrastructure
for the sparc64 when it becomes an officially supported port in Debian, 
a

so-called release architecture.

The Debian System Adminstrators (DSA) have the requirement that the 
hardware
they set up for the official buildds and porterboxes is new and not 
used,

old hardware which might fall apart while being used for critical
infrastructure.

Debian's release architectures come with active security support and 
for
that, the buildds infrastructure needs to be there with high 
availability
to be able to build updated packages with security patches the moment 
they

become available.


I've been working on the sparc64 port of Gentoo for quite a while. If
there are issues that need addressed for Debian i'm willing to help 
out

with the effort.


Some unresolved sparc64-related bugs can be found here:


https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sparc64;users=debian-sparc@lists.debian.org


You can find more issues if you look at the list of packages with state
"Build Attempted" in the buildd database:


https://buildd.debian.org/status/architecture.php?a=sparc64=sid


Oh, and btw, please upstream any changes you have made in Gentoo to fix
bugs on sparc64. Do you have patches available for the problems with
the testsuites of pulseaudio, util-linux and glibc. Or did you skip
the testsuites for these packages?



Haven't given pulseeaudio a test yet as i haven't really focused on 
sparc desktops. I do believe i have tests passing on util-linux and 
glibc, i will have to double check though. These are probably older 
versions than the unstable debian repository though.


Seems like most of the issues are either bad coding practices or 
little

mistakes.


True. Another example for that is kdevelop-php:


https://buildd.debian.org/status/package.php?p=kdevelop-php=sid


As you can see, the build fails due to unaligned access:

[  1%] Generating phptokentype.h, phpdebugvisitor.h, phptokentext.h,
phpast.h, phpparser.h, phpparser.cpp, phpvisitor.h, phpvisitor.cpp,
phpdefaultvisitor.h,
phpdefaultvisitor.cpp
cd /<>/obj-sparc64-linux-gnu/parser &&
/usr/bin/kdev-pg-qt --output=php --namespace=Php --debug-visitor
/<>/parser/php.g
Bus error
parser/CMakeFiles/kdev4phpparser.dir/build.make:66: recipe for target
'parser/phptokentype.h' failed
make[3]: *** [parser/phptokentype.h] Error 138

which is usually easy to track down with gdb.


Im sure there's a lot of that amongst the package tree. I haven't worked 
much on fixing unaligned access type errors, but it's on my todo list.




Thanks for your help!

Adrian

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

Hi Alex!

On 06/09/2016 06:44 AM, Alex McWhirter wrote:
> If it helps i have access to a decent amount of gear. E6K, V210, V215,
> M4000, T1000, T5120, Netra X1, Blade 150, and a V890.

Thanks for the offer. We don't actually lack any hardware, but what we need
is new off-the-shelf hardware that would be used to set up the infrastructure
for the sparc64 when it becomes an officially supported port in Debian, a
so-called release architecture.

The Debian System Adminstrators (DSA) have the requirement that the hardware
they set up for the official buildds and porterboxes is new and not used,
old hardware which might fall apart while being used for critical 
infrastructure.

Debian's release architectures come with active security support and for
that, the buildds infrastructure needs to be there with high availability
to be able to build updated packages with security patches the moment they
become available.

> I've been working on the sparc64 port of Gentoo for quite a while. If
> there are issues that need addressed for Debian i'm willing to help out
> with the effort.

Some unresolved sparc64-related bugs can be found here:

> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sparc64;users=debian-sparc@lists.debian.org

You can find more issues if you look at the list of packages with state
"Build Attempted" in the buildd database:

> https://buildd.debian.org/status/architecture.php?a=sparc64=sid

Oh, and btw, please upstream any changes you have made in Gentoo to fix
bugs on sparc64. Do you have patches available for the problems with
the testsuites of pulseaudio, util-linux and glibc. Or did you skip
the testsuites for these packages?

> Seems like most of the issues are either bad coding practices or little
> mistakes.

True. Another example for that is kdevelop-php:

> https://buildd.debian.org/status/package.php?p=kdevelop-php=sid

As you can see, the build fails due to unaligned access:

[  1%] Generating phptokentype.h, phpdebugvisitor.h, phptokentext.h, phpast.h, 
phpparser.h, phpparser.cpp, phpvisitor.h, phpvisitor.cpp, phpdefaultvisitor.h,
phpdefaultvisitor.cpp
cd /<>/obj-sparc64-linux-gnu/parser && /usr/bin/kdev-pg-qt 
--output=php --namespace=Php --debug-visitor /<>/parser/php.g
Bus error
parser/CMakeFiles/kdev4phpparser.dir/build.make:66: recipe for target 
'parser/phptokentype.h' failed
make[3]: *** [parser/phptokentype.h] Error 138

which is usually easy to track down with gdb.

Thanks for your help!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Alex McWhirter]

If it helps i have access to a decent amount of gear. E6K, V210, V215,
M4000, T1000, T5120, Netra X1, Blade 150, and a V890.

I've been working on the sparc64 port of Gentoo for quite a while. If
there are issues that need addressed for Debian i'm willing to help out
with the effort.

Seems like most of the issues are either bad coding practices or little
mistakes.

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On 2016-06-05 12:01, Niels Thykier wrote:

 * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
   s390x
   - *No* blockers at this time from RT, DSA nor security.
   - s390, ppc64el and all arm ports have DSA concerns.


What is the current DSA concern about s390x?

Kind regards and thanks
Philipp Kern

Re: [Stretch] Status for architecture qualification

[John David Anglin]

On 2016-06-05 8:56 AM, Steven Chamberlain wrote:

John Paul Adrian Glaubitz wrote:

>I have invested lots of time and effort to get sparc64 into a usable state in 
Debian.
>We are close to 11.000 installed packages. Missing packages include Firefox,
>Thunderbird/Icedove, golang and LibreOffice to name the most important ones.

Is there some way to define 'core'[0] packages as blockers for testing
migration, and arch release qualification;  but other packages not?

Many of these ports would be useful if just a base system was released,
and preferably having stable/security updates for that part (otherwise
it is difficult for users to try it, developers to work on it, or DSA to
support buildds for it;  all of which are limitations on ports' further
growth).
I might mention that many kernel and tool chain bugs have been resolved 
on hppa since
we joined ports.  Total source package count  is now close to 11100, 
although this fluctuates.
Using this measure we are at the same level as alpha, ppc64 and 
sparc64.  SMP systems

are stable and run reliably as buildd machines.

Even if we increased our relative package count, we don't have the 
manpower to re-qualify
as a release architecture.  However, I like Steve's suggestion. Helge 
effectively defined a set
of core packages for hppa when he set up a new jessie-based install disk 
a few months ago.
This is currently available at .  I tend to think 
this should be done within

the context of Debian ports.

Dave

--
John David Anglin  dave.ang...@bell.net

Re: [Stretch] Status for architecture qualification

[Marc Rosen]

If it would be helpful, I have access to two Sun T2000 machines, in a 
server room, that are in good working condition (one has a bad RAM chip, 
but everything else seems to work fine). If it would be helpful for the 
project, I'd be happy to have them be used. That being said, the 
machines are currently off, and I probably won't be able to access the 
LOC until September (or very late august).


~ Marc Rosen

Sysadmin of the JHU ACM

On 6/5/16 5:48 AM, Niels Thykier wrote:

John Paul Adrian Glaubitz:

Hi Niels!

On 06/05/2016 12:01 PM, Niels Thykier wrote:

Beyond mips64el, we are not aware of any new architectures for Stretch.

I kindly ask you to:

  * Porters, please assert if your architecture is targeting Stretch.

To give some insight what's happening in Debian Ports. We have two candidates 
which
I think would qualify for inclusion in a stable release. There is also a third
potential candidate for future releases of Debian once the hardware has become
available.


Thanks. :)


ppc64:

[...]

AFAICT, it is not in unstable and I have not heard of any attempts to
bootstrap it there yet.  Who is working on it and what is the ETA?


sparc64:

[...]


Thanks for the update.  For every one working on this, please keep in
mind that it can take quite a while to be set up and included in testing
(even without missing hardware).

If you are unable to acquire (promise of) the necessary hardware within
a month or two, making it into a Stretch will probably be very hard.


sh4:

[...]

Thanks,
Adrian

[...]

While it sounds exciting, I doubt it will be ready for Stretch (I
presume this was the "potential candidate for a future release").

Thanks,
~Niels

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Steven Chamberlain:
> Hi,
> 

Hi,

> John Paul Adrian Glaubitz wrote:
>> I have invested lots of time and effort to get sparc64 into a usable state 
>> in Debian.
>> We are close to 11.000 installed packages. Missing packages include Firefox,
>> Thunderbird/Icedove, golang and LibreOffice to name the most important ones.
> 
> Is there some way to define 'core'[0] packages as blockers for testing
> migration, and arch release qualification;  but other packages not?
> 

There is no current definition and I doubt it will be trivial to agree
on a definition.  Also, the moment you want to keep the set
self-contained (by including build-depends) it very easily explodes
unless you patch packages to disable "optional" features.

> Many of these ports would be useful if just a base system was released,
> and preferably having stable/security updates for that part (otherwise
> it is difficult for users to try it, developers to work on it, or DSA to
> support buildds for it;  all of which are limitations on ports' further
> growth).
> 

Assuming we use your definition as basis, you probably also want the
packages necessary to support a DSA maintained buildd.  Otherwise it
seems it fail one of your own proposed requirements.

> Trying to have *every* package build and stay built on every port, and
> supported for the lifetime of stable, is a lot of work without much
> purpose sometimes.  And it's unreasonable for any one port to block
> testing migration of a package on all arches, unless it is something
> really essential.
> 
> This might be done either:
>   * in the official archive, with relaxed rules for testing migration
> and more frequently de-crufting of out-of-date packages;

I suspect this will be a lot of work and an uphill battle as the our
current tooling is not really written for this case.  At the very least,
I fear a lot of extra special cases in Britney that I cannot easily deal
with.

>   * creating a mini testing/stable suite based on debian-ports.org?
> where maybe only the core packages are candidates to migrate.
> 

At least short term, this probably a lot more tractable. I am happy to
provide help with setting up a Britney instance for ports.  Though we
would need some way to provide a architecture specific version of the
"core" packages.

> [0]: I'd define core packages as everything needed to install, boot, and
> then build packages on that arch.  The rebootstrap project gives us some
> idea of what those are;  but add to that the kernel and any bootloaders.
> Being able to rebootstrap, should be part of the arch release
> qualification anyway IMHO.
> 
> Regards,
> 

Hmm, the rebootstrap idea is interesting as a new requirement.  I will
look into it.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Oleg Endo]

Hi,

On Sun, 2016-06-05 at 13:26 +0200, John Paul Adrian Glaubitz wrote:

> sh4:
> 

> 
> The two biggest issues with sh4 are currently with binutils and the 
> kernel. binutils has problems when building Qt5:
> 

There is in fact another big elephant in the room, which I have
mentioned several times before...

The atomic model that is currently being used on sh4-linux works only
on SH3* and SH4* single-core systems.  Packages built for the current
sh4-linux will not work on multi-core systems like SH7786...

There should be two distinct builds .. sh4-linux with the current
atomic model (-matomic-model=soft-gusa) and sh4a-linux with the newer 
-matomic-model=hard-llcs.  I think it would be the easiest thing for
Debian to switch the whole thing to SH4A only and drop the older SH4.

I will add a GCC configure option to allow changing the default atomic
model.  Currently it's hardcoded to -matomic-model=soft-gusa for sh3
-linux or sh4*-linux.

Cheers,
Oleg

(GCC SH Maintainer)

Re: [Stretch] Status for architecture qualification

[Holger Levsen]

thanks to everyone explaining arch:any to me :)

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[Steven Chamberlain]

Hi,

John Paul Adrian Glaubitz wrote:
> I have invested lots of time and effort to get sparc64 into a usable state in 
> Debian.
> We are close to 11.000 installed packages. Missing packages include Firefox,
> Thunderbird/Icedove, golang and LibreOffice to name the most important ones.

Is there some way to define 'core'[0] packages as blockers for testing
migration, and arch release qualification;  but other packages not?

Many of these ports would be useful if just a base system was released,
and preferably having stable/security updates for that part (otherwise
it is difficult for users to try it, developers to work on it, or DSA to
support buildds for it;  all of which are limitations on ports' further
growth).

Trying to have *every* package build and stay built on every port, and
supported for the lifetime of stable, is a lot of work without much
purpose sometimes.  And it's unreasonable for any one port to block
testing migration of a package on all arches, unless it is something
really essential.

This might be done either:
  * in the official archive, with relaxed rules for testing migration
and more frequently de-crufting of out-of-date packages;
  * creating a mini testing/stable suite based on debian-ports.org?
where maybe only the core packages are candidates to migrate.

[0]: I'd define core packages as everything needed to install, boot, and
then build packages on that arch.  The rebootstrap project gives us some
idea of what those are;  but add to that the kernel and any bootloaders.
Being able to rebootstrap, should be part of the arch release
qualification anyway IMHO.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

John Paul Adrian Glaubitz:
> Hi Niels!
> 
> On 06/05/2016 12:01 PM, Niels Thykier wrote:
>> Beyond mips64el, we are not aware of any new architectures for Stretch.
>>
>> I kindly ask you to:
>>
>>  * Porters, please assert if your architecture is targeting Stretch.
> 
> To give some insight what's happening in Debian Ports. We have two candidates 
> which
> I think would qualify for inclusion in a stable release. There is also a third
> potential candidate for future releases of Debian once the hardware has become
> available.
> 

Thanks. :)

> ppc64:
> 
> [...]

AFAICT, it is not in unstable and I have not heard of any attempts to
bootstrap it there yet.  Who is working on it and what is the ETA?

> 
> sparc64:
> 
> [...]
> 

Thanks for the update.  For every one working on this, please keep in
mind that it can take quite a while to be set up and included in testing
(even without missing hardware).

If you are unable to acquire (promise of) the necessary hardware within
a month or two, making it into a Stretch will probably be very hard.

> sh4:
> 
> [...]
> 
> Thanks,
> Adrian
> 
> [...]

While it sounds exciting, I doubt it will be ready for Stretch (I
presume this was the "potential candidate for a future release").

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[peter green]

On 05/06/16 13:00, Holger Levsen wrote:

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
   

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed
 

[...]
   

sparc64:
We are close to 11.000 installed packages.
 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?

   
I presume he is talking about source packages in the "installed" state 
in wana-build. For comparison this is currently 12153 for amd64 and 
10937 for mips.


(this leads to the interesting conclusion that about half the source 
packages in sid are arch-all only)

Re: [Stretch] Status for architecture qualification

[Christian Seiler]

On 06/05/2016 02:00 PM, Holger Levsen wrote:
> On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
>> ppc64:
>>
>> This architecture is basically on par with the release architectures. We 
>> have over
>> 11.000 packages installed
> [...]
>> sparc64:
>> We are close to 11.000 installed packages. 
> 
> I'm not sure whether you are talking about source or binary packages but
> sid/amd64 has over 24000 source packages and over 5 binary packages,
> so I would call the above "on par". Or what am I missing?

But around 12000 of those source packages only build Arch: all packages.
If you look at amd64's buildd stats in sid, there are ~12000 source
packages in the Installed state:

https://buildd.debian.org/status/architecture.php?a=amd64=sid

i386 also has ~12000; arm64, armhf, armel, powerpc and ppc64 have ~11500
each; mipsel has ~11300 and mips has ~11000.

Arch: all has ~15000 source packages in the Installed state (but that
also counts packages that build both Arch: !all and Arch: all.

From these statistics, sparc64 appears to be a tiny bit behind mips in
terms of archive coverage, but not by much.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/05/2016 02:00 PM, Holger Levsen wrote:
> I'm not sure whether you are talking about source or binary packages but
> sid/amd64 has over 24000 source packages and over 5 binary packages,
> so I would call the above "on par". Or what am I missing?

There are just around 12,000 source packages with arch:amd64 in sid:

glaubitz@wuiet:~$ wanna-build -A sparc64 -d unstable --list=installed | wc -l
10828
glaubitz@wuiet:~$ wanna-build -A ppc64 -d unstable --list=installed | wc -l
10990
glaubitz@wuiet:~$ wanna-build -A amd64 -d unstable --list=installed | wc -l
12154
glaubitz@wuiet:~$

The rest is arch:all:

glaubitz@wuiet:~$ wanna-build -A all -d unstable --list=installed | wc -l
15672
glaubitz@wuiet:~$

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Holger Levsen]

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
> ppc64:
> 
> This architecture is basically on par with the release architectures. We have 
> over
> 11.000 packages installed
[...]
> sparc64:
> We are close to 11.000 installed packages. 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

Hi Niels!

On 06/05/2016 12:01 PM, Niels Thykier wrote:
> Beyond mips64el, we are not aware of any new architectures for Stretch.
> 
> I kindly ask you to:
> 
>  * Porters, please assert if your architecture is targeting Stretch.

To give some insight what's happening in Debian Ports. We have two candidates 
which
I think would qualify for inclusion in a stable release. There is also a third
potential candidate for future releases of Debian once the hardware has become
available.

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed with some fluctuation due to the frequent necessary 
binNMUs
for the Haskell packages. Moreover, yaboot, the bootloader used on many powerpc
machines is now supporting ppc64, too. So building usable debian-installer CD 
images
should be possible:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322540

Although yaboot still currently FTBFS on ppc64, so someone has to look into 
that.

Both openSUSE and Fedora provide official installation images for ppc64, 
upstream
development in the toolchain and kernel is active, too.

> http://dl.fedoraproject.org/pub/fedora-secondary/releases/23/Server/ppc64/iso/
> http://download.opensuse.org/ports/ppc/distribution/13.2/iso/

To set up buildds and porterboxes, virtual machines could be set up on the same
POWER servers that are used to provide powerpc and ppc64el machines, provided
that there are still enough resources available.

sparc64:

Since sparc (32-bit userland, 64-bit kernel) was dropped after Wheezy, 
development
focus shifted to sparc64 which is fully 64-bit. Upstream development was 
recently
picked up again and both kernel and toolchain are again in active development 
with
many developers being employed by Oracle. They have released a reference 
platform
last fall:

> https://oss.oracle.com/projects/linux-sparc/

I have invested lots of time and effort to get sparc64 into a usable state in 
Debian.
We are close to 11.000 installed packages. Missing packages include Firefox,
Thunderbird/Icedove, golang and LibreOffice to name the most important ones. I
haven't looked into golang yet, but Firefox, Thunderbird and LibreOffice have 
good
chances to be working soon. LibreOffice has just some tests failing in the 
testsuite
thanks to James Clarke who has ported the architecture-dependent code from 
sparc to
sparc64. Firefox and Thunderbird require some fixing in the JavaScript engine:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1275204

There are also some pending patches which fix binutils/gold and gcc-5/6 after 
which
even more packages should build without problems:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809509
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818934
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792921

Otherwise, many packages mostly fail to build from source because of some bad
programming practices which provokes unaligned access:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806208

To set up buildds and porterboxes, we would need new hardware. We have some 
older
SPARC Fire T2000 machines running as buildds plus one beefy SPARC-T5 (192 GiB 
RAM,
192 CPU threads), but those are not really suitable as official DSA machines. I
have reached out to Oracle and asked for hardware donations for that matter.

sh4:

This architecture is also known as SuperH and is actually no longer actively
developed and marketed by its developing company, Renesas.

However, there have been interesting developments for this architecture, it is
becoming open source and therefore potentially interesting for many Debian users
and developers who are concerned with privacy and free computing:

> https://lwn.net/Articles/647636/

This has become possible since - as explained in the article above - all patents
related to SuperH are expiring one after another meaning that the hardware can 
be
reimplemented without infringing any patents.

The current result of this effort is the J-Core project:

> http://j-core.org/

The big advantage of Super-H/J-Core over existing open source architectures like
OpenRISC is that both kernel and toolchain are already fully supported so that
Debian can be installed on these machines without any limitations.

We are currently at around 9100 installed packages, a large number of packages 
will
soon be able to build once I have finished bootstrapping GHC (the Haskell 
compiler)
which takes some time on my older SH-7785LCR hardware (still building for 14 
days).


The two biggest issues with sh4 are currently with binutils and the kernel. 
binutils
has problems when building Qt5:

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

While the kernel needs some additional syscalls to be wired up in the interface 
which
prevents gtk+3.0_3.20.x being built on sh4:

> https://bugzilla.kernel.org/show_bug.cgi?id=119121

As the SH port of the Linux kernel was recently turned into maintained state 
again
after two 

[Stretch] Status for architecture qualification

[Niels Thykier]

Hi members of DSA, Security, RT and all porters.

While the freeze still seem far away, I think it is time to start with
the architecture qualifications.

For starters, here are the architectures we are aware of:

 * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
   s390x
   - *No* blockers at this time from RT, DSA nor security.
   - s390, ppc64el and all arm ports have DSA concerns.
   - armel has a RT concern about lack of buildds (only 2)

 * mips64el (NEW)
   - No DSA buildd (RT blocker)
   - Rebuild after import not complete (RT Blocker)
   - Not yet in testing (due to the above).

 * kfreebsd-i386, kfreebsd-amd64
   - Not included in Jessie due to lack of sustainable man-power (RT
 blocker)
   - No news of the situation having changed
   - If there is no news on the situation after DebConf16, I will
 assume kfreebsd-* will not target Stretch.

Beyond mips64el, we are not aware of any new architectures for Stretch.

I kindly ask you to:

 * Porters, please assert if your architecture is targeting Stretch.
 * Review the list architectures and the reported blockers/concerns
 * Reply to this mail with updates to these blockers/concerns (if any).
   - DSA/Security/RT: Please use the word "blocker" or "RC" for issues
 that *must* be solved for you to be willing to support the
 architecture.

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Re: Status

[Artyom Tarasenko]

On Fri, Apr 15, 2016 at 1:06 PM, John Paul Adrian Glaubitz
<glaub...@physik.fu-berlin.de> wrote:
> On 04/15/2016 12:52 PM, Artyom Tarasenko wrote:
>> This misinformation made me feel obliged to fix it in the upstream.
>> So, today's QEMU git can boot FreeBSD/sparc64. Don't know though
>> whether it's really relevant for anyone at debian-sparc mailing list.
>> :-)
>
> Awesome, thanks a lot!
>
>> (15+ years ago, mentioning *BSD on a Linux mailing list or vice-versa
>> would cause a holly war, but now we are all grown up, right?)
>
> Well, for my part, I think that emacs is much better than vim! xD

Well emacs is good. Except for the missing text editor. xD

> Btw, from your above comment it sounds like you have commit
> access to qemu? Am I understanding this correctly? Because
> I have a few qemu patches for the m68k target which are still
> waiting to be merged.

I don't have commit access to qemu. I think meanwhile it's more or
less centralized and pretty much everything is committed by Peter
Maydell.

The way to get the patches  is to post them on the Mailing list CCing
the sub-system maintainer.
According to the current MAINTAINERS file (I'm not loud, the actual
file name is all caps), M68K
has "Orphan" status. Which probably mean that you gonna have to CC
Peter himself.

Perhaps you would like to be a m68k mainainer? You cope with
debian-sparc very well. :-)

Artyom

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: Status

[John Paul Adrian Glaubitz]

On 04/15/2016 12:52 PM, Artyom Tarasenko wrote:
> This misinformation made me feel obliged to fix it in the upstream.
> So, today's QEMU git can boot FreeBSD/sparc64. Don't know though
> whether it's really relevant for anyone at debian-sparc mailing list.
> :-)

Awesome, thanks a lot!

> (15+ years ago, mentioning *BSD on a Linux mailing list or vice-versa
> would cause a holly war, but now we are all grown up, right?)

Well, for my part, I think that emacs is much better than vim! xD

Btw, from your above comment it sounds like you have commit
access to qemu? Am I understanding this correctly? Because
I have a few qemu patches for the m68k target which are still
waiting to be merged.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Status

[Artyom Tarasenko]

On Thu, Apr 7, 2016 at 1:38 PM, Artyom Tarasenko  wrote:
> On Thu, Apr 7, 2016 at 11:29 AM, Michael-John Turner  
> wrote:
>> On Thu, Apr 07, 2016 at 11:12:50AM +0200, John Paul Adrian Glaubitz wrote:
>>> The document you linked is over 6 years old! sparc64 emulation is pretty
>>> usable already, I have installed the sparc64 netinst images that I built
>>> without any problems.
>>
>> Ah, I missed the date at the bottom of the page and didn't realise that!
>> I'm not sure that installing newer version of Solaris works yet though (at
>> least according to this[1] 2015 thread from Stack Exchange). Still,
>> possibly worth a try though.
>
> Not yet. There is some  progress, for instance, qemu-system-sparc64
> can boot Linux since March 2013 [1], and NetBSD since 2014 [2].
> One of the problems is that qemu-system-sparc64 emulates a workstation
> which has been never existed as a bare metal. Therefore it's not
> possible to use an existing firmware to boot Solaris and Solaris for
> 64 bit SPARC machines is very picky about the firmware.
> But Mark Cave-Ayland is working on OpenBIOS (in the mean time it can
> already boot FreeBSD)

Ops. Have just seen the mail from Mark, that not yet. Sorry for the
mis-information.
The rest is still valid. :-)

> and I work on sun4v emulation which could re-use
> Firmware from the OpenSPARC project (its Firmware is indeed
> Solaris-compatible).
> So, stay tuned.
>
>
> 1. http://tyom.blogspot.de/2013/03/debiansparc64-wheezy-under-qemu-how-to.html
> 2. http://tyom.blogspot.de/2014/08/upstream-qemu-can-run-netbsdsparc64.html
> --
> Regards,
> Artyom Tarasenko
>
> SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu



-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: Status

[Artyom Tarasenko]

On Thu, Apr 7, 2016 at 11:29 AM, Michael-John Turner  wrote:
> On Thu, Apr 07, 2016 at 11:12:50AM +0200, John Paul Adrian Glaubitz wrote:
>> The document you linked is over 6 years old! sparc64 emulation is pretty
>> usable already, I have installed the sparc64 netinst images that I built
>> without any problems.
>
> Ah, I missed the date at the bottom of the page and didn't realise that!
> I'm not sure that installing newer version of Solaris works yet though (at
> least according to this[1] 2015 thread from Stack Exchange). Still,
> possibly worth a try though.

Not yet. There is some  progress, for instance, qemu-system-sparc64
can boot Linux since March 2013 [1], and NetBSD since 2014 [2].
One of the problems is that qemu-system-sparc64 emulates a workstation
which has been never existed as a bare metal. Therefore it's not
possible to use an existing firmware to boot Solaris and Solaris for
64 bit SPARC machines is very picky about the firmware.
But Mark Cave-Ayland is working on OpenBIOS (in the mean time it can
already boot FreeBSD) and I work on sun4v emulation which could re-use
Firmware from the OpenSPARC project (its Firmware is indeed
Solaris-compatible).
So, stay tuned.


1. http://tyom.blogspot.de/2013/03/debiansparc64-wheezy-under-qemu-how-to.html
2. http://tyom.blogspot.de/2014/08/upstream-qemu-can-run-netbsdsparc64.html
-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: Status

[Mark Cave-Ayland]

On 07/04/16 10:29, Michael-John Turner wrote:

> On Thu, Apr 07, 2016 at 11:12:50AM +0200, John Paul Adrian Glaubitz wrote:
>> The document you linked is over 6 years old! sparc64 emulation is pretty
>> usable already, I have installed the sparc64 netinst images that I built
>> without any problems.
> 
> Ah, I missed the date at the bottom of the page and didn't realise that!
> I'm not sure that installing newer version of Solaris works yet though (at
> least according to this[1] 2015 thread from Stack Exchange). Still,
> possibly worth a try though.
> 
> [1] 
> https://unix.stackexchange.com/questions/199827/booting-solaris-10-or-11-for-sparc-in-qemu-system-sparc64

Currently FreeBSD and Solaris don't boot under qemu-system-sparc64,
although progress has been slow recently as most of my spare time went
into last year's GSoC. I'm gradually starting to find time to look at
SPARC issues again and of course more testing/bug reports are always
welcome :)


ATB,

Mark.

Re: Status

[Mark Cave-Ayland]

On 07/04/16 10:12, John Paul Adrian Glaubitz wrote:

> Hi Michael!
> 
>> On Apr 7, 2016, at 10:43 AM, Michael-John Turner  wrote:
>>
>>>
>>
>> I believe that will only work on x86 systems - KVM isn't supported on SPARC.
>> QEMU has some early emulation support for 64-bit SPARC hardware but it's
>> not really usable yet[1].
> 
> The document you linked is over 6 years old! sparc64 emulation is pretty 
> usable already, I have installed the sparc64 netinst images that I built 
> without any problems.

Wow, yes. The link you've posted below references a snapshot from the
documentation for QEMU 0.12 which is, well, old. I recently submitted an
update which can be found in the automated builds here:
http://qemu.weilnetz.de/qemu-doc.html#Sparc64-System-emulator.


ATB,

Mark.

Re: Status

[Michael-John Turner]

On Thu, Apr 07, 2016 at 11:12:50AM +0200, John Paul Adrian Glaubitz wrote:
> The document you linked is over 6 years old! sparc64 emulation is pretty
> usable already, I have installed the sparc64 netinst images that I built
> without any problems.

Ah, I missed the date at the bottom of the page and didn't realise that!
I'm not sure that installing newer version of Solaris works yet though (at
least according to this[1] 2015 thread from Stack Exchange). Still,
possibly worth a try though.

[1] 
https://unix.stackexchange.com/questions/199827/booting-solaris-10-or-11-for-sparc-in-qemu-system-sparc64

Cheers, MJ
-- 
Michael-John Turner * m...@mjturner.net * http://mjturner.net/

Re: Status

[John Paul Adrian Glaubitz]

Hi Michael!

> On Apr 7, 2016, at 10:43 AM, Michael-John Turner  wrote:
> 
>> 
> 
> I believe that will only work on x86 systems - KVM isn't supported on SPARC.
> QEMU has some early emulation support for 64-bit SPARC hardware but it's
> not really usable yet[1].

The document you linked is over 6 years old! sparc64 emulation is pretty usable 
already, I have installed the sparc64 netinst images that I built without any 
problems.

Cheers,
Adrian

> If the OP has a newer system, a possible option would be to install Solaris
> in an LDOM and use that.
> 
> [1] 
> http://wiki.qemu.org/download/qemu-doc.html#QEMU-System-emulator-for-non-PC-targets
> 
> Cheers, MJ
> -- 
> Michael-John Turner * m...@mjturner.net * http://mjturner.net/

Re: Status

[Michael-John Turner]

On Mon, Apr 04, 2016 at 10:38:25AM +0200, John Paul Adrian Glaubitz wrote:
> On 04/04/2016 05:04 AM, Jerome Ibanes wrote:
> > * Does Debian/sparc64 offer any binary compatibility layer for solaris
> > 10/sparc64 binaries?
> 
> No, unfortunately not. You would have to resort to kvm to install
> an instance of Solaris in a kernel-based virtual machine.

I believe that will only work on x86 systems - KVM isn't supported on SPARC.
QEMU has some early emulation support for 64-bit SPARC hardware but it's
not really usable yet[1].

If the OP has a newer system, a possible option would be to install Solaris
in an LDOM and use that.

[1] 
http://wiki.qemu.org/download/qemu-doc.html#QEMU-System-emulator-for-non-PC-targets

Cheers, MJ
-- 
Michael-John Turner * m...@mjturner.net * http://mjturner.net/

Re: Status

[John Paul Adrian Glaubitz]

On 04/04/2016 05:04 AM, Jerome Ibanes wrote:
> A few questions related to migrating a solaris 10/sparc64 only
> application; which isn't available for other platforms.
> 
> * Does Debian/sparc64 offer any binary compatibility layer for solaris
> 10/sparc64 binaries?

No, unfortunately not. You would have to resort to kvm to install
an instance of Solaris in a kernel-based virtual machine.

> * Does Debian/sparc64 have support for X11/Xorg, and if so, which
> video cards are supported, the application aforementioned has a
> graphical requirement (which could be remotely displayed if necessary,
> but we would prefer not to).

Yes, Debian on sparc64 has full support for Xorg. Basically all display
hardware supported by the current release of Xorg should work. There
might be some issues with Sun-specific display adapters as someone
else previously reported on this list, but in such cases, you
could just install a known-working standard PC graphics card
as a work-around (PCI, AGP or PCI Express).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Status

[Jerome Ibanes]

List,

A few questions related to migrating a solaris 10/sparc64 only
application; which isn't available for other platforms.

* Does Debian/sparc64 offer any binary compatibility layer for solaris
10/sparc64 binaries?

* Does Debian/sparc64 have support for X11/Xorg, and if so, which
video cards are supported, the application aforementioned has a
graphical requirement (which could be remotely displayed if necessary,
but we would prefer not to).

Jerome

Re: Quick status update on sparc64

[Artyom Tarasenko]

On Tue, Nov 10, 2015 at 4:10 PM, John Paul Adrian Glaubitz
 wrote:
> Over the past weeks, we have made substantial progress in catching up
> with the build queue and the number of packages which are up-to-date
> in the sparc64 port are now over 8400 which means we have built more
> than 700 packages since I started my thread with the subjet
> "Resurrecting Debian on SPARC" on September, 15 2015.
>
> One important factor is an additional buildd machine, a Sun T2000,
> which is hosted by Harka Gyozo at the University of Pécs in Pécs,
> Hungary. Thanks, Harka! Helge Deller, the main porter and buildd
> maintainer, for Debian's hppa (PA-RISC) port, helped in setting
> up a total of five buildd instances on Harka's machine (andi1
> through andi5) which helped to use the machine more efficiently.
> Plus, Helge is now registered as a wanna-build (Debian's package
> build database) which means he can trigger binNMUs and rebuilds
> on sparc64 as well. In order for Helge to be able to solve
> problems with the buildds, he has also been granted access to
> the sparc64 buildds which helps reducing my workload. Thanks, Helge!
>
> Furthermore, I managed to fix several packages that were failing to
> build by completely disabling the gold linker on sparc64. As further
> research has shown, gold currently creates defect binaries due to
> the fact that it does not fully implement the specification for
> ELF binaries on SPARC.
>
> To be more precise, it lacks support for the so-called dummy symbol
> "STT_SPARC_REGISTER" which the linker uses to define how either of the
> four global CPU registers %[2367] are used. Since gold does not
> understand that STT_SPARC_REGISTER is a dummy symbol and not to
> be associated with an actual offset address, it sets the address
> field associated with the symbol to zero (while only 2, 3, 6 or
> 7 are valid values) which produces a defect object file which
> later produces the known error message on consecutive linker
> runs [1]:
>
>Only registers %g[2367] can be declared using STT_REGISTER
>
> The problem with this bug is that currently gold's internal
> representation of ELF objects has no way to accommodate these
> dummy symbols. This means, that gold needs additional work
> on its generic, non-target-specific code which will naturally
> take a bit longer.

Good work, John!

Out of curiosity, the STT_REGISTER issue is caused by ABI and is
not Linux-specific, so Solaris and *BSD have it too, right?

Artyom

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Quick status update on sparc64

[John Paul Adrian Glaubitz]

Hi!

Over the past weeks, we have made substantial progress in catching up
with the build queue and the number of packages which are up-to-date
in the sparc64 port are now over 8400 which means we have built more
than 700 packages since I started my thread with the subjet
"Resurrecting Debian on SPARC" on September, 15 2015.

One important factor is an additional buildd machine, a Sun T2000,
which is hosted by Harka Gyozo at the University of Pécs in Pécs,
Hungary. Thanks, Harka! Helge Deller, the main porter and buildd
maintainer, for Debian's hppa (PA-RISC) port, helped in setting
up a total of five buildd instances on Harka's machine (andi1
through andi5) which helped to use the machine more efficiently.
Plus, Helge is now registered as a wanna-build (Debian's package
build database) which means he can trigger binNMUs and rebuilds
on sparc64 as well. In order for Helge to be able to solve
problems with the buildds, he has also been granted access to
the sparc64 buildds which helps reducing my workload. Thanks, Helge!

Furthermore, I managed to fix several packages that were failing to
build by completely disabling the gold linker on sparc64. As further
research has shown, gold currently creates defect binaries due to
the fact that it does not fully implement the specification for
ELF binaries on SPARC.

To be more precise, it lacks support for the so-called dummy symbol
"STT_SPARC_REGISTER" which the linker uses to define how either of the
four global CPU registers %[2367] are used. Since gold does not
understand that STT_SPARC_REGISTER is a dummy symbol and not to
be associated with an actual offset address, it sets the address
field associated with the symbol to zero (while only 2, 3, 6 or
7 are valid values) which produces a defect object file which
later produces the known error message on consecutive linker
runs [1]:

   Only registers %g[2367] can be declared using STT_REGISTER

The problem with this bug is that currently gold's internal
representation of ELF objects has no way to accommodate these
dummy symbols. This means, that gold needs additional work
on its generic, non-target-specific code which will naturally
take a bit longer. Thus, until the associated PR [1] in gold
has been fixed, it's the safest option disable gold on sparc*
altogether. By not using gold, we won't loose anything really
except that the whole linking process takes longer as gold
has been designed with link-time reduction in mind. I am not
sure though whether there are actually any differences in the
resulting binaries though.

Anyway, we have now 8 buildd processes which are crunching
through the build queue now and with some luck, we might
be able to catch up with architectures like hppa in 1-2
more months unless there are more packages that need
additional manual work.

Future plans could see a sparc64 installation image for
Debian. Helge Deller has already this for hppa and he
will certainly lend his expertise and help us to create
fresh installation images for sparc64 so that all SPARC
machines still running the 32-bit port of Debian SPARC
can be upgraded to the 64-bit sparc64 port.

Cheers,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19019


-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Sparc status ?

[Anatoly Pugachev]

On Mon, Apr 28, 2014 at 9:06 PM, Axel Beckert a...@debian.org wrote:
 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.

I have successfully installed wheezy (debian-7.2.0-sparc-DVD-1.iso)
today to SF V215 hardware. Installation went clean. Upgraded to
unstable, now running 3.14-1-sparc64-smp . Meanwhile compiling 3.14.4
kernel sources as a test with gcc-4.9.  Going to leave this machine
running, just to see how stable it will be.


--
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/cadxrzqxof7aekx+mvlpgtgss4_8fu7ryrjfivxx5-upifp7...@mail.gmail.com

Re: Sparc status ?

[Sébastien Bernard]

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: Sparc status ?

[Patrick Baggett]

  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: Sparc status ?

[Patrick Baggett]

 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: Sparc status ?

[Sébastien Bernard]

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: Sparc status ?

[Axel Beckert]

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: Sparc status ?

[Julien Cristau]

On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote:

 Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit :
 I'd guess skilled hacker time is more needed than hardware. Reading
 https://release.debian.org/jessie/arch_qualify.html , it seems major
 blocking issues are: Using gcc-4.6 as default compiler and Have to run
 oldstable kernels. Related to this: only 1 porter, only partial upstream
 support. Bye, Joost - who'd _love_ to have a fully supported Debian on
 sparc
 So, if I have understood correctly, the main problem is that 32bit
 compilation is not supported in the current releases of gcc ?

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.

 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


signature.asc
Description: Digital signature

Re: Sparc status ?

[Sébastien Bernard]

Le 20/04/2014 18:26, Patrick Baggett a écrit :


Also, a lot of the messages about removing v8 support or upstream 
dropping sparc32 is confusing. SPARCv8, sometimes called sparc32 
(more specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA, 
SPARCv9) is used by just /one/ CPU that is modern -- Leon. The 
remaining CPUs are all 64-bit since 1997. However, a 32-bit 
/ABI/ (note ABI, NOT ISA) used on a v9 platform seems like a sane 
idea, and that is the current case of Debian and Solaris. This is 
because it's absolutely a terrible idea to remove a 32-bit ABI for v9 
CPUs. This ABI is called v8+, which incidentally is a terrible name.


I don't care if Debian or other upstream packages drops sparc32 aka 
v8 support, because the current kernel will only boot on SPARCv9 
CPUs, so it doesn't make any sense to add a constraint that binaries 
must run on v8 CPUs. And I mostly don't care if GCC removes the 
ability to generate sparc32 aka SPARCv8 code. What I /do/ care 
about it the removal of the ability to build 32-bit binaries on 
SPARCv9, because 64-bit only binaries is a ridiculous idea.


So Jurij, I don't see any reason to believe that upstream support is 
disappearing. None of the messages are from GCC maintainers directly, 
and nothing on GCC's website about 4.7 / 4.8 states this to be the case.


Patrick



Ok, so,  if I make a long story short:
  first showstopper (a.k.a. no/partial upstream support from gcc) for 
jessie is a red herring, nothing should prevent the switch to the 
gcc-4.8 toolchain.
  second old kernel - Well, how to put that... the machine I have is 
running 3.13, so maybe the obligation to run old kernel does not really 
stand for all hardware.


Then, maybe sparc porter must tell debian release team that the two 
problem identified really aren't that much problem.


Seb

Re: Sparc status ?

[Jurij Smakov]

On Fri, Apr 18, 2014 at 6:11 PM, Sébastien Bernard sbern...@nerim.netwrote:


  Doh, beat me to it by a minute. Yeah, you see what I mean. :)

 It would be platform suicide to drop 32-bit code generation. Like many
 RISC architectures, switching to 64-bit is only done for apps that need it,
 because it is not free and will not, in general, make apps faster. Anyone
 who has worked on PPC, MIPS, SPARC, etc will be able to confirm this in a
 heartbeat, and no doubt gcc-sparc maintainers are aware of this as well.

 Patrick

  So this does not really help to understand why the switch to gcc-4.8
 didn't happened on the sparc architecture.


Because GCC maintainers have been saying for years, that they are unwilling
to support the weird use case of Debian sparc port, which has 64-bit kernel
but 32-bit userspace. I can find discussions about it going back as far as
2009:

https://lists.debian.org/debian-sparc/2009/08/msg00010.html

Another possibly relevant bit is that Aurelien Jarno started working on an
unofficial sparc64 port a while ago, but the current status of it is
unknown to me. See, for example

https://wiki.debian.org/Sparc64




 Cheers.

 Sébastien



 --
 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/53515cb3.7030...@nerim.net




-- 
Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D

Re: Sparc status ?

[Patrick Baggett]

 Because GCC maintainers have been saying for years, that they are
 unwilling to support the weird use case of Debian sparc port, which has
 64-bit kernel but 32-bit userspace. I can find discussions about it going
 back as far as 2009:

 https://lists.debian.org/debian-sparc/2009/08/msg00010.html


This is a weak case. I have 64-bit MIPS hardware running debian and it
doesn't seem to matter to anyone that the userspace is 32-bit, though the
kernel is 64-bit and I can also run 64-bit MIPS binaries on it.

GCC is also used on Solaris/SPARC which has a 64-bit kernel and 32-bit
userland.

I just don't buy the debian sparc is a [uniquely] weird use case. It's
not even unique to Debian, and it's not even unique to SPARC.

Patrick

Re: Sparc status ?

[Patrick Baggett]

 Because GCC maintainers have been saying for years, that they are
 unwilling to support the weird use case of Debian sparc port, which has
 64-bit kernel but 32-bit userspace. I can find discussions about it going
 back as far as 2009:


Also, a lot of the messages about removing v8 support or upstream
dropping sparc32 is confusing. SPARCv8, sometimes called sparc32 (more
specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA, SPARCv9) is
used by just *one* CPU that is modern -- Leon. The remaining CPUs are all
64-bit since 1997. However, a 32-bit *ABI* (note ABI, NOT ISA) used on a v9
platform seems like a sane idea, and that is the current case of Debian and
Solaris. This is because it's absolutely a terrible idea to remove a 32-bit
ABI for v9 CPUs. This ABI is called v8+, which incidentally is a terrible
name.

I don't care if Debian or other upstream packages drops sparc32 aka v8
support, because the current kernel will only boot on SPARCv9 CPUs, so it
doesn't make any sense to add a constraint that binaries must run on v8
CPUs. And I mostly don't care if GCC removes the ability to generate
sparc32 aka SPARCv8 code. What I *do* care about it the removal of the
ability to build 32-bit binaries on SPARCv9, because 64-bit only binaries
is a ridiculous idea.

So Jurij, I don't see any reason to believe that upstream support is
disappearing. None of the messages are from GCC maintainers directly, and
nothing on GCC's website about 4.7 / 4.8 states this to be the case.

Patrick

Re: Sparc status ?

[Patrick Baggett]

I really don't understand why this 32-bit gone myth is happening. It was
poor wording at least. Debian doesn't even support the ancient 32-bit sparc
CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running
in 32-bit code, it's like x32 ABI in x86 land.

SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now
SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just
fine.

And just so we can finally kill this rumor dead:

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options

GCC still supports the 32-bit ABI:

With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference
from the V8 ABI is that the global and out registers are considered 64 bits
wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9
processors.


So no, you don't need to rebuild everything as 64-bit binaries, or should I
say, rebuild under LP64 model. That wouldn't even make sense and would hurt
performance. Please refer anyone who believes this to this message.

Patrick


On Fri, Apr 18, 2014 at 3:44 AM, Sébastien Bernard sbern...@nerim.netwrote:

 Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit :

  I'd guess skilled hacker time is more needed than hardware. Reading
 https://release.debian.org/jessie/arch_qualify.html , it seems major
 blocking issues are: Using gcc-4.6 as default compiler and Have to run
 oldstable kernels. Related to this: only 1 porter, only partial upstream
 support. Bye, Joost - who'd _love_ to have a fully supported Debian on
 sparc

 So, if I have understood correctly, the main problem is that 32bit
 compilation is not supported in the current releases of gcc ?
 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 ?

 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/5350e5e0.1090...@nerim.net

Re: Sparc status ?

[Joël BERTRAND]

Le 18/04/2014 14:16, Patrick Baggett a écrit :

I really don't understand why this 32-bit gone myth is happening. It
was poor wording at least. Debian doesn't even support the ancient
32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs
even when running in 32-bit code, it's like x32 ABI in x86 land.


	Debian sparc userland is v8+. It only is usable on v9 CPU, not v8. I 
have reinstalled all my old sparc v8 under NetBSD.



SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now


You have forgotten Leon CPU that are v8e (32 bits), not v8+ or v9.


SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them
just fine.


There are some bugs in userland (mainly due to endianess).

Regards,

JKB


--
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/53511a08.8090...@systella.fr

Re: Sparc status ?

[Patrick Baggett]

Yeah, I understand why you would believe that. I'm not blaming you, I just
want to let everyone know the sentence 32-bit code generation as we use it
is no longer supported upstream is incorrect. You can see on the GCC 4.7
[1] and 4.8 [2] changes list that removing any SPARC code generation
features is NOT mentioned. In fact, the only SPARC related change was GCC
4.7 dropping Solaris 8, which has been EOL for a long time.

There is no need to switch to a 64-bit userland. I can already build both
32-bit and 64-bit apps on my system, right now.

[1] http://gcc.gnu.org/gcc-4.7/changes.html
[2] http://gcc.gnu.org/gcc-4.8/changes.html


On Fri, Apr 18, 2014 at 11:35 AM, Sébastien Bernard sbern...@nerim.netwrote:

  Le 18/04/2014 14:16, Patrick Baggett a écrit :

 I really don't understand why this 32-bit gone myth is happening. It was
 poor wording at least. Debian doesn't even support the ancient 32-bit sparc
 CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running
 in 32-bit code, it's like x32 ABI in x86 land.

  SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them now
 SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just
 fine.

  And just so we can finally kill this rumor dead:


 http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options

  GCC still supports the 32-bit ABI:

  With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference
 from the V8 ABI is that the global and out registers are considered 64 bits
 wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9
 processors.


 So no, you don't need to rebuild everything as 64-bit binaries, or should
 I say, rebuild under LP64 model. That wouldn't even make sense and would
 hurt performance. Please refer anyone who believes this to this message.

  Patrick


   So, if I have understood correctly, the main problem is that 32bit
 compilation is not supported in the current releases of gcc ?
 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
 ?

 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/5350e5e0.1090...@nerim.net


  Maybe it was poor understanding by my side. I read the
 https://release.debian.org/jessie/arch_qualify.html and at the bottom
 line, there is this mention of this :
  sparc  Upstream Support

  According to the gcc maintainer 32bit code generation as we use it is no
 longer supported upstream and we should aim for  a switch to 64bit
 userland anytime soon.
 This is quite clear, and maybe plain wrong according to you.
 This seems to prevent switch from gcc 4.6 to gcc 4.8.

 Seb

Re: Sparc status ?

[Patrick Baggett]

 I don't understand, there is no warning of abi or architecture deprecation
 in the release notes of gcc, neither 4.7 nor 4.8.
 Maybe they have information I don't, but I doubt it. I'll dig in the gcc
 mailing list to see if I can find something related.

 Sébastien


Doh, beat me to it by a minute. Yeah, you see what I mean. :)

It would be platform suicide to drop 32-bit code generation. Like many RISC
architectures, switching to 64-bit is only done for apps that need it,
because it is not free and will not, in general, make apps faster. Anyone
who has worked on PPC, MIPS, SPARC, etc will be able to confirm this in a
heartbeat, and no doubt gcc-sparc maintainers are aware of this as well.

Patrick

Re: Sparc status ?

[Sébastien Bernard]

Doh, beat me to it by a minute. Yeah, you see what I mean. :)

It would be platform suicide to drop 32-bit code generation. Like many 
RISC architectures, switching to 64-bit is only done for apps that 
need it, because it is not free and will not, in general, make apps 
faster. Anyone who has worked on PPC, MIPS, SPARC, etc will be able to 
confirm this in a heartbeat, and no doubt gcc-sparc maintainers are 
aware of this as well.


Patrick

So this does not really help to understand why the switch to gcc-4.8 
didn't happened on the sparc architecture.


Cheers.

Sébastien


--
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/53515cb3.7030...@nerim.net

Sparc status ?

[Sébastien Bernard]

Reading the 2 or 3 warning from from debian-devel-announce,
I'm afraid that the sparc architecture is going legacy the same way that 
it did for the hppa.

What could it be done to keep this architecture as a first class citizen ?

If I understood correctly, the debian port of debian is on watch and 
should improve or it'll be removed from testing,

which would be unfortunate.

What could be done to improve the situation of this port ?
Is the sparc architecture no more relevant to modern computing ?

I'm willing to dedicate a share of my time or hardware if there's 
something to be done.


Cheers

S. Bernard




--
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/53506b97.7000...@nerim.net

Re: Sparc status ?

[Joost van Baal-Ilić]

On Fri, Apr 18, 2014 at 02:02:31AM +0200, Sébastien Bernard wrote:
 Reading the 2 or 3 warning from from debian-devel-announce,
 I'm afraid that the sparc architecture is going legacy the same way
 that it did for the hppa.
 What could it be done to keep this architecture as a first class citizen ?
 
 If I understood correctly, the debian port of debian is on watch and
 should improve or it'll be removed from testing,
 which would be unfortunate.
 
 What could be done to improve the situation of this port ?
 Is the sparc architecture no more relevant to modern computing ?
 
 I'm willing to dedicate a share of my time or hardware if there's
 something to be done.

I'd guess skilled hacker time is more needed than hardware.
Reading https://release.debian.org/jessie/arch_qualify.html ,
it seems major blocking issues are: Using gcc-4.6 as default compiler
and Have to run oldstable kernels.  Related to this: only 1 porter,
only partial upstream support.

Bye,

Joost - who'd _love_ to have a fully supported Debian on sparc


-- 
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/20140418045627.gv2...@beskar.mdcc.cx

Re: Roll call for porters of architectures in sid and testing (Status update)

[Martin Lucina]

Hi,

b...@decadent.org.uk said:
  I've also provided a couple of kernel patches in the past. I'm cross
  testing with Gentoo to ensure that bugs I report are Debian-specific
  or ia64-generic.
  
  I'll continue testing/software development activity on ia64 for the
  Jessie cycle, and more generally, until Debian drops ia64. I'm already
  waiting for Wayland on ia64 and other big updates.
  
  So please, keep ia64 in the bandwagon ;-)
 
 But I don't think ia64 is well-supported even in wheezy.  The kernel
 doesn't boot on some common machines and no-one seems to be able to fix
 it.

I'm the most recent person to report that bug. Unfortunately I run a sole
ia64 box in a production setting and I only have physical access to it
during business hours (and no management card) which makes experimenting
with kernels difficult.

I would be more than happy to sign up as a porter for ia64 however I would
need to obtain more hardware. HP rx1620s can be had on eBay for $100 but
they are located in California and shipping + customs to Slovakia is not
worth it :-/

If someone is willing to donate hardware, or knows of a cheap source of
ia64 hardware in Europe I'm more than happy to host it here, maintain it,
provide access to developers, and time permitting test and and help
diagnose ia64-specific problems with the base system for the lifetime of
the jessie release.

I am also a long-time Debian user (10 years, mostly x86/amd64, alpha in
the past, some arm work and ia64 from the time I've had this hardware). I
am not a DD/DM but have experience as a package maintainer via sponsorship
in the past.

Martin


signature.asc
Description: Digital signature

Re: Roll call for porters of architectures in sid and testing (Status update)

[Émeric MASCHINO]

Hi,

I'm a long-time ia64 Debian user ( 10 years). I'm mostly focused on
desktop aspects (GNOME, Iceweasel, LibreOffice, Qt Creator, C++ 3D
software development) while most other ia64 users that I know are more
inclined on server use.

I'm not a DD/DM, but daily update my ia64 workstation, report bugs and
do my best to provide useful information in order to get them fixed.
I've also provided a couple of kernel patches in the past. I'm cross
testing with Gentoo to ensure that bugs I report are Debian-specific
or ia64-generic.

I'll continue testing/software development activity on ia64 for the
Jessie cycle, and more generally, until Debian drops ia64. I'm already
waiting for Wayland on ia64 and other big updates.

So please, keep ia64 in the bandwagon ;-)

 Émeric

2013/9/20 Lennart Sorensen lsore...@csclub.uwaterloo.ca:
 On Fri, Sep 20, 2013 at 11:19:24AM -0400, Federico Sologuren wrote:
 i have a HP Visualize B2000 that i managed to install last night from iso
 distribution that i found after a lot of looking. at this point only
 terminal is working. will keep reading to get debian up and running.

 i would like to get involved. will need some additional information on what
 is needed and what skills are required. what does DD/DM stand for?

 DD = Debian Developer
 DM = Debian Maintainer

 unless I remember wrong of course. :)

 --
 Len Sorensen


 --
 To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20130920181059.gj13...@csclub.uwaterloo.ca



--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caa9xbm7xvu5xd4vz1a7h9ccqp0+k+k6k3ondty3rqnp_oex...@mail.gmail.com

Re: Roll call for porters of architectures in sid and testing (Status update)

[Ben Hutchings]

On Sat, 2013-09-21 at 19:36 +0200, Émeric MASCHINO wrote:
 Hi,
 
 I'm a long-time ia64 Debian user ( 10 years). I'm mostly focused on
 desktop aspects (GNOME, Iceweasel, LibreOffice, Qt Creator, C++ 3D
 software development) while most other ia64 users that I know are more
 inclined on server use.
 
 I'm not a DD/DM, but daily update my ia64 workstation, report bugs and
 do my best to provide useful information in order to get them fixed.

Thank you for this.

 I've also provided a couple of kernel patches in the past. I'm cross
 testing with Gentoo to ensure that bugs I report are Debian-specific
 or ia64-generic.
 
 I'll continue testing/software development activity on ia64 for the
 Jessie cycle, and more generally, until Debian drops ia64. I'm already
 waiting for Wayland on ia64 and other big updates.
 
 So please, keep ia64 in the bandwagon ;-)

But I don't think ia64 is well-supported even in wheezy.  The kernel
doesn't boot on some common machines and no-one seems to be able to fix
it.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

Re: Roll call for porters of architectures in sid and testing (Status update)

[John David Anglin]

On 21-Sep-13, at 7:23 PM, Ben Hutchings wrote:


I'll continue testing/software development activity on ia64 for the
Jessie cycle, and more generally, until Debian drops ia64. I'm  
already

waiting for Wayland on ia64 and other big updates.

So please, keep ia64 in the bandwagon ;-)


But I don't think ia64 is well-supported even in wheezy.  The kernel
doesn't boot on some common machines and no-one seems to be able to  
fix

it.



I don't believe this for a minute.  This is about Debian and it's  
ability to attract capable

porters.

I seem to recall that a recent Wayland build is in the unstable parisc  
archive...


Dave
--
John David Anglin   dave.ang...@bell.net




--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp95e95ff163518fb536728097...@phx.gbl

Re: Roll call for porters of architectures in sid and testing (Status update)

[Michael Cree]

FWIW, I am a porter of the Alpha architecture in the following ways:

 - run a buildd
 - kernel support
 - work with upstreams for toolchain support
 - general porting work including filing bugs and patches

I doubt if I will continue that for the life cycle of Jessie given that
many of the former faithful seem to be deserting alpha and I don't fancy
being the last one left to turn off the lights.

But possibly of interest is that I seem to be finding myself using arm
based hardware more and more and I anticipate that I might soon be doing
arm porting work.  Whether that is for all or just a subset of arm ports
is yet to be seen.

I am subscribed to the debian-alpha and debian-arm mail lists.

I am not a DD.

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130920092747.GA6590@omega

Re: Roll call for porters of architectures in sid and testing (Status update)

[Federico Sologuren]

i have a HP Visualize B2000 that i managed to install last night from iso
distribution that i found after a lot of looking. at this point only
terminal is working. will keep reading to get debian up and running.

i would like to get involved. will need some additional information on what
is needed and what skills are required. what does DD/DM stand for?


On Fri, Sep 20, 2013 at 4:32 AM, Gasha ga...@pie-dabas.net wrote:

 Hi,

 I am an active tester (not always porter) for the following architectures
 and I intend
 to continue this for the lifetime of the jessie release:

 i386, amd64, armel

 - test most base packages on this architecture (every day tasks)
 - test arch-related things
 - test lots of ipv6 related issues


 sparc, powerpc
 - test base packages on this architecture (not every day)

 I also own SGI Indy (mips*), HP (hppa) and have access to HP Itanium
 (ia64).
 I have plans to do some debian on them, in my limited free time.

 I am not a DD/DM

 Gatis Visnevskis



 --
 To UNSUBSCRIBE, email to 
 debian-hppa-REQUEST@lists.**debian.orgdebian-hppa-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/**523c0811.4060...@pie-dabas.nethttp://lists.debian.org/523c0811.4060...@pie-dabas.net




-- 
Federico

Re: Roll call for porters of architectures in sid and testing (Status update)

[Lennart Sorensen]

On Fri, Sep 20, 2013 at 11:19:24AM -0400, Federico Sologuren wrote:
 i have a HP Visualize B2000 that i managed to install last night from iso
 distribution that i found after a lot of looking. at this point only
 terminal is working. will keep reading to get debian up and running.
 
 i would like to get involved. will need some additional information on what
 is needed and what skills are required. what does DD/DM stand for?

DD = Debian Developer
DM = Debian Maintainer

unless I remember wrong of course. :)

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130920181059.gj13...@csclub.uwaterloo.ca

Re: Roll call for porters of architectures in sid and testing (Status update)

[Niels Thykier]

On 2013-09-01 09:33, Niels Thykier wrote:
 Hi,
 
 As we announced in [LAST-BITS], we would like to get a better idea of
 that status of the ports, to make an informed decision about which
 port can be released with jessie. One of the steps is to get an
 overview of which of the porters are (still) active for each
 port. Once the results from the role-call are in, we will request
 other information about the status of the ports. In the meantime, feel
 free to update and collect info about the ports in the Debian wiki[WIKI].
 
 If you are (or intend to become) an active porter for the lifetime of
 jessie, then please send a signed email explaining your involvement in
 the port to the Release Team debian-rele...@lists.debian.org before
 1st of October 2013. Please explain the level of your involvement in
 the port.
 
 Feel free to use the following template as your reply:
 
 [...]
 
 Niels, on behalf of the release team
 
 [LAST-BITS] 
 http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
 
 [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
 


Hi all,

Here is a little status update on the mails we have received so far.
First off, thanks to all the porters who have already replied!

So far, the *no one* has stepped up to back the following architectures:

   hurd-i386
   ia64
   mips
   mipsel
   s390x

I have pinged some people and #d-hurd, so this will hopefully be amended
soon.  Remember that the *deadline is 1st of October*.

In the list above, I excluded:

  amd64 and i386: requirement for porters is waived
  s390: Being removed from testing during the Jessie cycle
(Agreement made during the Wheezy release cycle)

The following table shows the porters for each architecture in
*unstable* that I have data on so far:

armel: Wookey (DD)
armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD)
kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD),
   Petr Salinger (!DD), Robert Millan (DD)
kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD),
   Petr Salinger (!DD), Robert Millan (DD)
powerpc: Geoff Levand (!DD), Roger Leigh (DD)
sparc: Axel Beckert (DD), Rainer Herbst (!DD)


If you are missing from this list above, then I have missed your email.
 Please follow up to this mail with a message-ID (or resend it,
whichever you prefer).

We also got a number of people interested in architectures not currently
in unstable.  These are:

  alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD)
  arm64: Wookey (DD)
  parisc/hppa: Helge Deller (!DD)
  ppc64: Steven Gawroriski (!DD)
  sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD)

This will hopefully teach me to remember to include the in unstable
restriction to the next roll call.  :)  Anyhow, if you are working on
these architectures on debian-ports and saw a new name in the list
above, this might be an opportunity to recruit new people.


We also received a couple of emails from people who are not or did not
want to be porters at the moment.  However, they expressed an interest
in the architectures:

  David Kuehling: mipsel
- debug arch-related issues
  Meelis Roos: ppc, sparc64 (parisc)
- test and report bugs in upstream kernel
  Peter Green: armhf (possibly any-arm)
- works on raspbian


In the template email included in the roll call, we included some tasks
that people might be doing.  These are the task people have said they
are doing for a given port.

  * test packages: armhf, kfreebsd-amd64 (x4), kfreebsd-i386 (x4),
 powerpc, sparc (x2)
  * fix toolchain issues: armhf, powerpc
  * triage arch-specific bugs: armhf, kfreebsd-amd64 (x3),
 kfreebsd-i386 (x3), powerpc, sparc (x2)
  * fix arch-related bugs: armhf, kfreebsd-amd64 (x3),
  kfreebsd-i386 (x3), powerpc
  * maintain buildds: armhf, kfreebsd-amd64, kfreebsd-i386

NB: I have manually translated some prose-text into the items above, so
something might have been lost (or gained) in that translation.

Some of the porters also added some new items.  I have included some of
these items below:

  + test d-i when needed: powerpc (x2)
  + maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386
  + maintain non-DSA porter box: kfreebsd-amd64
  + maintain production system of $arch: sparc/stable
  + can offer hardware access[1]: sparc (Axel Beckert)
  + eglibc issues: kfreebsd-amd64, kfreebsd-i386
  + maintain+test cross-toolchains for $arch: armel, armhf

~Niels

[1] Restrictions may apply.


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/523ab805.7000...@thykier.net

Re: Roll call for porters of architectures in sid and testing (Status update)

[Lennart Sorensen]

On Thu, Sep 19, 2013 at 10:38:29AM +0200, Niels Thykier wrote:
 Here is a little status update on the mails we have received so far.
 First off, thanks to all the porters who have already replied!
 
 So far, the *no one* has stepped up to back the following architectures:
 
hurd-i386
ia64
mips
mipsel
s390x
 
 I have pinged some people and #d-hurd, so this will hopefully be amended
 soon.  Remember that the *deadline is 1st of October*.
 
 In the list above, I excluded:
 
   amd64 and i386: requirement for porters is waived
   s390: Being removed from testing during the Jessie cycle
 (Agreement made during the Wheezy release cycle)
 
 The following table shows the porters for each architecture in
 *unstable* that I have data on so far:
 
 armel: Wookey (DD)
 armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD)
 kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD),
Petr Salinger (!DD), Robert Millan (DD)
 kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD),
Petr Salinger (!DD), Robert Millan (DD)
 powerpc: Geoff Levand (!DD), Roger Leigh (DD)
 sparc: Axel Beckert (DD), Rainer Herbst (!DD)
 
 
 If you are missing from this list above, then I have missed your email.
  Please follow up to this mail with a message-ID (or resend it,
 whichever you prefer).

Message-ID: 20130904160124.gt12...@csclub.uwaterloo.ca
Sent September 4th.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130919145648.gf13...@csclub.uwaterloo.ca

Re: status of ruby 1.9.1 wrt porting

[Lennart Sorensen]

On Mon, Aug 29, 2011 at 11:48:34PM +0200, Lucas Nussbaum wrote:
 Ruby 1.9.3 is going to be released in september, and is a candidate for
 the default ruby version in wheezy. A snapshot is available in
 experimental. Now is an ideal time to work on porting issues and get the
 fixes integrated upstream. Ruby has a fairly large test suite, which
 makes finding problems easy, but exercises the threading library in
 interesting ways.
 
 Most of the issues are reproducible by re-building the Debian package.
 Use make  make test to get a shorter build.
 
 Here is the current complete list of issues I'm aware of. My time will
 be very limited in the coming weeks, but I will try my best to provide
 help.
 
 [armel,sparc] FTBFS due to miscompilation with -ftree-sra (inc. in -O3).
 See http://bugs.debian.org/635126.
 Currently worked-around by using -fno-tree-sra.
 Other packages might be affected.
 - FIXED from ruby1.9.1's POV, but you really want to look at this
for other packages.
 
 [armel] I've just seen that now that this one is fixed, the test suite
 segfaults.
 See
 https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1arch=armelver=1.9.3~preview1%2Bsvn33077-1stamp=1314634969
 search for 'TestFiber#test_many_fibers'.
 'make test-all' to reproduce. Failures during test-all are currently not
 fatal. The remaining ones needs more investigation, but I don't think
 that they are arch-specific. I'd like to make test-all failures fatal at
 some point.

Building on armhf seemed to go fine, and running some of the examples
looked good too.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110830140829.gl15...@caffeine.csclub.uwaterloo.ca

status of ruby 1.9.1 wrt porting

[Lucas Nussbaum]

Hi,

Ruby 1.9.3 is going to be released in september, and is a candidate for
the default ruby version in wheezy. A snapshot is available in
experimental. Now is an ideal time to work on porting issues and get the
fixes integrated upstream. Ruby has a fairly large test suite, which
makes finding problems easy, but exercises the threading library in
interesting ways.

Most of the issues are reproducible by re-building the Debian package.
Use make  make test to get a shorter build.

Here is the current complete list of issues I'm aware of. My time will
be very limited in the coming weeks, but I will try my best to provide
help.

[armel,sparc] FTBFS due to miscompilation with -ftree-sra (inc. in -O3).
See http://bugs.debian.org/635126.
Currently worked-around by using -fno-tree-sra.
Other packages might be affected.
- FIXED from ruby1.9.1's POV, but you really want to look at this
   for other packages.

[armel] I've just seen that now that this one is fixed, the test suite
segfaults.
See
https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1arch=armelver=1.9.3~preview1%2Bsvn33077-1stamp=1314634969
search for 'TestFiber#test_many_fibers'.
'make test-all' to reproduce. Failures during test-all are currently not
fatal. The remaining ones needs more investigation, but I don't think
that they are arch-specific. I'd like to make test-all failures fatal at
some point.

[sparc] continuations are completely broken.
See http://redmine.ruby-lang.org/issues/5244 (minimal test case
included)

[ia64] crashes during test suite, linked to continuations according to
backtrace.
See http://redmine.ruby-lang.org/issues/5246. 'make test' to reproduce.
Might be related to the sparc problem above.

[kfreebsd] waitpid from threads problem
http://redmine.ruby-lang.org/issues/5239
http://bugs.debian.org/639658
Will add a patch in test suite runner to work-around this
- FIXED from ruby1.9.1's POV.

[kfreebsd] mmap() with MAP_STACK requires non-null first arg
http://redmine.ruby-lang.org/issues/5241
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=158755
patch will be applied upstream, added to Debian package in the meantime
- FIXED from ruby1.9.1's POV.

[kfreebsd] thread-related hangs
http://redmine.ruby-lang.org/issues/5240
bisected the upstream commit.
Petr Salinger working on a fix, see
http://lists.debian.org/debian-bsd/2011/08/msg00180.html


I've just uploaded (to experimental) a new version fixing the issues marked 
FIXED.

Thanks!

- Lucas


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110829214834.ga2...@xanadu.blop.info

Re: Sparc64 status / overview page

[Aurelien Jarno]

On Fri, Jul 02, 2010 at 11:40:20AM +0200, Sebastian Andrzej Siewior wrote:
 Hi Aurelien,

Hi,

 it looks like you are the only sparc64 porter atleast I haven't found
 any other uploaders on debian-ports in the changes files for June.
 There is no status / info page about the port. Such a page or something
 else what is representative for the port would be handy so I can include
 it in #571325. The question is what should pop up if you click on
  packages.d.o/sid/sparc64/pkg/download
 

It's a port I have started following a discussion on IRC with the
release team. Given the Sparc32 port is slowly dying due to lack of
upstream support it is necessary to switch sooner or later to a Sparc64
port. DSA was kind enough to give me access to zee.debian.org that is
faster than my UltraSparc machine, and that also runs a build daemon.

The base of the port is there, but there are still a lot of work mainly
to get Qt and OpenJDK working here before the port can progress further.

I have created a quick and dirty Sparc64 page on the wiki [1], please
fill free to improve it.

Cheers,
Aurelien

[1] http://wiki.debian.org/Sparc64

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100703163521.ga4...@ohm.aurel32.net