Archive for category sabayon linux
Since the release of 5.4 many many things changed. As you might have noticed, the Sabayon Linux project is moving fast and many updates are generated every day.
Because we are now a rolling distro and moved some things into the maintenance scope, things that would normally ONLY get updated on a new branch, we had to resolve an issue that some Gnome users ran into. In fact the problem was not a specific Gnome issue but a distro wide problem.
When I bumped glibc because a security reason, Fabio already warned me about problems that could affect our users but we decided to go ahead.
What we learned is that in such a case, glibc on the user end should ALWAYS be installed first. And Fabio wouldn’t be Fabio if he didn’t foresee the need for such a feature and this was already possible to do for some time now. So we moved glibc to the special list and there you have it on a fresh install:
equo update && equo upgrade:
It now wants to first install glibc! You ofcourse should do this (you have no choice using upgrade)
When this is installed you want to install the latest entropy version first:
equo install entropy –relaxed
Finally you can install all the updates.
Remember that Sabayon 5.4 shipped with the 2.6.35 kernel version. If you want the 2.6.36 kernel version (or later whenever it is available in Entropy) you should manually install it. Please refer to our wiki on how to do this.
In my daily maintenance routine I tend to throw an emerge -uav world against the sabayon trees and see what packages can be bumped. I also check http://www.gentoo-portage.com to see what is new. In this routine 90% off all things I bump for Entropy it is done manually writing each emerge -av command by hand.
Since I trust Gentoo developers for doing a good job within their own little expertise and interest, I kinda trust each package bump makes sense. If it is either some revision bump because there was some LD flags to respect, a fix for –as-needed or simple another minor thing I just bump them. Even though on the binary end this would not make any difference for the user experience I just do it.
However this workflow sometimes leads to some stupid breakages because somebody thought it was a great idea to bump some lib that in fact is there for a reason. Some things in the Portage tree simply are there because some, or maybe one, of the atoms in the tree need them. There are numerous examples I ran into lately but here is one off them:
In my daily routine, some while back I bumped net-libs/enet. Not a big deal really. However this seemed to break games-action/supertuxkart and my tools could not detect this breakage. Otherwise I would obviously reverted this update. I went looking into some history and I realized that only games-action/supertuxkart ,games-rpg/egoboo and games-puzzle/enigma actually need net-libs/enet within the Portage tree, so why was this package bumped anyway? Not because it was needed for one of its parent atoms , no, because some user on the gentoo bugzilla requested this atom (remember only needed so far by 3 atoms) to be updated because “there was a newer version”. http://bugs.gentoo.org/325809 (just an example, do not shoot anybody for this!)
Somebody requested without any motivation this package to be updated and without question this was done. This all leads to atoms currently in Portage to mall function, fail to compile, etc. Later this all was corrected by Gentoo QA team where they slotted the enet version.
So what happens next is that users notice this when they install one off the games and it doesn’t work? They file a bug to Sabayon, or a Gentoo user files a bug to the Gentoo bugzilla. A bug wrangler needs to check the bug is valid enough and assign it to a herd/maintainer. The maintainer then discovers the unwanted enet bump and got to do all the work to block the newer version. All that kinda work because somebody thought it would be nice to bump a library/piece off software.
If users request such a version bump do not be scared to ask for a motivation.
It is nice to be bleeding edge, but really uncool to fall off the cliff just to look cool.
Earlier I posted a dirty hack how to get the sound going again with flash on 64bits.
Now we have www-plugins/adobe-flash-10.1.53.64-r11 in the repositories with a cure for that.
If you did follow my previous post on how to get it working with mozilla-firefox, you should undo that (remove the libflashplayer.so from ~/.mozilla/plugins )
equo update && equo install www-plugins/adobe-flash-10.1.53.64-r11
Now you should check if you have /etc/asound.conf with the following contents:
Reboot and all should be fine again.
Just as a note to myself and maybe helpful to others.
To compress all files in zip file in a directory:
zip test.zip *.*
-rw-r--r-- 1 joost joost 111M Jul 21 14:23 test.zip
If you want to split up the zip file because it is a bit too big (111MB) we can use the zipsplit command.
Lets pass the -t parameter to first let it explain what it would do:
joost@xbox-360 ~/Desktop/moos $ zipsplit -tn 10000000 test.zip
12 zip files would be made (100% efficiency)
ooh yes I wants that!
joost@xbox-360 ~/Desktop/moos $ zipsplit -n 10000000 test.zip
12 zip files will be made (100% efficiency)
And there you have it.
Well due recent changes I noticed that using flash on firefox was hijacking the sound on my system.
If you aren’t a careless internet surfer and still want to use the latest amd64 flash version that didn’t have the sound problems you can try this.
then download this flash release.
Extract libflashplayer.so into the directory we just created and restart firefox.
Some other people say they have benefit by setting an environmental variable but that didn’t work for me.
I’m not sure if the issue is only related to x86_64 yet.
A few posts back I posted about setting up your own spin. Things got moving quickly and we decided to overhaul the way we maintain our iso’s server-side.
Sabayon 5.4 will have everything based on the SpinBase iso and all applications on top off this will be placed in sets. A KDE set is going to be written soon.
A first result of the reorganization are the LXDE and XFCE spins released today!
Some important recent changes:
- On amd64 we moved to 32bits flash.
If you have a problem with it consider reinstalling nspluginwrapper. I know it is not the most elegant solution, but keeping users with a potential security risk was worse. And upstream Adobe did NOT provide a 64bits version.
- ATI-drivers 10.6 problems
Due a bug in the new ati-drivers that only affects people with a default xorg.conf (most off you) the light went out and X would die with a segfault. Check out this bug report on debian. As a result we decided to mask 10.6.
(this post was made by Mitch Harder on the development mailing list)
I want to bring everybody up to speed on some name shuffling we are
doing with our “Core” releases.
CoreCDX is now our primary public “Core” release. Users who want to
install a minimal Sabayon Linux version should use this version with
the graphical installer.
The CoreCD has been renamed “SpinBase”. It’s primary purpose is to be
our internal “Base” for building up automated “Spin” releases. It
will be publicly available to anyone who wants it (primarily
developers and molecule users), but will not be advertised as a
The upstream maintainers of Anaconda have drastically cut back the
functionality of the Anaconda installer with respect to console-based
The graphical installer is working great, and has updated some
capabilities to handle new hardware. But the console-based text
installer has lost the ability to custom partition an installation,
and is primarily directed at installing to an empty disk. Inattentive
users who are used to the previous text-based installer run the hazard
of overwriting their entire hard disk.
During this release cycle, we’ve been struggling with how to handle
this change in our installer. We’ve developed CoreCDX as a release
intended for end users who want a minimal Sabayon Linux system with a
robust, easy-to-use installer.
The CoreCD is still extremely important to Sabayon as we evolve our
“Spin” releases. But it has become of marginal value to end users due
to the limitations of the text-based installer. And, the text-based
installer as it exists now will confuse users and perhaps lead to lose
of data for those expecting it to function like previous releases.
So we have renamed the “CoreCD” to “SpinBase” since the name was too
close to CoreCDX, and would lead to confusion. As previously noted,
it will be publicly available, but not promoted as a “release”.
So, to summarize:
(1) CoreCDX is our new ‘minimal’ release for users who want a
stripped down Sabayon installation.
(2) SpinBase is a release primarily directed at developers who want
to use molecule, and also an important internal release.