added required kdebase package to package group. This also explains an incomprehensible bug report I got from someone on irc. Sadly he did not find the solution and tell it to me.

The problem with these rolling releases, as I noted, is that once you set them up, you don't need to do it again, so I have little reason to always test every piece of smxi, have to rely on people doing setups and finding glitches for that.

The skype installer can be fixed by finding what packages need to be installed for a clean 64 bit install, so if you can get that package list I can just add that, and a comment warning 64 bit users that will happen in the installation process. The goal is a clean install.

To help in a real sense with smxi, that's the kind of research and testing that is very time consuming, but will actually teach y ou a lot about how apt and debian work.

For example, in the case of the 64 bit skype package, you see what it needs, and why it breaks or removes stuff, then find out if that's fixable, what packages are required. A virtual machine that can be reset with snapshots of os after each test, to restore to vanilla condition, is particularly helpful for more complicated failures where you don't really know what is breaking or changing, skype packages would be in that category. Once you learn debian and apt better, it's very rare that a virtual machine is needed, since apt usually tells you what s happening and why, even if it's obscure or arcane.

You can read on some of the issues on Skype on Linux 64 bit in the reader comments, there is a beta 2.2 that has native support. Not sure where that's at.

Given that there appears to be a native 64 bit package in the works, I think I'll just wait on this one.
Back to top

I couldn't get the option for installing Skype to work today & the Debian package building tool failed to build a usable AMD64 Google Earth package for me... My log file is too large to pastebin according to the Debian PasteBin site... Also the vm-installer option died on me earlier tonight with a error pointing to line 961 of the main smxi script...

I think maybe the recent bash upgrade that happened on 12/24/11 may have caused smxi to act glitchy but it's hard to say for sure... I run AMD64 Debian Wheezy on a HP Pavilion dv6z-1100 with 2 GBs of RAM...
Back to top

Ha, I am running an HP Pavilion too.
Google Earth installed fine but I still did not test it, will be back on that.
@Techadmin: I will be glad to test for you, hey, I get a benefit from that too.
But I am just setting up the system, I am a refugee from aptosid (I still have it in a machine, mostly for the manual), and have to set up my production system again.
I already set up the runlevels I was used too and that I find useful, I was shutting down X with smxi, but going to init 3 is faster.
Virtualbox is one of my doubts, I will ask about it in another thread, need to decide which way to go, ose or non-ose, but I will open another thread for that later.
rbxi definitely does not install, corrupt file even after installing your bzip2.
So, give me some time, I will install VM and test for you.
In the meantime I have a huge issue with ntfs-3g, please answer the thread that I will open for that.
Thank you.
Back to top

rbxi installs fine, you probably got either an incomplete download or some other corruption, just remove the bz file from /usr/local/bin, and all rbxi stuff, and install it again.

ntfs3g is very risky to use for serious data, be warned. I gave up trying to share ntfs partitions years ago. Keep in mind that all the ntfs stuff is reverse engineered, and usually not very well. Reading the data is fine and safe, but all write operations should be considered as carrying a risk.

I'll use ntfs3g for short term mounts if working on a system via a livecd or something though. The kernel has native ntfs read capability I believe.

I don't bother tracking the status of non free 64 bit binaries, sometimes they work and sometimes they don't, it's unclear to me why after so many years where this has always been the case this fact still has not registered.

You can always try and see, and sometimes it works just fine.

If you read the thread I linked to re skype and 64 bit, you can see that it's not working for most people, and that skype has been very slow to update or fix their code for linux. That's a very simple thing to understand, by the way, if you are allocating resources as a company, especially a company now owned by microsoft, do you really think that 64 bit, used by a fraction of a fraction of desktop users, is really going to merit, objectively, a large part of the programming budget?

Here's how desktop budgets work in the real world:

windows 7 32
windows 7 64
windows xp 32
windows xp 64 (if any support at all)
mac os x
then make a huge space, since mac osx is around 10% of desktops, and jump down to linux:
32 bit - usually decent
64 bit, either non existent, using 32 bit compat libs, intermittent (like adobe flash), or full support, like opera.

Also keep in mind that Windows maintains very stable APIs for the desktop, which means that in many cases, but not all, the code that worked on xp in 2001 is probably going to work fine on vista and 7, or work with just small changes, and then after those changes, the api doesn't change. This is the polar opposite of the case of Linux, where if you start trying to offer commercial support, you have to deal with constant api churn, in the core desktop apis, the xorg apis, an entirely new x manager api, wayland, kernel issues, and where change is considered a virtue, not a failure. Imagine how frustrating that is to try to track, especially if you have to pay the programmers. That means that not only does Linux have a small market share, within that share, you have to spend a lot more time running after the changing apis. You see this video drivers too, where linux kernel devs seem to take an almost perverse delight in introducing api/abi changes that seem to have only the purpose of making the video drivers fail to install...

If you give desktop linux a roughly max 2% market share, which is quite realistic, and if you give 64 bit a roughly 25% total max share, you can see that 64 bit represents, at very max, about .5% of the total desktop market. And that .5% is further divided into an entire range of largely incompatible desktop apis and kernels. And now even varying x managers, with wayland coming along.

Once you really get this, you can see why, for long term support, ie, if you are using your system to do web development, where things really must always work for testing/debugging, 64 bit just never has quite cut t.

Now, if you don't use any non free stuff, or just basic stuff well and consistently supported, the story is totally different, it's been years since the last major obstacles for full 64 bit in the free software realms were removed, OOo was one of them, but that is old news now..

The same goes for other packages, virtualbox non ose, ie, using the extension pack, vmware, etc. If you must have full functionality of such tools, always, then that's something to consider as well.

I always chuckle when year in and year out some key piece of 64 bit fails, flash was this years, skype is ongoing but I don't consider it key, especially after reading that skype blog thread about the ongoing dismal overall linux support.

And that, to make it shorter, is why I still don't run 64 bit.
Back to top

Craigwd_2000, please post the output of the error exactly, it's very unlikely it's that line number of the main smxi file, but it could be on a library file, I need to know which one.

You can run most of smxi in X, with the -G option, so you can easily go to where the error appeared and then copy the error code and the surrounding text so I can pinpoint it.

I did some changes yesterday and an error is entirely possible.

You can use pastebin.com to paste larger files. I think only debian has that size restriction, not sure.

I just tested the live smxi, and started the vm installer from smxi, no errors, where exactly in the process did you get an error? Once the vm thing is running, that's svmi, not smxi.
Back to top

Craigwd_2000, sorry, missed some things. You are right that a recent bash upgrade has messed up stuff, for some truly bizarre reason they have changed some core functionality, I discovered one change in grep last night, that required recoding a method I use all the time, and to find all those instances, well, that's not going to be easy.

I am completely unable to understand how such core changes, which can and do break all existing code and scripting that use them, can be allowed to be introduced, that removes one of the prime positives linux systems offer: stability.

So there are now going to be a lot of places where certain behaviors that have always worked may not work the same. Time will tell.
Back to top

@Techadmin,
I just installed Google Earth fine on my 64-bit system, using smxi.

However, rbxi still fails.
Deleted rb from /usr/local/bin and attempted reinstall.
bzip2 and rsync were already installed.
downloaded rbxi
Extracting rbxi data
tar (child): rbxi.tar.bz2: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now.
tar: child returned status 2
tar: Error is not recoverable: exiting now
Setting up rbxi...chmod: cannot access 'rbxi': No such file or directory.
rbxi setup completed
Verifying rbxi file integrity...grep: rbxi: No such file or directory
file is corrupted: test failed!
Exiting because of unexpected error. Please make sure you have a good connection.
Back to top

oh, I see, a behavior has changed, grrr.

I noticed this on something else but it hadn't registered.

In this case it's wget, previously the rb short cut leads to the rbxi.tar.bz2 file, and wget downloads that file name.

These kind of random changes for no apparent reason are really not a good thing....

I'll have to check that code, sigh...
Back to top

This is a behavior change in wget, quite worrying, since there was also a behavior change in grep, I hope this isn't indicative of a total breakdown in discipline in core tools...

This is now handled in smxi, thanks for the explicit errors, that showed where the issue actually is.
Back to top

rbxi installed fine this time.
Seems like a great solution for backups.
Now let's get it set up.
When attempting to run it in console as root it said:

Does this mean that all variables in that set must be set to true?
One more little purist thing: there is typo at the end of line, the word 'run' is missing.
Back to top