Not this is not (quite) the same as using (only) debian sid/unstable.
To sidux your antiX is to utilise the great work done by the sidux team.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.sidux.com/"
linktext was:"http://www.sidux.com/"
====================================


Why should I do it?

Firstly, you get all the bleeding edge apps from debian.
Sid seems to be faster than Lenny (Testing)
It is cool to try!

If you want to use the debian sid/unstable branch, antiX allows you to do so simply by enabling the repositories in /etc/apt/sources.list
To add sidux, just copy/paste into the sources.list

deb
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://sidux.com/debian/"
linktext was:"http://sidux.com/debian/"
====================================
sid main contrib non-free firmware fix.main fix.contrib fix.non-free

Followed by an apt-get update
apt-get install sidux-scripts
apt-get dist-upgrade

Sid may break more than Lenny, but it is fixed quicker.

sidux tries to tame sid (and IMO it succeeds on the whole) as it warns you if there are problems, and there is the fantastic smxi script, which works in antiX!

sidux also upgrades the kernel very regularly, and sidux kernels work in antiX too!

Anyone who has tried this on antiX (all versions) could you please comment. Successes and failures.
I'm thinking of including the sidux repos (commented out) in the sources.list and having the smxi script installed by default.

I'll give it a go. __{{emoticon}}__

My test machine (P3) has already got Sidux installed, and antiX as well, and although i don't want to mess up the antiX that i already have on there (only because i'm trying out a few things & having a blast) i'll gladly install another antiX on a fresh partition (I have a few spare) and give it a go. It'll be cool to have a direct comparison between the two as well. __{{emoticon}}__

I did try this a few weeks ago when malanrich (is that the right name) mentioned Sidux etc, and although the scripts worked OK, they complained about converting from debian to sidux (or something like that) and i have read the same on the Sidux forums that they're no longer supporting conversion (at least from the scripts side of things).

Hmmm, thinking back on it now, i actually found the box running slower than using lenny....... Anyway, what the heck..... i'll try it on another partition & see how it goes. I'll get back to you with my results. __{{emoticon}}__

Oh, and does this mean that we're now going to call it"SidantiX" ?? LOL!

OK, it's done, and i've now got (i think) a"SidantiX". __{{emoticon}}__

I've probably made a lot of mistakes though. I added the sidux repo, but wasn's sure what to do about the other entries for testing, so i disabled all of those & went ahead with it all.

It worked..... didn't really upgrade much at all, smxi complained (as it did before) about not supporting Debian conversions, but i pressed"y" anyway. Can't seem to upgrade the kernel at all, so i'm still running the Mepis kernel. Xorg wouldn't upgrade either (apparently it wanted to take out Xorg 7.2 & replace with 7.3).

Also, i've had to do it all in a normal terminal (Roxterm) as even when i run smxi and it asks if i want to drop to init 3, it stays in the terminal & carries on. (Seems to have worked OK though). I did try booting without a gui (using the Grub"nogui" thing) and then run the script from there as root, but all it did was say that i needed to be at init 3....."Would i like to change to init 3 now?" to which i typed yes, and then it started up slim and the normal boot process??

Anyway, just wanted to let you know my initial findings (Slim as they are) and although there doesn't seem to be much difference, it's all running OK and seems good so far.

smxi support has been radically improved for debian sid/testing distros in the last 4 days.

Bugs fixed: the init 3 thing is now fixed.

Automatic adding of sidux sources if desired fixed.

No more problems running smxi on different distros like antix, will simply ask you what you want to do now.

The sidux conversion is also not required any longer, you can use sid sources alone with smxi, or sid+sidux sources, without doing any further conversions.

Supports both debian and sidux kernels now depending on your options, currently no support for mepis type kernels because I don't have the data I need to add that type of support in, but with more testing I can probably get more stuff working..

If you have run smxi in the past, with the conversion stuff, it's not as easy to undo that, but if you are doing a fresh install, it should be much better now.

graphics installer should of course work fine with sid based, and testing based, systems, as long as they are close to real debian.

I'm still debugging issues, but I have most of the core functionality working now, I finished the last bunch today.

Feedback and suggestions can be posted here:

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://techpatterns.com/forums/forum-33.html"
linktext was:"http://techpatterns.com/forums/forum-33.html"
====================================


A simple one line smxi install:
To run only graphics installer sgfxi, install same way: Both scripts should be run out of x, and should correctly handle your runlevels now, and kill your desktop if running, if it fails to kill it, it's a bug and needs to get fixed.

Thanks for the post h2, and the work on your script to include antiX (and Mepis).

The next version of antiX will include the smxi script by default. Using this script, especially for the antiX-base version, should be able to help users upgrade antiX in many ways.

1. Keep the default repos and just regularly dist-upgrade. (ie stay a Testing/Stable mix distro)
2. Enable sid/unstable repos and dist-upgrade.
3. Enable the sidux and sid/unstable repos and dist-upgrade.
4. Enable the sidux repos to the default ones (ie no unstable/sid) so you can upgrade the kernel and nvidia/ati drivers.
5. Install a new desktop environment
6. Other options.

For those that wish to test out the script, post here or to the forum link that h2 provides in his post. It should work with all antiX-M7 series ie Lysistrata and Vetëvendosje, but with Vetëvendosje, it should work better.

Have fun with the script. It really is a fantastic script, especially if you run the sid/unstable repos.

Thanks for the kind words, I've been doing some extensive hacking on this the last weeks, and I'm making very good progress.

The latest feature is dynamic stable/testing/sid testing, with some fun regex in sources.list, will default to sid if it can't find anything else, but as long as the distro sources have the word stable or etch or testing or lenny in their string, they should get detected. It skips standard optional repo tests like opera, skype, multimedia, etc, so those won't trigger a positive detection. That list will need to get expanded over time to be a better blacklist.

Post any missing repos that triggered a false result in the functionality.

this will get improved and less prone to error long term.

This data is now used to set 1 of 3 warning/package hold levels, stable, testing, and sid.

sid is the same as you're used to with smxi, testing offers different warnings and holds, and stable skips the fixes part completely, and also has its own warnings and holds, if any be required.

I've been debugging fairly extensively, and it's now working pretty well on testing, and most big bugs in stable are fixed.

If you have testing + sid, it will default to sid, if you have stable + testing it will default to testing. all other detections will default to sid.

If it's detected as stable it will not offer sidux source install, because that's simply too unsafe.

Oh, by the way, unless there's a bug, sgfxi or smxi graphics installer should be able to install nvidia/fglrx on any debian system, possibly even stable, maybe not, haven't tested it. Definitely testing and sid out of the box though.

anticapitalista wrote:Not this is not (quite) the same as using (only) debian sid/unstable.
To sidux your antiX is to utilise the great work done by the sidux team.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.sidux.com/"
linktext was:"http://www.sidux.com/"
====================================

I'm there now on my server -- I like to take a walk on the wild side!

Should my daily upgrade be -upgrade or -dist-upgrade from now on?

Don

You should use the smxi script from now on if your using sidux/sid.

'splain. Clueless (and I am seldom like that.)

From h2's post above:

A simple one line smxi install:

Code:
cd /usr/local/bin; wget -Nc techpatterns.com/smxi; chmod +x smxi;smxi

I now have Debian Sid, sidux, and smxi functionality in one of my systems. So far it looks good, just as it usually does both in antiX and sidux! __{{emoticon}}__

I decided to do this to my SimplyMEPIS 7.0 system since it has been dormant for such a long time. One difference is that I went with Lenny instead of Sid, just to see how h2's scripts work in that space. I am very impressed. Works well. I do have to sacrifice some MEPIS stuff, which is tied to Etch... oh well. I still have the purchased CD and I can always reinstall it should I change my mind. I have about five instances of various releases of SimplyMEPIS on two of my four systems, so that should not be a problem!

The sxmi sidification of my antiX partition went REAL well earlier. So far, the MEPIS one is going well too.

masinick, interesting result, sounds like it's working pretty well so far.

smxi still does not have Mepis kernel support, though that is not super pressing I think at the moment, but the infrastructure for it is there when required, with some testing.

Can you tell me what the file that is used to identify Mepis is, like /etc/antiX, or /etc/sidux-version?

This should show where it is: grep -is mepis /etc/*

This will let me improve the mepis detections and handling, but I won't be able to do active live support for that, but at some point in the future, I can add an antix/mepis user to the config/warning control panel where holds, configs, alert//warnings are set. I especially am interested in people who are tracking Debian testing based distros.

When I do a uname -a I get Linux mepis1 in the initial part of the string; I get 2.6.22-1-mepis-smp as the kernel. Will have to hunt a bit to find the /etc file that provides identification. The only one I see right now is the mepis-network/ directory, which has to do with mepis wireless support.

grep -is mepis /etc/*

Output is: