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 is back up. I was using a home machine to to host my site, however with the latest Alpha releases and the latest builds of KDE 4.5 RC 3 I have decided to try and make my home machine more the work horse and less the file provider. This is better for my home Internet connection and it’s better for those downloading ISOs or packages as it will be much faster with the host I have gone with.

Currently I have packaged KDE 4.5 RC 3 and KDE Pim 4.4.5. A Vast majority of packages have been updated and can be found in the repository for those who want to test if you would like to connect to the new server it will be up soon and I am more than willing to support those who want to test.

Synergy Linux Latest Release
Currently Synergy Linux is at Alpha3a we’ll be moving to Alpha3b tonight which includes more video drivers and wireless drivers. Alpha3c will be pushed out some Tomorrow or Thursday and unless there are major issues still it will the be last Alpha release.

Moving on to Beta
A few things will be focused on during the Beta series. A further investigation will be put into KDE 4 running in our compressed mode. Comparisons between gzip and lzma compression too see if it makes a difference in memory and ramdisk allocation will be investigated. Further investigation into running KDE 4 with less than 512 will be looked into. Swap is a first suggestion some will make. However performance has to be key in this scenario and a lot of testing and test cases will need to be thrown at such a feature. In my attempts I have found that when the system starts swapping to slows down quite a bit. However, further tests will need to be done. If it ends up working it could be a viable USB solution and the installer could create a swap partition quite easily with the needed amount of memory to run and allocate most of ram to disk space and the rest of the USB for persistent file storage. Cosmetically a new theme and background will be released and witht he exception of minor improvements and tweaks should carry into the first official final release. Late in the Beta cycle, packages that allow remote use and enhance netbook functionality integration will be the focus. is gone

Well is down and will be for a while. At the time renewal came up, though not costly I couldn’t part with the moneys for various reasons. However was really just a portal for packaging work that was being done for KDE 4, Synergy Linux, and Unity Linux. is ran by Richard and is really the work horse for forums and community interaction. So one could argue not much was lost, well really nothing was lost but a few forum entries because a new blog can be found at this is a webserver I have that hosts rpms and a blog off my home ISP. Here’s my plug for Qwest, they may not be the fastest ISP, but they don’t block ports, so I have had it pretty easy not having to do port forwarding etc.. to get things going.


So right now there’s controversy in Unity Linux, well at least in my mind. I kinda feel that we have been focusing on updating more then stabilizing our current repositories. Now I very much could be wrong and I realize if anyone has been following the Mailing List they can see how harsh I can be, but much like some of our devoted users I really just want a stable release out already and I feel that over a year to create one is enough. I do understand how far we have came though and how much work it has been, a majority of it I haven’t really helped with so I’m sure backlash for the above statement is warranted. However I feel most if not all of the pieces are in place. Here’s an over view of all the work that’s been done.

  • The Tool Chain :The team started out with a PCLinuxOS base and quickly found that for the direction we wanted to go the toolchain was too old. Instead of updating the PCLinuxOS base it was easier just to rebase off of Mandriva’s tool chain. From that point packaging relations started to quickly drift away from PCLinuxOS.
  • RPM5: It was decided that RPM4 was becoming outdated, there were certain features and future visions in RPM5 that were attractive. Despite some views of the RPM5 maintainer, communication between Unity Linux developers and the RPM5 team was established and it was decided almost unanimously that RPM5 would replace RPM4. At that point rebuilding rpms with RPM5 meant that no other RPM4 distribution (ie Mandriva, PCLinuxOS) could use our binary RPMS. Unity Linux though can still install RPM4 based rpms though. This is just a symptom of using RPM5 it’s backwards compatible but not forwards compatible. It should be noted though that everything needed to still build a RPM4 based binary rpm can be found in Unity Linux SVN.
  • Smart: PCLinuxOS used Apt4rpm and the used Synaptic as a frontend. Development for both Apt4rpm and Apt4rpm support in Synaptic was done by Connectiva and once Connectiva was bought by Mandriva development slowed tremendously if not some feel halted. I’m not sure on the status now, however to ensure a future without the work of maintaining both apt4rpm and support for it in Synaptic a different package manager and gui had to be chosen. So Smart was chosen for its versatility and power, however not so much for it’s gui (graphical frontend). The good news is with 1.4 new frontends for GTK and QT4 will be available so it was a wise investment in hindsight.
  • Buildtools: mklivecd revolutionized PCLinuxOS and really the early adoption of it is what I feel lead to the success of PCLinuxOS, but now live distributions are almost the defacto and there’s multiple methods some claim easier methods. So now at the imaging level linux distributions are easier to create by users, however packaging a more detailed task can still be elusive. To try and help solve some of that elusiveness some awesome people on the Unity Linux team created a set of build tools. One can download a package from SVN update it, know a little about updating a spec file, and build with the build tools automatically update the changelog and find, download and install the buildrequires all with two commands. More advanced users can even setup a build environment and build for multiple architectures with one command and a few flags. Using SVN allows a more open way to display source and using the build tools (once understood) simplifies the build process. SVN access coupled with the Build Server (a web interface to a build system) now allows even a point and click method to build packages
  • MKLiveCD: This is most likely one of the most controversial projects the Unity Linux team has adopted. Within the PCLinuxOS community even by the highest raking members it’s been expressed that MKLiveCD was stolen. I’m not sure how any opensource project can be stolen, normally that’s called a fork and that’s how opensource works. In no way has Unity Linux stole anything development has been open and published online since the initial announcement that work had been done. Some of the biggest changes to that of the MKLiveCD that existed at that the time Unity Linux was formed is multiple architecture support (right now 32bit and 64bit is supported) and support for kernels greater than 2.6.31. That’s not to say that PCLinuxOS hasn’t done their own work on their version of MkLiveCD (now referred to as MyLiveCD) but at least with their last release 2010.1 no 64bit version of the distribution was offered. Granted they still may support it in MyLiveCD, just not have the 64bit packages to create a 64bit version. This is one thing that testifies to the Unity Linux Build System and can be seen on the Unity Linux Build Server. When you build a package it builds for both popular architectures (32 and 64bit). It’s also obvious that they fixed the issues with going to a kernel higher then 2.6.31 as their current kernel is and pretty fast from what I’ve read.

So it’s obvious (at least to me) Unity Linux has everything in place technically to be a success, whether it’s chosen to continue to release a minimal release, or too keep to the original plan to just offer a base repository and set of tools to allow other to create their own customized distributions (branches) and use Unity Linux as their core. At this point the only thing in my mind that’s holding people back is the announcement of a stable base and freeze on the stable repositories to allow people something stable to build from. This is not so say development shouldn’t continue on a unstable repository.

At this point my plan would be a SVN and RPM repository freeze. Create a copy of the current SVN repo and call it Cooker, Baker, Unstable, Mulched  or what have you and have all current upgrades to there until the next stable release. Work on the current SVN to fix bugs and only allow upgrades to CRITICAL issues, as in A program won’t work at this point unless B is upgraded. Create a LiveCD from RPMS based off what’s in the current stable SVN and RPM repositiory. Test and do major QA, very few packages should be updated at this point even in Unstable Cooker. Packages at this point should be making sure all the packages they are responsible for are in working order and tested. Release any given number of test releases every week to few weeks to the community to test with a general direction of what to test and look out for. Allow input on a forum and major issues reported that can be fixed should have a issue on the issue tracker assigned to the next current release label. However no matter what the next release should come out in a set time unless it’s a critical issue affecting a majority of testers.

I think this or a similar process should be done and very soon and it should be outline on whatever form of external media that’s related to Unity Linux

KDEPIM and Kmail 2

It’s been decided that the KDEPIM team will not release a new version till KDE 4.5 RC1 all of the Beta versions will be using KDEPIM from the 4.4.x series. Just thought I would let everyone know so it’s written somewhere. 😉

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!