Re: Bug#730258: please add arch-specific BTS tags

[John Paul Adrian Glaubitz]

On 11/23/2013 11:51 PM, Helge Deller wrote:
 What else am I missing?
 
 Please add hppa

Assuming that you are one of the hppa guys, how is the port doing? Any
chance that the buildds will be up and running again anytime soon?

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


-- 
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/52913875.3080...@physik.fu-berlin.de

Re: Bug#730258: please add arch-specific BTS tags

[John Paul Adrian Glaubitz]

On 11/24/2013 12:22 AM, Helge Deller wrote:
 On 11/24/2013 12:21 AM, John Paul Adrian Glaubitz wrote:
 On 11/23/2013 11:51 PM, Helge Deller wrote:
 Please add hppa

 Assuming that you are one of the hppa guys, how is the port doing? Any
 chance that the buildds will be up and running again anytime soon?
 
 Yes, think so.
 I'm working on that just right now...

Very cool! Hope you guys will soon be where we already are with the
m68k port :).

Crossing my fingers! It's been sad to see the number of up-to-date
packages in hppa dropping over the time.

Keep us updated!

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


-- 
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/52913bad.9000...@physik.fu-berlin.de

Re: Bug#730258: please add arch-specific BTS tags

[John Paul Adrian Glaubitz]

On 11/24/2013 12:47 AM, John David Anglin wrote:
 On 23-Nov-13, at 6:35 PM, John Paul Adrian Glaubitz wrote:
 
 Crossing my fingers! It's been sad to see the number of up-to-date
 packages in hppa dropping over the time.
 
 It should be going up now.

So, the buildds are already up and running? Shouldn't they be showing
up on buildd.debian-ports.org [1]?

Adrian

 [1]
http://buildd.debian-ports.org/status/architecture.php?a=hppasuite=sid

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


-- 
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/52913f09.6080...@physik.fu-berlin.de

Re: Bug#730258: please add arch-specific BTS tags

[John Paul Adrian Glaubitz]

On 11/24/2013 01:20 AM, Thorsten Glaser wrote:
 John Paul Adrian Glaubitz dixit:
 So, the buildds are already up and running? Shouldn't they be showing
 up on buildd.debian-ports.org [1]?
 
 I think I saw buildd uploads for hppa on incoming.d.o this week.

Indeed:

 http://incoming.debian-ports.org/buildd/packages/unstable/main/

Very cool!

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


-- 
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/529148de.8070...@physik.fu-berlin.de

Re: How to get a new palo source package into unstable?

[John Paul Adrian Glaubitz]

Hello Helge!

On Sat, Jan 11, 2014 at 10:37:52PM +0100, Helge Deller wrote:
 as you might have noticed, we did huge progress on the HPPA (PA-RISC) port:
 http://buildd.debian-ports.org/stats/

Indeed. Congratulations on that! I'm glad to see the HPPA port coming
back to life. I'd love to test it myself, but the only PA-RISC machine
that I currently know of which is in my vicinity is located inside a
laboratory at my physics department and it's still running HP-UX.
Might be that it gets scrapped soon and replaced with something more
fancy so that I can get hold of it, who knows ;).

 In order to be able to boot parisc machines, the hppa port needs the palo 
 debian package.
 PALO is the PA-RISC boot loader and a boot-loader-image generator, 
 similar to 
 lilo on i386 or silo on sparc.

Or aboot on the Alpha machines.

 I've continued to maintain and further develop palo.
 The new palo git repository is now at:
 git://git.kernel.org/pub/scm/linux/kernel/git/deller/palo.git
 and the source should compile and run on all plattforms.
 A simple checkout and dpkg-buildpackage should work.

Thank you very much for doing this (and the hard work of bringing the
buildds back to life). Even though I currently don't own a PA-RISC
machine, I'm very glad that someone took care of it, such that owners
of these machines can still use it with a current Debian release.

 Since I'm not a debian-developer, I don't know how to get this package into 
 debian unstable again.
 What is the usual process to get a new/old package back into debian unstable? 
 Maybe someone of you who has a debian developer rights is willing to upload 
 the 
 source package?

I'm a Debian Developer with full upload permissions to the archive and
would absolutely love to help you get the boot loader (and any other
possibly necessary packages) back into Debian.

The best is to have the package(s) uploaded to Debian Mentors [1] so I
can grab them from there and review them, send you suggestions on
improving them and finally upload them.

Plus, it would be nice to have access to a PA-RISC machine myself so I
can perform a test build and inspect the finished package. Would that
be possible?

PS: I have noticed that the HPPA builds never include the build log,
for example radeontop [2]. Would it be possible to have these
enabled as well, so we can easily find out what went wrong when a
build failed?

Cheers,

Adrian

 [1] http://mentors.debian.net/
 [2] http://buildd.debian-ports.org/status/package.php?p=radeontopsuite=sid

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


-- 
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/20140112163248.ga10...@physik.fu-berlin.de

Re: How to get a new palo source package into unstable?

[John Paul Adrian Glaubitz]

Hi Helge!

On 01/12/2014 10:36 PM, Helge Deller wrote:
 Indeed. Congratulations on that! I'm glad to see the HPPA port coming
 back to life. I'd love to test it myself, but the only PA-RISC machine
 that I currently know of which is in my vicinity is located inside a
 laboratory at my physics department and it's still running HP-UX.
 Might be that it gets scrapped soon and replaced with something more
 fancy so that I can get hold of it, who knows ;).
 
 Good thing is, that those machines got pretty cheap now.
 A Dualcore-C8000 workstation is available on ebay for  100 EUR.

If just had enough room. There are already too many Amigas taking
up my space :). Still, I like to support the port as much as I
can.

 I'm a Debian Developer with full upload permissions to the archive and
 would absolutely love to help you get the boot loader (and any other
 possibly necessary packages) back into Debian.
 
 Thanks!
 AFAIK the bootloader is the only package which is parisc specific.

Ok, good to know.

 The best is to have the package(s) uploaded to Debian Mentors [1] so I
 can grab them from there and review them, send you suggestions on
 improving them and finally upload them.
 
 I uploaded it, and CC'ed you on the request.
 http://mentors.debian.net/package/palo
 The info at top of the website is the latest package with most warnings fixed.
 It would be nice if you could help me (off-list) further on that.

Will do! I'll answer your separate mail later!

 Plus, it would be nice to have access to a PA-RISC machine myself so I
 can perform a test build and inspect the finished package. Would that
 be possible?
 
 Sure, I'll send you login details off-list.
 If other people here on the list want access, please let me know.

Thanks, got them. Will change the password and install my SSH key ASAP.

 We had problems with sending mails from the buildds when I started the 
 buildds mid december.
 Currently we have 5 buildds running:
 http://unstable.buildd.net/index-hppa.html
 Since around 2-3 weeks, all buildds except mx3210 do send build logs.

Ah, glad to hear it has been fixed. Then there's nothing I am worrying
about. Are you working together with Ingo Juergensmann to update the
buildd status information on buildd.net?

 I can reschedule a rebuild of radeontop for you, or you can just build it
 yourself on the machine for which I send you a login. Just let me know.

Don't worry about radeontop. I just picked that package as an example to
check whether the build logs are still missing or not. This is one of
my own packages and the last upload was just done a few weeks ago, so
I thought I might check this one to see whether the problem has already
been addressed.

But when you say the logs are properly uploaded now, I'm happy. So,
please don't reschedule the package, it will updated in the very
near future anyway.

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


-- 
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/52d33683.2020...@physik.fu-berlin.de

Re: How to get a new palo source package into unstable?

[John Paul Adrian Glaubitz]

Hi Helge!

On 01/11/2014 10:37 PM, Helge Deller wrote:
 Since I'm not a debian-developer, I don't know how to get this package into 
 debian unstable again.
 What is the usual process to get a new/old package back into debian unstable? 
 Maybe someone of you who has a debian developer rights is willing to upload 
 the 
 source package?

I'm mostly finished with palo now. I converted the package to the
latest debhelper format, reformatted the copyright file to the new
1.0 format (still need to some missing copyright holders and
verify the license is correct for all source files). I also
added a README.source to explain what happened with palo after
version 1.16.

The remaining things are cleaning up the changelog, removing
other cruft and updating files like README.Debian.

Hope to get it finished by the weekend. I will send you the
patches, have you ACK them and upload on Saturday or Sunday.

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


-- 
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/530f4e65.7080...@physik.fu-berlin.de

Re: Roll call for porters of architectures in sid and testing

[John Paul Adrian Glaubitz]

Hello!

On 09/25/2013 05:09 AM, Nobuhiro Iwamatsu wrote:
 I am an active porter for the following architectures and I intend
 to continue this for the lifetime of the jessie release:
 
 For sh4, I
 - test packages on this architecture
 - triage arch-specific bugs
 - fix arch-related bugs
 - maintain buildds

I have joined Nobuhiro to help supporting the sh4 port. I am currently
working on to reactive the build queue again. Needs-Build on sh4 is
currently over 4000 and I need to build a couple of essential packages
like gcc-4.9, gcc-4.8 and python2.7 manually to be able to resolve
the dependency problems.

gcc-4.9 has been building since Wednesday but it's looking good. I hope
to have the packages uploaded over the weekend.

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


-- 
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/53e618fc.9070...@physik.fu-berlin.de

sh4 missing on packages.debian.org

[John Paul Adrian Glaubitz]

Hi Aurelien!

I just noticed that there seems to be something wrong with
packages.debian.org regarding sh4. Many packages are not
listed there as available even though they are built and
installed.

For example, src:glibc, has been fully built on sh4, yet:

 https://packages.debian.org/sid/libc6

It's not there. It's also not installable anymore:

yamato:~# apt-cache policy libc6
libc6:
  Installed: 2.19-9
  Candidate: 2.19-9
  Version table:
 *** 2.19-9 0
100 /var/lib/dpkg/status
yamato:~#

yamato:~# cat /etc/apt/sources.list
deb http://ftp.debian-ports.org/debian/ unstable main
deb http://ftp.debian-ports.org/debian/ unreleased main
yamato:~#

Do you know what could be wrong?

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


-- 
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/5409ed32.7080...@physik.fu-berlin.de

Re: Bug#399608: fixed in sysvinit 2.88dsf-59.1

[John Paul Adrian Glaubitz]

Hi there!

This upload most likely broke the build queue on several ports
architectures because sysvinit-tools depend on a specific version
of util-linux which wasn't build on the affected architectures
yet [1].

I fixed sh4 and m68k manually, but sparc64 and powerpcspe are still
stuck because they can't build the current version of util-linux. The
problem is currently overshadowed on sparc64 by other BD-Uninstallable
packages but it exists there as well most likely.

To fix the issue, I had to build util-linux manually, wanna-build was
unable to resolve the dependencies. Maybe the dependency on
src:util-linux is incorrect and it should be just util-linux as
src:util-linux apparently always depends on the most current version
in the main archive instead of just any usable version in the
archives? I don't know.

In any case, I would love to fix the powerpcspe and sparc64 ports but
I haven't got an account on any machine with these architectures yet
so I can't help at the moment. I have asked for a sparc64 account but
with no positive result so far.

Anyway, just wanted to raise some awareness that this change broke
the build queue on the ports and it might break again once util-linux
is updated in the main archive again.

Cheers,
Adrian

 [1]
http://buildd.debian-ports.org/status/package.php?p=util-linuxsuite=sid

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


-- 
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/55588921.7070...@physik.fu-berlin.de

Re: binNMUs of rtmpdump on sparc64 and sh4

[John Paul Adrian Glaubitz]

On 06/19/2015 09:09 PM, Andreas Cadhalpun wrote:
 Could someone please schedule appropriate binNMUs?

I have rescheduled both sparc64 and sh4, as I currently maintain both.

Thanks a lot for letting me know, very often the need of binNMU in such
cases are noticed only very late and eventually require manual builds.

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


-- 
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/558475fd.7090...@physik.fu-berlin.de

Re: binNMUs of rtmpdump on sparc64 and sh4

[John Paul Adrian Glaubitz]

On 06/19/2015 10:49 PM, Andreas Cadhalpun wrote:
 I have rescheduled both sparc64 and sh4, as I currently maintain both.
 
 Thanks for doing that so quickly!

Sure.

 Thanks a lot for letting me know, very often the need of binNMU in such
 cases are noticed only very late and eventually require manual builds.
 
 Unfortunately the build on sh4 failed with an internal compiler error:
 rtmp.c: In function 'RTMP_Init':
 rtmp.c:341:3: internal compiler error: Segmentation fault
r-m_fAudioCodecs = 3191.0;

This is well known and already being analyzed in [1].

 Anyway, I'm mainly interested in getting a ffmpeg build log from sparc64,
 because the previous builds always failed with a lot of SIGBUS crashes during
 the test suite [1].

Might be related to previous hardware issues with the buildds. We have
a new machine set up now and I just recently got build queue going
again. I am taking care of as many packages as I can, currently for
m68k, sh4 and sparc64 :).

 Since I can't reproduce this with a sparc64 installation on qemu, I'm now
 trying to run the test suite under gdb to get some backtraces.

I could test it on real hardware, if you're interested.

Adrian

 [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563


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


-- 
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/5584828b.8050...@physik.fu-berlin.de

Re: Bug#777169: FTBFS on sparc64: symbol errors

[John Paul Adrian Glaubitz]

On 06/17/2015 11:47 PM, John Paul Adrian Glaubitz wrote:
 Send a patch if you feel it is worth it.
 
 Currently working on that. Will throw in a patch once I got a working
 build which I will be uploading to unreleased.

Attached patch fixes the FTBFS for me on sparc64. I'm about to upload
a fixed version to unreleased now. The transfer of the compiled packages
from the build machine is a bit slow at the moment.

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
diff -Nru gcc-old/gcc-4.9-4.9.2/debian/libstdc++6.symbols.32bit gcc-4.9-4.9.2/debian/libstdc++6.symbols.32bit
--- gcc-old/gcc-4.9-4.9.2/debian/libstdc++6.symbols.32bit	2015-06-18 15:49:22.0 -0500
+++ gcc-4.9-4.9.2/debian/libstdc++6.symbols.32bit	2015-06-17 02:25:10.074262708 -0500
@@ -328,7 +328,7 @@
  _ZNSt14collate_bynameIcEC2EPKcj@GLIBCXX_3.4 4.1.1
  _ZNSt14collate_bynameIwEC1EPKcj@GLIBCXX_3.4 4.1.1
  _ZNSt14collate_bynameIwEC2EPKcj@GLIBCXX_3.4 4.1.1
- (arch=!powerpc !powerpcspe !ppc64 !sparc)_ZNSt14numeric_limitsIeE12max_digits10E@GLIBCXX_3.4.14 4.5.0
+ (arch=!powerpc !powerpcspe !ppc64 !sparc !sparc64)_ZNSt14numeric_limitsIeE12max_digits10E@GLIBCXX_3.4.14 4.5.0
  _ZNSt15basic_streambufIcSt11char_traitsIcEE10pubseekoffExSt12_Ios_SeekdirSt13_Ios_Openmode@GLIBCXX_3.4 4.1.1
  _ZNSt15basic_streambufIcSt11char_traitsIcEE12__safe_gbumpEi@GLIBCXX_3.4.16 4.6.0
  _ZNSt15basic_streambufIcSt11char_traitsIcEE12__safe_pbumpEi@GLIBCXX_3.4.16 4.6.0
diff -Nru gcc-old/gcc-4.9-4.9.2/debian/libstdc++6.symbols.common gcc-4.9-4.9.2/debian/libstdc++6.symbols.common
--- gcc-old/gcc-4.9-4.9.2/debian/libstdc++6.symbols.common	2015-06-18 15:49:22.0 -0500
+++ gcc-4.9-4.9.2/debian/libstdc++6.symbols.common	2015-06-18 02:25:21.144521387 -0500
@@ -1112,17 +1112,17 @@
  _ZNSt12system_errorD0Ev@GLIBCXX_3.4.11 4.4.0
  _ZNSt12system_errorD1Ev@GLIBCXX_3.4.11 4.4.0
  _ZNSt12system_errorD2Ev@GLIBCXX_3.4.11 4.4.0
- _ZNSt13__future_base11_State_baseD0Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base11_State_baseD1Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base11_State_baseD2Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base12_Result_baseC1Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base12_Result_baseC2Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base12_Result_baseD0Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base12_Result_baseD1Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base12_Result_baseD2Ev@GLIBCXX_3.4.15 4.6
- _ZNSt13__future_base19_Async_state_commonD0Ev@GLIBCXX_3.4.17 4.7.0~rc1
- _ZNSt13__future_base19_Async_state_commonD1Ev@GLIBCXX_3.4.17 4.7.0~rc1
- _ZNSt13__future_base19_Async_state_commonD2Ev@GLIBCXX_3.4.17 4.7.0~rc1
+ (arch=!sparc64)_ZNSt13__future_base11_State_baseD0Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base11_State_baseD1Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base11_State_baseD2Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base12_Result_baseC1Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base12_Result_baseC2Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base12_Result_baseD0Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base12_Result_baseD1Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base12_Result_baseD2Ev@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZNSt13__future_base19_Async_state_commonD0Ev@GLIBCXX_3.4.17 4.7.0~rc1
+ (arch=!sparc64)_ZNSt13__future_base19_Async_state_commonD1Ev@GLIBCXX_3.4.17 4.7.0~rc1
+ (arch=!sparc64)_ZNSt13__future_base19_Async_state_commonD2Ev@GLIBCXX_3.4.17 4.7.0~rc1
  _ZNSt13bad_exceptionD0Ev@GLIBCXX_3.4 4.1.1
  _ZNSt13bad_exceptionD1Ev@GLIBCXX_3.4 4.1.1
  _ZNSt13bad_exceptionD2Ev@GLIBCXX_3.4 4.1.1
@@ -1931,9 +1931,9 @@
  _ZNSt16invalid_argumentD0Ev@GLIBCXX_3.4 4.1.1
  _ZNSt16invalid_argumentD1Ev@GLIBCXX_3.4 4.1.1
  _ZNSt16invalid_argumentD2Ev@GLIBCXX_3.4.15 4.6
- _ZNSt16nested_exceptionD0Ev@CXXABI_1.3.5 4.6
- _ZNSt16nested_exceptionD1Ev@CXXABI_1.3.5 4.6
- _ZNSt16nested_exceptionD2Ev@CXXABI_1.3.5 4.6
+ (arch=!sparc64)_ZNSt16nested_exceptionD0Ev@CXXABI_1.3.5 4.6
+ (arch=!sparc64)_ZNSt16nested_exceptionD1Ev@CXXABI_1.3.5 4.6
+ (arch=!sparc64)_ZNSt16nested_exceptionD2Ev@CXXABI_1.3.5 4.6
  _ZNSt17__timepunct_cacheIcE12_S_timezonesE@GLIBCXX_3.4 4.1.1
  _ZNSt17__timepunct_cacheIcED0Ev@GLIBCXX_3.4 4.1.1
  _ZNSt17__timepunct_cacheIcED1Ev@GLIBCXX_3.4 4.1.1
@@ -2562,9 +2562,9 @@
  _ZTIN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE@GLIBCXX_3.4 4.1.1
  _ZTIN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE@GLIBCXX_3.4 4.1.1
  _ZTIN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE@GLIBCXX_3.4 4.1.1
- _ZTINSt13__future_base11_State_baseE@GLIBCXX_3.4.15 4.6
- _ZTINSt13__future_base12_Result_baseE@GLIBCXX_3.4.15 4.6
- _ZTINSt13__future_base19_Async_state_commonE@GLIBCXX_3.4.17 4.7.0~rc1
+ (arch=!sparc64)_ZTINSt13__future_base11_State_baseE@GLIBCXX_3.4.15 4.6
+ (arch=!sparc64)_ZTINSt13__future_base12_Result_baseE@GLIBCXX_3.4.15 4.6

Re: Bug#777169: FTBFS on sparc64: symbol errors

[John Paul Adrian Glaubitz]

 Send a patch if you feel it is worth it.

Currently working on that. Will throw in a patch once I got a working
build which I will be uploading to unreleased.

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


-- 
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/5581eada.4050...@physik.fu-berlin.de

Re: Time to change the debian-ports list?

[John Paul Adrian Glaubitz]

I'm in favor of the old design because I think it's important to havw a list 
which can be used to make announcements about important issues that all porters 
should be aware of.

It's not really that mails going to debian-ports@ appear that often.

PS: Excuse my quoting style, currently on mobile.

Adrian

 On Jul 22, 2015, at 7:04 PM, Steve McIntyre st...@einval.com wrote:
 
 On Wed, Jul 22, 2015 at 05:38:17PM +0200, Wouter Verhelst wrote:
 On Fri, Jul 17, 2015 at 01:40:20PM +0100, Steve McIntyre wrote:
 On Thu, Sep 11, 2014 at 12:51:29PM +0100, Steve McIntyre wrote:
 On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote:
 Alexander Wirt dixit:
 
 Could you please (technically) summarize what needs to be done from
 listmaster side?
 
 1. Remove whatever debian-po...@lists.debian.org is right now
 
 2. Create a new debian-po...@lists.debian.org mailing list which
  works just like the other regular lists
 
 3. Announce the new debian-po...@lists.debian.org so that people
  can subscribe to it; document that there is no longer
  an address to reach *all* ports but that people should
  eMail the individual ports’ lists (and cross-post if
  needed, but only to the amount needed), and that the
  new debian-po...@lists.debian.org instead is a mailing list for
  discussion about
  a) debian-ports.org infrastructure
  b) porting Debian in general
  c) questions related to setting up a Debian port,
 including wanna-build, buildd, etc.
 
 That seems like a bad idea to me, tbh. There will be people who won't
 notice that the meaning of debian-ports@ has changed, and who will try
 to use it with its old meaning.
 
 If there are problems with the current meaning of debian-ports, can't we
 just retire the old alias and create a list under a different name?
 
 Is there much point to that? I've not heard anybody at all speak up in
 favour of the existing behaviour. If anybody does use try to use it
 that way in future, the new list will most likely be the best place
 for their mail to go...
 
 -- 
 Steve McIntyre, Cambridge, UK.st...@einval.com
 I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall.  -- Charlie Stross
 
 
 -- 
 To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20150722170456.gc5...@einval.com


--
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/a3f2133d-cea2-42d5-a4d3-5dacfe6ec...@physik.fu-berlin.de

Re: using build profiles breaks debian-ports

[John Paul Adrian Glaubitz]

On 07/17/2015 09:31 AM, Thorsten Glaser wrote:
 using build profiles breaks debian-ports architectures, all of them:

What exactly is a build profile in this context?

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


-- 
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/55a8bda0.4010...@physik.fu-berlin.de

Re: Bug#777169: FTBFS on sparc64: symbol errors

[John Paul Adrian Glaubitz]

On 06/18/2015 11:29 PM, Matthias Klose wrote:
 this doesn't look correct. You simply allow the libstdc++ build without these
 symbols.  Please could you address this upstream, and ask to create a baseline
 symbols file, and then see if the build is supposed to be done without these
 symbols?

Just for documentation purposes, this issue seems to have the same
cause as #792204 in the gcc-5 package. The bug report there now shows
a possible solution, see [1].

Adrian

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792204#35

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


-- 
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/55acaed5.9050...@physik.fu-berlin.de

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

mozjs on sparc64 has been fixed

[John Paul Adrian Glaubitz]

Hello!

I have had a closer look at the mozjs package and it turns out that
the package can be easily fixed on sparc64 by disabling the integrated
just-in-time compiler, the same measure that already helped with
pcre3.

The patch is rather simple and just involved patching the configure.in
and its resulting configure script in js/src as described here [1] in a
fix for Iceweasel (Iceweasel uses the same JavaScript engine).

Furthermore, I have updated the symbols file for all architecture so
that #669944 [2] is fixed as well.

I'm just waiting for a friend who is currently writing a patch to
fix the build on x32 which is a bit tricky since the source code
does not really deal with a amd64 ABI with 32-bit pointers.

We're making good progress on sparc64 now.

Cheers,
Adrian

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

-- 
 .''`.  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: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

[John Paul Adrian Glaubitz]

On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> If the output is -1, the bug has been fixed. If the output is 0, then
> the bug is still present. 0 indicates the two strings are equal. Clearly
> they are not. :)

Looks like it has been fixed. Anything non-zero means strcmp says the
strings are not equal, so not just -1:

(unstable-sparc64-sbuild)root@andi:/tmp# gcc -O0 test.c -o test64
(unstable-sparc64-sbuild)root@andi:/tmp# ./test64
1
(unstable-sparc64-sbuild)root@andi:/tmp# cat test.c
/* test.c */
#include 
#include 

int main() {
  char a[2] = { 1, 0 };
  char b[2] = { 0, 0 };
  printf("%d\n", strcmp(a,b));
}
(unstable-sparc64-sbuild)root@andi:/tmp#

This has been tested with gcc_5.2.1-23 and glibc_2.19-22 on sparc64.

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

[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: Infiniband and OFED on Debian sparc64

[John Paul Adrian Glaubitz]

On 11/13/2015 09:58 AM, Tony Rodriguez wrote:
>>From my understanding some individuals are working on updating/fixing
> Debian sparc64.  Can we also please add Infiniband and OFED for Debian
> Sparc64?  Sun Infiniband cards don¹t appear to  be supported on Debian
> Sparc 64 with OFED.

I have no idea what QFED is so you have to be a bit more elaborative.

I assume that Infiniband support should be the same or similar as on
x86_64 provided that the kernel you are using is recent enough but
frankly, I have never used Infiniband on anything else but x86_64.

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

[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: Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

On 10/30/2015 09:56 PM, John Paul Adrian Glaubitz wrote:
> Because currently any package linking against libsystemd or 
> libudev, *will* fail to build from source on sparc and sparc64. In 
> return, these packages have many reverse dependencies meaning that 
> many packages in sparc64 are currently BD-Uninstallable.

Is there any chance now that this fix can be temporarily merged into
the systemd package until the larger work on binutils/gold to implement
support for the STT_REGISTER has been finished?

We really don't have any chance to continue working on this port without
this hotfix as *all* packages which link against either libsystemd
or libudev will fail with linker issues such as:

configure: error: udev selected but libudev not found
checking for udev_new in -ludev... no
"tail -v -n +0 config.log"
==> config.log <==
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by util-linux configure 2.27, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --build=sparc64-linux-gnu --prefix=/usr
- --includedir=${prefix}/include --mandir=${prefix}/share/man
- --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
- --disable-silent-rules --libdir=${prefix}/lib/sparc64-linux-gnu
- --libexecdir=${prefix}/lib/sparc64-linux-gnu --disable-maintainer-mode
- --disable-dependency-tracking --enable-line
- --libdir=/lib/sparc64-linux-gnu
- --libexecdir=${prefix}/lib/sparc64-linux-gnu --enable-raw
- --with-selinux --enable-partx --with-systemd --with-udev
- --enable-tunelp --enable-static-programs=fdisk,sfdisk,blkid
- --localstatedir=/run --disable-silent-rules --without-python
- --enable-libmount-force-mountinfo --disable-login --disable-nologin
- --disable-su --disable-kill --disable-eject --disable-chfn-chsh

We really need your help on this.

Thank you,

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWN35LAAoJEHQmOzf1tfkTnC8P/3sYeiJfu8vACM+iPyvEEARm
hCFA1aJFSRVgOdVBearw98hQjilgi28A/gL5/Qux79CnBvwBvw4/S2u2nCvR1UIn
SW0d1lb668618GMkJmD2+4wWu2cON47502x35A8H6c1gwLzQOd0Kk+P72E3iRC06
GdTvg7C0R7+XPO7/pA4QysSkSDFZjf4ZGo+Tt2qo1ol/waN/sR9WFn7zg9pT6LLA
hOvfRdC8blV5xMZg6kAQBb7DF2PgrjYs2zPQhbWu7y4/nm4VhfMlwK4HvF46tRzM
T8azgKuRYscZY/YTbi1APd3EjVvEuLqt1Ynx3jbX1JBX6NTAX7eiaSSZ1b/EgBdy
7obbTOdA8kxpRjZ4q5fuGuQkYQRswl1UwfLt0ls15qcv0iTgzCqm51niFQ0AC3Cg
TXIj7aBltIInmdeBYswZb9Exlw09amhP2yXwYzbuPC+Xrynzitq9vQ+sq2Dqa/Kl
Ay0W4rWN0/3epevoqjKYTJqqoNrM0BXG4tyGppn4m++gttLFCcGFenYph3XA76Um
dMj7JACxug3zLZlcCBeszGzA3d62bn/zyePHCpRDOAzVOhUWqNSHBU9VJAXHr26H
cLdfbFpCGtzZlr8bqvCd3EfAkZydTymwlY9xYVtquD8nWfxz6jMDq1498WsYx8ss
zpiXDOtzySdNr4vTrGw6
=WNPj
-END PGP SIGNATURE-

Re: Fix for pcre3 on sparc64

[John Paul Adrian Glaubitz]

On 11/02/2015 03:58 PM, John Paul Adrian Glaubitz wrote:
> Disabling the JIT fixes the build problem on sparc64. I have already
> prepared a patch and asked the maintainer for permission for an NMU [1].

Alright. I got a positive answer, fixed package has already been
uploaded :).

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

Fix for pcre3 on sparc64

[John Paul Adrian Glaubitz]

Hi!

I had another look at the pcre3 issue on sparc64 today and realized
that this package fails to build from source because it ships with
a just-in-time compiler (JIT) which is not fully compatible with
sparc64.

Disabling the JIT fixes the build problem on sparc64. I have already
prepared a patch and asked the maintainer for permission for an NMU [1].

Adrian

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

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

[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

Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

Package: systemd
Version: 227-2
Severity: important

Hello!

We're currently having linker issues on sparc64 for packages which link against
libsystemd. This is a result of systemd defaulting to gold instead of ld/bfd.

While there has been an exception in place for sparc [1], this does not cover
sparc64 and there linker problems there still cause lots of headaches for
the sparc64 port.

Could you please change the build system (e.g. rules file) such that it uses
ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
in the future)?

This workaround is necessary because gold is currently missing support for
the STT_REGISTER [2]. This feature is currently being worked on and once
it's there, the workaround can be dropped.

Cheers,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760879
> [2] 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: Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

Control: tags -1 patch

On 10/30/2015 04:26 PM, John Paul Adrian Glaubitz wrote:
> On 10/30/2015 01:59 PM, John Paul Adrian Glaubitz wrote:
>> Could you please change the build system (e.g. rules file) such that it uses
>> ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
>> in the future)?
> 
> More specific, please re-apply this patch [1] and extend it for sparc64
> as well:

Attaching a suggested 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
--- debian/rules.org	2015-10-09 12:54:59.0 +0200
+++ debian/rules	2015-10-30 16:45:06.317724651 +0100
@@ -16,6 +16,13 @@
 export DEB_BUILD_PROFILES += noudeb
 endif
 
+# Linking systemd with the gold linker on sparc/sparc64 currently breaks
+# linking of other binaries against systemd's shared libraries due to a
+# limitation in gold on these architectures (binutils PR target/19019).
+ifneq (,$(findstring $(DEB_BUILD_ARCH), sparc sparc64))
+LD=ld
+endif
+
 CONFFLAGS = \
 	--with-rootprefix= \
 	--with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \

Re: Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

On 10/30/2015 01:59 PM, John Paul Adrian Glaubitz wrote:
> Could you please change the build system (e.g. rules file) such that it uses
> ld/bfd on *both* sparc *and* sparc64 (we are planning to ressurrect sparc
> in the future)?

More specific, please re-apply this patch [1] and extend it for sparc64
as well:

diff --git a/debian/rules b/debian/rules
index f7effa5..78074ff 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,13 @@ ifneq (,$(findstring stage1,$(DEB_BUILD_PROFILES)))
 BOOTSTRAP_DH_FLAGS := -Ngir1.2-gudev-1.0 -Nlibgudev-1.0-0
-Nlibgudev-1.0-dev
 endif

+# sparc/sparc64 must use the bfd linker since gold will
+# will result in broken shared libraries
+ifneq ($(findstring $(DEB_BUILD_ARCH), sparc sparc64),)
+LD=ld
+endif
+
+
 CONFFLAGS = \
--with-rootprefix= \
--with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \

This patch was dropped when gudev was removed from systemd upstream
assuming that linking with gold would affect gudev only. However,
it affects linking against libsystemd and libudev in general,
for example usbutils [2]:

/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

Thanks,

Adrian

> [1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8e9833a6f297a0c69180ba4a4801fd1d396b17a9
> [2]
https://buildd.debian.org/status/fetch.php?pkg=usbutils=sparc64=1%3A007-4=171387
-- 
 .''`.  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: Fix for pcre3 on sparc64

[John Paul Adrian Glaubitz]

On 11/02/2015 03:58 PM, John Paul Adrian Glaubitz wrote:
> Disabling the JIT fixes the build problem on sparc64. I have already
> prepared a patch and asked the maintainer for permission for an NMU [1].

Btw, as for systemd - the second essential package which has currently
issues on sparc64 - I still haven't received a positive reply from
the systemd maintainers in Debian to acknowledge my patch which
would work-around the linker issues we have [1].

Adrian

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

-- 
 .''`.  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: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

On 10/14/2015 11:20 AM, Josip Rodin wrote:
> I didn't claim that, I just said the shipping cost range can be unreasonable.
> In fact, I would say even 40-50 EUR is entirely unreasonable for a machine 
> that
> *maybe* costs that much now, and which is so battered that it will probably
> cost 0 EUR by the time it's rebooted once again - when it finally fails due
> to any one of its many ailments.

Meh, it's still not that easy to get such hardware on eBay for that
price, at least not in Europe. I would also still consider 50 Euros
not to much for shipping.

> You don't need the specific hardware, the only thing of value on it is the
> software, and you can have DSA rsync everything from the old machines, which
> also costs 0 EUR if we ignore man-hours :)

Yeah, sure. But anyway, we will probably not need schroeder and lebrun
anyway. However, if there are any useful hardware components in them
that are hard to get by, it would still be great to keep them.

In any case, we have several people who have offered hosted SPARC
machines for Debian SPARC now as well as a team at Oracle which
is still actively supporting Linux on SPARC. Thus, I already
sent a request to the Debian FTP and buildd teams as well as
Aurelien Jarno to get 'sparc' added to Debian Ports.

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: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

On 10/14/2015 10:31 AM, Josip Rodin wrote:
> Which is entirely irrelevant to this case because schroeder and lebrun are
> not in Germany, and someone already posted links to the online documentation
> that says so?

Yes, but they are in Croatia and shipping 31.5 kg from Croatia to
Germany costs approximately 40-50 Euros and not 500 something
as you claimed.

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: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/14/2015 11:33 AM, Paul Wise wrote:
> On Wed, 2015-10-14 at 11:25 +0200, John Paul Adrian Glaubitz
> wrote:
> 
>> a team at Oracle which is still actively supporting Linux on
>> SPARC
> 
> That seems surprising, do you have a reference for this?

Sure: https://lists.debian.org/debian-sparc/2015/10/msg00012.html

- -- 
 .''`.  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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWHiJBAAoJEHQmOzf1tfkTYZYP/j/xh9Cev8nQXmO/FisDpxg9
AK7MzhORhZfN9wygbGreYkEOuRO9zq2DX4IxSoPXfoqyrmMnfrPJgGhs2PVCTlLR
dJrjPVj5cqlre09NKozuDlaXes2o1gWrgPFbsYmOoAz/3wXrwSH55VoSZwFJ3ioI
LFxSpL55kQVvPh4fQP0waJ0baa6JxLLDh16aDyK12MKAhiDTAFzEDBeKRolwnOLD
X5YRLuq+mPOE1sXLjxE1EFgXtbrViOJUf2eorPVGpDSkgxTqG7PZm1KpedZ3w7/W
QPjpzMEwUtA8/yYb9BDQmsnV8Iq4muI2fCE4gxJ0oNZjQHHxkMyjo2/+w4Lqw29o
9aCgm34fJRHyoI2rePgb/xWNizODdSG513yTTKF6qcUzN1/6X4QJmqjlW/OT4qT0
/exP6bBqpN9XnMxYBxxURSowNTd0F0nZAXp/EVSnHkckNqRAOZNSzoEcfotJu8kj
J/E6O9oL/wD+spGxy2UtD/c6KjhM0w2HW4j8zcJ+hEKaBsKEFzzxkWN1pBV1o/6N
zhFyERiQTfSvH61IHnYNdPqvh8sgpRyRoCqTUuOvkhFeRYR0LLWVs0Lkx5HIst/a
pXluDIvT3106Xd+My9utYmkc0ewg4AMOoI9JUVmfBgxVbFDShtzQKRCkpWXeaWMI
pMB6rQ+zw69yx6HakcG9
=+Yp7
-END PGP SIGNATURE-

Re: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

On 10/14/2015 11:56 AM, Josip Rodin wrote:
> OTOH perhaps this is a simple indicator why the port has been dying - if it
> takes a non-trivial amount of money to get a long-obsolete, over a decade
> old machine, it's not going to attract a lot of people.

The reactions to my survey regarding the resurrection of the sparc
port on debian-sparc have been thoroughly positive. There are many
users interested in getting the port back into shape.

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 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: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

Sounds awesome!

I would love to setup a buildd for sparc (32 bit) on this machine for Debian 
Ports.

I'm a DD and I will send you my SSH public key later. Currently at the airport 
and on mobile only.

Cheers,
Adrian

> On Oct 12, 2015, at 9:53 AM, Harka Gyozo SA <car...@ttk.pte.hu> wrote:
> 
> On Sat, 10 Oct 2015 08:57:17 +0200, Josip Rodin wrote
>> On Sun, Oct 04, 2015 at 09:43:04AM +0200, Peter Palfrader wrote:
>>> John Paul Adrian Glaubitz schrieb am Sonntag, dem 04. Oktober 2015:
>>> 
>>>> Where are those machines hosted at the moment and would it be possible
>>>> to keep them at their current place but hand the administration to the
>>>> people working on the sparc/sparc64 ports?
>>>> 
>>>> I would love to set them up as buildds for Debian ports.
>>> 
>>> The machines have broken disks so their raids have failed.  And the
>>> mgmt stuff is complaining about CPU and/or other fans too.
>>> 
>>> I don't think you'd want those machines.
> 
> I have a T2000 as a "hot spare". We can fire it up and give access to it if
> DSA wants, or we can give access to "people working on the sparc/sparc64
> ports" while it's still hosted here.
> AFAIK it has 8GB ram, two working ~73G sff sas hdds, an optical drive, 4xGbit
> eth, and a working management. And it has T1 Naigara cpu (executes the SPARC
> V9 instruction set).
> AFAIK It has a virtualization support ( this works somehow with a solaris
> hypervisor, and works with linux guests, but I think the machine is too small
> to utilize this ).
> We can also add some backup space (on a slow nas with rsync, etc.).
> 
> But as I can see there is sompek and stadler still running...
> 
> It' a little bit noisy, but still works well.
> If I turn it on, I will not hear anything from it because there is an SGI UV
> 1000 in that room :D
> 
> I have a machine like schroeder, but that's still in use (armed to the teeth).
> 
> 
> HARKA Győző
> PTE-TTK SzSzK vez.h.

Re: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

The cost of shipping depends on from where to where you ship them, obviously.

You can ship up to 31.5 kg within Germany for just 13.99 EUR. As long as you 
don't have to ship acres the pond, it shouldn't be too expensive.

> On Oct 10, 2015, at 3:57 PM, Josip Rodin <j...@entuzijast.net> wrote:
> 
>> On Sun, Oct 04, 2015 at 09:43:04AM +0200, Peter Palfrader wrote:
>> John Paul Adrian Glaubitz schrieb am Sonntag, dem 04. Oktober 2015:
>> 
>>> Where are those machines hosted at the moment and would it be possible
>>> to keep them at their current place but hand the administration to the
>>> people working on the sparc/sparc64 ports?
>>> 
>>> I would love to set them up as buildds for Debian ports.
>> 
>> The machines have broken disks so their raids have failed.  And the
>> mgmt stuff is complaining about CPU and/or other fans too.
>> 
>> I don't think you'd want those machines.
> 
> The cost of shipping any of them would probably exceed the cost of getting
> a new one from eBay these days. I did that search now just for kicks and
> the third result on the UK site literally says GBP 45.77 + 553.64 postage :)
> 
> I haven't seen the original message in this thread, but just make sure
> you mail the folks at CARNet when you pull the plug, so they can do that
> literally.
> 
> -- 
> 2. That which causes joy or happiness.

Re: schroeder and lebrun EOL - decomission

[John Paul Adrian Glaubitz]

Wow, I am overwhelmed by all these offers. You people are amazing!

> On Oct 12, 2015, at 7:30 AM, david h. <davidh...@gmail.com> wrote:
> 
> Hello, 
> I have 2 t2000 servers with 8 cores and 32 gigabytes of ram, each.
> I have to change some ram because at the moment they utilize only 16, but 
> then I will search for cheap rack space to put them in, and could set them up 
> as build servers. If there is need for that.
> 
> Greetings David
> Am 12.10.2015 03:04 schrieb "John Paul Adrian Glaubitz" 
> <glaub...@physik.fu-berlin.de>:
>> The cost of shipping depends on from where to where you ship them, obviously.
>> 
>> You can ship up to 31.5 kg within Germany for just 13.99 EUR. As long as you 
>> don't have to ship acres the pond, it shouldn't be too expensive.
>> 
>> > On Oct 10, 2015, at 3:57 PM, Josip Rodin <j...@entuzijast.net> wrote:
>> >
>> >> On Sun, Oct 04, 2015 at 09:43:04AM +0200, Peter Palfrader wrote:
>> >> John Paul Adrian Glaubitz schrieb am Sonntag, dem 04. Oktober 2015:
>> >>
>> >>> Where are those machines hosted at the moment and would it be possible
>> >>> to keep them at their current place but hand the administration to the
>> >>> people working on the sparc/sparc64 ports?
>> >>>
>> >>> I would love to set them up as buildds for Debian ports.
>> >>
>> >> The machines have broken disks so their raids have failed.  And the
>> >> mgmt stuff is complaining about CPU and/or other fans too.
>> >>
>> >> I don't think you'd want those machines.
>> >
>> > The cost of shipping any of them would probably exceed the cost of getting
>> > a new one from eBay these days. I did that search now just for kicks and
>> > the third result on the UK site literally says GBP 45.77 + 553.64 postage 
>> > :)
>> >
>> > I haven't seen the original message in this thread, but just make sure
>> > you mail the folks at CARNet when you pull the plug, so they can do that
>> > literally.
>> >
>> > --
>> > 2. That which causes joy or happiness.

Adding sparc to Debian Ports

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear FTP team and dear buildd team!

As discussed at DebConf15, I would like to ask you to add 'sparc'
(SPARC 32-bit port)to Debian Ports after it was previously removed from
the release architecture.

After a fruitful discussion on the debian-sparc mailing list [1],
we have come to the conclusion that there are enough people willing
to invest time, effort and resources in resurrecting the sparc
ports of Debian. While we already have sparc64 in ports, sparc (32)
runs on more hardware and has more packages which are actually
ported to sparc. For example, mozjs builds fine on sparc32 but
FTBFS on sparc64.

Moreover, several people [2-3] have also offered fast SPARC machines
as buildds which they are hosting themselves so we are not
dependent on any of the older, half-broken Debian SPARC
machines. So hardware won't be an issue.

Plus, Oracle is still actively maintaining the Linux SPARC
port [4], so I think we have the ideal prerequisites for
reviving the port.

I will take care of setting up the buildds and all, I just need
to have 'sparc' added on the FTP servers as well in wanna-build.

Please let me know if there is anything I can do to help in
the process.

Thanks,
Adrian

> [1] https://lists.debian.org/debian-sparc/2015/09/msg4.html [2]
> https://lists.debian.org/debian-sparc/2015/10/msg00017.html [3]
> https://lists.debian.org/debian-sparc/2015/10/msg00020.html [4]
> https://lists.debian.org/debian-sparc/2015/10/msg00012.html

- -- 
 .''`.  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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWHPv7AAoJEHQmOzf1tfkTPDQQAJzd/Am6ODUW+csk2WErcY2Q
Vugd/k7WPq5r8IsZZJuCJ1Y5qBCl1VXIW/6liwcsvFR5EsHWpwd5LUTv6fdqayQ5
5MjwPooVs6LQpEilXEo4lOmhYCq+mxdXaJhzaAezaQmGBY1eBHMBlQXZTiAbUfry
U+PDF5B4iMRYo2JlF06Pu5MQNFjNvF1aa9xDy0A1tcWPlMLRpVUsHhAE7ir004ve
6NaLGytZmS1LnechW8NVvC0sCilg5mes5nriFsTokGZMZQdwBqFGw9UH+D5xEtqd
1v1RxwE3eCTQnn6paCw8vy+YxZYsdCp11IlxPTr6UvcKzOwHJ9uXkrmTfahtMjfF
P+xU0AG47VTwu4VZqq05mzfNlfIHZC/jnsCfqGMRLHfXP5rzydzSC4cw4+Ko/92M
bPSZIZHUbrKkd+O5gVBUkIMZebDYnmeVUVMPYPvsW6wfpMNKW9wzNu8w3PRc91f1
Rm9CR5rot7ZYs/IdPzx4OxpK2OvmGqstWzJY51JMBsAw2u3fsOf6BImzW7e9brCy
h8Sr6RgT8Bs03UGyk88LvE6VD0IgNZO/HQj0zLdAAolNPxcBzhxeqISsN5lEGoFX
HOgnb26t17P5GswSnpDBZfZ0A2CNXC0pZ+HaQBKU+RiSwwmXXkXsFmBop06mWZJ6
ykqs9blY+s129Sdt1M5V
=Uw90
-END PGP SIGNATURE-

Re: Bug#790556: systemctl crashes, systemd setup fails

[John Paul Adrian Glaubitz]

Hello!

This has been recently fixed upstream in binutils. So rebuilding the
systemd package with the patched version of binutils should fix this
issue! There is a second binutils bug which still results in a
partially broken systemd package though [1].

@Matthias: Could you please backport the patch from trunk? It's filed
   as PR ld/18855 [2].

Cheers,

Adrian

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

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

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=sparc64=1%3A007-4=1441551102
> [2]
https://buildd.debian.org/status/fetch.php?pkg=systemd=sparc64=226-1=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

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

[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

[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/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

[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

[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: Building a sparc64 chroot with debootstrap (?)

[John Paul Adrian Glaubitz]

On 09/18/2015 03:07 AM, jhcha54008 wrote:
> Hi,
> I just read the ongoing discussion on sparc64 chroots (
> https://lists.debian.org/debian-sparc/2015/09/msg00015.html
> and https://lists.debian.org/debian-sparc/2015/09/msg00016.html)
> 
> Perhaps my debootstrap script 
> 
> https://lists.debian.org/debian-alpha/2014/06/msg00012.html
> 
> may help in this regard. It was tested only on alpha so far
> (and hppa where it is irrelevant) and I would be thankful
> for test reports on other architectures. 

That's actually a nice idea, thanks for the patch. Have you
considered sending this patch to the debbootstrap maintainer?

Being able to use unreleased when bootstrapping a ports architecture
is an incredibly helpful feature. Please file a bug against
debbootstrap with your patch attached if you haven't already.

> P-S : It seems that the package libaudit1 currently causes the
> installation to fail - it is perhaps advisable to wait for a newer
> version.
> 
> .The following dependency problems occur :
> required  package libaudit1(1:2.4.4-3) :  unmet dependency  libaudit-common 
>   (>= 1:2.4.4-3)  -  libaudit-common (1:2.4.4-2)  will be installed

Yeah, but we still stumble over libpcre3 which is not available
in unstable but unreleased only. I had to patch the package
as it won't build on sparc64 without modifications.

Normally, I can just build such packages manually with

$ export DEB_BUILD_OPTIONS="nobench nocheck" ; sbuild ...

but that doesn't help as the pcre3 source package ignores these
settings, it will run the testsuite in any case. Running with
"nobench nocheck" set normally disables the testsuite for
most packages.

Fixing the testsuite failure for pcre3 is also a high priority
task, btw. But first we have to fix the linker issue as having
a properly working toolchain is most important since a broken
toolchain can result into broken binaries which expose weird
crashes which are often incorrectly identified as a bug in the
particular package instead of the toolchain.

FWIW, the audit problem has already resolved itself. It was just
the debian-ports FTP server which hadn't synced the audit-common
package yet.

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

[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

[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/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: [Debian-ports-devel] wanna-build borked for m68k, sh4, sparc64

[John Paul Adrian Glaubitz]

On 11/30/2015 10:05 PM, Christian T. Steigies wrote:
> If you decide to do nothing, can I put an instrument or two on your rocket?
> I'd love to do some in-situ measurements on the way to Pluto!

<3. If we hurry up, we might be able to catch up with Voyager I ;-).

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: Bug#806837: qtwebkit: FTBFS on sparc64

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/02/2015 11:18 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
>> Could you also apply David's patch [1] which is required to fix
>> the build on sparc64? Disabling the JIT on sparc64 unfortunately 
>> isn't enough.
> 
> Good catch! Indeed I missed it. The patch looks fine and qt4's
> upstream status is "no more changes", so I'm applying it as a
> Debian delta.

Awesome, thank you very much!

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWX27gAAoJEHQmOzf1tfkTdsQQALPWdtGtSn8XepnzzWTvsqgW
lgt/3ldb/haoqnGeqdfN53dGHwecCeYUkp7Jrc7B82gzQNaH0KUWcqyRYIpjJZ9j
7pVmjNkDvF8w9p3DZzZiMEB9N48u7nQIlQvUw2fMJJBknUCvzpJ333woB/Q1Z1Ft
FtFx+BCWvlzyp1Ua9FmhFJew7vEGXQu3GhpG4naitbPxYkmp/V3W0Y5hDfH5Weg+
gl/3fb0rDLnIqO3Wh9Zgq5hEpWmD1exKeciwn+d+/P882VxhIkaVjvBMnK7uHacp
vgclKD1wQW4oajw6P4X5aSygWE7o67JTTnK2BQMVNymL0O4G4y3c/un3V7t2+9w5
lEWimOSBU+skpEXGk5NtqRl9hMEXTTm6mBuhXsSPA2+S8Z9mTPNIjIc2lZhyFEEZ
fX0+c2vlbxEIP6mWCRvgKmWrnr1qEDfG+GpOxc3R41ehWcQeC7H3GOvbkPXo/mTx
8eb5I7ydZxM8iZLYTNs6dtXXkP739ujg04a7kx0QEvZAAVY3F0EFiPgWwpWdU7R/
aWwyT8NzjeUZqlJDQSypqJAgS4vSWmeHYZ03hmdRvUtQoUUIrF0r2q0gci5jw+zp
LIihlBPurH/k3hLLn5KUNg+u/YGd2xY2Ts8RDIImrVVr/lMqDfI9JS9iHNOsyaA4
8UuU4sPtwm3T2oW1+xqq
=chUB
-END PGP SIGNATURE-

Pre-compiled ghc binaries for sparc64?

[John Paul Adrian Glaubitz]

Hi Jose!

I'm currently trying to bootstrap ghc on Debian/sparc64 which is a bit
tricky since ghc requires ghc to build itself [1].

I was wondering whether you have any ghc binaries for sparc64 available
from Oracle Linux etc which I could use to build the ghc package in
Debian/sparc64.

I'm cross-posting this to debian-sparc@l.d.o., maybe someone else here
has an idea how to build ghc for sparc64 without having to mess around
with cross-compilers on an amd64 host.

Adrian

> [1] https://buildd.debian.org/status/package.php?p=ghc=sid

-- 
 .''`.  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: Pre-compiled ghc binaries for sparc64?

[John Paul Adrian Glaubitz]

On 12/03/2015 11:04 AM, Romain Dolbeau wrote:
> Apparently you don't need a cross-compiler:
> 
> <https://wiki.haskell.org/GHC:FAQ#How_do_I_port_GHC_to_platform_X.3F>
> 
> I quote:
> 
>  "Both ways require you to bootstrap from intermediate HC files: these
> are the stylised C files generated by GHC when it compiles Haskell
> source. Basically the idea is to take the HC files for GHC itself to the
> target machine and compile them with gcc to get a working GHC, and go
> from there."

Sounds a bit more feasible, yeah!

But I'll wait if someone else shows up with pre-compiled binaries.
Still looks like a lot of work and I would like to do some m68k
work 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: Bug#806784: gcc-5: FTBFS on sparc64 due to mismatched lib32gfortran3.symbols.sparc64

[John Paul Adrian Glaubitz]

On 12/01/2015 11:18 AM, John Paul Adrian Glaubitz wrote:
> Unfortunately, the latest upload of gcc-5 (5.2.1-27) fails to build from
> source for us due to a mismatched lib32gfortran3.symbols.sparc64 symbols
> file [1].

This bug currently prevents us from building a sparc64 cross-compiler
according to [1] which we will need to build ghc.

Adrian

> [1] https://wiki.debian.org/BuildingCrossCompilers

-- 
 .''`.  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: Samba FTBFS - no idea why

[John Paul Adrian Glaubitz]

On 12/04/2015 12:53 PM, Mark Cave-Ayland wrote:
> It was a few years back I ran into this, but from memory the fallback
> downloads weren't cached so all the stylesheets were downloaded for
> every build which took a significant amount of time

But as I said, downloading the stylesheet with wget does work. So
the file is there on the server:

> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

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: Samba FTBFS - no idea why

[John Paul Adrian Glaubitz]

On 12/04/2015 12:44 PM, Mark Cave-Ayland wrote:
> Not sure if it's exactly the same problem, however I've experienced
> something similar trying to build other software - if xsltproc can't
> find a particular stylesheet installed locally then it will fall back to
> trying to download it from the stylesheet URI.

Hmm, but surprisingly, the download seems to work using wget and on
the buildds where the build succeeds, the download is actually
working:

Checking for stylesheet
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
: ok

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: Pre-compiled ghc binaries for sparc64?

[John Paul Adrian Glaubitz]

On 12/03/2015 02:13 PM, Jose E. Marchesi wrote:
> Nope.  We didn't bootstrap ghc in sparc64 yet.  However, if you have a
> working multilib toolchain you could probably use a sparcv9 ghc build to
> bootstrap a sparc64 build (according to [1] there are sparc debian and
> gentoo packages).

That's exactly the idea I just had moments ago ;-).

Currently working on 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: Pre-compiled ghc binaries for sparc64?

[John Paul Adrian Glaubitz]

On 12/03/2015 02:07 PM, John Paul Adrian Glaubitz wrote:
> Currently working on that.

Ok, so I had to copy the ghc stuff into the sparc64 chroot manually
because the package versions for glibc and libgcc cannot be matched,
even with snapshots.

I got this far so far:

(unstable-sparc64-sbuild)root@andi:/# /usr/lib/ghc/bin/ghc
bash: /usr/lib/ghc/bin/ghc: No such file or directory
(unstable-sparc64-sbuild)root@andi:/# /lib/sparc-linux-gnu/ld-linux.so.2
--library-path /lib/sparc-linux-gnu/ usr/lib/ghc/bin/ghc
ghc: missing -B option
(unstable-sparc64-sbuild)root@andi:/#

Any idea what is missing here that I need to run the binary with the
dynamic loader from sparcv8+ manually? Shouldn't just running
/usr/lib/ghc/bin/ghc be enough?

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: Pre-compiled ghc binaries for sparc64?

[John Paul Adrian Glaubitz]

On 12/03/2015 02:20 PM, John Paul Adrian Glaubitz wrote:
> Any idea what is missing here that I need to run the binary with the
> dynamic loader from sparcv8+ manually? Shouldn't just running
> /usr/lib/ghc/bin/ghc be enough?

Did a little script magic:

(unstable-sparc64-sbuild)root@andi:/# ghc --version
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The Glorious Glasgow Haskell Compilation System, version 7.8.4
(unstable-sparc64-sbuild)root@andi:/#

Now I'll just need to manage to get it actually compile.

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: Samba FTBFS - no idea why

[John Paul Adrian Glaubitz]

On 12/04/2015 02:49 PM, Mark Cave-Ayland wrote:
> While the download fall-back should work, my personal experience has
> been that the docbook.xsl download is terribly flakey, presumably since
> as the default behaviour is to download any missing .xsl files on every
> invocation then the origin servers must struggle with load at peak times.

But why does it work on all other architectures except kfreebsd-*,
sparc64 and x32:

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

They even just recently rebuilt the samba packages. If your theory
was correct, then this should affect all the other architectures
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

Partial bootstrapping guide for ghc

[John Paul Adrian Glaubitz]

Hello!

I have been busy almost the whole evening yesterday to bootstrap ghc on
Debian sh4 yesterday. I successfully cross-compiled ghc for sh4 and
installed a mini ghc distribution into my sh4 sbuild chroot. I still
have some minor issues with the ghc package database so that I cannot
build the Debian ghc package for sh4 yet, but otherwise, ghc on sh4
is fully working.

Thus, if anyone wants to get their hands at bootstrapping ghc for
sparc64 - which I would highly appreciate - here's what you need
to do to get a stage2 (a native) compiler for sparc64:

1. Install ghc on your amd64 build machine and its build
   dependencies:

   $ apt-get install ghc && apt-get build-dep ghc

2. Install the sparc64 gcc cross toolchain:

   $ apt-get install gcc-sparc64-linux-gnu

3. Download the right version of ghc from Debian:

   $ wget
http://snapshot.debian.org/archive/debian/20151203T214229Z/pool/main/g/ghc/ghc_7.10.3.orig.tar.xz

4. Unpack the source tarball:

   $ tar xf ghc_7.10.3.orig.tar.xz

5. Apply this patch: https://phabricator.haskell.org/D1430

6. Run configure with sparc64-linux-gnu as TARGET:

   $ ./configure --enable-unregisterised --target=sparc64-linux-gnu
--with-curses-libraries=/usr/lib/sparc64-linux-gnu
--with-curses-includes=/usr/include
--with-gmp-libraries=/usr/lib/sparc64-linux-gnu
--with-gmp-includes=/usr/sparc64-linux-gnu/include

7. Edit ghc's build configuration to build ghc's BuildFlavour
   "quick-cross" only.

   $ cp mk/build.mk.sample mk/build.mk

   and uncomment "BuildFlavour  = quick-cross"

   In the same file, check that in the section for "quick-cross"
   further below, you remove "-fllvm" everywhere.

   Here you can also control with ("stage=1" or "stage=2") whether
   you want to build just stage1 or right away stage2 the latter
   requiring to move the code over onto a native sparc64 to
   continue the build at some point.

8. Run "make".

Let me know about your results. This guide is still incomplete
but if everything goes well, you should end up with a minimal
stage1 and/or stage2 compiler respectively.

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: Partial bootstrapping guide for ghc

[John Paul Adrian Glaubitz]

On 12/05/2015 10:13 AM, John Paul Adrian Glaubitz wrote:
> I have been busy almost the whole evening yesterday to bootstrap ghc on
> Debian sh4 yesterday. I successfully cross-compiled ghc for sh4 and
> installed a mini ghc distribution into my sh4 sbuild chroot. I still
> have some minor issues with the ghc package database so that I cannot
> build the Debian ghc package for sh4 yet, but otherwise, ghc on sh4
> is fully working.

The issue I have in particular, see [1]:

utils/ghc-pwd/Main.hs:1:1:
Could not find module `Prelude'
There are files missing in the `base-4.8.2.0' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.

utils/ghc-pwd/Main.hs:4:8:
Could not find module `System.Directory'
There are files missing in the
`directory-1.2.2.0@direc_4Sod2TaWh9Z6fieXcjcSyq' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.

utils/ghc-pwd/Main.hs:5:8:
Could not find module `System.Environment'
There are files missing in the `base-4.8.2.0' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.

utils/ghc-pwd/Main.hs:6:8:
Could not find module `System.Exit'
There are files missing in the `base-4.8.2.0' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.

utils/ghc-pwd/Main.hs:7:8:
Could not find module `System.IO'
There are files missing in the `base-4.8.2.0' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.

Anyone can help fixing this?

Adrian

> [1] https://people.debian.org/~glaubitz/ghc-build.log

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

Bug#807006: qemu: FTBFS on sparc64 due to incompatible linker parameters

[John Paul Adrian Glaubitz]

Package: qemu
Version: 1:2.4+dfsg-5
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64

Hello!

qemu currently fails to build from source on sparc64 because it sets
both the linker parameters "-r" and "--relax":

cc -nostdlib -Wl,-r -o block/iscsi.mo block/iscsi.o
/usr/bin/ld: --relax and -r may not be used together
collect2: error: ld returned 1 exit status
make[1]: *** [block/iscsi.mo] Error 1
/«BUILDDIR»/qemu-2.4+dfsg/rules.mak:117: recipe for target 'block/iscsi.mo' 
failed

This happens because gcc is called with "-Wl,-r" which does not gcc's
internal mechanism to disable "--relax" at the same time (for whatever
reason).

Thus, on sparc*, gcc should be either called with just "-Wl" but not with "-r"
or the option "-no-relax" should be passed in order to fix this problem.

ghc upstream had the same problem and fixed the issue by setting "-no-relax"
for sparc [1].

Please apply a similar fix for qemu.

Cheers,
Adrian

> [1] https://ghc.haskell.org/trac/ghc/ticket/3791

-- 
 .''`.  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: Bug#806837: qtwebkit: FTBFS on sparc64

[John Paul Adrian Glaubitz]

On 12/02/2015 02:26 AM, David Matthew Mattli wrote:
> qtwebkit currently fails to build for sparc64. I was able to
> fix the build by adding sparc64 to the list of non-JIT archs
> in debian/rules

FWIW, please add m68k and sh4 to this list, too!

Building a patched version for 'unreleased' now in any case.

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: Bug#806837: qtwebkit: FTBFS on sparc64

[John Paul Adrian Glaubitz]

On 12/02/2015 10:32 AM, John Paul Adrian Glaubitz wrote:
> On 12/02/2015 02:26 AM, David Matthew Mattli wrote:
>> qtwebkit currently fails to build for sparc64. I was able to
>> fix the build by adding sparc64 to the list of non-JIT archs
>> in debian/rules
> 
> FWIW, please add m68k and sh4 to this list, too!

Make it alpha and ppc64 as well.

Thus, please add alpha m68k ppc64 sh4 sparc64 to the list of
architectures where the JIT should be disabled.

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: Bug#806837: qtwebkit: FTBFS on sparc64

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/02/2015 02:23 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> The change is already pushed to our repo.

Thanks!

Could you also apply David's patch [1] which is required to fix the
build on sparc64? Disabling the JIT on sparc64 unfortunately
isn't enough.

Cheers,
Adrian

> [1]
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=5;bug=806837;fil
ename=fix-sparc64.diff

- -- 
 .''`.  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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWXvGlAAoJEHQmOzf1tfkT8/wQAMNXDtiU/cI8yRbRRNSO8l3F
yXzAxmdzPqB5pR84NtpKP8NIbutQFeyw5tn3id628flMwaVkejwZDEvI8DpdA1BY
UEhof/5jExsDo+nyUVjhxxb4MzRTrbUopw7my1XnJu5KadjG07K7dbdsvTngxZXU
iB8xWIydiIlmyMAdWK7raN2EOSPbbfPtGwblK+HQXAJXXl/B7qewWzWIvsZGuBxm
8xiaohZ2bDZVFrp9F+Fp9XSIegpbJ2xUV67GgdtPkpK/FoJR1QPKECQxCtLyebQR
5Ogfyxho8K6VO14+0CXe42G1Jk51wdrdsb+KY63ZGYV6xZWu/BeCqTGPIMv2tcs+
W5OOBWLY2ifdF4RS4hU/lcj6HVCO0IC6frlN94aA7J63RNH9fF0KF49IhXU3Ej8r
ebMeFWrCPgPf6eYnffk2F2iOHnEAQS62sD7xSQbTGaL2RjxtJEO0EZoeiwo7wcGi
t0cfnjUcQO+Y5uwPdKtvde7XO+mhSFpinBaFbHmek/TPA9tNOrkN21r2AhSa2RF4
FqN4UtWZ3jDYcxH2pRYjC7+bhDpkOJ7MYyn73hbfjX9yzWJh+CmvnW0UMVJNOtHq
DbOhVNQ3q5wVA0z28oduQYdYDaWAuTbarYhhgQ2/HHnpRvFY1mJVjSttEdEBWCj7
hnp2LkIuQ0CNtq3NrKwT
=gYx2
-END PGP SIGNATURE-

Re: Bug#807777: ghc: Please adjust linker options for sparc64 (patch supplied)

[John Paul Adrian Glaubitz]

On 12/13/2015 12:05 PM, John Paul Adrian Glaubitz wrote:
> Ok, this seems to be a bit more complicated as the linker settings have
> to be explicitly set in the ghc source code directly. I have tried
> building hscolour manually which initially works but eventually fails
> with:
> 
> Language/Haskell/HsColour.hs:94:55: Warning: Tab character
> [ 1 of 16] Compiling Language.Haskell.HsColour.General (
> Language/Haskell/HsColour/General.hs,
> dist-ghc/build/Language/Haskell/HsColour/General.p_o )
> /usr/bin/ld: --relax and -r may not be used together
> collect2: error: ld returned 1 exit status
> make: *** [build-ghc-stamp] Error 1
> /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target
> 'build-ghc-stamp' failed
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Temporary workaround:

root@andi:/srv/disk1/chroots/unstable-sparc64-sbuild/usr/lib/ghc# diff
-u settings.orig settings
--- settings.orig   2015-12-12 15:18:11.0 +0100
+++ settings2015-12-13 11:45:21.52801 +0100
@@ -1,6 +1,6 @@
 [("GCC extra via C opts", " -fwrapv"),
  ("C compiler command", "/usr/bin/gcc"),
- ("C compiler flags", " -fno-stack-protector"),
+ ("C compiler flags", " -fno-stack-protector -Wl,-no-relax"),
  ("C compiler link flags", ""),
  ("Haskell CPP command","/usr/bin/gcc"),
  ("Haskell CPP flags","-E -undef -traditional "),
root@andi:/srv/disk1/chroots/unstable-sparc64-sbuild/usr/lib/ghc#

So, in case the patch from message #5 [1] in this bug report is
applied, please make sure to also patch the settings file for
ghc as above on sparc64 to make sure -Wl,-no-relax is always
used in ghc on sparc64.

I am about to file an upstream bug report in ghc so upstream can
develop a proper fix similar to the older fix for sparc [2].

Cheers,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80#5
> [2] https://ghc.haskell.org/trac/ghc/ticket/3791

-- 
 .''`.  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: Bug#807777: ghc: Please adjust linker options for sparc64 (patch supplied)

[John Paul Adrian Glaubitz]

On 12/12/2015 10:27 PM, John Paul Adrian Glaubitz wrote:
> I just successfully built the first ghc Debian packages for sparc64 with the
> help of bootstrapping ghc on amd64. In order to successfully build ghc on
> sparc64, I had to add -optl-Wl,-no-relax to SRC_HC_OPTS as otherwise gcc
> would pass "-r" and "--relax" to ld which is not allowed on sparc*.

Ok, this seems to be a bit more complicated as the linker settings have
to be explicitly set in the ghc source code directly. I have tried
building hscolour manually which initially works but eventually fails
with:

Language/Haskell/HsColour.hs:94:55: Warning: Tab character
[ 1 of 16] Compiling Language.Haskell.HsColour.General (
Language/Haskell/HsColour/General.hs,
dist-ghc/build/Language/Haskell/HsColour/General.p_o )
/usr/bin/ld: --relax and -r may not be used together
collect2: error: ld returned 1 exit status
make: *** [build-ghc-stamp] Error 1
/usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target
'build-ghc-stamp' failed
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Full build log here [1].

Thus, we have to make sure that ghc does not just set "-Wl,-no-relax"
when building itself but also when building any other Haskell sources.

Or, alternatively, we could try to convince the gcc/binutils developers
to fix the behavior of gcc/binutils when "-Wl,-r" are set. Apparently,
this could be interpreted as a bug in gcc which actually sets
"-no-relax" when "-r" is passed but not when "-Wl,-r" is passed.

qemu is affected by the same problem, see [2].

Anyone on the Debian sparc mailing list with an idea?

Cheers,
Adrian

> [1]
https://people.debian.org/~glaubitz/hscolour_1.23-3+sparc64_sparc64-20151213-0722
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807006

-- 
 .''`.  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: Bug#807777: ghc: Please adjust linker options for sparc64 (patch supplied)

[John Paul Adrian Glaubitz]

On 12/13/2015 07:04 PM, John Paul Adrian Glaubitz wrote:
> On 12/13/2015 12:32 PM, John Paul Adrian Glaubitz wrote:
>> I am about to file an upstream bug report in ghc so upstream can
>> develop a proper fix similar to the older fix for sparc [2].
> 
> Attaching a proposed fix which I have also posted upstream [1].

Oops, just saw there was a copy-and-paste error, attaching refreshed
patch. I forgot to change ArchSPARC to ArchSPARC64 after copying
the map section from sparc to sparc64.

Sorry for the noise!

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
Description: Add initial platform support for sparc64
 This patch adds initial platform support for sparc64 by
 mapping sparc64 to "ArchSPARC64" instead of "ArchUnknown"
 in aclocal.m4. Additionally, it adds "ArchSPARC64" to the
 list of known platforms in compiler/utils/Platform.hs
 and patches compiler/main/DriverPipeline.hs to explicitly
 pass -no-relax to gcc. See upstream ticket #11211 and
 Debian bug #80.
 .

Index: ghc-7.10.3/aclocal.m4
===
--- ghc-7.10.3.orig/aclocal.m4
+++ ghc-7.10.3/aclocal.m4
@@ -193,6 +193,10 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 sparc)
 test -z "[$]2" || eval "[$]2=ArchSPARC"
 ;;
+sparc64)
+test -z "[$]2" || eval "[$]2=ArchSPARC64"
+;;
+
 arm)
 GET_ARM_ISA()
 test -z "[$]2" || eval "[$]2=\"ArchARM {armISA = \$ARM_ISA, armISAExt = \$ARM_ISA_EXT, armABI = \$ARM_ABI}\""
@@ -209,7 +213,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 mipsel)
 test -z "[$]2" || eval "[$]2=ArchMipsel"
 ;;
-hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sh4|sparc64|vax)
+hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sh4|vax)
 test -z "[$]2" || eval "[$]2=ArchUnknown"
 ;;
 *)
Index: ghc-7.10.3/compiler/main/DriverPipeline.hs
===
--- ghc-7.10.3.orig/compiler/main/DriverPipeline.hs
+++ ghc-7.10.3/compiler/main/DriverPipeline.hs
@@ -2208,6 +2208,7 @@ joinObjectFiles dflags o_files output_fn
 -- -r and --relax are incompatible for ld, so
 -- disable --relax explicitly.
  ++ (if platformArch (targetPlatform dflags) == ArchSPARC
+ || platformArch (targetPlatform dflags) == ArchSPARC64
  && ldIsGnuLd
 then [SysTools.Option "-Wl,-no-relax"]
 else [])
Index: ghc-7.10.3/compiler/utils/Platform.hs
===
--- ghc-7.10.3.orig/compiler/utils/Platform.hs
+++ ghc-7.10.3/compiler/utils/Platform.hs
@@ -48,6 +48,7 @@ data Arch
 | ArchPPC
 | ArchPPC_64
 | ArchSPARC
+| ArchSPARC64
 | ArchARM
   { armISA:: ArmISA
   , armISAExt :: [ArmISAExt]

Re: Bug#807777: ghc: Please adjust linker options for sparc64 (patch supplied)

[John Paul Adrian Glaubitz]

On 12/13/2015 12:32 PM, John Paul Adrian Glaubitz wrote:
> I am about to file an upstream bug report in ghc so upstream can
> develop a proper fix similar to the older fix for sparc [2].

Attaching a proposed fix which I have also posted upstream [1].

Cheers,
Adrian

> [1] https://ghc.haskell.org/trac/ghc/ticket/11211

-- 
 .''`.  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
Description: Add initial platform support for sparc64
 This patch adds initial platform support for sparc64 by
 mapping sparc64 to "ArchSPARC64" instead of "ArchUnknown"
 in aclocal.m4. Additionally, it adds "ArchSPARC64" to the
 list of known platforms in compiler/utils/Platform.hs
 and patches compiler/main/DriverPipeline.hs to explicitly
 pass -no-relax to gcc. See upstream ticket #11211 and
 Debian bug #80.
 .

--- ghc-7.10.3.orig/aclocal.m4
+++ ghc-7.10.3/aclocal.m4
@@ -193,6 +193,10 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 sparc)
 test -z "[$]2" || eval "[$]2=ArchSPARC"
 ;;
+sparc64)
+test -z "[$]2" || eval "[$]2=ArchSPARC"
+;;
+
 arm)
 GET_ARM_ISA()
 test -z "[$]2" || eval "[$]2=\"ArchARM {armISA = \$ARM_ISA, armISAExt = \$ARM_ISA_EXT, armABI = \$ARM_ABI}\""
@@ -209,7 +213,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 mipsel)
 test -z "[$]2" || eval "[$]2=ArchMipsel"
 ;;
-hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sh4|sparc64|vax)
+hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sh4|vax)
 test -z "[$]2" || eval "[$]2=ArchUnknown"
 ;;
 *)
--- ghc-7.10.3.orig/compiler/main/DriverPipeline.hs
+++ ghc-7.10.3/compiler/main/DriverPipeline.hs
@@ -2208,6 +2208,7 @@ joinObjectFiles dflags o_files output_fn
 -- -r and --relax are incompatible for ld, so
 -- disable --relax explicitly.
  ++ (if platformArch (targetPlatform dflags) == ArchSPARC
+ || platformArch (targetPlatform dflags) == ArchSPARC64
  && ldIsGnuLd
 then [SysTools.Option "-Wl,-no-relax"]
 else [])
--- ghc-7.10.3.orig/compiler/utils/Platform.hs
+++ ghc-7.10.3/compiler/utils/Platform.hs
@@ -48,6 +48,7 @@ data Arch
 | ArchPPC
 | ArchPPC_64
 | ArchSPARC
+| ArchSPARC64
 | ArchARM
   { armISA:: ArmISA
   , armISAExt :: [ArmISAExt]

Re: Bug#807777: ghc: Please adjust linker options for sparc64 (patch supplied)

[John Paul Adrian Glaubitz]

Hi Joachim!

As per discussion on IRC in #debian-haskell, I have revised my patch
a bit after doing a build test on amd64 which triggered a few warnings
which this new patch eliminates. ghc builds cleanly on amd64 with
my patch applied.

My patch basically is a copy of the patch which added initial platform
support for Alpha, Mipseb and Mipsel upstream [1] minus the part with
the alignment requirement which is not necessary on SPARC and SPARC64
but plus the enforcing of "-no-relax" which is required on SPARC
and SPARC64.

Thus, if you compare my patch with the changes from [1], it should
be obvious that my patch is good and should do the right thing on
sparc64 without the danger of breaking anything else.

Please replace my old patch with the new one. I will also perform
a test build on sparc64 now. However, building on sparc64 is a
tad slower which means we will have to wait several days maybe
so you might as well upload 7.10.3-4 right away with my updated
patch.

Thanks for making me review my changes and test build them!
Adrian

> [1]
https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d53170c542

-- 
 .''`.  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
Description: Add initial platform support for sparc64
 This patch adds initial platform support for sparc64 by mapping
 sparc64 to "ArchSPARC64" instead of "ArchUnknown" in aclocal.m4.
 Additionally, it adds "ArchSPARC64" to the list of known platforms
 in compiler/utils/Platform.hs and various code sections of the
 compiler code where the architecture is checked. Finally, it patches
 compiler/main/DriverPipeline.hs to explicitly pass "-no-relax" to gcc.
 See upstream ticket #11211 and Debian bug #80.
 .

Index: ghc-7.10.3/aclocal.m4
===
--- ghc-7.10.3.orig/aclocal.m4
+++ ghc-7.10.3/aclocal.m4
@@ -193,6 +193,10 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 sparc)
 test -z "[$]2" || eval "[$]2=ArchSPARC"
 ;;
+sparc64)
+test -z "[$]2" || eval "[$]2=ArchSPARC64"
+;;
+
 arm)
 GET_ARM_ISA()
 test -z "[$]2" || eval "[$]2=\"ArchARM {armISA = \$ARM_ISA, armISAExt = \$ARM_ISA_EXT, armABI = \$ARM_ABI}\""
@@ -209,7 +213,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
 mipsel)
 test -z "[$]2" || eval "[$]2=ArchMipsel"
 ;;
-hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sh4|sparc64|vax)
+hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sh4|vax)
 test -z "[$]2" || eval "[$]2=ArchUnknown"
 ;;
 *)
Index: ghc-7.10.3/compiler/main/DriverPipeline.hs
===
--- ghc-7.10.3.orig/compiler/main/DriverPipeline.hs
+++ ghc-7.10.3/compiler/main/DriverPipeline.hs
@@ -2208,6 +2208,7 @@ joinObjectFiles dflags o_files output_fn
 -- -r and --relax are incompatible for ld, so
 -- disable --relax explicitly.
  ++ (if platformArch (targetPlatform dflags) == ArchSPARC
+ || platformArch (targetPlatform dflags) == ArchSPARC64
  && ldIsGnuLd
 then [SysTools.Option "-Wl,-no-relax"]
 else [])
Index: ghc-7.10.3/compiler/nativeGen/AsmCodeGen.hs
===
--- ghc-7.10.3.orig/compiler/nativeGen/AsmCodeGen.hs
+++ ghc-7.10.3/compiler/nativeGen/AsmCodeGen.hs
@@ -171,6 +171,7 @@ nativeCodeGen dflags this_mod modLoc h u
   ArchX86_64  -> nCG' (x86_64NcgImpl dflags)
   ArchPPC -> nCG' (ppcNcgImpldflags)
   ArchSPARC   -> nCG' (sparcNcgImpl  dflags)
+  ArchSPARC64 -> panic "nativeCodeGen: No NCG for SPARC64"
   ArchARM {}  -> panic "nativeCodeGen: No NCG for ARM"
   ArchARM64   -> panic "nativeCodeGen: No NCG for ARM64"
   ArchPPC_64  -> panic "nativeCodeGen: No NCG for PPC 64"
Index: ghc-7.10.3/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs
===
--- ghc-7.10.3.orig/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs
+++ ghc-7.10.3/compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs
@@ -111,6 +111,7 @@ trivColorable platform virtualRegSqueeze
 ArchX86_64-> 5
 ArchPPC   -> 16
 ArchSPARC -> 14
+ArchSPARC64   -> panic "

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

Source: libechonest
Version: 2.3.1-0.2
Severity: serious

Hello!

libechonest currently fails to build from source on *all* architectures
due to mismatched symbols file(s) after an unsuccessful NMU to fix
these files.

Please use the logs provided by the buildds [1] to fix the symbols for ALL
architectures, even on older architectures like m68k or sh4.

If you need assistance updating the symbol files for these architectures,
please let me know and I will help as I am an active porter for most
Debian Ports architectures.

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: Bug#807777: ghc: Please adjust linker options for sparc64 (patch supplied)

[John Paul Adrian Glaubitz]

On 12/12/2015 10:27 PM, John Paul Adrian Glaubitz wrote:
> ghc upstream actually contains a fix for this [1] which, unfortuntely,
> applies to sparc but not sparc64 as the latter is not natively supported
> by ghc yet and not detected as ArchSPARC.

Oops, forgot the link:

> [1] https://ghc.haskell.org/trac/ghc/ticket/3791

-- 
 .''`.  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: [feature request] linux-image-4.3.0-1-sparc64-smp: tpm random module for linux LDOMs

[John Paul Adrian Glaubitz]

On 01/04/2016 11:48 AM, Anatoly Pugachev wrote:
> Package: src:linux
> Version: 4.3.3-2
> Severity: wishlist

Missing the necessary tags:

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

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/04/2016 10:39 PM, Ulrich Teichert wrote:
> Yupp, with usual workarounds (preseeding, editing partman, manual module
> selections, manual kernel and silo install) I was able to use the image
> for an install (I used the older image, the CD was still in the drive):

Fixing the kernel and silo installation issue is up next. Currently
discussing with the d-i people in #debian-boot. I hope they're going
to merge my sparc64 patches for base-installer soon.

Btw, how did you install silo manually? I did that today with:

chroot /target
apt-get install linux-image-sparc64
# adding debian unreleased to /etc/apt/sources.list
apt-get update && apt-get install silo
# this installs silo and makes it bootable, but silo points to
# the wrong kernel by default

Or did you run silo outside the chroot?

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 12/29/2015 03:15 PM, John Paul Adrian Glaubitz wrote:
> On 12/29/2015 03:07 PM, Knut Petter Ølberg wrote:
>> Started installing in an LDOM, seems to be working fine. Came as far as
>> specifying the mirror, where I'm a bit lost as to what I should specify
>> to make reprepo create a local repo for stretch.
> 
> Normally you should be able to just use a regular Debian mirror, but
> when you use ftp.debian-ports.org/debian, it's not recognized as
> a mirror.

I'm working on a quick mini-howto for reprepro with apt-cacher-ng and
it seems I have to rebuild the netinst image to have debian-installer
set the default suite to "unstable" (currently points to "stretch").

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 12/29/2015 06:31 PM, John Paul Adrian Glaubitz wrote:
> On 12/29/2015 06:22 PM, John Paul Adrian Glaubitz wrote:
>> Hmm, let me test the new image first once it has been built. Might
>> be that we don't need a mirror after all. Could be that d-i couldn't
>> just use ftp.debian-ports.org because the suite was still set to
>> "stretch" which ftp.debian-ports.org doesn't have.
> 
> I have changed the suite to "sid" now:

Still doesn't work really. But if anyone else wants to try, you can
also configure debian-installer with the help of a preseed.cfg, see
here for an example:

> http://backup.parisc-linux.org/preseed-alpha.cfg

Adopt for your own needs and arch.

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 12/29/2015 05:57 PM, Kieron Gillespie wrote:
> I have a server sitting in the cloud currently not doing anything
> useful. It has a fairly good Internet connection. If I am pointed to
> some instructions I could set up a dedicated mirror for SPARC64.

Sounds good. Let me just test everything first.

But in case you want to start already, here's the mini howto:

$ apt-get install reprepro apt-cacher-ng
$ mkdir /srv/debian-sparc64-archive
$ cd /srv/debian-sparc64-archive
$ wget https://people.debian.org/~glaubitz/reprepro-conf-sparc64.tgz
$ tar xf reprepro-conf-sparc64.tgz
$ reprepro -V update # this takes some time
$ edit /etc/apt-cacher-ng/acng.conf

Uncomment the following line:

Port:3142

and under LocalDirs, add:

LocalDirs: debian /srv/debian-sparc64-archive

save the file and restart apt-cacher-ng:

$ /etc/init.d/apt-cacher-ng restart

# alternatively: systemctl restart apt-cacher-ng.service

This should make the mirror available as "http://yourserver:3141/debian;.

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 12/29/2015 06:05 PM, John Paul Adrian Glaubitz wrote:
> On 12/29/2015 05:57 PM, Kieron Gillespie wrote:
>> I have a server sitting in the cloud currently not doing anything
>> useful. It has a fairly good Internet connection. If I am pointed to
>> some instructions I could set up a dedicated mirror for SPARC64.
> 
> Sounds good. Let me just test everything first.
> 
> But in case you want to start already, here's the mini howto:

Hmm, let me test the new image first once it has been built. Might
be that we don't need a mirror after all. Could be that d-i couldn't
just use ftp.debian-ports.org because the suite was still set to
"stretch" which ftp.debian-ports.org doesn't have.

Looking at /var/log/syslog when d-i runs, helps to debug this.

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 12/29/2015 06:22 PM, John Paul Adrian Glaubitz wrote:
> Hmm, let me test the new image first once it has been built. Might
> be that we don't need a mirror after all. Could be that d-i couldn't
> just use ftp.debian-ports.org because the suite was still set to
> "stretch" which ftp.debian-ports.org doesn't have.

I have changed the suite to "sid" now:

>
https://people.debian.org/~glaubitz/debian-cd/debian-9.0-sparc64-NETINST-1.iso

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/01/2016 11:55 PM, John Paul Adrian Glaubitz wrote:
> Almost done. It seems I simply did not built the new base-installer and
> partman-ext3 packages. Will be right back with a new image.

Ok, updated:

>
https://people.debian.org/~glaubitz/debian-cd/debian-9.0-sparc64-NETINST-1.iso

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/01/2016 10:35 PM, Ulrich Teichert wrote:
> Partitioning is OK, but creating an ext4 filesystems still gets no further
> than 33%. Looks unchanged to me - from the outside.

Did you check whether the change that Kieron was talking about:

> Modified /lib/partman/commit.d/50format_ext3
> and changed the line
> mkfs.$filesystem $device $usage >/dev/null; then
> to
> mkfs.$filesystem -F $device $usage >/dev/null; then

was actually in? I might have just made a mistake while creating the
new image and forgot to include the updated installer packages.

> Never seen the kernel message in the logs before,

That's unrelated and probably an issue with your hardware.

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/01/2016 11:48 PM, Ulrich Teichert wrote:
> No harm done, though, installed the rest by hand for now and got a booting
> system with kernel 4.3.3. That's more than I could say last year ;-)

Almost done. It seems I simply did not built the new base-installer and
partman-ext3 packages. Will be right back with a new image.

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/02/2016 12:08 AM, Kieron Gillespie wrote:
> Any chance that we are about ready to write some instructions on how
> other can setup there own instance of SPARC64 yet?

Actually, once we have resolved these two issues, it should be almost
straight-forward to install sparc64. You just need to supply the
preseed file at the boot prompt:

boot: install
preseed/url=http://users.physik.fu-berlin.de/~glaubitz/preseed-sparc64.cfg

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/01/2016 10:49 PM, John Paul Adrian Glaubitz wrote:
> was actually in? I might have just made a mistake while creating the
> new image and forgot to include the updated installer packages.

Working on a new image, just a second.

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/01/2016 08:10 PM, John Paul Adrian Glaubitz wrote:
> Oh, nice. I can certainly just change this in d-i as well.

Updated NETINST ISO containing both changes:

>
https://people.debian.org/~glaubitz/debian-cd/debian-9.0-sparc64-NETINST-1.iso

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/02/2016 07:50 PM, Ulrich Teichert wrote:
> Booted up OK (with preseeding as usually), but still lacks the change for
> the partitioner. Are these changes part of the packages which are retrieved
> over the net?

I'm not sure. I was actually sure that debian-installer would use the
version of partman-ext3 which I provided with "localudebs". It might
be true that the updated package has to be on the servers actually.

> Perhaps they haven't been updated on debian-ports?

Well, I cannot just build and upload a fixed package to unstable because
the original maintainer would probably rather upset. I can, however,
upload the package to "unreleased" to see whether that helps.

The proper version of the package should be 85+sparc64 which includes
the fix. I'll just upload the package to unreleased now, just a
second.

> Unfortunatly, I'm now running into a new error during install of the base
> system:
> 
> Jan  2 18:15:07 debootstrap: dpkg: regarding .../ifupdown_0.8.5_sparc64.deb 
> containing ifupdown:
> Jan  2 18:15:07 debootstrap:  ifupdown breaks systemd (<< 228-3~)
> Jan  2 18:15:07 debootstrap:   systemd (version 228-2) is present and 
> triggered.
> 
> Does somebody know a different way forward?

Well, the error message is pretty clear. ifupdown wants system 228-3
or newer while sparc64 has still 228-2 which is a result of the
systemd package not being built on sparc64 yet (it's still building,
see [1]).

Adrian

> [1] https://buildd.debian.org/status/package.php?p=systemd=sid

-- 
 .''`.  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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/02/2016 08:20 PM, Ulrich Teichert wrote:
> Yeah, right, now the build of systemd has failed with the infamous segfault
> of xsltproc which I wanted to debug on the system where the install has
> failed...

Yeah, this should really be fixed. I'll check whether I can hack a work
around as this issue is starting to annoy me.

> I still can't stand systemd, can we please have back sysvinit as default?

I hope you are kidding. But in case you are not, the answer is no since
this isn't a simple matter of changing defaults and there is a shitton
of reverse dependencies that systemd has. Also, sysvinit is old and
unmaintained software.

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/02/2016 08:11 PM, John Paul Adrian Glaubitz wrote:
> Yeah, this should really be fixed. I'll check whether I can hack a work
> around as this issue is starting to annoy me.

I just made a binNMU for docbook-xsl with the proposed patch from
#765567 [1] which should alleviate this issue.

I will then reschedule all affected packages - including systemd -
later on.

Adrian

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

-- 
 .''`.  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: systemd again

[John Paul Adrian Glaubitz]

On 01/02/2016 10:22 PM, Ulrich Teichert wrote:
> For reasons, see [1] for example, but I'm sorry to stirr this all up
> again on this ML, where all people are tired of the discussion,

Yes, I'm tired of this as well because it always boils down to "I don't
like change" but change is inevtitable when it comes to software.

There is no reasonable argument against systemd and similar systems
which is why all major operating systems have shifted to something
like systemd, be it Solaris (SMF), OSX (launchd) or Linux (systemd).

And even the often cited FreeBSD developers actually agree on that
systemd moves into the right direction and FreeBSD will eventually
also jump the bandwagon:

>
https://www.reddit.com/r/linux/comments/2nhkx9/freebsds_jordan_hubbard_sees_need_for_a_modern/

Allowing choice for something fundamental as the init daemon requires
lots of maintanenace effort and people can't really expect developers
to spend that effort when there is no real gain in the end.

But anyway, please don't start flamewars here.

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: New working sparc64 netinst image

[John Paul Adrian Glaubitz]

On 01/02/2016 10:06 PM, Anatoly Pugachev wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809685

Oh, I forgot to mention, please always add:

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

Just did that manually using the bts command.

-- 
 .''`.  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: xsltproc: bus error on some architectures

[John Paul Adrian Glaubitz]

Hi!

We are constantly running into this issue on sparc64 as well.

I have already updated the kernel to 4.3.3 from unstable as well as
tried the patch that Peter De Wachter suggested for docbook-xsl as
well as changing the permissions for /dev/shm, to no avail.

xsltproc still randomly segfaults:

root@test-adrian1:~# chroot /srv/sid-sparc64-sbuild/
root@test-adrian1:/# cd debian/libxslt/systemd-228/man/
root@test-adrian1:/debian/libxslt/systemd-228/man# /usr/bin/xsltproc -o
man/halt.8 --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 228 --path
'./man:../man' ../man/custom-man.xsl ../man/halt.xml
Segmentation fault
root@test-adrian1:/debian/libxslt/systemd-228/man# /usr/bin/xsltproc -o
man/halt.8 --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 228 --path
'./man:../man' ../man/custom-man.xsl ../man/halt.xml  <== here it worked
root@test-adrian1:/debian/libxslt/systemd-228/man# /usr/bin/xsltproc -o
man/halt.8 --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 228 --path
'./man:../man' ../man/custom-man.xsl ../man/halt.xml
Segmentation fault
root@test-adrian1:/debian/libxslt/systemd-228/man# /usr/bin/xsltproc -o
man/halt.8 --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 228 --path
'./man:../man' ../man/custom-man.xsl ../man/halt.xml
Segmentation fault
root@test-adrian1:/debian/libxslt/systemd-228/man#

Frankly, I am very much convinced that xsltproc is broken. It's
apparently happening quite often that xsltproc segfaults as the
below reports on different architectures and operating systems
show:

> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471029
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203250
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195044
> https://forums.gentoo.org/viewtopic-t-248184-start-0.html
> https://trac.macports.org/ticket/24060

I find it rather frustrating that libxslt upstream does not consider
this a bug and hence closed the related bug report:

> https://bugzilla.gnome.org/show_bug.cgi?id=736077

I'm currently out of ideas and I would appreciate it a lot if anyone
could suggest something else to try.

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