On 2024-08-13 11:46, Aurélien COUDERC wrote:
> 2 tests are segfaulting:
> The following tests FAILED:
> 2 - testbuiltins (SEGFAULT)
> 3 - testloadertags (SEGFAULT)
> Errors while running CTest
This looks like a GCC 14 regression, see the initial analysis on
https://bugs
Hello Hector,
thanks for bringing this up!
On 2024-08-21 05:18, Hector Oron wrote:
> There was a compelling reason to do at least one more armel release to
> have at least one official release with time64 support.
FWIW I think this makes a lot of sense: have one stable release with
time64 support
[ Martin added to CC ]
On 2024-08-16 12:02, Chris Hofstaedtler wrote:
> while investigating a test failure in ksh93u+m, it became clear that
> packages last built before the time_t-64bit transition can have
> latent bugs.
> They might very well now FTBFS or fail at runtime (autopkgtest time
> or l
Hi Diederik,
On 2024-07-22 10:15, Diederik de Haas wrote:
> The referenced commit is part of 2.42.90.20240720-1, so this bug can be
> closed
> (and the workaround for the kernel dropped)?
Indeed, I just built Linux 6.10 with CONFIG_RELR=y and binutils
2.42.90.20240720. It booted fine:
Linux ve
On 2024-06-26 03:19, Emanuele Rocca wrote:
> Binutils upstream is now looking at the issue, see:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31924
>
> For the time being we could explicitly set CONFIG_RELR=n in
> debian/config/arm64/config as a workaround, while waiting
On 2024-06-24 06:10, Emanuele Rocca wrote:
> On 2024-06-23 12:13, Chris Hofstaedtler wrote:
> > I think this also means rebuilding an existing kernel in unstable
> > or testing will also break.
>
> That is correct, I've built Linux 6.8.12 in a sid chroot and the
>
Hi,
On 2024-06-23 12:13, Chris Hofstaedtler wrote:
> I think this also means rebuilding an existing kernel in unstable
> or testing will also break.
That is correct, I've built Linux 6.8.12 in a sid chroot and the
resulting kernel image is 26M and unbootable.
Toolchain package versions, for refe
Hey,
On 2024-06-21 02:57, Emanuele Rocca wrote:
> Index: ocaml-5.2.0/otherlibs/runtime_events/runtime_events_consumer.c
Please ignore the diff, this was sent out by mistake as I was testing my
suggestions. I haven't checked any other area in the code, so I'm not
sure what a proper
Hello Stéphane,
On 2024-06-19 03:20, Stéphane Glondu wrote:
> While investigating OCaml 5.2.0 build failure on armel, I realized that
> atomic 64-bit reads from mmap-ed memory on armel results in a segfault.
>
> See:
>
> https://github.com/ocaml/ocaml/issues/13234#issuecomment-2176079951
In t
, temporarily drop the subversion and libsvn-perl
+build-deps. The packages are currently not installable on those arches due
+to the ongoing t64 transition and are only needed by git-svn.
+
+ -- Emanuele Rocca Wed, 20 Mar 2024 09:10:32 +0100
+
git (1:2.43.0-1) unstable; urgency=low
On 2024-03-13 02:08, Emanuele Rocca wrote:
> When it comes to actually satisfying build-depends properly it seems
> that as of right now the missing ones are libcurl4-gnutls-dev and
> libgit2-dev.
Cargo is now done. With libcurl4-gnutls-dev and libgit2-dev available I
could bootstrap it
Hi,
On 2024-03-12 05:55, Emanuele Rocca wrote:
> I did manage to get cargo to build in a armhf chroot by manually
> installing the various deps
When it comes to actually satisfying build-depends properly it seems
that as of right now the missing ones are libcurl4-gnutls-dev and
libgit2-dev
[ debian-rust added to CC ]
Hi,
On 2024-03-12 11:03, Simon McVittie wrote:
> In the medium term, cargo needs re-bootstrapping on the affected
> architectures (armel and armhf, plus a bunch of -ports architectures
> where as far as I can see cargo was never available in the past) -
> that's #10657
Hi,
On 2023-11-25 12:37, Wookey wrote:
> For debian we'll keep an eye on it, do a belated rebuild to see how
> much of a problem we really have, and then decide if we should revert
> it too until some stuff if fixed.
I now finally have some data to share. In total, out of the whole Debian
archive
Hi Matthias,
On 2024-01-23 09:01, Matthias Klose wrote:
> This is a long standing, re-occurring issue which never has been
> forwarded and committed by the armel ports to GCC upstream.
You seem to be aware of previous occurrences of this issue. Please share
the details you have available such as
Hi Mathieu!
On 2024-01-12 11:33, Mathieu Malaterre wrote:
> Could someone please confirm what I see on the armel/buildd:
>
> *
> https://buildd.debian.org/status/fetch.php?pkg=dcmtk&arch=armel&ver=3.6.8-2&stamp=1705054390&raw=0
>
> Is this a 32bits/limited RAM issue ? Is there a way to fix the
Hi Bastian,
On Sun, Jan 07, 2024 at 11:07:48PM +0100, Bastian Blank wrote:
> Do we have any armel subarch that can be installed via d-i?
Not as far as I know, perhaps Sledge has more info on this? Also, I don't think
we've seen anyone mentioning armel in ages on debian-boot, both in terms of
inst
Package: gcc-12
Version: 12.3.0-12
X-Debbugs-Cc: debian-arm@lists.debian.org, debian-gl...@lists.debian.org
Dear Maintainer,
PAC/BTI is a useful Arm security feature, see this recent presentation
at the Cambridge Mini Debconf for all details: [0]
In order to properly support PAC/BTI in Debian we
Hi Andreas!
On 2023-12-03 06:20, Andreas Metzler wrote:
> gnutls28 is currently blocked from testing because gsasl's autopkg test
> fails.
We recently enabled stack-clash-protection on all arm ports. On 32 bit
arm the feature is implemented using stack probes, which valgrind flags
as illegal acce
Hi,
On 2023-11-24 10:50, Matthias Klose wrote:
> A major problem will be valgrind stopping to work, causing issues in the
> test suites of other packages.
>
> Also after rebuilding libxml2, libarchive, gnutls28, libselinux without this
> flag on armhf, issues go away again.
FTR there is no issue
Hi Matthias,
On 2023-11-24 10:50, Matthias Klose wrote:
> On 24.11.23 07:19, Emanuele Rocca wrote:
> > In case there are any bugs, which is of course possible, please file
> > them and add debian-arm@ to X-Debbugs-CC.
>
> No, I will not do that. Sorry, but the task of the
Hello Lucas!
On 2023-10-25 08:55, Lucas Nussbaum wrote:
> On 14/08/23 at 14:53 +0200, Emanuele Rocca wrote:
> > I'm not sure how the deal with AWS is (how many credits we have
> > available and such) but would it be possible to repeat the experiment
> > for armhf too?
Hello!
On 2023-11-24 01:34, Guillem Jover wrote:
> According to https://bugs.debian.org/918914#73 there were no pending
> toolchain issues related to this.
That is correct. The GCC maintainers at Arm confirm that
stack-clash-protection is supported on 32 bit too.
In case there are any bugs, whic
Hi Lucas!
On 2023-10-25 08:55, Lucas Nussbaum wrote:
> Is this still of interest?
Not really, we've flipped the switch now. Thanks nonetheless. :-)
Emanuele
Hi Guillem,
On 2023-10-27 04:33, Guillem Jover wrote:
> Checking now again, I realize Wookey mentioned enabling this for the 3
> arm arches (those would be arm64, armhf and armel), so the patch I
> provided would match that. But I was wondering now what about armeb and
> arm64ilp32? I mean, I assu
Hello Stéphane,
On 2023-09-28 03:31, Stéphane Glondu wrote:
> These days, eliom FTBFS on armhf buildds:
>
> https://buildd.debian.org/status/package.php?p=eliom
>
> I've given it back several times; the failure is consistent.
>
> However, I cannot reproduce it locally nor on a porterbox (abel
Hi Lucas,
On 2023-08-12 08:18, Lucas Nussbaum wrote:
> Results:
> http://qa-logs.debian.net/2023/08/11.stackclash-arm/
>
> I only included logs for builds that succeeded in a vanilla build,
> but failed with the custom build.
Thank you so much, this is great! There's not much fallout.
I'm not s
Hi Ross,
On Thu, Aug 10, 2023 at 10:45:54PM -0700, Ross Vandegrift wrote:
> New to running arm64 stuff on physical arm64 hardware, and I'm unable to start
> a kvm guest. I'm sure I'm missing something, hoping someone can point me in
> the right direction.
[...]
> qemu-system-aarch64 \
> -nog
Hi,
On 2023-08-10 02:43, Lucas Nussbaum wrote:
> What I would need is a script that customizes a chroot.
This is what I'm passing to sbuild --chroot-setup-commands for my
builds:
sbuild --chroot-setup-commands='printf "APPEND CFLAGS
-fstack-clash-protection\nAPPEND CXXFLAGS -fstack-clash-prot
Hi,
On 2023-08-06 11:25, Moritz Mühlenhoff wrote:
> I worked with Lucas a while back and he made an archive rebuild on amd64,
> only a minimal list of packages will need to be adapted:
> http://qa-logs.debian.net/2023/05/24/
Can we do the same for arm64? As far as I understand the archive rebuild
Hi,
On 2023-06-27 03:16, Emanuele Rocca wrote:
> On 2023-06-15 11:21, Guillem Jover wrote:
> > AFAIR there was also the case of objects being annotated with
> > Tag_ABI_VFP_args but not with either of the ABI hard or soft float
> > flags.
>
> Indeed, there are
Hi,
On 2023-06-28 01:41, Guillem Jover wrote:
> On Fri, 2023-06-16 at 11:19:21 +0200, Emanuele Rocca wrote:
> > are written in
> > Pascal. It seems that fpc just emits the wrong flags. As an example,
> > here is the readelf output for the armhf version of cqrlog. Note that
&g
Hi,
On 2023-06-15 11:21, Guillem Jover wrote:
> AFAIR there was also the case of objects being annotated with
> Tag_ABI_VFP_args but not with either of the ABI hard or soft float
> flags.
Indeed, there are 1 armel and 91 armhf binary packages shipping ELF
files without float flags (hard or soft)
On 2023-06-16 11:19, Emanuele Rocca wrote:
> I'll look at the soft/hard float ones next.
Two findings.
(1) I couldn't find any armel object with the hard-float flag set.
(2) There are a few armhf packages shipping files with the soft-float flag.
All of them, with the exception
Hey,
On 2023-06-15 11:21, Guillem Jover wrote:
> AFAIR there was also the case of objects being annotated with
> Tag_ABI_VFP_args but not with either of the ABI hard or soft float
> flags. And rechecking the commit message, it seems there were also
> objects with both ABI float flags set at the sa
Hi Guillem,
On 2023-04-27 11:27, Guillem Jover wrote:
> I was recently working on the Dpkg::Shlibs::Objdump module code
> related to ELF and ABI tracking, and when seeing the ARM handling
> missing there, recalled the issues we saw some time ago with ARM
> when I tried to make that tracking more s
3.1/debian/changelog 2023-05-04 13:40:28.0 +0200
@@ -1,3 +1,11 @@
+gdb (13.1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * aarch64: add aarch64-pauth-registers.patch to check for valid inferior
+thread/regcache before reading pauth registers. (Closes: #1034611)
+
+ -
Hi,
Secure Boot on arm64 should be working fine with grub2 2.06-9 or later and
shim-signed 1.39, both in sid.
If you have SB-capable hardware please give it a try. It should just be a
matter of ensuring that your grub-efi-arm64-signed and shim-signed packages are
up-to-date. For details about ena
Hi Alan,
On Sat, Apr 01, 2023 at 09:01:42PM -0400, Alan Corey wrote:
> I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
> with Debian armhf
The Raspberry Pi 3 has a 64-bit CPU, you can install Debian arm64 instead of
armhf on it.
ema@raspi:~
$ sudo dmesg | grep 'Machine mod
39 matches
Mail list logo
