Requests for current-next (15.0-->15.1)

lonestar_italy · 10-29-2023, 06:48 AM

Quote:

Originally Posted by marav

As far as possible, a generic kernel should be suitable for all hardware and for all users

I understand that the naming doesn't suggest so, but I always considered the huge kernel to be the one meant for "all users" who aren't skilled yet or are in a hurry, while the generic being meant to be small and with less impact.

marav · 10-29-2023, 07:13 AM

Quote:

Originally Posted by lonestar_italy

I understand that the naming doesn't suggest so, but I always considered the huge kernel to be the one meant for "all users" who aren't skilled yet or are in a hurry, while the generic being meant to be small and with less impact.

To be honest, in this great world of Linux distributions, absolutely nobody provides a huge kernel with all these built-in modules
They provide a kind of generic kernel with initramfs (self generated, ditto after each kernel update)
Mr Volkerding has been kind enough to propose a workaround to that self generation of the initrd, i.e. the generic kernel no longer needs one, at least for booting (in most cases)

Are you suggesting that Slackware users are less skilled than all other users?

ZhaoLin1457 · 10-29-2023, 08:11 AM

Quote:

Originally Posted by marav

To be honest, in this great world of Linux distributions, absolutely nobody provides a huge kernel with all these built-in modules
They provide a kind of generic kernel with initramfs (self generated, ditto after each kernel update)

Indeed, all other major Linux distributions manage initrd by themselves, without user intervention.

And it was discussed in detail in this forum, how it is possible to do the same in Slackware. It is very simple to do this. What apparently is missing is the will to do it.

Quote:

Originally Posted by marav

Mr Volkerding has been kind enough to propose a workaround to that self generation of the initrd, i.e. the generic kernel no longer needs one, at least for booting (in most cases)

Let's be honest. It's not even a workaround. It is a concession made to some people who refuse to learn to use an initrd.

Quote:

Originally Posted by marav

Are you suggesting that Slackware users are less skilled than all other users?

How can you describe the attitude of some people who consider it a burden to learn to use /etc/mkinitrd.conf.sample ? Technologically challenged?

For your enjoyment, I've attached this Slackware configuration file below. Would you mind explaining to me what is difficult to understand in this file?

Code:

# mkinitrd.conf.sample
# See "man mkinitrd.conf" for details on the syntax of this file
#
#SOURCE_TREE="/boot/initrd-tree"
#CLEAR_TREE="0"
#OUTPUT_IMAGE="/boot/initrd.gz"
#KERNEL_VERSION="$(uname -r)"
#KEYMAP="us"
#MODULE_LIST="ext4"
#LUKSDEV="/dev/sda2"
#LUKSTRIM="/dev/sda2" # verify support with 'hdparm -I $dev | grep TRIM'
#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
#ROOTDEV="/dev/sda1"
#ROOTFS="ext4"
#RESUMEDEV="/dev/sda2"
#RAID="0"
#LVM="0"
#UDEV="1"
#MODCONF="0"
#MICROCODE_ARCH="/boot/intel-ucode.cpio"
#WAIT="1"

Personally, I think it is ridiculous some people to call what I do "advanced usage", when it comes to a Slackware system installed in an SD-card, using UUIDs for portability. If really I am an "advanced user", then the general level of knowledge in the Slackware community hits the deep bottom.

Andrew_R · 10-29-2023, 08:35 AM

Quote:

Originally Posted by Andrew_R

I take liberty to request SPIRV-LLVM-Translator:

Ah, it already included in -current, my bad (but some linking still might help with clover - opencl-c.h and opencl-c-base.h from llvm package should be put somewhere system-readable, like /usr/include, instead of /usr/lib/clang/16/include/ on my machine or similar with llvm-17 from -current).

also, making rust-book separate from rust itself might save some 500 Mb of /usr/doc space on someone's limited tmpfs during update ...

franzen · 10-29-2023, 08:38 AM

Quote:

Originally Posted by Petri Kaukasoina

EDIT: OK, dropping the huge kernel was already considered in ChangeLog.txt: "First of all, it's clear that some Slackware users have been using the huge kernel all along, without an initrd, and are (to say the least) unhappy about the prospect of a new requirement to start using one."

The changelog also says: "The conclusion that I've come to here is that rather than drop the huge
kernel, ... it would be better to make the generic kernel more huge, and minimize the differences between the two kernel
configs."

which sounds like keeping two kernels.

ZhaoLin1457 · 10-29-2023, 08:50 AM

Speaking of the new generic kernel a bit huge, it is not able to mount the EFI partition without the associated modules.

This will block the user's access to the EFI partition, if he does a kernel upgrade and has uninstalled the associated kernel-modules. It is one of the main reasons for user errors when using elilo or similar bootloaders which needs putting files in the EFI partition.

Code:

root@darkstar:~# mv /lib/modules//6.1.60 /lib/modules/6.1.60.bak
root@darkstar:~# 
root@darkstar:~# mount /boot/efi
mount: /boot/efi: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.
root@darkstar:~# 
root@darkstar:~# mv /lib/modules/6.1.60.bak /lib/modules/6.1.60
root@darkstar:~#

Petri Kaukasoina · 10-29-2023, 09:05 AM

Quote:

Originally Posted by ZhaoLin1457

Speaking of the new generic kernel a bit huge, it is not able to mount the EFI partition without the associated modules.

I guess config-generic needs CONFIG_NLS_ISO8859_1=y

ZhaoLin1457 · 10-29-2023, 09:18 AM

Quote:

Originally Posted by Petri Kaukasoina

I guess config-generic needs CONFIG_NLS_ISO8859_1=y

And CONFIG_NLS_CODEPAGE_437=y

Petri Kaukasoina · 10-29-2023, 09:19 AM

Quote:

Originally Posted by ZhaoLin1457

And CONFIG_NLS_CODEPAGE_437=y

It is there already.

ZhaoLin1457 · 10-29-2023, 09:22 AM

Quote:

Originally Posted by Petri Kaukasoina

It is there already.

Yes. You are right.

baldzhang · 10-29-2023, 09:36 AM

Quote:

Originally Posted by glennmcc

Oh I see.... you're running LiveSlak in VB.

Perhaps the problem is with running it in virtualbox ?

no, it's not

if run with "live" account in the above steps, everything is good.

and firstly, i was met this in a vnc server and spent a whole to found out and re-produce, because alien's livecd is good
finally found the shortest way to re-produce and then ...

and i post vnc log following.

glennmcc · 10-29-2023, 12:30 PM

Quote:

Originally Posted by baldzhang

no, it's not

if run with "live" account in the above steps, everything is good.

and firstly, i was met this in a vnc server and spent a whole to found out and re-produce, because alien's livecd is good
finally found the shortest way to re-produce and then ...

and i post vnc log following.

Question: What OS is the computer actually booted into in-which you are then booting the LiveSlak ISO from within virtalbox ?

glennmcc · 10-29-2023, 12:48 PM

Quote:

Originally Posted by ZhaoLin1457

How can you describe the attitude of some people who consider it a burden to learn to use /etc/mkinitrd.conf.sample ? Technologically challenged?

No, not "Technologically challenged"... I'm just lazy

But, be that as it may...

I agree completely with Patrick's point-of-view and would be perfectly fine
with the total elimination of the huge kernel.

If he decided to go to just the 'standard' generic kernel requiring an initrd, that would be fine by me.

Heck, during an install from DVD, if the generic kernel is installed
the setup system automatically generates that intitrd.

So, since it can be done automatically during initial install...
it shouldn't be too darned difficult to do it manually each time the kernel gets upgraded.

Patrick has already said that v15.1 will no-longer have lilo but rather only GRUB.

So, those of us who have only ever used lilo will either need to continue using lilo from 15.0 or learn to use GRUB instead.

reddog83 · 10-29-2023, 12:59 PM

xdg-desktop-portal 1.18.1

Since Slackware does not install bubblewrap or flatpack by default this patch removes the bubblewrap requirements and with @0XBF https://www.linuxquestions.org/quest...ml#post6461102 modified Slackbuild it allow's xdg-desktop-portal to install.

Quote:

diff --git a/meson.build b/meson.build
index 1b0c5ecd..26078d35 100644
--- a/meson.build
+++ b/meson.build
@@ -112,19 +112,7 @@ libportal_dep = dependency('libportal',
pipewire_dep = dependency('libpipewire-0.3', version: '>= 0.2.90')
libsystemd_dep = dependency('libsystemd', required: get_option('systemd'))

-
-use_bwrap = get_option('sandboxed-image-validation')
-bwrap = find_program('bwrap', required: use_bwrap)
-
-if not use_bwrap
- warning('''
- Sandboxed image validation with Bubblewrap is DISABLED.
- If your system can run Bubblewrap, it's **hightly** recommended that you enable this
- option. Bitmap validation and processing is a common attack vector.
- By proceeding with sandboxed image validation disabled, you acknowledge that you
- are lowering your system's security, and are subject to known or unknown exploits.
- ''')
-endif
+bwrap = find_program('bwrap', required: false)

have_libportal = libportal_dep.found()
if have_libportal
@@ -201,7 +189,6 @@ summary({
'Enable python test suite': enable_pytest,
'Build man pages': rst2man.found(),
'Build flatpak interfaces': flatpak_dep.found(),
- 'Sandboxed image validation': use_bwrap,
},
section: 'Optional builds',
bool_yn: true,

diff --git a/meson_options.txt b/meson_options.txt
index 41b2eefb..2545a3fa 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -50,7 +50,3 @@ option('man-pages',
type: 'feature',
value: 'auto',
description: 'Build man pages (requires rst2man)')
-option('sandboxed-image-validation',
- type: 'boolean',
- value: true,
- description: 'Use Bubblewrap to sandbox image validation. Disabling this option may lead to security vulnerabilities.')

baldzhang · 10-29-2023, 01:10 PM

Quote:

Originally Posted by glennmcc

Question: What OS is the computer actually booted into in-which you are then booting the LiveSlak ISO from within virtalbox ?

1) this was firstly occurred on slarm64-current at a arm sbc days ago

2) tested in virtualbox(7.0.12) on 2 host
A) dell precision workstation, win10 pro
B) dell xps, win10 pro

3) with the same vm config and same kernel, -15.0 is ok, -current has problem

4) it's the same in vnc and X-window in vb gui

5) in 2) was tested with alien's livecd 2023-10-27, and re-tested 2023-10-29 this morning, it's same

6) finally found same bug in arch bs, and in xfconf git issues(it has been fixed and closed already)

so, I believe it's a software bug, nothing related to hardware and testing environments.

any more info you want to know, just ask me.