Is it possible that some RPM-macros are missing in Fedora_Core_5?
Up to now I came across
_jvmdir
_jvmjardir
... I think they should be there since they are used throughout the jpackage
project which [I think] uses a lot Fedora for a build system -- I could be
wrong though.
Thanks,
--
Daniel Bornkessel Tel: +49 911 740 53 161
Novell :: SUSE R&D :: Internal Tools / Java Packaging
______________________________________________________________________
:wq
Hi.
Trying to build some packages, I got an expansion error on Mandriva2006:
nothing provides gcc-java
The package there is called 'gcc-java', I checked. Can we add it?
Thanks,
--
Daniel Bornkessel Tel: +49 911 740 53 161
Novell :: SUSE R&D :: Internal Tools / Java Packaging
______________________________________________________________________
:wq
On Fedora Core (4 and 5), I'm getting expansion errors which shouldn't occur:
nothing provides /usr/bin/symlinks (this should be provided by the symlinks package, perhaps the system does not currently support file based requires?)
[x86_64] nothing provides libpng-devel (there should be a x86_64 RPM for libpng-devel)
Thanks,
Bernard
Hello there:
I've just recently joined the list and have started using the build service - it is pretty neat!
I was wondering if it will be possible to include Fedora Extras for FC4/5, they contain a bunch of extra RPMs not included in the standard distributions.
Also, has any group built rrdtool-devel for FC? I need that for building the ganglia package.
Thanks!
Bernard
Hi,
the build server builds my package (sax2) for SuSE dists just fine
but to build for RedHat (FC5) I'm using a different spec file. The
main reason for this are the package name differences within the
BuildRequires statement.
For example:
SuSE: ghostscript-fonts-std
FC5: xorg-x11-server-sdk
The package structures on RedHat are very different from the SuSE
ones. So it's in many cases not only the name which is different.
How do I handle this within one spec file in the opensuse build
service ?
Thanks
Regards
Marcus
--
Public Key available
-------------------------------------------------------
Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 Nürnberg
http://www.suse.de Germany
-------------------------------------------------------
Hi,
we have updated the Factory distro in the BS yesterday, we have also renamed
some project names (people did build against "openSUSE" because they thought
it was a distribution, but it is only the tool set for the build service).
This triggered some hundred build jobs and we seem to have a technical problem
in the backends atm, which slow downs the build.
So the turn around times of a build job are quite long atm, we will of course
look in the backend problem and we will enable some more build hosts to
become faster again.
I hope we will be fine again tomorrow.
(current state, 350 build jobs are in "waiting" state)
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian(a)suse.de
Hi,
is it possible to build SuSE kernels in buildservice?
-----------------------------------------------------------------
I have the following modifications for kernel-bigsmp.spec:
23c23
< Release: 28
---
> Release: 1.1
-----------------------------------------------------------------
----- building kernel-bigsmp.spec (user abuild)
-----------------------------------------------------------------
-----------------------------------------------------------------
chmod: cannot access `/usr/src/packages/SOURCES/make-symsets': No such file or
directory
error: Architecture is not included: x86_64
full log may be accessed at home:openvz/kernel/
--
Thanks,
Dmitry.
Hi,
I want to share with you a primitive script which allows copying files
from and to the buildservice server.
It is probably similar (and likely inferiour) to the
opensuse-commandline tool from Christopher Hofmann
http://build.opensuse.org/package/show?package=opensuse-commandline&project…
and the primary reason I didn't build on it is that it wasn't accessible
at the time I wanted to try it out ;) However, I also like the idea of
having the functionality in a python library.
It can be found here, and if anyone wants to extend it please contact me
to get write access:
http://svn.poeml.de/svn/oschttp://svn.poeml.de/viewcvs/osc/
To explain what's currently implemented, here are usage examples:
# list contents
opensuse-commander.py ls
opensuse-commander.py ls Apache
opensuse-commander.py ls Apache subversion
# show xml meta
opensuse-commander.py meta Apache
opensuse-commander.py meta Apache subversion
opensuse-commander.py id username
# check out sources
mkdir subversion
cd subversion
opensuse-commander.py co Apache subversion [file]
vi *.spec
opensuse-commander.py diff Apache subversion [file]
opensuse-commander.py ci Apache subversion file1 [file2...]
(I hope I got that right, it is partly from memory)
Regards,
Peter
--
SUSE LINUX Products GmbH Thought is limitation.
Research & Development Free your mind.
Hi
I am part of a team which is working on the development of a Linux
distribution (such as SUSE), as part of the European EDOS project
(http://www.edos-project.org).
We have developed some tools to manage package dependencies which you may find
useful. For example, anla (http://brion.inria.fr/anla/), a package
exploration utility to spot and to trace dependency problems over time
(currently working with a Debian package pool).
anla depends on other tools such as ceve, a parser written in ocaml for deb,
rpm and other files, and a SAT solver.
One of the goals of the EDOS project is to maintain a set of packages on the
server side (avoiding dependency issues), but we are also interested in
"thinning" a distribution, that is producing a Linux "CD" (for example)
containing a requested set of packages, and the minimal set of packages which
are necessary to complete the dependency requirements, nothing more.
Another interest of ours is the rebuilding of a distribution from scratch, in
such a way that a user can reproduce the binaries shipped to him by using
only the sources coming with them.
The EDOS project also deals with the diffusion of the package (a P2P system is
under development) and the testing domain (a portal is also being developed).
We would like to know about the issues you may face in your build management
project and we would be glad to bring our expertise. We also want to ensure
that our tools will work for the SUSE user.
All the best,
Marc Lijour
