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
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\"
-DCEPH_PKGLIBDIR=\"/usr/lib/arm-linux-g
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 up
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 ma
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 pro
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 ol
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 t
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
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 at 11:14, E
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
> wrote:
>> In file included from /«PKGBUILDDIR»/lib/Support/ThreadPool.cpp:14:0:
>> /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In
Hi,
peter green wrote:
> On 18/05/16 04:50, Tim Northover wrote:
> If you don't need/want the various Sanitizer runtimes (e.g. you don't
> support sanitizers or already have versions provided with GCC) then
> it's as easy as not downloading compiler-rt or removing it from the
> projects/ directory
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:
>
> | /«PKGBUILDDIR»/include/llvm/Suppor
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 w
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 Stretch should be
>>
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
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-linu
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 patch
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
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 patc
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
On 23/10/15 11:20, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
>
>> 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
&g
[ 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 rebu
22 matches
Mail list logo
