Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski <kilob...@angband.pl> wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
>> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>> <glaub...@physik.fu-berlin.de> wrote:
>> [...]
>> > On the other hand, some packages dropped support for PowerPC32 like Mono
>> > but this isn't a concern for most users, I would say.
>> [...]
>>
>> However I need to mention that the specific ppc/mono issue is in fact
>> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
>> short version is that this issue only happen because we build the
>> ppc32 mono version on a ppc64 kernel, I know that since I did debug
>> this issue.
>
> Which, if I read the bug correctly, is a yet another case of a bogus
> build system looking at characteristics of the machine it's compiled on
> rather than baseline of the arch.

Well the bug is really upstream: one cannot assume page size at
compilation time. But that is a different story.

> And, per your own work, it's +patch +fixed-upstream.

Wow ! In fact I just realize my patch was against git/master at the
time, and was never backported. Need to get this fixed ASAP.

>> I have not heard from the ppc64el porters, but I suspect ppc64 will
>> not be a release arch. So you need to take into consideration that for
>> powerpc to remain a release arch, one need minimal working ppc64 port.
>> Could we solve the situation of ppc64 for Stretch, could it be moved
>> to official release arch ?
>
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
>
> powerpc has:
> linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
> i386 has:
> linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
> linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
> linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
> protection
> linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
> linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)
>
> Note the joke: "for modern PCs".  Unless you do embedded it takes some
> serious dumpster diving to find a machine not better served by an -amd64
> kernel (and thus multiarch).  The i386 architecture is not self-contained,
> powerpc is.
>
> Thus, there is no need for ppc64 (userland), as long as powerpc has the
> toolchain to build 64-bit kernels.  And that's a primary target for gcc
> upstream.

Great ! That's all I wanted to check. I was worried we would need
buildd(s) running on ppc64el.

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Adrian,

On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
 wrote:
[...]
> On the other hand, some packages dropped support for PowerPC32 like Mono
> but this isn't a concern for most users, I would say.
[...]

Thanks very much for stepping up as porter, you have my vote !

However I need to mention that the specific ppc/mono issue is in fact
pretty interesting. The long thread is on debian-powerpc@l.d.o but the
short version is that this issue only happen because we build the
ppc32 mono version on a ppc64 kernel, I know that since I did debug
this issue.

I have not heard from the ppc64el porters, but I suspect ppc64 will
not be a release arch. So you need to take into consideration that for
powerpc to remain a release arch, one need minimal working ppc64 port.
Could we solve the situation of ppc64 for Stretch, could it be moved
to official release arch ?

-M

Re: [Stretch] Status for architecture qualification

[Mathieu Malaterre]

Hi Hector,

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

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

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

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

-M

Why is tbb 'Installed'

[Mathieu Malaterre]

[CC me please]

Hi,

I am starring at:

http://buildd.debian-ports.org/status/fetch.php?pkg=tbbarch=hppaver=4.2~20140122-2stamp=1408661761

How come the build finished with an error but the package is considered valid ?

Thanks


-- 
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUswOaOPJu_hL9JhL93qWJuDh2VMZmC=khdx-j9wg11c...@mail.gmail.com

Re: GCC-4.5 as the default for (at least some) architectures

[Mathieu Malaterre]

On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis
mar...@genesi-usa.com wrote:
 On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote:
 I'll make GCC 4.6 the default after the release of
 GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
 powerpc.

 Could you include armhf in the list as well?

I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package:

https://buildd.debian.org/status/package.php?p=vxl

but since there is no log I cannot confirm this is the same ICE as on i386/armel

thanks,
-- 
Mathieu


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

Re: [workaround] doxygen segfaults on kfreebsd-*, hppa

[Mathieu Malaterre]

On Fri, Aug 20, 2010 at 10:33 AM, Petr Salinger petr.salin...@seznam.cz wrote:
 hppa-porters, please take a look whether similar
 workaround works also for your pet architecture.
 So far at least clp, soprano, schroot are affected.

 Dear doxygen maintainer, please apply the workaround bellow,
 until the real cause is found.

 It looks like it affects also other platforms, only likelihood
 is a different. gdcm failed on armel, hppa, kfreebsd-amd64,
 powerpc, s390.

 Therefore I suggest:

 --- qtools/qthread_unix.cpp
 +++ qtools/qthread_unix.cpp
 @@ -179,6 +179,9 @@
  int QThread::idealThreadCount()
  {
     int cores = -1;
 +#if 1
 +    return -1;
 +#endif
  #if defined(_OS_MAC_)
     // Mac OS X
     cores = MPProcessorsScheduled();

 So far no response from doxygen maintainer, any NMUer ?

BTW, I am not even sure this would fix the symptoms. I tried a rebuild
of gdcm using DOT_NUM_THREADS = 1 in the doxygen configuration (which
I would hope would be the old behavior).
It did solve the symptoms on most platforms, except hppa:

https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=hppaver=2.0.16-2stamp=1282239282file=logas=raw

Total:
--
(in = 35718) (out = 17406) (deflated 51%)
[100%] building vtkgdcm.jar
make[3]: Leaving directory
`/build/buildd-gdcm_2.0.16-2-hppa-IM6tJt/gdcm-2.0.16/debian/build-python2.6'
[100%] Built target VTKGDCMJavaJar
make[3]: Entering directory
`/build/buildd-gdcm_2.0.16-2-hppa-IM6tJt/gdcm-2.0.16/debian/build-python2.6'
Scanning dependencies of target vtkgdcmPython
make[3]: Leaving directory
`/build/buildd-gdcm_2.0.16-2-hppa-IM6tJt/gdcm-2.0.16/debian/build-python2.6'
make[3]: Entering directory
`/build/buildd-gdcm_2.0.16-2-hppa-IM6tJt/gdcm-2.0.16/debian/build-python2.6'
[100%] Building CXX object
Utilities/VTK/CMakeFiles/vtkgdcmPython.dir/vtkgdcmPythonInit.cxx.o
Linking CXX shared module ../../bin/libvtkgdcmPython.so
Copy vtkgdcm.py into
/build/buildd-gdcm_2.0.16-2-hppa-IM6tJt/gdcm-2.0.16/debian/build-python2.6/bin
make[3]: Leaving directory
`/build/buildd-gdcm_2.0.16-2-hppa-IM6tJt/gdcm-2.0.16/debian/build-python2.6'
[100%] Built target vtkgdcmPython
make[3]: *** Deleting file `Utilities/doxygen/html/index.html'E:
Caught signal 'Terminated': terminating immediately

make[3]: *** wait: No child processes.  Stop.
make[3]: *** Waiting for unfinished jobs
make[3]: *** wait: No child processes.  Stop.
make[2]: *** [Utilities/doxygen/CMakeFiles/GDCMDoxygenDoc.dir/all] Error 2
make[1]: *** [all] Terminated
make: *** [debian/build-python2.6-stamp] Terminated
Build killed with signal TERM after 150 minutes of inactivity

Build finished at 20100819-1725
FAILED [dpkg-buildpackage died]



-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimxyenmwsnbh+izf-d8vn_qlvykukzuluzl1...@mail.gmail.com

Re: State of openjdk on hppa

[Mathieu Malaterre]

On Mon, Dec 7, 2009 at 5:55 PM, Matthias Klose d...@ubuntu.com wrote:
 On 07.12.2009 14:36, Onkar Shinde wrote:

 Hi,

 java3d currently fails to build on hppa because it uses some sun
 specific APIs and default-jdk is GCJ on hppa. A solution for this
 could be to use openjdk-6-jdk build-dep instead of default-jdk. But
 the problem is that there are no openjdk-* packages on hppa.

 Does anyone know if there is any effort going on to make openjdk-*
 packages available on hppa. If not then I will have to make java3d a
 !hppa package.

 openjdk builds on hppa, but doesn't run (yet). Andrew Haley once debugged it
 and found out at least one things which would need to be fixed: the
 assumption in the C++ interpreter that the stack always grows downwards, and
 not upwards as on hppa.

 please could one of the hotspot developers sched some light on this, how
 easy this might to be fix, and if there are other assumptions?

[hijacking thread]

Switching to openjdk would also work around the following issue:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40816

This means that VTK 5.4 will NOT FTBS on hppa once switched to openjdk :)

Thanks !
-- 
Mathieu


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

quilt: missing xutils-dev: missing libx11-dev: missing

[Mathieu Malaterre]

Hi there,

   I have yet another problem on the hppa buildd machine:

https://buildd.debian.org/fetch.cgi?pkg=dicom3toolsarch=hppaver=1.0~20091113-1stamp=1258748671file=logas=raw

...
Using default version 7.4.5
quilt: missing
xutils-dev: missing
libx11-dev: missing
x11proto-xext-dev: missing
Checking for source dependency conflicts...
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or
specify a solution).
Installing positive dependencies: debhelper quilt xutils-dev
libx11-dev x11proto-xext-dev
Reading package lists...
Building dependency tree...
Reading state information...
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
  debhelper: Depends: html2text but it is not going to be installed
 Depends: po-debconf but it is not going to be installed
 Depends: man-db (= 2.5.1-1) but it is not going to be installed

...

Is this a known problem ?

Thanks,
-- 
Mathieu


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

Re: gcj-4.4: Internal error: Segmentation fault (program ecj1)

[Mathieu Malaterre]

On Fri, Oct 30, 2009 at 4:58 PM, Carlos O'Donell
car...@systemhalted.org wrote:
 On Thu, Oct 29, 2009 at 2:30 PM, Mathieu Malaterre
 mathieu.malate...@gmail.com wrote:
 https://buildd.debian.org/~luk/status/package.php?p=gdcm
 - 
 https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=hppaver=2.0.13-1stamp=1256783874file=logas=raw

 Linking CXX shared library ../../bin/libvtkgdcmJava.so
 make[3]: Leaving directory
 `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
 [ 88%] Built target vtkgdcmJava
 make[3]: Entering directory
 `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
 Scanning dependencies of target VTKGDCMJavaJar
 make[3]: Leaving directory
 `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
 make[3]: Entering directory
 `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
 [ 88%] javac *.java - jar; jar cvf - vtkgdcm.jar
 gcj-4.4: Internal error: Segmentation fault (program ecj1)
 Please submit a full bug report.
 See file:///usr/share/doc/gcj-4.4/README.Bugs for instructions.
 make[3]: *** [bin/vtkgdcm.jar] Error 1
 make[2]: *** [Utilities/VTK/CMakeFiles/VTKGDCMJavaJar.dir/all] Error 2
 make[1]: *** [all] Error 2
 make: *** [debian/build-python2.5-stamp] Error 2


 I tried reproducing it here on my amd64 box using gcj-4.4 (testing)
 and gcc-snapshot but I cannot reproduce it here. I am guessing this is
 a hppa only issue. How should I handle that ? Could someone please
 have a look and

 I'm building this locally to see if I can reproduce.

BTW This may be linked to:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553722


-- 
Mathieu


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

gcj-4.4: Internal error: Segmentation fault (program ecj1)

[Mathieu Malaterre]

Hi there,

 I am starring at:

https://buildd.debian.org/~luk/status/package.php?p=gdcm
- 
https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=hppaver=2.0.13-1stamp=1256783874file=logas=raw

Linking CXX shared library ../../bin/libvtkgdcmJava.so
make[3]: Leaving directory
`/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
[ 88%] Built target vtkgdcmJava
make[3]: Entering directory
`/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
Scanning dependencies of target VTKGDCMJavaJar
make[3]: Leaving directory
`/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
make[3]: Entering directory
`/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5'
[ 88%] javac *.java - jar; jar cvf - vtkgdcm.jar
gcj-4.4: Internal error: Segmentation fault (program ecj1)
Please submit a full bug report.
See file:///usr/share/doc/gcj-4.4/README.Bugs for instructions.
make[3]: *** [bin/vtkgdcm.jar] Error 1
make[2]: *** [Utilities/VTK/CMakeFiles/VTKGDCMJavaJar.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [debian/build-python2.5-stamp] Error 2


I tried reproducing it here on my amd64 box using gcj-4.4 (testing)
and gcc-snapshot but I cannot reproduce it here. I am guessing this is
a hppa only issue. How should I handle that ? Could someone please
have a look and

Ref:

$ apt-cache policy gcj-4.4-jdk gcc-snapshot
gcj-4.4-jdk:
 Installed: 4.4.1-6
 Candidate: 4.4.1-6
 Version table:
 *** 4.4.1-6 0
       200 http://ftp.fr.debian.org testing/main Packages
       100 http://ftp.fr.debian.org unstable/main Packages
       100 /var/lib/dpkg/status
gcc-snapshot:
 Installed: 20090923-1
 Candidate: 20090923-1
 Version table:
 *** 20090923-1 0
       100 http://ftp.fr.debian.org unstable/main Packages
       100 /var/lib/dpkg/status

Thanks
--
Mathieu
Ps: on a different note, the README.Bugs file lives with gcc subdir,
not gcj subdir (IMHO):

http://packages.debian.org/search?suite=sidarch=anymode=pathsearchon=contentskeywords=README.Bugs


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

Please remove sticky Dep-Wait: libvtk5 (= 5.2.1-3) on gdcm

[Mathieu Malaterre]

Please clear  sticky Dep-Wait: libvtk5 (= 5.2.1-3) on gdcm package.

Ref:
https://buildd.debian.org/pkg.cgi?pkg=gdcm

Thank you

-- 
Mathieu


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