One never gets this message if one uses bsdtar. On Sun, 3 Jun 2018 at 15:24, <tlaro...@polynum.com> wrote:
> Hello, > > On Sun, Jun 03, 2018 at 01:51:52PM +0200, Rhialto wrote: > > On Sun 03 Jun 2018 at 11:33:17 +0200, tlaro...@polynum.com wrote: > > > tar: File extended headers posix ustar archive. Extracting as plain > > > files. Following files might be in the wrong directory or have > wrong > > > attributes. > > > > I started noticing that when I was building some more packages from the > > then-latest stable pkgsrc branch (2018Q1). > > But in my case, the problem is not for something "packaged" by > NetBSD nor pkgsrc, but with the source files. > > If I retrieve from a gnu mirror say the source for gcc7: > > gcc-7.3.0.tar.gz > gcc-7.3.0.tar.xz > > and use xz(1) or gunzip(1) and the system tar(1), I get the problem. > While gtar(1) (installed from pkgsrc and built on 2015-01-17) doesn't > complain. > > My system is: > > NetBSD 7.1.1_PATCH Sun Jan 21 21:28:41 CET 2018 amd64 > > and tar(1) is from the base set retrieved 2018-01-21. > > That's why I think whether the problem is in our tar(1) or in the > gtar(1) used upstream. Obviously, something has changed somewhere, but I > don't think it's in pkgsrc. > > If you have also problem with the packages generated after some date, is > the system tar(1) at fault or is gtar(1) used by pkgsrc for some > packages generating a tarball with extensions not understood by the > system tar(1)? > > Best, > -- > Thierry Laronde <tlaronde +AT+ polynum +dot+ com> > http://www.kergis.com/ > http://www.sbfa.fr/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > -- ----
