Re: [gentoo-user] Exact setting in grub to default to a kernel by name?
>Let me rephrase the question more generally... given a >kernel "/boot/vmlinuz-fubar" how and where do I specify it by name as >the default boot kernel? What about this? https://www.stephenrlang.com/2017/06/setting-default-kernel-in-grub2/ -- Hund
[gentoo-user] Exact setting in grub to default to a kernel by name?
I have multiple (would you believe 2?) kernels in /boot. [x8940][waltdnes][~] ll /boot/vm* -rwxr-xr-x 1 root root 7046848 Jun 12 23:46 /boot/vmlinuz-experimental -rwxr-xr-x 1 root root 6986624 Jun 12 16:55 /boot/vmlinuz-production The grub kernel listing at bootup is - production kernel - production kernel recovery mode - experimental kernel - experimental kernel recovery mode The default is the first entry, i.e. "GRUB_DEFAULT=0" in /etc/default/grub. I prefer going with "experimental". If I screw up the config to the point where it can't boot, then I'll manually override to "production". The simple way of getting the third entry as default is "GRUB_DEFAULT=2" (remember to count from zero). This works for now. But what happens if/when I add more kernels for whatever reason? Let me rephrase the question more generally... given a kernel "/boot/vmlinuz-fubar" how and where do I specify it by name as the default boot kernel? -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Warnings during google-chrome build
On Sat, Jun 12, 2021 at 09:33:24PM +0100, Michael wrote
> On Saturday, 12 June 2021 19:16:17 BST Walter Dnes wrote:
> > * Messages for package www-client/google-chrome-91.0.4472.77:
> >
> > * USER_NS is required for sandbox to work
> > * Please check to make sure these options are set correctly.
> > * Failure to do so may cause unexpected problems.
> >
> > >>> Auto-cleaning packages...
>
> This involves the use of namespaces for sandboxing purposes and your
> configuration to enable it in the kernel:
>
> $ grep USER_NS /usr/src/linux/.config
> CONFIG_USER_NS=y
>
> More here:
>
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/docs/
> linux/sandboxing.md
I use a different "search" method. In the "make menuconfig" menu, the
top few lines state...
===
Arrow keys navigate the menu. selects submenus ---> (or empty
submenus ). Highlighted letters are hotkeys. Pressing
includes, excludes, modularizes features. Press to
exit, for Help, for Search. Legend: [*] built-in [ ]
===
Note the bit about " for Search". So I press "/" and type in
"USER_NS" or "CONFIG_USER_NS". It doesn't matter which, and it's not
case-sensitive. Hitting {ENTER} gives a list of hits, with associated
numbers. In this case, there's only one hit, with associated number
"1", so I press "1". That takes me to the *EXACT LOCATION* in the whole
"make menuconfig" layout where I need to press "Y" to enable it. Before
doing so, I tabbed over to the for this item. It mentions...
> When user namespaces are enabled in the kernel it is
> recommended that the MEMCG option also be enabled and that
> user-space use the memory control groups to limit the amount
> of memory a memory unprivileged users can use.
So I...
* the help
* tap "Y" to enable "CONFIG_USER_NS"
* out of the "Namespaces Support" menu
* out of the "Search Results"
This take me back to "make menuconfig" "base level". From there I
repeat the process for "MEMCG" (or "CONFIG_MEMCG") upper/lower case is OK.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Warnings during google-chrome build
On Saturday, 12 June 2021 19:16:17 BST Walter Dnes wrote: > Pale Moon is my "daily driver" web browser, but I need google-chrome > to handle Netflix DRM. Anyhow, I get some warnings at the end of the > build about... > > 1) Metadata location > > 2) USER_NS and sandbox > > Does everybody else get them? Chrome seems to work OK. > > == > * Final size of build directory: 4 KiB > * Final size of installed tree: 239104 KiB (233.5 MiB) > > * > * This package seems to install metainfo files into the following > * location(s): > * > * /usr/share/appdata > * > * This location is deprecated, it should not be used anymore by new > software. * Appdata/Metainfo files should be installed into > /usr/share/metainfo directory. * For more details, please see the > freedesktop Upstream Metadata guidelines at * > https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html * > * Gentoo Tracker bug: https://bugs.gentoo.org/709450 > * The above bug refers - just a change of path to store metadata of chromium into. Give it a few versions and it should drop out. > >>> Installing (5 of 5) www-client/google-chrome-91.0.4472.77::gentoo > > * >>> SetUID: [chmod go-r] /opt/google/chrome/chrome-sandbox ...[ > ok ] * Updating .desktop files database ... > [ ok ] * Updating icons cache ... > [ ok ] > >>> Recording www-client/google-chrome in "world" favorites file... > > * Messages for package media-fonts/liberation-fonts-2.1.3: > > * The following fontconfig configuration files have been installed: > * > * 60-liberation.conf > * > * Use `eselect fontconfig` to enable/disable them. > > * Messages for package www-client/google-chrome-91.0.4472.77: > > * USER_NS is required for sandbox to work > * Please check to make sure these options are set correctly. > * Failure to do so may cause unexpected problems. > > >>> Auto-cleaning packages... This involves the use of namespaces for sandboxing purposes and your configuration to enable it in the kernel: $ grep USER_NS /usr/src/linux/.config CONFIG_USER_NS=y More here: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/docs/ linux/sandboxing.md signature.asc Description: This is a digitally signed message part.
[gentoo-user] Warnings during google-chrome build
Pale Moon is my "daily driver" web browser, but I need google-chrome to handle Netflix DRM. Anyhow, I get some warnings at the end of the build about... 1) Metadata location 2) USER_NS and sandbox Does everybody else get them? Chrome seems to work OK. == * Final size of build directory: 4 KiB * Final size of installed tree: 239104 KiB (233.5 MiB) * * This package seems to install metainfo files into the following * location(s): * * /usr/share/appdata * * This location is deprecated, it should not be used anymore by new software. * Appdata/Metainfo files should be installed into /usr/share/metainfo directory. * For more details, please see the freedesktop Upstream Metadata guidelines at * https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html * * Gentoo Tracker bug: https://bugs.gentoo.org/709450 * >>> Installing (5 of 5) www-client/google-chrome-91.0.4472.77::gentoo * >>> SetUID: [chmod go-r] /opt/google/chrome/chrome-sandbox ...[ ok ] * Updating .desktop files database ... [ ok ] * Updating icons cache ... [ ok ] >>> Recording www-client/google-chrome in "world" favorites file... * Messages for package media-fonts/liberation-fonts-2.1.3: * The following fontconfig configuration files have been installed: * * 60-liberation.conf * * Use `eselect fontconfig` to enable/disable them. * Messages for package www-client/google-chrome-91.0.4472.77: * USER_NS is required for sandbox to work * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. >>> Auto-cleaning packages... -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed
On Saturday, 12 June 2021 15:43:18 BST Dr Rainer Woitok wrote:
> Greetings,
>
> it's been quite a while that I had problems doing my routine Gentoo up-
> grade. This time package "dev-texlive/texlive-basic-2021" balked, and
> in the build log I found this:
>
> * Package:dev-texlive/texlive-basic-2021
> * Repository: gentoo
> * Maintainer: aball...@gentoo.org t...@gentoo.org
> * USE:abi_x86_64 amd64 elibc_glibc kernel_linux luajittex
> userland_GNU * FEATURES: network-sandbox preserve-libs sandbox userpriv
> usersandbox ---8><---
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = "en_GB:en",
> LC_ALL = (unset),
> LC_MESSAGES = "C",
> LC_CTYPE = "C.UTF-8",
> LC_COLLATE = "C",
> LANG = "en_GB"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
>
> While the value of environment variable "LANGUAGE" is clearly mine, the
> other values except "LC_COLLATE" and "LC_ALL" are obviously _not mine_
> (in particular "LANG" is missing the ".utf8" part):
>
> $ sudo env | grep LANGU
> Password:
> LANGUAGE=en_GB:en
> $ sudo locale
> LANG=en_GB.utf8
> LC_CTYPE="en_GB.utf8"
> LC_NUMERIC="en_GB.utf8"
> LC_TIME="en_GB.utf8"
> LC_COLLATE=C
> LC_MONETARY="en_GB.utf8"
> LC_MESSAGES="en_GB.utf8"
> LC_PAPER="en_GB.utf8"
> LC_NAME="en_GB.utf8"
> LC_ADDRESS="en_GB.utf8"
> LC_TELEPHONE="en_GB.utf8"
> LC_MEASUREMENT="en_GB.utf8"
> LC_IDENTIFICATION="en_GB.utf8"
> LC_ALL=
> $
>
> Using "grep" to sift through my build logs the first occurance of the
> line "perl: warning: Setting locale failed." occured a year ago at 2020-
> 05-18 while upgrading package "media-libs/exiftool-11.93" and since then
> it is present in quite a few build logs without apparently doing any
> harm. However, now making "luatex", "luahbtex", and "dviluatex" as part
> of package "dev-texlive/texlive-basic-2021" all failed with "Unable to
> read environment locale: exit now." and finally caused the build to die:
>
> ---8><---
> fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence
> order): fmtutil: texmf-dist/fmtutil/format.texlive-basic.cnf
> fmtutil: fmtutil is using the following fmtutil.cnf file for writing
> changes: fmtutil: texmf-dist/fmtutil/format.texlive-basic.cnf
> fmtutil [INFO]: writing formats under
> /var/tmp/portage/dev-texlive/texlive-basic-2021/work/texmf-var/web2c
> fmtutil [INFO]: --- remaking luatex with luatex
> fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini'
> ... Unable to read environment locale: exit now.
> ---8><---
> fmtutil [INFO]: --- remaking luahbtex with luahbtex
> fmtutil: running `luahbtex -ini -jobname=luahbtex -progname=luahbtex
> luatex.ini' ... Unable to read environment locale: exit now.
> ---8><---
> fmtutil [INFO]: --- remaking dviluatex with luatex
> fmtutil: running `luatex -ini -jobname=dviluatex -progname=dviluatex
> dviluatex.ini' ... Unable to read environment locale: exit now.
> ---8><---
> fmtutil [INFO]: failed to build: 3 (luatex/luatex luahbtex/luahbtex
> luatex/dviluatex) fmtutil [INFO]: total formats: 8
> fmtutil [INFO]: exiting with status 3
> * ERROR: dev-texlive/texlive-basic-2021::gentoo failed (compile phase):
> * failed to build format texmf-dist/fmtutil/format.texlive-basic.cnf
> *
> * Call stack:
> * ebuild.sh, line 125: Called src_compile
> * environment, line 510: Called texlive-module_src_compile
> * environment, line 721: Called die
> * The specific snippet of code:
> * VARTEXFONTS="${T}/fonts"
> TEXMFHOME="${S}/texmf:${S}/texmf-dist:${S}/texmf-var" env -u TEXINPUTS
> $fmt_call --cnffile "${i}" --fmtdir "${S}/texmf-var/web2c" --all || die
> "failed to build format ${i}";
>
> Is the failure to make "luatex", "luahbtex", and "dviluatex" due to not
> being able to "read environment locale" a consequence of "perl" claiming
> to have problems with _my_ locale? If not, what else is going on here?
>
> Sincerely,
> Rainer
I can't speak for your lua* packages, but as long as you have defined your
locale correctly in /etc/locale.gen your system should source what it needs
from there.
Regarding perl complaining, there was a perl update recently (stable) so
running perl-cleaner is recommended and may fix at least your texlive-basic
issue.
signature.asc
Description: This is a digitally signed message part.
[gentoo-user] Building package "dev-texlive/texlive-basic-2021" failed
Greetings,
it's been quite a while that I had problems doing my routine Gentoo up-
grade. This time package "dev-texlive/texlive-basic-2021" balked, and
in the build log I found this:
* Package:dev-texlive/texlive-basic-2021
* Repository: gentoo
* Maintainer: aball...@gentoo.org t...@gentoo.org
* USE:abi_x86_64 amd64 elibc_glibc kernel_linux luajittex userland_GNU
* FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox
---8><---
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB:en",
LC_ALL = (unset),
LC_MESSAGES = "C",
LC_CTYPE = "C.UTF-8",
LC_COLLATE = "C",
LANG = "en_GB"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
While the value of environment variable "LANGUAGE" is clearly mine, the
other values except "LC_COLLATE" and "LC_ALL" are obviously _not mine_
(in particular "LANG" is missing the ".utf8" part):
$ sudo env | grep LANGU
Password:
LANGUAGE=en_GB:en
$ sudo locale
LANG=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE=C
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=
$
Using "grep" to sift through my build logs the first occurance of the
line "perl: warning: Setting locale failed." occured a year ago at 2020-
05-18 while upgrading package "media-libs/exiftool-11.93" and since then
it is present in quite a few build logs without apparently doing any
harm. However, now making "luatex", "luahbtex", and "dviluatex" as part
of package "dev-texlive/texlive-basic-2021" all failed with "Unable to
read environment locale: exit now." and finally caused the build to die:
---8><---
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil: texmf-dist/fmtutil/format.texlive-basic.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil: texmf-dist/fmtutil/format.texlive-basic.cnf
fmtutil [INFO]: writing formats under
/var/tmp/portage/dev-texlive/texlive-basic-2021/work/texmf-var/web2c
fmtutil [INFO]: --- remaking luatex with luatex
fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ...
Unable to read environment locale: exit now.
---8><---
fmtutil [INFO]: --- remaking luahbtex with luahbtex
fmtutil: running `luahbtex -ini -jobname=luahbtex -progname=luahbtex
luatex.ini' ...
Unable to read environment locale: exit now.
---8><---
fmtutil [INFO]: --- remaking dviluatex with luatex
fmtutil: running `luatex -ini -jobname=dviluatex -progname=dviluatex
dviluatex.ini' ...
Unable to read environment locale: exit now.
---8><---
fmtutil [INFO]: failed to build: 3 (luatex/luatex luahbtex/luahbtex
luatex/dviluatex)
fmtutil [INFO]: total formats: 8
fmtutil [INFO]: exiting with status 3
* ERROR: dev-texlive/texlive-basic-2021::gentoo failed (compile phase):
* failed to build format texmf-dist/fmtutil/format.texlive-basic.cnf
*
* Call stack:
* ebuild.sh, line 125: Called src_compile
* environment, line 510: Called texlive-module_src_compile
* environment, line 721: Called die
* The specific snippet of code:
* VARTEXFONTS="${T}/fonts"
TEXMFHOME="${S}/texmf:${S}/texmf-dist:${S}/texmf-var" env -u TEXINPUTS
$fmt_call --cnffile "${i}" --fmtdir "${S}/texmf-var/web2c" --all || die "failed
to build format ${i}";
Is the failure to make "luatex", "luahbtex", and "dviluatex" due to not
being able to "read environment locale" a consequence of "perl" claiming
to have problems with _my_ locale? If not, what else is going on here?
Sincerely,
Rainer
Re: [gentoo-user] gdm is running Xwayland, what about startx?
Ühel kenal päeval, T, 08.06.2021 kell 18:04, kirjutas Adam Carter: > I've noticed that my gdm system is running /usr/bin/Xwayland instead of > /usr/bin/Xorg, so I infer that Gentoo devs, or upstream, are preferring > it now. It isn't really running in Xwayland really, it's running natively with the Wayland protocol. Xwayland is a by-product of supporting applications that still use X11 and settings for such applications. gdm itself does not implement a GUI - it makes use of a login mode of gnome-shell for that purpose. Future versions of GNOME will be able to default to running Xwayland on-demand, so in the future you won't see Xwayland running with just gdm, as no legacy applications are needed. Right now I believe some accessibility things might need it still in theory, so it isn't yet always skipped with GDM either. GDM uses wayland when it can and all the support has been built for that with USE=wayland on a bunch of packages, including GDM itself. > Can i try Xwayland with startx? No, Xwayland isn't something that can really run without a native Wayland compositor, to my knowledge. You can read up on what Xwayland is from https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Compatibility_with_X and elsewhere through your favorite Internet search engine. > pstree shows the execution paths as below. Inscrutable to me and > interesting that they're so different. > > gdm: systemd -> gnome-shell -> Xwayland > startx: startx -> xinit -> X (AND in parallel) gnome-session -> gnome- > shell startx is incapable of running Wayland sessions, so it forces the legacy Xorg GNOME session, which you'd also get if you explicitly choose "GNOME on Xorg" from gdm. One big benefit of having GDM running with Wayland, even if you have to pick Xorg for your GNOME due to some legacy app not supporting screencasting portal or something along those lines, is that GDM when using Wayland is capable of shutting down the gnome-shell it uses when you aren't on GDM VT (i.e, have logged into a desktop session) and will start it back up when you go back to GDM VT (i.e, you log out of your desktop), which is not implemented for Xorg using GDM. This saves on memory usage, as you don't have a background gnome-shell kept running. Currently GDM also is incapable of starting Wayland session when it itself isn't "using" Wayland. Best, Mart signature.asc Description: This is a digitally signed message part
