Re: [gentoo-dev] Trying to use Python3.9 as default for my laptop

2020-10-14 Thread Mike Gilbert
On Wed, Oct 14, 2020 at 5:34 PM Mike Gilbert  wrote:
>
> On Wed, Oct 14, 2020 at 5:01 PM Alexey 'Alexxy' Shvetsov
>  wrote:
> >
> > Hi!
> >
> > Recently i give a try for python 3.9 as default for my work laptop. So i
> > created a list of packages that laks python3_9 flag in pytargets
> >
> > media-gfx/fontforge
>
> Last I checked, the tests fail with newer versions of python. Please
> do not add new python implementations to this (or any) package without
> running the tests first.

Hmm, I guess my head was stuck in 2018, when someone added python3.6
to fontforge without testing it. It looks like python3.9 works fine.



Re: [gentoo-dev] Trying to use Python3.9 as default for my laptop

2020-10-14 Thread Mike Gilbert
On Wed, Oct 14, 2020 at 5:01 PM Alexey 'Alexxy' Shvetsov
 wrote:
>
> Hi!
>
> Recently i give a try for python 3.9 as default for my work laptop. So i
> created a list of packages that laks python3_9 flag in pytargets
>
> media-gfx/fontforge

Last I checked, the tests fail with newer versions of python. Please
do not add new python implementations to this (or any) package without
running the tests first.



Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-13 Thread Mike Gilbert
On Sun, Sep 13, 2020 at 7:21 AM Andrew Savchenko  wrote:
>
> On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
> > Thanks to David Michael for the initial patch and upstream fixes.
> >
> > Signed-off-by: Michał Górny 
> > ---
> >  eclass/acct-group.eclass | 16 +++-
> >  eclass/acct-user.eclass  | 16 +++-
> >  2 files changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 5550e4a2fb10..dc1562974870 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -80,7 +80,7 @@ S=${WORKDIR}
> >
> >
> >  # << Phase functions >>
> > -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> > +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
> >
> >  # @FUNCTION: acct-group_pkg_pretend
> >  # @DESCRIPTION:
> > @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
> >   fi
> >  }
> >
> > +# @FUNCTION: acct-group_src_install
> > +# @DESCRIPTION:
> > +# Installs sysusers.d file for the group.
> > +acct-group_src_install() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + insinto /usr/lib/sysusers.d
> > + newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> > + printf "g\t%q\t%q\n" \
> > + "${ACCT_GROUP_NAME}" \
> > + "${ACCT_GROUP_ID/#-*/-}"
> > + )
> > +}
> > +
> >  # @FUNCTION: acct-group_pkg_preinst
> >  # @DESCRIPTION:
> >  # Creates the group if it does not exist yet.
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> > index e82f3c56dbbe..f9772c3cb111 100644
> > --- a/eclass/acct-user.eclass
> > +++ b/eclass/acct-user.eclass
> > @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
> >  # @FUNCTION: acct-user_src_install
> >  # @DESCRIPTION:
> >  # Installs a keep-file into the user's home directory to ensure it is
> > -# owned by the package.
> > +# owned by the package, and sysusers.d file.
> >  acct-user_src_install() {
> >   debug-print-function ${FUNCNAME} "${@}"
> >
> > @@ -321,6 +321,20 @@ acct-user_src_install() {
> >   # created yet
> >   keepdir "${ACCT_USER_HOME}"
> >   fi
> > +
> > + insinto /usr/lib/sysusers.d
> > + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> > + printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> > + "${ACCT_USER_NAME}" \
> > + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> > + "${DESCRIPTION//[:,=]/;}" \
> > + "${ACCT_USER_HOME}" \
> > + "${ACCT_USER_SHELL/#-*/-}"
> > + if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> > + printf "m\t${ACCT_USER_NAME}\t%q\n" \
> > + "${ACCT_USER_GROUPS[@]:1}"
> > + fi
> > + )
> >  }
>
> Why these files are installed unconditionally?
>
> Of course we have a common "small files" policy that USE flags
> should not control small files in packages, such rule was designed
> for common packages where:
>   1) small files are insignificant disk usage compared to a whole
> package;
>   2) an average package takes significant time to rebuild and mass
> rebuild will cause problems during USE flip.
>
> While both arguments are valid for a common packages which provide
> real software, this is not true for very special acct-* packages:
>   1) They may (and usually do) have zero size of installed files,
> this makes sysusers.d stuff an infinite times larger than a
> whole typical acct-* package (it will still be much larger if one
> will consider size of new passw/group records).
>   2) acct-* packages are very fast to rebuild, so such price will
> be small compared to other changes necessary when USE="systemd" is
> being flipped.
>
> So it will be reasonable to add USE="systemd" to acct-* eclasses
> to control the changes proposed above.

If a USE flag is introduced for this, please use something other than
"systemd". While the only existing implementation is systemd-sysusers,
there is nothing stopping someone from developing a similar tool to
apply the same configuration data.



Re: [gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default

2020-09-10 Thread Mike Gilbert
On Thu, Sep 10, 2020 at 11:45 AM Alec Warner  wrote:
>
> On Thu, Sep 10, 2020 at 1:59 AM Mikle Kolyada  wrote:
>>
>>
>> On 10.09.2020 08:35, Hans de Graaff wrote:
>> > On Wed, 2020-09-09 at 13:35 +0300, Mikle Kolyada wrote:
>> >> Closes: https://bugs.gentoo.org/741380
>> > Could you provide a rationale for removing this? The bug only has a
>> > single anecdotal report of a user who can run a desktop without it. I'm
>> > not sure if that is reason enough to remove this. I guess we won't be
>> > able to figure out easily how many of our desktop profile users are
>> > actually using LDAP, but changing this may cause surprises and I'm not
>> > sure if that's warranted.
>> >
>> > Hans
>>
>>
>> Hi.
>>
>> It is dictated by common sense.
>>
>>
>> I barely can imagine a case where you need ldap support in each and
>> every package you install.
>
>
> I can, but not in a desktop environment. In an enterprise environment you 
> will need it (but I'd expect folks to add it.)
> The challenge is just in changing the default. E.g. we might not do it until 
> a new profile bump (e.g. do it in a 2020 or 2021 profile?)

I think a news item with some time delay would be sufficient to inform
any enterprise admins so they can push a local config change.



Re: [gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default

2020-09-09 Thread Mike Gilbert
Seems like a good idea to me.



[gentoo-dev] [PATCH 2/2] systemd.eclass: deprecate tmpfiles functions

2020-09-06 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/740638
Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 97ecf0786aef..09ea71bbfdc5 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -240,6 +240,8 @@ systemd_install_serviced() {
 # @FUNCTION: systemd_dotmpfilesd
 # @USAGE: ...
 # @DESCRIPTION:
+# Deprecated in favor of tmpfiles.eclass.
+#
 # Install systemd tmpfiles.d files. Uses doins, thus it is fatal
 # in EAPI 4 and non-fatal in earlier EAPIs.
 systemd_dotmpfilesd() {
@@ -260,6 +262,8 @@ systemd_dotmpfilesd() {
 # @FUNCTION: systemd_newtmpfilesd
 # @USAGE:  .conf
 # @DESCRIPTION:
+# Deprecated in favor of tmpfiles.eclass.
+#
 # Install systemd tmpfiles.d file under a new name. Uses newins, thus it
 # is fatal in EAPI 4 and non-fatal in earlier EAPIs.
 systemd_newtmpfilesd() {
@@ -435,6 +439,8 @@ systemd_is_booted() {
 # @FUNCTION: systemd_tmpfiles_create
 # @USAGE:  ...
 # @DESCRIPTION:
+# Deprecated in favor of tmpfiles.eclass.
+#
 # Invokes systemd-tmpfiles --create with given arguments.
 # Does nothing if ROOT != / or systemd-tmpfiles is not in PATH.
 # This function should be called from pkg_postinst.
-- 
2.28.0




[gentoo-dev] [PATCH 1/2] systemd.eclass: fix systemd_tmpfiles_create under EAPI 7

2020-09-06 Thread Mike Gilbert
Closes: https://bugs.gentoo.org/740586
Signed-off-by: Mike Gilbert 
---
 eclass/systemd.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 04f277e94d64..97ecf0786aef 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -448,7 +448,7 @@ systemd_tmpfiles_create() {
 
[[ ${EBUILD_PHASE} == postinst ]] || die "${FUNCNAME}: Only valid in 
pkg_postinst"
[[ ${#} -gt 0 ]] || die "${FUNCNAME}: Must specify at least one 
filename"
-   [[ ${ROOT} == / ]] || return 0
+   [[ ${ROOT:-/} == / ]] || return 0
type systemd-tmpfiles &> /dev/null || return 0
systemd-tmpfiles --create "${@}"
 }
-- 
2.28.0




[gentoo-dev] Re: [PATCH] meson.eclass: fix machine files

2020-08-30 Thread Mike Gilbert
On Sun, Aug 30, 2020 at 4:06 PM William Hubbs  wrote:
>
> Several options we were setting in the [properties] section of the
> machine files have been moved to the [built-in options] section.

What version of meson introduced "built-in options"? I imagine we will
need to keep the properties around until a new enough version of meson
is stable.



Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Mike Gilbert
On Tue, Aug 18, 2020 at 8:05 AM Joonas Niilola  wrote:
>
> Hey,
>
> some of you may already have seen the new packages.gentoo.org page,
>   https://packages.gentoo.org/
>
> and the new maintainer pages in it,
>   https://packages.gentoo.org/maintainers
>
> If you open a maintainer page,
>   https://packages.gentoo.org/maintainer/juip...@gentoo.org
>
> you can see a tab called "pull requests" there,
>   https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests
>
> with description saying:
> "If you also like to help the Gentoo project, you can consider sending a
> Pull Request via GitHub.
> Before doing so, you might want to take a look at the wiki page."
>
> I'm suggesting of adding a new metadata flag to our Wiki's
> User:/Project: page which then prints a message to this page saying
> whether the maintainer (be it project or user), "accepts" or "deals
> with" Github contributions. The wording can be a bit better, but it'd be
> there to **notify** our **contributors** whether their time and effort
> will most likely be wasted making a pull request for this particular
> maintainer.
>
> This note would then be displayed in every package the maintainer is
> assigned to,
>   https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests
>
> I'd imagine a simple switch in Wiki could do it. No need to add anything
> to ::gentoo repo. The switch can be visible in User:/Project: page, but
> it doesn't have to. Unspecified metadata flag would print something like
> "This maintainer hasn't specified whether they handle Github pull
> requests. If you wish to help using Github, please also open a bug prior
> to that and link your pull request commit to that bug (add link to
> glep-66 here)". Or just default it to "No."
>
> Note that the bug text could always be displayed nevertheless, since
> that is still the main channel to communicate with maintainers.
>
> It's undeniable we get a lot of pull requests and unfortunate that many
> are left without any attention to rot.
>   https://github.com/gentoo/gentoo/pulls
>
> I think this would serve both parties - devs and contributors, with
> little to no cost.

Your proposal makes sense to me.



Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Mike Gilbert
On Tue, Aug 18, 2020 at 11:48 AM Michał Górny  wrote:
>
> On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote:
> > Joonas Niilola wrote:
> > > some of you may already have seen the new packages.gentoo.org page,
> > >   https://packages.gentoo.org/
> >
> > I had not seen that - that's wonderful!
> >
> > I would just request that /packages/ is removed from the start of
> > package URLs. I understand how this makes request routing more
> > complicated, but I consider it a significant usability improvement.
> >
> >
> > ..anyway:
> >
> > > I'm suggesting of adding a new metadata flag to our Wiki's
> > > User:/Project: page which then prints a message to this page saying
> > > whether the maintainer (be it project or user), "accepts" or "deals
> > > with" Github contributions. The wording can be a bit better, but it'd be
> > > there to **notify** our **contributors** whether their time and effort
> > > will most likely be wasted making a pull request for this particular
> > > maintainer.
> >
> > I think this is a very good feature.
> >
> > If I ever do become a proper Gentoo developer I will certainly not spend
> > any time on anything to do with GitHub, and in my current position of
> > occasional contributor I don't either. The workflow imposed by GitHub
> > isn't good and it's important to demonstrate other methods.
> >
>
> Read: it's important to slap users to satisfy developer's wannabes.

This sentence makes no sense, but it seems to be saying something rude.

Would you like to clarify?



Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions

2020-08-07 Thread Mike Gilbert
On Fri, Aug 7, 2020 at 2:43 PM Toralf Förster  wrote:
>
> On 8/7/20 8:25 PM, Michael Orlitzky wrote:
> >
> > I have too many other things to do to waste time reverse-engineering
> > these fuck-ups. Get it together.
>
> I'm just curious if you refer to commit d8c442ba8 - b/c that was made by 
> someone at Wed Oct 16 19:41:02 2019 + and I do wonder why nobody else run 
> into that issue since that time?

The problem doesn't surface until x11-apps/mkfontdir was removed in
April 2020. I assume Michael hasn't rebuilt xorg-x11 since before
then.

Also, if you run emege --changed-deps, that works around the issue.



Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Mike Gilbert
On Thu, Aug 6, 2020 at 11:59 AM Thomas Deutschmann  wrote:
>
> On 2020-08-06 17:44, Michał Górny wrote:
> > I'm not sure if you've noticed but there are people actively working
> > towards removing stale news items and trying not to dump everything
> > on once on a user freshly installing the system.  Don't you consider
> > this a worthwhile goal?
>
> I don't see how this is conflicting.
>
> This news item can probably go away after 1-2 years.
>
> But for now, people who were just lucky will probably trigger this when
> upgrading to genkernel-4.1 on their first reboot due to switched device
> manager.
>
> But again: It's not a genkernel issue, so displaying that only for
> people who have genkernel installed would miss a bunch of users.

I would guess that most users do not utilize kexec at all, and this
news item is irrelevant for them.

Personally, I agree that this is not worth spamming every Gentoo user.



Re: [gentoo-dev] systems-246 changes tmpfs default size from 50% to 10% of RAM

2020-07-28 Thread Mike Gilbert
On Tue, Jul 28, 2020 at 3:13 PM Mike Gilbert  wrote:
>
> On Tue, Jul 28, 2020 at 2:50 PM Zoltan Puskas  wrote:
> >
> > Hi,
> >
> > I've upgraded to and running systemd-246_rc2 on one of my systems and
> > noticed that tmpfs mounted directories are significantly smaller.
> >
> > This is because with commit
> > https://github.com/systemd/systemd/commit/7d85383edbab73274dc81cc888d884bb01070bc2
> > they have changed them to be 10% of the physical memory instead of the
> > default of 50%.
> >
> > This is a potentially breaking, or at least an unexpected behaviour
> > change, especially for people using tmpfs on /tmp for compiling.
> >
> > Maybe we should make a news item to let people know that they either
> > need to add an fstab entry with size option set, or better, create a
> > systemd local override with relevant content.
>
> Don't use /tmp for PORTAGE_TMPDIR. /tmp is meant for small temporary
> storage. If you want to compile in a tmpfs, set up a separate mount
> point for it.
>
> I don't intend to create a news item for this, but I would not object
> to someone else doing it.

Also, the limit for /tmp is likely to change again before the 246 final release.

https://github.com/systemd/systemd/pull/16576



Re: [gentoo-dev] systems-246 changes tmpfs default size from 50% to 10% of RAM

2020-07-28 Thread Mike Gilbert
On Tue, Jul 28, 2020 at 2:50 PM Zoltan Puskas  wrote:
>
> Hi,
>
> I've upgraded to and running systemd-246_rc2 on one of my systems and
> noticed that tmpfs mounted directories are significantly smaller.
>
> This is because with commit
> https://github.com/systemd/systemd/commit/7d85383edbab73274dc81cc888d884bb01070bc2
> they have changed them to be 10% of the physical memory instead of the
> default of 50%.
>
> This is a potentially breaking, or at least an unexpected behaviour
> change, especially for people using tmpfs on /tmp for compiling.
>
> Maybe we should make a news item to let people know that they either
> need to add an fstab entry with size option set, or better, create a
> systemd local override with relevant content.

Don't use /tmp for PORTAGE_TMPDIR. /tmp is meant for small temporary
storage. If you want to compile in a tmpfs, set up a separate mount
point for it.

I don't intend to create a news item for this, but I would not object
to someone else doing it.



Re: [gentoo-dev] RFC: Standard build environment variables

2020-06-28 Thread Mike Gilbert
On Sun, Jun 28, 2020 at 8:18 AM Michael Orlitzky  wrote:
>
> As many of you probably know, ago@ has been expanding the scope of our
> CFLAGS/CC support to include some other common build variables:
>
>   * CC
>   * CXX
>   * AR
>   * CPP
>   * NM
>   * RANLIB
>   * AS
>   * LD
>
> Some of those are POSIX standards[0],
>
>   * CC
>   * AR
>
> Others are de-facto GNU make standards[1],
>
>   * CXX
>   * CPP
>   * AS
>
> and a few are de-facto GNU libtool standards[2]:
>
>   * NM
>   * RANLIB
>   * LD
>
> If we expect them all to work properly in Gentoo, we have to agree on
> what they mean, and thus how they should be injected into build systems.
> For example, we had a problem with sci-mathematics/pari, whose upstream
> is using the LD environment variable for something other than what GNU
> libtool uses it for. With LD set to something libtooly in the
> environment, the pari build fails. We can solve that by unsetting LD in
> the ebuild, but for that to be The Right Thing To Do, we should be
> expecting LD to contain something libtooly, and thus something
> inappropriate to be passed to the pari build.
>
> To avoid these issues, I suggest creating a list of "Gentoo environment
> variables" in the devmanual with descriptions of how they should be used
> and pointers to the references (for why we chose that meaning). That way
> a user can export LD, for example, and know that it will be used how he
> thinks it will be used.

Makes sense to me.



[gentoo-dev] [PATCH] unpacker.eclass: call BUILD_AR when unpacking deb files

2020-06-22 Thread Mike Gilbert
Closes: https://bugs.gentoo.org/722054
Signed-off-by: Mike Gilbert 
---
 eclass/unpacker.eclass | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
index 865e2e1a1a58..63aedee4480e 100644
--- a/eclass/unpacker.eclass
+++ b/eclass/unpacker.eclass
@@ -17,6 +17,8 @@
 if [[ -z ${_UNPACKER_ECLASS} ]]; then
 _UNPACKER_ECLASS=1
 
+inherit toolchain-funcs
+
 # @ECLASS-VARIABLE: UNPACKER_BZ2
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -279,8 +281,7 @@ unpack_deb() {
done
} < "${deb}"
else
-   local AR=${AR-ar}
-   ${AR} x "${deb}" || die
+   $(tc-getBUILD_AR) x "${deb}" || die
fi
 
unpacker ./data.tar*
-- 
2.27.0




Re: [gentoo-dev] [PATCH 2/2] kernel-install.eclass: Warn about linux-firmware in pkg_pretend()

2020-06-17 Thread Mike Gilbert
On Wed, Jun 17, 2020 at 7:42 AM Ulrich Mueller  wrote:
>
> > On Wed, 17 Jun 2020, Michał Górny wrote:
>
> > Can we please put users above silly politics?  Gentoo 'does not depend'
> > on any non-free package to print the warning.  If people have hardware
> > that requires non-free firmware, the least we can do is point out where
> > to get this firmware from.
>
> s/If/If and only if/ and I'll be fine with it. :)

Are you proposing that the ebuild inspect the user's hardware and/or
kernel config before printing a warning? That sounds like a terrible
idea to me. Who is going to maintain the problematic hardware list?

I do think it would be nice to give people a way to opt-out of seeing
this warning message every time they install a kernel though.



Re: [gentoo-portage-dev] [PATCH] Use env to find python

2020-06-16 Thread Mike Gilbert
On Tue, Jun 16, 2020 at 1:55 PM Zac Medico  wrote:
>
> On 6/16/20 10:46 AM, Mike Gilbert wrote:
> > On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
> >>
> >> On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
> >>>
> >>> On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> >>>> But we know that it is in /usr/bin, so why add yet another indirection?
> >>>>
> >>>> Attachments:
> >>>> * signature.asc
> >>>
> >>> Ah, sorry -- I forgot to note this here. If you wish to support prefix it 
> >>> is possible it may not be in /usr/bin. Granted I am not sure if the 
> >>> prefix stage3 I was using is old enough to be broken in some way, but 
> >>> adding this would prevent future breakage.
> >>
> >> The portage ebuild and the python distutils module already take care
> >> of updating shebangs at install time.
> >
> > I suppose your patch might be useful if you are trying to run portage
> > from a git checkout on a prefix system.
> >
>
> So, given that the ebuild updates shebangs automatically, should't we
> optimize the default shebangs to be as flexible as possible?

Yes, that makes sense.

However, we should test to make sure that distutils is smart enough to
parse that "/usr/bin/env -S python" string and replace it with
version-specific python shebang.



Re: [gentoo-portage-dev] [PATCH] Use env to find python

2020-06-16 Thread Mike Gilbert
On Tue, Jun 16, 2020 at 1:45 PM Mike Gilbert  wrote:
>
> On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
> >
> > On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> > > But we know that it is in /usr/bin, so why add yet another indirection?
> > >
> > > Attachments:
> > > * signature.asc
> >
> > Ah, sorry -- I forgot to note this here. If you wish to support prefix it 
> > is possible it may not be in /usr/bin. Granted I am not sure if the prefix 
> > stage3 I was using is old enough to be broken in some way, but adding this 
> > would prevent future breakage.
>
> The portage ebuild and the python distutils module already take care
> of updating shebangs at install time.

I suppose your patch might be useful if you are trying to run portage
from a git checkout on a prefix system.



Re: [gentoo-portage-dev] [PATCH] Use env to find python

2020-06-16 Thread Mike Gilbert
On Mon, Jun 15, 2020 at 9:39 AM Sid Spry  wrote:
>
> On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> > But we know that it is in /usr/bin, so why add yet another indirection?
> >
> > Attachments:
> > * signature.asc
>
> Ah, sorry -- I forgot to note this here. If you wish to support prefix it is 
> possible it may not be in /usr/bin. Granted I am not sure if the prefix 
> stage3 I was using is old enough to be broken in some way, but adding this 
> would prevent future breakage.

The portage ebuild and the python distutils module already take care
of updating shebangs at install time.



[gentoo-dev] [PATCH 2/2] multilib.eclass: drop amd64 from maintainers

2020-06-14 Thread Mike Gilbert
Acked-by: Agostino Sarubbo 
Signed-off-by: Mike Gilbert 
---
 eclass/multilib.eclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 29d44768adec..4d1be867f14d 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -3,7 +3,6 @@
 
 # @ECLASS: multilib.eclass
 # @MAINTAINER:
-# am...@gentoo.org
 # toolch...@gentoo.org
 # @BLURB: This eclass is for all functions pertaining to handling multilib 
configurations.
 # @DESCRIPTION:
-- 
2.27.0




[gentoo-dev] [PATCH 1/2] multilib.eclass: use tc-export to simplify multilib_toolchain_setup

2020-06-14 Thread Mike Gilbert
This also gives a tiny performance boost by reducing the number of
subshells that are forked.

Signed-off-by: Mike Gilbert 
---
 eclass/multilib.eclass | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 342d21a2e1c3..29d44768adec 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -506,19 +506,15 @@ multilib_toolchain_setup() {
# Make sure ${save_restore_variables[@]} list matches below.
export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
 
-   export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
+   # Append ABI flags to CHOST-prefixed tools
export CC="$(tc-getCC) $(get_abi_CFLAGS)"
export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
export F77="$(tc-getF77) $(get_abi_CFLAGS)"
export FC="$(tc-getFC) $(get_abi_CFLAGS)"
export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
-   export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
-   export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use 
'${CHOST}-objdump'
-   export PKG_CONFIG="$(tc-getPKG_CONFIG)"
-   export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use 
'${CHOST}-ranlib'
-   export READELF="$(tc-getREADELF)" # Avoid 'readelf', use 
'${CHOST}-readelf'
-   export STRINGS="$(tc-getSTRINGS)" # Avoid 'strings', use 
'${CHOST}-strings'
-   export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use 
'${CHOST}-strip'
+
+   # Use CHOST-prefixed tools
+   tc-export AR NM OBJDUMP PKG_CONFIG RANLIB READELF STRINGS STRIP
 
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
-- 
2.27.0




[gentoo-dev] Re: [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one

2020-06-12 Thread Mike Gilbert
On Fri, Jun 12, 2020 at 5:25 PM Sergei Trofimovich  wrote:
>
> x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> tool on sys-devel/binutils-config[-native-symlinks] system as:
> `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
>
> It's caused by the code that locates the tool as:
> `prog_nm = find_program('nm')`.
>
> The change adds 'nm' tool along with other binutils tools.
>
> CC: William Hubbs 
> CC: Mike Gilbert 
> Closes: https://bugs.gentoo.org/720886
> Signed-off-by: Sergei Trofimovich 
> ---
>  eclass/meson.eclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index e79faa1beea..1590c1f14cf 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> cpp = $(_meson_env_array "$(tc-getCXX)")
> fortran = $(_meson_env_array "$(tc-getFC)")
> llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> +   nm = $(_meson_env_array "$(tc-getNM)")
> objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> pkgconfig = '$(tc-getPKG_CONFIG)'
> @@ -228,6 +229,7 @@ _meson_create_native_file() {
> cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> +   nm = $(_meson_env_array "$(tc-getBUILD_NM)")
> objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
> --
> 2.27.0
>

Looks good.



[gentoo-dev] Re: [PATCH] meson.eclass: override 'nm' tool with tuple-prefixed one

2020-06-12 Thread Mike Gilbert
On Fri, Jun 12, 2020 at 2:37 PM Sergei Trofimovich  wrote:
>
> x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> tool on sys-devel/binutils-config[-native-symlinks] system as:
> `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
>
> It's caused by the code that locates the tool as:
> `prog_nm = find_program('nm')`.
>
> The change adds 'nm' tool along with other binutils tools.
>
> CC: William Hubbs 
> CC: Mike Gilbert 
> Closes: https://bugs.gentoo.org/720886
> Signed-off-by: Sergei Trofimovich 
> ---
>  eclass/meson.eclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index e79faa1beea..20f74a29b83 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> cpp = $(_meson_env_array "$(tc-getCXX)")
> fortran = $(_meson_env_array "$(tc-getFC)")
> llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> +   nm = $(_meson_env_array "$(tc-getNM nm)")
> objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> pkgconfig = '$(tc-getPKG_CONFIG)'
> @@ -228,6 +229,7 @@ _meson_create_native_file() {
> cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> +   nm = $(_meson_env_array "$(tc-getBUILD_NM nm)")
> objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'

You are passing an extraneous "nm" to tc-getNM and tc-getBUILD_NM.



Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-06 Thread Mike Gilbert
On Sat, Jun 6, 2020 at 7:05 PM Andreas K. Hüttel  wrote:
> That said, I think the basic action is in this case pretty unproductive. We
> now have a large number of central libraries maintainer-needed (libpng, jpeg,
> tiff, ...) which would really merit a team...

Seems like one or two devs have been bumping the packages you listed
for the last couple of years, and neither of them are actually members
of the graphics project.

I don't see the value in a project where none of the members actually
maintain their packages.



[gentoo-dev] [PATCH 1/2] multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in multilib_toolchain_setup

2020-06-06 Thread Mike Gilbert
This ensures pkg-config --libs will filter -L/usr/lib from its output for
non-native ABIs.

Signed-off-by: Mike Gilbert 
---
 eclass/multilib.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index ed54568aa2d9..3503ac2ed5b7 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -472,6 +472,7 @@ multilib_toolchain_setup() {
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
+   PKG_CONFIG_SYSTEM_LIBRARY_PATH
)
 
# First restore any saved state we have laying around.
@@ -516,6 +517,7 @@ multilib_toolchain_setup() {
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
+   export 
PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/usr/$(get_libdir)
fi
 }
 
-- 
2.27.0.rc2




[gentoo-dev] [PATCH 0/2] multilib.eclass: improve multilib handling of pkg-config

2020-06-06 Thread Mike Gilbert
These patches are part of a larger change to eliminate MULTILIB_USEDEP
from virtual/pkgconfig dependencies in BDEPEND.

See https://bugs.gentoo.org/723112 and
https://github.com/gentoo/gentoo/pull/16025.

Mike Gilbert (2):
  multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in
multilib_toolchain_setup
  multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup

 eclass/multilib.eclass | 4 
 1 file changed, 4 insertions(+)

-- 
2.27.0.rc2




[gentoo-dev] [PATCH 2/2] multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup

2020-06-06 Thread Mike Gilbert
This ensures that autoconf will not try to use a crossdev wrapper for
non-native ABIs. Instead, we always use the native pkg-config, and
override its behavior via PKG_CONFIG_LIBDIR and
PKG_CONFIG_SYSTEM_LIBRARY_PATH.

Signed-off-by: Mike Gilbert 
---
 eclass/multilib.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 3503ac2ed5b7..54ff1509eada 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -467,6 +467,7 @@ multilib_toolchain_setup() {
LD
NM
OBJDUMP
+   PKG_CONFIG
RANLIB
READELF
STRIP
@@ -511,6 +512,7 @@ multilib_toolchain_setup() {
export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use 
'${CHOST}-objdump'
+   export PKG_CONFIG="$(tc-getPKG_CONFIG)"
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use 
'${CHOST}-ranlib'
export READELF="$(tc-getREADELF)" # Avoid 'readelf', use 
'${CHOST}-readelf'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use 
'${CHOST}-strip'
-- 
2.27.0.rc2




Re: [gentoo-portage-dev] [PATCH] Escape percent-signs in filename when fetching from mirrors

2020-05-31 Thread Mike Gilbert
On Sun, May 31, 2020 at 4:20 PM Zac Medico  wrote:
>
> On 5/30/20 8:26 PM, Mike Gilbert wrote:
> > Bug: https://bugs.gentoo.org/719810
> > Signed-off-by: Mike Gilbert 
> > ---
> >  lib/portage/package/ebuild/fetch.py | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/portage/package/ebuild/fetch.py 
> > b/lib/portage/package/ebuild/fetch.py
> > index 28e7caf53..47c3ad28f 100644
> > --- a/lib/portage/package/ebuild/fetch.py
> > +++ b/lib/portage/package/ebuild/fetch.py
> > @@ -26,6 +26,11 @@ try:
> >  except ImportError:
> >   from urlparse import urlparse
> >
> > +try:
> > + from urllib.parse import quote as urlquote
> > +except ImportError:
> > + from urllib import quote as urlquote
> > +
> >  import portage
> >  portage.proxy.lazyimport.lazyimport(globals(),
> >   'portage.package.ebuild.config:check_config_instance,config',
> > @@ -351,7 +356,7 @@ _size_suffix_map = {
> >
> >  class FlatLayout(object):
> >   def get_path(self, filename):
> > - return filename
> > + return urlquote(filename)
> >
> >   def get_filenames(self, distdir):
> >   for dirpath, dirnames, filenames in os.walk(distdir,
> > @@ -382,7 +387,7 @@ class FilenameHashLayout(object):
> >   c = c // 4
> >   ret += fnhash[:c] + '/'
> >   fnhash = fnhash[c:]
> > - return ret + filename
> > + return ret + urlquote(filename)
> >
> >   def get_filenames(self, distdir):
> >   pattern = ''
> >
>
> Please go ahead an merge, since SRC_URI arrows allow use to neglect
> unquoting as discussed in
> https://archives.gentoo.org/gentoo-portage-dev/message/176d5e6f38b346be760d05f9c6e72e02.

I ended up reverting this; I did not realize emirrordist shared the
same code. A new patch is on its way.



[gentoo-portage-dev] [PATCH] Escape percent-signs in portage.package.ebuild.fetch.get_mirror_url()

2020-05-31 Thread Mike Gilbert
This avoids double-escaping in emirrordist. We only want to escape the
path when fetching the file from the mirror, not when mirroring the
file.

Bug: https://bugs.gentoo.org/719810
Fixes: 4c18f523bb86a8be4c148f365dabee06fca2e4fa
Signed-off-by: Mike Gilbert 
---
 lib/portage/package/ebuild/fetch.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/portage/package/ebuild/fetch.py 
b/lib/portage/package/ebuild/fetch.py
index 28e7caf53..9682fea89 100644
--- a/lib/portage/package/ebuild/fetch.py
+++ b/lib/portage/package/ebuild/fetch.py
@@ -26,6 +26,11 @@ try:
 except ImportError:
from urlparse import urlparse
 
+try:
+   from urllib.parse import quote as urlquote
+except ImportError:
+   from urllib import quote as urlquote
+
 import portage
 portage.proxy.lazyimport.lazyimport(globals(),
'portage.package.ebuild.config:check_config_instance,config',
@@ -520,7 +525,7 @@ def get_mirror_url(mirror_url, filename, mysettings, 
cache_path=None):
f.close()
 
return (mirror_url + "/distfiles/" +
-   
mirror_conf.get_best_supported_layout().get_path(filename))
+   
urlquote(mirror_conf.get_best_supported_layout().get_path(filename)))
 
 
 def fetch(myuris, mysettings, listonly=0, fetchonly=0,
-- 
2.27.0.rc2




Re: [gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI

2020-05-31 Thread Mike Gilbert
On Sun, May 31, 2020 at 2:01 PM Zac Medico  wrote:
>
> On 5/31/20 6:17 AM, Mike Gilbert wrote:
> > Unquote the URL basename when fetching from upstream.
> > Quote the filename when fetching from mirrors.
> >
> > Bug: https://bugs.gentoo.org/719810
> > Signed-off-by: Mike Gilbert 
> > ---
> >  lib/portage/dbapi/porttree.py   | 7 ++-
> >  lib/portage/package/ebuild/fetch.py | 9 +++--
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py
> > index 08af17bcd..984263039 100644
> > --- a/lib/portage/dbapi/porttree.py
> > +++ b/lib/portage/dbapi/porttree.py
> > @@ -55,6 +55,11 @@ try:
> >  except ImportError:
> >   from urlparse import urlparse
> >
> > +try:
> > + from urllib.parse import unquote as urlunquote
> > +except ImportError:
> > + from urllib import unquote as urlunquote
> > +
> >  if sys.hexversion >= 0x300:
> >   # pylint: disable=W0622
> >   basestring = str
> > @@ -1547,7 +1552,7 @@ def _parse_uri_map(cpv, metadata, use=None):
> >   myuris.pop()
> >   distfile = myuris.pop()
> >   else:
> > - distfile = os.path.basename(uri)
> > + distfile = urlunquote(os.path.basename(uri))
> >   if not distfile:
> >   raise portage.exception.InvalidDependString(
> >   ("getFetchMap(): '%s' SRC_URI has no 
> > file " + \
> > diff --git a/lib/portage/package/ebuild/fetch.py 
> > b/lib/portage/package/ebuild/fetch.py
> > index 28e7caf53..47c3ad28f 100644
> > --- a/lib/portage/package/ebuild/fetch.py
> > +++ b/lib/portage/package/ebuild/fetch.py
> > @@ -26,6 +26,11 @@ try:
> >  except ImportError:
> >   from urlparse import urlparse
> >
> > +try:
> > + from urllib.parse import quote as urlquote
> > +except ImportError:
> > + from urllib import quote as urlquote
> > +
> >  import portage
> >  portage.proxy.lazyimport.lazyimport(globals(),
> >   'portage.package.ebuild.config:check_config_instance,config',
> > @@ -351,7 +356,7 @@ _size_suffix_map = {
> >
> >  class FlatLayout(object):
> >   def get_path(self, filename):
> > - return filename
> > + return urlquote(filename)
> >
> >   def get_filenames(self, distdir):
> >   for dirpath, dirnames, filenames in os.walk(distdir,
> > @@ -382,7 +387,7 @@ class FilenameHashLayout(object):
> >   c = c // 4
> >   ret += fnhash[:c] + '/'
> >   fnhash = fnhash[c:]
> > - return ret + filename
> > + return ret + urlquote(filename)
> >
> >   def get_filenames(self, distdir):
> >   pattern = ''
> >
>
> We've also got these other basename calls in fetch.py:
>
> > diff --git a/lib/portage/package/ebuild/fetch.py 
> > b/lib/portage/package/ebuild/fetch.py
> > index 28e7caf53..56b375d58 100644
> > --- a/lib/portage/package/ebuild/fetch.py
> > +++ b/lib/portage/package/ebuild/fetch.py
> > @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0,
> > else:
> > for myuri in myuris:
> > if urlparse(myuri).scheme:
> > -   
> > file_uri_tuples.append((os.path.basename(myuri), myuri))
> > +   
> > file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri))
> > else:
> > -   
> > file_uri_tuples.append((os.path.basename(myuri), None))
> > +   
> > file_uri_tuples.append((urlunquote(os.path.basename(myuri)), None))

I'm not sure how to reach this particular code path. In my testing,
the fetch() function gets passed an OrderedDict in myuris, and the
filenames have already been unquoted, so we don't want to do it again.

Any idea how this "else" block would ever be executed?



Re: [gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI

2020-05-31 Thread Mike Gilbert
On Sun, May 31, 2020 at 4:32 PM Zac Medico  wrote:
>
> On 5/31/20 1:24 PM, Ulrich Mueller wrote:
> >> On Sun, 31 May 2020, Zac Medico wrote:
> >
> >> We've also got these other basename calls in fetch.py:
> >
> >>> diff --git a/lib/portage/package/ebuild/fetch.py 
> >>> b/lib/portage/package/ebuild/fetch.py
> >>> index 28e7caf53..56b375d58 100644
> >>> --- a/lib/portage/package/ebuild/fetch.py
> >>> +++ b/lib/portage/package/ebuild/fetch.py
> >>> @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0,
> >>> else:
> >>> for myuri in myuris:
> >>> if urlparse(myuri).scheme:
> >>> -   
> >>> file_uri_tuples.append((os.path.basename(myuri), myuri))
> >>> +   
> >>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri))
> >>> else:
> >>> -   
> >>> file_uri_tuples.append((os.path.basename(myuri), None))
> >>> +   
> >>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), None))
> >
> >> The case with no scheme is not a URI, so we need to decide whether
> >> or not to unquote, and we should make _parse_uri_map behavior
> >> consistent for this case.
> >
> > I think that this follows from PMS, section 8.2 [1]:
> >
> > | The following elements are recognised in at least one class of
> > | specification. All elements must be surrounded on both sides by
> > | whitespace, except at the start and end of the string.
> > |
> > | [...]
> > | - A URI, in the form proto://host/path. Permitted in SRC_URI and
> > | HOMEPAGE. In EAPIs listed in table 8.4 as supporting SRC_URI arrows,
> > | may optionally be followed by whitespace, then ->, then whitespace,
> > | then a simple filename when in SRC_URI. For SRC_URI behaviour, see
> > | section 8.2.10.
> > | - A flat filename. Permitted in SRC_URI.
> >
> > So if it isn't an URI then it is a "flat filename" which IMHO is to be
> > interpreted literally without any unquoting.
> >
> > Ulrich
> >
> > [1] https://projects.gentoo.org/pms/7/pms.html#x1-690008.2
> >
>
> This interpretation sounds good to me.

Agreed.



Re: [gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI

2020-05-31 Thread Mike Gilbert
On Sun, May 31, 2020 at 3:36 PM Zac Medico  wrote:
>
> On 5/31/20 12:21 PM, Mike Gilbert wrote:
> > On Sun, May 31, 2020 at 2:01 PM Zac Medico  wrote:
> >>
> >> On 5/31/20 6:17 AM, Mike Gilbert wrote:
> >>> Unquote the URL basename when fetching from upstream.
> >>> Quote the filename when fetching from mirrors.
> >>>
> >>> Bug: https://bugs.gentoo.org/719810
> >>> Signed-off-by: Mike Gilbert 
> >>> ---
> >>>  lib/portage/dbapi/porttree.py   | 7 ++-
> >>>  lib/portage/package/ebuild/fetch.py | 9 +++--
> >>>  2 files changed, 13 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py
> >>> index 08af17bcd..984263039 100644
> >>> --- a/lib/portage/dbapi/porttree.py
> >>> +++ b/lib/portage/dbapi/porttree.py
> >>> @@ -55,6 +55,11 @@ try:
> >>>  except ImportError:
> >>>   from urlparse import urlparse
> >>>
> >>> +try:
> >>> + from urllib.parse import unquote as urlunquote
> >>> +except ImportError:
> >>> + from urllib import unquote as urlunquote
> >>> +
> >>>  if sys.hexversion >= 0x300:
> >>>   # pylint: disable=W0622
> >>>   basestring = str
> >>> @@ -1547,7 +1552,7 @@ def _parse_uri_map(cpv, metadata, use=None):
> >>>   myuris.pop()
> >>>   distfile = myuris.pop()
> >>>   else:
> >>> - distfile = os.path.basename(uri)
> >>> + distfile = urlunquote(os.path.basename(uri))
> >>>   if not distfile:
> >>>   raise portage.exception.InvalidDependString(
> >>>   ("getFetchMap(): '%s' SRC_URI has 
> >>> no file " + \
> >>> diff --git a/lib/portage/package/ebuild/fetch.py 
> >>> b/lib/portage/package/ebuild/fetch.py
> >>> index 28e7caf53..47c3ad28f 100644
> >>> --- a/lib/portage/package/ebuild/fetch.py
> >>> +++ b/lib/portage/package/ebuild/fetch.py
> >>> @@ -26,6 +26,11 @@ try:
> >>>  except ImportError:
> >>>   from urlparse import urlparse
> >>>
> >>> +try:
> >>> + from urllib.parse import quote as urlquote
> >>> +except ImportError:
> >>> + from urllib import quote as urlquote
> >>> +
> >>>  import portage
> >>>  portage.proxy.lazyimport.lazyimport(globals(),
> >>>   'portage.package.ebuild.config:check_config_instance,config',
> >>> @@ -351,7 +356,7 @@ _size_suffix_map = {
> >>>
> >>>  class FlatLayout(object):
> >>>   def get_path(self, filename):
> >>> - return filename
> >>> + return urlquote(filename)
> >>>
> >>>   def get_filenames(self, distdir):
> >>>   for dirpath, dirnames, filenames in os.walk(distdir,
> >>> @@ -382,7 +387,7 @@ class FilenameHashLayout(object):
> >>>   c = c // 4
> >>>   ret += fnhash[:c] + '/'
> >>>   fnhash = fnhash[c:]
> >>> - return ret + filename
> >>> + return ret + urlquote(filename)
> >>>
> >>>   def get_filenames(self, distdir):
> >>>   pattern = ''
> >>>
> >>
> >> We've also got these other basename calls in fetch.py:
> >>
> >>> diff --git a/lib/portage/package/ebuild/fetch.py 
> >>> b/lib/portage/package/ebuild/fetch.py
> >>> index 28e7caf53..56b375d58 100644
> >>> --- a/lib/portage/package/ebuild/fetch.py
> >>> +++ b/lib/portage/package/ebuild/fetch.py
> >>> @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0,
> >>> else:
> >>> for myuri in myuris:
> >>> if urlparse(myuri).scheme:
> >>> -   
> >>> file_uri_tuples.append((os.path.basename(myuri), myuri))
> >>> +   
> >>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri))
> >>> else:
> >>> -   
> &g

Re: [gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI

2020-05-31 Thread Mike Gilbert
On Sun, May 31, 2020 at 2:01 PM Zac Medico  wrote:
>
> On 5/31/20 6:17 AM, Mike Gilbert wrote:
> > Unquote the URL basename when fetching from upstream.
> > Quote the filename when fetching from mirrors.
> >
> > Bug: https://bugs.gentoo.org/719810
> > Signed-off-by: Mike Gilbert 
> > ---
> >  lib/portage/dbapi/porttree.py   | 7 ++-
> >  lib/portage/package/ebuild/fetch.py | 9 +++--
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py
> > index 08af17bcd..984263039 100644
> > --- a/lib/portage/dbapi/porttree.py
> > +++ b/lib/portage/dbapi/porttree.py
> > @@ -55,6 +55,11 @@ try:
> >  except ImportError:
> >   from urlparse import urlparse
> >
> > +try:
> > + from urllib.parse import unquote as urlunquote
> > +except ImportError:
> > + from urllib import unquote as urlunquote
> > +
> >  if sys.hexversion >= 0x300:
> >   # pylint: disable=W0622
> >   basestring = str
> > @@ -1547,7 +1552,7 @@ def _parse_uri_map(cpv, metadata, use=None):
> >   myuris.pop()
> >   distfile = myuris.pop()
> >   else:
> > - distfile = os.path.basename(uri)
> > + distfile = urlunquote(os.path.basename(uri))
> >   if not distfile:
> >   raise portage.exception.InvalidDependString(
> >   ("getFetchMap(): '%s' SRC_URI has no 
> > file " + \
> > diff --git a/lib/portage/package/ebuild/fetch.py 
> > b/lib/portage/package/ebuild/fetch.py
> > index 28e7caf53..47c3ad28f 100644
> > --- a/lib/portage/package/ebuild/fetch.py
> > +++ b/lib/portage/package/ebuild/fetch.py
> > @@ -26,6 +26,11 @@ try:
> >  except ImportError:
> >   from urlparse import urlparse
> >
> > +try:
> > + from urllib.parse import quote as urlquote
> > +except ImportError:
> > + from urllib import quote as urlquote
> > +
> >  import portage
> >  portage.proxy.lazyimport.lazyimport(globals(),
> >   'portage.package.ebuild.config:check_config_instance,config',
> > @@ -351,7 +356,7 @@ _size_suffix_map = {
> >
> >  class FlatLayout(object):
> >   def get_path(self, filename):
> > - return filename
> > + return urlquote(filename)
> >
> >   def get_filenames(self, distdir):
> >   for dirpath, dirnames, filenames in os.walk(distdir,
> > @@ -382,7 +387,7 @@ class FilenameHashLayout(object):
> >   c = c // 4
> >   ret += fnhash[:c] + '/'
> >   fnhash = fnhash[c:]
> > - return ret + filename
> > + return ret + urlquote(filename)
> >
> >   def get_filenames(self, distdir):
> >   pattern = ''
> >
>
> We've also got these other basename calls in fetch.py:
>
> > diff --git a/lib/portage/package/ebuild/fetch.py 
> > b/lib/portage/package/ebuild/fetch.py
> > index 28e7caf53..56b375d58 100644
> > --- a/lib/portage/package/ebuild/fetch.py
> > +++ b/lib/portage/package/ebuild/fetch.py
> > @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0,
> > else:
> > for myuri in myuris:
> > if urlparse(myuri).scheme:
> > -   
> > file_uri_tuples.append((os.path.basename(myuri), myuri))
> > +   
> > file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri))
> > else:
> > -   
> > file_uri_tuples.append((os.path.basename(myuri), None))
> > +   
> > file_uri_tuples.append((urlunquote(os.path.basename(myuri)), None))
>
> The case with no scheme is not a URI, so we need to decide whether
> or not to unquote, and we should make _parse_uri_map behavior
> consistent for this case.

Backing up, I think unquoting the basename is really a separate issue
from quoting the filename in Layout.get_path(). The latter fixes a
known bug when fetching from mirrors, whereas the former seems like a
cosmetic issue. I don't think we should mix these two up into the same
commit.

Could I get your approval to push my original patch (Escape
percent-signs in filename when fetching from mirrors)?



[gentoo-portage-dev] Re: [PATCH] Improve handling of percent-signs in SRC_URI

2020-05-31 Thread Mike Gilbert
On Sun, May 31, 2020 at 9:17 AM Mike Gilbert  wrote:
>
> Unquote the URL basename when fetching from upstream.

I ran "repoman manifest" for the entire Gentoo repo, and this affected
one package that had a space encoded as "%20" in SRC_URI.

Fixed with this commit:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f5467ab16175fe9095f0b5a0a1c8e56e4250



[gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI

2020-05-31 Thread Mike Gilbert
Unquote the URL basename when fetching from upstream.
Quote the filename when fetching from mirrors.

Bug: https://bugs.gentoo.org/719810
Signed-off-by: Mike Gilbert 
---
 lib/portage/dbapi/porttree.py   | 7 ++-
 lib/portage/package/ebuild/fetch.py | 9 +++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py
index 08af17bcd..984263039 100644
--- a/lib/portage/dbapi/porttree.py
+++ b/lib/portage/dbapi/porttree.py
@@ -55,6 +55,11 @@ try:
 except ImportError:
from urlparse import urlparse
 
+try:
+   from urllib.parse import unquote as urlunquote
+except ImportError:
+   from urllib import unquote as urlunquote
+
 if sys.hexversion >= 0x300:
# pylint: disable=W0622
basestring = str
@@ -1547,7 +1552,7 @@ def _parse_uri_map(cpv, metadata, use=None):
myuris.pop()
distfile = myuris.pop()
else:
-   distfile = os.path.basename(uri)
+   distfile = urlunquote(os.path.basename(uri))
if not distfile:
raise portage.exception.InvalidDependString(
("getFetchMap(): '%s' SRC_URI has no 
file " + \
diff --git a/lib/portage/package/ebuild/fetch.py 
b/lib/portage/package/ebuild/fetch.py
index 28e7caf53..47c3ad28f 100644
--- a/lib/portage/package/ebuild/fetch.py
+++ b/lib/portage/package/ebuild/fetch.py
@@ -26,6 +26,11 @@ try:
 except ImportError:
from urlparse import urlparse
 
+try:
+   from urllib.parse import quote as urlquote
+except ImportError:
+   from urllib import quote as urlquote
+
 import portage
 portage.proxy.lazyimport.lazyimport(globals(),
'portage.package.ebuild.config:check_config_instance,config',
@@ -351,7 +356,7 @@ _size_suffix_map = {
 
 class FlatLayout(object):
def get_path(self, filename):
-   return filename
+   return urlquote(filename)
 
def get_filenames(self, distdir):
for dirpath, dirnames, filenames in os.walk(distdir,
@@ -382,7 +387,7 @@ class FilenameHashLayout(object):
c = c // 4
ret += fnhash[:c] + '/'
fnhash = fnhash[c:]
-   return ret + filename
+   return ret + urlquote(filename)
 
def get_filenames(self, distdir):
pattern = ''
-- 
2.27.0.rc2




[gentoo-portage-dev] [PATCH] Escape percent-signs in filename when fetching from mirrors

2020-05-30 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/719810
Signed-off-by: Mike Gilbert 
---
 lib/portage/package/ebuild/fetch.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/portage/package/ebuild/fetch.py 
b/lib/portage/package/ebuild/fetch.py
index 28e7caf53..47c3ad28f 100644
--- a/lib/portage/package/ebuild/fetch.py
+++ b/lib/portage/package/ebuild/fetch.py
@@ -26,6 +26,11 @@ try:
 except ImportError:
from urlparse import urlparse
 
+try:
+   from urllib.parse import quote as urlquote
+except ImportError:
+   from urllib import quote as urlquote
+
 import portage
 portage.proxy.lazyimport.lazyimport(globals(),
'portage.package.ebuild.config:check_config_instance,config',
@@ -351,7 +356,7 @@ _size_suffix_map = {
 
 class FlatLayout(object):
def get_path(self, filename):
-   return filename
+   return urlquote(filename)
 
def get_filenames(self, distdir):
for dirpath, dirnames, filenames in os.walk(distdir,
@@ -382,7 +387,7 @@ class FilenameHashLayout(object):
c = c // 4
ret += fnhash[:c] + '/'
fnhash = fnhash[c:]
-   return ret + filename
+   return ret + urlquote(filename)
 
def get_filenames(self, distdir):
pattern = ''
-- 
2.27.0.rc2




Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-26 Thread Mike Gilbert
On Tue, May 26, 2020 at 2:13 PM Mike Gilbert  wrote:
>
> On Tue, May 26, 2020 at 2:03 PM Alexis Ballier  wrote:
> >
> > On Tue, 26 May 2020 10:45:39 -0400
> > Mike Gilbert  wrote:
> > > > Note that having the 'pic' useflag should be considered something
> > > > to be fixed: rewrite the asm in a PIC way. But these days nobody
> > > > has the will to do it since this is mostly an issue on x86+pax,
> > > > both being slowly decreasing.
> > >
> > > Given that PaX has been stripped out of official Gentoo kernels due to
> > > the grsecurity licensing issue, I wonder if there is any other good
> > > reason to keep the "pic" USE flag today. Surely this affects a very
> > > small population of users.
> >
> >
> > I couldn't find any recent reference, but PIC shared libs used to be a
> > QA policy. There's mainly two reasons to it: First is W^X enforcement;
> > non PIC shared libs are refused by the x86_64 linker so a non-issue
> > there, on x86 you need pax to emulate it because the mmu doesn't support
> > the X part; I don't know about other arches.
> > Then there is the small memory waste done because those libs will be
> > loaded COW and thus their "code" is not shared anymore between
> > processes. And the small startup performance hit to
> > perform the relocations.
> >
> > The latter part affects everyone, and the rule of thumb for having a
> > pic useflag (instead of always pic) is that the gain for non-pic asm is
> > better than the loss of non-pic shared libs. This is subjective but
> > usually a no-brainer for multimedia packages.
>
> Assuming that the pic performance penalty is really only relevant on
> legacy arches (like x86), here are a couple of options:
>
> 1. Disable pic on arches where tie performance penalty is small.
> 2. Force pic everywhere, performance be damned.

Option 1 should say "Disable pic on arches where the performance
penalty is large."



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-26 Thread Mike Gilbert
On Tue, May 26, 2020 at 2:03 PM Alexis Ballier  wrote:
>
> On Tue, 26 May 2020 10:45:39 -0400
> Mike Gilbert  wrote:
> > > Note that having the 'pic' useflag should be considered something
> > > to be fixed: rewrite the asm in a PIC way. But these days nobody
> > > has the will to do it since this is mostly an issue on x86+pax,
> > > both being slowly decreasing.
> >
> > Given that PaX has been stripped out of official Gentoo kernels due to
> > the grsecurity licensing issue, I wonder if there is any other good
> > reason to keep the "pic" USE flag today. Surely this affects a very
> > small population of users.
>
>
> I couldn't find any recent reference, but PIC shared libs used to be a
> QA policy. There's mainly two reasons to it: First is W^X enforcement;
> non PIC shared libs are refused by the x86_64 linker so a non-issue
> there, on x86 you need pax to emulate it because the mmu doesn't support
> the X part; I don't know about other arches.
> Then there is the small memory waste done because those libs will be
> loaded COW and thus their "code" is not shared anymore between
> processes. And the small startup performance hit to
> perform the relocations.
>
> The latter part affects everyone, and the rule of thumb for having a
> pic useflag (instead of always pic) is that the gain for non-pic asm is
> better than the loss of non-pic shared libs. This is subjective but
> usually a no-brainer for multimedia packages.

Assuming that the pic performance penalty is really only relevant on
legacy arches (like x86), here are a couple of options:

1. Disable pic on arches where tie performance penalty is small.
2. Force pic everywhere, performance be damned.



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-26 Thread Mike Gilbert
On Tue, May 26, 2020 at 5:30 AM Alexis Ballier  wrote:
> On Mon, 2020-05-25 at 21:09 -0400, Mike Gilbert wrote:
> > If I understand you correctly, we should just drop the USE="pic"
> > logic
> > from the remaining packages that have it? Or are you trying to say
> > something else?
>
>
> Drop USE=asm unless there's a real reason to it: Such a useflag is,
> IMHO, at the same level of a useflag on dev-lang/python that would
> toggle dict's underlying implementations but not the semantics of the
> language.
> Have USE=pic for its historical meaning, aka, sacrificing everything to
> have PIC shared libs because your system enforces this (pax).

Thanks, this last sentence gives me a better understanding of why this
"pic" USE flag exists at all.

> Note that having the 'pic' useflag should be considered something to be
> fixed: rewrite the asm in a PIC way. But these days nobody has the will
> to do it since this is mostly an issue on x86+pax, both being slowly
> decreasing.

Given that PaX has been stripped out of official Gentoo kernels due to
the grsecurity licensing issue, I wonder if there is any other good
reason to keep the "pic" USE flag today. Surely this affects a very
small population of users.



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 7:35 PM Alexis Ballier  wrote:
>
> On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote:
> > On Mon, May 25, 2020 at 3:18 PM Michał Górny 
> > wrote:
> > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote:
> > > > On Mon, 25 May 2020 11:26:26 -0400
> > > > Mike Gilbert  wrote:
> > > >
> > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier <
> > > > > aball...@gentoo.org>
> > > > > wrote:
> > > > > > On Sun, 24 May 2020 20:25:11 + (UTC)
> > > > > > "Thomas Deutschmann"  wrote:
> > > > > >
> > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > > > > > Author: Thomas Deutschmann  gentoo 
> > > > > > > org>
> > > > > > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > > > > > Commit: Thomas Deutschmann  gentoo 
> > > > > > > org>
> > > > > > > CommitDate: Sun May 24 20:23:53 2020 +
> > > > > > > URL:
> > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > > > > > >
> > > > > > > media-libs/x265: drop USE=pic
> > > > > > >
> > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was
> > > > > > > added,
> > > > > > > we no longer need a USE flag to control that behavior.
> > > > > >
> > > > > > You got it wrong here it seems: USE=pic does not control
> > > > > > whether
> > > > > > the toolchain produces PIC or not. Shared libs always are,
> > > > > > and have
> > > > > > always been, built that way on Gentoo.
> > > > > > In this case, USE=pic means "no matter what it costs, I do
> > > > > > not want
> > > > > > textrels", for the cases of hand written assembly that has to
> > > > > > be
> > > > > > rewritten to support PIC. And, still in this case, this costs
> > > > > > a lot
> > > > > > of performance, so it is enabled by default on hardened
> > > > > > profiles
> > > > > > and not others.
> > > > > > Textrels work fine (on some architectures), they disallow W^X
> > > > > > and
> > > > > > force each process using the shared lib to make a "copy" at
> > > > > > runtime
> > > > > > in order to resolve relocations, so are not desirable but
> > > > > > sometimes
> > > > > > the cost outweights the gain.
> > > > > >
> > > > > > Plus, profiles/features/hardened enables pic by default but
> > > > > > knows
> > > > > > nothing about USE=asm so this is a regression for them.
> > > > >
> > > > > The USE flag toggles use of assembly, not use of PIC. The
> > > > > default USE
> > > > > value in the hardened profile should not drive decisions on
> > > > > what we
> > > > > name USE flags.
> > > >
> > > > ... but using a global well documented useflag instead of a local
> > > > invention should drive such decisions.
> > >
> > > What 'global well documented useflag'?
> >
> > It's neither global, nor well-documented, but several packages do
> > define it locally.
> >
>
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680
>
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba
>
> I guess this hasn't been really discussed back then.
>
> It is also used in a global way in profiles (make.defaults).
>
> > Personally, I think it should be renamed to "asm" or something
> > similar
> > in the majority of cases where it actually disables all use of
> > assembly code.
>
> Thankfully these days there's usually no need to disable asm to have
> pic. hardened has no mention of that flag, and I think that e.g. for
> openssl they would have noticed long ago.
> And again, 'asm' as a useflag makes no sense: if it works and simply
> replaces a C function by a faster one then it shouldn't even be an
> useflag. 'pic' on the other hand conveys the tradeoff idea.

If I understand you correctly, we should just drop the USE="pic" logic
from the remaining packages that have it? Or are you trying to say
something else?



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 3:18 PM Michał Górny  wrote:
>
> On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote:
> > On Mon, 25 May 2020 11:26:26 -0400
> > Mike Gilbert  wrote:
> >
> > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier 
> > > wrote:
> > > > On Sun, 24 May 2020 20:25:11 + (UTC)
> > > > "Thomas Deutschmann"  wrote:
> > > >
> > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > > > > Author: Thomas Deutschmann  gentoo  org>
> > > > > AuthorDate: Sun May 24 19:47:08 2020 +
> > > > > Commit: Thomas Deutschmann  gentoo  org>
> > > > > CommitDate: Sun May 24 20:23:53 2020 +
> > > > > URL:
> > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> > > > >
> > > > > media-libs/x265: drop USE=pic
> > > > >
> > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> > > > > we no longer need a USE flag to control that behavior.
> > > >
> > > > You got it wrong here it seems: USE=pic does not control whether
> > > > the toolchain produces PIC or not. Shared libs always are, and have
> > > > always been, built that way on Gentoo.
> > > > In this case, USE=pic means "no matter what it costs, I do not want
> > > > textrels", for the cases of hand written assembly that has to be
> > > > rewritten to support PIC. And, still in this case, this costs a lot
> > > > of performance, so it is enabled by default on hardened profiles
> > > > and not others.
> > > > Textrels work fine (on some architectures), they disallow W^X and
> > > > force each process using the shared lib to make a "copy" at runtime
> > > > in order to resolve relocations, so are not desirable but sometimes
> > > > the cost outweights the gain.
> > > >
> > > > Plus, profiles/features/hardened enables pic by default but knows
> > > > nothing about USE=asm so this is a regression for them.
> > >
> > > The USE flag toggles use of assembly, not use of PIC. The default USE
> > > value in the hardened profile should not drive decisions on what we
> > > name USE flags.
> >
> > ... but using a global well documented useflag instead of a local
> > invention should drive such decisions.
>
> What 'global well documented useflag'?

It's neither global, nor well-documented, but several packages do
define it locally.

profiles % grep ":pic " use.local.desc
app-arch/gzip:pic - disable optimized assembly code that is not PIC friendly
app-benchmarks/ramspeed:pic - Force shared libraries to be built as
PIC (this is slower)
dev-libs/gmp:pic - Force static libraries to be built as PIC to avoid TEXTRELs.
gnome-base/orbit:pic - Force libname-server-2 to be built as PIC;
needed on hardened systems
media-libs/x264:pic - disable optimized assembly code that is not PIC friendly
media-libs/x265:pic - Disable optimized assembly code that is not PIC friendly
media-libs/xvid:pic - disable optimized assembly code that is not PIC friendly
media-video/ffmpeg:pic - Force shared libraries to be built as PIC
(this is slower)
media-video/transcode:pic - disable optimized assembly code that is
not PIC friendly
www-client/chromium:pic - Disable optimized assembly code that is not
PIC friendly

I suspect this flag got copy/pasted between various packages related
to ffmpeg. That's certainly how chromium ended up with it.

Personally, I think it should be renamed to "asm" or something similar
in the majority of cases where it actually disables all use of
assembly code.



Re: [gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 9:06 AM Sergei Trofimovich  wrote:
>
> Bug: https://bugs.gentoo.org/725304
> Signed-off-by: Sergei Trofimovich 

Both patches look good to me.

However, I think you should remove the bug number from the summary
line; it makes the summary too long and the Bug tag later in the
commit message is sufficient.



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-25 Thread Mike Gilbert
On Mon, May 25, 2020 at 9:13 AM Alexis Ballier  wrote:
>
> On Sun, 24 May 2020 20:25:11 + (UTC)
> "Thomas Deutschmann"  wrote:
>
> > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3
> > Author: Thomas Deutschmann  gentoo  org>
> > AuthorDate: Sun May 24 19:47:08 2020 +
> > Commit: Thomas Deutschmann  gentoo  org>
> > CommitDate: Sun May 24 20:23:53 2020 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596
> >
> > media-libs/x265: drop USE=pic
> >
> > Gentoo's toolchain uses PIC by default. Since USE=asm was added,
> > we no longer need a USE flag to control that behavior.
>
>
> You got it wrong here it seems: USE=pic does not control whether
> the toolchain produces PIC or not. Shared libs always are, and have
> always been, built that way on Gentoo.
> In this case, USE=pic means "no matter what it costs, I do not want
> textrels", for the cases of hand written assembly that has to be
> rewritten to support PIC. And, still in this case, this costs a lot of
> performance, so it is enabled by default on hardened profiles and not
> others.
> Textrels work fine (on some architectures), they disallow W^X and force
> each process using the shared lib to make a "copy" at runtime in order
> to resolve relocations, so are not desirable but sometimes the cost
> outweights the gain.
>
> Plus, profiles/features/hardened enables pic by default but knows
> nothing about USE=asm so this is a regression for them.

The USE flag toggles use of assembly, not use of PIC. The default USE
value in the hardened profile should not drive decisions on what we
name USE flags.

You can add the flag to package.use or package.use.mask in the
hardened profile if necessary.



Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-23 Thread Mike Gilbert
On Fri, May 22, 2020 at 5:36 PM Sergei Trofimovich  wrote:
>
> 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> packages that don't respect users' CC/AR/LD flags.
>
> I added new USE=-native-symlinks mode for gcc-config and
> binutils-config to ease detection of such packages.
>
> Native symlinks are still installed by default. Nothing should
> break for users who use default USE flags.
>
> USE=-native-symlinks removes a bunch of links that most packages
> use by default until are overridden explicitly. Incomplete list is:
> - /lib/cpp
> - /usr/bin/{gcc,cc,g++,c++,...}
> - /usr/bin/{as,ld,ranlib,dwp,...}
>
> The rule of thumb is: if a tool does not have ${CTARGET}- prefix
> it will probably disappear with USE=-native-symlinks.
>
> (At least eventually) 'emerge' should still be able to build most
> of packages in such environment. I expect initial breakage will be
> huge though.

Could you please add this flag to package.use.force? I don't think we
want to give people the impression that this is a well-supported
configuration. I would only expect people to disable this if they want
to break their system intentionally.

Also, people are likely to disable this accidentally via USE="-*".



Re: [gentoo-dev] rfc: $PROPERTIES, $FEATURES and pms

2020-05-17 Thread Mike Gilbert
On Sun, May 17, 2020 at 7:44 PM William Hubbs  wrote:
>
> All,
>
> I have been acting as a backup maintainer for dev-vcs/cli. A pull
> request was opened today that changes the way we detect whether the
> ebuild is live from looking for "live" in $PROPERTIES to the version
> number [1].
>
> A different dev referred me to PMS which indicates that ebuilds should
> not rely on $PROPERTIES for anything [2].

That's not what PMS says, and I think you are misinterpreting it.

> I see quite a few ebuilds in the tree checking $FEATURES however, which
> imo is even less reliable since $FEATURES is not specified anywhere in pms
> and the $FEATURES variable is portage-specific.

We don't really support checking FEATURES officially. It's a
last-resort when no better option presents itself.

> I guess I'm looking for consistency. If we are going to allow
> $FEATURES to be checked, should we allow $PROPERTIES to be checked? Or,
> should we ban checking both of them?

Inspecting PROPERTIES is technically fine, but seems fairly useless to
me. Its value is defined in ebuild code, so there's no "new"
information to be gained from it.

The code in dev-vcs/cli is broken: the "has" function takes a value
list as separate arguments, but the ebuild is passing a single string
to it. It is also done inconsistently: On line 10, it checks ${PV} ==
*, and then switches to checking ${PROPERTIES} later in the
ebuild. I think it is better to use the same logic in both places.



Re: [gentoo-dev] PR mass closing

2020-05-16 Thread Mike Gilbert
On Sat, May 16, 2020 at 2:08 PM  wrote:
>
> Was it necessary to mass close my PR on GitHub? I’ve lost quite some time to 
> make them and I’m a bit upset.

Most of us have no idea what you are talking about. Perhaps you should
direct this message to whoever closed your pull request, or provide
some context for the rest of us.



Re: [gentoo-dev] Last-rites: app-office/pybliographer

2020-05-16 Thread Mike Gilbert
On Fri, May 1, 2020 at 4:36 PM Andreas Sturmlechner  wrote:
>
> # Andreas Sturmlechner  (2020-05-01)
> # Last release in 2018, wip/gtk3 branch untouched since 2017. Bug #598906
> # Stuck on Python 2 and pygtk. Masked for removal in 30 days.
> app-office/pybliographer

I added dev-python/python-bibtex to this mask. It is also stuck on
python2, and pybliographer is the only reverse dependency.



Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-12 Thread Mike Gilbert
On Mon, May 11, 2020 at 6:58 PM William Hubbs  wrote:
>
> On Mon, May 11, 2020 at 09:51:45AM -0400, Mike Gilbert wrote:
> > On Sun, May 10, 2020 at 5:16 PM William Hubbs  wrote:
> > >
> > > All,
> > >
> > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
> > > go-module.eclass.
> > >
> > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> > > warning advising people to migrate their ebuilds to EGO_SUM.
> > >
> > > This patch makes migrating mandatory by forcing ebuilds to die if they
> > > have EGO_VENDOR set and are using go-module.eclass.
> > >
> > > Thoughts?
> >
> > It seems like you're being very lazy about this. At a minimum, you
> > should do the following:
>
> I will respond to your points below, but first, I take offense to your
> accusation of me being lazy especially since it seems pretty obvious you
> didn't attempt to research my work before you said it.

The phrasing of your original email, combined with a question you
asked in IRC lead me to the wrong conclusion. Sorry about that.



Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-11 Thread Mike Gilbert
On Sun, May 10, 2020 at 5:16 PM William Hubbs  wrote:
>
> All,
>
> now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
> go-module.eclass.
>
> This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> warning advising people to migrate their ebuilds to EGO_SUM.
>
> This patch makes migrating mandatory by forcing ebuilds to die if they
> have EGO_VENDOR set and are using go-module.eclass.
>
> Thoughts?

It seems like you're being very lazy about this. At a minimum, you
should do the following:

1. Search for affected packages.
2. Contact the maintainers, possibly via bug reports.
3. Give them a some time to convert their packages.
4. Mask any packages that do not get updated.



[gentoo-portage-dev] [PATCH] phase-functions.sh: do not set PKG_CONFIG_PATH

2020-05-03 Thread Mike Gilbert
Recent pkg-config should have the correct path built in by default.

Bug: https://bugs.gentoo.org/720866
Signed-off-by: Mike Gilbert 
---
 bin/phase-functions.sh | 4 
 1 file changed, 4 deletions(-)

diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index 709fd7527..90e622e75 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -1019,10 +1019,6 @@ __ebuild_main() {
[[ ${SANDBOX_WRITE/$DISTCC_DIR} = 
$SANDBOX_WRITE ]] && \
addwrite "$DISTCC_DIR"
 
-   x=LIBDIR_$ABI
-   [ -z "$PKG_CONFIG_PATH" -a -n "$ABI" -a -n "${!x}" ] && 
\
-   export 
PKG_CONFIG_PATH=${EPREFIX}/usr/${!x}/pkgconfig
-
if has noauto $FEATURES && \
[[ ! -f $PORTAGE_BUILDDIR/.unpacked ]] ; then
echo
-- 
2.26.2




Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.

2020-04-27 Thread Mike Gilbert
On Mon, Apr 27, 2020 at 10:03 AM Kent Fredric  wrote:
>
> On Mon, 27 Apr 2020 09:43:44 -0400
> Mike Gilbert  wrote:
>
> > He was replying to me. Your master connection will continue to work
> > just fine, as I said in my previous message.
>
> I must have lost something in grammar, because no matter how many times I 
> read:
>
> > If you are authenticating that master connection as the "git" user, I
> > suspect it will not affect you. If you are using it to push to
> > gentoo.git, that is almost certainly the case.
>
> I interpret that as:
>
> - Anonymous fetch is fine
> - Authorised Push will fail

There's no such thing as an "anonymous fetch" from git.gentoo.org. You
must be authenticated to do anything.

> But I guess my mistake is in that we don't push with "user@git ...", we
> push with "git@ ... ", and the SSH key is the gate keeper of "push will
> work", not the UID.
>
> Right?

Correct.

> So assuming you're using git@ for fetch *and* push, *then* it will
> continue to work.
>
> Right?

Correct.



Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.

2020-04-27 Thread Mike Gilbert
On Mon, Apr 27, 2020 at 9:13 AM Kent Fredric  wrote:
>
> On Sun, 26 Apr 2020 18:00:19 -0700
> Alec Warner  wrote:
>
> > This is correct.
>
> Surely then, this is a reduction in fuctionality.
>
> That's a handy tool to put up your sleeve when you're trying to avoid
> getting thrashed by slow network connects when some contributor is
> pushing every 30 seconds :)

He was replying to me. Your master connection will continue to work
just fine, as I said in my previous message.



Re: [gentoo-dev] [PATCH] glep-0072: The arch name in the first column must be unique.

2020-04-26 Thread Mike Gilbert
On Sun, Apr 26, 2020 at 3:37 PM Ulrich Mueller  wrote:
>
> When implementing support for arches.desc in ebuild-mode, I noticed
> that the GLEP would allow several lines with the same architecture in
> the first column. So, specify that the arch must be unique.
>
> I don't attach the full text because this is a one-line change.

Please use git-send-email whenever possible; it makes reviewing
changes in an email client easier.



Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.

2020-04-26 Thread Mike Gilbert
On Sun, Apr 26, 2020 at 8:38 AM Kent Fredric  wrote:
>
> On Sat, 25 Apr 2020 14:12:02 -0700
> Alec Warner  wrote:
>
> > Thus I now plan to remove this access[0]. If you need access to ssh as
> > something not-git to git.gentoo.org, let me know in the next week.
>
> Will this affect people who set up no-op SSH connections for a
> persistent connection master, so that following git actions don't have
> to pay the SSH connection startup penalty?

If you are authenticating that master connection as the "git" user, I
suspect it will not affect you. If you are using it to push to
gentoo.git, that is almost certainly the case.



[gentoo-dev] [PATCH] meson.eclass: implement support for native machine files

2020-04-25 Thread Mike Gilbert
Using a native file avoids putting meson into cross-compiler mode for
multilib builds.

Reference: https://mesonbuild.com/Machine-files.html
Reference: https://mesonbuild.com/Native-environments.html

Bug: https://bugs.gentoo.org/719382
Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 107 +++-
 1 file changed, 87 insertions(+), 20 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 423a497e840c..7b1a6a9735bd 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -125,17 +125,17 @@ _meson_env_array() {
python -c "${__MESON_ARRAY_PARSER}" "$@"
 }
 
-# @FUNCTION: _meson_create_cross_file
+# @FUNCTION: _meson_get_machine_info
+# @USAGE: 
+# @RETURN: system/cpu_family/cpu variables
 # @INTERNAL
 # @DESCRIPTION:
-# Creates a cross file. meson uses this to define settings for
-# cross-compilers. This function is called from meson_src_configure.
-_meson_create_cross_file() {
-   # Reference: http://mesonbuild.com/Cross-compilation.html
+# Translate toolchain tuple into machine values for meson.
+_meson_get_machine_info() {
+   local tuple=$1
 
# system roughly corresponds to uname -s (lowercase)
-   local system=unknown
-   case ${CHOST} in
+   case ${tuple} in
*-aix*)  system=aix ;;
*-cygwin*)   system=cygwin ;;
*-darwin*)   system=darwin ;;
@@ -145,19 +145,29 @@ _meson_create_cross_file() {
*-solaris*)  system=sunos ;;
esac
 
-   local cpu_family=$(tc-arch)
+   cpu_family=$(tc-arch "${tuple}")
case ${cpu_family} in
amd64) cpu_family=x86_64 ;;
arm64) cpu_family=aarch64 ;;
esac
 
# This may require adjustment based on CFLAGS
-   local cpu=${CHOST%%-*}
+   cpu=${tuple%%-*}
+}
+
+# @FUNCTION: _meson_create_cross_file
+# @RETURN: path to cross file
+# @INTERNAL
+# @DESCRIPTION:
+# Creates a cross file. meson uses this to define settings for
+# cross-compilers. This function is called from meson_src_configure.
+_meson_create_cross_file() {
+   local system cpu_family cpu
+   _meson_get_machine_info "${CHOST}"
 
-   local needs_exe_wrapper=false
-   tc-is-cross-compiler && needs_exe_wrapper=true
+   local fn=${T}/meson.${CHOST}.ini
 
-   cat > "${T}/meson.${CHOST}.${ABI}" <<-EOF
+   cat > "${fn}" <<-EOF
[binaries]
ar = $(_meson_env_array "$(tc-getAR)")
c = $(_meson_env_array "$(tc-getCC)")
@@ -181,16 +191,67 @@ _meson_create_cross_file() {
objc_link_args = $(_meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
objcpp_args = $(_meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
-   needs_exe_wrapper = ${needs_exe_wrapper}
+   needs_exe_wrapper = true
sys_root = '${SYSROOT}'
-   pkg_config_libdir = 
'${PKG_CONFIG_LIBDIR-${EPREFIX}/usr/$(get_libdir)/pkgconfig}'
+   pkg_config_libdir = '${EPREFIX}/usr/$(get_libdir)/pkgconfig'
 
[host_machine]
system = '${system}'
cpu_family = '${cpu_family}'
cpu = '${cpu}'
-   endian = '$(tc-endian)'
+   endian = '$(tc-endian "${CHOST}")'
+   EOF
+
+   echo "${fn}"
+}
+
+# @FUNCTION: _meson_create_native_file
+# @RETURN: path to native file
+# @INTERNAL
+# @DESCRIPTION:
+# Creates a native file. meson uses this to define settings for
+# native compilers. This function is called from meson_src_configure.
+_meson_create_native_file() {
+   local system cpu_family cpu
+   _meson_get_machine_info "${CBUILD}"
+
+   local fn=${T}/meson.${CBUILD}.ini
+
+   cat > "${fn}" <<-EOF
+   [binaries]
+   ar = $(_meson_env_array "$(tc-getBUILD_AR)")
+   c = $(_meson_env_array "$(tc-getBUILD_CC)")
+   cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
+   fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
+   llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+   objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
+   objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
+   pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
+   strip = $(_meson_env_array "$(tc-getBUILD_STRIP)")
+   windres = $(_meson_env_array "$(tc-getBUILD_PROG RC windres)")
+
+   [properties]
+   c_args = $(_meson_env_array "${BUILD_CFLAGS} ${BUILD_CPPFLAGS}")
+   c_link_args = $(_meson_env_array "${BUILD_CFLAGS} ${BUILD_LDFLAGS}")
+   cpp_args = $(_meson_env_array "${BUILD_CXXFLAGS} ${BUILD_CPPFLAGS}")
+   cpp_link_args = $(_meson_env_array "${BUILD_CXXFLAGS} ${BUILD

[gentoo-portage-dev] [PATCH] Import portage.util.netlink.RtNetlink in global scope

2020-04-20 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/718578
Signed-off-by: Mike Gilbert 
---
 lib/portage/process.py | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/portage/process.py b/lib/portage/process.py
index 590116890..79052b608 100644
--- a/lib/portage/process.py
+++ b/lib/portage/process.py
@@ -27,6 +27,13 @@ from portage.const import BASH_BINARY, SANDBOX_BINARY, 
FAKEROOT_BINARY
 from portage.exception import CommandNotFound
 from portage.util._ctypes import find_library, LoadLibrary, ctypes
 
+try:
+   from portage.util.netlink import RtNetlink
+except ImportError:
+   if platform.system() == "Linux":
+   raise
+   RtNetlink = None
+
 try:
import resource
max_fd_limit = resource.getrlimit(resource.RLIMIT_NOFILE)[0]
@@ -504,8 +511,8 @@ def _configure_loopback_interface():
# Bug: https://bugs.gentoo.org/690758
# Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
 
-   # Avoid importing this module on systems that may not support netlink 
sockets.
-   from portage.util.netlink import RtNetlink
+   if RtNetlink is None:
+   return
 
try:
with RtNetlink() as rtnl:
-- 
2.26.1




[gentoo-dev] [PATCH] meson.eclass: export NM and READELF variables

2020-04-20 Thread Mike Gilbert
These are used by the symbolextractor.py script in meson.

Closes: https://bugs.gentoo.org/717720
Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2bd1dc017609..81cfa7c38fc6 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -261,6 +261,11 @@ meson_src_configure() {
"${BUILD_DIR}"
)
 
+   # Used by symbolextractor.py
+   # https://bugs.gentoo.org/717720
+   tc-export NM
+   tc-getPROG READELF readelf >/dev/null
+
# https://bugs.gentoo.org/625396
python_export_utf8_locale
 
-- 
2.26.1




[gentoo-dev] Re: [PATCH] meson.eclass: update the example to use modern helper functions

2020-04-13 Thread Mike Gilbert
On Mon, Apr 13, 2020 at 5:48 PM Marek Szuba  wrote:
>
> We have now got meson_use and meson_feature yet the example still
> used usex.
>
> Signed-off-by: Marek Szuba 

Reviewed-by: Mike Gilbert 



Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread Mike Gilbert
On Mon, Apr 13, 2020 at 1:17 PM Michał Górny  wrote:
>
> Hi,
>
> One of the goals behind NATTkA was to make keywording/stabilization
> easier.  Right now it's mostly possible to file the most common requests
> without having to copy keywords everywhere.  Still, there's a need to CC
> arches which isn't exactly the most convenient part.
>
> I was thinking how to make NATTkA help with that.  After considering
> a few options, I'd like to push forward the following proposition: let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
>
> What do you think?

Sounds good to me.



Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Mike Gilbert
On Sat, Apr 11, 2020 at 12:28 PM Thomas Deutschmann  wrote:
>
> On 2020-04-11 17:33, Michał Górny wrote:
> > 1. We kill both keywords, and just rely on components, or
> >
> > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where
> > appropriate.
>
> I think you cannot kill it.
>
> Yes, we have a component for stabilization/keywording, but we also do
> stabilization from security bugs which don't have such a component and
> some tools must be able to filter.

Someone proposed that we change the security bug workflow to include a
separate stable request bug, which would resolve this.

That would also help in cases where we are stabilizing
security-unsupported archs at the same time.



[gentoo-dev] [PATCH 2/2] meson.eclass: add MYMESONARGS variable

2020-04-08 Thread Mike Gilbert
This was requested to allow users to pass aribtrary arguments to meson.

Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 3e3a2e2f7a2e..0932a7ed427f 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -84,6 +84,11 @@ fi
 # Optional meson test arguments as Bash array; this should be defined before
 # calling meson_src_test.
 
+# @VARIABLE: MYMESONARGS
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# User-controlled environment variable containing arguments to be passed to
+# meson in meson_src_configure.
 
 read -d '' __MESON_ARRAY_PARSER <<"EOF"
 import shlex
@@ -236,6 +241,9 @@ meson_src_configure() {
 
BUILD_DIR="${BUILD_DIR:-${WORKDIR}/${P}-build}"
 
+   # Handle quoted whitespace
+   eval "local -a MYMESONARGS=( ${MYMESONARGS} )"
+
mesonargs+=(
# Arguments from ebuild
"${emesonargs[@]}"
@@ -243,6 +251,9 @@ meson_src_configure() {
# Arguments passed to this function
"$@"
 
+   # Arguments from user
+   "${MYMESONARGS[@]}"
+
# Source directory
"${EMESON_SOURCE:-${S}}"
 
-- 
2.26.0




[gentoo-dev] [PATCH 1/2] meson.eclass: clean up meson_src_configure

2020-04-08 Thread Mike Gilbert
This mainly rearranges some code to make it easier to read.
Also changes the bare 'meson' call to 'meson setup'.

Signed-off-by: Mike Gilbert 
---
 eclass/meson.eclass | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 16e17dd4a384..3e3a2e2f7a2e 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -219,32 +219,42 @@ meson_feature() {
 meson_src_configure() {
debug-print-function ${FUNCNAME} "$@"
 
-   # Common args
local mesonargs=(
+   meson setup
--buildtype plain
--libdir "$(get_libdir)"
--localstatedir "${EPREFIX}/var/lib"
--prefix "${EPREFIX}/usr"
--sysconfdir "${EPREFIX}/etc"
--wrap-mode nodownload
-   )
+   )
 
if tc-is-cross-compiler || [[ ${ABI} != ${DEFAULT_ABI-${ABI}} ]]; then
_meson_create_cross_file || die "unable to write meson cross 
file"
mesonargs+=( --cross-file "${T}/meson.${CHOST}.${ABI}" )
fi
 
+   BUILD_DIR="${BUILD_DIR:-${WORKDIR}/${P}-build}"
+
+   mesonargs+=(
+   # Arguments from ebuild
+   "${emesonargs[@]}"
+
+   # Arguments passed to this function
+   "$@"
+
+   # Source directory
+   "${EMESON_SOURCE:-${S}}"
+
+   # Build directory
+   "${BUILD_DIR}"
+   )
+
# https://bugs.gentoo.org/625396
python_export_utf8_locale
 
-   # Append additional arguments from ebuild
-   mesonargs+=("${emesonargs[@]}")
-
-   BUILD_DIR="${BUILD_DIR:-${WORKDIR}/${P}-build}"
-   set -- meson "${mesonargs[@]}" "$@" \
-   "${EMESON_SOURCE:-${S}}" "${BUILD_DIR}"
-   echo "$@"
-   tc-env_build "$@" || die
+   echo "${mesonargs[@]}" >&2
+   tc-env_build "${mesonargs[@]}" || die
 }
 
 # @FUNCTION: meson_src_compile
-- 
2.26.0




Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

2020-04-06 Thread Mike Gilbert
On Mon, Apr 6, 2020 at 9:23 AM Pacho Ramos  wrote:
>
> El jue, 02-04-2020 a las 16:28 +0200, Pacho Ramos escribió:
> > Hello,
> >
> > I was reviewing about how to enable globally on my system the usage of
> > libappindicator and I realized that we have multiple names for that in the
> > tree.
> > "ayatana" is the only global one, while other packages are using 
> > "indicator",
> > "libindicate", "appindicator"...
> >
> > Personally I would merge all them in only one, and I wonder if maybe
> > "indicator"
> > or "appindicator" would be more meaningful for most users than "ayatana", 
> > what
> > do you think?
> >
> > Thanks
>
> Personally I would opt for global "appindicator" as it seems to be more widely
> used and I think it is a bit more self-explanatory :/

Sounds reasonable to me.



Re: [gentoo-dev] Changes to toolchain.eclass to better support gnat-gpl ebuild

2020-04-02 Thread Mike Gilbert
On Thu, Apr 2, 2020 at 6:52 AM Alfredo Tupone  wrote:
>
> I would like to have the attached changes reviewed and, if possible,
> applied to the toolchain eclass.

Please generate patches using git-format-patch, and send them using
git-send-email. This allows them to be easily reviewed in a mail
client.

> + if use ada; then
> + gcc_do_make "-C gcc gnatlib-shared"
> + ln -s gcc ../build/prev-gcc || die
> + ln -s ${CHOST} ../build/prev-${CHOST} || die
> + gcc_do_make "-C gcc gnattools"
> + fi

You probably want "is_ada" instead of "use ada" here. Otherwise,
portage will error if "ada" is not in IUSE.



[gentoo-dev] [PATCH] cmake.eclass: do not append -DNDEBUG to CPPFLAGS

2020-03-29 Thread Mike Gilbert
The NDEBUG macro turns the assert() function into a noop. This gives a
small performance boost, but may allow subtle programming errors to go
unnoticed.

This code was added back in 2008, when we started passing
-DCMAKE_BUILD_TYPE=None instead of Release or Debug. It probably tries
to mimic a default behavior of Release type builds.

Other common build systems do not do this by default. For example,
autoconf's AC_HEADER_ASSERT macro only sets NDEBUG if --disable-assert
is passed to configure (it defaults to enabled).

It is better to let users add this to CPPFLAGS themselves if they really
want to save those few CPU cycles.

Signed-off-by: Mike Gilbert 
---
 eclass/cmake.eclass | 9 -
 1 file changed, 9 deletions(-)

diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 160f40b1cf8e..3da3b9aeb555 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -371,15 +371,6 @@ cmake_src_configure() {
# Fix xdg collision with sandbox
xdg_environment_reset
 
-   # @SEE CMAKE_BUILD_TYPE
-   if [[ ${CMAKE_BUILD_TYPE} = Gentoo ]]; then
-   # Handle release builds
-   if ! in_iuse debug || ! use debug; then
-   local CPPFLAGS=${CPPFLAGS}
-   append-cppflags -DNDEBUG
-   fi
-   fi
-
# Prepare Gentoo override rules (set valid compiler, append CPPFLAGS 
etc.)
local build_rules=${BUILD_DIR}/gentoo_rules.cmake
 
-- 
2.26.0.rc2




Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-28 Thread Mike Gilbert
On Sat, Mar 28, 2020 at 10:22 AM Jaco Kroon  wrote:
>
> Hi,
>
> So I figured I better write the patch for dahdi-tools against musl ...
> so I proceed to download a stage3 tar from
> http://distfiles.gentoo.org/experimental/amd64/musl/ (vanilla).
>
> I extract it, and mount --rebind /dev, /proc and /sys, and copy in
> /etc/resolve.conf ...
>
> chroot ... and so far so good.
>
> emerge --sync
> emerge -uDNav @world.
>
> And this blows up on pam-1.3.1-r2.  Looks like
> https://bugs.gentoo.org/687234.
>
> I've seen mention of a musl overlay?
>
> What's the best way to proceed?

Either add sys-libs/pam to package.accept_keywords to pick the latest
fixes, or fetch/enable this overlay:
https://gitweb.gentoo.org/proj/musl.git/



Re: [gentoo-dev] [PATCH 2/2] multilib.eclass: multilib_env(): set LIBDIR=lib for *-musl*

2020-03-28 Thread Mike Gilbert
On Sat, Mar 28, 2020 at 5:40 AM Sergei Trofimovich  wrote:
>
> In contrast to glibc musl profiles use 'lib' layour for 32-bit
> and 64-bit targets. multilib_env() did not take it into account
> and assumed glibc's lib64 layout.
>
> That breaks crossdev as it uses multilib_env to extract target
> definition. Native builds are unaffected by this change.
>
> Bug: https://bugs.gentoo.org/675954
> Bug: https://gcc.gnu.org/PR90077
> Bug: https://github.com/gentoo/musl/issues/245
> Signed-off-by: Sergei Trofimovich 

Please also update the copyright notice in multilib.eclass while you're at it.



Re: [gentoo-dev] [PATCH 1/2] eclass/tests: add basic tests for multilib_env() expansion

2020-03-28 Thread Mike Gilbert
On Sat, Mar 28, 2020 at 5:40 AM Sergei Trofimovich  wrote:
>
> Signed-off-by: Sergei Trofimovich 
> ---
>  eclass/tests/multilib.sh | 61 
>  1 file changed, 61 insertions(+)
>  create mode 100755 eclass/tests/multilib.sh
>
> diff --git a/eclass/tests/multilib.sh b/eclass/tests/multilib.sh
> new file mode 100755
> index 000..308c456b98d
> --- /dev/null
> +++ b/eclass/tests/multilib.sh
> @@ -0,0 +1,61 @@
> +#!/bin/bash
> +# Copyright 1999-2020 Gentoo Foundation

This should say "Copyright 2020 Gentoo Authors".

> +# Distributed under the terms of the GNU General Public License v2
> +
> +source tests-common.sh
> +
> +inherit multilib
> +
> +# Run 'multilib_env' and check what variables it expands to
> +test-multilib_env() {
> +   local target=$1 exp_abi=$2 exp_vars=" $3"
> +   tbegin "expand-target $1"
> +
> +   # Reset default
> +   unset MULTILIB_ABIS
> +   unset DEFAULT_ABI
> +   CFLAGS_default=
> +   LDFLAGS_default=
> +   LIBDIR_default=lib
> +   CHOST_default=${target}
> +   CTARGET_default=${CHOST_default}
> +   LIBDIR_default=lib
> +
> +   multilib_env ${target}
> +
> +   local actual_abi="${DEFAULT_ABI}:${MULTILIB_ABIS}"
> +
> +   local actual_vars=""
> +   local abi var v
> +   for abi in ${MULTILIB_ABIS}; do
> +   actual_vars+=" ${abi}? ("
> +   for var in CHOST LIBDIR CFLAGS LDFLAGS; do
> +   v=${var}_${abi}
> +   actual_vars+=" ${var}=${!v}"
> +   done
> +   actual_vars+=" )"
> +   done
> +
> +   [[ "${exp_abi}" == "${actual_abi}" && "${exp_vars}" == 
> "${actual_vars}" ]]
> +
> +   if ! tend $? ; then
> +   printf '### EXPECTED ABI: %s\n' "${exp_abi}"
> +   printf '### ACTUAL   ABI: %s\n' "${actual_abi}"
> +   printf '### EXPECTED VARS: %s\n' "${exp_vars}"
> +   printf '### ACTUAL   VARS: %s\n' "${actual_vars}"
> +   fi
> +}
> +
> +# Pick a few interesting gargets from:

Probably a typo: s/gargets/targets/

> +# $ grep -h -o -R 'CHOST=.*' ../../profiles/ | sort -u
> +
> +test-multilib_env \
> +   "x86_64-pc-linux-gnu" \
> +   "amd64:amd64 x86" \
> +   "amd64? ( CHOST=x86_64-pc-linux-gnu LIBDIR=lib64 CFLAGS=-m64 LDFLAGS= 
> ) x86? ( CHOST=i686-pc-linux-gnu LIBDIR=lib CFLAGS=-m32 LDFLAGS= )"
> +test-multilib_env \
> +   "x86_64-pc-linux-gnux32" \
> +   "x32:x32 amd64 x86" \
> +   "x32? ( CHOST=x86_64-pc-linux-gnux32 LIBDIR=libx32 CFLAGS=-mx32 
> LDFLAGS= ) amd64? ( CHOST=x86_64-pc-linux-gnu LIBDIR=lib64 CFLAGS=-m64 
> LDFLAGS= ) x86? ( CHOST=i686-pc-linux-gnu LIBDIR=lib CFLAGS=-m32 LDFLAGS= )"
> +
> +texit
> --
> 2.26.0
>
>



Re: [gentoo-dev] Missing ebuild for Mirror and CI scripts

2020-03-27 Thread Mike Gilbert
On Fri, Mar 27, 2020 at 12:19 PM Samuel Bernardo
 wrote:
>
> Dear all,
>
> Would it be possible to create official ebuilds for Gentoo
> infrastructure projects, such as:
>
> https://github.com/mgorny/repo-mirror-ci
>
> https://github.com/mgorny/pkgcheck-result-parser
>

Neither repo has any tagged "releases". I don't see how an ebuild
would be particularly useful. How do you intend to use them?



Re: [gentoo-dev] [PATCH v2]

2020-03-26 Thread Mike Gilbert
On Thu, Mar 26, 2020 at 7:19 PM Patrick McLean  wrote:
>
> This patch splits the definition of _PYTHON_ALL_IMPLS and
> _python_impl_supported to a separate eclass, this allows overlays
> to easily support a different set of python implementations than
> ::gentoo without having to fork the entire suite of eclasses.
>
> Changes from previous version (based on feedback on IRC):
> - add a guard variable to make sure it's being inherited
>   python-utils-r1.eclass

In the future, please generate patches using git-format-patch, and
mail them using git-send-email. That way we don't end up having to
open an attachment, and we can also review the commit message.



Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread Mike Gilbert
On Thu, Mar 26, 2020 at 3:13 PM William Hubbs  wrote:
>
> This variable is meant to be set in downstream overlays when they need python
> implementations other than the ones we support in the tree.
> It should be a space-separated list of extra implementations.

This new variable should be documented in the eclass, along with a
note that its use is unsupported for general use.

Do you intend this variable to be set in profiles or make.conf? In
either case, I don't think you can use bash arrays. Also, you're
mixing scalar and array variable syntax in your patch.



[gentoo-dev] Re: [PATCH v2] fixheadtails.eclass: drop the sed dependency

2020-03-25 Thread Mike Gilbert
On Wed, Mar 25, 2020 at 1:40 PM David Michael  wrote:
>
> On Fri, Mar 20, 2020 at 5:12 PM David Michael  wrote:
> > Signed-off-by: David Michael 
> > ---
> >
> > Changes since v1:
> >   * Drop the dependency altogether
> >
> >  eclass/fixheadtails.eclass | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/eclass/fixheadtails.eclass b/eclass/fixheadtails.eclass
> > index c19d33924aa..475b182843a 100644
> > --- a/eclass/fixheadtails.eclass
> > +++ b/eclass/fixheadtails.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2014 Gentoo Foundation
> > +# Copyright 1999-2020 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >
> >  # @ECLASS: fixheadtails.eclass
> > @@ -8,8 +8,6 @@
> >  # Original author John Mylchreest 
> >  # @BLURB: functions to replace obsolete head/tail with POSIX compliant ones
> >
> > -DEPEND=">=sys-apps/sed-4"
> > -
> >  _do_sed_fix() {
> > einfo " - fixed $1"
> > sed -i \
> > --
> > 2.21.1
>
> Can this patch be applied?

Done.



Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-21 Thread Mike Gilbert
On Sat, Mar 21, 2020 at 6:43 AM Mart Raudsepp  wrote:
>
> Ühel kenal päeval, L, 21.03.2020 kell 11:16, kirjutas Pacho Ramos:
> > I agree, I see that also Debian is applying it unconditionally even
> > when running
> > systemd
>
> But I assume it would be a problem with USE=systemd + USE=-user-session
> dbus, so how about instead of this profile business, we then just go
> with:
>
> * Revbump bluez to drop IUSE=user-session, unconditionally apply the
> patch and change the dbus dep in systemd conditional to
> >=sys-apps/dbus-1.6:=[user-session(+)]
> * Fix bluez USE=systemd handling in above revbump as well: --enable-
> systemd should always be passed, not controlled by a USE=systemd,
> because all it appears to do is decide whether to install systemd
> service files, and that should be always done per the small files
> policy.
>
> * Revbump dbus, dropping user-session IUSE and unconditionally passing
> --enable-user-session

I think we should probably move it behind USE=systemd. It should
probably be that way already, but I missed it when adding the
user-session flag to the dbus ebuild.

There is a quite a bit of conditionally compiled code in dbus-daemon
that gets disabled if --disable-systemd is passed to configure. I
would guess that dbus.service will not function properly if this code
is not enabled.

Since we are dropping user-session from IUSE, the following should suffice:

$(use_enable systemd user-session)

> * After some time (dbus revision with IUSE=user-session has been gone
> for a while), remove all of the IUSE=systemd handling from bluez, as
> the user-session matching enforcement isn't needed anymore (and the
> configure systemd conditional has been nuked per above)
> * At that point the package.use entries can be removed altogether as
> well, instead of migrating to systemd target profile.

Agreed on the rest of the plan.



Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Mike Gilbert
On Wed, Mar 18, 2020 at 9:59 PM Kent Fredric  wrote:
>
> On Wed, 18 Mar 2020 17:52:25 +
> James Le Cuirot  wrote:
>
> > Not quite. Tools like repoman will need to be updated to understand
> > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> > only KEYWORDS="noarch". I do think the idea has merit though.
>
> But the inverse is _not_ true, an ebuild with KEYWORDS="noarch"
> *cannot* depend on another ebuild with only KEYWORDS="amd64".
>
> Otherwise it breaks the entire stabilization graph.

I'm not sure what you mean by "stabilization graph". I'm guessing you
mean the dependency graph for stable keywords?

Valid dependency graphs are determined by whatever our tooling deems
valid. The tooling could be updated to permit amd64 packages to depend
on noarch packages, and vice-versa.



Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-19 Thread Mike Gilbert
On Thu, Mar 19, 2020 at 9:41 AM Mart Raudsepp  wrote:
>
> Ühel kenal päeval, K, 18.03.2020 kell 16:43, kirjutas Mike Gilbert:
> > Seems good to me in principle, but I'm not sure it is something we
> > > should do until we haven't promoted this into a global USE flag.
> >
> > An alternative would be to add entries in package.use.
>
> Yeah, that'd be what it is now, just done in systemd profile, not most
> of the separate systemd profiles.
>
> > > With the disclaimer of not knowing anything about dbus[user-
> > > session] on
> > > a non-systemd system - maybe it's just time to make user-session
> > > unconditionally enabled on dbus (and then bluez) instead?
> > > All it seems to do (on a very quick look) is install some extra
> > > systemd
> > > files - can't they just be always installed (by always passing --
> > > enable-user-session) and call it a day?
> >
> > It looks like user-session has no effect if systemd is not in use.
> >
> > On systems running systemd, having the units installed automatically
> > enables the systemd user bus, and the only way to disable it is to
> > mask the units. Having the user bus enabled generally prevents
> > display
> > managers and startx from starting individual session buses, since
> > they
> > will use the user bus instead. That's probably fine, but I wanted to
> > note it.
>
> So how about we try to just always enable this instead in dbus and
> bluez? Anyone got any objections, provided the below can be handled?
>
> I peeked at bluez, and there USE=user-session exists to apply a patch
> to unbreak things when user-session is disabled. Unfortunately it seems
> to be needed there for non-systemd systems as well. I think we should
> be able to figure things out to work in all situations there, or make
> it be applied for USE=-systemd only (that's already the case there,
> just it is not applied for USE="systemd -user-session" right now).

I think we can apply
0001-Allow-using-obexd-without-systemd-in-the-user-session-r2.patch
unconditionally.

The patched unit should work just fine with systemd, provided the user
bus is available.



Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-18 Thread Mike Gilbert
On Wed, Mar 18, 2020 at 4:16 PM Mart Raudsepp  wrote:
>
> > @@ -1,6 +1,6 @@
> > -# Copyright 1999-2014 Gentoo Foundation
> > +# Copyright 1999-2020 Gentoo Foundation
> >  # Distributed under the terms of the GNU General Public License v2
> >
> > -USE="systemd udev"
> > +USE="systemd udev user-session"
> >
> >  BOOTSTRAP_USE="${BOOTSTRAP_USE} systemd udev"
>
> Seems good to me in principle, but I'm not sure it is something we
> should do until we haven't promoted this into a global USE flag.

An alternative would be to add entries in package.use.

> With the disclaimer of not knowing anything about dbus[user-session] on
> a non-systemd system - maybe it's just time to make user-session
> unconditionally enabled on dbus (and then bluez) instead?
> All it seems to do (on a very quick look) is install some extra systemd
> files - can't they just be always installed (by always passing --
> enable-user-session) and call it a day?

It looks like user-session has no effect if systemd is not in use.

On systems running systemd, having the units installed automatically
enables the systemd user bus, and the only way to disable it is to
mask the units. Having the user bus enabled generally prevents display
managers and startx from starting individual session buses, since they
will use the user bus instead. That's probably fine, but I wanted to
note it.



Re: [gentoo-dev] [PATCH] fcaps.eclass: use BDEPEND for EAPI 7

2020-03-13 Thread Mike Gilbert
On Fri, Mar 13, 2020 at 2:23 PM David Michael  wrote:
>
> The eclass installs libcap to execute the setcap program, so it
> must be installed in /.  Optional libcap linking is handled by the
> USE=caps flag, which is unrelated to this eclass, so the DEPEND
> declaration is not needed on EAPI 7.
>
> Closes: https://bugs.gentoo.org/700018
> Signed-off-by: David Michael 
> ---
>  eclass/fcaps.eclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
> index 467f955f5e9..b0479f32456 100644
> --- a/eclass/fcaps.eclass
> +++ b/eclass/fcaps.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2015 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>
>  # @ECLASS: fcaps.eclass
> @@ -34,7 +34,10 @@ _FCAPS_ECLASS=1
>  IUSE="+filecaps"
>
>  # We can't use libcap-ng atm due to #471414.
> -DEPEND="filecaps? ( sys-libs/libcap )"
> +case "${EAPI:-0}" in
> +   7) BDEPEND="filecaps? ( sys-libs/libcap )" ;;
> +   *) DEPEND="filecaps? ( sys-libs/libcap )" ;;
> +esac

Please reverse the logic: if EAPI is in 0-6, set DEPEND, otherwise set
BDEPEND. Assuming future EAPIs support BDEPEND, this will future-proof
the eclass somewhat.



[gentoo-dev] [PATCH] profiles: remove USE="cxx" from the base profile

2020-03-09 Thread Mike Gilbert
This was added back in the days when all toolchain ebuilds had EAPI=0
and IUSE defaults were not an option. toolchain.eclass now supports
newer EAPIs, and sets IUSE="+cxx".

Signed-off-by: Mike Gilbert 
---
 profiles/base/make.defaults | 6 --
 1 file changed, 6 deletions(-)

diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index f4782af3b138..cf27a009b57c 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -102,12 +102,6 @@ LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 
lcdm001 mtxorb ncurses te
 # Updated to include ruby25 on 2019-07-17
 RUBY_TARGETS="ruby24 ruby25"
 
-# Samuli Suominen  (2009-12-03)
-# Enable USE cxx by default so base-system and toolchain pkgs can start using 
USE cxx
-# instead of USE nocxx.
-# 
https://archives.gentoo.org/gentoo-dev/msg_a181cd0d36600067b599f4b996c6989f.xml
-USE="${USE} cxx"
-
 # Enable extended filesystem attribute support by default.
 # 
https://archives.gentoo.org/gentoo-dev/message/ba0e3457e4b807e79816f0df03566af0
 USE="${USE} xattr"
-- 
2.25.1




Re: [gentoo-dev] [PATCH] fcaps.eclass: skip fcaps() on Prefix.

2020-03-08 Thread Mike Gilbert
On Sun, Mar 8, 2020 at 5:20 AM  wrote:
>
> From: Benda Xu 
>
> Gentoo Prefix runs with a normal user and cannot grant extra
> capabilities.  Exit gracefully with a message.
>
> Signed-off-by: Benda Xu 
> ---
>  eclass/fcaps.eclass | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
> index 467f955f5e9a..ddc4d3ccc6d8 100644
> --- a/eclass/fcaps.eclass
> +++ b/eclass/fcaps.eclass
> @@ -78,6 +78,11 @@ DEPEND="filecaps? ( sys-libs/libcap )"
>  fcaps() {
> debug-print-function ${FUNCNAME} "$@"
>
> +   if [[ ${EUID} != 0 ]] ; then
> +   einfo "Insufficient privileges to execute ${FUNCNAME}, skip."
> +   return 0
> +   fi
> +

It seems like you are commanding the user to skip.

s/skip/skipping/



Re: [gentoo-dev] [PATCH] meson.eclass: Set needs_exe_wrapper in cross file

2020-03-06 Thread Mike Gilbert
On Wed, Mar 4, 2020 at 2:55 PM Matt Turner  wrote:
>
> needs_exe_wrapper tells meson whether the build machine is able to
> directly execute the binaries it produces or whether it needs an exe
> wrapper (like QEMU). For non-native ABI builds like building 32-bit
> libraries on an x86-64 system, we want this set to false to communicate
> to meson that the build machine can run the binaries directly.
>
> This allows dev-libs/wayland to execute the wayland-scanner binary it
> builds rather than relying on the system's.
>
> Signed-off-by: Matt Turner 

Reviewed-by: Mike Gilbert 

Looks good to me.



Re: [gentoo-portage-dev] [PATCH] repoman: remove check for addpredict

2020-03-05 Thread Mike Gilbert
On Thu, Mar 5, 2020 at 3:59 PM Michał Górny  wrote:
>
> On Thu, 2020-03-05 at 15:30 -0500, Mike Gilbert wrote:
> > This function has not been deprecated, and developers generally have a
> > good reason for using it. A repoman warning for this is just noise.
> >
> > No reason was given when this check was added in 2010, and it was requested
> > by a developer who has since retired.
> >
>
> If you want to remove this class of warnings, I'd suggest removing
> the one for -j1 as well.  Same argument.

Makes sense to me.



[gentoo-portage-dev] [PATCH] repoman: remove check for addpredict

2020-03-05 Thread Mike Gilbert
This function has not been deprecated, and developers generally have a
good reason for using it. A repoman warning for this is just noise.

No reason was given when this check was added in 2010, and it was requested
by a developer who has since retired.

Signed-off-by: Mike Gilbert 
---
 repoman/cnf/linechecks/linechecks.yaml | 1 -
 repoman/cnf/repository/repository.yaml | 1 -
 .../lib/repoman/modules/linechecks/workaround/__init__.py  | 6 --
 .../repoman/modules/linechecks/workaround/workarounds.py   | 7 ---
 4 files changed, 15 deletions(-)

diff --git a/repoman/cnf/linechecks/linechecks.yaml 
b/repoman/cnf/linechecks/linechecks.yaml
index 410bcd9c5..2182b467a 100644
--- a/repoman/cnf/linechecks/linechecks.yaml
+++ b/repoman/cnf/linechecks/linechecks.yaml
@@ -28,7 +28,6 @@ errors:
 PRESERVE_OLD_LIB: 'Ebuild calls deprecated preserve_old_lib'
 BUILT_WITH_USE: 'built_with_use'
 NO_OFFSET_WITH_HELPERS: 'Helper function is used with D, ROOT, ED, EROOT 
or EPREFIX'
-SANDBOX_ADDPREDICT: 'Ebuild calls addpredict'
 USEQ_ERROR: 'Ebuild calls deprecated useq function'
 HASQ_ERROR: 'Ebuild calls deprecated hasq function'
 URI_HTTPS: 'Ebuild uses http:// but should use https://'
diff --git a/repoman/cnf/repository/repository.yaml 
b/repoman/cnf/repository/repository.yaml
index 935260424..ad00d18c1 100644
--- a/repoman/cnf/repository/repository.yaml
+++ b/repoman/cnf/repository/repository.yaml
@@ -71,6 +71,5 @@ linechecks_modules:
 uselessdodoc
 whitespace
 blankline
-addpredict
 noasneeded
 
diff --git a/repoman/lib/repoman/modules/linechecks/workaround/__init__.py 
b/repoman/lib/repoman/modules/linechecks/workaround/__init__.py
index 425085a5c..694695015 100644
--- a/repoman/lib/repoman/modules/linechecks/workaround/__init__.py
+++ b/repoman/lib/repoman/modules/linechecks/workaround/__init__.py
@@ -10,12 +10,6 @@ module_spec = {
'name': 'do',
'description': doc,
'provides':{
-   'addpredict-check': {
-   'name': "addpredict",
-   'sourcefile': "workarounds",
-   'class': "SandboxAddpredict",
-   'description': doc,
-   },
'noasneeded-check': {
'name': "noasneeded",
'sourcefile': "workarounds",
diff --git a/repoman/lib/repoman/modules/linechecks/workaround/workarounds.py 
b/repoman/lib/repoman/modules/linechecks/workaround/workarounds.py
index 37cb54314..768a47e8e 100644
--- a/repoman/lib/repoman/modules/linechecks/workaround/workarounds.py
+++ b/repoman/lib/repoman/modules/linechecks/workaround/workarounds.py
@@ -9,10 +9,3 @@ class NoAsNeeded(LineCheck):
repoman_check_name = 'upstream.workaround'
re = re.compile(r'.*\$\(no-as-needed\)')
error = 'NO_AS_NEEDED'
-
-
-class SandboxAddpredict(LineCheck):
-   """Check for calls to the addpredict function."""
-   repoman_check_name = 'upstream.workaround'
-   re = re.compile(r'(^|\s)addpredict\b')
-   error = 'SANDBOX_ADDPREDICT'
-- 
2.25.1




Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Mike Gilbert
On Wed, Feb 19, 2020 at 3:41 PM Michael Jones  wrote:
>
> How does this effect systemd's socket activation?
>
> E.g. The systemd sshd.socket unit file.

Please avoid top-posting.

When socket-activated, a separate instance of sshd is spawned for each
connection. I don't think any action is needed in that case.



Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Mike Gilbert
On Wed, Feb 19, 2020 at 3:02 PM Patrick McLean  wrote:
>
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: 
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
>
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t
>
> If your system is booted with openrc, use this command  (as root)
> to restart sshd:
> /etc/init.d/sshd restart
>
> If your system is booted with systemd, use this command (as root)
> to restart sshd:
> systemctl restart sshd
>
> WARNING: On systemd booted machines, this command will terminate all currently
>  open ssh connections, it is *strongly* reccommended that you validate
>  your configuration before restarting sshd.
>

Existing connections are only terminated if the pam_systemd module is
not enabled. This might happen if the user has disabled USE=pam on
sys-apps/systemd, or if they have modified the system pam stack to
exclude pam_systemd.

Maybe change the warning to this:

WARNING: On systemd booted machines with PAM disabled, this command
will terminate all currently open ssh connections. It is *strongly*
recommended that you validate your configuration before restarting
sshd.



Re: [gentoo-dev] Changes made by acct-* ebuilds

2020-02-14 Thread Mike Gilbert
On Fri, Feb 14, 2020 at 12:42 PM Thomas Deutschmann  wrote:
>
> > # usermod -aG thomas postfix
> > # id postfix
> > uid=207(postfix) gid=207(postfix)
> groups=207(postfix),12(mail),1004(thomas)
> > # emerge -a1 acct-user/postfix
> > [...]
> >
> > >>> Installing (1 of 1) acct-user/postfix-0::gentoo
> >  * checking 0 files for package collisions
> > >>> Merging acct-user/postfix-0 to /
> > >>> Safely unmerging already-installed instance...
> > No package files given... Grabbing a set.
> > >>> Regenerating /etc/ld.so.cache...
> > >>> Original instance of package unmerged safely.
> >  * Updating groups for user 'postfix' ...
> >  *  - Groups: postfix,mail
> > >>> acct-user/postfix-0 merged.
> > >>> Auto-cleaning packages...
> >
> > [...]
> >
> > # id postfix
> > uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail)
> >

There's a significant difference between changing group membership for
a system user versus a user account that is used interactively.

I don't think the handbook advises people to mess with system accounts.



Re: [gentoo-dev] Changes made by acct-* ebuilds

2020-02-14 Thread Mike Gilbert
On Fri, Feb 14, 2020 at 9:12 AM Thomas Deutschmann 
wrote:

> On 2020-02-13 17:17, Mike Gilbert wrote:
> > I don't agree that this should be happen by default. I suspect the
> > majority of users do not wish to manage system users/groups
> > themselves.
>
> Follow handbook to get a working system and rebuild entire world. You
> will get surprised.


Could you just explain please? I’m not inclined to read through the
handbook and rebuild a system to guess what this horrible breakage might
be.

>


Re: [gentoo-dev] Changes made by acct-* ebuilds

2020-02-13 Thread Mike Gilbert
On Thu, Feb 13, 2020 at 6:24 PM Michael 'veremitz' Everitt <
gen...@veremit.xyz> wrote:

> On 13/02/20 16:17, Mike Gilbert wrote:
> > On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann 
> wrote:
> >> In short: It was a very bad decision that acct-* stuff is *changing*
> >> existing stuff. This must be turned of *by default*. Maybe provide a
> >> setting a user can put into make.conf to opt into current, still new,
> >> behavior but by default, a package should never ever make changes to
> >> *existing* user (unless it knows for sure it was the only source
> >> creating that user and nothing was changed since creation which isn't
> >> easy to track).
> > I think it would make sense to add some eclass variables that would
> > turn user.eclass functions into no-ops.
> >
> > I don't agree that this should be happen by default. I suspect the
> > majority of users do not wish to manage system users/groups
> > themselves.
> >
> I would suggest anyone competent enough to build a kernel from scratch
> (genkernel users, I'm ignoring you) should be equally at-home managing
> system users and groups and associated permissions? Or am I perhaps
> overestimating the average Genbuntu users here ... >,<
>
> I said nothing of capability. Most people don’t care to micromanage
> accounts.


Re: [gentoo-dev] Changes made by acct-* ebuilds

2020-02-13 Thread Mike Gilbert
On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann  wrote:
> In short: It was a very bad decision that acct-* stuff is *changing*
> existing stuff. This must be turned of *by default*. Maybe provide a
> setting a user can put into make.conf to opt into current, still new,
> behavior but by default, a package should never ever make changes to
> *existing* user (unless it knows for sure it was the only source
> creating that user and nothing was changed since creation which isn't
> easy to track).

I think it would make sense to add some eclass variables that would
turn user.eclass functions into no-ops.

I don't agree that this should be happen by default. I suspect the
majority of users do not wish to manage system users/groups
themselves.



Re: [gentoo-dev] [PATCH] python-single-r1.eclass: don't crash Portage with invalid USEDEP syntax

2020-02-12 Thread Mike Gilbert
On Wed, Feb 12, 2020 at 1:31 PM Michał Górny  wrote:
>
> On Wed, 2020-02-12 at 13:25 -0500, Mike Gilbert wrote:
> > This should still serve the purpose of alerting overlay maintainers
> > without making emerge completely unusable in the interim.
> >
>
> I don't understand what's the gain.  In both cases emerge won't proceed.
> However, with the original syntax the message is clearer:

A pentoo user reported an actual crash in portage when it was unable
to parse the dependency atom. See the backlog in #gentoo-qa for the
discussion.

However, I have been unable to reproduce this crash myself, so I'm
going to hold off on merging this patch until the problem can be
further diagnosed.

The portage output is below.

Calculating dependencies  ... . done!
Traceback (most recent call last):
  File "/usr/lib64/python3.6/site-packages/portage/dep/__init__.py",
line 739, in use_reduce
is_valid_flag=is_valid_flag)
  File "/usr/lib64/python3.6/site-packages/portage/dep/__init__.py",
line 1411, in __init__
use = _use_dep(use_str[1:-1].split(","), eapi_attrs)
  File "/usr/lib64/python3.6/site-packages/portage/dep/__init__.py",
line 897, in __init__
raise InvalidAtom(_("Invalid use dep: '%s'") % (x,))
portage.exception.InvalidAtom: Invalid use dep:
'%PYTHON_USEDEP-HAS-BEEN-REMOVED%'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.6/emerge", line 53, in 
retval = emerge_main()
  File "/usr/lib64/python3.6/site-packages/_emerge/main.py", line
1309, in emerge_main
return run_action(emerge_config)
  File "/usr/lib64/python3.6/site-packages/_emerge/actions.py", line
3358, in run_action
retval = action_build(emerge_config, spinner=spinner)
  File "/usr/lib64/python3.6/site-packages/_emerge/actions.py", line
357, in action_build
settings, trees, myopts, myparams, myaction, myfiles, spinner)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
9891, in backtrack_depgraph
myaction, myfiles, spinner)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
9928, in _backtrack_depgraph
success, favorites = mydepgraph.select_files(myfiles)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
3990, in select_files
return self._select_files(args)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
4333, in _select_files
return self._resolve(myfavorites)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
4484, in _resolve
if not self._create_graph():
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
2722, in _create_graph
allow_unsatisfied=allow_unsatisfied):
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
3480, in _add_pkg_deps
allow_unsatisfied):
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
3496, in _add_pkg_dep_string
allow_unsatisfied)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
3576, in _wrapped_add_pkg_dep_string
pkg, dep_priority, root_config, selected_atoms[pkg]):
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
3775, in _minimize_children
root_config.root, atom, parent=parent)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
5775, in _select_pkg_highest_available
ret = self._select_pkg_highest_available_imp(root, atom,
onlydeps=onlydeps, parent=parent)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
6003, in _select_pkg_highest_available_imp
root, atom, onlydeps=onlydeps, parent=parent)
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
6600, in _wrapped_select_pkg_highest_available_imp
self._changed_deps(pkg))):
  File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line
2697, in _changed_deps
eapi=ebuild.eapi, token_class=Atom)
  File "/usr/lib64/python3.6/site-packages/portage/dep/__init__.py",
line 744, in use_reduce
% (e, pos+1), errors=(e,))
portage.exception.InvalidDependString: Invalid atom (Invalid use dep:
'%PYTHON_USEDEP-HAS-BEEN-REMOVED%'), token 6



[gentoo-dev] [PATCH] python-single-r1.eclass: don't crash Portage with invalid USEDEP syntax

2020-02-12 Thread Mike Gilbert
This should still serve the purpose of alerting overlay maintainers
without making emerge completely unusable in the interim.

Signed-off-by: Mike Gilbert 
---
 eclass/python-single-r1.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/python-single-r1.eclass b/eclass/python-single-r1.eclass
index 739a394ddd18..971adba42c5f 100644
--- a/eclass/python-single-r1.eclass
+++ b/eclass/python-single-r1.eclass
@@ -249,7 +249,7 @@ _python_single_set_globals() {
else
PYTHON_DEPS=${deps}
PYTHON_REQUIRED_USE=${requse}
-   PYTHON_USEDEP='%PYTHON_USEDEP-HAS-BEEN-REMOVED%'
+   PYTHON_USEDEP='PYTHON_USEDEP-HAS-BEEN-REMOVED'
PYTHON_SINGLE_USEDEP=${single_usedep}
readonly PYTHON_DEPS PYTHON_REQUIRED_USE PYTHON_SINGLE_USEDEP \
PYTHON_USEDEP
-- 
2.25.0




[gentoo-portage-dev] [PATCH] phase-helpers.sh: avoid passing an empty root value to portageq

2020-02-08 Thread Mike Gilbert
Bug: https://bugs.gentoo.org/708660
Signed-off-by: Mike Gilbert 
---
 bin/phase-helpers.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 020862ba0..3deb28c68 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -878,7 +878,7 @@ ___best_version_and_has_version_common() {
if ___eapi_has_prefix_variables; then
case ${root_arg} in
-r) root=${ROOT%/}/${EPREFIX#/} ;;
-   -d) root=${ESYSROOT} ;;
+   -d) root=${ESYSROOT:-/} ;;
-b)
# Use 
/${PORTAGE_OVERRIDE_EPREFIX#/} which is equivalent
# to BROOT, except BROOT is 
only defined in src_* phases.
@@ -888,8 +888,8 @@ ___best_version_and_has_version_common() {
esac
else
case ${root_arg} in
-   -r) root=${ROOT} ;;
-   -d) root=${SYSROOT} ;;
+   -r) root=${ROOT:-/} ;;
+   -d) root=${SYSROOT:-/} ;;
-b) root=/ ;;
esac
fi ;;
-- 
2.25.0




Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

2020-02-07 Thread Mike Gilbert
On Fri, Feb 7, 2020 at 2:39 PM Ulrich Mueller  wrote:
>
> > On Fri, 07 Feb 2020, Matt Turner wrote:
>
> > On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano  wrote:
> >>
> >> # Mike Pagano  (2020-02-07)
> >> # The standalone ebuild for this driver is made
> >> # unnecessary as it is included in the package:
> >> # sys-kernel/linux-firmware
> >> sys-firmware/iwl6050-ucode
>
> > How about all the others as well?
>
> > sys-firmware/iwl1000-ucode
> > sys-firmware/iwl3160-7260-bt-ucode
> > sys-firmware/iwl3160-ucode
> > sys-firmware/iwl6005-ucode
> > sys-firmware/iwl6030-ucode
> > sys-firmware/iwl7260-ucode
> > sys-firmware/iwl8000-ucode
>
> I had asked the same question back in November, but an argument against
> it was that sys-kernel/linux-firmware is quite a monster. In the default
> configuration, its installation footprint is 515 MiB.
>
> But yeah, either we should keep them all or remove them all.

It looks like several different people maintain the individual
iwl-ucode packages.

Removing them all would require some consensus among those maintainers.

Keeping them all means forcing maintainers to work on stuff they don't
care about, or will result in stuff getting dropped to
maintainer-needed.



[gentoo-dev] [PATCH] user.eclass: move read-only functionality to user-info.eclass

2020-02-05 Thread Mike Gilbert
The new eclass can be used by ebuilds to look up user information
without triggering a deprecation warning from repoman and pkgcheck.

Signed-off-by: Mike Gilbert 
---
 eclass/user-info.eclass | 158 
 eclass/user.eclass  | 149 +
 2 files changed, 161 insertions(+), 146 deletions(-)
 create mode 100644 eclass/user-info.eclass

diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
new file mode 100644
index ..ea037d54dfdd
--- /dev/null
+++ b/eclass/user-info.eclass
@@ -0,0 +1,158 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: user-info.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org (Linux)
+# Michał Górny  (NetBSD)
+# @BLURB: Read-only access to user and group information
+
+if [[ -z ${_USER_INFO_ECLASS} ]]; then
+_USER_INFO_ECLASS=1
+
+# @FUNCTION: egetent
+# @USAGE:  
+# @DESCRIPTION:
+# Small wrapper for getent (Linux), nidump (< Mac OS X 10.5),
+# dscl (Mac OS X 10.5), and pw (FreeBSD) used in enewuser()/enewgroup().
+#
+# Supported databases: group passwd
+egetent() {
+   local db=$1 key=$2
+
+   [[ $# -ge 3 ]] && die "usage: egetent  "
+
+   case ${db} in
+   passwd|group) ;;
+   *) die "sorry, database '${db}' not yet supported; file a bug" ;;
+   esac
+
+   case ${CHOST} in
+   *-freebsd*|*-dragonfly*)
+   case ${db} in
+   passwd) db="user" ;;
+   *) ;;
+   esac
+
+   # lookup by uid/gid
+   local opts
+   if [[ ${key} == [[:digit:]]* ]] ; then
+   [[ ${db} == "user" ]] && opts="-u" || opts="-g"
+   fi
+
+   pw show ${db} ${opts} "${key}" -q
+   ;;
+   *-openbsd*)
+   grep "${key}:\*:" /etc/${db}
+   ;;
+   *)
+   # ignore nscd output if we're not running as root
+   type -p nscd >/dev/null && nscd -i "${db}" 2>/dev/null
+   getent "${db}" "${key}"
+   ;;
+   esac
+}
+
+# @FUNCTION: egetusername
+# @USAGE: 
+# @DESCRIPTION:
+# Gets the username for given UID.
+egetusername() {
+   [[ $# -eq 1 ]] || die "usage: egetusername "
+
+   egetent passwd "$1" | cut -d: -f1
+}
+
+# @FUNCTION: egetgroupname
+# @USAGE: 
+# @DESCRIPTION:
+# Gets the group name for given GID.
+egetgroupname() {
+   [[ $# -eq 1 ]] || die "usage: egetgroupname "
+
+   egetent group "$1" | cut -d: -f1
+}
+
+# @FUNCTION: egethome
+# @USAGE: 
+# @DESCRIPTION:
+# Gets the home directory for the specified user.
+egethome() {
+   local pos
+
+   [[ $# -eq 1 ]] || die "usage: egethome "
+
+   case ${CHOST} in
+   *-freebsd*|*-dragonfly*)
+   pos=9
+   ;;
+   *)  # Linux, NetBSD, OpenBSD, etc...
+   pos=6
+   ;;
+   esac
+
+   egetent passwd "$1" | cut -d: -f${pos}
+}
+
+# @FUNCTION: egetshell
+# @USAGE: 
+# @DESCRIPTION:
+# Gets the shell for the specified user.
+egetshell() {
+   local pos
+
+   [[ $# -eq 1 ]] || die "usage: egetshell "
+
+   case ${CHOST} in
+   *-freebsd*|*-dragonfly*)
+   pos=10
+   ;;
+   *)  # Linux, NetBSD, OpenBSD, etc...
+   pos=7
+   ;;
+   esac
+
+   egetent passwd "$1" | cut -d: -f${pos}
+}
+
+# @FUNCTION: egetcomment
+# @USAGE: 
+# @DESCRIPTION:
+# Gets the comment field for the specified user.
+egetcomment() {
+   local pos
+
+   [[ $# -eq 1 ]] || die "usage: egetshell "
+
+   case ${CHOST} in
+   *-freebsd*|*-dragonfly*)
+   pos=8
+   ;;
+   *)  # Linux, NetBSD, OpenBSD, etc...
+   pos=5
+   ;;
+   esac
+
+   egetent passwd "$1" | cut -d: -f${pos}
+}
+
+# @FUNCTION: egetgroups
+# @USAGE: 
+# @DESCRIPTION:
+# Gets all the groups user belongs to.  The primary group is returned
+# first, then all supplementary groups.  Groups are ','-separated.
+egetgroups() {
+   [[ $# -eq 1 ]] || die "usage: egetgroups "
+
+   local egroups_arr
+   read -r -a egroups_arr < <(id -G -n "$1")
+
+   local g groups=${egroups_arr[0]}
+   # sort supplementary groups to make comparison possible
+   while read -r g; do
+   [[ -n ${g} ]] && groups+=",${g}"
+   done < <(printf '%s\n' "${egroups_arr[@]:1}" | sort)
+   echo "${groups}"
+}
+
+fi
diff --git a/eclass/user.eclass b/eclass/user.eclass
index f433d32bf7ed..9bd0b607eab8 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -1,4 +1,4 @@

[gentoo-portage-dev] [PATCH] Include the category when we suggest running "emerge ... portage"

2020-01-31 Thread Mike Gilbert
This will prevent problems if another package named "portage" is added
in another category.

Signed-off-by: Mike Gilbert 
---
 lib/portage/emaint/modules/sync/sync.py| 2 +-
 lib/portage/package/ebuild/deprecated_profile_check.py | 2 +-
 man/emerge.1   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/portage/emaint/modules/sync/sync.py 
b/lib/portage/emaint/modules/sync/sync.py
index e28c42336..ac37fdcfa 100644
--- a/lib/portage/emaint/modules/sync/sync.py
+++ b/lib/portage/emaint/modules/sync/sync.py
@@ -299,7 +299,7 @@ class SyncRepos(object):
msgs.append(warn(" * ")+bold("An update to portage is 
available.")+" It is _highly_ recommended")
msgs.append(warn(" * ")+"that you update portage now, 
before any other packages are updated.")
msgs.append('')
-   msgs.append(warn(" * ")+"To update portage, run 'emerge 
--oneshot portage' now.")
+   msgs.append(warn(" * ")+"To update portage, run 'emerge 
--oneshot sys-apps/portage' now.")
msgs.append('')
return msgs
 
diff --git a/lib/portage/package/ebuild/deprecated_profile_check.py 
b/lib/portage/package/ebuild/deprecated_profile_check.py
index fdb19b4ac..abf32a079 100644
--- a/lib/portage/package/ebuild/deprecated_profile_check.py
+++ b/lib/portage/package/ebuild/deprecated_profile_check.py
@@ -77,7 +77,7 @@ def deprecated_profile_check(settings=None):
"can migrate to the above profile.")), 
noiselevel=-1)
writemsg(" %s %s\n\n" % (colorize("WARN", "*"),
_("In order to update portage, "
-   "run 'emerge --oneshot portage'.")),
+   "run 'emerge --oneshot 
sys-apps/portage'.")),
noiselevel=-1)
 
return True
diff --git a/man/emerge.1 b/man/emerge.1
index 4ce0dbebc..2261a771b 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -319,7 +319,7 @@ finished calculating the graph.
 
 \fB--alert\fR may be 'y' or 'n'. 'true' and 'false' mean the same thing.
 Using \fB--alert\fR without an option is the same as using it with 'y'.
-Try it with 'emerge -aA portage'.
+Try it with 'emerge -aA sys-apps/portage'.
 
 If your terminal emulator is set up to make '\\a' into a window manager
 urgency hint, move your cursor to a different window to get the effect.
@@ -1294,7 +1294,7 @@ permanent, you can put them in /etc/portage/package.use 
instead.
 If \fBemerge \-\-update @system\fR or \fBemerge \-\-update @world\fR
 fails with an error message, it may be that an ebuild uses some
 newer feature not present in this version of \fBemerge\fR.  You
-can use \fBemerge \-\-update portage\fR to upgrade to the lastest
+can use \fBemerge \-\-update sys-apps/portage\fR to upgrade to the lastest
 version, which should support any necessary new features.
 .SH "MASKED PACKAGES"
 \fINOTE: Please use caution when using development packages.  Problems
-- 
2.25.0




[gentoo-dev] Last rites: app-admin/cli53

2020-01-20 Thread Mike Gilbert
# Mike Gilbert  (2020-01-20)
# Newer versions are using Go modules, which makes this more difficult to
# maintain. Take this over if wanted, otherwise I will remove it in 30 days.
app-admin/cli53



[gentoo-dev] Last rites: dev-python/transmissionrpc

2020-01-12 Thread Mike Gilbert
# Mike Gilbert  (2020-01-12)
# No upstream activity since 2014, no reverse deps.
# Remove in 30 days.
dev-python/transmissionrpc



Re: [gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-06 Thread Mike Gilbert
On Mon, Jan 6, 2020 at 12:54 PM Michał Górny  wrote:
>
> On Mon, 2020-01-06 at 12:43 -0500, Mike Gilbert wrote:
> > On Sun, Jan 5, 2020 at 1:27 AM Michał Górny  wrote:
> > > +# @FUNCTION: kernel-build_src_configure
> > > +# @DESCRIPTION:
> > > +# Prepare the toolchain for building the kernel, get the default .config
> > > +# or restore savedconfig, and get build tree configured for modprep.
> > > +kernel-build_src_configure() {
> > > +   debug-print-function ${FUNCNAME} "${@}"
> > > +
> > > +   # force ld.bfd if we can find it easily
> > > +   local LD="$(tc-getLD)"
> > > +   if type -P "${LD}.bfd" &>/dev/null; then
> > > +   LD+=.bfd
> > > +   fi
> >
> > Is there some reason not to use the tc-ld-disable-gold function?
> >
>
> Yes.  As the name says, it covers gold usage only and not lld.

It might be a good idea to copy this logic to handle multi-word LD values.

https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain-funcs.eclass#n498

Or, a nicer alternative would be to refactor tc-ld-disable-gold into 2
functions: move most of the logic into a new function
"tc-ld-force-bfd", and update tc-ld-disable-gold to call the former if
tc-ld-is-gold is true. I can write a patch for that if you agree.



Re: [gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-06 Thread Mike Gilbert
On Sun, Jan 5, 2020 at 1:27 AM Michał Górny  wrote:
> +# @FUNCTION: kernel-build_src_configure
> +# @DESCRIPTION:
> +# Prepare the toolchain for building the kernel, get the default .config
> +# or restore savedconfig, and get build tree configured for modprep.
> +kernel-build_src_configure() {
> +   debug-print-function ${FUNCNAME} "${@}"
> +
> +   # force ld.bfd if we can find it easily
> +   local LD="$(tc-getLD)"
> +   if type -P "${LD}.bfd" &>/dev/null; then
> +   LD+=.bfd
> +   fi

Is there some reason not to use the tc-ld-disable-gold function?



Re: [gentoo-dev] [PATCH 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-04 Thread Mike Gilbert
On Sat, Jan 4, 2020 at 4:24 PM Michał Górny  wrote:
> +# @FUNCTION: kernel-build_src_configure
> +# @DESCRIPTION:
> +# Prepare the toolchain for building the kernel, get the default .config
> +# or restore savedconfig, and get build tree configured for modprep.
> +kernel-build_src_configure() {
> +   debug-print-function ${FUNCNAME} "${@}"
> +
> +   # force ld.bfd if we can find it easily
> +   local LD="$(tc-getLD)"
> +   if type -P "${LD}.bfd" &>/dev/null; then
> +   LD+=.bfd
> +   fi
> +
> +   MAKEARGS=(
> +   V=1
> +
> +   HOSTCC="$(tc-getCC)"
> +   HOSTCXX="$(tc-getCXX)"
> +   HOSTCFLAGS="${CFLAGS}"
> +   HOSTLDFLAGS="${LDFLAGS}"

I think the HOST variables should reference the CBUILD toolchain. Example below.

# Sets BUILD_CFLAGS and BUILD_LDFLAGS if not set in make.conf.
tc-export_build_env

HOSTCC="$(tc-getBUILD_CC)"
HOSTCXX="$(tc-getBUILD_CXX)"
HOSTCFLAGS="${BUILD_CFLAGS}"
HOSTLDFLAGS="${BUILD_LDFLAGS}"



  1   2   3   4   5   6   7   8   9   10   >