[gentoo-dev] last rites: app-accessibility/espeak
# William Hubbs (2023-07-25) # This package has been replaced by app-accessibility/espeak-ng. # Please transition to the new package. # Removal: 2023-08-24. Bug #877221. app-accessibility/espeak Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] go-module.eclass: inline _go-module_gomod_encode()
This is applied.
Thanks,
William
On Mon, Jun 12, 2023 at 01:22:57PM +0200, Florian Schmaus wrote:
> The only call site of _go-module_gomod_encode() was using $() in a loop
> over EGO_SUM. This caused bash to fork() for every loop iteration, which
> significantly affected the time it takes to "source" an ebuild using
> EGO_SUM.
>
> For example, "pkg pkg source =sys-cluster/k3s-1.23.3_p1" previously took
> 2.4 seconds. Inlining _go-module_gomod_encode() reduces this to
> 236 milliseconds.
>
> This also adds missing 'local' declarations for some variables.
>
> Signed-off-by: Florian Schmaus
> ---
> eclass/go-module.eclass | 44 +++--
> 1 file changed, 16 insertions(+), 28 deletions(-)
>
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> index f97b69f591c8..6c58d7f26f07 100644
> --- a/eclass/go-module.eclass
> +++ b/eclass/go-module.eclass
> @@ -262,7 +262,22 @@ go-module_set_globals() {
> continue
> fi
>
> - _dir=$(_go-module_gomod_encode "${module}")
> + # Encode the name(path) of a Golang module in the format
> expected by Goproxy.
> + # Upper letters are replaced by their lowercase version with a
> '!' prefix.
> + # The transformed result of 'module' is stored in the '_dir'
> variable.
> + #
> + ## Python:
> + # return re.sub('([A-Z]{1})', r'!\1', s).lower()
> + ## Sed:
> + ## This uses GNU Sed extension \l to downcase the match
> + # echo "${module}" |sed 's,[A-Z],!\l&,g'
> + local re _dir lower
> + _dir="${module}"
> + re='(.*)([A-Z])(.*)'
> + while [[ ${_dir} =~ ${re} ]]; do
> + lower='!'"${BASH_REMATCH[2],}"
> + _dir="${BASH_REMATCH[1]}${lower}${BASH_REMATCH[3]}"
> + done
>
> for _ext in "${exts[@]}" ; do
> # Relative URI within a GOPROXY for a file
> @@ -496,33 +511,6 @@ go-module_live_vendor() {
> popd >& /dev/null || die
> }
>
> -# @FUNCTION: _go-module_gomod_encode
> -# @DEPRECATED: none
> -# @DESCRIPTION:
> -# Encode the name(path) of a Golang module in the format expected by Goproxy.
> -#
> -# Upper letters are replaced by their lowercase version with a '!' prefix.
> -#
> -_go-module_gomod_encode() {
> - ## Python:
> - # return re.sub('([A-Z]{1})', r'!\1', s).lower()
> -
> - ## Sed:
> - ## This uses GNU Sed extension \l to downcase the match
> - #echo "${module}" |sed 's,[A-Z],!\l&,g'
> - #
> - # Bash variant:
> - debug-print-function "${FUNCNAME}" "$@"
> - #local re input lower
> - re='(.*)([A-Z])(.*)'
> - input="${1}"
> - while [[ ${input} =~ ${re} ]]; do
> - lower='!'"${BASH_REMATCH[2],}"
> - input="${BASH_REMATCH[1]}${lower}${BASH_REMATCH[3]}"
> - done
> - echo "${input}"
> -}
> -
> fi
>
> if [[ ! ${GO_OPTIONAL} ]]; then
> --
> 2.39.3
>
>
signature.asc
Description: PGP signature
Re: [gentoo-dev] EGO_SUM
On Fri, Jun 02, 2023 at 10:13:55AM +0300, Joonas Niilola wrote: > On 1.6.2023 22.55, William Hubbs wrote: > >> > >> The EGO_SUM alternatives > >> - do not have the same level of trust and therefore have a negative > >> impact on security (a dubious tarball someone put somewhere, especially > >> when proxy-maint) > > > > For this, I would argue that vetting the tarball falls to the developer > > who is proxying. If you don't trust the proxy maintainer you > > are pushing for, it is easy to make a dependency tarball yourself and > > add it to your dev space. > > > > > >> - require additional effort when developing ebuilds > > > > This "additional effort" is pretty subjective. Making a dependency tarball > > isn't a lot of work, especially with the script that I posted in this > > thread. > > > > In theory it's "easy", but in practice how'd you work? This would be > fine when a single developer is proxying a single maintainer, but when a > a stack of devs (project) are proxying hundreds of different people, it > becomes messy and unsustainable rather fast. This comment is completely off topic for this thread, so start another thread for it if you want, but if hundreds of people are being proxied by proxy-maint, that seems to be a concern unrelated to this. It seems the fix for that is to advocate for some of these hundreds of people to become developers so they don't have to be proxied any more. > I do want to point out that any proxied maintainer can and should upload > the vendor tarballs to their own Github / Gitlab distfile-repos for the > time being, but allowing EGO_SUM to be used again would be the easiest > solution here in my opinion for everyone involved. I'm aware it's pushed > back due to technicalities. Like I said at another point in the thread, I want to get rid of EGO_SUM by moving most of the processing for it out of the eclass. I'm looking into that now. This will still run into the same problem as EGO_SUM if $A is still exported, but it should speed up ebuild processing. William signature.asc Description: PGP signature
Re: [gentoo-dev] EGO_SUM
I know I'm pretty late to this thread, but I'm going to respond to some
of the concerns and suggest another alternative.
On Mon, Apr 17, 2023 at 09:37:32AM +0200, Florian Schmaus wrote:
> I want to continue the discussion to re-instate EGO_SUM, potentially
> leading to a democratic vote on whether EGO_SUM should be re-instated or
> deprecated.
>
> For the past months, I tried to find *technical reasons*, e.g., reasons
> that affect end-users, that justify the deprecation of EGO_SUM. However,
> I was unable to find any. The closest thing I could find was portage
> being unable to process an ebuild due to its large environment (bug
> 830187). However, as this happens while developing an ebuild, it should
> never affect users. Obviously this is a situation where EGO_SUM can not
> be used. Fortunately, it does not affect most Go packages, as seen in my
> previous analysis of Go packages in ::gentoo and their EGO_SUM size.
> Furthermore, newer portage versions, with USE=gentoo-dev, will
> proactively warn you if the environment caused by the ebuild becomes large.
>
> All further arguments for the deprecation of EGO_SUM where of cosmetic
> nature.
>
> However, the deprecation of EGO_SUM is harmful to Gentoo and its users.
> To briefly re-iterate the reasons:
>
> The EGO_SUM alternatives
> - do not have the same level of trust and therefore have a negative
> impact on security (a dubious tarball someone put somewhere, especially
> when proxy-maint)
For this, I would argue that vetting the tarball falls to the developer
who is proxying. If you don't trust the proxy maintainer you
are pushing for, it is easy to make a dependency tarball yourself and
add it to your dev space.
> - are not easily verifiable
I don't have a response to this other than to say that go does its
own verification of modules with the dependency tarballs that it can't
do with vendor tarballs.
> - require additional effort when developing ebuilds
This "additional effort" is pretty subjective. Making a dependency tarball
isn't a lot of work, especially with the script that I posted in this thread.
> - hinder the packaging and Gentoo's adoption of Go-based projects, which
> is worrisome as Go is very popular
I don't have a response here. I don't see it as much of a henderance
(this is obviously subjective).
> - prevent Go modules from being shared as DISTFILES on the mirrors
> across various packages
The issue here is really the duplicate data in the dependency or vendor
tarballs, and yes, there is a lot of it.
> Last but not least, we have the same situation in the Rust ecosystem,
> but we allow the EGO_SUM "equivalent" there.
I'm not sure it is quite the same because Rust projects tend to have
much smaller numbers of dependencies.
Another thing to consider is that using EGO_SUM adds a significant
amount of processing to the go-module eclass.
I was advised recently that this isn't a good idea since bash is
slow, so I am considering moving most of that processing into
get-ego-vendor by having it generate the contents of SRC_URI directly
instead of using the eclass code to do that.
My thought is to have get-ego-vendor output the value for a variable,
GO_SRC_URI and add that to SRC_URI in the ebuild like so:
# The output from get-ego-vendor:
GO_SRC_URI="
# dependency 1
# dependency 2
"
SRC_URI="https://main-project-here
${GO_SRC_URI}"
This should speed things up some since most of the processing we are
doing in the eclass would be removed, so I would rather not see the council
force the use of EGO_SUM. This, however, is still going to hit the
limitation of bug 830187.
I am, however, open to another solution, so I will keep following this
thread.
I think the better question should be around what we can do to get bug 721088 or
bug 833567 to move forward.
Thanks,
William
signature.asc
Description: PGP signature
Re: [gentoo-dev] Portage and languages with built-in cache support
On Wed, Apr 26, 2023 at 06:43:04PM +0500, Anna (cybertailor) Vyalkova wrote:
> On 2023-04-25 16:09, Maciej Barć wrote:
> > You would also have to have correct permissions on cache dirs
> > (root:portage or portage:portage) this also means that the cache dir
> > will have to be set during build explicitly.
> > Do both Nim and Go support setting it?
>
> Yes. For Nim it would be something like that:
>
> # nim.cfg
> --nimcache:"${EPREFIX}/var/cache/nim/${CATEGORY}/${PN}"
>
> And for Go:
>
> export GOCACHE="${EPREFIX}/var/cache/go"
This would be very easy to do in the go-module eclass, but we would need
to test how it works with go upgrades. This cache is for compiled
objects, so I hope it would clean the cache and restart it with
every go upgrade since compiled go objects are not compatible between go
versions.
William
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: EGO_SUM
On Wed, May 31, 2023 at 08:30:58AM +0200, pascal.jaeger leimstift.de wrote:
>
> > Arthur Zamarin hat am 30.05.2023 18:35 CEST
> > geschrieben:
> >
> >
> > Currently the best solution *per package* is to speak with upstream, to
> > add a CI workflow which create a source tarball which includes `vendor`
> > dir. This is the best way, and I'm doing that for multiple upstream of
> > some random Go packages in ::gentoo. But I know the disadvantage -
> > requirement to speak with upstream, explain why, and add it to the
> > system. This is best long-run solution, but more hardships.
> >
>
> I would like to add to this, that even if upstream is not willing to do this,
> devs could automate the creation of vendor tarballs using GitHub actions. I
> only did this for an upstream repositories that are also on GitHub and for
> projects written in Rust. Initially I did this for complicated Rust projects
> with several git submodules and submodules of submodules. But with a little
> tweaking of the GitHub actions I think it would be possible to use it for Go
> as well.
> https://wiki.gentoo.org/wiki/User:Schievel/autocreate_rust_sources
>
> This is additional initial work, but once you set it up, you don't even have
> the extra work of creating a new EGO_SUM for every package release. Ideally
> you just have to change the version in the file name of the ebuild to bump a
> package.
>
> Security wise I do not see a difference between this and creating the vendor
> tarball manually and uploading it to GitHub, as many proxy maintainers
> without devspace do it.
Can we please avoid vendor tarballs? there are situations, say when a
dependency includes non-go code, when vendor tarballs do not work.
That is why I went with the dependency tarballs.
I haven't written github actions, but here is the script I use to create
them, partly thanks to Sam for this.
This is stored in my ~/bin directory and I run it from the top level of
a go project which does not have a "vendor" directory.
William
#!/bin/bash
if [[ -z $1 ]]; then
printf "no tarball name specified\n" >&2
return 1
fi
GOMODCACHE=${PWD}/go-mod go mod download -modcacherw
XZ_OPT='-T0 -9' \
tar --owner 0 --group 0 --posix -acf ${1}-deps.tar.xz go-mod
rm -fr go-mod
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: EGO_SUM
On Mon, Apr 17, 2023 at 02:28:22PM +0500, Anna (cybertailor) Vyalkova wrote: > On 2023-04-17 09:37, Florian Schmaus wrote: > > The EGO_SUM alternatives > > - do not have the same level of trust and therefore have a negative > > impact on security (a dubious tarball someone put somewhere, especially > > when proxy-maint) I haven't read all of this thread yet, but I did speak with Sam last night, and I have another idea about this. - I still want to deprecate EGO_SUM, but I'm working in the background on reworking get-ego-vendor to generate the data that goes into src_uri directly. This would eliminate most of the processing in the eclass. That, however, doesn't remove the concern about big ebuilds and manifests. I will look at the remainder of the thread to figure out what is going on with that. William signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH 0/1] dev-lang/luajit: indentation fixes
On Thu, Nov 10, 2022 at 08:50:53AM +0100, Petr Vaněk wrote: > On Thu, Nov 03, 2022 at 10:05:57AM +0100, Petr Vaněk wrote: > > Hi, > > > > I have found improperly indented dosym call in src_install phase in > > luajit ebuilds. Following patch fixes it. > > Ping I'll look at this today. Thanks, William > > signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Oct 01, 2022 at 07:21:13PM +0200, Florian Schmaus wrote: > On 01/10/2022 18.36, Ulrich Mueller wrote: > >> On Sat, 01 Oct 2022, Florian Schmaus wrote: > > > >> Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It > >> appears that the ebuild had more than 6000 entries in SRC_URI [1], > > > > That includes double counting and must be divided by the number of > > developers in TEXLIVE_DEVS. AFAICS that number was two in 2020. So 3000 > > is more realistic as a number there. > > That may be very well the case. I'd appreciate if you would elaborate on > the double counting. If someone knows a good and easy way to compute A > for an ebuild, then please let me know. That would help to get more > meaningful data. > > > >> from which A is generated from. Hence even a EGO_SUM limit of 3000 > >> entries should provide enough safety margin to avoid any Golang ebuild > >> running into this. > > > > See above, with 3000 entries there may be zero safety margin. It also > > depends on total filename length, because the limit is the Linux > > kernel's MAX_ARG_STRLEN (which is 128 KiB). > > Of course, this is a rough estimation assuming that the filename length > is roughly the same on average. That said, my proposed limit for EGO_SUM > is 1500, which is still half of 3000 and should still provide enough > safety margin. Since EGO_SUM_SRC_URI is the variable that gets added to SRC_URI, I would rather put the limitation there instead of EGO_SUM if we do end up keeping this. William signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Fri, Sep 30, 2022 at 12:49:02PM -0700, Alec Warner wrote: > On Fri, Sep 30, 2022 at 7:53 AM Florian Schmaus wrote: > > > > On 30/09/2022 02.36, William Hubbs wrote: > > > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: > > >>>>>>> On Wed, 28 Sep 2022, Florian Schmaus wrote: > > >>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer > > >>> maintains the package > > >>> 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > > >>> maintainer maintains the package > > >> > > >> These numbers seem quite large, compared to the mean number of 3.4 > > >> distfiles for packages in the Gentoo repository. (The median and the > > >> 99-percentile are 1 and 22, respectively.) > > > > The numbers may appear large when compared to the whole tree, but I > > think a fair comparison would be within the related programming language > > ecosystem, e.g., Golang or Rust. > > > > For example, analyzing ::gentoo yields the following histogram for > > 2022-01-01: > > https://dev.gentoo.org/~flow/ego_sum_entries_histogram-2020-01-01.png > > > > > > > To stay with your example, restic has a 300k manifest, multiple 30k+ > > > ebuilds and897 distfiles. > > > > > > I'm thinking the limit would have to be much lower. Say, around 256 > > > entries in EGO_SUM_SRC_URI. > > > > A limit of 256 appears to be to low to be of any use. It is slightly > > above the 50th percentile, half of the packages could not use it. > > > > We have to realize that programming language ecosystems that only build > > static binaries tend to produce software projects that have a large > > number of dependencies. For example, app-misc/broot, a tool written in > > Rust, has currently 310 entries in its Manifest. Why should we threat > > one programming language different from another? Will be see voices that > > ask for banning Rust packages in ::gentoo in the future? With the rising > > popularity of Golang and Rust, we will (hopefully) only ever see an > > increase of such packages in ::gentoo. And most existing packages in > > this category will at best keep their dependency count constant, but are > > also likely to accumulate further dependencies over time. > > > > And quite frankly, I don't see a problem with "large" Manifests and/or > > ebuilds. Yes, it means our FTPs are hosting many files, in some cases > > even many small files. And yes, it means that in some cases ebuild > > parsing takes a bit longer. But I spoke with a few developers in the > > past few months and was not presented with any real world issues that > > EGO_SUM caused. If someone wants to fill in here, then now is a good > > time to speak up. But my impression is that the arguments against > > EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am > > wrong. > > I thought the problem was that EGO_SUM ends up in SRC_URI, which ends > up in A. A ends up in the environment, and then exec() fails with > E2BIG because there is an imposed limit on environment variables (and > also command line argument length.) > > Did this get fixed? > > https://bugs.gentoo.org/719202 You are correct this was part of the issue as well. I don't know what the status of this bug is. William signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Fri, Sep 30, 2022 at 10:07:44PM +0200, Arsen Arsenović wrote:
> Hey,
>
> On Friday, 30 September 2022 02:36:05 CEST William Hubbs wrote:
> > I don't know for certain about a vendor tarball, but I do know there
> > are instances where a vendor tarball wouldn't work.
> > app-containers/containerd is a good example of this, That is why the
> > vendor tarball idea was dropped.
> It is indeed not possible to verify vendor tarballs[1]. The proposed
> solution Go people had would also require network access.
>
> > Upstream doesn't need to provide a tarball, just an up-to-date
> > "vendor" directory at the top level of the project. Two examples that
> > do this are docker and kubernetes.
> Upstreams doing this sounds like a mess, because then they'd have to
> maintain multiple source trees in their repositories, if I understand
> what you mean.
Well, there isn't a lot of work involved in this for upstream, they just
run:
$ go mod vendor
at the top level of their project and keep that directory in sync in
their vcs. The down side is it can be big and some upstreams do not want
to do it.
>
> An alternative to vendor tarballs is modcache tarballs. These are
> absolutely massive (~20 times larger IIRC), though, they are verifiable.
The modcache tarballs are what I'm calling dependency tarballs, and yes
they are bigger than vendor tarballs and verifiable.
Also, the go-module eclass sets the GOMODCACHE environment variable to
point to the directory where the contents of the dependency tarball ends
up which makes it easy for the go tooling to just use the information in
that directory.
If we can get bug https://bugs.gentoo.org/833567 to happen in eapi 9,
that would solve all of this.
The next step after I got that to happen would be to put a shared go
module cache in, for example, "${DISTDIR}/go-mod", so that all go
modules from packages would be downloaded there, and they would be
consumed like all distfiles are.
> opinion: I see no way around it. Vendor tarballs are the way to go. For
> trivial cases, this can likely be EGO_SUM, but it scales exceedingly
> poorly, to the point of the trivial case being a very small percentage
> of Go packages. I proposed authenticated automation on Gentoo
> infrastructure as a solution to this, and implemented (a slow and
> unreliable) proof of concept (posted previously). The obvious question
> of "how will proxy maintainers deal with this" is also relatively
> simple: giving them authorization for a subset of packages that they'd
> need to work on. This is an obvious increase in the barrier of entry for
> fresh proxy maintainers, but it's still likely less than needing
> maintainers to rework ebuilds to use vendor tarballs on dev.g.o.
Vendor tarballs are not complete. The best example of this I see in the tree is
app-containers/containerd. If you try to build that with a vendor tarball
instead of a dependency tarball, the build will break, but it works with
a dependency tarball.
William
>
>
> [1]: https://github.com/golang/go/issues/27348
> --
> Arsen Arsenović
signature.asc
Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Fri, Sep 30, 2022 at 04:53:39PM +0200, Florian Schmaus wrote: > On 30/09/2022 02.36, William Hubbs wrote: > > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: > >>>>>>> On Wed, 28 Sep 2022, Florian Schmaus wrote: > >>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer > >>> maintains the package > >>> 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > >>> maintainer maintains the package > >> > >> These numbers seem quite large, compared to the mean number of 3.4 > >> distfiles for packages in the Gentoo repository. (The median and the > >> 99-percentile are 1 and 22, respectively.) > > The numbers may appear large when compared to the whole tree, but I > think a fair comparison would be within the related programming language > ecosystem, e.g., Golang or Rust. > > For example, analyzing ::gentoo yields the following histogram for > 2022-01-01: > https://dev.gentoo.org/~flow/ego_sum_entries_histogram-2020-01-01.png > > > > To stay with your example, restic has a 300k manifest, multiple 30k+ > > ebuilds and897 distfiles. > > > > I'm thinking the limit would have to be much lower. Say, around 256 > > entries in EGO_SUM_SRC_URI. > > A limit of 256 appears to be to low to be of any use. It is slightly > above the 50th percentile, half of the packages could not use it. > > We have to realize that programming language ecosystems that only build > static binaries tend to produce software projects that have a large > number of dependencies. For example, app-misc/broot, a tool written in > Rust, has currently 310 entries in its Manifest. Why should we threat > one programming language different from another? Will be see voices that > ask for banning Rust packages in ::gentoo in the future? With the rising > popularity of Golang and Rust, we will (hopefully) only ever see an > increase of such packages in ::gentoo. And most existing packages in > this category will at best keep their dependency count constant, but are > also likely to accumulate further dependencies over time. I tend to agree with you honestly. I worked with Zac to come up with a different proposal which would allow upstream tooling for all languages that do this to work, but so far it is meeting resistance [1]. I will go back and add more information to that bug, but it will be later today before I can do that. I want to develop a poc to answer the statement that these would be live ebuilds if we allowed that. > And quite frankly, I don't see a problem with "large" Manifests and/or > ebuilds. Yes, it means our FTPs are hosting many files, in some cases > even many small files. And yes, it means that in some cases ebuild > parsing takes a bit longer. But I spoke with a few developers in the > past few months and was not presented with any real world issues that > EGO_SUM caused. If someone wants to fill in here, then now is a good > time to speak up. But my impression is that the arguments against > EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am > wrong. I can't name any specific examples at the moment, but I have gotten some complaints about how long it takes to download and build go packages with hundreds of dependencies. Other than that, I'm not the one who voiced the problem originally, so we definitely need others to speak up. William [1] https://bugs.gentoo.org/833567 signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: > > On Wed, 28 Sep 2022, Florian Schmaus wrote: > > > I would like to continue discussing whether we should entirely > > deprecate EGO_SUM without the desire to offend anyone. Don't worry, I am not offended. I just haven't found a simple way to do this. Sure, I will continue the discussion. > > We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic > > is a very popular backup software written in Go. The PR drops EGO_SUM > > in favor of a vendor tarball created by the proxied maintainer. > > However, I am unaware of any tool that lets you practically audit the > > 35 MiB source contained in the tarball. And even if such a tool > > exists, this would mean another manual step is required, which is, > > potentially, skipped most of the time, weakening our user's security. > > This is because I believe neither our tooling, e.g., go-mod.eclass, > > nor any Golang tooling, does authenticate the contents of the vendor > > tarball against upstream's go.sum. But please correct me if I am > > wrong. I don't know for certain about a vendor tarball, but I do know there are instances where a vendor tarball wouldn't work. app-containers/containerd is a good example of this, That is why the vendor tarball idea was dropped. Go modules are verified by go tooling. That is why I went with a dependency tarball. > > I wonder if we can reach consensus around un-depreacting EGO_SUM, but > > discouraging its usage in certain situations. That is, provide EGO_SUM > > as option but disallow its use if > > 1.) *upstream* provides a vendor tarball Upstream doesn't need to provide a tarball, just an up-to-date "vendor" directory at the top level of the project. Two examples that do this are docker and kubernetes. If the "vendor" directory is in the project, EGO_SUM should not be used. This is already documented in the eclass. > > 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer > > maintains the package > > 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > > maintainer maintains the package > > These numbers seem quite large, compared to the mean number of 3.4 > distfiles for packages in the Gentoo repository. (The median and the > 99-percentile are 1 and 22, respectively.) There is no way from within portage to tell whether a proxied maintainer or a developer maintains the package, and I don't think we should care. We don't want different qa standards for packages in the tree based on who maintains them. I think we should settle on one limit. I could check for that limit inside the eclass and make the ebuild process die if the limit is not observed. The concern, as I understand it, is about the sizes of the ebuilds and manifests for go software. Since the number of distfiles was mentioned, I will add it here and show it in my example numbers below. To stay with your example, restic has a 300k manifest, multiple 30k+ ebuilds and897 distfiles. I'm thinking the limit would have to be much lower. Say, around 256 entries in EGO_SUM_SRC_URI. William signature.asc Description: PGP signature
Re: [gentoo-dev] Up for grabs: dev-go/licenseclassifier, dev-go/go-licenses, sys-cluster/kube-router
On Wed, Jul 27, 2022 at 06:09:41AM +0100, Sam James wrote: > The following packages are up for grabs b/c of proxied maintainer retirement: > > dev-go/licenseclassifier > dev-go/go-licenses > sys-cluster/kube-router I'll grab these. William signature.asc Description: PGP signature
[gentoo-dev] last rites: dev-go/golint
# William Hubbs (2022-07-24) # **NOTE:** Golint is deprecated and frozen # according to [this issue](https://github.com/golang/go/issues/38968). # There's no drop-in replacement for it, but tools such as # [Staticcheck](https://staticcheck.io/) # and `go vet` should be used instead. # Bug #844412 # Removal: 2022-08-23 dev-go/golint Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 10:20:01PM +0200, Ulrich Mueller wrote: > >>>>> On Sat, 16 Jul 2022, William Hubbs wrote: > > The only question is, is there a way to reliably tell whether or not > > we are in the main tree? > > An eclass has no legitimate way to find out in which repository it is. > The rationale is that users should be able to copy ebuilds and eclasses > to their local overlays, and they should work there in the same way. > > There is an internal (and undocumented) Portage variable, but that > shouldn't be used. In that case, I'm left with two options. 1) continue with deprecating and removing EGO_SUM. 2) (suggested on IRC) allow EGO_SUM as long as it has below a certain low number of entries. It would need to be kept small to keep ebuilds and manifests from bloating too much. Thoughts? William signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 06:46:40PM +, Robin H. Johnson wrote:
> On Sat, Jul 16, 2022 at 09:31:35PM +0300, Arthur Zamarin wrote:
> > I want to give another option. Both ways are allowed by eclass, but by
> > QA policy (or some other decision), it is prohibited to use EGO_SUM in
> > main ::gentoo tree.
> >
> > As a result, overlays and ::guru can use the EGO_SUM or dist distfile
> > (remember, they don't have access to hosting on dev.g.o).
> Yes; this is the option I was trying to propose as an intermediate step
> until we have indirect Manifests that provide the best of both worlds
> (not bloating the tree, and not requiring creation of dep tarballs).
I could force this in the eclass with the following flow if I know how
to tell if the ebuild inheriting it is in the main tree or not:
# in_main_tree is a place holder for a test to see if the ebuld running
# this is in the tree
if [[ -n ${EGO_SUM} && in_main_tree ]]; then
eqawarn "EGO_SUM is not allowed in the main tree"
eqawarn "This will become a fatal error in the future"
fi
The only question is, is there a way to reliably tell whether or not
we are in the main tree?
William
signature.asc
Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Sat, Jul 16, 2022 at 02:58:04PM +0300, Joonas Niilola wrote: > On 16.7.2022 14.24, Florian Schmaus wrote: > > > > That reads as if you wrote it under the assumption that we can only > > either use dependency tarballs or use EGO_SUM. At the same time, I have > > not seen an argument why we can not simply do *both*. > > > > EGO_SUM has numerous advantages over dependency tarballs, but can not be > > used if the size of the EGO_SUM value crosses a threshold. So why not > > mandate dependency tarballs if a point is crossed and otherwise allow > > EGO_SUM? That way, we could have the best of both worlds. > > > > - Flow > > > > ++ this sounds most sensible. This is also how I've understood your > proposal. Remember that with EGO_SUM all of the bloated manifests and ebuilds are on every user's system. I added mgorny as a cc to this message because he made it pretty clear at some point in the previous discussion that the size of these ebuilds and manifests is unacceptable. William signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
On Wed, Jul 06, 2022 at 02:42:34PM +0200, Florian Schmaus wrote: > On 04/07/2022 17.27, David Seifert wrote: > > Ultimately, all these things really matter when only the defaults > > change. Turn-right-on-red in the US is such a thing, because unless > > otherwise stated, it's the norm. Knowing our devbase, with roughly 75% > > mostly AWOL and barely reading the MLs, I don't think this idea will > > bring about the desired change. > > This sounds like you assume that the majority of Gentoo devs are OK with > other people making changes to their packages. This very well could be > true, but without an indication you never know if the maintainer feels > this way. I was on vacation when this thread started, so that's why I'm responding now. The default assumption according to the dev manual is that maintainers are not ok with others touching their packages without permission except for very trivial changes. IMO this is the safer default. https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html > > > > Instead, we should really just go for > > the tag, because my feeling is that > > the default will be that most maintainers don't mind non-maintainer > > commits, except a select few territorial ones. > > It appears that we have at least two options here: > > A) Establish that the default is non-maintainer-commits-welcome, and > introduce a metadata element. This would go against the default from the dev manual, so if we go with it, which I do not recommend, we should fix the dev manual. > B) Declare the default to be unspecified and introduce two metadata > elements: and > . > > I think you are proposing A) here, but please correct me if I am wrong. > > Personally I would tend to B). But I have no strong opinion on this, as > long as some kind of signalling is established. > > How do others feel about this? I would suggest the default be consistent with the dev manual and we add a element. William signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-project] gitlab accessibility
Let's keep this thread on -project, so please see my answer there. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Mon, Jun 27, 2022 at 01:43:19AM +0200, Zoltan Puskas wrote: *snip* > First of all one of the advantages of Gentoo is that it gets it's source > code from upstream (yes, I'm aware of mirrors acting as a cache layer), > which means that poisoning source code needs to be done at upstream > level (effectively means hacking GitHub, PyPi, or some standalone > project's Gitea/cgit/gitlab/etc. instance or similar), sources which > either have more scrutiny or have a limited blast radius. I don't quite follow what you mean. Upstream for go modules is actually proxy.golang.org, or some other similar proxy, which the go tooling knows how to access [1]. > Additionally if an upstream dependency has a security issue it's easier > to scan all EGO_SUM content and find packages that potentially depend on > a broken dependency and force a re-pinning and rebuild. The tarball > magic hides this completely and makes searching very expensive. I'm not comfortable at all with us changing the dependencies like this downstream for the same reason the Debian folks ultimately were against it for kubernetes. If you make these kinds of changes you are affectively creating a fork, and that would mean we would be building packages with untested libraries [2]. *snip* > Considering that BTRFS (and possibly other filesystems) support on the > fly compression the physical cost of a few inflated ebuilds and The problem here is the size of SRC_URI when you add the EGO_SUM_SRC_URI to it. SRC_URI gets exported to the environment, so it can crash portage if it is too big. > Manifests is actually way smaller than the logical size would indicate. > Compare that to the huge incompressible tarballs that now we need to > store. > > As a proxied maintainer or overlay owner hosting these huge tarballs > also becomes problem (i.e. we need some public space with potentially > gigabytes of free space and enough bandwidth to push that to users). > Pushing toward vendor tarballs creates an extra expense on every level > (Gentoo infra, mirrors, proxy maintainers, overlay owners, users). I agree that creating the dependency tarballs is not ideal. We asked for another option [3], but as you can see from the bug this was refused by the PMS team. That refusal is the only reason we have to worry about dependency tarballs. > It also breaks reproducibility. With EGO_SUM I can check out an older > version of portage tree (well to some extent) and rebuild packages since > dependency upstream is very likely to host old versions of their source. > With the tarballs this breaks since as soon as an ebuild is dropped from > mainline portage the vendor tarballs follow them too. There is no way > for the user to roll back a package a few weeks back (e.g. if new > version has bugs), unlike with EGO_SUM. The contents of a dependency tarball is created using "go mod download", which is controlled by the go.mod/go.sum files in the package. So, it is possible to recreate the dependency tarball any time. I do not see any advantage EGO_SUM offers over the dependency tarballs in this space. > Finally with EGO_SUM we had a nice tool get-ego-vendor which produced > the EGO_SUM for maintainers which has made maintenance easier. However I > haven't found any new guidance yet on how to maintain go packages with > the new tarball method (e.g. what needs to go into the vendor tarball, > what changes are needed in ebuilds). Overall this complifates further > ebuild development and verification of PRs. The documentation for how to build dependency tarballs is in the eclass. The GOMODCACHE environment variable is used in the eclass to point to the location where the dependency tarball is unpacked, and that location is read by the normal go tooling. > In summary, IMHO the EGO_SUM way of handling of go packages has more > benefits than drawbacks compared to the vendor tarballs. EGO_SUM can cause portage to break; that is the primary reason support is going away. We attempted another solution that was refused, so the only option we have currently is to build the dependency tarballs. > > Cheers, > Zoltan > > [1] > https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ > [1] https://go.dev/ref/mod [2] https://lwn.net/Articles/835599/ [3] https://bugs.gentoo.org/833567 signature.asc Description: PGP signature
[gentoo-dev] last rites: dev-util/cligh
# William Hubbs (2022-06-17) # Dead upstream, please use dev-util/github-cli # Bug #845921 # Removal: 2022-07-17 dev-util/cligh Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Mon, Jun 13, 2022 at 12:26:43PM +0200, Ulrich Mueller wrote: > > On Mon, 13 Jun 2022, Florian Schmaus wrote: > > Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, > where some voices where in agreement that EGO_SUM has its raison d'être, > while there where no arguments in favor of eventually removing EGO_SUM, > I hereby propose to undeprecate EGO_SUM. > > 1: > https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa > > >> Can this be done without requesting changes to package managers? > > > What is 'this' here? > > Undeprecating EGO_SUM. > > > The patchset does not make changes to any package manager, just the > > go-module eclass. > > > Note that this is not about finding about an alternative to dependency > > tarballs. It is just about re-allowing EGO_SUM in addition to > > dependency tarballs for packaging Go software in Gentoo. Like I said on my earlier reply, there have been packages that break using EGO_SUM. Also, Robin's proposal will not be happening, if it does, for some time since it will require an eapi bump and doesn't have a working implementation. The most pressing concern about EGO_SUM is that it can make portage crash because of the size of SRC_URI, so it definitely should not be preferred over dependency tarballs. If you want to chat more about this on the list we can, but for now, let's not undeprecate EGO_SUM in the eclass. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] go-module.eclass: undeprecate EGO_SUM
On Mon, Jun 13, 2022 at 09:44:11AM +0200, Florian Schmaus wrote: > Following the gentoo-dev@ mailing list discussion [1], this > un-deprecates EGO_SUM. Sorry I haven't been on this list in a a while (I've been pretty busy with work). Did you talk to the pms team about https://bugs.gentoo.org/833567? I knew about Robin's proposal, but there isn't a working version of that yet, and I've seen packages break portage using EGO_SUM. William signature.asc Description: PGP signature
[gentoo-dev] [POC PATCH] go-module.eclass: remove deprecated code
This is not being merged. I am posting it now to show how I want
the eclass to change after the usage of EGO_SUM is removed from the tree.
I will re-post before I merge.
---
eclass/go-module.eclass | 359 +---
1 file changed, 5 insertions(+), 354 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 817f8a9fd3e..557f3fb9654 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -104,85 +104,6 @@ QA_FLAGS_IGNORED='.*'
# Go packages should not be stripped with strip(1).
RESTRICT+=" strip"
-# @ECLASS-VARIABLE: EGO_SUM
-# @DEPRECATED:
-# @DESCRIPTION:
-# This is replaced by a dependency tarball, see above for how to create
-# one.
-#
-# This array is based on the contents of the go.sum file from the top
-# level directory of the software you are packaging. Each entry must be
-# quoted and contain the first two fields of a line from go.sum.
-#
-# You can use some combination of sed/awk/cut to extract the
-# contents of EGO_SUM or use the dev-go/get-ego-vendor tool.
-#
-# One manual way to do this is the following:
-#
-# @CODE
-#
-# cat go.sum | cut -d" " -f1,2 | awk '{print "\t\"" $0 "\""}'
-#
-# @CODE
-#
-# The format of go.sum is described upstream here:
-# https://go.dev/ref/mod#go-sum-files
-#
-# For inclusion in EGO_SUM, the h1: value and other future extensions SHOULD be
-# omitted at this time. The EGO_SUM parser will accept them for ease of ebuild
-# creation.
-#
-# h1: is the Hash1 structure used by upstream Go
-# The Hash1 is MORE stable than Gentoo distfile hashing, and upstream warns
-# that it's conceptually possible for the Hash1 value to remain stable while
-# the upstream zipfiles change. Here are examples that do NOT change the h1:
-# hash, but do change a regular checksum over all bytes of the file:
-# - Differing mtimes within zipfile
-# - Differing filename ordering with the zipfile
-# - Differing zipfile compression parameters
-# - Differing zipfile extra fields
-#
-# For Gentoo usage, the authors of this eclass feel that the h1: hash should
-# NOT be included in the EGO_SUM at this time in order to reduce size of the
-# ebuilds. This position will be reconsidered in future when a Go module
-# distfile collision comes to light, where the Hash1 value of two distfiles is
-# the same, but checksums over the file as a byte stream consider the files to
-# be different.
-#
-# This decision does NOT weaken Go module security, as Go will verify the
-# go.sum copy of the Hash1 values during building of the package.
-
-# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
-# @DEPRECATED:
-# @DESCRIPTION:
-# Golang module proxy service to fetch module files from. Note that the module
-# proxy generally verifies modules via the Hash1 code.
-#
-# Users in China may find some mirrors in the default list blocked, and should
-# explicitly set an entry in /etc/portage/mirrors for goproxy to
-# https://goproxy.cn/ or another mirror that is not blocked in China.
-# See https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/ for
-# further details
-#
-# This variable is NOT intended for user-level configuration of mirrors, but
-# rather to cover go modules that might exist only on specific Goproxy
-# servers for non-technical reasons.
-#
-# This variable should NOT be present in user-level configuration e.g.
-# /etc/portage/make.conf, as it will violate metadata immutability!
-#
-# I am considering removing this and just hard coding mirror://goproxy
-# below, so please do not rely on it.
-: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
-
-# @ECLASS-VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
-# @DEPRECATED:
-# @DESCRIPTION:
-# Mapping back from Gentoo distfile name to upstream distfile path.
-# Associative array to avoid O(N*M) performance when populating the GOPROXY
-# directory structure.
-declare -A -g _GOMODULE_GOSUM_REVERSE_MAP
-
# @ECLASS-VARIABLE: GO_OPTIONAL
# @DEFAULT_UNSET
# @PRE_INHERIT
@@ -205,260 +126,17 @@ ego() {
"$@" || die -n "${*} failed"
}
-# @FUNCTION: go-module_set_globals
-# @DEPRECATED:
-# @DESCRIPTION:
-# Convert the information in EGO_SUM for other usage in the ebuild.
-# - Populates EGO_SUM_SRC_URI that can be added to SRC_URI
-# - Exports _GOMODULE_GOSUM_REVERSE_MAP which provides reverse mapping from
-# distfile back to the relative part of SRC_URI, as needed for
-# GOPROXY=file:///...
-go-module_set_globals() {
- local line exts
- # for tracking go.sum errors
- local error_in_gosum=0
- local -a gosum_errorlines
- # used make SRC_URI easier to read
- local newline=$'\n'
-
- # Now parse EGO_SUM
- for line in "${EGO_SUM[@]}"; do
- local module version modfile version_modfile kvs x
- read -r module version_modfile kvs <<< "${line}"
- # kvs contains the hash and may contain other data from
- # upstream in the future. We do not currently use any of this
data.
-
-
Re: [gentoo-dev] Deprecating repoman
On Thu, Mar 10, 2022 at 09:29:59AM -0800, Matt Turner wrote: > On Wed, Mar 9, 2022 at 11:09 PM Joonas Niilola wrote: > > > > On 9.3.2022 23.00, Matt Turner wrote: > > > I'd like to deprecate and ultimately remove repoman. I believe that > > > dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts) > > > are far superior replacements, and it makes sense to have people using > > > the same tool and seeing the same warnings as in the CI. > > > > > > Are there any useful checks or behaviors of repoman that are missing > > > from pkgcheck and pkgcommit? > > > > > > Thanks, > > > Matt > > > > > > > I still fail to see the "why" in here. Repoman is better than pure 'git > > commit' that I know some people still like to use, and as long as it's > > kept maintained. > > repoman is inferior to other tooling mentioned. The other tooling is > actually run in CI. Developers should get the same warnings locally as > in CI. Restated another way: I'm tired of telling people to stop using > repoman or "pkgcheck would have caught that". I am going to nit-pick here, but pkgcheck pulls in pkgcore still. As far asI know, pkgcore was meant to be a portage-like package manager, but it isn't maintained. So, can we break that dependency before we make pkgcheck the official tool for qa checks? I would rather not have pkgcore landing on everyone's systems unless it is usable. If I am wrong about pkgcore, please correct me and I'll be quiet, but if not let's make pkgcheck independent from it before we deprecate repoman. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v5] go-module.eclass: deprecate EGO_SUM
On Mon, Mar 07, 2022 at 01:10:46PM +0100, tastytea wrote:
> On 2022-03-05 16:17-0600 William Hubbs wrote:
>
> > +# @CODE
> > +#
> > +# $ cd /path/to/project
> > +# $ GOMODCACHE="${PWD}"/go-mod go mod download -modcacherw
> > +# $ tar -acf project-1.0-deps.tar.xz go-mod
>
> What's the reason to use `go mod download` here and not `go mod
> vendor`? The former seems to always generate much bigger directories.
> For www-apps/hugo it is 1.5G vs. 65M and someone on IRC mentioned that
> for another ebuild it is >600M vs 22M.
You are correct, it does generate bigger directories. "go mod vendor"
doesn't preserve everything needed to make some builds happen, so I had
to go with "go mod download". For more info, see the following upstream
issue (note that several folks have asked for the discussion to be
restarted; I haven't seen any responses yet).
http://github.com/golang/go/issues/26366
Thanks,
William
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH v5] go-module.eclass: deprecate EGO_SUM
On Sun, Mar 06, 2022 at 09:20:03AM +, Sam James wrote:
>
>
> > On 5 Mar 2022, at 22:17, William Hubbs wrote:
> >
> >EGO_SUM can be thousands of lines long in ebuilds, and it leads to
> >creating Manifest files that are thousands of lines long.
> >It has been determined that dependency tarballs are a better solution if
> >upstream doesn't vendor their dependencies.
> >
> >Signed-off-by: William Hubbs
> > ---
> > [snip]
>
> > -#
> > -# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> > ${P}.tar.gz
> > -# ${EGO_SUM_SRC_URI}"
> > +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> > ${P}.tar.gz"
> > +# Add this line if you have a dependency tarball.
> > +# SRC_URI+=" ${P}-dep.tar.xz"
>
> In #gentoo-dev-help, Weiss-Fder[m] pointed out this should be 'deps'.
This is fixed and the patch is merged.
Thanks,
William
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH v5] go-module.eclass: deprecate EGO_SUM
EGO_SUM can be thousands of lines long in ebuilds, and it leads to
creating Manifest files that are thousands of lines long.
It has been determined that dependency tarballs are a better solution if
upstream doesn't vendor their dependencies.
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 45 ++---
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 635d2b5161a..2d42758c6f4 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,8 +25,20 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. Otherwise, you need to also populate
-# EGO_SUM and call go-module_set_globals as discussed below.
+# eclass. If it doesn't, you need to also create a dependency tarball and
+# host it somewhere, for example in your dev space.
+#
+# Here is an example of how to create a dependency tarball.
+# The base directory in the GOMODCACHE setting must be go-mod in order
+# to match the settings in this eclass.
+#
+# @CODE
+#
+# $ cd /path/to/project
+# $ GOMODCACHE="${PWD}"/go-mod go mod download -modcacherw
+# $ tar -acf project-1.0-deps.tar.xz go-mod
+#
+# @CODE
#
# Since Go programs are statically linked, it is important that your ebuild's
# LICENSE= setting includes the licenses of all statically linked
@@ -40,15 +52,9 @@
#
# inherit go-module
#
-# EGO_SUM=(
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
-# )
-#
-# go-module_set_globals
-#
-# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz
-# ${EGO_SUM_SRC_URI}"
+# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
+# Add this line if you have a dependency tarball.
+# SRC_URI+=" ${P}-dep.tar.xz"
#
# @CODE
@@ -99,7 +105,11 @@ QA_FLAGS_IGNORED='.*'
RESTRICT+=" strip"
# @ECLASS-VARIABLE: EGO_SUM
+# @DEPRECATED:
# @DESCRIPTION:
+# This is replaced by a dependency tarball, see above for how to create
+# one.
+#
# This array is based on the contents of the go.sum file from the top
# level directory of the software you are packaging. Each entry must be
# quoted and contain the first two fields of a line from go.sum.
@@ -143,6 +153,7 @@ RESTRICT+=" strip"
# go.sum copy of the Hash1 values during building of the package.
# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
+# @DEPRECATED:
# @DESCRIPTION:
# Golang module proxy service to fetch module files from. Note that the module
# proxy generally verifies modules via the Hash1 code.
@@ -165,6 +176,7 @@ RESTRICT+=" strip"
: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
# @ECLASS-VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
+# @DEPRECATED:
# @DESCRIPTION:
# Mapping back from Gentoo distfile name to upstream distfile path.
# Associative array to avoid O(N*M) performance when populating the GOPROXY
@@ -194,6 +206,7 @@ ego() {
}
# @FUNCTION: go-module_set_globals
+# @DEPRECATED:
# @DESCRIPTION:
# Convert the information in EGO_SUM for other usage in the ebuild.
# - Populates EGO_SUM_SRC_URI that can be added to SRC_URI
@@ -284,6 +297,7 @@ go-module_set_globals() {
}
# @FUNCTION: go-module_setup_proxy
+# @DEPRECATED:
# @DESCRIPTION:
# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
# this function in src_unpack.
@@ -327,11 +341,14 @@ go-module_setup_proxy() {
# @FUNCTION: go-module_src_unpack
# @DESCRIPTION:
# If EGO_SUM is set, unpack the base tarball(s) and set up the
-# local go proxy.
+# local go proxy. Also warn that this usage is deprecated.
# - Otherwise, if EGO_VENDOR is set, bail out.
# - Otherwise do a normal unpack.
go-module_src_unpack() {
if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
+ eqawarn "This ebuild uses EGO_SUM which is deprecated"
+ eqawarn "Please migrate to a dependency tarball"
+ eqawarn "This will become a fatal error in the future"
_go-module_src_unpack_gosum
elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
eerror "${EBUILD} is using EGO_VENDOR which is no longer
supported"
@@ -342,6 +359,7 @@ go-module_src_unpack() {
}
# @FUNCTION: _go-module_src_unpack_gosum
+# @DEPRECATED:
# @DESCRIPTION:
# Populate a GOPROXY directory hierarchy with distfiles from EGO_SUM and
# unpack the base distfiles.
@@ -387,6 +405,7 @@ _go-module_src_unpack_gosum() {
}
# @FUNCTION: _go-module_gosum_synthesize_files
+# @DEPRECATED:
# @DESCRIPTION:
# Given a path & version, populate all Goproxy metadata files which aren't
# needed to be downloaded directly.
@@ -414,6 +433,7 @@ _go-module_gosum
[gentoo-dev] [PATCH v4] go-module.eclass: deprecate EGO_SUM
EGO_SUM can be thousands of lines long in ebuilds, and it leads to
creating Manifest files that are thousands of lines long.
It has been determined that dependency tarballs are a better solution if
upstream doesn't vendor their dependencies.
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 46 ++---
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 635d2b5161a..427a61a1b84 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,8 +25,21 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. Otherwise, you need to also populate
-# EGO_SUM and call go-module_set_globals as discussed below.
+# eclass. If it doesn't, you need to also create a dependency tarball and
+# host it somewhere, for example in your dev space.
+#
+# Here is an example of how to create a dependency tarball.
+# The base directory in the GOMODCACHE setting must be go-mod in order
+# to match the settings in this eclass.
+#
+# @CODE
+#
+# $ cd /path/to/project
+# $ GOMODCACHE=/path/to/go-mod go mod download -modcacherw
+# $ tar -acf project-1.0-deps.tar.xz /path/to/go-mod \
+# --xform 's,.*go-mod/,go-mod/'
+#
+# @CODE
#
# Since Go programs are statically linked, it is important that your ebuild's
# LICENSE= setting includes the licenses of all statically linked
@@ -40,15 +53,9 @@
#
# inherit go-module
#
-# EGO_SUM=(
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
-# )
-#
-# go-module_set_globals
-#
-# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz
-# ${EGO_SUM_SRC_URI}"
+# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
+# Add this line if you have a dependency tarball.
+# SRC_URI+=" ${P}-dep.tar.xz"
#
# @CODE
@@ -99,7 +106,11 @@ QA_FLAGS_IGNORED='.*'
RESTRICT+=" strip"
# @ECLASS-VARIABLE: EGO_SUM
+# @DEPRECATED:
# @DESCRIPTION:
+# This is replaced by a dependency tarball, see above for how to create
+# one.
+#
# This array is based on the contents of the go.sum file from the top
# level directory of the software you are packaging. Each entry must be
# quoted and contain the first two fields of a line from go.sum.
@@ -143,6 +154,7 @@ RESTRICT+=" strip"
# go.sum copy of the Hash1 values during building of the package.
# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
+# @DEPRECATED:
# @DESCRIPTION:
# Golang module proxy service to fetch module files from. Note that the module
# proxy generally verifies modules via the Hash1 code.
@@ -165,6 +177,7 @@ RESTRICT+=" strip"
: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
# @ECLASS-VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
+# @DEPRECATED:
# @DESCRIPTION:
# Mapping back from Gentoo distfile name to upstream distfile path.
# Associative array to avoid O(N*M) performance when populating the GOPROXY
@@ -194,6 +207,7 @@ ego() {
}
# @FUNCTION: go-module_set_globals
+# @DEPRECATED:
# @DESCRIPTION:
# Convert the information in EGO_SUM for other usage in the ebuild.
# - Populates EGO_SUM_SRC_URI that can be added to SRC_URI
@@ -284,6 +298,7 @@ go-module_set_globals() {
}
# @FUNCTION: go-module_setup_proxy
+# @DEPRECATED:
# @DESCRIPTION:
# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
# this function in src_unpack.
@@ -327,11 +342,14 @@ go-module_setup_proxy() {
# @FUNCTION: go-module_src_unpack
# @DESCRIPTION:
# If EGO_SUM is set, unpack the base tarball(s) and set up the
-# local go proxy.
+# local go proxy. Also warn that this usage is deprecated.
# - Otherwise, if EGO_VENDOR is set, bail out.
# - Otherwise do a normal unpack.
go-module_src_unpack() {
if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
+ eqawarn "This ebuild uses EGO_SUM which is deprecated"
+ eqawarn "Please migrate to a dependency tarball"
+ eqawarn "This will become a fatal error in the future"
_go-module_src_unpack_gosum
elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
eerror "${EBUILD} is using EGO_VENDOR which is no longer
supported"
@@ -342,6 +360,7 @@ go-module_src_unpack() {
}
# @FUNCTION: _go-module_src_unpack_gosum
+# @DEPRECATED:
# @DESCRIPTION:
# Populate a GOPROXY directory hierarchy with distfiles from EGO_SUM and
# unpack the base distfiles.
@@ -387,6 +406,7 @@ _go-module_src_unpack_gosum() {
}
# @FUNCTION: _go-module_gosum_synthesize_files
+# @DEPRECATED:
# @DESCRIPTION:
# Given a path & version, populate all Goproxy metadata files which aren't
# needed to be downloaded directly.
@@
[gentoo-dev] [PATCH v3] go-module.eclass: deprecate EGO_SUM
EGO_SUM can be thousands of lines long in ebuilds, and it leads to
creating Manifest files that are thousands of lines long.
It has been determined that dependency tarballs are a better solution if
upstream doesn't vendor their dependencies.
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 46 ++---
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 635d2b5161a..485f26096c3 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,8 +25,21 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. Otherwise, you need to also populate
-# EGO_SUM and call go-module_set_globals as discussed below.
+# eclass. If it doesn't, you need to also create a dependency tarball and
+# host it somewhere, for example in your dev space.
+#
+# Here is an example of how to create a dependency tarball.
+# go-mod is a temporary directory where the dependencies will be stored,
+# but it must be named go-mod to match the GOMODCACHE setting in this
+# eclass.
+#
+# @CODE
+#
+# $ cd /path/to/project
+# $ GOMODCACHE=go-mod go mod download -modcacherw
+# $ tar -acf project-1.0-deps.tar.xz go-mod
+#
+# @CODE
#
# Since Go programs are statically linked, it is important that your ebuild's
# LICENSE= setting includes the licenses of all statically linked
@@ -40,15 +53,9 @@
#
# inherit go-module
#
-# EGO_SUM=(
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
-# )
-#
-# go-module_set_globals
-#
-# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz
-# ${EGO_SUM_SRC_URI}"
+# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
+# Add this line if you have a dependency tarball.
+# SRC_URI+=" ${P}-dep.tar.xz"
#
# @CODE
@@ -99,7 +106,11 @@ QA_FLAGS_IGNORED='.*'
RESTRICT+=" strip"
# @ECLASS-VARIABLE: EGO_SUM
+# @DEPRECATED:
# @DESCRIPTION:
+# This is replaced by a dependency tarball, see above for how to create
+# one.
+#
# This array is based on the contents of the go.sum file from the top
# level directory of the software you are packaging. Each entry must be
# quoted and contain the first two fields of a line from go.sum.
@@ -143,6 +154,7 @@ RESTRICT+=" strip"
# go.sum copy of the Hash1 values during building of the package.
# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
+# @DEPRECATED:
# @DESCRIPTION:
# Golang module proxy service to fetch module files from. Note that the module
# proxy generally verifies modules via the Hash1 code.
@@ -165,6 +177,7 @@ RESTRICT+=" strip"
: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
# @ECLASS-VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
+# @DEPRECATED:
# @DESCRIPTION:
# Mapping back from Gentoo distfile name to upstream distfile path.
# Associative array to avoid O(N*M) performance when populating the GOPROXY
@@ -194,6 +207,7 @@ ego() {
}
# @FUNCTION: go-module_set_globals
+# @DEPRECATED:
# @DESCRIPTION:
# Convert the information in EGO_SUM for other usage in the ebuild.
# - Populates EGO_SUM_SRC_URI that can be added to SRC_URI
@@ -284,6 +298,7 @@ go-module_set_globals() {
}
# @FUNCTION: go-module_setup_proxy
+# @DEPRECATED:
# @DESCRIPTION:
# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
# this function in src_unpack.
@@ -327,11 +342,14 @@ go-module_setup_proxy() {
# @FUNCTION: go-module_src_unpack
# @DESCRIPTION:
# If EGO_SUM is set, unpack the base tarball(s) and set up the
-# local go proxy.
+# local go proxy. Also warn that this usage is deprecated.
# - Otherwise, if EGO_VENDOR is set, bail out.
# - Otherwise do a normal unpack.
go-module_src_unpack() {
if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
+ eqawarn "This ebuild uses EGO_SUM which is deprecated"
+ eqawarn "Please migrate to a dependency tarball"
+ eqawarn "This will become a fatal error in the future"
_go-module_src_unpack_gosum
elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
eerror "${EBUILD} is using EGO_VENDOR which is no longer
supported"
@@ -342,6 +360,7 @@ go-module_src_unpack() {
}
# @FUNCTION: _go-module_src_unpack_gosum
+# @DEPRECATED:
# @DESCRIPTION:
# Populate a GOPROXY directory hierarchy with distfiles from EGO_SUM and
# unpack the base distfiles.
@@ -387,6 +406,7 @@ _go-module_src_unpack_gosum() {
}
# @FUNCTION: _go-module_gosum_synthesize_files
+# @DEPRECATED:
# @DESCRIPTION:
# Given a path & version, populate all Goproxy metadata files which aren't
# needed to be downloaded directly.
@@ -414,6 +
Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Fri, Mar 04, 2022 at 12:01:42AM +, Sam James wrote: > > > > On 4 Mar 2022, at 00:00, William Hubbs wrote: > > > > On Wed, Mar 02, 2022 at 09:32:14PM +0500, Anna Vyalkova wrote: > >> On 2022-03-01 15:55, William Hubbs wrote: > >>> I am willing to flag EGO_SUM as deprecated if a variable can be flagged > >>> as deprecated; that is what I'm looking up now. > >> > >> EGO_SUM is often the only choice for overlays, so consider not > >> deprecating it. > > > > EGO_SUM does not work for large SRC_URI; that is the reason it is > > being deprecated. > > > > Also, my understanding is we do not normally keep code around > > if that code's only purpose is to support overlays. > > I don't think there's a need to rip it out given we know it can be quite > useful there though, right? > > It's not actively harming anything to just keep the small amount of code > there. Sure, it may not be harmful to keep it there, but using it in the main tree isn't going to be a thing. > I think it's quite a nice convenience option (in fact, for ::gentoo too), > where > EGO_SUM isn't huge. But I admit this isn't that common. Another thing to consider is that the bulk of the code in the eclass is for handling EGO_SUM, so if I can remove it, ultimately, it will mean less code to maintain. I will post a separate patch which I will not merge at this point to show what I'm talking about. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Wed, Mar 02, 2022 at 09:32:14PM +0500, Anna Vyalkova wrote: > On 2022-03-01 15:55, William Hubbs wrote: > > I am willing to flag EGO_SUM as deprecated if a variable can be flagged > > as deprecated; that is what I'm looking up now. > > EGO_SUM is often the only choice for overlays, so consider not > deprecating it. EGO_SUM does not work for large SRC_URI; that is the reason it is being deprecated. Also, my understanding is we do not normally keep code around if that code's only purpose is to support overlays. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Tue, Mar 01, 2022 at 09:03:52PM +, Sam James wrote: > > > > On 27 Feb 2022, at 04:38, William Hubbs wrote: > > > > EGO_SUM can be thousands of lines long in ebuilds, and it leads to > > creating Manifest files that are thousands of lines long. > > It has been determined that vendor tarballs are a better solution if > > upstream doesn't vendor their dependencies. > > > > Also, call the ego helper function instead of calling go directly. > > > > Signed-off-by: William Hubbs > > --- > > Per comments on IRC, I suggest not removing the EGO_SUM > examples for now until we've got good documentation and tooling > for vendor stuff, and a transition period is completed. I would rather not keep the EGO_SUM documentation. I do not want any new ebuilds coming into the tree using it. I am willing to flag EGO_SUM as deprecated if a variable can be flagged as deprecated; that is what I'm looking up now. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Sun, Feb 27, 2022 at 12:17:45PM +0100, Ulrich Mueller wrote: > >>>>> On Sun, 27 Feb 2022, Ionen Wolkens wrote: > > > On Sat, Feb 26, 2022 at 10:38:33PM -0600, William Hubbs wrote: > >> +# eclass. If it doesn't, you need to also create a vendor tarball and > > > Unnecessary double space. > > No. It is a sentence end, so the double space is mandatory. > > (The reason is that we generate manpages from eclass documentation, > so we should follow groff conventions for sentence ends.) I've never heard of this convention, and there many places in eclasses, including this one, that have a single space as a sentence end. that have a single space at a sentence end, so I will go ahead and fix this. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Sun, Feb 27, 2022 at 12:46:00AM -0500, Ionen Wolkens wrote:
> On Sat, Feb 26, 2022 at 10:38:33PM -0600, William Hubbs wrote:
> > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> > index 66fe52c9ad7..b9686ad555a 100644
> > --- a/eclass/go-module.eclass
> > +++ b/eclass/go-module.eclass
> > @@ -25,9 +25,26 @@
> > #
> > # If the software has a directory named vendor in its
> > # top level directory, the only thing you need to do is inherit the
> > -# eclass. Otherwise, you need to also populate
> > -# EGO_SUM and call go-module_set_globals as discussed below.
> > +# eclass. If it doesn't, you need to also create a vendor tarball and
>
> Unnecessary double space.
>
> > +# host it somewhere, for example in your dev space.
> > #
> > +# Here are the commands to create a vendor tarball.
> > +#
> > +# @CODE
> > +#
> > +# $ cd /path/to/project
> > +# $ go mod vendor
> > +# $ tar -acf project-1.0-vendor.tar.xz vendor --xform 's:^":project-1.0/:'
>
> Typo, that " doesn't exist at start of paths and it'd do nothing.
> Should just be 's:^:project-1.0/:'
This is fixed.
>
> > -# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> > ${P}.tar.gz
> > -# ${EGO_SUM_SRC_URI}"
> > +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> > ${P}.tar.gz"
> > +# Do not add the next line if you don't have a vendor tarball
> > +# SRC_URI+="${P}-vendor.tar.gz"
>
> Since example use .xz, should use it over .gz for vendor tarball.
Fixed, but note that it doesn't really matter. you can use .z, .gz,
.zip, or whatever you want to use.
>
> > @@ -256,7 +197,7 @@ go-module_set_globals() {
> > # Relative URI within a GOPROXY for a file
> > _reluri="${_dir}/@v/${version}.${_ext}"
> > # SRC_URI: LHS entry
> > - _uri="${_GOMODULE_GOPROXY_BASEURI}/${_reluri}"
> > + _uri="mirror://goproxy/${_reluri}"
> > # _uri="mirror://goproxy/${_reluri}"
>
> Unnecessary comment that duplicates the now-used above line.
This part of the eclass is out of scope for what I was changing, and
since most of this code will go away eventually, I'm not really worried
about this extra comment.
William
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go
EGO_SUM can be thousands of lines long in ebuilds, and it leads to
creating Manifest files that are thousands of lines long.
It has been determined that vendor tarballs are a better solution if
upstream doesn't vendor their dependencies.
Also, call the ego helper function instead of calling go directly.
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 144 +++-
1 file changed, 38 insertions(+), 106 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 66fe52c9ad7..b9686ad555a 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,9 +25,26 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. Otherwise, you need to also populate
-# EGO_SUM and call go-module_set_globals as discussed below.
+# eclass. If it doesn't, you need to also create a vendor tarball and
+# host it somewhere, for example in your dev space.
#
+# Here are the commands to create a vendor tarball.
+#
+# @CODE
+#
+# $ cd /path/to/project
+# $ go mod vendor
+# $ tar -acf project-1.0-vendor.tar.xz vendor --xform 's:^":project-1.0/:'
+#
+# @CODE
+#
+# Note that 'go mod vendor' drops files from the dependency tree, and
+# this causes errors with some builds. If your build crashes with errors
+# like the ones mentioned in the below issue, you will need to emerge
+# dev-go/vend and replace 'go mod vendor' above with 'vend'.
+#
+# https://github.com/golang/go/issues/26366
+#
# Since Go programs are statically linked, it is important that your ebuild's
# LICENSE= setting includes the licenses of all statically linked
# dependencies. So please make sure it is accurate.
@@ -40,15 +57,9 @@
#
# inherit go-module
#
-# EGO_SUM=(
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
-# )
-#
-# go-module_set_globals
-#
-# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz
-# ${EGO_SUM_SRC_URI}"
+# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
+# Do not add the next line if you don't have a vendor tarball
+# SRC_URI+="${P}-vendor.tar.gz"
#
# @CODE
@@ -100,72 +111,6 @@ QA_FLAGS_IGNORED='.*'
# Go packages should not be stripped with strip(1).
RESTRICT+=" strip"
-# @ECLASS-VARIABLE: EGO_SUM
-# @DESCRIPTION:
-# This array is based on the contents of the go.sum file from the top
-# level directory of the software you are packaging. Each entry must be
-# quoted and contain the first two fields of a line from go.sum.
-#
-# You can use some combination of sed/awk/cut to extract the
-# contents of EGO_SUM or use the dev-go/get-ego-vendor tool.
-#
-# One manual way to do this is the following:
-#
-# @CODE
-#
-# cat go.sum | cut -d" " -f1,2 | awk '{print "\t\"" $0 "\""}'
-#
-# @CODE
-#
-# The format of go.sum is described upstream here:
-# https://go.dev/ref/mod#go-sum-files
-#
-# For inclusion in EGO_SUM, the h1: value and other future extensions SHOULD be
-# omitted at this time. The EGO_SUM parser will accept them for ease of ebuild
-# creation.
-#
-# h1: is the Hash1 structure used by upstream Go
-# The Hash1 is MORE stable than Gentoo distfile hashing, and upstream warns
-# that it's conceptually possible for the Hash1 value to remain stable while
-# the upstream zipfiles change. Here are examples that do NOT change the h1:
-# hash, but do change a regular checksum over all bytes of the file:
-# - Differing mtimes within zipfile
-# - Differing filename ordering with the zipfile
-# - Differing zipfile compression parameters
-# - Differing zipfile extra fields
-#
-# For Gentoo usage, the authors of this eclass feel that the h1: hash should
-# NOT be included in the EGO_SUM at this time in order to reduce size of the
-# ebuilds. This position will be reconsidered in future when a Go module
-# distfile collision comes to light, where the Hash1 value of two distfiles is
-# the same, but checksums over the file as a byte stream consider the files to
-# be different.
-#
-# This decision does NOT weaken Go module security, as Go will verify the
-# go.sum copy of the Hash1 values during building of the package.
-
-# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
-# @DESCRIPTION:
-# Golang module proxy service to fetch module files from. Note that the module
-# proxy generally verifies modules via the Hash1 code.
-#
-# Users in China may find some mirrors in the default list blocked, and should
-# explicitly set an entry in /etc/portage/mirrors for goproxy to
-# https://goproxy.cn/ or another mirror that is not blocked in China.
-# See https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/ for
-# further details
-#
-# This variable is NOT intended for user-level configuration of mi
Re: [gentoo-dev] [PATCH] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Sat, Feb 26, 2022 at 01:45:24PM -0500, Ionen Wolkens wrote: > On Sat, Feb 26, 2022 at 11:55:10AM -0600, William Hubbs wrote: > > If I change the instructions as you suggest to re-package upstream's > > tarball the name wouldn't need the -vendor suffix since the tarball would > > be a > > fork, but I'm not asking people to fork and repackage upstream's tarballs, > > just > > the vendor folder. Fortunately, there is no reason to fork since it is very > > easy to package the vendor folder with Go's tools. > > Doing: > tar ... project-1.0-vendor.tar.xz project-1.0/vendor > > would only package the "vendor" directory and not the whole > project directory. Then when auto-unpacked by src_unpack, the > vendor directory is added under project-1.0/ > > So this isn't repacking upstream's or a fork. Ok, I get what you are saying, but normally the directory you have the package in doesn't have a version number if you are working from a git repository, so I don't know how to get around this: cd path/to/project # note, no version number in "project" go mod vendor cd .. tar -acf project/vendor project-1.0-vendor.tar.xz This will put everything in the tarball under "project/" instead of "project-1.0/". Does tar have an option to change that top level path that I don't know about? Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] go-module.eclass: deprecate EGO_SUM and call ego instead of go
On Sat, Feb 26, 2022 at 08:25:59AM +0100, Michał Górny wrote: > On Fri, 2022-02-25 at 20:50 -0600, William Hubbs wrote: > > EGO_SUM can be thousands of lines long in ebuilds, and it leads to > > creating Manifest files that are thousands of lines long. > > It has been determined that vendor tarballs are a better solution if > > upstream doesn't vendor their dependencies. > > > > Also, call the ego helper function instead of calling go directly. > > > > Signed-off-by: William Hubbs > > --- > > eclass/go-module.eclass | 140 ++-- > > 1 file changed, 34 insertions(+), 106 deletions(-) > > > > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass > > index 66fe52c9ad7..7f0d766f444 100644 > > --- a/eclass/go-module.eclass > > +++ b/eclass/go-module.eclass > > @@ -25,8 +25,18 @@ > > # > > # If the software has a directory named vendor in its > > # top level directory, the only thing you need to do is inherit the > > -# eclass. Otherwise, you need to also populate > > -# EGO_SUM and call go-module_set_globals as discussed below. > > +# eclass. If it doesn't, you need to also create a vendor tarball and > > +# host it somewhere, for example in your dev space. > > +# > > +# Here are the commands to create a vendor tarball. > > +# > > +# @CODE > > +# > > +# $ cd /path/to/project > > +# $ go mod vendor > > +# $ tar -acf project-1.0.tar.xz vendor > > Why not 'cd ..' first and create a tarball that doesn't require custom > src_unpack()? Also, shouldn't the name be 'project-1.0-vendor.tar'? > Also, you're mising -J. Using -a and -J together doesn't make sense since -a uses the suffix on the file name to determine which compressor to use. If I change the instructions as you suggest to re-package upstream's tarball the name wouldn't need the -vendor suffix since the tarball would be a fork, but I'm not asking people to fork and repackage upstream's tarballs, just the vendor folder. Fortunately, there is no reason to fork since it is very easy to package the vendor folder with Go's tools. To move the unpacked vendor folder to the right place, I have two choices, src_unpack and src_prepare. Since we already have a custom src_unpack, it is less invasive to do this there. If I use src_prepare, it would force me to bump the eclass, which I'm not interested in doing. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] go-module.eclass: add helper function to call go
This is in the tree. Thanks, William signature.asc Description: PGP signature
[gentoo-dev] [PATCH] go-module.eclass: deprecate EGO_SUM and call ego instead of go
EGO_SUM can be thousands of lines long in ebuilds, and it leads to
creating Manifest files that are thousands of lines long.
It has been determined that vendor tarballs are a better solution if
upstream doesn't vendor their dependencies.
Also, call the ego helper function instead of calling go directly.
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 140 ++--
1 file changed, 34 insertions(+), 106 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 66fe52c9ad7..7f0d766f444 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,8 +25,18 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. Otherwise, you need to also populate
-# EGO_SUM and call go-module_set_globals as discussed below.
+# eclass. If it doesn't, you need to also create a vendor tarball and
+# host it somewhere, for example in your dev space.
+#
+# Here are the commands to create a vendor tarball.
+#
+# @CODE
+#
+# $ cd /path/to/project
+# $ go mod vendor
+# $ tar -acf project-1.0.tar.xz vendor
+#
+# @CODE
#
# Since Go programs are statically linked, it is important that your ebuild's
# LICENSE= setting includes the licenses of all statically linked
@@ -40,15 +50,9 @@
#
# inherit go-module
#
-# EGO_SUM=(
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
-# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
-# )
-#
-# go-module_set_globals
-#
-# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz
-# ${EGO_SUM_SRC_URI}"
+# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
+# Do not add the next line if you don't have a vendor tarball
+# SRC_URI+="${P}-vendor.tar.gz"
#
# @CODE
@@ -100,72 +104,6 @@ QA_FLAGS_IGNORED='.*'
# Go packages should not be stripped with strip(1).
RESTRICT+=" strip"
-# @ECLASS-VARIABLE: EGO_SUM
-# @DESCRIPTION:
-# This array is based on the contents of the go.sum file from the top
-# level directory of the software you are packaging. Each entry must be
-# quoted and contain the first two fields of a line from go.sum.
-#
-# You can use some combination of sed/awk/cut to extract the
-# contents of EGO_SUM or use the dev-go/get-ego-vendor tool.
-#
-# One manual way to do this is the following:
-#
-# @CODE
-#
-# cat go.sum | cut -d" " -f1,2 | awk '{print "\t\"" $0 "\""}'
-#
-# @CODE
-#
-# The format of go.sum is described upstream here:
-# https://go.dev/ref/mod#go-sum-files
-#
-# For inclusion in EGO_SUM, the h1: value and other future extensions SHOULD be
-# omitted at this time. The EGO_SUM parser will accept them for ease of ebuild
-# creation.
-#
-# h1: is the Hash1 structure used by upstream Go
-# The Hash1 is MORE stable than Gentoo distfile hashing, and upstream warns
-# that it's conceptually possible for the Hash1 value to remain stable while
-# the upstream zipfiles change. Here are examples that do NOT change the h1:
-# hash, but do change a regular checksum over all bytes of the file:
-# - Differing mtimes within zipfile
-# - Differing filename ordering with the zipfile
-# - Differing zipfile compression parameters
-# - Differing zipfile extra fields
-#
-# For Gentoo usage, the authors of this eclass feel that the h1: hash should
-# NOT be included in the EGO_SUM at this time in order to reduce size of the
-# ebuilds. This position will be reconsidered in future when a Go module
-# distfile collision comes to light, where the Hash1 value of two distfiles is
-# the same, but checksums over the file as a byte stream consider the files to
-# be different.
-#
-# This decision does NOT weaken Go module security, as Go will verify the
-# go.sum copy of the Hash1 values during building of the package.
-
-# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
-# @DESCRIPTION:
-# Golang module proxy service to fetch module files from. Note that the module
-# proxy generally verifies modules via the Hash1 code.
-#
-# Users in China may find some mirrors in the default list blocked, and should
-# explicitly set an entry in /etc/portage/mirrors for goproxy to
-# https://goproxy.cn/ or another mirror that is not blocked in China.
-# See https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/ for
-# further details
-#
-# This variable is NOT intended for user-level configuration of mirrors, but
-# rather to cover go modules that might exist only on specific Goproxy
-# servers for non-technical reasons.
-#
-# This variable should NOT be present in user-level configuration e.g.
-# /etc/portage/make.conf, as it will violate metadata immutability!
-#
-# I am considering removing this and just hard coding mirror://goproxy
-# below, so please do not rely on it.
-: "${_GOMODULE_GOPROXY_BASEURI:=mirr
[gentoo-dev] [PATCH] go-module.eclass: add helper function to call go
This function will cause the ebuild to die if Go fails.
Also, it outputs the go command that is being run.
Closes: https://bugs.gentoo.org/833497
---
eclass/go-module.eclass | 13 +
1 file changed, 13 insertions(+)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 53f4a026942..66fe52c9ad7 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -184,6 +184,19 @@ declare -A -g _GOMODULE_GOSUM_REVERSE_MAP
# 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: ego
+# @USAGE: [...]
+# @DESCRIPTION:
+# Call go, passing the supplied arguments.
+# This function dies if go fails. It also supports being called via 'nonfatal'.
+# If you need to call go directly in your ebuilds, this is the way it
+# should be done.
+ego() {
+ set -- go "$@"
+ echo "$@" >&2
+ "$@" || die -n "${*} failed"
+}
+
# @FUNCTION: go-module_set_globals
# @DESCRIPTION:
# Convert the information in EGO_SUM for other usage in the ebuild.
--
2.34.1
Re: [gentoo-dev] last rites dev-go/blackfriday
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
# 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
This is committed. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] tmpfiles.eclass: add eapi 8 support
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
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
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
# 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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
# 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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
