But upgrading your databases is nontrivial. So maybe it's better to have postgresql upgrades decoupled from Slackware upgrades.

You talk about migration from MySQL to PostgreSQL? There is no need for, and the PostgreSQL server would work well along with MySQL.

In other hand, if you talk about the difficult to upgrade PostgreSQL databases, from when we care about offering to users some "stupid" paths of upgrading?

IF someone starts to use PostgreSQL, he should learn to use it properly, plain and simple.

So, this argument is moot, in my humble opinion.

And yes, I would love to see PostgreSQL into Slackware. It is a very nice database server. ;)

No.

If you knew anything about postgresql, you would know about pg_upgrade.

I given you my opinion also about migrating the PostgreSQL databases. ;)

Like I said, I do not consider an argument like "the difficult to upgrade the PostgreSQL databases" as good enough to limit the Slackware users choices by default.

IF an user will consider that these upgrades are too much for him, he can just use MariaDB instead, plain and simple.

Yes, this.

Having postgresql available as a very well-written SBo postgresql.SlackBuild has worked for me since Slackware 13.37 ( IIRC ).

See Postgresql Versioning Policy.

Postgresql is still actively supporting version 9.6 which is scheduled for EoL in September 2021 ( but the developers do make a 'best effort' to fix critical bugs after EoL ).

Because of the potential pain of changing our postgresql Major Version, I've created a clone of the new SBo Version 10 postgresql.SlackBuild as postgresql-9.SlackBuild

We've decided to keep running pg 9.6 until we come up with a Migration and Testing Plan for the DataBases and for a few of our Programs linked to /usr/lib{,64}/postgresql/9.?/lib/

Unless maybe Pat and the Team would stick with a postgresql Major Version for the life of a Slackware Release ...

But then again, postgresql 10 is scheduled for EoL in October 2022 which will be before the useful EoL of Slackware 15.0.

Catch 22 there ?

Anyhow ... my $0.02 ...

-- kjh

Still I fail to notice where's the tragedy from the Slackware POV, considering that the PostgreSQL developers offer at least several years of support for a Major Release...

Also, it is not supposed you guys to use stable releases in production and Slackware to stick on the software's Major Releases for lifetime of a release?

Last I checked, our BDFL still does not pushed in the Slackware 14.2 "patches" the Plasma5, for example. ;)

So, excuse me, but I cannot treat this story in other way than "yet another scary story ventilated in this forum" :D

meson-0.46.1

https://github.com/mesonbuild/meson/...-0.46.1.tar.gz

I discovered GNU Parallel these days and IMHO it would be a great addition to a distro like Slackware which probably has quite a few console users. It's like "xargs" but executes the commands in parallel, using all those cores modern CPUs have.

https://www.gnu.org/software/parallel/

it's already included in current since some weeks ;)

Oops. Thank you and sorry for the noise. That's awesome news.

Parallel - build and execute shell command lines from standard input in parallel. Uh, oh...

BUT, for a shell scripting feature (somehow similar with xargs), its location in D series is a bit strange. I imagined that its place is in AP series, eventually... ;)

It's just like anything else, minor version upgrades for security stuff is dead simple, restart the daemon. For other stuff, it requires an import/export, but it's only 3 commands...

There is no tragedy, postgres works every well and is easy to maintain. Easier in my opinion that mysql because mysql requires the user to know a little bit about the numerous different table types and has a lot of inconsistency issues, and in some cases plainly lacking real database features such as a timestamp with a time zone.

I'd WAY rather understand how to import and export every other year for a major release then hack time zone support into my app because the database won't do it.

Anyway, the SBo postgres package works fine, the only con is that it requires me to rebuild php to get the module. If postgres was in EXTRA, and the pgsql.so and pdo_pgsql.so modules were included in php (but disabled in php.ini), that would make my life WAY easier as I would just install postgres from EXTRA, uncomment two lines in php.ini and presto chango, php works. For those that don't want postgres, they don't install from EXTRA and it's just like it's always been.

My point is that a non intrusive change here makes slackware much nicer for those of us that want a real database.

IF the PostgreSQL is added to Slackware, as you pointed out, the PHP will build support for it.

BUT also the same will do Qt4 (or future Qt5) and probably other applications and libraries.

Then, I believe its place will not be in /extra, but in the main tree, maybe in N series.

And that's OK, because like you highlighted, PostgreSQL is a fine database server, with annual major releases and multi-annual maintenance and security support.

I for one, as one of those who uses PostgreSQL since Ice Age, I believe that it will be a fine addition to Slackware, and a non-invasive one.

I really hope that our BDFL will not be convinced for contrary by some who get mental scars from the usage of PostgreSQL. ;)

We need libstdc++.so.5 back in aaa_elflibs. There are legacy games that need it.

Reference:

https://www.linuxquestions.org/quest...6/#post5856210

I agree with you too, I have been using PostgreSQL since I started using Slackware many years ago.

Same here.

I think that PostgreSQL and NGINX will be nice additions to Slackware for the servers usage.

I do not know if the NGINX wasn't already requested, but it is widelly used and would be nice to have it along with Apache within Slackware.

It's written in Perl. Also, it's strange to keep fixating on which series a package belongs in, as if it's a dependency system or something.

nginx and postgresql are doing just fine on SBo. I don't see what adding them to Slackware core would bring to the table, aside from shifting the maintenance burden from people who know them well and use them regularly, to people who have a thousand other packages to look at.

As for php and qt, both of those have scripts up on SBo as well for postgresql support:
- php-pgsql
- libqsqlpsql

GNU parallel is quite a bit more advanced than xargs (but I'm sure you know that if you've gone over the tutorial ;-)

If all your script requires is a parallel xargs, check out the xargs -P option. It's already able to do simple parallelization. In fact, even the busybox version supports this.

openldap-client.SlackBuild:
You don't need PAM to run a LDAP server.



nfs-utils.SlackBuild:
http://git.linux-nfs.org/?p=steved/n...8b363f436cb1d5

You can enable nfs4 w/o gss, better than nothing.



Cheers

Perhaps I'll look at making the compression level a user-serviceable part. But I thought I should weigh in again here... the test you're running using random data doesn't really give real-world results since most compressors do a lousy job compressing random bytes. So here are three tests on my own machine using the Linux kernel source as the testfile:

As you can see, xz is still fairly slow even when the -9 is dropped, but look at the results using lbzip2 (bzip2 compression)!

The moral of the story is that if you're concerned about makepkg compression time, forget about building a .txz package - have it build .tbz instead. It will produce a larger package than xz will, but for packages intended for local use it's still a modest increase.

Fair enough.

I figured I would mention it since sendmail was removed. If we are going to force the sendmail/imapd users to migrate to postfix/docecot (or remove postfix and SBo sendmail) all in the name of it's a better mail system, then why not get a modern/feature-full database server in there while we are at it?

At least postfix supports milter, so it can mostly do what sendmail does....

schu

There's a lot of very good software out there, and Postgres is one of them but we can't include it all in the distro and I think we need to be wary of Everything-but-the-kitchensinkism when requesting things to be added to the distro.

Postgres is the sort of thing that I prefer to install to /opt independently of the distro, but that's just me.

Well, then you're talking about replacing httpd/mariadb, which puts this story in a whole different ballpark.

For the record, imapd was replaced because it's essentially dead, which can't be said about either httpd or mariadb. And sendmail is not removed, it's still sitting there in extra/. If you want it, use it.

Anyway, I won't stop anyone from lobbying for either of those. Who knows, maybe you do come up with exactly the right arguments that convince us to make the switch. However, I do think this is not the thread to have that discussion.

Roger that.... thanks for considering it...

Now back to netatalk? Does slackware want to move to the modern stable version (3.1.11) and include avahi? I strongly recommend this, or removing netatalk as the version in -current was released in 2012!

There is no dependence on pam, *AND* samba could be built with avahi support which will make it show up on macOS computer, which a lot of people are using these days.

It adds a dependency, but it's really worth while in my opinion....

Thanks for working on Slackware!

vim 8.1
Source: https://github.com/vim/vim/archive/v8.1.0001.zip
Release notes: https://www.vim.org/vim-8.1-released.php

I'd even go a step further - if there's a compressor that makes outstandingly small output files for /dev/urandom input, it's either a very fishy compressor, or very fishy /dev/urandom ;-)

Which is why for something resembling real-life scenario a bit more (in my followup post) I used all the *.txz packages found in slackware64-current. :-)

mesa-18.1.0
ftp://ftp.freedesktop.org/pub/mesa/mesa-18.1.0.tar.xz

Keep xorg 1.19 stack in extras
 

Hi,

Could it be possible to keep the latest xorg 1.19 server stack in the extras directory as an optional downgrade?
Nvidia legacy driver 304.xx does not work with 1.20 and it has been announced that no further work will be done in that series.
Also, it needs a trivial patch in order to compile against a 4.14 series kernel. The diff and instructions could be included, and I could send them to you provided I have a 1.19 server stack to test against.

Thank you for the great work.

Sergio Reyes-Peniche

If you need a nvidia blob that old, maybe nouveau might be a more than viable solution?

mariadb-10.2.15:

https://mariadb.com/kb/en/library/ma...release-notes/
http://ftp.igh.cnrs.fr/pub/mariadb//...10.2.15.tar.gz

hoping to getting GQRX & CubicSDR working, CubicSDR will build but it segfaults when i try to run the app (i have no idea what is causing it)

GNUradio wont build, something needs patched, and again i have no idea what, so i never got far enough to build & install gr-osmosdr & GQRX

Done.

Many Thanks!
:)

Keep xorg 1.19 stack in extras

=== If you need a nvidia blob that old
It's not that old, per se, version 304.137 is from last september, it's just that it won't be upgraded to ABI 24 (1.20).

=== maybe nouveau might be a more than viable solution
nouveau works OK for simple things, but if I attach an external monitor to my laptop and try to dual screen I get lots of flicker that make it completely unusable. Nvidia binary driver doesn't do this.

Keeping an xorg 1.19 stack in extras or even in pasture, as it was done with xorg 3.3.6, would also benefit people using the eight xorg drivers reported in the Changelog on May 12 as no longer compiling with 1.20 (xf86-video-geode, xf86-video-tseng, xf86-video-sis, xf86-video-savage, xf86-video-s3virge, xf86-video-rendition, xf86-video-r128, and xf86-video-mach64) and which are under consideration for removal.

As I don't have the hardware to test it I cannot be sure but I suspect the other legacy series from Nvidia (340.xx) could have the same problem with xorg 1.20.

Thank you.

Sergio Reyes-Peniche

You probably want to say "pasture" ... ;)

--------------------------------------------------------------------

BUT, that's the fun with using the proprietary drivers. Sooner or later they will not be compatible with current graphics stack.

Oh, and BTW, welcome to the blobs fun usually found on the RADEON side.

And why should be a tragedy that your NVIDIA blobs aren't compatible anymore and special measures to be done, when since ages the AMD/RADEON blobs has been Cinderellas of Slackware?

I remember of building of an entire really old graphics stack for a Radeon based laptop which overheated badly with open-source drivers... ;)

poppler-0.65.0:

https://poppler.freedesktop.org/
https://poppler.freedesktop.org/poppler-0.65.0.tar.xz

mutt-1.10.0:

http://www.mutt.org/relnotes/1.10/
ftp://ftp.mutt.org/pub/mutt/mutt-1.10.0.tar.gz

I agree with Darth here. This is essentially nvidia's bug and given they will not fix it talking to the nouveau developers to fix your other issues is probably the best long term solution. Short term you could just install an older xorg, but this is just a stop gap and will eventually become unfeasible...

Of course, the nouveau developers might just tell you your best bet is to buy amd which is well supported in linux now. :) (Maybe not with w/e old card Darth tried...)

procps-ng-3.3.15:

many CVE fix:
https://gitlab.com/procps-ng/procps/tags
https://sourceforge.net/projects/pro...ar.xz/download

For those interested in security, this is a result of a security audit by qualys. CVE-2018-1120 is also being addressed in kernel 4.14.42.

Would it be possible to include the BBR TCP congestion control module?
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BBR=m

There's a good description on lwn.net.

I tested on Debian 9 with kernel 4.9. Downloading 16MB file with Singapore wget client connecting to New Jersey web server, times varied from 14-92 seconds, averaging 60. After enabling BBR, times dropped to 5 seconds, with none higher than 5.5 seconds! Not bad for a 293ms ping time.

stunnel-5.45:

https://www.stunnel.org/sdf_ChangeLog.html
https://www.stunnel.org/downloads/stunnel-5.45.tar.gz

postfix-3.3.1:

http://www.postfix.org/announcements/postfix-3.3.1.html
http://cdn.postfix.johnriley.me/mirr...x-3.3.1.tar.gz

gimp-2.10.2:

https://www.gimp.org/
https://download.gimp.org/mirror/pub...2.10.2.tar.bz2

glib-networking-2.56.1.tar.xz:

http://ftp.gnome.org/pub/gnome/sourc...ng-2.56.1.news
http://ftp.gnome.org/pub/gnome/sourc...-2.56.1.tar.xz

vte-0.52.2.tar.xz:
http://ftp.gnome.org/pub/gnome/sourc...0.52.2.changes
http://ftp.gnome.org/pub/gnome/sourc...-0.52.2.tar.xz

Hello Guys!

I have a lot of free time! give me something to work on!

Kernel >= 4,17!
 

I understand that it's a bit bleeding edge, but it seems I can't get my brand new Ryzen 2200U to work with anything 4.15-4.16. Did not try 4.14, 4.13 still works.
4.17 is OK: I tried with Manjaro Linux, but I'd like so much to have the right kernel on my next Slackware!!!

You can build your own kernel and you might find instructions here,
https://docs.slackware.com/howtos:slackware_admin:start

I haven't built a kernel in years and have little to no interest in doing it again, so I use Dave's Unofficial Slackbuilt Kernels
from here, https://dusk.idlemoor.tk/

Once the 4.17 series is released as "Stable," Dave will, most likely, make it available at the above link.
My Ryzen CPU has worked well with the 4.15 and 4.16 kernels, but your newer version apparently needs the additional support provided by the 4.17 kernel.

That's not how it works around here.

True, and I have compiled kernels also recently (incl. 4.16.x), but if you want a distribution to reach the widest audience it is the best of options: people expect it just to work... and the Ryzen APUs are going to be more common in the coming months. I could not install nor Slackware 14.2 nor a -current snapshot, as I was in need for a quick though temporary solution I tried something very-recently released.
Given that it is not possible to install a bleeding-edge kernel by default, maybe an extra option to install some "almost latest" kernel right out from the 15.0 installation media could be a smart move.