Re: [gentoo-dev] [PATCH v2 1/4] kernel-install.eclass: Install logic for dist-kernels
On Sun, 2020-01-05 at 07:30 +, Robin H. Johnson wrote: > On Sun, Jan 05, 2020 at 07:27:38AM +0100, Michał Górny wrote: > > Introduce a new eclass that contains common logic needed to test > > and install distribution kernels. This is the eclass common both > > to kernels built from source and installed from binary packages. > I'm 100% in favour of the concept here, but I have some implementation > concerns. > > For the (public) record, Infra has been wrapping genkernel to build > binary kernel + initramfs for internal usage for 5 years now. > > Conceptually, can you clarify why you are depending on dracut here, > rather than using genkernel's initramfs mode? For a start, because dracut is not bundling all its dependencies. It's also tested outside Gentoo, so it has much wider testing than genkernel, and doesn't suffer from intermediate deaths, -next forks and total confusion over which version should be used. > I'm not sure you're going to get correct build output in cases like > x86_64 -> x86 cross-compiles. Cross-compile support is untested, and provided merely where it was clear how to do it. I'm happy to fix it later, when someone figures it out. > Why not call genkernel from the ebuild instead of re-inventing the > wheel to compile the kernel yourself. Have you read the logic and found a way to achieve all that from genkernel, without 1) losing advantages of my approach, 2) adding a huge dependency to replace 5 lines of code? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 1/4] kernel-install.eclass: Install logic for dist-kernels
On Sun, Jan 05, 2020 at 07:27:38AM +0100, Michał Górny wrote: > Introduce a new eclass that contains common logic needed to test > and install distribution kernels. This is the eclass common both > to kernels built from source and installed from binary packages. I'm 100% in favour of the concept here, but I have some implementation concerns. For the (public) record, Infra has been wrapping genkernel to build binary kernel + initramfs for internal usage for 5 years now. Conceptually, can you clarify why you are depending on dracut here, rather than using genkernel's initramfs mode? I'm not sure you're going to get correct build output in cases like x86_64 -> x86 cross-compiles. Why not call genkernel from the ebuild instead of re-inventing the wheel to compile the kernel yourself. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-dicts/sword-*
# Ulrich Müller (2020-01-06) # No license, therefore we have no permission to redistribute # these packages on Gentoo mirrors. Distfiles are unversioned # zipballs, which are updated in place when a new version is # released. Since this will break digests, mirror restriction # is not feasible. # Masked for removal in 30 days. Bug #703604. app-dicts/sword-ab app-dicts/sword-abs_essay_goodsam_swb app-dicts/sword-br_en app-dicts/sword-bulcarigradnt app-dicts/sword-bwe app-dicts/sword-chincvs app-dicts/sword-chincvt app-dicts/sword-chiun app-dicts/sword-chiuns app-dicts/sword-czecep app-dicts/sword-czekms app-dicts/sword-czenkb app-dicts/sword-dbd app-dicts/sword-emtv app-dicts/sword-est app-dicts/sword-family app-dicts/sword-finpr92 app-dicts/sword-frecrl app-dicts/sword-geneva app-dicts/sword-hebmodern app-dicts/sword-hunuj app-dicts/sword-icelandic app-dicts/sword-kekchi app-dicts/sword-korean app-dicts/sword-la_en app-dicts/sword-latvian app-dicts/sword-maori app-dicts/sword-romcor app-dicts/sword-umgreek app-dicts/sword-xhosa signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels
On Mon, 2020-01-06 at 13:07 -0500, Mike Gilbert wrote:
> On Mon, Jan 6, 2020 at 12:54 PM Michał Górny wrote:
> > On Mon, 2020-01-06 at 12:43 -0500, Mike Gilbert wrote:
> > > On Sun, Jan 5, 2020 at 1:27 AM Michał Górny wrote:
> > > > +# @FUNCTION: kernel-build_src_configure
> > > > +# @DESCRIPTION:
> > > > +# Prepare the toolchain for building the kernel, get the default
> > > > .config
> > > > +# or restore savedconfig, and get build tree configured for modprep.
> > > > +kernel-build_src_configure() {
> > > > + debug-print-function ${FUNCNAME} "${@}"
> > > > +
> > > > + # force ld.bfd if we can find it easily
> > > > + local LD="$(tc-getLD)"
> > > > + if type -P "${LD}.bfd" &>/dev/null; then
> > > > + LD+=.bfd
> > > > + fi
> > >
> > > Is there some reason not to use the tc-ld-disable-gold function?
> > >
> >
> > Yes. As the name says, it covers gold usage only and not lld.
>
> It might be a good idea to copy this logic to handle multi-word LD values.
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain-funcs.eclass#n498
>
> Or, a nicer alternative would be to refactor tc-ld-disable-gold into 2
> functions: move most of the logic into a new function
> "tc-ld-force-bfd", and update tc-ld-disable-gold to call the former if
> tc-ld-is-gold is true. I can write a patch for that if you agree.
>
Sure, that sounds like a good idea. Please also replace which(1) with
'type' while at it.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels
On Mon, Jan 6, 2020 at 12:54 PM Michał Górny wrote:
>
> On Mon, 2020-01-06 at 12:43 -0500, Mike Gilbert wrote:
> > On Sun, Jan 5, 2020 at 1:27 AM Michał Górny wrote:
> > > +# @FUNCTION: kernel-build_src_configure
> > > +# @DESCRIPTION:
> > > +# Prepare the toolchain for building the kernel, get the default .config
> > > +# or restore savedconfig, and get build tree configured for modprep.
> > > +kernel-build_src_configure() {
> > > + debug-print-function ${FUNCNAME} "${@}"
> > > +
> > > + # force ld.bfd if we can find it easily
> > > + local LD="$(tc-getLD)"
> > > + if type -P "${LD}.bfd" &>/dev/null; then
> > > + LD+=.bfd
> > > + fi
> >
> > Is there some reason not to use the tc-ld-disable-gold function?
> >
>
> Yes. As the name says, it covers gold usage only and not lld.
It might be a good idea to copy this logic to handle multi-word LD values.
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain-funcs.eclass#n498
Or, a nicer alternative would be to refactor tc-ld-disable-gold into 2
functions: move most of the logic into a new function
"tc-ld-force-bfd", and update tc-ld-disable-gold to call the former if
tc-ld-is-gold is true. I can write a patch for that if you agree.
Re: [gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels
On Mon, 2020-01-06 at 12:43 -0500, Mike Gilbert wrote:
> On Sun, Jan 5, 2020 at 1:27 AM Michał Górny wrote:
> > +# @FUNCTION: kernel-build_src_configure
> > +# @DESCRIPTION:
> > +# Prepare the toolchain for building the kernel, get the default .config
> > +# or restore savedconfig, and get build tree configured for modprep.
> > +kernel-build_src_configure() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + # force ld.bfd if we can find it easily
> > + local LD="$(tc-getLD)"
> > + if type -P "${LD}.bfd" &>/dev/null; then
> > + LD+=.bfd
> > + fi
>
> Is there some reason not to use the tc-ld-disable-gold function?
>
Yes. As the name says, it covers gold usage only and not lld.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels
On Sun, Jan 5, 2020 at 1:27 AM Michał Górny wrote:
> +# @FUNCTION: kernel-build_src_configure
> +# @DESCRIPTION:
> +# Prepare the toolchain for building the kernel, get the default .config
> +# or restore savedconfig, and get build tree configured for modprep.
> +kernel-build_src_configure() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + # force ld.bfd if we can find it easily
> + local LD="$(tc-getLD)"
> + if type -P "${LD}.bfd" &>/dev/null; then
> + LD+=.bfd
> + fi
Is there some reason not to use the tc-ld-disable-gold function?
[gentoo-dev] Packages up for grabs: app-office/pybliographer
Dear all, The following packages are up for grabs: app-office/pybliographer after removing the TeX project from the maintainer list. The bug tracker seems to be inactive https://gitlab.gnome.org/GNOME/pybliographer/issues?scope=all&utf8=%E2%9C%93&state=opened and it is likely that we will have to last rite the package with the removal of python 2. Take action, if you are user of app-office/pybliographer. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] go-module.eclass: set a reasonable default for the go build cache
On Sat, Jan 04, 2020 at 08:13:36PM -0600, William Hubbs wrote:
> Signed-off-by: William Hubbs
> ---
> eclass/go-module.eclass | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> index 9c11959fdf8..89b32ed1201 100644
> --- a/eclass/go-module.eclass
> +++ b/eclass/go-module.eclass
> @@ -59,6 +59,10 @@ BDEPEND=">=dev-lang/go-1.12"
> # this will become the default in the future.
> export GO111MODULE=on
>
> +# Set the default for the go build cache
> +# See "go help environment" for information on this setting
> +export GOCACHE="${T}/go-build"
> +
> # 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
> --
> 2.24.1
This is committed.
Thanks,
William
signature.asc
Description: Digital signature
