Debian Bug report logs - #452022
dpkg-dev: please ignore symbols differences on non-official architectures

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Aurelien Jarno <aurel32@debian.org>

Date: Mon, 19 Nov 2007 21:42:01 UTC

Severity: wishlist

Found in version dpkg/1.14.8

Fixed in version dpkg/1.14.12

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Mon, 19 Nov 2007 22:34:47 +0100
Package: dpkg-dev
Version: 1.14.8
Severity: serious
Justification: Potentially breaks all unofficial architectures

The new dpkg-gensymbols is surely a great thing that will help the
release a lot, but it has been pushed into unstable with a *known*
problem: it potentially breaks all unofficial architectures, as the
symbols for those architectures are not available on mole and may 
vary a bit. This causes packages to fails to build in case of 
differences in the list of symbols, and will progressively break all
unofficial architectures, even those that we want to *integrate as an
official* architecture sooner or later.

Listing all unofficial architectures on mole is not something really
easy to do, but on the other hand as unofficial architectures don't
have testing, we don't care about over-strict dependencies.

As already suggested, please ignore new or missing symbols on
unofficial architectures and generate a new symbols file in that case
(the current list of official architectures is: alpha amd64 arm hppa
hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc).

-- System Information:
Debian Release: lenny/sid
Architecture: kfreebsd-i386 (i686)

Kernel: kFreeBSD 6.2-1-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  coreutils                     5.97-5.3   The GNU core utilities
ii  libc0.1                       2.6.1-6    GNU C Library: Shared libraries

dpkg recommends no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurel32@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Mon, 19 Nov 2007 23:32:22 +0100
severity 452022 wishlist
thanks

On Mon, 19 Nov 2007, Aurelien Jarno wrote:
> Package: dpkg-dev
> Version: 1.14.8
> Severity: serious

Huh ?! I know it's important for you, but that doesn't make it RC.

> problem: it potentially breaks all unofficial architectures, as the
> symbols for those architectures are not available on mole and may 
> vary a bit.

This is not a justification.

> This causes packages to fails to build in case of differences in the
> list of symbols, and will progressively break all unofficial
> architectures, even those that we want to *integrate as an official*
> architecture sooner or later.

You're too pessimistic IMO. If the package has
debian/<package>.symbols.<arch> files then it will not fail because it
won't find a symbols file for the given architecture and will thus
generate a brand new one (and the comparison will only find new symbols
and it will not fail).

It will only fail if the package provides a debian/package.symbols file
(i.e. common to all architectures) and if symbols listed in that file
disappear on non-official architectures.

> As already suggested, please ignore new or missing symbols on
> unofficial architectures and generate a new symbols file in that case
> (the current list of official architectures is: alpha amd64 arm hppa
> hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc).

I won't harcode such a behaviour in dpkg. However what is doable is have
an environment variable that will override the "check level" that that the
package is using. Then you just have to make sure that the buildd of the
unofficial arches define that environment variable.

Does that seem reasonable?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Severity set to `wishlist' from `serious' Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Mon, 19 Nov 2007 22:42:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #17 received at 452022@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurel32@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 00:11:39 +0100
Raphael Hertzog a écrit :
> severity 452022 wishlist
> thanks
> 
> On Mon, 19 Nov 2007, Aurelien Jarno wrote:
>> Package: dpkg-dev
>> Version: 1.14.8
>> Severity: serious
> 
> Huh ?! I know it's important for you, but that doesn't make it RC.

Even if it is not important for you that doesn't give you the right to
ignore the problem as you did until now.

I guess it is also very important for the release team, because armel is
supposed to be shipped with lenny in order to drop arm for lenny + 1.
This architecture has to be kept in good shape.

>> problem: it potentially breaks all unofficial architectures, as the
>> symbols for those architectures are not available on mole and may 
>> vary a bit.
> 
> This is not a justification.
> 
>> This causes packages to fails to build in case of differences in the
>> list of symbols, and will progressively break all unofficial
>> architectures, even those that we want to *integrate as an official*
>> architecture sooner or later.
> 
> You're too pessimistic IMO. If the package has
> debian/<package>.symbols.<arch> files then it will not fail because it
> won't find a symbols file for the given architecture and will thus
> generate a brand new one (and the comparison will only find new symbols
> and it will not fail).
> 

As already explained, this is the case. Mole doesn't provide symbols for
unofficial architectures (which I can understand), so packages will
never have the symbols file for unofficial architectures.

And note that I am speaking of real examples. Just try on libusb for
example.

> It will only fail if the package provides a debian/package.symbols file
> (i.e. common to all architectures) and if symbols listed in that file
> disappear on non-official architectures.
>
>> As already suggested, please ignore new or missing symbols on
>> unofficial architectures and generate a new symbols file in that case
>> (the current list of official architectures is: alpha amd64 arm hppa
>> hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc).
> 
> I won't harcode such a behaviour in dpkg. However what is doable is have
> an environment variable that will override the "check level" that that the
> package is using. Then you just have to make sure that the buildd of the
> unofficial arches define that environment variable.
> 
> Does that seem reasonable?

Unfortunately I don't really like this idea because sbuild doesn't keep
environment variables, and I don't really want to patch sbuild every
time I want to update it instead of using the .deb package directly from
debian-admin.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurel32@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 08:35:21 +0100
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> Even if it is not important for you that doesn't give you the right to
> ignore the problem as you did until now.

We've had only one unconclusive IRC discussion, that's not really ignoring
the problem. And I still believe, you're over exagerating the problem
unless there are good reasons why exported API differ on unofficial
architectures more than on official architectures (this could be the case
for kfreebsd-*, I don't know).

> I guess it is also very important for the release team, because armel is
> supposed to be shipped with lenny in order to drop arm for lenny + 1.
> This architecture has to be kept in good shape.

And we'll make sure to find a statisfying solution once you give me all
the relevant infos to really understand how far reaching the problem is.

> > debian/<package>.symbols.<arch> files then it will not fail because it
> > won't find a symbols file for the given architecture and will thus
> > generate a brand new one (and the comparison will only find new symbols
> > and it will not fail).
> 
> As already explained, this is the case. Mole doesn't provide symbols for
> unofficial architectures (which I can understand), so packages will
> never have the symbols file for unofficial architectures.

Did you read what I wrote? I said "it will not fail" if the package
provides only debian/*.symbols.<arch>. 

> And note that I am speaking of real examples. Just try on libusb for
> example.

On which architecture did you try? And how? Where do I have an account on
an armel machine or a kfreebsd one?

Note that this is a case where the API is supposed to be stable across
architectures... can you show me what the differences are and why they are
legitimate?

Please show me the build-failure.

> > I won't harcode such a behaviour in dpkg. However what is doable is have
> > an environment variable that will override the "check level" that that the
> > package is using. Then you just have to make sure that the buildd of the
> > unofficial arches define that environment variable.
> > 
> > Does that seem reasonable?
> 
> Unfortunately I don't really like this idea because sbuild doesn't keep
> environment variables, and I don't really want to patch sbuild every
> time I want to update it instead of using the .deb package directly from
> debian-admin.

This is surely a feature that could be added to sbuild. I asked neuro on
IRC, I'm waiting his answer.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #27 received at 452022@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurel32@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 09:57:16 +0100
On Tue, 20 Nov 2007, Raphael Hertzog wrote:
> Note that this is a case where the API is supposed to be stable across
> architectures... can you show me what the differences are and why they are
> legitimate?
> 
> Please show me the build-failure.

FTR, here's the relevant output for kfreebsd:
dh_makeshlibs -V -plibusb-0.1-4 --add-udeb="libusb-0.1-udeb"
dpkg-gensymbols: warning: some symbols disappeared in the symbols file.
dpkg-gensymbols: warning: debian/libusb-0.1-4/DEBIAN/symbols doesn't match completely debian/libusb-0.1-4/DEBIAN/symbols

--- dpkg-gensymbolsCjbx1b	2007-11-20 08:40:47 +0100
+++ dpkg-gensymbolsa5oh1T	2007-11-20 08:40:47 +0100
@@ -8,7 +8,7 @@
  usb_control_msg@Base 0.1.12-7
  usb_debug@Base 0.1.12-7
  usb_destroy_configuration@Base 0.1.12-7
- usb_detach_kernel_driver_np@Base 0.1.12-7
+#DEPRECATED: 2:0.1.12-7# usb_detach_kernel_driver_np@Base 0.1.12-7
  usb_device@Base 0.1.12-7
  usb_error_errno@Base 0.1.12-7
  usb_error_str@Base 0.1.12-7
@@ -21,7 +21,7 @@
  usb_get_busses@Base 0.1.12-7
  usb_get_descriptor@Base 0.1.12-7
  usb_get_descriptor_by_endpoint@Base 0.1.12-7
- usb_get_driver_np@Base 0.1.12-7
+#DEPRECATED: 2:0.1.12-7# usb_get_driver_np@Base 0.1.12-7
  usb_get_string@Base 0.1.12-7
  usb_get_string_simple@Base 0.1.12-7
  usb_init@Base 0.1.12-7
dh_makeshlibs: command returned error code 256
make: *** [binary-arch] Erreur 1


This proves that with we will have legitimate API difference between
architectures who have differing kernels. I don't think it's representative of
the majority of packages though.

Though it's worth asking ourselves if it would make sense to have an
intermediary fallback between debian/*.symbols.<arch> and debian/*.symbols that
would be debian/*.symbols.<kernel>.

Opinions?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #32 received at 452022@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Aurelien Jarno <aurel32@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 10:29:39 +0100
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>> Even if it is not important for you that doesn't give you the right to
>> ignore the problem as you did until now.
> 
> We've had only one unconclusive IRC discussion, that's not really ignoring
> the problem. And I still believe, you're over exagerating the problem
> unless there are good reasons why exported API differ on unofficial
> architectures more than on official architectures (this could be the case
> for kfreebsd-*, I don't know).
> 
>> I guess it is also very important for the release team, because armel is
>> supposed to be shipped with lenny in order to drop arm for lenny + 1.
>> This architecture has to be kept in good shape.
> 
> And we'll make sure to find a statisfying solution once you give me all
> the relevant infos to really understand how far reaching the problem is.
> 
>>> debian/<package>.symbols.<arch> files then it will not fail because it
>>> won't find a symbols file for the given architecture and will thus
>>> generate a brand new one (and the comparison will only find new symbols
>>> and it will not fail).
>> As already explained, this is the case. Mole doesn't provide symbols for
>> unofficial architectures (which I can understand), so packages will
>> never have the symbols file for unofficial architectures.
> 
> Did you read what I wrote? I said "it will not fail" if the package
> provides only debian/*.symbols.<arch>. 

The ABI can be different on non official architectures, even if mole
only provide a common file for all official architectures.

>> And note that I am speaking of real examples. Just try on libusb for
>> example.
> 
> On which architecture did you try? And how? Where do I have an account on
> an armel machine or a kfreebsd one?

I did test on kfreebsd-i386, but history has prove that it can happens
on other architecture: bugs #441736, #429600 or #342084.

If you want to get access to a GNU/kFreeBSD machine, have a look to
http://io.debian.net/ssh.html .

> Note that this is a case where the API is supposed to be stable across
> architectures... can you show me what the differences are and why they are
> legitimate?
> 
> Please show me the build-failure.

Please see http://temp.aurel32.net/libusb_0.1.12-7_kfreebsd-i386.build

>>> I won't harcode such a behaviour in dpkg. However what is doable is have
>>> an environment variable that will override the "check level" that that the
>>> package is using. Then you just have to make sure that the buildd of the
>>> unofficial arches define that environment variable.
>>>
>>> Does that seem reasonable?
>> Unfortunately I don't really like this idea because sbuild doesn't keep
>> environment variables, and I don't really want to patch sbuild every
>> time I want to update it instead of using the .deb package directly from
>> debian-admin.
> 
> This is surely a feature that could be added to sbuild. I asked neuro on
> IRC, I'm waiting his answer.
> 
> Cheers,


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #37 received at 452022@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 10:29:41 +0100
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Raphael Hertzog wrote:
>> Note that this is a case where the API is supposed to be stable across
>> architectures... can you show me what the differences are and why they are
>> legitimate?
>>
>> Please show me the build-failure.
> 
> FTR, here's the relevant output for kfreebsd:
> dh_makeshlibs -V -plibusb-0.1-4 --add-udeb="libusb-0.1-udeb"
> dpkg-gensymbols: warning: some symbols disappeared in the symbols file.
> dpkg-gensymbols: warning: debian/libusb-0.1-4/DEBIAN/symbols doesn't match completely debian/libusb-0.1-4/DEBIAN/symbols
> 
> --- dpkg-gensymbolsCjbx1b	2007-11-20 08:40:47 +0100
> +++ dpkg-gensymbolsa5oh1T	2007-11-20 08:40:47 +0100
> @@ -8,7 +8,7 @@
>   usb_control_msg@Base 0.1.12-7
>   usb_debug@Base 0.1.12-7
>   usb_destroy_configuration@Base 0.1.12-7
> - usb_detach_kernel_driver_np@Base 0.1.12-7
> +#DEPRECATED: 2:0.1.12-7# usb_detach_kernel_driver_np@Base 0.1.12-7
>   usb_device@Base 0.1.12-7
>   usb_error_errno@Base 0.1.12-7
>   usb_error_str@Base 0.1.12-7
> @@ -21,7 +21,7 @@
>   usb_get_busses@Base 0.1.12-7
>   usb_get_descriptor@Base 0.1.12-7
>   usb_get_descriptor_by_endpoint@Base 0.1.12-7
> - usb_get_driver_np@Base 0.1.12-7
> +#DEPRECATED: 2:0.1.12-7# usb_get_driver_np@Base 0.1.12-7
>   usb_get_string@Base 0.1.12-7
>   usb_get_string_simple@Base 0.1.12-7
>   usb_init@Base 0.1.12-7
> dh_makeshlibs: command returned error code 256
> make: *** [binary-arch] Erreur 1
> 
> 
> This proves that with we will have legitimate API difference between
> architectures who have differing kernels. I don't think it's representative of
> the majority of packages though.
> 
> Though it's worth asking ourselves if it would make sense to have an
> intermediary fallback between debian/*.symbols.<arch> and debian/*.symbols that
> would be debian/*.symbols.<kernel>.

While it will fixes the problem due to the variation of the ABI across
kernels, I am not sure that is the problem we will see the most. The
most problematic variations, will happens on the same kernel, as it
could be seen from bugs #441736, #429600 or #342084.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #42 received at 452022@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 11:05:13 +0100
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> > Though it's worth asking ourselves if it would make sense to have an
> > intermediary fallback between debian/*.symbols.<arch> and debian/*.symbols that
> > would be debian/*.symbols.<kernel>.
> 
> While it will fixes the problem due to the variation of the ABI across
> kernels, I am not sure that is the problem we will see the most. The
> most problematic variations, will happens on the same kernel, as it
> could be seen from bugs #441736, #429600 or #342084.

Riku said in #441736:
"This is the same bug as on unixodbc, #429600, #342084."

The issue is that some supplementary symbols are exported due to libtool
working differently with C++ libs for apparently no good reasons. It is not
really armel-specific (except for the fact that armel generated
supplementary symbols that should be not exported according to the version
script).

In any case, having new symbols as is the case in those reports will not
generate a failure with the default behaviour of dpkg-gensymbols unless
the maintainer want those failures.

So it's still not representative of failures that we're likely to get due
to dpkg-gensymbols (unless many maintainers decide to increase the level
of checks, which I doubt. Furthermore maintainers that do that are likely
reactive maintainer that will quickly integrate changes needed for
unofficial architectures).

That said, we might want to have the possibility to flag private symbols
in symbols file and have a mode where the disparition of private symbols
doesn't cause a failure. Not sure about it. 

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #47 received at 452022@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Raphael Hertzog <hertzog@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 11:22:43 +0100
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>>> Though it's worth asking ourselves if it would make sense to have an
>>> intermediary fallback between debian/*.symbols.<arch> and debian/*.symbols that
>>> would be debian/*.symbols.<kernel>.
>> While it will fixes the problem due to the variation of the ABI across
>> kernels, I am not sure that is the problem we will see the most. The
>> most problematic variations, will happens on the same kernel, as it
>> could be seen from bugs #441736, #429600 or #342084.
> 
> Riku said in #441736:
> "This is the same bug as on unixodbc, #429600, #342084."
> 
> The issue is that some supplementary symbols are exported due to libtool
> working differently with C++ libs for apparently no good reasons. It is not
> really armel-specific (except for the fact that armel generated
> supplementary symbols that should be not exported according to the version
> script).

Please read the bug log again. The supplementary symbols are not the
same on the different architectures, which causes some architectures to
have missing symbols compared to some others.

> In any case, having new symbols as is the case in those reports will not
> generate a failure with the default behaviour of dpkg-gensymbols unless
> the maintainer want those failures.

Wrong. Some symbols are "missing" on armel:
Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base
QGList::count() const

> So it's still not representative of failures that we're likely to get due
> to dpkg-gensymbols (unless many maintainers decide to increase the level
> of checks, which I doubt. Furthermore maintainers that do that are likely
> reactive maintainer that will quickly integrate changes needed for
> unofficial architectures).

As explained, it would have also failed on armel without increasing the
level of checks.

> That said, we might want to have the possibility to flag private symbols
> in symbols file and have a mode where the disparition of private symbols
> doesn't cause a failure. Not sure about it. 

That is not a correct solution. If you are able to list private symbols,
better not export them instead of flagging them.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #52 received at 452022@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 12:05:48 +0100
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> > The issue is that some supplementary symbols are exported due to libtool
> > working differently with C++ libs for apparently no good reasons. It is not
> > really armel-specific (except for the fact that armel generated
> > supplementary symbols that should be not exported according to the version
> > script).
> 
> Please read the bug log again. The supplementary symbols are not the
> same on the different architectures, which causes some architectures to
> have missing symbols compared to some others.

In which case it doesn't make sense to have a common symbols file and the
problem is solved.

> > In any case, having new symbols as is the case in those reports will not
> > generate a failure with the default behaviour of dpkg-gensymbols unless
> > the maintainer want those failures.
> 
> Wrong. Some symbols are "missing" on armel:
> Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base
> QGList::count() const

In turn this is caused by a bug in libtool because that symbol should
never have been exported on any arch... and on armel gcc was doing the
right thing by "inlining" the function properly.

So the initial problem is not armel-specific and I fail to see why
we should ignore it when this failure enabled us to discover a bug in
libtool.

And if you want a permanent work-around, I already suggested the
environment variable. I haven't seen any other better alternative yet.

> > So it's still not representative of failures that we're likely to get due
> > to dpkg-gensymbols (unless many maintainers decide to increase the level
> > of checks, which I doubt. Furthermore maintainers that do that are likely
> > reactive maintainer that will quickly integrate changes needed for
> > unofficial architectures).
> 
> As explained, it would have also failed on armel without increasing the
> level of checks.

Because of a bug in libtool. I fail to see why we should be more lax just
because libtool has bugs.

> > That said, we might want to have the possibility to flag private symbols
> > in symbols file and have a mode where the disparition of private symbols
> > doesn't cause a failure. Not sure about it. 
> 
> That is not a correct solution. If you are able to list private symbols,
> better not export them instead of flagging them.

Yes, but that's not something I control. In fact, if that's what you want,
it's better to fail so that we can report problems to maintainers who will
then prod upstream to implement a version script or similar.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #57 received at 452022@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Raphael Hertzog <hertzog@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 12:18:01 +0100
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>>> The issue is that some supplementary symbols are exported due to libtool
>>> working differently with C++ libs for apparently no good reasons. It is not
>>> really armel-specific (except for the fact that armel generated
>>> supplementary symbols that should be not exported according to the version
>>> script).
>> Please read the bug log again. The supplementary symbols are not the
>> same on the different architectures, which causes some architectures to
>> have missing symbols compared to some others.
> 
> In which case it doesn't make sense to have a common symbols file and the
> problem is solved.

Except that the problem appearing only on unofficial architectures, mole
provide a common symbols file. That is where the problem lies.

>>> In any case, having new symbols as is the case in those reports will not
>>> generate a failure with the default behaviour of dpkg-gensymbols unless
>>> the maintainer want those failures.
>> Wrong. Some symbols are "missing" on armel:
>> Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base
>> QGList::count() const
> 
> In turn this is caused by a bug in libtool because that symbol should
> never have been exported on any arch... and on armel gcc was doing the
> right thing by "inlining" the function properly.
> 
> So the initial problem is not armel-specific and I fail to see why
> we should ignore it when this failure enabled us to discover a bug in
> libtool.

Even if the bug is present in all architectures, its effects are only
visible on armel. And maintainers do not care about unofficial
architectures, so the package will simply FTBFS.

> And if you want a permanent work-around, I already suggested the
> environment variable. I haven't seen any other better alternative yet.
> 
>>> So it's still not representative of failures that we're likely to get due
>>> to dpkg-gensymbols (unless many maintainers decide to increase the level
>>> of checks, which I doubt. Furthermore maintainers that do that are likely
>>> reactive maintainer that will quickly integrate changes needed for
>>> unofficial architectures).
>> As explained, it would have also failed on armel without increasing the
>> level of checks.
> 
> Because of a bug in libtool. I fail to see why we should be more lax just
> because libtool has bugs.

libtool is buggy, and that is even more true for older versions. And if
you look at the archive, you will see that most of libraries use an old
libtool version.

The library has to fixed, but the job of porters is not to fix general
problems with libraries, we already have a lot of work to do in other
domains. But if porters doesn't fix this, the maintainer will simply
ignore the problem, even if a bug report is sent.

Just have a look to the following URL and see how many libtool bugs are
ignored for a very long time:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;users=glibc-bsd-devel@lists.alioth.debian.org;pri0=pending:pending,forwarded,pending-fixed,fixed;ttl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU;pri1=pending%3dpending%2btag%3dwontfix,pending%3dpending%2btag%3dmoreinfo,pending%3dpending%2btag%3dpatch,pending%3dpending%2btag%3dconfirmed,pending%3dpending;ttl1=Will%20Not%20Fix,More%20information%20needed,Patch%20Available,Confirmed,Unclassified;ord1=2,3,4,1,0,5

>>> That said, we might want to have the possibility to flag private symbols
>>> in symbols file and have a mode where the disparition of private symbols
>>> doesn't cause a failure. Not sure about it. 
>> That is not a correct solution. If you are able to list private symbols,
>> better not export them instead of flagging them.
> 
> Yes, but that's not something I control. In fact, if that's what you want,
> it's better to fail so that we can report problems to maintainers who will
> then prod upstream to implement a version script or similar.

I totally agree it's better to fail in such cases, but it is better to
fails on all architectures, so that the problem is not just ignored.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #62 received at 452022@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 12:40:33 +0100
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> >> Please read the bug log again. The supplementary symbols are not the
> >> same on the different architectures, which causes some architectures to
> >> have missing symbols compared to some others.
> > 
> > In which case it doesn't make sense to have a common symbols file and the
> > problem is solved.
> 
> Except that the problem appearing only on unofficial architectures, mole
> provide a common symbols file. That is where the problem lies.

If we manage to have common symbol set for hurd-i386 and all the other
arches, then I think it should be doable to have the same symbol set on
unofficial architectures (or at least a superset).

> > So the initial problem is not armel-specific and I fail to see why
> > we should ignore it when this failure enabled us to discover a bug in
> > libtool.
> 
> Even if the bug is present in all architectures, its effects are only
> visible on armel. And maintainers do not care about unofficial
> architectures, so the package will simply FTBFS.

The fix is to remove one private symbol from the debian/*.symbols file so
that the lack of the symbol doesn't generate a failure. This fix is
trivial and can be done easily in a porter NMU without risking to break
everything.

> libtool is buggy, and that is even more true for older versions. And if
> you look at the archive, you will see that most of libraries use an old
> libtool version.

Indeed, but maybe the implementation of proper symbols versioning in the
debian package will trigger the required relibtoolizing... because 
hurd-i386 also needs it in many cases.

> The library has to fixed, but the job of porters is not to fix general
> problems with libraries, we already have a lot of work to do in other
> domains. But if porters doesn't fix this, the maintainer will simply
> ignore the problem, even if a bug report is sent.

If we follow your logic, we shouldn't do anything because maintainers are
not doing their work. While there's some truth in that, I just can't
accept this conclusion.

> >>> That said, we might want to have the possibility to flag private symbols
> >>> in symbols file and have a mode where the disparition of private symbols
> >>> doesn't cause a failure. Not sure about it. 
> >> That is not a correct solution. If you are able to list private symbols,
> >> better not export them instead of flagging them.
> > 
> > Yes, but that's not something I control. In fact, if that's what you want,
> > it's better to fail so that we can report problems to maintainers who will
> > then prod upstream to implement a version script or similar.
> 
> I totally agree it's better to fail in such cases, but it is better to
> fails on all architectures, so that the problem is not just ignored.

If only... there's no way for me to know if a symbol was intendend to be
private or not. So I can't do this.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Riku Voipio <riku.voipio@iki.fi>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #67 received at 452022@bugs.debian.org (full text, mbox):

From: Riku Voipio <riku.voipio@iki.fi>
To: 452022@bugs.debian.org
Cc: hertzog@debian.org, aurelien@aurel32.net
Subject: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 14:37:04 +0200
[Message part 1 (text/plain, inline)]
Hi,

On armel architecture, the symbol differences have usually been
inlined softfloat symbols being exported. Which is additional symbols
and would thus not break symbol checking (if I understood correctly).
What is more worrying is the lack of unofficial arch information in mole.
Thus maintainers are not aware of issues with their packages on
unofficial archs until someeon files a bug.

I can also see that this potentially much bigger problem for hurd/kfreebsd.

> Though it's worth asking ourselves if it would make sense to have an
> intermediary fallback between debian/*.symbols.<arch> and
> debian/*.symbols that would be debian/*.symbols.<kernel>.

One option would be to use dpkg-architecture provided variables:

DEB_HOST_ARCH=armel
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=arm
DEB_HOST_GNU_CPU=arm
DEB_HOST_GNU_SYSTEM=linux-gnueabi
DEB_HOST_GNU_TYPE=arm-linux-gnueabi

Thus one can use DEB_HOST_ARCH for symbol files specific for one
arch, DEB_HOST_ARCH_OS for kfreebsd/hurd DEB_HOST_ARCH_CPU when
same set of symbols affects arm and armel or all

> Because of a bug in libtool. I fail to see why we should be more lax
> just because libtool has bugs.

I think the pessimism to libtool comes from bugs like #347650 not
getting solved over time.. mind you that bug would help with the
same goal symbols file is working on - making transitions easier.

For the c++ and -version-script bug, #430971 I think this might
be much easier to fix.

> That is not a correct solution. If you are able to list private
> symbols, better not export them instead of flagging them.

> Yes, but that's not something I control. In fact, if that's what you
> want, it's better to fail so that we can report problems to maintainers who
> will then prod upstream to implement a version script or similar.

for most libraries, creating a version script should be be the
same amount of work as separating private/public symbols in .symbols
file. Also automatically generating .symbols file from version script
should not be very hard. The big benefit of using version-scripts
is that it makes dynamic linking much more faster, when the symbol
tables have only the needed symbols.

-- 
"rm -rf" only sounds scary if you don't have backups
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #72 received at 452022@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Tue, 20 Nov 2007 14:38:20 +0100
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>>>> Please read the bug log again. The supplementary symbols are not the
>>>> same on the different architectures, which causes some architectures to
>>>> have missing symbols compared to some others.
>>> In which case it doesn't make sense to have a common symbols file and the
>>> problem is solved.
>> Except that the problem appearing only on unofficial architectures, mole
>> provide a common symbols file. That is where the problem lies.
> 
> If we manage to have common symbol set for hurd-i386 and all the other
> arches, then I think it should be doable to have the same symbol set on
> unofficial architectures (or at least a superset).

You can get data for kfreebsd-i386, kfreebsd-amd64 and armel from
gnuab.org. The repository is rsyncable, and we can even send a push signal.

But that don't solve the problem for other unofficial architectures
(what comes to mind is nexenta, sh4, m32r).

>>> So the initial problem is not armel-specific and I fail to see why
>>> we should ignore it when this failure enabled us to discover a bug in
>>> libtool.
>> Even if the bug is present in all architectures, its effects are only
>> visible on armel. And maintainers do not care about unofficial
>> architectures, so the package will simply FTBFS.
> 
> The fix is to remove one private symbol from the debian/*.symbols file so
> that the lack of the symbol doesn't generate a failure. This fix is
> trivial and can be done easily in a porter NMU without risking to break
> everything.
> 
>> libtool is buggy, and that is even more true for older versions. And if
>> you look at the archive, you will see that most of libraries use an old
>> libtool version.
> 
> Indeed, but maybe the implementation of proper symbols versioning in the
> debian package will trigger the required relibtoolizing... because 
> hurd-i386 also needs it in many cases.
> 
>> The library has to fixed, but the job of porters is not to fix general
>> problems with libraries, we already have a lot of work to do in other
>> domains. But if porters doesn't fix this, the maintainer will simply
>> ignore the problem, even if a bug report is sent.
> 
> If we follow your logic, we shouldn't do anything because maintainers are
> not doing their work. While there's some truth in that, I just can't
> accept this conclusion.

You are changing the truth. I never said "we shouldn't do anything", I
proposed solutions so that the packages do not FTBFS on unofficial
architectures. But you rejecting most them, instead trying to convince
me there is no or very few problems.

Also note that the main difference is that FTBFS are considered RC for
official architectures, so if a maintainer don't do his/her job, others
can NMU the package.

That is not true for unofficial architecture, even if we managed to NMU
 some of them when the maintainer is clearly MIA.


>>>>> That said, we might want to have the possibility to flag private symbols
>>>>> in symbols file and have a mode where the disparition of private symbols
>>>>> doesn't cause a failure. Not sure about it. 
>>>> That is not a correct solution. If you are able to list private symbols,
>>>> better not export them instead of flagging them.
>>> Yes, but that's not something I control. In fact, if that's what you want,
>>> it's better to fail so that we can report problems to maintainers who will
>>> then prod upstream to implement a version script or similar.
>> I totally agree it's better to fail in such cases, but it is better to
>> fails on all architectures, so that the problem is not just ignored.
> 
> If only... there's no way for me to know if a symbol was intendend to be
> private or not. So I can't do this.
> 
> Cheers,


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #77 received at 452022@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: 452022@bugs.debian.org, aurelien@aurel32.net, jeroen@debian.org
Subject: Re: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Wed, 21 Nov 2007 12:51:44 +0100
On Tue, 20 Nov 2007, Riku Voipio wrote:
> On armel architecture, the symbol differences have usually been
> inlined softfloat symbols being exported. Which is additional symbols
> and would thus not break symbol checking (if I understood correctly).

Yes.

> What is more worrying is the lack of unofficial arch information in mole.

You're welcome to help make it available. mole is hosted on merkel, its
source code is on a public repository.

Jeroen seemed to think that it shouldn't be too difficult to do. Jeroen,
can you look into it?

> Thus maintainers are not aware of issues with their packages on
> unofficial archs until someeon files a bug.

That's true even for official arches in many cases. :)
Anyway, I have nothing against adding support for unofficial arches
on mole but the unofficial arches need to be made available in some
coherent archive to not have to hardcode an URL for each unofficial
arch.

Be that gnuab.org or doorstep.debian.net, it doesn't matter much.

> > Though it's worth asking ourselves if it would make sense to have an
> > intermediary fallback between debian/*.symbols.<arch> and
> > debian/*.symbols that would be debian/*.symbols.<kernel>.
> 
> One option would be to use dpkg-architecture provided variables:

I know that, it's precisely because it's easy to do that I suggested it.
If it's useful, I'll implement it.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#452022; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #82 received at 452022@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Aurelien Jarno <aurel32@debian.org>, 452022@bugs.debian.org
Subject: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Date: Wed, 21 Nov 2007 14:43:55 +0100
On Tue, 20 Nov 2007, Raphael Hertzog wrote:
> > Unfortunately I don't really like this idea because sbuild doesn't keep
> > environment variables, and I don't really want to patch sbuild every
> > time I want to update it instead of using the .deb package directly from
> > debian-admin.
> 
> This is surely a feature that could be added to sbuild. I asked neuro on
> IRC, I'm waiting his answer.

FWIW, Ryan is not interested to add this feature. 

During the discussion, we came to the conclusion that we should rather
avoid using debian/*.symbols files in favor of debian/*.symbols.<arch> when
the package maintainer is not sure if there's going to be differences in
the set of symbols for all architectures.

He can use #include to avoid duplicating the content too many times. That
way unofficial arch won't use symbols files until the maintainer
explicitely added support for them.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Tags added: pending Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Wed, 28 Nov 2007 15:06:05 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Aurelien Jarno <aurel32@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #89 received at 452022-close@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 452022-close@bugs.debian.org
Subject: Bug#452022: fixed in dpkg 1.14.12
Date: Thu, 29 Nov 2007 05:32:02 +0000
Source: dpkg
Source-Version: 1.14.12

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:

dpkg-dev_1.14.12_all.deb
  to pool/main/d/dpkg/dpkg-dev_1.14.12_all.deb
dpkg_1.14.12.dsc
  to pool/main/d/dpkg/dpkg_1.14.12.dsc
dpkg_1.14.12.tar.gz
  to pool/main/d/dpkg/dpkg_1.14.12.tar.gz
dpkg_1.14.12_i386.deb
  to pool/main/d/dpkg/dpkg_1.14.12_i386.deb
dselect_1.14.12_i386.deb
  to pool/main/d/dpkg/dselect_1.14.12_i386.deb



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 452022@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@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 29 Nov 2007 06:14:09 +0200
Source: dpkg
Binary: dpkg dselect dpkg-dev
Architecture: source i386 all
Version: 1.14.12
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <team@dpkg.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - package maintenance system for Debian
 dpkg-dev   - package building tools for Debian
 dselect    - user tool to manage Debian packages
Closes: 452022
Changes: 
 dpkg (1.14.12) unstable; urgency=low
 .
   [ Raphael Hertzog ]
   * Add -I<file> option to dpkg-gensymbols to force the usage of a specific
     symbols file.
   * Dpkg::Shlibs::find_library() now returns canonicalized paths.
   * dpkg-shlibdeps always tries the realpath() of a lib as fallback when
     trying to identify the package of a lib (and not only for symlinks).
   * dpkg-shlibdeps doesn't fail any more if it can't find unversioned
     libraries on the presumption that they are just private libraries. Outputs
     a warning instead.
   * Expand the dpkg-shlibdeps manual page with explanations concerning
     failures.
   * The environment variable DPKG_GENSYMBOLS_CHECK_LEVEL can be used to force
     dpkg-gensymbols to use a precise level of checks. Closes: #452022
 .
   [ Guillem Jover ]
   * Define several private functions and variables as static.
   * Move extern declarations to header files and stop defining them as extern.
   * Unify parsing of Section and Priority in dpkg-gencontrol with Homepage.
   * Switch dpkg-scanpackages to use the new Dpkg::ErrorHandling and
     Dpkg::Versions modules.
Files: 
 71c860f0f5cac3268d23d7e489cda3fd 997 admin required dpkg_1.14.12.dsc
 76bf280f2af1711d159ba33e3024d84a 6294479 admin required dpkg_1.14.12.tar.gz
 bfac4bbc9563bb54cf9468cf32caca4b 2149590 admin required dpkg_1.14.12_i386.deb
 50691e1b99dcdbd19253e0bfa6c64819 511682 admin required dselect_1.14.12_i386.deb
 ba9eeaf4917a6d663afd31d82ece2359 320940 utils optional dpkg-dev_1.14.12_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHTkh6uW9ciZ2SjJsRAk9ZAKC8WPGC08dtEk5bAbz/cPatKZBMogCfS89U
XkLf5aut7ruBFJOC8AQT0x0=
=dNcE
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 28 Dec 2007 07:26:49 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 20:05:28 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.