Re: [gentoo-portage-dev] portageq not reading profile.bashrc
On 11/4/19 10:50 AM, Joakim Tjernlund wrote:
> On Mon, 2019-11-04 at 18:35 +, Joakim Tjernlund wrote:
>>
>> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
>>
>> cat profile.bashrc
>> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
>> export INSTALL_MASK
>> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
>>
>> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
>> export PKG_INSTALL_MASK
>> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
>>
>> Using portageq envvar INSTALL_MASK I expect to see my settings but
>> INSTALL_MASK is empty.
>>
>> Am I missing something ?
>>
>>Jocke
>
> in profile make.defaults I have
> CONFIG_PROTECT=""
> yet I see:
> portageq envvar CONFIG_PROTECT
> /etc
>
> Is portageq envvar somewhat broken?
>
Well, it's complicated because CONFIG_PROTECT is an "incremental"
variable. You can try to clear it out completely by setting
CONFIG_PROTECT="-*" in profile make.defaults, but that only works if the
CONFIG_PROTECT="/etc" setting came from earlier in the inheritance
hierarchy. You can use this command to see the inheritance order:
python -c 'import portage; print("\n".join(portage.settings.profiles))'
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] portageq not reading profile.bashrc
On 11/4/19 10:35 AM, Joakim Tjernlund wrote:
> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
>
> cat profile.bashrc
> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
> export INSTALL_MASK
> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
>
> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
> export PKG_INSTALL_MASK
> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
>
> Using portageq envvar INSTALL_MASK I expect to see my settings but
> INSTALL_MASK is empty.
>
> Am I missing something ?
>
>Jocke
>
The bashrc files are only executed during ebuild phases. The portageq
envvar command only returns settings from make.defaults and make.conf
files which are parsed by python and never executed by bash.
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] portageq not reading profile.bashrc
On Mon, 2019-11-04 at 18:35 +, Joakim Tjernlund wrote:
>
> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
>
> cat profile.bashrc
> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
> export INSTALL_MASK
> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
>
> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
> export PKG_INSTALL_MASK
> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
>
> Using portageq envvar INSTALL_MASK I expect to see my settings but
> INSTALL_MASK is empty.
>
> Am I missing something ?
>
>Jocke
in profile make.defaults I have
CONFIG_PROTECT=""
yet I see:
portageq envvar CONFIG_PROTECT
/etc
Is portageq envvar somewhat broken?
[gentoo-portage-dev] portageq not reading profile.bashrc
I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
cat profile.bashrc
INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
export INSTALL_MASK
echo "profile INSTALL_MASK: ${INSTALL_MASK}"
PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
export PKG_INSTALL_MASK
echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
Using portageq envvar INSTALL_MASK I expect to see my settings but
INSTALL_MASK is empty.
Am I missing something ?
Jocke
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
On Mon, 2019-11-04 at 04:15 -0600, William Hubbs wrote: > I also don't like your tone in your response to Zac merging the patch. > > https://archives.gentoo.org/gentoo-portage-dev/message/1abfd0499e514b7d6b70b709e9e3ae18 > > If I say out here that since I'm a council member I'm above you and zac > should listen to me and apply the patch is that appropriate? I imagine > not, so I feel the same way about you bringing your qa membership into > the discussion. > In my opinion, all that kind of thing leads to is people becoming angry. > > I'm going to ask you to close https://bugs.gentoo.org/699254. I honestly > do not feel that this is an appropriate way to deal with this situation. > Excuse me but are you serious? So first you choose to claim that something is not policy because you don't see it stamped. Then you demand that QA doesn't vote on stamping it because... why exactly? Because it's 'not an appropriate way', apparently. So what's the appropriate way? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
On Sun, Nov 03, 2019 at 10:37:29PM +0100, Michał Górny wrote: > That is a really poor argument. Something that's respected for 10+ > years and reported as QA violation is a standing policy as far as I'm > concerned. Just because it isn't backed by a formally stamped policy > (at least as far as we know -- maybe it was actually stamped somewhere > in the past?) doesn't mean you it's fine for one person to change it ad- > hoc because it stands in his way. > > I should point that I'm very concerned that you're pushing this forward > even though: > > 1) I've objected to the change itself, You have the right to object, as does anyone, but what I take very strong issue with is your tone and your way of dealing with the situation. An objection with another alternative would have gone a lot better with me. > 2) I've pointed out that it's been sent to the wrong mailing list, > and that this explicitly prevents a number of developers from even > knowing that this is happening, You rudely attacked me and accused me of something I wasn't trying to do. https://archives.gentoo.org/gentoo-portage-dev/message/d5be93dc7767f2256041eb2cb54b8b38 Then floppym responded and advised again that this is the place to send patches for portage. https://archives.gentoo.org/gentoo-portage-dev/message/af686e9d2d94a9b940f8f71efdf73b2b So, that is why this point wasn't really considered. > 3) removing it provides a way for regressions that can have major impact > on users and that involve much effort in reverting that. Maybe the way around this is to stop building static libs for the ebuilds that call gen_usr_ldscript. Once that happens and gen_usr_ldscript isn't called in the tree any more, this patch could be applied. > So if I send a revert patch afterwards, and you object, should the patch > be accepted because only one person objected? This is one of our problems as a distro. there isn't a way to measure concensus. I also don't like your tone in your response to Zac merging the patch. https://archives.gentoo.org/gentoo-portage-dev/message/1abfd0499e514b7d6b70b709e9e3ae18 If I say out here that since I'm a council member I'm above you and zac should listen to me and apply the patch is that appropriate? I imagine not, so I feel the same way about you bringing your qa membership into the discussion. In my opinion, all that kind of thing leads to is people becoming angry. I'm going to ask you to close https://bugs.gentoo.org/699254. I honestly do not feel that this is an appropriate way to deal with this situation. William signature.asc Description: Digital signature
