This is an auto-filled bug because sys-auth/pambase calls cpp directly. The issue was originally discovered on amd64, but it may be reproducible on other arches as well. Attached build log and emerge --info. NOTE: This issue has been reproduced by setting the CPP variable and by removing the /usr/bin/cpp binary.
Created attachment 634362 [details] build.log build log and emerge --info
well, no point to make it not directly.
Please reopen the bug This isn't the right mentality for a developer of a source based distro The point is to build every package with the compiler the user want (example: clang) Also a member of the QA team wontfixing QA issues launches bad signs about the status of the whole distro
For those who follow along the correct fix is to always try toolchain-prefixed tool first: $ diff -U3 pambase-20200304.ebuild pambase-20200304-r1.ebuild | cat --- pambase-20200304.ebuild 2020-03-26 18:01:10.000000000 +0000 +++ pambase-20200304-r1.ebuild 2020-05-25 11:31:22.000000000 +0100 @@ -3,6 +3,8 @@ EAPI=7 +inherit toolchain-funcs + DESCRIPTION="PAM base configuration files" HOMEPAGE="https://github.com/gentoo/pambase" SRC_URI="https://github.com/gentoo/pambase/archive/${P}.tar.gz" @@ -58,6 +60,7 @@ emake \ GIT=true \ + CPP="$(tc-getPROG CPP cpp)" \ $(use_var debug) \ $(use_var LIBCAP caps) \ $(use_var cracklib) \ @@ -79,5 +82,5 @@ src_test() { :; } src_install() { - emake GIT=true DESTDIR="${ED}" install + emake GIT=true CPP="$(tc-getPROG CPP cpp)" DESTDIR="${ED}" install }
Reopening until either a hard verdict by QA stating: - This doesn't matter - This should be fixed Or the bug itself (which seems to have a trivial solution) is fixed.
As long as there is no the outcome I prefer the status quo. Please do not reopen the bugs you are not responsible for. Think you.
After discussion with QA team lead, this bug should stay open.
(In reply to Kent Fredric (IRC: kent\n) from comment #7) > After discussion with QA team lead, this bug should stay open. I have different information at hand.
(In reply to Kent Fredric (IRC: kent\n) from comment #7) > After discussion with QA team lead, this bug should stay open. figured, although pambase is under slow restoration (really slow). This bug is not a priority.
Anything wrong with patch from #comment4?
(In reply to Sergei Trofimovich from comment #10) > Anything wrong with patch from #comment4? Looks fine, even though we really need to fix pambase properly
(In reply to David Seifert from comment #11) > (In reply to Sergei Trofimovich from comment #10) > > Anything wrong with patch from #comment4? > > Looks fine, even though we really need to fix pambase properly Can you elaborate? Is it about restructuring something upstream? What specifically? Or in ebuilds? Looking at required behaviour from 'cpp' it looks like pambase needs an 'unifdef'.
(In reply to Sergei Trofimovich from comment #12) > (In reply to David Seifert from comment #11) > > (In reply to Sergei Trofimovich from comment #10) > > > Anything wrong with patch from #comment4? > > > > Looks fine, even though we really need to fix pambase properly > > Can you elaborate? Is it about restructuring something upstream? What > specifically? Or in ebuilds? > > Looking at required behaviour from 'cpp' it looks like pambase needs an > 'unifdef'. Meant to be "in source" fix as I am the upstream of the pambase for now, naturally.
(In reply to Mikle Kolyada from comment #13) > (In reply to Sergei Trofimovich from comment #12) > > (In reply to David Seifert from comment #11) > > > (In reply to Sergei Trofimovich from comment #10) > > > > Anything wrong with patch from #comment4? > > > > > > Looks fine, even though we really need to fix pambase properly > > > > Can you elaborate? Is it about restructuring something upstream? What > > specifically? Or in ebuilds? > > > > Looking at required behaviour from 'cpp' it looks like pambase needs an > > 'unifdef'. > > Meant to be "in source" fix as I am the upstream of the pambase for now, > naturally. What specifically should be changed upstream?
(In reply to Sergei Trofimovich from comment #14) > What specifically should be changed upstream? I believe the objective is to simply not abuse CPP as a general macro language. ( The rest of the code isn't C-like at all ) If you have a look at what pambase installs.... /etc/pam.d/su /etc/pam.d/system-remote-login /etc/pam.d/other /etc/pam.d/system-login /etc/pam.d/system-services /etc/pam.d/system-local-login /etc/pam.d/passwd /etc/pam.d/system-auth /etc/pam.d/login These are all just text-files compiled by CPP-macros.
(In reply to Kent Fredric (IRC: kent\n) from comment #15) > (In reply to Sergei Trofimovich from comment #14) > > > What specifically should be changed upstream? > > I believe the objective is to simply not abuse CPP as a general macro > language. Would be nice it it was stated here by the maintainer to corroborate. Along with more detailed plan what should be done so someone could implement it and why workaround from #comment4 can't be applied meanwhile. Also let's add +qa@ explicitly to officially answer #comment5 to have a path forward in this bug.
> Would be nice it it was stated here by the maintainer to corroborate. Along > with more detailed plan what should be done so someone could implement it > and why workaround from #comment4 can't be applied meanwhile. > > Also let's add +qa@ explicitly to officially answer #comment5 to have a path > forward in this bug. Already had a conversation about this bug in #gentoo-qa , so I don't think they need further contribution. As long as this is fixed some way eventually ( as in, the proposed mechanism to remove the need to use CPP for macro handling in upstream code, would also solve this bug by way to removing CPP usage entirely ), having this bug open till it goes away is the least I can ask for. Though I do suspect the patching is completely appropriate, the understood "risk" is that by using user-overrideable CPP, they could somehow override CPP in such a way that it installs broken pam-base files, which would possibly break authentication entirely, and that's something that should be avoided.
(In reply to Kent Fredric (IRC: kent\n) from comment #17) > > Would be nice it it was stated here by the maintainer to corroborate. Along > > with more detailed plan what should be done so someone could implement it > > and why workaround from #comment4 can't be applied meanwhile. > > > > Also let's add +qa@ explicitly to officially answer #comment5 to have a path > > forward in this bug. > > Already had a conversation about this bug in #gentoo-qa , so I don't think > they need further contribution. Post the log with the decision here please.
Created attachment 644618 [details] #gentoo-qa.irclog As requested. Not much interesting to see.
Any reason why we can't merge the proposed ebuild change? Looks straight forward. Sure, if maintainer wants to fix pambase itself bug could stay open but why block other Gentoo devs who want to fix their package to work with USE=-native-symlinks and depend on pambase in the meanwhile?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b6864f38b6121ce01254e367dbd44cd3e9838a2 commit 3b6864f38b6121ce01254e367dbd44cd3e9838a2 Author: David Seifert <soap@gentoo.org> AuthorDate: 2020-07-03 09:55:26 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2020-07-03 09:55:26 +0000 sys-auth/pambase: Fix USE="native-symlinks" Closes: https://bugs.gentoo.org/719212 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Suggested-by: Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by: David Seifert <soap@gentoo.org> sys-auth/pambase/pambase-20190402.ebuild | 5 ++++- sys-auth/pambase/pambase-20191128.ebuild | 5 ++++- sys-auth/pambase/pambase-20200304.ebuild | 5 ++++- sys-auth/pambase/pambase-20200618.ebuild | 5 ++++- 4 files changed, 16 insertions(+), 4 deletions(-)
(In reply to Thomas Deutschmann from comment #20) > Any reason why we can't merge the proposed ebuild change? Looks straight > forward. > Sure, if maintainer wants to fix pambase itself bug could stay open but why > block other Gentoo devs who want to fix their package to work with > USE=-native-symlinks and depend on pambase in the meanwhile? Actually because I am not fond of unprofessional ugly fixes (yes, sounds strong, but it is), but if soap takes responsibility for that, I am also ok.
(In reply to Mikle Kolyada from comment #22) > (In reply to Thomas Deutschmann from comment #20) > > Any reason why we can't merge the proposed ebuild change? Looks straight > > forward. > > Sure, if maintainer wants to fix pambase itself bug could stay open but why > > block other Gentoo devs who want to fix their package to work with > > USE=-native-symlinks and depend on pambase in the meanwhile? > > Actually because I am not fond of unprofessional ugly fixes (yes, sounds > strong, but it is) This statement provides zero information on the nature of the problem you have with the "ugly fix". The question was asked at least 3 time how do you want fix to look like (this is the fourth one). I saw no answer.
(In reply to Sergei Trofimovich from comment #23) > (In reply to Mikle Kolyada from comment #22) > > (In reply to Thomas Deutschmann from comment #20) > > > Any reason why we can't merge the proposed ebuild change? Looks straight > > > forward. > > > Sure, if maintainer wants to fix pambase itself bug could stay open but why > > > block other Gentoo devs who want to fix their package to work with > > > USE=-native-symlinks and depend on pambase in the meanwhile? > > > > Actually because I am not fond of unprofessional ugly fixes (yes, sounds > > strong, but it is) > > This statement provides zero information on the nature of the problem you > have with the "ugly fix". The question was asked at least 3 time how do you > want fix to look like (this is the fourth one). I saw no answer. And you have been told at least twice by soap and me.
(In reply to Mikle Kolyada from comment #24) > (In reply to Sergei Trofimovich from comment #23) > > (In reply to Mikle Kolyada from comment #22) > > > (In reply to Thomas Deutschmann from comment #20) > > > > Any reason why we can't merge the proposed ebuild change? Looks straight > > > > forward. > > > > Sure, if maintainer wants to fix pambase itself bug could stay open but why > > > > block other Gentoo devs who want to fix their package to work with > > > > USE=-native-symlinks and depend on pambase in the meanwhile? > > > > > > Actually because I am not fond of unprofessional ugly fixes (yes, sounds > > > strong, but it is) > > > > This statement provides zero information on the nature of the problem you > > have with the "ugly fix". The question was asked at least 3 time how do you > > want fix to look like (this is the fourth one). I saw no answer. > > And you have been told at least twice by soap and me. Then I missed it. Can you post a link?
