May 2011 - openSUSE Build Service - openSUSE Mailing Lists

[opensuse-buildservice] Build Team Meeting
by Adrian Schröter 26 May '11

26 May '11

Note: meeting minutes from yesterday morning present: mls, saschpe, adrian * OBS 2.3 state * OBS rename * server upgrade * continous integration * Ruby coding style OBS 2.3 ======= * Features complete - new source service handling implemented To be fixed before Beta 2: * Last missing feature: - Delta rpm configuration * Make OBS name and description configurable via "Setup OBS" * Remaining problems: - createrepo is not extending existing meta data - createrepo & modifyrepo have no --rsyncable option - some regressions in webui to be fixed OBS Rename ========== Our implementation of OBS, the "openSUSE Build Service" will be renamed to "Open Build Service (OBS)". "openSUSE Build Service" name will stay for our public instance behind build.opensuse.org. Details will be announced by Jos. Server Upgrade ============== New backend server systems are installed, stress testing is WIP. Continous Integration ===================== Sascha plays with hudson & friends. Goal is to have a full test coverage after each commit including performance benchmarks. Open question: Do we want to create an hudson.opensuse.org ? Ruby coding style ================= SUSE developers created a draft for a common ruby coding style. The draft got published in opensuse wiki: http://en.opensuse.org/openSUSE:Ruby_coding_conventions We will move our code into that direction but not reformat everything now. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

3 2

[opensuse-buildservice] Custom Initrd Images
by Praveen_Paladugu＠Dell.com 26 May '11

26 May '11

All, Is it possible to embed the custom initrd images built on OBS into other live image builds on OBS? For example the kiwi package provides the boot configuration suse-SLES11. If any extra configuration has to be done for this boot image, you make the changes in the kiwi package and re- build the live image. So, instead of providing boot="isoboot/suse-SLES11" inside the config.kiwi file, if it is possible to provide something like boot="obs://proj_id/pkg_id ", and the live image can actually pick up the initrd image configuration/build from proj_id/pkg_id, it would be really cool. Is such a feature currently available? I remember seeing something like that in the past. But a quick scan through doesn't allude to any such options. So, I wanted to make sure such a feature is available, before I drill into the failure I see. Thank you Praveen K Paladugu Dell Linux Engineering -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

[opensuse-buildservice] OBS, far more work then on Launchpad for Ubuntu
by peer 26 May '11

26 May '11

Hi, As said before I prefer OBS above Launchpad, but one thing bothers me atm. On OBS I have to build a lot of (depends) packages which I don't have to build on Launchpad. About 2/3 of my project are dependencies to make it able to build the packages I want. I guess this is due to the fact that Launchpad adds more repo's by default then OBS does. Does OBS only add the main repositories? Why and is it possible to add more repositories, to avoid an unnecessary amount of work and time (and space)? Best regards, ~P -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 3

[opensuse-buildservice] About product concept
by Sandro Andrade 25 May '11

25 May '11

Hi there, I'm playing with product creation in order to provide three different "versions" of a kiwi image I'm working into. The goal is to have a basic image, with only essential packages, an intermediate image with some additional applications, and a "full" image containing a larger set of packages. I'd be grateful if someone could clarify some points ... 1) I'm planning to provide the basic image as a base product and make intermediate and full as add-ons which depend on the base product. Is this a good approach ? 2) I understand the concept of product as a specific group of packages made available by some kind of media(um) but the real goal of release packages (as openSUSE-release) is still obscure to me. When I try to install a new add-on by using YaST module it asks me the product source (url, DVD, etc) and just shows me the YaST module for selecting patterns for installation (including patterns from all repositories currently enabled). Couldn't I ask to install all packages from the add-on ? Do I need create a pattern in product description to have this working (create_pattern="true" in "<use group ..." ?) ? 3) A bunch of packages depend on openSUSE-release package, or anyone providing distribution-release resolvable. But what would be the goal of add-ons release packages ? Just to indicate that a particular product is installed ? What if I remove all add-on packages and keep the add-on release package ? So, the relatioship between patterns, release packages and products is still abscure to me ... Thanks in advance, see you ... -- Sandro -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 3

[opensuse-buildservice] new openSUSE:* source processing method. PLEASE TEST !
by Adrian Schröter 25 May '11

25 May '11

Hello, I look for some more people who want to try our hopefully soon to be applied new source processing method for openSUSE:Factory and the maintenance updates to :Update projects. It should work good already, so you do not need to be brave ;) You may know that currently all package source submissions to Factory and friends get SUSE in-house be reviewed, re-validated and reformated. You can see this in the additional "autobuild" commits in the openSUSE:Factory commits. We plan to do following changes in future: * We would like to do these steps out there and as soon as possible in future. This means in best case before any packager is commiting his changes the validating and reformating is done already. This avoids any possible merge problems, unnecessary commits and extra turn around times. * these services can be code stream specific (unlike current osc_source_validator). That means we will be able to do better checks in future for Factory then for maintenance updates (where we need to stay compatible). And we do not need to take care about non-SUSE code streams, eg. Fedora or MeeGo people can still work and submit their changes to their projects or write their own services. * In addition to existing checks, we want to track where upstream sources (tar balls) are comming from. So far we had the download_url source service, which downloaded files and stored them with _service: prefix what not everybody liked. The new and project wide working "download_files" service is just validate the URL's from the spec file. The new osc will commit these files as usual files and the server is just validating this. (People with low upstream bandwidth can still decide to skip the commit, the server will store it with prefix again.) So, if everybody is using this current osc & source service stack, the source services will be used to do these steps, but there will be no _service* file(s) in your package sources. And the last really SUSE in-house part of Factory development would be the legal review db, really everything else would be out there in build.o.o... How to test this ? ================== First of all you need the new services and a new osc installed. Please add the proper openSUSE:Tools project repo and install zypper in obs-service-download_files obs-service-format_spec_file obs-service-source_validator In addition to that please install "osc" from openSUSE:Tools:Unstable project. If you do not like to add the repo, just run osc getbinaries openSUSE:Tools:Unstable osc $YOUR_REPO $YOUR_ARCH and install the osc package manually. To activate this for your entire devel project (it would work also per package) do # osc co $YOUR_DEVEL_PROJECT _project # cd $YOUR_DEVEL_PROJECT/_project # cat > _service <<EOF <services> <service name="format_spec_file" mode="trylocal"/> <service name="download_files" mode="trylocal"/> <service name="source_validator" mode="trylocal"/> </services> EOF # osc addremove # osc ci -m "activate factory default source services" Afterwards these services running on "osc build" and "osc commit" actions, if not disabled via CLI switch. Reformated spec files will be uploaded directly and in case of validation errors, osc will abort before commit/build'ing. What happens to people with old osc version (0.130 and before) or just using the webui after activating these services ? Nothing. The services will run on the server only. => The source state will turn into "broken" if a validation error exists. => if tar ball is missing/different or spec file is different formated they will be visible with _service:* prefix again. How to get rid of them again ? Just anyone with a current osc stack will merge these changes automatically on next commit and the server side generated files will disappear again. If this testing phase works out fine, we will of course make a maintenance update for all these packages, so everybody should have a current stack. I have activated this already for the openSUSE:Tools* projects and everything seems to work. And I found out that 3 out of 3 random packages from openSUSE:Factory contain broken Source: $URL lines ;) Feel free to branch any openSUSE:Tools package into your branch and try to edit it. With the new osc you will use these local services automatically. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

1 0

[opensuse-buildservice] Fwd: qwt6 package in your opensuse buildservice home
by Robert Riemann 25 May '11

25 May '11

Hi all, we are talking about packages (qwt6, ...) in home:koprok:Factory. Any hint how to make one of the packages a noarch one, when creating multiple rpms out of one spec file? Kind regards, Robert ---------- Forwarded message ---------- From: Todor Prokopov <koprok(a)nand.bg> Date: 2011/5/25 Subject: Re: qwt6 package in your opensuse buildservice home To: Robert Riemann <saloution(a)googlemail.com> Hello Robert > I think you can add one line "arch: noarch" to such a non-binary package lik this to produce an architecture-independant package. This saves disc space and build-time. ;) I have tried to add "BuildArch: noarch" at the top of qwt.spec file. But this makes ALL of the built packages noarch, i.e. libqwt6, qwt-devel, qwt-examples, qwt-designer, all of them become noarch. This is an error. Maybe I have to dig into other rpm spec files for examples of how to make only qwt package noarch, or maybe ask some more experienced rpm guru :-) If you have any ideas - they are welcome! Until then - I leave it like this. Best regards, Todor -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

[opensuse-buildservice] Associate a set of workers to a package build
by Praveen_Paladugu＠Dell.com 24 May '11

24 May '11

Is it possible to associate the build of a package/image on OBS to a set of workers? The workers in our private OBS are running out of space while building some Live Images. So, we are wondering if it is possible to increase the disk space on only a few workers and somehow setup an affinity to get the builds of these huge images on those workers. By having the option to set such affinity, we don't have to increase the disk space on all the workers of our OBS. Thank you Praveen K Paladugu Dell Linux Engineering -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

[opensuse-buildservice] source services and spec file in git
by guillem.pages-gassull＠nokia.com 23 May '11

23 May '11

Hi, I was trying to use source services, to automatically fetch the sources from a git repository, including the spec file, and start building. In my "_service" file I have a "tar_scm", "extract_file", "recompress" and "set_version", but here, only the first two are relevant. My repository actually contains more than one sub-project, so I was using the "subdir" option in tar_scm to only get the sources I need. <service name="tar_scm"> <param name="url">git@192.168.1.1:Blub/git/BigGit</param> <param name="scm">git</param> <param name="subdir">hello1</param> <param name="exclude">.git*</param> <param name="filename">hello1</param> </service> After some trial-and-error, I managed to extract the spec file: <service name="extract_file"> <param name="archive">*hello1*tar</param> <param name="files">*/hello1.spec</param> <param name="outfilename">hello1.spec</param> </service> But then, I was getting an error from the service daemon: Unexpected EOF. In the /srv/obs/log/src_service.log I could see the lines: Use of uninitialized value $r in numeric eq (==) at /usr/lib/obs/server//BSHTTP.pm line 338. Use of uninitialized value $r in subtraction (-) at /usr/lib/obs/server//BSHTTP.pm line 342. Use of uninitialized value $r in numeric eq (==) at /usr/lib/obs/server//BSHTTP.pm line 338. Use of uninitialized value $r in subtraction (-) at /usr/lib/obs/server//BSHTTP.pm line 342. Use of uninitialized value $r in numeric eq (==) at /usr/lib/obs/server//BSHTTP.pm line 338. Use of uninitialized value $r in subtraction (-) at /usr/lib/obs/server//BSHTTP.pm line 342. . I managed to track it down to an empty directory left over after unpacking the file. After that, I added a line at the end of extract_file, so that empty directories are removed. And now it works. Does anyone have a better idea, or some hints that I might be doing something wrong? Or see any problems with this? Otherwise, I am attaching a patch, in case you want to apply it. Kind Regards, Guillem

2 2

[opensuse-buildservice] Feature request? Web ui package details
by Dave Plater 21 May '11

21 May '11

I've always wished for an easy to access rpm file list in the package rpm details (possibly parsed from the spec file?), recommends suggests and friends could also be parsed from the spec file. I'd do it myself but it'd take too long, it's a useful and to me apparently easy to implement with php. Dave P -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 2

[opensuse-buildservice] php-zip and Enterprise Editions
by Johannes Weberhofer 20 May '11

20 May '11

Is there a special reason, why php-zip is not available for SLES, RHEL and CentOS repository? Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1