What about to put qt5 in /extra? To be installed in parallel with qt4?

Why in /extra? It should be totally fine to have it in /l.

Yes. It should be great to have qt5 in /l.
But if you know Pat, you know that it would be easier to convince him to add qt5 to /extra instead of having two different versions of the same library in the same directory :) (assuming that qt4 will be kept in /l)

Several libraries are already present in /l, in different versions ;)

Another new gdbm-1.14.1:

ftp://ftp.gnu.org/gnu/gdbm/gdbm-1.14.1.tar.gz

Not true at all. Counteexamples: GTK1-3, SDL 1 and 2.

Sure, but also the installed Qt5 package alone (with no deps) has "only" 319MB and considering the holly full install which is preached here... ;)

Yet another 500MB added to the recommended installation? :D

Just saying, because now we are around 11GB installed, anyways... ;)

Once KDE is updated to Plasma 5, is Qt4 needed for anything else in Slackware? I would assume it would be removed eventually and wind up in SBo or other third-party repositories for those who still need it.

Okay, I definitely didn't click "Post" twice. :)

Yes, would be needed by the KDE4 compatibility support. Specially used by the KDE Libs v4.

Believe or not, there are still tons of applications which use KDE4.

And I talk about open source apps, not about a specific closed source one. ;)

Is that a part of Plasma 5 that would be required? I'm guessing that is for applications that haven't been ported to KDE Frameworks yet, but those applications may also not be included in Slackware.

I know that. I'm talking specifically about things in the Slackware tree, as that's what dictates whether Qt4 needs to be included or not (granted that, of course, the decision to keep it is PV's whether or not it is technically "required").

The qt4 and qt5 packages do not overlap, you can have both installed without adverse effects. See my Plasma 5 desktop package set.

Eric can give here a more proper response than me.

Anyway, precisely nothing depends right now in Qt5, you know... ;)

I'd have to check that qControlCenter be compatible quit Qt5. Although I'll probably use GTK3 instead, to make it actually accessible with speech.

This is just one example, and even if Slackware proper don't ship Qt4 apps, I guess that users will still want to install some as third party packages.

So, at least ship it in /extra or /pasture, I'd suggest.

That's why my question was (in case you forgot already):

Certainly. Today, that's the case with Qt5, but nevertheless Pat doesn't include Qt5. The point is that there are other places to get third party software, and there is precedent for only including a single Qt version.

OK, my bad habit to respond indirectly.

How today we can assume safely that nothing depends on Qt5, probably in future we can assume the reverse side, as nothing depending in Qt4, excluding in the Poppler support.

BUT, this discourse works only if our BDFL decide to cut the ties with the KDE4 support at all. ;)

The reason I asked was because of your comment about adding 300 - 500MB to the distribution. Assuming Qt4 were removed, it would really be that minus whatever the size of Qt4 is, so probably not actually that big of an increase.

Well, our mighty Qt4 has 130MB while installed.

Package for Slackware64-14.2:

Didier, something is wrong with your numbers, because the qt-4.8.7-x86_64-4.txz from my local mirror of 14.2 has 31843K as size.

You are right. I just reinstalled it and now I get:Now I have to investigate why.

PS The records of the removed and reinstalled packages in /var/log/ list exactly the same files, so I will check the assumption that spkg -i and installpkg don't do the same maths. One more item in my TODO list...

Looks like your SPKG is strong at Math like my first kid... :p

Nothing in the latest editions of KDE Frameworks, Plasma and Applications depends on Qt4 or the old kdelibs. You'd want those only to support 3rd party packages that do not have a Qt5 port.
Mind you: the last source release of Qt4 (4.8.7) was in May 2015, i.e. nearing 3 years now. Qt4 is in 'legacy state' and does not get updates. Applications that still use Qt4 can be considered 'legacy' too.

The qt5 package is 74 MB in size. The installed size is a bit bigger than 300 MB. What are we talking about really.
The linux kernel, tex, rust, llvm packages are way larger and I assume that after installation of Slackware, those will be used a lot less on a daily basis than qt5.

Hi,

I wouldn't be that harsh.
They are still very useful apps.
Although to be sincere, I haven't checked when they were last updated or if they can be compiled against Qt5:
Anyway, I'm fine with Qt4 in SBo if need be.

I hope that, when the time comes, Pat will make it actually bigger, by including docs and examples.
Or at least by providing separate packages for them.
docs and examples are really great things if you learn to program in Qt.

--
Best regards,
Andrzej Telszewski

That is a great idea. Python (even a demo), ruby (ri and rdoc), and perl (perldoc) all do so.

I agree totally with the docs and examples from Qt. That's totally worth. :thumbsup:

Heck, at 11GB installed and counting, who care about another 1GB for those development goodies? :D

I think that they are worth every single byte. ;)

ruby-2.5.0
https://cache.ruby-lang.org/pub/ruby...y-2.5.0.tar.gz

What do I think it needs. Current PAT WTF. Dude. Buld the kernel 4.4.11 then see if it builds against NVidia if not put the message out.
Obviously the latest kernel build is for a newer gcc. weather it is in the fookin kernel.log or not. How about fix your push to thousands of NVidia users before you push it. Look yes I am pissed At this simple bool. and a stupid short integer that the nvidia guys take our money and send Vaseline . Do not be like them put it in the log this shit breaks "nvida" PAT.
I think it is cold out side spent all day working in the cold not at a desk top. to break my system over a team leader not building NVidia and if you did it did not build if it did build how the am I wrong. Oh breaks Nvidia ?
Pissy.
Rants over you going to drop support for NVidia let me know drop some AMD cards in and end stop the bull.

Wait what?

First, there's never any guarantee that nvidia's binary driver is going to build against *any* kernel, but certainly not the latest release.
Second, you've got to accept that risk if you're going to run the -current branch.

Mr workman the work affects thousands fill the log out. Or go back to IRC. This is not testing this is current thump your chest somewhere else .

This is why I don't always even make an attempt to be polite when someone is rude, but I did for you.

@Drakeo:
Long version: I can hardly believe that after having regularly visited this forum since nine years you still don't know that -current is provided for testing.
Short version: run 14.2 until 15.0 is released.

Robby talk to the hand build it like slackbooks says put it in the log as a fail. I read logs. I push all the time. And I know this tells me one thing Pat did not build against Nivida. .No other words. KISS . I read Logs before I do anything.
look rude you are out of line. I have seen your wonderful work I use it. When I screw up no one sugar coats it.
sh NV press tab. fill the log out.

David love your work. Thats it. You have great logs. Trust meI was let down that a simple show killer was passed never noted.
It will happen again .

I don't test with NVIDIA's driver.
I don't test with AMD's official driver.
I don't test VMWare's kernel stuff.
I don't test those and lots of other stuff because I don't have the (non-free) hardware or software to do so.
That will not change.

I can't speak for Pat, as I don't know what hardware he has exactly, but this expectation you seem to have of him to test a new kernel with NVIDIA's non-free software is unreasonable.

I'm surprised that this surprises you.

Who was talking about you. This was About Pat pushing a show killer and not noting it. Stop it. It is Pat's changelog.
do not harass me again. This is a slackware forum. And this is Abouts Pat's WORK. not yours. I support his work. I care less If he likes me or not. Makes me think. You Sir Are Out of line. We the slackware supporters ask wtf wtf Pat. Get with it KISS. heads up nvida broke dudes.

It's getting late and I am tired so maybe I am not understanding the problem Drakeo is having. The nvidia driver is not building with 4.4.11? As I stated in another post this was fixed 14 hours ago...

https://www.linuxquestions.org/quest...4/#post5801515

I do not have a problem. I was reporting Pat pushed a show killer with out a note. Slackbuilds is far from slackbooks.
KISS I am disappointed this much work in a kernel and no note the nvidia installer is broken.
None of those links you pushed sir are from this years nvidia blob.
Be so kind to learn what a changelog is for.
Ask your self Why would I care.

Dude now you are pissing me off. The first link was wrong, I said that, READ the other two, this is fixed! It's late and I am trying to finish up my work so I posted one wrong link then immediately corrected it. If you are too lazy to patch 6 lines of code in one file then just sit there and wait for nvidia to release a new version and stop complaining because Pat didn't take the time to inform you something might break on the TESTING branch of Slackware.

nvm push the link to the latest. it is a forum 0 and 1. kiss
current is not testing. learn current can break at any time you want to follow in RWorkmans foots steps. Wtf dude type sh NV the fill out the log. What is a log.? Why do we have them.
Yes Pat let me down. 2 times in 20 years stuff happens . Better than my mom.
She dead

Which driver are you using?
I have 2 different computers with different NVidia drivers (one is legacy 304.xx and the other is 384.xx) and they are working great with Linux Kernel 4.14.x. You just need to find the patches for the version you used and it's already available for some time

-current is the ongoing effort of developing, *testing* and stabilizing the next Slackware release. It is *not* a rolling release that's supposed to work all the time. There *will* be breakage of various things all over the place. It's inevitable because nobody can account for everything. That's why we expect people running -current to be experienced and mature enough to test and verify *their* particular use-case(s) and report to us when something is broken, preferably already with a proposed solution.

So, in your case, instead of ranting on and on about how the breakage with the proprietary nvidia driver was not noted in the changelog, you should've just calmly noted that the latest kernel update doesn't yet work with it. Ranting won't fix anything.

Current releases of sqlitebrowser are Qt5 based (https://github.com/sqlitebrowser/sql...er/BUILDING.md).
SMtube is now also Qt5 based (https://www.smtube.org/).
I have a Qt5 based Krusader in my own Plasma 5 repository.
Krename development in git is based on Qt5 and KF5 (https://cgit.kde.org/krename.git/tree/CMakeLists.txt).
Firetools supports both Qt4 and Qt5 (https://github.com/netblue30/firetools)
About qtgzmanager, I don't think there was any development for multiple years and the last couple of releases were only done to add new Slackware versions it should support. Time to say bye-bye.

So you're mostly good.

If you want a stable system, run Slackware 14.2.
If you decide on slackware-current, then - as I have told countless times - you are considered to be a Slackware BETA-TESTER. We (Slackware team) expect that if you run slackware-current, you accept that things can break suddenly without immediate fix, and we also expect that you are able to fix issues yourself and get your computer back to a workable state.
Read https://docs.slackware.com/slackware...rrent_versions please.

Like Robby said: slackware-current is not a rolling release model. It is where development happens. It is much more stable than development versions of other distro's, but this is NOT a stable release. If proprietary software can not cope with updates in Linux land, then too bad ans we will have to wait for them to fix their shit.
It's not like this is the first time this happened... I have had multiple occasions where I had to revert to a previous kernel temporarily in order to avoid losing my GPU-accelerated desktop.

Another tool ported on kf5, kbackup:

https://www.linux-apps.com/p/1127679/

Hi,

Thanks for checking it out.
I guess qtgzmanager maintainer will easily follow the suite.
I'm all set ;-)

There are couple of more stock packages that depend on Qt4, but they are rather active projects, so no doubt they'll adapt or already support Qt5.

--
Best regards,
Andrzej Telszewski

We all been here. Think pat Worked on that Kernel that long and did not have an issue made me look very hard at the two systems I run current. So This is A Learning Curve. About The Lead. My First post asked wtf and is it me or Pat.;
You all seem to think it is my system. OK. Great Thanks for the help. Back to the winter,

No, it is not that we think it's your system. It's the way you seem to be looking at slackware-current, expecting updates to be fully tested against everything that is NOT part of Slackware itself.
That is not how it works. The development cycle between two stable releases (14.2 and 15.0 for instance) is called "slackware-current" and if you use that development version you are a tester. Period.
You can expect that on release of Slackware 15.0, it probably contains a kernel that is supported by the Nvidia drivers, but even that compatibility will not be tested by Pat or the Slackware team.
And if it is tested and it's proven that Nvidia drivers are not compatible, that's still not a reason to delay updates. Slackware-current is always the bleeding edge and sometimes, it bleeds until 3rd parties get their act together.

You, the user/admin, are responsible for keeping a Slackware-current system functional. If you distrust -current updates because of potential incompatibilities (Nvidia for instance) but you want to run slackware-current regardless, then the best advice is to NOT immediately apply updates. Rather, you wait a day, check this LinuxQuestions.org forum for any reported issues, and eventually you update your computer when you are confident that there is no major breakage.

And a final advice. In case of kernel upgrades, ALWAYS keep a working kernel installed. NEVER use "upgradepkg" or "slackpkg upgrade-all" to upgrade from your working kernel to the next one. If you use slackpkg, make sure to blacklist "kernel-generic", "kernel-huge" and "kernel-modules".
My boot menu always contains at least two kernel choices. If the new kernel does not work or creates issues, you can safely go back to your previous kernel.

I do not understand why you were so pissed at Slackware and Pat. It was unwarranted.