From phil at bolthole.com Tue Mar 1 04:01:27 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Feb 2011 19:01:27 -0800 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot Message-ID: I just tried to vote on this finally. Sadly, it seems the ballot is invalid. While the discussions on the list, and the "writeup" agreed that it should be possible to vote for "0 to 3" board positions to have the key, voting for 0, is not accepted. The wording around it, seems to imply that you "must" vote for at least one, which is bad enough. But the vote is configured to actually *REQUIRE* that you vote for at least one, in that "group" for the ballot. Also, why is there not a link to the writeup, in the actual ballot? I thought that was at least agreed upon. Bad enough that the wording itself is not there. But not even a link to it? From phil at bolthole.com Tue Mar 1 07:39:41 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Feb 2011 22:39:41 -0800 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: I also have to point out, that there was a "late entry" to this ballot, that was not properly investigated or written up. The issue of key escrow. (it was for this sort of reason exactly, that I requested that the exact ballot wording be made public before the vote was made active. Not this shell game of, "well, we'll make a separate 'writeup' first, but the actual ballot will be separate, and out of view, until the actual vote is active) The specific problem, is that "escrow" may imply to some people, that it addresses the issue of "cannot take back a key, once it is handed out". Unfortunately, the proposed method (sssh, or whatever it was called), does not do that (to the best of my knowlege). It splits up the key across (N) people. However, once their term of office is ended, the same people still have the same parts of the key. Nothing stops them from getting together and using it after their term has ended. If my summary of the escrow is valid, please adjust the wording to make that clear (or preferably just remove the secondary question entirely), when the ballot is fixed and restarted. From maciej at opencsw.org Tue Mar 1 09:43:29 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 1 Mar 2011 08:43:29 +0000 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: 2011/3/1 Philip Brown : > I just tried to vote on this finally. Sadly, it seems the ballot is > invalid. While the discussions on the list, and the "writeup" agreed > that it should be possible to vote for "0 to 3" board positions to > have the key, voting for 0, is not accepted. > > The wording around it, seems to imply that you "must" vote for at > least one, which is bad enough. > But the vote is configured to actually *REQUIRE* that you vote for at > least one, in that "group" for the ballot. Yes, that's a bug. I didn't realize the consequences of picking a required, grouped Yes/No multiple-answer vote. Sorry about that. I'm preparing a new ballot, with four two-item radio button groups. This way, an independent yes/no answer will be possible for every question. > Also, why is there not a link to the writeup, in the actual ballot? Because ballotbin does not support adding any text directly to the actual ballot. The closest you can do, is adding a biographical note to a specific answer on the ballot. You cannot add anything on the ballot level. If answers are on the answer level, and you have a single writeup, you cannot add the link to just one answer; because it could be construed as suggesting a particular answer. If not to just one, you have to add the note to every answer. As Peter F likes, to say: consequently, I've added the link to each of the 8 answers. > I thought that was at least agreed upon. When discussing the dev/devel vote, we agreed[1] on sending the writeup. 2011/3/1 Philip Brown : > I also have to point out, that there was a "late entry" to this > ballot, that was not properly investigated or written up. > The issue of key escrow. > > (it was for this sort of reason exactly, that I requested that the > exact ballot wording be made public before the vote was made active. > ?Not this shell game of, "well, we'll make a separate 'writeup' > first, but the actual ballot will be separate, and out of view, until > the actual vote is active) > > The specific problem, is that "escrow" may imply to some people, that > it addresses the issue of "cannot take back a key, once it is handed > out". > Unfortunately, the proposed method (sssh, or whatever it was called), > does not do that (to the best of my knowlege). > > ?It splits up the key across (N) people. However, once their term of > office is ended, the same people still have the same parts of the key. > Nothing stops them from getting together and using it after their term > has ended. True. The escrow option is not about revoking access; it's about distributing access. It is not worse not better than the other options. The threat that escrow protects against, is a single board member using the key without the consent of other board members. Using the key after the term of office ends, is another threat which needs another solution. > If my summary of the escrow is valid, please adjust the wording to > make that clear (or preferably just remove the secondary question > entirely), when the ballot is fixed and restarted. Since the vote is not about key revocation, I see no reason to remove the escrow question. However, since there seems to be disagreement about what the ballot should look like, I won't send out a new one before this issue is settled. Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-February/014221.html From maciej at opencsw.org Tue Mar 1 12:20:25 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 1 Mar 2011 11:20:25 +0000 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: 2011/3/1 Maciej Blizi?ski : > However, since there seems to be disagreement about what the ballot > should look like, I won't send out a new one before this issue is > settled. Phil, would you mind adjusting the wording on the wiki? I have unlocked the writeup page: http://wiki.opencsw.org/vote-gpgkey If others agree with the updated writeup, I'll activate the new ballot. Maciej From maciej at opencsw.org Tue Mar 1 14:11:25 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Tue, 1 Mar 2011 14:11:25 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <1296994980-22573-1-git-send-email-maciej@opencsw.org> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> Message-ID: <1298985086-1852-1-git-send-email-maciej@opencsw.org> There has been lately no progress on the issue on the initial patch. The current state of opinions about the latest version of the patch[1] is as follows: Maciej Blizi??ski: For subsmission as presented Peter Felecan: For submission as presented Phil Brown: Against submission as presented The objection from Phil was that copyright is not necessary, while others (also outside the policy team) believe it is. There was a suggestion[2] to take out the abstract from the patch. I did that, here's the patch which only sets the license. Policy team, RSVP. Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html [2] http://lists.opencsw.org/pipermail/maintainers/2011-February/014104.html From maciej at opencsw.org Tue Mar 1 14:11:26 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Tue, 1 Mar 2011 14:11:26 +0100 Subject: [csw-maintainers] =?utf-8?q?=5BPATCH=5D_opencsw-policy=3A_The_cop?= =?utf-8?q?yright_notice?= In-Reply-To: <1296994980-22573-1-git-send-email-maciej@opencsw.org> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> Message-ID: <1298985086-1852-2-git-send-email-maciej@opencsw.org> This patch sets the copyright of policy package and policy documents to GPL-2.0+. --- pkg/opencsw-policy/trunk/Makefile | 4 ++-- pkg/opencsw-policy/trunk/checksums | 2 +- pkg/opencsw-policy/trunk/files/index.txt | 25 ++++++++++++++++++++++++- 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/pkg/opencsw-policy/trunk/Makefile b/pkg/opencsw-policy/trunk/Makefile index e2f2c18..c7adc07 100644 --- a/pkg/opencsw-policy/trunk/Makefile +++ b/pkg/opencsw-policy/trunk/Makefile @@ -10,14 +10,14 @@ define BLURB endef SPKG_SOURCEURL = http://www.opencsw.org MASTER_SITES = http://www.gnu.org/licenses/ -DISTFILES = fdl-1.3.txt +DISTFILES = gpl-2.0.txt CONFIGURE_SCRIPTS = BUILD_SCRIPTS = policy INSTALL_SCRIPTS = policy TEST_SCRIPTS = ARCHALL_CSWopencsw-policy = 1 CATALOGNAME_CSWopencsw-policy = opencsw_policy -LICENSE = fdl-1.3.txt +LICENSE = gpl-2.0.txt BUILD_DEP_PKGS = CSWasciidoc diff --git a/pkg/opencsw-policy/trunk/checksums b/pkg/opencsw-policy/trunk/checksums index e6fa4f0..6986890 100644 --- a/pkg/opencsw-policy/trunk/checksums +++ b/pkg/opencsw-policy/trunk/checksums @@ -1 +1 @@ -10b9de612d532fdeeb7fe8fcd1435cc6 fdl-1.3.txt +b234ee4d69f5fce4486a80fdaf4a4263 gpl-2.0.txt diff --git a/pkg/opencsw-policy/trunk/files/index.txt b/pkg/opencsw-policy/trunk/files/index.txt index 7e9ee64..1433795 100644 --- a/pkg/opencsw-policy/trunk/files/index.txt +++ b/pkg/opencsw-policy/trunk/files/index.txt @@ -3,5 +3,28 @@ OpenCSW packaging policy $Id: Makefile 11888 2010-12-12 12:43:48Z skayser $ :toc: :website: http://www.opencsw.org - :leveloffset: 1 + +Copyright Notice +================ + +Copyright ? 2011 OpenCSW + +Parts of this manual are copied from the Debian GNU/Linux policy manual. +This manual is released with compliance with Debian manual's licensing +terms. + +This manual is free software; you may redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. + +This is distributed in the hope that it will be useful, but without any +warranty; without even the implied warranty of merchantability or +fitness for a particular purpose. See the GNU General Public License for +more details. + +A copy of the GNU General Public License is available on the World Wide +Web at the GNU General Public Licence. You can also obtain it by writing +to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, +Boston, MA 02110-1301, USA. -- 1.7.3.2 From pfelecan at opencsw.org Tue Mar 1 14:26:13 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 01 Mar 2011 14:26:13 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <1298985086-1852-1-git-send-email-maciej@opencsw.org> (Maciej Blizinski's message of "Tue, 1 Mar 2011 14:11:25 +0100") References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: Maciej Blizinski writes: > There has been lately no progress on the issue on the initial patch. The > current state of opinions about the latest version of the patch[1] is as > follows: > > Maciej Blizi??ski: For subsmission as presented > Peter Felecan: For submission as presented > Phil Brown: Against submission as presented > > The objection from Phil was that copyright is not necessary, while others > (also outside the policy team) believe it is. There was a suggestion[2] to take > out the abstract from the patch. > > I did that, here's the patch which only sets the license. > > Policy team, RSVP. 1. copyright and license: alright for me, the only suggestion is to use GPL 3 as is the more current. 2. abstract: call it what you want but we need an introductory text and what was presented under the heading of "abstract" it's exactly that; I don't understand why you removed it: the discussion implied 3 persons among which 2 were for keeping the abstract. It's that not good enough? -- Peter From jcraig at opencsw.org Tue Mar 1 15:33:13 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Tue, 1 Mar 2011 09:33:13 -0500 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: On Tue, Mar 1, 2011 at 8:26 AM, Peter FELECAN wrote: > Maciej Blizinski writes: > >> There has been lately no progress on the issue on the initial patch. ?The >> current state of opinions about the latest version of the patch[1] is as >> follows: >> >> Maciej Blizi??ski: For subsmission as presented >> Peter Felecan: For submission as presented >> Phil Brown: Against submission as presented >> >> The objection from Phil was that copyright is not necessary, while others >> (also outside the policy team) believe it is. ?There was a suggestion[2] to take >> out the abstract from the patch. >> >> I did that, here's the patch which only sets the license. >> >> Policy team, RSVP. > > 1. copyright and license: alright for me, the only suggestion is to use > ? GPL 3 as is the more current. > > 2. abstract: call it what you want but we need an introductory text and > ? what was presented under the heading of "abstract" it's exactly that; > ? I don't understand why you removed it: the discussion implied 3 > ? persons among which 2 were for keeping the abstract. It's that not > ? good enough? > I agree, a copyright is needed. Without a specified copyright then people who wish to build on our work are left with a conundrum. Either they choose to see the lack of copyright as placing the work in the public domain or they choose to see it as all rights reserved. This would also jeopardize our efforts to evolve the document over time as we would have to assume "public domain" or get the permission of each persons submission to use/modify it at need. Assuming "public domain" leaves one open to legal issues in the future. I also feel the abstract/preamble/forward as appropriate and necessary but I don't really care what we call it. From trygvis at opencsw.org Tue Mar 1 16:01:16 2011 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Tue, 01 Mar 2011 16:01:16 +0100 Subject: [csw-maintainers] [PATCH] opencsw-policy: The copyright notice In-Reply-To: <1298985086-1852-2-git-send-email-maciej@opencsw.org> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-2-git-send-email-maciej@opencsw.org> Message-ID: <4D6D0A3C.9010500@opencsw.org> On 3/1/11 2:11 PM, Maciej Blizinski wrote: > This patch sets the copyright of policy package and policy documents to > GPL-2.0+. To be honest I find it legally insane to allow the user to choose their own license at their will. Take one license and stick to it. I'd suggest using GPL 2.0 (but 3.0 is fine with me) for all of the documentation. Feel free to explicitly state that we're choosing to use GPL v2 for Debian's parts. [snip] -- Trygve From dam at opencsw.org Tue Mar 1 17:15:10 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Mar 2011 17:15:10 +0100 Subject: [csw-maintainers] lighttpd and ipv6 In-Reply-To: References: <7DC3AB18-AB6D-477C-B5EA-4E3F852278D8@opencsw.org> Message-ID: Hi Maciej, (switched to maintainers@ as of general interest) Am 01.03.2011 um 12:34 schrieb Maciej Blizi?ski: > David, do you know if the mod_compress module does work in the non-gar > build of lighttpd? If it doesn't, then maybe we can disable the test > suite in the gar build for now and release garified lighttpd? In the > meantime, we'd continue looking at the mod_compress issue, until it's > solved. The issue was real. When sending compressed data the compression is done in a temp directory which is created on demand. If this directory is on an automounted filesystem (like /home/dam) the result of mkdir(2) is ENOSYS instead of EEXIST which confuses the recursive directory creation routine thinking that the directory is already there: /1: mkdir("/home", 0700) Err#17 EEXIST /1: mkdir("/home/dam", 0700) Err#89 ENOSYS As the compression then fails because deeper pathes are missing lighttpd just sends the uncompressed file instead making the testsuite fail. Patch #2 is not necessary as LDFLAGS usually does not include runtime linker options, these are in RUNTIME_LINKER_FLAGS and are usually passed with the environment as LD_OPTIONS bypassing buildsystem processing. To pass them via the normal build system use LD_OPTIONS = EXTRA_LINKER_FLAGS = $(RUNPATH_LINKER_FLAGS) which is also documented at http://wiki.opencsw.org/porting-faq#toc8 The package now builds fine and the testsuite passes, everything is checked in. Now whos next for the third 90% ? ;-) Best regards -- Dago From phil at bolthole.com Tue Mar 1 17:25:28 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Mar 2011 08:25:28 -0800 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <1298985086-1852-1-git-send-email-maciej@opencsw.org> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: On 3/1/11, Maciej Blizinski wrote: > > There has been lately no progress on the issue on the initial patch. The > current state of opinions about the latest version of the patch[1] is as > follows: > > Maciej Blizi??ski: For subsmission as presented > Peter Felecan: For submission as presented > Phil Brown: Against submission as presented > > The objection from Phil was that copyright is not necessary, while others > (also outside the policy team) believe it is. There was a suggestion[2] to > take > out the abstract from the patch. I dont know that I would describe my position as "against" it. Merely that I was specifically asked for feedback,and I gave my opinion that both the copyright, and the abstract, are unnecessary. Your summary is missing one thing, however, in that someone (I dont remember who) suggested an alternative license to the GPL. From skayser at opencsw.org Tue Mar 1 17:09:26 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 1 Mar 2011 17:09:26 +0100 Subject: [csw-maintainers] lighttpd and ipv6 In-Reply-To: References: <7DC3AB18-AB6D-477C-B5EA-4E3F852278D8@opencsw.org> Message-ID: <20110301160926.GC28572@sebastiankayser.de> * Dagobert Michelsen wrote: > (switched to maintainers@ as of general interest) > > Am 01.03.2011 um 12:34 schrieb Maciej Blizi??ski: > > David, do you know if the mod_compress module does work in the non-gar > > build of lighttpd? If it doesn't, then maybe we can disable the test > > suite in the gar build for now and release garified lighttpd? In the > > meantime, we'd continue looking at the mod_compress issue, until it's > > solved. > > The issue was real. When sending compressed data the compression is done > in a temp directory which is created on demand. If this directory is on > an automounted filesystem (like /home/dam) the result of mkdir(2) is > ENOSYS instead of EEXIST which confuses the recursive directory creation > routine thinking that the directory is already there: > > /1: mkdir("/home", 0700) Err#17 EEXIST > /1: mkdir("/home/dam", 0700) Err#89 ENOSYS Cool. Not an uncommon issue btw., also saw it with Dovecot a while ago: http://www.mail-archive.com/dovecot at dovecot.org/msg17523.html Sebastian From Joerg.Schilling at fokus.fraunhofer.de Tue Mar 1 18:00:39 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 01 Mar 2011 18:00:39 +0100 Subject: [csw-maintainers] lighttpd and ipv6 In-Reply-To: References: <7DC3AB18-AB6D-477C-B5EA-4E3F852278D8@opencsw.org> Message-ID: <4d6d2637.dmE65TqFn2Pa297Z%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > The issue was real. When sending compressed data the compression is done > in a temp directory which is created on demand. If this directory is on > an automounted filesystem (like /home/dam) the result of mkdir(2) is > ENOSYS instead of EEXIST which confuses the recursive directory creation > routine thinking that the directory is already there: > > /1: mkdir("/home", 0700) Err#17 EEXIST > /1: mkdir("/home/dam", 0700) Err#89 ENOSYS A POSIXly correct error code would be EROFS. Would this help? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From phil at bolthole.com Tue Mar 1 18:00:59 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Mar 2011 09:00:59 -0800 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: On 3/1/11, Maciej Blizi?ski wrote: > >> Also, why is there not a link to the writeup, in the actual ballot? > > Because ballotbin does not support adding any text directly to the > actual ballot. Wow.. that's .. surprisingly limited. But perhaps it is an artifact of which voting style you used? [....] Yes, to a point. As you mention, there is the option of adding a ["biographical"] note per question, which is not exactly what I was hoping. But perhaps in some voting issues, it would be good to use this. > As Peter F likes, to > say: consequently, I've added the link to each of the 8 answers. great >. However, once their term of >> office is ended, the same people still have the same parts of the key. >> Nothing stops them from getting together and using it after their term >> has ended. > > True. The escrow option is not about revoking access; it's about > distributing access. It is not worse not better than the other > options. The threat that escrow protects against, is a single board > member using the key without the consent of other board members. > Using the key after the term of office ends, is another threat which > needs another solution. > >> If my summary of the escrow is valid, please adjust the wording to >> make that clear (or preferably just remove the secondary question >> entirely), when the ballot is fixed and restarted. > > Since the vote is not about key revocation, I see no reason to remove > the escrow question. It is more complicated than you might think. Please see my adjusted writeup at http://wiki.opencsw.org/vote-gpgkey for why. That might convince you to move the key escrow vote, to another time, after either more discussion, or alternative technology is proposed. If we had better key escrow tech (William suggested such may exist, but costs $$$), then this wouldnt be a problem. From pfelecan at opencsw.org Tue Mar 1 18:12:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 01 Mar 2011 18:12:46 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: (Philip Brown's message of "Tue, 1 Mar 2011 08:25:28 -0800") References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: Philip Brown writes: > Your summary is missing one thing, however, in that someone (I dont > remember who) suggested an alternative license to the GPL. There were only 3 persons implied in the discussion, Maciej, your self and me. No one proposed an alternative license. -- Peter From dam at opencsw.org Tue Mar 1 18:37:21 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Mar 2011 18:37:21 +0100 Subject: [csw-maintainers] lighttpd and ipv6 In-Reply-To: <4d6d2637.dmE65TqFn2Pa297Z%Joerg.Schilling@fokus.fraunhofer.de> References: <7DC3AB18-AB6D-477C-B5EA-4E3F852278D8@opencsw.org> <4d6d2637.dmE65TqFn2Pa297Z%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Hi J?rg, Am 01.03.2011 um 18:00 schrieb Joerg Schilling: > Dagobert Michelsen wrote: >> The issue was real. When sending compressed data the compression is done >> in a temp directory which is created on demand. If this directory is on >> an automounted filesystem (like /home/dam) the result of mkdir(2) is >> ENOSYS instead of EEXIST which confuses the recursive directory creation >> routine thinking that the directory is already there: >> >> /1: mkdir("/home", 0700) Err#17 EEXIST >> /1: mkdir("/home/dam", 0700) Err#89 ENOSYS > > A POSIXly correct error code would be EROFS. Would this help? I have seen checks for EROFS in code from other programs when investigating this issue, but as ENOSYS is returned from mkdir(2) I don't see how an explicit check could be avoided with the exception of rewriting it the way the Solaris implementation did it (traversing from right to left instead of mkdir'ing from left to right): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libgen/common/mkdirp.c Best regards -- Dago From Joerg.Schilling at fokus.fraunhofer.de Tue Mar 1 18:44:25 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 01 Mar 2011 18:44:25 +0100 Subject: [csw-maintainers] lighttpd and ipv6 In-Reply-To: References: <7DC3AB18-AB6D-477C-B5EA-4E3F852278D8@opencsw.org> <4d6d2637.dmE65TqFn2Pa297Z%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4d6d3079.v+S+0kgejHoEk4R0%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > >> /1: mkdir("/home/dam", 0700) Err#89 ENOSYS > > > > A POSIXly correct error code would be EROFS. Would this help? > > I have seen checks for EROFS in code from other programs when > investigating this issue, but as ENOSYS is returned from mkdir(2) > I don't see how an explicit check could be avoided with the > exception of rewriting it the way the Solaris implementation > did it (traversing from right to left instead of mkdir'ing from > left to right): > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libgen/common/mkdirp.c The correct place to fix would be in this function: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/autofs/auto_vnops.c#663 J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From phil at bolthole.com Tue Mar 1 19:05:12 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Mar 2011 10:05:12 -0800 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: On 3/1/11, Peter FELECAN wrote: > Philip Brown writes: > >> Your summary is missing one thing, however, in that someone (I dont >> remember who) suggested an alternative license to the GPL. > > There were only 3 persons implied in the discussion, Maciej, your self > and me. No one proposed an alternative license. > it was not one of us 3, sure. but someone did. Presumably, we are still having these discussions on "the maintainers list", for exactly this purpose? So other maintainers can read what we're saying, and also freely add comments? So.. are "we 3" going to pay attention to those comments, or just ignore them? From pfelecan at opencsw.org Tue Mar 1 19:24:41 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 01 Mar 2011 19:24:41 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: (Philip Brown's message of "Tue, 1 Mar 2011 10:05:12 -0800") References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: Philip Brown writes: > On 3/1/11, Peter FELECAN wrote: >> Philip Brown writes: >> >>> Your summary is missing one thing, however, in that someone (I dont >>> remember who) suggested an alternative license to the GPL. >> >> There were only 3 persons implied in the discussion, Maciej, your self >> and me. No one proposed an alternative license. >> > > it was not one of us 3, sure. but someone did. > > Presumably, we are still having these discussions on "the maintainers > list", for exactly this purpose? So other maintainers can read what > we're saying, and also freely add comments? > > So.. are "we 3" going to pay attention to those comments, or just ignore them? Alright. I re-read the thread, please do it also. William proposed CDDL. You proposed to not have a license, neither an abstract. Sebastian and Ben agreed to have GPL. Finally, what's your point? -- Peter From phil at bolthole.com Tue Mar 1 20:08:42 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Mar 2011 11:08:42 -0800 Subject: [csw-maintainers] use my opencsw not bolthole addr Message-ID: FYI: email for my bolthole domain will most likely be in flux for the next few days. Please be sure to use my opencsw.org email, not my usual bolthole one. I think there should be no problems with that. From phil at bolthole.com Tue Mar 1 23:29:08 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Mar 2011 14:29:08 -0800 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: On 3/1/11, Peter FELECAN wrote: > Philip Brown writes: > >> it was not one of us 3, sure. but someone did. >> >> Presumably, we are still having these discussions on "the maintainers >> list", for exactly this purpose? So other maintainers can read what >> we're saying, and also freely add comments? >> >> So.. are "we 3" going to pay attention to those comments, or just ignore >> them? > > Alright. I re-read the thread, please do it also. William proposed > CDDL. You proposed to not have a license, neither an abstract. Sebastian > and Ben agreed to have GPL. Finally, what's your point? > So there we go. I validly reported "someone suggested a difference license". Now how about you answer my question of, are "we 3" going to pay attention to those comments[both in this specific case,and in the general case], or just ignore them? Your prior message seemed to imply that since we are the people who formally volunteered for the policy board, we can ignore input from others. (In which case I would ask, why are we discussing policy issues on the maintainers list then?) My opinion is that we should pay attention to them, both in the specific, and the general case. What's your, and Maciej's opinion on this? (For the "specific instance" . someone has raised the suggestion of an alternative license. there have been no discussions on relative merits of GPL vs CDDL. To just pick a license for our documentation, based on only the handful of people who have spoken up so far, that is going to apply for all our docs, for a Very Long Time, without any analysis of which, if any, is better... strikes me as.. rash. PS; to address someone's comment of "what about if someone wants to 'use our documentation work' for future purposes and other projects"... there is also the possibility of simply making our documentation fully "public domain". So, possibilities that have been now mentioned are: a) none b) GPL c) CDDL d) public domain Anyone want to state *why* one is particularly better than the other choices, in their opinion? It would probably help to also state up front, what the perceived benefit of having a copyright notice is. The only one I have seen so far is, "[to clearly allow people to use our documentation for other projectsj]". If that is the only goal, then it seems we want to be as permissive as possible. The option that fits "most permissive" from the above list, is "public domain". From maciej at opencsw.org Wed Mar 2 01:31:07 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 2 Mar 2011 00:31:07 +0000 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/1 Philip Brown : > So there we go. I validly reported "someone suggested a difference license". > Now how about you answer my question of, > ?are "we 3" going to pay attention to those comments[both in this > specific case,and in the general case], or just ignore them? > > Your prior message seemed to imply that since we are the people who > formally volunteered for the policy board, we can ignore input from > others. > (In which case I would ask, why are we discussing policy issues on the > maintainers list then?) > > > My opinion is that we should pay attention to them, both in the > specific, and the general case. What's your, and Maciej's opinion on > this? We are going to pay attention to comments from everyone. > (For the "specific instance" . someone has raised the suggestion of an > alternative license. there have been no discussions on relative merits > of GPL vs CDDL. > To just pick a license for our documentation, based on only the > handful of people who have spoken up so far, that is going to apply > for all our docs, for a Very Long Time, without any analysis of which, > if any, is better... strikes me as.. rash. What's your timeline for the licensing choice? Keep in mind that this issue blocks any further changes to our policy documents. The license will not apply to all our docs. It will apply to files which make up our policy documentation, living in the code repository. It will be only a fraction of our documentation. The handful of people who have spoken are the ones who care. Other ones probably don't care about the license, as long as the policy is there for them to read. The idea behind policy team is to avoid exactly the problem you're creating above: we want to stop worrying about what any maintainer might think but doesn't say. We want to go forward in a small team of people who care, while allowing others to speak up when they want to. If you want to go against the idea of policy-team in this case and ask for everyone's opinion, we can do it in a systematic way by calling a vote on the issue. > PS; to address someone's comment of "what about if someone wants to > 'use our documentation work' for future purposes and other > projects"... there is also the possibility of simply making our > documentation fully "public domain". > > So, possibilities that have been now mentioned are: > > a) none > b) GPL > c) CDDL > d) public domain > > Anyone want to state *why* one is particularly better than the other > choices, in their opinion? > > It would probably help to also state up front, what the perceived > benefit of having a copyright notice is. The only one I have seen so > far is, "[to clearly allow people to use our documentation for other > projectsj]". > > If that is the only goal, then it seems we want to be as permissive as > possible. The option that fits "most permissive" from the above list, > is "public domain". Public domain is not without problems. It is a US-centric concept, while our project needs to be considered in a larger context. For example, there are jurisdictions in which the notion of public domain is not acknowledged[1], with unfortunate consequences. The choice of "none" license is riddled with many of the same problems as public domain. If I understand correctly, CDDL was preferred by some for build description license. I think that the reasoning behind it was that a commercial third party would be allowed to take our build descriptions, modify them and distribute them without contributing back to our project. Fair enough. However, in the case of policy documents, CDDL does not offer any benefit of this kind to third parties. GPL is a well known and well understood license, certainly more known and better understood than CDDL -- that's why it is my preferred choice. I believe that many others share my opinion. Maciej [1] http://warp.povusers.org/grrr/costly_open_source_licenses.html From maciej at opencsw.org Wed Mar 2 03:18:45 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 2 Mar 2011 02:18:45 +0000 Subject: [csw-maintainers] lighttpd and ipv6 In-Reply-To: References: <7DC3AB18-AB6D-477C-B5EA-4E3F852278D8@opencsw.org> Message-ID: Hi Dago, Thanks for the debugging work! Go team! 2011/3/1 Dagobert Michelsen : > The package now builds fine and the testsuite passes, everything is > checked in. Now whos next for the third 90% ? ;-) I completed some more work: - I set the user and group to "lighttpd", because running as "nobody" generally doesn't seem like a good idea - Changed sysconfdir and localstatedir to the ones that work with Solaris zones - Added a default index file - Added SMF integration I tested the package on my test box. It's able to run, I also got mod_userdir to work. Packages are available from my experimental repository: http://buildfarm.opencsw.org/experimental.html#maciej The difference between the old and the new package: --- /tmp/pkg_DO47AQ/lighttpd-1.4.28,REV=2010.10.30-SunOS5.8-sparc-CSW.pkg.gz +++ /tmp/pkg_Ps2Qgm/lighttpd-1.4.28,REV=2011.03.02-SunOS5.10-i386-CSW.pkg.gz @@ -1,89 +1,51 @@ -/etc/init.d/cswlighttpd -/etc/rc0.d/K15cswlighttpd --> /etc/init.d/cswlighttpd -/etc/rc1.d/K15cswlighttpd --> /etc/init.d/cswlighttpd -/etc/rc2.d/K15cswlighttpd --> /etc/init.d/cswlighttpd -/etc/rc3.d/S40cswlighttpd --> /etc/init.d/cswlighttpd -/etc/rcS.d/K15cswlighttpd --> /etc/init.d/cswlighttpd -/opt/csw/etc/lighttpd.conf.CSW -/opt/csw/lib -/opt/csw/lib/mod_access.la -/opt/csw/lib/mod_access.so (...) -/opt/csw/lib/svc -/opt/csw/lib/svc/method -/opt/csw/lib/svc/method/cswlighttpd -/opt/csw/sbin +/etc/opt/csw/init.d +/etc/opt/csw/init.d/cswlighttpd +/etc/opt/csw/lighttpd.conf.CSW +/etc/opt/csw/pkg +/etc/opt/csw/pkg/lighttpd +/etc/opt/csw/pkg/lighttpd/cswusergroup +/opt/csw/lib/lighttpd +/opt/csw/lib/lighttpd/liblightcomp.so +/opt/csw/lib/lighttpd/mod_access.so (...) -/opt/csw/share +/opt/csw/share/doc/lighttpd +/opt/csw/share/doc/lighttpd/license -/opt/csw/share/man -/opt/csw/var/lighttpd -/opt/csw/var/svc -/opt/csw/var/svc/manifest -/opt/csw/var/svc/manifest/network -/opt/csw/var/svc/manifest/network/lighttpd.xml +/var/opt/csw/log +/var/opt/csw/log/lighttpd +/var/opt/csw/run David, could you check out the build description from the repository and review it? Maciej From phil at bolthole.com Wed Mar 2 07:08:11 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Mar 2011 22:08:11 -0800 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/1 Maciej Blizi?ski > 2011/3/1 Philip Brown : > > > > My opinion is that we should pay attention to them, both in the > > specific, and the general case. What's your, and Maciej's opinion on > > this? > > We are going to pay attention to comments from everyone. > glad to hear it. > > > (For the "specific instance" . someone has raised the suggestion of an > > alternative license. there have been no discussions on relative merits > > of GPL vs CDDL. > > To just pick a license for our documentation, based on only the > > handful of people who have spoken up so far, that is going to apply > > for all our docs, for a Very Long Time, without any analysis of which, > > if any, is better... strikes me as.. rash. > > What's your timeline for the licensing choice? Keep in mind that this > issue blocks any further changes to our policy documents. > I dont have a "timeframe" in mind; rather, more of a completeness goal. If someone tomorrow comes up with a reasonably comprehensive comparison between the choices, and no-one has anything further to add; it seems reasonable we could probably proceed with a vote very shortly thereafter. What you wrote below helps a lot in that reguard, Maciej. However, it's missing a bit of comparative info, I think. Perhaps we could convince William to talk more about why he recommends CDDL? > If you want to go against the idea of policy-team in this case and ask > for everyone's opinion, we can do it in a systematic way by calling a > vote on the issue. > I dont see this as going "against" the idea of policy team. I see policy-team's purpose as two-fold: 1. straightening out minor points of pickiness in an optimal and timely fashion 2. condensing and summarizing "Really Important Stuff" in a thorough fashion, so that we can have a clean vote on it > > > > It would probably help to also state up front, what the perceived > > benefit of having a copyright notice is. The only one I have seen so > > far is, "[to clearly allow people to use our documentation for other > > projectsj]". > > > > If that is the only goal, then it seems we want to be as permissive as > > possible. The option that fits "most permissive" from the above list, > > is "public domain". > > Public domain is not without problems. It is a US-centric concept, > while our project needs to be considered in a larger context. For > example, there are jurisdictions in which the notion of public domain > is not acknowledged[1], with unfortunate consequences. > Huh.That's silly. Oh well, then substitute "BSD License" for "public domain", then > > The choice of "none" license is riddled with many of the same problems > as public domain. > Fair enough. Although you still did not explicitly state what you believe the goals of the license should be, as concerns our documentation. I will proceed with the assumption that you believe the goal is to have the most amount of people be able to reuse our docs, as they see fit. > > If I understand correctly, CDDL was preferred by some for build > description license. I think that the reasoning behind it was that a > commercial third party would be allowed to take our build > descriptions, modify them and distribute them without contributing > back to our project. Fair enough. However, in the case of policy > documents, CDDL does not offer any benefit of this kind to third > parties. > Why not? The only reason I can imagine you saying that, would be "because no-one else would want to use OUR policy documents". But that can't be it, because if so, then having a license for something "no-one else would want to use", is a waste of time. > > GPL is a well known and well understood license, certainly more known > and better understood than CDDL -- that's why it is my preferred > choice. Personally, I dont like picking a choice merely because [it's popular, and I dont understand the alternatives as well]. I prefer to increase my understanding of the alternatives before making the choice. Recalling conversations from "The Original OpenCSW meeting", there was some interest in having our core framework scripts, etc. also be CDDL. You seemed to say that, in your opinion, CDDL would not make so much sense for documentation, but it would make more sense to you, to have our framework code be CDDL. If we did do that, it would then be nicest to have everything use the same license, would it not? Contrariwise, if having different licenses for docs vs frameworks does not matter to you; BSD style license is much simpler, and shorter than GPL, so would seem to be even better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Wed Mar 2 10:07:19 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 02 Mar 2011 10:07:19 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: (Philip Brown's message of "Tue, 1 Mar 2011 14:29:08 -0800") References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: Philip Brown writes: > On 3/1/11, Peter FELECAN wrote: >> Philip Brown writes: >> >>> it was not one of us 3, sure. but someone did. >>> >>> Presumably, we are still having these discussions on "the maintainers >>> list", for exactly this purpose? So other maintainers can read what >>> we're saying, and also freely add comments? >>> >>> So.. are "we 3" going to pay attention to those comments, or just ignore >>> them? >> >> Alright. I re-read the thread, please do it also. William proposed >> CDDL. You proposed to not have a license, neither an abstract. Sebastian >> and Ben agreed to have GPL. Finally, what's your point? >> > > So there we go. I validly reported "someone suggested a difference license". > Now how about you answer my question of, > are "we 3" going to pay attention to those comments[both in this > specific case,and in the general case], or just ignore them? > > Your prior message seemed to imply that since we are the people who > formally volunteered for the policy board, we can ignore input from > others. > (In which case I would ask, why are we discussing policy issues on the > maintainers list then?) Here, again, you interpret what I'm writing to suit your goals. My previous messages were just a summary of how many people has expressed their opinion. > My opinion is that we should pay attention to them, both in the > specific, and the general case. What's your, and Maciej's opinion on > this? Who said something else? It's again your insinuation that we are not caring for other people opinion when in fact, by you rehashing the same points, you try to impose your point on everybody else. > (For the "specific instance" . someone has raised the suggestion of an > alternative license. there have been no discussions on relative merits > of GPL vs CDDL. > To just pick a license for our documentation, based on only the > handful of people who have spoken up so far, that is going to apply > for all our docs, for a Very Long Time, without any analysis of which, > if any, is better... strikes me as.. rash. > > > PS; to address someone's comment of "what about if someone wants to > 'use our documentation work' for future purposes and other > projects"... there is also the possibility of simply making our > documentation fully "public domain". > > So, possibilities that have been now mentioned are: > > a) none > b) GPL > c) CDDL > d) public domain b was supported by 5 people c was suggested by 1 person a & d are supported/proposed by your self (yes, you added also BSD) > Anyone want to state *why* one is particularly better than the other > choices, in their opinion? > > It would probably help to also state up front, what the perceived > benefit of having a copyright notice is. The only one I have seen so > far is, "[to clearly allow people to use our documentation for other > projectsj]". > > If that is the only goal, then it seems we want to be as permissive as > possible. The option that fits "most permissive" from the above list, > is "public domain". All this discussion is meaningless and will go until the end of ages having the same level of ridiculousness as that on the gender of angels. Frankly, I think that nothing is coming out of this. The only thing which suits you is something that you've written completely. Nothing else is good. That is an egotistical stance. Consequently, having this discussion with you is a fight against windmills, and I'm abandoning it. KO -- Peter From skayser at opencsw.org Wed Mar 2 10:02:38 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 2 Mar 2011 10:02:38 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: <20110302090238.GE28572@sebastiankayser.de> * Philip Brown wrote: > 2011/3/1 Maciej Blizi?*ski <[1]maciej at opencsw.org> > GPL is a well known and well understood license, certainly more known > and better understood than CDDL -- that's why it is my preferred > choice. ? > > Personally, I dont like picking a choice merely because [it's popular, and > I dont understand the alternatives as well]. I prefer to increase my > understanding of the alternatives before making the choice. GPL is what the debian policy is licensed with. If we choose GPL, we can cherry pick existing paragraphs from the extensive and thorough debian policy (without having to re-invent the wheel) and focus on parts that are specific to us. WRT to GPL vs CDDL http://lmgtfy.com/?q=cddl+vs+gpl Sebastian From james at opencsw.org Wed Mar 2 10:49:53 2011 From: james at opencsw.org (James Lee) Date: Wed, 02 Mar 2011 09:49:53 GMT Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <1298985086-1852-1-git-send-email-maciej@opencsw.org> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> Message-ID: <20110302.9495300.2618472041@gyor.oxdrove.co.uk> On 01/03/11, 13:11:25, Maciej Blizinski wrote regarding [csw-maintainers] [POLICY] opencsw-policy: The copyright notice: > There has been lately no progress on the issue on the initial patch. The > current state of opinions about the latest version of the patch[1] is as > follows: > Maciej Blizi? ??ski: For subsmission as presented > Peter Felecan: For submission as presented > Phil Brown: Against submission as presented I'm against it. That's based on the fact that GPL is largely irrelevant to the task. Would a supporter please explain which parts of GPL help in defining a policy document? James. From skayser at opencsw.org Wed Mar 2 10:39:29 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 2 Mar 2011 10:39:29 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <20110302.9495300.2618472041@gyor.oxdrove.co.uk> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> <20110302.9495300.2618472041@gyor.oxdrove.co.uk> Message-ID: <20110302093929.GF28572@sebastiankayser.de> * James Lee wrote: > On 01/03/11, 13:11:25, Maciej Blizinski wrote > regarding [csw-maintainers] [POLICY] opencsw-policy: The copyright > notice: > > > There has been lately no progress on the issue on the initial patch. The > > current state of opinions about the latest version of the patch[1] is as > > follows: > > > Maciej Blizi? ??ski: For subsmission as presented > > Peter Felecan: For submission as presented > > Phil Brown: Against submission as presented > > I'm against it. That's based on the fact that GPL is largely irrelevant > to the task. > > Would a supporter please explain which parts of GPL help in defining a > policy document? http://lists.opencsw.org/pipermail/maintainers/2011-March/014269.html Sebastian From dam at opencsw.org Wed Mar 2 10:57:52 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Mar 2011 10:57:52 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <20110302.9495300.2618472041@gyor.oxdrove.co.uk> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> <20110302.9495300.2618472041@gyor.oxdrove.co.uk> Message-ID: <3A483EBC-246B-4C7B-A19D-BEDD39C3E49F@opencsw.org> Hi James, first let me say that I value your input both personally and as maintainer and I especially want to point out that you please not take this personally. Am 02.03.2011 um 10:49 schrieb James Lee: > On 01/03/11, 13:11:25, Maciej Blizinski wrote > regarding [csw-maintainers] [POLICY] opencsw-policy: The copyright > notice: > >> There has been lately no progress on the issue on the initial patch. The >> current state of opinions about the latest version of the patch[1] is as >> follows: > >> Maciej Blizi????ski: For subsmission as presented >> Peter Felecan: For submission as presented >> Phil Brown: Against submission as presented > > I'm against it. That's based on the fact that GPL is largely irrelevant > to the task. You are neither a member of the foundation (which you could if you would apply) and also not a member of the policy team (which you could also after becoming a member if you would apply). If you want to engage to the discussion feel free to change that. Best regards -- Dago From dam at opencsw.org Wed Mar 2 11:26:50 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Mar 2011 11:26:50 +0100 Subject: [csw-maintainers] SSH keys and security on the buildfarm Message-ID: Hi folks, I have a small snippet here that makes use of passphrases for the ssh key pretty easy: 1. Set passphrase on the key ssh-keygen -p -f .ssh/id_dsa 2. Add this to your .zshrc (or the respective file for your favorite shell): # executed for interactive shells if [ "x$HOSTNAME" = "xlogin" ]; then if [ -f ~/.ssh-agent ]; then source ~/.ssh-agent fi if [ -z "$SSH_AUTH_SOCK" -o ! -w "$SSH_AUTH_SOCK" ]; then if read -q '?Start ssh-agent? (y/n) '; then ssh-agent -s >~/.ssh-agent && \ source ~/.ssh-agent && \ ssh-add fi fi fi 3. Make sure the ssh agent information is forwarded to trusted machines (echo "Host current*"; echo "\tForwardAgent yes") >> ~/.ssh/config This is also documented at the bottom of http://wiki.opencsw.org/buildfarm Best regards -- Dago From maciej at opencsw.org Wed Mar 2 11:39:19 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 2 Mar 2011 10:39:19 +0000 Subject: [csw-maintainers] SSH keys and security on the buildfarm In-Reply-To: References: Message-ID: 2011/3/2 Dagobert Michelsen : > This is also documented at the bottom of > ?http://wiki.opencsw.org/buildfarm Cool. I also did a similar thing a while back, using keychain: http://lists.opencsw.org/pipermail/maintainers/2009-December/010732.html keychain is essentially a wrapper around ssh-agent and gpg-agent. Setup with keychain is slightly easier, and you also get gpg-agent support. Maciej From james at opencsw.org Wed Mar 2 12:17:07 2011 From: james at opencsw.org (James Lee) Date: Wed, 02 Mar 2011 11:17:07 GMT Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <20110302093929.GF28572@sebastiankayser.de> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> <20110302.9495300.2618472041@gyor.oxdrove.co.uk> <20110302093929.GF28572@sebastiankayser.de> Message-ID: <20110302.11170700.2752649352@gyor.oxdrove.co.uk> On 02/03/11, 09:39:29, Sebastian Kayser wrote regarding Re: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice: > > Would a supporter please explain which parts of GPL help in defining a > > policy document? > http://lists.opencsw.org/pipermail/maintainers/2011-March/014269.html http://lists.opencsw.org/pipermail/maintainers/2011-February/014062.html James. From james at opencsw.org Wed Mar 2 12:20:01 2011 From: james at opencsw.org (James Lee) Date: Wed, 02 Mar 2011 11:20:01 GMT Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <3A483EBC-246B-4C7B-A19D-BEDD39C3E49F@opencsw.org> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> <20110302.9495300.2618472041@gyor.oxdrove.co.uk> <3A483EBC-246B-4C7B-A19D-BEDD39C3E49F@opencsw.org> Message-ID: <20110302.11200100.554586472@gyor.oxdrove.co.uk> On 02/03/11, 09:57:52, Dagobert Michelsen wrote regarding Re: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice: > first let me say that I value your input both personally and as > maintainer ... > You are neither a member of the foundation (which you could if you would > apply) and also not a member of the policy team (which you could also > after becoming a member if you would apply). If you want to engage to the > discussion feel free to change that. You do not value my input either personal or as maintainer because you imply only members may engage in discussion. If I were a member I'd resign. James. From skayser at opencsw.org Wed Mar 2 15:27:03 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 2 Mar 2011 15:27:03 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <20110302.11170700.2752649352@gyor.oxdrove.co.uk> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> <20110302.9495300.2618472041@gyor.oxdrove.co.uk> <20110302093929.GF28572@sebastiankayser.de> <20110302.11170700.2752649352@gyor.oxdrove.co.uk> Message-ID: <20110302142703.GG28572@sebastiankayser.de> * James Lee wrote: > On 02/03/11, 09:39:29, Sebastian Kayser wrote > regarding Re: [csw-maintainers] [POLICY] opencsw-policy: The copyright > notice: > > > > Would a supporter please explain which parts of GPL help in defining a > > > policy document? > > > http://lists.opencsw.org/pipermail/maintainers/2011-March/014269.html > > http://lists.opencsw.org/pipermail/maintainers/2011-February/014062.html Citing from above: "This is a false choice. Most of the policies we need, we already have written up." Would you honestly second that our policy is near complete and that we could not possibly make use of policy bits which have been distilled over time within a project that is noticably larger than ours? Even, if you do think so. Would you object to use GPL if someone else (i.e. Maciej) was working on the policy and found it helpful to integrate some Debian policy bits? If so, why? Where's the harm? Sebastian From phil at bolthole.com Wed Mar 2 18:29:32 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Mar 2011 09:29:32 -0800 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: On 3/1/11, Philip Brown wrote: > On 3/1/11, Maciej Blizi?ski wrote: >> >> Since the vote is not about key revocation, I see no reason to remove >> the escrow question. > > It is more complicated than you might think. Please see my adjusted writeup > at > http://wiki.opencsw.org/vote-gpgkey > for why. That might convince you to move the key escrow vote, to > another time, after either more discussion, or alternative technology > is proposed. > If we had better key escrow tech (William suggested such may exist, > but costs $$$), then this wouldnt be a problem. > Errr.. you kicked off a new ballot, without any kind of response to my email above. Did you even read the update? Since you Once Again decided to kick off a vote, without putting the actual ballot up publicly for review beforehand, it is not clear whether you did so. From james at opencsw.org Wed Mar 2 18:48:54 2011 From: james at opencsw.org (James Lee) Date: Wed, 02 Mar 2011 17:48:54 GMT Subject: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice In-Reply-To: <20110302142703.GG28572@sebastiankayser.de> References: <1296994980-22573-1-git-send-email-maciej@opencsw.org> <1298985086-1852-1-git-send-email-maciej@opencsw.org> <20110302.9495300.2618472041@gyor.oxdrove.co.uk> <20110302093929.GF28572@sebastiankayser.de> <20110302.11170700.2752649352@gyor.oxdrove.co.uk> <20110302142703.GG28572@sebastiankayser.de> Message-ID: <20110302.17485400.1445576862@gyor.oxdrove.co.uk> On 02/03/11, 14:27:03, Sebastian Kayser wrote regarding Re: [csw-maintainers] [POLICY] opencsw-policy: The copyright notice: > > > > Would a supporter please explain which parts of GPL help in defining a > > > > policy document? > > > > > http://lists.opencsw.org/pipermail/maintainers/2011-March/014269.html > > > > http://lists.opencsw.org/pipermail/maintainers/2011-February/014062.html > Citing from above: > "This is a false choice. Most of the policies we need, we already have > written up." > Would you honestly second that our policy is near complete and that we > could not possibly make use of policy bits which have been distilled > over time within a project that is noticably larger than ours? I see it as possible but not necessary. Citing from above: "You make it sound like we are facing a choice of either writing hundreds of pages ourselves, or copying wholesale from debian" Plus the idea we copy passages without carefully digesting the meaning is worrying, so I don't see it as difficult to write our own policies simply by doing the same amount of thought. > Even, if you do think so. Would you object to use GPL if someone else > (i.e. Maciej) was working on the policy and found it helpful to > integrate some Debian policy bits? If so, why? Where's the harm? Yes. The harm is that anyone in the future can't use material from a GPL incompatible source but I recommend creating for the purpose and not copying others then you are free as in free to make your own choices. GPL is not free in that it imposes one author's restriction (the restriction to not restrict) on all others it touches. This doesn't address the irrelevance point. The documents are written by OpenCSW for OpenCSW. GPL does not protect the documents, far from it, it actually grants people rights to create unauthorised copies - unauthorised in that they are not authorised OpenCSW documents, the ability to create variants is authorised by GPL. GPL constrains (2+)th parties in the way that derived works and additions remain source accessible per the wishes of the 1st party but wait, it's text not complied source anyway and who are these 2+ parties? James. From dam at opencsw.org Thu Mar 3 10:29:22 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Mar 2011 10:29:22 +0100 Subject: [csw-maintainers] Going ahead with package splits References: <0F5DAF73-1660-4FD4-B984-3503FE68E164@baltic-online.de> Message-ID: <219C9F0E-851F-474A-8C77-2D0A1018CDFE@opencsw.org> Hi, to go ahead with massive rebuild it would be good to start at the bottom, which would be gettext iconv Sebastian, Ben: As this has almost been done it would be really cool if you could release the package at least to "unstable" if not to "current". Best regards -- Dago From bwalton at opencsw.org Thu Mar 3 15:27:21 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Mar 2011 09:27:21 -0500 Subject: [csw-maintainers] Going ahead with package splits Message-ID: <1299162414-sup-3333@pinkfloyd.chass.utoronto.ca> Hi Dago, > Sebastian, Ben: As this has almost been done it would be really cool > if you could release the package at least to "unstable" if not to > "current". I've been running the updated ggettext on a few boxes here without issue, so I think it's ready to go. I've had no other feedback. I'll push them out later today. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Mar 3 15:46:41 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Mar 2011 06:46:41 -0800 Subject: [csw-maintainers] Going ahead with package splits In-Reply-To: <219C9F0E-851F-474A-8C77-2D0A1018CDFE@opencsw.org> References: <0F5DAF73-1660-4FD4-B984-3503FE68E164@baltic-online.de> <219C9F0E-851F-474A-8C77-2D0A1018CDFE@opencsw.org> Message-ID: On Thu, Mar 3, 2011 at 1:29 AM, Dagobert Michelsen wrote: > Hi, > > to go ahead with massive rebuild it would be good to start at > the bottom, which would be > gettext > iconv > before doing any "massive rebuild/split" work, shouldnt we have the dev/devel vote? -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at wbonnet.net Thu Mar 3 22:24:44 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 03 Mar 2011 22:24:44 +0100 Subject: [csw-maintainers] redundant, and seemingly redundant, packages listed In-Reply-To: References: Message-ID: <4D70071C.5020809@wbonnet.net> Hi >> CSWfirefox-fr vs CSWffox-l10n-fr > one is for version 3, one is for version 2. so, not redundant. I'm sorry but... No it is. CSWffox-l10n-fr declares CSWfirefox-fr as Incompatible. BTW, could you please push the l10n packages to CSW database ? cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From gadavis at opencsw.org Fri Mar 4 01:23:05 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Thu, 3 Mar 2011 16:23:05 -0800 Subject: [csw-maintainers] Oracle Solaris Studio Patch availability Message-ID: <2D26459F-F62F-4F87-8144-C27CEC103344@opencsw.org> Hi all, I'm installing the "Oracle Solaris Studio 12" (formerly Sun Studio 12) on one of my freshly installed systems, and much to my chagrin I've discovered that I can't patch the thing. We've got gold support on our systems via our old Sun Spectrum account, but this apparently doesn't include patches for the compilers any more, according to: http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index-jsp-136213.html What are the maintainers of the buildfarm planning to do about patching the compiler suite now that it's not included with the Solaris support contract? Oracle: nickle-and-diming you to death. Saddening output of my patching attempt is below: $ sudo pca --pattern="Sun Studio" -d Using /var/tmp/patchdiag.xref from Mar/03/11 Host: strombolian (SunOS 5.10/Generic_141444-09/sparc/sun4v) List: missing (11/6338) Patch IR CR RSB Age Synopsis ------ -- - -- --- --- ------------------------------------------------------- 124861 02 < 20 --- 170 Sun Studio 12: Compiler Common patch for Sun C C++ F77 F95 Looking for 124861-20 (1/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 124863 01 < 26 --- 127 Sun Studio 12: Patch for Sun C++ Compiler Looking for 124863-26 (2/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 126495 01 < 04 --- 571 Sun Studio 12: Patch for debuginfo handling Looking for 126495-04 (3/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 124867 01 < 16 --- 198 Sun Studio 12: Patch for C 5.9 compiler Looking for 124867-16 (4/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 124870 01 < 03 --- 963 Sun Studio 12: Patch for Sun Performance Library Looking for 124870-03 (5/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 124872 01 < 07 --- 701 Sun Studio 12: Patch for dbx 7.6 Debugger Looking for 124872-07 (6/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 126995 01 < 04 --- 905 Sun Studio 12: Patch for Performance Analyzer Tools Looking for 126995-04 (7/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 127001 01 < 04 --- 641 Sun Studio 12: Patch for Fortran 95 8.3 Dynamic Libraries Looking for 127001-04 (8/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 127143 01 < 03 --- 999 Sun Studio 12: Patch for Fortran 95 8.3 Support Library Looking for 127143-03 (9/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 127000 01 < 13 --- 386 Sun Studio 12: Patch for Fortran 95 8.3 Compiler Looking for 127000-13 (10/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ 128225 -- < 01 --- 668 Sun Studio 12: Patch for localization of Sun C C++ F77 F95 Looking for 128225-01 (11/11) Trying Oracle Trying https://getupdates.oracle.com/ (1/1) Failed (Error 403: You are not entitled to retrieve this content.) Failed (patch not found) ------------------------------------------------------------------------------ Download Summary: 11 total, 0 successful, 0 skipped, 11 failed $ sudo pca --supplevel Determining MOS Support Levels OS: Solaris patches and updates PUB: Oracle Open Office/StarOffice and patch utilities FMW: Firmware, drivers, bios, system controller software, ALOM/ILOM, diagnostics $ From maciej at opencsw.org Fri Mar 4 11:03:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 4 Mar 2011 10:03:24 +0000 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: 2011/3/2 Philip Brown : > On 3/1/11, Philip Brown wrote: >> On 3/1/11, Maciej Blizi?ski wrote: >>> >>> Since the vote is not about key revocation, I see no reason to remove >>> the escrow question. >> >> It is more complicated than you might think. Please see my adjusted writeup >> at >> http://wiki.opencsw.org/vote-gpgkey >> for why. That might convince you to move the key escrow vote, to >> another time, after either more discussion, or alternative technology >> is proposed. >> If we had better key escrow tech (William suggested such may exist, >> but costs $$$), then this wouldnt be a problem. >> > > > Errr.. you kicked off a new ballot, without any kind of response to my > email above. > Did you even read the update? I did read it. The key escrow scenarios in the writeup make certain assumptions, which may or may not be true. I am confident that escrow can be done right. > Since you Once Again decided to kick off a vote, without putting the > actual ballot up publicly for review beforehand, it is not clear > whether you did so. In what form did you expect the ballot for review? I've given a description: 4x two-element yes/no radio button. I've seen no objections to this ballot design. Maciej From maciej at opencsw.org Fri Mar 4 11:37:10 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 4 Mar 2011 10:37:10 +0000 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: Hello fellow maintainers, The results of the dev/devel vote are in: CSW*-dev and *_dev -- 11 votes CSW*-devel and *_devel -- 5 votes Everyone who participated in the vote can check ballotbin personally to verify the numbers. The vote establishes CSW*-dev and *_dev as the development package convention for OpenCSW, effective immediately (2011-03-04). I'd like to thank everyone who participated in the vote! Maciej From maciej at opencsw.org Fri Mar 4 15:28:18 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 4 Mar 2011 14:28:18 +0000 Subject: [csw-maintainers] The "[^]" URL decorators on mantis Message-ID: Hello bugtracker admins, Mantis currently injects a "[^]" string after each URL. I've just confused a user on mantis[1], because I couldn't paste in any shell command that included a URL, without the command being corrupted by mantis. Can mantis be configured not to inject "[^]" after every URL? Maciej [1] https://www.opencsw.org/mantis/view.php?id=4703 From phil at bolthole.com Fri Mar 4 17:09:37 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Mar 2011 08:09:37 -0800 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: 2011/3/4 Maciej Blizi?ski > > > Since you Once Again decided to kick off a vote, without putting the > > actual ballot up publicly for review beforehand, it is not clear > > whether you did so. > > > In what form did you expect the ballot for review? ?I've given a > description: 4x two-element yes/no radio button. ?I've seen no > objections to this ballot design. > How about:? cut and paste (or equivalent) the exact output the voter will see, and put it on the wiki somewhere. From phil at bolthole.com Fri Mar 4 17:16:44 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Mar 2011 08:16:44 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: 2011/3/4 Maciej Blizi?ski : > Hello fellow maintainers, > > The results of the dev/devel vote are in: > > CSW*-dev and *_dev -- 11 votes > CSW*-devel and *_devel -- 5 votes > > Everyone who participated in the vote can check ballotbin personally > to verify the numbers. For the record, I would like to state that I never saw a vote invite. This might have something to do with the fact that the vote invite last time, showed up as from "Maciej at mail.guatec.com" It was not even from an @opencsw.org address. And there was no announce that I saw on the maintainers list, "hey I sent a vote invite out". That being said, I acknowlege that according to the above numbers, we had good participation, and the majority favors -dev. So I'll be passing -dev packages through now. Are there any other non-announced votes currently going on? From dam at opencsw.org Fri Mar 4 20:59:36 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Mar 2011 20:59:36 +0100 Subject: [csw-maintainers] Going ahead with package splits In-Reply-To: References: <0F5DAF73-1660-4FD4-B984-3503FE68E164@baltic-online.de> <219C9F0E-851F-474A-8C77-2D0A1018CDFE@opencsw.org> Message-ID: Hi Phil, Am 03.03.2011 um 15:46 schrieb Philip Brown: > On Thu, Mar 3, 2011 at 1:29 AM, Dagobert Michelsen wrote: >> to go ahead with massive rebuild it would be good to start at >> the bottom, which would be >> gettext >> iconv >> > > before doing any "massive rebuild/split" work, shouldnt we have the dev/devel vote? Sure, but as I anticipated it took a few days to respond and then the vote was over :-) Ben: Good to hear, please push as you see fit. Sebastian: I need feedback on libiconv for a sane package name split as tons of stuff depends on it and I want to get the dependencies right and not touch everything again. Will you have time in the next few days? If not please let me know also so I can prepare the package split and you can rebuild and release if you want. Best regards -- Dago From bwalton at opencsw.org Sat Mar 5 02:02:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 04 Mar 2011 20:02:01 -0500 Subject: [csw-maintainers] Going ahead with package splits In-Reply-To: References: <0F5DAF73-1660-4FD4-B984-3503FE68E164@baltic-online.de> <219C9F0E-851F-474A-8C77-2D0A1018CDFE@opencsw.org> Message-ID: <1299286910-sup-9016@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 04 14:59:36 -0500 2011: > Ben: Good to hear, please push as you see fit. Pushed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 5 09:12:53 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 5 Mar 2011 08:12:53 +0000 Subject: [csw-maintainers] [GAR] Simple checks for package installation image in PKGROOT Message-ID: Here's an idea I would like to share. It happened quite a few times that I saw recurring problems with certain packages, mostly MySQL and PostgreSQL when working on them. It was usually as simple as a missing file, or a surplus file, or a file in a wrong directory. checkpkg couldn't help, because it only implements global checks - the ones that apply to all packages in the catalog. In these cases, I wanted checks specific to the software I was building. I first wanted to have support for such checks in GAR, but I've recently came to a conclusion that it's best to handle such checking outside of it. Since the nature of such tests is hard to predict, writing (simple!) ad-hoc shell scripts looks like the best approach. I left one example[1] on GAR issue tracker. The basic idea is simple: in the post-merge step, when the installation image is ready, we're calling a shell script. The shell script is run with "set -e", meaning that any failed command in the shell script will abort it with an error exit status code. In GNU make, this results in the build being stopped. I've also used "set -x" in my example, so in case of failure, it is immediately visible, what command has failed. In the GAR build description: post-merge: $(FILEDIR)/check_pkgroot.sh "$(PKGROOT)" The checking script itself: #!/opt/csw/bin/bash declare -r PKGROOT="$1" if [[ -z "${PKGROOT}" ]] then echo "Please give an argument." exit 1 fi set -u set -e set -x # Look for unexpanded variables ! grep @sysconfdir@ ${PKGROOT}/etc/opt/csw/init.d/cswpostgres_9_0 # This symlink is not supposed to be there ! test -h ${PKGROOT}/opt/csw/lib/postgresql/9.0/lib/libecpg.so Maciej [1] http://sourceforge.net/apps/trac/gar/ticket/18#comment:3 From maciej at opencsw.org Sat Mar 5 11:39:29 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 5 Mar 2011 10:39:29 +0000 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: 2011/3/4 Philip Brown : > 2011/3/4 Maciej Blizi?ski : >> Hello fellow maintainers, >> >> The results of the dev/devel vote are in: >> >> CSW*-dev and *_dev -- 11 votes >> CSW*-devel and *_devel -- 5 votes >> >> Everyone who participated in the vote can check ballotbin personally >> to verify the numbers. > > For the record, I would like to state that I never saw a vote invite. That's unfortunate! > This might have something to do with the fact that the vote invite > last time, showed up as from > "Maciej at mail.guatec.com" > > It was not even from an @opencsw.org address. And there was no > announce that I saw on the maintainers list, "hey I sent a vote invite > out". My understanding was that people will learn about the vote when they receive e-mails send directly to them. Announcements on the mailing list would be redundant. Of course, I can send redundant notifications to the mailing list, if that helps. I do not have control of the source e-mail address, e-mails are generated and sent by ballotbin. I suggest always monitoring e-mail send directly to each user name, e.g.: "To: @opencsw.(...)" > That being said, I acknowlege that according to the above numbers, we > had good participation, and the majority favors -dev. So I'll be > passing -dev packages through now. Great! > Are there any other non-announced votes currently going on? The gpg vote has ended last night, I'll be sending results shortly. Maciej From maciej at opencsw.org Sat Mar 5 11:48:21 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 5 Mar 2011 10:48:21 +0000 Subject: [csw-maintainers] GPG Key Vote In-Reply-To: References: <1298129678-sup-6465@pinkfloyd.chass.utoronto.ca> <1298682151-sup-9235@pinkfloyd.chass.utoronto.ca> Message-ID: Hello maintainers, The vote results are in. Participation: 8 voters. Vote results: Should the Secretary position hold the key? Result: Yes (5 vs 3) Should the Treasurer position hold the key? Result: Yes (7 vs 1) Should the President position hold the key? Result: Tie (4 vs 4) Should the key be held by board in escrow? Result: Yes (6 vs 2) They are also available as a screenshot from ballotbin on the wiki. http://wiki.opencsw.org/vote-gpgkey Maciej From maciej at opencsw.org Sat Mar 5 11:52:13 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 5 Mar 2011 10:52:13 +0000 Subject: [csw-maintainers] [GAR] libdir vs BUILD64 Message-ID: In the lighttpd build, the libdir is set so that lighttpd uses a subdirectory: libdir = $(prefix)/lib/foo It works for the 32-bit build. When BUILD64 is set to 1, libdir is apparently reset to /opt/csw/lib/sparcv9: /opt/csw/lib/sparcv9/liblightcomp.so What's the proper way of handling custom libdir for 64-bit builds? Maciej From phil at bolthole.com Sat Mar 5 15:47:16 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Mar 2011 06:47:16 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: 2011/3/5 Maciej Blizi?ski > > 2011/3/4 Philip Brown : > > > > It was not even from an @opencsw.org address. And there was no > > announce that I saw on the maintainers list, "hey I sent a vote invite > > out". > > My understanding was that people will learn about the vote when they > receive e-mails send directly to them. ?Announcements on the mailing > list would be redundant. ?Of course, I can send redundant > notifications to the mailing list, if that helps. A single, "every member should have recieved a vote invite" seems appropriate. It was done previously, on the first vote we did via ballotbin. > I suggest always monitoring e-mail send directly to each user name, e.g.: > "To: @opencsw.(...)" I do that already . From phil at bolthole.com Sat Mar 5 15:52:23 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Mar 2011 06:52:23 -0800 Subject: [csw-maintainers] GPG Key Vote In-Reply-To: References: <1298129678-sup-6465@pinkfloyd.chass.utoronto.ca> <1298682151-sup-9235@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/3/5 Maciej Blizi?ski : > Hello maintainers, > > The vote results are in. > > Participation: 8 voters. that's pretty poor turnout, compared to the other vote. I wonder if there were more people who did not get vote invitations. the 7/1 vote is pretty clear. but it makes some of the other ones a bit dubious From bwalton at opencsw.org Mon Mar 7 03:52:45 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Mar 2011 21:52:45 -0500 Subject: [csw-maintainers] [GAR] libdir vs BUILD64 In-Reply-To: References: Message-ID: <1299466300-sup-157@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Mar 05 05:52:13 -0500 2011: Hi Maciej, > libdir = $(prefix)/lib/foo > > It works for the 32-bit build. When BUILD64 is set to 1, libdir is > apparently reset to /opt/csw/lib/sparcv9: > > /opt/csw/lib/sparcv9/liblightcomp.so > > What's the proper way of handling custom libdir for 64-bit builds? A quick skim of the gar code for the relocations makes me wonder if this is a glitch related to the merge-relocated* targets and the mergebase function? I'm not very familiar with this area though, so Dago would be a better person to ask. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Mar 7 03:57:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Mar 2011 21:57:39 -0500 Subject: [csw-maintainers] [GAR] Simple checks for package installation image in PKGROOT In-Reply-To: References: Message-ID: <1299466503-sup-919@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Mar 05 03:12:53 -0500 2011: Hi Maciej, > I first wanted to have support for such checks in GAR, but I've > recently came to a conclusion that it's best to handle such checking > outside of it. What about 'plugins' to checkpkg. These would still be scripts (any language) but would be run by checkpkg. They could be triggered by an environment variable or some other mechanism that points checkpkg at a directory to use. The checkpkg run could then call each script in the directory and bail if $? != 0. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Mon Mar 7 07:32:30 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Mar 2011 07:32:30 +0100 Subject: [csw-maintainers] [GAR] libdir vs BUILD64 In-Reply-To: <1299466300-sup-157@pinkfloyd.chass.utoronto.ca> References: <1299466300-sup-157@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 07.03.2011 um 03:52 schrieb Ben Walton: > Excerpts from Maciej Blizi?ski's message of Sat Mar 05 05:52:13 -0500 2011: >> libdir = $(prefix)/lib/foo >> >> It works for the 32-bit build. When BUILD64 is set to 1, libdir is >> apparently reset to /opt/csw/lib/sparcv9: >> >> /opt/csw/lib/sparcv9/liblightcomp.so >> >> What's the proper way of handling custom libdir for 64-bit builds? > > A quick skim of the gar code for the relocations makes me wonder if > this is a glitch related to the merge-relocated* targets and the > mergebase function? Nope, but it is the wrong variable to overwrite: "libdir" is the exact variable passed to configure in $DIRPATHS. To set the base and to allow isa-specific extensions there is an additional set called "libdir_install", "bindir_install", "libexec_installed" and "sbindir_install". Best regards -- Dago From maciej at opencsw.org Mon Mar 7 09:22:56 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 7 Mar 2011 08:22:56 +0000 Subject: [csw-maintainers] checkpkg plugins Message-ID: [topic changed to checkpkg plugins] 2011/3/7 Ben Walton : > What about 'plugins' to checkpkg. These would still be scripts (any > language) but would be run by checkpkg. ?They could be triggered by > an environment variable or some other mechanism that points checkpkg > at a directory to use. > > The checkpkg run could then call each script in the directory and bail > if $? != 0. The environment in which the checking functions run, is somewhat restricted. - no access to original .pkg file - no access to unpacked files - no assumptions about the host architecture, OS release, or even the operating system type can be made The checking code can only communicate with a designated interface, which allows to make certain queries or assertions, e.g. "which packages contain files named libbar.so.1, an in which directories are these files?", or "Package CSWfoo needs file /opt/csw/lib/libbar.so.1 because binary /opt/csw/bin/foo has libbar.so.1 in NEEDED and /opt/csw/lib in RPATH". The data available to the checking functions are in the form of a single data structure, a combination of dictionaries and lists. It is possible to fit a plugin architecture into the existing code, if communication paths are provided. I could imagine a bit of Python code which would wrap plugins from a certain directory, and took the responsibility of communicating with them. Maciej From phil at bolthole.com Mon Mar 7 17:52:06 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Mar 2011 08:52:06 -0800 Subject: [csw-maintainers] slashdot referenced article Message-ID: http://unarmed.shlomifish.org/909.html "Dealing with Internet Trolls" From bwalton at opencsw.org Tue Mar 8 02:22:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Mar 2011 20:22:34 -0500 Subject: [csw-maintainers] checkpkg plugins In-Reply-To: References: Message-ID: <1299547140-sup-3236@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Mon Mar 07 03:22:56 -0500 2011: Hi Maciej, > It is possible to fit a plugin architecture into the existing code, > if communication paths are provided. I could imagine a bit of > Python code which would wrap plugins from a certain directory, and > took the responsibility of communicating with them. Yes, I it could be made to work. That would more tightly couple checkpkg to GAR though (at least in the sense that checkpkg would expect to be told where plugins live). If this were to be implemented, the packages themselves should carry the plugin code so that it could be verified outside of the GAR/build context. Does that make sense to you? (Note that I'm not really pushing for this, just discussing the idea.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Mar 8 10:02:36 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Mar 2011 09:02:36 +0000 Subject: [csw-maintainers] checkpkg plugins In-Reply-To: <1299547140-sup-3236@pinkfloyd.chass.utoronto.ca> References: <1299547140-sup-3236@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/3/8 Ben Walton : > Excerpts from Maciej Blizi?ski's message of Mon Mar 07 03:22:56 -0500 2011: > > Hi Maciej, > >> It is possible to fit a plugin architecture into the existing code, >> if communication paths are provided. ?I could imagine a bit of >> Python code which would wrap plugins from a certain directory, and >> took the responsibility of communicating with them. > > Yes, I it could be made to work. ?That would more tightly couple > checkpkg to GAR though (at least in the sense that checkpkg would > expect to be told where plugins live). I would need to verify that, but I think that checkpkg can discover where it's being run from, which would allow to locate a plugin subdirectory. > If this were to be > implemented, the packages themselves should carry the plugin code so > that it could be verified outside of the GAR/build context. ?Does that > make sense to you? ?(Note that I'm not really pushing for this, just > discussing the idea.) I wouldn't like checkpkg to execute code contained in the package. A broken package with broken code could for example damage the database and the files I own on the buildfarm. I'd be more inclined to provide a way to include data, which could be later used for checking. The checking code would be in the repository / on the filesystem, and would process input data from the package. As far as code goes, I'm for strict control of what is executed. Maciej From dam at opencsw.org Tue Mar 8 16:22:43 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 16:22:43 +0100 Subject: [csw-maintainers] Proposing new "x" flag References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> Message-ID: Hi, I would like to introduce a new flag "x" in addition to the "p" (patched) flag. It should mean that the packages is "64 bit compatible", whatever that means: - it may contain 64 bit libraries - it may contain 64 bit binaries - it may contain perl modules suitable for 32- and 64 bit perl The last issue is particularly important to me as it should be easily visible to the end user if the module is usable with the new 64 bit perl. Sidenote: The flags would always be alphabetically sorted. Thoughts? Best regards -- Dago From phil at bolthole.com Tue Mar 8 18:29:09 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Mar 2011 09:29:09 -0800 Subject: [csw-maintainers] Proposing new "x" flag In-Reply-To: References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> Message-ID: On Tue, Mar 8, 2011 at 7:22 AM, Dagobert Michelsen wrote: > Hi, > > I would like to introduce a new flag "x" in addition to > the "p" (patched) flag. It should mean that the packages > is "64 bit compatible", whatever that means: >... > Thoughts? Hmm. 2 thoughts: 1. that may be confused with "x86" 2. its interesting to note that sun USED to do this.. but now decided to bundle everything together. no separate 32 vs 64 bit packages that I'm aware of now. > The last issue is particularly important to me as it should > be easily visible to the end user if the module is usable > with the new 64 bit perl. Is there going to be a *separate* "64bit perl" package? or is there going to be one single unified perl package, that is "64bit 'capable'" ? I was going to make a suggestion, but realized that the answer to the above, would change the relevence of it. From james at opencsw.org Tue Mar 8 18:40:51 2011 From: james at opencsw.org (James Lee) Date: Tue, 08 Mar 2011 17:40:51 GMT Subject: [csw-maintainers] Proposing new "x" flag In-Reply-To: References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> Message-ID: <20110308.17405100.1107925112@gyor.oxdrove.co.uk> On 08/03/11, 15:22:43, Dagobert Michelsen wrote regarding [csw-maintainers] Proposing new "x" flag: > I would like to introduce a new flag "x" in addition to > the "p" (patched) flag. It should mean that the packages > is "64 bit compatible", whatever that means: > - it may contain 64 bit libraries > - it may contain 64 bit binaries > - it may contain perl modules suitable for 32- and 64 bit perl Picking up on language, packages may (and many do) include 64 bit files now so presumably you mean that they do/must include 64 bit if tagged x. Are you also proposing that if they are 64 bit they must be tagged x? Requires repackage of a lot of existing packages before the flag is useful. James. From phil at bolthole.com Tue Mar 8 20:01:56 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Mar 2011 11:01:56 -0800 Subject: [csw-maintainers] pkg.opencsw.org Message-ID: My attention was drawn to http://pkg.opencsw.org I would like to suggest that whoever is maintaining it, add a top-level link to http://pkg.opencsw.org/pkgbrowser There is otherwise no clue that it exists. Note that this will make the outputs google-searchable. I presume that this is a good, or at least neutral, thing. From dam at opencsw.org Tue Mar 8 20:58:58 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 20:58:58 +0100 Subject: [csw-maintainers] pkg.opencsw.org In-Reply-To: References: Message-ID: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> Hi Phil, Am 08.03.2011 um 20:01 schrieb Philip Brown: > My attention was drawn to http://pkg.opencsw.org > I would like to suggest that whoever is maintaining it, add a top-level link to > http://pkg.opencsw.org/pkgbrowser > > There is otherwise no clue that it exists. > > Note that this will make the outputs google-searchable. I presume that > this is a good, or at least neutral, thing. It already is linked from http://buildfarm.opencsw.org/experimental.html If you throw a package in /home/experimental/ there will be browserinformation and checkpkg report automatically generated. Best regards -- Dago From dam at opencsw.org Tue Mar 8 21:09:34 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 21:09:34 +0100 Subject: [csw-maintainers] Proposing new "x" flag In-Reply-To: References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> Message-ID: Hi Phil, Am 08.03.2011 um 18:29 schrieb Philip Brown: > On Tue, Mar 8, 2011 at 7:22 AM, Dagobert Michelsen wrote: >> I would like to introduce a new flag "x" in addition to >> the "p" (patched) flag. It should mean that the packages >> is "64 bit compatible", whatever that means: >> ... >> Thoughts? > > Hmm. 2 thoughts: > > 1. that may be confused with "x86" Because it is an "x"? If it is documented this should be no problem. > 2. its interesting to note that sun USED to do this.. but now decided > to bundle everything together. > no separate 32 vs 64 bit packages that I'm aware of now. > >> The last issue is particularly important to me as it should >> be easily visible to the end user if the module is usable >> with the new 64 bit perl. > > Is there going to be a *separate* "64bit perl" package? or is there > going to be one single unified perl package, that is "64bit 'capable'" > ? Sun made separate packages in Solaris 7 for 32 and 64 bit where the 64 bit packages had an append "x" on package name. I suggest making combined packages for 32 and 64 bit. My main intention is Perl modules where it may not be possible to build a 64 bit module for some reason. If a user needs specific modules it should be as easy as possible to see if the 64 bit Perl can be used for this. With the "x" flag it would be sufficient to just look at the module version listing. Best regards -- Dago From dam at opencsw.org Tue Mar 8 21:12:31 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 21:12:31 +0100 Subject: [csw-maintainers] Proposing new "x" flag In-Reply-To: <20110308.17405100.1107925112@gyor.oxdrove.co.uk> References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> <20110308.17405100.1107925112@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 08.03.2011 um 18:40 schrieb James Lee: > On 08/03/11, 15:22:43, Dagobert Michelsen wrote regarding > [csw-maintainers] Proposing new "x" flag: > >> I would like to introduce a new flag "x" in addition to >> the "p" (patched) flag. It should mean that the packages >> is "64 bit compatible", whatever that means: > >> - it may contain 64 bit libraries >> - it may contain 64 bit binaries >> - it may contain perl modules suitable for 32- and 64 bit perl > > Picking up on language, packages may (and many do) include 64 bit > files now so presumably you mean that they do/must include 64 bit if > tagged x. I should prepend "At least one of the following conditions must be fulfilled:" > Are you also proposing that if they are 64 bit they must be tagged > x? Yes. > Requires repackage of a lot of existing packages before the > flag is useful. Well, as I wrote in my other email the main driver is Perl modules and as all Perl modules will be rebuild for perl-dublin http://wiki.opencsw.org/perl-dublin the flag would be accurate and usable at least for these packages. Most of the other packages containing 64 bit are library packages which need also to be rebuild according to -devel/-dev and single library packaging. Best regards -- Dago From phil at bolthole.com Tue Mar 8 21:51:14 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Mar 2011 12:51:14 -0800 Subject: [csw-maintainers] pkg.opencsw.org In-Reply-To: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> References: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> Message-ID: On Tue, Mar 8, 2011 at 11:58 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 08.03.2011 um 20:01 schrieb Philip Brown: >> My attention was drawn to http://pkg.opencsw.org >> I would like to suggest that whoever is maintaining it, add a top-level link to >> http://pkg.opencsw.org/pkgbrowser >> >> There is otherwise no clue that it exists. >> >> Note that this will make the outputs google-searchable. I presume that >> this is a good, or at least neutral, thing. > > It already is linked from > ?http://buildfarm.opencsw.org/experimental.html well that's a good thing, but there there a specific reason why it is NOT linked, from pkg.opencsw.org? From dam at opencsw.org Tue Mar 8 21:54:35 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 21:54:35 +0100 Subject: [csw-maintainers] pkg.opencsw.org In-Reply-To: References: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> Message-ID: Hi Phil, Am 08.03.2011 um 21:51 schrieb Philip Brown: >> Am 08.03.2011 um 20:01 schrieb Philip Brown: >>> My attention was drawn to http://pkg.opencsw.org >>> I would like to suggest that whoever is maintaining it, add a top-level link to >>> http://pkg.opencsw.org/pkgbrowser >>> >>> There is otherwise no clue that it exists. >>> >>> Note that this will make the outputs google-searchable. I presume that >>> this is a good, or at least neutral, thing. >> >> It already is linked from >> http://buildfarm.opencsw.org/experimental.html > > well that's a good thing, but there there a specific reason why it is > NOT linked, from pkg.opencsw.org? Because the reports are specific to what is on the buildfarm. The natural entry point is the buildfarm, so thats why it is linked from there... Best regards -- Dago From phil at bolthole.com Tue Mar 8 22:13:43 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Mar 2011 13:13:43 -0800 Subject: [csw-maintainers] Proposing new "x" flag In-Reply-To: References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> Message-ID: On Tue, Mar 8, 2011 at 12:09 PM, Dagobert Michelsen wrote: > Hi Phil, > > Am 08.03.2011 um 18:29 schrieb Philip Brown: >> On Tue, Mar 8, 2011 at 7:22 AM, Dagobert Michelsen wrote: >>> I would like to introduce a new flag "x" in addition to >>> the "p" (patched) flag. It should mean that the packages >>> is "64 bit compatible", whatever that means: >>> ... >>> Thoughts? >> >> Hmm. ?2 thoughts: >> >> 1. that may be confused with "x86" > > Because it is an "x"? If it is documented this should be no problem. A general-case comment: Documenting something that is counter-intuitive, does not make it not a problem any more. specific case comment: its not in either the catalog name or the pkg name directly. So a maintainer would have to do extra checking to find out this flaw. you indicate that not having 64bit support would be the rare case. As such, we might add a hint to the description, for the rare case. pm_blah - CPAN::blah::blah something here (32bit) From phil at bolthole.com Tue Mar 8 22:16:00 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Mar 2011 13:16:00 -0800 Subject: [csw-maintainers] pkg.opencsw.org In-Reply-To: References: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> Message-ID: On Tue, Mar 8, 2011 at 12:54 PM, Dagobert Michelsen wrote: > Hi Phil, > > Am 08.03.2011 um 21:51 schrieb Philip Brown: > >> >> well that's a good thing, but there there a specific reason why it is >> NOT linked, from pkg.opencsw.org? > > Because the reports are specific to what is on the buildfarm. > The natural entry point is the buildfarm, so thats why it is > linked from there... > So, you are saying that http://pkg.opencsw.org/pkgbrowser/reports/ is only relevant to "things in experimental, on buildfarm"? If so, then wouldnt it make sense to "move" it to be pkgbrowser ? (and then make links at the top level , http://buildfarm.opencsw.org/ , for it?) From dam at opencsw.org Tue Mar 8 22:20:51 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 22:20:51 +0100 Subject: [csw-maintainers] pkg.opencsw.org In-Reply-To: References: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> Message-ID: <8A63C7EF-A786-4102-8992-DE4116175B27@opencsw.org> Hi Phil, Am 08.03.2011 um 22:16 schrieb Philip Brown: > On Tue, Mar 8, 2011 at 12:54 PM, Dagobert Michelsen wrote: >> Hi Phil, >> >> Am 08.03.2011 um 21:51 schrieb Philip Brown: >> >>> >>> well that's a good thing, but there there a specific reason why it is >>> NOT linked, from pkg.opencsw.org? >> >> Because the reports are specific to what is on the buildfarm. >> The natural entry point is the buildfarm, so thats why it is >> linked from there... >> > > So, you are saying that > http://pkg.opencsw.org/pkgbrowser/reports/ > > is only relevant to "things in experimental, on buildfarm"? At this time, yes. > If so, then wouldnt it make sense to "move" it to be > pkgbrowser > > ? > (and then make links at the top level , http://buildfarm.opencsw.org/ , for it?) No, because the longterm idea is to have a general package browser to dive into every package. But as we don't have this neatly ATM it is implemented as experimental feature for maintainers only on buildfarm. Does that make sense? Best regards -- Dago From dam at opencsw.org Tue Mar 8 22:26:14 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Mar 2011 22:26:14 +0100 Subject: [csw-maintainers] Problem with magic checkpkg Message-ID: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> Hi Maciej, I just updated all build machines to current/ and now checkpkg has an issue: mkp: exec( rm -rf /home/dam/spool.5.9-sparc/CSWlibtoolrt ) Traceback (most recent call last): File "gar//bin/checkpkg", line 14, in import database File "/home/dam/mgar/gar/v2/lib/python/database.py", line 10, in import system_pkgmap File "/home/dam/mgar/gar/v2/lib/python/system_pkgmap.py", line 16, in import package_stats File "/home/dam/mgar/gar/v2/lib/python/package_stats.py", line 13, in import checkpkg File "/home/dam/mgar/gar/v2/lib/python/checkpkg.py", line 17, in import inspective_package File "/home/dam/mgar/gar/v2/lib/python/inspective_package.py", line 7, in import magic File "/opt/csw/lib/python/site-packages/magic.py", line 54, in _open = _libraries['magic'].magic_open File "/opt/csw/lib/python/ctypes/__init__.py", line 366, in __getattr__ func = self.__getitem__(name) File "/opt/csw/lib/python/ctypes/__init__.py", line 371, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: ld.so.1: python2.6: fatal: magic_open: can't find symbol gmake: *** [pkgcheck] Error 2 Would you mind having a look? Best regards -- Dago From phil at bolthole.com Tue Mar 8 22:29:38 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Mar 2011 13:29:38 -0800 Subject: [csw-maintainers] pkg.opencsw.org In-Reply-To: <8A63C7EF-A786-4102-8992-DE4116175B27@opencsw.org> References: <2913A9B7-4E2F-4A41-BA2A-DC7DF23528DE@opencsw.org> <8A63C7EF-A786-4102-8992-DE4116175B27@opencsw.org> Message-ID: On Tue, Mar 8, 2011 at 1:20 PM, Dagobert Michelsen wrote: > >> If so, then wouldnt it make sense to "move" it to be >> pkgbrowser >> >> ? >> (and then make links at the top level , http://buildfarm.opencsw.org/ , for it?) > > No, because the longterm idea is to have a general package browser to > dive into every package. But as we don't have this neatly ATM it is > implemented as experimental feature for maintainers only on buildfarm. > Does that make sense? > your explanation, explains how things came to be this way. however, no, I dont think it "makes sense" to leave it this way. I think that at minimum, buildfarm.opencsw.org should have a link, to (whereever it is currently functioning) If it needs to be adjusted later, then lets adjust it later. but meanwhile, lets update it to how things are "for now" ? In my opinion, best to keep the code "portable", and move it over to buildfarm. then, when and if pkg.opencsw.org is ready to run it on "every package", then copy it back and activate it over there as well. If pkg.opencsw.org is meant to be for currently released packages, then there is a problem with having pkg.opencsw.org/pkgbrowser work on [not released packages]. I think that it is useful to have it for released pacakges, and it is also useful to have it for experimental. So its not a matter of picking one OR the other. Lets have it work whereever it is functional? From skayser at opencsw.org Tue Mar 8 23:06:34 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 8 Mar 2011 23:06:34 +0100 Subject: [csw-maintainers] Going ahead with package splits In-Reply-To: References: <0F5DAF73-1660-4FD4-B984-3503FE68E164@baltic-online.de> <219C9F0E-851F-474A-8C77-2D0A1018CDFE@opencsw.org> Message-ID: <20110308220634.GK28572@sebastiankayser.de> * Dagobert Michelsen wrote: > Sebastian: I need feedback on libiconv for a sane package name split > as tons of stuff depends on it and I want to get the dependencies > right and not touch everything again. Will you have time in the next > few days? If not please let me know also so I can prepare the package > split and you can rebuild and release if you want. Please go ahead with the rebuild and release. I won't have time to sit down and work on this in the upcoming days. Sebastian From skayser at opencsw.org Tue Mar 8 23:11:20 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 8 Mar 2011 23:11:20 +0100 Subject: [csw-maintainers] The "[^]" URL decorators on mantis In-Reply-To: References: Message-ID: <20110308221120.GL28572@sebastiankayser.de> * Maciej Blizi??ski wrote: > Mantis currently injects a "[^]" string after each URL. I've just > confused a user on mantis[1], because I couldn't paste in any shell > command that included a URL, without the command being corrupted by > mantis. Can mantis be configured not to inject "[^]" after every URL? I can configure Mantis to disable the linkification of URLs (which also disables the embedding of "[^]"). Sebastian From maciej at opencsw.org Wed Mar 9 01:50:55 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Mar 2011 00:50:55 +0000 Subject: [csw-maintainers] Problem with magic checkpkg In-Reply-To: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> References: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> Message-ID: 2011/3/8 Dagobert Michelsen : > ?File "/opt/csw/lib/python/ctypes/__init__.py", line 371, in __getitem__ > ? ?func = self._FuncPtr((name_or_ordinal, self)) > AttributeError: ld.so.1: python2.6: fatal: magic_open: can't find symbol > gmake: *** [pkgcheck] Error 2 The problem is caused by missing magic.so, a shared object which is supposed to be under /opt/csw/lib/python/site-packages. The breakage of py_libmagic was introduced in version 5.05, but we didn't notice that, because py_libmagic in the catalog stayed at 5.04 while other packages were at 5.05. After building 5.05, I did test the file utility, but not py_magic. I've put in place a check for the presence of the magic.so file, so this particular problem won't happen again: files/check_pkgroot.sh "/home/maciej/src/opencsw/pkg/file/trunk/work/solaris9-sparc/pkgroot" + test -f /home/maciej/src/opencsw/pkg/file/trunk/work/solaris9-sparc/pkgroot/opt/csw/lib/python/site-packages/magic.so gmake: *** [post-merge] Error 1 I've built the previous version, 5.04, while keeping the new package layout. The updated files are available from /home/experimental/maciej. Buildfarm admins, please downgrade py_libmagic on the buildfarm to 5.04 (the REV stamp is today, so pkgutil should pick it up). With the fire on the buildfarm put out, I'll examine what's wrong with 5.05. Maciej From maciej at opencsw.org Wed Mar 9 02:06:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Mar 2011 01:06:35 +0000 Subject: [csw-maintainers] The "[^]" URL decorators on mantis In-Reply-To: <20110308221120.GL28572@sebastiankayser.de> References: <20110308221120.GL28572@sebastiankayser.de> Message-ID: 2011/3/8 Sebastian Kayser : > I can configure Mantis to disable the linkification of URLs (which also > disables the embedding of "[^]"). Slightly annoying... but I'd say that the safety of pasted in code is more important than the convenience of link-clicking. Maciej From maciej at opencsw.org Wed Mar 9 05:12:51 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Mar 2011 04:12:51 +0000 Subject: [csw-maintainers] Problem with magic checkpkg In-Reply-To: References: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> Message-ID: 2011/3/9 Maciej Blizi?ski : > /home/experimental/maciej. ?Buildfarm admins, please downgrade > py_libmagic on the buildfarm to 5.04 (the REV stamp is today, so > pkgutil should pick it up). The package has been downgraded on the buildfarm, checkpkg is working again. From bonivart at opencsw.org Wed Mar 9 09:19:26 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 9 Mar 2011 09:19:26 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with magic checkpkg In-Reply-To: References: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> Message-ID: 2011/3/9 Maciej Blizi?ski : > The package has been downgraded on the buildfarm, checkpkg is working again. Thanks for staying up all night to fix that! :) /peter From maciej at opencsw.org Wed Mar 9 10:15:58 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Mar 2011 09:15:58 +0000 Subject: [csw-maintainers] [csw-buildfarm] Problem with magic checkpkg In-Reply-To: References: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> Message-ID: 2011/3/9 Peter Bonivart : > 2011/3/9 Maciej Blizi?ski : >> The package has been downgraded on the buildfarm, checkpkg is working again. > > Thanks for staying up all night to fix that! :) It would have been faster if I checkpkg was working and telling me what's wrong with the package! I still need to figure out what's the issue with 5.05. I saw in the changelog that there was a rewrite of Python bindings (in pure Python). My guess is that it hasn't been tested on Solaris. I'll post an update when I figure out what was the problem. Maciej From james at opencsw.org Wed Mar 9 10:26:41 2011 From: james at opencsw.org (James Lee) Date: Wed, 09 Mar 2011 09:26:41 GMT Subject: [csw-maintainers] Proposing new "x" flag In-Reply-To: References: <17D4A2B1-29C8-4371-AF58-3F6E75B09ED0@baltic-online.de> <20110308.17405100.1107925112@gyor.oxdrove.co.uk> Message-ID: <20110309.9264100.3546951695@gyor.oxdrove.co.uk> On 08/03/11, 20:12:31, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Proposing new "x" flag: > >> the "p" (patched) flag. It should mean that the packages > >> is "64 bit compatible", whatever that means: > > > >> - it may contain 64 bit libraries > >> - it may contain 64 bit binaries > >> - it may contain perl modules suitable for 32- and 64 bit perl > > > > Picking up on language, packages may (and many do) include 64 bit > > files now so presumably you mean that they do/must include 64 bit if > > tagged x. > I should prepend "At least one of the following conditions must be > fulfilled:" You still need to remove "may" to remove the suggested you are granting permission. James. From maciej at opencsw.org Wed Mar 9 11:56:37 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Mar 2011 10:56:37 +0000 Subject: [csw-maintainers] [csw-buildfarm] Problem with magic checkpkg In-Reply-To: References: <1CA51D33-D364-4AF2-AF77-478B1B035985@opencsw.org> Message-ID: The issue turns out to be two issues. One is that the file Python bindings call ctypes.util.find_library() at runtime, which is not acceptable on production systems[1]. The second issue is that in the OpenCSW environment, the find_library() function does not work at all, which probably has to be fixed in the ctypes (that is, core Python) code. However, theres is no portability issue that cannot be solved with an unportable patch[2]. Updated 5.05 packages are now in experimental[3]. Maciej [1] http://mx.gw.com/pipermail/file/2011/000739.html [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/file/trunk/files/0002-Do-not-use-find_library-at-runtime.patch [3] http://buildfarm.opencsw.org/experimental.html#libmagic From dam at opencsw.org Wed Mar 9 21:44:41 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Mar 2011 21:44:41 +0100 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> Message-ID: <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> Hi Phil, Am 09.03.2011 um 21:31 schrieb Philip Brown: > On Wed, Mar 9, 2011 at 12:24 PM, Ben Walton wrote: >> Excerpts from Philip Brown's message of Wed Mar 09 15:21:57 -0500 2011: >> >>> Errr.. this package seems to have been generated for no good reason >>> whatsoever. So I'm dropping it. >>> It would be nice if could eliminate this stuff from appearing in the future. >>> Or better yet, have something appear that says, "Hey! Rename the old >>> devel to the new dev please" >> >> Actually, this is the obsoletes mechanism at work. For users with the >> old (_devel) package installed, an update will pull this in, which in >> turn pulls in the new _dev package. The old is easily identified by >> /var/sadm/pkg/CSWfoo/obsolete. In the fairly near future, pkgutil is >> going to sprout an option to search and destroy on these packages. >> >> The _devel package is empty of real content but provides a smooth >> transition. > > and do we have a writeup of all this somewheres? A writeup to have an empty transitional package pulling in a new one? We always handled renames this way in the past. The only new thing is that we now have an idiom in GAR to make this as simple as possible: https://sourceforge.net/apps/trac/gar/wiki/ObsoletingPackages And putting "i obsolete" with the obsoleting package names is rather straight forward and done automatically. Best regards -- Dago From phil at bolthole.com Wed Mar 9 22:55:35 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Mar 2011 13:55:35 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> Message-ID: On Wed, Mar 9, 2011 at 12:44 PM, Dagobert Michelsen wrote: > Hi Phil, > > Am 09.03.2011 um 21:31 schrieb Philip Brown: > >>> The _devel package is empty of real content but provides a smooth >>> transition. >> >> and do we have a writeup of all this somewheres? > > A writeup to have an empty transitional package pulling in a new one? > We always handled renames this way in the past. no.. no we havent "always" handled them this way. We have *occasionally* done that. Transitioning from old to new smoothly, is a tricky thing. The "make a stub package to pull in new one", can be nice for "leaf" packages (dependency speaking), or when a package is depended on by waaay too many packages to update in a reasonable amount of time. (although it still has the problem of leaving old obsolete packages around.. yuck) However, when a package is "internal" to a dependancy tree, and it has a limited amount of dependancies, the cleanest way is to NOT make a stub package, but to rely on our existing [conflicts == auto-replace] mechanism. example of using auto-replace: Start with softA, depends on libA softB, depends on libA libA gets renamed to libShinyA. But presume that at the file level, it is 100% compatible with "libA". its just a rename. So, new libShinyA package created. Declared to conflict with libA softA and softB are repackaged to depend on libShinyA. User does an update; either a global one, or one specifically for either softA, or softB. softA gets upgraded.. which pulls in libShinyA. Which then auto-removes the older libA libA has now successfully been transitioned to libShinyA, and there was no need for a stub package. From dam at opencsw.org Wed Mar 9 23:09:44 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Mar 2011 23:09:44 +0100 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> Message-ID: Hi Phil, Am 09.03.2011 um 22:55 schrieb Philip Brown: > On Wed, Mar 9, 2011 at 12:44 PM, Dagobert Michelsen wrote: >> Hi Phil, >> >> Am 09.03.2011 um 21:31 schrieb Philip Brown: >> >>>> The _devel package is empty of real content but provides a smooth >>>> transition. >>> >>> and do we have a writeup of all this somewheres? >> >> A writeup to have an empty transitional package pulling in a new one? >> We always handled renames this way in the past. > > no.. no we havent "always" handled them this way. > We have *occasionally* done that. > Transitioning from old to new smoothly, is a tricky thing. > > The "make a stub package to pull in new one", can be nice for "leaf" > packages (dependency speaking), or when a package is depended on by > waaay too many packages to update in a reasonable amount of time. > (although it still has the problem of leaving old obsolete packages > around.. yuck) > > However, when a package is "internal" to a dependancy tree, and it has > a limited amount of dependancies, the cleanest way is to NOT make a > stub package, but to rely on our existing [conflicts == auto-replace] > mechanism. > > example of using auto-replace: > > Start with > softA, depends on libA > softB, depends on libA > > libA gets renamed to libShinyA. But presume that at the file level, it > is 100% compatible with "libA". its just a rename. > So, new libShinyA package created. Declared to conflict with libA > softA and softB are repackaged to depend on libShinyA. > > > User does an update; either a global one, or one specifically for > either softA, or softB. > softA gets upgraded.. which pulls in libShinyA. Which then > auto-removes the older libA > > libA has now successfully been transitioned to libShinyA, and there > was no need for a stub package. From the task to clean package names in release "dublin" we are targetting I estimate about 500 renames. Handling this on an individual basis is IMHO prone to errors while always using intermediate packages is a simple, clean and easy way to achieve consistent updating. The "I" workaround was necessary to avoid leaving outdated packages around. Now with the "i obsolete" marker the packaging tool has a clean indication when a package can safely be removed and the I-workaround is no longer needed. Following the "I"-approach consistently would probably require rebuilding the whole set and pushing 500 packages at once which would be much harder to do right and to verify. Best regards -- Dago From phil at bolthole.com Wed Mar 9 23:51:13 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Mar 2011 14:51:13 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> Message-ID: On Wed, Mar 9, 2011 at 2:09 PM, Dagobert Michelsen wrote: > Hi Phil, > > > From the task to clean package names in release "dublin" we are targetting > I estimate about 500 renames. Handling this on an individual basis is IMHO > prone to errors while always using intermediate packages is a simple, clean > and easy way to achieve consistent updating. It may be "simple, clean and easy" from the perspective of someone generating a bunch of packages to dump out. But from the perspective of integrating into our package database, its very messy. Even setting aside the issue of potentially having 500 "junk" entries in our databases... which isnt so nice...., there's the issue of file collisions. if you have CSWoldpkg, and CSWnewpkg, and they both have the same files... you cant register "newpkg" until "oldpkg" has been cleaned out of the collision database! > Following the "I"-approach consistently would probably require rebuilding > the whole set and pushing 500 packages at once which would be much harder > to do right and to verify. I would say just the opposite. Using the "i" approach, would lead to doing smaller sets of packages at one time, instead of dumping 100 into the update stream all at once. Seems like the reason we have so many different perl packages, is that only a handful are actually *shared*. Most of the time, perl CPAN modules are used by only 1 or two packages, I think. (please note I said "most", but not all :-) From bwalton at opencsw.org Thu Mar 10 03:14:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Mar 2011 21:14:34 -0500 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> Message-ID: <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Mar 09 17:51:13 -0500 2011: > if you have CSWoldpkg, and CSWnewpkg, and they both have the same > files... you cant register "newpkg" until "oldpkg" has been cleaned > out of the collision database! Which is a trivial sql query, no? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Mar 10 03:40:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Mar 2011 21:40:29 -0500 Subject: [csw-maintainers] Fwd: RE: precompiled PHP binaries for Solaris Message-ID: <1299724738-sup-794@pinkfloyd.chass.utoronto.ca> A colleague's first experience with OpenCSW... :) Thanks -Ben --- Begin forwarded message from Sarosh Jamal --- Ben, I just installed AMP with a bunch of modules and phpmyadmin in a matter of minutes thanks to your advice and pkgutil. This is just "WOW" compared to my previous workflow.. SFW is just what I'd always been referred to and used over the past few years. Now on to configuring and making sure my apps work, finally! Thanks so much, Sarosh --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Mar 10 15:04:37 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 10 Mar 2011 15:04:37 +0100 Subject: [csw-maintainers] Takout of -norunpath / -xnorunpath in GAR References: <61071F91-3B4C-43CD-B039-5FEFDF1AFBE8@baltic-online.de> Message-ID: <1899392E-8E22-4A53-9CBA-93CD094FD7E6@opencsw.org> Dear maintainers, after a lot of trouble in different packages I decided to take out -norunpath -xnorunpath from the GAR defaults. The problem is that the flags must be applied during linkage ("LDFLAGS") and unfortunately there are a number of different linkers available like "cc", "CC" and "ld" which all take different flags and GAR has no way of knowing which one is used. If the "forbidden pathes" error from checkpkg occurs I suggest using the appropriate flag in EXTRA_LINKER_FLAGS The change is in effect since r13727. Best regards -- Dago From bonivart at opencsw.org Thu Mar 10 16:03:25 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Mar 2011 16:03:25 +0100 Subject: [csw-maintainers] Fwd: RE: precompiled PHP binaries for Solaris In-Reply-To: <1299724738-sup-794@pinkfloyd.chass.utoronto.ca> References: <1299724738-sup-794@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Mar 10, 2011 at 3:40 AM, Ben Walton wrote: > A colleague's first experience with OpenCSW... :) Nice! :) /peter From phil at bolthole.com Thu Mar 10 18:05:07 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Mar 2011 09:05:07 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Mar 9, 2011 at 6:14 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Mar 09 17:51:13 -0500 2011: > >> if you have CSWoldpkg, and CSWnewpkg, and they both have the same >> files... ?you cant register "newpkg" until "oldpkg" has been cleaned >> out of the collision database! > > Which is a trivial sql query, no? Because of the automated "block ACCIDENTAL file collisions" checks, every single rename is a manual decision at the moment. Although I suppose I can do something with the "i obsoletes" file. But I also need to spend some time to make sure that any such automated replace, is a **safe** automated replace. It needs safeguards. That will take me finding some quiet time for coding. From bwalton at opencsw.org Thu Mar 10 18:07:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Mar 2011 12:07:43 -0500 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> Message-ID: <1299776810-sup-5144@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Mar 10 12:05:07 -0500 2011: > Because of the automated "block ACCIDENTAL file collisions" checks, > every single rename is a manual decision at the moment. But this is just a different version of a package split, no? Files move between packages all the time. Is the issue the fact that the catalog name is the primary key and that's changing? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Mar 10 19:58:08 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Mar 2011 10:58:08 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: <1299776810-sup-5144@pinkfloyd.chass.utoronto.ca> References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> <1299776810-sup-5144@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Mar 10, 2011 at 9:07 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Mar 10 12:05:07 -0500 2011: > >> Because of ?the automated "block ACCIDENTAL file collisions" checks, >> every single rename is a manual decision at the moment. > > But this is just a different version of a package split, no? ?Files > move between packages all the time. And its often a pain for the person who has to handle the actual package registration. Lucky you, you guys dont have to deal with that pain. I do. being release manager is not a whole lot of fun. It depends on the exact order that the "new" packages get registered. If it happens that a new package with the same PKG name as the existing one gets registered *first*, and thus "frees up" the filename space, then its easy and "automatic", of sorts. But most often it happens the other way, and I need to figure out which one I need to register "first". > ?Is the issue the fact that the > catalog name is the primary key and that's changing? Off the top of my head, the PKG name is primary key. Which would be appropriate, since that's what Solaris "keys" it off, as well. From phil at bolthole.com Thu Mar 10 20:02:31 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Mar 2011 11:02:31 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Mar 10, 2011 at 9:05 AM, Philip Brown wrote: > > > Although I suppose I can do something with the "i obsoletes" file. But > I also need to spend some time to make sure that any such automated > replace, is a **safe** automated replace. It needs safeguards. > That will take me finding some quiet time for coding. nuts. this wont work. would require an extension of the new "obsoletes" style packaging. The problem is that what you guys have implemented (as far as I can see), is only a "this package is obsolete" flag. Whereas what is needed for auto-takeover, is the other direction. What we have usually done with "conflicts with" . You dont seem to have an "obsolete*s*" indicator. only an "obsolete" indicator. The former, would be useful. From phil at bolthole.com Thu Mar 10 20:10:48 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Mar 2011 11:10:48 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: <1299776810-sup-5144@pinkfloyd.chass.utoronto.ca> References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> <1299723228-sup-823@pinkfloyd.chass.utoronto.ca> <1299776810-sup-5144@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Mar 10, 2011 at 9:07 AM, Ben Walton wrote: > > But this is just a different version of a package split, no? ?Files > move between packages all the time. ?Is the issue the fact that the > catalog name is the primary key and that's changing? > btw: there are TWO levels of checks that I guess get hit here. 1. filespace conflicts between packages 2. checks against same PKG name but different catalog name (ie someone changed it "accidentally") bad enough when one changes, but both at same time is nasty From phil at bolthole.com Fri Mar 11 15:09:21 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Mar 2011 06:09:21 -0800 Subject: [csw-maintainers] Obsoleting packages In-Reply-To: <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> References: <201103091619.p29GJpZr025872@login.bo.opencsw.org> <1299702175-sup-3332@pinkfloyd.chass.utoronto.ca> <340FB746-74F2-4E77-8245-CD36ABE1EFA2@opencsw.org> Message-ID: On Wed, Mar 9, 2011 at 12:44 PM, Dagobert Michelsen wrote: > > The only new thing > is that we now have an idiom in GAR to make this as simple as possible: > ?https://sourceforge.net/apps/trac/gar/wiki/ObsoletingPackages > And putting "i obsolete" with the obsoleting package names is rather > straight forward and done automatically > Speaking of automatically... how are we going to automatically make sure these "transitional" packages, get deleted from *our* side in a timely manner? (mirrors, internal databases....) From bonivart at opencsw.org Sat Mar 12 21:26:51 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 12 Mar 2011 21:26:51 +0100 Subject: [csw-maintainers] Old packages left in the package database Message-ID: I noticed that the old libclamav packages are still in the package database, they are not present on the mirrors though. These packages should be removed from the database: CSWlibclamav CSWlibclamav-devel /peter From maciej at opencsw.org Sat Mar 12 23:29:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 12 Mar 2011 22:29:35 +0000 Subject: [csw-maintainers] GPG Key Vote -- INVALID ballot In-Reply-To: References: Message-ID: 2011/3/4 Philip Brown : > How about:? cut and paste (or equivalent) the exact output the voter > will see, and put it on the wiki somewhere. Fair enough, I'll post screenshots of ballot previews. From maciej at opencsw.org Sun Mar 13 13:06:15 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sun, 13 Mar 2011 13:06:15 +0100 Subject: [csw-maintainers] =?utf-8?q?=5BPATCH=5D_opencsw-policy=3A_Copyrig?= =?utf-8?q?ht_notice?= In-Reply-To: <4D6D0A3C.9010500@opencsw.org> References: <4D6D0A3C.9010500@opencsw.org> Message-ID: <1300017975-19993-2-git-send-email-maciej@opencsw.org> This patch sets the copyright of policy package and policy documents to GPL-3.0. Signed-off-by: Maciej Blizinski --- pkg/opencsw-policy/trunk/Makefile | 4 ++-- pkg/opencsw-policy/trunk/checksums | 2 +- pkg/opencsw-policy/trunk/files/index.txt | 21 ++++++++++++++++++++- 3 files changed, 23 insertions(+), 4 deletions(-) diff --git a/pkg/opencsw-policy/trunk/Makefile b/pkg/opencsw-policy/trunk/Makefile index e2f2c18..1d8cf0e 100644 --- a/pkg/opencsw-policy/trunk/Makefile +++ b/pkg/opencsw-policy/trunk/Makefile @@ -10,14 +10,14 @@ define BLURB endef SPKG_SOURCEURL = http://www.opencsw.org MASTER_SITES = http://www.gnu.org/licenses/ -DISTFILES = fdl-1.3.txt +DISTFILES = gpl-3.0.txt CONFIGURE_SCRIPTS = BUILD_SCRIPTS = policy INSTALL_SCRIPTS = policy TEST_SCRIPTS = ARCHALL_CSWopencsw-policy = 1 CATALOGNAME_CSWopencsw-policy = opencsw_policy -LICENSE = fdl-1.3.txt +LICENSE = gpl-3.0.txt BUILD_DEP_PKGS = CSWasciidoc diff --git a/pkg/opencsw-policy/trunk/checksums b/pkg/opencsw-policy/trunk/checksums index e6fa4f0..6986890 100644 --- a/pkg/opencsw-policy/trunk/checksums +++ b/pkg/opencsw-policy/trunk/checksums @@ -1 +1 @@ -10b9de612d532fdeeb7fe8fcd1435cc6 fdl-1.3.txt +b234ee4d69f5fce4486a80fdaf4a4263 gpl-2.0.txt diff --git a/pkg/opencsw-policy/trunk/files/index.txt b/pkg/opencsw-policy/trunk/files/index.txt index 7e9ee64..e4caf9d 100644 --- a/pkg/opencsw-policy/trunk/files/index.txt +++ b/pkg/opencsw-policy/trunk/files/index.txt @@ -3,5 +3,24 @@ OpenCSW packaging policy $Id: Makefile 11888 2010-12-12 12:43:48Z skayser $ :toc: :website: http://www.opencsw.org - :leveloffset: 1 + +Copyright Notice +================ + +Copyright ? 2011 OpenCSW + +Parts of this manual are copied from the Debian GNU/Linux policy manual. +This manual is released with compliance with Debian manual's licensing +terms. + +This manual is free software: you can redistribute it and/or modify it under +the terms of the GNU General Public License as published by the Free Software +Foundation, version 3 of the License. + +This manual is distributed in the hope that it will be useful, but without any +warranty; without even the implied warranty of merchantability or fitness for +a particular purpose. See the GNU General Public License for more details. + +You should have received a copy of the GNU General Public License along with +this program. If not, see . -- 1.7.3.2 From maciej at opencsw.org Sun Mar 13 13:06:14 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sun, 13 Mar 2011 13:06:14 +0100 Subject: [csw-maintainers] [PATCH] opencsw-policy: Copyright notice In-Reply-To: <4D6D0A3C.9010500@opencsw.org> References: <4D6D0A3C.9010500@opencsw.org> Message-ID: <1300017975-19993-1-git-send-email-maciej@opencsw.org> Here's an update for the policy patch, setting the license to GPL-3.0. Debian's license is 2.0+, so it is compatible with Debian's policy manual's license. From maciej at opencsw.org Sun Mar 13 13:34:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 13 Mar 2011 12:34:20 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH] opencsw-policy: Copyright notice In-Reply-To: <1300017975-19993-1-git-send-email-maciej@opencsw.org> References: <4D6D0A3C.9010500@opencsw.org> <1300017975-19993-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/13 Maciej Blizinski : > Here's an update for the policy patch, setting the license to GPL-3.0. > Debian's license is 2.0+, so it is compatible with Debian's policy manual's > license. Here's a summary of the discussion so far: - Maciej has sent out a patch that sets the license to GPL-2.0+ - Phil Brown has not approved the patch and suggested choosing no license, or a BSD license, or another license, after a thorough research including evaluating multiple licenses - Most of project members approve of the patch as presented - There was a suggestion to define the license version explicitly as either 2.0 or 3.0 There was no progress nor any further discussion on the issue in the last week. To bring the issue to a close, I'm setting up a vote whether to submit the patch under question (revised version[1]), or not. The vote will: Open: 2011-03-13 00:00:00 GMT (ballot already open) Close: 2011-03-16 23:59:00 GMT Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-March/014344.html From phil at bolthole.com Sun Mar 13 18:18:41 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 13 Mar 2011 10:18:41 -0700 Subject: [csw-maintainers] Old packages left in the package database In-Reply-To: References: Message-ID: Thanks for pointing that out. i think its taken care of now. On Sat, Mar 12, 2011 at 12:26 PM, Peter Bonivart wrote: > I noticed that the old libclamav packages are still in the package > database, they are not present on the mirrors though. > > These packages should be removed from the database: > > CSWlibclamav > CSWlibclamav-devel > > /peter > From phil at bolthole.com Sun Mar 13 18:44:31 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 13 Mar 2011 10:44:31 -0700 Subject: [csw-maintainers] [csw-devel] [PATCH] opencsw-policy: Copyright notice In-Reply-To: References: <4D6D0A3C.9010500@opencsw.org> <1300017975-19993-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/13 Maciej Blizi?ski : > > The vote will: > Open: 2011-03-13 00:00:00 GMT (ballot already open) > Close: 2011-03-16 23:59:00 GMT Please the cancel this vote, and start it up again in a few days. There are multiple things wrong with the way you proceeded with this. 1. There was no prior presentation of the ballot, as you just recently suggested would do for ballots from now on. (and the ballot does not look good. I think the "view bio" thing is funky) 2. There wasnt even a "okay lets have a vote on this issue, here's what I propose it will look like" 3. there is no decent.. or even mediocre.. summary of issues 4. the vote ballot is presented as "approve a patch". This is HORRIBLY misleading. The vote is really "to determine the license for opencsw documentation", is it not? And as such, you should be offering alternative licenses as a choice. I would like to point out that there was some amount of discussion already , on the pros and cons of each. Some of the discussion was quite useful, in my opinion. It's really "the secretary"s job to summarize this stuff, but in an effort to assist, I will include a mini-summary of things as I read them. First off, a meta-point: I think that *all* votes should have the highest level purpose clearly stated. so that people know, more than "what" they are voting for, but *why* it is important for them to vote in the first place. Issue: determine a license for opencsw documentation Purpose: (aka reason _why_ we need to determine a license for all our docs) [This part is not clear to me; the closest I have seen from anyone is , "(so that other projects can re-use our documentation)" If on the other hand, the purpose is "so that we can freely cut-n-paste debian policy", then it changes the whole rationale for the vote. ] Suggested choices for license: BSD style GPL ("public domain" or "none" have legal issues making them not a good choice for european users) Positives for BSD: allows maximum sharing/reuse Negatives: ? Positives for GPL: allows verbatim cut-n-pasting from debian Negatives: "The harm is that anyone in the future can't use material from a GPL incompatible source" ... [and also limits "downstream" sharing of our docs]" From bwalton at opencsw.org Tue Mar 15 01:49:46 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Mar 2011 20:49:46 -0400 Subject: [csw-maintainers] compiler vs compiler Message-ID: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> Hi All, I bumped an issue tonight that may warrant a bit of discussion. I'm not sure there is a good, global, solution for this, but lets see what people think. In preparing the ruby update to match the specs we set in Dublin, I went to test building a native gem. On my test box, I installed the CSWruby18-gcc4 package that gives me a gcc4 compatible rbconfig.rb. I then went to build the mysql gem with: gem install mysql -- --with-mysql-config=/opt/csw/mysql5/bin/mysql_config. (The first issue I hit is that on the isaexec pulled in the 64-bit version while ruby is currently 32-bit only...side issue). Running it as: gem install mysql -- --with-mysql-config=/opt/csw/mysql5/bin/sparcv8/mysql_config still throws errors as the --cflags argument to that binary returns values suitable for the sun compiler set since that's what it was built with. As our policy is to build with sun cc when possible, this is not an easy problem to work around. I don't think it's the wrong policy either, but it certainly has downsides. It almost forces sites wanting to build locally to use sun cc. Is there a way to build with sun cc but not tie our users to it? (This now costs them an extra support contract.) Having all packages provide gcc4-compatible *-config type binaries might help, but that's no small feat. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Mar 15 02:27:30 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Mar 2011 18:27:30 -0700 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> Message-ID: With things that have complex build environments, and build tools, the "nice" thing for the maintainer to do, is to hand-patch the compiling wrapper to be "polymorphic". To change the arguments based on the value of $CC At various times, this was done for both libtool, and perl's Config.pm(or whatever it is). Dont know if this is still done. I hope it is. From dam at opencsw.org Tue Mar 15 10:39:22 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Mar 2011 10:39:22 +0100 Subject: [csw-maintainers] Major adjustment of GAR defaults Message-ID: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> Fellow maintainers, as it was observed during the talk in Dublin some defaults in GAR are not really sane and it would be good to adjust them. The following variables are candidates for adjustment: * MERGE_SCRIPTS_isa-extra = copy-relocated-only copy-config-only This is copy-relocated-only at the moment. The present setting just copies $(bindir)/*-config but not the 64 bit equivalent $(bindir)/(sparcv9|amd64)/*-config This change should be transparent to all packages only fixing issues about missing *-config for 64 bit. * MERGE_DIRS_isa-extra = $(libdir) This is now $(bindir) $(libdir) $(sbindir) $(libexecdir) However, it was felt that most of the time only the libraries need to be provided for 64 bit and the binaries hence should be excluded for automatic inclusion. Adding the old default to build recipes may or may not be good because there are several other ways to exclude files and it would be confusing to add them explcitily and later on remove them again. * CONFIGURE_ARGS = $(DIRPATHS) This defaults to empty ATM. The number of packages using configure with no arguments should be really small as this would be a non-standard build. * TEST_TARGET = check The previous target was "test". This can be detected and reset for Makefiles requiring the old target. * NOISAEXEC = 1 -> ISAEXEC ?= 0 The current default is to use ISAEXEC when more then one ISA is built. Again as most of the time libraries are used for multiple ISAs the defaulting of ISAEXEC is usually considered wrong and should be enabled together with $(bindir) MERGE_DIRS only when a benefit has been proven. The current name is "NOISAEXEC", changing the default to "1" would require setting "NOISAEXEC = 0" which looks not straight forward. I tend to invert it to default to "ISAEXEC ?= 0" and allow setting of "ISAEXEC = 1" in the Makefile. This can be detected and reset for Makefile using it. * sysconfdir = /etc/opt/csw * localstatedir = /var/opt/csw These have been changed some time ago and should be the default now. Only very specific packages should stick to /opt/csw/etc as default and /opt/csw/var should not be used at all. As the new default should apply to a lot of packages I would rather not update this automatically. I plan to do the update in one large swoop. Thoughts? Best regards -- Dago From dam at opencsw.org Tue Mar 15 10:47:45 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Mar 2011 10:47:45 +0100 Subject: [csw-maintainers] Fwd: [csw-users] nautilus and jpeg References: Message-ID: Hi, (Fwd' from users@) Am 14.03.2011 um 10:42 schrieb Petra Humann: > Hello, > > I' using Sun Solaris 10 x86. > > nautilus is crashing with: > > 7 {host}:~>nautilus > ** > GdkPixbuf:ERROR:io-jpeg.c:123:fatal_error_handler: code should not be reached > > ** (process:7447): WARNING **: Read error: bytes 0: Error 0 > Abort > Exit 134 > > 8 {host}:~>truss nautilus | & grep jpeg > xstat(2, "/opt/csw/lib/libjpeg.so.62", 0x080471D8) = 0 > resolvepath("/opt/csw/lib/libjpeg.so.62", "/opt/csw/lib/libjpeg.so.62.0.0", 1023) = 30 > open("/opt/csw/lib/libjpeg.so.62", O_RDONLY) = 3 > /1: stat64("/opt/csw/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so", 0x08036F00) = 0 > /1: xstat(2, "/opt/csw/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so", 0x080367C0) = 0 > /1: resolvepath("/opt/csw/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so", "/opt/csw/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so", 1023) = 59 > /1: open("/opt/csw/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so", O_RDONLY) = 21 > /1: xstat(2, "/opt/csw/lib/libjpeg.so.7", 0x08036708) = 0 > /1: resolvepath("/opt/csw/lib/libjpeg.so.7", "/opt/csw/lib/libjpeg.so.7.0.0", 1023) = 29 > /1: open("/opt/csw/lib/libjpeg.so.7", O_RDONLY) = 21 > GdkPixbuf:ERROR:io-jpeg.c:123:fatal_error_handler: code should not be reached > > Whereis the error? > Opening a jpeg file with eog is also crashing with the same error. > > Thank you. > Petra Humann Anfang der weitergeleiteten E-Mail: > Von: Petra Humann > Datum: 15. M?rz 2011 10:43:16 MEZ > An: Questions and discussions > Betreff: Re: [csw-users] nautilus and jpeg > Antwort an: Questions and discussions > > > Am 14.03.2011 um 11:03 schrieb James Lee: > >> Solution: use one jpeg lib. >> Suggestion: get nautilus rebuilt. > So all applications using libjpeg.so.62 need to rebuilt. > http://www.opencsw.org/packages/jpeg/: These are 133 software packages. > > I made a symblic link from /opt/csw/lib/libjpeg.so.62 to /opt/csw/lib/libjpeg.so.7. > Now nautilus and eog work. > But if I log in in Gnome(CSW), the session crashs with "segmentation fault" yet > after a few seconds or minutes. Rebuilding 133 packages is quite a task. James, what do you suggest? Rolling back only the packages in the chain? Unfortunately a lot of these http://www.opencsw.org/packages/jpeg are unmaintained ATM. Other ideas anyone? Best regards -- Dago From phil at bolthole.com Tue Mar 15 16:30:40 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Mar 2011 08:30:40 -0700 Subject: [csw-maintainers] Major adjustment of GAR defaults In-Reply-To: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> References: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> Message-ID: On Tue, Mar 15, 2011 at 2:39 AM, Dagobert Michelsen wrote: > .... > > I plan to do the update in one large swoop. > > Thoughts? > These are all good changes. The only potential issue, is in somehow alerting maintainers on rebuild of a package, "Hey, the behaviour has changed since this was last built" If gar was changed to be modeled after usual software practices.. with explicit "releases"... this would be trivial. Then each recipe could trivially contain some kind of [last built for GAR v#] marker, and there could be a warning when the gar version is bumped. Note also, that it would not be desirable to have a warning each and every time something is touched in gar; only changes that justify bumping the "gar release version" number. From phil at bolthole.com Tue Mar 15 16:38:05 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Mar 2011 08:38:05 -0700 Subject: [csw-maintainers] Fwd: [csw-users] nautilus and jpeg In-Reply-To: References: Message-ID: On Tue, Mar 15, 2011 at 2:47 AM, Dagobert Michelsen wrote: > > Unfortunately a lot of these > ?http://www.opencsw.org/packages/jpeg > are unmaintained ATM. > > Other ideas anyone? > If one wanted to be lazy about the updates, it's worth noting that not ALL "133 packages" need to be recompiled. Only packages that intersect with other packages, that use new jpeg. And even of those, they can be prioritized into sets. 1. kde packages (actually, I'm not sure the kde packages intersect with "newer" jpeg at all. this may be ignorable) 2. gnome packages (30 of them?) Probably the rest do not "need" to be recompiled, although of course it would be nice. From gadavis at opencsw.org Tue Mar 15 18:01:11 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Tue, 15 Mar 2011 10:01:11 -0700 Subject: [csw-maintainers] Major adjustment of GAR defaults In-Reply-To: References: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> Message-ID: <839D9BC6-083C-4A99-955F-76695C6247CA@opencsw.org> On Mar 15, 2011, at 8:30 AM, Philip Brown wrote: > On Tue, Mar 15, 2011 at 2:39 AM, Dagobert Michelsen wrote: >> .... >> >> I plan to do the update in one large swoop. >> >> Thoughts? >> > > These are all good changes. The only potential issue, is in somehow > alerting maintainers on rebuild of a package, "Hey, the behaviour has > changed since this was last built" > > If gar was changed to be modeled after usual software practices.. with > explicit "releases"... this would be trivial. > Then each recipe could trivially contain some kind of [last built for > GAR v#] marker, and there could be a warning when the gar version is > bumped. > > Note also, that it would not be desirable to have a warning each and > every time something is touched in gar; only changes that justify > bumping the "gar release version" number. I like this idea. It's currently a bit tough to tell when a big change in behavior to GAR is made. From skayser at opencsw.org Wed Mar 16 00:15:31 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Mar 2011 00:15:31 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> Message-ID: <20110315231531.GH24305@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 09.11.2009 um 17:11 schrieb Maciej (Matchek) Blizinski: > >On Sat, Nov 7, 2009 at 9:36 AM, rupert THURNER > >wrote: > >>can we delete the tag in the repository itself by doing something > >>like "svn > >>rm https://.../bdb3/tags/..." ? > > > >I tried something different: I cd'd into the > >bdb3-stub-to-bdb33-UNRELEASED directory, ran "svn up" -- it completed > >without errors. I went one level up, ran "svn up" again, it worked. > >Back to the 'pkg' level, svn up --ignore-externals -- it worked. > > > >I'm wondering it it would also work for other people. > > Yes, it does. SVN does feel strange from time to time. I do keep > a backup of the tree around, have to check some time... After Maciej reported that he encountered the issue again, I've deleted and re-committed the affected directory (hoping that this will simply solve the problem). If someone still stumbles upon this issue please let me know. Sebastian From bwalton at opencsw.org Wed Mar 16 03:40:10 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Mar 2011 22:40:10 -0400 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> Message-ID: <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Mar 14 21:27:30 -0400 2011: > With things that have complex build environments, and build tools, the > "nice" thing for the maintainer to do, is to hand-patch the compiling > wrapper to be "polymorphic". > To change the arguments based on the value of $CC This works, but is a pita for the maintainer and somewhat so for the user. I think a better approach is the one I'm taking with ruby...Provide the sun cc version of everything by default, but it's setup with alternatives for any binary, etc files that matter. Then, offer a -gcc4 sub-package that provides higher priority alternatives that use gcc. This makes it easier for the maintainer (build via modulations in GAR, no patching required) and the users who can now toggle the preference with a standard tool. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Mar 16 09:08:50 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Mar 2011 09:08:50 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... References: Message-ID: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> Hi Rupert, Anfang der weitergeleiteten E-Mail: > Von: rupert THURNER > Datum: 16. M?rz 2011 08:24:23 MEZ > An: Dagobert Michelsen , DOGAN Ihsan > Betreff: Fwd: help needed for subversion ... > > otherwise could you forward the mail below ... I am still failing to change my sender address out of android :( > > Sure :-) > >> ---------- Forwarded message ---------- >> From: "rupert THURNER" >> Date: Mar 16, 2011 7:58 AM >> Subject: help needed for subversion ... >> To: "internal list for the CSW maintainers" >> >> hi, >> >> i wanted to do an emergency build of subversion, as there is a remote denial of service possibility only requiring read permission, see http://subversion.apache.org/security/CVE-2011-0715-advisory.txt. >> >> after getting checkpkg errors, i tried to spin a >> $ SKIPTEST=1 gmake repackage remerge >> quickly ... but the checkpkg errors stayed the same. >> >> so i do a replatform again and will look in two days :) if somebody would have time to spin it as well, or look earlier than i can, i'd be very glad. >> >> for checkpkg: >> would it be a possibility to do one of (1) use automatically the "old" gar version so it reliably builds, or (2) enable a continuous integration build so a gar change immediately lets the build of subversion fail? >> >> rupert. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Mar 16 09:26:31 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 16 Mar 2011 08:26:31 +0000 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> Message-ID: > Von: rupert THURNER > i wanted to do an emergency build of subversion, as there is a remote denial > of service possibility only requiring read permission, > see?http://subversion.apache.org/security/CVE-2011-0715-advisory.txt. > after getting checkpkg errors, i tried to spin a > $ SKIPTEST=1 gmake repackage remerge > quickly ... but the checkpkg errors stayed the same. After changing overrides, repackage is not enough. Overrides are generated during the merge stage, so you need call the remerge target. Maciej From bonivart at opencsw.org Wed Mar 16 10:50:48 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 16 Mar 2011 10:50:48 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> Message-ID: On Wed, Mar 16, 2011 at 9:08 AM, Dagobert Michelsen wrote: > after getting checkpkg errors, i tried to spin a > $ SKIPTEST=1 gmake repackage remerge > quickly ... but the checkpkg errors stayed the same. SKIPTEST skips the software tests (make test/check) in the middle, not our package tests (checkpkg) afterwards. /peter From phil at bolthole.com Wed Mar 16 17:28:44 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Mar 2011 09:28:44 -0700 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 15, 2011 at 7:40 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Mar 14 21:27:30 -0400 2011: > >> With things that have complex build environments, and build tools, the >> "nice" thing for the maintainer to do, is to hand-patch the compiling >> wrapper to be "polymorphic". >> To change the arguments based on the value of $CC > > This works, but is a pita for the maintainer and somewhat so for the > user. How is "I dont have to think; the tool will do it for me", a "pita for the user" ?? > ?I think a better approach is the one I'm taking with > ruby...Provide the sun cc version of everything by default, but it's > setup with alternatives for any binary, etc files that matter. ?Then, > offer a -gcc4 sub-package that provides higher priority alternatives > that use gcc. > > This makes it easier for the maintainer (build via modulations in GAR, > no patching required) and the users who can now toggle the preference > with a standard tool. Err, no... *users* cannot toggle the preference. only sysadmins can. Thats why its not the best solution. From bwalton at opencsw.org Wed Mar 16 17:32:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Mar 2011 12:32:15 -0400 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> Message-ID: <1300293018-sup-7525@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Mar 16 12:28:44 -0400 2011: > How is "I dont have to think; the tool will do it for me", a "pita > for the user" ?? The do have to think. They need to ensure CC is set properly in the environment. > Err, no... *users* cannot toggle the preference. only sysadmins can. > Thats why its not the best solution. Users in the sense of site admins. Admins control what compilers are available, so it's a good idea to allow them to make the choice. It's also possible, using alternatives to allow both choices if the user (non-admin) wants to install an alternate compiler locally, etc. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Mar 16 17:51:40 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Mar 2011 09:51:40 -0700 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: <1300293018-sup-7525@pinkfloyd.chass.utoronto.ca> References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> <1300293018-sup-7525@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Mar 16, 2011 at 9:32 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Mar 16 12:28:44 -0400 2011: > >> How is "I dont have to think; the tool will do it for me", a "pita >> for the user" ?? > > The do have to think. ?They need to ensure CC is set properly in the > environment. That is standard practice for practically all software build sysems. If it isnt defined, it usually gets defined. So still pretty much on the "dont have to think" level. >> Err, no... *users* cannot toggle the preference. only sysadmins can. >> Thats why its not the best solution. > > Users in the sense of site admins. ?Admins control what compilers are > available, and often, they choose to have both sun cc and gcc available to their users. That's why the auto-adapt methodology serves our customers better. Yes, its more work for maintainers. But that is why our customers value CSW maintainers. They do more work, so CSW *users* do less work. From gadavis at opencsw.org Thu Mar 17 01:50:35 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Wed, 16 Mar 2011 17:50:35 -0700 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> <1300293018-sup-7525@pinkfloyd.chass.utoronto.ca> Message-ID: <442126CA-4816-4209-A36C-35E4C256EED8@opencsw.org> In most cases, the compilers are also installed by the sysadmin. Therefore, the sysadmin is going to have to intervene no matter what. I don't see the need to jump through a bunch of hoops for an edge case of an edge case - the alternatives mechanism looks perfectly serviceable. On Mar 16, 2011, at 9:51 AM, Philip Brown wrote: > On Wed, Mar 16, 2011 at 9:32 AM, Ben Walton wrote: >> Excerpts from Philip Brown's message of Wed Mar 16 12:28:44 -0400 2011: >> >>> How is "I dont have to think; the tool will do it for me", a "pita >>> for the user" ?? >> >> The do have to think. They need to ensure CC is set properly in the >> environment. > > That is standard practice for practically all software build sysems. > If it isnt defined, it usually gets defined. So still pretty much on > the "dont have to think" level. > > >>> Err, no... *users* cannot toggle the preference. only sysadmins can. >>> Thats why its not the best solution. >> >> Users in the sense of site admins. Admins control what compilers are >> available, > > and often, they choose to have both sun cc and gcc available to their users. > That's why the auto-adapt methodology serves our customers better. > Yes, its more work for maintainers. > But that is why our customers value CSW maintainers. They do more > work, so CSW *users* do less work. > _______________________________________________ > 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 Thu Mar 17 03:02:42 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Mar 2011 19:02:42 -0700 Subject: [csw-maintainers] compiler vs compiler In-Reply-To: <442126CA-4816-4209-A36C-35E4C256EED8@opencsw.org> References: <1300149799-sup-5893@pinkfloyd.chass.utoronto.ca> <1300242928-sup-5493@pinkfloyd.chass.utoronto.ca> <1300293018-sup-7525@pinkfloyd.chass.utoronto.ca> <442126CA-4816-4209-A36C-35E4C256EED8@opencsw.org> Message-ID: On Wed, Mar 16, 2011 at 5:50 PM, Geoff Davis wrote: > In most cases, the compilers are also installed by the sysadmin. Therefore, the sysadmin is going to have to intervene no matter what. Errr.. what? what you said doesnt make sense. how does the sysadmin going to "have to intervene", if the build tool is autosensing? for 99% percent of all development use, building tools tends to be some variant of ./configure blah blah blah configure will automatically set CC to SOMETHING, if it is unset. So if our side auto-switches based on CC, where is this supposed intervention needed? I am coming from the standpoint of, "the generic build environment is already in place. the end user wants to choose one of the already installed compilers, that they are already using, to compile something that needs one of our packages" > I don't see the need to jump through a bunch of hoops for an edge case of an edge case That is another issue. If people want to decide based on that, that is reasonable. I just object to people making invalid claims about use, rather than just being honest and saying, "I dont want to do the extra work". And really, the extra work is pretty #@$@# trivial.About the same amount of work compared to setting up alternatives to be the front end. We could actually make a generic template for this. But here's a quick hackjob. If someone is already going to the trouble of providing something for "alternatives" to point at, they already have some equivalent of bin/compile.cc bin/compile.gcc So then instead of providing /opt/csw/bin/bin/compile (alternatives set symlink to compile.XX) just provide as /opt/csw/bin/compile ----------------------- #!/bin/ksh -p BUILD_EXEC=/opt/csw/bin/compile.cc case "$CC" in gcc|*/gcc) BUILD_EXEC=/opt/csw/bin/compile.gcc esac exec $BUILD_EXEC "$@" -------------------- There. done. From bwalton at opencsw.org Thu Mar 17 12:16:10 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 17 Mar 2011 07:16:10 -0400 Subject: [csw-maintainers] Major adjustment of GAR defaults In-Reply-To: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> References: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> Message-ID: <580f4177-402b-46b8-9746-967b77d1394c@email.android.com> I think all of the proposed changes sound good. Thanks -Ben Dagobert Michelsen wrote: Fellow maintainers, as it was observed during the talk in Dublin some defaults in GAR are not really sane and it would be good to adjust them. The following variables are candidates for adjustment: * MERGE_SCRIPTS_isa-extra = copy-relocated-only copy-config-only This is copy-relocated-only at the moment. The present setting just copies $(bindir)/*-config but not the 64 bit equivalent $(bindir)/(sparcv9|amd64)/*-config This change should be transparent to all packages only fixing issues about missing *-config for 64 bit. * MERGE_DIRS_isa-extra = $(libdir) This is now $(bindir) $(libdir) $(sbindir) $(libexecdir) However, it was felt that most of the time only the libraries need to be provided for 64 bit and the binaries hence should be excluded for automatic inclusion. Adding the old default to build recipes may or may not be good because there are several other ways to exclude files and it would be confusing to add them explcitily and later on remove them again. * CONFIGURE_ARGS = $(DIRPATHS) This defaults to empty ATM. The number of packages using configure with no arguments should be really small as this would be a non-standard build. * TEST_TARGET = check The previous target was "test". This can be detected and reset for Makefiles requiring the old target. * NOISAEXEC = 1 -> ISAEXEC ?= 0 The current default is to use ISAEXEC when more then one ISA is built. Again as most of the time libraries are used for multiple ISAs the defaulting of ISAEXEC is usually considered wrong and should be enabled together with $(bindir) MERGE_DIRS only when a benefit has been proven. The current name is "NOISAEXEC", changing the default to "1" would require setting "NOISAEXEC = 0" which looks not straight forward. I tend to invert it to default to "ISAEXEC ?= 0" and allow setting of "ISAEXEC = 1" in the Makefile. This can be detected and reset for Makefile using it. * sysconfdir = /etc/opt/csw * localstatedir = /var/opt/csw These have been changed some time ago and should be the default now. Only very specific packages should stick to /opt/csw/etc as default and /opt/csw/var should not be used at all. As the new default should apply to a lot of packages I would rather not update this automatically. I plan to do the update in one large swoop. Thoughts? 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. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Mar 17 12:56:44 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 17 Mar 2011 11:56:44 +0000 Subject: [csw-maintainers] Major adjustment of GAR defaults In-Reply-To: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> References: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> Message-ID: 2011/3/15 Dagobert Michelsen : > Fellow maintainers, > > as it was observed during the talk in Dublin some defaults in GAR are > not really sane and it would be good to adjust them. (...) > > Thoughts? I think that all of these changes are beneficial and worth making. What we can think about is minimizing potential negative impact, such as broken builds. Changes also need to be communicated. I would suggest creating a branch of GAR, introducing the change in there, letting a few brave test them. Testing instructions would be useful: "To test the new GAR branch, run these commands: ...". Maciej From dam at opencsw.org Thu Mar 17 14:22:48 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 17 Mar 2011 14:22:48 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> Message-ID: Hi Rupert, From: "rupert THURNER" > i wanted to do an emergency build of subversion, as there is a remote denial of service possibility only requiring read permission, see http://subversion.apache.org/security/CVE-2011-0715-advisory.txt. > > after getting checkpkg errors, i tried to spin a > $ SKIPTEST=1 gmake repackage remerge > quickly ... but the checkpkg errors stayed the same. The order is reversed :-) Try gmake remerge && gmake repackage > so i do a replatform again and will look in two days :) if somebody would have time to spin it as well, or look earlier than i can, i'd be very glad. > > for checkpkg: > would it be a possibility to do one of (1) use automatically the "old" gar version so it reliably builds, or (2) enable a continuous integration build so a gar change immediately lets the build of subversion fail? This would of course be possible but it would not be good: the udpated checkpkg catches much more errors and when they show up it usually means the package needs more fixing instead of "please let me release what was thought to be good yesterday". Best regards -- Dago From skayser at opencsw.org Thu Mar 17 14:13:02 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Mar 2011 14:13:02 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> Message-ID: <20110317131302.GO24305@sebastiankayser.de> * Dagobert Michelsen wrote: > From: "rupert THURNER" > > i wanted to do an emergency build of subversion, as there is a remote denial of service possibility only requiring read permission, see http://subversion.apache.org/security/CVE-2011-0715-advisory.txt. > > > > [...] > > > > for checkpkg: > > would it be a possibility to do one of (1) use automatically the "old" gar version so it reliably builds, or (2) enable a continuous integration build so a gar change immediately lets the build of subversion fail? > > This would of course be possible but it would not be good: the udpated > checkpkg catches much more errors and when they show up it usually means > the package needs more fixing instead of "please let me release what was > thought to be good yesterday". I agree though that the possibility of emergency-building a package tweak with the GAR version that was used to build the previous package revision is something that sounds helpful. Dago, could we start to integrate the GAR URL & revision that's used for building a package in pkginfo? I remember that we had the discussion previously and OPENCSW_REPOSITORY was mentioned. The used GAR revision isn't necessarily the same though. Sebastian From dam at opencsw.org Thu Mar 17 14:38:54 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 17 Mar 2011 14:38:54 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <20110317131302.GO24305@sebastiankayser.de> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> <20110317131302.GO24305@sebastiankayser.de> Message-ID: <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> Hi Sebastian, Am 17.03.2011 um 14:13 schrieb Sebastian Kayser: > * Dagobert Michelsen wrote: >> From: "rupert THURNER" >>> i wanted to do an emergency build of subversion, as there is a remote denial of service possibility only requiring read permission, see http://subversion.apache.org/security/CVE-2011-0715-advisory.txt. >>> >>> [...] >>> >>> for checkpkg: >>> would it be a possibility to do one of (1) use automatically the "old" gar version so it reliably builds, or (2) enable a continuous integration build so a gar change immediately lets the build of subversion fail? >> >> This would of course be possible but it would not be good: the udpated >> checkpkg catches much more errors and when they show up it usually means >> the package needs more fixing instead of "please let me release what was >> thought to be good yesterday". > > I agree though that the possibility of emergency-building a package > tweak with the GAR version that was used to build the previous package > revision is something that sounds helpful. > > Dago, could we start to integrate the GAR URL & revision that's used for > building a package in pkginfo? I remember that we had the discussion > previously and OPENCSW_REPOSITORY was mentioned. The used GAR revision > isn't necessarily the same though. As there is only one revision for the whole svn tree including GAR and the packages the tree and number is sufficient. The URL and revision is in the packages for a long time now: web at web [web]:/home/web/bin > pkgparam CSWiconv OPENCSW_REPOSITORY https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libiconv/trunk at 5766 You can use the revision to fixate the external link on checking out GAR. This should best be done using by using mgar and with some build option to it, like "mgar --legacy-rebuild" or something. Best regards -- Dago From bonivart at opencsw.org Thu Mar 17 15:58:37 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 17 Mar 2011 15:58:37 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> <20110317131302.GO24305@sebastiankayser.de> <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> Message-ID: On Thu, Mar 17, 2011 at 2:38 PM, Dagobert Michelsen wrote: > As there is only one revision for the whole svn tree including GAR and > the packages the tree and number is sufficient. The URL and revision is > in the packages for a long time now: > > ?web at web [web]:/home/web/bin > pkgparam CSWiconv OPENCSW_REPOSITORY > ?https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libiconv/trunk at 5766 > > You can use the revision to fixate the external link on checking out GAR. > This should best be done using by using mgar and with some build option > to it, like "mgar --legacy-rebuild" or something. I use an old GAR for pkgutil since I still want to publish Solaris 8 packages and newer GAR requires packages only available on Solaris 9. I have it locked on 9999 or something in that dir. /peter From skayser at opencsw.org Thu Mar 17 16:00:19 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Mar 2011 16:00:19 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> <20110317131302.GO24305@sebastiankayser.de> <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> Message-ID: <20110317150019.GP24305@sebastiankayser.de> * Dagobert Michelsen wrote: > As there is only one revision for the whole svn tree including GAR and > the packages the tree and number is sufficient. The URL and revision is > in the packages for a long time now: > > web at web [web]:/home/web/bin > pkgparam CSWiconv OPENCSW_REPOSITORY > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libiconv/trunk at 5766 > > You can use the revision to fixate the external link on checking out GAR. Understood, but I fear there's a very common scenario where this doesn't yield the proper result. Person A and B do the following: * A checks out the whole tree * B commits several changes to GAR * A doesn't update GAR, commits changes to a package recipe * A builds this package Doesn't the repo revision from OPENCSW_REPOSITORY then refer to a GAR revision which is newer than the one that was actually used to build the package? Also, from looking at the _REVISION code for OPENCSW_REPOSITORY it seems to rely on the (to be obsoleted) gar/ symlink, right? http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L597 > This should best be done using by using mgar and with some build option > to it, like "mgar --legacy-rebuild" or something. Definitly. As soon as the general concept is sorted, I'll start integrating an appropriate mechanism. Sebastian From skayser at opencsw.org Thu Mar 17 16:06:51 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Mar 2011 16:06:51 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> <20110317131302.GO24305@sebastiankayser.de> <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> Message-ID: <20110317150651.GQ24305@sebastiankayser.de> * Peter Bonivart wrote: > On Thu, Mar 17, 2011 at 2:38 PM, Dagobert Michelsen wrote: > > As there is only one revision for the whole svn tree including GAR and > > the packages the tree and number is sufficient. The URL and revision is > > in the packages for a long time now: > > > > ?web at web [web]:/home/web/bin > pkgparam CSWiconv OPENCSW_REPOSITORY > > ?https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libiconv/trunk at 5766 > > > > You can use the revision to fixate the external link on checking out GAR. > > This should best be done using by using mgar and with some build option > > to it, like "mgar --legacy-rebuild" or something. > > I use an old GAR for pkgutil since I still want to publish Solaris 8 > packages and newer GAR requires packages only available on Solaris 9. > I have it locked on 9999 or something in that dir. When we'll introduce GARBRANCH to the build recipes, I could easily add support for an optional revision specifier too, e.g. GARBRANCH = v2 at 9999 mgar would then take care to checkout the required GAR revision to .buildsys/v2 at 9999 and use this instead of plain v2. Sebastian From dam at opencsw.org Thu Mar 17 16:26:55 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 17 Mar 2011 16:26:55 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <20110317150019.GP24305@sebastiankayser.de> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> <20110317131302.GO24305@sebastiankayser.de> <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> <20110317150019.GP24305@sebastiankayser.de> Message-ID: <4BFDD281-5AE4-4DCE-BA88-FC9CF2D579DD@opencsw.org> Hi Sebastian, Am 17.03.2011 um 16:00 schrieb Sebastian Kayser: > * Dagobert Michelsen wrote: >> As there is only one revision for the whole svn tree including GAR and >> the packages the tree and number is sufficient. The URL and revision is >> in the packages for a long time now: >> >> web at web [web]:/home/web/bin > pkgparam CSWiconv OPENCSW_REPOSITORY >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libiconv/trunk at 5766 >> >> You can use the revision to fixate the external link on checking out GAR. > > Understood, but I fear there's a very common scenario where this doesn't > yield the proper result. Person A and B do the following: > > * A checks out the whole tree > * B commits several changes to GAR > * A doesn't update GAR, commits changes to a package recipe > * A builds this package This would break it, yes. The only way to check this is to use something like Hudson which always builds at consistent state. With "mgar package" you could also enforce this as it requires a commit or "UNCOMMITTED" would be in the package name. You could update GAR after commit to exactly the commmitted level before the actual package build. > Doesn't the repo revision from OPENCSW_REPOSITORY then refer to a GAR > revision which is newer than the one that was actually used to build the > package? In the above case, yes, but it is fixable, also as above. > Also, from looking at the _REVISION code for OPENCSW_REPOSITORY it seems > to rely on the (to be obsoleted) gar/ symlink, right? I don't think so. > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L597 > >> This should best be done using by using mgar and with some build option >> to it, like "mgar --legacy-rebuild" or something. > > Definitly. As soon as the general concept is sorted, I'll start > integrating an appropriate mechanism. Cool. Best regards -- Dago From dam at opencsw.org Thu Mar 17 16:29:03 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 17 Mar 2011 16:29:03 +0100 Subject: [csw-maintainers] Fwd: help needed for subversion ... In-Reply-To: <20110317150651.GQ24305@sebastiankayser.de> References: <5CEFE228-C950-4FE8-8123-D56E631DF776@opencsw.org> <20110317131302.GO24305@sebastiankayser.de> <1A2A2BFA-7828-424D-BF81-BC67D55A2340@opencsw.org> <20110317150651.GQ24305@sebastiankayser.de> Message-ID: Hi Sebastian, Am 17.03.2011 um 16:06 schrieb Sebastian Kayser: > When we'll introduce GARBRANCH to the build recipes, I could easily add > support for an optional revision specifier too, e.g. > > GARBRANCH = v2 at 9999 > > mgar would then take care to checkout the required GAR revision to > .buildsys/v2 at 9999 and use this instead of plain v2. Most of the time this will not be good, apart from special test branches. The goal should be to build all packages with one GAR version. Fixating for a rebuild would be ok, maybe it could be automatically added on branching? Best regards -- Dago From maciej at opencsw.org Thu Mar 17 17:10:17 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 17 Mar 2011 16:10:17 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH] opencsw-policy: Copyright notice In-Reply-To: References: <4D6D0A3C.9010500@opencsw.org> <1300017975-19993-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/13 Philip Brown : > 2011/3/13 Maciej Blizi?ski : >> >> The vote will: >> Open: 2011-03-13 00:00:00 GMT (ballot already open) >> Close: 2011-03-16 23:59:00 GMT > > Please ?the cancel this vote, and start it up again in a few days. > There are multiple things wrong with the way you proceeded with this. By saying "wrong", you imply that the way I proceeded with the vote, deviated from a standard procedure. It would be helpful if you provided a reference to what that procedure is, so that we can review whether the points you have raised are valid, or not. Maciej From phil at bolthole.com Thu Mar 17 17:31:52 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Mar 2011 09:31:52 -0700 Subject: [csw-maintainers] [csw-devel] [PATCH] opencsw-policy: Copyright notice In-Reply-To: References: <4D6D0A3C.9010500@opencsw.org> <1300017975-19993-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/17 Maciej Blizi?ski : > 2011/3/13 Philip Brown : >> 2011/3/13 Maciej Blizi?ski : >>> >>> The vote will: >>> Open: 2011-03-13 00:00:00 GMT (ballot already open) >>> Close: 2011-03-16 23:59:00 GMT >> >> Please ?the cancel this vote, and start it up again in a few days. >> There are multiple things wrong with the way you proceeded with this. > > By saying "wrong", you imply that the way I proceeded with the vote, > deviated from a standard procedure. ?It would be helpful if you > provided a reference to what that procedure is, so that we can review > whether the points you have raised are valid, or not. There are multiple things I could say here, but I'll keep it short: first and formost.. as I already said... it deviated from the proceedure that **you** said you would follow! That is, putting up the ballot for review, before the actual vote process starts. From maciej at opencsw.org Thu Mar 17 17:44:15 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 17 Mar 2011 16:44:15 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH] opencsw-policy: Copyright notice In-Reply-To: References: <4D6D0A3C.9010500@opencsw.org> <1300017975-19993-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/17 Philip Brown : > 2011/3/17 Maciej Blizi?ski : >> 2011/3/13 Philip Brown : >>> 2011/3/13 Maciej Blizi?ski : >>>> >>>> The vote will: >>>> Open: 2011-03-13 00:00:00 GMT (ballot already open) >>>> Close: 2011-03-16 23:59:00 GMT >>> >>> Please ?the cancel this vote, and start it up again in a few days. >>> There are multiple things wrong with the way you proceeded with this. >> >> By saying "wrong", you imply that the way I proceeded with the vote, >> deviated from a standard procedure. ?It would be helpful if you >> provided a reference to what that procedure is, so that we can review >> whether the points you have raised are valid, or not. > > There are multiple things I could say here, but I'll keep it short: > first and formost.. as I already said... ?it deviated from the proceedure that > **you** said you would follow! That is, putting up the ballot for > review, before the actual vote process starts. I understand that point, I was asking about other points. Maciej From phil at bolthole.com Thu Mar 17 17:53:51 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Mar 2011 09:53:51 -0700 Subject: [csw-maintainers] Proposed standard for voting Message-ID: I would like to propose the following standard for all future vote write-ups: - All ballots/voting instructions should have the high level purpose of the vote stated. (briefly. one or two sentences are all that is required) This gives the voters a better idea of why the issue is even important enough to vote, and also hopefully the full impact of the vote, along with any alternative options. Otherwise, there is a danger of voting on technical details, without giving context for why the voter might consider approving or not approving it. This tends to lead to either uninformed voting, or lack of voter participation. Both of which are bad. (imaginary example follows) BAD EXAMPLE: This is a vote on meta tag. [vote option]Add meta tag to website, (meta some-magic-string-here) [vote option]Dont add meta tag GOOD EXAMPLE: This vote is to determine whether we want to enable google's (whiz-bang-super feature). This requires adding a custom meta tag. (optional details about why feature is good here) [vote option]Add meta tag, enabling super feature [vote option]Do not add tag From phil at bolthole.com Thu Mar 17 23:11:19 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Mar 2011 15:11:19 -0700 Subject: [csw-maintainers] [csw-devel] [PATCH] opencsw-policy: Copyright notice In-Reply-To: References: <4D6D0A3C.9010500@opencsw.org> <1300017975-19993-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/3/17 Maciej Blizi?ski : > 2011/3/17 Philip Brown : > >> There are multiple things I could say here, but I'll keep it short: >> first and formost.. as I already said... ?it deviated from the proceedure that >> **you** said you would follow! That is, putting up the ballot for >> review, before the actual vote process starts. > > I understand that point, I was asking about other points. You requested above, a reference to "[a standard procedure]" of voting. I did not previously do any comparisons; what I wrote was my opinion of what fair voting practices should be like. but since you asked for a comparison, I just took a look at our favourite point of comparison. And found things like http://www.debian.org/devel/constitution#item-A A. Standard Resolution Procedure .... That goes into even more hairy detail and parliamentary style procedure than I was suggesting. But, there, you have a reference to "a standard". (fyi, voting specifics, are also spread out a bit among other bits, such as section 4.2) I will also note that their *minimum* discussion time for a proposal, is *2* weeks. And that time, is counted from when a specific, "formal proposal" is raised. Not from the time an idea is first brought up as a discussion point. Additionally, the specific proposal, is frozen in wording. THEN it is discussed. and the voting is done on the specifically discussed and frozen proposal, not (whatever the secretary feels like wording it as, at time of the ballot) PS; they also have a requirement of a proposal summary as well. Details on that and other fussy details, can be found at http://www.debian.org/vote/howto_proposal Although oddly, they limit the summary to 60 chars From dam at opencsw.org Fri Mar 18 11:46:49 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Mar 2011 11:46:49 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[13852] csw/mgar/pkg/ruby-augeas/trunk/Makefile In-Reply-To: References: Message-ID: <90A9F70B-2918-49A1-9A59-BC1CD34D3C2F@opencsw.org> Hi, Am 17.03.2011 um 18:56 schrieb phipsy at users.sourceforge.net: > Revision: 13852 > http://gar.svn.sourceforge.net/gar/?rev=13852&view=rev > Author: phipsy > Date: 2011-03-17 17:56:16 +0000 (Thu, 17 Mar 2011) > > Log Message: > ----------- > ruby_augeas: works > > Modified Paths: > -------------- > csw/mgar/pkg/ruby-augeas/trunk/Makefile > > Modified: csw/mgar/pkg/ruby-augeas/trunk/Makefile > =================================================================== > --- csw/mgar/pkg/ruby-augeas/trunk/Makefile 2011-03-17 15:52:20 UTC (rev 13851) > +++ csw/mgar/pkg/ruby-augeas/trunk/Makefile 2011-03-17 17:56:16 UTC (rev 13852) > @@ -13,8 +13,6 @@ > PACKAGES = CSWrubyaugeas > CATALOGNAME = ruby_augeas > > -PATCHFILES = 0001-Does-this-fix-the-building-issues.patch > - > RUNTIME_DEP_PKGS_CSWrubyaugeas += CSWaugeas > RUNTIME_DEP_PKGS_CSWrubyaugeas += CSWruby > CHECKPKG_OVERRIDES_CSWrubyaugeas += catalogname-does-not-match-pkgname|pkgname=CSWrubyaugeas|catalogname=ruby_augeas|expected-catalogname=rubyaugeas Please note that this does not conform to naming standards, which would be CSWrb-augeas and rb_augeas Best regards -- Dago > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > _______________________________________________ > devel mailing list > devel at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/devel From phil at bolthole.com Fri Mar 18 22:19:34 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Mar 2011 14:19:34 -0700 Subject: [csw-maintainers] request for comments, on ruby multi-version support Message-ID: I'm hereby soliciting comments from other maintainers, reguarding a new layout in the ruby package. Currently, we have regular old /opt/csw/bin/ruby, as part of CSWruby The latest submitted package, has /opt/csw/bin/ruby (amoung other things) configured as an "alternative", pointing by default to /opt/csw/bin/ruby18 Presumably, this is to allow future use of a ruby19 package side by side, and to allow site admins to pick the default. However.. what if both are installed, and someone wants to autoconfigure something that uses the older ruby? (such as facter, which, last time I checked, does not work with ruby19) Programs presumably autodetect for a "ruby" executable, rather than "ruby18". There are also the ruby related executables of irb erb rdoc ri testrb Seems like, rather than having to hand-edit a bunch of files to call frontend18 instead of frontend, they would rather just set their PATH to something and use it naturally. In other words, in cases like this, seems like our users will be best served putting the version specific stuff somewhere like /opt/csw/libexec/ruby18/ruby and so enabling users to do PATH=/opt/csw/libexec/ruby18:$PATH when they want to override more modern defaults for ruby. (and then 'alternatives' can still be used, but just pointing to the target under libexec) Comments? From bwalton at opencsw.org Sat Mar 19 01:23:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Mar 2011 20:23:24 -0400 Subject: [csw-maintainers] request for comments, on ruby multi-version support In-Reply-To: References: Message-ID: <1300493781-sup-6518@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Mar 18 17:19:34 -0400 2011: > However.. what if both are installed, and someone wants to > autoconfigure something that uses the older ruby? (such as facter, > which, last time I checked, does not work with ruby19) Easy. The ruby18 package will retain higher priority until such time as we decide to make 1.9 (or hopefully 2.x) the default. This is in line with other distributions: $ ls -l /usr/bin/ruby* lrwxrwxrwx 1 root root 7 2010-11-30 20:34 /usr/bin/ruby -> ruby1.8 -rwxr-xr-x 1 root root 6200 2010-07-31 10:42 /usr/bin/ruby1.8 -rwxr-xr-x 1 root root 6224 2010-09-13 15:15 /usr/bin/ruby1.9.1 This can be announced well ahead of time giving people ample opportunity to fix hash-bangs if they want to force a specific version. I don't expect a flip in the default for a year or two yet. But there is a lot of demand for 1.9 as it offers many nice new language features, a faster execution engine, etc. > /opt/csw/libexec/ruby18/ruby > and so enabling users to do > PATH=/opt/csw/libexec/ruby18:$PATH _If_ we were switching the default preferred version of ruby in the way you described, this might be worthwhile. As we're not doing that and users of 1.9 will simply hash-bang their new scripts bin/ruby19, this isn't really an issue. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Mar 19 02:05:06 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Mar 2011 18:05:06 -0700 Subject: [csw-maintainers] request for comments, on ruby multi-version support In-Reply-To: <1300493781-sup-6518@pinkfloyd.chass.utoronto.ca> References: <1300493781-sup-6518@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Mar 18, 2011 at 5:23 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Mar 18 17:19:34 -0400 2011: >...gine, etc. > >> /opt/csw/libexec/ruby18/ruby >> and so enabling users to do >> ? ? ?PATH=/opt/csw/libexec/ruby18:$PATH > > _If_ we were switching the default preferred version of ruby in the > way you described, this might be worthwhile. ?As we're not doing that > and users of 1.9 will simply hash-bang their new scripts bin/ruby19, > this isn't really an issue. You presume that users of ruby1.9, will only be writing new code, so that its no big deal for them to set the first line explicitly. But what if they are downloading and working with other peoples' code, rather than writing their own? OR, if they want to easily test if their code works with both versions? So my comments are equally applicable, reguardless of which one is the default. It may be that a particular site stays on default ruby=v1.8, but a subset of the site's users primarily want to test out ruby1.9 heavily It seems nicer to users, to put the collected (rubyX) executables in /opt/csw/libexec/rubyX. This allows them to adjust their path one time, rather than force them to edit every script they want to work with. (reminder: both "#!ruby" and "#!/bin/env ruby" work, for executable ruby scripts. A full path is not required.) Now how about seeing what other maintainers think about this? From bwalton at opencsw.org Sat Mar 19 02:38:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Mar 2011 21:38:29 -0400 Subject: [csw-maintainers] Major adjustment of GAR defaults In-Reply-To: References: <7CF99F7B-2176-4BBF-86ED-E61D6EE051FF@opencsw.org> Message-ID: <1300498682-sup-5212@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Thu Mar 17 07:56:44 -0400 2011: > as broken builds. Changes also need to be communicated. I would > suggest creating a branch of GAR, introducing the change in there, > letting a few brave test them. Testing instructions would be useful: > "To test the new GAR branch, run these commands: ...". I'll work on the test branch if it's created. I think it's a good idea. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 19 04:06:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Mar 2011 23:06:29 -0400 Subject: [csw-maintainers] request for comments, on ruby multi-version support In-Reply-To: References: <1300493781-sup-6518@pinkfloyd.chass.utoronto.ca> Message-ID: <1300503954-sup-8536@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Mar 18 21:05:06 -0400 2011: > Now how about seeing what other maintainers think about this? Sure. In the meantime, please push the current package set. If this needs to change, it can be done in a subsequent update. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 19 17:45:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Mar 2011 12:45:58 -0400 Subject: [csw-maintainers] gnulinks on bender Message-ID: <1300553124-sup-4367@pinkfloyd.chass.utoronto.ca> Can someone please kill the gnulinks in /home/newpkgs on bender? I'm submitting an updated version with the ggettext* update. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sat Mar 19 20:36:34 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Mar 2011 20:36:34 +0100 Subject: [csw-maintainers] gnulinks on bender In-Reply-To: <1300553124-sup-4367@pinkfloyd.chass.utoronto.ca> References: <1300553124-sup-4367@pinkfloyd.chass.utoronto.ca> Message-ID: <5655580D-5523-4DE4-8C92-1381E6C21872@opencsw.org> Hi Ben, Am 19.03.2011 um 17:45 schrieb Ben Walton: > Can someone please kill the gnulinks in /home/newpkgs on bender? I'm > submitting an updated version with the ggettext* update. AFAIK only the initial submitter (Gordon) and Phil can do this. Best regards -- Dago From bwalton at opencsw.org Sun Mar 20 02:44:08 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Mar 2011 21:44:08 -0400 Subject: [csw-maintainers] alternate mail for william? Message-ID: <1300585406-sup-8560@pinkfloyd.chass.utoronto.ca> Hi All, It seems that mail to William is bouncing via his personal domain address. Does anyone have an alternate? (@opencsw is aliased to his personal domain account.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sun Mar 20 23:16:02 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 20 Mar 2011 23:16:02 +0100 Subject: [csw-maintainers] Fwd: [csw-users] SunFreeware vs. Blastwave In-Reply-To: <60860.10.0.66.17.1300658919.squirrel@interact.purplecow.org> References: <60860.10.0.66.17.1300658919.squirrel@interact.purplecow.org> Message-ID: Why do we allow blastwave addresses to sign up? It isn't the first time Dennis has popped up from lurking the list. /peter ---------- Forwarded message ---------- From: Dennis Clarke Date: Sun, Mar 20, 2011 at 11:08 PM Subject: Re: [csw-users] SunFreeware vs. Blastwave To: Questions and discussions > FYI to Larry Siden: > I'm not sure where you got the idea that blastwave supports signed > packages whereas opencsw does not. > (or perhaps, you were only commenting on blastwave vs sunfreeware? At > any rate...) > As far as I know, blastwave still uses the same signing mechanisms > that I wrote, before the OpenCSW split-off. > > So, both blastwave and opencsw still use gpg for package integrity in > the same way I think. Everything written by you was thrown away the next day after you stole away in the middle of the night with *everything* you could copy, carry or steal, that includes the Blastwave GPG key. ?Everything was re-written from scratch after that and no one here will touch anything that bears your name. Ever. -- Dennis Clarke dclarke at opensolaris.ca ?<- Email related to the open source Solaris dclarke at blastwave.org ? <- Email related to open source for Solaris _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users From phil at bolthole.com Sun Mar 20 23:32:36 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 20 Mar 2011 15:32:36 -0700 Subject: [csw-maintainers] Fwd: [csw-users] SunFreeware vs. Blastwave In-Reply-To: References: <60860.10.0.66.17.1300658919.squirrel@interact.purplecow.org> Message-ID: On Sun, Mar 20, 2011 at 3:16 PM, Peter Bonivart wrote: > Why do we allow blastwave addresses to sign up? It isn't the first > time Dennis has popped up from lurking the list. wouldnt really solve anything to ban them, would it? If he's going to sign up, he's going to sign up, whether from a "blastwave" address, or elsewhere. May as well make it obvious it's him when he's speaking. From dam at opencsw.org Mon Mar 21 14:31:03 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Mar 2011 14:31:03 +0100 Subject: [csw-maintainers] Fwd: Major adjustment of GAR defaults References: Message-ID: Hi, I have made a test branch "v2-defaultchange" with the described changes and some minor adjustments. Am 15.03.2011 um 10:39 schrieb Dagobert Michelsen: > Fellow maintainers, > > as it was observed during the talk in Dublin some defaults in GAR are > not really sane and it would be good to adjust them. The following > variables are candidates for adjustment: > > * MERGE_SCRIPTS_isa-extra = copy-relocated-only copy-config-only > > This is copy-relocated-only at the moment. The present setting just > copies > $(bindir)/*-config > but not the 64 bit equivalent > $(bindir)/(sparcv9|amd64)/*-config > This change should be transparent to all packages only fixing > issues about missing *-config for 64 bit. > > * MERGE_DIRS_isa-extra = $(libdir) > > This is now > $(bindir) $(libdir) $(sbindir) $(libexecdir) > However, it was felt that most of the time only the libraries need to > be provided for 64 bit and the binaries hence should be excluded for > automatic inclusion. > Adding the old default to build recipes may or may not be good because > there are several other ways to exclude files and it would be > confusing to add them explcitily and later on remove them again. I have enhanced this that the new setting with just libdir is the default if NO isaexec is used, otherwise the existing default with $(bindir) etc. is kept. > * CONFIGURE_ARGS = $(DIRPATHS) > > This defaults to empty ATM. The number of packages using configure with > no arguments should be really small as this would be a non-standard > build. In addition to this there is now EXTRA_CONFIGURE_ARGS for additions. > * TEST_TARGET = check > > The previous target was "test". This can be detected and reset > for Makefiles requiring the old target. > > * NOISAEXEC = 1 -> ISAEXEC ?= 0 > > The current default is to use ISAEXEC when more then one ISA is built. > Again as most of the time libraries are used for multiple ISAs the > defaulting of ISAEXEC is usually considered wrong and should be > enabled together with $(bindir) MERGE_DIRS only when a benefit has > been proven. > The current name is "NOISAEXEC", changing the default to "1" would > require setting "NOISAEXEC = 0" which looks not straight forward. > I tend to invert it to default to "ISAEXEC ?= 0" and allow setting > of "ISAEXEC = 1" in the Makefile. This can be detected and reset > for Makefile using it. > > * sysconfdir = /etc/opt/csw > * localstatedir = /var/opt/csw > > These have been changed some time ago and should be the default > now. Only very specific packages should stick to /opt/csw/etc > as default and /opt/csw/var should not be used at all. > As the new default should apply to a lot of packages I would > rather not update this automatically. > > I plan to do the update in one large swoop. About the warning printed on major changes: I could print a warning once (by using a cookie) if the commit of the Makefile is older then the major GAR change and print a note about each change to be reviewed. Best regards -- Dago From maciej at opencsw.org Mon Mar 21 15:44:31 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 21 Mar 2011 14:44:31 +0000 Subject: [csw-maintainers] Fwd: Major adjustment of GAR defaults In-Reply-To: References: Message-ID: 2011/3/21 Dagobert Michelsen : > About the warning printed on major changes: I could print a warning once > (by using a cookie) if the commit of the Makefile is older then the > major GAR change and print a note about each change to be reviewed. This sounds good, one thing to keep in mind: to have a failback if svn is not available: some people work with the sources using git-svn, which causes commands such as "svn info" fail. Maciej From bwalton at opencsw.org Mon Mar 21 17:20:54 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Mar 2011 12:20:54 -0400 Subject: [csw-maintainers] libxml2 update in experimental Message-ID: <1300724401-sup-6743@pinkfloyd.chass.utoronto.ca> Hi All, I've done a version bump and naming cleanup on libxml2. It's available for http://buildfarm.opencsw.org/experimental.html#libxml2 Feedback welcomed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Mar 21 19:34:20 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Mar 2011 11:34:20 -0700 Subject: [csw-maintainers] gnulinks on bender In-Reply-To: <5655580D-5523-4DE4-8C92-1381E6C21872@opencsw.org> References: <1300553124-sup-4367@pinkfloyd.chass.utoronto.ca> <5655580D-5523-4DE4-8C92-1381E6C21872@opencsw.org> Message-ID: On Sat, Mar 19, 2011 at 12:36 PM, Dagobert Michelsen wrote: > Hi Ben, > > Am 19.03.2011 um 17:45 schrieb Ben Walton: >> Can someone please kill the gnulinks in /home/newpkgs on bender? ?I'm >> submitting an updated version with the ggettext* update. > > AFAIK only the initial submitter (Gordon) and Phil can do this. > fyi I removed it From bwalton at opencsw.org Mon Mar 21 19:52:47 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Mar 2011 14:52:47 -0400 Subject: [csw-maintainers] gnulinks on bender In-Reply-To: References: <1300553124-sup-4367@pinkfloyd.chass.utoronto.ca> <5655580D-5523-4DE4-8C92-1381E6C21872@opencsw.org> Message-ID: <1300733546-sup-8920@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Mar 21 14:34:20 -0400 2011: > fyi I removed it Perfect. Thanks. Incoming... -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Mon Mar 21 23:03:41 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Mon, 21 Mar 2011 15:03:41 -0700 Subject: [csw-maintainers] auto-switching thing In-Reply-To: References: Message-ID: Hi Phil, The short answer is that I already deal with enough "smart" compilation tools and I'm afraid that I will be finding corner case after corner case in this one. The mechanism needs to be as dumb as possible. There is a commercial software package for seismic data acquisition and processing that I support at my site, called Antelope [1]. This package lives in it's own little tree under /opt/antelope, largely independent of system software. The major exception to the self-contained nature of Antelope is the contributed code library[2], which has dependencies on a lot of open source projects - things like ImageMagick, RRDTool, Python, etc. My site makes heavy use of "antelope_contrib" because almost all of my users are Power Users and many are authors of items in antelope_contrib. Maintaining the products generated by compiling the antelope_contrib tree unfortunately is where most of my time seems to go because of the third-party and open source dependencies. There are a number of eccentricities with the build process for the antelope_contrib code, and the end result is that I have to battle with several "smart" tools that set and tweak various environment variables. I had a bit of a masochistic laugh when I read your response [3] to me on maintainers that used a command called "compile" to perform the auto-switch - that is EXACTLY the name of the goofy macro/wrapper that this commercial package uses to abstract between SPRO and GCC on Solaris. I think the AntelopeMake Makefile actually sets "CC" to "compile" during the build phase. I'd really prefer to set and forget using the alternatives mechanism, rather than have a tool try to guess my intentions through three or more layers of abstraction. Using something like the alternatives mechanism, I can force my build process to look at the "right" auto-configure tool for a package like Python or Ruby or RRDtool. [1] http://brtt.com [2] http://github.com/antelopeusersgroup/antelope_contrib [3] http://lists.opencsw.org/pipermail/maintainers/2011-March/014365.html On Mar 21, 2011, at 1:36 PM, Philip Brown wrote: > Hello there, > I'm keeping an eye on the polling thing :) and I'm curious, why you chose > "site wide, fixed configuration" > rather than having the tool auto-switch based on value of CC? > > I'm having difficulty understanding why, in cases where the tool can > easily suport both, and it will default to (something reasonable) if > CC is not set... why you would not prefer it to be auto-switching? From william at wbonnet.net Tue Mar 22 15:42:58 2011 From: william at wbonnet.net (William Bonnet) Date: Tue, 22 Mar 2011 15:42:58 +0100 Subject: [csw-maintainers] Test Message-ID: <4D88B572.6040000@wbonnet.net> Hi Sorry for the noise, it seems some emails are bouncing. Just a test... cheers W. From phil at bolthole.com Tue Mar 22 19:21:25 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Mar 2011 11:21:25 -0700 Subject: [csw-maintainers] *automated* firefox4 wrapper: RFC Message-ID: Hi folks, I just put together a wrapper that automatically downloads the "contrib" firefox4 package from mozilla, and then extracts it and configures it to use CSW libraries, instead of the ones side-bundled with the package. http://buildfarm.opencsw.org/experimental/phil/firefox4_installer Please give me some feedback on it. So far, "it works for me". Tested on a new box that had nothing but pkg-get on it. (it pulls in required CSW packages, if missing) If it looks good to others, I'll announce it on the users list. I'm kindasorta tempted to make a package for it... but I dunno. (Hmm. I suppose I might even go further and have it bootstrap, even if there is no /opt/csw whatsoever. Whaddya think?) From phil at bolthole.com Tue Mar 22 19:34:39 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Mar 2011 11:34:39 -0700 Subject: [csw-maintainers] *automated* firefox4 wrapper: RFC In-Reply-To: References: Message-ID: PS: While it whines about "old drivers, blah blah, no WebGL"... a demo supposedly marked as needing WebGL works on my sparc station, does actual work. It also works on my x86 box, with no whine. (both have nvidia 3d cards) https://mozillademos.org/demos/planetarium/demo.html From bwalton at opencsw.org Wed Mar 23 01:28:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Mar 2011 20:28:28 -0400 Subject: [csw-maintainers] apache2 update available for tire kicking Message-ID: <1300840010-sup-956@pinkfloyd.chass.utoronto.ca> Hi All, The apache2 update is both a version bump and a dependency alteration to make it pkg-get upgrade compatible. If you have a chance, please give it a try. http://buildfarm.opencsw.org/experimental.html#apache2-new I scaled back all attempts to move it out of /opt/csw/apache2/{var,etc} for this as I wanted to focus on the pkg-get problem first. I also have some renames to take care of but I'm leaving all but -dev for now. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Wed Mar 23 11:12:55 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Wed, 23 Mar 2011 11:12:55 +0100 Subject: [csw-maintainers] Fwd: [csw-users] SunFreeware vs. Blastwave In-Reply-To: References: <60860.10.0.66.17.1300658919.squirrel@interact.purplecow.org> Message-ID: <4D89C7A7.5090600@opencsw.org> On 03/20/11 11:16 PM, Peter Bonivart wrote: > Why do we allow blastwave addresses to sign up? It isn't the first > time Dennis has popped up from lurking the list. When we moved from Blastwave to OpenCSW, I just renamed the list. Back then, Dennis did not unsubscribe from the users list. Besides that, I think the list should be open fro everyone. Blocking or unsubscribing Dennis would not help to solve anything. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Wed Mar 23 13:52:27 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Mar 2011 08:52:27 -0400 Subject: [csw-maintainers] Fwd: [csw-users] SunFreeware vs. Blastwave In-Reply-To: <4D89C7A7.5090600@opencsw.org> References: <60860.10.0.66.17.1300658919.squirrel@interact.purplecow.org> <4D89C7A7.5090600@opencsw.org> Message-ID: <1300884726-sup-3913@pinkfloyd.chass.utoronto.ca> Excerpts from ?hsan Do?an's message of Wed Mar 23 06:12:55 -0400 2011: > Besides that, I think the list should be open fro everyone. Blocking > or unsubscribing Dennis would not help to solve anything. Agreed. If he wants to be childish, just ignore him. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Mar 23 14:02:38 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Mar 2011 09:02:38 -0400 Subject: [csw-maintainers] gnulib use Message-ID: <1300885285-sup-7192@pinkfloyd.chass.utoronto.ca> Hi All, If you know of any packages that are using gnulib, the gnulib project is looking to record this. You can either send the name to me and I'll proxy it for you or you can send a patch to them directly. The git checkout contains a file called users.txt which is where the change would go. I'm going to submit tmpwatch and cvsps. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Wed Mar 23 23:47:37 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 23 Mar 2011 23:47:37 +0100 Subject: [csw-maintainers] apache2 update available for tire kicking In-Reply-To: <1300840010-sup-956@pinkfloyd.chass.utoronto.ca> References: <1300840010-sup-956@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Mar 23, 2011 at 1:28 AM, Ben Walton wrote: > The apache2 update is both a version bump and a dependency alteration > to make it pkg-get upgrade compatible. ?If you have a chance, please > give it a try. I've tried it on a couple of servers, the upgrade (with pkgutil) worked and it seems to work just like before. It's only lightly used on those servers though. /peter From bwalton at opencsw.org Thu Mar 24 00:43:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Mar 2011 19:43:51 -0400 Subject: [csw-maintainers] apache2 update available for tire kicking In-Reply-To: References: <1300840010-sup-956@pinkfloyd.chass.utoronto.ca> Message-ID: <1300923798-sup-1469@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Mar 23 18:47:37 -0400 2011: Hi Peter, > I've tried it on a couple of servers, the upgrade (with pkgutil) > worked and it seems to work just like before. It's only lightly used > on those servers though. Thanks for testing. My own updates (also pkgutil) went fine too. I'll toss this for release shortly. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Mar 24 01:01:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Mar 2011 20:01:12 -0400 Subject: [csw-maintainers] _stub suffix for obsoleted packages Message-ID: <1300924769-sup-8785@pinkfloyd.chass.utoronto.ca> If nobody objects, I'm going to make _stub the default for obsoleted packages. It's a one line change to GAR. I thought it would require an extra checkpkg override, but that's already in place. I'd say we should go with _obs or something, but a bunch of things went out with _stub already and since it really doesn't matter all that much, we might as well use this since it serves the purpose. I'll commit tomorrow morning unless I see objections. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Mar 24 11:04:40 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 24 Mar 2011 10:04:40 +0000 Subject: [csw-maintainers] _stub suffix for obsoleted packages In-Reply-To: <1300924769-sup-8785@pinkfloyd.chass.utoronto.ca> References: <1300924769-sup-8785@pinkfloyd.chass.utoronto.ca> Message-ID: Looks good to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Thu Mar 24 21:21:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Mar 2011 16:21:05 -0400 Subject: [csw-maintainers] paypal account? Message-ID: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> Hi All, A user in IRC the other night came 'storming' in wondering where our donate link was. He indicated that we'd saved him a pile of time and he would have tossed some money at the project. This has been discussed briefly before, but maybe we should actually address it... I don't personally like PayPal, but it's widely used for this type of thing. Does anyone see a problem with registering an OpenCSW paypal account, with the credentials to be held by the board (treasurer). Use of any funds would require further discussion. (I'm wide open to PayPal alternates as long as their use wouldn't deter people from donating should they look to do so.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Mar 24 22:26:52 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Mar 2011 14:26:52 -0700 Subject: [csw-maintainers] paypal account? In-Reply-To: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> Message-ID: actually wr already have one. you should have asked the treasurer :) On Thursday, March 24, 2011, Ben Walton wrote: > > Hi All, > > A user in IRC the other night came 'storming' in wondering where our > donate link was. ?He indicated that we'd saved him a pile of time and > he would have tossed some money at the project. > > This has been discussed briefly before, but maybe we should actually > address it... > > I don't personally like PayPal, but it's widely used for this type of > thing. ?Does anyone see a problem with registering an OpenCSW paypal > account, with the credentials to be held by the board (treasurer). > Use of any funds would require further discussion. > From bwalton at opencsw.org Thu Mar 24 22:35:32 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Mar 2011 17:35:32 -0400 Subject: [csw-maintainers] paypal account? In-Reply-To: References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> Message-ID: <91b370d2-8dfe-4f61-81c7-e4bdc0e7b7f4@email.android.com> Cool...does anyone object to a donate link on the home page then? Nothing huge, just a subtle button somewhere on the side menu? Thanks -Ben Philip Brown wrote: actually wr already have one. you should have asked the treasurer :) On Thursday, March 24, 2011, Ben Walton wrote: > > Hi All, > > A user in IRC the other night came 'storming' in wondering where our > donate link was. He indicated that we'd saved him a pile of time and > he would have tossed some money at the project. > > This has been discussed briefly before, but maybe we should actually > address it... > > I don't personally like PayPal, but it's widely used for this type of > thing. Does anyone see a problem with registering an OpenCSW paypal > account, with the credentials to be held by the board (treasurer). > Use of any funds would require further discussion. >_____________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Thu Mar 24 23:12:53 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Mar 2011 15:12:53 -0700 Subject: [csw-maintainers] paypal account? In-Reply-To: <91b370d2-8dfe-4f61-81c7-e4bdc0e7b7f4@email.android.com> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <91b370d2-8dfe-4f61-81c7-e4bdc0e7b7f4@email.android.com> Message-ID: On Thu, Mar 24, 2011 at 2:35 PM, Ben Walton wrote: > Cool...does anyone object to a donate link on the home page then? Nothing > huge, just a subtle button somewhere on the side menu? > I'm guessing that almost no-one will object to a link in and of itself, but the wording of the "donate" page will probably be more of an object of interest. From bwalton at opencsw.org Fri Mar 25 00:05:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Mar 2011 19:05:07 -0400 Subject: [csw-maintainers] http in /etc/services? Message-ID: <1301007747-sup-7015@pinkfloyd.chass.utoronto.ca> Hi All, I found a test failure tonight that is triggered because http isn't registered in /etc/services. I can ignore this failure, but I'm curious if anyone know why it isn't listed. Is there possibly a neat historical artifact/story hiding here? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Fri Mar 25 10:17:13 2011 From: james at opencsw.org (James Lee) Date: Fri, 25 Mar 2011 09:17:13 GMT Subject: [csw-maintainers] paypal account? In-Reply-To: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> Message-ID: <20110325.9171300.1489557564@gyor.oxdrove.co.uk> On 24/03/11, 20:21:05, Ben Walton wrote regarding [csw-maintainers] paypal account?: > A user in IRC the other night came 'storming' in wondering where our > donate link was. He indicated that we'd saved him a pile of time and > he would have tossed some money at the project. The bigger question than should you ask for money is how to you propose to distribute it? James. From dam at opencsw.org Fri Mar 25 10:21:57 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Mar 2011 10:21:57 +0100 Subject: [csw-maintainers] paypal account? In-Reply-To: <20110325.9171300.1489557564@gyor.oxdrove.co.uk> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <20110325.9171300.1489557564@gyor.oxdrove.co.uk> Message-ID: <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> Hi, Am 25.03.2011 um 10:17 schrieb James Lee: > On 24/03/11, 20:21:05, Ben Walton wrote regarding > [csw-maintainers] paypal account?: > >> A user in IRC the other night came 'storming' in wondering where our >> donate link was. He indicated that we'd saved him a pile of time and >> he would have tossed some money at the project. > > The bigger question than should you ask for money is how to you > propose to distribute it? I suggest spending it for operational things like - the domain registration - ssl certificates Best regards -- Dago From james at opencsw.org Fri Mar 25 10:39:26 2011 From: james at opencsw.org (James Lee) Date: Fri, 25 Mar 2011 09:39:26 GMT Subject: [csw-maintainers] paypal account? In-Reply-To: <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <20110325.9171300.1489557564@gyor.oxdrove.co.uk> <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> Message-ID: <20110325.9392600.1823886698@gyor.oxdrove.co.uk> On 25/03/11, 09:21:57, Dagobert Michelsen wrote regarding Re: [csw-maintainers] paypal account?: > >> donate link was. He indicated that we'd saved him a pile of time and > >> he would have tossed some money at the project. > > > > The bigger question than should you ask for money is how to you > > propose to distribute it? > I suggest spending it for operational things like > - the domain registration > - ssl certificates Worthy claims. I'm only asking... don't think I'm saying there are none but do recall the problems when similar questions arose before. A side note, I don't think I've ever seen an OCSW balance sheet published, that could be because I'm looking in the wrong place or search fails and if so please simply give me the link to a document on the web site. James. From dam at opencsw.org Fri Mar 25 10:41:48 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Mar 2011 10:41:48 +0100 Subject: [csw-maintainers] paypal account? In-Reply-To: <20110325.9392600.1823886698@gyor.oxdrove.co.uk> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <20110325.9171300.1489557564@gyor.oxdrove.co.uk> <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> <20110325.9392600.1823886698@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 25.03.2011 um 10:39 schrieb James Lee: > On 25/03/11, 09:21:57, Dagobert Michelsen wrote regarding > Re: [csw-maintainers] paypal account?: > >>>> donate link was. He indicated that we'd saved him a pile of time and >>>> he would have tossed some money at the project. >>> >>> The bigger question than should you ask for money is how to you >>> propose to distribute it? > >> I suggest spending it for operational things like >> - the domain registration >> - ssl certificates > > Worthy claims. I'm only asking... don't think I'm saying there are none > but do recall the problems when similar questions arose before. > > A side note, I don't think I've ever seen an OCSW balance sheet > published, that could be because I'm looking in the wrong place or search > fails and if so please simply give me the link to a document on the web > site. There was when the previous board gave the yearl (*cough*) report. IIRC it was a sentence of the form "There were no incomes and expenses besides the donation of the domain by Dago and the certs by Ihsan" :-) Best regards -- Dago From dam at opencsw.org Fri Mar 25 10:57:21 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Mar 2011 10:57:21 +0100 Subject: [csw-maintainers] paypal account? In-Reply-To: References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <20110325.9171300.1489557564@gyor.oxdrove.co.uk> <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> <20110325.9392600.1823886698@gyor.oxdrove.co.uk> Message-ID: <533624D8-0C7B-45B3-A318-5AC81C61CDBC@opencsw.org> hi James, Am 25.03.2011 um 10:41 schrieb Dagobert Michelsen: > Am 25.03.2011 um 10:39 schrieb James Lee: >> On 25/03/11, 09:21:57, Dagobert Michelsen wrote regarding >> Re: [csw-maintainers] paypal account?: >> >>>>> donate link was. He indicated that we'd saved him a pile of time and >>>>> he would have tossed some money at the project. >>>> >>>> The bigger question than should you ask for money is how to you >>>> propose to distribute it? >> >>> I suggest spending it for operational things like >>> - the domain registration >>> - ssl certificates >> >> Worthy claims. I'm only asking... don't think I'm saying there are none >> but do recall the problems when similar questions arose before. >> >> A side note, I don't think I've ever seen an OCSW balance sheet >> published, that could be because I'm looking in the wrong place or search >> fails and if so please simply give me the link to a document on the web >> site. > > There was when the previous board gave the yearl (*cough*) report. IIRC it was > a sentence of the form "There were no incomes and expenses besides > the donation of the domain by Dago and the certs by Ihsan" :-) It is in the Wave as referenced from http://wiki.opencsw.org/annual-meeting under "Budget". Best regards -- Dago From james at opencsw.org Fri Mar 25 11:14:09 2011 From: james at opencsw.org (James Lee) Date: Fri, 25 Mar 2011 10:14:09 GMT Subject: [csw-maintainers] paypal account? In-Reply-To: <533624D8-0C7B-45B3-A318-5AC81C61CDBC@opencsw.org> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <20110325.9171300.1489557564@gyor.oxdrove.co.uk> <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> <20110325.9392600.1823886698@gyor.oxdrove.co.uk> <533624D8-0C7B-45B3-A318-5AC81C61CDBC@opencsw.org> Message-ID: <20110325.10140900.2246494707@gyor.oxdrove.co.uk> On 25/03/11, 09:57:21, Dagobert Michelsen wrote regarding Re: [csw-maintainers] paypal account?: > It is in the Wave as referenced from > http://wiki.opencsw.org/annual-meeting > under "Budget". I don't consider "google wave" as being published meeting minutes but let's not get too worked up about lack of transparent processes. James. From bwalton at opencsw.org Fri Mar 25 14:42:49 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Mar 2011 09:42:49 -0400 Subject: [csw-maintainers] paypal account? In-Reply-To: References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <91b370d2-8dfe-4f61-81c7-e4bdc0e7b7f4@email.android.com> Message-ID: <1301060539-sup-3165@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Mar 24 18:12:53 -0400 2011: > I'm guessing that almost no-one will object to a link in and of > itself, but the wording of the "donate" page will probably be more > of an object of interest. Ok, I'll research how other projects do this, including language used, etc, and come back with some ideas. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Mar 25 14:43:33 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Mar 2011 09:43:33 -0400 Subject: [csw-maintainers] paypal account? In-Reply-To: <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <20110325.9171300.1489557564@gyor.oxdrove.co.uk> <9CE452AE-6756-4E11-AD52-CD849A1C0DB1@opencsw.org> Message-ID: <1301060574-sup-2491@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 25 05:21:57 -0400 2011: > I suggest spending it for operational things like > - the domain registration > - ssl certificates Yes, these are the types of costs that should be offset, I think. It's a shared resource, but the investments have been personal. If we can correct that, we should. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Mar 25 16:41:47 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Mar 2011 08:41:47 -0700 Subject: [csw-maintainers] paypal account? In-Reply-To: <1301060539-sup-3165@pinkfloyd.chass.utoronto.ca> References: <1300997838-sup-5031@pinkfloyd.chass.utoronto.ca> <91b370d2-8dfe-4f61-81c7-e4bdc0e7b7f4@email.android.com> <1301060539-sup-3165@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Mar 25, 2011 at 6:42 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Mar 24 18:12:53 -0400 2011: > >> I'm guessing that almost no-one will object to a link in and of >> itself, but the wording of the "donate" page will probably be more >> of an object of interest. > > Ok, I'll research how other projects do this, including language used, > etc, and come back with some ideas. > It would probably be helpful to specifically mention in the page, the "known costs" (domain, ssl), plus history of donations, and also prospective uses. Plus commitment to "transparency". Which is why there should probably be a reference to some kind of *permenant* yearly income&expense history pages. From bonivart at opencsw.org Sun Mar 27 15:40:48 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 27 Mar 2011 15:40:48 +0200 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf Message-ID: We're testing a change submitted by phalenor at IRC (sorry, forgot real name). We've had statekeeping for a while now (contributed by Yann Rouillard) but it's implemented in a way that makes it second to the csw.conf file. That results in state not kept in all cases, the patch changes that so state is most important, meaning that if you upgrade an enabled daemon you will get the updated daemon enabled as well even if autoenable is off in csw.conf. Please help us test it so there's no bugs in this widely used class action script. An updated package can be found here: http://buildfarm.opencsw.org/experimental.html#bonivart Easy update: # pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/bonivart -u cas_initsmf /peter From bwalton at opencsw.org Sun Mar 27 16:11:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 27 Mar 2011 10:11:16 -0400 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: References: Message-ID: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Mar 27 09:40:48 -0400 2011: Hi Peter, > # pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/bonivart > -u cas_initsmf I've updated this on a few boxes and will let you know if I see anything that doesn't seem right. Assume that no news is good news from me. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sun Mar 27 16:14:44 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 27 Mar 2011 16:14:44 +0200 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Mar 27, 2011 at 4:11 PM, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Sun Mar 27 09:40:48 -0400 2011: > > Hi Peter, > >> # pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/bonivart >> -u cas_initsmf > > I've updated this on a few boxes and will let you know if I see > anything that doesn't seem right. ?Assume that no news is good news > from me. Thanks. This is the actual patch if someone wants to just look at it: Index: CSWcswclassutils.i.cswinitsmf =================================================================== --- CSWcswclassutils.i.cswinitsmf (revision 13715) +++ CSWcswclassutils.i.cswinitsmf (working copy) @@ -235,14 +235,16 @@ if [ "`grep '^#AUTOENABLE' $dest`" ]; then AUTOENABLE=`grep '^#AUTOENABLE' $dest | awk '{print $2}' | /usr/xpg4/bin/tr -s '[:upper:]' '[:lower:]'` fi - if [ "$daemon" = "yes" -a "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then - load_smf_service_state "$FMRI/$service" - if [ "$SMF_STATE" = "enabled" ]; then - echo "Clearing svc:/$FMRI/$service in case it's in the maintenance state..." - /usr/sbin/svcadm clear svc:/$FMRI/$service > /dev/null 2>&1 - echo Enabling svc:/$FMRI/$service ... - /usr/sbin/svcadm enable svc:/$FMRI/$service > /dev/null 2>&1 - fi + + load_smf_service_state "$FMRI/$service" + # enable the service if it was enabled before, OR if $daemon = yes and AUTOENABLE is set + # previous SMF state always takes precedence + # note: autoenable_daemons and autoenable_$service controls $daemon, $AUTOENABLE is set by the package itself + if [ "$SMF_STATE" = "enabled" ] || [ "$daemon" = "yes" -a "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then + echo "Clearing svc:/$FMRI/$service in case it's in the maintenance state..." + /usr/sbin/svcadm clear svc:/$FMRI/$service > /dev/null 2>&1 + echo Enabling svc:/$FMRI/$service ... + /usr/sbin/svcadm enable svc:/$FMRI/$service > /dev/null 2>&1 fi else # Copy the service script From maciej at opencsw.org Mon Mar 28 09:17:10 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 28 Mar 2011 08:17:10 +0100 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/3/27 Peter Bonivart : > + ? ?if [ "$SMF_STATE" = "enabled" ] || [ "$daemon" = "yes" -a > "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then This is a weird syntax, a combination of [ ] and -a. I thought you could just use -o: > + ? ?if [ "$SMF_STATE" = "enabled" -o "$daemon" = "yes" -a > "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then From phil at bolthole.com Mon Mar 28 22:18:36 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Mar 2011 13:18:36 -0700 Subject: [csw-maintainers] plan for _stub packages Message-ID: Please read: Wanted to toss this out to other maintainers, before we officially start doing it, in about a day or so. Ben and I have been chatting about our use of _stub packages. So far, we have come to an agreement that the best thing to do as far as registering them, would seem to be, to NOT register them. This means, what will happen will be: When you upload a _stub package for release, the registration process will attempt to look at the "obsolete" file, if present. It will then DEREGISTER from our web databases, both the sub package itself, and any packages referenced by the "obsolete" file. This is in order to free up the filename space, for the presumed new, "proper" package that will most likely contain those files. This is beneficial for us for multiple reasons; one of which being that we will avoid having literally hundreds of "xxx_stub" packages littering up mantis, etc. From bwalton at opencsw.org Mon Mar 28 23:40:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 28 Mar 2011 17:40:15 -0400 Subject: [csw-maintainers] plan for _stub packages In-Reply-To: References: Message-ID: <179bd156-9a74-42d5-abe4-d333715f56f7@email.android.com> This is incorrect...I'll send a better reply from home, but the obsolete file lists the packages that supersede the one being marked obsolete. Only the package marked obsolete should be deregistered. The others remain valid. Thanks -Ben Philip Brown wrote: Please read: Wanted to toss this out to other maintainers, before we officially start doing it, in about a day or so. Ben and I have been chatting about our use of _stub packages. So far, we have come to an agreement that the best thing to do as far as registering them, would seem to be, to NOT register them. This means, what will happen will be: When you upload a _stub package for release, the registration process will attempt to look at the "obsolete" file, if present. It will then DEREGISTER from our web databases, both the sub package itself, and any packages referenced by the "obsolete" file. This is in order to free up the filename space, for the presumed new, "proper" package that will most likely contain those files. This is beneficial for us for multiple reasons; one of which being that we will avoid having literally hundreds of "xxx_stub" packages littering up mantis, etc._____________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Tue Mar 29 02:14:37 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 28 Mar 2011 20:14:37 -0400 Subject: [csw-maintainers] plan for _stub packages In-Reply-To: References: Message-ID: <1301357525-sup-706@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Mar 28 16:18:36 -0400 2011: Hi Phil, > When you upload a _stub package for release, the registration process > will attempt to look at the "obsolete" file, if present. > It will then DEREGISTER from our web databases, both the sub > package itself, and any packages referenced by the "obsolete" file. The 'obsolete' file in the pkgmap of a package indicates that the package carrying it is obsolete. The _content_ of that file denotes which package (or packages) have taken on the functionality formerly provided by the package that is now obsolete. In some cases, this will be one item (eg: pmfoo -> pm_foo). In others, it may be multiple (eg: coolpkgrt -> libcool1, libcoolsupport2, etc). > This is beneficial for us for multiple reasons; one of which being > that we will avoid having literally hundreds of "xxx_stub" packages > littering up mantis, etc. This is a good thing. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Mar 30 00:26:00 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 29 Mar 2011 23:26:00 +0100 Subject: [csw-maintainers] OpenCSW on FLOSS Weekly Message-ID: I just listened to FLOSS Weekly episode 158 (about the 2600hz Project). At the end of the show Randal mentions future guests, and he announces that our project will be featured this quarter. http://twit.tv/floss158 Maciej From dam at opencsw.org Wed Mar 30 14:42:29 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Mar 2011 14:42:29 +0200 Subject: [csw-maintainers] Buildfarm leased line upgrade Message-ID: <93664E98-7494-41D2-93DD-1BBF59574329@opencsw.org> Hi folks, on Monday, 4th of April between 8:00 AM and 8:30 AM MET the leased line where the Baltic Online buildfarm is connected to will have an outage due to an upgrade from 2 MBit to 5 MBit :-) Sorry for the inconvenience -- Dago From bwalton at opencsw.org Thu Mar 31 00:34:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 30 Mar 2011 18:34:20 -0400 Subject: [csw-maintainers] GAR default change branch is now merged Message-ID: <1301524419-sup-688@pinkfloyd.chass.utoronto.ca> Hi All, The v2-default change branch of GAR is now merged to v2. Please report any issues to Dago or myself. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert.thurner at gmail.com Wed Mar 16 07:58:38 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Wed, 16 Mar 2011 06:58:38 -0000 Subject: [csw-maintainers] help needed for subversion ... Message-ID: hi, i wanted to do an emergency build of subversion, as there is a remote denial of service possibility only requiring read permission, see http://subversion.apache.org/security/CVE-2011-0715-advisory.txt. after getting checkpkg errors, i tried to spin a $ SKIPTEST=1 gmake repackage remerge quickly ... but the checkpkg errors stayed the same. so i do a replatform again and will look in two days :) if somebody would have time to spin it as well, or look earlier than i can, i'd be very glad. for checkpkg: would it be a possibility to do one of (1) use automatically the "old" gar version so it reliably builds, or (2) enable a continuous integration build so a gar change immediately lets the build of subversion fail? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at probably.co.uk Mon Mar 28 12:38:29 2011 From: mark at probably.co.uk (Mark Phillips) Date: Mon, 28 Mar 2011 10:38:29 -0000 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> Message-ID: <773D4D6F-A240-4A4E-A2A4-2BBD4273BB0D@opencsw.org> On 28 Mar 2011, at 08:17, Maciej Blizi?ski wrote: > 2011/3/27 Peter Bonivart : >> + if [ "$SMF_STATE" = "enabled" ] || [ "$daemon" = "yes" -a >> "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then > > This is a weird syntax, a combination of [ ] and -a. I thought you > could just use -o: > >> + if [ "$SMF_STATE" = "enabled" -o "$daemon" = "yes" -a >> "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then I would've said -o too - easier to read, if nothing else.