Re: Resurrecting Debian on SPARC

[James Reggie Reilly]

On Fri, Nov 13, 2015 at 11:02:14AM +, James Reggie Reilly wrote:
> On Fri, Nov 13, 2015 at 12:18:37AM -0800, Tony Rodriguez wrote:
> > YES, Please resurrect Debian on SPARC! I have a couple of T5140s and one
> > T5120 that I would be love to continue running Debian on.
> > 
> > Thanks,
> > Tony
> > 
> 
> 
> +1
> 
> Huge SPARC fan, would love to keep debian running on the arch. In a week
> or so I should have a T2000 I can dedicate to buildd/testing and am
> willing to help out however I can.
> 
> James


OK. Just today picked up the T2000 in question. Will ping back in the next
couple of days when I get it set up and it's ready to run buildd.

James




signature.asc
Description: Digital signature

Re: Resurrecting Debian on SPARC

[Romain Dolbeau]

2015-11-19 16:35 GMT+01:00 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:
>
> What's the proper fix then? Preferably one that works on sparc (v8+)
> as well.

Just the 'mc_' :-) At least if it works with REG_O6, which I suspect it
should since userland should load the glibc header rather than the kernel
header (... I think).

And it should work with v8+ as well (v8+ is v9 in 32 bits mode,
fundamentally. So it has the new instructions like CAS, the new CCR
registers, ...).
%o6 has been %sp since v7, IIRC (i.e. the Stack Pointer is in Output
register 6, so is available to the callee in %i6, Input register 6, as the
Frame Pointer %fp). SPARC register windows are cool when you get to know
them :-)

Cordially,

--
Romain Dolbeau

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/19/2015 04:29 PM, Romain Dolbeau wrote:
> It seems the glibc-2.21 header
> (sysdeps/unix/sysv/linux/sparc/sys/ucontext.h) defines REG_O6 as well,
> so that bit of the fix might not be necessary. It does use mc_gregs like
> 3.16.

That's the only fix I applied and it fixed the FTBFS.

What's the proper fix then? Preferably one that works on sparc (v8+)
as well.

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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/19/2015 04:21 PM, John Paul Adrian Glaubitz wrote:
>> So perhaps:
>> #define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *)
>> ucp)->uc_mcontext.mc_gregs[MC_O6]
> 
> I'll give that a shot.

FIXED!

Will upload the fixed package to "unreleased" right away.

Does this have to be changed for sparc (v8+) as well?

Thanks,
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: Resurrecting Debian on SPARC

[Romain Dolbeau]

2015-11-19 16:21 GMT+01:00 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:
>
> > So perhaps:
> > #define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *)
> > ucp)->uc_mcontext.mc_gregs[MC_O6]
>
> I'll give that a shot.
>

It seems the glibc-2.21 header
(sysdeps/unix/sysv/linux/sparc/sys/ucontext.h) defines REG_O6 as well, so
that bit of the fix might not be necessary. It does use mc_gregs like 3.16.

Cordially,

--
Romain Dolbeau

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/19/2015 04:19 PM, Romain Dolbeau wrote:
> Armchair quarterbacking here, but from my old copy of linux 3.16, the
> registers from the windows are named mc_gregs not gregs. The definition
> of "ucontext_t" is in
> "linux-source-3.16/arch/sparc/include/uapi/asm/uctx.h". It's also not
> REG_O6 but MC_O6 apparently.
> 
> So perhaps:
> #define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *)
> ucp)->uc_mcontext.mc_gregs[MC_O6]

I'll give that a shot.

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: Resurrecting Debian on SPARC

[Romain Dolbeau]

2015-11-19 16:05 GMT+01:00 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:
>
>
https://buildd.debian.org/status/fetch.php?pkg=libsigsegv&arch=sparc64&ver=2.10-4&stamp=1447500379
> If you have any idea on how to fix this issue, I would be more than
> happy to integrate your patch :).


Armchair quarterbacking here, but from my old copy of linux 3.16, the
registers from the windows are named mc_gregs not gregs. The definition of
"ucontext_t" is in "linux-source-3.16/arch/sparc/include/uapi/asm/uctx.h".
It's also not REG_O6 but MC_O6 apparently.

So perhaps:
#define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *)
ucp)->uc_mcontext.mc_gregs[MC_O6]

Cordially,

--
Romain Dolbeau

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

Hi David!

On 11/18/2015 01:53 AM, David Matthew Mattli wrote:
> I'm a programmer and I've been looking for a way to become more involved
> with Debian, if you'd be interested in my help.

Great!

> This past summer I spent some time investigating failed Debian/sparc
> builds. The main issues I found were the now fixed fpu corruption bug,
> the gold linker bug, and nettle. The nettle package was changed to
> enable "make check" on the builds and this fails on sparc. This was
> making nettle block a lot of packages before sparc was removed from
> Debian.

Yeah!

> As far as buildd hardware, some interesting machines are for sale on
> ebay for almost nothing. Some, like the t5120, have better single-thread
> performance and more threads than the t2000 class hardware. If you have
> a place for some noisy 1U servers I'd be happy to buy a machine for
> Debian use as a buildd or porterbox.
> 
> Thanks for standing up for Debian/sparc and I hope I can help!

If you want to help, have a look at the packages on sparc64 that
currently fail to build from source:

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

One package of particular importance which needs to be fixed is
libsigsegv:

>
https://buildd.debian.org/status/fetch.php?pkg=libsigsegv&arch=sparc64&ver=2.10-4&stamp=1447500379

If you have any idea on how to fix this issue, I would be more than
happy to integrate your patch :).

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: Resurrecting Debian on SPARC

[David Matthew Mattli]

John Paul Adrian Glaubitz  writes:

> On 11/13/2015 12:02 PM, James Reggie Reilly wrote:
>> Huge SPARC fan, would love to keep debian running on the arch. In a week
>> or so I should have a T2000 I can dedicate to buildd/testing and am
>> willing to help out however I can.
>
> We could actually set this one up as a buildd for sparc (32 bits)
> which is still on my TODO list.
>
> In order to be able to do that, we will need additional people who
> are willing to dedicate some time for supporting the port.
>
> Aurelien Jarno, who is the "gate keeper" for the Debian Ports
> infrastructure, asked me to present a team of at least 3 people
> who would be willing to dedicate some of their time to the
> port. The more, the better.
>
> I would be in and Helge Deller (the main porter behind the Debian
> hppa port) would help me. Is there anyone else here who has some
> experience hacking code who would be willing to help?

Hi Adrian

I'm a programmer and I've been looking for a way to become more involved
with Debian, if you'd be interested in my help.

This past summer I spent some time investigating failed Debian/sparc
builds. The main issues I found were the now fixed fpu corruption bug,
the gold linker bug, and nettle. The nettle package was changed to
enable "make check" on the builds and this fails on sparc. This was
making nettle block a lot of packages before sparc was removed from
Debian.

As far as buildd hardware, some interesting machines are for sale on
ebay for almost nothing. Some, like the t5120, have better single-thread
performance and more threads than the t2000 class hardware. If you have
a place for some noisy 1U servers I'd be happy to buy a machine for
Debian use as a buildd or porterbox.

Thanks for standing up for Debian/sparc and I hope I can help!

-David

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/13/2015 05:17 PM, Artyom Tarasenko wrote:
>> V8 supports more software (e.g., JavaScript JIT is not supported on
>> V9) and more older hardware.
> 
> I think JavaScript JIT is supported for v8plus which actually requires a V9 
> CPU,
> (it's a 64bit ABI with 32bit pointers, so v8/v8plus/v9 counterparts in the
> x86 world are i686/x32/x86_64).

Sorry, I confused V8 and V8plus, I actually was talking about the
latter. We have currently several packages like webkitgtk or
openjdk-7 which don't build on sparc64 while they built fine on
sparc.

I will follow up with a list of packages that needs porting later if
anyone wants to jump in and help. I can't take care of all packages
myself, even when it just comes to reporting bugs upstream.

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: Resurrecting Debian on SPARC

[Artyom Tarasenko]

On Fri, Nov 13, 2015 at 12:55 PM, John Paul Adrian Glaubitz
 wrote:

> My intention to revive "sparc" is because it uses the V8 instruction
> set as opposed to the V9 instruction set used by "sparc64".

 Wow, that's ambitious! AFAIR the last V8 Debian was Etch.

> V8 supports more software (e.g., JavaScript JIT is not supported on
> V9) and more older hardware.

I think JavaScript JIT is supported for v8plus which actually requires a V9 CPU,
(it's a 64bit ABI with 32bit pointers, so v8/v8plus/v9 counterparts in the
x86 world are i686/x32/x86_64).

Artyom

-- 
Regards,
Artyom Tarasenko

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

Re: Resurrecting Debian on SPARC

[Romain Dolbeau]

2015-11-13 12:55 GMT+01:00 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:

> My intention to revive "sparc" is because it uses the V8 instruction
> set as opposed to the V9 instruction set used by "sparc64". V8
> supports more software (e.g., JavaScript JIT is not supported on
> V9) and more older hardware.
>

Commonly accessible C8 CPUs are MicroSPARC, SuperSPARC and HyperSPARC (of
course there's a zillion other implementations like LEON, but those are not
'commonly' available). That's 20 years old 32 bits hardware. I love them
(currently trying to rebuild some recent software on Solaris 7 and 8 in v7
and v8 on my SS20s :-), but do you really think a recent Linux would work
(let alone "work well") on those? Even NetBSD has trouble on such old
hardware.

Also, a *lot* of software wants multithreading nowadays, and will require
some form of synchronization (including ICU for Unicode, and other unlikely
places). V8 doesn't have Compare-And-Swap, only Swap and Test-And-Set, like
v7. It's possible to emulate CAS, but it requires an extra memory byte for
the lock, which is non-trivial to do properly in the multi-process case
(inefficient multi-thread is trivial). GCC doesn't supply such emulation,
so lots of software will fail because symbols like __sync_fetch_and_add_4
are missing (C++11 atomic uses those nowaadays).

Don't take me wrong - I would *love* to be able to update my SS5-110MHz
running Debian 4 to a newer Debian. I'm just not sure whether it's worth
the hassle compared to say, trying to improve NetBSD or OpenBSD...

Cordially,

-- 
Romain Dolbeau

Re: Resurrecting Debian on SPARC

[James Reggie Reilly]

On Fri, Nov 13, 2015 at 12:55:24PM +0100, John Paul Adrian Glaubitz wrote:



> Aurelien Jarno, who is the "gate keeper" for the Debian Ports
> infrastructure, asked me to present a team of at least 3 people
> who would be willing to dedicate some of their time to the
> port. The more, the better.
> 
> I would be in and Helge Deller (the main porter behind the Debian
> hppa port) would help me. Is there anyone else here who has some
> experience hacking code who would be willing to help?
> 

I'm interested. How can I help (bar donating some hardware)?

James


signature.asc
Description: Digital signature

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/13/2015 12:02 PM, James Reggie Reilly wrote:
> Huge SPARC fan, would love to keep debian running on the arch. In a week
> or so I should have a T2000 I can dedicate to buildd/testing and am
> willing to help out however I can.

We could actually set this one up as a buildd for sparc (32 bits)
which is still on my TODO list.

In order to be able to do that, we will need additional people who
are willing to dedicate some time for supporting the port.

Aurelien Jarno, who is the "gate keeper" for the Debian Ports
infrastructure, asked me to present a team of at least 3 people
who would be willing to dedicate some of their time to the
port. The more, the better.

I would be in and Helge Deller (the main porter behind the Debian
hppa port) would help me. Is there anyone else here who has some
experience hacking code who would be willing to help?

My intention to revive "sparc" is because it uses the V8 instruction
set as opposed to the V9 instruction set used by "sparc64". V8
supports more software (e.g., JavaScript JIT is not supported on
V9) and more older hardware.

Cheers,
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: Resurrecting Debian on SPARC

[James Reggie Reilly]

On Fri, Nov 13, 2015 at 12:18:37AM -0800, Tony Rodriguez wrote:
> YES, Please resurrect Debian on SPARC! I have a couple of T5140s and one
> T5120 that I would be love to continue running Debian on.
> 
> Thanks,
> Tony
> 


+1

Huge SPARC fan, would love to keep debian running on the arch. In a week
or so I should have a T2000 I can dedicate to buildd/testing and am
willing to help out however I can.

James


signature.asc
Description: Digital signature

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/13/2015 10:52 AM, Tony Rodriguez wrote:
> PS - Will you please provide any additional instructions and specify any
> links needed to ensure I download from the correct sparc64 repo?

For sparc64, the following has been verified to work:

$ debootstrap --no-check-gpg --arch=sparc64 --foreign unstable
sparc64-chroot ftp://ftp.debian-ports.org/debian

$ chroot sparc64-chroot
$ ./debootstrap/debootstrap --second-stage

Normally, it should work without "--foreign" and consecutive running
of "./debootstrap/debootstrap --second-stage" but we are currently
running into a problem with the postinst script of the systemd
package which I haven't been able to solve yet. Looks quoting
issue with the shell script.

This will give you a minimal Debian sparc64 root filesystem from
which you can set up your system manually (APT, APT keys, networking
and so on).

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: Resurrecting Debian on SPARC

[Frans van Berckel]

Hi Tony,

Tony Rodriguez schreef op 2015-11-13 10:52:
Thanks I am new to the debootstrap command but I plan to install an 
older

wheezy imagine using the sparc cd iso and then execute debootstrap.

The debian website https://wiki.debian.org/Debootstrap  states:

"To setup a Wheezy  system:
main # cd /
main # mkdir /wheezy-chroot
main # debootstrap wheezy ./wheezy-chroot 
http://http.debian.net/debian/³



PS - Will you please provide any additional instructions and specify 
any

links needed to ensure I download from the correct sparc64 repo?


Are you able test what's on the wiki about bootstrapping sparc64, is 
still up to date?


https://wiki.debian.org/Sparc64

Thanks,

Frans van Berckel

Re: Resurrecting Debian on SPARC

[Tony Rodriguez]

Thanks I am new to the debootstrap command but I plan to install an older
wheezy imagine using the sparc cd iso and then execute debootstrap.

The debian website https://wiki.debian.org/Debootstrap  states:

"To setup a Wheezy  system:
main # cd /
main # mkdir /wheezy-chroot
main # debootstrap wheezy ./wheezy-chroot http://http.debian.net/debian/³


PS - Will you please provide any additional instructions and specify any
links needed to ensure I download from the correct sparc64 repo?


Thanks,
Tony


On 11/13/15, 1:32 AM, "John Paul Adrian Glaubitz"
 wrote:

>On 11/13/2015 09:18 AM, Tony Rodriguez wrote:
>> YES, Please resurrect Debian on SPARC! I have a couple of T5140s and one
>> T5120 that I would be love to continue running Debian on.
>
>You already can. You'll just have to install the machine using
>debootstrap for the time being until we are able to create usable
>install images. Anything else should be working and is up-to-date.
>
>With the plans of the debian-cd team to adopt "vmdebootstrap" in the
>future, it will hopefully be easier to create new install images in
>the future. In fact, someone on the debian-cd team I spoke to promised
>me they would eventually create unofficial install images for the
>ports architectures.
>
>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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 11/13/2015 09:18 AM, Tony Rodriguez wrote:
> YES, Please resurrect Debian on SPARC! I have a couple of T5140s and one
> T5120 that I would be love to continue running Debian on.

You already can. You'll just have to install the machine using
debootstrap for the time being until we are able to create usable
install images. Anything else should be working and is up-to-date.

With the plans of the debian-cd team to adopt "vmdebootstrap" in the
future, it will hopefully be easier to create new install images in
the future. In fact, someone on the debian-cd team I spoke to promised
me they would eventually create unofficial install images for the
ports architectures.

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: Resurrecting Debian on SPARC

[Tony Rodriguez]

YES, Please resurrect Debian on SPARC! I have a couple of T5140s and one
T5120 that I would be love to continue running Debian on.

Thanks,
Tony

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 10/30/2015 01:29 PM, John Paul Adrian Glaubitz wrote:
> On 10/30/2015 01:34 PM, Jose E. Marchesi wrote:
>> Cary is working on it.  He mentioned that supporting the
>> STT_SPARC_REGISTER symbols will require some work on the
>> target-independent code of gold, so it may take a while.
>>
>> Can't libsystemd be linked with ld/bfd instead of gold?
> 
> Not sure. I'll ask the systemd maintainers and Lennart.

Aha, the systemd maintainers *did* actually previously disable
gold for this particular reason [1].

Back then, they were primarily concerned about sparc though
and since sparc was recently removed from Debian, they dropped
the patch which resulted in the recent linking problems on
sparc64.

I will perform a manual rebuild of systemd on sparc64 later
today which will be linked using ld/bfd instead of gold.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760879

-- 
 .''`.  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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 10/30/2015 01:34 PM, Jose E. Marchesi wrote:
> Cary is working on it.  He mentioned that supporting the
> STT_SPARC_REGISTER symbols will require some work on the
> target-independent code of gold, so it may take a while.
> 
> Can't libsystemd be linked with ld/bfd instead of gold?

Not sure. I'll ask the systemd maintainers and Lennart.

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: Resurrecting Debian on SPARC

[Jose E. Marchesi]

> I've a SunFire 280r which I'd really like to see running Jessie to be
> used for compiling gcc-5.2 and gnu modula-2 amongst other things

We still have to wait for this rather serious upstream issue [1] in
binutils to be resolved before we can continue with any serious work
on either of the SPARC ports of Debian.

Unless this issue is fixed, binaries cannot be linked against libsystemd
properly meaning that many packages will fail to build from source
(FTBFS).

@Jose: Any updates regarding PR target/19019 in binutils?

Cary is working on it.  He mentioned that supporting the
STT_SPARC_REGISTER symbols will require some work on the
target-independent code of gold, so it may take a while.

Can't libsystemd be linked with ld/bfd instead of gold?

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 10/29/2015 10:06 PM, Gaius Mulley wrote:
> I've a SunFire 280r which I'd really like to see running Jessie to be
> used for compiling gcc-5.2 and gnu modula-2 amongst other things

We still have to wait for this rather serious upstream issue [1] in
binutils to be resolved before we can continue with any serious work
on either of the SPARC ports of Debian.

Unless this issue is fixed, binaries cannot be linked against libsystemd
properly meaning that many packages will fail to build from source
(FTBFS).

@Jose: Any updates regarding PR target/19019 in binutils?

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: Resurrecting Debian on SPARC

[Gaius Mulley]

Hi,

 +1 vote for resurrecting debian on sparc.

I've a SunFire 280r which I'd really like to see running Jessie to be
used for compiling gcc-5.2 and gnu modula-2 amongst other things

regards,
Gaius

Re: Resurrecting Debian on SPARC

[James Morris]

On 10/13/2015 12:21 AM, Frans van Berckel wrote:

On Thu, 2015-10-08 at 11:44 +1100, James Morris wrote:

FYI,

Oracle developers have been working on Sparc Linux (as some may have
noticed from lkml commits).  We've just made an initial cut of this
available publicly, for the purposes of sharing it with the wider
community.

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

There are some mailing lists, a git repo, installable distro etc.

I hope that some of this work will be useful to the Debian project,
and please feel free to provide us with feedback.


Checking: Did you know James, a serious sparc64 bug is solved in Stable
git tree? It's not committed in linux-uek.git yet?

sparc64: Fix userspace FPU register corruptions, as David said, this
bug is about two decades old.

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/lo
g/?id=refs%2Ftags%2Fv4.1.10&qt=grep&q=sparc



Hi Frans,

I've confirmed that the fix was in the released kernel and it's in the 
git tree.


Check out the tag:

$ git checkout -b my_lfs v4.1.8-15.1

Then you'll find the fix in commit 30471d04c2a3b1471a28d1ccf898bada2d3fc9ce


- James

Re: Resurrecting Debian on SPARC

[Frans van Berckel]

On Thu, 2015-10-08 at 11:44 +1100, James Morris wrote:
> FYI,
> 
> Oracle developers have been working on Sparc Linux (as some may have 
> noticed from lkml commits).  We've just made an initial cut of this 
> available publicly, for the purposes of sharing it with the wider
> community.
> 
> See https://oss.oracle.com/projects/linux-sparc/
> 
> There are some mailing lists, a git repo, installable distro etc.
> 
> I hope that some of this work will be useful to the Debian project, 
> and please feel free to provide us with feedback.

Checking: Did you know James, a serious sparc64 bug is solved in Stable
git tree? It's not committed in linux-uek.git yet?

sparc64: Fix userspace FPU register corruptions, as David said, this
bug is about two decades old.

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/lo
g/?id=refs%2Ftags%2Fv4.1.10&qt=grep&q=sparc

Thanks,


Frans van Berckel

Re: Resurrecting Debian on SPARC

[Mark Morgan Lloyd]

James Morris wrote:

FYI,

Oracle developers have been working on Sparc Linux (as some may have 
noticed from lkml commits).  We've just made an initial cut of this 
available publicly, for the purposes of sharing it with the wider 
community.


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

There are some mailing lists, a git repo, installable distro etc.

I hope that some of this work will be useful to the Debian project, and 
please feel free to provide us with feedback.


Good to hear and thanks for the update.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

Hi James!

> On Oct 8, 2015, at 9:44 AM, James Morris  wrote:
> 
> FYI,
> 
> Oracle developers have been working on Sparc Linux (as some may have noticed 
> from lkml commits).  We've just made an initial cut of this available 
> publicly, for the purposes of sharing it with the wider community.

This is awesome, thank you! I was actually wondering why there was apparently 
no public activity from Oracle and Fujitsu regarding SPARC despite them still 
selling SPARC-related hard- and software.

> See https://oss.oracle.com/projects/linux-sparc/
> 
> There are some mailing lists, a git repo, installable distro etc.

Superb!

> I hope that some of this work will be useful to the Debian project, and 
> please feel free to provide us with feedback.

Absolutely. What should be on top of the priority list is fixing binutils and 
gcc for SPARC. We had two rather nasty bugs in binutils [1] and [2].

While [1] has recently been fixed, thanks to Michael Karcher's excellent 
debugging skills, we still have [2] which needs to be fixed. It would be 
awesome if one of the SPARC experts at Oracle could take a look and use the 
reduced test case, that was again provided by Michael Karcher, to help fix the 
issue.

There is also another gcc bug which prevents us from using multi-arch (32-bit 
on 64-bit SPARC), but I haven't reported that one yet. Will follow up shortly.

I think it should also be in Oracle's and Fujitsu's interests to get the 
toolchain with binutils and gcc fixed on SPARC as I assume these are also used 
internally for development.

I will send an email to Debian FTP and the Buildd principal admins to ask them 
to ask SPARC (32 bit) back to ports, also citing your mail which proves there 
is still upstream support for SPARC.

Thanks a lot for your mail!

Adrian

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

Re: Resurrecting Debian on SPARC

[James Morris]

FYI,

Oracle developers have been working on Sparc Linux (as some may have 
noticed from lkml commits).  We've just made an initial cut of this 
available publicly, for the purposes of sharing it with the wider community.


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

There are some mailing lists, a git repo, installable distro etc.

I hope that some of this work will be useful to the Debian project, and 
please feel free to provide us with feedback.



- James

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/15/2015 12:07 PM, John Paul Adrian Glaubitz wrote:
> ===
> 
> gcc -DHAVE_CONFIG_H -I. -I../../../usbhid-dump/src -I..
> -I/«PKGBUILDDIR»/usbhid-dump/include
> -I/«PKGBUILDDIR»/build-deb/usbhid-dump
> -I/«PKGBUILDDIR»/build-deb/usbhid-dump/include -DNDEBUG
> -D_FORTIFY_SOURCE=2  -Os -Wall -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/include/libusb-1.0  -c -o usbhid-dump.o
> ../../../usbhid-dump/src/usbhid-dump.c
> /bin/bash ../libtool  --tag=CC   --mode=link gcc  -Os -Wall -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security
> -I/usr/include/libusb-1.0   -Wl,-z,relro -o usbhid-dump usbhid-dump.o
> ../lib/libuhd.la -lusb-1.0
> libtool: link: gcc -Os -Wall -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/include/libusb-1.0 -Wl,-z -Wl,relro -o
> usbhid-dump usbhid-dump.o  ../lib/.libs/libuhd.a -lusb-1.0
> /usr/bin/ld: //lib/sparc64-linux-gnu/libudev.so.1: Only registers
> %g[2367] can be declared using STT_REGISTER
> //lib/sparc64-linux-gnu/libudev.so.1: error adding symbols: No such file
> or directory
> collect2: error: ld returned 1 exit status
> make[6]: *** [usbhid-dump] Error 1
> 
> ===

I have filed a bug report against binutils for this now [1].

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: Resurrecting Debian on SPARC

[rod]

Oh one more thing I noticed:
I have to run the debootstrap --second-stage twice to get it to fully
install.

Not sure if this is normal but I thought I'd mention it.

Rod

On 9/25/2015 11:32 AM, rod wrote:
> Good afternoon,
> 
> Having re-read all of these emails again, I have two questions (before I
> go find another machine to play on so I don't mess this one (raverin) up):
> 
> 1) in my efforts to setup my own chroot build environment I have created
> it using the debootstrap command as discussed and created a directory in
> my home directory: "sid-sparc64-sbuild-rod".  This hasn't been that bad.
> I also was able to get the libpcre in the correct place. Q: Is this the
> correct way to do this on a machine which currently has a build
> environment for sparc64?
> 
> if so...
> 2) I think I need to create the configuration file making changes to
> point to my newly created sbuild directory (primarily name of the config
> file, new directory located in my home directory, and add my user name
> to the groups and root-groups lines). Is this correct?
> 
> I REALLY don't want to mess up the buildd process we have going.
> 
> Also, I noticed on raverin that when I did an apt-get source that is
> seems to be pulling from wheezy as opposed to unstable. Does this mean
> that the sources list has been changed?
> 
> Oh and I think I'm going to work on liblo as it seems to have fewer
> problems and I need to understand more of the how, who and what of
> maintaining.
> 
> Rod
> 
> On 9/18/2015 2:57 PM, John Paul Adrian Glaubitz wrote:
>> On 09/18/2015 09:41 PM, rod wrote:
>>> 1) the installation we've done sets up a minimun "system" and things
>>> like network config, wget, and other programs need to be copied into the
>>> system to make them work?
>>
>> I think you misunderstood. The chroot is solely used for *building* a
>> package, not anything else. You usually don't need a fancy network
>> configuration or additional tools installed for that.
>>
>> The idea of the chroot for a build server or porter box is to have a
>> clean, well-defined minimum environment which is used to build packages.
>>
>> This guarantees that your package is only build against libraries and
>> other binaries installed from unmodified Debian packages and is
>> necessary to make sure your package is installable and usable on
>> any standard Debian system. If you just built a package without a clean
>> chroot, you might end up building a package which requires weird
>> dependencies which are only present on your particular system and
>> therefore make the packages unusable on other Debian installations.
>>
>> You also need a chroot in the special case when you run a 64-bit SPARC
>> kernel with a 32-bit userland such that all packages in the normal
>> system are "sparc" while you actually want to build on "sparc64"
>> packages. Then you need the chroot to have a "sparc64" build
>> environment.
>>
>> Also, once the chroot has been set up and sbuild has been configured,
>> you don't have to change anything about the chroot configuration
>> anymore. You merely need to update the chroots from time to time
>> by chrooting into them and running "apt-get update && apt-get
>> dist-upgrade".
>>
>>> 2) I downloaded the source for mozjs and attempted to build starting
>>> with a ./configure and found python was missing. Is it better to install
>>> the networking and such to do an apt-get install or should I manually
>>> install python?
>>
>> That's not how Debian packages are built. You should work on the
>> actual Debian package:
>>
>> $ apt-get source mozjs
>> $ cd mozjs-XXX
>> $ sbuild --source --arch-all --arch=sparc64  -d sid --source
>>
>> Again, read the manpage for sbuild.
>>
>> >From the top of my head, what needs to be done:
>>
>> 1) Edit js/src/configure.in, line 3025:
>>
>>sparc- => sparc*-
>>
>>This makes sure "sparc64-linux-gnu" is detected at this
>>point.
>>
>> 2) Add dh-autoreconf to Build-Depends in debian/control
>>
>> 3) Modify debian/rules to run autoreconf.
>>
>> Steps 2) and 3) are necessary to have the configure script
>> rewritten as you modified the configure.in autoconf template
>> (configure is a machine-generated script which is created
>> by autoconf by interpreting configure.in).
>>
>> See also: https://wiki.debian.org/Autoreconf
>>
>>> 3) The version of mozjs I downloaded was 31.2.0-rc0.  Should I start
>>> with the this one or should I try 1.8.5-1.0.0+dfsg-4.3?
>>
>> Take the one from Debian. Download the sources with apt-get source
>> mozjs.
>>
>> Adrian
>>
> 

Re: Resurrecting Debian on SPARC

[rod]

Good afternoon,

Having re-read all of these emails again, I have two questions (before I
go find another machine to play on so I don't mess this one (raverin) up):

1) in my efforts to setup my own chroot build environment I have created
it using the debootstrap command as discussed and created a directory in
my home directory: "sid-sparc64-sbuild-rod".  This hasn't been that bad.
I also was able to get the libpcre in the correct place. Q: Is this the
correct way to do this on a machine which currently has a build
environment for sparc64?

if so...
2) I think I need to create the configuration file making changes to
point to my newly created sbuild directory (primarily name of the config
file, new directory located in my home directory, and add my user name
to the groups and root-groups lines). Is this correct?

I REALLY don't want to mess up the buildd process we have going.

Also, I noticed on raverin that when I did an apt-get source that is
seems to be pulling from wheezy as opposed to unstable. Does this mean
that the sources list has been changed?

Oh and I think I'm going to work on liblo as it seems to have fewer
problems and I need to understand more of the how, who and what of
maintaining.

Rod

On 9/18/2015 2:57 PM, John Paul Adrian Glaubitz wrote:
> On 09/18/2015 09:41 PM, rod wrote:
>> 1) the installation we've done sets up a minimun "system" and things
>> like network config, wget, and other programs need to be copied into the
>> system to make them work?
> 
> I think you misunderstood. The chroot is solely used for *building* a
> package, not anything else. You usually don't need a fancy network
> configuration or additional tools installed for that.
> 
> The idea of the chroot for a build server or porter box is to have a
> clean, well-defined minimum environment which is used to build packages.
> 
> This guarantees that your package is only build against libraries and
> other binaries installed from unmodified Debian packages and is
> necessary to make sure your package is installable and usable on
> any standard Debian system. If you just built a package without a clean
> chroot, you might end up building a package which requires weird
> dependencies which are only present on your particular system and
> therefore make the packages unusable on other Debian installations.
> 
> You also need a chroot in the special case when you run a 64-bit SPARC
> kernel with a 32-bit userland such that all packages in the normal
> system are "sparc" while you actually want to build on "sparc64"
> packages. Then you need the chroot to have a "sparc64" build
> environment.
> 
> Also, once the chroot has been set up and sbuild has been configured,
> you don't have to change anything about the chroot configuration
> anymore. You merely need to update the chroots from time to time
> by chrooting into them and running "apt-get update && apt-get
> dist-upgrade".
> 
>> 2) I downloaded the source for mozjs and attempted to build starting
>> with a ./configure and found python was missing. Is it better to install
>> the networking and such to do an apt-get install or should I manually
>> install python?
> 
> That's not how Debian packages are built. You should work on the
> actual Debian package:
> 
> $ apt-get source mozjs
> $ cd mozjs-XXX
> $ sbuild --source --arch-all --arch=sparc64  -d sid --source
> 
> Again, read the manpage for sbuild.
> 
>>From the top of my head, what needs to be done:
> 
> 1) Edit js/src/configure.in, line 3025:
> 
>sparc- => sparc*-
> 
>This makes sure "sparc64-linux-gnu" is detected at this
>point.
> 
> 2) Add dh-autoreconf to Build-Depends in debian/control
> 
> 3) Modify debian/rules to run autoreconf.
> 
> Steps 2) and 3) are necessary to have the configure script
> rewritten as you modified the configure.in autoconf template
> (configure is a machine-generated script which is created
> by autoconf by interpreting configure.in).
> 
> See also: https://wiki.debian.org/Autoreconf
> 
>> 3) The version of mozjs I downloaded was 31.2.0-rc0.  Should I start
>> with the this one or should I try 1.8.5-1.0.0+dfsg-4.3?
> 
> Take the one from Debian. Download the sources with apt-get source
> mozjs.
> 
> Adrian
> 

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/23/2015 12:57 PM, John Paul Adrian Glaubitz wrote:
>> In general should I start tracking errors from the bottom of the build
>> log or from the first error/warning that shows up?
> 
> Depends on the errors. If you run into a simple

Oops, looks like I got distracted in the middle of the sentence.

I meant to say: If it's a simple problem, first try to fix it
yourself and if you can't fix it yourself, just ask on IRC
(#debian-sparc or #debian-mentors) for advise.

Again, it's difficult to give you a canonical answer to this
but I can just recommend to ask any time you need help. You
just shouldn't limit yourself to the debian-sparc mailing
list, especially when you have a more generic, non-SPARC
question.

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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/22/2015 06:45 PM, rod wrote:
> When building packages (in this case mozjs), where is the proper
> place/forum to post questions about the errors (assuming I've
> searched/googled/experimented/tried to trace the error(s) on my own first)?

I cannot give you a canonical answer to this. But usually, you should
get in touch with the upstream developers, both through their mailing
lists and IRC. The upstream developers of a certain Debian package
can be found under "homepage" on the PTS (package tracking system)
page of each package.

If you cannot find an upstream contact, you can still ask the Debian
maintainer of the package or maybe debian-de...@lists.debian.org.

> In general should I start tracking errors from the bottom of the build
> log or from the first error/warning that shows up?

Depends on the errors. If you run into a simple

> Oh, and in the off chance I actually manage to fix something; whom
> should I inform, the list, the bug tracking system, the maintainer, or ...?

See the list above. If you found a fix, file a bug against the Debian
source package and attach your patch. Make sure to use the "patch"
tag.

Best way to report such a bug is "reportbug " which
works fine once you have a working mail setup on the machine you
run reportbug on. reportbug allws to add patches, tags and so
on, so it's always a good idea to use it.

> -still reading and trying to figure things out in the world of debian
> maintaining-

Have you found Debian's New Maintainer Guide?

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: Resurrecting Debian on SPARC

[rod]

More a question of mechanics and proper ways of doing things...

When building packages (in this case mozjs), where is the proper
place/forum to post questions about the errors (assuming I've
searched/googled/experimented/tried to trace the error(s) on my own first)?

In general should I start tracking errors from the bottom of the build
log or from the first error/warning that shows up?

Oh, and in the off chance I actually manage to fix something; whom
should I inform, the list, the bug tracking system, the maintainer, or ...?

Rod

-still reading and trying to figure things out in the world of debian
maintaining-

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/15/2015 12:07 PM, John Paul Adrian Glaubitz wrote:
> ===
> 
> And some just segfault during build [2]:
> 
> ===
> 
> /usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
> man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
> man.authors.section.enabled 0 --stringparam
> man.copyright.section.enabled 0 --stringparam systemd.version 226 --path
> './man:../man' ../man/custom-man.xsl ../man/bootup.xml
> make[4]: *** [man/bootup.7] Segmentation fault
> Makefile:21248: recipe for target 'man/bootup.7' failed
> make[3]: *** [all-recursive] Error 1
> 
> ===

Ok, this seems to be a compiler bug which occurs when xsltproc is build
with hardening enabled. I will try to create a reduced case, then report
an upstream gcc bug.

Installing the same version of xsltproc on raverin which was built with
without hardening makes the segmentation fault go away.

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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/18/2015 09:41 PM, rod wrote:
> 1) the installation we've done sets up a minimun "system" and things
> like network config, wget, and other programs need to be copied into the
> system to make them work?

I think you misunderstood. The chroot is solely used for *building* a
package, not anything else. You usually don't need a fancy network
configuration or additional tools installed for that.

The idea of the chroot for a build server or porter box is to have a
clean, well-defined minimum environment which is used to build packages.

This guarantees that your package is only build against libraries and
other binaries installed from unmodified Debian packages and is
necessary to make sure your package is installable and usable on
any standard Debian system. If you just built a package without a clean
chroot, you might end up building a package which requires weird
dependencies which are only present on your particular system and
therefore make the packages unusable on other Debian installations.

You also need a chroot in the special case when you run a 64-bit SPARC
kernel with a 32-bit userland such that all packages in the normal
system are "sparc" while you actually want to build on "sparc64"
packages. Then you need the chroot to have a "sparc64" build
environment.

Also, once the chroot has been set up and sbuild has been configured,
you don't have to change anything about the chroot configuration
anymore. You merely need to update the chroots from time to time
by chrooting into them and running "apt-get update && apt-get
dist-upgrade".

> 2) I downloaded the source for mozjs and attempted to build starting
> with a ./configure and found python was missing. Is it better to install
> the networking and such to do an apt-get install or should I manually
> install python?

That's not how Debian packages are built. You should work on the
actual Debian package:

$ apt-get source mozjs
$ cd mozjs-XXX
$ sbuild --source --arch-all --arch=sparc64  -d sid --source

Again, read the manpage for sbuild.

>From the top of my head, what needs to be done:

1) Edit js/src/configure.in, line 3025:

   sparc- => sparc*-

   This makes sure "sparc64-linux-gnu" is detected at this
   point.

2) Add dh-autoreconf to Build-Depends in debian/control

3) Modify debian/rules to run autoreconf.

Steps 2) and 3) are necessary to have the configure script
rewritten as you modified the configure.in autoconf template
(configure is a machine-generated script which is created
by autoconf by interpreting configure.in).

See also: https://wiki.debian.org/Autoreconf

> 3) The version of mozjs I downloaded was 31.2.0-rc0.  Should I start
> with the this one or should I try 1.8.5-1.0.0+dfsg-4.3?

Take the one from Debian. Download the sources with apt-get source
mozjs.

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: Resurrecting Debian on SPARC

[rod]

Good afternoon,

I seem to have gotten the chroot to function.  Not know much about them
and searching for answers I still have the following questions (and if
you point me in the right direction I'll read, search, try, and then ask
more questions):

1) the installation we've done sets up a minimun "system" and things
like network config, wget, and other programs need to be copied into the
system to make them work?

2) I downloaded the source for mozjs and attempted to build starting
with a ./configure and found python was missing. Is it better to install
the networking and such to do an apt-get install or should I manually
install python?

3) The version of mozjs I downloaded was 31.2.0-rc0.  Should I start
with the this one or should I try 1.8.5-1.0.0+dfsg-4.3?

I appreciate the help in understanding how this should be done.  Please
let me know if I'm going about it wrong? I hope my questions don't
bother the guru's.

Reading and following maintainers guide as well.

Rod
-newbie still-

On 9/18/2015 2:22 AM, R.Schnell wrote:
> Not calling myself an idiot but...I'll go find my shoes. ;)
> 
> I have no excuse. Time to dig back into the man page(s) and see if I can 
> glean anything more. 
> Rod
> 
> Sent from my iPhone
> 
>> On Sep 18, 2015, at 01:40, John Paul Adrian Glaubitz 
>>  wrote:
>>
>> On 09/18/2015 03:42 AM, rod wrote:> So...
>>> Following the directions given (on two different machines just to make
>>> sure) I get to the point where I try to use dpkg -i to install the
>>> downloaded file and I end up with this error:
>>>
>>> I have no name!@ravirin:/# dpkg -i libpcre3_8.35-7.1+sparc64_sparc64.deb
>>> dpkg: error while loading shared libraries: libpcre.so.3: cannot open
>>> shared object file: No such file or directory
>>
>> Well, it actually tells you what's wrong. Your problem is that dpkg
>> requires libpcre3.so.3 to work which is in the package you are
>> currently trying to install.
>>
>> $ dpkg-deb -c libpcre3_8.35-7.1+sparc64_sparc64.deb |grep libpcre.so.3.13.1
>> -rw-r--r-- root/root437096 2015-08-11 04:18
>> ./lib/sparc64-linux-gnu/libpcre.so.3.13.1
>> lrwxrwxrwx root/root 0 2015-08-11 04:18
>> ./lib/sparc64-linux-gnu/libpcre.so.3 -> libpcre.so.3.13.1
>>
>> Just extract libpcre3.so.3.13.1 manually and copy it into place:
>>
>> $ dpkg -x libpcre3_8.35-7.1+sparc64_sparc64.deb ~/libpcre3
>> $ cp -av ~/libpcre3/lib/sparc64-linux-gnu/libpcre.so.3.13.1 \
>>  sid-sparc64-sbuild/lib/sparc64-linux-gnu/libpcre.so.3.13.1
>> $ ln -s  sid-sparc64-sid/lib/sparc64-linux-gnu/libpcre.so.3.13.1 \
>>  sparc64-sid-sbuild/lib/sparc64-linux-gnu/libpcre.so.3
>>
>> Then try again.
>>
>>> Q1: did I miss a step? I am logged in as myself and not as root. Does it
>>> matter?
>>
>> No, you didn't. I forgot to mention that. But the error message above
>> should have given you the proper clue.
>>
>>> Q2: should debootstrap --second-stage be run from within chroot or from
>>> outside?
>>
>> Of course *within* the chroot. The idea behind the two stages is that
>> the first stage is run on the host system while the second stage is
>> run on the target system when using --foreign to debbootstrap a foreign
>> architecture.
>>
>> Please read the manpage of debootstrap.
>>
>> 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: Resurrecting Debian on SPARC

[R.Schnell]

Not calling myself an idiot but...I'll go find my shoes. ;)

I have no excuse. Time to dig back into the man page(s) and see if I can glean 
anything more. 
Rod

Sent from my iPhone

> On Sep 18, 2015, at 01:40, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 09/18/2015 03:42 AM, rod wrote:> So...
>> Following the directions given (on two different machines just to make
>> sure) I get to the point where I try to use dpkg -i to install the
>> downloaded file and I end up with this error:
>> 
>> I have no name!@ravirin:/# dpkg -i libpcre3_8.35-7.1+sparc64_sparc64.deb
>> dpkg: error while loading shared libraries: libpcre.so.3: cannot open
>> shared object file: No such file or directory
> 
> Well, it actually tells you what's wrong. Your problem is that dpkg
> requires libpcre3.so.3 to work which is in the package you are
> currently trying to install.
> 
> $ dpkg-deb -c libpcre3_8.35-7.1+sparc64_sparc64.deb |grep libpcre.so.3.13.1
> -rw-r--r-- root/root437096 2015-08-11 04:18
> ./lib/sparc64-linux-gnu/libpcre.so.3.13.1
> lrwxrwxrwx root/root 0 2015-08-11 04:18
> ./lib/sparc64-linux-gnu/libpcre.so.3 -> libpcre.so.3.13.1
> 
> Just extract libpcre3.so.3.13.1 manually and copy it into place:
> 
> $ dpkg -x libpcre3_8.35-7.1+sparc64_sparc64.deb ~/libpcre3
> $ cp -av ~/libpcre3/lib/sparc64-linux-gnu/libpcre.so.3.13.1 \
>  sid-sparc64-sbuild/lib/sparc64-linux-gnu/libpcre.so.3.13.1
> $ ln -s  sid-sparc64-sid/lib/sparc64-linux-gnu/libpcre.so.3.13.1 \
>  sparc64-sid-sbuild/lib/sparc64-linux-gnu/libpcre.so.3
> 
> Then try again.
> 
>> Q1: did I miss a step? I am logged in as myself and not as root. Does it
>> matter?
> 
> No, you didn't. I forgot to mention that. But the error message above
> should have given you the proper clue.
> 
>> Q2: should debootstrap --second-stage be run from within chroot or from
>> outside?
> 
> Of course *within* the chroot. The idea behind the two stages is that
> the first stage is run on the host system while the second stage is
> run on the target system when using --foreign to debbootstrap a foreign
> architecture.
> 
> Please read the manpage of debootstrap.
> 
> 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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/18/2015 04:19 AM, Bob Bib wrote:
> sparc arch removal also affected some SPARC-specific packages[1] (e. g.,
> "SILO" bootloader).

Yes, I am fully aware of that. We have the same problem on all other
ports like hppa which require a bootloader which cannot be uploaded
to unstable when it's only available on a ports architecture.

SILO was removed because packages which do not build any binary packages
in unstable are automatically removed from unstable within a few hours.

I discussed this issue with Aurelien at DebConf 15.

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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/18/2015 03:42 AM, rod wrote:> So...
> Following the directions given (on two different machines just to make
> sure) I get to the point where I try to use dpkg -i to install the
> downloaded file and I end up with this error:
> 
> I have no name!@ravirin:/# dpkg -i libpcre3_8.35-7.1+sparc64_sparc64.deb
> dpkg: error while loading shared libraries: libpcre.so.3: cannot open
> shared object file: No such file or directory

Well, it actually tells you what's wrong. Your problem is that dpkg
requires libpcre3.so.3 to work which is in the package you are
currently trying to install.

$ dpkg-deb -c libpcre3_8.35-7.1+sparc64_sparc64.deb |grep libpcre.so.3.13.1
-rw-r--r-- root/root437096 2015-08-11 04:18
./lib/sparc64-linux-gnu/libpcre.so.3.13.1
lrwxrwxrwx root/root 0 2015-08-11 04:18
./lib/sparc64-linux-gnu/libpcre.so.3 -> libpcre.so.3.13.1

Just extract libpcre3.so.3.13.1 manually and copy it into place:

$ dpkg -x libpcre3_8.35-7.1+sparc64_sparc64.deb ~/libpcre3
$ cp -av ~/libpcre3/lib/sparc64-linux-gnu/libpcre.so.3.13.1 \
  sid-sparc64-sbuild/lib/sparc64-linux-gnu/libpcre.so.3.13.1
$ ln -s  sid-sparc64-sid/lib/sparc64-linux-gnu/libpcre.so.3.13.1 \
  sparc64-sid-sbuild/lib/sparc64-linux-gnu/libpcre.so.3

Then try again.

> Q1: did I miss a step? I am logged in as myself and not as root. Does it
> matter?

No, you didn't. I forgot to mention that. But the error message above
should have given you the proper clue.

> Q2: should debootstrap --second-stage be run from within chroot or from
> outside?

Of course *within* the chroot. The idea behind the two stages is that
the first stage is run on the host system while the second stage is
run on the target system when using --foreign to debbootstrap a foreign
architecture.

Please read the manpage of debootstrap.

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: Resurrecting Debian on SPARC

[Bob Bib]

Just a note:
sparc arch removal also affected some SPARC-specific packages[1] (e. g., 
"SILO" bootloader).


According to Aurelien Jarno,[2] they should be re-uploaded to "unreleased".

[1] http://lists.debian.org/debian-sparc/2015/07/msg00037.html
[2] http://lists.debian.org/debian-sparc/2015/08/msg00018.html

--
Best wishes,
Bob

Re: Resurrecting Debian on SPARC

[rod]

So...
Following the directions given (on two different machines just to make
sure) I get to the point where I try to use dpkg -i to install the
downloaded file and I end up with this error:

I have no name!@ravirin:/# dpkg -i libpcre3_8.35-7.1+sparc64_sparc64.deb
dpkg: error while loading shared libraries: libpcre.so.3: cannot open
shared object file: No such file or directory

Q1: did I miss a step? I am logged in as myself and not as root. Does it
matter?

Q2: should debootstrap --second-stage be run from within chroot or from
outside?

Rod

(apologies to Adrian whom I keep pestering... )

On 9/17/2015 2:13 PM, John Paul Adrian Glaubitz wrote:
> On 09/17/2015 05:26 PM, rod wrote:
>> In my efforts to help this along I am trying to set up a chroot
>> environment for testing.  I have tried multistrap and sbuild setup from
>> the debian wiki and from various places found whilst googling.  To date
>> I've not had any success.
> 
> There is no real trick behind it, you just use debbootstrap. If you want
> to create the chroot in the directory "sid-sparc-sbuild", you run:
> 
> $ debootstrap --no-check-gpg --arch=sparc64 --variant=buildd unstable \
>   sid-sparc64-sbuild ftp://ftp.debian-ports.org/debian
> 
> However, this will currently fail for sparc64 as the libpcre3 package is
> not installable from *unstable* as I had to built it manually with tests
> disabled and therefore had to upload it to the *unreleased*
> distribution.
> 
> As a workaround, you need to run debbootstrap with "--foreign" which
> will just download the packages, unpack them but not configure them:
> 
> $ debootstrap --no-check-gpg --foreign --arch=sparc64 --variant=buildd \
>   unstable sid-sparc64-sbuild ftp://ftp.debian-ports.org/debian
> 
> Once this has finished, you change into the directory you just created:
> 
> $ cd sid-sparc64-sbuild
> 
> Then wget the libpcre3 package;
> 
> $ wget
> ftp://ftp.debian-ports.org/debian/pool-sparc64/main/p/pcre3/libpcre3_8.35-7.1+sparc64_sparc64.deb
> 
> Then chroot into the newly created build root:
> 
> $ chroot .
> 
> Install the libpcre3 package manually:
> 
> $ dpkg -i ibpcre3_8.35-7.1+sparc64_sparc64.deb
> 
> And finally run the second stage of debbootstrap:
> 
> $ debbootstrap/debboostrap --second-stage
> 
> After that, you need to add entries to the etc/apt/sources.list (best
> done from outside the chroot):
> 
> deb http://ftp.debian-ports.org/debian/ unstable main
> deb http://ftp.debian-ports.org/debian unreleased main
> deb http://incoming.debian-ports.org/buildd unstable main
> deb-src http://ftp.debian.org/debian/ unstable main
> deb-src http://incoming.debian.org/debian-buildd buildd-unstable main
> 
> And add the Debian Ports GPG key (this has to be done inside the
> chroot):
> 
> $ gpg --keyserver pgp.mit.edu --recv-keys A53AB45AC448326E && gpg
> --export --armor A53AB45AC448326E |apt-key add -
> 
> Then the chroot is basically set up. But you need to add a configuration
> for sbuild, namely:
> 
> root@ravirin:~# cat /etc/schroot/chroot.d/sid-sparc64-sbuild
> [sid-sparc64-sbuild]
> description=Debian sid chroot for sparc64
> type=directory
> directory=/var/sid-sparc64-sbuild
> #groups=Debian,guest,d-i
> #profile=dsa
> #aliases=sid
> groups=root,sbuild,glaubitz,buildd
> root-groups=root,sbuild,glaubitz,buildd
> command-prefix=eatmydata
> #source-root-users=glaubitz,sbuild,buildd
> #run-setup-scripts=true
> #run-exec-scripts=true
> root@ravirin:~#
> 
> That should be all. On a new machine, you also need to run
> "sbuild-update --keygen" after creating .gnupg in the home
> directory of the root user (mkdir /root/.gnupg).
> 
> Cheers,
> Adrian
> 

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/17/2015 05:26 PM, rod wrote:
> In my efforts to help this along I am trying to set up a chroot
> environment for testing.  I have tried multistrap and sbuild setup from
> the debian wiki and from various places found whilst googling.  To date
> I've not had any success.

There is no real trick behind it, you just use debbootstrap. If you want
to create the chroot in the directory "sid-sparc-sbuild", you run:

$ debootstrap --no-check-gpg --arch=sparc64 --variant=buildd unstable \
  sid-sparc64-sbuild ftp://ftp.debian-ports.org/debian

However, this will currently fail for sparc64 as the libpcre3 package is
not installable from *unstable* as I had to built it manually with tests
disabled and therefore had to upload it to the *unreleased*
distribution.

As a workaround, you need to run debbootstrap with "--foreign" which
will just download the packages, unpack them but not configure them:

$ debootstrap --no-check-gpg --foreign --arch=sparc64 --variant=buildd \
  unstable sid-sparc64-sbuild ftp://ftp.debian-ports.org/debian

Once this has finished, you change into the directory you just created:

$ cd sid-sparc64-sbuild

Then wget the libpcre3 package;

$ wget
ftp://ftp.debian-ports.org/debian/pool-sparc64/main/p/pcre3/libpcre3_8.35-7.1+sparc64_sparc64.deb

Then chroot into the newly created build root:

$ chroot .

Install the libpcre3 package manually:

$ dpkg -i ibpcre3_8.35-7.1+sparc64_sparc64.deb

And finally run the second stage of debbootstrap:

$ debbootstrap/debboostrap --second-stage

After that, you need to add entries to the etc/apt/sources.list (best
done from outside the chroot):

deb http://ftp.debian-ports.org/debian/ unstable main
deb http://ftp.debian-ports.org/debian unreleased main
deb http://incoming.debian-ports.org/buildd unstable main
deb-src http://ftp.debian.org/debian/ unstable main
deb-src http://incoming.debian.org/debian-buildd buildd-unstable main

And add the Debian Ports GPG key (this has to be done inside the
chroot):

$ gpg --keyserver pgp.mit.edu --recv-keys A53AB45AC448326E && gpg
--export --armor A53AB45AC448326E |apt-key add -

Then the chroot is basically set up. But you need to add a configuration
for sbuild, namely:

root@ravirin:~# cat /etc/schroot/chroot.d/sid-sparc64-sbuild
[sid-sparc64-sbuild]
description=Debian sid chroot for sparc64
type=directory
directory=/var/sid-sparc64-sbuild
#groups=Debian,guest,d-i
#profile=dsa
#aliases=sid
groups=root,sbuild,glaubitz,buildd
root-groups=root,sbuild,glaubitz,buildd
command-prefix=eatmydata
#source-root-users=glaubitz,sbuild,buildd
#run-setup-scripts=true
#run-exec-scripts=true
root@ravirin:~#

That should be all. On a new machine, you also need to run
"sbuild-update --keygen" after creating .gnupg in the home
directory of the root user (mkdir /root/.gnupg).

Cheers,
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: Resurrecting Debian on SPARC

[Hartwig Atrops]

On Tuesday 15 September 2015 12:07:10 John Paul Adrian Glaubitz wrote:
> Hi!
>
> I was wondering how many here are still interested in the Debian
> SPARC port?

count ++

Hartwig

Re: Resurrecting Debian on SPARC

[rod]

Good morning,

In my efforts to help this along I am trying to set up a chroot
environment for testing.  I have tried multistrap and sbuild setup from
the debian wiki and from various places found whilst googling.  To date
I've not had any success.

Is there a HOW-TO somewhere for setting up a chroot environment for the
purpose of testing/porting portions of sid?

Am I even asking the right question(s)?

Rod

On 9/15/2015 5:07 AM, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I was wondering how many here are still interested in the Debian
> SPARC port?
> 
> In the past weeks, I have invested some efforts to revive the sparc64
> port a bit and managed to get at least gcc-5 compile and work through
> the build queue a bit. Rod Schnell, a user from the US, kindly donated
> an UltraSPARC IIIi for use which I set up as an additional buildd and
> porterbox (Hostname: raverin).
> 
> Currently, there are some packages left like mozjs that need manual
> porting before they will compile on sparc64. Furthermore, there are
> a number of packages which fail with weird linker errors [1]:
> 
> ===
> 
> gcc -DHAVE_CONFIG_H -I. -I../../../usbhid-dump/src -I..
> -I/«PKGBUILDDIR»/usbhid-dump/include
> -I/«PKGBUILDDIR»/build-deb/usbhid-dump
> -I/«PKGBUILDDIR»/build-deb/usbhid-dump/include -DNDEBUG
> -D_FORTIFY_SOURCE=2  -Os -Wall -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/include/libusb-1.0  -c -o usbhid-dump.o
> ../../../usbhid-dump/src/usbhid-dump.c
> /bin/bash ../libtool  --tag=CC   --mode=link gcc  -Os -Wall -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security
> -I/usr/include/libusb-1.0   -Wl,-z,relro -o usbhid-dump usbhid-dump.o
> ../lib/libuhd.la -lusb-1.0
> libtool: link: gcc -Os -Wall -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/include/libusb-1.0 -Wl,-z -Wl,relro -o
> usbhid-dump usbhid-dump.o  ../lib/.libs/libuhd.a -lusb-1.0
> /usr/bin/ld: //lib/sparc64-linux-gnu/libudev.so.1: Only registers
> %g[2367] can be declared using STT_REGISTER
> //lib/sparc64-linux-gnu/libudev.so.1: error adding symbols: No such file
> or directory
> collect2: error: ld returned 1 exit status
> make[6]: *** [usbhid-dump] Error 1
> 
> ===
> 
> And some just segfault during build [2]:
> 
> ===
> 
> /usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
> man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
> man.authors.section.enabled 0 --stringparam
> man.copyright.section.enabled 0 --stringparam systemd.version 226 --path
> './man:../man' ../man/custom-man.xsl ../man/bootup.xml
> make[4]: *** [man/bootup.7] Segmentation fault
> Makefile:21248: recipe for target 'man/bootup.7' failed
> make[3]: *** [all-recursive] Error 1
> 
> ===
> 
> Anyone here willing to join the efforts to fix the sparc64 port or
> even resurrect the 32-bit SPARC port which was recently removed from
> Debian?
> 
> I think it might be actually a good idea to resurrect the 32-bit
> port and add it to Debian ports since sparc32 seems to be a in
> a better shape regarding kernel and toolchain support.
> 
> Cheers,
> Adrian
> 
>> [1]
> https://buildd.debian.org/status/fetch.php?pkg=usbutils&arch=sparc64&ver=1%3A007-4&stamp=1441551102
>> [2]
> https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=sparc64&ver=226-1&stamp=1442141223
> 

Re: Resurrecting Debian on SPARC

[Patrick Baggett]

On Tue, Sep 15, 2015 at 9:32 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 09/15/2015 04:10 PM, waz0wski wrote:
> > I would love to see Debian-on-SPARC continue on, even if not fully
> > supported, similar to how the FreeBSD project handles sparc64[1]
>
> Ok, the question is: Do we want sparc32 as well or just sparc64? As
> I mentioned already, sparc32 (32-bit userland and 64-bit kernel -
> where supported) most likely needs less porting and should be
> easier to be kept up-to-date than sparc64.
>

My two cents: if you have limited efforts, then 64-bit sparc only is the
most future proof. Ideally though, you would not use 64-bit binaries unless
it made sense, because 64-bit binaries on sparc are usually slower. There
is no magic "64-bit is faster" on sparc like there is on x86. 32-bit
binaries are not the same as supporting ancient SPARC CPUs which are 32-bit
only. All binaries should be built for SPARCv9 ISA, which is the ISA that
supports 64-bit processing. 32-bit sparc binaries using v9 ISA is more
similar to the new(ish) "x32" ISA for x86 CPUs, where pointers are mapped
<= 4GB, but registers are still 64-bits wide.


>
> However, both 32-bit and 64-bit SPARC packages can be built on
> 64-bit machines using different build chroots.
>
> > I have access to a couple of UltraSPARC T2 systems (T5220/T5440) which
> > could be made available for development and testing purposes -- ping me
> > off-list for more info.
>
> I will come back to that.
>
> 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: Resurrecting Debian on SPARC

[rod]

I like the idea of maintaining sparc32. It seems as if we have the
machines. I guess it's getting the talent to do the programming. Being a
noob when it comes to maintaining I'm open for learning and direction.
I will continue to pursue, ask questions, and such for my own knowledge
and to help the effort.

Rod

On 9/15/2015 9:32 AM, John Paul Adrian Glaubitz wrote:
> On 09/15/2015 04:10 PM, waz0wski wrote:
>> I would love to see Debian-on-SPARC continue on, even if not fully
>> supported, similar to how the FreeBSD project handles sparc64[1]
> 
> Ok, the question is: Do we want sparc32 as well or just sparc64? As
> I mentioned already, sparc32 (32-bit userland and 64-bit kernel -
> where supported) most likely needs less porting and should be
> easier to be kept up-to-date than sparc64.
> 
> However, both 32-bit and 64-bit SPARC packages can be built on
> 64-bit machines using different build chroots.
> 
>> I have access to a couple of UltraSPARC T2 systems (T5220/T5440) which
>> could be made available for development and testing purposes -- ping me
>> off-list for more info.
> 
> I will come back to that.
> 
> Adrian
> 

Re: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

On 09/15/2015 04:10 PM, waz0wski wrote:
> I would love to see Debian-on-SPARC continue on, even if not fully
> supported, similar to how the FreeBSD project handles sparc64[1]

Ok, the question is: Do we want sparc32 as well or just sparc64? As
I mentioned already, sparc32 (32-bit userland and 64-bit kernel -
where supported) most likely needs less porting and should be
easier to be kept up-to-date than sparc64.

However, both 32-bit and 64-bit SPARC packages can be built on
64-bit machines using different build chroots.

> I have access to a couple of UltraSPARC T2 systems (T5220/T5440) which
> could be made available for development and testing purposes -- ping me
> off-list for more info.

I will come back to that.

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: Resurrecting Debian on SPARC

[waz0wski]

I would love to see Debian-on-SPARC continue on, even if not fully supported, 
similar to how the FreeBSD project handles sparc64[1]

I have access to a couple of UltraSPARC T2 systems (T5220/T5440) which could be 
made available for development and testing purposes -- ping me off-list for 
more info.

[1] https://www.freebsd.org/platforms/sparc.html


> On Sep 15, 2015, at 7:08 AM, david h.  wrote:
> 
> Hello,
> 
> I would love to resurrect debian sparc 64, I can provide 2 t2000 Sun fires, 
> and one v880, which are not on line at the moment, but I will use them for 
> testing. 
> Also is there someone who made a CD image for a newer debian version to put 
> on my Sun, so I don't have to build my own?
> 
> Greetings
> 
> David
> 
> Am 15.09.2015 14:01 schrieb "John Paul Adrian Glaubitz" 
> mailto:glaub...@physik.fu-berlin.de>>:
> Hi Frans!
> 
> On 09/15/2015 12:51 PM, Frans van Berckel wrote:
> > Seen the Gold linker bug on sparc64? Do you think it's related?
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790560 
> > 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=18855 
> > 
> 
> Indeed, that looks like it. Thanks for the heads-up!
> 
> I have already replied to the upstream bug report and will
> provide assistance to help fixing the bug. I will also get
> into contact with Matthias Klose (doko) and see what he
> has to say.
> 
> 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: Resurrecting Debian on SPARC

[david h.]

Hello,

I would love to resurrect debian sparc 64, I can provide 2 t2000 Sun fires,
and one v880, which are not on line at the moment, but I will use them for
testing.
Also is there someone who made a CD image for a newer debian version to put
on my Sun, so I don't have to build my own?

Greetings

David
Am 15.09.2015 14:01 schrieb "John Paul Adrian Glaubitz" <
glaub...@physik.fu-berlin.de>:

> Hi Frans!
>
> On 09/15/2015 12:51 PM, Frans van Berckel wrote:
> > Seen the Gold linker bug on sparc64? Do you think it's related?
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790560
> > https://sourceware.org/bugzilla/show_bug.cgi?id=18855
>
> Indeed, that looks like it. Thanks for the heads-up!
>
> I have already replied to the upstream bug report and will
> provide assistance to help fixing the bug. I will also get
> into contact with Matthias Klose (doko) and see what he
> has to say.
>
> 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: Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

Hi Frans!

On 09/15/2015 12:51 PM, Frans van Berckel wrote:
> Seen the Gold linker bug on sparc64? Do you think it's related?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790560
> https://sourceware.org/bugzilla/show_bug.cgi?id=18855

Indeed, that looks like it. Thanks for the heads-up!

I have already replied to the upstream bug report and will
provide assistance to help fixing the bug. I will also get
into contact with Matthias Klose (doko) and see what he
has to say.

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: Resurrecting Debian on SPARC

[Frans van Berckel]

Hi Adrian,

On Tue, 2015-09-15 at 12:07 +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I was wondering how many here are still interested in the Debian
> SPARC port?
> 
> In the past weeks, I have invested some efforts to revive the sparc64
> port a bit and managed to get at least gcc-5 compile and work through
> the build queue a bit. Rod Schnell, a user from the US, kindly 
> donated an UltraSPARC IIIi for use which I set up as an additional 
> buildd and porterbox (Hostname: raverin).
> 
> Currently, there are some packages left like mozjs that need manual
> porting before they will compile on sparc64. Furthermore, there are
> a number of packages which fail with weird linker errors [1]:

Seen the Gold linker bug on sparc64? Do you think it's related?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790560
https://sourceware.org/bugzilla/show_bug.cgi?id=18855

Thanks,


Frans van Berckel

Re: Resurrecting Debian on SPARC

[Hermann Lauer]

Hello,

On Tue, Sep 15, 2015 at 12:07:10PM +0200, John Paul Adrian Glaubitz wrote:
> I was wondering how many here are still interested in the Debian
> SPARC port?

Interest is there, but unfortunately nearly no time during the next 6 Months.

> In the past weeks, I have invested some efforts to revive the sparc64
> port a bit and managed to get at least gcc-5 compile and work through
> the build queue a bit. Rod Schnell, a user from the US, kindly donated
> an UltraSPARC IIIi for use which I set up as an additional buildd and
> porterbox (Hostname: raverin).

That I can offer too for at least a limited time: We have also some
US III sparc boxes sitting around here. Last problem with vanilla
kernel on one of the boxes was a scsi host problem, on with DaveM referred
to the host drivers maintainer, at which point I gave up. 

> Anyone here willing to join the efforts to fix the sparc64 port or
> even resurrect the 32-bit SPARC port which was recently removed from
> Debian?

What's in Debian wheezy is the 32-bit SPARC with 64-bit Kernel, right ?

> I think it might be actually a good idea to resurrect the 32-bit
> port and add it to Debian ports since sparc32 seems to be a in
> a better shape regarding kernel and toolchain support.

My time will allow only a litte bit of testing (e.g. including sources
list and try some packages).

Good luck,
 greetings
   Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: hermann.la...@iwr.uni-heidelberg.de

Resurrecting Debian on SPARC

[John Paul Adrian Glaubitz]

Hi!

I was wondering how many here are still interested in the Debian
SPARC port?

In the past weeks, I have invested some efforts to revive the sparc64
port a bit and managed to get at least gcc-5 compile and work through
the build queue a bit. Rod Schnell, a user from the US, kindly donated
an UltraSPARC IIIi for use which I set up as an additional buildd and
porterbox (Hostname: raverin).

Currently, there are some packages left like mozjs that need manual
porting before they will compile on sparc64. Furthermore, there are
a number of packages which fail with weird linker errors [1]:

===

gcc -DHAVE_CONFIG_H -I. -I../../../usbhid-dump/src -I..
-I/«PKGBUILDDIR»/usbhid-dump/include
-I/«PKGBUILDDIR»/build-deb/usbhid-dump
-I/«PKGBUILDDIR»/build-deb/usbhid-dump/include -DNDEBUG
-D_FORTIFY_SOURCE=2  -Os -Wall -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -I/usr/include/libusb-1.0  -c -o usbhid-dump.o
../../../usbhid-dump/src/usbhid-dump.c
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -Os -Wall -g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-I/usr/include/libusb-1.0   -Wl,-z,relro -o usbhid-dump usbhid-dump.o
../lib/libuhd.la -lusb-1.0
libtool: link: gcc -Os -Wall -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -I/usr/include/libusb-1.0 -Wl,-z -Wl,relro -o
usbhid-dump usbhid-dump.o  ../lib/.libs/libuhd.a -lusb-1.0
/usr/bin/ld: //lib/sparc64-linux-gnu/libudev.so.1: Only registers
%g[2367] can be declared using STT_REGISTER
//lib/sparc64-linux-gnu/libudev.so.1: error adding symbols: No such file
or directory
collect2: error: ld returned 1 exit status
make[6]: *** [usbhid-dump] Error 1

===

And some just segfault during build [2]:

===

/usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
man.authors.section.enabled 0 --stringparam
man.copyright.section.enabled 0 --stringparam systemd.version 226 --path
'./man:../man' ../man/custom-man.xsl ../man/bootup.xml
make[4]: *** [man/bootup.7] Segmentation fault
Makefile:21248: recipe for target 'man/bootup.7' failed
make[3]: *** [all-recursive] Error 1

===

Anyone here willing to join the efforts to fix the sparc64 port or
even resurrect the 32-bit SPARC port which was recently removed from
Debian?

I think it might be actually a good idea to resurrect the 32-bit
port and add it to Debian ports since sparc32 seems to be a in
a better shape regarding kernel and toolchain support.

Cheers,
Adrian

> [1]
https://buildd.debian.org/status/fetch.php?pkg=usbutils&arch=sparc64&ver=1%3A007-4&stamp=1441551102
> [2]
https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=sparc64&ver=226-1&stamp=1442141223

-- 
 .''`.  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