This is an auto-filled bug because app-crypt/debian-archive-keyring calls ar directly. The issue was originally discovered on amd64, but it may be reproducible on other arches as well. If you think that a different summary clarifies the issue better, feel free to change it. Attached build log and emerge --info. NOTE: If you think it doesn't make sense fix these type of issues, I'd like to point out that won't be possible use a different AR implementation (like llvm-ar) by setting the AR variable. So this issue has been reproduced by setting the AR variable to x86_64-pc-linux-gnu-ar and by removing the /usr/bin/ar binary.
Created attachment 637460 [details] build.log build log and emerge --info
The ebuild does not really compile anything. If direct invocation of "ar" is a problem, this might affect the unpacker eclass more than app-crypt/debian-archive-keyring maybe. Otherwise maybe we need to add a missing build dependency here? What do you think?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9de9d52da4a36f1308a837fd2c4803e893ef9e97 commit 9de9d52da4a36f1308a837fd2c4803e893ef9e97 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-05-10 16:35:02 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-05-10 16:39:44 +0000 unpacker.eclass: respect AR variable in unpack_deb Closes: https://bugs.gentoo.org/722054 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/unpacker.eclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
The planned 'ar' wrapper would print QA warning when called directly. I suggest to use: local AR=${AR-${CHOST}-ar}
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4) > The planned 'ar' wrapper would print QA warning when called directly. Where is this plan you mention?
*** Bug 721910 has been marked as a duplicate of this bug. ***
Currently net-im/signal-desktop-bin which uses the unpacker eclass fails with: >>> Unpacking signal-desktop_1.34.2_amd64.deb to /var/portage/tmp/portage/net-im/signal-desktop-bin-1.34.2/work /var/portage/tmp/portage/net-im/signal-desktop-bin-1.34.2/temp/environment: line 869: ar: command not found * ERROR: net-im/signal-desktop-bin-1.34.2::gentoo failed (unpack phase): When using: local AR=${AR-${CHOST}-ar} like Arfrever suggested the unpacking succeeds!
Okay so this was just me playing with use -native-symlinks [1] and not setting it back properly! However it probably still makes sense considering the suggestion of Arfrever. [1] https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks
I find the idea that we cannot call ar to unpack an archive ridiculous.
Proposed patch: https://archives.gentoo.org/gentoo-dev/message/4bdaa3b26738b7736fa7393b324f60d0
POSIX considers the existence of 'ar' mandatory. Artificially removing this program makes the system set invalid, and I don't think it reasonable to waste people's time on working around deliberately broken systems.
Copying toolchain in case they have some opinion on this.
(In reply to Michał Górny from comment #11) > POSIX considers the existence of 'ar' mandatory. Artificially removing this > program makes the system set invalid, and I don't think it reasonable to > waste people's time on working around deliberately broken systems. Just for me to understand. You consider the native symlinks approach broken? Or do you mean it needs to fixed to not mess wit ar, etc? I was just thinking from the tracker bug that this will eventually become the default.
I certainly don't think this should ever become the default. I also don't think it makes sense to officially support USE="-native-symlinks" without installing ar, cc, etc in PATH some other way.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e424e535ba0ae80880ee13417713757161a925f0 commit e424e535ba0ae80880ee13417713757161a925f0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-06-22 15:07:39 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-06-28 22:01:40 +0000 unpacker.eclass: call BUILD_AR when unpacking deb files Closes: https://bugs.gentoo.org/722054 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/unpacker.eclass | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
