Re: Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]

[Guillem Jover]

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: serious
> > 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 (hopefully):
> > > cc -g -O2 -Werror=implicit-function-declaration 
> > > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > > -fstack-clash-protection -Wformat -Werror=format-security -g -O2 -fPIC 
> > > -fvisibility=hidden -fomit-frame-pointer -Wall -D_LARGEFILE_SOURCE 
> > > -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
> > > -Wl,-z,relro -Wl,-z,now -c ops.c
> > > mem.c: In function ‘vm_i_byte’:
> > > mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   581 | return inb(addr);
> > >   |^~~
> > >   |ins
> > > mem.c: In function ‘vm_i_word’:
> > > mem.c:619:10: error: implicit declaration of function ‘inw’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   619 |   return inw(addr);
> > >   |  ^~~
> > >   |  ins
> > > mem.c: In function ‘vm_i_dword’:
> > > mem.c:657:10: error: implicit declaration of function ‘inl’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   657 |   return inl(addr);
> > >   |  ^~~
> > >   |  ins
> > > mem.c: In function ‘vm_o_byte’:
> > > mem.c:676:5: error: implicit declaration of function ‘outb’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   676 | outb(val, addr);
> > >   | ^~~~
> > >   | outs
> > > mem.c: In function ‘vm_o_word’:
> > > mem.c:711:3: error: implicit declaration of function ‘outw’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   711 |   outw(val, addr);
> > >   |   ^~~~
> > >   |   outs
> > > mem.c: In function ‘vm_o_dword’:
> > > mem.c:748:3: error: implicit declaration of function ‘outl’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   748 |   outl(val, addr);
> > >   |   ^~~~
> > >   |   outs
> > > cc1: some warnings being treated as errors
> > > make[1]: *** [Makefile:22: mem.o] Error 1
> 
> 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), ia64 and alpha have port I/O, other
> systems have instead memory mapped I/O, but the code in mem.c is
> unconditionally calling port I/O functions such as in*() and out*(),
> provided by glibc.
> 
> Until the upstream code is ported to systems with memory mapper I/O, I
> think the "best" way to resolve this would be to restrict the
> architecture list to:
> 
>   any-amd64 any-i386 alpha ia64

The attached patch implements this. It should not affect reverse build
depending packages (only hwinfo) which is already arch restricted to
«amd64 i386».

I'm including the arm list to confirm the above, but also in case
someone there feels like porting the library to support memory mapped
I/O? (But perhaps that's not worth the effort.)

Thanks,
Guillem
From bafb0ddee8942c60b17745547854b3ed53ca4545 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 11 Jun 2024 13:30:40 +0200
Subject: [PATCH] Do not build on ARM architectures where there is no port I/O

Only x86 (i386 and amd64), ia64 and alpha have port I/O, other systems
have instead memory mapped I/O, but the code in mem.c is unconditionally
calling port I/O functions such as in*() and out*(), provided by glibc.

Until the upstream code is ported to systems with memory mapped I/O, the
best way forward is to restrict to systems that are supported right now.

(The only current package build depending on libx86emu-dev is already
arch restricted to amd64 and i386.)
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index f10e3e2..e8c974b 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Homepage: https://github.com/wfeldt/libx86emu

Re: Really enable -fstack-clash-protection on armhf/armel?

[Guillem Jover]

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 note that this bug was closed on 2018-01, so the information therein
might not be the most up-to-date?

> 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 issues related to this. And I think the security team mostly
deferred to the ports teams.

> In Ubuntu, people tracked down segfaults due to this change in at least
> valgrind and gnutls, maybe more.

If there's some missing support somewhere that might make this a
common thing instead of just affecting a handful of packages that
could simply disable the flags, and the Arm porters consider that
fixing that is not feasible in the short term, I guess it makes
sense to stop emitting the flag for the arm32 arches. In the end
I'd still defer to what the porters prefer, and I can easily revert
that change for arm32 and queue it for a next upload if desired.

Thanks,
Guillem

Re: Removing dpkg arch definition for arm64ilp32?

[Guillem Jover]

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 this to disourage it
> >becoming a thing we'd all have to maintain for years. I was doing the
> >debian development at ARM at the time and the bootstrap was never
> >completed. A few people (largely just CISCO) wanted it quite
> >badly. Nearly everyone else thought it was not worth the maintenance
> >effort. No-one has asked about it for quite a few years now (last mail
> >Oct 2018) so I think we can assume that it is indeed dead and no-one
> >would notice for years/ever if you removed it from dpkg.
> 
> +1 on the story and on dropping it.

Thanks for the background info! Ok then, I've queued its removal
from dpkg.

> >> For armeb, I assume it was properly upstreamed at the time, and it was
> >> actually used, even if it's currently not in use (like arm) I see tons
> >> of references in Sources files, and thus removing the arch definitions
> >> for either of these would not be safe right now I think.
> >
> >It is obsolete. It probably doesn't work any more having been unused
> >since the early days of the NSLU2/Sarge (circa 2006/2007). It might
> >still have been in use till 2011ish?. As you say it should probably be
> >removed from upstream sources before it is removed from
> >dpkg. Interesting question on how much effort (if any) (and when)
> >should be applied to tidying up stuff like this which is simply no
> >longer in use. If/when 'arm' is removed 'armeb' should certainly go
> >with it.

Sorry, I was probably not clear, with the "references in Sources
files" I meant mainly references in debian/control (in fields), that
trickle down into Sources repo indices, where on Debian, AFAIUI dak
might be unhappy about unknown architectures once its host gets
updated to a version of dpkg that does not list them (but perhaps
that's only on upload but not for existing ones in the archive). I
think that could be the main blocker for such removals. Whether
upstream kernels and toolchains might keep, drop, or lack support for
existing ports, could be indicators of their liveliness but I don't
think should be the only deciding factors, just important ones to
consider. (I'm thinking about the recent ia64 removal from Linux and
probably glibc for example.)

> armeb was mostly before my involvement in any arm stuff, as Wookey
> says. It did at least have some life as a functioning port, at
> least. I'd agree on leaving it in place for now, assuming it's not
> causing any trouble in terms of maintenance / support.

Ah, I just had a flash from the past, about chatting about the port
face to face with Lennert Buytenhek. :) For dpkg there's not really
much of a maintenance burden. My concern has increasingly been that
these (dead/unused) ports can confuse or be a burden instead to
diligent package maintainers, when they try to handle or list all
such ports in packages.

I've now also gone over the current dpkg arch definitions and tried to
locally restrict or remove obsolete/non-existing things, going from the
current «dpkg-architecture -L» list of 524 arches down to 238, and will
see what's safe to push out. :) Checking now for references to ports
such as arm or armeb in Sources indices does not look too bad (around
40 source packages for arm and 10 for armeb), so I might do a better
analysis and then check how these could be shadowed for linux-any (as
I also realized now these are part of the base CPU definitions which
cannot be removed as that would affect any other port), and perhaps
propose their shadowing too alongside a mass bug filing to remove
such references in a bit if people would like to see such cleanup
getting done, otherwise keeping them for a while also seems fine to me.

Thanks,
Guillem

Removing dpkg arch definition for arm64ilp32?

[Guillem Jover]

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 ever
> really used big endian and that's a long time ago.  arm64ilp32 seems
> to serve less purpose than x32 did (and x32 doesn't seem to be doing
> much either).  Certainly looks essentially dead at this point.

While scanning the libc-alpha list recently I read [M] that arm64ilp32
was never upstreamed in Linux nor glibc? If so, I think there's little
point in carrying the arch definitions in dpkg, and I guess that would
not make the cut if requested now (for reference this was requested in
bug #824742). Does anyone know whether it was ever used or it is being
used even if privately/internally somewhere? I'd think that could be a
good argument to make an exception, and keep this for a while still. I
see no usage of this arch in Debian Sources files for example, so it'd
seem safe to remove the arch definition in the Debian context.

[M] 

For armeb, I assume it was properly upstreamed at the time, and it was
actually used, even if it's currently not in use (like arm) I see tons
of references in Sources files, and thus removing the arch definitions
for either of these would not be safe right now I think.

Thanks,
Guillem

Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

[Guillem Jover]

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 since dpkg 1.22.0:
> > https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
> > 
> > However, due to an issue in the following conditional in
> > scripts/Dpkg/Vendor/Debian.pm, the flag is only on for amd64 and arm64:
> > 
> >   if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
> > 
> > The value of $cpu is "arm" for both armhf and armel. Please change the
> > line above to:
> > 
> >   if (none { $cpu eq $_ } qw(amd64 arm64 arm)) {
> 
> Ah, nice catch, and sorry! I think this happened due to copy pasting
> and modifying one of the surrounding lines. The intention was to use
> $arch here, to avoid enabling this on all arm-based arches which might
> not support this. I've queued the attached patch for my next push.

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 assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),
but wanted to ask in any case before pushing. If I don't hear anything
before the release, I'll just push what I proposed, and we can always
enabled these later on if needed.

Thanks,
Guillem

Re: Enabling -fstack-clash-protection for trixie

[Guillem Jover]

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 clash style attacks. When this option
> | is enabled, the compiler will only allocate one page of stack space
> | at a time and each page is accessed immediately after allocation.
> | Thus, it prevents allocations from jumping over any stack guard page
> | provided by the operating system.
> 
> This has been enabled on other distros for many years already (e.g.
> Fedora since 27, RHEL since 8, OpenSUSE since 15.1, Ubuntu since 19.10).
> 
> 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/
> 
> The open question is whether to also enable this for arm64, mips64el,
> ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's
> consensus among porters of a given arch other than amd64 to also add
> the flag, please post a followup to #918914.

Given the results from the rebuilds for amd64 and arm64 with minimal
fallout, and no complaints, I'm going to enable this for amd64 and the
three arm arches (arm64, armhf and armel) with dpkg 1.22.0, to be
uploaded later today. We can later on modify the set of architectures
(by request from porters) or tune them if it ends up causing problems.

Thanks,
Guillem

Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches

[Guillem Jover]

Hi!

On Fri, 2023-06-16 at 11:19:21 +0200, Emanuele Rocca wrote:
> I did a first pass, and it seems that the only objects with Version4 are
> generated by tcc.
> 
> Flags according to readelf -h on armel:
>  0x4000200, Version4 EABI, 
> 
> And on armhf:
>  0x4000400, Version4 EABI, 
> 
> For reference, the files are:
> 
>  /usr/lib/arm-linux-gnueabi{,hf}/tcc/bcheck.o
>  /usr/lib/arm-linux-gnueabi{,hf}/tcc/bt-exe.o
>  /usr/lib/arm-linux-gnueabi{,hf}/tcc/bt-log.o
> 
> Those are probably not particularly interesting for dpkg-shlibdeps, but
> I've filed #1038162 nonetheless.

Thanks, and right I guess as long as no package builds using tcc and
we do not end up with those in the archive, then that seems fine. But
in any case it would indeed be nice to get fixed.

> You mentioned in #853793 paris-traceroute also targeting Version4, but
> that package is now gone.

Ah, good then, I guess. :)

On Wed, 2023-06-21 at 15:22:11 +0200, Emanuele Rocca wrote:
> 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.

Great!

> (2) There are a few armhf packages shipping files with the soft-float flag.
> 
> All of them, with the exception of the u-boot packages,

I agree with Vagrant, that this does not seem problematic, and I guess
strictly speaking boot loaders would instead be packaged as part of
some kernel-less architecture, but because we are not there now (or
ever), then this seems fine.

> 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
> Tag_ABI_VFP_args is not set either.

Oh, hmm, could you file a report for this (perhaps preferably
upstream)? (Or perhaps you did already? :)

> Full list of armhf packages shipping ELF objects with the soft-float
> flag set:
> 
> astap
> astap-cli
> c-evo-dh-gtk2
> c-evo-dh-stdai
> cqrlog
> doublecmd-gtk
> doublecmd-plugins
> doublecmd-qt
> el-ixir
> fp-compiler-3.2.2
> fp-ide-3.2.2
> fp-units-castle-game-engine
> fp-units-rtl-3.2.2
> fp-utils-3.2.2
> gearhead
> gearhead-sdl
> goverlay
> lazpaint-gtk2
> lazpaint-qt5
> 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 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 1 armel and 91 armhf binary packages shipping ELF
> files without float flags (hard or soft) but with TAG_ABI_VFP_ARGS.
> 
> Examples:
> 
>  gcc-arm-none-eabi_12.2.rel1-1_armel.deb 
> ./usr/lib/gcc/arm-none-eabi/12.2.1/arm/v5te/hard/crtbegin.o 0x500: 
> Version5 EABI TAG_ABI_VFP_ARGS

Given that this looks like a cross toolchain, it might need to be
exempted, as these might end up shipping objects for the target arch
which will not match the package arch.

>  clisp-module-fastcgi_2.49.20210628.gitde01f0f-3_armhf.deb 
> ./usr/lib/clisp-2.49.93+/fastcgi/fastcgi.o 0x500: Version5 EABI 
> TAG_ABI_VFP_ARGS

This seems like something to fix.

> What do we want to do about those? I can take care of filing bug reports
> asking to add the missing flags if we agree it's a good idea.

I guess it would be interesting to know whether this is due to these
having been built with old toolchains (and never been rebuilt since),
or there's some toolchain or build machinery issue at play or similar.
Otherwise it would be nice to get consistency here, and I'm in
particular looking forward to being able to re-enable the ABI checker
in dpkg-shlibdeps. :)

> > And rechecking the commit message, it seems there were also
> > objects with both ABI float flags set at the same time.
> 
> I couldn't find any such case in my analysis, do you perhaps remember
> which objects were affected?

Rechecking the bug report, it looks like this was the part with
sonames2elf from wine, which is supposedly fixed now. But it seems
there was a potential problem with gcc mishandling builds that did not
include libc, see this message which describes this a bit more:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853793#45

where I don't know whether that part got reported or is fixed in gcc.

And thanks for doing this analysis! Much appreciated.

Regards,
Guillem

Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches

[Guillem Jover]

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 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 objects in the wild. For context that
> > was #853793.
> 
> My understanding is that the problematic cases are ELF files with:
> 
> (1) EABIv4 instead of EABIv5
> (2) armhf files with the ARM_SOFT_FLOAT flag set
> (3) armel files with the ARM_HARD_FLOAT flag set
> 
> Is that correct? Anything else?

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 same time.

I'm not sure whether you plan on analyzing all ELF objects in the
Debian archive for the Arm architectures, but if so, that would be
rather helpful. But thanks in any case for looking into this!

Thanks,
Guillem

Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches

[Guillem Jover]

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 this issue and put it on our list of things to look
> at. I was going to wait until I had something useful to say before
> replying :-)

Ah, great! Thanks both for the update. Then I think I'll just add a
comment on the code for now with a ref to that old revert, and it can
be refreshed or acted on once there are news on this front, so that I
do not forget about this.

Thanks,
Guillem

Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches

[Guillem Jover]

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 objects in the wild. For context that
was #853793.

I was wondering whether you (or know if someone else) had worked on
the ARM port side of things to clean up those issues, from toolchain to
specific objects in packages? I'm not in a hurry to add that code back
so do not feel any pressure from this, I'm mostly wondering where we are
at with this, and whether there is something I can improve from dpkg side
in that regard, but if not that's also fine, and then I'd probably try
to update the status somewhere (code comment or wiki or something).

(I think at least the issue with wine should be solved now with commit
https://salsa.debian.org/wine-team/wine/-/commit/51f48d3e6c04cef760610d14ba5f368e7f2baf7a)

Thanks,
Guillem

Re: Y2038 - best way forward in Debian?

[Guillem Jover]

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'll always have those!)
> 
>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>default* to use 32-bit time_t to keep compatibility with existing
>code. This will *not* be safe as we approach 2038.
> 
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>upwards, but this will of course affect the ABI. Embedded uses of
>time_t in libraries will change size, etc. This *will* be safe for
>2038.

I think there is still work pending in glibc to expose both 32-bit and
64-bit interfaces at the same time? (Currently it seems to be either-or.)

I'd like to use this for example in libbsd, to make a smooth
transition similar to the one made in glibc, w/o needing to bump the
SONAME.

> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe. When we had to do
> something like this in the past, to deal with the libc5->libc6
> transition, we had an SONAME change in libc to work with. We decided
> to append the "g" tag to the names of our library binary packages to
> signal that a library was built against libc6. We can still see some
> of the effects of this in the archive, many years later
> (e.g. zlib1g). The problem now is that we will *not* have an soname
> change here to help identify code compatibility on the 32-bit front.

Well, I guess such a new (conditinally selectable) name could be
coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
(We already have precedent in some ports that do not use the same
prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would
indeed involve lots of work, with massive amounts of package renames. :/

> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
> 
>  A Follow a similar path to last time (rename library packages).

>  *** OR ***

>  B Decide which 32-bit ports we expect to care about by 2038, and
>re-bootstrap new versions of those ports *with different
>names*. This would allow most of our developers to ignore the
>problem here (as 64-bit arches are not affected) and let a smaller
>number of people re-bootstrap with new ABIs with 64-bit time_t
>embedded. There are some downsides here:

(If we are going for this, I'd say it might make sense to consider
also enabling LFS, although that might be a dangerous change, see
the lintian tag for the rationale. :)

>* users would *not* be able to simply upgrade from one to the
>  other, due to lack of binary compatibility

I think this conclusion stems from an incorrect premise. See below.

>We'd need to decide exactly which of our 32-bit ports we would want
>to do this path with (probably armhf->arhmft?, maybe
>armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
>continuity, we will most likely *not* end up with a different
>visible ABI via the triplet and the runtime linker, so old/new
>multi-arch will be impossible.

A new dpkg architecture must use a different triplet, as these are
required to be bijective. See “lpia” for a previous example of this.
(This would then make it possible to cross-grade.)

In addition if we are using a new multiarch triplet, and need to
rebuild the world, are going to be ABI incompatible anyway, we might
as well use a proper multiarch-qualified ld.so pathname that does
not collide with anything.

I also think we have a C option, which would be something like:

  C Do a transition equivalent to the LFS one, by either switching
libraries opportunistically to 64-bit time_t on their next SONAME
bumps, or by updating them to provide 64-bit variants of their
interfaces along their 32-bit ones, as done in glibc. Of course
the main problem here is that the LFS "transition" is not one we
should be very proud of, as it's been dragging on for a very long
time, and it's not even close to be finished…


(Hmm there seems to be something borked with lintian.d.o, as the
general tag numbers seem extremely low. :)

Thanks,
Guillem

Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

[Guillem Jover]

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
> >> generate a library which does not link against libc (this is used by
> >> sonames2elf in some packages) causes both flags to be set (maybe
> >> because it's compatible with both?).
> >
> >Even worse, I've found at least one instance of a package containing
> >binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have
> >to remove the flags matching on EM_ARM ELF binaries for now. At least
> >this will get us back to the previous behavior with objdump, no
> >regression in that sense.
> >
> >To be able to distinguish armel from armhf I'd probably need to check
> >the arm attributes section for Tag_ABI_VFP_args, which annoyingly
> >seems to be set even when the HARD flag is not set. :/ But this will
> >be for dpkg 1.19.x.
> 
> Please don't go down that route, the ABI flags are intended to save
> people from that. I'm curious what's going wrong with libgsm1 here
> such that we're not seeing consistent ABI flags.

Well, I don't see any other sane option really. The problem is that
the code involved is in perl so must be arch independent, in contrast
to glibc, which is built against the architecture's ABI.

In this case dpkg-shlibdeps, sees an ELF object with an EM_ARM machine
ID which links against "stuff". And it traverses the linker paths, in
principle in the right order, but for example there is no guarantee of
the correct order when using the ld.so.conf paths, because they are
alpha sorted, not in host > foreign order. :(

So we have an ELF object that might or might not have the SOFT/HARD
flags set, which links against SONAMEs that when found might or might
not have the SOFT/HARD flags set. And it needs to know which one is
ABI compatible to keep it or discard it.

Also inferring the architecture from the package shipping the file is
not currently reliable, due to multilib, because those subvert the
packaging system by shipping .deb with contents for the wrong arch. :(

> If you're worried about EABIv4, does the logic of the dpkg checker not
> match the checks we added in glibc itself?

One of the problems is that currently the ABI matcher is a bit
simplistic, and it just combines various things that need to really
match and just compares the byte-streams for equality. Because that
allows the code to do good enough matching even when it does not know
new ELF machine types. It does better than the previous objdump
matcher in any case.

In the future I guess I'll need to special case some architectures,
in particular, at least ARM, MIPS and SH.

And just for reference the code being discussed is:

  
<https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Shlibs/Objdump.pm#n173>

Thanks,
Guillem

Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

[Guillem Jover]

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 a bit too strict on armel and
> armhf. The detector forces the ELF_FLAG_ARM_HARD_FLOAT and
> ELF_FLAG_ARM_SOFT_FLOAT flags to be equal on both the library and its
> user but checking ABI comparability doesn't seem that simple.

Indeed. :(

> For example, on armel linking against libgsm.so currently gives this:
> 
> $ dpkg-shlibdeps -v -e../a.out -Ttest
> dpkg-shlibdeps: debug: >> Scanning ../a.out (for Depends field)
> dpkg-shlibdeps: debug: Skipping lib /usr/lib/arm-linux-gnueabi/libgsm.so.1, 
> libabi=0x010100280500 != objabi=0x0101002805000200
> dpkg-shlibdeps: error: cannot find library libgsm.so.1 needed by ../a.out 
> (ELF format: 'elf32-littlearm' abi: '0101002805000200'; RPATH: '')
> dpkg-shlibdeps: debug: Library libc.so.6 found in 
> /lib/arm-linux-gnueabi/libc.so.6
> dpkg-shlibdeps: debug: Using symbols file 
> /var/lib/dpkg/info/libc6:armel.symbols for libc.so.6
> dpkg-shlibdeps: warning: binaries to analyze should already be installed in 
> their package's directory
> dpkg-shlibdeps: error: cannot continue due to the error above
> Note: libraries are not searched in other binary packages that do not have 
> any shlibs or symbols file.
> To help dpkg-shlibdeps find private libraries, you might need to use -l.
> 
> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
> generate a library which does not link against libc (this is used by
> sonames2elf in some packages) causes both flags to be set (maybe
> because it's compatible with both?).

Even worse, I've found at least one instance of a package containing
binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have
to remove the flags matching on EM_ARM ELF binaries for now. At least
this will get us back to the previous behavior with objdump, no
regression in that sense.

To be able to distinguish armel from armhf I'd probably need to check
the arm attributes section for Tag_ABI_VFP_args, which annoyingly
seems to be set even when the HARD flag is not set. :/ But this will
be for dpkg 1.19.x.

> This was first seen with wine:
> https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0
> https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0
>
> But there seem to be some other recent build failures relating to this
> as well.

Oh, wow, I'm not sure this is very kosher, but if it is causing build
failures, then it does not matter much.

I'm preparing an upload right now.

Thanks,
Guillem

[RFC] The PIE unholy mess

[Guillem Jover]

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 has somewhat changed recently. But also because
unconditionally setting it, breaks at least PIC builds. So PIE got
enabled recently by default in gcc, as it could easily control when it
is relevant. Although this has been done only for release architectures.

At about the same time this was being considered, I realized that dpkg
could enable this "safely" by using gcc specs files. But this is in
any case also required to be able to disable PIE when it is implicitly
enabled by default in gcc. So we'll need specs files no matter what,
at least for now.

While adapting dpkg-buildflags to cover for the new gcc defaults, I
unintentionally enabled PIE by default on all architectures, and when
I noticed, it seemed to make sense to leave it like that, because:

  * All previous build flags from dpkg-buildflags have always been
enabled globally and only blacklisted completely when they have
been non-functional.
  * It's a more consistent interface for packages, as they get built
with the same flags everywhere. Otherwise we'd get PIE enabled by
default in release arches, disabled by default elsewhere, and
enabled or disabled depending on the package requesting so.
  * It will mean that PIE coverage reporting will be shadowed in
lintian, because the tags only cover i386 and amd64, so maintainers
will probably stop enabling them globally.

Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
requesting to not enable PIE globally from dpkg-buildflags, and pretty
much immediately added a patch into gcc [P] to ignore dpkg-buildflags
PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did
not enable PIE explicitly (I only fully understood the request after
seeing the gcc patch).

  [P] 


Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
does not even need to be exported from debian/rules, nor from the
dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
--export=configure or --export=cmdline. It's also a layer violation.
It also breaks unrelated stuff as now gcc emits notes when it thinks
the -specs option should not be passed. And while I could certainly
have started an arms-race by adding counter-measures by randomizing
the filenames or something similarly ugly, that'd be pretty much silly
and childish.

For better or worse, this does not affect the release architectures,
so by extension it should not affect the release, but it still sucks.

So, I'd like to know how people feel about the requested interface
(i.e. not enabling PIE globally from dpkg-buildflags). If there's
consensus that porters and maintainers want that, I'll just change
dpkg-buildflags to do this, even though I think it's a very
suboptiomal behavior.

Alternatively, porters could as well request PIE be enabled by default
in gcc on their port, which could make this also globally enabled.

Thanks,
Guillem

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Guillem Jover]

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 below… :/

> Guillem Jover dixit:
> >Those specs files should make it possible to build stuff with PIE
> 
> Yes, but they *do* break anything that
> - acts on the CFLAGS (and LDFLAGS) variables
> - uses klcc or other compiler wrappers that don't understand -specs
> - uses clang or pcc or whatever other compilers

The default dpkg build flags have always been tied to the specific
language compiler version currently marked as the default (for C that
would currently be gcc-6).

> Worse, they break *differently* on whether…
> 
> >Precisely to make the behavior consistent on all architectures, dpkg
> >enables PIE (conditionally if no other flags marks it as to be
> >disabled) on all architectures were gcc has not enabled this by
> >default.
> 
> … that. And that is just plain wrong. Either dpkg should inject
> -specs= stuff on all architectures or on none. Differing like this
> just invites hidden and hard to track down bugs.

As long as gcc enables PIE on a subset, there will be need to inject
some form of specs on either subset of those arches, either on
hardening=+pie or on hardening=-pie, pick yout poison. :(

Injecting just the raw -fno-PIE and -no-pie does not work, so when you
need to disable those we need to pass via specs files.

> Please get an agreement with the GCC maintainer on how to proceed
> from here.
>
> Personally, I’d still prefer for GCC to behave as on other systems,
> i.e. not to enable PIE by default, and to have it done completely
> within dpkg, but I can *also* live with it being done exclusively
> in GCC.
> 
> Either are *much* better than the current way.

Well you and me both, I'm just adapting the dpkg-buildflags to the
current gcc situation. :/

> >Also BTW the gcc maintainer asked that porters
> >interested could request PIE to be enabled by default in gcc.
> 
> What difference does it make on whether GCC or dpkg enables PIE?

It means it should at least get the same behavior from gcc as all
official ports, it is more transparent and should not suffer from
unbalanced passing of CFLAGS w/o LDFLAGS or the other way around,
for example. Of course that does not mean that package might still
not fail, in case they try to link PIE code into a shared library
or similar.

> The two last quote sections make it clear that any architecture
> that currently has PIE enabled in dpkg should have it enabled in
> GCC in the first place.

Enabling new build flags in dpkg has always been done globally,
except for specific blacklists on things that were completely broken
in the toolchain, which have then been enabled eventually when they
got fixed.

Having a subset of architectures is a pain for maintainers as they
get different resulting objects depending on the architectures, it
also changes the semantics from before the gcc default change, as
previously explicitly enabling PIE was global, and now would be for
a subset.

Or worse, the new semantics would need to be that by default you get
PIE on a subset but if you pass hardening=+pie on each package you get
it enabled globally? Pretty unintuitive IMO.

> (Did dpkg enable that on porters’ requests?
> It does not look like that to me. This smells like overstepping
> boundaries.)

If porters are unhappy about this, I'll revert PIE for those ports in
dpkg, but this will not make the situation less of a mess, hardening=-pie
will still need the specs files on ports were gcc enables it by default,
and hardening=+pie might need them on the ones that do not…

> tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
> as long as only one does it. FFS, just enable it on all of them
> unless known to absolutely not work; that’d still be better than
> the current mess.

Well I think we should be enabling all hardening flags directly in
gcc, but now that we have the specs files I guess it would not be
too bad to enable them just in dpkg, but I agree either would be
preferable. :/

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Guillem Jover]

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 will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem

Re: Bug#623747: svgalib: FTBS on armel

[Guillem Jover]

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 in bug 625680.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110505015326.ga11...@gaara.hadrons.org

Re: Bug#623747: svgalib: FTBS on armel

[Guillem Jover]

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 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.

 What i'm not sure on is which is the correct path. I know there have
 been arm boxes that use PC graphics hardware in the past but I don't
 know if they are compatible with svgalib or indeed whether they are
 compatible with the debian armel port.

The portability fixes I introduced some time ago allow svgalib to use
the framebuffer if the I/O drivers are not buildable.

 Depending on the responses I get I will either raise the severity of
 this bug or file a new rc bug against fp-units-gfx-2.4.2

Well, I don't think this bug RC, as the package has never been built
there. Anyway packages on their way to the archive now.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110504044720.ga5...@gaara.hadrons.org

Re: Bug#594179: dpkg armhf patch acceptance status?

[Guillem Jover]

[ 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 like your opinion on my proposed solution
involving some Debian gcc changes. ]
 
 The armhf patch for gcc looks ok, however I would like to see this
 better addressed in Linaro and/or upstream.

Ok, I'll run it through upstream to see what they say. I just wanted
to check if you'd be fine including it regardless of upstream's stance
on it, to at least be able to decide on the armhf triplet issue, the
multiarch paths decision would be unrelated to this then.

   Yes but x86 goes to the other extreme, with separate triplets for
   compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
   triplet is not a good ABI specifier.
 
 Sure, but as mentioned above, I'm now convinced the correct solution is
 to switch back to i386-linux-gnu.
 
 No, this doesn't work. the triplet currently is set to
 i586-linux-gnu. Switching back to to i386 would loose the sync
 primitives and a not working gomp.  There is too much relying on =
 i586 in many configure's of other packages.

Oh, I think this actually strengthens my point!

The gcc-4.4:i386 package seems to be compiled on Debian to target i586
as the base instruction set, as can be seen in its debian/rules2:388,
which implies changing the triplet would not affect this (barring the
small change I'm attaching a patch for, untested), and thus the sync
primitive and gomp would be fine (at least from my understanding of
the gcc build system). And just to make this perfectly clear, I'm
not proposing to downgrade the actual instruction set base line.

So while the base instruction set was changed to i586 in gcc 4.4.0-1~exp1
it did not switch the GNU triplet to i586-linux-gnu to match:

$ dpkg --print-architecture
i386
$ gcc-4.4 -dumpmachine
i486-linux-gnu
$ gcc-4.5 -dumpmachine
i486-linux-gnu
$ gcc-4.6 -dumpmachine
i486-linux-gnu
$ grep ^i386 /usr/share/dpkg/cputable|tr -s '\t '|cut -f2
i486

So I don't see how any debian/rules could be currently relying on
the i586-linux-gnu triplet (as long as they set them correctly through
the dpkg-architecture variables, coming from gcc, and not from
config.guess).

Also having to transition all our packaging to the new triplet every
time i386 changes the base line does not seem right, and it's
something we don't do on any of the other architectures. I'd even say
it's just wrong, packages should either use the default compiler base
instruction set, set their required one independenly of it, do
multiple builds and use hwcaps for libraries or do run time detection.

Given the above we'd need to either switch to i586-linux-gnu or
i386-linux-gnu, it seems to me both will imply the same amount of
changes? And thus going for the latter seems the correct solution,
it matches with the other architectures, can be used as the multiarch
paths and can reduce some divergence with Ubuntu, all of them a clear
win! :)

 Not only for the good, as the switch in Ubuntu to i686 did show,
 because many configure files assume sse with i686-linux-gnu.

I'd say any such assumption in those packages is buggy, per above.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110221063219.ga22...@gaara.hadrons.org

Re: Bug#594179: dpkg armhf patch acceptance status?

[Guillem Jover]

 for
  the triplet (i386-linux-gnu) in the same way we use it in other
  arches, like on arm where we use arm-linux-gnu instead of something
  like armv4tel-linux-gnueabi, for example. (I mentioned this already to
  Steve and Raphaël on some private conversation.)


Solution(s)
---

So while some of the previous points _could_ be considered corner-cases,
there are several of them piling up, which work just fine with our (and
GNU build system) current assumptions, and breaking them seems
gratuituous and way worse than not doing it, as it adds future confusion,
breakage and complexity, instead of the extremely “simple” and more
correct solution (in contrast to the claimed dpkg lameness/limitation,
which I disagree with, and I think I've proven incorrect above) of just
using a new triplet.


- Use additional pre-processor macros for armhf, inccurs an additional
  pre-processor call for the arm arches. It implies the Debian arches
  cannot be fully retrieved w/o a cross-compiler for each of the arches
  lacking information, which means we lose the univeral bi-directional
  mapping.

  This one is a no go.

- Abuse the vendor field, a hack upstream does not like either, although
  strangely enough they seem to prefer it instead of a proper triplet.

  Although viable, I don't really see the point, we might as well just
  do the right thing and use a proper triplet then.

+ Just use a new triplet arm-*-*-gnueabihf or whatever in a similar vein
  as our own -gnulp and -gnuspe.

  Would not need to be explicitly supported by gcc upstream to perform
  the automatic selection of the ABI based on the triplet for different
  variants, which seems to be the biggest reason they have against it.
  This should be satisfactory for upstream as the magic will be kept
  in the Debian packaging, and they can be kept oblivious of it.

  Package build systems might be matching against stuff like
  arm*-*-linux-gnueabi, so it might require changes to match on -gnueabi*
  instead, but is more immediate, and not like propagating config.guess
  all over the place, which we should not need as debian/rules should
  be passing --build to configure anyway, and config.sub can already
  canonicalize something like arm-linux-gnueabihf by way of the current
  patterns.

  Switch also i486-linux-gnu (Debian) and i686-linux-gnu (Ubuntu) to
  simply i386-linux-gnu (but still preserving their respective cpu
  tunnings). This also fixes this inconsistency in the i386 arch.

  So Matthias would you be amenable to including something like the
  attached patch to Debian gcc (regardless of upstream accepting it,
  although the patch is pretty minimal and non-intrusive, which would
  seem to have good chances of being accepted there)?
  What about switching the triplet for i386, I could prepare patches
  for that if you want (I think it's a one-liner though)?

  Konstantinos, would you be willing test such patch with an accompanying
  triplet in dpkg (patch attached too)? If you 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 Wed, Sep 08, 2010, Guillem Jover wrote:
  We currently need something like this in dpkg-dev because the mappings
  need to be bidirectional, as dpkg-dev needs to be able to convert
  from GNU triplet to Debian architecture and the other way around.
  
  Steve wondered why this is the case, and that's because for
  cross-compiling purposes dpkg-architecture infers the host architecture
  from the CC environment variable through the -dumpmachine option.
  Chaning this is possible but, would break a current way of
  cross-compiling which has been around for a long time.
 
  So this use case is CC=arm-linux-gnueabi-gcc dpkg-buildpackage and it
  just guesses the -a flag that you should have set?

That and for automatic bootstrapping purposes too.

  The toolchain has the same triplet for binary incompatible producing
  objects, which seems like a bug/misfeature to me, and that's one of
  the assumptions dpkg-dev has relied on, in the same way as multiarch
  when deciding to use the triplet as a unique token for the installation
  directories.
 
  You describe this as a bug/misfeature, that might be true but I don't
  think we can challenge this usage of triplets in the upstream
  toolchain, and multiarch is moving to having its own tuples instead now
  (http://wiki.debian.org/Multiarch/Tuples).

Oh, but I think I just did. :) Also given the above I don't think it
makes sense to invent a new set of tuples, the triplets should work
just fine. In addition those tuples end up relying partly on the
definition of the ABI the default gcc has for a given target, which
should not change incompatibly for a given Debian architecture, or we
are screwed anyway. So I don't see that it buys us much

Re: dpkg armhf patch acceptance status?

[Guillem Jover]

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, Konstantinos Margaritis wrote:
   I really would like to know the stance of the dpkg maintainers regarding 
 the 
 armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as 
 bug reports, but without the dpkg patch, those patches would be useless, so 
 I'm holding back, but that in the meantime increases the workload as newer 
 packages appear all the time and I have to forward port the armhf patches all 
 the time. Plus, the whole port is unusable without dpkg functioning properly. 
 The patched version I have uploaded in debian-ports works fine without any 
 side-effects whatsoeer. I'm not asking for immediate acceptance, but even a 
 short mail of 'it's ok, but needs more work here and there' will do. 

I don't quite like the current implementation, which abuses the vendor
for information related to the ABI.

So, recapping a bit the long thread about the new port:


I agree with Paul Brook that abusing the vendor in this way poses a
compatibility issue with upstreams, I'd rather not use something like
this which is probably Debian specific.


We currently need something like this in dpkg-dev because the mappings
need to be bidirectional, as dpkg-dev needs to be able to convert
from GNU triplet to Debian architecture and the other way around.

Steve wondered why this is the case, and that's because for
cross-compiling purposes dpkg-architecture infers the host architecture
from the CC environment variable through the -dumpmachine option.
Chaning this is possible but, would break a current way of
cross-compiling which has been around for a long time.


The toolchain has the same triplet for binary incompatible producing
objects, which seems like a bug/misfeature to me, and that's one of
the assumptions dpkg-dev has relied on, in the same way as multiarch
when deciding to use the triplet as a unique token for the installation
directories. Although one can produce binary incompatible output with
normal gcc options, like changing the calling conventions with something
like for example -fpcc-struct-return, but those are not part of the
default ABI, and are expected and warned as producing incompatible
binaries.

This also causes issue with not being able to have installed two
cross-toolchains for say armel and armhf as they share triplet,
although you can use the armel toolchain with few options to build for
armhf, but then you'd need to specify those as part of the CC variable.
Also that also happens with biarch, you can produce i386 binaries from
an x86_64 toolchain, yet they both have their own triplet.

I'm just wondering if this is also the case for mips triarch, or do
those have each their own triplet, and is only arm that has this
issue?

Anyway, ideally I'd rather see this addressed by giving armhf a real
triplet, which would also make multiarch life way easier as there'd not
be any need to define an artificial set of neutral architecture names
to be able to place objects in the file system. But if this is not going
to happen, and thus the assumptions dpkg-dev is making have been just
wrong, then I'd rather drop the bidirectional mappings, and be done
with it. This will need careful consideration though, as it's breaking
a current interface, but something that could be done for dpkg 1.16.x.


I can propose a patch for this once I get back.


thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908094013.ga28...@gaara.hadrons.org

Re: armelfp: new architecture name for an armel variant

[Guillem Jover]

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 that Aurelien
was mentioning (building few core packages with softfp) should be strongly
considered instead of adding a whole new architecture, which didn't look
had been properly explored from the initial mail?

  -mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and
  libraries can be freely mixed). Obviously softfp code will will only work
   on a CPU with an FPU, but that's not different to (say) armv5 v.s. armv6
   or vfpv2 v.s. vfpv3.
  
  -mfloat-abi=hard is not compatible with either of the other -mfloat-abi
  options.
 
 Hm, true, my mistake. Still, now with A8 and A9 cores, software is 
 underoptimized even with softfp. Hence the request for a new flavour. :)

Personally, before any further discussion I'd like to see some numbers
with core libraries (libc, libgcc, libgmp, libatlas? etc) built with
softfp, which eventually might be able to switch to use the hwcaps
infrastructure in a similar way as how packages like libc6-i686 are
handled.

Adding a new (official) architecture variant is a huge overhead for
everyone, it implies adding new porter boxes, patching packages (but
hopefully not many) to handle the new arch, having someone handle the
build daemons, porters to handle arch specific issues (which arguably
should be minimal given the semblance with armel, but still), more mirror
space, user confusion due to the incompatibility of the binaries that
might run on the same hardware, and I'm probably forgetting others. The
lpia is a great example of an architecture variant that was a mistake,
and should haver never been created.

If the arm porters decide afterall that they want something like armelfp
anyway, then of course I'll be glad to add the architecture name to dpkg,
but I'd first try to exhaust other alternatives with way less overhead.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100708110658.ga20...@gaara.hadrons.org

Re: firefox(iceweseal), firebird(icedove), openoffice

[Guillem Jover]

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 version of libgtk-2.0-0
 catches up with the
 same-for-all-processors version of libgtk2-common that it expects.
 A question of a few days or weeks.
 
 If you're desperate I can send you matching .deb's for the previous
 version of the libgtk packages.

People can try to find this kind of stuff either in:

  http://ftp.debian-ports.org/debian/obsolete/

or

  http://ftp.debian-ports.org/debian-snapshot/

although the contents of those are not guaranteed to last forever.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: packages with different build-depends on arm than armel

[Guillem Jover]

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 are of the form 
 [long list of arches including arm] or [!arm] and obviously just
 need armel added to the list. Some of these may already have bugs
 filed due to FTBFS on armel.

Ideally we should be switching all of those to architecture wildcards
like [linux-any], but sbuild does not have support for that.

 bochs
 directfb (bug filed)

Both fixed in svn now, will be included in next uploads.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnuab.org unreleased analysis

[Guillem Jover]

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 versions in unreleased in the meantime:
 
 gdb 6.6.dfsg-1+armel
 gettext 0.16.1-1+armel
 libtool 1.5.22-4+armel
 nspr 2.6.18-7+armel
 python-numeric 24.2-7+armel
   Changelog for the +armel version says Disable lapack and blas
   support., but it was a binary-only upload so I don't know what
   changes were made to the source and couldn't produce a patch.
   This needs to be dealt with.

Hmm this should not have happened, stuff to unreleased should always
be uploaded with sources. I might add a reject check for this.

 The following packages in the unreleased suite on gnuab.org seem like
 cruft that can be removed soon:
 
 gcc-defaults 1.56+armel
   Newer version in unstable has the armel patches.
   But new version hasn't built on armel yet for some reason.
 procpc 1:3.2.7-4.1+armel
   Fix just NMUed into unstable today, can remove from unreleased
   once it autobuilds for armel.

Those will be automatically obsoleted once the new version appears in
unstable (unreleased and unstable are considered part of the same
suite when obsoleting packages).

 linux-kernel-headers 2.6.18-7+armel
   Removed from unstable.

Removed now.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: armel debian-installer using gnuab repo

[Guillem Jover]

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 modutils problem in debootstrap today. It was probably
 being pulled in somehow due to the db4.3 dependency issues.

I removed it from the archive, after Riku's request.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Reestructuration of armel and kfreebsd-any repos at GNUAB

[Guillem Jover]

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 packages.

The following should be enough for those architectures:

  deb http://ftp.gnuab.org/debian unstable main
  deb http://ftp.gnuab.org/debian unreleased main

regards,
guillem

[0] «deb http://ftp.debian.org/debian dists/sid/main/binary-i386/»
which can be removed now from your sources.list


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian Armel ARM Port

[Guillem Jover]

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 applieddata mirrors, those contain the whole archive
rebuild that Riku is doing, which is needed as all packages should
have been built by a DD before uploading to the Debian archive.

 These mirrors (?) don't seem to have all the packages present in the
 armel-debs.applieddata.net
 repository. Things like tzdata and dpkg-dev to name a few.

Right, it's a partial repository, architecture independent packages are
not included. You can pull them from the official mirrors using something
like:

deb http://ftp.de.debian.org/debian dists/unstable/main/binary-i386/

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: arm eabi port, patches

[Guillem Jover]

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, which I've done,
 but that raises some questions about definitive arch-names, and
 dpkg-architecture -L. I'll post another mail about that. 

I think the correct thing to do is to merge dpkg-cross into dpkg
itself, and I'm willing to start discussing what's needed from dpkg
side to start incrementaly merging the functionality. Nikita, Neil?

 And that reveals some problems in the existing gcc-4.1-4.1.1ds2 patch
 (armel/armeb are used as a CPU name in rules.def, but they aren't so
 the wrong things try to get built). I've fixed that, and will post
 all three patches once a finished cross-compiler pops out with no
 further probs.

Yeah the cpu name should not change with the port name. ;)

As I told Riku I think the binutils patch might be wrong as well, but
I've not had the time to review it properly.

  Unfortunately I'll not go to FOSDEM this year.
 
 There was no Lennert either (SFAICS). Despite these lacks it was still
 excellent.

That's what I've heard. =)

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-cross, dpkg-architecture and arch names

[Guillem Jover]

[ 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 debian-gnu arch names:

[...]

 Now it seems to me that it would be more sensible to use
 dpkg-architecture to make this table. However dpkg-architecture (with
 guillem's triplet patch ported forward to 1.13.25) has a somewhat
 different table of arches. (See below - it's rather long).

That's because the patch was a proof of concept and not intended to be
used for anything outside i386/arm/armel ports. Otherwise I'd have
commited it already.

 Is there a definitive list of debian arches somewhere?

The point is not needing a definitive list. The only canonical arch
name is the one coming from the toolchain to which we do the mapping
to get the Debian arch name.

 The default list (on both patched and unpatched versions) includes a
 lot of arches that make little sense (like bsd-darwin-sh3,
 kfreebsd-s390) and doesn't include at least one that is useful for
 cross-building: win32-i386. (for use with mingw32 I think).

When the former system was replaced by the new cputable and ostable,
the idea was to be able to generate any combination of possible valid
names that could come up in the future w/o needing to add support for
those explicitely into dpkg. So if suddently somone starts a port for
kfreebsd-arm, it would just be supported.

The latter (missing win32), is a matter of adding that to the ostable,
I can do that, if there's consensus among the win32 porters.

 And all the bsd-based arches have different names, prefixed by bsd. So
 openbsd-i386 is bsd-openbsd-i386. I think this amounts to a bug
 introduced in the triplet patch (it doesn't happen in the old version)
 and should be changed to be implied in the debian arch name, as linux
 is on many arches.

Yep, but as those arches are mostly dead I didn't bother fixing for
the temporary patch.

 There are also a load of gnuaebi-linux-foo arches which are clearly
 bollocks and need removing.

Given the current implementation which combines the ostable and cputable
to generate all possible triplets and then mapping those to Debian
arches, the output is correct even if bogus.

That's one of the reasons I've not commited the patch (not even the
improved one I've around), because the current handling of the arches is
a bit messy. Also because it needs changing the format of the ostable,
which is something I was a bit reluctant to do before the release.

 And armel appearing twice is supicious too. Not sure where that is
 coming from.

Right, noted that on the list.

 And another datapoint is that the gcc built allows a target of avr
 which isn't in the list at all.

Then this needs to be added into the cputable, but there hasn't been
any demand so far.

 Here is the output: dpkg-architecture -L with dpkg 1.13.25 with
 guillem 'triplet' patch:

I don't think my initial patch was producing the redundant armel
entries.

 gnueabi-linux-i386
  ...
 armel

This one is fine is a remapping of arm-linux-gnueabi to armel.

 gnueabi-linux-armel

This one is wrong, there's not cpu called armel.

 gnueabi-linux-sparc
 i386
  ...
 armel

And from the position this one indicates that internally now dpkg is
considering a linux-armel arch, which is wrong as well.

 bsd-darwin-i386
  ...
 bsd-openbsd-sparc

And yes those two need to get the bsd- stripped from the name.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: arm eabi port, patches

[Guillem Jover]

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:

http://lists.debian.org/debian-embedded/2006/05/msg00032.html
   
   Now that I've opened dpkg's trunk for 1.14 (targetted for lenny), I'll
   be appliying a cleaner version of the patch, those versions will be
   going to experimental for now.
  
  I've rebased this patch for dpkg 1.13.25 and it seems to work OK. (I'm
  currently building an emdebian armel cross-toolchain with it.)

For some reason I failed to see this previous mail with the patch. Now
skimming over it I see that at least the arch.m4 change is wrong, it
should not be needed anymore, would have to check the rest.

  I can't see this filed as a bug/patch for dpkg (but there are an awful
  lot, so I may have missed it), so I'll do that unless someone shouts
  that there is a better plan imminent, or that this has in fact already
  been done.

No, it's not there, it's on my TODO list anyway.

 After doing some testing I found that in fact there is a bug.
 dpkg-architecture for i386 gives the Build arch and host differently:
 DEB_BUILD_ARCH=linux-i386
 DEB_HOST_ARCH=i386
 which stops dpkg installing anything on the build machine.
 This is probably my fault rather than Guillem's, but needs fixing
 before it can go upstream.

 I shall try and fix this on the way to fosdem, and if I can't, hope
 Guillem is there to explain it all to me :-)

Unfortunately I'll not go to FOSDEM this year, but I can forward port
the patch even if it's not going to be the defeinitive version merged
into svn.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: arm eabi port available

[Guillem Jover]

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, not many, but as Riku said we were using really outdated
versions of packages.

#407187: apt: use dpkg-architecture to get host architecture
#407191: debianutils: armel and crosscompilation problems
#407192: dosfstools: uses obsolete dpkg argument
#407196: openssl: please add armel support

The others have better versions in your diff dir. Also saw libaio
there, and just uploaded a new package now. And qemu has the arches
added now in svn as well.

  A migration path for current old-ABI Debian users needs to be worked out.
 
 The way I switched one of my boxes over to EABI was to put an EABI root
 fs in /newroot, and then have a perl script move the directories in / to
 /oldroot and the directories in /newroot to /.  I doubt this is a good
 solution for most users, though.

Probably debtakeover could solve this, but I'd have to update it to
support sarge (urgh!) and etch systems first...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: arm eabi port, patches

[Guillem Jover]

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 working on a from-scratch EABI port, sponsored by Applied
 Data Systems (http://www.applieddata.net/)  Six and a half weeks later,
 there's about 6000 debs built, and so far it all seems to work pretty
 well.

Nice!

 I can't share the debs yet (internal and customer use only for now),
 but I would like to get consensus on armel patches before I start
 submitting them.
 
 The first candidate is dpkg.  Guillem Jover's patch available here:
 
   http://lists.debian.org/debian-embedded/2006/05/msg00032.html

Now that I've opened dpkg's trunk for 1.14 (targetted for lenny), I'll
be appliying a cleaner version of the patch, those versions will be
going to experimental for now.

 changes DEB_HOST_GNU_{SYSTEM,TYPE} to have -gnueabi at the end.  I've
 found that this doesn't work too well.

GNU_{SYSTEM,TYPE} map to the gnu triplet stuff, so whatever is in
there should be in those variables, and those variables should be used
mostly only for configure scripts, or similar stuff.

 For example, util-linux does stuff like this all over debian/rules:

   ifeq ($(DEB_HOST_GNU_SYSTEM),linux-gnu)
   MOUNTBINFILES  = mount/mount mount/umount
   MOUNTSBINFILES = mount/swapon mount/losetup
   endif

This is would be broken, it should be using ($(DEB_HOST_ARCH_OS),linux).

 And ruby1.8 does:
 
   arch_dir  = $(subst linux-gnu,linux,$(target_os))

 (which turns arch_dir into arm-linuxeabi instead of arm-linux-eabi.)

The same for this one.

 I asked Joey Hess, and he felt that there are probably more packages
 that depend on linux-gnu than on having gnueabi, which makes sense.
 The only packages that really need to know about gnueabi are binutils,
 gcc and glibc, the rest should just be checking defined(__ARM_EABI__).

I'd say it's good that those break, thet expose problems in the abuse
and assumptions of those packages when using the wrong variables, and
fixing this may help with portability in the future. ;)

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian EABI arm port name: armel

[Guillem Jover]

[ 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 making armeb EABI in the future

 Except that people are already using the armeb repository for real
 work. If you EABIfy armeb we end up with two sets of Debian packages
 floating around called armeb that are binary incompatible, the
 avoidance of which was the whole reason for making a new arch at all.

It was for the current Debian arm, as it is an official arch. We are
*not* going to break binary compat in any Debian arch if it implies
non smooth transitions/upgrades.

 armel was the worst choice of them all (except maybe the ones with
 hyphens) because armeb already exists and means something else.
 Either we are prevented from making a bigendian ARM EABI repository,
 or we have to throw away the existing armeb repository, which I gather
 people are using for real work.

Moving armeb to EABI should be done before getting it into Debian if
at all, and as it is not official yet and ususally those do not have
any kind of guarantee on binary compat or release status compared with
official Debian arches, I don't see any better time.

Also by creating yet another arch sidewise to armeb, will imply having
to maintain *both*. The arm port is lacking people already in Debian as
to having to maintain *4* ports now. But if you (and a group of people)
is willing to maitain it until there's a clean upgrade path from armeb
to armeb+eabi then we could reconsider (that could imply years). But
I'd strongly suggest you to talk with the armeb developers, which
supposedly are the ones who are going to do the work, and which seem
the ones most appropriate to do this kind of decision.

About arm and armel being confusing, the idea is to create the new
port, create a transition plan and after we can upgrade from the
former to the later smoothly, ditch the oldABI port after one release
and replace it in Debian as the only arm little endian arch.

About the arch names:

* hyphens are bad, mainly because right now they imply os-cpu, so it
  would make more difficult to get a consistent namespace, in case of
  linux, right now it's implicit (linux-i386).
* the arch name does not have to match any real cpu or abi, we just
  need a way to map it to the GNU triplet.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Debian EABI arm port name: armel

[Guillem Jover]

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 mismatch between armeb being old ABI and armel
being EABI, giving a confusing situation. Lennert at least didn't see
any problem in making armeb EABI in the future, before adding it to
the archive.

I'll be preapring a patch for dpkg, and will include in the next
release if there's no big opposition to this name, which will happen
more or less once the latest dpkg migrates into testing.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Deciding new arm EABI port name

[Guillem Jover]

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), I'd like to reach now consensus among the Debian
arm porters for a new arch name which would be used by Debian once
or if it's decided to go for EABI.

There's some current proposals in the wiki page that Riku Voipio and
Martin Guy have been preparing at http://wiki.debian.org/ArmEabiPort,
which I'll include here for the discussion:

,---
|update: since dpkg in etch, gnueabi-arm is pretty much the only choice.

Someone knows what does this mean?

|Suggested names for the new port.
|
| gnueabi-arm (long)

Long and the dash ... =)

| earm (short)
| arm2 (confusing: armN is already overloaded with 2 meanings: core
|   versions and instruction sets)

Agree, it's confusing.

| armel (confusing: armeb is already taken for bigendian old-ABI)

Is there any plan for armeb to switch to EABI before getting into the
archive? If there is this would not be as confusing. Also it would be
nice if the name could be consistent in case armeb wants an EABI
counterpart (if it has not switched to it).

| armeabi
`---

As soon as we have the name I can add it to dpkg ...

regards (with too many hats on),
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]