We merely need a wrapper for (the late last few) scripts failing to seek for python2 the same as the new scripts would seek for python3 when 2.7 was the "default".

The time for more time was the past ten years, and if any time - it is about high time it is up now, soon there could be python 4 and we are still considering if we stay or go from 2 to 3?

And I say this regarding my self the most conservative user there possibly can be.

Make install for python-2 creates these symlinks:
/usr/bin/python -> /usr/bin/python2
/usr/bin/python-config -> /usr/bin/python2-config

Make install for python-3 does not create a /usr/bin/python symlink or a /usr/bin/python-config symlink.

I think it's better to leave things as they are and assume that /usr/bin/python will always point to python2. That is, until python2 goes away, at which point I don't think there should be a /usr/bin/python symlink at all.

PEP 394 seems to agree with this assessment.

10 members found this post helpful.

We have no idea if this is the case or not. The length of this dev cycle and the length of time 4.4 will be supported might not have any link. 15.0 could've taken just as long even if 4.4 was never marked as an extended LTS. We might've just gotten lucky during this dev cycle.

I don't think many SlackBuilds would need anything more than a simple sed to switch all instances of "python setup.py" to "python2 setup.py". All scripts using/supporting python3 already have that specified, so switching python to python2 in the scripts would future-proof SBo no matter what Pat chooses for python in 15.0 or future releases. Plus it has the added benefit of still working on 14.2, so the SBo master could be changed and ponce wouldn't need to worry about it in his repo.

Assuming Pat doesn't remove python2 entirely from 15.0, this should cause very little issues, and those can be fixed as they're found.

2 members found this post helpful.

@bassmadrigal
Some slackbuilds , make first install with python3 , and later to python2 to ensure python2 is the default, you casn see this in pip slackbuild , but i think others do same action to ensure default is version 2.

@SCerovec
No understand my message , i agree to go with 3 as default, but this change need some time under slackbuilds , and some test later.

In some case, patrick say version 2 goes default, some more time ... sad :=(

The pip SlackBuild looks to be python2 only. If you're talking about official Slackware packages, I'm sure Pat will do the testing and fixing before it's pushed out to the public. We have very few hiccups from official packages, just usually breakage with 3rd-party packages or bugs in the software itself, not a packaging problem from Pat.

But I do understand what you're saying, but this wouldn't affect how the packages are built right now, just ensuring that if the switch is ever thrown (or the symlink is completely removed) that all scripts will still function the exact same. If the default python ends up being changed at some point in the future and breaks packages, those can be found and fixed during the development of that Slackware release through ponce's repo or during the inevitable freeze of SBo while they're prepping for the new release.

Thanks Patric, I see, seems logical although.

1 members found this post helpful.

Taking advantage of the discussion about python 2 or 3...
In the past I asked for Qt5 in -current. But now I'm asking a little bit more:
Qt5 + PyQt5 with python 3 support

Reasons:
Qt5 will facilitate the life o people that want to move from KDE4 to Plasma5;
Qt4 isn't supported since December 2015;
The complete set mentioned above will allow (almost painless) compilation of some softwares, like SciDAVis and Veusz (well the are not popular, but...), using the latest versions of Qt, PyQt and python.

3 members found this post helpful.

AlienBOB's plasma 5 contains exactly that.

3 members found this post helpful.

Bad choice , cause plasma deps , and slackbuilds, not match qt5 version , and later problems arrive when some slackbuilds.org not build, under qt5 erick version for plasma.

You no understand this, cause living under kde4 or xfce , but users need qt5 , ... and the best way is a official packages for all 3rth have one version FIXED , and yea , i know slackbuilds not officially support "-current" ... but ponce do the work for slackware users.

I hope you understand the users "need" , this qt5 , cause qt4 is obsolet, and options to get qt5 are not same on 3rth party.

One more time , requesting qt5 , to start point ... some times i think you wait for qt6 or qt7.... or return to qt3 , cause thats an x-files expedient to no provide qt5.

After all , im happy with current, but qt4 , is very obsolete ,if no plans to go plasma soon , at least make qt5 possible, in /extra or /testing ... but do something.

2 members found this post helpful.

FWIW and IMHO, Eric's present qt5 version (5.13.x) or the last LTS (5.12.x) should be perfectly fine too if provided by Slackware...
I kept at 5.9.x in the unofficial repository for current because I personally don't have the resources to test every qt5 library/application on SBo but I'm pretty confident that users of current that work with qt5 applications will be motivated enough to contribute version bumps/patches too in this case.

3 members found this post helpful.

Why is this a bad choice? The scripts at slackbuilds.org are targeting the stable Slackware releases, and all script updates on the SBo site are for the latest stable release 14.2. There are no SlackBuild scripts on SBo that target Slackware-current.
In my own repository (my regular and the Plasma5 repositories) I have qt5 5.13.1. I build a lot of packages against that release. Nothing bad happens.

If you want to run Slackware-current you are committing yourself to testing the next stable release of Slackware and giving feedback on the issues that you encounter. If (on top of that) you install my KDE Plasma5, you are in the bleeding edge section because on top of Slackware development you are using a 3rd-party development (mine). All the breakage is yours to fix if you don't want to work together.

Instead, you could fix the issues you are having, report your fixes to the maintainers of the SBo scripts you fixed, support and assist other people here on the LQ forum with the knowledge you have built up. That is good for everybody and makes the Slackware community a good place to hang out.

But stop whining here and on my blog (where you've become really offensive). Start being constructive please, and also accept that not everything you request in this LQ topic will eventually become true.

10 members found this post helpful.

I Virgil commit my life to the Living One. Sorry I just can't withstand. I think we use -current for many purposes. I have -current installed but nowadays I mostly use 14.2. Just only upgrade. And I keep -current clean. As possible minimal number of additional packages. Once 15.0 will be released I will start to use it and then will add what I need. I don't have enough resources for testing - say I would build app on -current - once -current will be upgraded I would have to rebuild all application. I have too old computer it is slowly dying - it would be just overkill. So I do what I can.

1 members found this post helpful.

Feature request: Enable ~/.xsession-errors by default.

Nominal discussion here.

Related discussions here and here.

Thanks.

Hello,

I don't know if it's the correct thread to post this minor issue...

The package fvwm-2.6.9 on slackware-current does not contain the fvwm man page.

You have to explicitly use the option --enable-mandoc with configure in order to have the man page created.

I reported this bug upstream here : https://github.com/fvwmorg/fvwm/issues/86

2 members found this post helpful.

OT:

https://www.menshealth.com/fitness/a...-weir-workout/