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