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: 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
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: 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: [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: 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: 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: bison.diff
On Mon, Feb 23, 2009, OpenPKG Project Robot wrote:
> The following OpenPKG Contribution Area operation occurred.
> uploaded DIFF file "bison.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: 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: 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 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: 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: anubis.diff
On Mon, Dec 22, 2008, OpenPKG Project Robot wrote:
> The following OpenPKG Contribution Area operation occurred.
> uploaded DIFF file "anubis.diff" accepted -- moved to contrib area.
> No action is required on your part.
Applied. 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-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 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. The problem seems to be not the "python" package, but the "readline" package. GNU readline requires a system termcap. Ncurses just also provides this API and hence solves the problem. But the main point is that OpenPKG always required that the OS provides the termcap API: either natively or in case of Linux with the ncurses-dev OS package. That is the reason why OpenPKG always requires "ncurses-dev" under Linux, because there is no "native" termcap for Linux. Just always using OpenPKG's own "ncurses" was not possible because of package dependencies and cross-Class-dependencies. Now that our "ncurses" already became CORE Class this might be different... 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: 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: 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: 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: 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: 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: 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: 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: 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 2>&1 | 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, 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: [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: 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: 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: [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: [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: 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=1&order=dateopened&sort=desc&order2=&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: 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, 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=1&order=dateopened&sort=desc&order2=&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: [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, 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/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, 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/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: [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: 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: 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 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: [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: [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: 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 > > | [...] > > > > 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
| [...]
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-dev&m=118579674004043&w=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: | #!/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
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 > > /include or /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: /include/foo-1.2.3/ or /var/run/ as many upstream authors prefer, or /share/man/ and /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 " to "#include " 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: 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-dev&m=117147128624622&w=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 /include or /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: [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: 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: 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:
> On Thu, Jul 05, 2007, Ralf S. Engelschall wrote:
>
> > 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?
>
> Had similar problem, too. Nevertheless, this is not related to swig
> 1.3.31, it also happens to 1.3.29 when you try to compile it on the
> same environment. The error message itself is misleading, since the
> error is triggered several lines above in the configure script. For me,
> it looks more like a bug of the shell since I haven't found any syntax
> errors (correct me if I'm wrong). In your case your shell most likely
> misinterprets the hash signs in following snippet as comment, leaving
> the backticks unbalanced. The next backtick is down in the Ruby section,
> thus resulting in the error you see above.
>
> snippet from ./configure
> [...]
> | if test -n "$MZSCHEME"; then
> | echo "$as_me:$LINENO: checking for MzScheme dynext object" >&5
> | echo $ECHO_N "checking for MzScheme dynext object... $ECHO_C" >&6
> | MZDYNOBJ=`$MZSCHEME --mute-banner --version --eval '(begin (require (lib
> "link.ss" "dynext")) (with-handlers (((lambda args #t) (lambda args #f)))
> (for-each (lambda (x) (display x) (display " "))
> ((current-make-standard-link-libraries (with-handlers (((lambda args #t)
> (lambda args #f))) (for-each (lambda (x) (display x) (display " "))
> (expand-for-link-variant (current-standard-link-libraries)'`
> | echo "$as_me:$LINENO: result: $MZDYNOBJ" >&5
> | echo "${ECHO_T}$MZDYNOBJ" >&6
> | fi
> [...]
>
> Til now, I wasn't able to hunt down the root cause, but I'm sure it
> hasn't anything to do with swig itself. Looks more like a bug in bash to
> me. In my environment (and several others I've got at hand) it builds
> like a charm. I already played around with several patch levels of GNU
> bash, but as mentioned, I wasn't able to nail down the root cause yet.
Good catch. Yes, seems like this LISP/Scheme stuff is the problem. Ok,
I've applied some bandage for this problem by just patching out this
line as it should be not relevant for us anyway.
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: pb with members list ?
On Tue, Jul 03, 2007, Olivier Kaloudoff wrote:
> tried to post my first message in members tonight ... but fails ..
> I've checked the addresse 3 times :-) .. temporary problem ?
No, just without the "openpkg-" prefix, please.
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///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
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
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: 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: 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 02, 2007, Anders F Björklund wrote:
> > With those two issues patched, it then bootstrapped just
> > fine on Mac OS X 10.4.9 (tested on PowerPC and on Intel)
> [...]
> > Now onwards to test some actual packages, but it looks good.
> > Will let you know if I find anything else, or just ask...
>
> Tested building some packages now, and that's where the
> troubles begin. :-) There needs to be some major changes:
>
> 1) by default it tries to use GNU binutils. These don't
> work on Mac OS X, so it fails already there (in "ar")
> This needs to be changed into using Apple's cctools,
> probably by using the MOF "odcctools-622.3" version.
Ok, binutils now builds and the (remaining) tools seem to work.
strip(1), ar(1), ranlib(1), as(1) and ld(1) have to be left out. But
this doesn't hurt.
> 2) by default it tries to use GNU/FSF gcc. This is not
> 100% binary compatible with Apple's gcc as far as I
> know and might lead to some subtle libgcc/libstdc++
> problems later on ? So will switch, to "gcc-5363".
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
| rm -f ./libgcov.a
| ar rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o
libgcc/./_gcov_merge_single.o libgcc/./_gcov_merge_delta.o
libgcc/./_gcov_fork.o libgcc/./_gcov_execl.o libgcc/./_gcov_execlp.o
libgcc/./_gcov_execle.o libgcc/./_gcov_execv.o libgcc/./_gcov_execvp.o
libgcc/./_gcov_execve.o libgcc/./_gcov_interval_profiler.o
libgcc/./_gcov_pow2_profiler.o libgcc/./_gcov_one_value_profiler.o
| ranlib -c ./libgcov.a
| echo timestamp > stmp-multilib
| # 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
| 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?
Was anybody already successful in building a stock GCC 4.2.0 under Mac OS X?
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: Mac OS X: OpenSSL again
On Wed, Jun 06, 2007, Anders F Björklund wrote: > >> This can be provided by "openpkg-import". > > > > Will do that, then: use openpkg-import to replace "binutils" and "gcc". > > > > One little problem is that the binutils and cctools differ in content, so > > the following programs are missing: addr2line, objcopy, objdump, readelf > > I fixed the missing symlink target with ignoring the return code: > http://www.algonet.se/~afb/openpkg/openpkg-import.diff Ok, now fixed, too. > However, this still did not work because OpenPKG will fail to locate > the real compiler e.g. i686-apple-darwin8-gcc-4.0.1 (from /usr/bin), > but only find the "gcc-4.0" driver front-end... (symlinked from cc) > So either I need to bring some more symlinks in, or do it differently ? This I do not understand: what _IS_ /usr/bin/gcc under MacOS? Is is a strange wrapper script which is unable to find its backends when called via a symlink? Ok, let's try a different approach: in the latest "openpkg-import" I've now replaced the symlinks with wrapper scripts which directly _exec_ the /usr/bin/gcc. Perhaps this works better. 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 /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: 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: 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
