Re: OpenPKG-4: problem compiling nail on Solaris 10 x86
On 16.04.10 13:45, Olivier Fournier wrote: Found a solution (source: http://www.mail-archive.com/pld-cvs-com...@lists.pld-linux.org/msg216476.html) Ok, upstream vendor fixes taken over and applied to the latest nail package of OpenPKG. It should now build just fine again against OpenSSL 1.0. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Hints for using OpenPKG 4 under Mac OS X 10.6
An important hint for those of you who want to run OpenPKG under Mac OS X 10.6 (in addition or instead of the similar and also great MacPorts). You can use OpenPKG mostly out-of-the-box except for one particular issue: you need the openpkg-darwin package to replace the plain GNU binutils and GNU gcc packages (as those two do not work out-of-the-box under Mac OS X). The procedure to deploy an OpenPKG instance is: | # initial deployment | $ wget http://openpkg.org/go/download/openpkg.src.sh | $ sh openpkg.src.sh --prefix=/openpkg --tag=openpkg \ | --user=openpkg --group=openpkg | $ sh openpkg-*-*.*-openpkg.sh | $ /openpkg/bin/openpkg build openpkg-darwin | sh | $ /openpkg/bin/openpkg build whatever | sh | | # regular upgrade | $ /openpkg/bin/openpkg build -U -a -H openpkg-darwin | sh The trick is to deploy the openpkg-darwin package (which will virtually Provide binutils and gcc and create symlinks to the system tools) and the -H option on upgrading. That's it. Everything else should just work as expected. At least I'm using OpenPKG this way on my Mac OS X 10.6.3 system now... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: more goofy dependency problems
On 06.04.10 17:51, Doug Henry wrote:
I get a lot of this stuff with openpkg 4, not sure why or what it means...
+ /tools/lin64-testing/lib/openpkg/rpmtool files -v -ofiles
-r/tools/lin64-testing/RPM/TMP/openssl-1.0.0-20100331-buildroot
'%defattr(-,tools,tools)' /tools/lin64-testing '%not %dir
{/tools/lin64-testing,/tools/lin64-testing/*,/tools/lin64-testing/etc/rc.d,/tools/lin64-testing/man/*}'
'%config /tools/lin64-testing/etc/openssl/openssl.cnf'
rpmtool:files: pass 1 (preparation and syntactical expansions)
rpmtool:files: pass 2 (filesystem-based expansions)
rpmtool:files: pass 3 (duplication removal and cleanup)
+ exit 0
Processing files: openssl-1.0.0-20100331
Wrote:
/tools/lin64-testing/RPM/PKG/openssl-1.0.0-20100331.amd64-ubuntu6.06-bsi.rpm
Executing(%clean): env -i /tools/lin64-testing/lib/openpkg/bash --norc
--noprofile --posix -e /tools/lin64-testing/RPM/TMP/rpm-tmp.19048
+ cd /tools/lin64-testing/RPM/TMP
+ cd openssl-1.0.0
+ rm -rf /tools/lin64-testing/RPM/TMP/openssl-1.0.0-20100331-buildroot
Executing(--clean): env -i /tools/lin64-testing/lib/openpkg/bash --norc
--noprofile --posix -e /tools/lin64-testing/RPM/TMP/rpm-tmp.19048
+ cd /tools/lin64-testing/RPM/TMP
+ rm -rf openssl-1.0.0
error: Failed dependencies:
/tools/lin64-testing/lib64 is needed by openssl-1.0.0-20100331
Should be now gone with the latest openssl package.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@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 User Communication List openpkg-users@openpkg.org
Re: Cannot download openpkg-2-20091231
On Tue, Feb 02, 2010, steve muskiewicz wrote: 1. as announced, we have finally frozen the old RPM 4 based OpenPKG 2 CURRENT distribution (OpenPKG 3 actually was the commercial OpenPKG ENTERPRISE variant on which OpenPKG 4 now partly is based) and moved it from ftp://ftp.openpkg.org/current/SRC/ to http://download.openpkg.org/stacks/archive/openpkg-2-20091231/ This is now 100% frozen (no more package updates) and exists as a reference point for those who don't want to upgrade to the new OpenPKG 4. This is not working. The URL will display all of the file listings, however any attempts to fetch files result in a 403 Forbidden error message. How do I go about downloading these files? Ops, sorry for the delay. Issue resolved now. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Introducing OpenPKG 4.x
On Wed, Feb 17, 2010, Wilson Jason wrote: Is there any information you can provide the existing users? Well, since 2010-01-01 the PROMO license allowed everybody to drive OpenPKG without problems. Since 2010-04-01 both COMMUNITY and VALUE licenses are available. See http://www.openpkg.com/go/framework-licensing for more details on the licenses. And sorry for the inconviniences you experienced. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: problems compiling libxml correctly on solaris 10
On Mon, Feb 01, 2010, Doug Henry wrote: I have an interesting problem on my solaris 10 box I thought someone may be able to help with. The libxml package builds and installs but it does not install all the files, since the build doesn't fail it probably makes it difficult to notice this failure during testing. Doing rpm -ql libxml I get the following listing, which is not even close to a complete libxml install. /tools/sparc10/bin/xml2-config /tools/sparc10/bin/xmlcatalog /tools/sparc10/bin/xmllint /tools/sparc10/include/libxml2 /tools/sparc10/include/libxml2/libxml /tools/sparc10/include/libxml2/libxml/SAX.h /tools/sparc10/include/libxml2/libxml/SAX2.h /tools/sparc10/lib/libxml2.a /tools/sparc10/lib/libxml2.la /tools/sparc10/lib/pkgconfig /tools/sparc10/lib/pkgconfig/libxml-2.0.pc /tools/sparc10/lib/xml2Conf.sh /tools/sparc10/man/man1/xml2-config.1 /tools/sparc10/man/man1/xmllint.1 /tools/sparc10/man/man3/libxml.3 /tools/sparc10/share/aclocal /tools/sparc10/share/aclocal/libxml.m4 I did a rpm -bb and checked in the RPM/TMP folder and poked around with the build, if I run make install I notice the following error during install, which I believe somehow causes the other files to not be installed (I don't see this error on my linux box). /bin/bash ../../mkinstalldirs /tools/sparc10/share/doc/libxml2-2.7.6/html ../.././install-sh -c -m 0644 ./*.html ./*.c ./*.xml ./*.xsl ./*.res /tools/ sparc10/share/doc/libxml2-2.7.6/html install: ./*.html does not exist make[3]: [install-data-local] Error 1 (ignored) I noticed the configure/makefile system has a /usr/bin/genhtml program listed, but that executable does not exist on the solaris 10 box, probably has something to do with it. I anyone has any info on what might be causing this problem, please shot me a note. Thanks. Hmmm I've currently no recent Solaris 10 box at hand myself, but the genhtml also does not exist on e.g. FreeBSD and there libxml builds just fine. Can you check for the actual build error, because what you see here is already during installation. There has to be also an error earlier during %build... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: RPM or sh on the production server
On Fri, Feb 26, 2010, Benoît Dubé wrote: I got the following after running the shell script on my dev environment box: | openpkg-4.0.2-20100131.src.sh | | | | The results are the following three files: | | | | openpkg-4.0.2-20100131.src.rpm | | openpkg-4.0.2-20100131.ix86-rhel5.4-openpkg.rpm | | openpkg-4.0.2-20100131.ix86-rhel5.4-openpkg.sh | | | [...] When I read the result for the second and third file generated, it's looks both will do the same job, except one will use RPM and the other a shell script, is it right ? Yes, correct. Independently of which one I run, rpm or sh, on the dev box, can I simply install the OpenPKG Framework Binary RPM Package on my production box to have a complete working environment, or I need to run the sh before followeb by the RPM ? Initially you _CANNOT_ run the .rpm as you don't have RPM available. And once you bootstrapped OpenPKG you have RPM available and from then on you should never use the .sh file again. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: apache-suphp dependency error
On Fri, Feb 26, 2010, Bill Campbell wrote: The apache-suphp package should have arp in BuildPreReq. Fixed. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: OpenPKG-4: why can't I retrieve packages through HTTP?
On Mon, Feb 08, 2010, Olivier Fournier wrote: I am trying to download packages and source packages from different remote HTTP repositories, but it doesn't work as expected... open...@lab$ openpkg -v OpenPKG-CURRENT (4.0.2) open...@lab$ openpkg rpm -Uvh http://download.openpkg.org/packages/current/ source/BASE/adns-1.4-20080101.src.rpm = error: open of http://UID:UID.UID@download.openpkg.org/packages/ current/source/BASE/adns-1.4-20080101.src.rpm failed: No such file or directory but... open...@lab$ openpkg curl http://download.openpkg.org/packages/current/source/ BASE/adns-1.4-20080101.src.rpm = works like a charm Am I missing something / doing something wrong? With previous OpenPKG releases this feature was working as expected... Thanks a lot in advance for your answer, Hmmm... this seems to be related to still existing old Registry related rewriting code in the rpm executable wrapper. I guess you can get rid of it by just performing the openpkg register command and let is create its information. But I'll remove this rewriting code in the next version of the OpenPKG Framework. As a quick workaround, just remove line 37 in prefix/libexec/openpkg/rpm with a text editor. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Bootstraping on x86/solaris 10 fails
On Mon, Mar 08, 2010, Daniel Vergien wrote: I tried to install openpkg like in the tutorial, but it fails: make[3]: Entering directory /tmp/openpkg-4.0.2/rpm-5.1.9/tools' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory /tmp/openpkg-4.0.2/rpm-5.1.9' make: *** [all] Error 2 + exit 2 ./openpkg.boot:ERROR: script returned non-null value -bash-3.00# -bash-3.00# cat /etc/release Solaris 10 5/09 s10x_u7wos_08 X86 Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 30 March 2009 -bash-3.00# The system is a fresh installed zone. The installscript is openpkg-4.0.2-20100131.src.sh This is too less information. What errors occur in the tools directory of RPM? I There has to be more details... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: OpenPKG procedure: test-drive OpenPKG 4 from scratch
On Mon, Jan 18, 2010, Olivier Fournier wrote: here are my results of the test-driving procedure on a fresh installed Debian Lenny. I've done an installation under Debian 5.0 myself recently without problems. Interesting that it caused problems for you. Can someone explain me the following things: - Why does OpenPKG need to be bootstrapped twice in order to get it to work without warnings? It should not. The warnings result because of the wrong ownerships on the files. Why the ownerships are wrong I don't know. Have you specified some strange --user or --group options during bootstrapping? - Why do the permissions of the license file have to be manually adjusted in order to activate a license? It should not require any permission adjustments. There something is broken for you. - Why do so many files belong to root after a fresh installation? Also this is incorrect. There ownerships were not correctly set for you as it seems. I've to check this myself under Debian 5.0 again... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Introducing OpenPKG 4.x
On Mon, Jan 04, 2010, Steeve McCauley wrote: There doesn't seem to be a whole lot of documentation out there that is specific to openpkg-4, correct me if I'm wrong but it seems that the openpkg.org site is still related to the rpm 4.x based distro. Yes, we are still busy with download.openpkg.org. Once everything is done the website will be updated, too. I know I'm not really a high priority as a single home user who runs openpkg to keep his firewall packages up to date regardless of which distro is installed, but I'm a little concerned about what the restrictions on the COMMUNITY license are. I don't mind upgrading packages, but was wondering if this is going to be automatic or if one must be sure to run upgrades frequently to avoid packages going out of date. My main concern is this sttaement, Only those OSS packages listed or newer can be run. Well, COMMUNITY contains the name-version-release information of all packages and runs for about 1-2 months. So, if you manually or automatically (think about a cron(8) job here) upgrade your OpenPKG instances running the COMMUNITY license on a frequent interval of about 2-4 weeks, you are just fine and don't have to do anything manually yourself. The COMMUNITY license technically does actually just check for 90% of your packages, so it is even fine if you have up to 10% custom (not known and hence not listed) packages mixed in or if (for whatever reasons) you can't upgrade some packages. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
OpenPKG procedure: test-drive OpenPKG 4 from scratch
For our reference and your convenience, here is an OpenPKG 4 procedure for test-driving it from scratch: - # download latest OpenPKG framework bootstrap sources curl -LO http://openpkg.org/go/download/openpkg.src.sh # bootstrap OpenPKG instance sh openpkg.src.sh \ --prefix=/openpkg --tag=openpkg \ --user=openpkg --group=openpkg sh openpkg-*-openpkg.sh # build and install Apache and Lynx /openpkg/bin/openpkg build \ -D apache::with_mod_ssl apache lynx | sh # start Apache and test with Lynx /openpkg/bin/openpkg rc apache start /openpkg/bin/lynx https://localhost/ # stop Apache and erase OpenPKG instance /openpkg/bin/openpkg rc apache stop /openpkg/bin/openpkg rpm \ -e `/openpkg/bin/openpkg rpm -qa` - Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
OpenPKG procedure: upgrade from OpenPKG 2/3 to OpenPKG 4
For our reference and your convenience, here is a procedure for upgrading OpenPKG 2 (CURRENT) and OpenPKG 3 (ENTERPRISE) instances to the new OpenPKG 4: - # set prefix of OpenPKG 2/3 instance to upgrade prefix=/openpkg # build and upgrade to the OpenPKG 4 framework # (builds RPM 5 with RPM 4) $prefix/bin/openpkg build \ -r http://download.openpkg.org/stacks/current/source/ openpkg | sh # rebuild RPM database $prefix/bin/openpkg rpm --db-rebuild # remove obsolete package $prefix/bin/openpkg rpm -e openpkg-tools # rebuild and reinstall OpenPKG 4 framework with itself # (builds RPM 5 with RPM 5) $prefix/bin/openpkg build -g -u -q openpkg | sh # rebuild all OpenPKG packages with new RPM 5 based OpenPKG 4 framework rm -rf $prefix/RPM/PKG/* $prefix/bin/openpkg build -ZaKB | sh - Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Introducing OpenPKG 4.x
/openpkg/bin/openpkg build \ -D apache::with_mod_ssl apache lynx | sh # start Apache and test with Lynx /openpkg/bin/openpkg rc apache start /openpkg/bin/lynx https://localhost/ # stop Apache and erase OpenPKG instance /openpkg/bin/openpkg rc apache stop /openpkg/bin/openpkg rpm \ -e `/openpkg/bin/openpkg rpm -qa` UPGRADE FROM OPENPKG 2/3 to OPENPKG 4 -- # set prefix of OpenPKG 2/3 instance to upgrade prefix=/openpkg # build and upgrade to the OpenPKG 4 framework # (builds RPM 5 with RPM 4) $prefix/bin/openpkg build \ -r http://download.openpkg.org/stacks/current/source/ openpkg | sh # rebuild RPM database $prefix/bin/openpkg rpm --db-rebuild # remove obsolete package $prefix/bin/openpkg rpm -e openpkg-tools # rebuild and reinstall OpenPKG 4 framework with itself # (builds RPM 5 with RPM 5) $prefix/bin/openpkg build -g -u -q openpkg | sh # rebuild all OpenPKG packages with new RPM 5 based OpenPKG 4 framework rm -rf $prefix/RPM/PKG/* $prefix/bin/openpkg build -ZaKB | sh - Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: php with mysql build problem
On Fri, Nov 27, 2009, Victor G. Bolshakov wrote: Hello, I try to build latest php (php-5.3.1-20091121.src.rpm) with latest mysql (mysql-5.1.41-20091121.src.rpm) on Solaris 10 and got this: checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... /openpkg/var/mysql/mysql.sock checking for MySQL UNIX socket location... /openpkg/var/mysql/mysql.sock checking for mysql_close in -lmysqlclient... no checking for mysql_error in -lmysqlclient... no end of config.log: configure:59006: checking for mysql_close in -lmysqlclient configure:59025: /openpkg/bin/cc -o conftest -fvisibility=hidden -I/openpkg/include -D_POSIX_PTHREAD_SEMANTICS -R/openpkg/lib/mysql -L/openpkg/lib/mysql -L/openpkg/lib -R/usr/ucblib -L/usr/ucblib -R/openpkg/lib/gcc/sparc-sun-solaris2.10/4.2.4 -L/openpkg/lib/gcc/sparc-sun-solaris2.10/4.2.4 -R/openpkg/lib -L/openpkg/lib conftest.c -lmysqlclient -lz -lpcre -lm -lsocket -lgcc -lxml2 -lz -liconv -lm -lsocket -lnsl 15 /openpkg/lib/mysql/libmysqlclient.a(my_sync.o): In function `my_sync': my_sync.c:(.text+0x1c): undefined reference to `fdatasync' collect2: ld returned 1 exit status configure: failed program was: #line 59014 configure #include confdefs.h /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char mysql_close(); Well, yes, fdatasync(3) is part of librt under Solaris. And PHP seems to not know that it has to link against librt in case of linking against libmysqlclient. We can apply a workaround to the php package, but the error actually is that MySQL does not announce that it requires librt or that PHP does not use mysql_config. Can you show me the output of the following command on your platform: $ /openpkg/bin/mysql_config --libs Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Problem with libxml wget
On Mon, Oct 19, 2009, Alex Huth wrote: I have installed wget and now i must install libxml for using mod_security. The installation of libxml stopped after building libiconv-1.13.1-20090701: charset.alias conflicts with the file from wget-1.12-20090923 I don't want to remove wget for building libxml. Any idea? I now removed the conflict by removing the charset.alias from wget package. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: I/O error
On Fri, Oct 16, 2009, Bill Campbell wrote: On Fri, Oct 16, 2009, Alex Huth wrote: I want to install openpkg in a Virtualbox with FreeBSD as a guest. Bootstrapping the source and intalling the binaries works without any error, but when i want to install the tool chain i get a I/O error. When i try it on a Debian Lenny, i get this, when bootstrapping the src: When building OpenPKG on OS X 10.6 Snow Leopard, I had to replace tar-1.19 with tar-1.20 in the OpenPKG package as it had problems compiling otherwise. If I remember correctly, there were other problems bootstrapping openpkg on OS X 10.5 Leopard with the original version of gcc in xCode, which may have required this originally. After an xCode update, gcc was fixed. Just take the bootstrap from the soon to be released OpenPKG 4.0 from http://download.openpkg.org/framework/testing/source/. It already contains even GNU tar 1.22. Yours, Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-comp module fixes
On Thu, Oct 08, 2009, steve muskiewicz wrote: Looks like the perl-comp package is still pulling a bunch of older module versions, probably due to the fact that the Compress::Zlib and various IO::Compress::* modules seem to have now been rolled into a single distribution called IO::Compress http://search.cpan.org/~pmqs/IO-Compress-2.021/ Can this package be updated so that it uses the newer modules? Sure, now done. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Python-2.6.2 --with=db
On Sun, Oct 04, 2009, Armin B. Resch wrote: The advantage is that you this way can create your own independent distribution for your particular software stack. That's powerful, indeed, perhaps even more compelling when a considerable subset of packages are not hosted by OpenPKG such as closed-source, proprietary. Exactly: this way you can even mix OpenPKG upstream packages (perhaps even fixed to a particular version you want to stay at) and local closed-source packages. I use this myself with a few OpenPKG packages of non-open-source applications (e.g. the commercial FlexeLint). No, we also patch many upstream sources. Not just for packaging issues, but also to fix bugs, too add additional features, etc. But the packaging issues are 95% of the patch reasons, of course. If housekeeping is part of OpenPKG's routine, here might be one for you: Unless Google changes their mind and reinstates their SOAP API (http://googlecode.blogspot.com/2009/08/well-earned-retirement-for-soap-sear ch.html), Net::Google is a candidate for removal from perl-www. Ok, removed. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Python-2.6.2 --with=db
On Sat, Oct 03, 2009, Armin B. Resch wrote: Thanks, guys, for your insights wrt the bsddb module which appears to be deprecated, possibly in part due to the pitfalls you described. I guess one way forward to ameliorate API ugliness was to abstract it behind a separate python package (http://pypi.python.org/pypi/bsddb3/4.8.0). Perhaps, under Oracle's auspices, the Berkeley db release cycle is better managed, too. As a relative OpenPKG newbie, my inquiry is more mundane and general in nature, though, because my use case is this: I have a stack of open source products which I built up using OpenPKG and all its components play nicely together. I periodically update the instance which - thanks to rpm - 'memorizes' the product-specific build options as exposed by the spec file. The plan is to 'snapshot' the product semi-annually or so. But, as this python-bdb issue exemplifies, there are limitations to this approach of build automation, because here we have a situation in which a build of the same package/version/build-option suddenly fails because a dependency changed. So, what should be the proper approach and who takes ownership of the issue? To my mind, the options are: (1) Do nothing - hope for the downstream dependency to fix the issue in a subsequent release or otherwise let the spec file atrophy and the user deal with it (2) Pull the offending package (e.g. db-4.8) from the central repo and revert to the previous version (3) Remove the offending build option (e.g. for python, remove with_db) (4) Morph the build option into a no-op as far as build configuration goes, but print a DISCLAIMER to stdout with instructions on how to remedy the situation (e.g. deprecated - install python-bsddb3) (5) Apply a patch (6) make a snapshot by storing all Source RPM files (*.src.rpm) which you used to created your software stack into a local repository, index them there with openpkg index and deploy your software stacks from there via openpkg build -r url. This way you are independent of our OpenPKG upstream packages (which intentionally are a fast moving target in order to continously track the latest vendor versions). Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Python-2.6.2 --with=db
On Sat, Oct 03, 2009, Armin B. Resch wrote: Thanks for that. Option 6 is not unlike the first one, then. Your suggestion is interesting, though. I do use the -r option against a local mirror, but would have dealt with situations like that by simply adding the offending package to an exclusion list on the build command (after reverting the offending package to the prior state, naturally). What are the benefits of creating a separate repo+index? Run-time dependencies? The advantage is that you this way can create your own independent distribution for your particular software stack. As a general rule, would it be accurate to say that you don't try to patch a package unless it's an OpenPKG-induced build failure (package builds if pulled from the vendor, but not if pulled from the OpenPKG repo)? No, we also patch many upstream sources. Not just for packaging issues, but also to fix bugs, too add additional features, etc. But the packaging issues are 95% of the patch reasons, of course. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Project status/future
On Tue, Sep 22, 2009, Dan wrote: Ralf S. Engelschall wrote: On Mon, Sep 21, 2009, Stefan Palm wrote: 1) After playing around a little with OpenPKG I'm wondering about this projects status. The last (official) release is dated from 2007-12-27, quite a lot of pages at openpkg.org are outdated and the mailings list seem to be rather quiet. All this gave me the impression that this project is about to fade away. Is that correct? No, OpenPKG certainly is not fading away. We were just too busy with other earn-a-living jobs and OpenPKG 4.0 was still not ready until recently. Hence we kept the websites around until we have something new. Now that OpenPKG 4.0 is stable and already working on lots of production servers, it will be officially released soon -- together with a new website. That the last official bootstrap is from 2007-12-27 was intentionally, as this was the last time we updated the old RPM 4 based bootstrap. Since this time we worked on the RPM 5 based one for OpenPKG 4.0. I thought the whole point of closing off access to the code and charging for support was to fund the project. If the userbase has shrunk and the paying subset is too small to generate adequate income, why not open the project back up until it reaches critical mass? OpenPKG _is_ open: you can get anything in source form and you can also use it for free as long as the promotion period is extended by us (PROMO license) or forever if you are willing to regularily upgrade to the latest version (COMMUNITY license). More details will follow soon on the website... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Project status/future
On Mon, Sep 21, 2009, Jeff Johnson wrote: On Sep 21, 2009, at 3:41 PM, Ralf S. Engelschall wrote: No, not worth the effort as even in the days of GNU libtool it is an endless effort when it comes to true cross-platform solutions like OpenPKG. And beside faster updates in case of security issues (because you don't have to rebuild the application) there is no real advantage in practice. The disadvantages (portability issues) fully destroy the advantages. What's the actual engineering issue with dynamic vs static? Is it just that there's too many flavors of dynamic linking? Just curious, not questioning at all. The problem is that (1) building shared libraries is platform-specific, (2) not all Unix platform support path stickyness (like cc -Wl,-R) and (3) OpenPKG is a multi-instance solution. So, first, all packages which are not GNU libtool based would have to be manually teached how to build shared libraries and second, on some platforms we even might need program wrappers which set the LD_LIBRARY_PATH accordingly (as we cannot import the while OpenPKG prefix/lib into the global system library path as OpenPKG supports multiple instances and hance there are multiple prefix/lib directories). And finally, the whole shared library business is not worth the effort at all because the advantages (less disk space, faster updates and sharing code segments in RAM) are either harmless (disk space and code segments) or (in case of faster updates) are less then the disadvantages (mentioned above). Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Project status/future
On Mon, Sep 21, 2009, Stefan Palm wrote: 1) After playing around a little with OpenPKG I'm wondering about this projects status. The last (official) release is dated from 2007-12-27, quite a lot of pages at openpkg.org are outdated and the mailings list seem to be rather quiet. All this gave me the impression that this project is about to fade away. Is that correct? No, OpenPKG certainly is not fading away. We were just too busy with other earn-a-living jobs and OpenPKG 4.0 was still not ready until recently. Hence we kept the websites around until we have something new. Now that OpenPKG 4.0 is stable and already working on lots of production servers, it will be officially released soon -- together with a new website. That the last official bootstrap is from 2007-12-27 was intentionally, as this was the last time we updated the old RPM 4 based bootstrap. Since this time we worked on the RPM 5 based one for OpenPKG 4.0. 2) The FAQ states that someday OpenPKG might support dynamically linked (internal) libs. Are there any news on that? No, not worth the effort as even in the days of GNU libtool it is an endless effort when it comes to true cross-platform solutions like OpenPKG. And beside faster updates in case of security issues (because you don't have to rebuild the application) there is no real advantage in practice. The disadvantages (portability issues) fully destroy the advantages. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Bootstrapping OpenPKG-4.0b81 fails
On Sun, Sep 20, 2009, Jeff Johnson wrote: On Sep 20, 2009, at 9:02 AM, Stefan Palm wrote: Am Samstag, den 19.09.2009, 20:18 +0200 schrieb Ralf S. Engelschall: [...] The NAME_MAX simple is not available under your Solaris 10 as it seems. I've applied a patch for this to 4.0b82 and above now. Fine, looks like your patch worked, I can get beyond this point now. But I'm up to the next error: there's no mkdtemp in Solaris 10 (Sparc) and although configure detected that (according to config.log) it still tries to use it: libtool: link: /usr/sfw/bin/gcc -D_GNU_SOURCE -D_REENTRANT -o rpmdigest rpmdigest.o -L/root/tmp/openpkg-4.0b82/uuid-1.6.2/.libs -L/root/tmp/openpkg-4.0b82/pcre-7.9/.libs -L/root/tmp/openpkg-4.0b82/sqlite-3.6.17/.libs -L/root/tmp/openpkg-4.0b82/beecrypt-4.2.1/.libs -L/root/tmp/openpkg-4.0b82/bzip2-1.0.5/.libs -L/root/tmp/openpkg-4.0b82/popt-1.15/.libs -L/root/tmp/openpkg-4.0b82/popt-1.15 -L/root/tmp/openpkg-4.0b82/zlib-1.2.3 -L/root/tmp/openpkg-4.0b82/bzip2-1.0.5 -L/root/tmp/openpkg-4.0b82/beecrypt-4.2.1 -L/root/tmp/openpkg-4.0b82/openssl-0.9.8k/lib -L/root/tmp/openpkg-4.0b82/sqlite-3.6.17 -L/root/tmp/openpkg-4.0b82/pcre-7.9 -L/root/tmp/openpkg-4.0b82/uuid-1.6.2 ./.libs/librpmio.a ../ misc/.libs/librpmmisc.a -L/root/tmp/openpkg-4.0b82/rpm-5.1.9/db3 -L/ root/tmp/openpkg-4.0b82/rpm-5.1.9/lua -lresolv /root/tmp/ openpkg-4.0b82/uuid-1.6.2/.libs/libuuid.a /root/tmp/openpkg-4.0b82/ pcre-7.9/.libs/libpcreposix.a /root/tmp/openpkg-4.0b82/ pcre-7.9/.libs/libpcre.a -ldl /root/tmp/openpkg-4.0b82/ sqlite-3.6.17/.libs/libsqlite3.a -lcrypto /root/tmp/openpkg-4.0b82/ beecrypt-4.2.1/.libs/libbeecrypt.a /root/tmp/openpkg-4.0b82/ bzip2-1.0.5/.libs/libbz2.a -lz /root/tmp/openpkg-4.0b82/ popt-1.15/.libs/libpopt.a -lrt -lsocket -lnsl -lm Undefined first referenced symbol in file mkdtemp ../misc/.libs/librpmmisc.a (liblua_la-lposix.o) ld: fatal: Symbol referencing errors. No output written to rpmdigest collect2: ld returned 1 exit status make[4]: *** [rpmdigest] Error 1 Hmm, I thought I'd fixed this in rpm. Checking ... yes, there's a misc/mkdtemp.c in cvs head. All that's needed is to put the symbol into -lrpmmisc. Yes, that's the right fix at rpm5.org, Jeff. For OpenPKG I in the meantime will just disable the whole mkdtemp stuff as it is currently not used at all. OpenPKG 4.0b82 and above will have this fixed. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Bootstrapping OpenPKG-4.0b81 fails
On Fri, Sep 18, 2009, Stefan Palm wrote: today I tried to bootstrap openpkg-4.0b81 on Solaris10/Sparc and failed to do so. 1) Building libarchive-2.7.1 failed in the first place, but after adding -D_POSIX_PTHREAD_SEMANTICS to the libarchive CPPFLAGS it builds fine. Ok, applied for 4.0b82 and above now. 2) Now I got stuck building rpm-5.1.9. Within rpmio the build fails with error: /tmp/openpkg-4.0b81/rpm-5.1.9/rpmio /usr/sfw/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -I../db3 -I../db3 -I../lua/local -I../lua/local -I../lua -I../lua -DRPM_VENDOR_OPENPKG -DRPM_OS_SOLARIS=021000 -I/tmp/openpkg-4.0b81/popt-1.15 -I/tmp/openpkg-4.0b81/zlib-1.2.3 -I/tmp/openpkg-4.0b81/bzip2-1.0.5 -I/tmp/openpkg-4.0b81/beecrypt-4.2.1/include -I/tmp/openpkg-4.0b81/openssl-0.9.8k/include -I/tmp/openpkg-4.0b81/sqlite-3.6.17 -I/tmp/openpkg-4.0b81/pcre-7.9 -I/tmp/openpkg-4.0b81/uuid-1.6.2 -D_GNU_SOURCE -D_REENTRANT -MT glob.lo -MD -MP -MF .deps/glob.Tpo -c glob.c -o glob.o glob.c: In function NAME_MAX' undeclared (first use in this function) glob.c:1114: error: (Each undeclared identifier is reported only once glob.c:1114: error: for each function it appears in.) Any ideas what's going on here? The NAME_MAX simple is not available under your Solaris 10 as it seems. I've applied a patch for this to 4.0b82 and above now. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Newbie question for rebuild apache
On Fri, Jul 24, 2009, Alex Huth wrote: sorry for asking maybe simple questions, but after reading the manual and searching the web for hours i can't get a solution. I am at a new job, never used openpkg and have to get a new module into a existing apache asap. Here what i have done so far: 1. openpkg rpm -Uvh apache-2.2.11-20090201.src.rpm 2. rebuild as user admin in apache source tree openpkg rpm --rebuild --enable-layout=GNU --prefix=/adm -- sysconfdir=/adm/etc/apache2 --libexecdir=/adm/libexec/apache2 --with- mpm=prefork --enable-suexec --with-suexec-bin=/adm/sbin/suexec -- with-suexec-caller=admin-n --with-suexec-userdir=public_html --with- suexec-lofile=/adm/var/apache/log/suexec.log --enable-ssl --with- ssl=/adm --enable-proxy --enable-proxy-connect --enable-proxy-http --enable-proxy-ftp --enable-file-cache --enable-so --enable-spelling --enable-rewrite --enable-headers --enable-info --enable-mime-magic --enable-vhost-alias --enable-auth-dbm --disable-shared --disable- threads --with-dbm=db42 --with-berkley-db=/adm --with-expat=/adm -- with-iconv=/adm --enable-deflate apache-2.2.11-20090201.src.rpm --enable-layout=GNU: unknown option Then i have read in the group that i should use build -D instead of rpm -- rebuild. OK, here we go now as root: /adm/bin/openpkg build -D --enable-layout=GNU --prefix=/adm -- sysconfdir=/adm/etc/apache2 --libexecdir=/adm/libexec/apache2 --with- mpm=prefork --enable-suexec --with-suexec-bin=/adm/sbin/suexec -- with-suexec-caller=admin-n --with-suexec-userdir=public_html --with- suexec-lofile=/adm/var/apache/log/suexec.log --enable-ssl --with- ssl=/adm --enable-proxy --enable-proxy-connect --enable-proxy-http --enable-proxy-ftp --enable-file-cache --enable-so --enable-spelling --enable-rewrite --enable-headers --enable-info --enable-mime-magic --enable-vhost-alias --enable-auth-dbm --disable-shared --disable- threads --with-dbm=db42 --with-berkley-db=/adm --with-expat=/adm -- with-iconv=/adm --enable-deflate apache-2.2.11-20090201.src.rpm # operating with OpenPKG instance /adm # operating with OpenPKG RPM /adm/bin/openpkg rpm # fetching XML/RDF index from URL ftp://ftp.openpkg.org/stable/2/00INDEX.rdf # using internal XML/RDF parser openpkg:build:FATAL: an I/O error occured That's now the point where i need the help! How can i get the additional modul into the apache? Where is my failure? Errr your problem simply is that you intermix Apache configure options, openpkg rpm options and openpkg build options. You can't just pass an Apache configure option to the packaging infrastructure. You can only enable with openpkg build -D with_mod_xxx or openpkg rpm --with mod_xxx what the packaging of Apache explicitly supports. openpkg rpm -qpi apache*src.rpm tells you what this is under Provides. For building and installing an Apache with mod_ssl enabled you have to use openpkg build -D with_mod_ssl apache | sh. But if you want to enable a custom module (which the packaging doesn't know) you would first have to extend the packaging. There you cannot expect a simple option to pass... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: squirrelmail, please upgrade compatibility modules
On Sun, May 10, 2009, Alain Spineux wrote: using last openpkg squirrelmail-1.4.17-20090327 package, I got this error [10-May-2009 17:06:11] PHP Fatal error: Cannot redeclare sqauth_save_password() (previously declared in /kolab/share/squi rrelmail/plugins/compatibility/includes/1.5.1/global.php:205) in /kolab/share/squirrelmail/functions/auth.php on line 291 I have upgraded the compatibility module from 2.09 to the last version 2.0.14 and get no more errors. Upgrade now done. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: missing perl dep for Archive::Tar
On Tue, May 05, 2009, steve muskiewicz wrote: The latest Archive::Tar module (1.48) in perl-sys requires the Package::Constants module, which doesn't appear to be provided by any of the perl-* packages in openpkg CURRENT. Can this module be added to whichever perl-* package is appropriate? Ok, Package::Constants now added to perl-util and perl-util now required by perl-sys. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: outdated module in perl-devel
On Thu, May 07, 2009, steve muskiewicz wrote: The Devel::StackTrace module in perl-devel in CURRENT is outdated. Latest version is 1.20, the package still has 1.1902 Ok, module now upgraded. Thanks for the hint. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unrar support in clamav 0.95 and above
On Thu, Apr 09, 2009, Thomas Arendsen Hein wrote: * Thomas Arendsen Hein tho...@intevation.de [20090409 15:31]: With clamav-0.95.1-20090409 and clamav-0.95-20090323 and trying to scan .rar files I get the following warning: LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable No clamav was installed in the base system and I tried with and without a previous clamav package installen in OpenPKG. When compiling without --disable-shared it seems to work, at least 'make check' runs fine now, which did not before. I've now applied a --disable-unrar and additionally disabled the dlopen(3) call for the libclamunrar_iface. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: On Rpm5 (was: gcc 4.3 tar does not build (was: Ubuntu 8.10/Intrepid and openpkg.))
On Tue, Feb 17, 2009, Bernhard Reiter wrote: Am Montag, 16. Februar 2009 20:02:35 schrieb Ralf S. Engelschall: Yes, the new RPM 5 based bootstrap is already based on GNU Tar 1.21 and hence built just fine for me last week on a new Debian 5.0 box. This boostrap will be made available to the public soon, too. Just be patient a little bit more. I saw that you are deeply involved with rpm5(.org). On rpm.org and rpm5.org I could not find statements on the relation of both efforts and why rpm5 would be better than rpm4 in the long run. Do you know such a document comparing the approaches? (Best would be from a neutral point of view, but having the view of both groups would be interesting as well)? Some time ago I wrote a little bit on this topic: http://trainofthoughts.org/blog/2008/01/06/rpm5-vs-rpm/ Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: gcc 4.3 tar does not build (was: Ubuntu 8.10/Intrepid and openpkg.)
On Tue, Feb 17, 2009, Bernhard Reiter wrote: Am Montag, 16. Februar 2009 20:02:35 schrieb Ralf S. Engelschall: Yes, the new RPM 5 based bootstrap is already based on GNU Tar 1.21 and hence built just fine for me last week on a new Debian 5.0 box. This boostrap will be made available to the public soon, too. Just be patient a little bit more. Wouldn't be cool to also have an update to the current RPM4 based bootstrap? I fear upgrading will be a problem with all packages that we use for Kolab Server. What would I need to do to update the current bootstrap for tar 1.21? Would just updating tar 1.21 be enough? [...] I don't know, perhaps. If the older GNU Tar is the only(!) problem under Debian 5.0 it might be sufficient to upgrade just GNU Tar. But it could be also that there are other corners which break under the newer Linux distro versions. The new RPM 5 based bootstrap is suffciently different, so I without trying I cannot say what else has to be touched. I just know that the new RPM 5 based bootstrap worked out-of-the-box under a Debian 5.0 (amd64) server last week... Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: gcc 4.3 tar does not build (was: Ubuntu 8.10/Intrepid and openpkg.)
On Mon, Feb 16, 2009, Bernhard Reiter wrote: On Donnerstag, 13. November 2008, David Stenglein wrote: I wanted to report on my experience installing openpkg on ubuntu 8.10. The main issue was the compiler upgrade to gcc 4.3. I was able to install gcc 4.2 and do a bootstrap by specifying the compiler explicitly. The real issue came when I wanted install other packages after the bootstrap. It doesn't seem easy to override the compiler of all of the various packages, so I had to do a little tweak. I uninstalled gcc4.3 and made a symbolic for gcc and cc and then everything built just fine. OpenPKG does not seem to build the bootstrap on gcc 4.3. One problem reported for Ubunto 8.10 and OpenSuse 11.1 is building tar 1.19. Logs can be found here for example: OpenSuse 11.1: https://www.intevation.de/roundup/kolab/file1046/kolab-install.log Debian Lenny/amd64 https://www.intevation.de/roundup/kolab/msg15671 The tar source comes from within openpkg-20071227-20071227 package. There is a newer tar available 1.21. Yes, the new RPM 5 based bootstrap is already based on GNU Tar 1.21 and hence built just fine for me last week on a new Debian 5.0 box. This boostrap will be made available to the public soon, too. Just be patient a little bit more. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: net-snmp : snmptrapd free() error
On Fri, Feb 13, 2009, Christian Lete wrote: Sorry for the double posting... I found more info regarding the error: I added an extra line in snmptrapd.c to get more information on the pointer: Breakpoint 1, free_config_pidFile () at snmptrapd.c:523 523 if (pid_file) (gdb) n 524 printf(the pid file ptr %p\n,pid_file); (gdb) n the pid file ptr 0x4e9508 525 free(pid_file); (gdb) n *** glibc detected *** /opt/openpkg/sbin/snmptrapd: free(): invalid pointer: 0x004e9508 *** 526 pid_file = /openpkg/var/snmp/snmptrapd.pid; Hope this brings more information. I checked the piece of code and I saw the problem. pid_file is initialized to a non-NULL and non-strdup'ed string by us and this breaks here in case the free(pid_file) is done. I've tried to fix this in the latest snmp package now. Thanks for the hints. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: whoson CURRENT rc.whoson patch
On Mon, Feb 09, 2009, Bill Campbell wrote: The attached patch for the CURRENT version of whoson does four things. It adds %status and %restart sections and modifies the %start and %stop sections to start whoson well in advance of other packages that may use whoson such as postfix, courier-imap, etc. Now taken over. Thanks, Bill. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Building squid on Solaris 10 with large file support
On Mon, Feb 09, 2009, Wilson Jason wrote: Wilson Jason wrote: multilib is disabled by default. Rebuilding now with multilib explicitly enabled and will report how it goes. Building of gcc went fine - now have multilib support. Unfortunately having problems with squid still. When squid is running its configure scripts it is doing compile time tests with a command like: gcc -m64 conftest.c -lfsl The problem is that the libfsl.a library is only 32 bit (or so I presume) as I get errors like: /secomon/openpkg-3/bin/ld: skipping incompatible /secomon/openpkg/lib/libfsl.a when searching for -lfsl I have rebuilt fsl with the new gcc, but doesn't help with the problem - as it defaults to 32bit of course. Do I need to build the whole openpkg system with 64bit support defined for everything, like this article you linked previously talks about? http://marc.info/?l=openpkg-usersm=116072933928495w=2 If so, this is probably more effort then I am prepared to do just to get the largefile support in squid when I have a workable 'hack' to do it with 32bit compiling. The problem is that you cannot mix 32 and 64 objects. If you run OpenPKG's GCC in 64 bit mode you really have to build the _complete_ OpenPKG instance in 64 bit mode. Linking in old libraries (which are still built 32 bit) doesn't work. Sorry, this is a restriction of the platform and cannot be changed by OpenPKG. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Building squid on Solaris 10 with large file support
On Thu, Feb 05, 2009, Wilson Jason wrote: [...] Now, gcc doesn't like this and the Squid configure scripts changes this to '-m64'. Unfortunately gcc doesn't support 64bit builds and any compile returns an error about multilib not being supported, because it isn't. Why does your GCC not support -m64 on your 64-bit platform? PS: For some old hints about OpenPKG and 64 bit see also: http://www.lotterer.net/blog/en/78-openpkg-32bit-vs-64bit http://marc.info/?l=openpkg-usersm=116072933928495w=2 Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Problem building bison on Solaris 10
On Wed, Dec 10, 2008, Victor G. Bolshakov wrote: Problem solved - as i understand CONFIG_SHELL=/bin/sh \ not needed in %build block of bison.spec [...] The question is _why_ this breaks the build on Solaris? It certainly was added for good reasons in the past, so before removing it we have to understand why it breaks now... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openssh CURRENT s
On Fri, Nov 14, 2008, Bill Campbell wrote: The attached patch fixes a syntax error when building the CURRENT openssh-5.1p1-20080730.src.rpm package with the options shown in the attached build.sh file. I have not had time to go through the full %prep section to see where this extra ``}'' is showing up in the source. I've now fixed the sftplogging patch accordingly. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openssh CURRENT watchdog.patch
On Fri, Nov 14, 2008, Bill Campbell wrote: [...] I checked the web site in the track section of the openssh.spec file, and it appears that nothing has been done on this recently so it may be a good idea to drop this from the package. I've forward ported the Watchdog patch and include it in the package itself. This should be fixed now. [...] The openssh package seems to be a bit vulnerable to issues when various combinations of options are specified (e.g. if one turns sftplogging off, it results in a patch failure). Regression testing all combinations of options is a major pain. Yes, the major problem is that each patch itself works just fine now again, but some of them conflict as they patch exactly the same source code pieces. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Maven package problem.
On Thu, Nov 13, 2008, David Stenglein wrote: The mvn/maven.sh seems to be based on the new java infrastructure, but it seems to have a problem. The line at the beginning: export JAVA_PLATFORM=sun-jdk seems to throw things off. Should this just be removed? Sorry, can you be more specific: what do you mean by throw things off? The JAVA_PLATFORM variable just says that the Java has to be a JDK (and not GCJ, etc) because (as I can remember) that Maven didn't work with GCJ. What does break for you? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openmotiv
On Thu, Nov 06, 2008, [EMAIL PROTECTED] wrote: I?ve a problem to build the current openmotiv package under solaris10? is there somebody who knows what it is needed to get it working? thanks for a small feedback? As MOTIF is an X11/Desktop thing and OpenPKG is primarily focused on server-based software, all those X11 packages (including Motif) never were in the focus and hence partly can be broken. This is also reflected by the package Class which usually is never BOOT, CORE or BASE. Usually it is not even PLUS. Intead the X11 packages are usually just EVAL quality. Mostly all X11 based packages in OpenPKG just exist for convenience reasons in case one needs them. But not because they are of any importance for OpenPKG's server-computing focus. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openmotiv
On Thu, Nov 06, 2008, [EMAIL PROTECTED] wrote: Thanks for the feedback, openmotiv is required to compile nedit, therefore it is needed... are there other ways to achieve it... There is also lesstif as a MOTIF alternative. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Java infrastructure revised
On Fri, Oct 31, 2008, David Stenglein wrote: [...] Is there some way we could automate the RPM and grab the sources on the fly like wrapper packages on some of the distributions do? I would be nice to make this process a lot cleaner. I know this could be difficult due to licensing/ click-through. Because of licensing constraints by Sun _WE_ are not allowed to redistribute a complete .src.rpm which includes all files. But _YOU_ can roll your own complete .src.rpm for personal automation purposes, of course. Just unpack the .nosrc.rpm, download all missing files from Sun and then roll the .src.rpm via openpkg rpm -bs --norestriction *.spec and you will end up with a complete .src.rpm which works just fine in full batch/automation processes. I also signed the contributor agreement, so I'd like to update java-jdk16 to u10 and fix a typo in the name of the docs zip. Just send us a diff(1) output here or tell us what has to be changed. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Java infrastructure revised
On Sat, Nov 01, 2008, David Stenglein wrote: Ralf S. Engelschall wrote: On Fri, Oct 31, 2008, David Stenglein wrote: [...] Is there some way we could automate the RPM and grab the sources on the fly like wrapper packages on some of the distributions do? I would be nice to make this process a lot cleaner. I know this could be difficult due to licensing/ click-through. Because of licensing constraints by Sun _WE_ are not allowed to redistribute a complete .src.rpm which includes all files. But _YOU_ can roll your own complete .src.rpm for personal automation purposes, of course. Just unpack the .nosrc.rpm, download all missing files from Sun and then roll the .src.rpm via openpkg rpm -bs --norestriction *.spec and you will end up with a complete .src.rpm which works just fine in full batch/automation processes. I'm not talking about distributing the files, just getting them at install time. Instead of listing them as sources, have the spec do a wget or equivalent of the source for the current platform. This is what I mean by wrapper. It is a very different approach to RPMs than is usually done, though. With the forthcoming (still under testing) RPM 5 based OpenPKG 4 this can be already done. There OpenPKG RPM can automatically download missing SourceX files. For the current released OpenPKG RPM this is only possible through the openpkg dev environment and very nasty to setup. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Java infrastructure revised
On Fri, Oct 31, 2008, David Stenglein wrote: I am having problems building the java-jdk15 and java-jdk16. It seems to want the sources for all platforms due to the %setup macro. What is the procedure for installing java for a single platform? Well, just touch(1) the remaining SourceX files on the filesystem. OpenPKG RPM is happy if the files just exist. Only those who belong to your particular platform have to be real files. The other possibility is to install a JDK totally manually and outside of OpenPKG into /path/to/jdk and then install the java-jdkfake package plus running java-toolkit --register=sun-jdk-fake:/path/to/jdk. This also will satisfy all Java dependencies within OpenPKG. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Problem building daemontools on Centos-4.5
On Tue, Oct 07, 2008, Walter Franzini wrote: Walter Franzini [EMAIL PROTECTED] writes: I'm unable to build daemontools: The patch below (stolen from the debian package) had fixed the problem for me. --- admin/daemontools-0.76/src/error.h.orig 2008-10-07 11:24:00.0 +0200 +++ admin/daemontools-0.76/src/error.h2008-10-07 11:24:12.0 +0200 @@ -3,7 +3,7 @@ #ifndef ERROR_H #define ERROR_H -extern int errno; +#include errno.h extern int error_intr; extern int error_nomem; Ah, ok. This makes sense, of course. Patch now applied. Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Problem building ispell
On Thu, Jul 31, 2008, Artur Frysiak wrote: ispell-3.3.02-20080101 Building igerman98 ispell dictionary ends with error: [...] Adding SHELL=/openpkg/bin/bash to `make` invocation fixes problem. Now added. The problem should be now gone with the latest ispell package released today. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unable to buld FreeRADIUS 2.0.5 under Solaris 10
On Thu, Jul 31, 2008, Victor G. Bolshakov wrote: [...] freeradius with and without openldap not That was because the remaining problem was related to Libtool and not OpenLDAP. I applied a patch which now has resolved the problem for me under Solaris 10. Just retry with the latest freeradius package from today. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unable to buld FreeRADIUS 2.0.5 under Solaris 10
On Thu, Jul 31, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Thu, Jul 31, 2008, Victor G. Bolshakov wrote: [...] freeradius with and without openldap not That was because the remaining problem was related to Libtool and not OpenLDAP. I applied a patch which now has resolved the problem for me under Solaris 10. Just retry with the latest freeradius package from today. 1. Wrong href for freeradius in 00INDEX.rdf.bz2 rdf:Description about=freeradius-2.0.5-20080731 href=00UPLOAD/freeradius-2.0.5-20080731.src.rpm This certainly was just a temporary problem as you were faster than the upload processing procedure picked up and relocated the new source RPM. 2. I'm unable to build latest package... [...] Sure, because you still used the older package version. Retry now. The 00INDEX.rdf.bz2 should be now correct as the uploaded newer package was already relocated to the final location. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unable to buld FreeRADIUS 2.0.5 under Solaris 10
On Thu, Jul 31, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Thu, Jul 31, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Thu, Jul 31, 2008, Victor G. Bolshakov wrote: [...] freeradius with and without openldap not That was because the remaining problem was related to Libtool and not OpenLDAP. I applied a patch which now has resolved the problem for me under Solaris 10. Just retry with the latest freeradius package from today. 1. Wrong href for freeradius in 00INDEX.rdf.bz2 rdf:Description about=freeradius-2.0.5-20080731 href=00UPLOAD/freeradius-2.0.5-20080731.src.rpm This certainly was just a temporary problem as you were faster than the upload processing procedure picked up and relocated the new source RPM. 2. I'm unable to build latest package... [...] Sure, because you still used the older package version. Retry now. The 00INDEX.rdf.bz2 should be now correct as the uploaded newer package was already relocated to the final location. Strange, but i just ftp://ftp.openpkg.org/current/SRC/00INDEX.rdf.bz2 downloaded from ftp and find href=00UPLOAD/freeradius-2.0.5-20080731.src.rpm in it... Ah, there was a problem in processing the file. Now fixed. File should be now updated within the next 15 minutes. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unable to buld FreeRADIUS 2.0.5 under Solaris 10
On Wed, Jul 30, 2008, Victor G. Bolshakov wrote: I`m unable to build FreeRADIUS 2.0.5 under Solaris 10. Buld just stop with checking for gcc... /openpkg/bin/cc checking for C compiler default output file name... configure: error: C compiler cannot create executables Many other packages (apache, mysql, postgresql)compiled and worked without any problems. Any suggestions? See the config.log file in the source tree top-level directory of FreeRADIUS. There is the reason for the problem, usually some libraries cannot be found or a compiler flag is not understood or something like this. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unable to buld FreeRADIUS 2.0.5 under Solaris 10
On Wed, Jul 30, 2008, Victor G. Bolshakov wrote: External dependence for OpenPKG packege? I also try to build without LDAP (with_openldap=no) without any success... [EMAIL PROTECTED] wrote: can you try a ls /usr/lib/liblber*.so ? if the lib is not present, you might need to pkgadd some ldap packages. Sorry, I'm just inattentively looked in to config.log for first time... This is the problem: configure:2314: checking for C compiler default output file name configure:2341: /openpkg/bin/cc -I/openpkg/RPM/TMP/freeradius-server-2.0.5/src/include -O2 -pipe -I/openpkg/include -I/openpkg/include -L/openpkg/lib conftest.c -llber -lssl -lcrypto 5 /openpkg/bin/ld: cannot find -llber collect2: ld returned 1 exit status Yes, liblber is part of OpenLDAP. If with_openldap=no doesn't help then we have to fix something here. But I see already a problem in the packaging: LDAP libraries are passed in LIBS unconditionally. I've tried to fix this with the latest freeradius package. Please retry with this one. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: unable to buld FreeRADIUS 2.0.5 under Solaris 10
On Wed, Jul 30, 2008, Artur Frysiak wrote: Victor G. Bolshakov wrote: I try to build openldap and also without success: /openpkg/bin/cc -O2 -pipe -I/openpkg/include/pth -D_AVL_H -I../../../include -I../../../include -I.. -I./.. -I/openpkg/include -I/openpkg/include/pth -c monitor.c -o monitor.o In file included from ../../../include/ac/signal.h:20, from ../slap.h:38, from ../back-monitor/back-monitor.h:28, from back-ldap.h:27, from monitor.c:33: /usr/include/signal.h:222: error: conflicting types for 'pth_sigwait' /openpkg/include/pth/pth.h:536: error: previous declaration of 'pth_sigwait' was here make[3]: *** [monitor.lo] Error 1 make[2]: *** [.backend] Error 1 make[1]: *** [all-common] Error 1 make: *** [all-common] Error 1 On Solaris 9: /bin/sh ../../..//libtool --tag=disable-shared --mode=compile /openpkg/bin/cc -O2 -pipe -I/openpkg/include/pth -D_AVL_H -I../../../include-I../../../include -I.. -I./.. -I/openpkg/include -I/openpkg/include/pth-c monitor.c /openpkg/bin/cc -O2 -pipe -I/openpkg/include/pth -D_AVL_H -I../../../include -I../../../include -I.. -I./.. -I/openpkg/include -I/openpkg/include/pth -c monitor.c -o monitor.o In file included from ../../../include/ac/signal.h:20, from ../slap.h:38, from ../back-monitor/back-monitor.h:28, from back-ldap.h:27, from monitor.c:33: /openpkg/lib/gcc/sparc-sun-solaris2.9/4.2.4/include/signal.h:218: error: conflicting types for 'pth_sigwait' /openpkg/include/pth/pth.h:536: error: previous declaration of 'pth_sigwait' was here Ok, I applied a workaround. Please retry with the latest openldap package as of this evening. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Fwd: screen / solaris
On Mon, Jul 14, 2008, Dewey Hylton wrote: On Thu, Jul 10, 2008 at 1:37 PM, Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Thu, Jul 10, 2008, Dewey Hylton wrote: hi all, just found openpkg a month ago so i'm pretty green. i like what i see so far! building ncurses fails on solaris10/x86. i found this when attempting to build/ install screen. here is the relevant part of the output: cc --param max-inline-insns-single=1200 -o background ../objects/background.o -I../test -I. -DHAVE_CONFIG_H -I. -I../include -I/openpkg/include -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -DNDEBUG -I/openpkg/include/ncurses --param max-inline-insns-single=1200 `echo -static -L../lib -lform -lmenu -lpanel -lncurses -dynamic | sed -e 's/-lform.*-lpanel[^ ]*//'` -lm ld: fatal: library -lm: not found ld: fatal: library -lc: not found ld: fatal: File processing errors. No output written to background collect2: ld returned 1 exit status make[1]: *** [background] Error 1 make: *** [all] Error 2 where do i go from here? If libc.a and libm.a are not found this means your particular Solaris installation is too less. You need to install the Solaris vendor packages providing those two files, please. neither of these are provided by solaris 10 any longer. is there a way to build this port without those static libraries? from docs.sun.com: In a 64-bit environment, many system libraries are available only as shared dynamic libraries. These include libm.so and libc.so (libm.a and libc.a are not provided). As a result, -Bstatic and -dn may cause linking errors in 64-bit Solaris operating systems. Applications must link with the dynamic libraries in these cases. here's when/why: http://blogs.sun.com/rie/entry/static_linking_where_did_it I checked the ncurses package in detail and there is actually already some patching to get rid of full static building. I've no clue why these patches do not work for you as I still see a -static above in your output. Just to make sure: this is really with the latest ncurses package from OpenPKG CURRENT, i.e., ncurses-5.6.20080713-20080713.src.rpm, right? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Mailman won't start
On Thu, Jul 10, 2008, Mark Berndt wrote: I have a problem with the mailman package not starting with openpkg rc mailman start. If I launch from the command line as root mailmanctl start then the mailmanctl and several python qrunner scripts are visible in the process table. running openpkg rc mailman stop correctly stops the mailmanctl and qrunner processes. Changing rc.mailman to use openpkg-n as the user partially works. The qrunner python scripts are launched by mailmanctl and can be found in the process table, but the mailmanctl program does not remain running. Can anyone assist with this problem? I don't know why you need to change the rc.mailman to use the openpkg-n user, but if the mailmanctl does not run it certainly is related to some file permissions which also would have to be adjusted for the use of openpkg-n. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Fwd: screen / solaris
On Thu, Jul 10, 2008, Dewey Hylton wrote: hi all, just found openpkg a month ago so i'm pretty green. i like what i see so far! building ncurses fails on solaris10/x86. i found this when attempting to build/ install screen. here is the relevant part of the output: cc --param max-inline-insns-single=1200 -o background ../objects/background.o -I../test -I. -DHAVE_CONFIG_H -I. -I../include -I/openpkg/include -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -DNDEBUG -I/openpkg/include/ncurses --param max-inline-insns-single=1200 `echo -static -L../lib -lform -lmenu -lpanel -lncurses -dynamic | sed -e 's/-lform.*-lpanel[^ ]*//'` -lm ld: fatal: library -lm: not found ld: fatal: library -lc: not found ld: fatal: File processing errors. No output written to background collect2: ld returned 1 exit status make[1]: *** [background] Error 1 make: *** [all] Error 2 where do i go from her If libc.a and libm.a are not found this means your particular Solaris installation is too less. You need to install the Solaris vendor packages providing those two files, please. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Perl package issues on RHEL4
On Thu, Jun 12, 2008, steve muskiewicz wrote:
I'm currently building OpenPKG CURRENT on RHEL4, found a minor issue with the
perl:
The way the libdirs assignment is done causes a leading space to get added
to
the contents. This appears to be enough to break the perl -v and perl -V
output (in this case, it reports the Perl details from the RHEL4 package, ie.
the libs from /usr/lib/perl). I fixed it by changing this:
for dir in %{l_prefix}/lib /lib64 /usr/lib64 /lib /usr/lib /usr/ccs/lib;
do
[ -d $dir ] libdirs=$libdirs $dir
done
to this:
for dir in %{l_prefix}/lib /lib64 /usr/lib64 /lib /usr/lib /usr/ccs/lib;
do
[ -d $dir ] libdirs=${libdirs}${dir}
done
Now fixed. Thanks for reporting.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: gd package problems
On Thu, Jun 12, 2008, steve muskiewicz wrote: In OpenPKG CURRENT, there are a couple of issues with some of the options to the gd package: If %option with_fontconfig no, then you need to pass an explicit --without-fontconfig to configure, or else it ends up linking to it if the packages are found from the RHEL libs (/usr/lib) directory. Ok, --without-fontconfig now added. Also I although I am specifying with_xpm no and can see that configure is passing the --without-xpm option, if I run ldd on the gd binaries, I see that they are still linked to the RHEL libraries for Xpm (libXpm.so.4 = /usr/X11R6/ lib/libXpm.so.4). Not sure what the proper fix for this would be...anyone have any suggestions? Hmmm... perhaps an indirect dependency. In the build output I do not see that -lxpm is linked for me. But I'm not under RHEL... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Cyrus IMAPd 2.3.12p2
On Mon, May 26, 2008, Alain Spineux wrote: Do you know IMAPd 2.3.12 don't support very well blank line in configuration file ? On some platform, it SEGFAULT, on other it silently corrupt memory ! The IMAPd 2.3.12 p2 solve this problem. Maybe you missed the announce about the IMAPd 2.3.12 p2 or have other raisons the skip the p2 ? No reason, vcheck(1) just has not catched this version. I'll upgrade the package... PS: I still have no answer about DNS BIND CAPABILITIES problems :-( As usual, no problem. We at least have it fixed now in our BIND packaging. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Installing openpkg wrong target
On Thu, May 15, 2008, Jeremy Lewi wrote: I'm installing openpkg for the first time. I followed the instructions on http://www.openpkg.org/documentation/tutorial/. After running the script to produce the binary shell package, the files produced had a suffix amd64-rhel14-openpkg. My architecture however is x86_64 as I have an Xeon processor. Does this indicate a problem and is there a way to correctly specify the target? No, the architecture is correct: AMD64 is the marketing/technology name of the original vendor of the x86 64-bit technology while x86_64 is the identifier the Linux kernel uses for this platform. They are the same! It is just a little bit obscure and partly historical that even Intel Xeon's are today labeled with AMD64. OTOH it is not such incorrect as one thinks on the first spot as the 64-bit extension EMT64 the Xeons use is AFAIK a licensed technology originally coming from AMD's AMD64 platform. But you have no problem, the architecture is just fine. For some more background: it is important for GNU shtool (the tool doing the detection) to _NOT_ distinguish between ix86+EMT64 and AMD64 because they two are really mostly identical -- both for the OS and even more for OpenPKG. If GNU shtool would label one amd64 and the other e.g. ix64 (or whatever) all packages would have to recognize both, although technically there would be no single reason. So, I do not plan to change GNU shtool here... Currently, you can't specify the target manually as until now nobody ever wanted to do this (as the determined platform is usually correct). The branding in case of the x86 / 64-bit platform is just a little historical accident ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Installing openpkg wrong target
On Thu, May 15, 2008, Ralf S. Engelschall wrote: On Thu, May 15, 2008, Jeremy Lewi wrote: I'm installing openpkg for the first time. I followed the instructions on http://www.openpkg.org/documentation/tutorial/. After running the script to produce the binary shell package, the files produced had a suffix amd64-rhel14-openpkg. My architecture however is x86_64 as I have an Xeon processor. Does this indicate a problem and is there a way to correctly specify the target? No, the architecture is correct: AMD64 is the marketing/technology name of the original vendor of the x86 64-bit technology while x86_64 is the identifier the Linux kernel uses for this platform. They are the same! It is just a little bit obscure and partly historical that even Intel Xeon's are today labeled with AMD64. OTOH it is not such incorrect as one thinks on the first spot as the 64-bit extension EMT64 the Xeons use is AFAIK a licensed technology originally coming from AMD's AMD64 platform. But you have no problem, the architecture is just fine. For some more background: it is important for GNU shtool (the tool doing the detection) to _NOT_ distinguish between ix86+EMT64 and AMD64 because they two are really mostly identical -- both for the OS and even more for OpenPKG. If GNU shtool would label one amd64 and the other e.g. ix64 (or whatever) all packages would have to recognize both, although technically there would be no single reason. So, I do not plan to change GNU shtool here... Currently, you can't specify the target manually as until now nobody ever wanted to do this (as the determined platform is usually correct). The branding in case of the x86 / 64-bit platform is just a little historical accident ;-) s/EMT64/EM64T/, of course. Sorry for the confusion... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-xml and ncurses minor issues on sol 10
On Fri, May 09, 2008, Scott Cruzen wrote: perl-xml contains HTML-Table-2.08.tar.gz which has a funky gid value that /openpkg/lib/openpkg/tar refuses to extract. I fixed it by recreating the tar file. I've applied a workaround to the perl-xml package which should fix this. ncurses fails to build because it can't find libm because there's no static libm on Solaris 10. Fixed by adding --with-shared to the spec file. Now also fixed by not building the test/ stuff at all from Ncurses. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: rc.bind stop not working
On Thu, May 08, 2008, Alain Spineux wrote: I found this too, this solve the chown(), but not the bind() ! For the bind I simply did a # chmod g+w /kolab/var/bind Then only two small thing tho change until the BIND developer team react :-) I didn't get any answer from bind's Team until now, except the ACK. Do you plan to fix this in you package ? Index: bin/named/unix/os.c --- bin/named/unix/os.c.orig2006-02-04 00:51:38 +0100 +++ bin/named/unix/os.c 2008-05-02 17:25:33 +0200 @@ -212,6 +212,11 @@ caps |= (1 CAP_SETGID); /* +* Since we call chown, we need this. +*/ + caps |= (1 CAP_CHOWN); + + /* * Without this, we run into problems reading a configuration file * owned by a non-root user and non-world-readable on startup. */ I thought the CAP_CHOWN patch was not sufficient to also solve your bind(2) problem. So if I apply this fix we would not gain a final solution, right? But if you can confirm that applying my CAP_CHOWN patch is sufficient I'm happy to include it into the OpenPKG bind package, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: rc.bind stop not working
On Thu, May 08, 2008, Alain Spineux wrote: On Thu, May 8, 2008 at 4:33 PM, Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Thu, May 08, 2008, Alain Spineux wrote: I found this too, this solve the chown(), but not the bind() ! For the bind I simply did a # chmod g+w /kolab/var/bind Then only two small thing tho change until the BIND developer team react :-) I didn't get any answer from bind's Team until now, except the ACK. Do you plan to fix this in you package ? Index: bin/named/unix/os.c --- bin/named/unix/os.c.orig2006-02-04 00:51:38 +0100 +++ bin/named/unix/os.c 2008-05-02 17:25:33 +0200 @@ -212,6 +212,11 @@ caps |= (1 CAP_SETGID); /* +* Since we call chown, we need this. +*/ + caps |= (1 CAP_CHOWN); + + /* * Without this, we run into problems reading a configuration file * owned by a non-root user and non-world-readable on startup. */ I thought the CAP_CHOWN patch was not sufficient to also solve your bind(2) problem. So if I apply this fix we would not gain a final solution, right? But if you can confirm that applying my CAP_CHOWN patch is sufficient I'm happy to include it into the OpenPKG bind package, of course. Be happy :-) The CAP_CHOWN patch _and_ a chmod g+w /kolab/var/bind solved the problem. You have to estimate the chmod effect on the security! I checked, a g+w is still acceptable to me from a security point of view. I've updated the package: patch included, permissions adjusted. Thanks for your feedback. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: gcc 4.1
On Mon, May 05, 2008, Benson Margulies wrote: Is there any way to get gcc 4.1 on Solaris under current openpkg? What is wrong with our current GCC 4.2.3? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: rc.bind stop not working
On Fri, May 02, 2008, Alain Spineux wrote:
[...]
# /kolab/sbin/named -u kolab-r -g
[...]
controls {
unix /kolab/var/bind/named.ctl
perm 0600 owner 19415 group 19415
keys { rndc-key; };
#inet 127.0.0.1 port 953
#allow { 127.0.0.1; }
#keys { rndc-key; };
};
[...]
Any idea what's wrong ?
Is UID 19415 really the kolab-r user?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: rc.bind stop not working
On Fri, May 02, 2008, Alain Spineux wrote:
On Fri, May 2, 2008 at 8:17 AM, Ralf S. Engelschall [EMAIL PROTECTED] wrote:
On Fri, May 02, 2008, Alain Spineux wrote:
[...]
# /kolab/sbin/named -u kolab-r -g
[...]
controls {
unix /kolab/var/bind/named.ctl
perm 0600 owner 19415 group 19415
keys { rndc-key; };
#inet 127.0.0.1 port 953
#allow { 127.0.0.1; }
#keys { rndc-key; };
};
[...]
Any idea what's wrong ?
Is UID 19415 really the kolab-r user?
Yes :-)
I looked further and found this is a capability problem, I removed
the two call to linux_setcaps in bind-9.4.2/bin/named/unix/os.c
and all (the bind and the chown) the problems diapered.
I thing this is a bind bug, not openpkg related !
They should setup the correct capabilities for linux platform.
Any comments ?
I would say: please file a bug report with the BIND developer team. If
you in parallel could fine out what the _correct_ way is to initialize
the Linux capability stuff, I'm also happy to include a patch into the
bind package to fix this until a fixed new BIND version is released.
But just removing the two calls I think might be too extreme. Can the
_real_ problem be fixed: the reason why it actually breaks?
I've not tested the following, but as a wild guess perhaps the
following solves the problem:
Index: bin/named/unix/os.c
--- bin/named/unix/os.c.orig2006-02-04 00:51:38 +0100
+++ bin/named/unix/os.c 2008-05-02 17:25:33 +0200
@@ -212,6 +212,11 @@
caps |= (1 CAP_SETGID);
/*
+* Since we call chown, we need this.
+*/
+ caps |= (1 CAP_CHOWN);
+
+ /*
* Without this, we run into problems reading a configuration file
* owned by a non-root user and non-world-readable on startup.
*/
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: rc.bind stop not working
On Thu, May 01, 2008, Alain Spineux wrote:
# openpkg rc bind stop
dont work.
running the command in a terminal show :
# /kolab/sbin/rndc stop
socket.c:3432: 2/No such file or directory
rndc: connect: unexpected error
in the file /kolab/etc/bind/rndc.conf
##
## /kolab/etc/bind/rndc.conf -- BIND rndc configuration
##
options {
default-server localhost-unix;
};
server localhost-unix {
addresses { /kolab/var/bind/named.ctl; };
key rndc-key;
};
server localhost-inet {
addresses { 127.0.0.1; };
port 953;
key rndc-key;
};
include /kolab/etc/bind/rndc.key;
You set the default to the unix socket, but looking in named.conf,
only the inet is defined.
Then changing the default to inet, like this
options {
default-server localhost-int;
};
make thinks works better.
Well, we intentionally use localhost-unix here as this way the rndc
can more easily timeout on connects in case BIND is not running at all.
The question for me is just whether localhost-unix isn't working for
you. For me it is working just fine here under FreeBSD 6...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: make the startup script more fedora/redhat friendly (chkconfig compatible)
On Thu, Apr 24, 2008, Alain Spineux wrote:
RH/fedora use chkconfig command to enable/disable a service.
This command requires some comment in the startup script to create links
in /etc/rc.d/*
[...]
Ok, the next major version of the OpenPKG Framework (to be released
soon) will contain the following change which achieves what you
requested:
Index: openpkg/src/openpkg.spec
--- openpkg/src/openpkg.spec745c5c16f259825e4b0e488917f4b40cef0c5397
+++ openpkg/src/openpkg.spec47e7d7a77c3c07f1dfba36f08a23d173b00a79bb
@@ -2372,13 +2372,36 @@ Provides: openpkg = %{release}-%{rel
chmod 755 /etc/init.d/${name}
/sbin/rc-update add ${name} default
fi
+elif [ -f /etc/redhat-release ]; then
+sroot=/etc/rc.d/init.d
+if [ ! -f $sroot/${name} ]; then
+# install transfer script
+( echo #!/bin/sh
+ echo ##
+ echo ## ${name} -- startup/shutdown transfer
script for OpenPKG ${prefix} hierarchy
+ echo ##
+ echo
+ echo # chkconfig: 2345 99 00
+ echo # description: OpenPKG ${prefix}
+ echo
+ echo [ ! -f ${prefix}/bin/openpkg ] exit 0
+ echo case \$1 in
+ echo start ) exec ${prefix}/bin/openpkg rc all
start ;;
+ echo stop ) exec ${prefix}/bin/openpkg rc all
stop ;;
+ echo esac
+) $sroot/${name}
+chmod 755 $sroot/${name}
+# activate script
+/sbin/chkconfig --add ${name}
+/sbin/chkconfig ${name} on
+fi
else
# sroot: script root directory
# lroot: link root directory
if [ -f /etc/debian_version ]; then
sroot=/etc/init.d
lroot=/etc/rc%%d.d
-elif [ -f /etc/redhat-release -o -f /etc/mandrake-release
]; then
+elif [ -f /etc/mandrake-release ]; then
sroot=/etc/rc.d/init.d
lroot=/etc/rc.d/rc%%d.d
elif [ -f /etc/SuSE-release ]; then
@@ -3160,13 +3183,17 @@ Provides: openpkg = %{release}-%{rel
if [ -f /etc/gentoo-release ]; then
/sbin/rc-update del ${name} /dev/null 21
rm -f /etc/init.d/${name} /dev/null 21
+elif [ -f /etc/redhat-release ]; then
+/sbin/chkconfig ${name} off/dev/null 21
+/sbin/chkconfig --del ${name} /dev/null 21
+rm -f /etc/rc.d/init.d/${name} /dev/null 21
else
# sroot: script root directory
# lroot: link root directory
if [ -f /etc/debian_version ]; then
sroot=/etc/init.d
lroot=/etc/rc%%d.d
-elif [ -f /etc/redhat-release -o -f /etc/mandrake-release
]; then
+elif [ -f /etc/mandrake-release ]; then
sroot=/etc/rc.d/init.d
lroot=/etc/rc.d/rc%%d.d
elif [ -f /etc/SuSE-release ]; then
Thanks for your feedback.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: updated Spreadsheet::ParseExcel module in perl-ole?
On Mon, Apr 07, 2008, steve muskiewicz wrote: It looks like there is a newer release (0.32) of the Perl Spreadsheet::ParseExcel module on CPAN. Can the perl-ole package be updated to use the newer version? (currently still using 0.2603 which is a couple of years old.) Now updated. Thanks for the hint. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: gdb breakage
On Mon, Mar 31, 2008, Caleb Epstein wrote: gdb 6.8-20080328 will not build in openpkg-current: /openpkg-current/bin/cc -L/openpkg-current/lib -c -O2 -pipe -I/openpkg-current/include/ncurses -I/openpkg-current/include -I. -I.././gdb -I.././gdb/config -DLOCALEDIR=\/openpkg-current/share/locale\ -DHAVE_CONFIG_H -I.././gdb/../include/opcode -I.././gdb/../readline/.. -I../bfd -I.././gdb/../bfd -I.././gdb/../include -I../libdecnumber -I.././gdb/../libdecnumber -DMI_OUT=1 -DTUI=1 -I/openpkg-current/include -I/openpkg-current/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror remote.c cc1: warnings being treated as errors remote.c: In function 'extended_remote_attach_1': remote.c:2859: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'pid_t' The warning would be effectively harmless, but because of the -Werror it is treated as an error and hence the build fails. I think we should remove -Werror. Now applied. Just retry with latest package version. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: spamassassin and fsl not working
On Fri, Feb 29, 2008, Birger Krägelin wrote: On Mon, Feb 25, 2008, Birger Krägelin wrote: On changing the default fsl configuration of spamassassin we found that spamassassin doesn't work with fsl. The default logfile was hardcoded in rc.spamassassin. After removing the startup option spamassassin logs to syslog. Platform is Solaris 10 Sparc. Any ideas? SpamAssassin is written in Perl and hence calls Perl's vsyslog(3) function and hence OSSP fsl cannot intercept here. But why do you want OSSP fsl here? Doesn't the --syslog=/path/to/logfile (which is in rc.spamassassin) work as expected? Or do you need OSSP fsl for some non-file based logging? This is one point, the other one is logfile rotating. The default way for openkpg packages is to rotate the logfiles and restart the servers every night. As we have heavy traffic and critical applications we cannot go offline. So wie modified fsl-descriptions to use jitter and monitor to allow for rotating without restart. But this does not work for all applications (e.g. spamassassin). I think about disabling fsl and moving to syslog-ng. Your thoughts? Well, as long as you are running just a single OpenPKG instance per Unix system and don't need the syslogd(8) of the Unix system, I see no problem by replacing OSSP fsl with syslog-ng. But if you are running multiple instances of OpenPKG or want to run the system syslogd(8) I would stick with OSSP fsl... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Squid large file support
On Thu, Feb 21, 2008, Wilson Jason wrote: Another similar one for findutils - currently it explicitly disables large files, this patch makes it an option to re-enable. [...] Ok, now also available for findutils. I just decided to remove the plural, i.e., I now use with_largefile, in order to avoid typos. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Squid large file support
On Wed, Feb 20, 2008, Wilson Jason wrote: We are running squid (squid-3.0.1-20080101) on Solaris 10 and ran into 32bit file size limits for log files. Is it possible to get something like the following patch included: [...] Sure, now applied -- I just used with_largefile (no second underscore) for the name. Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: kerberos build error
On Mon, Jan 28, 2008, Martin Lathoud wrote: [...] when trying to build kerberos, I get the following: configure: running /bin/sh './configure' --prefix=/openpkg '--prefix=/openpkg' '--includedir=/openpkg/include/kerberos' '--libdir=/openpkg/lib/kerberos' '-- checking for off_t... (cached) yes ./configure: line 6255: syntax error near unexpected token `in' ./configure: line 6255: `for ac_func in' configure: error: /bin/sh './configure' failed for plugins/preauth/pkinit error: Bad exit status from /openpkg/RPM/TMP/rpm-tmp.72379 (%build) [...] Yes, upstream vendor's configure.ac is broken. Now fixed by patching the configure script. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: mod_python
On Fri, Jan 18, 2008, Victor G. Bolshakov wrote:
Ralf S. Engelschall wrote:
On Fri, Jan 18, 2008, Victor G. Bolshakov wrote:
Ralf S. Engelschall wrote:
On Fri, Jan 18, 2008, Victor G. Bolshakov wrote:
Ralf S. Engelschall wrote:
On Mon, Oct 30, 2006, Ralf S. Engelschall wrote:
On Sun, Oct 29, 2006, Vinod Kutty wrote:
file /export/apps/opkg/2.x/lib/libexpat.a from install of
expat-2.0.0-2.20061018 conflicts with file from package
subversion-1.4.0-2.20061018
file /export/apps/opkg/2.x/lib/libexpat.la from install of
expat-2.0.0-2.20061018 conflicts with file from package
subversion-1.4.0-2.20061018
H... interesting. I cannot reproduce this in CURRENT (which has the
same version as STABLE currently): there is never a libexpat.{a,la}
installed for me (under FreeBSD). Perhaps this is related to your
particular platform (Solaris 8). I'll retry under this platform, but
this requires some time as our Solaris 8 box is not as fast as wished
and Subversion has many dependencies.
Ok, as I assumed: for some unknown reasons libexpat is installed in a
platform dependend way. Under Solaris 8 I got the file conflict now,
too. Ok, this is now fixed with subversion-1.4.0-20061030 in CURRENT.
Another one conflict between subversion and expat:
file /openpkg/lib/libexpat.a from install of subversion-1.4.6-20080117
conflicts with file from package expat-2.0.1-20080101
file /openpkg/lib/libexpat.la from install of subversion-1.4.6-20080117
conflicts with file from package expat-2.0.1-20080101
Ah, I see, Subversion includes APR and APR includes an Expat copy.
I tried to fix it now. Please retry with the latest version of
subversion package as of today.
Now OK.
P.S. Can you try to add mod_pyton into openpkg?
You can find it as apache-python in OpenPKG-CURRENT now...
One small thing - need to create openpkg/var/apache-python
without it i got this in error.log:
[Fri Jan 18 21:49:42 2008] [notice] suEXEC mechanism enabled (wrapper:
/openpkg/sbin/suexec)
[Fri Jan 18 21:49:42 2008] [notice] mod_python: Creating 8 session
mutexes based on 150 max processes and 0 max threads.
[Fri Jan 18 21:49:42 2008] [notice] mod_python: using mutex_directory
/openpkg/var/apache-python
[Fri Jan 18 21:49:42 2008] [error] (2)No such file or directory:
mod_python: Failed to create global mutex 0 of 8
(/openpkg/var/apache-python/mpmtx82880).
Configuration Failed
Now fixed, directory created.
And another strange thing - no usual error message OpenPKG: start:
apache:FAILED on openpkg rc apache start.
This might be related to the above error.
You have to use openpkg rc -d apache start to find out more...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: How to build a quick and dirty binary RPM?
On Fri, Jan 18, 2008, Birger Krägelin wrote: I just built a daemon program, which we need on several servers. To build this peace of software is a bit complicated, I have no .spec yet. Just to install and run it, I have a binary (one version linked with -lfsl, one version traditional syslog), I have a config file and i have a prepared fsl and a rc file. I installed by hand, but fsl and rc do not work. I suppose they need registration which is done, when a RPM gets installed. How to quickly build this type of binary RPM, which just consists of four files? I don't want to hack other files, just to start the daemon and to handle the syslog. The simple way is to copy an arbitrary OpenPKG *.spec file (usually from a similar package or at least one which also contains a run-command script and FSL logging, e.g. qpopper) and then edit it to fit your particular needs. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: libexpat.a/libexpat.la from install of subversion-1.4.6-20080117 conflicts with file from package expat-2.0.1-20080101
On Fri, Jan 18, 2008, Victor G. Bolshakov wrote:
Ralf S. Engelschall wrote:
On Fri, Jan 18, 2008, Victor G. Bolshakov wrote:
Ralf S. Engelschall wrote:
On Mon, Oct 30, 2006, Ralf S. Engelschall wrote:
On Sun, Oct 29, 2006, Vinod Kutty wrote:
file /export/apps/opkg/2.x/lib/libexpat.a from install of
expat-2.0.0-2.20061018 conflicts with file from package
subversion-1.4.0-2.20061018
file /export/apps/opkg/2.x/lib/libexpat.la from install of
expat-2.0.0-2.20061018 conflicts with file from package
subversion-1.4.0-2.20061018
H... interesting. I cannot reproduce this in CURRENT (which has the
same version as STABLE currently): there is never a libexpat.{a,la}
installed for me (under FreeBSD). Perhaps this is related to your
particular platform (Solaris 8). I'll retry under this platform, but
this requires some time as our Solaris 8 box is not as fast as wished
and Subversion has many dependencies.
Ok, as I assumed: for some unknown reasons libexpat is installed in a
platform dependend way. Under Solaris 8 I got the file conflict now,
too. Ok, this is now fixed with subversion-1.4.0-20061030 in CURRENT.
Another one conflict between subversion and expat:
file /openpkg/lib/libexpat.a from install of subversion-1.4.6-20080117
conflicts with file from package expat-2.0.1-20080101
file /openpkg/lib/libexpat.la from install of subversion-1.4.6-20080117
conflicts with file from package expat-2.0.1-20080101
Ah, I see, Subversion includes APR and APR includes an Expat copy.
I tried to fix it now. Please retry with the latest version of
subversion package as of today.
Now OK.
P.S. Can you try to add mod_pyton into openpkg?
You can find it as apache-python in OpenPKG-CURRENT now...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: cacti under openpkg
On Mon, Jan 14, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Sat, Jan 12, 2008, Victor G. Bolshakov wrote: Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: But next problem that poller.php return sh: /usr/local/php/bin/php: not found sh: /usr/local/php/bin/rrdtool: not found Last time i correct this using bad hack - put copy of php and rrdtool into /usr/local//php/bin/. Now i try to find real problem, but without any suspect. No, problem not with default search path in installer - it save several seconds, but it can be changed by hands while installing. Problem that something in cacti scripts try to use very strange path as location for php and rrdtool sh: /usr/local/php/bin/php: not found sh: /usr/local/php/bin/rrdtool: not found i solve this problem with safe_mode = off in ./etc/php/php.ini I tried to fix it by adding -d safe_mode=off to the php(1) call in cacti-cron now. Hopefully the stuff now works out-of-the-box and without any manual intervention... I completely forgot about command line params for php... And there is only one small thing - for smooth graphics cacti-cron need to be run every 5 minutes or even every minute. May be we can use dcron as internal openpkg cron for cacti? Ok, now also implemented. dcron is now used. Please check the latest cacti from scratch and tell us if there is still something we has to fix or adjust... not working. need to move /openpkg/etc/dcron/crontabs/cacti to /openpkg/var/dcron/crontabs/root Are you sure you are using the latest dcron package? I had to fix the dcron package first yesterday... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: cacti under openpkg
On Sat, Jan 12, 2008, Victor G. Bolshakov wrote: Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: But next problem that poller.php return sh: /usr/local/php/bin/php: not found sh: /usr/local/php/bin/rrdtool: not found Last time i correct this using bad hack - put copy of php and rrdtool into /usr/local//php/bin/. Now i try to find real problem, but without any suspect. No, problem not with default search path in installer - it save several seconds, but it can be changed by hands while installing. Problem that something in cacti scripts try to use very strange path as location for php and rrdtool sh: /usr/local/php/bin/php: not found sh: /usr/local/php/bin/rrdtool: not found i solve this problem with safe_mode = off in ./etc/php/php.ini I tried to fix it by adding -d safe_mode=off to the php(1) call in cacti-cron now. Hopefully the stuff now works out-of-the-box and without any manual intervention... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: cacti under openpkg
On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Sat, Jan 12, 2008, Victor G. Bolshakov wrote: Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: But next problem that poller.php return sh: /usr/local/php/bin/php: not found sh: /usr/local/php/bin/rrdtool: not found Last time i correct this using bad hack - put copy of php and rrdtool into /usr/local//php/bin/. Now i try to find real problem, but without any suspect. No, problem not with default search path in installer - it save several seconds, but it can be changed by hands while installing. Problem that something in cacti scripts try to use very strange path as location for php and rrdtool sh: /usr/local/php/bin/php: not found sh: /usr/local/php/bin/rrdtool: not found i solve this problem with safe_mode = off in ./etc/php/php.ini I tried to fix it by adding -d safe_mode=off to the php(1) call in cacti-cron now. Hopefully the stuff now works out-of-the-box and without any manual intervention... I completely forgot about command line params for php... And there is only one small thing - for smooth graphics cacti-cron need to be run every 5 minutes or even every minute. May be we can use dcron as internal openpkg cron for cacti? Ok, now also implemented. dcron is now used. Please check the latest cacti from scratch and tell us if there is still something we has to fix or adjust... Ok, will test and report. P.S. can you help me with packaging Spine (http://www.cacti.net/spine_info.php, http://www.cacti.net/downloads/spine/cacti-spine-0.8.7a.tar.gz) - external binary poller for Cacti? A'm not so good with RPM. There is now a cacti-spine package. But I guess we have to pre-configure its spine.conf a little bit and link it into Cacti (instead of cmd.php), right? Can you tell me details? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: cacti under openpkg
On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: P.S. can you help me with packaging Spine (http://www.cacti.net/spine_info.php, http://www.cacti.net/downloads/spine/cacti-spine-0.8.7a.tar.gz) - external binary poller for Cacti? A'm not so good with RPM. There is now a cacti-spine package. But I guess we have to pre-configure its spine.conf a little bit and link it into Cacti (instead of cmd.php), right? Can you tell me details? May be cacti is missing prereq for cacti-spine - it is possible to run Spine without Cacti, but... I avoided the dependency from cacti to cacti-spine as users of cacti should be not _forced_ having to use cacti-spine. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: cacti under openpkg
On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: Ralf S. Engelschall wrote: On Sun, Jan 13, 2008, Victor G. Bolshakov wrote: P.S. can you help me with packaging Spine (http://www.cacti.net/spine_info.php, http://www.cacti.net/downloads/spine/cacti-spine-0.8.7a.tar.gz) - external binary poller for Cacti? A'm not so good with RPM. There is now a cacti-spine package. But I guess we have to pre-configure its spine.conf a little bit and link it into Cacti (instead of cmd.php), right? Can you tell me details? Ok. Cacti config is /openpkg/share/cacti/include/config.php Significant lines is: $database_type = mysql; $database_default = cacti; $database_hostname = localhost; $database_username = cacti; $database_password = cacti; $database_port = 3306; Spine config is spine.conf (near spine binary by default, i think it correcteble only in sources for right location) Significant lines is: DB_Host localhost DB_Database cacti DB_User cacti DB_Pass cacti DB_Port 3306 Ok, understood this part. But how does one tell Cacti that Spine is used instead of cmd.php? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: sendmail and SMTP AUTH
On Sat, Jan 05, 2008, Birger Krägelin wrote: Just upgraded from OpenPKG 2.4.0 to current... sendmail built with TLS and SMTP-AUTH doesn't work anymore unable to open Berkeley db /opt/local/var/sasl/sasldb: No such file or directory On 2.4.0 I configured /opt/local/etc/sasl/apps/Sendmail.conf to use saslauthd. When serching for bugs I found string /opt/local/etc/sasl/sasl in the sendmail binary. Sendmail is still searching for sasldb and not connecting to saslauthd... Any suggestions? I'm not using Sendmail myself, but I've setup a TLS and SMTP-AUTH driven SASL-enabled Postfix and its config file is expected under prefix/etc/sasl/postfix.conf, so I would guess your file path has to be /opt/local/etc/sasl/sendmail.conf (assuming that /opt/local is your OpenPKG instance prefix). Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: cacti under openpkg
On Sat, Jan 12, 2008, Victor G. Bolshakov wrote:
While installing cacti under openpkg i found several problems.
First - Cacti poller executed through apache using this command from
cacti-cron.sh
/openpkg/bin/wget -qO /dev/null http://$server/cacti/poller.php ||
true
actually poller.php not work from web server and return:
brstrongThis script is only meant to run at the command
line./strong
This problem very easy to solve - comment this string and add
/openpkg/bin/php /openpkg/share/cacti/poller.php /dev/null 21
Now fixed.
But next problem that poller.php return
sh: /usr/local/php/bin/php: not found
sh: /usr/local/php/bin/rrdtool: not found
Last time i correct this using bad hack - put copy of php and rrdtool
into /usr/local//php/bin/. Now i try to find real problem, but without
any suspect.
Anyone using cacti under openpkg? Are there better way to correct this
problem?
Forgot to note that i got this problem under Solaris 10 (Sparc) and FreeBSD
6.2 on x86.
Should be now fixed, too. At least when one reinstalls Cacti from
scratch. I hacked the installer so it now checks for prefix/{bin,sbin}
first when searching the tools like php(1) and rrdtool(1).
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: CURRENT: 00INDEX.rdf.bz2 multiple entries for perl-openpkg
On Tue, Jan 08, 2008, Scott Cruzen wrote: There's two entries for perl-openpkg in the 00INDEX.rdf.bz2 file. One starts on line 11120 and mentions perl-openpkg-5.10.0-20080101. The other starts on line 60339 and refers to perl-openpkg-5.10.0-20080107. The url of the second points to the 00UPLOAD directory, which is inaccessible. I think that there's probably some bug in the process that generates 00INDEX.rdf.bz2, or my openpkg build command doesn't know that it should ignore the second entry. Oh, my fault. The file in 00UPLOAD was not picked up and filed into the proper subdir on the FTP server because it was alreay rolled with RPM 5 ;-) Sorry, should be fixed once the index is updated in about 30 minutes. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: squirrelmail openpkg
On Fri, Jan 04, 2008, Alain Spineux wrote: Their was no problem ! My own post-install script had replaced apache-php.conf by an empty file, as I was doing before the patch, then no more PHPINIDir, and then the error message. My squirrelmail package was already ok with openpkg, but now kolab has a patch that should make it work. So, please still acceede the OpenPKG Contributor Agreement on the website, send your patch to me via mail and I'll commit it for you into OpenPKG-CURRENT. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: squirrelmail openpkg
On Fri, Jan 04, 2008, Ralf S. Engelschall wrote: [...] You still have to explicitly reply to the *mail* which was generated by the OCA web *form*... Thanks, now received. But the simple reply to acknowledge the Petidomo service is sufficient, of course ;-) Your patch I've now committed: http://cvs.openpkg.org/chngview?cn=38653 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: conflicting files perl vs. perl-module
On Thu, Jan 03, 2008, Thomas Moschny wrote: Ralf S. Engelschall wrote: The conflicting files are from Module::Build which now seems to ship also with Perl itself. As perl-module always contains the latest version, I'm now removing those files in perl. So, issue now fixed. Thanks. While you're at it, here are two more overlaps: /openpkg/bin/ptar and /openpkg/bin/ptardiff for perl and perl-sys and /openpkg/bin/shasum for perl and perl-crypto. Thanks for those hints, too. Now fixed, too. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: About openpkg changes in 2008
On Wed, Jan 02, 2008, Alain Spineux wrote: I have some problem to understand the split between packages and framework and in particular this: 4. The exclusive rights to use the whole OpenPKG Framework was assigned by contract from Ralf S. Engelschall to the OpenPKG GmbH. The OpenPKG GmbH from now on is the official provider of the OpenPKG Framework, which technically includes the OpenPKG bootstrap, the OpenPKG tool chain, the OpenPKG registry, etc. The OpenPKG GmbH will deliver the OpenPKG Framework under licenses which grant limited permission to use, copy, modify and distribute it. I dont understant very well what is the Framework or the place it take into the Openpkg system Does binutils-2.18-2007.src.rpm (that is an important part of a tool chain) is part of the Framework or just a product/result of it ? Is the Framework, the infrastructure: tools, internal scripts or software, maybe the website, maybe a computer farms that help to generate the packages ? The OpenPKG Framework is just the old openpkg (bootstrap) package and the few corresponding openpkg-* packages. Technically it is still shipped as the openpkg bootstrap package, but internally it contains more functionality (e.g. RPM 5, openpkg index, etc). Does this paragraph 4 change anything for kolab users or developers ? No, nothing will change for the KOLAB *users* as long as the KOLAB *developers* either stay with the old RPM 4 based OpenPKG or for using the forthcoming RPM 5 based OpenPKG at least take explicit action to once receive a custom KOLAB license from the OpenPKG GmbH which in turn can be applied by all KOLAB users. Notice that the new OpenPKG Framework will be licensed in various distinct ways and so this mentioned special KOLAB license is already planned by us. According to our current plan it will be some sort of a reusable free of charge but instance prefix is limited to /kolab license. So, you should be effectively not have a drawback by the forthcoming changes to the OpenPKG world order and instead even be more free than currently as we additionally plan to even lift all current download restrictions... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: issues with build -Ua
On Fri, Dec 28, 2007, Martin Lathoud wrote: openpkg build -Ua is trying to reinstall already current packages, the generated script is attached. o rpm -q flex perl-parse perl-xml perl-net perl-www flex-2.5.34-20071222 perl-parse-5.10.0-20071227 perl-xml-5.10.0-20071219 perl-net-5.10.0-20071219 perl-www-5.10.0-20071222 The options -Ua also trigger rebuilds for reverse dependencies. You would have to use -Uaq to get rid of those, I think. I also have to use a proxy to access ftp.openpkg.org and it's a pain to get it working: proxytunnel is broken (not being used when put in curlrc), then I allow ftp.openpkg.org to go through the firewall with no proxy, perl-www is trying to fetch some dependencies with CPAN which isn't ftp_proxy aware (hence failing) and even configuring a proxy with /openpkg/bin/perl -MCPAN has no effect when perl-www is being built. For the proxies problems we cannot do anything from the OpenPKG side, I think. But that perl-www tries to download something via CPAN shell is a problem we can fix. This means a dependency module is missing. Can you show me the details, i.e., _WHICH_ module it tries to download? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: issues with build -Ua
On Fri, Dec 28, 2007, Martin Lathoud wrote: 2007/12/28, Ralf S. Engelschall [EMAIL PROTECTED]: For the proxies problems we cannot do anything from the OpenPKG side, I think. But that perl-www tries to download something via CPAN shell is a problem we can fix. This means a dependency module is missing. Can you show me the details, i.e., _WHICH_ module it tries to download? Actually, it is Text::Autoformat: [...] Ok, now fixed. A dependency to perl-text was required. Thanks for your feedback. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Apache suphp and Solaris 10 Sparc
On Wed, Dec 26, 2007, Birger Krägelin wrote: When compiling apache-suphp on Solaris 10 I get the following error: make[3]: Nothing to be done for `install-exec-am'. ../../config/install-sh -c -d /opt/local/RPM/TMP/apache-suphp-0.6.2-root'/opt/local/libexec/apache' /bin/ksh: ../../config/install-sh: cannot execute make[3]: *** [install-data-local] Error 126 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 error: Bad exit status from /opt/local/RPM/TMP/rpm-tmp.19213 (%install) Should be now fixed with latest apache-suphp from CURRENT. The script install-sh was not provided by the upstream vendor with the correct permissions. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Imageagick and Solaris 10 Sparc
On Wed, Dec 26, 2007, Birger Krägelin wrote: I get the following error when compiling Imagemagick on a Sparc machine running Solaris 10 udate 4 (08/2007) /bin/sh ./libtool --silent --tag=CC --mode=compile /opt/local/bin/cc -DHAVE_CONFIG_H -I. -I./config -I./ltdl -I./ltdl -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include/tiff -O2 -pipe -I/opt/local/include -I/opt/local/include/tiff -Wall -W -MT magick/magick_libMagick_la-animate.lo -MD -MP -MF magick/.deps/magick_libMagick_la-animate.Tpo -c -o magick/magick_libMagick_la-animate.lo `test -f 'magick/animate.c' || echo './'`magick/animate.c /opt/local/RPM/TMP/ImageMagick-6.3.7/libtool: bad substitution make[1]: *** [magick/magick_libMagick_la-animate.lo] Error 1 make[1]: Leaving directory `/opt/local/RPM/TMP/ImageMagick-6.3.7' Any suggestions? Perhaps related to the fact that /bin/sh under Solaris is a Korn-Shell or some variables in libtool were incorrectly determined and hence some substitution fails. I'm currently trying to build Imagemagick on your box (rm9.openpkg.net) in the hope I can reproduce the problem. But rm9.openpkg.net is installed under a far older Solaris, so in case will be not able to reproduce myself, it could be also related to your new Solaris verision. We'll see... it needs time to check as I still build the larger set of dependencies ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: some remarks on openldap.spec
On Sat, Dec 22, 2007, Dieter Klünter wrote: the openldap.spec file for openldap-2.4.7 contains some deprecated build args: ldbm is deprecated Thanks for the hint. Now completely removed from *.spec. slurp is deprecated Good catch. I've now removed all references to it. How to use syncrepl I leave up to the user for now. crypt is discouraged Sure, crypt(3) is already discouraged since about 15 years ;-) I'm keeping it for now anyway as I quickly cannot decide how important it still is... readline is deprecated Ok, removed at all. openldap.patch is obsolete to my understanding. Not all parts. Only the slurp parts, I think. These I've now removed. As OpenLDAP strongly recommends building with sasl I would also recommend to modify package options to 'with_sasl yes'. H... mostly all other SASL-enabled OpenPKG packages default to with_sasl=no. No, I don't think we really should follow what the vendor recommends here... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openldap dumps core
On Sat, Dec 22, 2007, Dieter Klünter wrote: Hi, my system: x86_64 opensuse-10.3 I have built db and sasl without additional flags and openldap with with_pth=no with_pthreads=yes with_sasl=yes with_slurpd=no slapd started in debugging modus shows that the initializing process hangs with daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: epoll: listen=10 busy I don't think the daemon hangs, it is just waiting for connections, right? when killing the process daemon: shutdown requested and initiated daemon: closing 9 daemon: closing 10 slapd shutdown: waiting for 2 threads to terminate slapd_listener(@Fn) daemon: accept(10) failed errno=9 (Bad file descriptor) The core didn't show much in gdb and attaching strace to slapd pid didn't show much either: write(2, daemon: epoll: listen=10 busy\n, 30) = 30 epoll_wait(8, unfinished ... Yes, I've seen this segfault since a longer time in OpenLDAP. It always happended on shutdown. I guess the shutdown procedure of OpenLDAP is buggy. I presume this is due to the fact that BerkeleyDB and slapd have been build with different mutexes. What are the correct arguments to build db with pthread instead of libthread_db? It might be related to this, but I personally think it is more a bug in the OpenLDAP shutdown procedure. But for using openldap::with_pthreads=yes you *HAVE* to use db::with_pthreads=yes. There is already an explicit dependency, but I guess you installed openldap with --force and hence have not noticed. But please be aware that db::with_pthreads=yes easily breaks mostly everything in OpenPKG, because other packages which are also db consumers do not know how to correctly build a thread-enabled Berkeley-DB (no use of db.pc, etc). PS: I've now forced OpenLDAP to not use epoll(2) or /dev/poll if GNU Pth is used for threading. This should fix your issues under Linux. Just try it out... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
