On Mon, Mar 04, 2024 at 09:52:14AM +0100, Gerardo Ballabio wrote:
> Gianluca Renzi wrote:
> > The same here. We never used the d-i but we are using Debian systems
> > (kernel and root file system) as daily bases of our line of products
> > embedded systems. Hundred of thousands of boards are
On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more
On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
>...
> Note that the last time the problem arised already earlier in
> experimental and Ben workarounded it there with
> https://salsa.debian.org/kernel-team/linux/-/commit/9dfe6d33a4fd220394228b30cbbfdb3b444d36ec
> We probably
On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
>...
> - Relese the DSA without armel builds. This is not optimal and for the point
> release
> we need to have to have all builds, but this gives people who still are
> interested
> in this architecture to step up and
On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 25.06.23 um 13:37 schrieb Rene Engelhard:
> > > what about the
> > > following:
> > > - make all test failures fatal on a*64 (since upstream tests these), and
> > > - make smoketest failures fatal on all architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
> Hi,
>
> Am 19.06.23 um 23:29 schrieb Rene Engelhard:
> > > The pragmatic option would be to run only a smoketest for build success
> > > on architectures not tested by upstream.
> >
> > And have Format->Character in Impress crash
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit
On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> I won't be of much help here unfortunately, except
> maybe testing patches, but then again there's porterboxes
>...
You are the only one who could realistically debug many of these.
E.g. on armel it says:
Fatal exception:
On Wed, Jan 18, 2023 at 12:50:15PM +0200, Graham Inggs wrote:
> Control: severity -1 serious
> Control: tags -1 + ftbfs
>
> Hi Maintainer and i386, arm, mips porters
>
> > As far as I can tell, the reason is that coreutils now uses a 64-bit
> > time_t and functions with a "64" suffix. Datefudge
Package: firefox-esr
Version: 102.3.0esr-1
Severity: serious
Tags: bookworm sid
X-Debbugs-Cc: Carsten Schoenert ,
debian-rele...@lists.debian.org, t...@security.debian.org,
debian-arm@lists.debian.org
[ various potentially interested parties are Cc'ed ]
4 GB address space for one process is an
On Sun, Oct 02, 2022 at 04:23:35PM +0200, Arnd Bergmann wrote:
> On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
> > On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
> >> On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
> >>...
> >> > I know are
On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
> On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
>...
> > I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
> > use musl-1.2, not glibc, and they have a much smaller set of packages.
>
> OK. We still have plenty of bugs to
Control: tags -1 ftbfs
On Thu, Sep 30, 2021 at 09:57:32PM +0200, Paul Gevers wrote:
> Source: netgen
> Version: 6.2.2006+really6.2.1905+dfsg-4
> X-Debbugs-CC: debian...@lists.debian.org
>...
> test_pickling.py Fatal Python error: Bus error
>
> Current thread 0xf7af5730 (most recent call first):
On Tue, Oct 05, 2021 at 03:23:53PM -0400, Camm Maguire wrote:
>...
> Fair enough, but *Debian* ships a given compiled kernel fixing this
> parameter, no? That is the target for the distribution and
> apps/packages.
Most x86 users use our kernel, but not on arm.
On x86 nearly all hardware
On Tue, Oct 05, 2021 at 01:37:49PM -0400, Camm Maguire wrote:
>...
> To me it seems that the 64bit kernel, if it
> offers a compatibility mode, should match whatever the contemporaneous
> 32bit kernel behavior is, making this a bug in the compatibility mode.
>...
You are expecting compatibility
Source: ndpi
Version: 4.0-2
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/logs.php?pkg=ndpi=armhf
...
Bus error
openvpn.pcapERROR
...
make[1]: *** [debian/rules:35: override_dh_auto_test] Error 1
This is likely an alignment problem, similar to the
On Sat, Jun 26, 2021 at 08:43:22PM +0200, Christoph Biedl wrote:
>...
> can please somebody check the armel jitterentropy-rngd package in
> testing and unstable (1.2.1-2) on various arm platforms? Things look
> really weird and I have no idea how to proceed.
>
> Initial observation: On an old
On Fri, Jun 11, 2021 at 08:51:00PM -0400, Jeffrey Walton wrote:
>...
> Maybe the GPL license needs an update that addresses the abandonware
> problem. The update clause requires vendors on top of the base system
> to provide updates for the life of the device. Something like, "GPL
> plus the
On Fri, May 07, 2021 at 09:07:29AM +0200, Jérémy Lal wrote:
>...
> i'm trying to see if there was a real reason besides "external
> contingencies":
>...
> - what else could explain a crash there and not there
Looking through #debian-admin backlog, I see that a member of DSA was
doing some changes
On Fri, Jan 08, 2021 at 06:07:29PM +0100, Alberto Garcia wrote:
> On Mon, Dec 21, 2020 at 11:30:14PM +0200, Adrian Bunk wrote:
> > > I see that the build eventually succeeded:
> > >
> > >
> > > https://buildd.debian.org/status/logs.php?pkg=geary=3.38
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> > I am sorry for the later response.
> >Hi,
> >
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the Bullseye release
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> > I am sorry for the later response.
> >Hi,
> >
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the Bullseye release
On Fri, Nov 27, 2020 at 06:52:05AM -0400, David Bremner wrote:
> Wookey writes:
>
> > On 2020-11-17 21:19 +, Dominic Hargreaves wrote:
> >> Thanks for your work on this. As of today polymake has been uploaded
> >> to use gcc-9 which doesn't have this problem, so the perl transition
> >> has
On Fri, Nov 20, 2020 at 02:20:12PM +0100, Arnd Bergmann wrote:
>...
> The main question for what would happen with the armel port
> I think is what kernel to ship.
The main question is whether anyone in addition to me will sign up
as armel porter for bullseye.
> When the marvell kernel gets
>
Source: kitinerary
Version: 20.08.2-2
Severity: serious
Tags: ftbfs
It is surprising that even the failing tests that look
like a timezone issue are reproducibly architecture specific.
kitinerary builds for riscv64 on Ubuntu, but they are
just ignoring test results.
On Fri, May 15, 2020 at 12:03:16PM +0300, Adrian Bunk wrote:
>...
> "Bus error" usually means unaligned access somewhere in C code,
> and this is a more of a problem when running on armv8 than
> on armv7 (some buildds are armv7, some are armv8 like this one).
Confirmed on th
ot; now, will take a while.
> >
> > Also for this one, only vtkplotter showed up.
>
> Did you check #951704 ? This affect python3 package using jemalloc.
I wrote earlier:
On Thu, May 07, 2020 at 01:16:15PM +0300, Adrian Bunk wrote:
>...
> #951704 looks like a similar
On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote:
>...
> On 07-05-2020 10:07, Adrian Bunk wrote:
> > This is a toolchain problem affecting many packages:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25051
>
> Do you have any rough estimate how many
On Fri, Mar 06, 2020 at 10:57:20AM +0100, Paul Gevers wrote:
>...
> However, it fails on arm64. I copied some of the output at the bottom of
> this report.
>
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?
>...
>
On Wed, May 06, 2020 at 01:56:24PM +0100, Steve McIntyre wrote:
>...
> On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
> >
> >One solution for this would be to ship the optimized library in the same
> >package as the default library. Now this is not acceptable for embedded
>
On Mon, May 04, 2020 at 02:45:41PM -0400, Noah Meyerhans wrote:
>...
> I wonder if it'd make sense for libc to be a virtual package, with
> functionality provided by optimized builds and dependencies satisfied
> via Provides. I don't know how well dpkg would cope with transitioning
> between
On Sun, Feb 16, 2020 at 01:33:55PM +0100, Christian Kastner wrote:
> On armel, dividing a flow by zero does not raise an exception, as it
> does on other platforms.
>...
> Any suggestions on how to deal with this? Is this really a bug, or is my
> test program above missing something?
>...
armel
On Fri, Feb 14, 2020 at 10:56:47AM -0600, John Goerzen wrote:
>
> The thing that we have to remember is that an operating system is a
> platform for running software. This problem is rather thorny, because:
>
> 1) Some software is provided in only binary form and cannot be
> recompiled
>
> 2)
On Tue, Jan 14, 2020 at 02:43:43PM +0100, Fabian Wolff wrote:
> On Tue, Jan 14, 2020 at 12:57:11 +0200, Adrian Bunk wrote:
> > This looks like ~ 70 arm64-only Build-Attempted failures since buildd
> > chroots were regenerated on Sunday, in a wide variety of packages.
>
> M
On Tue, Jan 14, 2020 at 10:57:29AM +0100, Stéphane Glondu wrote:
>...
> Christian Marillat says that "Binutils package is broken see #911990",
> but this bug has been marked as fixed-upstream for more than 1 year, is
> it really still on topic?
Correct bug number would be #948803 or #948819.
The
On Sun, May 12, 2019 at 03:16:10PM +0300, Ilias Tsitsimpis wrote:
> On Mon, Mar 11, 2019 at 12:05PM, Adrian Bunk wrote:
> > On Thu, Jan 31, 2019 at 08:12:17PM +0100, Bernhard Übelacker wrote:
> > > See attached file with several debugging attempts.
> >
> > Look
On Wed, Apr 10, 2019 at 11:12:17AM +0200, Matthias Klose wrote:
> On 10.04.19 10:29, Adrian Bunk wrote:
> > On Wed, Apr 10, 2019 at 10:11:29AM +0200, Matthias Klose wrote:
> >> Package: src:llvm-toolchain-7
> >> Version: 1:7.0.1-8
> >> Severity: serious
> &g
Control: severity -1 serious
Control: reassign -1 ghc 8.4.4+dfsg1-1
Control: affects -1 git-annex
On Thu, Jan 31, 2019 at 08:12:17PM +0100, Bernhard Übelacker wrote:
> Hello Everyone,
> I own a qnap ts-119pII with a similar cpu.
>
> See attached file with several debugging attempts.
Thanks a
On Thu, Feb 28, 2019 at 09:05:04AM +, Ian Campbell wrote:
>
> To spell it out: the gist of this is that it isn't possible to provide
> a single arm binary which works well for both armel and armhf (which I
> think is what Jeff is trying/wants to do?).
It is not even possible to provide a
Source: probabel
Version: 0.5.0+dfsg-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/fetch.php?pkg=probabel=arm64=0.5.0%2Bdfsg-1=1538603399=0
...
FAIL: test_bt
=
Analysing BT...
BT check: dose vs. dose_fv OK
BT check (add
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> > $ grep-dctrl -n -sSource:Package -FDepends \
> > -e
> > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> >
On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
>...
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
>...
Is there some rationale documented somewhere why this wasn't used in
Source: llvm-toolchain-7
Version: 1:7.0.1~+rc2-1~exp1
Severity: grave
Control: block 912164 by -1
Control: affects -1 src:rust-pulldown-cmark src:mesa src:cargo
LLVM now violates the armhf baseline by using NEON,
this can be reproduced as easy as:
(sid_armhf-dchroot)bunk@abel:~$ llvm-config-7
On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote:
>...
> Hardware setup: I've configured the earlier 3 as buildds in little 1U
> cases with 32GiB RAM and mirrored SSDs, but for $reasons they're not
> yet installed and running. I'm assuming that a similar spec would be
> wanted for
Source: dpuser
Version: 3.3+p1+dfsg-2
Severity: serious
Tags: ftbfs
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/dpuser.html
...
Executing selfmade procedure # 6
>>> "addquad" exists already as stored function!
>>> "factorial" exists already as stored function!
>>>
Source: luajit
Version: 2.0.4+dfsg-1
Severity: serious
Forwarded: https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-260205661
This is an RFC regarding what to do for avoiding runtime
problems on arm64 like e.g. #907729.
The big hammer would be to drop luajit on arm64,
reverse dependencies
On Wed, Aug 29, 2018 at 09:43:41PM +0100, Steve McIntyre wrote:
> On Wed, Aug 29, 2018 at 11:29:51PM +0300, Adrian Bunk wrote:
> >On Wed, Aug 29, 2018 at 09:07:45PM +0100, Steve McIntyre wrote:
> >>
> >> This is utterly premature and unwarranted. Don't be ridiculous.
&g
On Sat, Aug 18, 2018 at 07:01:39PM +0900, Roger Shimizu wrote:
>...
> Yes. In latest ARM BoF of DebConf18, Steve (93sam) informed us that
> he's trying to rebuild all the armhf archive on arm64 box.
> When that's done, we will get to know how many packages need to fix.
> If the number of those
Control: retitle -1 dbus-cpp: async_execution_load_test fails sometimes
(randomly?)
Control: found -1 5.0.0+18.04.20171031-1
Control: severity -1 serious
On Fri, Feb 02, 2018 at 10:08:54AM +0100, Aurelien Jarno wrote:
> control: retitle -1 Bug#888995: FTBFS: async_execution_load_test fails on
>
On Tue, Jul 24, 2018 at 08:43:02PM +0200, Christoph Biedl wrote:
> Adrian Bunk wrote...
>
> > I'd like to get a clear picture regarding the situation of building
> > armel for buster on arm64, ideally moving it to arm64 hardwre soon.
>
> JFTR, I'd appreciate if ar
On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote:
>...
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>...
I'd like to get a clear picture regarding the situation of building
armel for buster on
On Tue, Jan 16, 2018 at 12:38:25AM +0500, Lev Lamberov wrote:
> Hi,
>
> recently I've discussed with upstream the build problems regarding the
> swi-prolog package on arm{el,hf} and mipsel [0], which are also
> highlighted in #887155 [1].
>
> We're wondering whether or not some of the tests are
On Mon, Nov 20, 2017 at 09:37:10AM +, Lars Brinkhoff wrote:
> Adrian Bunk wrote:
> > If anyone is running stretch, buster or sid on ARMv4t hardware, then
> > please let us know what device and kernel you are using and whether
> > you intend to use buster.
>
> M
On Sun, Nov 19, 2017 at 10:14:35PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/12/2017 05:44 PM, Adrian Bunk wrote:
>...
> > A working kernel recent enough for buster on hardware where running
> > buster makes sense, and with actual users - this might simply no
> >
Package: gcc-7
Version: 7.2.0-16
Severity: normal
Tags: patch
As announced in https://lists.debian.org/debian-arm/2017/11/msg00045.html
this patch raises the armel baseline for buster from armv4t to armv5te.
--- debian/rules2.old 2017-11-18 22:12:44.946825904 +
+++ debian/rules2
Package: libqt5opengl5-dev
Version: 5.9.2+dfsg-4
Severity: normal
Tags: patch
Different from other architectures, on armel and armhf
Qt in Debian is configured to use OpenGL ES instead
of full OpenGL.
Some OpenGL-related functionality in Qt is not available
with OpenGL ES, and Qt also offers
On Sun, Nov 12, 2017 at 03:30:22PM +0100, John Paul Adrian Glaubitz wrote:
> I’m not sure whether there was actually a realistic chance of finding anyone
> on the mailing lists when you ask such questions.
>
> I would assume that 99% of our users aren’t present on the mailing lists and
>
Hi,
my search for armv4t users on >= stretch [1] did not find a single one,
and unless someone brings up a strong reason against doing so I will
request a baseline bump to armv5te in gcc in a week.[2]
Worth mentioning is that this is armv5te, not armv5t.
Quoting Arnd Bergmann regarding kernel
On Sat, Nov 11, 2017 at 09:03:04PM +0100, Andreas Henriksson wrote:
> Hello,
>
> On Tue, Nov 07, 2017 at 11:10:27PM +0200, Adrian Bunk wrote:
> [...]
> > This whole "so many packages are broken on armel" narrative
> > is actually mostly FUD,
On Tue, Nov 07, 2017 at 07:45:35PM +, Wookey wrote:
>...
> I'm very happy if people mark problematic packages that no longer
> build for armv5 as 'notforus' if no-one steps up to fix them in a
> timely fashion, but killing the architecture because some upstreams
> no-longer care about v5 seems
On Tue, Nov 07, 2017 at 11:08:39AM +0100, Julien Cristau wrote:
>
> That's not clear to me at all. Keeping armel on life support for 2 more
> years is a significant drain on DSA and our hosters,
>...
What kind of significant drain exactly?
AFAIK so far noone has stated that it would be safe to
On Tue, Nov 07, 2017 at 01:43:50PM +0100, Héctor Orón Martínez wrote:
>...
> 2017-11-05 22:32 GMT+01:00 Adrian Bunk <b...@debian.org>:
>
> > for the armel port in buster the question of raising the baseline came up.
>
> That has been a recurring question over the tim
Hi,
for the armel port in buster the question of raising the baseline came up.
20 years ago you could go into a shop and buy a mobile phone
with a CPU supported by the armel port in stretch.
Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug
reports from users on ARMv5
On Mon, Aug 28, 2017 at 06:57:40PM +0100, Ian Campbell wrote:
> On Mon, 2017-08-28 at 06:53 +0800, Paul Wise wrote:
> > On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
> >
> > > However, I think armel is time to transit to v5.
> >
> > As someone who can no longer run Debian stable on his
On Mon, Aug 28, 2017 at 06:53:54AM +0800, Paul Wise wrote:
>...
> OTOH the
> only relevant hardware for armel these days seems to be RPi, so why
> not make armel into armhfv6 instead?
Incompatible ABI, your suggestion to move Raspbian as armhfv6
into Debian would therefore have to be a new port.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
since I am not in Montréal, I am sending my participation by email:
Since Debian dropping popular ports is nothing I consider good for
Debian, I hereby step up as armel porter for buster.
If none of the curent armel porters want to continue
On Fri, Jul 28, 2017 at 08:30:30AM +, Riku Voipio wrote:
> On Tue, Jul 11, 2017 at 09:45:49AM +0100, Ian Campbell wrote:
> > On Tue, 2017-07-11 at 08:56 +0100, Edmund Grimley Evans wrote:
> > > > Does this emulation take a considerable performance hit, as opposed
> > > > to
> > > > running on
Package: binutils
Version: 2.29-1
Severity: important
binutils 2.29-1 causes many haskell packages to FTBFS, example:
https://tests.reproducible-builds.org/debian/unstable/arm64/haskell-asn1-encoding
...
[12 of 12] Compiling Data.ASN1.BinaryEncoding ( Data/ASN1/BinaryEncoding.hs,
On Sat, Jul 01, 2017 at 01:33:14PM +0200, Matthias Klose wrote:
> On 30.06.2017 15:22, Adrian Bunk wrote:
> > On Thu, Jun 29, 2017 at 02:37:27PM +0200, Matthias Klose wrote:
> >> On 29.06.2017 06:51, Adrian Bunk wrote:
> >>> Package: libstdc++6
> >>>
On Thu, Jun 29, 2017 at 02:37:27PM +0200, Matthias Klose wrote:
> On 29.06.2017 06:51, Adrian Bunk wrote:
> > Package: libstdc++6
> > Version: 7.1.0-7
> > Severity: serious
> > Control: affects -1 src:mesa
> >
> > mesa FTBFS on armel due to:
> >
>
On Thu, Jun 29, 2017 at 02:37:27PM +0200, Matthias Klose wrote:
> On 29.06.2017 06:51, Adrian Bunk wrote:
> > Package: libstdc++6
> > Version: 7.1.0-7
> > Severity: serious
> > Control: affects -1 src:mesa
> >
> > mesa FTBFS on armel due to:
> >
>
Package: libstdc++6
Version: 7.1.0-7
Severity: serious
Control: affects -1 src:mesa
mesa FTBFS on armel due to:
https://buildd.debian.org/status/fetch.php?pkg=mesa=armel=17.1.3-2=1498610882=0
...
llvm-config-4.0: relocation error:
/usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1: symbol
On Thu, Apr 27, 2017 at 07:23:20AM +, Gianfranco Costamagna wrote:
> Hello,
>
> > rnahybrid FTBFS on armel:
>
>
> the warning above is somewhat important
> (too many nested loops), and this usually relates badly with
> high optimization levels
>...
The warning is about an off-by-one in the
Source: dietlibc
Version: 0.34~cvs20160606-4
Severity: serious
https://buildd.debian.org/status/fetch.php?pkg=dietlibc=arm64=0.34~cvs20160606-4=1483685322
...
test/stdlib/testrand.c : build: OKrun: OK
test/stdlib/tst-calloc.c : build: OKrun: ERROR
Source: libwebp
Version: 0.5.1-3
Severity: serious
https://buildd.debian.org/status/logs.php?pkg=libwebp=armhf
...
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src/webp -DNDEBUG
-Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -Wall
-Wdeclaration-after-statement -Wextra
On Thu, Nov 24, 2016 at 04:35:28PM +0100, Guillem Jover wrote:
>...
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
>...
> > Worse, they break *differently* on whether…
> >
> > >Precisely to make the behavior consistent on all architectures, dpkg
> > >enables PIE (conditionally if
On Sun, Nov 06, 2016 at 09:59:20AM +0100, Mehdi Dogguy wrote:
> Hi,
>
> On 02/11/2016 03:22, Ximin Luo wrote:
> >
> > let emit_load_symbol_addr dst s = if !Clflags.pic_code then begin [..] end
> > else if !arch > ARMv6 && not !Clflags.dlcode && !fastcode_flag then begin `
> > movw
On Wed, Nov 02, 2016 at 02:22:00AM +, Ximin Luo wrote:
>...
Thanks a lot for debugging this.
> let emit_load_symbol_addr dst s =
> if !Clflags.pic_code then begin
> [..]
> end else if !arch > ARMv6 && not !Clflags.dlcode && !fastcode_flag then
> begin
> ` movw{emit_reg dst},
On Mon, Oct 31, 2016 at 06:46:00PM +, Niels Thykier wrote:
> Control: retitle -1 ocaml: FTBFS on -fPIE binNMU on armhf - test failure
>
> Dear maintainer,
>
> We have tried to binNMU ocaml in unstable now that PIE is on by default.
> This worked fine on all release architectures except
[ fullquote adding -ports, for people not following -release or -devel ]
On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
>
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also
On Sat, 9 Dec 2000, Reuben Thomas wrote:
Package: mtools
Version: 3.9.6-3.1
On my ARM system (Acorn RISC PC, StrongARM, kernel 2.2.16-rmk3, libc
2.1.3-13), issuing a command such as mcopy or mdir gives the error:
Mtools has not been correctly compiled
Recompile it using a more recent
On Tue, 12 Dec 2000, Philip Blundell wrote:
I have some questions:
1. Are the Linux/arm machines all called armv4l?
No, you should match on just `arm*'. armv4l happens to be the most common,
but many others are possible.
I've changed this.
...
3. Is this patch all right?
Using
82 matches
Mail list logo
