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

Hot Off The openSUSE Build Service Press

January 27th, 2010 by

Now with the aid of the Hermes notification system, you can find out as soon as a new version of software you’re interested in is uploaded to the openSUSE Build Service.

KDE version updates shown in the News widget

Here we see the test KDE feed I setup in the News widget.  You can setup your own new version feeds by going to the Hermes web interface with your openSUSE login, My Subscriptions, then scroll to the bottom of the page and enter the ‘expert interface’.  Add a new subscription of message type ‘OBS_SRCSRV_VERSION_CHANGE’ then set the appropriate digest period and the delivery mode to Web/RSS Newsfeed.  Finally add a Filter for ‘packagename’ and probably ‘containsitem’ then some part of the project name you are interested in.  I used ‘KDE:’ for the above feed, but you could use a more complete project name to include only for example new versions in KDE:KDE4:Factory:Desktop.  Save your changes, and you can then go to the ‘My Feeds’ link in the Hermes toolbox at left to get the feed URL.  To add a feed name, edit the notification and add a description.

Now all you research students and other compulsive update fans needn’t ‘zypper dup’ 10 times a day to find out if your favourite software changed.  Enhancement #434757 is done!

A stable repository for kolab

January 17th, 2010 by

During the X-mas holidays Kolab, the groupware server got a stable repository for 11.1 and 11.2 on the openSUSE build service (OBS). All packages that are not provided by the openSUSE base distribution have been copied (using osc copypac) to the STABLE repository. Another possiblity to achieve the same result could be by making a fixed link to the unstable package using osc linkpac -r <rev>. Once the unstable package works again the link could be updated with osc setlinkrev -r <newrev> to point to the working revision or updated revision.

The stable repository already shows its benefits, as cyrus-imapd was updated from version 2.3.14 to 2.3.16 in the server:mail, being the cyrus-imapd development repository for Factory. As the cyrus-imapd package in kolab:UNSTABLE links to the server:mail one, it no longer builds as the kolab patches no longer apply. Unfortunately my computer went South, and real package development is at the moment not possible. A good thing to mention here is, that cyrus-imapd-2.3.16 includes patches that are needed for Kolab and which have been in the review queue for multiple years!

Just before X-mas Kolab-2.2.3 was announced. This version is not used in the openSUSE packages, as we package the version from trunk. After the 2.2.3 release the kolab development, moved back to trunk and the next version will be from trunk.

During the 8th annual KDE PIM meeting in Osnabrück, Northern Germany Kolab got some attention as well, with the following exciting announcement: KDAB and Intevation will be working on making a functional PIM suite and Kolab Groupware client based on Kontact for mobile platforms.

OBS reports scheduling state now

January 11th, 2010 by

After getting asked daily why package X or project Y is in a certain state, why it is not yet published or if a “trigger rebuild” button click is needed, I finally got around and implemented the last planned feature for OBS 1.7.

Each repository has a scheduler state now for each architecture. This state tells you in which state the scheduler saw it the last time he looked at it. In addition to that, there is also a “dirty” flag. This gets set, when something happened what requires a re-calculation by the scheduler, but he has not done this yet. So no need to hit the “trigger rebuild” button in this case, it won’t help 😉

A typical state round trip is the following, it can stop at any point and restart from a higher listed state again if this is needed:

unknown: a repo has just been created for this architecture. The scheduler has not seen this yet. This is currently the case also in most repos, just because the scheduler with this new code has not looked at all existing repos yet. But you will see this only in very rare cases in future.
scheduling: the scheduler is looking at this repo right now. The package states will get updated soon (from 1 second up to 2 minutes, depending on the project complexity)

blocked: packages from other repos need to build first until any of the packages from this repo can get build.
building: packages are scheduled for building, this means they are in “build”, “scheduled” or “finished” state.

unpublished: all packages got built, publishing is disabled, so nothing is to do here anymore.
or
finished: all packages which require a build have been built. This repo is enabled for publishing, but this has not yet happened.
publishing: The publisher is currently processing this repository.
published: the latest built packages have been uploaded to the stage server and are available via download.opensuse.org

Future plans for this are to add this state list in the web interface somehow, so everybody gets an explanation in the context.

Another thing what I want to add is a button beside the “unpublished” state, to force a publishing. So by default nothing gets published, but the project owner can force it when he things it makes sense. However, this is now also possible to achieve by swithing the publish flag and revert it after some time. The OBS is now even publishing when the build has already finished (unlike before).

openSUSE Build Service 1.7 Beta 1

December 23rd, 2009 by

The openSUSE Build Service (OBS) team just announced the Beta 1 version of the upcomming 1.7 release. Most of the features are already accessable in the Build Service instance which is used by the opensuse.org project.

Please find a more detailed announcement here.

The final release is planed early next year.

Kolab cyrus-imapd inherits from openSUSE base cyrus-imapd

December 3rd, 2009 by

This week kolab became one small step closer to realize feature request 307846: include Kolab in openSUSE. Although it will take lots and lots of more work to achieve this goal at all. The one step closer was realized in cooperation with the openSUSE cyrus-imapd maintainer R. The openSUSE cyrus-imapd spec file in the repository server:mail spec file has been extended with information about kolab, but the actual execution of the information has been switched off. With the Build Service link functionality the package server:mail/cyrus-imapd has been linked to the package server:kolab:UNSTABLE/cyrus-imapd-kolab, where the kolab functionality gets built. This is achieved by activating the variable with_kolab in the project related configuration file:
# osc meta prjconf server:Kolab:UNSTABLE
%define with_kolab 1
Macros:
%with_kolab 1

See the Build_Service prjconf page in the openSUSE wiki for more information about this awesome functionality. This way the cyrus-imapd-kolab package inherits everything from the openSUSE base cyrus-imapd package.

One drawback for kolab administrators, you have to manually correct the currently installed kolab packages. Start with downgrading cyrus-imapd-kolab (it only downgrades the Build service version and not cyrus-imapd itself):
# zyp in cyrus-imapd-kolab
This will install the dependent package perl-Cyrus-IMAP-kolab instead of perl-Cyrus-IMAP and perl-Cyrus-SIEVE-managesieve-kolab instead of perl-Cyrus-SIEVE-managesieve and it might remove kolab and perl-kolab.

Now reinstall kolab with:
# zyp in kolab
that should be sufficient to be in sync with the repository again. Don’t forget to restart the services, with:
# rckolab restart

This week also showed the power of the build service, as I could install kolab within only some minutes after installing openSUSE-11.2 in Virtualbox, while I never installed openSUSE-11.2 before.

The kolab installation in openSUS-11.2 made some problems visible in kolabconf -n. The latter has been fixed, it was a general problem in kolabconf and did not have anything to do with openSUSE-11.2.

The kolabconf problem however required some debugging, with a resulted spin off that the spamassassin daemon spamd is no longer activated via the startup scripts, but as a library of amavisd instead. That is the way amavisd and spamd have been configured in kolab, but what was not honored in the kolab setup on openSUSE.

Due to the change in the amavisd and spamd deamons, the script kolabsrv has been extended, and can now show a list with services required by kolab and what their current status is (see screenshot):

kolabsrv list and status output

kolabsrv list and status output

The main task of kolabsrv is to convert the openpkg service names to the distribution dependent names.

The kolab project is heading towards a new release 2.2.3 with a planned release date in December 2009.

Sascha released a nice Brain Dump of the Week, giving a nice insight in the possible future of Kolab.

In one of the replies of Sasha’s brain dump, a references was made to project-builder, a project similar to the openSUSE build service. Although the OBS and project-builder may be similar, some people are wondering what the differences (1) and (2) are.

That’s quite a lot of information, but lots of things happened since my last blog entry about Kolab.

PS: many thanks that M. from Novell, who made my Lizards blog account working again. For the most part of this week, I’ve not been able to login to my blog account. After logging in with the correct credentials, I was referred back to the Lizards entry page. M. knows the details, so if this happens to you contact M. from Novell 🙂

openSUSE 11.2 is out

November 12th, 2009 by

The openSUSE Project is pleased to announce the release of openSUSE 11.2. After a couple of month good work towards the 11.2 we’re enjoying a very nice distribution which I already like very much. It is running on most of my machines for a few weeks now. I have already seen some SUSE Linux distros going gold over the time I spent with SUSE and my personal gut feeling tells me this is one of the more remarkable versions.

As usual it comes with tons of new up to date software and also the installation runs smoothly, please read the announcement for all the details, but what for me the most remarkable with 11.2 is that it is a real community openSUSE distro.

There is so much effort visible in 11.2 which was achieved through our growing community rather than just the SUSE people. We had a lots of requests in openFATE suggesting features, we discussed some of them quite heated, others were no-brainer. We again had lots of testers who hammered the alphas and betas and reported big and small bugs. On the openSUSE Conference many discussions about the upcoming distribution took place which were inspiring. We were able to utilize the powerful openSUSE Buildservice to build the distro together with all packagers very effectively. That improved the quality of our packages again. Another very visible thing for me personally is the desktop artwork which was done in best cooperation with upstream – and it looks so great that I hesitate to start applications which cover the desktop all day 😉

It is really exciting to see how things come together on the way to community distribution, and how far we got with openSUSE 11.2. I am happy about that and I am proud to be part of this and like to say thank you for every little bit you might have contributed. I believe that the message that openSUSE is your community distribution has arrived.

Of course openSUSE continues to be open for your ideas, the distribution can be the vehicle to power up ideas from a little application to huge software projects. The openSUSE project is the powerful community behind which helps to make ideas reality. And all that based on the principles of free software! I am really happy today and very excited about what future will bring 🙂

I hope to see you on the release event here in Nürnberg soon 🙂

OBS webclient is now able to handle requests

November 10th, 2009 by

Since a few days, the OBS webbclient is now able to handle requests which means that you can accept/decline requests concerning you or revoke own requests. Furthermore you see a complete diff for submit requests. For me, it was my first experience with Ruby on Rails but it seems to be very exciting. So the usability is not perfect now but i will working on it.

Next step is to implement the attribute system (//lizards.opensuse.org/2009/11/02/obs-attribute-system/)

OBS Attribute System (not only for maintenance!)

November 2nd, 2009 by

People who follow the openSUSE Build Service (OBS) developments might know it already, we work on an attribute system for OBS. But what it is good for at all ?

Our current driver is to enable every OBS user to do maintenance for packages in the maintained products (which are currently openSUSE 11.0, 11.1 and a few days 11.2). The maintenance concept itself is described in a very first draft here

However, the attribute system is way more powerful and can be used to store all kind of informations, attached to projects, source packages or even binary sub packages. The important thing here is that the attribute types have own permission rules. So it is for example possible to edit data in projects like openSUSE:11.1 or Fedora:9 which are usually read only.

A simple example is the OBS:Screenshot attribute, as you might guess you can attach references to screenshots to it. Every maintainer or bugowner has write access to it, this means if you are the bugowner of a package, you store this kind of informations not only in your projects, but also in the openSUSE:11.X project packages.

There is also the openSUSE:Playground attribute type created, just for you, when you like to play with this. Btw, the current available attribute types can be requested via “osc meta prj OBS”. And when you use the osc 0.123svn from svn trunk or openSUSE:Tools:Unstable Project, you can even check single attributes in different ways or create them.

For example:


osc meta attribute openSUSE:11.2 # Shows the attributes of the openSUSE:11.2 project
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --create # just creates the attribute in my home project
osc meta attribute home:adrianSuSE zphoto # returns empty, since the package hasn't the attribute.
osc meta attribute home:adrianSuSE zphoto --attribute-project # returns with attribute, since it falls back to the project


# stores two values (World Domination and fast) inside of the attribute:
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --set "World Domination,fast"
osc meta attribute home:adrianSuSE # shows all attributes in my home


osc search --attribute openSUSE:Playground # finds all packages in all projects with the openSUSE:Playground attribute
osc search --package zphoto --attribute openSUSE:Playground # finds all zphoto packages in all project with the openSUSE:Playground attribute

Okay, Okay, all that sounds not horrible sexy when you read it first. But imaging the possibilities. Each team or use case can get their own attributes. They decide what to store in which package, independend if they can modify the sources of project or not. So a team can easily mark packages for any kind of purpose (to fix bugreport 1234, to complete their product Z, to show the state of the packages on web page X, …).

The “osc mbranch” command from the maintenance concept shows also the power of this. You do not need to know where all instances of your package, just tell the server that you need to work on it and the server collects them all.

Please note that the API for the attribute system still might change until OBS 1.7 gets released, we may even need to remove the attributes (even though this is not planned). However, the version running at opensuse.org should be ready to play with this system. And I _really_ would like to hear any kind of feedback, ideas or requests. Can you please comment here, what you can imaging, what else you can use this system for ?

Thanks a lot !

PS: New attribute types can be defined only by the administrator atm, but I am really happy to create any kind of attributes for you, even though you just want to play with it!

Developing for openSUSE using Devel Projects

October 22nd, 2009 by

With the opening of the openSUSE distribution so that everybody can contribute to packaging, we introduced the concept of devel projects and I’d like to explain a bit more what they are and why they are important.

(more…)

update from the openSUSE Boosters

October 21st, 2009 by

While openSUSE 11.2 gets closer and closer, all of the Boosters are mostly busy making sure RC1 and the final release are good.  But we’re finding some time to work on our Boosting projects.  On the umbrella site for all opensuse.org sites front, a design and user profiles are being developed .  The factory.opensuse.org status site concept is being developed in collaboration with the Maintenance team, so that it will be used for seeing the state of maintenance work (ie online updates) for released openSUSE versions.  We’re analysing the Build Service web client code for how to hook in there, and several team members are brushing up their Ruby skills.  The reorganize contributor documentation squad are discussing a new structure on the opensuse-wiki mailing list.

If you have any feedback on these ideas you can find us on the opensuse-project mailing list or on -wiki as above.  If you want to help out, we’ll be using opensuse-boosters@opensuse.org in future.

Busily,

The Propaganda Minister