Re: Shared Libraries
Am Donnerstag 15 September 2005 08:01 schrieb Michael van Elst: Hi Michael, > On Thu, Sep 15, 2005 at 03:04:31AM +0200, Martin Konold wrote: > > My personal main issue with the static linking is that in case I am > > developing a package for OpenPKG I have a _very_ hard time to make > > _certain_ that the correct libraries get picked up during compile time. > > With dynamic linking you have the same problem and additionally you > have it when you run the program. Yes, but I can easily detect the problem and therefor deal with bug reports much better. Actually to me the static linking is the biggest obstacle to OpenPKG. The problematic debugging with static linking has lead to me having spent many useless hours and to users loosing data. (Linking to wrong version of libdb :-() and no reliable way for to detect the problem reliably. Regards, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Shared Libraries
Am Dienstag 13 September 2005 12:28 schrieb Ralf S. Engelschall: > These are mainly the two major issues AFAIK which trigger the requests > for shared libraries. My personal main issue with the static linking is that in case I am developing a package for OpenPKG I have a _very_ hard time to make _certain_ that the correct libraries get picked up during compile time. With shared libraries I can easily verify this with ldd but it is very hard to do this with static linking. E.g. a package might build cleanly on my development machine but picks up the wrong version of berkley db on another host. Such things lead to ugly bug reports... Yours, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
problems with the OpenPKG build process
Hi, Sofar several times we got hit by the very same OpenPKG specific issue of lack of separation of the system libraries and the OpenPKG environment. An illustration: When compiling php from OpenPKG 2.2 the resulting binary is linked to the _system _ library libgcrypt dynamically. (This is new behavior in 2.2 and was not present before) Later when compiling Apache I noticed that Apache fails to build due to availability of libgcrypt. After removing the system / vendor provided libgcrypt library Apache built happily but I broke unknowingly php. IMHO the current / long standing decision about how to deal with libraries within OpenPKG needs rediscussion. I have the strong impression that the current solution is not optimal. E.g. reconsidering a LD_LIBRARY type approach can be discussed. Bug like https://intevation.de/roundup/kolab/msg3293 really hurt us in the long run as it looks like side effects between upgrades are unpredictable. With purely shared libraries checking which libs actually got really compiled in the resulting binary is trivial while static linking needs much more difficult analyses before being able to figure out what is actually happening. Yours, -- martin "I am committed to helping Ohio deliver its electoral votes to the President next year." -- Wally O'Dell - CEO of Diebold, Inc. e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: [Kolab] CVS work restarted
Am Donnerstag, 1. April 2004 13:19 schrieb Thomas Lotterer: Hi Thomas, > track with OpenPKG. Having that said I hope you will try minimize local > changes and try hard to push them down to zero. This was always a goal with Kolab but sometimes we don't feel 100% comfortable and are not fully sure that a change we need for Kolab is implemented generic enough so that it does not hurt in other use cases. > on a OpenPKG *release* rathen than a collection of CURRENT or local > modified packages. It would be nice for the Kolab community if the Kolab > activities within ZfOS will finally reduce to a storage for binaries or > even less. This would be really nice but I am not sure if it is feasable. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: [Kolab] CVS work restarted
Am Donnerstag, 1. April 2004 13:19 schrieb Thomas Lotterer: Hi Thomas, > track with OpenPKG. Having that said I hope you will try minimize local > changes and try hard to push them down to zero. This was always a goal with Kolab but sometimes we don't feel 100% comfortable and are not fully sure that a change we need for Kolab is implemented generic enough so that it does not hurt in other use cases. > on a OpenPKG *release* rathen than a collection of CURRENT or local > modified packages. It would be nice for the Kolab community if the Kolab > activities within ZfOS will finally reduce to a storage for binaries or > even less. This would be really nice but I am not sure if it is feasable. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Bootstrap of 1.3.1 on plain Debian 3.0 (supported platform) fails
Am Sunday 05 October 2003 01:00 pm schrieb Ralf S. Engelschall: Hi Ralf, thanks for helping to track down the problem. > > uudeview openpkg-1.3.1-1.3.1.src.sh > > That's interesting. This then has to mean that perhaps you have CR-LFs in > your .src.sh file or such differences which the /usr/bin/uudecode dislikes. > This has to mean your MD5 checksum already has to be different, too. > | $ openssl md5 ../openpkg-1.3.1-1.3.1.src.sh > | MD5(../openpkg-1.3.1-1.3.1.src.sh)= 99fccd6073d06689351e17e432d60c98 > | [EMAIL PROTECTED]:/tmp/x Explicit ascii mode transfer using ftp: 99fccd6073d06689351e17e432d60c98 openpkg-1.3.1-1.3.1.src.sh Works! Explicit binary mode transfer using ftp: 99fccd6073d06689351e17e432d60c98 openpkg-1.3.1-1.3.1.src.sh Works! Explicit ascii mode transfer using ncftp: 90bceeaa04cbbda92ef7b5e4c91087bd openpkg-1.3.1-1.3.1.src.sh Failure! Explicit binary mode transfer using ncftp: 351f1e220b0e9131cfbbc6faa95486da openpkg-1.3.1-1.3.1.src.sh Failure! Now try again to retrieve the file via binary mode transfer using ncftp: 7fba76d19c80b006030664468e4b0ca8 openpkg-1.3.1-1.3.1.src.sh Failure! (Yet another different md5sum!) ncftp --version NcFTP 3.1.3 (Mar 27, 2002) by Mike Gleason ([EMAIL PROTECTED]). So it looks to me like ncftp as provided by Debian woody is the culprit. I did not expect this to happen. Can anyone confirm this problem using ncftp from Debian 3.0? > OpenPKG-CURRENT now (see http://cvs.openpkg.org/chngview?cn=12611 for > details). I like these changes! Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Bootstrap of 1.3.1 on plain Debian 3.0 (supported platform) fails
Hi, I tried to bootstrap from source on a plain Debian woody (3.0) installation. When following exactly the manual it fails with: max:~# sh ./openpkg-1.3.1-1.3.1.src.sh --prefix=/kolab --user=kolab --group=kolab ./openpkg-1.3.1-1.3.1.src.sh: extracting to openpkg-1.3.1-1.3.1.src... ./openpkg-1.3.1-1.3.1.src.sh: extraction done. ./openpkg-1.3.1-1.3.1.src.sh: building for /kolab... ./openpkg.boot: ./openpkg.boot: No such file or directory This is the result of a failing uudecode. When using uudecode manually I get: max:~# tar tvf openpkg-1.3.1-1.3.1.src.tar.Z -rw-r--r-- rse/wheel 6214 2003-09-25 14:13:46 HISTORY -rw-r--r-- rse/wheel 8583 2003-09-25 14:13:46 README -rw-r--r-- rse/wheel 3805 2003-09-25 14:13:46 aux.prereq.sh -rw-r--r-- rse/wheel 6840 2003-09-25 14:13:46 aux.usrgrp.sh -rw-r--r-- rse/wheel 3795 2003-09-25 14:13:46 aux.wrapbin.sh -rw-r--r-- rse/wheel 3520 2003-09-25 14:13:46 aux.wrapsrc.sh -rw-r--r-- rse/wheel 1956216 2003-09-25 14:13:46 bash-2.05b.tar.gz tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Error exit delayed from previous errors The above problem looks to me like the openpkg bootstrap shell script is not compatible to the Debian uudecode utility. When invoking the uudeview utility manually I can successfully unpack/decode the archive from the shell script. uudeview openpkg-1.3.1-1.3.1.src.sh The resulting openpkg-1.3.1-1.3.1.src.tar.Z is actually missleading. The file is actually not a compressed file but a plain tar archive. If I remember correctly it was decided during the 1.3 development not to depend on the compress utility anymore. In addition I would like to know what you think about replacing uudecode with uudeview -i in the bootstrap shell script. At least for me this helped on Debian 3.0 and SuSE 8.2. Last but not least I would love to see the bootstrap script to check for all required prerequisites (required utilities) instead of failing "silently" or giving missleading error messages. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
missleading guest account on rt.openpkg.org
Hi, when people are entering the rt web interface they are offered to login as guest user. Later they are offered to enter a new ticket only to be confronted with an error after making the bug report. IMHO if anonymous users shall not be able to enter bug reports then guest users shall not get the "new ticket" menu entry. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
openpkg.src.sh should check for dependencies or at least fail
Hi OpenPKG team, the Kolab team just released the Kolab server which is heavily based on your OpenPKG efforts. So now people more and more bug reports are coming in ;-) = Fom: Bernhard Erdmann <[EMAIL PROTECTED]> To: Kolab Server and KDE Client development issues <[EMAIL PROTECTED]> Hi, openpkg-20030606-20030606.src.sh tries to execute uudecode without testing its existance or checking its return code: # extract the tarball echo "$me: extracting to $dir..." uudecode $me rm -rf $dir >/dev/null 2>&1 mkdir $dir || exit 1 As uudecode (part of sharutils) is not installed on each and every system, this line should read at least: uudecode $me || exit 1 Regrds, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: apache, openldap, and sasl dependencies
Am Dienstag, 24. Juni 2003 18:45 schrieb Michael van Elst: Hi, > On Tue, Jun 24, 2003, Bill Campbell wrote: > > There seems to be a dependency problem between apache, openldap, and > > sasl. Openldap has an option to use sasl, but the > This looks like nonsense. Why would mod_php_openldap use sasl libraries > and not depend on them ? I was always wondering why it shall make sense to let openldap depend on sasl? Of course it makes often sense that sasl depends on openldap. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: imapd broken with gcc 3.3.
Am Dienstag, 17. Juni 2003 07:01 schrieb Martin Konold:
Hi,
> When trying to build imapd you get
>
> In file included from com_err.c:54:
> /kolab/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/varargs.h:4:2: #error "GCC
> no longer implements ."
> /kolab/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/varargs.h:5:2: #error
> "Revise your code to use ."
This simple patch did help to work around the problem for me. Shouldn't
HAVE_STDARG_H been defined somewhere else?
[EMAIL PROTECTED] diff -u imapd.spec.orig imapd.spec
--- imapd.spec.orig Tue Jun 17 07:16:06 2003
+++ imapd.spec Tue Jun 17 07:16:23 2003
@@ -117,7 +117,7 @@
%endif
%build
-cflags="%{l_cppflags}"
+cflags="%{l_cppflags} -D HAVE_STDARG_H"
ldflags="%{l_ldflags} `%{l_prefix}/bin/fsl-config --all --ldflags`"
case "%{l_target}" in
*-solaris* ) ldflags="$ldflags -lsocket -lnsl" ;;
Yours,
-- martin
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
Re: imapd broken with gcc 3.3.
Am Montag, 16. Juni 2003 20:48 schrieb Michael van Elst: Hi Michael,. > > it looks like cyrus imapd has not been ported to gcc 3.3 sofar. > > Can you be more specific ? When trying to build imapd you get In file included from com_err.c:54: /kolab/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/varargs.h:4:2: #error "GCC no longer implements ." /kolab/lib/gcc-lib/i686-pc-linux-gnu/3.3/include/varargs.h:5:2: #error "Revise your code to use ." com_err.c:88: error: parse error before "va_list" com_err.c: In function `default_com_err_proc': com_err.c:100: error: `whoami' undeclared (first use in this function) with gcc-3.3 -- -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
imapd broken with gcc 3.3.
Hi, it looks like cyrus imapd has not been ported to gcc 3.3 sofar. Is anyone already looking into this? Yours, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Docs in openpkg
Am Mittwoch, 26. Februar 2003 19:06 schrieb Andrews, Martin: Hi, > Hear hear. I am struggling with sasl and imapd and was just about to ask > the same question. You might check the kroupware cvs. There we solved the sasl imapd issues of OpenPKG. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany fon: 0711 67400963, fax: 0711 67400959 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
OpenPKG and static linking
Hi, as you probably noticed we are builing the kolab groupware server on top of OpenPKG. During the development we gained the experience that the static linking approach causes multiple problems while not granting any significant advantages. o the resulting binaries are still not portable between different versions of the OS due to the fact that not all libraries are static. o it often happens that packages pick up the libraries provided by the host OS instead of the OpenPKG counterparts during build because the standard configure scripts are satisified with finding the required libs in standard places (like /lib or /usr/lib). oo modifiying the configure stuff is a maintainance nightmare and violates the minimal impact philosophy. oo it is rather difficult to detect if the wrong library or the wrong header was used during build when looking at the final binaries. The simple ldd approach usable for shared libraries fails here. oo When doing the recommended build from source the resulting binaries differ depending on many factors. This is a big maintainane problem for us because we can not easily help people on mailing lists in this case and only get useless bug reports. I therefor want to propose to drop the static building approach in OpenPKG. In the end it looks like there is more to loose than to win with static linking. All platforms which are supported by OpenPKG and also most unsupported platforms have in the meantime decent support for shared libraries. Regards, -- martin Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Nobelstrasse 15, 70569 Stuttgart, Germany mobil: 0175 4148693 fax: 0175 13 4148693 email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: OpenPKG on IRIX
On Saturday 02 November 2002 11:23 am, Ralf S. Engelschall wrote: Hi Ralf, > general RPM bug. But we're currently in the process of upgrading to RPM > 4.1, we will not further debug RPM 4.0.4 for those new platforms. But Do you intend to merge some of the changes I proposed for portability to IBM AIX into RPM 4.1? What about dumping the dependency on the patented lzw compress utility? Yours, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Patch for imapd.spec
On Monday 28 October 2002 05:29 pm, Martin Konold wrote: > Here a patch for imapd.spec in order to get /etc/imapd.group, sieve and the > perl utils working correctly. > -Patch1: imapd-db4.patch > +Patch1: imapd-db4.patch I just figured out the the db4 patch as provided in the openpkg package does not work and I therefor went back to db3. Regards, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Patch for imapd.spec
-f -p -m 755 \
$RPM_BUILD_ROOT%{l_prefix}/etc/imapd \
$RPM_BUILD_ROOT%{l_prefix}/var/imapd \
-$RPM_BUILD_ROOT%{l_prefix}/var/spool
+$RPM_BUILD_ROOT%{l_prefix}/var/spool \
+ $RPM_BUILD_ROOT%{l_prefix}/var/spool/imap/sieve
# offer a sane configuration
cp master/conf/small.conf master/conf/cyrus.conf
@@ -129,7 +185,17 @@
%{l_rpmtool} files -v -ofiles -r$RPM_BUILD_ROOT \
%{l_files_std} \
'%config %{l_prefix}/etc/imapd/imapd.conf' \
-'%config %{l_prefix}/etc/imapd/cyrus.conf'
+'%config %{l_prefix}/etc/imapd/cyrus.conf' \
+ '%not %dir %{l_prefix}/lib/perl5' \
+ '%not %dir %{l_prefix}/lib/perl5/*' \
+"%not %dir $installarchlib" \
+"%not %dir $installprivlib" \
+"%not %dir $installsitearch" \
+"%not %dir $installsitelib" \
+"%not %dir $installarchlib/auto" \
+"%not %dir $installprivlib/auto" \
+"%not %dir $installsitearch/auto" \
+"%not %dir $installsitelib/auto"
%files -f files
--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
little patch for cyrus imapd and another one for sieve
Hi,
cyrus imapd is completly independent of unix accounts and therefor does not
depend on /etc/passwd.
I think beeing dependent on /etc/group is not nice either and therefor this
little patch in the attachment.
Also in order to get sieve working correctly the following trivial change is
required:
--- timsieved/lex.c.orig2002-10-04 23:58:36.0 +0200
+++ timsieved/lex.c 2002-10-04 23:59:09.0 +0200
@@ -322,6 +322,7 @@
if (isdigit((unsigned char) ch)) {
lexer_state=LEXER_STATE_NUMBER;
tmpnum = ch -'0';
+break;
}
switch (ch) {
case '(':
Regards,
--martin
--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: [EMAIL PROTECTED]
--- lib/auth_unix.c Thu Oct 10 16:38:26 2002
+++ lib/auth_unix.c Thu Oct 10 17:48:04 2002
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
@@ -143,6 +144,26 @@
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
+
+static struct group* fgetgrnam(const char* name)
+{
+struct group *grp;
+FILE *groupfile;
+
+groupfile = fopen("/etc/imapd.group","r");
+if (!groupfile) groupfile = fopen("/etc/group", "r");
+if (groupfile) {
+ while ((grp = fgetgrent(groupfile))) {
+ if (strcmp(grp->gr_name, name) == 0) {
+ fclose(groupfile);
+ return grp;
+ }
+ }
+}
+if (groupfile) fclose(groupfile);
+return NULL;
+}
+
/*
* Convert 'identifier' into canonical form.
* Returns a pointer to a static buffer containing the canonical form
@@ -185,7 +206,7 @@
*/
if (!strncmp(retbuf, "group:", 6)) {
- grp = getgrnam(retbuf+6);
+ grp = fgetgrnam(retbuf+6);
if (!grp) return 0;
strcpy(retbuf+6, grp->gr_name);
return retbuf;
@@ -228,6 +249,7 @@
struct passwd *pwd;
struct group *grp;
char **mem;
+FILE *groupfile;
identifier = auth_canonifyid(identifier, 0);
if (!identifier) return 0;
@@ -241,20 +263,23 @@
newstate->ngroups = 0;
newstate->group = (char **) 0;
-setgrent();
-while ((grp = getgrent())) {
- for (mem = grp->gr_mem; *mem; mem++) {
- if (!strcmp(*mem, identifier)) break;
- }
-
- if (*mem || (pwd && pwd->pw_gid == grp->gr_gid)) {
- newstate->ngroups++;
- newstate->group = (char **)xrealloc((char *)newstate->group,
- newstate->ngroups * sizeof(char *));
- newstate->group[newstate->ngroups-1] = xstrdup(grp->gr_name);
- }
-}
-endgrent();
+groupfile = fopen("/etc/imapd.group", "r");
+if (!groupfile) groupfile = fopen("/etc/group","r");
+if (groupfile) {
+ while ((grp = fgetgrent(groupfile))) {
+ for (mem = grp->gr_mem; *mem; mem++) {
+if (!strcmp(*mem, identifier)) break;
+ }
+
+ if (*mem || (pwd && pwd->pw_gid == grp->gr_gid)) {
+newstate->ngroups++;
+newstate->group = (char **)xrealloc((char *)newstate->group,
+newstate->ngroups * sizeof(char *));
+newstate->group[newstate->ngroups-1] = xstrdup(grp->gr_name);
+ }
+ }
+ fclose(groupfile);
+}
return newstate;
}
Patch for gdbm.spec and for apach mod_ldap module
Hi,
in order to make the current apache build happy ndbm.h is required.
I am compiling a slightly modified apache with:
rpm -bb apache.spec --define 'with_mod_ssl yes' --define 'with_mod_php yes'
--define 'with_mod_dav yes' --define 'with_mod_auth_ldap yes' --define
'with_mod_php_openldap yes'
and it then complains about:
/kolab/bin/cc -c -I/kolab/include -I../../os/unix -I../../include -DLINUX=22
-DTARGET=\"apache\" -DMOD_SSL=208112 -I/kola
b/RPM/TMP/apache-1.3.27/php-4.2.3
-I/kolab/RPM/TMP/apache-1.3.27/php-4.2.3/main
-I/kolab/RPM/TMP/apache-1.3.27/php-4.2.3/ma
in -I/kolab/RPM/TMP/apache-1.3.27/php-4.2.3/Zend
-I/kolab/RPM/TMP/apache-1.3.27/php-4.2.3/Zend -I/kolab/RPM/TMP/apache-1.3.
27/php-4.2.3/TSRM -I/kolab/RPM/TMP/apache-1.3.27/php-4.2.3/TSRM
-I/kolab/RPM/TMP/apache-1.3.27/php-4.2.3 -I/kolab/include -
DEAPI -DEAPI_MM -DUSE_EXPAT -I../../lib/expat-lite -O `../../apaci`
mod_rewrite.c
In file included from mod_rewrite.c:93:
mod_rewrite.h:133:18: ndbm.h: No such file or directory
gdbm Patch:
--- gdbm.spec.org 2002-10-28 16:04:16.0 +0100
+++ gdbm.spec 2002-10-28 16:04:52.0 +0100
@@ -63,7 +63,7 @@
%install
rm -rf $RPM_BUILD_ROOT
-%{l_make} %{l_mflags} install \
+%{l_make} %{l_mflags} install-compat\
prefix=$RPM_BUILD_ROOT%{l_prefix} \
exec_prefix=$RPM_BUILD_ROOT%{l_prefix} \
BINOWN=`%{l_shtool} echo -e %u` \
Apache mod_auth patch:
--- mod_auth_ldap.moduleSun Oct 13 03:51:05 2002
+++ mod_auth_ldap.moduleSun Oct 13 03:52:10 2002
@@ -8,14 +8,14 @@
# if you installed LDAP headers in an unusual place,
# modify the variable below to specify the ldap libraries, example:
# LDAP_INCLUDES="-I/usr/local/foo/include"
-LDAP_INCLUDES=''
+LDAP_INCLUDES='-I@PREFIX@/include'
# LDAP Libraries ##
# if you installed LDAP stuff in an unusual place,
# modify the variable below to specify the ldap libraries, example:
#LDAP_LIB="-L/usr/foo/lib -lldap -llber"
-LDAP_LIBS=''
+LDAP_LIBS='-L@PREFIX@/lib'
error_occurred=0
--- MakefileSun Oct 13 01:30:17 2002
+++ MakefileSun Oct 13 01:47:12 2002
@@ -24,16 +24,16 @@
CPP=gcc -E
TARGET=httpd
OPTIM=
-SSL_BASE=/usr/local/ssl
+SSL_BASE=@PREFIX@
SSL_BINDIR=$(SSL_BASE)/bin
SSL_INCDIR=$(SSL_BASE)/include
SSL_LIBDIR=$(SSL_BASE)/lib
-SSL_PROGRAM=/usr/local/ssl/bin/openssl
+SSL_PROGRAM=@PREFIX@/bin/openssl
SSL_VERSION=-DMOD_SSL_VERSION=\"2.7.1\"
SSL_CFLAGS= -DSSL_COMPAT -DSSL_USE_SDBM -I$(SSL_INCDIR)
SSL_VENDOR_OBJS=
SSL_VENDOR_OBJS_PIC=
-CFLAGS1= -DLINUX=2 -DMOD_SSL=207101 -I/usr/local/open-ldap/include
-DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED
+CFLAGS1= -DLINUX=2 -DMOD_SSL=207101 -I@PREFIX@/include -DUSE_HSREGEX -DEAPI
-DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED
INCLUDES1=
LIBS_SHLIB=
LDFLAGS1= -L$(SSL_LIBDIR)
@@ -41,7 +41,7 @@
REGLIB=regex/libregex.a
EXPATLIB=lib/expat-lite/libexpat.a
RANLIB=ranlib
-LIBS1= /usr/local/open-ldap/lib/libldap.a /usr/local/open-ldap/lib/liblber.a
-lm -lcrypt -lssl -lcrypto
+LIBS1= @PREFIX@/lib/libsasl2.a @PREFIX@/lib/libldap.a @PREFIX@/lib/liblber.a
-lm -lcrypt -lssl -lcrypto
##
## (End of automatically generated section)
##
BTW: What do you think about adding mod_auth_ldap.tar.gz to the apache rpm?
Regards,
--martin
--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
Re: Litte problem with sasl
On Monday 28 October 2002 02:09 pm, Michael Schloh von Bennewitz wrote: Hi Michael, > ftp://ftp.openpkg.org/current/SRC/sasl-2.1.9-20021028.src.rpm Thanks! > There's your patch. By the way, I think your diff was > backwards (I corrected this in the patch). Which kind of diffs do you prefer? diff -u org new ? > Also, there is no 'with_ldap' > option for SASL. Yes! This was a mistake on my side. Regards, --martin -- -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Litte problem with sasl
On Monday 28 October 2002 01:04 pm, Michael Schloh von Bennewitz wrote: Hi Michael, > I tried reproducing this problem on openpkg-20021002-20021002 FreeBSD 4.7 > STABLE, using sasl-2.1.9-20021022. In my case, the 'ln -s' soft link was > successful with no patching. Can you please tell me which version of > OpenPKG you are using Current version from yesterday on Debian testing. sasl-2.1.7-20021004.src.rpm > (--rebuild or -bb?). I'll try to fix the problem by adding your patch as I used rpm -ba sasl.spec --define 'with_fsl yes' --define 'with_ldap yes' Regards, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
litte problem with sasl
Hi, sasl-2.1.9-20021022 does currently not build due to a trivial problem. Here is the patch: sasl/cyrus-sasl-2.1.9/lib --- Makefile.in 2002-10-27 13:12:43.0 +0100 +++ Makefile.in.org 2002-10-27 13:19:41.0 +0100 @@ -437,7 +437,7 @@ plugin_common.lo: plugin_common.o - ln -fs $(top_builddir)/plugins/plugin_common.lo plugin_common.lo + ln -s $(top_builddir)/plugins/plugin_common.lo plugin_common.lo plugin_common.o: ln -s $(top_builddir)/plugins/plugin_common.o plugin_common.o Regards, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Substitution during install
On Monday 07 October 2002 09:58 pm, Ralf S. Engelschall wrote:
Hi Ralf,
> > Any ideas?
> you this enhanced version:
>
> %{l_shtool} install -c -m 644 \
> -e 's;@@@kolab_prefix@@@;%{l_prefix};g' \
> -e "s;@@@fqdn@@@;`%{l_shtool} echo -e %h%d`;g" \
> kolab.conf
Thank you very much! This helped!
> > P.S.: is there documentation available about the install you are using?
>
> Sorry, can you be more specific here? Are you talking about the
> BuildRoot feature?
I was basically wondering where to find information how to write spec files
for OpenPKG. Looking at your spec files I noticed that they significantly
differ from the stuff documented at http://www.rpm.org/max-rpm/. Most stuff
looks more clean and efficient but it is hard to find documentation on things
like the possible options / syntax of install like above.
Sofar I basically tried to learn via looking at numerious different examples
in 1.1.0.
Yours,
--martin
--
--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
Substitution during install
Hi,
I am trying to learn how to write spec files for OpenPKG. I do have the
impression that your modified rpm-4.x is rather powerful.
I am therefore wondering if the following is possible.
{l_shtool} install -c -m 700 -e \
's;@@@kolab_prefix@@@;%{l_prefix};g;\
s;@@@fqdn@@@;`hostname --fqdn`;g;' kolab.conf
Basically I would love to have @@@fqdn@@@ in the file kolab.conf replaced with
the output of the shell command hostname --fqdn.
With the above line though `hostname --fqdn` does not get evaluated during
installation but is taken literally.
Any ideas?
Regards,
--martin
P.S.: is there documentation available about the install you are using?
--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
Makefile
Hi, I am wondering how Makefile and Makefile.rules are generated in the SRC directory. Any hints? Regards, --martin -- -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Supported platforms
Hi, when bootstrapping on SuSE 8.1 the user gets presented the following message ++ platform: i686-pc-linux-gnu2 (Sorry: not supported) But it looks like the resulting binary runs well on SuSE. (minor the compress and the init.d issues) Can this be change in the next version? Regards, --martin -- -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
OpenPKG on SuSE 8.x
Hi, SuSE decided to become more Linux Standard Bases complient and therefor /sbin/init.d does not exist anymore. (Use /etc/init.d instead) Do you intend to reflect this in the bootstrapping? Regards, --martin -- -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: bootstrapping dependency on compress/uncompress
On Saturday 05 October 2002 12:00 pm, Ralf S. Engelschall wrote: Hi, > No, the bootstrap process just should fallback automatically to gzip > for uncompressing if uncompress is not available. But the compression > should be still done with compress only. Because compress is a smaller > denominator. This is now implemented with openpkg-2002105-2002105 and > higher. Thanks for the hint. I further looked into it and it seems that gzip -d working for uncompression but compress on SuSE is a shell skript which is only presenting a message that compress is depreciated and non funtional. Regards, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
bootstrapping dependency on compress/uncompress
Hi, it looks to me like the OpenPKG source bootstrapping procedure does depend on the availability of the traditional compress/uncompress. It came to my attention that due to patent issues the distribution of these programs is not allowed anymore. Therefore SuSE decided to not ship compress anymore starting with SuSE 8.0. SuSE proposes to use gzip instead of compress. ++ IFS=/ ++ echo '' opt openpkg + d=/opt + '[' '!' -d /opt ']' + d=/opt/openpkg + '[' '!' -d /opt/openpkg ']' + uudecode openpkg-1.1.0-1.1.0.ix86-linux2.4-ope.sh + uncompress uncompress: stdin: not in gzip format + cd /opt/openpkg + tar xf - + rm -f openpkg-1.1.0-1.1.0.ix86-linux2.4-ope.tar.Z konold@alpha:~> rpm -qf `which uncompress` gzip-1.3-311 What do you think? Should in the future gzip be a requirement for bootstrapping OpenPKG? Regards, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: OpenPKG and static linking
On Friday 04 October 2002 04:38 pm, Ralf S. Engelschall wrote: Hi, > Library packages we usually provide only if other packages > require them. But we nevertheless can package gdbm > for completeness reasons, too. You can find it now at > ftp://ftp.openpkg.org/current/SRC/gdbm-1.8.2-20021004.src.rpm Thank you! We use it together with Apache2. We did an alpha release of Apache2 for OpenPKG. (Still some issues with php and other DSO stuff) Are you interested in the spec and configure stuff we did? Basically we are going to release a pre alpha version of the kolab server very soon and will do so on the basis of Openpkg technology incl. fsl etc. Yours, --martin -- -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: OpenPKG and static linking
On Friday 04 October 2002 04:14 pm, Ralf S. Engelschall wrote: Hi Ralf, > But the static linking > in OpenPKG affects only libraries _WITHIN_ OpenPKG, i.e. packages like > zlib or libxml provide only static libs. But it does not mean that we > statically link executables as a whole. They are still build against the > dynamic system libraries, of course. Ok, I see now. (I also reread FAQ 13 http://www.openpkg.org/faq.html) Thanks for clarification. BTW: Do you consider libgdbm to be a system library or do you intend to provide a ligdbm package in the future? > > Is Linux different from other platforms in this respect? > > No, although I do not know exactly the point you wanted to address, > Linux is not different when it comes to shared libraries. Well, there are some issues with regards to libresolv and other things in glibc with regards to static linking. Yours, --martin -- -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
OpenPKG and static linking
Hi, I am wondering with the OpenPKG policy with regards to static linking. E.g. what about libc? Is Linux different from other platforms in this respect? Yours, --martin -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: porting openpkg 1.1.0 to AIX 4.3.3
On Tuesday 17 September 2002 09:26 am, Ralf S. Engelschall wrote: Hi, > On Mon, Sep 16, 2002, [EMAIL PROTECTED] wrote: > > I succeeded to bootstrap openpkg 1.1.0 on IBM AIX 4.3.3. > > So now I am wondering how to contribute back the patch? > > Just post it to [EMAIL PROTECTED] Ok, I had to find out that the bootstrapping (from source and binary) only worked on a single machine due to the fact that uname -m gives the processor id on AIX So maybe too soon to post... I now ported the openpkg rpm to AIX ppc (and ia64 partially). I still have problems though because I need perl for automake/autoconf stuff and I cannot compile perl on AIX using the openpkg gcc properly :-( As soon as I get again access to this machine I will post the issue. BTW: We are basing the kolab server (see: kroupware.kde.org) entirely on openpkg for multiple reasons incl. portability) Regards, -- Dipl.-Phys. Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Germanenstrasse 15, 70563 Stuttgart, Germany email: [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
