These last few days have been the days of updates for me. I noticed I still had KDE 4.5.1 rpms that I hadn’t pushed too the Unity KDE 4 Channel. Really the only thing holding me back was building language packs (kde-l10n) a script later on my build machine and they were all updated and done. In case some of you don’t know the Synergy KDE 4 Channel that is ran by me separate from Unity KDE 4 is like a testing or staging Channel. I normally keep packages residing on the Synergy KDE 4 Channel some times for a few weeks before syncing them with Unity. I Like to run them a while and allow a few others too just to make sure there’s no major issues. There wasn’t so they got synced, a little later than I would have liked but 4.5.2 is just around the corner and I’ll have time to prove myself. I’m really in no rush, just waiting for the binaries to show up on my favorite kde ftp server and I’ll start the scripts up. In the mean time I’ve been going through all the source packages in SVN and updating to the most recent version. Good times so far, most likely a lot of these updates will hit the Unity KDE channel pretty quick as a lot of them are just small updates to an already stable existing version.

So anyways you should see updates coming down the pipe for all QT4 and KDE 4 related packages. please as normal let me know if there’s any issues.


Mandriva Fork: and Unity

September 20, 2010

It seems a lot of the old Mandriva employees have decided to create there own distribution that will of course be closely related to Mandriva but not MandrivaLinux S.A. The new name is Mageia which means Magic.

There have been a few post and a few people who have wondered about what will happen for the Mandriva based Linux distributions if Mandriva was to go away. Now in the current case if Mageia fails or takes for ever to come up with development structure ie. SVN, BuildServers etc.. What will happen with Mandriva will Unity be based on Mandriva or Mageia?

First let’s start with a little history. Unity Linux started as a fork from PCLinuxOS during the early development stage it was decided to rebase on Mandriva and maintain our own repositories, more specifically Kernel, Xorg version, Window Managers etc.. So we created a SVN repository and started importing packages from Mandriva changing spec files, taking out epochs, adding patches, and updating source. Then the decision was made to use RPM5+Smart dropping any option for urpmi or apt-rpm. Once again packages were rebuilt, so Unity uses it’s own version of RPM and maintains it’s own repositories using smart too install and manage packages.

So now we have some things that are very similar to Mandriva like drakxtools that are basically patched to use SMART instead or URPMI. We have become pretty familiar with drakxtools and themed it for Unity etc.. but it’s still drakxtools and we still sync the source (like we would do with any project) to Mandriva when there’s new upgrades that are worth the time in testing. We also follow PulseAudio pretty closely as it’s no secret that Mandriva has one of the best implementations. Even more on our BuildServer we can pull source packages from Mandriva SVN and build some (very few packages) will little or no changes. We tend to shy away from Epochs though, even though we have some packages that still have them. Yet Mandriva has no issues using them.

So is Unity dependent on Mandriva? Yes too a point we are. We like their configuration tools (some times) and with some packages that really are straight forward to build we may import from Mandriva SVN. However these are just niceties. The real question is could we survive without Mandriva.. Yes we could and may have too until they get a clear direction (for that matter survive) or the fork gets off the ground enough so we can pull and push packages for them. What will this mean? In our case packages may not be updated as fast as normal, because packagers may have to take on a few more packages.

In the long run though if Mandriva does survive and Mageia gets off the ground Unity will have more resources to pull from. Our plan is to not use just one for resources but both. There’s rumors one may choose to upgrade to RPM5 (which will be fine for us) and may even drop URPMI for SMART. Now this is all speculation but in any scenario it seems with time Unity will turn out better off than before. So should the Unity community be worried no, just offer help where you can and test for us and we’ll be good.

Some ask why not just disband Unity and Work with Mageia? Well the reason we have created Unity is too allow more advanced Linux users a core or ground work to create their own distribution. That is our focus. Our focus is not desktop use, or even end users. Someone who uses Unity for it’s packages and core though may decide to create a community driven distribution with these focuses and we will be very supportive of that. We call such project branches and are very friendly to branch maintainers. However if we were merge our efforts at Unity with Mageia than we would loose our focus and direction that we have all come together to create. Unity is a much different concept and a concept we are quite happy with.

Hope this helps expel some fears 😉 and explain why at the very least I am very much excited about all of this..

The Pre Beta Release of Synergy Linux Code Named “Identity Crisis” has been released. The official announcement is here:

Identity Crisis

Today I patched kdebase to have webcam image support for kdepasswd. This patch simply allows the user to take a picture of themselves and use it as there User account icon in kde4. If you don’t have a webcam plugged in or detected then the button will stay grayed out. This patch obsoletes the kcm-useraccount package that has now been retired.

For screenshots and more information see:

KDE 4.4.2 Packaging.

This weekend I have pretty much finished packaging for 4.4.2. It’s a little later then what I wanted it for a few different reasons.

1. There was a Akonadi MySql issue that I think had to do with the lastest Mysql update on the mirrors. This was reported by Steve who was very patient. Eventually in his case we ended up having to delete the ~/.config/akonadi folder and reinstalling the akonadi packages. Fortunately he had no saved data in akonadi so nothing was lost. I still haven’t been able to put my finger on the issue as it seems on some of my machines Akonadi complains and in others it doesn’t. There was a patch I found from fedora that gives the path to the innodb plugin for Sql. That patch has been applied and maybe that’s why it worked on some of my machines and not others.

2. I only have so many build machines. The last group of packages I normally do are the language packs. Using the bldchrt script with the Unity build package this would take forever because I was using bldchrt -xb-crk, this causes all the requires for each build to be installed and removed with each package. So a majority of the time to build was being taken by installing and removing packages each time and these are the same buildrequires that are need for all language packs. I knew there was a better way but decided I’d just let it build it couldn’t take too long could it? 24 Hours later it’s still building and I bring it up to Matt and of course I could have used bldchrt -b-rckl which keeps all the buildrequires installed in the chrooted environments and then you can simple clean up with bldchrt -c “rmp -a”

Now the only thing left is too build the kdesdk package. I am running into a few issues with it and I’m wondering if my latest cmake update will fix it. We’ll see. At this point though everything is very usable and the older kdesdk packages will work just fine so it’s not a show stoppper.  Have fun!

A Quiet release

March 1, 2010

KDE 4.4.1 Was released yesterday so quietly I almost missed it. Right now I’m building the base packages for 4.4.1. There’s nothing ground breaking about it. Just some fixes to kmail might be noticeable if you’re a kmail user. There might have also been a few stability improvements too a few favorite plasmoids. Other then that it’s pretty mundane. What you may notice if you keep track of the repository or is the influx of applications. There’s at least one new Qt4 or KDE 4 based application added each day (normally 3 or 4). Make sure you check out for new applications for Synergy/Unity Linux and even news on updates.

Wow! It’s been a crazy month so far. Stepping back and looking at the waters surface I’m sure to the Linux community the waters of Unity Linux look calm, but underneath the surface has been a fast current, a current of change and progress. Some pretty important stuff has gone down this month.

KDE 4.4 Progress
We (Synergy Linux) released our KDE 4.4 Packages that are heavily based on Fedora, Mandriva and Suse RPMS. Not soon after our release we were gobbled up by Unity Linux Main. What I mean by that is our packages from Synergy SVN were imported into Unity SVN. Synergy Linux has now taken over the development of KDE 4 for Unity Linux and we maintain the unity-kde4 repository now that is mirrored around the world. I have opened up a issue tracker for these rpms. Sorry but for now registration is required at, but if you’re really serious about helping us out please register and post your issue. You can also give suggestions and keep up with the latest packages that Synergy-Linux is packaging for Unity Linux.

Unity Base Install from RPMS
Although updating to KDE 4.4 is progress for me the real progress comes with what’s currently being tested and worked on by the Unity Core team. Currently with most LiveCD distributions a base install of a parent distribution is needed. A known example would be PCLinuxOS’ relationship with Mandriva. In the case of PCLinuxOS they (at least used to) start with a Mandriva 32bit release update it with their rpms and changes (themes and optimizations) and then use a livecd creation tool. In a few days hopefully we’ll see that’s how things used to work at Unity Linux. With the new method now being worked on there’s no need to install a parent distribution. You quite simply use the rpms that are already in the Unity Linux repository and create your remaster, livecd, or branch from there. For Unity Linux developers this cuts a lot of time out of creating releases and for branch maintainers it allows more control in the creation process.

Look for a release out soon using this method