Odd dh_strip failure with some packages - Debian

This is a discussion on Odd dh_strip failure with some packages - Debian ; Reviewing the latest lintian findings, there are a surprising number of packages with unstripped binaries, including some that are using debhelper and dh_strip. See: http://lintian.debian.org/reports/Tu...or-object.html Looking at build logs on i386, the common problem for many seems to be variations ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Odd dh_strip failure with some packages

  1. Odd dh_strip failure with some packages

    Reviewing the latest lintian findings, there are a surprising number of
    packages with unstripped binaries, including some that are using debhelper
    and dh_strip. See:

    http://lintian.debian.org/reports/Tu...or-object.html

    Looking at build logs on i386, the common problem for many seems to be
    variations of:

    dh_strip
    strip: unable to copy file 'debian/libwebauth-perl/usr/lib/perl5/auto/WebAuth/WebAuth.so' reason: Permission denied

    I can't duplicate this with a build under cowbuilder with fakeroot, but
    that may not be horribly surprising.

    Spot-checking several packages with this issue, they all seem to have been
    auto-built on ninsei (in some cases, years ago), which makes me think this
    may be a very long-standing problem with that particular buildd. I'm not
    sure who to contact, though (or how to find that out).

    --
    Russ Allbery (rra@debian.org)


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

  2. Re: Odd dh_strip failure with some packages

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

    iD8DBQFGd3o0mO5zOp3h7rERArU8AJ0SrUIDHpbI8C86OmnqNB 0bOCTtbACfQqmy
    VYa4n3A7cKx0Ers2OSRARNo=
    =qGLo
    -----END PGP SIGNATURE-----

  3. Re: Odd dh_strip failure with some packages

    Marc 'HE' Brockschmidt writes:
    > Russ Allbery writes:
    >> Looking at build logs on i386, the common problem for many seems to be
    >> variations of:
    >>
    >> dh_strip
    >> strip: unable to copy file 'debian/libwebauth-perl/usr/lib/perl5/auto/WebAuth/WebAuth.so' reason: Permission denied


    > This is a known problem with XFS (which is used as FS on the i386
    > buildd) [1] - usually switching the order of the dh_fixperms and
    > dh_strip calls helps.


    Er, weird. If this bug isn't going to be fixed soon, should dh_strip work
    around it somehow? Getting everyone to change the order of their
    debhelper calls is going to be hard.

    --
    Russ Allbery (rra@debian.org)


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

  4. Re: Odd dh_strip failure with some packages

    On Tue, Jun 19, 2007 at 08:39:44AM +0200, Marc 'HE' Brockschmidt wrote:

    > This is a known problem with XFS (which is used as FS on the i386
    > buildd) [1] - usually switching the order of the dh_fixperms and
    > dh_strip calls helps.


    > Footnotes:
    > [1] I think it was something about not stripping the file is not +x or
    > something


    Actually, AFAIK it has to do with whether the *read* bit is set. I.e., the
    files are installed as a non-root user, readable only by the owner; then
    root tries to read the file in the binary target, without first changing the
    permissions.

    On Tue, Jun 19, 2007 at 12:02:15AM -0700, Russ Allbery wrote:
    > Er, weird. If this bug isn't going to be fixed soon, should dh_strip work
    > around it somehow? Getting everyone to change the order of their
    > debhelper calls is going to be hard.


    I haven't seen any reason to believe it's a bug in XFS, FWIW. If you know
    that the XFS behavior is a POSIX violation or something, that would be a
    good argument for changing the i386 buildd (though I'm not sure whether the
    i386 buildd that was installed with XFS is still the one in use).

    But even if the buildd were changed, Debian kernels support XFS and d-i
    supports XFS, so we can't prevent maintainers from uploading packages built
    in such an environment.

    How many packages are you seeing with this problem? I'm not keen on the
    idea of having dh_strip try to work around it, but maybe dh_strip could be
    changed to treat such failures as fatal errors at least.

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


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

  5. Re: Odd dh_strip failure with some packages

    Steve Langasek writes:

    > Actually, AFAIK it has to do with whether the *read* bit is set. I.e.,
    > the files are installed as a non-root user, readable only by the owner;
    > then root tries to read the file in the binary target, without first
    > changing the permissions.


    Well, unless the buildd is running with some demented umask, that's not
    happening with webauth. Everything is created with the default umask.

    > How many packages are you seeing with this problem? I'm not keen on the
    > idea of having dh_strip try to work around it, but maybe dh_strip could
    > be changed to treat such failures as fatal errors at least.


    http://lintian.debian.org/reports/Tu...or-object.html

    Nearly all of those appear to be this problem. There are a few where the
    maintainer really isn't stripping files, but that's much rarer. Look for
    any of the packages there that were autobuilt on i386.

    If dh_strip makes this an error, ninsei is going to stop being able to
    build various packages, which will probably help get this fixed, I guess.

    --
    Russ Allbery (rra@debian.org)


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

  6. Re: Odd dh_strip failure with some packages

    On Tue, Jun 19, 2007 at 03:49:27AM -0700, Russ Allbery wrote:
    > Steve Langasek writes:


    > > Actually, AFAIK it has to do with whether the *read* bit is set. I.e.,
    > > the files are installed as a non-root user, readable only by the owner;
    > > then root tries to read the file in the binary target, without first
    > > changing the permissions.


    > Well, unless the buildd is running with some demented umask, that's not
    > happening with webauth. Everything is created with the default umask.


    But "the default umask" may well be 0600, in which case the file perms would
    indeed say that root does not have read access to the files.

    > > How many packages are you seeing with this problem? I'm not keen on the
    > > idea of having dh_strip try to work around it, but maybe dh_strip could
    > > be changed to treat such failures as fatal errors at least.


    > http://lintian.debian.org/reports/Tu...or-object.html


    > Nearly all of those appear to be this problem. There are a few where the
    > maintainer really isn't stripping files, but that's much rarer. Look for
    > any of the packages there that were autobuilt on i386.


    > If dh_strip makes this an error, ninsei is going to stop being able to
    > build various packages, which will probably help get this fixed, I guess.


    I didn't think ninsei was still active, but it appears that it is after all.
    So yes, turning these into build failures seems most reliable to me.

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    vorlon@debian.org http://www.debian.org/


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

  7. Re: Odd dh_strip failure with some packages

    Steve Langasek writes:
    > On Tue, Jun 19, 2007 at 03:49:27AM -0700, Russ Allbery wrote:


    >> Well, unless the buildd is running with some demented umask, that's not
    >> happening with webauth. Everything is created with the default umask.


    > But "the default umask" may well be 0600, in which case the file perms would
    > indeed say that root does not have read access to the files.


    I think a buildd using a 0600 umask counts as somewhat demented, but I
    agree that things should generally cope.

    > I didn't think ninsei was still active, but it appears that it is after
    > all. So yes, turning these into build failures seems most reliable to
    > me.


    Bug filed against debhelper.

    --
    Russ Allbery (rra@debian.org)


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

+ Reply to Thread