RE: [gentoo-user] 5.4 kernels won't compile
"Pengcheng Xu" writes: > A quick Google with keyword "R_X86_64_PC64 uclibc" shows that uclibc is > missing some ELF definitions that are needed for newer kernels: > > https://gogs.waldemar-brodkorb.de/oss/uclibc-ng/issues/2 > > You may try the proposed solution there (to insert the definition into > /usr/include/elf.h), but IMHO this should be handled by uclibc-ng themselves > or a patch in Gentoo. As it seems like you've packaged uclibc-ng yourself > (sys-libs/uclibc-ng: 1.0.33::akater) maybe you would want to add a > patch there instead. Thank you! I did some web search (DDG) but managed to missed this. signature.asc Description: PGP signature
Re: [gentoo-user] Daily update fails
On Fri, 8 May 2020 16:20:46 +0200, Dan Johansson wrote: > After that "initial" update was done, I removed the added entries > (including the "PYTHON_SINGLE_TARGET: python2_7" ones) and started a > new emerge update. With exception of one package (net-misc/s3cmd) > everything went as it should. s3cmd has an older version in the tree, 2.0.2. 2.1.0 has python 3.7/8 support but no ebuild yet. There is a bug filed on this. -- Neil Bothwick Always proofread carefully to see if you any words out. pgpN9mLr36kWI.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Gcc-10.1.0, anyone?
On 5/8/20 2:18 PM, Peter Humphrey wrote: Afternoon all, Today's update included this latest version of gcc. I installed it, switched to it and rebuilt @system and the kernel. On booting, The system hung at its very first loading: as soon as I selected the kernel to boot, I got the usual "SHA256 validated" message, but it never went away. Yup, known problem. For the time being I've reverted to gcc-9.3.0. Is my experience of 10.1.0 typical? For the kernel you need [1], which is not yet in any released versions or even Linus' main tree. With it it works fine - using it right now. Most user-space packages should build & work fine; the ones that do not typically rely on bad legacy C behaviour that was previously permitted, but now leads to errors. That's a good thing. -h [1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=f670269a42bfdd2c83a1118cc3d1b475547eac22
Re: [gentoo-user] Daily update fails
On 07.05.20 16:30, Dan Johansson wrote: On 07.05.20 13:59, Franz Fellner wrote: On Thu May 7 10:04:37 2020, Dan Johansson wrote: Today when I tried to do my daily "emerge --update ... @world", portage spitted out a lot of "Multiple package instances within a single package slot have been pulled" messages. So THIS would have been the issue you should have given us to solve. Instead you borked your package.use by globally deactivating py2.7 and asked us to point you to that. So please: Revert the python changes you did in your package.use, rerun your update command and post the error you get with that. Please post the whole output, including the exact command you used. And also add "--tree --verbose" to the emerge options, this usually requires less guessing. Neil's suggestion made me add "PYTHON_SINGLE_TARGET: python2_7" to seven packages and now my box is happily compiling (will take some time as there are some "big" packages in there, i.e. firefox, chromium, ...). As per your suggestion I will remove */* PYTHON_TARGETS: python3_6 python3_7 */* PYTHON_SINGLE_TARGET: -* python3_6 and my "PYTHON_SINGLE_TARGET: python2_7" when finished and retry my emerge. If it fails I can certainly post the Output here. A short update: Following the suggestion in the news-item I added */* PYTHON_TARGETS: python3_6 python3_7 */* PYTHON_SINGLE_TARGET: -* python3_6 and "PYTHON_SINGLE_TARGET: python2_7" for selected packages to my use flags and run the update without issues. After that "initial" update was done, I removed the added entries (including the "PYTHON_SINGLE_TARGET: python2_7" ones) and started a new emerge update. With exception of one package (net-misc/s3cmd) everything went as it should. Thanks Niel for the hint about PYTHON_SINGLE_TARGET for the "misbehaving" packages. Regards, -- Dan Johansson, *** This message is printed on 100% recycled electrons! ***
[gentoo-user] Gcc-10.1.0, anyone?
Afternoon all, Today's update included this latest version of gcc. I installed it, switched to it and rebuilt @system and the kernel. On booting, The system hung at its very first loading: as soon as I selected the kernel to boot, I got the usual "SHA256 validated" message, but it never went away. For the time being I've reverted to gcc-9.3.0. Is my experience of 10.1.0 typical? -- Regards, Peter.
RE: [gentoo-user] 5.4 kernels won't compile
A quick Google with keyword "R_X86_64_PC64 uclibc" shows that uclibc is missing some ELF definitions that are needed for newer kernels: https://gogs.waldemar-brodkorb.de/oss/uclibc-ng/issues/2 You may try the proposed solution there (to insert the definition into /usr/include/elf.h), but IMHO this should be handled by uclibc-ng themselves or a patch in Gentoo. As it seems like you've packaged uclibc-ng yourself (sys-libs/uclibc-ng: 1.0.33::akater) maybe you would want to add a patch there instead. Regards, -- Pengcheng Xu https://jsteward.moe > -Original Message- > From: akater > Sent: Friday, May 8, 2020 7:43 PM > To: gentoo-user@lists.gentoo.org > Subject: [gentoo-user] 5.4 kernels won't compile > > Neither linux-5.4.28-gentoo nor linux-5.4.38-gentoo would compile, with the > following error: > > > CFLAGS="-Wno-error=undef" make && make modules_install > > HOSTCC scripts/basic/fixdep > > HOSTCC arch/x86/tools/relocs_32.o > > HOSTCC arch/x86/tools/relocs_64.o > > In file included from arch/x86/tools/relocs_64.c:18: > > arch/x86/tools/relocs.c: In function 'rel_type': > > arch/x86/tools/relocs.c:201:12: error: 'R_X86_64_PC64' undeclared (first use > in this function); did you mean 'R_X86_64_64'? > > 201 | REL_TYPE(R_X86_64_PC64), > > |^ > > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > > 197 | #define REL_TYPE(X) [X] = #X > > | ^ > > arch/x86/tools/relocs.c:201:12: note: each undeclared identifier is reported > only once for each function it appears in > > 201 | REL_TYPE(R_X86_64_PC64), > > |^ > > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > > 197 | #define REL_TYPE(X) [X] = #X > > | ^ > > arch/x86/tools/relocs.c:201:12: error: array index in initializer not of > integer type > > 201 | REL_TYPE(R_X86_64_PC64), > > |^ > > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > > 197 | #define REL_TYPE(X) [X] = #X > > | ^ > > arch/x86/tools/relocs.c:201:12: note: (near initialization for 'type_name') > > 201 | REL_TYPE(R_X86_64_PC64), > > |^ > > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > > 197 | #define REL_TYPE(X) [X] = #X > > | ^ > > arch/x86/tools/relocs.c: In function 'do_reloc64': > > arch/x86/tools/relocs.c:802:7: error: 'R_X86_64_PC64' undeclared (first use > in this function); did you mean 'R_X86_64_64'? > > 802 | case R_X86_64_PC64: > > | ^ > > | R_X86_64_64 > > make[1]: *** [scripts/Makefile.host:124: arch/x86/tools/relocs_64.o] > > Error 1 > > make: *** [arch/x86/Makefile:232: archscripts] Error 2 > > I did not find anything relevant on Gentoo forums or on this mailing list. > Configuration is a little non-standard. The first lines of emerge --info: > > > Portage 2.3.99 (python 3.7.7-final-0, > > default/linux/amd64/17.0/uclibc/hardened, gcc-9.3.0, uclibc-ng-1.0.33, > > 4.19.97-gentoo-poseidon x86_64) > > = > > System uname: > Linux-4.19.97-gentoo-poseidon-x86_64-Intel-R-_Core-TM-2_Duo_CPU_L9400_@_1. > 86GHz-with-gentoo-2.6 > > KiB Mem: 1929164 total,152428 free > > KiB Swap: 0 total, 0 free > > Timestamp of repository gentoo: Fri, 08 May 2020 05:00:01 + Head > > commit of repository gentoo: 92957d0a4e66217194d92beb864ef7b9f2c04cbb > > sh bash 5.0_p17 > > ld GNU ld (Gentoo 2.33.1 p2) 2.33.1 > > ccache version 3.7.7 [enabled] > > app-shells/bash: 5.0_p17::gentoo > > dev-lang/perl:5.30.1::gentoo > > dev-lang/python: 2.7.18::gentoo, 3.7.7-r2::gentoo, 3.8.2-r2::gentoo > > dev-util/ccache: 3.7.7-r1::gentoo > > dev-util/cmake: 3.16.5::akater > > sys-apps/baselayout: 2.6-r1::gentoo > > sys-apps/openrc: 0.42.1::gentoo > > sys-apps/sandbox: 2.13::gentoo > > sys-devel/autoconf: 2.69-r4::gentoo > > sys-devel/automake: 1.16.1-r1::gentoo > > sys-devel/binutils: 2.33.1-r1::gentoo > > sys-devel/gcc:9.3.0::gentoo > > sys-devel/gcc-config: 2.2.1::gentoo > > sys-devel/libtool:2.4.6-r6::gentoo > > sys-devel/make: 4.2.1-r4::gentoo > > sys-kernel/linux-headers: 5.4::gentoo (virtual/os-headers) > > sys-libs/uclibc-ng: 1.0.33::akater > > Please help. openpgp-digital-signature.asc Description: PGP signature
[gentoo-user] 5.4 kernels won't compile
Neither linux-5.4.28-gentoo nor linux-5.4.38-gentoo would compile, with the following error: > CFLAGS="-Wno-error=undef" make && make modules_install > HOSTCC scripts/basic/fixdep > HOSTCC arch/x86/tools/relocs_32.o > HOSTCC arch/x86/tools/relocs_64.o > In file included from arch/x86/tools/relocs_64.c:18: > arch/x86/tools/relocs.c: In function 'rel_type': > arch/x86/tools/relocs.c:201:12: error: 'R_X86_64_PC64' undeclared (first use > in this function); did you mean 'R_X86_64_64'? > 201 | REL_TYPE(R_X86_64_PC64), > |^ > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > 197 | #define REL_TYPE(X) [X] = #X > | ^ > arch/x86/tools/relocs.c:201:12: note: each undeclared identifier is reported > only once for each function it appears in > 201 | REL_TYPE(R_X86_64_PC64), > |^ > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > 197 | #define REL_TYPE(X) [X] = #X > | ^ > arch/x86/tools/relocs.c:201:12: error: array index in initializer not of > integer type > 201 | REL_TYPE(R_X86_64_PC64), > |^ > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > 197 | #define REL_TYPE(X) [X] = #X > | ^ > arch/x86/tools/relocs.c:201:12: note: (near initialization for 'type_name') > 201 | REL_TYPE(R_X86_64_PC64), > |^ > arch/x86/tools/relocs.c:197:22: note: in definition of macro 'REL_TYPE' > 197 | #define REL_TYPE(X) [X] = #X > | ^ > arch/x86/tools/relocs.c: In function 'do_reloc64': > arch/x86/tools/relocs.c:802:7: error: 'R_X86_64_PC64' undeclared (first use > in this function); did you mean 'R_X86_64_64'? > 802 | case R_X86_64_PC64: > | ^ > | R_X86_64_64 > make[1]: *** [scripts/Makefile.host:124: arch/x86/tools/relocs_64.o] Error 1 > make: *** [arch/x86/Makefile:232: archscripts] Error 2 I did not find anything relevant on Gentoo forums or on this mailing list. Configuration is a little non-standard. The first lines of emerge --info: > Portage 2.3.99 (python 3.7.7-final-0, > default/linux/amd64/17.0/uclibc/hardened, gcc-9.3.0, uclibc-ng-1.0.33, > 4.19.97-gentoo-poseidon x86_64) > = > System uname: > Linux-4.19.97-gentoo-poseidon-x86_64-Intel-R-_Core-TM-2_Duo_CPU_L9400_@_1.86GHz-with-gentoo-2.6 > KiB Mem: 1929164 total,152428 free > KiB Swap: 0 total, 0 free > Timestamp of repository gentoo: Fri, 08 May 2020 05:00:01 + > Head commit of repository gentoo: 92957d0a4e66217194d92beb864ef7b9f2c04cbb > sh bash 5.0_p17 > ld GNU ld (Gentoo 2.33.1 p2) 2.33.1 > ccache version 3.7.7 [enabled] > app-shells/bash: 5.0_p17::gentoo > dev-lang/perl:5.30.1::gentoo > dev-lang/python: 2.7.18::gentoo, 3.7.7-r2::gentoo, 3.8.2-r2::gentoo > dev-util/ccache: 3.7.7-r1::gentoo > dev-util/cmake: 3.16.5::akater > sys-apps/baselayout: 2.6-r1::gentoo > sys-apps/openrc: 0.42.1::gentoo > sys-apps/sandbox: 2.13::gentoo > sys-devel/autoconf: 2.69-r4::gentoo > sys-devel/automake: 1.16.1-r1::gentoo > sys-devel/binutils: 2.33.1-r1::gentoo > sys-devel/gcc:9.3.0::gentoo > sys-devel/gcc-config: 2.2.1::gentoo > sys-devel/libtool:2.4.6-r6::gentoo > sys-devel/make: 4.2.1-r4::gentoo > sys-kernel/linux-headers: 5.4::gentoo (virtual/os-headers) > sys-libs/uclibc-ng: 1.0.33::akater Please help. signature.asc Description: PGP signature
Re: [gentoo-user] Re: [OT] ubuntu equivalent of world file
2020-05-06 16:25 GMT+02:00, Mark Knecht : > On Wed, May 6, 2020 at 2:39 AM marco restelli wrote: > >> 2020-05-06 11:29 GMT+02:00, marco restelli : >> > Hi all, >> >this is a bit off topic, but probably is not an unknown problem for >> > many on the list. >> > >> > I am a long time gentoo user and I occasionally work on an Ubuntu >> > system. I wonder >> > whether there is an Ubuntu equivalent of the portage world file, to >> > separate the packages >> > installed because the user wants them and those that are only there as >> > a dependency. >> >> So, I finally found it short after posting: >> >> apt-mark showauto >> apt-mark showmanual >> >> does the job. >> >> Marco >> >> > $ cat /var/log/apt/history.log > ~/Desktop/allhistory.log && zcat /var/log/apt/history.log*gz >> ~/Desktop/allhistory.log OK, yes, this is also a solution, thank you. apt-mark gives the present state, looking into the logs provides the whole evolution. Marco
