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
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
>
I believe the most obvious issues we were having was the gsasl tests indirectly
triggered
by gnutls28 the unrar-free tests triggered by libarchive. Both of which do
include
valgrind use.
In addition to flag being obviously incompatible with valgrind, it also caused
issues
with gdb for me,
Hello,
Another Canonicaler chiming in, I was also involved with debugging this problem
in Ubuntu.
I believe the most obvious issues we were having was the gsasl tests indirectly
triggered
by gnutls28, and the unrar-free tests triggered by libarchive. Both of which do
include
valgrind use.
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
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 porters it NOT to put
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
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
> > valgrind and gnutls, maybe
Hi,
Short introduction: I work at Canonical in the Foundations team and made
changes in gnutls which is one of the packages that first
encountered/caused issues which then started blocking various migrations
and changes.
On Fri, Nov 24, 2023, Matthias Klose wrote:
> On 24.11.23 07:19, Emanuele
* 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.
On 24.11.23 07:19, Emanuele Rocca wrote:
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
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,
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_bug.cgi?id=1522678
I
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 security
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
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
On Fri, Oct 27, 2023 at 03:23:10PM +0200, Emanuele Rocca wrote:
>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.
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
Hi!
On Thu, 2023-10-26 at 12:55:32 +0200, Guillem Jover wrote:
> On Thu, 2023-10-26 at 11:40:53 +0200, Emanuele Rocca wrote:
> > Package: dpkg-dev
> > Version: 1.22.0
> > Severity: normal
> > -fstack-clash-protection is supposed to be enabled by default on amd64,
> > arm64, armhf, and armel
19 matches
Mail list logo
