W: armhf version for thunderbird bullseye

2021-10-06 Thread Tuxo
Hi list Is there a thunderbird version for armhf in one of the debian repositories? checking [1] and [2] they mention armhf versions of tb 78 for Buster and Stretch, none for Bullseye so far. [1] https://packages.debian.org/search?arch=armhf=thunderbird [2]

Re: W: armhf version for thunderbird bullseye

2021-10-06 Thread peter green
I think the issue may have been the linker running out of address space. Certainly we ran into that in raspbian. I do have a thunderbird package in raspbian which may work for you, but I have to build it in a slightly hacked-up environment with the linker replaced by a cross-linker. On

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

2021-10-06 Thread Simon McVittie
Source: llvm-toolchain-13 Version: 1:13.0.0-2 Severity: important X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, debian-arm@lists.debian.org llvm-toolchain-13 has always failed to build on armel, mipsel, mips64el. This makes mesa BD-Uninstallable on those release

Re: W: armhf version for thunderbird bullseye

2021-10-06 Thread John Paul Adrian Glaubitz
Hello! On 10/6/21 16:38, Tuxo wrote: > Is there a thunderbird version for armhf in one of the debian repositories? > > checking [1] and [2] they mention armhf versions of tb 78 for Buster and > Stretch, none for Bullseye so far. Carsten Schoenert has disabled the 32-bit ARM builds of

Re: W: armhf version for thunderbird bullseye

2021-10-06 Thread Carsten Schoenert
Hello Adrian, hello Tuxo, Am 06.10.21 um 17:06 schrieb John Paul Adrian Glaubitz: Hello! On 10/6/21 16:38, Tuxo wrote: Is there a thunderbird version for armhf in one of the debian repositories? checking [1] and [2] they mention armhf versions of tb 78 for Buster and Stretch, none for

Re: armv8 does not respect personality ADDR_LIMIT_3GB

2021-10-06 Thread Camm Maguire
Greetings, and thanks for your reply On Tue, 5 Oct 2021 15:01:59 -0400, Len Sorensen wrote: >>From what I could find, some programs allocate their own stack early in >execution and can hence put it where they want which I guess would free >up some known address space range. Potentially. With