kde » The Blog From Hell

How the kongoni KDE ports work

Jan 062009

This post is meant to provide an overview of how the KDE4.2 ports in Kongoni are structured, how they differ from Robbie’s original SlackBuild scripts and how they are (best) installed. Furthermore I hope that this will also provide a deeper level of insight into the overall workings of the kongoni ports tree and help others after the baseline release who wish to work on other big port collections (such as Gnome for example).

Beneath the kongoni ports tree lies a desktop directory, this directory currently contains only one subdirectory kde4 but we hope to expand it with other desktops at a later stage.

There are basically four directories below that: deps, kde, kdemore and kongoni_kde_desktop.
The last one is important because it’s in fact a port. It holds a meta package that while devoid of almost any content of it’s own (it literally just installs some basic docs like a README) depends on all the packages that make up the KDE desktop as it will ship in the release disks.

The current kongoni_kde_desktop package is versioned: 4.1.85.1 the first three numbers (4.1.85) indicating the KDE version it is built around, the final one the specific version of the kongoni kde desktop built on that. Thus if we add theme packages or fixes, only the last number needs to change to allow a user to upgrade only what has been modified.

Portpkg has no ordering for dependencies and will, lacking other information, simply install the in alphabetic order, so this by itself is not enough to ensure the ports are built in the right order, it is just enough to make sure the right ports get built. Each ports own internal dependencies come into play for determining build order and the ports have carefully constructed dependencies on each other to ensure that each builds before the ones that need it.

The simplest of the other three directories is kdemore. This directory holds those KDE ports that, while part of the official KDE release, is simply too big or too niche-use to go into the live cd. These packages cannot be built without the rest of KDE there and thus they all have a listed dependency on kongoni_kde_desktop but kongoni_kde_desktop will not make any attempt to build or install them. Those who want a particular package from this set, can easily do so with a single command: portpkg -n PACKAGENAME

The packages in kdemore are: kdeaccessibility, kdeartwork, kdepim, kdeutils
All of which are useful packages that many people use, but also packages that not everybody needs and some of which like kdeartwork take up a lot of disk space. Since we are intending to do our own theme for the final release, it makes little sense to ship all the stock artwork in the base install, but it does make sense to keep it available for those who want it. The default theme and artwork is included in kdebase anyway.

Next up is deps, everything in deps is installed by kongoni_kde_desktop, this location came from the fact that these packages were kept separate in slackware as they are not part of the default slackware distribution. However most of them should ultimately move up to the base or libs directories. Currently the only known bugs in the ports tree are in fact in this set, specifically with boost and QScintilla. The bug in question is that both these packages do things with their build processes (not in the port scripts, in their makefiles) which break when run under fakeroot. They install fine if you run the SlackBuild script as root, but currently the ports cannot finish building. These need to be fixed before we can reorganize the deps into their appropriate locations higher up in the tree.

Finally, there is the kde directory, this one holds everything our default desktop needs to have installed to function properly. It is basically the remainder of the KDE tree, we had a lot of build issues inside the ports with earlier version of KDE but the 4.1.85 packages have built brilliantly. The packages in kde are:
guidance-power-manager, kdeadmin, kdebase-runtime, kdebase-workspace, kdebase, kdebindings, kdegraphics, kdelibs, kdemultimedia, kdenetwork, kdepimlibs, kdeplasma-addons, lancelot

Some of these are of interest for further discussion. The first is guidance-power-manager which is in fact not part of the stock KDE distribution but comes from extragear. This is included in the slackware version upstream too and for good reason, it provides a solid power management suite for laptops built on… well solid. There is room for some debate about kdemultimedia and ultimately it may actually be moved to kdemore though it does contain the awesome dragon movie player and unless I were to stumble across a truly phenomenal alternative kde movie player, I am likely to keep it here (though of course it could become a case of splitting dragon out into a separate package – I’ll hash this debate out with my fellow developers after the baseline release.

You may wonder why kdepimlibs is in kde but kdepim is in kdemore. The reason is in fact a simple matter of dependencies. You need kdepimlibs to build support for PIM interaction in several other parts of the suite, even if you don’t install the PIM utilities it’s good to have the support for them in built into the desktop so that those who do, can get their full benefit.

Another possible trim-out is kdeplasma-addons, having plenty of nice plasmoids available in the live cd is a good way to make the desktop shiny, but it’s also a rather big package and the very important core plasmoids like folderview and the panel are in the kdebase-workspace anyway. So it is quite likely that ultimately this may move to kdemore, depending on how many of the plasmoids in there actually get used in the theme (again, splitting it up into smaller packages for this purpose is a future possibility).

Finally, there is lancelot. Lancelot is Ivan Kucic’s alternative menu system for KDE which I always intended to be the default on kongoni because it’s a really awesome menu system even if it’s not part of the stock KDE distribution. Right now it’s dependency has been removed from kongoni_kde_desktop however due to a version incompatibility in lancelot (the stable release can only build on 4.1 and the svn trunk release cannot build on the beta as it needs features added to trunk later). This should be a fairly simple problem to resolve in kongoni_kde_desktop 1.4.85.2 but in the meantime I did not wish to hold up the entire process.

I hope that this overview of what lies in the KDE ports give an idea of how things are structured, the thinking behind the structures and of course why it took so long to get this far. The good news is maintaining the ports from here on in will be fairly simple and this was the bulk of the effort. I would go so far as to say that getting the KDE ports working fine was the single biggest task in kongoni I would ever do (well have done by now) without help – since I could not release the baseline without it, it was impractical to get help on it but the remaining work on the baseline is very small and once it is out, many hands are waiting to help pick up the load.

Share|

Text dragging on (K)ubuntu considdered harmful now ?

Diary No Responses »

Dec 022008

My home machine, as I’ve said before, runs Bluewhite64 with KDE4.1.3, it’s basically a bit of a preview of what Kongoni is being built from. My work laptop however runs Kubuntu Intrepid also with KDE4.1.3. Now overall I’m actually quite happy with this kubuntu release, it’s certainly the first one that shows polish even remotely comparable to it’s gnome counterpart so that’s a good thing.
Unfortunately, it has one seriously annoying bug. Selecting and dragging text in firefox is a CPU killer, I know this is neither a firefox nor a kubuntu bug since the problem doesn’t exist on my home machine. It’s something specific to this machine, or this release of Kubuntu.
What happens ? Well select some text and drag it – you don’t even need to drop it anywhere – just letting go of the mouse is enough, the system freezes while the CPU works incredibly hard for several minutes and then finally drops the text (if you didn’t drop it somewhere else, back where it was) before returning to normal.
During this time, the rest of the system is completely unresponsive, you can see the text moving incredibly slowly over the path the mouse followed before finally dropping and then the system recovers. Now just why exactly this is slow I haven’t been able to figure out conclusively – but I have a theory.
This machine, unlike the home machine, has full XRandR1.2 support and really good XRender support, and I think firefox is using XRender to draw the text when it’s being dragged – and I think it’s buggy with the way it does that. It doesn’t happen at home because nvidia’s xrender support sucks so bad that firefox doesn’t even try to use it. But if firefox is using it this badly – it would have been better not to use it at all.
So by my theory, the problem is with firefox on intel graphics cards that support full XRender. By that logic – the problem needs to be fixed either in firefox or in the i915 driver. Since both are FOSS code – this should be doable. Hence my decision to post it here. It would be good to know if anybody has similar problems, and on what video cards – if it’s happening for you on something that doesn’t support XRender then it suggests the problem is confined to firefox, if it happens for you in other apps – it means it’s something at library level in Kubuntu. The most likely combinations are similar hardware but other apps, same apps on different hardware or same apps on same hardware. Getting some feedback on which scenario’s are out there will help track down who to file a bug report with at least.

Share|

Announcing Kongoni: A call for volunteers

Diary No Responses »

Oct 292008

Today I posed this message to several of the LUG’s in South Africa. I am reposting it here without edits.

Hi Everybody,
Sorry for the cross-post, I promise it’s a once-off but this is a bit of a special circumstance.
In the grand tradition of GNU and later the Linux kernel, I am beginning with a mail to announce
my intentions, and a request for anybody who shares my vision to help out.
The interest in my CLUG talk about distribution creation some time ago left me thinking that
perhaps there are enough people out there (particularly here in South Africa) who may feel up to
the fun and work of helping to create something special. Having spent 5 years creating a
successful commercial distribution, I believe I have the skills for such a project to be workable, though this one is meant to be very different as you’ll see.

Starting in the next weeks I want to create a GNU/Linux distribution called kongoni. Kongoni is the
Shona word for a gnu (wildebeest) and this represents the origins of the system: firstly it is African,
secondly it is meant to be a truly free distribution of the GNU operating system.
The name in other words translates literally as: GNU Linux (I rather like the wordplay as well).

Fundamental to the design will be an absolute commitment to free software only. That means we will not
include in the installer, nor in the ports tree or any other officially distributed packages any piece of
software that is not under an FSF approved license.
Some degree of the workload can be shared by utilising (and contributing back to) Gnewsense’s list (and blacklist).

Development releases will have a kernel compiled with the no-taint flag – not allowing any non-free drivers to load,
which will be very useful for auditing purposes, where possible we will provide free alternate drivers.
UPDATE: I should have been more clear here. I mean ONLY development releases will have notaint, official releases will not restrict what users can or cannot load.

Where possible I want the system to actively contribute to high-priority free software projects like GNASH and Nouveau,
not least by providing automated scripts in the packages to allow even non-technical users to file automated
bug reports to the projects with usefully information for their needs. Thus possibly increasing the number of testers
exponentially, the improvements that arise will in turn benefit all free software users and developers.
The system will never be commercial, I have no problem with commercial free software (in fact I run a commercial free
software company) but this project would best benefit from being a true community project. If the need arises to
formalize structures, I pledge that it will be done by registering a charity organisation, or joining an existing one
– not by starting a company. If people some day want to start companies that sell services related to the system however
more power to them.

Now on to the initial technical details. First off, I don’t think there is any room in the market for yet another Ubuntu
respin. Ubuntu is a nice system in many ways, but the need is met – and Gnewsense already provides a fully free alternative
to fans of Ubuntu. Instead I believe there is room for new ideas and new thinking.
To this end I want to start with a slackware/bluewhite64 baseline initially targeting x86_32 and x86_64 platforms.
Slackware has many advantages as a baseline and offers enormous power of (easy) customization to give the system a real
unique identity while staying true to standards.
The biggest catch is addressing slackware’s number one shortcoming for desktop users: the limited package manager.
To address this, and also minimise the workload of multiple platforms, I intend to use portpkg to provide a ports tree
that is fully tracked for dependencies. Among my first coding tasks will be a full graphical frontend for portpkg as well
as a series of patches to portpkg itself to allow us to maintain our own ports trees as default. These will consist
of license-audited and dependency-mapped clones of the slackware/bluewhite64 repositories for upstream, and source-only
ports for 3rd-party packages. It is important to maintain our own ports tree since unfortunately all the default ports
available in portpkg include non-free software in their package lists. While we cannot (and should not) prevent users
adding those repositories and installing such proprietary packages – we should not give this action any official support.

The initial default desktop will be KDE4 with intention of including KDE4.2 (due in February) in the first stable release
if possible. OpenOffice.org 3.0 is on the standard packages list, and if the promised GNU/Linux port of Chromium is available by
release time it will be the default browser, otherwise one of the free firefox forks.
An absolute must is a powerful and complete system administration and configuration tool,
utilising things like darkstarlinux’s ALICE suite to complement a full kit for user-admin,
setting up advanced Xorg settings (like multiheads) and other common admin tasks. To ensure
seamless wireless and wired network roaming, wicd will be a default package (and madwifi with the new free ath5k hal for older cards and the newly GPL’d hal from Atheros as well).

It is quite possible that if we have enough volunteers and resources future releases could include parallel versions for
Gnome,xfce,enlightenment etc. and I am happy to include these in the ports tree if somebody helps create the ports.

In terms of project admin I wish to set up a suite of easy-to-use web-apps for contributing, auditing and approving
of ports (the first should be open to all, the latter two to trusted testers only). Designed to make the task
of contributing in this manner not only as simple as possible but to minimize the time needed as far as possible so
that those who choose to contribute their spare time to it can spend as much of that time as possible doing fun stuff
and as little as possible doing drudge work.

The focus of the project is home and desktop users, there are other distro’s aiming at this market but precious few
with a stated mission to be completely free, in both senses of the word.
After freedom, our second most important design principle should be one of “it just works”.

Now of course, as I type this Kongoni is vapourware, the first line of code has yet to be written (though I’ve done
significant amounts of research to make the decisions above, and I have written an installer).
Normally, it isn’t my style to announce something until the first pieces are written but in this case I
find it crucial to the very concept that other people be involved from the start. I have proposed a vision
(not an uneditable one technically) and I want to see who shares my vision and would like to contribute to it’s
realisation. I will be happy to fund hosting for the project and contribute much of my free time to it’s realisation
but I would like to have as many people helping as possible so that this is not just my vision, but our vision.
People who can suggest ideas and improvements, people who can help realise those ideas and help with the
large workload ahead.

If just a few people say “I’m in” – then that’s a go-ahead as far as I’m concerned.

The most useful skills right now will be:
*Web-app programming and web-design
*Ports builders and co-maintainers of the tree
*Graphic design
*Testers

These will likely get official lieutenants appointed on a first-come, first-serve basis.
There is much more to do so if you feel that you can contribute something please feel free to speak up.
If any of the mirror maintainers would be willing to host local mirrors of the ports tree and ISO’s when
we get to release time, please let me know as I have learned from hard experience how even a small distro
release can hit a server.

May I request that those who wish to contribute also reply to me directly as I do not want any
names to get lost in the noise as people discuss the idea.
Finally, I would like to suggest that those who are in Cape Town (once we have a list) meet up
for a face-to-face planning session. Perhaps over coffee on Saturday somewhere in Rondebosch ?

Thank you for reading this far
I hope to hear from you.

Ciao
A.J.

Share|

What’s nouveau with nouveau ?

Diary No Responses »

Oct 272008

I finally decided last week to take the plunge and try the nouveau driver out. My feelings on proprietary drivers like nvidia’s are well known by now so I doubt there is anybody who will be much surprised except that I took so long.
RMS has said many times that the only time it is acceptable for somebody who believes in free software to use proprietary software is when (1) there are no usable free alternative and (2) you are also contributing to the creation of such an alternative. Thus the use of the proprietary only program is just a temporary stopgap – and you are making an effort according to your abilities to ensure it remains temporary.

Well there are four pieces of proprietary software on my computer (that I know about – if something else slipped through I haven’t found it but even gnewsense has trouble finding it all – and if I haven’t found it then the implications if that I don’t use it). The first is the BIOS, well there isn’t much I can do about that right now, opencore doesn’t support my motherboard yet, and since it’s not a dual-bios motherboard there is no way I can help fix this without bricking my computer. The second is java, which is not major concern to me since it’s 90% GPL’d already and the remaining ten percent will be GPL’d by April if SUN keeps their word.

The last two are the nvidia driver and the adobe flash player. So those two are things that I can start helping to get rid off, and I am doing just that. For flash, I am running gnash as well, my coding skills do not extend to what gnash needs but I can contribute bug reports and I am doing so as I have been for several years. Gnash is fast approaching a usable state. I see too many ‘opensource’ people cheering because Adobe finally ‘saw the light’ and released the GNU/Linux flash-10 alongside the windows version. Wake-up people. They didn’t see the light, they didn’t do this because they are nice ! They did it because gnash is fast approaching a usable state for everybody (it already works for almost everybody) and they want to try and stop it’s momentum by cementing their position with an early release.
Please folks, if you care about free software, see through this piece of pure marketing strategy. Adobe didn’t do this to make it easier on new GNU/Linux users, they did it because GNASH represents a threat to them on Windows and on GNU/Linux, so stopping it where it is currently strongest is their best bet to try and prevent it replacing them on both.
I believe however that they will come to learn that the only way they really could have stopped gnash and made it irrelevant would have been to make flash free software.

But back to the topic at hand, there is one project out there to try and create a free replacement for nvidia’s proprietary driver and I am now running it. At this stage you will need to have xorg1.5 installed to make the most of it, the 1.4 3D and compositing support requires the gallium driver for it which is … very broken. But not long ago, all of nouveau was pretty broken. It’s impressive how the driver has come along in a short period of time. Already it outperforms the nv driver a hundred times over on my system.
I will be upgrading to xorg 1.5 as soon as it’s practical to test it on that (particularly it’s 3D support) but I can vouch that if you follow the wiki instructions for installation nouveau works pretty well for 2D on most setups. There are some quirks which I will post on more fully as I discover them, but well done to the nouveau folks, I have already offered them what help I can give because contributing to this is the only way I can rid myself of a driver that has proven unstable, badly designed and thoroughly proven that proprietary software always comes back to bite you in the ass sooner or later.

Share|

I love me some NWN

Diary 2 Responses »

Oct 082008

I got my hands on a copy of NeverWinterNights for Linux the other day, and I’ve been playing it whenever I have spare time at night – what a great RPG. Now before the flame comments start, I’m on record as saying I don’t think it’s ethically crucial that games be free software because they aren’t software to begin with – they are art. At least, they art part is far more important than the programming part.
Which is not to say it’s not very good (and certainly a lot better) when they are free software, but like with music it’s good when it happens, but not evil when it doesn’t.

So back on topic, I really enjoy NWN. It’s rules are familiar to anybody who knows even the basics of DnD or has played Nethack for that matter, and it’s filled with tremendous flexibility of gameplay (as befits an RPG). I haven’t tried the online version at all I must admit, but the single player version is really nice. A compelling storyline with the kind of environment that allows you to live that storyline out.

NWN is of course, 32-bit only but I had no real trouble running it on Bluewhite64, all I had to do was grab the 32-bit SDL packages from slackware.com install them in a temp root and copy the usr/lib files into /usr/lib32 and it worked fine ever since.

I did find one nasty – it doesn’t play (no pun intended) nicely with twinview, putting itself in the middle of the two screens spanning halfway onto each. With Xinerama, it works perfectly. Of course Xinerama on NVidia means no compiz effects but I have also found that with twinview enabled my system is really slow and unstable, using Xinerama instead is much faster and works way better under KDE4.

I made one change though, I don’t run it under KDE at all, seeing as I have two screens, KDE needs to keep managing the one NWN is not on, and it’s not like I can multitask that way since the mouse is trapped inside NWN, so that was just a waste of resources, instead I created a .desktop file to launch NWN by itself and copied it into /usr/share/xsessions, now when I want to play it I just select “Neverwinter Nights” from my session menu on the login screen and log in, when I exit the game I’m back at the login screen. I tend to do this with most heavy-on-resource games anyway and I highly recommend it. Being able to completely switch off your desktop while playing games is just part of the real power that GNU/Linux with it’s immense customization offers over other OS’s.

Share|

BlueWhite64 releases new liveDVD’s – with bw64installer included.

Diary 1 Response »

Oct 072008

Arny has just announced the availability of new live DVD’s for Bluewhite64. There are now both KDE3 and KDE4 live DVD’s available and both sets have received a number of crucial security and stability updates.

Most exciting to me (and I hope a lot of users however) is the inclusion of bw64installer. For those who do not know yet, bw64installer is a complete, flexible, powerful and above all ease to use live system installer I wrote for bluewhite64. The code has been under development for some time (the official releases are shipping with version 0.0.5 which could be considered the first fully stable version).

This puts the LIVE versions of bluewhite64 completely on par with most other live distributions. Bluewhite64 has taken the interesting approach of buiding what is essentially a pure 64-bit port of slackware on one hand, and then being truly creative in their LIVE setups on the other, which ship a solid and easy to use preconfigured desktop system with a very impressive suite of applications, many of which are not included in the default (slackware ported) images, one example of which being the ALICE administration suite from the darklinux team.

As I mentioned in an earlier post, bw64installer is now part of the playground repository of DarkLinux which should allow it to grow even more. In the meantime, I have achieve my initial major goal with it- to make the creative and unique BW64 LIVE systems capable of acting as easy-to-use and desktop-friendly installable operating systems. This allows bluewhite64 a best-of-both worlds approach with full compatibility to slackware on one hand, and an easy preconfigured and modern desktop distribution on the other.

While merely writing an installer is not such a huge contribution, the fact is that nobody had done it – and writing a good installer for a distro isn’t easy. I had done it in the past and I could draw on my old experience (and some of my old code) which allowed me to write it faster than most people could with a solid set of features.

There are two new feature requests which I didn’t have time to finish before the release-freeze but they will be in the next update, along with any other sensible once I can come up with (a crucial thing about installers is that bloat is even more evil than usual – more steps means more difficulty and slower installs, so you have to be careful about which features you actually choose to include).

One side-note: please note that the current release does not support ReiserFS without some tweaking, so please install on ext3 partitions.

Share|

A small status update on KDE3to4

Diary No Responses »

Sep 082008

As you may know, the feature freeze for KDE 4.2 is only 3 weeks away, so of course that means that if KDE3to4 is to be includeable there, it needs to have the current bugs fixed by then. Unfortunately, I am also right now working on bw64installer which needs to be ready ASAP so it can be included in bluewhite64′s next LIVEDVD. I will therefore put in a big bughunt fest for kde3to4 it this weekend with hopefully a 0.0.5 release by Monday which should be ready to propose for inclusion into the main kde 4.2 tree.

Share|

Updated Lancelot packages, KDE4.1.1 and WiCD

Diary No Responses »

Sep 052008

Today has been a good day. First off, I just uploaded an updated set of lancelot packages. These packages are now compiled against KDE4.1.1 (they’ll probably work on older ones but don’t quote me on that) and contain a fix in the slack-desc file (thanks Kenjiro Tanaka for pointing that out).

Secondly, I’m now running KDE4.1.1 for bluewhite64 mere days after the official release, another big thank you going out to Kenjiro once more as he was the one who built these packages. I love how alive the community around BW64 is
KDE4.1.1 is quite impressive for a mere maintenance release and I definitely has a slicker feel to it. Things just work that tiny bit better especially in plasma. Still runs slow on my system though and I still blame NVidia, despite the fact that it now renders at a good speed, kwin still uses massive amounts of CPU even with effects turned off.

Finally I also discoverd wicd, courtesy of Robby Workman – finally a lovely userspace tool for network management that doesn’t bugger up the slackware philosophy, handles WPA with sweet beauty and doesn’t depend on half of gnome like NetworkManager does.

Share|

Older Entries