: armhf
User: debian-arm@lists.debian.org
Usertags: armhf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear ftpmasters,
please remove src:marble on armhf. It previously OOM'd there, even with
d/rules workarounds in place. I uploaded a version depending on a
non-existant armhf package, so
...@lists.debian.org,
debian-powe...@lists.debian.org, debian-sup...@lists.debian.org, Package
Salvaging Team , Ari Pollak
Control: affects -1 + src:jnettop
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-arm@lists.debian.org
Usertags: armel armhf
User: debian...@lists.debian.org
...@lists.debian.org,
debian-sup...@lists.debian.org, Package Salvaging Team
Control: affects -1 + src:genwqe-user
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-arm@lists.debian.org
Usertags: armel armhf
User: debian...@lists.debian.org
Usertags: i386
User: debian-m
Control: severity -1 important
Control: unblock 1094845 by -1
Control: user debian-arm@lists.debian.org
Control: usertags -1 armel
This build failure was a result of a packaging change where we now
install mesa-vulkan-drivers which enabled running additional tests.
Since there is no regression her
Source: gtk4
Version: 4.17.3+ds-1
Severity: serious
Tags: experimental ftbfs
User: debian-arm@lists.debian.org
Usertags: armhf
X-Debbugs-CC: debian-arm@lists.debian.org
Two of gtk4's build tests are failing with gtk4 4.17.3 in experimental
on armel and armhf but appear to pass on Debian'
On Tue, Jan 28, 2025, at 10:39, Jérémy Lal wrote:
> Le mar. 28 janv. 2025 à 10:21, Arnd Bergmann a écrit :
>> On Tue, Jan 28, 2025, at 09:38, Jérémy Lal wrote:
>> > Le mar. 28 janv. 2025 à 09:29, Arnd Bergmann a écrit :
>>
>> Can you debug into this file on i386 to see which symbol
>> it picks u
Le mar. 28 janv. 2025 à 10:21, Arnd Bergmann a écrit :
> On Tue, Jan 28, 2025, at 09:38, Jérémy Lal wrote:
> > Le mar. 28 janv. 2025 à 09:29, Arnd Bergmann a écrit :
> >>
> >> The bit I don't understand is why libuv was ever getting built
> >> without largefile support. It probably makes sense t
On Tue, Jan 28, 2025, at 09:38, Jérémy Lal wrote:
> Le mar. 28 janv. 2025 à 09:29, Arnd Bergmann a écrit :
>>
>> The bit I don't understand is why libuv was ever getting built
>> without largefile support. It probably makes sense to change that
>> for all architectures regardless of time64 suppor
Le mar. 28 janv. 2025 à 09:29, Arnd Bergmann a écrit :
> On Mon, Jan 27, 2025, at 19:31, Jérémy Lal wrote:
> > Le lun. 27 janv. 2025 à 17:41, Arnd Bergmann a écrit :
> >> On Mon, Jan 27, 2025, at 15:19, Jérémy Lal wrote:
> >>
> >>if ((sizeof(long)< sizeof(off_t))
> >> p = dlsym(R
On Mon, Jan 27, 2025, at 19:31, Jérémy Lal wrote:
> Le lun. 27 janv. 2025 à 17:41, Arnd Bergmann a écrit :
>> On Mon, Jan 27, 2025, at 15:19, Jérémy Lal wrote:
>>
>>if ((sizeof(long)< sizeof(off_t))
>> p = dlsym(RTLD_DEFAULT, is_pread ? "preadv64" : "pwritev64");
>>else
>>
Le lun. 27 janv. 2025 à 17:41, Arnd Bergmann a écrit :
> On Mon, Jan 27, 2025, at 15:19, Jérémy Lal wrote:
> > Hi,
> >
> > as discussed in
> > https://github.com/libuv/libuv/issues/4678
> >
> > and associated build failures
> > https://buildd.debian.org/status/package.php?p=libuv1&suite=experimen
On Mon, Jan 27, 2025, at 15:19, Jérémy Lal wrote:
> Hi,
>
> as discussed in
> https://github.com/libuv/libuv/issues/4678
>
> and associated build failures
> https://buildd.debian.org/status/package.php?p=libuv1&suite=experimental
>
> It seems that gcc is doing something wrong with the offset param
Hi,
as discussed in
https://github.com/libuv/libuv/issues/4678
and associated build failures
https://buildd.debian.org/status/package.php?p=libuv1&suite=experimental
It seems that gcc is doing something wrong with the offset parameter of
preadv, pwritev.
The same problem happens with optimizatio
]: *** [Makefile:1657: tmp/moc_qsocketnotifier_hook.cpp]
Segmentation fault
Note, the first build works, only the 2nd one fails!
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/libqt6pas.html
Regards,
Peter
Hi,
On Thu, Aug 15, 2024 at 7:21 PM Chris Hofstaedtler wrote:
>
> Hi,
>
> 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
> o
On 2024-08-16 10:25, Emanuele Rocca wrote:
> Martin, I think you and your employer were looking for ways to help the
> armhf/armel ports. This looks like a great one! :)
Noted ;-)
Source: libgrokj2k
Version: 0.0.5-1
Severity: serious
X-Debbugs-Cc: debian-arm@lists.debian.org
This package failed to build against Perl 5.40 on armhf.
It built fine in March, and the error looks unrelated to Perl.
https://buildd.debian.org/status/logs.php?pkg=libgrokj2k&arch=armhf
ded, it creates
> /tmp/.X11-unix as a side-effect, and then by the time mutter needs it,
> it already exists and all is well.
>
> But, on armhf with the current libunwind8 from unstable, Xvfb is crashing,
> so it doesn't get far enough to create /tmp/.X11-unix; but for whatever
&g
> > "/tmp/.X11-unix" is not writable
Actually, this might be another symptom of #1082659, a libunwind8
regression on armhf (which either doesn't affect arm64, or is masked by
the fact that the new libunwind FTBFS on arm64, #1082284). It looks as
though that regression doesn&#
On Sat, 05 Oct 2024 at 17:35:46 +0200, Aurelien Jarno wrote:
> Everything is fine on the buildds side. Both arm64 and armhf chroots on
> the above buildds have an empty 1777 root:root /tmp directory.
...
> Chroots are created identically in schroot and unshare mode. /tmp is
> part o
> User: debian-arm@lists.debian.org
> Usertags: armhf
> Control: block 1081519 by -1
>
> The recent upload of mutter in unstable FTBFS on multiple armhf buildds:
> arm-ubc-01, arm-conova-03, arm-ubc-05. Interestingly, the arm64 build on
> one of the same buildds (arm-conova-03) was succ
Source: mutter
Version: 47.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-arm@lists.debian.org, ar...@buildd.debian.org
User: debian-arm@lists.debian.org
Usertags: armhf
Control: block 1081519 by -1
The recent
Source: chatty
Version: 0.8.5-1
Severity: serious
Tags: ftbfs
User: debian-arm@lists.debian.org
Usertags: armhf
X-Debbugs-CC: debian-arm@lists.debian.org
chatty was recently rebuilt for the libspelling transition but it
fails to build on armhf.
Some major changes that have happened in the past
Package: libunwind8
Version: 1.7.2-1
Severity: serious
Justification: results in FTBFS in unrelated packages
X-Debbugs-Cc: debian-arm@lists.debian.org
User: debian-arm@lists.debian.org
Usertags: armhf
The test suite for the libportal package, like many packages that use
GUI libraries, is run
Source: libportal
Version: 0.8.1-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-arm@lists.debian.org
User: debian-arm@lists.debian.org
Usertags: armhf
My recent libportal upload repeatably fails to build on
On 2024-09-16, at 15:18:27 +0200, Andreas Tille wrote:
> Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> > Try this patch.
>
> Works.
>
> Thanks a lot for the quick help
A quick follow-up now I have more time. The definition of `struct
input_event` in /usr/include/linux/input.h
Hi Jeremy,
Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> Try this patch.
Works.
Thanks a lot for the quick help
Andreas.
--
https://fam-tille.de
TBFS
> for several 32bit architectures (not only armhf) remains[2].
>
> Since I have no experience with these architectures I'd kindly ask for
> help here.
>
> Kind regards
> Andreas.
>
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-ta
Control: tags -1 help
Control: tags -1 confirmed
Thanks
Hi,
since input-utils showed up as Bug of the Day[1] I worked down the list
of bugs including upgrading to latest upstream. Unfortunately the FTBFS
for several 32bit architectures (not only armhf) remains[2].
Since I have no experience
Source: gnome-snapshot
Version: 47~beta-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-arm@lists.debian.org
Usertags: armel armhf
X-Debbugs-CC: debian-arm@lists.debian.org, debian-r...@lists.debian.org
The
On Mon, Aug 26, 2024 at 06:46:35AM +0200, Mechtilde Stehmann wrote:
> > I'll note that fakeroot was probably broken on armel, armhf since
> > the t64 migration until mid-August.
> > Is fakeroot involved in any way? If so, it might make sense to
> > discard any resul
Hello Chris,
Am 26.08.24 um 00:05 schrieb Chris Hofstaedtler:
[..]
Dates are 2022-06-08 as expected and not 1970-01-03 as described
at tests.rb.o.
[..]
https://tests.reproducible-builds.org/debian/history/armhf/vinnie.html
I briefly looked at vinnie. Given it is arch:all, I kinda expect
[..]
> Dates are 2022-06-08 as expected and not 1970-01-03 as described
> at tests.rb.o.
[..]
> > https://tests.reproducible-builds.org/debian/history/armhf/vinnie.html
I briefly looked at vinnie. Given it is arch:all, I kinda expect it
to produce the "same" deb regard
Hello Vagrant,
in the meantime I did a build at amdahl.debian.org and can't reproduce
the problem too.
i did it with this package
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/csvjdbc.html
Dates are 2022-06-08 as expected and not 1970-01-03 as described at
tests
Hello,
in the meantime I did some more tests to find the reason for it.
I build it again with pbuilder specifying ARCH=armhf and get the right
date for the pom file (same date as the amd64 build)
Now I think I need access to an armhf box to test it natively.
What should I do to get
user debian-arm@lists.debian.org
usertag 1079443 time-t
thanks
Hi debian-arm,
in case you don't know yet, here is a bug affecting dracut-install
on armhf (and probably armel), causing the built initramfs to lack a
lot of kernel modules. Probably makes a lot of things unbootable.
It looks
is an archive rebuild and running the
autopkgtests for all packages.
Martin, I think you and your employer were looking for ways to help the
armhf/armel ports. This looks like a great one! :)
Emanuele
Hi,
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 later).
I believe FTBFS are bugs are probably caught by periodic rebuilds
do
Control: reopen -1
On Sun, Aug 11, 2024 at 10:36:40PM +0200, Chris Hofstaedtler wrote:
> I've done some light tests on arm64 and emulated armhf, but
> additional tests would be very helpful.
Seems like that wasn't enough and on the buildds the build-time
tests fail:
PASS:
debian-arm,
please help testing fakeroot/experimental, which fixes the FTBFS on
armel, armhf. Please test it.
I've done some light tests on arm64 and emulated armhf, but
additional tests would be very helpful.
> Changes:
> fakeroot (1.35.1-1.2) experimental; urgency=medium
>
Hi,
Am 28.07.24 um 18:38 schrieb Rene Engelhard:
see
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0~rc2-1&stamp=1722178361&raw=1:
build CXX] bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
S=/<> && I=$S/instdir &&
On 2024-07-28 Adrian Bunk wrote:
> On Sun, Jul 28, 2024 at 06:38:01PM +0200, Rene Engelhard wrote:
[...]
> > /<>/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:278:5:
> > error: ‘asm’ operand has impossible constraints or there are not enough
> > registers
> > 278 | __asm__ __volatile__
On Sun, Jul 28, 2024 at 06:38:01PM +0200, Rene Engelhard wrote:
> [ Ccing libreoffice upstream ]
[ Cc changed for this reply ]
> Hi,
>
> see
> https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0~rc2-1&stamp=1722178361&raw=1:
[ Ccing libreoffice upstream ]
Hi,
see
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0~rc2-1&stamp=1722178361&raw=1:
build CXX] bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
S=/<> && I=$S/instdir && W=$S/workdir &a
On 2024-07-28 14:27, Jeffrey Walton wrote:
On Sun, Jul 28, 2024 at 7:47 AM Drew Parsons
wrote:
I've uploaded an NMU for uid-wrapper 1.3.0-5.1 to skip the syscall
gettimeofday test on __arm__, since armel and armhf are returning
tv_sec=0 from the syscall. Obviously replace the patch w
ofday system calls on 32-bit ARM.
> >
> > cc:ing ARM porters. Can you advise on the 32-bit arm test failure
> > reported in Bug#1069425 ?
> > SYS_gettimeofday is returning zero time.
>
> I've uploaded an NMU for uid-wrapper 1.3.0-5.1 to skip the syscall
> get
test failure
reported in Bug#1069425 ?
SYS_gettimeofday is returning zero time.
I've uploaded an NMU for uid-wrapper 1.3.0-5.1 to skip the syscall
gettimeofday test on __arm__, since armel and armhf are returning
tv_sec=0 from the syscall. Obviously replace the patch with a better
fix i
Given the timing of the test failure, my guess is that uid-wrapper is a
casuality of the time_64 transition. It looks like something is amiss
with the __NR_gettimeofday system calls on 32-bit ARM.
cc:ing ARM porters. Can you advise on the 32-bit arm test failure
reported in Bug#1069425 ?
SY
Source: rust-ntp-os-clock
Version: 1.1.3-1
Severity: serious
Tags: ftbfs
User: debian-arm@lists.debian.org
Usertags: armel armhf
X-Debbugs-CC: debian-arm@lists.debian.org, sylves...@debian.org
The new version of rust-ntp-os-clock fails to build on armel & armhf.
(It looks like the same erro
Source: ffmpeg
Version: 7:6.1.1-4
Severity: serious
Tags: ftbfs
User: debian-arm@lists.debian.org
Usertags: armel armhf
X-Debbugs-CC: debian-arm@lists.debian.org
ffmpeg is failing to build on armel & armhf (but not arm64). This was
noticed while rebuilding ffmpeg for the ongoing jpeg-xl
Hi Guillem,
On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote:
> > I had a look at this, and it seems like this package has never really
> > worked on ARM systems at all? And this was hidden due to the missing
> > declarations not being an error.
> >
> > AFAIK, only x86 (i386 and amd64), ia6
ous
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf
>
> > During a rebuild of all packages in sid, your package failed to build
> > on armhf.
> > Relevant part
Hi,
On 2024-05-17 14:46, Adam D. Barratt wrote:
> Source: linux
> Version: 6.7.12-1~bpo12+1
> Severity: serious
> X-Debbugs-CC: debian-arm@lists.debian.org
> X-Debbugs-CC: d...@debian.org
>
> Hi,
>
> armhf builds of the bookworm-backports kernel appear to have
.reproducible-builds.org/debian/history/armhf/vinnie.html
It is only very recently that this started happening (2024-05-04)
without source changes in vinnie itself, so I would suspect some change
in the toolchain used to produce the .pom files?
commons-email is similar, although start
;
is.close();
df.setLastModified(sf.lastModified());
}
}
… on armhf with OpenJDK 8, 17 and 21 (11 needs t64-transitioning).
Given the range of January 1970…
$ TZ=UTC date -d '1970-01-31T23:59:59Z' +%s
2678399
$ TZ=UTC date -d @2678399000
Sun Nov 15 23:43:20 UTC 2054
…
Hello,
I want to clean up my Java packages.
There are several with FTBR. I found that the day of the *.poms s a date
from 1970.
for example they are the packages
vinnie
commons-email
ez-vcard
...
and so on
Can you give me/a hint to fix this behaviour.
Kind regards
--
Mechtilde Stehmann
##
-21-jdk-headless:armel
openjdk-21-jdk-headless depends on:
- openjdk-21-jre-headless:armel (= 21.0.2+13-2)
openjdk-21-jre-headless depends on:
- libcups2:armel
libcups2t64 conflicts with:
- libcups2:armel (< 2.4.7-1.2)
Dependency installability problem for openjdk-21 on armhf:
openjdk-21 bu
Wookey dixit:
>And it worked beatifully. Thanks.
Nice!
>I'll try doing openjdk-20 next.
You’ll want 21 as 20 has not got the t64 treatment.
gl hf,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
inaries is very useful
> >too to satisfy the self-dependency without more faff.
>
> Yes, that was their purpose.
And it worked beatifully. Thanks.
armhf and armel uploaded and accepted half an hour ago (armel built by Andrey
Rakhmatullin)
I'll try doing openjdk-20 next.
Woo
Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already
moved to 17.0.11~7ea.orig.tar.*
>So I now have all the pieces (on armhf, not checked armel yet but
>hopefully it matches)
Depends, but 'apt install /tmp/*.deb' will tell you ;-)
>The build failed:
>
>An excep
On 2024-03-27 15:27 +, Wookey wrote:
> On 2024-03-26 22:28 +, Thorsten Glaser wrote:
>
> > I hacked that, and I tried to do armel and armhf as well but
> > dak stopped me, whereas mini-dak was not as strict.
>
> What was the actual problem with uploading the imag
On 2024-03-26 22:28 +, Thorsten Glaser wrote:
> I hacked that, and I tried to do armel and armhf as well but
> dak stopped me, whereas mini-dak was not as strict.
What was the actual problem with uploading the images you built? Just
not having any corresponding source? Or somethin
ed at the amount of users wanting 8, so
I now provide those in a private repo of mine, but so far
amd64/i386-only has sufficed for those. For the purposes
for which 8 is still in sid, dropping armel and armhf will
_most likely_ also suffice; ELTS still wants them, but
rebuilt in jessie and stretch chroots so there is no re‐
bootstrapping to be done.)
On 2024-03-26 10:35 +, Simon McVittie wrote:
> It seems that some of the dependency chains for packages that are still
> waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
> default Java version for most architectures and Build-Depends on itself
> (with an
On Tue, 26 Mar 2024, Jeffrey Walton wrote:
>Nothing beats a native compile in your basement.
Yes, definitely.
>> Do they run stock Debian armhf?
>
>So the CubieTruck is embarrassingly down level:
Oofff…
>The Wandboard is doing better:
Right, close enough anyway.
>I d
asts 6 to 9 months before you start seeing
unexplained file system errors. That's around the time you know it's
time to replace the SDcard.
> Do they run stock Debian armhf?
So the CubieTruck is embarrassingly down level:
cubietruck:~$ lsb_release -a
Distributor ID: Linaro
Description:
ight on them, but with
swap the compiling should work. Both seem to have serial console, good.
Do they run stock Debian armhf?
Thanks,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser wrote:
>
> [...]
>
> The options for the armel/armhf porters are to either get the
> .debs from me, install them in a chroot, and then the other B-D,
> and rebuild the packages, or to use dpkg --force-depends to
> install th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I
It seems that some of the dependency chains for packages that are still
waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
default Java version for most architectures and Build-Depends on itself
(with an alternative dependency on openjdk-16, but that no longer exists
Source: git
Version: 1:2.43.0-1
X-Debbugs-Cc: debian-arm@lists.debian.org
Severity: wishlist
Tags: trixie sid patch
Hi,
on armhf and armel both subversion and libsvn-perl are currently not
installable due to the ongoing 64-bit time_t transition. It seems
however that git builds fine without
Package: at-spi2-core
Version: 2.51.90-3
Severity: important
X-Debbugs-Cc: debian-arm@lists.debian.org
Tags: patch
at-spi2-core has a circular build-dependency on itself when tests are
enabled, which makes its build-dependencies unsatisfiable (libglib2.0-dev
depends on libglib2.0-0t64, but at-spi2
e whole Debian
archive, 4 packages fail to build because of stackclash on armhf and 2
on armel. Additionally, 5 packages have failing autopkgtests.
The main issue really is the open valgrind bug on armhf when checking
programs built with stack-clash-protection:
https://bugs.debian.org/1061496
No problem o
On 2024-01-17 09:33, Matthias Klose wrote:
> Package: src:h5py
> Version: 3.10.0-1
> Severity: serious
> Tags: sid trixie
>
> armhf: h5py's tests expose unaligned memory accesses during the build, this
> not seen with with the 3.9.0 version. You don't see this
Hi,
I finally got time to perform those archive rebuilds.
Results are available at http://qa-logs.debian.net/2024/01/11/
I did a first archive rebuild (all packages on arm64, armhf, armel), and
then did a second one, restricted to packages that failed at on at least
one architecture.
Results in
On Thu, Nov 23, 2023 at 10:45:33AM +0100, Matthias Klose wrote:
> Hi,
>
> it looks like enabling this flag on armel/armhf is a little bit premature.
>
> Apparently it's not completely supported upstream, and might cause
> regressions, according to
> https://bugzilla.
Control: tags -1 + help
On Tue, 08 Nov 2022 at 09:47:15 +, Simon McVittie wrote:
> On Mon, 07 Nov 2022 at 21:51:05 +0100, Paul Gevers wrote:
> > # Executing: glib/threadtests.test
> > # Executing: glib/threadtests.test
> > # Executing: glib/threadtests.test
> > not ok - Test timed out after 30
On 2023-12-04 Emanuele Rocca wrote:
> 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 s
as illegal accesses because they occur below the stack pointer address.
However, stack probes don't actually care about the contents - just that
the address is valid.
When it comes to armel, valgrind is not supported altogether.
I have added a suppression to valgrind 1:3.20.0-2 on armhf, which
most of the testsuite fail, including this trivial test:
This is due to -fstack-clash-protection now being enabled through
buildflags (it was actually enabled on armhf after amd64 and arm64);
gnutls was rebuilt with it and this reliably causes issues under
valgrind.
The actual cause is a bit un
the above in my tests.
Also the packages don't seem to use valgrind at any point: not when
building, not in the autopkgtests.
Full build logs including autopkgtest output here:
https://people.debian.org/~ema/armhf-stack-clash-protection/
What exactly did not work in Ubuntu and how? Perhaps ther
Hello,
That is the same issue we had in Ubuntu, and is caused by the recent
addition of the -fstack-clash-protection compiler flag.
There is an earlier thread discussing exactly this on debian-arm.
Mate Kukri
On 12/3/23 17:20, Andreas Metzler wrote:
Hello,
gnutls28 is currently blocked fro
Hello,
gnutls28 is currently blocked from testing because gsasl's autopkg test
fails. I have played around on abel:
Taking a trixie chroot and pulling in newer gnutls via LD_LIBRARY_PATH
makes most of the testsuite fail, including this trivial test:
8X--
LD_LIBRARY_PA
Kukri
FTR there is no issue in Debian with any of the above in my tests.
Also the packages don't seem to use valgrind at any point: not when
building, not in the autopkgtests.
Full build logs including autopkgtest output here:
https://people.debian.org/~ema/armhf-stack-clash-protection/
What ex
ewhen:
$ rmadison -s unstable ure-java
ure-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
ure-java | 4:7.6.4~rc1-1 | unstable | amd64, arm64, armel, i386
Regards,
Rene
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.
I was trying to say
is: if you know that something is broken, please let us know because we
are not aware of any issues.
> Debian is the first distro to turn this on on armhf, but didn't do any
> checks or test rebuilds before turning this on.
I have rebuilt and tested a few key packages mys
On Fri, Nov 24, 2023 at 01:34:21AM +0100, Guillem Jover wrote:
> > Is that a feature that the Debian ARM32 porters and the security team really
> > want to support actively, despite the missing upstream support?
>
> According to https://bugs.debian.org/918914#73 there were no pending
> toolchain i
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?
On 2023-11-24 01:34 +0100, Guillem Jover wrote:
> On Thu, 2023-11-23 at 10:45:33 +0100, Matthias Klose wrote:
> > it looks like enabling this flag on armel/armhf is a little bit premature.
> > In Ubuntu, people tracked down segfaults due to this change in at least
> > valgr
figure out
> these issues on their own. Please don't do that.
>
> Debian is the first distro to turn this on on armhf, but didn't do any
> checks or test rebuilds before turning this on.
>
> > So far I'm only aware of an issue with plplot, which turned out to
* Emanuele Rocca:
> 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.
J
, but the task of the porters it NOT to
put this kind of work on the shoulders on others, but to do this
analysis themself. You seem to rely on every other package maintainer
to figure out these issues on their own. Please don't do that.
Debian is the first distro to turn this on on armhf,
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!
On Thu, 2023-11-23 at 10:45:33 +0100, Matthias Klose wrote:
> it looks like enabling this flag on armel/armhf is a little bit premature.
>
> Apparently it's not completely supported upstream, and might cause
> regressions, according to
> https://bugzilla.redhat.com/show_b
Hi,
it looks like enabling this flag on armel/armhf is a little bit premature.
Apparently it's not completely supported upstream, and might cause
regressions, according to
https://bugzilla.redhat.com/show_bug.cgi?id=1522678
Is that a feature that the Debian ARM32 porters and the sec
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,
since LibreOffice 7.6 (which added some more tests which were manual
before to the automatic set) the testtools' bridge test fails:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A7.6.2-5&stamp=1698791231&raw=0
only on armhf. armel and
On 2023-10-27 14:29 +0100, Steve McIntyre wrote:
>
> Are either of those ports (armeb/arm64ilp32) actually useful / alive
> at this point?
No, but if someone did try to build a package for those it would be
incorrect for dpkg to enable these flags. The chances of anyone
actually doing that are pr
On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote:
> Are either of those ports (armeb/arm64ilp32) actually useful / alive
> at this point?
Not that I have seen. I didn't think anything other than the IXP ever
really used big endian and that's a long time ago. arm64ilp32 seems
to ser
1 - 100 of 1468 matches
Mail list logo
