Created attachment 513480 [details] app-crypt:gpgme-1.10.0:20180105-200824.log When FEATURES=test is ran I see gtk window popping up and asking the password. No matter what I do test fails: FAIL: t-thread1 PASS: t-thread-keylist PASS: t-thread-keylist-verify stopping gpg-agent PASS: final.test ====================================== 9 of 26 tests failed Please report to http://bugs.gnupg.org ====================================== ...
Created attachment 513482 [details] amd64-emerge-info.txt
Can you please try to unset GPG_TTY? Can you please provide the gnupg version? Can you please attach *.log out of the WORKDIR? Need more information to reproduce. Thanks!
(In reply to Alon Bar-Lev from comment #2) > Can you please try to unset GPG_TTY? No change. Still getting pop-ups. I wonder how it finds my X11. > Can you please provide the gnupg version? $ emerge --info gnupg ... app-crypt/gnupg-2.2.0::gentoo was built with the following: USE="bzip2 gnutls ldap nls readline smartcard -doc -selinux -tofu -tools -usb -wks-server" ABI_X86="(64)" > Can you please attach *.log out of the WORKDIR? Looks like there is only config.log (surprisingly no test-suite.log) Is it enough? Attaching.
Created attachment 513484 [details] config.log
Dropping DISPLAY as 'DISPLAY= emerge ...' does not fix test failures but at least stops gtk popups from pinentry on test runs.
Thanks for the info! However, there must be logs of tests somewhere... Can you please try to search the entire /var/tmp/portage/app-crypt/gpgme-1.10.0?
Basically the same as bug #642940 but this time it got a little further than on Toralf's system. *** This bug has been marked as a duplicate of bug 642940 ***
One more thing that I can suspect, can you please try to run with MAKEOPTS="-j1", I had some issues with parallel make in the past and I see you use a decent machine with 8 in parallel.
(In reply to Alon Bar-Lev from comment #8) > One more thing that I can suspect, can you please try to run with > MAKEOPTS="-j1", I had some issues with parallel make in the past and I see > you use a decent machine with 8 in parallel. ok, the other bugs is with -j1 so not relevant.
I think I have a good guess. You use a long path for temp directory: /tmp/portage-tmpdir/portage/app-crypt/gpgme-1.10.0/work/gpgme-1.10.0 While the default is: /var/tmp/portage/app-crypt/gpgme-1.10/work/gpgme-1.10.0 As gpg uses usockets the name is too long. Checked and it is the problem you experience.
@grobian: you are not crypto you are *NOT* allowed to touch packages, you should file a bug. We are not expected to understand that you made a change that breaks people settings! commit da9631f509b21f34f51ac2780589f5d64161f8d6 Author: Fabian Groffen <grobian@gentoo.org> Date: Tue Dec 19 18:49:09 2017 +0100 app-crypt/gpgme: drop obsolete hacks for Darwin, shorten socketpath length Package-Manager: Portage-2.3.13, Repoman-2.3.3
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d79c8d63be6c1ef25de5b5a444e1a9263f27ce7 commit 1d79c8d63be6c1ef25de5b5a444e1a9263f27ce7 Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2018-01-05 23:43:11 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2018-01-05 23:43:29 +0000 app-crypt/gpgme: partial revert unauthorized da9631f50 Bug: https://bugs.gentoo.org/642940 Bug: https://bugs.gentoo.org/643604 app-crypt/gpgme/gpgme-1.10.0.ebuild | 9 --------- 1 file changed, 9 deletions(-)}
Please test again, everything should be fine. My suspected failure can be reproduced with additional 10 bytes to your path.
*** This bug has been marked as a duplicate of bug 642940 ***
With this change all tests pass locally \o/ Thank you!
(In reply to Alon Bar-Lev from comment #11) > @grobian: you are not crypto you are *NOT* allowed to touch packages, you > should file a bug. We are not expected to understand that you made a change > that breaks people settings! Hah. It's broken now for others, so kind of hard judgement.
(In reply to Fabian Groffen from comment #16) > (In reply to Alon Bar-Lev from comment #11) > > @grobian: you are not crypto you are *NOT* allowed to touch packages, you > > should file a bug. We are not expected to understand that you made a change > > that breaks people settings! > > Hah. It's broken now for others, so kind of hard judgement. Unbelievable! Once again... you are not a maintainer of this package you are not allowed to touch it, you can file bugs as any regular user. For prefix we are somewhat flexible as long as you break *ONLY* prefix. Here you broke *ALL* architectures, and failed stabilization process. If will not comply I will report these incidents.
I admit that a revbump would've been nicer, but the archs are all unstable (so no stable breakage whatsoever, let alone stabilisation!) so I trusted on that to be a guard for this hitting the grand crowd, as with any changes. Next, I *tested* this change on stable amd64, and it ran (still does) without any problem. So I did *NOT* break this package for *ALL* architectures.
(In reply to Fabian Groffen from comment #18) > I admit that a revbump would've been nicer, but the archs are all unstable > (so no stable breakage whatsoever, let alone stabilisation!) so I trusted on > that to be a guard for this hitting the grand crowd, as with any changes. > Next, I *tested* this change on stable amd64, and it ran (still does) > without any problem. So I did *NOT* break this package for *ALL* > architectures. You still do not understand... You broke [at least] amd64 and x86 which are the most popular archs, and probably all, as what you have done does not make any sense. It broke my system and as you see from bugs filled other systems. You can test as much as you want and submit a patch into bugzilla. You are *NOT* allowed to touch package that you are not maintain period. Please ACK or I escalate this for you to understand.
I'm sorry I accidentially broke your package. This was not my intention at all, and I'm glad you just reverted the bad commit. Unfortunately you were not aware of the change that went in, which cause you to needlessly search for clues. I hope we can continue on making Gentoo work for everyone.
(In reply to Fabian Groffen from comment #20) > I'm sorry I accidentially broke your package. This was not my intention at > all, and I'm glad you just reverted the bad commit. Unfortunately you were > not aware of the change that went in, which cause you to needlessly search > for clues. > > I hope we can continue on making Gentoo work for everyone. You still not get it... In Gentoo there is a concept of a maintainer per package. If you are not a maintainer of a package you do not modify a package. Simple as that. Obviously, you still do not understand that.
