Re: [gentoo-dev] last rites dev-go/blackfriday

2021-12-15 Thread William Hubbs
Resending this to fix the date.

# William Hubbs  (2021-12-15)
# This is a go module and is included in projects directly.
# Bug #819639; masked for removal on 2022-01-15.
dev-go/blackfriday

Thanks,
 
William
> 




signature.asc
Description: PGP signature


[gentoo-dev] last rites dev-go/blackfriday

2021-12-15 Thread William Hubbs
# William Hubbs  (2021-12-15)
# This is a go module and is included in projects directly.
# Bug #819639; masked for removal on 2022-12-15.
dev-go/blackfriday

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

2021-12-11 Thread William Hubbs
This is committed.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] tmpfiles.eclass: add eapi 8 support

2021-12-11 Thread William Hubbs
This is in the tree.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-30 Thread William Hubbs
On Tue, Nov 30, 2021 at 12:59:18PM +0100, Ulrich Mueller wrote:
> > On Tue, 30 Nov 2021, James Cloos wrote:
> 
> > "UM" == Ulrich Mueller  writes:
> UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
> UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.
> 
> > why do you thing gentoo is everyone's first or only dist on their
> > network?
> 
> > or even on any given box?
> 
> I was specifically asking about Gentoo infra there.
> 
> > forcing existing boxen to change just because a new dist is added
> > is also unacceptable.
> 
> > for me though, it would be enough if there is something i can add to
> > make.conf to ensure that the acct-user and acct-group builds avoid the
> > ranges i already use.
> 
> > that may also work for others.
> 
> UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
> used for dynamic allocation of system accounts. GLEP 81 hasn't really
> changed anything there, except that the ebuild will now suggest an ID to
> try first.

This is the part of this that I don't understand. If we aren't enforcing
an ID, why do we care which ID to try first? It seems to be an
unnecessary step since users can pick the IDs they want by putting
settings in make.conf.

William


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] tmpfiles.eclass: add eapi 8 support

2021-11-30 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/tmpfiles.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
index b9238a6434a..7a0e2cb7265 100644
--- a/eclass/tmpfiles.eclass
+++ b/eclass/tmpfiles.eclass
@@ -8,7 +8,7 @@
 # @AUTHOR:
 # Mike Gilbert 
 # William Hubbs 
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: Functions related to tmpfiles.d files
 # @DESCRIPTION:
 # This eclass provides functionality related to installing and
@@ -56,7 +56,7 @@ if [[ -z ${TMPFILES_ECLASS} ]]; then
 TMPFILES_ECLASS=1
 
 case "${EAPI}" in
-5|6|7) ;;
+5|6|7|8) ;;
 *) die "API is undefined for EAPI ${EAPI}" ;;
 esac
 
-- 
2.32.0




[gentoo-dev] last rites: net-vpn/badvpn

2021-11-30 Thread William Hubbs
# William Hubbs  (2021-11-30)
# Dead upstream, no releases since 2015
# Bug #770619; masked for removal on 2021-12-30.
net-vpn/badvpn

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-28 Thread William Hubbs
All,

I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
for all acct-user and acct-group packages in ::gentoo.

Here are my thoughts about it.

- As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
  most of the time.

- I realize that our settings are suggestions, but the values we can
  suggest are not infinite. We have run out once, and it is only a matter of
  time until we do again.

- If an end user needs to care about the UID/GID, they can easily override
  the settings in make.conf.

In short, I don't think we should be forcing maintainers to pick a
specific UID/GID for every package that needs a user/group. Most of the
time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.

Thoughts? In particular, I want to hear from folks who disagree with me
about using -1 in the main tree for most packages.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread William Hubbs
On Sun, Nov 28, 2021 at 02:46:24PM -0600, William Hubbs wrote:
> On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote:
> > On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> > > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > > > 
> > > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > > > nowadays
> > > > > > 2/ We cant keep adding new IDs to a distribution as new software 
> > > > > > gets
> > > > > > added - one side is unbounded.  This is losing game.
> > > > 
> > > > Not sure. In practice, the number of packages is limited. (And if the
> > > > argument was valid, it would apply to dynamic alloction too.)
> > > > 
> > > > > > Switching back to dynamic allocation seems to be the best option.
> > > > 
> > > > > I realize I'm very late to this party, but +1 from me also.
> > > > 
> > > > > We should use dynamic uid/git assignment by default and maybe provide
> > > > > a way to force certain uids/gids to be constant if users want this.
> > > > 
> > > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > > is rather weak, several people had argued in favour of it on the mailing
> > > > list [2].
> > > > 
> > > > In any case, let's cross that bridge when we reach it. For now, we're
> > > > good with 250 additional IDs.
> > > 
> > > It is inevitable that we will reach this bridge again -- whether or not
> > > it is in a month or a year, it will happen.
> > > 
> > > Why are we just kicking the can down the road instead of admitting that
> > > static allocation wasn't a good idea and going back to dynamic
> > > allocation? Let's find out what the people who argued for static
> > > allocation think.
> > > 
> > 
> > Why are you assuming that something "wasn't a good idea" just because
> > you think so?
> 
> ulm and others on the thread also mentioned the possibility of going
> back to dynamic allocation, so it isn't just me who brought it up.
> 
> I honestly am just looking for a discussion.
> 
> Do other distros statically allocate all of their system users? If not,
> why do we by default? I understand why enterprise users might need to,
> and they can with the glep 81 eclasses by setting uids/gids in
> make.conf, but is there a reason we force the issue at the distro level
> and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID?
> 
> William
> 


Ok, based on floppym's response, I'm going to start a new thread.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread William Hubbs
On Sun, Nov 28, 2021 at 02:42:23PM -0600, Gordon Pettey wrote:
> On Sun, Nov 28, 2021 at 2:27 PM William Hubbs  wrote:
> 
> > On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > > We don't even do static allocation.
> 
> > There are a few exceptional cases where a user or group needs a
> > > specific identifier; but those were always statically allocated and
> > > nothing has changed in that regard.
> >
> > Doesn't the emerge fail if a different user with ACCT_USER_ID already
> > exists on
> > the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa
> > policy)?
> >
> > If that's the case I don't see how we aren't doing static allocation.
> >
> 
> User PoV when I see a bunch of acct-* packages pop up in emerge @world
> updates:
> 
> A bunch of of acct-* ebuilds make claims for specific uid/gid for
> applications
> that don't have a reason I can think of to be requiring a specific number,
> and
> would never be used in a way (e.g. NFS-shared /etc) where the numeric
> value actually matters.

That's because qa mandates that any acct-group/acct-user packages in the
tree must claim a uid/gid.

Ultimately, we will run out of uids/gids to claim.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread William Hubbs
On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote:
> On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > > 
> > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > > nowadays
> > > > > 2/ We cant keep adding new IDs to a distribution as new software gets
> > > > > added - one side is unbounded.  This is losing game.
> > > 
> > > Not sure. In practice, the number of packages is limited. (And if the
> > > argument was valid, it would apply to dynamic alloction too.)
> > > 
> > > > > Switching back to dynamic allocation seems to be the best option.
> > > 
> > > > I realize I'm very late to this party, but +1 from me also.
> > > 
> > > > We should use dynamic uid/git assignment by default and maybe provide
> > > > a way to force certain uids/gids to be constant if users want this.
> > > 
> > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > is rather weak, several people had argued in favour of it on the mailing
> > > list [2].
> > > 
> > > In any case, let's cross that bridge when we reach it. For now, we're
> > > good with 250 additional IDs.
> > 
> > It is inevitable that we will reach this bridge again -- whether or not
> > it is in a month or a year, it will happen.
> > 
> > Why are we just kicking the can down the road instead of admitting that
> > static allocation wasn't a good idea and going back to dynamic
> > allocation? Let's find out what the people who argued for static
> > allocation think.
> > 
> 
> Why are you assuming that something "wasn't a good idea" just because
> you think so?

ulm and others on the thread also mentioned the possibility of going
back to dynamic allocation, so it isn't just me who brought it up.

I honestly am just looking for a discussion.

Do other distros statically allocate all of their system users? If not,
why do we by default? I understand why enterprise users might need to,
and they can with the glep 81 eclasses by setting uids/gids in
make.conf, but is there a reason we force the issue at the distro level
and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID?

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread William Hubbs
On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> > 
> > While the rationale for static allocation that made it into GLEP 81 [1]
> > is rather weak, several people had argued in favour of it on the mailing
> > list [2].
> > 
> 
> We don't even do static allocation. The UIDs and GIDs in the ebuilds
> are suggestions, meant to benefit the people who will benefit from
> them, and be ignored by everyone else.
> 
> There are a few exceptional cases where a user or group needs a
> specific identifier; but those were always statically allocated and
> nothing has changed in that regard.

Doesn't the emerge fail if a different user with ACCT_USER_ID already exists on
the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa policy)?

If that's the case I don't see how we aren't doing static allocation.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

2021-11-28 Thread William Hubbs
On Sun, Nov 28, 2021 at 11:23:16AM -0800, Zac Medico wrote:
> On 11/21/21 02:57, Florian Schmaus wrote:
> > Following the pattern found in other eclasses, add GO_OPTIONAL to the
> > go-module eclass. This allows to inherit the eclass without pulling
> > its dependencies. See, e.g., bug #775779 for the motivation.
> > 
> > Signed-off-by: Florian Schmaus 
> > ---
> >   eclass/go-module.eclass | 31 ++-
> >   1 file changed, 22 insertions(+), 9 deletions(-)
> > 
> > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> > index 3ad8542a28ae..c9eb90ac62ea 100644
> > --- a/eclass/go-module.eclass
> > +++ b/eclass/go-module.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 2019-2020 Gentoo Authors
> > +# Copyright 2019-2021 Gentoo Authors
> >   # Distributed under the terms of the GNU General Public License v2
> >   
> >   # @ECLASS: go-module.eclass
> > @@ -55,13 +55,17 @@ if [[ -z ${_GO_MODULE} ]]; then
> >   
> >   _GO_MODULE=1
> >   
> > -BDEPEND=">=dev-lang/go-1.12"
> > +if [[ ! ${GO_OPTIONAL} ]]; then
> > +   BDEPEND=">=dev-lang/go-1.12"
> >   
> > -# Workaround for pkgcheck false positive: 
> > https://github.com/pkgcore/pkgcheck/issues/214
> > -# MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
> > -# Added here rather than to each affected package, so it can be cleaned up 
> > just
> > -# once when pkgcheck is improved.
> > -BDEPEND+=" app-arch/unzip"
> > +   # Workaround for pkgcheck false positive: 
> > https://github.com/pkgcore/pkgcheck/issues/214
> > +   # MissingUnpackerDep: version ...: missing BDEPEND="app-arch/unzip"
> > +   # Added here rather than to each affected package, so it can be cleaned 
> > up just
> > +   # once when pkgcheck is improved.
> > +   BDEPEND+=" app-arch/unzip"
> > +
> > +   EXPORT_FUNCTIONS src_unpack
> > +fi
> >   
> >   # Force go to build in module mode.
> >   # In this mode the GOPATH environment variable is ignored.
> > @@ -83,8 +87,6 @@ QA_FLAGS_IGNORED='.*'
> >   # Go packages should not be stripped with strip(1).
> >   RESTRICT+=" strip"
> >   
> > -EXPORT_FUNCTIONS src_unpack
> > -
> >   # @ECLASS-VARIABLE: EGO_SUM
> >   # @DESCRIPTION:
> >   # This is an array based on the go.sum content from inside the target 
> > package.
> > @@ -147,6 +149,17 @@ EXPORT_FUNCTIONS src_unpack
> >   # directory structure.
> >   declare -A -g _GOMODULE_GOSUM_REVERSE_MAP
> >   
> > +# @ECLASS-VARIABLE: GO_OPTIONAL
> > +# @DEFAULT_UNSET
> > +# @PRE_INHERIT
> > +# @DESCRIPTION:
> > +# If set to a non-null value before inherit, then the Go part of the
> > +# ebuild will be considered optional. No dependencies will be added and
> > +# no phase functions will be exported.
> > +#
> > +# If you enable GO_OPTIONAL, you have to set BDEPEND on >=dev-lang/go-1.12
> > +# for your package and call go-module_src_unpack manually.
> > +
> >   # @FUNCTION: go-module_set_globals
> >   # @DESCRIPTION:
> >   # Convert the information in EGO_SUM for other usage in the ebuild.
> > 
> 
> How about if we also add a GO_DEPEND variable, so that eclasshi 
> consumers can do something like BDEPEND="go? ( ${GO_DEPEND} )" ?
> -- 
> Thanks,
> Zac

this is on my radar. I haven't read the bug yet, but I'll look at it, if
not today, sometime this week.

Without looking at the bug, I'm not sure why you would want to use this
eclass without depending on dev-lang/go.

Also, if you have to write src_unpack you can call go-module_setup_proxy
in src_unpack to set things up.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread William Hubbs
On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> >>>>> On Sun, 28 Nov 2021, William Hubbs wrote:
> 
> > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> >> 1/ Static allocation does not really solve a problem. Not really not
> >> nowadays
> >> 2/ We cant keep adding new IDs to a distribution as new software gets
> >> added - one side is unbounded.  This is losing game.
> 
> Not sure. In practice, the number of packages is limited. (And if the
> argument was valid, it would apply to dynamic alloction too.)
> 
> >> Switching back to dynamic allocation seems to be the best option.
> 
> > I realize I'm very late to this party, but +1 from me also.
> 
> > We should use dynamic uid/git assignment by default and maybe provide
> > a way to force certain uids/gids to be constant if users want this.
> 
> While the rationale for static allocation that made it into GLEP 81 [1]
> is rather weak, several people had argued in favour of it on the mailing
> list [2].
> 
> In any case, let's cross that bridge when we reach it. For now, we're
> good with 250 additional IDs.

It is inevitable that we will reach this bridge again -- whether or not
it is in a month or a year, it will happen.

Why are we just kicking the can down the road instead of admitting that
static allocation wasn't a good idea and going back to dynamic
allocation? Let's find out what the people who argued for static
allocation think.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-27 Thread William Hubbs
On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> On Sun, Nov 14, 2021 at 09:15:36PM +0100, Thomas Deutschmann wrote:
> > On 2021-11-11 11:59, Ulrich Mueller wrote:
> > > We could:
> > > 
> > > - Open some part of the range between 500 and 1000. For example,
> > >500..799, which would leave 200 IDs for dynamic allocation.
> > > 
> > > - Open part of the range 60001..65533. Not sure if all software will be
> > >happy with that.
> > > 
> > > - Admit that the concept of static allocation has failed, and return to
> > >dynamic allocation.
> > 
> > Only the third option is really possible.
> 
> FWIW, I agree with this sentiment.
> 
> 1/ Static allocation does not really solve a problem. Not really not
> nowadays
> 2/ We cant keep adding new IDs to a distribution as new software gets
> added - one side is unbounded.  This is losing game.
> 
> Switching back to dynamic allocation seems to be the best option.
> 
> -- 
> Eray
> 

I realize I'm very late to this party, but +1 from me also.

We should use dynamic uid/git assignment by default and maybe provide a
way to force certain uids/gids to be constant if users want this.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only

2021-10-16 Thread William Hubbs
On Thu, Oct 14, 2021 at 03:40:02PM +0200, Marek Szuba wrote:
> Dear everyone,
> 
> Following some private discussions, I feel quite strongly now that it 
> would both considerably improve certain processes and make our use of 
> limited manpower more efficient were we to further reduce the number of 
> stable arches in Gentoo Linux. Specifically, I propose to drop
>   - hppa,
>   - ppc,
>   - sparc,
>   - x86
> to ~arch-only status.
> 
> Note that this does NOT mean we intend to drop support for those arches 
> altogether.
> 
> There are IMHO several good reasons for this:
>   - most of the arches from this list are quite dated and either aren't 
> really developed upstream any more or got superseded by newer ones (for 
> the record, it's been 18 years since the first amd64 CPUs came out)
>   - we have got very few people actually supporting these arches, and in 
> case of hppa there is also the hardware bottleneck. Subsequently, 
> stabilisation requests often take a long time to resolve
>   - feedback we receive, e.g. by Bugzilla, suggests that Gentoo on at 
> least some of these arches have got very, very few users
>   - last but by no means least, my personal experience from the last 
> several years suggests that running ~arch is reasonably trouble-free 
> these days
> 
> WDYT?

For the record, I'm fine with this.

x86 being on the list sort of caught my attention, but it does seem to
fall into the superceeded category, so it should be fine.

Even though running ~arch may be mostly trouble-free, this isn't really
relevant to the discussion imo. If you run ~arch, you should be prepared
for possible breakage at any time and be able to recover from it.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] Package up for grabs: >=app-emulation/docker-compose-2.0.0 (1.x.x was Python, 2.0.0 is Go)

2021-09-30 Thread William Hubbs
On Wed, Sep 29, 2021 at 12:52:52AM +0200, Sebastian Pipping wrote:
> Hi!
> 
> docker-compose upstream has apparently re-written docker-compose in
> Golang from scratch.  While I'm happy to keep maintaining the current
> python-based  someone to take over Go packaging of docker-compose >=2.0.0 in Gentoo.
> Thanks in advance!

I'll take this; I'm also co-maintaining the docker/runc/containerd
stack.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/9] drop the go-module_pkg_postinst function

2021-09-01 Thread William Hubbs
On Sun, Aug 29, 2021 at 11:33:17AM -0500, William Hubbs wrote:
> It seems to me that we don't need this function any longer since the go
> ebuild displays a message when it is upgraded or downgraded explaining
> how to rebuild go packages, so I would like to remove it.
> 
> This patch series contains all of the changes I could find that need to
> happen to allow the removal.

This series has been added to the tree.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] go-module.eclass: drop --mod=readonly from GOFLAGS

2021-09-01 Thread William Hubbs
On Sat, Aug 28, 2021 at 08:12:53PM -0500, William Hubbs wrote:
> As of go 1.16, --mod=readonly is the default, so we don't need to
> specify it.
> https://golang.org/ref/mod#build-commands
> https://golang.org/doc/go1.16
> 
> Signed-off-by: William Hubbs 
> ---
>  eclass/go-module.eclass | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

This is in the tree.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] The inherit-EXPORT_FUNCTIONS ordering problem

2021-08-29 Thread William Hubbs
On Sat, Aug 28, 2021 at 06:35:06PM +0200, Michał Górny wrote:
> Hi,
> 
> I've been informed of a slight inconsistency in package manager behavior
> that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks
> for the report!).  Please consider the three following snippets:
 
 ...

> 1. I'd like to propose that we explicitly require all inherits to happen
> before EXPORT_FUNCTIONS.  This will ensure consistent behavior across
> all package managers.
> 
> 2. I'd like to ask your opinion whether we should:
> 
> a. revert the Portage behavior to be consistent with PkgCore/Paludis
> 
> b. update PMS to identify the behavior as 'undefined', i.e. either
> solution is correct.

I would go with 1 and 2 b, but I also propose another option for the
next eapi which may be a bit controversial.

Starting with eapi 9, make export_functions a noop (you can't remove it
until all eclasses/ebuilds only support eapis that don't require it).

I understand that this is controversial, because it would require a lot
of work to convert ebuilds to eapi 9, but it would eliminate this
ambiguity/inconsistency in the future because it would require all
ebuilds to have phase functions unless they can use the default phases
the eapis provide.

Thoughts?

William

> 
> WDYT?
> 
> 
> [1] 
> https://github.com/gentoo/portage/commit/06d4433e8b8be60d606733b9e23f57f8a5869d8f
> 
> -- 
> Best regards,
> Michał Górny
> 
> 
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH 2/9] app-metrics/blackbox_exporter: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 .../blackbox_exporter/blackbox_exporter-0.19.0.ebuild| 5 -
 1 file changed, 5 deletions(-)

diff --git a/app-metrics/blackbox_exporter/blackbox_exporter-0.19.0.ebuild 
b/app-metrics/blackbox_exporter/blackbox_exporter-0.19.0.ebuild
index fd11adf7117..6a621d733a1 100644
--- a/app-metrics/blackbox_exporter/blackbox_exporter-0.19.0.ebuild
+++ b/app-metrics/blackbox_exporter/blackbox_exporter-0.19.0.ebuild
@@ -506,8 +506,3 @@ src_install() {
insinto /etc/logrotate.d
newins "${FILESDIR}/${PN}.logrotated" "${PN}"
 }
-
-pkg_postinst() {
-   fcaps_pkg_postinst
-   go-module_pkg_postinst
-}
-- 
2.31.1




[gentoo-dev] [PATCH 7/9] www-apps/gitea: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 www-apps/gitea/gitea-1.14.6.ebuild | 1 -
 www-apps/gitea/gitea-.ebuild   | 1 -
 2 files changed, 2 deletions(-)

diff --git a/www-apps/gitea/gitea-1.14.6.ebuild 
b/www-apps/gitea/gitea-1.14.6.ebuild
index c1bc0be80fa..38cd614841a 100644
--- a/www-apps/gitea/gitea-1.14.6.ebuild
+++ b/www-apps/gitea/gitea-1.14.6.ebuild
@@ -124,6 +124,5 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
tmpfiles_process gitea.conf
 }
diff --git a/www-apps/gitea/gitea-.ebuild b/www-apps/gitea/gitea-.ebuild
index 6a4eaea9959..912d2f81957 100644
--- a/www-apps/gitea/gitea-.ebuild
+++ b/www-apps/gitea/gitea-.ebuild
@@ -117,6 +117,5 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
tmpfiles_process gitea.conf
 }
-- 
2.31.1




[gentoo-dev] [PATCH 6/9] net-vpn/riseup-vpn: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 net-vpn/riseup-vpn/riseup-vpn-0.21.6.ebuild | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net-vpn/riseup-vpn/riseup-vpn-0.21.6.ebuild 
b/net-vpn/riseup-vpn/riseup-vpn-0.21.6.ebuild
index c2c5eb8da77..3b22b5554ae 100644
--- a/net-vpn/riseup-vpn/riseup-vpn-0.21.6.ebuild
+++ b/net-vpn/riseup-vpn/riseup-vpn-0.21.6.ebuild
@@ -133,5 +133,4 @@ src_install() {
 
 pkg_postinst() {
xdg_pkg_postinst
-   go-module_pkg_postinst
 }
-- 
2.31.1




[gentoo-dev] [PATCH 4/9] net-dns/coredns: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 net-dns/coredns/coredns-1.8.3.ebuild | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net-dns/coredns/coredns-1.8.3.ebuild 
b/net-dns/coredns/coredns-1.8.3.ebuild
index 14b4e4767af..184cef43304 100644
--- a/net-dns/coredns/coredns-1.8.3.ebuild
+++ b/net-dns/coredns/coredns-1.8.3.ebuild
@@ -911,6 +911,5 @@ src_test() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
tmpfiles_process ${PN}.conf
 }
-- 
2.31.1




[gentoo-dev] [PATCH 8/9] www-servers/caddy: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
---
 www-servers/caddy/caddy-2.3.0-r1.ebuild | 1 -
 www-servers/caddy/caddy-2.4.2.ebuild| 1 -
 2 files changed, 2 deletions(-)

diff --git a/www-servers/caddy/caddy-2.3.0-r1.ebuild 
b/www-servers/caddy/caddy-2.3.0-r1.ebuild
index 32da8be5fb0..05facd87394 100644
--- a/www-servers/caddy/caddy-2.3.0-r1.ebuild
+++ b/www-servers/caddy/caddy-2.3.0-r1.ebuild
@@ -1160,5 +1160,4 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
 }
diff --git a/www-servers/caddy/caddy-2.4.2.ebuild 
b/www-servers/caddy/caddy-2.4.2.ebuild
index 2b788410be2..1f1105833ea 100644
--- a/www-servers/caddy/caddy-2.4.2.ebuild
+++ b/www-servers/caddy/caddy-2.4.2.ebuild
@@ -1181,5 +1181,4 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
 }
-- 
2.31.1




[gentoo-dev] [PATCH 9/9] go-module.eclass: drop the go-module_pkg_postinst function

2021-08-29 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 053861a1a18..3f6e07fad2f 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -85,7 +85,7 @@ QA_FLAGS_IGNORED='.*'
 # Go packages should not be stripped with strip(1).
 RESTRICT+=" strip"
 
-EXPORT_FUNCTIONS src_unpack pkg_postinst
+EXPORT_FUNCTIONS src_unpack
 
 # @ECLASS-VARIABLE: EGO_SUM
 # @DESCRIPTION:
@@ -417,21 +417,6 @@ go-module_live_vendor() {
popd >& /dev/null || die
 }
 
-# @FUNCTION: go-module_pkg_postinst
-# @DESCRIPTION:
-# Display a warning about security updates for Go programs.
-go-module_pkg_postinst() {
-   debug-print-function "${FUNCNAME}" "$@"
-   [[ -n ${REPLACING_VERSIONS} ]] && return 0
-   ewarn "${PN} is written in the Go programming language."
-   ewarn "Since this language is statically linked, security"
-   ewarn "updates will be handled in individual packages and will be"
-   ewarn "difficult for us to track as a distribution."
-   ewarn "For this reason, please update any go packages asap when new"
-   ewarn "versions enter the tree or go stable if you are running the"
-   ewarn "stable tree."
-}
-
 # @FUNCTION: _go-module_gomod_encode
 # @DESCRIPTION:
 # Encode the name(path) of a Golang module in the format expected by Goproxy.
-- 
2.31.1




[gentoo-dev] [PATCH 3/9] app-misc/pet: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 app-misc/pet/pet-0.3.6-r1.ebuild | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/app-misc/pet/pet-0.3.6-r1.ebuild b/app-misc/pet/pet-0.3.6-r1.ebuild
index 09f5ee655f7..4beff9649cc 100644
--- a/app-misc/pet/pet-0.3.6-r1.ebuild
+++ b/app-misc/pet/pet-0.3.6-r1.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -78,8 +78,6 @@ src_install() {
 }
 
 pkg_postinst() {
-   go-module_pkg_postinst
-
if ! has_version app-shells/peco && ! has_version app-shells/fzf ; then
einfo "You should consider to install app-shells/peco or"
einfo "app-shells/fzf to be able to use selector command"
-- 
2.31.1




[gentoo-dev] [PATCH 5/9] net-dns/dnscrypt-proxy: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 net-dns/dnscrypt-proxy/dnscrypt-proxy-2.0.45.ebuild | 1 -
 net-dns/dnscrypt-proxy/dnscrypt-proxy-2.1.0.ebuild  | 1 -
 net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild   | 1 -
 3 files changed, 3 deletions(-)

diff --git a/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.0.45.ebuild 
b/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.0.45.ebuild
index 86f103a511c..ffe2f5f05aa 100644
--- a/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.0.45.ebuild
+++ b/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.0.45.ebuild
@@ -74,7 +74,6 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
 
if ! use filecaps; then
ewarn "'filecaps' USE flag is disabled"
diff --git a/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.1.0.ebuild 
b/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.1.0.ebuild
index 19acce66145..3e4c51ce549 100644
--- a/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.1.0.ebuild
+++ b/net-dns/dnscrypt-proxy/dnscrypt-proxy-2.1.0.ebuild
@@ -74,7 +74,6 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
 
if ! use filecaps; then
ewarn "'filecaps' USE flag is disabled"
diff --git a/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild 
b/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
index 43359636f25..ef229346589 100644
--- a/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
+++ b/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
@@ -74,7 +74,6 @@ src_install() {
 
 pkg_postinst() {
fcaps_pkg_postinst
-   go-module_pkg_postinst
 
if ! use filecaps; then
ewarn "'filecaps' USE flag is disabled"
-- 
2.31.1




[gentoo-dev] [PATCH 1/9] app-admin/vault: drop calls to go-module_pkg_postinst

2021-08-29 Thread William Hubbs
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: William Hubbs 
---
 app-admin/vault/vault-1.5.9.ebuild | 5 -
 app-admin/vault/vault-1.6.5.ebuild | 5 -
 app-admin/vault/vault-1.7.3.ebuild | 5 -
 app-admin/vault/vault-1.8.1.ebuild | 5 -
 4 files changed, 20 deletions(-)

diff --git a/app-admin/vault/vault-1.5.9.ebuild 
b/app-admin/vault/vault-1.5.9.ebuild
index 0e1b75de2be..d8143cfbf23 100644
--- a/app-admin/vault/vault-1.5.9.ebuild
+++ b/app-admin/vault/vault-1.5.9.ebuild
@@ -71,8 +71,3 @@ src_install() {
keepdir /var/log/${PN}
fowners ${PN}:${PN} /var/log/${PN}
 }
-
-pkg_postinst() {
-   fcaps_pkg_postinst
-   go-module_pkg_postinst
-}
diff --git a/app-admin/vault/vault-1.6.5.ebuild 
b/app-admin/vault/vault-1.6.5.ebuild
index 64280d983e9..87aa3191263 100644
--- a/app-admin/vault/vault-1.6.5.ebuild
+++ b/app-admin/vault/vault-1.6.5.ebuild
@@ -71,8 +71,3 @@ src_install() {
keepdir /var/log/${PN}
fowners ${PN}:${PN} /var/log/${PN}
 }
-
-pkg_postinst() {
-   fcaps_pkg_postinst
-   go-module_pkg_postinst
-}
diff --git a/app-admin/vault/vault-1.7.3.ebuild 
b/app-admin/vault/vault-1.7.3.ebuild
index 64280d983e9..87aa3191263 100644
--- a/app-admin/vault/vault-1.7.3.ebuild
+++ b/app-admin/vault/vault-1.7.3.ebuild
@@ -71,8 +71,3 @@ src_install() {
keepdir /var/log/${PN}
fowners ${PN}:${PN} /var/log/${PN}
 }
-
-pkg_postinst() {
-   fcaps_pkg_postinst
-   go-module_pkg_postinst
-}
diff --git a/app-admin/vault/vault-1.8.1.ebuild 
b/app-admin/vault/vault-1.8.1.ebuild
index 7699be83768..e05fbc3bfbc 100644
--- a/app-admin/vault/vault-1.8.1.ebuild
+++ b/app-admin/vault/vault-1.8.1.ebuild
@@ -1802,8 +1802,3 @@ src_install() {
keepdir /var/log/${PN}
fowners ${PN}:${PN} /var/log/${PN}
 }
-
-pkg_postinst() {
-   fcaps_pkg_postinst
-   go-module_pkg_postinst
-}
-- 
2.31.1




[gentoo-dev] [PATCH 0/9] drop the go-module_pkg_postinst function

2021-08-29 Thread William Hubbs
It seems to me that we don't need this function any longer since the go
ebuild displays a message when it is upgraded or downgraded explaining
how to rebuild go packages, so I would like to remove it.

This patch series contains all of the changes I could find that need to
happen to allow the removal.

William Hubbs (9):
  app-admin/vault: drop calls to go-module_pkg_postinst
  app-metrics/blackbox_exporter: drop calls to go-module_pkg_postinst
  app-misc/pet: drop calls to go-module_pkg_postinst
  net-dns/coredns: drop calls to go-module_pkg_postinst
  net-dns/dnscrypt-proxy: drop calls to go-module_pkg_postinst
  net-vpn/riseup-vpn: drop calls to go-module_pkg_postinst
  www-apps/gitea: drop calls to go-module_pkg_postinst
  www-servers/caddy: drop calls to go-module_pkg_postinst
  go-module.eclass: drop the go-module_pkg_postinst function

 app-admin/vault/vault-1.5.9.ebuild  |  5 -
 app-admin/vault/vault-1.6.5.ebuild  |  5 -
 app-admin/vault/vault-1.7.3.ebuild  |  5 -
 app-admin/vault/vault-1.8.1.ebuild  |  5 -
 .../blackbox_exporter-0.19.0.ebuild |  5 -
 app-misc/pet/pet-0.3.6-r1.ebuild|  4 +---
 eclass/go-module.eclass | 17 +
 net-dns/coredns/coredns-1.8.3.ebuild|  1 -
 .../dnscrypt-proxy/dnscrypt-proxy-2.0.45.ebuild |  1 -
 .../dnscrypt-proxy/dnscrypt-proxy-2.1.0.ebuild  |  1 -
 .../dnscrypt-proxy/dnscrypt-proxy-.ebuild   |  1 -
 net-vpn/riseup-vpn/riseup-vpn-0.21.6.ebuild |  1 -
 www-apps/gitea/gitea-1.14.6.ebuild  |  1 -
 www-apps/gitea/gitea-.ebuild|  1 -
 www-servers/caddy/caddy-2.3.0-r1.ebuild |  1 -
 www-servers/caddy/caddy-2.4.2.ebuild|  1 -
 16 files changed, 2 insertions(+), 53 deletions(-)

-- 
2.31.1




[gentoo-dev] [PATCH] go-module.eclass: drop --mod=readonly from GOFLAGS

2021-08-28 Thread William Hubbs
As of go 1.16, --mod=readonly is the default, so we don't need to
specify it.
https://golang.org/ref/mod#build-commands
https://golang.org/doc/go1.16

Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 053861a1a18..d51b8279f97 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -75,9 +75,7 @@ export GOCACHE="${T}/go-build"
 # The following go flags should be used for all builds.
 # -v prints the names of packages as they are compiled
 # -x prints commands as they are executed
-# -mod=readonly do not update go.mod/go.sum but fail if updates are needed
-# -mod=vendor use the vendor directory instead of downloading dependencies
-export GOFLAGS="-v -x -mod=readonly"
+export GOFLAGS="-v -x"
 
 # Do not complain about CFLAGS etc since go projects do not use them.
 QA_FLAGS_IGNORED='.*'
-- 
2.31.1




Re: [gentoo-dev] [PATCH v5] meson.eclass: several cleanups

2021-08-26 Thread William Hubbs
On Wed, Aug 25, 2021 at 11:16:40AM -0500, William Hubbs wrote:
> On Wed, Aug 25, 2021 at 10:27:54AM -0500, William Hubbs wrote:
> > - Remove extraneous whitespace.
> 
> This will be removed from the commit message before I add the patch to
> the tree, and a sign-off will be added.

This is in the tree.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v5] meson.eclass: several cleanups

2021-08-25 Thread William Hubbs
On Wed, Aug 25, 2021 at 10:27:54AM -0500, William Hubbs wrote:
> - Remove extraneous whitespace.

This will be removed from the commit message before I add the patch to
the tree, and a sign-off will be added.

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] [PATCH v5] meson.eclass: several cleanups

2021-08-25 Thread William Hubbs
- Drop the unused emesontestargs variable.

- Use the compile and install subcommands of meson instead of calling
  ninja. This allows for the possibility of a different back end.

- Stop using the NINJAOPTS variable.

- Add --num-processes to "meson test" call regardless of whether MAKEOPTS
  is set since the default is 1 process.

- Pass --jobs 0 instead of 999 to represent infinity.

- Echo commands before running them.
- Remove extraneous whitespace.
---
 eclass/meson.eclass | 41 -
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2a563e367c6..8b22797da71 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -77,12 +77,6 @@ fi
 # Optional meson arguments as Bash array; this should be defined before
 # calling meson_src_configure.
 
-# @VARIABLE: emesontestargs
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# Optional meson test arguments as Bash array; this should be defined before
-# calling meson_src_test.
-
 # @VARIABLE: MYMESONARGS
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -379,7 +373,17 @@ meson_src_configure() {
 meson_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   eninja -C "${BUILD_DIR}" "$@"
+   local mesoncompileargs=(
+   -C "${BUILD_DIR}"
+   --jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
+   --load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
+   --verbose
+   "$@"
+   )
+
+   set -- meson compile "${mesoncompileargs[@]}"
+   echo "$@" >&2
+   "$@" || die "compile failed"
 }
 
 # @FUNCTION: meson_src_test
@@ -391,28 +395,31 @@ meson_src_test() {
 
local mesontestargs=(
-C "${BUILD_DIR}"
+   --num-processes "$(makeopts_jobs "${MAKEOPTS}")"
+   "$@"
)
-   [[ -n ${NINJAOPTS} || -n ${MAKEOPTS} ]] &&
-   mesontestargs+=(
-   --num-processes "$(makeopts_jobs 
${NINJAOPTS:-${MAKEOPTS}})"
-   )
-
-   # Append additional arguments from ebuild
-   mesontestargs+=("${emesontestargs[@]}")
 
-   set -- meson test "${mesontestargs[@]}" "$@"
+   set -- meson test "${mesontestargs[@]}"
echo "$@" >&2
"$@" || die "tests failed"
 }
 
 # @FUNCTION: meson_src_install
-# @USAGE: [extra ninja install arguments]
+# @USAGE: [extra meson install arguments]
 # @DESCRIPTION:
 # This is the meson_src_install function.
 meson_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
+   local mesoninstallargs=(
+   -C "${BUILD_DIR}"
+   --destdir "${D}"
+   "$@"
+   )
+
+   set -- meson install "${mesoninstallargs[@]}"
+   echo "$@" >&2
+   "$@" || die "install failed"
 
pushd "${S}" > /dev/null || die
einstalldocs
-- 
2.31.1




[gentoo-dev] [PATCH v4] meson.eclass: several cleanups

2021-08-24 Thread William Hubbs
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.

Stop using the NINJAOPTS variable.

Add --num-processes to "meson test" call regardless of whether MAKEOPTS
is set since the default is 1 process.
Signed-off-by: William Hubbs 
---
 eclass/meson.eclass | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2a563e367c6..a14d7412b56 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -379,7 +379,13 @@ meson_src_configure() {
 meson_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   eninja -C "${BUILD_DIR}" "$@"
+   local mesoncompileargs=(
+   -C "${BUILD_DIR}"
+   --jobs "$(makeopts_jobs "${MAKEOPTS}")"
+   --load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
+   )
+
+   meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
 }
 
 # @FUNCTION: meson_src_test
@@ -391,11 +397,8 @@ meson_src_test() {
 
local mesontestargs=(
-C "${BUILD_DIR}"
+   --num-processes "$(makeopts_jobs "${MAKEOPTS}" )"
)
-   [[ -n ${NINJAOPTS} || -n ${MAKEOPTS} ]] &&
-   mesontestargs+=(
-   --num-processes "$(makeopts_jobs 
${NINJAOPTS:-${MAKEOPTS}})"
-   )
 
# Append additional arguments from ebuild
mesontestargs+=("${emesontestargs[@]}")
@@ -406,13 +409,17 @@ meson_src_test() {
 }
 
 # @FUNCTION: meson_src_install
-# @USAGE: [extra ninja install arguments]
+# @USAGE: [extra meson install arguments]
 # @DESCRIPTION:
 # This is the meson_src_install function.
 meson_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
+   local mesoninstallargs=(
+   -C "${BUILD_DIR}"
+   --destdir "${D}"
+   )
+   meson install "${mesoninstallargs[@]}" "$@"
 
pushd "${S}" > /dev/null || die
einstalldocs
-- 
2.31.1




[gentoo-dev] [PATCH v3] meson.eclass: stop calling ninja

2021-08-24 Thread William Hubbs
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.

Stop using the NINJAOPTS variable.

Signed-off-by: William Hubbs 
---
 eclass/meson.eclass | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2a563e367c6..89f9e6bac87 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -379,7 +379,13 @@ meson_src_configure() {
 meson_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   eninja -C "${BUILD_DIR}" "$@"
+   local mesoncompileargs=(
+   -C "${BUILD_DIR}"
+   --jobs "$(makeopts_jobs "${MAKEOPTS}")"
+   --load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
+   )
+
+   meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
 }
 
 # @FUNCTION: meson_src_test
@@ -392,9 +398,9 @@ meson_src_test() {
local mesontestargs=(
-C "${BUILD_DIR}"
)
-   [[ -n ${NINJAOPTS} || -n ${MAKEOPTS} ]] &&
+   [[ -n ${MAKEOPTS} ]] &&
mesontestargs+=(
-   --num-processes "$(makeopts_jobs 
${NINJAOPTS:-${MAKEOPTS}})"
+   --num-processes "$(makeopts_jobs)"
)
 
# Append additional arguments from ebuild
@@ -406,13 +412,17 @@ meson_src_test() {
 }
 
 # @FUNCTION: meson_src_install
-# @USAGE: [extra ninja install arguments]
+# @USAGE: [extra meson install arguments]
 # @DESCRIPTION:
 # This is the meson_src_install function.
 meson_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
+   local mesoninstallargs=(
+   -C "${BUILD_DIR}"
+   --destdir "${D}"
+   )
+   meson install "${mesoninstallargs[@]}" "$@"
 
pushd "${S}" > /dev/null || die
einstalldocs
-- 
2.31.1




[gentoo-dev] [PATCH v2] meson.eclass: stop calling ninja

2021-08-24 Thread William Hubbs
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.

Signed-off-by: William Hubbs 
---
 eclass/meson.eclass | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2a563e367c6..0bc74012fb1 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -379,7 +379,19 @@ meson_src_configure() {
 meson_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   eninja -C "${BUILD_DIR}" "$@"
+   local mesoncompileargs=(
+   -C "${BUILD_DIR}"
+   )
+   # use NINJAOPTS before MAKEOPTS for consistency with meson_src_test
+   local options="${NINJAOPTS:-${MAKEOPTS}}"
+   if [[ -n ${options} ]]; then
+   mesoncompileargs+=(
+   --jobs "$(makeopts_jobs ${options})"
+   --load-average "$(makeopts_loadavg ${options})"
+   )
+   fi
+
+   meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
 }
 
 # @FUNCTION: meson_src_test
@@ -406,13 +418,17 @@ meson_src_test() {
 }
 
 # @FUNCTION: meson_src_install
-# @USAGE: [extra ninja install arguments]
+# @USAGE: [extra meson install arguments]
 # @DESCRIPTION:
 # This is the meson_src_install function.
 meson_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
+   local mesoninstallargs=(
+   -C "${BUILD_DIR}" "$@"
+   --destdir "${D}"
+   )
+   meson install "${mesoninstallargs[@]}" "$@"
 
pushd "${S}" > /dev/null || die
einstalldocs
-- 
2.31.1




[gentoo-dev] [PATCH] meson.eclass: stop calling ninja

2021-08-23 Thread William Hubbs
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.

Signed-off-by: William Hubbs 
---
 eclass/meson.eclass | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 2a563e367c6..e9c9b155096 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -379,7 +379,21 @@ meson_src_configure() {
 meson_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   eninja -C "${BUILD_DIR}" "$@"
+   local mesoncompileargs=(
+   -C "${BUILD_DIR}"
+   )
+   if [[ -n ${NINJAOPTS} ]]; then
+   mesoncompileargs+=(
+   --jobs "$(makeopts_jobs ${NINJAOPTS})"
+   --load-average "$(makeopts_loadavg ${NINJAOPTS})"
+   )
+   elif [[ -n ${MAKEOPTS} ]]; then
+   mesoncompileargs+=(
+   --jobs "$(makeopts_jobs ${MAKEOPTS})"
+   --load-average "$(makeopts_loadavg ${MAKEOPTS})"
+   )
+
+   meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
 }
 
 # @FUNCTION: meson_src_test
@@ -406,13 +420,17 @@ meson_src_test() {
 }
 
 # @FUNCTION: meson_src_install
-# @USAGE: [extra ninja install arguments]
+# @USAGE: [extra meson install arguments]
 # @DESCRIPTION:
 # This is the meson_src_install function.
 meson_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
+   local mesoninstallargs=(
+   -C "${BUILD_DIR}" "$@"
+   --destdir "${D}"
+   )
+   meson install "${mesoninstallargs[@]}" "$@"
 
pushd "${S}" > /dev/null || die
einstalldocs
-- 
2.31.1




Re: [gentoo-dev] News Item for uClibc-ng deprecation

2021-08-17 Thread William Hubbs
On Tue, Aug 17, 2021 at 02:54:19PM -0400, Anthony G. Basile wrote:
> On 8/17/21 2:24 PM, Aaron Bauman wrote:
> > On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
> >> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile  
> >> wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> Can I get feedback on the following news item?  (BTW, thanks soap)
> >>>
> >>> Title: uClibc-ng retirement on 2023/01/01
> >>> Author: Anthony G. Basile 
> >>> Posted: 2021-08-15
> >>> Revision: 1
> >>> News-Item-Format: 2.0
> >>> Display-If-Profile: default/linux/uclibc/*
> >>>
> >>> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> >>> noone has volunteered to step up maintenance or expressed interest in
> >>> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> >>> profiles, which will be removed on 2023/01/01. For parties interested in
> >>> an alternative libc, consider moving to musl, which is supported.
> >>
> >> 2023? That seems like a pretty long time to wait to remove something
> >> that isn't very well supported right now.
> > 
> > +1
> > 
> > While I have no involvement with uClibc-ng, it does seem awfully long
> > before removal.
> > 
> > -Aaron
> > 
> 
> How does 2022-08-01 sound?  That's about 1 year.

Since we know it is broken, a year even seems long.
Also, We can't get rid of the uclibc-based profiles until uclibc is removed.

Thanks,

William

> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH 1/1] profiles/hardened: remove the legasy musl profiles

2021-08-12 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 profiles/hardened/linux/musl/eapi   |  1 -
 profiles/hardened/linux/musl/make.defaults  |  5 -
 profiles/hardened/linux/musl/mips/eapi  |  1 -
 profiles/hardened/linux/musl/mips/mipsel/eapi   |  1 -
 profiles/hardened/linux/musl/mips/mipsel/parent |  2 --
 profiles/hardened/linux/musl/mips/parent|  2 --
 profiles/hardened/linux/musl/package.use.mask   |  6 --
 profiles/hardened/linux/musl/use.force  |  8 
 profiles/hardened/linux/musl/use.mask   | 17 -
 profiles/profiles.desc  |  2 --
 10 files changed, 45 deletions(-)
 delete mode 100644 profiles/hardened/linux/musl/eapi
 delete mode 100644 profiles/hardened/linux/musl/make.defaults
 delete mode 100644 profiles/hardened/linux/musl/mips/eapi
 delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/eapi
 delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/parent
 delete mode 100644 profiles/hardened/linux/musl/mips/parent
 delete mode 100644 profiles/hardened/linux/musl/package.use.mask
 delete mode 100644 profiles/hardened/linux/musl/use.force
 delete mode 100644 profiles/hardened/linux/musl/use.mask

diff --git a/profiles/hardened/linux/musl/eapi 
b/profiles/hardened/linux/musl/eapi
deleted file mode 100644
index 7ed6ff82de6..000
--- a/profiles/hardened/linux/musl/eapi
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/profiles/hardened/linux/musl/make.defaults 
b/profiles/hardened/linux/musl/make.defaults
deleted file mode 100644
index 1212f635f54..000
--- a/profiles/hardened/linux/musl/make.defaults
+++ /dev/null
@@ -1,5 +0,0 @@
-# Copyright 1999-2017 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
-USE="${USE} hardened pic -jit -orc"
-BOOTSTRAP_USE="${BOOTSTRAP_USE} hardened pic -jit -orc"
diff --git a/profiles/hardened/linux/musl/mips/eapi 
b/profiles/hardened/linux/musl/mips/eapi
deleted file mode 100644
index 7ed6ff82de6..000
--- a/profiles/hardened/linux/musl/mips/eapi
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/profiles/hardened/linux/musl/mips/mipsel/eapi 
b/profiles/hardened/linux/musl/mips/mipsel/eapi
deleted file mode 100644
index 7ed6ff82de6..000
--- a/profiles/hardened/linux/musl/mips/mipsel/eapi
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/profiles/hardened/linux/musl/mips/mipsel/parent 
b/profiles/hardened/linux/musl/mips/mipsel/parent
deleted file mode 100644
index c3e31b29715..000
--- a/profiles/hardened/linux/musl/mips/mipsel/parent
+++ /dev/null
@@ -1,2 +0,0 @@
-../../../../../default/linux/musl/mips/mipsel
-..
diff --git a/profiles/hardened/linux/musl/mips/parent 
b/profiles/hardened/linux/musl/mips/parent
deleted file mode 100644
index 506bb45139d..000
--- a/profiles/hardened/linux/musl/mips/parent
+++ /dev/null
@@ -1,2 +0,0 @@
-../../../../default/linux/musl/mips
-..
diff --git a/profiles/hardened/linux/musl/package.use.mask 
b/profiles/hardened/linux/musl/package.use.mask
deleted file mode 100644
index ce38400b406..000
--- a/profiles/hardened/linux/musl/package.use.mask
+++ /dev/null
@@ -1,6 +0,0 @@
-# Copyright 1999-2015 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
-# Matthias Maier  (2017-05-11)
-# masked in base, unmask for hardened/musl/
-sys-devel/gcc -pie
diff --git a/profiles/hardened/linux/musl/use.force 
b/profiles/hardened/linux/musl/use.force
deleted file mode 100644
index e2d7cf05ec5..000
--- a/profiles/hardened/linux/musl/use.force
+++ /dev/null
@@ -1,8 +0,0 @@
-# Copyright 1999-2013 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
-elibc_musl
-
-# Make sure people don't accidentally turn of ssp/pie in important packages.
-pie
-ssp
diff --git a/profiles/hardened/linux/musl/use.mask 
b/profiles/hardened/linux/musl/use.mask
deleted file mode 100644
index b851b043ca0..000
--- a/profiles/hardened/linux/musl/use.mask
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2015 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
--elibc_musl
-elibc_uclibc
-elibc_glibc
-
--hardened
-
-# precompiled headers are not compat with ASLR.
-pch
-
-# prelink is masked for hardened
-prelink
-
-# profile are incompatible when linking with pie
-profile
diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index e7e19692b5d..c02a0d23c6c 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -254,9 +254,7 @@ arm default/linux/arm/17.0/musl/armv7a/hardened 
exp
 arm64  default/linux/arm64/17.0/musl   exp
 arm64  default/linux/arm64/17.0/musl/hardened  exp
 mips   default/linux/musl/mips exp
-mips   hardened/linux/musl/mipsexp
 mips   default/linux/musl/mips/mipsel 

[gentoo-dev] [PATCH 0/1] remove the legasy musl profiles

2021-08-12 Thread William Hubbs
I spoke with several people on the #gentoo-hardened channel and no one
knows of any place where these profiles are being used.

I'll apply this patch early on Aug 16 UTC if no one objects.

William Hubbs (1):
  profiles/hardened: remove the legasy musl profiles

 profiles/hardened/linux/musl/eapi   |  1 -
 profiles/hardened/linux/musl/make.defaults  |  5 -
 profiles/hardened/linux/musl/mips/eapi  |  1 -
 profiles/hardened/linux/musl/mips/mipsel/eapi   |  1 -
 profiles/hardened/linux/musl/mips/mipsel/parent |  2 --
 profiles/hardened/linux/musl/mips/parent|  2 --
 profiles/hardened/linux/musl/package.use.mask   |  6 --
 profiles/hardened/linux/musl/use.force  |  8 
 profiles/hardened/linux/musl/use.mask   | 17 -
 profiles/profiles.desc  |  2 --
 10 files changed, 45 deletions(-)
 delete mode 100644 profiles/hardened/linux/musl/eapi
 delete mode 100644 profiles/hardened/linux/musl/make.defaults
 delete mode 100644 profiles/hardened/linux/musl/mips/eapi
 delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/eapi
 delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/parent
 delete mode 100644 profiles/hardened/linux/musl/mips/parent
 delete mode 100644 profiles/hardened/linux/musl/package.use.mask
 delete mode 100644 profiles/hardened/linux/musl/use.force
 delete mode 100644 profiles/hardened/linux/musl/use.mask

-- 
2.31.1




Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

2021-08-11 Thread William Hubbs
On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote:
> I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
> first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> priority.

> 
> The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
> semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
> suggestions.

FWIW, I like loong and ABI_LOONG better, or even better would be to use the
string `uname -m` returns for the hardware as ARCH and as the suffix for
ABI_.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

2021-08-06 Thread William Hubbs
On Thu, Aug 05, 2021 at 05:57:06PM -0700, Alec Warner wrote:
> On Thu, Aug 5, 2021 at 2:44 PM Georgy Yakovlev  wrote:
> >
> > Hi,
> >
> > We've been collecting more and more container related packages in
> >  app-emulation/*
> >
> > What do you think about finally moving those packages to separate category?
> 
> As always my opinion is that:
> 
> (a) Categories were a design mistake.
> (b) The mistake is hard to fix.
> (c) It's basically low-value to try to 'correctly' categorize packages
> because of A.

I disagree that categories are a mistake. For one thing, they help with
situations where different upstream packages have the same name (we have
two docker packages for example, both named docker by their upstreams),
and in my opinion they help keep the tree organized. It is nice to be
able to do something like `ls -d ` and check out somewhat
related groups of packages.

I will agree that C above is subjective.

> (d) Recategorizing means a bunch of stuff has to be updated.

All of the updates are much easier to do since we use git, so this isn't
a concern. You can set this up so it hits the tree all at once.

> Do people actually care what category things are in? I just use
> --search or eix or whatever and the category is just this...bad
> concept we attach to packages for silly historical reasons..

Yes, I think they are useful like I said above.

So add me to the list of folks supporting recatagorizing the packages.

William


signature.asc
Description: PGP signature


[gentoo-dev] app-accessibility/eflite last rites

2021-07-17 Thread William Hubbs
# William Hubbs  (2021-07-17)
# Does not build and has multiple open bugs including a security issue.
# Dead upstream (last release in 2006).
# Removal in 30 days (2021-08-16) (bug #602594).
app-accessibility/eflite

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables

2021-07-13 Thread William Hubbs
On Mon, Jul 12, 2021 at 11:24:42AM +0100, Marek Szuba wrote:
> On 2021-07-10 22:55, William Hubbs wrote:
> 
> > Change the _R0 suffix on these variable names to _ECLASS.
> 
> Since my question in response to the previous round of this has yet to 
> be answered, I repeat: are there any non-cosmetic reasons for doing this?

Consistency with the rest of the tree. If you do a "git grep _R0" on the
eclass directory, the lua eclasses are the only ones that have this in
the names of the guard variables, and the eclasses themselves aren't
named lua-r0.eclass etc.

What will break if I do this?

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

2021-07-11 Thread William Hubbs
On Sun, Jul 11, 2021 at 03:53:31PM +0200, Thomas Deutschmann wrote:
> Hi,
> 
> TL;DR:
> 
> Given that William said in the meanwhile, he sees no future for 
> opentmpfiles [1] and that nobody else, including me, is interested in 
> stepping up, things have changed.

Add this reference as well if you want, everyone upstream seems to agree
that opentmpfiles doesn't have a future.

https://github.com/OpenRC/opentmpfiles/issues/19

William


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables

2021-07-10 Thread William Hubbs
Change the _R0 suffix on these variable names to _ECLASS.
Signed-off-by: William Hubbs 
---
 eclass/lua-single.eclass | 10 +++---
 eclass/lua-utils.eclass  |  8 
 eclass/lua.eclass| 12 +---
 3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index ab4fdb3c75a..5e1ee936c12 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -68,16 +68,15 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-if [[ ! ${_LUA_SINGLE_R0} ]]; then
+if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
+_LUA_SINGLE_ECLASS=1
 
-if [[ ${_LUA_R0} ]]; then
+if [[ ${_LUA_ECLASS} ]]; then
die 'lua-single.eclass cannot be used with lua.eclass.'
 fi
 
 inherit lua-utils
 
-fi
-
 EXPORT_FUNCTIONS pkg_setup
 
 # @ECLASS-VARIABLE: LUA_COMPAT
@@ -275,8 +274,6 @@ _lua_single_set_globals() {
 _lua_single_set_globals
 unset -f _lua_single_set_globals
 
-if [[ ! ${_LUA_SINGLE_R0} ]]; then
-
 # @FUNCTION: _lua_gen_usedep
 # @USAGE: [...]
 # @INTERNAL
@@ -531,5 +528,4 @@ lua-single_pkg_setup() {
[[ ${MERGE_TYPE} != binary ]] && lua_setup
 }
 
-_LUA_SINGLE_R0=1
 fi
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 278bbca58a3..52ba290e544 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -23,7 +23,7 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-if [[ ! ${_LUA_UTILS_R0} ]]; then
+if [[ ! ${_LUA_UTILS_ECLASS} ]]; then
 
 inherit toolchain-funcs
 
@@ -376,7 +376,7 @@ lua_enable_tests() {
busted)
test_directory="${2:-spec}"
test_pkg="dev-lua/busted"
-   if [[ ! ${_LUA_SINGLE_R0} ]]; then
+   if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
eval "lua_src_test() {
busted --lua=\"\${ELUA}\" 
--output=\"plainTerminal\" \"${test_directory}\" || die \"Tests fail with 
\${ELUA}\"
}"
@@ -395,7 +395,7 @@ lua_enable_tests() {
 
local test_deps=${RDEPEND}
if [[ -n ${test_pkg} ]]; then
-   if [[ ! ${_LUA_SINGLE_R0} ]]; then
+   if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
test_deps+=" ${test_pkg}[${LUA_USEDEP}]"
else
test_deps+=" $(lua_gen_cond_dep "
@@ -528,5 +528,5 @@ lua_get_version() {
echo "${LUA_VERSION}"
 }
 
-_LUA_UTILS_R0=1
+_LUA_UTILS_ECLASS=1
 fi
diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index e9a5c117560..3b0816f9834 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -56,9 +56,10 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-if [[ ! ${_LUA_R0} ]]; then
+if [[ ! ${_LUA_ECLASS} ]]; then
+_LUA_ECLASS=1
 
-if [[ ${_LUA_SINGLE_R0} ]]; then
+if [[ ${_LUA_SINGLE_ECLASS} ]]; then
die 'lua.eclass cannot be used with lua-single.eclass.'
 fi
 
@@ -196,8 +197,6 @@ fi
 # lua_targets_lua5-1(-)?,lua_targets_lua5-2(-)?
 # @CODE
 
-if [[ ! ${_LUA_R0} ]]; then
-
 # @FUNCTION: _lua_validate_useflags
 # @INTERNAL
 # @DESCRIPTION:
@@ -313,9 +312,6 @@ lua_foreach_impl() {
multibuild_foreach_variant _lua_multibuild_wrapper "${@}"
 }
 
-_LUA_R0=1
-fi
-
 # @FUNCTION: _lua_set_globals
 # @INTERNAL
 # @DESCRIPTION:
@@ -374,3 +370,5 @@ _lua_set_globals() {
 
 _lua_set_globals
 unset -f _lua_set_globals
+
+fi
-- 
2.31.1




Re: [gentoo-dev] Require opt-in for bitcoin upgrade?

2021-07-10 Thread William Hubbs
To update everyone involved in this, please read my last comment on the
pr. Basically, this can be treated like a test version by adding it to
package.mask with an appropriate message then maybe publishing a
newsitem if the maintainer wants it to be known by other users.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Require opt-in for bitcoin upgrade?

2021-07-10 Thread William Hubbs
Hey All,

I'm responding again because I saw that I left Luke off of my original
message and I cleaned up my steps a bit.

We talked about this on the irc channel, and several of us feel that you
don't need anything special in the ebuild at all, you can do this via
package.mask and a newsitem.

I suggest the following assuming that the older version will stop
working when the network is fully upgraded.

- Publish a newsitem explaining this issue.
- After the newsitem is published, Commit the newer version under
  package.mask with the mask message being an explanation of the issue.
- at this point, if people want to opt in, they can unmask the newer
  version and add it to package.accept_keywords.
- Once the network is upgraded, unmask the newer version (and you
  might have to fast stable if the older version doesn't work).
- If I understand correctly, at this point, opting in isn't
  optional since the network is upgraded, so if people don't want
to use the new algo they can't use bitcoin.

That will give everyone time to see the newsitem before the newer version hits.

It seems like this is the best you can do since upstream is doing a hard
switchover to the new algo.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Require opt-in for bitcoin upgrade?

2021-07-10 Thread William Hubbs
On Sat, Jul 10, 2021 at 11:42:28AM -0400, Craig Andrews wrote:
> Gentoo currently has a number of packages required to run a bitcoin node 
> in its tree, including:
> * net-libs/libbitcoinconsensus
> * net-p2p/bitcoin-qt
> * net-p2p/bitcoind
> 
> In version 0.21.1, bitcoin included a consensus algorithm changed call 
> taproot. There is no configuration opt-in with this change; bitcoin < 
> 0.21.1 does not include taproot, bitcoin >= 0.21.1 does include taproot.
> 
> A PR [1] was created the bitcoin packaging proxy maintainer (Like 
> Dash-Jr, CC'ed) for the bitcoin 0.21.1 version bump. In that PR, Luke 
> insists that users must explicitly opt-in to the bitcoin 0.21.1 upgrade 
> because of the taproot consensus algorithm change. I encourage 
> interested parties to read the conversation in that PR to get the full 
> context.
> 
> * This is a minor version bump (assuming semver, this is the "patch" 
> level version change in bitcoin), indicating that upstream does not 
> consider this to be a major/breaking change.
> * Upstream does not have a mechanism for notifying users or requiring 
> them to opt-in to this change
> * Upstream does not have a mechanism to opt out of this change. The 
> users only option is to develop their own fork of the bitcoin software 
> or never upgrade the package if they want to avoid taproot.
> * Taproot was locked by miners, so the network will be upgrading [2]

I suggest the following:

1) a newsitem explaining this issue.
2) at the same time, package.mask the newer version temporarily and keep
the older version in the tree.
3) Once the network is upgraded, unmask the newer version and drop the
older version. If people want the older version at that point and write
a fork, you'll have to rename itt.

> 
> Therefore, I have a few questions for the fellow Gentoo developers:
> 1) Should we require users to explicitly opt-in to this upgrade beyond 
> the usual?
> 2) If so, how do we do that? I have been unable to find any 
> documentation or examples of existing packages that require explicit 
> upgrade opt-in. A REQUIRED_USE or a LICENSE [3] were suggested as well 
> as PROPERTIES="interactive" [4], but such approaches seem like 
> unintended/unconventional abuses of those settings as well as annoying 
> to the user.

If you do, I think you can do it the way I suggested without adding
extra things to the ebuild.

> 
> My suggested approach was to notifying the user of the change in the 
> pkg_pretend phase [5] so they're aware before they actually upgrade; 
> however, the proxy maintainer disagreed and force a revert. [6]

As far as I know proxy maintainers can't force anything; they defer to
developers because we are the ones who are more familiar with the way
the tree works.

That being said, I still think the cleaner solution is to use
a temporary package.mask along with a newsitem.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Dropping dev-lang/lua:5.2

2021-07-09 Thread William Hubbs
On Fri, Jul 09, 2021 at 04:49:59PM +0100, Marek Szuba wrote:
> On 2021-07-09 15:35, William Hubbs wrote:
> 
> >> As many (if not most) of you know, the Lua ecosystem is somewhat awkward
> >> owing to the facts that on the one hand dev-lang/lua upstream has never
> >> officially declared end of life on older versions,
> > 
> > Actually upstream does say when they will stop supporting each version
> > [1].
> 
> Um, where? Because I've looked at this page before, I've looked at it 
> again just now and I all can see there is that there will be no further 
> releases of Lua versions up to and including 5.2, and that there will 
> *probably* be no more 5.3 releases. No official End of Life statements, 
> no EOL timeline, and 5.3 is apparently both dead and alive at the same 
> time - which is fine for cats but not so for software.

I guess it is a matter of interpretation then, "there will be no further
releases" means end of life, to me anyway.

I do agree that we aren't sure about 5.3, but "there will be no further
releases" is pretty clear to me.
Older than lua 5.3 is dead.

> > 5.1 can go because luajit would cover it
> 
> Alas, not quite.
> 
> One, we've got quite a few packages in the tree which currently declare 
> compatibility with lua5-1 but not luajitt. This could probably be 
> addressed quite easily, the worst I have seen so far after substituting 
> luajit for lua5-1 is some memory leaks, but it will take some time and 
> effort to test all such packages.
> 
> Two, more importantly, making LuaJIT the only available implementation 
> of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64, 
> riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1 
> but are not supported by LuaJIT at all) as well as force arm64 and 
> ppc64le users to use a 2.1-beta version. This I am afraid might be the 
> deal breaker, as I honestly cannot imagine Gentoo suddenly implementing 
> support for all those arches.

Some of the arches you listed are not stable, so I don't think we have
to worry about those arches (see arches.desc). If the arch isn't stable,
we can't guarantee anything.

There is activity in luajit upstream, so hopefully they will do a new
release that supports the newer lua versions. I do agree that it is
problematic that they only support lua 5.1.

William



signature.asc
Description: PGP signature


[gentoo-dev] opemtmpfiles masking

2021-07-09 Thread William Hubbs
All,

I'm sure everyone has seen the news item and the masking of
opentmpfiles.

The tl;dr is that I do not see a future for opentmpfiles as it currently
stands and I don't see a particular need for another fork.

systemd-tmpfiles is small (a single binary and two man pages), and it is the
reference implementation. The only issue I'm aware of with it is on
selinux (but we can fix that in our selinux policies; it is not a bug in
systemd-tmpfiles).

I think that systemd-tmpfiles is the better choice at this point than
attempting to keep opentmpfiles going. Opentmpfiles is based on a fork
that was being used in archlinux before they switched to systemd. As far
as I know, Gentoo is the only distro using this, so moving to
systemd-tmpfiles is fine with me.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Dropping dev-lang/lua:5.2

2021-07-09 Thread William Hubbs
On Fri, Jul 09, 2021 at 11:36:21AM +0100, Marek Szuba wrote:
> Dear everyone,
> 
> As many (if not most) of you know, the Lua ecosystem is somewhat awkward 
> owing to the facts that on the one hand dev-lang/lua upstream has never 
> officially declared end of life on older versions, and on the other 
> dev-lang/luajit has never moved beyond 5.1 with their API support. 
> Still, this doesn't mean WE have to support all branches in 
> perpetuity... Between 5.1 being effectively here to stay due to LuaJIT 
> and 5.4 still being relatively new (meaning it cannot feasibly replace 
> 5.3 at this point), I would like to start by getting rid of 5.2 first.

Actually upstream does say when they will stop supporting each version
[1].

5.1 can go because luajit would cover it, but 5.2 is also a candidate.

William

[1] http://www.lua.org/versions.html


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-08 Thread William Hubbs
On Fri, Jul 09, 2021 at 07:04:45AM +0300, Joonas Niilola wrote:
> On 9.7.2021 5.49, William Hubbs wrote:
> 
> >> +Display-If-Installed: virtual/tmpfiles
> > 
> > This should be:
> > 
> > Display-If-Installed: sys-apps/opentmpfiles
> > 
> 
> Disagree. Some people seem to be waking up into "oh no, what have I
> installed?".

systemd and systemd-tmpfiles are also providers of this virtual, so
people who have these installed don't need to see the newsitem.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-08 Thread William Hubbs
On Thu, Jul 08, 2021 at 07:38:05PM -0700, Georgy Yakovlev wrote:
> Signed-off-by: Sam James 
> Signed-off-by: Georgy Yakovlev 
> ---
>  .../2021-07-07-systemd-tmpfiles.en.txt| 48 +++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> 
> diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt 
> b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> new file mode 100644
> index 000..0960663
> --- /dev/null
> +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> @@ -0,0 +1,48 @@
> +Title: systemd-tmpfiles replaces opentmpfiles due to security issues
> +Author: Georgy Yakovlev 
> +Author: Sam James 
> +Posted: 2021-07-07
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Installed: virtual/tmpfiles

This should be:

Display-If-Installed: sys-apps/opentmpfiles

> +
> +On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a
> +root privilege escalation vulnerability (CVE-2017-18925 [0],
> +bug #751415 [1], issue 4 [2] upstream).
> +
> +The use of opentmpfiles is discouraged by its maintainer due to the
> +unpatched vulnerability and other long-standing bugs [3].
> +
> +Users will start seeing their package manager trying to replace
> +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
> +another provider of virtual/tmpfiles.
> +
> +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
> +not use dbus, and is just a drop-in replacement for opentmpfiles. It is
> +a small binary built from systemd source code, but works separately,
> +similarly to eudev or elogind. It is known to work on both glibc and
> +musl systems.
> +
> +Note that systemd-tmpfiles is specifically for non-systemd systems. It
> +is intended to be used on an OpenRC system.
> +
> +If you wish to selectively test systemd-tmpfiles, follow those steps:
> +
> + 1. # emerge --oneshot sys-apps/systemd-tmpfiles
> + 2. # reboot
> +
> +No other steps required.
> +
> +If, after reviewing the linked bug reference for opentmpfiles, you feel
> +your system is not vulnerable/applicable to the attack described, you
> +can unmask[4] opentmpfiles at your own risk:
> +
> +1. In /etc/portage/package.unmask, add:
> +-sys-apps/opentmpfiles
> +2. # emerge --oneshot sys-apps/opentmpfiles

Something might need to be added cautioning folks that if they unmask
this, it may disappear on them in the future if we decide to remove it.

William

> +
> +[0] https://nvd.nist.gov/vuln/detail/CVE-2017-18925
> +[1] https://bugs.gentoo.org/751415
> +[2] https://github.com/OpenRC/opentmpfiles/issues/4
> +[3] https://bugs.gentoo.org/741216
> +[4] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package
> -- 
> 2.32.0
> 
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables

2021-07-06 Thread William Hubbs
Change the _R0 suffix on these variable names to _ECLASS.
Signed-off-by: William Hubbs 
---
 eclass/lua-single.eclass | 8 
 eclass/lua-utils.eclass  | 8 
 eclass/lua.eclass| 8 
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index ab4fdb3c75a..8b3692b2f18 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -68,9 +68,9 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-if [[ ! ${_LUA_SINGLE_R0} ]]; then
+if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
 
-if [[ ${_LUA_R0} ]]; then
+if [[ ${_LUA_ECLASS} ]]; then
die 'lua-single.eclass cannot be used with lua.eclass.'
 fi
 
@@ -275,7 +275,7 @@ _lua_single_set_globals() {
 _lua_single_set_globals
 unset -f _lua_single_set_globals
 
-if [[ ! ${_LUA_SINGLE_R0} ]]; then
+if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
 
 # @FUNCTION: _lua_gen_usedep
 # @USAGE: [...]
@@ -531,5 +531,5 @@ lua-single_pkg_setup() {
[[ ${MERGE_TYPE} != binary ]] && lua_setup
 }
 
-_LUA_SINGLE_R0=1
+_LUA_SINGLE_ECLASS=1
 fi
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 278bbca58a3..52ba290e544 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -23,7 +23,7 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-if [[ ! ${_LUA_UTILS_R0} ]]; then
+if [[ ! ${_LUA_UTILS_ECLASS} ]]; then
 
 inherit toolchain-funcs
 
@@ -376,7 +376,7 @@ lua_enable_tests() {
busted)
test_directory="${2:-spec}"
test_pkg="dev-lua/busted"
-   if [[ ! ${_LUA_SINGLE_R0} ]]; then
+   if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
eval "lua_src_test() {
busted --lua=\"\${ELUA}\" 
--output=\"plainTerminal\" \"${test_directory}\" || die \"Tests fail with 
\${ELUA}\"
}"
@@ -395,7 +395,7 @@ lua_enable_tests() {
 
local test_deps=${RDEPEND}
if [[ -n ${test_pkg} ]]; then
-   if [[ ! ${_LUA_SINGLE_R0} ]]; then
+   if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
test_deps+=" ${test_pkg}[${LUA_USEDEP}]"
else
test_deps+=" $(lua_gen_cond_dep "
@@ -528,5 +528,5 @@ lua_get_version() {
echo "${LUA_VERSION}"
 }
 
-_LUA_UTILS_R0=1
+_LUA_UTILS_ECLASS=1
 fi
diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index e9a5c117560..d6fe7201779 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -56,9 +56,9 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-if [[ ! ${_LUA_R0} ]]; then
+if [[ ! ${_LUA_ECLASS} ]]; then
 
-if [[ ${_LUA_SINGLE_R0} ]]; then
+if [[ ${_LUA_SINGLE_ECLASS} ]]; then
die 'lua.eclass cannot be used with lua-single.eclass.'
 fi
 
@@ -196,7 +196,7 @@ fi
 # lua_targets_lua5-1(-)?,lua_targets_lua5-2(-)?
 # @CODE
 
-if [[ ! ${_LUA_R0} ]]; then
+if [[ ! ${_LUA_ECLASS} ]]; then
 
 # @FUNCTION: _lua_validate_useflags
 # @INTERNAL
@@ -313,7 +313,7 @@ lua_foreach_impl() {
multibuild_foreach_variant _lua_multibuild_wrapper "${@}"
 }
 
-_LUA_R0=1
+_LUA_ECLASS=1
 fi
 
 # @FUNCTION: _lua_set_globals
-- 
2.31.1




[gentoo-dev] [PATCH] s6.eclass: add eapi 8 support

2021-07-05 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/s6.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/s6.eclass b/eclass/s6.eclass
index b84d5a166db..25960ba4a1d 100644
--- a/eclass/s6.eclass
+++ b/eclass/s6.eclass
@@ -4,7 +4,7 @@
 # @ECLASS: s6.eclass
 # @MAINTAINER:
 # William Hubbs 
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @BLURB: helper functions to install s6 services
 # @DESCRIPTION:
 # This eclass provides helpers to install s6 services.
@@ -25,9 +25,9 @@
 # }
 # @CODE
 
-case ${EAPI:-0} in
-   5|6|7) ;;
-   *) die "${ECLASS}.eclass: API in EAPI ${EAPI} not yet established" ;;
+case ${EAPI} in
+   5|6|7|8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 # @FUNCTION: _s6_get_servicedir
-- 
2.31.1




[gentoo-dev] [PATCH 3/3] lua.eclass: clean up the eapi test

2021-07-05 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/lua.eclass | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index e3a25c5d184..e9a5c117560 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -50,15 +50,10 @@
 # }
 # @CODE
 
-case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
-   die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
-   ;;
+case ${EAPI} in
7|8)
;;
-   *)
-   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-   ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 if [[ ! ${_LUA_R0} ]]; then
-- 
2.31.1




[gentoo-dev] [PATCH 2/3] lua-utils.eclass: clean up the eapi test

2021-07-05 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/lua-utils.eclass | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 59959eaf9c0..278bbca58a3 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -17,15 +17,10 @@
 # This eclass neither sets any metadata variables nor exports any phase
 # functions. It can be inherited safely.
 
-case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
-   die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
-   ;;
+case ${EAPI} in
7|8)
;;
-   *)
-   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-   ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 if [[ ! ${_LUA_UTILS_R0} ]]; then
-- 
2.31.1




[gentoo-dev] [PATCH 1/3] lua-single.eclass: clean up the eapi test

2021-07-05 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/lua-single.eclass | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index 7abe1eb6674..ab4fdb3c75a 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -62,15 +62,10 @@
 # }
 # @CODE
 
-case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
-   die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
-   ;;
+case ${EAPI} in
7|8)
;;
-   *)
-   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-   ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 if [[ ! ${_LUA_SINGLE_R0} ]]; then
-- 
2.31.1




[gentoo-dev] [PATCH 0/3] lua eclass cleanup round 2

2021-07-05 Thread William Hubbs
*** BLURB HERE ***
This is the second attempt to clean up these EAPI checks.

William Hubbs (3):
  lua-single.eclass: clean up the eapi test
  lua-utils.eclass: clean up the eapi test
  lua.eclass: clean up the eapi test

 eclass/lua-single.eclass | 9 ++---
 eclass/lua-utils.eclass  | 9 ++---
 eclass/lua.eclass| 9 ++---
 3 files changed, 6 insertions(+), 21 deletions(-)

-- 
2.31.1




[gentoo-dev] [PATCH] go-module.eclass: add eapi 8 support

2021-07-05 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index c11895944cd..053861a1a18 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # William Hubbs 
 # Robin H. Johnson 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: basic eclass for building software written as go modules
 # @DESCRIPTION:
 # This eclass provides basic settings and functions needed by all software
@@ -46,9 +46,9 @@
 #
 # @CODE
 
-case ${EAPI:-0} in
-   7) ;;
-   *) die "${ECLASS} EAPI ${EAPI} is not supported."
+case ${EAPI} in
+   7|8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 if [[ -z ${_GO_MODULE} ]]; then
-- 
2.31.1




[gentoo-dev] [PATCH 3/3] lua.eclass: clean up the eapi test

2021-07-02 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/lua.eclass | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index e3a25c5d184..b4cbac7afa8 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -51,13 +51,10 @@
 # @CODE
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
-   die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
-   ;;
7|8)
;;
*)
-   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   die "Unsupported EAPI=${EAPI} for ${ECLASS}"
;;
 esac
 
-- 
2.31.1




[gentoo-dev] [PATCH 2/3] lua-utils.eclass: clean up the eapi test

2021-07-02 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/lua-utils.eclass | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 59959eaf9c0..80758c15ded 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -18,13 +18,10 @@
 # functions. It can be inherited safely.
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
-   die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
-   ;;
7|8)
;;
*)
-   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   die "Unsupported EAPI=${EAPI} for ${ECLASS}"
;;
 esac
 
-- 
2.31.1




[gentoo-dev] [PATCH 1/3] lua-single.eclass: clean up the eapi test

2021-07-02 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/lua-single.eclass | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index 7abe1eb6674..3d7ef974bef 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -63,13 +63,10 @@
 # @CODE
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
-   die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
-   ;;
7|8)
;;
*)
-   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   die "Unsupported EAPI=${EAPI} for ${ECLASS}"
;;
 esac
 
-- 
2.31.1




[gentoo-dev] [PATCH 0/3] clean up lua eclass eapi checks

2021-07-02 Thread William Hubbs
*** BLURB HERE ***
We don't need to differentiate between EAPIs that are too old vs other
unsupported EAPIs.

William Hubbs (3):
  lua-single.eclass: clean up the eapi test
  lua-utils.eclass: clean up the eapi test
  lua.eclass: clean up the eapi test

 eclass/lua-single.eclass | 5 +
 eclass/lua-utils.eclass  | 5 +
 eclass/lua.eclass| 5 +
 3 files changed, 3 insertions(+), 12 deletions(-)

-- 
2.31.1




[gentoo-dev] [PATCH] go-module.eclass: add eapi 8 support

2021-07-01 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index c11895944cd..a8a3a7e26a7 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # William Hubbs 
 # Robin H. Johnson 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: basic eclass for building software written as go modules
 # @DESCRIPTION:
 # This eclass provides basic settings and functions needed by all software
@@ -47,7 +47,7 @@
 # @CODE
 
 case ${EAPI:-0} in
-   7) ;;
+   7|8) ;;
*) die "${ECLASS} EAPI ${EAPI} is not supported."
 esac
 
@@ -83,7 +83,11 @@ export GOFLAGS="-v -x -mod=readonly"
 QA_FLAGS_IGNORED='.*'
 
 # Go packages should not be stripped with strip(1).
-RESTRICT+=" strip"
+if [[ ${EAPI} == 7 ]]; then
+   RESTRICT+=" strip"
+else
+   RESTRICT=" strip"
+fi
 
 EXPORT_FUNCTIONS src_unpack pkg_postinst
 
-- 
2.31.1




Re: [gentoo-dev] Lua eclasses: support EAPI 8

2021-06-29 Thread William Hubbs
On Wed, Jun 16, 2021 at 10:34:18AM +0100, Marek Szuba wrote:
> Nothing special here. RESTRICT manipulation in lua-utils still uses +=
> on purpose, for consistency with how other variables are handled there
> as well as in order to avoid wasting CPU cycles on an EAPI version
> check for something that ultimately achieves the same.

I was on vacation for a number of days so didn't have a chance to check
on this.

Is portage stable already supporting eapi 8? if so when did that happen?
If not we can't support it in eclasses yet.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Update your IRC handle in LDAP

2021-05-30 Thread William Hubbs
On Sat, May 29, 2021 at 10:09:46AM +0200, Michał Górny wrote:
> On Sat, 2021-05-29 at 10:05 +0200, Ulrich Mueller wrote:
> > Please don't forget to update your IRC handle in LDAP. For example, if
> > you have moved from Freenode to Libera.Chat:
> > 
> > $ perl_ldap -b user -E gentooIM irc://irc.freenode.net/ 
> > ${USER}
> > $ perl_ldap -b user -C gentooIM ircs://irc.libera.chat/ 
> > ${USER}
> > 
> 
> It would be also nice if you took this as an opportunity to grow up
> and start using your developer nickname instead of switching through
> silly nicknames all the time, so that people can actually find you.

I wouldn't say it this way, but yes, I agree that we should all use our
developer nics on irc.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [PATCH 0/2] go-module.eclass cleanups

2021-05-25 Thread William Hubbs
On Tue, May 25, 2021 at 11:31:17AM -0700, Zac Medico wrote:
> On 5/21/21 8:45 AM, William Hubbs wrote:
> > This is an improvement to my previous patch. It is a patch series now
> > because there are two separate changes:
> > 
> > - GOPROXY is exported in go-module_set_globals since it is not needed if
> >   EGO_SUM is not set in the ebuild.
> > 
> > - go-module_setup_proxy is added. This function sets up the go proxy
> >   directory so that dependencies can be read from it.
> > 
> > William Hubbs (2):
> >   go-module.eclass: fix GOPROXY export
> >   go-module.eclass: add go-module_setup_proxy function
> > 
> >  eclass/go-module.eclass | 47 +++--
> >  1 file changed, 45 insertions(+), 2 deletions(-)
> > 
> 
> This series looks great to me! Thank you!

This series is committed.

Thanks,

William


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH 2/2] go-module.eclass: add go-module_setup_proxy function

2021-05-21 Thread William Hubbs
This function is to be used in an ebuild that uses EGO_SUM and defines
src_unpack.

Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 41 +
 1 file changed, 41 insertions(+)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 9d64ad48b43..c11895944cd 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -239,6 +239,47 @@ go-module_set_globals() {
_GO_MODULE_SET_GLOBALS_CALLED=1
 }
 
+# @FUNCTION: go-module_setup_proxy
+# @DESCRIPTION:
+# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
+# this function in src_unpack.
+# It sets up the go module proxy in the appropriate location.
+go-module_setup_proxy() {
+   # shellcheck disable=SC2120
+   debug-print-function "${FUNCNAME}" "$@"
+
+   if [[ ! ${_GO_MODULE_SET_GLOBALS_CALLED} ]]; then
+   die "go-module_set_globals must be called in global scope"
+   fi
+
+   local goproxy_dir="${GOPROXY/file:\/\//}"
+   mkdir -p "${goproxy_dir}" || die
+
+   # For each Golang module distfile, look up where it's supposed to go and
+   # symlink it into place.
+   local f
+   local goproxy_mod_dir
+   for f in ${A}; do
+   goproxy_mod_path="${_GOMODULE_GOSUM_REVERSE_MAP["${f}"]}"
+   if [[ -n "${goproxy_mod_path}" ]]; then
+   debug-print-function "Populating go proxy for 
${goproxy_mod_path}"
+   # Build symlink hierarchy
+   goproxy_mod_dir=$( dirname 
"${goproxy_dir}"/"${goproxy_mod_path}" )
+   mkdir -p "${goproxy_mod_dir}" || die
+   ln -sf "${DISTDIR}"/"${f}" 
"${goproxy_dir}/${goproxy_mod_path}" ||
+   die "Failed to ln"
+   local v=${goproxy_mod_path}
+   v="${v%.mod}"
+   v="${v%.zip}"
+   v="${v//*\/}"
+   _go-module_gosum_synthesize_files "${goproxy_mod_dir}" 
"${v}"
+   fi
+   done
+
+   # Validate the gosum now
+   _go-module_src_unpack_verify_gosum
+}
+
 # @FUNCTION: go-module_src_unpack
 # @DESCRIPTION:
 # If EGO_SUM is set, unpack the base tarball(s) and set up the
-- 
2.26.3




[gentoo-dev] [PATCH 1/2] go-module.eclass: fix GOPROXY export

2021-05-21 Thread William Hubbs
This variable should be exported in the go-module_set_globals function
since it is not needed unless EGO_SUM is used.

Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index c9a7ab12eaf..9d64ad48b43 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -232,6 +232,9 @@ go-module_set_globals() {
readonly EGO_SUM_SRC_URI
readonly _GOMODULE_GOSUM_REVERSE_MAP
 
+   # export the GOPROXY setting
+   export GOPROXY="file://${T}/go-proxy"
+
# Set the guard that we are safe
_GO_MODULE_SET_GLOBALS_CALLED=1
 }
@@ -268,7 +271,7 @@ _go-module_src_unpack_gosum() {
die "go-module_set_globals must be called in global scope"
fi
 
-   local goproxy_dir="${T}/go-proxy"
+   local goproxy_dir="${GOPROXY/file:\/\//}"
mkdir -p "${goproxy_dir}" || die
 
# For each Golang module distfile, look up where it's supposed to go, 
and
@@ -293,7 +296,6 @@ _go-module_src_unpack_gosum() {
unpack "$f"
fi
done
-   export GOPROXY="file://${goproxy_dir}"
 
# Validate the gosum now
_go-module_src_unpack_verify_gosum
-- 
2.26.3




[gentoo-dev] [PATCH 0/2] go-module.eclass cleanups

2021-05-21 Thread William Hubbs
This is an improvement to my previous patch. It is a patch series now
because there are two separate changes:

- GOPROXY is exported in go-module_set_globals since it is not needed if
  EGO_SUM is not set in the ebuild.

- go-module_setup_proxy is added. This function sets up the go proxy
  directory so that dependencies can be read from it.

William Hubbs (2):
  go-module.eclass: fix GOPROXY export
  go-module.eclass: add go-module_setup_proxy function

 eclass/go-module.eclass | 47 +++--
 1 file changed, 45 insertions(+), 2 deletions(-)

-- 
2.26.3




Re: [gentoo-dev] Re: [PATCH] go-module.eclass: add functions for use in custom src_unpack phase

2021-05-20 Thread William Hubbs
On Wed, May 19, 2021 at 01:57:38PM -0700, Zac Medico wrote:
> On 5/19/21 1:45 PM, Zac Medico wrote:
> >> +# @FUNCTION: go-module_setup_proxy
> >> +# @DESCRIPTION:
> >> +# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
> >> +# this function in src_unpack.
> >> +# It sets up the go module proxy in the appropriate location and exports
> >> +# the GOPROXY environment variable so that go calls will be able to
> >> +# locate the proxy directory.
> >> +go-module_setup_proxy() {
> >> +  # shellcheck disable=SC2120
> >> +  debug-print-function "${FUNCNAME}" "$@"
> >> +
> >> +  if [[ ! ${_GO_MODULE_SET_GLOBALS_CALLED} ]]; then
> >> +  die "go-module_set_globals must be called in global scope"
> >> +  fi
> >> +
> >> +  local goproxy_dir="${T}/go-proxy"
> >> +  mkdir -p "${goproxy_dir}" || die
> >> +
> >> +  # For each Golang module distfile, look up where it's supposed to go and
> >> +  # symlink it into place.
> >> +  local f
> >> +  local goproxy_mod_dir
> >> +  for f in ${A}; do
> >> +  goproxy_mod_path="${_GOMODULE_GOSUM_REVERSE_MAP["${f}"]}"
> >> +  if [[ -n "${goproxy_mod_path}" ]]; then
> >> +  debug-print-function "Populating go proxy for 
> >> ${goproxy_mod_path}"
> >> +  # Build symlink hierarchy
> >> +  goproxy_mod_dir=$( dirname 
> >> "${goproxy_dir}"/"${goproxy_mod_path}" )
> >> +  mkdir -p "${goproxy_mod_dir}" || die
> >> +  ln -sf "${DISTDIR}"/"${f}" 
> >> "${goproxy_dir}/${goproxy_mod_path}" ||
> >> +  die "Failed to ln"
> >> +  local v=${goproxy_mod_path}
> >> +  v="${v%.mod}"
> >> +  v="${v%.zip}"
> >> +  v="${v//*\/}"
> >> +  _go-module_gosum_synthesize_files "${goproxy_mod_dir}" 
> >> "${v}"
> >> +  fi
> >> +  done
> >> +  export GOPROXY="file://${goproxy_dir}"
> >> +
> >> +  # Validate the gosum now
> >> +  _go-module_src_unpack_verify_gosum
> >> +}
> >> +
> >>  # @FUNCTION: go-module_src_unpack
> >>  # @DESCRIPTION:
> >>  # If EGO_SUM is set, unpack the base tarball(s) and set up the
> >>
> > 
> > The go-module_setup_proxy function solves bug 790851 nicely, since
> > sys-cluster/k3s ebuilds can call that instead of go-module_src_unpack.
> 
> I do have one criticism of the go-module_setup_proxy, which is that it
> relies on the side-effect of the GOPROXY export for its operation. We
> can instead echo the GOPROXY value to stdout and force the caller to
> export it themselves, and provide a convenience wrapper function which
> works based on side-effects.

You really only need GOPROXY if you use EGO_SUM in your ebuild, so I
could probably export GOPROXY in go-module_set_globals.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] go-module.eclass: add functions for use in custom src_unpack phase

2021-05-19 Thread William Hubbs
Robin,

I would like your thoughts also. The idea is to allow something like
this. Maybe an example like this one should go in the top of the eclass
as well.

src_unpack() {
local srcs
go-module_setup_proxy
srcs="$(go-module_filter_proxy)"
# unpack or do what you need to do with everything in ${srcs}
}

William



signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] go-module.eclass: add functions for use in custom src_unpack phase

2021-05-19 Thread William Hubbs
If an ebuild uses EGO_SUM and needs to define a custom src_unpack phase,
these functions will make that easier.

go-module_setup_proxy is used to create a local file proxy of the
dependencies listed in EGO_SUM and go-module_filter_proxy is used to
create a new ${A} with the EGO_SUM_SRC_URI values removed.

Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 69 +
 1 file changed, 69 insertions(+)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index c9a7ab12eaf..80e1f711215 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -236,6 +236,75 @@ go-module_set_globals() {
_GO_MODULE_SET_GLOBALS_CALLED=1
 }
 
+# @FUNCTION: go-module_filter_proxy
+# @DESCRIPTION:
+# If your ebuild redefines src_unpack and uses EGO_SUM, use the return
+# value of this function in place of ${A} in your src_unpack function.
+# It filters the EGO_SUM_SRC_URI values out of SRC_URI.
+go-module_filter_proxy() {
+   # shellcheck disable=SC2120
+   debug-print-function "${FUNCNAME}" "$@"
+
+   if [[ ! ${_GO_MODULE_SET_GLOBALS_CALLED} ]]; then
+   die "go-module_set_globals must be called in global scope"
+   fi
+
+   # Skip golang modules and add the rest of the entries to a local
+   # array.
+   local f
+   local -a src
+   for f in ${A}; do
+   if [[ -z ${_GOMODULE_GOSUM_REVERSE_MAP["${f}"]} ]]; then
+   src+=("${f}")
+   fi
+   done
+   echo "${src[@]}"
+}
+
+# @FUNCTION: go-module_setup_proxy
+# @DESCRIPTION:
+# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
+# this function in src_unpack.
+# It sets up the go module proxy in the appropriate location and exports
+# the GOPROXY environment variable so that go calls will be able to
+# locate the proxy directory.
+go-module_setup_proxy() {
+   # shellcheck disable=SC2120
+   debug-print-function "${FUNCNAME}" "$@"
+
+   if [[ ! ${_GO_MODULE_SET_GLOBALS_CALLED} ]]; then
+   die "go-module_set_globals must be called in global scope"
+   fi
+
+   local goproxy_dir="${T}/go-proxy"
+   mkdir -p "${goproxy_dir}" || die
+
+   # For each Golang module distfile, look up where it's supposed to go and
+   # symlink it into place.
+   local f
+   local goproxy_mod_dir
+   for f in ${A}; do
+   goproxy_mod_path="${_GOMODULE_GOSUM_REVERSE_MAP["${f}"]}"
+   if [[ -n "${goproxy_mod_path}" ]]; then
+   debug-print-function "Populating go proxy for 
${goproxy_mod_path}"
+   # Build symlink hierarchy
+   goproxy_mod_dir=$( dirname 
"${goproxy_dir}"/"${goproxy_mod_path}" )
+   mkdir -p "${goproxy_mod_dir}" || die
+   ln -sf "${DISTDIR}"/"${f}" 
"${goproxy_dir}/${goproxy_mod_path}" ||
+   die "Failed to ln"
+   local v=${goproxy_mod_path}
+   v="${v%.mod}"
+   v="${v%.zip}"
+   v="${v//*\/}"
+   _go-module_gosum_synthesize_files "${goproxy_mod_dir}" 
"${v}"
+   fi
+   done
+   export GOPROXY="file://${goproxy_dir}"
+
+   # Validate the gosum now
+   _go-module_src_unpack_verify_gosum
+}
+
 # @FUNCTION: go-module_src_unpack
 # @DESCRIPTION:
 # If EGO_SUM is set, unpack the base tarball(s) and set up the
-- 
2.26.3




[gentoo-dev] packages up for grabs: www-netbox and dependencies

2021-04-25 Thread William Hubbs
Hi all,

www-apps/netbox and its dependencies need love which I haven't been able
to give them lately, so I've decided to put them up for grabs.

I have dropped maintainership on the first two because the python team
is already a co-maintainer.

I am the only maintainer on the rest of these, so feel free to replace
me if you take them. netbox itself has some open bugs and a version
bump. I'm sure the bump can resolve the bugs.

I will go through the list again in a couple of weeks and do a lastrites
for the packages that do not have a maintainer.

dev-python/django-cacheops
dev-python/djangorestframework

www-apps/netbox
acct-group/netbox
acct-user/netbox
dev-python/django-cors-headers
dev-python/django-filter
dev-python/django-js-asset
dev-python/django-mptt
dev-python/django-pglocks
dev-python/django-prometheus
dev-python/django-rq
dev-python/django-taggit
dev-python/django-taggit-serializer
dev-python/django-timezone-field
dev-python/djangorestframework
dev-python/drf-yasg
dev-python/coreapi
dev-python/coreschema
dev-python/itypes
dev-python/swagger-spec-validator

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-29 Thread William Hubbs
This is getting really long, so I'm going to remove more things I'm not
answering directly.

On Sun, Mar 28, 2021 at 07:31:02PM -0400, Joshua Kinard wrote:
> > The problem is, there's a chicken-and-egg problem in the scenario where
> > / and /usr are on separate partitions, and this is why a number of linux
> > distros have moved to requiring an initramfs in this situation.
> > I'm linking systemd's description here, only because it is the best
> > writeup of the issue I've found [1].
> > Anything that is needed in the early boot process requires all of its 
> > libraries,
> > dependent libraries, binaries, data files, etc to be on /, and this has
> > become a moving target.
> 
> Yeah, I've read systemd's explanation, and generally disagree with it.  They
> created the problem in the first place, then invented their own solution for
> it, and now everyone acts like they're the wise men on the mountain for it.

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Rob Landley had a lot to say about how linux should be using initramfs
to handle early boot long before systemd came  along, so this has been
an issue a lot longer than systemd; the systemd guys just amplified it.

> I still don't see the connection to the static *.a libs and whether they're
> on /lib or /usr/lib, though.  Unless we're implying that where the *.a's go,
> so too do the *.so's go, then THAT makes sense because *.so's ARE needed at
> program runtime, whereas *.a's are not.

It is a linker behavior issue we discovered and  worked around.

In the past, Gentoo has gone an extra mile to make some things useable
by people who have separate /usr without an initramfs by moving only
shared libraries to /lib*. We leave everything else that would be in
libdir in the default location which is /usr/lib*. This includes things
like static libs, pkgconfig files etc.

When we started doing this we found that the linker favors libraries in
/usr/lib* over libraries in /lib*, so if you are linking to libfoo and
there's a static version in /usr/lib* and a shared version in /lib* you
will link to the static version. That's what bug 4411 is about. 

gen_usr_ldscript gets around this by creating a linker script at the
original location of the shared library in /usr/lib* when it moves the
shared library to /lib*.
See /usr/lib64/libbz2.so for an example of the generated linker script.

Getting rid of gen_usr_ldscript would move the shared libraries back to
their upstream location (/usr/lib*) and remove the linker scripts. This
would also allow the removal of the usr-ldscript eclass and the
gen_usr_ldscript function from eutils.eclass.

The up side of this is that it allows us to get rid of some of our
custom code in ebuilds, and it is completely transparent to most of our
user base.

The down side is that if you are using separate /usr with no
initramfs, libraries that you were accessing in /lib* during early boot will
moved to /usr/lib* and not be available before /usr is mounted.
This would cause breakage until you reconfigured your system to boot
with an initramfs and mount / and /usr before jumping into the real
system.

> I wonder if we couldn't shovel all static libs off to a dedicated folder
> somewhere, like '/usr/lib/static//*.a', similar to the way debug files
> are now consolidated under '/usr/lib/debug'.  Since they're only needed
> during a specific kind of compilation that we don't support out-of-the-box
> that happens long after the system is fully booted, stuffing them off
> somewhere unimportant would make some sense.  Most modern software should be
> using shared libs by default, and if it ain't, that's either a bug or that
> software is for a very specific function (like a bootloader).

If you started creating separate static libs folders you would need one per
abi, so it would end up being pretty ugly. We don't build that many
static libraries right now, so I'm not sure it is worth moving them to
some other folder.

If we put the shared libs back in the upstream expected location
(/usr/lib*) we would eliminate the linker issue.

*snip*

> > The way I see it, when we start to remove the gen_usr_ldscript calls,
> > people using a sep-usr mount without an initramfs will run into one or
> > both of these issues:
> > 
> > - they might have to increase the size of their root partition depending
> >   on what gets added to /lib*
> > - if one package in that list drops gen_usr_ldscript without installing
> >   libraries in /lib*, it will mean they need an initramfs.
> 
> I tend to make my root partitions ~4GB, which has often been plenty of room
> for well over 15 years.  But again, location of the *.a static libs is
> irrelevant during system boot.  They are not needed nor referenced when a
> program executes.  A statically-compiled program has all of its dependencies
> lumped inside of it, so you could put it pretty much anywhere on the
> filesystem and run it (ignoring for a moment 'noexec' potentially being
> set).  Or even 

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-28 Thread William Hubbs
On Sat, Mar 27, 2021 at 10:51:11PM -0400, Joshua Kinard wrote:
> On 3/27/2021 20:32, William Hubbs wrote:
> > On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote:
> >> On 3/23/2021 07:31, Rich Freeman wrote:
> >>> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel  
> >>> wrote:
> >>>>
> >>>>>> Council decided years ago that we don't support separate /usr without
> >>>>>> an initramfs, but we haven't completed that transition yet.
> >>>>>
> >>>>> Which doesn't imply that we deliberately break things.
> >>>>
> >>>> That's right. Though we should at some point start thinking about an end 
> >>>> of support for separate usr without initramfs.
> >>>>
> >>>
> >>> Just to clarify - it is already unsupported at a distro level.  It is
> >>> just that some individual packages still work with it.
> >>>
> >>> The current Council decisions on the issue are (just providing for
> >>> general reference):
> >>>
> >>> - "Since that particular setup may already be subtly broken today
> >>>   depending on the installed software, Council recommends using an
> >>>   early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
> >>>   is on a separate partition."
> >>>   Accepted unanimously. [1]
> >>>
> >>> - "The intention is to eventually not require maintainers to support
> >>>   a separate /usr without an early boot mechanism once the Council
> >>>   agrees that the necessary docs/migration path is in place."
> >>>   Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1]
> >>>
> >>> - "The Council agrees that all preparations for dropping support for
> >>>   separate /usr without an initramfs or similar boot mechanism are
> >>>   complete. A news item will be prepared, and users will be given one
> >>>   month to switch after the news item has been sent."
> >>>   Accepted with 5 yes votes, 1 no vote, 1 abstention. [2]
> >>>
> >>> Current policy documentation:
> >>> Developers are not required to support using separate /usr filesystem
> >>> without an initramfs. [3]
> >>>
> >>> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt
> >>> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt
> >>> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202
> >>
> >> Is there a list of software/ebuilds that currently do this "subtle" 
> >> handling
> >> of separate /usr w/o initramfs?
> >>
> >> I've got just my MIPS systems left that use a separate /usr and do not boot
> >> with initramfs because I build fully monolithic kernels and that makes the
> >> resulting vmlinux images run up against hard size limits in the SGI PROM
> >> (firmware, BIOS, etc) on these machines if I try to pack too large of an
> >> initramfs in.  I can check for any software that may be switched over soon
> >> to a hard initramfs requirement and look at my options.
> > 
> > One group of packages involved in this is any package that calls
> > gen_usr_ldscript. We have this function for a couple of reasons.
> > 
> > Gentoo has a policy that bans *.a static libraries from being
> > installed in /lib*. I think this policy is unique to Gentoo,
> > because Most build systems I've seen do not
> > have separate paths for static vs dynamic libraries, so all libraries
> > from a package are installed in /usr/lib* or /lib*. This policy was
> > originally hard coded into portage some time back (I can find the commit
> > if you want it) before it was made a formal policy by the qa team.
> > It has since become a formal policy.
> > 
> > Because of this policy, we have to tell upstream build systems to
> > install libraries in ${ED}/usr/$(get_libdir). This is fine unless you
> > have separate usr with no initramfs. In that case, you have binaries on
> > / that link to shared libraries on /usr. When we saw this happening, we
> > started manually moving shared libraries from /usr/lib* to /lib* if
> > someone needed the package at boot time. Then we hit bug 4411 [1]
> > where the linker was prioritizing static libraries in /usr/lib* over shared
> > libraries in /lib*. 
> > 
> > I don't know if we tried to address that upstream or not, but ultimately
> > gen_usr_ldsc

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-27 Thread William Hubbs
On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote:
> On 3/23/2021 07:31, Rich Freeman wrote:
> > On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel  
> > wrote:
> >>
>  Council decided years ago that we don't support separate /usr without
>  an initramfs, but we haven't completed that transition yet.
> >>>
> >>> Which doesn't imply that we deliberately break things.
> >>
> >> That's right. Though we should at some point start thinking about an end 
> >> of support for separate usr without initramfs.
> >>
> > 
> > Just to clarify - it is already unsupported at a distro level.  It is
> > just that some individual packages still work with it.
> > 
> > The current Council decisions on the issue are (just providing for
> > general reference):
> > 
> > - "Since that particular setup may already be subtly broken today
> >   depending on the installed software, Council recommends using an
> >   early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
> >   is on a separate partition."
> >   Accepted unanimously. [1]
> > 
> > - "The intention is to eventually not require maintainers to support
> >   a separate /usr without an early boot mechanism once the Council
> >   agrees that the necessary docs/migration path is in place."
> >   Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1]
> > 
> > - "The Council agrees that all preparations for dropping support for
> >   separate /usr without an initramfs or similar boot mechanism are
> >   complete. A news item will be prepared, and users will be given one
> >   month to switch after the news item has been sent."
> >   Accepted with 5 yes votes, 1 no vote, 1 abstention. [2]
> > 
> > Current policy documentation:
> > Developers are not required to support using separate /usr filesystem
> > without an initramfs. [3]
> > 
> > 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt
> > 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt
> > 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202
> 
> Is there a list of software/ebuilds that currently do this "subtle" handling
> of separate /usr w/o initramfs?
> 
> I've got just my MIPS systems left that use a separate /usr and do not boot
> with initramfs because I build fully monolithic kernels and that makes the
> resulting vmlinux images run up against hard size limits in the SGI PROM
> (firmware, BIOS, etc) on these machines if I try to pack too large of an
> initramfs in.  I can check for any software that may be switched over soon
> to a hard initramfs requirement and look at my options.

One group of packages involved in this is any package that calls
gen_usr_ldscript. We have this function for a couple of reasons.

Gentoo has a policy that bans *.a static libraries from being
installed in /lib*. I think this policy is unique to Gentoo,
because Most build systems I've seen do not
have separate paths for static vs dynamic libraries, so all libraries
from a package are installed in /usr/lib* or /lib*. This policy was
originally hard coded into portage some time back (I can find the commit
if you want it) before it was made a formal policy by the qa team.
It has since become a formal policy.

Because of this policy, we have to tell upstream build systems to
install libraries in ${ED}/usr/$(get_libdir). This is fine unless you
have separate usr with no initramfs. In that case, you have binaries on
/ that link to shared libraries on /usr. When we saw this happening, we
started manually moving shared libraries from /usr/lib* to /lib* if
someone needed the package at boot time. Then we hit bug 4411 [1]
where the linker was prioritizing static libraries in /usr/lib* over shared
libraries in /lib*. 

I don't know if we tried to address that upstream or not, but ultimately
gen_usr_ldscript came out of it.
 
Several folks have wanted to get rid of this function for years [2].

I have looked into it before, and there are several things that can be done.

We can have packages that currently build static libraries and
use gen_usr_ldscript stop building static libraries and use the
appropriate setting in their build systems to install libraries in
/$(get_libdir). This is the path OpenRC is taking per request of the qa
lead. The next release will not support the static-libs use flag. This
will actively break anyone who is expecting this use flag to exist for OpenRC.

If a package does not build static libraries in the first place, there is
really no reason  to call gen_usr_ldscript; the ebuild should be using
the upstream build system to put the libraries where they need to be.

If static libraries are needed for a package that is using
gen_usr_ldscript to move shared libraries to /lib*, the only option you
have is to drop the gen_usr_ldscript call. If you do that, all of the
libraries will stay in /usr/lib*, but as soon as one package takes this
path, there will be active breakage for someone who is using a separate
/usr without an 

Re: [gentoo-dev] rfc: usrmerge script

2021-03-24 Thread William Hubbs
On Wed, Mar 24, 2021 at 01:09:52PM -0400, Rich Freeman wrote:
> On Wed, Mar 24, 2021 at 11:09 AM William Hubbs  wrote:
> >
> > On Wed, Mar 24, 2021 at 08:48:41AM +0100, Michał Górny wrote:
> > >
> > > What really can help is reflinking on filesystems supporting that.
> >
> > What really can help is more info instead of being terse like this.
> > Which filesystems support it?
> >
> 
> According to Google right now: Btrfs, CIFS, NFS 4.2, OCFS2, overlayfs, and XFS
> 
> Lizardfs ought to, but doesn't currently.  zfs does not because clones
> only are supported at the dataset level.
> 
> In any case, if you're using coreutils cp to do the copy, just pass
> --reflink=auto.  Honestly, I have no idea why this isn't the default
> behavior.  Who wouldn't want instant copy operations that consume zero
> space (aside from metdata)?  If you're doing this in C or some other
> language you would need to see if they have a library call to do it
> easily - see man ioctl_ficlone.

I'm using busybox, and I just checked and it also supports the
--reflink=auto switch.

I thought about coreutils, but with everything on the fs being moved
around, I think that would get messy.

Thanks a lot for the info Rich. :-)

William

> 
> -- 
> Rich
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: usrmerge script

2021-03-24 Thread William Hubbs
On Wed, Mar 24, 2021 at 08:48:41AM +0100, Michał Górny wrote:
> On Wed, 2021-03-24 at 00:20 -0500, William Hubbs wrote:
> > On Tue, Mar 23, 2021 at 10:23:11AM +0100, Michał Górny wrote:
> > > On Sun, 2021-03-21 at 12:39 -0500, William Hubbs wrote:
> > > > All,
> > > > 
> > > > the following is a script which will migrate a Gentoo system to the usr
> > > > merge layout. This is similar to the unsymlink-lib tool used to migrate
> > > > a system  from the 17.0 to the 17.1 profiles.
> > > > 
> > > > I'm attaching it here to get some comments before I package it, so
> > > > please let me know if I have missed something.
> > > 
> > > To be honest, I don't think critical system modifications should be done
> > > in shell script, and especially not via a fringe non-standards complaint
> > > shell implementation in busybox.  Even if you can assume you make no
> > > mistakes, shell is unreliable by design.  For example, your script may
> > > start behaving in unexpected ways if you run out of space.
> > 
> > I went with busybox shell in this case because busybox is a static
> > binary and I figured with everything being moved around on the system it
> > would be a good choice.
> > 
> > I could pretty easily go with straight sh/bash, I just was focusing on
> > bb since the commands are built in.
> > 
> > You are right about shell behaving in weird ways if you run out of
> > space, but that's true for anything that happens to be running when a
> > system runs out of space.
> 
> This is not true.  Most of the programming languages can behave sanely
> in out-of-space conditions.  Sure, I/O fails one way or another but if
> it's just a matter of proper error handling.  Shells on the other hand,
> tend to use temporary files under the hood and can misbehave
> in unexpected ways.
 
Another reason I went with bb is there are no deps outside of bb and the
script. Also bb is on every gentoo system.
In short, I went for something that I knew would be everywhere.
If I'm going to do the work, it isn't going to be in python because I'm
not a fan. I can write some in python, but I don't consider my skills
there to be the best, and the indentation requirements make it tedious
for me to debug.

> > That is why I put the rollback directory in /var by
> > default figuring there is more space there than in /, especially on
> > systems with separate /var.
> 
> What really can help is reflinking on filesystems supporting that.
 
What really can help is more info instead of being terse like this.
Which filesystems support it?

> > The run_command wrapper in the script causes an immediate exit when the
> > command it runs fails so things don't go any
> > further than the failing command, so I'm not sure what else I can do
> > with this situation. One option is to always echo the command we are
> > about to run then just not run it if -d is specified. That means you
> > would always see the commands the script is running.
> 
> Did you see the verbose explanatory messages unsymlink-lib produces
> on every error condition?  Compared to this, your script is printing
> Windows-level 'error figure-it-out-yourself'.
 
This is early in development. Ideally I would handle most of the error
conditions before people start using this on production systems; that is
why I put it out here.

> > > You don't seem to be handling file collisions at all.  Even today we
> > > have files like /bin/bzip2 and /usr/bin/bzip2, not to mention shared
> > > libraries.  Silently ignoring the problem or requiring the users to
> > > manually ensure their system is clean is not going to solve it.
> 
> > I have added -i to the cp commands in my latest version of this so I'll
> > see when we have duplicate names, and yes that is an issue, even without
> > the /usr merge.
> 
> I don't think that's the best UI for this possible.  I doubt that
> a random user running the script will figure out why it is asking about
> file replacements.
 
 You are probably right, that's why I put this out here, and
 listed my thoughts about it below to generate discussion.

> > I'm curious why we are duplicating all of these names in the first
> > place honestly. 
> > 
> > One example of this is in coreutils, and we even say in the ebuild
> > comment that we need to figure out why we are doing it.
> > 
> > There are a couple of ways forward for this.
> > 
> > 1) attempt to open bugs on the packages and remove the duplicate names
> > by dropping symlinks and putting the files in their cannonical
> > locations.  this could lead  to breakages if

Re: [gentoo-dev] rfc: usrmerge script

2021-03-23 Thread William Hubbs
On Tue, Mar 23, 2021 at 10:23:11AM +0100, Michał Górny wrote:
> On Sun, 2021-03-21 at 12:39 -0500, William Hubbs wrote:
> > All,
> > 
> > the following is a script which will migrate a Gentoo system to the usr
> > merge layout. This is similar to the unsymlink-lib tool used to migrate
> > a system  from the 17.0 to the 17.1 profiles.
> > 
> > I'm attaching it here to get some comments before I package it, so
> > please let me know if I have missed something.
> 
> To be honest, I don't think critical system modifications should be done
> in shell script, and especially not via a fringe non-standards complaint
> shell implementation in busybox.  Even if you can assume you make no
> mistakes, shell is unreliable by design.  For example, your script may
> start behaving in unexpected ways if you run out of space.

I went with busybox shell in this case because busybox is a static
binary and I figured with everything being moved around on the system it
would be a good choice.

I could pretty easily go with straight sh/bash, I just was focusing on
bb since the commands are built in.

You are right about shell behaving in weird ways if you run out of
space, but that's true for anything that happens to be running when a
system runs out of space.

That is why I put the rollback directory in /var by
default figuring there is more space there than in /, especially on
systems with separate /var.

The run_command wrapper in the script causes an immediate exit when the
command it runs fails so things don't go any
further than the failing command, so I'm not sure what else I can do
with this situation. One option is to always echo the command we are
about to run then just not run it if -d is specified. That means you
would always see the commands the script is running.

> You don't seem to be handling file collisions at all.  Even today we
> have files like /bin/bzip2 and /usr/bin/bzip2, not to mention shared
> libraries.  Silently ignoring the problem or requiring the users to
> manually ensure their system is clean is not going to solve it.
 
I have added -i to the cp commands in my latest version of this so I'll
see when we have duplicate names, and yes that is an issue, even without
the /usr merge.
I'm curious why we are duplicating all of these names in the first
place honestly. 

One example of this is in coreutils, and we even say in the ebuild
comment that we need to figure out why we are doing it.

There are a couple of ways forward for this.

1) attempt to open bugs on the packages and remove the duplicate names
by dropping symlinks and putting the files in their cannonical
locations.  this could lead  to breakages if one of the alternate names is
expected by something until the /usr merge is done.

2) try to guess at resolving the duplicate names as part of the
   usr merge process.

a. symmlinks in /bin or /sbin that point to the same name in /usr/bin or
/usr/sbin should be removed.
b. symlinks in /usr/bin or /usr/sbin that point to the same name in /
should be removed.
c. Other symlinks that I can think of should be preserved.

Which path for handling this is best? Do you have any thoughts?

> You don't seem to provide any helpful messages.  When things fail, user
> will be left in the blue with an error message from some system tool (or
> rather, cheap-ass busybox rewrite, I guess).
 
If the rollback directory is populated, you can use -r to recover,
and the script will not let you perform the /usr merge if the rollback
directory is not populated.

> Also, have you verified that busybox's cp(1) actually preserves all file
> properties (including xattrs, ACLs, caps...)?
 
The documentation for busybox states that -p preserves file attributes
if possible,  and by doing ls -l in the chroot I can see that
ownership/permissions are preserved. So, logically I would guess it
preserves the others.

If switching back to non-busybox is fine for this operation, I have no
problem doing that either.

> Please don't forget to include tests with it.  Docker's good for testing
> stuff like this.

Docker can't be used during src_test that I'm aware of, so I'm not sure
how Docker could be used to test this.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: usrmerge script

2021-03-21 Thread William Hubbs
On Sun, Mar 21, 2021 at 08:08:00PM +0100, Luigi Mantellini wrote:
> there are some typos at lines 93, 94 and 95 (run_cmd instead run_command).
> 
> ciao
> 
> luigi
 
 Hi Luigi,

Thanks for catching these, all instances of run_cmd are now changed to
run_command.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: usrmerge script

2021-03-21 Thread William Hubbs
On Sun, Mar 21, 2021 at 01:00:01PM -0500, Matthias Maier wrote:
> Hi William,
> 
> I have migrated my system to a merged /usr a while ago.
> 
> In addition to moving everything to /usr and setting up symlinks, the
> main thing I had to do was to set up a /etc/portage/bashrc hook for
> post_src_install() that would move everything into /usr.
> 
> Do we have native support in portage for this now?

From what I know, you don't need that hook. The ebuilds handle this now
by using the split-usr use flag, so if you add this to
/etc/portage/make.conf you should be ok.

USE="${USE} -split-usr"

Let me know if that isn't the case.

I'm not exactly sure what portage will do without your hook though. What
happens if you remove your hook then some ebuild tries to install
something in /bin for example? I would argue that, if /bin resolves to a
path, portage should just follow the symlink and install where the
symlink points.  I base this argument on the return of `test -d` for
this situation.

```
$ ln -s /usr/bin foo
$ [ -d foo ] && echo "foo is a path"
```

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: usrmerge script

2021-03-21 Thread William Hubbs
All,

the following is a script which will migrate a Gentoo system to the usr
merge layout. This is similar to the unsymlink-lib tool used to migrate
a system  from the 17.0 to the 17.1 profiles.

I'm attaching it here to get some comments before I package it, so
please let me know if I have missed something.

Thanks,

William

#!/bin/bb
# shellcheck disable=SC2039 shell=sh

rollback_path=/var/usrmerge-rollback

check_internal_commands() {
for cmd in cp ln; do
[ "$(command -v "${cmd}")" = ${cmd} ] && continue
printf 'busybox does not include the %s command internally\n' 
"${cmd}"
return 1
done
return 0
}

check_root() {
 [ "$(id -u)" = 0 ] && return 0
 printf 'This script must be run by root\n'
 return 1
}

run_command() {
local cmd
[ -n "${dryrun}" ] && cmd="echo"
${cmd} "$@" || exit
return 0
}

setup_rollback() {
if [ -e "${rollback_path}" ]; then
printf '%s already exists\n' "${rollback_path}"
printf 'please remove it before continuing\n'
return 1
fi
printf 'Creating %s to allow rollbacks\n' "${rollback_path}"
run_command mkdir "${rollback_path}"
run_command mkdir "${rollback_path}/usr"
local dir
for dir in /bin /lib* /sbin; do
run_command cp -a "${dir}" "${rollback_path}"
done
for dir in /usr/bin /usr/lib* /usr/sbin; do
[ "${dir}" = /usr/libexec ] && continue
run_command cp -a "${dir}" "${rollback_path}/usr"
done
return 0
}

action_finish() {
run_command rm -fr "${rollback_path}"
return 0
}

action_help() {
local cmd
cmd="$(basename "${0}")"
printf 'usage: %s -h\n' "${cmd}"
printf '   %s [-d] -f|-m|-r\n' "${cmd}"
printf '\n'
printf '-h | --help  - displays this message\n'
printf '-d | --dry-run   - show what would be done\n'
printf '-f | --finish- remove the rollback data\n'
printf '-m | --merge - perform the usr merge\n'
printf '-r | --roll-back - attempt to undo the usr merge\n'
return 0
}

action_merge() {
if [ -L /bin ] || [ -L /sbin ]; then
printf 'The /usr merge has been completed on this system\n'
return 0
fi

local dir
for dir in /lib*; do
[ -L "${dir}" ] || continue
printf '%s is a symbolic link.\n' "${dir}"
printf 'This means you have not migrated to the 17.1 profiles 
yet\n'
printf 'please do so before running this script\n'
return 1
done

setup_rollback || return

# copy root directories to /usr counterparts and create
# the /usr merge compatibility symlinks
for dir in /bin /lib* /sbin; do
run_command cp -a -i "${dir}"/* /usr/"${dir}"
run_command rm -rf "${dir}"
run_command ln -snf usr/"${dir}" "${dir}"
done

# merge /usr/sbin into /usr/bin
run_cmd cp -a -i /usr/sbin/* /usr/bin
run_cmd rm -fr /usr/sbin
run_cmd ln -snf bin /usr/sbin
return 0
}

action_rollback() {
if [ ! -d "${rollback_path}" ]; then
printf '%s does not exist, unable to roll back\n' 
"${rollback_path}"
return 1
fi
local dir rollback_dir
for dir in /bin /lib* /sbin /usr/bin /usr/lib* /usr/sbin; do
[ "${dir}" = /usr/libexec ] && continue
rollback_dir="${rollback_path}/${dir}"
[ -d "${rollback_dir}" ] && continue
printf 'Unable to perform rollback, %s is missing\n' 
"${rollback_dir}"
return 1
done
for dir in /bin /lib* /sbin ; do
rollback_dir="${rollback_path}/${dir}"
run_cmd  rm -fr "${dir}"
run_cmd cp -a "${rollback_dir}" /
done
for dir in /usr/bin /usr/lib* /usr/sbin; do
[ "${dir}" = /usr/libexec ] && continue
rollback_dir="${rollback_path}/${dir}"
run_cmd  rm -f "${dir}"
run_cmd cp -a "${rollback_dir}" /usr
done
return 0
}

main() {
local dryrun finish merge rollback
while [ $# -gt 0 ]; do
case $1 in
-d|--dry-run)
dryrun=1
;;
-h|--help)
action_help
return 0
;;
-f|--finish)
finish=1
;;
-m|--merge)
merge=1
;;

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-20 Thread William Hubbs
On Sat, Mar 20, 2021 at 05:04:06PM +0100, Nils Freydank wrote:
> Hi Andreas,
> 
> Am Samstag, den 20.03.2021 um 16:37:23 Uhr +0100 schrieb "Andreas K. Huettel" 
> :
> > [...]
> > Does anyone remember the reason for 1) ? Or is that lost in history?
> 
> I just quote comment 3 from the linked bug https://bugs.gentoo.org/737914#c3:
> "copying the zonefile to /etc/localtime is a good idea, as /usr could be on a 
> separate partition. How about creating the
> 
> /etc/TZ -> /etc/timezone softlink by default?"
> 
> In my opinion so many tools tend to expect an always-mounted /usr that the
> symlink would not do any harm. FWIW I use symlinks on a handfull Gentoo 
> machines
> and had no issues in years, but I'm pretty close to mainstream (amd64, glibc,
> OpenRC).

I'm not sure which symlink you are talking about, so I am adding my
comments here.

/etc/localtime should definitely be a symlink to the proper file in
/usr/share/zoneinfo.

This works fine if /usr is on a separate partition *and* you are using
an initramfs. The only time it doesn't work is if /usr is separate
without using an initramfs.

Council decided years ago that we don't support separate /usr without an
initramfs, but we haven't completed that transition yet.

William



signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] eclass/lua-utils.eclass: remove EPREFIX from exported module paths

2021-01-11 Thread William Hubbs
Bug: https://bugs.gentoo.org/762769
Signed-off-by: William Hubbs 
---
 eclass/lua-utils.eclass | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 100be14cb08..9fe4d22e93f 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -212,8 +212,9 @@ _lua_get_library_file() {
die "Invalid implementation: ${impl}"
;;
esac
-   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
 
+   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
+   
debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
echo "${libdir}/${libname}"
 }
@@ -274,6 +275,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_CMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_CMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
${LUA_CMOD_DIR}"
@@ -282,6 +284,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable includedir 
${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_INCLUDE_DIR=${val}
debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
${LUA_INCLUDE_DIR}"
@@ -298,6 +301,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_LMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_LMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
${LUA_LMOD_DIR}"
@@ -364,11 +368,14 @@ lua_get_CFLAGS() {
 # @USAGE: []
 # @DESCRIPTION:
 # Obtain and print the name of the directory into which compiled Lua
-# modules are installed, for the given implementation. If no implementation
+# modules are installed for the given implementation. If no implementation
 # is provided, ${ELUA} will be used.
 #
-# Please note that this function requires Lua and pkg-config installed,
-# and therefore proper build-time dependencies need be added to the ebuild.
+# Please note that this function requires Lua and pkg-config to be installed,
+# and therefore proper build-time dependencies need to be added to the ebuild.
+#
+# For prefix installations, this function does not include the offset in
+# the path.
 lua_get_cmod_dir() {
debug-print-function ${FUNCNAME} "${@}"
 
@@ -385,6 +392,9 @@ lua_get_cmod_dir() {
 #
 # Please note that this function requires Lua and pkg-config installed,
 # and therefore proper build-time dependencies need be added to the ebuild.
+#
+# For prefix installations, this function does not include the offset in
+# the path.
 lua_get_include_dir() {
debug-print-function ${FUNCNAME} "${@}"
 
@@ -412,11 +422,14 @@ lua_get_LIBS() {
 # @USAGE: []
 # @DESCRIPTION:
 # Obtain and print the name of the directory into which native-Lua
-# modules are installed, for the given implementation. If no implementation
+# modules are installed for the given implementation. If no implementation
 # is provided, ${ELUA} will be used.
 #
 # Please note that this function requires Lua and pkg-config installed,
 # and therefore proper build-time dependencies need be added to the ebuild.
+#
+# For prefix installations, this function does not include the offset in
+# the path.
 lua_get_lmod_dir() {
debug-print-function ${FUNCNAME} "${@}"
 
-- 
2.26.2




Re: [gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths

2021-01-07 Thread William Hubbs
I'll fix the subject before I commit.

William

On Thu, Jan 07, 2021 at 05:13:09PM -0600, William Hubbs wrote:
> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs 
> ---
>  eclass/lua-utils.eclass | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..1e552da0848 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,10 @@ _lua_get_library_file() {
>   die "Invalid implementation: ${impl}"
>   ;;
>   esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>  
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
> + 
>   debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
>   echo "${libdir}/${libname}"
>  }
> @@ -274,6 +276,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_CMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
> ${LUA_CMOD_DIR}"
> @@ -282,6 +285,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable includedir 
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_INCLUDE_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +302,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_LMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
> ${LUA_LMOD_DIR}"
> -- 
> 2.26.2
> 
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths

2021-01-07 Thread William Hubbs
Bug: https://bugs.gentoo.org/762769
Signed-off-by: William Hubbs 
---
 eclass/lua-utils.eclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 100be14cb08..1e552da0848 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -212,8 +212,10 @@ _lua_get_library_file() {
die "Invalid implementation: ${impl}"
;;
esac
-   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
 
+   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
+   libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
+   
debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
echo "${libdir}/${libname}"
 }
@@ -274,6 +276,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_CMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_CMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
${LUA_CMOD_DIR}"
@@ -282,6 +285,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable includedir 
${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_INCLUDE_DIR=${val}
debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
${LUA_INCLUDE_DIR}"
@@ -298,6 +302,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_LMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_LMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
${LUA_LMOD_DIR}"
-- 
2.26.2




Re: [gentoo-dev] [PATCH 1/3] meson.eclass: use python eselect module in _meson_env_array

2020-12-20 Thread William Hubbs
On Thu, Dec 17, 2020 at 10:58:23PM +0100, Michał Górny wrote:
> On Thu, 2020-12-17 at 16:50 -0500, Mike Gilbert wrote:
> > On Thu, Dec 17, 2020 at 4:44 PM Michał Górny 
> > wrote:
> > > 
> > > On Thu, 2020-12-17 at 16:30 -0500, Mike Gilbert wrote:
> > > > Closes: https://bugs.gentoo.org/759433
> > > > Signed-off-by: Mike Gilbert 
> > > > ---
> > > >  eclass/meson.eclass | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > > > index 21338280df33..6296f1dd26e5 100644
> > > > --- a/eclass/meson.eclass
> > > > +++ b/eclass/meson.eclass
> > > > @@ -126,7 +126,8 @@ EOF
> > > >  #  '--unicode-16=з', '--unicode-32=अ']
> > > >  #
> > > >  _meson_env_array() {
> > > > -   python -c "${__MESON_ARRAY_PARSER}" "$@"
> > > > +   local python="$(eselect python show)"
> > > > +   ${python} -c "${__MESON_ARRAY_PARSER}" "$@"
> > > >  }
> > > > 
> > > >  # @FUNCTION: _meson_get_machine_info
> > > 
> > > You're missing a BDEPEND on app-eselect/eselect-python.
> > > 
> > > Also, I really don't like these workarounds.  It takes a lot of
> > > effort
> > > to figure out how to break stuff, so people stop doing awful
> > > things.
> > > It's disrespectful to my time when you invent new hacks.  Now I'll
> > > have
> > > to figure out how to change eselect-python to break it.
> > 
> > Why is this such an awful thing to do?
> > 
> > The code should be able to execute with any version of python
> > currently supported by Gentoo.
> > 
> > Please don't assume that I'm trying to avoid a proper solution here.
> > Please suggest a better alternative if you have one.
> 
> I actually liked installing the script to the system.

If we are going to install it to the system, that should not be done by
dev-util/meson; it is a gentoo-specific script, so we should probably
create a separate package for it. Also, it is debatable whether that
script should be installed in a directory that is on the path.

I have major concerns about the native-symlinks use flag for python-exec.
It looks like turning this flag off would result in /usr/bin/python not being
installed which will cause massive breakage. This is similar to removing
/bin/sh., so I am strongly against the idea of this use flag unless
upstream python is recommending it. If they are not installing
/usr/bin/python in their native builds any longer, I'll be quiet.
Otherwise, imo this is a really bad idea for a use flag.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-17 Thread William Hubbs
On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote:
> On Sat, Dec 12, 2020 at 9:09 PM William Hubbs  wrote:
> >
> > On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote:
> > > On Sat, Dec 12, 2020 at 3:48 PM William Hubbs  wrote:
> > > > If both /usr/bin/python and /usr/bin/python3 are going away, the best
> > > > choice would be to add functionality to python-exec or eselect python 
> > > > to tell us
> > > > the path to the default python interpretor. Once we know that we call it
> > > > directly.
> > >
> > > I don't think they are "going away". There is a USE flag on
> > > dev-lang/python-exec that makes them optional, and I think it will be
> > > forcibly enabled for the foreseeable future.
> > >
> > > > Please do not apply this patch to meson; I think we can figure something
> > > > out that is better.
> > >
> > > I think installing a small script to help translate arguments from one
> > > format to another is a reasonable solution.
> >
> >  I think we should look at the eclass to see if we can provide functions
> >  that can be used by consumers to handle this.
> 
> I don't really understand what you mean by this. I am converting one
> internal bash function into an external script so that its python
> dependencies can be better defined and managed.

What I mean is, ebuilds should not be calling _meson_env_array at all
since it is defined and documented as an eclass internal function.

I would like to know more about what the gallium-nine-standalone ebuild
is doing and why it needs to call a meson.eclass internal function.

On the other hand, if _meson_env_array is meant to be called by ebuilds,
we need to rename it and improve the documentation for it in the eclass.

> > Also, I don't think your script will run if native-symlinks is disabled 
> > since in
> > that setting /usr/bin/python would not exist.
> 
> python_doscript updates the shebang before installing the script.
 
 Ok, I didn't know python_doscript does this, but couldn't we just
 change line 129 in the eclass to "python3 -c ..."?

> > I question the value of the native-symlinks  use flag on python-exec
> > unless there is a way to query the path of the default python
> > interpretor.
> 
> Regardless, I don't see how that makes my solution a bad thing. It
> ensures that the code will be executed by a known/support/tested
> version of python.
> 

I'm not sure how useful the script is as a command, so I don't think it
should be installed that way, but I do want to hear more about this,
both from you and chewi. :-)

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-12 Thread William Hubbs
On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote:
> On Sat, Dec 12, 2020 at 3:48 PM William Hubbs  wrote:
> > If both /usr/bin/python and /usr/bin/python3 are going away, the best
> > choice would be to add functionality to python-exec or eselect python to 
> > tell us
> > the path to the default python interpretor. Once we know that we call it
> > directly.
> 
> I don't think they are "going away". There is a USE flag on
> dev-lang/python-exec that makes them optional, and I think it will be
> forcibly enabled for the foreseeable future.
> 
> > Please do not apply this patch to meson; I think we can figure something
> > out that is better.
> 
> I think installing a small script to help translate arguments from one
> format to another is a reasonable solution.
 
 I think we should look at the eclass to see if we can provide functions
 that can be used by consumers to handle this.

Also, I don't think your script will run if native-symlinks is disabled since in
that setting /usr/bin/python would not exist.

I question the value of the native-symlinks  use flag on python-exec
unless there is a way to query the path of the default python
interpretor.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 3/3] app-emulation/gallium-nine-standalone: use meson-array

2020-12-12 Thread William Hubbs
On Fri, Dec 11, 2020 at 06:17:44PM -0500, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/759433
> Signed-off-by: Mike Gilbert 
> ---
>  .../gallium-nine-standalone-0.7.ebuild| 4 ++--
>  .../gallium-nine-standalone-.ebuild   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild 
> b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
> index 3e96326a2fc8..9e075e1f5edb 100644
> --- a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
> +++ b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
> @@ -65,8 +65,8 @@ src_prepare() {
>  
>   sed \
>   -e "s!@PKG_CONFIG@!$(tc-getPKG_CONFIG)!" \
> - -e "s!@CFLAGS@!$(_meson_env_array "${CFLAGS} 
> '-DG9DLL=${g9dll}'")!" \
> - -e "s!@LDFLAGS@!$(_meson_env_array "${LDFLAGS}")!" \
> + -e "s!@CFLAGS@!$(meson-array "${CFLAGS} 
> '-DG9DLL=${g9dll}'")!" \
> + -e "s!@LDFLAGS@!$(meson-array "${LDFLAGS}")!" \
>   -e 
> "s!@PKG_CONFIG_LIBDIR@!${PKG_CONFIG_LIBDIR:-${ESYSROOT}/usr/$(get_libdir)/pkgconfig}!"
>  \
>   ${file}.in > ${file} || die
>   }
> diff --git 
> a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild 
> b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
> index 3e96326a2fc8..9e075e1f5edb 100644
> --- 
> a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
> +++ 
> b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
> @@ -65,8 +65,8 @@ src_prepare() {
>  
>   sed \
>   -e "s!@PKG_CONFIG@!$(tc-getPKG_CONFIG)!" \
> - -e "s!@CFLAGS@!$(_meson_env_array "${CFLAGS} 
> '-DG9DLL=${g9dll}'")!" \
> - -e "s!@LDFLAGS@!$(_meson_env_array "${LDFLAGS}")!" \
> + -e "s!@CFLAGS@!$(meson-array "${CFLAGS} 
> '-DG9DLL=${g9dll}'")!" \
> + -e "s!@LDFLAGS@!$(meson-array "${LDFLAGS}")!" \
>   -e 
> "s!@PKG_CONFIG_LIBDIR@!${PKG_CONFIG_LIBDIR:-${ESYSROOT}/usr/$(get_libdir)/pkgconfig}!"
>  \
>   ${file}.in > ${file} || die
>   }
> -- 
> 2.29.2

# @FUNCTION: _meson_env_array
# @INTERNAL
# @DESCRIPTION:
# Parses the command line flags and converts them into an array suitable for
# use in a cross file.

The _meson_env_array function is not part of the API for the meson
eclass.

Can you tell me more about gallium-nine-standalone and what it needs
from the meson eclass? We can probably provide functions that return the
info it needs.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-12 Thread William Hubbs
On Fri, Dec 11, 2020 at 06:17:42PM -0500, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/759433
> Signed-off-by: Mike Gilbert 
> ---
>  dev-util/meson/files/meson-array   | 18 ++
>  ...on-0.55.3.ebuild => meson-0.55.3-r1.ebuild} |  5 +
>  dev-util/meson/meson-.ebuild   |  5 +
>  3 files changed, 28 insertions(+)
>  create mode 100644 dev-util/meson/files/meson-array
>  rename dev-util/meson/{meson-0.55.3.ebuild => meson-0.55.3-r1.ebuild} (96%)
> 
> diff --git a/dev-util/meson/files/meson-array 
> b/dev-util/meson/files/meson-array
> new file mode 100644
> index ..0f4e8c7c6389
> --- /dev/null
> +++ b/dev-util/meson/files/meson-array
> @@ -0,0 +1,18 @@
> +#!/usr/bin/env python
> +
> +import itertools
> +import shlex
> +import sys
> +
> +def quote(s):
> +return "'" + s.replace("\\", "").replace("'", "\\'") + "'"
> +
> +def main():
> +args = sys.argv[1:]
> +args = (shlex.split(x) for x in args)
> +args = itertools.chain.from_iterable(args)
> +args = (quote(x) for x in args)
> +print("[" + ", ".join(args) + "]")
> +
> +if __name__ == "__main__":
> +main()
> diff --git a/dev-util/meson/meson-0.55.3.ebuild 
> b/dev-util/meson/meson-0.55.3-r1.ebuild
> similarity index 96%
> rename from dev-util/meson/meson-0.55.3.ebuild
> rename to dev-util/meson/meson-0.55.3-r1.ebuild
> index ddf27ccdc725..4708a46b324f 100644
> --- a/dev-util/meson/meson-0.55.3.ebuild
> +++ b/dev-util/meson/meson-0.55.3-r1.ebuild
> @@ -82,6 +82,11 @@ python_test() {
>   ) || die "Testing failed with ${EPYTHON}"
>  }
>  
> +python_install() {
> + distutils-r1_python_install
> + python_doscript "${FILESDIR}/meson-array"
> +}
> +
>  python_install_all() {
>   distutils-r1_python_install_all
>  
> diff --git a/dev-util/meson/meson-.ebuild 
> b/dev-util/meson/meson-.ebuild
> index 38ccf9179e21..1cdd142a3f79 100644
> --- a/dev-util/meson/meson-.ebuild
> +++ b/dev-util/meson/meson-.ebuild
> @@ -82,6 +82,11 @@ python_test() {
>   ) || die "Testing failed with ${EPYTHON}"
>  }
>  
> +python_install() {
> + distutils-r1_python_install
> + python_doscript "${FILESDIR}/meson-array"
> +}
> +
>  python_install_all() {
>   distutils-r1_python_install_all
>  
> -- 
> 2.29.2

I am fully aware I don't have full context for this, so fill me in if I
am missing something.

Reading this patch series and the bug linked in this message, it looks
like we are trying to make meson.eclass work if /usr/bin/python is missing.

My question is why? as far as I know /usr/bin/python is standard
like /bin/sh; when a version of python is installed this link is
always available.

If /usr/bin/python is going away, it is going to break not only this but
every python script that has "#!/usr/bin/python" or
"#!/usr/bin/env python" as a shebang line.

If /usr/bin/python is going away, what about /usr/bin/python3? If that
isn't going away, the easier thing to do is to tweak the eclass to call
it instead.

If both /usr/bin/python and /usr/bin/python3 are going away, the best
choice would be to add functionality to python-exec or eselect python to tell us
the path to the default python interpretor. Once we know that we call it
directly.

Please do not apply this patch to meson; I think we can figure something
out that is better.

Also, see my comments on the third patch in the series for more context.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-29 Thread William Hubbs
On Thu, Nov 26, 2020 at 07:55:33AM +0100, Piotr Karbowski wrote:
> Hi,
> 
> On 25/11/2020 22.57, Georgy Yakovlev wrote:
> > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
> > and is just a drop-in replacement, the only step needed is to emerge the
> > package.
> > it's a simple single binary + manpage, binary links to libacl and couple 
> > other
> > system libs.
> 
> Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been
> using it since end of October.
> 
> Two things that are different in terms of interface to opentmpfiles is
> that systemd-tmpfiles does not have --dry-run runtime option, and it
> will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of
> /run, but that's just an warning.

Also, have we tested this on musl systems?

My plan is to take the tmpfiles code from systemd, like eudev and elogin
have done, and rewrite it to not use the systemd libraries so it will be
more portable.

Once this happens, I'll probably switch the provider back to
opentmpfiles.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-07 Thread William Hubbs
On Tue, Nov 03, 2020 at 10:32:11PM +0100, Michał Górny wrote:
> net-libs/nodejs

I'll take this one for now.

William


signature.asc
Description: PGP signature


[gentoo-dev] sys-cluster/kubernetes last rites

2020-10-25 Thread William Hubbs
# Wiliam Hubbs  (2020-10-26)
# Combining kubernetes into one package breaks upgrades, so it is split
# into separate packages. You need to upgrade and install the following
# packages based on the needs of your cluster:
#
# sys-cluster/kubeadm, sys-cluster/kube-apiserver
# sys-cluster/kube-controller-manager, sys-cluster/kubectl
# sys-cluster/kubelet, sys-cluster/kube-proxy
# sys-cluster/kube-scheduler
#
# This package is being removed in 30 days. bug #741572
sys-cluster/kubernetes

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 1/6] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread William Hubbs
Hey all,

I'm just picking an eclass to respond to because I see this pretty
often, so I'm definitely not picking on mgorny with this question.

On Tue, Oct 06, 2020 at 02:10:45PM +0200, Michał Górny wrote:

*snip*

> +case "${EAPI:-0}" in
> + 0|1|2|3|4|5|6)
> + die "Unsupported EAPI=${EAPI} (obsolete) for ${ECLASS}"
> + ;;
> + 7)
> + ;;
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac

Does it really matter that an EAPI is unsupported because it is obsolete
vs unknown? Can we simplify this case statement to the following or
something similar for all of our eclasses?

case "${EAPI:-0}" in
7)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac

William



signature.asc
Description: PGP signature


[gentoo-dev] newsitem: k8s split packages round 3

2020-10-05 Thread William Hubbs
[Note: After chatting on irc, I haven't come up with anything that makes
sense for a kubernetes meta package, but I am open to meta packages if others
think they might be useful, so let's discuss that idea in a separate
thread. The text of the newsitem is below.]

Title: kubernetes Split Packages Returning
Author: William Hubbs 
Posted: 2020-10-06
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-cluster/kubernetes

In order to fix the ability to upgrade kubernetes components separately,
the kubernetes split packages are returning [1].

Starting with kubernetes 1.17.12, 1.18.9 and 1.19.2, you will need to
install the following packages in the appropriate configuration for
your cluster.

sys-cluster/kubeadm
sys-cluster/kube-apiserver
sys-cluster/kube-controller-manager
sys-cluster/kubectl
sys-cluster/kubelet
sys-cluster/kube-proxy
sys-cluster/kube-scheduler

Once the split packages are stabilized, sys-cluster/kubernetes will be
masked and removed.

[1] https://bugs.gentoo.org/741572


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >