Re: Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote: > This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR. > The bootstrap happens with the upstream binaries as we've done in the past. > I have also avoided the bump to LLVM 9/10, we use buster's LLVM 7 instead. Th

Bug#913599: ceph: FTBFS on armel: #error "NEON intrinsics not available with the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard"

Source: ceph Version: 12.2.8+dfsg1-2 Severity: serious Tags: ftbfs Hi, Your package failed to build on armel: cd /<>/ceph-12.2.8+dfsg1/obj-arm-linux-gnueabi/src/erasure-code/jerasure && /usr/bin/cc -DARM_NEON -DCEPH_LIBDIR=\"/usr/lib/arm-linux-gnueabi\"

Re: Bug#895193: transition: openmpi

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

Re: Bug#881846: rustc: FTBFS on armel

On 03/03/18 09:32, John Paul Adrian Glaubitz wrote: > Hi! > > I have managed to build rustc 1.24 natively on armel using the changes from > the following bug reports: > > - #891022 - rustc: Please include patch to disable kernel helpers on armel > - #891913 - rustc: Please add architecture

Re: Bug#880883: FTBFS on arm64: test suite times out (on arm-arm-04)

On 12/11/17 15:02, Michael Biebl wrote: > Am 05.11.2017 um 13:14 schrieb Michael Biebl: >> Looking through past build logs, it consistently seems to fail at this >> point: >> >> make[7]: Entering directory >> '/<>/debian/build/deb/tests/refcount' >> make closures objects objects2 properties

Bug#881846: rustc: FTBFS on armel

Source: rustc Version: 1.21.0+dfsg1-3 Severity: important Hi, rustc is missing on armel. I asked sometime ago about its status: 17:08 < infinity0> pochu_: armel isn't supported because of lack of proper atomics in llvm, it is theoreticaly possible but noone has spent the effort There are no

Re: armel after Stretch

On 07/12/16 16:53, Steve McIntyre wrote: > * It will need somebody happy to dive into the lower levels of the >various toolchains to verify support for atomics and make things >work where it's not already, by adding support for the kernel >helpers. There has been some recent work on

Re: Please give back prometheus on armel

On 24/11/16 05:37, Martín Ferrari wrote: > On 23/11/16 19:13, Emilio Pozuelo Monfort wrote: > >>> prometheus 1.2.3+ds2-2 failed to build on armel, but I am not being able >>> to reproduce this failure in porter boxes. Can you please trigger a >>> rebuild to

Re: llvm-toolchain-3.8 on lower arm targets

On 05/11/16 17:57, Pauli wrote: > On Wed, 5 Oct 2016 23:33:49 +1300, Bruce Hoult wrote: >> On Wed, Oct 5, 2016 at 7:46 AM, Tim Northover via llvm-dev < >> llvm-...@lists.llvm.org> wrote: >> >>> Hi Emilio, >>> >>> On 4 October 2016 a

Re: [llvm-dev] llvm-toolchain-3.8 on lower arm targets

Hi Tim, On 04/10/16 20:46, Tim Northover wrote: > Hi Emilio, > > On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev > <llvm-...@lists.llvm.org> wrote: >> In file included from /«PKGBUILDDIR»/lib/Support/ThreadPool.cpp:14:0: >> /«PKGBUILDDIR»/inc

Re: Need help with llvm-toolchain-3.8 on armel

Control: tags -1 help On Tue, 6 Sep 2016 09:45:10 +0200 Sylvestre Ledru wrote: > Hello, > > Is there anyone to help with this bug > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535 ? > LLVM toolchain 3.8 and later (3.9 & 4.0) are failing with: > > |

Re: [Stretch] Status for architecture qualification

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

Re: [Stretch] Status for architecture qualification

On 14/06/16 12:36, Steve McIntyre wrote: > On Tue, Jun 07, 2016 at 11:38:06AM -0700, Martin Michlmayr wrote: >> * Steve McIntyre [2016-06-06 15:14]: >>> However, I will admit (again) that armel is starting to lose upstream >>> support in some cases. I'm tempted to suggest that

Re: [Stretch] Status for architecture qualification

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

Re: Fixing the armhf linker path

On 27/01/16 18:40, Aurelien Jarno wrote: > On 2015-12-16 23:37, Emilio Pozuelo Monfort wrote: >> On 16/12/15 23:30, Aurelien Jarno wrote: >>> At the beginning of the armhf port the hard-float dynamic linker has >>> been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.

Re: Fixing the armhf linker path

On 16/12/15 23:30, Aurelien Jarno wrote: > At the beginning of the armhf port the hard-float dynamic linker has > been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it > has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have > changed it in Debian, and added a

Re: binNMUs: please exercise some care

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 automatic

Re: binNMUs: please exercise some care

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 larges