Home Home > Build-service
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Build Service’ Category

« Older Entries
Newer Entries »

Hello and APT repository decline

March 15th, 2009 by

Let me introduce myself. I’m an active packager for openSUSE. You can find packages that I build in the following repositories:

Some of you might remember me as the provider of the apt rpm package. The apt package is already for a long time included in the openSUSE base distribution, as such I don’t need to maintain it anylonger. Another reason is, that apt has been superceded by other package managers, such as smart and of course openSUSE’s own zypper.

The apt repository that is provided on the great opensuse mirror GWDG for the suse distributions 7.3 – 10.1 gets still many visitors, although the numbers are declining, with every new version that openSUSE releases. Only this weekend the number of visitors dropped below 100 (99) on a single day for the first time in 6 years (the top was around november 2005 with more 3600 visitors a day). It’s amazing to see how long people are using a service. It’s even more amazing when one realizes that the repository provides only packages for discontinued SuSE distributions….

That’s it for now, I hope that you will enjoy my future blogs!

Posted in Build Service, lizards.openSUSE.org, Miscellaneous | Comments Off on Hello and APT repository decline

python-TurboGears2 alive and kickin’ on the build service

March 6th, 2009 by
Screenshot of TurboGears 2

Screenshot of TurboGears 2

It’s been quite a while since I last posted an update on the state of python-turbogears in the openSUSE build service. The TurboGears project currently has three branches open (which seems to cause more confusion that actually help people) – the 1.0 branch, the 1.1 branch and the 2.0 branch. Whereas newcomers are advised to install from the 1.0 branch and to develop web applications based on that branch, the truth is that most of the active development goes on in the 2.0 branch. TurboGears 2.0 is at beta7 stage right now – features are frozen and a release data is in sight for the big 2.0.

Without getting into the major differences between 1.0 and 2.0, many people on the TurboGears Google Group have expressed the opinion that the 2.0 branch, despite its beta suffix, is exceptionally stable and well suited to production deployment. One of the major obstacles facing people was how to actually install it. Because it requires some cutting edge packages which might not be standard fare for many distributions, it is recommended to install TurboGears2 (beta) in a virtual python environment using the virtualenv package. Once the new virtual environment is ready and activated, a simple easy_install will automatically install the TurboGears2 package and its requirements. This is well documented.

I got a bit fed up with the virtual environment setup – it worked fairly well, but I was constantly having to set up completely new virtual environments just to install another TurboGears web application. There is an option when using virtualenv, to make the entire virtual environment “mobile” (meaning that you can pack virtual environment plus web app off to another computer easily), but it wasn’t working for me.

Enter python-TurboGears2 on the openSUSE build service. It took me a couple of days to get all the dependencies in the correct versions and installing properly, but it looks as if it works now. As TurboGears2 will be in a more or less constant state of flux until the final 2.0 release, there will probably be quite a lot of work to do to keep the packages up to date, but it’s worth it for the simple zypper in python-TurboGears2 🙂 What I want to do now is to try creating a SUSE Studio based virtual appliance – that way practically any web app could be created and setup easily – and with a bit of elbow grease you could probably use apparmor etc to make it rock solid.

PS: it would be well cool if people would test the package

Tags: , , ,
Posted in Build Service, Packaging | Comments Off on python-TurboGears2 alive and kickin’ on the build service

New/Updated Applications @ home:saigkill

March 4th, 2009 by

Hello Folks,

now following an List from my last updated/worked Packages:

  1. boinc-client 6.4.5 (last stable and recommended Version)
  2. boinctray 2.3
  3. kde4-skrooge 0.2.4 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
  4. libatlas3 3.8.2 (also published in Education)
  5. libdbus++ 0.6.0
  6. libtinyxml0 2.5.3 (also published in openSUSE:Factory:contrib)
  7. libtktray1 1.1
  8. lynis 1.2.3 (also published in openSUSE:Factory:contrib)
  9. mountmanager 0.2.6 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
  10. necpp 1.2.6+cvs20070816
  11. python-iCalendar 1.2 (also published in openSUSE_Factory:contrib)
  12. qantenna 0.2.1
  13. rkhunter 1.3.4 (also published in openSUSE:Factory:contrib)

Have a lot of Fun 🙂

Tags: , ,
Posted in Build Service, Contrib, KDE, lizards.openSUSE.org, Miscellaneous, Packaging | 1 Comment »

openSUSE-like update repositories for third party projects

February 22nd, 2009 by

Starting with 11.0, the openSUSE-Education project hosts it’s own, separate update repository. This is our solution for the strategic decision not to use the openSUSE Build Service as repository for endusers but for development only.

So for production purposes, we always recommend to use our frozen repositories on http://download.opensuse-education.org/. But as “frozen” implies, the repositories there are frozen at the time, the openSUSE-Education team declares them as “Goldmaster” (which is the case for all except the 11.1 repo at the moment) – and no package update or changes happens for this repositories.

The openSUSE-Education team has relatively long development and testing cycles – but as everywhere, shi* happens, and so it might be that some of the packages in the frozen repository are broken or need a security fix. For this, we have created update repositories (for at least 11.0 and the upcomming 11.1 Edu-Release) which are disabled per default, but added to the system during installation of the openSUSE-Education-release  package. (Reason behind this decision: if an administrator installs openSUSE-Education in a school, he wants to “mirror” the update repositories and not point every client to the official ones. All a user has to do is to enable this update repository via YaST or via “zypper mr -e ‘openSUSE-Education Updates'”.

We’re using the “updateinfo.xml” file formal described in the openSUSE-Wiki. Currently, we’ve 5 package updates/fixes for 11.0 in the update repository – and this might grow over the time. The updates are shown in the current online-update-applets as “normal” updates like the openSUSE ones. Interestingly, the user can’t see if an update is from the official openSUSE or the openSUSE-Education update repository – even if we use a different “from” tag. Perhaps we have to “play” with the “release” or other tags: testing is needed as it looks like nobody tries this before…

Tags: , ,
Posted in Build Service, Packaging, Software Management | 2 Comments »

Status russian mirrors

February 19th, 2009 by

Some times ago Russian and Ukrainian users noticed strange connection drops from Yandex. I can’t solve this problem, because I’m not Yandex employee.

Russian mirrors problems are mostly solved by introducing new mirror (Thanks to Yuri xnu!! Tsarev). This mirror have all openSUSE related stuff, 100 Mbit connection, 1Tb storage drive. After testing period now we can see that mirror is ready for main workload. So we adjust priorities and if you are try to access download.opensuse.org from Russian IP you should be redirected to this new mirror.

Due problems with foreign bandwidth we can’t serve Ukrainian users with Peter Poeml help we switch they directly to German mirrors.

If you have problems with Russian mirror accessing via download.opensuse.org please contact me directly. I’ll try to solve this

Posted in Build Service, Software Management | 4 Comments »

Why the Buildservice is currently not for endusers

February 19th, 2009 by

Everytime, when I hear people rendering homage to the openSUSE Build Service as “nice tool for endusers to get packages”, I’m a bit confused. From my point of view, the Build Service in it’s current state is not really usable for endusers.

Here are some reasons why:

  1. No displayed License before adding the repository (have a look at the Non-OSS or Education Repositories to get an idea how this works) – this might be important if people crash their hardware after adding a repository with special kernel modules without being informed about possible problems…
  2. No package groups called “patterns” – so people can’t get an easy overview about the various software areas a project provides (using YaST -> Software -> RPM Groups is not usable for me since someone decided to show just a plain structure there).
  3. No package translations (sometimes I like to see the Summary and Description of a package translated in my own language to understand the real area of application for this package).
  4. As the Repositories change over and over again (sometimes just because a dependend package in another project has changed), you need to download at least the metadata of a project again and again. For the Education repository in the Build Service this means: transfering 4MB of data each time you call “zypper”. Not really nice for people with a low bandwith.
  5. Endusers will “upgrade” their installed packages again and again – without knowing the real reason for this upgrade until they can have a look at the package changelog (hoping the developer has added some informations there). Not even the Factory distribution has this problem with automatic rebuilds (resulting just in increased release numbers) and no information for endusers why they had to download tons of MB each week…
  6. Real Packagers use their Build Service repositories for development and testing – so some packages will likely be broken during this phase – and just the packager knows when it will be really “stable”. (I’m talking about “real packagers” as I often see people using their home projects in the Build Service just to create an own repository containing packages they use – just by linking packages from other projects without any changes. But this is another topic…)

Projects like KDE or GNOME try to balance some of this problems by using the “publish disabled” option until they want to release a new version of their project. But this makes testing for developers and testers harder: with publish disabled, developers and testers can’t easily download and test new packages via the synced, public repositories – they have to download their packages via the API of the Build Service one by one.

With the upcomming releases of the Build Service, this will hopefully change. Up with 1.5 project admins can create a “full featured YaST Repository” for their projects covering the points 1, 2 and perhaps 3. But I think we also need more or less “frozen” repositories beside the current project repositories to cover 4, 5 and 6.

These “frozen” repositories should IMO be placed in separate directories (like the official openSUSE distribution directories) to make it clear to everyone that these repositories have an “enduser focus” and not a “developer focus”. This way, a project like KDE or GNOME could:

  • use the current repositories below download.opensuse.org/repositories as their “bleeding edge”  development repos for packagers and testers.
  • have a separate enduser repository with additional features like patterns and translations using the “ftp tree generation” feature.

…and thats the reason why the summary of this blog contains the word “currently” – I think the Build Service is on a good way to be a really good solution for developers and endusers. But we should find a final solution for the open issues mentioned above before we point endusers to this tool.

Tags:
Posted in Build Service | 1 Comment »

Product Creation with the openSUSE Build Service

February 11th, 2009 by

Product

First of all, what is a “Product”? The openSUSE Wiki has the following statement on the Product Definition Article:

“A product is a defined set of packages plus extra information”

In the most simple interpretation this means a set of RPM files plus a set of metadata which contains the installation kernel, information about the installation work flow, hardware detection, languages, licenses, slide shows and the like.

Thus the most simple product imaginable is a basic set of RPM files for the system to be installed and a minimum set of metadata: an installation system consisting of kernel, initrd and the packages necessary for installation.

(more…)

Posted in Build Service, Distribution, Documentation, Software Management, Systems Management | Comments Off on Product Creation with the openSUSE Build Service

New/Updated Software

February 10th, 2009 by

Hello Mates,

now following new/updated and published Software:

* Repo: openSUSE:Factory:Contrib:
kde4-skrooge
lynis
python-icalendar
rkhunter

* Repo: KDE/KDE4/Community
kde4-skrooge

* Repo: home:saigkill
boinctray
tktray

Tags: ,
Posted in Build Service, Contrib, KDE, lizards.openSUSE.org | Comments Off on New/Updated Software

Linking Buildservice packages with exact revisions

February 6th, 2009 by

During the “cleanup” of the HP-Education repository, I used a very interesting feature of the openSUSE Build Service: linking against revisions.

Sometimes, you want to patch a package from another repository to build with special features enabled or disabled. The Build Service allows you to link the package from this other repository (and avoid wasting space by duplicating the sources) and add your patches.

Now think about a patch against a special version of a package – and you know that you don’t want a package with a newer version in your repository for a foreseeable time. But if you use the plain link command of the Build Service, the linked package in your repository will get updated if the original package in the original project is updated.

Luckily, the buildservice allows you to link against a “frozen” state of a package: it’s source-revision. People already knowing any revision control systems like Subversion also know that the revision of a source is increased each time, a new change is submitted. And that’s what we need now: link against a special revision of the package from the other repository and apply our patch against it. The webclient currently doesn’t support such special features, but with osc it’s very easy.
(more…)

Tags: , ,
Posted in Build Service | Comments Off on Linking Buildservice packages with exact revisions

Build maemo-apps with openSUSE BuildService ? – It works !

January 27th, 2009 by

build serviceThe openSUSE Build Service is an open and complete distribution development platform. It’s the infrastructure for a development of the openSUSE distributions. But this powerful tool can do much more! The upcoming version 1.5 will also have cross-build support and thus be able to build e.g. ARM packages on x86 hardware .

maemo.org loko Maemo is the platform for mobile devices like the N810 and has been developed by Nokia in collaboration with many open source projects such as the Linux kernel, GNOME and many more. (more…)

Tags: , , , , , ,
Posted in Architectures, Base System, Build Service, Distribution, Hackweek, Packaging, Toolchain, Virtualization | 3 Comments »

« Older Entries
Newer Entries »