from:"Mathieu Malaterre"

Re: Porter roll call for Debian Stretch

2016-10-01 Thread 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

2016-09-30 Thread 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: Porter roll call for Debian Stretch

2016-09-30 Thread Mathieu Malaterre

Hi all,

On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
>> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>>- powerpc: No porter (RM blocker)
>>
>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>> maintaining powerpcspe which is very similar to powerpc.
>
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

[Let's assume that we can't find a powerpc porter in time for Stretch.]

1. Will `powperpc` automatically be downgraded to simple port ? Or is
this also not automated and the port may simply be removed (eg. sparc)
?
2. Apart from loosing the automatic debian-installer stuff, what else
are we going to loose in that scenario ?

Thanks much for pointers !

-M

Re: [Stretch] Status for architecture qualification

2016-06-16 Thread Mathieu Malaterre

Hi Hector,

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

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

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

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

-M

Re: openexr

2016-04-26 Thread Mathieu Malaterre

On Fri, Apr 22, 2016 at 10:25 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> [CC me please]
>
> I am trying to debug openexr FTBFS:
>
> https://buildd.debian.org/status/fetch.php?pkg=openexr=sparc64=2.2.0-10=1461249335
>
> As far as I know there are no porterbox for sparc64:
>
> https://db.debian.org/machines.cgi
>
> Anyone could try to dump a full backtrace of the crash ?
>
> thanks much

Just for reference, the bug was trivial. Minimal test case:

$ cat test.cxx
#include 
#include 

using namespace std;

int main()
{
  int dataSize = 8220;
  vector data(4096);
  data.resize(dataSize);
{
  int64_t * p = (int64_t*)[0];
  *p = 0;
}
{
  int64_t * p = (int64_t*)([0]+1);
  *p = 0;
}
  return 0;
}

On x86 you can take advantage of the new UB sanitizer behavior from gcc:

$ g++ -fsanitize=undefined -o test test.cxx && ./test
test.cxx:18:9: runtime error: store to misaligned address
0x00f78c31 for type 'int64_t', which requires 8 byte alignment
0x00f78c31: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00
00 00 00 00 00  00 00 00 00 00
  ^

Cheers

openexr

2016-04-22 Thread Mathieu Malaterre

[CC me please]

I am trying to debug openexr FTBFS:

https://buildd.debian.org/status/fetch.php?pkg=openexr=sparc64=2.2.0-10=1461249335

As far as I know there are no porterbox for sparc64:

https://db.debian.org/machines.cgi

Anyone could try to dump a full backtrace of the crash ?

thanks much

ninja-build on sparc

2012-12-29 Thread Mathieu Malaterre

Dear sparc gurus,

  I am currently starring at:

https://buildd.debian.org/status/fetch.php?pkg=ninja-buildarch=sparcver=1.0.0-2stamp=1355239881

  This is extremely hard to deduce the type of error ninja-build could
be doing, that does not please a sparc system. I tried getting access
to a porterbox sparc machine, but my mail request does not seems to
reach anything [1], I suspect something is going on wrong ATM.

  So could someone with time  expertise could try building
ninja-build on sparc, and simply executing the test suite ?

Thanks much in advance,

Happy holidays !


[1] https://db.debian.org/doc-mail.html


-- 
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/CA+7wUswirC=L9=Zb76pKq_5GA2=yxqfux2pn1eapfbqvja7...@mail.gmail.com

gcc ICE

2011-11-04 Thread Mathieu Malaterre

Hi all,

  I am reporting an ICE for one of my project. Because I am not a DD,
I cannot fill a proper bug report upstream (gcc).

[  9%] Building CXX object
core/vnl/CMakeFiles/vnl.dir/Templates/vnl_matrix_fixed+vnl_rational.3.3-.o
cd 
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/core/vnl
 /usr/bin/c++   -Dvnl_EXPORTS -DVXL_WARN_DEPRECATED
-DVXL_WARN_DEPRECATED_ONCE -DVXL_LEGACY_ERROR_REPORTING -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
-Werror=format-security   -fPIC
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/vcl
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/core
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core-o
CMakeFiles/vnl.dir/Templates/vnl_matrix_fixed+vnl_rational.3.3-.o -c
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vnl/Templates/vnl_matrix_fixed+vnl_rational.3.3-.cxx
In file included from /usr/include/c++/4.6/vector:70:0,
 from
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl/iso/vcl_vector.h:6,
 from
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl/vcl_vector.h:16,
 from
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vsl/vsl_basic_xml_element.h:10,
 from
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vsl/vsl_basic_xml_element.cxx:2:
/usr/include/c++/4.6/bits/vector.tcc: In member function 'void
std::vector_Tp, _Alloc::_M_insert_aux(std::vector_Tp,
_Alloc::iterator, const _Tp) [with _Tp =
std::pairstd::basic_stringchar, std::basic_stringchar , _Alloc =
std::allocatorstd::pairstd::basic_stringchar,
std::basic_stringchar  , std::vector_Tp, _Alloc::iterator =
__gnu_cxx::__normal_iteratorstd::pairstd::basic_stringchar,
std::basic_stringchar *,
std::vectorstd::pairstd::basic_stringchar, std::basic_stringchar
  , typename std::_Vector_base_Tp,
_Alloc::_Tp_alloc_type::pointer = std::pairstd::basic_stringchar,
std::basic_stringchar *]':
/usr/include/c++/4.6/bits/vector.tcc:373:5: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.

ref:
http://buildd.debian-ports.org/status/fetch.php?pkg=vxlarch=sparc64ver=1.14.0-11stamp=1320254572

Thanks
-- 
Mathieu


-- 
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/CA+7wUswv9r-t5wnGG9s5D5isJzYA7JZkoBNi8hVH4=ys8b0...@mail.gmail.com

Re: gcc ICE

2011-11-04 Thread Mathieu Malaterre

Hi,

  To be more precise I would appreciate if someone could send me the
output of the following:

cd 
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/core/vnl
 /usr/bin/c++ -save-temps  -Dvnl_EXPORTS -DVXL_WARN_DEPRECATED
-DVXL_WARN_DEPRECATED_ONCE -DVXL_LEGACY_ERROR_REPORTING -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
-Werror=format-security   -fPIC
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/vcl
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/core
-I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core-o
CMakeFiles/vnl.dir/Templates/vnl_matrix_fixed+vnl_rational.3.3-.o -c
/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vnl/Templates/vnl_matrix_fixed+vnl_rational.3.3-.cxx

  the bug has been reported as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50990


Thanks !

On Fri, Nov 4, 2011 at 5:05 AM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:
 Hi all,

  I am reporting an ICE for one of my project. Because I am not a DD,
 I cannot fill a proper bug report upstream (gcc).

 [  9%] Building CXX object
 core/vnl/CMakeFiles/vnl.dir/Templates/vnl_matrix_fixed+vnl_rational.3.3-.o
 cd 
 /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/core/vnl
  /usr/bin/c++   -Dvnl_EXPORTS -DVXL_WARN_DEPRECATED
 -DVXL_WARN_DEPRECATED_ONCE -DVXL_LEGACY_ERROR_REPORTING -g -O2
 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
 -Werror=format-security   -fPIC
 -I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/vcl
 -I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl
 -I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/obj-sparc64-linux-gnu/core
 -I/build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core    -o
 CMakeFiles/vnl.dir/Templates/vnl_matrix_fixed+vnl_rational.3.3-.o -c
 /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vnl/Templates/vnl_matrix_fixed+vnl_rational.3.3-.cxx
 In file included from /usr/include/c++/4.6/vector:70:0,
                 from
 /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl/iso/vcl_vector.h:6,
                 from
 /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/vcl/vcl_vector.h:16,
                 from
 /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vsl/vsl_basic_xml_element.h:10,
                 from
 /build/buildd-vxl_1.14.0-11-sparc64-7PtzH6/vxl-1.14.0/core/vsl/vsl_basic_xml_element.cxx:2:
 /usr/include/c++/4.6/bits/vector.tcc: In member function 'void
 std::vector_Tp, _Alloc::_M_insert_aux(std::vector_Tp,
 _Alloc::iterator, const _Tp) [with _Tp =
 std::pairstd::basic_stringchar, std::basic_stringchar , _Alloc =
 std::allocatorstd::pairstd::basic_stringchar,
 std::basic_stringchar  , std::vector_Tp, _Alloc::iterator =
 __gnu_cxx::__normal_iteratorstd::pairstd::basic_stringchar,
 std::basic_stringchar *,
 std::vectorstd::pairstd::basic_stringchar, std::basic_stringchar
  , typename std::_Vector_base_Tp,
 _Alloc::_Tp_alloc_type::pointer = std::pairstd::basic_stringchar,
 std::basic_stringchar *]':
 /usr/include/c++/4.6/bits/vector.tcc:373:5: internal compiler error:
 Segmentation fault
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.

 ref:
 http://buildd.debian-ports.org/status/fetch.php?pkg=vxlarch=sparc64ver=1.14.0-11stamp=1320254572

 Thanks
 --
 Mathieu




-- 
Mathieu


--
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/CA+7wUswf+-L4LWj=vsb9hxuakxchce7m1rcs2pj65y72aga...@mail.gmail.com

Re: gcc ICE

2011-11-04 Thread Mathieu Malaterre

On Fri, Nov 4, 2011 at 9:49 PM, Julien Cristau jcris...@debian.org wrote:
 On Fri, Nov  4, 2011 at 10:05:49 +0100, Mathieu Malaterre wrote:

 Hi all,

   I am reporting an ICE for one of my project. Because I am not a DD,
 I cannot fill a proper bug report upstream (gcc).

 This makes no sense, what does being a DD have to do with upstream
 gcc...

Ok. I'll rephrase it into, i need someone with proper write level
access to buidd machine to execute the command described at:

http://lists.debian.org/debian-sparc/2011/11/msg8.html


-- 
Mathieu


--
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/CA+7wUszDT=7Xwe0W=ZHPUXh=btkegkmpnefjdktpe3sprv7...@mail.gmail.com

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

2011-04-26 Thread 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com

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

2009-07-14 Thread 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Porter roll call for Debian Stretch

Re: Porter roll call for Debian Stretch

Re: Porter roll call for Debian Stretch

Re: [Stretch] Status for architecture qualification

Re: openexr

openexr

ninja-build on sparc

gcc ICE

Re: gcc ICE

Re: gcc ICE

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

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

12 matches

Site Navigation

Mail list logo

Footer information