Re: Dependency Suggestion
Ralf S. Engelschall wrote: On Thu, Nov 02, 2006, David M. Fetter wrote: I notice that the latest 2-STABLE-20061018 release is now including the EVAL src.rpms. In addition, it seems that there are inter-dependencies between CORE, BASE, PLUS and EVAL which don't particularly leave me with a good fuzzy feeling. My suggestion is that CORE and BASE should not have any dependencies on software outside of themselves. The logical reason is that by having dependencies outside of CORE and BASE, which are the assured production quality software, it taints that assurance with software from any other source. Ultimately, all software that is assured production quality should also have the same assurance for any dependencies that software may have. The functional reason is that it would be nice to simply exclude the PLUS and/or EVAL sub-directories from custom build repositories without having any missing dependencies. This would ease things if a customer/user just wants to install production quality software only and non of the PLUS or EVAL software. Also, in a similar mindset, nothing from PLUS should have dependencies on anything in EVAL but the reverse can certainly be true. Thus, PLUS could have dependencies from software within CORE or BASE but not from EVAL. EVAL, of course, could pretty much have dependencies wherever since it is for evaluation only. Anyway, I thought I would send this suggestion out. Well, the classes _are_ full subsets of each other and without any dependency errors _WHEN IT COMES TO THE DEFAULT BUILD OPTIONS_. It is correct that there _are_ options which then cause additional dependencies to be activated which in turn break the class embedding order. That's the price of this flexibility. But unfortuntely this cannot be resolved in mostly all of the remaining cases known to us because usually the dependend package usually does _NOT_ qualify for the higher quality class of the package it requires it. For us it is more important that the class of a package describes as best as it can the package's content quality (the vendor software it contains) and not primarily a totally stricly independent set of packages within the distribution. If you followed the release engineering processes you have seen that we are very carefully in blessing packages for higher classes and especially in the last release engineering process we even were forced to downgrade a bunch of packages to lower classes to fix some classification problems. With over thousand packages this whole package classification is already extremely difficult and it is obvious that one cannot make it completely perfect from all points of view. Currently it is nearly optimal from the content classification and default-option based dependency order. To be both optimal from the content classification and total dependency order is IMHO not possible. For this OpenPKG is already too flexible with its build options. BTW, the reason why we now finally decided to also include the EVAL packages into the snapshot distribution is because many people asked for this in the past (mainly to have a more self-consistent distribution at hand and not requiring mixing of distributions). All of this is understandable to me, however, I made the suggested because it comes down to simplicity. Most customers want things quick easy. So, if you want to grab a decent sized customer base real quick, then making it as easy as possible for them will be important. In conjunction with quick easy, the customer also wants stability. While many folks may desire to have EVAL included, it takes away from a certain stability. Now, I haven't had the time to take a deeper look at the E1 release, so maybe it is more along these lines already. Basically, in my experience with consulting, customers want a couple main things: Quick Easy; and, Stable. I'm taking some extra time to go through the process of building everything and I'm just taking down some notes that I think might be helpful to make OpenPKG even better than the spectacular product it already is. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David Beware the barrenness of a busy life. ~Socrates __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Dependency Suggestion
I notice that the latest 2-STABLE-20061018 release is now including the EVAL src.rpms. In addition, it seems that there are inter-dependencies between CORE, BASE, PLUS and EVAL which don't particularly leave me with a good fuzzy feeling. My suggestion is that CORE and BASE should not have any dependencies on software outside of themselves. The logical reason is that by having dependencies outside of CORE and BASE, which are the assured production quality software, it taints that assurance with software from any other source. Ultimately, all software that is assured production quality should also have the same assurance for any dependencies that software may have. The functional reason is that it would be nice to simply exclude the PLUS and/or EVAL sub-directories from custom build repositories without having any missing dependencies. This would ease things if a customer/user just wants to install production quality software only and non of the PLUS or EVAL software. Also, in a similar mindset, nothing from PLUS should have dependencies on anything in EVAL but the reverse can certainly be true. Thus, PLUS could have dependencies from software within CORE or BASE but not from EVAL. EVAL, of course, could pretty much have dependencies wherever since it is for evaluation only. Anyway, I thought I would send this suggestion out. -- David M. Fetter - Portland State University - UNIX Systems Administrator Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
gettext on rhel4 fails
I'm finding that gettext under rhel is still failing unless I add '-lcharset' to the LDFLAGS in the spec file. Is there another fix for this? If not, maybe some case statement within the spec file for gettext can be added so that on rhel systems it explicitly adds the '-lcharset' flag? -- David M. Fetter - Portland State University - UNIX Systems Administrator Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: New OpenSSH error
On Wed, 2006-10-04 at 08:25 +0200, Ralf S. Engelschall wrote: On Tue, Oct 03, 2006, David M. Fetter wrote: Nope. Still getting the error. My build options are as follows: -Dopenssh::with_alias=no -Dopenssh::with_chroot=no -Dopenssh::with_connect=no -Dopenssh::with_ldap=yes -Dopenssh::with_libedit=no -Dopenssh::with_pam=yes -Dopenssh::with_sftplogging=no -Dopenssh::with_skey=no -Dopenssh::with_trysetpath=yes -Dopenssh::with_watchdog=no -Dopenssh::with_wrap=yes -Dopenssh::with_x11=yes Ok, I see. It's the LDAP stuff. Hmmm... seems like the project moved on the net, so we've not automatically detected that a newer and ajusted version of the LDAP patches already existed. I've now updated the OpenSSH package for the latest LPK patchset. This should be now finally fixed with openssh-4.4p1-2.20061004. Sorry for the inconvinience during updating. Thanks. It's cool. We can deal with it. I'm more worried about those who can't, which is why I was pointing it out. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
query all build options?
Is there a simply built-in method to query all installed rpms for what build options are used? -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
Re: query all build options?
Ok. That's what I'm already doing basically. I was just hoping for some openpkg-tools method or something. No biggie. Thanks. ;-) On Wed, 2006-10-04 at 20:35 +0200, Ralf S. Engelschall wrote: 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? $ openpkg rpm -qai | grep ::with_ Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
New OpenSSH error
Just an FYI, I'm getting the following error on both RHEL4 and Sol10 when trying to update OpenSSH after yesterdays security update was put out. /var/tmp/OpenPKG/SRC/UPD/openssh-4.4p1-2.20060929.src.rpm Installing /var/tmp/OpenPKG/SRC/UPD/openssh-4.4p1-2.20060929.src.rpm Executing(%prep): env -i /usr/local/lib/openpkg/bash --norc --noprofile --posix -e /usr/local/RPM/ROOT/TMP/rpm-tmp.11288 + cd /usr/local/RPM/ROOT/SRC + cd /usr/local/RPM/ROOT/SRC + rm -rf openssh-4.4p1 + /usr/local/lib/openpkg/gzip -dc /usr/local/RPM/ROOT/SOURCES/openssh-4.4p1.tar.gz + /usr/local/lib/openpkg/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd openssh-4.4p1 + echo 'Patch #0 (openssh.patch):' Patch #0 (openssh.patch): + /usr/local/lib/openpkg/patch -p0 -s -b + /usr/local/lib/openpkg/shtool subst -e 's;@l_openpkg_release@;OpenPKG-2-STABLE;' version.h + /usr/local/bin/patch -p1 -b patching file Makefile.in Hunk #1 FAILED at 86. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.in.rej patching file README.lpk patching file auth-rsa.c Hunk #1 succeeded at 173 (offset 13 lines). patching file auth2-pubkey.c Hunk #1 succeeded at 53 (offset 10 lines). Hunk #2 succeeded at 190 (offset 10 lines). patching file config.h.in Hunk #1 succeeded at 510 (offset 34 lines). patching file configure Hunk #1 FAILED at 876. Hunk #2 succeeded at 11268 with fuzz 2 (offset 25 lines). Hunk #3 succeeded at 33491 with fuzz 1 (offset 5383 lines). 1 out of 3 hunks FAILED -- saving rejects to file configure.rej patching file configure.ac Hunk #1 succeeded at 1218 (offset 84 lines). Hunk #2 succeeded at 3997 with fuzz 1 (offset 200 lines). patching file ldapauth.c patching file ldapauth.h patching file lpk-user-example.txt patching file openssh-lpk.schema patching file servconf.c Hunk #1 succeeded at 40 with fuzz 2 (offset 17 lines). Hunk #2 FAILED at 123. Hunk #3 succeeded at 270 (offset 17 lines). Hunk #4 succeeded at 339 with fuzz 1 (offset 18 lines). Hunk #5 FAILED at 443. Hunk #6 succeeded at 1330 (offset 265 lines). 2 out of 6 hunks FAILED -- saving rejects to file servconf.c.rej patching file servconf.h Hunk #1 succeeded at 16 with fuzz 2 (offset -2 lines). Hunk #2 FAILED at 139. 1 out of 2 hunks FAILED -- saving rejects to file servconf.h.rej patching file sshd.c Hunk #1 succeeded at 124 (offset 31 lines). Hunk #2 succeeded at 1433 with fuzz 1 (offset 340 lines). patching file sshd_config Hunk #1 succeeded at 101 (offset 1 line). patching file sshd_config.5 Hunk #1 succeeded at 897 with fuzz 2 (offset 120 lines). error: Bad exit status from /usr/local/RPM/ROOT/TMP/rpm-tmp.11288 (% prep) -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
Re: New OpenSSH error
Nope. Still getting the error. My build options are as follows: -Dopenssh::with_alias=no -Dopenssh::with_chroot=no -Dopenssh::with_connect=no -Dopenssh::with_ldap=yes -Dopenssh::with_libedit=no -Dopenssh::with_pam=yes -Dopenssh::with_sftplogging=no -Dopenssh::with_skey=no -Dopenssh::with_trysetpath=yes -Dopenssh::with_watchdog=no -Dopenssh::with_wrap=yes -Dopenssh::with_x11=yes On Tue, 2006-10-03 at 19:19 +0200, Ralf S. Engelschall wrote: On Tue, Oct 03, 2006, David M. Fetter wrote: Just an FYI, I'm getting the following error on both RHEL4 and Sol10 when trying to update OpenSSH after yesterdays security update was put out. /var/tmp/OpenPKG/SRC/UPD/openssh-4.4p1-2.20060929.src.rpm Installing /var/tmp/OpenPKG/SRC/UPD/openssh-4.4p1-2.20060929.src.rpm [...] I guess you have the with_watchdog option enabled, right? This was temporarily broken as the watchdog patch was still not released with an up-to-date version by the upstream author. It was already fixed in CURRENT. I've now MFC'ed the update to 2-STABLE so this should be fixed now. Please retry with openssh-4.4p1-2.20061003. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
Re: [CVS] OpenPKG: openpkg-src/perl-www/ perl-www.patch perl-www.spec
Ah, sorry. Posting in haste. It's on Solaris 10 sparc64. On Thu, 2006-09-28 at 07:50 +0200, Ralf S. Engelschall wrote: On Wed, Sep 27, 2006, David M. Fetter wrote: This seems to be a problem again. See below: ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [blib/arch/auto/Embperl/Embperl.so] Error 1 /usr/local/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible On what particular platform is this, David? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
Re: Getent shell script calls.
Will the openpkg fix be MFC'd into the 2.20060622 stable release as an
UPD? It would be nice if it was.
On Fri, 2006-09-29 at 08:54 +0200, Ralf S. Engelschall wrote:
On Thu, Sep 28, 2006, Mark Keller wrote:
I have a feature request or bug fix as I see it.
We use LDAP for NSS/PAM and we have about 50,000 user accounts and 50,000
groups. Each user has a group. I have noticed that our LDAP servers were
having some performance problems from time to time. I narrowed it down to
openpkg causing severe LDAP lookups during cron routines and other types of
openpkg commands.
I found the following three shell scripts calling getent in a horribly
inefficient way. Basically causing a complete dump of the password and
group file for certain operations.
/usr/local/etc/openpkg/rpmmacros
Several lines like this:
%l_suid %((getent passwd; cat /etc/passwd; ypcat passwd;
nidump passwd .) 2/dev/null | grep ^ %{l_susr}: | sed -e 'q' |
awk -F: '{ print $3; }')
/usr/local/lib/openpkg/shtool
This one as the following:
groupname=`(getent group) 2/dev/null | \
grep ^[^:]*:[^:]*:${groupid}: | \
sed -e 's/:.*$//'`
/usr/local/libexec/openpkg-tools/dev.sh
This one has the following:
realname=`(getent passwd; cat /etc/passwd; ypcat passwd; nidump passwd .)
2/dev/null |\
grep ^${username}: | awk -F: '{ print $5; }'`
Ideally these would have something like:
getent passwd ${username} ; grep ^${username} /etc/passwd; ypmatch
${username} passwd; nidump passwd
I am sure NIS+ has a similar command, but I don't use it.
I see that this has been done is a few of the scripts, but those there seem
to still have problems. Anyhow, that would certainly make things way more
efficient.
Yes, good catch. Although we cannot make it more efficient for those
cases where we have to map from ID to name, we at least can make
it more efficient in those cases where we have to map from name to
anything else (which is 90% of all cases).
This is now fixed in openpkg-tools-0.8.75-20060929 for openpkg dev and
in openpkg-20060929-20060929 for the bootstrap package. Please give them
a try and test it to make sure it doesn't break in any new way.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David M. Fetter - Portland State University - UNIX Systems Administrator
Reality is merely an illusion, albeit a very persistent one. ~Einstein
signature.asc
Description: This is a digitally signed message part
Re: OpenPKG versioning (was: Getent shell script calls.)
On Fri, 2006-09-29 at 19:37 +0200, Ralf S. Engelschall wrote:
On Fri, Sep 29, 2006, David M. Fetter wrote:
Will the openpkg fix be MFC'd into the 2.20060622 stable release as an
UPD? It would be nice if it was.
Hmmm no, I don't think we should MFC it to the old 2-STABLE
snapshot. Mainly because I've already not MFC'ed other similar things
(like the SetUID) which could too easy break. But we'll MFC it to the
2-STABLE branch and this way it will be part of the forthcoming 2-STABLE
snapshot which will be rolled around the 18th of October. Have a look at
http://www.openpkg.org/project/events.php for details on the forthcoming
events.
Ah. Well, this brings up another topic. We're finally getting around
to updating our servers from 2.3 to 2-STABLE. However, I'm finding that
some of the logic in the various scripts I wrote to deal with how we
push out and maintain our rpm repository are going to be broken now.
You see, I have some variables that are defined by grabbing the version
based on what 'openpkg -v' spits out. With the new 2-STABLE it seems
that there isn't as nice of a way to display a static version to build
off of. Perhaps I should go into more detail. Since we don't want to
have all of our servers rebuild all rpms, we have our own custom binary
repository setup. The names of this repository has typically been
${VERSION}-${ARCH}. These variables are obtained via my scripts which
ultimately make this to be something like 2.3-sparc-sun-solaris2.9,
etc. With the way that openpkg now spits out it's version, it means
that all snapshots of 2-STABLE, regardless of when they were made, will
come out to be something like 2STABLE-sparc-sun-solaris2.10, etc.
However, this won't change from snapshot release to snapshot release
using the same method. I can't just grab the date from the way the new
version either because that date changes if the main openpkg rpm has a
UPD rebuild. We need to have something truly static with minimal
changes to overall architecture to ensure production quality. I'm
thinking that there are several ways to resolve this. Is there another
way to get a version of the snapshot time that will stay consistent
throughout changes/updates (i.e. 2.20060622 would work)? If not, can
openpkg -v instead reply with something more like OpenPKG-2.20060622
(2.20060818) so that it shows the snapshot date and next to it the UPD
rebuild date? Mainly, if I had some consistent way to get the snapshot
date so I can setup the binary repos using that, then that would work.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David M. Fetter - Portland State University - UNIX Systems Administrator
Reality is merely an illusion, albeit a very persistent one. ~Einstein
signature.asc
Description: This is a digitally signed message part
Re: OpenPKG versioning (was: Getent shell script calls.)
Ok, this might work. I'll play with it. Thanks.
On Fri, 2006-09-29 at 21:09 +0200, Ralf S. Engelschall wrote:
On Fri, Sep 29, 2006, David M. Fetter wrote:
Will the openpkg fix be MFC'd into the 2.20060622 stable release as an
UPD? It would be nice if it was.
Hmmm no, I don't think we should MFC it to the old 2-STABLE
snapshot. Mainly because I've already not MFC'ed other similar things
(like the SetUID) which could too easy break. But we'll MFC it to the
2-STABLE branch and this way it will be part of the forthcoming 2-STABLE
snapshot which will be rolled around the 18th of October. Have a look at
http://www.openpkg.org/project/events.php for details on the forthcoming
events.
Ah. Well, this brings up another topic. We're finally getting around
to updating our servers from 2.3 to 2-STABLE. However, I'm finding that
some of the logic in the various scripts I wrote to deal with how we
push out and maintain our rpm repository are going to be broken now.
You see, I have some variables that are defined by grabbing the version
based on what 'openpkg -v' spits out.
The official way to determine the release is the newer openpkg release
command. Run openpkg man release for more details.
With the new 2-STABLE it seems
that there isn't as nice of a way to display a static version to build
off of.
Well, openpkg release --fmt=%t should do what you want.
Perhaps I should go into more detail. Since we don't want to
have all of our servers rebuild all rpms, we have our own custom binary
repository setup. The names of this repository has typically been
${VERSION}-${ARCH}. These variables are obtained via my scripts which
ultimately make this to be something like 2.3-sparc-sun-solaris2.9,
etc. With the way that openpkg now spits out it's version, it means
that all snapshots of 2-STABLE, regardless of when they were made, will
come out to be something like 2STABLE-sparc-sun-solaris2.10, etc.
[...]
That's not the case with openpkg release. It reads the optional
prefix/etc/openpkg/release config file and its TAG variable and this
way knowns about 2-STABLE snapshots, too.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David M. Fetter - Portland State University - UNIX Systems Administrator
Reality is merely an illusion, albeit a very persistent one. ~Einstein
signature.asc
Description: This is a digitally signed message part
Re: [CVS] OpenPKG: openpkg-src/perl-www/ perl-www.patch perl-www.spec
This seems to be a problem again. See below: ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [blib/arch/auto/Embperl/Embperl.so] Error 1 /usr/local/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible and + /usr/local/lib/openpkg/shtool mkdir -f -p -m 755 /usr/local/RPM/ROOT/TMP/perl-www-5.8.8-root/usr/local/cgi + mv /usr/local/RPM/ROOT/TMP/perl-www-5.8.8-root/usr/local/bin/embpcgi /usr/local/RPM/ROOT/TMP/perl-www-5.8.8-root/usr/local/cgi/embpcgi mv: cannot stat `/usr/local/RPM/ROOT/TMP/perl-www-5.8.8-root/usr/local/bin/embpcgi': No such file or directory On Tue, 2005-10-04 at 09:58 +0200, Ralf S. Engelschall wrote: On Tue, Oct 04, 2005, Christoph Schug wrote: modifying package: perl-www-5.8.7 20050929 - 20051004 [...] -%define V_embperl 2.0.0 +%define V_embperl 2.0.1 [...] Unfortunately the package continues building, but unfortunately the Embperl itself fails: | [...] | kg-dev/include -O2 -pipe -DVERSION=\2.0.1\ -DXS_VERSION=\2.0.1\ -DPIC -fPIC -I/openpkg-dev/lib/perl/5.8.7/i386-freebsd/CORE -DEP2 -DLIBXSLT -o epchar.o epchar.c | /openpkg-dev/bin/cc -c -I/openpkg-dev/include/libxml2 -I/openpkg-dev/include -I/openpkg-dev/include -I/openpkg-dev/include/libxml2 -I/tmp/rse/openpkg/perl-www-5.8.7/Embperl-2.0.1/xs -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/openpkg-dev/include -O2 -pipe -DVERSION=\2.0.1\ -DXS_VERSION=\2.0.1\ -DPIC -fPIC -I/openpkg-dev/lib/perl/5.8.7/i386-freebsd/CORE -DEP2 -DLIBXSLT -o eputil.o eputil.c | eputil.c:2057: error: 'timezone' redeclared as different kind of symbol | /usr/include/time.h:149: error: previous declaration of 'timezone' was here | make: *** [eputil.o] Error 1 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
openssh.spec update
I modified the latest openssh.spec to change the with_trysetpath to with_securepath so that if it is enabled then it sets the path otherwise it leaves the configure with default behavior. This is as I outlined in another email I sent a couple weeks ago. I'm hoping that this will be accepted and added as part of the 2.6 release. -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
openssh default pathing
I was reviewing the openssh.spec file that is within the CURRENT
revision of openssh and I wanted to open up a discussion about the
default pathing. When the latest openssh security patch was released,
our instance of openssh broke on solaris when using rsync (or any other
command really). I'm not too concerned because we're still on openpkg
2.3 and I plan on upgrading when 2.6 comes out. In the current spec
file I see the following in regards to default pathing:
%if %{with_trysetpath} == yes
--enable-etc-default-login \
--with-default-path=%{l_prefix}/bin:/bin:/usr/bin:/usr/local/bin
\
--with-superuser-path=%{l_prefix}/bin:/usr/bin:/sbin:/usr/sbin \
%else
--disable-etc-default-login \
--with-default-path=/bin:/usr/bin \
--with-superuser-path=/bin:/usr/bin:/sbin:/usr/sbin \
%endif
This means that on solaris systems pathing will generally be broken by
default unless with_trysetpath is set to yes due to the
--with-default-path and other related options. As far as I'm aware,
these options are more for security reasons for openssh than they are to
fix default pathing on solaris (or whatever other OS's have the same
problem). My thoughts are that the option in the spec file should be
called with_securepath (or just with_secpath) and it should only be
a single if statement that disables /etc/default/login and sets the
specific paths which should only include %{l_prefix}. It definitely
should not include any sbin paths because part of the reason is to lock
the pathing down if you want a more secure openssh installation. In any
case, I am only one opinion and as I said, I wanted to open this up for
discussion. So, what do the rest of you think?
--
David M. Fetter - Portland State University - UNIX Systems Administrator
I do not agree with what you have to say, but I'll defend to the death
your right to say it. ~François-Marie Arouet
signature.asc
Description: This is a digitally signed message part
openpkg tools rebuild dependency dilemma
This is more of a discussion about how openpkg tools find dependencies and thus rebuilds and/or installs rpms. It appears that if something is listed as a BuildPreReq or as a PreReq, then it will want to rebuild and/or install the rpm. There is a subtle problem with this, I think. I'm thinking that openpkg tools should only rebuild the rpms if it is listed under BuildPreReq and not worry about the PreReq. It should, of course, worry about the PreReq when checking to see if that rpm is installed or not, but that's it. BuildPreReq would ideally be used to state what other libraries or software needs to exist during (re)build of a given package. PreReq would list the various software that needs to be installed during install time in order for the software to even function properly. These two things can be different and ultimately, probably should be different in most cases. Now, don't get me wrong. I realize this would require some serious accountability and attention to detail. I'm just curious if it would be possible to modify openpkg tools so that it only rebuilds and installs dependent rpms if it in the BuildPreReq but not in the PreReq. Let me explain the dilemma so that it is (hopefully) understood. I will use an example using the latest sendmail security fix. When the fix is released, obviously, sendmail needs to be rebuilt and deployed. In addition to rebuilding sendmail, openpkg tools sees various other rpms as also needing to be rebuilt then reinstalled due to static library linking. For our environment, this includes: dk-milter; imapd; inn; mailman; majordomo; mapson; mimedefang; nagios; nail; nn; pine; pks; qpoper; pb4sd; and, shiela. Now this isn't that many really, but how many of these actually need to be rebuilt and reinstalled? I don't think any of them need to be rebuilt actually. I'm pretty sure none of these dependent rpms are build with statically linked sendmail libraries. So, why is this a problem? Of these rpms six of them are used as part of critical (i.e. high availability) services. When these are reinstalled there is a subtle, yet noticeable by many, blip in the radar. There may even be in some rare instances a complete failure of the service because it doesn't restart properly or something of that nature. Obviously, in any critical service environment, this presents a problem. Now, as for the solution, I can foresee a couple things to do. One is that some standards need to be written on how to write spec files. Within this standard document for writing spec files it should be indicated that BuildPreReq and PreReq have the two different aforementioned definitions for very specific reasons. This, of course, is only one piece. The other piece is going to be that we have to go through all of the current spec files and evaluate if the various BuildPreReq and PreReq values are defined in the manner we decide. (By we I mean the OpenPKG foundation and by decide I mean that I am not stating how it should be done only possible ways it could be done and thus a decision needs to be made.) In addition, the openpkg-tools will need some reworking. How much I don't know. Maybe it's just a small tweak or maybe it's a major undertaking. That will have to be figured out (unless it's already known) then the time to do it will have to be determined. That's the tough part...time. Time is our nemesis! We should've never made that up. ;-) In any case, what say you all? Thoughts/ideas? -- David M. Fetter - Portland State University - UNIX Systems Administrator Reality is merely an illusion, albeit a very persistent one. ~Einstein signature.asc Description: This is a digitally signed message part
j2se14.spec fix
There was a bug in the j2se14.spec file because a variable named pkgfile2 was being confused with another variable named suppfile. They are actually the same file but used differently. I fixed this and made the variable consistently used and it resolved the issue, which was that it wasn't installing the sparcv9 java bits. I just uploaded this to contrib. FYI. -- David M. Fetter - UNIX Systems Administrator Portland State University There are 10 types of people in the world, those that understand binary and those that don't. signature.asc Description: This is a digitally signed message part
Re: openssh.spec modification
Super! Thanks. On Thu, 2005-09-15 at 20:41 +0200, Ralf S. Engelschall wrote: On Thu, Sep 15, 2005, David M. Fetter wrote: On Thu, 2005-09-15 at 07:21 +0200, Ralf S. Engelschall wrote: On Wed, Sep 14, 2005, David M. Fetter wrote: It doesn't seem that any fixes for the default path problem has been put into UPD, at least for OpenPKG 2.3. Not sure if it was put into OpenPKG 2.4 because we haven't upgraded to that and we probably won't be able too until next year. Are there any plans to add this as a UPD fix? If not, then we will need to do something else on our side. I've not MFC'ed it as it is actually changing semantics and this way is not backward compatible. Hence it could break an existing installation, which should not happen for UPD packages. I thought the conclusive fix was an option that would disable those features, but by default they are on, therefore it won't break existing installations? Oh, I see. Yes, you're right. My fault. I've forgotten that it was a build-time option and disabled by default. Well, then we could MFC it, yes. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba w/ADS - Test Update
Hello all. I was curious if anybody has worked on this anymore and
perhaps found the fix? I haven't had any extra time since my last work
on this, but I will probably start looking into it more in the near
future if it hasn't been resolved. If it has been resolved, I would
certainly appreciate hearing how. Thanks.
On Fri, 2005-08-26 at 14:53 -0700, David M. Fetter wrote:
On Thu, 2005-08-25 at 17:04 -0700, David M. Fetter wrote:
On Thu, 2005-08-25 at 13:35 -0700, Doug Summers wrote:
Well, I didn't have to patch anything with the Samba 3.0.14a code I
downloaded from samba.org. The only issues I had were with Kerberos
OpenLDAP playing together. At this point I think I could get ADS support
working if I could just get Samba w/LDAP support compiled. If you have
any tricks let me know - I can't get it to work on Linux or Solaris.
Ah, well, then that information must be obsoleted now. Good. That
makes things a bit easier. As for something to try, because openldap
under openpkg is compiled by default with ssl support, you need to add
'-lssl -lcrypt' into the LIBS flag. You can do this by inserting the
following code after line 99 of the samba.spec file:
%if %{with_ldap} == yes
LIBS=$LIBS -lssl -lcrypto
export LIBS
%endif
However, while this seems to fix one issue, another one crops up
afterward. It seems to fail with:
Compiling libsmb/clikrb5.c
libsmb/clikrb5.c:163:2: #error UNKNOWN_GET_ENCTYPES_FUNCTIONS
libsmb/clikrb5.c: In function `krb5_locate_kdc':
libsmb/clikrb5.c:212: error: `krb5_krbhst_handle' undeclared (first use
in this function)
libsmb/clikrb5.c:212: error: (Each undeclared identifier is reported
only once
libsmb/clikrb5.c:212: error: for each function it appears in.)
libsmb/clikrb5.c:212: error: parse error before hnd
libsmb/clikrb5.c:213: error: `krb5_krbhst_info' undeclared (first use in
this function)
libsmb/clikrb5.c:213: error: `hinfo' undeclared (first use in this
function)
libsmb/clikrb5.c:222: error: `KRB5_KRBHST_KDC' undeclared (first use in
this function)
libsmb/clikrb5.c:222: error: `hnd' undeclared (first use in this
function)
make: *** [libsmb/clikrb5.o] Error 1
This is true both under Solaris9 and RHEL3. I will look more into this
tomorrow unless somebody else finds the fix for this.
Well, I'm now stuck on this (at least for now). I can't seem to find
the reference krb5_kt_compare in any of the libraries, even
under /usr/local/lib/kerberos, using nm. This is the first undefined
reference where it bombs as you can see here:
configure:31168: checking for krb5_kt_compare in -lkrb5
configure:31196: /usr/local/bin/gcc -o conftest
-I/usr/local/include/kerberos -O2 -pipe -D_SAMBA_BUILD_
-I/usr/local/include/kerberos -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/usr/local/include
-I/usr/local/include/openssl -DOPENSSL_DISABLE_OLD_DES_SUPPORT
-I/usr/include -L/usr/local/lib/kerberos -L/usr/local/lib
-L/usr/local/lib -L/lib conftest.c -lkrb5 -L/usr/local/lib/kerberos
-L/usr/local/lib -L/usr/local/lib/kerberos -L/usr/local/lib
-lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lfsl
-lnsl -lresolv -lnsl -ldl -lssl -lcrypto -liconv 5
/usr/local/RPM/USER/TMP/cc4DgFl1.o(.text+0xd): In function `main':
: undefined reference to `krb5_kt_compare'
collect2: ld returned 1 exit status
configure:31202: $? = 1
configure: failed program was:
Anybody else have any ideas to move this along?
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: openssh.spec modification
It doesn't seem that any fixes for the default path problem has been put into UPD, at least for OpenPKG 2.3. Not sure if it was put into OpenPKG 2.4 because we haven't upgraded to that and we probably won't be able too until next year. Are there any plans to add this as a UPD fix? If not, then we will need to do something else on our side. On Tue, 2005-08-02 at 12:16 -0700, David M. Fetter wrote: I just uploaded it the modified one and this is the follow up explanation of what the contributed spec file has that is different. On Tue, 2005-08-02 at 21:13 +0200, Matthias Kurz wrote: On Tue, Aug 02, 2005, David M. Fetter wrote: This spec file for openssh simply has the hardcoded --with-default-path and --disable-etc-default-login removed from it because these are essentially not appropriate for a generic environment, etc. Hi. Is this an analysis or did you contribute it ? (mk) -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba w/ADS - Test Update
On Thu, 2005-08-25 at 17:04 -0700, David M. Fetter wrote:
On Thu, 2005-08-25 at 13:35 -0700, Doug Summers wrote:
Well, I didn't have to patch anything with the Samba 3.0.14a code I
downloaded from samba.org. The only issues I had were with Kerberos
OpenLDAP playing together. At this point I think I could get ADS support
working if I could just get Samba w/LDAP support compiled. If you have
any tricks let me know - I can't get it to work on Linux or Solaris.
Ah, well, then that information must be obsoleted now. Good. That
makes things a bit easier. As for something to try, because openldap
under openpkg is compiled by default with ssl support, you need to add
'-lssl -lcrypt' into the LIBS flag. You can do this by inserting the
following code after line 99 of the samba.spec file:
%if %{with_ldap} == yes
LIBS=$LIBS -lssl -lcrypto
export LIBS
%endif
However, while this seems to fix one issue, another one crops up
afterward. It seems to fail with:
Compiling libsmb/clikrb5.c
libsmb/clikrb5.c:163:2: #error UNKNOWN_GET_ENCTYPES_FUNCTIONS
libsmb/clikrb5.c: In function `krb5_locate_kdc':
libsmb/clikrb5.c:212: error: `krb5_krbhst_handle' undeclared (first use
in this function)
libsmb/clikrb5.c:212: error: (Each undeclared identifier is reported
only once
libsmb/clikrb5.c:212: error: for each function it appears in.)
libsmb/clikrb5.c:212: error: parse error before hnd
libsmb/clikrb5.c:213: error: `krb5_krbhst_info' undeclared (first use in
this function)
libsmb/clikrb5.c:213: error: `hinfo' undeclared (first use in this
function)
libsmb/clikrb5.c:222: error: `KRB5_KRBHST_KDC' undeclared (first use in
this function)
libsmb/clikrb5.c:222: error: `hnd' undeclared (first use in this
function)
make: *** [libsmb/clikrb5.o] Error 1
This is true both under Solaris9 and RHEL3. I will look more into this
tomorrow unless somebody else finds the fix for this.
Well, I'm now stuck on this (at least for now). I can't seem to find
the reference krb5_kt_compare in any of the libraries, even
under /usr/local/lib/kerberos, using nm. This is the first undefined
reference where it bombs as you can see here:
configure:31168: checking for krb5_kt_compare in -lkrb5
configure:31196: /usr/local/bin/gcc -o conftest
-I/usr/local/include/kerberos -O2 -pipe -D_SAMBA_BUILD_
-I/usr/local/include/kerberos -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/usr/local/include
-I/usr/local/include/openssl -DOPENSSL_DISABLE_OLD_DES_SUPPORT
-I/usr/include -L/usr/local/lib/kerberos -L/usr/local/lib
-L/usr/local/lib -L/lib conftest.c -lkrb5 -L/usr/local/lib/kerberos
-L/usr/local/lib -L/usr/local/lib/kerberos -L/usr/local/lib
-lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lfsl
-lnsl -lresolv -lnsl -ldl -lssl -lcrypto -liconv 5
/usr/local/RPM/USER/TMP/cc4DgFl1.o(.text+0xd): In function `main':
: undefined reference to `krb5_kt_compare'
collect2: ld returned 1 exit status
configure:31202: $? = 1
configure: failed program was:
Anybody else have any ideas to move this along?
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: Samba w/ADS - Test Update
On Tue, 2005-08-23 at 18:25 -0700, Doug Summers wrote: Doug Summers wrote: Matthias Kurz wrote: On Tue, Aug 23, 2005, Doug Summers wrote: [...] I'm not even getting to the test for the kerberos files as it's failing on OpenLDAP: checking for LDAP support... yes checking ldap.h usability... yes checking ldap.h presence... yes checking for ldap.h... yes checking lber.h usability... yes checking lber.h presence... yes checking for lber.h... yes checking for ber_scanf in -llber... yes checking for ldap_init in -lldap... no checking for ldap_domain2hostlist... no checking for ldap_set_rebind_proc... no checking whether ldap_set_rebind_proc takes 3 arguments... 3 checking for ldap_initialize... no configure: error: libldap is needed for LDAP support You should always check config.log in such cases. I guess there was a problem with compiling/linking of a config check. (mk) I get the exact same error when using the sources I downloaded from Samba. I'll take a look to see what happened. From everything I'm reading (and I ran into the same problem compiling all parts from scratch on AIX Solaris) I'm supposed to add some LDFLAGS CPPFLAGS settings which point to where the openldap files are installed, none of which are working. I tried reinstalling all of the samba w/ldap parts using 'openpkg build samba | sh', which also fails the same way (RHEL 3 w/U5 and Solaris 9): builds pth builds openldap builds popt fails on samba __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org Ah, yes, the old samba with ADS support. I looked into this quite some time ago and it was on my task list for my place of work to get it implemented, though priorities changed. From my research into it, there is a special patch that is not in the current sources for samba that must be applied in order for ADS to function properly. You can find examples of the patch by looking at other linux distributions because they all pretty much included it so they can advertise the functionality. So, the answer is, yes there are plans to add this but it's a little more work than just adding an option. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba w/ADS - Test Update
On Thu, 2005-08-25 at 13:35 -0700, Doug Summers wrote:
Well, I didn't have to patch anything with the Samba 3.0.14a code I
downloaded from samba.org. The only issues I had were with Kerberos
OpenLDAP playing together. At this point I think I could get ADS support
working if I could just get Samba w/LDAP support compiled. If you have
any tricks let me know - I can't get it to work on Linux or Solaris.
Ah, well, then that information must be obsoleted now. Good. That
makes things a bit easier. As for something to try, because openldap
under openpkg is compiled by default with ssl support, you need to add
'-lssl -lcrypt' into the LIBS flag. You can do this by inserting the
following code after line 99 of the samba.spec file:
%if %{with_ldap} == yes
LIBS=$LIBS -lssl -lcrypto
export LIBS
%endif
However, while this seems to fix one issue, another one crops up
afterward. It seems to fail with:
Compiling libsmb/clikrb5.c
libsmb/clikrb5.c:163:2: #error UNKNOWN_GET_ENCTYPES_FUNCTIONS
libsmb/clikrb5.c: In function `krb5_locate_kdc':
libsmb/clikrb5.c:212: error: `krb5_krbhst_handle' undeclared (first use
in this function)
libsmb/clikrb5.c:212: error: (Each undeclared identifier is reported
only once
libsmb/clikrb5.c:212: error: for each function it appears in.)
libsmb/clikrb5.c:212: error: parse error before hnd
libsmb/clikrb5.c:213: error: `krb5_krbhst_info' undeclared (first use in
this function)
libsmb/clikrb5.c:213: error: `hinfo' undeclared (first use in this
function)
libsmb/clikrb5.c:222: error: `KRB5_KRBHST_KDC' undeclared (first use in
this function)
libsmb/clikrb5.c:222: error: `hnd' undeclared (first use in this
function)
make: *** [libsmb/clikrb5.o] Error 1
This is true both under Solaris9 and RHEL3. I will look more into this
tomorrow unless somebody else finds the fix for this.
Doug
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
perl-db update for solaris
The DB_File piece within perl-db wasn't being built correctly under Solaris. It needs to have the -lrt added to it's compile options. I added a section in the spec file to address this for Solaris systems and uploaded it to the contrib area. After some cross platform testing this should be put into UPD areas. This is a known problem under 2.3. Not sure if the problem still exists under 2.4 because we haven't upgraded to that as of yet. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
openssh.spec modification
This spec file for openssh simply has the hardcoded --with-default-path and --disable-etc-default-login removed from it because these are essentially not appropriate for a generic environment, etc. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openssh.spec modification
I just uploaded it the modified one and this is the follow up explanation of what the contributed spec file has that is different. On Tue, 2005-08-02 at 21:13 +0200, Matthias Kurz wrote: On Tue, Aug 02, 2005, David M. Fetter wrote: This spec file for openssh simply has the hardcoded --with-default-path and --disable-etc-default-login removed from it because these are essentially not appropriate for a generic environment, etc. Hi. Is this an analysis or did you contribute it ? (mk) -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
tcl/expect install fix
I have an idea to potentially permanently resolve the tcl/expect problem upon initial upgrades, etc. Why not add an explicit statement somewhere within the openpkg tools so that it will always install tcl expect in the same command. If it sees they need to be updated it just does the 'openpkg rpm -Uhv --force tcl.rpm expect.rpm' in one command. That resolves the issue right there. Can this be done? Would it be difficult? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: OpenSSH PATH problem
Actually, we are having the same problem now. I found out why. It is
because of the following configure options:
220 --disable-etc-default-login \
221 --with-default-path=/bin:/usr/bin \
222 --with-superuser-path=/bin:/usr/bin:/sbin:/usr/sbin \
I understand the thoughts behind adding such configure options, however
for the generic use of openssh, these options shouldn't be default. In
addition, these options break openssh for everybody who is using an
openpkg environment because this means that prior to login the path is
hardcoded to what you see above. This also means that things like
`rsync -av -e ssh dir/ host:/tmp/dir/` will not work because openssh
won't see the rsync binary that resides under %{l_prefix}/bin, etc.
This breaks svn over ssh as well. So, either these options should
include %{l_prefix}/bin and %{l_prefix}/sbin or they should just be
removed altogether. Any thoughts?
On Tue, 2005-03-29 at 21:48 +0200, Ralf S. Engelschall wrote:
On Tue, Mar 29, 2005, Bill Campbell wrote:
I ran into a problem at a customer's yesterday when I found that
openssh no longer prepends the OpenPKG bin directory to the PATH
on the server. Looking back through my archives, this appears to
have happened between Release 2.1 and Release 2.2. This causes
things like ``rsync -e ssh xxx'' to fail on the remote system or
to find invalid configuration if there's a vendor supplied
version of the program on the remote end that conflicts with the
OpenPKG version of the program.
The attached patch fixes this in what I think is a logical manner
for OpenPKG Release 2.2, 2.3, and CURRENT.
Unfortunately, no, it doesn't. Well, to be precise, it fixes it
on those platforms where OpenSSH supports the --with-default-path
functionality only!
That's the reason why we explicitly removed any %{l_prefix} stuff there
(see http://cvs.openpkg.org/chngview?cn=19660) for cross-platform
consistency reasons. Because it is totally confusing if one some
platforms one magically has the %{l_prefix} in path by default set
by sshd(8) and on other platforms it isn't. Hence we decided to
intentionally not try to add %{l_prefix}/bin there at all and instead
have to life with the fact that there has to be either (1) a global
shell profile setting PATH correctly, or (2) a local shell profile
setting PATH correctly or (3) the user calls the command with an
absolute path.
All this I personally don't like very much, but to be honest, I do not
see a solution. Even hacking sshd(8) is not possible because the reason
why --with-default-path isn't working on all platforms is partly because
on those login(1) is used by sshd(8) (and this way PATH is reset by the
system after sshd forked off its child), etc.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: Q: Pointers to OpenPKG-HOWTOs ?
On Fri, 2005-07-01 at 13:13 -0700, Bill Campbell wrote: On Fri, Jul 01, 2005, Matthias Kurz wrote: Hi. I've seen some pointers in the past, but i cannot find them again. Are there some public documents/HOWTOs, where people describe how they configure and maintain OpenPKG ? I have an overview on one of our sites that I wrote a couple of years ago (and need to update). It's also referenced at the bottom of the OpenPKG documentation page. http://www.libertysoft.org/openpkg/overview/ David Fetter, also has written quite a bit, certainly more detailled than mine. This is also referenced on the OpenPKG documentation page. http://www.cns.pdx.edu/documentation/openpkg/psu_unofficial_openpkg_howto.html I will be updating this document within the next few months as well to reflect either things that haven't been documented yet but need to be or changes just for better or more efficient methods I have found in testing. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC 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/ Many companies that have made themselves dependent on [the equipment of a certain major manufacturer] (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Updated Mailman RPM
On Sat, 2005-05-21 at 21:28 +0200, Ralf S. Engelschall wrote: The remaining changes you've made for making the user/group configurable I've also not taken over as it is a little bit against the general principle of having all OpenPKG packages fit together and of having the OpenPKG instance fully self-contained. The default user/group should fit what the MTAs expect, shouldn't it? If we allow the user/group to be changed, a totally different package comes out which mainly exists just to integrate better with software _outside_ OpenPKG, right? I see the motivation for adding this flexibility, but OTOH if we go into this direction for the mailman package, why are we not doing it also for all other packages? If we really need this flexibility, I think a more general solution (perhaps doing a --rebuild --musr foo --mgrp foo) should be provided... The main reason for adding an option to change the musr mgrp is so that we can add this change into the build file for automated rebuilding. If we have to manually rebuild the package with those options then it defeats the ability of rebuilding the software using the build file. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: New Dependency Problem
On Thu, 2005-04-28 at 07:48 +0200, Michael van Elst wrote: On Wed, Apr 27, 2005 at 03:57:20PM -0700, David M. Fetter wrote: Ok, so the installed postgresql7 does show this: Hmmm, well, we didn't build it 'with_mta=yes'. The installed instance of openpkg-import shows: What does the index show ? resource equ=noopenpkg-import::with_mta/resource resource equ=sendmailopenpkg-import::with_mta_path/resource resource equ=0-2.3.0openpkg-import/resource -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
New Dependency Problem
In OpenPKG 2.3, we have the choice of either using postgresql (which is postgresql v8) or postgresql7. We chose to stay with postgresql7 for now as more significant testing needs to be done to do the upgrade for us. Now when I try to do a rebuild I get the following: FATAL: errors occured while building: bind-9.3.0-2.3.0: bind searches a frood called 'postgresql' jabberd-2.0s6-2.3.1: jabberd searches a frood called 'postgresql' openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 Now, it does seem that bind and jabberd could be built to use postgresql, however we didn't build it with enabling that option. It seems like an issue is present where bind and jabberd is requiring postgresql, when in fact it should only be required of the options that build them with postgresql support are enabled. As far as the openpkg-import and sendmail conflict goes. I'm not sure as of yet what that conflict might be, but it seems to be reporting such. Also, something of note is that this dilemma seems to only occur on our Solaris build server but not on our Linux build server. Anybody have any ideas about this or can it be fixed as a UPD? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: New Dependency Problem
On Thu, 2005-04-28 at 00:21 +0200, Michael van Elst wrote: On Wed, Apr 27, 2005 at 03:08:26PM -0700, David M. Fetter wrote: FATAL: errors occured while building: bind-9.3.0-2.3.0: bind searches a frood called 'postgresql' jabberd-2.0s6-2.3.1: jabberd searches a frood called 'postgresql' This means it requires 'postgresql' which doesn't exist. Now, the postgresql7 package should also provide 'postgresql'. I don't know why it isn't found. Ok, so the installed postgresql7 does show this: Provides: postgresql7::with_server = yes postgresql7::with_cxx = no postgresql7::with_perl = yes postgresql7::with_odbc = yes postgresql7::with_compat = no postgresql7::with_tcl = yes postgresql7::with_slony1 = no postgresql7::with_pgpool = no postgresql postgresql7 postgresql7 = 7.4.7-20050407 So, yes, it should be detecting that, but it's not. openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 When openpkg-import is built with 'with_mta=yes' then it makes available the MTA of the operating system to the OpenPKG instance. This conflicts with the packages exim, postfix, sendmail, ssmtp. There can be only one MTA. Hmmm, well, we didn't build it 'with_mta=yes'. The installed instance of openpkg-import shows: Provides: openpkg-import::with_mta = no openpkg-import::with_mta_path = sendmail openpkg-import = 0-2.3.0 -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: postrgresql7 and perl-openpkg dependency issue (fixed)
On Fri, 2005-04-08 at 08:46 +0200, Ralf S. Engelschall wrote: On Thu, Apr 07, 2005, David M. Fetter wrote: There was another little glitch with the provides line. Somehow, based on what it previously had in the provides the build tools showed the following: postgresql- NEW postgresql-7.4.7-20050407 postgresql7-7.4.7-20050407 OK Not exactly sure where it was getting the postgresql- from, but I changed the provides to just be postgresql and postgresql7. That seemed to resolve that issue as well. Hmmm... this Provides: name = version in a package nameX is what we are doing all the time and since ever. It allows package nameX to act as a full alternative to package name. The above is perhaps a little buglet in the openpkg build program? That could be, however, it seemed that when I changed it, I no longer had it show up as postgresql-. There very well could be a correlation though. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
RPM Upgrade Conflicts
It seems that when most of the rpms that have config files are upgraded, the working config is moved to some *.rpmsave file and the new one is put into place. What this basically means is that any services on a server where we might upgrade an rpm on will temporarily break. Most other linux distributions will put the new config with an upgraded package as *.rpmnew instead of moving aside the working config. Then it would be up to the administrators to do a comparison to see if anything needs to be added or modified between the working config and the new config. This seems to be a better approach so that running services are not broken in the middle of upgrading a package. Why does OpenPKG move the working config aside instead? Can this be changed so the packages with configs will copy the new config as *.rpmnew so running services don't break? The problem that I'm trying to solve here is that we want to have a certain portion of rpms automatically updated on a weekly basis as needed in a more or less hands off fashion, but if the upgrade means that the services break because the running config is moved aside, then that's not possible. Any comments? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: RPM Upgrade Conflicts
On Fri, 2005-04-08 at 20:59 +0200, Michael van Elst wrote: On Fri, Apr 08, 2005 at 11:39:33AM -0700, David M. Fetter wrote: It seems that when most of the rpms that have config files are upgraded, the working config is moved to some *.rpmsave file and the new one is put into place. What this basically means is that any services on a server where we might upgrade an rpm on will temporarily break. This assumes that the new software is able to work correctly with the old config files. This might be even true for most popular packages most of the time but for a real production environment you want some proper configuration management. Right. We actually have cfengine too for all of our configs. The dilemma is that when an rpm is updated it moves the config aside then restarts and bam we have downtime upon update. Cfengine comes along every 10 or 15 minutes and puts the proper config back into place, but we don't use cfengine to restart most of the services due to some issues we have had with trying to do it that way. So, the problem I'm trying to point out is that moving aside the running configs could cause unnecessary downtime even if it is for 10 or 15 minutes. Any down time is generally not good. Now I can understand that the some software won't work at all with an old config and I think at that juncture it is suitable for the running config to be moved aside to an *.rpmsave. It makes it so that it is blatantly obvious that the admin has to review it right away. However, most of the time, the running config works with slightly newer revisions of software and at that point it makes more sense to copy the new config to *.rpmnew so that when the admin has time they can go review the differences. It isn't really a matter of neglect on the admins' side of things, but in general most unix shops are understaffed and/or shorthanded due to the number of outstanding projects, so they may not have time to review every new config for every package and if it's not immediately necessary then why should they be forced to do that? In our shop, it is a goal to cut down the maintenance cost of maintaining software in general. Part of this project ended up using the fine OpenPKG product to assist with a good portion of the software management. We still have about 20-30 pieces of software that we have to manually maintain and keep current, but for the other 500+ pieces we are trying to incorporate it into an auto-update procedure. If it is the philosophy of OpenPKG to always move aside running configs to *.rpmsave regardless of whether it is necessary or not, then I suppose we will just need to manually update those pieces of software as well and pull them out of the automated update process. Unfortunately, this takes away from lowering the overall maintenance cost. All I'm trying to do is to see if I can bring up the discussion and maybe ultimately change the way the configs are handled during an upgrade of a package so that the maintenance cost can stay as minimal as possible. I completely agree with what you're saying and in a perfect world every admin would have the time to properly review thoroughly each piece of software prior to upgrade as well as each individual patch for the underlying OS. This, however, is not a perfect world and so we admins must make do and do the best we can to maintain stability in our environments. It becomes even more difficult to manage config changes like this with the more servers you have. From this stand point, it seems logical that there are reasons for using *.rpmnew and *.rpmsave for configs. Most of the time, *.rpmnew is sufficient and that's good because it can keep the maintenance costs down. When a piece of software changes a config so radically that it won't function with an old config, then using *.rpmsave to move aside the running config makes more sense. That is basically how I see it from the administrative aspect. I hope this makes some sense. I'm not trying to ruffle feathers or anything, I'm just trying to state what I think is a valid point. Thanks. Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
postrgresql7 and perl-openpkg dependency issue (fixed)
I had a dependency issue for some reason regarding installing postgresql7 from current. When I was trying to install it via the openpkg build tools, it responded with an error about how it was searching for a frood called perl-openpkg. This package is in fact installed, so I don't know why it couldn't find it. It found it when rebuilding the rpm. What I did is changed the PreReq to just require perl while leaving the BuildPreReq with the perl-openpkg dependency. As far as I can tell the only real dependency for perl-openpkg is during the rebuild of postrgresql7, so this should be a suitable fix. This fix does resolve the issue I was seeing and now the upgrade is moving along fine. I uploaded the new revised spec file for this. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: postrgresql7 and perl-openpkg dependency issue (fixed)
There was another little glitch with the provides line. Somehow, based on what it previously had in the provides the build tools showed the following: postgresql- NEW postgresql-7.4.7-20050407 postgresql7-7.4.7-20050407 OK Not exactly sure where it was getting the postgresql- from, but I changed the provides to just be postgresql and postgresql7. That seemed to resolve that issue as well. On Thu, 2005-04-07 at 14:16 -0700, David M. Fetter wrote: I had a dependency issue for some reason regarding installing postgresql7 from current. When I was trying to install it via the openpkg build tools, it responded with an error about how it was searching for a frood called perl-openpkg. This package is in fact installed, so I don't know why it couldn't find it. It found it when rebuilding the rpm. What I did is changed the PreReq to just require perl while leaving the BuildPreReq with the perl-openpkg dependency. As far as I can tell the only real dependency for perl-openpkg is during the rebuild of postrgresql7, so this should be a suitable fix. This fix does resolve the issue I was seeing and now the upgrade is moving along fine. I uploaded the new revised spec file for this. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build -A -U problem
It seems that the fixes that were put into place have resolved the issues I was seeing now. Thank you. We can now commence with total world domination!!! Muhahahaha! ;-) On Thu, 2005-03-24 at 08:05 +0100, Ralf S. Engelschall wrote: On Thu, Mar 24, 2005, Michael van Elst wrote: On Wed, Mar 23, 2005 at 01:39:05PM -0800, David M. Fetter wrote: Haha. I was wondering about that when I was doing it. Ok, well, here is the debug from the -a -U then. However, it still seemed to have an issue. Ok. The bug is far away from what I thought. The problem was that a requirement for a package option (such as openssl::with_threads) is matched by multiple packages (i.e. version 2.3.0 and 2.3.1) and then sorted by the option value instead of by the package version to select a 'best' choice. Since the option value in this case is the default value it is 'no' vs 'no' and the result depends on the internal perl hash function, i.e. it is random and machine dependent. Fixing this required some bigger changes, so I need more testing time. I've rolled your last two fixes to openpkg build into the new OpenPKG-CURRENT package openpkg-tools-0.8.34-20050324. This way people can test your changes easily... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build -A -U problem
On Wed, 2005-03-23 at 11:40 -0800, David M. Fetter wrote: Can you verify that 'openpkg build -u -A' doesn't show the same pecularities ? I'm running this now. I will let you know when it finishes. Thanks. I attached the output for the -u -A run, but it seems to still show the same issue. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu debug_output-u.tar.bz2 Description: application/bzip-compressed-tar signature.asc Description: This is a digitally signed message part
Re: openpkg build -A -U problem
On Wed, 2005-03-23 at 22:10 +0100, Michael van Elst wrote: Ouch. I meant -U -a of course :-| -A - select all packages in the index -a - select all packages that are installed Haha. I was wondering about that when I was doing it. Ok, well, here is the debug from the -a -U then. However, it still seemed to have an issue. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu debug_output-a.tar.bz2 Description: application/bzip-compressed-tar signature.asc Description: This is a digitally signed message part
openpkg build -A -U problem
I'm working on building a new binary repository out of the latest 2.3 release, but I'm coming across an issue with openssl. When I do an 'openpkg build -A -U' initially I get: openssl-0.9.7e-2.3.0UPDATE openssl-0.9.7e-2.3.1 Then when I execute 'openpkg build -A -U' a second time to make sure everything is updated properly, it comes back with: openssl-0.9.7e-2.3.1UPDATE openssl-0.9.7e-2.3.0 This problem causes many packages to want to be rebuilt due to the dependencies of dependencies, etc. I have seen something similar with the 2.1 release as well. Is anybody aware of this problem? Has anybody else seen this? It seems to be only on Solaris because we build under RHEL3 and I don't have the same problem there. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build -A -U problem
On Tue, 2005-03-22 at 22:35 +0100, Michael van Elst wrote: On Tue, Mar 22, 2005 at 09:13:42AM -0800, David M. Fetter wrote: I'm working on building a new binary repository out of the latest 2.3 release, but I'm coming across an issue with openssl. When I do an 'openpkg build -A -U' initially I get: openssl-0.9.7e-2.3.0UPDATE openssl-0.9.7e-2.3.1 If you have 2.3.0 and 2.3.1 then you have the update packages in your repository. In that case the first installation of openssl should pick the update (i.e. 2.3.1). So what is 'initially' ? How did you install 2.3.0 ? Initially, is just the first time I run it. Then the second it returns the next results. Then when I execute 'openpkg build -A -U' a second time to make sure everything is updated properly, it comes back with: openssl-0.9.7e-2.3.1UPDATE openssl-0.9.7e-2.3.0 This looks like 2.3.1 is no longer avaible in the repository. They are both there. Do you install directly from ftp.openpkg.org ? No, I rsync my own local copy of the src rpms, which then removes about 30 or so of them that we don't want available, then rebuild the src rpm index and run the build command. The local src rpm repository has the base SRC with PLUS and UPD as subdirectories. Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build -A -U problem
On Tue, 2005-03-22 at 23:45 +0100, Michael van Elst wrote: On Tue, Mar 22, 2005 at 02:04:48PM -0800, David M. Fetter wrote: openssl-0.9.7e-2.3.0UPDATE openssl-0.9.7e-2.3.1 So what is 'initially' ? How did you install 2.3.0 ? Initially, is just the first time I run it. Then the second it returns the next results. The output (which is from build -s) says you already have 2.3.0 installed and the index contains the version 2.3.1. as an update. So how did you install openssl-0.9.7e-2.3.0 ? The first time a 'build -s' would return something like: openssl ADD openssl-0.9.7e-2.3.1 The first time was an upgrade from 2.1 to 2.3. I don't have the status output from that point from my test server anymore. Now it just goes back and forth and wants to go from one to the other. The src rpm repository is the same each time, so it includes both the openssl-0.9.7e-2.3.0 and openssl-0.9.7e-2.3.1 versions within the newly generated index file. There is more output than just this bit, which is as far as I can tell just flopping back and forth. I'm looking through the list to see if there might be something that is calling for a specific revision or something in a spec file as a dependency. I'm also trying to get a clean sample of the entire status output so I can send that. It takes a bit to run through it all and do the compiles so I might not be able to get it until tomorrow. and a simple 'build openssl' returns something like: echo ftp://ftp.openpkg.org/release/2.3/UPD/openssl-0.9.7e-2.3.1.src.rpm /usr/local/openpkg/bin/openpkg rpm --rebuild ftp://ftp.openpkg.org/release/2.3/UPD/openssl-0.9.7e-2.3.1.src.rpm || exit $? /usr/local/openpkg/bin/openpkg rpm -Uvh /usr/local/openpkg/RPM/PKG/openssl-0.9.7e-2.3.1.ix86-netbsd2.0-ulo.rpm || exit $? echo ftp://ftp.openpkg.org/release/2.3/UPD/openssl-0.9.7e-2.3.1.src.rpm = $? Do you install directly from ftp.openpkg.org ? No, I rsync my own local copy of the src rpms This at least rules out intermittent problem with the index. BTW, what perl is used when you run the build tool ? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
AMD Fix Uploaded to Contrib
I just uploaded a new AMD source rpm into the contrib. This source removes the restarting of AMD after any sort of upgrade or removal of the package. It also removes the log rotation bit with the restart. Restarting AMD while it is in use is a serious problem. Since amd has low level hooks into kernel space, if users or processes happen to be using an area that is automounted via AMD and it restarts on them, it basically can cause the entire server to come to a crashing halt. These bits shouldn't be included as part of the rpm itself. In my opinion, this bug is catastrophic enough that it probably should be fixed in UPD for the current release (after testing of course), but that's just my opinion and the rollout philosophy may differ for you guys. Anyway, I just wanted to send an email to explain the update. Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: AMD Fix Uploaded to Contrib
On Mon, 2005-03-07 at 21:56 +0100, Michael van Elst wrote: On Mon, Mar 07, 2005 at 12:18:03PM -0800, David M. Fetter wrote: David, Restarting AMD while it is in use is a serious problem. restarting AMD is usually not a problem. You should use the restart_mounts option or you have to clean up the mounts yourself. You should not use the unmount_on_exit option because unmounting might not work if a filesystem is busy. Hmmm. We went to look up these options in the AMD book we have and it seems that perhaps these options might solve our problems. We will try that on a test server and see. Thanks. Since amd has low level hooks into kernel space, if users or processes happen to be using an area that is automounted via AMD and it restarts on them, it basically can cause the entire server to come to a crashing halt. Areas that are automounted are conventional mounts that are not affected by AMD. AMD just provides links and, unlike autofs, doesn't hook into kernel space. More of a problem are NFS servers that do not respond. This may freeze amd when it tries to unmount such a server and often causes large delays when it tries to restart an existing mount to such a server. If you automount /home or use an automounted directory accessed in the shell profile you may not be able to log into the server anymore. If your entire server comes to a crashing halt then something else is wrong. Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: AMD Fix Uploaded to Contrib
On Mon, 2005-03-07 at 14:08 -0800, Bill Campbell wrote: On Mon, Mar 07, 2005, Michael van Elst wrote: On Mon, Mar 07, 2005 at 12:18:03PM -0800, David M. Fetter wrote: David, Restarting AMD while it is in use is a serious problem. restarting AMD is usually not a problem. You should use the restart_mounts option or you have to clean up the mounts yourself. You should not use the unmount_on_exit option because unmounting might not work if a filesystem is busy. Since amd has low level hooks into kernel space, if users or processes happen to be using an area that is automounted via AMD and it restarts on them, it basically can cause the entire server to come to a crashing halt. Areas that are automounted are conventional mounts that are not affected by AMD. AMD just provides links and, unlike autofs, doesn't hook into kernel space. More of a problem are NFS servers that do not respond. This may freeze amd when it tries to unmount such a server and often causes large delays when it tries to restart an existing mount to such a server. If you automount /home or use an automounted directory accessed in the shell profile you may not be able to log into the server anymore. I've seen problems with Linux servers with multiple IP aliases on the interface where some Mac OS X systems couldn't connect. Doing some sniffing, I found that the Linux server, for some odd reason, was replying with UDP packets from one of the alias addresses, not the primary (eth0) address. My fix was to force the Apple to use tcp, which is probably more efficient in any case. Ah, yes. Most of our servers use virtual ip addresses. Not sure if this could cause extra grief or not. Also, I still might have to maintain that none of the rpms should ever do a restart on their own. This should be a controlled thing that is done through some administrative function. In our environment, one of the biggest problems with OpenPKG right now is that they all want to restart on on upgrade. We cannot have this happen without explicit control and timing over it. It seems to me that this would cause for concern in any production environment. I mean upgrading the software is one thing but willy-nilly restarting it seems a little more unpredictable. I want to be able to upgrade a piece of software, verify it's installation, then do a restart. Not upgrade the software and have it automagically perform the restart while hoping that things do not go awry. Does that make some sense? Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC 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/ ``Are we at last brought to such a humiliating and debasing degradation, that we cannot be trusted with arms for our own defense? Where is the difference between having our arms in our own possession and under our own direction, and having them under the management of Congress? If our defense be the real object of having those arms, in whose hands can they be trusted with more propriety, or equal safety to us, as in our own hands?'' -- Patrick Henry June 9, 1788, in the Virginia Convention on the ratification of the Constitution. __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Expect Tcl Dependency Problem
On Fri, 2005-03-04 at 09:17 +0100, Ralf S. Engelschall wrote:
On Thu, Mar 03, 2005, David M. Fetter wrote:
Something seems wrong with how Expect and Tcl interacts in regards to
dependencies. The problem occurs if you have a prior version of Tcl and
Expect installed, then go to upgrade to any other version. What happens
is that the update fails when trying to upgrade Tcl using the build
tools. It seems to be because Expect has a specific version of Tcl
required in it's Requires section. Since Expect has Tcl as a
requirement then the build tool sees that Tcl should be upgraded before
Expect as per the order it derives based on what exists in the Require
section of all of the rpms. However, since Expect has a specific
version of Tcl required, the update of the newer Tcl fails because the
currently old Expect that is installed requires an older specific
version of Tcl. I'm thinking that line #61 of the expect.spec file
should be:
PreReq: OpenPKG, openpkg = 2.3.0, tcl = %{V_tcl}
Instead of:
PreReq: OpenPKG, openpkg = 2.3.0, tcl = %{V_tcl}
Line #60, which is the BuildPreReq, has the same line. I'm not sure if
this should be changed though. I'm thinking that only the PreReq should
be changed while the BuildPreReq stays with the specific version as that
seems that it would logically function as is needed and not break
updating from an older version to newer as well. Does this logic seem
proper to you guys?
Hmmm... yes, this is a reasonable idea. The BuildPreReq we definitely
cannot change because Expect requires definitely _both_ the sources and
the installed files and if they do not match it too easily can break
under build-time. But relaxing the PreReq is a very good idea because
a break under run-time is less likely and it would be broken usually
during updates only. I've relaxed the dependency now as you suggested:
http://cvs.openpkg.org/chngview?cn=22400
Thanks for the idea.
Super! Yes, it seems that the main problem with RPM or rather it's one
weakness is still based on human error. If the dependencies are not
properly thought it in a clear logical method then all things good will
become chaos. Thanks. ;-)
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Expect Tcl Dependency Problem
Something seems wrong with how Expect and Tcl interacts in regards to
dependencies. The problem occurs if you have a prior version of Tcl and
Expect installed, then go to upgrade to any other version. What happens
is that the update fails when trying to upgrade Tcl using the build
tools. It seems to be because Expect has a specific version of Tcl
required in it's Requires section. Since Expect has Tcl as a
requirement then the build tool sees that Tcl should be upgraded before
Expect as per the order it derives based on what exists in the Require
section of all of the rpms. However, since Expect has a specific
version of Tcl required, the update of the newer Tcl fails because the
currently old Expect that is installed requires an older specific
version of Tcl. I'm thinking that line #61 of the expect.spec file
should be:
PreReq: OpenPKG, openpkg = 2.3.0, tcl = %{V_tcl}
Instead of:
PreReq: OpenPKG, openpkg = 2.3.0, tcl = %{V_tcl}
Line #60, which is the BuildPreReq, has the same line. I'm not sure if
this should be changed though. I'm thinking that only the PreReq should
be changed while the BuildPreReq stays with the specific version as that
seems that it would logically function as is needed and not break
updating from an older version to newer as well. Does this logic seem
proper to you guys?
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: Expect Tcl Dependency Problem
On Thu, 2005-03-03 at 13:25 -0800, Bill Campbell wrote: On Thu, Mar 03, 2005, David M. Fetter wrote: Something seems wrong with how Expect and Tcl interacts in regards to dependencies. The problem occurs if you have a prior version of Tcl and Expect installed, then go to upgrade to any other version. What happens ... Line #60, which is the BuildPreReq, has the same line. I'm not sure if this should be changed though. I'm thinking that only the PreReq should be changed while the BuildPreReq stays with the specific version as that seems that it would logically function as is needed and not break updating from an older version to newer as well. Does this logic seem proper to you guys? This is a long-standing issue. My solution has been to massage the output of ``openpkg build'' to add ``--nodeps'' to the installation commands for tcl and expect before running the generated script. Is this massaging part of the build tools or something you are stating you do manually? 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/ If you want government to intervene domestically, you're a liberal. If you want government to intervene overseas, you're a conservative. If you want government to intervene everywhere, you're a moderate. If you don't want government to intervene anywhere, you're an extremist -- Joseph Sobran __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
gettext can't find charset under RHEL3
It seems that gettext can't locate the libcharset when rebuilding the rpm from OpenPKG 2.3 src.rpm. If I add 'LIBS=-lcharset' after the CFLAGS line (line # 93), then it builds fine. I tested this and it works fine rebuilding the package under both RHEL3 and Solaris 9. I uploaded the updated spec file as well. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] OpenPKG 2.3
It doesn't seem to have it listed in your rsync area. rsync rsync://rsync.openpkg.org/openpkg-ftp/release/ drwxrwxr-x 512 2005/02/21 09:14:09 . -rw-r--r-- 181 2003/03/05 08:28:54 00README drwxr-xr-x 512 2005/02/14 00:45:42 1.0 drwxr-xr-x 512 2005/02/14 00:45:45 1.1 drwxr-xr-x 512 2005/02/14 00:45:48 1.2 drwxr-xr-x 512 2005/02/14 00:45:51 1.3 drwxr-xr-x 512 2004/07/15 02:47:23 2.0 drwxr-xr-x 512 2004/10/11 11:36:50 2.1 drwxr-xr-x 512 2004/10/20 00:28:11 2.2 That's all that shows up. On Thu, 2005-02-24 at 18:41 +0100, Christoph Schug wrote: On Thu, Feb 24, 2005, Bill Campbell wrote: On Thu, Feb 24, 2005, OpenPKG wrote: The OpenPKG project releases version 2.3 of the unique cross-platform software packaging facility. Nothing on ftp.openpkg.org yet? - ftp://ftp.openpkg.org/release/2.3/ What's the matter? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Apache 1 and 2 should conflict.
We should they conflict? In our environment we actually have specific need to run both versions. We cannot have both installed however due to as far as we can tell only two conflicting files which are a man page and logrotate. Personally, it seems to me that it would be better to rename the conflicting man page and rename the logrotate to logrotate2 thus following the pattern already defined. On Mon, 2005-02-14 at 08:45 +0100, Matthias Kurz wrote: All said. (mk) -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Apache 1 and 2 should conflict.
On Mon, 2005-02-14 at 21:51 +0100, Matthias Kurz wrote: On Mon, Feb 14, 2005, David M. Fetter wrote: We should they conflict? In our environment we actually have specific need to run both versions. We cannot have both installed however due to as far as we can tell only two conflicting files which are a man page and logrotate. Personally, it seems to me that it would be better to rename the conflicting man page and rename the logrotate to logrotate2 thus following the pattern already defined. There are conflicting files. And this is why i thought, they should conflict. Either, this, or someone should fix the conflicts. Ah, yes. I believe one of our crew here is working on fixing the conflicts of which will be submitted sometime in the future. But this is not my real problem. There are some packages, that Require: apache, and therefor it is compiled all the time. Yes, what would be nice is if we could make a Require statement that can include something like apache||apache2. That would be helpful in numerous cases. There is no need for action by anyone, because i said this. For me this is currently more or less a cosmetical problem. When there is real need, i'll speak up again. (mk) On Mon, 2005-02-14 at 08:45 +0100, Matthias Kurz wrote: All said. (mk) -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
[Fwd: Re: OpenPKG Dependency Loop?]
I'm thinking that this thread should be forwarded to the dev list. Do you have any input? Forwarded Message From: David M. Fetter [EMAIL PROTECTED] Reply-To: openpkg-users@openpkg.org To: openpkg-users@openpkg.org Subject: Re: OpenPKG Dependency Loop? Date: Thu, 10 Feb 2005 10:49:14 -0800 Ok, that's what I was thinking as well. I just wanted to confirm my suspicions. Will this be fixed or is it just going to be ignored since the latest release is 2.2 and 2.3 is soon to be released? On Thu, 2005-02-10 at 07:15 +0100, Michael van Elst wrote: On Wed, Feb 09, 2005 at 04:30:27PM -0800, David M. Fetter wrote: openpkg-2.1.2-2.1.2,openpkg-20040825-20040825 This is supposed to be one package name with version and revision information. I guess there is a typo in a requirement or provides where the entries are not whitespace but comma separated. Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
[Fwd: openpkg rc conflicts]
I didn't see a response from this bug report when I sent it to the users list, so I thought I would forward it to the dev list in case I sent it to the wrong list. Any comments on whether this will be fixed in 2.3? Right now, we are running with 2.1, but we will be rolling out 2.3 when it is released. I'm trying to submit all of our spec files and bugs that we have come across in hopes they will be addressed in the 2.3 release. Thanks. Forwarded Message From: David M. Fetter [EMAIL PROTECTED] Reply-To: openpkg-users@openpkg.org To: openpkg-users@openpkg.org Subject: openpkg rc conflicts Date: Fri, 07 Jan 2005 16:48:36 -0800 There seems to be an issue within openpkg somewhere within it's own rc bits. We originally found that when we would execute openpkg rc eval, we would get strange errors. We discovered through tracing the process out originally on our solaris systems and found that the openpkg rc got confused somehow and was calling the rpm package rc, which is the Plan9 shell. We resolved this problem on our own by removing and no longer installing the rc rpm. We now have found that we are having a similar confusion problem coming from openpkg rc eval on our RHEL3 linux systems. It is specifically related to linux now since we don't install the rc rpm, however RHEL3 linux using the /etc/rc system to do it's own initialization. Somehow openpkg rc is confusing it's own rc call with the /etc/rc under RHEL3 and we are having errors spawn do to this. A specific effect of this problem is that none of the services we run respond to an openpkg rc restart. To work around this problem we have been doing a stop, then a start manually. We're not quite sure how openpkg rc is getting confused with the other rc's, but perhaps openpkg rc should have some sort of hard set full path to the openpkg rc bit itself? Thus it wouldn't get confused like this? Anyway, we wanted to let you know about this one as well. Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
[Fwd: [SAMBA] CAN-2004-1154 : Integer overflow could lead to remote code execution in Samba 2.x, 3.0.x = 3.0.9]
In case you guys weren't aware of this. Also, I will be working on adding ads support into the samba openpkg rpm in the near future. Forwarded Message From: Gerald Carter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [SAMBA] CAN-2004-1154 : Integer overflow could lead to remote code execution in Samba 2.x, 3.0.x = 3.0.9 Date: Thu, 16 Dec 2004 06:17:29 -0600 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == == == Subject: Possible remote code execution == CVE ID#: CAN-2004-1154 == == Versions:Samba 2.x 3.0.x = 3.0.9 == == Summary: A potential integer overflow when == unmarshalling specific MS-RPC requests == from clients could lead to heap == corruption and remote code execution. == == === Description === Remote exploitation of an integer overflow vulnerability in the smbd daemon included in Samba 2.0.x, Samba 2.2.x, and Samba 3.0.x prior to and including 3.0.9 could allow an attacker to cause controllable heap corruption, leading to execution of arbitrary commands with root privileges. Successful remote exploitation allows an attacker to gain root privileges on a vulnerable system. In order to exploit this vulnerability an attacker must possess credentials that allow access to a share on the Samba server. Unsuccessful exploitation attempts will cause the process serving the request to crash with signal 11, and may leave evidence of an attack in logs. == Patch Availability == A patch for Samba 3.0.9 (samba-3.0.9-CAN-2004-1154.patch) can be downloaded from http://www.samba.org/samba/ftp/patches/security/ The patch has been signed with the Samba Distribution Verification Key (ID F17F9772). = Protecting Unpatched Servers = The Samba Team always encourages users to run the latest stable release as a defense against attacks. However, under certain circumstances it may not be possible to immediately upgrade important installations. In such cases, administrators should read the Server Security documentation found at http://www.samba.org/samba/docs/server_security.html. === Credits === This security issue was reported to Samba developers by iDEFENSE Labs. The vulnerability was discovered by Greg MacManus, iDEFENSE Labs. == == Our Code, Our Bugs, Our Responsibility. == The Samba Team == -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBwXzZIR7qMdg1EfYRAqv1AJ9FqoFnBPnjNMGVjlsjO47yAk/UYACg9KMa L+VEkr69J9oGg48m771bC7U= =gtGA -END PGP SIGNATURE- -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: OpenPKG Tool Update Problem Persists
Yes, that message was tcl requires with_x11. I had added that to the build file, but for some reason the double requirement is causing the openpkg tool to choke and not do the right thing. That is my problem here. On Fri, 2004-11-19 at 00:21 +0100, Michael van Elst wrote: On Thu, Nov 18, 2004 at 02:13:48PM -0800, David M. Fetter wrote: and force install the resulting binary rpm. I received this error message when initially trying: FATAL: errors occured while building: postgresql-7.4.3-2.1.0: postgresql has conflicting requirement There is another message in the output that tells you what requirement did conflict. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
OpenPKG Tool Update Problem Persists
Ok, so I have a problem that seems to be able to be replicated where the update doesn't work for binary rpms on client systems. Perhaps this will help you help me out with this issue. Here it is... 1. Rebuild and install all release src rpms with only the default options on a separate build server. For the sake of consistency and the feel of a clean room type setup, do this test as root where the environment is identical on both servers. 2. Copy all of the created binary rpms into some sort of repository for client systems after which build a new index file for them. 3. On a client system of like hardware architecture and OS, install only the binary rpms created on the build server using a command like: `openpkg build -r /the/repos/path/ -p $arch -f /the/repos/path/index.rdf -A -i | sh` 4. Create a build file under root's home dir at ~/.openpkg/build which should exist on all systems with the following options: -Dtcl::with_x11=yes -Dpostgresql::with_server=yes -Dpostgresql::with_odbc=yes -Dpostgresql::with_tcl=yes -Dpostgresql::with_perl=yes The focus rpms in this example are tcl and postgresql. The tcl package requires with_x11 when you enable with_tcl for postgresql. 5. Now go back to the build server and rebuild the tcl and postgresql packages. Some problem here caused me to have to manually rebuild tcl and force install the resulting binary rpm. I received this error message when initially trying: FATAL: errors occured while building: postgresql-7.4.3-2.1.0: postgresql has conflicting requirement Afterward, the openpkg tools found that postgresql needed to be rebuilt with new options and did so. 6. Copy the newly rebuilt binary rpms into the repository you created previously and regenerate a new index file. 7. Go to the client system and attempt to update the system using a similar command to the one in step 3. I initially received the same error I showed in step 5 but after I force installed tcl, then it caught that postgresql had an option update and installed properly. This seems to be a consistent problem and should be able to be reproduced. The problem here is that the client update fails even though the build file does exist on all systems. I have had a similar problem with OpenSSH and GCC, though not with some other packages. It seems to only affect some rpms and not all. Can anybody help me resolve this issue because currently it is a major stopping block as the client systems aren't getting their updates automagically as they should due to this error? Thank you. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
snmp build error
Ok, I'm getting this build error now when I manually try to build snmp with the following command: openpkg rpm --rebuild --define 'with_mib_host yes' --define 'with_perl yes' snmp-5.1.1-2.1.0.src.rpm /bin/sh ../../libtool --silent --mode=compile /usr/local/bin/gcc -I../../include -I../../include -I. -I../.. -I. -I./../.. -I./../../snmplib -I./.. -I.. -I/usr/local/include -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/lib/perl/5.8.4/sun4-solaris/CORE -O2 -pipe -I/usr/local/include -Dsolaris2 -c -o host/hr_storage.lo host/hr_storage.c host/hr_storage.c: In function `sol_get_swapinfo': host/hr_storage.c:845: error: storage size of 'ainfo' isn't known host/hr_storage.c:847: error: `SC_AINFO' undeclared (first use in this function)host/hr_storage.c:847: error: (Each undeclared identifier is reported only once host/hr_storage.c:847: error: for each function it appears in.) make[2]: *** [host/hr_storage.lo] Error 1 make[1]: *** [subdirs] Error 1 make: *** [subdirs] Error 1 Anybody know what the issue is or how to resolve it? Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: snmp build error
I tried with the snmp srpm out of current and got the same results. This is on a Solaris 9 Sparc system with the latest patch cluster. On Tue, 2004-09-28 at 07:22, David M. Fetter wrote: Ok, I'm getting this build error now when I manually try to build snmp with the following command: openpkg rpm --rebuild --define 'with_mib_host yes' --define 'with_perl yes' snmp-5.1.1-2.1.0.src.rpm /bin/sh ../../libtool --silent --mode=compile /usr/local/bin/gcc -I../../include -I../../include -I. -I../.. -I. -I./../.. -I./../../snmplib -I./.. -I.. -I/usr/local/include -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/lib/perl/5.8.4/sun4-solaris/CORE -O2 -pipe -I/usr/local/include -Dsolaris2 -c -o host/hr_storage.lo host/hr_storage.c host/hr_storage.c: In function `sol_get_swapinfo': host/hr_storage.c:845: error: storage size of 'ainfo' isn't known host/hr_storage.c:847: error: `SC_AINFO' undeclared (first use in this function)host/hr_storage.c:847: error: (Each undeclared identifier is reported only once host/hr_storage.c:847: error: for each function it appears in.) make[2]: *** [host/hr_storage.lo] Error 1 make[1]: *** [subdirs] Error 1 make: *** [subdirs] Error 1 Anybody know what the issue is or how to resolve it? Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: snmp build error
On Tue, 2004-09-28 at 13:06, Michael van Elst wrote: On Tue, Sep 28, 2004 at 07:22:04AM -0700, David M. Fetter wrote: host/hr_storage.c: In function `sol_get_swapinfo': host/hr_storage.c:845: error: storage size of 'ainfo' isn't known host/hr_storage.c:847: error: `SC_AINFO' undeclared (first use in this function)host/hr_storage.c:847: error: (Each undeclared identifier is Anybody know what the issue is or how to resolve it? Thanks. Apparently mib_host is broken for Solaris. Well, it seems that if I rebuild snmp with only the mib_host option then it successfully builds. However, if I rebuild snmp with only the perl option then it also successfully builds. If I use both options together then it fails with the error I gave before. So, something is definitely wrong here, but perhaps it is mibs host only with the perl module? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: lprng and ifhp
I attached the rc scripts for tomcat5 and lprng here in case anybody
wants them, since I could upload them to the contrib area or the
src.rpms which contained them.
On Tue, 2004-09-21 at 12:26, David M. Fetter wrote:
Well, I tried to upload the src rpms for lprng and tomcat5 but they were
rejected in that form. I uploaded the spec files only. The rc scripts
won't upload due to some filename rejection. Not sure why the src rpms
failed. The rejection doesn't seem to indicate why.
On Tue, 2004-09-21 at 11:56, David M. Fetter wrote:
I also uploaded an lprng src rpm which includes and rc script and the
ifhp spec file.
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
Only those who attempt the absurd can achieve the impossible.
[EMAIL PROTECTED]@/lib/openpkg/bash @l_prefix@/etc/rc
##
## rc.lprng -- Run-Commands for LPRng daemon
##
%config
lprng_enable=$openpkg_rc_def
lprng_user=@l_musr@
lprng_group=@l_mgrp@
%common
[EMAIL PROTECTED]@/var/lprng/run/lprng.lock.*
lprng_signal() {
SIGNALTYPE=$1
overall_retval=0
for f in $lprng_pidfiles ; do
# catch fall-through case where no PID files are found
[ x${f} = [EMAIL PROTECTED]@/var/lprng/run/lprng.lock.* ] {
return 1
}
[ -f $f ] {
pid=`cat $f`
kill -${SIGNALTYPE} $pid
single_retval=$?
# if non-success error code, record it
[ $single_retval != 0 ] overall_retval=$single_retval
}
done
return $overall_retval
}
%status -u @l_susr@ -o
lprng_usable=unknown
lprng_active=no
rcService lprng enable yes \
lprng_signal 0 lprng_active=yes
echo lprng_enable=\$lprng_enable\
echo lprng_usable=\$lprng_usable\
echo lprng_active=\$lprng_active\
%start -u @l_susr@
rcService lprng enable yes || exit 0
rcService lprng active yes exit 0
@l_prefix@/sbin/lpd
%stop -u @l_susr@
rcService lprng enable yes || exit 0
rcService lprng active no exit 0
lprng_signal TERM
rm -f $lprng_pidfiles 2/dev/null || true
%restart -u @l_susr@
rcService lprng enable yes || exit 0
rcService lprng active no exit 0
rc lprng stop
sleep 2
rc lprng start
%daily -u @l_susr@
rcService lprng enable yes || exit 0
#!/usr/local/lib/openpkg/bash /usr/local/etc/rc
##
## rc.tomcat5 -- Run-Commands
##
%config
tomcat5_enable=$openpkg_rc_def
tomcat5_home=/usr/local/libexec/tomcat5
tomcat5_log_prolog=true
tomcat5_log_epilog=true
tomcat5_log_numfiles=10
tomcat5_log_minsize=1M
tomcat5_log_complevel=9
%common
tomcat5_pidfile=/usr/local/var/tomcat5/log/tomcat.pid
tomcat5_signal () {
[ -f $tomcat5_pidfile ] kill -$1 `cat $tomcat5_pidfile`
}
%status
tomcat5_usable=unknown
tomcat5_active=no
rcService tomcat5 enable yes \
tomcat5_signal 0 tomcat5_active=yes
echo tomcat5_enable=\$tomcat5_enable\
echo tomcat5_usable=\$tomcat5_usable\
echo tomcat5_active=\$tomcat5_active\
%start
rcService tomcat5 enable yes || exit 0
rcService tomcat5 active yes exit 0
JAVA_HOME=$java_home; export JAVA_HOME
CATALINA_HOME=$tomcat5_home; export CATALINA_HOME
CATALINA_OPTS=; export CATALINA_OPTS
CATALINA_PID=$tomcat5_pidfile; export CATALINA_PID
DAEMON_HOME=${CATALINA_HOME}/bin; export DAEMON_HOME
TOMCAT_USER=www; export TOMCAT_USER
TMP_DIR=/var/tmp; export TMP_DIR
CLASSPATH=${JAVA_HOME}/lib/tools.jar:${CATALINA_HOME}/bin/commons-daemon.jar:${CATALINA_HOME}/bin/bootstrap.jar;
export CLASSPATH
#
# Start Tomcat
#
$DAEMON_HOME/jsvc \
-user $TOMCAT_USER \
-home $JAVA_HOME \
-Dcatalina.home=$CATALINA_HOME \
-Djava.io.tmpdir=$TMP_DIR \
-outfile $CATALINA_HOME/logs/catalina.out \
-errfile '1' \
$CATALINA_OPTS \
-cp $CLASSPATH \
org.apache.catalina.startup.Bootstrap
#
# To get a verbose JVM
#-verbose \
# To get a debug of jsvc.
#-debug
%stop
rcService tomcat5 enable yes || exit 0
rcService tomcat5 active no exit 0
JAVA_HOME=$java_home; export JAVA_HOME
CATALINA_HOME=$tomcat5_home; export CATALINA_HOME
ps -ef|grep tomcat5|grep -v grep|awk '{print $2}'|xargs -t kill 12/dev/null
rm -f $tomcat5_pidfile 2/dev/null || true
%restart
rcService tomcat5 enable yes || exit 0
rcService tomcat5 active no exit 0
rc tomcat5 stop
rc tomcat5 start
%daily
rcService tomcat5 enable yes || exit 0
# rotate logfile
shtool rotate -f \
-n ${tomcat5_log_numfiles} -s ${tomcat5_log_minsize} -d \
-z ${tomcat5_log_complevel} -o www -g alummail -m 660 \
-P ${tomcat5_log_prolog} \
-E ${tomcat5_log_epilog} rc tomcat5 restart \
$CATALINA_HOME/logs/catalina.out
%env
rcService tomcat5 enable yes || exit 0
j2se14 spec file (modified)
I uploaded a new j2se14.spec file. I added options to it so that you
can keep the demos if you want, add docs, remove man pages and/or add
the US Encryption policy files. I tried to upload the src.rpm which
included an rc script that just adds the JAVA_HOME into the environment,
but it was rejected. I attached the rc script to this email in case
anyone wants it.
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
Only those who attempt the absurd can achieve the impossible.
#!/usr/local/lib/openpkg/bash /usr/local/etc/rc
##
## rc.j2se14 -- Run-Commands
##
%config
j2se14_enable=$openpkg_rc_def
j2se14_home=/usr/local/libexec/j2se14
java_home=$j2se14_home
%status -u root -o
j2se14_usable=unknown
j2se14_active=no
${j2se14_home}/bin/java -version 2 /dev/null
status=$?
if [ $status -eq 0 ]; then
j2se14_active=yes
fi
echo j2se14_enable=\$j2se14_enable\
# active is the same as usable
echo j2se14_usable=\$j2se14_active\
echo j2se14_active=\$j2se14_active\
%start
:
%stop
:
%env
rcService j2se14 enable yes || exit 0
JAVA_HOME=$JDK_home
JDK_home=$j2se14_home
JAVA_home=$j2se14_home
export JAVA_HOME JDK_home JAVA_home
signature.asc
Description: This is a digitally signed message part
Re: j2se14 spec file (modified)
On Wed, 2004-09-22 at 11:29, Ralf S. Engelschall wrote: On Wed, Sep 22, 2004, David M. Fetter wrote: I've taken it over but tried to simplify and cleanup a few parts. Especially the with_man option I've removed (we always install manual pages in OpenPKG) and your changes to %env in rc.j2se14 I do not understand (the JDK_home and JRE_home variables are meant as internal OpenPKG variables only). Ah, that might explain some things. I was trying to extract those variables for use with tomcat5 in it's rc script. Then I just ended up making the rc script for j2se14 and passed the variable that way to tomcat5 as well as other potential apps. See http://cvs.openpkg.org/chngview?cn=19144 what I've comitted until now. Thanks for your contribution. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
tomcat5 src rpm uploaded
I uploaded a tomcat5 src rpm to the contrib area. It includes an rc script for it. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
lprng and ifhp
I also uploaded an lprng src rpm which includes and rc script and the ifhp spec file. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: lprng and ifhp
Well, I tried to upload the src rpms for lprng and tomcat5 but they were rejected in that form. I uploaded the spec files only. The rc scripts won't upload due to some filename rejection. Not sure why the src rpms failed. The rejection doesn't seem to indicate why. On Tue, 2004-09-21 at 11:56, David M. Fetter wrote: I also uploaded an lprng src rpm which includes and rc script and the ifhp spec file. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
swatch spec file
I created a swatch spec file and uploaded to the contrib/00UPLOAD/ area. Is this the proper place to upload these contributions? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: Package Upgrade Problems
WARNING: This e-mail has been altered by the PSU Mail System.
An attachment of type text/x-sh, named opkg-update.sh was removed
from this e-mail message as it constituted a potential security hazard.
Various attachment types are used by viruses and/or spammers in an
attempt to compromise your computer's security. As a precaution, we
remove various file types from your incoming e-mail. The types removed
generally have very little real-world use, but are often exploited by
malicious people.
The list we use is one recommended by Microsoft. To see the complete
list, please visit:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;290497
We block all attachments listed on that list, except files ending in a
.exe and .mdb extension.
If you have any questions about this message or viruses in general,
please call the User Support Services Help Desk at 503-725-4357, or
email [EMAIL PROTECTED]
On Wed, 2004-09-08 at 22:27, Ralf S. Engelschall wrote:
Shouldn't the newer version of the software and the openpkg revision
make it so they don't want to be updated?
Yes, these should be not downgraded. How can this happen to you?
Perhaps is the UPD 00INDEX.rdf.bz2 not read here?
Currently, I'm sync'ing a local copy of the SRC for 2.1, doing some
cleanup, reindexing and then doing the upgrade. I'm not sync'ing over
the UPD dir at this time. I was assuming that simply by having the
newer revision installed, the openpkg tools would identify it as such
and thus not attempt any update ever since the version in SRC is not
newer. If I sync both SRC and UPD, will the openpkg tools automagically
identify the newest version, ignoring the other versions and use that
for the updates? I was under the impression that this wouldn't work
either and it would instead be confused by the two different versions.
I attached the script I'm using to do this work for you to look at. It
should explain in detail what's going on. Please correct me if I'm
mistaken in any of these assumptions. Thanks.
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
Only those who attempt the absurd can achieve the impossible.
# This is the config file for the openpkg auto update and rebuild all scripts.
# Make sure to edit these variables as necessary for your system.
# Set hostnames for solaris and linux build hosts
SOLBH=spoor.oit.pdx.edu
LNXBH=shroom.oit.pdx.edu
export SOLBH LNXBH
# Set openpkg directory name and current version
OPKGDIR=`openpkg --version|awk '{print $1}'`
OPKGVER=`openpkg --version|awk '{print $1}'|awk -F- '{print $2}'`
export OPKGDIR OPKGVER
# Setup base directory names where work will be done
REPBASEDIR=/vol/openpkg/${OPKGVER}
FTPDIR=/vol/ftp/pub/mirrors/linux/openpkg-ftp
RPMBUILDDIR=/usr/local/RPM/ROOT
BINDIR=${RPMBUILDDIR}/RPMS
TMPDIR=${RPMBUILDDIR}/TMP
SRCBASEDIR=${TMPDIR}
export REPBASEDIR FTPDIR BINDIR TMPDIR RPMBUILDDIR SRCBASEDIR
# Add software packages and files that you don't want to have auto-updated here
#
# NOTE: IF YOU ADD A SOFTWARE PACKAGE TO THESE EXCLUSIONS, YOU NEED TO GO TO
# EACH BUILD HOST AND REMOVE THE APPROPRIATE BINARY PACKAGE FROM
# /usr/local/RPM/ROOT/RPMS OR ELSE THE NEXT TIME THE AUTO UPDATE SCRIPTS RUN THE
# BINARY PACKAGE WILL GET COPIED OVER INTO THE ALPH REPOSITORY AND CONFLICTS
# WILL OCCUR ON THE CLIENT HOSTS THE NEXT TIME THEY TRY TO UPDATE THEMSELVES.
#
# add non rpm bits here, generally this is not touched
NONRPM=00README 00INDEX.rdf.bz2 openpkg-*.sh
# add software we don't want to exist in our installations here
UNWANTED=openpkg-1.9.0 openpkg-2.0.0 openpkg-2.1.0 postfix ssmtp imapd teapop ksh awk
bind8 termutils mysql41 mysql3 cacti icon noweb gcrypt opencdk gnutls cadaver di kolab
quagga pinfo wml sitecopy apr imaputils mailsync proftpd rc apache2 squid calamaris
ldapdiff exim delegate ethereal sqlite cvstrac tetex latex2html pnet pnetlib mozilla
# add software that is customized (i.e. from current or sources or home made or
# anything that resides under the PSU subdirectory)
CUSTOM=a2ps amanda cfengine fping grazer ifhp imap inetutils j2se14 logrotate lprng
mimedefang muppet nagios oracle-barebone pdflib php php-accelerator php-pear-Log
php-pear-Mail_Mime php-pear-Net_Socket psu-perl-db psu-perl-misc psu-perl-net
psu-perl-sec psu-perl-www sendmail setoolkit subversion tomcat5 top wv
export NONRPM UNWANTED CUSTOM
signature.asc
Description: This is a digitally signed message part
Re: Package Upgrade Problems
Looks like our mail system cut out my shell script based on it's extension. I gzip'ed it instead here. On Thu, 2004-09-09 at 10:03, David M. Fetter wrote: On Wed, 2004-09-08 at 22:27, Ralf S. Engelschall wrote: Shouldn't the newer version of the software and the openpkg revision make it so they don't want to be updated? Yes, these should be not downgraded. How can this happen to you? Perhaps is the UPD 00INDEX.rdf.bz2 not read here? Currently, I'm sync'ing a local copy of the SRC for 2.1, doing some cleanup, reindexing and then doing the upgrade. I'm not sync'ing over the UPD dir at this time. I was assuming that simply by having the newer revision installed, the openpkg tools would identify it as such and thus not attempt any update ever since the version in SRC is not newer. If I sync both SRC and UPD, will the openpkg tools automagically identify the newest version, ignoring the other versions and use that for the updates? I was under the impression that this wouldn't work either and it would instead be confused by the two different versions. I attached the script I'm using to do this work for you to look at. It should explain in detail what's going on. Please correct me if I'm mistaken in any of these assumptions. Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. opkg-update.sh.gz Description: GNU Zip compressed data signature.asc Description: This is a digitally signed message part
Package Upgrade Problems
I manually upgraded a couple packages out of the UPD directory for 2.1, however, when I run my auto update script it wants to update them. See here: lynx-2.8.5-2.1.1UPDATE lynx-2.8.5-2.1.0 openpkg-tools-0.8.18-2.1.3 UPDATE openpkg-tools-0.8.15-2.1.0 Shouldn't the newer version of the software and the openpkg revision make it so they don't want to be updated? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
PAM build issue on RHEL3
Well, after getting past the gettext issue and building most of the
packages under RHEL3, I'm now getting some error with PAM. It seems
that it's having problems auto-detecting some base system info. Are
there arguments that I can pass through openpkg to set them manually
with the pam src rpm? The output of the error is attached.
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
Only those who attempt the absurd can achieve the impossible.
Installing OpenPKG-2.1/SRC/pam-0-2.1.0.src.rpm
Executing(%prep): env -i /usr/local/lib/openpkg/bash --norc --noprofile --posix -e
/usr/local/RPM/TMP/rpm-tmp.24468
+ cd /usr/local/RPM/TMP
+ exit 0
Executing(%build): env -i /usr/local/lib/openpkg/bash --norc --noprofile --posix -e
/usr/local/RPM/TMP/rpm-tmp.24468
+ cd /usr/local/RPM/TMP
+ exit 0
Executing(%install): env -i /usr/local/lib/openpkg/bash --norc --noprofile --posix -e
/usr/local/RPM/TMP/rpm-tmp.24468
+ cd /usr/local/RPM/TMP
+ rm -rf /usr/local/RPM/TMP/pam-0-root
+ pam_cfgloc=
+ pam_modpfx=
+ pam_incdir=
+ pam_libdir=
+ '[' -f /etc/pam.d -o -d /etc/pam.d ']'
+ pam_cfgloc=/etc/pam.d
+ break
+ '[' -d /etc/pam.d ']'
++ cat /etc/pam.d/authconfig /etc/pam.d/chfn /etc/pam.d/chsh /etc/pam.d/cups
/etc/pam.d/halt /etc/pam.d/internet-druid /etc/pam.d/kbdrate /etc/pam.d/login
/etc/pam.d/neat /etc/pam.d/other /etc/pam.d/passwd /etc/pam.d/poweroff /etc/pam.d/ppp
/etc/pam.d/reboot /etc/pam.d/redhat-config-mouse /etc/pam.d/redhat-config-network
/etc/pam.d/redhat-config-network-cmd /etc/pam.d/redhat-config-network-druid
/etc/pam.d/rhn_register /etc/pam.d/setup /etc/pam.d/smtp /etc/pam.d/smtp.sendmail
/etc/pam.d/sshd /etc/pam.d/su /etc/pam.d/sudo /etc/pam.d/system-auth
/etc/pam.d/up2date /etc/pam.d/up2date-config /etc/pam.d/up2date-nox /etc/pam.d/xserver
++ grep '^#*[ ]*other'
++ head -1
++ awk '{ print $3; }'
+ mod=
+ '[' -f /usr/include/security/pam_appl.h ']'
+ '[' -f /usr/local/include/security/pam_appl.h ']'
+ '[' -f /opt/include/security/pam_appl.h ']'
+ '[' -f /lib/libpam.a ']'
+ '[' -f /lib/libpam.so ']'
+ '[' -f /lib/libpam.sl ']'
+ '[' -f /lib/libpam.so.0 ']'
+ pam_libdir=/lib
+ break
+ '[' ./lib '!=' . ']'
+ break
+ '[' ./etc/pam.d = . ']'
+ '[' . = . ']'
+ echo ''
+ echo '** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!'
** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!
+ echo '** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!'
** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!
+ echo '**'
**
+ echo '** We found out:'
** We found out:
+ echo '**PAM Config Location: /etc/pam.d'
**PAM Config Location: /etc/pam.d
+ echo '**PAM Module Prefix:'
**PAM Module Prefix:
+ echo '**PAM Include Directory: '
**PAM Include Directory:
+ echo '**PAM Library Directory: /lib'
**PAM Library Directory: /lib
+ echo '**'
**
+ echo '** Unfortunately, some information is missing here.'
** Unfortunately, some information is missing here.
+ echo '**'
**
+ echo '** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!'
** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!
+ echo '** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!'
** ERROR: SOME PAM INFORMATION COULD NOT BE DETERMINED!!
+ echo ''
+ exit 1
error: Bad exit status from /usr/local/RPM/TMP/rpm-tmp.24468 (%install)
RPM build errors:
Bad exit status from /usr/local/RPM/TMP/rpm-tmp.24468 (%install)
signature.asc
Description: This is a digitally signed message part
Re: PAM build issue on RHEL3
Nevermind. Figured it out. I had to install pam-devel and that solved the problem. This should probably be added as one of the additional packages to install on http://cvs.openpkg.org/getfile?f=openpkg-re/osprereq.txt under RHEL3. On Mon, 2004-08-09 at 08:31, David M. Fetter wrote: Well, after getting past the gettext issue and building most of the packages under RHEL3, I'm now getting some error with PAM. It seems that it's having problems auto-detecting some base system info. Are there arguments that I can pass through openpkg to set them manually with the pam src rpm? The output of the error is attached. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: problem rebuilding gettext on rhel3
So, in desperation I decided to try and rebuild as many of the packages
as possible. To do this I started by excluding gettext then things that
depended on it and so on. This pattern followed for quit a while until
finally I ended up excluding the following list of packages:
ldapdiff exim gettext popt orbit glib2 gtk2 gqview perl-locale aegis
yodl indent gimp openjade samba mozilla newt gmime ethereal ldapvi
libgdome atk giftcurs pango perl-gtk pam sasl pureftpd imap sendmail
openldap sysmon pks qpopper shiela gup inn nail pine cpu majordomo nn
mapson pb4sd delegate nmap sqlite cvstrac lynx subversion a2ps
This is in addition to my normal exclusions of stuff we just don't
want. Once this was complete, I went back to try to rebuild gettext and
it still failed. Then I started to dig around a bit and I found the
following section in the gettext.spec file within the %prep section:
# remove part that conflicts with libiconv
%{l_shtool} subst \
-e '/localcharset.\$lo/d' \
gettext-runtime/intl/Makefile.in
%{l_shtool} subst \
If I comment this secion out and build it manually, then it builds fine
past the original point of failure. Unfortunately, I get a new failure
which is:
jar cf gettext.jar gnu/gettext/DumpResource*.class
gnu/gettext/GetURL*.class
gnu/gettext/DumpResource*.class: No such file or directory
Error adding gnu/gettext/DumpResource*.class to jar archive!
make[4]: *** [gettext.jar] Error 1
There is another section in the spec file that does something with
these, but I get this same failure no matter if I comment that section
out or not. So, I'm again stuck with another dreaded error from
rebuilding gettext. I'm also left with questions of why this
localcharset manipulation was put there and whether or not it is in fact
still necessary? Any thoughts?
On Wed, 2004-08-04 at 13:43, David M. Fetter wrote:
One of my co-workers here discovered that something may be missing from
the make file in the source tree distributed with the openpkg src rpm.
See here:
could be our problem is the section for building localcharset.lo,
with the missing symbol locale_charset, is absent from the openpkg
gettext tarblob compared to the one I looked at from gnu this morning.
in any case, I did manage to build the one from gnu without problems.
shroom$ diff -Naur /tmp/gettext-0.14.1/gettext-runtime/intl/Makefile.in
/tmp/gettext-0.14.1-openpkg/gettext-runtime/intl/Makefile.in
--- /tmp/gettext-0.14.1/gettext-runtime/intl/Makefile.in
2004-01-17 07:54:06.0 -0800
+++ /tmp/gettext-0.14.1-openpkg/gettext-runtime/intl/Makefile.in
2004-08-04 10:21:33.0 -0700
@@ -121,7 +121,6 @@
ngettext.$lo \
plural.$lo \
plural-exp.$lo \
- localcharset.$lo \
relocatable.$lo \
localename.$lo \
log.$lo \
@@ -423,8 +422,6 @@
explodename.$lo l10nflist.$lo: $(srcdir)/loadinfo.h
dcigettext.$lo loadmsgcat.$lo plural.$lo plural-exp.$lo:
$(srcdir)/plural-exp.h
dcigettext.$lo: $(srcdir)/eval-plural.h
-localcharset.$lo: $(srcdir)/localcharset.h
-localealias.$lo localcharset.$lo relocatable.$lo:
$(srcdir)/relocatable.h
printf.$lo: $(srcdir)/printf-args.h $(srcdir)/printf-args.c
$(srcdir)/printf-parse.h $(srcdir)/wprintf-parse.h $(srcdir)/xsize.h
$(srcdir)/printf-parse.c $(srcdir)/vasnprintf.h $(srcdir)/vasnwprintf.h
$(srcdir)/vasnprintf.c
tags: TAGS
On Tue, 2004-08-03 at 09:06, David M. Fetter wrote:
On Mon, 2004-08-02 at 04:37, Thomas Lotterer wrote:
On Fri, Jul 30, 2004, David M. Fetter wrote:
Dear David,
this issue is really the hunt for the living dead. I remember we faught
against it in the past and failed. So let's retry.
Yes. Those damned living dead are hard to kill! :-)
So for good measure, I build a fresh RHEL3 [...]
Any ideas? I can go into more detail if you need.
I thought I found the problem in a sublibrary within gettext but my lab
results prooved me wrong. So I'm asking for a list of libraries you have
installed on your machine and the packages they came from. Thanks to RPM
this can be done by running
$ for i in `ls /lib/lib* /usr/lib/lib*`; do \
echo $i = `/bin/rpm -qf $i`; \
done
I attached a file named rhel3_libs.out with the output of this. Also,
for your reference, so far I have the following OpenPKG rpms installed:
openpkg-2.1.0-2.1.0
binutils-2.14-2.1.0
perl-5.8.4-2.1.0
bind-9.2.3-2.1.0
bison-1.35-2.1.0
libdnet-1.8-2.1.0
autoconf-2.59-2.1.0
libiconv-1.9.2-2.1.0
gpg-pubkey-63c4cb9f-3c591eda
openpkg-tools-0.8.15-2.1.0
make-3.80-2.1.0
gcc-3.4.1-2.1.0
openssl-0.9.7d-2.1.0
m4-1.4.1-2.1.0
flex-2.5.4a-2.1.0
nslint-2.1a3-2.1.0
automake-1.8.5-2.1.0
Also I wonder if you installed your machine using a non US ('C')
locale/time setting?
Well, my LANG and LANGVAR by default is set as follows:
LANG=en_US.UTF-8
LANGVAR=en_US.UTF-8
I did
Re: problem rebuilding gettext on rhel3
Ok, another update. I got gettext to rebuild finally however, I had to
comment that section out concerning the local_charset in the spec file
and uninstall libgcj from the RHEL3 temporarily. I'm expecting that if
I were to install a j2sdk openpkg package then that would've solved the
second problem as well as removing libgcj. Anyway, it seems there is
still some sort of issue that probably needs to be fixed here on a more
permanent basis. I don't know if removing that local_charset section
permanently is good or not in regards to the other variations of unix
that openpkg is designed for, but it does seem to do the trick for
RHEL3.
On Fri, 2004-08-06 at 14:25, David M. Fetter wrote:
So, in desperation I decided to try and rebuild as many of the packages
as possible. To do this I started by excluding gettext then things that
depended on it and so on. This pattern followed for quit a while until
finally I ended up excluding the following list of packages:
ldapdiff exim gettext popt orbit glib2 gtk2 gqview perl-locale aegis
yodl indent gimp openjade samba mozilla newt gmime ethereal ldapvi
libgdome atk giftcurs pango perl-gtk pam sasl pureftpd imap sendmail
openldap sysmon pks qpopper shiela gup inn nail pine cpu majordomo nn
mapson pb4sd delegate nmap sqlite cvstrac lynx subversion a2ps
This is in addition to my normal exclusions of stuff we just don't
want. Once this was complete, I went back to try to rebuild gettext and
it still failed. Then I started to dig around a bit and I found the
following section in the gettext.spec file within the %prep section:
# remove part that conflicts with libiconv
%{l_shtool} subst \
-e '/localcharset.\$lo/d' \
gettext-runtime/intl/Makefile.in
%{l_shtool} subst \
If I comment this secion out and build it manually, then it builds fine
past the original point of failure. Unfortunately, I get a new failure
which is:
jar cf gettext.jar gnu/gettext/DumpResource*.class
gnu/gettext/GetURL*.class
gnu/gettext/DumpResource*.class: No such file or directory
Error adding gnu/gettext/DumpResource*.class to jar archive!
make[4]: *** [gettext.jar] Error 1
There is another section in the spec file that does something with
these, but I get this same failure no matter if I comment that section
out or not. So, I'm again stuck with another dreaded error from
rebuilding gettext. I'm also left with questions of why this
localcharset manipulation was put there and whether or not it is in fact
still necessary? Any thoughts?
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
Only those who attempt the absurd can achieve the impossible.
signature.asc
Description: This is a digitally signed message part
index files and build options
I'm curious to know if when the openpkg index is called if it takes into account of build options that might exist in ~/.openpkg/build? The reason why I ask is because I had a few anomalies when I was doing a complete rebuild from scratch on a fresh system where a few packages didn't build successfully at first. I ended up excluding them temporarily and it built all of the rest. Then when I went back to build the ones I excluded it build no problem. It almost seems that there is a problem with the indexing and it determining proper dependencies. Is this a possible bug with the indexing? I can provide more detail if you like. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
gc pnet conflict
Just another minor conflict I thought I would mention. file /usr/local/share/gc/README from install of gc-6.3-2.1.0 conflicts with file from package pnet-0.6.6-2.1.0 file /usr/local/share/gc/README.changes from install of gc-6.3-2.1.0 conflicts with file from package pnet-0.6.6-2.1.0 I don't know if you want to know about these or not. If not just let me know and I won't send them anymore. If you appreciate the bug reports then I'll keep sending them. Either way let me know. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
texinfo tetex conflict
This is minor but there is a conflict with a couple man pages between texinfo and tetex as seen here: file /usr/local/man/man5/info.5 from install of tetex-2.0.2-2.1.0 conflicts with file from package texinfo-4.7-2.1.0 file /usr/local/man/man5/texinfo.5 from install of tetex-2.0.2-2.1.0 conflicts with file from package texinfo-4.7-2.1.0 Just thought I'd mention it. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: problem rebuilding gettext on rhel3
On Mon, 2004-08-02 at 04:37, Thomas Lotterer wrote:
On Fri, Jul 30, 2004, David M. Fetter wrote:
Dear David,
this issue is really the hunt for the living dead. I remember we faught
against it in the past and failed. So let's retry.
Yes. Those damned living dead are hard to kill! :-)
So for good measure, I build a fresh RHEL3 [...]
Any ideas? I can go into more detail if you need.
I thought I found the problem in a sublibrary within gettext but my lab
results prooved me wrong. So I'm asking for a list of libraries you have
installed on your machine and the packages they came from. Thanks to RPM
this can be done by running
$ for i in `ls /lib/lib* /usr/lib/lib*`; do \
echo $i = `/bin/rpm -qf $i`; \
done
I attached a file named rhel3_libs.out with the output of this. Also,
for your reference, so far I have the following OpenPKG rpms installed:
openpkg-2.1.0-2.1.0
binutils-2.14-2.1.0
perl-5.8.4-2.1.0
bind-9.2.3-2.1.0
bison-1.35-2.1.0
libdnet-1.8-2.1.0
autoconf-2.59-2.1.0
libiconv-1.9.2-2.1.0
gpg-pubkey-63c4cb9f-3c591eda
openpkg-tools-0.8.15-2.1.0
make-3.80-2.1.0
gcc-3.4.1-2.1.0
openssl-0.9.7d-2.1.0
m4-1.4.1-2.1.0
flex-2.5.4a-2.1.0
nslint-2.1a3-2.1.0
automake-1.8.5-2.1.0
Also I wonder if you installed your machine using a non US ('C')
locale/time setting?
Well, my LANG and LANGVAR by default is set as follows:
LANG=en_US.UTF-8
LANGVAR=en_US.UTF-8
I did manually change this to be C before one attempt at rebuilding
gettext but that didn't seem to make a difference.
As a last resort I'll ask for shell access to the affected box or
consider reproducing the problem in a VMWare virtual machine and send me
the image for inspection.
If it comes to this then I can probably oblige, but we will need to
setup some sort of appointment so we can chat real time.
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List [EMAIL PROTECTED]
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
Only those who attempt the absurd can achieve the impossible.
/lib/libacl.so.1 = libacl-2.2.3-1
/lib/libacl.so.1.0.3 = libacl-2.2.3-1
/lib/libanl-2.3.2.so = glibc-2.3.2-95.20
/lib/libanl.so.1 = glibc-2.3.2-95.20
/lib/libattr.so.1 = libattr-2.2.0-1
/lib/libattr.so.1.0.1 = libattr-2.2.0-1
/lib/libBrokenLocale-2.3.2.so = glibc-2.3.2-95.20
/lib/libBrokenLocale.so.1 = glibc-2.3.2-95.20
/lib/libc-2.3.2.so = glibc-2.3.2-95.20
/lib/libcom_err.so.2 = e2fsprogs-1.32-15
/lib/libcom_err.so.2.0 = e2fsprogs-1.32-15
/lib/libcrypt-2.3.2.so = glibc-2.3.2-95.20
/lib/libcrypto.so.0.9.7a = openssl-0.9.7a-33.4
/lib/libcrypto.so.4 = file /lib/libcrypto.so.4 is not owned by any package
/lib/libcrypt.so.1 = glibc-2.3.2-95.20
/lib/libc.so.6 = glibc-2.3.2-95.20
/lib/libdb-4.1.so = db4-4.1.25-8
/lib/libdl-2.3.2.so = glibc-2.3.2-95.20
/lib/libdl.so.2 = glibc-2.3.2-95.20
/lib/libe2p.so.2 = e2fsprogs-1.32-15
/lib/libe2p.so.2.3 = e2fsprogs-1.32-15
/lib/libext2fs.so.2 = e2fsprogs-1.32-15
/lib/libext2fs.so.2.4 = e2fsprogs-1.32-15
/lib/libgcc_s-3.2.3-20040414.so.1 = libgcc-3.2.3-34
/lib/libgcc_s.so.1 = libgcc-3.2.3-34
/lib/libipsec.so = ipsec-tools-0.2.5-0.4
/lib/libipsec.so.0 = ipsec-tools-0.2.5-0.4
/lib/libipsec.so.0.0.0 = ipsec-tools-0.2.5-0.4
/lib/libiw.so.26 = wireless-tools-26-2
/lib/liblaus.so.1 = laus-libs-0.1-56RHEL3
/lib/liblaus.so.1.0.0 = laus-libs-0.1-56RHEL3
/lib/liblaussrv.so.0 = laus-libs-0.1-56RHEL3
/lib/liblaussrv.so.0.0.0 = laus-libs-0.1-56RHEL3
/lib/liblvm-10.so = lvm-1.0.3-15
/lib/liblvm-10.so.1 = lvm-1.0.3-15
/lib/liblvm-10.so.1.0 = lvm-1.0.3-15
/lib/libm-2.3.2.so = glibc-2.3.2-95.20
/lib/libm.so.6 = glibc-2.3.2-95.20
/lib/libNoVersion-2.3.2.so = glibc-2.3.2-95.20
/lib/libNoVersion.so.1 = glibc-2.3.2-95.20
/lib/libnsl-2.3.2.so = glibc-2.3.2-95.20
/lib/libnsl.so.1 = glibc-2.3.2-95.20
/lib/libnss1_compat-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss1_compat.so.1 = glibc-2.3.2-95.20
/lib/libnss1_dns-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss1_dns.so.1 = glibc-2.3.2-95.20
/lib/libnss1_files-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss1_files.so.1 = glibc-2.3.2-95.20
/lib/libnss1_nis-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss1_nis.so.1 = glibc-2.3.2-95.20
/lib/libnss_compat-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss_compat.so.1 = glibc-2.3.2-95.20
/lib/libnss_compat.so.2 = glibc-2.3.2-95.20
/lib/libnss_dns-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss_dns.so.1 = glibc-2.3.2-95.20
/lib/libnss_dns.so.2 = glibc-2.3.2-95.20
/lib/libnss_files-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss_files.so.1 = glibc-2.3.2-95.20
/lib/libnss_files.so.2 = glibc-2.3.2-95.20
/lib/libnss_hesiod-2.3.2.so = glibc-2.3.2-95.20
/lib/libnss_hesiod.so.2 = glibc-2.3.2-95.20
/lib/libnss_ldap-2.3.2.so = nss_ldap-207-10
/lib/libnss_ldap.so.2 = file /lib/libnss_ldap.so.2 is not owned by any package
/lib/libnss_nis-2.3.2.so = glibc-2.3.2-95.20
RE: problem rebuilding gettext on rhel3
So for good measure, I build a fresh RHEL3 system with the exact requisite packages as found at http://cvs.openpkg.org/getfile?f=openpkg-re/osprereq.txt. Then I proceeded to rebuild all of the packages, excluding a few that we don't want, but it still fails at the same exact point. Any ideas? I can go into more detail if you need. On Tue, 2004-07-27 at 09:08, David M. Fetter wrote: Unfortunately, this didn't work. It does seem that /usr/local/lib is not in my library path or ldpath. I added to /etc/ld.so.conf but that didn't work still. I added it to the LD_LIBRARY_PATH, again no workie. Even the LDPATH didn't make it work. Also, I seem to be getting an error when I try to eval for the pathing instead of having it actually set my paths, like this: /usr/local/etc/rc --eval all env . /tmp/rc-20040727110815-19013/rc.tmp; rm -rf /tmp/rc-20040727110815-19013 2/dev/null || true On Tue, 2004-07-27 at 04:34, Rangarajan, Mukund (Cognizant) wrote: David, I have faced this issue before. This happens because your configure script cannot find the libcharset library in the path. Try the following: export LDFLAGS=-Ldir -lcharset where dir is the directory path of the libcharset.a or libcharset.so file. Hope this helps. Mukund -Original Message- From: [EMAIL PROTECTED] on behalf of David M. Fetter Sent: Tue 7/27/2004 3:59 AM To: [EMAIL PROTECTED] Cc: Subject:problem rebuilding gettext on rhel3 I'm getting an error when trying to rebuild gettext on a RHEL3 x86 system. It is as follows: + ./configure --prefix=/usr/local --with-libiconv-prefix=/usr/local --with-included-gettext --disable-csharp --disable-shared + /usr/local/bin/make --no-print-directory ../intl/.libs/libintl.a(loadmsgcat.o)(.text+0x119): In function locale_charset' collect2: ld returned 1 exit status make[3]: *** [gettext] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Complete logging of the rebuild is in the attached tarball. Does anybody know how to resolve this issue? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: problem rebuilding gettext on rhel3
Nope. I'm using the latest 2.1 release. On Tue, 2004-07-27 at 07:47, Ralf S. Engelschall wrote: On Mon, Jul 26, 2004, David M. Fetter wrote: I'm getting an error when trying to rebuild gettext on a RHEL3 x86 system. It is as follows: + ./configure --prefix=/usr/local --with-libiconv-prefix=/usr/local --with-included-gettext --disable-csharp --disable-shared + /usr/local/bin/make --no-print-directory ../intl/.libs/libintl.a(loadmsgcat.o)(.text+0x119): In function `_nl_init_domain_conv': : undefined reference to `locale_charset' collect2: ld returned 1 exit status make[3]: *** [gettext] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Complete logging of the rebuild is in the attached tarball. Does anybody know how to resolve this issue? Hmmm... I'm unable to reproduce this on our RHEL3 box with the gettext package from CURRENT and 2.1. Is this perhaps an older version you are trying? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED] -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
RE: problem rebuilding gettext on rhel3
Unfortunately, this didn't work. It does seem that /usr/local/lib is not in my library path or ldpath. I added to /etc/ld.so.conf but that didn't work still. I added it to the LD_LIBRARY_PATH, again no workie. Even the LDPATH didn't make it work. Also, I seem to be getting an error when I try to eval for the pathing instead of having it actually set my paths, like this: /usr/local/etc/rc --eval all env . /tmp/rc-20040727110815-19013/rc.tmp; rm -rf /tmp/rc-20040727110815-19013 2/dev/null || true On Tue, 2004-07-27 at 04:34, Rangarajan, Mukund (Cognizant) wrote: David, I have faced this issue before. This happens because your configure script cannot find the libcharset library in the path. Try the following: export LDFLAGS=-Ldir -lcharset where dir is the directory path of the libcharset.a or libcharset.so file. Hope this helps. Mukund -Original Message- From: [EMAIL PROTECTED] on behalf of David M. Fetter Sent: Tue 7/27/2004 3:59 AM To: [EMAIL PROTECTED] Cc: Subject:problem rebuilding gettext on rhel3 I'm getting an error when trying to rebuild gettext on a RHEL3 x86 system. It is as follows: + ./configure --prefix=/usr/local --with-libiconv-prefix=/usr/local --with-included-gettext --disable-csharp --disable-shared + /usr/local/bin/make --no-print-directory ../intl/.libs/libintl.a(loadmsgcat.o)(.text+0x119): In function locale_charset' collect2: ld returned 1 exit status make[3]: *** [gettext] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Complete logging of the rebuild is in the attached tarball. Does anybody know how to resolve this issue? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
OS Reqs for Sol9 (Mod)
I was looking at the OS requirements for OpenPKG at http://cvs.openpkg.org/getfile?f=openpkg-re/osprereq.txt and noticed that Solaris9 stated it needed SUNWCall. We have OpenPKG fully functional with the following install: install_typeinitial_install system_type standalone partitioningexplicit cluster SUNWCprog package SUNWsshcu delete package SUNWsshdr delete package SUNWsshdu delete package SUNWsshr delete package SUNWsshu delete package SUNWntpr delete package SUNWntpu delete package SUNWpsr delete package SUNWpsu delete package SUNWpcr delete package SUNWpcu delete package SUNWscplp delete package SUNWtcsh add package SUNWzsh add package SUNWypr add package SUNWypu add As reflected from a jumpstart install file. Just thought I'd share so the os requirements section could be updated. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
problem rebuilding gettext on rhel3
I'm getting an error when trying to rebuild gettext on a RHEL3 x86 system. It is as follows: + ./configure --prefix=/usr/local --with-libiconv-prefix=/usr/local --with-included-gettext --disable-csharp --disable-shared + /usr/local/bin/make --no-print-directory ../intl/.libs/libintl.a(loadmsgcat.o)(.text+0x119): In function `_nl_init_domain_conv': : undefined reference to `locale_charset' collect2: ld returned 1 exit status make[3]: *** [gettext] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Complete logging of the rebuild is in the attached tarball. Does anybody know how to resolve this issue? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. gettext_build_logs.tar.gz Description: application/compressed-tar signature.asc Description: This is a digitally signed message part
howto build src.prm for perl modules?
How does everyone else build a slew of perl modules into src.rpm under OpenPKG? Is there a tool or something that already exists for doing this? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
LPRng Spec File?
Before I start hacking out my own spec file I figured I'd ask here to see if anyone already has an LPRng spec file or src rpm they've put together. It always makes sense to save time if one can, eh? :-) -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
