The new mercurial-based specs repository is supposed to make it easier to try out the KDE4 packages. It requires less downloading, I hope, than the whole Dude checkout, less disk space, and less futzing around.
The mercurial-based specs repository is available in two flavors: - kde4-specs (stable) - kde4-specs-dev (unstable, public) I'm going to sync up -specs-dev to -specs in a few moments to express that the packages that are there -- right up to kdebase -- seem to be stable. You can clone that repo with hg clone https://solaris.bionicmutton.org/hg/kde4-specs or get the -specs-dev repo with hg clone https://solaris.bionicmutton.org/hg/kde4-specs-dev or, if you don't like using mercurial at all, you can get the tarball http://solaris.bionicmutton.org/hg/kde4-specs/archive/tip.tar.gz which is the latest stuff. It might be easiest to clone the -specs-dev repo, though, also for contributing back (which this mail message is all about). The -specs-dev repo is public and writable (over https) so you too can push fixes back on to it; review will happen before things end up in -specs and if things get hairy then I'll re-clone -specs-dev and throw out the hairy bits. What kinds of things need to be done specifically? Well, there's a TODO list in specs/ which lists a few things; I'll produce a separate list here: - specfile formatting so they're all consistently formatted; I waffled over spaces-vs-tabs and things like that, and now it's a bit of a mess. This is pretty basic administrivia, but it would save *me* a bunch of time and get *you* into reading specfiles which might prompt further action. - version and license checking. Each package needs to be documented what the license is -- many have a # TODO line or license set to ? to express that I haven't looked at the source or the homepage of the project to check. We should fix the license lines and document the existence of newer versions. - duplication checking. In some cases we may be able to ditch a package and just use an existing SUNW one -- consider FOSSlibgpg-error, for instance. These are administrative in nature, but it is necessary work beside the regular porting-of-applications. It's a good introduction to the shape of the specfiles (derived from pspc, obviously). This kind of cleanup needs to happen before we push things into any kind of official OSOL repository for package specfiles (this is why we have the two clones on solaris.bionicmutton and not just the one in OSOL itself). - pspc import. There's 160-odd pspc files and I've spec-ified 57 of them. Changing the format is a 3 minute job at most, but checking the license, source and homepage takes a bit longer -- again something that needs to be done before we can really publicize these specfiles (or the pspcs, for that matter). That item is needed to get the whole dependency tree going again. I've been working (with hg mq, which is wonderful for this purpose) backwards from the KDE specfiles (which are in Dude) and pulling in only the necessary dependencies, not everything-we-might-need which is what's in Dude right now. Eventually we should get to the complete coverage level again, though. Given the lack of push for input methods and such, though, this may take some time. - build testing. We need people running the builds all over the place. I do my builds on dillon (nv70b still), benedict (nv83) and my U45; we should have more SPARC hardware in place soon, I hope. Pertti has been doing some useful builds, with good failure reports; this flags particular packages for re- examination. - runtime testing. We don't have much in the way of documented KDE4 *use* on Solaris. I use it, and stuff that bugs me gets fixed (eventually .. , see konsole, kmail crashes, missing ksysguard stuff). But we don't have much of a concerted effort to file bugs with Solaris set as OS in bugs.kde.org and not many reports of daily use of the existing KDE4 packages. - runtime wishlists. What do we need still in KDE4 on Solaris? These could be filed as wishlist items in bugs.kde.org as well. One I have is nicer ZFS support in the filemanager -- this has been on our list for a long time, mostly pushed back because there's other packaging efforts that need work too. GNOME just implemented something along these lines. These two items are what will make KDE4 shine on Solaris. Anyway, contributions solicited. Make yours either through the repo or by email. [ade]
