OpenPKG Framework COMMUNITY and VALUE licenses available
Dear community members and commercial customers, since months we have been providing OpenPKG 4 under the PROMO license until the VALUE license was available for ordering and the COMMUNITY license proved to be working as expected. The PROMO license finally expired on April 1st and you now finally have the option of always running a bleeding edge OpenPKG fully free of charge via the COMMUNITY license (and this way implicitly act as testers in our community) and the option of lazily running a productive and hence fixed OpenPKG instance via the VALUE license for a small fee (and this way at least support the OpenPKG development financially). Details on the various licenses -- including a comparison of the licenses based on their particular license assertions -- you now can find under the URL: http://www.openpkg.com/go/framework-licensing In case you want to run the COMMUNITY license you always can download the latest version on this page (or get it indirectly via the latest OpenPKG Framework on upgrade). In case you want to run the VALUE license you can directly online order your copy there, too. With the new OpenPKG 4 model I think we finally found a reasonable compromise between a free of charge community offering and a still inexpensive offering for the commercial customers -- both at the same time. Thanks for supporting OpenPKG. Yours, Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: curl.spec patch
On Sun, Feb 07, 2010, PLI wrote: PS: How can we upload diff , previously located in ftp://ftp.openpkg.org/contrib/00UPLOAD/ ? We no longer provide an upload area as it complicates to correlate contributors to their patches this way. Just post your patches to the mailing list. That's just fine. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: curl.spec patch
On Sun, Feb 07, 2010, PLI wrote:
You will find here a small patch for the curl.spec file.
1) To build curl with the the rigth ssl depencies (ex zlib), i use
pkg-config --libs openssl to populate LIBS.
This should be no longer needed with the latest openssl package as
I've switched it to using a local zlib copy as a DSO and hence the extra
dependencies should be gone.
2) i use the full path for %{l_prefix}/bin/pkg-config
I see no reason. %{l_prefix}/bin is in the $PATH during
build-time. Why do you need to pass an absolute path?
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: postfix - procmail compilation and failure
On Mon, Jul 27, 2009, Sasha Kacanski wrote: Hi, I am trying to build kolab 2.2.2 on fedora release 11. /kolab/bin/cc -c -fPIC formail.c In file included from formail.c:25: formisc.h:20: error: conflicting types for 'getline' /usr/include/stdio.h:655: error: previous declaration of 'getline' was here make[1]: *** [formail.o] Error 1 make: *** [bins] Error 2 error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.59346 (%build) While compiling procmail as dependency for postfix, I am getting above error. How can I remove procmail from the openpkg build or how can I add new version of the procmail package to the 2.2.2 kolab sources? I applied a workaround for you in the latest procmail package: http://cvs.openpkg.org/chngview?cn=45814 Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: tomcat.diff
On Wed, May 06, 2009, PLI wrote:
This latest patch relocate log and temp directory to %{l_prefix}/var/tomcat
Why symlinks instead of the previous reconfiguration?
Didn't patching the catalina.sh script no longer work?
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Possible bug in snmp 5.4.2.1 / snmptrapd double free()
On Fri, Feb 06, 2009, Christian Lete wrote: [...] I'm having problems to run snmptrapd, I keep getting the following error: [...] Warning: no access control information configured. This receiver will *NOT* accept any incoming notifications. *** glibc detected *** snmptrapd: free(): invalid pointer: 0x00533308 *** [...] Sould be now already fixed with the latest snmp package. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: imagemagick.diff
On Mon, Feb 23, 2009, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file imagemagick.diff accepted -- moved to contrib area. No action is required on your part. Taken over. Thanks. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: readline.diff
On Mon, Feb 23, 2009, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file readline.diff accepted -- moved to contrib area. No action is required on your part. Taken over. Thanks. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: file.diff
On Mon, Feb 23, 2009, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file file.diff accepted -- moved to contrib area. No action is required on your part. Applied to CVS. Thanks. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: apache-define.diff
On Sun, Dec 28, 2008, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file apache-define.diff accepted -- moved to contrib area. No action is required on your part. The .diff file is empty. Just upload apache-define.spec as a whole... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: perl.diff
On Thu, Dec 25, 2008, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file perl.diff accepted -- moved to contrib area. No action is required on your part. Taken over. Thanks, Christoph. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: openssh.diff
On Mon, Dec 22, 2008, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file openssh.diff accepted -- moved to contrib area. No action is required on your part. I've committed a slight variation of this patch now. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: openssh.diff
On Tue, Dec 23, 2008, Christoph Schug wrote: Ralf S. Engelschall wrote: On Mon, Dec 22, 2008, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file openssh.diff accepted -- moved to contrib area. No action is required on your part. I've committed a slight variation of this patch now. Hmm, but I think this way it does not make too much sense as you included a more or less complete list of available ciphers. As far as I know the server picks one cipher based on the client's perference. The client can choose from the list offered by the server and might potentially prefer a cipher which might be insecure. IIRC the order within the list of ciphers on the server is not relevant. So the idea was to remove any potentially insecure ciphers. Well, as the advisory states, the whole impact of the vulnerability is still somewhat unclear and the suggested reduction of the cipher suite is OK to be safe in advance on _this_ vulnerability, but OTOH it might have other drawbacks. So, I don't want to rush as long as the upstream vendors make a more clear and definite statement. Instead, I think the reduction to Protocol 2 only by default on the server and the _addition_ of the CTR-mode ciphers is a reasonable thing we should do and hence I've applied this. On the client side I want to be not too restrictive by default at this time and on the server-side we need more consideration before we should reduce the accepted cipher suites such massively. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: apache-kerberos.diff
On Thu, Dec 18, 2008, PLI wrote: I see that in the new official release of mod_auth_kerb (5.4), this patch is not necessary any more. The Krb5AuthToLocal directive is now replaced by KrbLocalUserMapping, and fully integrated. see ChangeLog -- 5.4 -- *implemented KrbLocalUserMapping i.e. to strip @REALM from username for further use I've uploaded a new apache-kerberos.diff, which upgrade apache-kerberos.spec and remove the patch. Ok, package upgrade done. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: apache-kerberos.diff
On Wed, Dec 17, 2008, PLI wrote: [...] This patch remove the @REALM from the end of a user name when the user is authenticated, in apache-kerberos. The following directive is added Krb5AuthToLocal (default to off) please see http://www.stacken.kth.se/lists/heimdal-discuss/2008-05/msg8.html http://patch-tracking.debian.net/patch/series/view/libapache-mod-auth-kerb/5.3-5/auth_to_local.patch Patch taken over. Thanks. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: subversion.diff
On Wed, Dec 17, 2008, PLI wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file subversion.diff accepted -- moved to contrib area. No action is required on your part. In the previous patch, i forgot to complete mod_dav_svn_DEPS variable (libfs_base-1.la libsvn_fs_fs-1.la libsvn_fs_util-1.la). subversion::with_apache now build correctly Patch taken over. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: subversion.diff
On Sat, Dec 13, 2008, PLI wrote: When compiling subversion::with_apache, the module mod_dav_svn won't be loaded in apache. I have added the following lib libsvn_fs_util when building mod_dav_svn. Zlib (-lz) is needed in LIBS to make the build successfull Ok, taken over. Thanks. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: bind.diff
On Thu, Nov 27, 2008, PLI wrote: One another bug found in bind-9.5p2 and dlz. When trying to make a zone transfert request, bind + dlz crashes. I found this patch on comp.protocols.dns.bind: Assertion debug information Ok, taken over. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: bind.diff
On Wed, Nov 26, 2008, PLI wrote: OpenPKG Project Robot a écrit : The following OpenPKG Contribution Area operation occurred. uploaded DIFF file bind.diff accepted -- moved to contrib area. No action is required on your part. bind with dlz ldap, doesn't work without this patch the '%' symbol used in the named.conf to describe LDAP url, must be replaces by another symbol ex: '$'. '%' is a reserved symbol used to escape characters in URL's. Description of the problem in the following articles Re: bind9-9.4.2 + DLZ + slapd 2.4.7 Re: Bind-9.4.2 DLZ LDAP on http://news.gmane.org/gmane.network.dns.bind9.dlz Now taken over into the latest version of bind package. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: dhcpd.diff
On Sat, Nov 15, 2008, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file dhcpd.diff accepted -- moved to contrib area. No action is required on your part. Hmmm... this patch includes a rather huge LDAP patch. If we really include this into the OpenPKG package it means we have to maintain this patch (forward porting it to the latest ISC DHCPD versions). H... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: perl-xml.diff
On Sun, Nov 09, 2008, PLI wrote: Net::LDAP::DSML in perl-ldap need the following 2 xml modules in perl-xml to work correctly XML-SAX-Writer and XML-Filter-BufferText Ok, patch applied. Thanks for your contribution. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: actual Python package
On Thu, Nov 06, 2008, Torsten Homeyer wrote: Ralf S. Engelschall wrote: AFAIK the system's ncurses-dev _always_ was a hard requirement for OpenPKG to get the necessary termcap/termlib stuff under _Linux_. So what? My understanding is, that OpenPKG is as self contained as possible. The understanding is correct, Torsten. And I see no problem for the python package to require OpenPKG-ncurses for readline functionality. For the particular python package the requirement might be ok. I spoke about the _general_ requirement for the system ncurses-dev package to be installed under Linux. I'm really sure, that I don't want to install the OS vendor package for this. Whats wrong on this view? Nothing is wrong here. Fact is just that OpenPKG requires ncurses-dev anyway under Linux, so I thought it should not hurt you for python, too. I see that the python package has a with_curses option, too. Would using this already solve your problem or do we first have to patch Python to correctly find OpenPKG's ncurses and solve your problem? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: actual Python package
On Tue, Nov 04, 2008, Torsten Homeyer wrote: since my development environment is broken and I don't have time and mood to fix this again, somebody else could eventually do the required changes: The actual python package doesn't link if build with with_readline. To fix this ncurses should be required if with_readline=yes and -ltermcap should be replaced with -lncurses. AFAIK the system's ncurses-dev _always_ was a hard requirement for OpenPKG to get the necessary termcap/termlib stuff under _Linux_. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: xerces-c.diff
On Fri, Oct 17, 2008, PLI wrote: I have upgrade xerces-c.spec to 2.8.0. pthreads, and cpp patch have been adjusted. The folloween option is added to runConfigure: -s, to enable static lib -b, to enable 32/64 bits Applied. But under with_pth=yes the package still fails to build as the xerces-c.patch.pth still needs adjustment... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Problem building rrdtool-1.3.4-20081005
On Thu, Oct 16, 2008, Artur Frysiak wrote: /bin/bash ../libtool --tag=CC --mode=link /openpkg/bin/cc -O2 -pipe -D_GNU_SOURCE -fno-strict-aliasing -Wall -std=c99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wold-style-definition -W -fPIC -DPIC -L/openpkg/lib -L/openpkg/lib -L/openpkg/lib -R/openpkg/lib -o rrdtool rrd_tool.o librrd.la /openpkg/bin/cc -O2 -pipe -D_GNU_SOURCE -fno-strict-aliasing -Wall -std=c99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wold-style-definition -W -fPIC -DPIC -o rrdtool rrd_tool.o -L/openpkg/lib ./.libs/librrd.a -lrt -lpangocairo /openpkg/lib/libcairo.a -lpangoft2 /openpkg/lib/libpixman-1.a /openpkg/lib/libpng12.a -lpango /openpkg/lib/libfontconfig.a /openpkg/lib/libexpat.a -lgobject2 -lgmodule2 -lglib2 /openpkg/lib/libintl.a -lc /openpkg/lib/libpcre.a /openpkg/lib/libfreetype.a /openpkg/lib/libxml2.a -lz -liconv -lm -lsocket -lnsl -Wl,--rpath -Wl,/openpkg/lib /openpkg/lib/libpangocairo.a(libpangocairo_1_0_la-pangocairo-render.o): In function INT_cairo_surface_cairo_has_show_text_glyphs' collect2: ld returned 1 exit status Reference to INT_cairo_surface_cairo_has_show_text_glyphs is introduced by pango.patch, but this function isn't present in cairo 1.8.0. I think better solution is upgrade pango to 1.22.0 and drop pango.patch. Ok, OpenPKG pango package is now at 1.22.0. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: sqlite-CURRENT broken due to tcl
On Tue, Sep 30, 2008, Doug Henry wrote: sqlite-CURRENT does not build on linux-amd64 due to the tcl wrapper failing to build (see error below). It doesn't look like tcl is a build requirement for the package so I think --disable-tcl should be provided to configure. libtool: compile: /tools/lin64/bin/cc -I. -I/tools/lin64/include -fPIC -pipe -Os -mtune=nocona -DSQLITE_OS_UNIX=1 -I. -I./src -D_HAVE_SQLITE_CONFIG_H -DNDEBUG -DSQLITE_THREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DUSE_TCL_STUBS=1 -c ./src/tclsqlite.c -o tclsqlite.o ./src/tclsqlite.c:283: error: 'TCL_CHANNEL_VERSION_2' undeclared here (not in a function) Ok, --disable-tcl added. Seems like this option was a recent addition, as in the past I already would have liked this option for SQLite... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: shtool rotate patch to pass file values to epilog/prolog
On Sun, Sep 21, 2008, Bill Campbell wrote:
tatus: RO
Content-Length: 2216
Lines: 52
On Sun, Sep 21, 2008, Ralf S. Engelschall wrote:
On Fri, Sep 19, 2008, Bill Campbell wrote:
The attached patch to the sh.rotate script sets an environment
variable ROTATE_LOGFILE with the name of the current file being
processed before invoking the epilog or prolog programs. This
permits the epilog/prolog script to do things such as calling
webalizer to process the file being rotated.
The problem is that defining multiple log files in the rc.conf
file with lines like the follow cause the epilog/prolog programs
to be execute multiple times without knowledge of which file is
being processed.
apache_log_files=/opkg/var/apache/log/*access*log
I first tried having the sh.rotate script add an argument to the
eval of the epilog/prolog command, but this does not work when
the command is compound as in the rc.apache daily processing:
-E ${apache_log_epilog} rc apache reload
Creating a new environment variable avoids this problem and
cannot break any existing epilog/prolog programs as they will not
be aware of the variable.
Ok, taken over into my GNU shtool source tree for inclusion into
GNU shtool 2.0.9 -- with just a small adjustment: ROTATE_LOGFILE
- SHTOOL_ROTATE_LOGFILE to avoid any conflicts. Thanks for your
contribution, Bill!
I thought you might want to use a more descriptive environment
variable, and that get it into the main shtool.
Presumably this will make it into the shtool rotate man page?
I've now also added two sentences into the manpage about the variables.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: webalizer -- add with-bzip2 option
On Thu, Sep 18, 2008, Bill Campbell wrote:
May I suggest adding ``--with-bzip2'' to the default options to
configure in the webalizer package as it is required to process
the default compressed apache log files.
There is no --with-bzip2 option, but I added...
--enable-bz2 \
--with-bz2lib=%{l_prefix}/lib \
--with-bz2=%{l_prefix}/include \
...now. I guess this is what you wanted, Bill.
Yours,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: shtool rotate patch to pass file values to epilog/prolog
On Fri, Sep 19, 2008, Bill Campbell wrote:
The attached patch to the sh.rotate script sets an environment
variable ROTATE_LOGFILE with the name of the current file being
processed before invoking the epilog or prolog programs. This
permits the epilog/prolog script to do things such as calling
webalizer to process the file being rotated.
The problem is that defining multiple log files in the rc.conf
file with lines like the follow cause the epilog/prolog programs
to be execute multiple times without knowledge of which file is
being processed.
apache_log_files=/opkg/var/apache/log/*access*log
I first tried having the sh.rotate script add an argument to the
eval of the epilog/prolog command, but this does not work when
the command is compound as in the rc.apache daily processing:
-E ${apache_log_epilog} rc apache reload
Creating a new environment variable avoids this problem and
cannot break any existing epilog/prolog programs as they will not
be aware of the variable.
Ok, taken over into my GNU shtool source tree for inclusion into
GNU shtool 2.0.9 -- with just a small adjustment: ROTATE_LOGFILE
- SHTOOL_ROTATE_LOGFILE to avoid any conflicts. Thanks for your
contribution, Bill!
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: aegis package
On Fri, Aug 08, 2008, Walter Franzini wrote: looking at your package for aegis I've noted the following issues: * The aelock program is not installed suid. SetUID to _what_ user? Also root? * The UUID library detection in configure has been improved so it /should/ be possible to remove the subst statement in the %build section. Report any problem to Aegis developers, please. * It /should/ be possible to remove the patch applyied by the spec file, since 4.24 has improved portability. If you still need to patch the source let the developers know why, so the problem can be fixed once for all. Ok, I've removed the stuff for now. Let's see when it breaks the next time... * The testsuite is not executed. Aegis has an extensive test suite that helps ensure it not only compiles but also works as expected. In order to run the testsuite 'make sure' has to be invoked. Can you take the time to report any failure to [EMAIL PROTECTED] or to me if you prefer? On modern hardware the test suite should complete in 30min. Well, OpenPKG packages are intended to be run by admins in batch/no-attention mode, not developers in interactive/feedback mode. So, executing a test suite, especially one which runs many minutes, IMHO is not really what should be done during building an OpenPKG package. That Aegis works correctly an Aegis-skilled developer has to ensure beforehand, not the average admin just leveraging from its OpenPKG packaging. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: File conflict apr vs. subversion
On Fri, Aug 08, 2008, Christoph Schug wrote: I guess following fix is required to install apr and subversion without any conflicting files: [...] Hi Christoph! Yes, good catch. This might be also the reason why uprading apache failed for me yesterday but after a simple reinstall of apr it succeeeded again just fine. The problem seem to be that subversion was installed after apr and then apache tried to build against inst special APR copy and hence failed. Now committed and this way fixed. Thanks for your contribution. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: fix building vim with python support
On Sat, Aug 02, 2008, Artur Frysiak wrote: I trying to enable python support in vim. I build vim with --define 'with_python yes'. Package build fine but vim report no python support. After small investigation I made patch to vim.spec. With this patch python support in vim is correctly build. Taken over except that I do not change configure.in in order to avoid having to require Autoconf. Thanks for your support. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: BIND -- Problems with Linux capabilties
On Thu, Jul 24, 2008, Bill Campbell wrote: I ran into a problem today attempting to build the current version of bind, bind-9.5.0p1-20080709.src.rpm, on a SuSE Linux Enterprise 9 PL3 system with the following error: /csrel25/bin/cc -I/csrel25/RPM/TMP/bind-9.5.0-P1 -I./include -I./../include -I/csrel25/RPM/TMP/bind-9.5.0-P1/lib/dns/include -I../../../lib/dns/include -I/csrel25/RPM/TMP/bind-9.5.0-P1/lib/isc/include -I../../../lib/isc -I../../../lib/isc/include -I../../../lib/isc/unix/include -I../../../lib/isc/nothreads/include -I../../../lib/isc/x86_32/include -fPIC -I/csrel25/include -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c os.c -o os.o os.c: In function 'linux_initialprivs': os.c:266: error: invalid operands to binary | make[3]: *** [os.lo] Error 1 make[2]: *** [subdirs] Error 1 make[1]: *** [subdirs] Error 1 make: *** [subdirs] Error 1 error: Bad exit status from This is in the line that is patched in bind.patch, and results when attempting to OR something into a structure, a practice that has been deprecated for decades (no wonder it' Buggy Internet Name Daemon :-). Ok, I see. But before we completely disable the Capability stuff, can you once again try to build the latest bind package? I tried to adjust the patch to fit the BIND 9.5.0 world order and hopefully it now builds for you even without --disable-linux-caps. Can you check? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: libxslt compilation problem on Solaris 9
On Wed, Jul 09, 2008, Artur Frysiak wrote: When I try to compile libxslt on Solaris 9 on Sparc machine I get this error message: /bin/bash ../libtool --tag=CC --mode=compile /openpkg/bin/cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../libxslt -I/openpkg/include/libxml2 -I/openpkg/include -I/openpkg/include -O2 -pipe -I/openpkg/include -Wall -MT extra.lo -MD -MP -MF .deps/extra.Tpo -c -o extra.lo extra.c extra.c: In function 'xsltFunctionLocalTime': extra.c:252: error: 'struct tm' has no member named 'tm_gmtoff' mv -f .deps/variables.Tpo .deps/variables.Plo make[2]: *** [extra.lo] Error 1 xsltFucntionLocalTime implements (unportable as noted in source) localTime XSLT extension, so I decided to not build it on Solaris. Modified libxslt.patch attached. Thanks. Applied. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Oracle support in python-db.spec
On Wed, Jul 09, 2008, Artur Frysiak wrote: python-db.spec (2.5-20080612) build two Oracle modules: - cx_Oracle - DCOracle2 cx_Oracle build fine, but DCOracle2 doesn't build. On DCOracle2 home page you can read: DCOracle2 is currently unmaintained, and no support is available. I think is time to drop DCOracle2 from python-db.spec. Yes, agreed. Additionaly last stable version of mysql-python is 1.2.2 not 1.2.2c1 (c1 means release candidate 1) Both fixed in attached patch. Applied. Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: file 4.25 20080704 compilation problem
On Tue, Jul 08, 2008, Artur Frysiak wrote: I try to build file-4.25-20080704 on Solaris 9 at Sparc machine. [...] I solved this using attached file.patch (replacing file.patch from original package). Thanks for your contribution. Patch now applied. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: freeradius.diff
On Tue, Jun 24, 2008, PLI wrote: I uploaded this patch to fix the following error during build. modules.c:(.text+0x12ed): undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' solution found on http://bugs.gentoo.org/show_bug.cgi?id=225725 On what platform were you faced with this problem. For me the freeradius package builds just fine under both FreeBSD and Debian GNU/Linux. Also, if we are using --with-system-libtool we also would have to add a dependency to our libtool package, of course. Hmmm... I'm not fully convinced whether this change is the right way to go. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/rsyslog/ rsyslog.patch rsyslog.spec
On Thu, Jun 12, 2008, Christoph Schug wrote: [...] upgrading package: rsyslog 3.19.6 - 3.19.7 [...] Index: tools/syslogd.c tools/syslogd.c.orig 2008-04-15 14:24:00 +0200 -+++ tools/syslogd.c 2008-04-15 21:07:54 +0200 -@@ -207,36 +207,20 @@ +--- tools/syslogd.c.orig 2008-06-10 08:16:53 +0200 tools/syslogd.c 2008-06-11 22:19:10 +0200 +@@ -202,36 +202,20 @@ #ifndef _PATH_LOGCONF #define _PATH_LOGCONF /etc/rsyslog.conf -+#define _PATH_LOGCONF @l_prefix@/etc/rsyslog/rsyslog.conf ++#define _PATH_LOGCONF /openpkg-dev/etc/rsyslog/rsyslog.conf #endif #ifndef _PATH_MODDIR -#define _PATH_MODDIR/lib/rsyslog/ -+#define _PATH_MODDIR@l_prefix@/lib/rsyslog/ ++#define _PATH_MODDIR/openpkg-dev/lib/rsyslog/ #endif Is there any specific reason to hard-code '/openpkg-dev/' here? No, this was just an OSI layer 8 problem ;-) Now fixed. Thanks for catching this. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/star/ star.spec
On Fri, May 23, 2008, Christoph Schug wrote: upgrading package: star 1.5 - 1.5a89 [...] Really a downgrade? What's broken with the release version 1.5? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Problems with openpkg rc --eval all env
On Sun, Mar 09, 2008, Steffen Weinreich wrote: ~eval `openpkg rc --eval all env` to setup the paths for a openpkg instance in the system login script. This works fine except that the directory which is created under /tmp could not be deleteted since the owner of the dir is the management user and therefore the calling user is not able to delete the directory. Any idea how to fix this behaviour? You could use: $ eval `openpkg --keep-privileges rc --eval all env` Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: drac and Solaris 10
On Thu, Dec 27, 2007, Birger Krägelin wrote: To successfully compile and install drac-1.12-20071027.src.rpm on Solaris 10 (tested on Sparc) you need additional libraries: The daemon now needs realtime extensions and the test program needs explicit linking to the socket library. I set this in drac.spec ldflags=$ldflags -lnsl -lrt ldflags_tst=$ldflags_tst -lnsl -lsocket Ok, fixes now conditionally applied for Solaris 10 in latest drac package. Thanks for your feedback. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Kolab2 Beta3 install-kolab.sh -H -F does not work
On Tue, Dec 18, 2007, ComCept Soliva wrote: I saw that Beta3 was released and would like to give a try but first commands fails: # sh install-kolab.sh -H -F 21 | tee kolab-install.log install-kolab.sh: syntax error at line 137: `R_KID=$' unexpected I'm not very familar with shell scripts.but it seems that following positions is not fitting the requirements: 136 137 R_KID=$(($KID + 1)) 138 N_KID=$(($R_KID + 1)) 139 Althought this is the _OpenPKG_ forum and not the _KOLAB_ forum. your problem is that the KOLAB scripts seem to use Bash features while your sh(1) is just a stock Bourne-Shell. Run the Script with bash(1) instead. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/imapd/ imapd.spec
On Thu, Dec 06, 2007, Gunnar Wrobel wrote: [...] Cyrus IMAPd did link to the bdb instance outside of the OpenPKG environment in the release we are currently building. We observed the same for the sasl: root# ldd /kolabrelease/sbin/saslauthd libcrypt.so.1 = /lib/libcrypt.so.1 (0xb7fb) libresolv.so.2 = /lib/libresolv.so.2 (0xb7f9e000) libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7ead000) libnsl.so.1 = /lib/libnsl.so.1 (0xb7e97000) libc.so.6 = /lib/libc.so.6 (0xb7d78000) /lib/ld-linux.so.2 (0xb7fe6000) I tried copying the stanza from imapd.spec to sasl.spec but that didn't work. For the Kolab release this problem does not matter but we thought we should mention it. I've tried to fix it now. Just retry with latest sasl package... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/fetchmail/ rc.fetchmail
On Wed, Dec 05, 2007, Christoph Schug wrote: On Wed, Dec 05, 2007, Torsten Homeyer wrote: Index: openpkg-src/fetchmail/rc.fetchmail $ cvs diff -u -r1.6 -r1.7 rc.fetchmail --- openpkg-src/fetchmail/rc.fetchmail5 Dec 2007 09:29:54 - 1.6 +++ openpkg-src/fetchmail/rc.fetchmail5 Dec 2007 13:16:21 - 1.7 @@ -33,7 +33,7 @@ fi if [ -s $fetchmail_users ]; then sed -e '/^[[:space:]]*#.*/d' \ --e '/^$/d' $fetchmail_users |\ +-e '/^[[:space:]]*$/d' $fetchmail_users |\ while read user comment; do fetchmailrc=`eval echo ~$user`/.fetchmailrc if [ -s $fetchmailrc ]; then @@ . Do you think this is portable enough? I'm not sure whether all implementations of sed correctly implement POSIX character classes. fetchmail at least already requires sed (GNU sed), so maybe this is already sufficient for this (I've not checked myself)? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: delegate.diff
On Mon, Nov 26, 2007, PLI wrote: I've uploaded this patch to remove the strip operation after the make install. The Make install process of delegated include a self signed integrity mecanism that is calculated during make install. If we strip the binary after the make install, delegated refuse to start. Fix now applied. Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/apache/ apache.spec
On Wed, Nov 21, 2007, Gunnar Wrobel wrote: [...] What is the best method to build the package on the OpenPKG server with the options? Something like opd bu -D with_mod_authn_alias yes? opd bu -f -D with_mod_authn_alias[=yes] Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/apache/ apache.spec
On Wed, Nov 21, 2007, Christoph Schug wrote: On Wed, Nov 21, 2007, Ralf S. Engelschall wrote: On Wed, Nov 21, 2007, Gunnar Wrobel wrote: [...] What is the best method to build the package on the OpenPKG server with the options? Something like opd bu -D with_mod_authn_alias yes? opd bu -f -D with_mod_authn_alias[=yes] BTW, Ralf, can you take care of the version tracker which is broken since several days now. I already sent you a mail in private but maybe it got stuck somewhere in your mail filter (which is known to happen from time to time ;-) Yes, seems to got filtered somewhere. Package aria2 broke the tracking. Now fixed. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Building cyrus imapd fails
On Tue, Nov 06, 2007, Gunnar Wrobel wrote:
Currently I fail to build the imapd package on rm0. It fails with
checking for db.h... yes
configure: error: Berkeley DB 3.x or later was not found. You may need to
supply the --with-bdb-libdir or --with-bdb-incdir configure options.
error: Bad exit status from /ltmp/kk/openpkg/rpm-tmp.18065 (%build)
I tried installing db45 but that didn't seem to help. What could I
do to fix that?
The problem is that the installed db package was built by me with
with_pthreads=yes a few days ago for testing purposes together with
OpenLDAP. I just forgot to reinstall a regular db package. Now
fixed.
The thing I wanted to change on the imapd package was actually
trivial:
diff -u -d -u -d -r1.14 fsl.imapd
--- fsl.imapd 17 Dec 2006 12:35:57 -1.14
+++ fsl.imapd 6 Nov 2007 15:05:45 -
@@ -38,7 +38,7 @@
}
};
-ident (lmtpd)/.+ q{
+ident (lmtpd|lmtp)/.+ q{
prefix(
prefix=%b %d %H:%M:%S %N %L $1[%P]:
)
Currently the lmtpd does not write a log file since the log lines
start with lmtp rather than lmtpd
You should be now able to again build imapd and especially commit this
change...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Building cyrus imapd fails
On Tue, Nov 06, 2007, Christoph Schug wrote:
On Tue, Nov 06, 2007, Ralf S. Engelschall wrote:
On Tue, Nov 06, 2007, Gunnar Wrobel wrote:
Currently I fail to build the imapd package on rm0. It fails with
checking for db.h... yes
configure: error: Berkeley DB 3.x or later was not found. You may need to
supply the --with-bdb-libdir or --with-bdb-incdir configure options.
error: Bad exit status from /ltmp/kk/openpkg/rpm-tmp.18065 (%build)
I tried installing db45 but that didn't seem to help. What could I
do to fix that?
The problem is that the installed db package was built by me with
with_pthreads=yes a few days ago for testing purposes together with
OpenLDAP. I just forgot to reinstall a regular db package. Now
fixed.
Ah, nice hint. In the case we should add a conflict to the list of
dependencies. OTOH, if don't want to clutter all packages using db, why
not change the db package by building one version of db without thread
support and build a second version of db with thread support under a
different path. So we can handle it nicely in the db package itself.
In general: yes. But the with_pthread=yes option in db is really just
experimental. I even added a %{warn: ...} to it. I currently just need
it to allow one to drive a Pthread-based OpenLDAP and actually I would
like to get rid of db's with_pthread option at all again soon, too.
So, I don't think we should put any real efforts into this. Best is to
never build db with with_pthread=yes at all... Perhaps the %{warn}
in db.spec should be even a %{error}...
Furhtermore I just had a look at the imapd configure script. From my
point of view we can clean up several things in the imapd.spec file. The
shtool subst operations are obsolete. The '-L' and '-I' lines are not
longer existent and the rest seems to be handled correctly when invoking
configure with the '--with-bdb' option. Furthermore, '--with-bdb-incdir=
und '--with-bdb-libdir' don't make any sense as long the '--with-bdb'
option is given.
[...]
I build once with and without your patch and the result looks just fine.
I see no problem. Please commit these cleanup changes, Christoph.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/op/ op.conf op.spec
On Thu, Oct 25, 2007, Christoph Schug wrote: [...] Ralf, I don't think it's a good idea to shutdown paths here, in general they are not correct. At least on my FreeBSD boxes, it's /sbin/shutdown, and well, under Linux, which distribution flavor do you like? On Debian, it is /sbin/shutdown. I would suggest, just to hardcode the shutdown parameters for each platform and let shtool path do the rest on all platforms. Yes, good idea. Now implemented. Thanks for the feedback, Christoph. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/op/ op.conf op.spec
On Thu, Oct 25, 2007, Christoph Schug wrote: On Thu, Oct 25, 2007, Ralf S. Engelschall wrote: On Thu, Oct 25, 2007, Christoph Schug wrote: [...] Ralf, I don't think it's a good idea to shutdown paths here, in general they are not correct. At least on my FreeBSD boxes, it's /sbin/shutdown, and well, under Linux, which distribution flavor do you like? On Debian, it is /sbin/shutdown. I would suggest, just to hardcode the shutdown parameters for each platform and let shtool path do the rest on all platforms. Yes, good idea. Now implemented. Thanks for the feedback, Christoph. Argh, seems that shtool path is not (yet?) suitable for the job. First, the non-privileged build user might lack /sbin and /usr/sbin in it PATH. This one is solvable using the -p option. But second, shtool path searches for executables only (yes, of course). The problem is, that the shutdown binary might not be executable by non-privileged users (e.g., on FreeBSD, NetBSD) and therefore it cannot be found by shtool path. So, hard code everything? Improve GNU shtool? Hmmm... now it gets really complicated, yes. Perhaps we should just use other examples in the default op.conf? I wanted to add shutdown and reboot as samples as those are the usual ones one often needs. But if it becomes such nasty to provide the right values it perhaps is better to now provide anything. Sometimes it is better not to play at all. Hmmm.. I actually don't know what is best here... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: OpenLDAP 2.3.38 segfaults with db-4.6.21
On Thu, Oct 18, 2007, Gunnar Wrobel wrote: We are currently preparing the next Kolab release and the combination of the mentioned versions failed in our hands. We reverted back to db-4.5. There are several references on the web mentioning issues in that area. Here is one: http://bugs.archlinux.org/task/8311?project=1order=dateopenedsort=descorder2=sort2= Ok, I also can confirm that slapd is segfaulting. But at least the mentioned URL seems to talk about a different issue: just a version mismatch between Berkeley-DB used during build-time and run-time... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: MIME/Parser.pm incompatible with File/Temp.pm
On Thu, Oct 18, 2007, Gunnar Wrobel wrote: As the subject mentions I get a conflict between MIME/Parser.pm from perl-mail-5.8.8-20070928 and File/Temp.pm from perl-5.8.8-20071011 I see this error once a mail runs through amavis (and spamassassin). This is the error: Error in processing, id=19858-03, mime_decode-1 FAILED: Can't locate object method seek via package File::Temp at /kolabrelease/lib/perl/vendor_perl/5.8.8/MIME/Parser.pm It seems that the Parser.pm module expects File::Temp to be a subclass IO::Seekable which got implemented in File::Temp = 0.18 and the current package does not provide that. In principle the dependencies in the Mime::Parser package probably were not correctly defined upstream. http://groups.google.de/group/perl.cpan.testers/browse_thread/thread/cb814cb0d4b9c567/574ff5ef99afbfab%23574ff5ef99afbfab Any suggestion how I can fix the issue in the OpenPKG packages? I've include File::Temp 0.18 now in perl-sys. This should fix the issue. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: OpenLDAP 2.3.38 segfaults with db-4.6.21
On Thu, Oct 18, 2007, Ralf S. Engelschall wrote: On Thu, Oct 18, 2007, Gunnar Wrobel wrote: We are currently preparing the next Kolab release and the combination of the mentioned versions failed in our hands. We reverted back to db-4.5. There are several references on the web mentioning issues in that area. Here is one: http://bugs.archlinux.org/task/8311?project=1order=dateopenedsort=descorder2=sort2= Ok, I also can confirm that slapd is segfaulting. Ok, I really dislike this very very much, but I've packaged up Berkeley-DB 4.5.20.2 as db45 and use this in the openldap package. Only OpenLDAP 2.4.6 and higher will support Berkeley-DB 4.6 as it looks... :-( So, at least _your_ problems should be fixed now... ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/openssl/ openssl.patch
On Wed, Oct 17, 2007, Christoph Schug wrote: On Wed, Oct 17, 2007, Christoph Schug wrote: On Wed, Oct 17, 2007, Ralf S. Engelschall wrote: OpenPKG CVS Repository http://cvs.openpkg.org/ Server: cvs.openpkg.org Name: Ralf S. Engelschall Root: /v/openpkg/cvs Email: [EMAIL PROTECTED] Module: openpkg-src Date: 17-Oct-2007 10:01:05 Branch: HEAD Handle: 2007101709010400 Modified files: openpkg-src/openssl openssl.patch Log: fix patching Thanks! (was just building a fixed version but you has been faster ;) Do you fix openpkg as well? Thanks, fixed openpkg just appeared on my radar as well But it was still broken as today I seem unable to create correct patches. Now fixed. Should be available online in about 5 minutes. Then you can retry with the fixed bootstrap package. Sorry for the inconveniences... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/openldap/ openldap.spec
On Fri, Oct 12, 2007, Kolab Konsortium via Gunnar Wrobel wrote: Hm, the package from yesterday didn't make it on the ftp server. let's try again by bumping the release number. According to the upload logs, you still _never_ uploaded any file successfully. I've looked at your ~/.openpkg/dev.rc. Seemed like some entries were missing for the upload URL. I felt free to add it for you. Please upload all your packages again with opd rel after bumping the release date. You can find out which packages this was by looking for by kk under http://cvs.openpkg.org/timeline Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/openldap/ openldap.spec
On Fri, Oct 12, 2007, Ralf S. Engelschall wrote: On Fri, Oct 12, 2007, Gunnar Wrobel wrote: Ralf S. Engelschall [EMAIL PROTECTED] writes: On Fri, Oct 12, 2007, Kolab Konsortium via Gunnar Wrobel wrote: Hm, the package from yesterday didn't make it on the ftp server. let's try again by bumping the release number. According to the upload logs, you still _never_ uploaded any file successfully. I've looked at your ~/.openpkg/dev.rc. Seemed like some entries were missing for the upload URL. I felt free to add it for you. Please upload all your packages again with opd rel after bumping the release date. You can find out which packages this was by looking for by kk under http://cvs.openpkg.org/timeline Hm, now I get: ++ releasing openldap-2.3.38-20071012.src.rpm to distribution area OpenPKG /current/SRC/00UPLOAD/ Permission denied (publickey,password,keyboard-interactive). lost connection ++ determining commit message Is this missing the ssh key? No, but Steffen Hansen's key was still konfigured for the Kolab Konsortium. I've now replaced his key with your one. Please retry again. Sorry for the inconviences. Fine, now your upload finally worked! Now please upload also the other packages you changed. AFAIK a simple opd rel without any changes should do the trick, too. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/openldap/ openldap.spec
On Fri, Oct 12, 2007, Gunnar Wrobel wrote: Ralf S. Engelschall [EMAIL PROTECTED] writes: On Fri, Oct 12, 2007, Kolab Konsortium via Gunnar Wrobel wrote: Hm, the package from yesterday didn't make it on the ftp server. let's try again by bumping the release number. According to the upload logs, you still _never_ uploaded any file successfully. I've looked at your ~/.openpkg/dev.rc. Seemed like some entries were missing for the upload URL. I felt free to add it for you. Please upload all your packages again with opd rel after bumping the release date. You can find out which packages this was by looking for by kk under http://cvs.openpkg.org/timeline Hm, now I get: ++ releasing openldap-2.3.38-20071012.src.rpm to distribution area OpenPKG /current/SRC/00UPLOAD/ Permission denied (publickey,password,keyboard-interactive). lost connection ++ determining commit message Is this missing the ssh key? No, but Steffen Hansen's key was still konfigured for the Kolab Konsortium. I've now replaced his key with your one. Please retry again. Sorry for the inconviences. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/openldap/ openldap.spec
On Fri, Oct 12, 2007, Gunnar Wrobel wrote: [...] Fine, now your upload finally worked! Now please upload also the other packages you changed. Both gd and perl were fixed by you afterwards. So it was only openldap still missing. Really? AFAIK you also touched imapd, imap, etc... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/gd/ gd.spec
On Thu, Oct 11, 2007, Kolab Konsortium via Gunnar Wrobel wrote:
[...]
Log:
Run libtoolize if you rebuild the configure system. See
http://article.gmane.org/gmane.linux.gentoo.devel/23449. This allows
to build gd on a recent gentoo system.
[...]
%{l_shtool} subst -e 's;-LNONE;;' Makefile
+libtoolize --copy --force
%{l_make} %{l_mflags}
%{l_shtool} subst -e 's;/usr/bin/perl;%{l_prefix}/bin/perl;' bdftogd
Hmmm...
1. libtoolize is provided by the libtool package. If it is used, a
dependency to the libtool package has to added, too.
2. running libtoolize _after_ running the configure script
seems to be wrong and technically useless to me. If the libtool
files really are out of sync and a libtoolize run should be
required, it IMHO has to be done _before_ running configure.
3. The above URL shows a discussion which tells that the generated
files can be go out of sync if just autoconf is run. But the
OpenPKG gd package does not run autoconf and it also doesn't
patch autoconf input files (and so autoconf should be also not
run implicitly). So how should the files gone out of sync here?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/gd/ gd.spec
On Thu, Oct 11, 2007, Gunnar Wrobel wrote: [...] config.status: executing depfiles commands + /kolab/lib/openpkg/shtool subst -e 's;-LNONE;;' Makefile shtool:subst:Warning: substitution resulted in no content change on file Makefile + /kolab/bin/make --no-print-directory cd . /bin/sh /kolab/RPM/TMP/gd-2.0.35/config/missing --run aclocal-1.9 -I config cd . /bin/sh /kolab/RPM/TMP/gd-2.0.35/config/missing --run automake-1.9 --foreign cd . /bin/sh /kolab/RPM/TMP/gd-2.0.35/config/missing --run autoconf Ok, I see. I've tried to apply the usual workaround which we have already in many other packages. Can you retry with the latest gd package to make sure that the workaround also works for you? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Problem with shtool on IRIX6
On Thu, Oct 04, 2007, Joerg Lehrke wrote: I know that IRIX is not a supported platform, but the problem I found there can be avoided easily. /bin/sh messes up the opt_e string within the install command of shtool. Especially the MySQL RPM build fails on IRIX because of this. Since OpenPKG provides a BASH this shell should be used for all crucial scripts. At least we were on the safe side this way, what you think? So, there is no bug in GNU shtool's shtool install command, but the /bin/sh of IRIX fails over the opt_e variable, right? Strange! Is opt_e something special in IRIX /bin/sh? Well, ok... In general I also prefer to use GNU bash inside OpenPKG, but in the particular case of GNU shtool I would like to better stay with just the vendor's /bin/sh. Why? Well, how should I explain this I know that the author of GNU shtool uses OpenPKG as its unofficial field test area for his tool ;-) So, if OpenPKG starts running its shtool version under GNU bash, then the GNU shtool author could be certainly less sure that GNU shtool _really_ works on all major Unix platform out-of-the-box. Nevertheless I would like to see GNU shtool working with IRIX' /bin/sh out-of-the-box. So, can we give the upstream author a little bit of details about the problem? Is just the _name_ of the variable the problem? Or its particular use? I can ensure that the upstream author looks at our issue in more detail if we have the necessary information at hand for him... ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Problem with shtool on IRIX6
On Fri, Oct 05, 2007, Joerg Lehrke wrote: The problem is caused by following block within the shtool install function: [...] Ah, I see. Well, mysql.spec's usage of shtool subst with _arbitrary_ complex sed(1) style -e options is already the source of the trouble. I'll see what we can do for GNU shtool but in the meantime I've changed mysql.spec to use a regular simple sed(1) call. That's just fine here, too. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Problem with shtool on IRIX6
On Fri, Oct 05, 2007, Christoph Schug wrote:
On Fri, Oct 05, 2007, Ralf S. Engelschall wrote:
On Fri, Oct 05, 2007, Joerg Lehrke wrote:
The problem is caused by following block within the shtool install
function:
[...]
Ah, I see. Well, mysql.spec's usage of shtool subst with _arbitrary_
complex sed(1) style -e options is already the source of the trouble.
I'll see what we can do for GNU shtool but in the meantime I've changed
mysql.spec to use a regular simple sed(1) call. That's just fine here,
too.
I don't feel very comfortable with the solution applied to the MySQL
package. To be honest, the sed expressions in question aren't that
complex. As there might be other expressions, similar or not, which
would also not work under IRIX, we end up with a vaguely definied
list of functionality which is not working as documented. So on
what features can we rely on and which ones not in the future? This
might affect dozens of packages. If the problem can be fixed on this
very specific platform, IRIX, why not define the %{l_shool} macro
differently on that platform, maybe one can expand it to '%{l_bash}
%{l_prefix}/lib/openpkg/shtool' on IRIX and stick with the default on
all the other platforms.
Well, I have to agree that it really was just a workaround here. If
someone can come up with a better solution (a fix for GNU shtool?)
I would be happy. I just was not able to find one by looking at the
provides outputs. I do not see why the stuff fails on IRIX. At least
s/../../ commands never caused us such trouble, so I guess it is
related to the other sed commands used here.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/postgrey/ postgrey.spec
On Wed, Oct 03, 2007, Christoph Schug wrote:
fix shebang
[...]
--e 's;#!/usr/bin/perl -T;#!%{l_prefix}/bin/perl;g' \
+-e 's;#!/usr/bin/perl;#!%{l_prefix}/bin/perl;g' \
[...]
Err... The removal of also -T (tainting) was not a typo. It really
_should_ be removed as postrey's taining is not compatible with the
latest Net::Server stuff we have in perl-net. So, the -T really has to
be removed.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/postgrey/ postgrey.spec
On Wed, Oct 03, 2007, Christoph Schug wrote:
On Wed, Oct 03, 2007, Ralf S. Engelschall wrote:
On Wed, Oct 03, 2007, Christoph Schug wrote:
fix shebang
[...]
--e 's;#!/usr/bin/perl -T;#!%{l_prefix}/bin/perl;g' \
+-e 's;#!/usr/bin/perl;#!%{l_prefix}/bin/perl;g' \
[...]
Err... The removal of also -T (tainting) was not a typo. It really
_should_ be removed as postrey's taining is not compatible with the
latest Net::Server stuff we have in perl-net. So, the -T really has to
be removed.
There is no '-T' (anymore?), therefore the subst failed before.
Oh, I see. The upstream author has already removed it! Ok, thanks for
clarification, Christoph. I overlooked the fact that a new upstream
version already is present here, as it was just recently that I had to
fix the stuff by adding the -T in our substitution. Thanks.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Openpkg Source Kolab2 Solaris 10 Sparcdb4 major version not recognized
On Thu, Aug 30, 2007, ComCept GmbH Andrea Soliva wrote: Was there a time to look into this issue described below? [...] As promised here the neccessary information... [...] | [...] | What one has to do is to inspect the config.log file in the | /kolab/RPM/TMP/php-*/ directory to see more details about the above | problem. There is a mismatch between the version the picked up db.h | [...] Without more details we cannot help you here as we still cannot reproduce it ourself with the latest OpenPKG-CURRENT. So, please please digg for the details in the config.log for additional hints to the root of the problems. Thanks for digging out more information, but AFAIK under the mentioned URL there is still no information about the config.log, isn't it? Sorry having to say this but _THAT IS_ the essential information for which I asked. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: ctype support in php
On Fri, Aug 24, 2007, Gunnar Wrobel wrote: For some new PHP based packages for the Kolab server I'd require the ctype flag to be activated on php. The current OpenPKG php.spec file does not support this and I attached a patch for it. The same would also apply to the apache2-php definition that we are currently using for the Kolab Server but I did not find the package in your cvs. I also attached that patch. I'd be grateful if this could be integrated. Integrated into our php and apache-php packages. The apache2-php is now named apache-php as we finally upgraded OpenPKG from Apache 1.3 to 2.2 recently. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Openpkg Source Kolab2 Solaris 10 Sparc db4 major version not recognized
On Fri, Aug 10, 2007, Bernhard Reiter wrote: On Monday 30 July 2007 13:58, Ralf S. Engelschall wrote: while AFAIK even the latest Kolab 2.1 is based on a lot older OpenPKG packages and this way older PHP and DB versions. Kolab Server 2.2beta1 is a lot newer and Andrea tried with it as well (as we mentioned). Aim should be to solve the issue for the next server 2.2beta. Sure, but please see my reply, Bernhard: | [...] | What one has to do is to inspect the config.log file in the | /kolab/RPM/TMP/php-*/ directory to see more details about the above | problem. There is a mismatch between the version the picked up db.h | [...] Without more details we cannot help you here as we still cannot reproduce it ourself with the latest OpenPKG-CURRENT. So, please please digg for the details in the config.log for additional hints to the root of the problems. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Openpkg Source Kolab2 Solaris 10 Sparcdb4 major version not recognized
On Thu, Aug 09, 2007, ComCept GmbH Andrea Soliva wrote: I wrote this message for about one week. Any comments on this issue? http://marc.info/?l=openpkg-devm=118579674004043w=2 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: rcService: command not found
On Tue, Jul 31, 2007, Olivier Kaloudoff wrote: Hello list ! I just installed snort on current, but at rc.snort start, it fails with rcService: command not found. Browsing the web, it turns out that it might be a mismatch between snort rc scripts and openpkg ones, so I updated openpkg to 20070718 .. still the same problem .. any ideas ? -bash-3.00# sh -x /openpkg/etc/rc.d/rc.snort start [...] Sorry, rc.xxx are _NOT_ a regular shell scripts! See the first she bang line in rc.xxx scripts: | #!prefix/bin/openpkg rc So, it has to be executed through the openpkg rc shell. You can't just run sh -x on it as it contains RPM-style sections, etc. You have to run it via: $ /openpkg/bin/openpkg rc snort [...]# canonical way $ /openpkg/etc/rc.d/rc.snort [...] # alternative way Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Openpkg Source Kolab2 Solaris 10 Sparc db4 major version not recognized
On Mon, Jul 30, 2007, Andrea Soliva wrote:
[...]
checking for sys/types.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for strtoll... yes
checking for atoll... yes
checking for strftime... (cached) yes
checking whether to enable DBA... no
checking for QDBM support... no
checking for GDBM support... no
checking for NDBM support... no
checking for db4 major version... configure: error: Header contains
different version
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.259 (%build)
I guess we are talking about the php package with the option
with_bdb set to yes. When I try this under FreeBSD 6 with the latest
php package from OpenPKG-CURRENT I see:
| checking for QDBM support... no
| checking for GDBM support... no
| checking for NDBM support... no
| checking for db4 minor version and patch level... ok
| checking for Berkeley DB4 support... yes
| checking for Berkeley DB3 support... no
| checking for Berkeley DB2 support... no
| checking for DB1 support... no
So, I cannot reproduce this with at least the latest OpenPKG packages.
But this is with PHP 5.1.4 and DB 4.6.18 while AFAIK even the latest
Kolab 2.1 is based on a lot older OpenPKG packages and this way older
PHP and DB versions.
[...]
-- Do you know this error/issue etc. ?
No, not known until now. Unfortunately, the versions of OpenPKG packages
which are still used by Kolab 2.1 went already end-of-life at the
OpenPKG side about a year ago.
-- If yes is there a solution/workaround ?
-- If no can you please me deliver what you exact need to go forward to
troubleshoot this issue (known by kolab2 dev list under issue 1809).
[...]
I don't know whether there is a simple workaround. But there is
certainly a solution possible if one accepts to fix the packaging, of
course. But the solution depends on the details of the problem.
What one has to do is to inspect the config.log file in the
/kolab/RPM/TMP/php-*/ directory to see more details about the above
problem. There is a mismatch between the version the picked up db.h
header and the version in the libdb.a. This is certainly the case
because either the libdb.a is not found at all or there is a second
libdb.{a,so} somewhere on the system which accidentally got picked up.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: implict and explicit requirements (Was: Re: HEADS UP: Apache 2.2 is coming...)
On Tue, Jul 24, 2007, Christoph Schug wrote: [...] Well, another question regarding both PHP packages, 'php' and 'apache-php'. Why is there a run-time requirement for a MTA by default? I thought this is exactly why we have the 'with_sendmail' option. If no one speaks up, I will drop the default MTA dependency. I now dropped it as I cannot remember why it was there. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Milter build problems again.
On Mon, Jul 23, 2007, Birger Krägelin wrote: Anyhow, I am wondering why the decision was made to move the milter include files to milter/*.h instead of the default libmilter/*.h? If something really needs the includes in milter/*.h maybe a symbolic link should be made so it works for both locations. Maybe I am just missing something, but any ideas would be helpful. Simply because a package named foo should provide its includes in prefix/include or prefix/include/foo and not in any other location. So another decision might be to rename the milter library to libmilter and provide the include files in libmilter/*.h Milter is the actual program running as a mail filter, libmilter is the library to link against. My vote is for a package named libmilter with default paths from the authors. I vote against patching mimedefang. If we would just have the milter package I also would vote for renaming it to libmilter immediately. But what about the milter-xxx packages? They use the milter prefix to show their correlation to the milter package. Until now all foo-bar packages were directly related to a central foo package (e.g. perl and perl-xxx, python and python-xxx, etc). Sure, we can break this convention here, but is it worth the effort? The mimedefang package is now already fixed and I don't know at least about any remaining issues. I see enough arguments to keep the default paths of software. The naming scheme for the OpenPKG packages shold reflect these. Yes and no. Yes, as long as it makes sense from a consistency point of view, OpenPKG always should (and actually does AFAIK) follow the names and paths of the upstream vendor. But, no, if the upstream vendor decides for a path which doesn't fit very well into the filesystem layout of OpenPKG (here the libmilter example would be still fine, of course) we definetely will make it fit (and not adjust our side according to the upstream vendor intentions). There are just too many existing upstream vendor intentions -- if we too flexibly adjust our filesystem layout to them, OpenPKG instances would be a mess within a short timeframe. But, this is a generic statement here and as an exception does not really apply to the Sendmail Milter API as a libmilter would still fit into the layout, of course. Just to give you an example what does *not* fit: prefix/include/foo-1.2.3/ or prefix/var/run/ as many upstream authors prefer, or prefix/share/man/ and prefix/share/info/ as the newer GNU Autoconf prefers. So what? Who prefers... 1. to rename milter to libmilter despite the fact that this breaks the OpenPKG convention of a central master package foo and sub-packages foo-bar? 2. or to keep the milter package and the already existing #include libmilter/* to #include milter/* patches in the milter-xxx packages. Birger voted for (2). I personally still vote for (1) as this means nothing to be done and to not break the conventions (although it doesn't follow the upstream vendor intention). More votes? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: traceroute-1.4a12 / current / Darwin
On Thu, Jul 19, 2007, Olivier Kaloudoff wrote:
to compile traceroute on Darwin, I had to tweak 2 files with a very
short
change (aclocal.m4 and findsaddr-socket.c). Something more heavy was
needed, replace original config.sub and config.guess by the one provided by
Apple (last update, 1999 whereas traceroute has 1996). Change is about 2000
lines ..
For bringing the config.* files to a newer level you can just require
the config package and then run %{l_prefix}/bin/config install .
in the traceroute.spec:%build. This way you especially do not need the
aclocal.m4 patch and no dependency to AutoXXX.
running aclocal ; autoconf ; configure ; make works like a charm after
this...
Are patches for Darwin accepted in current for openpkg ? If yes, what
should I do about config.guess and config.sub ? Push patch for the moment,
ask the upstream packager to update their version, and remove the patch
when done ?
Sure, Darwin is just fine. Kick your findsaddr-socket.c fix and the
the above config install into our traceroute package, please.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: ACCESS DENIED: Christoph Schug
On Fri, Jul 20, 2007, Christoph Schug wrote: ATTENTION: ACCESS DENIED OpenPKG CVS Repository denied COMMIT access for user Christoph Schug [EMAIL PROTECTED] on files: o openpkg-src/varnish/rc.varnish:HEAD o openpkg-src/varnish/varnish.patch:HEAD o openpkg-src/varnish/varnish.spec:HEAD Just don't panic, guys. Thomas is busy in performing a mass commit for about 100 packages and for this he just temporarily disabled all developer access. Once you see his commit mail you should be again able to commit just fine. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Milter build problems again.
On Fri, Jul 20, 2007, Mark Keller wrote: I had discussed a milter problem before in a previous request to the openpkg-dev list. http://marc.info/?l=openpkg-devm=117147128624622w=2 It turns out I have the problem again now that I am trying to uprade our packages. The mimedefang package fails to build because it is looking for the milter include files in libmilter/*.h, but openpkg seems to install the includes in milter/*.h. milter_cap.c:15:29: error: libmilter/mfapi.h: No such file or directory In file included from milter_cap.c:16: milter_cap.h:15:2: error: #error You must include libmilter/mfapi.h before milter_cap.h The fix that Ralph made last time at least got the package to build, but now that I look at the cvs log I don't see how that fixed the problem and it certainly doesn't work now. I do have binaries from last time, but can't repeat the process now. Yes, seems like mimedefang introduced another source file which needs patching now, too. Now fixed. Anyhow, I am wondering why the decision was made to move the milter include files to milter/*.h instead of the default libmilter/*.h? If something really needs the includes in milter/*.h maybe a symbolic link should be made so it works for both locations. Maybe I am just missing something, but any ideas would be helpful. Simply because a package named foo should provide its includes in prefix/include or prefix/include/foo and not in any other location. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: implict and explicit requirements (Was: Re: HEADS UP: Apache 2.2 is coming...)
On Wed, Jul 11, 2007, Thomas Lotterer wrote: The topic is about how to handle with_foo for a with_foo_bar option that only makes sense in concert with with_foo. On Tue, Jul 10, 2007, Christoph Schug wrote: For me, it looks more like the second [implicit] case, but I might be wrong. If not, there should be some fiddling in the fixing implicit extension dependencies and correlations section, right? I remember the implicit dependency issue but wasn't sure what the best practice is to make clear to the user that with_imap_annotate implies with_imap. My ideas were: - use if with_foo || with_foo_bar in the with_foo logic this will build with_foo if only with_foo_bar is given but rpm -qi will show up with_foo=no. Bad - implicitly set with_foo=yes when the user chooses with_foo_bar AFAIK the current practice. Build and query ok, but somewhat magic. - make the package require itself, enforcing an explicit setting Something like if with_foo_bar then require self::with_foo=yes If the latter works, I'd prefer it. Never tested it. As I think RPM will not allow the latter, just use the second one. This is what we already have in a bunch of similar packages. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Tue, Jul 10, 2007, Christoph Schug wrote: On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. OpenPKG-CURRENT is now finally upgraded. When you upgrade your instances, please notice that manual intervention is required as mod_php and mod_perl are now in their own packages apache-php and apache-perl. So, previously you installed a PHP/Perl-aware Apache with e.g. openpkg builld -D with_mod_php -D with_mod_php_xml -D with_mod_perl apache | sh while now you have to use openpkg builld-D apache-php::with_xml apache apache-php apache-perl | sh. If been playing around with the new apache packages lately. Here's my list of annotations :-) Apache's default config references several snakeoil SSL certs which aren't supplied by the package leaving Apache in an unusable state. As there doesn't seem to be a helpful script at hand like mod_ssl's mkcert.sh there a several routes to go. The obvious is to steal mkcert.sh from mod_ssl and incorporate it into the apache package. OTOH there might be other packages which could benefit from a general purpose (dummy) cert facility as well. As openssl is part of the bootstrap might it be a better idea to provide such a facility as part of the openpkg package? I don't think this really has to be provided already by the boostrap (openpkg) package. But a dedicated openpkg-x509 package might be more than just reasonable. All packages which require an X.509 certificate should use this to generate one -- both snake-oil, self-signed and real ones, of course. Next topic: apache-php. I haven't played with every single option but there's one I found a little bit curious in the spec file. As I haven't any application which makes use of that specific functionality I want to raise the issue here on the list. apache-php provides an option called 'with_imap_annotate'. It's unclear to me whether this in an independent option or it's just a variant of 'with_imap'. For me, it looks more like the second case, but I might be wrong. If not, there should be some fiddling in the fixing implicit extension dependencies and correlations section, right? Perhaps this is from the Kolab changes? Thomas? [...] Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/swig/ swig.spec
On Thu, Jul 05, 2007, Christoph Schug wrote:
upgrading package: swig 1.3.29 - 1.3.31
Sorry, every version since 1.3.29 breaks for me under FreeBSD.
You can see it on rm0.openpkg.net:
| checking for Guile header files... /openpkg-dev/include
| checking for Guile library... checking whether Guile's gh_ API works... no
| checking whether Guile's SCM_ API works... no
| ./configure: line 7487: syntax error near unexpected token `('
| ./configure: line 7487: ` RUBYDIR=`($RUBY -rmkmf -e 'print
Config::CONFIG[archdir] || $archdir') 2/dev/null`'
| error: Bad exit status from /tmp/rse/openpkg/rpm-tmp.54670 (%build)
I've already looked at this once, but was not able to figure out
immediately a solution. Can you investigate on this?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/expat/ expat.spec
On Fri, Jun 29, 2007, Christoph Schug wrote:
fixed %prep section; while being here removed %{V_date} which I don't
see a reason for (flawed tarball in the past?)
Yes, it was broken in the past and even the 2.0.1 tarball was broken
and seems to be be now replaced in place by the upstream vendor.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Fix to R package
On Wed, Jun 27, 2007, Dennis McRitchie wrote: I just uploaded a modified spec file for the R statistical package. The fix is to patch *both* R scripts, and to patch not just R_HOME_DIR, but also R_SHARE_DIR, R_INCLUDE_DIR, and R_DOC_DIR. This is necessary to allow packages to be installed. Now fixed in the latest r package of OpenPKG CURRENT -- together with another packaging bug. Thanks for your feedback and support. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/cacti/ cacti.spec
On Mon, Jun 25, 2007, Christoph Schug wrote: On Mon, Jun 25, 2007, Ralf S. Engelschall wrote: OpenPKG CVS Repository http://cvs.openpkg.org/ Server: cvs.openpkg.org Name: Ralf S. Engelschall Root: /v/openpkg/cvs Email: [EMAIL PROTECTED] Module: openpkg-src Date: 25-Jun-2007 22:50:28 Branch: HEAD Handle: 2007062521502800 Modified files: openpkg-src/cacti cacti.spec Log: fix dependencies If I'm not wrong it's not just fixing deps to make this package Apache 2.2 compliant. The configuration file needs adjustments as well. For example, s/IfModule mod_ssl.c/IfModule ssl_module/g . Ah, good catch. But a diff between cacti-apacher.conf and joomla-apache.conf (which I packaged and tested yesterday) shows just this as the difference. So I guess adjusting the IfModule stuff should finally fix it. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. OpenPKG-CURRENT is now finally upgraded. When you upgrade your instances, please notice that manual intervention is required as mod_php and mod_perl are now in their own packages apache-php and apache-perl. So, previously you installed a PHP/Perl-aware Apache with e.g. openpkg builld -D with_mod_php -D with_mod_php_xml -D with_mod_perl apache | sh while now you have to use openpkg builld-D apache-php::with_xml apache apache-php apache-perl | sh. Experience shows that Apache 1.3 seems to have had some sort of a security bug: access was granted to RewriteRule-mapped directories without actually requiring one to explicitly enable access to this diretcory (area). Apache 2 now handles the access control correctly, but unfortunately this means that one three sites I now already had to add a bunch of missing config directives to re-enable access. So, in case you hit the same problem, just remember that it worked in Apache 1.3 -- but IMHO more because of a bug. Apache 2 is correct here, so you have to explicitly enable access. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
HEADS UP: Apache 2.2 is coming...
Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. OpenPKG-CURRENT is now finally upgraded. When you upgrade your instances, please notice that manual intervention is required as mod_php and mod_perl are now in their own packages apache-php and apache-perl. So, previously you installed a PHP/Perl-aware Apache with e.g. openpkg builld -D with_mod_php -D with_mod_php_xml -D with_mod_perl apache | sh while now you have to use openpkg builld-D apache-php::with_xml apache apache-php apache-perl | sh. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: access to any machine [EMAIL PROTECTED]
On Fri, Jun 08, 2007, Olivier Kaloudoff wrote: I successfully logged onto login.openpkg.net, but whenever I select a machine to connect to and press enter, my connection gets closed .. maybe I need an additionnal access ? You _have_ to run an SSH agent locally as the setup uses a gateway which runs another SSH connection to the backend servers and this requires access to your SSH key. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: OpenPKG on Mac OS X 10.4
On Sat, Jun 09, 2007, Anders F Björklund wrote:
I've now tried to build our gcc package (GCC 4.2.0). t starts just
Ifine and compiles lots of things, but then it unfortunately fails
[...]
| strip -o libgcc_s.10.4.dylib_T${mlib} \
| -s
/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/../gcc/config/i386/darwin-libgcc.10.4.ver
-c -u \
| ./${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \
| done
| strip: can't open file:
/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/gcc/libgcc_s.1.dylib.tmp (No such
file or directory)
| make[3]: *** [libgcc_s.10.4.dylib] Error 1
| make[2]: *** [all-stage1-gcc] Error 2
| make[1]: *** [stage1-bubble] Error 2
| make: *** [bootstrap-lean] Error 2
Has anybody already seen this problem related to libgcc_s.1.dylib?
Yes, it's a known problem - Darwin doesn't support static libgcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
Was anybody already successful in building a stock GCC 4.2.0 under Mac OS
X?
My computer unfortunately started kernel panicking recently,
so I will have to downgrade to Mac OS X 10.4.8 and try again...
I think it should work without the --disable-shared, though ?
Ok, let's see: I'll retry with --enable-shared...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: OpenPKG on Mac OS X 10.4
On Sat, Jun 09, 2007, Ralf S. Engelschall wrote:
On Sat, Jun 09, 2007, Anders F Björklund wrote:
I've now tried to build our gcc package (GCC 4.2.0). t starts just
Ifine and compiles lots of things, but then it unfortunately fails
[...]
| strip -o libgcc_s.10.4.dylib_T${mlib} \
| -s
/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/../gcc/config/i386/darwin-libgcc.10.4.ver
-c -u \
| ./${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \
| done
| strip: can't open file:
/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/gcc/libgcc_s.1.dylib.tmp (No such
file or directory)
| make[3]: *** [libgcc_s.10.4.dylib] Error 1
| make[2]: *** [all-stage1-gcc] Error 2
| make[1]: *** [stage1-bubble] Error 2
| make: *** [bootstrap-lean] Error 2
Has anybody already seen this problem related to libgcc_s.1.dylib?
Yes, it's a known problem - Darwin doesn't support static libgcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
Was anybody already successful in building a stock GCC 4.2.0 under Mac OS
X?
My computer unfortunately started kernel panicking recently,
so I will have to downgrade to Mac OS X 10.4.8 and try again...
I think it should work without the --disable-shared, though ?
Ok, let's see: I'll retry with --enable-shared...
Hmmm... now the library was built but a tool (I've never heard of in my
Unix life) named lipo now complains:
| # When building multilibbed target libraries, all the required
| # libraries are expected to exist in the multilib directory.
| MLIBS=`/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/./gcc/xgcc
-B/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/./gcc/
-B/Users/rse/openpkg/i386-apple-darwin8.9.1/bin/
-B/Users/rse/openpkg/i386-apple-darwin8.9.1/lib/ -isystem
/Users/rse/openpkg/i386-apple-darwin8.9.1/include -isystem
/Users/rse/openpkg/i386-apple-darwin8.9.1/sys-include --print-multi-lib \
| | sed -e 's/;.*$//' -e '/^\.$/d'` ; \
| for mlib in $MLIBS ; do \
| rm -f ${mlib}/libgcc_s.10.4.dylib || exit 1 ; \
| ln -s ../libgcc_s.10.4.dylib ${mlib}/libgcc_s.10.4.dylib || exit 1
; \
| done
| MLIBS=`/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/./gcc/xgcc
-B/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/./gcc/
-B/Users/rse/openpkg/i386-apple-darwin8.9.1/bin/
-B/Users/rse/openpkg/i386-apple-darwin8.9.1/lib/ -isystem
/Users/rse/openpkg/i386-apple-darwin8.9.1/include -isystem
/Users/rse/openpkg/i386-apple-darwin8.9.1/sys-include --print-multi-lib \
| | sed -e 's/;.*$//' -e '/^\.$/d'` ; \
| for mlib in '' $MLIBS ; do \
| strip -o libgcc_s.10.4.dylib_T${mlib} \
| -s
/Users/rse/openpkg/RPM/TMP/gcc-4.2.0/obj/../gcc/config/i386/darwin-libgcc.10.4.ver
-c -u \
| ./${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \
| done
| lipo -output libgcc_s.10.4.dylib -create libgcc_s.10.4.dylib_T*
| lipo: can't figure out the architecture type of: libgcc_s.10.4.dylib_T
| make[3]: *** [libgcc_s.10.4.dylib] Error 1
| make[2]: *** [all-stage1-gcc] Error 2
| make[1]: *** [stage1-bubble] Error 2
| make: *** [bootstrap-lean] Error 2
| error: Bad exit status from /Users/rse/openpkg/RPM/TMP/rpm-tmp.9343 (%build)
Seems like lipo is some sort of a tool for the Universal Binaries
stuff of Mac OS X and the generated libgcc_s.10.4.dylib file seems to be
not carrying the information it expects. Hmmm.. but for the generation
of this file now the Mac OS X tool chain is used. Why to the hell is
this Mac OS X platform such different and is not willing to just play
nicely with us!?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Mac OS X: OpenSSL again
On Wed, Jun 06, 2007, Anders F Björklund wrote:
Ralf S. Engelschall wrote:
So appending -Wl,-search_paths_first to the LDFLAGS should work too.
Cool, that's it! If we now override the cc, gcc and ld commands under
Mac OS X and enfore this option, the various linking problems you have
observed should be gone. What about the following (untested) patch?
The patch works, though we might want to filter out the extra warning
issued when using gcc/g++ for just compiling and not doing any linking:
-search_paths_first: linker input file unused because linking not done
Otherwise you get one of those for each gcc -c, since the override
can't tell whether gcc is going to be used for compiling or linking...
Oh, I see. Ok, I've now improved the wrapper scripts. Please manually
remove prefix/libexec/openpkg/override/{cc,gcc} and upgrade to the
latest bootstrap version as of today. Then if -c or -E is present
on the compiler command line the -Wl,-search_paths_first should be no
longer used and this way the warning be gone.
And need to provide fake binutils/gcc packages, with /usr symlinks.
(so that dependencies and such work, otherwise it'll try to install)
/openpkg/bin/cc - /usr/bin/cc
/openpkg/bin/gcc - /usr/bin/gcc
This can be provided by openpkg-import.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Darwin (Mac OS X) platform names
On Mon, Jun 04, 2007, Anders F Björklund wrote: Ralf S. Engelschall wrote: It should be: concise system product: Mac OS X 10 regular system product: Mac OS X 10.3 verbose system product: Apple Mac OS X 10.3.9 And the technology should be: concise system technology: Darwin 7 regular system technology: Darwin 7.9 verbose system technology: Apple Darwin 7.9.0 So, the truncation was still incorrect. Hell, it is rather complicated to get it right when one has to do it blindly. Find attached one more version where I now also tried to fix the truncation. Works as intended. concise system product: Mac OS X 10 regular system product: Mac OS X 10.3 verbose system product: Apple Mac OS X 10.3.9 concise system technology: Darwin 7 regular system technology: Darwin 7.9 verbose system technology: Apple Darwin 7.9.0 Good blind flying! Just an idea/suggestion, truncating to 10 is too much... Really? Keep in mind that it would be reduced to 10 just for the _concise_ format which is extremely truncated for mostly all platforms. Well, it depends on whether you want the version to say anything or if it should just say number 10 for OS X or something... :-) But Mac OS X 10.3 == Darwin 7, so Mac OS X 10 would equal Darwin. (as opposed to for instance Mac OS X Server 1.x which was Rhapsody) Ok, you conviced me. For Mac OS X it certainly makes sense to keep 10.x even in the concise output. Now committed this way to the OSSP CVS for inclusion in the next GNU shtool version and a snapshot is now also committed to the OpenPKG bootstrap package. Thanks for your great support. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: openpkg-20070603-20070603 build problems
On Sun, Jun 03, 2007, Thomas Arendsen Hein wrote: When building openpkg-20070603-20070603.src.sh on Debian etch on x86 I get the following error while 20070520 compiles fine on that box. My fault. During upgrade of openssl.patch I've overlooked that there were bootstrap specific parts in it. Parts resurrected and it now should build again. Sorry and thanks for reporting. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Mac OS X: OpenSSL again
On Sun, Jun 03, 2007, Anders F Björklund wrote:
I don't know of any linker option to have it look for static libs
(other than explicitly listing them by name), but either a wrapper
to the binary or even patching the source of the binary is doable.
Reading through the source code I realize I didn't look *that* hard:
-search_paths_first
By default when the -dynamic flag is in effect, the -lx and
-weak-lx options first search for a file of the form
`libx.dylib' in each directory in the library search path, then
a file of the form `libx.a' is searched for in the library
search paths. This option changes it so that in each path
`libx.dylib' is searched for then `libx.a' before the next path
in the library search path is searched.
So appending -Wl,-search_paths_first to the LDFLAGS should work too.
Cool, that's it! If we now override the cc, gcc and ld commands under
Mac OS X and enfore this option, the various linking problems you have
observed should be gone. What about the following (untested) patch?
Index: openpkg.spec
===
RCS file: /v/openpkg/cvs/openpkg-src/openpkg/openpkg.spec,v
retrieving revision 1.589
diff -u -d -u -d -u -d -r1.589 openpkg.spec
--- openpkg.spec3 Jun 2007 09:47:55 - 1.589
+++ openpkg.spec3 Jun 2007 21:02:49 -
@@ -2437,6 +2437,29 @@
chmod 775 %{l_prefix}/lib/openpkg/override/install-info
fi
;;
+*-*-macos10.* | *-*-darwin* )
+gcc=`%{l_prefix}/lib/openpkg/shtool path gcc`
+cc=`%{l_prefix}/lib/openpkg/shtool path cc`
+ld=`%{l_prefix}/lib/openpkg/shtool path ld`
+if [ .$gcc != . -a ! -f %{l_prefix}/lib/openpkg/override/gcc ];
then
+( echo #!/bin/sh
+ echo $gcc -Wl,-search_paths_first \[EMAIL PROTECTED]
+) %{l_prefix}/lib/openpkg/override/gcc
+chmod 775 %{l_prefix}/lib/openpkg/override/gcc
+fi
+if [ .$cc != . -a ! -f %{l_prefix}/lib/openpkg/override/cc ];
then
+( echo #!/bin/sh
+ echo $cc -Wl,-search_paths_first \[EMAIL PROTECTED]
+) %{l_prefix}/lib/openpkg/override/cc
+chmod 775 %{l_prefix}/lib/openpkg/override/cc
+fi
+if [ .$ld != . -a ! -f %{l_prefix}/lib/openpkg/override/ld ];
then
+( echo #!/bin/sh
+ echo $ld -search_paths_first \[EMAIL PROTECTED]
+) %{l_prefix}/lib/openpkg/override/ld
+chmod 775 %{l_prefix}/lib/openpkg/override/ld
+fi
+;;
esac
# FIXME: hack to workaround problems in environments with too few
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: clamav-0.90.2-20070413 compile problem
On Thu, May 31, 2007, Thomas Arendsen Hein wrote:
* Thomas Arendsen Hein [EMAIL PROTECTED] [20070530 21:44]:
I'm not subscribed to the list, so please Cc: me on replies.
When building clamav-0.90.2-20070413.src.rpm on Debian sarge on
x86 with OpenPKG-current from today I got the following error:
/kolab/bin/cc -O2 -pipe -o clamscan output.o getopt.o cfgparser.o misc.o
options.o clamscan.o others.o manager.o treewalk.o -L/kolab/lib
../libclamav/.libs/libclamav.a -liconv -lbz2 /kolab/lib/libgmp.a
/kolab/lib/libcurl.a -lz -lssl -lcrypto -ldl -lnsl -lpthread
output.o: In function `logg':
output.c:(.text+0x1c8): undefined reference to `libintl_gettext'
output.c:(.text+0x2ca): undefined reference to `libintl_gettext'
output.c:(.text+0x31c): undefined reference to `libintl_gettext'
Ah, I just saw that I had the same problem a while ago with an
OpenPKG 2.5 based installation, see my mail on this list:
[EMAIL PROTECTED]
My proposed solution there was:
--- clamav.spec.orig2007-02-14 06:54:23.0 +0100
+++ clamav.spec 2007-02-14 17:54:29.0 +0100
@@ -84,6 +84,7 @@
CFLAGS=%{l_cflags -O} \
CPPFLAGS=%{l_cppflags} \
LDFLAGS=%{l_ldflags} \
+LIBS=-lintl -liconv \
GREP=grep \
./configure \
--prefix=%{l_prefix} \
Seems as if -lintl isn't added automatically (while -liconv is),
adding LIBS=-lintl solves (or works around) the problem.
Thanks for reporting. I've now also fixed it, but at the root: the
ClamAV people hard-coded gettext (libintl) usage on Linux. Please
retry with the latest version as of today.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: spamassassin-3.2.0-20070515 compile problem
On Wed, May 30, 2007, Thomas Arendsen Hein wrote: I'm not subscribed to the list, so please Cc: me on replies. When building spamassassin-3.2.0-20070515.src.rpm on Debian sarge on x86 with OpenPKG-current from today I got the following error: /kolab/bin/make -f spamc/Makefile spamc/spamc /kolab/bin/gcc -O2 -pipe spamc/spamc.c spamc/getopt.c spamc/libspamc.c spamc/utils.c \ -o spamc/spamc -L/kolab/lib -ldl -lz -L/kolab/lib -L/kolab/lib -lfsl -lnsl spamc/libspamc.c: In function '_zlib_compress': spamc/libspamc.c:1029: error: 'z_stream' undeclared (first use in this function) spamc/libspamc.c:1029: error: (Each undeclared identifier is reported only once spamc/libspamc.c:1029: error: for each function it appears in.) spamc/libspamc.c:1029: error: expected ';' before 'strm' spamc/libspamc.c:1042: error: 'strm' undeclared (first use in this function) spamc/libspamc.c:1042: error: 'Z_NULL' undeclared (first use in this function) spamc/libspamc.c:1046: error: 'Z_OK' undeclared (first use in this function) spamc/libspamc.c:1057: error: 'Z_FINISH' undeclared (first use in this function) spamc/libspamc.c:1058: error: 'Z_STREAM_ERROR' undeclared (first use in this function) make[1]: *** [spamc/spamc] Error 1 make: *** [spamc/spamc] Error 2 error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.77327 (%build) Althought it built just fine on our Debian 3.1 box rm2.openpkg.net I nevertheless see the root of the problem. There is no -I/kolab/include on the gcc command line. Don't know why it works for me, but perhaps my vendor zlib is newer than your one. Anyway, I've tried to fix it the blind way. Please now retry with the latest spamassassin package as of today. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/bzip2/ bzip2.spec openpkg-src/db/ db.spec o...
On Sun, May 06, 2007, Christoph Schug wrote:
On Sat, May 05, 2007, Ralf S. Engelschall wrote:
On Sat, May 05, 2007, Christoph Schug wrote:
sparc64-freebsd platform fixes
Christoph, as it seems to be a generic PIC issue, wouldn't it be more
reasonable to fixate to PIC building directly via rpmtool as we are
already doing for amd64-freebsd? Because I'm sure these are not the only
libraries which are affected...
Yeah, I had a similar idea but wasn't aware of the rpmtool(8) hack. I'm
not completely satisfied with the way it is done in rpmtool(8) also
as '-fPIC' is being set always, even if not necessary. While vendor
compiler on FreeBSD is always gcc(1) there might be other platforms in
the future were this isn't the case. Wouldn't it be better to introduce
an additional macro which defaults to '%nil' and expands to '-fPIC' on
specific cases?
Yes, some specific macro could be useful. Or an option like -l as in
%{l_cflags -l} which tells RPM that compiler flags should be expanded
for use with libraries. The reason why I've done a force PIC at all
under amd64-freebsd was because (as you noticed) GCC is present anyway
_AND_ especially because one cannot easily distinguish when it is
necessary. And even on platforms where GCC is not always present we
could add an if cascade to rpmtool for the various compilers. But
this is at least still better than a case construct in dozend of
packages...
Nevertheless I consider this commit as a quick hackish solution just to
get a step forword and to evaluate whether sparc64-freebsd might be a
suitable platform for OpenPKG stuff. Sorry for the mess, should I back
out the change?
I personally would prefer to back it out and instead add a similar hack
for sparc64-freebsd as we already have for amd64-freebsd to rpmtool.
This way you also can proceed under sparc64-freebsd but without having
to touch dozend of packages.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/bzip2/ bzip2.spec openpkg-src/db/ db.spec o...
On Mon, May 07, 2007, Christoph Schug wrote: On Sun, May 06, 2007, Ralf S. Engelschall wrote: I personally would prefer to back it out and instead add a similar hack for sparc64-freebsd as we already have for amd64-freebsd to rpmtool. This way you also can proceed under sparc64-freebsd but without having to touch dozend of packages. Okay, done. Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/bzip2/ bzip2.spec openpkg-src/db/ db.spec o...
On Mon, May 07, 2007, Christoph Schug wrote: move over sparc64-freebsd fixes to a more general form within rpmtool(8) Thanks, Christoph. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CONTRIB] ACCEPT: qdbm.diff
On Wed, Mar 28, 2007, OpenPKG Project Robot wrote: The following OpenPKG Contribution Area operation occurred. uploaded DIFF file qdbm.diff accepted -- moved to contrib area. No action is required on your part. Committed. Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: [CVS] OpenPKG: openpkg-src/qdbm/ qdbm.spec
On Thu, Mar 29, 2007, Christoph Schug wrote:
+%if %{with_cxx} == yes
+BuildPreReq: gcc::with_cxx = yes
+%endif
Oh, good catch. Thanks.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
