Yes, you are missing something, but that's because my answer was missing something :-)
If there's not a desktop file for blueman in your $HOME/.config/autostart/ then that means the default systemwide one is being used; you'll need to copy that one into your $HOME/.config/autostart/ and then edit it to add the Hidden=true part. I knew what I meant when I was typing it, but that's of little importance to a reader... ;-)

Seems fine here.

The package is fine in the "real thing". Perhaps you should take it up with the Porteus devs.

I had a look at the gif. This package is installed in Porteus using their getpkg (not installpkg). Probably in this case getpkg didn't work as it should have. Please only bring in this thread issues about Slackware-current, not derivatives.

As the others have said, it seems to work properly in Slackware.

Time to take it up with porteus or switch to Slackware.

please ship nano in the installer
 

It's small, easier to get acquainted to than vi or such for most people and just needs the shared library libmagic.so as additional dependency (I didn't check in current's installer, at least that's the case for 14.2).

You might be interested in this :) (also the program for it is on SBo).

And libmagic.so needs /etc/magic which contains a lot of files.

No. It's /etc/file/magic not /etc/magic and if you (re)move this directory nano will still work, without syntax highlighting.

Maybe busybox could be convinced to add a nano applet.

Maybe. But until they do it's no big deal to ship the binary IMO. I do that in the Slint installer since a long time, with no issue so far.

I'm a little late to the PHP 7.4 party, but I upgraded to it today on -current and noticed that php.ini removes the "extension=gd" line, despite the fact that PHP is (thankfully) compiled with GD support. Without it calls to GD functions fail. Adding it back in, a simple test like the following runs fine.

Additionally, I noticed the same with "extension=zip" (still compiled into php, but removed in latest php.ini). Just added the line back in and zip functions/support works fine.

Unless I'm missing something blatantly obvious, could I request the two lines be re-added to php.ini in -current.

Pat, please consider a policy that patches never overwrite /etc files, including /etc/rc.d scripts. The policy should include third party repos such SBo.

Not an exhaustive list but the following rc.d scripts are overwritten when patched:

rc.acpid
rc.alsa
rc.httpd
rc.messagebus
rc.ntpd
rc.sshd
rc.sysstat
rc.udev

Overwriting certain rc.d scripts might seem reasonable, but a fair counter offer is all /etc files should be left untouched to be reviewed by the user/admin.

Thanks!

actually, just for the sake of clarity:

- rc.ntpd and rc.httpd are not overwritten and the *.new file is left for evaluation

- rc.messagebus has this message in the doinst.sh script
- in most other cases there's a message in the doinst.sh
- for acpid, alsa-utils and openssh is overwritten silently

check 0.14.0

https://github.com/libcheck/check/releases/tag/0.14.0

The majority of your list actually isn't overwritten. I think there's a reasonable balance currently, but feel free to make a case for individual files. Or you could always use chattr(1) to make some files immutable.

I lazily created the list from the following:

I ran that one-liner on the original source tree and not the patches tree. I did not individually inspect each doinst.sh. As ponce noted, some of the doinst.sh scripts contain comments explaining why the script is overwritten.

While there is the mantra of "read the change log," perhaps when the rc.d script is overwritten rather than install a *.new file, the original file is preserved with an *.old file. Users/admins can compare changes.

I'd be inclined to say that if you can make a reasonable case as to *why* one of the currently-overwritten init scripts would *need* to be edited by the sysadmin, i.e. the edit could not be better accomplished by a change elsewhere, then that could be convincing.

As it stands, the "just in case" thing has bitten us in the ass at least once or twice (this is at least why rc.udev is overwritten).

EDIT for additions: I seem to recall the same for rc.messagebus, and for rc.sshd, there was a "lock you out of the system" bug in it many years ago that necessitated overwriting the old one. That one in particular is a good example of "pretty much anything you think might require an rc.sshd edit is instead configurable in /etc/ssh/*"

Yes, I vaguely remember such moments.

That still leaves open the idea of creating *old files when there is an upstream decision to explicitly overwrite the files. Not arguing or frothing, just offering an idea. :)

zerofree
 

There's a program called zerofree that's very handy when distributing virtual machines. It zeroes out unused disk blocks which can usually then be compressed by a tool provided with your virtualisation software.

The most convenient way to use it is from a bootable DVD where you don't have the fs mounted, unless you want to deal with the caveats of a read-only fs. For this reason I'd love to see it make its way into the Slackware initrd, or perhaps as a bare executable in the /extra directory (this latter being what I now do with all my generated -current ISO images). It's not very large:

thanks for your consideration,
Biff.

I don't know if you are aware, but zerofree is available at SBo.

ninja-1.10.0 released
https://github.com/ninja-build/ninja...v1.10.0.tar.gz

sqlite-3.31.1
https://www.sqlite.org/2020/sqlite-a...on-3310100.zip

qpdf-9.1.1
https://github.com/qpdf/qpdf/archive...f-9.1.1.tar.gz

cups-filters-1.27.0
http://openprinting.org/download/cup...-1.27.0.tar.xz

Looks like the bump of gnome-doc-utils in linuxdoc-utils has a broken xml2po. Most everything has switched to python3, but it still compiles the xml2po module with python2. I found it is due to the ./configure for gnome-doc-utils uses the default system python (which is obviously python2 on Slackware), but that can be overridden by passing PYTHON=python3 to the ./configure in the gnome-doc-utils section of the linuxdocs-utils.build script and this will produce a python3 xml2po module.

See this post for where the issue was reported.

Maybe , as some people request , do python3 the default python , python2 goes deprecated fast , i see projects removing python2 support, or no build tools if no python3 the python system...but this need some big work and test under slackbuild scripts.

I think Pat's plan is to keep python pointing to python2 until python2 is removed. python3 doesn't create a symlink like python2 did, so once python2 is sent to pasture/ or removed completely, /usr/bin/python will no longer exist.

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

like archlinux do ..we can

and later, python2 ..as only python2 .... like python3 does now.

In python2, the symlinks are automatically created, in python3, they are not. Pat tries to keep things vanilla, so changing what upstream intends for something like this seems contrary to what Slackware aims to do. There's no technical issue that requires a /usr/bin/python symlink, but it does simplify (and complicate) some situations. If everyone just specifically referenced the python version they want to use in their code, this problem would never exist.

Plus if the symlink for python3 is made, it could cause issues with any legacy software that actually requires python2 and doesn't work with python3.

And then in 10 years when python3 is EOL and python4 is out, we'd have to go through the same process... ;)

Thanks for the report and patch.

Sorry for the late reply, yes I am, however it needs to be on a (not necessarily the Slackware) bootable DVD, or accessible from there so I can easily run it with my rootfs unmounted.

So I have been:

1) Compiling zerofree from slackbuilds (as in your link)
2) Dumping my install ISO contents
3) Copying zerofree into the slackware /extra directory
4) Re-building my Slackware install DVD ISO.

Then I just boot the Slackware DVD and execute zerofree from extra.

Latterly I've been putting it directly in the initrd. I've written some (fairly crude) code to 'install' my packages into the uncompressed initrd (less manual pages, header files etc...) so I don't have to do it manually:
https://github.com/bifferos/vagaslac...lpkg_initrd.py
Because that wasn't the only thing I wanted to add.

May I suggest to split cache generation parts of rc.M into separate rc files?

What I am referring are:
For my case, I frequently restart my machine, and it does not need to re-run them every time. If those commands are in separate rc files, I could simply disable the executable attribute and run it if necessary.

I discovered performance issues on my office system.

While Slackware often has a server reputation and focus more than a desktop, and servers are not rebooted as often as desktops, I second the idea of moving those tasks to a different rc.d script. A simple chmod solves the problem for both types of users.

Here's one I made earlier.
I re-wrote the icon-cache stuff to be more efficient.

Been running this for a number of years now ;)

Suggestion for the find part:

Sometimes I use find -exec other times I reach for xargs out of habbit. ;)

Actually, now you mention it, I don't know whether the gtk-update-icon-cache command can take more than one path at a time, so '\;' might be safer than '+' and my xargs should probably use a "-n 1".

There is that ionice stuff that can go there too along these lines.

Since it usually does not need be done the instance the user logs on, but usually has some 40-50 seconds lee way.

This helps like bring the login prompt sooner up - so like 15 seconds off the 45 second startup - where applicable (spinning storage media).

HTH

Glibc 2.31
Release notes and download links: https://lists.gnu.org/archive/html/i.../msg00001.html

Binutils 2.34
Release notes and links: https://lists.gnu.org/archive/html/i.../msg00000.html

This changes the libbfd API such that oprofile and perf (and probably others) no longer compile.

Incompatible time handling means we'll need to be cautious with this one as well. A full make world will be needed to see how extensive the fallout is.

This being the case, it probably suggests that they should be some kind of cron job instead of just during boots. They don't seem boot-related. I'm still not convinced about cleaning out /tmp on boot (I was most disconcerted the first time I came across this (not on Slackware)). If the aim is to run them when the software is not running then they should be tied into the lifecycle of the software. The aim of the boot process is to get the machine into a user-usable state and not perform maintenance tasks (exceptions apply, of course) in my opinion.

s-nail-14.9.17
Announcement

I adressed to upstream, that "make test" did fail on the last release. This is fixed and "make test" may be added back to the buildscript.

Provided cron does perform tasks, missed while being offline, immediately, there will be little if any differences out of the box. Also i happen to agree strongly with the proposed purpose of boot:

It is an unavoidable evil, let's get over it as soon as practical.

If it possible I have request to build xsane package with GTK3 and skip GTK2.

Thanks.

xsane as gimp plugin
 

Since you just mentioned xsane ;) My previous post may have gotten lost between all the others: Applying this little patch to xsane.SlackBuild will add xsane (which is already compiled with GIMP support) as plugin to GIMP. With this you get a new menu entry (File → Create → X-Sane: Device dialog…) to scan directly from GIMP and don't have to create a temporary file in xsane first.

Of course, the link can easily be created manually without being part of the package, but it would certainly be very helpful to set it by default. :)

-----------

And inotify-tools got just a few hours after 3.20.2.1 a second bugfix update to 3.20.2.2

Excellent idea!
:hattip:
As I think about it, and I could be wrong (it wouldn't be the first time :) ), but didn't that use to be the default?
It is only recently I noticed it was no longer possible to scan directly from within The GIMP.

I only know it working in Windows-GIMP “out of the box”. But as both Gentoo and Arch "manually" add the symlink in their package build scripts, that's probably the “right” way and not a missing option in Slackwares ./configure or make install of xsane or GIMP.

announcements/postfix-3.4.9
postfix-3.4.9.tar.gz

/etc/rc.d/rc.nfsd does not check for /etc/exports.d
 

The /etc/rc.d/rc.nfsd script exits without checking /etc/exports.d and provides no helpful messages why the script terminated.

This affects 14.2 too.

From exportfs.c:

Looks like the exportfs command will check both locations before warning. Possible patch:

Double TigerVNC menu items
 

The TigerVNC 1.10 package in /extra installs two *.desktop files:

/usr/share/applications/tigervnc.desktop
/usr/share/applications/vncviewer.desktop

The result is two TigerVNC Viewer items in the Internet menu.

The sources come with a vnciewer.desktop file. The tigervnc.desktop file created in the SlackBuild no longer is necessary. Proposed patch: