[opensuse-buildservice] Re: Would it be possible to build openpkg rpms with OBS
Am Dienstag, 13. April 2010 10:50:52 schrieb Richard Bos:
Hello Adrian,
the developers of the groupware project Kolab (http://kolab.org) are about to start using a different way of building packages. I proposed the OBS, but there is a problem to start using it at the moment (I think). The the Kolab project itself uses openpkg (http://openpkg.org/) to distribute the code. The advantage of openpkg is that the rpms are build on the target system, which could be a solaris, any linux, BSD system, etc. It does this by building a kind of complete distribution the host system, so an openpkg system provides it own glib, libpng, c compiler, php rpm packages which are for kolab most often stored in /kolab.
Yes, this is more a replacement for OBS then an extension ... Installation of an entire system on another one is actually exactly what we want to avoid with OBS and get always native package builds for the base system.
Would it be possible to build openpkg rpms with OBS? I would think that an image should exist that contains the openpkg environment, and that a build target "openpkg_3.0 (i586|x86_64)" would exist. If something like this would be possible, I would think that it is to be used in a private build service. I can not imagine that you would maintain the openpkg image, or would you ;) ?
I personally would not mind to host another base distro. But where would I get binary rpms from ? There are only official src.rpm releases, right ?
A spec file for openpkg does not look the same as for other distributions. An example of such a spec file can be seen at: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webadmin/kolab-webadmin/kolab-webadmin.spec.in?rev=1.21&content-type=text/vnd.viewcvs-markup http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/kolabd.spec.in?rev=1.48&content-type=text/vnd.viewcvs-markup
hm, the @PACKAGE@ and @VERSION@ worries a bit, it would lead to some side effects, but package building should be possible anyway. Or would these fields get replaced before ?
For the email that announces a different package build approach can be seen on this link: (What about starting to use project-builder for native packages? (was: Re: Next Suse Kolab version?)) http://kolab.org/pipermail/kolab-users/2010-April/011289.html
Looking forward to your reply (if you like to reply to the OBS list, rather than private that is fine with me. I'm subscribed to the BS emaillist.
bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi Adrian, At dinsdag 13 april 2010 12:58:51 wrote Adrian Schröter:
Would it be possible to build openpkg rpms with OBS? I would think that an image should exist that contains the openpkg environment, and that a build target "openpkg_3.0 (i586|x86_64)" would exist. If something like this would be possible, I would think that it is to be used in a private build service. I can not imagine that you would maintain the openpkg image, or would you ;) ?
I personally would not mind to host another base distro.
:) That would be great.
But where would I get binary rpms from ? There are only official src.rpm releases, right ?
Rpms can be downloaded from http://files.kolab.org/server/release/kolab-server-2.2.3/ There are rpms for Debian system ;) and src.rpm for other systems. I'm currently building the src.rpms, which is rather trivial: download the src.rpms, and execute a bootstrap script. This will install the bin.rpms in /kolab. The install will also add 3 users to the system. I wonder what would be easier for a build system image: just download the src.rpms and run the bootscript or download the binaries and install them manually. The first is fully automated, but slow (building the rpms takes time), the 2nd method not automated.... I actually don't know how that goes (as it involved bootstrap a new rpmdb in /kolab/lib/openpkg/rpmdb) Would installing the rpms for a Debian host system, make it possible to .... hmmmm ... how to say that ..... build rpm packages. But the way we do now for openSUSE??
A spec file for openpkg does not look the same as for other distributions. An example of such a spec file can be seen at: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webadmin/kolab-we badmin/kolab-webadmin.spec.in?rev=1.21&content-type=text/vnd.viewcvs-m arkup http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/kolabd.sp ec.in?rev=1.48&content-type=text/vnd.viewcvs-markup
hm, the @PACKAGE@ and @VERSION@ worries a bit, it would lead to some side effects, but package building should be possible anyway.
I was more worried about the % values, but I assume now that those can be assigned in e.g. the prjconf file or a similar one, isn't it? I also miss the to see the possibility to e.g. see an openSUSE specfile combined with an openpkg spec file. If this would be feasible that would be really great (like the combined specfiles for openSUSE and Fedora or Mandriva).
Or would these fields get replaced before ?
These variables (@PACKAGE@ and @VERSION@) are now populated by a makefile. I think that these could be entered manually also. -- Richard -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello Adrian, At dinsdag 13 april 2010 23:17:22 wrote Richard Bos:
Hi Adrian,
At dinsdag 13 april 2010 12:58:51 wrote Adrian Schröter:
Would it be possible to build openpkg rpms with OBS? I would think that an image should exist that contains the openpkg environment, and that a build target "openpkg_3.0 (i586|x86_64)" would exist. If something like this would be possible, I would think that it is to be used in a private build service. I can not imagine that you would maintain the openpkg image, or would you ;) ?
I personally would not mind to host another base distro.
Someone already did something with openpkg: https://build.opensuse.org/project/show?project=OpenPKG Maintainer is thl probably Thomas L, the openpkg vice president according this link: https://irc.openpkg.net/ratbot/secretary.community.log
:) That would be great. :
But where would I get binary rpms from ? There are only official src.rpm releases, right ?
Rpms can be downloaded from http://files.kolab.org/server/release/kolab-server-2.2.3/ There are rpms for Debian system ;) and src.rpm for other systems.
I think that packages can be downloaded from http://openpkg.org as well. But one needs to register.
I'm currently building the src.rpms, which is rather trivial: download the src.rpms, and execute a bootstrap script. This will install the bin.rpms in /kolab. The install will also add 3 users to the system. I wonder what would be easier for a build system image: just download the src.rpms and run the bootscript or download the binaries and install them manually. The first is fully automated, but slow (building the rpms takes time), the 2nd method not automated.... I actually don't know how that goes (as it involved bootstrap a new rpmdb in /kolab/lib/openpkg/rpmdb)
The packages are build, in total 129 packages and 246MB. The build started with the following packages: /kolab/RPM/PKG # ls -tr | head -20 | sed 's/.ix86.*//' openpkg-20071227-20071227_kolab2 make-3.81-20080101 binutils-2.18-20080101 gcc-4.2.2-20080101 perl-5.10.0-20080103 openpkg-tools-1.4.6-20071231 openssl-0.9.8g-20080101 db-4.5.20.2-20070628_kolab1 fsl-1.7.0-20080101 readline-5.2.12-20080101 openldap-2.3.43-20081212 procmail-3.22-20090727 ncurses-5.6.20080112-20080113 texinfo-4.11-20080101 pcre-7.5-20080110 grep-2.5.3-20080101 m4-1.4.9-20080101 bison-2.3-20080101 groff-1.19.2-20080101 sasl-2.1.22-20080101 perl-openpkg-5.10.0-20080109 perl-module-5.10.0-20080101 perl-util-5.10.0-20080116 perl-stats-5.10.0-20080101 perl-ds-5.10.0-20080104 perl-time-5.10.0-20080101 postfix-2.4.6-20080101_kolab mm-1.4.2-20080101 gawk-3.1.6-20080101 sqlite-3.6.4-20081212 mhash-0.9.9-20080101 libiconv-1.12-20080101 imap-2006k-20080101 autoconf-2.61-20080101 automake-1.10-20080101 gettext-0.17-20080101 zlib-1.2.3-20080101 libxml-2.6.31-20080111 flex-2.5.34-20080101 libmcrypt-2.5.8-20080101 sed-4.1.5-20080101 expat-2.0.1-20080101 apr-1.2.12-20080101 apache-2.2.10-20081111 png-1.2.24-20080101 libxslt-1.1.22-20080101 freetype-2.3.5-20080101 jpeg-6b-20080101 gd-2.0.35-20080101 apache-php-5.2.8-20081209_kolab2 config-20060923-20080101 imapd-2.3.13-20081020_kolab4 php-5.2.8-20081209_kolab2 perl-term-5.10.0-20080116 perl-sys-5.10.0-20080101 diffutils-2.8.7-20080101 bzip2-1.0.5-20080318 gzip-1.3.12-20080101 perl-mail-5.10.0-20080117 perl-ssl-5.10.0-20080101 perl-conv-5.10.0-20080101 perl-crypto-5.10.0-20080101 perl-locale-5.10.0-20080112 perl-text-5.10.0-20080101 lzo-2.02-20080101 perl-comp-5.10.0-20080110 perl-parse-5.10.0-20080117 perl-xml-5.10.0-20080101 perl-net-5.10.0-20080101 perl-www-5.10.0-20080103 perl-ldap-5.10.0-20081028_kolab1 perl-db-5.10.0-20080118 curl-7.17.1-20080101 bc-1.06-20080101 pkgconfig-0.23-20080117 gmp-4.2.2-20080101_kolab clamav-0.95.3-20091030 I think that these 78 rpms should be available via the build service (if that would be possible). The other rpms (~50) are to build and maintained, via the build service. The rpms are installed in /kolab and this directory has the following layout: # ls -1 /kolab .bash_login .bashrc bin cgi etc .history include info lib libexec local man pub README RPM sbin share var Would it make sense to pack the before mentioned rpms and have them somehow transferred to you? -- Richard -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (2)
-
Adrian Schröter -
Richard Bos