From bwalton at opencsw.org  Sun May  1 15:18:58 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 01 May 2011 09:18:58 -0400
Subject: [csw-maintainers] call for php5 testing
Message-ID: <1304255726-sup-4642@pinkfloyd.chass.utoronto.ca>


Hi All,

I've placed a set of packages in experimental/php5[1] that I think are
worthy of wider testing.  This is a large overhaul of the GAR recipe
(it now builds in only a few hours instead of 1+ days) and is
modernized in other ways too.

I'm using the 'e build' method to enable/disable modphp5 in apache and
also to enable/disable modules in php.ini.  The etc/ directory has
been moved to /etc/opt/csw/php5/ now too.

As this is a large package (GAR build and number of outputs) and will
affect a great many sites, I'd appreciate any testing feedback you can
offer.

(Sorry this has taken so long...it was a real beast.)

Thanks
-Ben

[1] http://buildfarm.opencsw.org/experimental.html#php5
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From darin at darins.net  Tue May  3 14:14:44 2011
From: darin at darins.net (Darin Perusich)
Date: Tue, 3 May 2011 08:14:44 -0400
Subject: [csw-maintainers] write access to tape devices
In-Reply-To: <1304090190-sup-6499@pinkfloyd.chass.utoronto.ca>
References: <1304042353-sup-9634@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=QOz33qju1TtnjmfCM40XqK56EOA@mail.gmail.com>
	<1304090190-sup-6499@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTim9hPyA_YqUt3A53NE=jDCKyksYDg@mail.gmail.com>

Ben,

Having the bacula user in the 'sys' group should be all that's
necessary to write to the tape devices and read the disk device, this
is the case for Amanda, but if you're using something outside of
ufsdump/ufsrestore you'll hit permissions issues. For Amanda there are
some RBAC rules that need to be set for taking ZFS snapshots and
stuff. You'll need to take a look at the Amanda package or my build
scripts to get the details. I'm not managing Solaris systems anymore
so I don't recall the specifics.

--
Later,
Darin



On Fri, Apr 29, 2011 at 11:18 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Apr 29 11:14:49 -0400 2011:
>
> Hi Phil,
>
>> so you arent being that much more "secure" by putting bacula in
>> group sys.
>
> Well, I'm trying to have the daemons run with uid != 0, but the
> storage daemon in some configs will need tape access, so I need to
> make sure it has the required rights.
>
> Thanks for the info though.
>
> Thanks
> -Ben
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From maciej at opencsw.org  Wed May  4 09:20:51 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Wed, 4 May 2011 08:20:51 +0100
Subject: [csw-maintainers] Blastwave releases new catalog
Message-ID: <BANLkTikYw_X_23nUX8pMw7m-zUws+uCgag@mail.gmail.com>

https://www.blastwave.org/wiki/display/BWSTACK/BWTree+Release+Announcement

Notable changes:

- installs in /opt/bw
- interactive configuration during installs

The main mirror is here:
http://d1.blastwave.org/bwstag/

Maciej

From bwalton at opencsw.org  Wed May  4 15:03:28 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 May 2011 09:03:28 -0400
Subject: [csw-maintainers] write access to tape devices
In-Reply-To: <BANLkTim9hPyA_YqUt3A53NE=jDCKyksYDg@mail.gmail.com>
References: <1304042353-sup-9634@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=QOz33qju1TtnjmfCM40XqK56EOA@mail.gmail.com>
	<1304090190-sup-6499@pinkfloyd.chass.utoronto.ca>
	<BANLkTim9hPyA_YqUt3A53NE=jDCKyksYDg@mail.gmail.com>
Message-ID: <1304514165-sup-5303@pinkfloyd.chass.utoronto.ca>

Excerpts from Darin Perusich's message of Tue May 03 08:14:44 -0400 2011:

Hi Darin,

> Having the bacula user in the 'sys' group should be all that's
> necessary to write to the tape devices and read the disk device,
> this is the case for Amanda, but if you're using something outside
> of ufsdump/ufsrestore you'll hit permissions issues. For Amanda
> there are some RBAC rules that need to be set for taking ZFS
> snapshots and stuff. You'll need to take a look at the Amanda
> package or my build scripts to get the details. I'm not managing
> Solaris systems anymore so I don't recall the specifics.

Thanks for this info.  I'll look at amanda and get the RBAC changes
integrated into bacula too.

Thanks!
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Wed May  4 16:47:50 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 May 2011 10:47:50 -0400
Subject: [csw-maintainers] Available atom feeds
In-Reply-To: <BANLkTik5vq9jN4ovrZNY=Fi0jocZbukziQ@mail.gmail.com>
References: <D1315850-4F66-42CF-BB1D-A73391666B6D@opencsw.org>
	<1303995507-sup-9833@pinkfloyd.chass.utoronto.ca>
	<BANLkTik5vq9jN4ovrZNY=Fi0jocZbukziQ@mail.gmail.com>
Message-ID: <1304520444-sup-7903@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Fri Apr 29 01:57:07 -0400 2011:

> Could you modify the feed from the current catalog so it's called
> 'current' rather than 'unstable'?

Yes.  Sorry to be slow in response here.  I'll fix this tonight.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Thu May  5 02:09:07 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 May 2011 20:09:07 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
Message-ID: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>


Hi All,

It's time to change the way OpenCSW packages are released.  The
current system has many flaws and inconsistencies that cause
frustration among maintainers.  Changing the process isn't a new idea.
Several proposals have hit the maintainers list in the past. What's
different this time is that there is something to back the proposal
up!  Maciej has been busy coding.  Other maintainers have been
diligently providing feedback and suggestions for improvements.  Many
of us are currently using the new process.

As I type this, it's possible to use gar/v2/bin/csw-upload-pkg to
submit your packages to the unstable catalog in opencsw-future that
sees them immediately cataloged and available for download.

At this point, the only thing lacking in the new process is the gpg
signing of the catalog.  Although this will be addressed before any
official switch to this tool, we feel that it's time to open the doors
to wider testing of the new process.

You are encouraged to kick the tires on this new tool and provide
feedback that can be incorporated to make it better.

Going forward, I formally propose that the current release system be
abolished in favour of an automated one. This will entail:

1. All packages are submitted to unstable via csw-upload-pkg.
2. After 2 weeks in unstable with no bugs filed, they are
   automatically promoted to current.

Users are free to pull from unstable directly (just as they can in
debian), but most will wait for current.  The experimental catalogs on
the buildfarm will remain unchanged as they're a good way to deliver
quick downloads for personal or bugfix testing.

Objections to this type of automation in the past have focused on the
benefits of the human inspection that we have currently.  Nobody is
disputing that having other eyes on a package is a good thing.  We
hope that people will continue poking at the packages in unstable and
filing bug reports.  We're attempting to address the following issue
with the current process without reducing the ability for human QA:

1. Inconsistent application of policy. Multiple tools that implement
   different standards or the same standards differently are self
   defeating.
2. An und(er)ocumented, manual process with no way to know where a
   package sits or why it sits there.
3. Subject to time availability of a single person.  (Redundancy
   exists on paper but not in practice.)
4. Packages may be stalled for non-policy reasons.

The new process will address these areas as follows:

A package that fails Maciej's version of checkpkg will be rejected.
If checkpkg is ok with it, it will be released into unstable.  If
problems are discovered by use and/or manual inspection of the
packages, a bug can be filed and the issue discussed on the list. At
resolution time, checkpkg will be augmented to catch the new problem
or the problem will be deemend 'not a bug.'

The process will be fully knowable.  The tools are open to all.  The
back end handling for everything will be fully documented[1].

Packages can be released when you're ready, at any time of day.

All policy issues will require discussion on the list where all voices
are equal.  Votes will be held when required to decide issues, but in
many cases, we hope they aren't necessary as consensus will be reached
quickly.

Any and all feedback is welcomed.  Update your GAR checkouts and give
this a whirl!  Watch activity in the new catalog by subscribing to an
atom feed for the catalogs[2].

Thanks
-Ben

[1] http://wiki.opencsw.org/automated-release-process
[2] http://buildfarm.opencsw.org/~bwalton
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Thu May  5 02:43:53 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 4 May 2011 17:43:53 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>

On Wed, May 4, 2011 at 5:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
>...
> Objections to this type of automation in the past have focused on the
> benefits of the human inspection that we have currently. ?Nobody is
> disputing that having other eyes on a package is a good thing. ?We
> hope that people will continue poking at the packages in unstable and
> filing bug reports.

"hoping", never leads to good quality process.

when you switch to this, virtually all packages will have no-one but
the maintainer looking at them before release.

?We're attempting to address the following issue
> with the current process without reducing the ability for human QA:
>
> 1. Inconsistent application of policy. Multiple tools that implement
> ? different standards or the same standards differently are self
> ? defeating.

If you switch to this method, then the release toolchain, effectively
becomes both "release manager", and "policy enforcer".

What process are you going to put in place, to restrict changes to the
behaviour of those things, without being effectively "at the whim of
one person", albeit a DIFFERENT person than it has been up until now?




> All policy issues will require discussion on the list where all voices
> are equal. ?Votes will be held when required to decide issues, but in
> many cases, we hope they aren't necessary as consensus will be reached
> quickly.

Does this translate to,, "maciej will put in any changes as soon as he
feels like it. They will be backed out, only if someone complains, AND
the board agrees to put up a vote on the issue"?

I would suggest that this is poor quality practice, and that ALL
changes must be reviewed and approved by more than just the person
coding the change.
(given that, as I point out above, the code becomes effectively
interchangable with "policy")

From bwalton at opencsw.org  Thu May  5 04:06:40 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 May 2011 22:06:40 -0400
Subject: [csw-maintainers] Available atom feeds
In-Reply-To: <BANLkTik5vq9jN4ovrZNY=Fi0jocZbukziQ@mail.gmail.com>
References: <D1315850-4F66-42CF-BB1D-A73391666B6D@opencsw.org>
	<1303995507-sup-9833@pinkfloyd.chass.utoronto.ca>
	<BANLkTik5vq9jN4ovrZNY=Fi0jocZbukziQ@mail.gmail.com>
Message-ID: <1304561074-sup-2355@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Fri Apr 29 01:57:07 -0400 2011:

Hi Maciej,

> Could you modify the feed from the current catalog so it's called
> 'current' rather than 'unstable'?

I'm currently building feeds for:

http://mirror.opencsw.org/opencsw/5.9/unstable
http://mirror.opencsw.org/opencsw/5.10/unstable
http://mirror.opencsw.org/opencsw-future/5.9/unstable
http://mirror.opencsw.org/opencsw-future/5.10/unstable

I can add polling for the 'current' catalog if you want (and it will
automatically get the proper title).

Let me know.

Thanks
-Ben

--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Thu May  5 19:37:08 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 05 May 2011 13:37:08 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
Message-ID: <1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed May 04 20:43:53 -0400 2011:
> On Wed, May 4, 2011 at 5:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
> >...
> > Objections to this type of automation in the past have focused on the
> > benefits of the human inspection that we have currently. ?Nobody is
> > disputing that having other eyes on a package is a good thing. ?We
> > hope that people will continue poking at the packages in unstable and
> > filing bug reports.
> 
> "hoping", never leads to good quality process.

Feel free to file bugs on packages pushed to future/unstable.  This
change will _not_ restrict the ability for humans to QA packages.  It
just changes the handling of the QA process.

> when you switch to this, virtually all packages will have no-one but
> the maintainer looking at them before release.

Broken packages will make it to unstable with the new tool, but they
do with current processes too.

> We're attempting to address the following issue > with the current
> process without reducing the ability for human QA:
> >
> > 1. Inconsistent application of policy. Multiple tools that implement
> > ? different standards or the same standards differently are self
> > ? defeating.
> 
> If you switch to this method, then the release toolchain, effectively
> becomes both "release manager", and "policy enforcer".

The difference from the current process being that the same checks
will be applied to every package in a consistent fashion.  And
checkpkg will only block on policy issues.

> What process are you going to put in place, to restrict changes to
> the behaviour of those things, without being effectively "at the
> whim of one person", albeit a DIFFERENT person than it has been up
> until now?

The checkpkg development happens in the open, under the eyes of anyone
watching devel at .  All maintainers have the ability to work on and
modify this code.  I've submitted (small) changes and have more in
mind presently.  These are all just adding things that people agree on
already (eg: _stub package shsould have the obsolete file).  For
actual changes in packaging standards, there should be discussion
before implementation within checkpkg.

> > All policy issues will require discussion on the list where all
> > voices are equal. ?Votes will be held when required to decide
> > issues, but in many cases, we hope they aren't necessary as
> > consensus will be reached quickly.
> 
> Does this translate to,, "maciej will put in any changes as soon as he
> feels like it. They will be backed out, only if someone complains, AND
> the board agrees to put up a vote on the issue"?

Not at all.

> I would suggest that this is poor quality practice, and that ALL
> chpanges must be reviewed and approved by more than just the person
> coding the change.  (given that, as I point out above, the code
> becomes effectively interchangable with "policy")

I think that's fair.  We already have patches flying by on devel@, we
could move to a SoB (signed off by), AB (Acked by) model like git
where at least two people must ok each change before it's approved.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Thu May  5 20:52:17 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 5 May 2011 19:52:17 +0100
Subject: [csw-maintainers] Available atom feeds
In-Reply-To: <1304561074-sup-2355@pinkfloyd.chass.utoronto.ca>
References: <D1315850-4F66-42CF-BB1D-A73391666B6D@opencsw.org>
	<1303995507-sup-9833@pinkfloyd.chass.utoronto.ca>
	<BANLkTik5vq9jN4ovrZNY=Fi0jocZbukziQ@mail.gmail.com>
	<1304561074-sup-2355@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimtirOsQqmnbJ2PKz7tmKkSkiLdcQ@mail.gmail.com>

2011/5/5 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Maciej Blizi?ski's message of Fri Apr 29 01:57:07 -0400 2011:
>
> Hi Maciej,
>
>> Could you modify the feed from the current catalog so it's called
>> 'current' rather than 'unstable'?
>
> I'm currently building feeds for:
>
> http://mirror.opencsw.org/opencsw/5.9/unstable
> http://mirror.opencsw.org/opencsw/5.10/unstable
> http://mirror.opencsw.org/opencsw-future/5.9/unstable
> http://mirror.opencsw.org/opencsw-future/5.10/unstable
>
> I can add polling for the 'current' catalog if you want (and it will
> automatically get the proper title).

I would suggest that the polling of unstable from the old set of
catalogs could be removed.  The unstable catalog is only a
compatibility symlink, while in opencsw-future it's a separate entity.
This way, if you see 'unstable', you think opencsw-future.  If you see
'current', you think the old set of catalogs.

Maciej

From bwalton at opencsw.org  Thu May  5 21:00:55 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 05 May 2011 15:00:55 -0400
Subject: [csw-maintainers] Available atom feeds
In-Reply-To: <BANLkTimtirOsQqmnbJ2PKz7tmKkSkiLdcQ@mail.gmail.com>
References: <D1315850-4F66-42CF-BB1D-A73391666B6D@opencsw.org>
	<1303995507-sup-9833@pinkfloyd.chass.utoronto.ca>
	<BANLkTik5vq9jN4ovrZNY=Fi0jocZbukziQ@mail.gmail.com>
	<1304561074-sup-2355@pinkfloyd.chass.utoronto.ca>
	<BANLkTimtirOsQqmnbJ2PKz7tmKkSkiLdcQ@mail.gmail.com>
Message-ID: <1304622036-sup-2189@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Thu May 05 14:52:17 -0400 2011:

> > I can add polling for the 'current' catalog if you want (and it
> > will automatically get the proper title).
> 
> I would suggest that the polling of unstable from the old set of
> catalogs could be removed.  The unstable catalog is only a
> compatibility symlink, while in opencsw-future it's a separate
> entity.  This way, if you see 'unstable', you think opencsw-future.
> If you see 'current', you think the old set of catalogs.

Ok, I'll switch this up tonight.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Fri May  6 21:19:26 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 06 May 2011 15:19:26 -0400
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
Message-ID: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>

I've checked on mirror.opencsw.org and file the isn't there (in any of
the multiple arch/osrel pairs I checked).  It's not in the catalog
either.  Is this a DB error or was this package nuked by accident?

I seem to recall someone working on this one recently.  Ideas?

Thanks
-Ben

--- Begin forwarded message from axelle_apvrille ---
From: axelle_apvrille <axelle_apvrille at yahoo.fr>
To: users <users at lists.opencsw.org>
Date: Fri, 06 May 2011 15:11:12 -0400
Subject: [csw-users] Can't find CSWunrealircd

Hi list,

I can't install unrealircd on SunOS 10:
# pkgutil -i CSWunrealircd
Solving needed dependencies ...
Package CSWunrealircd not in catalog. Exiting.

Though it does exist: http://www.opencsw.org/packages/CSWunrealircd/

# pkgutil -v
2.3

and my catalog is recently updated.

I use:
descriptions.ibiblio.org_pub_packages_solaris_opencsw_current_sparc_5.10

SunOS 5.10

Thanks
Axelle

--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bonivart at opencsw.org  Fri May  6 21:29:27 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 6 May 2011 21:29:27 +0200
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>

On Fri, May 6, 2011 at 9:19 PM, Ben Walton <bwalton at opencsw.org> wrote:
> I've checked on mirror.opencsw.org and file the isn't there (in any of
> the multiple arch/osrel pairs I checked). ?It's not in the catalog
> either. ?Is this a DB error or was this package nuked by accident?
>
> I seem to recall someone working on this one recently. ?Ideas?

There's a four year old package here:

http://csw.informatik.uni-erlangen.de/oldpkgs/unstable/i386/5.10/unrealircd-3.2.6-SunOS5.8-i386-CSW.pkg.gz
http://csw.informatik.uni-erlangen.de/oldpkgs/unstable/sparc/5.10/unrealircd-3.2.6-SunOS5.8-sparc-CSW.pkg.gz

Somehow it has dropped out of the catalog..? Maybe we should first
reinstate it and then rebuild a new version since it was recently
updated (Dec 2010).

http://www.unrealircd.com/

/peter

From phil at bolthole.com  Fri May  6 22:24:11 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 6 May 2011 13:24:11 -0700
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
Message-ID: <BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>

On Fri, May 6, 2011 at 12:29 PM, Peter Bonivart <bonivart at opencsw.org> wrote:
....
> Somehow it has dropped out of the catalog..? Maybe we should first
> reinstate it and then rebuild a new version since it was recently
> updated (Dec 2010).
>
> http://www.unrealircd.com/
>

It's possible someone explicitly asked me to remove it, but I forgot
to deregister it after removing the file.

either way, if someone just goes ahead and rebuilds, it will
automatically get "reinstated" once submitted :)

From phil at bolthole.com  Fri May  6 23:22:47 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 6 May 2011 14:22:47 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>

On Thu, May 5, 2011 at 10:37 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Wed May 04 20:43:53 -0400 2011:
>> On Wed, May 4, 2011 at 5:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
>> >...
>> > Objections to this type of automation in the past have focused on the
>> > benefits of the human inspection that we have currently. ?Nobody is
>> > disputing that having other eyes on a package is a good thing. ?We
>> > hope that people will continue poking at the packages in unstable and
>> > filing bug reports.
>>
>> "hoping", never leads to good quality process.
>
> Feel free to file bugs on packages pushed to future/unstable. ?This
> change will _not_ restrict the ability for humans to QA packages. ?It
> just changes the handling of the QA process.
>

It seems that you missed.. or ignored... my point.
but I'll save further conversation about that, to voting time.


>> Does this translate to,, "maciej will put in any changes as soon as he
>> feels like it. They will be backed out, only if someone complains, AND
>> the board agrees to put up a vote on the issue"?
>
> Not at all.
>
>> I would suggest that this is poor quality practice, and that ALL
>> chpanges must be reviewed and approved by more than just the person
>> coding the change. ?(given that, as I point out above, the code
>> becomes effectively interchangable with "policy")
>
> I think that's fair. ?We already have patches flying by on devel@, we
> could move to a SoB (signed off by), AB (Acked by) model like git
> where at least two people must ok each change before it's approved.
>

And what if "at least two people" like the change, but other people do not?
Since, I repeat, this stuff becomes de-facto policy --  what
(political/policy) mechanisms are you going to put in place to
disallow "two people" to determine policy between themselves?

There will need to be some kind of auto-triggered dispute policy on
this. Otherwise,
two board members who collude, can do whatever they feel like to the
code, and block votes on issues that they personally are against.

From rupert at opencsw.org  Fri May  6 23:30:16 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Fri, 6 May 2011 23:30:16 +0200
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
Message-ID: <BANLkTikSK5HGRyoN4k7DBhikq3TTd0BueQ@mail.gmail.com>

On Fri, May 6, 2011 at 23:22, Philip Brown <phil at bolthole.com> wrote:
> On Thu, May 5, 2011 at 10:37 AM, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Philip Brown's message of Wed May 04 20:43:53 -0400 2011:
>>> On Wed, May 4, 2011 at 5:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
>>> >...
>>> > Objections to this type of automation in the past have focused on the
>>> > benefits of the human inspection that we have currently. ?Nobody is
>>> > disputing that having other eyes on a package is a good thing. ?We
>>> > hope that people will continue poking at the packages in unstable and
>>> > filing bug reports.

would it be possible to bring checkpkg in some kind of release
according to the release of the rest of the software?

rupert.

From maciej at opencsw.org  Sat May  7 02:30:21 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 7 May 2011 01:30:21 +0100
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTikSK5HGRyoN4k7DBhikq3TTd0BueQ@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<BANLkTikSK5HGRyoN4k7DBhikq3TTd0BueQ@mail.gmail.com>
Message-ID: <BANLkTimtK+rH+-=XFOJ5DFYjqYPHF1hi4Q@mail.gmail.com>

2011/5/6 rupert THURNER <rupert at opencsw.org>:
> would it be possible to bring checkpkg in some kind of release
> according to the release of the rest of the software?

It is certainly possible.  It would have a bureaucratic overhead; in
order to create checkpkg releases, we need to put in place new
processes.  Establishing and executing these will consume people's
precious time, so we need to weigh the cost vs benefit.

Volunteers would most probably be accepted.

Maciej

From maciej at opencsw.org  Sat May  7 17:47:22 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 7 May 2011 16:47:22 +0100
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
	<BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
Message-ID: <BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>

The new version depends on libtre, which I built some time ago. It is in
opencsw-future/unstable. But the unrealircd build system is quite
maintainer-hostile. If you search for 'unrealircd build', you will find a
forum post in which unrealircd developer says they discourage packaging it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110507/4df57411/attachment.html>

From bwalton at opencsw.org  Sun May  8 15:26:51 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 08 May 2011 09:26:51 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
Message-ID: <1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri May 06 17:22:47 -0400 2011:
> On Thu, May 5, 2011 at 10:37 AM, Ben Walton <bwalton at opencsw.org> wrote:
> > Excerpts from Philip Brown's message of Wed May 04 20:43:53 -0400 2011:
> >> On Wed, May 4, 2011 at 5:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
> >> >...
> >> > Objections to this type of automation in the past have focused on the
> >> > benefits of the human inspection that we have currently. ?Nobody is
> >> > disputing that having other eyes on a package is a good thing. ?We
> >> > hope that people will continue poking at the packages in unstable and
> >> > filing bug reports.
> >>
> >> "hoping", never leads to good quality process.
> >
> > Feel free to file bugs on packages pushed to future/unstable. ?This
> > change will _not_ restrict the ability for humans to QA packages. ?It
> > just changes the handling of the QA process.
> >
> 
> It seems that you missed.. or ignored... my point.
> but I'll save further conversation about that, to voting time.

No, I understand what you're saying quite clearly.  The 'all packages
must be inspected' argument has been your historical position on
this.  Again, nobody that thinks the automated solution is better
thinks that human inspection _can't_ help.

I happen to know that not all package submitted for release are
subjected to the same level of scrutiny though.  Some are passed
immediately without inspection.  I also know that although checkpkg
would pass a package, packages are not pushed for release.  This is
what I call a non-policy block.

csw-upload-pkg solves these problems.  All packages are equal in the
eyes of checkpkg.  They either pass policy or they don't.

Can csw-upload-pkg release bad packages?  Absolutely.  Can the human
release manager release bad packages?  See libneon.  csw-upload-pkg
has a distinct advantage in turn around for correction here as it's
not subject to time zones and sleep requirements, etc.

> >> Does this translate to,, "maciej will put in any changes as soon
> >> as he feels like it. They will be backed out, only if someone
> >> complains, AND the board agrees to put up a vote on the issue"?
> >
> > Not at all.
> >
> >> I would suggest that this is poor quality practice, and that ALL
> >> chpanges must be reviewed and approved by more than just the person
> >> coding the change. ?(given that, as I point out above, the code
> >> becomes effectively interchangable with "policy")
> >
> > I think that's fair. ?We already have patches flying by on devel@, we
> > could move to a SoB (signed off by), AB (Acked by) model like git
> > where at least two people must ok each change before it's approved.
> >
> 
> And what if "at least two people" like the change, but other people do not?
> Since, I repeat, this stuff becomes de-facto policy --  what
> (political/policy) mechanisms are you going to put in place to
> disallow "two people" to determine policy between themselves?

Well, most people wouldn't simply alter checkpkg (maciej's version) to
have it enforce new rules.  These would be discussed and then
implemented.  And, as development is fully open with changes sent to
the mailing list, it's easy to monitor (not that I have any qualms
about this at all).

And, if you want to get right down to it, even in your worst case
scenario above where two people collude on policy, that's still better
than the current situation where it only takes one.

> There will need to be some kind of auto-triggered dispute policy on
> this. Otherwise, two board members who collude, can do whatever they
> feel like to the code, and block votes on issues that they
> personally are against.

While I don't see this happening in the way you do, all I can say is
that the board is an elected body.  It will change over time.  Just
like any government it will make decisions you don't personally like.
Challenge it at the ballot box the next time around.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Sun May  8 16:04:55 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 08 May 2011 10:04:55 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTikSK5HGRyoN4k7DBhikq3TTd0BueQ@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<BANLkTikSK5HGRyoN4k7DBhikq3TTd0BueQ@mail.gmail.com>
Message-ID: <1304863375-sup-3481@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Fri May 06 17:30:16 -0400 2011:

Hi Rupert,

> would it be possible to bring checkpkg in some kind of release
> according to the release of the rest of the software?

You're suggesting a checkpkg package?  I think this would be nice.
The idea has been kicked around a bit in the past.  Maciej is correct
that it would add overhead, but (python packaging aside), I don't
think this would be too burdensome.

Maciej, how much effort is involved in packaging up the checkpkg code
as a separate entity from with gar/v2?  I will undertake this work if
you can provide the direction for which files are required.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Sun May  8 16:36:38 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 8 May 2011 15:36:38 +0100
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1304863375-sup-3481@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<BANLkTikSK5HGRyoN4k7DBhikq3TTd0BueQ@mail.gmail.com>
	<1304863375-sup-3481@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=0210xzBcwYf7xp9AGzJQQyY5D2A@mail.gmail.com>

Em 08/05/2011 15:05, "Ben Walton" <bwalton at opencsw.org> escreveu:
> Maciej, how much effort is involved in packaging up the checkpkg code
> as a separate entity from with gar/v2?  I will undertake this work if
> you can provide the direction for which files are required.

Generally the same as with submitpkg. If a symlink in /opt/csw/bin is
provided, it should just work.

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110508/371511d7/attachment.html>

From bwalton at opencsw.org  Sun May  8 21:00:03 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 08 May 2011 15:00:03 -0400
Subject: [csw-maintainers] gcc __sync_fetch_and_add revisited
Message-ID: <1304881068-sup-51@pinkfloyd.chass.utoronto.ca>


Hi All,

I bumped into a problem that others have seen previously and I _think_
I found the problem...

Certain c++ apps fail to build on sparc with the 'undefined symbol
__sync_fetch_and_add4' error.  It seems that this may be due to the
way gcc was packaged for sparc.

If we look through the headers for __sync_fetch_and_add, we find:
include/c++/4.3.3/ext/atomicity.h (and a few others)

This file defines __exchange_and_add using __sync_fetch_and_add if
_GLIBCXX_ATOMIC_BUILTINS is defined.

This value is defined as 1 in:
include/c++/4.3.3/sparc-sun-solaris2.8/bits/c++config.h
include/c++/4.3.3/sparc-sun-solaris2.8/sparcv9/bits/c++config.h

Looking in include/c++/4.3.3/sparc-sun-solaris2.8/, we have only bits/
and sparcv9/.

As sparcv9 supports the required atomic operations but sparcv8 doesn't
(according to my reading, correct me if I'm wrong), I hypothesize that
the architecture detection done during the gcc4 build picked up the
fact that it was building on a sparcv9 and set values accordingly.
Thus, even when building things with flags forcing sparcv8, gcc thinks
it can use capabilities that it can't.

Does this all sound reasonable?

If this is the case, we should likely have gcc4 rebuilt with different
flags so that it's base is v8.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Sun May  8 21:32:21 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 8 May 2011 12:32:21 -0700
Subject: [csw-maintainers] gcc __sync_fetch_and_add revisited
In-Reply-To: <1304881068-sup-51@pinkfloyd.chass.utoronto.ca>
References: <1304881068-sup-51@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=zEJBa5NFc0yB4VSRa_AFsgE+r1Q@mail.gmail.com>

On Sun, May 8, 2011 at 12:00 PM, Ben Walton <bwalton at opencsw.org> wrote:
>
> Does this all sound reasonable?
>
> If this is the case, we should likely have gcc4 rebuilt with different
> flags so that it's base is v8.
>

yes that sounds like what happened... however.... we should also make
it so that the library actually uses the extra functionality on v9.
atomic-add is pretty important for good performance.
we can't NOT support it, on the better cpus.

reminder: this can be done with AUX_FILTERs, perhaps.

From rupert at opencsw.org  Sun May  8 22:17:03 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 8 May 2011 22:17:03 +0200
Subject: [csw-maintainers] lzlib-1.1: ldconfig not found ...
Message-ID: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>

when upgrding lzlib the following error is thrown:


install-info --info-dir="/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/share/info"
/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/share/info/lzlib.info
if [ ! -d "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/include"
] ; then /opt/csw/bin/ginstall -d -m 755
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/include"
; fi
if [ ! -d "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib"
] ; then /opt/csw/bin/ginstall -d -m 755
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib"
; fi
/opt/csw/bin/ginstall -p -m 644 ./lzlib.h
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/include/lzlib.h"
/opt/csw/bin/ginstall -p -m 644 ./liblz.a
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib/liblz.a"
if [ -n "minilzip_shared" ] ; then \
  /opt/csw/bin/ginstall -p -m 755 ./liblz.so.1.1
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib/liblz.so.1.1"
; \
  if [ -f "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib/liblz.so.1"
] ; then \
    run_ldconfig=no ; rm -f
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib/liblz.so.1"
; \
  else run_ldconfig=yes ; \
  fi ; \
  cd "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib"
&& ln -s liblz.so.1.1 liblz.so.1 ; \
  if [ ${run_ldconfig} = yes ] ; then ldconfig
"/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib"
; fi ; \
fi
/bin/sh: ldconfig: not found
gmake[2]: *** [install] Error 1
gmake[2]: Leaving directory
`/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/build-isa-sparcv8/lzlib-1.1'
gmake[1]: *** [install-work/solaris9-sparc/build-isa-sparcv8/lzlib-1.1/Makefile]
Error 2
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/lzlib/trunk'
gmake: *** [merge-isa-sparcv8] Error 2


i am unsure how this should behave correctly.

rupert.

From jeff at cjsa.com  Mon May  9 09:13:16 2011
From: jeff at cjsa.com (Jeffery Small)
Date: Mon, 9 May 2011 07:13:16 GMT
Subject: [csw-maintainers] Sendmail question
Message-ID: <LKx2q4.IFB@cjsa.com>


I see that Alex Moore (Retired) is listed as the cswsendmail maintainer.
As he is not available, I wanted to see if anyone here had some insight
into a an aspect of how sendmail operates that I am finding confusing.  I'm
running Solaris 10 on a SPARC server with the current CSW sendmail version
8.14.2,REV=2007.12.17.

The problem I am seeing is that some mail scheduled for local delivery gets
placed in the /opt/csw/var/spool/clientmqueue directory and then waits
there for a long period before being delivered.  The following services and
processes are running:

% svcs | grep sendmail
online         23:31:39 svc:/network/smtp:cswsendmail

% sps -A | grep sendmail
root   22888 sendmail: accepting connections
smmsp  22885 sendmail: Queue runner at 00:15:00 for /opt/csw/var/spool/clientmqueue

and:

% cat /opt/csw/var/spool/clientmqueue/sm-client.pid
22885
/opt/csw/lib/sendmail -L sm-msp -Ac -q15m

The mail files appear to be sitting in /opt/csw/var/spool/clientmqueue for
up to 15 minutes due to the -q15m option.  I want to speed up delivery, but
I am unsure where to set this.  In the sendmail book I cannot seem to find
any sendmail configuration option to modify the *.mc file and subsequent
sendmail.cf.  The script which fires off the processes is located at
/opt/csw/lib/svc/method/svc-sendmail and contains the following section:

check_queue_interval_syntax()
{
    default="15m"
    if [ $# -lt 1 ]; then
	answer=$default
	return
    fi
    if echo $1 | egrep '^([0-9]*[1-9][0-9]*[smhdw])+$' >/dev/null 2>&1; then
	answer=$1
    else
	answer=$default
    fi
}

Now, I can change the default value here, but I really don't want to edit
this file since it will likely be overwritten every time the sendmail
package is updated.

Prior to the Solaris 10 switch to services, I knew what to do, but now
it is a bit of a mystery.  So does anyone know what the factory approved
method of resetting this queue is?

Thanks for any insights.

Regards,
-- 
Jeff

C. Jeffery Small           CJSA LLC                       206-232-3338
jeff at cjsa.com              7000 E Mercer Way, Mercer Island, WA  98040


From james at opencsw.org  Mon May  9 10:29:28 2011
From: james at opencsw.org (James Lee)
Date: Mon, 09 May 2011 08:29:28 GMT
Subject: [csw-maintainers] Sendmail question
In-Reply-To: <LKx2q4.IFB@cjsa.com>
References: <LKx2q4.IFB@cjsa.com>
Message-ID: <20110509.8292800.2715349735@gyor.oxdrove.co.uk>

On 09/05/11, 08:13:16, Jeffery Small <jeff at cjsa.com> wrote regarding
[csw-maintainers] Sendmail question:

> The mail files appear to be sitting in /opt/csw/var/spool/clientmqueue
> for up to 15 minutes due to the -q15m option.  I want to speed up
> delivery, but I am unsure where to set this.  In the sendmail book I
> cannot seem to find any sendmail configuration option to modify the
> *.mc file and subsequent sendmail.cf.  The script which fires off the
> processes is located at /opt/csw/lib/svc/method/svc-sendmail and
> contains the following section:

> check_queue_interval_syntax()
> {
>     default="15m"
>     if [ $# -lt 1 ]; then
>       answer=$default
>       return
>     fi
>     if echo $1 | egrep '^([0-9]*[1-9][0-9]*[smhdw])+$' >/dev/null 2>&1;
then
>       answer=$1
>     else
>       answer=$default
>     fi
> }

> Now, I can change the default value here, but I really don't want to edit
> this file since it will likely be overwritten every time the sendmail
> package is updated.

$1 is $CLIENTQUEUEINTERVAL which is sourced from $DEFAULT_FILE which is
/opt/csw/etc/default/sendmail

Try:
CLIENTQUEUEINTERVAL=10m
in /opt/csw/etc/default/sendmail (untested suggestion).

Alex was an early adopter of the Service Management Facility with CSW so
his methods predate current ideas.


I think 15m is a good interval for retries - don't hammer the receiver if
it's not ready.


Your underlying problem is that some local email is being queue.  I use
the default (SUNW) sendmail client to pass to my exim server.  Sendmail
client only queues when the receiver is not ready.  If it's queuing check
the receiver.




James.

From phil at bolthole.com  Mon May  9 18:43:00 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 9 May 2011 09:43:00 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>

On Sun, May 8, 2011 at 6:26 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri May 06 17:22:47 -0400 2011:
>
>> There will need to be some kind of auto-triggered dispute policy on
>> this. Otherwise, two board members who collude, can do whatever they
>> feel like to the code, and block votes on issues that they
>> personally are against.
>
> While I don't see this happening in the way you do, all I can say is
> that the board is an elected body. ?It will change over time. ?Just
> like any government it will make decisions you don't personally like.
> Challenge it at the ballot box the next time around.

People can vote different people into the board, yet still have
unchanged opinions about policy.
This sort of thing leads to the problems in a "representative
democracy": The problem where the elected representatives set up
systems that the people who voted for them, would vote AGAINST, if
given the chance. Except they arent given the chance.

I thought direct democracy is what we were supposed to be aiming for, in OpenCSW

You are essentially setting up "the board", to be the governing body
of policy, rather than direct democracy. Apparently, since they are
"an elected body", this is all right with you, over mandating that
policy be enforcedly fully democratic.

That is potentially an okay way to go, IF people understand
beforehand, that is what is happening.
Seems to me that this sort of change should be scheduled to take
effect at the convening of the next board.
It should then be made clear to the voters, that they are not just
voting for "officers of opencsw", but also the policy governing
apparatus.

From bwalton at opencsw.org  Mon May  9 19:28:29 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 09 May 2011 13:28:29 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
Message-ID: <1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon May 09 12:43:00 -0400 2011:

> You are essentially setting up "the board", to be the governing body
> of policy, rather than direct democracy. Apparently, since they are
> "an elected body", this is all right with you, over mandating that
> policy be enforcedly fully democratic.

No.  You are perceiving this only.  You misunderstood what the SoB/Ack
was meant to accomplish and extrapolated from there.  My mistake was
not clearly correcting you the first time.

I'm suggesting that changes to checkpkg should require multiple
eyeballs before committing.  Those eyeballs could belong to any person
with commit rights.  Could be 2 board members or 2 random maintainers
or a combination.  The aim here is to see that changes to checkpkg
actually enforce agreed upon policies and removes the 'one person
dictacting policy' you seemed to worry about.  I don't feel that this
is a concern but addressing it doesn't hurt anyway.

Any abuse is easily spotted since changes propagate to the mailing
list.

The above is just a verification process.  Changes to checkpkg (the
enforced tests, anyway) should not be made at whim.  They should agree
with policies decided in the current mechanisms...discussion on the
list and votes when necessary.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From jeff at cjsa.com  Mon May  9 19:50:37 2011
From: jeff at cjsa.com (Jeffery Small)
Date: Mon, 9 May 2011 10:50:37 -0700 (PDT)
Subject: [csw-maintainers] Sendmail question
References: <LKx2q4.IFB@cjsa.com>
	<20110509.8292800.2715349735@gyor.oxdrove.co.uk>
Message-ID: <201105091750.p49HobWO004346@cjsa2.com>

In local.csw.maint you write:

>$1 is $CLIENTQUEUEINTERVAL which is sourced from $DEFAULT_FILE which is
>/opt/csw/etc/default/sendmail

>Try:
>CLIENTQUEUEINTERVAL=10m
>in /opt/csw/etc/default/sendmail (untested suggestion).

>Alex was an early adopter of the Service Management Facility with CSW so
>his methods predate current ideas.

>I think 15m is a good interval for retries - don't hammer the receiver if
>it's not ready.

>Your underlying problem is that some local email is being queue.  I use
>the default (SUNW) sendmail client to pass to my exim server.  Sendmail
>client only queues when the receiver is not ready.  If it's queuing check
>the receiver.

James:

Thanks for the feedback.  I'll look into things further and see if I
can determine why the mail is being queued.  Everything mail related is
happening on a single machine, so this system should simply be putting
these queued messages in the proper mailboxes in /var/mail.  This is only
happening with certain mail, and I cannot see a predictable pattern.  I'll
examine the logs and possible step up the debugging level to see what may
be happening.

Regards,
-- 
Jeff

C. Jeffery Small           CJSA LLC                       206-232-3338
jeff at cjsa.com              7000 E Mercer Way, Mercer Island, WA  98040

From bwalton at opencsw.org  Tue May 10 04:10:22 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 09 May 2011 22:10:22 -0400
Subject: [csw-maintainers] lzlib-1.1: ldconfig not found ...
In-Reply-To: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>
References: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>
Message-ID: <1304993092-sup-1194@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sun May 08 16:17:03 -0400 2011:

Hi Rupert,

> when upgrding lzlib the following error is thrown:

>   if [ -f "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib/liblz.so.1"
> ] ; then \
>     run_ldconfig=no ; rm -f
> "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib/liblz.so.1"
> ; \
>   else run_ldconfig=yes ; \
>   fi ; \
>   cd "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib"
> && ln -s liblz.so.1.1 liblz.so.1 ; \
>   if [ ${run_ldconfig} = yes ] ; then ldconfig
> "/home/rupert/mgar/pkg/lzlib/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lib"
> ; fi ; \
> fi
> /bin/sh: ldconfig: not found

This looks to be a linuxism that has been coded into the build
process.  I'd question it's correctness in the form above if run on a
linux box as that would manipulate /etc/ld.so.conf.  This is a rough
equivalent of crle.

If you disable it via patching, what happens?  Maybe just turn that
line into a no-op?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Tue May 10 18:01:13 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 10 May 2011 09:01:13 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>

On Mon, May 9, 2011 at 10:28 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon May 09 12:43:00 -0400 2011:
>
>> You are essentially setting up "the board", to be the governing body
>> of policy, rather than direct democracy. Apparently, since they are
>> "an elected body", this is all right with you, over mandating that
>> policy be enforcedly fully democratic.
>
> No. ?You are perceiving this only. ?You misunderstood what the SoB/Ack
> was meant to accomplish and extrapolated from there. ?My mistake was
> not clearly correcting you the first time.

Sounds like I should point back to my earlier email: seems like you
missed the point of what I was saying earlier.

What this system is "meant to accomplish", and what this system WILL
accomplish, are overlapping, but not strictly equal, sets :-/


> I'm suggesting that changes to checkpkg should require multiple
> eyeballs before committing. ?Those eyeballs could belong to any person
> with commit rights. ?Could be 2 board members or 2 random maintainers
> or a combination. ?The aim here is to see that changes to checkpkg
> actually enforce agreed upon policies and removes the 'one person
> dictacting policy' you seemed to worry about. ?I don't feel that this
> is a concern but addressing it doesn't hurt anyway.
>
> Any abuse is easily spotted since changes propagate to the mailing
> list.

There is "abuse", and there is "difference of opinion".
You have not laid down any foundation for smoothly resolving
"difference of opinion".
What you have written so far, only works out well for "everyone comes
to consensus on the issue".
It works out poorly, for " three people have an argument, and no-one
else cares to say anything either way" (or even cares to read the
discussion thread).


It has been my experience (and even my own behaviour), that people may
not neccessarily be bothered to read a discussion thread, but they may
pay attention if the issue is actually brought to a vote.

Not every issue is worth voting about. But some are. As such, I think
there should be some kind of official trigger for the dissenting
voice(s) to be able to start a vote on a policy/release toolchain
issue.

From bwalton at opencsw.org  Tue May 10 18:41:50 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 10 May 2011 12:41:50 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
Message-ID: <1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Tue May 10 12:01:13 -0400 2011:

> Not every issue is worth voting about. But some are. As such, I
> think there should be some kind of official trigger for the
> dissenting voice(s) to be able to start a vote on a policy/release
> toolchain issue.

This is all well and good, but it's a tangential issue to what we're
proposing here.  Replacing a human release manager with csw-upload-pkg
does not strictly require changes to other day-to-day activities aside
from how packages are pushed for release.  It's a change in workflow.

Policy discussions, resolutions and changes to checkpkg to reflect the
former can happen as they have been or we can implement stricter
controls (sob/ab, etc).  I'm not against standardizing how changes
happen, but it's a side issue.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Tue May 10 19:19:18 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Tue, 10 May 2011 18:19:18 +0100
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
	<BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
	<BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>
Message-ID: <BANLkTinaOd_xB6O7M6_EUxfzRP3BChguXg@mail.gmail.com>

2011/5/7 Maciej Blizi?ski <maciej at opencsw.org>:
> If you search for 'unrealircd build', you will find a forum post in which
> unrealircd developer says they discourage packaging it.

The mentioned forum post:
http://forums.unrealircd.com/viewtopic.php?p=33524#p33524

Maciej

From phil at bolthole.com  Tue May 10 20:26:20 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 10 May 2011 11:26:20 -0700
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTinaOd_xB6O7M6_EUxfzRP3BChguXg@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
	<BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
	<BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>
	<BANLkTinaOd_xB6O7M6_EUxfzRP3BChguXg@mail.gmail.com>
Message-ID: <BANLkTimmdt2kFu99SWAQhfVa3is+WzzsGA@mail.gmail.com>

2011/5/10 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/5/7 Maciej Blizi?ski <maciej at opencsw.org>:
>> If you search for 'unrealircd build', you will find a forum post in which
>> unrealircd developer says they discourage packaging it.
>
> The mentioned forum post:
> http://forums.unrealircd.com/viewtopic.php?p=33524#p33524
>

doesnt seem particularly relevant to the problems we are facing right
now, on a technical level. There is no technical barrier mentioned.
It's more that the developer appears to be allergic to packaging.
Possibly one of those rabid religious zealots that believes that all
software should only be distributed via source, and EVERYONE should
compile ALL their programs from source.
(which ignores the inconvenient problem of: if everything is source,
then with what are you going to compile it, and what are you going to
compile it ON? ;-)


It's ironic that (as pointed out in the thread), he is pro GPL, yet at
the same time resists the direct results of GPL:  anyone can take the
program, and redistribute it and tweak it in any manner they wish, to
suit their needs or preferences.
Sad, really.

but reguardless, anyone who is interested in it, should package it.
if no-one is interested in it, then lets remove its registration, and move on.

From maciej at opencsw.org  Tue May 10 23:46:02 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Tue, 10 May 2011 22:46:02 +0100
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTimmdt2kFu99SWAQhfVa3is+WzzsGA@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
	<BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
	<BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>
	<BANLkTinaOd_xB6O7M6_EUxfzRP3BChguXg@mail.gmail.com>
	<BANLkTimmdt2kFu99SWAQhfVa3is+WzzsGA@mail.gmail.com>
Message-ID: <BANLkTi=VqXBtGqHL2y-CVYcD+=WXqJgkVw@mail.gmail.com>

2011/5/10 Philip Brown <phil at bolthole.com>:
> but reguardless, anyone who is interested in it, should package it.

I took a stab at it and here's the error I got:

In file included from
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/iso/wchar_iso.h:44,
                 from
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/wchar.h:20,
                 from /opt/csw/include/tre/tre.h:147,
                 from /opt/csw/include/tre/regex.h:16,
                 from ../include/struct.h:68,
                 from s_kline.c:24:
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/ctype.h:58:
error: expected ')' before '>=' token

I've committed all previous work to the repository, so if anyone wants
to continue, can pick up where I left off.

Maciej

From phil at bolthole.com  Wed May 11 00:01:37 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 10 May 2011 15:01:37 -0700
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
	<BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
	<BANLkTi=0OSTLz3E2=bhQu4bnDYk2Kq7K0g@mail.gmail.com>
Message-ID: <BANLkTinqS0WWGg7QQ-j26HLzaJGRrjJmGw@mail.gmail.com>

2011/5/7 Maciej Blizi?ski <maciej at opencsw.org>:
> The new version depends on libtre, which I built some time ago.


hrm.

well, I downloaded 3.2.8.1, and did a quickie configure --prefix=/opt/csw
with CC=cc, Sunpro version 11, not 12.
On Solaris 10.

and, interestingly... it compiles
Without libtre.

(I think there's a bundled version of it in the archive. under the
"extras" dir.)

Be warned that the "configure" phase, does a compile of the "extras" stuff.



one warning is that it fails linking, because of "inline" stuffs.

Tehre's a quickie fix for that, but I gotta run Right Now-- no time to
look itup.
otherwise I'm guessing it will cmpile and link just fine.

From maciej at opencsw.org  Wed May 11 11:39:34 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Wed, 11 May 2011 10:39:34 +0100
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinF=0VSRivBLLYTDB=Vb7=mAFO0+A@mail.gmail.com>

For those who haven't yet tried it, here's an example run.  The
executable can be run from checked out sources by giving the full
path, as shown below.

In the first phase, srv4 files are uploaded to allpkgs.  Once this is
done, checkpkg is run against all catalogs that the packages are going
to be added to.  When inserting a 5.9 package to a 5.10 catalog, it's
a good idea to check the package against the 5.10 catalog too, as
there may be some differences between corresponding 5.9 and 5.10
catalogs.  If all checks pass, packages are added to corresponding
catalogs.

maciej at login [login]:~ > ~/src/opencsw-git/gar/v2/bin/csw-upload-pkg
~/exp/gfile* ~/exp/*magic*
Processing 8 file(s). Please wait.
Uploading '/home/maciej/exp/gfile-5.07,REV=2011.05.11-SunOS5.9-i386-CSW.pkg.gz'
Uploading '/home/maciej/exp/gfile-5.07,REV=2011.05.11-SunOS5.9-sparc-CSW.pkg.gz'
Uploading '/home/maciej/exp/libmagic1-5.07,REV=2011.05.11-SunOS5.9-i386-CSW.pkg.gz'
Uploading '/home/maciej/exp/libmagic1-5.07,REV=2011.05.11-SunOS5.9-sparc-CSW.pkg.gz'
Uploading '/home/maciej/exp/libmagic_data-5.07,REV=2011.05.11-SunOS5.9-all-CSW.pkg.gz'
Uploading '/home/maciej/exp/libmagic_dev-5.07,REV=2011.05.11-SunOS5.9-i386-CSW.pkg.gz'
Uploading '/home/maciej/exp/libmagic_dev-5.07,REV=2011.05.11-SunOS5.9-sparc-CSW.pkg.gz'
Uploading '/home/maciej/exp/py_libmagic-5.07,REV=2011.05.11-SunOS5.9-all-CSW.pkg.gz'
Checking 5 package(s) against catalog unstable sparc SunOS5.9
Checking 5 package(s) against catalog unstable i386 SunOS5.9
Checking 5 package(s) against catalog unstable sparc SunOS5.10
Checking 5 package(s) against catalog unstable i386 SunOS5.10
All checks successful. Proceeding.
Inserting gfile (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting libmagic1 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting libmagic_data (all SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting libmagic_dev (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting py_libmagic (all SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting gfile (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting libmagic1 (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting libmagic_data (all SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting libmagic_dev (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting py_libmagic (all SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting gfile (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libmagic1 (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libmagic_data (all SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libmagic_dev (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting py_libmagic (all SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting gfile (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting libmagic1 (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting libmagic_data (all SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting libmagic_dev (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting py_libmagic (all SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting gfile (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting libmagic1 (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting libmagic_data (all SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting libmagic_dev (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting py_libmagic (all SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting gfile (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting libmagic1 (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting libmagic_data (all SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting libmagic_dev (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting py_libmagic (all SunOS5.9) into catalog unstable sparc SunOS5.9
maciej at login [login]:~ >

When packages are added, a cron job rebuilds the opencsw-future
catalog, and the maintainer gets an email notification about the new
version being available from the mirror.

If you haven't tried it yet, please give it a go!  If you don't have
any new packages at the moment, you can run the tool with previously
submitted packages.

Maciej

From bwalton at opencsw.org  Wed May 11 15:22:44 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 11 May 2011 09:22:44 -0400
Subject: [csw-maintainers] gcc __sync_fetch_and_add revisited
In-Reply-To: <BANLkTi=zEJBa5NFc0yB4VSRa_AFsgE+r1Q@mail.gmail.com>
References: <1304881068-sup-51@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=zEJBa5NFc0yB4VSRa_AFsgE+r1Q@mail.gmail.com>
Message-ID: <1305120143-sup-493@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun May 08 15:32:21 -0400 2011:

> yes that sounds like what happened... however.... we should also
> make it so that the library actually uses the extra functionality on
> v9.  atomic-add is pretty important for good performance.  we can't
> NOT support it, on the better cpus.

Agreed.  I don't have time to tackle this though.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Thu May 12 01:55:35 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 11 May 2011 16:55:35 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>

On Tue, May 10, 2011 at 9:41 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Tue May 10 12:01:13 -0400 2011:
>
>> Not every issue is worth voting about. But some are. As such, I
>> think there should be some kind of official trigger for the
>> dissenting voice(s) to be able to start a vote on a policy/release
>> toolchain issue.
>
> This is all well and good, but it's a tangential issue to what we're
> proposing here. ?Replacing a human release manager with csw-upload-pkg
> does not strictly require changes to other day-to-day activities aside
> from how packages are pushed for release. ?It's a change in workflow.
>
> Policy discussions, resolutions and changes to checkpkg to reflect the
> former can happen as they have been or we can implement stricter
> controls (sob/ab, etc). ?I'm not against standardizing how changes
> happen, but it's a side issue.

What you seem to be saying is,

"Hey, its time to change the workflow. Lets not bother thinking about
the *impact* of changing the workflow, lets just go ahead and change
it! "
This is a poor "policy workflow", in and of itself.

Coincidentally, the parts that you dont seem to think are worth
discussing BEFORE the change, are the parts that put you and maciej
directly in charge of the workflow AFTER the change.
AND, coincidentally, you and maciej will be the ones who will control
any later avenues of complaint or adjustment against the "workflow"
once it is implemented.

In legal, and corporate circles, this is what is known as a "conflict
of interest".

From dam at opencsw.org  Thu May 12 09:19:43 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 12 May 2011 09:19:43 +0200
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
Message-ID: <55C5637C-EDFD-49E5-8166-03DB577CEA91@opencsw.org>

Hi,

Am 12.05.2011 um 01:55 schrieb Philip Brown:
> On Tue, May 10, 2011 at 9:41 AM, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Philip Brown's message of Tue May 10 12:01:13 -0400 2011:
>> 
>>> Not every issue is worth voting about. But some are. As such, I
>>> think there should be some kind of official trigger for the
>>> dissenting voice(s) to be able to start a vote on a policy/release
>>> toolchain issue.
>> 
>> This is all well and good, but it's a tangential issue to what we're
>> proposing here.  Replacing a human release manager with csw-upload-pkg
>> does not strictly require changes to other day-to-day activities aside
>> from how packages are pushed for release.  It's a change in workflow.
>> 
>> Policy discussions, resolutions and changes to checkpkg to reflect the
>> former can happen as they have been or we can implement stricter
>> controls (sob/ab, etc).  I'm not against standardizing how changes
>> happen, but it's a side issue.
> 
> What you seem to be saying is,
> 
> "Hey, its time to change the workflow. Lets not bother thinking about
> the *impact* of changing the workflow, lets just go ahead and change
> it! "
> This is a poor "policy workflow", in and of itself.
> 
> Coincidentally, the parts that you dont seem to think are worth
> discussing BEFORE the change, are the parts that put you and maciej
> directly in charge of the workflow AFTER the change.
> AND, coincidentally, you and maciej will be the ones who will control
> any later avenues of complaint or adjustment against the "workflow"
> once it is implemented.
> 
> In legal, and corporate circles, this is what is known as a "conflict
> of interest".

I don't understand all the fuzz about this. The previous workflow looked
like this:

  pkgsubmissions@ -> Release Manager -> current

The proposed new workflow looks like this:

  csw-upload-pkg -> unstable -> QA Team -> current

The policies in csw-upload-pkg are well accepted and all packages pass them
anyway when build with GAR. As the previous Release Manager is propably
a member of the QA Team there is no change in policies: what had to be
discussed previously as guideline for the release manager must now be
discussed as guideline for the QA Team. I fail to see a significant change
here.

Besides all this a proverb comes to my mind:

  "The engineers doubting that something is possible should just
   step aside from the engineers already doing it."



Best regards

  -- Dago


From phil at bolthole.com  Thu May 12 20:01:49 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 12 May 2011 11:01:49 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <55C5637C-EDFD-49E5-8166-03DB577CEA91@opencsw.org>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
	<55C5637C-EDFD-49E5-8166-03DB577CEA91@opencsw.org>
Message-ID: <BANLkTi=CwY=2O7fuC=6NARtnyW6XuhujUw@mail.gmail.com>

On Thu, May 12, 2011 at 12:19 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> I don't understand all the fuzz about this. The previous workflow looked
> like this:
>
> ?pkgsubmissions@ -> Release Manager -> current
>
> The proposed new workflow looks like this:
>
> ?csw-upload-pkg -> unstable -> QA Team -> current

Eh? where did this "qa team" get mentioned? I see no mention of any
such "QA team".
What I DO see (reading Ben's original email in this thread), is:

- Automatic, immediate publishing to "unstable".

- Automatic publishing to "current", after 2 weeks and no bugs filed.

There is then an unsubstantiated claim of,
"Users are free to pull from unstable directly (just as they can in
debian), but most will wait for current. "

"most will wait" is unsubstantiated. no-one knows for sure what our
users will do.

Changing tracks a little, it seems that certain people in opencsw are
attempting to pull a "sun".
ie:
  Get rid of all the old-school in-house "QA process", publish
"directly", and let "the internet" magically file bugs and do all the
QA work. and somehow hope that the result is good quality.

Unfortunately, that thought process is awfully similar to the business plan of

1. Create internet startup
2.  ?????
3. PROFIT!!!

From dam at opencsw.org  Thu May 12 20:14:37 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 12 May 2011 20:14:37 +0200
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTi=CwY=2O7fuC=6NARtnyW6XuhujUw@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
	<55C5637C-EDFD-49E5-8166-03DB577CEA91@opencsw.org>
	<BANLkTi=CwY=2O7fuC=6NARtnyW6XuhujUw@mail.gmail.com>
Message-ID: <C40F2DFA-66E6-4E3C-9820-67CC4501595B@opencsw.org>

Hi Phil,

Am 12.05.2011 um 20:01 schrieb Philip Brown:
> On Thu, May 12, 2011 at 12:19 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> 
>> I don't understand all the fuzz about this. The previous workflow looked
>> like this:
>> 
>>  pkgsubmissions@ -> Release Manager -> current
>> 
>> The proposed new workflow looks like this:
>> 
>>  csw-upload-pkg -> unstable -> QA Team -> current
> 
> Eh? where did this "qa team" get mentioned? I see no mention of any
> such "QA team".
> What I DO see (reading Ben's original email in this thread), is:
> 
> - Automatic, immediate publishing to "unstable".
> - Automatic publishing to "current", after 2 weeks and no bugs filed.
> 
> There is then an unsubstantiated claim of,
> "Users are free to pull from unstable directly (just as they can in
> debian), but most will wait for current. "
> 
> "most will wait" is unsubstantiated. no-one knows for sure what our
> users will do.

I don't know what you want to say by that. Some users still subscribe to
stable, some use experimental, YMMV.

> Changing tracks a little, it seems that certain people in opencsw are
> attempting to pull a "sun".
> ie:
>  Get rid of all the old-school in-house "QA process", publish
> "directly", and let "the internet" magically file bugs and do all the
> QA work. and somehow hope that the result is good quality.

At the moment most users have subscribed to current as it is the only
usable catalog receiving updates. We have exactly 1 person looking
at the packages before going to current (=you). While this catches
bugs from time to time it also leads to completely broken catalogs
from time to time. Publishing packages to unstable first give more
people a chance to inspect and actually use packages before going
to current. Something like the curl desaster would have been cought.
Additionally, I see no reason why the same person doing QA now can't
file a bug instead of writing an email. Apart from hopefully many
more eyes.

To stick to you web analogies: you want the cathedral instead of the
bazaar.


Best regards

  -- Dago


From dam at opencsw.org  Fri May 13 15:27:27 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 13 May 2011 15:27:27 +0200
Subject: [csw-maintainers] lzlib-1.1: ldconfig not found ...
In-Reply-To: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>
References: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>
Message-ID: <B3ADE547-25E5-4C20-9803-026A4C05465D@opencsw.org>

Hi Rupert,

Am 08.05.2011 um 22:17 schrieb rupert THURNER:
> when upgrding lzlib the following error is thrown:
> ...
> /bin/sh: ldconfig: not found
> ...
> 
> i am unsure how this should behave correctly.

I took the liberty of fixing the issue by replacing LDCONFIG with 'echo'
and bringing it up to the latest standards:
  http://sourceforge.net/apps/trac/gar/changeset/14571

Please release as you see fit.


Best regards

  -- Dago

From phil at bolthole.com  Sat May 14 05:02:45 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 13 May 2011 20:02:45 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <C40F2DFA-66E6-4E3C-9820-67CC4501595B@opencsw.org>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
	<55C5637C-EDFD-49E5-8166-03DB577CEA91@opencsw.org>
	<BANLkTi=CwY=2O7fuC=6NARtnyW6XuhujUw@mail.gmail.com>
	<C40F2DFA-66E6-4E3C-9820-67CC4501595B@opencsw.org>
Message-ID: <BANLkTik=OR6d4PdpNNxab6TMkWUA8kF2HA@mail.gmail.com>

On Thu, May 12, 2011 at 11:14 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> ...
> Additionally, I see no reason why the same person doing QA now can't
> file a bug instead of writing an email.

and I see no reason why you "couldnt" send me $200 every month.
I'm sure you "could". but are you going to? :)

> To stick to you web analogies: you want the cathedral instead of the
> bazaar.

well, if you want to go there.. I seem to recall that "Mr. cathedral
and the bazaar" himself, said that the bazaar methodology is NOT
suited to every purpose.

Also, "the bazaar model" does not mean "no QA before release". it
means [OPEN testing(and source code], according to the summary at
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

That is not at all the same thing as "open (no lack of individuals in
charge) *releases*"
You are twisting, or perhaps misunderstanding, the whole premise there.


You name ONE MAJOR DISTRIBUTION that has a completely automated release process?
Debian? nope. redhat? nope. ubuntu? nope. slackware? nope.
*LINUX ITSELF*?
That's a big *nope*.


Right now, "current" is the one and only "release" that we have.
We have no "stable release manager" any more.
(because its a worse job than even the current release manager, and
no-one wants to do it in a serious manner any more)

This is effectively going to a fully automated "release" system.


> Publishing packages to unstable first give more
> people a chance to inspect and actually use packages before going
> to current.

side comment: "unstable" has too much history, both with us, and with
other distros. it would probably be better named "testing".

From rupert at opencsw.org  Sat May 14 14:01:53 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 14 May 2011 14:01:53 +0200
Subject: [csw-maintainers] Fwd:  lzlib-1.1: ldconfig not found ...
In-Reply-To: <BANLkTine1BR-N2tbQFDiOa+6Q1tuGYXFjA@mail.gmail.com>
References: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>
	<B3ADE547-25E5-4C20-9803-026A4C05465D@opencsw.org>
	<BANLkTine1BR-N2tbQFDiOa+6Q1tuGYXFjA@mail.gmail.com>
Message-ID: <BANLkTinV8gvVTzNPLUPHmOZqqigZqMCxHA@mail.gmail.com>

talked to antonio, it will be fixed upstream as well.

On May 13, 2011 3:27 PM, "Dagobert Michelsen" <dam at opencsw.org> wrote:

Hi Rupert,

Am 08.05.2011 um 22:17 schrieb rupert THURNER:

> when upgrding lzlib the following error is thrown:

> ...

> /bin/sh: ldconfig: not found

> ...

>
> i am unsure how this should behave correctly.

I took the liberty of fixing the issue by replacing LDCONFIG with 'echo'
and bringing it up to the latest standards:
?http://sourceforge.net/apps/trac/gar/changeset/14571

Please release as you see fit.


Best regards

?-- Dago

_______________________________________________
maintainers mailing list
maintainers at lists.opencsw.o...

From maciej at opencsw.org  Sun May 15 14:14:35 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 15 May 2011 13:14:35 +0100
Subject: [csw-maintainers] An idea: monthly IRC meetings
Message-ID: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>

Hello, community!

We've been using IRC for a long time, but it's been informal, and we'd
meet at random times.  We've also been meeting in real life, but only
every 6 months.  How about combining the two ideas and establishing
monthly IRC meetings? They could constitute a useful middle ground
between the slow paced, low-interaction mailing list and
high-interaction but costly IRL meetings.

Here are some proposed details:

- The meeting would be held on a designated day of week on e.g. every
Nth week of the month, or something like "last Wednesday of the
month".
- The meeting would be 1h hour long. A designated person would track
the time and indicate transitions between agenda items.
- The agenda would be on our wiki, where project members would add
items they want to discuss.
- Meeting logs would not be publicly accessible (this doesn't rule out
local logging)

Here is a wiki page I started, with agenda items:
http://wiki.opencsw.org/irc-meeting-agenda

Please add items. If there will be too many items for an 1h meeting,
we'll move the items to the next one.

I have created a doodle so we can pick the best date and time for everybody.

When selecting a date, don't just think "Nth of May", but think
"Monday" or "Wednesday" and how it fits into your week. For me for
example, Thursdays would be non-optimal, because of my other weekly
activities.

All times are in UTC, please take your time zone into account.  For
example, 17:00 UTC is 18:00 CEST (Central Europe), is 12:00 EST (East
Coast), is 09:00 PST (West Coast).

Here's the doodle for the meeting:
http://www.doodle.com/kmfdyrfc8kwcum2x

Please pick times that suit you best.

Maciej

From bwalton at opencsw.org  Sun May 15 16:28:32 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 15 May 2011 10:28:32 -0400
Subject: [csw-maintainers] An idea: monthly IRC meetings
In-Reply-To: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
References: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
Message-ID: <1305469646-sup-7636@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Sun May 15 08:14:35 -0400 2011:

Hi Maciej,

> We've been using IRC for a long time, but it's been informal, and
> we'd meet at random times.  We've also been meeting in real life,
> but only every 6 months.  How about combining the two ideas and
> establishing monthly IRC meetings? They could constitute a useful
> middle ground between the slow paced, low-interaction mailing list
> and high-interaction but costly IRL meetings.

I like this idea.  IRC is great for chats, but due to time zones,
we're rarely all in there at the same time.  If we designate certain
points in time when we'll attempt to get together, this would help a
lot, I think.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Sun May 15 20:24:51 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 15 May 2011 14:24:51 -0400
Subject: [csw-maintainers] Fwd: [findutils 0004769]: Current stable release
	is vulnerable to CVE-2007-2452
Message-ID: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>


Does anyone have stable installs kicking around still?  Want to roll
an updated findutils for it?

Thanks
-Ben

--- Begin forwarded message from Mantis Bug Tracker ---
From: Mantis Bug Tracker <noreply at opencsw.org>
Date: Sun, 15 May 2011 12:10:16 -0400
Subject: [findutils 0004769]: Current stable release is vulnerable to CVE-2007-2452


The following issue has been REOPENED. 
====================================================================== 
https://www.opencsw.org/mantis/view.php?id=4769 
====================================================================== 
Reported By:                jay
Assigned To:                bwalton
====================================================================== 
Project:                    findutils
Issue ID:                   4769
Category:                   upgrade
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
====================================================================== 
Date Submitted:             2011-05-14 14:50 CEST
Last Modified:              2011-05-15 18:10 CEST
====================================================================== 
Summary:                    Current stable release is vulnerable to
CVE-2007-2452
Description: 
GNU Findutils release 4.2.31 fixes CVE-2007-2452 but stable is 4.2.30, and
so it's vulnerable.
====================================================================== 

--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bonivart at opencsw.org  Sun May 15 20:51:11 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 15 May 2011 20:51:11 +0200
Subject: [csw-maintainers] Fwd: [findutils 0004769]: Current stable
 release is vulnerable to CVE-2007-2452
In-Reply-To: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
References: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>

On Sun, May 15, 2011 at 8:24 PM, Ben Walton <bwalton at opencsw.org> wrote:
>
> Does anyone have stable installs kicking around still? ?Want to roll
> an updated findutils for it?

Before someone spends time on this maybe we should find out how to
actually update a package in stable?

About 18 months ago I updated BIND for security reasons, I even
packaged it the same way but it never got released. It was a waste of
time for me and the users of stable never got the secure version.

/peter

From bwalton at opencsw.org  Sun May 15 20:56:53 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 15 May 2011 14:56:53 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
Message-ID: <1305483964-sup-4851@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed May 11 19:55:35 -0400 2011:

> AND, coincidentally, you and maciej will be the ones who will
> control any later avenues of complaint or adjustment against the
> "workflow" once it is implemented.

Not Ihsan too?  Please don't mistake this as something that only
Maciej and I are backing.  There is a large group of active
maintainers that have provided input to this already.

> In legal, and corporate circles, this is what is known as a
> "conflict of interest".

If you consider this change a conflict of interest, you must see the
irony in the current release manager arguing for status quo. :)

I don't see the conflict here.  I'm pushing for what I believe to be a
better process.  As things stand currently, there is a single person
capable of preventing package release.  This is done far too often for
reasons other than policy.  It is inconsistent.  It is handled by
closed tools and processes.

When many people want things a certain way but one doesn't and that
one can block packages, there is a glaring deficiency.  We're
addressing this problem.

csw-upload-pkg levels the playing field.  As Dago noted, it changes
where QA is applied.  It removes the bottle neck and forces the QA
team to play by the same rules as everyone else.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Sun May 15 22:01:20 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 15 May 2011 13:01:20 -0700
Subject: [csw-maintainers] Fwd: [findutils 0004769]: Current stable
 release is vulnerable to CVE-2007-2452
In-Reply-To: <BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>
References: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
	<BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>
Message-ID: <BANLkTinVM3jNQF3sJSc9h-ACGTSmB5FbUQ@mail.gmail.com>

On Sun, May 15, 2011 at 11:51 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Sun, May 15, 2011 at 8:24 PM, Ben Walton <bwalton at opencsw.org> wrote:
>>
>> Does anyone have stable installs kicking around still? ?Want to roll
>> an updated findutils for it?
>
> Before someone spends time on this maybe we should find out how to
> actually update a package in stable?

there is the technical "how to update the catalog", and there is
policy on "what kind of updates are allowed to packages in stable".
See below.

> About 18 months ago I updated BIND for security reasons, I even
> packaged it the same way but it never got released. It was a waste of
> time for me and the users of stable never got the secure version.

It was rejected for one of two reasons (I dont remember which).
either
a) you did not verify you had tested it, or
b) you went too far in your updates. you did not merely patch the
security hole, but changed the package.


To restate that in terms of "what kind of updates are allowed to
packages in stable?":

stable package updates should only be done at critical need (ie:
crucial security flaw), and they should involve only minimal change to
the package. Ideally, just patching the security hole, and a
recompile. No version changes, etc.

Anything beyond that, and it is no longer "stable".

The actual adding of a package into stable, is trivial.

From bonivart at opencsw.org  Sun May 15 22:10:34 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 15 May 2011 22:10:34 +0200
Subject: [csw-maintainers] Fwd: [findutils 0004769]: Current stable
 release is vulnerable to CVE-2007-2452
In-Reply-To: <BANLkTinVM3jNQF3sJSc9h-ACGTSmB5FbUQ@mail.gmail.com>
References: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
	<BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>
	<BANLkTinVM3jNQF3sJSc9h-ACGTSmB5FbUQ@mail.gmail.com>
Message-ID: <BANLkTi=Eu6vXB=Qs1+kmKwRqAvobtNkrRQ@mail.gmail.com>

On Sun, May 15, 2011 at 10:01 PM, Philip Brown <phil at bolthole.com> wrote:
> a) you did not verify you had tested it, or

Of course I tested it.

> b) you went too far in your updates. you did not merely patch the
> security hole, but changed the package.

I used ISC's official solution to the security flaw, I even went the
extra mile to package it the same way it already was even though that
was extra work since it by that time was done differently. It sure was
a minimal change.

From phil at bolthole.com  Sun May 15 22:14:18 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 15 May 2011 13:14:18 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1305483964-sup-4851@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
	<1305483964-sup-4851@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTim-YY4q4rED4-VVzzLLcFSdKHdfZQ@mail.gmail.com>

On Sun, May 15, 2011 at 11:56 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Wed May 11 19:55:35 -0400 2011:
>
>> In legal, and corporate circles, this is what is known as a
>> "conflict of interest".
>
> If you consider this change a conflict of interest, you must see the
> irony in the current release manager arguing for status quo. :)


not at all. This is not a case where the person(s) controlling the
flow of "product", also controls all means of complaint and redress.
I have shown multiple times as release manager, that in the existing
process, the recourse for redress, is a vote, and I have abided by the
results of the vote in all cases.




> I don't see the conflict here. ?I'm pushing for what I believe to be a
> better process. ?As things stand currently, there is a single person
> capable of preventing package release.

As I have just pointed out, the single person is ultimately only
capable of DELAYING, not preventing, a package release.


> ?This is done far too often for reasons other than policy.

I think this would be more accurately stated as, "you disagree with
the reasons for it".
Written policy does not and cannot cover everything, so complaining
the reasons are "outside policy" is non-productive.

>It is inconsistent.

no-one is 100% consistent. A better question is whether overall
quality is higher with it, or not.
A process that adds higher quality to a random 50% of the packages,
but does not touch the other 50%, is still valuable to have, not
withstanding that it is "not consistent".




> It is handled by closed tools and processes.

untrue. And as a board member, that is tantamount to lying, since what
other members dont know, is that previously, the current board
requested documentation and disclosure of all processes related to
release. Which I complied with, and you all agreed I had complied
with.


> When many people want things a certain way but one doesn't and that
> one can block packages, there is a glaring deficiency. ?We're
> addressing this problem.

it already has been addressed. multiple times, as mentioned above. A
vote on the specific issue can always be taken.
This seems more about maintainer impatience than anything else.

From phil at bolthole.com  Sun May 15 22:16:19 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 15 May 2011 13:16:19 -0700
Subject: [csw-maintainers] Fwd: [findutils 0004769]: Current stable
 release is vulnerable to CVE-2007-2452
In-Reply-To: <BANLkTi=Eu6vXB=Qs1+kmKwRqAvobtNkrRQ@mail.gmail.com>
References: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
	<BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>
	<BANLkTinVM3jNQF3sJSc9h-ACGTSmB5FbUQ@mail.gmail.com>
	<BANLkTi=Eu6vXB=Qs1+kmKwRqAvobtNkrRQ@mail.gmail.com>
Message-ID: <BANLkTikr_KF3LauGC=a8CZySfikQT+Gw5A@mail.gmail.com>

On Sun, May 15, 2011 at 1:10 PM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Sun, May 15, 2011 at 10:01 PM, Philip Brown <phil at bolthole.com> wrote:
>> a) you did not verify you had tested it, or
>
> Of course I tested it.
>
>> b) you went too far in your updates. you did not merely patch the
>> security hole, but changed the package.
>
> I used ISC's official solution to the security flaw, I even went the
> extra mile to package it the same way it already was even though that
> was extra work since it by that time was done differently. It sure was
> a minimal change.


since you seem to have this fresh in your mind, and I do not... if you
wish to discuss that specific incident further, perhaps you can dig up
the specific email where I said the reason why it was not accepted.

From dam at opencsw.org  Sun May 15 22:27:11 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 15 May 2011 22:27:11 +0200
Subject: [csw-maintainers] Update of stable/ with BIND some time ago
In-Reply-To: <BANLkTikr_KF3LauGC=a8CZySfikQT+Gw5A@mail.gmail.com>
References: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
	<BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>
	<BANLkTinVM3jNQF3sJSc9h-ACGTSmB5FbUQ@mail.gmail.com>
	<BANLkTi=Eu6vXB=Qs1+kmKwRqAvobtNkrRQ@mail.gmail.com>
	<BANLkTikr_KF3LauGC=a8CZySfikQT+Gw5A@mail.gmail.com>
Message-ID: <581A811D-5BBC-417A-BA3B-36F624E54761@opencsw.org>

Hi folks,

Am 15.05.2011 um 22:16 schrieb Philip Brown:
> On Sun, May 15, 2011 at 1:10 PM, Peter Bonivart <bonivart at opencsw.org> wrote:
>> On Sun, May 15, 2011 at 10:01 PM, Philip Brown <phil at bolthole.com> wrote:
>>> a) you did not verify you had tested it, or
>> 
>> Of course I tested it.
>> 
>>> b) you went too far in your updates. you did not merely patch the
>>> security hole, but changed the package.
>> 
>> I used ISC's official solution to the security flaw, I even went the
>> extra mile to package it the same way it already was even though that
>> was extra work since it by that time was done differently. It sure was
>> a minimal change.
> 
> since you seem to have this fresh in your mind, and I do not... if you
> wish to discuss that specific incident further, perhaps you can dig up
> the specific email where I said the reason why it was not accepted.

All I could find was "all right then":
  http://lists.opencsw.org/pipermail/pkgsubmissions/2010-April/000578.html


Best regards

  -- Dago


From phil at bolthole.com  Sun May 15 23:43:37 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 15 May 2011 14:43:37 -0700
Subject: [csw-maintainers] Update of stable/ with BIND some time ago
In-Reply-To: <581A811D-5BBC-417A-BA3B-36F624E54761@opencsw.org>
References: <1305483722-sup-7908@pinkfloyd.chass.utoronto.ca>
	<BANLkTikOjAU2bHu9bPOUyO+B=chwMrPFvA@mail.gmail.com>
	<BANLkTinVM3jNQF3sJSc9h-ACGTSmB5FbUQ@mail.gmail.com>
	<BANLkTi=Eu6vXB=Qs1+kmKwRqAvobtNkrRQ@mail.gmail.com>
	<BANLkTikr_KF3LauGC=a8CZySfikQT+Gw5A@mail.gmail.com>
	<581A811D-5BBC-417A-BA3B-36F624E54761@opencsw.org>
Message-ID: <BANLkTi=STdhFu5P4A_+6FbUH76uB_BN2Kg@mail.gmail.com>

On Sun, May 15, 2011 at 1:27 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi folks,
>
> Am 15.05.2011 um 22:16 schrieb Philip Brown:
>>> since you seem to have this fresh in your mind, and I do not... if you
>> wish to discuss that specific incident further, perhaps you can dig up
>> the specific email where I said the reason why it was not accepted.
>
> All I could find was "all right then":
> ?http://lists.opencsw.org/pipermail/pkgsubmissions/2010-April/000578.html
>

Hmm. odd.

Although I should say, its also usually expected, to have more than
one person test it. maybe the blocking issue was around that.

From phil at bolthole.com  Tue May 17 15:58:07 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 17 May 2011 06:58:07 -0700
Subject: [csw-maintainers] discussion: optional config files in etc
Message-ID: <BANLkTi=SSx1pRGFSRrg=3HcJ0spZxNo1Rg@mail.gmail.com>

Hi folks,
A question has come up, about best pratices for files in etc. Please
give your input. Things can be summarized as follows:

Some programs require having config files in etc to run.
Some programs *allow* config files in etc, to override defaults.

Is it better as a general principle, to have *all possible* config
files, exist as both
etc/config.CSW
etc/config (autogenerated from config.CSW)

or is it better to have the optional ones have their example files
stashed somewhere such as share/doc/prog/config.example, and save the
clutter of not one, but two files, in etc, when they arent usually
needed?

My own preferences is to avoid unneccessary clutter in etc.
Ben and Dago seem to like clutter :)

What are other folks' opinions?

From gadavis at opencsw.org  Tue May 17 17:29:03 2011
From: gadavis at opencsw.org (Geoff Davis)
Date: Tue, 17 May 2011 08:29:03 -0700
Subject: [csw-maintainers] discussion: optional config files in etc
In-Reply-To: <BANLkTi=SSx1pRGFSRrg=3HcJ0spZxNo1Rg@mail.gmail.com>
References: <BANLkTi=SSx1pRGFSRrg=3HcJ0spZxNo1Rg@mail.gmail.com>
Message-ID: <8C9DF81D-34BF-42C2-ADEB-EBE68A8298C0@opencsw.org>

I hate to split hairs on this, but it really does depend on the program in question. I'd say leave it up to the package maintainer to make the call. /etc is hardly pristine on Solaris as shipped from Oracle, with the legacy symbolic links to system binaries and all.

On May 17, 2011, at 6:58 AM, Philip Brown wrote:

> Hi folks,
> A question has come up, about best pratices for files in etc. Please
> give your input. Things can be summarized as follows:
> 
> Some programs require having config files in etc to run.
> Some programs *allow* config files in etc, to override defaults.
> 
> Is it better as a general principle, to have *all possible* config
> files, exist as both
> etc/config.CSW
> etc/config (autogenerated from config.CSW)
> 
> or is it better to have the optional ones have their example files
> stashed somewhere such as share/doc/prog/config.example, and save the
> clutter of not one, but two files, in etc, when they arent usually
> needed?
> 
> My own preferences is to avoid unneccessary clutter in etc.
> Ben and Dago seem to like clutter :)
> 
> What are other folks' opinions?
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From phil at bolthole.com  Tue May 17 18:37:48 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 17 May 2011 09:37:48 -0700
Subject: [csw-maintainers] discussion: stub package naming
Message-ID: <BANLkTi=HJfdyoawdHiVfUEc4DZba8qUDnA@mail.gmail.com>

(I had suggested that Ben start a vote on this, but since he hasnt,
and stuff is piling up, I'll start this additional discussion thread)

There is currently a disagreement about how "stub" packages should
have their catalog name set.

Reminder: Stub packages, are created for purposes of renaming older
packages, that have non-desired names.
They are empty packages, that allow an automated {pkg-get, pkgutil}
update, to pull in the "correct", newer packages.

Almost by definition, the older packages will have non-standard naming.
The question is what to do about the stub package naming.

the SVR4 PKG name must be the same as the old one, there is no choice there.

Here is where the difference of opinion lies: the "catalog" name.

As release manager,  I think that the most consistent thing to do, is
have the catalog name, exactly match the original name, but with
"_stub"
added.
Thus  "libfoo_devel", becomes "libfoo_devel_stub"
I say "consistent", because the stub package, is supposed to be a
placeholder for [old package], so as such, it should conform to [old
package] as tightly as possible.
It also makes searches for it easier. If someone is remembering the
existance of "libfoo_devel", they are going to search directly for
that. In that case, libfoo_devel_stub" is more likely to show up in
the search.
It has been mentioned that pkgutil's "fuzzy search" can in many cases
still show the stub. But there are more ways to search than just that.

Other people are tending to say that the stub catalog name should
follow our *new* standards.
ie: if original is  CSWlibfoodev, libfoo_devel
stub is   CSWlibfoodev, libfoodev_stub

This seems to stem basically from the fact that this is the current
default gar behaviour, and they dont want to spend time updating gar
code to do it the other way, rather than any argument that they
specifically want the naming done that way.

Other people's opinions on this matter are hereby requested.

From dam at opencsw.org  Tue May 17 20:05:56 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 17 May 2011 20:05:56 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
Message-ID: <E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>

Hi Ben,

(moving to maintainers@)

Am 17.05.2011 um 18:47 schrieb Ben Walton:
> Excerpts from Philip Brown's message of Tue May 17 12:40:46 -0400 2011:
> 
>> yes, see http://www.opencsw.org/packages/puppet/
>> 
>> Since people can still trim off the @UNCOMMITTED and get something
>> useful, I deemed it non-fatal.
> 
> I agree it's non-fatal, I was just clarifying.

I think it should be fatal: not because the error is that big, but because
1) it can result in privately build, non-repeatable package builds
2) it breaks browsing of the repository
3) it is really easy to fix

>> Reguardless of what triggered it, I think that the mgar [re]package
>> code, should refuse to continue if it attempts to package something
>> with OPENCSW_REPOSITORY=.*UNCOMMITTED
> 
> Actually, this should be a check added to checkpkg.  The [re]package
> target in mgar shouldn't care about this.

I thought submitpkg already had a trigger in it refusing to submit
uncommitted packages?


Best regards

  -- Dago

From phil at bolthole.com  Tue May 17 20:13:11 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 17 May 2011 11:13:11 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
Message-ID: <BANLkTi=o+f_5hK4CvH=b89yQ-SZQxtvdWQ@mail.gmail.com>

On Tue, May 17, 2011 at 11:05 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Ben,
>
> (moving to maintainers@)
>
> Am 17.05.2011 um 18:47 schrieb Ben Walton:
>> Excerpts from Philip Brown's message of Tue May 17 12:40:46 -0400 2011:
>>
>>> Reguardless of what triggered it, I think that the mgar [re]package
>>> code, should refuse to continue if it attempts to package something
>>> with OPENCSW_REPOSITORY=.*UNCOMMITTED
>>
>> Actually, this should be a check added to checkpkg. ?The [re]package
>> target in mgar shouldn't care about this.
>
> I thought submitpkg already had a trigger in it refusing to submit
> uncommitted packages?
>


It has yet to be proven or disproven whether or not the involved files
are committed, or uncommitted.
They may well be committed.
All we know for sure(until the original maintainer pipes up) at this
point, is that the pkginfo is not what is desired.

From dam at opencsw.org  Tue May 17 20:16:14 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 17 May 2011 20:16:14 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <BANLkTi=o+f_5hK4CvH=b89yQ-SZQxtvdWQ@mail.gmail.com>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
	<BANLkTi=o+f_5hK4CvH=b89yQ-SZQxtvdWQ@mail.gmail.com>
Message-ID: <2634A9E0-740B-4C32-B6BE-6DF37E168392@opencsw.org>

Hi Phil,

Am 17.05.2011 um 20:13 schrieb Philip Brown:
> On Tue, May 17, 2011 at 11:05 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> Am 17.05.2011 um 18:47 schrieb Ben Walton:
>>> Excerpts from Philip Brown's message of Tue May 17 12:40:46 -0400 2011:
>>> 
>>>> Reguardless of what triggered it, I think that the mgar [re]package
>>>> code, should refuse to continue if it attempts to package something
>>>> with OPENCSW_REPOSITORY=.*UNCOMMITTED
>>> 
>>> Actually, this should be a check added to checkpkg.  The [re]package
>>> target in mgar shouldn't care about this.
>> 
>> I thought submitpkg already had a trigger in it refusing to submit
>> uncommitted packages?
> 
> It has yet to be proven or disproven whether or not the involved files
> are committed, or uncommitted.
> They may well be committed.
> All we know for sure(until the original maintainer pipes up) at this
> point, is that the pkginfo is not what is desired.

*If* pkginfo and/or the package name has "uncommitted" in the name the
packaging directory in GAR has not been completely committed which
is not good. A package resulting from such a build should not be
released.


Best regards

  -- Dago


From bonivart at opencsw.org  Tue May 17 20:19:56 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 17 May 2011 20:19:56 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
Message-ID: <BANLkTim2FJBQG-3OD0ATaTE_4+n39Zbq_g@mail.gmail.com>

On Tue, May 17, 2011 at 8:05 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> I thought submitpkg already had a trigger in it refusing to submit
> uncommitted packages?

I think that only looks at the filename (!CSW).

/peter

From phil at bolthole.com  Tue May 17 20:21:11 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 17 May 2011 11:21:11 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <2634A9E0-740B-4C32-B6BE-6DF37E168392@opencsw.org>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
	<BANLkTi=o+f_5hK4CvH=b89yQ-SZQxtvdWQ@mail.gmail.com>
	<2634A9E0-740B-4C32-B6BE-6DF37E168392@opencsw.org>
Message-ID: <BANLkTim948bR+TsRcLZAi_Y=U1WrLvdKxQ@mail.gmail.com>

On Tue, May 17, 2011 at 11:16 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
>
> *If* pkginfo and/or the package name has "uncommitted" in the name the
> packaging directory in GAR has not been completely committed which
> is not good. A package resulting from such a build should not be
> released.
>

I could indeed put in a blocking check for that on my end, if that is
deemed good.

as a side note, this completely blows a hole in the claim some people
are making, that "having two independant error checking systems is
bad".

If we just relied on gar checkpkg to shovel everything through, this
error would never have been seen

From bwalton at opencsw.org  Wed May 18 02:44:56 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 17 May 2011 20:44:56 -0400
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <BANLkTim-YY4q4rED4-VVzzLLcFSdKHdfZQ@mail.gmail.com>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
	<1305483964-sup-4851@pinkfloyd.chass.utoronto.ca>
	<BANLkTim-YY4q4rED4-VVzzLLcFSdKHdfZQ@mail.gmail.com>
Message-ID: <1305678624-sup-43@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun May 15 16:14:18 -0400 2011:

> As I have just pointed out, the single person is ultimately only
> capable of DELAYING, not preventing, a package release.

Delaying to the point where the other parties give up.  I can provide
examples of this, but I don't think that would benefit the discussion.
Gradual improvement is a much better outcome than frustrating people
to the point where the end result is a package not released at all.

> > This is done far too often for reasons other than policy.
> 
> I think this would be more accurately stated as, "you disagree with
> the reasons for it".

No, I mean that packages are blocked based on the personal preferences
of a single individual.  They are not blocked based on real defects[1].

> A process that adds higher quality to a random 50% of the packages,
> but does not touch the other 50%, is still valuable to have, not
> withstanding that it is "not consistent".

The new process will not prevent you or anyone else from inspecting
50% of the packages and providing feedback/filing reports.  It will
alter the dynamics such that no single person can impose their will on
the larger community though.

> > It is handled by closed tools and processes.
> 
> untrue. And as a board member, that is tantamount to lying, since what
> other members dont know, is that previously, the current board
> requested documentation and disclosure of all processes related to
> release. Which I complied with, and you all agreed I had complied
> with.

Sorry, but no.  We made the request, yes.  You pointed at some
notes[2] you'd written previously.  I didn't follow up on it.  Unless
my memory and email history searching are faulty, I don't recall
indicating anything in either direction there.  (Corrections are
welcome, I may not have found the right threads in my mail.)

That isn't what I'm referring to here though...

Rather, I'm talking about things like changes to catalog format
(SITEFEATURES) that can be made on a whim[3] by one person while
others supported by multiple people (DATESTAMP) are dragged out
endlessly[4].

We only have one of the above changes in the catalog.

There are other examples of what I mean by 'closed' here but I think
the above highlights perfectly what I mean.

When the code is developed in the open, by any member that cares to
work on it, implementing agreed upon (functional) changes, we'll have
a good start at the required level of openness.  When we set things up
so that no single person is "more equal" we'll be in great shape.

The new tools are already fully open and available for all.  The new
work flow addresses the second issue.

> > When many people want things a certain way but one doesn't and
> > that one can block packages, there is a glaring deficiency. ?We're
> > addressing this problem.
> 
> it already has been addressed. multiple times, as mentioned above. A
> vote on the specific issue can always be taken.  This seems more
> about maintainer impatience than anything else.

It's good that we're voting on issues now.  I'm glad to see that in
every case changes were implemented when forced with the vote.

The problem is that we shouldn't need to force this every time.  In a
healthy situation, people would see when they're the only one against
a particular change.  That's not the case in the majority of issues
raised.

OpenCSW is supposed to be a collaborative effort.  For the most part
it is.  There is one area where the collaboration continuously breaks
down.  Time to grease the squeaky wheel.

I think the current process is broken and that the new one is a better
way forward.  I can't state it more plainly than that.

I'm going to excuse myself from the remainder of this thread unless
others raise questions or concerns that I can provide useful feedback
to.  There is no point in me reiterating my position further.

Thanks
-Ben

[1] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-May/002769.html
[2] http://wiki.opencsw.org/release-process
[3] http://lists.opencsw.org/pipermail/maintainers/2010-October/012950.html
[4] http://lists.opencsw.org/pipermail/maintainers/2011-April/014447.html
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Wed May 18 16:00:12 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 18 May 2011 07:00:12 -0700
Subject: [csw-maintainers] discussion: optional config files in etc
In-Reply-To: <8C9DF81D-34BF-42C2-ADEB-EBE68A8298C0@opencsw.org>
References: <BANLkTi=SSx1pRGFSRrg=3HcJ0spZxNo1Rg@mail.gmail.com>
	<8C9DF81D-34BF-42C2-ADEB-EBE68A8298C0@opencsw.org>
Message-ID: <BANLkTinPyZAw56gnwA0BjmVa52F8iKM_bQ@mail.gmail.com>

On Tue, May 17, 2011 at 8:29 AM, Geoff Davis <gadavis at opencsw.org> wrote:
> I hate to split hairs on this, but it really does depend on the program in question. I'd say leave it up to the package maintainer to make the call.


Something that I'm not opposed to... I'm in favor of maintainers
carefully considering each package in depth :)
But what guidelines would you suggest they use, to decide if they do,
vs dont, ship it in /opt/csw/etc if it is not normally needed?


/etc is hardly pristine on Solaris as shipped from Oracle, with the
legacy symbolic links to system binaries and all.

well, isnt it nice that OUR etc is not so cluttered as that?
Seems to me it would be nice to keep it that way.

From phil at bolthole.com  Wed May 18 19:07:42 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 18 May 2011 10:07:42 -0700
Subject: [csw-maintainers] introducing csw-upload-pkg
In-Reply-To: <1305678624-sup-43@pinkfloyd.chass.utoronto.ca>
References: <1304553260-sup-5157@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=0wMizKOQSheUT-0e6obNGepxo3Q@mail.gmail.com>
	<1304616522-sup-8705@pinkfloyd.chass.utoronto.ca>
	<BANLkTikJbtmrVx-Jb7sieGjUk0i50cEZ4g@mail.gmail.com>
	<1304859824-sup-4420@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWh=WR98OMSENjWrwH4ASyH9M6+g@mail.gmail.com>
	<1304961557-sup-5206@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Rym0HhbSxqMHg_JSVzN3D2G7ToQ@mail.gmail.com>
	<1305045081-sup-9315@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=sJVbhwBf6DNmGncma_-Rt5H54-w@mail.gmail.com>
	<1305483964-sup-4851@pinkfloyd.chass.utoronto.ca>
	<BANLkTim-YY4q4rED4-VVzzLLcFSdKHdfZQ@mail.gmail.com>
	<1305678624-sup-43@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikbgAU98UG-ZWdR0TYbkp9tAydSSA@mail.gmail.com>

On Tue, May 17, 2011 at 5:44 PM, Ben Walton <bwalton at opencsw.org> wrote:
>....
> Rather, I'm talking about things like changes to catalog format
> (SITEFEATURES) that can be made on a whim[3] by one person while
> others supported by multiple people (DATESTAMP) are dragged out
> endlessly[4].

Cutting the rest of my reply down to a summary here, because this I
think is the crux of basically all the unhappiness about process of
late.

There are only 2 ways to resolve differences in this, and many areas:
1. discussion, until agreement is reached
2. a vote among the appropriate group with responsibility.
  That would be either the entire membership, or a release (manager/group).

You complain about BOTH these things. You complain that discussion
goes on too long.
But you also complain that not everything should be forced to a vote.

I'll point the failings in both of these complaints together, because
they are related:
When people complain that "discussion has gone on too long", but they
also dont want to vote on it, that is usually a sign that they have
run out of anything to support their position. This means that *they*
are clinging to a personal preference, without supporting fact. A
reasonable person would concede the point. But they want their way, so
they complain 'this is not going anywhere', by which they mean, "I
cant see any route to GET MY WAY!!!" and so they stop participating in
the discussion.

When was the last time I blocked a vote on an issue?
Compared to the last time other people blocked one?

I'm not the one insisting on getting my way here. I am always open to
the voting process. I've shown myself to consistently be more open to
"democratic process" than most of the vocally unhappy people

Anyone who claims they want things to be "more open and equal to all
maintainers", but yet stands in the way of all maintainers voting on
issues, is a hypocrite.



> The problem is that we shouldn't need to force this every time. ?In a
> healthy situation, people would see when they're the only one against
> a particular change. ?That's not the case in the majority of issues
> raised.

There is a big difference between "the only person with a particular
opinion, in the handful who are bothering to read the issue", and "the
only *maintainer* who cares about the issue."
The first situation, does not prove the second one. Only a vote does.

Going by what you suggest, basically means that a vocal minority of 2
or 3 people can undemocratically control the flow of most everything
in opencsw, because they are the ones that bother to read and reply
regularly on the various mailing lists.

Now, dont get me wrong: "those who pay attention, get to run things",
is one valid way to run an organization.

But it is **not** "democratic".

Either opencsw is "a democratic organization, where issues are decided
by all voting members",
or it is an organization where the only thing that matters is which
group of people is most active on the mailing lists.

PICK ONE OR THE OTHER, MAKE IT WRITTEN POLICY, AND STICK TO IT.

From phil at bolthole.com  Wed May 18 19:23:51 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 18 May 2011 10:23:51 -0700
Subject: [csw-maintainers] catalog date announcement
Message-ID: <BANLkTi=MX0E_bVCM_m9Tb7Lhg8S4snmVkg@mail.gmail.com>

I was recently falsely accused of "dragging out the discussion on a
timestamp for our catalog, 'endlessly' "
This is completely untrue.  The truth is, the discussion had
appropriately run its course, and a consensus had pretty much been
reached.

I had just sent a final email, asking that the last person who had an
issue with the format, confirm that it was okay.
http://lists.opencsw.org/pipermail/maintainers/2011-April/014508.html

Please note that, rather than me blocking things from progressing, or
doing things on my own,  I was actually attempting to confirm
consensus, before proceeding.
I was relying getting a reply to that, to be the trigger for actually
implementing it.
Unfortunately, I never received a reply,and had forgotten about it until now.

So at this point, 3 weeks later,  I will take "no reply", as a go ahead.
>From now on, as negotiated in the thread above, the first line of our
catalog will be of the format

# CREATIONDATE 2011-04-21T20:10:46Z

From maciej at opencsw.org  Fri May 20 09:50:04 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Fri, 20 May 2011 08:50:04 +0100
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <BANLkTim2FJBQG-3OD0ATaTE_4+n39Zbq_g@mail.gmail.com>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
	<BANLkTim2FJBQG-3OD0ATaTE_4+n39Zbq_g@mail.gmail.com>
Message-ID: <BANLkTi=MDSn084wuOL0pUb1UKK7vA2Ytjg@mail.gmail.com>

2011/5/17 Peter Bonivart <bonivart at opencsw.org>:
> On Tue, May 17, 2011 at 8:05 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> I thought submitpkg already had a trigger in it refusing to submit
>> uncommitted packages?
>
> I think that only looks at the filename (!CSW).

Yes, there are separate checks performed on package contents, and on
file names.  There was a check for the file name, but not for the
OPENCSW_REPOSITORY entry in pkginfo.

r14626 adds a check for pkginfo.  I wasn't sure how strict the check
should be, so for starters, there are 2 things required:

1. pkginfo should contain the OPENCSW_REPOSITORY entry
2. the entry should not contain the UNCOMMITTED tag

Maciej

http://sourceforge.net/apps/trac/gar/changeset/14626

From ellson at opencsw.org  Fri May 20 18:31:16 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 20 May 2011 12:31:16 -0400
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc ?
Message-ID: <4DD69754.9090007@opencsw.org>

I'm having a hard time getting graphviz-2.28 to build on current9s.

The latest problem is with installed perl headers, outside of my ability
to fix:

    CXX    libgv_perl_la-gv_perl.lo
    CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
ignored otherwise
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 38: Warning: attribute
nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 43: Warning: attribute
nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 48: Warning: attribute
nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 53: Warning: attribute
nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 58: Warning: attribute
nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 67: Warning: attribute
nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 90: Warning: attribute
__malloc__ is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 94: Warning: attribute
__malloc__ is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 98: Warning: attribute
__malloc__ is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 118: Warning:
attribute nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 129: Warning:
attribute nonnull is unsupported and will be skipped..
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 130: Error: "{"
expected instead of "(".
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 130: Error: The
function "nonnull" must have a prototype.
    "/opt/csw/lib/perl/5.10.1/CORE/proto.h", line 134: Error: Linkage
specifications are allowed only at file level.
    ...


My guess is that I won't get this problem if I build with gcc, instead
of /opt/SUNWspro/bin/cc

Is that permitted for OpenCSW builds?   If so, where can I find a recent
gcc installed?

John

From phil at bolthole.com  Fri May 20 18:44:30 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 20 May 2011 09:44:30 -0700
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4DD69754.9090007@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
Message-ID: <BANLkTinV3jDgzSSOwtBuTAKeJoKpHs_SQQ@mail.gmail.com>

On Fri, May 20, 2011 at 9:31 AM, John Ellson <ellson at opencsw.org> wrote:
> I'm having a hard time getting graphviz-2.28 to build on current9s.
>
> The latest problem is with installed perl headers, outside of my ability
> to fix:

This raises a couple of questions, which are directly related to your
issue, and anyone else using perl modules:

1. Did we stop supporting sun cc, for perl modules?
2. If not, then isnt this clearly a bug, that needs to be fixed by the
appropriate maintainer?



More general answer to you:

> My guess is that I won't get this problem if I build with gcc, instead
> of /opt/SUNWspro/bin/cc
>
> Is that permitted for OpenCSW builds?

It's okay, so long as sun cc has been show to be an unreasonable
hinderance to compiling.
In this case, it's probably best to wait for that installed package to
get fixed, if it's going to be fixed.

From Joerg.Schilling at fokus.fraunhofer.de  Fri May 20 19:00:44 2011
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Fri, 20 May 2011 19:00:44 +0200
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4DD69754.9090007@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
Message-ID: <4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>

John Ellson <ellson at opencsw.org> wrote:

> I'm having a hard time getting graphviz-2.28 to build on current9s.
>
> The latest problem is with installed perl headers, outside of my ability
> to fix:
>
>     CXX    libgv_perl_la-gv_perl.lo
>     CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
> ignored otherwise

Are you compiling C++?

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 ellson at opencsw.org  Fri May 20 19:07:43 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 20 May 2011 13:07:43 -0400
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
 ?
In-Reply-To: <4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <4DD69FDF.2060006@opencsw.org>

On 05/20/2011 01:00 PM, Joerg Schilling wrote:
> John Ellson <ellson at opencsw.org> wrote:
>
>> I'm having a hard time getting graphviz-2.28 to build on current9s.
>>
>> The latest problem is with installed perl headers, outside of my ability
>> to fix:
>>
>>     CXX    libgv_perl_la-gv_perl.lo
>>     CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
>> ignored otherwise
> Are you compiling C++?
>
> J?rg
>

Oh! yes, thats right.   I'm compiling against a swig generated wrapper
of a thin C++ layer.

./configure is finding:

CXX='/opt/SUNWspro/bin/CC'



I generated Mantis report #0004771 -  I'll update with this info.

John


From ellson at opencsw.org  Fri May 20 19:12:13 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 20 May 2011 13:12:13 -0400
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
 ?
In-Reply-To: <BANLkTinV3jDgzSSOwtBuTAKeJoKpHs_SQQ@mail.gmail.com>
References: <4DD69754.9090007@opencsw.org>
	<BANLkTinV3jDgzSSOwtBuTAKeJoKpHs_SQQ@mail.gmail.com>
Message-ID: <4DD6A0ED.3040302@opencsw.org>

Perl header problem reported in Mantis #0004771

John



On 05/20/2011 12:44 PM, Philip Brown wrote:
> On Fri, May 20, 2011 at 9:31 AM, John Ellson <ellson at opencsw.org> wrote:
>> I'm having a hard time getting graphviz-2.28 to build on current9s.
>>
>> The latest problem is with installed perl headers, outside of my ability
>> to fix:
> This raises a couple of questions, which are directly related to your
> issue, and anyone else using perl modules:
>
> 1. Did we stop supporting sun cc, for perl modules?
> 2. If not, then isnt this clearly a bug, that needs to be fixed by the
> appropriate maintainer?
>
>
>
> More general answer to you:
>
>> My guess is that I won't get this problem if I build with gcc, instead
>> of /opt/SUNWspro/bin/cc
>>
>> Is that permitted for OpenCSW builds?
> It's okay, so long as sun cc has been show to be an unreasonable
> hinderance to compiling.
> In this case, it's probably best to wait for that installed package to
> get fixed, if it's going to be fixed.
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>


From phil at bolthole.com  Fri May 20 19:12:49 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 20 May 2011 10:12:49 -0700
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4DD69FDF.2060006@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD69FDF.2060006@opencsw.org>
Message-ID: <BANLkTi=mOE8K6eyyZbPmzLAHbVUmE_Xauw@mail.gmail.com>

On Fri, May 20, 2011 at 10:07 AM, John Ellson <ellson at opencsw.org> wrote:
> On 05/20/2011 01:00 PM, Joerg Schilling wrote:
>> John Ellson <ellson at opencsw.org> wrote:
>>
>>> I'm having a hard time getting graphviz-2.28 to build on current9s.
>>>
>>> The latest problem is with installed perl headers, outside of my ability
>>> to fix:
>>>
>>> ? ? CXX ? ?libgv_perl_la-gv_perl.lo
>>> ? ? CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
>>> ignored otherwise
>> Are you compiling C++?
>>
>> J?rg
>>
>
> Oh! yes, thats right. ? I'm compiling against a swig generated wrapper
> of a thin C++ layer.
>
> ./configure is finding:
>
> CXX='/opt/SUNWspro/bin/CC'
>
>

Good catch, J?rg

So, the likely case is:

- the perl stuff is just fine
- whatever you are compiling, has not properly declared
   extern "C" {
     #include "perl-stuffs-here"
  }

From Joerg.Schilling at fokus.fraunhofer.de  Fri May 20 19:15:23 2011
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Fri, 20 May 2011 19:15:23 +0200
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4DD69FDF.2060006@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD69FDF.2060006@opencsw.org>
Message-ID: <4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>

John Ellson <ellson at opencsw.org> wrote:

> On 05/20/2011 01:00 PM, Joerg Schilling wrote:
> > John Ellson <ellson at opencsw.org> wrote:
> >
> >> I'm having a hard time getting graphviz-2.28 to build on current9s.
> >>
> >> The latest problem is with installed perl headers, outside of my ability
> >> to fix:
> >>
> >>     CXX    libgv_perl_la-gv_perl.lo
> >>     CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
> >> ignored otherwise
> > Are you compiling C++?
> >
> > J?rg
> >
>
> Oh! yes, thats right.   I'm compiling against a swig generated wrapper
> of a thin C++ layer.
>
> ./configure is finding:
>
> CXX='/opt/SUNWspro/bin/CC'

Well, CC does not support -xnorunpath and the build system of your software 
should know this if it supports Sunpro C.

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 ellson at opencsw.org  Fri May 20 19:54:41 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 20 May 2011 13:54:41 -0400
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
 ?
In-Reply-To: <4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
References: <4DD69754.9090007@opencsw.org>	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>	<4DD69FDF.2060006@opencsw.org>
	<4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <4DD6AAE1.5050703@opencsw.org>

On 05/20/2011 01:15 PM, Joerg Schilling wrote:
>
> Well, CC does not support -xnorunpath and the build system of your software 
> should know this if it supports Sunpro C.
>
> J?rg
>

"norunpath" is not coming from anything in the graphviz sources.  It
looks like it is coming from gar  ?

$ pwd
/home/ellson/mgar/pkg/graphviz/trunk
$ grep norunpath * */* */*/* */*/*/*
gar/categories/x11/category.mk:_CATEGORY_CXXFLAGS_SOS11 = -xlibmil
-xlibmopt -features=tmplife -norunpath
gar/categories/x11/category.mk:_CATEGORY_CXXFLAGS_SOS12 = -xlibmil
-xlibmopt -features=tmplife -norunpath
gar/categories/xfce/category.mk:CXXFLAGS += -xlibmil -xlibmopt
-features=tmplife -norunpath

John



From Joerg.Schilling at fokus.fraunhofer.de  Fri May 20 20:12:54 2011
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Fri, 20 May 2011 20:12:54 +0200
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4DD6AAE1.5050703@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD69FDF.2060006@opencsw.org>
	<4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD6AAE1.5050703@opencsw.org>
Message-ID: <4dd6af26.iZ6zgkpTsciAJ3Ku%Joerg.Schilling@fokus.fraunhofer.de>

John Ellson <ellson at opencsw.org> wrote:

> On 05/20/2011 01:15 PM, Joerg Schilling wrote:
> >
> > Well, CC does not support -xnorunpath and the build system of your software 
> > should know this if it supports Sunpro C.
> >
> > J?rg
> >
>
> "norunpath" is not coming from anything in the graphviz sources.  It
> looks like it is coming from gar  ?

If it comes from gar, then I would expect all C++ projects to fail, or do they 
need a special setup?

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 maciej at opencsw.org  Fri May 20 20:59:45 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Fri, 20 May 2011 19:59:45 +0100
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4dd6af26.iZ6zgkpTsciAJ3Ku%Joerg.Schilling@fokus.fraunhofer.de>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD69FDF.2060006@opencsw.org>
	<4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD6AAE1.5050703@opencsw.org>
	<4dd6af26.iZ6zgkpTsciAJ3Ku%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <BANLkTinss1FsXeBsneefPVKzPPWQouyg_g@mail.gmail.com>

2011/5/20 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>:
> If it comes from gar, then I would expect all C++ projects to fail, or do they
> need a special setup?

I think that the breakage occurs only when CFLAGS (instead of
CXXFLAGS) are added to an invocation of a C++ compiler/linker.  It
used to be the case with cups:

https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cups/trunk/files/CFLAGS-leaking-to-C++-compiler.patch

Maciej

From ellson at opencsw.org  Sat May 21 00:28:17 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 20 May 2011 18:28:17 -0400
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
 ?
In-Reply-To: <4dd6af26.iZ6zgkpTsciAJ3Ku%Joerg.Schilling@fokus.fraunhofer.de>
References: <4DD69754.9090007@opencsw.org>	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>	<4DD69FDF.2060006@opencsw.org>	<4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>	<4DD6AAE1.5050703@opencsw.org>
	<4dd6af26.iZ6zgkpTsciAJ3Ku%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <4DD6EB01.5060607@opencsw.org>

On 05/20/2011 02:12 PM, Joerg Schilling wrote:
> John Ellson <ellson at opencsw.org> wrote:
>
>> On 05/20/2011 01:15 PM, Joerg Schilling wrote:
>>> Well, CC does not support -xnorunpath and the build system of your software 
>>> should know this if it supports Sunpro C.
>>>
>>> J?rg
>>>
>> "norunpath" is not coming from anything in the graphviz sources.  It
>> looks like it is coming from gar  ?
> If it comes from gar, then I would expect all C++ projects to fail, or do they 
> need a special setup?
>
> J?rg
>

Perhaps not gar.  This is where "-xnorunpath" is coming from:

   $ /opt/csw/bin/perl -MExtUtils::Embed -e ccopts
   -D_REENTRANT -xO3 -m32 -xarch=v8 -xnorunpath -I/opt/csw/bdb48/include
-I/opt/csw/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/opt/csw/lib/perl/5.10.1/CORE


John

From ellson at opencsw.org  Sat May 21 01:28:25 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 20 May 2011 19:28:25 -0400
Subject: [csw-maintainers] merge issue  for swig-2.0.3
Message-ID: <4DD6F919.9080005@opencsw.org>

So after getting stuck on the graphviz-2.28 perl binding, I was
wondering if it was perhaps a swig issue,
so I started a swig upgrade.... but that dies during the merge phase.

It appears that the merge scripts are not handling filenames with spaces
in them correctly?

See:
   
/home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/pkgroot/opt/csw/share/doc/swig/Examples/test-suite/preproc_include*

Advice please?


-----------------

mkp: exec( pkgmk -d /home/ellson/spool/5.9-sparc -r
/home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/pkgroot -b
/home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/pkgroot -f
/home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/build-global/CSWswig.prototype-sparc
WORKDIR_FIRSTMOD=../build-isa-sparcv8 )
## Building pkgmap from package prototype file.
ERROR in
/home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/build-global/CSWswig.prototype-sparc:
    garbled entry
    - pathname:
/opt/csw/share/doc/swig/Examples/test-suite/preproc_include_d
    - problem: mode string is too long.
pkgmk: ERROR: unable to build pkgmap from prototype file
## Packaging was not successful.
mkp: ERROR:  Failed to create CSWswig using
/home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/build-global/CSWswig.prototype-sparc
gmake: *** [package-CSWswig] Error 2


--------------------------------

John

From maciej at opencsw.org  Sat May 21 12:58:44 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 21 May 2011 11:58:44 +0100
Subject: [csw-maintainers] merge issue for swig-2.0.3
In-Reply-To: <4DD6F919.9080005@opencsw.org>
References: <4DD6F919.9080005@opencsw.org>
Message-ID: <BANLkTi=3QmA3emSMtMSW_cqH96+X0OP6kw@mail.gmail.com>

2011/5/21 John Ellson <ellson at opencsw.org>:
> So after getting stuck on the graphviz-2.28 perl binding, I was
> wondering if it was perhaps a swig issue,
> so I started a swig upgrade.... but that dies during the merge phase.
>
> It appears that the merge scripts are not handling filenames with spaces
> in them correctly?
>
> See:
>
> /home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/pkgroot/opt/csw/share/doc/swig/Examples/test-suite/preproc_include*
>
> Advice please?

I think that it's the native Solaris packaging system that is unable
to handle file names with spaces.

http://sourceforge.net/apps/trac/gar/changeset/14632

After excluding these files from the merge phase, pkgmk completes successfully.

Maciej

From dam at opencsw.org  Sat May 21 14:16:32 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 21 May 2011 14:16:32 +0200
Subject: [csw-maintainers] can I use gcc instead of /opt/SUNWspro/bin/cc
	?
In-Reply-To: <4DD69754.9090007@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
Message-ID: <B45A3B2F-F844-4A1A-8377-17D53C7041BC@opencsw.org>

Hi John,

Am 20.05.2011 um 18:31 schrieb John Ellson:
> I'm having a hard time getting graphviz-2.28 to build on current9s.
> 
> The latest problem is with installed perl headers, outside of my ability
> to fix:
> 
>    CXX    libgv_perl_la-gv_perl.lo
>    CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
> ignored otherwise
>    ...
> 
> My guess is that I won't get this problem if I build with gcc, instead
> of /opt/SUNWspro/bin/cc
> 
> Is that permitted for OpenCSW builds?

It is permitted, but discouraged.

> If so, where can I find a recent gcc installed?

You can just set
  GARCOMPILER = GCC  (whatever is newest)
or
  GARCOMPILER = GCC3 / GCC4 (if you need a specific version)

The install locations on the farm are documented on "login" in /etc/SETUP.


Best regards

  -- Dago

From dam at opencsw.org  Sat May 21 14:22:26 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 21 May 2011 14:22:26 +0200
Subject: [csw-maintainers] -norunpath and -xnorunpath
In-Reply-To: <4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD69FDF.2060006@opencsw.org>
	<4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <0F27B157-93AB-48E5-A7EB-E357EF20261A@opencsw.org>

Hi,

Am 20.05.2011 um 19:15 schrieb Joerg Schilling:
> John Ellson <ellson at opencsw.org> wrote:
>> On 05/20/2011 01:00 PM, Joerg Schilling wrote:
>>> John Ellson <ellson at opencsw.org> wrote:
>>> 
>>>> I'm having a hard time getting graphviz-2.28 to build on current9s.
>>>> 
>>>> The latest problem is with installed perl headers, outside of my ability
>>>> to fix:
>>>> 
>>>>    CXX    libgv_perl_la-gv_perl.lo
>>>>    CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
>>>> ignored otherwise
>>> Are you compiling C++?
>>> 
>>> J?rg
>>> 
>> 
>> Oh! yes, thats right.   I'm compiling against a swig generated wrapper
>> of a thin C++ layer.
>> 
>> ./configure is finding:
>> 
>> CXX='/opt/SUNWspro/bin/CC'
> 
> Well, CC does not support -xnorunpath and the build system of your software 
> should know this if it supports Sunpro C.

Don't let this fool you. -xnorunpath has nothing to do with Johns
problems. cc and CC take different flags to not include runpathes:
-xnorunpath for cc and -norunpath for CC. As they are linker flags
they should be in LDFLAGS. However, the use of LDFLAGS is not compiler
specific. As some programs link with cc and some with CC I tried at
one point to just put both in there and ignore the warning. However,
there are certain cases where LDFLAGS is passed to libtool causing
real errors so I took it out and now require explicit addition
in GAR as EXTRA_LINKER_FLAGS after encountering the problem and
manually setting the flag to the correct value.

The issue arose between r9383 and r13727 as documented at the bottom of
  http://sourceforge.net/apps/trac/gar/

The change was accounted in March:
  http://lists.opencsw.org/pipermail/maintainers/2011-March/014334.html

Best regards

  -- Dago

From dam at opencsw.org  Sat May 21 14:32:15 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 21 May 2011 14:32:15 +0200
Subject: [csw-maintainers] Spaces in the prototype
In-Reply-To: <BANLkTi=3QmA3emSMtMSW_cqH96+X0OP6kw@mail.gmail.com>
References: <4DD6F919.9080005@opencsw.org>
	<BANLkTi=3QmA3emSMtMSW_cqH96+X0OP6kw@mail.gmail.com>
Message-ID: <6D22DC44-831D-4EB6-9922-F26C62500294@opencsw.org>

Hi,

Am 21.05.2011 um 12:58 schrieb Maciej Blizi?ski:
> 2011/5/21 John Ellson <ellson at opencsw.org>:
>> So after getting stuck on the graphviz-2.28 perl binding, I was
>> wondering if it was perhaps a swig issue,
>> so I started a swig upgrade.... but that dies during the merge phase.

The merge phase worked perfectly. This is in the invocation of 'pkgmk'.

>> It appears that the merge scripts are not handling filenames with spaces
>> in them correctly?
>> 
>> See:
>> 
>> /home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/pkgroot/opt/csw/share/doc/swig/Examples/test-suite/preproc_include*
>> 
>> Advice please?
> 
> I think that it's the native Solaris packaging system that is unable
> to handle file names with spaces.
> 
> http://sourceforge.net/apps/trac/gar/changeset/14632
> 
> After excluding these files from the merge phase, pkgmk completes successfully.

No need to exclude them. You can use this snippet to replace spaces with '_':
  http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/adobereader/trunk/Makefile#L65
The ultimate solution would be a specific class action undoinng the substitution on install,
but I never ancountered a case where this was really necessary.


Best regards

  -- Dago

From ellson at opencsw.org  Sat May 21 14:43:13 2011
From: ellson at opencsw.org (John Ellson)
Date: Sat, 21 May 2011 08:43:13 -0400
Subject: [csw-maintainers] Spaces in the prototype
In-Reply-To: <6D22DC44-831D-4EB6-9922-F26C62500294@opencsw.org>
References: <4DD6F919.9080005@opencsw.org>	<BANLkTi=3QmA3emSMtMSW_cqH96+X0OP6kw@mail.gmail.com>
	<6D22DC44-831D-4EB6-9922-F26C62500294@opencsw.org>
Message-ID: <4DD7B361.5030408@opencsw.org>

On 05/21/2011 08:32 AM, Dagobert Michelsen wrote:
> Hi,
>
> Am 21.05.2011 um 12:58 schrieb Maciej Blizi?ski:
>> 2011/5/21 John Ellson <ellson at opencsw.org>:
>>> So after getting stuck on the graphviz-2.28 perl binding, I was
>>> wondering if it was perhaps a swig issue,
>>> so I started a swig upgrade.... but that dies during the merge phase.
> The merge phase worked perfectly. This is in the invocation of 'pkgmk'.
>
>>> It appears that the merge scripts are not handling filenames with spaces
>>> in them correctly?
>>>
>>> See:
>>>
>>> /home/ellson/mgar/pkg/swig/trunk/work/solaris9-sparc/pkgroot/opt/csw/share/doc/swig/Examples/test-suite/preproc_include*
>>>
>>> Advice please?
>> I think that it's the native Solaris packaging system that is unable
>> to handle file names with spaces.
>>
>> http://sourceforge.net/apps/trac/gar/changeset/14632
>>
>> After excluding these files from the merge phase, pkgmk completes successfully.
> No need to exclude them. You can use this snippet to replace spaces with '_':
>   http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/adobereader/trunk/Makefile#L65
> The ultimate solution would be a specific class action undoinng the substitution on install,
> but I never ancountered a case where this was really necessary.

Well, just changing them to '_' kind of misses the point that these
test-suite files are tests for spaces in filenames.

I think I'll just leave these tests excluded for now.   


Should I generate a Mantis report against pkgmk ?


John

From maciej at opencsw.org  Sat May 21 15:06:58 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 21 May 2011 14:06:58 +0100
Subject: [csw-maintainers] Spaces in the prototype
In-Reply-To: <4DD7B361.5030408@opencsw.org>
References: <4DD6F919.9080005@opencsw.org>
	<BANLkTi=3QmA3emSMtMSW_cqH96+X0OP6kw@mail.gmail.com>
	<6D22DC44-831D-4EB6-9922-F26C62500294@opencsw.org>
	<4DD7B361.5030408@opencsw.org>
Message-ID: <BANLkTi=+XycLrcbxH6JjCdn=AsWFJq8chQ@mail.gmail.com>

2011/5/21 John Ellson <ellson at opencsw.org>:
> Should I generate a Mantis report against pkgmk ?

It's a native Solaris tool, the best you could do is trying your luck
with Oracle.

Maciej

From maciej at opencsw.org  Sat May 21 16:03:10 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 21 May 2011 15:03:10 +0100
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <BANLkTi=MDSn084wuOL0pUb1UKK7vA2Ytjg@mail.gmail.com>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
	<BANLkTim2FJBQG-3OD0ATaTE_4+n39Zbq_g@mail.gmail.com>
	<BANLkTi=MDSn084wuOL0pUb1UKK7vA2Ytjg@mail.gmail.com>
Message-ID: <BANLkTikFdO=AzMx=AGa+5G2NPnNiHYV0_Q@mail.gmail.com>

2011/5/20 Maciej Blizi?ski <maciej at opencsw.org>:
> 1. pkginfo should contain the OPENCSW_REPOSITORY entry
> 2. the entry should not contain the UNCOMMITTED tag

This check might be slightly annoying in day to day work.  Until the
package that is worked on, is built from committed sources, checkpkg
will display the error.  Maintainers will always see at least one
error from checkpkg when working on a package.

Maciej

From phil at bolthole.com  Sat May 21 16:22:46 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 21 May 2011 07:22:46 -0700
Subject: [csw-maintainers] -norunpath and -xnorunpath
In-Reply-To: <0F27B157-93AB-48E5-A7EB-E357EF20261A@opencsw.org>
References: <4DD69754.9090007@opencsw.org>
	<4dd69e3c.HaSJjJWo8J7p1z+V%Joerg.Schilling@fokus.fraunhofer.de>
	<4DD69FDF.2060006@opencsw.org>
	<4dd6a1ab.q/QDMbEUk269rMU0%Joerg.Schilling@fokus.fraunhofer.de>
	<0F27B157-93AB-48E5-A7EB-E357EF20261A@opencsw.org>
Message-ID: <BANLkTin3f=GN0Aw5-SjigMB==KV9rhuj9A@mail.gmail.com>

On Sat, May 21, 2011 at 5:22 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
>>
> Don't let this fool you. -xnorunpath has nothing to do with Johns
> problems. cc and CC take different flags to not include runpathes:
> -xnorunpath for cc and -norunpath for CC. As they are linker flags
> they should be in LDFLAGS.

no, they are not linker flags. they are compiler flags. "the linker" is "ld".
"LDFLAGS", is really supposed to only be used when calling "ld" directly.

That's why in the last 10 years or so, GNU stuff is tending to support
things like "CCLDFLAGS", and "CXXLDFLAGS"

From ellson at opencsw.org  Sat May 21 16:36:50 2011
From: ellson at opencsw.org (John Ellson)
Date: Sat, 21 May 2011 10:36:50 -0400
Subject: [csw-maintainers] swig-2.0.3
Message-ID: <4DD7CE02.8050600@opencsw.org>

I pushed swig-2.0.3 to unstable using the process described in:

    http://wiki.opencsw.org/automated-release-process

and using the command:

    /home/ellson/mgar/pkg/swig/trunk/gar/bin/csw-upload-pkg \
       
/home/ellson/newpkgs/swig-2.0.3\,REV\=2011.05.21-SunOS5.9-i386-CSW.pkg.gz \
       
/home/ellson/newpkgs/swig-2.0.3\,REV\=2011.05.21-SunOS5.9-sparc-CSW.pkg.gz

I hope I did that right?


Will this new version of swig be available on the build hosts soon?   
I'd like to see if it solves the graphviz-2.28 problem with the
swig-generated perl binding.


John

From maciej at opencsw.org  Sat May 21 17:00:55 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 21 May 2011 16:00:55 +0100
Subject: [csw-maintainers] swig-2.0.3
In-Reply-To: <4DD7CE02.8050600@opencsw.org>
References: <4DD7CE02.8050600@opencsw.org>
Message-ID: <BANLkTinjAWer12mGk9Ut2jTv9uhuxDknWw@mail.gmail.com>

2011/5/21 John Ellson <ellson at opencsw.org>:
> I pushed swig-2.0.3 to unstable using the process described in:
>
> ? ?http://wiki.opencsw.org/automated-release-process
>
> and using the command:
>
> ? ?/home/ellson/mgar/pkg/swig/trunk/gar/bin/csw-upload-pkg \
>
> /home/ellson/newpkgs/swig-2.0.3\,REV\=2011.05.21-SunOS5.9-i386-CSW.pkg.gz \
>
> /home/ellson/newpkgs/swig-2.0.3\,REV\=2011.05.21-SunOS5.9-sparc-CSW.pkg.gz
>
> I hope I did that right?

Looks good!

> Will this new version of swig be available on the build hosts soon?
> I'd like to see if it solves the graphviz-2.28 problem with the
> swig-generated perl binding.

Here's how to go about it: You will get an email notification when the
updated swig is available from the mirror.  Once receive that email,
you can send a request to buildfarm@ to install the updated swig on
unstable9{s,x} hosts.  When they are installed you can ssh to
unstable9s or unstable9x and work there.

To get the new swig installed on current9{s,x}, your packages will
need to go through the old process.

Maciej

From ihsan at opencsw.org  Wed May 25 16:11:48 2011
From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=)
Date: Wed, 25 May 2011 16:11:48 +0200
Subject: [csw-maintainers] Forum Software
Message-ID: <4DDD0E24.6010907@opencsw.org>

Hi guys,

As discussed on the IRC, I'm currently working on a forum for OpenCSW. 
I've did a test installation of the most recent phpBB version, but I'm 
not happy with it. Somehow I don't like the software.

Does someone has already experience with forum software and can 
recommend me a good alternative to phpBB?




Ihsan

-- 
ihsan at dogan.ch		http://blog.dogan.ch/

From bonivart at opencsw.org  Wed May 25 18:05:27 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 25 May 2011 18:05:27 +0200
Subject: [csw-maintainers] Fwd: [csw-users] GCC 4.3.3 Question
In-Reply-To: <B8ADB9DA2FFB574188E2D75B43246131A76D32@corpatsmail4.corp.sensis.com>
References: <B8ADB9DA2FFB574188E2D75B43246131A76D32@corpatsmail4.corp.sensis.com>
Message-ID: <BANLkTi=mvJ=HG2UUUxavqT5uh5BV14Hpng@mail.gmail.com>

FYI

---------- Forwarded message ----------
From: Kapoor, Nitin <Nitin.Kapoor at sensis.com>
Date: Wed, May 25, 2011 at 5:11 PM
Subject: [csw-users] GCC 4.3.3 Question
To: users at lists.opencsw.org


Hi All ,



If this is not the right location for this post please let me know
where to post this message.

I am running Solaris 10 and using GCC version 4.3.3 downloaded from OpenCSW.



What I am trying to find out is? whether the following bug:



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024



is fixed in the GCC 4.3.3 that I downloaded using pkg-get from
OpenCSW ? Because my GCC compiled applications are behaving the same
way as described by the bug description.



-bash-3.00$ g++ --v



Using built-in specs.

Target: sparc-sun-solaris2.8



Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4

--exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas

--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls

--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x

--with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib

--enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix

--enable-stage1-languages=c

--enable-languages=ada,c,c++,fortran,java,objc



Thread model: posix

gcc version 4.3.3 (GCC)



Thanks,



NitinK.



This message is intended only for the addressee and may contain
information that is company confidential or privileged. Any technical
data in this message may be exported only in accordance with the U.S.
International Traffic in Arms Regulations (22 CFR Parts 120-130) or
the Export Administration Regulations (15 CFR Parts 730-774).
Unauthorized use is strictly prohibited and may be unlawful. If you
are not the intended recipient, or the person responsible for
delivering to the intended recipient, you should not read, copy,
disclose or otherwise use this message. If you have received this
email in error, please delete it, and advise the sender immediately.
_______________________________________________
users mailing list
users at lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/users

From skayser at opencsw.org  Wed May 25 18:43:48 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Wed, 25 May 2011 18:43:48 +0200
Subject: [csw-maintainers] Forum Software
In-Reply-To: <4DDD0E24.6010907@opencsw.org>
References: <4DDD0E24.6010907@opencsw.org>
Message-ID: <20110525164348.GG11519@sebastiankayser.de>

* ??hsan Do??an <ihsan at opencsw.org> wrote:
> As discussed on the IRC, I'm currently working on a forum for OpenCSW. 
> I've did a test installation of the most recent phpBB version, but I'm 
> not happy with it. Somehow I don't like the software.
> 
> Does someone has already experience with forum software and can 
> recommend me a good alternative to phpBB?

During winter camp Maciej mentioned Vanilla which seems loosely modelled
after Stackoverflow [1,2]. From looking at it briefly, it feels more
like the 21th century than traditional forums. That's only the user side
though, not the admin perspective.

Sebastian

[1] http://wiki.opencsw.org/wintercamp-2011#toc6
[2] http://vanillaforums.org/

From phil at bolthole.com  Wed May 25 19:17:38 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 25 May 2011 10:17:38 -0700
Subject: [csw-maintainers] Fwd: [csw-users] GCC 4.3.3 Question
In-Reply-To: <BANLkTi=mvJ=HG2UUUxavqT5uh5BV14Hpng@mail.gmail.com>
References: <B8ADB9DA2FFB574188E2D75B43246131A76D32@corpatsmail4.corp.sensis.com>
	<BANLkTi=mvJ=HG2UUUxavqT5uh5BV14Hpng@mail.gmail.com>
Message-ID: <BANLkTi=DiRwmGdcO=yEf7G+RP9mHuVgk9w@mail.gmail.com>

On Wed, May 25, 2011 at 9:05 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> FYI
>
> ---------- Forwarded message ----------
> From: Kapoor, Nitin <Nitin.Kapoor at sensis.com>
>
>.....
>
> What I am trying to find out is? whether the following bug:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
>
> is fixed in the GCC 4.3.3 that I downloaded using pkg-get from
> OpenCSW ? Because my GCC compiled applications are behaving the same
> way as described by the bug description.
>....


I think this is basically a roundabout way of saying, "we need our
gcc4 to be upgraded to 4.3.4 or newer."

Unfortunately, it was last compiled by Mike Watters, who has retired.
It is now 2 years old.

Anyone willing to take it over?

From bwalton at opencsw.org  Wed May 25 19:20:46 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 25 May 2011 13:20:46 -0400
Subject: [csw-maintainers] Fwd: [csw-users] GCC 4.3.3 Question
In-Reply-To: <BANLkTi=DiRwmGdcO=yEf7G+RP9mHuVgk9w@mail.gmail.com>
References: <B8ADB9DA2FFB574188E2D75B43246131A76D32@corpatsmail4.corp.sensis.com>
	<BANLkTi=mvJ=HG2UUUxavqT5uh5BV14Hpng@mail.gmail.com>
	<BANLkTi=DiRwmGdcO=yEf7G+RP9mHuVgk9w@mail.gmail.com>
Message-ID: <1306343971-sup-217@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed May 25 13:17:38 -0400 2011:

> Anyone willing to take it over?

I already poked things a bit.  It's not a simple version bump as some
of the deps (libgmp and ???) require updates too.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From ellson at opencsw.org  Wed May 25 22:12:18 2011
From: ellson at opencsw.org (John Ellson)
Date: Wed, 25 May 2011 16:12:18 -0400
Subject: [csw-maintainers] howto use unstable9s instead of current9s ?
Message-ID: <4DDD62A2.8090702@opencsw.org>

I've tried adding (from:
http://sourceforge.net/apps/trac/gar/wiki/Platforms ) :   
   

	BUILDHOST_sparc-32 = unstable9s
	BUILDHOST_sparc-64 = unstable9s
	BUILDHOST_i386-32  = unstable9x
	BUILDHOST_i386-64  = unstable10x

	define modulation2host
	$(BUILDHOST_$(GARCH)-$(MEMORYMODEL_$(ISA)))
	endef

but still my buildit.sh script goes to current9s

	#!/usr/bin/ksh

	if [ -z $1 ]
	        then 
	        print "Usage: $0 package"
	        exit
	fi

	# Ref: http://sourceforge.net/apps/trac/gar/wiki/Platforms

	cd mgar/pkg/$1/trunk
	gmake spotless
	gmake platforms


What am I missing please?

John


From ellson at opencsw.org  Wed May 25 23:34:14 2011
From: ellson at opencsw.org (John Ellson)
Date: Wed, 25 May 2011 17:34:14 -0400
Subject: [csw-maintainers] graphviz-2.28 status.
Message-ID: <4DDD75D6.40708@opencsw.org>

It seems that the perl issue I was having is resolved by using a newer
version of swig.  I've marked Mantis#0004771 as resolved.

So now, to finish the graphviz-2.28 upgrade, as I understand it, I need to:

    - post swig-2.0.3

        [ Please remind me.  Do I do a:
                submitpkg ~/newpkgs/swig-2.0.3*
         ? ]

    - wait for swig-2.0.3 on current* build hosts

    - build graphviz-2.28 using current* build hosts

    - post graphviz-2.28

Is that the best plan?

John

From maciej at opencsw.org  Thu May 26 01:14:00 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 26 May 2011 00:14:00 +0100
Subject: [csw-maintainers] howto use unstable9s instead of current9s ?
In-Reply-To: <4DDD62A2.8090702@opencsw.org>
References: <4DDD62A2.8090702@opencsw.org>
Message-ID: <BANLkTi=pyhyttt8j5mtRXDytyeHwmaLspw@mail.gmail.com>

2011/5/25 John Ellson <ellson at opencsw.org>:
> I've tried adding (from:
> http://sourceforge.net/apps/trac/gar/wiki/Platforms ) :
>
>
> ? ? ? ?BUILDHOST_sparc-32 = unstable9s
> ? ? ? ?BUILDHOST_sparc-64 = unstable9s
> ? ? ? ?BUILDHOST_i386-32 ?= unstable9x
> ? ? ? ?BUILDHOST_i386-64 ?= unstable10x
>
> ? ? ? ?define modulation2host
> ? ? ? ?$(BUILDHOST_$(GARCH)-$(MEMORYMODEL_$(ISA)))
> ? ? ? ?endef
>
> but still my buildit.sh script goes to current9s

When I work with the unstable hosts, I say "mgar platforms", and it
does the right thing.  The build host configuration should be in garrc
in /etc/opt/csw.  No private setup should be necessary.

Maciej

From maciej at opencsw.org  Thu May 26 09:32:08 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 26 May 2011 08:32:08 +0100
Subject: [csw-maintainers] graphviz-2.28 status.
In-Reply-To: <4DDD75D6.40708@opencsw.org>
References: <4DDD75D6.40708@opencsw.org>
Message-ID: <BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>

2011/5/25 John Ellson <ellson at opencsw.org>:
> It seems that the perl issue I was having is resolved by using a newer
> version of swig. ?I've marked Mantis#0004771 as resolved.
>
> So now, to finish the graphviz-2.28 upgrade, as I understand it, I need to:
>
> ? ?- post swig-2.0.3
>
> ? ? ? ?[ Please remind me. ?Do I do a:
> ? ? ? ? ? ? ? ?submitpkg ~/newpkgs/swig-2.0.3*
> ? ? ? ? ? ]

Correct.

> ? ?- wait for swig-2.0.3 on current* build hosts

To unpack this bit:

1. You need to wait for packages to be available from the mirrors.
You will get an email notification when that happens.
2. Once it's available from the mirrors, you send an email to
buildfarm@ and ask buildfarm admins to install updated swig on
current* hosts.
3. You wait for confirmation that packages have been installed.

> ? ?- build graphviz-2.28 using current* build hosts
>
> ? ?- post graphviz-2.28
>
> Is that the best plan?

Looks good, with one note I added about getting the packages on current* hosts.

Maciej

From maciej at opencsw.org  Thu May 26 09:58:34 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 26 May 2011 08:58:34 +0100
Subject: [csw-maintainers] An idea: monthly IRC meetings
In-Reply-To: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
References: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
Message-ID: <BANLkTim8a436A4spU3_8iJVGMpuL5UQETg@mail.gmail.com>

Due to the lack of interest, the IRC meeting idea has been shelved.
We might revisit it at later time.

Maciej

From dam at opencsw.org  Thu May 26 10:04:05 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 May 2011 10:04:05 +0200
Subject: [csw-maintainers] An idea: monthly IRC meetings
In-Reply-To: <BANLkTim8a436A4spU3_8iJVGMpuL5UQETg@mail.gmail.com>
References: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
	<BANLkTim8a436A4spU3_8iJVGMpuL5UQETg@mail.gmail.com>
Message-ID: <7F180244-0A59-4B57-93E0-B92EE26C8DB8@opencsw.org>

Hi Maciej,

Am 26.05.2011 um 09:58 schrieb Maciej Blizi?ski:
> Due to the lack of interest, the IRC meeting idea has been shelved.
> We might revisit it at later time.

I would put it a bit differently: The people interested in it are already
reachable most of the time on irc :-)


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From maciej at opencsw.org  Thu May 26 10:21:58 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 26 May 2011 09:21:58 +0100
Subject: [csw-maintainers] An idea: monthly IRC meetings
In-Reply-To: <7F180244-0A59-4B57-93E0-B92EE26C8DB8@opencsw.org>
References: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
	<BANLkTim8a436A4spU3_8iJVGMpuL5UQETg@mail.gmail.com>
	<7F180244-0A59-4B57-93E0-B92EE26C8DB8@opencsw.org>
Message-ID: <BANLkTikjYd28pxbAWjEgDG9vhNOz=b+ctQ@mail.gmail.com>

2011/5/26 Dagobert Michelsen <dam at opencsw.org>:
> Hi Maciej,
>
> Am 26.05.2011 um 09:58 schrieb Maciej Blizi?ski:
>> Due to the lack of interest, the IRC meeting idea has been shelved.
>> We might revisit it at later time.
>
> I would put it a bit differently: The people interested in it are already
> reachable most of the time on irc :-)

True.  I hoped that it could help with the following problem (a
fictionalized example):

17:43 -!- joe [~joe at example.com] has joined #opencsw
17:43 <joe> I have a question about compiling c++ with sunpro
17:44 <joe> hello, anybody there?
17:46 <joe> hello?
17:46 -!- joe [~joe at example.com] has quit [Quit: joe]
18:04 <automaciej> that was a long meeting... phew.
18:04 <automaciej> joe: hi, what's your question?
18:04 <automaciej> he's gone...

If we had a designated time to meet, people who do not usually keep
open IRC sessions, could also benefit from the closer to real-time
communication.  But it's generally the problem of getting people from
one communication medium to take a look at other ones. It's like the
Matrix, "no one can be told what IRC is".

Maciej

From james at opencsw.org  Thu May 26 10:48:35 2011
From: james at opencsw.org (James Lee)
Date: Thu, 26 May 2011 08:48:35 GMT
Subject: [csw-maintainers] An idea: monthly IRC meetings
In-Reply-To: <BANLkTikjYd28pxbAWjEgDG9vhNOz=b+ctQ@mail.gmail.com>
References: <BANLkTikdKf0rPTjpXJunkCtJJA+EO4tkdg@mail.gmail.com>
	<BANLkTim8a436A4spU3_8iJVGMpuL5UQETg@mail.gmail.com>
	<7F180244-0A59-4B57-93E0-B92EE26C8DB8@opencsw.org>
	<BANLkTikjYd28pxbAWjEgDG9vhNOz=b+ctQ@mail.gmail.com>
Message-ID: <20110526.8483500.1810744390@gyor.oxdrove.co.uk>

On 26/05/11, 09:21:58, =?UTF-8?Q?Maciej_Blizi=C5=84ski?=
<maciej at opencsw.org> wrote regarding Re: [csw-maintainers] An idea: monthly
IRC meetings:


> True.  I hoped that it could help with the following problem (a
> fictionalized example):

> 17:43 -!- joe [~joe at example.com] has joined #opencsw
> 17:43 <joe> I have a question about compiling c++ with sunpro
> 17:44 <joe> hello, anybody there?
> 17:46 <joe> hello?
> 17:46 -!- joe [~joe at example.com] has quit [Quit: joe]
> 18:04 <automaciej> that was a long meeting... phew.
> 18:04 <automaciej> joe: hi, what's your question?
> 18:04 <automaciej> he's gone...

09:45 <james> Good morning Joe, send your question to the mailing list.
      Someone might see it in the morning and answer it.  Both the
      question and answer will be recorded in the mailing list archive
      for others to see in the future, in fact if you search the mailing
      list you might find the answer there already.



(sorry, my answer a bit 2 lng for the twitbook gener8ion.)

James.

From ellson at opencsw.org  Thu May 26 15:00:02 2011
From: ellson at opencsw.org (John Ellson)
Date: Thu, 26 May 2011 09:00:02 -0400
Subject: [csw-maintainers] graphviz-2.28 status.
In-Reply-To: <BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>
References: <4DDD75D6.40708@opencsw.org>
	<BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>
Message-ID: <4DDE4ED2.1050204@opencsw.org>

On 05/26/2011 03:32 AM, Maciej Blizi?ski wrote:
> 2011/5/25 John Ellson <ellson at opencsw.org>:
>>
>> So now, to finish the graphviz-2.28 upgrade, as I understand it, I
need to:
>>
>> - post swig-2.0.3
>>
>> [ Please remind me. Do I do a:
>> submitpkg ~/newpkgs/swig-2.0.3*
>> ? ]
>
> Correct.
>

Well almost..

Apparently the procedure is:

    mkdir -p /home/experimental/ellson
    cp  ~/newpkgs/swig-2.0.3* /home/experimental/ellson
    cd /home/experimental/ellson
    submitpkg  swig-2.0.3*


Why doesn't submitpkg take care of this itself, and simply accept
filepaths to the packages?


Also, some programs, for example, svn and cvs for their changelogs,
can detect if the edit session was closed normally or aborted,
and then use this to decide whether to complete processing.   The
separate "sendmail -t < newpkgs.mail" just seems a bit unnecessary.


John


From bwalton at opencsw.org  Thu May 26 15:10:47 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 26 May 2011 09:10:47 -0400
Subject: [csw-maintainers] graphviz-2.28 status.
In-Reply-To: <4DDE4ED2.1050204@opencsw.org>
References: <4DDD75D6.40708@opencsw.org>
	<BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>
	<4DDE4ED2.1050204@opencsw.org>
Message-ID: <1306415370-sup-5312@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Thu May 26 09:00:02 -0400 2011:

Hi John,

> Why doesn't submitpkg take care of this itself, and simply accept
> filepaths to the packages?

The most recent update of submitpkg does take paths instead of package
names.  It was released yesterday.

> Also, some programs, for example, svn and cvs for their changelogs,
> can detect if the edit session was closed normally or aborted, and
> then use this to decide whether to complete processing.  The
> separate "sendmail -t < newpkgs.mail" just seems a bit unnecessary.

This was an early choice that may not make sense now.  Maciej?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Thu May 26 16:08:31 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 26 May 2011 15:08:31 +0100
Subject: [csw-maintainers] graphviz-2.28 status.
In-Reply-To: <1306415370-sup-5312@pinkfloyd.chass.utoronto.ca>
References: <4DDD75D6.40708@opencsw.org>
	<BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>
	<4DDE4ED2.1050204@opencsw.org>
	<1306415370-sup-5312@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTin1hs7_--dAe4Hryxm4VRE8g9T2zw@mail.gmail.com>

2011/5/26 Ben Walton <bwalton at opencsw.org>:
> Excerpts from John Ellson's message of Thu May 26 09:00:02 -0400 2011:
>
> Hi John,
>
>> Why doesn't submitpkg take care of this itself, and simply accept
>> filepaths to the packages?
>
> The most recent update of submitpkg does take paths instead of package
> names. ?It was released yesterday.

Yes, sorry about that John, I myself use submitpkg directly from
subversion, so it was already true for me when I wrote the email, but
it wasn't true for you if you used submitpkg installed on the login
host.

The updated CSWcswutils (containing submitpkg) hasn't hit the mirrors
yet, once that happens we'll upgrade CSWcswutils on login, and
submitpkg will accept paths from there on.

>> Also, some programs, for example, svn and cvs for their changelogs,
>> can detect if the edit session was closed normally or aborted, and
>> then use this to decide whether to complete processing. ?The
>> separate "sendmail -t < newpkgs.mail" just seems a bit unnecessary.
>
> This was an early choice that may not make sense now. ?Maciej?

I might be mistaken, but I think that the way svn and others detect
that, is by looking whether the temporary file has been modified or
not.  If you quit the editor without modifying the file, the commit
operation will be aborted.  In the submitpkg case, comments are
optional, and I didn't want to make them mandatory.  I preferred to
have exact control of what is sent, and when it's sent, hence the
simple solution with sendmail -t.  I'm open to suggestions for a
workable alternative.

Maciej

From dam at opencsw.org  Thu May 26 21:50:33 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 May 2011 21:50:33 +0200
Subject: [csw-maintainers] graphviz-2.28 status.
In-Reply-To: <4DDD75D6.40708@opencsw.org>
References: <4DDD75D6.40708@opencsw.org>
Message-ID: <714BC25F-E4BD-44A5-96D8-B381360F4ADB@opencsw.org>

Hi John,

Am 25.05.2011 um 23:34 schrieb John Ellson:
> It seems that the perl issue I was having is resolved by using a newer
> version of swig.  I've marked Mantis#0004771 as resolved.
> 
> So now, to finish the graphviz-2.28 upgrade, as I understand it, I need to:
> 
>    - post swig-2.0.3
> 
>        [ Please remind me.  Do I do a:
>                submitpkg ~/newpkgs/swig-2.0.3*
>         ? ]
> 
>    - wait for swig-2.0.3 on current* build hosts

The package has been released and I took the liberty of immediately
updating current*.

>    - build graphviz-2.28 using current* build hosts
> 
>    - post graphviz-2.28
> 
> Is that the best plan?

Yes :)


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896


From maciej at opencsw.org  Fri May 27 00:07:58 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 26 May 2011 23:07:58 +0100
Subject: [csw-maintainers] Further improvements to our website
Message-ID: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>

Hi William and others,

I did a review of our homepage at the SEO angle.  I used an extension
for Chrome, which analyzed the page and offered a couple of
suggestions.

- http://validator.w3.org/check?uri=http%3A//www.opencsw.org/ shows 64
HTML errors
- http://jigsaw.w3.org/css-validator/validator?uri=http%3A//www.opencsw.org/
shows 37 CSS errors
- description meta tag is missing
- keywords meta tag is missing (not that important, but it wouldn't
hurt to put "solaris packages" in there)
- no entry in the DMOZ directory

Let's look at our website again and see which ones we can easily fix.
William, do you accept volunteers who would like to work with the
website?  If so, could you provide hints, as to where to start and how
to contribute?  Thanks!

In the meantime, when searching for "solaris packages" in Chrome in
the incognito mode (no cookies), I see our website on the 10th place,
which means: The first result page! Good job everyone!

Maciej

From ellson at opencsw.org  Sun May 29 21:01:01 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 29 May 2011 15:01:01 -0400
Subject: [csw-maintainers] graphviz-2.28 status.
In-Reply-To: <BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>
References: <4DDD75D6.40708@opencsw.org>
	<BANLkTim3gzaQS3=EbjA=k7=Uah_a0StXdQ@mail.gmail.com>
Message-ID: <4DE297ED.2020404@opencsw.org>

This is odd.  It didn't ask me for a passwd when I pushed swig a couple
of days ago.

 ellson at login:~> submitpkg graphviz*2.28.0*
+-----------------------------------------------------------------+
| Sofern Sie unautorisiert in fremde Datenverarbeitungssysteme    |
| eindringen, machen Sie sich strafbar. Sie koennen bei einem     |
| Verstoss gegen art. 143 des Schweizerischen Strafgesetzbuches   |
| mit bis zu fuenf Jahren Zuchthaus oder bei einer Verletzung von |
| art. 143bis und 144bis des Schweizerischen Strafgesetzbuches    |
| mit bis zu drei Jahren Gefaengnis bestraft werden.              |
+-----------------------------------------------------------------+
| Unauthorized use of this computer system is punishable with a   |
| prison term of up to five years, according to article 143 of    |
| the Swiss criminal code.  Articles 143bis and 144bis also allow |
| for prison terms of up to three years.                          |
+-----------------------------------------------------------------+
Password:
  

I've no idea what my password is anymore ... could someone reset it for me?


I can still ssh to "login" ok, and from there to "current9s" etc with my
public keys.

John



From skayser at opencsw.org  Mon May 30 13:40:03 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 30 May 2011 13:40:03 +0200
Subject: [csw-maintainers] Packaging DBD::Sybase: need Sybase 12.5 x86
	32 bit
In-Reply-To: <716DB9DD-63AC-4DF5-8D9E-F5A33629EEBE@opencsw.org>
References: <716DB9DD-63AC-4DF5-8D9E-F5A33629EEBE@opencsw.org>
Message-ID: <20110530114003.GF29708@sebastiankayser.de>

Dago,

* Dagobert Michelsen <dam at opencsw.org> wrote:
> I have packaged up the Perl module DBD::Sybase bound against
> Sybase OCS 12.5 and FreeTDS as alternative. However, as the
> customer uses Sparc I only have Sybase Sparc at hand. To build
> the x86 Perl module I would need a Sybase OCS 12.5 Client
> for x86 with 32 bit. I happen to have a 64 bit x64 which
> is unfortunately useless for a 32 bit Perl...

was there further progress on DBD::Sybase? Got a Nagios plugin here
which could use it. In case the Sybase x86 client is still missing,
would it be feasible to release a build with / against FreeTDS only?

Sebastian

From maciej at opencsw.org  Mon May 30 15:43:53 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 30 May 2011 14:43:53 +0100
Subject: [csw-maintainers] [announcement] New submitpkg version
Message-ID: <BANLkTinxJBf8ts2ODrBfKPTgTdJMXV1F0g@mail.gmail.com>

Hello fellow maintainers,

Many of you were not happy with the way submitpkg worked.  It used to
take only catalognames as arguments, and expect all packages to reside
in a specified directory.  This behavior is now changed; from now on,
submitpkg takes direct package paths (relative or absolute), and
processes just the given files, with no additional magic.

There are checks done to the file set, for example, if there is a i386
package present, submitpkg expects there to be a corresponding sparc
package too. This makes it harder to make While this holds true for
most packages, and missing the sparc package is a bug, there are
legitimate cases such as the Acrobat reader, which is only available
for the Intel architecture.  When such package needs releasing, the
--force option can be used to push the package despite failing checks.

The new version of CSWcswutils (containing submitpkg) has been
installed on the login host.  If you run into any issues running
submitpkg, please let me know.

Thanks,
Maciej

From maciej at opencsw.org  Mon May 30 15:47:56 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 30 May 2011 14:47:56 +0100
Subject: [csw-maintainers] [announcement] New submitpkg version
In-Reply-To: <BANLkTinxJBf8ts2ODrBfKPTgTdJMXV1F0g@mail.gmail.com>
References: <BANLkTinxJBf8ts2ODrBfKPTgTdJMXV1F0g@mail.gmail.com>
Message-ID: <BANLkTintqriE7uTb-Sr+KmOmVD_H5qsR8w@mail.gmail.com>

[corrected version of the previous email]

Hello fellow maintainers,

Many of you were not happy with the way submitpkg worked.  It used to
take only catalognames as arguments, and expect all packages to reside
in a specified directory.  This behavior is now changed; from now on,
submitpkg takes direct package paths (relative or absolute), and
processes just the given files, with no additional magic.

There are checks done to the file set, for example, if there is a i386
package present, submitpkg expects there to be a corresponding sparc
package too. This checks makes it harder to make a human error when
sending packages for release.

While the i386-sparc correspondence holds true for most packages,
there are legitimate exceptions such as the Acrobat reader, which is
only available for the Intel architecture. ?When such package needs
releasing, the --force option can be used to push the package despite
failing checks.

The new version of CSWcswutils (containing submitpkg) has been
installed on the login host.  If you run into any issues running
submitpkg, please let me know.

Maciej

From rupert at opencsw.org  Mon May 30 22:08:35 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 30 May 2011 22:08:35 +0200
Subject: [csw-maintainers] Fwd: complicated build, subversion client
In-Reply-To: <20110529223727.GB9828@ted.stsp.name>
References: <f966cfe0-7ee1-4f3c-8eb1-9d745969b467@h9g2000yqk.googlegroups.com>
	<20110529181632.GA9828@ted.stsp.name>
	<BANLkTinDzWoGH3dhbTLOPow4pmJi+4oNGw@mail.gmail.com>
	<20110529223727.GB9828@ted.stsp.name>
Message-ID: <BANLkTi=nCLN2XPz6EZ3x5KMXNbTny2sTYQ@mail.gmail.com>

maciej suggested to cross post the answer from stefan, dev at svn, to the
question where our problem to compile the recent subversion might come from.

---------- Forwarded message ----------
From: Stefan Sperling <stsp at elego.de>
Date: Mon, May 30, 2011 at 00:37
Subject: Re: complicated build, subversion client
To: rupert THURNER <rupert.thurner at gmail.com>
Cc: dev at subversion.apache.org


On Sun, May 29, 2011 at 11:19:05PM +0200, rupert THURNER wrote:
> and we separate out the apache module, but imo a client should not contain
> svnserve, svnsync, svndumpfilter, etc., see
> http://www.opencsw.org/search/subversion/ for list of files we have
> currently in subversion. currently we have sasl, ldap and berkely db
> dependencies in this package

You could separate out svnserve and other repository administration
*binaries* (svnadmin, svnlook, svndumpfilter) into a separate package.

With the svn libraries it's a different story. You will want all
of them on both the client and server. This means you'll need most
(and probably all) dependencies on both sides.

SASL is a dependency of svnserve (server-side implementation of
the svn:// protocol) and of libsvn_ra_svn (client-side implementation
of same). You'll need it on both servers and client if you want
to support SASL authentication.

You'll need berkeley DB on the server, and on the client for the
libsvn_ra_local (file:// repository access protocol) to support
Subversion repositories using BDB accessed via file://.

I suppose the LDAP dependecy comes from berkeley DB?
Subversion has no direct dependency on LDAP.

> ... which seems bloat.

Well, Subversion has a large set of features, some of which are optional.
And with all those features come a lot of external dependencies.

You could choose not to compile some optional features in to keep
package dependencies down but I think that would be to the detriment
of your users more than it helps them. You usually won't know in advance
which features users of your packages will need.

You could also take a look at how the Debian packages for Subversion
split things up. They probably have things split up as much as
reasonably possible.

> > > 2. comlicated build
> > > the build itself is so complicated that, since i can remember, we
> > > continually fail to package a current version of subversion.
> >
> > Can you point out more specifically what problems you are running into?
> >
> > If there is something concrete we could do in to improve the build
system
> > we will consider it. Suggestions (and of course patches) are always
> > welcome.
> >
> >
> some files compile with the standard sun compiler, some don't, see:
>
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/Makefile
>

The files that don't compile with SUN's cc are generated by SWIG.
Can you figure out if it's possible to make SWIG generate code that
compiles with gcc as well as Sun's cc? If so we might be able to
fix your problem by changing the way we generate these files.

> we patch certain files, see:
> *
>
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch

That patch looks fine. If there is a pre-processor macro that identifies
a CWS build we could also include this change upstream wrapped in the
right #ifdef.

It's a very small patch though and doesn't really cause maintenance
effort at your end, does it?

> *
>
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh

This I don't really understand.

Editing Makefiles and libtool scripts like that is going to get you into
trouble sooner or later, no doubt. This seems very hackish and hard to
maintain. You are fixing up *generated* files. They going to change more
often than not from release to release. It's probably easier to fix up
the source files these were generated from, and regenerate.
Preferably in a way that we can integrate upstream.

Does CSW have a generic libtool replacement to deal with special
requirements that you impose on shared libraries?
OpenBSD does have one:
http://www.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/bin/libtool
(It's only used for package builds -- my dev builds don't use this but
they work fine on OpenBSD regardless.)

> * (not sure if this is still active:
>
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/javahl_headers_for_nested_classes.diff
> )

Note sure what the above is doing.

> *
>
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/subversion161.diff

This is OK. We do similar things in OpenBSD. Unfortunately everyone has
their own ideas about where stuff like python libraries should go.

SVN should probably add a new configure script parameter to take away the
need to patch this.

> > > what would be a good way to address this in your opinion? would it be
> > > possible to switch the build system to something easier to handle and
> > > introduce proper dependencies?
> >
> > I don't think that smart handling of dependencies belongs into the
> > Subversion core build system because there are so many different ways
> > people manage dependencies on different systems.
> > It would be very hard to come up with something that works for everyone.
> >
>
> autotools / libtool seems to be responsible for 80% of the problems.
beside
> making the build very slow we always need to tinker (see above), and still

I know that libtool is hard to deal with sometimes (I pulled some of
my own hair out over it as well). But it serves a great purpose for
Subversion because it is the most widespread way of dealing with
shared libraries on many UNIX-like platforms. I don't think we can
afford not to use it. If libtool is broken for you please try to
get libtool fixed instead. This would also help you port other software
that uses libtool more easily.

Note that as of Subversion 1.7 the build system will always use the libtool
program that was used to compile APR. This was done so we could remove
the configure script code for finding the right libtool and let APR sort
this out for us instead.

> get errors like just now when trying to build 1.6.16:
>
> cd subversion/bindings/swig/python ; /bin/bash
>
/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.16/libtool
> --mode=install /opt/csw/bin/ginstall -c
> _
core.la/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lion2.3/libsvn/_
> core.la
> libtool: install: error: cannot install `_core.la' to a directory not
ending
> in /opt/csw/lib/python/site-packages/libsvn
> gmake[2]: *** [install-swig-py] Error 1
> gmake[2]: Leaving directory
>
`/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.16'
> gmake[1]: *** [svn-python] Error 2
> gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk'
> gmake: *** [merge-isa-sparcv8] Error 2

I suppose the above is something with the fixme.sh gone wrong?
I've never seen an error like this.

> but the subversion community is very nice and helpful which makes it still
a
> pleasure :)

Well, I hope my hints and suggestions will help. I'm sorry I don't have
any conclusive answers to your problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110530/8ff055bc/attachment.html>

From william at wbonnet.net  Mon May 30 22:11:20 2011
From: william at wbonnet.net (William Bonnet)
Date: Mon, 30 May 2011 22:11:20 +0200
Subject: [csw-maintainers] Further improvements to our website
In-Reply-To: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
References: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
Message-ID: <4DE3F9E8.7020303@wbonnet.net>

Hi


> Let's look at our website again and see which ones we can easily fix.
> William, do you accept volunteers who would like to work with the
> website?  If so, could you provide hints, as to where to start and how
> to contribute?  Thanks!
I'll be happy to have help for the web site. The website is easy to 
hack. It is a standard wordpress site. The theme is under svn. If 
someone wants to give a try on the website, i can help you to setup a 
local copy of the website. The missing data you'll need are a database 
dump. Depending on what you would like to fix, you may not even need it 
(the default db is enough).

If you don't want to setup a local site, you can work on the mockup 
server. www-mockup.opencsw.org. Ask Ihsan to get an account :)

I'm going to try to give a look to the problem you reported. Maybe only 
this week end (which is 4 days long ;) )

Cheers
W.

-- 
William Bonnet http://www.wbonnet.net

http://www.opencsw.org      Community SoftWare for Solaris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110530/674958d5/attachment-0001.html>

From skayser at opencsw.org  Mon May 30 22:35:06 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 30 May 2011 22:35:06 +0200
Subject: [csw-maintainers] GAR: Oracle Solaris Studio now ships w/ changed
	paths
Message-ID: <20110530203506.GH29708@sebastiankayser.de>

Hi,

this is mostly to Dago, maybe others want to chime in. I just went
through the "Getting Started" page for GAR [1] and noticed that the
Solaris Studio installer and its install destination have changed.

It's now triggered via:

    ./SolarisStudio12.2-solaris-x86-pkg-ML.sh \
        --installation-location <dest> --non-interactive

And the compiler ends up in a sub directory to <dest>, e.g.

    /opt                ->  /opt/solstudio12.2
    /opt/studio/SOS12   ->  /opt/studio/SOS12/solstudio12.2

Couldn't make it install to /opt/studio/SOSXX/SUNWspro any more, thus
the documentation for beginners would need adjustment (easy) and GAR
also. Any preferences on how should we proceed?

Sebastian

[1] https://sourceforge.net/apps/trac/gar/wiki/GarSetup

From bwalton at opencsw.org  Tue May 31 02:25:16 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 30 May 2011 20:25:16 -0400
Subject: [csw-maintainers] Fwd: complicated build, subversion client
In-Reply-To: <BANLkTi=nCLN2XPz6EZ3x5KMXNbTny2sTYQ@mail.gmail.com>
References: <f966cfe0-7ee1-4f3c-8eb1-9d745969b467@h9g2000yqk.googlegroups.com>
	<20110529181632.GA9828@ted.stsp.name>
	<BANLkTinDzWoGH3dhbTLOPow4pmJi+4oNGw@mail.gmail.com>
	<20110529223727.GB9828@ted.stsp.name>
	<BANLkTi=nCLN2XPz6EZ3x5KMXNbTny2sTYQ@mail.gmail.com>
Message-ID: <1306800816-sup-4668@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Mon May 30 16:08:35 -0400 2011:

Hi Rupert,

> You could separate out svnserve and other repository administration
> *binaries* (svnadmin, svnlook, svndumpfilter) into a separate
> package.

This sounds like a good idea.  I've seen a few bug requests for it.

> With the svn libraries it's a different story. You will want all of
> them on both the client and server. This means you'll need most (and
> probably all) dependencies on both sides.

This would be a good subversion-common package.  Both the server and
client packages could then depend on it.

> I suppose the LDAP dependecy comes from berkeley DB?  Subversion has
> no direct dependency on LDAP.

Does checkpkg tell you it's a surplus dep?  If so, you could just drop
it.  It may be pulled in via something else and not actually be
required.  I haven't looked at it though.

> You could also take a look at how the Debian packages for Subversion
> split things up. They probably have things split up as much as
> reasonably possible.

It looks like a fairly monolithic setup there.

> The files that don't compile with SUN's cc are generated by SWIG.
> Can you figure out if it's possible to make SWIG generate code that
> compiles with gcc as well as Sun's cc? If so we might be able to fix
> your problem by changing the way we generate these files.

Might John's updated swig packages alleviate this?

> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch
> 
> That patch looks fine. If there is a pre-processor macro that
> identifies a CWS build we could also include this change upstream
> wrapped in the right #ifdef.

Aside from the fact that this should be handled by autoconf (or
whatever build system they're using) instead of the way they're doing
it, I agree that the current patch shouldn't be too onerous to
support.  If they use autoconf and you'd like a hand building a patch
for that to make this sane, let me know.

> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh
> 
> This I don't really understand.

This may be replaceable by the 'STRIP_LIBTOOL = 1' capability that
Mike introduced to GAR, but I'm not sure.

> SVN should probably add a new configure script parameter to take
> away the need to patch this.

Agreed.


> Note that as of Subversion 1.7 the build system will always use the
> libtool program that was used to compile APR. This was done so we
> could remove the configure script code for finding the right libtool
> and let APR sort this out for us instead.

This should be a good change overall, I think.  That will likely mean
that it uses /opt/csw/bin/libtool (or whatever).  It may be possible
that the version of libtool changes between subversion releases though
since it won't be in lockstep with apr.

> I suppose the above is something with the fixme.sh gone wrong?
> I've never seen an error like this.

I'd suspect the same thing.

Hopefully some of my feedback is useful too.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From phil at bolthole.com  Tue May 31 05:48:59 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 30 May 2011 20:48:59 -0700
Subject: [csw-maintainers] Fwd: complicated build, subversion client
In-Reply-To: <1306800816-sup-4668@pinkfloyd.chass.utoronto.ca>
References: <f966cfe0-7ee1-4f3c-8eb1-9d745969b467@h9g2000yqk.googlegroups.com>
	<20110529181632.GA9828@ted.stsp.name>
	<BANLkTinDzWoGH3dhbTLOPow4pmJi+4oNGw@mail.gmail.com>
	<20110529223727.GB9828@ted.stsp.name>
	<BANLkTi=nCLN2XPz6EZ3x5KMXNbTny2sTYQ@mail.gmail.com>
	<1306800816-sup-4668@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimQE7wXB_CdrS8Ts+D2pcW_jU9VjA@mail.gmail.com>

On Mon, May 30, 2011 at 5:25 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from rupert THURNER's message of Mon May 30 16:08:35 -0400 2011:
>
> Hi Rupert,
>
>> You could separate out svnserve and other repository administration
>> *binaries* (svnadmin, svnlook, svndumpfilter) into a separate
>> package.
>
> This sounds like a good idea. ?I've seen a few bug requests for it.
>
>> With the svn libraries it's a different story. You will want all of
>> them on both the client and server. This means you'll need most (and
>> probably all) dependencies on both sides.
>
> This would be a good subversion-common package. ?Both the server and
> client packages could then depend on it

we have a tradition of "common" usually being non-binary.
Prossibly "utils" is better for the executables. and the usual lib
stuff, for libraries?

From maciej.blizinski at gmail.com  Sat May  7 16:44:01 2011
From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 07 May 2011 14:44:01 -0000
Subject: [csw-maintainers] Fwd: [csw-users] Can't find CSWunrealircd
In-Reply-To: <BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
References: <1304709541-sup-9489@pinkfloyd.chass.utoronto.ca>
	<BANLkTini7zF4FuvwdBkbC=jHAPHywrNNaQ@mail.gmail.com>
	<BANLkTimqP-BU6=AatvrBOSREjE7JXwHutg@mail.gmail.com>
Message-ID: <BANLkTikzPepskEvOEx_G6uchJtdgT0uDOw@mail.gmail.com>

The new version depends on libtre, I built it some time ago. It is in
opencsw-future/unstable. But the unrealircd build system is quite
maintainer-hostile. If you search for 'unrealircd build', you will find a
forum post in which unrealircd developer says they discourage packaging it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110507/2e1b32c4/attachment-0001.html>

From rupert.thurner at gmail.com  Sat May 14 13:40:59 2011
From: rupert.thurner at gmail.com (rupert THURNER)
Date: Sat, 14 May 2011 11:40:59 -0000
Subject: [csw-maintainers] lzlib-1.1: ldconfig not found ...
In-Reply-To: <B3ADE547-25E5-4C20-9803-026A4C05465D@opencsw.org>
References: <BANLkTi=z_nJjKCR2yqVBagQsws0zFzS0HQ@mail.gmail.com>
	<B3ADE547-25E5-4C20-9803-026A4C05465D@opencsw.org>
Message-ID: <BANLkTine1BR-N2tbQFDiOa+6Q1tuGYXFjA@mail.gmail.com>

talked to antonio, it will be fixed upstream as well.

On May 13, 2011 3:27 PM, "Dagobert Michelsen" <dam at opencsw.org> wrote:

Hi Rupert,

Am 08.05.2011 um 22:17 schrieb rupert THURNER:

> when upgrding lzlib the following error is thrown:
> ...

> /bin/sh: ldconfig: not found
> ...

>
> i am unsure how this should behave correctly.
I took the liberty of fixing the issue by replacing LDCONFIG with 'echo'
and bringing it up to the latest standards:
 http://sourceforge.net/apps/trac/gar/changeset/14571

Please release as you see fit.


Best regards

 -- Dago

_______________________________________________
maintainers mailing list
maintainers at lists.opencsw.o...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110514/63522923/attachment-0001.html>

From mark at probably.co.uk  Tue May 17 23:50:31 2011
From: mark at probably.co.uk (Mark Phillips)
Date: Tue, 17 May 2011 21:50:31 -0000
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs puppet,
	puppetmaster
In-Reply-To: <BANLkTim948bR+TsRcLZAi_Y=U1WrLvdKxQ@mail.gmail.com>
References: <201105171549.p4HFn6NP024022@login.bo.opencsw.org>
	<BANLkTinByNRPk9Aw0UD2gBmMxaZ_vOz3AQ@mail.gmail.com>
	<1305649802-sup-9503@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=fLOmJOjQ_r6xhyoOeM5FNgTx1VA@mail.gmail.com>
	<1305650813-sup-2188@pinkfloyd.chass.utoronto.ca>
	<E681134E-D51B-434E-827C-EC584CD2ED34@opencsw.org>
	<BANLkTi=o+f_5hK4CvH=b89yQ-SZQxtvdWQ@mail.gmail.com>
	<2634A9E0-740B-4C32-B6BE-6DF37E168392@opencsw.org>
	<BANLkTim948bR+TsRcLZAi_Y=U1WrLvdKxQ@mail.gmail.com>
Message-ID: <7B579C1E-8AB7-40B4-847A-8BFD252F12F7@opencsw.org>

Crikey, you go out for the evening and it all goes mad.

Sorry, just catching up with this. Did I do something wrong? :)

--Mark

From trygvis at inamo.no  Thu May 26 15:16:30 2011
From: trygvis at inamo.no (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=)
Date: Thu, 26 May 2011 13:16:30 -0000
Subject: [csw-maintainers] Forum Software
In-Reply-To: <20110525164348.GG11519@sebastiankayser.de>
References: <4DDD0E24.6010907@opencsw.org>
	<20110525164348.GG11519@sebastiankayser.de>
Message-ID: <4DDE52A3.9020300@inamo.no>

On 05/25/2011 06:43 PM, Sebastian Kayser wrote:
> * ??hsan Do??an<ihsan at opencsw.org>  wrote:
>> As discussed on the IRC, I'm currently working on a forum for OpenCSW.
>> I've did a test installation of the most recent phpBB version, but I'm
>> not happy with it. Somehow I don't like the software.
>>
>> Does someone has already experience with forum software and can
>> recommend me a good alternative to phpBB?
>
> During winter camp Maciej mentioned Vanilla which seems loosely modelled
> after Stackoverflow [1,2]. From looking at it briefly, it feels more
> like the 21th century than traditional forums. That's only the user side
> though, not the admin perspective.
>
> Sebastian
>
> [1] http://wiki.opencsw.org/wintercamp-2011#toc6
> [2] http://vanillaforums.org/

Another option is Shapado [1] which is more or less a stackexchange[2] 
copy. It's a bit different than traditional forums, but has a very nice 
"community" thing to it.

[1]: http://shapado.com/pages/code.
[2]: http://stackexchange.com, the platform behind stackoverflow.

-- 
Trygve