[gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system
On 03/01/2020 12:52, Jason A. Donenfeld wrote:
A user reported that when compiling modules for a system with a 64-bit
kernel and a 32-bit userland, there were linker errors. This patch here
is an attempt to fix that by making sure that we always use the kernel
ABI when giving target build parameters.
Signed-off-by: Jason A. Donenfeld
Fixes: https://bugs.gentoo.org/704468
Cc: joakim.tjernl...@infinera.com
Cc: ker...@gentoo.org
---
eclass/linux-mod.eclass | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b6dc2c84d09..60b0d88e9b9 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -671,13 +671,16 @@ linux-mod_src_compile() {
# spaces that must be preserved. If don't do this, then
the stuff
# inside the variables gets used as targets for Make,
which then
# fails.
- eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \
- CROSS_COMPILE=${CHOST}- \
- LDFLAGS=\"$(get_abi_LDFLAGS)\" \
+ local KERNEL_CHOST="$(ABI=${KERNEL_ABI} get_abi_CHOST)"
+ local KERNEL_LDFLAGS="$(ABI=${KERNEL_ABI}
get_abi_LDFLAGS)"
+ local HOST_CC="$(tc-getBUILD_CC)"
+ eval "emake HOSTCC=\"${HOST_CC}\" \
+ CROSS_COMPILE=${KERNEL_CHOST}- \
+ LDFLAGS=\"${KERNEL_LDFLAGS}\" \
${BUILD_FIXES} \
${BUILD_PARAMS} \
${BUILD_TARGETS} " \
- || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)"
CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS}
${BUILD_TARGETS}"
+ || die "Unable to emake HOSTCC="${HOST_CC}"
CROSS_COMPILE=${KERNEL_CHOST}- LDFLAGS="${KERNEL_LDFLAGS}" ${BUILD_FIXES} ${BUILD_PARAMS}
${BUILD_TARGETS}"
cd "${OLDPWD}"
touch "${srcdir}"/.built
fi
It seems doing what it is supposed to do. what is the testing condition?
lu
Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies
On Thu, 2020-01-02 at 16:57 +0100, Michał Górny wrote: > Using 2-style USE dependencies on packages not having the flag > in question is forbidden by PMS. Looks good to me, thanks for proposing a fix for this. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies
On Thu, 2020-01-02 at 22:08 +0100, Michał Górny wrote: > On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote: > > > Hadn't we established that ruby_samelib() is dead code, no longer > > used > > since 2010? > > > > You did. However, it isn't marked as private API and I'm not the > eclass > maintainer to take care of removing public API. I have no clue if > Ruby > project doesn't have some secret overlays using it. I'm not aware of any usage, but I also was not aware that this is no longer used. I'll make a note to check this out and propose a deprecation/removal plan. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Vanilla sources
On 2020.01.04 13:43, Thomas Deutschmann wrote: > On 2020-01-04 14:08, Roy Bamford wrote: > > emerge -1 vanilla-sources > > eselect kernel ... > > genkernel all > > ... > > Please tell user to do > > genkernel --kernel-config=/proc/config.gz all > > by default which will give them a better experience because new kernel > will be build based on kernel configuration from current running > kernel. > Without providing a kernel config, user will probably fall back to > generic configuration which isn't intended for daily usage. > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 > > Thomas, Ten years ago the user did genkernel all and used the default .config provided with genkernel. Today, genkernel --kernel-config=/proc/config.gz all does not improve that config. genkernel --kernel-config=/proc/config.gz all perpetuates the existing .config which is only useful if its not an earlier generic configuration. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpjhN8CA5bom.pgp Description: PGP signature
Re: [gentoo-dev] Vanilla sources
On 1/4/20 2:13 PM, Rolf Eike Beer wrote: > > Bad idea. If you wonder why: eshowkw dev-lang/rust. > Or consider that every rust package in Gentoo bundles hundreds of libraries. We'd be fixing one security issue by introducing 10x more. Not that rewriting it in rust would fix anything; writing it in C is only a solution insofar as it makes the window to exploit the race condition is as small as possible.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-01-05 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-01-05 23:59 UTC. Removals: app-admin/linux-bench20200101-08:42 zlogene 7682e89afbf app-misc/hachoir-subfile 20200104-10:17 zlogene ffaba0fba6a app-misc/rq 20200101-08:38 zlogene 64bd5872a16 app-misc/yworklog20200104-10:17 zlogene ffaba0fba6a app-text/pdfshuffler 20200105-03:14 bman 0c00371747d dev-go/glide 20200101-08:43 zlogene 9dc47bec1ff dev-go/logrus20200103-23:03 mattst88 e5ef2c4bc82 dev-go/zglob 20200103-23:01 mattst88 3908fcf0333 dev-java/balloontip 20200104-09:21 fordfrog 137fc9015bc dev-php/magickwand 20191230-14:44 grknight 6a8e8e89a70 dev-php/PEAR-MDB2_Driver_mysql 20191230-14:43 grknight d5dce1eba37 dev-php/pecl-bbcode 20191230-14:45 grknight 91856534a83 dev-php/pecl-cairo 20191230-14:46 grknight b94f5fa0d2c dev-php/pecl-dbx 20191230-14:47 grknight f7fc55b3208 dev-php/pecl-haru20191230-14:48 grknight 4eb036e79bf dev-php/pecl-htscanner 20191230-14:48 grknight 12d14c2648a dev-php/pecl-libevent20191230-14:49 grknight 2fb50d63e57 dev-php/pecl-mongo 20191230-14:51 grknight 0b57e3d5340 dev-php/pecl-mysqlnd_ms 20191230-14:52 grknight 5f7fbb7dd37 dev-php/pecl-mysqlnd_qc 20191230-14:52 grknight 95854119c39 dev-php/pecl-sphinx 20191230-14:53 grknight a944ed37d7a dev-php/pecl-spl_types 20191230-14:55 grknight 368c42a529c dev-php/pecl-svn 20191230-14:55 grknight 12ea5452a9b dev-php/pecl-xrange 20191230-14:56 grknight e2600f572fc dev-php/suhosin 20191230-14:57 grknight f02c74a649c dev-php/xcache 20191230-14:58 grknight bc73929503b dev-python/anyvc 20200104-10:16 zlogene adb836b3001 dev-python/asciitree 20200104-10:16 zlogene adb836b3001 dev-python/beanstalkc20200104-10:16 zlogene adb836b3001 dev-python/bicyclerepair 20200104-10:16 zlogene adb836b3001 dev-python/buzhug20200104-10:16 zlogene adb836b3001 dev-python/cement20200104-10:16 zlogene adb836b3001 dev-python/cherrytemplate20200104-10:16 zlogene adb836b3001 dev-python/clientcookie 20200104-10:16 zlogene adb836b3001 dev-python/dib-utils 20200104-10:16 zlogene adb836b3001 dev-python/dirq 20200104-10:16 zlogene adb836b3001 dev-python/disqus-python 20200104-10:16 zlogene adb836b3001 dev-python/figleaf 20200104-10:16 zlogene adb836b3001 dev-python/flask-dashed 20200105-03:20 bman 3623c1486a3 dev-python/foolscap 20200104-10:16 zlogene adb836b3001 dev-python/gdmodule 20200104-10:16 zlogene adb836b3001 dev-python/graphy20200104-10:16 zlogene adb836b3001 dev-python/guppy 20200104-10:16 zlogene adb836b3001 dev-python/hachoir-regex 20200104-10:11 zlogene 39fc8f4d296 dev-python/happydoc 20200104-10:11 zlogene 39fc8f4d296 dev-python/hcluster 20200104-10:11 zlogene 39fc8f4d296 dev-python/hcs-utils 20200104-10:11 zlogene 39fc8f4d296 dev-python/hp3parclient 20200104-10:11 zlogene 39fc8f4d296 dev-python/htmlgen 20200104-10:11 zlogene 39fc8f4d296 dev-python/inotifyx 20200104-10:11 zlogene 39fc8f4d296 dev-python/irman-python 20200104-10:11 zlogene 39fc8f4d296 dev-python/jonpy 20200104-10:11 zlogene 39fc8f4d296 dev-python/keyczar 20200104-10:11 zlogene 39fc8f4d296 dev-python/keyrings_alt 20200104-10:11 zlogene 39fc8f4d296 dev-python/libextractor-python 20200104-10:11 zlogene 39fc8f4d296 dev-python/libiscsi-python 20200104-10:11 zlogene 39fc8f4d296 dev-python/libnatpmp 20200104-10:11 zlogene 39fc8f4d296 dev-python/log4py20200104-10:11 zlogene 39fc8f4d296 dev-python/louie 20200104-10:11 zlogene 39fc8f4d296 dev-python/lp_solve 20200104-10:11 zlogene 39fc8f4d296 dev-python/lupy 20200104-10:11 zlogene 39fc8f4d296 dev-python/m2secret 20200104-10:11 zlogene 39fc8f4d296 dev-python/mwlib-ext 20200104-10:11 zlogene 39fc8f4d296 dev-python/newt_syrup20200104-10:11 zlogene 39fc8f4d296 dev-python/numdisplay20200104-10:11 zlogene 39fc8f4d296 dev-python/optcomplete 20200104-10
Re: [gentoo-dev] New acct-* package policy
Am 21.12.19 um 18:32 schrieb Michał Górny: > Please commit and push uid-gid.txt [3] change to data/api.git *before* > your packages. This makes sure that any potential collisions are caught > as merge conflicts before they hit users. The CI also catches UID/GID > collisions. One remark from a "proxy-maintainer" view: A proxy-maintainer (like me) cannot commit or add github pull requests for https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.tx and therefore cannot allocate a valid UID/GID for valid new ebuilds in pull requests. So for proxy-maintained packages which need acct-user/acct-group ebuilds this must be - either done like before - announcement on the gentoo-dev ML, then committed by ??? - or done by a member of the proxy-maintainers group. Maybe you find the time to refine that exception in the documentation. Bye Martin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New acct-* package policy
* Martin Dummer: > A proxy-maintainer (like me) cannot commit or add github pull requests > for https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.tx We can, actually, using https://github.com/gentoo/api-gentoo-org to create pull requests in the usual manner. These PRs are usually processed significantly quicker than the ebuild-related ones. -Ralph
Re: [gentoo-dev] New acct-* package policy
On Mon, Jan 06, 2020 at 01:36:53AM +0100, Martin Dummer wrote: > Am 21.12.19 um 18:32 schrieb Michał Górny: > > Please commit and push uid-gid.txt [3] change to data/api.git *before* > > your packages. This makes sure that any potential collisions are caught > > as merge conflicts before they hit users. The CI also catches UID/GID > > collisions. > > > One remark from a "proxy-maintainer" view: > > A proxy-maintainer (like me) cannot commit or add github pull requests for > > https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.tx > > and therefore cannot allocate a valid UID/GID for valid new ebuilds in > pull requests. > > So for proxy-maintained packages which need acct-user/acct-group ebuilds > this must be > > - either done like before - announcement on the gentoo-dev ML, then > committed by ??? > > - or done by a member of the proxy-maintainers group. > > > Maybe you find the time to refine that exception in the documentation. > > > Bye > > Martin https://github.com/gentoo/api-gentoo-org/pulls -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] New acct-* package policy
On 1/6/20 2:36 AM, Martin Dummer wrote: > Am 21.12.19 um 18:32 schrieb Michał Górny: >> Please commit and push uid-gid.txt [3] change to data/api.git *before* >> your packages. This makes sure that any potential collisions are caught >> as merge conflicts before they hit users. The CI also catches UID/GID >> collisions. > > > pull requests. > > So for proxy-maintained packages which need acct-user/acct-group ebuilds > this must be > > - either done like before - announcement on the gentoo-dev ML, then > committed by ??? > > - or done by a member of the proxy-maintainers group. - your package will be assigned the next free ID by whoever commits. (your 2nd option) From the end-user point it doesn't matter much whether it's 321 or 320 as long as it stays the same after being merged. Although I'm still of the opinion we should try to **pick** same IDs that other distros use, but it's already looking desperate for that matter. But if you have time, please do make a pull request to URL mentioned by Ralph and Aaron. > > Maybe you find the time to refine that exception in the documentation. I think having some guidance on proxy-maint project wiki page about this whole acct- thing wouldn't hurt, but it may come a bit too late already. -- juippis signature.asc Description: OpenPGP digital signature
