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

marav · 10-28-2023, 03:52 PM

Quote:

Originally Posted by franzen

While this is nice to know, i hope the 32bit tree will not be a keeper for 15.1 and beyond(in the hope it saves some time for Pat).

It will
because of :
http://ftp.slackware.com/pub/slackwa...kware-current/

glennmcc · 10-28-2023, 04:23 PM

Quote:

Originally Posted by franzen

While this is nice to know, i hope the 32bit tree will not be a keeper for 15.1 and beyond(in the hope it saves some time for Pat).

When I asked him a couple of months ago if his plan was to drop 32bit in v15.1,
his reply was that if that were his plan, he'd not be wasting his time with 32bit upgrades in current.

https://www.linuxquestions.org/quest...ml#post6448728

Just in case anyone might be interested in this info...

Code:

root@glennmcc-Dell:~# uname -a
Linux glennmcc-Dell.net 6.1.60 #1 PREEMPT_DYNAMIC Wed Oct 25 19:53:55 CDT 2023 i686 Pentium II (Klamath) GenuineIntel GNU/Linux

root@glennmcc-Dell:~# free
               total        used        free      shared  buff/cache   available
Mem:          493264       31820      214388         844      247056      447300
Swap:         976496           0      976496

root@glennmcc-Dell:~# ls -l /boot
total 14608
lrwxrwxrwx 1 root root      38 Oct 28 16:12 README.initrd -> /usr/doc/mkinitrd-1.4.11/README.initrd
lrwxrwxrwx 1 root root      25 Oct 28 12:42 System.map -> System.map-generic-6.1.60
-rw-r--r-- 1 root root 4232526 Oct 25 20:54 System.map-generic-6.1.60
-rw-r--r-- 1 root root     512 Oct 10 15:42 boot.0800
-rw-r--r-- 1 root root     136 Oct  9 04:08 boot_message.txt
lrwxrwxrwx 1 root root      21 Oct 28 12:42 config -> config-generic-6.1.60
-rw-r--r-- 1 root root  248645 Oct 25 20:27 config-generic-6.1.60
-rwxr-xr-x 1 root root  217896 Aug  5  2022 elilo-ia32.efi*
-rwxr-xr-x 1 root root  239734 Aug  5  2022 elilo-x86_64.efi*
-rw-r--r-- 1 root root   22578 Feb 13  2021 inside.bmp
-rw-r--r-- 1 root root     432 Feb 13  2021 inside.dat
-rw------- 1 root root  184320 Oct 28 17:29 map
-rw-r--r-- 1 root root    6878 Feb 13  2021 onlyblue.bmp
-rw-r--r-- 1 root root     424 Feb 13  2021 onlyblue.dat
-rw-r--r-- 1 root root   14174 Feb 14  2010 slack.bmp
-rw-r--r-- 1 root root   33192 Feb 13  2021 tuxlogo.bmp
-rw-r--r-- 1 root root     423 Feb 13  2021 tuxlogo.dat
lrwxrwxrwx 1 root root      22 Oct 28 12:42 vmlinuz -> vmlinuz-generic-6.1.60
lrwxrwxrwx 1 root root      22 Oct 28 12:42 vmlinuz-generic -> vmlinuz-generic-6.1.60
-rw-r--r-- 1 root root 9718528 Oct 25 20:54 vmlinuz-generic-6.1.60

SCerovec · 10-28-2023, 04:30 PM

Quote:

Originally Posted by franzen

While this is nice to know, i hope the 32bit tree will not be a keeper for 15.1 and beyond(in the hope it saves some time for Pat).

Since we're speaking of culling and time saving, just a reminder almost complete KDE is available as flatpak as well as most 32bit applications, wine included. If we could free the dev team of the KDE burden (delegate it off to a flatpak add on method) and unload the multilib to it too (i have read people play on pure 64bit Slackware via flatpak on steam(!))?

Just saying, maybe it is worth investigating?

I'd rather have Slackware pruned of most if not all desktops and WMs come in same or faster pace, being ready when it's ready, than see the last Slackware ship KDE and then stop existing just because each release needs ever more work.

Also, is Gnome having a comeback to sanity or not?

glennmcc · 10-28-2023, 05:14 PM

Further to culling and time saving,

DOCs, FAQs, HOW-TOs & man pages are only ever read by those who don't actually need to read them
and are _never_ read by those who do actually need to read them.

Heck, /usr/doc + /usr/man == 52,000 files that no-one who needs to ever reads.

So, free-up a bunch of disk space and reduce the download bandwidth by eliminating all of them from the distro.

reddog83 · 10-28-2023, 05:16 PM

Quote:

Originally Posted by SCerovec

Since we're speaking of culling and time saving, just a reminder almost complete KDE is available as flatpak as well as most 32bit applications, wine included. If we could free the dev team of the KDE burden (delegate it off to a flatpak add on method) and unload the multilib to it too (i have read people play on pure 64bit Slackware via flatpak on steam(!))?

Just saying, maybe it is worth investigating?

I'd rather have Slackware pruned of most if not all desktops and WMs come in same or faster pace, being ready when it's ready, than see the last Slackware ship KDE and then stop existing just because each release needs ever more work.

Also, is Gnome having a comeback to sanity or not?

What would you mean by Gnome making a comeback…

marav · 10-28-2023, 05:58 PM

Quote:

Originally Posted by glennmcc

Further to culling and time saving,

DOCs, FAQs, HOW-TOs & man pages are only ever read by those who don't actually need to read them
and are _never_ read by those who do actually need to read them.

Heck, /usr/doc + /usr/man == 52,000 files that no-one who needs to ever reads.

So, free-up a bunch of disk space and reduce the download bandwidth by eliminating all of them from the distro.

/usr/doc/ mainly contains license files, that are mandatory

also changelog and release notes, combined with /usr/man, these are particularly useful when investigating FTBFS issues

side note:
@redddog83 your changelog is very nice ;-)
https://reddoglinux.ddns.net/linux/gnome/
PS: the one on your home page is stuck at 2023/03/28

reddog83 · 10-28-2023, 06:28 PM

Quote:

Originally Posted by marav

/usr/doc/ mainly contains license files, that are mandatory

also changelog and release notes, combined with /usr/man, these are particularly useful when investigating FTBFS issues

side note:
@redddog83 your changelog is very nice ;-)
https://reddoglinux.ddns.net/linux/gnome/
PS: the one on your home page is stuck at 2023/03/28

Thank you @marav u r the inspiration. And about the homepage ya ive been busy just havent gotten around to updating it.

baldzhang · 10-28-2023, 08:31 PM

updating from 4.18.1 to 4.18.2 causing xfwm4 to segfault
https://gitlab.xfce.org/xfce/xfconf/-/issues/35

looks like a new release will not happen soon, so is it possible to add this patch ?

it is good in alien's livecd when login from sddm, but occurs when startxfce4 from run level 3.

glennmcc · 10-28-2023, 09:12 PM

Quote:

Originally Posted by baldzhang

updating from 4.18.1 to 4.18.2 causing xfwm4 to segfault
https://gitlab.xfce.org/xfce/xfconf/-/issues/35

looks like a new release will not happen soon, so is it possible to add this patch ?

it is good in alien's livecd when login from sddm, but occurs when startxfce4 from run level 3.

<noise clipped>

The problem is supposedly in xfconf v4.18.2

Well... it is here on my system and has no such problem.

I always boot to run level 3

xfce is chosen as DE via xwmconfig and xfce is started from the run level 3 cli with simply 'startx'

baldzhang · 10-28-2023, 09:29 PM

emmm....

this is a bug in xfconf-4.18.2, then xfwm4 segfault...

---

try login root then startxfce4 ...

glennmcc · 10-28-2023, 10:00 PM

Quote:

Originally Posted by baldzhang

emmm....

this is a bug in xfconf-4.18.2, then xfwm4 segfault...

---

try login root then startxfce4 ...

Also no problem at-all

startxfce4 fired-up xfwm4 without any problems and I'm here in it right now.

root@glennmcc-i7:~# slackpkg search xfconf

Looking for xfconf in package list. Please wait... DONE

The list below shows all packages with name matching "xfconf".

[ installed ] - xfconf-4.18.2-x86_64-1

You can search specific files using "slackpkg file-search file".

baldzhang · 10-28-2023, 11:58 PM

http://slackware.uk/liveslak/slackwa...ve-current.iso
Date: 2023-10-29

running in virtualbox, after boot, CTRL+ALT+F2 enter tty2 (pic #1)

Code:

xinit /usr/bin/xterm -- :1

run xfwm4 in xterm (pic #2)
first time running there will be lots of error message and segfault
after that only segfault printed
dmesg has info also (pic #3)

other bug report here: https://bugs.archlinux.org/task/79989

or just run startxfce4 -- :1 (pic #4)

glennmcc · 10-29-2023, 01:16 AM

Quote:

Originally Posted by baldzhang

http://slackware.uk/liveslak/slackwa...ve-current.iso
Date: 2023-10-29

running in virtualbox, after boot, CTRL+ALT+F2 enter tty2 (pic #1)

Code:

xinit /usr/bin/xterm -- :1

run xfwm4 in xterm (pic #2)
first time running there will be lots of error message and segfault
after that only segfault printed
dmesg has info also (pic #3)

other bug report here: https://bugs.archlinux.org/task/79989

or just run startxfce4 -- :1 (pic #4)

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

Perhaps the problem is with running it in virtualbox ?

Have you done an actual install of the full SlackWare64-current onto HDD and booted that ?

https://slackware.nl/slackware/slackware64-current-iso/ 2023-10-29 01:24 3.7G

http://glennmcc.dynu.com/startxfce4_..._fine_here.mp4

http://glennmcc.dynu.com/Youre_doing...r_Mom_1983.mp4

franzen · 10-29-2023, 02:58 AM

Quote:

Originally Posted by marav

It will
because of :
http://ftp.slackware.com/pub/slackwa...kware-current/

Then i hope for the next dev cycle to be -current64 only.

Quote:

l/vid.stab-1.1.1-x86_64-1.txz: Upgraded.

Thanks.

Petri Kaukasoina · 10-29-2023, 04:42 AM

Quote:

Originally Posted by volkerdi

I never changed my recommendation to use generic + initrd and don't plan to change any documentation regarding that. I just noted that it'll probably work better for that than the huge kernel did since the modules match the kernel better, and several footbullets have been unloaded.

Or another solution to the need of two sets of modules:

Don't provide huge kernels at all. Go back to slim generic kernels. You could probably even leave something out of them, something you have added to generic only to circumvent module problems with huge.

Use the generic kernel in the install image. udevd would load the root file system driver instead of them all built-in. The initrd image would be larger because of all the modules, but the kernel image would be smaller.

Initrd would then be mandatory on the installed system (except with custom kernels). And there would not be the larger memory usage of huger kernels.

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."