About dpkg-shlibdeps checks - Debian

This is a discussion on About dpkg-shlibdeps checks - Debian ; Hello, as announced in http://lists.debian.org/debian-devel.../msg00004.html the new dpkg-shlibdeps is stricter in what it accepts and will fail when it can't find dependency information for a library that is used by an executable or a public library (a public library is ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 27

Thread: About dpkg-shlibdeps checks

  1. About dpkg-shlibdeps checks

    Hello,

    as announced in
    http://lists.debian.org/debian-devel.../msg00004.html the
    new dpkg-shlibdeps is stricter in what it accepts and will fail when it
    can't find dependency information for a library that is used by an
    executable or a public library (a public library is defined as a library
    which has a SONAME, see the output of "objdump -p").

    Failures look like this:
    dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient).

    It might also look like this:
    dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: only packages with 'shlibs' files are looked into).

    I believe this change is good because it makes sure we don't upload
    packages lacking some important dependency information (see the bug
    #10807 for a simple example...).

    But it sure breaks quite a few packages who have "private" libraries with
    a SONAME. I'm willing to add meaningful exceptions to the rule and I just
    implemented two of them (not yet committed, so it's not in 1.14.10
    recently uploaded):
    - when the library is in the same package than the binary analyzed
    - when the library is not versionned and can't have a shlibs file

    I think those ought to be enough to avoid many build-failures. In all other
    cases, I believe the right way to fix the failures is to add "shlibs"
    informations even if they are only used between multiple binary packages
    of the same source package. It means that dh_makeshlibs needs to be called
    before dh_shlibdeps of course.

    If you know of other good exceptions, please tell me.

    Cheers,
    --
    Rapha雔 Hertzog

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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: About dpkg-shlibdeps checks

    On Fri, Nov 23, 2007 at 09:39:58AM +0000, Raphael Hertzog wrote:
    > Hello,
    >
    > as announced in
    > http://lists.debian.org/debian-devel.../msg00004.html the
    > new dpkg-shlibdeps is stricter in what it accepts and will fail when it
    > can't find dependency information for a library that is used by an
    > executable or a public library (a public library is defined as a library
    > which has a SONAME, see the output of "objdump -p").
    >
    > Failures look like this:
    > dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient).
    >
    > It might also look like this:
    > dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: only packages with 'shlibs' files are looked into).
    >
    > I believe this change is good because it makes sure we don't upload
    > packages lacking some important dependency information (see the bug
    > #10807 for a simple example...).
    >
    > But it sure breaks quite a few packages who have "private" libraries with
    > a SONAME. I'm willing to add meaningful exceptions to the rule and I just
    > implemented two of them (not yet committed, so it's not in 1.14.10
    > recently uploaded):
    > - when the library is in the same package than the binary analyzed
    > - when the library is not versionned and can't have a shlibs file
    >
    > I think those ought to be enough to avoid many build-failures. In all other
    > cases, I believe the right way to fix the failures is to add "shlibs"
    > informations even if they are only used between multiple binary packages
    > of the same source package. It means that dh_makeshlibs needs to be called
    > before dh_shlibdeps of course.
    >
    > If you know of other good exceptions, please tell me.


    does your plan include having a version of the dpkg-shlibdeps that
    works in "warning-mode" only so that we can have a more extensive idea
    of how the things are going to be, before it stops the development of
    the biggest and already hardest packages to maintain out there ?

    I mean warning that a new dpkg-shlibdeps is in town is a thing, but
    having clues _before_ the storm on how bad the storm will be would be of
    help. It's too early to break _everything_ in Debian. Please consider
    that plan.

    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHRqMMvGr7W6HudhwRApHqAJ9KrGWDxACyZ5AaoJ89UI/FZoyWygCeLZxi
    92iPvWqki69M+oZWLNmDsjw=
    =ECHY
    -----END PGP SIGNATURE-----


  3. Re: About dpkg-shlibdeps checks

    On Fri, 23 Nov 2007, Pierre Habouzit wrote:
    > does your plan include having a version of the dpkg-shlibdeps that
    > works in "warning-mode" only so that we can have a more extensive idea
    > of how the things are going to be, before it stops the development of
    > the biggest and already hardest packages to maintain out there ?


    The --ignore-missing-info flag has been added for this purpose from the
    beginning.

    > I mean warning that a new dpkg-shlibdeps is in town is a thing, but
    > having clues _before_ the storm on how bad the storm will be would be of
    > help.


    Well, the d-d-a mail included a list of affected packages. So we had a
    clue on how many packages are affected. The list has probably evolved
    since september but not by much.

    Cheers,
    --
    Rapha雔 Hertzog

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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: About dpkg-shlibdeps checks

    On 2007-11-23, Raphael Hertzog wrote:
    > Well, the d-d-a mail included a list of affected packages. So we had a
    > clue on how many packages are affected. The list has probably evolved
    > since september but not by much.


    Except covering kde now. KDE didn't change that much since september.

    /Sune


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: About dpkg-shlibdeps checks

    On ven, nov 23, 2007 at 10:14:51 +0000, Raphael Hertzog wrote:
    > On Fri, 23 Nov 2007, Pierre Habouzit wrote:
    > > does your plan include having a version of the dpkg-shlibdeps that
    > > works in "warning-mode" only so that we can have a more extensive idea
    > > of how the things are going to be, before it stops the development of
    > > the biggest and already hardest packages to maintain out there ?

    >
    > The --ignore-missing-info flag has been added for this purpose from the
    > beginning.


    It needs to be activated by the maintainers, which is intrusive. That
    should be the default behavior for the coming weeks. And then changed
    when some carefully chosen targets have been migrated from top to
    bottom.

    But forcing every maintainer that probably had an agenda for their
    package already, to comply to yours without even knowing what's coming
    is at the very least tactless and disruptive.

    Any change of that magnitude has to come in step by step, inch by
    inch. I'm really serious here, I believe that the current behavior of
    dpkg-shlibdeps is premature, and that it needs a progressive and
    incremental introduction.

    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHRrKnvGr7W6HudhwRAnXGAKCn+Shl1MB33X873QSk1N fxL8NgHACghXge
    0wxmxckvpOelhQjYuBv4ve0=
    =H0kE
    -----END PGP SIGNATURE-----


  6. Re: About dpkg-shlibdeps checks

    Pierre Habouzit wrote:

    > But forcing every maintainer that probably had an agenda for their
    > package already, to comply to yours without even knowing what's coming
    > is at the very least tactless and disruptive.


    the new dpkg was in experimental for a long enough time, and this was
    announced often enough. If packages run into trouble with it now, it's
    imho not the problem of the dpkg maintainer (except there're bugs in
    dpkg, of course).

    --
    Bernd Zeimetz



    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: About dpkg-shlibdeps checks

    On Fri, 23 Nov 2007, Sune Vuorela wrote:
    > On 2007-11-23, Raphael Hertzog wrote:
    > > Well, the d-d-a mail included a list of affected packages. So we had a
    > > clue on how many packages are affected. The list has probably evolved
    > > since september but not by much.

    >
    > Except covering kde now. KDE didn't change that much since september.


    Apparently not any more with the dpkg-shlibdeps that implements the exceptions
    that I listed in my first mail... (you know it since you tested it for me)

    I'm willing to take some blame, mind you. But I'm just not willing to
    fully revert a decision because some grumpy maintainers are not happy that
    they have some fixing to do (in particular when it looks like they don't
    really understand the issues at hand).

    Cheers,
    --
    Rapha雔 Hertzog

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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: About dpkg-shlibdeps checks

    On 2007-11-23, Raphael Hertzog wrote:
    > they have some fixing to do (in particular when it looks like they don't
    > really understand the issues at hand).


    If this was targetted at me, then please explain me what I don't really
    understand.

    /Sune


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: About dpkg-shlibdeps checks

    On ven, nov 23, 2007 at 11:31:57 +0000, Raphael Hertzog wrote:
    > (in particular when it looks like they don't really understand the
    > issues at hand).


    Please, this ad hominem isn't deserved, because the KDE team could
    exactly answer the same to you. Mind you, but the huge workload you just
    inflicted to them shows that you maybe underestimate "slightly" what
    their work is.

    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHRrzJvGr7W6HudhwRAk9NAJoD5oVYLobPJj9jv8CxiQ 4TfzDrOQCeOqZH
    Vj4fXhQEhGjwdR1RgqERkN8=
    =mX1f
    -----END PGP SIGNATURE-----


  10. Re: About dpkg-shlibdeps checks

    On Fri, Nov 23, 2007 at 11:15:46AM +0000, Bernd Zeimetz wrote:
    > Pierre Habouzit wrote:
    >
    > > But forcing every maintainer that probably had an agenda for their
    > > package already, to comply to yours without even knowing what's coming
    > > is at the very least tactless and disruptive.

    >
    > the new dpkg was in experimental for a long enough time, and this was
    > announced often enough. If packages run into trouble with it now, it's
    > imho not the problem of the dpkg maintainer (except there're bugs in
    > dpkg, of course).


    I disagree. We have (Raphael among the "we") little clues right now on
    how well the new implementation will work on a large scale. We already
    see a lot of nasty failures happen that aren't expected, because the
    maintainers that will likely suffer from those the most, are the one
    that already had the less time to test it.

    "announcing" a new feature and giving a time-frame for people to
    conform and then shoot them, is not really what I call management.
    Proper management includes a staging period between the absence of the
    failure, and the full pedantic activation of it.

    There is a huge difference between a dpkg in experimental that many a
    couple of people tried, and being forced to suffer its disruption during
    a transition or a long planned upload. So I urge Raphael to keep the
    "errors" warnings for a month so that people can get used to it, and
    take proper measures.

    The disruption it caused to the KDE guys (and I fear for OOo or
    moizilla) isn't _that_ surprising to me, and it's completely unfair to
    prevent them from doing anything. Because that's what dpkg-shlibdeps
    does: the KDE team think it's a 3days effort to support the new
    dpkg-shlibdeps. They had plans, it gets all destroyed because there
    wasn't an incremental introduction of the feature.

    What I've learned, and I believed that Debian should know since: in
    computing (and I believe in many other areas) *NOTHING* works according
    to the plan. So you'd better have a progressive plan to keep the issues
    manageable. The "Off->On" switch button is the worst one can do in that
    regard.

    I absolutely don't understand what Raphael has to gain by forcing
    everyone to fix their package *RIGHT NOW OR YOU DIE HAHAHAHA*, except
    raising the frustration levels wrt a migration that I believe goes in
    the good direction. It's not because it's a good thing that it should be
    aggressively forced and imposed to the face of the world.

    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHRrxdvGr7W6HudhwRAjm3AKCFJTF9tWghZCIs/pYpqM1JBijlbgCgjnZv
    Nrp9+nuSsxCxAF/2aG6p+mY=
    =DUQo
    -----END PGP SIGNATURE-----


  11. Re: About dpkg-shlibdeps checks

    On ven, nov 23, 2007 at 11:31:57 +0000, Raphael Hertzog wrote:
    > But I'm just not willing to fully revert a decision


    Damn I wanted to answer to that, and forgot: I don't think anyone
    wants a revert. I'd expect you to make lower the dpkg-shlibdeps
    expectations for a while, so that we can take our time to catalog every
    issues that it raise.

    Then we'll go through the usual way:

    (1) understand *non disruptive* warnings properly, and sort them
    between the spurious issue packages will have to work around, and
    the one that are usual issue that did not fit in your early
    design.

    (2) Take according actions and propose solutions.

    (3) wait a few weeks, and if too many errors exist, go back to (1)

    (4) hurray \o/ we have a manageable list of issues now, dpkg-shlibdeps
    can turn his fascist pedantic mode on, without getting on
    everybody's nerves.

    Isn't it a better plan ? I believe it would get a 10x better reception
    from the DDs, and would result in a better quality for the tool, because
    choices for the fixes do not need to be done in a hurry.
    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHRr73vGr7W6HudhwRAodlAJwI1HmIPkBYvDdz2mKv0T S+/XkJHACghhKH
    B6O7CCL3STADL5SLnNKeru4=
    =NV2X
    -----END PGP SIGNATURE-----


  12. Re: About dpkg-shlibdeps checks

    Raphael Hertzog wrote:
    > On Fri, 23 Nov 2007, Sune Vuorela wrote:
    >> On 2007-11-23, Raphael Hertzog wrote:
    >>> Well, the d-d-a mail included a list of affected packages. So we had a
    >>> clue on how many packages are affected. The list has probably evolved
    >>> since september but not by much.

    >> Except covering kde now. KDE didn't change that much since september.

    >
    > Apparently not any more with the dpkg-shlibdeps that implements the exceptions
    > that I listed in my first mail... (you know it since you tested it for me)
    >
    > I'm willing to take some blame, mind you. But I'm just not willing to
    > fully revert a decision because some grumpy maintainers are not happy that
    > they have some fixing to do (in particular when it looks like they don't
    > really understand the issues at hand).


    Nowadays there are better alternatives to uploading to unstable for
    archive wide testing IMHO. Uploading to experimental is a good thing to
    have some initial testing on many architectures, though I would go for a
    rebuild of the whole archive for testing things like this for all
    packages... before uploading to unstable.

    I do hope you will think about this next time.

    Cheers

    Luk


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Re: About dpkg-shlibdeps checks

    On Fri, Nov 23, 2007 at 09:49:10PM +0000, Luk Claes wrote:
    > Raphael Hertzog wrote:
    > > On Fri, 23 Nov 2007, Sune Vuorela wrote:
    > >> On 2007-11-23, Raphael Hertzog wrote:
    > >>> Well, the d-d-a mail included a list of affected packages. So we had a
    > >>> clue on how many packages are affected. The list has probably evolved
    > >>> since september but not by much.
    > >> Except covering kde now. KDE didn't change that much since september.

    > >
    > > Apparently not any more with the dpkg-shlibdeps that implements the exceptions
    > > that I listed in my first mail... (you know it since you tested it for me)
    > >
    > > I'm willing to take some blame, mind you. But I'm just not willing to
    > > fully revert a decision because some grumpy maintainers are not happy that
    > > they have some fixing to do (in particular when it looks like they don't
    > > really understand the issues at hand).

    >
    > Nowadays there are better alternatives to uploading to unstable for
    > archive wide testing IMHO. Uploading to experimental is a good thing to
    > have some initial testing on many architectures, though I would go for a
    > rebuild of the whole archive for testing things like this for all
    > packages... before uploading to unstable.


    He did a full rebuild, and even posted a list. Though it was for x86
    which is a tolerant architecture, and the arch where libtool is the less
    broken. And also Raphael had the brilliant idea to upload a code more
    strict than the one used for his tests.

    Both things render the rebuild he did moot.
    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHR08nvGr7W6HudhwRAqgnAJ9ktKuP0pemmBNmY51Je7 8hh+76ngCffrrq
    JeRyG6CSsefQ1pNchhZA56I=
    =C5Fu
    -----END PGP SIGNATURE-----


  14. Re: About dpkg-shlibdeps checks

    On Fri, 23 Nov 2007, Luk Claes wrote:
    > Nowadays there are better alternatives to uploading to unstable for
    > archive wide testing IMHO. Uploading to experimental is a good thing to
    > have some initial testing on many architectures, though I would go for a
    > rebuild of the whole archive for testing things like this for all
    > packages... before uploading to unstable.
    >
    > I do hope you will think about this next time.


    Well, I did. But I should have done another run before the upload to
    unstable, agreed. Because I fixed other bugs since july and because some
    previous runs were done with symbols files (while right now we have no
    symbols files yet in unstable).

    Cheers,
    --
    Rapha雔 Hertzog

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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: About dpkg-shlibdeps checks

    On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote:
    > Hello,


    Hello,

    > as announced in
    > http://lists.debian.org/debian-devel.../msg00004.html the
    > new dpkg-shlibdeps is stricter in what it accepts and will fail when it
    > can't find dependency information for a library that is used by an
    > executable or a public library (a public library is defined as a library
    > which has a SONAME, see the output of "objdump -p").
    >
    > Failures look like this:
    > dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient).
    >
    > It might also look like this:
    > dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: only packages with 'shlibs' files are looked into).


    I am exactly seeing this for 'shogun-octave' and I ask for your advise
    how to fix things. octave2.9 contains a couple of .so files in
    /usr/lib/octave-2.9.17, when building extensions to octave (as with
    shogun-octave), the resulting 'sg.oct' file is linked to some of the .so
    files in that directory, which of course is not available in ld.so.conf
    or the like, so dpkg-shlibdeps fails to find the libraries, e.g.
    liboctinterp.so. Also according to objdump also only has SONAME
    liboctinterp.so. As octave handles loading extensions itself, --rpath or
    the like are not normally needed.

    But what is the intended way of fixing things with the newer
    dpkg-shlibdeps ? Adding --rpath ?


    $ dpkg-shlibdeps build-octave/sg.oct

    dpkg-shlibdeps: failure: couldn't find library liboctinterp.so (note: only packages with 'shlibs' files are looked into).

    $ LD_LIBRARY_PATH=/usr/lib/octave-2.9.17/ dpkg-shlibdeps -v build-octave/sg.oct
    Scanning build-octave/sg.oct (for Depends field)
    Library liboctinterp.so found in /usr/lib/octave-2.9.17/liboctinterp.so
    Library libcruft.so found in /usr/lib/octave-2.9.17/libcruft.so
    Library liboctave.so found in /usr/lib/octave-2.9.17/liboctave.so
    Library liblapack.so.3 found in /usr/lib/liblapack.so.3
    Library libblas.so.3 found in /usr/lib/libblas.so.3
    Library libstdc++.so.6 found in /usr/lib/libstdc++.so.6
    Library libm.so.6 found in /lib/libm.so.6
    Library libgcc_s.so.1 found in /lib/libgcc_s.so.1
    Library libpthread.so.0 found in /lib/libpthread.so.0
    Library libc.so.6 found in /lib/libc.so.6
    Looking up shlibs dependency of libstdc++.so.6 provided by 'libstdc++6'
    Found libstdc++6 (>= 4.2.1) in /var/lib/dpkg/info/libstdc++6.shlibs
    Looking up shlibs dependency of libc.so.6 provided by 'libc6'
    Found libc6 (>= 2.6.1-1) in /var/lib/dpkg/info/libc6.shlibs
    Looking up shlibs dependency of liblapack.so.3 provided by 'lapack3'
    Found atlas3-base | lapack3 | liblapack.so.3 in /var/lib/dpkg/info/lapack3.shlibs
    Looking up shlibs dependency of libblas.so.3 provided by 'refblas3'
    Found atlas3-base | refblas3 | libblas.so.3 in /var/lib/dpkg/info/refblas3.shlibs
    Looking up shlibs dependency of libpthread.so.0 provided by 'libc6'
    Found libc6 (>= 2.6.1-1) in /var/lib/dpkg/info/libc6.shlibs
    Looking up shlibs dependency of libm.so.6 provided by 'libc6'
    Found libc6 (>= 2.6.1-1) in /var/lib/dpkg/info/libc6.shlibs
    Looking up shlibs dependency of liboctinterp.so provided by 'octave2.9'
    dpkg-shlibdeps: warning: Can't extract name and version from library name `liboctinterp.so'
    dpkg-shlibdeps: warning: Can't extract name and version from library name `liboctinterp.so'
    Found nothing
    dpkg-shlibdeps: failure: No dependency information found for liboctinterp.so (used by build-octave/sg.oct).


    I am expecting similar problems with R extensions ... where libR.so is
    in /usr/lib/R/lib/libR.so and not even has a SONAME ...

    Any ideas?

    Thanks,
    Soeren
    --
    For the one fact about the future of which we can be certain is that it
    will be utterly fantastic. -- Arthur C. Clarke, 1962

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

    iD8DBQBHR8uM/h9eL9HisW8RAlOoAJkBIiklFPk2sffHE6lsCIqG0wC0DQCeOrZ b
    89xc9bdmhdVpADCNK//Q+d0=
    =ozNE
    -----END PGP SIGNATURE-----


  16. Re: About dpkg-shlibdeps checks

    On Sat, 24 Nov 2007, Soeren Sonnenburg wrote:
    > But what is the intended way of fixing things with the newer
    > dpkg-shlibdeps ? Adding --rpath ?


    Helping dpkg-shlibdeps with LD_LIBRARY_PATH is the right thing as you did
    below... (option -l for dh_shlibdeps)

    > $ LD_LIBRARY_PATH=/usr/lib/octave-2.9.17/ dpkg-shlibdeps -v build-octave/sg.oct
    > Scanning build-octave/sg.oct (for Depends field)
    > Library liboctinterp.so found in /usr/lib/octave-2.9.17/liboctinterp.so

    [...]
    > dpkg-shlibdeps: failure: No dependency information found for liboctinterp.so (used by build-octave/sg.oct).


    With dpkg 1.14.11 uploaded yersterday evening, this wouldn't have caused
    an error since it's unversionned.

    > I am expecting similar problems with R extensions ... where libR.so is
    > in /usr/lib/R/lib/libR.so and not even has a SONAME ...


    Wihtout SONAME for a private library is the right thing... no reason to
    expect more problems. :-)

    Cheers,
    --
    Rapha雔 Hertzog

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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  17. Re: About dpkg-shlibdeps checks

    On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote:
    > Hello,
    >
    > as announced in
    > http://lists.debian.org/debian-devel.../msg00004.html the
    > new dpkg-shlibdeps is stricter in what it accepts and will fail when it
    > can't find dependency information for a library that is used by an
    > executable or a public library (a public library is defined as a library
    > which has a SONAME, see the output of "objdump -p").
    >
    > Failures look like this:
    > dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient).
    >
    > It might also look like this:
    > dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: only packages with 'shlibs' files are looked into).


    After my last attempts to rebuild the archive (using rebuildd) on
    powerpc, I've faced that given this, lots of packages now FTBFS.

    ie.

    dpkg-shlibdeps: failure: No dependency information found for libecalendar_common_conduit.so (used by debian/evolution/usr/lib/evolution/2.12/conduits/libetodo_conduit.so).
    dh_shlibdeps: command returned error code 512
    make: *** [binary-predeb-IMPL/evolution] Error 1
    dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit
    status 2

    So, how should we expect buildds to behave after this change? Should all
    of these FTBFSs be filed on the BTS? What should rebuilders do? Consider
    these questions just for the sake of a better understanding on actions
    taken.

    --
    David Moreno Garza | http://www.damog.net/
    Que toda la gente diga, "ah, ese g╡y existe".


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

    iD8DBQBHSHrxmBxf18ZxJX0RAmoKAJ963az2VlsMx/xFaJAOx3rYOg3USACfS5dM
    i0324JpFzV2ocmJhP4AysCM=
    =lKrT
    -----END PGP SIGNATURE-----


  18. Re: About dpkg-shlibdeps checks

    On Sat, 24 Nov 2007, David Moreno Garza wrote:
    > After my last attempts to rebuild the archive (using rebuildd) on
    > powerpc, I've faced that given this, lots of packages now FTBFS.


    I know, and I expect most of them to not happen any more with dpkg
    1.14.11.

    In any case, I've asked Lucas to do a full rebuild (which he will do on
    Monday) so that we have a more accurate vision of the problem.

    > So, how should we expect buildds to behave after this change? Should all
    > of these FTBFSs be filed on the BTS?


    I suggest we wait until I have the results of Lucas, then I'll look over
    the failures and check if there are more cases that should be ignored.

    (This precise thread has been seeking for more exceptions but nobody ever
    suggested any)

    I found a new possible exception which is do not fail if I don't find a
    NEEDED library which is not versionned (on the assumption that it's a
    private lib and that we won't miss a dependency because of this). This
    means however that in that particular case symbols checking can't be done
    for the binary being analyzed.

    If you have failures with dpkg 1.14.11, feel free to point me at them

    Cheers,
    --
    Rapha雔 Hertzog

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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  19. Re: About dpkg-shlibdeps checks

    On Sat, Nov 24, 2007 at 07:26:41PM +0000, David Moreno Garza wrote:
    > On Fri, 2007-11-23 at 10:39 +0100, Raphael Hertzog wrote:
    > > Hello,
    > >
    > > as announced in
    > > http://lists.debian.org/debian-devel.../msg00004.html the
    > > new dpkg-shlibdeps is stricter in what it accepts and will fail when it
    > > can't find dependency information for a library that is used by an
    > > executable or a public library (a public library is defined as a library
    > > which has a SONAME, see the output of "objdump -p").
    > >
    > > Failures look like this:
    > > dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient).
    > >
    > > It might also look like this:
    > > dpkg-shlibdeps: failure: couldn't find library libhpip.so.0 (note: onlypackages with 'shlibs' files are looked into).

    >
    > After my last attempts to rebuild the archive (using rebuildd) on
    > powerpc, I've faced that given this, lots of packages now FTBFS.


    Not true, that's because lazy maintainers didn't read d-d-a and should
    have fixed it in the generous 48h window that was given to them. You can
    ignore them.


    --
    路O路 Pierre Habouzit
    路路O madcoder@debian.org
    OOO http://www.madism.org

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

    iD8DBQBHST57vGr7W6HudhwRAlY3AJ9OBjP4DbFQX8s5WeiFe3 E7rVN7hACeIs5q
    NePNScSL2IWP5/ZvLttnQSs=
    =wBq4
    -----END PGP SIGNATURE-----


  20. Re: About dpkg-shlibdeps checks

    On Sat, 2007-11-24 at 10:07 +0100, Raphael Hertzog wrote:
    > On Sat, 24 Nov 2007, Soeren Sonnenburg wrote:
    > > But what is the intended way of fixing things with the newer
    > > dpkg-shlibdeps ? Adding --rpath ?

    >
    > Helping dpkg-shlibdeps with LD_LIBRARY_PATH is the right thing as you did
    > below... (option -l for dh_shlibdeps)

    [...]
    > > I am expecting similar problems with R extensions ... where libR.so is
    > > in /usr/lib/R/lib/libR.so and not even has a SONAME ...

    >
    > Wihtout SONAME for a private library is the right thing... no reason to
    > expect more problems. :-)


    Thank you very much for your help.

    Soeren
    --
    For the one fact about the future of which we can be certain is that it
    will be utterly fantastic. -- Arthur C. Clarke, 1962

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

    iD8DBQBHSa8t/h9eL9HisW8RAl5zAJ9nmmQz0dEaMDoiqYG9Ty1AZA/PGACggq1h
    jPpyNPUXXApFx2yC1+63OZA=
    =DTsR
    -----END PGP SIGNATURE-----


+ Reply to Thread
Page 1 of 2 1 2 LastLast