Many, many, new users at some point make the mistake of running "make ...."
in the source directory of a distribution kernel.
This returns a vague error due to the absence of the kernel source files:
make[2]: *** No rule to make target 'arch/x86/entry/syscalls/syscall_32.tbl', needed by 'arch/x86/include/generated/uapi/asm/unistd_32.h'. Stop.
make[1]: *** [arch/x86/Makefile:248: archheaders] Error 2
make: *** [Makefile:234: __sub-make] Error 2
Here we append to the kernel Makefile a warning that should make it more clear
what is going wrong. "$(shell [ -t 0 ] && echo 1)" is a trick to show this
warning when an user is executing "make" from their shell, but not when they are
compiling out-of-tree kernel modules (which is the reason we need to install
these makefiles to begin with).
We also add a "dist-kernel" file containing the package atom of the ebuild that
installed this kernel. This makes it possible for ebuilds/eclasses or whatever
other tools to check if a kernel is a Gentoo distribution kernel. This
identifier will be overwritten in gentoo-kernel-bin.ebuild.
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
Some users do not like te idea of wine prefixes being able to
read everything through the rootfs Z:\ drive and opt to remove
it, but then this unexpectedly breaks mono and is not entirely
obvious as to why.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It uses a heavily vintage autoconf 2.13 in the dist tarball, while
simultaneously packed with gettextize bombs. It fails to configure under
Modern C compilers. Simply regenerating the build system solves all
this.
Bonus: there's a patch that patches a gettext input, which is no longer
used or needed. It dates back to at least the import of ::gentoo into
git.
Closes: https://bugs.gentoo.org/871537
Closes: https://bugs.gentoo.org/906253
Closes: https://github.com/gentoo/gentoo/pull/37307
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
We leave an empty directory behind after moving the completion files
around. Portage's QA check thinks that means we are actually using a
legacy dynamic loader location??
* QA Notice: Bash completions were installed in legacy location. Please update
* the ebuild to get the install paths using bash-completion-r1.eclass.
But the eclass doesn't support the eager-loader directory at all, and
the QA notice isn't warning about it either -- the warning is simply
because we have that empty directory (that gets cleaned up after the QA
checks run, since keepdir isn't used).
No revbump. It only affects an install-time warning and rmdir cannot
change the resulting package contents.
Closes: https://bugs.gentoo.org/926047
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Sam James
Andrew Ammerlaan
Eray Aslan
Florian Schmaus
Ionen Wolkens
Joonas Niilola
Brahmajit Das
Hans de Graaff
Eli Schwartz
Michał Górny
Erik Mackdanz