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
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
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, 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
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
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
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
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: 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
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
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
Anybody working on pam_ldap support?
We need to support pam_ldap because we need to make a minor customization to it. I have gone as far as building it from PADL's v176 tar ball against our OpenPKG openldap, sasl, and ssl. Before I go to the trouble of creating an OpenPKG RPM spec file for this product, I thought I'd check to see if there is anyone who is further along than I am in doing this. Anybody? 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 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]
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]
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]
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]
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: /man/man5/info.5 /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]
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]
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]
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]
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 \
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]
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]
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 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 -I/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 /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]
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]
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]
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]
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
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]
--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 #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]
[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: 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" 1>&2
> > 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.
>
[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" 1>&2
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 #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: 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: > > openpkg-import::with_mta > > 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 #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 #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: 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 #302] Continuing problems building perl-tk
Menubutton.xs
Finding dependancies for Listbox.xs
Test Compile/Run jpeg/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/a
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]
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]
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) {
>
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]
RE: tcpwrappers / openssh
Have Matthias' changes for openssh (below) been incorporated in openssh-3.7.1p2-20031125.src.rpm? Thanks, Dennis > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Kurz > Sent: Monday, November 10, 2003 7:25 PM > To: [EMAIL PROTECTED] > Subject: tcpwrappers / openssh > > > > 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. > > > openssh > --- > - changes to 'configure' because the test for the library > that contains > nanosleep() needed to be performed before the test for a > usable libwrap. > > > Well, my main goal was to realize a mechanism that accepts > ssh logins only from known hosts. This is difficult when > dynamic ip addresses come into play. There was an article in > the german journal iX, that describes some routines to apply > changes to "hosts.allow" controlled by PGP signed mails. Does > anyone know, whether there is a "ready to use" version, somewhere ? > > >(mk) > > Attachments: > > tcpwrappers.patch : updated patch > openssh.tar : includes openssh_config.patch and a new version of > openssh.spec > > -- > Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 >>> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) << > __ 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: Correspondence added by [EMAIL PROTECTED] Time: Tue Dec 02 18:12:28 2003 Is there any interest in picking up this change? I haven't heard any feedback about it. Thanks, Dennis > -Original Message- > From: The OpenPKG Project [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 9:03 AM > To: [EMAIL PROTECTED] > Subject: [OpenPKG #286] New problem and solution for building > pine with LDAP > > > This message has been automatically generated in response to > the creation of your OpenPKG request ticket regarding: > > "New problem and solution for building pine with LDAP" > > There is no need to reply to this message right now. Your > ticket has been assigned an ID of [OpenPKG #286]. Please > include the string "[OpenPKG #286]" 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/286 > > OpenPKG Request Tracker (RT) > [EMAIL PROTECTED] > https://rt.openpkg.org/ > __ > ___ > > 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: Tue Dec 02 18:10:22 2003 Is this problem still being worked on? I have not seen anything about it since October 24? Thanks, Dennis > -Original Message- > From: The OpenPKG Project [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 23, 2003 5:07 PM > To: [EMAIL PROTECTED] > Subject: [OpenPKG #284] New openpkg-tool problem > > > This message has been automatically generated in response to > the creation of your OpenPKG request ticket regarding: > > "New openpkg-tool problem" > > There is no need to reply to this message right now. Your > ticket has been assigned an ID of [OpenPKG #284]. Please > include the string "[OpenPKG #284]" 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/284 > > OpenPKG Request Tracker (RT) > [EMAIL PROTECTED] > https://rt.openpkg.org/ > __ > ___ > > 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 > > __ 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
> 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: 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: 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 1>&2
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]
