[gentoo-user] Re: app-emulation/docker-20.10.2 ebuild is borked?
On 09/01/2021 05:02, Ionen Wolkens wrote: On Sat, Jan 09, 2021 at 03:46:10AM +0200, Nikos Chantziaras wrote: Portage was trying to update docker from 20.10.1 to 20.10.2. However, it aborts with: ERROR: setup CONFIG_RT_GROUP_SCHED: is not set when it should be. I don't believe this check aborts the build, maybe something else happened? At least it doesn't for me. Hm, right. It says "ERROR" so I assumed it's an error, not a warning. I replied to https://bugs.gentoo.org/764524#c1 which should answer both issues. I'm assuming some extra changes were accidentally merged while adding cli USE. Thank you! Performing those two changes in the ebuild fixed it.
Re: [gentoo-user] app-emulation/docker-20.10.2 ebuild is borked?
On Sat, Jan 09, 2021 at 03:46:10AM +0200, Nikos Chantziaras wrote: > Portage was trying to update docker from 20.10.1 to 20.10.2. However, it > aborts with: > >ERROR: setup >CONFIG_RT_GROUP_SCHED: is not set when it should be. I don't believe this check aborts the build, maybe something else happened? At least it doesn't for me. >ERROR: compile >ERROR: app-emulation/docker-20.10.2::local failed (compile phase): > USE Flag 'selinux' not in IUSE for app-emulation/docker-20.10.2 > > OK, so I added "selinux" to IUSE. Portage now aborts with: > >Building: bundles/dynbinary-daemon/dockerd-dev >GOOS="" GOARCH="" GOARM="" >cannot find package "github.com/docker/docker/cmd/dockerd" in any of: >/usr/lib/go/src/github.com/docker/docker/cmd/dockerd (from $GOROOT) > > /var/tmp/portage/app-emulation/docker-20.10.2/work/docker-20.10.2/src/github.com/docker/docker/cmd/dockerd > > (from $GOPATH) >* ERROR: app-emulation/docker-20.10.2::local failed (compile phase): >* dynbinary failed > > Unfortunately, 20.10.1 was deleted from portage and I cannot go back as > docker-cli has already been updated to 20.10.2... > I replied to https://bugs.gentoo.org/764524#c1 which should answer both issues. I'm assuming some extra changes were accidentally merged while adding cli USE. -- ionen signature.asc Description: PGP signature
[gentoo-user] app-emulation/docker-20.10.2 ebuild is borked?
Portage was trying to update docker from 20.10.1 to 20.10.2. However, it aborts with: ERROR: setup CONFIG_RT_GROUP_SCHED: is not set when it should be. That's a stupid requirement and not needed, as it breaks realtime scheduling with rtkit (PulseAudio for example.) So I copied the ebuild to my local overlay and removed ~RT_GROUP_SCHED from CONFIG_CHECK. Portage now aborts with: ERROR: compile ERROR: app-emulation/docker-20.10.2::local failed (compile phase): USE Flag 'selinux' not in IUSE for app-emulation/docker-20.10.2 OK, so I added "selinux" to IUSE. Portage now aborts with: Building: bundles/dynbinary-daemon/dockerd-dev GOOS="" GOARCH="" GOARM="" cannot find package "github.com/docker/docker/cmd/dockerd" in any of: /usr/lib/go/src/github.com/docker/docker/cmd/dockerd (from $GOROOT) /var/tmp/portage/app-emulation/docker-20.10.2/work/docker-20.10.2/src/github.com/docker/docker/cmd/dockerd (from $GOPATH) * ERROR: app-emulation/docker-20.10.2::local failed (compile phase): * dynbinary failed Unfortunately, 20.10.1 was deleted from portage and I cannot go back as docker-cli has already been updated to 20.10.2... Help?
Re: [gentoo-user] Gentoo chroot with old glibc
Am Montag, 4. Januar 2021, 13:57:37 EET schrieb Thomas Mueller: > > > That's what I did: I found a 2017 stage3 with a still older glibc and > > > managed to upgrade to a 2020 gentoo while masking the last glibc > > > versions. That was tricky because I had to git-checkout intermediate > > > versions of the portage tree in order to deal with the EAPI changes but > > > I have a working chroot now. Thanks. > > > > That's the easy way to do it, yes. > > > > The hard way is to treat this as a cross-compilation problem and bootstrap > > your own stages from scratch. Instructions would be a bit longer... > > > > Andreas K. Hüttel > > I have looked through crossdev. Is that what it would take to cross-compile > and bootstrap stages from scratch? > > Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD > or NetBSD? In principle yes, but every experimental piece can add more problems. It's probably best to start with a base that is as boring as possible. What crossdev does is (simplified) * "create" (as symlinks) ebuilds for cross-compiler, cross-binutils, and target glibc * build cross-compiler, cross-binutils, and target glibc * installs a wrapper for emerge that uses these For example, you end up on an amd64 system with an additional directory /usr/ riscv64-unknown-linux-gnu that contains * a gcc that runs on amd64 (CBUILD) but generates code for riscv64 (CTARGET) * a binutils that runs on amd64 but works with files for riscv64 * a glibc for riscv64 Then, using commands like riscv64-unknown-linux-gnu-emerge -av @system you can build in /usr/riscv64-unknown-linux-gnu pieces of the target system. This works only in a very limited way, since many upstream build systems do not support cross-compiling. However, with some patience you can get to the point where the directory can be tarred up and used as a chroot on the target architecture. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: ld: skipping incompatible /usr/lib/libpthread.so
On 2021-01-08, Grant Edwards wrote: > I've noticed that when linking an applicatoin I now get warnings like this: > > /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible > /usr/lib/libpthread.so when searching for -lpthread > /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible > /usr/lib/libpthread.a when searching for -lpthread > /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible > /usr/lib/libc.so when searching for -lc > /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible > /usr/lib/libc.a when searching for -lc > > Those files appear to be 32-bit versions. Never mind. I just noticed that the build script is specifying -L /usr/lib when it should not. That's what's causing the warnings.
[gentoo-user] ld: skipping incompatible /usr/lib/libpthread.so
I've noticed that when linking an applicatoin I now get warnings like this: /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/gcc/[...]/x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc Those files appear to be 32-bit versions. Did I screw something up back when updating the profile from 17.0 to 17.1? -- Grant
[gentoo-user] Voting for the best software of 2020 on LinuxQuestions.org
Recently, I got an e-mail on voting for the best software of 2020 (including the preferred Linux distribution) on LinuxQuestions.org and think that it may be of interest for gentoo-users as well (and will help Gentoo to be better presented :). Moreover, the more users will vote, the more interesting will be the results. The original e-mail is provided below. -- Forwarded message - От: Date: ср, 6 янв. 2021 г. в 00:23 Subject: LinuxQuestions.org - Community Bulletin Voting for the 2020 LinuxQuestions.org Members Choice Awards is now open. The Members Choice Awards allow the Linux community to select their favorite products in a variety of categories. Awards will be given out in 40 categories this year, including Browser of the Year, Desktop and Server Distribution of the Year, Linux/Open Source Podcast of the Year, Audio Media Player of the Year, and more. The polls will close on February 17th. Visit https://www.linuxquestions.org/questions/2020-linuxquestions-org-members-choice-awards-131/welcome-to-the-2020-linuxquestions-org-members-choice-awards-4175687341/ for more information. Vote now and make sure your voice is heard! -jeremy http://jeremy.linuxquestions.org/
Re: [gentoo-user] Screen/driver/xserver freezing after suspension
On 07/01/2021 18:48, Igor Mróz wrote: On Thu, 7 Jan 2021 13:47:56 +0100 Hogren wrote: Did you try to open another tty after a freeze (CTRL + ALT [0-9]) ? Yes - screen is completely frozen and only way to interact with system is via ALT + SysRq. I've also tried to reboot/shutdown system via SSH, but it didn't work. After execute a remote reboot, how long did you wait before to force the machine ? Do you have systemd ? Did you analyse journalctl (you just said dmesg/logs) ? Regards Hogren
