Hello!
Currently there is no way to link to a package built on the build service
because if we do so this link will break on every rebuild since the release
number will change.
Because of that I recommmend to automatically create symbolic links without
the version number as we have in the update directories on ftp.suse.com. For
example:
zypper.rpm -> zypper-0.6.15-0.1.i586.rpm
If we do so we can just link to
http://software.opensuse.com/download/.../packagename.rpm. This link will
never break due to an automatic rebuild.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
Hi,
Short changelog:
- new "search" command
- new "meta" command
- initial support for commit messages
- new "log" command (commit log)
Full changelog:
- added initial search support (some ideas are taken from the webclient):
* when searching a package/project it
is also possible to search for the search term
in the <title /> and <description /> elements of
a package/project.
* show only exact matches
- new meta command, replacing editmeta, editprj, createprj,
editpac, createpac, edituser. Can either show existing meta, or
edit it (--edit), or upload content (--file). Fix metadata
change detection, which no longer relies on the timestamp of
the temporary file.
- log:
- renamed previous "log" command to "buildlog" (short: bl)
- implementing a log command to review the commit log
- commit:
- commit: implemented -m and -F option for the commit message.
NOTE: if -m is used, osc uses a different mode of uploading
files and commit them, namely the way which is currently
documented in the api. So far, osc was uploading each file
separately through the old backward compatible way. This way
of committing can also be forced with do_commits = 1 in
.oscrc.
- other changes:
- api now sends HTTP/1.1 400 Bad Request for invalid xml. Thus,
show the reply body because it contains helpful info.
- if PUT on metadata fails with a 500, and http_debug is True,
print out the body of the server reply
- improved exception handling in some places
- updatepacmetafromspec: read spec files in utf-8, or whatever
the preferred encoding is in the locale
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
SLES9 ships with Python 2.3. With my latest code changes, I noticed that
I changed things in a way incompatible to Python 2.3 (using decorators).
(I basically noticed this because byte-compiling failed according to the
build log, although the build didn't actually fail due to that. I saw it
by pure luck.)
This can easily be fixed, so I removed the decorators and started to
test osc on SLES9, and found more problems on the way.
Python 2.3 didn't have a cookielib module, and it is not easy to add it
because parts of it live integrated in the urllib2 module. Still, it is
straightforward to just skip cookie support if not available.
But there were further problems, which prevent the current codebase from
working with Python 2.3. I fixed some further issues, and got as far as
to a working 'osc build'.
However, the next problem I'm facing is that I can't commit files (gets
an internal server error back), and since urllib2 is not as easy to
debug as newer versions, I stopped there for now.
Overall, the situation gives me the impression that osc hasn't been
working on SLES9 lately, or maybe since a long time, and nobody did ever
complain about it.
The download statistics show 6 or 7 osc package downloads in the
last 50 days for SLES9.
What do you think. Is it worth pursuing this further? Or should we maybe
simply no longer build osc for SLES9?
All other platforms in the buildservice seem to have Python 2.4 or
newer.
Peter
--
Allen Gewalten zum Trutz sich erhalten.
SUSE LINUX Products GmbH
Research & Development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yesterday I've written a very nice addition for our packager toolbox: a
command-line client for Benjamin Weber's excellent openSUSE Package
Search service (aka webpin).
Very useful to find in which package a file (e.g. a shared lib or a
header) is available, or to find out whether someone already packages
foobar or not.
More information here:
http://dev-loki.blogspot.com/2007/07/webpin-command-line-client.html
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGrFnTr3NMWliFcXcRAiSbAKCjK8XIkHTST6Sjrn2OzLNxsokSQgCgtJ9p
SPki9j62fxfqm16rMP6ZzPA=
=0DQs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
the build service is supporting the storage of pattern files from now on.
Additionally it does create .ymp files for each repo from it.
.ymp files (read One-Click install files) are very usefull to make it easy for
your users to install a set of packages.
We will also highlight ymp files in the new End-User interface comming to
software.opensuse.org next week. This means, if a ymp file does match the
user search request, it will be shown on top of the search list. Any other
matches will come afterwards.
There is no need to create patterns just for one package, because the new
End-User interface will create them on the fly when a user clicks on a
package to install.
So, if you want to create also pattern files for your project, have a look
here:
http://en.opensuse.org/Build_Service_Tutorial#Create_Patterns
Example pattern files can be also found in the KDE:KDE4 project, the resulting
ymp files are here for example:
http://download.opensuse.org/repositories/KDE:/KDE4/SUSE_Factory/
The api is validating your files on uploading, so have a deeper look on the
output, if you get an error on uploading. But it is really easy to create
patterns based on the example files.
happy to help you in case of trouble :)
adrian
--
Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
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
I began using buildservice today.
I am trying to build the gnome-subtitles mono project. I can build it on OpenSuse 10.1. I am using SUSE_Linux_10.1 and openSUSE_10.2 repositories in i586 and x86_64 architectures.
My openSuSE builds fail during configure with:
configure: error: gnome-doc-utils >= 0.3.2 not found
even though I have 'BuildRequires: gnome-doc-utils' in the spec file.
The SUSE_Linux_10.1 builds fail much later, even though they use the same source tarball and spec file.
scrollkeeper-update -p
/var/tmp/gnome-subtitles-0.6-build/var/lib/scrollkeeper -o
/var/tmp/gnome-subtitles-0.6-build/usr/share/omf/gnome-subtitles
Could not create directory /gnome-subtitles-0.6-build : Permission denied
Could not create database. Aborting update.
Cannot write to log file: /var/log/scrollkeeper.log : Permission denied
Cannot write to log file: /var/log/scrollkeeper.log : Permission denied
make[2]: *** [install-doc-omf] Error 1
The command lines look right - all referring to $RPM_BUILD_ROOT (/var/tmp/gnome-subtitles-0.6-build).
Any ideas?
Does BuildRequires control the packages added to the chroot environment?
Damien
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
I have some more build service questions:
(1) On my create home project page, it says:
Please ask on opensuse-buildservice(a)opensuse.org mailing list
before creating projects outside of your home:<login>
namespace.
So does this mean that you can create subprojects of your
home:<login> namespece? How deep can subprojects be nested?
The feature we were discussing yesterday:
<publish>
<disable />
</publish>
Can that be per sub-project, so that you can have some public
subprojects and some private?
(2) On the Workflows page:
Edit Packages
add files
add sources (http source, svn/cvs source)
edit spec file (using web ui)
add/remove users
change version
What is the difference between a source and a file?
Can a source be a FQDN like source0 in a spec file?
Explain what svn/cvs source is like. Does it have to refer
to the buildservce svn/cvs?
--
Paul Elliott 1(512)837-1096
pelliott(a)io.com PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/ Austin TX 78758-3117
Hi !
Whats your estimation ... how hard/possible/impossible is it to setup obs
on/for a PPC target ?
We could need a probably mixed env, because intel* and ppc are used here.
Would it be easier to use 2 separate setups (intel + ppc) or can it be done
with e.g. sched/repserver on intel and workers on intel + ppc (which i
thought should be possible).
Greets
Jan-Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
