Re:Re: Re:[gentoo-user] meson causes system freeze
I also suspected that it could be overheating, and I also set up a small fan just beside it to blow some wind towords it in order to cool it. It can even compile the gcc without freeze. But every time it goes to glib or systemd, it will freeze. I have also an older gentoo installation on that netbook on another partition. I remember that I tried "meson _build" for the same glib version in the older gentoo, it passed the configuration. I guess there could be some conflict between meson and something else or meson uses some libs with conflicts. I will provide the older gentoo system configuration later. Do I need to report this to the meson developer to see whether they could be of any help? At 2023-06-13 11:13:32, mad.scientist.at.la...@tutanota.com wrote: >Sounds like it may be overheating, laptops do that when they get dirty (so do >desktops). It can be amazingly consistent about which point they freeze. >I've had it happen 3 times trying to install the os that shall not be named >with some time between each occurrence. Compiling uses a lot of resources, >which is why I have an old server, specifically for compiling and possible >other heavy lifting. HP dl575 g7 with 4 processor chips, 12 cores each. I'm >about to update the cpu's 2 generations and to 16 cores each. It's loud but >powerful. Also an embarrassingly large amount of memory. I got a real deal >on it. > >--"Fascism begins the moment a ruling class, fearing the people may use their >political democracy to gain economic democracy, begins to destroy political >democracy in order to retain its power of exploitation and special privilege." >Tommy Douglas > > > > >Jun 12, 2023, 19:47 by johnstr...@163.com: > >> >> >> >> >> To be precise, when I tried "meson _build" in the >> "/var/tmp/.../glib-2.76.3/work/glib-2.76.3/", the system froze at the step I >> mentioned in my last email, not "stop". >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> At 2023-06-13 09:39:14, "johnstrass" wrote: >> >> >>> >>> Dear friends, >>> >>> >>> >>> >>> >>> I am using an Yeeloong netbook and it freezed when I was doing the >>> >>> >>> usual update of the world. I found that it was stoped at the step of >>> >>> >>> configuring the glib. The glib uses the meson to config it. Before >>> >>> >>> this freeze, it also froze at configuring the systemd-253.5 and I masked >>> >>> >>> the systemd. Systemd is also using the meson to do the configuration. I >>> >>> >>> suspect that the meson seems to conflict with something. I have tried >>> >>> >>> meson 1.1.1 and also downgraded the meson to 1.0.1, the same thing happens. >>> >>> >>> >>> >>> >>> The "emerge --info" shows >>> >>> >>> >>> >>> >>> [code] >>> >>> >>> Portage 3.0.48.1 (python 3.11.4-final-0, >>> default/linux/mips/17.0/mipsel/n32/systemd/merged-usr, gcc-13, >>> glibc-2.37-r3, 6.3.4-gentoo-Yeeloong mips64) >>> >>> >>> = >>> >>> >>> System uname: >>> Linux-6.3.4-gentoo-Yeeloong-mips64-ICT_Loongson-2_V0.3_FPU_V0.1-with-glibc2.37 >>> >>> >>> KiB Mem: 1025664 total, 65408 free >>> >>> >>> KiB Swap:8388592 total, 8387568 free >>> >>> >>> Timestamp of repository gentoo: Mon, 12 Jun 2023 10:15:01 + >>> >>> >>> Head commit of repository gentoo: 6de146db15fb2000c53d0af5fb284a1d34f9ea3d >>> >>> >>> sh bash 5.2_p15-r3 >>> >>> >>> ld GNU ld (Gentoo 2.40 p5) 2.40.0 >>> >>> >>> ccache version 4.8 [enabled] >>> >>> >>> app-misc/pax-utils:1.3.7::gentoo >>> >>> >>> app-shells/bash: 5.2_p15-r3::gentoo >>> >>> >>> dev-lang/perl: 5.36.1-r2::gentoo >>> >>> >>> dev-lang/python: 3.10.12::gentoo, 3.11.4::gentoo, >>> 3.12.0_beta2::gentoo >>> >>> >>> dev-util/ccache: 4.8-r2::gentoo >>> >>> >>> dev-util/cmake:3.26.4-r1::gentoo >>> >>> >>> dev-util/meson:1.0.1::gentoo >>> >>> >>> sys-apps/baselayout: 2.13-r1::gentoo >>> >>> >>> sys-apps/sandbox: 2.30-r1::gentoo >>> >>> >>> sys-apps/systemd: 253.4::gentoo >>> >>> >>> sys-devel/autoconf:2.71-r6::gentoo >>> >>> >>> sys-devel/automake:1.16.5-r1::gentoo >>> >>> >>> sys-devel/binutils:2.40-r5::gentoo >>> >>> >>> sys-devel/binutils-config: 5.5::gentoo >>> >>> >>> sys-devel/gcc: 11.3.1_p20230518::gentoo, >>> 13.1.1_p20230520::gentoo >>> >>> >>> sys-devel/gcc-config: 2.11::gentoo >>> >>> >>> sys-devel/libtool: 2.4.7-r1::gentoo >>> >>> >>> sys-devel/make:4.4.1-r1::gentoo >>> >>> >>> sys-kernel/linux-headers: 6.3::gentoo (virtual/os-headers) >>> >>> >>> sys-libs/glibc:2.37-r3::gentoo >>> >>> >>> Repositories: >>> >>> >>> >>> >>> >>> gentoo >>> >>> >>> location: /var/db/repos/gentoo >>> >>> >>> sync-type: rsync >>> >>> >>> sync-uri: rsync://mirrors.ustc.edu.cn/gentoo-portage >>> >>> >>> priority: -1000 >>> >>> >>> volatile: False >>> >>> >>> sync-rsync-verify-jobs: 1 >>> >>> >>>
Re: Re:[gentoo-user] meson causes system freeze
Sounds like it may be overheating, laptops do that when they get dirty (so do desktops). It can be amazingly consistent about which point they freeze. I've had it happen 3 times trying to install the os that shall not be named with some time between each occurrence. Compiling uses a lot of resources, which is why I have an old server, specifically for compiling and possible other heavy lifting. HP dl575 g7 with 4 processor chips, 12 cores each. I'm about to update the cpu's 2 generations and to 16 cores each. It's loud but powerful. Also an embarrassingly large amount of memory. I got a real deal on it. --"Fascism begins the moment a ruling class, fearing the people may use their political democracy to gain economic democracy, begins to destroy political democracy in order to retain its power of exploitation and special privilege." Tommy Douglas Jun 12, 2023, 19:47 by johnstr...@163.com: > > > > > To be precise, when I tried "meson _build" in the > "/var/tmp/.../glib-2.76.3/work/glib-2.76.3/", the system froze at the step I > mentioned in my last email, not "stop". > > > > > > > > > > > > > > > > > At 2023-06-13 09:39:14, "johnstrass" wrote: > > >> >> Dear friends, >> >> >> >> >> >> I am using an Yeeloong netbook and it freezed when I was doing the >> >> >> usual update of the world. I found that it was stoped at the step of >> >> >> configuring the glib. The glib uses the meson to config it. Before >> >> >> this freeze, it also froze at configuring the systemd-253.5 and I masked >> >> >> the systemd. Systemd is also using the meson to do the configuration. I >> >> >> suspect that the meson seems to conflict with something. I have tried >> >> >> meson 1.1.1 and also downgraded the meson to 1.0.1, the same thing happens. >> >> >> >> >> >> The "emerge --info" shows >> >> >> >> >> >> [code] >> >> >> Portage 3.0.48.1 (python 3.11.4-final-0, >> default/linux/mips/17.0/mipsel/n32/systemd/merged-usr, gcc-13, >> glibc-2.37-r3, 6.3.4-gentoo-Yeeloong mips64) >> >> >> = >> >> >> System uname: >> Linux-6.3.4-gentoo-Yeeloong-mips64-ICT_Loongson-2_V0.3_FPU_V0.1-with-glibc2.37 >> >> >> KiB Mem: 1025664 total, 65408 free >> >> >> KiB Swap: 8388592 total, 8387568 free >> >> >> Timestamp of repository gentoo: Mon, 12 Jun 2023 10:15:01 + >> >> >> Head commit of repository gentoo: 6de146db15fb2000c53d0af5fb284a1d34f9ea3d >> >> >> sh bash 5.2_p15-r3 >> >> >> ld GNU ld (Gentoo 2.40 p5) 2.40.0 >> >> >> ccache version 4.8 [enabled] >> >> >> app-misc/pax-utils: 1.3.7::gentoo >> >> >> app-shells/bash: 5.2_p15-r3::gentoo >> >> >> dev-lang/perl: 5.36.1-r2::gentoo >> >> >> dev-lang/python: 3.10.12::gentoo, 3.11.4::gentoo, >> 3.12.0_beta2::gentoo >> >> >> dev-util/ccache: 4.8-r2::gentoo >> >> >> dev-util/cmake: 3.26.4-r1::gentoo >> >> >> dev-util/meson: 1.0.1::gentoo >> >> >> sys-apps/baselayout: 2.13-r1::gentoo >> >> >> sys-apps/sandbox: 2.30-r1::gentoo >> >> >> sys-apps/systemd: 253.4::gentoo >> >> >> sys-devel/autoconf: 2.71-r6::gentoo >> >> >> sys-devel/automake: 1.16.5-r1::gentoo >> >> >> sys-devel/binutils: 2.40-r5::gentoo >> >> >> sys-devel/binutils-config: 5.5::gentoo >> >> >> sys-devel/gcc: 11.3.1_p20230518::gentoo, 13.1.1_p20230520::gentoo >> >> >> sys-devel/gcc-config: 2.11::gentoo >> >> >> sys-devel/libtool: 2.4.7-r1::gentoo >> >> >> sys-devel/make: 4.4.1-r1::gentoo >> >> >> sys-kernel/linux-headers: 6.3::gentoo (virtual/os-headers) >> >> >> sys-libs/glibc: 2.37-r3::gentoo >> >> >> Repositories: >> >> >> >> >> >> gentoo >> >> >> location: /var/db/repos/gentoo >> >> >> sync-type: rsync >> >> >> sync-uri: rsync://mirrors.ustc.edu.cn/gentoo-portage >> >> >> priority: -1000 >> >> >> volatile: False >> >> >> sync-rsync-verify-jobs: 1 >> >> >> sync-rsync-extra-opts: >> >> >> sync-rsync-verify-max-age: 24 >> >> >> sync-rsync-verify-metamanifest: no >> >> >> >> >> >> ACCEPT_KEYWORDS="mips ~mips" >> >> >> ACCEPT_LICENSE="@FREE" >> >> >> CBUILD="mips64el-unknown-linux-gnu" >> >> >> CFLAGS="-O2 -march=loongson2f -mhard-float -mplt -Wa,-mfix-loongson2f-nop >> -pipe" >> >> >> CHOST="mips64el-unknown-linux-gnu" >> >> >> CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" >> >> >> CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d >> /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild >> /etc/sandbox.d" >> >> >> CXXFLAGS="-O2 -march=loongson2f -mhard-float -mplt -Wa,-mfix-loongson2f-nop >> -pipe" >> >> >> DISTDIR="/var/cache/distfiles" >> >> >> EMERGE_DEFAULT_OPTS="--usepkg --with-bdeps=y" >> >> >> ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY >> GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE >> PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME
Re: [gentoo-user] trying to get sd card reader to work
On Mon, Jun 12, 2023 at 7:38 PM Wol wrote: > On 09/06/2023 23:50, Lee wrote: > > Modern kernels support damn near everything these days, the trick is > > finding the right things to enable in the kernel! > > > They can't support stuff if the hardware can't ... > > My first reaction was exactly that. I doubt the hardware is a true > SD-card reader, they're pretty ancient. The Inspiron 5759 in which the card reader finds itseif is ancient, circa 2015 if I have the date right. Don’t know what a “true” sd card reader is, but appropriate kernel config renders cards readable and writeable. Enough functionality for me. > > > Good to know it all works, but if you're sticking a new card in an old > reader, they may not be compatible. Don’t know what constitutes new/old, but these are <1 year old cards. Satisfied with empiric evidence that it all works. Have written mp3 files to this card and played them via Arduino/attached mp3 board. Sufficient for my purposes. Amazed that it all works! (Pushing beyond my comfort level with card reader/Arduino/mp3 board/wiring all this stuff together.) So… have been using Gentoo for 20+ years. Have gradually morphed from numerical analysis to sound processing to photography to elaborate wikis to modern languages (go) to microcontroller stuff. Gentoo has supported me throughout the journey, even as I’ve pushed way past my areas of expertise. Gentoo always seems to support what I want to do, provides documentation, and comes with a community that can point the way when I’ve confused myself. Best computing environment ever. Thanks to every one making it possible! John Blinka > >
Re:[gentoo-user] meson causes system freeze
To be precise, when I tried "meson _build" in the "/var/tmp/.../glib-2.76.3/work/glib-2.76.3/", the system froze at the step I mentioned in my last email, not "stop". At 2023-06-13 09:39:14, "johnstrass" wrote: Dear friends, I am using an Yeeloong netbook and it freezed when I was doing the usual update of the world. I found that it was stoped at the step of configuring the glib. The glib uses the meson to config it. Before this freeze, it also froze at configuring the systemd-253.5 and I masked the systemd. Systemd is also using the meson to do the configuration. I suspect that the meson seems to conflict with something. I have tried meson 1.1.1 and also downgraded the meson to 1.0.1, the same thing happens. The "emerge --info" shows [code] Portage 3.0.48.1 (python 3.11.4-final-0, default/linux/mips/17.0/mipsel/n32/systemd/merged-usr, gcc-13, glibc-2.37-r3, 6.3.4-gentoo-Yeeloong mips64) = System uname: Linux-6.3.4-gentoo-Yeeloong-mips64-ICT_Loongson-2_V0.3_FPU_V0.1-with-glibc2.37 KiB Mem: 1025664 total, 65408 free KiB Swap:8388592 total, 8387568 free Timestamp of repository gentoo: Mon, 12 Jun 2023 10:15:01 + Head commit of repository gentoo: 6de146db15fb2000c53d0af5fb284a1d34f9ea3d sh bash 5.2_p15-r3 ld GNU ld (Gentoo 2.40 p5) 2.40.0 ccache version 4.8 [enabled] app-misc/pax-utils:1.3.7::gentoo app-shells/bash: 5.2_p15-r3::gentoo dev-lang/perl: 5.36.1-r2::gentoo dev-lang/python: 3.10.12::gentoo, 3.11.4::gentoo, 3.12.0_beta2::gentoo dev-util/ccache: 4.8-r2::gentoo dev-util/cmake:3.26.4-r1::gentoo dev-util/meson:1.0.1::gentoo sys-apps/baselayout: 2.13-r1::gentoo sys-apps/sandbox: 2.30-r1::gentoo sys-apps/systemd: 253.4::gentoo sys-devel/autoconf:2.71-r6::gentoo sys-devel/automake:1.16.5-r1::gentoo sys-devel/binutils:2.40-r5::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/gcc: 11.3.1_p20230518::gentoo, 13.1.1_p20230520::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/make:4.4.1-r1::gentoo sys-kernel/linux-headers: 6.3::gentoo (virtual/os-headers) sys-libs/glibc:2.37-r3::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://mirrors.ustc.edu.cn/gentoo-portage priority: -1000 volatile: False sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-max-age: 24 sync-rsync-verify-metamanifest: no ACCEPT_KEYWORDS="mips ~mips" ACCEPT_LICENSE="@FREE" CBUILD="mips64el-unknown-linux-gnu" CFLAGS="-O2 -march=loongson2f -mhard-float -mplt -Wa,-mfix-loongson2f-nop -pipe" CHOST="mips64el-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d" CXXFLAGS="-O2 -march=loongson2f -mhard-float -mplt -Wa,-mfix-loongson2f-nop -pipe" DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS="--usepkg --with-bdeps=y" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg buildpkg-live ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo https://mirrors.163.com/gentoo; LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" LINGUAS="en zh" MAKEOPTS="-j1" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X acl bzip2 cjk cli crypt gdbm iconv ipv6 mips ncurses nls nptl pam pcre readline seccomp ssl systemd test-rust udev unicode xattr zlib" ABI_MIPS="n32" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock
[gentoo-user] meson causes system freeze
Dear friends, I am using an Yeeloong netbook and it freezed when I was doing the usual update of the world. I found that it was stoped at the step of configuring the glib. The glib uses the meson to config it. Before this freeze, it also froze at configuring the systemd-253.5 and I masked the systemd. Systemd is also using the meson to do the configuration. I suspect that the meson seems to conflict with something. I have tried meson 1.1.1 and also downgraded the meson to 1.0.1, the same thing happens. The "emerge --info" shows [code] Portage 3.0.48.1 (python 3.11.4-final-0, default/linux/mips/17.0/mipsel/n32/systemd/merged-usr, gcc-13, glibc-2.37-r3, 6.3.4-gentoo-Yeeloong mips64) = System uname: Linux-6.3.4-gentoo-Yeeloong-mips64-ICT_Loongson-2_V0.3_FPU_V0.1-with-glibc2.37 KiB Mem: 1025664 total, 65408 free KiB Swap:8388592 total, 8387568 free Timestamp of repository gentoo: Mon, 12 Jun 2023 10:15:01 + Head commit of repository gentoo: 6de146db15fb2000c53d0af5fb284a1d34f9ea3d sh bash 5.2_p15-r3 ld GNU ld (Gentoo 2.40 p5) 2.40.0 ccache version 4.8 [enabled] app-misc/pax-utils:1.3.7::gentoo app-shells/bash: 5.2_p15-r3::gentoo dev-lang/perl: 5.36.1-r2::gentoo dev-lang/python: 3.10.12::gentoo, 3.11.4::gentoo, 3.12.0_beta2::gentoo dev-util/ccache: 4.8-r2::gentoo dev-util/cmake:3.26.4-r1::gentoo dev-util/meson:1.0.1::gentoo sys-apps/baselayout: 2.13-r1::gentoo sys-apps/sandbox: 2.30-r1::gentoo sys-apps/systemd: 253.4::gentoo sys-devel/autoconf:2.71-r6::gentoo sys-devel/automake:1.16.5-r1::gentoo sys-devel/binutils:2.40-r5::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/gcc: 11.3.1_p20230518::gentoo, 13.1.1_p20230520::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/make:4.4.1-r1::gentoo sys-kernel/linux-headers: 6.3::gentoo (virtual/os-headers) sys-libs/glibc:2.37-r3::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://mirrors.ustc.edu.cn/gentoo-portage priority: -1000 volatile: False sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-max-age: 24 sync-rsync-verify-metamanifest: no ACCEPT_KEYWORDS="mips ~mips" ACCEPT_LICENSE="@FREE" CBUILD="mips64el-unknown-linux-gnu" CFLAGS="-O2 -march=loongson2f -mhard-float -mplt -Wa,-mfix-loongson2f-nop -pipe" CHOST="mips64el-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d" CXXFLAGS="-O2 -march=loongson2f -mhard-float -mplt -Wa,-mfix-loongson2f-nop -pipe" DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS="--usepkg --with-bdeps=y" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg buildpkg-live ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo https://mirrors.163.com/gentoo; LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" LINGUAS="en zh" MAKEOPTS="-j1" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X acl bzip2 cjk cli crypt gdbm iconv ipv6 mips ncurses nls nptl pam pcre readline seccomp ssl systemd test-rust udev unicode xattr zlib" ABI_MIPS="n32" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias"
Re: [gentoo-user] some help with wayland
On 10/06/2023 09:44, Michael wrote: Without sddm, you can run the startplasma-wayland stanza from a console, do your thing, logout and the console would have captured various logs - just as startx does. Does that actually work now? Last I tried I ended up looking for the docu, and found that it said that was a bad idea and not guaranteed to work. Certainly on my system, it just hung with, iirc, no logs whatsoever. Once I enabled sddm.service, it worked fine ... Cheers, Wol
Re: [gentoo-user] Re: Can't upgrade portage or update/install ebuilds
On 09/06/2023 21:16, Grant Edwards wrote: On 2023-06-09, Daniel Pielmeier wrote: If it is only about gemato then temporary disable the rsync-verify flag which pulls it in. # USE="-rsync-verify" emerge sys-apps/portage The problem I ran into is that you never know how many issues there are standing in the way of upgrading. The one time I decided to muscle my way through updating an "obsolete" Gentoo install, I spent a very long day fixing "one more problem" and trying again. It took many more hours than a scratch install would have taken, but at some point I decided to keep going just to see if I could make it all the way through the process. I did. Then I promised myself never to try that again. You do learn alot about how portage/emerge works... Learning that is a good idea maybe :-) But last time I had a well-out-of-date system, it was a long and messy process ... What I did was, every time portage said "giving up" or "conflict found" or whatever, I just took a note of as many of the packages I could remember that portage said it could emerge, and then manually updated them "emerge --update --one-shot". And any conflicts, if I dared, I simply deleted then "emerge -C --one-shot". And once I managed to get the system to complete an update, I then did a --deep --new-use. The idea is to update the absolute minimum possible to get your system up-to-date, so you probably only want to update @system not @world. If @system is up-to-date, it's not major if you break other stuff. Cheers, Wol
Re: [gentoo-user] trying to get sd card reader to work
On 09/06/2023 23:50, Lee wrote: Modern kernels support damn near everything these days, the trick is finding the right things to enable in the kernel! They can't support stuff if the hardware can't ... My first reaction was exactly that. I doubt the hardware is a true SD-card reader, they're pretty ancient. Good to know it all works, but if you're sticking a new card in an old reader, they may not be compatible. Cheers, Wol
Re: [gentoo-user] KWallet refuses to auto open at login
On Mon, 12 Jun 2023 at 09:33, Michael wrote: > > You could try making gnome keyring wait until a login session is up an running > and only run if an application asks for it. Take a look in /etc/pam.d/sddm > (or perhaps /etc/pam.d/sddm-autologin?) then add an 'only_if' conditional > statement at the end, e.g.: > > -session optional pam_gnome_keyring.so only_if=gdm,sddm,xdm, here> > > This means whenever an application requires gnome keyring it will ask you for > your passwd, instead of auto-unlocking it at the start of the desktop login > session. However, this may or may not fix your problem, because as you point > out the other host is working normally without this tweak. > Interesting suggestion, thanks! I tried this, as well as adding force_run to "-session optional pam_kwallet5.so auto_start" neither option worked. > out the other host is working normally without this tweak. I wonder ... is > the other host running on (much) slower hardware? > Yes and no. They're both Skylake machines with mobile CPUs, only difference is the one it's not working on is a quad-core i7 HQ series and the other (where it's working) is a dual-core i7 U-series low voltage. On the other hand, I decided to F it, and move back to Xorg. It all works fine on Xorg after the usual wipe of KDE-related stuff in ~/.config, ~/.local, and ~/.cache. Trying a Wayland session _after_ the fact, is still broken. Yet, I can't see anything in the logs to suggest why this might be the case. This, on top of Night Colour also not work well (gets stuck in whatever state it was in if the display goes to sleep) tells me Wayland is _still_ not ready for day to day use. Which is a shame, because it's _this_ close, but annoyances like the above are just not worth the hassle (yet). Ironically, the timing of my post is near perfect with that of the other thread re Wayland issues. Best Regards, Victor
Re: [gentoo-user] Re: google-chrome can render pages after update
On Monday, 12 June 2023 17:57:47 BST Grant Edwards wrote: > On 2023-06-12, Michael wrote: > >> It seems to be a variation on this bug which affects only AMD GPUs: > >> https://bugs.gentoo.org/907431 > >> > >> Clearing the GPU driver cache or using the > >> -disable-gpu-driver-bug-workarounds option avoids the problem. > >> > >> In my case, It wasn't a mesa update that triggered the problem. I > >> think it was the llvm update (I haven't confirmed that). > > > > Did you (re)compile anything graphics related using llvm, which > > might be used by the Chrome binary? > > No -- but as I understand it, mesa uses llvm (at runtime) to generate > GPU object code. Based on the work-around, it looks like compiled GPU > object code is cached by Chrome/Chromium, and updates to mesa and/or > llvm can result attempts to use old, incompatible GPU object code. > > As pages are rendered, there was a constant stream of "link failure" > messages on the console window where Chrome is running. Yes, you're right. Gallium llvmpipe driver uses llvm in runtime for rasterisation. I wasn't aware of this and thought llvm is only a build time compiler! :-) This also explains why clearing the cache fixes the problem of what is essentially stale code. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: google-chrome can render pages after update
On 2023-06-12, Michael wrote: >> It seems to be a variation on this bug which affects only AMD GPUs: >> >> https://bugs.gentoo.org/907431 >> >> Clearing the GPU driver cache or using the >> -disable-gpu-driver-bug-workarounds option avoids the problem. >> >> In my case, It wasn't a mesa update that triggered the problem. I >> think it was the llvm update (I haven't confirmed that). > > Did you (re)compile anything graphics related using llvm, which > might be used by the Chrome binary? No -- but as I understand it, mesa uses llvm (at runtime) to generate GPU object code. Based on the work-around, it looks like compiled GPU object code is cached by Chrome/Chromium, and updates to mesa and/or llvm can result attempts to use old, incompatible GPU object code. As pages are rendered, there was a constant stream of "link failure" messages on the console window where Chrome is running. > I don't have chrome/chromium installed here to directly compare > notes and so far qtwebengine appears to work fine after updating > llvm this morning, as does www-client/microsoft-edge. Firefix-bin still worked fine also. It only seemed to affect Chrome/Chromium or it's derivitives. -- Grant
Re: [gentoo-user] Re: google-chrome can render pages after update
On Monday, 12 June 2023 17:05:31 BST Grant Edwards wrote: > On 2023-06-12, Grant Edwards wrote: > > I did an update this morning which installed the following: > > aleph ~ # fgrep '>>> emerge ' emerge.log > > > > 1686579407: >>> emerge (1 of 11) dev-util/strace-6.3 to / > > 1686579455: >>> emerge (2 of 11) dev-libs/nspr-4.35-r2 to / > > 1686579470: >>> emerge (3 of 11) dev-python/fonttools-4.39.4 to / > > 1686579500: >>> emerge (4 of 11) dev-python/weasyprint-59.0 to / > > 1686579507: >>> emerge (5 of 11) net-print/cups-2.4.4 to / > > 1686579541: >>> emerge (6 of 11) sys-devel/llvm-15.0.7-r3 to / > > 1686582174: >>> emerge (7 of 11) app-portage/gemato-20.4 to / > > 1686582180: >>> emerge (8 of 11) media-libs/gstreamer-1.20.5 to / > > 1686582206: >>> emerge (9 of 11) dev-db/unixODBC-2.3.11 to / > > 1686582239: >>> emerge (10 of 11) media-libs/gst-plugins-base-1.20.5 > > to / > > 1686582282: >>> emerge (11 of 11) www-client/firefox-bin-114.0.1 to / > > > > Now google-chrome-stable Version 114.0.5735.106 (Official Build) > > (64-bit) can lo longer display pages proplerly. It looks like chunks > > of the application window are randomly scrambled or shown in the wrong > > places. AFIACT, the pages are being parsed/process properly but the > > actaul rendering of the X11 window is broken. > > It seems to be a variation on this bug which affects only AMD GPUs: > > https://bugs.gentoo.org/907431 > > Clearing the GPU driver cache or using the > -disable-gpu-driver-bug-workarounds option avoids the problem. > > In my case, It wasn't a mesa update that triggered the problem. I > think it was the llvm update (I haven't confirmed that). > > -- > Grant Did you (re)compile anything graphics related using llvm, which might be used by the Chrome binary? I don't have chrome/chromium installed here to directly compare notes and so far qtwebengine appears to work fine after updating llvm this morning, as does www-client/microsoft-edge. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: google-chrome can render pages after update
On 2023-06-12, Grant Edwards wrote: > I did an update this morning which installed the following: > > aleph ~ # fgrep '>>> emerge ' emerge.log > > 1686579407: >>> emerge (1 of 11) dev-util/strace-6.3 to / > 1686579455: >>> emerge (2 of 11) dev-libs/nspr-4.35-r2 to / > 1686579470: >>> emerge (3 of 11) dev-python/fonttools-4.39.4 to / > 1686579500: >>> emerge (4 of 11) dev-python/weasyprint-59.0 to / > 1686579507: >>> emerge (5 of 11) net-print/cups-2.4.4 to / > 1686579541: >>> emerge (6 of 11) sys-devel/llvm-15.0.7-r3 to / > 1686582174: >>> emerge (7 of 11) app-portage/gemato-20.4 to / > 1686582180: >>> emerge (8 of 11) media-libs/gstreamer-1.20.5 to / > 1686582206: >>> emerge (9 of 11) dev-db/unixODBC-2.3.11 to / > 1686582239: >>> emerge (10 of 11) media-libs/gst-plugins-base-1.20.5 to / > 1686582282: >>> emerge (11 of 11) www-client/firefox-bin-114.0.1 to / > > > Now google-chrome-stable Version 114.0.5735.106 (Official Build) > (64-bit) can lo longer display pages proplerly. It looks like chunks > of the application window are randomly scrambled or shown in the wrong > places. AFIACT, the pages are being parsed/process properly but the > actaul rendering of the X11 window is broken. It seems to be a variation on this bug which affects only AMD GPUs: https://bugs.gentoo.org/907431 Clearing the GPU driver cache or using the -disable-gpu-driver-bug-workarounds option avoids the problem. In my case, It wasn't a mesa update that triggered the problem. I think it was the llvm update (I haven't confirmed that). -- Grant
[gentoo-user] google-chrome can render pages after update
I did an update this morning which installed the following:
aleph ~ # fgrep '>>> emerge ' emerge.log
1686579407: >>> emerge (1 of 11) dev-util/strace-6.3 to /
1686579455: >>> emerge (2 of 11) dev-libs/nspr-4.35-r2 to /
1686579470: >>> emerge (3 of 11) dev-python/fonttools-4.39.4 to /
1686579500: >>> emerge (4 of 11) dev-python/weasyprint-59.0 to /
1686579507: >>> emerge (5 of 11) net-print/cups-2.4.4 to /
1686579541: >>> emerge (6 of 11) sys-devel/llvm-15.0.7-r3 to /
1686582174: >>> emerge (7 of 11) app-portage/gemato-20.4 to /
1686582180: >>> emerge (8 of 11) media-libs/gstreamer-1.20.5 to /
1686582206: >>> emerge (9 of 11) dev-db/unixODBC-2.3.11 to /
1686582239: >>> emerge (10 of 11) media-libs/gst-plugins-base-1.20.5 to /
1686582282: >>> emerge (11 of 11) www-client/firefox-bin-114.0.1 to /
Now google-chrome-stable Version 114.0.5735.106 (Official Build)
(64-bit) can lo longer display pages proplerly. It looks like chunks
of the application window are randomly scrambled or shown in the wrong
places. AFIACT, the pages are being parsed/process properly but the
actaul rendering of the X11 window is broken.
You can see examples here:
https://www.panix.com/~grante/chrome/foo.png
https://www.panix.com/~grante/chrome/bar.png
None of the other "big" X11 apps seem to be affected (firefox,
thunderbird, libre-office, etc. all work fine).
The console window where I launch chrome now spews almost continuous
errors like those show below. Has anybody else run into this? I'm
going to start backing out the updates above, but thought I'd check to
see if this was a known problem. I haven't found anything in buzilla
yet...
Errors:
link failed but did not provide an info log
[7110:7110:0612/103618.780116:ERROR:shared_context_state.cc(81)] Skia
shader compilation error
// Vertex SKSL
#extension GL_NV_shader_noperspective_interpolation: require
uniform float4 sk_RTAdjust;uniform float2 uAtlasSizeInv_S0;in float2
inPosition;in half4 inColor;in ushort2 inTextureCoords;noperspective out float2
vTextureCoords_S0;flat out float vTexIndex_S0;noperspective out half4
vinColor_S0;void main() {// Primitive Processor BitmapText
int texIdx = 0;float2 unormTexCoords = float2(inTextureCoords.x,
inTextureCoords.y);vTextureCoords_S0 = unormTexCoords *
uAtlasSizeInv_S0;vTexIndex_S0 = float(texIdx);vinColor_S0 = inColor;float2
_tmp_1_inPosition = inPosition;sk_Position = inPosition.xy01;}
// Fragment SKSL
#extension GL_NV_shader_noperspective_interpolation: require
const int kFillBW_S1_c0 = 0;
const int kInverseFillBW_S1_c0 = 2;
const int kInverseFillAA_S1_c0 = 3;
uniform float4 urectUniform_S1_c0;uniform sampler2D uTextureSampler_0_S0;
noperspective in float2 vTextureCoords_S0;flat in float
vTexIndex_S0;noperspective in half4 vinColor_S0;half4 Rect_S1_c0(half4 _input) {
half4 _tmp_0_inColor = _input;
half coverage;
if (int(2) == kFillBW_S1_c0 || int(2) == kInverseFillBW_S1_c0) {
coverage = half(all(greaterThan(float4(sk_FragCoord.xy,
urectUniform_S1_c0.zw), float4(urectUniform_S1_c0.xy, sk_FragCoord.xy;
} else {
half4 dists4 = saturate(half4(1.0, 1.0, -1.0, -1.0) *
half4(sk_FragCoord.xyxy - urectUniform_S1_c0));
half2 dists2 = (dists4.xy + dists4.zw) - 1.0;
coverage = dists2.x * dists2.y;
}
if (int(2) == kInverseFillBW_S1_c0 || int(2) == kInverseFillAA_S1_c0) {
coverage = 1.0 - coverage;
}
return half4(half4(coverage));
}
half4 Blend_S1(half4 _src, half4 _dst) {
return blend_modulate(Rect_S1_c0(_src), _src);}
void main() {// Stage 0, BitmapText
half4 outputColor_S0;outputColor_S0 = vinColor_S0;half4 texColor;{ texColor
= sample(uTextureSampler_0_S0, vTextureCoords_S0).; }half4
outputCoverage_S0 = texColor;half4 output_S1;output_S1 =
Blend_S1(outputCoverage_S0, half4(1));{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * output_S1;}}
// Vertex GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
uniform highp vec2 uAtlasSizeInv_S0;
in highp vec2 inPosition;
in mediump vec4 inColor;
in mediump uvec2 inTextureCoords;
noperspective out highp vec2 vTextureCoords_S0;
flat out highp float vTexIndex_S0;
noperspective out mediump vec4 vinColor_S0;
void main() {
highp int texIdx = 0;
highp vec2 unormTexCoords = vec2(float(inTextureCoords.x),
float(inTextureCoords.y));
vTextureCoords_S0 = unormTexCoords * uAtlasSizeInv_S0;
vTexIndex_S0 = float(texIdx);
vinColor_S0 = inColor;
gl_Position = vec4(inPosition, 0.0, 1.0);
gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww *
sk_RTAdjust.yw, 0.0, gl_Position.w);
}
//
Re: [gentoo-user] KWallet refuses to auto open at login
On Mon, 12 Jun 2023 at 06:53, Bryan Gardiner wrote: > Are you testing with LightDM and SDDM logins where you type your > password manually, rather than relying on autologin, or fingerprint > readers, etc.? If memory serves me, something needs to pass down the > password to kwallet, so with autologin, it can't unlock the wallet. > (At least, not without extra help, I see the Arch wiki mentions > pam_autologin for this but I haven't used it: [1]) > Yes, I never use auto login. It's password based SDDM set up. Configs are in line with suggestions in Gentoo Wiki. I too consulted the Arch Wiki but most of it overlaps (as one might expect). To be honest, these days the kde-plasma/kwallet-pam package comes with the correct config by default and I've not had to touch it manually.
Re: [gentoo-user] KWallet refuses to auto open at login
On Sunday, 11 June 2023 23:48:08 BST Victor Ivanov wrote: > On Sun, 11 Jun 2023 at 14:22, Neil Bothwick wrote: > > Anything in the logs? Maybe someting to indicate whether PAM is trying to > > open the wallet and failing, or whether it is not trying at all. > > Thanks, Neil, good point. Not that I can tell. /var/log/auth.log looks > identical on both systems after cold boot login. Here's an example > (same on both hosts): > > --- > Jun 11 23:13:04 somehost sddm-helper: pam_unix(sddm-greeter:session): > session opened for user sddm(uid=) by (uid=0) > Jun 11 23:13:06 somehost start-stop-daemon: > pam_unix(start-stop-daemon:session): session opened for user > pcscd(uid=(uid=) by (uid=0) > Jun 11 23:13:15 somehost sddm-helper: gkr-pam: unable to locate daemon > control file > Jun 11 23:13:15 somehost sddm-helper: gkr-pam: stashed password to try > later in open session > Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:auth): > pam_kwallet5: pam_sm_authenticate > Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred): > pam_kwallet5: pam_sm_setcred > Jun 11 23:13:15 somehost sddm-helper: pam_unix(sddm:session): session > opened for user *(uid=*) by (uid=0) > Jun 11 23:13:15 somehost sddm-helper: gkr-pam: gnome-keyring-daemon > started properly and unlocked keyring > Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:session): > pam_kwallet5: pam_sm_open_session > Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred): > pam_kwallet5: pam_sm_setcred > Jun 11 23:13:17 somehost gnome-keyring-daemon[5636]: discover_other_daemon: > 1 Jun 11 23:13:17 somehost polkitd[3881]: Registered Authentication > Agent for unix-session:2 (system bus name :1.48 > [/usr/lib64/libexec/polkit-kde-authentication-agent-1], object path > /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.utf8) > --- > > So it would appear "pam_kwalletd5" is loaded and initialised. There > are no errors It makes me wonder if gnome keyring is to blame and if > there's some sort of a race condition. On the other hand, there is the > message "discover_other_daemon: 1". I have seen the same in one of my systems. I understand the gkr message to be informational only, after all it succeeds once kwallet5 kicks in. > Besides, if it were a race I would > expect KWallet to work at least some of the time on either system, > while the issue is always reproducible on one host and never on the > other. Yes, or at least it would be logical to expect some error message if a race condition occurred and gnome keyring failed to authenticate. > Other logs such as "/var/log/sddm.log" and > "$HOME/.local/share/sddm/wayland-session.log" also look similar on > both hosts without anything related to KWallet. > > I've also one-shot "eix -I# sddm" (SDDM owns sddm-helper) with > --noconfmem. Still no luck. Use flags are more or less identical on > both hosts as well. > > Something is tricksing me badly and I'm one step from emerging @world > with --noconfmem and --empytree to see if that helps. You could try making gnome keyring wait until a login session is up an running and only run if an application asks for it. Take a look in /etc/pam.d/sddm (or perhaps /etc/pam.d/sddm-autologin?) then add an 'only_if' conditional statement at the end, e.g.: -session optional pam_gnome_keyring.so only_if=gdm,sddm,xdm, This means whenever an application requires gnome keyring it will ask you for your passwd, instead of auto-unlocking it at the start of the desktop login session. However, this may or may not fix your problem, because as you point out the other host is working normally without this tweak. I wonder ... is the other host running on (much) slower hardware? signature.asc Description: This is a digitally signed message part.
