How about adding LX-QT to that script? It and KDE are the only two desktops that I can think of offhand that are Qt-based. We should also send the fix up to dolphin_oracle for so all MX 17 can benefit.

Does NeptuneOS use a newer Qt 5? If so, that would break programs that use the private Qt 5 libs, since they are tied to a specific version of Qt 5 and would have to be rebuilt. The only one of those I can think of offhand is Calibre--most Qt 5 programs don't use the private libs.

Last edited by Stevo on Sat May 05, 2018 2:10 pm, edited 1 time in total.

wrt the script: Hi Stevo, sure, but i know nothing about those X11 session scripts, nor the lifecycle of these XDG variables. I *think* I noticed that the one i test is actually not set when choosing the "default" session, which is why i ended up testing for KDE rather than XFCE (which corresponds both to the default choice and an explicit one). I suppose this would be worth reviewing to make it more robust, but it is an improvement over the current unconditional setting of the QT_xyz vars.

wrt qt5: how can i check whether neptune overrode my QT libs ? I also do not know what you mean by "private" lib. Anyway I wouldn't jump the gun and start recompiling stuff to be compatible with the newer KDE. Keeping MX as compatible as possible with debian stable seems more important to me (and KDE 5.8 isn't bad or that old, either)

baldyeti wrote:wrt the script: Hi Stevo, sure, but i know nothing about those X11 session scripts, nor the lifecycle of these XDG variables. I *think* I noticed that the one i test is actually not set when choosing the "default" session, which is why i ended up testing for KDE rather than XFCE (which corresponds both to the default choice and an explicit one). I suppose this would be worth reviewing to make it more robust, but it is an improvement over the current unconditional setting of the QT_xyz vars.

wrt qt5: how can i check whether neptune overrode my QT libs ? I also do not know what you mean by "private" lib. Anyway I wouldn't jump the gun and start recompiling stuff to be compatible with the newer KDE. Keeping MX as compatible as possible with debian stable seems more important to me (and KDE 5.8 isn't bad or that old, either)

Calibre depends on calibre-bin, and the Qt specific private library calibre-bin needs is qtbase-abi-5-7-1. This won't be available with other versions of Qt 5, so Calibre would need to be rebuilt. That package actually isn't in apt, but it is generated during the package build and I assume points to the private library.

I do not want to actually download and install neptune, but i perused their site a bit. They simply mention being based on debian stretch (like all debian-based distros, to which extent it is customised and prone to break compatibility is anyone's guess). Here is a list of included packages.

There is also this reddit discussion (not really conclusive, though, and based on a release candidate)

Find in attachment the output of "dpkg -l" on my system. It looks to me like all libqt5* packages are at 5.7.1-1, and all *neptune* packages seem kde/plasma-related, but what do i know...

I would donate a considerable quantity of fine single malt plus some excellent stogies to such a successful event
If any group could do it, it has to be the MX Crowd - it would blast DW into orbit, keep Igor in clover for eons
Lets do this - you know you want to ...
Regards

It did not go well - even the 'install' button complained - said I had to run yadda/yadda in root terminal
So why not run 'minstall' in root terminal, right from the get-go

I setup KDE like I usually do - everything went according to plan - no problems - menus still very cluttered/busy
Would have expected some culling here - its still a kludge of both window GUI's - even the standard GUI is too busy [my nickel]

The first executable I tried was 'gdebi' .. no go ... simply a lot of noise/messages ... too many to remember - it does not work
The next was 'partition editor' which brought up KDE's lame version - what happened to 'gparted' - it simply works, as it should
As we use iPhones, I hit 'iDeviceMounter' ... it took a while, but eventually recognized my rooted iPhone, but alas would/could
not display any files in either Thunar or Dolphin - thats when I quit - this is simply not up to MX Linux incredibly high standards

I understand all the unofficial respin caveats - I simply wanted to see if it was better/different from my own respin, which we
have been running for about a year, along with all its attendant upgrades and snapshots - we have never, repeat, never been able
to break or crash this version of MXL + KDE - which cannot be said for any other DEB/RPM/KDE O/S - we have broken and crashed
them all, unfortunately - all except MX Linux - we run say 15 partitions with various flavors, with say 3 or 4 current O/S, in case
there is a hiccup after any sizeable/significant update - easier to simply continue with another O/S, and fix that ails it later on.
Thruput is simply critical-mass in our business - all this on my main production notebook ... a highly modified 18'' Vaio