Hello Niels,
On 2024-12-28 01:06, Niels Thykier wrote:
> Please review attached as an example of how to fix this problem.
>
> Note: Untested, since I was doing my testing on amd64.
LGTM. I applied your patch and built the package with a regular user as
follows:
$ dpkg-buildpackage -us -uc -b -r
On 2025-03-19 09:45, Aurelien Jarno wrote:
> So far my finding are quite limited. It seems the new GCC generates more
> optimized code in general, and especially for the memmem() function, and
> that changes the location of the memmove() function located just after in
> the binary. Aligning it to 6
ate->pattern,
> | ^~
> bing_probes.c:31:1: note: include ‘’ or provide a declaration of
> ‘memcpy’
The fix suggested by the compiler (first part) works fine. See attached
patch.
Emanuele
>From ad2111765318727b9ce8ff40ddd25ae7ec728ce4 Mon Sep 17 00:00:0
Hi,
I've prepared an NMU for android-platform-external-libunwind (versioned
as 10.0.0+r36-4.1). Please find the diff attached.
commit a2061b471eb85b27f67be83e0febd657e01d35ca
Author: Emanuele Rocca
Date: Wed Mar 5 13:38:39 2025 +0100
Update path to 7zip to fix FTBFS #1060969
diff --
Control: retitle -1 barrier: FTBFS: failing test on hosts with one or two CPUs
On 2024-05-27 08:45, Kentaro HAYASHI wrote:
> I've just tried it with debian:sid container,
> it seems that there is no test failure about 4 reported failures.
Indeed I can also confirm that on my workstation the build
Control: tag -1 unreproducible
Hi Graham,
On 2024-08-28 11:19, Graham Inggs wrote:
> Since the upload of mpi-defaults 1.17, switching the default MPI on
> 32-bit architectures, valgrind FTBFS
It seems that valgrind is currently building fine on both armhf and i386
with mpi-defaults 1.17:
https:
Control: retitle -1 toulbar2: FTBFS with doxygen 1.12.0
Control: severity -1 minor
On 2024-08-31 11:41, Paolo Greppi wrote:
> with the upcoming doxygen 1.12.0+ds-1 I am preparing here:
> https://salsa.debian.org/debian/doxygen/-/wikis/home
>
> Of 572 tested packages, only 3 seem to fail the build
On 2024-12-06 05:25, Emanuele Rocca wrote:
> DEB_BUILD_MAINT_OPTIONS=-stackprotector
Apologies, I meant:
DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector
Hi,
On 2024-12-03 12:27, Andres Salomon wrote:
> Currently waiting on #1088699 to fix this.
On arm64 I tried building chromium 131.0.6778.85-1~deb12u1 without stack
protector, and the resulting build does not crash:
DEB_BUILD_MAINT_OPTIONS=-stackprotector
Not ideal, but better than a chromium
Hi Andres,
On 2024-12-03 12:27, Andres Salomon wrote:
> Currently waiting on #1088699 to fix this.
I tried building the affected chromium version using clang from
bookworm-proposed-updates with CC=clang-19 and CXX=clang++-19, and with
the following build-depends bumped:
lld-19, clang-19, cla
Package: chromium
Version: 131.0.6778.85-1~deb12u1
Severity: serious
User: debian-...@lists.debian.org
Usertags: arm64
On arm64 systems, the version of chromium currently in bookworm-security
(131.0.6778.85-1~deb12u1) fails to start with several "stack smashing detected"
errors. The bookworm versi
Source: tiledarray
Version: 1.0.0-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, tiledarray failed to build from source
on both amd64 and arm64 with the following error message:
-- Performing Test EIGEN3_COMPILES - Success
CMake Error at /
Source: seqkit
Version: 2.8.2+ds-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, seqkit failed to build from
source on both amd64 and arm64 with the following error message:
github.com/shenwei356/seqkit/seqkit/cmd
# github.com/shenwei356/se
Source: singularity-container
Version: 4.1.5+ds3-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, singularity-container failed to
build from source on both amd64 and arm64 with the following error
message:
github.com/sylabs/singularity/vendo
Source: nthash
Version: 2.3.0+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, this package failed to build on
arm64. On amd64 it builds correctly.
Here is the error message:
[ 75%] Lin
Source: fiat-ecmwf
Version: 1.4.0-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, this package failed to build on
arm64. On amd64 it builds correctly.
It seems that the build uses /usr/lib/x
Source: dbcsr
Version: 2.6.0-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, this package failed to build on
arm64. On amd64 it builds correctly.
It seems that the build uses /usr/lib/x86_64
Source: coccinelle
Version: 1.2.deb-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, coccinelle failed to build on
arm64 and amd64 with the following error.
[7]
Underfull \hbox (badness 1) in paragraph at lines 76--82
! Missing \cr inse
Source: xserver-xorg-video-trident
Version: 1:1.4.0-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, xserver-xorg-video-trident failed
to build on arm64 with the following error. On amd64 the
Source: xserver-xorg-video-tdfx
Version: 1:1.5.0-5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, xserver-xorg-video-tdfx failed
to build on arm64 with the following error. On amd64 the packag
Source: superlu-dist
Version: 8.2.1+dfsg1-5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, superlu-dist failed to build on
arm64 with the following error. On amd64 the package builds correctly
Source: rocsparse
Version: 5.7.1-5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, rocsparse failed to build
with the following error.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 337,
Source: mfem
Version: 4.7+ds-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, mfem failed to build on arm64
with the following error. On amd64 the package builds correctly.
/usr/bin/ld: warni
Source: elkcode
Version: 9.6.8-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
During a rebuild of all packages in sid, this package failed to build on
arm64. On amd64 it builds correctly.
It seems that the build uses /usr/lib/x86_
Source: groonga
Version: 14.0.5+dfsg-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, groonga failed to build from
source on both amd64 and arm64 with the following error message:
/usr/bin/install: cannot stat './html/_static/webpack-macros.
Source: coreboot
Version: 4.15~dfsg-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
During a rebuild of all packages in sid, this package failed to build on arm64
with the following error. On amd64 the package builds correctly.
accessors/cmos-hw-unix.c: In function ‘cmos_hal_read’
Hi,
On 2024-10-23 11:12, Paul Gevers wrote:
> On 23-10-2024 10:40, Emanuele Rocca wrote:
> > Indeed the simplest repro is just running the following in a sid armhf
> > schroot running on a amd64 host with binfmt qemu-user-static emulation
> > on:
>
> For avoidance of
On 2024-10-22 11:04, Étienne Mollier wrote:
> I just saw the answer from Paul in parallel, and apparently the crash
> condition also occurs in armhf on top of amd64.
Indeed the simplest repro is just running the following in a sid armhf
schroot running on a amd64 host with binfmt qemu-user-static
Hi,
On 2024-10-21 11:53, Étienne Mollier wrote:
> The issue looks very specific to this way of running Xvfb :5,
> other ways I know of within autopkgtests seem to be running fine
> in the same configuration. Quick lookup of open xvfb issues
> suggest that #1084230 could be relevant to the problem
Hi Simon,
On 2024-09-24 09:16, Simon McVittie wrote:
> In a recent upload this failed on armhf, and only armhf: the actual
> tests appear to have all succeeded, but then xvfb-run exited with status
> 1 anyway. I am able to reproduce this on the armhf porterbox amdahl.
>
> A simplified reproducer
Source: mir
Version: 2.14.1-7
Severity: serious
Tags: sid trixie ftbfs
User: debian-...@lists.debian.org
Usertags: arm64 armel armhf
mir fails to build with the following error on arm64, armel, armhf,
alpha, hppa, powerpc and sparc64. The problem can be reproduced with
both GCC 14 and 13, hence it
Hi,
On 2024-08-15 10:46, Andreas Beckmann wrote:
> /usr/lib/llvm-17/include/clang/Basic/TokenKinds.def:23:26: error: pasting
> "kw_" and "[" does not give a valid preprocessing token
>23 | #define KEYWORD(X,Y) TOK(kw_ ## X)
This is a LLVM 17 / GCC 14 regression:
https://bugs.debian.org/10770
Bonjour Cyril,
On 2024-08-20 11:45, Cyril Brulebois wrote:
> I couldn't replicate the FTBFS within a devel sid chroot that has tons of
> extra packages, including python3-packaging, and python3-platformdirs, but
> not python3-jaraco.text.
Could it be that your sid chroot has an older version of
Package: python3-pkg-resources
Version: 72.2.0-1
Severity: serious
X-Debbugs-CC: debian-b...@lists.debian.org
[debian-boot added to CC as this issue breaks d-i builds]
Importing pkg_resources fails with the following error:
(sid-amd64-sbuild)ema@ariel:~$ python3
Python 3.12.5 (main, Aug 7 2
Source: pytorch
Version: 2.1.2+dfsg-4
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-impfuncdef
Dear Maintainer,
pytorch fails to build from source with the following errors:
/<>/torch/csrc/dynamo/eval_frame.c: In function ‘eval_custom_code’:
/<>/to
Package: python3-torch
Version: 2.1.2+dfsg-4
Severity: serious
Hi,
python3-torch cannot be installed in sid:
(sid-amd64-sbuild)ema@ariel:/$ sudo apt install python3-torch
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using
Hi,
On 2024-07-18 11:45, Aurelien Jarno wrote:
> With glibc 2.39, the revert is not possible anymore, therefore I
> rocm-hipamd FTBFS again. I have therefore upgraded the severity to
> serious.
>
> Emanuele Rocca is working on a solution on the upstream LLVM side. In
> the mean
Hello Jeremy and Roland,
On 2024-07-05 01:27, Jeremy Bícha wrote:
> plotpy fails to build on arm64. Because it built once on arm64, its
> build needs to be fixed or you could file a RM bug to remove it only
> on arm64.
I've forwarded the issue upstream [1], and they were quick to come up
with a f
Source: aspectc++
Version: 1:2.3+git20230726-1
Severity: serious
Control: block 1050069 by -1
Dear Maintainer,
aspectc++ build-depends on llvm-14-dev, which is not going to be
part of Trixie. See https://bugs.debian.org/1050069
Please make sure that the package builds with LLVM 18 instead.
Than
Control: tags -1 + patch
On 2024-06-14 10:42, Emanuele Rocca wrote:
> stderr: x86_64-w64-mingw32-gcc: error: unrecognized command-line option
> ‘-mbranch-protection=standard’
Please consider applying the attached patch to fix this FTBFS bug by
using CFLAGS as defined for amd64 instead of
Source: dxvk
Version: 2.3.1-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: pac-bti
dxvk fails to build from source on arm64 due to the aarch64-specific
compiler flag -mbranch-protection=standard leaking into CFLAGS used by
x86_64-w64-mingw32-gcc:
meson.build:1:0: ERROR: Unable t
Hello!
On 2024-06-06 12:48, Bo YU wrote:
> hmm, here I use libdw-dev instead of libunwind-dev as upstream
> suggested. I just have uploaded it to mentor because my mentor did not
> respond to me for a while. Could you help me to try to build it on
> arm64 or armhf again? I have tested it on qemu-u
000
+++ strace-6.8/debian/changelog 2024-06-05 13:09:41.0 +
@@ -1,3 +1,9 @@
+strace (6.8-1.1) unstable; urgency=medium
+
+ * Only use libunwind on amd64 (Closes: #1070853)
+
+ -- Emanuele Rocca Wed, 05 Jun 2024 13:09:41 +
+
strace (6.8-1) unstable; urgency=medium
* Team upload.
d
Hi Paul,
On 2024-04-06 11:38, Paul Gevers wrote:
> I noticed you "binNMU"-ed siridb-server in Ubuntu where it built
> successfully on all arches. In Debian I got the bug below reported. Any idea
> what the difference could be between the state of Debian and the state of
> Ubuntu that causes this?
Hey,
On 2023-11-05 04:12, Hervé Werner wrote:
> I faced this issue on real data but I struggled to find a reliable scenario
> to reproduce it. Here is what I just came up with:
> sudo mkfs -t ext4 -O fast_commit,inline_data /dev/sdb
> sudo mount /dev/sdb /mnt/
> sudo install -d -o myuser /m
angelog 2024-03-12 12:14:12.0 +0100
+++ cfengine3-3.21.4/debian/changelog 2024-04-18 11:32:38.0 +0200
@@ -1,3 +1,10 @@
+cfengine3 (3.21.4-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * d/patches/time-t-long-long.patch: coerce time_t to long long (closes: #1068665)
+
+ -- Eman
Hi Roland,
On 2024-03-05 03:15, Roland Mas wrote:
> close 1063631 5.0.0.3381-2
The version of hkl currently in unstable, 5.0.0.3381-1, fails to build.
Would it be possible to upload 5.0.0.3381-2 to unstable?
Emanuele
00 +0200
@@ -1,3 +1,11 @@
+amberol (0.10.3-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Update build dependencies: librust-lofty-0.18-dev,
+librust-mpris-server-0.7-dev. (Closes: #1064531)
+
+ -- Emanuele Rocca Fri, 12 Apr 2024 12:23:35 +0200
+
amberol (0.10.3-2) u
+0200
@@ -1,3 +1,10 @@
+mathgl (8.0.1-8) unstable; urgency=medium
+
+ * Build-depend on python3-all to ensure all supported python versions are
+installed when running debian/tests/run-tests. (Closes: #1067367)
+
+ -- Emanuele Rocca Thu, 11 Apr 2024 15:00:39 +0200
+
mathgl (8.0.1-7) un
.
+ * Apply upstream patch to fix FTBFS on armhf/armel (Closes: #1067829)
+
+ -- Emanuele Rocca Thu, 28 Mar 2024 16:56:19 +0100
+
nfs-utils (1:2.6.4-3) unstable; urgency=medium
[ Salvatore Bonaccorso ]
diff -Nru nfs-utils-2.6.4/debian/patches/flushtime-long-long-int.patch nfs-utils-
Hi Andreas,
On 2024-03-19 10:40, Andreas Tille wrote:
> Since you all pinged that bug we now have another 4 weeks of time before
> anything gets removed from testing. So we just need to bear the noise
> from testing removal warnings of quite some packages (which I'd love to
> get rid of thus uplo
Hi,
On 2024-03-19 06:24, Sébastien Jodogne wrote:
> Because of bug #1060104, a large majority of the packages related to
> medical imaging have just disappeared from Debian Unstable.
>
> But, if I correctly understand #1060104, it is specific to one single
> platform (armel).
Indeed, and there
Source: grok
Version: 1.20110708.1-7.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t
Hi,
grok fails to build from source if -Werror=implicit-function-declaration
is on. The flag was added to the default ones on armhf and armel to help
with the ongoing time64 wor
Source: fakeroot
Version: 1.34-1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t
Hi,
fakeroot fails to build on armhf and armel when compiled with the time64
flags:
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-Werror=implicit-function-declaration
Source: mongo-c-driver
Version: 1.26.0-1.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t
Dear Maintainer,
mongo-c-driver fails to build from source on armhf. The failure may be
explained with the build flags introduced for the time64 migration,
which are on by d
Hi Michael,
On 2024-03-01 09:13, Michael Tokarev wrote:
> This has nothing to do with time64.
Yes and no. :-)
> The prob here is -Werror=implicit-function-declaration
>
> Where that flag is coming from?
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=ef90821fe45b99fa8c8c4279b9a74c30f59f491d
Source: udns
Version: 0.4-1.1
Severity: serious
Tags: ftbfs
User: debian-de...@lists.debian.org
Usertags: time64
Dear Maintainer,
udns fails to build on both armhf and armel with the time64 build flags, which
are on by default. It builds fine without.
Specifically, the following flags cause a fa
Source: google-perftools
Version: 2.15-1.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertag: time64
Dear Maintainer,
google-perftools fails to build from source when building with -D_TIME_BITS=64
on armhf and armel with the following error:
src/mmap_hook.cc:309:31: error:
On 2024-03-01 10:28, Emanuele Rocca wrote:
> /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed
> only with _FILE_OFFSET_BITS=64"
>26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
> | ^
The build
Source: v4l-utils
Version: 1.26.1-3.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertag: time64
Dear Maintainer,
v4l-utils fails to build from source on armhf and armel with the
following error:
In file included from /usr/include/features.h:393,
from
/usr/
Hi,
On 2024-02-08 02:06, Colin Watson wrote:
> On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote:
> > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
> > >Perhaps this is related to the fact that 1.224 dropped the binary
> > >package console-s
Source: pycurl
Version: 7.45.2-7
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs
Dear Maintainer,
pycurl currently fails to build from source on amd64 and arm64 with the
following error:
=== F
Source: lsof
Version: 4.95.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs
Dear Maintainer,
lsof currently fails to build from source on amd64 and arm64 with the following
error:
Optional tests:
LTbigf ... OK
LTdnl
Source: console-setup
Version: 1.224
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs
Dear Maintainer,
console-setup 1.224 fails to build from source with the following error:
Dumping the encoded keymaps for pc105...
WARN
Source: libcap-ng
Version: 0.8.4-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
libcap-ng currently FTBFS with the following error:
make[6]: Entering directory '/<>/build-py3.11/bindings/python3'
cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' >
caps.h
cat ../../../s
Hi,
On 2024-02-04 08:47, Paul Gevers wrote:
> With a recent upload of gcc-defaults the autopkgtest of mosquitto fails in
> testing when that autopkgtest is run with the binary packages of
> gcc-defaults from unstable on armel. It passes when run with only packages
> from testing. In tabular form:
specific build flags.
+ Closes: -1.
+
+ -- Emanuele Rocca Tue, 06 Feb 2024 20:23:38 +0100
+
gdb-mingw-w64 (13) unstable; urgency=medium
* Switch from the obsolete libncurses5-dev build-dependency to
diff -Nru gdb-mingw-w64-13/debian/rules gdb-mingw-w64-13+nmu1/debian/rules
--- gdb-mingw-w64-13/deb
Source: gcc-14
Version: 14-20240201-2
Severity: serious
Tags: sid ftbfs
User: debian-...@lists.debian.org
Usertags: arm64
gcc-14 currently FTBFS on arm64 due to an upstream regression. Last known
working version was 20240131.
during GIMPLE pass: widening_mul
../../src/gcc/value-range-storage.cc:
load.
+ * Don't run autopkgtests on armhf due to valgrind bug #1061496. (Closes: #XXX)
+
+ -- Emanuele Rocca Fri, 26 Jan 2024 11:02:37 +0100
+
sndfile-tools (1.5-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru sndfile-tools-1.5/debian/tests/control sndfile-tools-1.5/debian/tests/
@@ -1,3 +1,11 @@
+libvorbis (1.3.7-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable test-coupling-segfault on armhf due to valgrind bug #1061496.
+(Closes: #XXX)
+
+ -- Emanuele Rocca Thu, 25 Jan 2024 16:25:09 +0100
+
libvorbis (1.3.7-1) unstable; urgency=medium
now that #1057693 is fixed.
+
+ -- Emanuele Rocca Thu, 25 Jan 2024 12:29:55 +0100
+
libgssglue (0.8-2) unstable; urgency=medium
* Disable valgrind in i386 due to #1057693.
diff -Nru libgssglue-0.8/debian/tests/control libgssglue-0.8/debian/tests/control
--- libgssglue-0.8/debian/tests
Source: kbtin
Version: 2.1-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Hi,
kbtin currently fails to build from source on armhf. The failure is due
to an incompatibility between valgrind and stack-clash-protection on
32bit arm reported upstream at:
Source: jtdx
Version: 2.2.159-1
Severity: serious
Tags: ftbfs, patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Dear Maintainer,
jtdx currently fails to build from source on armel. To address the
immediate issue, please disable stack-clash-protection with the
following snippet i
Hi Mathieu,
On 2024-01-14 11:24, Mathieu Malaterre wrote:
> On Sat, Jan 13, 2024 at 9:42 PM Emanuele Rocca wrote:
> > We should downgrade the severity to minor once the fix enters unstable, but
> > keep the bug open as this seems to be an interesting case of
> > s
Control: user -1 debian-...@lists.debian.org
Control: usertag -1 + 32bit-stackclash
Hi,
On Fri, Jan 05, 2024 at 11:45:28PM +0100, Sebastian Ramacher wrote:
> /tmp/ccm0eYhx.s: Assembler messages:
> /tmp/ccm0eYhx.s:537: Error: bad immediate value for offset (4100)
This is caused by stack-clash-pro
Source: dumpasn1
Version: 20210212-3
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Hi,
dumpasn1 currently fails to build from source on armhf. The failure is due to
an incompatibility between valgrind and stack-clash-protection on 32bit arm
reported up
Source: abinit
Version: 9.10.4-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash
Dear Maintainer,
abinit currently fails to build from source on armhf. To address the immediate
issue, please disable stack-clash-protection with the following snippet in
de
Hi Julian!
On 2024-01-12 01:47, Julian Andres Klode wrote:
> Either way, these are harmless
I'm not saying they're harmful, what I'm saying is:
1) the errors you see on armhf when building apt without
stack-clash-protection are the same valgrind reports on amd64 as
well. Hence, you could c
Hi Julian,
On 2024-01-11 05:46, Julian Andres Klode wrote:
> And there aren't any hard errors. We could zero initialize
> those or add supressions to make things look nicer I suppose.
Mmmh no, they are all actual errors as far as valgrind is concerned.
The thing is, you're running valgrind witho
Hi Julian,
On 2024-01-08 10:28, Julian Andres Klode wrote:
> (in Ubuntu we have partially recovered by disabling stack clash
> protection but it crashes on invalid writes there, I suppose we need
> to rebuild some more apt dependencies without the flag...).
The 'invalid writes' issue seems unrela
I've added more context to https://bugs.debian.org/1059352#38, but just to have
some info here too this is the error:
722s ==221367== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
722s ==221367== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright
info
722s ==221367==
Control: retitle -1 valgrind: Access not within mapped region on armhf
Hello Paul and Julian,
On 2023-12-24 07:31, Paul Gevers wrote:
> On 23-12-2023 20:40, Julian Andres Klode wrote:
> > the logs for well known bugs so that you don't end up filing bugs
> > against every package broken by valgrin
Hi,
On 2023-12-04 03:10, Ben Hutchings wrote:
> The D and W flags mean there were prior BUG and WARN errors logged.
> Please send those as well.
Here is the very first warning:
Nov 30 17:16:45 ci-worker-armhf-03 kernel: WARNING: CPU: 10 PID: 1592 at
fs/dcache.c:365 dentry_free+0x98/0xd0
Control: retitle -1 systemtap: FTBFS with g++-13 on i386, ppc64el, riscv64
On 2023-12-01 04:53, Emanuele Rocca wrote:
> In constructor ‘symresolution_info::symresolution_info(systemtap_session&,
> bool)’,
> inlined from ‘int semantic_pass_symbols(systemtap_session&)’ at
>
Package: systemtap
Version: 5.0-1
Severity: serious
g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"'
-DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"'
-DLOCALEDIR='"/usr/share/locale"' -DDOCDIR='"/usr/share/doc/systemtap"'
-DPYEXECDIR='""' -DPY3EXECDIR
Hi!
On 2023-11-09 05:11, Rafael Laboissière wrote:
> The Fortran example x09f.f90, which is exercised during the building of
> plplot, now fails on armhf, due to the use of the compiler option
> -fstack-clash-protection.
The problem seems unrelated to stach-clash-protection I think, enabling
the
Hello Andrius,
On 2023-09-09 08:38, Andrius Merkys wrote:
> This is news to me. Could you please point out where in Debian Policy I can
> read more about such requirement? I thought I saw packages dropping support
> for one or another release architecture without being removed from testing.
See h
Control: retitle -1 asmjit: FTBFS on armel and armhf
Hi Andrius,
On 2023-08-28 07:42, Andrius Merkys wrote:
> On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca wrote:
> > asmjit does not build correctly on the following architectures:
> > armel, armhf, mips64el, mipsel, s390x.
Hallo Andreas,
On Fri, Aug 25, 2023 at 11:28:16AM +0200, Andreas Tille wrote:
> Am Wed, Aug 16, 2023 at 03:43:24PM +0200 schrieb Emanuele Rocca:
> > btllib currently fails to build from source on armhf with the following
> > tests-related error:
>
> Armhf (as well as all o
Hi,
On 2023-08-25 09:46, Graham Inggs wrote:
> On Fri, 25 Aug 2023 at 09:03, Andreas Tille wrote:
> > upstream does not support 32bit and the usage of this package on 32bit is
> > questionable anyway so please remove all 32bit builds of this package.
>
> Andreas, what 32-bit builds? bbhash has
Source: cpu-features
Version: 0.7.0-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-...@lists.debian.org
Usertags: armhf armel
Hi,
cpu-features fails to build on armhf and armel with the following error:
In file included from /<>/test/cpuinfo_aarch64_test.cc:15:
/<>/test/../include/cpuin
Hi!
On 2023-08-21 07:36, Adam Borowski wrote:
> On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> > Well FTBFS is a bug isn't it? :-)
>
> A FTBFS on an architecture that has built before (and hasn't been RMed)
> is a bug, and one that's polici
Control: retitle -1 cpp-httplib: FTBFS on s390x, armhf due to flaky tests
Hi,
On 2023-07-24 04:26, Andrea Pappacoda wrote:
> I've looked into this, but I couldn't find any change which would
> cause test failures on s390x specifically. cpp-httplib's test suite
> is a bit flaky though, so it may
Hi Adam,
On 2023-08-16 05:14, Adam Borowski wrote:
> This is not a regression, thus why would it be a bug?
Well FTBFS is a bug isn't it? :-)
> There's nothing in birdtray itself that would prevent it from being built on
> these architectures the moment problems in thunderbird are resolved
Why d
Hi Matthias,
On 2023-08-18 06:46, Matthias Klose wrote:
> still ftbfs on arm64 and armhf. would it be possible to pay attention to
> build failures after uploads, or even better to pay attention until the
> package migrates?
See https://bugs.debian.org/1037579#43
We are currently packaging the l
Source: coinor-bonmin
Version: 1.8.9-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
coinor-bonmin fails to build with the following error:
g++ -shared -nostdlib
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o .libs/BonCbc.o
.libs
Source: cctz
Version: 2.3+dfsg1-3
Severity: serious
Tags: sid trixie ftbfs
Hi,
cctz fails to build with the following error message:
75% tests passed, 1 tests failed out of 4
Total Test time (real) = 30.25 sec
The following tests FAILED:
2 - time_zone_lookup_test (Failed)
Errors whi
Source: coccinelle
Version: 1.1.1.deb-3
Severity: serious
Tags: sid ftbfs
User: debian-...@lists.debian.org
Usertags: armhf
Hi,
coccinelle fails to build from source on armhf with a "out of memory"
error.
(1) The error seems to be a red herring given that the machine on
which I'm building the pa
Source: btllib
Version: 1.4.10+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
Hi,
btllib currently fails to build from source on armhf with the following
tests-related error:
Iteration 1
Test FASTA
Source: birdtray
Version: 1.9.0+ds-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
Hi,
birdtray is 'Architecture: any' and build-depends on thunderbird.
However, armhf, armel, and mipsel are not in thunderbird's architecture
list. For this reason birdtray cannot be build on those
1 - 100 of 151 matches
Mail list logo
