Fix to R package
I just uploaded a modified spec file for the R statistical package. The fix is to patch *both* R scripts, and to patch not just R_HOME_DIR, but also R_SHARE_DIR, R_INCLUDE_DIR, and R_DOC_DIR. This is necessary to allow packages to be installed. Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
perl-dbi submission: problems with DBD_Oracle
I just uploaded perl-dbi-5.8.8-20060929pu1_cses.src.rpm. There were two problems when with_dbd_oracle = yes: 1) DBD_Oracle would not build. This turned out to be a naming problem. The version provided in the rpm is 1.18, but it was named 1.18a. It unpacked into a directory with a -1.18 suffix, but the spec file was looking for it in a directory with a -1.18a suffix. I renamed the .tar.gz file and changed the spec file to use 1.18 as the version, and the package now built. 2) DBD_Oracle would not run: This was trickier. DBD_Oracle is designed to set LD_RUN_PATH during the build such that $ORACLE_HOME/lib will be added to Oracle.so's search paths at run time to find libclntsh.so. The code in DBD_Oracle 1.18 is now incompatible with v1.50 of MakeMaker (packaged with perl 5.8.8), so that $ORACLE_HOME/lib is not added to Oracle.so's search path, and DBD_Oracle fails to initialize. I've created a patch that is compatible with both the new and the old MakeMaker to fix this problem. I will submit it to the authors as well. Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
RE: query all build options?
Bill, Would you be willing to share your python version? Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Campbell Sent: Wednesday, October 04, 2006 6:12 PM To: openpkg-dev@openpkg.org Subject: Re: query all build options? On Wed, Oct 04, 2006, Dennis McRitchie wrote: Bill, You recently posted a perl script called rpmgetopts.pl. Is this the one you meant? I guess I posted the older perl version. I then rewrote it in python, adding a few features such as automatically enclosing the ``--define'' lines between ``openpkg rpm $@'' and the spec file name. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc. UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ ``The Income Tax has made more Liars out of American people than Golf has.'' Will Rogers __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
RE: query all build options?
Bill, You recently posted a perl script called rpmgetopts.pl. Is this the one you meant? Thanks, Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Campbell Sent: Wednesday, October 04, 2006 4:16 PM To: openpkg-dev@openpkg.org Subject: Re: query all build options? On Wed, Oct 04, 2006, David M. Fetter wrote: Is there a simply built-in method to query all installed rpms for what build options are used? I recently posted a python script, getrpms.py, that I use to make it easy to create the ~/.openpkg/build file used by ``openpkg build'' or scripts that can be used in a SRC/packagename directory. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc. UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ ``Perhaps, when committing your first federal crime, it would be unwise to slap your name and address on it and mail it to 10,000 people.'' --Dogbert __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
How to re-package the openpkg shell script
Hi, I need to add a couple of files (e.g., environment-setting scripts that are similar to the long version of the opa script) to openpkg-*-*.src.sh so that they get copied to the openpkg tree once the binary shell script is built (from the source script) and installed. I also need to modify etc/rc.func for reasons I'll explain in another email. I would prefer not to create another RPM just for this purpose, since eval `$prefix/etc/rc --eval all env` is part of the base package, and I would like the opa-like wrapper script to be similarly available. What is the recommended way to re-package openpkg-*-*.src.sh ? Thanks, Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Problematic side-effect of the openpkg environment-setting script
Hi, The environment-setting script eval `$prefix/etc/rc --eval all env` is very useful, but has one inconvenient side-effect: it insists on putting certain system directories (e.g., /bin, /usr/bin, etc.) at the end of the path variable it is modifying (e.g., PATH, MANPATH, LD_LIBRARY_PATH, INFOPATH), whether these system directories are already present in the path variable or not. The rcPath() function in etc/rc.func does check to see if the system directory is present in the file system, and does not add it if it is not; but it does no similar check to see if it is present in the path variable it is modifying. The net result in our environment is that certain commands will break after setting the openpkg environment in this fashion. One example: we also use the Berkeley system library on our systems, but place it after /usr/bin and /bin, because we don't want to use the Berkeley versions of commands unless there is no comparable native version. However, after executing eval `$prefix/etc/rc --eval all env` the Berkeley version of commands becomes the preferred one. Since I'd like to make sure that I stay in sync with future versions of OpenPKG, I would prefer to continue to use eval `$prefix/etc/rc --eval all env` rather than write my own environment-setting script from scratch. So I decided to modify rcPath() such that when the -e option is passed to it, it makes sure that the passed system directory is *both* present in the file system and *not* present in the path variable before it adds the system directory to the path variable. My question is whether you would entertain my submitting this change to rc.func for inclusion as part of the OpenPKG base package. Thanks, Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
openssh with_ldap option fails in v 2.5
When building openssh-4.2p1-2.5.0.src.rpm with the with_ldap option turned on, we found that it failed at the patching stage. Further investigation revealed this comment in the spec file: # FIXME: rse: with_ldap currently broken due to upgrades I don't see a fix in the UPD directory, but I do see that there is a newer version of 4.2p1 in current that patches differently when using the with_ldap option, and where the FIXME comment has been removed. 1) Should we be using the current version if we need the with_ldap option? 2) Shouldn't this fix be back-ported into the 2.5 UPD directory? Thanks, Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
RE: openssh with_ldap option fails in v 2.5
Thanks Ralf! Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralf S. Engelschall Sent: Thursday, January 19, 2006 10:47 AM To: openpkg-dev@openpkg.org Subject: Re: openssh with_ldap option fails in v 2.5 On Thu, Jan 19, 2006, Dennis McRitchie wrote: When building openssh-4.2p1-2.5.0.src.rpm with the with_ldap option turned on, we found that it failed at the patching stage. Further investigation revealed this comment in the spec file: # FIXME: rse: with_ldap currently broken due to upgrades I don't see a fix in the UPD directory, but I do see that there is a newer version of 4.2p1 in current that patches differently when using the with_ldap option, and where the FIXME comment has been removed. 1) Should we be using the current version if we need the with_ldap option? 2) Shouldn't this fix be back-ported into the 2.5 UPD directory? I think back-porting is ok here, especially because it just changes the packaging of OpenSSH under build option with_ldap and there (if it is already broken) can only improve it. I've now MFC'ed the LDAP support fixes to OpenPKG-2.5-SOLID and released the resulting openssh-4.2p1-2.5.1.src.rpm to the FTP server. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Can't build openldap-2.3.11-2.5.0.src.rpm on Solaris 9
Hi Ralf, When building openldap-2.3.11-2.5.0.src.rpm on Solaris 9 using openpkg-tools, we encountered the following build failure: v checking for SSLeay_add_ssl_algorithms in -lssl... no checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no checking OpenSSL library version (CRL checking capability)... yes configure: error: Could not locate TLS/SSL package error: Bad exit status from /usr/psr.local/RPM/TMP/rpm-tmp.29402 (%build) ^^ The problem turned out to be a missing reference to -lz on the command line used to test for SSL_library_init. Config.log reveals: vv configure:19388: checking for SSL_library_init in -lssl configure:19418: /usr/psr.local/bin/cc -o conftest -O2 -pipe -I/usr/psr.local/ include/pth -I/usr/psr.local/include -I/usr/psr.local/include/sasl -I/usr/psr. local/include/pth -L/usr/psr.local/lib -L/usr/psr.local/lib/pth -L/usr/psr.loc al/lib conftest.c -lssl -lcrypto -lresolv -lpth -lfsl -lsocket -lnsl -lrt 5 /usr/psr.local/lib/libcrypto.a(c_zlib.o): In function `zlib_stateful_free_ex_d ata': c_zlib.c:(.text+0x8): undefined reference to `inflateEnd' c_zlib.c:(.text+0x10): undefined reference to `deflateEnd' /usr/psr.local/lib/libcrypto.a(c_zlib.o): In function `zlib_stateful_init': c_zlib.c:(.text+0x90): undefined reference to `inflateInit_' c_zlib.c:(.text+0xe4): undefined reference to `deflateInit_' /usr/psr.local/lib/libcrypto.a(c_zlib.o): In function `zlib_stateful_compress_ block': c_zlib.c:(.text+0x230): undefined reference to `deflate' /usr/psr.local/lib/libcrypto.a(c_zlib.o): In function `zlib_stateful_expand_bl ock': c_zlib.c:(.text+0x2b0): undefined reference to `inflate' collect2: ld returned 1 exit status ^ Adding -lz solved the problem. What we're trying to understand is how you were able to build it on your build farm without it? libcrypto.a is built as part of openssl and contains references to zlib; in fact, zlib is an openssl dependency. Yet, the openldap configure script, which requires openssl, does not reference zlib. So how did this work for you? As a member, is there a way for me to look at your config.log to see what is different in your setup? I want OpenPKG to succeed, and problems like this can contribute to users not accepting OpenPKG as their solution. So it would be good if we could understand the discrepancy, and then clarify, perhaps through documentation, what the required Solaris 9 setup is for a successful build. Thanks, Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
RE: Can't build openldap-2.3.11-2.5.0.src.rpm on Solaris 9
Hi Ralf, I'm responding to the list in case this helps someone else. I actually had to check in /v/openpkg/bf/arc/OpenPKG_2.5/log to find the right build, but I found the problem. We are building openssl with with_zlib enabled, and that is setting up the unresolved 2nd-order dependency in openldap (i.e., openldap knows it needs openssl, but does not realize that this implies it also needs zlib). Having gotten past this problem, we have encountered the same problem building perl-www which also needs openssl, and hence zlib. (We built with the same options when we built OepnPKG 2.1, but for some reason did not hit these snags then.) I have in the past encountered other examples of these 2nd-order dependency problems (as well as other problems) when turning on with_xxx options that default to off. What is the OpenPKG policy with regard to testing the provided options prior to delivering a release? Do you simply guarantee that the default set of options will build out of the box, but that turning on any options is at the user's own risk? Or do you also test with, say, all options enabled? If it's the former, is this documented on the openpkg website? I can sympathize if you only have the resources to test the defaults, but feel that it makes the untested options significantly less useful, given the number of times I've been bitten turning them on. But in any case, what OpenPKG is committing to testing and not testing has to be clear to potential adopters, I think. Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University -Original Message- From: Ralf S. Engelschall [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 1:33 PM To: [EMAIL PROTECTED] Subject: Re: Can't build openldap-2.3.11-2.5.0.src.rpm on Solaris 9 On Tue, Jan 17, 2006, Dennis McRitchie wrote: As a member, is there a way for me to look at your config.log to see what is different in your setup? [...] Sure, log onto *.openpkg.net and look into the directory /v/openpkg/bf/log/ (is auto-mounted on access). Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Problem installing add-on packages with R
Hi, Some of our faculty members have requested we provide them the R statistical package. I used the r-2.1.1-20050625.src.rpm package in current. This built fine, but encountered some problems when installing add-on packages at runtime using the install.packages() function. I fixed one problem (and will submit the fix in a while), but have now encountered a philosophical problem I need some advice on how best to handle. Some of these add-on packages are actually built from source by R. You invoke R, and from its command prompt, you type in, say, 'install.packages(c(MCMCpack))'. This invokes a script that downloads the package from the Carnegie CRAN site, unpacks the tar.gz file, calls configure, make, and make install. The directories appear to be set correctly; it is the libraries that are the problem in some cases. In the case of MCMCpack, it uses the g++ compiler, and needs the libstdc++.so library. OpenPKG's gcc rpm only provides libstdc++.a, due to its policy of creating only static libraries. So the build fails. Manually changing the MCMCpack bundle is not a good solution since any user that installs our R binary rpm on their local machine is free to invoke the install.packages() function at any time to download and install the latest version of their favorite R add-on package. Therefore I would not have control over those versions. Furthermore, install.packages() requires that you download the package from an internet source (R offers you a list of about 50 mirror sites), so I can't tell it to install a modified add-on package from our repository. Since this problem is due to gcc being built with static libraries, I wanted to ask this forum what the party line is for such a case. Is it that we cannot support this functionality in R? That would be an unpopular choice among our users. Is there any thought to removing the static library restriction anytime soon? Thanks, Dennis Dennis McRitchie Computational Science and Engineering Support (CSES) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Updated perl-crypto contribution
Hi, I just uploaded perl-crypto-5.8.4-20050329.src.rpm to the contrib area. The changes consist of adding Crypt::Rijndael v0.05 support to the package. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Contribution for multi-threaded perl
Hi, I just uploaded a modified perl.spec based on the one in your perl-5.8.4-2.1.0.src.rpm package. What has been added is a with_multi-threading option, which defaults to no to emulate the original behavior. We needed this capability to improve performance on some of our more complex perl usage. This change has been tested on both RedHat Linux 9 and Solaris 9. I know you're up to 2.2 now, but we're still on 2.1. Hopefully the change can be easily ported to 2.2, assuming you haven't put in the option yourself in the meantime. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Conditional Provides in openpkg-import confuses openpkg-tools
openpkg-import-0-2.1.0.src.rpm has a spec file containing the following
lines:
%if %{with_mta} == yes
Provides: MTA
Conflicts:exim, postfix, sendmail, ssmtp
%endif
Apparently, since the Provides is only executed conditionally, it is not
recognized by openpkg-tools. So while openpkg-import will get built, it will
not be seen as providing MTA by openpkg-tools. It does not matter if the
default value for with_mta is yes or no.
I had to remove the %if and %endif altogether to get openpkg-tools to
recognize the Provides keyword.
I wasn't sure if you were already aware of this quirk, so I thought I'd
mention it.
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
RE: Dependency problem with unixodbc
Ralf, I see what you mean. Many simple packages have no Provides directives in their spec files and yet they work fine with openpkg-tools. Hmmm I can't quite completely reconstruct events at this point (I did this several weeks ago), but as I recall, I was using openpkg-tools to create an index and then build a script. On one occasion when I did this, the openpkg build failed with one of those frood can't be found messages, in this case perl-dbi/DBD::ODBC (or freetds) required unixodbc but openpkg build did not seem to be able to find it. So I added a Provides: unixodbc directive to the unixodbc spec file, reran openpkg index and openpkg build, and the problem went away. The commands I used were: openpkg index -r PSR/Source -o 00INDEX.rdf -i [my source rpm directory] openpkg build -R [prefix]/bin/openpkg rpm -r [my source rpm directory] -A [build-script] I know it doesn't make much sense, but I don't have time right now to reproduce the problem, so maybe we need to wait until it happens again. Thanks for your help. Dennis P.S. openpkg rpm -qi only reports what is explicitly provided by a package (i.e., via Provides directives). It does not report the implicit provide self that you mention that all packages have. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralf S. Engelschall Sent: Thursday, September 16, 2004 8:07 AM To: [EMAIL PROTECTED] Subject: Re: Dependency problem with unixodbc On Wed, Sep 15, 2004, Dennis McRitchie wrote: The spec file in unixodbc-2.2.9-2.1.0.src.rpm lacks a Provides: unixodbc directive. This is required by perl-dbi when with_dbd_odbc=yes and by freetds. I have uploaded a modified spec file with this directive added. This cannot be. An RPM package foo always implicitly does a Provides: foo. So, adding a Provides: unixodbc to unixodbc.spec is redundant AFAIK. Your problem has to be something else. Can you recheck this issue? You can see what a package provides with rpm -qi or rpm -qpi. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Does openpkg-bugdb still work?
I submitted a bug report yesterday (twice) but it has not yet shown up in the mailing list or the newsgroup. Thanks, Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Minor problems with oracle-barebone-9.2.0-20040818
Hi Ralf, Nice job on OpenPKG 2.x. I finally upgraded from 1.3+ and it generally went quite smoothly. Just a few problems with oracle-barebone this time around. 1) I believe oracle-barebone.pl should list network/admin/samples in addition to network/admin since the spec file refers to files in network/admin/samples and this will provide the user with samples to work from. 2) Since the last time I used it, oracle-barebone.pl has had rdbms/install and network/lib32 added to the directory list (among other dirs), but my Oracle installation - using client runtime + oracle call interfaces and oracle programmer - does not create those (I use the 32-bit distribution). However, I was able to run oracle-barebone successfully without them in the past, and I still can, so I'm not sure why they're there. 3) The spec file names the solaris bz2 files sun4u-sunos5.X whereas the doc file still provides instructions on naming them sparc64-solarisX. 4) It would be great if there were a way to provide a set of dependencies that caused the openpkg oracle package to require oracle-barebone. Perhaps adding a with_oracle-barebone option to the oracle package, and a Provides: oracle-barebone to oracle-barebone? As it is, one has to manually build and install oracle-barebone first before using openpkg-tools for the rest of the packages. Thanks, Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Modified pine-4.60L-2.1.0.src.rpm to support openldap with sasl
I reported this one before, but the problem is still in openpkg 2.1.
If openldap is built using with_sasl=yes, then libsasl2 and libdl need to
be added to other packages that link using openldap.
I have uploaded a pine.spec with the following change:
%if %{with_ldap} == yes
ldflags=$ldflags -lsasl2 -ldl
case %{l_platform -t} in
*-sunos5.* ) ldflags=$ldflags -lresolv ;;
esac
%endif
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
openldap change needed for sasl support on RedHat Linux 9
I uploaded openldap.spec with the following change:
%if %{with_sasl} == yes
# hard-code use of SASL2 library
( echo ac_cv_lib_sasl2_sasl_client_init=yes
) config.cache
cf=%{l_cppflags sasl}
# -ldl needed on link line to satisfy -lsasl2, which is turned on
# by the configure script. Only a problem on redhat9.
sasl_ldflags=-ldl
%else
cf=%{l_cppflags}
%endif
CC=%{l_cc} \
CFLAGS=%{l_cflags -O} \
CPPFLAGS=$cf \
LDFLAGS=%{l_ldflags} %{l_fsl_ldflags} $sasl_ldflags \
LIBS=%{l_fsl_libs} \
./configure \
snip
This adds libdl to LDFLAGS to satisfy some libsasl2 references. For some
reason, this was only necessary on RedHat Linux 9 and not on Sun Solaris 9,
though I was not able to track down the reason.
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
perl-dbi spec changed to fix build error
I have uploaded the spec file for perl-dbi-5.8.4-2.1.0.src.rpm with some changes: 1) the calls to perl-openpkg for with_dbd_odbc and with_dbd_pgsql need to be in the same scope as ODBCHOME and POSTGRES_HOME. Otherwise a build error results. 2) I had to undo the change to rename demo_rdbms.mk to demo_rdbms32.mk because I built oracle-barebone using the 32-bit distribution, which contains the former but not the latter. Perhaps a better solution would be to have the rename be conditional on an option such as with_32-bit_oracle being set to no, which could be the default? Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Dependency problem with unixodbc
The spec file in unixodbc-2.2.9-2.1.0.src.rpm lacks a Provides: unixodbc directive. This is required by perl-dbi when with_dbd_odbc=yes and by freetds. I have uploaded a modified spec file with this directive added. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Need optional xaw3d dependency in emacs
When emacs-21.3-2.1.0.src.rpm builds, it *implicitly* looks for xaw3d and uses it if it finds it. However, since there is no explicit dependency on xaw3d, openpkg-tools may choose to build emacs first. In this case, the build will succeed but xaw3d will not be included, and the scroll bars will not work as expected. One solution is to add a with_xaw3d option to the emacs spec file to force an RPM requirement for xaw3d, and thus guarantee that the latter will be built first by openpkg-tools. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
texinfo and tetex packages have a conflict
There are two files that appear in both tetex-2.0.2-2.1.0.src.rpm and texinfo-4.7-2.1.0.src.rpm: prefix/man/man5/info.5 prefix/man/man5/texinfo.5 As a result, regardless of the build and install order, the second of these two packages to be installed will fail to install unless the --force flag is used. Thus these packages cannot be built together using openpkg-tools. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
RE: perl-dbi spec changed to fix build error
Michael, This is indeed a different problem, and may actually be the reason why I'm not seeing *your* problem: I'm using the 32-bit distribution from Oracle and thus probably don't have a mix of 32- and 64-bit components. Thanks, Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schloh Sent: Wednesday, September 15, 2004 2:02 PM To: [EMAIL PROTECTED] Subject: Re: perl-dbi spec changed to fix build error On Wed, Sep 15, 2004, Dennis McRitchie wrote: I have uploaded the spec file for perl-dbi-5.8.4-2.1.0.src.rpm with some changes: 2) I had to undo the change to rename demo_rdbms.mk to demo_rdbms32.mk because I built oracle-barebone using the 32-bit distribution, which contains the former but not the latter. Perhaps a better solution would be to have the rename be conditional on an option such as with_32-bit_oracle being set to no, which could be the default? I'm currently investigating problems with the with_dbd_oracle option. If you are using a SPARC 64bit, I believe the perl-dbi is broken due to mixed 32bit/64bit linking of liboracle.a or something like that. The workaround is to set LD_LIBRARY_PATH to point to the lib32 directory. If this doesn't make sense to you it may mean that we are talking about two separate problems. Regards, Michael -- Michael Schloh von Bennewitz [EMAIL PROTECTED] Development Team, Operations Northern Europe Cable Wireless Telecommunications Services Tel +49-89-92699-227, Fax +49-89-92699-808 __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Modified tcpwrappers contribution
Hi, I modified tcpwrappers-7.6k to play nicely with other OpenPKG packages - such as ORBit - that link with libwrap.a, if present. The changes are as follows: 1) Steve Grubb changed the name of a number of external library definitions to avoid namespace collisions. E.g., by default his code defines tcpd_sock_host instead of sock_host, and tcpd_eval_client instead of eval_client. Since the ORBit package is looking for the traditional function names, it fails to link with Grubb's default libwrap.a. So I added an option to the spec file called with_private_namespace, which defaults to no so that the traditional lib defs are created by default. Setting the option to yes creates the new private definitions. This change also required a change to the patch file because Steve had apparently forgotten to include sock_host in the list of methods that need to be optionally publicized. 2) Matthias Kurz's patch to run under Solaris changed the name of the local my_setenv() function to setenv(). The ORBit package objects to this because it does not want to link with a tcpwrappers that has setenv() built in. (I'm not sure why this is since Solaris by default does not have a setenv() function, which is why tcpwrappers conditionally includes one.) However, the way to make ORBit happy is to leave my_setenv() alone and to conditionally redefine the call to setenv() in options.c to be a call to my_setenv() on systems that need the local definition of this function. That way any other external packages that are fussy about this will not complain. These changes are also present in this package. Hope this helps. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
RE: emacs, giflib, and tiff contributions
Well, I do not mean that other packages use tiff/tiff.h,
but the other packages explicitly use -Iprefix/include/tiff
to locate the stuff (see %{l_cppflags} for this). This we
would have to change in all other packages. OTOH if a package
has a larger set of includes, it is reasonable to place the
stuff into its own subdir. So is a %{l_cppflags tiff .}
enough for Emacs to find the prefix/include/tiff/ files?
Yes, %{l_cppflags tiff .} works to build emacs. I tested it on both Redhat
Linux 9 and Solaris 9.
I've uploaded the src rpm file with the modified spec file.
Dennis
P.S. I still think you're giving yourself way more work than you need to by
moving these header files. But who am I to complain since you're doing most
of the work... :-)
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
emacs, giflib, and tiff contributions
Hi, I've uploaded the above 3 contributions. Here are the changes: 1) emacs: emacs segfaults when starting up in X mode if built with with_x11 yes on Solaris 9 with a recent version GNU ld. This is because a couple of years ago, GNU ld changed the combreloc switch from being defaulted off to being defaulted on. So now you need -z nocombreloc to build emacs with GNU ld. Emacs had been patched to turn on this option for GNU/Linux and FreeBSD, but not for Solaris. I have added to emacs.patch to provide this switch for Solaris as well. Note that if you build on Solaris and use the native ld, you must not use -z nocombreloc else you get a fatal error. I tried to allow for this in my patch, but am not sure if I succeeded. However, I passed the patch on to Richard Stallman, and he's accepted the it, so it's probably the right way to go. 2)giflib: emacs requires libungif v4.1.0b1 or later. The package you provide only has v4.1.0, which will be ignored by emacs. Toshio Kuratomi is now back supporting libungif (as of a few weeks ago) and has already produced v4.1.1, which incorporates v4.1.0b1, some subsequent patches that various packagers have applied, and support for the latest libtool (so your libtool patches are no longer needed). So rather than update the OpenPKG giflib package with libungif v4.1.0b1 (which is already several years old), I used v4.1.1. Also, Toshio has moved libungif to SourceForge, so I changed the URL. See http://sourceforge.net/projects/libungif. 3) tiff: emacs looks for tiff header files in specified include directories only. Since the OpenPKG tiff package put them in a tiff subdirectory within the OpenPKG include directory, they were not found by emacs and therefore not used. Note that both the RedHat 9 package and the sunfreeware package places them in /usr/include and /usr/local/include respectively, where they can be found by emacs. So I changed the package to place them where they are needed. I saw that you provide 12 header files while the RedHat 9 and sunfreeware packages only provide 4: tiff.h, tiffconf.h, tiffio.h, and tiffvers.h . I'm not sure what the other 8 are used for, but I put all 12 in the standard OpenPKG include directory. You may prefer to only put the 4 major header files there and leave the other 8 in the tiff subdirectory. The same change may need to be applied to your newer v3.6.1 package. And as you can see, I am not on OpenPKG 2.0 yet, so the spec files also reflect that. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
RE: emacs, giflib, and tiff contributions
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralf S. Engelschall Sent: Tuesday, March 02, 2004 2:48 PM To: [EMAIL PROTECTED] Subject: Re: emacs, giflib, and tiff contributions On Tue, Mar 02, 2004, Dennis McRitchie wrote: 3) tiff: emacs looks for tiff header files in specified include directories only. Since the OpenPKG tiff package put them in a tiff subdirectory within the OpenPKG include directory, they were not found by emacs and therefore not used. Note that both the RedHat 9 package and the sunfreeware package places them in /usr/include and /usr/local/include respectively, where they can be found by emacs. So I changed the package to place them where they are needed. I saw that you provide 12 header files while the RedHat 9 and sunfreeware packages only provide 4: tiff.h, tiffconf.h, tiffio.h, and tiffvers.h . I'm not sure what the other 8 are used for, but I put all 12 in the standard OpenPKG include directory. You may prefer to only put the 4 major header files there and leave the other 8 in the tiff subdirectory. The same change may need to be applied to your newer v3.6.1 package. [...] Err... this then might fix Emacs but will perhaps breaks lots of other packages which search explicitly for Tiff in the subdir. Best is to fix Emacs here also to search it in the subdir. How can this be achieved? I can look into that, but before I do, are you sure that this will break other packages? As I wrote, neither the Redhat 9's libtiff-devel-3.5.7-11.i386.rpm nor Sunfreeware's tiff-3.6.1-sol9-sparc-local.gz packages install their 4 header files in a tiff subdirectory. In fact I just went to the libtiff.org website and downloaded their v3.6.1 tarball, and it installs its header files into /usr/local/include by default. Also, their documentation shows that to compile a program with tiff, you should use #include tiffio.h, not #include tiff/tiffio.h. And emacs is a popular editor that has been ported to many OSs. It would be surprising to hear that it is looking for tiff in the wrong place all this time. Perhaps there are others, but the only context I was able to find where apps looked for tiff header files in a TIFF subdirectory was with users of ivtools. Ivtools (optionally?) includes the tiff package within it, and then installs the tiff header files in a TIFF subdirectory. But the regular tiff package does not do this, so I don't believe that apps using the tiff package without ivtools would be looking in a subdirectory for the header files. So I'm confused why you think many programs would be looking for those headers in a tiff subdirectory. Even if you're right, I have to believe that on RedHat 9 and Solaris 9 systems that most programs there would be looking for them in an include dir, not a tiff subdir, since that is where their *binary* packages install the tiff header files. If these are needed in both places in OpenPKG (due to multi-OS support?), then perhaps the 4 main header files should be copied to both the include dir and the tiff subdir, rather than try to change every package that is looking in what is surely the standard tiff header directory on RedHat and Solaris. Dennis __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
freetds v0.62.1 package submission
Hi,
I have uploaded freetds-0.62.1-20040211.src.rpm to the openpkg.org upload
site for your consideration.
The package has been built and tested on Solaris 9 and RedHat Linux 9.
The spec file was based on a contribution from Steffen Weinreich. I have
changed it in the following ways:
1) Upgraded to freetds 0.62.1
2) Added a patch to fix a build problem (caused by library order on ld
command line) that affected both Solaris 9 and RedHat Linux 9.
3) Changed two Makefile.in's to build its 3 utilities (tsql, freebcp, and
tdspool) with static libraries.
4) Some minor edits to clean up.
It is configured to work with the OpenPKG unixodbc package almost out of the
box, except as follows.
%{l_prefix}/etc/unixodbc/odbcinst.ini needs the following contents:
[TDS]
Description = v0.62.1 with protocol 7.0
Driver = %{l_prefix}/lib/libtdsodbc.so
FileUsage = 1
where %{l_prefix} has been appropriately substituted.
And of course, each user needs to fill in their .odbc.ini file to identify
their database.
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
New oracle-barebone submission
Resend since [EMAIL PROTECTED] is down.
Dennis
-Original Message-
From: Dennis McRitchie [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 4:54 PM
To: '[EMAIL PROTECTED]'
Subject: New oracle-barebone submission
I have just uploaded oracle-barebone-9.2.0.1-20040128.nosrc.rpm to the
contrib area.
The only change from the previous version is a critical documentation change
to oracle-barebone.txt: The new instructions now state in part:
3. Also create an empty directory /oracle/OracleHome on the target machine,
also owned by oracle/oracle. Then create a symbolic link to it from
%{l_prefix}/share/oracle-barebone, e.g.,
ln -s /oracle/OracleHome %{l_prefix}/share/oracle-barebone
The user is then instructed to use this symbolic link as the path to use
when installing Oracle 9i, instead of using /oracle/OracleHome.
The reason for this change is that libclntsh.so is created at install time
(by genclntsh), and records the current ORACLE_HOME as the RPATH to use when
loading for libwtc9.so at run time. Both files are subsequently moved to
%{l_prefix}/share/oracle-barebone. Furthermore, in programs such as the
DBD::Oracle sub-module within the perl-dbi module, when Oracle.so is built,
libclntsh.so is explicitly specified, but libwtc9.so is not. It is assumed
that ORACLE_HOME will not have changed once Oracle 9i has been installed. So
when Oracle.so is subsequently loaded, the ldd (dynamic loader) on Solaris
can't find libwtc9.so once it has been moved to
%{l_prefix}/share/oracle-barebone. (The dynamic loader on Red Hat Linux 9
also looks in /oracle/OracleHome, but if it does not find it there, it then
looks in %{l_prefix}/share/oracle-barebone. So DBD::Oracle works on Linux,
but it would be safer if the dynamic loader did not look in
/oracle/OracleHome at all.)
The advantage of changing things in oracle-barebone rather than in perl-dbi
is that all users of libclntsh.so will benefit automatically.
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
RE: New oracle-barebone submission
Ralf,
Depends on how you define universal :-). My solution is universal in that
it allows all packages that use oracle-barebone to work flawlessly without
change (albeit for one %{l_prefix}). Yours only allows DBD::Oracle to work
with oracle-barebone.
Nonetheless, I agree that this is a drawback to my method. The problem is
that the oracle-barebone [no]src rpm package - unlike most of your src
packages - does not actually *build* anything: it just install files. All
the building is done when Oracle 9i is originally installed. In theory, if
there were a way to package the Oracle Universal Installer as part of the
oracle-barebone package, you could build and install it wherever you wanted.
Also, since this is a nosrc package, the package - as provided by OpenPKG -
can indeed be installed wherever you want. You merely have to use an
appropriate oracle bz2 file for the build of the nosrc package that you
are doing at the moment. And since we distribute only binary rpm's here,
they can only be installed in the designated %{l_prefix} anyway. In other
words, it is only a problem if you actually create a true src rpm (with both
bz2 files included), and you want to be able to build that package for any
%{l_prefix}.
So while I understand your desire to adhere to your package design
philosophy (install anywhere - even with a src package that *doesn't*
build from source), in this case my concern with patching DBD::Oracle (as
well as all other packages that use oracle-barebone) is that the scope of
the problem is unknown (how many packages might be affected?), and I may not
discover this type of problem until it is too late. For example, in our
case, the problem was not detected until a user tried running the new
DBD::Oracle from a machine that did not happen to have a non-OpenPKG Oracle
client installed. And since we're also deploying installed packages to our
entire user community, stability and predictability is very important to us.
So I think we'll be safer to stick with my method for now.
Just FYI, the preferred way to patch DBD::Oracle is to modify the
Makefile.PL. This will involve writing some Perl code - after the script has
discovered the Oracle OCI build rules - to test for the Oracle version and
the OS, and replace -lclntsh with -lclntsh -lwtc9. [I notice that your
oracle import package creates an rc.oracle file with the line
'oracle_libs=-lclntsh -lwtc9'. Is there a way to use that as part of this
patch?]
BTW, do you have a sense of how many packages you are currently supporting
(or planning to support in the near future) that could be made to rely on
oracle-barebone?
Thanks,
Dennis
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ralf S.
Engelschall
Sent: Friday, January 30, 2004 10:43 AM
To: [EMAIL PROTECTED]
Subject: Re: New oracle-barebone submission
On Fri, Jan 30, 2004, Dennis McRitchie wrote:
I have just uploaded
oracle-barebone-9.2.0.1-20040128.nosrc.rpm to the
contrib area.
The only change from the previous version is a critical
documentation
change to oracle-barebone.txt: The new instructions now
state in part:
3. Also create an empty directory /oracle/OracleHome on the
target machine,
also owned by oracle/oracle. Then create a symbolic link
to it from
%{l_prefix}/share/oracle-barebone, e.g.,
ln -s /oracle/OracleHome %{l_prefix}/share/oracle-barebone
The user is then instructed to use this symbolic link as
the path to
use when installing Oracle 9i, instead of using /oracle/OracleHome.
The reason for this change is that libclntsh.so is created
at install
time (by genclntsh), and records the current ORACLE_HOME as
the RPATH
to use when loading for libwtc9.so at run time. Both files are
subsequently moved to %{l_prefix}/share/oracle-barebone.
Furthermore,
in programs such as the DBD::Oracle sub-module within the perl-dbi
module, when Oracle.so is built, libclntsh.so is explicitly
specified,
but libwtc9.so is not. It is assumed that ORACLE_HOME will not have
changed once Oracle 9i has been installed. So when Oracle.so is
subsequently loaded, the ldd (dynamic loader) on Solaris can't find
libwtc9.so once it has been moved to
%{l_prefix}/share/oracle-barebone. (The dynamic loader on Red Hat
Linux 9 also looks in /oracle/OracleHome, but if it does
not find it
there, it then looks in %{l_prefix}/share/oracle-barebone. So
DBD::Oracle works on Linux, but it would be safer if the dynamic
loader did not look in /oracle/OracleHome at all.)
The advantage of changing things in oracle-barebone rather than in
perl-dbi is that all users of libclntsh.so will benefit
automatically.
Yes, but is implies that you build the oracle-barebone only
for your particular %{l_prefix}. Once you build it for a
different one you again went into trouble. And OpenPKG is
about we allow installating into arbitrary filesystem
areas
[OpenPKG #310] New oracle-barebone submission
Request 310 was acted upon. _ URL: https://rt.openpkg.org/id/310 Ticket: [OpenPKG #310] Subject: New oracle-barebone submission Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Correspondence added by [EMAIL PROTECTED] Time: Wed Jan 14 15:59:03 2004 One more thing that I think should be done to this package, but that I did not do: I believe that this package should be changed to provide ORACLE, and that it should become mutually exclusive of the OpenPKG oracle package. Also, the latter's functionality I think really belongs in openpkg-import. Dennis -Original Message- From: The OpenPKG Project [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 4:01 PM To: [EMAIL PROTECTED] Subject: [OpenPKG #310] New oracle-barebone submission This message has been automatically generated in response to the creation of your OpenPKG request ticket regarding: New oracle-barebone submission There is no need to reply to this message right now. Your ticket has been assigned an ID of [OpenPKG #310]. Please include the string [OpenPKG #310] in the subject line of all future correspondence about this issue. To do so, you may just reply to this message. You can also find your OpenPKG request ticket under the URL https://rt.openpkg.org/id/310 OpenPKG Request Tracker (RT) [EMAIL PROTECTED] https://rt.openpkg.org/ __ ___ URL: https://rt.openpkg.org/id/310 Ticket: [OpenPKG #310] Subject: New oracle-barebone submission Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Tue Jan 13 22:00:49 2004 __ ___ I have just uploaded oracle-barebone-9.2.0.1-20040113.nosrc.rpm to the contrib area. Changes are as follows: 1) oracle-barebone.spec: Conditional code to preserve any tnsnames.ora or sqlnet.ora present in .../network/admin/ instead of unconditionally overwriting them with the versions in .../network/admin/samples/. This is useful if - after installing the Oracle client SW in /oracle/OracleHome - we want to be able to store a default tnsnames.ora or sqlnet.ora in /oracle/OracleHome/network/admin/ that is intended to be automatically installed from the binary RPM created by oracle-barebone. 2) oracle-barebone.pl: Added files to the file list so that files in /oracle/OracleHome/network/admin/ would be copied to the bz2 file, and added directories that were previously being created implicitly by cpio at unpacking time. The absence of these directories in the list (e.g., bin and oracore) resulted in inappropriate permissions being set in some cases when the directory was later created by cpio, sometimes causing the files to be unreadable by group and other. 3) oracle-barebone.txt: Changed the solaris gz file names to be those of the 32-bit Oracle download. Created steps 5-7 to be more explicit about what needs to be done at the end. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
--provides option inconsistent with spec file defaults
If src and binary rpm files are built (via rpm -ba) with some build options explicitly turned on, the src rpm subsequently reports these options as on (via rpm -qpi or rpm -qp --provides) even though the spec file has them defaulted to off. Case in point: I started with perl-dbi-20040108-20040108.src.rpm as my base package. rpm -qip --provides reports all options turned off: rpm -qip --provides perl-dbi-20040108-20040108.src.rpm Name: perl-dbi Relocations: (not relocateable) Version : 20040108 Vendor: Perl Community Release : 20040108 Build Date: Thu Jan 8 15:09:03 2004 Install Date: (not installed) Build Host: dv1.dev.de.cw.net Group : Language Source RPM: (none) Size: 1295730 License: GPL/Artistic Signature : (none) Packager: The OpenPKG Project URL : http://www.cpan.org/ Summary : Perl Modules for use with DBI API Description : Various modules for using the DBI API of Perl: - DBI (1.40) - SQL::Statement (1.005) - DBD::AnyData (0.06) - DBD::Sprite (0.47) - DBD::SQLite (0.29) - DBD::mysql (2.9003) [no] - DBD::Pg (1.31) [no] - DBD::Oracle (1.14) [no] - DBD::ODBC (1.06) [no] perl-dbi::with_dbd_mysql = no perl-dbi::with_dbd_pg = no perl-dbi::with_dbd_oracle = no perl-dbi::with_dbd_odbc = no I then installed the source package, made some changes to the spec file (though not to the option defaults), and rebuilt it with the following command: rpm -ba perl-dbi.spec --define with_dbd_oracle yes --define with_dbd_odbc yes Now executing rpm -qip --provides on the resulting src rpm yields the following: rpm -qip --provides perl-dbi-20040114-20040114.src.rpm Name: perl-dbi Relocations: (not relocateable) Version : 20040114 Vendor: Perl Community Release : 20040114 Build Date: Wed Jan 14 15:55:36 2004 Install Date: (not installed) Build Host: geraldine.Princeton.EDU Group : Language Source RPM: (none) Size: 1295757 License: GPL/Artistic Signature : (none) Packager: The OpenPKG Project URL : http://www.cpan.org/ Summary : Perl Modules for use with DBI API Description : Various modules for using the DBI API of Perl: - DBI (1.40) - SQL::Statement (1.005) - DBD::AnyData (0.06) - DBD::Sprite (0.47) - DBD::SQLite (0.29) - DBD::mysql (2.9003) [no] - DBD::Pg (1.31) [no] - DBD::Oracle (1.14) [yes] - DBD::ODBC (1.06) [yes] perl-dbi::with_dbd_mysql = no perl-dbi::with_dbd_pg = no perl-dbi::with_dbd_oracle = yes perl-dbi::with_dbd_odbc = yes There are also a few packages on the openpkg ftp site that show this problem: openpkg-import-20031027-20031027.src.rpm perl-dbi-20031129-20031129.src.rpm (now obsolete) I think that the src rpm should only report the spec file option defaults, and not the set of options that the binary rpm was built with. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #309] perl-dbi now broken on Solaris due to recent change
Request 309 was acted upon.
_
URL: https://rt.openpkg.org/id/309
Ticket: [OpenPKG #309]
Subject: perl-dbi now broken on Solaris due to recent change
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: Nobody
Status: open
Transaction: Correspondence added by [EMAIL PROTECTED]
Time: Tue Jan 13 19:58:02 2004
Hi Ralf,
Thanks for the explanation. I now understand the rationale, but...
That it worked before for you (and also for us) is because
the DBD::Oracle was different in the past and because you
certainly used a full-featured Oracle installation (where
demo_rdbms32.mk existed).
...The DBD::Oracle I am using is the one from the 2003/11/29 package, which
is the same as the one in the 20040108 package: v1.14. And the
oracle-barebone that I built and used did not install demo_rdbms32.mk. Yet,
DBD::Oracle works fine for me on Solaris when it was built using
demo_rdbms.mk.
Under Solaris I was unable to get all those files by doing a
plain Oracle 9i Client Installation, including a Custom
one. For getting the remaining files (including
demo_rdbms32.mk) I had to (believe it or not) install the
Oracle database server. The reason is that the Oracle Call
Interfaces (OCI) are part of the database server instead of
the client. Interestingly, the same Oracle version has OCI
part of the client under Linux! Just under Solaris the OCI
stuff is part of the database server.
Actually, in my case I found the OCI stuff under Oracle Client for both the
Linux and Solaris installations. Upon taking a closer look, I now realize
that I have been installing Oracle9i Database Release 2 Enterprise/Standard
Edition for Sun SPARC Solaris (32-bit), rather than Oracle9i Database
Release 2 Enterprise Edition for Sun SPARC Solaris (64-bit) as instructed
by the oracle-barebone documentation.
Since you want to use the 32-bit libraries anyway, wouldn't it be easier to
use the 32-bit download? Solaris 8 and 9 support it, and then there would be
no need to install the entire database server nor a need for the spec file
patch that forces the use of demo_rdbms32.mk.
In my case the resulting oracle-barebone file sizes are:
-rw-rw-r-- 1 psr psr 24650873 Jan 7 17:14
oracle-barebone-9.2.0.1.ix86-linux.cpio.bz2
-rw-rw-r-- 1 psr psr 27713659 Jan 8 11:35
oracle-barebone-9.2.0.1.sparc64-solaris.cpio.bz2
Note how much smaller my Solaris file is compared to yours.
Dennis
-Original Message-
From: Ralf S. Engelschall via RT [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 13, 2004 3:10 AM
To: [EMAIL PROTECTED]
Subject: [OpenPKG #309] perl-dbi now broken on Solaris due to
recent change
Request 309 was acted upon.
__
___
URL: https://rt.openpkg.org/id/309
Ticket: [OpenPKG #309]
Subject: perl-dbi now broken on Solaris due to recent change
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: Nobody
Status: open
Transaction: Correspondence added by rse
Time: Tue Jan 13 09:10:16 2004
__
___
On Mon, Jan 12, 2004, Dennis McRitchie via RT wrote:
Using perl-dbi-20031129-20031129.src.rpm, I was able to build
DBD::Oracle on Solaris 9. However, using
perl-dbi-20040108-20040108.src.rpm, the build blew up. The
problem is
due to these recently added lines to the spec file:
case %{l_platform -t} in
i?86-linux* )
;;
sun*-sunos* )
# OpenPKG builds with gcc in 32-bit mode by default
%{l_shtool} subst \
-e 's;demo_rdbms\.mk;demo_rdbms32.mk;g' \
Makefile.PL
;;
* )
echo Platform \%{l_platform -t}\ not
supported 12
exit 1
;;
esac
So the DBD:Oracle makefile is now looking for
demo_rdbms32.mk rather
than demo_rdbms.mk on Solaris. The problem is that when I build the
oracle-barebone package using Oracle 9.2.0.1, demo_rdbms.mk is
present, but not demo_rdbms32.mk. Hence this spec file
works on Linux,
and older perl-dbi packages work on Solaris, but the new
spec file now
breaks on Solaris.
I searched the cvs repository for perl-dbi so I could try to figure
out the reason for this change, and I could not find this change.
Also, there are problems with the perl-dbi checkins since
2003/11/29:
[...] So why was this change made?
Because our OpenPKG gcc produces by default (unless you use
-m64) 32 bit binaries under Solaris. Hence we have to link in
the 32-bit Oracle libraries, too.
That it worked before for you (and also for us) is because
[OpenPKG #310] New oracle-barebone submission
Request 310 was acted upon. _ URL: https://rt.openpkg.org/id/310 Ticket: [OpenPKG #310] Subject: New oracle-barebone submission Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Tue Jan 13 22:00:49 2004 _ I have just uploaded oracle-barebone-9.2.0.1-20040113.nosrc.rpm to the contrib area. Changes are as follows: 1) oracle-barebone.spec: Conditional code to preserve any tnsnames.ora or sqlnet.ora present in .../network/admin/ instead of unconditionally overwriting them with the versions in .../network/admin/samples/. This is useful if - after installing the Oracle client SW in /oracle/OracleHome - we want to be able to store a default tnsnames.ora or sqlnet.ora in /oracle/OracleHome/network/admin/ that is intended to be automatically installed from the binary RPM created by oracle-barebone. 2) oracle-barebone.pl: Added files to the file list so that files in /oracle/OracleHome/network/admin/ would be copied to the bz2 file, and added directories that were previously being created implicitly by cpio at unpacking time. The absence of these directories in the list (e.g., bin and oracore) resulted in inappropriate permissions being set in some cases when the directory was later created by cpio, sometimes causing the files to be unreadable by group and other. 3) oracle-barebone.txt: Changed the solaris gz file names to be those of the 32-bit Oracle download. Created steps 5-7 to be more explicit about what needs to be done at the end. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #309] perl-dbi now broken on Solaris due to recent change
Request 309 was acted upon.
_
URL: https://rt.openpkg.org/id/309
Ticket: [OpenPKG #309]
Subject: perl-dbi now broken on Solaris due to recent change
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: Nobody
Status: new
Transaction: Ticket created by [EMAIL PROTECTED]
Time: Mon Jan 12 15:57:15 2004
_
Using perl-dbi-20031129-20031129.src.rpm, I was able to build DBD::Oracle on
Solaris 9. However, using perl-dbi-20040108-20040108.src.rpm, the build blew
up. The problem is due to these recently added lines to the spec file:
case %{l_platform -t} in
i?86-linux* )
;;
sun*-sunos* )
# OpenPKG builds with gcc in 32-bit mode by default
%{l_shtool} subst \
-e 's;demo_rdbms\.mk;demo_rdbms32.mk;g' \
Makefile.PL
;;
* )
echo Platform \%{l_platform -t}\ not supported 12
exit 1
;;
esac
So the DBD:Oracle makefile is now looking for demo_rdbms32.mk rather than
demo_rdbms.mk on Solaris. The problem is that when I build the
oracle-barebone package using Oracle 9.2.0.1, demo_rdbms.mk is present, but
not demo_rdbms32.mk. Hence this spec file works on Linux, and older perl-dbi
packages work on Solaris, but the new spec file now breaks on Solaris.
I searched the cvs repository for perl-dbi so I could try to figure out the
reason for this change, and I could not find this change. Also, there are
problems with the perl-dbi checkins since 2003/11/29:
1) Check-in [13667]
upgrading package: perl-dbi 20031129 - 20031205
[This one is OK and does not contain the change]
2) Check-in [14091]
upgrading package: perl-dbi 20031230 - 20040108
[This one internally shows a version change from 2003/12/05 to 2004/01/08,
but still does not contain the change.]
3) Check-in [14092]
upgrading package: perl-dbi 20031230 - 20040108
[This one internally shows a version change from 2003/12/30 to 2004/01/08,
but still does not contain the change.]
So ticket 14091 is incorrectly labeled and conflicts with 14092, and none
show the change containing the new lines above.
So why was this change made?
Thanks,
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
[OpenPKG #304] Fatal error using openpkg tool
Request 304 was acted upon. _ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: open Transaction: Correspondence added by [EMAIL PROTECTED] Time: Mon Dec 22 17:12:16 2003 You're right. The default in the spec file for openpkg-import-20031027-20031027.src.rpm is: # package options %option with_mta no So one minor mystery (that I'll ask about in another thread) is why rpm -qp --provides returns: rpm -qp --provides openpkg-import-20031027-20031027.src.rpm openpkg-import::with_mta = yes openpkg-import::with_mta_path = sendmail MTA In any event, I have attached my .openpkg/build file so you can see how I am turning on with_mta. Thanks, Dennis -Original Message- From: Michael van Elst via RT [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 4:50 PM To: [EMAIL PROTECTED] Subject: [OpenPKG #304] Fatal error using openpkg tool Request 304 was acted upon. __ ___ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: open Transaction: Correspondence added by mlelstv Time: Fri Dec 19 22:49:56 2003 __ ___ On Fri, Dec 19, 2003 at 10:15:37PM +0100, Dennis McRitchie via RT wrote: My index file does seem to have the expected info you describe. One odd thing though - which perhaps relates to the problem - is that the index file states: resource equ=noopenpkg-import::with_mta/resource The index stores the default setting of the option, which is no. So at least that is correct :) -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. build Description: Binary data
[OpenPKG #305] rpm --provides gives incorrect info for openpkg-import
Request 305 was acted upon. _ URL: https://rt.openpkg.org/id/305 Ticket: [OpenPKG #305] Subject: rpm --provides gives incorrect info for openpkg-import Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Mon Dec 22 17:22:14 2003 _ When I run rpm -qp --provides on openpkg-import-20031027-20031027.src.rpm, I get the following: rpm -qp --provides openpkg-import-20031027-20031027.src.rpm openpkg-import::with_mta = yes openpkg-import::with_mta_path = sendmail MTA Yet, if I do and rpm -i on it and look at the spec file, I see: # package options %option with_mta no Yet this same command on openssh-3.6.1p2-1.3.2.src.rpm yields: rpm -qp --provides openssh-3.6.1p2-1.3.2.src.rpm openssh::with_fsl = yes openssh::with_pam = no openssh::with_pcre = no openssh::with_skey = no openssh::with_x11 = no openssh::with_chroot = no This does match the spec file. So why is the output incorrect for openpkg-import? Thanks, Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #304] Fatal error using openpkg tool
Request 304 was acted upon. _ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Fri Dec 19 17:43:09 2003 _ I'm having another problem using openpkg tool: My command line is: openpkg build -R /usr/psr/bin/rpm -r /usr/psr.devel/SRPMS.orig/ -f /usr/psr.devel/SRPMS.orig/00INDEX.rdf -A /usr/psr.devel/redhat9/buildrh9.sh The result is: FATAL: errors occurred while building: pine-4.58L-20031024: pine searches a frood called 'MTA' The buildrh9.sh output file is attached. From looking at it, it looks like it resolves MTA (from openpkg-import) first and adds it to the list. Then it resolves pine (by looking for MTA) and adds it to the list. Then sometime later it aborts as shown above. My repository has 71 source rpm files, the openpkg source shell script, and the rdf file. Any ideas as to what to do? Also, I still haven't heard any resolution about bug report #284. Is this being worked on or do you need more info from me about it? In that case, openpkg tool was producing quite inconsistent (and wrong) output when build options had been changed since the last run of the tool. I would like to use this tool routinely, but don't currently have a lot of confidence in it. I know it's not good practice to discuss more than one problem in an email, but I sent in a reminder message about 284 the proper way on Dec 2 and never heard back. Thanks, Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #304] Fatal error using openpkg tool
Request 304 was acted upon. _ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Correspondence added by [EMAIL PROTECTED] Time: Fri Dec 19 17:45:55 2003 Sorry, I forgot to attach the openpkg tool output file. Dennis -Original Message- From: The OpenPKG Project [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 11:43 AM To: [EMAIL PROTECTED] Subject: [OpenPKG #304] Fatal error using openpkg tool This message has been automatically generated in response to the creation of your OpenPKG request ticket regarding: Fatal error using openpkg tool There is no need to reply to this message right now. Your ticket has been assigned an ID of [OpenPKG #304]. Please include the string [OpenPKG #304] in the subject line of all future correspondence about this issue. To do so, you may just reply to this message. You can also find your OpenPKG request ticket under the URL https://rt.openpkg.org/id/304 OpenPKG Request Tracker (RT) [EMAIL PROTECTED] https://rt.openpkg.org/ __ ___ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Fri Dec 19 17:43:09 2003 __ ___ I'm having another problem using openpkg tool: My command line is: openpkg build -R /usr/psr/bin/rpm -r /usr/psr.devel/SRPMS.orig/ -f /usr/psr.devel/SRPMS.orig/00INDEX.rdf -A /usr/psr.devel/redhat9/buildrh9.sh The result is: FATAL: errors occurred while building: pine-4.58L-20031024: pine searches a frood called 'MTA' The buildrh9.sh output file is attached. From looking at it, it looks like it resolves MTA (from openpkg-import) first and adds it to the list. Then it resolves pine (by looking for MTA) and adds it to the list. Then sometime later it aborts as shown above. My repository has 71 source rpm files, the openpkg source shell script, and the rdf file. Any ideas as to what to do? Also, I still haven't heard any resolution about bug report #284. Is this being worked on or do you need more info from me about it? In that case, openpkg tool was producing quite inconsistent (and wrong) output when build options had been changed since the last run of the tool. I would like to use this tool routinely, but don't currently have a lot of confidence in it. I know it's not good practice to discuss more than one problem in an email, but I sent in a reminder message about 284 the proper way on Dec 2 and never heard back. Thanks, Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University buildrh9.sh Description: Binary data
[OpenPKG #304] Fatal error using openpkg tool
Request 304 was acted upon. _ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: open Transaction: Correspondence added by [EMAIL PROTECTED] Time: Fri Dec 19 18:40:50 2003 Well, the log does contain the following lines: # source for openpkg-import::with_mta is openpkg-import-20031027-20031027 # source for openpkg-import::with_mta_path is openpkg-import-20031027-20031027 The repository (and therefore presumably the index) includes this file. When I run rpm -qp --provides on it I get: rpm -qp --provides openpkg-import-20031027-20031027.src.rpm openpkg-import::with_mta = yes openpkg-import::with_mta_path = sendmail MTA And I also have a build file in ~/.openpkg that includes the line: -Dopenpkg-import::with_mta Since according to you the log says that openpkg tool can't find MTA, then why can't it? It is present in my repository, and openpkg tool has apparently found the src rpm file that provides MTA. Thanks, Dennis P.S. Is frood the German word for friend? :-) -Original Message- From: Michael van Elst via RT [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: [OpenPKG #304] Fatal error using openpkg tool Request 304 was acted upon. __ ___ URL: https://rt.openpkg.org/id/304 Ticket: [OpenPKG #304] Subject: Fatal error using openpkg tool Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: open Transaction: Correspondence added by mlelstv Time: Fri Dec 19 18:24:59 2003 __ ___ On Fri, Dec 19, 2003 at 05:43:11PM +0100, Dennis McRitchie via RT wrote: The buildrh9.sh output file is attached. From looking at it, it looks like it resolves MTA (from openpkg-import) first and adds it to the list. According to the log it doesn't. There is no package that provides 'MTA'. Also, I still haven't heard any resolution about bug report #284. Is this being worked on or do you need more info from me about it? I currently have no system running OpenPKG as the bootstrap broke for NetBSD after switching to rpm4.2.1. I'll see if I can set up a Linux system this weekend. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #302] Continuing problems building perl-tk
/has_jpeg.c
Writing Makefile for Tk::PNG
^^
Since the warning says to please inform the author, I thought I would pass
it on in case you had not already noticed it.
Dennis
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dennis McRitchie
Sent: Tuesday, October 28, 2003 3:46 PM
To: [EMAIL PROTECTED]
Subject: Problem building perl-tk on Solaris 9
I tried to build first perl-tk-1.3.0-1.3.0.src.rpm and - when
that failed - then perl-tk-20031027-20031027.src.rpm.
They both failed the same way:
Writing
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/auto/Tk/.packlist
+ cd Tk-TIFF-0.08
+ /usr/psr.oit/solaris9/lib/openpkg/shtool subst -e
's;-I/usr/local/include;-I/usr/psr.oit/solaris9/include/tiff
-I/usr/psr.oit/ solaris9/include;' -e
's;-L/usr/local/lib;-L/usr/psr.oit/solaris9/lib;'
Makefile.PL
+ /usr/psr.oit/solaris9/bin/perl-openpkg install
perl-openpkg: determine build parameters
perl-openpkg: configuring Perl module
Can't locate Tk/Event.pm in @INC (@INC contains:
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/5.8.1/sun4-solaris
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/5.8.1
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1
/usr/psr.oit/solaris9/lib/perl/site_perl/5.8.1/sun4-solaris
/usr/psr.oit/solaris9/lib/perl/site_perl/5.8.1
/usr/psr.oit/solaris9/lib/perl/site_perl
/usr/psr.oit/solaris9/lib/perl/vendor_perl/5.8.1/sun4-solaris
/usr/psr.oit/solaris9/lib/perl/vendor_perl/5.8.1
/usr/psr.oit/solaris9/lib/perl/vendor_perl
/usr/psr.oit/solaris9/lib/perl/5.8.1/sun4-solaris
/usr/psr.oit/solaris9/lib/perl/5.8.1 .) at
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/Tk.pm line 13.
Tk::BEGIN() called at Tk/Event.pm line 13
eval {...} called at Tk/Event.pm line 13
require Tk.pm called at Makefile.PL line 4
main::BEGIN() called at Tk/Event.pm line 13
eval {...} called at Tk/Event.pm line 13
BEGIN failed--compilation aborted at
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/Tk.pm line 13.
require Tk.pm called at Makefile.PL line 4
main::BEGIN() called at
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/Tk.pm line 13
eval {...} called at
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/Tk.pm line 13
Compilation failed in require at Makefile.PL line 4.
main::BEGIN() called at
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/Tk.pm line 4
eval {...} called at
/usr/psr.oit/solaris9/RPM/TMP/perl-tk-20031027-root/usr/psr.oi
t/solaris9/lib
/perl/site_perl/5.8.1/sun4-solaris/Tk.pm line 4
BEGIN failed--compilation aborted at Makefile.PL line 4.
perl-openpkg: building Perl module
make: *** No rule to make target `pure_all'. Stop.
perl-openpkg: installing Perl module
make: *** No rule to make target `pure_install'. Stop.
+ exit 2
error: Bad exit status from
/usr/psr.oit/solaris9/RPM/TMP/rpm-tmp.14762
(%install) ^
The complete build output is attached.
I was able to build perl-tk-20031027-20031027.src.rpm
successfully on RedHat 9, and needless to say, the build
outputs - while not completely identical up to that point -
diverge sharply at the point where the error occurs on
Solaris 9, as shown below:
vvv
Writing
/usr/psr.oit/redhat9/RPM/TMP/perl-tk-20031027-root/usr/psr.oit
/redhat9/lib/p
erl/site_perl/5.8.1/i686-linux/auto/Tk/.packlist
+ cd Tk-TIFF-0.08
+ /usr/psr.oit/redhat9/lib/openpkg/shtool subst -e
's;-I/usr/local/include;-I/usr/psr.oit/redhat9/include/tiff
-I/usr/psr.oit/r edhat9/include;' -e
's;-L/usr/local/lib;-L/usr/psr.oit/redhat9/lib;'
Makefile.PL
+ /usr/psr.oit/redhat9/bin/perl-openpkg install
perl-openpkg: determine build parameters
perl-openpkg: configuring Perl module
/usr/psr.oit/redhat9/RPM/TMP/perl-tk-20031027/Tk-TIFF-0.08
does not start with
/usr/psr.oit/redhat9/RPM/TMP/perl-tk-20031027-root/usr/psr.oit
/redhat9/lib/p
RE: tcpwrappers
What is the RBL patch, and what are the consequences of not having it? Where can I get more information about it? Thanks, Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralf S. Engelschall Sent: Friday, October 31, 2003 3:48 PM To: [EMAIL PROTECTED] Subject: Re: tcpwrappers On Fri, Oct 31, 2003, Bill Campbell wrote: Is anybody working on tcpwrappers for Solaris ? I got it to compile, but it does not work as expected, so one needs to do some debugging. I'm going to do this, when nobody speeks up. I haven't tried it, but do know that there was a bigendian issue with the RBL patch to tcp_wrappers. For those and similar reasons I've not included the RBL patch in our tcpwrappers package for now. But anyway, what patches for Solaris are available? Perhaps we can already start including those... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Error replying to an Openpkg ticket
Why did I get the message below in connection with my reply to Michael's
comment? My original message, as returned by the OpenPKG server, is
attached.
Dennis
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 11:13 AM
To: [EMAIL PROTECTED]
Subject: Message not recorded
Permission Denied
Ah! I got it now. My mistake was assuming that Matthias' changes had been
incorporated in the tcpwrappers I downloaded yesterday; but I now see that
it is older than Matthias' submission. So I'll add his changes. Thanks
Matthias!
Dennis
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Schloh v. Bennewitz via RT
Sent: Wednesday, December 03, 2003 6:47 AM
To: AdminCc of OpenPKG Ticket #299:
Subject: [OpenPKG #299] Can't compile
tcpwrappers-7.6k-20031021.src.rpm on Solaris 9 [comment]
Request 299 was acted upon.
This is a comment. It is not sent to the Requestor(s).
__
___
URL: https://rt.openpkg.org/id/299
Ticket: [OpenPKG #299]
Subject: Can't compile tcpwrappers-7.6k-20031021.src.rpm
on Solaris 9
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: Nobody
Status: new
Transaction: Comentarios añadidos por ms
Time: Mie. Dic. 03 12:47:12 2003
__
___
More helpful code from Matthias KURZ follows, as found on
http://www.mail-archive.com/openpkg-dev%40openpkg.org/msg11251.html
--
Michael Schloh v. Bennewitz
OpenPKG Developer
[EMAIL PROTECTED]
tcpwrappers
---
- changes to make it compile under Solaris
- changes to let it run on machines that do not have IPv6 enabled
I did not know how to test the TLI part, because i have no
test case. The whole thing (with or without my patches) will
not run on Solaris versions before Solaris 8, i think.
Index: Makefile
===
RCS file: /cvs/opkg/vendor_stuff/tcpwrappers/Makefile,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 Makefile
--- Makefile3 Jan 2003 18:52:40 - 1.1.1.1
+++ Makefile11 Nov 2003 00:18:26 -
@@ -128,12 +128,12 @@
386bsd netbsd bsdos:
@make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
LIBS= RANLIB=ranlib ARFLAGS=rv AUX_OBJ= NETGROUP= TLI= \
- EXTRA_CFLAGS=VSYSLOG= all
+ EXTRA_CFLAGS= VSYSLOG= all
freebsd:
@make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
LIBS= RANLIB=ranlib ARFLAGS=rv AUX_OBJ= NETGROUP= TLI= \
- EXTRA_CFLAGS=VSYSLOG= all
+ EXTRA_CFLAGS=-I. VSYSLOG= all
linux:
@make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR)
STYLE=$(STYLE) \ @@ -183,11 +183,15 @@
# SunOS 5.x is another SYSV4 variant.
sunos5:
- @make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
- LIBS=-lsocket -lnsl RANLIB=echo ARFLAGS=rv VSYSLOG= \
+ @case `uname -r` in \
+5.6) RTLIB=-lposix4;; \
+ *) RTLIB=-lrt;; \
+ esac; \
+ make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
+ LIBS=-lsocket -lnsl $$RTLIB RANLIB=echo ARFLAGS=rv
VSYSLOG= \
NETGROUP=-DNETGROUP AUX_OBJ=setenv.o TLI=-DTLI \
BUGS=$(BUGS) all \
- EXTRA_CFLAGS=-DNEED_SETENV
+ EXTRA_CFLAGS=-DNEED_SETENV -DNEED_GETOPT
# Generic SYSV40
esix sysv4:
Index: fix_options.c
===
RCS file: /cvs/opkg/vendor_stuff/tcpwrappers/fix_options.c,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 fix_options.c
--- fix_options.c 5 Jan 2003 01:27:10 - 1.1.1.1
+++ fix_options.c 11 Nov 2003 00:18:26 -
@@ -47,7 +47,14 @@
clean_exit(request);
}
if (ADDR_FAM(ss) == AF_INET) {
+#if defined(__FreeBSD__) || defined(__sun__)
+unsigned char optbuf[BUFFER_SIZE / 3];
+int optlen;
+struct in_addr dummy;
+unsigned char *ucp;
+#else
struct ip_opts optbuf;
+#endif
char lbuf[BUFFER_SIZE], *lp, *cp;
struct protoent *ip;
int optsize = sizeof(optbuf);
@@ -65,9 +72,15 @@
* here was wrong.
*/
+#if defined(__FreeBSD__) || defined(__sun__)
+#define ADDR_LEN sizeof(dummy.s_addr)
+for (ucp = optbuf + ADDR_LEN; ucp optbuf +
optsize; ucp += optlen) {
+u_char c = ucp[IPOPT_OPTVAL];
+#else
for (i = 0; (void *)optbuf.ip_opts[i] - (void
*)optbuf
optsize; ) {
u_char c = (u_char)optbuf.ip_opts[i];
+#endif
if (c == IPOPT_LSRR || c == IPOPT_SSRR) {
syslog(LOG_WARNING,
refused connect from %s with IP source
routing options, @@ -77,7 +90,17 @@
RE: tcpwrappers
Another question: will the OpenPKG team inform Steve Grubb about the problems found with and patches applied to his code? He indicates in his README file that he will continue to maintain the package until Wietse releases a new version (could be a while!), and that he'd like to know about bugs. My more general question is whether changes accepted by OpenPKG are routinely referred back to the Vendor (for incorporation into their next version), or whether the submitters of the changes need to do this? Thanks, Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis McRitchie Sent: Wednesday, December 03, 2003 11:20 AM To: [EMAIL PROTECTED] Subject: RE: tcpwrappers What is the RBL patch, and what are the consequences of not having it? Where can I get more information about it? Thanks, Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralf S. Engelschall Sent: Friday, October 31, 2003 3:48 PM To: [EMAIL PROTECTED] Subject: Re: tcpwrappers On Fri, Oct 31, 2003, Bill Campbell wrote: Is anybody working on tcpwrappers for Solaris ? I got it to compile, but it does not work as expected, so one needs to do some debugging. I'm going to do this, when nobody speeks up. I haven't tried it, but do know that there was a bigendian issue with the RBL patch to tcp_wrappers. For those and similar reasons I've not included the RBL patch in our tcpwrappers package for now. But anyway, what patches for Solaris are available? Perhaps we can already start including those... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
RE: tcpwrappers
Thanks for the info, Bill.
I take it from your reply (and from not finding any references to RBL in the
original code) that this patch actually creates this previously non-existing
feature?
Where can I find a copy of this patch, should I want to work on the
big-endian problem?
Thanks,
Dennis
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Campbell
Sent: Wednesday, December 03, 2003 2:03 PM
To: [EMAIL PROTECTED]
Subject: Re: tcpwrappers
On Wed, Dec 03, 2003, Dennis McRitchie wrote:
What is the RBL patch, and what are the consequences of not
having it?
Where can I get more information about it?
The RBL patch allows one to specify dnsRBLs (Realtime
Blackhole Lists) in the /etc/hosts.allow file. We used this
extensively with smail-3.2 to block spam. Some entries from
one of our servers:
# this one allows anybody in our white hat list
ALL: {RBL}.whl.celestial.net. : ALLOW
# deny from our local database of people who've tried
cracking # or abusing our ftp servers.
ALL: {RBL}.guardian.celestial.net. : DENY
sendmail,smtpd: {RBL}.dynablock.wirehub.net. : DENY
sendmail,smtpd: {RBL}.sbl.spamhaus.org. : DENY
...
Personally I find the RBL capabilities one of the most useful
features of tcp_wrappers.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc.
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820;
(206) 236-1676
URL: http://www.celestial.com/
``The meek shall inherit the Earth, the rest of us will go to
the stars...''
-Dr. Isaac Asimov
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
[OpenPKG #286] New problem and solution for building pine with LDAP
Request 286 was acted upon. _ URL: https://rt.openpkg.org/id/286 Ticket: [OpenPKG #286] Subject: New problem and solution for building pine with LDAP Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Mon Oct 27 15:03:27 2003 _ I submitted a change to the pine package about 3 weeks ago to support building pine with LDAP on Solaris 9. That was for building with LDAP without sasl. Now that I've built LDAP *with* sasl, pine will no longer build with LDAP on either RedHat 9 or Solaris 9, since it does not know where to find the required sasl libraries. One solution, which I've uploaded to your contrib area (see pine-4.58L-20031024.src.rpm), is to add: ldflags=$ldflags -lsasl2 -ldl conditionally if with_ldap == yes. It would be better, I suppose, to only add the libraries if the LDAP in question was built with sasl, but I don't know any way to detect that. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology 327 87 Prospect 609-258-4612 __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #284] New openpkg-tool problem
Request 284 was acted upon. _ URL: https://rt.openpkg.org/id/284 Ticket: [OpenPKG #284] Subject: New openpkg-tool problem Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: open Transaction: Correspondence added by [EMAIL PROTECTED] Time: Fri Oct 24 15:31:52 2003 Thanks Michael. Since I used the OpenPKG source bootstrap script to build the rpm tool, I never actually used any openpkg rpm file. So my repository contains what I used: openpkg-20031020-20031020.src.sh. What should I put in the repository to eliminate these warnings: 1) The source rpm created by the above shell? 2) The binary rpm created by the above shell? 3) Something else? Thanks, Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael van Elst via RT Sent: Thursday, October 23, 2003 5:22 PM To: AdminCc of OpenPKG Ticket #284: Subject: [OpenPKG #284] New openpkg-tool problem Request 284 was acted upon. _ URL: https://rt.openpkg.org/id/284 Ticket: [OpenPKG #284] Subject: New openpkg-tool problem Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: open Transaction: Correspondence added by mlelstv Time: Thu Oct 23 23:22:00 2003 On Thu, Oct 23, 2003 at 11:06:37PM +0200, Dennis McRitchie via RT wrote: Also, why does the build tool report: # ATTENTION: openpkg has no upgrade path # ATTENTION: OpenPKG has no upgrade path All packages require the OpenPKG property and the openpkg package, but your index does not contain either of these. The build tool warns you that there is no possibility to rebuild (or upgrade) the bootstrap package. -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
[OpenPKG #284] New openpkg-tool problem
Request 284 was acted upon. _ URL: https://rt.openpkg.org/id/284 Ticket: [OpenPKG #284] Subject: New openpkg-tool problem Requestors: [EMAIL PROTECTED] Queue: openpkg Owner: Nobody Status: new Transaction: Ticket created by [EMAIL PROTECTED] Time: Thu Oct 23 23:06:18 2003 _ I am getting inconsistent results when running openpkg build against the same set of source files and same index file. The version of openpkg-tool I am using is openpkg-tool-20030919-20030919.src.rpm. My environment: 1) My own small repository of around 30 packages. 2) Some of these packages had already been installed at the time I ran openpkg build, some not. 3) I have a /.openpkg/build file that contains a number of options that are enabled. 4) Some of the installed packages were originally installed with different options than those now specified in the build configuration file 5) I built my index with: openpkg index -r PSR/Source -o 00INDEX.rdf -i /usr/psr.devel/SRPMS.orig/. 6) I create my build script with: openpkg build -r /usr/psr.devel/SRPMS.orig/ -A buildrh9.sh. If I simply run step 6 over and over, every 3-4 runs, I get a different result. The less frequent result is more correct then the other, but is still not completely correct. Specifically, those packages that are now to be rebuilt with different with_xxx options, are not consistently picked up as candidates for rebuilding, and some are never picked up. See the two attached files. In the one called buildrh9.sh.caughterror, openssh is detected to need rebuilding, but in the other file it is not. And in neither file are openldap or openssl detected as needing rebuilding, though their build options have changed. I had to uninstall those 3 packages to get a correct result from the openpkg tool. I believe that someone reported inconsistent results before, so perhaps this is the same problem. Also, why does the build tool report: # ATTENTION: openpkg has no upgrade path # ATTENTION: OpenPKG has no upgrade path Thanks, Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University buildrh9.sh.didntcatcherror Description: Binary data buildrh9.sh.caughterror Description: Binary data
RE: Release Engineering Preparations for OpenPKG 2.0
Also, if you want to see additional packages rolled or if you would like to have additional build %options or whatever type of change for the OpenPKG 2.0 release, please act _NOW_ and give this feedback to us. Then there is certainly a chance for consideration and perhaps inclusion into the next release. For this just fill out the OpenPKG Community Feedback form under http://www.openpkg.org/feedback.html or at least drop us on [EMAIL PROTECTED] a note. Thanks. Well, since it is the only package we need that you don't have, I'll put in a request for Wietse's TCP Wrapper (ftp://ftp.porcupine.org/pub/security/index.html). Since Wietse has not upgraded the package since 1997 (except for Casper Dik's later IPV6 version), I believe that some of the patches in RH9's tcp_wrappers-7.6-34 package may be needed because they implement a security fix. Thanks for considering this package. Dennis __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
RE: Release Engineering Preparations for OpenPKG 2.0
Although we've still a few important TODO points left before we can make OpenPKG 2.0 (see FIXME entries in http://cvs.openpkg.org/getfile?f=openpkg-re/news.txt), we now have to start fixing all CORE, BASE and PLUS packages in preparation for the OpenPKG 2.0 release engineering phase which will start in November. In checking this out, I found: vvv - Platform Identification: We finally cleaned up the whole platform identification in RPM. ^^^ Is this why I can't install packages built with OpenPKG 1.3.1 using OpenPKG RPM 4.2.1 (as I reported in some previous emails)? e.g., vvv rpm -Uvh openpkg-20031006-20031006.sparc64-solaris2.9-ups.rpm, and got: Preparing...### [100%] package openpkg-20031006-20031006 is intended for a solaris2.9 operating system ^^^ and vvv rpm -Uvh openpkg-20031006-20031006.ix86-linux2.4-upr.rpm, and got: Preparing...### [100%] package openpkg-20031006-20031006 is intended for a linux2.4 operating system ^^^ If so, this seems a steep price to pay for upgrading... Dennis __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
RE: Problem building pine 4.58 on Solaris 9 with LDAP
The problem comes in building on Solaris 9. Openldap's libldap.a calls inet_aton(), which on Solaris resides in /usr/lib/libresolv.so (whereas on RedHat 9 it resides in libc). This is therefore not being automatically picked up by the pine makefile, so specifying -lresolv as part of EXTRALDFLAGS is required to complete the build successfully. (Interestingly, openldap is aware of the -lresolv requirement and uses it to test for the presence of inet_aton() as well as at build time.) I've taken over your LDAP related changes, although in a little bit adjusted way. Especially I had to make the -lresolv part dependent on the Solaris platform, of course. See http://cvs.openpkg.org/chngview?cn=12595 for details. Thanks for your contribution. Glad to help. BTW, although I like your conditional solution better, making -lresolv conditional on Solaris is not actually required since the original OpenLDAP scripts unconditionally use -lresolv on both RedHat and Solaris. But I agree that it is preferred. Dennis Dennis McRitchie Research Academic Applications Support (RAAS) Academic Services Department Office of Information Technology Princeton University __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Problem building pine 4.58 on Solaris 9 with LDAP
We need pine to support both ssl and ldap. So I obtained the pine version
from the openpkg current site (pine-4.58L-20030919.src.rpm) and modified the
spec file to conditionally (with_ldap=yes) support LDAP as shown in the
extract at the bottom of this message.
The problem comes in building on Solaris 9. Openldap's libldap.a calls
inet_aton(), which on Solaris resides in /usr/lib/libresolv.so (whereas on
RedHat 9 it resides in libc). This is therefore not being automatically
picked up by the pine makefile, so specifying -lresolv as part of
EXTRALDFLAGS is required to complete the build successfully. (Interestingly,
openldap is aware of the -lresolv requirement and uses it to test for the
presence of inet_aton() as well as at build time.)
I also added another build option regarding sendmail which you may or may
not want to include. On our systems, sendmail is considered an integral part
of the OS (be it Solaris or Linux) and is installed and configured
appropriately for our mail server on all systems. So we don't want to build
mail clients (such as pine) that default to their own private sendmail.
Rather, we need to build pine so that it points to the OS default sendmail
location. My option (default_sendmail=yes) does this.
Note that everything defaults to the way you had it if no options are
explicitly specified with --define.
I have uploaded the new src rpm (pine-4.58L-20031003.src.rpm) built from the
changed pine.spec to the openpkg upload area for your consideration.
Dennis
# package options
%option with_ssl no
%option with_ldap no
%option default_sendmail no
# list of sources
Source0: ftp://ftp.cac.washington.edu/pine/pine%{V_real}.tar.bz2
Source1: pine.conf.fixed
Source2: pine.conf
# build information
Prefix: %{l_prefix}
BuildRoot:%{l_buildroot}
BuildPreReq: OpenPKG, openpkg = 1.3.1, make, gcc
PreReq: OpenPKG, openpkg = 1.3.1
%if %{default_sendmail} == no
BuildPreReq: MTA
PreReq: MTA
%endif
%if %{with_ssl} == yes
BuildPreReq: openssl
PreReq: openssl
%endif
%if %{with_ldap} == yes
BuildPreReq: openldap
PreReq: openldap
%endif
AutoReq: no
AutoReqProv: no
%description
Pine - a Program for Internet News Email - is a tool for reading,
sending, and managing electronic messages. Pine was developed by
Computing Communications at the University of Washington. Though
originally designed for inexperienced email users, Pine has evolved
to support many advanced features, and an ever-growing number of
configuration and personal-preference options.
%prep
%setup -q -n pine%{V_real}
%build
# determine build platform
OS=
OS_DEP_FILE=
case %{l_platform -t} in
*-freebsd* ) OS=bsf; OS_DEP_FILE=pine/osdep/os-bsf.h ;;
*-linux* ) OS=slx; OS_DEP_FILE=pine/osdep/os-lnx.h ;;
*-sunos5.* ) OS=gs5; OS_DEP_FILE=pine/osdep/os-sol.h ;;
*)
echo Sorry, unsupported architecture '%{l_platform -t}' |
%{l_rpmtool} msg -b -t error 12
exit 1
;;
esac
# adjust paths
PINE_CONF_FIXED=%{l_prefix}/etc/pine/pine.conf.fixed
PINE_CONF=%{l_prefix}/etc/pine/pine.conf
%if %{default_sendmail} == no
SENDMAIL=%{l_prefix}/sbin/sendmail
%endif
%{l_shtool} subst -e s;^\(#define SYSTEM_PINERC_FIXED[]\).*$;\1
\\; -e s;^\(#define SYSTEM_PINERC[ ]\).*$;\1 \\; %if
%{default_sendmail} == no
-e s;^\(#define SENDMAIL[ ]\).*$;\1 \\; %endif
# clean up before building Pine
sh ./build clean
# set up for LDAP if requested
%if %{with_ldap} == yes
mkdir ldap
ln -s %{l_prefix}/include ldap/include
ln -s %{l_prefix}/lib ldap/libraries
%endif
# build Pine
sh ./build CC=%{l_cc} EXTRACFLAGS=%{l_cflags -O} %if
%{with_ldap} == yes
EXTRALDFLAGS=%{l_ldflags} -lresolv %else
EXTRALDFLAGS=%{l_ldflags} NOLDAP %endif
%if %{with_ssl} == yes
SSLDIR=%{l_prefix} SSLTYPE=unix %else
NOSSL %endif
^^
Dennis McRitchie
Research Academic Applications Support (RAAS)
Academic Services Department
Office of Information Technology
Princeton University
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
