Debian Bug report logs - #785344
libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Display info messages

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

From: Michael Hudson-Doyle <michael.hudson@canonical.com>

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

Subject: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Fri, 15 May 2015 15:03:53 +1200

Package: libdpkg-perl
Version: 1.17.25ubuntu1
Severity: normal

Dear Maintainer,

I have been working on adding support to the native Go toolchain for shared
libraries.  Upstream git now produces shared libraries and dpkg-shlibdeps 
complains noisily when processing them:

dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string

I suppose a few regexp tweaks are required.

Cheers,
mwh


-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), (100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-16-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdpkg-perl depends on:
ii  dpkg              1.17.25ubuntu1
ii  libtimedate-perl  2.3000-2
ii  perl              5.20.2-2

Versions of packages libdpkg-perl recommends:
ii  bzip2                   1.0.6-7
ii  libfile-fcntllock-perl  0.22-1build1
ii  xz-utils                5.1.1alpha+20120614-2ubuntu2

Versions of packages libdpkg-perl suggests:
ii  binutils              2.25-5ubuntu7
pn  debian-keyring        <none>
ii  gcc [c-compiler]      4:4.9.2-2ubuntu2
ii  gcc-4.9 [c-compiler]  4.9.2-10ubuntu13
ii  gnupg                 1.4.18-7ubuntu1
ii  gpgv                  1.4.18-7ubuntu1
ii  patch                 2.7.5-1

-- no debconf information

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

From: Guo Yixuan (郭溢譞) <culu.gyx@gmail.com>

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

Subject: Re: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Mon, 18 May 2015 01:55:57 -0400

Package: libdpkg-perl
Version: 1.17.25
Followup-For: Bug #785344

It seems that ELF symbol names can contain any characters, except "\0".
So a correct solution would be read ELF from perl, instead of using the
output of objdump. (Unless objdump has a -0 option similar to xargs...)

This discussion at golang provides some background:
  https://go-review.googlesource.com/19101

Regards,
Yixuan

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

From: Guillem Jover <guillem@debian.org>

To: Michael Hudson-Doyle <michael.hudson@canonical.com>, 785344@bugs.debian.org, Guo Yixuan <culu.gyx@gmail.com>

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Tue, 19 May 2015 23:24:02 +0200

Hi!

On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
> Package: libdpkg-perl
> Version: 1.17.25ubuntu1
> Severity: normal
> 
> I have been working on adding support to the native Go toolchain for shared
> libraries.

Cool! I've long considered languages not supporting shared libraries
to not be very compelling (to put it mildly :).

> Upstream git now produces shared libraries and dpkg-shlibdeps 
> complains noisily when processing them:
> 
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
> 
> I suppose a few regexp tweaks are required.

This would imply changing the regexes to match on column basis or very
strict amount of spaces, because there are valid cases where a version
node or the visibility markers might or not be present, which seems a
bit more flaky, although I doubt the objdump output format has changed
for a long time, but we'd have to verify that.

In any case, there's several things that come to mind why on first
thought this might seem like not an entirely good idea anyway (w/o
having never actually looked deep into Go in any serious way):

  - Is the ABI (for each supported arch) specified as part of the
    language, or is it an implementation detail?
    + If the latter, it means this might allow linking incompatible
      objects, which is one of the reasons C++ does not specify the
      mangling rules.
  - Do the symbol names interop with GCC Go?
  - How would this handle ABI changes in the future if the symbols are
    not mangled?
  - How would this handle interop with languages that do not support
    spaces? Can you specify to export to a specific language so that
    it gets symbols mangled for that? Or do you need something else
    like manually specifying the symbols in asm, or something like
    FFI?

On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
> Package: libdpkg-perl
> Version: 1.17.25
> Followup-For: Bug #785344
> 
> It seems that ELF symbol names can contain any characters, except "\0".
> So a correct solution would be read ELF from perl, instead of using the
> output of objdump. (Unless objdump has a -0 option similar to xargs...)

While it's true that those are allowed symbols, as I could not find
anything stating otherwise in the ELF spec, I've to wonder about the
wisdom of that choice? But when handling dpkg issues, my most
conservative side comes afloat, so it might just be that talking here. :)

And Implementing an ELF parser in perl, just to be able to support Go,
does not seem very compelling, no.

> This discussion at golang provides some background:
>   https://go-review.googlesource.com/19101

It complains about a session expired and that I need to login, after
ignoring the dialog, I cannot see anything there.

Thanks,
Guillem

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

From: Michael Hudson-Doyle <michael.hudson@canonical.com>

To: Guillem Jover <guillem@debian.org>

Cc: 785344@bugs.debian.org, Guo Yixuan <culu.gyx@gmail.com>

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Wed, 20 May 2015 09:49:22 +1200

On 20 May 2015 at 09:24, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
>> Package: libdpkg-perl
>> Version: 1.17.25ubuntu1
>> Severity: normal
>>
>> I have been working on adding support to the native Go toolchain for shared
>> libraries.
>
> Cool! I've long considered languages not supporting shared libraries
> to not be very compelling (to put it mildly :).

:-)

>> Upstream git now produces shared libraries and dpkg-shlibdeps
>> complains noisily when processing them:
>>
>> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
>> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
>> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
>> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
>>
>> I suppose a few regexp tweaks are required.
>
> This would imply changing the regexes to match on column basis or very
> strict amount of spaces, because there are valid cases where a version
> node or the visibility markers might or not be present, which seems a
> bit more flaky, although I doubt the objdump output format has changed
> for a long time, but we'd have to verify that.

Yeah, the patch I wrote yesterday (at
http://paste.ubuntu.com/11232233/) checks for the number of spaces
indicated by an absent version.  A bit fragile but I don't suppose
this is very likely to change.  Parsing the ELF would be better but
obviously a bunch of work (Go has a nice ELF library :-), doesn't
support versions though).

> In any case, there's several things that come to mind why on first
> thought this might seem like not an entirely good idea anyway (w/o
> having never actually looked deep into Go in any serious way):
>
>   - Is the ABI (for each supported arch) specified as part of the
>     language, or is it an implementation detail?

Oh very much an implementation detail at this point.

>     + If the latter, it means this might allow linking incompatible
>       objects, which is one of the reasons C++ does not specify the
>       mangling rules.
>   - Do the symbol names interop with GCC Go?

I don't know for sure about the names, but there is no chance of the
native toolchain and gccgo directly interoperating anyway: the native
toolchain does not follow the platform ABI.

>   - How would this handle ABI changes in the future if the symbols are
>     not mangled?

At least in the medium term, there is not going to be anywhere near as
much ABI stability over time with a Go library compared to a C or even
C++ library.  A new compiler version implies a new ABI version, for
example.

>   - How would this handle interop with languages that do not support
>     spaces? Can you specify to export to a specific language so that
>     it gets symbols mangled for that? Or do you need something else
>     like manually specifying the symbols in asm, or something like
>     FFI?

Go and other code can not interoperate directly (see above comments
about not following ABI). There is a thing (cgo) that generates code
to support thunking between the two worlds, and you can make it
generate symbols that conform to C's expectations. Besides that, the
symbols that end up containing spaces are not the sort of things that
other languages want to access, it's mostly stuff like the data for a
type.

> On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
>> Package: libdpkg-perl
>> Version: 1.17.25
>> Followup-For: Bug #785344
>>
>> It seems that ELF symbol names can contain any characters, except "\0".
>> So a correct solution would be read ELF from perl, instead of using the
>> output of objdump. (Unless objdump has a -0 option similar to xargs...)
>
> While it's true that those are allowed symbols, as I could not find
> anything stating otherwise in the ELF spec, I've to wonder about the
> wisdom of that choice? But when handling dpkg issues, my most
> conservative side comes afloat, so it might just be that talking here. :)
>
> And Implementing an ELF parser in perl, just to be able to support Go,
> does not seem very compelling, no.
>
>> This discussion at golang provides some background:
>>   https://go-review.googlesource.com/19101
>
> It complains about a session expired and that I need to login, after
> ignoring the dialog, I cannot see anything there.

I think he means https://go-review.googlesource.com/#/c/10191/

Cheers,
mwh

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

From: Guillem Jover <guillem@debian.org>

To: Michael Hudson-Doyle <michael.hudson@canonical.com>, 785344@bugs.debian.org

Cc: Guo Yixuan <culu.gyx@gmail.com>

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Tue, 26 May 2015 07:35:22 +0200

Hi!

On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote:
> On 20 May 2015 at 09:24, Guillem Jover <guillem@debian.org> wrote:
> > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
> >> Package: libdpkg-perl
> >> Version: 1.17.25ubuntu1
> >> Severity: normal

> >> Upstream git now produces shared libraries and dpkg-shlibdeps
> >> complains noisily when processing them:
> >>
> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
> >>
> >> I suppose a few regexp tweaks are required.
> >
> > This would imply changing the regexes to match on column basis or very
> > strict amount of spaces, because there are valid cases where a version
> > node or the visibility markers might or not be present, which seems a
> > bit more flaky, although I doubt the objdump output format has changed
> > for a long time, but we'd have to verify that.
> 
> Yeah, the patch I wrote yesterday (at
> http://paste.ubuntu.com/11232233/) checks for the number of spaces
> indicated by an absent version.  A bit fragile but I don't suppose
> this is very likely to change.  Parsing the ELF would be better but
> obviously a bunch of work (Go has a nice ELF library :-), doesn't
> support versions though).

As mentioned above, we'd need to check if this has changed in the
past, and if so how long ago.

W/o having checked deeply, I think the patch can be simplified, by
just changing the regex to cover the different cases. But I'm still
uncertain if it is a good idea, given that it has the potential to
break existing stuff.

It would be nice if the unit test would cover versions longer than
the normal space padding, and the visibility attributes.

> > In any case, there's several things that come to mind why on first
> > thought this might seem like not an entirely good idea anyway (w/o
> > having never actually looked deep into Go in any serious way):
> >
> >   - Is the ABI (for each supported arch) specified as part of the
> >     language, or is it an implementation detail?
> 
> Oh very much an implementation detail at this point.

Ok.

> >     + If the latter, it means this might allow linking incompatible
> >       objects, which is one of the reasons C++ does not specify the
> >       mangling rules.
> >   - Do the symbol names interop with GCC Go?
> 
> I don't know for sure about the names, but there is no chance of the
> native toolchain and gccgo directly interoperating anyway: the native
> toolchain does not follow the platform ABI.

But if the symbols match then users might end up linking both, which
might become run-time errors instead of link-time ones? This would not
seem ideal. Or is there something else to guarantee no mixups?

> >   - How would this handle ABI changes in the future if the symbols are
> >     not mangled?
> 
> At least in the medium term, there is not going to be anywhere near as
> much ABI stability over time with a Go library compared to a C or even
> C++ library.  A new compiler version implies a new ABI version, for
> example.

Hmm, so what would be the point of shared libraries then? If a new
compiler version implies a new ABI version, then that will require
rebuilding the world, with flag-day transitions, and automatic SOVERSION
bumps or Conflicts or similar.

I'm also not seeing how it could provide a stable ABI w/o some kind of
mangling, or at lest some ABI namespaceing or tagging?

> >   - How would this handle interop with languages that do not support
> >     spaces? Can you specify to export to a specific language so that
> >     it gets symbols mangled for that? Or do you need something else
> >     like manually specifying the symbols in asm, or something like
> >     FFI?
> 
> Go and other code can not interoperate directly (see above comments
> about not following ABI). There is a thing (cgo) that generates code
> to support thunking between the two worlds, and you can make it
> generate symbols that conform to C's expectations.

> Besides that, the symbols that end up containing spaces are not the
> sort of things that other languages want to access, it's mostly stuff
> like the data for a type.

Right, I realized that after sending my reply, when I actually peeked
at the spec for what were valid identifiers. :)

> > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
> >> It seems that ELF symbol names can contain any characters, except "\0".
> >> So a correct solution would be read ELF from perl, instead of using the
> >> output of objdump. (Unless objdump has a -0 option similar to xargs...)
> >
> > While it's true that those are allowed symbols, as I could not find
> > anything stating otherwise in the ELF spec, I've to wonder about the
> > wisdom of that choice? But when handling dpkg issues, my most
> > conservative side comes afloat, so it might just be that talking here. :)
> >
> > And Implementing an ELF parser in perl, just to be able to support Go,
> > does not seem very compelling, no.

I didn't find any perl module in CPAN exposing everything that we'd
need to be able to switch to. Do you know of any?

> >> This discussion at golang provides some background:
> >>   https://go-review.googlesource.com/19101
> >
> > It complains about a session expired and that I need to login, after
> > ignoring the dialog, I cannot see anything there.
> 
> I think he means https://go-review.googlesource.com/#/c/10191/

Ah thanks. So, there seems to be some comments about mangling at least
spaces (or did I misinterpret that)?

Andwhile I could agree that the dpkg perl modules are "buggy" because
they do not support spaces, as allowed by the ELF specs. It seems the
C++ approach was pretty wise when choosing to mangle the symbols and
sidestepped any such issue entirely.

Thanks,
Guillem

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

From: Michael Hudson-Doyle <michael.hudson@canonical.com>

To: Guillem Jover <guillem@debian.org>

Cc: 785344@bugs.debian.org, Guo Yixuan <culu.gyx@gmail.com>

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Tue, 26 May 2015 20:48:48 +1200

On 26 May 2015 at 17:35, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote:
>> On 20 May 2015 at 09:24, Guillem Jover <guillem@debian.org> wrote:
>> > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
>> >> Package: libdpkg-perl
>> >> Version: 1.17.25ubuntu1
>> >> Severity: normal
>
>> >> Upstream git now produces shared libraries and dpkg-shlibdeps
>> >> complains noisily when processing them:
>> >>
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
>> >>
>> >> I suppose a few regexp tweaks are required.
>> >
>> > This would imply changing the regexes to match on column basis or very
>> > strict amount of spaces, because there are valid cases where a version
>> > node or the visibility markers might or not be present, which seems a
>> > bit more flaky, although I doubt the objdump output format has changed
>> > for a long time, but we'd have to verify that.
>>
>> Yeah, the patch I wrote yesterday (at
>> http://paste.ubuntu.com/11232233/) checks for the number of spaces
>> indicated by an absent version.  A bit fragile but I don't suppose
>> this is very likely to change.  Parsing the ELF would be better but
>> obviously a bunch of work (Go has a nice ELF library :-), doesn't
>> support versions though).
>
> As mentioned above, we'd need to check if this has changed in the
> past, and if so how long ago.

Well, as I far as I understand the binutils code (not especially far),
this hasn't changed since 1999.  I got the number of spaces from this
line:


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=ab010d46f4b76d7da9985adef366f4be62c561a4;hb=252b5132c753830d5fd56823373aed85f2a0db63#l811

(There is older history in the binutils git but it seems that master
does not have the older stuff in its history and it confuses me)

> W/o having checked deeply, I think the patch can be simplified, by
> just changing the regex to cover the different cases. But I'm still
> uncertain if it is a good idea, given that it has the potential to
> break existing stuff.
>
> It would be nice if the unit test would cover versions longer than
> the normal space padding, and the visibility attributes.
>
>> > In any case, there's several things that come to mind why on first
>> > thought this might seem like not an entirely good idea anyway (w/o
>> > having never actually looked deep into Go in any serious way):
>> >
>> >   - Is the ABI (for each supported arch) specified as part of the
>> >     language, or is it an implementation detail?
>>
>> Oh very much an implementation detail at this point.
>
> Ok.
>
>> >     + If the latter, it means this might allow linking incompatible
>> >       objects, which is one of the reasons C++ does not specify the
>> >       mangling rules.
>> >   - Do the symbol names interop with GCC Go?
>>
>> I don't know for sure about the names, but there is no chance of the
>> native toolchain and gccgo directly interoperating anyway: the native
>> toolchain does not follow the platform ABI.
>
> But if the symbols match then users might end up linking both, which
> might become run-time errors instead of link-time ones? This would not
> seem ideal. Or is there something else to guarantee no mixups?
>
>> >   - How would this handle ABI changes in the future if the symbols are
>> >     not mangled?
>>
>> At least in the medium term, there is not going to be anywhere near as
>> much ABI stability over time with a Go library compared to a C or even
>> C++ library.  A new compiler version implies a new ABI version, for
>> example.
>
> Hmm, so what would be the point of shared libraries then? If a new
> compiler version implies a new ABI version, then that will require
> rebuilding the world, with flag-day transitions, and automatic SOVERSION
> bumps or Conflicts or similar.
>
> I'm also not seeing how it could provide a stable ABI w/o some kind of
> mangling, or at lest some ABI namespaceing or tagging?
>
>> >   - How would this handle interop with languages that do not support
>> >     spaces? Can you specify to export to a specific language so that
>> >     it gets symbols mangled for that? Or do you need something else
>> >     like manually specifying the symbols in asm, or something like
>> >     FFI?
>>
>> Go and other code can not interoperate directly (see above comments
>> about not following ABI). There is a thing (cgo) that generates code
>> to support thunking between the two worlds, and you can make it
>> generate symbols that conform to C's expectations.
>
>> Besides that, the symbols that end up containing spaces are not the
>> sort of things that other languages want to access, it's mostly stuff
>> like the data for a type.
>
> Right, I realized that after sending my reply, when I actually peeked
> at the spec for what were valid identifiers. :)
>
>> > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
>> >> It seems that ELF symbol names can contain any characters, except "\0".
>> >> So a correct solution would be read ELF from perl, instead of using the
>> >> output of objdump. (Unless objdump has a -0 option similar to xargs...)
>> >
>> > While it's true that those are allowed symbols, as I could not find
>> > anything stating otherwise in the ELF spec, I've to wonder about the
>> > wisdom of that choice? But when handling dpkg issues, my most
>> > conservative side comes afloat, so it might just be that talking here. :)
>> >
>> > And Implementing an ELF parser in perl, just to be able to support Go,
>> > does not seem very compelling, no.
>
> I didn't find any perl module in CPAN exposing everything that we'd
> need to be able to switch to. Do you know of any?
>
>> >> This discussion at golang provides some background:
>> >>   https://go-review.googlesource.com/19101
>> >
>> > It complains about a session expired and that I need to login, after
>> > ignoring the dialog, I cannot see anything there.
>>
>> I think he means https://go-review.googlesource.com/#/c/10191/
>
> Ah thanks. So, there seems to be some comments about mangling at least
> spaces (or did I misinterpret that)?
>
> Andwhile I could agree that the dpkg perl modules are "buggy" because
> they do not support spaces, as allowed by the ELF specs. It seems the
> C++ approach was pretty wise when choosing to mangle the symbols and
> sidestepped any such issue entirely.
>
> Thanks,
> Guillem

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

From: Michael Hudson-Doyle <michael.hudson@canonical.com>

To: Guillem Jover <guillem@debian.org>

Cc: 785344@bugs.debian.org, Guo Yixuan <culu.gyx@gmail.com>

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Tue, 26 May 2015 21:07:28 +1200

Sorry for the truncated reply.

On 26 May 2015 at 17:35, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote:
>> On 20 May 2015 at 09:24, Guillem Jover <guillem@debian.org> wrote:
>> > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
>> >> Package: libdpkg-perl
>> >> Version: 1.17.25ubuntu1
>> >> Severity: normal
>
>> >> Upstream git now produces shared libraries and dpkg-shlibdeps
>> >> complains noisily when processing them:
>> >>
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
>> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
>> >>
>> >> I suppose a few regexp tweaks are required.
>> >
>> > This would imply changing the regexes to match on column basis or very
>> > strict amount of spaces, because there are valid cases where a version
>> > node or the visibility markers might or not be present, which seems a
>> > bit more flaky, although I doubt the objdump output format has changed
>> > for a long time, but we'd have to verify that.
>>
>> Yeah, the patch I wrote yesterday (at
>> http://paste.ubuntu.com/11232233/) checks for the number of spaces
>> indicated by an absent version.  A bit fragile but I don't suppose
>> this is very likely to change.  Parsing the ELF would be better but
>> obviously a bunch of work (Go has a nice ELF library :-), doesn't
>> support versions though).
>
> As mentioned above, we'd need to check if this has changed in the
> past, and if so how long ago.

Well, as I far as I understand the binutils code (not especially far),
this hasn't changed since 1999.  I got the number of spaces from this
line:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;hb=dab394de9e41de54df5e2310e081e1c550326f5b#l1582

and it was there in the initial import:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=ab010d46f4b76d7da9985adef366f4be62c561a4;hb=252b5132c753830d5fd56823373aed85f2a0db63#l811

(There is older history in the binutils git but it seems that master
does not have the older stuff in its ancestry and it confuses me)

> W/o having checked deeply, I think the patch can be simplified, by
> just changing the regex to cover the different cases.

You can tell I'm not a perl natural because I replaced a regexp with
some logic :-)

> But I'm still
> uncertain if it is a good idea, given that it has the potential to
> break existing stuff.

Well yeah, that's the fear.  It would be possible to do something only
in the case of a Go shared library, but that sounds pretty horrible.

> It would be nice if the unit test would cover versions longer than
> the normal space padding, and the visibility attributes.

I'll try to do that tomorrow.

>> > In any case, there's several things that come to mind why on first
>> > thought this might seem like not an entirely good idea anyway (w/o
>> > having never actually looked deep into Go in any serious way):
>> >
>> >   - Is the ABI (for each supported arch) specified as part of the
>> >     language, or is it an implementation detail?
>>
>> Oh very much an implementation detail at this point.
>
> Ok.
>
>> >     + If the latter, it means this might allow linking incompatible
>> >       objects, which is one of the reasons C++ does not specify the
>> >       mangling rules.
>> >   - Do the symbol names interop with GCC Go?
>>
>> I don't know for sure about the names, but there is no chance of the
>> native toolchain and gccgo directly interoperating anyway: the native
>> toolchain does not follow the platform ABI.
>
> But if the symbols match then users might end up linking both, which
> might become run-time errors instead of link-time ones? This would not
> seem ideal. Or is there something else to guarantee no mixups?

I can't really see how you could have that happen without determined
effort.  The user is expected to use the go tool to create and link to
the shared libraries, and that uses different directory for "gc stuff"
and "gccgo stuff" (and the stuff includes the .so symlinks).

>> >   - How would this handle ABI changes in the future if the symbols are
>> >     not mangled?
>>
>> At least in the medium term, there is not going to be anywhere near as
>> much ABI stability over time with a Go library compared to a C or even
>> C++ library.  A new compiler version implies a new ABI version, for
>> example.
>
> Hmm, so what would be the point of shared libraries then?

Being able to distribute security fixes to a library by just updating
the library not all its rdeps and also size on disk; something I did
earlier today:

mwhudson@glamdring:golang$ go build debian/readabihash.go
mwhudson@glamdring:golang$ ls -lh readabihash
-rwxrwxr-x 1 mwhudson mwhudson 3.1M May 26 10:03 readabihash
mwhudson@glamdring:golang$ go build -linkshared debian/readabihash.go
mwhudson@glamdring:golang$ ls -lh readabihash
-rwxrwxr-x 1 mwhudson mwhudson 26K May 26 10:03 readabihash

(and we want to write Go stuff for the phone...)

> If a new
> compiler version implies a new ABI version, then that will require
> rebuilding the world, with flag-day transitions, and automatic SOVERSION
> bumps or Conflicts or similar.

Yes.  I was told by people who know more about this than I do that
this would be painful but not disastrously so.

> I'm also not seeing how it could provide a stable ABI w/o some kind of
> mangling, or at lest some ABI namespaceing or tagging?

I don't understand.

It remains to be seen but I suspect that most new upstream releases of
Go things will break ABI and only targeted bugfixes will not.  We'll
see how things play out in practice.  And in the long term (say 5
years or so), I expect the toolchain will settle down a bit.

>> >   - How would this handle interop with languages that do not suppor
>> >     spaces? Can you specify to export to a specific language so that
>> >     it gets symbols mangled for that? Or do you need something else
>> >     like manually specifying the symbols in asm, or something like
>> >     FFI?
>>
>> Go and other code can not interoperate directly (see above comments
>> about not following ABI). There is a thing (cgo) that generates code
>> to support thunking between the two worlds, and you can make it
>> generate symbols that conform to C's expectations.
>
>> Besides that, the symbols that end up containing spaces are not the
>> sort of things that other languages want to access, it's mostly stuff
>> like the data for a type.
>
> Right, I realized that after sending my reply, when I actually peeked
> at the spec for what were valid identifiers. :)
>
>> > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
>> >> It seems that ELF symbol names can contain any characters, except "\0".
>> >> So a correct solution would be read ELF from perl, instead of using the
>> >> output of objdump. (Unless objdump has a -0 option similar to xargs...)
>> >
>> > While it's true that those are allowed symbols, as I could not find
>> > anything stating otherwise in the ELF spec, I've to wonder about the
>> > wisdom of that choice? But when handling dpkg issues, my most
>> > conservative side comes afloat, so it might just be that talking here. :)
>> >
>> > And Implementing an ELF parser in perl, just to be able to support Go,
>> > does not seem very compelling, no.
>
> I didn't find any perl module in CPAN exposing everything that we'd
> need to be able to switch to. Do you know of any?

I don't.

>> >> This discussion at golang provides some background:
>> >>   https://go-review.googlesource.com/19101
>> >
>> > It complains about a session expired and that I need to login, after
>> > ignoring the dialog, I cannot see anything there.
>>
>> I think he means https://go-review.googlesource.com/#/c/10191/
>
> Ah thanks. So, there seems to be some comments about mangling at least
> spaces (or did I misinterpret that)?

Well the end of the discussion was that I would try to fix the perl.
If I fail, I guess I'll go back to upstream...

> Andwhile I could agree that the dpkg perl modules are "buggy" because
> they do not support spaces, as allowed by the ELF specs. It seems the
> C++ approach was pretty wise when choosing to mangle the symbols and
> sidestepped any such issue entirely.

Well, C++ has other reasons for needing mangling of course.

Cheers,
mwh

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

From: GUO Yixuan <culu.gyx@gmail.com>

To: Guillem Jover <guillem@debian.org>

Cc: Michael Hudson-Doyle <michael.hudson@canonical.com>, 785344@bugs.debian.org

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Tue, 26 May 2015 16:37:01 -0400

Hello,

On Tue, May 26, 2015 at 07:35:22AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote:
> > On 20 May 2015 at 09:24, Guillem Jover <guillem@debian.org> wrote:
> > > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
> > >> Package: libdpkg-perl
> > >> Version: 1.17.25ubuntu1
> > >> Severity: normal
> 
> > >> Upstream git now produces shared libraries and dpkg-shlibdeps
> > >> complains noisily when processing them:
> > >>
> > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884d8 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088
> > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 00000000002884f0 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090
> > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288858 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
> > >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 0000000000288940 R_X86_64_64       type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
> > >>
> > >> I suppose a few regexp tweaks are required.
> > >
> > > This would imply changing the regexes to match on column basis or very
> > > strict amount of spaces, because there are valid cases where a version
> > > node or the visibility markers might or not be present, which seems a
> > > bit more flaky, although I doubt the objdump output format has changed
> > > for a long time, but we'd have to verify that.
> > 
> > Yeah, the patch I wrote yesterday (at
> > http://paste.ubuntu.com/11232233/) checks for the number of spaces
> > indicated by an absent version.  A bit fragile but I don't suppose
> > this is very likely to change.  Parsing the ELF would be better but
> > obviously a bunch of work (Go has a nice ELF library :-), doesn't
> > support versions though).
> 
> As mentioned above, we'd need to check if this has changed in the
> past, and if so how long ago.
> 
> W/o having checked deeply, I think the patch can be simplified, by
> just changing the regex to cover the different cases. But I'm still
> uncertain if it is a good idea, given that it has the potential to
> break existing stuff.
> 
> It would be nice if the unit test would cover versions longer than
> the normal space padding, and the visibility attributes.
> 
> > > In any case, there's several things that come to mind why on first
> > > thought this might seem like not an entirely good idea anyway (w/o
> > > having never actually looked deep into Go in any serious way):
> > >
> > >   - Is the ABI (for each supported arch) specified as part of the
> > >     language, or is it an implementation detail?
> > 
> > Oh very much an implementation detail at this point.
> 
> Ok.
> 
> > >     + If the latter, it means this might allow linking incompatible
> > >       objects, which is one of the reasons C++ does not specify the
> > >       mangling rules.
> > >   - Do the symbol names interop with GCC Go?
> > 
> > I don't know for sure about the names, but there is no chance of the
> > native toolchain and gccgo directly interoperating anyway: the native
> > toolchain does not follow the platform ABI.
> 
> But if the symbols match then users might end up linking both, which
> might become run-time errors instead of link-time ones? This would not
> seem ideal. Or is there something else to guarantee no mixups?
> 
> > >   - How would this handle ABI changes in the future if the symbols are
> > >     not mangled?
> > 
> > At least in the medium term, there is not going to be anywhere near as
> > much ABI stability over time with a Go library compared to a C or even
> > C++ library.  A new compiler version implies a new ABI version, for
> > example.
> 
> Hmm, so what would be the point of shared libraries then? If a new
> compiler version implies a new ABI version, then that will require
> rebuilding the world, with flag-day transitions, and automatic SOVERSION
> bumps or Conflicts or similar.
> 
> I'm also not seeing how it could provide a stable ABI w/o some kind of
> mangling, or at lest some ABI namespaceing or tagging?
> 
> > >   - How would this handle interop with languages that do not support
> > >     spaces? Can you specify to export to a specific language so that
> > >     it gets symbols mangled for that? Or do you need something else
> > >     like manually specifying the symbols in asm, or something like
> > >     FFI?
> > 
> > Go and other code can not interoperate directly (see above comments
> > about not following ABI). There is a thing (cgo) that generates code
> > to support thunking between the two worlds, and you can make it
> > generate symbols that conform to C's expectations.
> 
> > Besides that, the symbols that end up containing spaces are not the
> > sort of things that other languages want to access, it's mostly stuff
> > like the data for a type.
> 
> Right, I realized that after sending my reply, when I actually peeked
> at the spec for what were valid identifiers. :)
> 
> > > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
> > >> It seems that ELF symbol names can contain any characters, except "\0".
> > >> So a correct solution would be read ELF from perl, instead of using the
> > >> output of objdump. (Unless objdump has a -0 option similar to xargs...)
> > >
> > > While it's true that those are allowed symbols, as I could not find
> > > anything stating otherwise in the ELF spec, I've to wonder about the
> > > wisdom of that choice? But when handling dpkg issues, my most
> > > conservative side comes afloat, so it might just be that talking here. :)
> > >
> > > And Implementing an ELF parser in perl, just to be able to support Go,
> > > does not seem very compelling, no.
> 
> I didn't find any perl module in CPAN exposing everything that we'd
> need to be able to switch to. Do you know of any?

No, I don't know either. Those available on CPAN are roughly wrappers
of readelf or something else, probably not better than our wrapper of
objdump.

I'm trying to write a XS module for libbfd, but that won't be anything
close to stable and ready to use.

> 
> > >> This discussion at golang provides some background:
> > >>   https://go-review.googlesource.com/19101
> > >
> > > It complains about a session expired and that I need to login, after
> > > ignoring the dialog, I cannot see anything there.

Sorry for the glitch in the url. I've also seen this complaint after
I opened it the second time...

> > 
> > I think he means https://go-review.googlesource.com/#/c/10191/
> 
> Ah thanks. So, there seems to be some comments about mangling at least
> spaces (or did I misinterpret that)?
> 
> Andwhile I could agree that the dpkg perl modules are "buggy" because
> they do not support spaces, as allowed by the ELF specs. It seems the
> C++ approach was pretty wise when choosing to mangle the symbols and
> sidestepped any such issue entirely.
> 
> Thanks,
> Guillem

Regards,
Yixuan

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

From: Michael Hudson-Doyle <michael.hudson@canonical.com>

To: Guillem Jover <guillem@debian.org>

Cc: 785344@bugs.debian.org, Guo Yixuan <culu.gyx@gmail.com>

Subject: Re: Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

Date: Thu, 4 Jun 2015 14:21:07 +1200

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

On 26 May 2015 at 21:07, Michael Hudson-Doyle
<michael.hudson@canonical.com> wrote:
>> It would be nice if the unit test would cover versions longer than
>> the normal space padding, and the visibility attributes.
>
> I'll try to do that tomorrow.

So it took a week longer than I hoped, but I'm attaching a patch with,
I think, pretty comprehensive tests.  The implementation is the same
as my previous patch (and the tests fail without the new
implementation). I'm not much of a perl programmer, so my perl is
probably as unidiomatic as it gets, but if you can make my test cases
pass I don't really care if you change everything else completely :-)

Cheers,
mwh

[0001-Support-for-spaces-in-symbols-in-Dpkg-Shlibs-Objdump.patch (text/x-patch, attachment)]

Message #48 received at 785344-submitter@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 785344-submitter@bugs.debian.org

Subject: Bug#785344 marked as pending

Date: Sun, 02 Aug 2015 23:20:30 +0000

Control: tag 785344 pending

Hi!

Bug #785344 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    https://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=8bc91e0

---
commit 8bc91e0955c99f48fbc177ba77d84a8d851cfa8c
Author: Guillem Jover <guillem@debian.org>
Date:   Sun Aug 2 02:02:02 2015 +0200

    Dpkg::Shlibs::Objdump: Support spaces in symbol names
    
    The ELF spec does not disallow symbols with embedded spaces, so we
    should really be supporting those. This is required by Go shared
    libraries.
    
    Closes: #785344
    Based-on-patch-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
    Signed-off-by: Guillem Jover <guillem@debian.org>

diff --git a/debian/changelog b/debian/changelog
index fbc0f6c..6104c4e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -65,6 +65,9 @@ dpkg (1.18.2) UNRELEASED; urgency=low
     - Make the dependency comparison deep by comparing not only the first
       dependency alternative, to get them sorted in a reproducible way.
       Based on a patch by Chris Lamb <lamby@debian.org>. Closes: #792491
+    - Support spaces in symbol names in Dpkg::Shlibs::Objdump. This is
+      required by Go shared libraries. Closes: #785344
+      Based on a patch by Michael Hudson-Doyle <michael.hudson@canonical.com>.
   * Test suite:
     - Set SIGINT, SIGTERM and SIGPIPE to their default actions to get
       deterministic behavior.

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

From: Guillem Jover <guillem@debian.org>

To: 785344-close@bugs.debian.org

Subject: Bug#785344: fixed in dpkg 1.18.2

Date: Wed, 05 Aug 2015 03:20:10 +0000

Source: dpkg
Source-Version: 1.18.2

We believe that the bug you reported is fixed in the latest version of
dpkg, 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 785344@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg 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, 03 Aug 2015 15:40:21 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all amd64
Version: 1.18.2
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description:
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 480638 571671 785344 787616 787986 788211 788819 789096 789097 789580 789957 790025 790073 791535 792491 793330
Changes:
 dpkg (1.18.2) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Fix plural form translations for single plural languages. Closes: #790025
   * Add new dpkg-buildpackage -J option, which is a safe version of -j.
   * Fix dpkg-gencontrol to add correct binary filename to debian/files,
     even when overriding the Package field value with the -D option.
     Reported by Niels Thykier <niels@thykier.net>.
   * Move the implicit build-essential:native Build-Depends from
     dpkg-checkbuilddeps to a new vendor hook, as it is Debian-specific.
   * Add support for ignoring built-in build dependencies and conflicts
     with the new «dpkg-buildpackage --ignore-builtin-builddeps» and
     «dpkg-checkbuilddeps -I» options. Closes: #480638, #571671
   * When sys_siglist is defined in the system, try to use NSIG as we cannot
     compute the array size with sizeof(). If NSIG is missing fallback to 32
     items. Prompted by Igor Pashev <pashev.igor@gmail.com>.
   * Use string_to_security_class() instead of a literal SECCLASS value in
     the setexecfilecon() libcompat function, as <selinux/flask.h> is now
     deprecated.
   * Switch libdpkg xz compressor to use CRC64 for integrity checks, to match
     the default on the command-line tool, which should provide slightly better
     detection against damaged data, at a negligible speed difference.
   * Only use the SHELL environment variable for interactive shells.
     Closes: #788819
   * Move tar option --no-recursion before -T in dpkg-deb. With tar > 1.28 the
     --no-recursion option is now positional, and needs to be passed before
     the -T option, otherwise the tarball will end up with duplicated entries.
     Thanks to Richard Purdie <richard.purdie@linuxfoundation.org>.
   * Add an extra level of escaping for double $(evals) in architecture.mk
     and buildflags.mk, so that the variables are computed lazily again.
     Regression introduced in dpkg 1.16.2. Closes: #793330
   * Add binary packages Essential information to Package-List field in the
     .dsc file, as optional essential=yes entries. This allows precomputing
     the pseudo-essential set before starting an architecture bootstrap.
   * Perl modules:
     - Remove non-functional timezone name support from
       Dpkg::Changelog::Entry::Debian.
     - Use Time::Piece (part of the perl core distribution) instead of
       Date::Parse in Dpkg::Changelog::Entry::Debian. This reduces the build
       and run-time dependencies, and helps architecture bootstrapping.
     - Simplify distribution splitting in Dpkg::Changelog::Entry::Debian.
     - Add new function changelog_parse_plugin() in Dpkg::Changelog::Parse.
     - Add new function changelog_parse_debian() in Dpkg::Changelog::Parse, and
       use it in changelog_parse() instead of the external plugin parser when
       the input format is “debian”. This significantly speeds up the parsing.
     - Remove trailing space before handling blank line dot-separator in
       Dpkg::Control::HashCore. Regression introduced in dpkg 1.18.0.
       Reported by Jakub Wilk <jwilk@debian.org>. Closes: #789580
     - Allow the Maintainer field in CTRL_FILE_STATUS.
     - Import make_path from File::Path in Dpkg::Source::Package::V2.
       Regression introduced in dpkg 1.18.0. Closes: #789957
     - Make the BinaryFiles subpackage self-contained by explicitly importing
       File::Spec in Dpkg::Source::Package::V2.
     - Do not exclude pre-existing symlinks when unpacking the debian/ tarball
       in Dpkg::Source::Package::V2. Closes: #790073, #791535
     - Disable the thread sanitizer when the address sanitizer is enabled
       in Dpkg::Vendor::Debian as these are mutually incompatible, and make
       sanitize=+all not work at all.
     - Allow colons (:) in added filenames in Dpkg::Dist::Files, which can be
       present when the upstream version contains colons. Regression introduced
       in dpkg 1.18.0. Reported by Jakub Wilk <jwilk@debian.org>.
     - Future-proof tar invocations in Dpkg::Source::Archive for options that
       might become positional in the future, and by always placing function
       options first.
     - Make the dependency comparison deep by comparing not only the first
       dependency alternative, to get them sorted in a reproducible way.
       Based on a patch by Chris Lamb <lamby@debian.org>. Closes: #792491
     - Support spaces in symbol names in Dpkg::Shlibs::Objdump. This is
       required by Go shared libraries. Closes: #785344
       Based on a patch by Michael Hudson-Doyle <michael.hudson@canonical.com>.
   * Test suite:
     - Set SIGINT, SIGTERM and SIGPIPE to their default actions to get
       deterministic behavior.
     - Add test cases for the makefile snippets.
     - Delete DEB_VENDOR from the environment to get reliable results.
   * Packaging:
     - Make the libdpkg-dev package Multi-Arch:same.
     - Mark libio-string-perl as <!nocheck>.
   * Documentation:
     - Fix grammar in dpkg-architecture(1).
       Thanks to Chris Lamb <lamby@debian.org>. Closes: #787616
     - Use the feature area name in the dpkg-buildflags(1) subsection title.
     - Document DPKG_HOOK_ACTION also in dpkg(1) ENVIRONMENT section.
     - Clarify when some features where added in man pages.
     - Document --yet-to-unpack, --predep-packages and all --assert-<feature>
       commands as supported in both «dpkg --help» and dpkg(1).
     - Document abitable in dpkg-architecture(1).
     - Clarify that an architecture wildcard is a Debian thing in
       dpkg-architecture(1).
     - Document multiarch triplet in dpkg-architecture(1) TERMS section.
     - Remove “my” keyword from Dpkg perl modules function prototypes.
     - Say FUNCTIONS instead of METHODS for Dpkg modules when appropriate.
     - Fix POD syntax inside verbatim paragraph in Dpkg::Changelog.
     - Document and mark Dpkg::Arch as a public module.
     - Fix Dpkg::Changelog::Parse::changelog_parse documentation.
 .
   [ Updated programs translations ]
   * Dutch (Frans Spiesschaert). Closes: #789097
   * Simplified Chinese (Zhou Mo). Closes: #787986
   * Turkish (Mert Dirik). Closes: #788211
   * Vietnamese (Trần Ngọc Quân).
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated dselect translations ]
   * Dutch (Frans Spiesschaert). Closes: #789096
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
Checksums-Sha1:
 2ae95a867db6c932b99e0e0f4f2978a31c8e5c7d 2021 dpkg_1.18.2.dsc
 5460c186c6dc59e7c721084cca8e4888596bdfd2 4345224 dpkg_1.18.2.tar.xz
 4e9ca94b3664562f8ef14ee5af7b69cbfa7d42d5 1425274 dpkg-dev_1.18.2_all.deb
 5bf5998a7769cf88ddb6d2f46aff650ad5972973 2905246 dpkg_1.18.2_amd64.deb
 0c4954a51f2fff280424faf607cf1be4ffd22ab6 1186194 dselect_1.18.2_amd64.deb
 73c66b2905c02fbe94adc352182373aebd82d359 931966 libdpkg-dev_1.18.2_amd64.deb
 d99dec6652852240172f2c45a92daf7cb4f83814 1122344 libdpkg-perl_1.18.2_all.deb
Checksums-Sha256:
 dcc8b376723c4328d0c6af41aed32dd594c80cbd35257f2c3aa55526e052fdee 2021 dpkg_1.18.2.dsc
 11484f2a73d027d696e720a60380db71978bb5c06cd88fe30c291e069ac457a4 4345224 dpkg_1.18.2.tar.xz
 b7cbcb96ee48a8f858c132787618221f1deb1ff1e9723cf73895cc9c6ce498a5 1425274 dpkg-dev_1.18.2_all.deb
 683b28d09035a94899cab1ac8e473f4c7e90cf1188bfcce007b21d3707d0b238 2905246 dpkg_1.18.2_amd64.deb
 985edbd32c251e1f1afc59cbdd412753651d3b814737f84c061e5d46865dd5c9 1186194 dselect_1.18.2_amd64.deb
 da9f68dd5950e14924f359ccf0cb3affaeae798c1951fc847eb3f9935fd0d7ca 931966 libdpkg-dev_1.18.2_amd64.deb
 2f1b9624a9d582b003cdc2e8f31e69b34c66f32c0746a272bd7be19bb06b746e 1122344 libdpkg-perl_1.18.2_all.deb
Files:
 734609a5c0e8a047b3a9d11e77c78337 2021 admin required dpkg_1.18.2.dsc
 63b9d869081ec49adeef6c5ff62d6576 4345224 admin required dpkg_1.18.2.tar.xz
 98cda1fa3ab11ebcb0c4c34e248cda2b 1425274 utils optional dpkg-dev_1.18.2_all.deb
 c9b70772e48be54558481446c11d15f1 2905246 admin required dpkg_1.18.2_amd64.deb
 05f258a6c05460f5c8ff27df3f915db9 1186194 admin optional dselect_1.18.2_amd64.deb
 8d60a4bc3459977bb97c206e2be9f31b 931966 libdevel optional libdpkg-dev_1.18.2_amd64.deb
 8f5078aef6753952e20644205a1107c2 1122344 perl optional libdpkg-perl_1.18.2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVwWI5AAoJELlyvz6krlejR7UP/1wzSY1z5ccAaTDriQpuKA/E
xfJDirpB9JcDjbgdHPp4pwBRp27zWWrhW7VIYRS+5cWOMjmBeaRiXXMMYDDqbKJj
YUxw7c/3MWqUEQYF2V4ZMJX0kjHRdUX8VdhKn98aO78NvdGJsye6STOE3D2EdN+Y
KHxjT0R+SaadvlWyQimsGasXx34SlEoV9JM7sSglzYA/nshmb8N+OGelpLDCAA6U
99f8383npNAih0U8Uc2K7lQBJHD49dJavkbU/mbfSTZIpHO7ZM/X3DVfmctoWZSG
AQ8Rw38FoRqidIMuH0f6hfm0Chilm5PX9IiPsrkGMfixNoiwAU3TLpdKk8jpJ9xx
rJ0gTPnVP2dRvaza1cCtgMrd0CWaNeSTuAjdaOEBHdN/cUdP31xkpPOstwUpymzk
xTZfUHEPdivqydKr7kvbWuESCC21e1o4p6L0Q6cL0zoek0NT2Yvar7Vd4Vytm4db
upY6PMiKTq0yp7eAeBGG2j0iJ4lvf+wS71XC6oH23RijHGio4LkwCcqWUFgOuUJn
4wgm8vyPr0JHWLRtgT8NcizFRJ2sjxFoy6rtzK3dk+G1YzXpUWS3oI2iFsnlgpKm
fS9tJeCssOvruqxyyyUCe9j54MQ2P1PhFGgtDh5XPZ7w0JgIJbtMR04UzfcppMen
DyRup5x087FikSzLzv7o
=hrPH
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.