SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If people don't want to run the new software that requires Qt5 then they can run the old software that doesn't. qjackctl without the Qt5 dependency is there on Slackbuilds under Slackware 14.0. The Slackbuilds website is very functional and people can find older versions of software that doesn't require Qt5 on it.
This is the most complete piece of truth on this whole thread. Slackbuilds.org has all the older versions available, all you have to do is reset the search box to the older version and look at the dependency.
Thanks to the SBO Team for such a great site and testing everything before it goes on the site. Thanks to the SBO maintainers for their time and efforts with scripts to keep everything sorted with each version.
As for those criticizing. It reads to me that they have mixed -current with SBO stable and are falling into the pit of dis-"pair" which will always mean the system will be unstable. Specifically, if you don't follow the recipe for making bread, the bread will be flat, tasteless and be un-eatable. You'll have to throw the whole batch out for the birds and animals, or choke it down with lots of beer. Anyone have some free beer? Cheers.
@Drakeo: I don't really want to quibble over definitions, but in the context of SBo "dependency" means some new software ("A") that the system needs in order to compile/run the new software that you actually want ("B"). As for Debian/Ubuntu, yeah, not my cup of tea, but they're widely used. And I have donated to Slackware a few times, thanks
Huh? Does SBo not provide scripts to create additional packages? Of course there will dependencies for some builds
*edit* I read that as "does not provide additional packages", but now I can't work out why it's "interesting" at all :P
sorry for confusing you, but you need to read the whole thread to see where 'adding the Qt5 as dependency on SBO is purely madness' actually comes from, and to which I tried to make a small allusion to, without going too much into details or start a discussion
sorry for confusing you, but you need to read the whole thread to see where 'adding the Qt5 as dependency on SBO is purely madness' actually comes from, and to which I tried to make a small allusion to, without going too much into details or start a discussion
Ah right, got it! And yes, SlackOnly is a nice initiative (especially for situations like Qt5). I got around to looking at the excellent slackrepo (which SlackOnly uses)... the images on the FAQ seem appropriate
sorry for confusing you, but you need to read the whole thread to see where 'adding the Qt5 as dependency on SBO is purely madness' actually comes from, and to which I tried to make a small allusion to, without going too much into details or start a discussion
It's not madness at all. It's by nature.... more and more projects are migrating to Qt5.
I have one suggestion. Perhaps direct users to older versions of software in the description if the system requirements of the new software is too much for low end systems with a warning that it may or may not work with the latest stable release of Slackware.
Slackbuilds.org approaches to python2 vs python3 support?
[Not sure if this is the right forum for this Q, or Ponce fork, or elsewhere]
Regarding python2 and python3 support in slackbuilds.org, currently there are various approaches taken:
* Some Slackbuilds build a package that includes BOTH python2 and python3 support (i.e. both /usr/lib64/python2.7/site-packages and /usr/lib64/python3.6/site-packages are populated). For example, "MarkupSafe" supports both in one build.
* Some packages have two different slackbuilds - for ex. numpy/numpy3, scipy/scipy3
* Some packages have only a python2 slackbuild. For ex. "scikit-learn" slackbuild (there is currently no "scikit-learn3" slackbuild).
I can easily modify some of the slackbuilds to support both python2 and python3 via something like:
(though it seems there may be special cases where the python2 or python3 build may require different tweaks)
Question: is there a recommended philosophy or approach for how to support python2 and python3?
Is the goal ultimately to have each slackbuild include (possibly optional) support for both python2 and python3?
Having each slackbuild support both at least *appears* a nicer solution than maintaining two different, and mostly identical, slackbuilds for python2 and python3.
I think that will be addressed in the next development cycle targeting for Slackware 15.0 repository since Python3 is now included in the main tree. All scripts should unified to support both Python 2/3
I honestly do not understand all you people in this thread that are bashing SBo.
You can be a Slackware user and never touch anything from SBo. If you need more software than Slackware offers (and that is all of us) then you have a couple of choices:
Do a "./configure && make && make install" on the sources and hope that you end up with a working software and a OS that has not been thrashed by a bad install script
Write a SlackBuild script to automate the "./configure && make && make install" and allow this software to be managed by the Slackware package tools
Look for a repository which has a binary for the program already - but you are at the mercy of the person who compiled it (remember linuxmafia?) and binary package repositories for Slackware are few, and none of them are big
Look in the slackbuilds.org script repository and pick a SlackBuild for your program if it's there, knowing that it was submitted by one of your Slackware peers and independently QA tested on a clean Slackware system by an administrator of SBo
I do not see anything negative in using SBo.
The most ridiculous comment in this thread so far comes (again, naturally) from Darth Vader when he writes "I believe that adding the Qt5 as dependency on SBO is purely madness". If someone needs software which has Qt5 as a dependency, then there is no way around that. If that same someone takes up the challenge to write a SlackBuild script, submit it to SBo and accepts that he/she has to maintain it for future versions, then that someone has become a benefactor to the Slackware community. And if you do not like adding Qt5 to your Slackware 14.2 then no-one will force you to use it. And again, Drakeo's dyslexia works overtime so that I have no idea what his issue is...
I think that it is pretty lame, sitting behind your computer, acting like a leech, using other people's work, not giving back, yet always finding ways to diminish those who make your life easier.
Even though Jeremy reprimanded 55020, I do fully agree. I am in the same boat as he and ponce are. I am fed up with smelling your brown arses from up close.
this started with 14.1 qt5 was very new. and the developers were getting things ready. latest greatest not always right for a distro. You sir know why.
It's not madness at all. It's by nature.... more and more projects are migrating to Qt5.
When was 14.1 released. when was qt5 added to 14.1 slackbuilds for an absolute dependency.
it is all on the git hub. may be not. Looks around.
qt5 broke so much stuff in 14.1 ldconfig. cmake. thats when I brought it to the maintainers of slackbuilds attention.
pretty much grab his git blob and fix it for the slackware version.
Ponce already said to bad. Now Slackbuild has a chance to do what we did for years keep it simple.
@Drakeo: I don't really want to quibble over definitions, but in the context of SBo "dependency" means some new software ("A") that the system needs in order to compile/run the new software that you actually want ("B"). As for Debian/Ubuntu, yeah, not my cup of tea, but they're widely used. And I have donated to Slackware a few times, thanks
All I know is http://www.slackware.com/releasenotes/14.1.php and not long after qt 5 became a dependency for qjackctl.
I think instead of breaking a system you compile with was a bad idea. Remember Slackbuilds builds virgin everything.
no one keeps a virgin system. So we the ppeople say oh this break xyz. Well to bad dude it is what we get.
I just fork it make it mine. I am not lazy just point to a broken system.
go test it.I did
Toughen up If you need Qt5, either compile it and save the package (in case you need to reinstall), or use a binary package. The rest is gabble gabble talk
no why would I want to break my 14.1. now go rebuild cmake.
All I know is http://www.slackware.com/releasenotes/14.1.php and not long after qt 5 became a dependency for qjackctl.
I think instead of breaking a system you compile with was a bad idea. Remember Slackbuilds builds virgin everything.
no one keeps a virgin system. So we the ppeople say oh this break xyz. Well to bad dude it is what we get.
I just fork it make it mine. I am not lazy just point to a broken system.
go test it.I did
Not too sure what you're talking about, but I don't personally have any problems with SBo (I currently have 271 packages installed from SBo scripts). qjackctl builds fine here on 14.2, but sorry no, I'm not going to install Slackware 14.1 to test that out (and honestly I wouldn't be very concerned if it didn't work, the SBo team are hardly obliged to maintain scripts for all historical versions of Slackware).
Quote:
Originally Posted by Drakeo
no why would I want to break my 14.1. now go rebuild cmake.
I don't have anything new to add apart from what I already said in post #45.
Drakeo, I give up on you.
You keep complaining.
You state that the slackbuilds.org admins purposefully break your computers by introducing qt5 into their repository.
You keep on telling us that you are fixing all these bad things on your own computers. Apparently for many years now.
You also stubbornly stick to Slackware 14.1 while demanding that all the modern software must work.
You also seem to disagree with the concept of QA-testing all SlackBuild scripts on a 'virgin' computer. But this is the only way to do those tests. The SBo admins can never reproduce all the computer configurations of all the Slackware users. If a SlackBuild script breaks on your custom system then you are the only one who knows what you installed, and therefore it is you who needs to find the cause and a fix.
However.
I have not seen one line of code from you. No patch. No documentation. Nothing to share with the Slackware community.
Nothing will ever be fixed if you do not share and only complain.
If you plan to keep using Slackware 14.1, i would suggest you to find qjackctl SlackBuild script that worked with that version. Do not use the 14.2 version as it would have introduced Qt5 as the dep for it. Please note that we no longer support 14.1 repository in SBo, so you are on your own.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.