openSUSE Build Service July 2007

buildservice@lists.opensuse.org

54 participants
59 discussions

[opensuse-buildservice] ANN: osc 0.97 release

by Dr. Peter Poeml

Hi, I would like to announce a new release of osc. The major changes are listed below. Marcus Huewe contributed significantly to this release. He also implemented what I consider the most important advance: - added initial revision handling: - extended "osc co prj pac" to checkout a specific revision of pac - extended "osc up" to update to a specific revision - extended "osc diff" to diff the working copy against a specific revision on the server. The following change gives you the opportunity to implement new subcommands (or change existing commands) without touching the osc package (if there is interest in this, I can write a howto): - load subcommands from /var/lib/osc-plugins/ or ~/.osc-plugins/ Then there is a number of new commands and new options: - new commands: wipebinaries, abortbuild, info - for all server-side commands, allow arguments "foo/bar" instead of "foo bar" - updatepacmetafromspec scans for spec files automatically. Also added a --specfile option. - ls: add --verbose option to print extra information for packages - build: --extra-pkgs option, --prefer-pkgs and --keep-pkgs option - implement 'info' subcommand - copypac: implement package copy from one buildservice instance to another (--to-apiurl option) For those who didn't know it yet, there is a feature which makes working with multiple api servers easier: - memorize the used server in the working copy Some of the above changes are not really recent, but I thought I'd list them for those who might have missed them so far. Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development

14 years, 11 months

[opensuse-buildservice] Minutes of build service meeting at SUSE 2007-07-06

by Dr. Peter Poeml

Build service meeting at SUSE, 6. July 2007 mls, darix, tscholz, poeml, lrupp Topics: (1) commit method (2) local build of linked packages (3) method of sending files for buildinfo (4) diff (5) osc: log/buildlog (6) wipe (7) osc: editing project config (8) api version enforcement Action Items: - poeml, mls: talk to Andreas Bauer about committing files and necessary api changes - poeml: implement new commit method in osc - poeml: ask on opensuse-buildservice for osc log/buildlog command - mls: see how well the code handling linked packages can be separated and placed in build.rpm - poeml: for buildinfo, parse rpm headers of local packages and send along buildinfo request - abauer: check whether / how requests on /source/prj/pac could provide information about linked packages (see (2)) - abauer: check if diff route allows file= and ofile= parameters in the query string - mls implement "single file diff" - poeml: finish osc's project config editing feature - poeml: let osc send api version, as a first step - lrupp: check if selective wipe command really doesn't work :-) (1) commit method Committing files to the backend is going to be atomar in the future, and planned to happen like this: 1) client sends list of files' md5sums to server 2) server checks which files are already in the repo, and replies with list of "missing" files 3) client POSTs files (possibly packed together as cpio? See (3). Possibly compressed to save bandwidth) Implementation status: backend already supports this. API needs to be extended to pass through the POST request. osc needs to be changed for this. How about compatibility to old clients? (2) local build of linked packages Exhaustive list of _link file features: http://opensu.se/~darix/link.xml.txt Questions: - whether to handle this on the server or client side - whether _link file contents should be stored as XML metadata instead - whether _link contents (and patches) are "metadata" at all, or "source" the distinction is relevant with regard to triggering rebuilds. Generally, there are properties which may trigger a rebuild, and others which may not. Now, metadata changes do not trigger rebuilds, source changes do. Use cases: - linked package, local build, either a) the sources and patches need to be send to the server and the patched sources returned to the client for building, or b) or the the client needs to implement the same logic as the server, and possibly needs to check out all packages linked to and apply the patches - link to locally modified package (hardly possible to handle this on the server side) - link to other link (no problem for the server) - when trying to check in changed sources, but encountering a "not allowed", create a linked package on-the-fly and commit the local changes as linked package instead. a.k.a. "Adrian use case" ;-) Extension to this train of thought: Possibly submit a "merge request" Theoretically, a /source/prj/pac request should provide information about linked packages, where applicable (like: package and project linked to) (3) method of sending files for buildinfo osc needs to send two things to the backend for calculation of the buildinfo: a) the specfile b) provides/requires lists of local packages which should be used in the server-side expansion The request will be a POST with a a) and b) encoded together as cpio. The provides/requires come as P:x,y,... R:x,y,... lists. (4) diff "osc diff" of the working copy against old revisions is implemented (Thanks, Marcus!). This is done via a temporary checkout of the revision in question. There is a server-side diff provided by the backend for an arbitrary revision against another one. This has the advantage of being "intelligent" (by noticing renames and diffing tarball contents) and the disadvantage of working only on package level (so it can't be used to diff a single file). We decided to add a way to diff single files. Thinking about the needed API, it was felt that the simplest thing is to add file= and ofile= query parameters, resembling the rev= and orev= parameters, which means that the api route probably doesn't need a change. (5) osc: log/buildlog Question: - should the osc log subcommand be renamed to buildlog (bl), so log can be used to retrieve the commit log? -> ask users for feedback Also to do: change the log/buildlog command to work without a checked out working copy (6) wipe Users want a command to wipe all packages which have been built already, but for which "publishing" has been later disabled. Selective wiping is implemented for packages marked with build=disabled. (If this wipe doesn't work as expected yet, there might be a bug in the current implementation. Please check, and report failures.) Question: - is it sufficient if there is a way to wipe all packages for which _build_ is disabled (vs. "publishing disabled" or other properties) ? It might be enough, since users could wipe the entire repo and then build the desired packages again. - how to do this in a way compatible to package renames? Actually, there is no facility to rename packages anyways. There is only a copy (client side in osc). Michael says that the backend's repository handling might need a rewrite, in order to properly track disabling/enabling packages (so to be able to keep old versions in the repo as long a package is disabled). Such a rewrite is also needed to support clustering. (7) osc: editing project config - A facility in osc to edit project configuration is work in progress, but takes a little time because I'm cleaning up code for that and want to clean up the other metadata editing facilities first. (8) api version enforcement - the osc client should send the api version it is known to support. - the api should should return "412 Precondition Failed" if the site administrators decide to depracate old clients and a client isn't up to date enough. - the client needs to provision for this condition, and error out. Open question: can this be performed in a way that a user, who is forced to update the client, can still have a client wich is functional with other (e.g. local) buildservice instances. If the client doesn't stop working, but only issues a warning, the server can't reply with HTTP code 412. But it can perhaps add a warning header line which is seen by the client, which issues a warning then. Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development

14 years, 11 months

[opensuse-buildservice] osc commands for showing/editing metadata

by Dr. Peter Poeml

Hi, while looking at adding support for editing project configuration, I thought that I'd like to organize osc subcommands that show or change metadata in a more consistent way. I have written down some ideas, that involve some renaming, and I'm wondering what would make most sense to most people: 1) current: new (read): new (write): usermeta,edituser showuser edituser meta,editmeta showpacmeta editpacmeta meta,editprj showprj editprj meta,editpac showpac editpac updatepacmetafromspec editpac --fromspec - showprjconf editprjconf This swamps the "osc help" output with new commands... but they will at least appear together, since alphabetically sorted... 2) Only have a "showmeta" and a "editmeta" subcommand, which take their own subcommand specifying what kind of metadata to work on: showmeta user showmeta prj showmeta prjconf showmeta pac editmeta user editmeta prj editmeta prjconf editmeta pac [--fromspec] 3) Or maybe even put them under a single subcommand, "meta": meta [--edit] user meta [--edit] prj meta [--edit] prjconf meta [--edit] pac Anyone has an opinion on that? Thanks, Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development

14 years, 11 months

[opensuse-buildservice] Telephony packages

by Matt White

Anybody know what happen to the packages at: http://software.opensuse.org/download/server:/telephony/ I had grown dependent on the openser and rtpproxy packages. If anybody knows where I can redownload these for SLES 10 I would appreciate. I do see some openser packages here : http://software.opensuse.org/download/server:/messaging/SLE_10/i586/ But not all the dependencies resolve. Missing libfreeradius client and others and there is no rtproxy. Thanks! This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

14 years, 11 months

[opensuse-buildservice] Unable to upload 250MB source tarball via webclient

by Ladislav Michnovič

Hi. I'm unable to upload 250 MB large tarball to my project(lmich) package openarena. Regards Ladislav. OpenSUSE Webclient Error: Error Details: Errorcode: 500 Message: failed to allocate memory Exception from Webclient: NoMemoryError: failed to allocate memory Stack Trace: (eval):3:in `read' (eval):3:in `read' /srv/www/opensuse/webclient/current/public/../config/../app/models/package.rb:19:in `save_file' /srv/www/opensuse/webclient/current/public/../config/../app/controllers/package_controller.rb:344:in `save_file' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/base.rb:1095:in `perform_action_without_filters' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:632:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:638:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:438:in `call' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:637:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:638:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:438:in `call' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:637:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:638:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:438:in `call' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:637:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:638:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:438:in `call' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:637:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:638:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:449:in `call' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:637:in `call_filter' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:619:in `perform_action_without_benchmark' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /usr/lib64/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/rescue.rb:83:in `perform_action' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/base.rb:430:in `process_without_filters' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/filters.rb:624:in `process_without_session_management_support' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/session_management.rb:114:in `process' /usr/lib64/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/base.rb:330:in `process' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:41:in `dispatch' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:168:in `process_request' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:143:in `process_each_request!' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:109:in `with_signal_handler' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:142:in `process_each_request!' /usr/lib64/ruby/1.8/fcgi.rb:612:in `each_cgi' /usr/lib64/ruby/1.8/fcgi.rb:609:in `each_cgi' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:141:in `process_each_request!' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:55:in `process!' /usr/lib64/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:25:in `process!' /srv/www/opensuse/webclient/current/public/dispatch.fcgi:24 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

14 years, 11 months

[opensuse-buildservice] x86_64 cannor find the spec patch after it actually used the patch

by Truth

Hi all, I linked pidgin and patched on the code with a patch for spec and a patch for source code. Today I removed the old spec patch and uploaded a new spec patch. It displayed "Added Patch" rather than the old "Global Patch". Then x86_64 couldn't build while i586 built fine. When building for x86_64, it seemed that it already patched the spec file actually then reported the patch for spec "no such file or directory " as an error. x86_64 build log: http://build.opensuse.org/package/live_build_log?package=pidgin&repository=… i586 build log: http://build.opensuse.org/package/live_build_log?package=pidgin&repository=… Please have a check on this. Something wrong with scripts? Regards, Thruth --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

14 years, 11 months

[opensuse-buildservice] How to name stable, development and edge packages?

by Lars Marowsky-Bree

Hi all, we (as in, Andrew and myself for the Linux HA project) maintain server:ha-clustering packages, in particular heartbeat. Now, for that, Andrew maintains a stable build which we're actually recommending to users, and I do a daily build in my home project, build with some scripts from Andrew's because _link isn't powerful enough. I'd like to make that more "official" and move it out of my playground. Is there already a naming convention for that? 1) I could add them to server:ha-clustering as heartbeat-snapshot, plus obsoletes/provides lines. I think that would be kind of ugly. 2) I could create a new project to build them, which wouldn't be quite as ugly, but then - what to name it? I like 2) best and would like to suggest we create a (CURRENT|DEVEL) top-level distinction, because I don't think we're the only ones with this issue. Then user's would automatically know where to go look for the development snapshots. What do you think? Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

14 years, 11 months

[opensuse-buildservice] Problems with Ubuntu Dapper (6.06) on local buildservice installation

by Stephan Hermann

Good morning colleagues, yesterday I played around with configuring Ubuntu Distros on a local installed opensuse buildservice. I imported all packages for Ubuntu Dapper into /srv/obs/build/UBUNTU:DAPPER/standard/{x86_64,i586}/:full (*_all.debs are in both directories available). I pushed all packages, means from Ubuntus Repositories named main, restricted, universe multiverse). Now I get a message which tells me that "nothing provides libasound2 > 1.0.10 needed by libesd-alsa0" Which is somehow strange. libasound2 is there in version 1.0.10-2ubuntu4. Reading the binary package description on http://packages.ubuntu.com/dapper/libs/libesd-alsa0 it needs libasound2 (>> 1.0.10) The operator >> means >= so, 1.0.10-2ubuntu4 (the version in the repositories for dapper) is definitly greater then 1.0.10. How can someone fix this? Thx for you help in advance :) \sh -- Stephan Hermann eMail: sh(a)sourcecode.de Blog: http://linux.blogweb.de/ JID: sh(a)linux-server.org OSS-Developer and Admin

14 years, 11 months

[opensuse-buildservice] Wrong filesize is shown in the BS web interface

by Ladislav Michnovič

Hello. After uploading a new tarball to my home project, the web interface is showing wrong size of the tarball. It shows 27 MB but it should be 2.7 MB. The file is not corrupted, just the number displayed on the webpage is wrong. Regards Ladislav Michnovic.

14 years, 11 months

[opensuse-buildservice] python problem on the build service

by Peter Nixon

Hi Guys There seems to be a problem on the build service with python packages. Some packages have been continuously building since last night: http://build.opensuse.org/project/monitor?project=devel%3Alanguages%3Apython They are: python-django-registration python-django-snapshot python-markdown I updated them last night, and when they rebuilt they failed with a " python is needed by python-markdown-1.6a-7.1" error. (Error message is different for each package obviously) I thought, "thats weird, python-devel should pull in python", but added python to the BuildDependency line as a quick fix. However, the packages are continuously rebuilding and failing with the same error, over and over and over again.... Can someone please have a look at it? They all build perfectly when built locally with "osc build" TIA -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

14 years, 11 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service July 2007