Control: tag -1 patch
[ CCing debian-arm list to loop them into the porting issue. ]
Hi!
On Fri, 2024-06-07 at 14:42:18 +0200, Guillem Jover wrote:
> On Sat, 2024-04-20 at 14:56:40 +0200, Lucas Nussbaum wrote:
> > Source: libx86emu
> > Version: 3.5-1
> > Severity: seri
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
On Sat, 2023-11-11 at 23:52:21 +, Steve McIntyre wrote:
> On Sat, Nov 11, 2023 at 08:36:16PM +, Wookey wrote:
> >It was being used internally/developmentally for a while (at CISCO)
> >but, as you observe, only with large kernel and toolchain
> >patches. Various groups dragged their feet on
Hi!
On Fri, 2023-10-27 at 20:17:21 -0400, Lennart Sorensen wrote:
> 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 eve
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,
Hi!
On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote:
> Following the procedure to modify default dpkg-buildflags I propose to
> enable -fstack-clash-protection on amd64. The bug for dpkg tracking this
> is #918914.
>
> | -fstack-clash-protection
> | Generate code to prevent stack cl
gt; mricron
> nbc
> pasdoc
> tomboy-ng
[…]
> view3dscene
> winff-gtk2
> winff-qt
Hmm I guess these are going to be problematic for dpkg-shlibdeps when
trying to analyze these objects against the shared libraries they link
against.
On Tue, 2023-06-27 at 15:16:22 +0200, Emanuele Ro
Hi!
On Thu, 2023-06-15 at 14:56:21 +0200, Emanuele Rocca wrote:
> 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 t
Hi!
On Wed, 2023-05-03 at 23:16:16 +0100, Wookey wrote:
> On 2023-05-03 21:50 +0100, Steve McIntyre wrote:
> > If we're still seeing
> > issues in packages today, then maybe we might find some help from
> > Wookey or Emmanuel (who should both be reading this list!).
>
> I am, and have noticed thi
Hi Steve!
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 strict, which had to be
reverted due to issues with o
Hi!
On Tue, 2020-02-04 at 13:14:10 +, Steve McIntyre wrote:
> The glibc folks have taken an interesting approach.
>
> * 64-bit ABIs/architectures are already using 64-bit time_t
>throughout. The design is sane and so we should already be mostly
>safe here, modulo silly code bugs (we'
On Wed, 2017-02-01 at 15:34:04 +, Steve McIntyre wrote:
> On Wed, Feb 01, 2017 at 05:08:50AM +0100, Guillem Jover wrote:
> >On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
> >>
> >> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
&g
Hi!
On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
> Package: dpkg
> Version: 1.18.21
> Severity: serious
> X-Debbugs-CC: debian-arm@lists.debian.org
> [Disclaimer: I'm not an ARM porter and I don't really know much about
> the ARM psABI]
>
> The new ABI mismatch detector seems to be
Hi!
I'd like to get some feedback from porters and package maintainers,
given that this affects at least both groups. Some background first.
One of the reasons PIE has in the past not been enabled by default in
dpkg-buildflags, is because it introduced some slowness on some arches,
although this
Hi!
On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
> clone 845193 -1
> reassign -1 dpkg
> retitle -1 dpkg: please do not add -specs= flags only on some architectures
> thanks
I'm afraid I'll have to wontfix this because it is not really
implementable. See belo
Hi!
On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >> * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> >
> > If -fPIE is the default
On Wed, 2011-05-04 at 06:47:20 +0200, Guillem Jover wrote:
> I've implemented a different change, but it should also fix the issue
> at hand. I'll be requesting an update to the P-a-s entries.
The new svgalib is now in the archive, and I've requested the P-a-s
update i
Hi!
On Wed, 2011-05-04 at 02:01:18 +0100, peter green wrote:
> I see two ways of fixing the uninstallability.
>
> 1: apply the patch the submitter of this bug supplied and change
> packages-arch-specific allow the buildds to build svgalib on armel
> (and possiblly other architectures).
I've impl
[ Sorry for entangling the armhf bug with the i386 stuff, subsequent
replies should probably remove debian-arm and the bug report from
them. ]
On Fri, 2011-02-18 at 13:30:19 +0100, Matthias Klose wrote:
> On 18.02.2011 11:13, Guillem Jover wrote:
> >[ CCing Matthias, as I'd lik
u don't like
arm-linux-gnueabihf, then something like arm-linux-gnueabivfp or
whatever you want, I don't think I particularly care much, it would
need to be prefixed arm-linux-gnueabi though so that the matches work
transparently.
Beware, both patches completely untested!
> On
Hi!
[ I'm leaving for two days, and running out the door just right now, so
this mail is a bit rushed, and might contain inaccuracies and
repetition due to lack of proper review, sorry about that, I'll try
to clarify anything unclear once I get back. ]
On Tue, 2010-09-07 at 14:01:37 +0300,
Hi!
On Tue, 2010-07-06 at 21:07:10 +0300, Konstantinos Margaritis wrote:
> On Tuesday 06 July 2010 20:45:33 Paul Brook wrote:
> > Debian is pure soft-float (i.e. -mfloat-abi=soft).
>
> Right, all the more reason for a new flavour then :)
Actually, this only seems to me to indicate the option tha
Hi,
On Wed, 2007-12-19 at 13:30:10 +, Martin Guy wrote:
> 2007/12/19, Sergey Smirnov <[EMAIL PROTECTED]>:
> > Do anybody have any of this program working with Debian armel?
>
> Yes, they are all in the repo, but you cannot currently install them
> from ftp.debian-ports.org until the armel ver
Hi,
On Fri, 2007-12-07 at 17:25:05 -0500, Joey Hess wrote:
> This is a list of packages that build-depend/conflict with something on
> arm, but not on armel. I've fltered out obvious cases where arm and
> armel are meant to differ, but haven't investigated everything
> thuroughly. Most of these ar
Hi,
On Mon, 2007-09-10 at 18:32:37 -0400, Joey Hess wrote:
> The following packages in unreleased have older versions than unstable
> and the new versions don't have the armel patch applied. I filed bugs
> on several of these since the patch wasn't in the BTS. We probably should
> update the versi
On Wed, 2007-08-08 at 11:16:26 -0700, Joey Hess wrote:
> Riku Voipio wrote:
> > I fixed the libpam-modules issue, but I don't know why d-i wants to
> > install modutils. Since armel never supported linux 2.4 we really
> > shouldn't have it in armel repo for the first place.
>
> I don't see any mod
Hi,
The kfreebsd-i386, kfreebsd-amd64 and armel repos at GNUAB now carry
the pure arch:all packages mirrored from the main archive. The
previously needed sources.list deb line hack[0] is not anymore. This
will also make it easier to work on D-I and stop bothering users
about unathenticated package
Hi,
On Fri, 2007-06-15 at 10:26:51 +0900, Mohan wrote:
> I tried debootstrap/cdebootstrap from the other mirrors (?) like
> http://ftp.gnuab.org/debian
> http://ftp.de.debian.org/debian-kfreebsd
> http://www.gtlib.gatech.edu/pub/gnuab/debian
> But was somehow not able to do it.
Those are not appl
[ Please use my debian address as I prefer to use that hat for dpkg
stuff. ]
Hi,
On Tue, 2007-02-27 at 00:03:30 +, Wookey wrote:
> I noticed that dpkg-cross didn't automatically recognise armel when
> provided with an updated dpkg-architecture.
>
> This is because it has its own table of d
On Mon, 2007-02-26 at 23:07:28 +, Wookey wrote:
> On 2007-02-22 18:47 +0200, Guillem Jover wrote:
> Well spotted. That is indeed the offending bit. dpkg-architecture now seems
> to give the right answers.
Perfect!
> That has revealed that dpkg-cross needed armel support, whi
Hi,
On Thu, 2007-02-22 at 15:33:35 +, ext Wookey wrote:
> On 2007-02-14 04:00 +, Wookey wrote:
> > On 2007-01-10 23:06 +0200, Guillem Jover wrote:
> > > > The first candidate is dpkg. Guillem Jover's patch available here:
> > > >
> > > &g
On Mon, 2007-01-15 at 12:57:38 +0100, Lennert Buytenhek wrote:
> On Fri, Jan 12, 2007 at 02:01:27AM +0100, Lennert Buytenhek wrote:
[ list of patches needed ]
I just took the time the other day to check some of the patches I
produced some time ago for the N770 and file bug reports where
relevant,
Hi,
On Wed, 2007-01-10 at 17:11:23 +0100, Lennert Buytenhek wrote:
> More and more VFP-supporting CPUs are coming out lately, and it would
> be nice to be able to use VFP on them in a sane way. The existing
> Debian EABI efforts have been taking a while, so November 24 last year
> I started worki
[ Resending as the initial mail on the 22th seems to have been lost or
stuck somewhere. ]
Hi,
I'll reply here to the whole thread. Even if the tone of this mail was not
encouraging to do so.
On Thu, 2006-04-20 at 11:03:35 +0200, Martin Guy wrote:
> > Lennert at least didn't see any problem in
Hi,
A few of us are at the Debian Embedded sessions in Extremadura. We
have talked about the new arch name and have reached consensus on
armel, which matches the "naming convention" used in other arch names
in Debian like mipsel, and with the counterpart armeb. One of the
main concerns was the mis
Hi,
At Nokia for the next 770 software update we are switching to EABI.
And using the same Debian arch name w/o changing lib names will make
it binary incompatible with Debian, which I'd hate to see. Thus even
if there's no plan for an upgrade path yet (although multi arch could
be the solution),
36 matches
Mail list logo
