Hello,
I have been working on an import tool from the build service into git
repositories; the result seems to be basically working now. It is available
as:
home:agruen:Factory/bsgit
The git repository is available at:
http://git.opensuse.org/?p=people/agruen/bsgit.git
Exporting changes into the build service is not supported yet, but it's a
start. Integration into osc also hasn't happened, yet.
The tool tries to be nice to the server and not request the same data over and
over again. Still, when fetching a package, this retrieves all the package's
revisions unless you create a shallow copy using bsgit's --depth=N option.
So please do not blindly fetch huge packages with a long history just to see
what happens. (What would happen is pretty clear -- I would get into
troubles with the build service maintainers!)
Here is how to use bsgit:
$ mkdir stuff
$ cd stuff
$ git init
$ bsgit fetch home:agruen:Factory bsgit
Fetching home:agruen:Factory/bsgit (1)
Fetching home:agruen:Factory/bsgit (2)
Branch 'bsgit' created.
$ git branch -a
* bsgit
remotes/api.opensuse.org/home/agruen/Factory/bsgit
$ bsgit pull
Fetching home:agruen:Factory/bsgit (3)
Branch 'bsgit' updated.
$ bsgit fetch
Already up-to-date.
Observe that bsgit created a remote branch with a long name that encodes the
server, project, and package. This is the state of the package in the build
service. A local branch, 'bsgit', tracks that remote branch. You may make
changes on the local branch.
When you fetch a package, this will leave the local branch alone (except for
creating it when it doesn't exist). A pull does a fetch, followed by a
rebase of the local branch. (It doesn't do a merge because we will not be
able to export merges to the build service anyways, at least not with the
current backend.)
When bsgit detects a source link, it creates a remote branch for the target
package as well (i.e., the package linked to), and it expands the source
link.
Source links are expanded against the revision of the target package that they
were *created* against. Very unfortunately, the build service backend does
not record the revision it creates a source link against. Until that is
fixed (and I hope soon!), some guessing is involved, and some source links
may be expanded against the wrong revision.
Here is a source link example:
$ bsgit clone home:coolo:branches:home:darix:Factory FastCGI
Fetching openSUSE:Factory/FastCGI (1)
Fetching openSUSE:Factory/FastCGI (2)
Fetching openSUSE:Factory/FastCGI (3)
Fetching home:darix:Factory/FastCGI (1)
Fetching home:coolo:branches:home:darix:Factory/FastCGI (1)
Fetching home:coolo:branches:home:darix:Factory/FastCGI (2)
Branch 'FastCGI' created.
$ git branch -a
* FastCGI
remotes/api.opensuse.org/home/coolo/branches/home/darix/Factory/FastCGIremotes/api.opensuse.org/home/darix/Factory/FastCGIremotes/api.opensuse.org/openSUSE/Factory/FastCGI
Cheers,
Andreas
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hello,
whether I add "Packager" in a spec file or not, rpmlint complains in both
cases. One time because of hardcoding. The other time because it is
missing.
Could this please be fixed?
What I would like to see is that the buildservice-email-address also used
in the GPG key of the repository is automatically copied into the spec
(like e.g. changelog or revision).
Is this possible (thought that would not fix the hardcoding error
message) or can the name+email be added in the build command directly?
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
A new osc release, version 0.117 is out. This one has as main features
the long awaited "repairlink" functionality to fix broken source links due to
conflicting source changes and also tool support to maintain the .changes file
easier.
"osc repairlink" was implemented by Michael Schroeder. It checks out a package
with merged source changes. It usesa 3-way merge to resolve file conflicts.
After reviewing/repairing the merge, 'osc ci' will re-create a working source
link.
"osc vc" was implemented by Michal Vyskocil and can collect commit messages to
prepare a changelog entry in the .changes file.
Please note that the entries there get read by users of the package, so commit
messages like "get it building" or "yet another try to get the patch applied"
are not helpfull for them and should get removed from the .changes file.
An alternative solution to maintain the changelog is to call "buildvc"
directly, which gets provided by the also released build.rpm
There are also a number of bugfixes and improvements inside to make your life
easier:
* You do not need to specify project and package anymore on "osc getbinaries"
when your cwd is a checkout package.
* "osc branch" got a new option to define a different branch project name.
* "osc branch" got a new option to checkout the package directly after
branching
* "osc co PACKAGE" works inside of a checked out project directory
You can find the latest version of osc and build rpms in openSUSE:Tools
project as usual.
http://download.opensuse.org/repositories/openSUSE:/Tools/
I hope this makes your life much easier now :)
bye
adrian
--
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
Hi,
is it possible to have the network:/utilities also built for SLES9?
Or is there a major problem with that?
--
Mit freundlichen Gruessen,
Andreas Vetter
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
we have problems doing a local build against our own OBS. It seems like osc
tries to fetch the base packages from a location which is not available on
our OBS. See below:
osc build --alternative-project open-xchange-snapshot DebianEtch i586 *.dsc
Building open-xchange-admin-soap_6.9.0.0-0.dsc for DebianEtch/i586
Getting buildinfo from server
Updating cache of required packages
Trying upstream server for perl-base (Debian:Etch), since it is not on
buildservice.netline.de.
Trying upstream server for perl-base (Debian:Etch), since it is not on
buildapi.netline.de.
Error: No more mirrors to try.
Failed to retrieve perl-base-5.8.8-7etch4.i386.deb from the following
locations (in order):
file:///var/tmp/osbuild-packagecache/Debian:Etch/standard/i386/perl-base-5.8.8-7etch4.i386.deb/
http://buildservice.netline.de/repositories/Debian:Etch/standard/i386/perl-…http://buildapi.netline.de//build/Debian:Etch/standard/i586/_repository/per…
Can anybody tell me how this must be configured? I've already searched the
websides, but I don't find a solution to this.
Thanks in advance,
Dennis
Hi dear all,
osc build always use /var/tmp/build-root and /var/tmp/osbuildpackages
as root and rpm cache.
This bothers me because my / partition is quite small.
Is there any way to use some other directory?
build has the --root option but I don't know how to use this option in
"osc build".
Thanks,
Fred
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi !
In preparation to my GSoC project (openSUSE@arm) I'd like to propose this patch of Build.pm for inclusion into the Build Service code.
===================================================================
--- Build.pm (Revision 7227)
+++ Build.pm (Arbeitskopie)
@@ -216,6 +216,9 @@
$config->{'patterntype'} = [ @l ];
} elsif ($l0 eq 'release:') {
$config->{'release'} = $l[0];
+ } elsif ($l0 eq 'changetargetarch:') {
+ @macros = grep {$_ !~ /^%define _target_cpu/ } @macros;
+ push @macros, "%define _target_cpu @l";
} elsif ($l0 !~ /^[#%]/) {
warn("unknown keyword in config: $l0\n");
}
Reasoning:
Some lines above in Build.pm %_target_arch gets set to the scheduler arch (scheduler name).
In ARM world this is a bit more complicated - e.g. there's armv5tel, armv5tejl, armv5tevl .
This is no problem in debian world IIRC as we see so far in Mer.
Unfortunately rpmbuild needs to know the right value (armv5tel instead of armv5el).
It would be bad to use now different schedulers only for tel/tejl/tevl and so on.
So with my patch we can use still the armv5el scheduler and differ through
"changetargetarch:" the _target_cpu where needed.
Best,
Jan-Simon
Hi !
Now as we have an average build time, i thought it would be great to get an
approximation of the ETA for a build to start . But i found that this
wouldn't work right now as we use
for my $job (List::Util::shuffle(@b)) {
-> random job selected in the dispatcher.
Thus there's no fixed list of jobs which could evaluated.
Any ideas ?
Best,
Jan-Simon
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
I have a problem with a package that builds fine locally, but when build on
the Build Service the build fails. The package that shows the problem is
server:php:applications horde-util, at the bottom of this email I included the
end of the local build log. As you can see the package passes the rpmlint
test and all seems fine.
On the build service however, the build stops rather quickly with the
following error:
installing php5-pear-5.2.6-49.11
installing horde-token-0.0.4-5.1
Package "/var/lib/pear/Horde_Token.xml" is not valid
install failed
error: %post(horde-token-0.0.4-5.1.noarch) scriptlet failed, exit status 1
mount: can't find / in /etc/fstab or /etc/mtab
System halted.
The post script is:
%post
pear install --nodeps --soft --force --register-only %{xmldir}/%{prj}.xml
With %{xmldir} and %{prj} respectively defined as %{_var}/lib/pear and
Horde_Token.
So I downloaded the horde-token package from the repository and installed it
manually using chroot in the created local build environment. This all works,
now why does it fail at the server???
med:/usr/tmp> pear uninstall --nodeps --ignore-errors --register-only
pear.horde.org/Horde_Token
warning: "horde/Horde_Token" is required by installed package horde/Horde_Form
warning: horde/Horde_Token should not be uninstalled, other installed packages
depend on this package
uninstall ok: channel://pear.horde.org/Horde_Token-0.0.4
med:/usr/tmp> pear install --nodeps --soft --force --register-only
/var/lib/pear/Horde_Token.xml
install ok: channel://pear.horde.org/Horde_Token-0.0.4
med:/usr/tmp> echo $?
0
As (many) packages depend on horde-util, it is a bit awkward that this
happens. Does any one see, what I should see to prevent this problem? What
is different on the Build Server, compared to a local build? The horde-util
spec file is similar to many other horde-* spec file, and all those others
build fine.
/me puzzled...
--
Richard
Wrote: /usr/src/packages/SRPMS/horde-util-0.1.0-0.src.rpm
Wrote: /usr/src/packages/RPMS/noarch/horde-util-0.1.0-0.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.35682
+ umask 022
+ cd /usr/src/packages/BUILD
+ cd Util-0.1.0
+ /bin/rm -rf /var/tmp/horde-util-0.1.0-build
+ exit 0
... checking for files with abuild user/group
... running 00-check-install-rpms
... installing all built rpms
error: failed to stat /sys/kernel/debug: No such file or directory
Preparing packages for installation...
horde-util-0.1.0-0
install ok: channel://pear.horde.org/Util-0.1.0
... running 01-check-debuginfo
... testing for empty debuginfo packages
... running 02-check-gcc-output
... testing for serious compiler warnings
(using /usr/lib/build/checks-data/check_gcc_output)
(using /var/tmp/build-root-openSUSE_11.1-i586/.build.log)
... running 03-check-binary-kernel-log
... running 04-check-filelist
... checking filelist
... running 05-check-invalid-requires
... running 06-check-installtest
... testing for pre/postinstall scripts that are not idempotent
install ok: channel://pear.horde.org/Util-0.1.0
... running 08-check-permissions
... testing for modified permissions
... running 09-check-packaged-twice
... running 10-check-lanana
... running 11-check-pkgconfig-deps
... testing devel dependencies required by pkgconfig .pc files
... running 12-check-libtool-deps
... testing devel dependencies required by libtool .la files
(can be skipped by "skip-check-libtool-deps" anywhere in spec)
... running 13-check-invalid-provides
... running 14-check-gconf-scriptlets
... testing GConf scriptlet presence
... running 99-check-remove-rpms
... removing all built rpms
(order: reverse horde-util)
error: failed to stat /sys/kernel/debug: No such file or directory
uninstall ok: channel://pear.horde.org/Util-0.1.0
RPMLINT report:
===============
2 packages and 0 specfiles checked; 0 errors, 0 warnings.
med finished "build horde-util.spec" at Thu Apr 30 23:41:01 CEST 2009.
/var/tmp/build-root-openSUSE_11.1-i586/usr/src/packages/SRPMS/horde-
util-0.1.0-0.src.rpm
/var/tmp/build-root-openSUSE_11.1-i586/usr/src/packages/RPMS/noarch/horde-
util-0.1.0-0.noarch.rpm
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
I'm maintaining a php/pear package. This one normally builds fine, but today
I noticed that it builds kde! Why is that?
horde-token> osc bl openSUSE_11.0 i586 | grep kde | head
/usr/lib/python2.6/site-packages/osc/conf.py:326: DeprecationWarning: Use of
the 'scheme' or 'apisrv' config option is deprecated! See README for migration
details.
DeprecationWarning)
build22 started "build mono-kde4.spec" at Thu Apr 30 08:17:07 UTC 2009.
Building mono-kde4 for project 'home:snorp' repository 'SUSE_Factory' arch
'x86_64' srcmd5 '2e0606141c34d28ff28c8f4940138e88'
processing specfile /abuild/root_4/.build-srcdir/mono-kde4.spec...
running changelog2spec --target rpm --file /abuild/root_4/.build-srcdir/mono-
kde4.spec
init_buildsystem --prepare --clean --rpmlist /abuild/root_4/.build.rpmlist
/abuild/root_4/.build-srcdir/mono-kde4.spec build rpmlint-Factory ...
processing specfile /.build-srcdir/mono-kde4.spec...
init_buildsystem /.build-srcdir/mono-kde4.spec build rpmlint-Factory ...
The concerning package that I'm working on is server:php:applications
horde-token. This package has no reference to kde or what so ever:
horde-token> grep kde *
richard@med111:~/packages/osc/server:php:applications/horde-token> ls
Horde_Token-0.0.4.tgz horde-token.changes horde-token.spec log
Is there something broken on the server??
--
Richard
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org