[OpenPKG] Version Tracking Report (2005-03-07 18:45)
OpenPKG Version Tracking Report === Reporting Time:2005-03-07 18:45 Tracking Duration: 0:32:25 (H:M:S) Tracking Input:1474 sources (856 packages) Tracking Result: 1403 up-to-date, 16 out-dated, 55 error The following 16 sources were determined to be out-dated because newer vendor versions were found. Upgrade the corresponding OpenPKG packages. - - - Package Old Version New Version - - - blender 2.34 2.35 [1] kde-arts 1.3.1 1.3.2 kde-base 3.2.3 3.3.2 kde-libs 3.3.1 3.3.2 keychain 2.5.1 2.5.2 libspf2 1.0.4 1.2.5 [2] mplayer:live 2005.03.052005.03.07[3] parrot0.1.1 0.1.2 perl-ds:Tree-BPTree 1.06 1.07 [4] perl-tk:Tk-JComboBox 1.04 1.05 perl-util:Class-Autouse 1.16 1.17 perl-www:CGI-Builder-HTML 1.1 1.2 postgrey 1.17 1.18 ups 3.37 3.38-beta2[5] uvscan:datfiles 4440 4441 xalan-c 1_6 1_9_0 - - - [1] blender: tho: 17.11.04: they scrapt configure in 2.35, using scons now [2] libspf2: ms: 1.2.5 depends on res_nclose(3), missing in FreeBSD [3] mplayer:live: rse: new snapshots occur every second day, no need to upgrade such fast [4] perl-ds:Tree-BPTree: rse: 1.07: requires Module::Build, no Makefile.PL provided [5] ups: rse: broken on FreeBSD = 4.5-STABLE because ptrace' PT_READ_U missing The following 55 sources could not be successfully checked because an error occurred while processing. Keep at least an eye on them. - - - Package Old Version Error - - - apache:mod_layout 3.2.1 regex didn't match (pro.. apache:mod_relocate 1.0 regex didn't match (pro.. apache:mod_security 1.8.6 regex didn't match (pro.. as-cui0.6.5 regex didn't match (pro.. as-gui0.7.7 regex didn't match (pro.. dspam 3.3.13latest version online l.. enscript 1.6.3 regex didn't match (p [1] epm 3.7 2nd connection failed o.. firefox 1.0 2nd connection failed o.. freetype 2.1.9 connection failed or ti.. gale 0.99fruit latest version online l.. gcc:spp 3.4-2 latest version online l.. gconf 2.9 2nd connection failed o.. ghc 6.4.20050304 regex didn't match (pro.. gtkmm 2.4.8 connection failed or ti.. imap 2004c regex didn't match (pro.. inkscape 0.40 connection failed or ti.. ircd 2.11.0connection failed or ti.. jabberd 2.0s6 regex didn't match (pro.. less 385 latest version online l.. libart2.3.162nd connection failed o.. libextractor 0.4.0 regex didn't match (pro.. libgda1.1.992nd connection failed o.. libodbcplus 0.2.3 regex didn't match (pro.. librsvg 2.9.5 2nd regex didn't match .. libsigcxx 2.0.6 regex didn't match (pro.. max 7.4.2 regex didn't match (p [2] mgv 3.1.5 regex didn't match (pro.. mirror2.9 connection failed or ti.. mozilla 1.7.5 2nd connection failed o.. mysql40 4.0.23a regex didn't match (pro.. nessus-libs:libnasl
[CONTRIB] ACCEPT: amd-6.0.9-2.3.1.src.rpm
The following OpenPKG Contribution Area operation occurred. uploaded RPM file amd-6.0.9-2.3.1.src.rpm accepted -- moved to contrib area. No action is required on your part. Information about amd-6.0.9-2.3.1.src.rpm follows: | Name: amd Source RPM: (none) | Version: 6.0.9 Signature: md5:8d0ac6ed347a0d2c8cde54d4300b88cc | Release: 2.3.1 Build Host: madcap.oit.pdx.edu | Group:SystemBuild System: ix86-rhel3 | Class:BASE Build Time: Mon Mar 7 21:03:50 2005 | Distrib: OpenPKG Install Time: (not installed) | License: BSD Install Size: 1484667 bytes | Packager: The OpenPKG Project Relocations: (not relocateable) | Vendor: UCB | Summary: Auto-Mounting Daemon | URL: http://www.am-utils.org/ | Description: | An automounting daemon maintains a cache of mounted filesystems. | Filesystems are mounted on demand when they are first referenced, | and unmounted after a period of inactivity. Amd may be used as a | replacement for Sun's original automounter. The choice of which | filesystem to mount can be controlled dynamically with selectors. | Selectors allow decisions of the form hostname is this, or | architecture is not that. Selectors may be combined arbitrarily. | Amd also supports a variety of filesystem types, including NFS, | UFS and the novel program filesystem. The combination of selectors | and multiple filesystem types allows identical configuration | files to be used on all machines thus reducing the administrative | overhead. Amd ensures that it will not hang if a remote server goes | down. Moreover, Amd can determine when a remote server has become | inaccessible and then mount replacement filesystems as and when they | become available. | Files: __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
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, 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. If your entire server comes to a crashing halt then something else is wrong. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
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: Python Release 2.2 and CURRENT vs Berkeley DB.
On Sat, Mar 05, 2005, Bill Campbell wrote:
On Sat, Mar 05, 2005, Bill Campbell wrote:
I found that the python package in Release 2.3 and CURRENT isn't
building the bsddb, Berkeley Database, Module as the _bsddb.c
file isn't compatible with db-4.3. Unfortunately this isn't
obvious during the build process as it requires careful perusal
of the python build output to see which, if any, Modules didn't
build properly.
I tried fixing this myself, looking at the perl Berkeley module,
but couldn't get it to work properly. I then tried by using the
_bsddb.c module from the current python CVS. This built, but
then failed when attempting to access a cache.db file created
using the openpkg-tools index program (a patch file is attached).
I meant to defer this, not send it to the list, since I'm trying
further testing to see if there's a binary incompatibility with
files created on the previous version of the Berkeley DB package.
Given the number of packages that depend on the Berkeley DB
packages, perl-db, python, mysql, openldap, postfix, etc., and the
history of binary incompatibilities with the databases, I think it's
extremely important to make sure that any issues are resolved and
documented before changing the db package.
I did some more testing on this on a system that's basically OpenPKG
Release 2.3 with a few CURRENT packages that require frequent updating
(e.g. clamav, spamassassin, etc.). The version I build by copying the
_bsddb.c file from the current CVS failed with the traceback attached here.
Today I tried what is probably an extreme measure, and patched the python
tree with the current CVS tree which now works, but may well introduce
other issues. This built, and seems to work OK, at least as far as the
bsddb module is concerned.
I backed off from that a bit as that was really python-2.5.alpha something
or other. I did a cvs checkout on the release24-maint tag, which I presume
is basically maintenance. After some fiddling with the python.spec file,
largely to debug the failing install, I have a working source package at
URI below. The patch file is rather large, so I'm not going to post it to
a mailing list.
ftp://ftp.celestial.com/private/ftp.openpkg.org/release/2.3/SRC/python-2.4-20050307.src.rpm
I would like to suggest that in interests of stability on the OpenPKG
Release 2.3 tree, that the Berkeley db package be back dated to the
db-4.2.52.2-2.2.0.src.rpm version. I would like to see another cycle of
testing in the CURRENT tree before declaring this stable.
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/
Foreign aid might be defined as a transfer from poor people in rich
countries to rich people in poor countries -- Douglas Casey
Traceback (most recent call last):
File /root/lbin/opkgcachedump.py, line 52, in ?
db = anydbm.open('cache.db')
File /home/csoft/suse90/lib/python/anydbm.py, line 83, in open
return mod.open(file, flag, mode)
File /home/csoft/suse90/lib/python/dbhash.py, line 16, in open
return bsddb.hashopen(file, flag, mode)
File /home/csoft/suse90/lib/python/bsddb/__init__.py, line 285, in hashopen
e = _openDBEnv()
File /home/csoft/suse90/lib/python/bsddb/__init__.py, line 339, in
_openDBEnv
e.open('.', db.DB_PRIVATE | db.DB_CREATE | db.DB_THREAD | db.DB_INIT_LOCK |
db.DB_INIT_MPOOL)
bsddb._db.DBError: (135879120, 'Unknown error 135879120')
[OpenPKG] Version Tracking Report (2005-03-08 06:40)
OpenPKG Version Tracking Report === Reporting Time:2005-03-08 06:40 Tracking Duration: 0:28:07 (H:M:S) Tracking Input:1474 sources (856 packages) Tracking Result: 1398 up-to-date, 17 out-dated, 59 error The following 17 sources were determined to be out-dated because newer vendor versions were found. Upgrade the corresponding OpenPKG packages. - - - Package Old Version New Version - - - blender 2.34 2.35 [1] findutils 4.2.184.2.19 gmime 2.1.122.1.13 kde-arts 1.3.1 1.3.2 kde-base 3.2.3 3.3.2 kde-libs 3.3.1 3.3.2 kwiki:Kwiki-Backlinks 0.06 0.07 libpixman 0.1.3 0.1.4 libspf2 1.0.4 1.2.5 [2] parrot0.1.1 0.1.2 perl-dbi:SQL-Abstract 1.17 1.18 perl-ds:Tree-BPTree 1.06 1.07 [3] perl-gd:GD2.21 2.22 perl-gtk:Gtk2-Perl:Glib 1.074 1.080 perl-gtk:Gtk2-Perl:Gtk1.074 1.080 ups 3.37 3.38-beta2[4] xalan-c 1_6 1_9_0 - - - [1] blender: tho: 17.11.04: they scrapt configure in 2.35, using scons now [2] libspf2: ms: 1.2.5 depends on res_nclose(3), missing in FreeBSD [3] perl-ds:Tree-BPTree: rse: 1.07: requires Module::Build, no Makefile.PL provided [4] ups: rse: broken on FreeBSD = 4.5-STABLE because ptrace' PT_READ_U missing The following 59 sources could not be successfully checked because an error occurred while processing. Keep at least an eye on them. - - - Package Old Version Error - - - apache:mod_security 1.8.6 regex didn't match (pro.. as-cui0.6.5 regex didn't match (pro.. as-gui0.7.7 regex didn't match (pro.. dspam 3.3.13latest version online l.. enscript 1.6.3 regex didn't match (p [1] epm 3.7 2nd connection failed o.. firefox 1.0 2nd connection failed o.. freetype 2.1.9 connection failed or ti.. gale 0.99fruit latest version online l.. gcc 3.4.3 1st connection failed o.. gcc2 2.95.31st connection failed o.. gcc33 3.3.5 1st connection failed o.. gcc40 4.0-20050305 1st connection failed o.. gcc:spp 3.4-2 latest version online l.. gconf 2.9 2nd connection failed o.. ghc 6.4.20050304 regex didn't match (pro.. gtkmm 2.4.8 connection failed or ti.. imap 2004c regex didn't match (pro.. inkscape 0.40 connection failed or ti.. ircd 2.11.0connection failed or ti.. jabberd 2.0s6 regex didn't match (pro.. jikes 1.22 2nd regex didn't match .. less 385 latest version online l.. libart2.3.162nd connection failed o.. libextractor 0.4.0 regex didn't match (pro.. libgda1.1.992nd connection failed o.. libodbcplus 0.2.3 regex didn't match (pro.. librsvg 2.9.5 2nd regex didn't match .. libsigcxx 2.0.6 regex didn't match (pro.. max 7.4.2 regex didn't match (p [2] mgv 3.1.5 regex didn't match (pro.. mirror2.9 connection failed
Re: AMD Fix Uploaded to Contrib
On Mon, Mar 07, 2005 at 05:22:21PM -0800, David M. Fetter wrote: David, 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. I guess this is an eternal discussion. In my world upgrading isn't a safe operation either and the minimum that must be done with an upgrade is an automated _shutdown_ of the old service because doing nothing is better than doing something wrong. In a production environment you need some kind of configuration management. Deployment then starts with shutting down services, continues with rolling out the new version, installing new configuration files from a repository, and finally restarting services. If you can't take that downtime (and we are still talking about minutes) then you want a high availability solution anyway. This is nothing that OpenPKG provides out of the box. For the non-productive environment I believe the automated restart of services is a convenience. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
