Home Home > Tag > 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...

Posts Tagged ‘Build Service’

« Older Entries

LXDE and gtk3

July 19th, 2011 by

GTK3 will slowly replace the “old” gtk2, and of course, if we don’t want to be left behind we have to move to gtk3 eventually.

Even if slowly (we need horse power! –> yes we need you too!!) LXDE is being ported too. Nothing has been released yet, but a good deal of work is actually into git repositories.

X11:lxde:gtk3 project

Thanks to openSUSE Build Service (public instance of the Open Build Service) we are currently able to get git code and build it auto-magically (thanks god you created obs _services 😀 )

Right now, only five packages don’t want to build with gtk3 and they are: gpicview, libfm, lxmusic, lxpanel, pcmanfm. Everything else builds fine. As a side note, lxdm gtk greeter build but seems to crasch.

Please test those packages and report in our mailing list or even better upstream your issues.

To conclude, right now i don’t feel comfortable to push into factory gtk3 packages, so 12.1 most probably will stuck with the well know stable gtk2 packages.

Also, i’m actually working to use obs, to provide gtk3 enabled git nightly build not only to openSUSE (actually only >= 11.4) but also to Fedora 15 (already building with many successful packages) and Ubuntu/Debian. So if you are .deb packagers, please let me know, i need your help. Contact me and the lxde team using our mailing list opensue-lxde@opensuse.org

Have a great day,

Andrea

Tags: , ,
Posted in Build Service, Desktop, Distribution, Packaging, Programming | 1 Comment »

Factory Progress

May 27th, 2011 by

A lot of things are happening in our Factory distribution that will be released in November 2011 as openSUSE 12.1 and I’d like to point out a few things from the last few weeks that users and developers of factory shouldn’t miss.

Roadmap openSUSE 12.1

Stephan “Coolo” Kulow has updated the openSUSE 12.1 Roadmap, the next milestone is Milestone 1 which is delayed and targeted now for release on Tuesday, 30th May. The next paragraphs highlight some of the updates for this versions.

GCC 4.6

The GNU Compiler Collection has been updated to version 4.6, the list of  changes includes the following new warning that will be visible while compiling packages for openSUSE Factory:

  • “New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were added for C, C++, Objective-C and Objective-C++. These warnings diagnose variables respective parameters which are only set in the code and never otherwise used. Usually such variables are useless and often even the value assigned to them is computed needlessly, sometimes expensively. The -Wunused-but-set-variable warning is enabled by default by -Wall flag and -Wunused-but-set-parameter by -Wall -Wextra flags.”

Some packages have been failing by the new GCC due to new warnings and new optimizations and most have been fixed already but please double check that your packages are building and running fine.

RPM 4.9

Michael Schröder announced RPM 4.9 for Factory. He explains the main packager visible changes as:

“Besides some bug fixes and an update to a newer BerkeleyDB
library rpm-4.9.0 contains plugin architecture for dependency
generation. In older rpms, the internal dependency generator
was pretty much hardcoded in C, so we always used the old
external one to generate dependencies. With rpm-4.9.0, the
internal generator has become flexible enough so that we
can use it.

This means for you, that rpm will no longer use the %__find_provides and %__find_requires macros. Some packages redefined those macros to be able to filter the generated dependencies.
This will no longer work in rpm-4.9.0. Instead, support for
dependency filtering was added to rpm…”

GNOME 3

GNOME 3 has now hit Factory as well and Vincent Untz explained how to fix failures due to the large push.

Linux Kernel 2.6.39

This update was a “boring” update – nothing broke AFAIK ;), so I hope it’s a solid version. Users will benefit from the new features in it. 2.6.39 is the first kernel without the Big Kernel Lock at all!

Packaging Changes

Besides new software, also new ways of handling it get introduced. The following catched my eyes:

Rpmlint update

Ludwig Nussel updated rpmlint to version 1.2 and explained the new warnings about packaging of rpm packages – and what to do about them.

Changing the process of Factory submissions with the Open Build Service

Now with every submission to Factory scripts are run automatically that do two different reviews before the package goes to human check-in review:

  • The “legal-auto” review checks the updated package for changes in licenses.
  • The “factory-auto” review checks that the updated package builds actually in the devel project – and if not, rejects it.

The “legal-auto” review has quite a long backlog at the moment and Jürgen is working on moving some of the checks to rpmlint or osc checks – so that the packager notices and fixes them before submission to Factory.

Also, you can now submit packages to Factory even if you are not the maintainer of the package but in this case the maintainer (packager) gets a review request to review that the package really can go to factory and thus a plea to packagers to handle their review requests.

openSUSE Conference

The openSUSE Conference is this year co-located with the SUSE Labs conference. Join us to present and discuss also Factory related topics. The Call for papers is open now!

I’m interested on feedback on this article – should I start a series?

Tags: , , , ,
Posted in Distribution, Factory | 11 Comments »

new osc feature to edit a request

January 30th, 2011 by

Hi,

I just pushed a new osc feature to git master which allows you to edit a submit action. Use case: suppose you review a request (which has at least one submit action) and you find a small typo (for instance in the spec file) but except the typo everything is fine. So instead of declining the request you can fix the typo, create a new request (which contains the fix + the original changes), accept the newly created request and supersede the original request (that’s basically what osc does behind the scenes).

Example:

# request with id 80 needs a small fix
marcus@linux:~> osc rq show 80 –edit
Request: #80

submit:       home:Admin/foo  -> home:foobar/dest
delete:       home:foobar/xxx

Message:
deletes package xxx and fixes dest.

State:   new        2011-01-30T15:04:03 Admin
Comment: <no comment>
A    /tmp/osc_editsrr2iDcI/test.spec
A    /tmp/osc_editsrr2iDcI/src.tar.bz2
At revision 1.
Checked out package ‘foo.home_Admin’ to /tmp/osc_editsrr2iDcI. Started a new shell (/bin/bash).
Please fix the package and close the shell afterwards.
marcus@linux:/tmp/osc_editsrr2iDcI> # fix it and commit changes
marcus@linux:/tmp/osc_editsrr2iDcI> exit
exit
Request: #None

submit:       home:Admin:branches:REQUEST_80/foo.home_Admin(cleanup) -> home:foobar/dest
delete:        home:foobar/xxx

Message:
<no message>
d(i)ff/(a)ccept/(b)uildstatus/(e)dit/(s)kip/(c)ancel > a -m “accepted request and applied small fix”
Supersede original request? (y|N) y
marcus@linux:~>

By the way you can also do it manually (osc rq clone <id>; osc co <clone project>; fix package(s) and commit changes; create a new request, accept it and supersede original request).

Tags:
Posted in Build Service | Comments Off on new osc feature to edit a request

Happy Birthday Scribus

December 9th, 2010 by

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.

Enjoy!

Tags: , , , ,
Posted in Build Service, Desktop, Miscellaneous | Comments Off on Happy Birthday Scribus

New Package for packager: whohas

November 16th, 2010 by

Sometimes a packager asked himself, who has already packaged this Software? Maybe the Packagingfiles can help me to fix a error? Or maybe an other packager has a written a patch that i can use for my situation?
Philipp L. Wesche knows this situation, and he wrote a program, that allows to view in other Distributions and Repositories, who has a specific Software packaged. The commandline tool “whohas” supports Arch, Debian, Fedora, Gentoo, Mandriva, openSUSE, Slackware, linuxpackages.net, Source Mage, Ubuntu, FreeBSD, NetBSD, OpenBSD, Fink, MacPorts and Cygwin. Philipp wrote this tool in Perl and was designed to help package maintainers find ebuilds, pkgbuilds and similar package definitions to learn from.

The Tutorial from the Autor can found at: http://www.philippwesche.org/200811/whohas/intro.html

You can download this tool on: http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib

Tags: , ,
Posted in Build Service, Packaging | 1 Comment »

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 🙂

Tags: , ,
Posted in Build Service, lizards.openSUSE.org, Server | Comments Off on Kolab cyrus-imapd inherits from openSUSE base cyrus-imapd

openSUSE@ARM/GSoC: Cross-compilation & speedup

June 16th, 2009 by

This weeks topic was the integration of the cross-compilation mode into the build environment. But it’s more than just a cross-toolchain – it’s a speed-boost for our ARM build environment. As of today, the source is deployed in the repository Base:build:arm:cross. It’s not fully bootstrapped because of the current high load and the upcoming downtime – so watch out for changes there and in Base:build:arm.

But what are these “speedup’s” ? First, you’ve to know that in our build environment the ARM binaries are executed through an emulation-layer. This works on the cost of speed. The goal is now, to exchange some key parts in a transparent manner with native x86 binaries: no emulation, no slowdown. Sounds reasonable, but is it easily possible ?
I had to take care not to mix stuff too much because the environment would break. But now I’ve to say:  WOW, this worked incredibly well  😉 .

The distinctive feature of our approach in comparison to usual cross-build environments is that we use the best of native environment emulation and the speed of cross-compilation. Because of this combination we don’t have to patch the individual packages to make them cross-compilation ready. This is a new way of cross-compiling suitable also for large number of packages. A detailed overview about the different crossbuild types can be found on this page.
Another feature to note is that the exchanged binaries (replacing ARM with x86 in the build environment) also don’t need heavy patching and there’s no need to compile them as static binaries. All of them are normal distribution packages.

A switch in the project enables/disables the new features. With the new changes in place, the speed could be vastly increased. Some figures:
* package rpm
* package glibc w/o locales

Build time in minutes
x86 native armv5tel native armv5tel cross factor native factor cross
rpm 8 107 17 13,38 2,13
glibc 33 505 63 15,3 1,91

overview cross-environment

Thats a drop from about x15 to x2 in comparison to the native x86 build-time !! See it yourself when the “crosscompiled” repo in Base:build:arm is up and running.

In other words: “Warp 5, Mr. Sulu !” 😉

Tags: , , , , , , , ,
Posted in Architectures, Base System, Build Service, Distribution, Packaging | 2 Comments »

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 »

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 »

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

« Older Entries