Enlightenment just announced and released an alpha version for their “EFL” Enlightenment Foundation Libraries. On Unity Linux in the past to get the most recent stuff from e17, the HUMANity remaster would use the easy_e17.sh which would go out and download an SVN snapshot of Enlightenment and install it to your computer. The problem you run into with this way of installing is that the package management system is not aware of what you’ve installed…after all, they’re not RPMs.

Wouldn’t it be great if the latest and greatest were available IN THE REPOSITORY for Unity users to install? The Unity developerswave a magic wand above smart repositories IT IS NOW! Currently in unstable repository for your testing pleasure are all of the packages that easy_e17.sh would download to build and install for you. We’ve made it so that smart can manage things for you. Once things are tested a bit we’ll shuffle it back to the e17 channel…but until then it will remain in unstable.

To install, enable the unstable repository and look for task-17 2010.2.

Plenty more goodies on the way of course…we’ve got some under our belt and are getting ready to make a few more notches on said belt. Currently in the PLF repository is the google-talk-plugin. A recent addition is Wicd and we need people to test it out. On the heels of wicd, we’re working on network manager AND testing functionality with it plugged into the drakxtools from Mandriva as a replacement for net_applet (Mandriva is also testing this). So, lots of interesting things happening…not just cutting edge Enlightement goodies Thanks for using Unity and have fun!

The developers at Unity Linux have been working hard on expanding our package repositories. At this point, there are well over 8600 packages for each of the i586 and x86_64 architectures. Considering that our development team is still relatively small, this is quite a feat. One reason for this accomplishment is the establishment of standard procedures for building the RPMs, adding them to our repository, and promoting packages from unstable/test channels to the packages’ intended channels upon successful testing. The added benefit of this process is that it is very easy for new packagers and contributors to add content to Unity Linux. However, ensuring that every packager follows the standard build procedures has been somewhat difficult … until now.

The Unity Linux Build Server

One of the new additions to the Unity Linux packaging process is the introduction of the Build Server (or buildserv for short) The main purpose of the buildserv is to provide users with the ability to package content following our established procedures without being burdened by the overhead of doing so. The buildserv really consists of two parts: a backend server and a frontend web interface.

How Does It Work?

The frontend is a secure web interface to our standard build environment. Once an account is created for the packager, they can log into the buildserv and, with a few simple clicks, be able to select any of the packages they have recently committed to SVN, and schedule them for building. The actual RPM building happens by the backend server which processes the queued up requests. With the help of our chroot-based standard build environments it generates the i586 and x86_64 arch RPMs automatically. The success or failure of this build, as well as the details of the output are then accessible to the user from the web frontend.

This takes care of the initial packaging aspects of the buildserv. However, the full capability of the build server is far from over. If the RPMs for the requested package(s) were successfully created, the backend server then automatically transfers the files into the Test channel of our repos and cleans up any duplicate/obsoleted RPMs. Moreover, the buildserv can then promote these RPMs from the Test channel to the intended channel once the RPMs are deemed stable and tested*. In other words, much of the burden of tedious maintenance of packages while they are in the repos is removed from the shoulders of contributors, freeing them up to do more useful work.

Why Is the Buildserv Important?

Anytime you automate tasks there are benefits to those users and developers who would normally perform those tasks manually. In this case, the Unity Linux developers and contributors will save the tedious tasks of RPM building by the automated buildserv. In other words, packagers will be able to package more because of a huge time saving. This also could translate to more RPMs and packages for end users as developers may take on more packages due to the automation. When end users request a package it will be a few clicks of the mouse to get it into testing. This is a huge benefit for developers which is passed directly to end users through time savings.

The future of buildserv

There is still much work to be done on the buildserv. Currently, many of the administrative tasks cannot be done over the web interface (will only be available for users with admin privileges); the web interface itself, was done with quite primitive HTML and can use a modernized face lift; the frontend can use more cross-linking to improve usability; the backend still needs to be improved for synchronization with our repo content; the backend needs to be made PLF aware; etc.

There are many more features and improvements that will happen soon. Nevertheless, the build server is already gaining momentum and is on track to becoming the next big hit for Unity Linux.

* This capability is currently being worked on and is not yet fully functional.

What to write/right. I have been trying to get back around to posting a blog every once in awhile. It’s hard because I have so much going on in regards to the distro and trying to get it to pick up traction. We are really starting to make good progress on what I would consider a truly open community based distro.

Mirrors: We have found an abundance of freely hosted mirror around the world thanks to Paul’s and others work. With the addition of smart-utils and the upgrade of smart to version 1.3, our package manager problems have really been minimized.

Package Requests: This has been one of the aspects that has occupied much of my time. Since the rc1 release I have gotten a constant stream of requests from the IRC channel, forum, Mail Lists, and personal contact with others using Unity Linux.

Upgrades & Fixes: I have also done quite a few upgrades to core packages along with others devs that have corrected some off our gfx card, wireless cards and other application bugs.

Build Server: With the developments happening to the BS and our constant improvements on the pkgutils suite. All contributors builds and those without he capability to build both arches should soon start filtering throught the BS. Also, we have perfected our method for creating chroots for building or creating the livecd iso.

Open Communication and Collaboration: We have had some success in this area despite many attempt to heal old wounds. Yoper and Unity Linux have found ways to share resources on a few levels that are beginning show beneficial to each other. I will continue to try to reach out to other rpm-based community distros and see if there is not more that we can share and learn from each other.

So, I purchase a brand new build box last week and I am finally be able to build x86-64 rpm binaries. It has been a slow start getting a 64 bit OS (mdv2009.1 from boot.iso) installed and then a chroot jail build environment setup where I can build and install rpm5, mezzanine and caos-builder.

I am finally coming around on my third pass through the svn repo and over half of the packages are now successfully built. I will probably let the autobuilder make one more pass through the svn repo before I kill it and try to reconstitute a native Unity-Linux chroot jail environment and start over on rebuilding the packages cleanly without old Mandriva build dependencies.

Needless to say, the autobuilder (caos-builder) for unity linux is now working and can be applied in the future to build both 32bit and 64bit unity-linux rpms.

I remember when we started to put together lists of SRPMs that needed to redone/update/etc to break the dependency from pclos. At first you could build packages, but you would still have to use the pclos repos. Slowly, we started making head way and it became less frequent that you would need to pull a build requirement from the pclos repos.

Now, we are completely free of those chains, and it’s pretty much open season, for maintaining and building your favorite applications. You still have to import packages, but they are not the long list of build dependencies that we once had.

Just to give an example. I recently built mozilla-thunder and wine for unity, and I hope to have miro ready for the repo soon too. Also, it’s nice to see new releases of applications like Firefox 3.5 make it into the repo so quickly!

I say this because, everyday Unity is becoming more useful as a desktop or a core for whatever one may want to use it for. As we are finally narrowing down our selections for the logo, that means we are getting very close of an official alpha release. We are at an exciting time of what will be an explosion on the Unity Linux platform. It will be interesting to see what the near future has for us in-store.

Since the last iso seem sufficiently solid, I decided to focus on the logo.

There are over 200 logo designs to sort out. The GFX guys were busy. I was hoping to have the first set of voting underway early this week but it looks more like it going to be for the end of this week.

This is the remaining major issue preventing us from having our first official alpha release so things are looking good. There are other minor issues but those can be dealt with during the alpha release stage.

On another subject, I was able to install kde4 simply by installing “task-kde4″ from Smart package manager. Gnome packaging has started and is shaping up nicely. I need to go through XFCE to complete the missing packages so that it become available for installation.