From bwalton at opencsw.org Wed Sep 1 02:03:00 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 31 Aug 2010 20:03:00 -0400 Subject: [csw-maintainers] Board election method In-Reply-To: References: Message-ID: <1283299339-sup-575@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Tue Aug 31 08:06:55 -0400 2010: > abstruse/abscons. As for the tool to use I think that CIVS, private, is > a good and quick compromise. For the debian-voting, the interest is > that +1 for CIVS. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Sep 1 10:45:04 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 1 Sep 2010 10:45:04 +0200 Subject: [csw-maintainers] GAR and checksums In-Reply-To: References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> Message-ID: <56889906-15B9-48CF-8CB4-C0B3E788C609@opencsw.org> Hi, Am 24.08.2010 um 17:34 schrieb Philip Brown: > On Tue, Aug 24, 2010 at 6:19 AM, Ben Walton > wrote: >> Excerpts from Philip Brown's message of Tue Aug 24 09:09:18 -0400 >> 2010: >> >>> thats fine an all, for "external" files... but at the same time, it >>> doesn't make much sense to be running checksums on files which are >>> kept in our subversion repository >> >> This would be an easy fix, as we'd simply drop $(PATCHFILES) from the >> $(CHECKSUMFILES) variable, leaving only the tarballs/source files... > > Would that catch (or rather , skip!) things such as the cswclassutils > files.. which are not strictly "patches", yet are not downloaded > either? I have now made a very simple change to GAR, which excludes things in files/ from checksumming. These files are usually in the repository and don't need checksumming. All files pulled in from anywhere else are still checksummed. See the change at http://sourceforge.net/apps/trac/gar/changeset/10862 Best regards -- Dago From maciej at opencsw.org Wed Sep 1 10:51:48 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 1 Sep 2010 09:51:48 +0100 Subject: [csw-maintainers] GAR and checksums In-Reply-To: <56889906-15B9-48CF-8CB4-C0B3E788C609@opencsw.org> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> <56889906-15B9-48CF-8CB4-C0B3E788C609@opencsw.org> Message-ID: No dia 1 de Setembro de 2010 09:45, Dagobert Michelsen escreveu: > Hi, > > Am 24.08.2010 um 17:34 schrieb Philip Brown: >> >> On Tue, Aug 24, 2010 at 6:19 AM, Ben Walton wrote: >>> >>> Excerpts from Philip Brown's message of Tue Aug 24 09:09:18 -0400 2010: >>> >>>> thats fine an all, for "external" files... but at the same time, it >>>> doesn't make much sense to be running checksums on files which are >>>> kept in our subversion repository >>> >>> This would be an easy fix, as we'd simply drop $(PATCHFILES) from the >>> $(CHECKSUMFILES) variable, leaving only the tarballs/source files... >> >> Would that catch (or rather , skip!) things such as the cswclassutils >> files.. which are not strictly "patches", yet are not downloaded >> either? > > I have now made a very simple change to GAR, which excludes things in files/ > from checksumming. These files are usually in the repository and don't need > checksumming. All files pulled in from anywhere else are still checksummed. > See the change at > ?http://sourceforge.net/apps/trac/gar/changeset/10862 Yes, if anything in files/ would not match the repository, GAR would add the UNCOMMITTED tag. An operation equivalent to checksumming is still done in files/. From dam at opencsw.org Wed Sep 1 13:24:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 1 Sep 2010 13:24:56 +0200 Subject: [csw-maintainers] GAR and checksums In-Reply-To: References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> <56889906-15B9-48CF-8CB4-C0B3E788C609@opencsw.org> Message-ID: <1FCE5D05-0E79-4311-BDB2-BD9DC0AB6181@opencsw.org> Hi Maciej, Am 01.09.2010 um 10:51 schrieb Maciej (Matchek) Blizinski: >> I have now made a very simple change to GAR, which excludes things >> in files/ >> from checksumming. These files are usually in the repository and >> don't need >> checksumming. All files pulled in from anywhere else are still >> checksummed. >> See the change at >> http://sourceforge.net/apps/trac/gar/changeset/10862 > > Yes, if anything in files/ would not match the repository, GAR would > add the UNCOMMITTED tag. An operation equivalent to checksumming is > still done in files/. Correct. You don't need to do "gmake makesums" for changes in files/, but you still need to commit. And commit will _not_ be optional ;-) Best regards -- Dago From phil at bolthole.com Fri Sep 3 01:56:38 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 2 Sep 2010 16:56:38 -0700 Subject: [csw-maintainers] note on using installf Message-ID: For those who have already, or may in the future, use the "installf" command, either in "class action" scripts or otherwise: Please remember to use "installf -f" at the end of it! This is mentioned, and demonstrated in the manpage. but apparently, we are forgetting to do it. The same applies for "removef" From maciej at opencsw.org Fri Sep 3 13:41:28 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 3 Sep 2010 12:41:28 +0100 Subject: [csw-maintainers] note on using installf In-Reply-To: References: Message-ID: No dia 3 de Setembro de 2010 00:56, Philip Brown escreveu: > For those who have already, or may in the future, use the "installf" command, > either in "class action" scripts or otherwise: > Please remember to use "installf -f" at the end of it! To clarify, by 'it' Phil refers to the whole class action script, not an individual installf invocation. You could derive it from the context, but I wanted to make it explicit. From bonivart at opencsw.org Fri Sep 3 16:03:28 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 3 Sep 2010 16:03:28 +0200 Subject: [csw-maintainers] Fwd: [csw-pkgsubmissions] newpkgs pm_podescapes In-Reply-To: References: Message-ID: Sorry for top-posting, background below. CSWpmpodescapes only has three packages that depend on it, two of them (CSWpmpodsimple and CSWmailscanner) are mine and already rebuilt without it. The third one is an orphaned package from Cory, CSWsvk which I have also rebuilt without this dep. CSWsvk and CSWpmpodsimple are now also up to date, also respun a new version of pm_svnmirror to make CSWsvk happy. If this is ok I will submit these four and you can remove CSWpmpodescapes. -- /peter ---------- Forwarded message ---------- From: Philip Brown Date: Fri, Sep 3, 2010 at 12:36 AM Subject: Re: [csw-pkgsubmissions] newpkgs pm_podescapes To: pkgsubmissions at lists.opencsw.org On 9/2/10, Peter Bonivart wrote: > On Thu, Sep 2, 2010 at 8:18 PM, Philip Brown wrote: >> FYI there's a problem with pm_podescapes. >> >> ERROR 1062 (23000) at line 8: Duplicate entry >> '/opt/csw/share/man/man3/Pod::Escapes.3perl' for key 1 >> >> >> It's also in perldoc. >> >> So please either submit an updated perldoc, or remove from podescapes > > First I went to fix this by removing the man page from podescapes but > when I took a closer look I see that 5.10.1 (CSWperl) already contains > the latest podescapes (1.04 from 2004-05-07) so I see no need for this > package at all. > > How to proceed now? > well, if Perldoc is part of official 5.10.1 perl, then just officially request that the package be removed and marked as obsolete. "official", in this case, is probably best pursued as "email the maintainers list", so it gets archived properly. From phil at bolthole.com Fri Sep 3 21:58:53 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Sep 2010 12:58:53 -0700 Subject: [csw-maintainers] Fwd: [csw-pkgsubmissions] newpkgs pm_podescapes In-Reply-To: References: Message-ID: On 9/3/10, Peter Bonivart wrote: > Sorry for top-posting, background below. > > CSWpmpodescapes only has three packages that depend on it, two of them > (CSWpmpodsimple and CSWmailscanner) are mine and already rebuilt > without it. The third one is an orphaned package from Cory, CSWsvk > which I have also rebuilt without this dep. > > CSWsvk and CSWpmpodsimple are now also up to date, also respun a new > version of pm_svnmirror to make CSWsvk happy. > > If this is ok I will submit these four and you can remove CSWpmpodescapes. > > -- > /peter > > ---------- Forwarded message ---------- > From: Philip Brown > Date: Fri, Sep 3, 2010 at 12:36 AM > Subject: Re: [csw-pkgsubmissions] newpkgs pm_podescapes > To: pkgsubmissions at lists.opencsw.org > > > On 9/2/10, Peter Bonivart wrote: >> On Thu, Sep 2, 2010 at 8:18 PM, Philip Brown wrote: >>> FYI there's a problem with pm_podescapes. >>> >>> ERROR 1062 (23000) at line 8: Duplicate entry >>> '/opt/csw/share/man/man3/Pod::Escapes.3perl' for key 1 >>> >>> >>> It's also in perldoc. >>> >>> So please either submit an updated perldoc, or remove from podescapes >> >> First I went to fix this by removing the man page from podescapes but >> when I took a closer look I see that 5.10.1 (CSWperl) already contains >> the latest podescapes (1.04 from 2004-05-07) so I see no need for this >> package at all. >> >> How to proceed now? >> > > well, if Perldoc is part of official 5.10.1 perl, then just officially > request that the package be removed and marked as obsolete. > "official", in this case, is probably best pursued as "email the > maintainers list", so it gets archived properly. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Fri Sep 3 21:59:42 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Sep 2010 12:59:42 -0700 Subject: [csw-maintainers] Fwd: [csw-pkgsubmissions] newpkgs pm_podescapes In-Reply-To: References: Message-ID: On 9/3/10, Philip Brown wrote: > On 9/3/10, Peter Bonivart wrote: >> CSWpmpodescapes only has three packages that depend on it, two of them >> (CSWpmpodsimple and CSWmailscanner) are mine and already rebuilt >> without it. The third one is an orphaned package from Cory, CSWsvk >> which I have also rebuilt without this dep. >> >> CSWsvk and CSWpmpodsimple are now also up to date, also respun a new >> version of pm_svnmirror to make CSWsvk happy. >> >> If this is ok I will submit these four and you can remove >> CSWpmpodescapes. >> Sounds good to me. From phil at bolthole.com Sat Sep 4 00:02:09 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Sep 2010 15:02:09 -0700 Subject: [csw-maintainers] supported configuration for zones: inherit-pkg-dir only Message-ID: FYI: Due to a recent bug report, I am updating the wiki page http://www.opencsw.org/use-it/sharing-optcsw/ to state that our "officially supported" deployment of packages to zones, IF you pkgadd them from the global, is to use /opt/csw as "inherit-pkg-dir" in the zone configs. I'm being a little premature in writing this up without a lengthy discussion... however, this is important enough that I dont want to forget to go back and write it up later. Please feel free to discuss now, though, and if people come up with good reasons to the contrary, I'll rewrite the page as suitable. The bugid in question is: https://www.opencsw.org/mantis/view.php?id=4538 From dam at opencsw.org Sat Sep 4 21:42:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 4 Sep 2010 21:42:36 +0200 Subject: [csw-maintainers] Hardware maintenance tomorrow References: Message-ID: <1C3AE9CB-44B2-438C-A36B-5281041DEB79@opencsw.org> Fellow buildfarm users, tomorrow will be a downtime of the buildfarm for hardware maintenance. It will start in roughly 12 hours (about 10 AM MET) and hopefully last a few hours. Sorry for the inconvenience -- Dago PS: If you want to know what is going on please read on! Two weeks ago I had a hang of the external storage array (16 x 120 GB SATA-to-FC) when I tried to replace a failed disk. After powercycling the array and changing the disk I kept getting parity errors from ZFS from the array without bad blocks from a disk, which is a bad sign, typically a memory problem on the array controller. Tomorrow the array will be replaced by 4 x 1 TB 2,5" SATA internal disks. From dam at opencsw.org Sun Sep 5 15:40:20 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 5 Sep 2010 15:40:20 +0200 Subject: [csw-maintainers] Buildfarm is available again Message-ID: Hi, the buildfarm is available again. The resilvering will take another day, so please take that into consideration if you measure disk performance. Please let me know if you encounter anything strange. Sorry for the inconvenience -- Dago From bonivart at opencsw.org Mon Sep 6 17:02:24 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 6 Sep 2010 17:02:24 +0200 Subject: [csw-maintainers] Fwd: [csw-pkgsubmissions] newpkgs pm_podescapes In-Reply-To: References: Message-ID: On Fri, Sep 3, 2010 at 9:59 PM, Philip Brown wrote: > On 9/3/10, Philip Brown wrote: >> On 9/3/10, Peter Bonivart wrote: >>> CSWpmpodescapes only has three packages that depend on it, two of them >>> (CSWpmpodsimple and CSWmailscanner) are mine and already rebuilt >>> without it. The third one is an orphaned package from Cory, CSWsvk >>> which I have also rebuilt without this dep. >>> >>> CSWsvk and CSWpmpodsimple are now also up to date, also respun a new >>> version of pm_svnmirror to make CSWsvk happy. >>> >>> If this is ok I will submit these four and you can remove >>> CSWpmpodescapes. > > Sounds good to me. I have now submitted the four packages so nothing should depend on CSWpmpodescapes any more. Please remove it from the catalog. -- /peter From bonivart at opencsw.org Mon Sep 6 23:46:22 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 6 Sep 2010 23:46:22 +0200 Subject: [csw-maintainers] New mirror added in Sweden - SUNET Message-ID: I have gotten us a new mirror in Sweden hosted by SUNET. SUNET is short for Swedish University Computer Network, they were pioneers of internet in Sweden and have a huge capacity. We can expect good speeds from this mirror when connected through any Swedish ISP. General information: http://www.sunet.se/English/Home.html The archive: http://ftp.sunet.se/index.html Direct links to the OpenCSW mirror: http://ftp.sunet.se/pub/vendor/sun/OpenCSW/, ftp://ftp.sunet.se/pub/vendor/sun/OpenCSW/ Happy downloading! -- /peter From dam at opencsw.org Sat Sep 4 21:22:21 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 4 Sep 2010 21:22:21 +0200 Subject: [csw-maintainers] [buildfarm-announce] Hardware maintenance tomorrow Message-ID: Fellow buildfarm users, tomorrow will be a downtime of the buildfarm for hardware maintenance. It will start in roughly 12 hours (about 10 AM MET) and hopefully last a few hours. Sorry for the inconvenience -- Dago PS: If you want to know what is going on please read on! Two weeks ago I had a hang of the external storage array (16 x 120 GB SATA-to-FC) when I tried to replace a failed disk. After powercycling the array and changing the disk I kept getting parity errors from ZFS from the array without bad blocks from a disk, which is a bad sign, typically a memory problem on the array controller. Tomorrow the array will be replaced by 4 x 1 TB 2,5" SATA internal disks. _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From dam at opencsw.org Fri Sep 10 14:12:57 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 10 Sep 2010 14:12:57 +0200 Subject: [csw-maintainers] checkpkg very slow on new internal disks Message-ID: Hi, there is something strange going on: checkpkg runs very slow on the internal disks. Of course these are not expected to be superfast, but as the ARC is now twice as large as before and I disabled atime and ZIL I would imagine disk performance wouldn't hurt that much. Maciej: is checkpkg doing some synchronous database operations? If yes, these should be disabled. Best regards -- Dago From dam at opencsw.org Fri Sep 10 15:51:51 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 10 Sep 2010 15:51:51 +0200 Subject: [csw-maintainers] Again downtime of OpenCSW buildfarm on monday Message-ID: <03F6BCBF-4613-4D00-A6BF-71F42CBDC234@opencsw.org> Fellow buildfarm users, I am very unhappy to be forced to announce another downtime of the buildfarm on the evening of monday, 13th (3 days from now). The homedirectories on the new local disks is too slow due to the I/O of specific buildjobs, so we will try some hopefully faster configuration and update to Solaris 10u9 during this opportunity. Sorry for the inconvenience -- Dago From gadavis at opencsw.org Fri Sep 10 18:56:46 2010 From: gadavis at opencsw.org (Geoff Davis) Date: Fri, 10 Sep 2010 09:56:46 -0700 Subject: [csw-maintainers] Revisiting the GCC4 Undefined symbol __sync_fetch_and_add_4 nonsense Message-ID: <4C8A634E.8030803@opencsw.org> Hi all, I'm battling with a program called NetCDF that can't be compiled under Sun Studio due to problems with the redistribution of the Fortran to C libraries. I'm attempting to compile under GCC4, but I'm getting a link error in the C++ bindings where it starts looking for a symbol called __sync_fetch_and_add_4. I'm on a Sparc system, so this of course fails. Roger mentioned that he tweaked the compiler options for GCC4 from -mcpu=v8 to -m32. I tried this but checkpackage whined that all of my binaries and libraries were compiled for v8+ instead of v8 and wanted them in arch-specific sub directories. Has anyone found the magic set of GCC4 options to make C++ work properly on Sparc in a fashion that generates pure sparcv8 libraries? Or should I just put in ignores for checkpackage and release the v8+ binaries instead of the v8 ones? Package Makefile in question is https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/netcdf/branches/gar-fortran/Makefile Also, I haven't been able to get ahold of Ihsan recently. I actually sent a couple of emails to this list last Friday, September 3, but they never posted. I'm trying to use the mail.opencsw.org SMTP server instead of my work SMTP box in case there is some weird interaction there. Thanks, Geoff From bonivart at opencsw.org Mon Sep 13 11:13:57 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 13 Sep 2010 11:13:57 +0200 Subject: [csw-maintainers] Updates not pushed? Message-ID: I checked the list of updates for my own packages and it's not correct: mailscanner:4.81.4.1,REV=2010.09.06 - A Free Anti-Virus and Anti-Spam Filter OK. pm_podsimple:3.14,REV=2010.09.08 - Pod-Simple: Framework for parsing Pod Not there, just old pm_podsimple-3.07,REV=2009.03.25. pm_svnmirror:0.75,REV=2010.09.03 - SVN-Mirror: Mirror remote repository to local Subversion repository OK. svk:2.2.3,REV=2010.09.03 - SVK: A distributed version control system OK. Also, pm_podescapes is not removed. -- /peter From dam at opencsw.org Mon Sep 13 17:37:52 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 13 Sep 2010 17:37:52 +0200 Subject: [csw-maintainers] Maintenance starts Message-ID: <2D69D1E4-D824-40E7-B6E5-AEAD0177D355@opencsw.org> Hi, as I announced I'll start now patching the machines to fix the issues with the internal disks. Sorry for the inconvenience -- Dago From phil at bolthole.com Mon Sep 13 18:44:18 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 13 Sep 2010 09:44:18 -0700 Subject: [csw-maintainers] Updates not pushed? In-Reply-To: References: Message-ID: Yup, wasnt pushed yet. I was waiting for a few more to trickle in as usual, before pushing. It was a surprisingly slow weekend :) From dam at opencsw.org Mon Sep 13 22:43:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 13 Sep 2010 22:43:59 +0200 Subject: [csw-maintainers] Buildfarm update almost finished Message-ID: <26AE7C9B-AD96-4E8C-B450-882A3F58E3AA@opencsw.org> Hi, the buildfarm update is mostly done. There are still some patches being applied for Solaris 9 which may take some more hours and will require a reboot of the zones tomorrow. I'll keep you informed. Best regards -- Dago From dam at opencsw.org Tue Sep 14 09:51:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 14 Sep 2010 09:51:31 +0200 Subject: [csw-maintainers] Buildfarm update finally finished Message-ID: Fellow buildfarm users, the update is now finally done and the farm should be fully usable again. Please let me know if you encounter anything suspicious. Sorry for the inconvenience -- Dago From maciej at opencsw.org Thu Sep 16 12:35:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 16 Sep 2010 11:35:07 +0100 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <2FD57AEC-D3E7-4533-ACE7-3B0A351B6D13@opencsw.org> References: <2FD57AEC-D3E7-4533-ACE7-3B0A351B6D13@opencsw.org> Message-ID: No dia 12 de Dezembro de 2009 07:05, Dagobert Michelsen escreveu: > Hi Maciej, > > Am 12.12.2009 um 02:27 schrieb Maciej (Matchek) Blizinski: >> >> Suppose I have a file CSWfoo.postinstall, which has some variables >> which need to be substituted before the file can be shipped. >> Something along the lines of: >> >> mycommand=@bindir@/foo >> >> Is it possible to preprocess a postinstall file like that? ?At which >> stage should it be done? > > The natural place for this is in post-install-modulated. > However, you may also do it during post-merge or in a > custom-merge rule doing substitute-copy in one step. I'm seeing the postinstall file in these directories: work/solaris9-sparc/build-isa-sparcv8/CSWpostgresql-84.postinstall work/solaris9-sparc/build-global/CSWpostgresql-84.postinstall post-install-modulated looks like it's too late, these dirs are build dirs, aren't they? Shouldn't it be in post-build-modulated? From maciej at opencsw.org Thu Sep 16 18:17:28 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 16 Sep 2010 17:17:28 +0100 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <2FD57AEC-D3E7-4533-ACE7-3B0A351B6D13@opencsw.org> Message-ID: No dia 16 de Setembro de 2010 11:35, Maciej (Matchek) Blizinski escreveu: > No dia 12 de Dezembro de 2009 07:05, Dagobert Michelsen > escreveu: >> Hi Maciej, >> >> Am 12.12.2009 um 02:27 schrieb Maciej (Matchek) Blizinski: >>> >>> Suppose I have a file CSWfoo.postinstall, which has some variables >>> which need to be substituted before the file can be shipped. >>> Something along the lines of: >>> >>> mycommand=@bindir@/foo Dago, you asked why do I need to preprocess the file. Here's an example: # Read in the user configuration file [ -s /opt/csw/etc/postgresql.conf ] && . /opt/csw/etc/postgresql.conf [ -s @sysconfdir@/postgresql.conf ] && . @sysconfdir@/postgresql.conf # Defaults [ -z "${PGDATA}" ] && PGDATA=@PGDATA@ [ -z "${PGCTL}" ] && PGCTL=@bindir@/sparcv8/pg_ctl [ -z "${PGINIT}" ] && PGINIT=@bindir@/sparcv8/initdb I would like the script source to be identical for PostgreSQL 8.3 and 8.4 (and potentially 9.0). Of course, I could just hardcode the values. However, the bigger plan is to rework both 8.3 and 8.4 packages so that you can run both at the same time and migrate the data with minimal downtime. From dam at opencsw.org Thu Sep 16 21:23:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 16 Sep 2010 21:23:30 +0200 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <2FD57AEC-D3E7-4533-ACE7-3B0A351B6D13@opencsw.org> Message-ID: <9043386F-6061-409A-929D-222B3C904CA7@opencsw.org> Hi Maciej, Am 16.09.2010 um 18:17 schrieb Maciej (Matchek) Blizinski: > No dia 16 de Setembro de 2010 11:35, Maciej (Matchek) Blizinski > escreveu: >> No dia 12 de Dezembro de 2009 07:05, Dagobert Michelsen >> escreveu: >>> Hi Maciej, >>> >>> Am 12.12.2009 um 02:27 schrieb Maciej (Matchek) Blizinski: >>>> >>>> Suppose I have a file CSWfoo.postinstall, which has some variables >>>> which need to be substituted before the file can be shipped. >>>> Something along the lines of: >>>> >>>> mycommand=@bindir@/foo > > Dago, you asked why do I need to preprocess the file. Here's an > example: > > # Read in the user configuration file > [ -s /opt/csw/etc/postgresql.conf ] && . /opt/csw/etc/postgresql.conf > [ -s @sysconfdir@/postgresql.conf ] && . @sysconfdir@/postgresql.conf > > # Defaults > [ -z "${PGDATA}" ] && PGDATA=@PGDATA@ > [ -z "${PGCTL}" ] && PGCTL=@bindir@/sparcv8/pg_ctl > [ -z "${PGINIT}" ] && PGINIT=@bindir@/sparcv8/initdb > > I would like the script source to be identical for PostgreSQL 8.3 and > 8.4 (and potentially 9.0). Of course, I could just hardcode the > values. However, the bigger plan is to rework both 8.3 and 8.4 > packages so that you can run both at the same time and migrate the > data with minimal downtime. Ok, done in r10981: http://sourceforge.net/apps/trac/gar/changeset/10981 Let me know if you encounter anything strange. Best regards -- Dago From dam at opencsw.org Fri Sep 17 21:51:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 17 Sep 2010 21:51:10 +0200 Subject: [csw-maintainers] [csw-buildfarm] SUNWspro and libyabe.so In-Reply-To: <4C7E9F2D.7020804@pleiades.fr.eu.org> References: <4C7E9F2D.7020804@pleiades.fr.eu.org> Message-ID: Hi Yann, Am 01.09.2010 um 20:45 schrieb Yann Rouillard: > Dear buildfarm maintainers, > > I am currently trying to compile last openssl version and I am > running into the following error: > > [...] > making all in crypto... > gmake[3]: Entering directory `/home/yann/mgar/openssl/trunk/work/ > solaris9-sparc/build-isa-sparcv8/openssl-0.9.8o/crypto' > cc -I. -I.. -I../include -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS - > D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=v8 -xO5 -xstrconst - > xdepend -Xa -DB_ENDIAN -DBN_DIV2W -I/opt/csw/include -c -o > cryptlib.o cryptlib.c > ld.so.1: acomp: fatal: libyabe.so: open failed: No such file or > directory > cc: Fatal error in /opt/studio/SOS11/SUNWspro/prod/bin/acomp : Killed > gmake[3]: *** [cryptlib.o] Error 9 > gmake[3]: Leaving directory `/home/yann/mgar/openssl/trunk/work/ > solaris9-sparc/build-isa-sparcv8/openssl-0.9.8o/crypto' > gmake[2]: *** [build_crypto] Error 1 > gmake[2]: Leaving directory `/home/yann/mgar/openssl/trunk/work/ > solaris9-sparc/build-isa-sparcv8/openssl-0.9.8o' > gmake[1]: *** [build-work/solaris9-sparc/build-isa-sparcv8/ > openssl-0.9.8o/Makefile] Error 2 > gmake[1]: Leaving directory `/home/yann/mgar/openssl/trunk' > gmake: *** [merge-isa-sparcv8] Error 2 > > It seems to be related to SUNWspro so I am trying to know at your > door. > > Any idea what is the origin of this problem ? > > I saw the following pages on internet about libyabe.so: > http://hub.opensolaris.org/bin/view/Community+Group+ha-clusters/FAQ#buildingagents > http://forums.sun.com/thread.jspa?threadID=5071875 > > libyabe.so is present at: > /opt/SUNWspro/prod/lib/sys/libyabe.so > > I might add this path but I suppose there is something else wrong. I looked more into it and in fact Sun Studio 11 is broken at least on current9s. The installation is definitely broken and my guess is that it is due to my installation/removal order of SOS11/12/12u1, then remove and reinstall 12 again because of a faulty script not taking multi-instance-packages into account correctly. I am reinstall Sun Studio 11 on current9s now and fix the issue. BTW: I need SOS11 too for a libserf bump bound to the compilation of the Apache stack also compiled with SOS11 ATM. Best regards -- Dago From dam at opencsw.org Fri Sep 17 22:14:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 17 Sep 2010 22:14:31 +0200 Subject: [csw-maintainers] Sun Studio 11 is broken on current9s ATM In-Reply-To: References: <4C7E9F2D.7020804@pleiades.fr.eu.org> Message-ID: <7029BA0F-5BC3-4F60-AB41-BFAD7DD51F4D@opencsw.org> Hi, Am 17.09.2010 um 21:51 schrieb Dagobert Michelsen: > Am 01.09.2010 um 20:45 schrieb Yann Rouillard: >> Dear buildfarm maintainers, >> >> I am currently trying to compile last openssl version and I am >> running into the following error: >> >> [...] >> making all in crypto... >> gmake[3]: Entering directory `/home/yann/mgar/openssl/trunk/work/ >> solaris9-sparc/build-isa-sparcv8/openssl-0.9.8o/crypto' >> cc -I. -I.. -I../include -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS - >> D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=v8 -xO5 -xstrconst - >> xdepend -Xa -DB_ENDIAN -DBN_DIV2W -I/opt/csw/include -c -o >> cryptlib.o cryptlib.c >> ld.so.1: acomp: fatal: libyabe.so: open failed: No such file or >> directory >> cc: Fatal error in /opt/studio/SOS11/SUNWspro/prod/bin/acomp : Killed >> gmake[3]: *** [cryptlib.o] Error 9 >> gmake[3]: Leaving directory `/home/yann/mgar/openssl/trunk/work/ >> solaris9-sparc/build-isa-sparcv8/openssl-0.9.8o/crypto' >> gmake[2]: *** [build_crypto] Error 1 >> gmake[2]: Leaving directory `/home/yann/mgar/openssl/trunk/work/ >> solaris9-sparc/build-isa-sparcv8/openssl-0.9.8o' >> gmake[1]: *** [build-work/solaris9-sparc/build-isa-sparcv8/ >> openssl-0.9.8o/Makefile] Error 2 >> gmake[1]: Leaving directory `/home/yann/mgar/openssl/trunk' >> gmake: *** [merge-isa-sparcv8] Error 2 >> >> It seems to be related to SUNWspro so I am trying to know at your >> door. >> >> Any idea what is the origin of this problem ? >> >> I saw the following pages on internet about libyabe.so: >> http://hub.opensolaris.org/bin/view/Community+Group+ha-clusters/FAQ#buildingagents >> http://forums.sun.com/thread.jspa?threadID=5071875 >> >> libyabe.so is present at: >> /opt/SUNWspro/prod/lib/sys/libyabe.so >> >> I might add this path but I suppose there is something else wrong. > > I looked more into it and in fact Sun Studio 11 is broken at least > on current9s. The installation is definitely broken and my guess is > that it is due to my installation/removal order of SOS11/12/12u1, > then remove and reinstall 12 again because of a faulty script not > taking multi-instance-packages into account correctly. > > I am reinstall Sun Studio 11 on current9s now and fix the issue. > BTW: I need SOS11 too for a libserf bump bound to the compilation > of the Apache stack also compiled with SOS11 ATM. My guess was right: the try to remove/reinstall SOS11 corrupted the SOS12 installation, so there is a glitch in the scripts: ld: fatal: file /opt/SUNWspro/prod/lib/v9/crti.o: open failed: No such file or directory I guess I need to remove SOS12 also als then reinstall SOS11 and SOS12 without intermediate removal. Later I will inspect the compiler installations on the other machines... Sorry for the inconvenience -- Dago From dam at opencsw.org Sat Sep 18 17:14:57 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 18 Sep 2010 17:14:57 +0200 Subject: [csw-maintainers] Fwd: experimental catalogs broken? References: <5CCC83E8-8D5C-4244-8FB6-FF403A20BD6E@opencsw.org> Message-ID: Hi Ben, Am 18.09.2010 um 16:21 schrieb Ben Walton: > It seems that the personal experimental catalogs aren't working right > now. This looks to be as a result of the changes you made the other > day. Will they be coming back or am I simply looking in the wrong > spot now? > > I was trying to pull my updated ruby packages to a test box from: > http://mirror.opencsw.org/opencsw/experimental/bwalton/ Together with Ihsan we changed mirror.opencsw.org now to the primary mirror which ran only rsync in the past. I meant to announce this and set redirects from the previous mirror.* on the buildfarm, but not the new mirror.*. The new layout looks like this: * rsync.opencsw.org Primary in Erlangen just as before * mirror.opencsw.org Was on the buildfarm and is now also on the primary in Erlangen running HTTP for direct access. /experimental.html redirs to buildfarm.opencsw.org/experimental.html /opencsw/experimental/* redirects to buildfarm.opencsw.org/opencsw/ experimental/* * buildfarm.opencsw.org Now hosts /experimental.html /opencsw/* I also changed the link on the experimental page to http://buildfarm.opencsw.org/opencsw/experimental/... Just let me know if you encounter any other locations that should be adjusted. Best regards -- Dago From dam at opencsw.org Sun Sep 19 13:54:20 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 19 Sep 2010 13:54:20 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs mutt, mutt_base, mutt_ncurses, mutt_slang In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> Message-ID: Hi Phil, Am 18.09.2010 um 16:51 schrieb Philip Brown: > On Thursday, September 16, 2010, Dagobert Michelsen wrote: >> Am 17.09.2010 um 00:30 schrieb Philip Brown: >> >> Wouldnt it make sense to have the Muttrc, be a more cross-system >> 'global', than an individual one? >> If so, wouldnt it be better to keep it in /opt/csw/etc ? >> >> IMHO not. Having stuff in /opt/csw/etc is only good if there is >> no reason whatsoever to have zone-specific files. I can't see >> this is true in this case. > > I think we have to differentiate between "possible" and "reasonable". > > why would anyone reasonably change it for a zone? > I would think that would only happen on extreme cases. > > the reason I'm being particular about this, is that it would seem far > more likely to me for a site to want to have all machines deploy mutt > with the SAME configuration.(and I have had specific experience as a > site admin doing this with mutt ) > > Putting the default location in /etc makes that much more difficult. > whereas if you put the default in /opt/csw/etc, they could make it a > symlink, in the unlikely event they wanted zones to be different Either way, by symlinking /etc/opt/csw/muttrc to /opt/csw/etc/muttrc or vice versa you can have the desired behaviour. That being said I would value consistency higher than to select where configs are put on a package-by-package basis. And as we have decided with /etc/opt/csw as default for configurations I think it is better to put everything in there as you can still link back if you need it. Best regards -- Dago From dam at opencsw.org Sat Sep 18 07:46:22 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 18 Sep 2010 07:46:22 +0200 Subject: [csw-maintainers] [buildfarm-announce] Fwd: [csw-buildfarm] Latest libffi/libffidevel on build servers References: <1284766806-sup-3533@pinkfloyd.chass.utoronto.ca> Message-ID: <5DFBCD19-C953-4DB1-8B44-F2AA6803F12D@opencsw.org> Hi Jens, Anfang der weitergeleiteten E-Mail: >> I'm trying to build the latest version of Ruby (1.9.2 p0) and am >> running into a compiler issue related to libffi headers. The fix >> appears to be in libffi 3.0.9 (which is in svn), but the build >> servers still have 3.0.8. Would it be possible to update the build >> servers to the latest libffi/libffidevel (3.0.9)? > > The policy is that the buildfarm (current* boxen) only get packages > available from the current catalog. There are testing* boxen that we > can use to put things from experimental into play when required. > > When you say that 3.0.9 is in svn, do that mean there is an updated > GAR recipe for it? If so, the best approach is to ping the > maintainer[1] > for an update and if there's no active maintainer, take it over! :) > > HTH. > -Ben > > [1] In this case, Mike Watters is on 'sabbatical' so you'd be best to > roll the updated package yourself. As Roger already built libffi 3.0.9 and put it into testing I suggest you respin the package, we install it on a testing-machine and you release it after verification. Then it gets installed on the current* machines and you can proceed. Best regards -- Dago _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From dam at opencsw.org Sun Sep 19 17:07:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 19 Sep 2010 17:07:35 +0200 Subject: [csw-maintainers] Our primary and comment strings on rsync Message-ID: Hi, I just added comment strings on rsync: > opencsw-rsync# rsync rsync://localhost > csw CSW Primary Mirror, use this if you are mirroring OpenCSW > opencsw The same as 'csw', use this if you prefer the full project name as source > opencsw-future The proposed future layout of the OpenCSW Primary, layout may change without notice at any time I added "opencsw" as some mirrors refer to us as "opencsw", so it may be good to long term move to the more specific term. Additionally, I activated lighttpd and Ihsan moved the mirror alias to rsync, so we have now our own primary mirror at http://mirror.opencsw.org There are now nice access stats yet, just access logs. There are also automatic monthly snapshots at http://mirror.opencsw.org/opencsw-future/snapshots/ and an archive of all released packages: http://mirror.opencsw.org/opencsw-future/allpkgs/ Additionally, the changes between the snapshots is calculated and viewed for each catalog, e.g.: http://mirror.opencsw.org/opencsw-future/unstable/sparc/5.9/ Next I plan to add descriptive text on that URL about available mirrors, mirror status and how to become a mirror. Feedback very welcome! Best regards -- Dago From james at opencsw.org Mon Sep 20 10:46:49 2010 From: james at opencsw.org (James Lee) Date: Mon, 20 Sep 2010 08:46:49 GMT Subject: [csw-maintainers] Board election method In-Reply-To: References: Message-ID: <20100920.8464900.2150801284@gyor.oxdrove.co.uk> On 31/08/10, 11:17:17, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Board election method: > We need elect a new board. Previously, the election has been done in > person, but this time it needs to be done remotely, which will require > a new voting method. We need to choose a method of voting then, which > begs a question: What voting method will we use to decide on the > voting method? > We could use the Concordet voting system. We could also use an > external site, such as [2]. I've also created a package with > debian-vote, an implementation of the Concordet system, the package is > available from experimental[3]. The OpenCSW Bylaws state "Board members are elected by the general meeting", "Each voting member has one vote", and "The president decides in case of a tie", "The board decides about the procedure of such votes." etc. Should you wish to change the voting method see section 8 "Changing the Bylaws". James. From bonivart at opencsw.org Mon Sep 20 10:50:44 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 20 Sep 2010 10:50:44 +0200 Subject: [csw-maintainers] Fwd: experimental catalogs broken? In-Reply-To: References: <5CCC83E8-8D5C-4244-8FB6-FF403A20BD6E@opencsw.org> Message-ID: On Sat, Sep 18, 2010 at 5:14 PM, Dagobert Michelsen wrote: > Just let me know if you encounter any other locations that should be > adjusted. On the page http://mirror.opencsw.org/ the mirror status link (Global Mirrors Status - http://mirror.opencsw.org/mirror/status/) is broken. -- /peter From dam at opencsw.org Mon Sep 20 11:03:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 20 Sep 2010 11:03:43 +0200 Subject: [csw-maintainers] Fwd: experimental catalogs broken? In-Reply-To: References: <5CCC83E8-8D5C-4244-8FB6-FF403A20BD6E@opencsw.org> Message-ID: <6EF2D8B6-16E8-44A1-A562-79E3246F9322@opencsw.org> Hi Peter, Am 20.09.2010 um 10:50 schrieb Peter Bonivart: > On Sat, Sep 18, 2010 at 5:14 PM, Dagobert Michelsen > wrote: >> Just let me know if you encounter any other locations that should be >> adjusted. > > On the page http://mirror.opencsw.org/ the mirror status link I guess you have a outdated cached copy, please try reloading. > (Global > Mirrors Status - http://mirror.opencsw.org/mirror/status/) is broken. That was proxied to http://www.canoedissent.org.uk/mirror/status/ I would like to move that status directly to the mirror page in the future. For now there is no proxying as the proxying features from lighttpd are less capable than Apaches and I need lighttpd for package download due to performance issues on the machine. Best regards -- Dago From phil at bolthole.com Mon Sep 20 21:10:37 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 20 Sep 2010 12:10:37 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs mutt, mutt_base, mutt_ncurses, mutt_slang In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> Message-ID: On 9/19/10, Dagobert Michelsen wrote: > Hi Phil, > > Am 18.09.2010 um 16:51 schrieb Philip Brown: >... >> the reason I'm being particular about this, is that it would seem far >> more likely to me for a site to want to have all machines deploy mutt >> with the SAME configuration.(and I have had specific experience as a >> site admin doing this with mutt ) >> >> Putting the default location in /etc makes that much more difficult. >> whereas if you put the default in /opt/csw/etc, they could make it a >> symlink, in the unlikely event they wanted zones to be different > > Either way, by symlinking /etc/opt/csw/muttrc to /opt/csw/etc/muttrc or > vice versa you can have the desired behaviour. That has the same behaviour for an end user, but not for sysadmin. If you say the default is /etc/opt/csw/muttrc, and you then require to symlink back to /opt/csw/etc for supporting a single global config.. the admin then has to hit Every Single Machine, and make that symlink. That can be irritating to maintain, for a site that is centered around global configurations, like a simple shared /opt/csw *our* "user" is the sysadmin, and we are supposed to be making things easier for "our users". > That being said I would > value consistency higher than to select where configs are put on a > package-by-package basis. And as we have decided with /etc/opt/csw as > default for configurations I think it is better to put everything in > there as you can still link back if you need it. "consistency" does not mean "no exceptions". Also, I believe that there was still agreed support for global, non-/etc/opt configurations, *IF* it makes more sense. So then the question is, does it make more sense? Do you agree, or disagree, with my premise, that it is "[far more] likely ...for a site to want to have all machines deploy mutt with the SAME configuration." If you, and/or other who are regular mutt admins, can honestly say that it is now more likely to have machine-unique mutt configs, then I'll let this go. However, I'm skeptical that things have changed that much since last I was a sysadmin for mutt. From gadavis at opencsw.org Mon Sep 20 21:40:04 2010 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 20 Sep 2010 12:40:04 -0700 Subject: [csw-maintainers] old gcc4* packages in catalog In-Reply-To: References: <1275352845-sup-6422@pinkfloyd.chass.utoronto.ca> Message-ID: <3AC3D9EA-F656-4658-8981-18C823D1B2C7@opencsw.org> Hi all, dragging this one back from the dead: the presence of these obsolete packages on the build farm is causing me problems when I try to build software with the Fortran compilers. Can we either remove gcc4g95 and gcc4g95_rt from the build farm systems or push out the stub packages that Phil propsed below? The problems with gcc4g95 and gcc4g95_rt are documented here: http://lists.opencsw.org/pipermail/users/2009-August/008350.html On Jun 7, 2010, at 11:52 AM, Peter FELECAN wrote: > Philip Brown writes: > >> On Mon, Jun 7, 2010 at 10:25 AM, Peter FELECAN wrote: >>> Philip Brown writes: >>> >>>> okay. well someone please submit an empty packed of the new one that >>>> depends on the old one >>> >> oops. I mistyped. (durn iphone! yeah, that's it...) > > Are you following the WWDC announcement? > >> I meant submit old, empty package that depends on new one. >> make gcc4g95 pull in gcc4gfortran. > > Yup. > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From dam at opencsw.org Mon Sep 20 22:06:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 20 Sep 2010 22:06:06 +0200 Subject: [csw-maintainers] old gcc4* packages in catalog In-Reply-To: <3AC3D9EA-F656-4658-8981-18C823D1B2C7@opencsw.org> References: <1275352845-sup-6422@pinkfloyd.chass.utoronto.ca> <3AC3D9EA-F656-4658-8981-18C823D1B2C7@opencsw.org> Message-ID: Hi Geoff, Am 20.09.2010 um 21:40 schrieb Geoff Davis: > dragging this one back from the dead: the presence of these obsolete > packages on the build farm is causing me problems when I try to > build software with the Fortran compilers. Can we either remove > gcc4g95 and gcc4g95_rt from the build farm systems Sure, done. > On Jun 7, 2010, at 11:52 AM, Peter FELECAN wrote: >> Philip Brown writes: >>> On Mon, Jun 7, 2010 at 10:25 AM, Peter FELECAN >>> wrote: >>>> Philip Brown writes: >>>>> okay. well someone please submit an empty packed of the new one >>>>> that >>>>> depends on the old one >>>> >>> oops. I mistyped. (durn iphone! yeah, that's it...) >> >> Are you following the WWDC announcement? >> >>> I meant submit old, empty package that depends on new one. >>> make gcc4g95 pull in gcc4gfortran. >> >> Yup. > > or push out the stub packages that Phil propsed below? > > The problems with gcc4g95 and gcc4g95_rt are documented here: http://lists.opencsw.org/pipermail/users/2009-August/008350.html Peter, you offered to update gcc4 during the Summercamp. Do you have a timeframe when it may be ready? Best regards -- Dago From dam at opencsw.org Mon Sep 20 22:08:29 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 20 Sep 2010 22:08:29 +0200 Subject: [csw-maintainers] Unable to compile Ruby binding for Subversion Message-ID: <496B94C3-6388-4489-9E29-B96AB80C2E2E@opencsw.org> Hi, I am trying to bump Subversion to 1.6.12 and get the following error when compiling the Ruby bindings: > ==> Building Ruby bindings > touch work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.12/ > subversion/bindings/swig/ruby/*.c > prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" > sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/ > csw/share" sysconfdir="/opt/csw/etc" sharedstatedir="/opt/csw/share" > localstatedir="/opt/csw/var" libdir="/opt/csw/lib" infodir="/opt/csw/ > share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/ > opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/ > doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/apache2/include - > I/opt/csw/include" CFLAGS="-xO3 -m32 -xarch=v8 -xnorunpath" > CXXFLAGS="-xO3 -m32 -xarch=v8 -norunpath" LDFLAGS="-m32 -xarch=v8 - > norunpath -L/opt/csw/apache2/lib -L/opt/csw/bdb48/lib -L/opt/csw/lib/ > svn -L/opt/csw/lib -lintl -liconv" ASFLAGS="" OPTFLAGS="-xO3 -m32 - > xarch=v8 -xnorunpath" CC="/opt/SUNWspro/bin/cc" CXX="/opt/SUNWspro/ > bin/CC" CC_HOME="/opt/SUNWspro" CC_VERSION="Sun C 5.9 SunOS_sparc > Patch 124867-16 2010/08/11" CXX_VERSION="Sun C++ 5.9 SunOS_sparc > Patch 124863-25 2010/08/24" GARCH="sparc" GAROSREL="5.9" > GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/apache2/lib -R/opt/csw/ > bdb48/lib/\$ISALIST -R/opt/csw/bdb48/lib -R/opt/csw/lib/svn -R/opt/ > csw/lib/\$ISALIST -R/opt/csw/lib" gmake -C work/solaris9-sparc/build- > isa-sparcv8/subversion-1.6.12 swig-rb > gmake[2]: Entering directory `/home/dam/mgar/pkg/subversion/trunk/ > work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.12' > /bin/bash /home/dam/mgar/pkg/subversion/trunk/work/solaris9-sparc/ > build-isa-sparcv8/subversion-1.6.12/libtool --tag=CC --silent -- > mode=compile none -I/opt/csw/apache2/include -I/opt/csw/include - > DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT - > D_LARGEFILE64_SOURCE -I/home/dam/mgar/pkg/subversion/trunk/work/ > solaris9-sparc/build-isa-sparcv8/subversion-1.6.12/subversion/ > bindings/swig/ruby/libsvn_swig_ruby -prefer-pic -c -o subversion/ > bindings/swig/ruby/svn_client.lo subversion/bindings/swig/ruby/ > svn_client.c > /home/dam/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa- > sparcv8/subversion-1.6.12/libtool: none: command not found > gmake[2]: *** [subversion/bindings/swig/ruby/svn_client.lo] Error 1 > gmake[2]: Leaving directory `/home/dam/mgar/pkg/subversion/trunk/ > work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.12' > gmake[1]: *** [svn-ruby] Error 2 > gmake[1]: Leaving directory `/home/dam/mgar/pkg/subversion/trunk' > gmake: *** [merge-isa-sparcv8] Error 2 I find "none" pretty suspicious. Ben, do you have a clue why this is happening? Best regards -- Dago From bwalton at opencsw.org Tue Sep 21 01:45:43 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 20 Sep 2010 19:45:43 -0400 Subject: [csw-maintainers] old gcc4* packages in catalog In-Reply-To: References: <1275352845-sup-6422@pinkfloyd.chass.utoronto.ca> <3AC3D9EA-F656-4658-8981-18C823D1B2C7@opencsw.org> Message-ID: <1285026247-sup-7033@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Sep 20 16:06:06 -0400 2010: > Peter, you offered to update gcc4 during the Summercamp. Do you have > a timeframe when it may be ready? I took a whack at this a few months back and got stuck on dependency update requirements. libmpfr iirc. My memory is hazy on this, but I believe it built fine but wasn't passing all of the tests...I had meant to get back to it but haven't had time yet. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Sep 21 01:52:45 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 20 Sep 2010 19:52:45 -0400 Subject: [csw-maintainers] Unable to compile Ruby binding for Subversion In-Reply-To: <496B94C3-6388-4489-9E29-B96AB80C2E2E@opencsw.org> References: <496B94C3-6388-4489-9E29-B96AB80C2E2E@opencsw.org> Message-ID: <1285026676-sup-2518@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Sep 20 16:08:29 -0400 2010: Hi Dago, > > /home/dam/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa- > > sparcv8/subversion-1.6.12/libtool: none: command not found > > gmake[2]: *** [subversion/bindings/swig/ruby/svn_client.lo] Error 1 > > gmake[2]: Leaving directory `/home/dam/mgar/pkg/subversion/trunk/ > > work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.12' > I find "none" pretty suspicious. Ben, do you have a clue why this is > happening? I bet this is due to the SOS12 path change. I've placed updated packages in my experimental catalog that have the proper path embedded now. I haven't even done a test install, but on such a small change, I may as well just fire them at release. Please stand by. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Sep 21 11:27:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 21 Sep 2010 11:27:06 +0200 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: <4AC1194A.3040308@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> Message-ID: <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> Hi, we have come a long way. I just reviewed the descriptions at http://www.opencsw.org/get-it/ and this way too complex for a simple task. It should IMHO better read * pkg-get: pkgadd -d http://mirror.opencsw.org/opencsw/pkg-get.pkg /opt/csw/bin/pkg-get -i * pkgutil: pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil.pkg /opt/csw/bin/pkgutil -i After reviewing the discussion I really think the argument of "uglyness" about having two wgets must stand back if it allows just one line of installation. Best regards -- Dago PS: This was the initial thread I was referring to: Am 28.09.2009 um 22:15 schrieb Sebastian Kayser: > Dagobert Michelsen wrote on 28.09.2009 21:16: >> Am 28.09.2009 um 21:12 schrieb Sebastian Kayser: >>> pkgutil was placed straight at the mirror root a while ago to >>> facilitate >>> downloading, but it doesn't seem to get updates. The version >>> floating >>> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please >>> be >>> fixed (and be kept in sync in the future pleeeaase :). >>> >>> Furthermore, could pkgutil be made an ARCH=all package, so that >>> there is >>> just _one_ direct link that one can point new users to and not a >>> platform specific one (i know about uname -p, still it just makes >>> things >>> more straightforward)? >>> >>> I see, the package contains a wget which is platform specific. >>> Couldn't >>> we just include two wgets (wget.i386, wget.sparc)? From what i >>> remember, >>> that is the same approach Sun uses for its explorer package. >> >> This was Peters intent, but Phil argued strongly against having >> ARCHALL=1 >> packages with arch-specific binaries. See the thread for details: >> >> > > Wow, that's a huge discussion. I couldn't resist thinking about our > motto (while reading): > > "to provide a straightforward, easy-to-use experience for the user" > > pkgutil is one out of two possible packages of ours that a user comes > across first. While i see that there is a need to decide about what > should be an ARCH=all package, i don't really see the need to make an > example of pkgutil (considering that one could argue both ways). :/ From pfelecan at opencsw.org Tue Sep 21 12:27:48 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 21 Sep 2010 12:27:48 +0200 Subject: [csw-maintainers] old gcc4* packages in catalog In-Reply-To: <1285026247-sup-7033@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Mon, 20 Sep 2010 19:45:43 -0400") References: <1275352845-sup-6422@pinkfloyd.chass.utoronto.ca> <3AC3D9EA-F656-4658-8981-18C823D1B2C7@opencsw.org> <1285026247-sup-7033@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Dagobert Michelsen's message of Mon Sep 20 16:06:06 -0400 2010: > >> Peter, you offered to update gcc4 during the Summercamp. Do you have >> a timeframe when it may be ready? No time frame yet. -- Peter From phil at bolthole.com Tue Sep 21 17:56:26 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 21 Sep 2010 08:56:26 -0700 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> Message-ID: On 9/21/10, Dagobert Michelsen wrote: > Hi, > > we have come a long way. I just reviewed the descriptions at > http://www.opencsw.org/get-it/ > and this way too complex for a simple task. It should IMHO > better read > > * pkg-get: pkgadd -d http://mirror.opencsw.org/opencsw/pkg-get.pkg > /opt/csw/bin/pkg-get -i > * pkgutil: pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil.pkg > /opt/csw/bin/pkgutil -i > > After reviewing the discussion I really think the argument > of "uglyness" about having two wgets must stand back if it > allows just one line of installation. > It's unclear, but I think you are suggesting to still roll wget binaries into pkgutil, but lie and claim ARCH=all. I would counter that this is unneccessary. If the directions are going to presume solaris 10 (since only that allows pkgadd over url directly), then it is equally reasonable to presume that the user already has wget installed in /usr/sfw/bin, and there is no need for pkgutil to bundle wget in the first place. Then it will be cleanly ARCH=all , and there is no longer an issue there. From gmarler at opencsw.org Tue Sep 21 18:20:37 2010 From: gmarler at opencsw.org (Gordon Marler) Date: Tue, 21 Sep 2010 12:20:37 -0400 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> Message-ID: <4C98DB55.7090807@opencsw.org> On 09/21/2010 11:56 AM, Philip Brown wrote: > On 9/21/10, Dagobert Michelsen wrote: > >> Hi, >> >> we have come a long way. I just reviewed the descriptions at >> http://www.opencsw.org/get-it/ >> and this way too complex for a simple task. It should IMHO >> better read >> >> * pkg-get: pkgadd -d http://mirror.opencsw.org/opencsw/pkg-get.pkg >> /opt/csw/bin/pkg-get -i >> * pkgutil: pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil.pkg >> /opt/csw/bin/pkgutil -i >> >> After reviewing the discussion I really think the argument >> of "uglyness" about having two wgets must stand back if it >> allows just one line of installation. >> >> > It's unclear, but I think you are suggesting to still roll wget > binaries into pkgutil, but lie and claim ARCH=all. > > I would counter that this is unneccessary. > If the directions are going to presume solaris 10 (since only that > allows pkgadd over url directly), then it is equally reasonable to > presume that the user already has wget installed in /usr/sfw/bin, and > there is no need for pkgutil to bundle wget in the first place. > >From site to site, it's never safe to assume that anyone has installed any of the /{usr,opt}/sfw packages. Frankly, I've never actually been to a place that installed them by default. Expected behavior of installing either pkg-get or pkgutil would be that it "just works", regardless of what trickery was necessary to bootstrap that into existence. Everything *after that* would be expected to "follow the rules" in a pedantic sort of way. Seems like bundling both wget binaries in an ARCH=all package is just the price of doing business to allow for maximum uptake and diminished confusion for new users. > Then it will be cleanly ARCH=all , and there is no longer an issue there. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > From phil at bolthole.com Tue Sep 21 19:15:34 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 21 Sep 2010 10:15:34 -0700 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: <4C98DB55.7090807@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> Message-ID: On 9/21/10, Gordon Marler wrote: > > >From site to site, it's never safe to assume that anyone has installed > any of the /{usr,opt}/sfw packages. Frankly, I've never actually been > to a place that installed them by default. ?? Gordan, are you looking at some solaris 9 machines? Solaris 10 **requires** packages under /usr/sfw So I think your viewpoint needs to be adjusted to be up to date. This discussion is centered around solaris 10. From gmarler at opencsw.org Tue Sep 21 19:29:45 2010 From: gmarler at opencsw.org (Gordon Marler) Date: Tue, 21 Sep 2010 13:29:45 -0400 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> Message-ID: <4C98EB89.20408@opencsw.org> On 09/21/2010 01:15 PM, Philip Brown wrote: > On 9/21/10, Gordon Marler wrote: > >> >From site to site, it's never safe to assume that anyone has installed >> any of the /{usr,opt}/sfw packages. Frankly, I've never actually been >> to a place that installed them by default. >> > ?? > > Gordan, are you looking at some solaris 9 machines? > No - looking exclusively at Solaris 10. > Solaris 10 **requires** packages under /usr/sfw > While Solaris 10 may require *some* packages that deliver payloads to /usr/sfw to be installed, wget is not one of them. Across 1400 Solaris 10 systems I have access to, only 3 or 4 of them have had that particular package installed. It's fairly normal for your OS Security folks to come down with an edict that SFW packages aren't installed by default, not that I advocate that either. > So I think your viewpoint needs to be adjusted to be up to date. > Oh dear - that's an unexpected comment. > This discussion is centered around solaris 10. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > From phil at bolthole.com Tue Sep 21 20:27:28 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 21 Sep 2010 11:27:28 -0700 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: <4C98EB89.20408@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> Message-ID: On 9/21/10, Gordon Marler wrote: > On 09/21/2010 01:15 PM, Philip Brown wrote: >> On 9/21/10, Gordon Marler wrote: >> >>> >From site to site, it's never safe to assume that anyone has installed >>> any of the /{usr,opt}/sfw packages. Frankly, I've never actually been >>> to a place that installed them by default. >>> >> ?? >> > While Solaris 10 may require *some* packages that deliver payloads to > /usr/sfw to be installed, wget is not one of them. Across 1400 Solaris > 10 systems I have access to, only 3 or 4 of them have had that > particular package installed. You seem to be contradicting yourself a bit. You went from "[you shouldnt assume that] any of the /usr/sfw packages are installed", to [some of them can be expected]. But, that being said, I can understand how wget might not be included in a system install. I'm just disagreeing on a solution to the issue of "let's provdide one stop bootstrapping for opencsw". It seems like this issue has been a little misrepresented. We already HAVE "one line bootstrapping" via the pkgutil method. One that is already mentioned on our web site: # pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil-`uname -p`.pkg This doesnt seem complicated to me. A one line cut-n-paste. Easy. From dam at opencsw.org Tue Sep 21 21:11:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 21 Sep 2010 21:11:59 +0200 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> Message-ID: Hi Phil, Am 21.09.2010 um 20:27 schrieb Philip Brown: > It seems like this issue has been a little misrepresented. > We already HAVE "one line bootstrapping" via the pkgutil method. > One that is already mentioned on our web site: > > # pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil-`uname -p`.pkg > > This doesnt seem complicated to me. A one line cut-n-paste. Easy. It is not complicated. But it can be even less complicated by not having to specify `uname -p`. After reviewing the old discussion I can't see a particular reason to not include wget to a generic version. It really boils down to beauty vs. ease-of-use. Beauty is of course nice to look at, but it is not a virtue of its own. Best regards -- Dago From phil at bolthole.com Tue Sep 21 21:51:55 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 21 Sep 2010 12:51:55 -0700 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> Message-ID: On 9/21/10, Dagobert Michelsen wrote: > Hi Phil, > > Am 21.09.2010 um 20:27 schrieb Philip Brown: >> It seems like this issue has been a little misrepresented. >> We already HAVE "one line bootstrapping" via the pkgutil method. >> One that is already mentioned on our web site: >> >> # pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil-`uname -p`.pkg >> >> This doesnt seem complicated to me. A one line cut-n-paste. Easy. > > It is not complicated. But it can be even less complicated by > not having to specify `uname -p`. After reviewing the old > discussion I can't see a particular reason to not include > wget to a generic version. > > It really boils down to beauty vs. ease-of-use. Beauty is > of course nice to look at, but it is not a virtue of its own. > > > Best regards > > -- Dago > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Tue Sep 21 22:02:35 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 21 Sep 2010 13:02:35 -0700 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> Message-ID: On 9/21/10, Dagobert Michelsen wrote: > Hi Phil, > > Am 21.09.2010 um 20:27 schrieb Philip Brown: >> It seems like this issue has been a little misrepresented. >> We already HAVE "one line bootstrapping" via the pkgutil method. >> One that is already mentioned on our web site: >> >> # pkgadd -d http://mirror.opencsw.org/opencsw/pkgutil-`uname -p`.pkg >> >> This doesnt seem complicated to me. A one line cut-n-paste. Easy. > > It is not complicated. But it can be even less complicated by > not having to specify `uname -p`. After reviewing the old > discussion I can't see a particular reason to not include > wget to a generic version. You are not clearly stating what you are pushing. Please dont use these 'generic' terms, it's misleading. To be specific, you are suggesting that we have a package that is explicitly designated as "ARCH=all" - a designation that is usually understood to mean "no binaries" - contain binaries. > It really boils down to beauty vs. ease-of-use. Beauty is > of course nice to look at, but it is not a virtue of its own. It's not "beauty", it is "clarity and accuracy of package labelling". I see two issues with your proposal: 1: what you are suggesting does not improve ease of use in any noticable way. The change reduces by a handful of characters, a line that is going to be long either way. (ironically, it could be argued better as a "beauty enhancement", since some people consider backticks to be "ugly". but not "easy of use") 2: this was already fully discussed and debated on the list a year or three ago, and the issue was settled, by general consensus of the maintainers: "ARCH=all" means "no binaries". You already know this, since you were "there" :), and also you mentioned you have recently reviewed the archives. So why bring up this old issue now all of a sudden? From phil at bolthole.com Tue Sep 21 23:12:24 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 21 Sep 2010 14:12:24 -0700 Subject: [csw-maintainers] tip on smf services, and conditional start Message-ID: I've just discovered something that, if true, may be very useful to us, for SMF based services. Background: There are certain demons that may or may not be chosen to be enabled, at install time. Right now, we go through assorted backflips to respect things like "autoenable_demons=no", and the like, attempting to use svcadm/svccfg enable/disable at install time. However, there seems to be another alternative. IF the demon expects a config file, and IF that config file needs to be hand-crafted by the user before being useful; It seems we can add special magic into the xml manifest, where IF the config file exists, then SMF will start the service. but if not, then the service wont start. Without any errors being flagged. I came across this while examining the sun ssh SMF definitions. I think that if if /etc/ssh/sshd_config is not present entirely, then it just leaves the service in an offline state. Even directly attempting to online it, leaves it offline, until the config file is created. The magic xml to include, would seem to be: I'm not an XML or smf guru, so this sort of thing should be tested carefully before deploying. But I thought I'd share this potentially useful trick, in case anyone is motivated to take it further. From dam at opencsw.org Wed Sep 22 09:15:22 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 22 Sep 2010 09:15:22 +0200 Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> Message-ID: Hi Phil, Am 21.09.2010 um 22:02 schrieb Philip Brown: > 1: what you are suggesting does not improve ease of use in any > noticable way. The change reduces by a handful of characters, a line > that is going to be long either way. Argh! For some reason I thought wget was not bundled with pkgutil AT ALL, which is clearly wrong now that I have looked. The last posting I read was from you suggesting a "script bootstrapping" to download wget after package install, then I failed to follow up he next posting which is printed somewhere else. Summary: Never mind, everything is fine as it is. Ihsan: I find it hard to work with the web-archive. Would it be possible to set up a public read-only IMAP mailbox with all archived postings in it? Best regards -- Dago From james at opencsw.org Wed Sep 22 10:57:49 2010 From: james at opencsw.org (James Lee) Date: Wed, 22 Sep 2010 08:57:49 GMT Subject: [csw-maintainers] Simplify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> Message-ID: <20100922.8574900.571147344@gyor.oxdrove.co.uk> On 21/09/10, 21:02:35, Philip Brown wrote regarding Re: [csw-maintainers] Easify OpenCSW bootstrapping on a server: > 2: this was already fully discussed and debated on the list a year or > three ago, and the issue was settled, by general consensus of the > maintainers: "ARCH=all" means "no binaries". You already know this, > since you were "there" :), and also you mentioned you have recently > reviewed the archives. Pardon me for not recalling the thread but "ARCH=all" means what it says and not "binaries=none", just as ARCH=i386 does not mean it contains only i386 files and no amd64. Provided that a package works correctly on all architectures (through some mechanism like iaexec) then it's suitable for all architectures (or those stated). Interestingly the man page for pkginfo(4) makes no mention of "all": "Third party application software should restrict itself to ARCH values from the following Solaris-supported instruction set architectures (uname -p): sparc, i386, and ppc." Of course isalist could always end with "all" or "any", assuming some generic exec is provided. James. From bonivart at opencsw.org Wed Sep 22 13:51:28 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 22 Sep 2010 13:51:28 +0200 Subject: [csw-maintainers] Simplify OpenCSW bootstrapping on a server In-Reply-To: <20100922.8574900.571147344@gyor.oxdrove.co.uk> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> <20100922.8574900.571147344@gyor.oxdrove.co.uk> Message-ID: On Wed, Sep 22, 2010 at 10:57 AM, James Lee wrote: > On 21/09/10, 21:02:35, Philip Brown wrote regarding Re: > [csw-maintainers] Easify OpenCSW bootstrapping on a server: > >> 2: this was already fully discussed and debated on the list a year or >> three ago, and the issue was settled, by general consensus of the >> maintainers: "ARCH=all" means "no binaries". You already know this, >> since you were "there" ?:), and also you mentioned you have recently >> reviewed the archives. > > Pardon me for not recalling the thread but "ARCH=all" means what it > says and not "binaries=none", just as ARCH=i386 does not mean it > contains only i386 files and no amd64. ?Provided that a package > works correctly on all architectures (through some mechanism like > iaexec) then it's suitable for all architectures (or those stated). Support from James! I'm honored. :-) -- /peter From dam at opencsw.org Wed Sep 22 15:01:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 22 Sep 2010 15:01:12 +0200 Subject: [csw-maintainers] FYI: Project linkage from experimental currently broken Message-ID: <2D9F4EA9-BAC1-48F4-A2E9-30AD5A7267D1@opencsw.org> Hi, it looks like wikidot changed the XML::RPC API for their wiki which I rely on for project linking from the alternatives page: http://www.wikidot.com/doc:api The information I need is no longer accessible (at least not with the current published API), so the linking is basically inactive until I found out how to circumvent this. Best regards -- Dago From dam at opencsw.org Wed Sep 22 15:38:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 22 Sep 2010 15:38:37 +0200 Subject: [csw-maintainers] FYI: Project linkage from experimental currently broken In-Reply-To: <2D9F4EA9-BAC1-48F4-A2E9-30AD5A7267D1@opencsw.org> References: <2D9F4EA9-BAC1-48F4-A2E9-30AD5A7267D1@opencsw.org> Message-ID: Hi, Am 22.09.2010 um 15:01 schrieb Dagobert Michelsen: > it looks like wikidot changed the XML::RPC API for their wiki which > I rely on for project linking from the alternatives page: > http://www.wikidot.com/doc:api > The information I need is no longer accessible (at least not with > the current published API), so the linking is basically inactive > until I found out how to circumvent this. Wow, WikiDot fixed the bug within 30 minutes from my bug report. Cool shop! Everything should work again now. Best regards -- Dago From phil at bolthole.com Wed Sep 22 18:36:31 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 22 Sep 2010 09:36:31 -0700 Subject: [csw-maintainers] Simplify OpenCSW bootstrapping on a server In-Reply-To: <20100922.8574900.571147344@gyor.oxdrove.co.uk> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> <20100922.8574900.571147344@gyor.oxdrove.co.uk> Message-ID: On 9/22/10, James Lee wrote: > > Pardon me for not recalling the thread but "ARCH=all" means what it > says and not "binaries=none", just as ARCH=i386 does not mean it > contains only i386 files and no amd64. amd64 is in the same architecture "family" as i386, so I dont see any relevant conflict in that comparison. The prior (very old) thread did explicitly agree, AFAIR, that for opencsw purposes, it does mean "binaries=none". > Interestingly the man page for pkginfo(4) makes no mention of "all": However, it is a clear de-facto standard employed by sun. For example, the following packages in the solaris distribution: SUNWjdmk-base SUNWjhdem SUNWjhdev SUNWjhdoc SUNWjhrt SUNWmlibk These are all "ARCH=all" as defined by the the pkginfo . > "Third party application software > should restrict itself to ARCH values from the following > Solaris-supported instruction set architectures (uname > -p): sparc, i386, and ppc." and you'll notice that "ppc" is a valid "ARCH". Therefore, if you're going by strict definitions, something cannot claim to support "all" ARCH values, unless it supports ppc. Does the package in question do that? :-} From dam at opencsw.org Thu Sep 23 10:09:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 23 Sep 2010 10:09:14 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs mutt, mutt_base, mutt_ncurses, mutt_slang In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> Message-ID: <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> Hi Phil, Am 20.09.2010 um 21:10 schrieb Philip Brown: > On 9/19/10, Dagobert Michelsen wrote: >> Am 18.09.2010 um 16:51 schrieb Philip Brown: >> ... >>> the reason I'm being particular about this, is that it would seem far >>> more likely to me for a site to want to have all machines deploy mutt >>> with the SAME configuration.(and I have had specific experience as a >>> site admin doing this with mutt ) >>> >>> Putting the default location in /etc makes that much more difficult. >>> whereas if you put the default in /opt/csw/etc, they could make it a >>> symlink, in the unlikely event they wanted zones to be different >> >> Either way, by symlinking /etc/opt/csw/muttrc to /opt/csw/etc/muttrc or >> vice versa you can have the desired behaviour. > > That has the same behaviour for an end user, but not for sysadmin. > If you say the default is /etc/opt/csw/muttrc, and you then require to > symlink back to /opt/csw/etc for supporting a single global config.. > the admin then has to hit Every Single Machine, and make that symlink. > That can be irritating to maintain, for a site that is centered around > global configurations, like a simple shared /opt/csw If we deliver to /opt/csw/etc and the sysadmin wants to have different configurations he has to copy the configuration manually over. The (open) question is what is the most common use case. > *our* "user" is the sysadmin, and we are supposed to be making things > easier for "our users". > >> That being said I would >> value consistency higher than to select where configs are put on a >> package-by-package basis. And as we have decided with /etc/opt/csw as >> default for configurations I think it is better to put everything in >> there as you can still link back if you need it. > > "consistency" does not mean "no exceptions". Also, I believe that > there was still agreed support for global, non-/etc/opt > configurations, *IF* it makes more sense. IIRC we agreed to allow /opt/csw/etc when there is *no benefit* in having multiple copies of the same file in /etc/opt/csw. > So then the question is, does it make more sense? Yes. > Do you agree, or disagree, with my premise, that it is "[far more] > likely ...for a site to want to have all machines deploy mutt with the > SAME configuration." This heavily depends on your usecase. If you have a zone-per-user you are right. If you are hosting zones with dedicated interfaces in the zone and customer-specific configuration you are wrong. The main argument is: I shifted the location to /etc/opt/csw two releases ago which you accepted and I don't want to ping-pong the configuration depending on where the vane is pointing. Best regards -- Dago From james at opencsw.org Thu Sep 23 11:24:22 2010 From: james at opencsw.org (James Lee) Date: Thu, 23 Sep 2010 09:24:22 GMT Subject: [csw-maintainers] Simplify OpenCSW bootstrapping on a server In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> <4AC1194A.3040308@opencsw.org> <1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org> <4C98DB55.7090807@opencsw.org> <4C98EB89.20408@opencsw.org> <20100922.8574900.571147344@gyor.oxdrove.co.uk> Message-ID: <20100923.9242200.344650953@gyor.oxdrove.co.uk> On 22/09/10, 17:36:31, Philip Brown wrote regarding Re: [csw-maintainers] Simplify OpenCSW bootstrapping on a server: > > Pardon me for not recalling the thread but "ARCH=all" means what it > > says and not "binaries=none", just as ARCH=i386 does not mean it > > contains only i386 files and no amd64. > amd64 is in the same architecture "family" as i386, so I dont see any > relevant conflict in that comparison. elfdump and nm show sparc and i386 binaries belong to the same family but I fail to understand the relevance of family likeness as an AMD64 binary has the same chance of running on a pure 386 machine as a Sparc binary - none. What are you trying to achieve by saying no ELFs in an all arch package? Seems you are only constraining yourself. You can't mean no executable that won't run (on the named ARCH=) because amd64 and sparcv9+vis2 are both examples where this isn't true. > > Interestingly the man page for pkginfo(4) makes no mention of "all": > However, it is a clear de-facto standard employed by sun. This de-facto internal "standard" is not clear to me. SUNWglow (arbitrarily chosen) is not ARCH="all" but contains no ELFs, only arch independent files and the contents cksums match on i386 and sparc. > For example, the following packages in the solaris distribution: ... > > "Third party application software > > should restrict itself to ARCH values from the following "Third party application software" ... > and you'll notice that "ppc" is a valid "ARCH". Therefore, if you're > going by strict definitions, something cannot claim to support "all" > ARCH values, unless it supports ppc. > Does the package in question do that? :-} Show me an Oracle supported customer copy of Solaris 10u9 for PPC and we'll talk. James. From dam at opencsw.org Thu Sep 23 14:35:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 23 Sep 2010 14:35:12 +0200 Subject: [csw-maintainers] Subversion update to 1.6.12 References: <06A8F5EC-1F81-4B42-9277-FEB69F861557@baltic-online.de> Message-ID: <923597D8-F0DD-45C8-A739-4E7481A0E197@opencsw.org> Hi, I just bumped Subversion to 1.6.12: http://buildfarm.opencsw.org/experimental.html#subversion I updated svn on testing9s, everybody feel free to try. Best regards -- Dago From gmarler at opencsw.org Thu Sep 23 18:13:36 2010 From: gmarler at opencsw.org (Gordon Marler) Date: Thu, 23 Sep 2010 12:13:36 -0400 Subject: [csw-maintainers] Access to testing systems Message-ID: <4C9B7CB0.2080902@opencsw.org> I've got access to all of the current* systems, but none of the testing* systems, with my SSH key. Can someone fix this for me? Thanks! GM From dam at opencsw.org Thu Sep 23 18:32:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 23 Sep 2010 18:32:56 +0200 Subject: [csw-maintainers] Access to testing systems In-Reply-To: <4C9B7CB0.2080902@opencsw.org> References: <4C9B7CB0.2080902@opencsw.org> Message-ID: <1FBB9ADD-CC73-476A-A1B4-2DA11744E5B0@opencsw.org> Hi Gordon, Am 23.09.2010 um 18:13 schrieb Gordon Marler: > I've got access to all of the current* systems, but none of the testing* > systems, with my SSH key. > > Can someone fix this for me? This should be fixed now. Best regards -- Dago From phil at bolthole.com Thu Sep 23 23:04:27 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Sep 2010 14:04:27 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs mutt, mutt_base, mutt_ncurses, mutt_slang In-Reply-To: <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> Message-ID: On 9/23/10, Dagobert Michelsen wrote: > Hi Phil, *wave* >> If you say the default is /etc/opt/csw/muttrc, and you then require to >> symlink back to /opt/csw/etc for supporting a single global config.. >> the admin then has to hit Every Single Machine, and make that symlink. >> That can be irritating to maintain, for a site that is centered around >> global configurations, like a simple shared /opt/csw > > If we deliver to /opt/csw/etc and the sysadmin wants to have different > configurations he has to copy the configuration manually over. I'm not sure what point you are trying to make here. if a sysadmin wants different configurations on a per machine basis, then he's going to have to "copy the configuration [] over" and customise it to each machine, either way. if on the other hand, a sysadmin wants the same configuration everywhere, there is a clear "win" for him, for /opt/csw/etc over /etc/opt/csw > The (open) question is what is the most common use case. Yup, i agree. Any suggestions for resolution? polling our users list? or the mutt users list perhaps? >> *our* "user" is the sysadmin, and we are supposed to be making things >> easier for "our users". > The main argument is: I shifted the location to /etc/opt/csw two > releases ago which you accepted and I don't want to ping-pong > the configuration depending on where the vane is pointing. well, I dont deeply dig into Every package, Every time. This release I happened to have more time to dig. Lucky you ;-) I dont think "well, we made a mistake a while back, so lets stick with it" is best policy. I think we should better determine, "was it a mistake to do this?" As I mentioned, I have administered mutt before at a site, although I dont do that much any more. I am guessing that it would be correct to say that a vast majority of our mutt users are going to be either of the "one machine, so it doesnt matter" variety, or the "we're installing mutt at our site, which has one domain, so we want everything the same" variety. I would GUESS that it would be at least 90% of our user base for mutt. In contrast, I think the "we want to have different mutt configurations per machine" user set, would be less than 10%. Would you agree with that estimate, or would you prefer that we actually research it? From phil at bolthole.com Thu Sep 23 23:11:10 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Sep 2010 14:11:10 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs mutt, mutt_base, mutt_ncurses, mutt_slang In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> Message-ID: Something I forgot to mention: I am also thinking that for a lot of cases, mutt users will take whatever is auto-generated. But for those situations where a sysadmin cares to make default muttrc adjustments, it is more likely to be a site-wide adjustment, than a machine-by-machine adjustment. For example, to force a common domain name to be used when sending email. Or to specify the location of the standard mailspool. These things are not likely to be different between machines at the same site. On 9/23/10, Philip Brown wrote: > On 9/23/10, Dagobert Michelsen wrote: >> Hi Phil, > > *wave* > > >>> If you say the default is /etc/opt/csw/muttrc, and you then require to >>> symlink back to /opt/csw/etc for supporting a single global config.. >>> the admin then has to hit Every Single Machine, and make that symlink. >>> That can be irritating to maintain, for a site that is centered around >>> global configurations, like a simple shared /opt/csw >> >> If we deliver to /opt/csw/etc and the sysadmin wants to have different >> configurations he has to copy the configuration manually over. > > I'm not sure what point you are trying to make here. > if a sysadmin wants different configurations on a per machine basis, > then he's going to have to "copy the configuration [] over" and > customise it to each machine, either way. > if on the other hand, a sysadmin wants the same configuration > everywhere, there is a clear "win" for him, for /opt/csw/etc over > /etc/opt/csw > >> The (open) question is what is the most common use case. > > Yup, i agree. > Any suggestions for resolution? polling our users list? or the mutt > users list perhaps? > > >>> *our* "user" is the sysadmin, and we are supposed to be making things >>> easier for "our users". > > >> The main argument is: I shifted the location to /etc/opt/csw two >> releases ago which you accepted and I don't want to ping-pong >> the configuration depending on where the vane is pointing. > > well, I dont deeply dig into Every package, Every time. > This release I happened to have more time to dig. Lucky you ;-) > I dont think "well, we made a mistake a while back, so lets stick with > it" is best policy. I think we should better determine, "was it a > mistake to do this?" > > > As I mentioned, I have administered mutt before at a site, although I > dont do that much any more. > I am guessing that it would be correct to say that a vast majority of > our mutt users are going to be either of the "one machine, so it > doesnt matter" variety, or the "we're installing mutt at our site, > which has one domain, so we want everything the same" variety. > I would GUESS that it would be at least 90% of our user base for mutt. > In contrast, I think the "we want to have different mutt > configurations per machine" user set, would be less than 10%. Would > you agree with that estimate, or would you prefer that we actually > research it? > From maciej at opencsw.org Sat Sep 25 00:12:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 24 Sep 2010 15:12:38 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy Message-ID: Hello maintainers, This is an idea for packaging of shared libraries which simplifies the life cycle of a shared library, from the introduction to the removal from the catalog. Let's consider libfoo.so.1. Instead of putting it into CSWlibfoo, we put libfoo.so.1 into CSWlibfoo1. When libfoo.so.2 comes along, we package it into CSWlibfoo2. This way, there's no need to do the whole dance with shared libraries crammed into a single package. All software that depends on libfoo.so.1, depends on CSWlibfoo1 only. Once dependent packages get recompiled against libfoo.so.2, they stop depending on CSWlibfoo1 and start to depend on CSWlibfoo2. Once nothing depends on CSWlibfoo1 any more, the package is safe to remove from the catalog. It's also easy to check from the package database. Transition from the current state is easy: Before: CSWlibfoo (libfoo.so.1) After: CSWlibfoo (empty) ? CSWlibfoo1 (libfoo.so.1) For an existing more complex package, with already existing two versions of a library: Before: CSWlibfoo (libfoo.so.1, libfoo.so.2) After: CSWlibfoo (empty) ? CSWlibfoo1 (libfoo.so.1) CSWlibfoo (empty) ? CSWlibfoo2 (libfoo.so.2) With time, other packages start depending on CSWlibfoo2 and once all dependencies on CSWlibfoo are gone, it's safe to remove. Most of the benefit would come for the typical libraries such as neon, libxml, which mostly contain just one library file (currently, potentially in several versions). It would also work well for packages that change the sonames in a synchronous manner. If there is a single piece of software that provides multiple shared libraries and changes sonames at different times, we'd need to either create one package per one shared library, or do what we do now, which is providing all libraries in a single package. There's one more benefit I can see: annoying unfixable legacy libraries, e.g. with libraries with bad content. Instead of having to push a smelly content through our validation, we could separate out the smelly stuff, push it once and not update it any more. For example: Before: CSWpython (libpython2.5.so, libpython2.6.so) After: CSWpython (no shared libs) ? CSWlibpython25 (libpython2.5.so) CSWpython (no shared libs) ? CSWlibpython26 (libpython2.6.so) Once Python 3.1 becomes the new hotness and CSWlibpython3.1 comes along, CSWlibpython2.5 and CSWlibpython2.6 would remain without updates. To sum up: Advantages: - easy and complete lifecycle of shared libraries - phasing out of shared libraries can become part of standard catalog update procedures - simpler packages, simpler builds (no need for version modulations and complex merges, good for new maintainers) - isolation of old cruft - no constant re-pushing of files that aren't updated any more - more packages overall (good for stats!); at the same time, number of packages released per software upgrade remains the same. If there was, say 4 packages to release with each Python update, it remains 4 per release. There will be just one new package. Disadvantages: - maintainers need to make more decisions when packaging - there's some amount of work to be done to do the transition, such as creation of new packages and dependencies I can't really think of any significant issues here. It's basically a slight increase in granularity, based on sonames. Thoughts? From james at opencsw.org Sat Sep 25 11:55:54 2010 From: james at opencsw.org (James Lee) Date: Sat, 25 Sep 2010 09:55:54 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> On 24/09/10, 23:12:38, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] An idea for a shared libraries policy: > This is an idea for packaging of shared libraries which simplifies the > life cycle of a shared library, from the introduction to the removal > from the catalog. http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html James. From pfelecan at opencsw.org Sat Sep 25 12:45:16 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Sep 2010 12:45:16 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> (James Lee's message of "Sat, 25 Sep 2010 09:55:54 GMT") References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 24/09/10, 23:12:38, Maciej "(Matchek)" Blizinski > wrote regarding [csw-maintainers] An idea for a shared libraries policy: > >> This is an idea for packaging of shared libraries which simplifies the >> life cycle of a shared library, from the introduction to the removal >> from the catalog. > > http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html Having read the referenced message I think that you agree with Maciej's proposal. I'm I right? -- Peter From pfelecan at opencsw.org Sat Sep 25 12:48:33 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Sep 2010 12:48:33 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: (Maciej Blizinski's message of "Fri, 24 Sep 2010 15:12:38 -0700") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > Advantages: > - easy and complete lifecycle of shared libraries > - phasing out of shared libraries can become part of standard catalog > update procedures > - simpler packages, simpler builds (no need for version modulations > and complex merges, good for new maintainers) > - isolation of old cruft > - no constant re-pushing of files that aren't updated any more > - more packages overall (good for stats!); at the same time, number of > packages released per software upgrade remains the same. If there > was, say 4 packages to release with each Python update, it remains 4 > per release. There will be just one new package. > > Disadvantages: > - maintainers need to make more decisions when packaging > - there's some amount of work to be done to do the transition, such as > creation of new packages and dependencies Excellent proposition. Plenty of advantages and the considered disadvantages are not, in my opinion, detrimental to the overall quality of our distribution/stack/whatever we call it. On the contrary. -- Peter From james at opencsw.org Sat Sep 25 12:53:58 2010 From: james at opencsw.org (James Lee) Date: Sat, 25 Sep 2010 10:53:58 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> Message-ID: <20100925.10535800.903255136@gyor.oxdrove.co.uk> On 25/09/10, 11:45:16, Peter FELECAN wrote regarding Re: [csw-maintainers] An idea for a shared libraries policy: > James Lee writes: > > On 24/09/10, 23:12:38, Maciej "(Matchek)" Blizinski > > wrote regarding [csw-maintainers] An idea for a shared libraries policy: > > > >> This is an idea for packaging of shared libraries which simplifies the > >> life cycle of a shared library, from the introduction to the removal > >> from the catalog. > > > > http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html > Having read the referenced message I think that you agree with Maciej's > proposal. I'm I right? Maciej agrees with my old idea although it was pooh-poohed at the time. James. From pfelecan at opencsw.org Sat Sep 25 13:05:24 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Sep 2010 13:05:24 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100925.10535800.903255136@gyor.oxdrove.co.uk> (James Lee's message of "Sat, 25 Sep 2010 10:53:58 GMT") References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> <20100925.10535800.903255136@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 25/09/10, 11:45:16, Peter FELECAN wrote regarding > Re: [csw-maintainers] An idea for a shared libraries policy: > >> James Lee writes: > >> > On 24/09/10, 23:12:38, Maciej "(Matchek)" Blizinski >> > wrote regarding [csw-maintainers] An idea for a shared libraries policy: >> > >> >> This is an idea for packaging of shared libraries which simplifies the >> >> life cycle of a shared library, from the introduction to the removal >> >> from the catalog. >> > >> > http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html > >> Having read the referenced message I think that you agree with Maciej's >> proposal. I'm I right? > > Maciej agrees with my old idea although it was pooh-poohed at the time. Who dared pooh-pooh you? BTW, it's a regular verb? -- Peter From james at opencsw.org Sat Sep 25 13:30:37 2010 From: james at opencsw.org (James Lee) Date: Sat, 25 Sep 2010 11:30:37 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> <20100925.10535800.903255136@gyor.oxdrove.co.uk> Message-ID: <20100925.11303700.3494934348@gyor.oxdrove.co.uk> On 25/09/10, 12:05:24, Peter FELECAN wrote regarding Re: [csw-maintainers] An idea for a shared libraries policy: > >> >> This is an idea for packaging of shared libraries which simplifies the > >> >> life cycle of a shared library, from the introduction to the removal > >> >> from the catalog. > >> > > >> > http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html > > > >> Having read the referenced message I think that you agree with Maciej's > >> proposal. I'm I right? > > > > Maciej agrees with my old idea although it was pooh-poohed at the time. > Who dared pooh-pooh you? http://lists.opencsw.org/pipermail/maintainers/2009-October/009992.html > BTW, it's a regular verb? I guess so: I pooh-pooh, he pooh-poohs, we pooh-pooh, it was pooh-poohed, I am pooh-poohing... James. From pfelecan at opencsw.org Sat Sep 25 13:44:21 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Sep 2010 13:44:21 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100925.11303700.3494934348@gyor.oxdrove.co.uk> (James Lee's message of "Sat, 25 Sep 2010 11:30:37 GMT") References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> <20100925.10535800.903255136@gyor.oxdrove.co.uk> <20100925.11303700.3494934348@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 25/09/10, 12:05:24, Peter FELECAN wrote regarding > Re: [csw-maintainers] An idea for a shared libraries policy: > >> >> >> This is an idea for packaging of shared libraries which simplifies the >> >> >> life cycle of a shared library, from the introduction to the removal >> >> >> from the catalog. >> >> > >> >> > http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html >> > >> >> Having read the referenced message I think that you agree with Maciej's >> >> proposal. I'm I right? >> > >> > Maciej agrees with my old idea although it was pooh-poohed at the time. > >> Who dared pooh-pooh you? > > http://lists.opencsw.org/pipermail/maintainers/2009-October/009992.html Well, that was about splitting rt, dev, doc, &c. I don't say that it's dissimilar... Anyway, the thread will be forwarded to our dear president (not Phil but Nick) to handle all those pooh-poohers. -- Peter From bwalton at opencsw.org Sat Sep 25 14:26:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Sep 2010 08:26:20 -0400 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> <20100925.10535800.903255136@gyor.oxdrove.co.uk> <20100925.11303700.3494934348@gyor.oxdrove.co.uk> Message-ID: <1285417487-sup-5147@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Sep 25 07:44:21 -0400 2010: > dissimilar... Anyway, the thread will be forwarded to our dear president > (not Phil but Nick) to handle all those pooh-poohers. Is this 'Nick' similar in use to the affectionate shortening of our current asshat's name to 'Steve' ? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Sep 25 14:56:42 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Sep 2010 08:56:42 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs ap2_suexec, apache2, apache2_devel, a(...) In-Reply-To: <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> References: <201009242241.o8OMflW5021408@login.bo.opencsw.org> <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> Message-ID: <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Fri Sep 24 19:39:52 -0400 2010: > Excerpts from THURNER Rupert's message of Fri Sep 24 18:41:47 -0400 2010: > > upgrade apache2 package, including mpm and prefork options as > > alternatives. > > I wouldn't mind some testing on this before unleashing it. It's a > pretty major overhaul... :) Specifically, the changes in packaging are: * No more ap2_prefork or ap2_worker. These are bundled in apache2. * No more apache2c or apache2rt. As we're now leveraging an external apr-util, these didn't make sense any longer. * apache2 is marked I with the 4 packages above. * The httpd binary is setup using alternatives, with prefork having highest precedence. For this realease, var/ and etc/ are still housed at /opt/csw/apache2/. A future release will move these where they belong, but I think there has been enough change introduced for one release...and that it's more important to get apache2 moving again. I'm hoping to be able to test it myself this week, but haven't had a change yet. Can anyone else take a poke at these packages (in my experimental repo)? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat Sep 25 15:06:47 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Sep 2010 15:06:47 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <1285417487-sup-5147@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sat, 25 Sep 2010 08:26:20 -0400") References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> <20100925.10535800.903255136@gyor.oxdrove.co.uk> <20100925.11303700.3494934348@gyor.oxdrove.co.uk> <1285417487-sup-5147@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Peter FELECAN's message of Sat Sep 25 07:44:21 -0400 2010: > >> dissimilar... Anyway, the thread will be forwarded to our dear president >> (not Phil but Nick) to handle all those pooh-poohers. > > Is this 'Nick' similar in use to the affectionate shortening of our > current asshat's name to 'Steve' ? If Steve = Stephen + Harper then Nick is our asshat (I didn't know that word...) even though the French will call that Nico, but conversing with that British gent I adapted. -- Peter From ja at opencsw.org Sun Sep 26 20:48:54 2010 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 26 Sep 2010 20:48:54 +0200 Subject: [csw-maintainers] New Munin packages in experimental Message-ID: <8405F620-A7A2-4A9E-A44B-49109F92410F@opencsw.org> Hi there, there are new packages for Munin available from http://mirror.opencsw.org/experimental.html#ja Feedback is very welcome. Juergen -- Juergen Arndt From dam at opencsw.org Sun Sep 26 21:28:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 26 Sep 2010 21:28:38 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100925.11303700.3494934348@gyor.oxdrove.co.uk> References: <20100925.9555400.1481738481@gyor.oxdrove.co.uk> <20100925.10535800.903255136@gyor.oxdrove.co.uk> <20100925.11303700.3494934348@gyor.oxdrove.co.uk> Message-ID: Hi folks, Am 25.09.2010 um 13:30 schrieb James Lee: > On 25/09/10, 12:05:24, Peter FELECAN wrote > regarding > Re: [csw-maintainers] An idea for a shared libraries policy: > >>>>>> This is an idea for packaging of shared libraries which >>>>>> simplifies the >>>>>> life cycle of a shared library, from the introduction to the >>>>>> removal >>>>>> from the catalog. >>>>> >>>>> http://lists.opencsw.org/pipermail/maintainers/2009-October/009960.html >>> >>>> Having read the referenced message I think that you agree with >>>> Maciej's >>>> proposal. I'm I right? >>> >>> Maciej agrees with my old idea although it was pooh-poohed at the >>> time. > >> Who dared pooh-pooh you? > > http://lists.opencsw.org/pipermail/maintainers/2009-October/ > 009992.html No no no no... Don't you put the blame on me for that one! ;-) I like (and liked) the idea, but raised the issue that there may be multiple non-version-resembling shared libs from one package. Apart from that I like it. And after one more year of packaging experience I would say my doubts from that time have not been correct. Lots of complicated multi-version- modulation-libs would benefit from it, like libicu libcurl libneon which immediately come to my mind. Best regards -- Dago From bwalton at opencsw.org Sun Sep 26 23:25:10 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 26 Sep 2010 17:25:10 -0400 Subject: [csw-maintainers] ggettext update in experimental Message-ID: <1285536284-sup-26@pinkfloyd.chass.utoronto.ca> Hi All, If anyone is able and willing, I'd appreciate some feedback on the updated ggettext* packages in experimental/bwalton. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Sep 26 23:37:03 2010 From: phil at bolthole.com (Philip Brown) Date: Sun, 26 Sep 2010 14:37:03 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: I did not see anything in the proposal that mentioned how to handle catalog naming; only svr4 package names. that is why it seems so clean. once you step into that realm things become more messy. remember that upstream numbering is sometimes out of sync with the lib numbering. your proposal may "simplify" the number of versions of a library per package . however, it will *add* complexity to the naming and package building process in other ways. I'm not neccessarily against it. I'm just pointing out it isn't neccessarily the "simple" choice From dam at opencsw.org Mon Sep 27 09:25:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 Sep 2010 09:25:14 +0200 Subject: [csw-maintainers] Mutt and general release policy In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> Message-ID: <0C5FD3BA-C75E-4CC1-82BC-B78075787130@opencsw.org> Hi Phil, Am 23.09.2010 um 23:04 schrieb Philip Brown: >> The (open) question is what is the most common use case. > > Yup, i agree. > Any suggestions for resolution? polling our users list? or the mutt > users list perhaps? I'll do some more research among mutt users. > well, I dont deeply dig into Every package, Every time. > This release I happened to have more time to dig. Lucky you ;-) > I dont think "well, we made a mistake a while back, so lets stick with > it" is best policy. I think we should better determine, "was it a > mistake to do this?" Right. But in the meantime the submitted package should be released. It is in package quality not worse than what we have and better in terms of currentness. The release check should focus on technical things and proper functioning, not package usecases. These are very welcome to be checked and discussed on maintainers@, but it should not be possible to block a maintainer from releasing a proper working package just because the release manager thinks that specific issues done in the past are wrong now or just need more research. This has caused much frustration in the past. You will say that a maintainer who is not willing to work with the release manager to resolve this is not worthy to be a maintainer. I say the release manager should not have the power to force a maintainer to change or investigate these package-specific things. Don't get me wrong: I appreciate your (as "Phil") commitment and care about the packages. However, we need to differentiate between your work as team member among the maintainer, which are valued and your concerns and suggestions about the location are a good source of inspiration, and your power as release manager. You are IMHO misusing your power as release manager in this case to force discussion you drive as team member. Best regards -- Dago From james at opencsw.org Mon Sep 27 10:36:16 2010 From: james at opencsw.org (James Lee) Date: Mon, 27 Sep 2010 08:36:16 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: <20100927.8361600.2518509512@gyor.oxdrove.co.uk> On 26/09/10, 22:37:03, Philip Brown wrote regarding Re: [csw-maintainers] An idea for a shared libraries policy: > I did not see anything in the proposal that mentioned how to handle > catalog naming; only svr4 package names. Another old idea: packageName="CSW${softwareName}" softwareName="${packageName#CSW}" eg: http://lists.opencsw.org/pipermail/maintainers/2009-November/010467.html James. From phil at bolthole.com Mon Sep 27 15:41:53 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Sep 2010 06:41:53 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs ap2_suexec, apache2, apache2_devel, a(...) In-Reply-To: <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> References: <201009242241.o8OMflW5021408@login.bo.opencsw.org> <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> Message-ID: when do you want me to release this Ben? From bwalton at opencsw.org Mon Sep 27 16:10:57 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 27 Sep 2010 10:10:57 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs ap2_suexec, apache2, apache2_devel, a(...) In-Reply-To: References: <201009242241.o8OMflW5021408@login.bo.opencsw.org> <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> Message-ID: <1285596509-sup-5935@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Sep 27 09:41:53 -0400 2010: > when do you want me to release this Ben? Well, I just freed up a box that was running the old apache packages this morning, so give me a day or two to test the updates and then I'll provide my thoughts on the package changes. That being said, all I did was the package splitting and alternatives stuff...it'll be Rupert's package going forward as I don't want official ownership of it. (Rupert suggested making it a community/group-owned package whereby anyone wanting an update would roll it and own it until someone else took it...). If he really wants it out, it's his call, not mine. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Sep 27 19:32:01 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Sep 2010 10:32:01 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100927.8361600.2518509512@gyor.oxdrove.co.uk> References: <20100927.8361600.2518509512@gyor.oxdrove.co.uk> Message-ID: On 9/27/10, James Lee wrote: > On 26/09/10, 22:37:03, Philip Brown wrote regarding Re: > [csw-maintainers] An idea for a shared libraries policy: > >> I did not see anything in the proposal that mentioned how to handle >> catalog naming; only svr4 package names. > > > Another old idea: > > packageName="CSW${softwareName}" > softwareName="${packageName#CSW}" The issue is not so much the alpha-part of the name, as the numeric part :-/ From phil at bolthole.com Mon Sep 27 19:48:02 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Sep 2010 10:48:02 -0700 Subject: [csw-maintainers] Mutt and general release policy In-Reply-To: <0C5FD3BA-C75E-4CC1-82BC-B78075787130@opencsw.org> References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> <0C5FD3BA-C75E-4CC1-82BC-B78075787130@opencsw.org> Message-ID: On 9/27/10, Dagobert Michelsen wrote: >... > Right. But in the meantime the submitted package should be > released. It is in package quality not worse than what we have > and better in terms of currentness. [...] it should not be possible to block a > maintainer from releasing a proper working package just > because the release manager thinks that specific issues > done in the past are wrong now or just need more research. > This has caused much frustration in the past. Yes, it has. However, who says being a maintainer is supposed to be 100% frustration free? :-} > You will > say that a maintainer who is not willing to work with > the release manager to resolve this is not worthy to > be a maintainer. I say the release manager should > not have the power to force a maintainer to change > or investigate these package-specific things. "the release manager" is the only real point of quality control we have. Since packaging is a "volunteer effort", we cannot "force" a maintainer to rebuild a package. If we go with the "release now, argue about it later" methodology, then a maintainer may(and has in the past), simply say, 'well, in that case I dont care to update the package'. We then have a case where we have a package that has been agreed upon as "wrong", but does not get fixed. Maintainers put effort into packages, when they have the time and energy to do so. They have the time, when they are releasing a package. They may NOT have time later on. So in that sense also, I think that package release time in most cases works better for maintainers, since that when they have time and energy on-hand. I recognize that this may be true for some, but not all, maintainers. I welcome suggestions for alternative courses of action, that will result in the packages actually getting updated with agreed upon fixes in a timely manner. I HAVE also been quite flexible with people, who have told me up front, "okay, you might be right; I dont have time to rework the package right now,but I'll commit to rework it at (specific later date)". In those cases, I have gone ahead and released the "better than current, but not perfect" package. Did you want to make that commitment, to follow through on the research, AND rebuild mutt if research justifies it (by a specific date)? In which case, I'll release your current mutt package,and remind you down the road. > Don't get me wrong: I appreciate your (as "Phil") > commitment and care about the packages. However, > [...] You are IMHO misusing > your power as release manager in this case to force > discussion you drive as team member. I'll point out that I am not even "forcing" mutt to be done a certain way. I am only being sticky about the discussion on it. In my opinion, this is *exactly* what a release manager is for. (and I believe it parallels the functionality of release managers in other distributions) From dam at opencsw.org Mon Sep 27 21:23:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 Sep 2010 21:23:35 +0200 Subject: [csw-maintainers] Mutt and general release policy In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> <0C5FD3BA-C75E-4CC1-82BC-B78075787130@opencsw.org> Message-ID: Hi Phil, Am 27.09.2010 um 19:48 schrieb Philip Brown: > "the release manager" is the only real point of quality control we > have. > Since packaging is a "volunteer effort", we cannot "force" a > maintainer to rebuild a package. Exactly. > If we go with the "release now, argue about it later" methodology, > then a maintainer may(and has in the past), simply say, 'well, in that > case I dont care to update the package'. If it really is an issue two other maintainers will come and say "you update the package or we do it." > We then have a case where we have a package that has been agreed upon > as "wrong", but does not get fixed. If the maintainer refuses to make more changes and the release doesn't release it it won't get fixed either. > Maintainers put effort into packages, when they have the time and > energy to do so. They have the time, when they are releasing a > package. They may NOT have time later on. > So in that sense also, I think that package release time in most cases > works better for maintainers, since that when they have time and > energy on-hand. This is often true, but not always. > I recognize that this may be true for some, but not all, maintainers. > I welcome suggestions for alternative courses of action, that will > result in the packages actually getting updated with agreed upon fixes > in a timely manner. > > I HAVE also been quite flexible with people, who have told me up > front, "okay, you might be right; I dont have time to rework the > package right now,but I'll commit to rework it at (specific later > date)". In those cases, I have gone ahead and released the "better > than current, but not perfect" package. > > Did you want to make that commitment, to follow through on the > research, AND rebuild mutt if research justifies it (by a specific > date)? In which case, I'll release your current mutt package,and > remind you down the road. Of course, already done: http://marc.info/?l=mutt-users&m=128559587014190&w=2 Best regards -- Dago From phil at bolthole.com Mon Sep 27 21:42:11 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Sep 2010 12:42:11 -0700 Subject: [csw-maintainers] Mutt and general release policy In-Reply-To: References: <201009161303.o8GD3Qb5003939@login.bo.opencsw.org> <3504BD6E-D828-4C03-BE23-ABE8DC93D162@opencsw.org> <759378AC-56DB-4EDA-8EE1-5D58FBA0F301@opencsw.org> <0C5FD3BA-C75E-4CC1-82BC-B78075787130@opencsw.org> Message-ID: On 9/27/10, Dagobert Michelsen wrote: > Hi Phil, *wave* > Am 27.09.2010 um 19:48 schrieb Philip Brown: > >> If we go with the "release now, argue about it later" methodology, >> then a maintainer may(and has in the past), simply say, 'well, in that >> case I dont care to update the package'. > > If it really is an issue two other maintainers will come and say > "you update the package or we do it." This is an "unsubstantiated claim". I havent seen anything to indicate that would happen, and in contrast, I've seen plenty of evidence that this would NOT usually happen. Specific evidence: we have had "important" packages languishing as orphaned, for months (if not YEARS), and no single maintainer has stepped up to take them over (never mind "two other maintainers" that you claim :-D ) >> Did you want to make that commitment, to follow through on the >> research, AND rebuild mutt if research justifies it (by a specific >> date)? In which case, I'll release your current mutt package,and >> remind you down the road. > > Of course, already done: > http://marc.info/?l=mutt-users&m=128559587014190&w=2 Great! Okay, your mutt packages will be in the next batch. (but not the one I'm sending out right now,since that was already started) From maciej at opencsw.org Tue Sep 28 02:23:50 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 27 Sep 2010 17:23:50 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: No dia 26 de Setembro de 2010 14:37, Philip Brown escreveu: > I did not see anything in the proposal that mentioned how to handle > catalog naming; only svr4 package names. that is why it seems so > clean. > once you step into that realm things become more messy. > remember that upstream numbering is sometimes out of sync with the lib > numbering. > > your proposal may "simplify" the number of versions of a library per > package . however, it will *add* complexity to the naming and package > building process in other ways. > > I'm not neccessarily against it. I'm just pointing out it isn't > neccessarily the "simple" choice It's true. Specifically problematic are bits of software that already embed a number in the package name, or the soname. For example apache2rt package contains libapr-1.so.0. The corresponding pkgname would be something along the lines of CSWlibapr10 or CSWlibapr-10, or other punctuation variants. These names aren't strikingly pretty, but I think it's possible to make them consistent. Another thing is, that we don't need to put every shared library in a separate packages. This policy would only apply to libraries that other packages link to. If a shared library is linked to only by binaries from the same package, there's no benefit from separating out the libraries. These can be found retrospectively by running checkpkg against the whole catalog. It is harder at the checkpkg stage, I think the best bet are heuristics such as "if it is in other packages' RUNPATH, it can be linked to and should go into a separate package." The next bit of automation is figuring out automatically, what the package name should be. If we can handle that by an algorithm, we'll sport a consistent set of lib* packages. From james at opencsw.org Tue Sep 28 11:00:14 2010 From: james at opencsw.org (James Lee) Date: Tue, 28 Sep 2010 09:00:14 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: <20100927.8361600.2518509512@gyor.oxdrove.co.uk> Message-ID: <20100928.9001400.1201879712@gyor.oxdrove.co.uk> On 27/09/10, 18:32:01, Philip Brown wrote regarding Re: [csw-maintainers] An idea fo > >> I did not see anything in the proposal that mentioned how to handle > >> catalog naming; only svr4 package names. > > > > > > Another old idea: > > > > packageName="CSW${softwareName}" > > softwareName="${packageName#CSW}" > The issue is not so much the alpha-part of the name, as the numeric part > :-/ $ packageName=CSWlibpython26 $ softwareName="${packageName#CSW}" $ echo ${softwareName} libpython26 $ packageName="CSW${softwareName}" $ echo ${packageName} CSWlibpython26 $ ... works with numbers. James. From james at opencsw.org Tue Sep 28 11:00:13 2010 From: james at opencsw.org (James Lee) Date: Tue, 28 Sep 2010 09:00:13 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: <20100928.9001300.2508409390@gyor.oxdrove.co.uk> On 28/09/10, 01:23:50, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] An idea for a shared libraries policy: > > once you step into that realm things become more messy. > > remember that upstream numbering is sometimes out of sync with the lib > > numbering. > > > > your proposal may "simplify" the number of versions of a library per > > package . however, it will *add* complexity to the naming and package > > building process in other ways. > > > > I'm not neccessarily against it. I'm just pointing out it isn't > > neccessarily the "simple" choice > It's true. Specifically problematic are bits of software that already > embed a number in the package name, or the soname. For example > apache2rt package contains libapr-1.so.0. The corresponding pkgname > would be something along the lines of CSWlibapr10 or CSWlibapr-10, or > other punctuation variants. These names aren't strikingly pretty, but > I think it's possible to make them consistent. These packages are only used as dependencies so the naming doesn't have to be appealing. No user should need to directly install a run time. They should even be in the list offered to users, only the top level names should be, like jpeg, python. > Another thing is, that we don't need to put every shared library in a > separate packages. Only when the SONAME changes and it's incompatible, like major version changes on software, eg, apache2. > This policy would only apply to libraries that > other packages link to. If a shared library is linked to only by > binaries from the same package, there's no benefit from separating out > the libraries. Yes there is, it may change later. That's why we are where we are, because in the first place there isn't a need. James. From dam at opencsw.org Tue Sep 28 11:05:08 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 28 Sep 2010 11:05:08 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100928.9001300.2508409390@gyor.oxdrove.co.uk> References: <20100928.9001300.2508409390@gyor.oxdrove.co.uk> Message-ID: <46C218FA-D369-41DD-A218-C5E72EDCBA2C@opencsw.org> Hi James, Am 28.09.2010 um 11:00 schrieb James Lee: > On 28/09/10, 01:23:50, Maciej "(Matchek)" Blizinski > >> It's true. Specifically problematic are bits of software that >> already >> embed a number in the package name, or the soname. For example >> apache2rt package contains libapr-1.so.0. The corresponding pkgname >> would be something along the lines of CSWlibapr10 or CSWlibapr-10, or >> other punctuation variants. These names aren't strikingly pretty, >> but >> I think it's possible to make them consistent. > > These packages are only used as dependencies so the naming doesn't > have > to be appealing. No user should need to directly install a run time. > They should even be in the list offered to users, only the top level > names should be, like jpeg, python. I guess you mean "They should NOT even be...". Very true. This would solve one other issue: The JRE can be thought of as a runtime, which we can not deliver right now as it is not "bundled" with another Java-package that uses it. "Hiding" some packages from pkg-get/pkgutil would solve this. >> Another thing is, that we don't need to put every shared library in a >> separate packages. > > Only when the SONAME changes and it's incompatible, like major version > changes on software, eg, apache2. I am more thinking of krb5_lib which contains a bundle of related shared libs, each with its own soname-numbering (however, that one hasn't changed for a long time, so we may be off good here, but the basic problem remains). >> This policy would only apply to libraries that >> other packages link to. If a shared library is linked to only by >> binaries from the same package, there's no benefit from separating >> out >> the libraries. > > Yes there is, it may change later. That's why we are where we are, > because in the first place there isn't a need. Right. Best regards -- Dago From dam at opencsw.org Tue Sep 28 11:08:46 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 28 Sep 2010 11:08:46 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <46C218FA-D369-41DD-A218-C5E72EDCBA2C@opencsw.org> References: <20100928.9001300.2508409390@gyor.oxdrove.co.uk> <46C218FA-D369-41DD-A218-C5E72EDCBA2C@opencsw.org> Message-ID: <51B38A69-C05E-4782-8D81-89FEB05DA82A@opencsw.org> Hi, Am 28.09.2010 um 11:05 schrieb Dagobert Michelsen: > Am 28.09.2010 um 11:00 schrieb James Lee: >> On 28/09/10, 01:23:50, Maciej "(Matchek)" Blizinski > > >>> It's true. Specifically problematic are bits of software that >>> already >>> embed a number in the package name, or the soname. For example >>> apache2rt package contains libapr-1.so.0. The corresponding pkgname >>> would be something along the lines of CSWlibapr10 or CSWlibapr-10, >>> or >>> other punctuation variants. These names aren't strikingly pretty, >>> but >>> I think it's possible to make them consistent. >> >> These packages are only used as dependencies so the naming doesn't >> have >> to be appealing. No user should need to directly install a run time. >> They should even be in the list offered to users, only the top level >> names should be, like jpeg, python. > > I guess you mean "They should NOT even be...". Very true. This would > solve one other issue: The JRE can be thought of as a runtime, which > we can not deliver right now as it is not "bundled" with another > Java-package that uses it. "Hiding" some packages from pkg-get/pkgutil > would solve this. And Oracle Instantclient. Making packages not directly downlable should be seriously considered as it would make using packages relying on Java and the Oracle client *a lot* easier. Apart from that the packages are essentially ready for release. Best regards -- Dago From james at opencsw.org Tue Sep 28 11:15:19 2010 From: james at opencsw.org (James Lee) Date: Tue, 28 Sep 2010 09:15:19 GMT Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <46C218FA-D369-41DD-A218-C5E72EDCBA2C@opencsw.org> References: <20100928.9001300.2508409390@gyor.oxdrove.co.uk> <46C218FA-D369-41DD-A218-C5E72EDCBA2C@opencsw.org> Message-ID: <20100928.9151900.3055711316@gyor.oxdrove.co.uk> On 28/09/10, 10:05:08, Dagobert Michelsen wrote regarding Re: [csw-maintainers] An idea for a shared libraries policy: > > These packages are only used as dependencies so the naming doesn't > > have > > to be appealing. No user should need to directly install a run time. > > They should even be in the list offered to users, only the top level > > names should be, like jpeg, python. > I guess you mean "They should NOT even be...". Very true. Correct. Sorry, brain and fingers not connected. > This would > solve one other issue: The JRE can be thought of as a runtime, which > we can not deliver right now as it is not "bundled" with another > Java-package that uses it. "Hiding" some packages from pkg-get/pkgutil > would solve this. Yes, it's a presentation thing. Like the pkginfo flag CATEGORY: system|application. James. From phil at bolthole.com Tue Sep 28 18:49:46 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 28 Sep 2010 09:49:46 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <20100928.9151900.3055711316@gyor.oxdrove.co.uk> References: <20100928.9001300.2508409390@gyor.oxdrove.co.uk> <46C218FA-D369-41DD-A218-C5E72EDCBA2C@opencsw.org> <20100928.9151900.3055711316@gyor.oxdrove.co.uk> Message-ID: On 9/28/10, James Lee wrote: > On 28/09/10, 10:05:08, Dagobert Michelsen wrote regarding > Re: [csw-maintainers] An idea for a shared libraries policy: > >> > These packages are only used as dependencies so the naming doesn't >> > have >> > to be appealing. No user should need to directly install a run time. >> > They should even be in the list offered to users, only the top level >> > names should be, like jpeg, python. > >> I guess you mean "They should NOT even be...". Very true. > > Correct. Sorry, brain and fingers not connected. I would be very against the concept of 'disallowing' users to directly download any package conveniently through pkg-get or pkgutil. > Yes, it's a presentation thing. > Like the pkginfo flag CATEGORY: system|application. On the other hand, allowing users to CHOOSE to hide things, is another story. Top level users would probably much like the idea of "dont show me everything, just show me applications and utilities". it would hide a lot of "junk" to their eyes. That being said... if we're aiming for "pretty", we should probably aim for a "pretty GUI" front end for this sort of thing. Last time this topic came up, someone wanted to attempt to use someone else's work, and sort of tweak it for our purposes. But apparently that outside package management thing fizzled or something. We'd probably be better off with something "in-house". Then we could customise it to our needs better. Anyone with high-level GUI language skills? eg: TK, pyTK, or tcl, or (...) ? It should be a fairly trivial task. The biggest grunge is learning the GUI layer language, I think :) I once started a java wrapper for pkg-get, since I know the language already, but later decided java was going to be more work than I wanted to do at the time :-D From phil at bolthole.com Tue Sep 28 18:54:59 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 28 Sep 2010 09:54:59 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: On 9/27/10, Maciej (Matchek) Blizinski wrote: > No dia 26 de Setembro de 2010 14:37, Philip Brown > escreveu: >> >> I'm not neccessarily against it. I'm just pointing out it isn't >> neccessarily the "simple" choice > > It's true. Specifically problematic are bits of software that already > embed a number in the package name, or the soname. For example > apache2rt package contains libapr-1.so.0. The corresponding pkgname > would be something along the lines of CSWlibapr10 or CSWlibapr-10, or > other punctuation variants. These names aren't strikingly pretty, but > I think it's possible to make them consistent. > Side comment: this separation of shared lib binaries into separate packages is entirely possible to do right now. I think the only new "policy" we need to come up with here, is a naming policy, for when the number in the library's SONAME , does not clearly match up with the regular software version number. I'm guessing that debian already has a naming policy for this sort of thing, since I vaguely recall seeing some naming that I considered really ugly at the time. So interested parties should probably do a little research on other distros, to avoid needlessly introducing "yet another naming scheme" if there is an existing accepted one already out there. From maciej at opencsw.org Tue Sep 28 19:37:21 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 28 Sep 2010 10:37:21 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: No dia 28 de Setembro de 2010 09:54, Philip Brown escreveu: > Side comment: this separation of shared lib binaries into separate > packages is entirely possible to do right now. I think the only new > "policy" we need to come up with here, is a naming policy, for when > the number in the library's SONAME , does not clearly match up with > the regular software version number. Yes, it's this, and that two different SONAMEs don't go into a single package. > I'm guessing that debian already has a naming policy for this sort of > thing, since I vaguely recall seeing some naming that I considered > really ugly at the time. > So interested parties should probably do a little research on other > distros, to avoid needlessly introducing "yet another naming scheme" > if there is an existing accepted one already out there. Yes, I support that. I did a quick search and found that Debian policy says: "The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes. (...) Normally, the run-time shared library and its SONAME symlink should be placed in a package named librarynamesoversion, where soversion is the version number in the SONAME of the shared library." http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime I could write a checkpkg test: if there's a shared in /opt/csw/lib (including ISA subdirectories), and has a SONAME, the pkgname must conform to: CSWlibrarynamesonameversion or CSWlibraryname-sonameversion ...and the catalogname must conform to: librarynamesonameversion or libraryname_sonameversion If it's not under /opt/csw/lib, or is not a binary, or not a shared library, or doesn't have a soname, then the rule doesn't apply. Additional prefixes make it slightly harder; including the ISA subdirs, something like /opt/csw(/[a-z]+)?/lib(/[a-z0-9+]+)? would need to be used for matching. How does that sound? From phil at bolthole.com Tue Sep 28 19:57:07 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 28 Sep 2010 10:57:07 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: On 9/28/10, Maciej (Matchek) Blizinski wrote: > > Yes, I support that. I did a quick search and found that Debian policy > says: > > "The run-time shared library must be placed in a package whose name > changes whenever the SONAME of the shared library changes. (...) > Normally, the run-time shared library and its SONAME symlink should be > placed in a package named librarynamesoversion, where soversion is the > version number in the SONAME of the shared library." > > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime Hmm. Well, it's a good start. There are two unmentioned issues that come to my mind: 1. where the name is just Really Stupid :) 2. where the name may not neccessarily imply, "hey this is a library". For those cases, I'm a little leery of going with a hard line "name must exactly match SONAME" policy. I think that having that as a guideline would be okay though. > I could write a checkpkg test: if there's a shared in /opt/csw/lib > (including ISA subdirectories), and has a SONAME, the pkgname must > conform to: > > CSWlibrarynamesonameversion or CSWlibraryname-sonameversion > See above. I dont think it should be put as a blocking checkpkg test. Also, theres the issue that this is an OPTIONAL split-out. We were talking about doing this for *some* shared libs, but not all. But just to be nitpicky... > If it's not under /opt/csw/lib, or is not a binary, or not a shared > library, or doesn't have a soname, then the rule doesn't apply. If it doesnt have a soname, then things default to using the filename, I believe. so we'd still need to have the package name change if the filename changed. From bwalton at opencsw.org Wed Sep 29 00:47:02 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 28 Sep 2010 18:47:02 -0400 Subject: [csw-maintainers] apache2 update issue Message-ID: <1285713664-sup-4656@pinkfloyd.chass.utoronto.ca> Hi All, I'm soliciting a recommendation for how to handle a bug with the old apache removal process. If you install CSWapache2, you get CSWapache2, CSWapache2c, CSWapache2rt and CSWap2prefork. At this point, due to use of installf in the postinstall of CSWap2prefork, CSWap2prefork owns /opt/csw/apache2/sbin/httpd. If you now install CSWap2worker to get the httpd.worker mpm, You'll have CSWap2worker as the owner of sbin/httpd (postinstall script again), while the httpd.prefork binary lives at sbin/httpd.prefork and sbin/httpd.worker-save. Upon removal, CSWap2worker removes sbin/httpd since it is the registered owner, It then moves sbin/httpd.worker-save back to sbin/httpd to clean up after itself. Now, if you remove the rest of the apache2 stack, you get sbin/httpd left behind as it has no owner. When the new packages come along, alternatives balks at creating the symlinks required due to an existing binary...this is good, but leaves the wrong httpd in place. I suspect that the only good solution is a preinstall script for the new CSWapache2 that will do: HTTPD=$PKG_INSTALL_ROOT/opt/csw/apache2/sbin/httpd PKG_INSTALL_ROOT= [ -x "$HTTPD" ] && rm -f "$HTTPD" Anyone got a more creative idea for handling this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Sep 29 02:29:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 28 Sep 2010 17:29:45 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: No dia 28 de Setembro de 2010 10:57, Philip Brown escreveu: > On 9/28/10, Maciej (Matchek) Blizinski wrote: >> >> Yes, I support that. ?I did a quick search and found that Debian policy >> says: >> >> "The run-time shared library must be placed in a package whose name >> changes whenever the SONAME of the shared library changes. (...) >> Normally, the run-time shared library and its SONAME symlink should be >> placed in a package named librarynamesoversion, where soversion is the >> version number in the SONAME of the shared library." >> >> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime > > > Hmm. Well, it's a good start. By "start", do you mean only the quotation, or the whole thing? > There are two unmentioned issues that come to my mind: > 1. where the name is just Really Stupid :) I understand you reserve a right to say "no". > 2. where the name may not neccessarily imply, "hey this is a library". Can it ever not begin with "lib"? I thought that when you link using the -lfoo flag, the linker will only link with libfoo.so, nothing else. Hence, the file must be named libfoo, and so must the package. > For those cases, I'm a little leery of going with a hard line "name > must exactly match SONAME" policy. > I think that having that as a guideline would be okay though. > > >> I could write a checkpkg test: if there's a shared in /opt/csw/lib >> (including ISA subdirectories), and has a SONAME, the pkgname must >> conform to: >> >> CSWlibrarynamesonameversion or CSWlibraryname-sonameversion >> > > See above. I dont think it should be put as a blocking checkpkg test. > > Also, theres the issue that this is an OPTIONAL split-out. > We were talking about doing this for *some* shared libs, but not all. With checkpkg, all errors are equal and all can be overridden the same way. This way, no test is a blocking one. I try to keep the false positive rate to a minimum, but without giving up the promotion of our policies. In this case, if checkpkg displays an error about the package name not matching the shared library within it, the maintainer will still be able to override the error and do whatever he wants. The role of checkpkg is only a supporting one, and it's ultimately humans who make the decisions. > But just to be nitpicky... > >> If it's not under /opt/csw/lib, or is not a binary, or not a shared >> library, or doesn't have a soname, then the rule doesn't apply. > > If it doesnt have a soname, then things default to using the filename, > I believe. so we'd still need to have the package name change if the > filename changed. Right, and a new package is created. The old package stays around with the old name, until it becomes unreferenced and obsolete. I wrote an example implementation of that, worked nicely on a couple examples, but I haven't yet run it against the whole catalog. Here's an excerpt from a unit test: + self.error_mgr_mock.ReportError( + 'shared-lib-wrong-pkgname', + "file=opt/csw/lib/libneon.so.26.0.4 pkgname=CSWneon " + "expected=['CSWlibneon26', 'CSWlibneon-26']") From bwalton at opencsw.org Wed Sep 29 04:38:26 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 28 Sep 2010 22:38:26 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs ap2_suexec, apache2, apache2_devel, a(...) In-Reply-To: References: <201009242241.o8OMflW5021408@login.bo.opencsw.org> <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> Message-ID: <1285727779-sup-5452@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Sep 27 09:41:53 -0400 2010: > when do you want me to release this Ben? There are some fairly large issues with the package as it stands. Woody noticed problems with alternatives (a typo) that I corrected. I also found the removal bug in the old packages and a problem with the httpd.conf delivery in the new setup that prevented apache from starting after an update or fresh install. More tweaking and testing is required... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Sep 29 18:16:45 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 29 Sep 2010 09:16:45 -0700 Subject: [csw-maintainers] apache2 update issue In-Reply-To: <1285713664-sup-4656@pinkfloyd.chass.utoronto.ca> References: <1285713664-sup-4656@pinkfloyd.chass.utoronto.ca> Message-ID: On 9/28/10, Ben Walton wrote: > > When the new packages come along, alternatives balks at creating the > symlinks required due to an existing binary...this is good, but leaves > the wrong httpd in place. > > I suspect that the only good solution is a preinstall script for the > new CSWapache2 that will do: > > HTTPD=$PKG_INSTALL_ROOT/opt/csw/apache2/sbin/httpd > PKG_INSTALL_ROOT= > [ -x "$HTTPD" ] && rm -f "$HTTPD" > > Anyone got a more creative idea for handling this? > creative idea: dont use alternatives. Or at least, not on that path. Put that path as a "real file" wrapper of some kind. Then you could either put some kind of "alternatives" type logic in the wrapper, or merely have it exec some other path that is implemented with the alternatives package. /opt/csw/apache2/sbin/httpd.bin ? (personally, I'd favor the "straight wrapper, forget about alternatives" approach, but I dont care either way) From phil at bolthole.com Wed Sep 29 18:17:58 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 29 Sep 2010 09:17:58 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs ap2_suexec, apache2, apache2_devel, a(...) In-Reply-To: <1285727779-sup-5452@pinkfloyd.chass.utoronto.ca> References: <201009242241.o8OMflW5021408@login.bo.opencsw.org> <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> <1285727779-sup-5452@pinkfloyd.chass.utoronto.ca> Message-ID: On 9/28/10, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Sep 27 09:41:53 -0400 2010: > >> when do you want me to release this Ben? > > There are some fairly large issues with the package as it stands. > Woody noticed problems with alternatives (a typo) that I corrected. I > also found the removal bug in the old packages and a problem with the > httpd.conf delivery in the new setup that prevented apache from > starting after an update or fresh install. More tweaking and testing > is required... > okay. in that case, I've done what I dont usually do, and preemptively removed the old packages sitting in newpkgs. From phil at bolthole.com Wed Sep 29 18:32:21 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 29 Sep 2010 09:32:21 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: On 9/28/10, Maciej (Matchek) Blizinski wrote: > No dia 28 de Setembro de 2010 10:57, Philip Brown > escreveu: >> >> 2. where the name may not neccessarily imply, "hey this is a library". > > Can it ever not begin with "lib"? I thought that when you link using > the -lfoo flag, the linker will only link with libfoo.so, nothing > else. Hence, the file must be named libfoo, and so must the package. But there are other ways to use a dynamic object, other than linking with -lfoo. We have a plethora of such beasts. The related question would be whether it would be justified to ever create a separate package around them. Most of them are more the realm of dynamically loaded objects. An extreme case would be the gimp modules/plugins. Probably most of those things, arent versioned in the same way as regular shared libraries, so perhaps it is not an issue. But it still bears consideration. >> >>> I could write a checkpkg test: if there's a shared in /opt/csw/lib >>> (including ISA subdirectories), and has a SONAME, the pkgname must >>> conform to: >>> >>> CSWlibrarynamesonameversion or CSWlibraryname-sonameversion What about if there are multiple objects in the package? From bwalton at opencsw.org Wed Sep 29 18:35:01 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 29 Sep 2010 12:35:01 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs ap2_suexec, apache2, apache2_devel, a(...) In-Reply-To: References: <201009242241.o8OMflW5021408@login.bo.opencsw.org> <1285371565-sup-8881@pinkfloyd.chass.utoronto.ca> <1285419148-sup-2448@pinkfloyd.chass.utoronto.ca> <1285727779-sup-5452@pinkfloyd.chass.utoronto.ca> Message-ID: <1285778080-sup-9669@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Sep 29 12:17:58 -0400 2010: > okay. in that case, I've done what I dont usually do, and > preemptively removed the old packages sitting in newpkgs. Gracias. I should have new ones ready this evening if all goes well. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Sep 29 19:40:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 29 Sep 2010 10:40:47 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: No dia 29 de Setembro de 2010 09:32, Philip Brown escreveu: > On 9/28/10, Maciej (Matchek) Blizinski wrote: >> No dia 28 de Setembro de 2010 10:57, Philip Brown >> escreveu: >>> >>> 2. where the name may not neccessarily imply, "hey this is a library". >> >> Can it ever not begin with "lib"? ?I thought that when you link using >> the -lfoo flag, the linker will only link with libfoo.so, nothing >> else. ?Hence, the file must be named libfoo, and so must the package. > > But there are other ways to use a dynamic object, other than linking with -lfoo. > We have a plethora of such beasts. > The related question would be whether it would be justified to ever > create a separate package around them. > Most of them are more the realm of dynamically loaded objects. > An extreme case would be the gimp modules/plugins. > > Probably most of those things, arent versioned in the same way as > regular shared libraries, so perhaps it is not an issue. But it still > bears consideration. Do we have instances in which we package multiple version of the same dynamically loaded object into one package? I think not, but if we had, they could be separated as well. >>>> I could write a checkpkg test: if there's a shared in /opt/csw/lib >>>> (including ISA subdirectories), and has a SONAME, the pkgname must >>>> conform to: >>>> >>>> CSWlibrarynamesonameversion or CSWlibraryname-sonameversion > > What about if there are multiple objects in the package? The idea is to not have multiple objects in one package. It's best of the granularity corresponds to the chunks in which we'll phase out shared libraries. If there are multiple libraries that are to be phased out together, they could live in one package. However, this might be hard to predict, so it's safer to have each object in a separate package. There's one more thing: symlinks. With two versions of one library, we might have two packages: CSWlibfoo0: /opt/csw/lib/libfoo.so ? libfoo.so.0 /opt/csw/lib/libfoo.so.0 ? libfoo.so.0.0 /opt/csw/lib/libfoo.so.0.0 ? /opt/csw/lib/libfoo.so.0.0.1 /opt/csw/lib/libfoo.so.0.0.1 (actual data) CSWlibfoo1: /opt/csw/lib/libfoo.so ? libfoo.so.1 /opt/csw/lib/libfoo.so.1 ? libfoo.so.1.0 /opt/csw/lib/libfoo.so.1.0 ? /opt/csw/lib/libfoo.so.1.0.1 /opt/csw/lib/libfoo.so.1.0.1 (actual data) With this layout, we end up with two instances of /opt/csw/lib/libfoo.so. This file needs to be in a different package, I'd say in the same package as the header files. It could be a *-devel package or the main package. The corrected layout: CSWlibfoo-devel: /opt/csw/include/foo.h /opt/csw/lib/libfoo.so ? libfoo.so.1 CSWlibfoo0: /opt/csw/lib/libfoo.so.0 ? libfoo.so.0.0 /opt/csw/lib/libfoo.so.0.0 ? /opt/csw/lib/libfoo.so.0.0.1 /opt/csw/lib/libfoo.so.0.0.1 (actual data) CSWlibfoo1: /opt/csw/lib/libfoo.so.1 ? libfoo.so.1.0 /opt/csw/lib/libfoo.so.1.0 ? /opt/csw/lib/libfoo.so.1.0.1 /opt/csw/lib/libfoo.so.1.0.1 (actual data) From phil at bolthole.com Wed Sep 29 20:47:19 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 29 Sep 2010 11:47:19 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: On 9/29/10, Maciej (Matchek) Blizinski wrote: > > Do we have instances in which we package multiple version of the same > dynamically loaded object into one package? I think not, but if we > had, they could be separated as well. not to my memory. The "include older binary versions" issue, usually (possibly ONLY) comes up for traditional shared libraries only. >> What about if there are multiple objects in the package? > > The idea is to not have multiple objects in one package. It's best of > the granularity corresponds to the chunks in which we'll phase out > shared libraries. If there are multiple libraries that are to be > phased out together, they could live in one package. However, this > might be hard to predict, so it's safer to have each object in a > separate package. There are some things that conceptually should always be grouped together. For example: atspi /opt/csw/lib/libcspi.so.0.10.11 /opt/csw/lib/libloginhelper.so.0.0.0 /opt/csw/lib/libspi.so.0.10.11 augeas /opt/csw/lib/libaugeas.so.0.10.1 /opt/csw/lib/libfa.so.1.3.0 boost_rt (a BUNCH) fltk /opt/csw/lib/libfltk.so.1.1 /opt/csw/lib/libfltk_forms.so.1.1 /opt/csw/lib/libfltk_gl.so.1.1 /opt/csw/lib/libfltk_images.so.1.1 It would arguably be a mistake, to get into a packaging scheme which might allow some of these to accidentally get out of sync with one another. Ideally, in my opinion, they should remain as part of a single unified runtime package. > CSWlibfoo-devel: > /opt/csw/include/foo.h > /opt/csw/lib/libfoo.so ? libfoo.so.1 I agree, libxxx.so symlinks belong in devel packages. If you split out a runtime, you dont need the libxxx.so symlink. (but that's what we do right now already, I think. We just ship the "real" file, with no symlinks, in our "rt" packages) Random comment: I think that libraries with SONAMEs that include minor revs, are more likely to fall prey to the need for splitting out. In contrast, libraries that have ONLY a major rev: "libxxx.so.1" - tend to play nicely and respect compatibility between revs very well. (and by implication, will probably not need fancy sub-packages). So you might go easy on the checkpkg checks, in those cases. From hson at opencsw.org Thu Sep 30 01:05:10 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Thu, 30 Sep 2010 01:05:10 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: <4CA3C626.8040300@opencsw.org> On 2010-09-29 20:47, Philip Brown wrote: > On 9/29/10, Maciej (Matchek) Blizinski wrote: >> >> Do we have instances in which we package multiple version of the same >> dynamically loaded object into one package? I think not, but if we >> had, they could be separated as well. > > not to my memory. > The "include older binary versions" issue, usually (possibly ONLY) > comes up for traditional shared libraries only. > Well, imagemagick actually have both old shared libraries plus other dynamically loaded objects, however those objects are only loaded by the libraries and not by external applications (at least as far as I know). From hson at opencsw.org Thu Sep 30 01:07:07 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 30 Sep 2010 01:07:07 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: <4CA3C69B.5000101@opencsw.org> On 2010-09-28 02:23, Maciej (Matchek) Blizinski wrote: > No dia 26 de Setembro de 2010 14:37, Philip Brown escreveu: >> I did not see anything in the proposal that mentioned how to handle >> catalog naming; only svr4 package names. that is why it seems so >> clean. >> once you step into that realm things become more messy. >> remember that upstream numbering is sometimes out of sync with the lib >> numbering. >> >> your proposal may "simplify" the number of versions of a library per >> package . however, it will *add* complexity to the naming and package >> building process in other ways. >> >> I'm not neccessarily against it. I'm just pointing out it isn't >> neccessarily the "simple" choice > > It's true. Specifically problematic are bits of software that already > embed a number in the package name, or the soname. For example > apache2rt package contains libapr-1.so.0. The corresponding pkgname > would be something along the lines of CSWlibapr10 or CSWlibapr-10, or > other punctuation variants. Shouldn't that be CSWlibapr1-0? Or what should you name the package when libapr-1.so.10.0.0 get released? From maciej at opencsw.org Thu Sep 30 02:06:44 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 29 Sep 2010 17:06:44 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: No dia 29 de Setembro de 2010 11:47, Philip Brown escreveu: >>> What about if there are multiple objects in the package? >> >> The idea is to not have multiple objects in one package. ?It's best of >> the granularity corresponds to the chunks in which we'll phase out >> shared libraries. ?If there are multiple libraries that are to be >> phased out together, they could live in one package. ?However, this >> might be hard to predict, so it's safer to have each object in a >> separate package. > > There are some things that conceptually should always be grouped together. > > For example: > atspi > /opt/csw/lib/libcspi.so.0.10.11 > ?/opt/csw/lib/libloginhelper.so.0.0.0 > ?/opt/csw/lib/libspi.so.0.10.11 > > augeas > ?/opt/csw/lib/libaugeas.so.0.10.1 > ?/opt/csw/lib/libfa.so.1.3.0 > > boost_rt > ?(a BUNCH) > > fltk > ?/opt/csw/lib/libfltk.so.1.1 > ?/opt/csw/lib/libfltk_forms.so.1.1 > ?/opt/csw/lib/libfltk_gl.so.1.1 > ?/opt/csw/lib/libfltk_images.so.1.1 > > It would arguably be a mistake, to get into a packaging scheme which > might allow some of these to accidentally get out of sync with one > another. Does the concept of being out of sync apply to separate packages? This would be an example of an out-of-sync collection: CSWlibfoo0: /opt/csw/lib/libfoo.so.0 /opt/csw/lib/libfoo_bar.so.1 /opt/csw/lib/libfoo_baz.so.0 If you had them packaged as follows, you couldn't call them as being out-of-sync. CSWlibfoo0: /opt/csw/lib/libfoo.so.0 CSWlibfoo-bar1: /opt/csw/lib/libfoo_bar.so.1 CSWlibfoo-baz0: /opt/csw/lib/libfoo_baz.so.0 Each dependent package would refer to the exact shared library it uses. Boost library package is a collection of functionally unrelated shared libraries, I think it makes sense to split them out: why would download all of them if you only needed one? The general point stands, that there are situations in which it makes sense to group shared libraries together. The deciding factor should be the phasing out of the libraries: if we expect to remove them together, we can package them together. >From the checkpkg development point of view, it's best to provide a test that suggests the right thing as often as possible. Using heuristics is alright, if they have good enough hit rate. The base rule is: "If a package contains a shared library, the package must be named in such and such way." This rule can be extended to allow exceptions such as using the longest common substring, or something similar. I doesn't need to cover 100% cases, but the more, the better. > Ideally, in my opinion, they should remain as part of a single unified > runtime package. Did I already say that I consider the "runtime" word a misleading one in this context? Shared libraries are runtime files, but not all runtime files are shared libraries. For example, a Python "runtime" package would need to include the interpreter. However, libpython26 package doesn't suggest that "it's what you need to run Python programs". But this is another discussion; we could fork this thread if anyone feels like pursuing that topic. >> CSWlibfoo-devel: >> /opt/csw/include/foo.h >> /opt/csw/lib/libfoo.so ? libfoo.so.1 > > I agree, libxxx.so symlinks belong in devel packages. If you split out > a runtime, you dont need the libxxx.so symlink. > (but that's what we do right now already, I think. We just ship the > "real" file, with no symlinks, in our "rt" packages) The file with the data is usually named ${soname}.x.y, which will not be enough for runtime linker which looks specifically for ${soname}, I believe the library (or soname-providing) package should include all three to be fully functional: ${soname} ? ${soname}.x ${soname}.x ? ${soname}.x.y ${soname}.x.y (data) > Random comment: I think that libraries with SONAMEs that include minor > revs, are more likely to fall prey to the need for splitting out. > In contrast, libraries that have ONLY a major rev: ?"libxxx.so.1" - > tend to play nicely and respect compatibility between revs very well. > (and by implication, will probably not need fancy sub-packages). ? So > you might go easy on the checkpkg checks, in those cases. You mean, these where the soname has the form of libfoo.so.1.2? I think we best follow what linker does, which is the soname. Roger wrote: >> (...) CSWlibapr10 or CSWlibapr-10, (...) > Shouldn't that be CSWlibapr1-0? > Or what should you name the package when libapr-1.so.10.0.0 get released? libapr-1.so.10.0.0 would be... let's run my current algorithm... here it is: pkgname: ['CSWlibapr-110', 'CSWlibapr-1-10'] catalogname: ['libapr_110', 'libapr_1_10'] The policy would be: take the former, but if it's confusing, take the latter. I'd vote for CSWlibapr-1-10 + libapr_1_10. From bwalton at opencsw.org Thu Sep 30 04:33:10 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 29 Sep 2010 22:33:10 -0400 Subject: [csw-maintainers] call for apache2 testing Message-ID: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca> Hi All, I've placed what I think is a working set of apache2 packages in my experimental catalog. The changes noted previously (package split re-org, alternatives, etc) still stand with a few other changes added: 1. Dummy packages are provided for ap2_prefork and apache2rt. Other packages depend on these, so unfortunately they'll still live for a while longer. We're still I with apache2c and ap2_worker 2. I've added a new CAS, cswap2mod, that will toggle the enabled/commented state of a module in httpd.conf. This is demonstrated in the ap2_suexec package (which used postinstall/preremove scripts for this previously). 3. #2 above requires the updated cswclassutils also in my catalog. Any testing you can provide is appreciated. I'd prefer that this update not blow up web servers. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Thu Sep 30 05:10:57 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 30 Sep 2010 05:10:57 +0200 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: Message-ID: <4CA3FFC1.2090805@opencsw.org> On 2010-09-28 18:54, Philip Brown wrote: > I'm guessing that debian already has a naming policy for this sort of > thing, since I vaguely recall seeing some naming that I considered > really ugly at the time. > So interested parties should probably do a little research on other > distros, to avoid needlessly introducing "yet another naming scheme" > if there is an existing accepted one already out there. For the libraries I've maintain it looks like neither OpenSuSE nor Fedora/RedHat have any standard. Some libraries are packaged as libLIBVERSION-UPSTREAMFULLVERSION-DISTROVERSION (like libMagickCore1-6.4.5.4-15.1.x86_64.rpm whih includes libMagickCore.so.1.0.0 from ImageMagick 6.4.5-4). Others have libUPSTREAMMAJORVERSION-UPSTREAMFULLVERSION-DISTROVERSION (like libsoup22-2.2.100-50.23.x86_64.rpm which includes libsoup-2.2.so.8.5.0 from libsoup-2.2.100) From maciej at opencsw.org Thu Sep 30 08:33:18 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 29 Sep 2010 23:33:18 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: <4CA3FFC1.2090805@opencsw.org> References: <4CA3FFC1.2090805@opencsw.org> Message-ID: I ran my new code against the whole catalog to see what happens: how many shared libraries are there, what are they, etc. Here's the report: http://bender.opencsw.org/~maciej/shlib-tags.txt Please bear in mind that it is the first iteration. The check makes good suggestions for some packages, but crappy for others. It also does not do any grouping. An example of a good suggestion: file=opt/csw/lib/libfaac.so.0.0.0 pkgname=CSWfaac expected=['CSWlibfaac0', 'CSWlibfaac-0'] file=opt/csw/lib/sparcv9/libfaac.so.0.0.0 pkgname=CSWfaac expected=['CSWlibfaac0', 'CSWlibfaac-0'] A good example of a bad suggestion: file=opt/csw/lib/vhook/drawtext.so pkgname=CSWffmpeg expected=['CSWdrawtext'] file=opt/csw/lib/vhook/fish.so pkgname=CSWffmpeg expected=['CSWfish'] file=opt/csw/lib/vhook/imlib2.so pkgname=CSWffmpeg expected=['CSWimlib2'] file=opt/csw/lib/vhook/null.so pkgname=CSWffmpeg expected=['CSWnull'] file=opt/csw/lib/vhook/ppm.so pkgname=CSWffmpeg expected=['CSWppm'] I don't have a good idea for automating these. CSWnull is a poor suggestion, but I don't have a better one myself. These are weird shared object files, without sonames, without versions, in a subdirectory under lib. Perhaps these should be excluded from the check at all. There are 3 other files in CSWffmpeg: file=opt/csw/lib/libavcodec-0.4.9-pre1.so pkgname=CSWffmpeg expected=['CSWlibavcodec-0-4-9-pre1'] file=opt/csw/lib/libavformat-0.4.9-pre1.so pkgname=CSWffmpeg expected=['CSWlibavformat-0-4-9-pre1'] file=opt/csw/lib/libpostproc.so.0.0.1 pkgname=CSWffmpeg expected=['CSWlibpostproc0', 'CSWlibpostproc-0'] With these three, I don't know myself - does it make sense to separate these 3 libraries? Two of them seem to have the version in sync, but the version is entangled with the library name, instead of being located after the ".so" bit, where nature intended. There are 2 general categories of rules: one is figuring out how to exclude libraries; how to choose the ones that are unlikely to be linked to, such as /opt/csw/lib/gnucash/libgncmod-register-core.so.0.0.0. The second one is how to figure out sensible groups of shared libraries to contain within one package. There's also the idea that checkpkg could get hints from elsewhere in the package. For example, a special flag in pkginfo could hint about the shared libraries. It's only a vague idea at the moment. If people have ideas for rules for handling these suggestions, please share them. If you maintain a package with shared library, you can locate the relevant part of the report, quote it and suggest what you believe would be a good file/package layout in your case. From dam at opencsw.org Thu Sep 30 11:06:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 30 Sep 2010 11:06:43 +0200 Subject: [csw-maintainers] Web-access to the buildfarm In-Reply-To: References: <4CA3FFC1.2090805@opencsw.org> Message-ID: <4B52C0B9-C803-483F-AD50-F83668CAE70C@opencsw.org> Hi Maciej, Am 30.09.2010 um 08:33 schrieb Maciej (Matchek) Blizinski: > http://bender.opencsw.org/~maciej/shlib-tags.txt It looks like most of the maintainers are unaware that you can publish directly from the buildfarm: Just create /home//public_html and put public readable stuff in it and you can access it immediately by http://buildfarm.opencsw.org/~ No need to transfer anything to bender (at least for this) :-) Best regards -- Dago From dam at opencsw.org Thu Sep 30 15:04:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 30 Sep 2010 15:04:23 +0200 Subject: [csw-maintainers] New Subversion bound against apr available Message-ID: Hi, a new version of Subversion now bound against APR and APR-Util instead of apache2rt is now available from http://buildfarm.opencsw.org/experimental.html#subversion Best regards -- Dago From maciej at opencsw.org Thu Sep 30 19:30:26 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 30 Sep 2010 10:30:26 -0700 Subject: [csw-maintainers] An idea for a shared libraries policy In-Reply-To: References: <4CA3FFC1.2090805@opencsw.org> Message-ID: Updated location of the preliminary checkpkg results: http://buildfarm.opencsw.org/~maciej/shlib-tags.txt From phil at bolthole.com Thu Sep 30 20:35:13 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Sep 2010 11:35:13 -0700 Subject: [csw-maintainers] call for apache2 testing In-Reply-To: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca> References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca> Message-ID: > 3. #2 above requires the updated cswclassutils also in my catalog. > is it really appropriate to use a class action script for this? I'm not sure it is. and even if it is.... might it be more appropriate to split it out into it's own package? From bwalton at opencsw.org Thu Sep 30 20:43:18 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 30 Sep 2010 14:43:18 -0400 Subject: [csw-maintainers] call for apache2 testing In-Reply-To: References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca> Message-ID: <1285871973-sup-9588@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Sep 30 14:35:13 -0400 2010: > is it really appropriate to use a class action script for this? I'm > not sure it is. Well, it's a common installation task that is typically delivered by a script. So I'd argue that yes, it is a good candidate (else I wouldn't have written it). There are a bunch of ap2_* packages that can leverage this shared code now without popping up the 'this package runs scripts as root...' bit. Although the option isn't currently available, I'd also suggest that csw.conf could be used to determine whether the module is added and enabled or simply added (prefixed with #). I'll extend the CAS tonight to honour ap2_enable_default and ap2_enable_$module values in a similar vein to the service on/off settings. (Documented, of course.) > and even if it is.... might it be more appropriate to split it out > into it's own package? Yes, we'd agreed previously that we would put each CAS into it's own package. I just haven't gotten to the actual splitting yet. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at baltic-online.de Thu Sep 23 11:50:35 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Thu, 23 Sep 2010 11:50:35 +0200 Subject: [csw-maintainers] Subversion update to 1.6.12 Message-ID: <06A8F5EC-1F81-4B42-9277-FEB69F861557@baltic-online.de> Hi, I just bumped Subversion to 1.6.12: http://buildfarm.opencsw.org/experimental.html#subversion I updated svn on testing9s, everybody feel free to try. Best regards -- Dago