> Date: Mon, 24 Aug 2026 16:23:38 +0200 > From: Thomas Klausner <[email protected]> > > So what's the best way forward? > > pkgsrc sets > ALL_ENV+= LANG=C > by default, and this now breaks unpacking on NetBSD-current for at least > > devel/py-meson_python > textproc/py-sphinx > lang/go124 > devel/qt6-qttools > > I see > > a) do something about tar(1) in -current
This is likely to be a nonstarter unless there is an explicit option instructing tar(1) to take the pax extended header `path' verbatim or something. We shouldn't diverge from upstream libarchive bsdtar semantics unless we have an extremely compelling reason to do so. (The patch I applied was to _reduce_ divergence from what upstream's intent appeared to be, and I submitted it upstream for review in order to make the semantics agree on more platfoms as verified by the tests: <https://github.com/libarchive/libarchive/issues/3413>, <https://github.com/libarchive/libarchive/pull/3416>.) > b) do something about LANG=C in pkgsrc/mk I suggest we set LC_CTYPE to a UTF-8 locale in EXTRACT_ENV for these packages, if not also in ALL_ENV and/or likewise in all packages. Previously discussed on tech-pkg@ in 2022, leading us to set EXTRACT_ENV+= LC_CTYPE=en_US.UTF-8 in all packages on NetBSD<=8: https://mail-index.NetBSD.org/tech-pkg/2022/05/05/msg026252.html https://mail-index.netbsd.org/pkgsrc-changes/2022/05/21/msg254803.html For NetBSD>=10, we can use C.UTF-8 instead of en_US.UTF-8 (though if it's only for LC_CTYPE, using en_US.UTF-8 won't hurt, distressingly angloyankocentric though that may be). > c) extract them using gtar, which doesn't care This is likely not reliable as noted at: https://mail-index.NetBSD.org/tech-userlevel/2026/08/24/msg015063.html
