GNU tar -Holdgnu w/o fakeroot seems to be break dpkg 1.19.1

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

GNU tar -Holdgnu w/o fakeroot seems to be break dpkg 1.19.1

Guillem Jover
Hi!

I was checking the dpkg 1.19.1 FTBFS on the Hurd, and noticed few
things:

 * GNU tar with -Holdgnu seems broken (?) when packing a fifo, as it
   stores at least the S_IROOT mode bit, which makes GNU tar encode
   the mode data in base-256 (dpkg suppports that just fine, but it's
   still unexpected, and seems incorrect to me). None of the other tar
   formats show this behavior.
 * None of the other dpkg tests fail except for this one.
 * dpkg is now being built w/o fakeroot due to the R³ field set to no.
 * Building the source with fakeroot again makes GNU tar with -Holdgnu
   not store said bit, so it's a possible workaround for a dpkg porter
   build, probably.

So while I could workaround this in the test suite, I think it'd be
better to investigate why GNU tar behaves this way, and possibly fix
it there.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: GNU tar -Holdgnu w/o fakeroot seems to be break dpkg 1.19.1

Guillem Jover
Hi!

On Fri, 2018-09-28 at 09:59:57 +0200, Guillem Jover wrote:

> I was checking the dpkg 1.19.1 FTBFS on the Hurd, and noticed few
> things:
>
>  * GNU tar with -Holdgnu seems broken (?) when packing a fifo, as it
>    stores at least the S_IROOT mode bit, which makes GNU tar encode
>    the mode data in base-256 (dpkg suppports that just fine, but it's
>    still unexpected, and seems incorrect to me). None of the other tar
>    formats show this behavior.
>  * None of the other dpkg tests fail except for this one.
>  * dpkg is now being built w/o fakeroot due to the R³ field set to no.
>  * Building the source with fakeroot again makes GNU tar with -Holdgnu
>    not store said bit, so it's a possible workaround for a dpkg porter
>    build, probably.
>
> So while I could workaround this in the test suite, I think it'd be
> better to investigate why GNU tar behaves this way, and possibly fix
> it there.

So, the patch I sent for the tar package in Debian got applied in the
latest upload. Once that is built on the Hurd, dpkg could be given
back, as it should pass its own test suite then. :)

I also sent the patch upstream, but that has not yet received any
reaction.

Thanks,
Guillem