From maciej at opencsw.org  Wed Jun  1 16:50:01 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Wed, 1 Jun 2011 15:50:01 +0100
Subject: [csw-maintainers] Further improvements to our website
In-Reply-To: <4DE3F9E8.7020303@wbonnet.net>
References: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
	<4DE3F9E8.7020303@wbonnet.net>
Message-ID: <BANLkTikEtVBtb83i6A2bEupzpfATWYNsmw@mail.gmail.com>

2011/5/30 William Bonnet <william at wbonnet.net>:
> 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.

I will try to set it up on my virtual Solaris host to see how hard or
easy it is.  If I have any questions, I'll update this thread.

Maciej

From bonivart at opencsw.org  Wed Jun  1 19:12:05 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 1 Jun 2011 19:12:05 +0200
Subject: [csw-maintainers] User request from our old friends: zabbix
Message-ID: <BANLkTi=hbeTwiNxYdGh20OfPH9+bLLvUbA@mail.gmail.com>

As you know our old friends are not very responsive these days and
this request just came in, unanswered of course:

"Zabbix is an enterprise-class open source distributed monitoring solution.

http://www.zabbix.com/"

Someone interested in an alternative to Nagios/Cacti may want to build it.


/peter

From ja at opencsw.org  Thu Jun  2 10:20:10 2011
From: ja at opencsw.org (Juergen Arndt)
Date: Thu, 2 Jun 2011 10:20:10 +0200
Subject: [csw-maintainers] User request from our old friends: zabbix
In-Reply-To: <BANLkTi=hbeTwiNxYdGh20OfPH9+bLLvUbA@mail.gmail.com>
References: <BANLkTi=hbeTwiNxYdGh20OfPH9+bLLvUbA@mail.gmail.com>
Message-ID: <DE8444AD-E815-44D9-BAC2-ED36BDA9E83A@opencsw.org>


On 01.06.2011, at 19:12, Peter Bonivart wrote:

> As you know our old friends are not very responsive these days and
> this request just came in, unanswered of course:
> 
> "Zabbix is an enterprise-class open source distributed monitoring solution.
> 
> http://www.zabbix.com/"
> 
> Someone interested in an alternative to Nagios/Cacti may want to build it.

I give it a try, but compiling zabbix on solaris seems to be not very straight forward (at least for me), so I'll need some time.

Regards,
Juergen


-- 
Juergen Arndt


From bonivart at opencsw.org  Thu Jun  2 10:41:18 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 2 Jun 2011 10:41:18 +0200
Subject: [csw-maintainers] User request from our old friends: zabbix
In-Reply-To: <DE8444AD-E815-44D9-BAC2-ED36BDA9E83A@opencsw.org>
References: <BANLkTi=hbeTwiNxYdGh20OfPH9+bLLvUbA@mail.gmail.com>
	<DE8444AD-E815-44D9-BAC2-ED36BDA9E83A@opencsw.org>
Message-ID: <BANLkTimoP-qwMo-Byqc+z=XFjLYUznJQPQ@mail.gmail.com>

On Thu, Jun 2, 2011 at 10:20 AM, Juergen Arndt <ja at opencsw.org> wrote:
> I give it a try, but compiling zabbix on solaris seems to be not very straight forward (at least for me), so I'll need some time.

Cool! Maybe others can chip in if you have some specific problem.

/peter

From maciej at opencsw.org  Thu Jun  2 12:22:05 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 2 Jun 2011 11:22:05 +0100
Subject: [csw-maintainers] Uncommitted packages in experimental
In-Reply-To: <BANLkTimj1e8akXvxQwM5FkDynGsCMRiAhA@mail.gmail.com>
References: <BANLkTikMaj04hwd1Tn_5af_=F=14HgTO=g@mail.gmail.com>
	<BANLkTimj1e8akXvxQwM5FkDynGsCMRiAhA@mail.gmail.com>
Message-ID: <BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>

Hello fellow maintainers,

Currently, packages tagged uncommitted are not included in the experimental
catalogs. I find that I often want to try installing packages before I
commit code to the repository. To do that, I write shell scripts to push
packages out, then run gunzip and pkgadd. It would be easier if my
uncommitted packages were available for installation from experimental.

Do others think it's a good idea to allow uncommitted packages in
experimental?

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110602/5c67cecb/attachment-0001.html>

From rupert at opencsw.org  Thu Jun  2 16:55:05 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Thu, 2 Jun 2011 16:55:05 +0200
Subject: [csw-maintainers] --catalog-release does not exist ?
In-Reply-To: <BANLkTim+uFNXy-uy3-fDj9Sbr0DgdvbJpQ@mail.gmail.com>
References: <BANLkTim+uFNXy-uy3-fDj9Sbr0DgdvbJpQ@mail.gmail.com>
Message-ID: <BANLkTi=K=hsjL4EbrtpB+eUzZvOgRkUupw@mail.gmail.com>

what does the error message "--catalog-release does not exist" mean? and i
am wondering why this error message cannot be presented in 2 lines insead of
40 :)


$ csw-upload-pkg pkgs/02.Jun.2011/*
Processing 2 file(s). Please wait.
Uploading
'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz'
Uploading
'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz'
Checking 1 package(s) against catalog unstable sparc SunOS5.9
ERROR: --catalog-release does not exist
Checking 1 package(s) against catalog unstable i386 SunOS5.9
ERROR: --catalog-release does not exist
Checking 1 package(s) against catalog unstable sparc SunOS5.10
ERROR: --catalog-release does not exist
Checking 1 package(s) against catalog unstable i386 SunOS5.10
ERROR: --catalog-release does not exist
Checks failed for catalogs:
  - sparc SunOS5.9
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz
To see errors, run:
  /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9
--architecture sparc 5c73fa54a7b1e7fc0c3972748464c826
  - i386 SunOS5.9
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz
To see errors, run:
  /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9
--architecture i386 b2bb56a6f126713461695972ec8b9a3a
  - sparc SunOS5.10
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz
To see errors, run:
  /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.10
--architecture sparc 5c73fa54a7b1e7fc0c3972748464c826
  - i386 SunOS5.10
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz
To see errors, run:
6 b2bb56a6f126713461695972ec8b9a3a
Packages have not been submitted to the unstable catalog.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110602/dbdd0783/attachment.html>

From bwalton at opencsw.org  Thu Jun  2 17:02:51 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 02 Jun 2011 11:02:51 -0400
Subject: [csw-maintainers] --catalog-release does not exist ?
In-Reply-To: <BANLkTi=K=hsjL4EbrtpB+eUzZvOgRkUupw@mail.gmail.com>
References: <BANLkTim+uFNXy-uy3-fDj9Sbr0DgdvbJpQ@mail.gmail.com>
	<BANLkTi=K=hsjL4EbrtpB+eUzZvOgRkUupw@mail.gmail.com>
Message-ID: <1307026928-sup-7585@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Thu Jun 02 10:55:05 -0400 2011:

Hi Rupert,

> what does the error message "--catalog-release does not exist" mean?
> and i am wondering why this error message cannot be presented in 2
> lines insead of 40 :)

As for why it breaks, I need to push an update to cswutils.  That'll
be pushed later today, I hope.

The error message length I'll leave to Maciej.

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


From bwalton at opencsw.org  Thu Jun  2 17:06:53 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 02 Jun 2011 11:06:53 -0400
Subject: [csw-maintainers] [csw-buildfarm] Please install CSWlibnspr4
In-Reply-To: <7CDB44A5-E199-4D08-994A-D71EE08E3F44@opencsw.org>
References: <7CDB44A5-E199-4D08-994A-D71EE08E3F44@opencsw.org>
Message-ID: <1307027144-sup-4030@pinkfloyd.chass.utoronto.ca>

Excerpts from Juergen Arndt's message of Thu Jun 02 04:22:16 -0400 2011:

[+maintainers]

Hi Juergen,

> could you please install the package CSWlibnspr4. It is needed for
> compiling zabbix.

Solving needed dependencies ...
Package CSWlibnspr4 not in catalog. Exiting.

Not sure what's up.  The package is listed at opencsw.org/packages/...

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


From maciej at opencsw.org  Thu Jun  2 17:22:49 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 2 Jun 2011 16:22:49 +0100
Subject: [csw-maintainers] [csw-buildfarm] Please install CSWlibnspr4
In-Reply-To: <1307027144-sup-4030@pinkfloyd.chass.utoronto.ca>
References: <7CDB44A5-E199-4D08-994A-D71EE08E3F44@opencsw.org>
	<1307027144-sup-4030@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTiks1ti2pPeQuBeFs8G8_xdHtZfsVg@mail.gmail.com>

2011/6/2 Ben Walton <bwalton at opencsw.org>:
> [+maintainers]
>
> Hi Juergen,
>
>> could you please install the package CSWlibnspr4. It is needed for
>> compiling zabbix.
>
> Solving needed dependencies ...
> Package CSWlibnspr4 not in catalog. Exiting.
>
> Not sure what's up. ?The package is listed at opencsw.org/packages/...

There is an older version of the nspr package in the catalog.  The
updated version has not been released because of a file conflict with
CSWmozilla (although the current package conflicts with it as well, as
far as I remember).

Maciej

From maciej at opencsw.org  Thu Jun  2 18:10:08 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 2 Jun 2011 17:10:08 +0100
Subject: [csw-maintainers] --catalog-release does not exist ?
In-Reply-To: <BANLkTi=K=hsjL4EbrtpB+eUzZvOgRkUupw@mail.gmail.com>
References: <BANLkTim+uFNXy-uy3-fDj9Sbr0DgdvbJpQ@mail.gmail.com>
	<BANLkTi=K=hsjL4EbrtpB+eUzZvOgRkUupw@mail.gmail.com>
Message-ID: <BANLkTimKR+RX7UZk-NB=LHr5-ozJ8=A8jw@mail.gmail.com>

2011/6/2 rupert THURNER <rupert at opencsw.org>:
> what does the error message "--catalog-release does not exist" mean?

In this case the failure occurs, because /usr/bin/checkpkg is
currently the legacy checkpkg, and has different command line options;
it thinks that --catalog-release is a package to examine.

If you use csw-upload-pkg from gar sources, the upload will work.
csw-upload-pkg from gar sources uses checkpkg from the same location.

Ben will deploy a fix soon.

2011/6/2 rupert THURNER <rupert at opencsw.org>:
> and i am wondering why this error message cannot be presented in 2 lines
> insead of 40 :)

You wouldn't be yourself if you didn't, Rupert! ;-)

I don't have a good idea how to shorten the output without losing
information.  csw-upload-pkg runs checkpkg for each catalog, and I
didn't want to make it stop after the first failure.  It's useful to
know whether a set of packages fails for all catalogs or just one.

If it was a web interface, it would be easier, because a summary could
be displayed, with a "show more" button.  Here, you run the tool, and
either it prints something to the screen, or it doesn't.

As always, I'm accepting volunteer efforts to improve checkpkg.  The
sources are publicly available, and the bit of code that drives this
part of interaction is in the _RunCheckpkg function[1] in
csw_upload_pkg.py.  Feel free to hack at it and send me a patch!

Maciej

[1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/csw_upload_pkg.py#L487

From bwalton at opencsw.org  Thu Jun  2 20:00:08 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 02 Jun 2011 14:00:08 -0400
Subject: [csw-maintainers] Uncommitted packages in experimental
In-Reply-To: <BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>
References: <BANLkTikMaj04hwd1Tn_5af_=F=14HgTO=g@mail.gmail.com>
	<BANLkTimj1e8akXvxQwM5FkDynGsCMRiAhA@mail.gmail.com>
	<BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>
Message-ID: <1307037572-sup-4349@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Thu Jun 02 06:22:05 -0400 2011:

> Do others think it's a good idea to allow uncommitted packages in
> experimental?

I don't see the harm in it, but I've personally gotten used to just
committing often and early with svn.

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


From rupert at opencsw.org  Thu Jun  2 22:06:48 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Thu, 2 Jun 2011 22:06:48 +0200
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: <BANLkTin9gk2OxdDV+97OEEgvxUwSuLHCpA@mail.gmail.com>

On Tue, May 31, 2011 at 02:25, 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.


stefan had the the convincing argument that we won't save any space on this
as we need to deliver all the dependencies anyway as file:// needs to be
supported see "libraries" below.

my personal favourite as svn client currently is git. no svn necessary at
all. just three commands are necessary:
 git svn clone https://whatever
 git svn rebase    # update
 git svn dcommit   # commit

> 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.


STRIP_LIBTOOL is there as well.


>
> > 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.


many thanks, much appreciated :)  i tried removing fixme.sh, but it still
goes wrong. let me copy the part out of libtool where it fails:

       if test -n "$relink_command"; then
          # Determine the prefix the user has applied to our future dir.
          inst_prefix_dir=`$echo "$destdir" | $SED "s%$libdir\$%%"`

          # Don't allow the user to place us outside of our expected
          # location b/c this prevents finding dependent libraries that
          # are installed to the same prefix.
          # At present, this check doesn't affect windows .dll's that
          # are installed into $libdir/../bin (currently, that works fine)
          # but it's something to keep an eye on.
          if test "$inst_prefix_dir" = "$destdir"; then
            $echo "$modename: error: cannot install \`$file' to a directory
not ending in $libdir" 1>&2
            exit $EXIT_FAILURE
          fi

          if test -n "$inst_prefix_dir"; then
            # Stick the inst_prefix_dir data into the link command.
            relink_command=`$echo "$relink_command" | $SP2NL | $SED
"s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" | $NL2SP`
          else
            relink_command=`$echo "$relink_command" | $SP2NL | $SED
"s%@inst_prefix_dir@%%" | $NL2SP`
          fi



kr, rupert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110602/b8b7be44/attachment-0001.html>

From dam at opencsw.org  Thu Jun  2 22:10:31 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 2 Jun 2011 22:10:31 +0200
Subject: [csw-maintainers] stub naming
In-Reply-To: <BANLkTimdANnyYNu+hZTSmqtV59eyJmczUQ@mail.gmail.com>
References: <201105041748.p44HmMF9026139@login.bo.opencsw.org>
	<BANLkTi=ue=h5xKvvar-kNew7ad92mAzzcw@mail.gmail.com>
	<1304650265-sup-8640@pinkfloyd.chass.utoronto.ca>
	<BANLkTim1isN_2NdahK923nh211Drhaewcg@mail.gmail.com>
	<1305474909-sup-7699@pinkfloyd.chass.utoronto.ca>
	<BANLkTike64JWaFby+-cOuv6cRW8kcSLqrA@mail.gmail.com>
	<1305509630-sup-9069@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4OrJ_=at2s=MgvL9Z8Ncyz-jwQg@mail.gmail.com>
	<1307043617-sup-9241@pinkfloyd.chass.utoronto.ca>
	<BANLkTimdANnyYNu+hZTSmqtV59eyJmczUQ@mail.gmail.com>
Message-ID: <17A2F4C7-0AB7-4634-B062-74D79C3FD9C6@opencsw.org>

Hi Phil,

(moving to maintainers@)

Am 02.06.2011 um 21:55 schrieb Philip Brown:
> On Thu, Jun 2, 2011 at 12:41 PM, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Philip Brown's message of Tue May 17 12:47:05 -0400 2011:
>> 
>>> FYI, to tie loose ends together in this archive; since you declined
>>> to start a vote off, I have started a discussion about stub naming
>>> on the maintainer list .
>> 
>> Nobody seems to have an opinion on this in your spun out
>> thread...batching?
> 
> Well, on the one hand, there has been no general discussion, which is
> unfortunate. However, nor is there a "majority of maintainers" (or
> even anything close to it) who have spoken up on this issue. Please
> set up a vote on it.
> 
> I would suggest a format similar to
> http://wiki.opencsw.org/vote-release-process, and that the ballot
> reference the wiki page, giving as voting choices only,
> 
> "option A, on http....."
> "option B, on http..."
> 
> that way, people have to at least go to the page, to know what they
> are voting for.

I don't see a need for this. If there are no strong opinions and
almost same amounts on both sides it would be a waste of resources.

The argument that _stub should be appended to the *existing* catalog
name is IMHO good as it groups the package file together with the
old (pre-stub) package. I changed my opinion as this argument
convinced me. Aside from that I don't think there is a notable
difference how stubs are named.

So I suggest just going with that until someone has a strong other
opinion, ok?


Best regards

  -- Dago



From dam at opencsw.org  Thu Jun  2 22:17:42 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 2 Jun 2011 22:17:42 +0200
Subject: [csw-maintainers] Fwd: complicated build, subversion client
In-Reply-To: <BANLkTin9gk2OxdDV+97OEEgvxUwSuLHCpA@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>
	<1306800816-sup-4668@pinkfloyd.chass.utoronto.ca>
	<BANLkTin9gk2OxdDV+97OEEgvxUwSuLHCpA@mail.gmail.com>
Message-ID: <732A717A-4B6E-4432-B544-D0046C111556@opencsw.org>

Hi Rupert,

Am 02.06.2011 um 22:06 schrieb rupert THURNER:
> many thanks, much appreciated :)  i tried removing fixme.sh, but it still goes wrong. let me copy the part out of libtool where it fails:

Could you please commit what you have so I can have a look?


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 rupert at opencsw.org  Thu Jun  2 23:31:52 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Thu, 2 Jun 2011 23:31:52 +0200
Subject: [csw-maintainers] Uncommitted packages in experimental
In-Reply-To: <BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>
References: <BANLkTikMaj04hwd1Tn_5af_=F=14HgTO=g@mail.gmail.com>
	<BANLkTimj1e8akXvxQwM5FkDynGsCMRiAhA@mail.gmail.com>
	<BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>
Message-ID: <BANLkTi=5dXWv-HcBKM_MQA2omvr0R97Mkw@mail.gmail.com>

2011/6/2 Maciej Blizi?ski <maciej at opencsw.org>

> Hello fellow maintainers,
>
> Currently, packages tagged uncommitted are not included in the experimental
> catalogs. I find that I often want to try installing packages before I
> commit code to the repository. To do that, I write shell scripts to push
> packages out, then run gunzip and pkgadd. It would be easier if my
> uncommitted packages were available for installation from experimental.
>
> Do others think it's a good idea to allow uncommitted packages in
> experimental?
>
imo it would be better to keep it transparent for others - i.e. if the
package is public, the source which was used to get it is as well public.

rupert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110602/1995f175/attachment.html>

From dam at opencsw.org  Thu Jun  2 23:38:39 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 2 Jun 2011 23:38:39 +0200
Subject: [csw-maintainers] Uncommitted packages in experimental
In-Reply-To: <BANLkTi=5dXWv-HcBKM_MQA2omvr0R97Mkw@mail.gmail.com>
References: <BANLkTikMaj04hwd1Tn_5af_=F=14HgTO=g@mail.gmail.com>
	<BANLkTimj1e8akXvxQwM5FkDynGsCMRiAhA@mail.gmail.com>
	<BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>
	<BANLkTi=5dXWv-HcBKM_MQA2omvr0R97Mkw@mail.gmail.com>
Message-ID: <5750C825-844F-4B3B-A722-8BC36AAB94E5@opencsw.org>

Hi,

Am 02.06.2011 um 23:31 schrieb rupert THURNER:
> 2011/6/2 Maciej Blizi?ski <maciej at opencsw.org>
> Hello fellow maintainers,
> 
> Currently, packages tagged uncommitted are not included in the experimental catalogs. I find that I often want to try installing packages before I commit code to the repository. To do that, I write shell scripts to push packages out, then run gunzip and pkgadd. It would be easier if my uncommitted packages were available for installation from experimental.
> 
> Do others think it's a good idea to allow uncommitted packages in experimental?
> 
> imo it would be better to keep it transparent for others - i.e. if the package is public, the source which was used to get it is as well public.

+1 for me. What's wrong with an early commit? It helps making the work available
to others.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110602/07762746/attachment.html>

From ellson at opencsw.org  Thu Jun  2 23:42:14 2011
From: ellson at opencsw.org (John Ellson)
Date: Thu, 02 Jun 2011 17:42:14 -0400
Subject: [csw-maintainers] graphviz: pushed to unstable -  problem analysis,
 solution, and next issue
Message-ID: <4DE803B6.2000102@opencsw.org>

The latest graphviz-2.28.0 build looks much better.   It has been pushed
to unstable and I've given it a quick test on my nice new solaris-10
virtual host.

The work-around for the libtool problem (see below)  was to build on
machines *without* the older CSWgraphvizdevel installed.


Next problem:

    - Can someone advise me how to deal with the ImageMagic issue of
depending on the older graphviz libraries?
Maciej made changes (thank you) so that this won't be a problem next
time, but this time its still a problem.

I think Maciej suggested shipping the old libs along with the new
packages?   Is it kosher to just copy the old binary images
in to the new packages?  How would I actually do that?


John


Problem analysis.


    During "make install", libtool relinks libraries against the final 
installation location.   But the dependent libraries from the graphviz 
packages haven't been installed yet, so libtool picks up the old 
libraries incorrectly (but only if the -devel package is installed).

    In fact the libtool manual 
<http://www.gnu.org/software/libtool/manual/html_node/Install-mode.html> 
states:

        "Currently it is not generally possible to install into a 
temporary staging area that contains needed third-party libraries which 
are not yet visible at their final location."

    and yet, the earlier release built ok, so my working theory (now verified) is that 
it won't add incorrect libraries during the relink if they don't exist 
at all. 


John


From maciej at opencsw.org  Thu Jun  2 23:57:16 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 2 Jun 2011 22:57:16 +0100
Subject: [csw-maintainers] Uncommitted packages in experimental
In-Reply-To: <5750C825-844F-4B3B-A722-8BC36AAB94E5@opencsw.org>
References: <BANLkTikMaj04hwd1Tn_5af_=F=14HgTO=g@mail.gmail.com>
	<BANLkTimj1e8akXvxQwM5FkDynGsCMRiAhA@mail.gmail.com>
	<BANLkTimWA3AmMrwjJ_cgXQdjXrBE+cUTnw@mail.gmail.com>
	<BANLkTi=5dXWv-HcBKM_MQA2omvr0R97Mkw@mail.gmail.com>
	<5750C825-844F-4B3B-A722-8BC36AAB94E5@opencsw.org>
Message-ID: <BANLkTi=EFmXBYmRBzeipYyknk1DbEizivw@mail.gmail.com>

2011/6/2 Dagobert Michelsen <dam at opencsw.org>:
> Hi,
> Am 02.06.2011 um 23:31 schrieb rupert THURNER:
>
> 2011/6/2 Maciej Blizi?ski <maciej at opencsw.org>
>>
>> Hello fellow maintainers,
>>
>> Currently, packages tagged uncommitted are not included in the
>> experimental catalogs. I find that I often want to try installing packages
>> before I commit code to the repository. To do that, I write shell scripts to
>> push packages out, then run gunzip and pkgadd. It would be easier if my
>> uncommitted packages were available for installation from experimental.
>>
>> Do others think it's a good idea to allow uncommitted packages in
>> experimental?
>
> imo it would be better to keep it transparent for others - i.e. if the
> package is public, the source which was used to get it is as well public.
>
> +1 for me. What's wrong with an early commit? It helps making the work
> available
> to others.

Looking back at my work with MySQL and PostgreSQL, it would be a long,
long chain of annoying, meaningless commits.  In git speak, it would
be work in a local branch, experimenting that I would not like to push
out before I arrive at a reasonable state and clean it up.

The question I was asking is - given that I do build uncommitted
packages for experimentation purposes (like, really, it's going to
explode if you touch it) - can we make it easier to get these
experimental packages out of the buildfarm?  If the experimental
catalogs can't be used for this purpose, I will continue using shell
scripts wrapping scp, pkgrm, gunzip and pkgadd.

Maciej

From dam at opencsw.org  Thu Jun  2 23:58:45 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 2 Jun 2011 23:58:45 +0200
Subject: [csw-maintainers] graphviz: pushed to unstable - problem
	analysis, solution, and next issue
In-Reply-To: <4DE803B6.2000102@opencsw.org>
References: <4DE803B6.2000102@opencsw.org>
Message-ID: <7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org>

Hi John,

Am 02.06.2011 um 23:42 schrieb John Ellson:
> Next problem:
> 
>    - Can someone advise me how to deal with the ImageMagic issue of
> depending on the older graphviz libraries?
> Maciej made changes (thank you) so that this won't be a problem next
> time, but this time its still a problem.
> 
> I think Maciej suggested shipping the old libs along with the new
> packages?   Is it kosher to just copy the old binary images
> in to the new packages?  How would I actually do that?

The "classical" approach is to use a version modulation and build all
necessary versions in one build and then merge them. As this can be tricky
the "modern" approach is to just use different recipes to build the libraries.
See for example libflac4, libflac7 and libflac8 which build the necessary
libraries. Also
  libtool/branches/libldtl3
  libttol/branches/libtool24
could be used to study the technology (please don't use the path layout
from libtool, though. The correct one is the one used for libflac*).


Best regards

  -- Dago

From ellson at opencsw.org  Fri Jun  3 00:05:31 2011
From: ellson at opencsw.org (John Ellson)
Date: Thu, 02 Jun 2011 18:05:31 -0400
Subject: [csw-maintainers] graphviz: pushed to unstable -
 problem	analysis, solution, and next issue
In-Reply-To: <7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org>
References: <4DE803B6.2000102@opencsw.org>
	<7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org>
Message-ID: <4DE8092B.4030102@opencsw.org>

Dago,

This really sounds like a lot of work for a one-time problem.

Is there an alternative?    Could graphviz-2.28.0 be installed on the
current build hosts and then ImageMagic rebuilt for a simultaneous release?

John




On 06/02/2011 05:58 PM, Dagobert Michelsen wrote:
> Hi John,
>
> Am 02.06.2011 um 23:42 schrieb John Ellson:
>> Next problem:
>>
>>    - Can someone advise me how to deal with the ImageMagic issue of
>> depending on the older graphviz libraries?
>> Maciej made changes (thank you) so that this won't be a problem next
>> time, but this time its still a problem.
>>
>> I think Maciej suggested shipping the old libs along with the new
>> packages?   Is it kosher to just copy the old binary images
>> in to the new packages?  How would I actually do that?
> The "classical" approach is to use a version modulation and build all
> necessary versions in one build and then merge them. As this can be tricky
> the "modern" approach is to just use different recipes to build the libraries.
> See for example libflac4, libflac7 and libflac8 which build the necessary
> libraries. Also
>   libtool/branches/libldtl3
>   libttol/branches/libtool24
> could be used to study the technology (please don't use the path layout
> from libtool, though. The correct one is the one used for libflac*).
>
>
> Best regards
>
>   -- Dago
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>


From phil at bolthole.com  Fri Jun  3 00:08:27 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 2 Jun 2011 15:08:27 -0700
Subject: [csw-maintainers] graphviz: pushed to unstable - problem
 analysis, solution, and next issue
In-Reply-To: <4DE8092B.4030102@opencsw.org>
References: <4DE803B6.2000102@opencsw.org>
	<7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org>
	<4DE8092B.4030102@opencsw.org>
Message-ID: <BANLkTimE01-xgb2-j7vHwDx=n4U7tB0hUg@mail.gmail.com>

On Thu, Jun 2, 2011 at 3:05 PM, John Ellson <ellson at opencsw.org> wrote:
> Dago,
>
> This really sounds like a lot of work for a one-time problem.
>
> Is there an alternative? ? ?Could graphviz-2.28.0 be installed on the
> current build hosts and then ImageMagic rebuilt for a simultaneous release?
>

that is certainly an even better solution, if there is nothing else
depending on the older libraries.

From maciej at opencsw.org  Fri Jun  3 16:38:23 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Fri, 3 Jun 2011 15:38:23 +0100
Subject: [csw-maintainers] Further improvements to our website
In-Reply-To: <BANLkTikEtVBtb83i6A2bEupzpfATWYNsmw@mail.gmail.com>
References: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
	<4DE3F9E8.7020303@wbonnet.net>
	<BANLkTikEtVBtb83i6A2bEupzpfATWYNsmw@mail.gmail.com>
Message-ID: <BANLkTikrbCejTWi1GUhMfXaZLrH51uV3oQ@mail.gmail.com>

2011/6/1 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/5/30 William Bonnet <william at wbonnet.net>:
>> 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.
>
> I will try to set it up on my virtual Solaris host to see how hard or
> easy it is. ?If I have any questions, I'll update this thread.

No luck so far.

I've installed our apache, php and mysql.  I can run phpinfo() - it
works.  What doesn't work, is installing mantis.  When enter the top
level link, I'm redirected to admin/install.php, and all I see is a
blank page.  When running via curl, it just returns:

maciej at quince:~$ curl
'http://buildfarm.home.blizinski.pl/mantisbt-1.2.5/admin/install.php'
maciej at quince:~$

I configured PHP to log to /var/tmp/php.log, but the file does not
exist (and is not created).  From my php.ini:

error_reporting  =  E_ALL
display_errors = On
log_errors = On
log_errors_max_len = 1024
error_log = "/var/tmp/php.log"

There's nothing in Apache's error_log.

I'm a bit out of ideas.  Where else can I look?

Maciej

From dam at opencsw.org  Fri Jun  3 18:04:45 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 3 Jun 2011 18:04:45 +0200
Subject: [csw-maintainers] Rebuild of imagemagick
In-Reply-To: <4DE810E0.4050502@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
Message-ID: <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>

Hi John,

Am 03.06.2011 um 00:38 schrieb John Ellson:
> OK, I'm going to try rebuilding ImageMagick against graphviz-2.28.0 for a simultaneous release.
> 
> On the current* build hosts, could you please:
> 
>     Uninstall graphviz*-2.26.3 and ImageMagick
> 
>     Install graphviz-2.28.0 and graphvizdevel-2.28.0 from the unstable catalog.

Umh, the usual procedure is to just update unstable and build graphviz there.
I am doing this now, ok?

BTW, Roger had quite some effort in a 64 bit Imagemagick:
  http://wiki.opencsw.org/project-imagemagick64
Maybe we can continue this project and finish up in a joint effort?

Roger: Haven't heard from you in a while, everything ok? :-)


Best regards

  -- Dago

> 
> Thanks.
> 
> John
> 
> -------- Original Message --------
> Subject:	Re: [csw-maintainers] graphviz: pushed to unstable - problem analysis, solution, and next issue
> Date:	Thu, 2 Jun 2011 15:08:27 -0700
> From:	Philip Brown <phil at bolthole.com>
> Reply-To:	List for OpenCSW maintainers <maintainers at lists.opencsw.org>
> To:	List for OpenCSW maintainers <maintainers at lists.opencsw.org>
> 
> On Thu, Jun 2, 2011 at 3:05 PM, John Ellson <ellson at opencsw.org> wrote:
> > Dago,
> >
> > This really sounds like a lot of work for a one-time problem.
> >
> > Is there an alternative?    Could graphviz-2.28.0 be installed on the
> > current build hosts and then ImageMagic rebuilt for a simultaneous release?
> >
> 
> that is certainly an even better solution, if there is nothing else
> depending on the older libraries.
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
> 
> _______________________________________________
> buildfarm mailing list
> buildfarm at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/buildfarm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110603/0a34d9e6/attachment.html>

From phil at bolthole.com  Fri Jun  3 18:13:22 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 3 Jun 2011 09:13:22 -0700
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
Message-ID: <BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>

> Umh, the usual procedure is to just update unstable and build graphviz there.
> I am doing this now, ok?
> BTW, Roger had quite some effort in a 64 bit Imagemagick:
> ??http://wiki.opencsw.org/project-imagemagick64
> Maybe we can continue this project and finish up in a joint effort?

Or, since existing is not 64bit... perhaps just do a 32bit rebuild to
fix this problem, and focus on 64bit for later.
No need to make the existing workload on this multi-level project
larger than it already is.

From ellson at opencsw.org  Fri Jun  3 18:29:15 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 03 Jun 2011 12:29:15 -0400
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>
References: <4DE810E0.4050502@opencsw.org>	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
	<BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>
Message-ID: <4DE90BDB.9040708@opencsw.org>

On 06/03/2011 12:13 PM, Philip Brown wrote:
>> Umh, the usual procedure is to just update unstable and build graphviz there.
>> I am doing this now, ok?

Absolutely.  You're expert.  I'm still learning.

>> BTW, Roger had quite some effort in a 64 bit Imagemagick:
>>    http://wiki.opencsw.org/project-imagemagick64
>> Maybe we can continue this project and finish up in a joint effort?
> Or, since existing is not 64bit... perhaps just do a 32bit rebuild to
> fix this problem, and focus on 64bit for later.
> No need to make the existing workload on this multi-level project
> larger than it already is.

Yes, I'm willing to go further with ImageMagick, but I was proposing 
just the minimal changes need to get it out with graphviz-2.28.0 as a 
first step.

John

From bwalton at opencsw.org  Fri Jun  3 18:54:44 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 03 Jun 2011 12:54:44 -0400
Subject: [csw-maintainers] time to deprecate CSWmozilla
Message-ID: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>


Hi All,

As CSWmozilla is currently squatting on some nspr header files and
nobody has interest in rebuilding it (we have firefox, etc), I think
we should drop it from the catalog.  Anything that packages the header
files where they belong should declare I with CSWmozilla and people
that want both on their systems will need to make a choice between
modern packages and a 5 year old mozilla.

Thoughts?

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


From bwalton at opencsw.org  Fri Jun  3 18:55:28 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 03 Jun 2011 12:55:28 -0400
Subject: [csw-maintainers] Fwd: Re: [csw-pkgsubmissions] newpkgs git,
	git_completion, git_cvs, git_dev(...)
Message-ID: <1307120105-sup-1298@pinkfloyd.chass.utoronto.ca>

Oops.  Mistyped the list address in my mailer.

Thanks
-Ben
--- Begin forwarded message from Ben Walton ---
From: Ben Walton <bwalton at opencsw.org>
To: pkgsubmissions <pkgsubmissions at lists.opencsw.org>
Cc: maintainers
Date: Fri, 03 Jun 2011 12:52:16 -0400
Subject: Re: [csw-pkgsubmissions] newpkgs git, git_completion, git_cvs, git_dev(...)

Excerpts from Philip Brown's message of Fri Jun 03 11:46:30 -0400 2011:

> A slight adjustment, since Dagobert just posted on the maintainers
> list that he changed his position on the issue(and he suggested that
> we proceed that way without voting):
> Will you now act in the way you seem to think I should act, and change
> *your* position?

Fine.  It's not worth a vote over something so dumb.  I think that
filename grouping is a bit more useful than searching the catalog, but
still not much, imo.  Either way, I can see that I'm now the minority
position.

> Or will you insist on having a vote?

No, I value the time of all involved and wouldn't waste it on
something like this.

> either way, it would be beneficial to see an official notice on how
> things will work.
> ie: a writeup by "the board", on how official votes are triggered.

Sure.  Once I've cleared a few other things away I'll sit down and
draft something.

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


From ellson at opencsw.org  Fri Jun  3 19:27:26 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 03 Jun 2011 13:27:26 -0400
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <4DE90BDB.9040708@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>	<BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>
	<4DE90BDB.9040708@opencsw.org>
Message-ID: <4DE9197E.4030000@opencsw.org>

I took a look at the 64bit Imagemagick wiki page (nice job, btw).

AFAICT the current state of the 64bit builds is:

     imagemagick (Roger) depends on
         graphviz (John) depends on
             ghostscript (John) depends on
                 libcups (Dago) depends on
                     krb5_lib (Maciej)


Is there any status update on krb5_lib and libcups?    Should I be 
trying a ghostscript 64bit build?

John



On 06/03/2011 12:29 PM, John Ellson wrote:
> On 06/03/2011 12:13 PM, Philip Brown wrote:
>>> Umh, the usual procedure is to just update unstable and build 
>>> graphviz there.
>>> I am doing this now, ok?
>
> Absolutely.  You're expert.  I'm still learning.
>
>>> BTW, Roger had quite some effort in a 64 bit Imagemagick:
>>>    http://wiki.opencsw.org/project-imagemagick64
>>> Maybe we can continue this project and finish up in a joint effort?
>> Or, since existing is not 64bit... perhaps just do a 32bit rebuild to
>> fix this problem, and focus on 64bit for later.
>> No need to make the existing workload on this multi-level project
>> larger than it already is.
>
> Yes, I'm willing to go further with ImageMagick, but I was proposing 
> just the minimal changes need to get it out with graphviz-2.28.0 as a 
> first step.
>
> John
> _______________________________________________
> 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 Jun  3 19:35:31 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 3 Jun 2011 10:35:31 -0700
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <4DE9197E.4030000@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
	<BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>
	<4DE90BDB.9040708@opencsw.org> <4DE9197E.4030000@opencsw.org>
Message-ID: <BANLkTim=S9pnnRgSdRaQdr0w7qeiQx5ADw@mail.gmail.com>

On Fri, Jun 3, 2011 at 10:27 AM, John Ellson <ellson at opencsw.org> wrote:
> I took a look at the 64bit Imagemagick wiki page (nice job, btw).
>
> AFAICT the current state of the 64bit builds is:
>
> ? ?imagemagick (Roger) depends on
> ? ? ? ?graphviz (John) depends on
> ? ? ? ? ? ?ghostscript (John) depends on
> ? ? ? ? ? ? ? ?libcups (Dago) depends on
> ? ? ? ? ? ? ? ? ? ?krb5_lib (Maciej)
>
>
> Is there any status update on krb5_lib and libcups? ? ?Should I be trying a
> ghostscript 64bit build?

A side comment:

Sometimes, it is okay to have a 64bit library with "less" features,
than no 64bit at all.

So, at any point in the chain there, you might make a choice of, "oh
well, it would be nice to have [gs/cups/krb support] some day, but for
now, I'm just going to unplug the 64bit pipeline."
(Although of course, you need to document this very strongly if you
choose this path)

What makes a good choice of choosing a cutoff point, is when the stuff
you are chopping is not used by the top level.
The idea situation being, that , when "someday" comes... since
imagemagic does not directly use krb5 or cups(?), the library upgrade
lower down, will be transparent.

From phil at bolthole.com  Fri Jun  3 19:43:55 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 3 Jun 2011 10:43:55 -0700
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>

On Fri, Jun 3, 2011 at 9:54 AM, Ben Walton <bwalton at opencsw.org> wrote:
>
> Hi All,
>
> As CSWmozilla is currently squatting on some nspr header files and
> nobody has interest in rebuilding it (we have firefox, etc), I think
> we should drop it from the catalog. ?Anything that packages the header
> files where they belong should declare I with CSWmozilla and people
> that want both on their systems will need to make a choice between
> modern packages and a 5 year old mozilla.
>

Actually, I think "seamonkey" was already supposed to "replace"
mozilla for most everyone that cared. we most likely only kept it
around for header files.

There's just a question remaining, about what to do about the 2
packages that depend on it.
They are both rather old.. (and orphaned), but unfortunately, both
sound somewhat useful.

epiphany	The web browser for the GNOME Desktop
liferea	news aggregator for online news feeds

From ellson at opencsw.org  Fri Jun  3 19:44:36 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 03 Jun 2011 13:44:36 -0400
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <BANLkTim=S9pnnRgSdRaQdr0w7qeiQx5ADw@mail.gmail.com>
References: <4DE810E0.4050502@opencsw.org>	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>	<BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>	<4DE90BDB.9040708@opencsw.org>
	<4DE9197E.4030000@opencsw.org>
	<BANLkTim=S9pnnRgSdRaQdr0w7qeiQx5ADw@mail.gmail.com>
Message-ID: <4DE91D84.8000908@opencsw.org>

On 06/03/2011 01:35 PM, Philip Brown wrote:
> On Fri, Jun 3, 2011 at 10:27 AM, John Ellson<ellson at opencsw.org>  wrote:
>> I took a look at the 64bit Imagemagick wiki page (nice job, btw).
>>
>> AFAICT the current state of the 64bit builds is:
>>
>>     imagemagick (Roger) depends on
>>         graphviz (John) depends on
>>             ghostscript (John) depends on
>>                 libcups (Dago) depends on
>>                     krb5_lib (Maciej)
>>
>>
>> Is there any status update on krb5_lib and libcups?    Should I be trying a
>> ghostscript 64bit build?
> A side comment:
>
> Sometimes, it is okay to have a 64bit library with "less" features,
> than no 64bit at all.
>
> So, at any point in the chain there, you might make a choice of, "oh
> well, it would be nice to have [gs/cups/krb support] some day, but for
> now, I'm just going to unplug the 64bit pipeline."
> (Although of course, you need to document this very strongly if you
> choose this path)
>
> What makes a good choice of choosing a cutoff point, is when the stuff
> you are chopping is not used by the top level.
> The idea situation being, that , when "someday" comes... since
> imagemagic does not directly use krb5 or cups(?), the library upgrade
> lower down, will be transparent.
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

Yes, I was thinking that it would be easy to drop the ghostscript plugin 
from graphviz.
(Its used to import custom node shapes in PostScript - a feature that 
isn't used much, better to use SVG these days anyway.)

It would also be easy to drop the graphviz dependency from ghostscript.

But, if the goal is to use ImageMagic to drive the creation of a 64bit 
distribution, then there is less point in taking shortcuts.


John

From ellson at opencsw.org  Fri Jun  3 19:46:58 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 03 Jun 2011 13:46:58 -0400
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <4DE91D84.8000908@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>	<BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>	<4DE90BDB.9040708@opencsw.org>	<4DE9197E.4030000@opencsw.org>	<BANLkTim=S9pnnRgSdRaQdr0w7qeiQx5ADw@mail.gmail.com>
	<4DE91D84.8000908@opencsw.org>
Message-ID: <4DE91E12.7040005@opencsw.org>

On 06/03/2011 01:44 PM, John Ellson wrote:
> On 06/03/2011 01:35 PM, Philip Brown wrote:
>> On Fri, Jun 3, 2011 at 10:27 AM, John Ellson<ellson at opencsw.org>  wrote:
>>> I took a look at the 64bit Imagemagick wiki page (nice job, btw).
>>>
>>> AFAICT the current state of the 64bit builds is:
>>>
>>>     imagemagick (Roger) depends on
>>>         graphviz (John) depends on
>>>             ghostscript (John) depends on
>>>                 libcups (Dago) depends on
>>>                     krb5_lib (Maciej)
>>>
>>>
>>> Is there any status update on krb5_lib and libcups?    Should I be 
>>> trying a
>>> ghostscript 64bit build?
>> A side comment:
>>
>> Sometimes, it is okay to have a 64bit library with "less" features,
>> than no 64bit at all.
>>
>> So, at any point in the chain there, you might make a choice of, "oh
>> well, it would be nice to have [gs/cups/krb support] some day, but for
>> now, I'm just going to unplug the 64bit pipeline."
>> (Although of course, you need to document this very strongly if you
>> choose this path)
>>
>> What makes a good choice of choosing a cutoff point, is when the stuff
>> you are chopping is not used by the top level.
>> The idea situation being, that , when "someday" comes... since
>> imagemagic does not directly use krb5 or cups(?), the library upgrade
>> lower down, will be transparent.
>> _______________________________________________
>> maintainers mailing list
>> maintainers at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/maintainers
>> .:: This mailing list's archive is public. ::.
>>
>
> Yes, I was thinking that it would be easy to drop the ghostscript 
> plugin from graphviz.
> (Its used to import custom node shapes in PostScript - a feature that 
> isn't used much, better to use SVG these days anyway.)
>
> It would also be easy to drop the graphviz dependency from ghostscript.

Sorry.  I meant to say: "... from ImageMagick"

>
> But, if the goal is to use ImageMagic to drive the creation of a 64bit 
> distribution, then there is less point in taking shortcuts.
>
>
> John
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>


From bwalton at opencsw.org  Fri Jun  3 19:57:34 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 03 Jun 2011 13:57:34 -0400
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
Message-ID: <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Jun 03 13:43:55 -0400 2011:

> Actually, I think "seamonkey" was already supposed to "replace"
> mozilla for most everyone that cared. we most likely only kept it
> around for header files.

I think that's likely right.

> There's just a question remaining, about what to do about the 2
> packages that depend on it.
> They are both rather old.. (and orphaned), but unfortunately, both
> sound somewhat useful.
> 
> epiphany    The web browser for the GNOME Desktop
> liferea    news aggregator for online news feeds

Both of these will be vulnerable to all the same exploits as the
ancient mozilla since they use its rendering engine.  Let's remove
them too...unless somebody wants to modernize them?

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


From phil at bolthole.com  Fri Jun  3 20:15:24 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 3 Jun 2011 11:15:24 -0700
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>

On Fri, Jun 3, 2011 at 10:57 AM, Ben Walton <bwalton at opencsw.org> wrote:
>
>> epiphany ? ?The web browser for the GNOME Desktop
>> liferea ? ?news aggregator for online news feeds
>
> Both of these will be vulnerable to all the same exploits as the
> ancient mozilla since they use its rendering engine. ?Let's remove
> them too...unless somebody wants to modernize them?
>

I would guess they could be recompiled against seamonkey.

a quick googling for seamonkey indicates that people have been
compiling it against seamonkey for some time.

From phil at bolthole.com  Fri Jun  3 20:15:53 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 3 Jun 2011 11:15:53 -0700
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
Message-ID: <BANLkTikvDYa5QFw0ZYqcWma8UW5sFqLJUQ@mail.gmail.com>

On Fri, Jun 3, 2011 at 11:15 AM, Philip Brown <phil at bolthole.com> wrote:
> On Fri, Jun 3, 2011 at 10:57 AM, Ben Walton <bwalton at opencsw.org> wrote:
>>
>>> epiphany ? ?The web browser for the GNOME Desktop
>>> liferea ? ?news aggregator for online news feeds
>>
>> Both of these will be vulnerable to all the same exploits as the
>> ancient mozilla since they use its rendering engine. ?Let's remove
>> them too...unless somebody wants to modernize them?
>>
>
> I would guess they could be recompiled against seamonkey.
>
> a quick googling for seamonkey indicates that people have been
> compiling it against seamonkey for some time.



Doh.
lifearea + seamonkey

From phil at bolthole.com  Fri Jun  3 23:53:46 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 3 Jun 2011 14:53:46 -0700
Subject: [csw-maintainers] initialization problem: struct + union
Message-ID: <BANLkTi=Avk22e+vFdTwxn4q=bN_gFWf0gA@mail.gmail.com>

Hitting a problem trying to get something to compile with sun cc.
problem is auto-definition of a struct that has a union in it.
I forget what the hack is, to get sun cc to accept this sort of thing :(

A chopped down version, which compiles with gcc, but fails under sun cc:
( complains about the    {integer:2}  thing at bottom)




#include <stdio.h>
union types {
  char *string;
  int integer;
};
typedef struct {
  char *option;
  int type;
  union types default_value;
} config_opt_t;

#define INTEGER 1

config_opt_t config_opts[] = {
  { "snmp_timeout", INTEGER, {integer:2} },
};

From maciej at opencsw.org  Sat Jun  4 09:02:47 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 4 Jun 2011 08:02:47 +0100
Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick
In-Reply-To: <4DE9197E.4030000@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
	<BANLkTinb+bv96F_n+79jitfjTjNhmekCbw@mail.gmail.com>
	<4DE90BDB.9040708@opencsw.org> <4DE9197E.4030000@opencsw.org>
Message-ID: <BANLkTi=Emo=phzHkkxJKj0jzXPEGzwU+GA@mail.gmail.com>

2011/6/3 John Ellson <ellson at opencsw.org>:
> I took a look at the 64bit Imagemagick wiki page (nice job, btw).
>
> AFAICT the current state of the 64bit builds is:
>
> ? ?imagemagick (Roger) depends on
> ? ? ? ?graphviz (John) depends on
> ? ? ? ? ? ?ghostscript (John) depends on
> ? ? ? ? ? ? ? ?libcups (Dago) depends on
> ? ? ? ? ? ? ? ? ? ?krb5_lib (Maciej)

Slight correction:

krb5_lib is maintained by Dago, and libcups is maintained by me.

Maciej

From maciej at opencsw.org  Sat Jun  4 11:17:20 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 4 Jun 2011 10:17:20 +0100
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
Message-ID: <BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>

Em 03/06/2011 19:15, "Philip Brown" <phil at bolthole.com> escreveu:
>
> On Fri, Jun 3, 2011 at 10:57 AM, Ben Walton <bwalton at opencsw.org> wrote:
> >
> >> epiphany    The web browser for the GNOME Desktop
> >> liferea    news aggregator for online news feeds
> >
> > Both of these will be vulnerable to all the same exploits as the
> > ancient mozilla since they use its rendering engine.  Let's remove
> > them too...unless somebody wants to modernize them?
> >
>
> I would guess they could be recompiled against seamonkey.
>
> a quick googling for seamonkey indicates that people have been
> compiling it against seamonkey for some time.

What next steps do you suggest?

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110604/6da0fa35/attachment.html>

From phil at bolthole.com  Sat Jun  4 17:18:52 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 4 Jun 2011 08:18:52 -0700
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
Message-ID: <BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>

2011/6/4 Maciej Blizi?ski <maciej at opencsw.org>:
> Em 03/06/2011 19:15, "Philip Brown" <phil at bolthole.com> escreveu:
>
>> I would guess they could be recompiled against seamonkey.
>>
>> a quick googling for seamonkey indicates that people have been
>> compiling it against seamonkey for some time.
>
> What next steps do you suggest?
>

I would suggest that someone who is interested in repackaging them,
attempt to compile against seamonkey. and if it fails, pull up the
relevant patches, and try it again. debian and ubuntu seem to have
patches, according to google

From ellson at opencsw.org  Sat Jun  4 19:06:19 2011
From: ellson at opencsw.org (John Ellson)
Date: Sat, 04 Jun 2011 13:06:19 -0400
Subject: [csw-maintainers] how to set up a local buildhost?
Message-ID: <4DEA660B.4080102@opencsw.org>

Now that I have Solaris-10 running on a virtual host locally, is there
an easy way I can set it up as a buildhost?

If I could do that, I could use it to build the graphviz nightly
development snapshots.

John

From ellson at opencsw.org  Sat Jun  4 19:35:56 2011
From: ellson at opencsw.org (John Ellson)
Date: Sat, 04 Jun 2011 13:35:56 -0400
Subject: [csw-maintainers] pkg-config failure unstable9[xs]
Message-ID: <4DEA6CFC.7060500@opencsw.org>

The ImageMagick builds on unstable9[sx] are failing with:

    libtool: compile:  /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I.
-I./config -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt  
/csw/X11/include -I/opt/csw/include -I/opt/csw/X11/include
-I/opt/csw/include/libxml2 -I/opt/csw/include/lqr-1
-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -xopenmp
-xO3 -m32 -xarch=v8 -D_REENTRANT -c coders/svg.c  -KPIC -DPIC -o
coders/.libs/coders_svg_la-svg.o
    "coders/svg.c", line 93: cannot find include file: "librsvg/rsvg.h"
    "coders/svg.c", line 95: cannot find include file:
"librsvg/rsvg-cairo.h"
    "coders/svg.c", line 97: cannot find include file:
"librsvg/librsvg-features.h"


Is the librvg on unstable9[xs] out of date?   Or possibly pixman?

ellson at unstable9s:ellson> pkg-config --cflags librsvg-2.0
sh: gnome-config: not found
Package pixman-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `pixman-1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pixman-1', required by 'cairo', not found

ellson at current9s:ellson> pkg-config --cflags librsvg-2.0
-D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS
-DXUSE_MTSAFE_API -I/opt/csw/include/librsvg-2
-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include
-I/opt/csw/include/gtk-2.0 -I/opt/csw/include/cairo
-I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2
-I/opt/csw/include -I/opt/csw/include/libpng12 


John

From maciej at opencsw.org  Sat Jun  4 19:51:21 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 4 Jun 2011 18:51:21 +0100
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <4DEA660B.4080102@opencsw.org>
References: <4DEA660B.4080102@opencsw.org>
Message-ID: <BANLkTinjeVyx-WTtEz1g1gBAtF9cUE1gCQ@mail.gmail.com>

Em 04/06/2011 18:06, "John Ellson" <ellson at opencsw.org> escreveu:
>
> Now that I have Solaris-10 running on a virtual host locally, is there
> an easy way I can set it up as a buildhost?
>
> If I could do that, I could use it to build the graphviz nightly
> development snapshots.

It is an excellent idea to set up a build host!

I have a partly written howto document. I can send you a copy and help you
with any issues you might run into along the way.

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110604/0ca68235/attachment.html>

From phil at bolthole.com  Sat Jun  4 21:42:55 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 4 Jun 2011 12:42:55 -0700
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <4DEA660B.4080102@opencsw.org>
References: <4DEA660B.4080102@opencsw.org>
Message-ID: <BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>

On Sat, Jun 4, 2011 at 10:06 AM, John Ellson <ellson at opencsw.org> wrote:
> Now that I have Solaris-10 running on a virtual host locally, is there
> an easy way I can set it up as a buildhost?
>
> If I could do that, I could use it to build the graphviz nightly
> development snapshots.

err.. what do you mean by buildhost?

one that all maintainers can use? or just personal?

If personal, it should be as easy as just
"install the packages you need. install suncc. go compile stuff"
:)

(and if it isnt, we need to improve it, so it's easier for our users
to do compiles themselves)

From ellson at opencsw.org  Sat Jun  4 21:55:16 2011
From: ellson at opencsw.org (John Ellson)
Date: Sat, 04 Jun 2011 15:55:16 -0400
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>
References: <4DEA660B.4080102@opencsw.org>
	<BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>
Message-ID: <4DEA8DA4.8000304@opencsw.org>

On 06/04/2011 03:42 PM, Philip Brown wrote:
> On Sat, Jun 4, 2011 at 10:06 AM, John Ellson <ellson at opencsw.org> wrote:
>> Now that I have Solaris-10 running on a virtual host locally, is there
>> an easy way I can set it up as a buildhost?
>>
>> If I could do that, I could use it to build the graphviz nightly
>> development snapshots.
> err.. what do you mean by buildhost?
>
> one that all maintainers can use? or just personal?

Just for me personally to build on.  I want to generate binary packages
from the latest development sources, that can be installed in
/opt/csw/.  I'd make these nightly development packages available on
http://www.graphviz.org.   

I do this now for rpms, and debs, and MacOS pkgs


> If personal, it should be as easy as just
> "install the packages you need. install suncc. go compile stuff"
> :)

What about gar scripts?   Just "pkg-get -i gar" ?

What about catalog support for a graphviz.org collection?

> (and if it isnt, we need to improve it, so it's easier for our users
> to do compiles themselves)
> _______________________________________________

John

From bwalton at opencsw.org  Sun Jun  5 02:07:57 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 04 Jun 2011 20:07:57 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure
	unstable9[xs]
In-Reply-To: <4DEA6CFC.7060500@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>
Message-ID: <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Sat Jun 04 13:35:56 -0400 2011:

> Is the librvg on unstable9[xs] out of date?   Or possibly pixman?

I just installed CSWlibpixman-dev on the unstable* hosts.  It wasn't
there at all.  That seems to make unstable9x look like current9x.

Let me know if you spot any other issues.

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


From bwalton at opencsw.org  Sun Jun  5 04:33:18 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 04 Jun 2011 22:33:18 -0400
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <4DEA8DA4.8000304@opencsw.org>
References: <4DEA660B.4080102@opencsw.org>
	<BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>
	<4DEA8DA4.8000304@opencsw.org>
Message-ID: <1307241076-sup-4963@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Sat Jun 04 15:55:16 -0400 2011:

Hi John,

> What about gar scripts?   Just "pkg-get -i gar" ?

You'll want to do:

pkgutil -i CSWgar-dev

In a day or so when Phil has pushed CSWmgar, you can either add that
manually or update CSWgar-dev to pull it in too.  With mgar installed,
you can follow the instructions at:
http://wiki.opencsw.org/gar-wrapper

> What about catalog support for a graphviz.org collection?

There is buildcat for this.  I haven't used it myself, but Peter or
Dago could help with this as they're quite familiar with it.

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


From phil at bolthole.com  Sun Jun  5 05:29:42 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 4 Jun 2011 20:29:42 -0700
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <4DEA8DA4.8000304@opencsw.org>
References: <4DEA660B.4080102@opencsw.org>
	<BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>
	<4DEA8DA4.8000304@opencsw.org>
Message-ID: <BANLkTi=CXUw9Ywtt2Noa0m=w4GFXM6aUYQ@mail.gmail.com>

On Sat, Jun 4, 2011 at 12:55 PM, John Ellson <ellson at opencsw.org> wrote:
>
> What about catalog support for a graphviz.org collection?

I'm not sure what you mean by that.

From james at opencsw.org  Sun Jun  5 10:24:13 2011
From: james at opencsw.org (James Lee)
Date: Sun, 05 Jun 2011 08:24:13 GMT
Subject: [csw-maintainers] initialization problem: struct + union
In-Reply-To: <BANLkTi=Avk22e+vFdTwxn4q=bN_gFWf0gA@mail.gmail.com>
References: <BANLkTi=Avk22e+vFdTwxn4q=bN_gFWf0gA@mail.gmail.com>
Message-ID: <20110605.8241300.1660397962@gyor.oxdrove.co.uk>

On 03/06/11, 22:53:46, Philip Brown <phil at bolthole.com> wrote regarding
[csw-maintainers] initialization problem: struct + union:

> A chopped down version, which compiles with gcc, but fails under sun cc:
> ( complains about the    {integer:2}  thing at bottom)


> #include <stdio.h>
> union types {
>   char *string;
>   int integer;
> };
> typedef struct {
>   char *option;
>   int type;
>   union types default_value;
> } config_opt_t;

> #define INTEGER 1

> config_opt_t config_opts[] = {
>   { "snmp_timeout", INTEGER, {integer:2} },
> };


Remove the type qualifier and it compiles with just a warning.

config_opt_t config_opts[] = {
  { "snmp_timeout", INTEGER, 2 },
};


Simple case warning avoidance, declare integer first:

union types {
   int integer;
   char *string;
};




Extending the code to use both types in the union this complies with
warning and runs:



$ cat test.c
#include <stdio.h>
union types {
  char *string;
  int integer;
};
typedef struct {
  char *option;
  int type;
  union types default_value;
} config_opt_t;

#define INTEGER 1
#define STRING 2

config_opt_t config_opts[] = {
  { "snmp_timeout", INTEGER, 2 },
  { "snmp_message", STRING, "time out exceeded" },
};


int main(int argc, char* argv[])
{
    int i;
    for (i = 0; i < sizeof(config_opts) / sizeof(config_opt_t); i++) {
        switch (config_opts[i].type) {
            case INTEGER:
                printf("%s: %d\n", config_opts[i].option,
                                   config_opts[i].default_value.integer);
                break;
            case STRING:
                printf("%s: %s\n", config_opts[i].option,
                                   config_opts[i].default_value.string);
                break;
        }
    }
    return 0;
}
$ cc test.c
"test.c", line 16: warning: improper pointer/integer combination: op "="
$ ./a.out
snmp_timeout: 2
snmp_message: time out exceeded





James.

From bwalton at opencsw.org  Sun Jun  5 14:37:03 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 08:37:03 -0400
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <BANLkTi=CXUw9Ywtt2Noa0m=w4GFXM6aUYQ@mail.gmail.com>
References: <4DEA660B.4080102@opencsw.org>
	<BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>
	<4DEA8DA4.8000304@opencsw.org>
	<BANLkTi=CXUw9Ywtt2Noa0m=w4GFXM6aUYQ@mail.gmail.com>
Message-ID: <1307277386-sup-4020@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sat Jun 04 23:29:42 -0400 2011:
> On Sat, Jun 4, 2011 at 12:55 PM, John Ellson <ellson at opencsw.org> wrote:
> >
> > What about catalog support for a graphviz.org collection?
> 
> I'm not sure what you mean by that.

He wants the ability to build a catalog from his local set similar to
what we do for the experimental repos.  It could then be fed to
pkgutil -t, etc.

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


From bwalton at opencsw.org  Sun Jun  5 15:01:59 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 09:01:59 -0400
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
Message-ID: <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sat Jun 04 11:18:52 -0400 2011:

> I would suggest that someone who is interested in repackaging them,
> attempt to compile against seamonkey. and if it fails, pull up the
> relevant patches, and try it again. debian and ubuntu seem to have
> patches, according to google

If someone were interested in packaging them, they would have done so
already.  Why not abandon them until such time as somebody does have
interest so that we can stop blocking progress on the nspr issue that
people do care about?

I suggest we remove all three from the catalog.

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


From ellson at opencsw.org  Sun Jun  5 15:30:15 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 09:30:15 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure
	unstable9[xs]
In-Reply-To: <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>
References: <4DEA6CFC.7060500@opencsw.org>
	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>
Message-ID: <4DEB84E7.3030609@opencsw.org>

On 06/04/2011 08:07 PM, Ben Walton wrote:
> I just installed CSWlibpixman-dev on the unstable* hosts.  It wasn't
> there at all.  That seems to make unstable9x look like current9x.

Thanks
> Let me know if you spot any other issues.

I believe the libxml2 package on current9[xs] is newer than on
unstable9[sx] ?
>From diff'ing the two /opt/csw/include/libxml2/libxml/xmlversion.h I get:

< #define LIBXML_DOTTED_VERSION "2.7.8"
---
> #define LIBXML_DOTTED_VERSION "2.7.7"


This is causing some unresolved symbols in ImageMagick.   Could you
update CSWlibxml2 on unstable please?

[ BTW How to I list  the installed package with its package version
number?   "pkg-get -l" just gives me the name ]


I'm also seeing a problem with Undefined symbol:
    XSolarisIASetProcessInfo            /lib/libX11.so.4

Is that something you might recognise?

John


From dam at opencsw.org  Sun Jun  5 15:55:04 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 5 Jun 2011 15:55:04 +0200
Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure
	unstable9[xs]
In-Reply-To: <4DEB84E7.3030609@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>
	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>
	<4DEB84E7.3030609@opencsw.org>
Message-ID: <C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>

Hi John,

Am 05.06.2011 um 15:30 schrieb John Ellson:
> On 06/04/2011 08:07 PM, Ben Walton wrote:
>> I just installed CSWlibpixman-dev on the unstable* hosts.  It wasn't
>> there at all.  That seems to make unstable9x look like current9x.
> 
> Thanks
>> Let me know if you spot any other issues.
> 
> I believe the libxml2 package on current9[xs] is newer than on
> unstable9[sx] ?
> From diff'ing the two /opt/csw/include/libxml2/libxml/xmlversion.h I get:
> < #define LIBXML_DOTTED_VERSION "2.7.8"
> ---
>> #define LIBXML_DOTTED_VERSION "2.7.7"
> 
> 
> This is causing some unresolved symbols in ImageMagick.   Could you
> update CSWlibxml2 on unstable please?

This does not look good:

unstable9x# pkgutil -c libxml2
package                   installed                 catalog
CSWlibxml2                2.7.8,REV=2011.03.21      SAME                     
CSWlibxml2-2              2.7.8,REV=2011.03.24      SAME                     
CSWlibxml2devel           2.7.7,REV=2010.04.10      SAME                     

Ben: Would you mind having a look and re-release the devel package?

> [ BTW How to I list  the installed package with its package version
> number?   "pkg-get -l" just gives me the name ]

Try
  pkgutil -c libxml2
as seen above.

> I'm also seeing a problem with Undefined symbol:
>    XSolarisIASetProcessInfo            /lib/libX11.so.4
> 
> Is that something you might recognise?

Yes, these are still artifacts from
  http://wiki.opencsw.org/project-x11
where we tried to build the complete set against an OpenCSW X11. However,
this doesn't prove good and the above error is an indication of mixed
libx11.so.4 and libx11.so.6 linkage. The correct action is to find the
"old" package and rebuild it against SUNW x11.


Best regards

  -- Dago


From ellson at opencsw.org  Sun Jun  5 16:11:13 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 10:11:13 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config
	failure	unstable9[xs]
In-Reply-To: <C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>	<4DEB84E7.3030609@opencsw.org>
	<C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
Message-ID: <4DEB8E81.1070700@opencsw.org>

On 06/05/2011 09:55 AM, Dagobert Michelsen wrote:
> I'm also seeing a problem with Undefined symbol:
>>    XSolarisIASetProcessInfo            /lib/libX11.so.4
>>
>> Is that something you might recognise?
> Yes, these are still artifacts from
>   http://wiki.opencsw.org/project-x11
> where we tried to build the complete set against an OpenCSW X11. However,
> this doesn't prove good and the above error is an indication of mixed
> libx11.so.4 and libx11.so.6 linkage. The correct action is to find the
> "old" package and rebuild it against SUNW x11.

Possibly librsvg-2 ?

ellson at current9s:ellson> ldd /opt/csw/lib/librsvg-2.so | grep libX
        libXrender.so.1 =>       /opt/csw/lib/sparcv8/libXrender.so.1
        libX11.so.4 =>   /usr/lib/libX11.so.4
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0


From ellson at opencsw.org  Sun Jun  5 16:40:21 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 10:40:21 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config
	failure	unstable9[xs]
In-Reply-To: <C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>	<4DEB84E7.3030609@opencsw.org>
	<C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
Message-ID: <4DEB9555.7040107@opencsw.org>

On 06/05/2011 09:55 AM, Dagobert Michelsen wrote:
>
>> I'm also seeing a problem with Undefined symbol:
>>    XSolarisIASetProcessInfo            /lib/libX11.so.4
>>
>> Is that something you might recognise?
> Yes, these are still artifacts from
>   http://wiki.opencsw.org/project-x11
> where we tried to build the complete set against an OpenCSW X11. However,
> this doesn't prove good and the above error is an indication of mixed
> libx11.so.4 and libx11.so.6 linkage. The correct action is to find the
> "old" package and rebuild it against SUNW x11.
>

Not sure if these cause any problems, but I noticed that these x11
packages are installed on unstable but not on current.

CSWx11common              1.0,REV=2009.05.24       
SAME                    
CSWx11kbproto             1.0.4,REV=2010.02.20     
SAME                    
CSWx11xextproto           7.1.1,REV=2010.02.20     
SAME                    
CSWx11xproto              7.0.16,REV=2010.02.20     SAME         

From ellson at opencsw.org  Sun Jun  5 17:00:41 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 11:00:41 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config
	failure	unstable9[xs]
In-Reply-To: <C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>	<4DEB84E7.3030609@opencsw.org>
	<C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
Message-ID: <4DEB9A19.1020403@opencsw.org>

On 06/05/2011 09:55 AM, Dagobert Michelsen wrote:
>
>> I'm also seeing a problem with Undefined symbol:
>>    XSolarisIASetProcessInfo            /lib/libX11.so.4
>>
>> Is that something you might recognise?
> Yes, these are still artifacts from
>   http://wiki.opencsw.org/project-x11
> where we tried to build the complete set against an OpenCSW X11. However,
> this doesn't prove good and the above error is an indication of mixed
> libx11.so.4 and libx11.so.6 linkage. The correct action is to find the
> "old" package and rebuild it against SUNW x11.


I think I'm seeing the same problem I had with graphviz.   If there are
installed .so for the package from an old installation then libtool
tries to link them into the new build.

I can't find any libX11.so.4 in any products in the build tree, but I do
find it in:
    ellson at unstable9s:lib> ldd libMagick.so.10.0.4 | grep X11
        libX11.so.4 =>   /usr/openwin/lib/libX11.so.4

ImageMagic doesn't have a -devel package, so could you please uninstall
ImageMagic entirely from unstable6[sx]
while I try rebuilding?


John

From ellson at opencsw.org  Sun Jun  5 18:34:45 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 12:34:45 -0400
Subject: [csw-maintainers] gar and php question
Message-ID: <4DEBB025.6010702@opencsw.org>

I'm trying to build the php extension for graphviz.

The configure file looks for a php executable to use to extract php
configuration details.

It expects "php" in the regular PATH, but the opencsw php is installed
in /opt/csw/php5/bin/php.


I've tried adding this to my PATH, but configure still doesn't find it.

Q1.  Does GAR restrict or override PATH during builds?

Q2.  Could php be installed (perhaps as a softlink, perhaps as an
alternative) in /opt/csw/bin ?


John

From phil at bolthole.com  Sun Jun  5 19:03:53 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 5 Jun 2011 10:03:53 -0700
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
	<1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>

On Sun, Jun 5, 2011 at 6:01 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Sat Jun 04 11:18:52 -0400 2011:
>
>> I would suggest that someone who is interested in repackaging them,
>> attempt to compile against seamonkey. and if it fails, pull up the
>> relevant patches, and try it again. debian and ubuntu seem to have
>> patches, according to google
>
> If someone were interested in packaging them, they would have done so
> already.

so you're suggesting that from now on, no-one should ever bother
requesting anyone take over orphaned packages, becuase "if anyone were
interested in packaging them, they would have done so already".

we can wait a week.

From phil at bolthole.com  Sun Jun  5 19:07:49 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 5 Jun 2011 10:07:49 -0700
Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure
	unstable9[xs]
In-Reply-To: <4DEB9555.7040107@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>
	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>
	<4DEB84E7.3030609@opencsw.org>
	<C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
	<4DEB9555.7040107@opencsw.org>
Message-ID: <BANLkTi=3UY0bkzTMmwBUH9_Vrw6KLbk2sw@mail.gmail.com>

On Sun, Jun 5, 2011 at 7:40 AM, John Ellson <ellson at opencsw.org> wrote:
>
>
> Not sure if these cause any problems, but I noticed that these x11
> packages are installed on unstable but not on current.
>
> CSWx11common ? ? ? ? ? ? ?1.0,REV=2009.05.24
> SAME
> CSWx11kbproto ? ? ? ? ? ? 1.0.4,REV=2010.02.20
> SAME
> CSWx11xextproto ? ? ? ? ? 7.1.1,REV=2010.02.20
> SAME
> CSWx11xproto ? ? ? ? ? ? ?7.0.16,REV=2010.02.20 ? ? SAME
>

it would be better if these were removed. they are probably messing things up.

From phil at bolthole.com  Sun Jun  5 19:12:50 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 5 Jun 2011 10:12:50 -0700
Subject: [csw-maintainers] gar and php question
In-Reply-To: <4DEBB025.6010702@opencsw.org>
References: <4DEBB025.6010702@opencsw.org>
Message-ID: <BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>

>Q2.  Could php be installed (perhaps as a softlink, perhaps as an
>alternative) in /opt/csw/bin ?

i think this is a reasonable thing to do.
and, no need to make it an "alternative". just make the link.

From ellson at opencsw.org  Sun Jun  5 20:53:08 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 14:53:08 -0400
Subject: [csw-maintainers] Rebuild of imagemagick
In-Reply-To: <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
Message-ID: <4DEBD094.9080301@opencsw.org>

On 06/03/2011 12:04 PM, Dagobert Michelsen wrote:
> Hi John,
>
> Am 03.06.2011 um 00:38 schrieb John Ellson:
>> OK, I'm going to try rebuilding ImageMagick against graphviz-2.28.0
>> for a simultaneous release.
>>
>> On the current* build hosts, could you please:
>>
>>     Uninstall graphviz*-2.26.3 and ImageMagick
>>
>>     Install graphviz-2.28.0 and graphvizdevel-2.28.0 from the
>> unstable catalog.
>
> Umh, the usual procedure is to just update unstable and build graphviz
> there.
> I am doing this now, ok?

Unstable is a mess.  Can we go back to plan A (above) ?


Cranky John



>
> BTW, Roger had quite some effort in a 64 bit Imagemagick:
>   http://wiki.opencsw.org/project-imagemagick64
> Maybe we can continue this project and finish up in a joint effort?
>
> Roger: Haven't heard from you in a while, everything ok? :-)
>
>
> Best regards
>
>   -- Dago
>
>>
>> Thanks.
>>
>> John
>>
>> -------- Original Message --------
>> Subject: 	Re: [csw-maintainers] graphviz: pushed to unstable -
>> problem analysis, solution, and next issue
>> Date: 	Thu, 2 Jun 2011 15:08:27 -0700
>> From: 	Philip Brown <phil at bolthole.com>
>> Reply-To: 	List for OpenCSW maintainers <maintainers at lists.opencsw.org>
>> To: 	List for OpenCSW maintainers <maintainers at lists.opencsw.org>
>>
>>
>>
>> On Thu, Jun 2, 2011 at 3:05 PM, John Ellson <ellson at opencsw.org> wrote:
>> > Dago,
>> >
>> > This really sounds like a lot of work for a one-time problem.
>> >
>> > Is there an alternative?    Could graphviz-2.28.0 be installed on the
>> > current build hosts and then ImageMagic rebuilt for a simultaneous release?
>> >
>>
>> that is certainly an even better solution, if there is nothing else
>> depending on the older libraries.
>> _______________________________________________
>> maintainers mailing list
>> maintainers at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/maintainers
>> .:: This mailing list's archive is public. ::.
>>
>> _______________________________________________
>> buildfarm mailing list
>> buildfarm at lists.opencsw.org <mailto:buildfarm at lists.opencsw.org>
>> https://lists.opencsw.org/mailman/listinfo/buildfarm
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110605/40d04912/attachment-0001.html>

From ellson at opencsw.org  Sun Jun  5 20:56:33 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 14:56:33 -0400
Subject: [csw-maintainers] /opt/csw/bin/csw-upload-pkg still doesn't work on
	login
Message-ID: <4DEBD161.3020601@opencsw.org>

ellson at login:newpkgs> csw-upload-pkg *2.28.0,REV=2011.06.05*
Processing 35 file(s). Please wait.
Uploading 'graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz'
...
Checking 19 package(s) against catalog unstable sparc SunOS5.9
ERROR: --catalog-release does not exist
Checking 19 package(s) against catalog unstable i386 SunOS5.9
ERROR: --catalog-release does not exist
Checking 19 package(s) against catalog unstable sparc SunOS5.10
ERROR: --catalog-release does not exist
Checking 19 package(s) against catalog unstable i386 SunOS5.10
ERROR: --catalog-release does not exist
Checks failed for catalogs:
...


The version in the gar checkout works ok.

From ellson at opencsw.org  Sun Jun  5 21:03:15 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 15:03:15 -0400
Subject: [csw-maintainers] libxml2 broken
Message-ID: <4DEBD2F3.8070808@opencsw.org>

Trying to repackage libxml2 from trunk, with *no* changes, fails because
of test failures during "make package"

John


./runtest &&  ./testrecurse && ./testapi &&  ./testchar&&  ./testdict
&&  ./runxmlconf
## XML regression tests
File ./test/ebcdic_566012.xml generated an error
## XML regression tests on memory
File ./test/ebcdic_566012.xml generated an error
## XML entity subst regression tests
File ./test/ebcdic_566012.xml generated an error
## XML Namespaces regression tests
## Error cases regression tests
## Error cases stream regression tests
## Reader regression tests
Result for ./test/ebcdic_566012.xml failed
File ./test/ebcdic_566012.xml generated an error
## Reader entities substitution regression tests
Result for ./test/ebcdic_566012.xml failed
File ./test/ebcdic_566012.xml generated an error
## Reader on memory regression tests
Result for ./test/ebcdic_566012.xml failed
File ./test/ebcdic_566012.xml generated an error
## Walker regression tests
Failed to parse ./test/ebcdic_566012.xml
File ./test/ebcdic_566012.xml generated an error
## SAX1 callbacks regression tests
Failed to parse ./test/ebcdic_566012.xml
File ./test/ebcdic_566012.xml generated an error
## SAX2 callbacks regression tests
Failed to parse ./test/ebcdic_566012.xml
File ./test/ebcdic_566012.xml generated an error
## XML push regression tests
Failed to parse ./test/ebcdic_566012.xml
File ./test/ebcdic_566012.xml generated an error
## HTML regression tests
## Push HTML regression tests
## HTML SAX regression tests
## Valid documents regression tests
## Validity checking regression tests
## General documents valid regression tests
## XInclude regression tests
## XInclude xmlReader regression tests
## XInclude regression tests stripping include nodes
## XInclude xmlReader regression tests stripping include nodes
## XPath expressions regression tests
## XPath document queries regression tests
## XPointer document queries regression tests
## xml:id regression tests
## URI parsing tests
## URI base composition tests
## Path URI conversion tests
## Schemas regression tests
## Relax-NG regression tests
## Relax-NG streaming regression tests
## Pattern regression tests
## C14N with comments regression tests
## C14N without comments regression tests
## C14N exclusive without comments regression tests
## C14N 1.1 without comments regression tests
## Catalog and Threads regression tests
Total 2819 tests, 10 errors, 0 leaks
gmake[2]: *** [runtests] Error 1
gmake[2]: Leaving directory
`/home/ellson/mgar/pkg/libxml2/trunk/work/solaris9-sparc/build-isa-sparcv8/libxml2-2.7.8'
gmake[1]: ***
[test-work/solaris9-sparc/build-isa-sparcv8/libxml2-2.7.8/Makefile] Error 2
gmake[1]: Leaving directory `/home/ellson/mgar/pkg/libxml2/trunk'
make: *** [merge-isa-sparcv8] Error 2


From dam at opencsw.org  Sun Jun  5 21:30:42 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 5 Jun 2011 21:30:42 +0200
Subject: [csw-maintainers] Errors on current graphviz update
Message-ID: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>

Hi John,

I get the following errors on graphviz update from unstable:

=> Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ...
Please see /opt/csw/share/doc/graphviz/license for license information.

dot -c is running now to record available graphviz plugins.

Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found

Installation of <CSWgraphviz> was successful.


Best regards

  -- Dago

PS: It may be best to open up a webpage with "project-graphviz" which denotes the
state of the current subprojects (imagemagick, libxml etc.)

From ellson at opencsw.org  Sun Jun  5 21:57:17 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 15:57:17 -0400
Subject: [csw-maintainers] Errors on current graphviz update
In-Reply-To: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
References: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
Message-ID: <4DEBDF9D.3010707@opencsw.org>

On 06/05/2011 03:30 PM, Dagobert Michelsen wrote:
> Hi John,
>
> I get the following errors on graphviz update from unstable:
>
> => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ...
> Please see /opt/csw/share/doc/graphviz/license for license information.
>
> dot -c is running now to record available graphviz plugins.
>
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
What machine were you installing on?  unstable9s ?     Graphviz was
built on current9s.    Lots of stuff is broken in unstable9[sx]


>
> PS: It may be best to open up a webpage with "project-graphviz" which denotes the
> state of the current subprojects (imagemagick, libxml etc.)

Good idea, except that Firefox-3.6.17 doesn't seem to like the
Javascript from http://wiki.opencsw.org/

Try to "Sign in" or "Create account" and it just hangs with
"javascript:;" on the bottom status bar.


John

From ellson at opencsw.org  Sun Jun  5 22:07:39 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 16:07:39 -0400
Subject: [csw-maintainers] Errors on current graphviz update
In-Reply-To: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
References: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
Message-ID: <4DEBE20B.4000504@opencsw.org>

On 06/05/2011 03:30 PM, Dagobert Michelsen wrote:
> PS: It may be best to open up a webpage with "project-graphviz" which denotes the
> state of the current subprojects (imagemagick, libxml etc.)

There was another way to sign up, by trying to create a page.

I did that, now I have a user account on the wiki for
"ellson at opencsw.org", but it still won't let me create a page.
Now it says:

     "Permissions error.  Please note: Sorry, you cannot create a page
in this category.  Only member of this site, site administrators and
perhaps selected moderators are allowed to do it."

I was trying to use the entry-widget on the left to create
"project-graphviz"


John

From bonivart at opencsw.org  Sun Jun  5 22:12:32 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 5 Jun 2011 22:12:32 +0200
Subject: [csw-maintainers] Errors on current graphviz update
In-Reply-To: <4DEBDF9D.3010707@opencsw.org>
References: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
	<4DEBDF9D.3010707@opencsw.org>
Message-ID: <BANLkTikdQ5kvV-DJaYbywQmd4iTyV_922A@mail.gmail.com>

On Sun, Jun 5, 2011 at 9:57 PM, John Ellson <ellson at opencsw.org> wrote:
> Good idea, except that Firefox-3.6.17 doesn't seem to like the
> Javascript from http://wiki.opencsw.org/
>
> Try to "Sign in" or "Create account" and it just hangs with
> "javascript:;" on the bottom status bar.

Man, you do attract problems like a magnet.

You can create a dir "graphviz" under experimental. On the web page
for experimental there will then be a link to create a wiki project.
That's probably what Dago meant.

Regarding wiki access you need to apply for membership on our specific
wiki. You now have a wikidot account, good, apply for membership on
the OpenCSW wiki and I will approve it, then you can create/edit
pages.

/peter

From ellson at opencsw.org  Sun Jun  5 22:14:45 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 16:14:45 -0400
Subject: [csw-maintainers] php5 broken
Message-ID: <4DEBE3B5.4050904@opencsw.org>

I just tried repackaging php5 with *no* changes.

(I was investing how hard it would be to add a softlink:
    /opt/csw/bin/php -> /opt/csw/php5/bin/php
)

Why would it even fail for "surplus-dependency" ?    What harm is there?

John


If any of the reported errors were false positives, you can override them
pasting the lines below to the GAR recipe.
CHECKPKG_OVERRIDES_CSWphp5-mysql += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-gettext += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-gmp += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-dba += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-tidy += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-gd += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-sysvshm += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-hash += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-xsl += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-mssql += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-dom += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-sqlite += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-bcmath += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-imap += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-session += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-sysvmsg += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-zip += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-soap += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-json += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-xmlrpc += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-bz2 += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-pdo += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-shmop += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-posix += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-sysvsem += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-curl += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-wddx += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-xmlreader += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-ftp += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-mcrypt += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-sockets += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-openssl += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-iconv += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-calendar += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-mysqli += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-tokenizer += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-pgsql += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-mbstring += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-xmlwriter += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-readline += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-ldap += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-odbc += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-pcntl += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-pspell += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-exif += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-snmp += surplus-dependency|CSWphp5
CHECKPKG_OVERRIDES_CSWphp5-ctype += surplus-dependency|CSWphp5
Please note that checkpkg isn't suggesting you should simply add these
overrides
do the Makefile.  It only informs what the overrides could look like. 
You need
to understand what are the reported issues about and use your best
judgement to
decide whether to fix the underlying problems or override them. For more
information, scroll up and read the detailed messages.
WARNING: Some overrides did not match any errors. They can be removed,
as they
don't take any effect anyway.  If you're getting errors at the same
time, maybe
you didn't specify the overrides correctly.
* Unused Override: CSWphp5sqlite: archall-devel-package
* Unused Override: CSWphp5ldap: archall-devel-package
* Unused Override: CSWphp5pdo: archall-devel-package
* Unused Override: CSWphp5mssql: archall-devel-package
* Unused Override: CSWphp5-pdoodbc: surplus-dependency CSWphp5-pdo
* Unused Override: CSWphp5zip: archall-devel-package
* Unused Override: CSWphp5sysvshm: archall-devel-package
* Unused Override: CSWphp5xmlwriter: archall-devel-package
* Unused Override: CSWphp5pdomysql: archall-devel-package
* Unused Override: CSWphp5mcrypt: archall-devel-package
* Unused Override: CSWphp5mysql: archall-devel-package
* Unused Override: CSWphp5dba: archall-devel-package
* Unused Override: CSWphp5xmlrpc: archall-devel-package
* Unused Override: CSWphp5exif: archall-devel-package
* Unused Override: CSWap2modphp5: archall-devel-package
* Unused Override: CSWphp5bz2: archall-devel-package
* Unused Override: CSWphp5pdoodbc: archall-devel-package
* Unused Override: CSWphp5pdopgsql: archall-devel-package
* Unused Override: CSWphp5pgsql: archall-devel-package
* Unused Override: CSWphp5ftp: archall-devel-package
* Unused Override: CSWphp5calendar: archall-devel-package
* Unused Override: CSWphp5pdosqlite: archall-devel-package
* Unused Override: CSWphp5-pdopgsql: surplus-dependency CSWphp5-pdo
* Unused Override: CSWphp5posix: archall-devel-package
* Unused Override: CSWphp5sockets: archall-devel-package
* Unused Override: CSWphp5-pdosqlite: surplus-dependency CSWphp5-pdo
* Unused Override: CSWphp5pcntl: archall-devel-package
* Unused Override: CSWphp5mysqli: archall-devel-package
* Unused Override: CSWphp5tidy: archall-devel-package
* Unused Override: CSWphp5odbc: archall-devel-package
* Unused Override: CSWphp5readline: archall-devel-package
* Unused Override: CSWphp5gmp: archall-devel-package
* Unused Override: CSWphp5gd: archall-devel-package
* Unused Override: CSWphp5openssl: archall-devel-package
* Unused Override: CSWphp5session: archall-devel-package
* Unused Override: CSWphp5xmlreader: archall-devel-package
* Unused Override: CSWphp5bcmath: archall-devel-package
* Unused Override: CSWphp5-pdomysql: surplus-dependency CSWphp5-pdo
* Unused Override: CSWphp5ctype: archall-devel-package
* Unused Override: CSWphp5gettext: archall-devel-package
* Unused Override: CSWphp5iconv: archall-devel-package
* Unused Override: CSWphp5hash: archall-devel-package
* Unused Override: CSWphp5imap: archall-devel-package
* Unused Override: CSWphp5sysvsem: archall-devel-package
* Unused Override: CSWphp5snmp: archall-devel-package
* Unused Override: CSWphp5dom: archall-devel-package
* Unused Override: CSWphp5wddx: archall-devel-package
* Unused Override: CSWphp5soap: archall-devel-package
* Unused Override: CSWphp5shmop: archall-devel-package
* Unused Override: CSWphp5sysvmsg: archall-devel-package
* Unused Override: CSWphp5json: archall-devel-package
* Unused Override: CSWphp5tokenizer: archall-devel-package
* Unused Override: CSWphp5curl: archall-devel-package
* Unused Override: CSWphp5xsl: archall-devel-package
* Unused Override: CSWphp5mbstring: archall-devel-package
* Unused Override: CSWphp5pspell: archall-devel-package
gmake: *** [pkgcheck] Error 2
gmake: Leaving directory `/home/ellson/mgar/pkg/php5/trunk'
Connection to current9s closed.
gmake: *** [platforms] Error 2
ellson at login:~>


From ellson at opencsw.org  Sun Jun  5 22:43:21 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 16:43:21 -0400
Subject: [csw-maintainers] Errors on current graphviz update
In-Reply-To: <BANLkTikdQ5kvV-DJaYbywQmd4iTyV_922A@mail.gmail.com>
References: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>	<4DEBDF9D.3010707@opencsw.org>
	<BANLkTikdQ5kvV-DJaYbywQmd4iTyV_922A@mail.gmail.com>
Message-ID: <4DEBEA69.7040009@opencsw.org>

On 06/05/2011 04:12 PM, Peter Bonivart wrote:
> On Sun, Jun 5, 2011 at 9:57 PM, John Ellson <ellson at opencsw.org> wrote:
>> Good idea, except that Firefox-3.6.17 doesn't seem to like the
>> Javascript from http://wiki.opencsw.org/
>>
>> Try to "Sign in" or "Create account" and it just hangs with
>> "javascript:;" on the bottom status bar.
> Man, you do attract problems like a magnet.

I can't be just me?  How is anyone else able to maintain any opencsw
package these days???
> You can create a dir "graphviz" under experimental.

Did that.

> On the web page
> for experimental there will then be a link to create a wiki project.
Yes.  Followed that ok.

> That's probably what Dago meant.
Probably.
> Regarding wiki access you need to apply for membership on our specific
> wiki. You now have a wikidot account, good, apply for membership on
> the OpenCSW wiki and I will approve it, then you can create/edit
> pages.

Tried that.   It said:

    You can not apply.
It seems you have already applied for membership.

John (the cranky problem magnet).


From ellson at opencsw.org  Sun Jun  5 23:31:12 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 17:31:12 -0400
Subject: [csw-maintainers] http://wiki.opencsw.org/project-graphviz
Message-ID: <4DEBF5A0.9010004@opencsw.org>

There is a first-cut project page for graphviz now available at:

    http://wiki.opencsw.org/project-graphviz

John

From ellson at opencsw.org  Sun Jun  5 23:39:44 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 17:39:44 -0400
Subject: [csw-maintainers] Errors on current graphviz update
In-Reply-To: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
References: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
Message-ID: <4DEBF7A0.4010708@opencsw.org>

Dago,

I couldn't reproduce this here.  I installed
graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz
No problems during the "dot -c" postinstall step, and it tested fine with:
    echo "digraph {hello->world}" | dot -v -Tps:lasi

Any chance you could try installing on something other than unstable8[sx] ?

John


On 06/05/2011 03:30 PM, Dagobert Michelsen wrote:
> Hi John,
>
> I get the following errors on graphviz update from unstable:
>
> => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ...
> Please see /opt/csw/share/doc/graphviz/license for license information.
>
> dot -c is running now to record available graphviz plugins.
>
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>
> Installation of <CSWgraphviz> was successful.
>
>
> Best regards
>
>   -- Dago
>
> PS: It may be best to open up a webpage with "project-graphviz" which denotes the
> state of the current subprojects (imagemagick, libxml etc.)


From ellson at opencsw.org  Sun Jun  5 23:54:04 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 17:54:04 -0400
Subject: [csw-maintainers] Errors on current graphviz update
In-Reply-To: <4DEBF7A0.4010708@opencsw.org>
References: <FBB56E0D-A6CF-4C57-8B74-9F20A2828C1D@opencsw.org>
	<4DEBF7A0.4010708@opencsw.org>
Message-ID: <4DEBFAFC.2030706@opencsw.org>

This may be the problem:

ellson at unstable9s:ellson> ldd
/opt/csw/lib/sparcv8/libpangocairo-1.0.so.0 | grep X11
        libX11.so.4 =>   /usr/lib/libX11.so.4


John




On 06/05/2011 05:39 PM, John Ellson wrote:
> Dago,
>
> I couldn't reproduce this here.  I installed
> graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz
> No problems during the "dot -c" postinstall step, and it tested fine with:
>     echo "digraph {hello->world}" | dot -v -Tps:lasi
>
> Any chance you could try installing on something other than unstable8[sx] ?
>
> John
>
>
> On 06/05/2011 03:30 PM, Dagobert Michelsen wrote:
>> Hi John,
>>
>> I get the following errors on graphviz update from unstable:
>>
>> => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ...
>> Please see /opt/csw/share/doc/graphviz/license for license information.
>>
>> dot -c is running now to record available graphviz plugins.
>>
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>
>> Installation of <CSWgraphviz> was successful.
>>
>>
>> Best regards
>>
>>   -- Dago
>>
>> PS: It may be best to open up a webpage with "project-graphviz" which denotes the
>> state of the current subprojects (imagemagick, libxml etc.)
> _______________________________________________
> 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  Mon Jun  6 02:36:42 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 6 Jun 2011 01:36:42 +0100
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <4DEBD2F3.8070808@opencsw.org>
References: <4DEBD2F3.8070808@opencsw.org>
Message-ID: <BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>

2011/6/5 John Ellson <ellson at opencsw.org>:
> Trying to repackage libxml2 from trunk, with *no* changes, fails because
> of test failures during "make package"

I don't know exactly what state is libxml currently in, there is a
couple of possibilities:

- there was work on it going on, and not yet finished.  Looking at the
package database[1], the last published version was built from
revision 13937
- it was released despite failing unit tests
- something in the environment changed, causing tests to fail

Maciej

[1] http://www.opencsw.org/packages/CSWlibxml2-2/

From ellson at opencsw.org  Mon Jun  6 02:53:48 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 20:53:48 -0400
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>
References: <4DEBD2F3.8070808@opencsw.org>
	<BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>
Message-ID: <4DEC251C.5060106@opencsw.org>

On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote:
> 2011/6/5 John Ellson <ellson at opencsw.org>:
>> Trying to repackage libxml2 from trunk, with *no* changes, fails because
>> of test failures during "make package"
> I don't know exactly what state is libxml currently in, there is a
> couple of possibilities:
>
> - there was work on it going on, and not yet finished.  Looking at the
> package database[1], the last published version was built from
> revision 13937

That revision doesn't build now either.

gar//gar.pkg.mk:106: *** The deprecated variable 'NOISAEXEC' is defined,
this is now the default, please remove the line. Stop.

> - it was released despite failing unit tests
> - something in the environment changed, causing tests to fail
>
> Maciej
>
> [1] http://www.opencsw.org/packages/CSWlibxml2-2/
> _______________________________________________
> 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  Mon Jun  6 02:55:38 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 6 Jun 2011 01:55:38 +0100
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <4DEC251C.5060106@opencsw.org>
References: <4DEBD2F3.8070808@opencsw.org>
	<BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>
	<4DEC251C.5060106@opencsw.org>
Message-ID: <BANLkTi=saMW6hdBtYX_miBGOHVC9hXBePYSMsh7LNh68Xntkyg@mail.gmail.com>

2011/6/6 John Ellson <ellson at opencsw.org>:
> On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote:
>> 2011/6/5 John Ellson <ellson at opencsw.org>:
>>> Trying to repackage libxml2 from trunk, with *no* changes, fails because
>>> of test failures during "make package"
>> I don't know exactly what state is libxml currently in, there is a
>> couple of possibilities:
>>
>> - there was work on it going on, and not yet finished. ?Looking at the
>> package database[1], the last published version was built from
>> revision 13937
>
> That revision doesn't build now either.
>
> gar//gar.pkg.mk:106: *** The deprecated variable 'NOISAEXEC' is defined,
> this is now the default, please remove the line. Stop.

There was a GAR change since - if you check out GAR from the same
revision, you'll get the compatible code.

Maciej

From maciej at opencsw.org  Mon Jun  6 02:57:45 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 6 Jun 2011 01:57:45 +0100
Subject: [csw-maintainers] /opt/csw/bin/csw-upload-pkg still doesn't
 work on login
In-Reply-To: <4DEBD161.3020601@opencsw.org>
References: <4DEBD161.3020601@opencsw.org>
Message-ID: <BANLkTim7XhZ5qRn46uoHJVfiMfGrCbpyi6jEq8Uq6cPTuXqgaw@mail.gmail.com>

2011/6/5 John Ellson <ellson at opencsw.org>:
> ellson at login:newpkgs> csw-upload-pkg *2.28.0,REV=2011.06.05*
> Processing 35 file(s). Please wait.
> Uploading 'graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz'
> ...
> Checking 19 package(s) against catalog unstable sparc SunOS5.9
> ERROR: --catalog-release does not exist
> (...)
> The version in the gar checkout works ok.

Please keep using the version from GAR sources, until Ben and I finish
sorting out the version in /opt/csw/bin.

Maciej

From maciej at opencsw.org  Mon Jun  6 02:58:50 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 6 Jun 2011 01:58:50 +0100
Subject: [csw-maintainers] Rebuild of imagemagick
In-Reply-To: <4DEBD094.9080301@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
	<4DEBD094.9080301@opencsw.org>
Message-ID: <BANLkTi=w_pdNhHscsYoSrebRSg32E814k_YCtKroi2-x3866yw@mail.gmail.com>

2011/6/5 John Ellson <ellson at opencsw.org>
>
> Unstable is a mess.

In what way?  I am aware of the X11 libraries that need to be removed.
Is there anything else?

Maciej

From ellson at opencsw.org  Mon Jun  6 03:21:55 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 21:21:55 -0400
Subject: [csw-maintainers] Rebuild of imagemagick
In-Reply-To: <BANLkTi=w_pdNhHscsYoSrebRSg32E814k_YCtKroi2-x3866yw@mail.gmail.com>
References: <4DE810E0.4050502@opencsw.org>	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>	<4DEBD094.9080301@opencsw.org>
	<BANLkTi=w_pdNhHscsYoSrebRSg32E814k_YCtKroi2-x3866yw@mail.gmail.com>
Message-ID: <4DEC2BB3.9050007@opencsw.org>

On 06/05/2011 08:58 PM, Maciej Blizi?ski wrote:
> 2011/6/5 John Ellson <ellson at opencsw.org>
>> Unstable is a mess.
> In what way?  I am aware of the X11 libraries that need to be removed.
> Is there anything else?

Probably its mostly the libxml2 issue now:

current9s has CSWlibxml2-dev and a newer CSWlibxml2devel.

ellson at unstable9s:ellson> pkgutil -c libxml2
You're not root and didn't set -W, using home dir.
package installed catalog
CSWlibxml2 2.7.8,REV=2011.03.21 SAME
CSWlibxml2-2 2.7.8,REV=2011.03.24 SAME
CSWlibxml2devel 2.7.7,REV=2010.04.10 SAME
CSWpy-libxml2 2.7.8,REV=2011.03.24 SAME
CSWpylibxml2 2.7.8,REV=2011.03.21 SAME


ellson at current9s:ellson> pkgutil -c libxml2
You're not root and didn't set -W, using home dir.
package installed catalog
CSWlibxml2 2.7.8,REV=2011.03.24 SAME
CSWlibxml2-2 2.7.8,REV=2011.03.24 SAME
CSWlibxml2-dev 2.7.8,REV=2011.03.24 SAME
CSWlibxml2devel 2.7.8,REV=2011.03.24 SAME
CSWpy-libxml2 2.7.8,REV=2011.03.24 SAME
CSWpylibxml2 2.7.8,REV=2011.03.24 SAME



Also, if the plan is for me to try to build ImageMagick on unstable, I
need CSWimagemagick uninstalled, and CSWgraphviz-2.28.0 +
CSWgraphvizdevel-2.28.0 installed.



John


> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>


From ellson at opencsw.org  Mon Jun  6 03:28:23 2011
From: ellson at opencsw.org (John Ellson)
Date: Sun, 05 Jun 2011 21:28:23 -0400
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <BANLkTi=saMW6hdBtYX_miBGOHVC9hXBePYSMsh7LNh68Xntkyg@mail.gmail.com>
References: <4DEBD2F3.8070808@opencsw.org>	<BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>	<4DEC251C.5060106@opencsw.org>
	<BANLkTi=saMW6hdBtYX_miBGOHVC9hXBePYSMsh7LNh68Xntkyg@mail.gmail.com>
Message-ID: <4DEC2D37.2010809@opencsw.org>

On 06/05/2011 08:55 PM, Maciej Blizi?ski wrote:
> 2011/6/6 John Ellson <ellson at opencsw.org>:
>> On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote:
>>> 2011/6/5 John Ellson <ellson at opencsw.org>:
>>>> Trying to repackage libxml2 from trunk, with *no* changes, fails because
>>>> of test failures during "make package"


The test failures are only from test/ebcdic_566012.xml.   If that test
is removed, "make check" succeeds.

I suspect the problem is that CSWiconv doesn't have EBCDIC support:

    ellson at current9s:ellson> iconv -l | grep -i ebcdic
    ellson at current9s:ellson>

We could fix CSWiconv or disable the test in CSWlibxml2


John






>>> I don't know exactly what state is libxml currently in, there is a
>>> couple of possibilities:
>>>
>>> - there was work on it going on, and not yet finished.  Looking at the
>>> package database[1], the last published version was built from
>>> revision 13937
>> That revision doesn't build now either.
>>
>> gar//gar.pkg.mk:106: *** The deprecated variable 'NOISAEXEC' is defined,
>> this is now the default, please remove the line. Stop.
> There was a GAR change since - if you check out GAR from the same
> revision, you'll get the compatible code.
>
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From bwalton at opencsw.org  Mon Jun  6 03:44:02 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 21:44:02 -0400
Subject: [csw-maintainers] /opt/csw/bin/csw-upload-pkg still doesn't
	work on login
In-Reply-To: <4DEBD161.3020601@opencsw.org>
References: <4DEBD161.3020601@opencsw.org>
Message-ID: <1307324599-sup-631@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Sun Jun 05 14:56:33 -0400 2011:

> ellson at login:newpkgs> csw-upload-pkg *2.28.0,REV=2011.06.05*
> Processing 35 file(s). Please wait.
> Uploading 'graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz'
> ...
> Checking 19 package(s) against catalog unstable sparc SunOS5.9
> ERROR: --catalog-release does not exist
> Checking 19 package(s) against catalog unstable i386 SunOS5.9
> ERROR: --catalog-release does not exist
> Checking 19 package(s) against catalog unstable sparc SunOS5.10
> ERROR: --catalog-release does not exist
> Checking 19 package(s) against catalog unstable i386 SunOS5.10
> ERROR: --catalog-release does not exist
> Checks failed for catalogs:
> ...

This should actually be solved now, but Dago will need to update the
CSWcswutils that got batched last night on login.

Dago, can you push that update as I don't have the rights?

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


From bwalton at opencsw.org  Mon Jun  6 03:47:43 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 21:47:43 -0400
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
	<1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>
Message-ID: <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun Jun 05 13:03:53 -0400 2011:

> so you're suggesting that from now on, no-one should ever bother
> requesting anyone take over orphaned packages, becuase "if anyone
> were interested in packaging them, they would have done so already".

No, the request is fine and I don't mind waiting a week as you
suggest.  I'm just saying that we shouldn't let orphaned packages[1]
impede work on things that people do actively care about.

Thanks
-Ben

[1] Especially those that are known broken, have security issues and
    are at legacy versions.  I would consider an orphaned but current
    package differently.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Mon Jun  6 03:58:08 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 21:58:08 -0400
Subject: [csw-maintainers] gar and php question
In-Reply-To: <BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
References: <4DEBB025.6010702@opencsw.org>
	<BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
Message-ID: <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun Jun 05 13:12:50 -0400 2011:

> i think this is a reasonable thing to do.
> and, no need to make it an "alternative". just make the link.

We should look at dropping php4 at this point and moving php5 into the
normal namespace.  That's a big project though and I haven't quite
finished the php5 update (I think it's done but I haven't tested after
the last revision), so I don't want to add extra complexity just yet.

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


From bwalton at opencsw.org  Mon Jun  6 04:08:41 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 22:08:41 -0400
Subject: [csw-maintainers] Rebuild of imagemagick
In-Reply-To: <4DEC2BB3.9050007@opencsw.org>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
	<4DEBD094.9080301@opencsw.org>
	<BANLkTi=w_pdNhHscsYoSrebRSg32E814k_YCtKroi2-x3866yw@mail.gmail.com>
	<4DEC2BB3.9050007@opencsw.org>
Message-ID: <1307325614-sup-4801@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Sun Jun 05 21:21:55 -0400 2011:

> Probably its mostly the libxml2 issue now:
> 
> current9s has CSWlibxml2-dev and a newer CSWlibxml2devel.

I've just re-pushed the libxml2 dev packages to unstable so they'll be
properly available in unstable.  I will pop around and stuff them on
by hand shortly too.  I don't know why they weren't in the original
set that was uploaded.

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


From bwalton at opencsw.org  Mon Jun  6 04:43:42 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 22:43:42 -0400
Subject: [csw-maintainers] php5 broken
In-Reply-To: <4DEBE3B5.4050904@opencsw.org>
References: <4DEBE3B5.4050904@opencsw.org>
Message-ID: <1307328137-sup-8660@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Sun Jun 05 16:14:45 -0400 2011:

Hi John,

> I just tried repackaging php5 with *no* changes.
> 
> (I was investing how hard it would be to add a softlink:
>     /opt/csw/bin/php -> /opt/csw/php5/bin/php
> )
> 
> Why would it even fail for "surplus-dependency" ?    What harm is
> there?

I'm not sure what's going on with this and can't look tonight.  I may
have committed something wrong with this build description or ...?
I'm pretty close to having php5 updated and I can add the symlink
before it's released.

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


From bwalton at opencsw.org  Mon Jun  6 04:44:53 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 22:44:53 -0400
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <4DEC2D37.2010809@opencsw.org>
References: <4DEBD2F3.8070808@opencsw.org>
	<BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>
	<4DEC251C.5060106@opencsw.org>
	<BANLkTi=saMW6hdBtYX_miBGOHVC9hXBePYSMsh7LNh68Xntkyg@mail.gmail.com>
	<4DEC2D37.2010809@opencsw.org>
Message-ID: <1307328238-sup-7520@pinkfloyd.chass.utoronto.ca>

Excerpts from John Ellson's message of Sun Jun 05 21:28:23 -0400 2011:

> We could fix CSWiconv or disable the test in CSWlibxml2

I'm not sure what's happening here as I don't recall the test suite
having any failures when I last updated this package.

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


From bwalton at opencsw.org  Mon Jun  6 04:45:47 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 22:45:47 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure
	unstable9[xs]
In-Reply-To: <C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
References: <4DEA6CFC.7060500@opencsw.org>
	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>
	<4DEB84E7.3030609@opencsw.org>
	<C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
Message-ID: <1307328323-sup-2858@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Sun Jun 05 09:55:04 -0400 2011:

> Ben: Would you mind having a look and re-release the devel package?

Done.  The unstable* hosts were updated too.

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


From bwalton at opencsw.org  Mon Jun  6 04:46:15 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 05 Jun 2011 22:46:15 -0400
Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure
	unstable9[xs]
In-Reply-To: <BANLkTi=3UY0bkzTMmwBUH9_Vrw6KLbk2sw@mail.gmail.com>
References: <4DEA6CFC.7060500@opencsw.org>
	<1307232386-sup-7830@pinkfloyd.chass.utoronto.ca>
	<4DEB84E7.3030609@opencsw.org>
	<C7F6352A-BE8D-4109-A924-0E879BE83B3F@opencsw.org>
	<4DEB9555.7040107@opencsw.org>
	<BANLkTi=3UY0bkzTMmwBUH9_Vrw6KLbk2sw@mail.gmail.com>
Message-ID: <1307328358-sup-8886@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun Jun 05 13:07:49 -0400 2011:

> it would be better if these were removed. they are probably messing
> things up.

I'll do this tomorrow unless Dago beats me to it.

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


From phil at bolthole.com  Mon Jun  6 05:36:19 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 5 Jun 2011 20:36:19 -0700
Subject: [csw-maintainers] [csw-buildfarm]  Rebuild of imagemagick
In-Reply-To: <BANLkTi=w_pdNhHscsYoSrebRSg32E814k_YCtKroi2-x3866yw@mail.gmail.com>
References: <4DE810E0.4050502@opencsw.org>
	<7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org>
	<4DEBD094.9080301@opencsw.org>
	<BANLkTi=w_pdNhHscsYoSrebRSg32E814k_YCtKroi2-x3866yw@mail.gmail.com>
Message-ID: <BANLkTi=0Ep_vZXzRZWo27BRCTxTWYO=vDg@mail.gmail.com>

John has made a reasonable request to the buildfarm maintainers. twice now.

Are you folks going to ignore buildfarm requests for the
non-"unstable" machines now?

From phil at bolthole.com  Mon Jun  6 05:40:17 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 5 Jun 2011 20:40:17 -0700
Subject: [csw-maintainers] gar and php question
In-Reply-To: <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>
References: <4DEBB025.6010702@opencsw.org>
	<BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
	<1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=xW+KAxpGGYUZxedrgpom_TfHGAw@mail.gmail.com>

On Sun, Jun 5, 2011 at 6:58 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Sun Jun 05 13:12:50 -0400 2011:
>
>> i think this is a reasonable thing to do.
>> and, no need to make it an "alternative". just make the link.
>
> We should look at dropping php4 at this point and moving php5 into the
> normal namespace.

i'm not sure that that serves any useful purpose, other than /opt/csw/bin/php
I think adding the symlink, effectively accomplishes "moving php5 into
the normal namespace"

Methinks that any auto-detect stuff will most likely invoke "php (some
command" to determine location and flags for things.

From skayser at opencsw.org  Mon Jun  6 08:55:05 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 6 Jun 2011 08:55:05 +0200
Subject: [csw-maintainers] Further improvements to our website
In-Reply-To: <BANLkTikrbCejTWi1GUhMfXaZLrH51uV3oQ@mail.gmail.com>
References: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
	<4DE3F9E8.7020303@wbonnet.net>
	<BANLkTikEtVBtb83i6A2bEupzpfATWYNsmw@mail.gmail.com>
	<BANLkTikrbCejTWi1GUhMfXaZLrH51uV3oQ@mail.gmail.com>
Message-ID: <20110606065505.GJ29708@sebastiankayser.de>

* Maciej Blizi??ski <maciej at opencsw.org> wrote:
> I've installed our apache, php and mysql.  I can run phpinfo() - it
> works.  What doesn't work, is installing mantis.  When enter the top
> level link, I'm redirected to admin/install.php, and all I see is a
> blank page.

I ran into the same issue. Tried Mantis 1.2.5 (latest) and 1.2.4 (just
to double check) and it wasn't until I hit admin/check.php that I saw
session module related errors. Installing the PHP5 session module helped
in my case.

  pkgutil -i php5_session

Can you check whether it does the job for you too? If so, I am going to
uninstall it again on my box, verify the issue, and report a bug
upstream.

Sebastian

From skayser at opencsw.org  Mon Jun  6 10:01:15 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 6 Jun 2011 10:01:15 +0200
Subject: [csw-maintainers] Further improvements to our website
In-Reply-To: <20110606065505.GJ29708@sebastiankayser.de>
References: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
	<4DE3F9E8.7020303@wbonnet.net>
	<BANLkTikEtVBtb83i6A2bEupzpfATWYNsmw@mail.gmail.com>
	<BANLkTikrbCejTWi1GUhMfXaZLrH51uV3oQ@mail.gmail.com>
	<20110606065505.GJ29708@sebastiankayser.de>
Message-ID: <20110606080114.GK29708@sebastiankayser.de>

* Sebastian Kayser <skayser at opencsw.org> wrote:
> * Maciej Blizi??ski <maciej at opencsw.org> wrote:
> > I've installed our apache, php and mysql.  I can run phpinfo() - it
> > works.  What doesn't work, is installing mantis.  When enter the top
> > level link, I'm redirected to admin/install.php, and all I see is a
> > blank page.
> 
> I ran into the same issue. Tried Mantis 1.2.5 (latest) and 1.2.4 (just
> to double check) and it wasn't until I hit admin/check.php that I saw
> session module related errors. Installing the PHP5 session module helped
> in my case.
> 
>   pkgutil -i php5_session

Adding to this: what made debugging hard is the use of the @ operator in
install.php which - as I just learnt - suppresses even critical errors,
leaving no indication as to why a script terminates early [1]. Removing
this operator (for the core.php inclusion) should help to identify the
culprit [2].

Sebastian

[1] http://php.net/manual/en/language.operators.errorcontrol.php
[2] http://paste.pocoo.org/show/401482/

From ellson at opencsw.org  Mon Jun  6 12:17:57 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 06:17:57 -0400
Subject: [csw-maintainers] graphviz builds - build farm requests
Message-ID: <4DECA955.9020408@opencsw.org>

I see graphvizdevel installed on unstable9s, but that imagemagick is
still installed.  How did that happen?  I thought there was a dependency
from imagemagick on libgvc.so from graphviz-2.26.3 ?   Doesn't pkg-get
or pkgutil check?

1) Could you install graphvizdevel on unstable9x as well?  (I only have
resources for testing on i386 architecture here).

2) Please uninstall  imagemagick from unstable9[sx] while I rebuild.   I
still think libtool gets confused if old copies of the package's .so are
still installed. I currently get this error when building imagemagick on
unstable8s I think because its picking up the old libs.


libtool: link:  /opt/SUNWspro/bin/cc -G -z defs -M
coders/.libs/svg.so.exp -h svg.so -o coders/.libs/svg.so 
coders/.libs/coders_svg_la-svg.o  
-R/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs
-R/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/wand/.libs
-R/opt/csw/lib -R/opt/csw/X11/lib
-L/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs
-L/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/wand/.libs
-L/opt/csw/X11/lib -L/opt/csw/lib magick/.libs/libMagickCore.so
wand/.libs/libMagickWand.so
/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs/libMagickCore.so
-llcms -ltiff -lfreetype -ljpeg -llqr-1 -lfontconfig -lXext -lXt -lbz2
-lltdl -lSM -lICE -lX11 -lsocket -lnsl -lmtsk -lrsvg-2 -lgdk_pixbuf-2.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread
-lrt -lglib-2.0 -lintl -lxml2 -lz -lm -lc  -m32 -xarch=v8 -Wl,-zlazyload
-m32 -xarch=v8 
ld: warning: file
/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs/libMagickCore.so:
linked to magick/.libs/libMagickCore.so: attempted multiple inclusion of
file
Undefined                       first referenced
 symbol                             in file
XSolarisIASetProcessInfo            /lib/libX11.so.4
ld: fatal: Symbol referencing errors. No output written to
coders/.libs/svg.so
gmake[3]: *** [coders/svg.la] Error 1




After I get imagemagick to build and package on unstable9[sx], do I
still need to build and package on current9[sx] ?

John



From dam at opencsw.org  Mon Jun  6 14:03:57 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 6 Jun 2011 14:03:57 +0200
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <4DECA955.9020408@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
Message-ID: <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>

Hi John,

Am 06.06.2011 um 12:17 schrieb John Ellson:
> I see graphvizdevel installed on unstable9s, but that imagemagick is
> still installed.  How did that happen?

I would say this is normal as CSWimagemagick depends on CSWgraphviz, but not
CSWgraphvizdevel.

> I thought there was a dependency
> from imagemagick on libgvc.so from graphviz-2.26.3 ?   Doesn't pkg-get
> or pkgutil check?

They check explicit package dependencies when set, but the dependency is
more defined as above.

> 1) Could you install graphvizdevel on unstable9x as well?  (I only have
> resources for testing on i386 architecture here).

I have uninstalled CSWgraphvizdevel on all unstable* hosts now.

> 2) Please uninstall  imagemagick from unstable9[sx] while I rebuild.

Uninstalled from all unstable* hosts.

> After I get imagemagick to build and package on unstable9[sx], do I
> still need to build and package on current9[sx] ?

It is recommended ATM, but if you make sure that it works with the versions
in current a direct release to unstable should be no problem.


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 bwalton at opencsw.org  Mon Jun  6 15:05:12 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 06 Jun 2011 09:05:12 -0400
Subject: [csw-maintainers] gar and php question
In-Reply-To: <BANLkTi=xW+KAxpGGYUZxedrgpom_TfHGAw@mail.gmail.com>
References: <4DEBB025.6010702@opencsw.org>
	<BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
	<1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=xW+KAxpGGYUZxedrgpom_TfHGAw@mail.gmail.com>
Message-ID: <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun Jun 05 23:40:17 -0400 2011:

> i'm not sure that that serves any useful purpose, other than
> /opt/csw/bin/php I think adding the symlink, effectively
> accomplishes "moving php5 into the normal namespace"

Well, it is useful as php4 is not supported upstream and we have the
supported branch (although even our php5 version is unsupported now
until I get the update finished).  Removing it from the catalog won't
prevent those that want it from getting it, but we should make those
people 'work' for it and not provide some pretense that it's a
supported package.

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


From ellson at opencsw.org  Mon Jun  6 15:35:23 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 09:35:23 -0400
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
Message-ID: <4DECD79B.90601@opencsw.org>


>> 1) Could you install graphvizdevel on unstable9x as well?  (I only have
>> resources for testing on i386 architecture here).
> I have uninstalled CSWgraphvizdevel on all unstable* hosts now.
>

No, please *install* graphvizdevel-2.28.0 ons unstable9s and unstable9x.

graphviz is built. Now I need graphvizdevel for building imagemagick.

John

From maciej at opencsw.org  Mon Jun  6 15:39:32 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 6 Jun 2011 14:39:32 +0100
Subject: [csw-maintainers] Further improvements to our website
In-Reply-To: <20110606065505.GJ29708@sebastiankayser.de>
References: <BANLkTin4R=_SWhZA4oC7v+uinEgZ9Dh9RA@mail.gmail.com>
	<4DE3F9E8.7020303@wbonnet.net>
	<BANLkTikEtVBtb83i6A2bEupzpfATWYNsmw@mail.gmail.com>
	<BANLkTikrbCejTWi1GUhMfXaZLrH51uV3oQ@mail.gmail.com>
	<20110606065505.GJ29708@sebastiankayser.de>
Message-ID: <BANLkTimiuFct1XToz-aCsfRnF+Uv0_U9wg@mail.gmail.com>

2011/6/6 Sebastian Kayser <skayser at opencsw.org>:
> * Maciej Blizi??ski <maciej at opencsw.org> wrote:
>> I've installed our apache, php and mysql. ?I can run phpinfo() - it
>> works. ?What doesn't work, is installing mantis. ?When enter the top
>> level link, I'm redirected to admin/install.php, and all I see is a
>> blank page.
>
> I ran into the same issue. Tried Mantis 1.2.5 (latest) and 1.2.4 (just
> to double check) and it wasn't until I hit admin/check.php that I saw
> session module related errors. Installing the PHP5 session module helped
> in my case.
>
> ?pkgutil -i php5_session
>
> Can you check whether it does the job for you too? If so, I am going to
> uninstall it again on my box, verify the issue, and report a bug
> upstream.

Yes, that was the problem.  I wouldn't think that you could suppress
error reporting to such a high degree.  I understand that it makes
sense to suppress errors sent to the browser - you might want to avoid
revealing internal server information.  But why suppress errors sent
to a log file?

Thanks for the help!

Maciej

From dam at opencsw.org  Mon Jun  6 15:40:43 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 6 Jun 2011 15:40:43 +0200
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <4DEC2D37.2010809@opencsw.org>
References: <4DEBD2F3.8070808@opencsw.org>	<BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>	<4DEC251C.5060106@opencsw.org>
	<BANLkTi=saMW6hdBtYX_miBGOHVC9hXBePYSMsh7LNh68Xntkyg@mail.gmail.com>
	<4DEC2D37.2010809@opencsw.org>
Message-ID: <65D204EA-6681-4CAD-87C7-D383CD6E1875@opencsw.org>

Hi John,

Am 06.06.2011 um 03:28 schrieb John Ellson:
> On 06/05/2011 08:55 PM, Maciej Blizi?ski wrote:
>> 2011/6/6 John Ellson <ellson at opencsw.org>:
>>> On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote:
>>>> 2011/6/5 John Ellson <ellson at opencsw.org>:
>>>>> Trying to repackage libxml2 from trunk, with *no* changes, fails because
>>>>> of test failures during "make package"
> 
> The test failures are only from test/ebcdic_566012.xml.   If that test
> is removed, "make check" succeeds.
> 
> I suspect the problem is that CSWiconv doesn't have EBCDIC support:
> 
>    ellson at current9s:ellson> iconv -l | grep -i ebcdic
>    ellson at current9s:ellson>
> 
> We could fix CSWiconv or disable the test in CSWlibxml2

Always good to keep the eyes open. I just looked at the libiconv recipe and
"NOTES" from libiconv-1.13.1 says

  Q: Support EBCDIC ?
  A: No!

However, the packaged and released libxml2 2.7.8 does also not pass this test.

Ben: Do you want to report this upstream?


Best regards

  -- Dago


From dam at opencsw.org  Mon Jun  6 15:46:59 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 6 Jun 2011 15:46:59 +0200
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <4DECD79B.90601@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
	<4DECD79B.90601@opencsw.org>
Message-ID: <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>

Hi John,

Am 06.06.2011 um 15:35 schrieb John Ellson:
>>> 1) Could you install graphvizdevel on unstable9x as well?  (I only have
>>> resources for testing on i386 architecture here).
>> I have uninstalled CSWgraphvizdevel on all unstable* hosts now.
> 
> No, please *install* graphvizdevel-2.28.0 ons unstable9s and unstable9x.
> 
> graphviz is built. Now I need graphvizdevel for building imagemagick.

Ahhhh, sorry. Doing this now.

This gave the following errors on current9s:

> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ...
> Please see /opt/csw/share/doc/graphviz/license for license information.
> 
> dot -c is running now to record available graphviz plugins.
> 
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> 
> Installation of <CSWgraphviz> was successful.
> 
> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ...
> ...



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 ellson at opencsw.org  Mon Jun  6 16:20:33 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 10:20:33 -0400
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
Message-ID: <4DECE231.7010804@opencsw.org>

On 06/06/2011 09:46 AM, Dagobert Michelsen wrote:
>
>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ...
>> Please see /opt/csw/share/doc/graphviz/license for license information.
>>
>> dot -c is running now to record available graphviz plugins.
>>
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>
>> Installation of <CSWgraphviz> was successful.
>>
>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ...
>> ...
>
Do you see the same errors on current9x ?      I'm guessing no, because
it installs on my home box ok.



From dam at opencsw.org  Mon Jun  6 16:44:10 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 6 Jun 2011 16:44:10 +0200
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <4DECE231.7010804@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
	<4DECE231.7010804@opencsw.org>
Message-ID: <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>

Hi John,

Am 06.06.2011 um 16:20 schrieb John Ellson:
> On 06/06/2011 09:46 AM, Dagobert Michelsen wrote:
>> 
>>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ...
>>> Please see /opt/csw/share/doc/graphviz/license for license information.
>>> 
>>> dot -c is running now to record available graphviz plugins.
>>> 
>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>> 
>>> Installation of <CSWgraphviz> was successful.
>>> 
>>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ...
>>> ...
>> 
> 
> Do you see the same errors on current9x ?      I'm guessing no, because
> it installs on my home box ok.

In fact I do:

> *** Installing on unstable9x
> => Fetching new catalog and descriptions (http://mirror/opencsw-future/unstable/i386/5.9) if available ...
> --2011-06-06 15:45:40--  http://mirror/opencsw-future/unstable/i386/5.9/catalog
> Resolving proxy... 192.168.1.6
> Connecting to proxy|192.168.1.6|:3128... connected.
> Proxy request sent, awaiting response... 200 OK
> Length: 588293 (575K) [text/plain]
> Saving to: `/var/opt/csw/pkgutil/catalog.mirror_opencsw-future_unstable_i386_5.9.tmp'
> 
>      0K .......... .......... .......... .......... ..........  8% 7.02M 0s
>     50K .......... .......... .......... .......... .......... 17% 10.7M 0s
>    100K .......... .......... .......... .......... .......... 26% 11.0M 0s
>    150K .......... .......... .......... .......... .......... 34% 12.4M 0s
>    200K .......... .......... .......... .......... .......... 43% 10.3M 0s
>    250K .......... .......... .......... .......... .......... 52% 10.5M 0s
>    300K .......... .......... .......... .......... .......... 60% 11.9M 0s
>    350K .......... .......... .......... .......... .......... 69% 11.4M 0s
>    400K .......... .......... .......... .......... .......... 78% 10.7M 0s
>    450K .......... .......... .......... .......... .......... 87% 11.2M 0s
>    500K .......... .......... .......... .......... .......... 95% 10.7M 0s
>    550K .......... .......... ....                            100% 11.6M=0.05s
> 
> 2011-06-06 15:45:40 (10.5 MB/s) - `/var/opt/csw/pkgutil/catalog.mirror_opencsw-future_unstable_i386_5.9.tmp' saved [588293/588293]
> 
> --2011-06-06 15:45:40--  http://mirror/opencsw-future/unstable/i386/5.9/descriptions
> Resolving proxy... 192.168.1.6
> Connecting to proxy|192.168.1.6|:3128... connected.
> Proxy request sent, awaiting response... 200 OK
> Length: 169252 (165K) [text/plain]
> Saving to: `/var/opt/csw/pkgutil/descriptions.mirror_opencsw-future_unstable_i386_5.9.tmp'
> 
>      0K .......... .......... .......... .......... .......... 30% 6.86M 0s
>     50K .......... .......... .......... .......... .......... 60% 10.8M 0s
>    100K .......... .......... .......... .......... .......... 90% 10.9M 0s
>    150K .......... .....                                      100% 14.3M=0.02s
> 
> 2011-06-06 15:45:40 (9.40 MB/s) - `/var/opt/csw/pkgutil/descriptions.mirror_opencsw-future_unstable_i386_5.9.tmp' saved [169252/169252]
> 
> ==> 3026 packages loaded from /var/opt/csw/pkgutil/catalog.mirror_opencsw-future_unstable_i386_5.9
> Solving needed dependencies ...
> Solving dependency order ...
> Install 2 NEW packages: CSWgraphviz-2.28.0,REV=2011.06.05 CSWgraphvizdevel-2.28.0,REV=2011.06.05
> Install 7 UPDATED packages: CSWlibcdt5-2.28.0,REV=2011.06.05 CSWlibcgraph6-2.28.0,REV=2011.06.05 CSWlibgraph5-2.28.0,REV=2011.06.05 CSWlibgvc6-2.28.0,REV=2011.06.05 CSWlibgvpr2-2.28.0,REV=2011.06.05 CSWlibpathplan4-2.28.0,REV=2011.06.05 CSWlibxdot4-2.28.0,REV=2011.06.05
> 93 CURRENT packages: CSWbonobo2-2.24.3,REV=2010.06.25 CSWbzip2-1.0.6,REV=2010.09.21 CSWcacertificates-20091101,REV=2009.11.01 CSWcas-cpsampleconf-1.42,REV=2010.11.26 CSWcas-crontab-1.42,REV=2010.11.26 CSWcas-etcservices-1.42,REV=2011.02.16 CSWcas-inetd-1.42,REV=2010.11.26 CSWcas-initsmf-1.44,REV=2011.04.21 CSWcas-migrateconf-1.42,REV=2010.11.26 CSWcas-postmsg-1.42,REV=2010.11.26 CSWcas-preserveconf-1.42,REV=2010.11.26 CSWcas-pycompile-1.42,REV=2010.11.26 CSWcas-texinfo-1.42,REV=2010.11.26 CSWcas-usergroup-1.42,REV=2010.11.26 CSWcommon-1.5,REV=2010.12.11 CSWcswclassutils-1.42,REV=2010.11.26 CSWdbusglib-0.86,REV=2010.07.04 CSWexpat-2.0.1,REV=2009.01.22 CSWfam-2.70,REV=2010.06.15 CSWfconfig-2.6.0,REV=2009.04.24 CSWftype2-2.4.2,REV=2010.08.19 CSWgamin-0.1.9,REV=2010.06.15 CSWgcc4corert-4.3.3,REV=2009.05.07 CSWgcc4g++rt-4.3.3,REV=2009.05.07 CSWgconf2-2.28.1,REV=2010.06.26 CSWgcrypt-1.4.6,REV=2010.08.19 CSWggettext-0.18.1.1,p,REV=2011.03.15 CSWggettext-data-0.18.1.1,p,REV=2011.03.15 CSWggettextrt-0.18.1.1,p,REV=2011.03.15 CSWglib2-2.23.5,REV=2010.03.09 CSWgnomevfs2-2.21.90 CSWgnutls-2.10.4,REV=2011.01.18 CSWgpgerr-1.9,REV=2010.09.16 CSWgs-8.71,REV=2010.03.23 CSWgsfonts-8.11 CSWgtk2-2.18.9,REV=2010.06.07 CSWgts-0.7.6,REV=2009.05.20 CSWiconv-1.13.1,REV=2009.07.31 CSWisaexec-0.2,REV=2009.03.26 CSWjbig2dec-0.11,REV=2010.05.17 CSWjbigkit-2.0,REV=2008.10.28 CSWjpeg-7,REV=2009.08.17 CSWkrb5lib-1.4.4,REV=2006.12.27 CSWlibasprintf0-0.18.1.1,p,REV=2011.03.15 CSWlibatk-1.30.0,REV=2010.05.06 CSWlibcairo-1.8.10,REV=2010.06.07 CSWlibcroco-0.6.2,REV=2009.10.09 CSWlibcups-1.4.5,REV=2010.12.24 CSWlibcups2-1.4.5,REV=2010.12.24 CSWlibcupscgi1-1.4.5,REV=2010.12.24 CSWlibcupsdriver1-1.4.5,REV=2010.12.24 CSWlibcupsimage2-1.4.5,REV=2010.12.24 CSWlibcupsmime1-1.4.5,REV=2010.12.24 CSWlibcupsppdc1-1.4.5,REV=2010.12.24 CSWlibdbus-1.3.1,REV=2010.07.04 CSWlibgettextlib0-14-1-0.18.1.1,p,REV=2011.02.12 CSWlibgettextlib0-17-0.18.1.1,p,REV=2011.02.12 CSWlibgettextlib0-18-1-0.18.1.1,p,REV=2011.02.12 CSWlibgettextpo0-0.18.1.1,p,REV=2011.02.12 CSWlibgettextsrc0-18-1-0.18.1.1,p,REV=2011.02.12 CSWlibgnutls13-2.0.4,REV=2011.01.18 CSWlibgnutls26-2.10.4,REV=2011.01.18 CSWlibgsf-1.9.1 CSWlibidl-0.8.14,REV=2010.03.31 CSWlibintl2-0.18.1.1,p,REV=2011.02.12 CSWlibintl3-0.18.1.1,p,REV=2011.02.12 CSWlibintl8-0.18.1.1,p,REV=2011.03.15 CSWliblasi-1.1.0,REV=2009.05.28 CSWlibltdl7-2.4,REV=2011.04.20 CSWlibpixman1-0-0.21.4,REV=2011.02.02 CSWlibpopt-1.15,REV=2009.10.29 CSWlibrsvg-2.26.0,REV=2009.12.20 CSWlibtasn1-3-2.9,REV=2011.05.05 CSWlibxft2-2.1.14,REV=2010.06.07 CSWlibxml2-2-2.7.8,REV=2011.03.24 CSWlibxml2-2.7.8,REV=2011.03.21 CSWlibxml2devel-2.7.8,REV=2011.03.24 CSWlibxrender-0.9.5,REV=2010.05.20 CSWncurses-5.7,REV=2010.05.21 CSWorbit2-2.14.18,REV=2010.03.31 CSWossl-0.9.8r,REV=2011.02.12 CSWossldevel-0.9.8r,REV=2011.02.12 CSWosslrt-0.9.8r,REV=2011.02.12 CSWosslutils-0.9.8r,REV=2011.02.12 CSWpango-1.28.0,REV=2010.06.07 CSWpixman-0.21.4,REV=2011.02.02 CSWpng-1.2.44,REV=2010.06.28 CSWreadline-6.1,REV=2010.01.01 CSWsunmath-2007.08.04 CSWterminfo-5.7,REV=2010.05.21 CSWtiff-3.9.4,REV=2010.07.05 CSWxpm-3.5.8,REV=2010.05.24 CSWzlib-1.2.5,REV=2010.09.22
> 

...
> => Installing CSWlibgvpr2-2.28.0,REV=2011.06.05 (7/9) ...
> Please see /opt/csw/share/doc/libgvpr2/license for license information.
> 
> Installation of <CSWlibgvpr2> was successful.
> 
> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ...
> Please see /opt/csw/share/doc/graphviz/license for license information.
> 
> dot -c is running now to record available graphviz plugins.
> 
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> 
> Installation of <CSWgraphviz> was successful.
> 
> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ...
> Please see /opt/csw/share/doc/graphvizdevel/license for license information.
> 
> Installation of <CSWgraphvizdevel> was successful.




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 ellson at opencsw.org  Mon Jun  6 17:39:24 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 11:39:24 -0400
Subject: [csw-maintainers] pkg-config setup for X11 ?
In-Reply-To: <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
Message-ID: <4DECF4AC.9070503@opencsw.org>

What is the correct PKG_CONFIG_PATH these days, particularly for X11 ?


I currently have:
   
    ellson at unstable9s:ellson> echo $PKG_CONFIG_PATH
    /opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig


But this yields:

    ellson at unstable9s:ellson> pkg-config --libs x11
    -L/opt/csw/lib -lX11 


which does not provide the -L /usr/openwin/lib -lXext needed by, e.g.
/opt/csw/lib/libcairo.so

    ellson at unstable9s:ellson> ldd /opt/csw/lib/libcairo.so | grep X
        libXrender.so.1 =>       /opt/csw/lib/sparcv8/libXrender.so.1
        libX11.so.4 =>   /usr/lib/libX11.so.4
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0


From phil at bolthole.com  Mon Jun  6 19:07:49 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 6 Jun 2011 10:07:49 -0700
Subject: [csw-maintainers] pkg-config setup for X11 ?
In-Reply-To: <4DECF4AC.9070503@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DECF4AC.9070503@opencsw.org>
Message-ID: <BANLkTimhhunjnTTgKwebxjNFfTN+cK_dQw@mail.gmail.com>

On Mon, Jun 6, 2011 at 8:39 AM, John Ellson <ellson at opencsw.org> wrote:
> What is the correct PKG_CONFIG_PATH these days, particularly for X11 ?
>
>
> I currently have:
>
> ? ?ellson at unstable9s:ellson> echo $PKG_CONFIG_PATH
> ? ?/opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig

This is fatally wrong.


Remove PKG_CONFIG_PATH completely. Then make sure that
sunx11_devel
is installed.
That hacks in pkgconfig knowlege of x11, xext, xproto, and a few other things.

From phil at bolthole.com  Mon Jun  6 19:09:57 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 6 Jun 2011 10:09:57 -0700
Subject: [csw-maintainers] gar and php question
In-Reply-To: <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca>
References: <4DEBB025.6010702@opencsw.org>
	<BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
	<1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=xW+KAxpGGYUZxedrgpom_TfHGAw@mail.gmail.com>
	<1307365421-sup-6666@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinrVMgm1i-vcw7HMkjmQ-9dazTy=A@mail.gmail.com>

On Mon, Jun 6, 2011 at 6:05 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Sun Jun 05 23:40:17 -0400 2011:
>
>> i'm not sure that that serves any useful purpose, other than
>> /opt/csw/bin/php I think adding the symlink, effectively
>> accomplishes "moving php5 into the normal namespace"
>
> Well, it is useful as php4 is not supported upstream and we have the
> supported branch (although even our php5 version is unsupported now
> until I get the update finished). ?Removing it from the catalog won't
> prevent those that want it from getting it, but we should make those
> people 'work' for it

why?

> and not provide some pretense that it's a supported package.

we have plenty of packages that are no longer "supported" (ie:
orphaned), but we still keep available.
What specific problem does it solve to remove php4 from our catalog?

From bwalton at opencsw.org  Mon Jun  6 19:53:16 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 06 Jun 2011 13:53:16 -0400
Subject: [csw-maintainers] gar and php question
In-Reply-To: <BANLkTinrVMgm1i-vcw7HMkjmQ-9dazTy=A@mail.gmail.com>
References: <4DEBB025.6010702@opencsw.org>
	<BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
	<1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=xW+KAxpGGYUZxedrgpom_TfHGAw@mail.gmail.com>
	<1307365421-sup-6666@pinkfloyd.chass.utoronto.ca>
	<BANLkTinrVMgm1i-vcw7HMkjmQ-9dazTy=A@mail.gmail.com>
Message-ID: <1307382737-sup-3595@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Jun 06 13:09:57 -0400 2011:

> > Well, it is useful as php4 is not supported upstream and we have
> > the supported branch (although even our php5 version is
> > unsupported now until I get the update finished). ?Removing it
> > from the catalog won't prevent those that want it from getting it,
> > but we should make those people 'work' for it
> 
> why?

Because they can file bugs on it or expect some level of response from
us because it's in the catalog.

> > and not provide some pretense that it's a supported package.
> 
> we have plenty of packages that are no longer "supported" (ie:
> orphaned), but we still keep available.  What specific problem does
> it solve to remove php4 from our catalog?

It's legacy software (as deemed by the upstream).  What benefit is
there in retaining it?

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


From maciej at opencsw.org  Mon Jun  6 20:10:56 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 6 Jun 2011 19:10:56 +0100
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <4DECE231.7010804@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
	<4DECE231.7010804@opencsw.org>
Message-ID: <BANLkTi=TEic-Ny3_ozTjooKqSQtgfZf4zg@mail.gmail.com>

2011/6/6 John Ellson <ellson at opencsw.org>:
> On 06/06/2011 09:46 AM, Dagobert Michelsen wrote:
>>
>>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ...
>>> Please see /opt/csw/share/doc/graphviz/license for license information.
>>>
>>> dot -c is running now to record available graphviz plugins.
>>>
>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>>
>>> Installation of <CSWgraphviz> was successful.
>>>
>>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ...
>>> ...
>>
> Do you see the same errors on current9x ? ? ? ?I'm guessing no, because
> it installs on my home box ok.

Looking at the package metadata:

http://buildfarm.opencsw.org/pkgdb/srv4/a8cd2d66ee68ee509d749f16dd52d143/

The libgvplugin_lasi.so.6 is provided by the same package as the
binary.  I don't quite understand why would this shared library be not
found during runtime.

From phil at bolthole.com  Mon Jun  6 20:20:02 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 6 Jun 2011 11:20:02 -0700
Subject: [csw-maintainers] gar and php question
In-Reply-To: <1307382737-sup-3595@pinkfloyd.chass.utoronto.ca>
References: <4DEBB025.6010702@opencsw.org>
	<BANLkTikh1YQgLsweS+7sK8Z3tQg6zgD=-g@mail.gmail.com>
	<1307325421-sup-8953@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=xW+KAxpGGYUZxedrgpom_TfHGAw@mail.gmail.com>
	<1307365421-sup-6666@pinkfloyd.chass.utoronto.ca>
	<BANLkTinrVMgm1i-vcw7HMkjmQ-9dazTy=A@mail.gmail.com>
	<1307382737-sup-3595@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinysh5y9raLQc+sV=NeeySOEVWTdQ@mail.gmail.com>

On Mon, Jun 6, 2011 at 10:53 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Jun 06 13:09:57 -0400 2011:
>
>> > Well, it is useful as php4 is not supported upstream and we have
>> > the supported branch (although even our php5 version is
>> > unsupported now until I get the update finished). ?Removing it
>> > from the catalog won't prevent those that want it from getting it,
>> > but we should make those people 'work' for it
>>
>> why?
>
> Because they can file bugs on it or expect some level of response from
> us because it's in the catalog.

again, this is no different from our many other packages that are
orphaned, and people will get no response from doing that on those
either :-/

>> we have plenty of packages that are no longer "supported" (ie:
>> orphaned), but we still keep available. ?What specific problem does
>> it solve to remove php4 from our catalog?
>
> It's legacy software (as deemed by the upstream). ?What benefit is
> there in retaining it?

okay, that's a better reason to consider removing it.
But that being said.. we ARE sometimes in the "business" of providing
"legacy" frameworks.


Doing a bit of digging, it appears we agreed on the following, back in 2009:

>> it doesnt look like there are any dependancies of OURS that use it.
>> However, it would need to be carefully announced ahead of time to users.
>
>Agreed.
>
>-Ben

So, please go ahead and announce , that we plan to remove it within
[insert timeframe here].
(and to holler if this for some reason is a problem for someone, and why)

And then after that time, we can remove it.
Since this is by definition extreme legacy software, the people may
not keep up to date with announcements, etc :-} so we may want to set
a somewhat longer timeframe than would otherwise be fine.

July 1st?

From ellson at opencsw.org  Mon Jun  6 20:30:25 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 14:30:25 -0400
Subject: [csw-maintainers] graphviz builds - build farm requests
In-Reply-To: <BANLkTi=TEic-Ny3_ozTjooKqSQtgfZf4zg@mail.gmail.com>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<BANLkTi=TEic-Ny3_ozTjooKqSQtgfZf4zg@mail.gmail.com>
Message-ID: <4DED1CC1.3030409@opencsw.org>

On 06/06/2011 02:10 PM, Maciej Blizi?ski wrote:
> 2011/6/6 John Ellson <ellson at opencsw.org>:
>> On 06/06/2011 09:46 AM, Dagobert Michelsen wrote:
>>>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ...
>>>> Please see /opt/csw/share/doc/graphviz/license for license information.
>>>>
>>>> dot -c is running now to record available graphviz plugins.
>>>>
>>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>>>
>>>> Installation of <CSWgraphviz> was successful.
>>>>
>>>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ...
>>>> ...
>> Do you see the same errors on current9x ?      I'm guessing no, because
>> it installs on my home box ok.
> Looking at the package metadata:
>
> http://buildfarm.opencsw.org/pkgdb/srv4/a8cd2d66ee68ee509d749f16dd52d143/
>
> The libgvplugin_lasi.so.6 is provided by the same package as the
> binary.  I don't quite understand why would this shared library be not
> found during runtime.
Maciej,

I don't either understand either.   Also its working on my
Solaris-10-i386 box at home.

I suspect the message is a bit misleading.   The failure is occuring
because libgvplugin_lasi.so.6 can't be loaded, but it might be one of
the libs used by the plugin that is "file not found"

I don't see any problems with "ldd libgvplugin_lasi.so.6", but perhaps
root's environment that is different?

Unfortunately I can't debug because "dot -c"  needs to run as root in
order to write /opt/csw/lib/graphviz/config6

If you had a chance to run "dot -c" under gdb as root to see whats
happening, that would be really helpful?

John


From ellson at opencsw.org  Mon Jun  6 20:46:46 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 14:46:46 -0400
Subject: [csw-maintainers] request for packages on unstable9[sx]
Message-ID: <4DED2096.4020607@opencsw.org>

I'm going backwards, and accelerating :-(

The ImageMagic build is failing with:
    Undefined                       first referenced
       symbol                             in file
    XSolarisIASetProcessInfo            /lib/libX11.so.4


I believe the reference is coming from librsvg-2.so, so I'm trying to
repackage that.  

                      
Request:    Please install: CSWmozilla on unstable9[sx] for librsvg rebuild.



From phil at bolthole.com  Mon Jun  6 20:48:34 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 6 Jun 2011 11:48:34 -0700
Subject: [csw-maintainers] initialization problem: struct + union
In-Reply-To: <20110605.8241300.1660397962@gyor.oxdrove.co.uk>
References: <BANLkTi=Avk22e+vFdTwxn4q=bN_gFWf0gA@mail.gmail.com>
	<20110605.8241300.1660397962@gyor.oxdrove.co.uk>
Message-ID: <BANLkTim3bDB+GY5MO9svAbvU9myJHrFvuA@mail.gmail.com>

On Sun, Jun 5, 2011 at 1:24 AM, James Lee <james at opencsw.org> wrote:
>
> $ cc test.c
> "test.c", line 16: warning: improper pointer/integer combination: op "="
> $ ./a.out
> snmp_timeout: 2
> snmp_message: time out exceeded
>
>

Thanks for following through all the way to a test case. I had
actually tried that type of mod, but I guess I overreacted when I saw
"improper pointer/integer combination"
and didnt notice it was only a "warning" :-}

real program (mbrowse) now compiles fine.

From dam at opencsw.org  Mon Jun  6 21:32:55 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 6 Jun 2011 21:32:55 +0200
Subject: [csw-maintainers] [csw-buildfarm] request for packages on
	unstable9[sx]
In-Reply-To: <4DED2096.4020607@opencsw.org>
References: <4DED2096.4020607@opencsw.org>
Message-ID: <A99605BD-75FD-4796-A337-D41693CD0312@opencsw.org>

Hi John,

Am 06.06.2011 um 20:46 schrieb John Ellson:
> I'm going backwards, and accelerating :-(
> 
> The ImageMagic build is failing with:
>    Undefined                       first referenced
>       symbol                             in file
>    XSolarisIASetProcessInfo            /lib/libX11.so.4
> 
> I believe the reference is coming from librsvg-2.so, so I'm trying to
> repackage that.  

I don't think so, as "ldd -r librsvg-2.so" does not link to libX11.so.6.
The linkage to libX11.so.4 is the correct one. The error is caused by applications
being linked to libX11.so.6 which however pull in libX11.so.4 earlier by another
dependency.

> Request:    Please install: CSWmozilla on unstable9[sx] for librsvg rebuild.

Apart from the above comment I cannot see CSWmozilla as a dependency on
  http://www.opencsw.org/package/librsvg/

John, from my impression you are moving too fast shooting at everything that
doesn't immediately jump away :-) I suggest you come over to #opencsw so we
can investigate the problem ground up logically.


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 phil at bolthole.com  Tue Jun  7 00:52:51 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 6 Jun 2011 15:52:51 -0700
Subject: [csw-maintainers] An end to IRC back-biting ?
Message-ID: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>

So I happened to be in opencsw irc today, and noticed a board member
stirring up bad feeling about me on it.
And this griping was done, after the irc bot had already announced I
had addressed the issue Maciej had found, in svn, almost as soon as he
let me know about it.


<automaciej> Dagobert, bonivart_mac: Reviewed phil's package, found a surplus
  dep.
<bonivart_mac> :)
<automaciej> self_publishing--
<bonivart_mac> it's funny that his own packages gets released immedlately, no
  independent testing there
<bonivart_mac> double standard
<automaciej> yes, no testing and no review

As I pointed out in the channel afterwards:

 if someone actually VOLUNTEERED to always test my packages, in the same
  timeframe that I usually test others, I would LOVE to have someone else look
  at my packages

There was absolutely no positive effect to be gained from sniping
about me on the public channel, or even mentioning the issue on irc in
the first place, particularly as I'd already addressed the issue.

How about we have an end to negatively talking behind peoples' backs,
on the supposedly
" 'friendly' solaris channel"?

From ellson at opencsw.org  Tue Jun  7 00:57:22 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 18:57:22 -0400
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
Message-ID: <4DED5B52.6070302@opencsw.org>

Dago,

I'm totally baffled by this one.  The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file.


> dot -c is running now to record available graphviz plugins.
> 
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found


This only happens when running on Solaris-9, even though the binaries
were built on Solaris-9.
The binaries for Solaris-10, also built on Solaris-9, don't have this
problem.

This only happens with this plugin.  All the other plugins load as expected.
(This plugin happens to be the only one containing C++ code, but the C++
is wrapped in a C function.)

The error is reported by: lt_dlopen()  which is from libtool.

The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and
the plugin exists there.

Inspecting with ldd and elfdump show nothing unexpected.




Could it be some security feature???  (something like selinux ?)

Could it be something related to preload?

Could it be something related to C++?



The problem can be reproduced on unstable9s or testing9s using the
attached code.


John



 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 89 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110606/5225b1ba/attachment.bin>

From ellson at opencsw.org  Tue Jun  7 01:00:23 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 06 Jun 2011 19:00:23 -0400
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <4DED5B52.6070302@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
Message-ID: <4DED5C07.1010201@opencsw.org>

[Sorry.  Try that attachment again.]


On 06/06/2011 06:57 PM, John Ellson wrote:
> Dago,
>
> I'm totally baffled by this one.  The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file.
>
>
>> dot -c is running now to record available graphviz plugins.
>>
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>
> This only happens when running on Solaris-9, even though the binaries
> were built on Solaris-9.
> The binaries for Solaris-10, also built on Solaris-9, don't have this
> problem.
>
> This only happens with this plugin.  All the other plugins load as expected.
> (This plugin happens to be the only one containing C++ code, but the C++
> is wrapped in a C function.)
>
> The error is reported by: lt_dlopen()  which is from libtool.
>
> The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and
> the plugin exists there.
>
> Inspecting with ldd and elfdump show nothing unexpected.
>
>
>
>
> Could it be some security feature???  (something like selinux ?)
>
> Could it be something related to preload?
>
> Could it be something related to C++?
>
>
>
> The problem can be reproduced on unstable9s or testing9s using the
> attached code.
>
>
> John
>
>
>
>  
>
>
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110606/d00e7f2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 770 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110606/d00e7f2e/attachment.bin>

From phil at bolthole.com  Tue Jun  7 01:22:34 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 6 Jun 2011 16:22:34 -0700
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <4DED5B52.6070302@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
Message-ID: <BANLkTimyqueFq5uHqm5TxaX6TkyDa7M7rw@mail.gmail.com>

On Mon, Jun 6, 2011 at 3:57 PM, John Ellson <ellson at opencsw.org> wrote:
> ....
>>
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>....
>
> The error is reported by: lt_dlopen() ?which is from libtool.
>

well... maybe its a libtool problem. Try loading an older version of
liblt and see what happens.

and/or a small posibility that something in your environment on the
sol9 box is messing things up.
try with "env - blahblah", or a different sol9 box.

From bwalton at opencsw.org  Tue Jun  7 02:46:20 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 06 Jun 2011 20:46:20 -0400
Subject: [csw-maintainers] libxml2 broken
In-Reply-To: <65D204EA-6681-4CAD-87C7-D383CD6E1875@opencsw.org>
References: <4DEBD2F3.8070808@opencsw.org>
	<BANLkTi=Fa7XRBN__9B5-6pS5+j-DkWpHhMg3hSR7ptNRf+OGmQ@mail.gmail.com>
	<4DEC251C.5060106@opencsw.org>
	<BANLkTi=saMW6hdBtYX_miBGOHVC9hXBePYSMsh7LNh68Xntkyg@mail.gmail.com>
	<4DEC2D37.2010809@opencsw.org>
	<65D204EA-6681-4CAD-87C7-D383CD6E1875@opencsw.org>
Message-ID: <1307407557-sup-3296@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Mon Jun 06 09:40:43 -0400 2011:

> Always good to keep the eyes open. I just looked at the libiconv recipe and
> "NOTES" from libiconv-1.13.1 says
> 
>   Q: Support EBCDIC ?
>   A: No!
> 
> However, the packaged and released libxml2 2.7.8 does also not pass this test.
> 
> Ben: Do you want to report this upstream?

Sure.  Let me get a good set of info together to shoot up there and
I'll do so.

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


From bonivart at opencsw.org  Tue Jun  7 10:57:59 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 7 Jun 2011 10:57:59 +0200
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
Message-ID: <BANLkTinGGUV3DHJOqjzcbuNvPpLUQ3QT4g@mail.gmail.com>

On Tue, Jun 7, 2011 at 12:52 AM, Philip Brown <phil at bolthole.com> wrote:
> So I happened to be in opencsw irc today, and noticed a board member
> stirring up bad feeling about me on it.
>
> ...
>
> How about we have an end to negatively talking behind peoples' backs,
> on the supposedly
> " 'friendly' solaris channel"?

I don't think this qualifies as "talking behind peoples backs" at all,
you were online and could have engaged at any time, apparently you did
so after I was already offline. Whether or not you feel it was
negative (for you) I stand by what I said.

/peter

From dam at opencsw.org  Tue Jun  7 16:29:28 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 7 Jun 2011 16:29:28 +0200
Subject: [csw-maintainers] Rebuild of ImageMagick
Message-ID: <EF03FBA2-4453-4FBC-ABBC-F1AF600FD3D7@opencsw.org>

Hi,

I am currently looking at a rebuild of ImageMagick and noticed some things on legacy libraries:
They seem to require tons of other libs and configuration files which would be pulled in from
the ordinary CSWimagemagick. The only dependencies are
  CSWpstoedit
  CSWkofficegcc

Peter: Would you mind rebuilding pstoedit against an updated imagemagick on unstable* ?

I would like to completely drop CSWkofficegcc as it is already old, broken and I don't
see anyone is interested in it any more.

After that we could just ditch the old libraries *.so.10, *.so.2 and *.so.3

John: After that I could release ImageMagick build against the updated graphviz.

Roger: Feel free to chime in and take over at any time :-)


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 ellson at opencsw.org  Tue Jun  7 16:35:43 2011
From: ellson at opencsw.org (John Ellson)
Date: Tue, 07 Jun 2011 10:35:43 -0400
Subject: [csw-maintainers] Rebuild of ImageMagick
In-Reply-To: <EF03FBA2-4453-4FBC-ABBC-F1AF600FD3D7@opencsw.org>
References: <EF03FBA2-4453-4FBC-ABBC-F1AF600FD3D7@opencsw.org>
Message-ID: <4DEE373F.4030404@opencsw.org>

On 06/07/2011 10:29 AM, Dagobert Michelsen wrote:
> Hi,
>
> I am currently looking at a rebuild of ImageMagick and noticed some things on legacy libraries:
> They seem to require tons of other libs and configuration files which would be pulled in from
> the ordinary CSWimagemagick. The only dependencies are
>   CSWpstoedit
>   CSWkofficegcc
>
> Peter: Would you mind rebuilding pstoedit against an updated imagemagick on unstable* ?
>
> I would like to completely drop CSWkofficegcc as it is already old, broken and I don't
> see anyone is interested in it any more.
>
> After that we could just ditch the old libraries *.so.10, *.so.2 and *.so.3
>
> John: After that I could release ImageMagick build against the updated graphviz.

Dago,

I notice you have a new librsvg too?  So am I correct that I should
rebuild graphviz once  librsvg is installed on current9[sx] ?

Is librvg built for 64bits?    Should I attempt to turn that on in the
graphviz build?

John


> Roger: Feel free to chime in and take over at any time :-)
>
>
> Best regards
>
>   -- Dago
>


From dam at opencsw.org  Tue Jun  7 16:49:20 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 7 Jun 2011 16:49:20 +0200
Subject: [csw-maintainers] Rebuild of ImageMagick
In-Reply-To: <4DEE373F.4030404@opencsw.org>
References: <EF03FBA2-4453-4FBC-ABBC-F1AF600FD3D7@opencsw.org>
	<4DEE373F.4030404@opencsw.org>
Message-ID: <D7E69F88-A6D8-44CB-8B8D-7BC526DA8125@opencsw.org>

Hi John,

Am 07.06.2011 um 16:35 schrieb John Ellson:
> On 06/07/2011 10:29 AM, Dagobert Michelsen wrote:
>> I am currently looking at a rebuild of ImageMagick and noticed some things on legacy libraries:
>> They seem to require tons of other libs and configuration files which would be pulled in from
>> the ordinary CSWimagemagick. The only dependencies are
>>  CSWpstoedit
>>  CSWkofficegcc
>> 
>> Peter: Would you mind rebuilding pstoedit against an updated imagemagick on unstable* ?
>> 
>> I would like to completely drop CSWkofficegcc as it is already old, broken and I don't
>> see anyone is interested in it any more.
>> 
>> After that we could just ditch the old libraries *.so.10, *.so.2 and *.so.3
>> 
>> John: After that I could release ImageMagick build against the updated graphviz.
> 
> Dago,
> 
> I notice you have a new librsvg too?  So am I correct that I should
> rebuild graphviz once  librsvg is installed on current9[sx] ?

As it has the new library naming, yes. Apart from that there should be no
change as the soname is identical to the old one.

> Is librvg built for 64bits?

Nope, there are too many missing bits for gnome not ready yet.

> Should I attempt to turn that on in the graphviz build?

You can try and disable all components not ready yet. That would make the
shortcomings visible and you could file bugs for these and enable them
one by one as they become available.


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 phil at bolthole.com  Tue Jun  7 17:12:33 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 7 Jun 2011 08:12:33 -0700
Subject: [csw-maintainers] Rebuild of ImageMagick
In-Reply-To: <EF03FBA2-4453-4FBC-ABBC-F1AF600FD3D7@opencsw.org>
References: <EF03FBA2-4453-4FBC-ABBC-F1AF600FD3D7@opencsw.org>
Message-ID: <BANLkTim54WBoGBcOw-EF5rq0qcvf-sPPbw@mail.gmail.com>

On Tue, Jun 7, 2011 at 7:29 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
>
> I would like to completely drop CSWkofficegcc as it is already old, broken and I don't
> see anyone is interested in it any more.

this is probably a good idea.

But... given the size of it, you should make a "plan to drop"
announcement on users/announce list first, and wait a bit for
feedback.

From dam at opencsw.org  Tue Jun  7 17:17:25 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 7 Jun 2011 17:17:25 +0200
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <4DED5B52.6070302@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
Message-ID: <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>

Hi John,

Am 07.06.2011 um 00:57 schrieb John Ellson:
> I'm totally baffled by this one.  The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file.
> 
>> dot -c is running now to record available graphviz plugins.
>> 
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> 
> This only happens when running on Solaris-9, even though the binaries
> were built on Solaris-9.
> The binaries for Solaris-10, also built on Solaris-9, don't have this
> problem.

In fact they do, probably we have tested the wrong thing:

unstable10s# dot -c
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found

> This only happens with this plugin.  All the other plugins load as expected.
> (This plugin happens to be the only one containing C++ code, but the C++
> is wrapped in a C function.)
> 
> The error is reported by: lt_dlopen()  which is from libtool.
> 
> The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and
> the plugin exists there.
> 
> Inspecting with ldd and elfdump show nothing unexpected.

Try "ldd -r" and you see that there are lots of errors. The come from
  /opt/csw/lib/libLASi.so
because there has been no NEEDED for libCstd.so for Sun Studio in it.
Try adding -lCstd to the linker flags of liblasi and I am confident it will
work then.


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 dam at opencsw.org  Tue Jun  7 17:40:58 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 7 Jun 2011 17:40:58 +0200
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
Message-ID: <C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>

Hi John,

Am 07.06.2011 um 17:17 schrieb Dagobert Michelsen:
> Am 07.06.2011 um 00:57 schrieb John Ellson:
>> I'm totally baffled by this one.  The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file.
>> 
>>> dot -c is running now to record available graphviz plugins.
>>> 
>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> 
>> This only happens when running on Solaris-9, even though the binaries
>> were built on Solaris-9.
>> The binaries for Solaris-10, also built on Solaris-9, don't have this
>> problem.
> 
> In fact they do, probably we have tested the wrong thing:
> 
> unstable10s# dot -c
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
> 
>> This only happens with this plugin.  All the other plugins load as expected.
>> (This plugin happens to be the only one containing C++ code, but the C++
>> is wrapped in a C function.)
>> 
>> The error is reported by: lt_dlopen()  which is from libtool.
>> 
>> The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and
>> the plugin exists there.
>> 
>> Inspecting with ldd and elfdump show nothing unexpected.
> 
> Try "ldd -r" and you see that there are lots of errors. The come from
>  /opt/csw/lib/libLASi.so
> because there has been no NEEDED for libCstd.so for Sun Studio in it.
> Try adding -lCstd to the linker flags of liblasi and I am confident it will
> work then.

I rebuild liblasi and everything looks good. I am commiting my work so
you can rebuild and rerelease the liblasi packages.


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 bwalton at opencsw.org  Wed Jun  8 03:12:38 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 07 Jun 2011 21:12:38 -0400
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
Message-ID: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Jun 06 18:52:51 -0400 2011:

Hi Phil,

> There was absolutely no positive effect to be gained from sniping
> about me on the public channel, or even mentioning the issue on irc
> in the first place, particularly as I'd already addressed the issue.

You frustrate people.  People need to vent and say things like this
when they're frustrated.  As many of us hang out in irc all the time,
it's the natural place to do so.  It's the kind of thing friends do
with each other.

This particular jab stems from the perception that you hold yourself
as better than everyone else in the project.  You may not actually
feel this way, but to put it succinctly, this is the impression you
give.  It's perception that counts here.

If you could step back and see how your interactions with people
negatively colour their view of you, you might come to realize why
we're all so frustrated.  We've tried explaining it to you but you've
ignored, misinterpreted or outright dismissed the explanations.

I've gotten to the point where I find it incredibly difficult to
engage you at all.  I'm sure you've noticed that I walk away from
conversations with you, knowing full well that you'll reply anyway.
You may have also noticed a distinct lack of response to mailing list
threads you start.  People just don't think it's worth their time.

Is it just me?  Maybe.  I don't think it's all you as it does take two
to tango.  That being said, I have to wonder why so many others share
the same sentiment?  Then I'd wonder why everyone else is able to
interact so positively all the time?

> How about we have an end to negatively talking behind peoples'
> backs, on the supposedly " 'friendly' solaris channel"?

The channel _is_ very friendly.  I don't think I'd be stretching
things in the least to say that we're one of the best resources on the
net for helpful advice on solaris.  If you hung out and actually
participated in the community, perhaps you'd agree.

Although you may take this as just another personal attack, please
accept it as a sincere, honest and direct response.  It's borne out of
the same frustration that Maciej and Peter feel when they take part in
irc conversations such as the one you quoted.

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


From ellson at opencsw.org  Wed Jun  8 04:40:55 2011
From: ellson at opencsw.org (John Ellson)
Date: Tue, 07 Jun 2011 22:40:55 -0400
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
Message-ID: <4DEEE137.6040304@opencsw.org>

Dago,

I don't know how you got liblasi to build?   I had to change to:
    CXXFLAGS = -L/usr/lib -lCstd -norunpath

Then the "make test" would pass the first build.

But then the 64bit build failed with:

Linking CXX shared library libLASi.so
cd
/home/ellson/mgar/pkg/liblasi/trunk/work/solaris9-sparc/build-isa-sparcv9/libLASi-1.1.0/src
&& /opt/csw/bin/cmake -E cmake_link_script CMakeFiles/LASi.dir/link.txt
--verbose=1
/opt/SUNWspro/bin/CC  -KPIC -L/usr/lib -lCstd -norunpath  -G
-hlibLASi.so.0 -o libLASi.so.0.0.1 CMakeFiles/LASi.dir/drawGlyph.o
CMakeFiles/LASi.dir/glyphMgr.o CMakeFiles/LASi.dir/psDoc.o
CMakeFiles/LASi.dir/util.o -L/opt/csw/lib/sparcv9 -L/opt/csw/lib/64
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread
-lrt -lglib-2.0 -lintl -lpangoft2-1.0 -lpango-1.0 -lfreetype
-lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread
-lthread -lrt -lglib-2.0 -lintl -lfreetype -lm -lpango-1.0
-lpangoft2-1.0 -lfontconfig -lm -R/opt/csw/lib/sparcv9:/opt/csw/lib/64:
ld: fatal: file /opt/csw/lib/sparcv9/libfreetype.so: wrong ELF class:
ELFCLASS64
ld: fatal: file /opt/csw/lib/sparcv9/libfreetype.so: wrong ELF class:
ELFCLASS64
ld: fatal: File processing errors. No output written to libLASi.so.0.0.1
gmake[4]: *** [src/libLASi.so.0.0.1] Error 1
gmake[4]: Leaving directory
`/home/ellson/mgar/pkg/liblasi/trunk/work/solaris9-sparc/build-isa-sparcv9/libLASi-1.1.0'

So I disabled the 64bit build for now.

John

On 06/07/2011 11:40 AM, Dagobert Michelsen wrote:
> Hi John,
>
> Am 07.06.2011 um 17:17 schrieb Dagobert Michelsen:
>> Am 07.06.2011 um 00:57 schrieb John Ellson:
>>> I'm totally baffled by this one.  The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file.
>>>
>>>> dot -c is running now to record available graphviz plugins.
>>>>
>>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>> This only happens when running on Solaris-9, even though the binaries
>>> were built on Solaris-9.
>>> The binaries for Solaris-10, also built on Solaris-9, don't have this
>>> problem.
>> In fact they do, probably we have tested the wrong thing:
>>
>> unstable10s# dot -c
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found
>>
>>> This only happens with this plugin.  All the other plugins load as expected.
>>> (This plugin happens to be the only one containing C++ code, but the C++
>>> is wrapped in a C function.)
>>>
>>> The error is reported by: lt_dlopen()  which is from libtool.
>>>
>>> The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and
>>> the plugin exists there.
>>>
>>> Inspecting with ldd and elfdump show nothing unexpected.
>> Try "ldd -r" and you see that there are lots of errors. The come from
>>  /opt/csw/lib/libLASi.so
>> because there has been no NEEDED for libCstd.so for Sun Studio in it.
>> Try adding -lCstd to the linker flags of liblasi and I am confident it will
>> work then.
> I rebuild liblasi and everything looks good. I am commiting my work so
> you can rebuild and rerelease the liblasi packages.
>
>
> Best regards
>
>   -- Dago
>
>


From ellson at opencsw.org  Wed Jun  8 04:52:06 2011
From: ellson at opencsw.org (John Ellson)
Date: Tue, 07 Jun 2011 22:52:06 -0400
Subject: [csw-maintainers] csw-update-pkg does more checks????
In-Reply-To: <4DEEE137.6040304@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>	<4DED5B52.6070302@opencsw.org>	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
	<4DEEE137.6040304@opencsw.org>
Message-ID: <4DEEE3D6.8060700@opencsw.org>

liblasi built, passed its tests, successfully packaged, so I thought I'd
try pushing it with csw-update-pkg, but no, apparently csw-update-pkg
does some additional tests, tests that absolutely couldn't have been
done earlier in the build process ?!, which failed.

ellson at login:~> mgar/pkg/liblasi/trunk/gar/bin/csw-upload-pkg
newpkgs/liblasi*
There is a problem with the presented file list.
* CheckpkgTag(None, 'bad-arch-or-os-release', 'liblasi arch=unknown
osrel=unspecified')
* CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi0')
* CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi0')
* CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_dev')
* CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_stub')
* CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_dev')
* CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_stub')
* CheckpkgTag(None, 'bad-vendor-tag', 'filename=liblasi expected=CSW
actual=UNKN')


I give up.....   perhaps tomorrow?

Cranky John

From maciej at opencsw.org  Wed Jun  8 04:54:57 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Wed, 8 Jun 2011 03:54:57 +0100
Subject: [csw-maintainers] csw-update-pkg does more checks????
In-Reply-To: <4DEEE3D6.8060700@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
	<4DEEE137.6040304@opencsw.org> <4DEEE3D6.8060700@opencsw.org>
Message-ID: <BANLkTikhw-Z4XVSxrMSo5ZEQiiNQh-OzUExcPE7qvMXcrZBQtg@mail.gmail.com>

Hi John,

To address the subject - yes, it does more checks.  For example, if
you give it a sparc package with foo, it will expect there to be also
a i386 package with foo, and it will complain if it's not there.

2011/6/8 John Ellson <ellson at opencsw.org>:
> liblasi built, passed its tests, successfully packaged, so I thought I'd
> try pushing it with csw-update-pkg, but no, apparently csw-update-pkg
> does some additional tests, tests that absolutely couldn't have been
> done earlier in the build process ?!, which failed.
>
> ellson at login:~> mgar/pkg/liblasi/trunk/gar/bin/csw-upload-pkg
> newpkgs/liblasi*
> There is a problem with the presented file list.
> * CheckpkgTag(None, 'bad-arch-or-os-release', 'liblasi arch=unknown
> osrel=unspecified')
> * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi0')
> * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi0')
> * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_dev')
> * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_stub')
> * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_dev')
> * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_stub')
> * CheckpkgTag(None, 'bad-vendor-tag', 'filename=liblasi expected=CSW
> actual=UNKN')

I suspect that a non-package file was passed as an argument.

What was the exact file list? (i.e. output of echo newpkgs/liblasi*)

Maciej

From ellson at opencsw.org  Wed Jun  8 05:01:40 2011
From: ellson at opencsw.org (John Ellson)
Date: Tue, 07 Jun 2011 23:01:40 -0400
Subject: [csw-maintainers] csw-update-pkg does more checks????
In-Reply-To: <BANLkTikhw-Z4XVSxrMSo5ZEQiiNQh-OzUExcPE7qvMXcrZBQtg@mail.gmail.com>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>	<4DED5B52.6070302@opencsw.org>	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>	<4DEEE137.6040304@opencsw.org>
	<4DEEE3D6.8060700@opencsw.org>
	<BANLkTikhw-Z4XVSxrMSo5ZEQiiNQh-OzUExcPE7qvMXcrZBQtg@mail.gmail.com>
Message-ID: <4DEEE614.9030405@opencsw.org>

On 06/07/2011 10:54 PM, Maciej Blizi?ski wrote:
>
> I suspect that a non-package file was passed as an argument.
>
> What was the exact file list? (i.e. output of echo newpkgs/liblasi*)

Ah! You're so correct. I had a directory in there named liblasi.

newpkgs/liblasi*gz

worked much better. Thanks.

John


From dam at opencsw.org  Wed Jun  8 09:14:54 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 8 Jun 2011 09:14:54 +0200
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <4DEEE137.6040304@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
	<4DEEE137.6040304@opencsw.org>
Message-ID: <81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org>

Hi John,

Am 08.06.2011 um 04:40 schrieb John Ellson:
> I don't know how you got liblasi to build?   I had to change to:
>    CXXFLAGS = -L/usr/lib -lCstd -norunpath

This has a number of issues:

1. Setting CXXFLAGS unconditionally overwrites the GAR defaults.
   This means that e.g. -xarch=sparcv8 and -m64 is overwritten
   resulting in failing 64 build and sparcv8+ (compiler default)
   binaries in sparcv8 dirs. EXTRA_* makes sure the value is
   appended to the GAR defaults.

2. /usr/lib only contains 32 bit libraries. If you build things
   with 64 bit the best way is to use EXTRA_LIB = <libdir> which
   gets the ISA-specific subdirectory attached by default.

LDFLAGS does not work because it is not set in the configure-custom rule
for cmake. This was done manually by the original Makefile author and
would need adjustment by someone who knows cmake (not me).

The failing test for 64 bit seems to origin from a missing
  sparcv9/pango-querymodules
because binaries for 64 bit are stripped by default and just libs are in the
package. Fixing CSWpango now. It is a long way to 64 bit...

Additionally, I recommend not pushing things with controversial overrides
in it. As it worked for me it would be better to reply with "I get
error abc on host xyz and can't find the cause".


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 ellson at opencsw.org  Wed Jun  8 14:09:26 2011
From: ellson at opencsw.org (John Ellson)
Date: Wed, 08 Jun 2011 08:09:26 -0400
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
	<4DEEE137.6040304@opencsw.org>
	<81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org>
Message-ID: <4DEF6676.1070900@opencsw.org>

Dago,

Re: liblasi

This worked much better:

    EXTRA_LIB = -L/usr/lib -lCstd -norunpath

64 bit is disabled (fails tests)

Makefile contains the following overrides:

    # That is ok
    CHECKPKG_OVERRIDES_CSWliblasi-dev +=
file-with-bad-content|/usr/local|root/opt/csw/share/doc/liblasi/examples/README

    # Not sure about these
    CHECKPKG_OVERRIDES_CSWliblasi0 +=
bad-rpath-entry|/opt/SUNWspro/lib/v8|opt/csw/lib/libLASi.so.0.0.1
    CHECKPKG_OVERRIDES_CSWliblasi0 +=
bad-rpath-entry|/opt/SUNWspro/lib/rw7|opt/csw/lib/libLASi.so.0.0.1
    CHECKPKG_OVERRIDES_CSWliblasi0 +=
bad-rpath-entry|/lib|opt/csw/lib/libLASi.so.0.0.1
    CHECKPKG_OVERRIDES_CSWliblasi0 +=
bad-rpath-entry|/opt/SUNWspro/lib|opt/csw/lib/libLASi.so.0.0.1


OK to push?

John





On 06/08/2011 03:14 AM, Dagobert Michelsen wrote:
> Hi John,
>
> Am 08.06.2011 um 04:40 schrieb John Ellson:
>> I don't know how you got liblasi to build?   I had to change to:
>>    CXXFLAGS = -L/usr/lib -lCstd -norunpath
> This has a number of issues:
>
> 1. Setting CXXFLAGS unconditionally overwrites the GAR defaults.
>    This means that e.g. -xarch=sparcv8 and -m64 is overwritten
>    resulting in failing 64 build and sparcv8+ (compiler default)
>    binaries in sparcv8 dirs. EXTRA_* makes sure the value is
>    appended to the GAR defaults.
>
> 2. /usr/lib only contains 32 bit libraries. If you build things
>    with 64 bit the best way is to use EXTRA_LIB = <libdir> which
>    gets the ISA-specific subdirectory attached by default.
>
> LDFLAGS does not work because it is not set in the configure-custom rule
> for cmake. This was done manually by the original Makefile author and
> would need adjustment by someone who knows cmake (not me).
>
> The failing test for 64 bit seems to origin from a missing
>   sparcv9/pango-querymodules
> because binaries for 64 bit are stripped by default and just libs are in the
> package. Fixing CSWpango now. It is a long way to 64 bit...
>
> Additionally, I recommend not pushing things with controversial overrides
> in it. As it worked for me it would be better to reply with "I get
> error abc on host xyz and can't find the cause".
>
>
> Best regards
>
>   -- Dago
>


From dam at opencsw.org  Wed Jun  8 14:13:52 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 8 Jun 2011 14:13:52 +0200
Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem
In-Reply-To: <4DEF6676.1070900@opencsw.org>
References: <4DECA955.9020408@opencsw.org>	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>	<4DECD79B.90601@opencsw.org>	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
	<4DEEE137.6040304@opencsw.org>
	<81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org>
	<4DEF6676.1070900@opencsw.org>
Message-ID: <D6BEA10E-9020-4D73-A363-57880C27D3D7@opencsw.org>

Hi John,

Am 08.06.2011 um 14:09 schrieb John Ellson:

> Dago,
> 
> Re: liblasi
> 
> This worked much better:
> 
>    EXTRA_LIB = -L/usr/lib -lCstd -norunpath
> 
> 64 bit is disabled (fails tests)
> 
> Makefile contains the following overrides:
> 
>    # That is ok
>    CHECKPKG_OVERRIDES_CSWliblasi-dev +=
> file-with-bad-content|/usr/local|root/opt/csw/share/doc/liblasi/examples/README
> 
>    # Not sure about these
>    CHECKPKG_OVERRIDES_CSWliblasi0 +=
> bad-rpath-entry|/opt/SUNWspro/lib/v8|opt/csw/lib/libLASi.so.0.0.1
>    CHECKPKG_OVERRIDES_CSWliblasi0 +=
> bad-rpath-entry|/opt/SUNWspro/lib/rw7|opt/csw/lib/libLASi.so.0.0.1
>    CHECKPKG_OVERRIDES_CSWliblasi0 +=
> bad-rpath-entry|/lib|opt/csw/lib/libLASi.so.0.0.1
>    CHECKPKG_OVERRIDES_CSWliblasi0 +=
> bad-rpath-entry|/opt/SUNWspro/lib|opt/csw/lib/libLASi.so.0.0.1
> 
> 
> OK to push?

No, see my previous mail. Using EXTRA_LIB instead of EXTRA_CXXFLAGS
I used earlier mixes up -norunpath to -L-norunpath basically disabling
it. See for an explanation
  http://wiki.opencsw.org/checkpkg-error-tags#bad-rpath-entry

On one hand I find it pretty enlighting to see issues coming up,
however, the shere amount of issues on 64 bit is quite... frightening.
However, I am confident that most of them should be fixed soon with
the updated released of pango/cairo/liblasi.


Best regards

  -- Dago


From dam at opencsw.org  Wed Jun  8 19:53:48 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 8 Jun 2011 19:53:48 +0200
Subject: [csw-maintainers] Status of Graphviz update and assorted packages
Message-ID: <117AB9B9-7C77-481A-9995-35B974926944@opencsw.org>

Hi,

the major Graphviz update is coming along. Due to historic dependencies the updated
Graphviz will be acompanied by a bunch of other packages which also have been rebuild
due to older libs from graphviz we would like to abandon. This is especially
  CSWimagemagick
As the updated ImageMagick also some older libs we would like to get rid of Peter Felecan
will also rebuild CSWpstoedit against the updated ImageMagick.

The packages will be collected in /home/experimental/graphviz and released in one
large set.

The updated ImageMagick will still be 32 bit only for now, but the project "imagemagick64"
will be done when all dependencies are ready at a later time.

Testing the updated GraphViz resulted in a chained fault to be detected in
liblasi/pango/cairo which I have fixed. These will be released one at a time
as there is no strict dependency on the above.


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 dam at opencsw.org  Wed Jun  8 19:57:36 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 8 Jun 2011 19:57:36 +0200
Subject: [csw-maintainers] Status of Graphviz update and assorted
	packages
In-Reply-To: <117AB9B9-7C77-481A-9995-35B974926944@opencsw.org>
References: <117AB9B9-7C77-481A-9995-35B974926944@opencsw.org>
Message-ID: <596B00C9-3DD2-4917-98AC-2AA8EAFCB248@opencsw.org>

Hi folks,

Am 08.06.2011 um 19:53 schrieb Dagobert Michelsen:
> As the updated ImageMagick also some older libs we would like to get rid of Peter Felecan
> will also rebuild CSWpstoedit against the updated ImageMagick.

I meant "As the updated ImageMagick also CONTAINS some older libs we would like to get rid of,
AND Peter Felecan will also rebuild CSWpstoedit against the updated ImageMagick."

:-)

-- 
"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 phil at bolthole.com  Wed Jun  8 20:35:58 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 8 Jun 2011 11:35:58 -0700
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>

On Tue, Jun 7, 2011 at 6:12 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Jun 06 18:52:51 -0400 2011:
>
> Hi Phil,
>
>> There was absolutely no positive effect to be gained from sniping
>> about me on the public channel, or even mentioning the issue on irc
>> in the first place, particularly as I'd already addressed the issue.
>
> You frustrate people. ?People need to vent and say things like this
> when they're frustrated. ?As many of us hang out in irc all the time,
> it's the natural place to do so. ?It's the kind of thing friends do
> with each other.
>...
> It's perception that counts here.
>....
> Is it just me? ?Maybe. ?I don't think it's all you as it does take two
> to tango. ?That being said, I have to wonder why so many others share
> the same sentiment?


Right now, "so many others share the same sentiment", because it has
become accepted practice to bitch about me to others, rather than
engage with me.
You mention people's perceptions of me; however, people's views of a
person, are strongly shaped by what other people say about that
person. Even people who have not had issues with me in the past, have
their attitude biased against me because of this stuff.

It's self-fullfilling. If people are getting reinforced by comments on
irc, "Phil is difficult to deal with", then as part of human nature,
they will view everything I say through a "negative" filter, even when
the content is neutral.

What I quoted from irc is a perfect example of the locked-in bias.
My behaviour was exemplary in this issue: I responded quickly, and in
a manner favorable to the person who approached me..

**yet they still griped about me** ??

How is this in any way equitable?
How did my actions in this case, in any way merit this treatment?

It seems like just the opposite should be the case.
An unbiased person might have even taken a moment to say, "Huh. Phil
is responsive to complaints about his own packages. Maybe I should try
to be equally responsive".

But the anti-Phil bias is so strong in some people, the notion of
cutting me some slack, or giving me some positive credit, seems
impossible.


>> How about we have an end to negatively talking behind peoples'
>> backs, on the supposedly " 'friendly' solaris channel"?
>
> The channel _is_ very friendly.

except towards me. unjustifiably.
you suggest I hang out there more, but why would I wish to when people
treat me like this? it's extremely unpleasant.

From dam at opencsw.org  Wed Jun  8 20:56:43 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 8 Jun 2011 20:56:43 +0200
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
Message-ID: <5111CA35-F2C8-4BE3-930E-42BA8099C704@opencsw.org>

Hi Phil,

Am 08.06.2011 um 20:35 schrieb Philip Brown:
> you suggest I hang out there more, but why would I wish to when people
> treat me like this? it's extremely unpleasant.

Because it is easy to read an email wrong. IRC is more like talking and
talking gives a much more accurate picture of someone and misunderstanding
is harder :-)


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 bonivart at opencsw.org  Wed Jun  8 21:28:12 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 8 Jun 2011 21:28:12 +0200
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
Message-ID: <BANLkTikjOPdmaSLuQN_gC8bAOHgLs6DpiQ@mail.gmail.com>

On Wed, Jun 8, 2011 at 8:35 PM, Philip Brown <phil at bolthole.com> wrote:
> What I quoted from irc is a perfect example of the locked-in bias.
> My behaviour was exemplary in this issue: I responded quickly, and in
> a manner favorable to the person who approached me..

I don't think you're getting the context of what you quoted from IRC.
The thing is that you have always portrayed yourself as the only thing
guaranteeing quality from Blastwave/OpenCSW, without you checking
every package it would all go to hell. We have had many examples of
you stating that fact in one way or another, the latest just recently
regarding the upcoming vote.

Now peer review using checkpkg from GAR spotted an error in one of
your packages which at least I thought was somewhat amusing. I mean,
if you had used GAR yourself you would have known this, even if you
hadn't used GAR but tried the new upload feature it would have been
caught there but instead you totally missed it which just proves two
points - human inspection is inconsistent and you shouldn't inspect
your own packages.

To me, that's what those comments were about, that you yourself made
the case for us. You demonstrated why the current system is bad.

/peter

From phil at bolthole.com  Wed Jun  8 22:32:55 2011
From: phil at bolthole.com (Philip Brown)
Date: Wed, 8 Jun 2011 13:32:55 -0700
Subject: [csw-maintainers] Fwd: Kerberos support for SSHD on Solaris 10
In-Reply-To: <BANLkTim7avZncMHNnEgCZ09PG62sfuWr7w@mail.gmail.com>
References: <BANLkTin9+vpUBqJ+wQfriK9c9ZqQNwcboQ@mail.gmail.com>
	<CA0E9619.3CBCD%christopher.webber@ucr.edu>
	<BANLkTikj3RXFCqQO88fKUmuBR2Prtsbtew@mail.gmail.com>
	<BANLkTikextceAuJzDAtTG28OwjzaJVLhAg@mail.gmail.com>
	<BANLkTimDH=wFsDLdYm8j+Ekh1fxtnQGKXA@mail.gmail.com>
	<BANLkTim7avZncMHNnEgCZ09PG62sfuWr7w@mail.gmail.com>
Message-ID: <BANLkTik=7qt9miT_hL+X5J_OEymbeT8QhA@mail.gmail.com>

A note for the current, or any future, kerb maintainers.
This is a forward, from a local user group list that I'm on.

The user expected it to look in the solaris-documented location for
krb5.conf(4)

/etc/krb5/xxxxx

It would appear to check

/etc/krb5.conf:/opt/csw/etc/krb5.conf

however,   it should probably look in

/etc/opt/csw/krb5.conf:/etc/krb5/krb5.conf:/etc/krb5.conf:/opt/csw/etc/krb5.conf

(check all local locations, in that order, and then as a last-ditch
effort, check for a "global" one)



---------- Forwarded message ----------
From: Chris McDermott
Date: Wed, Jun 8, 2011 at 1:01 PM
Subject: Re: Kerberos support for SSHD on Solaris 10



Just to close the loop on this, I was able to use truss to figure out that
the csw openssh daemon was looking for the krb5.conf and krb5.keytab files
in a different location, and thus authentication was failing. ?I created
symlinks:

/etc/krb5.conf -> /etc/krb5/krb5.conf
/etc/krb5.keytab -> /etc/krb5/krb5.keytab

And everything works great now.

Thanks everyone!

Chris

From dam at opencsw.org  Wed Jun  8 22:37:39 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 8 Jun 2011 22:37:39 +0200
Subject: [csw-maintainers] Fwd: Kerberos support for SSHD on Solaris 10
In-Reply-To: <BANLkTik=7qt9miT_hL+X5J_OEymbeT8QhA@mail.gmail.com>
References: <BANLkTin9+vpUBqJ+wQfriK9c9ZqQNwcboQ@mail.gmail.com>
	<CA0E9619.3CBCD%christopher.webber@ucr.edu>
	<BANLkTikj3RXFCqQO88fKUmuBR2Prtsbtew@mail.gmail.com>
	<BANLkTikextceAuJzDAtTG28OwjzaJVLhAg@mail.gmail.com>
	<BANLkTimDH=wFsDLdYm8j+Ekh1fxtnQGKXA@mail.gmail.com>
	<BANLkTim7avZncMHNnEgCZ09PG62sfuWr7w@mail.gmail.com>
	<BANLkTik=7qt9miT_hL+X5J_OEymbeT8QhA@mail.gmail.com>
Message-ID: <ECBE03E9-ACD9-4330-B4E1-2CEC3119EFBA@opencsw.org>

Hi,

Am 08.06.2011 um 22:32 schrieb Philip Brown:
> A note for the current, or any future, kerb maintainers.

Added to http://wiki.opencsw.org/project-kerberos64

Best regards

  -- Dago


From bwalton at opencsw.org  Thu Jun  9 03:09:34 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 08 Jun 2011 21:09:34 -0400
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTikjOPdmaSLuQN_gC8bAOHgLs6DpiQ@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
	<BANLkTikjOPdmaSLuQN_gC8bAOHgLs6DpiQ@mail.gmail.com>
Message-ID: <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011:

Hi Peter,

> To me, that's what those comments were about, that you yourself made
> the case for us. You demonstrated why the current system is bad.

And importantly, Maciej demonstrated how the new system can work
well. :)

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


From dam at opencsw.org  Thu Jun  9 23:09:31 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 9 Jun 2011 23:09:31 +0200
Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request :
	Dovecot Version latest
References: <201106092059.p59KxerI024801@www.opencsw.org>
Message-ID: <105EB3FF-3D80-4419-A5B3-A4C932917DD8@opencsw.org>

Hi Jake,

any interest in also packaging dovecot 2?

Best regards

  -- Dago

Anfang der weitergeleiteten E-Mail:

> Von: pkgrequest at lists.opencsw.org
> Datum: 9. Juni 2011 22:59:40 MESZ
> An: pkgrequests at lists.opencsw.org
> Betreff: [csw-pkgrequests] New package request : Dovecot Version latest
> 
> Dear maintainers,
> 
> A new package request has been received from Gil Salazar (mailto:GILSALES at AG.ARIZONA.EDU). Dovecot Version latest is requested to be added to our catalog.
> 
> Here is the attached message : 
> 
> It would be a big help if someone could provide Dovecot 2 in this package. I have had troubles compiling all the necessary dependencies. Thank you very much in advance
> ~Gil
> _______________________________________________
> pkgrequests mailing list
> pkgrequests at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/pkgrequests

-- 
"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 jgoerzen at opencsw.org  Fri Jun 10 01:30:56 2011
From: jgoerzen at opencsw.org (Jake Goerzen)
Date: Thu, 09 Jun 2011 16:30:56 -0700
Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request :
 Dovecot Version latest
In-Reply-To: <105EB3FF-3D80-4419-A5B3-A4C932917DD8@opencsw.org>
References: <201106092059.p59KxerI024801@www.opencsw.org>
	<105EB3FF-3D80-4419-A5B3-A4C932917DD8@opencsw.org>
Message-ID: <4DF157B0.9040603@opencsw.org>

On 06/09/11 14:09, Dagobert Michelsen wrote:
> Hi Jake,
>
> any interest in also packaging dovecot 2?
>
> Best regards
>
>    -- Dago
>
> Anfang der weitergeleiteten E-Mail:
>
>> Von: pkgrequest at lists.opencsw.org
>> Datum: 9. Juni 2011 22:59:40 MESZ
>> An: pkgrequests at lists.opencsw.org
>> Betreff: [csw-pkgrequests] New package request : Dovecot Version latest
>>
>> Dear maintainers,
>>
>> A new package request has been received from Gil Salazar (mailto:GILSALES at AG.ARIZONA.EDU). Dovecot Version latest is requested to be added to our catalog.
>>
>> Here is the attached message :
>>
>> It would be a big help if someone could provide Dovecot 2 in this package. I have had troubles compiling all the necessary dependencies. Thank you very much in advance
>> ~Gil
>> _______________________________________________
>> pkgrequests mailing list
>> pkgrequests at lists.opencsw.org
>> https://lists.opencsw.org/mailman/listinfo/pkgrequests

Hi Dago,

   Yes, I was planning on it this month to get it done (upgrade to 
dovecot 2.0.13)  At the moment I'm trying to work out the _devel to _dev 
package naming change and update the dependencies before doing a major 
version jump and risk trying to do too much at once.

updated packages are now in experimental that I should be submitting 
soon.. then I'll get to work on dovecot 2

Thanks,
Jake

From dam at opencsw.org  Fri Jun 10 14:55:11 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 10 Jun 2011 14:55:11 +0200
Subject: [csw-maintainers] Fixing a date for the Summercamp 2011
Message-ID: <D766D043-69E4-47A7-97AF-48220C8894E0@opencsw.org>

Hi folks,

there is still some time left, but I already set up a doodle poll for the
technical Summercamp 2011 in Kiel, Germany:
  http://doodle.com/ewfzuze75afweueq


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 phil at bolthole.com  Sat Jun 11 06:22:17 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 10 Jun 2011 21:22:17 -0700
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
	<BANLkTikjOPdmaSLuQN_gC8bAOHgLs6DpiQ@mail.gmail.com>
	<1307581706-sup-7318@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTim9V3C3Br_WRxQ+bnmJdK8HivGcVA@mail.gmail.com>

On Wed, Jun 8, 2011 at 6:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011:
>
> Hi Peter,
>
>> To me, that's what those comments were about, that you yourself made
>> the case for us. You demonstrated why the current system is bad.
>
> And importantly, Maciej demonstrated how the new system can work
> well. :)


So, the new system is "Maciej personally checks everyone's packages"?
Great, I'm all for that! :)

Otherwise, I dont see how this demonstrates that in the new system,
all packages are going to be looked at by a second party.
That was the missing element here.

For the record.. I did see an error about "unneeded dependancy"
*before* I submitted it.
Unfortunately, I incorrectly judged it a false error, so did the
equivalent of a override in gar.
If I used gar, I would have done the same thing, so no, gar would not
have magically fixed this.

If anything, this incident shows *more strongly*, the benefit of
having at least 2 humans carefully look at a package before release.

The "new system" does not in any way ensure that.
I firmly believe that it will shepherd in the exact opposite: a time
when the majority of packages will be released with only one person
ever having looked at them.
This is a bad thing.

From rupert at opencsw.org  Sat Jun 11 06:45:43 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 11 Jun 2011 06:45:43 +0200
Subject: [csw-maintainers] oracle raises the operating system maintenance by
 a factor of 6, solaris will be history soon?
Message-ID: <BANLkTim5uv-2DFA+ucAGGZcHmoK9kqmDvg@mail.gmail.com>

there are rumors that oracle raises the maintenance price for solaris
by a factor of 6, is this true? do you feel some impact for the usage
of solaris by this or not yet?

rupert

From ellson at opencsw.org  Sat Jun 11 13:31:16 2011
From: ellson at opencsw.org (John Ellson)
Date: Sat, 11 Jun 2011 07:31:16 -0400
Subject: [csw-maintainers] pango -> graphviz -> imagemagick
Message-ID: <4DF35204.8050101@opencsw.org>

The process to get to a graphviz-2.28.0 release, as I understand it from
discussions with Dago, is as follows:

   1.  Wait for latest liblasi to show up on current9[sx] to resolve a
problem with a missing shared lib dependency that broke "dot -c" during
graphviz installs.

	Status:   CSWliblasi 1.1.0,REV=2011.06.09   installed

   2.  Wait on latest pango to show up on current9[sx] -- to be honest I
can't remember if this is essential, but Dago has made extensive build
fixes and may (I'm not sure) have repackaged the libs such that I need
changes in graphviz' Makefile.   Also the new pango is expected to be
64bit ready.

	Status:   not yet available.


When pango is available the remaining steps are:

   3. Build graphviz-2.28.0 as normal on current9[sx], but hold the
resulting packages in /home/experimental/graphviz/ until imagemagick
is also built.

   4. Install CSWgraphviz & CSWgraphvizdevel on unstable9[sx]

   5. Build imagemagic on unstable9[sx] and save resulting packages in
/home/experimental/graphviz/

   6. Release graphviz and imagemagick packages simultaneously.



So, bottom line,   where is pango?

John



From dam at opencsw.org  Sat Jun 11 15:04:10 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 11 Jun 2011 15:04:10 +0200
Subject: [csw-maintainers] pango -> graphviz -> imagemagick
In-Reply-To: <4DF35204.8050101@opencsw.org>
References: <4DF35204.8050101@opencsw.org>
Message-ID: <201757B1-6569-4EC8-B782-976932B72134@opencsw.org>

Hi John,

Am 11.06.2011 um 13:31 schrieb John Ellson:
> The process to get to a graphviz-2.28.0 release, as I understand it from
> discussions with Dago, is as follows:
> 
>   1.  Wait for latest liblasi to show up on current9[sx] to resolve a
> problem with a missing shared lib dependency that broke "dot -c" during
> graphviz installs.
> 
> 	Status:   CSWliblasi 1.1.0,REV=2011.06.09   installed

This problem in fact needs an updated liblasi -> pango -> cairo.
There is no need for a respin of graphviz as the sonames stay the same.

>   2.  Wait on latest pango to show up on current9[sx] -- to be honest I
> can't remember if this is essential, but Dago has made extensive build
> fixes and may (I'm not sure) have repackaged the libs such that I need
> changes in graphviz' Makefile.   Also the new pango is expected to be
> 64bit ready.
> 
> 	Status:   not yet available.

There is currently a discussion about package renaming, but this
does not affect the release of graphviz as explained above.
An updated pango will be released in the next few days.

> When pango is available the remaining steps are:
> 
>   3. Build graphviz-2.28.0 as normal on current9[sx], but hold the
> resulting packages in /home/experimental/graphviz/ until imagemagick
> is also built.

ImageMagick has already been rebuild and put in
  /home/experimental/graphviz
to be released _together in one batch_.

>   4. Install CSWgraphviz & CSWgraphvizdevel on unstable9[sx]
> 
>   5. Build imagemagic on unstable9[sx] and save resulting packages in
> /home/experimental/graphviz/
> 
>   6. Release graphviz and imagemagick packages simultaneously.

I don't think you need another rebuild of graphviz.

What is missing for a release is pstoedit by Peter Felecan, which is needed
because of the imagemagick rebuild. It is in progress right now. When
Peter has delivered this to /home/experimental/graphbiz you can
release all packages together immediately I would say.


Best regards

  -- Dago


From maciej at opencsw.org  Sun Jun 12 01:18:08 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 12 Jun 2011 00:18:08 +0100
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
Message-ID: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>

Hello fellow maintainers,

One of our guidelines has historically been to not provide binaries in
/opt/csw/bin named the same way as the ones in /usr/bin.  For
instance, bug 4533 has been filed because cups packages provide
/opt/csw/bin/lp which conflicts with /usr/bin/lp.

What are your thoughts on adding a check for binary name conflicts?

Maciej

[1] https://www.opencsw.org/mantis/view.php?id=4533

From bwalton at opencsw.org  Sun Jun 12 03:56:57 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 11 Jun 2011 21:56:57 -0400
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
Message-ID: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011:

Hi Maciej,

> One of our guidelines has historically been to not provide binaries
> in /opt/csw/bin named the same way as the ones in /usr/bin.  For
> instance, bug 4533 has been filed because cups packages provide
> /opt/csw/bin/lp which conflicts with /usr/bin/lp.

I'm not sure I'd consider this a problem.  If you're using cups, you
most likely want /opt/csw/bin/lp.  You don't want to have to learn new
commands for things that have traditional names (lp, lpstat, etc)
because cups is in play either.

> What are your thoughts on adding a check for binary name conflicts?

I don't see it as a conflict personally.  The filesystem provides a
separate name space and we're using it.  If you want the system lp,
either set the path accordingly or fully qualify it.  No point in
jumping through hoops for something like this, imo.

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


From bwalton at opencsw.org  Sun Jun 12 03:58:52 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 11 Jun 2011 21:58:52 -0400
Subject: [csw-maintainers] oracle raises the operating system
	maintenance by a factor of 6, solaris will be history soon?
In-Reply-To: <BANLkTim5uv-2DFA+ucAGGZcHmoK9kqmDvg@mail.gmail.com>
References: <BANLkTim5uv-2DFA+ucAGGZcHmoK9kqmDvg@mail.gmail.com>
Message-ID: <1307843833-sup-8328@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sat Jun 11 00:45:43 -0400 2011:

Hi Rupert,

> there are rumors that oracle raises the maintenance price for
> solaris by a factor of 6, is this true? do you feel some impact for
> the usage of solaris by this or not yet?

I hadn't heard this, but even without altering current pricing,
they're making solaris too expensive for us.  Our campus license is
being extended at the current price so we're registering systems.
After a cut-off date, no new systems will be eligible for this and
we'll pay 'market' rates which for us will be a deal breaker.

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


From phil at bolthole.com  Sun Jun 12 05:11:04 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 11 Jun 2011 20:11:04 -0700
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimNcrNiwcC7xJ5uyULk777BAtD7AA@mail.gmail.com>

On Sat, Jun 11, 2011 at 6:56 PM, Ben Walton <bwalton at opencsw.org> wrote:
>
> I don't see it as a conflict personally. ?The filesystem provides a
> separate name space and we're using it. ?If you want the system lp,
> either set the path accordingly or fully qualify it. ?No point in
> jumping through hoops for something like this, imo.

Not everyone gets to dictate to their users, "Your path WILL be this,
and you dont get to change it".
Having to pre-screen support calls with, "and what is your $PATH set
to?", gets unpleasant.
And its all very well to say, "if they change their PATH, they're
unsupported", but those people still CALL.
So you first have to remember to figure out, "oh, maybe they're using
[this path], not [path we expect], and that changes everything".

It's nicer for support people, to have a consistently working
environment reguardless of which order someone's $PATH is set to.

From bonivart at opencsw.org  Sun Jun 12 15:24:00 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 12 Jun 2011 15:24:00 +0200
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>

On Sun, Jun 12, 2011 at 3:56 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011:
>
> Hi Maciej,
>
>> One of our guidelines has historically been to not provide binaries
>> in /opt/csw/bin named the same way as the ones in /usr/bin. ?For
>> instance, bug 4533 has been filed because cups packages provide
>> /opt/csw/bin/lp which conflicts with /usr/bin/lp.
>
> I'm not sure I'd consider this a problem. ?If you're using cups, you
> most likely want /opt/csw/bin/lp. ?You don't want to have to learn new
> commands for things that have traditional names (lp, lpstat, etc)
> because cups is in play either.
>
>> What are your thoughts on adding a check for binary name conflicts?
>
> I don't see it as a conflict personally. ?The filesystem provides a
> separate name space and we're using it. ?If you want the system lp,
> either set the path accordingly or fully qualify it. ?No point in
> jumping through hoops for something like this, imo.

I agree with Ben here.

/peter

From maciej at opencsw.org  Sun Jun 12 17:45:02 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 12 Jun 2011 16:45:02 +0100
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTim9V3C3Br_WRxQ+bnmJdK8HivGcVA@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
	<BANLkTikjOPdmaSLuQN_gC8bAOHgLs6DpiQ@mail.gmail.com>
	<1307581706-sup-7318@pinkfloyd.chass.utoronto.ca>
	<BANLkTim9V3C3Br_WRxQ+bnmJdK8HivGcVA@mail.gmail.com>
Message-ID: <BANLkTim=+AzzTXaEFLcs-PMdCqBQsfX_5Q@mail.gmail.com>

2011/6/11 Philip Brown <phil at bolthole.com>:
> For the record.. I did see an error about "unneeded dependancy"
> *before* I submitted it.
> Unfortunately, I incorrectly judged it a false error, so did the
> equivalent of a override in gar.
> If I used gar, I would have done the same thing, (...)

Not necessarily.  Here's what would have probably happened if you used GAR:

A surplus-dependency [1] error would be thrown.  As far as shared
library analysis goes, checkpkg is almost never wrong about them.
Youd have confidence in the results you're looking at, and you would
not dismiss the error message.  If you wanted to see more details, you
would go to the buildfarm database, and look at the package
metadata[2]. You would look at the NEEDED section of your binary, and
see that openssl is not there. At this point you would understand that
the dependency is not necessary.

Maciej

[1] http://wiki.opencsw.org/checkpkg-error-tags#surplus-dependency
[2] http://buildfarm.opencsw.org/pkgdb/srv4/ecb59b20f4e4226a83a67b1bfe9f8379/

From phil at bolthole.com  Sun Jun 12 19:52:58 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 12 Jun 2011 10:52:58 -0700
Subject: [csw-maintainers] An end to IRC back-biting ?
In-Reply-To: <BANLkTim=+AzzTXaEFLcs-PMdCqBQsfX_5Q@mail.gmail.com>
References: <BANLkTi=myCNSpW7mo2Ha_RKNrLB4E7-Ktg@mail.gmail.com>
	<1307493218-sup-8821@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=X_oLo6KgfnjneZWAb+d-xpNbfxw@mail.gmail.com>
	<BANLkTikjOPdmaSLuQN_gC8bAOHgLs6DpiQ@mail.gmail.com>
	<1307581706-sup-7318@pinkfloyd.chass.utoronto.ca>
	<BANLkTim9V3C3Br_WRxQ+bnmJdK8HivGcVA@mail.gmail.com>
	<BANLkTim=+AzzTXaEFLcs-PMdCqBQsfX_5Q@mail.gmail.com>
Message-ID: <BANLkTinf=JDbtkymJM0OhFph0rCJM4nCNw@mail.gmail.com>

2011/6/12 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/6/11 Philip Brown <phil at bolthole.com>:
>> For the record.. I did see an error about "unneeded dependancy"
>> *before* I submitted it.
>> Unfortunately, I incorrectly judged it a false error, so did the
>> equivalent of a override in gar.
>> If I used gar, I would have done the same thing, (...)
>
> Not necessarily. ?Here's what would have probably happened if you used GAR:
>
> A surplus-dependency [1] error would be thrown. ?As far as shared
> library analysis goes, checkpkg is almost never wrong about them.
>...


Maciej, the python version of checkpkg and the ksh version, use
basically the same method of checking.
They are exactly as reliable as each other.

So no, nothing would have changed if I had used gar checkpkg.

Now how about addressing the other part of my email, reguarding
ensuring that at least two humans examine a package?
Feel free to change the subject line to something more appropriate,
for wider discussion.

From maciej at opencsw.org  Sun Jun 12 23:02:41 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 12 Jun 2011 22:02:41 +0100
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
	<BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>
Message-ID: <BANLkTikFTKAUhcsn0TV+S8T8c_iRdpuOeQ@mail.gmail.com>

2011/6/12 Peter Bonivart <bonivart at opencsw.org>:
> On Sun, Jun 12, 2011 at 3:56 AM, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011:
>>
>> Hi Maciej,
>>
>>> One of our guidelines has historically been to not provide binaries
>>> in /opt/csw/bin named the same way as the ones in /usr/bin. ?For
>>> instance, bug 4533 has been filed because cups packages provide
>>> /opt/csw/bin/lp which conflicts with /usr/bin/lp.
>>
>> I'm not sure I'd consider this a problem. ?If you're using cups, you
>> most likely want /opt/csw/bin/lp. ?You don't want to have to learn new
>> commands for things that have traditional names (lp, lpstat, etc)
>> because cups is in play either.
>>
>>> What are your thoughts on adding a check for binary name conflicts?
>>
>> I don't see it as a conflict personally. ?The filesystem provides a
>> separate name space and we're using it. ?If you want the system lp,
>> either set the path accordingly or fully qualify it. ?No point in
>> jumping through hoops for something like this, imo.
>
> I agree with Ben here.

My inclination was also that it is alright to provide binaries with
the same names.

In my case, there was a number of scripts written by developers, who
expected there to be a 'lp' command.  If we provided binaries with a
different name in /opt/csw/bin, then we would also need to make
symlinks to them from elsewhere, the same way symlink in /opt/csw/gnu
are provided.  I would also need to add /opt/csw/gnu (or equivalent)
to $PATH.  At the end of the day, it would be not much different from
just providing /opt/csw/bin/lp, just more complex.

In the case of CUPS, I have removed the stock Solaris printing
packages, so /usr/bin/lp and others were removed from the system.

Any more opinions from other maintainers?

Maciej

From phil at bolthole.com  Mon Jun 13 00:11:42 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 12 Jun 2011 15:11:42 -0700
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <BANLkTikFTKAUhcsn0TV+S8T8c_iRdpuOeQ@mail.gmail.com>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
	<BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>
	<BANLkTikFTKAUhcsn0TV+S8T8c_iRdpuOeQ@mail.gmail.com>
Message-ID: <BANLkTikUFoRwT9zBWghbHLxXFQOmZhAkpQ@mail.gmail.com>

2011/6/12 Maciej Blizi?ski <maciej at opencsw.org>:
> ...
> In the case of CUPS, I have removed the stock Solaris printing
> packages, so /usr/bin/lp and others were removed from the system.


waitaminit... do you mean that in your cups package, you *force*
removal of the solaris printing packages?
without giving the user/admin a choice?
Didnt we have a policy discussion about this sort of thing a while back?
I dont remember the exact details, but I thought the general result
was that we should try to give the user a choice in the matter.

From bwalton at opencsw.org  Mon Jun 13 02:17:20 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 12 Jun 2011 20:17:20 -0400
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <BANLkTikUFoRwT9zBWghbHLxXFQOmZhAkpQ@mail.gmail.com>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
	<BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>
	<BANLkTikFTKAUhcsn0TV+S8T8c_iRdpuOeQ@mail.gmail.com>
	<BANLkTikUFoRwT9zBWghbHLxXFQOmZhAkpQ@mail.gmail.com>
Message-ID: <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sun Jun 12 18:11:42 -0400 2011:

> waitaminit... do you mean that in your cups package, you *force*
> removal of the solaris printing packages?
> without giving the user/admin a choice?

I read that as 'on my systems, I...'

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


From phil at bolthole.com  Mon Jun 13 02:37:53 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 12 Jun 2011 17:37:53 -0700
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
	<BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>
	<BANLkTikFTKAUhcsn0TV+S8T8c_iRdpuOeQ@mail.gmail.com>
	<BANLkTikUFoRwT9zBWghbHLxXFQOmZhAkpQ@mail.gmail.com>
	<1307924216-sup-6771@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinhQLzhTuH_7ms+8eQsGNkq4m5Npg@mail.gmail.com>

On Sun, Jun 12, 2011 at 5:17 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Sun Jun 12 18:11:42 -0400 2011:
>
>> waitaminit... do you mean that in your cups package, you *force*
>> removal of the solaris printing packages?
>> without giving the user/admin a choice?
>
> I read that as 'on my systems, I...'

I understood that as an additional possibility.  But even if that is
so, accomodations need to be made for those who dont do that.

Contrariwise, if "we" are going to take the attitude of, "we wont make
you remove the solaris ones, but things wont really work properly if
you dont", then we probably should have a "remove sol lp, or quit
installation" catch in the package, I would think.

From maciej at opencsw.org  Mon Jun 13 07:35:31 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 13 Jun 2011 06:35:31 +0100
Subject: [csw-maintainers] csw-update-pkg does more checks????
In-Reply-To: <4DEEE614.9030405@opencsw.org>
References: <4DECA955.9020408@opencsw.org>
	<8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org>
	<4DECD79B.90601@opencsw.org>
	<5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org>
	<4DECE231.7010804@opencsw.org>
	<110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org>
	<4DED5B52.6070302@opencsw.org>
	<4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org>
	<C3BDAA7D-5294-4063-84D6-1F9A6DF7652D@opencsw.org>
	<4DEEE137.6040304@opencsw.org> <4DEEE3D6.8060700@opencsw.org>
	<BANLkTikhw-Z4XVSxrMSo5ZEQiiNQh-OzUExcPE7qvMXcrZBQtg@mail.gmail.com>
	<4DEEE614.9030405@opencsw.org>
Message-ID: <BANLkTi=1fKDfHLzSyBn5YOPXYWe05vf-6w@mail.gmail.com>

2011/6/8 John Ellson <ellson at opencsw.org>:
> On 06/07/2011 10:54 PM, Maciej Blizi?ski wrote:
>>
>> I suspect that a non-package file was passed as an argument.
>>
>> What was the exact file list? (i.e. output of echo newpkgs/liblasi*)
>
> Ah! You're so correct. I had a directory in there named liblasi.

I added a new check for file names[1]; files need to end with either
.pkg.gz or .pkg.  If they do not, csw-upload-pkg will additionally
display a 'bad-filename' error message, with the bad filename. In this
case it would show something like:

bad-filename filename=liblasi

Maciej

[1] http://sourceforge.net/apps/trac/gar/changeset/14796

From maciej at opencsw.org  Mon Jun 13 12:05:41 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 13 Jun 2011 11:05:41 +0100
Subject: [csw-maintainers] Code and package reviews
Message-ID: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>

2011/6/11 Philip Brown <phil at bolthole.com>:
> On Wed, Jun 8, 2011 at 6:09 PM, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011:
>>
>> Hi Peter,
>>
>>> To me, that's what those comments were about, that you yourself made
>>> the case for us. You demonstrated why the current system is bad.
>>
>> And importantly, Maciej demonstrated how the new system can work
>> well. :)
> (...)
> If anything, this incident shows *more strongly*, the benefit of
> having at least 2 humans carefully look at a package before release.
>
> The "new system" does not in any way ensure that.
> I firmly believe that it will shepherd in the exact opposite: a time
> when the majority of packages will be released with only one person
> ever having looked at them.
> This is a bad thing.
>
> Now how about addressing the other part of my email, reguarding
> ensuring that at least two humans examine a package?

I expect that your position can be described as "the release manager
position ensures that packages are always examined".  While on some
level it is true, it still depends on there being a person who
believes that examining packages is important, and who is willing to
spend their time on it. Therefore, just saying "a human must examine
all packages" doesn't solve the problem. If there's no one around
willing to be involved, any written rules are in vein.

Our aim is to build a culture in which peer review is one of the key
elements.  There needs to be an environment which encourages peer
reviews and makes them easy.

The first place is the devel mailing list.  If you examine its
archives, you'll see a number of discussions[1].  Some issues are very
easy to spot there. For example, if there's a code commit adding a lot
of overrides, it's a good indicator that the maintainer is facing
problems and could use some help.

The second place is the buildfarm database, which allows browsing
package metadata[2]. It's the easiest way to inspect certain features
of packages such as lists of binaries, their properties, required
shared libraries, etc.

Discussions usually take place on the devel mailing list, to avoid
overwhelming the maintainers list.

There are also the atom feeds[3], showing package updates.  All the
interested parties (not necessarily just maintainers) can monitor
feeds in a reader, and react to updates of packages that interest
them.

It is important that the senior members of the project actively
participate in code and package reviews, serving as a good example to
more junior members.

While this strategy does not claim to "ensure that X number of humans
will always do Y", it addresses the underlying issue of getting people
involved in the release process and quality assurance through peer
review.

Maciej

[1] http://lists.opencsw.org/pipermail/devel/2011-June/thread.html
[2] http://buildfarm.opencsw.org/pkgdb/
[3] Testing location: http://buildfarm.opencsw.org/~bwalton/

From ellson at opencsw.org  Mon Jun 13 13:49:34 2011
From: ellson at opencsw.org (John Ellson)
Date: Mon, 13 Jun 2011 07:49:34 -0400
Subject: [csw-maintainers] pango -> graphviz -> imagemagick
In-Reply-To: <201757B1-6569-4EC8-B782-976932B72134@opencsw.org>
References: <4DF35204.8050101@opencsw.org>
	<201757B1-6569-4EC8-B782-976932B72134@opencsw.org>
Message-ID: <4DF5F94E.8040408@opencsw.org>

On 06/11/2011 09:04 AM, Dagobert Michelsen wrote:

>>   6. Release graphviz and imagemagick packages simultaneously.
> 
> I don't think you need another rebuild of graphviz.
> 
> What is missing for a release is pstoedit by Peter Felecan, which is needed
> because of the imagemagick rebuild. It is in progress right now. When
> Peter has delivered this to /home/experimental/graphbiz you can
> release all packages together immediately I would say.


Dago,

How is this going?

John

From dam at opencsw.org  Mon Jun 13 14:35:00 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 13 Jun 2011 14:35:00 +0200
Subject: [csw-maintainers] pango -> graphviz -> imagemagick
In-Reply-To: <4DF5F94E.8040408@opencsw.org>
References: <4DF35204.8050101@opencsw.org>
	<201757B1-6569-4EC8-B782-976932B72134@opencsw.org>
	<4DF5F94E.8040408@opencsw.org>
Message-ID: <6029000D-B3DD-43A2-9557-80FDFD10C3B8@opencsw.org>

Hi John,

Von meinem iPad gesendet

Am 13.06.2011 um 13:49 schrieb John Ellson <ellson at opencsw.org>:

> On 06/11/2011 09:04 AM, Dagobert Michelsen wrote:
> 
>>>  6. Release graphviz and imagemagick packages simultaneously.
>> 
>> I don't think you need another rebuild of graphviz.
>> 
>> What is missing for a release is pstoedit by Peter Felecan, which is needed
>> because of the imagemagick rebuild. It is in progress right now. When
>> Peter has delivered this to /home/experimental/graphbiz you can
>> release all packages together immediately I would say.
> 
> 
> Dago,
> 
> How is this going?

Do you mean how it works or how it is coming along? I hope Peter is delivering the updated package in the next few days, then you can use csw-upload-pkg and submitpkg to deliver all packages in one batch. This is important, as there are library interdependencies from Graphviz to Imagemagick to pstoedit.


Best regards

  -- Dago

From phil at bolthole.com  Mon Jun 13 16:09:24 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 13 Jun 2011 07:09:24 -0700
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
Message-ID: <BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>

2011/6/13 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/6/11 Philip Brown <phil at bolthole.com>:
>
>> (...)
>> If anything, this incident shows *more strongly*, the benefit of
>> having at least 2 humans carefully look at a package before release.
>>
>> The "new system" does not in any way ensure that.
>
> I expect that your position can be described as "the release manager
> position ensures that packages are always examined".

yes.


> Our aim is to build a culture in which peer review is one of the key
> elements. ?There needs to be an environment which encourages peer
> reviews and makes them easy.
>....

you took the time to write a lot of things in your email. Thank you.
However,  while the things you wrote were "good", and "true"... they
still did not concretely address the issue :(
I think the rest of what you wrote, can be summed up, with a minor
insert, as follows:

> It is important that the senior members of the project actively
> participate in code and package reviews, serving as a good example to
> more junior members.
> [ So we **hope** that people will review packages]

This is exactly the problem that I see.
There have been a few people complaining about "lack of consistency"
with the current release process.
But how is a release strategy built around "hope", more consistent????



> While this strategy does not claim to "ensure that X number of humans
> will always do Y", it addresses the underlying issue of getting people
> involved in the release process and quality assurance through peer
> review.

It does not seem like it _adequately_ addresses the issue.
Providing people an optional mechanism to improve quality, does not
mean they will use it. "consistently".
Providing people an optional mechanism to "get involved", does not
mean they *will* get involved.

Some people.. including *you* Maciej... keep pressing the claims that
everything should be automated, for "consistency".
So why are you not automating a 2nd party validation check?

From pfelecan at acm.org  Mon Jun 13 18:20:50 2011
From: pfelecan at acm.org (Peter FELECAN)
Date: Mon, 13 Jun 2011 18:20:50 +0200
Subject: [csw-maintainers] pango -> graphviz -> imagemagick
In-Reply-To: <6029000D-B3DD-43A2-9557-80FDFD10C3B8@opencsw.org> (Dagobert
	Michelsen's message of "Mon, 13 Jun 2011 14:35:00 +0200")
References: <4DF35204.8050101@opencsw.org>
	<201757B1-6569-4EC8-B782-976932B72134@opencsw.org>
	<4DF5F94E.8040408@opencsw.org>
	<6029000D-B3DD-43A2-9557-80FDFD10C3B8@opencsw.org>
Message-ID: <x639jdhfdp.fsf@acm.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi John,
>
> Von meinem iPad gesendet
>
> Am 13.06.2011 um 13:49 schrieb John Ellson <ellson at opencsw.org>:
>
>> On 06/11/2011 09:04 AM, Dagobert Michelsen wrote:
>> 
>>>>  6. Release graphviz and imagemagick packages simultaneously.
>>> 
>>> I don't think you need another rebuild of graphviz.
>>> 
>>> What is missing for a release is pstoedit by Peter Felecan, which is needed
>>> because of the imagemagick rebuild. It is in progress right now. When
>>> Peter has delivered this to /home/experimental/graphbiz you can
>>> release all packages together immediately I would say.
>> 
>> 
>> Dago,
>> 
>> How is this going?
>
> Do you mean how it works or how it is coming along? I hope Peter is
> delivering the updated package in the next few days, then you can use
> csw-upload-pkg and submitpkg to deliver all packages in one
> batch. This is important, as there are library interdependencies from
> Graphviz to Imagemagick to pstoedit.

Done.
-- 
Peter FELECAN
mailto:pfelecan at acm.org

From bwalton at opencsw.org  Fri Jun 17 04:20:35 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 16 Jun 2011 22:20:35 -0400
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
	<1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>
	<1307324723-sup-7673@pinkfloyd.chass.utoronto.ca>
Message-ID: <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Sun Jun 05 21:47:43 -0400 2011:

> No, the request is fine and I don't mind waiting a week as you
> suggest.  I'm just saying that we shouldn't let orphaned packages[1]
> impede work on things that people do actively care about.

Ok, so anybody that wants to update nspr properly is now able to do so
and mark it 'I' with CSWmozilla.  When it's released, CSWmozilla
should be dropped from the catalog.

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


From maciej at opencsw.org  Fri Jun 17 12:00:08 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Fri, 17 Jun 2011 11:00:08 +0100
Subject: [csw-maintainers] New check: depending alternatives
Message-ID: <BANLkTimfFKRD+-2G53mv96EdqLnMW17CAA@mail.gmail.com>

Hello maintainers,

I've just added[1] a new check.  If a package contains a file of the
cswalternatives class, checkpkg will expect a dependency on
CSWalternatives.  For those who are interested in how the code works,
the dependency is declared via the NeedFile() function.  Inside the
check, it is declared that our package under check needs the
/opt/csw/sbin/alternatives file.  There is no need to specifically
list CSWalternatives.  Checkpkg resolves the
/opt/csw/sbin/alternatives path to the package that contains it.

Maciej

[1] http://sourceforge.net/apps/trac/gar/changeset/14834

From bwalton at opencsw.org  Sat Jun 18 15:52:55 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 18 Jun 2011 09:52:55 -0400
Subject: [csw-maintainers] proposal
Message-ID: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>


Hi All,

I think we've waited long enough on this.  Here is the proposal that
myself and others are setting forward regarding the changed release
process: http://wiki.opencsw.org/automated-release-proposal

If you like it, feel free to add your name at the bottom.  It's not an
exclusive thing.  The names there now are people that were involved in
the discussions at winter camp and then later as this has progressed.
I'm aware of one more person that will be signing it but there is no
reason to delay this further, I don't think.

Comments welcome.  Once this has been digested, Phil will write the
cons side of the ballot and I'll do the pros.

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


From phil at bolthole.com  Sat Jun 18 16:16:48 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 18 Jun 2011 07:16:48 -0700
Subject: [csw-maintainers] proposal
In-Reply-To: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>

On Sat, Jun 18, 2011 at 6:52 AM, Ben Walton <bwalton at opencsw.org> wrote:
>
> Hi All,
>
> I think we've waited long enough on this. ?Here is the proposal that
> myself and others are setting forward regarding the changed release
> process: http://wiki.opencsw.org/automated-release-proposal
>
> If you like it, feel free to add your name at the bottom.

huh? What's the point of that? we're going to vote on it, why are you
telling people to do that, AND vote?
It seems like nothing more than a "lobbying" effort to try to bias
people towards it, rather than just having a clean vote.


> Comments welcome. ?Once this has been digested, Phil will write the
> cons side of the ballot and I'll do the pros.

Ben, I believe that, weeks ago now, you said you would write up
something on what procedures opencsw would have to amend proposals
prior to vote.
You have not done that.
I would like to put forward an amendment to the proposal. Are you
going to disallow any kind of formal *on-list* amendment mechanism?

From rupert at opencsw.org  Sat Jun 18 17:21:55 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 18 Jun 2011 17:21:55 +0200
Subject: [csw-maintainers] proposal
In-Reply-To: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimwvpA9N5SMveaxQQBJFiWaC3jQkA@mail.gmail.com>

how much benefit does this give that it is enabled like this? it looks very
"spammy" to me and takes up half of my laptop screen ...


Automated Release Proposal

   - Agile Project
Management<http://googleads.g.doubleclick.net/aclk?sa=L&ai=BHX26VsH8Te_JHs-4sgb-w9n8BZSvod0BhIva1RLAjbcB8PZlEAEYASD7gYQKKAQ4AFCgs9i0-_____8BYPWtsYH8A7IBEHdpa2kub3BlbmNzdy5vcme6AQozMDB4MjUwX2FzyAEB2gEyaHR0cDovL3dpa2kub3BlbmNzdy5vcmcvYXV0b21hdGVkLXJlbGVhc2UtcHJvcG9zYWyAAgGpAlTWulwHx7M-qAMByAMX6AMf6AMg6APgBfUDAAAAxA&num=1&sig=AGiWqtyfpwsyGXaNE2PRNRfzN9cXjOjDQQ&client=ca-pub-8290351116363959&adurl=http://www.cougarpartners.com&nm=13>
   Agility and flexibility even in case of disruptive situations
   www.cougarpartners.com
   - Process control<http://googleads.g.doubleclick.net/aclk?sa=L&ai=B_-jrVsH8Te_JHs-4sgb-w9n8BbOI1NIB6_DgwirAjbcBgIgnEAIYAiD7gYQKKAQ4AFD2xLSc_f____8BYPWtsYH8A7IBEHdpa2kub3BlbmNzdy5vcme6AQozMDB4MjUwX2FzyAEB2gEyaHR0cDovL3dpa2kub3BlbmNzdy5vcmcvYXV0b21hdGVkLXJlbGVhc2UtcHJvcG9zYWypAjlLKeU-BLg-qAMByAMX6AMf6AMg6APgBfUDAAAAxA&num=2&sig=AGiWqtxIDFRmuk1tvuNa28kFF3e-A3i2Mw&client=ca-pub-8290351116363959&adurl=http://forest.savcor.com/solutions/wedge/&nm=9>
   World's leading provider on process diagnostic technology:Savcor Forest
   www.savcor.com
   - WS_FTP Server Test
frei<http://googleads.g.doubleclick.net/aclk?sa=l&ai=BOba1VsH8Te_JHs-4sgb-w9n8BdGaw98Bqe7m3RzAjbcBgIl6EAMYAyD7gYQKKAQ4AFCmyONBYPWtsYH8A6ABidrY7QOyARB3aWtpLm9wZW5jc3cub3JnugEKMzAweDI1MF9hc8gBAdoBMmh0dHA6Ly93aWtpLm9wZW5jc3cub3JnL2F1dG9tYXRlZC1yZWxlYXNlLXByb3Bvc2FsgAIBqAMByAMX6AMf6AMg6APgBfUDAAAAxA&num=3&sig=AGiWqtwJC4uFzLdznq2-NYAAh-yKX9V_Ng&client=ca-pub-8290351116363959&adurl=http://www.ipswitchft.com/Landing/Microsites/WsFtpServer75/IndexDE.aspx%3Fk_id%3DgoogleserverDElanding%26pi_ad_id%3D7611211153&nm=11>
   leichter, sicherer File Transfer + flexible Benutzerverwaltung
   IpswitchFT.com/FTPServer
   - Software Testing
Event<http://googleads.g.doubleclick.net/aclk?sa=l&ai=BWx6PVsH8Te_JHs-4sgb-w9n8Bei64asB9JSYqx7AjbcBkItAEAQYBCD7gYQKKAQ4AFDP6rukAWD1rbGB_AOgAaOamv8DsgEQd2lraS5vcGVuY3N3Lm9yZ7oBCjMwMHgyNTBfYXPIAQHaATJodHRwOi8vd2lraS5vcGVuY3N3Lm9yZy9hdXRvbWF0ZWQtcmVsZWFzZS1wcm9wb3NhbKkCVNa6XAfHsz6oAwHIAxfoAx_oAyDoA-AF9QMAAADE&num=4&sig=AGiWqtzHHlQbLWCVUOFVZ75VvBZRQYmALg&client=ca-pub-8290351116363959&adurl=http://www.bbv.ch/de/unternehmen/events.html&nm=18>
   Jetzt anmelden zum Q-Event `11 der bbv Software Services AG in Luzern
   www.bbv.ch



rupert.


On Sat, Jun 18, 2011 at 15:52, Ben Walton <bwalton at opencsw.org> wrote:

>
> Hi All,
>
> I think we've waited long enough on this.  Here is the proposal that
> myself and others are setting forward regarding the changed release
> process: http://wiki.opencsw.org/automated-release-proposal
>
> If you like it, feel free to add your name at the bottom.  It's not an
> exclusive thing.  The names there now are people that were involved in
> the discussions at winter camp and then later as this has progressed.
> I'm aware of one more person that will be signing it but there is no
> reason to delay this further, I don't think.
>
> Comments welcome.  Once this has been digested, Phil will write the
> cons side of the ballot and I'll do the pros.
>
> 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. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110618/d183daeb/attachment-0001.html>

From bwalton at opencsw.org  Sat Jun 18 20:51:06 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 18 Jun 2011 14:51:06 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
Message-ID: <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sat Jun 18 10:16:48 -0400 2011:

> huh? What's the point of that? we're going to vote on it, why are you
> telling people to do that, AND vote?

Well, if enough members support it before the vote happens, there is
no need for a vote as it will have passed without the formality of
ballot bin.

> It seems like nothing more than a "lobbying" effort to try to bias
> people towards it, rather than just having a clean vote.

The original names can be considered authorship.

Allowing people to sign on now can possibly prevent a vote at all.
The supporters and the one that has signaled intent make up just shy
of 50% of the active members.  If 4 more people support the proposal,
there is no need to vote and we save time.

> > Comments welcome. ?Once this has been digested, Phil will write the
> > cons side of the ballot and I'll do the pros.
> 
> Ben, I believe that, weeks ago now, you said you would write up
> something on what procedures opencsw would have to amend proposals
> prior to vote.  You have not done that.

Sorry, been busy.  It is on my todo list and maybe I'll work on it
this weekend if I find the time.

> I would like to put forward an amendment to the proposal. Are you
> going to disallow any kind of formal *on-list* amendment mechanism?

Please provide your amendment for public review and get the support of
every currently signed member.  Modifications without the support of
everyone that has already signed off on the current form might
invalidate their support, thus 100% approval for the change.  I don't
think that's unreasonable when you're talking about 33% of the
membership.

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


From bwalton at opencsw.org  Sat Jun 18 20:51:56 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 18 Jun 2011 14:51:56 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTimwvpA9N5SMveaxQQBJFiWaC3jQkA@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTimwvpA9N5SMveaxQQBJFiWaC3jQkA@mail.gmail.com>
Message-ID: <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sat Jun 18 11:21:55 -0400 2011:

Hi Rupert,

> how much benefit does this give that it is enabled like this? it
> looks very "spammy" to me and takes up half of my laptop screen ...

Sorry about this.  Unfortunately, there isn't much we can do about
it.  If you have a wikidot account (Peter Bonivart can help you with
that), you don't see the ads.  I forget that they're even there until
things like this happen.

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


From rupert at opencsw.org  Sat Jun 18 22:15:26 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 18 Jun 2011 22:15:26 +0200
Subject: [csw-maintainers] proposal
In-Reply-To: <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTimwvpA9N5SMveaxQQBJFiWaC3jQkA@mail.gmail.com>
	<1308423068-sup-8691@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinMizMt76qEOT+jT8yXD0tCEw9zzQ@mail.gmail.com>

On Sat, Jun 18, 2011 at 20:51, Ben Walton <bwalton at opencsw.org> wrote:

> Excerpts from rupert THURNER's message of Sat Jun 18 11:21:55 -0400 2011:
>
> Hi Rupert,
>
> > how much benefit does this give that it is enabled like this? it
> > looks very "spammy" to me and takes up half of my laptop screen ...
>
> Sorry about this.  Unfortunately, there isn't much we can do about
> it.  If you have a wikidot account (Peter Bonivart can help you with
> that), you don't see the ads.  I forget that they're even there until
> things like this happen.
>

this is the first thing people see if they come to the opencsw wiki ... and
i am really wondering if opencsw or the server operator has some financial
benefit? if not, i would strongly advocate to switch this off. if its built
into the wiki software, then switch to a reasonable wiki, like
http://moinmo.in or mediawiki, or redmine, or whatever.

rupert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110618/20cc7837/attachment.html>

From phil at bolthole.com  Sat Jun 18 23:22:31 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 18 Jun 2011 14:22:31 -0700
Subject: [csw-maintainers] proposal
In-Reply-To: <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>

On Sat, Jun 18, 2011 at 11:51 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Sat Jun 18 10:16:48 -0400 2011:
>
>> huh? What's the point of that? we're going to vote on it, why are you
>> telling people to do that, AND vote?
>
> Well, if enough members support it before the vote happens, there is
> no need for a vote as it will have passed without the formality of
> ballot bin.

When member(s) of the board, attempt to completely change the way
opencsw operates,
and they are at the same time *specfiically* attempting to avoid a
formal vote while doing so, there is something extremely wrong.

Is no-one else concerned about this? ???

>> I would like to put forward an amendment to the proposal. Are you
>> going to disallow any kind of formal *on-list* amendment mechanism?
>
> Please provide your amendment for public review and get the support of
> every currently signed member. ?Modifications without the support of
> everyone that has already signed off on the current form might
> invalidate their support, thus 100% approval for the change.

This is a ludicrous methodology. But now it seems clear your real
reason for getting people to "sign" it. You making the barrier to
suggest changes impossible to overcome.

This is abuse of power, yet again.

To people who arent saying anything about this because they agree
about the direction it is headed... consider that the same political
railroading will also be used in the future, for issues that you do
NOT agree with.
Speak up now if that thought bothers you.

If the majority of voting members votes a particular way, I'm not
going to fight it. What concerns me the most, is that if the board is
so convinced this is "the will of the majority", then why are they
fighting so hard to allow the majority to have a clean vote, instead
of these underhanded tactics?

From bwalton at opencsw.org  Sun Jun 19 04:20:14 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 18 Jun 2011 22:20:14 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTinMizMt76qEOT+jT8yXD0tCEw9zzQ@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTimwvpA9N5SMveaxQQBJFiWaC3jQkA@mail.gmail.com>
	<1308423068-sup-8691@pinkfloyd.chass.utoronto.ca>
	<BANLkTinMizMt76qEOT+jT8yXD0tCEw9zzQ@mail.gmail.com>
Message-ID: <1308449688-sup-9855@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sat Jun 18 16:15:26 -0400 2011:

Hi Rupert,

> this is the first thing people see if they come to the opencsw wiki
> ... and i am really wondering if opencsw or the server operator has
> some financial benefit? if not, i would strongly advocate to switch
> this off. if its built into the wiki software, then switch to a
> reasonable wiki, like http://moinmo.in or mediawiki, or redmine, or
> whatever.

Well, I don't know all of the original considerations, but wikidot has
provided a good service, I think.  We're on the free plan[1] where we
get no control of the ads.

We could host our own, I guess.  I'm not sure why we didn't, but I
suspect it's partially because nobody wanted to tend one of the wiki
packages which see a fairly constant update requirement.  I don't have
much against the ads from wikidot myself as they need to make money
and they're giving us a free service.  (I barely notice ads on pages
these days unless they're big, singing, dancing, spinning and
bouncing.)

Does an adblock plugin squash this?

Thanks
-Ben

[1] http://www.wikidot.com/plans
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From bwalton at opencsw.org  Sun Jun 19 13:34:25 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 19 Jun 2011 07:34:25 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
Message-ID: <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sat Jun 18 17:22:31 -0400 2011:

> When member(s) of the board, attempt to completely change the way
> opencsw operates, and they are at the same time *specfiically*
> attempting to avoid a formal vote while doing so, there is something
> extremely wrong.

No avoidance here.  If there isn't 50% support up front, the vote will
be run.  It can be run anyway although I'd personally see it as
wasting time if a majority clearly supports the change in an open,
documented fashion.  (I don't expect that this will actually happen
and fully expect to run a ballot bin.)

> >> I would like to put forward an amendment to the proposal. Are you
> >> going to disallow any kind of formal *on-list* amendment
> >> mechanism?
> >
> > Please provide your amendment for public review and get the
> > support of every currently signed member. ?Modifications without
> > the support of everyone that has already signed off on the current
> > form might invalidate their support, thus 100% approval for the
> > change.
> 
> This is a ludicrous methodology. But now it seems clear your real
> reason for getting people to "sign" it. You making the barrier to
> suggest changes impossible to overcome.

Say for a minute that there were no names undersigning the proposal.
There would still be multiple people that worked on it and put it
forward.  Do you feel that you have some intrinsic right to be able to
alter this proposal?  I think it would be ludicrous to not hold your
changes until it meets the support of the people that put forward the
original.

Go ahead and propose your changes on the list.  Do you not think
they'll be accepted by the people that have worked on the current
proposal?  Why is that?  Is it because the changes would run counter
to the meat of the current proposal?  If so, why would you expect a
change like that to be accepted?  If not, why are you worried about
getting the support of the current set of authors?

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


From rupert at opencsw.org  Sun Jun 19 15:00:55 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 19 Jun 2011 15:00:55 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
Message-ID: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>

hi,

as an experiment, i tried to convert the subversion gar repository to git
and mercurial:
 * http://code.google.com/p/gar/ (hg)
 * https://github.com/opencsw/gar (git)

where i was aware of a user name i entered you as owner as well.

what i am not sure is how to handle externals and patches onto them, but i
saw posts like:
*
http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment

what do you think, in general about a conversion, and in special, how to do
this patching?

rupert.



On Thu, Jan 6, 2011 at 02:30, Ben Walton <bwalton at opencsw.org> wrote:

> Excerpts from rupert THURNER's message of Wed Jan 05 14:12:46 -0500 2011:
>
> Hi Rupert,
>
> I'm sorry this wasn't easier for you.
>
> > * try to build, not all patches applied
> > * throw away the old patches, check in
>
> First, a recommendation: Never throw away patch/script/foo files from
> an existing build until you've got a working replacement.  I've kicked
> myself a few times for doing this. :)
>
> In a situation like this, I'd see if I could get the patches to apply
> manually using patch or other methods.
>
> > * "gmake extract" to get the source back
> > * edit the files again like it should be
>
> Although it may not complain, makepatch would prefer to be called
> after `gmake patch` to ensure all existing patches are applied.  I
> forget whether I enforced this with a constraint or not...If not, I
> don't recall a the reason why I didn't.
>
> > * "gmake makepatch"
> > * "gmake package", failed as there is a new file which would need
> >    patching as well.
>
> > * "gmake clean", "gmake extract" again
> > * edit the file
> > * "gmake makepatch" again
>
> Did you see your first patch applied in this process at all?  If not,
> you're working on a pre-patched set of files.
>
> > then i forgot to delete a line in a file which is already patched, and
> > i thought about repeating above procedure again:
> > 1. gmake extract
> >     applied patch 001
> > 2. gmake makepatch
> >     tried to apply patch 001 again
> > which failed.
>
> This is likely due to creating a patch against the unpatched tree
> above.  If so, I should look at making sure makepatch cannot run
> unless the patch target has already been called.  You could,
> potentially still have problems though...
>
> > then i gave up for the moment ... but this cannot be it, isn't it?
> > should we switch to the whole source from subversion to git and it
> > would be neater? then patches could be rebased instead of applied
> > newly.
>
> I wouldn't object[1], but others may disagree.  It's also a huge
> undertaking.  I know that many others are also using git quite a bit
> lately too.
>
> The first major portion of this transition would require separating
> GAR (the tool) from the build recipes.  Git simply doesn't handle
> (nicely) the idea of an external like subversion does.  This would be
> the final impetus to separate the two, most likely using Sebastian's
> excellent mgar!
>
> I know that Maciej has been having both success and frustration using
> the git-svn bridge as of late...
>
> Thanks
> -Ben
>
> [1] It would actually make my day!
> --
> 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. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110619/e163e301/attachment-0001.html>

From maciej at opencsw.org  Sun Jun 19 15:57:44 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 19 Jun 2011 14:57:44 +0100
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
	<BANLkTimsYXVfxT4+sfEnX4V2oxCOebT1bg@mail.gmail.com>
	<BANLkTikFTKAUhcsn0TV+S8T8c_iRdpuOeQ@mail.gmail.com>
	<BANLkTikUFoRwT9zBWghbHLxXFQOmZhAkpQ@mail.gmail.com>
	<1307924216-sup-6771@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikq0qtidbc9ZD7RQK4rFR6J4mdm-A@mail.gmail.com>

2011/6/13 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Philip Brown's message of Sun Jun 12 18:11:42 -0400 2011:
>
>> waitaminit... do you mean that in your cups package, you *force*
>> removal of the solaris printing packages?
>> without giving the user/admin a choice?
>
> I read that as 'on my systems, I...'

Yes, that's what I meant.

Maciej

From skayser at opencsw.org  Sun Jun 19 17:56:25 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 19 Jun 2011 17:56:25 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
Message-ID: <20110619155625.GC25705@sebastiankayser.de>

Hi Rupert,

* rupert THURNER <rupert at opencsw.org> wrote:
>    as an experiment, i tried to convert the subversion gar repository to git
>    and mercurial:
>    ? *? [1]http://code.google.com/p/gar/? (hg)
>    ? *? [2]https://github.com/opencsw/gar? (git)
>    where i was aware of a user name i entered you as owner as well.
>    what i am not sure is how to handle externals and patches onto them

to clarify, you are referring to the gar/ subtree (not the pkg/ subtree
which is also hosted in the GAR repo currently), right? 

Regarding externals, there's mgar, a wrapper around GAR which doesn't
rely on svn:externals [1,2]. It currently pulls gar/ from our subversion
repository and I could adjust it to pull from git instead (if folks
around here deem it useful to have gar/ hosted in a git repo).

Sebastian

[1] http://wiki.opencsw.org/gar-wrapper
[2] http://www.opencsw.org/packages/mgar/

From bwalton at opencsw.org  Mon Jun 20 03:27:20 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 19 Jun 2011 21:27:20 -0400
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
Message-ID: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011:

Hi Rupert,

> as an experiment, i tried to convert the subversion gar repository to git
> and mercurial:
>  * http://code.google.com/p/gar/ (hg)
>  * https://github.com/opencsw/gar (git)

I like this! :)  I'm not keen on mercurial given my exposure to it,
but anything distributed would be a step up.

> what i am not sure is how to handle externals and patches onto them,
> but i saw posts like:
> *
> http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment

> what do you think, in general about a conversion, and in special,
> how to do this patching?

I'm not sure what you mean by 'patches onto them' but basically,
submodules suck for our use case, in my estimation.  They're excellent
in projects where you're pulling in external code as a source library.
The most common example I see is that many projects have gnulib as a
submodule.  When they're polishing a new release, they update the
gnulib submodule to current as part of that process.  They won't work
nicely in our pkg/$foo/trunk setup though as we'd be constantly
required to update the sha1 reference to the submodule for every
recipe change.

As Sebastian mentioned, we can (and should!) do away with externals
and, if they're still in use, the old garlinks in favour of the new
mgar wrapper.

If we did this, we could (as long as Sebastian is on board), merge
mgar directly into the gar/v2 git repository and release an actual
package for it.  mgar is packaged now, but it could be extended to
deliver the rest of the gar code with it.

The impact of this would be that people would be forced to use mgar to
interact with gar (or create their own new frankenstein) and people
would need to learn/use git.  Many of us are already using git where
possible, so that's not likely a big hurdle.  Using mgar is a positive
experience and doesn't change workflow much beyond s/(svn|gmake)/mgar/
now.

Gar would have a package and we could still have a devel mode for gar
where the local git (or hg) repo is tracked against the head of the
main branch.  Good for users, good for devs.

This might be a nice test of the waters for a move away from svn
instead of attempting to move gar and all of the recipes in one shot.

Is anyone else excited by this idea?

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


From phil at bolthole.com  Mon Jun 20 06:59:26 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 19 Jun 2011 21:59:26 -0700
Subject: [csw-maintainers] proposal
In-Reply-To: <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>

On Sun, Jun 19, 2011 at 4:34 AM, Ben Walton <bwalton at opencsw.org> wrote:
> ...
> Say for a minute that there were no names undersigning the proposal.
> There would still be multiple people that worked on it and put it
> forward. ?Do you feel that you have some intrinsic right to be able to
> alter this proposal?

The trouble here is that we still have no proper (and by that I mean,
documented and officially approved)  procedures for even creating a
proposal, let alone amendment to the proposal, and then approving or
rejecting them.

As I have pointed out to the board previously, debian (for just one
example) has fully written up details of one way to do this.
A handwavy summary of that being:

  1. an initial proposal is made
  2. some formal discussion period (**ON THE LIST**) happens
      (off-list discussion may or may not happen, but the one that
actually counts, is the bits done on the developer list
       that is fully archivable by all members, fully accessible by
all members, and fully open to all members)
 3. If an amendment is proposed, then that is discussed. If
consensus(s) is reached, then the proposal is amended.
     (it is also possible that after discussion, the proposal is withdrawn)
     If no consensus is reached, then when voting time comes, both
versions of the proposal are put up for vote.
     The voting ballot then becomes,
    "Vote for one of the following:
        a) accept proposal documented [here]
        b) accept proposal as amended and documented [here]
        c) reject all versions of proposal"

  ( 4. otherwise, a summary of the proposal and its side effects is
drawn up, and the proposal is voted on)



> If so, why would you expect a
> change like that to be accepted? ?If not, why are you worried about
> getting the support of the current set of authors?

I am more concerned about "oh hey we reached X number of people with
their names on the document, so there's no reason to have discussion
on the mailing list, or a vote;  the proposal to change our practices
is 'deemed as passed'. Done. From now on we do this [this way].

From bonivart at opencsw.org  Mon Jun 20 10:24:02 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 20 Jun 2011 10:24:02 +0200
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTinMizMt76qEOT+jT8yXD0tCEw9zzQ@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTimwvpA9N5SMveaxQQBJFiWaC3jQkA@mail.gmail.com>
	<1308423068-sup-8691@pinkfloyd.chass.utoronto.ca>
	<BANLkTinMizMt76qEOT+jT8yXD0tCEw9zzQ@mail.gmail.com>
Message-ID: <BANLkTinBi6nrm-m2LwMz7AEA6D+NSx08MA@mail.gmail.com>

On Sat, Jun 18, 2011 at 10:15 PM, rupert THURNER <rupert at opencsw.org> wrote:
> this is the first thing people see if they come to the opencsw wiki ... and
> i am really wondering if opencsw or the server operator has some financial
> benefit? if not, i would strongly advocate to switch this off. if its built
> into the wiki software, then switch to a reasonable wiki, like
> http://moinmo.in or mediawiki, or redmine, or whatever.

But the wiki is not really public facing, it's mostly for maintainers
and those usually have an account on the wiki and do not see the ads
when logged in. When I created the wiki ads were optional, they no
longer are. I guess wikidot.com is not free to operate... :)

Please start a new thread if this is important to you, it's irrelevant
for this one.

/peter

From bonivart at opencsw.org  Tue Jun 21 17:29:29 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 21 Jun 2011 17:29:29 +0200
Subject: [csw-maintainers] /testing sendmail 8.14.5
Message-ID: <BANLkTim8J1a0wUYJ6tZ6Ursjyj64C9sgsg@mail.gmail.com>

I have done some work to the Sendmail 8.14.2 package from 2007. During
all this time Mike Watters, Benny von Mossner and Maciej Blizinski
have also contributed.

There's quite a few changes and it's a lot simpler now. It doesn't
mess with Solaris built-in Sendmail but instead delivers a script to
help with this. Change list:

+ it's in GAR
+ large file support
+ post install message to explain changes
+ fix paths in sendmail.cf and cswsendmail
+ include deactivate/reactivate scripts
+ migrate conf from /opt/csw/etc/mail
+ use alternatives to clear collisions with postfix
+ never start cswsendmail by default (collides with system sendmail)
+ path to sendmail.cf in binary (/etc/opt/csw/mail)
+ bdb hash support
+ remove all custom handling of conf files, users and so on. Replace with cas
+ contrib package

These bugs should be fixed:

#2915 Must stop built-in sendmail manually -> n/a
#3864 Sendmail must be relinked with new berkeley db -> bdb48
#4150 Sendmail 8.14.4 released -> this is 8.14.5
#4486 Provide sendmail's contrib/ tools as a separate package?

There's three packages: sendmail, sendmail_contrib and libmilter. You
can find them here:
http://buildfarm.opencsw.org/experimental.html#sendmail.

Please help test both new installs and upgrades. Does it work at all?
Things to do differently?

/peter

From bwalton at opencsw.org  Thu Jun 23 03:47:43 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 22 Jun 2011 21:47:43 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
	<BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
Message-ID: <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Jun 20 00:59:26 -0400 2011:
> On Sun, Jun 19, 2011 at 4:34 AM, Ben Walton <bwalton at opencsw.org> wrote:
> > ...
> > Say for a minute that there were no names undersigning the proposal.
> > There would still be multiple people that worked on it and put it
> > forward. ?Do you feel that you have some intrinsic right to be able to
> > alter this proposal?
> 
> The trouble here is that we still have no proper (and by that I mean,
> documented and officially approved)  procedures for even creating a
> proposal, let alone amendment to the proposal, and then approving or
> rejecting them.

And if we try to accomplish these things with you, we'll get nowhere.
We've tried this with the policy project.  Both Maciej and Peter gave
up working with you.

I'm more and more convinced that for such a small group of people, the
level of overhead involved with processes such as those in use at
Debian are not worthwhile.  Not that they're bad.  They're just very
heavy weight.

If you'd like to see changes to the proposal, put them forward.  If
they build on it in a constructive manner such that the those signed
on find them appealing, they'll be incorporated.  Otherwise they
won't.

>   1. an initial proposal is made

Done.

>   2. some formal discussion period (**ON THE LIST**) happens
>       (off-list discussion may or may not happen, but the one that
> actually counts, is the bits done on the developer list
>        that is fully archivable by all members, fully accessible by
> all members, and fully open to all members)

Please discuss.  That's why the proposal was announced.

>  3. If an amendment is proposed, then that is discussed. If
> consensus(s) is reached, then the proposal is amended.
>      (it is also possible that after discussion, the proposal is withdrawn)
>      If no consensus is reached, then when voting time comes, both
> versions of the proposal are put up for vote.

Right.  Put it out there and see if you get consensus.  As I said, if
you put something constructive together there is no reason it wouldn't
be accepted.  If you try to strip out the heart of the proposal,
nobody is going to bite on it, thus no consensus, thus no change.

Unless you've got a reasonable number of people (eg: more than one)
wanting a certain amendment, I don't see why it would hit the ballot.

> I am more concerned about "oh hey we reached X number of people with
> their names on the document, so there's no reason to have discussion
> on the mailing list, or a vote; the proposal to change our practices
> is 'deemed as passed'. Done. From now on we do this [this way].

Nobody is quelling discussion.  You're just not discussing it.  You'll
note that the names on the list are the ones that do the bulk of the
on-list discussing anyway and we've already talked about this.  There
will be a vote as well, although I stand by the statement that if we
had 50% + 1 people sign the proposal a vote is a waste of time.

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


From phil at bolthole.com  Thu Jun 23 18:49:55 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 23 Jun 2011 09:49:55 -0700
Subject: [csw-maintainers] proposal
In-Reply-To: <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
	<BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
	<1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinWqFC25t6WrzD1OrcLRpccC1_=0A@mail.gmail.com>

On Wed, Jun 22, 2011 at 6:47 PM, Ben Walton <bwalton at opencsw.org> wrote:
> ...
>
> Unless you've got a reasonable number of people (eg: more than one)
> wanting a certain amendment, I don't see why it would hit the ballot.

Because as you have pointed out, the people who pay attention and
speak up on the list, are already in favor of the proposal  as it is.
The whole point of having voting in the first place, rather than just
a "voice vote" on the list  is to "poll" the wishes of people who do
not speak up on the maintainers list.


Also: it doesnt "harm" anything, to have an amendment on the ballot.
if the silent folks dont want it, they wont vote for it.
Allowing people more options in a vote, shouldnt be something you need
to avoid. Rather, it should be favored.

politicians who attempt to limit voters' choices, are politicians who
manipulate the whole principles of democratic voting.

From jcraig at opencsw.org  Thu Jun 23 19:58:04 2011
From: jcraig at opencsw.org (Jonathan Craig)
Date: Thu, 23 Jun 2011 13:58:04 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTinWqFC25t6WrzD1OrcLRpccC1_=0A@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
	<BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
	<1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWqFC25t6WrzD1OrcLRpccC1_=0A@mail.gmail.com>
Message-ID: <BANLkTimpWsmjc74TevdLu_9nnnFJbcT-tw@mail.gmail.com>

On Thu, Jun 23, 2011 at 12:49 PM, Philip Brown <phil at bolthole.com> wrote:

> politicians who attempt to limit voters' choices, are politicians who
> manipulate the whole principles of democratic voting.

Phil, I dont nearly have the time I would like to participate in this
organization and you are one of the reasons that I am personally not
vocal on this list.  While most posts are constructive and attempt to
help one further their issues your posts generally do not.  I don't
need you to lecture me on the evils of authoritative systems.  The way
you drone on with comments like the above implies that others have
hidden agendas with aims to destroy the world as we know and your
simply trying to save the unwashed masses from their machinations.
Any post authored by you which is longer than a single word,
"batched", tends to raise my blood pressure to unhealthy limits.

The reason governing systems don't employ direct democracy is that it
doesn't scale.  We can't vote on every clause for every law we might
elect to have.  Voters tend to decide major issues:  Automated
publishing system vs. Human controlled w/ manual inspection.  Once the
main issue is decided then everyone digs in and crafts the best
solution that fulfills this goal.  To date, the only person I recall
staking out a position that a manual process is preferred is you.

For my two cents worth:  Given the size of the group and the demands
in terms of packages to support, automated publishing solutions turn a
subjective process into an objective process.  Any subjective control
that needs to be wielded can be handled by the bug process.
Increasing the ease and throughput of package development will be
beneficial and is unlikely to bring an end to democracy.  Not even the
US IRS attempts to individually review every tax return.  Automation,
and the development of an effective exceptions process, allows one to
handle this with increased efficiency.

While you have whined incessantly on this list about amendments, I
don't recall actually seeing an amendment.  Stop complaining about how
you should have the right to control the ballot before you start
turning out some verbage.  If your changes have merit, then people
will listen and incorporate your ideas.  Your current strategy seems
to employ a delaying tactic in the hopes that everyone will get tired
and leave so you may maintain the status quo.  If you want to be
heard, then lets see some original ideas that don't try to codify the
status quo or stop whining about the downfall of the democratic state.
 If you instead choose to continue attacking the governing process or
try to convince me of your virtue, don't bother as I'm tired of those
tactics already.

I'm sorry my post doesn't forward the discussion beyond stating: +1 to
an automated process

From phil at bolthole.com  Thu Jun 23 23:39:32 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 23 Jun 2011 14:39:32 -0700
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTimpWsmjc74TevdLu_9nnnFJbcT-tw@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
	<BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
	<1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWqFC25t6WrzD1OrcLRpccC1_=0A@mail.gmail.com>
	<BANLkTimpWsmjc74TevdLu_9nnnFJbcT-tw@mail.gmail.com>
Message-ID: <BANLkTingmkaSf+PiQgp-sreRB13W4Bymug@mail.gmail.com>

Hi Jonathan,

I was going to write more, but perhaps it is better for me to just
write on the most important bits here:


On Thu, Jun 23, 2011 at 10:58 AM, Jonathan Craig <jcraig at opencsw.org> wrote:

> Your current strategy seems
> to employ a delaying tactic in the hopes that everyone will get tired
> and leave so you may maintain the status quo.

actually, just the opposite is true. I've been petitioning the board
for an EARLIER vote on the related issues, for over a month now. They
have been delaying things, and making things more complicated for
voting for anything other than the new proposal.
If you disbelieve this, then request access to the full archives of
the board mailing list for the last 2 months.

my first emails to them about getting a vote going, was back on may 9th

I put forth a proposal for voting. I took the time to write up a
template for general "proposal" type ballots. They are the ones who
delayed things, and then, weeks later,  finally brought forward a
"vote" which was vastly different to the one I requested, in order to
favor their position.

Which is why I am complaining so strongly about manipulation of the
voting process.

If you wish to know more, then rather than attempting to summarize
over 30 emails, I will repeat my suggestion that you request access to
the full archives of the board mailing list.
You might find my original email sent to them on may 9th, to be
enlightening in the area of how you view my motivations on this.



>?If you want to be
> heard, then lets see some original ideas that don't try to codify the
> status quo or stop whining about the downfall of the democratic state.

I have been putting together something which will go out in a few
hours. I was pondering whether or not to break it up into separate
emails. But given that some people have complained when I send out my
disagreements one email at a time, I'm trying to make a single email
out of it.

From ellson at opencsw.org  Fri Jun 24 00:51:52 2011
From: ellson at opencsw.org (John Ellson)
Date: Thu, 23 Jun 2011 18:51:52 -0400
Subject: [csw-maintainers] where is graphviz-2.28 ?
Message-ID: <4E03C388.2070207@opencsw.org>

If I'm being impatient, then I'm sorry, but I don't seem to be able to 
get graphviz-2.28 from the openCSW mirrors yet.  Is there some problem?

Also, I'm wondering why the catalog at 
http://www.opencsw.org/get-it/packages/  still shows a few 2.26.3 packages?

graphviz2 <http://www.opencsw.org/packages/CSWgraphviz2>       
2.26.3,REV=2010.08.05 Stub to the CSWgraphviz package
graphvizdoc <http://www.opencsw.org/packages/CSWgraphvizdoc>     
2.26.3,REV=2010.08.05 Graphviz documentation
graphvizgraphs <http://www.opencsw.org/packages/CSWgraphvizgraphs>  
2.26.3,REV=2010.08.05 Graphviz example graphs


These are no-arch packages, and they possibly haven't changed since 
2.26.3, but they are provided from the latest 2.28.0 sources so I think 
they should be updated.

John

From phil at bolthole.com  Fri Jun 24 01:04:39 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 23 Jun 2011 16:04:39 -0700
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <4E03C388.2070207@opencsw.org>
References: <4E03C388.2070207@opencsw.org>
Message-ID: <BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>

On Thu, Jun 23, 2011 at 3:51 PM, John Ellson <ellson at opencsw.org> wrote:
> If I'm being impatient, then I'm sorry, but I don't seem to be able to get
> graphviz-2.28 from the openCSW mirrors yet. ?Is there some problem?
>

Ah, my apologies. sorry for the lack of feedback on this one.

there would seem to indeed be a problem.

ERROR 1062 (23000) at line 34: Duplicate entry '/opt/csw/bin/compare' for key 1
DB Update failed. Possibly a filename collision

our search page, shows
CSWschilyutils 	/opt/csw/bin/compare
CSWimagemagick 	/opt/csw/bin/compare

Should I release "all the rest", but hold off on the imagemagic
packages until we figure out what to do about that one?
Or hold everything in your very large set (51 packages)until that is redone?

From ellson at opencsw.org  Fri Jun 24 01:24:11 2011
From: ellson at opencsw.org (John Ellson)
Date: Thu, 23 Jun 2011 19:24:11 -0400
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
Message-ID: <4E03CB1B.9020408@opencsw.org>

On 06/23/2011 07:04 PM, Philip Brown wrote:
> On Thu, Jun 23, 2011 at 3:51 PM, John Ellson<ellson at opencsw.org>  wrote:
>> If I'm being impatient, then I'm sorry, but I don't seem to be able to get
>> graphviz-2.28 from the openCSW mirrors yet.  Is there some problem?
>>
> Ah, my apologies. sorry for the lack of feedback on this one.
>
> there would seem to indeed be a problem.
>
> ERROR 1062 (23000) at line 34: Duplicate entry '/opt/csw/bin/compare' for key 1
> DB Update failed. Possibly a filename collision
>
> our search page, shows
> CSWschilyutils 	/opt/csw/bin/compare
> CSWimagemagick 	/opt/csw/bin/compare
>
> Should I release "all the rest", but hold off on the imagemagic
> packages until we figure out what to do about that one?
> Or hold everything in your very large set (51 packages)until that is redone?

I think imagemagic has to be released at the same time, because the old 
version won't work with the new graphviz libs.
Possibly just   /opt/csw/bin/compare can be excluded, but this is upto Dago.


Can you explain the other issue with the version numbers on the  noarch 
packages?  Or is it just that the update stopped half way, or is there 
some other problem?

John

From phil at bolthole.com  Fri Jun 24 01:32:08 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 23 Jun 2011 16:32:08 -0700
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <4E03CB1B.9020408@opencsw.org>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
Message-ID: <BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>

On Thu, Jun 23, 2011 at 4:24 PM, John Ellson <ellson at opencsw.org> wrote:
>
>
> I think imagemagic has to be released at the same time, because the old
> version won't work with the new graphviz libs.
> Possibly just ? /opt/csw/bin/compare can be excluded, but this is upto Dago.

okay, holding ALL 51 packages :(


> Can you explain the other issue with the version numbers on the ?noarch
> packages? ?Or is it just that the update stopped half way, or is there some
> other problem?

sorry, dont understand/recall what you are referring to there.

From bwalton at opencsw.org  Fri Jun 24 02:19:19 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 23 Jun 2011 20:19:19 -0400
Subject: [csw-maintainers] proposal
In-Reply-To: <BANLkTingmkaSf+PiQgp-sreRB13W4Bymug@mail.gmail.com>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
	<BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
	<1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWqFC25t6WrzD1OrcLRpccC1_=0A@mail.gmail.com>
	<BANLkTimpWsmjc74TevdLu_9nnnFJbcT-tw@mail.gmail.com>
	<BANLkTingmkaSf+PiQgp-sreRB13W4Bymug@mail.gmail.com>
Message-ID: <1308874720-sup-1393@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Jun 23 17:39:32 -0400 2011:

> actually, just the opposite is true. I've been petitioning the board
> for an EARLIER vote on the related issues, for over a month
> now. They

Yes, we've been seeing the same things on board@ as we get on
maintainers at .  Things like "good news, I solved the problem with this
so we can keep a human release manager," etc...eg: working diligently
to derail this.

The vote writeup you did was an attempt at this.  I _want_ you to do
this writeup as much as possible as that removes avenues for complaint
later.  What I'm not going to allow is for this to be hijacked and
derailed by changing the content of the vote.

Admittedly, I've been slow in handling some of this this.  There are a
few reasons for that, not the least of which is that it's absolutely
painful moving forward as I know that each step is met with the same
thing.

> If you disbelieve this, then request access to the full archives of
> the board mailing list for the last 2 months.

Anyone that wishes may see this.  There's nothing to hide there.

> my first emails to them about getting a vote going, was back on may
> 9th

The vote will open on Monday the 27th.  That should be plenty of time
to wrap up any discussion assuming you get your proposed amendments
out tonight.  If real back and forth debate is still happening at that
time, we can delay.  Real debate would be welcome.

I'm going to be thrilled when this is settled though as there are
other OpenCSW things I'd like to spend time on.

> I put forth a proposal for voting. I took the time to write up a
> template for general "proposal" type ballots. They are the ones who
> delayed things, and then, weeks later, finally brought forward a
> "vote" which was vastly different to the one I requested, in order
> to favor their position.

The problem here is that you didn't request a vote.  You knew a vote
was coming and tried to steer it away from the heart of what we put
forward.  We can and will use this template that you have put together
although the wording will need work as we will be voting on the
proposal, not your wish for status quo.

As in many other cases, I'm done discussing this with you unless you
advance something useful to the discussion.  By useful, I mean
constructive.

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


From phil at bolthole.com  Fri Jun 24 02:49:59 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 23 Jun 2011 17:49:59 -0700
Subject: [csw-maintainers] proposal
In-Reply-To: <1308874720-sup-1393@pinkfloyd.chass.utoronto.ca>
References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca>
	<BANLkTikeeyi6J4p=zopyW4Ehk1JO--ia4w@mail.gmail.com>
	<1308420263-sup-8511@pinkfloyd.chass.utoronto.ca>
	<BANLkTikyzgPiZpD9UBtyVsSeUZ3JairzSw@mail.gmail.com>
	<1308482786-sup-7548@pinkfloyd.chass.utoronto.ca>
	<BANLkTinjz3LD0xVtr1C+rWS0Bd22-uQKNA@mail.gmail.com>
	<1308792965-sup-4934@pinkfloyd.chass.utoronto.ca>
	<BANLkTinWqFC25t6WrzD1OrcLRpccC1_=0A@mail.gmail.com>
	<BANLkTimpWsmjc74TevdLu_9nnnFJbcT-tw@mail.gmail.com>
	<BANLkTingmkaSf+PiQgp-sreRB13W4Bymug@mail.gmail.com>
	<1308874720-sup-1393@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTin+8caBeUnhZ4z8fdopWE3QyUa7DQ@mail.gmail.com>

On Thu, Jun 23, 2011 at 5:19 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Thu Jun 23 17:39:32 -0400 2011:
>
>> actually, just the opposite is true. I've been petitioning the board
>> for an EARLIER vote on the related issues, for over a month
>> now. They
>
> Yes, we've been seeing the same things on board@ as we get on
> maintainers at . ?Things like "good news, I solved the problem with this
> so we can keep a human release manager,"[....]
>
> The vote writeup you did was an attempt at this. ?I _want_ you to do
> this writeup as much as possible as that removes avenues for complaint
> later. ?What I'm not going to allow is for this to be hijacked and
> derailed by changing the content of the vote.
>

What you really seem be saying here is,
"What I'm not going to allow, is for a vote on whether or not to keep
a human release manager", even if everything else about the "new
process", migration to current, etc. is kept intact.

Which is exactly what I've been saying; you are controlling and
limiting voting choices.

To diffuse other people's accusations about "It's all about Phil
trying to keep control":
I don't care whether the release manager is me, or someone else.
Frankly, I'm rather tired of dealing with it myself.
I speak up for it, because I honestly believe that opencsw is better
off with *A* release manager, or a release manager group **in addition
to**  automation,
 vs pure automation all by itself.


Anyways.
next email is my? proposed amendments

From phil at bolthole.com  Fri Jun 24 02:53:21 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 23 Jun 2011 17:53:21 -0700
Subject: [csw-maintainers]  amendments and issues with recent prop
Message-ID: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>

Since the recent thread had gotten filled up with some things that
were only semi-relevant to the direct issue, or in some cases not at
all relevant, I thought it would be useful if I started a fresh
thread.
The following are some proposed amendments to the proposal given at
http://wiki.opencsw.org/automated-release-proposal

Each item below is a separate issue; this email is a collection of
suggested amendments, not an "all or nothing" document.
Some items are related to specific wording of the proposal. Other
items are related to technical issues that need to be addressed.

It is possible that some problems have arisen due to some maintainers
potentially misunderstanding how things *currently* work. Some of the
items below might help spread knowledge around more widely.


Sorry that this is long: however, people complain when I break things
up into smaller emails also, so it's a lose-lose situation no matter
what I do.
Wording problems are grouped in the first section, technical issues
are grouped in the later section.



1. Amendment: more technical details need to be given.
 (perhaps as a side referenced document)
  The proposal suggests that opencsw adopt a "new system", without
*fully* *defining* this new system at a technical level. There are
some technical specifics, but not full coverage.
  There is a lot of [will do, in the future] language without giving specifics.
 OpenCSW is supposed to be a technical organization. It seems to me
that we should be voting on specific full technical implementations,
rather than something with fuzzy chunks in it

2. Amendment: Removal of "Anyone can participate[in the new process]",
and related lines.
This line falsely implies that currently, people are somehow blocked
from participating now.
This is untrue, both at the direct package level and at the discussion
level, as shown below. Therefore this red herring should be removed.
(and possibly, maintainers should be re-informed of some facts):

   At the discussion level, all packages "held" from release, are
discussed in the pkgsubmissions mail list.
   Right now, "anyone can participate" in the discussion of a held package.

  At the direct package participation level:
   If a maintainer chooses to have their packages examined/tested
before pushing them out to the general public, they can already drop
them in "experimental" and ask that people look at them before
publicly pushing them out to newpkgs.

  The fact that others rarely choose look at them now when a
maintainer requests feedback, is not a failure of the current system,
but rather an indication that maintainers rarely choose to look at
other people's packages. It is doubtful that a wholesale "new system"
will change that.

If people rarely even look at packages when a maintainer *specifically
requests* feedback, it seems less likely when the whole thing is
automated and there is no explicit request to do so.


3. Removal or adjustment of "Packages are subject to stalls or
rejections for non-policy reasons."

First of all, it implies, FALSELY, that a package can be completely
rejected by the release manager with no recourse. As formalized in
http://wiki.opencsw.org/release-manager , a maintainer can always call
for a vote if they disagree with the stance that the release manager
has taken. This has already happened, twice, and after the vote, the
package(s) were released, so it is a proven effective method.

Additionally, it does not recognize the benefit that policy is not and
should not be set in stone for all time. If a release manager holds a
package, for reasons that are not currently policy, but perhaps should
be, then it is a good thing that discussion take place. Similarly, it
is actually a good thing if the issue gets forced to a vote, because
that way, policy can be officially adjusted, as the majority vote
decides.

4. Removal of "All code, tools and documentation will available for
all to see and improve."
 This falsely implies that there is "hidden code and/or tools". There is not.
 All code that is actually necessary for the release process is
already completely public and published.
 Most other stuff isnt strictly "published", but is readable by any
maintainer who actually cares, in my home
 directory on bender. It isnt much more than convenient aliases,etc. I
have, akin to aliases in a .bashrc, etc.

The release process as a whole has been fully documented also.
If anyone cares to dispute this, then please point out specific areas
or tools that either lack documentation, or are hidden.   I have
previously requested this, when this claim was made recently, but was
only met with groundless mumblings that things were still somehow
"hidden", without any specifics given.

5. Removal of "unclear path to resolution of disputes" claim.
 There is actually a clear path:
  discussion on pkgsubmissions list -> discussion on maintainers list
-> vote if needed.
 As far as complexity, this is virtually identical to the "new" path
to resolution. The main difference is only that under the current
system, a package deemed as "bad" will never be released, whereas
under the "new" system, a package deemed as "bad" will first be
released publically, but then after some indeterminate length of
time.. potentially a **month or more**.. eventually be retracted.

6. Removal or adjustment of "All participants will have equal standing".
  It would actually be harmful to opencsw to follow that sentiment
completely. Specifically, to have two new maintainers sign off on each
others packages, will inevitably lead to some mistakes that could be
avoided by the oversight of more experienced maintainers.





7. A technical implementation issue, that is not properly addressed in
the proposal:

There is no such thing as a *fully* automated release system: at some
point, issues come up that require manual intervention. For example,
package renames, and removals. or fixing bugs in some unforseen
interaction of the system and a new package.

The proposal declares that catalog signatures will be generated
automatically. However, who or what group will be responsible to
manage the catalog when the automated system is either inadequate, or
fails?

8. A technical implementation issue not addressed at all in the proposal:
What about package takeovers? is it going to be allowable for any
maintainer to take over any package, at any time? or remove any
package at any time?

9. A technical implementation issue not addressed at all in the proposal:

"A package may not progress from unstable to current with open bugs."

It has been written elsewhere, that this progress will be automated,
after (2 weeks time).
However, what about the problem when two new upgrades are released
together, as follows:
  libA1(.1) upgrades libA1(.0)
  libB1(.1) upgrades libB1(.0), and depends on libA1. It FAILS if run
against the older libA1.0
[ I am using the (.1, .0) syntax above, to indicate minor rev changes
to the hypothetical libraries, where the SONAME does not change. ]

  A bug is filed against libA1(.1)
   The bug is not addressed within 2 weeks. (lets say the bug is filed
on the 13th day)
However, libB1(.1) has no bugs filed. It then gets auto-migrated to
current. Where it will then be non-functional,
and break everything depending on "libB1"

I have used the example of shared libraries here, but the problem is
generic, for any time that two packages are pending migration from
unstable to current at the same time, with one dependent on the other.
It could well be that they are from completely diferent maintainers.
maintainer A, releases libA1 update to unstable. a day or two later,
maintainer B updates libB1 based on that update, and releases libB1 to
unstable. 12 days later, libA1 is blocked from release to current, but
libB1 will sail through 2 days later.

Note that this is particularly important when someone decides to do a
"complicated" upgrade set that has 10, 20, 30 or more packages


10. technical implementation suggestion:

If the goal is to make it *easier* for people to get involved in the
QA process, I would suggest that either a different mechanism than bug
filing be used, OR an alternative interface to the bug system be
provided.
I personally feel that the existing "exchange emails over the
pkgsubmissions mailing list" is the smallest pain point in this sort
of process.
Forcing people to move to (our existing) bug system for this kind of
discussion, makes it *more* difficult, not easier, to be involved in
QA, in my opinion. It's possible other bug systems would do better;
I'm just limiting my comments to our existing one.




11. technical implementation issue:

  "By opening up the QA process such that multiple people can easily
participate and have equal standing on the matters at hand, we feel
that overall package quality will improve;"

Unfortunately, (as mentioned on maintainers list previously), making
the capability available, does not actually mean that people will
definitely make use of it.
The new proposal as prototyped, currently allows for LESS people to
scrutinize a package than currently.
At the moment, a release manager is guaranteed to at least glance at
it. Whereas with the "new process", a package may (and I claim, will
*usually*) get released with no-one but the maintainer ever looking at
it.

If the goal is truly, "more/better QA", then a proposed remedy for
this, is to put in mandatory hooks for the "migrate from unstable to
current" step, to require that at least one other person besides
maintainer has examined the package.

If on the other hand, the goal is really "to allow packages to be
released with no one but the maintainer ever looking at it", then all
claims about better QA should be removed from the proposal, and the
stated "benefits" of the proposal should be updated to reflect that.

From bonivart at opencsw.org  Fri Jun 24 11:22:45 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 24 Jun 2011 11:22:45 +0200
Subject: [csw-maintainers] /testing SpamAssassin 3.3.2 (Fwd: ANNOUNCE:
	Apache SpamAssassin 3.3.2 available)
Message-ID: <BANLkTim-HB+LUkHc9Om+q2nd8YZ-kLPB3A@mail.gmail.com>

There's new packages to test in:

http://buildfarm.opencsw.org/experimental.html#spamassassin

/peter

---------- Forwarded message ----------
From: Warren Togami <wtogami at apache.org>
Date: Fri, Jun 24, 2011 at 1:40 AM
Subject: ANNOUNCE: Apache SpamAssassin 3.3.2 available
To: announce at spamassassin.apache.org


Release Notes -- Apache SpamAssassin -- Version 3.3.2

Introduction
------------

This is a minor release, primarily to support perl-5.12 and later.
Additionally several other minor bugs are fixed.


Downloading and availability
----------------------------

Downloads are available from:

http://spamassassin.apache.org/downloads.cgi

md5sum of archive files:

?253f8fcbeb6c8bfcab9d139865c1a404 ?Mail-SpamAssassin-3.3.2.tar.bz2
?d1d62cc5c6eac57e88c4006d9633b81e ?Mail-SpamAssassin-3.3.2.tar.gz
?06d84d34834d9aecdcdffcc4de08b2a7 ?Mail-SpamAssassin-3.3.2.zip
?72f8075499c618518c68c7399f02b458 Mail-SpamAssassin-rules-3.3.2-r1104058.tar.gz

sha1sum of archive files:

?f38480352935fe3bb849a27a52615e400dee7d66 ?Mail-SpamAssassin-3.3.2.tar.bz2
?de954f69e190496eff4a796a9bab61747f03072b ?Mail-SpamAssassin-3.3.2.tar.gz
?edc6297dc651eeb7a4872f596ec5a54aeea85349 ?Mail-SpamAssassin-3.3.2.zip
?a199d5f0f8c2381e3dfe421e7a774356b3ffda4b
Mail-SpamAssassin-rules-3.3.2-r1104058.tar.gz

Note that the *-rules-*.tar.gz files are only necessary if you cannot,
or do not wish to, run "sa-update" after install to download the
latest fresh rules.

See the INSTALL and UPGRADE files in the distribution for important
installation notes.


GPG Verification Procedure
--------------------------
The release files also have a .asc accompanying them. ?The file serves
as an external GPG signature for the given release file. ?The signing
key is available via the wwwkeys.pgp.net key server, as well as
http://www.apache.org/dist/spamassassin/KEYS

The key information is:

pub ? 4096R/F7D39814 2009-12-02
? ? ?Key fingerprint = D809 9BC7 9E17 D7E4 9BC2 ?1E31 FDE5 2F40 F7D3 9814
uid ? ? ? ? ? ? ? ? ?SpamAssassin Project Management Committee
<private at spamassassin.apache.org>
uid ? ? ? ? ? ? ? ? ?SpamAssassin Signing Key (Code Signing Key,
replacement for 1024D/265FA05B) <dev at spamassassin.apache.org>
sub ? 4096R/7B3265A5 2009-12-02

To verify a release file, download the file with the accompanying .asc
file and run the following commands:

?gpg -v --keyserver wwwkeys.pgp.net --recv-key F7D39814
?gpg --verify Mail-SpamAssassin-3.3.2.tar.bz2.asc
?gpg --fingerprint F7D39814

Then verify that the key matches the signature.

Note that older versions of gnupg may not be able to complete the
steps above. Specifically, GnuPG v1.0.6, 1.0.7 & 1.2.6 failed while
v1.4.11 worked flawlessly.

See http://www.apache.org/info/verification.html for more information
on verifying Apache releases.



Summary of major changes since 3.3.1
------------------------------------

NOTE: Complete changes are available at
http://svn.apache.org/repos/asf/spamassassin/branches/3.3/Changes

Bug #6353: Fix FH_FROMEML_NOTLD, add MISSING_FROM

Bug #6427: Spamc windows header library missing two defines.

Bug #6476: patch to fix missing sa-awl man page bug

Bug #6470: Small change in windows to exit stating that the exit
status is unknown. ?Thanks to Daniel Lemke for many of these small
win32 patches.

Bug #6314: Complete removal of spamassassin.spec

Bug #6589: Errors in man pages

Bug #6588: Small bug in the regexp caught by Jose Borges Ferreira in

Bug #6515: spamd timeout_child option overrides time_limit
configuration option with nastier behaviour

Bug #6490: Mail::SpamAssassin::Plugin::SPF - Two enhancement issues

Bug #6562: NULL reference bug in libspamc. Quick workaround to avoid a crash.

Bug #6454: wrong status test on $sth->rows in BayesStore::PgSQL

Bug #6418: Cannot Log to stderr without timestamps

Bug #6403: GMail should use ESMTPSA to indicate that it is in fact
authenticated, but doesn't

Bug #6229: TextCat is too case sensitive

Bug #6241: mkrules does not understand newer options and "else"

Bug #6382: add missing unwhitelist_from_dkim, remove facebook and
linkedin from dkim whitelisting

Bug #5744: some documentation fixes

Bug #6447: new feature to bayes autolearning: learn-on-error

Bug #6566: X-Ham-Report default wording ("has identified this incoming
email as possible spam") is confusing and inaccurate

Bug #6468: splice() offset past end of array in HTML.pm

Bug #6377: win32: spamd signal handling

Bug #6376: win32: consider negative pids under windows in spamds waitpid

Bug #6375: win32: posix macro not implemented - spamd

Bug #6336: "Illegal octal digit 9" received during rules compile

Bug #6526: Disable rfc-ignorant.org

Bug #6531: clear_uridnsbl_skip_domain feature to allow admin override
of default configuration

Bug #5491: MIME_QP_LONG_LINE triggering on valid email

Bug #6558: body rules having "tflags multiple" may cause infinite loop
when compiled - a workaround

Bug #6557: Use same age limits in ruleqa as in sa-updates

Bug #6548: spamd protocol examples are wrong

Bug #6500: clear_originating_ip_headers seems to be broken

Bug #6565: check_rbl_sub rules - all dots need to be escaped - commit
felicity/70_dnswl.cf and felicity/70_iadb.cf too

Bug #6565: check_rbl_sub rules - all dots need to be escaped

Bug #6578: Move TLD regexp to RegistrarBoundaries and make FreeMail use it

Bug #6392: fix one more case of a 'goto into a construct' this one
occured with sa-compile

Bug #6443: Metadata Headers are Case-Sensitive

Bug #5690: tune BAD_ENC_HEADER score down

Bug #6022, tune TVD_RCVD_IP score down

Bug #6394: too high score for FREEMAIL_ENVFROM_END_DIGIT

Bug #6499: and mailing list: wrapped scores for rules
DKIMDOMAIN_IN_DWL*, ACCESSDB and SHORTCIRCUIT into a suitable
ifplugin/endif to avoid lint warnings; removed score for nonexistent
rule SUBJ_RE_NUM.

Bug #6242: merge the boundary fix in r931527 to the 3.3 branch

Bug #6460: RCVD_ILLEGAL_IP false positives

Bug #6506: Modifying a list while traversing it with a foreach

Bug #6488: Lint errors with Perl 5.12.1 in AntiVirus.pm

Bug #6467: Remove assigned 223/8 from RCVD_ILLEGAL_IP

Bug #6419: Resolve rounding issue irregularity with spamd/spamc

Bug #5894: spamd doesn't use vpopmail virtual users' dirs - removed
one extra space

Bug #6416: avoid undef warnings in AutoWhitelist.pm as a result of
incorrect Received header field or its incorrect parsing

Bug #6415: Open of auto-whitelist file failed: Insecure dependency in eval

Bug #6299: update, enhance, and expand RCVD_ILLEGAL_IP from

Bug #6392: Test suite fails with perl 5.12.0

Bug #6412: remove .yu TLD and add .me SLDs

Bug #6395: backport - improved URI parsing

Bug #6393: make File::Copy module load conditional on 'sa-learn
--upgrade' with DBM files, not very commonly used

Bug #6396: Use of uninitialized value in lc at
lib/Mail/SpamAssassin/Plugin/MIMEEval.pm


About Apache SpamAssassin
-------------------------

Apache SpamAssassin is a mature, widely-deployed open source project
that serves as a mail filter to identify spam. SpamAssassin uses a
variety of mechanisms including mail header and text analysis,
Bayesian filtering, DNS blocklists, and collaborative filtering
databases. In addition, Apache SpamAssassin has a modular architecture
that allows other technologies to be quickly incorporated as an
addition or as a replacement for existing methods.

Apache SpamAssassin typically runs on a server, classifies and labels
spam before it reaches your mailbox, while allowing other components
of a mail system to act on its results.

Most of the Apache SpamAssassin is written in Perl, with heavily
traversed code paths carefully optimized. Benefits are portability,
robustness and facilitated maintenance. It can run on a wide variety
of POSIX platforms.

The server and the Perl library feels at home on Unix and Linux
platforms, and reportedly also works on MS Windows systems under
ActivePerl.

For more information, visit http://spamassassin.apache.org/


About The Apache Software Foundation
------------------------------------

Established in 1999, The Apache Software Foundation provides
organizational, legal, and financial support for more than 100
freely-available, collaboratively-developed Open Source projects. The
pragmatic Apache License enables individual and commercial users to
easily deploy Apache software; the Foundation's intellectual property
framework limits the legal exposure of its 2,500+ contributors.

For more information, visit http://www.apache.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: announce-unsubscribe at spamassassin.apache.org
For additional commands, e-mail: announce-help at spamassassin.apache.org

From bwalton at opencsw.org  Fri Jun 24 15:13:34 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 24 Jun 2011 09:13:34 -0400
Subject: [csw-maintainers] gar tip
Message-ID: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca>


Hi All,

Peter and I just realized that not everyone is aware of the templated
GAR recipe feature.  In opencsw/ (or opencsw/cpan, etc), you can type:

gmake newpkg-foo

This will give you a templated base recipe file.  It's custom to each
specialized category (cpan, etc) so that things like gmake
newpkg-Some::Cool:Perl will generate a recipe for
CSWpm-some-cool-perl/pm_some_cool_perl, etc.

It should save you some typing and give you a standard base recipe to
start from.

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


From ellson at opencsw.org  Fri Jun 24 15:49:16 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 24 Jun 2011 09:49:16 -0400
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
Message-ID: <4E0495DC.2070508@opencsw.org>

On 06/23/2011 07:32 PM, Philip Brown wrote:
> On Thu, Jun 23, 2011 at 4:24 PM, John Ellson<ellson at opencsw.org>  wrote:
>>
>>
>> I think imagemagic has to be released at the same time, because the old
>> version won't work with the new graphviz libs.
>> Possibly just   /opt/csw/bin/compare can be excluded, but this is upto Dago.
>
> okay, holding ALL 51 packages :(

Ok. Dago said he would fix this asap, when he gets back.

>
>
>> Can you explain the other issue with the version numbers on the  noarch
>> packages?  Or is it just that the update stopped half way, or is there some
>> other problem?
>
> sorry, dont understand/recall what you are referring to there.


If you go to:

   http://www.opencsw.org/get-it/packages/

and search for "graphviz" you will see that the graphviz-2.28 packages 
are already posted *except* for the 3 noarch packages which are still at 
2.26.3

Why are any 2.28 packages posted if the release is blocked?

Or, conversely, why aren't all 2.28 packages posted?


John


From phil at bolthole.com  Fri Jun 24 16:00:51 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 24 Jun 2011 07:00:51 -0700
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <4E0495DC.2070508@opencsw.org>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
	<4E0495DC.2070508@opencsw.org>
Message-ID: <BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>

On Fri, Jun 24, 2011 at 6:49 AM, John Ellson <ellson at opencsw.org> wrote:
>
>>> Can you explain the other issue with the version numbers on the ?noarch
>>> packages? ?Or is it just that the update stopped half way, or is there
>>> some
>>> other problem?
>>
>> sorry, dont understand/recall what you are referring to there.
>
>
> If you go to:
>
> ?http://www.opencsw.org/get-it/packages/
>
> and search for "graphviz" you will see that the graphviz-2.28 packages are
> already posted *except* for the 3 noarch packages which are still at 2.26.3


ah. yes, your guess is right, that's just where the update stopped,
there is no problem with the ARCH=all packages that I am aware of.

From bonivart at opencsw.org  Fri Jun 24 16:04:29 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 24 Jun 2011 16:04:29 +0200
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
	<4E0495DC.2070508@opencsw.org>
	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>
Message-ID: <BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>

On Fri, Jun 24, 2011 at 4:00 PM, Philip Brown <phil at bolthole.com> wrote:
> ah. yes, your guess is right, that's just where the update stopped,

So why did you say that it was batched then?

/peter

From phil at bolthole.com  Fri Jun 24 16:31:49 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 24 Jun 2011 07:31:49 -0700
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
	<4E0495DC.2070508@opencsw.org>
	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>
	<BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>
Message-ID: <BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>

On Fri, Jun 24, 2011 at 7:04 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Fri, Jun 24, 2011 at 4:00 PM, Philip Brown <phil at bolthole.com> wrote:
>> ah. yes, your guess is right, that's just where the update stopped,
>
> So why did you say that it was batched then?

unfortunately, I emailed prematurely. Normally, I wait until after the
"register in database and copy over" stuff is complete, but in this
case, since it was such a huge batch, (which probably takes over 10
mins to complete, rather than the usual <1 min)  I must have kicked
off that stuff, sent the email to let John know I had touched it, and
then moved on to do other things.

I should better have written "batching", I suppose.

From bonivart at opencsw.org  Fri Jun 24 16:37:56 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 24 Jun 2011 16:37:56 +0200
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
	<4E0495DC.2070508@opencsw.org>
	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>
	<BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>
	<BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>
Message-ID: <BANLkTinFZxutH93bbitTEkYsgryp385zaQ@mail.gmail.com>

On Fri, Jun 24, 2011 at 4:31 PM, Philip Brown <phil at bolthole.com> wrote:
> I should better have written "batching", I suppose.

No, you should have said what was wrong with it. You didn't follow
through with the batching but never updated the status either so the
maintainer was just left waiting for it to appear on the mirrors which
would have never happened.

/peter

From ellson at opencsw.org  Fri Jun 24 17:10:26 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 24 Jun 2011 11:10:26 -0400
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTinFZxutH93bbitTEkYsgryp385zaQ@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>	<4E03CB1B.9020408@opencsw.org>	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>	<4E0495DC.2070508@opencsw.org>	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>	<BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>	<BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>
	<BANLkTinFZxutH93bbitTEkYsgryp385zaQ@mail.gmail.com>
Message-ID: <4E04A8E2.1060602@opencsw.org>

On 06/24/2011 10:37 AM, Peter Bonivart wrote:
> On Fri, Jun 24, 2011 at 4:31 PM, Philip Brown<phil at bolthole.com>  wrote:
>> I should better have written "batching", I suppose.
>
> No, you should have said what was wrong with it. You didn't follow
> through with the batching but never updated the status either so the
> maintainer was just left waiting for it to appear on the mirrors which
> would have never happened.
>
> /peter


I'm sure Philip is doing the best he could under a heavy workload.


I'm more concerned that the failed batching process:

	a) failed because of checks that should have been done much earlier in 
the process.

	b) left the web pages in an inaccurate and inconsistent state.


John

From jcraig at opencsw.org  Fri Jun 24 17:30:00 2011
From: jcraig at opencsw.org (Jonathan Craig)
Date: Fri, 24 Jun 2011 11:30:00 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
Message-ID: <BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>

On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown <phil at bolthole.com> wrote:
>
> Sorry that this is long: however, people complain when I break things
> up into smaller emails also, so it's a lose-lose situation no matter
> what I do.

Yes, we know you are a misunderstood hero.
> 1. Amendment: more technical details need to be given.
> ?(perhaps as a side referenced document)
> ?The proposal suggests that opencsw adopt a "new system", without
> *fully* *defining* this new system at a technical level. There are
> some technical specifics, but not full coverage.
> ?There is a lot of [will do, in the future] language without giving specifics.
> ?OpenCSW is supposed to be a technical organization. It seems to me
> that we should be voting on specific full technical implementations,
> rather than something with fuzzy chunks in it

First, this isn't an amendment its a complaint.  An amendment would be
to start producing the technical details not lament their absence.
This is a volunteer organization and not a fortune 100 conglomerate
who can afford to pour millions into development of supporting systems
like this.  This aspect of OpenCSW is a sideshow for what the
organization is all about, namely turning out packages for end users.
To suggest that something be fully spec'd out and voted upon is to
declare "let's do nothing" as nobody has that kind of time or interest
(IMHO).  This amounts to a stalling tactic designed to paralyze
progress.


>
> 2. Amendment: Removal of "Anyone can participate[in the new process]",
> and related lines.
> This line falsely implies that currently, people are somehow blocked
> from participating now.
> This is untrue, both at the direct package level and at the discussion
> level, as shown below. Therefore this red herring should be removed.
> (and possibly, maintainers should be re-informed of some facts):
>
> ? At the discussion level, all packages "held" from release, are
> discussed in the pkgsubmissions mail list.
> ? Right now, "anyone can participate" in the discussion of a held package.
>
> ?At the direct package participation level:
> ? If a maintainer chooses to have their packages examined/tested
> before pushing them out to the general public, they can already drop
> them in "experimental" and ask that people look at them before
> publicly pushing them out to newpkgs.
>
> ?The fact that others rarely choose look at them now when a
> maintainer requests feedback, is not a failure of the current system,
> but rather an indication that maintainers rarely choose to look at
> other people's packages. It is doubtful that a wholesale "new system"
> will change that.
>
> If people rarely even look at packages when a maintainer *specifically
> requests* feedback, it seems less likely when the whole thing is
> automated and there is no explicit request to do so.
>

What is troubling is that one all powerful being gets to arbitrarily
block someone progress and force them to beg for support and
understanding.  As to participation, it is already stated that a third
party (you if you care to) can file a bug and seek changes prior to
publication.  You may always appeal closed bugs on the list if you
feel a maintainer is abusing their maintainer power.  If a maintainer
is uncooperative and releases poor packages this will be born out in
the bug tracker.  If the current bug tracker is too cumbersome then
maybe we should look at another, such as Jira.

>
> 3. Removal or adjustment of "Packages are subject to stalls or
> rejections for non-policy reasons."
>
> First of all, it implies, FALSELY, that a package can be completely
> rejected by the release manager with no recourse. As formalized in
> http://wiki.opencsw.org/release-manager , a maintainer can always call
> for a vote if they disagree with the stance that the release manager
> has taken. This has already happened, twice, and after the vote, the
> package(s) were released, so it is a proven effective method.
>
> Additionally, it does not recognize the benefit that policy is not and
> should not be set in stone for all time. If a release manager holds a
> package, for reasons that are not currently policy, but perhaps should
> be, then it is a good thing that discussion take place. Similarly, it
> is actually a good thing if the issue gets forced to a vote, because
> that way, policy can be officially adjusted, as the majority vote
> decides.
>

Automation doesn't fix policy for all time as it can grow and change
along with our understanding.  What it does is force policies to be
codified and enforced by an inanimate process without the ability to
adjust policy on a whim.

> 4. Removal of "All code, tools and documentation will available for
> all to see and improve."
> ?This falsely implies that there is "hidden code and/or tools". There is not.
> ?All code that is actually necessary for the release process is
> already completely public and published.
> ?Most other stuff isnt strictly "published", but is readable by any
> maintainer who actually cares, in my home
> ?directory on bender. It isnt much more than convenient aliases,etc. I
> have, akin to aliases in a .bashrc, etc.
>
> The release process as a whole has been fully documented also.
> If anyone cares to dispute this, then please point out specific areas
> or tools that either lack documentation, or are hidden. ? I have
> previously requested this, when this claim was made recently, but was
> only met with groundless mumblings that things were still somehow
> "hidden", without any specifics given.

This is simply defensive.  I don't care if its fully documented my
experience leads me to believe that an automated approach will be less
frustrating and more deterministic.  I want the comfort of having my
package pass all known tests and flowing through without me wondering
whether I've forgotten something.  The more this relies on human
interaction the less likely it will be that the automated checks will
be put in place to help me turn out more packages quicker with better
quality.

> 5. Removal of "unclear path to resolution of disputes" claim.
> ?There is actually a clear path:
> ?discussion on pkgsubmissions list -> discussion on maintainers list
> -> vote if needed.
> ?As far as complexity, this is virtually identical to the "new" path
> to resolution. The main difference is only that under the current
> system, a package deemed as "bad" will never be released, whereas
> under the "new" system, a package deemed as "bad" will first be
> released publically, but then after some indeterminate length of
> time.. potentially a **month or more**.. eventually be retracted.

Yes, the process begins with a public flogging that feels like a "oh,
you dumb shit you forgot" even when that wasn't the message intended.
When a piece of code tells me I cant submit a package that is
uncommitted, I say, "Oh doh, I knew that" and fix it.  When it gets
posted to everyone for all time, I get frustrated.

>
> 6. Removal or adjustment of "All participants will have equal standing".
> ?It would actually be harmful to opencsw to follow that sentiment
> completely. Specifically, to have two new maintainers sign off on each
> others packages, will inevitably lead to some mistakes that could be
> avoided by the oversight of more experienced maintainers.
>

You can't have both sides of an argument unless your talking to
yourself in a closet.  You are both for full classless participation
in a democratic process and then argue unless its two neophytes
colluding to avoid doing the right thing.  This is hardly a serious
concern and the damage would be limited, IMHO.

>
>
> 7. A technical implementation issue, that is not properly addressed in
> the proposal:
>
> There is no such thing as a *fully* automated release system: at some
> point, issues come up that require manual intervention. For example,
> package renames, and removals. or fixing bugs in some unforseen
> interaction of the system and a new package.
>
> The proposal declares that catalog signatures will be generated
> automatically. However, who or what group will be responsible to
> manage the catalog when the automated system is either inadequate, or
> fails?

Closest thing to a constructive request so far.  This is of course
voiced as a complaint instead of a fully formed and documented
solution.  I agree given the dynamics involved a group of SME's will
need to be responsible for arbitrating breakdowns and enhancing the
automation to accommodate future recurrences.

"A group of subject matter experts will be established to support and
maintain the release system.  This group will be subordinate to the
board and responsible for seeing that packaging policy to properly
enforced by the release systems.  In the event an unforeseen issue
disrupts the release process they are empowered to manually augment
the system to enable timely release of packages.  Such manual
intervention will be logged with the understanding that repeated
manual intervention will require enhancements to the release system to
accommodate routine exceptions."

I think most would have thought that something like this was inherent
to any automated solution, but it doesn't hurt to write a little
verbage to outline expectations.

>
> 8. A technical implementation issue not addressed at all in the proposal:
> What about package takeovers? is it going to be allowable for any
> maintainer to take over any package, at any time? or remove any
> package at any time?
>

Agreed, any release mechanism must have a method to accommodate
package takeovers.  It should do so in a manner consistent with
published policy.  Again, I see the complaint but no solution.  That
is of course unless your implying that a human release manager can
handle this bit of nastiness as they see fit.  Personally, having a
clear process for taking over a package and an automated solution to
enable "proper" takeover is better than doing this in the darkness of
night.

> 9. A technical implementation issue not addressed at all in the proposal:
>
> "A package may not progress from unstable to current with open bugs."
>
> It has been written elsewhere, that this progress will be automated,
> after (2 weeks time).
> However, what about the problem when two new upgrades are released
> together, as follows:
> ?libA1(.1) upgrades libA1(.0)
> ?libB1(.1) upgrades libB1(.0), and depends on libA1. It FAILS if run
> against the older libA1.0
> [ I am using the (.1, .0) syntax above, to indicate minor rev changes
> to the hypothetical libraries, where the SONAME does not change. ]
>
> ?A bug is filed against libA1(.1)
> ? The bug is not addressed within 2 weeks. (lets say the bug is filed
> on the 13th day)
> However, libB1(.1) has no bugs filed. It then gets auto-migrated to
> current. Where it will then be non-functional,
> and break everything depending on "libB1"
>
> I have used the example of shared libraries here, but the problem is
> generic, for any time that two packages are pending migration from
> unstable to current at the same time, with one dependent on the other.
> It could well be that they are from completely diferent maintainers.
> maintainer A, releases libA1 update to unstable. a day or two later,
> maintainer B updates libB1 based on that update, and releases libB1 to
> unstable. 12 days later, libA1 is blocked from release to current, but
> libB1 will sail through 2 days later.
>
> Note that this is particularly important when someone decides to do a
> "complicated" upgrade set that has 10, 20, 30 or more packages
>

This may prove too complicated to code and we might throw our hands in
the air and give up.  Or, someone may see this as an interesting
dilemma and work on a process and some code to handle this kind of
dependency.  It would be nice if the maintainer could code these
dependency into their submit and see that its handled to their wishes.
 That puts the maintainer in the drivers seat, where the
responsibility belongs.

>
> 10. technical implementation suggestion:
>
> If the goal is to make it *easier* for people to get involved in the
> QA process, I would suggest that either a different mechanism than bug
> filing be used, OR an alternative interface to the bug system be
> provided.
> I personally feel that the existing "exchange emails over the
> pkgsubmissions mailing list" is the smallest pain point in this sort
> of process.
> Forcing people to move to (our existing) bug system for this kind of
> discussion, makes it *more* difficult, not easier, to be involved in
> QA, in my opinion. It's possible other bug systems would do better;
> I'm just limiting my comments to our existing one.

Ah, but the bug system keeps the conversation on point.  In a mail
list an email is likely to get hijacked into a different directions
when you begin a philosophical debate over which approach is "best".
That is less likely to happen in the context of  a bug report as the
writer is conscious of the fact that this is all being filed against a
specific instance.  And the original maintainer may not even care
about the philosophical differences they simply need to get a package
published so they can get some other (possibly paid) work done.  Like
me, I build packages that by paying job needs, Not because packaging
applications is "Fun!".

>
> 11. technical implementation issue:
>
> ?"By opening up the QA process such that multiple people can easily
> participate and have equal standing on the matters at hand, we feel
> that overall package quality will improve;"
>
> Unfortunately, (as mentioned on maintainers list previously), making
> the capability available, does not actually mean that people will
> definitely make use of it.
> The new proposal as prototyped, currently allows for LESS people to
> scrutinize a package than currently.

Bullshit, it is your conjecture that apathy will rain and reduce
involvement beyond the current level.  If you choose to review and
file bugs on every application that releases then it has the same
level of critique.  If you can get one other person to do the same (oh
and by the way they cant today) then it doubles.

> At the moment, a release manager is guaranteed to at least glance at
> it. Whereas with the "new process", a package may (and I claim, will
> *usually*) get released with no-one but the maintainer ever looking at
> it.

I glance at every release already, then I mark the email "read" unless
its a package that holds interest to me.


>
> If the goal is truly, "more/better QA", then a proposed remedy for
> this, is to put in mandatory hooks for the "migrate from unstable to
> current" step, to require that at least one other person besides
> maintainer has examined the package.
>

The automated system does allows for more/better QA as indicated
above.  If quality suffers then we can look at this enforcement.  So
far its not a policy of the organization and I doubt you would get
much support for making it policy absent some reoccurring issue.


> If on the other hand, the goal is really "to allow packages to be
> released with no one but the maintainer ever looking at it", then all
> claims about better QA should be removed from the proposal, and the
> stated "benefits" of the proposal should be updated to reflect that.

No the goal is to determine the problems and teach an automated system
to apply this to every package, all the time.  Not allow a handful (or
one) person to arbitrarily decide to "look into" a package and place
it on hold until their curiosity is satisfied.

I can afford to call shenanigans on your post as I'm simply a
maintainer of a handful of packages and at worst I'm risking a few
future packages enduring more scrutiny as a result.  I've been witness
to these types of attempts to derail any progress you don't believe
in.  Your collection of amendments boil down to a list of complaints
that point towards status quo.  Do we need a vote that simply and
plainly declares the organizations direction towards automated
systems?  I would think that the support the existing proposal has
would make this fairly clear, but maybe you need more.  If a vote is
required I guess we could do that but do you really think you have an
unvoiced constituency that will keep us on the path of a human centric
release process, or will this essentially be another 7 - 14 day
delaying tactic?

From phil at bolthole.com  Fri Jun 24 18:55:41 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 24 Jun 2011 09:55:41 -0700
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <4E04A8E2.1060602@opencsw.org>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
	<4E0495DC.2070508@opencsw.org>
	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>
	<BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>
	<BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>
	<BANLkTinFZxutH93bbitTEkYsgryp385zaQ@mail.gmail.com>
	<4E04A8E2.1060602@opencsw.org>
Message-ID: <BANLkTinOMjshyH00KTRe7xyy2-tW_cPMjA@mail.gmail.com>

On Fri, Jun 24, 2011 at 8:10 AM, John Ellson <ellson at opencsw.org> wrote:
>
> I'm more concerned that the failed batching process:
>
> ? ? ? ?a) failed because of checks that should have been done much earlier
> in the process.
>
> ? ? ? ?b) left the web pages in an inaccurate and inconsistent state.
>

yeah, it's "not pretty", registration wise.
theoretically, name collision checks should already have been handled by gar.
Just goes to show, that it's Not A Good Idea, to put 100% confidence
in a single automated process.
No process is 100% bug free. For QA purposes, it's a benefit to have 2
independant checks.

in smaller batches of 1 or two packages, it's easy for me to
re-register the "old" versions.
For this huge thing, it's a considerable chunk of work.
If there isnt going to be a quick (day or two) moving forward, then  I
will spend the time to de-rev the registrations. Otherwise, it seems
simplest for me to just wait for the update and push the batch
through.

Which way would you recommend we go?

From ellson at opencsw.org  Fri Jun 24 20:55:09 2011
From: ellson at opencsw.org (John Ellson)
Date: Fri, 24 Jun 2011 14:55:09 -0400
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <BANLkTinOMjshyH00KTRe7xyy2-tW_cPMjA@mail.gmail.com>
References: <4E03C388.2070207@opencsw.org>	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>	<4E03CB1B.9020408@opencsw.org>	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>	<4E0495DC.2070508@opencsw.org>	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>	<BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>	<BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>	<BANLkTinFZxutH93bbitTEkYsgryp385zaQ@mail.gmail.com>	<4E04A8E2.1060602@opencsw.org>
	<BANLkTinOMjshyH00KTRe7xyy2-tW_cPMjA@mail.gmail.com>
Message-ID: <4E04DD8D.7050109@opencsw.org>

On 06/24/2011 12:55 PM, Philip Brown wrote:
> On Fri, Jun 24, 2011 at 8:10 AM, John Ellson<ellson at opencsw.org>  wrote:
>> I'm more concerned that the failed batching process:
>>
>>         a) failed because of checks that should have been done much earlier
>> in the process.
>>
>>         b) left the web pages in an inaccurate and inconsistent state.
>>
> yeah, it's "not pretty", registration wise.
> theoretically, name collision checks should already have been handled by gar.
> Just goes to show, that it's Not A Good Idea, to put 100% confidence
> in a single automated process.
> No process is 100% bug free. For QA purposes, it's a benefit to have 2
> independant checks.
>
> in smaller batches of 1 or two packages, it's easy for me to
> re-register the "old" versions.
> For this huge thing, it's a considerable chunk of work.
> If there isnt going to be a quick (day or two) moving forward, then  I
> will spend the time to de-rev the registrations. Otherwise, it seems
> simplest for me to just wait for the update and push the batch
> through.
>
> Which way would you recommend we go?
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
I'm assuming that the ImageMagic fix is small and that we should have a 
new set of packages in a few days, but Dago didn't say when he was going 
to be back.

I'm not even so worried about the web pages on this occasion.   It just 
seems to me that some scripts need to be fixed so that web updates are 
atomic and only happen if batching is successful.

For this release of graphviz, I suggest just waiting a few days, and re 
batch.

Thanks

john

From phil at bolthole.com  Fri Jun 24 21:29:22 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 24 Jun 2011 12:29:22 -0700
Subject: [csw-maintainers] where is graphviz-2.28 ?
In-Reply-To: <4E04DD8D.7050109@opencsw.org>
References: <4E03C388.2070207@opencsw.org>
	<BANLkTinmio8xNndnb8mxHudR_ksj5Kb7jw@mail.gmail.com>
	<4E03CB1B.9020408@opencsw.org>
	<BANLkTik305hD_-yrMCJ8LEM+KXQUNQAdbA@mail.gmail.com>
	<4E0495DC.2070508@opencsw.org>
	<BANLkTim48g2QN_M-24x3SMOyXW+4Osumzg@mail.gmail.com>
	<BANLkTinjA5is=kcQv9ORM9pT0ih1b0Abow@mail.gmail.com>
	<BANLkTinp=+xi_4L0VS=SM1QRahnKkVT=hQ@mail.gmail.com>
	<BANLkTinFZxutH93bbitTEkYsgryp385zaQ@mail.gmail.com>
	<4E04A8E2.1060602@opencsw.org>
	<BANLkTinOMjshyH00KTRe7xyy2-tW_cPMjA@mail.gmail.com>
	<4E04DD8D.7050109@opencsw.org>
Message-ID: <BANLkTi=+vcmu3fEX2faCbwouik6tJmeYhg@mail.gmail.com>

On Fri, Jun 24, 2011 at 11:55 AM, John Ellson <ellson at opencsw.org> wrote:
>
> I'm assuming that the ImageMagic fix is small and that we should have a new
> set of packages in a few days, but Dago didn't say when he was going to be
> back.
>
> I'm not even so worried about the web pages on this occasion. ? It just
> seems to me that some scripts need to be fixed so that web updates are
> atomic and only happen if batching is successful.


Would be useful.
However, at my utility script level, there is unfortunately no concept
of a maintainer-grouped-batch at the moment.
There is only individual-package visibility.

As I said, this isnt a problem with smaller grouped packages, so there
isnt much incentive to write something fancier.
I could in theory write something that would be more package-group
aware. However, it would probably involve a lot of saved state, and a
high (relative) degree of inner complexity. Which would mean high
likelyhood of bugs.
My gut level risk/reward analyzer suggests it would probably end up
causing more problems than it would solve.

> For this release of graphviz, I suggest just waiting a few days, and re batch.

okie dokie. just give me a nudge :)

From phil at bolthole.com  Sat Jun 25 00:42:22 2011
From: phil at bolthole.com (Philip Brown)
Date: Fri, 24 Jun 2011 15:42:22 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
Message-ID: <BANLkTimcCoqjh6YM3tR68kvEXxfXfebOrw@mail.gmail.com>

On Fri, Jun 24, 2011 at 8:30 AM, Jonathan Craig <jcraig at opencsw.org> wrote:
> On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown <phil at bolthole.com> wrote:
>....
> Ah, but the bug system keeps the conversation on point. ?In a mail
> list an email is likely to get hijacked into a different directions
> when you begin a philosophical debate over which approach is "best".
> That is less likely to happen in the context of ?a bug report as the
> writer is conscious of the fact that this is all being filed against a
> specific instance. ?And the original maintainer may not even care
> about the philosophical differences they simply need to get a package
> published so they can get some other (possibly paid) work done.

Your reply about motivations, actually aligns with what I'm trying to highlight.
A person who "just wants to get a package published", and doesnt care
about the finer points of issues... well.. doesnt care.  They "just
want to get it published" as quickly as possble, without necessarily
looking at whether it meshes well with opencsw as a whole.
It is  beneficial to overall opencsw package quality and consistency,
that someone else, with an objective eye also looks at the package.


>> 11. technical implementation issue:
>>
>> ?"By opening up the QA process such that multiple people can easily
>> participate and have equal standing on the matters at hand, we feel
>> that overall package quality will improve;"
>>[...]
>
>> At the moment, a release manager is guaranteed to at least glance at
>> it. Whereas with the "new process", a package may (and I claim, will
>> *usually*) get released with no-one but the maintainer ever looking at
>> it.
>
> I glance at every release already, then I mark the email "read" unless
> its a package that holds interest to me.

It seems you are saying that you "look at the pkgsubmissions mailing
list already".
But that is missing the point of what I'm bringing up in this issue.
How many times do you actually look at the package directly?
I would guess very rarely.
Do some experimental math for a moment.
think of how many times you actually look at a package, compared to
how many are released.
Then compare to how many active maintainers we have. We'll charitably
assume that they look at "someone else's package" with the same
frequency that you do.
add up (number of maintainers) * ( number of other packages looked at /year)

Then compare that number to the total number of packages *released*
every year (we've released 754 this year so far. that does not count
upgrades to same package, so probably 800), and maybe you'll realize
then just how many packages we can reasonably predict that no-one but
the maintainer will ever look at, if they do it on an "if I'm
interested" basis.


> The automated system does allows for more/better QA as indicated
> above. ?If quality suffers then we can look at this enforcement.

If no-one is LOOKING at organization-wide quality, then no-one will
realize that quality is suffering.
If you're making the assumption "if something is wrong, someone will
file a bug", unfortunately that is not true.
A package can have very bad bugs,and still no-one may report it for a
long time. Hopefully, some of the other long time maintainers will
back me up on this, if they are reading.
"no bugs filed" does not neccessarily mean "no one wants that
software". It often means "they chose to get it from someplace else,
that works, instead"



Also, once quality of a "product" suffers below some point...
"customers" tend to go elsewhere. irreversibly.
So an attitude of "well if it makes a mess, we can always fix it
later", can cause harm to the overall popularity of opencsw long term.


>> If on the other hand, the goal is really "to allow packages to be
>> released with no one but the maintainer ever looking at it", then all
>> claims about better QA should be removed from the proposal, and the
>> stated "benefits" of the proposal should be updated to reflect that.
>
> No the goal is to determine the problems and teach an automated system
> to apply this to every package, all the time.

you say "no" to start, but?the rest of your post seems to resonate
strongly with an actual practice of
([you] just want to get your packaged out there, with automated checks
only, as fast as possible. Without being hindered by 2nd party checks
on it)

If so, fine, that's your opinion and wish. I believe it is the wish of
some other maintainers also. If that's' what the majority of voters
want, so be it.  I'm just saying lets be honest about what we're
voting for.

From jcraig at opencsw.org  Sat Jun 25 02:52:09 2011
From: jcraig at opencsw.org (Jonathan Craig)
Date: Fri, 24 Jun 2011 20:52:09 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTimcCoqjh6YM3tR68kvEXxfXfebOrw@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<BANLkTimcCoqjh6YM3tR68kvEXxfXfebOrw@mail.gmail.com>
Message-ID: <BANLkTi=J-jCbPtTL8x3NZU5SCErq0rhrOw@mail.gmail.com>

On Fri, Jun 24, 2011 at 6:42 PM, Philip Brown <phil at bolthole.com> wrote:
> On Fri, Jun 24, 2011 at 8:30 AM, Jonathan Craig <jcraig at opencsw.org> wrote:
>> On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown <phil at bolthole.com> wrote:
>>....
> Your reply about motivations, actually aligns with what I'm trying to highlight.
> A person who "just wants to get a package published", and doesnt care
> about the finer points of issues... well.. doesnt care. ?They "just
> want to get it published" as quickly as possble, without necessarily
> looking at whether it meshes well with opencsw as a whole.
> It is ?beneficial to overall opencsw package quality and consistency,
> that someone else, with an objective eye also looks at the package.
>
>

That the reality of volunteer maintainers.  I pay attention to what I
have time to pay attention which is not the same as being unconcerned
with quality.  I'm not just flopping out my own packages, I'm trying
to use the tools and documentation to turn out the best package I can.
 For me better tools that provide "code coverage" and better
documentation is what I need.

>>> 11. technical implementation issue:
>>>
>>> ?"By opening up the QA process such that multiple people can easily
>>> participate and have equal standing on the matters at hand, we feel
>>> that overall package quality will improve;"
>>>[...]
>>
>>> At the moment, a release manager is guaranteed to at least glance at
>>> it. Whereas with the "new process", a package may (and I claim, will
>>> *usually*) get released with no-one but the maintainer ever looking at
>>> it.
>>
>> I glance at every release already, then I mark the email "read" unless
>> its a package that holds interest to me.
>
> It seems you are saying that you "look at the pkgsubmissions mailing
> list already".
> But that is missing the point of what I'm bringing up in this issue.
> How many times do you actually look at the package directly?
> I would guess very rarely.
> Do some experimental math for a moment.
> think of how many times you actually look at a package, compared to
> how many are released.
> Then compare to how many active maintainers we have. We'll charitably
> assume that they look at "someone else's package" with the same
> frequency that you do.
> add up (number of maintainers) * ( number of other packages looked at /year)
>

Ah, but the reality is that I pay greater attention to list emails
that are associated with bug reports.  Thats were I really feel I can
learn something.  Package submissions are only of interest if the
package is of interest.  When I look at others packages its usually
because I'm trying to determine how they've solved a similar packaging
issue in the past.

>
>
>> The automated system does allows for more/better QA as indicated
>> above. ?If quality suffers then we can look at this enforcement.
>
> If no-one is LOOKING at organization-wide quality, then no-one will
> realize that quality is suffering.
> If you're making the assumption "if something is wrong, someone will
> file a bug", unfortunately that is not true.
> A package can have very bad bugs,and still no-one may report it for a
> long time. Hopefully, some of the other long time maintainers will
> back me up on this, if they are reading.
> "no bugs filed" does not neccessarily mean "no one wants that
> software". It often means "they chose to get it from someplace else,
> that works, instead"

If you lose your maintainer group because the process of publication
is too cumbersome then you end up with no packages.  Lack of new and
updated packages will drive away customers even faster in my opinion.

>
> Also, once quality of a "product" suffers below some point...
> "customers" tend to go elsewhere. irreversibly.
> So an attitude of "well if it makes a mess, we can always fix it
> later", can cause harm to the overall popularity of opencsw long term.
>

I have no reason to believe that the core of maintainers would let
things fall that far or the belief that enforced human inspection
would prevent it.


>>> If on the other hand, the goal is really "to allow packages to be
>>> released with no one but the maintainer ever looking at it", then all
>>> claims about better QA should be removed from the proposal, and the
>>> stated "benefits" of the proposal should be updated to reflect that.
>>
>> No the goal is to determine the problems and teach an automated system
>> to apply this to every package, all the time.
>
> you say "no" to start, but?the rest of your post seems to resonate
> strongly with an actual practice of
> ([you] just want to get your packaged out there, with automated checks
> only, as fast as possible. Without being hindered by 2nd party checks
> on it)

You seem to continuously ignore the reality that the proposed process
allows anyone to review any package and seek corrections prior to
publication.  IMO, this is a form of intellectual dishonesty.  You
haven't said it but from your posts I can only assume that if you
can't be the "human" in human centric then you have no wish to
participate.  You can provide the same level of human oversight of the
current system in the proposed solution.  The only difference is you
need to do it as a customer of the package maintainer instead of lord
and master.

As to human vs automated processes you are ignoring that an automated
process can apply the same level of scrutiny to every package
regardless of the number submitted.  Further, the process of teaching
the system to check our packages provides a great deal of insight into
how to improve the overall process.  Much more so than a single
individual eye balling a subset and then one-off resolving problems
with a couple of keystrokes.

>
> If so, fine, that's your opinion and wish. I believe it is the wish of
> some other maintainers also. If that's' what the majority of voters
> want, so be it. ?I'm just saying lets be honest about what we're
> voting for.

Your implying others haven't been honest in their portrayal of the
desired solution, while I submit you could be accused of this very
thing.  I've never said that manual inspection isn't beneficial I'm
simply arguing that a subjective inspection by a small group (or one
individual) shouldn't be a gate in the production of new packages.
Reading your email I've only seen a mild attack on my motives and an
empty complaint that the new system inhibits one's ability to critique
submitted packages.  As to support for status quo vs an automated
system I've yet to see any support beyond yourself for the status quo.
 At some point you will need to come to grips with the proposed change
an either embrace it or move on.  If you can't be vested in developing
a better automated process then I fear you will be marginalized and
left in the past.  Another victim of progress much like those who once
made buggy whips and rail against the noisy new fangled contraptions
called cars.

Again, do you honestly believe that there is insufficient support for
moving forward with an automated approach.  Once we determine this
direction, and I feel its been determined, the rest can fall into
place with all parties vested in achieving the same goal.

From rupert at opencsw.org  Sat Jun 25 12:58:12 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 25 Jun 2011 12:58:12 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>

i see, you are of course right. lets tackle it stepwise thought.

currently gar is syncronised manually on git and hg. lets assume we would
extend this experiment a little bit, deciding for the moment onto git. what
i would miss currently are two things:

1.  a short description how i set up my environment so i can deliver, say
mercurial. currently i do check out the whole mgar tree, the externals are
replaced with symbolic links. what would be the best approach if gar is in
git?

cd ~
pkg=mercurial
mkdir git-experiment
cd git-experiment
git clone https://rthurner at github.com/opencsw/gar.git gar
git svn clone
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg}
ln -s ${pkg}/trunk/gar gar

2. how would i create a new package stub using git?


rupert


On Mon, Jun 20, 2011 at 03:27, Ben Walton <bwalton at opencsw.org> wrote:

> Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011:
>
> Hi Rupert,
>
> > as an experiment, i tried to convert the subversion gar repository to git
> > and mercurial:
> >  * http://code.google.com/p/gar/ (hg)
> >  * https://github.com/opencsw/gar (git)
>
> I like this! :)  I'm not keen on mercurial given my exposure to it,
> but anything distributed would be a step up.
>
> > what i am not sure is how to handle externals and patches onto them,
> > but i saw posts like:
> > *
> >
> http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment
>
> > what do you think, in general about a conversion, and in special,
> > how to do this patching?
>
> I'm not sure what you mean by 'patches onto them' but basically,
> submodules suck for our use case, in my estimation.  They're excellent
> in projects where you're pulling in external code as a source library.
> The most common example I see is that many projects have gnulib as a
> submodule.  When they're polishing a new release, they update the
> gnulib submodule to current as part of that process.  They won't work
> nicely in our pkg/$foo/trunk setup though as we'd be constantly
> required to update the sha1 reference to the submodule for every
> recipe change.
>
> As Sebastian mentioned, we can (and should!) do away with externals
> and, if they're still in use, the old garlinks in favour of the new
> mgar wrapper.
>
> If we did this, we could (as long as Sebastian is on board), merge
> mgar directly into the gar/v2 git repository and release an actual
> package for it.  mgar is packaged now, but it could be extended to
> deliver the rest of the gar code with it.
>
> The impact of this would be that people would be forced to use mgar to
> interact with gar (or create their own new frankenstein) and people
> would need to learn/use git.  Many of us are already using git where
> possible, so that's not likely a big hurdle.  Using mgar is a positive
> experience and doesn't change workflow much beyond s/(svn|gmake)/mgar/
> now.
>
> Gar would have a package and we could still have a devel mode for gar
> where the local git (or hg) repo is tracked against the head of the
> main branch.  Good for users, good for devs.
>
> This might be a nice test of the waters for a move away from svn
> instead of attempting to move gar and all of the recipes in one shot.
>
> Is anyone else excited by this idea?
>
> 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. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110625/7bb188a6/attachment.html>

From maciej at opencsw.org  Sat Jun 25 13:11:20 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 25 Jun 2011 12:11:20 +0100
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
Message-ID: <BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>

2011/6/13 Philip Brown <phil at bolthole.com>:
> 2011/6/13 Maciej Blizi?ski <maciej at opencsw.org>:
>> 2011/6/11 Philip Brown <phil at bolthole.com>:
>>
>>> (...)
>>> If anything, this incident shows *more strongly*, the benefit of
>>> having at least 2 humans carefully look at a package before release.
>>>
>>> The "new system" does not in any way ensure that.
>>
>> I expect that your position can be described as "the release manager
>> position ensures that packages are always examined".
>
> yes.
>
>
>> Our aim is to build a culture in which peer review is one of the key
>> elements. ?There needs to be an environment which encourages peer
>> reviews and makes them easy.
>>....
>
> you took the time to write a lot of things in your email. Thank you.
> However, ?while the things you wrote were "good", and "true"... they
> still did not concretely address the issue :(

I'm still unsure about your use of quotes or scare quotes, when you
quote the word good, which of the three you mean:

- something somebody else said that you quote here
- the literal: g, o, o, d
- not good

> I think the rest of what you wrote, can be summed up, with a minor
> insert, as follows:
>
>> It is important that the senior members of the project actively
>> participate in code and package reviews, serving as a good example to
>> more junior members.
>> [ So we **hope** that people will review packages]
>
> This is exactly the problem that I see.
> There have been a few people complaining about "lack of consistency"
> with the current release process.
> But how is a release strategy built around "hope", more consistent????

Let's consider three separate issues:

1. Package review
2. Policy development
3. Policy enforcement

The inconsistency that the proposal refers to, and attempts to
improve, is in point 3 above.  It seems to me that in your paragraph
above, you refer to point 1.

How would you define consistency in the context of a human examining a
svr4 file?

>> While this strategy does not claim to "ensure that X number of humans
>> will always do Y", it addresses the underlying issue of getting people
>> involved in the release process and quality assurance through peer
>> review.
>
> It does not seem like it _adequately_ addresses the issue.
> Providing people an optional mechanism to improve quality, does not
> mean they will use it. "consistently".
> Providing people an optional mechanism to "get involved", does not
> mean they *will* get involved.
>
> Some people.. including *you* Maciej... keep pressing the claims that
> everything should be automated, for "consistency".
> So why are you not automating a 2nd party validation check?

Do you have any specific solution in mind?  How would it work?

Maciej

From maciej at opencsw.org  Sat Jun 25 13:47:45 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 25 Jun 2011 12:47:45 +0100
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
Message-ID: <BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>

I've received a complaint for mixing technical and non-technical
issues in one email.  Sorry about that.  Here's the amended version of
the email.

2011/6/13 Philip Brown <phil at bolthole.com>:
> I think the rest of what you wrote, can be summed up, with a minor
> insert, as follows:
>
>> It is important that the senior members of the project actively
>> participate in code and package reviews, serving as a good example to
>> more junior members.
>> [ So we **hope** that people will review packages]
>
> This is exactly the problem that I see.
> There have been a few people complaining about "lack of consistency"
> with the current release process.
> But how is a release strategy built around "hope", more consistent????

Let's consider three separate issues:

1. Package review
2. Policy development
3. Policy enforcement

The inconsistency that the proposal refers to, and attempts to
improve, is in point 3 above. ?It seems to me that in your paragraph
above, you refer to point 1.

How would you define consistency in the context of a human examining a
svr4 file?

>> While this strategy does not claim to "ensure that X number of humans
>> will always do Y", it addresses the underlying issue of getting people
>> involved in the release process and quality assurance through peer
>> review.
>
> It does not seem like it _adequately_ addresses the issue.
> Providing people an optional mechanism to improve quality, does not
> mean they will use it. "consistently".
> Providing people an optional mechanism to "get involved", does not
> mean they *will* get involved.
>
> Some people.. including *you* Maciej... keep pressing the claims that
> everything should be automated, for "consistency".
> So why are you not automating a 2nd party validation check?

Do you have any specific solution in mind? ?How would it work?

Maciej

From bwalton at opencsw.org  Sat Jun 25 15:24:52 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 25 Jun 2011 09:24:52 -0400
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
Message-ID: <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sat Jun 25 06:58:12 -0400 2011:

Hi Rupert,

> 1.  a short description how i set up my environment so i can
> deliver, say mercurial. currently i do check out the whole mgar
> tree, the externals are replaced with symbolic links. what would be
> the best approach if gar is in git?
> 
> cd ~
> pkg=mercurial
> mkdir git-experiment
> cd git-experiment
> git clone https://rthurner at github.com/opencsw/gar.git gar
> git svn clone
> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg}
> ln -s ${pkg}/trunk/gar gar

I think this would become:

mgar init (maybe re-init to help with svn -> git)

That would wrap the two steps that it currently does which are:
svn co gar/mgar -> ~/opencsw/.builsys/
svn co gar/pkg -> ~/opencsw/

Replacing them with:
git clone gar/mgar -> ...
svn co gar/pkg -> ...

You would then use mgar as you currently do (or if you're still doing
the svn/gmake manually, those would remain the same for the time
being.

> 2. how would i create a new package stub using git?

This would (assuming we only use git/hg for that gar code and not the
whole package tree) be the same.  You'd do:

cd ~/opencsw
gmake newpkg-foo

The whole idea of transitioning the gar code to something other than
svn is made immensely easier by having it wrapped in mgar.

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


From bwalton at opencsw.org  Sat Jun 25 15:46:44 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 25 Jun 2011 09:46:44 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
Message-ID: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>

Excerpts from Jonathan Craig's message of Fri Jun 24 11:30:00 -0400 2011:

Hi Jonathan,

Thanks for writing such a well thought out response.  I think it
sounds better when it comes from a 'new' voice.  I agree with your
main points and have snipped out anything that you've covered
adequately.  The remainder of this mail deals with the useful items
you've pulled out.

> "A group of subject matter experts will be established to support
> and maintain the release system.  This group will be subordinate to
> the board and responsible for seeing that packaging policy to
> properly enforced by the release systems.  In the event an
> unforeseen issue disrupts the release process they are empowered to
> manually augment the system to enable timely release of packages.
> Such manual intervention will be logged with the understanding that
> repeated manual intervention will require enhancements to the
> release system to accommodate routine exceptions."

I agree with what you say here.  An automated process does not imply a
people-free process.  The tools will evolve and improve over time.  It
will be people that drive the changes.

This would be a good overall change to the proposal and I would
support something like this.  The key points for me are that 'group
will be established' must be defined to allow anyone interested to
participate.  It should not exclude anyone that wants to extend effort
toward making things flow and improving the tools.  It should not by
default give one or two maintainers more power than others.  We'd need
something that encourages more people to become SME's or at the very
least doesn't discourage them.  Setting hard barriers of any sort in
place would be counter to the goals of the new system.

[I can see that you understand this fully, I just want my rationale
here to be crystal clear.]

> I think most would have thought that something like this was
> inherent to any automated solution, but it doesn't hurt to write a
> little verbage to outline expectations.

Agreed.  This comment is well thought out and helpful.  If you'd like
to polish your statement above, I think that it fits well with the
proposal as currently written.  Although I won't speak for the other
signers, I think it would meet with acceptance.

Alternately, as most everyone understands this implicitly it may not
be required.

> handle this bit of nastiness as they see fit.  Personally, having a
> clear process for taking over a package and an automated solution to
> enable "proper" takeover is better than doing this in the darkness
> of night.

Agreed.  This is a tools implementing policy issue.

> dependency.  It would be nice if the maintainer could code these
> dependency into their submit and see that its handled to their
> wishes.  That puts the maintainer in the drivers seat, where the
> responsibility belongs.

I actually had a similar thought earlier today when reading the
graphviz thread.  If we supplied a cswdepend file that held REV= info
in addition to the package name, our tools could look at that and make
smarter choices.  This could allow for mypkg requires yourpkg with
version >= %Y%m%d.  (There are a lot of details in something like this
and it doesn't belong in this thread...)

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


From rupert at opencsw.org  Sat Jun 25 16:50:20 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sat, 25 Jun 2011 16:50:20 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>

On Sat, Jun 25, 2011 at 15:24, Ben Walton <bwalton at opencsw.org> wrote:

> Excerpts from rupert THURNER's message of Sat Jun 25 06:58:12 -0400 2011:
>
> Hi Rupert,
>
> > 1.  a short description how i set up my environment so i can
> > deliver, say mercurial. currently i do check out the whole mgar
> > tree, the externals are replaced with symbolic links. what would be
> > the best approach if gar is in git?
> >
> > cd ~
> > pkg=mercurial
> > mkdir git-experiment
> > cd git-experiment
> > git clone https://rthurner at github.com/opencsw/gar.git gar
> > git svn clone
> > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg}
> > ln -s ${pkg}/trunk/gar gar
>
> I think this would become:
>
> mgar init (maybe re-init to help with svn -> git)
>
>
this seems not to work yet ...

rupert at login:~/git-ben
$ mgar init mercurial
-bash: mgar: command not found

rupert at unstable9s:~/git-ben
$ mgar
bash: mgar: command not found


That would wrap the two steps that it currently does which are:
> svn co gar/mgar -> ~/opencsw/.builsys/
> svn co gar/pkg -> ~/opencsw/
>
> Replacing them with:
> git clone gar/mgar -> ...
> svn co gar/pkg -> ...
>
> You would then use mgar as you currently do (or if you're still doing
> the svn/gmake manually, those would remain the same for the time
> being.
>
> > 2. how would i create a new package stub using git?
>
> This would (assuming we only use git/hg for that gar code and not the
> whole package tree) be the same.  You'd do:
>
> cd ~/opencsw
> gmake newpkg-foo
>
> The whole idea of transitioning the gar code to something other than
> svn is made immensely easier by having it wrapped in mgar.
>
> i created, as experiment, https://github.com/opencsw/mercurial, and i
tried to write a description which one could execute with the existing
buildserver installation.  would this be ok like this:
https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw
 ?


rupert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110625/d9ca419f/attachment.html>

From bwalton at opencsw.org  Sat Jun 25 17:01:59 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 25 Jun 2011 11:01:59 -0400
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
Message-ID: <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>

Excerpts from rupert THURNER's message of Sat Jun 25 10:50:20 -0400 2011:

Hi Rupert,

> > mgar init (maybe re-init to help with svn -> git)
> >
> >
> this seems not to work yet ...
> 
> rupert at login:~/git-ben
> $ mgar init mercurial
> -bash: mgar: command not found

There are two problems here.

1. You likely don't have CSWmgar installed.
2. The mgar tool will need to learn how to checkout the git repo
   instead of the svn repo.

It was a "hypothetically this would become."  Sebastian would have the
best idea of how easy something like this would be to implement.

> > i created, as experiment, https://github.com/opencsw/mercurial,
> and i tried to write a description which one could execute with the
> existing buildserver installation.  would this be ok like this:
> https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw
> ?

I don't have time for a full review now, but this would raise an
interesting issue.  Currently we have one big repository for every
package.  What you've detailed here would see a separate repository
for each package description.  I can see pros and cons to this and
will outline some of them later[1]

I think a big consideration will be performance.  While subversion
_really_ sucks when working on the whole tree, git will (almost)
always work on the whole tree as it doesn't have the notion of
checking out bits and pieces of a repository like svn doesn (this
would hold for hg too, iiuc).  Git is inherently faster than svn but
it may still be slow to work with the whole tree...

Thanks
-Ben

[1] It's my son's birthday party today soI'll be more offline than on.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Sat Jun 25 19:16:59 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 25 Jun 2011 18:16:59 +0100
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
	<1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>
	<1307324723-sup-7673@pinkfloyd.chass.utoronto.ca>
	<1308277170-sup-1017@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinKiKRkSztzEpRNpJf01cb7r6dk7w@mail.gmail.com>

2011/6/17 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Ben Walton's message of Sun Jun 05 21:47:43 -0400 2011:
>
>> No, the request is fine and I don't mind waiting a week as you
>> suggest. ?I'm just saying that we shouldn't let orphaned packages[1]
>> impede work on things that people do actively care about.
>
> Ok, so anybody that wants to update nspr properly is now able to do so
> and mark it 'I' with CSWmozilla. ?When it's released, CSWmozilla
> should be dropped from the catalog.

A week has now passed.

I took a look at nspr today.  /opt/csw/share/aclocal/nspr.m4 from
nspr_dev conflicts not only with CSWmozilla, but also with CSWsunbird.

http://www.opencsw.org/packages/cswsunbird/

Do we drop both CSWmozilla and CSWsunbird?

Maciej

From bwalton at opencsw.org  Sat Jun 25 19:24:04 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 25 Jun 2011 13:24:04 -0400
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <BANLkTinKiKRkSztzEpRNpJf01cb7r6dk7w@mail.gmail.com>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
	<1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>
	<1307324723-sup-7673@pinkfloyd.chass.utoronto.ca>
	<1308277170-sup-1017@pinkfloyd.chass.utoronto.ca>
	<BANLkTinKiKRkSztzEpRNpJf01cb7r6dk7w@mail.gmail.com>
Message-ID: <1309022494-sup-2783@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Sat Jun 25 13:16:59 -0400 2011:

Hi Maciej,

> http://www.opencsw.org/packages/cswsunbird/
> 
> Do we drop both CSWmozilla and CSWsunbird?

It's abandoned upstream as they recommend using thunderbird 3 with the
lighting extension.  Dropping both has my support.

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


From maciej at opencsw.org  Sat Jun 25 20:26:15 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 25 Jun 2011 19:26:15 +0100
Subject: [csw-maintainers] time to deprecate CSWmozilla
In-Reply-To: <1309022494-sup-2783@pinkfloyd.chass.utoronto.ca>
References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca>
	<BANLkTikNrCiB+nJqEs4Afh__p+ampMCMoA@mail.gmail.com>
	<1307123778-sup-3520@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=6aQjfmy6X+_0W7oR2pBA+V7B3kA@mail.gmail.com>
	<BANLkTikQw_qdVepn8yEAxZS0HG4hnWr=rA@mail.gmail.com>
	<BANLkTikM-oQoj7a4mGB8UGGHbrvsLEUVJQ@mail.gmail.com>
	<1307278894-sup-1960@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=hQr5=jC+qXHvmCWe50G5zk=R09A@mail.gmail.com>
	<1307324723-sup-7673@pinkfloyd.chass.utoronto.ca>
	<1308277170-sup-1017@pinkfloyd.chass.utoronto.ca>
	<BANLkTinKiKRkSztzEpRNpJf01cb7r6dk7w@mail.gmail.com>
	<1309022494-sup-2783@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTinux_KfiGvypu+EatUz9wJ8YA8bDA@mail.gmail.com>

2011/6/25 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Maciej Blizi?ski's message of Sat Jun 25 13:16:59 -0400 2011:
>
> Hi Maciej,
>
>> http://www.opencsw.org/packages/cswsunbird/
>>
>> Do we drop both CSWmozilla and CSWsunbird?
>
> It's abandoned upstream as they recommend using thunderbird 3 with the
> lighting extension. ?Dropping both has my support.

Cool.  The updated packages are available for testing.

http://buildfarm.opencsw.org/experimental.html#nspr

This is nspr-4.8.7.  The version 4.8.8 is out, but doesn't compile,
unfortunately.

Maciej

From skayser at opencsw.org  Sun Jun 26 00:10:18 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 26 Jun 2011 00:10:18 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
	<1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
Message-ID: <20110625221018.GU25705@sebastiankayser.de>

* Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from rupert THURNER's message of Sat Jun 25 10:50:20 -0400 2011:
> > > mgar init (maybe re-init to help with svn -> git)
> > >
> > this seems not to work yet ...
> > 
> > rupert at login:~/git-ben
> > $ mgar init mercurial
> > -bash: mgar: command not found
> 
> There are two problems here.
> 
> 1. You likely don't have CSWmgar installed.

Just asked for it to be installed on the buildfarm, should be available
soon on the actual build hosts. On private boxes a simple 'pkgutil -i
mgar' against current/ should do. If anyone has any questions on mgar,
please let me know.

Basically, it's a wrapper around GAR to which you can feed the exact
same commands as to gmake plus some logic around it to populate and
manage the build tree (and only keep a single, central copy of a gar
branch while doing so). mgar init <path> will checkout the full build
tree (not only a single package) to <path>, thus in Rupert's example
above the result might not be as expected.

> 2. The mgar tool will need to learn how to checkout the git repo
>    instead of the svn repo.
> 
> It was a "hypothetically this would become."  Sebastian would have the
> best idea of how easy something like this would be to implement.

I'll think about it (and it should be fairly easy to implement), but can
we take one step back for a second? From what I understand, we have two
aspects, is that correct?

  1) move mgar/gar/ to git
  2) move mgar/pkg/* to git

The first item should be straight forward (and sort of behind the
scenes) in case we switch to mgar as the canonical build tool/interface.

The second one will need adjustments to gar itself (e.g. UNCOMMITTED
handling), some thought on whether to have a single repo or multiple
ones, and will imply a noticable change in terms of SCM for all
maintainers working with the pkg build repository.

Can I suggest to create a wikidot wiki page with a rationale and a brief
plan of actions (for both points) so that we can assemble a list of
things to consider?

> > > i created, as experiment, https://github.com/opencsw/mercurial,
> > and i tried to write a description which one could execute with the
> > existing buildserver installation.  would this be ok like this:
> > https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw
> > ?
> 
> I don't have time for a full review now, but this would raise an
> interesting issue.  Currently we have one big repository for every
> package.  What you've detailed here would see a separate repository
> for each package description.  I can see pros and cons to this and
> will outline some of them later[1]

If a full repository (containing all build recipes) is reasonable fast
to work with, we might actually address the people who currently prefer
to work with individual package checkouts (cause the current full svn
checkout is too slow for them).

If not, we could consider to start using the OPENCSW_REPOSITORY info in
the packages to establish a central package-version to build recipe
location mapping db. Which can then e.g. be used by mgar to checkout a
single build recipe. Just thinking out loud.

Sebastian

From maciej at opencsw.org  Sun Jun 26 00:45:19 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 25 Jun 2011 23:45:19 +0100
Subject: [csw-maintainers] Assessing catalog quality
Message-ID: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>

Hello fellow maintainers,

Phil has recently mentioned[1] the issue of organization-wide quality.
 I believe it is a very important one.

It would be beneficial for our project to come up with a way to track
the quality of our catalog.  We could see trends and react when
something bad is happening, and also see when the catalog is
improving.  We could come up with a set of metrics that would be
periodically applied and recorded.  With time, we would accumulate
information about which direction is our catalog heading.

We already have one metric, implemented by William: package count[2].
It is already a useful metric, allowing us to see how the catalog
grows in the number of packages.  It isn't a quality metric, though.
Quality metrics will require some consideration, and we need to
acknowledge that there will be no perfect metric to measure catalog
quality.  However, an imperfect metric is definitely better than no
metric.

Here's my question to maintainers: What metrics would you apply to the
catalog for the purpose of catalog quality evaluation?  Which aspects
of packages, or interactions between packages would you take into
consideration?  Do you have any already working code that could be
used for this purpose?

Maciej

[1] http://lists.opencsw.org/pipermail/maintainers/2011-June/014860.html
[2] http://www.opencsw.org/get-it/package-statistics/

From skayser at opencsw.org  Sun Jun 26 00:30:58 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 26 Jun 2011 00:30:58 +0200
Subject: [csw-maintainers] gar tip
In-Reply-To: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca>
References: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca>
Message-ID: <20110625223058.GV25705@sebastiankayser.de>

* Ben Walton <bwalton at opencsw.org> wrote:
> Peter and I just realized that not everyone is aware of the templated
> GAR recipe feature.  In opencsw/ (or opencsw/cpan, etc), you can type:
> 
> gmake newpkg-foo
> 
> This will give you a templated base recipe file.  It's custom to each
> specialized category (cpan, etc) so that things like gmake
> newpkg-Some::Cool:Perl will generate a recipe for
> CSWpm-some-cool-perl/pm_some_cool_perl, etc.

When you use mgar you can already also use:

  mgar newpkg <name> <version>

and it will populate the template's version field too. Beyond that (not
yet implemented), what would you think about populating the template
even further, by simply passing the upstream URL to newpkg?

  mgar newpkg http://foo.org/files/bla-1.2.3.tar.gz

It would then:

* check whether the file is available
* regex-retrieve NAME (bla) and VERSION (1.2.3)
* regex-retrieve MASTER_SITES (http://foo.org/files/)
* adjust the DISTFILES .tar.gz extension (if != .tar.gz)
* possibly run an initial 'mgar makesum'

Helpful or too much magic?

Sebastian

From jcraig at opencsw.org  Sun Jun 26 02:04:35 2011
From: jcraig at opencsw.org (Jonathan Craig)
Date: Sat, 25 Jun 2011 20:04:35 -0400
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
Message-ID: <BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>

2011/6/25 Maciej Blizi?ski <maciej at opencsw.org>
>
> Here's my question to maintainers: What metrics would you apply to the
> catalog for the purpose of catalog quality evaluation? ?Which aspects
> of packages, or interactions between packages would you take into
> consideration? ?Do you have any already working code that could be
> used for this purpose?

Here are some thoughts, but I'm not knowledgeable enough of the
internals of package publishing to know if they are determinable.

Positive measures could include:
? New package submission - Count of packages that didn't previously exist
? Updated packages ? ? ? ? ? - Count of packages that increment their
version number

Negative measure could include:
? Patched packages ? ? ? ? ? - Count of packages submitted that didn't
increment their version number

Neutral but interesting stats could include:
? Number of gar managed packages?????? - new or updated packages managed by gar
? Number of non-gar managed packages - new or updated packages from
outside of gar
  -- These speaks to quality if one accepts that packages built and
maintained through gar are both easier to update and/or takeover
? Number of package takeovers????????????? - indicative of the
stability of the maintainer-ship

Other non-catalog stats to report
? Track / Report post counts to the various mailing lists? -
indicative of the vibrancy of the various constituencies
? Wiki updates (Gar/OpenCSW)?????????????????????????????????? -
indicative of readily available documentation
? OpenCSW site updates??????????????????????????????????????????? -
indicative of the freshness of the site

From phil at bolthole.com  Sun Jun 26 02:33:58 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 25 Jun 2011 17:33:58 -0700
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
Message-ID: <BANLkTi=o-gPdSF9Umd2AedWsuc-XuDGoiw@mail.gmail.com>

2011/6/25 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/6/13 Philip Brown <phil at bolthole.com>:
>
>> you took the time to write a lot of things in your email. Thank you.
>> However, ?while the things you wrote were "good", and "true"... they
>> still did not concretely address the issue :(
>
> I'm still unsure about your use of quotes or scare quotes, when you
> quote the word good, which of the three you mean:
>
> - something somebody else said that you quote here
> - the literal: g, o, o, d


I am not a sarcastic person. When I write the word "good", in quotes
or otherwise, I mean
"good" :)
everything you wrote was a positive thing
everything you wrote was true.
but something can be both good, and true, yet still not address the issue.

technical reply, will follow in your [written for technical issues] email

From phil at bolthole.com  Sun Jun 26 02:48:35 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 25 Jun 2011 17:48:35 -0700
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
	<BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
Message-ID: <BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>

2011/6/25 Maciej Blizi?ski <maciej at opencsw.org>:
> I've received a complaint for mixing technical and non-technical
> issues in one email. ?Sorry about that. ?Here's the amended version of
> the email.
>
> 2011/6/13 Philip Brown <phil at bolthole.com>:
>
>> This is exactly the problem that I see.
>> There have been a few people complaining about "lack of consistency"
>> with the current release process.
>> But how is a release strategy built around "hope", more consistent????
>
> Let's consider three separate issues:
>
> 1. Package review
> 2. Policy development
> 3. Policy enforcement
>
> The inconsistency that the proposal refers to, and attempts to
> improve, is in point 3 above. ?It seems to me that in your paragraph
> above, you refer to point 1.
>
> How would you define consistency in the context of a human examining a
> svr4 file?

No manual human process can be perfectly consistent, I grant that.
My position is that  "A person, or persons, have a specific
responsability to at least glance at a package before release; if they
dont, a package wont get released"  is **more** consistent than

"all packages will automatically be released within 2 weeks.  Unless
someone, maybe, possibly, decides to look at someone else's packages
(without any prompting to do so) in that time window, and notices a
problem, and files a bug about it"

In the first example, it is guaranteed that a 2nd human has at least
"touched" the package. guaranteed. that's 100% consistency right
there.
There is no such guarantee in the new proposal, as it currently stands.


>> Some people.. including *you* Maciej... keep pressing the claims that
>> everything should be automated, for "consistency".
>> So why are you not automating a 2nd party validation check?
>
> Do you have any specific solution in mind? ?How would it work?


Since I have had no visibility into the new system, it is rather
difficult for me to suggest a "specific" solution.
In a more general view, it could work possibly similar to below:


* new package drop into "unstable".   They are flagged
somehow/somewhere as "needs review"
* Any motivated maintainer can go look at [the list of packages that
"needs review"], and....
   (unsure what goes here, exactly. In an ideal-yet-simple world,
perhaps click someplace, and have a browsable
  interface to show layout of files, and optional click-to-view-file interface?)
  If the maintainer wants to *really* check out details, they would
just install it from the "unstable" tree.
* if no problems seen, then after looking at above, the 3rd-party
maintainer clicks checkbox, "yes looks okay to me".
  package then gets cleared for migration to "current", after the 2
week period also elapses.

From phil at bolthole.com  Sun Jun 26 03:16:51 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 25 Jun 2011 18:16:51 -0700
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
Message-ID: <BANLkTik0VDmGGZXua0LNyd-H1W2sru7mbw@mail.gmail.com>

On Sat, Jun 25, 2011 at 5:04 PM, Jonathan Craig <jcraig at opencsw.org> wrote:
> 2011/6/25 Maciej Blizi?ski <maciej at opencsw.org>
>>
>> Here's my question to maintainers: What metrics would you apply to the
>> catalog for the purpose of catalog quality evaluation? ?Which aspects
>> of packages, or interactions between packages would you take into
>> consideration? ?Do you have any already working code that could be
>> used for this purpose?
>
> Here are some thoughts, but I'm not knowledgeable enough of the
> internals of package publishing to know if they are determinable.
>
> Positive measures could include:
> ? New package submission - Count of packages that didn't previously exist
> ? Updated packages ? ? ? ? ? - Count of packages that increment their
> version number
>
> Negative measure could include:
> ? Patched packages ? ? ? ? ? - Count of packages submitted that didn't
> increment their version number
>

[...]

This seems to be numerical "quality" based.  Which, while a good
thing, is not all I was concerned with.
What you wrote, is in some ways more "quantity/freshness" based.
In addition to the things you wrote, I was also thinking of overall
consistency between packages. In ways that *cannot* be measured by
simple pre-release scripts.
Many things can be. But not everything.
Random things like... i dunno.. naming of rc files, and placement, in
complex cases. there's other random small stuff like that.

To me, its the difference between, "hey lets just automate the BSD
ports tree to autocompile stuff for solaris instead", vs
"Hey lets look at the BSD ports tree, *package by package*, and ensure
that BSD-isms are replaced with more Solaris standard stuff".

Yes it's possible to write a robo-compiler mechanism.  But it yields
"higher quality" for a Solaris user, to have the packages individually
considered, *on top of* the initial grunt work done by robo-porting.


Yes, metrics are good!  But not as an end in and of itself.  To take
the biggest programmer metric failure:

How do you measure the "quality" of a programmer's work?
At one point, IBM said, "We'll measure it based on KLOC".
Epic Fail.

After 40 years, there is still no uniform "metric" for that sort of
thing. Nor is it possible to uniformly create one.
Some kinds of quality are simply not possible to reduce to "metrics".

From phil at bolthole.com  Sun Jun 26 03:26:15 2011
From: phil at bolthole.com (Philip Brown)
Date: Sat, 25 Jun 2011 18:26:15 -0700
Subject: [csw-maintainers] gar tip
In-Reply-To: <20110625223058.GV25705@sebastiankayser.de>
References: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca>
	<20110625223058.GV25705@sebastiankayser.de>
Message-ID: <BANLkTikLiOCUYd9V3Qj6pxSZCoT_yQKsTw@mail.gmail.com>

On Sat, Jun 25, 2011 at 3:30 PM, Sebastian Kayser <skayser at opencsw.org> wrote:
>
>
> and it will populate the template's version field too. Beyond that (not
> yet implemented), what would you think about populating the template
> even further, by simply passing the upstream URL to newpkg?
>
> ?mgar newpkg http://foo.org/files/bla-1.2.3.tar.gz
>

that sounds pretty nice!


as long as you allowed an override for name, because some of the
software archive filenames are pretty silly :-/

From bwalton at opencsw.org  Sun Jun 26 04:46:20 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 25 Jun 2011 22:46:20 -0400
Subject: [csw-maintainers] gar tip
In-Reply-To: <BANLkTikLiOCUYd9V3Qj6pxSZCoT_yQKsTw@mail.gmail.com>
References: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca>
	<20110625223058.GV25705@sebastiankayser.de>
	<BANLkTikLiOCUYd9V3Qj6pxSZCoT_yQKsTw@mail.gmail.com>
Message-ID: <1309056336-sup-9343@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Sat Jun 25 21:26:15 -0400 2011:
> On Sat, Jun 25, 2011 at 3:30 PM, Sebastian Kayser <skayser at opencsw.org> wrote:
> >
> >
> > and it will populate the template's version field too. Beyond that (not
> > yet implemented), what would you think about populating the template
> > even further, by simply passing the upstream URL to newpkg?
> >
> > ?mgar newpkg http://foo.org/files/bla-1.2.3.tar.gz
> >
> 
> that sounds pretty nice!
> 
> 
> as long as you allowed an override for name, because some of the
> software archive filenames are pretty silly :-/

Agreed.  This might be something best handled by real arguments.  -u
http://..., -n name, etc?

The idea is great though!

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


From rupert at opencsw.org  Sun Jun 26 08:58:35 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 26 Jun 2011 08:58:35 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <20110625221018.GU25705@sebastiankayser.de>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
	<1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
	<20110625221018.GU25705@sebastiankayser.de>
Message-ID: <BANLkTimcGB3-7LPiZYcZLxxdGO19mhUqKg@mail.gmail.com>

On Sun, Jun 26, 2011 at 00:10, Sebastian Kayser <skayser at opencsw.org> wrote:

> * Ben Walton <bwalton at opencsw.org> wrote:
> > Excerpts from rupert THURNER's message of Sat Jun 25 10:50:20 -0400 2011:
> > > > mgar init (maybe re-init to help with svn -> git)
> > > >
> > > this seems not to work yet ...
> > >
> > > rupert at login:~/git-ben
> > > $ mgar init mercurial
> > > -bash: mgar: command not found
> >
> > There are two problems here.
> >
> > 1. You likely don't have CSWmgar installed.
>
> Just asked for it to be installed on the buildfarm, should be available
> soon on the actual build hosts. On private boxes a simple 'pkgutil -i
> mgar' against current/ should do. If anyone has any questions on mgar,
> please let me know.
>
> Basically, it's a wrapper around GAR to which you can feed the exact
> same commands as to gmake plus some logic around it to populate and
> manage the build tree (and only keep a single, central copy of a gar
> branch while doing so). mgar init <path> will checkout the full build
> tree (not only a single package) to <path>, thus in Rupert's example
> above the result might not be as expected.
>
> > 2. The mgar tool will need to learn how to checkout the git repo
> >    instead of the svn repo.
> >
> > It was a "hypothetically this would become."  Sebastian would have the
> > best idea of how easy something like this would be to implement.
>
> I'll think about it (and it should be fairly easy to implement), but can
> we take one step back for a second? From what I understand, we have two
> aspects, is that correct?
>
>  1) move mgar/gar/ to git
>  2) move mgar/pkg/* to git
>
> The first item should be straight forward (and sort of behind the
> scenes) in case we switch to mgar as the canonical build tool/interface.
>
> The second one will need adjustments to gar itself (e.g. UNCOMMITTED
> handling), some thought on whether to have a single repo or multiple
> ones, and will imply a noticable change in terms of SCM for all
> maintainers working with the pkg build repository.
>
> Can I suggest to create a wikidot wiki page with a rationale and a brief
> plan of actions (for both points) so that we can assemble a list of
> things to consider?
>
> > > > i created, as experiment, https://github.com/opencsw/mercurial,
> > > and i tried to write a description which one could execute with the
> > > existing buildserver installation.  would this be ok like this:
> > >
> https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw
> > > ?
> >
> > I don't have time for a full review now, but this would raise an
> > interesting issue.  Currently we have one big repository for every
> > package.  What you've detailed here would see a separate repository
> > for each package description.  I can see pros and cons to this and
> > will outline some of them later[1]
>
> If a full repository (containing all build recipes) is reasonable fast
> to work with, we might actually address the people who currently prefer
> to work with individual package checkouts (cause the current full svn
> checkout is too slow for them).
>
> If not, we could consider to start using the OPENCSW_REPOSITORY info in
> the packages to establish a central package-version to build recipe
> location mapping db. Which can then e.g. be used by mgar to checkout a
> single build recipe. Just thinking out loud.


to get a feeling for the question how to get a full checkout, i created:
* https://github.com/opencsw/pkg <https://github.com/opencsw/pkg-all>
(submodules)
* https://github.com/opencsw/pkg-all (full repo)

the pkg-all feels quite heavy. creating it took nearly 9 hours, its 100mb
big, takes more than 5 minutes to push and clone, see below. and, it cannot
be cloned in parts, like the subversion tree before. and, it is not open to
have partial migration.

$ time git svn clone
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg pkg-all
...
real    509m37.383s
user    109m23.710s
sys     378m14.304s

rupert at login:~/git-experiment/pkg-all
$ time git push origin master
Counting objects: 87829, done.
Delta compression using up to 24 threads.
Compressing objects: 100% (51647/51647), done.
Writing objects: 100% (87829/87829), 95.34 MiB | 352 KiB/s, done.
Total 87829 (delta 31596), reused 85545 (delta 29312)
To git at github.com:opencsw/pkg-all.git
 * [new branch]      master -> master

real    5m6.088s
user    0m56.358s
sys     0m6.002s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110626/6167ba81/attachment.html>

From rupert at opencsw.org  Sun Jun 26 10:25:12 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 26 Jun 2011 10:25:12 +0200
Subject: [csw-maintainers] wiki access?
In-Reply-To: <BANLkTinMymsQWT5CH7B+BKGvhAZT1jHMvw@mail.gmail.com>
References: <BANLkTinMymsQWT5CH7B+BKGvhAZT1jHMvw@mail.gmail.com>
Message-ID: <BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>

i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would
not let me. joining returned:
 You can not apply.
It seems you have already applied for membership.
where does such an application go? it seems to be my fault that i cannot
remember when i applied, and not tracking it ...

rupert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110626/1de52fae/attachment.html>

From trygvis at opencsw.org  Sun Jun 26 12:04:38 2011
From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=)
Date: Sun, 26 Jun 2011 12:04:38 +0200
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
Message-ID: <4E070436.7080407@opencsw.org>

On 6/26/11 12:45 AM, Maciej Blizi?ski wrote:
> Hello fellow maintainers,
>
> Phil has recently mentioned[1] the issue of organization-wide quality.
>   I believe it is a very important one.
>
> It would be beneficial for our project to come up with a way to track
> the quality of our catalog.  We could see trends and react when
> something bad is happening, and also see when the catalog is
> improving.  We could come up with a set of metrics that would be
> periodically applied and recorded.  With time, we would accumulate
> information about which direction is our catalog heading.
>
> We already have one metric, implemented by William: package count[2].
> It is already a useful metric, allowing us to see how the catalog
> grows in the number of packages.  It isn't a quality metric, though.
> Quality metrics will require some consideration, and we need to
> acknowledge that there will be no perfect metric to measure catalog
> quality.  However, an imperfect metric is definitely better than no
> metric.
>
> Here's my question to maintainers: What metrics would you apply to the
> catalog for the purpose of catalog quality evaluation?  Which aspects
> of packages, or interactions between packages would you take into
> consideration?  Do you have any already working code that could be
> used for this purpose?

Number of overrides is one thing that comes to mind.

-- 
Trygve

From phil at bolthole.com  Sun Jun 26 15:55:16 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 26 Jun 2011 06:55:16 -0700
Subject: [csw-maintainers] wiki access?
In-Reply-To: <BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>
References: <BANLkTinMymsQWT5CH7B+BKGvhAZT1jHMvw@mail.gmail.com>
	<BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>
Message-ID: <BANLkTinB2T9QWpwe8_S23VkMXM=bXnbFyQ@mail.gmail.com>

I think this means, "you are already a 'member', but you dont have
permissions to edit that page"



On Sun, Jun 26, 2011 at 1:25 AM, rupert THURNER <rupert at opencsw.org> wrote:
> i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would
> not let me. joining returned:
> You can not apply.
> It seems you have already applied for membership.
> where does such an application go? it seems to be my fault that i cannot
> remember when i applied, and not tracking it ...
> rupert.
>

From skayser at opencsw.org  Sun Jun 26 16:47:57 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 26 Jun 2011 16:47:57 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <BANLkTimcGB3-7LPiZYcZLxxdGO19mhUqKg@mail.gmail.com>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
	<1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
	<20110625221018.GU25705@sebastiankayser.de>
	<BANLkTimcGB3-7LPiZYcZLxxdGO19mhUqKg@mail.gmail.com>
Message-ID: <20110626144757.GW25705@sebastiankayser.de>

* rupert THURNER <rupert at opencsw.org> wrote:
>    to get a feeling for the question how to get a full checkout, i created:
>    *?[5]https://github.com/opencsw/pkg? (submodules)
>    *?[6]https://github.com/opencsw/pkg-all?(full repo)

Cool, thanks alot for the experiment!

>    the pkg-all feels quite heavy. creating it took nearly 9 hours, its 100mb
>    big, takes more than 5 minutes to push and clone, see below. and, it
>    cannot be cloned in parts, like the subversion tree before. and, it is not
>    open to have partial migration.
>    $ time git svn clone
>    [7]https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg pkg-all
>    ...
>    real ? ?509m37.383s
>    user ? ?109m23.710s
>    sys ? ? 378m14.304s
>
>    rupert at login:~/git-experiment/pkg-all
>    $ time git push origin master
>    Counting objects: 87829, done.
>    Delta compression using up to 24 threads.
>    Compressing objects: 100% (51647/51647), done.
>    Writing objects: 100% (87829/87829), 95.34 MiB | 352 KiB/s, done.
>    Total 87829 (delta 31596), reused 85545 (delta 29312)
>    To git at github.com:opencsw/pkg-all.git
>    ?* [new branch] ? ? ?master -> master
>    real ? ?5m6.088s
>    user ? ?0m56.358s
>    sys ? ? 0m6.002s

The operations above are one off, right? To add some further figures, a git
clone of the full repo takes ~2mins for me, git log . in a package directory
~12 seconds.

$ time git clone git://github.com/opencsw/pkg-all.git
remote: Counting objects: 87829, done.
remote: Compressing objects: 100% (49363/49363), done.
Indexing 87829 objects.
remote: Total 87829 (delta 31596), reused 87829 (delta 31596)
 100% (87829/87829) done
Resolving 31596 deltas.
 100% (31596/31596) done
Checking files out...
 100% (12273/12273) done

real    1m56.048s
user    0m16.952s
sys     0m3.641s

$ pwd
/home/ska/tmp/gittest/pkg-all/lang-python/sqlobject/trunk
$ time git log . >/dev/null

real    0m11.587s
user    0m11.532s
sys     0m0.052s

Sebastian

From bwalton at opencsw.org  Sun Jun 26 17:21:37 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 26 Jun 2011 11:21:37 -0400
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <20110626144757.GW25705@sebastiankayser.de>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
	<1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
	<20110625221018.GU25705@sebastiankayser.de>
	<BANLkTimcGB3-7LPiZYcZLxxdGO19mhUqKg@mail.gmail.com>
	<20110626144757.GW25705@sebastiankayser.de>
Message-ID: <1309101553-sup-7811@pinkfloyd.chass.utoronto.ca>

Excerpts from Sebastian Kayser's message of Sun Jun 26 10:47:57 -0400 2011:

> The operations above are one off, right? To add some further
> figures, a git clone of the full repo takes ~2mins for me, git log
> . in a package directory ~12 seconds.

The initial price of a clone will be the heaviest as only new
references are transferred after that.  2 minutes isn't that bad for a
large repo like the package tree.

Was the log operation on a local or network mounted filesystem?  What
about a subsequent run of the same operation (cold vs hot cache)?

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


From maciej at opencsw.org  Sun Jun 26 17:45:26 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 26 Jun 2011 16:45:26 +0100
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
	<BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
	<BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>
Message-ID: <BANLkTim+-cmj1Vy=4g=Fk9pb97UFPww1Wg@mail.gmail.com>

2011/6/26 Philip Brown <phil at bolthole.com>:
> 2011/6/25 Maciej Blizi?ski <maciej at opencsw.org>:
>> I've received a complaint for mixing technical and non-technical
>> issues in one email. ?Sorry about that. ?Here's the amended version of
>> the email.
>>
>> 2011/6/13 Philip Brown <phil at bolthole.com>:
>>
>>> This is exactly the problem that I see.
>>> There have been a few people complaining about "lack of consistency"
>>> with the current release process.
>>> But how is a release strategy built around "hope", more consistent????
>>
>> Let's consider three separate issues:
>>
>> 1. Package review
>> 2. Policy development
>> 3. Policy enforcement
>>
>> The inconsistency that the proposal refers to, and attempts to
>> improve, is in point 3 above. ?It seems to me that in your paragraph
>> above, you refer to point 1.
>>
>> How would you define consistency in the context of a human examining a
>> svr4 file?
>
> No manual human process can be perfectly consistent, I grant that.
> My position is that ?"A person, or persons, have a specific
> responsability to at least glance at a package before release; if they
> dont, a package wont get released" ?is **more** consistent than
>
> "all packages will automatically be released within 2 weeks. ?Unless
> someone, maybe, possibly, decides to look at someone else's packages
> (without any prompting to do so) in that time window, and notices a
> problem, and files a bug about it"
>
> In the first example, it is guaranteed that a 2nd human has at least
> "touched" the package. guaranteed. that's 100% consistency right
> there.
> There is no such guarantee in the new proposal, as it currently stands.

The guarantee you mention, is a guarantee that a button is pressed.
There's no guarantee whether the human actually did anything or not.
Claiming 100% consistency is a bit of a stretch in my opinion.

The non-inclusion of reviews as a gating factor in the proposal is
intentional.  It might of course change - but so far, it has been
group's intention not to involve a human controlling package releases.

Peer reviews are an excellent mechanism to improve quality.  My
intention is to create an environment in which maintainers want their
packages reviewed.

>>> Some people.. including *you* Maciej... keep pressing the claims that
>>> everything should be automated, for "consistency".
>>> So why are you not automating a 2nd party validation check?
>>
>> Do you have any specific solution in mind? ?How would it work?
>
>
> Since I have had no visibility into the new system, it is rather
> difficult for me to suggest a "specific" solution.
> In a more general view, it could work possibly similar to below:
>
>
> * new package drop into "unstable". ? They are flagged
> somehow/somewhere as "needs review"
> * Any motivated maintainer can go look at [the list of packages that
> "needs review"], and....
> ? (unsure what goes here, exactly. In an ideal-yet-simple world,
> perhaps click someplace, and have a browsable
> ?interface to show layout of files, and optional click-to-view-file interface?)
> ?If the maintainer wants to *really* check out details, they would
> just install it from the "unstable" tree.
> * if no problems seen, then after looking at above, the 3rd-party
> maintainer clicks checkbox, "yes looks okay to me".
> ?package then gets cleared for migration to "current", after the 2
> week period also elapses.

How about a similar setup, in which there is no review based gating,
but accounting of reviews.  For example, there could be a tool
allowing maintainers to mark packages as reviewed and accepted.
Package review status would then appear on the web, in places such as
maintainer's page, and package pages in the buildfarm database.  It
would be a form a beneficial peer pressure, where maintainers would be
proud of having their packages reviewed.

Maciej

From skayser at opencsw.org  Sun Jun 26 17:40:39 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 26 Jun 2011 17:40:39 +0200
Subject: [csw-maintainers] wiki access?
In-Reply-To: <BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>
References: <BANLkTinMymsQWT5CH7B+BKGvhAZT1jHMvw@mail.gmail.com>
	<BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>
Message-ID: <20110626154039.GX25705@sebastiankayser.de>

Hi Rupert,

* rupert THURNER <rupert at opencsw.org> wrote:
>    i tried to edit [1]http://wiki.opencsw.org as user ThurnerRupert,
>    but it would not let me. joining returned: You can not apply.  It
>    seems you have already applied for membership.

no need to join if you've already applied. Application will likely go to
Peter and maybe to Maciej, too [1]. Chances are, they already granted
you access if you've applied previously. Can you add a new page (form at
the bottom of the left navbar) after you've logged in?

Sebastian

[1] http://wiki.opencsw.org/3rd-party-services#toc5

From bonivart at opencsw.org  Sun Jun 26 19:17:09 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 26 Jun 2011 19:17:09 +0200
Subject: [csw-maintainers] wiki access?
In-Reply-To: <BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>
References: <BANLkTinMymsQWT5CH7B+BKGvhAZT1jHMvw@mail.gmail.com>
	<BANLkTimR6tGtNQJMaORbBU6bxcKG37RjFA@mail.gmail.com>
Message-ID: <BANLkTingznJvhq+D+wmGziN8-1jwEQESwg@mail.gmail.com>

On Sun, Jun 26, 2011 at 10:25 AM, rupert THURNER <rupert at opencsw.org> wrote:
> i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would
> not let me. joining returned:

I have added you now. You should now be able to add/edit pages.

/peter

From bonivart at opencsw.org  Sun Jun 26 19:28:49 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 26 Jun 2011 19:28:49 +0200
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <4E070436.7080407@opencsw.org>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<4E070436.7080407@opencsw.org>
Message-ID: <BANLkTikxXAGVmJjS3DNvrX1xH-4ZGnox2A@mail.gmail.com>

2011/6/26 Trygve Laugst?l <trygvis at opencsw.org>:
> Number of overrides is one thing that comes to mind.

+1. We also need to analyze the overrides but that's a different matter.

Also, the package freshness William used to publish is a good metric,
I think we can agree that in general newer packages are better than
older packages, they follow our current standard better and are more
up to date with upstream versions. I know that in some cases an old
package can be perfect, there's just no action going on upstream but
for the whole catalog I think it would be interesting to see how many
packages are 1-3 months old, 3-6 months old, 6-12 months old or older
than a year e.g.

Also, regarding the talks about peer review, why not use that as a
quality metric.

/peter

From skayser at opencsw.org  Sun Jun 26 20:03:58 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 26 Jun 2011 20:03:58 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <1309101553-sup-7811@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
	<1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
	<20110625221018.GU25705@sebastiankayser.de>
	<BANLkTimcGB3-7LPiZYcZLxxdGO19mhUqKg@mail.gmail.com>
	<20110626144757.GW25705@sebastiankayser.de>
	<1309101553-sup-7811@pinkfloyd.chass.utoronto.ca>
Message-ID: <20110626180358.GY25705@sebastiankayser.de>

* Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Sebastian Kayser's message of Sun Jun 26 10:47:57 -0400 2011:
> 
> > The operations above are one off, right? To add some further
> > figures, a git clone of the full repo takes ~2mins for me, git log
> > . in a package directory ~12 seconds.
> 
> The initial price of a clone will be the heaviest as only new
> references are transferred after that.  2 minutes isn't that bad for a
> large repo like the package tree.

Sorry, I'll have to revert my 2 minute clone estimate, that was on my
vserver with a very thick uplink. Re-tried on my home server (~100
KiB/s), clone took about 20mins. :/

> Was the log operation on a local or network mounted filesystem?  What
> about a subsequent run of the same operation (cold vs hot cache)?

Local file system, same result on subsequent runs (git 1.4.4.4). On my
server at home (git 1.7.5.4) the log operation on a directory is faster
and takes ~2 seconds (both for initial and subsequent runs).

Sebastian

From dam at opencsw.org  Sun Jun 26 20:49:23 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 26 Jun 2011 20:49:23 +0200
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
Message-ID: <E062AD38-B320-40E1-A9F1-DF47FD55DA66@opencsw.org>

Hi Maciej,

Am 26.06.2011 um 00:45 schrieb Maciej Blizi?ski:
> Here's my question to maintainers: What metrics would you apply to the
> catalog for the purpose of catalog quality evaluation?  Which aspects
> of packages, or interactions between packages would you take into
> consideration?  Do you have any already working code that could be
> used for this purpose?

I like to look at the sum of the weighted bug counts:
  http://www.opencsw.org/buglist/buglist.cgi
It would be even better if bugs were reported against
specific package revisions, so it would be possible to
calculate the bugginess of a specific catalog release.


Best regards

  -- Dago


From rupert at opencsw.org  Sun Jun 26 22:00:40 2011
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 26 Jun 2011 22:00:40 +0200
Subject: [csw-maintainers] experimental: subversion --> git, mercurial
In-Reply-To: <20110626180358.GY25705@sebastiankayser.de>
References: <BANLkTi==Oz8NQv98kwFhsgi5Ap3Dzzf+Ow@mail.gmail.com>
	<1308533109-sup-6441@pinkfloyd.chass.utoronto.ca>
	<BANLkTimeWEO5Z=h+GXCxmvvN5C7OD_mihQ@mail.gmail.com>
	<1309008070-sup-7506@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=8_+5Ykwv3WCFtHGgZJS-3UBHJ9g@mail.gmail.com>
	<1309013532-sup-8950@pinkfloyd.chass.utoronto.ca>
	<20110625221018.GU25705@sebastiankayser.de>
	<BANLkTimcGB3-7LPiZYcZLxxdGO19mhUqKg@mail.gmail.com>
	<20110626144757.GW25705@sebastiankayser.de>
	<1309101553-sup-7811@pinkfloyd.chass.utoronto.ca>
	<20110626180358.GY25705@sebastiankayser.de>
Message-ID: <BANLkTi=r1TQTWezPM1h7-w5vFSVY2ZkQQw@mail.gmail.com>

On Sun, Jun 26, 2011 at 20:03, Sebastian Kayser <skayser at opencsw.org> wrote:

> * Ben Walton <bwalton at opencsw.org> wrote:
> > Excerpts from Sebastian Kayser's message of Sun Jun 26 10:47:57 -0400
> 2011:
> >
> > > The operations above are one off, right? To add some further
> > > figures, a git clone of the full repo takes ~2mins for me, git log
> > > . in a package directory ~12 seconds.
> >
> > The initial price of a clone will be the heaviest as only new
> > references are transferred after that.  2 minutes isn't that bad for a
> > large repo like the package tree.
>
> Sorry, I'll have to revert my 2 minute clone estimate, that was on my
> vserver with a very thick uplink. Re-tried on my home server (~100
> KiB/s), clone took about 20mins. :/
>
> > Was the log operation on a local or network mounted filesystem?  What
> > about a subsequent run of the same operation (cold vs hot cache)?
>
> Local file system, same result on subsequent runs (git 1.4.4.4). On my
> server at home (git 1.7.5.4) the log operation on a directory is faster
> and takes ~2 seconds (both for initial and subsequent runs).
>
> started http://wiki.opencsw.org/dvcs.

rupert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110626/8bfa9f8f/attachment-0001.html>

From william at wbonnet.net  Sun Jun 26 22:02:40 2011
From: william at wbonnet.net (William Bonnet)
Date: Sun, 26 Jun 2011 22:02:40 +0200
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
Message-ID: <4E079060.5050104@wbonnet.net>

Hi

Some of the indicators you mention already exist. I provide the url in 
the rest of the message. Let me know if you need to summarize all this 
under a specific "catalog qa page"

> Positive measures could include:
>    New package submission - Count of packages that didn't previously exist
>    Updated packages           - Count of packages that increment their
> version number
These are available from : http://www.opencsw.org/get-it/package-statistics/
It's a monthly view


> Negative measure could include:
>    Patched packages           - Count of packages submitted that didn't
> increment their version number
Pretty much easy to compute (taking in account what is already done)
> Neutral but interesting stats could include:
>    Number of gar managed packages       - new or updated packages managed by gar
>    Number of non-gar managed packages - new or updated packages from
> outside of gar
This is available from http://www.opencsw.org/qa/

This page provides several link to the different catagories. You will 
find the detailled list of data and instant values. I started to created 
some statistics based upon these data. I can push it son now that there 
are some data to display :)

>    -- These speaks to quality if one accepts that packages built and
> maintained through gar are both easier to update and/or takeover
>    Number of package takeovers              - indicative of the
> stability of the maintainer-ship
It's not too difficult to implement
> Other non-catalog stats to report
>    Track / Report post counts to the various mailing lists  -
> indicative of the vibrancy of the various constituencies
>    Wiki updates (Gar/OpenCSW)                                   -
> indicative of readily available documentation
>    OpenCSW site updates                                            -
> indicative of the freshness of the site
Existing solution does not cover this. It does not mean it cannot be 
done nor it's a bad idea :P It just mean it has tobe done ;)

Cheers
W.

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

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


From phil at bolthole.com  Mon Jun 27 01:29:27 2011
From: phil at bolthole.com (Philip Brown)
Date: Sun, 26 Jun 2011 16:29:27 -0700
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTim+-cmj1Vy=4g=Fk9pb97UFPww1Wg@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
	<BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
	<BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>
	<BANLkTim+-cmj1Vy=4g=Fk9pb97UFPww1Wg@mail.gmail.com>
Message-ID: <BANLkTinb8va+gxYKg0Cj8aaVh3rTSgo8hw@mail.gmail.com>

2011/6/26 Maciej Blizi?ski <maciej at opencsw.org>:
>
> The non-inclusion of reviews as a gating factor in the proposal is
> intentional. ?It might of course change - but so far, it has been
> group's intention not to involve a human controlling package releases.
>
> Peer reviews are an excellent mechanism to improve quality. ?My
> intention is to create an environment in which maintainers want their
> packages reviewed.

providing some kind of positive motivation is nice. Its a great
management strategy.
but what could be used as sufficient motivation?

>Package review status would then appear on the web, in places such as
>maintainer's page, and package pages in the buildfarm database.  It
>would be a form a beneficial peer pressure, where maintainers would be
>proud of having their packages reviewed

btw, we've tried similar incentives before, in the form of the bug scoring page.
While I think this sort of thing appeals to some, it is not universal.


Sadly, no amount of "incentive" helps in the case of a person who has
the attitude of,
"nothing appeals more to me than not having someone else review my work"
Additionally , it often happens, in all kinds of areas (software
programming, article writing, and others)
that the people who are most resistant to having others review their
work, are the ones that need it most
:(

Is that something you are ok with? Because that's what this sort of
thing comes down to in the end, really.

From bwalton at opencsw.org  Mon Jun 27 03:55:55 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 26 Jun 2011 21:55:55 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
Message-ID: <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Sat Jun 25 09:46:44 -0400 2011:

Hi Jonathan,

> Alternately, as most everyone understands this implicitly it may not
> be required.

Do you wish to see the clarifying statement added to the proposal
before the vote?  If not, that's ok.  As you say, most understand that
it's implied.  I'd still like to start the vote tomorrow, so let me
know if you're working on this.

Phil: I've modified the vote writeup such that it's talking about the
proposal as written.  Please fill out the cons side.  If Jonathan does
put forward an ammendment that's accepted, you can update as necessary
before the vote if started.

Maciej: Would you mind preparing the ballot bin stuff?

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


From maciej at opencsw.org  Mon Jun 27 11:21:53 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 27 Jun 2011 10:21:53 +0100
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTinb8va+gxYKg0Cj8aaVh3rTSgo8hw@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
	<BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
	<BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>
	<BANLkTim+-cmj1Vy=4g=Fk9pb97UFPww1Wg@mail.gmail.com>
	<BANLkTinb8va+gxYKg0Cj8aaVh3rTSgo8hw@mail.gmail.com>
Message-ID: <BANLkTikM5a4q3g--QmeUNiCz6UOU2TgtPQ@mail.gmail.com>

2011/6/27 Philip Brown <phil at bolthole.com>:
> 2011/6/26 Maciej Blizi?ski <maciej at opencsw.org>:
>>
>> The non-inclusion of reviews as a gating factor in the proposal is
>> intentional. ?It might of course change - but so far, it has been
>> group's intention not to involve a human controlling package releases.
>>
>> Peer reviews are an excellent mechanism to improve quality. ?My
>> intention is to create an environment in which maintainers want their
>> packages reviewed.
>
> providing some kind of positive motivation is nice. Its a great
> management strategy.
> but what could be used as sufficient motivation?

My first thought is: giving helpful reviews!  This does of course mean
pointing out issues, but also giving explanations why the issues in
question are important, and suggestions how to tackle them.

>>Package review status would then appear on the web, in places such as
>>maintainer's page, and package pages in the buildfarm database. ?It
>>would be a form a beneficial peer pressure, where maintainers would be
>>proud of having their packages reviewed
>
> btw, we've tried similar incentives before, in the form of the bug scoring page.
> While I think this sort of thing appeals to some, it is not universal.
>
>
> Sadly, no amount of "incentive" helps in the case of a person who has
> the attitude of,
> "nothing appeals more to me than not having someone else review my work"
> Additionally , it often happens, in all kinds of areas (software
> programming, article writing, and others)
> that the people who are most resistant to having others review their
> work, are the ones that need it most
> :(
>
> Is that something you are ok with? Because that's what this sort of
> thing comes down to in the end, really.

Am I OK with people resisting reviews?  Nobody can stop anybody from
reviewing their work if it's published, but there can be someone not
willing to listen, or not willing to follow suggestions.  Am I OK with
people willing to listen or not following suggestions?  It depends.
If this happens, it's either because they don't understand the
problem, or because they don't share goals with the reviewer.  The
second issue is harder, in such case the two people need to talk.  It
helps if agreed goals of the group are available in writing, so that a
common ground can be established.  The reviewer also needs to take it
into account that the review receiver has no obligation to follow all the
suggestions.  If there are suggestions that are not part of group's
common goals, the review receiver may simply decline to follow them,
and that's fine.  The reviewer needs to understand that he or she
needs to be reasonable and that it is a conversation between equals.
The reviewer's role is only to help.

While I'm not OK with someone not understanding what the issue is, I'm
OK with someone declining to follow a suggestion if the package
complies with our standards and policies.  For example, if the issue
is that the package is missing a dependency, it's a clear policy
issue.  If the issue is something like whether to use a regular file
or a symlink to one, and it doesn't pose an operational problem, then
the reviewer should let go and save stamina for another time.

Maciej

From dam at opencsw.org  Mon Jun 27 12:46:30 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 27 Jun 2011 12:46:30 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs augeas
In-Reply-To: <201106271040.p5RAeKhU002689@login.bo.opencsw.org>
References: <201106271040.p5RAeKhU002689@login.bo.opencsw.org>
Message-ID: <76FD8688-EE6F-4705-80FD-06C37A63F1F2@opencsw.org>

Hi Mark,

Am 27.06.2011 um 12:40 schrieb Mark Phillips:
>> Additionally, and possibly not coincidentally, there is indication
>> that your package stuff was not actually committed into subversion?
>> 
>> OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/augeas/trunk at UNCOMMITTED
> 
> Hmm, should all be there. My checkout is committed...
> 
> current10x:augeas$ svn info | grep URL
> URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/augeas
> current10x:augeas$ svn st
> X       trunk/gar
> 
> Performing status on external item at 'trunk/gar'
> 
> It was probably the case that the roll that's sitting in experimental hadn't
> yet been committed - I tend to svn commit after I've rolled the package and
> installed it, testing that it at least installs properly. When I'm confident it
> does, it then gets committed.
> 
> Hope that helps.

It explains what is in the package. However, the procedure you use is somewhat
illegal, because the package contains a reference to the repository of the time
the package was build. This makes it possible to check out the specific revision
a package was built from. If you commit later this does not work. For your own
testing this is not relevant, but for submission it is mandatory that everything
has been checked in prior to building the package. It is sufficient to do a
  gmake platforms-repackage
after commiting to get valid packages.


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 phil at bolthole.com  Mon Jun 27 15:08:39 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 27 Jun 2011 06:08:39 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=J-jCbPtTL8x3NZU5SCErq0rhrOw@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<BANLkTimcCoqjh6YM3tR68kvEXxfXfebOrw@mail.gmail.com>
	<BANLkTi=J-jCbPtTL8x3NZU5SCErq0rhrOw@mail.gmail.com>
Message-ID: <BANLkTik1bXsWh+UMmiSxK-zzcCn6Q2Ev+g@mail.gmail.com>

Snipping a lot for readability. I'm trying to do that in a way that
still preserves what I believe to be original meaning and intent. If I
botch it, my apologies, please correct it.


On Fri, Jun 24, 2011 at 5:52 PM, Jonathan Craig <jcraig at opencsw.org> wrote:
> On Fri, Jun 24, 2011 at 6:42 PM, Philip Brown <phil at bolthole.com> wrote:

>>
>> It seems you are saying that you "look at the pkgsubmissions mailing
>> list already".
>[...]
>
> Ah, but the reality is that I pay greater attention to list emails
> that are associated with bug reports. ?Thats were I really feel I can
> learn something.

In a way, your reply backs up what I am saying. You pay (greater)
attention, when *someone else* has noticed an issue. But what if
no-one is comitted to examining and bringing up issues in the first
place?
This is a core concern I have.

?[...]
> You seem to continuously ignore the reality that the proposed process
> allows anyone to review any package and seek corrections prior to
> publication. ?IMO, this is a form of intellectual dishonesty. ?You
> haven't said it but from your posts I can only assume that if you
> can't be the "human" in human centric then you have no wish to
> participate.

I thought I have explicitly said the opposite. I dont care if it's me,
but I believe there does need to be *someone*, or someones, with that
explicit task, otherwise it wont get fully done.



> As to human vs automated processes you are ignoring that an automated
> process can apply the same level of scrutiny to every package
> regardless of the number submitted.

People keep trying to force this into a "human, OR automated process",
and claiming this is what I want.
Yet not once have I advocated getting rid of the automated process. My
preference is for
"human examination, AND automated process".

I have been requesting this be made available as a choice, but it is
being blocked.

From phil at bolthole.com  Mon Jun 27 15:22:44 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 27 Jun 2011 06:22:44 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTikVDBTDimaJi=XJ09Rz_XHn+ymqhg@mail.gmail.com>

On Sun, Jun 26, 2011 at 6:55 PM, Ben Walton <bwalton at opencsw.org> wrote:
>
>
> Phil: I've modified the vote writeup such that it's talking about the
> proposal as written. ?Please fill out the cons side. ?If Jonathan does
> put forward an ammendment that's accepted, you can update as necessary
> before the vote if started.

Ben:
So, to be clear:  you are rejecting every single one of my wording amendments?
Even though some of them clearly point out that the proposal claims
things that are false?


Jonathan made *comments* about my proposed amendments 2,3,4&5
However, I dont see that he refuted what I was saying.
For example, on #3, he did comment on my complaint about the "set in
stone" bit, but did not argue with my statement that the release
manager cannot currently "reject" a package. Therefore, the "reject"
part should be taken out of the proposal, because it is undisputedly
false.

It would be nice if you reviewed his comments on 2,4 & 5  more carefully also.

From bwalton at opencsw.org  Mon Jun 27 15:23:16 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 27 Jun 2011 09:23:16 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTik1bXsWh+UMmiSxK-zzcCn6Q2Ev+g@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<BANLkTimcCoqjh6YM3tR68kvEXxfXfebOrw@mail.gmail.com>
	<BANLkTi=J-jCbPtTL8x3NZU5SCErq0rhrOw@mail.gmail.com>
	<BANLkTik1bXsWh+UMmiSxK-zzcCn6Q2Ev+g@mail.gmail.com>
Message-ID: <1309180908-sup-782@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Jun 27 09:08:39 -0400 2011:

> People keep trying to force this into a "human, OR automated process",
> and claiming this is what I want.
> Yet not once have I advocated getting rid of the automated process. My
> preference is for
> "human examination, AND automated process".

We currently have a human examination with 'automated' process wrapped
around it.  Normally we'd refer to this as status quo.

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


From jcraig at opencsw.org  Mon Jun 27 17:09:32 2011
From: jcraig at opencsw.org (Jonathan Craig)
Date: Mon, 27 Jun 2011 11:09:32 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>

On Sun, Jun 26, 2011 at 9:55 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Ben Walton's message of Sat Jun 25 09:46:44 -0400 2011:
>
> Phil: I've modified the vote writeup such that it's talking about the
> proposal as written. ?Please fill out the cons side. ?If Jonathan does
> put forward an ammendment that's accepted, you can update as necessary
> before the vote if started.
>

Here is my proposed amendment with the pre/post paragraphs to indicate
placement within current proposal.  Wasn't really sure whether this
was to be submitted by mail or simply edited into wiki page.

-- amendment --
Any bug filed has the potential to trigger the creation of new policy.
This would require list discussion and in some cases a vote if there
is no clear consensus from that discussion.  New policy will be
implemented as a check within checkpkg.

As part of this effort a group of volunteer subject matter experts
will be established to support and maintain the release system.
Membership in the group is open and the purpose is to establish a
broad list of individuals who are best capable of supporting and
improving the release system.  This group will be subordinate to the
board and responsible for seeing that packaging policy is properly
enforced by the release system.  In the event an unforeseen issue
disrupts the release process they are empowered to manually augment
the system to enable timely release of packages.  Such intervention
will be logged with the understanding that repeated manual
intervention will require enhancements to the release system to
accommodate routine exceptions.

All items that fail checks in checkpkg may be overridden to allow
package-local exceptions to policy when/where required.  These
overrides are visible in the package delivered to the system and the
code repository.  Additionally, they can be queried for in the package
database.
-- end --

From phil at bolthole.com  Mon Jun 27 18:42:34 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 27 Jun 2011 09:42:34 -0700
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTikM5a4q3g--QmeUNiCz6UOU2TgtPQ@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
	<BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
	<BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>
	<BANLkTim+-cmj1Vy=4g=Fk9pb97UFPww1Wg@mail.gmail.com>
	<BANLkTinb8va+gxYKg0Cj8aaVh3rTSgo8hw@mail.gmail.com>
	<BANLkTikM5a4q3g--QmeUNiCz6UOU2TgtPQ@mail.gmail.com>
Message-ID: <BANLkTi=hrTk+e7L3C41_h1i3-kTpFun14g@mail.gmail.com>

2011/6/27 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/6/27 Philip Brown <phil at bolthole.com>:
>> 2011/6/26 Maciej Blizi?ski <maciej at opencsw.org>:
>>>
>>> The non-inclusion of reviews as a gating factor in the proposal is
>>> intentional. ?It might of course change - but so far, it has been
>>> group's intention not to involve a human controlling package releases.
>>>
>>> Peer reviews are an excellent mechanism to improve quality. ?My
>>> intention is to create an environment in which maintainers want their
>>> packages reviewed.
>>
>> providing some kind of positive motivation is nice. Its a great
>> management strategy.
>> but what could be used as sufficient motivation?
>
> My first thought is: giving helpful reviews! ?This does of course mean
> pointing out issues, but also giving explanations why the issues in
> question are important, and suggestions how to tackle them.


Errr... not sure how that is motivational there. maybe I'm not
understanding what you're saying.


On the other side of the field,  I have a thought on motivation for
the people doing the actual reviewing:

Those who participate and do... (? x amount of package reviews per
month/week, and also file 'y' amount of feedback/whatever?) could get
to be recognized as being on "the review team" ?

From maciej at opencsw.org  Mon Jun 27 19:29:26 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 27 Jun 2011 18:29:26 +0100
Subject: [csw-maintainers] Code and package reviews
In-Reply-To: <BANLkTi=hrTk+e7L3C41_h1i3-kTpFun14g@mail.gmail.com>
References: <BANLkTinPjQgyLgHTX7yQwhmFbz5d=aVfbw@mail.gmail.com>
	<BANLkTi=qmeR8Xfx7vpQb1e28+f76qriv_w@mail.gmail.com>
	<BANLkTi=z2-C=BiC7OZRSQXcPVBrV-7_M4A@mail.gmail.com>
	<BANLkTimuEWdBZQ2mjWuusH60CNS4TByJDQ@mail.gmail.com>
	<BANLkTi=wTSmeLPAQOogxTzU-s2z1TGF2gA@mail.gmail.com>
	<BANLkTim+-cmj1Vy=4g=Fk9pb97UFPww1Wg@mail.gmail.com>
	<BANLkTinb8va+gxYKg0Cj8aaVh3rTSgo8hw@mail.gmail.com>
	<BANLkTikM5a4q3g--QmeUNiCz6UOU2TgtPQ@mail.gmail.com>
	<BANLkTi=hrTk+e7L3C41_h1i3-kTpFun14g@mail.gmail.com>
Message-ID: <BANLkTi=t7RfnzGmvBzppRhEnexPAp6Bh13Jx=HC_HsahGzGVtw@mail.gmail.com>

2011/6/27 Philip Brown <phil at bolthole.com>:
> 2011/6/27 Maciej Blizi?ski <maciej at opencsw.org>:
>> 2011/6/27 Philip Brown <phil at bolthole.com>:
>>> 2011/6/26 Maciej Blizi?ski <maciej at opencsw.org>:
>>>>
>>>> The non-inclusion of reviews as a gating factor in the proposal is
>>>> intentional. ?It might of course change - but so far, it has been
>>>> group's intention not to involve a human controlling package releases.
>>>>
>>>> Peer reviews are an excellent mechanism to improve quality. ?My
>>>> intention is to create an environment in which maintainers want their
>>>> packages reviewed.
>>>
>>> providing some kind of positive motivation is nice. Its a great
>>> management strategy.
>>> but what could be used as sufficient motivation?
>>
>> My first thought is: giving helpful reviews! ?This does of course mean
>> pointing out issues, but also giving explanations why the issues in
>> question are important, and suggestions how to tackle them.
>
>
> Errr... not sure how that is motivational there. maybe I'm not
> understanding what you're saying.

The motivation can flow from the helpfulness of reviews.  It's the
"thank goodness my package was reviewed" feeling.  It's when a
maintainer is glad and grateful for the feedback which allowed them to
make their package better.

> On the other side of the field, ?I have a thought on motivation for
> the people doing the actual reviewing:
>
> Those who participate and do... (? x amount of package reviews per
> month/week, and also file 'y' amount of feedback/whatever?) could get
> to be recognized as being on "the review team" ?

Yes, sounds like a good idea.  Reviewing takes time and skill.  Only
having packages for review doesn't get them reviewed if there are no
reviewers around.  Recognition for doing reviews would definitely
help.

Maciej

From bwalton at opencsw.org  Mon Jun 27 21:29:21 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 27 Jun 2011 15:29:21 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
Message-ID: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>

Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:

Hi Jonathan,

> Here is my proposed amendment with the pre/post paragraphs to
> indicate placement within current proposal.  Wasn't really sure
> whether this was to be submitted by mail or simply edited into wiki
> page.

I approve of this addition.  I'd appreciate it if signers of the
current proposal provide an explicit ACK to this change (or a NACK as
they set fit).

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


From bwalton at opencsw.org  Mon Jun 27 21:32:34 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 27 Jun 2011 15:32:34 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTikVDBTDimaJi=XJ09Rz_XHn+ymqhg@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTikVDBTDimaJi=XJ09Rz_XHn+ymqhg@mail.gmail.com>
Message-ID: <1309202971-sup-990@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Jun 27 09:22:44 -0400 2011:

Hi Phil,

> So, to be clear: you are rejecting every single one of my wording
> amendments?  Even though some of them clearly point out that the
> proposal claims things that are false?

I'll give this another read tonight.

> It would be nice if you reviewed his comments on 2,4 & 5 more
> carefully also.

Fine.  I'll go over this again tonight and provide explicit feedback
on each point.  I didn't think that was still necessary, but I'm
obviously mistaken.  As we need a bit of time for people to ACK/NACK
Jonathan's addition to the proposal the vote can't start tonight
anyway.

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


From bonivart at opencsw.org  Mon Jun 27 21:33:15 2011
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 27 Jun 2011 21:33:15 +0200
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=a36kuat+Qv0Sr+JA4-MJc6y4_zQ@mail.gmail.com>

On Mon, Jun 27, 2011 at 9:29 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
>
> Hi Jonathan,
>
>> Here is my proposed amendment with the pre/post paragraphs to
>> indicate placement within current proposal. ?Wasn't really sure
>> whether this was to be submitted by mail or simply edited into wiki
>> page.
>
> I approve of this addition. ?I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).

OK with me as well.

/peter

From maciej at opencsw.org  Mon Jun 27 21:35:04 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 27 Jun 2011 20:35:04 +0100
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=muvM9DVAjzMngwLvMQOhO-wzTmmBOjgAKs-azRL9Xsg@mail.gmail.com>

2011/6/27 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
>
> Hi Jonathan,
>
>> Here is my proposed amendment with the pre/post paragraphs to
>> indicate placement within current proposal. ?Wasn't really sure
>> whether this was to be submitted by mail or simply edited into wiki
>> page.
>
> I approve of this addition. ?I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).

Looks good!

From trygvis at opencsw.org  Mon Jun 27 21:39:11 2011
From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=)
Date: Mon, 27 Jun 2011 21:39:11 +0200
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <4E08DC5F.3030603@opencsw.org>

On 6/27/11 9:29 PM, Ben Walton wrote:
> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
>
> Hi Jonathan,
>
>> Here is my proposed amendment with the pre/post paragraphs to
>> indicate placement within current proposal.  Wasn't really sure
>> whether this was to be submitted by mail or simply edited into wiki
>> page.
>
> I approve of this addition.  I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).

ACK

-- 
Trygve

From dam at opencsw.org  Mon Jun 27 21:45:34 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 27 Jun 2011 21:45:34 +0200
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <C5ED6319-920A-40DF-A84A-06910798FAF4@opencsw.org>

Am 27.06.2011 um 21:29 schrieb Ben Walton <bwalton at opencsw.org>:

> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
> 
> Hi Jonathan,
> 
>> Here is my proposed amendment with the pre/post paragraphs to
>> indicate placement within current proposal.  Wasn't really sure
>> whether this was to be submitted by mail or simply edited into wiki
>> page.
> 
> I approve of this addition.  I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).

+1

Best regards -- Dago

From maciej at opencsw.org  Mon Jun 27 22:01:54 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Mon, 27 Jun 2011 21:01:54 +0100
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <4DEA8DA4.8000304@opencsw.org>
References: <4DEA660B.4080102@opencsw.org>
	<BANLkTin9bLzDBgydfLKZfw8D5mj9QY6drg@mail.gmail.com>
	<4DEA8DA4.8000304@opencsw.org>
Message-ID: <BANLkTimAYUqm+4WmsOkCRNuCargPZEMbOVKx+DshKKxToR2RxQ@mail.gmail.com>

2011/6/4 John Ellson <ellson at opencsw.org>:
> What about gar scripts? ? Just "pkg-get -i gar" ?

There is also the mgar package, which I highly recommend.

It was recently impossible to run checkpkg in an off-buildfarm
setting.  Last week was a bugfix week for checkpkg, thanks to Igor who
attacked and didn't let go until checkpkg was working.  Currently,
checkpkg will work off-buildfarm if CATALOG_RELEASE is set to current
or unstable in your ~/.garrc.  I will send a separate, more detailed
update to the list later in the week.

Maciej

From skayser at opencsw.org  Mon Jun 27 22:08:44 2011
From: skayser at opencsw.org (Sebastian Kayser)
Date: Mon, 27 Jun 2011 22:08:44 +0200
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <20110627200844.GF25705@sebastiankayser.de>

* Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
> > Here is my proposed amendment with the pre/post paragraphs to
> > indicate placement within current proposal.  Wasn't really sure
> > whether this was to be submitted by mail or simply edited into wiki
> > page.
> 
> I approve of this addition.  I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).

ACK. Thanks guys!

Sebastian

From phil at bolthole.com  Tue Jun 28 02:54:06 2011
From: phil at bolthole.com (Philip Brown)
Date: Mon, 27 Jun 2011 17:54:06 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309180908-sup-782@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<BANLkTimcCoqjh6YM3tR68kvEXxfXfebOrw@mail.gmail.com>
	<BANLkTi=J-jCbPtTL8x3NZU5SCErq0rhrOw@mail.gmail.com>
	<BANLkTik1bXsWh+UMmiSxK-zzcCn6Q2Ev+g@mail.gmail.com>
	<1309180908-sup-782@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTimqPSX6pXJ5NtUTa6r_0CSehWE8Xw@mail.gmail.com>

On Mon, Jun 27, 2011 at 6:23 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Jun 27 09:08:39 -0400 2011:
>
>> People keep trying to force this into a "human, OR automated process",
>> and claiming this is what I want.
>> Yet not once have I advocated getting rid of the automated process. My
>> preference is for
>> "human examination, AND automated process".
>
> We currently have a human examination with 'automated' process wrapped
> around it. ?Normally we'd refer to this as status quo.


I guess there's a bit of ambiguity there. there is currently
"automated process" in the sense of compiler helpers and checks  in
gar.
But there isnt so much "automated process" with the   (take package,
and help it flow out to "current") part of things.

So in this context, "automated process" is best read as "automated
release & validation process".

I think a lot of the new proposal is very good in that reguard: making
that flow a less manual process gets a thumbs up from me; its way too
manual for my liking also. The amount of by-hand messing around with
files currently required is not a good thing in my opinion.

I also like the fact that the new proposal has *some* measure of
automated quality control, in the sense of the "check for bugs before
migrating from unstable  to current" stuff.

Additionally, there is great positive potential for the tie-in for
reviewers, in the other thread Maciej started.
All of these things are, in my opinion, better than "status quo".

I would not prefer things to remain "status quo" indefinately; I
myself would like to see most of the improvements suggested in the
proposal.  Just not 100% of them.

From bwalton at opencsw.org  Tue Jun 28 05:54:27 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 27 Jun 2011 23:54:27 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
Message-ID: <1309233097-sup-5348@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Jun 23 20:53:21 -0400 2011:

Hi Phil,

[In the future, please format your emails in a legible fashion.  It's
very hard to read through the seemingly random line breaks, extra long
lines, missing spaces, strange indentations, etc.]

> 1. Amendment: more technical details need to be given.  (perhaps as
> a side referenced document) The proposal suggests that opencsw adopt
> a "new system", without *fully* *defining* this new system at a
> technical level. There are some technical specifics, but not full
> coverage.  There is a lot of [will do, in the future] language
> without giving specifics.  OpenCSW is supposed to be a technical
> organization. It seems to me that we should be voting on specific
> full technical implementations, rather than something with fuzzy
> chunks in it

Some things are technical and require a full technical writeup.  Some
things are not technical.  While the changes required by this proposal
will be technical, this proposal is addressing an organizational
issue.  It says: We want to change directions and start automating the
release process.  This includes catalog updates, mirror pushes, QA
processes, etc.

While Maciej has written an excellent tool that handles a large
portion of what we think the details will look like, there is more yet
to do.  At the current time, writing all of the code and tools would
be counter-productive as we have not formally adopted the new
direction yet.  Determining all of the details to begin implementation
up front is equally pointless.

If the proposal is accepted, there is more discussion to be had.

> 2. Amendment: Removal of "Anyone can participate[in the new
> process]", and related lines.  This line falsely implies that
> currently, people are somehow blocked from participating now.  This
> is untrue, both at the direct package level and at the discussion
> level, as shown below. Therefore this red herring should be removed.
> (and possibly, maintainers should be re-informed of some facts):

Please don't pass this off as 'uninformed maintainers' as that is not
what you're dealing with here.  We're all well versed in how things
work.

Participation implies that people work together on an even footing to
advance a goal they share.  The current system is anything but
participatory.

In the sense of the proposal, this means that anyone is able to work
on the code or documentation.  Anyone will be able to review packages
and fully contribute to the QA process (regardless if their view lines
up with yours).  Anyone will be able to suggest modifications to the
process and if they're accepted, help implement them.

This does not describe the current process.

> At the discussion level, all packages "held" from release, are
> discussed in the pkgsubmissions mail list.  Right now, "anyone can
> participate" in the discussion of a held package.

People can talk until they're blue in the face, but unless we beat you
down with a vote (something that wasn't an option until the election,
I might add), packages don't flow unless you allow it.  Not
participatory.

Also, don't overlook the fact that currently packages might be
submitted privately.  Any ensuing discussion at that point is private.
The other party will still talk until they're blue in the face, but it
won't be visible to anyone else.

> At the direct package participation level: If a maintainer chooses
> to have their packages examined/tested before pushing them out to
> the general public, they can already drop them in "experimental" and
> ask that people look at them before publicly pushing them out to
> newpkgs.

"Pay no attention to the man behind the curtain."

This isn't what we're talking about here.  We're talking about holding
an equal status in the process.  To play on Jonathan's wording, we'd
see everyone be freemen instead of serfs.

> The fact that others rarely choose look at them now when a
> maintainer requests feedback, is not a failure of the current
> system, but rather an indication that maintainers rarely choose to
> look at other people's packages. It is doubtful that a wholesale
> "new system" will change that.

There is nothing to be gained presently as it doesn't matter what
anyone but the release manager thinks.  The new system lays the
groundwork for people to begin feeling as though participation might
be rewarding instead of masochistic.

> If people rarely even look at packages when a maintainer *specifically
> requests* feedback, it seems less likely when the whole thing is
> automated and there is no explicit request to do so.

Given that you've taken the 'anyone can participate' out of context,
I'll ignore this bit.

> 3. Removal or adjustment of "Packages are subject to stalls or
> rejections for non-policy reasons."
> 
> First of all, it implies, FALSELY, that a package can be completely
> rejected by the release manager with no recourse. As formalized in
> http://wiki.opencsw.org/release-manager , a maintainer can always
> call for a vote if they disagree with the stance that the release
> manager has taken. This has already happened, twice, and after the
> vote, the package(s) were released, so it is a proven effective
> method.

First off, a vote is a new found power tool that didn't exist until
the recent election (on paper yes, in practice no).  Before that it
was your way or no way, so please don't fall back on this "but you can
vote" line that you keep trotting out.  This is simply a delay that
you've needed to resort to in recent times when you feel that you know
better than everyone else but can't bend people to your way of
thinking...or tire them out.

Secondly, while it's true that we now have a big hammer to wield, it's
not something that a small group of people wish to use every time.  If
we resorted to this every time a package was rejected based on your
personal preference, we'd do nothing else.  Thus, _in practice_ you
can and do reject packages on a regular basis.

If you don't believe this, please review the list of stalled packages
in (and don't rely on the out of date 00-README that your
documentation indicates is the place to look).

Thirdly, the wiki page you linked to was only just written when
csw-upload-package was originally floated.  It is something you wrote
without soliciting any input or feedback.  You now provide that as a
reference to policy?  This is about as useful to the discussion as a
backronym is to knowing what /etc means.

> Additionally, it does not recognize the benefit that policy is not
> and should not be set in stone for all time. If a release manager
> holds a package, for reasons that are not currently policy, but
> perhaps should be, then it is a good thing that discussion take
> place. Similarly, it is actually a good thing if the issue gets
> forced to a vote, because that way, policy can be officially
> adjusted, as the majority vote decides.

If this is true, why were there no votes in the two years you yourself
were on the board?  Why did every issue raised end with the other
person giving up?  I agree that votes can be useful, but I submit for
the record (again!) that for a group our size, they're far too much
overhead just to overrule the opinion of a single person.

The proposal makes no claims that policy _should_ be set in stone for
all time.  It only states that the tools should enforce policy as it
currently exists.  This will require code changes over time to both
tighten and relax various checks.

The proposal also in no way inhibits new policy from being formed.
Issues worthy of policy modification can and will be discussed.  When
required, votes can decide the outcome.  My preference is for people
to agree to disagree and move on when they're outnumbered as that is
what happens in real life.  _Most_ people already do this.

> 4. Removal of "All code, tools and documentation will available for
> all to see and improve."  This falsely implies that there is "hidden
> code and/or tools". There is not.  All code that is actually
> necessary for the release process is already completely public and
> published.

Published where?  I don't see a complete list of tools anywhere so
this is hard to judge.

> Most other stuff isnt strictly "published", but is readable by any
> maintainer who actually cares, in my home directory on bender. It
> isnt much more than convenient aliases,etc. I have, akin to aliases
> in a .bashrc, etc.

Why isn't this published?  This is about as open as OpenVMS.  Look but
don't touch.  Do you really think that aliases in your shell
environment count as open to the public?

> The release process as a whole has been fully documented also.  If
> anyone cares to dispute this, then please point out specific areas
> or tools that either lack documentation, or are hidden.  I have
> previously requested this, when this claim was made recently, but
> was only met with groundless mumblings that things were still
> somehow "hidden", without any specifics given.

"A catalog update script is called..."  What script?  Where is it?
Your documentation is hand-wavy at best and nowhere near what you
routinely demand of others.  (Including here, as item #1!)  Nobody
(myself included) to my knowledge has requested specific improvements,
but you've not (ever) volunteered this type of improvement yourself.

You recently implemented a cron job to remind you to manually run some
part of the process.  Is this documented?

> 5. Removal of "unclear path to resolution of disputes" claim.  There
> is actually a clear path: discussion on pkgsubmissions list ->
> discussion on maintainers list -> vote if needed.  As far as
> complexity, this is virtually identical to the "new" path to
> resolution. The main difference is only that under the current
> system, a package deemed as "bad" will never be released, whereas
> under the "new" system, a package deemed as "bad" will first be
> released publically, but then after some indeterminate length of
> time.. potentially a **month or more**.. eventually be retracted.

I submit that this is not clear.  Especially to newcomers.  Any
attempts at clarifying this have met with the same thing we see here.
Delays.  Demands for fully formed policy that is never good enough.
Discussions that just don't end until the other party tires, etc.

Currently it can take a "**month or more**" to get good packages out
the door.  You've stated on several occasions that QA people
everywhere have the privileges that you exercise; This may be true,
but I submit that you've gone beyond this.  The tail, more often than
not, wags the dog.

> 6. Removal or adjustment of "All participants will have equal
> standing".  It would actually be harmful to opencsw to follow that
> sentiment completely. Specifically, to have two new maintainers sign
> off on each others packages, will inevitably lead to some mistakes
> that could be avoided by the oversight of more experienced
> maintainers.

First, please don't extrapolate the proposal to things that have not
been decided yet.  You're implying that there will be some sort of
sign-off process.  While it's not outside the realm of possibility
that there may come to be a system that resembles this, it is not a
part of the proposal.

(I would not support a system that sets us up for the master/slave
relationship again.)

Second, there is no need to remove or adjust this.  It's _what we
want_ Phil.  OpenCSW should encourage new people to publish packages.
Will they make mistakes?  Sure.  Will they learn as time goes on?
Sure.  The key point is that in the current system, interactions leave
them with a lot of stick and next to no carrot.  (While this isn't a
theoretical deficiency in the current package flow, it's a practical
one.)  By opening the process and giving new people an equal voice, we
intend to drastically change the carrot/stick ratio.

> 7. A technical implementation issue, that is not properly addressed
> in the proposal:
> 
> There is no such thing as a *fully* automated release system: at
> some point, issues come up that require manual intervention. For
> example, package renames, and removals. or fixing bugs in some
> unforseen interaction of the system and a new package.
> 
> The proposal declares that catalog signatures will be generated
> automatically. However, who or what group will be responsible to
> manage the catalog when the automated system is either inadequate,
> or fails?

This is covered quite adequately by Jonathan's proposed amendment.
Again, my thanks to Jonathan for providing constructive feedback.  As
long as Peter F, William and Geoff are ok with the change, this will
land on the proposal before the vote.

> 8. A technical implementation issue not addressed at all in the
> proposal: What about package takeovers? is it going to be allowable
> for any maintainer to take over any package, at any time? or remove
> any package at any time?

Please see answer #1

> 9. A technical implementation issue not addressed at all in the
> proposal:
> 
> "A package may not progress from unstable to current with open
> bugs."

Please see answer #1.

> 10. technical implementation suggestion:
> 
> If the goal is to make it *easier* for people to get involved in the
> QA process, I would suggest that either a different mechanism than
> bug filing be used, OR an alternative interface to the bug system be
> provided.  I personally feel that the existing "exchange emails over
> the pkgsubmissions mailing list" is the smallest pain point in this
> sort of process.  Forcing people to move to (our existing) bug
> system for this kind of discussion, makes it *more* difficult, not
> easier, to be involved in QA, in my opinion. It's possible other bug
> systems would do better; I'm just limiting my comments to our
> existing one.

Things like this will be good discussion if the proposal is adopted.
Nobody loves mantis and we've already discussed jira as a possible
upgrade.

I do however think that Jonathan is correct that a good bug tracking
system is the best place for these discussions.  Some things will need
to move to the list, but having a record of this discussion attached
in a meaningful way (meta data, in a sense) to the package is quite
helpful.

> 11. technical implementation issue:
> 
> "By opening up the QA process such that multiple people can easily
> participate and have equal standing on the matters at hand, we feel
> that overall package quality will improve;"
> 
> Unfortunately, (as mentioned on maintainers list previously), making
> the capability available, does not actually mean that people will
> definitely make use of it.  The new proposal as prototyped,
> currently allows for LESS people to scrutinize a package than
> currently.

Actually, it allows for more people to scrutinize a package, and more
easily at that.  As written, it simply requires less scrutiny.

> At the moment, a release manager is guaranteed to at least glance at
> it. Whereas with the "new process", a package may (and I claim, will
> *usually*) get released with no-one but the maintainer ever looking
> at it.

Once again, I'd note that you can and do just 'run the scripts' too.
If you take 'glance' to mean cut/paste the file name into the cli then
I'd accept your statement.  Other than that the words guaranteed and
glance taken to mean "inspected every package equally" do not apply to
the current process.

> If the goal is truly, "more/better QA", then a proposed remedy for
> this, is to put in mandatory hooks for the "migrate from unstable to
> current" step, to require that at least one other person besides
> maintainer has examined the package.

We have different views of how to achieve more/better QA.  You prefer
the parent/child approach while we'd treat everyone as adults.

You'd take status quo with a few new tools written.  We think the
status quo is not adequate for fostering new maintainers that might
grow to be capable of providing good QA or at the very least not
requiring it constantly.

We also think that QA as administered by feedback from other
maintainers and bug reports would be both more productive and more
encouraging than the current system.  This will lead to more
willingness to address issues that are found.  That leads directly to
improved quality.

The proposal does not say that quality will improve immediately, it
simply says that it will improve.  Maybe it will take time to shake
off the low morale and attract new blood?  Maybe things will spring
back to life quickly?  My crystal ball isn't working.  I do however
feel that quality will, at a minimum, not decline.

I'm a consumer of the packages we release and have no interest in
causing myself more work by allowing catalog quality to deteriorate.
As far as I know, all signers are also catalog consumers and feel the
same way.  (I suspect they all run more boxes than I do and have more
at stake.)

> If on the other hand, the goal is really "to allow packages to be
> released with no one but the maintainer ever looking at it", then
> all claims about better QA should be removed from the proposal, and
> the stated "benefits" of the proposal should be updated to reflect
> that.

Modification of the wording is only required if we feel your
statements are correct.  This is not in fact the goal of the proposal.

Thus concludes my response to your proposed amendments and requested
corrections.  Unless you have actual constructive requests that
improve the proposal without altering its intent, do not expect any
further replies from me on this matter.  One evening devoted to a
single person/response is enough.

When I've collected the remaining ACK/NACK for Jonathan's amendment,
we can move forward with the vote.

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


From gadavis at opencsw.org  Tue Jun 28 18:52:54 2011
From: gadavis at opencsw.org (Geoff Davis)
Date: Tue, 28 Jun 2011 09:52:54 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <D1AF23D7-479E-4B39-857C-0159F203DC83@opencsw.org>

I agree to it as well.

On Jun 27, 2011, at 12:29 PM, Ben Walton wrote:

> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
> 
> Hi Jonathan,
> 
>> Here is my proposed amendment with the pre/post paragraphs to
>> indicate placement within current proposal.  Wasn't really sure
>> whether this was to be submitted by mail or simply edited into wiki
>> page.
> 
> I approve of this addition.  I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).
> 
> 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 phil at bolthole.com  Tue Jun 28 19:59:37 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 28 Jun 2011 10:59:37 -0700
Subject: [csw-maintainers] tech board?
Message-ID: <BANLkTikwYONXfxXPPfZiVj4k7R-zabuGfg@mail.gmail.com>

This was taken from a longer reply to a different email. I think it
may merit separate discussion. . Up to you folks.


Ben wrote:
>  I agree that votes can be useful, but I submit for
> the record (again!) that for a group our size, they're far too much
> overhead just to overrule the opinion of a single person.
> [..]
>  My preference is for people
> to agree to disagree and move on when they're outnumbered as that is
> what happens in real life.  _Most_ people already do this.


When "a majority" of the group have spoken, this makes sense.
However, "for a group our size", having even 3 or 4 people chime in on
a technical issue, does not constitute a majority. It could be that
the majority is actually against the 3 or 4.

In contrast, if you think having things decided by a smaller number of
people is "more efficient"
or something, than having full membership votes, then I would suggest having a
"technical board"
put together, so that sort of thing could be worked out faster.
In that sort of situation, if the tech board is X people, and (X/2)+1
agree on something, then it could be considered settled.

I think the problem here might be that you may think that (you+personX+personY)
already compose a "tech board", so if those people agree, you think
everyone else
should give way.

To which I say, if you wish opencsw to work that way, then make the
"tech board"
a formal entity.
Until then, the only really "everyone's opinion is equal" appropriate
way to resolve deadlock,
 is a full vote, to make sure that everyone's opinion is equally heard.

From phil at bolthole.com  Tue Jun 28 20:30:45 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 28 Jun 2011 11:30:45 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309233097-sup-5348@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<1309233097-sup-5348@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=xY=TLU5jWJ0_oT1JBFPhFcm=siw@mail.gmail.com>

On Mon, Jun 27, 2011 at 8:54 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Thu Jun 23 20:53:21 -0400 2011:
>
> Hi Phil,
>
> [In the future, please format your emails in a legible fashion. ?It's
> very hard to read through the seemingly random line breaks, extra long
> lines, missing spaces, strange indentations, etc.]

Sorry, It's "gmail behaving badly", I suppose. (web interface).
I thought it was wrapping things appropriately, but I guess not. Suggestions
 on how to improve gmail configs
would be nice.

First of all, thank you for spending what was obviously considerable time
writing your response.
I appreciate that you were willing to put in that effort.

You went to more effort than I requested though. I only requested a re-review
 of 2-5.


On the negative side.. a chunk of what you wrote, was non-factual.
There was a chunk of ad-homimem attacks, and stating assumptions
about my motivation. You also spent many paragraphs writing about
"feelings".
Can we leave those out and have an objective discussion?

I will attempt to clip out all that stuff, and continue with a
fact-based discussion.

I also removed the parts where you factually responded to what I
wrote, such as #10.
Thank you for that.



>> 2. Amendment: Removal of "Anyone can participate[in the new
>> process]", and related lines. ?This line falsely implies that
>> currently, people are somehow blocked from participating now.
>...
> In the sense of the proposal, this means that anyone is able to work
> on the code or documentation. ?Anyone will be able to review packages
> and fully contribute to the QA process (regardless if their view lines
> up with yours). ?Anyone will be able to suggest modifications to the
> process and if they're accepted, help implement them.

I think perhaps there is ambiguity of wording then. I was reading it
as relating to just the day-to-day flow of packages, but it seems you
intend it to cover more meaning that that.

The current summary merely reads, "1. Anyone can participate".
I would like to suggest you expand it to include the meaning that you wrote
 above.
Perhaps, "1. Anyone can participate in shaping the code, documentation,
 and the overall process itself"




>>[3] First of all, it implies, FALSELY, that a package can be completely
>> rejected by the release manager with no recourse. As formalized in
>> http://wiki.opencsw.org/release-manager , a maintainer can always
>> call for a vote if they disagree with the stance that the release
>> manager has taken. This has already happened, twice, and after the
>> vote, the package(s) were released, so it is a proven effective
>> method.
>
> First off, a vote is a new found power tool that didn't exist until
> the recent election (on paper yes, in practice no).  Before that it
> was your way or no way,
[assumptions and accusations about motivation snipped]

you're essentially contradicting yourself. past situations are irrelevant:
what matters is current policy. current policy is that people can
request a vote on this sort of thing. Additionally, it is more than
theoretical: it has been done so twice, AND I have abided by
the vote without further complaint. So it is a proven effective
tool.
Therefore, please adjust the wording.


>> 11. technical implementation issue:
...
>> Unfortunately, (as mentioned on maintainers list previously), making
>> the capability available, does not actually mean that people will
>> definitely make use of it.  The new proposal as prototyped,
>> currently allows for LESS people to scrutinize a package than
>> currently.
>
> Actually, it allows for more people to scrutinize a package, and more
> easily at that.

what you wrote, does not contradict what I said. The new system as proposed,
allows both "more people" and *also* "less people", unless hooks are
put in to specifically  require "at least one other person".



    ##########################################

This ends my official response to your comments on the proposal.
I hope you will take a little extra time to consider them.

Below, is a response to some (but not all of the ) incorrect things you
wrote, that I would like to respond to, even though they are not directly
 bearing on the above.



> Also, don't overlook the fact that currently packages might be
> submitted privately. ?Any ensuing discussion at that point is private.
> The other party will still talk until they're blue in the face, but it
> won't be visible to anyone else.

You seem to be complaining on behalf of people who have no complaint.
I think I can accurately say that the people who choose to submit
packages privately to me, do so because we work well together, and they
that is the individual's choice. The people who do that, work well with
me. But if a problem occurs, they know that they always have recourse
to a public discussion of issues.


> ?If
> we resorted to this every time a package was rejected based on your
> personal preference, we'd do nothing else. ?Thus, _in practice_ you
> can and do reject packages on a regular basis.

This is a gross distortion of fact. You talk about "in practice". So,
"practically"
go do a count of how many packages have been "denied" in the manner
you describe, over the last 6 months.
(if you choose to do this, please be specific about package names)
No more than 3, I would guess.

1 vote every 2 months, is "doing nothing else"?
Please be more objective in the future.

> If you don't believe this, please review the list of stalled packages
> in [newpkgs]

you mean old files in newpkgs? that is not a valid way to tally this:
a lot of those are actually files that have just not been cleaned up properly,
when a maintainer submitted new files to fix issues with the older ones.
(sometimes due to renames)
a couple are ones that i myself should have removed on publishing,
 but missed them.
Some I think are ones where I pointed out clear, undisputed policy issues..
but the maintainer just forgot to come back to them.

If you took the time to actually go through the pkgsubmissions list and count
that way, I think it would be close to my estimate of 3 in 6 months.

I've taken the liberty to clean up some of the bogus lagging ones now.
but the others are
still there for now, simply because its a lot of hassle for me to go
dig up specifics for each
and every one.


> Thirdly, the wiki page you linked to [about release managers]
> was only just written when
> csw-upload-package was originally floated. ?It is something you wrote
> without soliciting any input or feedback. ?You now provide that as a
> reference to policy?


I wrote that as a summary for what I do in pratice.?I consider that a
"draft policy"; it describes our "de facto" existing policies accurately,
I think. It seemed appropriate that if people were voting against
"a release manager", they should at least have some definition about
what a release manager is and does.
If people cared enough about having a release manager, to have a
separate vote/discussion on that page, I'd be happy to see it amended.


> If this is true, why were there no votes in the two years you yourself
> were on the board? ?Why did every issue raised end with the other
> person giving up?

I would guess for two reasons:
1. we did not have a nice method of voting during that time
2. people may have incorrectly assumed that since I was President, I would
 either not allow the vote (ahem, sounds familiar), or not abide by it.
In both cases, such assumptions would have been incorrect.


[bit about technical issue resolution, moved to separate email,
  "tech board?" ]



>> 5. Removal of "unclear path to resolution of disputes" claim. ?There
>> is actually a clear path: discussion on pkgsubmissions list ->
>> discussion on maintainers list -> vote if needed. ?As far as
>> complexity, this is virtually identical to the "new" path to
>> resolution.
>....
>
> Currently it can take a "**month or more**" to get good packages out
> the door.

only very very rarely.

In real-world QA, that sometimes happens.
In the NEW system, that will most likely happen sometimes too.
Are you planning to put in some kind of "hey this has been waiting,
lets ignore all bug reports and publish it"! system?
If not, then this is a bogus comparison.

From pfelecan at opencsw.org  Tue Jun 28 22:05:29 2011
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 28 Jun 2011 22:05:29 +0200
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> (Ben Walton's
	message of "Mon, 27 Jun 2011 15:29:21 -0400")
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309202812-sup-7249@pinkfloyd.chass.utoronto.ca>
Message-ID: <x61uydwwl2.fsf@opencsw.org>

Ben Walton <bwalton at opencsw.org> writes:

> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
>
> Hi Jonathan,
>
>> Here is my proposed amendment with the pre/post paragraphs to
>> indicate placement within current proposal.  Wasn't really sure
>> whether this was to be submitted by mail or simply edited into wiki
>> page.
>
> I approve of this addition.  I'd appreciate it if signers of the
> current proposal provide an explicit ACK to this change (or a NACK as
> they set fit).

++

-- 
Peter

From pfelecan at opencsw.org  Tue Jun 28 22:33:01 2011
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 28 Jun 2011 22:33:01 +0200
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTik0VDmGGZXua0LNyd-H1W2sru7mbw@mail.gmail.com> (Philip
	Brown's message of "Sat, 25 Jun 2011 18:16:51 -0700")
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
	<BANLkTik0VDmGGZXua0LNyd-H1W2sru7mbw@mail.gmail.com>
Message-ID: <x6wrg5vgqq.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> How do you measure the "quality" of a programmer's work?
> At one point, IBM said, "We'll measure it based on KLOC".
> Epic Fail.
>
> After 40 years, there is still no uniform "metric" for that sort of
> thing. Nor is it possible to uniformly create one.
> Some kinds of quality are simply not possible to reduce to "metrics".

LOC is the beginning of effort measure. Not really a failure except when
used as a silver bullet. Quality measure starts when you assess cyclomatic
complexity, function point, regression, &c. But that is CS 101...
-- 
Peter

From phil at bolthole.com  Tue Jun 28 22:51:32 2011
From: phil at bolthole.com (Philip Brown)
Date: Tue, 28 Jun 2011 13:51:32 -0700
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <x6wrg5vgqq.fsf@opencsw.org>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
	<BANLkTik0VDmGGZXua0LNyd-H1W2sru7mbw@mail.gmail.com>
	<x6wrg5vgqq.fsf@opencsw.org>
Message-ID: <BANLkTinBXnZh-_oZwhjXVTVr1yOkGzKdpQ@mail.gmail.com>

On Tue, Jun 28, 2011 at 1:33 PM, Peter FELECAN <pfelecan at opencsw.org> wrote:
> Philip Brown <phil at bolthole.com> writes:
>
>> How do you measure the "quality" of a programmer's work?
>> At one point, IBM said, "We'll measure it based on KLOC".
>> Epic Fail.
>>
>> After 40 years, there is still no uniform "metric" for that sort of
>> thing. Nor is it possible to uniformly create one.
>> Some kinds of quality are simply not possible to reduce to "metrics".
>
> LOC is the beginning of effort measure. Not really a failure except when
> used as a silver bullet. (...)

yes and no. it can *sometimes* be useful as a relative measure. but
the problem lies in the management axiom of (make sure you reward what
you are really interested in).
When "more KLOC=good", programmers start to needlessly bloat programs.
  (the extra irony being that in reality, usually a program is good
specifically because it has fewer lines)
That type of scenario is true failure of applying metrics to a problem.

Probably many others here have also experienced the unwanted side
effects of other metrics gone bad. For example;
When metrics management people decide "bugs closed quickly=good", then
support people start "accidentally" closing bug reports that have been
open long enough to make them start looking bad.
And, curiously, there is no way to re-open the original bug, you must
create a whole new ticket. Resetting the time factor. What an amazing
coincidence

Similarly, when companies decide "few bugs filed=good", and motivate
staff based on low total bug count... and then the staff then proceeds
to make it almost impossible for people to actually open a bug.

Attempting to "increase quality" based on blind application of
metrics, can sometimes lead to places not originally intended. Even
when there is not deliberate subversion of the metrics like the above
examples... sometimes they subconciously skew people towards unwanted
behaviour.  So, metrics need to be applied cautiously.

From bwalton at opencsw.org  Thu Jun 30 02:45:56 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 29 Jun 2011 20:45:56 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
Message-ID: <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>

Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:

Hi Jonathan,

> Here is my proposed amendment with the pre/post paragraphs to indicate
> placement within current proposal.  Wasn't really sure whether this
> was to be submitted by mail or simply edited into wiki page.

William gave this an ACK in irc, so please go ahead and add the
paragraph to the proposal.  I hope he'll still send a mail to this
thread but I'd like to move forward.

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


From william at wbonnet.net  Thu Jun 30 06:53:27 2011
From: william at wbonnet.net (William Bonnet)
Date: Thu, 30 Jun 2011 06:53:27 +0200
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
Message-ID: <4E0C0147.4080100@wbonnet.net>

Hi all

Late late late .... :)

Sorry

Yes i do ack


cheers
W.
Le 30/06/2011 02:45, Ben Walton a ?crit :
> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011:
>
> Hi Jonathan,
>
>> Here is my proposed amendment with the pre/post paragraphs to indicate
>> placement within current proposal.  Wasn't really sure whether this
>> was to be submitted by mail or simply edited into wiki page.
> William gave this an ACK in irc, so please go ahead and add the
> paragraph to the proposal.  I hope he'll still send a mail to this
> thread but I'd like to move forward.
>
> Thanks
> -Ben
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>


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

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


From maciej at opencsw.org  Thu Jun 30 11:25:26 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 30 Jun 2011 10:25:26 +0100
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTinBXnZh-_oZwhjXVTVr1yOkGzKdpQ@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
	<BANLkTik0VDmGGZXua0LNyd-H1W2sru7mbw@mail.gmail.com>
	<x6wrg5vgqq.fsf@opencsw.org>
	<BANLkTinBXnZh-_oZwhjXVTVr1yOkGzKdpQ@mail.gmail.com>
Message-ID: <BANLkTin4ryHMFw2Y8viJsYkg3TWEx4+aCw@mail.gmail.com>

2011/6/28 Philip Brown <phil at bolthole.com>:
> Attempting to "increase quality" based on blind application of
> metrics, can sometimes lead to places not originally intended. Even
> when there is not deliberate subversion of the metrics like the above
> examples... sometimes they subconciously skew people towards unwanted
> behaviour. ?So, metrics need to be applied cautiously.

Certainly.  Does it mean that you agree that cautiously applied
metrics can be useful?  Or do you believe that there are no meaningful
metrics that can be used to assess the quality of our package catalog,
and the only thing we have to go on, is people's opinions?

Maciej

From phil at bolthole.com  Thu Jun 30 18:09:51 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 30 Jun 2011 09:09:51 -0700
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <BANLkTin4ryHMFw2Y8viJsYkg3TWEx4+aCw@mail.gmail.com>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
	<BANLkTik0VDmGGZXua0LNyd-H1W2sru7mbw@mail.gmail.com>
	<x6wrg5vgqq.fsf@opencsw.org>
	<BANLkTinBXnZh-_oZwhjXVTVr1yOkGzKdpQ@mail.gmail.com>
	<BANLkTin4ryHMFw2Y8viJsYkg3TWEx4+aCw@mail.gmail.com>
Message-ID: <BANLkTikCXTTO9jCRTg+gGVxk44B3qxX81A@mail.gmail.com>

2011/6/30 Maciej Blizi?ski <maciej at opencsw.org>:
> 2011/6/28 Philip Brown <phil at bolthole.com>:
>> Attempting to "increase quality" based on blind application of
>> metrics, can sometimes lead to places not originally intended. Even
>> when there is not deliberate subversion of the metrics like the above
>> examples... sometimes they subconciously skew people towards unwanted
>> behaviour. ?So, metrics need to be applied cautiously.
>
> Certainly. ?Does it mean that you agree that cautiously applied
> metrics can be useful?

yes.

From bwalton at opencsw.org  Thu Jun 30 21:33:12 2011
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 30 Jun 2011 15:33:12 -0400
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
	<4E0C0147.4080100@wbonnet.net>
	<1309461613-sup-5409@pinkfloyd.chass.utoronto.ca>
Message-ID: <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca>

> Excerpts from William Bonnet's message of Thu Jun 30 00:53:27 -0400 2011:

> Late late late .... :)

No problem.  Jonathan has now amended the proposal and the ballot is
ready to roll.

Phil: You're happy with the 'against the proposal' side of the vote
writeup?  (No longer labelled as 'status quo.')

I'm thinking July 1 - July 7 (GMT).

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


From maciej at opencsw.org  Thu Jun 30 22:13:30 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 30 Jun 2011 21:13:30 +0100
Subject: [csw-maintainers] Assessing catalog quality
In-Reply-To: <4E079060.5050104@wbonnet.net>
References: <BANLkTi=L-C46M+V2Q9MqgKfJpeZmy0mckw@mail.gmail.com>
	<BANLkTi=r3HujTZGW+5Kq-G7_5ZjgAGR5VQ@mail.gmail.com>
	<4E079060.5050104@wbonnet.net>
Message-ID: <BANLkTimDB+g-wP6DO6aRd_eDq8F1OuNtgpV2WKvzOkr4pHo5BQ@mail.gmail.com>

2011/6/26 William Bonnet <william at wbonnet.net>:
> Some of the indicators you mention already exist. I provide the url in the
> rest of the message. Let me know if you need to summarize all this under a
> specific "catalog qa page"

Cool, this is excellent stuff.

William, do you think we could extend your tech behind the package
count graph and use it to plot more data?  I imagine that there would
be a separate package with catalog metrics.  Can you share the
information on how to create graphs on our web site?

Maciej

From phil at bolthole.com  Thu Jun 30 22:46:46 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 30 Jun 2011 13:46:46 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
	<4E0C0147.4080100@wbonnet.net>
	<1309461613-sup-5409@pinkfloyd.chass.utoronto.ca>
	<1309462365-sup-8809@pinkfloyd.chass.utoronto.ca>
Message-ID: <BANLkTi=Uj7SB00x1iHjfmDmYPFtqE=ywug@mail.gmail.com>

On Thu, Jun 30, 2011 at 12:33 PM, Ben Walton <bwalton at opencsw.org> wrote:
>
> Phil: You're happy with the 'against the proposal' side of the vote
> writeup? ?(No longer labelled as 'status quo.')
>
> I'm thinking July 1 - July 7 (GMT).

I would like to request an "amendment" to the ballot itself.
The labeling has changed, but semantically, the meaning will be seen
as the same.

I request that there be an option for those people who see a value in
required 2nd party review, to be able to register that opinion with
their vote, separate from whether they support the new mechanisms for
package release flow.

As an example, based on the most recent ballot sample, my proposed
single added line would look like this:

A) I accept the proposal
*B) I would like to see the proposal modified to have some form of 2nd
party mandated review
C) I do not accept the proposal
D) I abstain


The specific nature of the review, or persons doing the review, will
remain open;
the purpose of this vote choice would not be to pick a specific
mechanism, but only to register that there is sufficient interest to
warrant discussion on it.

The "2nd party review"  might be via a formal review team. It might be
via an elected review manager. It might be through some other means.
It might be at initial entry, or it might be only for migration from
unstable to current. We havent discussed those things.

Rather than spend more time discuss those things right now, I'm
suggesting this be inserted as an option into this current vote, as a
time saver.

If either A or B were chosen, coding, development, etc. on the new
mechanisms would still proceed, so there would be virtually no "delay"
in that area either way. The only difference between the two, would be
that if a noticable amount of people voted for B, it would then be
shown as worthwhile to discuss options on review further, while work
continued to bring it to


Contrariwise, if there was only one person voting for B, it would be
clear that further discussion in that area would be a waste of time,
and that the issue is dead.

From maciej at opencsw.org  Thu Jun 30 22:54:50 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 30 Jun 2011 21:54:50 +0100
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=Uj7SB00x1iHjfmDmYPFtqE=ywug@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
	<4E0C0147.4080100@wbonnet.net>
	<1309461613-sup-5409@pinkfloyd.chass.utoronto.ca>
	<1309462365-sup-8809@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Uj7SB00x1iHjfmDmYPFtqE=ywug@mail.gmail.com>
Message-ID: <BANLkTinyGi0+ryVUD=T+P2UCUx_cpQcFHBQCvaBz=xukxoE1kA@mail.gmail.com>

2011/6/30 Philip Brown <phil at bolthole.com>:
> I request that there be an option for those people who see a value in
> required 2nd party review, (...)

The notion of reviews needs to be defined with more precision.  In one
understanding, a review means reading and providing feedback, with no
decision making.  In the other understanding, a review means reading
something and making the go / no go decision.  The difference is
crucial, and you need to specify which one you mean.

Maciej

From maciej at opencsw.org  Thu Jun 30 23:13:47 2011
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 30 Jun 2011 22:13:47 +0100
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=Uj7SB00x1iHjfmDmYPFtqE=ywug@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
	<4E0C0147.4080100@wbonnet.net>
	<1309461613-sup-5409@pinkfloyd.chass.utoronto.ca>
	<1309462365-sup-8809@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Uj7SB00x1iHjfmDmYPFtqE=ywug@mail.gmail.com>
Message-ID: <BANLkTi=Pt3X797JER3q0_jADO5nvh8RRzACjYrWGKg192RW7qQ@mail.gmail.com>

2011/6/30 Philip Brown <phil at bolthole.com>:
> On Thu, Jun 30, 2011 at 12:33 PM, Ben Walton <bwalton at opencsw.org> wrote:
>>
>> Phil: You're happy with the 'against the proposal' side of the vote
>> writeup? ?(No longer labelled as 'status quo.')
>>
>> I'm thinking July 1 - July 7 (GMT).
>
> I would like to request an "amendment" to the ballot itself.
> The labeling has changed, but semantically, the meaning will be seen
> as the same.
>
> I request that there be an option for those people who see a value in
> required 2nd party review, to be able to register that opinion with
> their vote, separate from whether they support the new mechanisms for
> package release flow.
>
> As an example, based on the most recent ballot sample, my proposed
> single added line would look like this:
>
> A) I accept the proposal
> *B) I would like to see the proposal modified to have some form of 2nd
> party mandated review
> C) I do not accept the proposal
> D) I abstain
>
>
> The specific nature of the review, or persons doing the review, will
> remain open;
> the purpose of this vote choice would not be to pick a specific
> mechanism, but only to register that there is sufficient interest to
> warrant discussion on it.
>
> The "2nd party review" ?might be via a formal review team. It might be
> via an elected review manager. It might be through some other means.
> It might be at initial entry, or it might be only for migration from
> unstable to current. We havent discussed those things.
>
> Rather than spend more time discuss those things right now, I'm
> suggesting this be inserted as an option into this current vote, as a
> time saver.
>
> If either A or B were chosen, coding, development, etc. on the new
> mechanisms would still proceed, so there would be virtually no "delay"
> in that area either way. The only difference between the two, would be
> that if a noticable amount of people voted for B, it would then be
> shown as worthwhile to discuss options on review further, while work
> continued to bring it to
>
>
> Contrariwise, if there was only one person voting for B, it would be
> clear that further discussion in that area would be a waste of time,
> and that the issue is dead.

Proposal processing goes like this:

1. A proposal is written
2. A vote is held, where options are: accepting, not accepting, abstaining
3. If the vote is conclusive and positive, the proposal is implemented

If you have an idea for another proposal, you can write it up and put
it up for the vote.  The same procedure will be applied.  Your
argument is that your proposal would be similar to the current one.
If this is the case, and the current proposal is accepted, you only
need to write up the difference, and we can have the other vote.

My role as the secretary is to implement the vote procedure, and the
procedure is described as above.  I'm sorry, but even if it is
suboptimal from your point of view, I am obliged to protect it and
ensure that the vote process reaches completion.

Maciej

From phil at bolthole.com  Thu Jun 30 23:54:32 2011
From: phil at bolthole.com (Philip Brown)
Date: Thu, 30 Jun 2011 14:54:32 -0700
Subject: [csw-maintainers] amendments and issues with recent prop
In-Reply-To: <BANLkTi=Pt3X797JER3q0_jADO5nvh8RRzACjYrWGKg192RW7qQ@mail.gmail.com>
References: <BANLkTi=dQCb-djX=bwZYV379m4vRzwdfwg@mail.gmail.com>
	<BANLkTi=2xXTnzptgERKQym7MrVuDC6+bTQ@mail.gmail.com>
	<1309009539-sup-9132@pinkfloyd.chass.utoronto.ca>
	<1309139539-sup-2937@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=4mOz5=JERaaYBUhoSmmXNkfqmxg@mail.gmail.com>
	<1309394682-sup-1467@pinkfloyd.chass.utoronto.ca>
	<4E0C0147.4080100@wbonnet.net>
	<1309461613-sup-5409@pinkfloyd.chass.utoronto.ca>
	<1309462365-sup-8809@pinkfloyd.chass.utoronto.ca>
	<BANLkTi=Uj7SB00x1iHjfmDmYPFtqE=ywug@mail.gmail.com>
	<BANLkTi=Pt3X797JER3q0_jADO5nvh8RRzACjYrWGKg192RW7qQ@mail.gmail.com>
Message-ID: <BANLkTi=vd3j_S5y63E8ND+Ajy-BLqh1PHA@mail.gmail.com>

2011/6/30 Maciej Blizi?ski <maciej at opencsw.org>:
>
> Proposal processing goes like this:
>
> 1. A proposal is written
> 2. A vote is held, where options are: accepting, not accepting, abstaining
> 3. If the vote is conclusive and positive, the proposal is implemented
>
> If you have an idea for another proposal, you can write it up and put
> it up for the vote. ?The same procedure will be applied. ?Your
> argument is that your proposal would be similar to the current one.
> If this is the case, and the current proposal is accepted, you only
> need to write up the difference, and we can have the other vote.
>
> My role as the secretary is to implement the vote procedure, and the
> procedure is described as above. ?I'm sorry, but even if it is
> suboptimal from your point of view, I am obliged to protect it and
> ensure that the vote process reaches completion.
>

When was the above procedure voted on? or approved "by consensus"? or
even brought up as a proposal for a discussion?
As far as I can recall. it wasnt.

So I'm missing how it is "your duty" to follow a process that was
never approved, to my knowledge?

Your description of duty to "protect" a proposal, seems rather odd. A
secretary of an organization is traditionally only a recorder and
processor of ballots, votes, and other similar duties.  Not a champion
or protector of any specific proposal.


also, I am fully encouraging that this "vote reaches completion". I'm
only requesting that the ballot have an additional choice box on it.

I'm not requesting on more discussion before the vote. only that the
vote have more choices on it. So there is nothing about this
threatening "completion of the vote"

From rupert.thurner at gmail.com  Thu Jun  2 16:30:44 2011
From: rupert.thurner at gmail.com (rupert THURNER)
Date: Thu, 02 Jun 2011 14:30:44 -0000
Subject: [csw-maintainers] --catalog-release does not exist ?
Message-ID: <BANLkTim+uFNXy-uy3-fDj9Sbr0DgdvbJpQ@mail.gmail.com>

what does the error message "--catalog-release does not exist" mean? and i
am wondering why this error message cannot be presented in 2 lines insead of
40 :)


$ csw-upload-pkg pkgs/02.Jun.2011/*
Processing 2 file(s). Please wait.
Uploading
'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz'
Uploading
'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz'
Checking 1 package(s) against catalog unstable sparc SunOS5.9
ERROR: --catalog-release does not exist
Checking 1 package(s) against catalog unstable i386 SunOS5.9
ERROR: --catalog-release does not exist
Checking 1 package(s) against catalog unstable sparc SunOS5.10
ERROR: --catalog-release does not exist
Checking 1 package(s) against catalog unstable i386 SunOS5.10
ERROR: --catalog-release does not exist
Checks failed for catalogs:
  - sparc SunOS5.9
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz
To see errors, run:
  /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9
--architecture sparc 5c73fa54a7b1e7fc0c3972748464c826
  - i386 SunOS5.9
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz
To see errors, run:
  /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9
--architecture i386 b2bb56a6f126713461695972ec8b9a3a
  - sparc SunOS5.10
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz
To see errors, run:
  /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.10
--architecture sparc 5c73fa54a7b1e7fc0c3972748464c826
  - i386 SunOS5.10
    mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz
To see errors, run:
6 b2bb56a6f126713461695972ec8b9a3a
Packages have not been submitted to the unstable catalog.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110602/367f7197/attachment-0001.html>

From maciej.blizinski at gmail.com  Sat Jun  4 19:42:06 2011
From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=)
Date: Sat, 04 Jun 2011 17:42:06 -0000
Subject: [csw-maintainers] how to set up a local buildhost?
In-Reply-To: <4DEA660B.4080102@opencsw.org>
References: <4DEA660B.4080102@opencsw.org>
Message-ID: <BANLkTimqOaf7fENv0iQWhMCUsmfvvwNLPA@mail.gmail.com>

Em 04/06/2011 18:06, "John Ellson" <ellson at opencsw.org> escreveu:
>
> Now that I have Solaris-10 running on a virtual host locally, is there
> an easy way I can set it up as a buildhost?
>
> If I could do that, I could use it to build the graphviz nightly
> development snapshots.

It is an excellent idea to set up a build host!

I have a partly written howto document. I can send you a copy and help you
with any issues you might run into along the way.

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110604/f14cd5fc/attachment-0001.html>

From shuttlebox at gmail.com  Sun Jun 12 04:06:14 2011
From: shuttlebox at gmail.com (Peter Bonivart)
Date: Sun, 12 Jun 2011 02:06:14 -0000
Subject: [csw-maintainers] Idea for a new check: binary name conflicts
In-Reply-To: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
References: <BANLkTikRM54nJXKkFtovcqB+rxZfk_U2zA@mail.gmail.com>
	<1307843586-sup-7663@pinkfloyd.chass.utoronto.ca>
Message-ID: <-3414185869384472853@unknownmsgid>

On 12 jun 2011, at 03:57, Ben Walton <bwalton at opencsw.org> wrote:

> Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011:
>
> Hi Maciej,
>
>> One of our guidelines has historically been to not provide binaries
>> in /opt/csw/bin named the same way as the ones in /usr/bin.  For
>> instance, bug 4533 has been filed because cups packages provide
>> /opt/csw/bin/lp which conflicts with /usr/bin/lp.
>
> I'm not sure I'd consider this a problem.  If you're using cups, you
> most likely want /opt/csw/bin/lp.  You don't want to have to learn new
> commands for things that have traditional names (lp, lpstat, etc)
> because cups is in play either.
>
>> What are your thoughts on adding a check for binary name conflicts?
>
> I don't see it as a conflict personally.  The filesystem provides a
> separate name space and we're using it.  If you want the system lp,
> either set the path accordingly or fully qualify it.  No point in
> jumping through hoops for something like this, imo.

I agree with Ben here.

/peter

From rupert.thurner at gmail.com  Sun Jun 26 09:08:12 2011
From: rupert.thurner at gmail.com (rupert THURNER)
Date: Sun, 26 Jun 2011 07:08:12 -0000
Subject: [csw-maintainers] wiki access?
Message-ID: <BANLkTinMymsQWT5CH7B+BKGvhAZT1jHMvw@mail.gmail.com>

i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would
not let me. joining returned:
 You can not apply.
It seems you have already applied for membership.
where does such an application go? it seems to be my fault that i cannot
remember when i applied, and not tracking it ...

rupert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110626/1a0972aa/attachment-0001.html>