Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote: > On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: > > On 9/16/19 11:35 AM, William Hubbs wrote: > > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > > > > For packages that I maintain, I'd prefer to continue using EGO_VENDOR to > > > > even with packages using go.mod. I hope that this go-module.class will > > > > not preclude this sort of usage. For example, the latest go-tools ebuild > > > > uses EGO_VENDOR together with GOFLAGS="-mod=vendor": > > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f > > > > > > Can you elaborate on why you want to keep EGO_VENDOR? > > > > > > The "go mod vendor" command above downloads all the correct versions > > > of the dependencies and puts them in the vendor directory, so I'm not > > > sure why you would need the EGO_VENDOR variable. > > > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs > > containing vendored dependencies. It's more space-efficient in the sense > > that each vendored dependency is stored in a separate tarball, so > > multiple ebuilds can share the same tarball if the version of a > > particular vendored dependency has not changed. > > I see what you are saying, but I haven't yet found a way to generate > these separate tarballs that I'm comfortable with. Also, thinking about > this, there will be many more tarballs on our mirrors if we store one > dependency in each tarball than if we generate vendor tarballs that > contain all dependencies for a package. > > I would consider this an enhancement to the eclass if you still feel > that we need it, but let me get the eclass into the tree first then we > can work on that. > That sounds like a bad idea. If there are any potential enhancements that can happen, I'd rather see them happen before there's a bunch of ebuilds using the eclass in the wild, and potentially limiting possible changes. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 105
1 file changed, 105 insertions(+)
create mode 100644 eclass/go-module.eclass
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
new file mode 100644
index 000..810e66e1c5b
--- /dev/null
+++ b/eclass/go-module.eclass
@@ -0,0 +1,105 @@
+# Copyright 2019 gentoo authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-module.eclass
+# @MAINTAINER:
+# William Hubbs
+# @SUPPORTED_EAPIS: 7
+# @BLURB: basic eclass for building software written in the go
+# programming language that uses go modules.
+# @DESCRIPTION:
+# This eclass provides some basic things needed by all software
+# written in the go programming language that uses go modules.
+#
+# You will know the software you are packaging uses modules because
+# it will have files named go.sum and go.mod in its top-level source
+# directory. If it does not have these files, use the golang-* eclasses.
+#
+# If the software you are packaging uses modules, the next question is
+# whether it has a directory named "vendor" at the top-level of the source
tree.
+#
+# If it doesn't, you need to create a tarball of what would be in the
+# vendor directory and mirror it locally.
+# If foo-1.0 is the name of your project and you have the tarball for it
+# in your current directory, this is done with the following commands:
+#
+# @CODE:
+#
+# tar -xf foo-1.0.tar.gz
+# cd foo-1.0
+# go mod vendor
+# tar -acf foo-1.0-vendor.tar.gz vendor
+#
+# @CODE:
+#
+# Regardless of whether you create a vendor tarball, Since Go programs
+# are statically linked, it is important that the ebuild's LICENSE=
+# setting includes the licenses of all statically linked
+# dependencies. So please make sure it is accurate.
+
+case ${EAPI:-0} in
+ 7) ;;
+ *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
+esac
+
+if [[ -z ${_GO_MODULE} ]]; then
+
+_GO_MODULE=1
+
+BDEPEND=">=dev-lang/go-1.12"
+
+# Force go to build in module mode.
+# In this mode the GOPATH environment variable is ignored.
+# this will become the default in the future.
+export GO111MODULE=on
+
+# The following go flags should be used for all builds.
+# -mod=vendor stopps downloading of dependencies from the internet.
+# -v prints the names of packages as they are compiled
+# -x prints commands as they are executed
+export GOFLAGS="-mod=vendor -v -x"
+
+# Do not complain about CFLAGS etc since go projects do not use them.
+QA_FLAGS_IGNORED='.*'
+
+# Go packages should not be stripped with strip(1).
+RESTRICT="strip"
+
+EXPORT_FUNCTIONS src_prepare pkg_postinst
+
+# @FUNCTION: go-module_src_prepare
+# @DESCRIPTION:
+# Run a default src_prepare then move our provided vendor directory to
+# the appropriate spot if upstream doesn't provide a vendor directory.
+# If upstream vendors and we provide a vendor tarball, this is a fatal
+# error.
+go-module_src_prepare() {
+ default
+ if [[ -d "${S}"/vendor ]] && [[ -d ../vendor ]] ; then
+ eerror "The upstream source for ${P} includes a vendor
directory"
+ eerror "and a local vendor tarball is provided."
+ die "vendored dependencies are provided upstream"
+ fi
+ # Use the upstream provided vendor directory if it exists.
+ [[ -d "${S}"/vendor ]] && return
+ # If we are not providing a mirror of a vendor directory we created
+ # manually, return since there may be nothing to vendor.
+ [[ ! -d ../vendor ]] && return
+ # At this point, we know we are providing a vendor mirror.
+ mv ../vendor "${S}" || die "Unable to move ../vendor directory"
+}
+
+# @FUNCTION: go-module_pkg_postinst
+# @DESCRIPTION:
+# Display a warning about security updates for Go programs.
+go-module_pkg_postinst() {
+ 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."
+}
+
+fi
--
2.21.0
[gentoo-dev] [PATCH 0/1] introduce new eclass to handle go modules (round 4)
All,
This iteration adds the src_prepare function along with some sanity
checks for the location of the upstream vendor directory. We should use
"${S}"/vendor instead of just vendor.
Also, a comment was added about the LICENSE setting in ebuilds and we
now force go to operate in module mode by adding GO111MODULE=on to the
environment.
William Hubbs (1):
go-module.eclass: introduce new eclass to handle go modules
eclass/go-module.eclass | 105
1 file changed, 105 insertions(+)
create mode 100644 eclass/go-module.eclass
--
2.21.0
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: > On 9/16/19 11:35 AM, William Hubbs wrote: > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > >> For packages that I maintain, I'd prefer to continue using EGO_VENDOR to > >> even with packages using go.mod. I hope that this go-module.class will > >> not preclude this sort of usage. For example, the latest go-tools ebuild > >> uses EGO_VENDOR together with GOFLAGS="-mod=vendor": > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f > > > > Can you elaborate on why you want to keep EGO_VENDOR? > > > > The "go mod vendor" command above downloads all the correct versions > > of the dependencies and puts them in the vendor directory, so I'm not > > sure why you would need the EGO_VENDOR variable. > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs > containing vendored dependencies. It's more space-efficient in the sense > that each vendored dependency is stored in a separate tarball, so > multiple ebuilds can share the same tarball if the version of a > particular vendored dependency has not changed. I see what you are saying, but I haven't yet found a way to generate these separate tarballs that I'm comfortable with. Also, thinking about this, there will be many more tarballs on our mirrors if we store one dependency in each tarball than if we generate vendor tarballs that contain all dependencies for a package. I would consider this an enhancement to the eclass if you still feel that we need it, but let me get the eclass into the tree first then we can work on that. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On 9/16/19 11:26 AM, William Hubbs wrote:
> On Mon, Sep 16, 2019 at 10:48:14AM -0700, Zac Medico wrote:
>> On 9/16/19 7:17 AM, William Hubbs wrote:
>>> +BDEPEND=">=dev-lang/go-1.12"
>>> +
>>> +# The following go flags should be used for all go builds.
>>> +# -mod=vendor stopps downloading of dependencies from the internet.
>>> +# -v prints the names of packages as they are compiled
>>> +# -x prints commands as they are executed
>>> +export GOFLAGS="-mod=vendor -v -x"
>>
>> My experience with g-1.12.x was that you have to export GO111MODULE=on
>> or else GOFLAGS="-mod=vendor" triggers an error like this:
>>
>> build flag -mod=vendor only valid when using modules
>
> I thought that was only if ${S} was in GOPATH, but I'll take a look real
> quick. If it is, would it be best to bump the BDEPEND or turn on the
> environment setting?
I've tested again, and in fact it appears that GOPATH="${S}" triggers
this error, so I guess it would be sufficient to ensure that GOPATH is
unset. Maybe it's cleaner to explicitly export GO111MODULE=on though.
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-mail/mailsync
# Michał Górny (2019-09-16) # Unmaintained. Fails to build. Last release in 2004. EAPI 0. # Removal in 30 days. Bug #592360. net-mail/mailsync -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, 2019-09-16 at 13:46 -0500, William Hubbs wrote:
> On Mon, Sep 16, 2019 at 08:05:50PM +0200, Michał Górny wrote:
> > On Mon, 2019-09-16 at 09:17 -0500, William Hubbs wrote:
> > > Signed-off-by: William Hubbs
> > > ---
> > > eclass/go-module.eclass | 117
> > > 1 file changed, 117 insertions(+)
> > > create mode 100644 eclass/go-module.eclass
> > >
> > > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> > > new file mode 100644
> > > index 000..7e16ec4e95c
> > > --- /dev/null
> > > +++ b/eclass/go-module.eclass
> > > @@ -0,0 +1,117 @@
> > > +# Copyright 2019 gentoo authors
> > > +# Distributed under the terms of the GNU General Public License v2
> > > +
> > > +# @ECLASS: go-module.eclass
> > > +# @MAINTAINER:
> > > +# William Hubbs
> > > +# @SUPPORTED_EAPIS: 7
> > > +# @BLURB: basic eclass for building software written in the go
> > > +# programming language that uses go modules.
> > > +# @DESCRIPTION:
> > > +# This eclass provides some basic things needed by all software
> > > +# written in the go programming language that uses go modules.
> > > +#
> > > +# You will know the software you are packaging uses modules because
> > > +# it will have files named go.sum and go.mod in its top-level source
> > > +# directory. If it does not have these files, use the golang-* eclasses.
> >
> > Please add a big fat warning around here somewhere that people need to
> > look through LICENSE files in all vendored modules, and list them
> > in LICENSE. They also need to watch out for license conflicts.
> >
> > > +#
> > > +# If the software you are packaging uses modules, the next question is
> > > +# whether it has a directory named "vendor" at the top-level of the
> > > source tree.
> > > +#
> > > +# If it doesn't, you need to create a tarball of what would be in the
> > > +# vendor directory and mirror it locally.
> > > +# If foo-1.0 is the name of your project and you have the tarball for it
> > > +# in your current directory, this is done with the following commands:
> > > +#
> > > +# @CODE:
> > > +#
> > > +# tar -xf foo-1.0.tar.gz
> > > +# cd foo-1.0
> > > +# go mod vendor
> > > +# cd ..
> > > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
> > > +#
> > > +# @CODE:
> > > +
> > > +# If we uncomment src_prepare below, the last two lines in the above
> > > +# code block are reduced to one:
> > > +#
> > > +# @CODE:
> > > +#
> > > +# tar -acf foo-1.0-vendor.tar.gz vendor
> > > +#
> > > +# @CODE:
> > > +
> > > +case ${EAPI:-0} in
> > > + 7) ;;
> > > + *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> > > +esac
> > > +
> > > +if [[ -z ${_GO_MODULE} ]]; then
> > > +
> > > +_GO_MODULE=1
> > > +
> > > +BDEPEND=">=dev-lang/go-1.12"
> > > +
> > > +# The following go flags should be used for all go builds.
> > > +# -mod=vendor stopps downloading of dependencies from the internet.
> > > +# -v prints the names of packages as they are compiled
> > > +# -x prints commands as they are executed
> > > +export GOFLAGS="-mod=vendor -v -x"
> > > +
> > > +# Do not complain about CFLAGS etc since go projects do not use them.
> > > +QA_FLAGS_IGNORED='.*'
> > > +
> > > +# Go packages should not be stripped with strip(1).
> > > +RESTRICT="strip"
> > > +
> > > +# EXPORT_FUNCTIONS src_prepare pkg_postinst
> > > + EXPORT_FUNCTIONS pkg_postinst
> > > +
> > > +# @FUNCTION: go-module_src_prepare
> > > +# @DESCRIPTION:
> > > +# Run a default src_prepare then move our provided vendor directory to
> > > +# the appropriate spot if upstream doesn't provide a vendor directory.
> > > +#
> > > +# This is commented out because I want to see where the discussion on
> > > +# the ml leads.
> > > +# Commenting it out and following the above instructions means that you
> > > +# are forced to manually re-tar the vendored dependencies for every
> > > +# version bump.
> > > +# Using the previous method, it would be possible to decide if you need
> > > +# to do this by comparing the contents of go.mod in the previous and new
> > > +# version.
> > > +# Also, note that we can generate a qa warning if a maintainer forgets
> > > +# to drop the vendor tarball and upstream starts vendoring.
> > > +# go-module_src_prepare() {
> > > +#default
> > > +## If upstream vendors the dependencies and we provide a vendor
> > > +## tarball, generate a qa warning.
> > > +#if [[ -d vendor ]] && [[ -d ../vendor ]] ; then
> > > +#eqawarn "This package's upstream source includes a
> > > vendor
> > > +#eqawarn "directory and the maintainer provides a vendor
> > > tarball."
> > > +#eqawarn "Please report this on https://bugs.gentoo.org";
> >
> > Why aren't you making it fatal?
>
> I didn't make it fatal because it doesn't break the build. The build
> will ignore the ../vendor directory from the tarball since it is not
> under ${S}. Do you want it to be fatal?
>
Yes, it's ebuild author's mistake and there is no point
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On 9/16/19 11:35 AM, William Hubbs wrote: > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: >> For packages that I maintain, I'd prefer to continue using EGO_VENDOR to >> even with packages using go.mod. I hope that this go-module.class will >> not preclude this sort of usage. For example, the latest go-tools ebuild >> uses EGO_VENDOR together with GOFLAGS="-mod=vendor": >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f > > Can you elaborate on why you want to keep EGO_VENDOR? > > The "go mod vendor" command above downloads all the correct versions > of the dependencies and puts them in the vendor directory, so I'm not > sure why you would need the EGO_VENDOR variable. EGO_VENDOR eliminates to need to generate and host monolithic tarballs containing vendored dependencies. It's more space-efficient in the sense that each vendored dependency is stored in a separate tarball, so multiple ebuilds can share the same tarball if the version of a particular vendored dependency has not changed. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, Sep 16, 2019 at 08:05:50PM +0200, Michał Górny wrote:
> On Mon, 2019-09-16 at 09:17 -0500, William Hubbs wrote:
> > Signed-off-by: William Hubbs
> > ---
> > eclass/go-module.eclass | 117
> > 1 file changed, 117 insertions(+)
> > create mode 100644 eclass/go-module.eclass
> >
> > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> > new file mode 100644
> > index 000..7e16ec4e95c
> > --- /dev/null
> > +++ b/eclass/go-module.eclass
> > @@ -0,0 +1,117 @@
> > +# Copyright 2019 gentoo authors
> > +# Distributed under the terms of the GNU General Public License v2
> > +
> > +# @ECLASS: go-module.eclass
> > +# @MAINTAINER:
> > +# William Hubbs
> > +# @SUPPORTED_EAPIS: 7
> > +# @BLURB: basic eclass for building software written in the go
> > +# programming language that uses go modules.
> > +# @DESCRIPTION:
> > +# This eclass provides some basic things needed by all software
> > +# written in the go programming language that uses go modules.
> > +#
> > +# You will know the software you are packaging uses modules because
> > +# it will have files named go.sum and go.mod in its top-level source
> > +# directory. If it does not have these files, use the golang-* eclasses.
>
> Please add a big fat warning around here somewhere that people need to
> look through LICENSE files in all vendored modules, and list them
> in LICENSE. They also need to watch out for license conflicts.
>
> > +#
> > +# If the software you are packaging uses modules, the next question is
> > +# whether it has a directory named "vendor" at the top-level of the source
> > tree.
> > +#
> > +# If it doesn't, you need to create a tarball of what would be in the
> > +# vendor directory and mirror it locally.
> > +# If foo-1.0 is the name of your project and you have the tarball for it
> > +# in your current directory, this is done with the following commands:
> > +#
> > +# @CODE:
> > +#
> > +# tar -xf foo-1.0.tar.gz
> > +# cd foo-1.0
> > +# go mod vendor
> > +# cd ..
> > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
> > +#
> > +# @CODE:
> > +
> > +# If we uncomment src_prepare below, the last two lines in the above
> > +# code block are reduced to one:
> > +#
> > +# @CODE:
> > +#
> > +# tar -acf foo-1.0-vendor.tar.gz vendor
> > +#
> > +# @CODE:
> > +
> > +case ${EAPI:-0} in
> > + 7) ;;
> > + *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> > +esac
> > +
> > +if [[ -z ${_GO_MODULE} ]]; then
> > +
> > +_GO_MODULE=1
> > +
> > +BDEPEND=">=dev-lang/go-1.12"
> > +
> > +# The following go flags should be used for all go builds.
> > +# -mod=vendor stopps downloading of dependencies from the internet.
> > +# -v prints the names of packages as they are compiled
> > +# -x prints commands as they are executed
> > +export GOFLAGS="-mod=vendor -v -x"
> > +
> > +# Do not complain about CFLAGS etc since go projects do not use them.
> > +QA_FLAGS_IGNORED='.*'
> > +
> > +# Go packages should not be stripped with strip(1).
> > +RESTRICT="strip"
> > +
> > +# EXPORT_FUNCTIONS src_prepare pkg_postinst
> > + EXPORT_FUNCTIONS pkg_postinst
> > +
> > +# @FUNCTION: go-module_src_prepare
> > +# @DESCRIPTION:
> > +# Run a default src_prepare then move our provided vendor directory to
> > +# the appropriate spot if upstream doesn't provide a vendor directory.
> > +#
> > +# This is commented out because I want to see where the discussion on
> > +# the ml leads.
> > +# Commenting it out and following the above instructions means that you
> > +# are forced to manually re-tar the vendored dependencies for every
> > +# version bump.
> > +# Using the previous method, it would be possible to decide if you need
> > +# to do this by comparing the contents of go.mod in the previous and new
> > +# version.
> > +# Also, note that we can generate a qa warning if a maintainer forgets
> > +# to drop the vendor tarball and upstream starts vendoring.
> > +# go-module_src_prepare() {
> > +# default
> > +# # If upstream vendors the dependencies and we provide a vendor
> > +# # tarball, generate a qa warning.
> > +# if [[ -d vendor ]] && [[ -d ../vendor ]] ; then
> > +# eqawarn "This package's upstream source includes a vendor
> > +# eqawarn "directory and the maintainer provides a vendor
> > tarball."
> > +# eqawarn "Please report this on https://bugs.gentoo.org";
>
> Why aren't you making it fatal?
I didn't make it fatal because it doesn't break the build. The build
will ignore the ../vendor directory from the tarball since it is not
under ${S}. Do you want it to be fatal?
Thanks,
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > On 9/16/19 7:17 AM, William Hubbs wrote: > > +# You will know the software you are packaging uses modules because > > +# it will have files named go.sum and go.mod in its top-level source > > +# directory. If it does not have these files, use the golang-* eclasses. > > +# > > +# If the software you are packaging uses modules, the next question is > > +# whether it has a directory named "vendor" at the top-level of the source > > tree. > > +# > > +# If it doesn't, you need to create a tarball of what would be in the > > +# vendor directory and mirror it locally. > > +# If foo-1.0 is the name of your project and you have the tarball for it > > +# in your current directory, this is done with the following commands: > > +# > > +# @CODE: > > +# > > +# tar -xf foo-1.0.tar.gz > > +# cd foo-1.0 > > +# go mod vendor > > +# cd .. > > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor > > For packages that I maintain, I'd prefer to continue using EGO_VENDOR to > even with packages using go.mod. I hope that this go-module.class will > not preclude this sort of usage. For example, the latest go-tools ebuild > uses EGO_VENDOR together with GOFLAGS="-mod=vendor": > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f Can you elaborate on why you want to keep EGO_VENDOR? The "go mod vendor" command above downloads all the correct versions of the dependencies and puts them in the vendor directory, so I'm not sure why you would need the EGO_VENDOR variable. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, Sep 16, 2019 at 10:48:14AM -0700, Zac Medico wrote:
> On 9/16/19 7:17 AM, William Hubbs wrote:
> > +BDEPEND=">=dev-lang/go-1.12"
> > +
> > +# The following go flags should be used for all go builds.
> > +# -mod=vendor stopps downloading of dependencies from the internet.
> > +# -v prints the names of packages as they are compiled
> > +# -x prints commands as they are executed
> > +export GOFLAGS="-mod=vendor -v -x"
>
> My experience with g-1.12.x was that you have to export GO111MODULE=on
> or else GOFLAGS="-mod=vendor" triggers an error like this:
>
> build flag -mod=vendor only valid when using modules
I thought that was only if ${S} was in GOPATH, but I'll take a look real
quick. If it is, would it be best to bump the BDEPEND or turn on the
environment setting?
Thanks,
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] Last rites: app-emulation/vmips-cross-bin
On Mon, 2019-09-16 at 19:15 +0200, Michał Górny wrote: > # Michał Górny (2019-09-16) > # Unmaintained. Last touched in 2005. Keyworded ppc only. Upstream > # is still alive, so this thing needs a major version bump. > # Removal in 30 days. Bug #694562. > app-emulation/vmips-cross-bin + app-emulation/vmips -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On Mon, 2019-09-16 at 09:17 -0500, William Hubbs wrote:
> Signed-off-by: William Hubbs
> ---
> eclass/go-module.eclass | 117
> 1 file changed, 117 insertions(+)
> create mode 100644 eclass/go-module.eclass
>
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> new file mode 100644
> index 000..7e16ec4e95c
> --- /dev/null
> +++ b/eclass/go-module.eclass
> @@ -0,0 +1,117 @@
> +# Copyright 2019 gentoo authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: go-module.eclass
> +# @MAINTAINER:
> +# William Hubbs
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: basic eclass for building software written in the go
> +# programming language that uses go modules.
> +# @DESCRIPTION:
> +# This eclass provides some basic things needed by all software
> +# written in the go programming language that uses go modules.
> +#
> +# You will know the software you are packaging uses modules because
> +# it will have files named go.sum and go.mod in its top-level source
> +# directory. If it does not have these files, use the golang-* eclasses.
Please add a big fat warning around here somewhere that people need to
look through LICENSE files in all vendored modules, and list them
in LICENSE. They also need to watch out for license conflicts.
> +#
> +# If the software you are packaging uses modules, the next question is
> +# whether it has a directory named "vendor" at the top-level of the source
> tree.
> +#
> +# If it doesn't, you need to create a tarball of what would be in the
> +# vendor directory and mirror it locally.
> +# If foo-1.0 is the name of your project and you have the tarball for it
> +# in your current directory, this is done with the following commands:
> +#
> +# @CODE:
> +#
> +# tar -xf foo-1.0.tar.gz
> +# cd foo-1.0
> +# go mod vendor
> +# cd ..
> +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
> +#
> +# @CODE:
> +
> +# If we uncomment src_prepare below, the last two lines in the above
> +# code block are reduced to one:
> +#
> +# @CODE:
> +#
> +# tar -acf foo-1.0-vendor.tar.gz vendor
> +#
> +# @CODE:
> +
> +case ${EAPI:-0} in
> + 7) ;;
> + *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> +esac
> +
> +if [[ -z ${_GO_MODULE} ]]; then
> +
> +_GO_MODULE=1
> +
> +BDEPEND=">=dev-lang/go-1.12"
> +
> +# The following go flags should be used for all go builds.
> +# -mod=vendor stopps downloading of dependencies from the internet.
> +# -v prints the names of packages as they are compiled
> +# -x prints commands as they are executed
> +export GOFLAGS="-mod=vendor -v -x"
> +
> +# Do not complain about CFLAGS etc since go projects do not use them.
> +QA_FLAGS_IGNORED='.*'
> +
> +# Go packages should not be stripped with strip(1).
> +RESTRICT="strip"
> +
> +# EXPORT_FUNCTIONS src_prepare pkg_postinst
> + EXPORT_FUNCTIONS pkg_postinst
> +
> +# @FUNCTION: go-module_src_prepare
> +# @DESCRIPTION:
> +# Run a default src_prepare then move our provided vendor directory to
> +# the appropriate spot if upstream doesn't provide a vendor directory.
> +#
> +# This is commented out because I want to see where the discussion on
> +# the ml leads.
> +# Commenting it out and following the above instructions means that you
> +# are forced to manually re-tar the vendored dependencies for every
> +# version bump.
> +# Using the previous method, it would be possible to decide if you need
> +# to do this by comparing the contents of go.mod in the previous and new
> +# version.
> +# Also, note that we can generate a qa warning if a maintainer forgets
> +# to drop the vendor tarball and upstream starts vendoring.
> +# go-module_src_prepare() {
> +#default
> +## If upstream vendors the dependencies and we provide a vendor
> +## tarball, generate a qa warning.
> +#if [[ -d vendor ]] && [[ -d ../vendor ]] ; then
> +#eqawarn "This package's upstream source includes a vendor
> +#eqawarn "directory and the maintainer provides a vendor
> tarball."
> +#eqawarn "Please report this on https://bugs.gentoo.org";
Why aren't you making it fatal?
> +#fi
> +## Use the upstream provided vendor directory if it exists.
> +#[[ -d vendor ]] && return
> +## If we are not providing a mirror of a vendor directory we created
> +## manually, return since there may be nothing to vendor.
> +#[[ ! -d ../vendor ]] && return
> +## At this point, we know we are providing a vendor mirror.
> +#mv ../vendor . || die "Unable to move ../vendor directory"
> +# }
> +
> +# @FUNCTION: go-module_pkg_postinst
> +# @DESCRIPTION:
> +# Display a warning about security updates for Go programs.
> +go-module_pkg_postinst() {
> + 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 distributio
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On 9/16/19 7:17 AM, William Hubbs wrote: > +# You will know the software you are packaging uses modules because > +# it will have files named go.sum and go.mod in its top-level source > +# directory. If it does not have these files, use the golang-* eclasses. > +# > +# If the software you are packaging uses modules, the next question is > +# whether it has a directory named "vendor" at the top-level of the source > tree. > +# > +# If it doesn't, you need to create a tarball of what would be in the > +# vendor directory and mirror it locally. > +# If foo-1.0 is the name of your project and you have the tarball for it > +# in your current directory, this is done with the following commands: > +# > +# @CODE: > +# > +# tar -xf foo-1.0.tar.gz > +# cd foo-1.0 > +# go mod vendor > +# cd .. > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor For packages that I maintain, I'd prefer to continue using EGO_VENDOR to even with packages using go.mod. I hope that this go-module.class will not preclude this sort of usage. For example, the latest go-tools ebuild uses EGO_VENDOR together with GOFLAGS="-mod=vendor": https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-text/gnopaster
# Michał Górny (2019-09-16) # Unmaintained. Does not work anymore. Last release in 2007. # Our recommended alternative is app-text/wgetpaste. # Removal in 30 days. Bug #678554. app-text/gnopaster -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
On 9/16/19 7:17 AM, William Hubbs wrote: > +BDEPEND=">=dev-lang/go-1.12" > + > +# The following go flags should be used for all go builds. > +# -mod=vendor stopps downloading of dependencies from the internet. > +# -v prints the names of packages as they are compiled > +# -x prints commands as they are executed > +export GOFLAGS="-mod=vendor -v -x" My experience with g-1.12.x was that you have to export GO111MODULE=on or else GOFLAGS="-mod=vendor" triggers an error like this: build flag -mod=vendor only valid when using modules -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
All,
here is my thought about the src_prepare function in the eclass.
It is commented right now, but I want to uncomment it and not force ${P}
into the path in the vendor tarball if no one objects; I think it is
easier to do that because it would allow me to detect when upstream
vendors and the maintainer tries to provide a vendor tarball at the same
time as shown in the first if block in the function.
Let me know if you agree or disagree with this.
Thanks,
William
signature.asc
Description: Digital signature
[gentoo-dev] Last rites: app-emulation/vmips-cross-bin
# Michał Górny (2019-09-16) # Unmaintained. Last touched in 2005. Keyworded ppc only. Upstream # is still alive, so this thing needs a major version bump. # Removal in 30 days. Bug #694562. app-emulation/vmips-cross-bin -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 0/1] introduce new eclass to handle go modules (round 3)
All, this is the third iteration of this eclass. I have added a pkg_postinst function to warn about go being statically linked. Also, the src_prepare function, which is still commented out, has been adjusted to show how I could generate a qa warning if the maintainer packs a vendor tarball and upstream vendors. This could not happen if we use the method forcing the version into the path stored in the vendor tarball. Thanks, William William Hubbs (1): go-module.eclass: introduce new eclass to handle go modules eclass/go-module.eclass | 117 1 file changed, 117 insertions(+) create mode 100644 eclass/go-module.eclass -- 2.21.0
[gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Signed-off-by: William Hubbs
---
eclass/go-module.eclass | 117
1 file changed, 117 insertions(+)
create mode 100644 eclass/go-module.eclass
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
new file mode 100644
index 000..7e16ec4e95c
--- /dev/null
+++ b/eclass/go-module.eclass
@@ -0,0 +1,117 @@
+# Copyright 2019 gentoo authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-module.eclass
+# @MAINTAINER:
+# William Hubbs
+# @SUPPORTED_EAPIS: 7
+# @BLURB: basic eclass for building software written in the go
+# programming language that uses go modules.
+# @DESCRIPTION:
+# This eclass provides some basic things needed by all software
+# written in the go programming language that uses go modules.
+#
+# You will know the software you are packaging uses modules because
+# it will have files named go.sum and go.mod in its top-level source
+# directory. If it does not have these files, use the golang-* eclasses.
+#
+# If the software you are packaging uses modules, the next question is
+# whether it has a directory named "vendor" at the top-level of the source
tree.
+#
+# If it doesn't, you need to create a tarball of what would be in the
+# vendor directory and mirror it locally.
+# If foo-1.0 is the name of your project and you have the tarball for it
+# in your current directory, this is done with the following commands:
+#
+# @CODE:
+#
+# tar -xf foo-1.0.tar.gz
+# cd foo-1.0
+# go mod vendor
+# cd ..
+# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
+#
+# @CODE:
+
+# If we uncomment src_prepare below, the last two lines in the above
+# code block are reduced to one:
+#
+# @CODE:
+#
+# tar -acf foo-1.0-vendor.tar.gz vendor
+#
+# @CODE:
+
+case ${EAPI:-0} in
+ 7) ;;
+ *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
+esac
+
+if [[ -z ${_GO_MODULE} ]]; then
+
+_GO_MODULE=1
+
+BDEPEND=">=dev-lang/go-1.12"
+
+# The following go flags should be used for all go builds.
+# -mod=vendor stopps downloading of dependencies from the internet.
+# -v prints the names of packages as they are compiled
+# -x prints commands as they are executed
+export GOFLAGS="-mod=vendor -v -x"
+
+# Do not complain about CFLAGS etc since go projects do not use them.
+QA_FLAGS_IGNORED='.*'
+
+# Go packages should not be stripped with strip(1).
+RESTRICT="strip"
+
+# EXPORT_FUNCTIONS src_prepare pkg_postinst
+ EXPORT_FUNCTIONS pkg_postinst
+
+# @FUNCTION: go-module_src_prepare
+# @DESCRIPTION:
+# Run a default src_prepare then move our provided vendor directory to
+# the appropriate spot if upstream doesn't provide a vendor directory.
+#
+# This is commented out because I want to see where the discussion on
+# the ml leads.
+# Commenting it out and following the above instructions means that you
+# are forced to manually re-tar the vendored dependencies for every
+# version bump.
+# Using the previous method, it would be possible to decide if you need
+# to do this by comparing the contents of go.mod in the previous and new
+# version.
+# Also, note that we can generate a qa warning if a maintainer forgets
+# to drop the vendor tarball and upstream starts vendoring.
+# go-module_src_prepare() {
+# default
+# # If upstream vendors the dependencies and we provide a vendor
+# # tarball, generate a qa warning.
+# if [[ -d vendor ]] && [[ -d ../vendor ]] ; then
+# eqawarn "This package's upstream source includes a vendor
+# eqawarn "directory and the maintainer provides a vendor
tarball."
+# eqawarn "Please report this on https://bugs.gentoo.org";
+# fi
+# # Use the upstream provided vendor directory if it exists.
+# [[ -d vendor ]] && return
+# # If we are not providing a mirror of a vendor directory we created
+# # manually, return since there may be nothing to vendor.
+# [[ ! -d ../vendor ]] && return
+# # At this point, we know we are providing a vendor mirror.
+# mv ../vendor . || die "Unable to move ../vendor directory"
+# }
+
+# @FUNCTION: go-module_pkg_postinst
+# @DESCRIPTION:
+# Display a warning about security updates for Go programs.
+go-module_pkg_postinst() {
+ 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."
+}
+
+fi
--
2.21.0
Re: [gentoo-dev] Packages up for grabs: app-misc/ddcutil, media-libs/opencollada, media-sound/tuxguitar, sys-apps/qdirstat
On Fri, 13 Sep 2019 17:37:54 +0200 Michał Górny wrote: > Hi, > > The following packages are up for grabs due to prolonged inactivity > of dracwyrm: > > app-misc/ddcutil > media-libs/opencollada > media-sound/tuxguitar --- On Mon, 16 Sep 2019 00:05:02 + "Robin H. Johnson" wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2019-09-15 23:59 UTC. > > Removals: > ... > media-sound/tuxguitar 20190914-15:44 mgorny > 2f0cc63bfec Guess this one no longer matters ;) pgp7Q6jllKReJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On Fri, 13 Sep 2019 12:50:48 -0400 Michael Orlitzky wrote: > The rule "don't copy and paste code" applies to your > linker just as much as it applies to the first program you wrote in > CS101, and for the same reasons. My experience has taught me to ignore the rule as written, and consider it more a guideline aimed at novices. Importantly, don't copy and paste code you don't understand. However, if you re-use a given implementation, you can sometimes become dependent on specifics in that implementation. And upstream have an annoying tendency to change implementation details in incompatible ways. This breaks your code, sometimes obviously, sometimes subtly. So the benefit you'd hoped to attain by modularity only remains true if the modules in question are immutable for the problem you're using them for. Also, these external modules bring with them complexity you may not want or need (and their own dependencies with the same issues), and that's not free either. Subsequently, when considering a new dependency, I have to ask questions about whether I can implement a subset of the dependency faithfully that suits my needs, and ask if I have the skills to be an expert in this implementation. A level of distrust in the people who author and maintain your dependencies is something I consider healthy. Does this map at all to static linking? You bet. And that's part of why Go and Rust use it. The fragility of other-peoples code in the long view of time is high, because with dynamic linking, you don't have any guarantees about integrity. You have to cross your fingers and hope upstream so-named their libraries right, hope upstream changed their API markers right, hope upstream never accidentally made a breaking change without changing an API marker, hope your code doesn't need a mountain of work to recompile after the API marker changes, and hope upstream/gentoo maintainers for your package can still be bothered to ship fixes for the API consumer. That last paragraph sums up a large volume of the daily hell of being a maintainer and a gentoo user. Static linking is more a result of a sickness, not the sickness itself. pgpkxth8c0S4P.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
On Fri, 13 Sep 2019 19:44:55 -0400 Michael Orlitzky wrote: > They silently get something less than > they're expecting. We would be better off telling people to run "go > whatever" themselves, or by putting this stuff in an overlay where > expectations are clearly defined. That suggestion actually decreases security. Especially if the package in question is intended to be run as root. At least with using portage, you can side-step the nonsense of "and here's how you install this in /usr/bin curl url | sudo bash - " And additionally, we get a sandbox and all the features of file ownership tracking. And if there is a complaint about the package misbehaving, a bug can be filed in a common location, and a gentoo dev can actually fix the problem, even if upstream have moved on to greener pastures. ( This is the sad state of a lot of older perl stuff these days, they simply don't work vanilla any more, and gentoo are putting the patches in to keep it working ) So in summary, Portage does a lot more for the end user than "ensure dynamic linking works". pgpvsUZ0SBpwv.pgp Description: OpenPGP digital signature
