-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> How can I know what has triggered a rebuild in the build service
> repositories? I know that a rebuild can be triggered by a changed
> dependency, or by hand. But, since the packages change frecuently
> (thinking mainly kde) I'm interested in knowing which changes or what
> has caused the rebuild or version change (something like a changelog)
Shouldn't this be on the build service list. I am adding it. I think
this would have a better audience on that list.
Thanks,
- --
Boyd Gerber <gerberb(a)zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQFE7yugVtBjDid73eYRAvcMAJ0VGty1oCw518BCIbeoOJuDRsHppwCdFbE7
U66YfJf1UO9H5/Pq4hWaFE4=
=cmFI
-----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,
can anyone tell me why the version number of kernel-default and
kernel-source in
http://software.opensuse.org/download/repositories/Kernel/SUSE_Linux_10.1/x…
do not match? I installed both rpm's and I wanted to build VMware kernel
modules but the sources do not match to the running kernel
Markus
---------------------------------------------------------------------
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 down for some minutes.
We do upgrade the storage system atm.
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
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,
i would like to maintain koverartist (1), a very nice program to create
CD/DVD-covers, on kde:backports.
I build koverartist for PackMan (2) since version 0.3.1 (Apr 2006) and now,
it's time to go to opensuse.org... ;)
Detlef
(1) http://kde-apps.org/content/show.php?content=38195
(2) http://packman-test.links2linux.de/package/koverartist
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hello,
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number:
Release: 42
(If I don't, rpm complains and the build fails.)
The build service edits this number when building the package and sets
it to 1.42 then 2.42 then 3.42 etc.
This makes the release number in the specfile quite useless because it's
only on the second position.
The behaviour can also cause problems when someone imports a package to
the build service.
Say I have released a manually built foobar-1.0-42 package, then move to
the build service and do some small changes without changing the
version number. The build service will compile a foobar-1.0-1.42
package which looks "older" to RPM :-(
Are there any plans to change the behaviour regarding the release
number?
Regards,
Christian Boltz
--
Was hat ein Revolver mit Windows 98 gemeinsam?
Solange sie nicht geladen sind, sind sie harmlos.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
On Mon, Aug 14, 2006 at 06:27:11PM +0530, Jigish Gohil wrote:
> On 8/14/06, Stefan Dirsch <sndirsch(a)suse.de> wrote:
> >On Sun, Aug 13, 2006 at 02:28:38PM +0530, Jigish Gohil wrote:
> >> Here is the error with which it exits.
> >>
> >> checking if gcc -E requires -undef... gcc: no input files
> >> gcc: no input files
> >> configure: error: gcc -E defines unix with or without -undef. I don't
> >> know what to do.
> >> error: Bad exit status from /var/tmp/rpm-tmp.46657 (%build)
> >>
> >> I see the same error in xorg7 project too.
> >>
> >> Any suggestions?
> >
> >Yes, since this does not happen in STABLE for autobuild (STABLE="SUSE
> >internal Factory") this needs to be investigated with a local osc
> >build, but I never did such a local build before. :-(
>
> If that is so, I can only hope it will get fixed with the build
> service's next sync with the factory tree.
Not really.
Short version: put cpp in your BuildRequires
Long version:
- cpp is missing, therefore "gcc -E" is used instead for ${RAWCPP}
- unfortunately "gcc -E < input_file" does *not* work, whereas
"cpp < input_files" does
Conclusion:
- Bug in autotools?
- Wrong package expansion for buildservice Factory?
Best regards,
Stefan
Public Key available
------------------------------------------------------
Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstraße 5
FAX: 0911-740 53 479 D-90409 Nürnberg
http://www.suse.de Germany
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Here is the error with which it exits.
checking if gcc -E requires -undef... gcc: no input files
gcc: no input files
configure: error: gcc -E defines unix with or without -undef. I don't
know what to do.
error: Bad exit status from /var/tmp/rpm-tmp.46657 (%build)
I see the same error in xorg7 project too.
Any suggestions?
Thanks
-J
Hi Stefan and Mathias
The Mesa-configs.diff doesnt work for Factory any more due to the
change in paths and Mesa build fails, would any of you have the patch
which would replace this one?
Hopefully you would update fdo compiz for factory soon enough.
Warm regards
Jigish
Hi!
Yesterday I was experiencing some problems with the build service. I
don't know if it was really slow, or it was a connection problem from my
part.
The fact is that I submitted the spec files many times, and triggered a
rebuild on each upload, which, let's say, created 5 build requests.
Today I woke up and found out that the build service is still trying to
build my packages, after my erroneous 5 triggers.
The question is: I think there is no need to schedule a rebuild if you
already scheduled one before. IMHO, the second rebuild request should
either (a) override the first one or (b) be dropped until the first one
is finished. I vote for (a), since people make mistakes and it's very
probable that the second request is the right one.
I guess that way we would spare some building time on the service.
WDYT?
--
% Mauricio Teixeira (netmask)
% mteixeira{a}webset{d}net <> Maceio/AL/BR
% http://mteixeira.webset.net <> http://pmping.sf.net