Warning about Python3 update in latest -current

Warning for people running Slackware-current and have 3rd party packages installed (who doesn’t) that depend on Python3. That includes you who are running KDE Plasma5!

The “Sun Oct 25 18:05:51 UTC 2020” update in Slackware-current comes with a bump in the Python3 version (to 3.9) which is incompatible with software which already has been compiled against an older version of Python3 (like 3.8).

I found 26 of my own packages on my laptop that depend on Python3 and they are all probably going to break when upgrading to the latest slackware-current. This includes Plasma5 ‘ktown’ packages but also several of my DAW packages.

I suggest that you wait with upgrading to the latest -current for a short while. Give Pat a chance to add Plasma5 to Slackware, because I am not going to recompile any ‘ktown’ package over this.
I will however look at my other packages (cecilia5, wxpython to name but a few) and recompile those against the newer Python. Watch this space for more news.

43 thoughts on “Warning about Python3 update in latest -current

  1. Thanks so much for the heads up, Eric. I usually don’t sweat Python upgrades. Taking your advice and putting it off for a few days. 😉


  2. If I read it right this seems to be a good news after all, since it means that Plasma5 is going to land into slackware-current soon, which would make your (and my) life easier…;-)


  3. Just to be clear – This breakage has only to do with Python 3 upgrades? If so, I’m not too worried about blacklisting Python3 upgrades.


    1. Blacklisting Python3 package is not enough. Many other packages were recompiled against Python 3.9. If you upgrade those packages while keeping the Python 3.8 package, your system will be broken. As suggested by Eric, the best is to no longer upgrade current pending inclusion of KDE Plasma5. If you don’t use KDE Plasma5 and don’t have third-party packages depending on Python3, then you’re safe to upgrade.


  4. Some works ahead for the SBo contributors, if SBo follow suits which I hope it will… And some work for me as the main Slint repository hosts around 95 packages built against python 3.5… I won’t complain, was waiting for that to happen. Thanks for the heads-up, Eric.



  5. Thanks for the heads up! I have an instance of current on another partition. That is nothing but a clean install that I keep updated. The only thing not Slackware is the Nvidia blob.



  6. Pingback: Links 25/10/2020: Kodi 18.9, ScummVM Android Love, Cutelyst 2.13 | Techrights



  7. Thanks for the warning, Eric! I am going to hold off any further updates until I read that it is safe to do so!

    Pete


  8. For ktown python-3.9 need rebuild:
    kauth
    kcodecs
    kcompletion
    kconfig
    kconfigwidgets
    kcoreaddons
    kdbusaddons
    kguiaddons
    kjobwidgets
    kwidgetsaddons
    ki18n
    kitemmodels
    kitemviews
    kwidgetsaddons
    in dep:
    speech-dispatcher (need update also)
    mlt (need update also)
    python3-ramdom2
    lensfun


  9. @Gérard indeed Samuel Thibault has released speech-dispatcher 0.10.1 that I ship in Slint. This being said, to be really useful it needs to ship also orca and some synthesizers. There is already espeak-ng in -current, but it’s not complete (no mbrola voices IIRC) and would deserve an upgrade from the git repository.


  10. Ok, Didier, i have updated speech-dispatcher to 0.10.1, and mlt to 6.22.1, because the old version build by Eric not compil on current, here 😉


  11. Er, is Patrick able to work on moving ktown into current, what with him living under a bridge in a cardboard box and all? Please don’t tell me who screwed him out of the Slackware Store funds or I’d have to commit a felony.



  12. [satire off]

    I am among those who snail Pat a check whenever possible. BTW I didn’t say ‘which’ felony. For example, in California you can get arrested for sitting in your car near a beach watching the sun set into the ocean.
    [satire on]

    Obquote: “Pray! burn this as soon as it falls into your hands.” Jonathan Swift


  13. Er, I’m not now or ever plan to be a Python expert, but from what I can gather from python.org, warnings were turned into errors regarding python2.7. Code built with 3.8 is probably compatible with 3.9. I’m not convinced that rebuilding existing Frameworks packages is necessary for those who have already upgraded to 3.9. Is there a way to stress-test those 18 packages? What exactly will likely break?


  14. I noticed that upgradepkg left my 3.8 site-packages intact. All of the shared libraries in /usr/lib64/python3.8/site-packages/PyKF5, such as KCodecs.so and the rest of the above-mentioned Frameworks packages’ libraries exist in situ.


    1. Python 3.9 does not search in /usr/lib64/python3.8/ – only in /usr/lib64/python3.9/ . That is the problem. Plus, binaries can link dynamically to /usr/lib64/libpython3.so and now that is also gone.


      1. The kde frameworks packages enumerated by Master Monpontet are linked to the libraries in python3.8/site-packages. All I said was that the existing ktown packages do not need to be rebuilt. Programs that actually invoke python3 in a script are a different issue. I obviously did not make it clear that I was addressing the “Plasma5 ‘ktown’” part of the OP, for which I apologise for the confusion which arose. I simply ran `ldd` on the ktown binaries to search for missing libraries.
        Disclaimer: Your mileage may vary. Objects may appear closer than they are. Past performance does not guarantee future results.



  15. From today’s changelog:

    ‘x/x11-skel-7.7-x86_64-5.txz: Rebuilt.
    xwmconfig: change blurb from “K Desktop Environment” to “KDE Plasma Desktop”.’

    Let’s hope that’s an indication of “Real Soon Now” 🙂



      1. Sat Oct 31 01:29:37 UTC 2020
        a/aaa_elflibs-15.0-x86_64-27.txz: Rebuilt.
        More temporary additions:
        libicudata.so.67.1, libicui18n.so.67.1, libicuio.so.67.1, libicutest.so.67.1,
        libicutu.so.67.1, libicuuc.so.67.1.

        Because of this, it’s not really necessary to update the icu4c-compat package, right?






      1. We were discussing a replacement for the audio CD ripping tool kaudiocreator. K3b can do that as well as burning CD’s. And soundkonverter is another application that can rip audio CD’s.




      1. well, I think I might go on compiling it on my own… because I’m not much happy that some things are likely going to be cut out.
        I even plan on adding more, like Amarok-git 😀


        1. I know that Pat does not want to have some of the ktown packages included in Slackware. I don’t really care about that Patience game, but if he drops Digikam, I will certainly keep maintaining a package for it in ktown.


  16. Just installed vtown in a VMware Workstation 16 Player Slackware64-current VM, which I’m in as I write. Trying to figure out why all I get is a black screen when launching with initlevel 4. Initlevel 3 and startx works fine. Apart from that, it’s workig fine.



      1. Thanks, ArTourter, I’ll try that. It’s possible that the mirror I used wasn’t 100% up to date. Will let y’all know.



          1. Just upgraded my “metal” machine to vtown. Like butter.

            Thanks so much, Eric, for all of your hard work and long hours working on KDE. If it weren’t for you, I probably wouldn’t be using it, and loving it.


  17. Perhaps a new blog post may be in order, since Plasma5 finally landed in Slackware testing .
    There might be a few stragglers that haven’t been keeping an eye on the changelog.


    1. I can imagine that some people would want some guidance. But I was not informed ahead that there was going to be a ‘vtown’ this week, I could only guess and hope, and also this stuff *is* still in testing. Use at your own risk.
      I do not have the time to care at the moment, I have bigger issues to deal with privately. I am sorry. Maybe during or after the weekend.
      I have not even looked at what’s in Slackware’s ‘vtown’ except to find and report some bugs in the new sddm package. I also did not install it.


      1. That is quite understandable, personal life needs to taken care of too.

        In my case the transition from ktown to vtown went relatively smoothly. No major issues so far.
        Luckily sddm was already fixed before I made my attempt. I’ll leave some hints below for anyone else who wants to give it a try.

        On my system with slackpkg+ here are the steps I took to switch:
        1. Switch to init level 3 if not already
        2. slackpkg update && slackpkg upgrade-all
        3. slackpkg remove ktown kde kdei
        4. edit slackpkgplus.conf to remove ktown
        5. add testing:vtown to your PKGS_PRIORITY list in slackpkgplus.conf
        6. slackpkg update && slackpkg install vtown && slackpkg upgrade vtown


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.