I created packages for the nice KDM and ksplash theme Steampunk. For this theme a matching color scheme, wallpaper and mouse theme exist and those are packed in the same rpm. Youtube shows the theme in action for Kubuntu, the version in the rpm is distribution neutral. The rpm can be obtained from the home:rbos repository, I hope you enjoy the theme.
Posts Tagged ‘Package’
A few days ago I was wandering on the openSUSE Forums, once more in the games section when I saw one more post from one of our users asking for Unknown Horizons… I’ve search a bit and found 2 entries on OBS (openSUSE Build Service), one for Fedora packages and another for openSUSE packages.
I’ve joined #unknown-horizons on FreeNode and found out that Unknown Horizons is very active and people are very nice. I’ve made a few questions around and offered myself to package this nice game for openSUSE (home:ketheriel:UnknownHorizons). Some of the dependencies are provided by the games repository, to which I want to submit the major releases, and if possible enable builds for Fedora (and friends).
A few packages need some tweaks to enable builds for Fedora (allegro, libenet, guichan), and I’m working already on that. Meanwhile for everyone who wants to check out the latest development snapshot of Unknown Horizons, feel free to do so… Currently packaged for:
* openSUSE 11.3
* openSUSE 11.4
* openSUSE Factory
* openSUSE Tumbleweed
The 1-Click installer can be found on Unknown Horizons download page. There’s also a nice article (bumping ego) about the new openSUSE packages on Unknown Horizons webpage!
This is a title that all openSUSE users who like RTS games should try (supports openGL and sdl) and is powered by the FIFE Engine.
Today I was reading the openSUSE forums and found an interesting thread on the ‘Games’ section, from which I quote:
“I remember playing DreamChess on Ubuntu, but the one is not available for Suse 11.4 KDE.”
I’ve taken a look around, gathered the stuff required and made a quick package of this game, thus pushing it forward to the games repository. Within a few minutes of the submission, the package was approved and it’s ready to be served to the masses.
We can’t leave transitioning users from Ubuntu unhappy can we ?! Once more thanks to Dimstar and Prusnak for the quick answer in getting this package into the games repository.
I rarely blog and even this one is merely a link to another one, but: http://rants.scribus.net/2010/12/08/happy-birthday-scribus/ is worth a look. So, where is the connection to openSUSE ? Well, way back when, SuSE 9.0 was the first distro to really promote Scribus.
You can have the latest Scribus rpms for many distros, thanks to the awesome Build Service.
The last days I’ve spent some time to investigate how to package Google Earth into an rpm. There was already a script called make-google-package available on the internet, but this one creates a debian package only. However, it was a good start to get me going to create a Google Earth (GE) rpm. Although I met quite some obstacles, which is not to uncommon in package building, I was still able to come up with a procedure a get GE packaged. The biggest problem I encountered were incorrect library dependencies, for which I opened issue 702 in the Google Earth issue tracker. Anyway to make a long story short: the rpm installs Google Earth system wide, corrects file permissions, for openSUSE_11.2 it takes care that the font is rendered correctly, the rpm takes care that Google Earth integrates nicely with the rest of the openSUSE system.
The procedure to build the rpm can be found in the openSUSE wiki. One word of caution about the procedure, you need to be an experienced linux user and you need to have access to the openSUSE Build Service (OBS) to be able to build the rpm. This is due to library dependency problem, which prevents it to build without modification to the base system.
If you like and you have the knowledge how to build an rpm with the tool ‘build’, it would be great if you can extend the howto with steps how to do this (build a GE rpm with ‘build’) to the before mentioned page. The same is valid for a procedure that uses VirtualBox to build the rpm.
Last but not last; a procedure or even a script, that uses ”’rpmbuild -ba”’ to build the rpm, would be very welcom as well.
kpassgen is updated to 0.2. The Packages can be recieved in KDE:KDE4:Community.
Collaboration is not always an easy thing: Talking, meetings, making decisions and finding compromises. Sometimes I have the impression that some people in our business find this inter personal activities very exhausting and thus prefer to work on their own. Depending on how genius one is that works far. But for obvious reasons working alone has limits. If we talk about a whole Linux distribution for example one can not succeed: The working power, creativity and time of one is not enough.
That is one reason why we consider it as one of the keys for success that the Build Service enables people to work together in a useful and non annoying way. We think of tools in the Build Service which help. That is difficult because some formalism and guidance (in business often called ‘process’) is needed to keep things going in a transparent and reproduceable way. Control should stay there where it needs to be, for example at the maintainer of a project. On the other hand collaboration tools should not constrict people and their working together.
Here is a little story of Karl who wants to change something in the openSUSE Factory project. He needs to work with the Factory maintainers and this is how that is planned for the future:
Karl, a developer working for a small software company, loves openSUSE but not really the one package Kabax because there is a packaging problem Karl has analyzed.
Karl wants to change that to make sure that the next version of openSUSE contains a good version of Kabax.
For that, a branch of Kabax in Factory is needed where the fixes can be put in, built and tested. Karl uses osc to create a branch. The package is not really maintained in Factory itself, because the few Factory maintainers can not care about all packages there. Kabax has a Devel Project entry in its meta data that points to the project where it is actually maintained by the expert Karsten.
Because of the devel project, osc branches not really from the Factory package but from the development project where the development happens by Karsten. That might be different from the Factory package, but is clearly the development version that soon will be synced to Factory. When that happens is up to Karsten and the maintainers of Factory.
In the branch Karl starts to work on Kabax and creates a beautiful patch. Since his branch package also lives on the Build Service, it builds live for all relevant repos and along the changes of the devel project.
Once Karl is happy with his work he raises the attention of Karsten on his change by creating a submit request. A request in general informs others of something somebody else has done which requires action. In the case of the submit request it tells Karsten that there is a valuable change to his package that should make it’s way to Factory. Karsten now accepts the request and Karls contribution is in.
The nice thing about all this is also that the branch packages as well as the requests are open and visible to everybody who is interested in. That gives us the transparency we need. And of course that does not only work for Factory but for all projects if one wants to change something on a package where he/she does not have permissions yet.
How do you like this story?