New smxi, integrates the new sgfxi nvidia legacy level, 4, which will be for nvidia 6xxx/7xxx cards, that's the 304 driver series.

Once the current nvidia driver moves from 304, the legacy 4 feature will kick into place in smxi, or should.

For now you'll see the same driver offered for 6/7xxx cards and any newer nvidia card, but that will only last for the 304 driver series as current stable.

I removed the 71xx driver install option since that hasn't worked with xorg 1.11 and 1.12 for ages anyway, you can still install those if you must via sgfxi -o option. But really, just move to nouveau, you're better off long term.

I think the switch from legacy 3 being first legacy to legacy 4, 304, should go pretty smoothly.

The graphics install section should make sense with option names and other things, I also fixed some bugs I found there as well.
Back to top

fulfilled an ancient request, and also fixed some bugs in the process, now smxi will change upgrade type when apt type is changed.

I did this as part of the process of strongly urging users NOT to use aptitude, that application appears to be in total decay and collapse, and I have found it totally unable to resolve any of the situations it used to be quite good at, making it, sadly, totally unsuitable for average users at this point.

It may still work on stable, I don't know, but I recommend against it for all cases, it's also terrible for dist-upgrades moving from one stable to another, in fact, I've had to fall back to apt-get dist-upgrade in almost all upgrade scenarios on all systems at certain points, which makes aptitude basically worse than useless.

Sad, it had promise.

But in the process, I improved smxi's internal updating on script changes while it was running, so that should resolve some long standing glitches, particularly with liquorix kernel install.
Back to top

amd/ati card users, graphics install section now offers beta driver install for amd/ati cards.

there will only be beta drivers for the current branch, ie, for example, 12.11 this month.

Because of how ati numbers work, smxi itself won't know if your card version is supported until smxi starts sgfxi, then sgfxi's error handing will let you know if the beta driver works with your card.

Note very exciting, but there it is, after all these years, finally a way to test amd/ati beta drivers easily.
Back to top

i installed ceni from smxi and i noticed that it installed wireless-tools. it is still needed or is it a bug? i see from the changelog of ceni they removed it. i posted to let you know, it doesn't seem like a big deal.



edit: also when using smxi to install a kernel like 3.4 liquorix the script installs quite a collection of different versions of gcc and cpp (4.4, 4.6 and 4.7, base and full). thanks in advance.

< Edited by dark-D :: Oct 30, 12, 13:04 >
Back to top

oh, yeah, that could be a legacy thing, I don't spend much time tracking that, maybe it's time to update it again via smxi though.

The thing however with installing deb packages directly is that apt-get doesn't handle the dependencies automatically as it does via package pool installs, so smxi errs on the side of caution.

In most of smxi package install, also, it should use the built in testers to make sure listed packages are actually available in apt, and only install the ones that are, but there are a few functions where that doesn't happen, let me check with ceni installer to see if that's the case.
Back to top

Updated to ceni 2.37 for sid version.

smxi uses the availability tests for ceni dependencies/recommends, so if that wireless-tools package grows unavailable, it will just not try to install it.

If you don't use wireless or don't want that package, you can just remove it, unless there's a technical reason to not use it. The smxi ceni thing tries to give the end user all the packages that ceni might want in most common scenarios, just to make it easy, and so you have the tools if you ever need them upon losing network.

but thanks for the nudge, new ceni is there now, current, for sid. The stable version is still for squeeze, so it won't change until wheezy goes stable, at which point the old stable will change to the current sid, and the current sid will from then on track the current sid in siduction repos.

By the way, much appreciate siduction's work on this packaging, glad they pulled out the good stuff from aptosid, makes it easier to actually talk to someone if necessary, siduction guys are reasonable and nice.
Back to top

thanks for the answers. i use ceni at a daily basis and i'm grateful for this script. thank you for providing it, i first heard about it from smxi some years ago, not from sidux. because their antipathy for the common user (me at the time) preceded any good point about their distribution. i am grad that siduction started to maintain the ceni package and i also found some useful things on their site, like a proper how-to on configuring and maximizing the life of an ssd on linux.

i edited my post at the same time that you provided me with the answer. because i am not native english i can't quite figure out if there was an answer for this:

thanks for the help and i hope i do not burden or bother you with questions.
Back to top

Off the top of my head, smxi will install the firmware packages, some other things that are useful if you build stuff on kernels, like drivers etc, then the actual zip package itself, if you select that, has an installer script as well, where the actual gcc the packaged kernel will use is also added.

Also, if you pick the regular kernel install, ie, via apt-get, in smxi, that will pull in whatever gcc it requires.

I should check the gcc versions that smxi defaults too however for all kernel installs, those might be out of date.

Your questions have never been bad or useless, just keep posting them when you run into issues that aren't clear, at worst it will do as above, remind me it's time to update the smxi housed ceni deb package version for sid, heh. Or stop installing something that maybe no longer exists.
Back to top

in advanced kernel install, added option to install siduction/towo kernels, same logic as liquorix, adds sources, installs keyrings for siduction repos, updates smxi.

Then you can easily run those too if you want.

Note that the initial first run questions, where it offers you by default to add liquorix sources, haven't changed, to access the towo/siduction install option, you have to go in via kernel advanced options in the kernel section.

note,. I was a bit lazy and unsure if the pae stuff was going to be used, so smxi looks at the 686 kernel type, pae or 686 for siduction/debian, a few more for debian alone, and will offer the latest of whatever the user is already running.

Too complicated to add options for pae or regular 686 for now, maybe I'll do that later.
Back to top

Improved pae handling for debian and siduction, now if user has > 3,000,000 reported mem size in free, and if pae kernel package is available, smxi will default to pae kernels for that selection.

Also, added in a not yet fully implemented feature so users can use /etc/smxi.conf to override this, ie, if they want to use non pae kernels even if system detects that it's better to use pae

That is overridden by adding this to /etc/smxi.conf
use-pae-kernel=false
in other words, you are running a 32 bit system, you have > 3gB of ram, but you want the non pae 686 kernel anyway. I don't see this being an issue for most people though.

and that's that. I'll maybe add an option for that in a config area, we'll see, if there's any demand for it, I'll add it.

By the way, damentz reports that he's going to move liquorix 686 to pae only, so all you pentium M users, be warned, his current kernels will be the last you can run with your system.

However, you will be able to use the towo kernels for now if you want a current kernel after liquorix goes all pae for 686. Or debian.
Back to top