Debian Bug report logs - #695547
fpc does not set EABI tags to distinguish armel and armhf object files.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: peter green <peter.green@postgrad.manchester.ac.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: fpc does not set EABI tags to distinguish armel and armhf object files.

Date: Mon, 10 Dec 2012 01:00:50 +0000

Package: fpc
Severity: important

Note: this bug report is mostly a reminder to myself, i'm not expecting 
anyone else to take any action.

In particular this makes it impossible to distinguish for fpc built 
objects whether they use the soft or hard float ABI and that in turn has 
been causing some problems with a new glibc version in ubuntu (for now 
eglibc has been hacked to fix this but we really want fpc to be 
correctly tagging arm object files (tagging object files on other 
architectures would be nice too but is less important because they don't 
have this soft/hard float ABI split)

some (trimmed) irc discussions of this problem with adam conrad are 
reproduced below

* plugwash wasn't aware it needed fixing
<infinity> It does with glibc 2.16... Well, it did before too, we just 
didn't notice.
<plugwash> what exactly is the problem?
<infinity> It's not writing out the eabi extended attributes to its 
objects, but rather just assuming that linking crti.o will get it 
everything it needs.
<infinity> In 2.15, crti.o (incorrectly) had all the VFP tags turned on, 
so this worked.  In 2.16, it only actually has the tags it needs.
<infinity> So, now fpc's armhf binaries are coming out looking 
suspiciously like armel.
<infinity> I'm writing up a local patch to glibc right now, under the 
assumption that fpc isn't the only compiler that gets this wrong but, 
ultimately, we need to fix the compiler(s).
<plugwash> is this just a cosmetic issue or is it causing problems with 
the hacks debian/ubuntu made to distinguish armel from armhf in a 
multiarch context?
<infinity> The latter, for sure, but it's also rather incorrect to not 
have correct eabi tags.
<plugwash> Can you file a bug report with details of what tags we should 
be setting and how to set them in assembler?
<infinity> I'll get there, yeah.  After I monkeypatch glibc to make sure 
it'll carry us over for now.
<plugwash> file it in debian for now and i'll push it upstream after 
we've got a patch
<infinity> A simple solution for fpc may occur to me when I'm halfway 
through all of this.
<infinity> In typical shower epiphany style.
<plugwash> also in the bug report tell me what version of libc6 I need 
to use to reproduce the issue (I.E. the version that doesn't have the 
"monkeypatch"
<infinity> Check.  If you debootstrap raring right now, that would do 
for you.
<infinity> But I'll give you broken/"fixed" versions for reproduction 
when I get to filing reports.
<infinity> plugwash: Oh, also, glibc and gcc pustream are both carrying 
the new and improved linker path, so if you (or fpc upstream) are still 
waffling about pushing that, it's probably safe to assume we're done and 
decided.
<plugwash> upstream pushed the new linker path without my input :)
<infinity> The new one being /lib/ld-linux-armhf.so.3 ?
<infinity> If so, yay.
<plugwash> yep 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/systems/t_linux.pas?r1=22011&r2=22416
<plugwash> Regarding the tags please file your bug report in debian 
intitially, i'll push it upstream when I have a patch
<infinity> Yup, will do, once I have a handle on what needs changing, 
and how.
<infinity> For now, must shower and go spend time with someone who's far 
less interested in C libraries than I am.
------------------------------------------------
plugwash> BTW last time we spoke it was about elf tagging a new glibc 
version and the implications for compliers that had not previously been 
setting tags
<infinity> Right.  That may have become vaguely moot with some recent 
changes landed in binutils.  I'll have to revisit before I get back to you.
<plugwash> what is the current status on that? was eglibc 
"monkeypatched"? do you have instructions for complier maintainers on 
what tags need to be set on how to set them?
<infinity> Well, not that fpc shouldn't be setting EABI extended 
attributes (it should be), but it may not be particularly harmful if it 
fails to do so in the future either.
<plugwash> right, do you know where I can find what attributes should be 
set and how to set them?
<infinity> plugwash: I mangled eglibc for now, but there are other bits 
landing/landed too that make the immediate concern less interesting.
<infinity> plugwash: The canonical source for attributes that should be 
set it the GCC source.  I have people yelling at me to come eat some 
dinner, but I'll give you a pointer to the specific file in the source 
when I get back and find it again.
<infinity> plugwash: See gcc/config/arm/arm{,-c}.c
<infinity> plugwash: All the calls to EMIT_EABI_ATTRIBUTE
<infinity> plugwash: Which just embeds ".eabi_attribute NN, NN" at the 
asm level.
<infinity> plugwash: My short-term dirty hack to glibc was the 
following, but it doesn't emit all EABI extended attributes, just enough 
to ID a binary as armhf: http://paste.ubuntu.com/1422322/

Message #10 received at 695547@bugs.debian.org (full text, mbox, reply):

From: peter green <plugwash@p10link.net>

To: Steve McIntyre <steve@einval.com>

Cc: 695547@bugs.debian.org, ARM <debian-arm@lists.debian.org>

Subject: Re: armhf ABI flag problems with fpc-built binaries

Date: Tue, 14 Jun 2016 16:25:14 +0100

On 09/06/16 18:55, Steve McIntyre wrote:
> Hi folks,
>
> I'm one of the ARM porters, and I've recently run a scan of binaries
> in the archive to check on the state of the binaries for armel and
> armhf. As part of the ARM ABI, binaries (libraries and programs) are
> expected to specify ELF flags to specify whether they're using the
> hard-float or soft-float ABI (if they care specifically - some
> don't). I've found a few fpc-using packages (both under your
> maintenance and not) that appear to get this wrong, which suggests
> that there might be a toolchain issue here in fpc and friends. My
> scanner is telling me that the following armhf packages are broken:
>
> doublecmd-plugins_0.7.1-2_armhf.deb        hf_flags_wrong:6
> fp-compiler-3.0.0_3.0.0+dfsg-4_armhf.deb   hf_flags_wrong:4
> fp-ide-3.0.0_3.0.0+dfsg-4_armhf.deb        hf_flags_wrong:1
> fp-utils-3.0.0_3.0.0+dfsg-4_armhf.deb      hf_flags_wrong:28 no_hf_flags:2
> gearhead_1.300-1_armhf.deb                 hf_flags_wrong:1
> pasdoc_0.14.0-1_armhf.deb                  hf_flags_wrong:1
>
> "hf_flags_wrong" here means that the package is targeting armhf, but
> binaries within it claim to use the soft-float ABI. "no_hf_flags" is
> the number of binaries that have no ABI float flags attached. To see
> for yourself, you can use "readelf --file-header" to inspect the flags
> on binaries - look for
>
>    Flags:       0x5000202, has entry point, Version5 EABI, soft-float ABI
>
> etc. armhf binaries should show
>
>    Flags:       0x5000402, has entry point, Version5 EABI, hard-float ABI
>
> instead. I'm not sure exactly where fpc would be setting flags like
> this (if anywhere) or if it's calling binutils incorrectly maybe. Can
> anybody help me dig into this please?
>
> (See the attached list for details of the broken files.)
>    
Most likely the place to start in the fpc code is compiler/arm/agarmgas.pas

If someone can tell me what needs to be done at an assembler level I can 
look into making fpc do it. (unfortunately infinity's paste referenced 
in the bug report has expired).

Message #15 received at 695547@bugs.debian.org (full text, mbox, reply):

From: Peter Green <plugwash@debian.org>

To: Steve McIntyre <steve@einval.com>

Cc: Paul Gevers <elbrus@debian.org>, Pascal project developers <pkg-pascal-devel@lists.alioth.debian.org>, 695547@bugs.debian.org, FPC developers' list <fpc-devel@lists.freepascal.org>, control@bugs.debian.org

Subject: Re: sprint/bof @ Debconf to fix fpc bugs #695547 and #826300

Date: Wed, 06 Jul 2016 01:31:54 +0100

[Message part 1 (text/plain, inline)]

Tags 695547 +patch
Thanks

On 05/07/16 23:37, Steve McIntyre wrote:
> So Peter and I were talking a little earlier on #debian-arm,
Specifically we were talking about the arm tag/flag stuff. I haven't 
looked into the powerpc issue.  Freepascal has a chunk of platform/cpu 
specific assembler code that is used for mixed pascal/c programs to 
initialise both the freepascal runtime library and libc. The powerpc 
linux version of this file is located at rtl/linux/powerpc/cprt0.as . It 
would not surprise me if it was something to do with this init code.

It would be good to try and get a backtrace ("access violation" 
generally means that the freepascal runtime library trapped a segfault 
and turned it into an exception).

The remainder of this mail is about the arm tag/flag stuff.
>   and he
> was making good progress on fixing stuff. He may have stuff all done
> shortly, I guess... :-)
>    
I think i've fixed the arm tag/flag stuff. With the small patch attached 
I get the following.

root@odroidu2:/# readelf --file-header /usr/bin/fpc
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x100ec
  Start of program headers:          52 (bytes into file)
  Start of section headers:          410616 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         8
  Section header string table index: 7
root@odroidu2:/#

root@odroidu2:/# readelf -a /usr/bin/fpc
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x100ec
  Start of program headers:          52 (bytes into file)
  Start of section headers:          410616 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         8
  Section header string table index: 7


Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .note.ABI-tag     NOTE            000100c0 0000c0 000020 00   A  0   0 16
  [ 2] .text             PROGBITS        000100e0 0000e0 0501a4 00  AX  0   0  4
  [ 3] .rodata           PROGBITS        00060288 050288 010828 00   A  0   0  8
  [ 4] .data             PROGBITS        00081000 061000 003395 00  WA  0   0  8
  [ 5] .bss              NOBITS          00084398 064395 00237c 00  WA  0   0  4
  [ 6] .ARM.attributes   ARM_ATTRIBUTES  00000000 064395 000021 00      0   0  1
  [ 7] .shstrtab         STRTAB          00000000 0643b6 000042 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00010000 0x00010000 0x60ab0 0x60ab0 R E 0x10000
  LOAD           0x061000 0x00081000 0x00081000 0x03395 0x05714 RW  0x10000
  NOTE           0x0000c0 0x000100c0 0x000100c0 0x00020 0x00020 R   0x10
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.ABI-tag .text .rodata
   01     .data .bss
   02     .note.ABI-tag
   03

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Displaying notes found at file offset 0x000000c0 with length 0x00000020:
  Owner                 Data size       Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.0.0
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_VFP_args: VFP registers
root@odroidu2:/#

Which looks good to me, does it look ok to others here?

Some extracts from IRC for future reference.
<plugwash> does anyone know where I can find a decoder for 
.eabi_attribute statements ?
<--snip-->
* plugwash is trying to decipher the output of gcc -S but is struggling 
to find a list anywhere of what the numbers mean
<Sledge> ok...
<--snip-->
<Sledge> plugwash: I just tend to use readelf -A
<plugwash> what i'm trying to figure out is what I need to make fpc put 
in it's assembler files so the binaries come out tagged correctly
<Sledge> ack
<Sledge> I'm looking myself again, I added this stuff in binutils after all
<Sledge> but it's been a while
<Sledge> waiting on downloads ...
<--snip-->
<Sledge> plugwash: look at 3bfcb6528e6fb6a324b2e119f50f72a0674a1402 in 
git://sourceware.org/git/binutils-gdb.git for inspiration, maybe
* Sicelo009N (~sicelo@137.158.22.65) has joined #debian-arm
<Sledge> (unfortunately that's a few changes pushed together)
<plugwash> looks like the numbers are in elfcpp/arm.h in the binutils source
<Sledge> yup
<plugwash> one thing that is puzzling me, how do tags relate to flags?
<Sledge> tags are in the attributes section, and are basically a list
<Sledge> flags are specifically added in the ELF header to make them 
easier to work with
<Sledge> (not sure if that's what you're asking)
<plugwash> more what I was meaning is where do flags come from?
<Sledge> ah, ok
<plugwash> does the compiler have to set them explicitly? (and if so 
how?) does the linker turn tags into flags? something else?
<vagrantc> when one flag loves another flag...
<Sledge> vagrantc: :-)
<Sledge> plugwash: the compiler will set tags on various objects as it runs
<Sledge> the linker will check for the union of the tags and flags set 
and set flags appropriately on the output objects
<Sledge> elf32_arm_post_process_headers() is important here
<plugwash> right, so If I set the tags correctly binutils should set the 
flags correctly?
<plugwash> ok, it seems .o files have meaninful tags but not meaninful flags
* TiN (~TiN@00018ff4.user.oftc.net) has joined #debian-arm
<plugwash> ok, just tested it looks like tags in the assembler file 
remain as tags in the .o file and are then converted to flags by the linker.
<Sledge> yup
<plugwash> i'm guessing the critical tag is Tag_ABI_VFP_args correct?
<plugwash> looks like it, removing that tag results in a change of flags
<Sledge> yeah
<Sledge> (sorry, just changed rooms here)
* Sicelo009N has quit (Read error: Connection reset by peer)
<plugwash> ok, now to try and insert that into freepascal
* Sicelo009N (~sicelo@137.158.22.65) has joined #debian-arm
<plugwash> i've just make a change to fpc which I hope will fix this, 
now for a testbuild
<Sledge> woo
<plugwash> btw one thing i've noticed about this issue is it only seems 
to affect "pure" pascal binaries, binaries that link against libc seem 
to pick up the tags from somewhere
<plugwash> I gtg
<Sledge> right
<Sledge> the things linking with libc will probably end up getting the 
right flags automatically by merging with the libc flags

[fpc.debdiff (text/plain, attachment)]

Message #22 received at 695547@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Peter Green <plugwash@debian.org>

Cc: Paul Gevers <elbrus@debian.org>, Pascal project developers <pkg-pascal-devel@lists.alioth.debian.org>, 695547@bugs.debian.org, FPC developers' list <fpc-devel@lists.freepascal.org>, control@bugs.debian.org

Subject: Re: sprint/bof @ Debconf to fix fpc bugs #695547 and #826300

Date: Sun, 17 Jul 2016 01:08:34 +0100

Hi Peter,

Sorry to keep you waiting - I was on VAC in South Africa after
DebConf, and I'm just catching up on things again now.

On Wed, Jul 06, 2016 at 01:31:54AM +0100, Peter Green wrote:
>Tags 695547 +patch
>Thanks
>
>On 05/07/16 23:37, Steve McIntyre wrote:
>>So Peter and I were talking a little earlier on #debian-arm,
>Specifically we were talking about the arm tag/flag stuff. I haven't looked
>into the powerpc issue.  Freepascal has a chunk of platform/cpu specific
>assembler code that is used for mixed pascal/c programs to initialise both
>the freepascal runtime library and libc. The powerpc linux version of this
>file is located at rtl/linux/powerpc/cprt0.as . It would not surprise me if
>it was something to do with this init code.
>
>It would be good to try and get a backtrace ("access violation" generally
>means that the freepascal runtime library trapped a segfault and turned it
>into an exception).
>
>The remainder of this mail is about the arm tag/flag stuff.
>>  and he
>>was making good progress on fixing stuff. He may have stuff all done
>>shortly, I guess... :-)
>I think i've fixed the arm tag/flag stuff. With the small patch attached I
>get the following.
>
>root@odroidu2:/# readelf --file-header /usr/bin/fpc
>ELF Header:
>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>  Class:                             ELF32
>  Data:                              2's complement, little endian
>  Version:                           1 (current)
>  OS/ABI:                            UNIX - System V
>  ABI Version:                       0
>  Type:                              EXEC (Executable file)
>  Machine:                           ARM
>  Version:                           0x1
>  Entry point address:               0x100ec
>  Start of program headers:          52 (bytes into file)
>  Start of section headers:          410616 (bytes into file)
>  Flags:                             0x5000400, Version5 EABI, hard-float ABI
>  Size of this header:               52 (bytes)
>  Size of program headers:           32 (bytes)
>  Number of program headers:         4
>  Size of section headers:           40 (bytes)
>  Number of section headers:         8
>  Section header string table index: 7
>root@odroidu2:/#
>
>root@odroidu2:/# readelf -a /usr/bin/fpc
>ELF Header:
>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>  Class:                             ELF32
>  Data:                              2's complement, little endian
>  Version:                           1 (current)
>  OS/ABI:                            UNIX - System V
>  ABI Version:                       0
>  Type:                              EXEC (Executable file)
>  Machine:                           ARM
>  Version:                           0x1
>  Entry point address:               0x100ec
>  Start of program headers:          52 (bytes into file)
>  Start of section headers:          410616 (bytes into file)
>  Flags:                             0x5000400, Version5 EABI, hard-float ABI
>  Size of this header:               52 (bytes)
>  Size of program headers:           32 (bytes)
>  Number of program headers:         4
>  Size of section headers:           40 (bytes)
>  Number of section headers:         8
>  Section header string table index: 7
>
>
>Section Headers:
>  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
>  [ 1] .note.ABI-tag     NOTE            000100c0 0000c0 000020 00   A  0   0 16
>  [ 2] .text             PROGBITS        000100e0 0000e0 0501a4 00  AX  0   0  4
>  [ 3] .rodata           PROGBITS        00060288 050288 010828 00   A  0   0  8
>  [ 4] .data             PROGBITS        00081000 061000 003395 00  WA  0   0  8
>  [ 5] .bss              NOBITS          00084398 064395 00237c 00  WA  0   0  4
>  [ 6] .ARM.attributes   ARM_ATTRIBUTES  00000000 064395 000021 00      0   0  1
>  [ 7] .shstrtab         STRTAB          00000000 0643b6 000042 00      0   0  1
>Key to Flags:
>  W (write), A (alloc), X (execute), M (merge), S (strings)
>  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
>  O (extra OS processing required) o (OS specific), p (processor specific)
>
>There are no section groups in this file.
>
>Program Headers:
>  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>  LOAD           0x000000 0x00010000 0x00010000 0x60ab0 0x60ab0 R E 0x10000
>  LOAD           0x061000 0x00081000 0x00081000 0x03395 0x05714 RW  0x10000
>  NOTE           0x0000c0 0x000100c0 0x000100c0 0x00020 0x00020 R   0x10
>  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
>
> Section to Segment mapping:
>  Segment Sections...
>   00     .note.ABI-tag .text .rodata
>   01     .data .bss
>   02     .note.ABI-tag
>   03
>
>There is no dynamic section in this file.
>
>There are no relocations in this file.
>
>There are no unwind sections in this file.
>
>No version information found in this file.
>
>Displaying notes found at file offset 0x000000c0 with length 0x00000020:
>  Owner                 Data size       Description
>  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
>    OS: Linux, ABI: 2.0.0
>Attribute Section: aeabi
>File Attributes
>  Tag_CPU_name: "7-A"
>  Tag_CPU_arch: v7
>  Tag_CPU_arch_profile: Application
>  Tag_ARM_ISA_use: Yes
>  Tag_THUMB_ISA_use: Thumb-2
>  Tag_FP_arch: VFPv3-D16
>  Tag_ABI_VFP_args: VFP registers
>root@odroidu2:/#
>
>Which looks good to me, does it look ok to others here?

That all looks good to me, yes. Thanks for this!

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Message #27 received at 695547-close@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: 695547-close@bugs.debian.org

Subject: Bug#695547: fixed in fpc 3.0.0+dfsg-7

Date: Mon, 22 Aug 2016 22:07:02 +0000

Source: fpc
Source-Version: 3.0.0+dfsg-7

We believe that the bug you reported is fixed in the latest version of
fpc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 695547@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Gevers <elbrus@debian.org> (supplier of updated fpc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Mon, 22 Aug 2016 22:03:07 +0200
Source: fpc
Binary: fpc-3.0.0 fpc-source-3.0.0 fp-compiler-3.0.0 fp-ide-3.0.0 fp-utils-3.0.0 fp-docs-3.0.0 fp-units-rtl-3.0.0 fp-units-base-3.0.0 fp-units-fcl-3.0.0 fp-units-fv-3.0.0 fp-units-gtk2-3.0.0 fp-units-db-3.0.0 fp-units-gfx-3.0.0 fp-units-net-3.0.0 fp-units-math-3.0.0 fp-units-misc-3.0.0 fp-units-multimedia-3.0.0 fp-units-i386-3.0.0 fpc fpc-source fp-compiler fp-ide fp-utils fp-docs fp-units-rtl fp-units-base fp-units-fcl fp-units-fv fp-units-gtk2 fp-units-db fp-units-gfx fp-units-net fp-units-math fp-units-misc fp-units-multimedia fp-units-i386
Architecture: source
Version: 3.0.0+dfsg-7
Distribution: unstable
Urgency: medium
Maintainer: Pascal Packaging Team <pkg-pascal-devel@lists.alioth.debian.org>
Changed-By: Paul Gevers <elbrus@debian.org>
Description:
 fp-compiler - Free Pascal - compiler dependency package
 fp-compiler-3.0.0 - Free Pascal - compiler
 fp-docs    - Free Pascal - documentation dependency package
 fp-docs-3.0.0 - Free Pascal - documentation
 fp-ide     - Free Pascal - IDE dependency package
 fp-ide-3.0.0 - Free Pascal - IDE
 fp-units-base - Free Pascal - base units dependency package
 fp-units-base-3.0.0 - Free Pascal - base units
 fp-units-db - Free Pascal - database-library units dependency package
 fp-units-db-3.0.0 - Free Pascal - database-library units
 fp-units-fcl - Free Pascal - Free Component Library dependency package
 fp-units-fcl-3.0.0 - Free Pascal - Free Component Library
 fp-units-fv - Free Pascal - Free Vision units dependency package
 fp-units-fv-3.0.0 - Free Pascal - Free Vision units
 fp-units-gfx - Free Pascal - graphics-library units dependency package
 fp-units-gfx-3.0.0 - Free Pascal - graphics-library units
 fp-units-gtk2 - Free Pascal - GTK+ 2.x units dependency package
 fp-units-gtk2-3.0.0 - Free Pascal - GTK+ 2.x units
 fp-units-i386 - Free Pascal - Kylix compatibility units dependency package
 fp-units-i386-3.0.0 - Free Pascal - Kylix compatibility units
 fp-units-math - Free Pascal - math units dependency package
 fp-units-math-3.0.0 - Free Pascal - math units
 fp-units-misc - Free Pascal - miscellaneous units dependency package
 fp-units-misc-3.0.0 - Free Pascal - miscellaneous units
 fp-units-multimedia - Free Pascal - multimedia units dependency package
 fp-units-multimedia-3.0.0 - Free Pascal - multimedia units
 fp-units-net - Free Pascal - networking units dependency package
 fp-units-net-3.0.0 - Free Pascal - networking units
 fp-units-rtl - Free Pascal - runtime libraries dependency package
 fp-units-rtl-3.0.0 - Free Pascal - runtime libraries
 fp-utils   - Free Pascal - utilities dependency package
 fp-utils-3.0.0 - Free Pascal - utilities
 fpc        - Free Pascal - SDK suite dependency package
 fpc-3.0.0  - Free Pascal - SDK-3.0.0 suite
 fpc-source - Free Pascal - SDK source code dependency package
 fpc-source-3.0.0 - Free Pascal - SDK source code
Closes: 695547 826300 830906
Changes:
 fpc (3.0.0+dfsg-7) unstable; urgency=medium
 .
   [ Paul Gevers ]
   * Now really bumb Standards to 3.9.8 (forgot control.in)
   * Make output of fix-fp-timestamps update unique
   * autopkgtest failed to run properly due to accidental removal of code
     in 3.0.0+dfsg-5 and missing g++
   * Add fp-utils-# and fp-docs-# to the Depends of fpc to get all packages
     installed
   * Add fix_powerpc_ftbfs_with_new_glibc.patch to fix the FTBFS on powerpc
     with glibc 2.23 (Closes: #826300)
 .
   [ Peter Michael Green ]
   * Add elf tag to mark hardfp binaries as such. (Closes: #695547)
   * Add further-arm64-fixes.patch to fix IDE crash on arm64 (Closes:
     #830906)
Checksums-Sha1:
 cbb60c3e38a7e733a7e775ce72c40bca8699cf11 4098 fpc_3.0.0+dfsg-7.dsc
 7e0398d8cf94a78f149716e567496f4d1292be79 250400 fpc_3.0.0+dfsg-7.debian.tar.xz
Checksums-Sha256:
 4be7380c8bd49795d524eb7fef88c2a08b38dc9f98463d88d77108a8e2f00cb5 4098 fpc_3.0.0+dfsg-7.dsc
 507ec38b99e5c91db0a345c706c1e649779e5d997f2b4205717b0502feb5cd8a 250400 fpc_3.0.0+dfsg-7.debian.tar.xz
Files:
 6ea3f53755fe07da76fb4cd10c2c2d7e 4098 devel optional fpc_3.0.0+dfsg-7.dsc
 8728c156107f2ae9c2277708d5bb93a9 250400 devel optional fpc_3.0.0+dfsg-7.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJXu11kAAoJEJxcmesFvXUKWIQIAJ4J9hETBUE686s9NgP9d+pd
FL87GE6khO3kGCaDhdMSGbaJtuVrg2k7Itm6ULUSUcL2zUwSP3beI24Mo0z7GfmN
jwAnL4t3vULb+QMEh30z+gOfaPMrwP2zpyDH7faNd7QLVtuKda40p37paZSE0Tul
NqXbsIkTie7OikIbNQ6EPptQ12p4aCqr8sIQEpyEISVz0jmbHy07ubjF7hrFuDu0
5M4qfAvvRlV49DID686NHa7FD5xJgsWtzeSsWlk2eT4DgcUvGUkLCqqP7f6ayrd3
jpFEIdCiJ1dcrr62NyRytHdDYGYClY+S5Mur0XSv69BEwHoGNaOT1x3MfA81aag=
=z7gs
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.