Fair enough. Perhaps some nuance is lost in translation. The difference is not very subtle though.

If Patrick also had to support SBo projects he would not have time to sleep! As mentioned in their FAQ, SBo builds are supported by independent volunteers.
The key word in that sentence is "additional." As in, not part of the distribution, but able to be added.

3 members found this post helpful.

Maybe it would be nice if slackpkg+ was available in SBo?

3 members found this post helpful.

Endorsed, supported by, approved, validated ... Blessed by the BDFL The line between is thin

2 members found this post helpful.

Not really.

One refers to approved methods of adding software, and the other refers to providing help to users having trouble. Patrick should not be expected to provide support for SBo builds... He is more than busy enough.

Bonne Annee from the far east!

2 members found this post helpful.

Bonne Année ! 🍾 🎉

I'm with rkelsen on this one. The following phrase:
...simply provides additional information where users might find software that they may find useful, and is easily added to their Slackware system.

The distinction is important.

• "Endorsed" indicates some level of trust in the contents - either because you believe in it, or because someone paid you do say it (e.g. celebrity endorsements of products). "I am willing to have my name and reputation associated with this product."
• "Supported by" indicates the provision of some sort of resources (time, money) to assist in the development or distribution of the product.
• "Approved" indicates some level of review and indication that the product meets some sort of (personal|professional) standard.
• "Validated" implies some sort of testing process that the product has passed.

Yes, there are connections across the terms, but to me it appears that PV's level of "support" goes no further than telling people that the source of information exists. At least, as far as is expressed in the Slackware FAQ.

As for incorporating slackpkg+ into slackpkg - I don't use either, preferring to keep my 15.0 stable updated manually (as well as manually maintaining any SBo or other sources I use for software. Call be paranoid, but I like having control over what goes in my system.

...but to me, I like the old idea that you have a tool that does one job well, and create another tool for a different job. Maintaining my OS is not the same job as maintaining other software I install. If I were to start using slackpkg, I would probably want to just stick with official Slackware software - not all my additional stuff. Yes, I see that these package management tools can be told to not update parts of things - but I'd rather work with something that I add what I want rather than having it take over everything and then fight to stop it from doing things I don't want. Resolving dependencies manually for SBo packages etc is a pain, but at least I know what has been done.

...and although I'm a relatively new user here, I've been using Slackware since something like v2.0.

6 members found this post helpful.

Excellent post! I especially agree with the paragraph just above.

1 members found this post helpful.

This is not very fair to the people who work hard on Sbo (willy, ponce, dave, etc ...).
Semantics aside, what I understand from Patrick's "support" against SBo is that he validates the quality of what is offered in the same standard as Slackware.
Whatever the word you put on it

marav:

I said "At least, as far as is expressed in the Slackware FAQ."

I recognize that much more goes on in the background - but that single line from the FAQ should not be interpreted in light of things that are not included there.

1 members found this post helpful.

Frankly, I do not expect him to spend his valuable time on providing support for problems in "customers" Slackware installations either. When it happens I consider it to be a bonus and I appreciate all the work he does put in Slackware and gives it away for free downloads only hoping for some voluntary economical support.

My point of view is that Slackware consists of all packages supposed to go into a full install. Distributed with Slackware is also the /extra directory with packages. All those packages will for some time get support as security updates. All those packages might not get supported until the Slackware release gets EOL, but at least some of those packages will.

Then there are third party repositories provided by others and slackbuilds.org is the biggest and in my opinion number 1 source for third party software for Slackware. Any security upgrades for those packages will of course be the responsibility of those who provided the software.

regards Henrik

3 members found this post helpful.

That particular feature was removed from slackpkg-15.0, slackpkg+ has the option but it is disabled by default. There are too many assumptions needed to have it be automatic imho. Kernel updates are better off done separately or better yet manually (you do keep a known working backup kernel around right?).

2 members found this post helpful.

"Though a program be but three lines long, someday it will have to be maintained."
https://www.mit.edu/~xela/tao.html

People use slackpkg+ (how many is a good question), we don't know where the maintainer is, and as you can see above that his server that hosts slackpkg+ is down. I think it would be better if slackpkg+ was hosted on an official mirror. OpenSUSE provides support out of the box for third party repositories and it is the most hassle free way of getting a workable version of ffmpeg on OpenSUSE. People would have to still go find the third party mirrors, add them to slackpkg+, and configure slackpkg+ correctly. Other distributions like OpenSUSE found it worthwhile to let people add third party repositories with their update tools.

4 members found this post helpful.

This is one of more easy requests ever ... little tool , no extra deps.

clinfo

The reason is cause plasma now (NEXT 5.27 RELEASE) can provide opencl info in to the information system panel.

- The KDE Information Center is now able to show OpenCL device information, based on parsing output from clinfo.

A slackbuild exist , as i say no need extra deps , and no big size pkg.

https://slackbuilds.org/repository/1...?search=clinfo

Thanks.

More info into the KDE week changelog
https://pointieststick.com/2022/12/3...-year-goodies/

3 members found this post helpful.

Dear BDFL,

please be kind to patch the KTorrent package from Slackware 14.2 for the obnoxious nag screen regarding unknown host geolite.maxmind.com

If I remember right, there's already the patch for local IP location database, and it was used in the Slackware-current (pre Slackware 15.0) before switching to Plasma5

I know, I know, it's a quite old release, BUT seems like it and its KDE4 still haves usability in the old computers with graphics supporting OpenGL 1.2 only.

2 members found this post helpful.

FYI,

That was fixed a very long time ago by embedding
a copy of the geoIP database within ktorrent.
______________________________________________________

https://bugs.kde.org/show_bug.cgi?id=403054

Glenn McCorkle 2021-05-22 17:15:22 UTC

FYI,

Slackware "fixed" this problem over 2yrs ago via....
________________________________________________________________________________
Sun Mar 17 20:40:15 UTC 2019

kde/ktorrent-4.3.1-x86_64-4.txz: Rebuilt.
Embed a copy of the GeoIP database since the download link no longer works.
_________________________________________________________________________________

2 members found this post helpful.