Re: Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

[Emilio Pozuelo Monfort]

Hi Simon,

On 08/02/2024 21:59, Simon McVittie wrote:

On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote:

Package: libmozjs-115-dev
Justification: makes gjs FTBFS (#1063433)


I believe mozjs115_115.7.0-3 should fix this.

wb-team: Please could someone with wanna-build access schedule gjs
on mips64el to be built after the fixed version of mozjs115 becomes
available? I believe the correct spelling is:

dw gjs_1.78.3-1 . unstable . mips64el . -m 'libmozjs-115-dev (>= 115.7.0-3)'


mozjs115 is already built, so I just gave gjs back.

Cheers,
Emilio

Re: Bug#913709: boost1.67: intermitent FTBFS on mips64el: build hangs

[Emilio Pozuelo Monfort]

Hi Giovanni,

On 14/11/2018 10:29, Giovanni Mascellani wrote:
> Hi,
> 
> Il 14/11/18 09:56, Emilio Pozuelo Monfort ha scritto:
>> Your package fails to build quite often on mips64el, where the build gets
>> killed due to inactivity:
>>
>> Cannot find class named 'action'
>> Cannot find class named 'action'
>> Cannot find class named 'file-target'
>> Cannot find class named 'generator'
>> Cannot find class named 'generator'
>> Cannot find class named 'std::bad_cast'
>> E: Build killed with signal TERM after 150 minutes of inactivity
>>
>> This  may be due to an actual hang, or something just taking so long
>> that causes the build to get killed.
> 
> Thanks for bringing this up. Actually, I was concerned about the same
> thing, but I do not really know what is the way forward here.
> 
> The "Cannot find class" messages are harmless: they are produced on all
> architectures and are not fatal. It is not a compiler that produces
> them, but a documentation postprocessor. So the worse that can happen is
> that some internal links in the documentation are broken or ignored.
> 
> Looking at [1] and comparing with [2] it seems that the compilation
> takes much longer when compiled on a "Loongson 3A" machine then when
> compiled on a "Cavium Octeon III" machine. MIPS porters, is this
> sensible? The longer compilation time (apparently ~8.5h vs ~4.75h)
> triggers the build node timeout. However this is probably a close call,
> because version 1.67.0-6 managed to finish even when building on a
> weaker machine.
> 
>  [1] https://buildd.debian.org/status/logs.php?pkg=boost1.67=mips64el
>  [2]
> https://wiki.debian.org/MIPSPort?action=show=mips64el#Build_daemons_.26_porter_boxes
> 
> I am not sure of what is the way forward here: can larger packages, like
> boost, be forced to compile on stronger machines? Or can the timeout be
> raised for larger packages? Or is there anything that can I due within
> the package compilation script to avoid triggering timeout? (although
> this last road seems to be risky, as it might then prevent triggering
> the timeout for an actually stuck build process). In line of principle
> even the current situation can somewhat be tolerated, since it is enough
> to reschedule the build until it gets a strong machine. However, that
> does not seem optimal.

Yeah, it's not.

Some questions which may help solve this:

- What is happening when the build hangs? Is xsltproc still running, just being
too slow / taking way too long?
- Note that the inactivity timeout gets triggered only if there are no new lines
printed in the timeout period. So can xsltproc or whatever is getting killed be
made more verbose?
- Is this just generating documentation? The -doc package is architecture: all,
can't we just skip building the docs on binary-arch builds?

Cheers,
Emilio

Bug#913709: boost1.67: intermitent FTBFS on mips64el: build hangs

[Emilio Pozuelo Monfort]

Source: boost1.67
Version: 1.67.0-9
Severity: serious

Hi,

Your package fails to build quite often on mips64el, where the build gets
killed due to inactivity:

Cannot find class named 'action'
Cannot find class named 'action'
Cannot find class named 'file-target'
Cannot find class named 'generator'
Cannot find class named 'generator'
Cannot find class named 'std::bad_cast'
E: Build killed with signal TERM after 150 minutes of inactivity

This  may be due to an actual hang, or something just taking so long
that causes the build to get killed.

Cheers,
Emilio

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#913601: ceph: FTBFS on mips/el: /usr/include/c++/8/bits/atomic_base.h:304: undefined reference to `__atomic_fetch_sub_8'

[Emilio Pozuelo Monfort]

Source: ceph
Version: 12.2.8+dfsg1-2
Severity: serious
Tags: ftbfs

Your package failed to build on mips/el:

/usr/bin/ld: CMakeFiles/ceph-mgr.dir/mgr/DaemonServer.cc.o: in function 
`RefCountedObject::~RefCountedObject()':
/usr/include/c++/8/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/bin/ld: CMakeFiles/ceph-mgr.dir/mgr/DaemonServer.cc.o: in function 
`RefCountedObject::~RefCountedObject()':

You may need to link with -latomic.

Full logs at https://buildd.debian.org/status/package.php?p=ceph

Emilio

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

On 02/10/2018 17:33, Emilio Pozuelo Monfort wrote:
> On 02/10/2018 17:26, Sylvestre Ledru wrote:
>> Le 02/10/2018 à 16:55, John Paul Adrian Glaubitz a écrit :
>>> On 10/2/18 4:53 PM, Sylvestre Ledru wrote:
>>>>> Can you open bug reports against llvm-toolchain-6.0 and llvm-toolchain-7 
>>>>> to
>>>>> make sure, the fix gets backported?
>>>> I would prefer that rustc uses llvm 7 instead of 6.
>>>
>>> What is the current progress with this upstream? I have not followed
>>> up on this part? Sure, I prefer LLVM 7 as well. But as long as Rust
>>> upstream is not ready yet, we have to stick with what we have.
>>
>> Looks like it is what we are using in experimental
>> https://tracker.debian.org/news/990088/accepted-rustc-1300beta7dfsg1-1exp2-source-into-experimental/
> 
> Can you backport the llvm fix to llvm 7?

Actually given 7 is not in testing and rust is not using it atm, what would be
good is to have this backported to llvm 6 asap, so that we can (hopefully) get
rust bootstrapped in mips*, which is blocking quite some stuff.

Thanks,
Emilio

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

On 02/10/2018 17:26, Sylvestre Ledru wrote:
> Le 02/10/2018 à 16:55, John Paul Adrian Glaubitz a écrit :
>> On 10/2/18 4:53 PM, Sylvestre Ledru wrote:
 Can you open bug reports against llvm-toolchain-6.0 and llvm-toolchain-7 to
 make sure, the fix gets backported?
>>> I would prefer that rustc uses llvm 7 instead of 6.
>>
>> What is the current progress with this upstream? I have not followed
>> up on this part? Sure, I prefer LLVM 7 as well. But as long as Rust
>> upstream is not ready yet, we have to stick with what we have.
> 
> Looks like it is what we are using in experimental
> https://tracker.debian.org/news/990088/accepted-rustc-1300beta7dfsg1-1exp2-source-into-experimental/

Can you backport the llvm fix to llvm 7?

Thanks,
Emilio

Re: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

Hi Adrian,

On 28/05/18 10:33, John Paul Adrian Glaubitz wrote:
> On 05/28/2018 08:52 AM, Emilio Pozuelo Monfort wrote:
>> Any progress on these issues? I see that rust built on mips64el but it now
>> hangs. And mips/el are still uncompiled.
> 
> I have not been able to build rustc natively on mips/mipsel because the 
> process
> always runs out of memory when I try on minkus and eller.
> 
> I tried the workaround from [1] to disable debuginfo for the standard library
> but that didn't help either.

Ok. I wonder if there are other options for us here. At what point does it run
out of memory? Do you have a log?

BTW mips64el is failing to build on the buildds. It only built there once, on
eberlin. Is that the only mips64el buildd with an FPU? That could explain the
timeouts.

Cheers,
Emilio

Re: Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

On 02/02/18 13:14, James Cowgill wrote:
> Hi,
> 
> On 11/01/18 20:16, Emilio Pozuelo Monfort wrote:
>> On 17/11/17 13:25, James Cowgill wrote:
>>> Hi,
>>>
>>> On 15/11/17 17:30, Emilio Pozuelo Monfort wrote:
>>>> Source: rustc
>>>> Version: 1.21.0+dfsg1-3
>>>> Severity: important
>>>>
>>>> Hi,
>>>>
>>>> Sometime ago I asked about rustc bootstrap status on mips*:
>>>>
>>>> 17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, 
>>>> i didn't want to ship it, i haven't had time to check since
>>>>
>>>> >From 
>>>> >https://buildd.debian.org/status/fetch.php?pkg=rustc=mips=1.14.0%2Bdfsg1-3=1484077706=0
>>>>
>>>> test net::tcp::tests::timeouts ... FAILED
>>>> test net::udp::tests::timeouts ... FAILED
>>>> test sys::imp::ext::net::test::timeouts ... FAILED
>>>>
>>>> Looks like timeouts are broken on rust/mips?
>>>>
>>>> mips64el has different errors:
>>>>
>>>> test f32::f32::tanh_0 ... FAILED
>>>> test f64::f64::tanh_0 ... FAILED
>>>> test io::error::Error::from_raw_os_error_0 ... FAILED
>>>>
>>>> Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
>>>> errors are for 1.14.0, you'll want to try with a newer version first and
>>>> see what's the current status.
>>>
>>> I just tried building the latest rustc on mips64el. As I expected, I hit
>>> this LLVM bug again where any code using atomics will hang:
>>>
>>> https://bugs.llvm.org/show_bug.cgi?id=32020
>>>
>>> I'll see if I can get Simon to have a look at it again.
>>
>> FTR:
>>
>> According to our conversation over IRC, there's a patch for the above bug, 
>> but
>> mips64el is now affected by https://github.com/rust-lang/rust/issues/47290
>>
>> mips(el) may be fine now with that patch, or they may not :P
> 
> I have been looking at the state of rust support on mips over the last
> weeks or so. These are the major issues:
> 
> Hanging atomics (mips, mipsel, mips64el)
> 
> This is an LLVM bug which happens on all mips.
> 
> https://github.com/rust-lang/rust/issues/39013
> https://bugs.llvm.org/show_bug.cgi?id=32020
> 
> I have attached the most recent iteration of Simon's LLVM fix for this
> along with some of my adjustments to it and a backport to LLVM 4.0 I
> used for testing with rust.
> 
> LLVM 128-bit integer isues (mips, mipsel)
> 
> 128-bit integer arithmetic is broken in LLVM 4 on 32-bit MIPS. This has
> been fixed in LLVM 5. Unfortunately this bug has caused the upstream
> stage0 compiler to break badly so you may need to apply the fix and
> cross build your own stage0 until upstream binaries have moved to LLVM >= 5.
> 
> https://github.com/rust-lang/rust/issues/41222
> https://bugs.llvm.org/show_bug.cgi?id=32713
> https://reviews.llvm.org/rL305389
> 
> llvm.powi.f64 broken (mips64el)
> 
>>>> test f32::f32::tanh_0 ... FAILED
>>>> test f64::f64::tanh_0 ... FAILED
> 
> This is caused by the llvm.powi.f64 intrinsic being broken for negative
> powers. Thankfully this is not a very serious bug.
> 
> Fixed here:
> https://bugs.llvm.org/show_bug.cgi?id=36061
> https://reviews.llvm.org/D42537
> 
> No 64-bit Rust ABI support (mips64el)
> 
> The biggest issue with Rust itself is the lack of working FFI support
> for 64-bit mips.
> 
> My attempt at implementing this:
> https://github.com/rust-lang/rust/issues/47290
> https://github.com/rust-lang/rust/pull/47964
> 
> Other issues
> 
>>>> test net::tcp::tests::timeouts ... FAILED
>>>> test net::udp::tests::timeouts ... FAILED
>>>> test sys::imp::ext::net::test::timeouts ... FAILED
> 
> As I wrote in https://github.com/rust-lang/rust/issues/39013, these are
> big endian specific. I haven't had the chance to test rust on big endian
> yet.
> 
>>>> test io::error::Error::from_raw_os_error_0 ... FAILED
> 
> Fixed in https://github.com/rust-lang/rust/pull/47874
> 
> Some FPU errors only happen on Loongson. In theory, enabling FPXX in
> LLVM should have fixed this, but I have not investigated it very far.
> 
> There are a few other failing tests where the test itself is broken. I
> will try to submit fixes to ignore / adjust the tests soon.

Any progress on these issues? I see that rust built on mips64el but it now
hangs. And mips/el are still uncompiled.

Cheers,
Emilio

Re: Bug#895193: transition: openmpi

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 11/04/18 11:12, Alastair McKinstry wrote:
> 
> 
> On 11/04/2018 10:07, John Paul Adrian Glaubitz wrote:
>> On 04/11/2018 10:53 AM, Alastair McKinstry wrote:
>>> As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a
>>> problem; it had been dropped upstream because of an unknown bug, now
>>> fixed).
>>
>> Oh, really, they fixed that? I already had given up hopes and
>> therefore ignored
>> the thread on github out of frustration.
>>
>>From the thread (and related PRs it references) its fixed and works as
> long as -O3 is used.
> I've implemented and tested this in ./rules.
> 
>>> The other non-release archs were failing due to missing dependencies: in
>>> particular java support (not used by any package in stable/testing) and
>>> pmix (new; not used in testing/stable; pmix enables scaling to ~100,000+
>>> nodes, which is unlikely to be needed).
>>
>> I am working on fixing the remaining OpenJDK issues. I'm an upstream
>> committer in the OpenJDK project, so I can commit all changes myself.
>>
> Ok. I've just disabled support as necessary for archs with openjdk issues.
> While a riscv64 build has not yet occurred (awaiting in queue to see),
> all issues on all other archs should now be resolved,
> making the transition possible.

Great. Please go ahead.

Cheers,
Emilio

Re: Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

On 17/11/17 13:25, James Cowgill wrote:
> Hi,
> 
> On 15/11/17 17:30, Emilio Pozuelo Monfort wrote:
>> Source: rustc
>> Version: 1.21.0+dfsg1-3
>> Severity: important
>>
>> Hi,
>>
>> Sometime ago I asked about rustc bootstrap status on mips*:
>>
>> 17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, i 
>> didn't want to ship it, i haven't had time to check since
>>
>> >From 
>> >https://buildd.debian.org/status/fetch.php?pkg=rustc=mips=1.14.0%2Bdfsg1-3=1484077706=0
>>
>> test net::tcp::tests::timeouts ... FAILED
>> test net::udp::tests::timeouts ... FAILED
>> test sys::imp::ext::net::test::timeouts ... FAILED
>>
>> Looks like timeouts are broken on rust/mips?
>>
>> mips64el has different errors:
>>
>> test f32::f32::tanh_0 ... FAILED
>> test f64::f64::tanh_0 ... FAILED
>> test io::error::Error::from_raw_os_error_0 ... FAILED
>>
>> Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
>> errors are for 1.14.0, you'll want to try with a newer version first and
>> see what's the current status.
> 
> I just tried building the latest rustc on mips64el. As I expected, I hit
> this LLVM bug again where any code using atomics will hang:
> 
> https://bugs.llvm.org/show_bug.cgi?id=32020
> 
> I'll see if I can get Simon to have a look at it again.

FTR:

According to our conversation over IRC, there's a patch for the above bug, but
mips64el is now affected by https://github.com/rust-lang/rust/issues/47290

mips(el) may be fine now with that patch, or they may not :P

Cheers,
Emilio

Bug#886222: ld.gold: internal error in get_got_page_offset, at ../../gold/mips.cc:6271

[Emilio Pozuelo Monfort]

Source: binutils
Version: 2.29.1-12
Severity: important
Control: affects -1 ghc

Hi,

gold segfaults when building ghc 8.2.2-1 on mips*:

https://buildd.debian.org/status/logs.php?pkg=ghc=8.2.2-1

Gianfranco tried with binutils 2.29.51.20171218-1 as well and that failed too.
Unfortunately he cleaned the build directory afterwards, so we don't have any
files to attach to reproduce this, not atm. I guess that should be the next
step.

Emilio

Re: Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

On Fri, 17 Nov 2017 12:25:35 + James Cowgill <jcowg...@debian.org> wrote:
> Hi,
> 
> On 15/11/17 17:30, Emilio Pozuelo Monfort wrote:
> > Source: rustc
> > Version: 1.21.0+dfsg1-3
> > Severity: important
> > 
> > Hi,
> > 
> > Sometime ago I asked about rustc bootstrap status on mips*:
> > 
> > 17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, 
> > i didn't want to ship it, i haven't had time to check since
> > 
> >>From 
> >>https://buildd.debian.org/status/fetch.php?pkg=rustc=mips=1.14.0%2Bdfsg1-3=1484077706=0
> > 
> > test net::tcp::tests::timeouts ... FAILED
> > test net::udp::tests::timeouts ... FAILED
> > test sys::imp::ext::net::test::timeouts ... FAILED
> > 
> > Looks like timeouts are broken on rust/mips?
> > 
> > mips64el has different errors:
> > 
> > test f32::f32::tanh_0 ... FAILED
> > test f64::f64::tanh_0 ... FAILED
> > test io::error::Error::from_raw_os_error_0 ... FAILED
> > 
> > Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
> > errors are for 1.14.0, you'll want to try with a newer version first and
> > see what's the current status.
> 
> I just tried building the latest rustc on mips64el. As I expected, I hit
> this LLVM bug again where any code using atomics will hang:
> 
> https://bugs.llvm.org/show_bug.cgi?id=32020
> 
> I'll see if I can get Simon to have a look at it again.

Any luck there? (I don't see a ping on the bug report).

librsvg is now using rustc. We're stuck with an old version for now, but when we
upgrade to the rust version, I wouldn't want to have to remove it, along with
all the rdeps, from a bunch of architectures... Hence my insistence :)

Cheers,
Emilio

Bug#881845: rustc: FTBFS on mips*: test failures

[Emilio Pozuelo Monfort]

Source: rustc
Version: 1.21.0+dfsg1-3
Severity: important

Hi,

Sometime ago I asked about rustc bootstrap status on mips*:

17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, i 
didn't want to ship it, i haven't had time to check since

>From 
>https://buildd.debian.org/status/fetch.php?pkg=rustc=mips=1.14.0%2Bdfsg1-3=1484077706=0

test net::tcp::tests::timeouts ... FAILED
test net::udp::tests::timeouts ... FAILED
test sys::imp::ext::net::test::timeouts ... FAILED

Looks like timeouts are broken on rust/mips?

mips64el has different errors:

test f32::f32::tanh_0 ... FAILED
test f64::f64::tanh_0 ... FAILED
test io::error::Error::from_raw_os_error_0 ... FAILED

Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
errors are for 1.14.0, you'll want to try with a newer version first and
see what's the current status.

Emilio

Re: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory

[Emilio Pozuelo Monfort]

On 29/12/16 20:56, Gaudenz Steinlin wrote:
> 
> Hi Emilio
> 
> Emilio Pozuelo Monfort <po...@debian.org> writes:
> 
>> Source: ceph
>> Version: 10.2.5-2
>> Severity: serious
>>
>> Your package failed to build on mips/el:
>>
>> g++ -DHAVE_CONFIG_H -I.  -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE 
>> -D__STDC_FORMAT_MACROS -D_GNU_SOURCE 
>> -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" 
>> -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" 
>> -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT-Wdate-time -D_FORTIFY_SOURCE=2 
>> -I/usr/include/nss -I/usr/include/nspr  -Wall -Wtype-limits 
>> -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
>> -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 
>> -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall 
>> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
>> --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong  
>> -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>> tools/rbd/action/Resize.o tools/rbd/action/Resize.cc
>> virtual memory exhausted: Cannot allocate memory
>> Makefile:24792: recipe for target
>> 'test/encoding/ceph_dencoder-ceph_dencoder.o' failed
> 
> I already noticed this and tried to contact m...@buildd.debian.org and
> mip...@buildd.debian.org. Unfortunately nobody responded yet, so I don't
> know if the message was even received or not. AFAIK these are the
> correct contact points for buildd issues.

This is not a buildd issue but a porting issue. debian-mips@ldo is better for
this. Added to Cc.

> I don't think there is much I can do about this bug and I'm not
> convinced this is a issue in ceph. If the buildds are unable to build
> the package we can either completely remove ceph for mips/mipsel or try
> to only build the client part and have a reduced set of packages on
> these architectures.

IIRC there are some flags you can pass to reduce memory usage. Most notably
ggc-min-expand (which is going to be changed in GCC itself, but afaik it hasn't
happened yet). So you could try adding

--param ggc-min-expand=10

to CFLAGS/CXXFLAGS.

I'd try that before thinking about removing the package from mips.

Cheers,
Emilio

> The second option would have the advantage that no changes to the
> reverse dependencies (notably qemu) are needed.
> 
> Gaudenz
> 

Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table

[Emilio Pozuelo Monfort]

On Tue, 22 Nov 2016 11:46:33 + James Cowgill  wrote:
> Control: tags -1 patch
> 
> Hi,
> 
> On 18/11/16 23:39, James Cowgill wrote:
> > On 16/11/16 17:15, James Cowgill wrote:
> >> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828
> >>
> >> Hi,
> >>
> >> I've submitted the bug upstream with a reduced testcase and a bisection.
> >>
> >> As the bug requires -Wl,--gc-sections to occur, it may be possible to
> >> workaround in mesa by recompiling without it.
> > 
> > I have attached two patches:
> > 
> > binutils-pr20828-v1.patch attempts to fix the underlying issue in
> > binutils where local symbols appear intermixed with global symbols. It
> > does this by applying another pass over the symbol table to assign all
> > the local symbol indexes first, then ignoring local symbols in the
> > second pass. This seems to fix my testcase and mesa, although I am not
> > 100% sure of it and I would like to get some feedback from upstream as
> > well since I don't really do much work with binutils.
> 
> I think the breakage is too much to wait any longer, so please can you
> apply this patch to binutils so we can start recovering from all this.

Can any other mips* porter review this? Bonus points if you comment on the
upstream bug so that it can (eventually) get merged upstream.

Thanks,
Emilio

Re: [Debian-med-packaging] Bug#834856: python-pysam fails to build on mips64el arch.: failed test

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Fri, 19 Aug 2016 22:29:48 -0700 Afif Elghraoui  wrote:
> Control: severity -1 important
> Control: tag -1 + help
> 
> Hello and thank you for the report.
> 
> على الجمعـة 19 آب 2016 ‫14:48، كتب Jonathan Jackson:
> > Package: python-pysam
> > Version: 0.9.1.4+ds-1
> > Severity: grave
> > Justification: renders package unusable
> > 
> 
> While the package may be unusable on mips64el, it works well for the
> vast majority of users as I understand it, so this situation deserves a
> severity of 'important' rather than 'grave'.

mips64el is a release architecture, thus this bug is serious.

> > Python-pysam packages failed to build on March 24th on a mips64el 
> > architecture. Here is the tail of the failed-build log:
> > 
> [...]
> 
> I'd be happy to apply any patch that resolves this problem, but porting
> work is beyond what I can commit to do for this package.

Cc'ing debian-mips, maybe they can provide some help.

Cheers,
Emilio

Bug#832824: haskell-src-exts: fails to build on mips64el: ghc_8.hc:(.text+0x10c): relocation truncated to fit: R_MIPS_GOT_DISP against `stg_ap_0_fast'

[Emilio Pozuelo Monfort]

Source: haskell-src-exts
Version: 1.17.1-1
Severity: serious

Your package has been failing to build on mips64el for a while now:

https://buildd.debian.org/status/logs.php?pkg=haskell-src-exts=mips64el

>From the last two logs:

[22 of 24] Compiling Language.Haskell.Exts.Parser ( 
src/Language/Haskell/Exts/Parser.hs, 
dist-ghc/build/Language/Haskell/Exts/Parser.p_o )
[23 of 24] Compiling Language.Haskell.Exts.Annotated ( 
src/Language/Haskell/Exts/Annotated.hs, 
dist-ghc/build/Language/Haskell/Exts/Annotated.p_o )
[24 of 24] Compiling Language.Haskell.Exts ( src/Language/Haskell/Exts.hs, 
dist-ghc/build/Language/Haskell/Exts.p_o )
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`c66jH_entry':
ghc_8.hc:(.text+0x10c): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_ap_0_fast'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`c66jZ_entry':
ghc_8.hc:(.text+0x18c): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_ap_0_fast'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`s5G5u_entry':
ghc_8.hc:(.text+0x1b4): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_upd_frame_info'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`c66xW_entry':
ghc_8.hc:(.text+0x32c): relocation truncated to fit: R_MIPS_GOT_DISP against 
`base_GHCziNum_zp_entry'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`s5G5A_entry':
ghc_8.hc:(.text+0x364): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_upd_frame_info'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`haskezu4FklJxiwJoAI0XtFimUoU7_LanguageziHaskellziExtsziAnnotatedziSyntax_zdfFoldableAnnotation7_entry':
ghc_8.hc:(.text+0x500): relocation truncated to fit: R_MIPS_GOT_DISP against 
`ghczmprim_GHCziTypes_False_closure'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`s5G5Z_entry':
ghc_8.hc:(.text+0x630): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_upd_frame_info'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`s5G62_entry':
ghc_8.hc:(.text+0x6b0): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_upd_frame_info'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`s5G63_entry':
ghc_8.hc:(.text+0x730): relocation truncated to fit: R_MIPS_GOT_DISP against 
`stg_upd_frame_info'
dist-ghc/build/Language/Haskell/Exts/Annotated/Syntax.dyn_o: In function 
`c66Al_entry':
ghc_8.hc:(.text+0x884): relocation truncated to fit: R_MIPS_GOT_DISP against 
`base_GHCziNum_zp_entry'
ghc_8.hc:(.text+0x8e4): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status

I'm cc'ing debian-mips@ in case they have some insight.

Cheers,
Emilio

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 04/07/16 07:35, Aurelien Jarno wrote:
> On 2016-06-16 10:25, Aurelien Jarno wrote:
>> On 2016-06-16 02:12, Hector Oron wrote:
  * mips64el (NEW)
- No DSA buildd (RT blocker)
>>>
>>> As far as I can see mips64el is using shared builds with mipsel port
>>> hardware, those machines are DSA.
>>
>> We also have the confirmation that the UTM-8 machines sent by
>> Imagination Technologies have arrived at MAN-DA and SIL about one month
>> ago. They still need to be racked and installed.
>>
- Rebuild after import not complete (RT Blocker)
>>>
>>> Is there a list of packages that should be rebuilt?
>>
>> It is available here:
>>
>>   https://ftp-master.debian.org/users/mhy/mipsel64import.txt
>>
>> There is only a single package: db5.3. It is currently not buildable as
>> the ecj package doesn't build. The ecj java bytecode is not executed
>> correctly by gij. We have made some progress on this recently with a
>> simple reproducer not involving ecj. Matthew Fortune from Imagination
>> Technologies is currently working on that currently and has already
>> found that it is due to a sign extension issue at the JIT'd/FFI layer.
>> I therefore expect a solution a solution soon.
> 
> The latest gcc-5 and gcc-6 uploads include the patch fixing this issue.
> I have bootstrapped ecj and uploaded it to the archive yesterday. From
> there things went well and db5.3 has been built successfully.
> 
> Therefore the above list is now empty.

Brilliant. We will start the testing bootstrap soon.

Cheers,
Emilio

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

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

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

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

Sure, that's fine.

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

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

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

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

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

I have added you two as armel porters.

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

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

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

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

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

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

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

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

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

That's sorted out now.

Cheers,
Emilio

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

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

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

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

Emilio

Re: mips fpu hw

[Emilio Pozuelo Monfort]

On 06/04/16 10:39, Aurelien Jarno wrote:
> On 2016-03-11 19:11, Emilio Pozuelo Monfort wrote:
>> Hi,
> 
> Hi,
> 
>> It's been a long while that I have been asking on #debian-buildd about some
>> mips buildds with a floating point unit, and the answer has always been "it
>> will happen soon".
>>
>> Currently this state of affairs causes some packages to take several *days*
>> to build.
>>
>> So what's the status of this? Is there anything blocking this? Is there no
>> modern mips hardware with a fpu, like we used to have?
> 
> A first machine with FPU have been installed yesterday in AQL and called
> mips-aql-06. It has successfully built packages using floating point
> which failed to build before:
> - babl is now built in 27 minutes instead of getting killed after 12h
>   due to timeout [1]
> - chealpix is now built in 10 min instead of getting killed after 12h
>   due to timeout [2]
> - healpix-cxx is now built in 1h09 instead of getting killed after 78h
>   of timeout [3]
> 
> In addition it has 4 cores instead of 2 cores on the previous machines,
> so it builds package with parallel=n faster:
> - samba is now built in 1h23 instead of 2h37 due to the additional
>   cores [4]. 
> 
> More machines will be installed later so that we have full buildd
> redundancy.

Great news!

Thanks,
Emilio

mips fpu hw

[Emilio Pozuelo Monfort]

Hi,

It's been a long while that I have been asking on #debian-buildd about some mips 
buildds with a floating point unit, and the answer has always been "it will 
happen soon".


Currently this state of affairs causes some packages to take several *days* to 
build.


So what's the status of this? Is there anything blocking this? Is there no 
modern mips hardware with a fpu, like we used to have?


Cheers,
Emilio

Re: mips64el in testing

[Emilio Pozuelo Monfort]

On 06/03/16 01:21, Aurelien Jarno wrote:

On 2016-03-05 17:40, Emilio Pozuelo Monfort wrote:

Hi,


Hi,


So mips64el got into unstable on ftpmaster a while ago. I suppose you would like
for it to get into testing and released with Stretch. Is that right?


Yes, that is right.


If so, db5.3 needs to get built, as that's the last package that got imported
and hasn't been rebuilt since:

https://ftp-master.debian.org/users/mhy/mipsel64import.txt


Ok, we'll look at this one.


Also, it'd be good if you could give us information on what the status of the
port is, e.g. upstream support on the kernel, libc and toolchain, what DDs / DMs
are behind the port, etc.


The mips64el port is the natural evolution of the mipsel port,
following the tendency of all architectures to go to 64 bits. This
breaks the 2GiB virtual memory limit from 32-bit MIPS, which
unfortunately is triggered more and more often on the build daemons.
At the same time this port also takes the opportunity to increase the
required instruction set from MIPS II to MIPS64R2 for a better use of
the hardware. This port we'll eventually replaces the mipsel port,
though we don't have any plan to drop it yet.

The upstream support is basically the same than for 32-bit MIPS. MIPS
hardware is 64-bit capable for a lot of time, and in fact all the Debian
build daemons and porterboxes have been running a 64-bit kernel for more
than 10 years. There is no change on that side. The 64-bit toolchain was
already available in the mipsel port using the tri-arch libraries.

The Debian Developers (Cc:ed) behind this port are:
- Andi Barth <a...@debian.org>
- Anibal Monsalve Salazar <ani...@debian.org>
- Aurelien Jarno <aure...@debian.org>
- Aron Xu <a...@debian.org>
- James Cowgill <jcowg...@debian.org>
- Yunqiang Su <s...@debian.org>
In addition there are regular help from non-DD people from Imagination
Technologies.

The port itself is in a good shape, that said we are still lacking DSAed
build daemons (and thus autosigning). It is built mostly on 4 machines,
3 hosted in China by Aron Xu and 1 hosted in Germany by Andi Barth. In
addition the mipsel build daemons also build mips64el packages as the
lowest priority. The porterbox etler.d.o has both mipsel and mips64el
chroots. We are waiting for Octeon III hardware sponsored by Imagination
Technologies that will be used for the 3 MIPS ports (they are able to
boot on both endianness). That is the last blocker on our side and that
is why we haven't requested to get mips64el into testing yet.


Thanks for the update. I have updated 
https://release.debian.org/stretch/arch_qualify.html with this information.


Indeed getting some hardware administered by DSA would be a requirement. Also 
getting the final package rebuilt, as I indicated.


Please let us know when those issues get sorted out.

Cheers,
Emilio

mips64el in testing

[Emilio Pozuelo Monfort]

Hi,

So mips64el got into unstable on ftpmaster a while ago. I suppose you would like
for it to get into testing and released with Stretch. Is that right?

If so, db5.3 needs to get built, as that's the last package that got imported
and hasn't been rebuilt since:

https://ftp-master.debian.org/users/mhy/mipsel64import.txt

Also, it'd be good if you could give us information on what the status of the
port is, e.g. upstream support on the kernel, libc and toolchain, what DDs / DMs
are behind the port, etc.

Cheers,
Emilio

Re: binNMUs: please exercise some care

[Emilio Pozuelo Monfort]

On 23/10/15 13:21, Emilio Pozuelo Monfort wrote:
> On 23/10/15 13:02, Thorsten Glaser wrote:
>> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
>>
>>> wanna-build does, yes, but at least the Release Team tend to use the "wb"
>>> wrapper tool which automatically works out the next free number on each
>>> architecture.
>>
>> Ah, cool – so we have only to patch this tool to automatically
>> use the highest number per batch on all affected architectures
>> (or even to use the highest number if all architectures would
>> be touched, but that’s probably an unreasonable amount of code
>> change).
> 
> Sorry, aren't you saying the same thing in both cases? If not, can you 
> rephrase
> or expand that?
> 
>> Where’s the source code to that tool?
> 
> https://anonscm.debian.org/cgit/mirror/release-tools.git/tree/scripts/wb
> 
> Please open a bug report against release.debian.org when submitting a patch.

OTOH, I'm not sure this fix is appropriate. It just feels like a workaround for
a dpkg bug, which would be better fixed in dpkg itself.

This won't help when we have to schedule a binNMU on one or two architectures
and not all of them.

Emilio

Re: binNMUs: please exercise some care

[Emilio Pozuelo Monfort]

On 23/10/15 13:02, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> 
>> wanna-build does, yes, but at least the Release Team tend to use the "wb"
>> wrapper tool which automatically works out the next free number on each
>> architecture.
> 
> Ah, cool – so we have only to patch this tool to automatically
> use the highest number per batch on all affected architectures
> (or even to use the highest number if all architectures would
> be touched, but that’s probably an unreasonable amount of code
> change).

Sorry, aren't you saying the same thing in both cases? If not, can you rephrase
or expand that?

> Where’s the source code to that tool?

https://anonscm.debian.org/cgit/mirror/release-tools.git/tree/scripts/wb

Please open a bug report against release.debian.org when submitting a patch.

Cheers,
Emilio

Re: binNMUs: please exercise some care

[Emilio Pozuelo Monfort]

On 23/10/15 12:23, Wookey wrote:
> +++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]:
>> On 23/10/15 11:20, Thorsten Glaser wrote:
> 
>>> How about, scheduling them all at once, but using the same version
>>> number across arches when doing it (i.e. the largest)?
>>
>> Again, that involves determining what that number is for each package...
> 
> That is a single-page lookup, though, so only one lookup, not one for
> each arch e.g: https://buildd.debian.org/status/package.php?p=harfbuzz

I didn't say once per arch. I said once per package, which is worse. I normally
schedule binNMUs for several dozens packages. Multiply that by several
transitions... Sorry but I'm not going to do that.

>> Instead of all that manual work for every transition, you could ping
>> #758616 and try to get this solved at its root.
> 
> It would clearly be better if we either did sourceful rebuilds or
> fixed the 'binNMU skew' problem. But we do need to do something
> reasonably soon otherwise it's not going to be ready for Stretch
> either.

Ping the dpkg bug? :)

Emilio

Re: binNMUs: please exercise some care

[Emilio Pozuelo Monfort]

[ Sorry for the cross-post, but I believe the people in -release and -wb-team
should see this ]

On 23/10/15 09:05, Thorsten Glaser wrote:
> Hi,
> 
> whoever is scheduling binNMUs now should do so with a little
> bit more care, please.
> 
> Case in point, frameworkintegration – x32 already was rebuilt
> against the new Qt API and did not need the additional binNMU.

That one was me. This is what I did:

wb nmu fcitx-qt5 frameworkintegration gcin hime kwin libqtxdg lxqt-qtplugin
qtcurve calibre . ANY . -m "Rebuild against qtbase-abi-5-5-1." --extra-depends
"libqt5core5a (>= 5.5.1)"

I can go back to scheduling binNMUs for release architectures only, or for ANY
-x32. But I don't have the time to look at every architecture and determine
which one needs a binNMU and which one has already done it. Anyway if your
buildds are fast enough that they already rebuilt things, then maybe rebuilding
them again is not such a big deal...

Maybe when the transition tracker suggests commands to schedule binNMUs
(something I want to implement) it can do so for affected architectures only.

> Case in point, some OCaml binNMUs were done recently (within
> the last month), to rebuild against the new compiler version,
> but that version was not yet built on m68k. (You can set
> extra Build-Depends and use that to version them, to make
> sure that, while you have the comfort of scheduling them
> all at once instead of in several batches, they only happen
> after their prerequisite has been done.)

That wasn't me. But I'll try to spread the word about --extra-depends, as I
agree it's useful to avoid this. I didn't use it much in the past when I just
used to wait for all architectures in wanna-build to build. But now that we got
all the ports, it's a good way to schedule things just once without having to
wait for every port.

Cheers,
Emilio

Bug#760865: calibre: FTBFS on mips: thread.error: can't start new thread

[Emilio Pozuelo Monfort]

Source: calibre
Version: 2.0.0+dfsg-1
Severity: serious

Your package has failed to build on mips since version 2.0.0:

### Building extension freetype ###
Compiling freetype
Traceback (most recent call last):
  File setup.py, line 99, in module
sys.exit(main())
  File setup.py, line 85, in main
command.run_all(opts)
  File /«BUILDDIR»/calibre-2.2.0+dfsg/setup/__init__.py, line 181, in run_all
self.run_cmd(self, opts)
  File /«BUILDDIR»/calibre-2.2.0+dfsg/setup/__init__.py, line 178, in run_cmd
cmd.run(opts)
  File /«BUILDDIR»/calibre-2.2.0+dfsg/setup/extensions.py, line 397, in run
self.build(ext, dest)
  File /«BUILDDIR»/calibre-2.2.0+dfsg/setup/extensions.py, line 441, in build
if not parallel_build(jobs, self.info):
  File /«BUILDDIR»/calibre-2.2.0+dfsg/setup/parallel_build.py, line 32, in 
parallel_build
p = Pool(cpu_count)
  File /usr/lib/python2.7/multiprocessing/dummy/__init__.py, line 151, in Pool
return ThreadPool(processes, initializer, initargs)
  File /usr/lib/python2.7/multiprocessing/pool.py, line 718, in __init__
Pool.__init__(self, processes, initializer, initargs)
  File /usr/lib/python2.7/multiprocessing/pool.py, line 159, in __init__
self._repopulate_pool()
  File /usr/lib/python2.7/multiprocessing/pool.py, line 223, in 
_repopulate_pool
w.start()
  File /usr/lib/python2.7/multiprocessing/dummy/__init__.py, line 75, in start
threading.Thread.start(self)
  File /usr/lib/python2.7/threading.py, line 745, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
make: *** [common-build-arch] Error 1
debian/rules:14: recipe for target 'common-build-arch' failed
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Full logs at:

https://buildd.debian.org/status/logs.php?pkg=calibrearch=mips


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140908160754.6602.10654.reportbug@titan

Re: webkit build failure on mipsel

[Emilio Pozuelo Monfort]

On 19/06/13 01:47, Aurelien Jarno wrote:
 On Mon, Jun 17, 2013 at 07:42:51PM +0200, Emilio Pozuelo Monfort wrote:
 Hi,

 webkit is failing to build on mipsel[1] with:

 /bin/sh ./libtool  --tag=CXX   --mode=link g++ -fno-strict-aliasing -fno-rtti
 -D_FORTIFY_SOURCE=2 -D_REENTRANT  -I/usr/include  -O2 -Wformat
 -Werror=format-security -Wall -Wl,--as-needed -Wno-c++0x-compat -O2
 -Wl,-z,relro -Wl,--no-keep-memory -o Programs/jsc-1
 Source/JavaScriptCore/Programs_jsc_1-jsc.o -lpthread 
 libjavascriptcoregtk-1.0.la
 libtool: link: g++ -fno-strict-aliasing -fno-rtti -D_FORTIFY_SOURCE=2
 -D_REENTRANT -I/usr/include -O2 -Wformat -Werror=format-security -Wall
 -Wl,--as-needed -Wno-c++0x-compat -O2 -Wl,-z -Wl,relro -Wl,--no-keep-memory 
 -o
 Programs/.libs/jsc-1 Source/JavaScriptCore/Programs_jsc_1-jsc.o  -lpthread
 ./.libs/libjavascriptcoregtk-1.0.so -pthread
 /usr/bin/ld: 
 /usr/lib/gcc/mipsel-linux-gnu/4.6/../../../mipsel-linux-gnu/crt1.o:
 undefined reference to symbol '_gp'
 /usr/lib/mipsel-linux-gnu/libicui18n.so.48: error adding symbols: DSO missing
 from command line
 collect2: ld returned 1 exit status

 This looks suspiciously similar to [3]. Note however that it built fine on
 mips[2]. Both builds used the default compiler (gcc/g++ 4.6) and had libc6
 2.17-3. However mips had binutils 2.22-8 while mipsel had 2.23.52.20130612-1.
 Per the followups to [3] and per [4], I guess this is some binutils/eglibc 
 mismatch?

 
 The problem has been fixed in the latest eglibc upload and the chroots
 upgraded. I have requeued webkit on mipsel, I hope it will built
 successfully this time.

So do I!

Thank you,
Emilio


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c17667.6070...@debian.org

webkit build failure on mipsel

[Emilio Pozuelo Monfort]

Hi,

webkit is failing to build on mipsel[1] with:

/bin/sh ./libtool  --tag=CXX   --mode=link g++ -fno-strict-aliasing -fno-rtti
-D_FORTIFY_SOURCE=2 -D_REENTRANT  -I/usr/include  -O2 -Wformat
-Werror=format-security -Wall -Wl,--as-needed -Wno-c++0x-compat -O2
-Wl,-z,relro -Wl,--no-keep-memory -o Programs/jsc-1
Source/JavaScriptCore/Programs_jsc_1-jsc.o -lpthread libjavascriptcoregtk-1.0.la
libtool: link: g++ -fno-strict-aliasing -fno-rtti -D_FORTIFY_SOURCE=2
-D_REENTRANT -I/usr/include -O2 -Wformat -Werror=format-security -Wall
-Wl,--as-needed -Wno-c++0x-compat -O2 -Wl,-z -Wl,relro -Wl,--no-keep-memory -o
Programs/.libs/jsc-1 Source/JavaScriptCore/Programs_jsc_1-jsc.o  -lpthread
./.libs/libjavascriptcoregtk-1.0.so -pthread
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/4.6/../../../mipsel-linux-gnu/crt1.o:
undefined reference to symbol '_gp'
/usr/lib/mipsel-linux-gnu/libicui18n.so.48: error adding symbols: DSO missing
from command line
collect2: ld returned 1 exit status

This looks suspiciously similar to [3]. Note however that it built fine on
mips[2]. Both builds used the default compiler (gcc/g++ 4.6) and had libc6
2.17-3. However mips had binutils 2.22-8 while mipsel had 2.23.52.20130612-1.
Per the followups to [3] and per [4], I guess this is some binutils/eglibc 
mismatch?

Thanks,
Emilio

[1]
https://buildd.debian.org/status/fetch.php?pkg=webkitarch=mipselver=1.8.1-4stamp=1371488690

[2]
https://buildd.debian.org/status/fetch.php?pkg=webkitarch=mipsver=1.8.1-4stamp=1371214549
[3] https://lists.debian.org/debian-mips/2013/05/msg00018.html
[4] https://lists.debian.org/debian-devel-changes/2013/06/msg00501.html


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bf4a9b.7020...@debian.org

Re: Bug#711107: gtk+3.0: FTBFS on ia64 and mips

[Emilio Pozuelo Monfort]

Hi,

On 15/06/13 04:01, Stephan Schreiber wrote:
 I'm using Debian unstable on ia64.
 
 I built the gtk+3.0 package twice; the test always fails as on the ia64 
 buildd:
 
 /usr/bin/make  check-local
 make[4]: Entering directory
 `/home/stephan/gtkplus2/gtk+3.0-3.8.2/debian/build/shared/tests/a11y'
 TEST: accessibility-dump... (pid=3867)
 PASS: accessibility-dump
 TEST: tree-performance... (pid=3889)
 PASS: tree-performance
 TEST: text... (pid=3908)
   /text/bold/GtkLabel: OK
   /text/basic/GtkLabel:OK
   /text/basic/GtkEntry:OK
   /text/basic/GtkTextView: OK
   /text/words/GtkLabel:OK
   /text/words/GtkEntry:OK
   /text/words/GtkTextView: OK
   /text/changed/GtkLabel:  OK
   /text/changed/GtkEntry:  OK
   /text/changed/GtkTextView:   OK
   /text/selection/GtkLabel:OK
   /text/selection/GtkEntry:OK
   /text/selection/GtkTextView: OK
 PASS: text
 TEST: children... (pid=3927)
   /scrolledwindow/child-count: OK
   /child/add-remove/GtkScrolledWindow: OK
   /child/add-remove/GtkBox:OK
   /child/add-remove/GtkPaned:  OK
   /child/add-remove/GtkGrid:   OK
   /child/add-remove/GtkEventBox:   OK
   /child/add-remove/GtkWindow: OK
   /child/add-remove/GtkAssistant:  OK
   /child/add-remove/GtkFrame:  OK
   /child/add-remove/GtkExpander:   OK
   /child/add-remove/GtkTable:  OK
   /child/add-remove/GtkTextView:   OK
   /child/add-remove/GtkTreeView:   OK
   /child/add-remove/GtkNotebook:   OK
   /child/add-remove/GtkEntry:  **
 ERROR:/home/stephan/gtkplus2/gtk+3.0-3.8.2/./tests/a11y/children.c:201:test_add_remove:
 assertion failed: (parent_data[j].parent == NULL)
 FAIL
 GTester: last random seed: R02S2c373dee33e29d116c561db135f16945
 (pid=3946)
 FAIL: children
 TEST: derive... (pid=3960)
 PASS: derive
 TEST: value... (pid=3979)
   /value/basic/GtkSpinButton:  OK
   /value/basic/GtkLevelBar:OK
 PASS: value
 TEST: tree-relationships... (pid=3998)
   /a11y/tree/focus:OK
   /a11y/tree/relations:OK
 PASS: tree-relationships
 TEST: util... (pid=4018)
   /util/toolkit-name:  OK
   /util/toolkit-version:   OK
   /util/root:  OK
 PASS: util
 make[4]: *** [test-cwd] Error 1
 make[4]: Target `check-local' not remade because of errors.
 make[4]: Leaving directory
 `/home/stephan/gtkplus2/gtk+3.0-3.8.2/debian/build/shared/tests/a11y'
 make[3]: *** [check-am] Error 2
 make[3]: Target `check' not remade because of errors.
 make[3]: Leaving directory
 `/home/stephan/gtkplus2/gtk+3.0-3.8.2/debian/build/shared/tests/a11y'
 
 
 
 The test passes when I run it subsequently:
 
 stephan@itanic:~/gtkplus2/gtk+3.0-3.8.2/debian/build/shared/tests/a11y$ 
 xvfb-run
 ./children
 /scrolledwindow/child-count: OK
 /child/add-remove/GtkScrolledWindow: OK
 /child/add-remove/GtkBox: OK
 /child/add-remove/GtkPaned: OK
 /child/add-remove/GtkGrid: OK
 /child/add-remove/GtkEventBox: OK
 /child/add-remove/GtkWindow: OK
 /child/add-remove/GtkAssistant: OK
 /child/add-remove/GtkFrame: OK
 /child/add-remove/GtkExpander: OK
 /child/add-remove/GtkTable: OK
 /child/add-remove/GtkTextView: OK
 /child/add-remove/GtkTreeView: OK
 /child/add-remove/GtkNotebook: OK
 /child/add-remove/GtkEntry: OK
 
 
 
 It works with fakeroot as well:
 
 stephan@itanic:~/gtkplus2/gtk+3.0-3.8.2/debian/build/shared/tests/a11y$ 
 fakeroot
 xvfb-run ./children
 /scrolledwindow/child-count: OK
 /child/add-remove/GtkScrolledWindow: OK
 /child/add-remove/GtkBox: OK
 /child/add-remove/GtkPaned: OK
 /child/add-remove/GtkGrid: OK
 /child/add-remove/GtkEventBox: OK
 /child/add-remove/GtkWindow: OK
 /child/add-remove/GtkAssistant: OK

Re: Bug#711107: gtk+3.0: FTBFS on ia64 and mips

[Emilio Pozuelo Monfort]

Hi Stephan,

Thanks for your analysis! I indeed get a conditional jump based on an
uninitialized variable on x86_64. I have forwarded your bug report upstream at

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

As for the mips failure, I ran it on valgrind on x86_64 in case it was a similar
issue and oh surprise, it fails under valgrind, even though there are no errors
(well there are two but are suppressed, I haven't checked why but I'm assuming
if they are suppressed then they are false positives).

I have reported it with some more information at:

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

I'm making an upload with your patch and with the failing treeview testcase
disabled for now.

Thanks again!

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bcf180.3050...@debian.org

Re: Bug#711107: gtk+3.0: FTBFS on ia64 and mips

[Emilio Pozuelo Monfort]

tags 711107 + help
thanks

Hi,

On 04/06/13 20:45, Adam D. Barratt wrote:
 Source: gtk+3.0
 Version: 3.8.2-1
 Severity: serious
 Tags: jessie sid
 
 Hi,
 
 gtk+3.0 FTBFS on ia64 and mips with test errors. From the ia64 build
 log:
 
 TEST: children... (pid=30825)
 process 30825: D-Bus library appears to be incorrectly set up; failed to read 
 machine uuid: Failed to open /etc/machine-id: No such file or directory
 See the manual page for dbus-uuidgen to correct this issue.
   /scrolledwindow/child-count: OK
   /child/add-remove/GtkScrolledWindow: OK
   /child/add-remove/GtkBox:OK
   /child/add-remove/GtkPaned:  OK
   /child/add-remove/GtkGrid:   OK
   /child/add-remove/GtkEventBox:   OK
   /child/add-remove/GtkWindow: OK
   /child/add-remove/GtkAssistant:  OK
   /child/add-remove/GtkFrame:  OK
   /child/add-remove/GtkExpander:   OK
   /child/add-remove/GtkTable:  OK
   /child/add-remove/GtkTextView:   OK
   /child/add-remove/GtkTreeView:   OK
   /child/add-remove/GtkNotebook:   OK
 **
 ERROR:/build/buildd-gtk+3.0_3.8.2-1-ia64-B1rOQa/gtk+3.0-3.8.2/./tests/a11y/children.c:201:test_add_remove:
  assertion failed: (parent_data[j].parent == NULL)
   /child/add-remove/GtkEntry:  FAIL
 GTester: last random seed: R02Sae645f89bea2b5a42d0ff294fe8decbd
 (pid=30845)
 process 30845: D-Bus library appears to be incorrectly set up; failed to read 
 machine uuid: Failed to open /etc/machine-id: No such file or directory
 See the manual page for dbus-uuidgen to correct this issue.
 FAIL: children

I built gtk+3.0 in a mips and an ia64 porterboxes and reproduced the failures
(note they are different failures, the one above is for ia64). I had a look at
the source and couldn't find anything obviously wrong. Those tests pass on every
other architecture. Note that the tests run under Xvfb (see the Makefile). I
could reproduce the tests by running make check or by running xvfb-run
./children (or the mips failing test). I wanted to make sure this wasn't a
problem with xvfb by running this with a real display, but apparently X
forwarding is disabled on the buildds.

Help here is appreciated. I would suggest to first try these tests in a real
display to rule out Xvfb issues.

Thanks,
Emilio


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b85f4b.90...@debian.org

Re: Does buildd need some mipsel machines?

[Emilio Pozuelo Monfort]

Thanks for your interest. The appropriate place for buildd machines is the
wanna-build team (and debian-mips I guess), so I'm sending your message there.

Cheers,
Emilio

Full quoted message:

LIU Qi wrote:
 Hi guys,
 It seems that the mipsel machine of buildd doesn't work so well. Is
 there any need to add more mipsel machines? We have some Loongson-2
 based machines. Thanks.
 
 Regards,
 Qi




signature.asc
Description: OpenPGP digital signature