smxi: 8.15.0
Finalized the initial packages to be removed output, now smxi will also make an attempt to match packages to be added to packages to be removed list, using some regex slicing with sed, which will take any string 5 letters or - long or more, then cut out the part before any number, and then compare it to the packages to be added data.

This is often reliable, and most new packages are lib files, which in general have 5 or more characters before the first number.

This is a nifty feature, and lets people see the connections between upgrades that they generally would miss in the long hazy list of package names passing by in a blur on their monitors as the data floods the screen.

And no, nobody 'needs' this feature either, which is what makes it so nice to do, in fact, let's get serious: how many of us actually 'need' these silly computers in the first place? 'Need' as in you 'need' food and water and air, and enough heat to keep alive.

Now that we have the question of 'need' is out of the way, let's focus back on what's nice to have, what's convenient, what is a useful tool for people in general who do not want to waste their lives learning how to run an operating system in order to... well, I assume in order to be able to run it. Not a very productive use of your time on earth if you ask me, but each to their own.

For the rest of us, let's work on using our time as productively as we can.

Sample from today:


It was this convenient data set, by the way, that made me decide to implement this new feature, which just used some already existing data collected by smxi pre du already.

I also added debian testing to this since now that output would also have some value to testing users.
Back to top

Added support in smxi for antix/mepis users who have manually updated their menu.lst to use # kopt=..... root=LABEL=... or root=UUID=...

If this is detected when smxi started, it will allow Debian kernel install to occur, which will appear in the advanced kernel install options as another kernel install option.

While the default is still to show no kernel pre dist-upgrade, users can now go to post upgrade options, kernel options, advanced kernel options, and install a debian kernel there.

You can also, if you want, set the default system kernel install option in misc tweaks, advanced tweaks, kernel options, to debian-kernel from no-kernel, and then you'll see the latest debian kernel offered when you start smxi, pre du.
Back to top

New: Gnome version detection in package group hold/install tests.

It took some comparison time, found 3 distinct groups to work with, each with their own numbering scheme. I'm assuming with gnome that version number mismatches will always be picky, so I'm using the the pickiest numbering here by default.



However, at some point smxi had to deal with the reality of going out into the broader Debian pool, where many users run Gnome, or Xfce, with its gnome libs.

And the gnome apps etc. So I guess it's fine to support it. The new method I use to do pretesting of package groups speeds things up so much that it's not actually that painful to add a few more groups to the group testing, and gnome is certainly a biggy in that area.
Back to top

smxi now features initial support for the new damentz zen kernels, liquorix.

If you in your /etc/apt/sources.list or create /etc/apt/sources.list.d/liquorix.net a file with this repo:



You will see in advanced kernel install the option: install-liquorix-kernel

<update>Now featuring both 32 and 64 bit kernels.

Liquorix kernels use the zen sources, they support fglrx drivers, and they will largely be upto date, though of course I don't expect damentz to whip new ones out every day, that's not a great use of time.

So that's a neat new feature in smxi, another cutting edge kernel option, with even more fun stuff in it.

Visit irc.oftc.net channels either #smxi or #linux-smokers-club if you have any questions for damentz, who is building them and who made the repo etc.
Back to top

smxi now automatically updates inxi if inxi is user installed in /usr/local/bin.

This will overwrite user set permissions, but I think overall it's a lot easier to just let smxi update inxi, at least until it's packaged in a way that average users won't need to check.

Also of course, for cathbard repo users, this isn't an issue since he packages inxi already.

But that's why smxi only updates it in /usr/local/bin, the default cathbard path is: /usr/bin
Back to top

I finally got around to adding the one time seen pre du question for sidux users only to reconfigure locales (you know, how sidux has so many turned on and it takes forever to run through them?)

Now that question runs one time for sidux users pre du, and is of course still accessible via the old miscellaneous tweaks section. Also improved how the question is handled, added an option yes/continue no change selector to make it more intuitive, since all smxi users will see this one time.

Oh, you can also trigger this any time pre du with new -L option.
Back to top

Could you do the same for antiX users too (if not already done)?

The next version of antiX will have all utf8 locales available, so au upgrade of locales will take ages.

Thanks
Back to top

does that go for mepis too?

No problem, can you let me know for mepis, but I'll add in antix now.
Back to top

antix added, mepis addition is trivial if required.

I can't believe I waited so long for this, it's been on my mind for ages, but I just hadn't thought of a nice clean way to use it, now it runs only pre du, not generically, so -kwid for example would not show it.

-L will show it too always now.
Back to top

Thanks h2.

MEPIS uses the same number of utf8 locales as sidux, but not as many as antiX, so it is probably a good idea to do it for MEPIS as well.
Back to top