From noreply at opencsw.org Wed Sep 1 01:22:21 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 1 Sep 2010 01:22:21 +0200 Subject: [bug-notifications] [sudosh2 0004487]: New version of sudosh2 available with fixes for Solaris In-Reply-To: <65036e3e8b26dfdb53e2183aeb4141e0> Message-ID: <9a4ab55a58f76b6bf9211b910c47c633@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4487 ====================================================================== Reported By: ckmehta1 Assigned To: skayser ====================================================================== Project: sudosh2 Issue ID: 4487 Category: other Reproducibility: always Severity: major Priority: high Status: assigned ====================================================================== Date Submitted: 2010-07-08 13:48 CEST Last Modified: 2010-09-01 01:22 CEST ====================================================================== Summary: New version of sudosh2 available with fixes for Solaris Description: Per the author of sudosh2: I have just release sudosh2-1.0.3. This version contains a security fix that is important for anyone using sudosh as a login shell. There are also a few fixes for Solaris environments and potentially other non-Linux systems, and a few code cleanups for newer compilers. If you are using sudosh2 on Solaris or are using sudosh as a login shell, it is highly recommended that you upgrade. ====================================================================== ---------------------------------------------------------------------- (0008234) skayser (administrator) - 2010-09-01 01:22 https://www.opencsw.org/mantis/view.php?id=4487#c8234 ---------------------------------------------------------------------- Sorry for the delay. Upstream version is at 1.0.4 in the meantime. Updated packages are available from experimental for testing purposes. http://mirror.opencsw.org/experimental.html#skayser From noreply at opencsw.org Wed Sep 1 12:49:25 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 1 Sep 2010 12:49:25 +0200 Subject: [bug-notifications] [pkgutil 0004530]: RFE: Point out package download location when downloading In-Reply-To: <7f9248ee6e59a5541d0d9c1738a7ad9c> Message-ID: <60f7fb77e5a943bcca5ee39fea8c11fd@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4530 ====================================================================== Reported By: skayser Assigned To: bonivart ====================================================================== Project: pkgutil Issue ID: 4530 Category: other Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-26 13:07 CEST Last Modified: 2010-09-01 12:49 CEST ====================================================================== Summary: RFE: Point out package download location when downloading Description: When downloading a package (-d) there's no indication to the user where the package might have ended up at. root @ ray42 ~# pkgutil -Nd -T sparc:5.10 nagios_plugins Package list: CSWnagiosp-1.4.13,REV=2009.04.26 Total size: 1.6 MB => Fetching CSWnagiosp-1.4.13,REV=2009.04.26 (1/1) ... root @ ray42 ~# Compare this with the --stream download option where there's an indication to the user where he can find the generated stream. Transforming CSWsasl ... Transforming CSWoldaprt ... Transforming CSWlibpq ... Transforming CSWnagiosp ... Transforming packages into stream (/var/opt/csw/pkgutil/packages/nagios_plugins.sparc.5.10.pkg) ... Would be helpful to output the download directory on normal downloads also. Maybe add an extra line with the download directory? root @ ray42 ~# pkgutil -Nd -T sparc:5.10 nagios_plugins Package list: CSWnagiosp-1.4.13,REV=2009.04.26 Total size: 1.6 MB => Downloading packages to /var/opt/csw/pkgutil/packages => Fetching CSWnagiosp-1.4.13,REV=2009.04.26 (1/1) ... ====================================================================== ---------------------------------------------------------------------- (0008235) skayser (administrator) - 2010-09-01 12:49 https://www.opencsw.org/mantis/view.php?id=4530#c8235 ---------------------------------------------------------------------- I just gave it a try. The full paths are very helpful for copy&pasting (which I just used right afterwards). OTOH they tend to be 80+ chars in width, lead to line wraps in 80-column terminals and with a dozen or so of downloaded packages this looks quite messy. From noreply at opencsw.org Wed Sep 1 15:21:26 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 1 Sep 2010 15:21:26 +0200 Subject: [bug-notifications] [krb5_lib_dev 0004384]: krb5-config looks not good In-Reply-To: <3fa264af223d58003352276b1d72646f> Message-ID: <243fe18d0dacaa5e3c33e4381dc0e4fd@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4384 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: krb5_lib_dev Issue ID: 4384 Category: regular use Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-03-30 14:31 CEST Last Modified: 2010-09-01 15:21 CEST ====================================================================== Summary: krb5-config looks not good Description: The output of current9s% krb5-config --libs is -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl Note the trailing slash in /opt/csw/lib/ and the multiple calls to -R ====================================================================== ---------------------------------------------------------------------- (0008236) yann (developer) - 2010-09-01 15:21 https://www.opencsw.org/mantis/view.php?id=4384#c8236 ---------------------------------------------------------------------- I've also been hit by this issue while building openssh. From noreply at opencsw.org Wed Sep 1 16:15:05 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 1 Sep 2010 16:15:05 +0200 Subject: [bug-notifications] [setoolkit 0004539]: SEToolkit is not collecting stats on network aggregations Message-ID: <4bd3480fac4ec9ae596ac21dbe0bb74e@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4539 ====================================================================== Reported By: GlenG Assigned To: ====================================================================== Project: setoolkit Issue ID: 4539 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-01 16:15 CEST Last Modified: 2010-09-01 16:15 CEST ====================================================================== Summary: SEToolkit is not collecting stats on network aggregations Description: According to http://freshmeat.net/projects/setoolkit the following changes were made at 3.5.0 on 05 Aug 2008: Changes: The transfer rate of fjgi doesn't overflow anymore. Missing instance definitions in several kstat structures have been added. New kstat structures for e1000g, ipge, aggr, fjge,... and bnx network interfaces have been added. The network interfaces bge and dmfe now use :kstat-style notation. kstat(1M)-style specification of kstat members can now be used. The current includes files from Orca have been pulled in. Extended regular expressions can be used now. This release has switched to autoconf/automake/libtool. The orcallator has been updated to r535 but the OpenCSW package does not collect aggr stats. ====================================================================== From noreply at opencsw.org Thu Sep 2 00:54:34 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 00:54:34 +0200 Subject: [bug-notifications] [libsocks 0004536]: undefined reference to upnpcleanup and upgrade to 1.2.1 In-Reply-To: <5e506babd6b1d6853f93ba63ca861a69> Message-ID: <347557e5f17cf1e4aedaad5d6aacf494@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4536 ====================================================================== Reported By: yann Assigned To: skayser ====================================================================== Project: libsocks Issue ID: 4536 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 14:26 CEST Last Modified: 2010-09-02 00:54 CEST ====================================================================== Summary: undefined reference to upnpcleanup and upgrade to 1.2.1 Description: I am currently trying to compile lftp with socks support and I am running into the following error: configure:10190: checking for main in -lsocks configure:10209: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include -m32 -xarch=386 -norunpath -L/opt/csw/lib conftest.c -lsocks >&5 cc: Warning: illegal option -norunpath "conftest.c", line 42: warning: statement not reached Undefined first referenced symbol in file upnpcleanup /opt/csw/lib/libsocks.so ld: fatal: Symbol referencing errors. No output written to conftest [...] This bug seems to have been fixed in the 1.2.1 version according to the changelog: Fix libsocks upnpcleanup() linking problem when compiled without libminiupnpc. Problem reported by Kyle Thurow and Adam Prato . Could you upgrade to 1.2.1 or fix the current version ? Thanks in advance. Yann ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- child of 0004481 Adding SOCKS5 proxy support into LFTP ====================================================================== ---------------------------------------------------------------------- (0008237) skayser (administrator) - 2010-09-02 00:54 https://www.opencsw.org/mantis/view.php?id=4536#c8237 ---------------------------------------------------------------------- Just FYI, libsocks has been pushed to current, currently pending release. http://lists.opencsw.org/pipermail/pkgsubmissions/2010-September/001200.html From noreply at opencsw.org Thu Sep 2 05:53:17 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 05:53:17 +0200 Subject: [bug-notifications] [hdf5 0004540]: Requesting version bump of HDF5 1.8 series to 1.8.5 Message-ID: <1552980db6314c3498e526097dbaaaca@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4540 ====================================================================== Reported By: gadavis Assigned To: ====================================================================== Project: hdf5 Issue ID: 4540 Category: upgrade Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-02 05:53 CEST Last Modified: 2010-09-02 05:53 CEST ====================================================================== Summary: Requesting version bump of HDF5 1.8 series to 1.8.5 Description: I see that the GAR Makefile is showing version 1.8.5, but the package that is available on the mirrors is still 1.8.4. I'm trying to build NetCDF 4.1.1 which requires HDF5 1.8.4-patch1 or higher. Any chance that a new batch of packages can be cut for HDF5? ====================================================================== From noreply at opencsw.org Thu Sep 2 11:28:46 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 11:28:46 +0200 Subject: [bug-notifications] [hdf5 0004540]: Requesting version bump of HDF5 1.8 series to 1.8.5 In-Reply-To: <9839e0ffeecdb88a03d2938c83d930fc> Message-ID: <1ca76fef844105666cdec3790a8f3f8c@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4540 ====================================================================== Reported By: gadavis Assigned To: dam ====================================================================== Project: hdf5 Issue ID: 4540 Category: upgrade Reproducibility: N/A Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-02 05:53 CEST Last Modified: 2010-09-02 11:28 CEST ====================================================================== Summary: Requesting version bump of HDF5 1.8 series to 1.8.5 Description: I see that the GAR Makefile is showing version 1.8.5, but the package that is available on the mirrors is still 1.8.4. I'm trying to build NetCDF 4.1.1 which requires HDF5 1.8.4-patch1 or higher. Any chance that a new batch of packages can be cut for HDF5? ====================================================================== From noreply at opencsw.org Thu Sep 2 16:00:25 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 16:00:25 +0200 Subject: [bug-notifications] [hdf5 0004540]: Requesting version bump of HDF5 1.8 series to 1.8.5 In-Reply-To: <9839e0ffeecdb88a03d2938c83d930fc> Message-ID: <7b7cc4867d145b9a5c0d3b1b9eae7349@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4540 ====================================================================== Reported By: gadavis Assigned To: dam ====================================================================== Project: hdf5 Issue ID: 4540 Category: upgrade Reproducibility: N/A Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-09-02 05:53 CEST Last Modified: 2010-09-02 16:00 CEST ====================================================================== Summary: Requesting version bump of HDF5 1.8 series to 1.8.5 Description: I see that the GAR Makefile is showing version 1.8.5, but the package that is available on the mirrors is still 1.8.4. I'm trying to build NetCDF 4.1.1 which requires HDF5 1.8.4-patch1 or higher. Any chance that a new batch of packages can be cut for HDF5? ====================================================================== ---------------------------------------------------------------------- (0008238) dam (administrator) - 2010-09-02 16:00 https://www.opencsw.org/mantis/view.php?id=4540#c8238 ---------------------------------------------------------------------- I had failing test cases in the past which are gone now, maybe due to the new Sun Studio compiler patches. Updated packages hdf5-1.8.5,REV=2010.09.02 are released to current/. From noreply at opencsw.org Thu Sep 2 16:01:19 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 16:01:19 +0200 Subject: [bug-notifications] [setoolkit 0004539]: SEToolkit is not collecting stats on network aggregations In-Reply-To: Message-ID: <11667fc363a54fee1fe882add451d2a5@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4539 ====================================================================== Reported By: GlenG Assigned To: dam ====================================================================== Project: setoolkit Issue ID: 4539 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-01 16:15 CEST Last Modified: 2010-09-02 16:01 CEST ====================================================================== Summary: SEToolkit is not collecting stats on network aggregations Description: According to http://freshmeat.net/projects/setoolkit the following changes were made at 3.5.0 on 05 Aug 2008: Changes: The transfer rate of fjgi doesn't overflow anymore. Missing instance definitions in several kstat structures have been added. New kstat structures for e1000g, ipge, aggr, fjge,... and bnx network interfaces have been added. The network interfaces bge and dmfe now use :kstat-style notation. kstat(1M)-style specification of kstat members can now be used. The current includes files from Orca have been pulled in. Extended regular expressions can be used now. This release has switched to autoconf/automake/libtool. The orcallator has been updated to r535 but the OpenCSW package does not collect aggr stats. ====================================================================== From noreply at opencsw.org Thu Sep 2 16:03:47 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 16:03:47 +0200 Subject: [bug-notifications] [setoolkit 0004539]: SEToolkit is not collecting stats on network aggregations In-Reply-To: Message-ID: <617cc96d8bd57b1f91be5ba62cd8bdda@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4539 ====================================================================== Reported By: GlenG Assigned To: dam ====================================================================== Project: setoolkit Issue ID: 4539 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-01 16:15 CEST Last Modified: 2010-09-02 16:03 CEST ====================================================================== Summary: SEToolkit is not collecting stats on network aggregations Description: According to http://freshmeat.net/projects/setoolkit the following changes were made at 3.5.0 on 05 Aug 2008: Changes: The transfer rate of fjgi doesn't overflow anymore. Missing instance definitions in several kstat structures have been added. New kstat structures for e1000g, ipge, aggr, fjge,... and bnx network interfaces have been added. The network interfaces bge and dmfe now use :kstat-style notation. kstat(1M)-style specification of kstat members can now be used. The current includes files from Orca have been pulled in. Extended regular expressions can be used now. This release has switched to autoconf/automake/libtool. The orcallator has been updated to r535 but the OpenCSW package does not collect aggr stats. ====================================================================== ---------------------------------------------------------------------- (0008239) dam (administrator) - 2010-09-02 16:03 https://www.opencsw.org/mantis/view.php?id=4539#c8239 ---------------------------------------------------------------------- The necessary code should be in include/kstat.se and include/netif.se, I'll see if I can reproduce this. From noreply at opencsw.org Thu Sep 2 16:09:36 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 16:09:36 +0200 Subject: [bug-notifications] [syslog_ng 0004409]: Installing syslog_ng package disables default Solaris syslog service when autoenable_daemons=no In-Reply-To: <78e46ebcfd6e69544bed7cce590a23ae> Message-ID: <8e67c89f715bb286439992ee42ce2867@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4409 ====================================================================== Reported By: ckmehta1 Assigned To: ====================================================================== Project: syslog_ng Issue ID: 4409 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-04-27 20:57 CEST Last Modified: 2010-09-02 16:09 CEST ====================================================================== Summary: Installing syslog_ng package disables default Solaris syslog service when autoenable_daemons=no Description: While syslog_ng respects the autoenable_daemons=no setting in /opt/csw/etc/csw.conf when you install the syslog_ng package, by default it ALWAYS disables the Solaris syslog service in the CSWsyslogng/install/preinstall script: /usr/sbin/svcadm disable svc:/system/system-log:default regardless of the autoenable setting. This is an issue if you want to install the package for availability over NFS/non-global-zones, but don't want to automatically disable syslog on the primary-machine's global-zone and leave the system without any form of syslog. Two possible autoenable settings that are applicable here would be: autoenable_daemons= autoenable_cswsyslog_ng= Hopefully the preinstall script can take the autoenable features into account in /opt/csw/etc/csw.conf ====================================================================== ---------------------------------------------------------------------- (0008240) skayser (administrator) - 2010-09-02 16:09 https://www.opencsw.org/mantis/view.php?id=4409#c8240 ---------------------------------------------------------------------- We are currently running into the same issue. We'd like to offer syslog-ng as a cluster service without actually touching the node local system-log service. Once we install CSWsyslogng on one of the nodes though, the node local system-log SMF service gets disabled. As we (at OpenCSW) have taken the route to not touch system services in other areas (postfix, cups), would it be possible to not disable system-log? At least if autoenable_daemons == no. From noreply at opencsw.org Thu Sep 2 19:23:45 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 19:23:45 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-02 19:23 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008241) phil (manager) - 2010-09-02 19:23 https://www.opencsw.org/mantis/view.php?id=4538#c8241 ---------------------------------------------------------------------- How is /opt/csw declared, in this "sparse root zone"? standalone filesystem? pkg-inherit? part of "/" ? From noreply at opencsw.org Thu Sep 2 19:23:53 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 19:23:53 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <6e229fbfaf279ace6668d449b3a4a70e@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-02 19:23 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008241) phil (manager) - 2010-09-02 19:23 https://www.opencsw.org/mantis/view.php?id=4538#c8241 ---------------------------------------------------------------------- How is /opt/csw declared, in this "sparse root zone"? standalone filesystem? pkg-inherit? part of "/" ? From noreply at opencsw.org Thu Sep 2 19:47:13 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 19:47:13 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <4aca03484515a49e3e15c353b27a151b@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-02 19:47 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008242) gadavis (developer) - 2010-09-02 19:47 https://www.opencsw.org/mantis/view.php?id=4538#c8242 ---------------------------------------------------------------------- Sorry, should have been explicit about that - /opt/csw ends up as part of the zone "/" partition, but no pkg-inherit-dir for it. We tend to have different packages installed on a per-zone basis than what is installed in the global zone. Here's a typical zone configuration from one of our systems: create -b set zonepath=/zones/anfds set autoboot=true set limitpriv=default set ip-type=shared add inherit-pkg-dir set dir=/lib end add inherit-pkg-dir set dir=/platform end add inherit-pkg-dir set dir=/sbin end add inherit-pkg-dir set dir=/usr end add fs set dir=/usr/local set special=/zones/anfds/local set type=lofs end add net set address=NETADDR Censored set physical=aggr1 end add net set address=NETADDR Censored set physical=e1000g1003 end add attr set name=comment set type=string set value="ANF Directory Server" end From noreply at opencsw.org Thu Sep 2 21:23:53 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 21:23:53 +0200 Subject: [bug-notifications] [hdf5 0004540]: Requesting version bump of HDF5 1.8 series to 1.8.5 In-Reply-To: <9839e0ffeecdb88a03d2938c83d930fc> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4540 ====================================================================== Reported By: gadavis Assigned To: dam ====================================================================== Project: hdf5 Issue ID: 4540 Category: upgrade Reproducibility: N/A Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2010-09-02 05:53 CEST Last Modified: 2010-09-02 21:23 CEST ====================================================================== Summary: Requesting version bump of HDF5 1.8 series to 1.8.5 Description: I see that the GAR Makefile is showing version 1.8.5, but the package that is available on the mirrors is still 1.8.4. I'm trying to build NetCDF 4.1.1 which requires HDF5 1.8.4-patch1 or higher. Any chance that a new batch of packages can be cut for HDF5? ====================================================================== ---------------------------------------------------------------------- (0008243) dam (administrator) - 2010-09-02 21:23 https://www.opencsw.org/mantis/view.php?id=4540#c8243 ---------------------------------------------------------------------- The buildfarm has been updated. From noreply at opencsw.org Thu Sep 2 22:53:41 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 22:53:41 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-02 22:53 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008244) phil (manager) - 2010-09-02 22:53 https://www.opencsw.org/mantis/view.php?id=4538#c8244 ---------------------------------------------------------------------- Thanks for the info. I'd say you're doing it "wrong", then. Either you should have /opt/csw as inherit-pkg-dir... (or possibly have it just directly mounted read-only from global zone...) or you should have it installed as a fully local package. Whats the point of having a zone-local filesystem for /opt/csw, if you're not going to have actual "local" packages installed? If you could recreate, or adjust, the zone, and let me know if this fixes your issue, then I would be happy to, on our side, update our documents with this additional information, in whichever locations you might suggest. I know you mentioned that you "tend to have different packages installed on a per-zone basis than what is installed in the global zone". but you cant "half-share" packages like this. pick one way or the other. ERROR: Sanity check failed ;-) From noreply at opencsw.org Thu Sep 2 23:14:20 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 23:14:20 +0200 Subject: [bug-notifications] [setoolkit 0004541]: add nxge interface to gigabit collection Message-ID: <9b0981e1bd42f3122bfd34762d26f515@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4541 ====================================================================== Reported By: hudesd Assigned To: ====================================================================== Project: setoolkit Issue ID: 4541 Category: regular use Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-02 23:14 CEST Last Modified: 2010-09-02 23:14 CEST ====================================================================== Summary: add nxge interface to gigabit collection Description: 5xx0 (T2/T2+) series systems have copper gigabit ports which are nxge interfaces. Please modify orcallator.cfg according to this patch: -bash-3.00$ diff -u orcallator.cfg.CSW orcallator.cfg --- orcallator.cfg.CSW Wed Aug 4 05:09:04 2010 +++ orcallator.cfg Thu Sep 2 13:49:05 2010 @@ -356,7 +356,7 @@ plot { title %g Interface Bits Per Second: $1 source orcallator -data 1024 * 8 * ((?:(?:bge)|(?:ce)|(?:fjg[ei])|(?:v?ge)|(?:skge)|(?:e1000g)|(?:ipge)|(?:bnx))\d+)InKB/s +data 1024 * 8 * ((?:(?:bge)|(?:ce)|(?:nxge)|(?:fjg[ei])|(?:v?ge)|(?:skge)|(?:e1000g)|(?:ipge)|(?:bnx))\d+)InKB/s data 1024 * 8 * $1OuKB/s line_type area line_type line1 ====================================================================== From noreply at opencsw.org Thu Sep 2 23:30:49 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 23:30:49 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-02 23:30 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008245) gadavis (developer) - 2010-09-02 23:30 https://www.opencsw.org/mantis/view.php?id=4538#c8245 ---------------------------------------------------------------------- Phil, I'm confused what you mean by "or you should have it installed as a fully local package." Can you suggest what changes I would need to make to my zonecfg commands, or elaborate further? I'm not sharing any files from in the /opt/csw/ tree with the global zone. There are no loopback mounts anywhere for /opt/csw in the zone manifest that I pasted above. So therefore, a newly created sparse-root zone has it's own full copies of whatever CSW packages were installed in the global zone. The only exception to this rule is CSWclassutils, which has to put it's class action scripts in /usr. >From the section on "Sparse Root Zones" in zonecfg(1M): Packages that do not deliver content into read-only loopback mount file systems are fully installed. From noreply at opencsw.org Thu Sep 2 23:42:08 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 2 Sep 2010 23:42:08 +0200 Subject: [bug-notifications] [subversion 0004542]: Subversion needs a client only compilation Message-ID: <6f09fd90eaee33cbb1d9cac84b1f6d5f@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4542 ====================================================================== Reported By: fuqqer Assigned To: ====================================================================== Project: subversion Issue ID: 4542 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-02 23:42 CEST Last Modified: 2010-09-02 23:42 CEST ====================================================================== Summary: Subversion needs a client only compilation Description: the subversion package should not have heavy requirements just to check out from a tree. There should be a client and a server side package for subversion. ====================================================================== From noreply at opencsw.org Fri Sep 3 00:12:57 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 00:12:57 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <0c57ca5027fb85285e20efa5c1e81fed@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-03 00:12 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008246) phil (manager) - 2010-09-03 00:12 https://www.opencsw.org/mantis/view.php?id=4538#c8246 ---------------------------------------------------------------------- Part one of reply: To have a fully local package install, without changing anything else in your setup, you would have to do BOTH of - stop installing CSW packages in the global zone(or use pkgadd -G) - run pkgadd individually in each zone Note, however, that using pkgadd -G is not a good solution, since sun screwed up/orphaned the implementation. There is no pkgrm -G. So the next time you do pkgrm in the global(ie for an upgrade!), you will then pkgrm in all child zones automatically! part two of reply: the problem is that if you are not inherit-pkg-dir-ing, then updates may not get shared out to child zones properly. Things get copied okay initially, when you first create a child zone.. but then things drift, I think. Things get especially dangerous in a mixed mode, when you pkgadd/rm from global; You have class action scripts, and/or pre/postinstall scripts running, from the package in the global zone, that expect the same version of files in the package, but the actual files in the child zone may not be the same version. Note: I have not actually TESTED the behaviour in mixed-mode recently, but I believe this is the source of your problems. I think I'll go do some experimenting. From noreply at opencsw.org Fri Sep 3 01:21:50 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 01:21:50 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-03 01:21 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008247) gadavis (developer) - 2010-09-03 01:21 https://www.opencsw.org/mantis/view.php?id=4538#c8247 ---------------------------------------------------------------------- I can see where the class action scripts could cause problems in this mixed-mode when packages are added and removed. However, just to be clear, no further pkgadd commands were run in either the global zone or non-global zone after the zone was installed with "zoneadm -z whatever install" It's worth determining what exactly happens with the class action scripts when zoneadm install is run and the list of currently installed packages is duplicated to the zone. From noreply at opencsw.org Fri Sep 3 01:58:23 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 01:58:23 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <4b0373106b60fac4720a184f280c88e2@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-03 01:58 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008248) phil (manager) - 2010-09-03 01:58 https://www.opencsw.org/mantis/view.php?id=4538#c8248 ---------------------------------------------------------------------- Is your "alternatives" package up to date? I can imagine how the older implementation would have this problem, but not the newer one. (which is exactly why I WROTE the newer implementation! :-) From noreply at opencsw.org Fri Sep 3 03:02:08 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 03:02:08 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-03 03:02 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008249) phil (manager) - 2010-09-03 03:02 https://www.opencsw.org/mantis/view.php?id=4538#c8249 ---------------------------------------------------------------------- Hmm.. btw i take back what I said about pkgadd -G. If you always use it for global-zone CSW packages, it seems as though pkgrm knows the package was installed with -G, and so will not pkgrm in the child zones. I havent yet found out where it STORES this information in the global zone, which is making me a bit... irritated... but observationally, it at least appears to follow this behaviour somehow. From noreply at opencsw.org Fri Sep 3 12:47:18 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:47:18 +0200 Subject: [bug-notifications] [postfix 0003017]: Please depend against CSWpcrert instead of CSWpcre In-Reply-To: Message-ID: <9b95cbeb100aee4fa90c09ca0e418026@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=3017 ====================================================================== Reported By: dam Assigned To: skayser ====================================================================== Project: postfix Issue ID: 3017 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: resolved Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2009-01-15 16:29 CET Last Modified: 2010-09-03 12:47 CEST ====================================================================== Summary: Please depend against CSWpcrert instead of CSWpcre Description: Please depend against CSWpcrert instead of CSWpcre ====================================================================== ---------------------------------------------------------------------- (0008250) skayser (administrator) - 2010-09-03 12:47 https://www.opencsw.org/mantis/view.php?id=3017#c8250 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:47:28 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:47:28 +0200 Subject: [bug-notifications] [postfix 0003017]: Please depend against CSWpcrert instead of CSWpcre In-Reply-To: Message-ID: <616f63e8558960faf087690a87e4e5c5@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3017 ====================================================================== Reported By: dam Assigned To: skayser ====================================================================== Project: postfix Issue ID: 3017 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2009-01-15 16:29 CET Last Modified: 2010-09-03 12:47 CEST ====================================================================== Summary: Please depend against CSWpcrert instead of CSWpcre Description: Please depend against CSWpcrert instead of CSWpcre ====================================================================== ---------------------------------------------------------------------- (0008250) skayser (administrator) - 2010-09-03 12:47 https://www.opencsw.org/mantis/view.php?id=3017#c8250 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:47:49 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:47:49 +0200 Subject: [bug-notifications] [postfix 0002097]: `postconf -m` should support the lookup table type of \'hash\' In-Reply-To: <550ffaa45c0e04660f0b07d34975d3de> Message-ID: <7a9b0ce4eddfd1f15fee19bd2518711c@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=2097 ====================================================================== Reported By: kadowaki Assigned To: skayser ====================================================================== Project: postfix Issue ID: 2097 Category: packaging Reproducibility: always Severity: feature Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2007-01-04 00:14 CET Last Modified: 2010-09-03 12:47 CEST ====================================================================== Summary: `postconf -m` should support the lookup table type of \'hash\' Description: The lookup table type of \"hash\" is required to make postfix talk to SMTP-Auth enabled MTA as relayhost. As far as I know, followings are the most popular configurations in main.cf . smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/opt/csw/etc/postfix/sasl_passwd smtp_sasl_security_options = But, currently CSWpostfix does not support \"hash\". \"hash\" support should be integrated. ====================================================================== ---------------------------------------------------------------------- (0008251) skayser (administrator) - 2010-09-03 12:47 https://www.opencsw.org/mantis/view.php?id=2097#c8251 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:48:09 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:48:09 +0200 Subject: [bug-notifications] [postfix 0002964]: posfix shouldn't touch /usr filesystem on a solaris 10 sparse root zone In-Reply-To: <2f7be2c38be0e49f9c3e9b2d5ba99723> Message-ID: <06f3bfd2d4774aa2b214ff6409bb24cd@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=2964 ====================================================================== Reported By: fred Assigned To: skayser ====================================================================== Project: postfix Issue ID: 2964 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2008-12-02 09:41 CET Last Modified: 2010-09-03 12:48 CEST ====================================================================== Summary: posfix shouldn't touch /usr filesystem on a solaris 10 sparse root zone Description: Installing postfix on a solaris 10 sparse root zone: ## Executing postinstall script. CSWpostfix is renaming /usr/lib/sendmail, /usr/bin/newaliases and /usr/bin/mailq to *.OFF. Turning off /usr/lib/sendmail to enable the Postfix version mv: cannot rename /usr/lib/sendmail to /usr/lib/sendmail.OFF: Read-only file system Turning off /usr/bin/newaliases to enable the Postfix version mv: cannot access /usr/bin/newaliases Turning off /usr/bin/mailq to enable the Postfix version mv: cannot rename /usr/bin/mailq to /usr/bin/mailq.OFF: Read-only file system Linking /usr/lib/sendmail to /opt/csw/sbin/postfix ln: cannot create /usr/lib/sendmail: Read-only file system Linking /usr/bin/newaliases to /opt/csw/bin/newaliases ln: cannot create /usr/bin/newaliases: Read-only file system Linking /usr/bin/mailq to /opt/csw/bin/mailq ln: cannot create /usr/bin/mailq: Read-only file system ====================================================================== ---------------------------------------------------------------------- (0008252) skayser (administrator) - 2010-09-03 12:48 https://www.opencsw.org/mantis/view.php?id=2964#c8252 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:48:31 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:48:31 +0200 Subject: [bug-notifications] [postfix 0003060]: mv error in postinstall In-Reply-To: <4c2cdf8249e057b7a2e5129f1edab299> Message-ID: <03d990f203cdd5b05e487777f288773a@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3060 ====================================================================== Reported By: pfelecan Assigned To: skayser ====================================================================== Project: postfix Issue ID: 3060 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2009-02-05 18:43 CET Last Modified: 2010-09-03 12:48 CEST ====================================================================== Summary: mv error in postinstall Description: Solaris 10 10/08 s10x_u6wos_07b X86 In the postinstall script, when trying to move newaliases binary, the operation fails. Here is the installation relevant part: ## Executing postinstall script. CSWpostfix is renaming /usr/lib/sendmail, /usr/bin/newaliases and /usr/bin/mailq to *.OFF. Turning off /usr/lib/sendmail to enable the Postfix version Turning off /usr/bin/newaliases to enable the Postfix version mv: cannot access /usr/bin/newaliases Turning off /usr/bin/mailq to enable the Postfix version Linking /usr/lib/sendmail to /opt/csw/sbin/postfix Linking /usr/bin/newaliases to /opt/csw/bin/newaliases Linking /usr/bin/mailq to /opt/csw/bin/mailq ************************************************************ * Warning * ************************************************************ * This package keep the configuration files under * * /etc/opt/csw/postfix instead of the old prefix of * * /opt/csw/etc/postfix to make it zone-safe * ************************************************************ Installation of was successful. ====================================================================== ---------------------------------------------------------------------- (0008253) skayser (administrator) - 2010-09-03 12:48 https://www.opencsw.org/mantis/view.php?id=3060#c8253 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:48:49 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:48:49 +0200 Subject: [bug-notifications] [postfix 0003063]: /opt/csw/libexec/postfix not stripped, takes ~30MB In-Reply-To: <04bb44a4e12392f146860ab0a4b12060> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3063 ====================================================================== Reported By: skayser Assigned To: skayser ====================================================================== Project: postfix Issue ID: 3063 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2009-02-11 23:40 CET Last Modified: 2010-09-03 12:48 CEST ====================================================================== Summary: /opt/csw/libexec/postfix not stripped, takes ~30MB Description: I just wondered why the CSWpostfix package is so huge (10MB). No wonder, files in /opt/csw/libexec/postfix are compiled with debugging symbols and are not stripped ;) /opt/csw/libexec/postfix# du -ks . 30533 . Notice the -g flag /opt/csw/libexec/postfix# /opt/SUNWspro/bin/dwarfdump -i lmtp | grep DW_AT_SUN_command | head -1 DW_AT_SUN_command_line /opt/SUNWspro/prod/bin/cc -DUSE_TLS -DUSE_SASL_AUTH -DHAS_LDAP -DHAS_PCRE -DHAS_MYSQL -DHAS_PGSQL -DHAS_DB -DDEF_MANPAGE_DIR='"/opt/csw/man"' -DDEF_COMMAND_DIR='"/opt/csw/sbin"' -DDEF_CONFIG_DIR='"/etc/opt/csw/postfix"' -DDEF_DAEMON_DIR='"/opt/csw/libexec/postfix"' -DDEF_MAILQ_PATH='"/opt/csw/bin/mailq"' -DDEF_HTML_DIR='"yes"' -DDEF_NEWALIAS_PATH='"/opt/csw/bin/newaliases"' -DDEF_QUEUE_DIR='"/opt/csw/var/spool/postfix"' -DDEF_README_DIR='"yes"' -I/opt/csw/include -I/opt/csw/include/openssl -I/opt/csw/include/sasl -I/opt/csw/mysql4/include/mysql -I/opt/csw/postgresql/include -I/opt/csw/bdb4/include -DNO_CLOSEFROM -DNO_DEV_URANDOM -DNO_FUTIMESAT -Dstrcasecmp='fix_strcasecmp' -Dstrncasecmp='fix_strncasecmp' -g -O -I. -I../../include -DSUNOS5 -c smtp.c -W0,-xp.XAAj6I\$vgRPIV9P. After a strip, it looks better /opt/csw/libexec/postfix# strip * /opt/csw/libexec/postfix# du -ks . 12091 . Just add STRIP_DIRS = $(DESTDIR)$(libexecdir)/postfix to your GAR Makefile and you should be fine. ====================================================================== ---------------------------------------------------------------------- (0008254) skayser (administrator) - 2010-09-03 12:48 https://www.opencsw.org/mantis/view.php?id=3063#c8254 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:49:36 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:49:36 +0200 Subject: [bug-notifications] [postfix 0003580]: Not sun4m compatible In-Reply-To: Message-ID: <9eb8165a2d19dae8b59baa69675ac3ed@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3580 ====================================================================== Reported By: james Assigned To: skayser ====================================================================== Project: postfix Issue ID: 3580 Category: packaging Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2009-04-01 21:30 CEST Last Modified: 2010-09-03 12:49 CEST ====================================================================== Summary: Not sun4m compatible Description: Not sun4m compatible, needs -xarch=v8. ====================================================================== ---------------------------------------------------------------------- (0008255) skayser (administrator) - 2010-09-03 12:49 https://www.opencsw.org/mantis/view.php?id=3580#c8255 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:49:54 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:49:54 +0200 Subject: [bug-notifications] [postfix 0004349]: Upgrade to Postfix 2.5.1 In-Reply-To: <0aeeb19a668ffda750f05f5168fd2b8b> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4349 ====================================================================== Reported By: kenmays Assigned To: skayser ====================================================================== Project: postfix Issue ID: 4349 Category: upgrade Reproducibility: always Severity: block Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-03-16 22:49 CET Last Modified: 2010-09-03 12:49 CEST ====================================================================== Summary: Upgrade to Postfix 2.5.1 Description: http://mirrors.isc.org/pub/postfix/official/postfix-2.5.1.RELEASE_NOTES ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- has duplicate 0003970 Postfix 2.6.5 released has duplicate 0003700 Postfix 2.6.1 released ====================================================================== ---------------------------------------------------------------------- (0008256) skayser (administrator) - 2010-09-03 12:49 https://www.opencsw.org/mantis/view.php?id=4349#c8256 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:50:27 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:50:27 +0200 Subject: [bug-notifications] [postfix 0003946]: configuration is not zone friendly In-Reply-To: <3ee724edf06d4b976514574e4aeaebe1> Message-ID: <237bf5d8edd03864e8457a4b20eaf06d@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3946 ====================================================================== Reported By: japester Assigned To: skayser ====================================================================== Project: postfix Issue ID: 3946 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2009-10-07 19:09 CEST Last Modified: 2010-09-03 12:50 CEST ====================================================================== Summary: configuration is not zone friendly Description: 1. filesystem layout is not zone friendly. The spool directory is set to /opt/csw/var/spool/postfix, which violates the OpenCSW filesystem standards and ensures that only the global container can run postfix. Solution: set the spool directory to in /var/opt/csw/spool/postfix, or similar. 2. SMF manifest is not installed into non-global zones update the postinstall scripts to install the smf in non-global zones. ====================================================================== ---------------------------------------------------------------------- (0008257) skayser (administrator) - 2010-09-03 12:50 https://www.opencsw.org/mantis/view.php?id=3946#c8257 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 12:51:50 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 12:51:50 +0200 Subject: [bug-notifications] [postfix 0004414]: When configuring postfix to relay with gmail there is a problem with sasl In-Reply-To: Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4414 ====================================================================== Reported By: g_lamon Assigned To: skayser ====================================================================== Project: postfix Issue ID: 4414 Category: packaging Reproducibility: always Severity: block Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-05-10 11:54 CEST Last Modified: 2010-09-03 12:51 CEST ====================================================================== Summary: When configuring postfix to relay with gmail there is a problem with sasl Description: warning: unsupported SASL client implementation: cyrus fatal: SASL library initialization process /opt/csw/libexec/postfix/smtp pid 3169 exit status 1 /opt/csw/libexec/postfix/smtp: bad command startup -- throttling it seems that it have to be compiled with CYRUS_SASL flag enabled ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- has duplicate 0002843 No cyrus-sasl support ====================================================================== ---------------------------------------------------------------------- (0008258) skayser (administrator) - 2010-09-03 12:51 https://www.opencsw.org/mantis/view.php?id=4414#c8258 ---------------------------------------------------------------------- Fixed with 2.7.1,REV=2010.09.01 which is now available from current/. From noreply at opencsw.org Fri Sep 3 13:58:20 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 13:58:20 +0200 Subject: [bug-notifications] [vsftpd 0004516]: Please upgrade to 2.3.0 In-Reply-To: Message-ID: <472a308a8934755e8c9111036f57e60b@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4516 ====================================================================== Reported By: dam Assigned To: yann ====================================================================== Project: vsftpd Issue ID: 4516 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2010-08-07 22:25 CEST Last Modified: 2010-09-03 13:58 CEST ====================================================================== Summary: Please upgrade to 2.3.0 Description: Please upgrade to 2.3.0 ====================================================================== ---------------------------------------------------------------------- (0008259) yann (manager) - 2010-09-03 13:58 https://www.opencsw.org/mantis/view.php?id=4516#c8259 ---------------------------------------------------------------------- Done: http://www.opencsw.org/packages/CSWvsftpd/ From noreply at opencsw.org Fri Sep 3 14:00:57 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 14:00:57 +0200 Subject: [bug-notifications] [lftp 0004481]: Adding SOCKS5 proxy support into LFTP In-Reply-To: <0b6063ecfd4e24d73472d3490f8c1e0d> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4481 ====================================================================== Reported By: ckmehta1 Assigned To: yann ====================================================================== Project: lftp Issue ID: 4481 Category: regular use Reproducibility: always Severity: feature Priority: normal Status: acknowledged ====================================================================== Date Submitted: 2010-06-30 07:04 CEST Last Modified: 2010-09-03 14:00 CEST ====================================================================== Summary: Adding SOCKS5 proxy support into LFTP Description: Please add SOCKS5 proxy support into OpenCSW version of LFTP. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0004536 undefined reference to upnpcleanup and ... ====================================================================== ---------------------------------------------------------------------- (0008260) yann (manager) - 2010-09-03 14:00 https://www.opencsw.org/mantis/view.php?id=4481#c8260 ---------------------------------------------------------------------- I rebuilt last upstream version with socks5 support enabled. It should enter unstable soon, you can download them from my experimental repository if you don't want to wait: http://mirror.opencsw.org/experimental.html#yann From noreply at opencsw.org Fri Sep 3 14:01:54 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 14:01:54 +0200 Subject: [bug-notifications] [libsocks 0004536]: undefined reference to upnpcleanup and upgrade to 1.2.1 In-Reply-To: <5e506babd6b1d6853f93ba63ca861a69> Message-ID: <0de81a542d465c486b94dabf8639ceb1@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4536 ====================================================================== Reported By: yann Assigned To: skayser ====================================================================== Project: libsocks Issue ID: 4536 Category: regular use Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-08-31 14:26 CEST Last Modified: 2010-09-03 14:01 CEST ====================================================================== Summary: undefined reference to upnpcleanup and upgrade to 1.2.1 Description: I am currently trying to compile lftp with socks support and I am running into the following error: configure:10190: checking for main in -lsocks configure:10209: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include -m32 -xarch=386 -norunpath -L/opt/csw/lib conftest.c -lsocks >&5 cc: Warning: illegal option -norunpath "conftest.c", line 42: warning: statement not reached Undefined first referenced symbol in file upnpcleanup /opt/csw/lib/libsocks.so ld: fatal: Symbol referencing errors. No output written to conftest [...] This bug seems to have been fixed in the 1.2.1 version according to the changelog: Fix libsocks upnpcleanup() linking problem when compiled without libminiupnpc. Problem reported by Kyle Thurow and Adam Prato . Could you upgrade to 1.2.1 or fix the current version ? Thanks in advance. Yann ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- child of 0004481 Adding SOCKS5 proxy support into LFTP ====================================================================== ---------------------------------------------------------------------- (0008261) yann (developer) - 2010-09-03 14:01 https://www.opencsw.org/mantis/view.php?id=4536#c8261 ---------------------------------------------------------------------- the updated package entered current and has been installed on the build farm. I am closing this bug, thanks for your quick response. From noreply at opencsw.org Fri Sep 3 14:01:55 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 14:01:55 +0200 Subject: [bug-notifications] [lftp 0004481]: Adding SOCKS5 proxy support into LFTP In-Reply-To: <0b6063ecfd4e24d73472d3490f8c1e0d> Message-ID: The RELATED issue 0004536 has been CLOSED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4481 ====================================================================== Reported By: ckmehta1 Assigned To: yann ====================================================================== Project: lftp Issue ID: 4481 Category: regular use Reproducibility: always Severity: feature Priority: normal Status: acknowledged ====================================================================== Date Submitted: 2010-06-30 07:04 CEST Last Modified: 2010-09-03 14:00 CEST ====================================================================== Summary: Adding SOCKS5 proxy support into LFTP Description: Please add SOCKS5 proxy support into OpenCSW version of LFTP. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0004536 undefined reference to upnpcleanup and ... ====================================================================== ---------------------------------------------------------------------- (0008260) yann (developer) - 2010-09-03 14:00 https://www.opencsw.org/mantis/view.php?id=4481#c8260 ---------------------------------------------------------------------- I rebuilt last upstream version with socks5 support enabled. It should enter unstable soon, you can download them from my experimental repository if you don't want to wait: http://mirror.opencsw.org/experimental.html#yann From noreply at opencsw.org Fri Sep 3 14:54:47 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 14:54:47 +0200 Subject: [bug-notifications] [cswclassutils 0004543]: Configuration migration doesn't work properly if a directory is given Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4543 ====================================================================== Reported By: yann Assigned To: ====================================================================== Project: cswclassutils Issue ID: 4543 Category: regular use Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-03 14:54 CEST Last Modified: 2010-09-03 14:54 CEST ====================================================================== Summary: Configuration migration doesn't work properly if a directory is given Description: Hi, According to the wiki page, cswclassutils cswmigrateconf class action script can migrate a whole directory: "If a path specified in MIGRATE_FILES is a directory, the whole directory tree is going to be copied." [1] However I was not able to use this mode successfully with vsftpd. It seems that before doing the migration, the script always tries to test the existence of /etc/opt/csw/vsftpd.CSW which is not applicable in the directory case: # If there's a sample configuration file, remove the copied one. __sample_conf="${__dest_file_name}.CSW" if [ -r "${__sample_conf}" ]; then if files_are_identical "${__sample_conf}" "${__dest_file_name}"; then return "${__do_copy}" else return "${__do_not_copy}" fi fi Have I done something wrong or is it a bug ? Thanks in advance for your answer. [1] http://wiki.opencsw.org/cswclassutils-package#toc15 ====================================================================== From noreply at opencsw.org Fri Sep 3 16:32:29 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 16:32:29 +0200 Subject: [bug-notifications] [cswclassutils 0004543]: Configuration migration doesn't work properly if a directory is given In-Reply-To: Message-ID: <750ae3e281ead5f18916735112c87fd1@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4543 ====================================================================== Reported By: yann Assigned To: ====================================================================== Project: cswclassutils Issue ID: 4543 Category: regular use Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-03 14:54 CEST Last Modified: 2010-09-03 16:32 CEST ====================================================================== Summary: Configuration migration doesn't work properly if a directory is given Description: Hi, According to the wiki page, cswclassutils cswmigrateconf class action script can migrate a whole directory: "If a path specified in MIGRATE_FILES is a directory, the whole directory tree is going to be copied." [1] However I was not able to use this mode successfully with vsftpd. It seems that before doing the migration, the script always tries to test the existence of /etc/opt/csw/vsftpd.CSW which is not applicable in the directory case: # If there's a sample configuration file, remove the copied one. __sample_conf="${__dest_file_name}.CSW" if [ -r "${__sample_conf}" ]; then if files_are_identical "${__sample_conf}" "${__dest_file_name}"; then return "${__do_copy}" else return "${__do_not_copy}" fi fi Have I done something wrong or is it a bug ? Thanks in advance for your answer. [1] http://wiki.opencsw.org/cswclassutils-package#toc15 ====================================================================== ---------------------------------------------------------------------- (0008262) maciej (developer) - 2010-09-03 16:32 https://www.opencsw.org/mantis/view.php?id=4543#c8262 ---------------------------------------------------------------------- You probably spotted a bug. The directory case wasn't tested well. What do you think would be a good fix? Testing whether __dest_file_name is a directory, and have a separate clause for it? From noreply at opencsw.org Fri Sep 3 16:43:48 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 16:43:48 +0200 Subject: [bug-notifications] [cswclassutils 0004543]: Configuration migration doesn't work properly if a directory is given In-Reply-To: Message-ID: <4849452bf44b35076b4489251340f088@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4543 ====================================================================== Reported By: yann Assigned To: maciej ====================================================================== Project: cswclassutils Issue ID: 4543 Category: regular use Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-03 14:54 CEST Last Modified: 2010-09-03 16:43 CEST ====================================================================== Summary: Configuration migration doesn't work properly if a directory is given Description: Hi, According to the wiki page, cswclassutils cswmigrateconf class action script can migrate a whole directory: "If a path specified in MIGRATE_FILES is a directory, the whole directory tree is going to be copied." [1] However I was not able to use this mode successfully with vsftpd. It seems that before doing the migration, the script always tries to test the existence of /etc/opt/csw/vsftpd.CSW which is not applicable in the directory case: # If there's a sample configuration file, remove the copied one. __sample_conf="${__dest_file_name}.CSW" if [ -r "${__sample_conf}" ]; then if files_are_identical "${__sample_conf}" "${__dest_file_name}"; then return "${__do_copy}" else return "${__do_not_copy}" fi fi Have I done something wrong or is it a bug ? Thanks in advance for your answer. [1] http://wiki.opencsw.org/cswclassutils-package#toc15 ====================================================================== ---------------------------------------------------------------------- (0008262) maciej (developer) - 2010-09-03 16:32 https://www.opencsw.org/mantis/view.php?id=4543#c8262 ---------------------------------------------------------------------- You probably spotted a bug. The directory case wasn't tested well. What do you think would be a good fix? Testing whether __dest_file_name is a directory, and have a separate clause for it? From noreply at opencsw.org Fri Sep 3 19:54:48 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 19:54:48 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-03 19:54 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008263) gadavis (developer) - 2010-09-03 19:54 https://www.opencsw.org/mantis/view.php?id=4538#c8263 ---------------------------------------------------------------------- CSWalternatives is 1.0,REV=2010.05.21 which is what is reported as current. From noreply at opencsw.org Fri Sep 3 21:51:16 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 21:51:16 +0200 Subject: [bug-notifications] [setoolkit 0004539]: SEToolkit is not collecting stats on network aggregations In-Reply-To: Message-ID: <0f6af1284d0014dd554da8be4118f81a@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4539 ====================================================================== Reported By: GlenG Assigned To: dam ====================================================================== Project: setoolkit Issue ID: 4539 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-01 16:15 CEST Last Modified: 2010-09-03 21:51 CEST ====================================================================== Summary: SEToolkit is not collecting stats on network aggregations Description: According to http://freshmeat.net/projects/setoolkit the following changes were made at 3.5.0 on 05 Aug 2008: Changes: The transfer rate of fjgi doesn't overflow anymore. Missing instance definitions in several kstat structures have been added. New kstat structures for e1000g, ipge, aggr, fjge,... and bnx network interfaces have been added. The network interfaces bge and dmfe now use :kstat-style notation. kstat(1M)-style specification of kstat members can now be used. The current includes files from Orca have been pulled in. Extended regular expressions can be used now. This release has switched to autoconf/automake/libtool. The orcallator has been updated to r535 but the OpenCSW package does not collect aggr stats. ====================================================================== ---------------------------------------------------------------------- (0008264) GlenG (reporter) - 2010-09-03 21:51 https://www.opencsw.org/mantis/view.php?id=4539#c8264 ---------------------------------------------------------------------- Dago, I updated CSWorca from r535,REV=2009.03.19 to snapshot_r535,REV=2009.11.25 and aggr is now collecting. I understood "The current includes files from Orca have been pulled in." to mean the orca parts were included in the SEToolkit install. Sorry about that. (It's not graphing in a useful way but that's a problem for a different venu.) Here's what I'm getting now: head -1 /var/opt/csw/orca/orcallator/beaker/orcallator-2010-09-03-000 timestamp locltime uptime state_D state_N state_n state_s state_r state_k state_c state_m state_d state_i state_t DNnsrkcmdit usr% sys% wio% idle% 1runq 5runq 15runq #proc #runque #waiting #swpque scanrate pgrec/s pgfrec/s pgin/s pages_in/s pgout/s pages_out/s dfree/s min_fault/s maj_fault/s prot_fault/s cow_fault/s zfod/s interrupts/s intrthread/s system_calls/s context_switches/s invol_switches/s traps/s forks/s vforks/s execs/s namei/s ufsiget/s ufsdirblk/s #proc/s #proc/p5s smtx smtx/cpu ncpus mntC_/ mntU_/ mntA_/ mntP_/ mntc_/ mntu_/ mnta_/ mntp_/ mntC_/var mntU_/var mntA_/var mntP_/var mntc_/var mntu_/var mnta_/var mntp_/var mntC_/opt/openv mntU_/opt/openv mntA_/opt/openv mntP_/opt/openv mntc_/opt/openv mntu_/opt/openv mnta_/opt/openv mntp_/opt/openv mntC_/backup1fs mntU_/backup1fs mntA_/backup1fs mntP_/backup1fs mntc_/backup1fs mntu_/backup1fs mnta_/backup1fs mntp_/backup1fs mntC_/backup2fs mntU_/backup2fs mntA_/backup2fs mntP_/backup2fs mntc_/backup2fs mntu_/backup2fs mnta_/backup2fs mntp_/backup2fs mntC_/backup3fs mntU_/backup3fs mntA_/backup3fs mntP_/backup3fs mntc_/backup3fs mntu_/backup3fs mnta_/backup3fs mntp_/backup3fs mntC_/backup4fs mntU_/backup4fs mntA_/backup4fs mntP_/backup4fs mntc_/backup4fs mntu_/backup4fs mnta_/backup4fs mntp_/backup4fs mntC_/backupQ6TB mntU_/backupQ6TB mntA_/backupQ6TB mntP_/backupQ6TB mntc_/backupQ6TB mntu_/backupQ6TB mnta_/backupQ6TB mntp_/backupQ6TB mntC_/zpool1 mntU_/zpool1 mntA_/zpool1 mntP_/zpool1 mntc_/zpool1 mntu_/zpool1 mnta_/zpool1 mntp_/zpool1 disk_runp_sd3 disk_svct_sd3 disk_runp_sd7 disk_svct_sd7 disk_runp_sd11 disk_svct_sd11 disk_runp_sd16 disk_svct_sd16 disk_runp_sd19 disk_svct_sd19 disk_runp_sd25 disk_svct_sd25 disk_runp_sd30 disk_svct_sd30 disk_runp_sd36 disk_svct_sd36 disk_runp_md16 disk_svct_md16 disk_runp_md17 disk_svct_md17 disk_runp_md15 disk_svct_md15 disk_runp_sd53 disk_svct_sd53 disk_runp_sd54 disk_svct_sd54 disk_runp_sd51 disk_svct_sd51 disk_runp_sd52 disk_svct_sd52 disk_runp_md21 disk_svct_md21 disk_runp_md22 disk_svct_md22 disk_runp_md20 disk_svct_md20 disk_runp_sd9 disk_svct_sd9 disk_runp_sd4 disk_svct_sd4 disk_runp_sd2 disk_svct_sd2 disk_runp_sd1 disk_svct_sd1 disk_runp_sd42 disk_svct_sd42 disk_runp_sd6 disk_svct_sd6 disk_runp_sd15 disk_svct_sd15 disk_runp_sd8 disk_svct_sd8 disk_runp_sd43 disk_svct_sd43 disk_runp_sd10 disk_svct_sd10 disk_runp_sd12 disk_svct_sd12 disk_runp_sd20 disk_svct_sd20 disk_runp_sd44 disk_svct_sd44 disk_runp_sd13 disk_svct_sd13 disk_runp_sd17 disk_svct_sd17 disk_runp_sd24 disk_svct_sd24 disk_runp_sd14 disk_svct_sd14 disk_runp_sd18 disk_svct_sd18 disk_runp_sd45 disk_svct_sd45 disk_runp_sd21 disk_svct_sd21 disk_runp_sd22 disk_svct_sd22 disk_runp_sd27 disk_svct_sd27 disk_runp_sd46 disk_svct_sd46 disk_runp_sd28 disk_svct_sd28 disk_runp_sd23 disk_svct_sd23 disk_runp_sd47 disk_svct_sd47 disk_runp_sd32 disk_svct_sd32 disk_runp_sd34 disk_svct_sd34 disk_runp_sd26 disk_svct_sd26 disk_runp_sd31 disk_svct_sd31 disk_runp_sd39 disk_svct_sd39 disk_runp_sd48 disk_svct_sd48 disk_runp_sd38 disk_svct_sd38 disk_runp_sd29 disk_svct_sd29 disk_runp_sd33 disk_svct_sd33 disk_runp_sd40 disk_svct_sd40 disk_runp_sd49 disk_svct_sd49 disk_runp_sd35 disk_svct_sd35 disk_runp_sd41 disk_svct_sd41 disk_runp_sd37 disk_svct_sd37 disk_runp_md36 disk_svct_md36 disk_runp_md37 disk_svct_md37 disk_runp_md35 disk_svct_md35 disk_runp_md41 disk_svct_md41 disk_runp_md42 disk_svct_md42 disk_runp_md40 disk_svct_md40 disk_runp_md11 disk_svct_md11 disk_runp_md12 disk_svct_md12 disk_runp_md10 disk_svct_md10 disk_runp_md31 disk_svct_md31 disk_runp_md32 disk_svct_md32 disk_runp_md30 disk_svct_md30 disk_peak disk_mean disk_rd/s disk_wr/s disk_rK/s disk_wK/s tape_runp_st0 tape_svct_st0 tape_runp_st1 tape_svct_st1 tape_peak tape_mean tape_rd/s tape_wr/s tape_rK/s tape_wK/s swap_avail page_rstim freememK free_pages e1000g1Ipkt/s e1000g1Opkt/s e1000g1InKB/s e1000g1InDtSz/p e1000g1InOvH%/p e1000g1OuKB/s e1000g1OuDtSz/p e1000g1OuOvH%/p e1000g1IErr/s e1000g1OErr/s e1000g1Coll% e1000g1NoCP/s e1000g1Defr/s aggr1Ipkt/s aggr1Opkt/s aggr1InKB/s aggr1InDtSz/p aggr1InOvH%/p aggr1OuKB/s aggr1OuDtSz/p aggr1OuOvH%/p aggr1IErr/s aggr1OErr/s aggr1Coll% aggr1NoCP/s aggr1Defr/s tcp_Iseg/s tcp_Oseg/s tcp_InKB/s tcp_OuKB/s tcp_InDtSz/p tcp_InOvH%/p tcp_OuDtSz/p tcp_OuOvH%/p tcp_Ret% tcp_Dup% tcp_Icn/s tcp_Ocn/s tcp_estb tcp_Rst/s tcp_Atf/s tcp_Ldrp/s tcp_LdQ0/s tcp_HOdp/s udpNoPorts udpInOverflows udpInCksumErrs udpInDatagrams udpInErrors udpOutDatagrams nfs_call/s nfs_timo/s nfs_badx/s nfss_calls nfss_bad v2reads v2writes v3reads v3writes dnlc_ref/s dnlc_hit% inod_ref/s inod_hit% inod_stl/s ufsinopage/s pp_kernel pagesfree pageslock pagestotl From noreply at opencsw.org Fri Sep 3 23:43:20 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 3 Sep 2010 23:43:20 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-03 23:43 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008265) phil (manager) - 2010-09-03 23:43 https://www.opencsw.org/mantis/view.php?id=4538#c8265 ---------------------------------------------------------------------- Thanks for checking. I've done some more testing, and I have replicated it myself. Summary of behaviour: When creating a new zone, the "zoneadm install" command would seem to go through the package database in the global zone... NOT the filesystems... and copy every file that is both in the database, and not in a "inherit-pkg-dir" directory. Files in a filesystem, but not in the pkg database, do not get copied. The "alternatives" symlinks fit into this category. That being said... what to do about it? I could theoretically hack the "alternatives" scripts in nasty ways, to register the links with a fake package. or even the CSWalternatives package. But this does not seem clean to me. And then there remains the issue of: SHOULD I even attempt to fix this? It would validate a deployment method which in my opinion, will only lead to futhre trouble eventually. I think that if someone wants fully local package deployment to each zone, they should deploy packages locally. And if they want global installation of packages... they should use the inherit-pkg-dir functionality that is provided for that sort of thing! (specifically, for /opt/csw not /etc/opt/csw). It helps them a bunch also, avoiding needless redundant backups,etc. All zone-local configs should now be in /etc/opt/csw anyway, and any csw packages that dont follow this, should have a bug filed against them. What do you think, Geoff? From noreply at opencsw.org Sat Sep 4 00:13:51 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 00:13:51 +0200 Subject: [bug-notifications] [lftp 0004481]: Adding SOCKS5 proxy support into LFTP In-Reply-To: <0b6063ecfd4e24d73472d3490f8c1e0d> Message-ID: <8d778d34967ce10d021d0b14a2d21888@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4481 ====================================================================== Reported By: ckmehta1 Assigned To: yann ====================================================================== Project: lftp Issue ID: 4481 Category: regular use Reproducibility: always Severity: feature Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-06-30 07:04 CEST Last Modified: 2010-09-04 00:13 CEST ====================================================================== Summary: Adding SOCKS5 proxy support into LFTP Description: Please add SOCKS5 proxy support into OpenCSW version of LFTP. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0004536 undefined reference to upnpcleanup and ... ====================================================================== ---------------------------------------------------------------------- (0008266) yann (manager) - 2010-09-04 00:13 https://www.opencsw.org/mantis/view.php?id=4481#c8266 ---------------------------------------------------------------------- Package is now is current: http://www.opencsw.org/packages/CSWlftp/ I am closing this bug. From noreply at opencsw.org Sat Sep 4 00:54:28 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 00:54:28 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-04 00:54 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008267) gadavis (developer) - 2010-09-04 00:54 https://www.opencsw.org/mantis/view.php?id=4538#c8267 ---------------------------------------------------------------------- Well, here are my thoughts on it. Our systems have a baseline Solaris install of SUNW packages that we don't tweak on a per host basis, at least for those in the /usr tree. I think the jumpstart cluster used is SUNWcxall However, the individual zones vary significantly from one another in terms of their OpenCSW packages. Our development zones have compilers installed, automake, header files, etc - all stuff that doesn't really belong on a production system. Often, development and production Zones live on the same hosting physical system. Even among production systems, there's little reason for one of our data acquisition hosts to have Apache installed for example. In summary, the biggest difference between individual Zones in our environment is it's selection of CSW packages, not SUNW packages (Sun Studio being the only notable exception). Having a whole-root zone would result in a much larger duplication of packages. From noreply at opencsw.org Sat Sep 4 01:03:20 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 01:03:20 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-04 01:03 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008268) phil (manager) - 2010-09-04 01:03 https://www.opencsw.org/mantis/view.php?id=4538#c8268 ---------------------------------------------------------------------- Oh, I'm not saying individual root per zone at all!! I believe you can mix and match "sparse-ROOT", but zone-local /opt/csw. It is called sparse root, not "sparse packages" after all :) It kinda sounds like you're actually doing that already? Are you perhaps adding SOME csw packages at the global zone, but other packages at the individual zone level? From noreply at opencsw.org Sat Sep 4 01:09:07 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 01:09:07 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <97faef54a658d962da3acc4653cda3b4@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-04 01:09 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008269) gadavis (developer) - 2010-09-04 01:09 https://www.opencsw.org/mantis/view.php?id=4538#c8269 ---------------------------------------------------------------------- That is correct. We have a baseline of CSW packages installed in the global zone, things like sudo, cfengine, and their dependencies. We have been installing them without the -G option since all of our Zones need these common management tools as well. I guess we could start installing them with the -G option, but it will probably break the special case of CSWclassutils which has to have some of it's files in /usr somewhere. From noreply at opencsw.org Sat Sep 4 02:16:58 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 02:16:58 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <6efd0e15b4f70f36fb8cdfcbb9c01678@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-04 02:16 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008270) phil (manager) - 2010-09-04 02:16 https://www.opencsw.org/mantis/view.php?id=4538#c8270 ---------------------------------------------------------------------- Mmm, yeah CSWclassutils is unfortunately a special, somewhat ugly case. The good news is, that one doesnt have any postinstall scripts, etc. :) For everything else though, sounds like zone local is what you need, to ensure that everything works 100% as expected, when you create a new zone without cloning. OR.... you would do that special case re-running the alternatives script for new zones. sigh. Extra background: This could be "fixed" by installf getting called when symlinks are created... but installf requires a package to associate the symlinks with in the pkg database. which package would I use; itself, or the top level alternative being linked? Also, I'm trying to keep the "alternatives" script itself, portable. So I dont want to hardcode "CSWxxx" stuff in it. Hmm.. although I did have to hardcode /opt/csw in it anyway.... I MIGHT do that after all, I suppose. Another approach might be the other class-action wrappers, which in theory could be adjusted to register the symlinks when they call it, at pkgadd/rm time. Except that it would not be registered when 'alternatives' was called directly. From noreply at opencsw.org Sat Sep 4 03:02:41 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 03:02:41 +0200 Subject: [bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone In-Reply-To: <960a7844ae1b95d457c73e12363db4d1> Message-ID: <9148b967cc583652d0924a11e5602daf@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4538 ====================================================================== Reported By: gadavis Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4538 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-08-31 22:19 CEST Last Modified: 2010-09-04 03:02 CEST ====================================================================== Summary: Symbolic links not created in new sparse-root zone Description: There appears to be a bug in the alternatives mechanism when creating a new sparse-root zone on Solaris 10 systems. I have a global zone with CSW alternatives, CSWneon, CSWsudo, and CSWsudo-common installed. The alternatives mechanism has registered the symlinks in the right locations and alternatives --display neon and alternatives --display sudo work as expected. If I then create a new non-global zone with the default inherited paths (your typical sparse-root zone), alternatives --display whatever shows the correct paths listed, but the symlinks are not there. After zone creation, I have to manually force the alternatives mechanism to install the needed symlinks by running a shell loop: for d in `ls /opt/csw/share/alternatives`; do alt=`basename $d`; alternatives --auto $alt; done Note that if I uninstall CSWsudo inside the zone and then re-install it, the alternatives mechanism works as expected. It's only upon initial zone creation that the alternatives symlinks do not get created. ====================================================================== ---------------------------------------------------------------------- (0008271) phil (manager) - 2010-09-04 03:02 https://www.opencsw.org/mantis/view.php?id=4538#c8271 ---------------------------------------------------------------------- FYI: I updated http://wiki.opencsw.org/zone-behaviour with "complicated problem" sections, listed in the table of contents for easy reference. You might want to chew over those while contemplating your zone/pkg management strategy. I welcome feedback. From noreply at opencsw.org Sat Sep 4 22:17:45 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sat, 4 Sep 2010 22:17:45 +0200 Subject: [bug-notifications] [perl 0004544]: perl is missing DB_File.pm Message-ID: <7ed8187eaf4f7d3872674fc054690e3c@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4544 ====================================================================== Reported By: arw Assigned To: ====================================================================== Project: perl Issue ID: 4544 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-04 22:17 CEST Last Modified: 2010-09-04 22:17 CEST ====================================================================== Summary: perl is missing DB_File.pm Description: current perl package is missing DB_File.pm which breaks e.g. spamassassin Bayes-filtering. See error output in 'Additional Information'. Earlier versions of the perl 5.10.1 still included DB_File: Compare http://webcache.googleusercontent.com/search?q=cache:s-uSuGiWrqAJ:www.opencsw.org/search/perl/+DB_File.pm+opencsw&cd=2&hl=de&ct=clnk to current file list. ====================================================================== From noreply at opencsw.org Mon Sep 6 11:22:21 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 6 Sep 2010 11:22:21 +0200 Subject: [bug-notifications] [perl 0004544]: perl is missing DB_File.pm In-Reply-To: <72c7a47afe735db2b8d109e5a6e129d4> Message-ID: <910c29fb45ace0cd6461198934fcc3c1@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4544 ====================================================================== Reported By: arw Assigned To: bonivart ====================================================================== Project: perl Issue ID: 4544 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-04 22:17 CEST Last Modified: 2010-09-06 11:22 CEST ====================================================================== Summary: perl is missing DB_File.pm Description: current perl package is missing DB_File.pm which breaks e.g. spamassassin Bayes-filtering. See error output in 'Additional Information'. Earlier versions of the perl 5.10.1 still included DB_File: Compare http://webcache.googleusercontent.com/search?q=cache:s-uSuGiWrqAJ:www.opencsw.org/search/perl/+DB_File.pm+opencsw&cd=2&hl=de&ct=clnk to current file list. ====================================================================== From noreply at opencsw.org Mon Sep 6 12:04:37 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 6 Sep 2010 12:04:37 +0200 Subject: [bug-notifications] [ldns 0004545]: Please update to 1.6.6 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4545 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: ldns Issue ID: 4545 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-06 12:04 CEST Last Modified: 2010-09-06 12:04 CEST ====================================================================== Summary: Please update to 1.6.6 Description: Please update to 1.6.6 ====================================================================== From noreply at opencsw.org Mon Sep 6 14:26:46 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 6 Sep 2010 14:26:46 +0200 Subject: [bug-notifications] [perl 0004544]: perl is missing DB_File.pm In-Reply-To: <72c7a47afe735db2b8d109e5a6e129d4> Message-ID: The following issue requires your FEEDBACK. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4544 ====================================================================== Reported By: arw Assigned To: bonivart ====================================================================== Project: perl Issue ID: 4544 Category: regular use Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-04 22:17 CEST Last Modified: 2010-09-06 14:26 CEST ====================================================================== Summary: perl is missing DB_File.pm Description: current perl package is missing DB_File.pm which breaks e.g. spamassassin Bayes-filtering. See error output in 'Additional Information'. Earlier versions of the perl 5.10.1 still included DB_File: Compare http://webcache.googleusercontent.com/search?q=cache:s-uSuGiWrqAJ:www.opencsw.org/search/perl/+DB_File.pm+opencsw&cd=2&hl=de&ct=clnk to current file list. ====================================================================== ---------------------------------------------------------------------- (0008272) bonivart (manager) - 2010-09-06 14:26 https://www.opencsw.org/mantis/view.php?id=4544#c8272 ---------------------------------------------------------------------- That's weird, I'm using the latest Perl with SpamAssassin myself with no issues (I get Bayes scoring). We don't do anything special so if DB_File.pm shouldn't be included in core Perl I think we're better off making a separate package for it. Thoughts? From noreply at opencsw.org Mon Sep 6 17:43:38 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 6 Sep 2010 17:43:38 +0200 Subject: [bug-notifications] [pkgutil 0004530]: RFE: Point out package download location when downloading In-Reply-To: <7f9248ee6e59a5541d0d9c1738a7ad9c> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4530 ====================================================================== Reported By: skayser Assigned To: bonivart ====================================================================== Project: pkgutil Issue ID: 4530 Category: other Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-08-26 13:07 CEST Last Modified: 2010-09-06 17:43 CEST ====================================================================== Summary: RFE: Point out package download location when downloading Description: When downloading a package (-d) there's no indication to the user where the package might have ended up at. root @ ray42 ~# pkgutil -Nd -T sparc:5.10 nagios_plugins Package list: CSWnagiosp-1.4.13,REV=2009.04.26 Total size: 1.6 MB => Fetching CSWnagiosp-1.4.13,REV=2009.04.26 (1/1) ... root @ ray42 ~# Compare this with the --stream download option where there's an indication to the user where he can find the generated stream. Transforming CSWsasl ... Transforming CSWoldaprt ... Transforming CSWlibpq ... Transforming CSWnagiosp ... Transforming packages into stream (/var/opt/csw/pkgutil/packages/nagios_plugins.sparc.5.10.pkg) ... Would be helpful to output the download directory on normal downloads also. Maybe add an extra line with the download directory? root @ ray42 ~# pkgutil -Nd -T sparc:5.10 nagios_plugins Package list: CSWnagiosp-1.4.13,REV=2009.04.26 Total size: 1.6 MB => Downloading packages to /var/opt/csw/pkgutil/packages => Fetching CSWnagiosp-1.4.13,REV=2009.04.26 (1/1) ... ====================================================================== ---------------------------------------------------------------------- (0008273) bonivart (manager) - 2010-09-06 17:43 https://www.opencsw.org/mantis/view.php?id=4530#c8273 ---------------------------------------------------------------------- As agreed on IRC (Dago, Sebastian and me) I have implemented Sebastians suggestion: # pkgutil -Nd memconf Package list: CSWmemconf-2.16,REV=2010.08.09 Total size: 69.2 KB A local copy of CSWmemconf-2.16,REV=2010.08.09 exists and is of matching size. Packages downloaded to /var/opt/csw/pkgutil/packages: memconf-2.16,REV=2010.08.09-SunOS5.9-all-CSW.pkg.gz (OK) Checked in as r291. From noreply at opencsw.org Mon Sep 6 17:45:35 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 6 Sep 2010 17:45:35 +0200 Subject: [bug-notifications] [perl 0004103]: Sun Studio Compiler PATH in Config.pm/Config_heavy.pl and config.h In-Reply-To: Message-ID: <5e2610f97613dbacf0a5ed33099dafdb@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4103 ====================================================================== Reported By: rrossi33 Assigned To: bonivart ====================================================================== Project: perl Issue ID: 4103 Category: other Reproducibility: always Severity: tweak Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2009-12-29 10:41 CET Last Modified: 2010-09-06 17:45 CEST ====================================================================== Summary: Sun Studio Compiler PATH in Config.pm/Config_heavy.pl and config.h Description: Wrong hard coded cc path in Config.pm/ Config_heavy.pl and config.h cc => ?/opt/studio/SOS11/SUNWspro/bin/cc', on Machine: /opt/SUNWspro/bin/cc Result: /opt/csw/bin/perl -MCPAN -e shell CPAN Module Compiling - Entry in Makefile.pl: /opt/studio/SOS11/SUNWspro/bin/cc error in compiling ====================================================================== ---------------------------------------------------------------------- (0008274) bonivart (manager) - 2010-09-06 17:45 https://www.opencsw.org/mantis/view.php?id=4103#c8274 ---------------------------------------------------------------------- New package released. From noreply at opencsw.org Mon Sep 6 17:46:14 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 6 Sep 2010 17:46:14 +0200 Subject: [bug-notifications] [perl 0004253]: Compile Perl against BDB 4.8 In-Reply-To: <2864cd98c0b43a82f6df05827ccfc9f7> Message-ID: <3179894920f8c2bcd3b6bd19687c9ce6@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4253 ====================================================================== Reported By: dam Assigned To: bonivart ====================================================================== Project: perl Issue ID: 4253 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-02-03 12:56 CET Last Modified: 2010-09-06 17:46 CEST ====================================================================== Summary: Compile Perl against BDB 4.8 Description: Compile Perl against BDB 4.8 which may be useful ====================================================================== ---------------------------------------------------------------------- (0008275) bonivart (manager) - 2010-09-06 17:46 https://www.opencsw.org/mantis/view.php?id=4253#c8275 ---------------------------------------------------------------------- New package released. From noreply at opencsw.org Tue Sep 7 00:34:23 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 7 Sep 2010 00:34:23 +0200 Subject: [bug-notifications] [perl 0004544]: perl is missing DB_File.pm In-Reply-To: <72c7a47afe735db2b8d109e5a6e129d4> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4544 ====================================================================== Reported By: arw Assigned To: bonivart ====================================================================== Project: perl Issue ID: 4544 Category: regular use Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-04 22:17 CEST Last Modified: 2010-09-07 00:34 CEST ====================================================================== Summary: perl is missing DB_File.pm Description: current perl package is missing DB_File.pm which breaks e.g. spamassassin Bayes-filtering. See error output in 'Additional Information'. Earlier versions of the perl 5.10.1 still included DB_File: Compare http://webcache.googleusercontent.com/search?q=cache:s-uSuGiWrqAJ:www.opencsw.org/search/perl/+DB_File.pm+opencsw&cd=2&hl=de&ct=clnk to current file list. ====================================================================== ---------------------------------------------------------------------- (0008276) arw (reporter) - 2010-09-07 00:34 https://www.opencsw.org/mantis/view.php?id=4544#c8276 ---------------------------------------------------------------------- The Bayes-DB in Spamassassin seems to be storable in a number of formats. So maybe your configuration just doesn't depend on DB_File.pm. A separate package would be possible i guess, but CPAN says that DB_File.pm should be included in the standard distribution of perl (http://search.cpan.org/~pmqs/DB_File-1.820/DB_File.pm). Did any config/compile-flags change between the last two perl packages? From noreply at opencsw.org Tue Sep 7 09:28:45 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 7 Sep 2010 09:28:45 +0200 Subject: [bug-notifications] [perl 0004544]: perl is missing DB_File.pm In-Reply-To: <72c7a47afe735db2b8d109e5a6e129d4> Message-ID: <8a882c2fb93e1b09b7d04e3234b50b6a@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4544 ====================================================================== Reported By: arw Assigned To: bonivart ====================================================================== Project: perl Issue ID: 4544 Category: regular use Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-04 22:17 CEST Last Modified: 2010-09-07 09:28 CEST ====================================================================== Summary: perl is missing DB_File.pm Description: current perl package is missing DB_File.pm which breaks e.g. spamassassin Bayes-filtering. See error output in 'Additional Information'. Earlier versions of the perl 5.10.1 still included DB_File: Compare http://webcache.googleusercontent.com/search?q=cache:s-uSuGiWrqAJ:www.opencsw.org/search/perl/+DB_File.pm+opencsw&cd=2&hl=de&ct=clnk to current file list. ====================================================================== ---------------------------------------------------------------------- (0008277) bonivart (manager) - 2010-09-07 09:28 https://www.opencsw.org/mantis/view.php?id=4544#c8277 ---------------------------------------------------------------------- It's weird since the only thing we have changed since the first 5.10.1 package is compiler locations and depending on bdb48 instead of bdb47. If this is a problem for you you can get the old packages from http://csw.informatik.uni-erlangen.de/oldpkgs until we figure this out. From noreply at opencsw.org Wed Sep 8 16:59:35 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 8 Sep 2010 16:59:35 +0200 Subject: [bug-notifications] [orca_web 0004546]: network interface with greater than 1 Gbit of bandwidth does plot correctly Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4546 ====================================================================== Reported By: GlenG Assigned To: ====================================================================== Project: orca_web Issue ID: 4546 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-08 16:59 CEST Last Modified: 2010-09-08 16:59 CEST ====================================================================== Summary: network interface with greater than 1 Gbit of bandwidth does plot correctly Description: (This is a copy of my post to 'orca-users at orcaware.com') I'm trying to add a plot for a network interface with greater than 1 Gbit of bandwidth. I'm getting a plot but the y axis tops out at 1000Mb/s and when the interface is receiving > 1000Mb/s that variable is not plotted (the text portion Max. does not report the larger values either). Here's my plot configuration. I copied a working 1Gbit plot and changed data_max from 1000000000 to 2000000000. Also, tried deleting data_max. # Interface bits per second for > 1 Gbit interfaces. plot { title %g Interface Bits Per Second: $1 source orcallator data 1024 * 8 * ((?:(?:aggr))\d+)InKB/s data 1024 * 8 * $1OuKB/s line_type area line_type line1 legend Input legend Output y_legend Bits/s data_min 0 data_max 2000000000 plot_width 800 href http://www.orcaware.com/orca/docs/orcallator.html#interface_bits_per_second } ====================================================================== From noreply at opencsw.org Wed Sep 8 17:03:52 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 8 Sep 2010 17:03:52 +0200 Subject: [bug-notifications] [orca_web 0004546]: network interface with greater than 1 Gbit of bandwidth does plot correctly In-Reply-To: Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4546 ====================================================================== Reported By: GlenG Assigned To: ====================================================================== Project: orca_web Issue ID: 4546 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-08 16:59 CEST Last Modified: 2010-09-08 17:03 CEST ====================================================================== Summary: network interface with greater than 1 Gbit of bandwidth does plot correctly Description: (This is a copy of my post to 'orca-users at orcaware.com') I'm trying to add a plot for a network interface with greater than 1 Gbit of bandwidth. I'm getting a plot but the y axis tops out at 1000Mb/s and when the interface is receiving > 1000Mb/s that variable is not plotted (the text portion Max. does not report the larger values either). Here's my plot configuration. I copied a working 1Gbit plot and changed data_max from 1000000000 to 2000000000. Also, tried deleting data_max. # Interface bits per second for > 1 Gbit interfaces. plot { title %g Interface Bits Per Second: $1 source orcallator data 1024 * 8 * ((?:(?:aggr))\d+)InKB/s data 1024 * 8 * $1OuKB/s line_type area line_type line1 legend Input legend Output y_legend Bits/s data_min 0 data_max 2000000000 plot_width 800 href http://www.orcaware.com/orca/docs/orcallator.html#interface_bits_per_second } ====================================================================== ---------------------------------------------------------------------- (0008278) GlenG (reporter) - 2010-09-08 17:03 https://www.opencsw.org/mantis/view.php?id=4546#c8278 ---------------------------------------------------------------------- The png file is not from plotting the attached orcallator file. From noreply at opencsw.org Wed Sep 8 17:20:04 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 8 Sep 2010 17:20:04 +0200 Subject: [bug-notifications] [setoolkit 0004539]: SEToolkit is not collecting stats on network aggregations In-Reply-To: Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4539 ====================================================================== Reported By: GlenG Assigned To: dam ====================================================================== Project: setoolkit Issue ID: 4539 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-01 16:15 CEST Last Modified: 2010-09-08 17:20 CEST ====================================================================== Summary: SEToolkit is not collecting stats on network aggregations Description: According to http://freshmeat.net/projects/setoolkit the following changes were made at 3.5.0 on 05 Aug 2008: Changes: The transfer rate of fjgi doesn't overflow anymore. Missing instance definitions in several kstat structures have been added. New kstat structures for e1000g, ipge, aggr, fjge,... and bnx network interfaces have been added. The network interfaces bge and dmfe now use :kstat-style notation. kstat(1M)-style specification of kstat members can now be used. The current includes files from Orca have been pulled in. Extended regular expressions can be used now. This release has switched to autoconf/automake/libtool. The orcallator has been updated to r535 but the OpenCSW package does not collect aggr stats. ====================================================================== ---------------------------------------------------------------------- (0008279) GlenG (reporter) - 2010-09-08 17:20 https://www.opencsw.org/mantis/view.php?id=4539#c8279 ---------------------------------------------------------------------- I opened https://www.opencsw.org/mantis/view.php?id=4546 to pursue the plotting problem. If you would like more information to confirm collection is working as expected there is a sample collection file attached to report 4546. If you need more details let me know. From noreply at opencsw.org Thu Sep 9 11:07:01 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 9 Sep 2010 11:07:01 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-09 11:06 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== From noreply at opencsw.org Thu Sep 9 11:16:01 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 9 Sep 2010 11:16:01 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: <1bb4dd6f2c7183ba9d4b13485cc485b7@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-09 11:15 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008280) ssinyagin (reporter) - 2010-09-09 11:15 https://www.opencsw.org/mantis/view.php?id=4547#c8280 ---------------------------------------------------------------------- I installed Studio 12 on my test server (SolarisStudio12.2-solaris-sparc-pkg-ML.tar.bz2), and actually Studio 12 does not install by default into /opt/SUNWspro any more. From noreply at opencsw.org Thu Sep 9 22:01:46 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 9 Sep 2010 22:01:46 +0200 Subject: [bug-notifications] [wireshark 0004548]: Please Update Wireshark to latest stable release (currently 1.4.0) from Wireshark.org Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4548 ====================================================================== Reported By: alfyj Assigned To: ====================================================================== Project: wireshark Issue ID: 4548 Category: upgrade Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-09 22:01 CEST Last Modified: 2010-09-09 22:01 CEST ====================================================================== Summary: Please Update Wireshark to latest stable release (currently 1.4.0) from Wireshark.org Description: Current release 1.2.3 is at least 18 months old as a Solaris package, and probably additional months behind the Windows & OSX versions available at wireshark.org. My users are asking me to upgrade our server, which has monitor feeds from multiple routers in our lab. ====================================================================== From noreply at opencsw.org Fri Sep 10 13:33:34 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 10 Sep 2010 13:33:34 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: <5c92fffa3bcae954818494538cdface1@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-10 13:33 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008281) dam (administrator) - 2010-09-10 13:33 https://www.opencsw.org/mantis/view.php?id=4547#c8281 ---------------------------------------------------------------------- Sun Studio 12.2 is not Sun Studio 12. The versions 12, 12u1 and 12.2 are completely different compilers which should better have been named 12, 13 and 14. I expect they have just renamed 13 to 12u1 for the same reason there is no 13th floor in some hotels. Please download Sun Studio 12 from http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ss12-136026.html To easily distribute Sun Studio 12 as a single package I made a script that bundles up the complete installation and makes one large package out of it: http://sourceforge.net/apps/trac/gar/browser/csw/manual-recipes/sspkg You cannot make decent work with the tar-packaged compilers anyway because you cannot apply necessary patches to the distribution. From noreply at opencsw.org Fri Sep 10 13:34:15 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 10 Sep 2010 13:34:15 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: dam ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-10 13:34 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008281) dam (administrator) - 2010-09-10 13:33 https://www.opencsw.org/mantis/view.php?id=4547#c8281 ---------------------------------------------------------------------- Sun Studio 12.2 is not Sun Studio 12. The versions 12, 12u1 and 12.2 are completely different compilers which should better have been named 12, 13 and 14. I expect they have just renamed 13 to 12u1 for the same reason there is no 13th floor in some hotels. Please download Sun Studio 12 from http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ss12-136026.html To easily distribute Sun Studio 12 as a single package I made a script that bundles up the complete installation and makes one large package out of it: http://sourceforge.net/apps/trac/gar/browser/csw/manual-recipes/sspkg You cannot make decent work with the tar-packaged compilers anyway because you cannot apply necessary patches to the distribution. From noreply at opencsw.org Fri Sep 10 13:34:29 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 10 Sep 2010 13:34:29 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: The following issue requires your FEEDBACK. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: dam ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-10 13:34 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008281) dam (administrator) - 2010-09-10 13:33 https://www.opencsw.org/mantis/view.php?id=4547#c8281 ---------------------------------------------------------------------- Sun Studio 12.2 is not Sun Studio 12. The versions 12, 12u1 and 12.2 are completely different compilers which should better have been named 12, 13 and 14. I expect they have just renamed 13 to 12u1 for the same reason there is no 13th floor in some hotels. Please download Sun Studio 12 from http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ss12-136026.html To easily distribute Sun Studio 12 as a single package I made a script that bundles up the complete installation and makes one large package out of it: http://sourceforge.net/apps/trac/gar/browser/csw/manual-recipes/sspkg You cannot make decent work with the tar-packaged compilers anyway because you cannot apply necessary patches to the distribution. From noreply at opencsw.org Fri Sep 10 14:35:16 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 10 Sep 2010 14:35:16 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: <066472bb38d4d98aaf1e2226334e7bda@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: dam ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-10 14:35 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008282) ssinyagin (reporter) - 2010-09-10 14:35 https://www.opencsw.org/mantis/view.php?id=4547#c8282 ---------------------------------------------------------------------- probably it makes sense to put a document somewhere like /opt/csw/doc/perl/ or in the Wiki? or maybe switching to GCC would be much easier for everyone... From noreply at opencsw.org Fri Sep 10 15:21:15 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 10 Sep 2010 15:21:15 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: dam ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-10 15:21 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008283) dam (administrator) - 2010-09-10 15:21 https://www.opencsw.org/mantis/view.php?id=4547#c8283 ---------------------------------------------------------------------- Feel free to suggest a writeup :-) Regarding switching to gcc: This has several drawbacks, like a dependency to libgcc or making it impossible to link to c++ libraries due to different mangling of symbols. That is why gcc is avoided in OpenCSW packages whenever possible. From noreply at opencsw.org Fri Sep 10 15:36:56 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 10 Sep 2010 15:36:56 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: dam ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-10 15:36 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008284) ssinyagin (reporter) - 2010-09-10 15:36 https://www.opencsw.org/mantis/view.php?id=4547#c8284 ---------------------------------------------------------------------- actually the best will be to give clear instructions at http://www.opencsw.org/use-it/ Here I wrote some notes, but haven't updated them for a while: http://sourceforge.net/apps/mediawiki/torrus/index.php?title=Sun_Solaris_Install_Log I think we need to state clearly that Studio 12, packaged version is needed. And warn about 12.2. I'll do the installation steps and provide you with the text next week. From noreply at opencsw.org Mon Sep 13 10:55:08 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 13 Sep 2010 10:55:08 +0200 Subject: [bug-notifications] [rssh 0004549]: Runtime depends on CSWossh which isn't really required Message-ID: <494888bb85e0eab487d3916286185516@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4549 ====================================================================== Reported By: nicols Assigned To: ====================================================================== Project: rssh Issue ID: 4549 Category: packaging Reproducibility: N/A Severity: tweak Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-13 10:55 CEST Last Modified: 2010-09-13 10:55 CEST ====================================================================== Summary: Runtime depends on CSWossh which isn't really required Description: CSWossh shouldn't be runtime required for rssh We use Sun's SSH Daemon, but want rssh for rsync - thus we don't need rssh to link again CSWossh. Obviously, CSWossh still needs to be a build depend though ====================================================================== From noreply at opencsw.org Mon Sep 13 12:01:58 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 13 Sep 2010 12:01:58 +0200 Subject: [bug-notifications] [perl 0004547]: CSWperl 5.10.1, REV=2010.08.11 incompatible with Sun Studio 11 In-Reply-To: <5803f2ae002e026a7bceda46a356bf96> Message-ID: <831ce5aa04530818510907263785422a@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4547 ====================================================================== Reported By: ssinyagin Assigned To: dam ====================================================================== Project: perl Issue ID: 4547 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-09 11:06 CEST Last Modified: 2010-09-13 12:01 CEST ====================================================================== Summary: CSWperl 5.10.1,REV=2010.08.11 incompatible with Sun Studio 11 Description: Sun Studio 11 is the last Studio release that is tar archive with solaris packages. Studio 12 is a huge bourne shell archive, making it tricky to install on remote systems. In Studio 11, I could simply extract the 3 packages and skip the rest of a half-gig distribution. A simple program: #include int main() {} now it fails when compiling by /opt/SUNWspro/bin/cc -I/opt/csw/lib/perl/5.10.1/CORE xx.c The compiler reports syntax errors and undefined __attribute__ in /opt/csw/lib/perl/5.10.1/CORE/perl.h Also perl -V reports incompatible C flag (-m32). It will be great to still be able to use Studio 11 with CSWperl. ====================================================================== ---------------------------------------------------------------------- (0008285) ssinyagin (reporter) - 2010-09-13 12:01 https://www.opencsw.org/mantis/view.php?id=4547#c8285 ---------------------------------------------------------------------- Here's my writeup: 1. Download Sun Studio 12 (not 12.1 or 12.2) Package Installer from http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ss12-136026.html 2. run the following: mkdir SunStudio12ml cd SunStudio12ml bunzip2 -dc ../SunStudio12ml-solaris-sparc-200709-pkg.tar.bz2 | tar xvf - cd install-sparc-S2/packages-sparc-S2 pkgadd -d . SPROdwrfb SPROlang SPROcc 3. Alternatively, you can run tar cvf ~/studio12_SPROdwrfb_SPROlang_SPROcc.tar SPROdwrfb SPROlang SPROcc and copy the TAR archive to your Sun server, then install the packages From noreply at opencsw.org Mon Sep 13 21:00:18 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 13 Sep 2010 21:00:18 +0200 Subject: [bug-notifications] [orca_web 0004546]: network interface with greater than 1 Gbit of bandwidth does plot correctly In-Reply-To: Message-ID: <38b4ee72f9da752d7eb4b48b86efecab@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4546 ====================================================================== Reported By: GlenG Assigned To: ====================================================================== Project: orca_web Issue ID: 4546 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-08 16:59 CEST Last Modified: 2010-09-13 21:00 CEST ====================================================================== Summary: network interface with greater than 1 Gbit of bandwidth does plot correctly Description: (This is a copy of my post to 'orca-users at orcaware.com') I'm trying to add a plot for a network interface with greater than 1 Gbit of bandwidth. I'm getting a plot but the y axis tops out at 1000Mb/s and when the interface is receiving > 1000Mb/s that variable is not plotted (the text portion Max. does not report the larger values either). Here's my plot configuration. I copied a working 1Gbit plot and changed data_max from 1000000000 to 2000000000. Also, tried deleting data_max. # Interface bits per second for > 1 Gbit interfaces. plot { title %g Interface Bits Per Second: $1 source orcallator data 1024 * 8 * ((?:(?:aggr))\d+)InKB/s data 1024 * 8 * $1OuKB/s line_type area line_type line1 legend Input legend Output y_legend Bits/s data_min 0 data_max 2000000000 plot_width 800 href http://www.orcaware.com/orca/docs/orcallator.html#interface_bits_per_second } ====================================================================== ---------------------------------------------------------------------- (0008286) GlenG (reporter) - 2010-09-13 21:00 https://www.opencsw.org/mantis/view.php?id=4546#c8286 ---------------------------------------------------------------------- I got the plot to work by: 1. removing data_max from orcallator.cfg # Interface bits per second for > 1 Gbit interfaces. # data_max 2000000000 plot { title %g Interface Bits Per Second: $1 source orcallator data 1024 * 8 * ((?:(?:aggr))\d+)InKB/s data 1024 * 8 * $1OuKB/s line_type area line_type line1 legend Input legend Output y_legend Bits/s data_min 0 plot_width 800 href http://www.orcaware.com/orca/docs/orcallator.html#interface_bits_per_second } 2. killing Orca master: pkill orca 3. deleting rrd files: ls -ltrh /var/opt/csw/orca/rrd/orcallator/o_beaker | grep aggr -rw-r--r-- 1 root root 49K Sep 2 14:43 gauge_1024_X_18_X_aggr1OuKB_per_s.rrd -rw-r--r-- 1 root root 49K Sep 2 14:43 gauge_1024_X_18_X_aggr1InKB_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:23 gauge_1024_X_8_X_aggr1InKB_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:23 gauge_1024_X_8_X_aggr1OuKB_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1Coll_pct.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1Defr_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1IErr_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1InDtSz_per_p.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1InOvH_pct_per_p.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1Ipkt_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1NoCP_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1OErr_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1Opkt_per_s.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1OuDtSz_per_p.rrd -rw-r--r-- 1 root root 49K Sep 13 11:50 gauge_aggr1OuOvH_pct_per_p.rrd cd /var/opt/csw/orca/rrd/orcallator/o_beaker rm gauge_1024_X_18_X_aggr1OuKB_per_s.rrd gauge_1024_X_18_X_aggr1InKB_per_s.rrd gauge_1024_X_8_X_aggr1InKB_per_s.rrd gauge_1024_X_8_X_aggr1OuKB_per_s.rrd 4. restarting master /opt/csw/bin/orca -d /opt/csw/etc/orcallator.cfg I attached an "after" plot file. If I should have done something else please let me know. From noreply at opencsw.org Mon Sep 13 22:23:57 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 13 Sep 2010 22:23:57 +0200 Subject: [bug-notifications] [rssh 0004549]: Runtime depends on CSWossh which isn't really required In-Reply-To: Message-ID: <9a99277c689aa41be469f80abd383d07@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4549 ====================================================================== Reported By: nicols Assigned To: dam ====================================================================== Project: rssh Issue ID: 4549 Category: packaging Reproducibility: N/A Severity: tweak Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-13 10:55 CEST Last Modified: 2010-09-13 22:23 CEST ====================================================================== Summary: Runtime depends on CSWossh which isn't really required Description: CSWossh shouldn't be runtime required for rssh We use Sun's SSH Daemon, but want rssh for rsync - thus we don't need rssh to link again CSWossh. Obviously, CSWossh still needs to be a build depend though ====================================================================== From noreply at opencsw.org Mon Sep 13 22:25:46 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 13 Sep 2010 22:25:46 +0200 Subject: [bug-notifications] [rssh 0004549]: Runtime depends on CSWossh which isn't really required In-Reply-To: Message-ID: The following issue requires your FEEDBACK. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4549 ====================================================================== Reported By: nicols Assigned To: dam ====================================================================== Project: rssh Issue ID: 4549 Category: packaging Reproducibility: N/A Severity: tweak Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-13 10:55 CEST Last Modified: 2010-09-13 22:25 CEST ====================================================================== Summary: Runtime depends on CSWossh which isn't really required Description: CSWossh shouldn't be runtime required for rssh We use Sun's SSH Daemon, but want rssh for rsync - thus we don't need rssh to link again CSWossh. Obviously, CSWossh still needs to be a build depend though ====================================================================== ---------------------------------------------------------------------- (0008287) dam (administrator) - 2010-09-13 22:25 https://www.opencsw.org/mantis/view.php?id=4549#c8287 ---------------------------------------------------------------------- But I configure rssh with CONFIGURE_ARGS += --with-scp=$(bindir)/scp CONFIGURE_ARGS += --with-sftp-server=$(libexecdir)/sftp-server so essentially the defaults are OpenSSH from CSW, right? From noreply at opencsw.org Tue Sep 14 10:14:26 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 14 Sep 2010 10:14:26 +0200 Subject: [bug-notifications] [rssh 0004549]: Runtime depends on CSWossh which isn't really required In-Reply-To: Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4549 ====================================================================== Reported By: nicols Assigned To: dam ====================================================================== Project: rssh Issue ID: 4549 Category: packaging Reproducibility: N/A Severity: tweak Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-13 10:55 CEST Last Modified: 2010-09-14 10:14 CEST ====================================================================== Summary: Runtime depends on CSWossh which isn't really required Description: CSWossh shouldn't be runtime required for rssh We use Sun's SSH Daemon, but want rssh for rsync - thus we don't need rssh to link again CSWossh. Obviously, CSWossh still needs to be a build depend though ====================================================================== ---------------------------------------------------------------------- (0008288) nicols (developer) - 2010-09-14 10:14 https://www.opencsw.org/mantis/view.php?id=4549#c8288 ---------------------------------------------------------------------- Yup, the configure options are correct - but the following is specified in the Makefile: --- # We need at least OpenSSH, the other programs are optional RUNTIME_DEP_PKGS = CSWossh --- When actually, you don't need OpenSSH from CSW to run rssh if, for example, you're only running rssh with rsync. From noreply at opencsw.org Thu Sep 16 18:16:25 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 16 Sep 2010 18:16:25 +0200 Subject: [bug-notifications] [curl_devel 0004550]: curl-config emits 'xarch' value for --libs and --static-libs Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4550 ====================================================================== Reported By: jensd Assigned To: ====================================================================== Project: curl_devel Issue ID: 4550 Category: other Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-16 18:16 CEST Last Modified: 2010-09-16 18:16 CEST ====================================================================== Summary: curl-config emits 'xarch' value for --libs and --static-libs Description: I'm using the curl libs to build a ruby extension (curb). At some point the link call fails with: /opt/studio/SOS11/SUNWspro/bin/cc -I. -I. -I/opt/csw/lib/ruby/1.8/sparc-solaris2.8 -I. -DRUBY_EXTCONF_H=\"curb_config.h\" -I/opt/csw/include -D_FILE_OFFSET_BITS=64 -I/opt/csw/include -KPIC -xO3 -xarch=v8 -I/opt/csw/include -KPIC -I/opt/csw/include -g -c curb_multi.c ld -G -o curb_core.so curb.o curb_postfield.o curb_upload.o curb_errors.o curb_easy.o curb_multi.o -L. -L/opt/csw/lib -R/opt/csw/lib -L. -L/opt/csw/lib -R /opt/csw/lib -L/opt/csw/lib -lruby -lpthread -lrt -ldl -lcrypt -lm -lc -L/opt/csw/lib -lcurl -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -lcares -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz ld: illegal option -- x usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) The failure is because the linker is using the option -xarch=v8 and this is as a result of using 'curl-config --libs': jensd at current8s:ext$> curl-config --libs -L/opt/csw/lib -lcurl -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -lcares -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz I don't think curl-config should be emitting '-xarch=v8' here. ====================================================================== From noreply at opencsw.org Fri Sep 17 15:55:26 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 17 Sep 2010 15:55:26 +0200 Subject: [bug-notifications] [subversion 0004420]: Linked against old neon library (0.26) In-Reply-To: Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4420 ====================================================================== Reported By: alexs77 Assigned To: dam ====================================================================== Project: subversion Issue ID: 4420 Category: regular use Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-05-17 12:55 CEST Last Modified: 2010-09-17 15:55 CEST ====================================================================== Summary: Linked against old neon library (0.26) Description: When I try to execute svn, it fails, because it's linked against neon 0.26, but on the repository, there's already 0.29. ====================================================================== ---------------------------------------------------------------------- (0008289) dam (administrator) - 2010-09-17 15:55 https://www.opencsw.org/mantis/view.php?id=4420#c8289 ---------------------------------------------------------------------- The issue on CSWalternatives has been fixed in 1.0,REV=2010.05.21. From noreply at opencsw.org Fri Sep 17 23:02:13 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 17 Sep 2010 23:02:13 +0200 Subject: [bug-notifications] [curl_devel 0004550]: curl-config emits 'xarch' value for --libs and --static-libs In-Reply-To: <4f32526e93e16d42af1775400537269d> Message-ID: <309e00dee29b408ad6d91b4bf1e28fc5@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4550 ====================================================================== Reported By: jensd Assigned To: dam ====================================================================== Project: curl_devel Issue ID: 4550 Category: other Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-16 18:16 CEST Last Modified: 2010-09-17 23:02 CEST ====================================================================== Summary: curl-config emits 'xarch' value for --libs and --static-libs Description: I'm using the curl libs to build a ruby extension (curb). At some point the link call fails with: /opt/studio/SOS11/SUNWspro/bin/cc -I. -I. -I/opt/csw/lib/ruby/1.8/sparc-solaris2.8 -I. -DRUBY_EXTCONF_H=\"curb_config.h\" -I/opt/csw/include -D_FILE_OFFSET_BITS=64 -I/opt/csw/include -KPIC -xO3 -xarch=v8 -I/opt/csw/include -KPIC -I/opt/csw/include -g -c curb_multi.c ld -G -o curb_core.so curb.o curb_postfield.o curb_upload.o curb_errors.o curb_easy.o curb_multi.o -L. -L/opt/csw/lib -R/opt/csw/lib -L. -L/opt/csw/lib -R /opt/csw/lib -L/opt/csw/lib -lruby -lpthread -lrt -ldl -lcrypt -lm -lc -L/opt/csw/lib -lcurl -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -lcares -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz ld: illegal option -- x usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) The failure is because the linker is using the option -xarch=v8 and this is as a result of using 'curl-config --libs': jensd at current8s:ext$> curl-config --libs -L/opt/csw/lib -lcurl -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -lcares -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz I don't think curl-config should be emitting '-xarch=v8' here. ====================================================================== From noreply at opencsw.org Fri Sep 17 23:12:50 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 17 Sep 2010 23:12:50 +0200 Subject: [bug-notifications] [curl_devel 0004550]: curl-config emits 'xarch' value for --libs and --static-libs In-Reply-To: <4f32526e93e16d42af1775400537269d> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4550 ====================================================================== Reported By: jensd Assigned To: dam ====================================================================== Project: curl_devel Issue ID: 4550 Category: other Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-16 18:16 CEST Last Modified: 2010-09-17 23:12 CEST ====================================================================== Summary: curl-config emits 'xarch' value for --libs and --static-libs Description: I'm using the curl libs to build a ruby extension (curb). At some point the link call fails with: /opt/studio/SOS11/SUNWspro/bin/cc -I. -I. -I/opt/csw/lib/ruby/1.8/sparc-solaris2.8 -I. -DRUBY_EXTCONF_H=\"curb_config.h\" -I/opt/csw/include -D_FILE_OFFSET_BITS=64 -I/opt/csw/include -KPIC -xO3 -xarch=v8 -I/opt/csw/include -KPIC -I/opt/csw/include -g -c curb_multi.c ld -G -o curb_core.so curb.o curb_postfield.o curb_upload.o curb_errors.o curb_easy.o curb_multi.o -L. -L/opt/csw/lib -R/opt/csw/lib -L. -L/opt/csw/lib -R /opt/csw/lib -L/opt/csw/lib -lruby -lpthread -lrt -ldl -lcrypt -lm -lc -L/opt/csw/lib -lcurl -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -lcares -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz ld: illegal option -- x usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) The failure is because the linker is using the option -xarch=v8 and this is as a result of using 'curl-config --libs': jensd at current8s:ext$> curl-config --libs -L/opt/csw/lib -lcurl -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -lcares -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz I don't think curl-config should be emitting '-xarch=v8' here. ====================================================================== ---------------------------------------------------------------------- (0008290) dam (administrator) - 2010-09-17 23:12 https://www.opencsw.org/mantis/view.php?id=4550#c8290 ---------------------------------------------------------------------- Yes, you are right. I'll have a look how the option gets in there. From noreply at opencsw.org Mon Sep 20 09:19:58 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 20 Sep 2010 09:19:58 +0200 Subject: [bug-notifications] [ghostscript 0004551]: Please upgrade to 9.00 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4551 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: ghostscript Issue ID: 4551 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-20 09:19 CEST Last Modified: 2010-09-20 09:19 CEST ====================================================================== Summary: Please upgrade to 9.00 Description: Please upgrade to 9.00 as released by SFW today ====================================================================== From noreply at opencsw.org Mon Sep 20 10:23:27 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 20 Sep 2010 10:23:27 +0200 Subject: [bug-notifications] [ghostscript 0004551]: Please upgrade to 9.00 In-Reply-To: <71353c59fa0a6ee2d17866279a099076> Message-ID: <058c5c15b908165cb5f6bb9488230d3b@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4551 ====================================================================== Reported By: dam Assigned To: james ====================================================================== Project: ghostscript Issue ID: 4551 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-20 09:19 CEST Last Modified: 2010-09-20 10:23 CEST ====================================================================== Summary: Please upgrade to 9.00 Description: Please upgrade to 9.00 as released by SFW today ====================================================================== From noreply at opencsw.org Mon Sep 20 10:25:30 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 20 Sep 2010 10:25:30 +0200 Subject: [bug-notifications] [ghostscript 0004551]: Please upgrade to 9.00 In-Reply-To: <71353c59fa0a6ee2d17866279a099076> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4551 ====================================================================== Reported By: dam Assigned To: james ====================================================================== Project: ghostscript Issue ID: 4551 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-20 09:19 CEST Last Modified: 2010-09-20 10:25 CEST ====================================================================== Summary: Please upgrade to 9.00 Description: Please upgrade to 9.00 as released by SFW today ====================================================================== ---------------------------------------------------------------------- (0008291) james (manager) - 2010-09-20 10:25 https://www.opencsw.org/mantis/view.php?id=4551#c8291 ---------------------------------------------------------------------- Please do not waste my time and your time reporting updates within 24 hours of their release. With a major update (8.xx to 9.00) it makes sense to ignore it for a month anyway. From noreply at opencsw.org Mon Sep 20 15:22:14 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 20 Sep 2010 15:22:14 +0200 Subject: [bug-notifications] [gtk2 0003996]: missing printbackend In-Reply-To: <6ceb454748ad96fa5cd3416db8a68ff7> Message-ID: <3852868a6417850546946f7fe40b405a@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=3996 ====================================================================== Reported By: schwindt Assigned To: dam ====================================================================== Project: gtk2 Issue ID: 3996 Category: packaging Reproducibility: always Severity: feature Priority: normal Status: assigned ====================================================================== Date Submitted: 2009-11-05 00:41 CET Last Modified: 2010-09-20 15:22 CEST ====================================================================== Summary: missing printbackend Description: /opt/csw/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so is missing. it seems cups was not found at compile time. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- parent of 0003663 Please provide 64 bit libs ====================================================================== ---------------------------------------------------------------------- (0008292) dam (administrator) - 2010-09-20 15:22 https://www.opencsw.org/mantis/view.php?id=3996#c8292 ---------------------------------------------------------------------- For now I added CUPS for just 32 bit. Feel free to try the packages from my experimental: http://buildfarm.opencsw.org/experimental.html#dam From noreply at opencsw.org Mon Sep 20 17:52:03 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 20 Sep 2010 17:52:03 +0200 Subject: [bug-notifications] [bzip2 0004552]: Please upgrade to 1.0.6 Message-ID: <9188a01a4f04535368a8ca14e6f67855@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4552 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: bzip2 Issue ID: 4552 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-20 17:52 CEST Last Modified: 2010-09-20 17:52 CEST ====================================================================== Summary: Please upgrade to 1.0.6 Description: Please upgrade to 1.0.6 due to the security fix released today ====================================================================== From noreply at opencsw.org Wed Sep 22 09:41:43 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 22 Sep 2010 09:41:43 +0200 Subject: [bug-notifications] [subversion 0004542]: Subversion needs a client only compilation In-Reply-To: <9723c32d5cb799c0e8759127bdf99424> Message-ID: <05e7449568874810927769f8d9039d52@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4542 ====================================================================== Reported By: fuqqer Assigned To: dam ====================================================================== Project: subversion Issue ID: 4542 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-02 23:42 CEST Last Modified: 2010-09-22 09:41 CEST ====================================================================== Summary: Subversion needs a client only compilation Description: the subversion package should not have heavy requirements just to check out from a tree. There should be a client and a server side package for subversion. ====================================================================== From noreply at opencsw.org Wed Sep 22 09:45:13 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 22 Sep 2010 09:45:13 +0200 Subject: [bug-notifications] [subversion 0004542]: Subversion needs a client only compilation In-Reply-To: <9723c32d5cb799c0e8759127bdf99424> Message-ID: <5e879aa7dad19ba4350baa863fb9dd45@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4542 ====================================================================== Reported By: fuqqer Assigned To: dam ====================================================================== Project: subversion Issue ID: 4542 Category: packaging Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-02 23:42 CEST Last Modified: 2010-09-22 09:45 CEST ====================================================================== Summary: Subversion needs a client only compilation Description: the subversion package should not have heavy requirements just to check out from a tree. There should be a client and a server side package for subversion. ====================================================================== ---------------------------------------------------------------------- (0008293) dam (administrator) - 2010-09-22 09:45 https://www.opencsw.org/mantis/view.php?id=4542#c8293 ---------------------------------------------------------------------- The dependencies for the "svn" binary are already quite long. It may be necessary to add a "thin" svn client with minimal dependencies as alternative: current9s% ldd -r work/solaris9-sparc/pkgroot/opt/csw/bin/svn /usr/lib/secure/s9_preload.so.1 libsvn_client-1.so.0 => /opt/csw/lib/svn/libsvn_client-1.so.0 libsvn_wc-1.so.0 => /opt/csw/lib/svn/libsvn_wc-1.so.0 libsvn_ra-1.so.0 => /opt/csw/lib/svn/libsvn_ra-1.so.0 libsvn_diff-1.so.0 => /opt/csw/lib/svn/libsvn_diff-1.so.0 libsvn_ra_local-1.so.0 => /opt/csw/lib/svn/libsvn_ra_local-1.so.0 libsvn_repos-1.so.0 => /opt/csw/lib/svn/libsvn_repos-1.so.0 libsvn_fs-1.so.0 => /opt/csw/lib/svn/libsvn_fs-1.so.0 libsvn_fs_fs-1.so.0 => /opt/csw/lib/svn/libsvn_fs_fs-1.so.0 libsvn_fs_base-1.so.0 => /opt/csw/lib/svn/libsvn_fs_base-1.so.0 libdb-4.8.so => /opt/csw/bdb48/lib/libdb-4.8.so libsvn_fs_util-1.so.0 => /opt/csw/lib/svn/libsvn_fs_util-1.so.0 libsvn_ra_svn-1.so.0 => /opt/csw/lib/svn/libsvn_ra_svn-1.so.0 libsasl2.so.2 => /opt/csw/lib/sparcv8/libsasl2.so.2 libsvn_ra_neon-1.so.0 => /opt/csw/lib/svn/libsvn_ra_neon-1.so.0 libsvn_ra_serf-1.so.0 => /opt/csw/lib/svn/libsvn_ra_serf-1.so.0 libserf-0.so.0 => /opt/csw/lib/sparcv8/libserf-0.so.0 libsvn_delta-1.so.0 => /opt/csw/lib/svn/libsvn_delta-1.so.0 libsvn_subr-1.so.0 => /opt/csw/lib/svn/libsvn_subr-1.so.0 libintl.so.8 => /opt/csw/lib/sparcv8/libintl.so.8 libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 libsqlite3.so.0 => /opt/csw/lib/sparcv8/libsqlite3.so.0 libaprutil-1.so.0 => /opt/csw/apache2/lib/libaprutil-1.so.0 libldap-2.4.so.2 => /opt/csw/lib/sparcv8/libldap-2.4.so.2 liblber-2.4.so.2 => /opt/csw/lib/sparcv8/liblber-2.4.so.2 libexpat.so.1 => /opt/csw/lib/sparcv8/libexpat.so.1 libiconv.so.2 => /opt/csw/lib/sparcv8/libiconv.so.2 libapr-1.so.0 => /opt/csw/apache2/lib/libapr-1.so.0 libuuid.so.1 => /usr/lib/libuuid.so.1 libsendfile.so.1 => /usr/lib/libsendfile.so.1 librt.so.1 => /usr/lib/librt.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libneon.so.27 => /opt/csw/lib/sparcv8/libneon.so.27 libsocket.so.1 => /usr/lib/libsocket.so.1 libthread.so.1 => /usr/lib/libthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libldap-2.3.so.0 => /opt/csw/lib/sparcv8/libldap-2.3.so.0 liblber-2.3.so.0 => /opt/csw/lib/sparcv8/liblber-2.3.so.0 libresolv.so.2 => /usr/lib/libresolv.so.2 libaprutil-1.so.0 => /opt/csw/lib/libaprutil-1.so.0 libapr-1.so.0 => /opt/csw/lib/libapr-1.so.0 libm.so.1 => /usr/lib/libm.so.1 libz.so.1 => /opt/csw/lib/libz.so.1 libssl.so.0.9.8 => /opt/csw/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 => /opt/csw/lib/libcrypto.so.0.9.8 libsec.so.1 => /usr/lib/libsec.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libnet.so => /opt/csw/lib/sparcv8/libnet.so libssl.so.0.9.8 => /opt/csw/lib/sparcv8plus+vis/libssl.so.0.9.8 libcrypto.so.0.9.8 => /opt/csw/lib/sparcv8plus+vis/libcrypto.so.0.9.8 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 From noreply at opencsw.org Thu Sep 23 01:22:52 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 23 Sep 2010 01:22:52 +0200 Subject: [bug-notifications] [wireshark 0004548]: Please Update Wireshark to latest stable release (currently 1.4.0) from Wireshark.org In-Reply-To: <047aedc6bd702739e7f43bca56af3e1b> Message-ID: <15ce7d60505750e5c6240d451bb38aae@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4548 ====================================================================== Reported By: alfyj Assigned To: hson ====================================================================== Project: wireshark Issue ID: 4548 Category: upgrade Reproducibility: N/A Severity: feature Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-09 22:01 CEST Last Modified: 2010-09-23 01:22 CEST ====================================================================== Summary: Please Update Wireshark to latest stable release (currently 1.4.0) from Wireshark.org Description: Current release 1.2.3 is at least 18 months old as a Solaris package, and probably additional months behind the Windows & OSX versions available at wireshark.org. My users are asking me to upgrade our server, which has monitor feeds from multiple routers in our lab. ====================================================================== From noreply at opencsw.org Thu Sep 23 07:10:12 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 23 Sep 2010 07:10:12 +0200 Subject: [bug-notifications] [findutils 0004460]: Please provide /opt/csw/gnu links In-Reply-To: Message-ID: The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4460 ====================================================================== Reported By: bwalton Assigned To: gmarler ====================================================================== Project: findutils Issue ID: 4460 Category: packaging Reproducibility: N/A Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-06-17 03:19 CEST Last Modified: 2010-09-23 07:10 CEST ====================================================================== Summary: Please provide /opt/csw/gnu links Description: All packages providing g* binaries in /opt/csw/bin should now provide a symlink from /opt/csw/gnu/$bin_without_g_prefix to /opt/csw/bin/$bin_with_g_prefix (eg: /opt/csw/gnu/ls -> /opt/csw/bin/gls. Please update this package and let Ben know so he can drop the links from CSWgnulinks. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- has duplicate 0004475 Add g-prefixed-named binaries to /opt/c... ====================================================================== From noreply at opencsw.org Thu Sep 23 16:25:50 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 23 Sep 2010 16:25:50 +0200 Subject: [bug-notifications] [munin_node 0004553]: Please upgrade to 1.4 series Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4553 ====================================================================== Reported By: mgrueter Assigned To: ====================================================================== Project: munin_node Issue ID: 4553 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-23 16:25 CEST Last Modified: 2010-09-23 16:25 CEST ====================================================================== Summary: Please upgrade to 1.4 series Description: Please upgrade to the stable 1.4 release series of munin. According munin folks, the 1.3 series was never "release quality", it was a test series. ====================================================================== From noreply at opencsw.org Fri Sep 24 01:06:13 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 24 Sep 2010 01:06:13 +0200 Subject: [bug-notifications] [zlib 0004431]: Please upgrade to 1.2.5 In-Reply-To: <739b568688adb788b2ad1e22c3bf6013> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4431 ====================================================================== Reported By: dam Assigned To: hson ====================================================================== Project: zlib Issue ID: 4431 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-05-26 12:12 CEST Last Modified: 2010-09-24 01:06 CEST ====================================================================== Summary: Please upgrade to 1.2.5 Description: Please upgrade to 1.2.5 ====================================================================== ---------------------------------------------------------------------- (0008294) hson (manager) - 2010-09-24 01:06 https://www.opencsw.org/mantis/view.php?id=4431#c8294 ---------------------------------------------------------------------- zlib 1.2.5 released From noreply at opencsw.org Fri Sep 24 05:56:08 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 24 Sep 2010 05:56:08 +0200 Subject: [bug-notifications] [findutils 0004460]: Please provide /opt/csw/gnu links In-Reply-To: Message-ID: <04c027b6eeb80328f7577ae263f0cb28@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4460 ====================================================================== Reported By: bwalton Assigned To: gmarler ====================================================================== Project: findutils Issue ID: 4460 Category: packaging Reproducibility: N/A Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-06-17 03:19 CEST Last Modified: 2010-09-24 05:56 CEST ====================================================================== Summary: Please provide /opt/csw/gnu links Description: All packages providing g* binaries in /opt/csw/bin should now provide a symlink from /opt/csw/gnu/$bin_without_g_prefix to /opt/csw/bin/$bin_with_g_prefix (eg: /opt/csw/gnu/ls -> /opt/csw/bin/gls. Please update this package and let Ben know so he can drop the links from CSWgnulinks. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- has duplicate 0004475 Add g-prefixed-named binaries to /opt/c... ====================================================================== ---------------------------------------------------------------------- (0008296) gmarler (developer) - 2010-09-24 05:56 https://www.opencsw.org/mantis/view.php?id=4460#c8296 ---------------------------------------------------------------------- As recommended, now testing use of post-install-modulated target to do this, as implemented in CSWgrep. From noreply at opencsw.org Fri Sep 24 19:06:01 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Fri, 24 Sep 2010 19:06:01 +0200 Subject: [bug-notifications] [poppler 0004339]: CSWpoppler overwrites CSWxpdf files In-Reply-To: <7952e43689c58773810ede52bc4e8565> Message-ID: <1b19232af9455a82db328ac2ee51b819@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4339 ====================================================================== Reported By: james Assigned To: hson ====================================================================== Project: poppler Issue ID: 4339 Category: packaging Reproducibility: always Severity: block Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2010-03-13 13:58 CET Last Modified: 2010-09-24 19:06 CEST ====================================================================== Summary: CSWpoppler overwrites CSWxpdf files Description: CSWpoppler overwrites CSWxpdf files, see also: http://www.opencsw.org/bugtrack/view.php?id=2680 ====================================================================== ---------------------------------------------------------------------- (0008297) hson (manager) - 2010-09-24 19:06 https://www.opencsw.org/mantis/view.php?id=4339#c8297 ---------------------------------------------------------------------- Fixed in 0.12.4,REV=2010.04.10 From noreply at opencsw.org Sun Sep 26 04:50:27 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 04:50:27 +0200 Subject: [bug-notifications] [zlib 0004373]: zlib 1.2.4 breaks wireshark (maybe others too) In-Reply-To: <0d4486e07ab81e1a262f0c91b59166bb> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4373 ====================================================================== Reported By: skayser Assigned To: hson ====================================================================== Project: zlib Issue ID: 4373 Category: regular use Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-03-26 15:03 CET Last Modified: 2010-09-26 04:50 CEST ====================================================================== Summary: zlib 1.2.4 breaks wireshark (maybe others too) Description: After upgrading a Solaris 10 system running with current/ I could observe zlib related problems with wireshark just like reported elsewhere: FS#18061 - [wireshark] packet capture trouble with latest zlib http://bugs.archlinux.org/task/18061 For now, downgrading to zlib 1.2.3 helped to fix the problem. There are a couple of related bugs over at the wireshark bug tracker. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4439 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4606 Ben Walton informally reported suspected zlib 1.2.4 issues with libxml2. http://lists.opencsw.org/pipermail/users/2010-March/008635.html ====================================================================== ---------------------------------------------------------------------- (0008298) hson (manager) - 2010-09-26 04:50 https://www.opencsw.org/mantis/view.php?id=4373#c8298 ---------------------------------------------------------------------- No feedback recieved From noreply at opencsw.org Sun Sep 26 04:52:22 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 04:52:22 +0200 Subject: [bug-notifications] [cswutils 0003461]: checkpkg incorrectly warns for V8+ binaries In-Reply-To: <1be9bc426a5b1cdfd810ca8896f8a787> Message-ID: <8966cf46997b1fe420aaaceec1c329d0@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3461 ====================================================================== Reported By: hson Assigned To: maciej ====================================================================== Project: cswutils Issue ID: 3461 Category: regular use Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2009-03-08 02:55 CET Last Modified: 2010-09-26 04:52 CEST ====================================================================== Summary: checkpkg incorrectly warns for V8+ binaries Description: When packaging libnids, checkpkg reports: WARNING: found binaries in normal bin dir that are V8+ libnids doesn't have any binaries in /opt/csw/bin so this message is incorrectly ====================================================================== ---------------------------------------------------------------------- (0008124) maciej (developer) - 2010-07-20 00:02 https://www.opencsw.org/mantis/view.php?id=3461#c8124 ---------------------------------------------------------------------- I believe this is fixed, can you check? From noreply at opencsw.org Sun Sep 26 04:52:33 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 04:52:33 +0200 Subject: [bug-notifications] [cswutils 0003944]: checkpkg needs to check for wrong-arch libs In-Reply-To: <2ada85ec1ecca2ee89886d9e9cd94a4d> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=3944 ====================================================================== Reported By: skayser Assigned To: maciej ====================================================================== Project: cswutils Issue ID: 3944 Category: other Reproducibility: always Severity: feature Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2009-10-06 20:37 CEST Last Modified: 2010-09-26 04:52 CEST ====================================================================== Summary: checkpkg needs to check for wrong-arch libs Description: I just noticed sparcv9 libs in an i386 package of neon (https://www.opencsw.org/mantis/view.php?id=3943). Could checkpkg please be enhanced to also check for such wrong-arch libs in a package. # pkgchk -v CSWneon /opt/csw/lib/libneon.so /opt/csw/lib/libneon.so.26 /opt/csw/lib/libneon.so.26.0.4 /opt/csw/lib/libneon.so.27 /opt/csw/lib/libneon.so.27.2.0 /opt/csw/lib/sparcv9/libneon.so /opt/csw/lib/sparcv9/libneon.so.26 /opt/csw/lib/sparcv9/libneon.so.26.0.4 /opt/csw/lib/sparcv9/libneon.so.27 /opt/csw/lib/sparcv9/libneon.so.27.2.0 /opt/csw/share/doc/neon /opt/csw/share/doc/neon/license /opt/csw/share/locale/cs/LC_MESSAGES/neon.mo /opt/csw/share/locale/de/LC_MESSAGES/neon.mo /opt/csw/share/locale/fr/LC_MESSAGES/neon.mo /opt/csw/share/locale/ja/LC_MESSAGES/neon.mo /opt/csw/share/locale/nn/LC_MESSAGES/neon.mo /opt/csw/share/locale/pl/LC_MESSAGES/neon.mo /opt/csw/share/locale/ru/LC_MESSAGES/neon.mo /opt/csw/share/locale/tr/LC_MESSAGES/neon.mo /opt/csw/share/locale/zh_CN/LC_MESSAGES /opt/csw/share/locale/zh_CN/LC_MESSAGES/neon.mo # file /opt/csw/lib/sparcv9/libneon.so* /opt/csw/lib/sparcv9/libneon.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped /opt/csw/lib/sparcv9/libneon.so.26: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped /opt/csw/lib/sparcv9/libneon.so.26.0.4: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped /opt/csw/lib/sparcv9/libneon.so.27: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped /opt/csw/lib/sparcv9/libneon.so.27.2.0: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped ====================================================================== ---------------------------------------------------------------------- (0008126) maciej (developer) - 2010-07-20 13:25 https://www.opencsw.org/mantis/view.php?id=3944#c8126 ---------------------------------------------------------------------- Done, here's an example run: maciej at current9s :~/src/opencsw/gar/checkpkg-profiling > bin/checkpkg /home/maciej/neon-0.29.0,REV\=2009.09.14-SunOS5.8-i386-CSW.pkg.gz INFO:root:Juicing the srv4 package stream files... 100% |#################################################################################################################################################################################################| INFO:root:Unwrapping candies... 100% |#################################################################################################################################################################################################| INFO:root:Tasting candies one by one... 100% |#################################################################################################################################################################################################| INFO:root:Tasting them all at once... INFO:root:Stuffing the candies under the pillow... 100% |#################################################################################################################################################################################################| CSWneon: Applying the overrides and analyzing the results. If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWneon += bad-rpath-entry|/opt/csw/lib/|opt/csw/lib/libneon.so.26.0.4 CHECKPKG_OVERRIDES_CSWneon += bad-rpath-entry|/opt/csw/lib/|opt/csw/lib/libneon.so.27.2.0 CHECKPKG_OVERRIDES_CSWneon += binary-wrong-architecture|file=opt/csw/lib/sparcv9/libneon.so.27.2.0|pkginfo-says=i386|actual-binary=sparc CHECKPKG_OVERRIDES_CSWneon += binary-wrong-architecture|file=opt/csw/lib/sparcv9/libneon.so.26.0.4|pkginfo-says=i386|actual-binary=sparc Please note that checkpkg isn't suggesting you should simply add these overrides do the Makefile. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. For more information, scroll up and read the detailed messages. ERROR: Modular checks are reporting errors. To run checkpkg in the debug mode, add the '-d' flag, for example: After you modify any overrides, you need to do gmake remerge repackage or gmake platforms-remerge platforms-repackage. From noreply at opencsw.org Sun Sep 26 19:56:52 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 19:56:52 +0200 Subject: [bug-notifications] [munin_node 0004553]: Please upgrade to 1.4 series In-Reply-To: Message-ID: The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4553 ====================================================================== Reported By: mgrueter Assigned To: ja ====================================================================== Project: munin_node Issue ID: 4553 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-23 16:25 CEST Last Modified: 2010-09-26 19:56 CEST ====================================================================== Summary: Please upgrade to 1.4 series Description: Please upgrade to the stable 1.4 release series of munin. According munin folks, the 1.3 series was never "release quality", it was a test series. ====================================================================== From noreply at opencsw.org Sun Sep 26 20:11:29 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 20:11:29 +0200 Subject: [bug-notifications] [munin_node 0004553]: Please upgrade to 1.4 series In-Reply-To: Message-ID: <671f44531dcd3b36d05fe7d1057237b0@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4553 ====================================================================== Reported By: mgrueter Assigned To: ja ====================================================================== Project: munin_node Issue ID: 4553 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-23 16:25 CEST Last Modified: 2010-09-26 20:11 CEST ====================================================================== Summary: Please upgrade to 1.4 series Description: Please upgrade to the stable 1.4 release series of munin. According munin folks, the 1.3 series was never "release quality", it was a test series. ====================================================================== ---------------------------------------------------------------------- (0008299) ja (manager) - 2010-09-26 20:11 https://www.opencsw.org/mantis/view.php?id=4553#c8299 ---------------------------------------------------------------------- Please try the packages in the experimental section: http://buildfarm.opencsw.org/experimental/ja/munin_master-1.4.5,REV=2010.09.26-SunOS5.9-all-CSW.pkg.gz http://buildfarm.opencsw.org/experimental/ja/munin_common-1.4.5,REV=2010.09.26-SunOS5.9-all-CSW.pkg.gz http://buildfarm.opencsw.org/experimental/ja/munin_node-1.4.5,REV=2010.09.26-SunOS5.9-all-CSW.pkg.gz They should work out of the box quite well. Please give me a feedback, if these packages could be released from your point of view. Or if there are some problems, of course. Please note, that the node and the master package needs both the common package. From noreply at opencsw.org Sun Sep 26 20:11:54 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 20:11:54 +0200 Subject: [bug-notifications] [munin_node 0004553]: Please upgrade to 1.4 series In-Reply-To: Message-ID: The following issue requires your FEEDBACK. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4553 ====================================================================== Reported By: mgrueter Assigned To: ja ====================================================================== Project: munin_node Issue ID: 4553 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-23 16:25 CEST Last Modified: 2010-09-26 20:11 CEST ====================================================================== Summary: Please upgrade to 1.4 series Description: Please upgrade to the stable 1.4 release series of munin. According munin folks, the 1.3 series was never "release quality", it was a test series. ====================================================================== ---------------------------------------------------------------------- (0008299) ja (manager) - 2010-09-26 20:11 https://www.opencsw.org/mantis/view.php?id=4553#c8299 ---------------------------------------------------------------------- Please try the packages in the experimental section: http://buildfarm.opencsw.org/experimental/ja/munin_master-1.4.5,REV=2010.09.26-SunOS5.9-all-CSW.pkg.gz http://buildfarm.opencsw.org/experimental/ja/munin_common-1.4.5,REV=2010.09.26-SunOS5.9-all-CSW.pkg.gz http://buildfarm.opencsw.org/experimental/ja/munin_node-1.4.5,REV=2010.09.26-SunOS5.9-all-CSW.pkg.gz They should work out of the box quite well. Please give me a feedback, if these packages could be released from your point of view. Or if there are some problems, of course. Please note, that the node and the master package needs both the common package. From noreply at opencsw.org Sun Sep 26 21:34:37 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Sun, 26 Sep 2010 21:34:37 +0200 Subject: [bug-notifications] [dovecot 0004554]: Please upgrade to 1.2.14 Message-ID: <8fd7e3af0bc24bfa356524de763ae455@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4554 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: dovecot Issue ID: 4554 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-26 21:34 CEST Last Modified: 2010-09-26 21:34 CEST ====================================================================== Summary: Please upgrade to 1.2.14 Description: Please upgrade to 1.2.14 as released by sfw today ====================================================================== From noreply at opencsw.org Mon Sep 27 12:50:00 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Mon, 27 Sep 2010 12:50:00 +0200 Subject: [bug-notifications] [openldap 0004555]: libldap-2.4.so is linked against liblber-2.3.so Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4555 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: openldap Issue ID: 4555 Category: packaging Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-27 12:49 CEST Last Modified: 2010-09-27 12:49 CEST ====================================================================== Summary: libldap-2.4.so is linked against liblber-2.3.so Description: libldap-2.4.so is linked against liblber-2.3.so: current9s% dump -Lv /opt/csw/lib/sparcv8/libldap-2.4.so.2 /opt/csw/lib/sparcv8/libldap-2.4.so.2: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED liblber-2.3.so.0 [2] NEEDED libresolv.so.2 ... Most probably this is due to the use of LDFLAGS. ====================================================================== From noreply at opencsw.org Tue Sep 28 09:21:07 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 28 Sep 2010 09:21:07 +0200 Subject: [bug-notifications] [ap2_subversion 0004477]: missing dependency In-Reply-To: <80830fb6969873375ae22af4f34bc799> Message-ID: <5c9dbe8e123bd7d7dc45638767d71ad8@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4477 ====================================================================== Reported By: holzi Assigned To: dam ====================================================================== Project: ap2_subversion Issue ID: 4477 Category: regular use Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-06-24 14:05 CEST Last Modified: 2010-09-28 09:21 CEST ====================================================================== Summary: missing dependency Description: installing ap2_subversion on a new systems fails as the apache Server is not installed: 1. ## Installing part 1 of 1. 2. /opt/csw/apache2/etc/extra/httpd-svn.conf.CSW 3. /opt/csw/apache2/etc/svn_access.conf.CSW 4. /opt/csw/apache2/libexec/mod_authz_svn.so 5. /opt/csw/apache2/libexec/mod_dav_svn.so 6. /opt/csw/share/doc/ap2_subversion/changelog.CSW 7. /opt/csw/share/doc/ap2_subversion/license 8. [ verifying class ] 9. ## Executing postinstall script. 10. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 11. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 12. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 13. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 14. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 15. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 16. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 17. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 18. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 19. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 20. egrep: can't open /opt/csw/apache2/etc/httpd.conf 21. egrep: can't open /opt/csw/apache2/etc/httpd.conf 22. Adding Include for extra/http-svn.conf to httpd.conf 23. Creating /opt/csw/apache2/etc/extra/httpd-svn.conf 24. Creating /opt/csw/apache2/etc/svn_access.conf 25. 26. NOTICE: mod_dav, mod_dav_fs, mod_dav_svn, and mod_authz_svn are enabled in 27. httpd.conf, but the server was not restarted. Please examine your mod_dav_svn configuration and restart apache. 28. I guess ap2_subversion should depend on the whole apache2 stack. (cswapache2) ====================================================================== ---------------------------------------------------------------------- (0008230) rupert (developer) - 2010-08-31 18:20 https://www.opencsw.org/mantis/view.php?id=4477#c8230 ---------------------------------------------------------------------- ups ... sure you are right, changed in the makefile quite some time ago now, will see when i've time to release the version. From noreply at opencsw.org Tue Sep 28 09:21:28 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 28 Sep 2010 09:21:28 +0200 Subject: [bug-notifications] [ap2_subversion 0004477]: missing dependency In-Reply-To: <80830fb6969873375ae22af4f34bc799> Message-ID: The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=4477 ====================================================================== Reported By: holzi Assigned To: dam ====================================================================== Project: ap2_subversion Issue ID: 4477 Category: regular use Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2010-06-24 14:05 CEST Last Modified: 2010-09-28 09:21 CEST ====================================================================== Summary: missing dependency Description: installing ap2_subversion on a new systems fails as the apache Server is not installed: 1. ## Installing part 1 of 1. 2. /opt/csw/apache2/etc/extra/httpd-svn.conf.CSW 3. /opt/csw/apache2/etc/svn_access.conf.CSW 4. /opt/csw/apache2/libexec/mod_authz_svn.so 5. /opt/csw/apache2/libexec/mod_dav_svn.so 6. /opt/csw/share/doc/ap2_subversion/changelog.CSW 7. /opt/csw/share/doc/ap2_subversion/license 8. [ verifying class ] 9. ## Executing postinstall script. 10. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 11. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 12. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 13. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 14. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 15. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 16. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 17. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 18. Can't open /opt/csw/apache2/etc/httpd.conf: No such file or directory. 19. apxs:Error: /opt/csw/apache2/sbin/httpd not found or not executable. 20. egrep: can't open /opt/csw/apache2/etc/httpd.conf 21. egrep: can't open /opt/csw/apache2/etc/httpd.conf 22. Adding Include for extra/http-svn.conf to httpd.conf 23. Creating /opt/csw/apache2/etc/extra/httpd-svn.conf 24. Creating /opt/csw/apache2/etc/svn_access.conf 25. 26. NOTICE: mod_dav, mod_dav_fs, mod_dav_svn, and mod_authz_svn are enabled in 27. httpd.conf, but the server was not restarted. Please examine your mod_dav_svn configuration and restart apache. 28. I guess ap2_subversion should depend on the whole apache2 stack. (cswapache2) ====================================================================== ---------------------------------------------------------------------- (0008300) dam (administrator) - 2010-09-28 09:21 https://www.opencsw.org/mantis/view.php?id=4477#c8300 ---------------------------------------------------------------------- Fixed in 1.6.12,REV=2010.09.23 and released to current/. From noreply at opencsw.org Tue Sep 28 11:17:01 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 28 Sep 2010 11:17:01 +0200 Subject: [bug-notifications] [alternatives 0004556]: Major selection used by all packages does not work Message-ID: <4897ac51f15f557485da8a4a4ebb6533@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4556 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: alternatives Issue ID: 4556 Category: regular use Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-28 11:16 CEST Last Modified: 2010-09-28 11:16 CEST ====================================================================== Summary: Major selection used by all packages does not work Description: The major selection option used by all of my packages like /opt/csw/sbin/alternatives --config mutt does not work in this implementation. It should display a menu and allow easy selection. ====================================================================== From noreply at opencsw.org Tue Sep 28 18:38:01 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Tue, 28 Sep 2010 18:38:01 +0200 Subject: [bug-notifications] [alternatives 0004556]: Major selection used by all packages does not work In-Reply-To: <5726e3969ec32419f294c61ea9df623d> Message-ID: <1449bd7ca3d230477c620d05cdf55da6@www.opencsw.org> The following issue has been ASSIGNED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4556 ====================================================================== Reported By: dam Assigned To: phil ====================================================================== Project: alternatives Issue ID: 4556 Category: regular use Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 2010-09-28 11:16 CEST Last Modified: 2010-09-28 18:38 CEST ====================================================================== Summary: Major selection used by all packages does not work Description: The major selection option used by all of my packages like /opt/csw/sbin/alternatives --config mutt does not work in this implementation. It should display a menu and allow easy selection. ====================================================================== From noreply at opencsw.org Wed Sep 29 12:06:56 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 29 Sep 2010 12:06:56 +0200 Subject: [bug-notifications] [sudo 0004519]: Please upgrade to 1.7.4p2 In-Reply-To: <93483368a4f7c4267e8e9083766c909e> Message-ID: A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4519 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: sudo Issue ID: 4519 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-08-12 14:34 CEST Last Modified: 2010-09-29 12:06 CEST ====================================================================== Summary: Please upgrade to 1.7.4p2 Description: Please upgrade to 1.7.4p2 ====================================================================== ---------------------------------------------------------------------- (0008301) dam (administrator) - 2010-09-29 12:06 https://www.opencsw.org/mantis/view.php?id=4519#c8301 ---------------------------------------------------------------------- Please upgrade to 1.7.4p4 as released by SFW today. From noreply at opencsw.org Wed Sep 29 18:54:29 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Wed, 29 Sep 2010 18:54:29 +0200 Subject: [bug-notifications] [sudo 0004519]: Please upgrade to 1.7.4p2 In-Reply-To: <93483368a4f7c4267e8e9083766c909e> Message-ID: <5689f3a96b3964fb9fc8d2d2d72b40c9@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4519 ====================================================================== Reported By: dam Assigned To: ====================================================================== Project: sudo Issue ID: 4519 Category: upgrade Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-08-12 14:34 CEST Last Modified: 2010-09-29 18:54 CEST ====================================================================== Summary: Please upgrade to 1.7.4p2 Description: Please upgrade to 1.7.4p2 ====================================================================== ---------------------------------------------------------------------- (0008302) maciej (manager) - 2010-09-29 18:54 https://www.opencsw.org/mantis/view.php?id=4519#c8302 ---------------------------------------------------------------------- I tried 1.7.4. and it failed on me so horribly I still have twitches when I think about it. I'll give it another careful go. From noreply at opencsw.org Thu Sep 30 11:21:19 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 11:21:19 +0200 Subject: [bug-notifications] [iftop 0004557]: iftop displays zeroes for all values Message-ID: <4e449332413b4d2dd5668077c81ecf1d@www.opencsw.org> The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4557 ====================================================================== Reported By: laurent Assigned To: ====================================================================== Project: iftop Issue ID: 4557 Category: regular use Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-30 11:21 CEST Last Modified: 2010-09-30 11:21 CEST ====================================================================== Summary: iftop displays zeroes for all values Description: Following an upgrade to the current or unstable branches, iftop stops working and displays only zeroes: TX: cumm: 0B peak: 0b rates: 0b 0b 0b RX: 0B 0b 0b 0b 0b TOTAL: 0B 0b 0b 0b 0b Switching back to the stable branch, and reinstalling only iftop and libpcap, it works again. ====================================================================== From noreply at opencsw.org Thu Sep 30 15:18:50 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 15:18:50 +0200 Subject: [bug-notifications] [cswclassutils 0004558]: /usr/sadm/install/scripts/i.cswpreserveconf: syntax error at line 96: `end of file' unexpected Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4558 ====================================================================== Reported By: holzi Assigned To: ====================================================================== Project: cswclassutils Issue ID: 4558 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-30 15:18 CEST Last Modified: 2010-09-30 15:18 CEST ====================================================================== Summary: /usr/sadm/install/scripts/i.cswpreserveconf: syntax error at line 96: `end of file' unexpected Description: Scipts fails with: /usr/sadm/install/scripts/i.cswpreserveconf: syntax error at line 96: `end of file' unexpected found during apache 2 experimental test. http://buildfarm.opencsw.org/experimental.html#bwalton ====================================================================== From noreply at opencsw.org Thu Sep 30 15:42:37 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 15:42:37 +0200 Subject: [bug-notifications] [rssh 0001711]: Not Sun4m compatible In-Reply-To: Message-ID: <8b52304edd14709d4f23be6fd09f79da@www.opencsw.org> The following issue has been CLOSED ====================================================================== https://www.opencsw.org/mantis/view.php?id=1711 ====================================================================== Reported By: james Assigned To: dam ====================================================================== Project: rssh Issue ID: 1711 Category: other Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 2006-08-06 05:36 CEST Last Modified: 2010-09-30 15:42 CEST ====================================================================== Summary: Not Sun4m compatible Description: Not Sun4m compatible. CSWrssh 2.3.2 /opt/csw/bin/rssh: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped /opt/csw/libexec/rssh_chroot_helper: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped Remember Sun cc needs -xarch=v8 or -xarch=386 to keep arch generic. (Also watch for unnecessary bloat with Studio 11, note flags: -xnolibmil -xnolibmopt) ====================================================================== ---------------------------------------------------------------------- (0008303) dam (administrator) - 2010-09-30 15:42 https://www.opencsw.org/mantis/view.php?id=1711#c8303 ---------------------------------------------------------------------- I guess this is fixed now in 2.3.3,REV=2010.08.21. From noreply at opencsw.org Thu Sep 30 15:47:44 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 15:47:44 +0200 Subject: [bug-notifications] [alternatives 0004559]: --set does not work Message-ID: The following issue has been SUBMITTED. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4559 ====================================================================== Reported By: holzi Assigned To: ====================================================================== Project: alternatives Issue ID: 4559 Category: regular use Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2010-09-30 15:47 CEST Last Modified: 2010-09-30 15:47 CEST ====================================================================== Summary: --set does not work Description: during testing the new apache2 package I wanted to change the alternative: /opt/csw/sbin/alternatives --display httpd Installed alternatives for httpd are: /opt/csw/apache2/sbin/httpd httpd /opt/csw/apache2/sbin/httpd.prefork 100 /opt/csw/apache2/sbin/httpd httpd /opt/csw/apache2/sbin/httpd.worker 50 /opt/csw/sbin/alternatives --set httpd /opt/csw/apache2/sbin/httpd.worker ln: cannot create /etc/opt/etc/alternatives/httpd: No such file or directory ====================================================================== From noreply at opencsw.org Thu Sep 30 16:05:21 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 16:05:21 +0200 Subject: [bug-notifications] [rssh 0004549]: Runtime depends on CSWossh which isn't really required In-Reply-To: Message-ID: <2433a29ca26f9b0070e7436c2e4ccf89@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4549 ====================================================================== Reported By: nicols Assigned To: dam ====================================================================== Project: rssh Issue ID: 4549 Category: packaging Reproducibility: N/A Severity: tweak Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-13 10:55 CEST Last Modified: 2010-09-30 16:05 CEST ====================================================================== Summary: Runtime depends on CSWossh which isn't really required Description: CSWossh shouldn't be runtime required for rssh We use Sun's SSH Daemon, but want rssh for rsync - thus we don't need rssh to link again CSWossh. Obviously, CSWossh still needs to be a build depend though ====================================================================== ---------------------------------------------------------------------- (0008304) dam (administrator) - 2010-09-30 16:05 https://www.opencsw.org/mantis/view.php?id=4549#c8304 ---------------------------------------------------------------------- New rssh packages available from http://buildfarm.opencsw.org/experimental.html#dam Please verify before I release it. From noreply at opencsw.org Thu Sep 30 17:25:21 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 17:25:21 +0200 Subject: [bug-notifications] [ap2_subversion 0004490]: Upgrading to 1.6.11, REV=2010.05.27 breaks webdav folders In-Reply-To: <5199f52ef74d140834dfbd01a174f95e> Message-ID: The following issue requires your FEEDBACK. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4490 ====================================================================== Reported By: schwindt Assigned To: dam ====================================================================== Project: ap2_subversion Issue ID: 4490 Category: regular use Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-07-15 21:26 CEST Last Modified: 2010-09-30 17:25 CEST ====================================================================== Summary: Upgrading to 1.6.11,REV=2010.05.27 breaks webdav folders Description: uploads no longer are possible. The main problem seems to be bdb48, as apr-util still uses bdb47 the DavLockDB is no longer useable/createable and as a result the uploads fail. ====================================================================== ---------------------------------------------------------------------- (0008305) dam (administrator) - 2010-09-30 17:25 https://www.opencsw.org/mantis/view.php?id=4490#c8305 ---------------------------------------------------------------------- I think we have now compiled everything against BDB 4.8. Please try the current packages from http://buildfarm.opencsw.org/experimental.html#subversion From noreply at opencsw.org Thu Sep 30 17:32:47 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 17:32:47 +0200 Subject: [bug-notifications] [rssh 0004549]: Runtime depends on CSWossh which isn't really required In-Reply-To: Message-ID: <1d57259a5b0933b425d566d60f0a3d47@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4549 ====================================================================== Reported By: nicols Assigned To: dam ====================================================================== Project: rssh Issue ID: 4549 Category: packaging Reproducibility: N/A Severity: tweak Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-09-13 10:55 CEST Last Modified: 2010-09-30 17:32 CEST ====================================================================== Summary: Runtime depends on CSWossh which isn't really required Description: CSWossh shouldn't be runtime required for rssh We use Sun's SSH Daemon, but want rssh for rsync - thus we don't need rssh to link again CSWossh. Obviously, CSWossh still needs to be a build depend though ====================================================================== ---------------------------------------------------------------------- (0008306) nicols (developer) - 2010-09-30 17:32 https://www.opencsw.org/mantis/view.php?id=4549#c8306 ---------------------------------------------------------------------- Hi dam, Seems to work well for me - not attempting to install CSWossh any more at any rate ;) Andrew From noreply at opencsw.org Thu Sep 30 17:33:56 2010 From: noreply at opencsw.org (Mantis Bug Tracker) Date: Thu, 30 Sep 2010 17:33:56 +0200 Subject: [bug-notifications] [ap2_subversion 0004490]: Upgrading to 1.6.11, REV=2010.05.27 breaks webdav folders In-Reply-To: <5199f52ef74d140834dfbd01a174f95e> Message-ID: <9a786cec2f4d409192989fae74269ec0@www.opencsw.org> A NOTE has been added to this issue. ====================================================================== https://www.opencsw.org/mantis/view.php?id=4490 ====================================================================== Reported By: schwindt Assigned To: dam ====================================================================== Project: ap2_subversion Issue ID: 4490 Category: regular use Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-07-15 21:26 CEST Last Modified: 2010-09-30 17:33 CEST ====================================================================== Summary: Upgrading to 1.6.11,REV=2010.05.27 breaks webdav folders Description: uploads no longer are possible. The main problem seems to be bdb48, as apr-util still uses bdb47 the DavLockDB is no longer useable/createable and as a result the uploads fail. ====================================================================== ---------------------------------------------------------------------- (0008307) bwalton (developer) - 2010-09-30 17:33 https://www.opencsw.org/mantis/view.php?id=4490#c8307 ---------------------------------------------------------------------- Dago, It'd be nice if this used the new cswap2mod CAS upon update...if we get the bug in preserveconf fixed quickly, I think this new script is ready for release too. Thoughts? Thanks -Ben