I don't. It's supposed to be 92% complete, and who knows how long it will take to reach 100%. Pat will do what he wants of course, but I don't expect Slackware 15.0 to ship a huge toolkit like that not even yet released, with very few software already using it.

Didier, I also agree on that from your point of view, gtk4 is something has to be released yet, but it would be good to have it in 15.0 as we can start working on porting things over to it. Maybe in extra, but have underneath stuff ready to get it done. So glib, pango and friends should be at the level where gtk 4 could be compilled out of the box. Thats of course just mine opinion.

that's not what i meant.

At this point, many GNOME-related projects are still using GTK+3 and they are not going to switch to GTK+4 and abandon GTK+3 immediately, especially for distributions that has long support.

i agree also, I just wanted to say that gtk4, could coexist with the other gtk+ version,
but for pango the version for gnome-3.36 is '1.44' not '1.42'. ;)

GNOME usually uses always the latest stable version of their modules. This doesnt mean it can not work with some previous releases, usually not, but in some cases it does. Anyway the request from my side for GTK+4 was also to have a ready testbed for working with GTK+4
on future softwares, like we have other developer tools already in Slackware. Anyway I dont see a big problem in shipping it as extra
if possible as it will not require anything new than pango iirc. So I also hope that once XFCE is out Pat also updates the other older
stuff we still stick with (I'm reffering to upower, udisks, pango, etc...).

What gmgf requested I also understood it as an addition to the gtk stuff we have right now, but I can also say that if we have all the
other gtk+4 deps ready I am ok with it too, as its a simple matter of building it.

And lastly it is obvious for who follows gtk development and related projects that gtk+4 is not ready, but the intention of having it is to permit those people to help with development of gtk itself and port other software to it for the future purposes.

dconf-editor-3.36.2
https://download.gnome.org/sources/d...-3.36.2.tar.xz

PS: Also from what I see we still will have GNOME 3.38 release on gtk+3 in September. https://wiki.gnome.org/ThreePointThirtyseven

python-distro-1.5.0:

https://github.com/nir0s/distro/releases

vte-0.60.2
https://download.gnome.org/sources/v...-0.60.2.tar.xz

json-c 0.14 is out:

https://github.com/json-c/json-c/wiki
https://s3.amazonaws.com/json-c_rele...ses/index.html

pycups-2.0.1:

https://github.com/OpenPrinting/pycups/releases

(python setup.py install --root=$PKG || exit 1) in the SlackBuild not work here, python3 no problem.

gtk+-3.24.20
https://download.gnome.org/sources/g...3.24.20.tar.xz

CUPS v2.3.3

The change log and download links can be found at,
https://github.com/apple/cups/releases

Samba 4.12.2
https://www.samba.org/samba/history/samba-4.12.2.html

curl-7.70.0 is released.

https://curl.haxx.se/download/curl-7.70.0.tar.xz
https://curl.haxx.se/download/curl-7.70.0.tar.xz.asc

CMake 3.17.2
https://blog.kitware.com/cmake-3-17-...-for-download/
https://github.com/Kitware/CMake/rel...-3.17.2.tar.gz

gsettings-desktop-schemas-3.36.1
https://download.gnome.org/sources/g...-3.36.1.tar.xz

Mesa 20.0.6

Release Notes, 2020-04-29,

https://www.mesa3d.org/relnotes/20.0.6.html

I just stumbled upon the fact that, although /var/run is a bind mount of /run, the content of /var/run/user/$UID is only visible below /var/run but when looking in /run/user/$UID it is empty! This is because /var/run/user/$UID is automatically created as an additional tmpfs mount and mounts are private by default.

As far as I remember there were reasons for /var/run not simply being a symlink to /run but I think it would nevertheless be reasonable that its contents are identical, or not? Marking /run as shared seems to be a possible way to solve this confusion:

… or would this have other unwanted side-effects?

(Note: shared is intentionally applied in a separate line so that it is also applied if /run has already been mounted by initrd!)

I see x264 is not included in ffmpeg (and also in mencoder), why?

Patent issues in some countries.

I'm experimenting with EFI (in particular trying to run 32-bit Slackware on a 64-bit EFI machine which is unlikely to work). I noticed that the 32-bit usbboot.img contains EFI/BOOT/BOOTX64.EFI which is a 32-bit EFI executable. Should this be named BOOTIA32.EFI instead?

I don't own any 32-bit EFI machines, so take that with a grain of salt.

netconfig prompts for a domain name, and it doesn't accept an empty string. Can it be modified to allow leaving this blank, or is there a good reason why you should always enter a domain name? I usually enter a dummy name, then go remove it from /etc/hosts, /etc/HOSTNAME, and /etc/resolv.conf.

No. The UEFI specification clearly states that for a machine with architecture x64 the name should be BOOTX64.EFI, with a PE executable machine type of 0x8664 in the machine field of the COFF file header as defined in the Microsoft Portable Executable and CommonObjectFileFormat Specification, Revision 6.0. However the media may support multiple architectures by simply having a \EFI\BOOT\BOOT{machine type short-name}.EFI file of each possible machine type in the same directory.

What is the need for that, i.e. what is the usefulness of removing the domain name from these files?

Boost 1.73.0
https://www.boost.org/users/history/version_1_73_0.html

I also remove the domain name. Not because there's any need to, but, conversely, what is the use of keeping a dummy domain name?

As far as I'm concerned, there's no real need for the netconfig script to accept an empty domain name. I can handle it myself just as well. I just put together a script to do it for me.

Hmmm - I want to raise a warning flag on this one. I am not seeing a driving reason in the release notes for a new version of a package that has a history of breaking a lot of third party packages.
Some will have time on their hands and be happy to pay the penalty of required rebuilds, but others are relying on functional systems to complete required work tasks.
In the "new normal", I would request that a compatibility package for the existing boost version (as Alien Bob has provided in the past to maintain the libreoffice build) accompany any shift to the newer boost.

You can download a restricted FFmpeg package with AAC encoding and x264 support here:
https://bear.alienbase.nl/mirrors/pe...builds/ffmpeg/
I suggest that you build your own restricted FFmpeg package to sync it with the system version (4.2.2).

Right, but this is for the 32-bit EFI app on the 32-bit installer USB stick.

Because not everyone owns a domain name, and inserting a dummy one that's increasingly likely to conflict with a real one is asking for problems.

I see there's a "home.arpa" domain that might be intended for this purpose, but I need to do more reading. https://tools.ietf.org/html/rfc8375

What matters with regard to UEFI is the machine's architecture, in other words the hardware. Using a 32bit UEFI image on a 64bit hardware is not supposed to work. Whether the installer be 32bit or 64bit doesn't matter with regard to UEFI as when the installer is loaded it has taken over the hardware, so the firmware is out of sight of the UEFI image.

Do you have a real life example of such a conflict? I don't.

On the laptop I am using HOSTNAME is set to darkstar.slint.fr, slint.fr is a domain that I own. I use it for a mail server and web server on a VPS in Stuttgart, which I access through ssh, the domain is bound to the VPS with a DKIM record and this leads to zero conflict.

You can always use localdomain. It's what I use, even though I'm hosting a website with it's own domain on my computer.

I think that the only way (or at least the only *easy* way) to run 32-bit on a machine with UEFI is to put the machine in legacy boot mode.

Hello.

I always used ‘d’ and ‘v’ commands. Recently I upgraded to latest current version pre15.0 kernel 5.4.35 (from 14.2).

I saw you new /etc/profile.d/coreutils-dircolors.sh have not that commands yet.

coreutils-8.25-i586-2 still has it.

Please, recover this options inside /etc/profile.d/coreutils-dircolors.?sh files at coreutils package.

Attach diff between both. This is the unique difference.

¡Thanks!

root@darkstar:/mnt# diff /etc/profile.d/coreutils-dircolors.sh ~/temp/etc/profile.d/coreutils-dircolors.sh > /mnt/diff.txt

26c26,30
< # Set up aliases to use color ls by default:
---
> # Set up aliases to use color ls by default. A few additional
> # aliases like 'dir', 'vdir', etc, are some ancient artifacts
> # from 1992 or so... possibly they should be disabled, but maybe
> # someone out there is actually using them? :-)
> # Assume shell aliases are supported.
31a36,37
> alias dir='/bin/ls ${=LS_OPTIONS} --format=vertical'
> alias vdir='/bin/ls ${=LS_OPTIONS} --format=long'
33a40,41
> alias dir='/bin/ls $LS_OPTIONS --format=vertical'
> alias vdir='/bin/ls $LS_OPTIONS --format=long'
34a43,44
> alias d=dir
> alias v=vdir

I'm glad they've gone. Aliases really don't belong in /etc/profile anyway as they're not made available to non-login shells.

Have you considered adding them to your ~/.bashrc instead?

Yeah, I did it.

25 years ago my teacher tell us that d and v aliases to be Slackware examples to be easier use. I’m sad because this improvement general dissapear.

After slackpkg updates the kernel, would a (Y/n) prompt to update the corresponding files for the bootloader be nice addition for 15.0?

I use GRUB and wrote a post-function for slackpkg:
Then added an entry in lookkernel() to run it when GRUB is detected.

Wasn't already explained long time ago that is not the slackpkg's business to update the bootloader?

Anyway, even on Ubuntu or Fedora the bootloader setup is updated by the post-install scripts of particular (kernel) packages, not directly by the package manager and they use practically just one bootloader: GRUB. Slackware uses a legion.

How could help that the LILO, eLILO or SYSLINUX users, considering that they usually have GRUB installed on their systems?

Sorry, I was unaware of the previous discussion and have found it through the search. Relatively am a newbie to Slackware and especially the forum. I understand the reasons for leaving it out of slackpkg now.

The idea of automatic/prompting bootloader updates is something appealing to me, although I don't know how to best approach it except for what I've written already.

And the differences between legacy and EFI booting systems?

I believe that in fact you are only a victim of a subtle logical flaw which some believes to exists in Slackware: the kernel packages should never be upgraded automatically, like happens today, because they are of huge importance for a sane boot.

And I tend to agree with them, because I do not seen the major distributions (like Ubuntu or Fedora) doing that. They just install kernels.

In the past, someone proposed to apply an "incoming" treatment to kernels and their modules, just like was done with GLIBC libraries. A proof of concept for "doinst.sh" would be:
Basically, this will put out of the scope of pkgtools the file "/boot/vmlinuz-generic-5.4.36" and its associated config and System.map, then they never be removed automatically, on a kernel package upgrade or removal. Kind like do also Fedora.

The end result will be that if someone setup this particular kernel for the system boot, this particular kernel will be always available and will boot. Until this particular someone intervene and change his boot configuration. And this is of crucial importance for a proper boot flow.

Contrary to you, I honestly believe that Slackware already do way too much automation about the kernel packages, with possible unexpected results as unbootable systems for those who miss to update their bootloaders - and it should leave everything here to user's manual intervention.

Why not make a kernel-upgrade script which would take all the needed precautions ?

This would permit to leave out the kernel upgrades until the script is called. After the script was called it would check what kind of boot loader is installed and would take appropriate actions. This script could be called from within slackpkg or other tool if someone would need it done automatically. Otherwise the by hand solution would be still the option.

Why not call it upgrade-kernel instead?

If you refereeing at automated kernels upgrade - thanks, but no!

Looks like the people are unable to figure out that the automated package tools should leave alone the kernel files, because they are critical for a successful later boot.

Even myself I was bitten in the past by this sudden disappearance of the critical kernel files after some packages upgrades, what's so complicated to figure out?

Yes, could be done and would be nice to be done like this, but the first condition for a design like this is that the kernel files to have an "incoming" treatment, then to be forever leaved alone by the pkgtools.

Sure, no matter the name, i didn`t know it existed already one :)