From bonivart at opencsw.org  Fri Oct  1 00:13:25 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 1 Oct 2010 00:13:25 +0200
Subject: [csw-maintainers] Can't post to request list
Message-ID: <AANLkTimRMpG4Hpsh7m+60oi-jduHQKoCvHFOS_7CSVgP@mail.gmail.com>

I just built the three requested Perl modules from the request list
and wanted to answer the guy but my mail is rejected.

I think it's because I'm sending from gmail (as bonivart at opencsw.org),
however I do that to the other lists as well.

-- 
/peter

From dam at opencsw.org  Fri Oct  1 10:20:49 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 1 Oct 2010 10:20:49 +0200
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <AANLkTik1Yxcnf3yKEe1-vvpb9R1FsnDUSPbXP=6mVdKJ@mail.gmail.com>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<AANLkTik1Yxcnf3yKEe1-vvpb9R1FsnDUSPbXP=6mVdKJ@mail.gmail.com>
Message-ID: <0D924F58-0439-46C1-8DD1-9A1F6E9C2360@opencsw.org>

Hi,

Am 30.09.2010 um 20:35 schrieb Philip Brown:
>> 3. #2 above requires the updated cswclassutils also in my catalog.
>
> is it really appropriate to use a class action script for this? I'm
> not sure it is.
> and even if it is.... might it be more appropriate to split it out
> into it's own package?

I suggest moving the CAS to the package that delivers httpd.conf
We alredy do the same for texinfo, which delivers a CAS to add/
remove texinfo pages from the index.


Best regards

   -- Dago



From james at opencsw.org  Fri Oct  1 15:22:54 2010
From: james at opencsw.org (James Lee)
Date: Fri, 01 Oct 2010 13:22:54 GMT
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
Message-ID: <20101001.13225400.1309880630@gyor.oxdrove.co.uk>

On 30/09/10, 03:33:10, Ben Walton <bwalton at opencsw.org> wrote regarding 
[csw-maintainers] call for apache2 testing:

> I've placed what I think is a working set of apache2 packages in my
> experimental catalog.  The changes noted previously (package split
> re-org, alternatives, etc) still stand with a few other changes added:


1. Attempted to overwrite existing conf files:

apache2 - A high performance Unix-based HTTP server.(sparc) 
2.2.16,REV=2010.09.30
Please see /opt/csw/share/doc/apache2/license for license information.
## Processing package information.
## Processing system information.
   11 package pathnames are already properly installed.
## Verifying package dependencies.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.

The following files are already installed on the system and are being
used by another package:
* /opt/csw/apache2/etc/extra/httpd-mpm.conf
* /opt/csw/apache2/etc/extra/httpd-ssl.conf
  /opt/csw/apache2/sbin/httpd.prefork

Saying no means httpd.prefork isn't delivered.





2. It restarted in prefork mode although previously run as worker.





James.

From bwalton at opencsw.org  Fri Oct  1 15:25:31 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 01 Oct 2010 09:25:31 -0400
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <20101001.13225400.1309880630@gyor.oxdrove.co.uk>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
Message-ID: <1285939459-sup-154@pinkfloyd.chass.utoronto.ca>

Excerpts from James Lee's message of Fri Oct 01 09:22:54 -0400 2010:

Hi James,

> 1. Attempted to overwrite existing conf files:

Did you use pkg-get or pkgutil for this test?  I'm wondering what the
status of the original CSWapache2c package was when this happened.

> 2. It restarted in prefork mode although previously run as worker.

Hmm.  That's a problem indeed.  I'll have to think about this one.

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


From james at opencsw.org  Fri Oct  1 15:52:41 2010
From: james at opencsw.org (James Lee)
Date: Fri, 01 Oct 2010 13:52:41 GMT
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
	<1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
Message-ID: <20101001.13524100.2342954497@gyor.oxdrove.co.uk>

On 01/10/10, 14:25:31, Ben Walton <bwalton at opencsw.org> wrote regarding Re:
[csw-maintainers] call for apache2 testing:

> > 1. Attempted to overwrite existing conf files:

> Did you use pkg-get or pkgutil for this test?  I'm wondering what the
> status of the original CSWapache2c package was when this happened.

I can zfs rollback the machine and:

$ pkgchk -l -p /opt/csw/apache2/etc/extra/httpd-mpm.conf

$ pkgchk -l -p /opt/csw/apache2/etc/extra/httpd-mpm.conf.CSW
Pathname: /opt/csw/apache2/etc/extra/httpd-mpm.conf.CSW
Type: regular file
Expected mode: 0644
Expected owner: root
Expected group: bin
Expected file size (bytes): 3529
Expected sum(1) of contents: 32227
Expected last modification: Aug 22 15:46:39 2009
Referenced by the following packages:
        CSWapache2c
Current status: installed

it was installed without csw class action thus:

1 f none /opt/csw/apache2/etc/extra/httpd-mpm.conf.CSW 0644 root bin 3529
32227 1250952399

with a postinstall, excerpt:
...
UPGRADE_CONFIGS="\
    httpd.conf \
    ssl.conf \
    extra/httpd-ssl.conf \
    extra/httpd-mpm.conf \
    "
# Don't overwrite config if it exists
...





The new package has:

1 f none /opt/csw/apache2/etc/extra/httpd-mpm.conf 0644 root bin 3796
55204 1285813590
1 f none /opt/csw/apache2/etc/extra/httpd-mpm.conf.CSW 0644 root bin 3529
32227 1285813620

and I assume it should use class cswcpsampleconf




> > 2. It restarted in prefork mode although previously run as worker.

> Hmm.  That's a problem indeed.  I'll have to think about this one.

I'm playing being ignorant of how to use alternatives (very easy
because it's true) and letting update do its thing.  My expectation is
that it is left in the same mode after update as before.  Maybe a new
worker package can do the alternatives thing for me.



James.

From james at opencsw.org  Fri Oct  1 16:01:06 2010
From: james at opencsw.org (James Lee)
Date: Fri, 01 Oct 2010 14:01:06 GMT
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <20101001.13524100.2342954497@gyor.oxdrove.co.uk>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
	<1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
	<20101001.13524100.2342954497@gyor.oxdrove.co.uk>
Message-ID: <20101001.14010600.1362985201@gyor.oxdrove.co.uk>

On 01/10/10, 14:52:41, James Lee <james at opencsw.org> wrote regarding Re: 
[csw-maintainers] call for apache2 testing:

> I'm playing being ignorant of how to use alternatives (very easy
> because it's true)

PS:
http://www.opencsw.org/?s=alternatives

gives no clue!



James.


From dam at opencsw.org  Fri Oct  1 16:07:35 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 1 Oct 2010 16:07:35 +0200
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <20101001.14010600.1362985201@gyor.oxdrove.co.uk>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
	<1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
	<20101001.13524100.2342954497@gyor.oxdrove.co.uk>
	<20101001.14010600.1362985201@gyor.oxdrove.co.uk>
Message-ID: <6CA02CE2-4E1F-470F-A238-41D26DC901F3@opencsw.org>

Hi James,

Am 01.10.2010 um 16:01 schrieb James Lee:
> On 01/10/10, 14:52:41, James Lee <james at opencsw.org> wrote regarding  
> Re:
> [csw-maintainers] call for apache2 testing:
>
>> I'm playing being ignorant of how to use alternatives (very easy
>> because it's true)
>
> PS:
> http://www.opencsw.org/?s=alternatives
>
> gives no clue!

You are raising two points here which are already on the agenda:
1. Search needs to be working. AFAIK William is already working on it
2. We should have a wiki-page per package. It is
      http://wiki.opencsw.org/project-alternatives
    but unfortunately not linked from the main site :-(


Best  regards

   -- Dago

From bwalton at opencsw.org  Fri Oct  1 16:10:03 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 01 Oct 2010 10:10:03 -0400
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <20101001.13524100.2342954497@gyor.oxdrove.co.uk>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
	<1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
	<20101001.13524100.2342954497@gyor.oxdrove.co.uk>
Message-ID: <1285942050-sup-1145@pinkfloyd.chass.utoronto.ca>

Excerpts from James Lee's message of Fri Oct 01 09:52:41 -0400 2010:

Hi James,

Thanks for this info.  I need to twiddle the prototype a bit here to
that httpd-mpm.conf isn't delivered in the package at all.

> 1 f none /opt/csw/apache2/etc/extra/httpd-mpm.conf 0644 root bin 3796
> 55204 1285813590
> 1 f none /opt/csw/apache2/etc/extra/httpd-mpm.conf.CSW 0644 root bin 3529
> 32227 1285813620
> 
> and I assume it should use class cswcpsampleconf

No, not yet.  It will eventually, but I need to do a whole bunch of
stuff with the etc/ for apache and I don't want to do that with this
update.

> > Hmm.  That's a problem indeed.  I'll have to think about this one.
> 
> I'm playing being ignorant of how to use alternatives (very easy
> because it's true) and letting update do its thing.  My expectation
> is that it is left in the same mode after update as before.  Maybe a
> new worker package can do the alternatives thing for me.

This is likely what I'll have to do.  Re-instate the dummy
CSWap2worker package that does nothing but run a postinstall script
that drives a call to alternatives --set.  I'll need an updated
CSWalternatives first though, as the current implementation of --set
is broken (bug filed yesterday).

I'll ensure there is a message noted about using alternatives to
toggle the mpm.

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


From james at opencsw.org  Fri Oct  1 16:14:32 2010
From: james at opencsw.org (James Lee)
Date: Fri, 01 Oct 2010 14:14:32 GMT
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <6CA02CE2-4E1F-470F-A238-41D26DC901F3@opencsw.org>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
	<1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
	<20101001.13524100.2342954497@gyor.oxdrove.co.uk>
	<20101001.14010600.1362985201@gyor.oxdrove.co.uk>
	<6CA02CE2-4E1F-470F-A238-41D26DC901F3@opencsw.org>
Message-ID: <20101001.14143200.2830487273@gyor.oxdrove.co.uk>

On 01/10/10, 15:07:35, Dagobert Michelsen <dam at opencsw.org> wrote regarding 
Re: [csw-maintainers] call for apache2 testing:

> >> I'm playing being ignorant of how to use alternatives (very easy
> >> because it's true)
> >
> > PS:
> > http://www.opencsw.org/?s=alternatives
> >
> > gives no clue!

> You are raising two points here which are already on the agenda:
> 1. Search needs to be working. AFAIK William is already working on it

http://www.google.co.uk/search?q=site:www.opencsw.org+alternatives

Gives no more clue.  I suggest that there has to be something to find
before it can be found, (URLs to the alternatives documentation page
accepted as evidence that search is not working).



James.


From james at opencsw.org  Fri Oct  1 16:20:47 2010
From: james at opencsw.org (James Lee)
Date: Fri, 01 Oct 2010 14:20:47 GMT
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <1285942050-sup-1145@pinkfloyd.chass.utoronto.ca>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<20101001.13225400.1309880630@gyor.oxdrove.co.uk>
	<1285939459-sup-154@pinkfloyd.chass.utoronto.ca>
	<20101001.13524100.2342954497@gyor.oxdrove.co.uk>
	<1285942050-sup-1145@pinkfloyd.chass.utoronto.ca>
Message-ID: <20101001.14204700.3619874132@gyor.oxdrove.co.uk>

On 01/10/10, 15:10:03, Ben Walton <bwalton at opencsw.org> wrote regarding Re: 
[csw-maintainers] call for apache2 testing:

> > I'm playing being ignorant of how to use alternatives (very easy
> > because it's true) and letting update do its thing.  My expectation
> > is that it is left in the same mode after update as before.  Maybe a
> > new worker package can do the alternatives thing for me.

> This is likely what I'll have to do.  Re-instate the dummy
> CSWap2worker package that does nothing but run a postinstall script
> that drives a call to alternatives --set.  I'll need an updated
> CSWalternatives first though, as the current implementation of --set
> is broken (bug filed yesterday).

> I'll ensure there is a message noted about using alternatives to
> toggle the mpm.

There is a message but it's easily lost and didn't tell me ho to get
the worker or any hint on what alternatives is.  Part of the problem
is that alternatives itself is a mystery.


<message>

Hello CSW User/Sysadmin,

Please note that some recent changes to packages may affect the way
you're used to working with the CSW apache2 packages.

In the past, CSWap2prefork and CSWap2worker delivered a specific mpm
module for use with apache2.  We now ship both mpm modules as part of
CSWapache2 and allow you to toggle between them using the alternatives
support that recently materialized.  The default mpm is prefork.

We still provide CSWap2prefork and CSWap2worker for the time being,
but they're dummy packages used only to fill dependencies.

Thanks
-The OpenCSW apache2 team.

</message>



James.

From phil at bolthole.com  Fri Oct  1 19:46:18 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 1 Oct 2010 10:46:18 -0700
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <0D924F58-0439-46C1-8DD1-9A1F6E9C2360@opencsw.org>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<AANLkTik1Yxcnf3yKEe1-vvpb9R1FsnDUSPbXP=6mVdKJ@mail.gmail.com>
	<0D924F58-0439-46C1-8DD1-9A1F6E9C2360@opencsw.org>
Message-ID: <AANLkTi=TAX2_RHp7sHV-g4sHiU++Lgj7VFqq6nyki-v1@mail.gmail.com>

On 10/1/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> I suggest moving the CAS to the package that delivers httpd.conf
> We alredy do the same for texinfo, which delivers a CAS to add/
> remove texinfo pages from the index.
>

This makes the most sense to me. Ben, do you agree?

From bwalton at opencsw.org  Fri Oct  1 19:50:43 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 01 Oct 2010 13:50:43 -0400
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <AANLkTi=TAX2_RHp7sHV-g4sHiU++Lgj7VFqq6nyki-v1@mail.gmail.com>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
	<AANLkTik1Yxcnf3yKEe1-vvpb9R1FsnDUSPbXP=6mVdKJ@mail.gmail.com>
	<0D924F58-0439-46C1-8DD1-9A1F6E9C2360@opencsw.org>
	<AANLkTi=TAX2_RHp7sHV-g4sHiU++Lgj7VFqq6nyki-v1@mail.gmail.com>
Message-ID: <1285955400-sup-7249@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Oct 01 13:46:18 -0400 2010:

> > I suggest moving the CAS to the package that delivers httpd.conf
> > We alredy do the same for texinfo, which delivers a CAS to add/
> > remove texinfo pages from the index.
> >
> 
> This makes the most sense to me. Ben, do you agree?

I do and it's already done. :)  (No test packages yet, that's my job
this evening.)

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


From phil at bolthole.com  Sat Oct  2 01:37:16 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 1 Oct 2010 16:37:16 -0700
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
Message-ID: <AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>

I will preface my email, with the general premise: "Life is not simple".
It would be lovely if there were a nice clean way to deal with this...
but lets face facts, rather than to deny them. There Is No simple
clean automated, "always applies" solution to this.

That being said, lets move on to discuss what Can be done, in the face
of life's messy realities :)



On 9/29/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> ....
> file=opt/csw/lib/libavcodec-0.4.9-pre1.so pkgname=CSWffmpeg
> expected=['CSWlibavcodec-0-4-9-pre1']
> file=opt/csw/lib/libavformat-0.4.9-pre1.so pkgname=CSWffmpeg
> expected=['CSWlibavformat-0-4-9-pre1']
> file=opt/csw/lib/libpostproc.so.0.0.1 pkgname=CSWffmpeg
> expected=['CSWlibpostproc0', 'CSWlibpostproc-0']
>
> With these three, I don't know myself - does it make sense to separate
> these 3 libraries?  Two of them seem to have the version in sync, but
> the version is entangled with the library name, instead of being
> located after the ".so" bit, where nature intended.
>

This is exactly the sort of thing I envisioned running into. Thank you
for doing the hard research to dig up a specific example.
This example is extra complicated, since there is NO SONAME to any of them.
interestingly, though, there is a cross-dependancy in the libs themselves.
libavformat needs libavcodec.
Interestingly, however, it needs, by name, "libavcodec.so". no rev.

So in this case, it would serve no purpose whatsoever to split the
libraries out from the main ffmpeg package, or to split them up
independantly. A newer version of the package will transparently
update older versions, it would seem.


I think you might do well to go with my original theory, slightly expanded:

Unless you find a shared object, of filename "lib*.so*", AND it has a
"SONAME", AND that name has a double-numeric rev  (eg:
libfoo.so.#.#), then you should just leave it alone.

From maciej at opencsw.org  Sun Oct  3 08:16:53 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sat, 2 Oct 2010 23:16:53 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs
	pm_cryptpasswdmd5, pm_passwdunix, pm_(...)
In-Reply-To: <AANLkTinWtU4Dmh5ggzk1sFFj-r=H5rONOmFVaYFzFPov@mail.gmail.com>
References: <201010011423.o91ENchq003415@login.bo.opencsw.org>
	<AANLkTimT38QV33Dr2-Y252At0dYYrCvxvwU0JZhJrd2+@mail.gmail.com>
	<AANLkTimcbMvD7MfCBh5KUxRtkFHreUdP0K8vD9tRdyTg@mail.gmail.com>
	<AANLkTinWtU4Dmh5ggzk1sFFj-r=H5rONOmFVaYFzFPov@mail.gmail.com>
Message-ID: <AANLkTikxbr+a5mxYMPrvFpD+gt=BV8NxwL11sfZ_ZgLa@mail.gmail.com>

[+maintainers]

No dia 2 de Outubro de 2010 09:18, Philip Brown <phil at bolthole.com> escreveu:
> On Saturday, October 2, 2010, Peter Bonivart <bonivart at opencsw.org> wrote:
>
>
>> Can't you run your collision thingy on the whole catalog and we will
>> start a project to fix all of these problems? This instance was a new
>> mistake but we've had lurking collisions out there before and I'm sure
>> there are more of them.
>
>
> unfortunately,
>
> - the mechanisms aren't set up to make that sort of thing easy
> - there are indeed many more, if I recall :(

Yes, there's more.  All that I could find are here in this file:

http://buildfarm.opencsw.org/~maciej/file-conflicts.csv

It's based on the current catalog for sparc from about two days ago,
so pretty fresh.  The first column in the table is maintainer name, so
everyone can easily find their packages.

From bonivart at opencsw.org  Sun Oct  3 08:31:18 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 3 Oct 2010 08:31:18 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs
	pm_cryptpasswdmd5, pm_passwdunix, pm_(...)
In-Reply-To: <AANLkTikxbr+a5mxYMPrvFpD+gt=BV8NxwL11sfZ_ZgLa@mail.gmail.com>
References: <201010011423.o91ENchq003415@login.bo.opencsw.org>
	<AANLkTimT38QV33Dr2-Y252At0dYYrCvxvwU0JZhJrd2+@mail.gmail.com>
	<AANLkTimcbMvD7MfCBh5KUxRtkFHreUdP0K8vD9tRdyTg@mail.gmail.com>
	<AANLkTinWtU4Dmh5ggzk1sFFj-r=H5rONOmFVaYFzFPov@mail.gmail.com>
	<AANLkTikxbr+a5mxYMPrvFpD+gt=BV8NxwL11sfZ_ZgLa@mail.gmail.com>
Message-ID: <AANLkTimjYWFsqw4W1M8g6MP80FYvCeZjsFQeC5O9xZg_@mail.gmail.com>

On Sun, Oct 3, 2010 at 8:16 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> Yes, there's more. ?All that I could find are here in this file:
>
> http://buildfarm.opencsw.org/~maciej/file-conflicts.csv
>
> It's based on the current catalog for sparc from about two days ago,
> so pretty fresh. ?The first column in the table is maintainer name, so
> everyone can easily find their packages.

Thank you Maciej! Great work!

However, you forgot to state your ransom demands like Phil did. Or is
this free? :-)

-- 
/peter

From bonivart at opencsw.org  Sun Oct  3 17:37:46 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 3 Oct 2010 17:37:46 +0200
Subject: [csw-maintainers] How to deal with collisions?
Message-ID: <AANLkTim1ScUGvncprEGYvZ3DaqKezWwSao-wULBoS00d@mail.gmail.com>

Most of my collisions are with CSWperldoc, the documentation package
for Perl. Newer modules than Perl contains include the same man pages
in the same locations which causes the collisions.

I have no problem with removing the man pages from the module packages
since most users will never look at them anyway. On the other hand,
someone who installs CSWperldoc expects to get man pages! So no
problem there.

Different case with other files though. Below you see a few collisions
of executables, both the included in CSWperl executable and the one
from the module package go into /opt/csw/bin.

In this case it's harder to know what to do. If I remove the
executable from the module package functionality may be affected which
is worse than a somewhat outdated man page.

What to do? Deliver to another location and using alternatives? Too complicated?

Delete every module package in our catalog that causes these problems?
We're pretty up to date with Perl nowadays so the version difference
between what's included and what we can deliver in a separate package
may be marginal. The five collisions below are from only two packages.

bonivart,CSWpmmodcorelist,file-conflict,"/opt/csw/bin/corelist CSWperl
CSWpmmodcorelist"
bonivart,CSWperl,file-conflict,"/opt/csw/bin/corelist CSWperl CSWpmmodcorelist"
bonivart,CSWperl,file-conflict,"/opt/csw/bin/cpan2dist CSWperl CSWpmcpanplus"
bonivart,CSWperl,file-conflict,"/opt/csw/bin/cpanp CSWperl CSWpmcpanplus"
bonivart,CSWperl,file-conflict,"/opt/csw/bin/cpanp-run-perl CSWperl
CSWpmcpanplus"

This is the 3rd case where the actual modules are colliding:

bonivart,CSWpmtstbldrtester,file-conflict,"/opt/csw/share/perl/csw/Test/Builder/Tester.pm
CSWpmtestsimple CSWpmtstbldrtester"
bonivart,CSWpmtstbldrtester,file-conflict,"/opt/csw/share/perl/csw/Test/Builder/Tester/Color.pm
CSWpmtestsimple CSWpmtstbldrtester"

Two modules shouldn't use the same path..?

-- 
/peter

From dam at opencsw.org  Sun Oct  3 22:35:06 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 3 Oct 2010 22:35:06 +0200
Subject: [csw-maintainers] How to deal with collisions?
In-Reply-To: <AANLkTim1ScUGvncprEGYvZ3DaqKezWwSao-wULBoS00d@mail.gmail.com>
References: <AANLkTim1ScUGvncprEGYvZ3DaqKezWwSao-wULBoS00d@mail.gmail.com>
Message-ID: <02DC3593-27A2-4222-A489-BA38E1464974@opencsw.org>

Hi Peter,

Am 03.10.2010 um 17:37 schrieb Peter Bonivart:
> Most of my collisions are with CSWperldoc, the documentation package
> for Perl. Newer modules than Perl contains include the same man pages
> in the same locations which causes the collisions.
>
> I have no problem with removing the man pages from the module packages
> since most users will never look at them anyway.

The relevant question is: Does CSWperl contains the modules which
CSWperldoc documents and vice versa?

> On the other hand,
> someone who installs CSWperldoc expects to get man pages! So no
> problem there.
>
> Different case with other files though. Below you see a few collisions
> of executables, both the included in CSWperl executable and the one
> from the module package go into /opt/csw/bin.
>
> In this case it's harder to know what to do. If I remove the
> executable from the module package functionality may be affected which
> is worse than a somewhat outdated man page.
>
> What to do? Deliver to another location and using alternatives? Too  
> complicated?

I would say so. It would allow us to selectively either just go with
what CSWperl has or go to more modern version module-by-module
allowing fine-grained dependencies.

> Delete every module package in our catalog that causes these problems?
> We're pretty up to date with Perl nowadays so the version difference
> between what's included and what we can deliver in a separate package
> may be marginal. The five collisions below are from only two packages.
>
> bonivart,CSWpmmodcorelist,file-conflict,"/opt/csw/bin/corelist CSWperl
> CSWpmmodcorelist"
> bonivart,CSWperl,file-conflict,"/opt/csw/bin/corelist CSWperl  
> CSWpmmodcorelist"
> bonivart,CSWperl,file-conflict,"/opt/csw/bin/cpan2dist CSWperl  
> CSWpmcpanplus"
> bonivart,CSWperl,file-conflict,"/opt/csw/bin/cpanp CSWperl  
> CSWpmcpanplus"
> bonivart,CSWperl,file-conflict,"/opt/csw/bin/cpanp-run-perl CSWperl
> CSWpmcpanplus"

If the version in the base Perl is current enough I would vote for  
dropping
the "other" package (or move to alternatives which would allow an update
at a later time without sacrificing anything).

> This is the 3rd case where the actual modules are colliding:
>
> bonivart,CSWpmtstbldrtester,file-conflict,"/opt/csw/share/perl/csw/ 
> Test/Builder/Tester.pm
> CSWpmtestsimple CSWpmtstbldrtester"
> bonivart,CSWpmtstbldrtester,file-conflict,"/opt/csw/share/perl/csw/ 
> Test/Builder/Tester/Color.pm
> CSWpmtestsimple CSWpmtstbldrtester"
>
> Two modules shouldn't use the same path..?

Definitely not. I guess this must be discusses upstream, so maybe
we should file some bugs at rt.cpan.org.


Best regards

   -- Dago


From bonivart at opencsw.org  Mon Oct  4 11:22:20 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 4 Oct 2010 11:22:20 +0200
Subject: [csw-maintainers] How to deal with collisions?
In-Reply-To: <02DC3593-27A2-4222-A489-BA38E1464974@opencsw.org>
References: <AANLkTim1ScUGvncprEGYvZ3DaqKezWwSao-wULBoS00d@mail.gmail.com>
	<02DC3593-27A2-4222-A489-BA38E1464974@opencsw.org>
Message-ID: <AANLkTimDm6OxVNmomR19ENfY+XdPabBmfTu=3FrQS4NO@mail.gmail.com>

On Sun, Oct 3, 2010 at 10:35 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> This is the 3rd case where the actual modules are colliding:
>>
>> bonivart,CSWpmtstbldrtester,file-conflict,"/opt/csw/share/perl/csw/Test/Builder/Tester.pm
>> CSWpmtestsimple CSWpmtstbldrtester"
>>
>> bonivart,CSWpmtstbldrtester,file-conflict,"/opt/csw/share/perl/csw/Test/Builder/Tester/Color.pm
>> CSWpmtestsimple CSWpmtstbldrtester"
>>
>> Two modules shouldn't use the same path..?
>
> Definitely not. I guess this must be discusses upstream, so maybe
> we should file some bugs at rt.cpan.org.

Ok, my package, CSWpmtstbldrtester, should be removed. Your package,
CSWpmtestsimple, officially contains Test::Builder::Tester and
Test::Builder::Tester::Color.

Phil: please remove CSWpmtstbldrtester from the catalog.

-- 
/peter

From dam at opencsw.org  Mon Oct  4 14:40:41 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 4 Oct 2010 14:40:41 +0200
Subject: [csw-maintainers] Alternatives (was: [csw-devel] SF.net SVN:
	gar:[11132] csw/mgar/pkg/alternatives/trunk)
References: <E1P26Kc-0007WM-0G@sfp-svn-2.v30.ch3.sourceforge.com>
Message-ID: <D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org>

Hi Phil,

Anfang der weitergeleiteten E-Mail:
> Added: csw/mgar/pkg/alternatives/trunk/README
> ===================================================================
> --- csw/mgar/pkg/alternatives/trunk/README	                         
> (rev 0)
> +++ csw/mgar/pkg/alternatives/trunk/README	2010-10-02 17:57:09 UTC  
> (rev 11132)
> @@ -0,0 +1,7 @@
> +A quickie readme for the future, about this "alternatives"  
> implementation:
> +
> +Phil decided that a from-scratch, CSW-custom implementation was  
> needed,
> +because the debian one was hugely bloated, and the redhat smaller  
> one,
> +did not play nicely with NFS-shared /opt/csw
> +So pleaes dont go getting ideas that we can migrated back to  
> redhat,etc
> +in the future! :) we tried, and it failed.

?hhhh, what? At least I cannot remember that it failed. You insisted
to rewrite the otherwise fully working RedHat implementation just
because of the NFS-Share /opt/csw issue. And after seeing all these
issues with the rewrite the big question is: is it worth it?


Best regards

   -- Dago


From pfelecan at opencsw.org  Mon Oct  4 17:01:35 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 04 Oct 2010 17:01:35 +0200
Subject: [csw-maintainers] Alternatives (was: [csw-devel] SF.net SVN:
	gar:[11132] csw/mgar/pkg/alternatives/trunk)
In-Reply-To: <D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org> (Dagobert
	Michelsen's message of "Mon, 4 Oct 2010 14:40:41 +0200")
References: <E1P26Kc-0007WM-0G@sfp-svn-2.v30.ch3.sourceforge.com>
	<D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org>
Message-ID: <x6lj6e57e8.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Phil,
>
> Anfang der weitergeleiteten E-Mail:
>> Added: csw/mgar/pkg/alternatives/trunk/README
>> ===================================================================
>> --- csw/mgar/pkg/alternatives/trunk/README
>> (rev 0)
>> +++ csw/mgar/pkg/alternatives/trunk/README	2010-10-02 17:57:09
>> UTC (rev 11132)
>> @@ -0,0 +1,7 @@
>> +A quickie readme for the future, about this "alternatives"
>> implementation:
>> +
>> +Phil decided that a from-scratch, CSW-custom implementation was
>> needed,
>> +because the debian one was hugely bloated, and the redhat smaller
>> one,
>> +did not play nicely with NFS-shared /opt/csw
>> +So pleaes dont go getting ideas that we can migrated back to
>> redhat,etc
>> +in the future! :) we tried, and it failed.
>
> ?hhhh, what? At least I cannot remember that it failed. You insisted
> to rewrite the otherwise fully working RedHat implementation just
> because of the NFS-Share /opt/csw issue. And after seeing all these
> issues with the rewrite the big question is: is it worth it?

IMO not. People over the pond always said that NIH (Not Invented Here)
is an European engineer syndrome. The question is: why reinvent the
wheel? I thought that building on existing component was one of the open
source software advantages. If the RedHat version is 99% adapted to our
distribution (BTW which are the differences with the Debian version?)
why not use-it, even if we maintain a set of specific patches?
-- 
Peter

From phil at opencsw.org  Mon Oct  4 18:40:33 2010
From: phil at opencsw.org (Philip Brown)
Date: Mon, 4 Oct 2010 09:40:33 -0700
Subject: [csw-maintainers] How to deal with collisions?
In-Reply-To: <AANLkTimDm6OxVNmomR19ENfY+XdPabBmfTu=3FrQS4NO@mail.gmail.com>
References: <AANLkTim1ScUGvncprEGYvZ3DaqKezWwSao-wULBoS00d@mail.gmail.com>
	<02DC3593-27A2-4222-A489-BA38E1464974@opencsw.org>
	<AANLkTimDm6OxVNmomR19ENfY+XdPabBmfTu=3FrQS4NO@mail.gmail.com>
Message-ID: <AANLkTinnXmrb11Bxtdrb_GE+s=0ugsCT=UL+iWnW8w2V@mail.gmail.com>

On 10/4/10, Peter Bonivart <bonivart at opencsw.org> wrote:
>
> Ok, my package, CSWpmtstbldrtester, should be removed. Your package,
> CSWpmtestsimple, officially contains Test::Builder::Tester and
> Test::Builder::Tester::Color.
>
> Phil: please remove CSWpmtstbldrtester from the catalog.
>

I presume you mean "from the sol9 and 10 catalogs".

done. will be finalized on next push.

From phil at bolthole.com  Mon Oct  4 18:47:03 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 4 Oct 2010 09:47:03 -0700
Subject: [csw-maintainers] Alternatives (was: [csw-devel] SF.net SVN:
 gar:[11132] csw/mgar/pkg/alternatives/trunk)
In-Reply-To: <D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org>
References: <E1P26Kc-0007WM-0G@sfp-svn-2.v30.ch3.sourceforge.com>
	<D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org>
Message-ID: <AANLkTik9bZvpGz0UL3bhiK=QKV2xgfjFVe_Sq8JxGyb=@mail.gmail.com>

On 10/4/10, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,
>
>
> ?hhhh, what? At least I cannot remember that it failed. You insisted
> to rewrite the otherwise fully working RedHat implementation just
> because of the NFS-Share /opt/csw issue.

Yes. an "issue" which has been re-affirmed by multiple people
recently, not just me (at summer camp, I believe?) as worthwhile for
us to support.
So, lets *support* it, not keep bringing back, "should we support it?"
every time some effort is needed?
I'll also say the effort required is not colossal here.

> And after seeing all these
> issues with the rewrite the big question is: is it worth it?

I will point out that some of "these issues" have nothing to do with
the rewrite, but more about hokie behaviour with pkgadd across
global/non-global zones.

So yes, it most certainly is.
Any new implementation of something is going to have bugs. The
criteria should not be "does it have bugs", but "is it maintainable,
and can it meet our customer needs better than other solutions?"
The answer to the latter, is clearly "yes, and yes".

From phil at bolthole.com  Mon Oct  4 19:26:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 4 Oct 2010 10:26:29 -0700
Subject: [csw-maintainers] Alternatives (was: [csw-devel] SF.net SVN:
 gar:[11132] csw/mgar/pkg/alternatives/trunk)
In-Reply-To: <AANLkTik9bZvpGz0UL3bhiK=QKV2xgfjFVe_Sq8JxGyb=@mail.gmail.com>
References: <E1P26Kc-0007WM-0G@sfp-svn-2.v30.ch3.sourceforge.com>
	<D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org>
	<AANLkTik9bZvpGz0UL3bhiK=QKV2xgfjFVe_Sq8JxGyb=@mail.gmail.com>
Message-ID: <AANLkTi=a2NxGrAVFmGRjwNqYr-aRaAMqtLmMQQbgU9xJ@mail.gmail.com>

I will also point out bugid https://www.opencsw.org/mantis/view.php?id=4538
It's not just about NFS /opt/csw. There are also problems with zones.

This kind of problem, cannot be solved by "just using the redhat
alternative implementation".
We HAVE TO have our own Solaris-specific implementation to deal with
junk like this.

From phil at bolthole.com  Mon Oct  4 22:32:48 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 4 Oct 2010 13:32:48 -0700
Subject: [csw-maintainers] implementation question for CSWalternatives
Message-ID: <AANLkTi=k9gEO8xDmt4urvM58wKEcf9x+=SnyjN-CGE3f@mail.gmail.com>

So, there is a technical problem that we need to overcome, for zones,
and "alternatives", and I am asking for feedback on this issue.


PROBLEM STATEMENT:
if you create a new zone, then if /opt/csw is not actually shared from
somewhere... then only things that are registered in the package
database, will get copied into
newzone:/opt/csw

At the moment, CSWalternatives does NOT register the symlinks it creates.

PROPOSAL:
it has been suggested to me, that registering them as part of the
CSWalternative package, would be the best way to go  (as opposed to
registering it as part of whichever package it is servicing)

Comparison, as best I can think of it, is as follows:

register with CSWalternatives:
  Good, because it then becomes easy to figure out if a link was
created by our alternatives,
  vs done by hand or something.

register with CSWxyz
  Good, because if it points to a particular implementation for the
symlink, then when
  that package is removed, the symlink will automatically get removed.
  But then again, it should automatically get removed by class action
script anyway, so...
  are there any other benefits this way?

From phil at bolthole.com  Tue Oct  5 02:00:37 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 4 Oct 2010 17:00:37 -0700
Subject: [csw-maintainers] experimental: new binutils needs testing
Message-ID: <AANLkTikk5L3_aBoqTq+rjYd0=si8_-te0FD2JA0EZHks@mail.gmail.com>

hiya folks,

a long overdue update to binutils is now pending.
I've dropped it in my experimental dir,

( http://buildfarm.opencsw.org/experimental/phil/ if you like manually
doing stuff )

Any feedback would be appreciated, before I release this fairly
important piece of software.

From maciej at opencsw.org  Tue Oct  5 19:16:41 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 5 Oct 2010 10:16:41 -0700
Subject: [csw-maintainers] Alternatives (was: [csw-devel] SF.net SVN:
 gar:[11132] csw/mgar/pkg/alternatives/trunk)
In-Reply-To: <AANLkTi=a2NxGrAVFmGRjwNqYr-aRaAMqtLmMQQbgU9xJ@mail.gmail.com>
References: <E1P26Kc-0007WM-0G@sfp-svn-2.v30.ch3.sourceforge.com>
	<D7734207-2EA9-4A7F-A22E-DEA3EBC34189@opencsw.org>
	<AANLkTik9bZvpGz0UL3bhiK=QKV2xgfjFVe_Sq8JxGyb=@mail.gmail.com>
	<AANLkTi=a2NxGrAVFmGRjwNqYr-aRaAMqtLmMQQbgU9xJ@mail.gmail.com>
Message-ID: <AANLkTinOKuE9j_p-5xp1eFg8_9BKvRgCpNdMN8MbnHHs@mail.gmail.com>

No dia 4 de Outubro de 2010 10:26, Philip Brown <phil at bolthole.com> escreveu:
> I will also point out bugid https://www.opencsw.org/mantis/view.php?id=4538
> It's not just about NFS /opt/csw. There are also problems with zones.

I thought that it was only the shared NFS setup users that had
something to complain about in the redhat implementation.  What was
the problem with solaris zones?

From bwalton at opencsw.org  Wed Oct  6 02:43:58 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 05 Oct 2010 20:43:58 -0400
Subject: [csw-maintainers] implementation question for CSWalternatives
In-Reply-To: <AANLkTi=k9gEO8xDmt4urvM58wKEcf9x+=SnyjN-CGE3f@mail.gmail.com>
References: <AANLkTi=k9gEO8xDmt4urvM58wKEcf9x+=SnyjN-CGE3f@mail.gmail.com>
Message-ID: <1286325401-sup-1980@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Oct 04 16:32:48 -0400 2010:

> register with CSWalternatives:
>   Good, because it then becomes easy to figure out if a link was
> created by our alternatives,
>   vs done by hand or something.

What repercussions would this have across an update of CSWalternatives
itself?  Are these links registered in such a fashion that when
they're removed during an upgrade they'd be reinstated correctly
afterwards?

> register with CSWxyz
>   Good, because if it points to a particular implementation for the
> symlink, then when
>   that package is removed, the symlink will automatically get removed.
>   But then again, it should automatically get removed by class action
> script anyway, so...
>   are there any other benefits this way?

I don't care for this as much as placing the ownership with
alternatives itself.  The only real benefit I see is the one you've
noted already.

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


From phil at bolthole.com  Wed Oct  6 06:50:59 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 5 Oct 2010 21:50:59 -0700
Subject: [csw-maintainers] implementation question for CSWalternatives
In-Reply-To: <1286325401-sup-1980@pinkfloyd.chass.utoronto.ca>
References: <AANLkTi=k9gEO8xDmt4urvM58wKEcf9x+=SnyjN-CGE3f@mail.gmail.com>
	<1286325401-sup-1980@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikf-FhX3n13Mgt08w05cJ39EtkkRHHQ3hN5FvaT@mail.gmail.com>

On Tue, Oct 5, 2010 at 5:43 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Oct 04 16:32:48 -0400 2010:
>
>> register with CSWalternatives:
>> ? Good, because it then becomes easy to figure out if a link was
>> created by our alternatives,
>> ? vs done by hand or something.
>
> What repercussions would this have across an update of CSWalternatives
> itself? ?Are these links registered in such a fashion that when
> they're removed during an upgrade they'd be reinstated correctly
> afterwards?

Yup. either they are "auto" generated, or they are a result of the
"manual" choice of a user. files for which will be left in a separate
place.

erm.. waitaminit.. make that, "they COULD be regenerated". But I just
realized that would require a postinstall script. easy enough to do
once the need is known. Thanks for pointing that out.

Technically, that would count as a slight negative for this category
though: prompting the user to run the postinstall script.


>> register with CSWxyz
>> ? Good, because if it points to a particular implementation for the
>> symlink, then when
>> ? that package is removed, the symlink will automatically get removed.
>> ? But then again, it should automatically get removed by class action
>> script anyway, so...
>> ? are there any other benefits this way?
>
> I don't care for this as much as placing the ownership with
> alternatives itself. ?The only real benefit I see is the one you've
> noted already.


sounds like "one vote for making the links registered to CSWalternatives" then.
Thanks for the feedback.

From dam at opencsw.org  Wed Oct  6 10:26:02 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 6 Oct 2010 10:26:02 +0200
Subject: [csw-maintainers] Fwd: "default"(?) postmsg for alternatives
References: <4493D18F-A381-46FB-B642-57AABFE9A890@opencsw.org>
Message-ID: <1C543530-B47F-4971-9B82-01A7ACED34DD@opencsw.org>

(Resend due to general interest)

Anfang der weitergeleiteten E-Mail:

> Von: Dagobert Michelsen <dam at opencsw.org>
> Datum: 6. Oktober 2010 10:25:03 MESZ
> An: Philip Brown <phil at bolthole.com>
> Betreff: Re: "default"(?) postmsg for alternatives
>
> Hi Phil,
>
> Am 05.10.2010 um 23:11 schrieb Philip Brown:
>> the gar page on alternatives, seems to hint that there is a  
>> "standard"
>> postinstall message.
>>
>> ( https://sourceforge.net/apps/trac/gar/wiki/Alternatives )
>
> Well, I used that for my packages. There is no automatism for it,
> you have to manually add it for each package.
>
>> I'm rather against this for two reasons: first of all, people usually
>> complain there is too much output already :-}
>> The other, is that I dont think it is useful enough.
>> Just saying "use --config" implies that they should ALWAYS use it,
>> which is false.
>
> Hugh?
>  "You can easily select between the versions with the alternatives(8)
>   system by executing"
>
>> Ideally, I think it should be removed. or at best, a simple reference
>> that actually works.
>
> It worked perfectly in the past.
>
>> Do note that
>>
>> http://wiki.opencsw.org/package-alternatives
>>
>> is now an invalid url!!
>
> I vaguely remember there was a page. And it is a standard to have
>  http://wiki.opencsw.org/package-<catalogname>
> to explain things about the package.
>
>> If you feel strongly that a longer version should stay in, then I  
>> have
>> some suggestions for improvement.
>
> Please do.
>
>
> Best regards
>
>  -- Dago
>


From dam at opencsw.org  Wed Oct  6 11:03:58 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 6 Oct 2010 11:03:58 +0200
Subject: [csw-maintainers] Fwd: "default"(?) postmsg for alternatives
In-Reply-To: <1C543530-B47F-4971-9B82-01A7ACED34DD@opencsw.org>
References: <4493D18F-A381-46FB-B642-57AABFE9A890@opencsw.org>
	<1C543530-B47F-4971-9B82-01A7ACED34DD@opencsw.org>
Message-ID: <F4C1A641-1745-4591-A0FB-89E53A4D7424@opencsw.org>

Hi,

Am 06.10.2010 um 10:26 schrieb Dagobert Michelsen:
>>> Do note that
>>>
>>> http://wiki.opencsw.org/package-alternatives
>>>
>>> is now an invalid url!!
>>
>> I vaguely remember there was a page. And it is a standard to have
>> http://wiki.opencsw.org/package-<catalogname>
>> to explain things about the package.

I remembered wrong and the documentation was also wrong. The standard it
   <catalogname>-package
and I set up a forward for now in the wiki from package-<catalogname>.


Best regrads

   -- Dago



From bwalton at opencsw.org  Wed Oct  6 14:27:53 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 06 Oct 2010 08:27:53 -0400
Subject: [csw-maintainers] implementation question for CSWalternatives
In-Reply-To: <AANLkTikf-FhX3n13Mgt08w05cJ39EtkkRHHQ3hN5FvaT@mail.gmail.com>
References: <AANLkTi=k9gEO8xDmt4urvM58wKEcf9x+=SnyjN-CGE3f@mail.gmail.com>
	<1286325401-sup-1980@pinkfloyd.chass.utoronto.ca>
	<AANLkTikf-FhX3n13Mgt08w05cJ39EtkkRHHQ3hN5FvaT@mail.gmail.com>
Message-ID: <1286368002-sup-5946@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed Oct 06 00:50:59 -0400 2010:

> erm.. waitaminit.. make that, "they COULD be regenerated". But I just
> realized that would require a postinstall script. easy enough to do
> once the need is known. Thanks for pointing that out.
> 
> Technically, that would count as a slight negative for this category
> though: prompting the user to run the postinstall script.

I agree it's a slight negative, but I still think it's the right
choice.  In time, alternatives will stabilize to the point where it's
quite static.

Yes, +1 for registering it to alternatives.

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


From bonivart at opencsw.org  Wed Oct  6 17:41:07 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 6 Oct 2010 17:41:07 +0200
Subject: [csw-maintainers] Collisions
Message-ID: <AANLkTi=TmFrm+9isW5GG6tPQ5W86qKrgZ1SrEQxLW0tZ@mail.gmail.com>

This is what I have done to tackle my share of the file collisions
(http://buildfarm.opencsw.org/~maciej/file-conflicts.csv):

- asked to have CSWpmtstbldrtester removed from the catalog (now
included in CSWpmtestsimple)
- filed bugs against other maintainers packages with man pages
colliding with CSWperl
- - 4562, pm_compressrawzlib, Benny vonMossner
- - 4563, pm_compressrawbz2, Benny vonMossner
- - 4564, pm_iocompress, Dagobert Michelsen
- - 4566, pm_version, Benny vonMossner
- - 4567, pm_testsimple, Dagobert Michelsen
- - 4568, pm_pkgconst, William Bonnet
- - 4569, pm_objaccessor, William Bonnet
- - 4570, pm_iozlib, Dagobert Michelsen
- - 4571, pm_extutparsexs, Dagobert Michelsen
- - 4572, pm_extutcbuilder, Dagobert Michelsen
- - 4573, pm_moduleplug, Dagobert Michelsen
- updated my own colliding packages
- - CSWpmmodload
- - CSWpmmodloadcond
- overtaken colliding packages from retired maintainers (all from Cory)
- - CSWpmextutilsmft
- - CSWpmfilefetch
- - CSWpmipccmd
- - CSWpmlclemktxtsimple
- - CSWpmlogmsgsimple
- - CSWpmmodloaded
- - CSWpmprmscheck
- - CSWpmtermui
- asked to have CSWpmlogmessage removed from the catalog (CSWperl has
current version, CSWpmlogmessage is older)
- asked to have CSWpmmodcorelist removed from the catalog (CSWperl has
2.18, current is 2.39)
- asked to have CSWpmcpanplus removed from the catalog (CSWperl has
0.88, CSWpmcpanplus is 0.076)

-- 
/peter

From phil at bolthole.com  Wed Oct  6 18:27:53 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 6 Oct 2010 09:27:53 -0700
Subject: [csw-maintainers] Collisions
In-Reply-To: <AANLkTi=TmFrm+9isW5GG6tPQ5W86qKrgZ1SrEQxLW0tZ@mail.gmail.com>
References: <AANLkTi=TmFrm+9isW5GG6tPQ5W86qKrgZ1SrEQxLW0tZ@mail.gmail.com>
Message-ID: <AANLkTim_n4UTGjyCkdByRwJDn_xKsVsyBhG7HvNOG3p8@mail.gmail.com>

On 10/6/10, Peter Bonivart <bonivart at opencsw.org> wrote:
> This is what I have done to tackle my share of the file collisions
> (...



>
> - asked to have CSWpmlogmessage removed from the catalog (CSWperl has
> current version, CSWpmlogmessage is older)
> - asked to have CSWpmmodcorelist removed from the catalog (CSWperl has
> 2.18, current is 2.39)
> - asked to have CSWpmcpanplus removed from the catalog (CSWperl has
> 0.88, CSWpmcpanplus is 0.076)
>

Ah.. I do not see prior qemails about those. Do I take it to mean,
"you are NOW asking to have..."  ?

From dam at opencsw.org  Wed Oct  6 18:44:08 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 6 Oct 2010 18:44:08 +0200
Subject: [csw-maintainers] Collisions
In-Reply-To: <AANLkTi=TmFrm+9isW5GG6tPQ5W86qKrgZ1SrEQxLW0tZ@mail.gmail.com>
References: <AANLkTi=TmFrm+9isW5GG6tPQ5W86qKrgZ1SrEQxLW0tZ@mail.gmail.com>
Message-ID: <713AB04C-7240-438C-8C92-3DE25413696A@opencsw.org>

Hi Peter,

Am 06.10.2010 um 17:41 schrieb Peter Bonivart:
> This is what I have done to tackle my share of the file collisions
> (http://buildfarm.opencsw.org/~maciej/file-conflicts.csv):
>
> - asked to have CSWpmtstbldrtester removed from the catalog (now
> included in CSWpmtestsimple)
> - filed bugs against other maintainers packages with man pages
> colliding with CSWperl
> - - 4562, pm_compressrawzlib, Benny vonMossner
> - - 4563, pm_compressrawbz2, Benny vonMossner
> - - 4564, pm_iocompress, Dagobert Michelsen
> - - 4566, pm_version, Benny vonMossner
> - - 4567, pm_testsimple, Dagobert Michelsen
> - - 4568, pm_pkgconst, William Bonnet
> - - 4569, pm_objaccessor, William Bonnet
> - - 4570, pm_iozlib, Dagobert Michelsen
> - - 4571, pm_extutparsexs, Dagobert Michelsen
> - - 4572, pm_extutcbuilder, Dagobert Michelsen
> - - 4573, pm_moduleplug, Dagobert Michelsen
> - updated my own colliding packages
> - - CSWpmmodload
> - - CSWpmmodloadcond
> - overtaken colliding packages from retired maintainers (all from  
> Cory)
> - - CSWpmextutilsmft
> - - CSWpmfilefetch
> - - CSWpmipccmd
> - - CSWpmlclemktxtsimple
> - - CSWpmlogmsgsimple
> - - CSWpmmodloaded
> - - CSWpmprmscheck
> - - CSWpmtermui
> - asked to have CSWpmlogmessage removed from the catalog (CSWperl has
> current version, CSWpmlogmessage is older)
> - asked to have CSWpmmodcorelist removed from the catalog (CSWperl has
> 2.18, current is 2.39)
> - asked to have CSWpmcpanplus removed from the catalog (CSWperl has
> 0.88, CSWpmcpanplus is 0.076)

Excellent work, thanks! I'll see that I get my things updated.


Best regards

   -- Dago


From maciej at opencsw.org  Thu Oct  7 06:42:49 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 6 Oct 2010 21:42:49 -0700
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
Message-ID: <AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>

No dia 1 de Outubro de 2010 16:37, Philip Brown <phil at bolthole.com> escreveu:
> I will preface my email, with the general premise: "Life is not simple".
> It would be lovely if there were a nice clean way to deal with this...
> but lets face facts, rather than to deny them. There Is No simple
> clean automated, "always applies" solution to this.
> That being said, lets move on to discuss what Can be done, in the face
> of life's messy realities :)

Yes, I'm well aware that it's not possible to come up with a simple
rule that humans would agree to adhere to.

> On 9/29/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> ....
>> file=opt/csw/lib/libavcodec-0.4.9-pre1.so pkgname=CSWffmpeg
>> expected=['CSWlibavcodec-0-4-9-pre1']
>> file=opt/csw/lib/libavformat-0.4.9-pre1.so pkgname=CSWffmpeg
>> expected=['CSWlibavformat-0-4-9-pre1']
>> file=opt/csw/lib/libpostproc.so.0.0.1 pkgname=CSWffmpeg
>> expected=['CSWlibpostproc0', 'CSWlibpostproc-0']
>>
>> With these three, I don't know myself - does it make sense to separate
>> these 3 libraries? ?Two of them seem to have the version in sync, but
>> the version is entangled with the library name, instead of being
>> located after the ".so" bit, where nature intended.
>>
>
> This is exactly the sort of thing I envisioned running into. Thank you
> for doing the hard research to dig up a specific example.
> This example is extra complicated, since there is NO SONAME to any of them.
> interestingly, though, there is a cross-dependancy in the libs themselves.
> libavformat needs libavcodec.
> Interestingly, however, it needs, by name, "libavcodec.so". no rev.
>
> So in this case, it would serve no purpose whatsoever to split the
> libraries out from the main ffmpeg package, or to split them up
> independantly. A newer version of the package will transparently
> update older versions, it would seem.

Yes, libavcodec.so is a symlink:

/opt/csw/lib/libavcodec.so -> libavcodec-0.4.9-pre1.so

I'm not sure what would developers do if they needed to update the
API, but I'm guessing that they would release a new package that would
no longer provide libavcodec.so, but libavcodec.so.1 or similar.  What
matters is the correspondence between the SONAME and the library file
name, and revisions are just a convenient notation for humans.

I don't quite agree with the splitting serving no purpose.  You can
always have a client program needing libavcodec.so, and not needing
other libraries.  Consider this scenario:

/opt/csw/lib/libavformat.so needs libavcodec.so
/opt/csw/bin/foo needs libavcodec.so

At some point, libavformat.so goes away, nothing else links to it.
You want to remove it.  However, it's packaged together with
libavcodec.so, and /opt/csw/bin/foo still depends on it.  If you had
those two libraries packaged separately, you could retire
libavformat.so.

> I think you might do well to go with my original theory, slightly expanded:
>
> Unless you find a shared object, of filename "lib*.so*", AND it has a
> "SONAME", AND that name has a double-numeric rev ?(eg:
> libfoo.so.#.#), then you should just leave it alone.

I understand and I agree with the first two criteria: It makes sense
to separate the library out, if it is named lib*.so*, and has a
SONAME.  I don't get the bit with the double-numeric versions.  What
matters is the presence of SONAME, and the contents is a conventional
notation, why would any numbers matter?

I'd add a third criterion, which is: It must be in one of the default
search locations, in our case: /opt/csw/lib with optional isalist
subdirectories.

From phil at bolthole.com  Thu Oct  7 15:55:44 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 7 Oct 2010 06:55:44 -0700
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
Message-ID: <AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>

On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> (Phil wrote)
>> I think you might do well to go with my original theory, slightly expanded:
>>
>> Unless you find a shared object, of filename "lib*.so*", AND it has a
>> "SONAME", AND that name has a double-numeric rev ?(eg:
>> libfoo.so.#.#), then you should just leave it alone.
>
> I understand and I agree with the first two criteria: It makes sense
> to separate the library out, if it is named lib*.so*, and has a
> SONAME. ?I don't get the bit with the double-numeric versions. ?What
> matters is the presence of SONAME, and the contents is a conventional
> notation, why would any numbers matter?
>

(I did explain this previously, but I'll repeat myself for this case)
It has been my experience that libraries with only a single digit
signifier in the SONAME, tend to respect backward compatibility, and
the value of a stable API.
They tend to not ever change the SONAME, unless the major version of
the associated program changes. in which case, there's no reason to
split out the shared lib even more, if it was not normally done so.
(note that I do explicitly mean the SONAME. if just the filename has
double digits, that doesnt count)

In contrast, developers who put in the minor rev number to the SONAME,
are practically announcing the fact of, "We have no respect for
consistency across major version numbers. We are specifically
intending to introduce incompatible features in minor revisions of the
program"
Hence why they have gone to the extra trouble of putting in the minor
rev number into the SONAME.

summary: single-digit SONAME implies long term stability. double digit
SONAME implies frequent change, and thus a very good reason to split
out the lib for dependancy purposes.

From Joerg.Schilling at fokus.fraunhofer.de  Thu Oct  7 16:14:32 2010
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Thu, 07 Oct 2010 16:14:32 +0200
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
	<AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
Message-ID: <4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>

Philip Brown <phil at bolthole.com> wrote:

> On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
> > (Phil wrote)
> >> I think you might do well to go with my original theory, slightly expanded:
> >>
> >> Unless you find a shared object, of filename "lib*.so*", AND it has a
> >> "SONAME", AND that name has a double-numeric rev ?(eg:
> >> libfoo.so.#.#), then you should just leave it alone.
> >
> > I understand and I agree with the first two criteria: It makes sense
> > to separate the library out, if it is named lib*.so*, and has a
> > SONAME. ?I don't get the bit with the double-numeric versions. ?What
> > matters is the presence of SONAME, and the contents is a conventional
> > notation, why would any numbers matter?
> >
>
> (I did explain this previously, but I'll repeat myself for this case)
> It has been my experience that libraries with only a single digit
> signifier in the SONAME, tend to respect backward compatibility, and
> the value of a stable API.

This is all outdated technology. library versioning is nowerdays done via 
mapfiles. This allows even to link against an older lib at runtime than you
did at compile time iff the old lib supports the interfaces needed by a 
specific program.

Unfortunately, few OSS authors understand how to correctly deal with library 
interface versioning.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

From dam at opencsw.org  Thu Oct  7 20:37:48 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 7 Oct 2010 20:37:48 +0200
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
	<AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
	<4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <13FA6C60-5D59-4488-AD56-623235333121@opencsw.org>

Hi Joerg,

Am 07.10.2010 um 16:14 schrieb Joerg Schilling:
> Philip Brown <phil at bolthole.com> wrote:
>
>> On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski
>> <maciej at opencsw.org> wrote:
>>> (Phil wrote)
>>>> I think you might do well to go with my original theory, slightly  
>>>> expanded:
>>>>
>>>> Unless you find a shared object, of filename "lib*.so*", AND it  
>>>> has a
>>>> "SONAME", AND that name has a double-numeric rev  (eg:
>>>> libfoo.so.#.#), then you should just leave it alone.
>>>
>>> I understand and I agree with the first two criteria: It makes sense
>>> to separate the library out, if it is named lib*.so*, and has a
>>> SONAME.  I don't get the bit with the double-numeric versions.  What
>>> matters is the presence of SONAME, and the contents is a  
>>> conventional
>>> notation, why would any numbers matter?
>>>
>>
>> (I did explain this previously, but I'll repeat myself for this case)
>> It has been my experience that libraries with only a single digit
>> signifier in the SONAME, tend to respect backward compatibility, and
>> the value of a stable API.
>
> This is all outdated technology. library versioning is nowerdays  
> done via
> mapfiles. This allows even to link against an older lib at runtime  
> than you
> did at compile time iff the old lib supports the interfaces needed  
> by a
> specific program.
>
> Unfortunately, few OSS authors understand how to correctly deal with  
> library
> interface versioning.

This is very interesting. We have a long-standing issue about  
incompatible
API-changes to libnet:
   http://lists.opencsw.org/pipermail/maintainers/2009-March/007191.html
Could these maps help solve the issue?


Best regards

   -- Dago

From bwalton at opencsw.org  Thu Oct  7 20:41:49 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 07 Oct 2010 14:41:49 -0400
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
	<AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
	<4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <1286476807-sup-4831@pinkfloyd.chass.utoronto.ca>

Excerpts from Joerg.Schilling's message of Thu Oct 07 10:14:32 -0400 2010:

Hi J?rg,

> Unfortunately, few OSS authors understand how to correctly deal with library 
> interface versioning.

Symbol versioning is much nicer, but I've found it's not always a
panacea either...specifically, libxslt provides a symbol version map
that chokes suncc. :(

Suggestions/fixes welcome for this issue...the only 'fix' I found was
to turn off symbol versioning.  As this isn't ideal, I've left the
update on my todo list for some time now.

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


From maciej at opencsw.org  Fri Oct  8 01:24:36 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 7 Oct 2010 16:24:36 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs tetex
In-Reply-To: <x6lj6a2y1f.fsf@opencsw.org>
References: <x6pqvo4hlp.fsf@opencsw.org>
	<AANLkTi=RjjOVL_GuHy6urj+Q_c8hgEv=P4KaTtHe-USY@mail.gmail.com>
	<x6hbgz4wm1.fsf@opencsw.org>
	<AANLkTinx77cbd9r-K5JNY-OSfAa2g1A0-GuT4qWeG_2T@mail.gmail.com>
	<x6lj6a2y1f.fsf@opencsw.org>
Message-ID: <AANLkTi=ST1nA9UggTdTPH=41Pw2iYC4bZWmX+gQczh6F@mail.gmail.com>

[-pkgsubmissions, +maintainers]

No dia 7 de Outubro de 2010 01:43, Peter FELECAN
<pfelecan at opencsw.org> escreveu:
>>> Look at the tail of
>>> login:/home/pfelecan/CSW/logs/tetex-3.0REV2010.10.05-sparc.log
>>
>> I looked at it; it doesn't look like checkpkg output to me.[...]
>
> Indeed, we may not discuss the same tool. What I'm refering to is
> /opt/csw/bin/checkpkg supplied by CSWcswutils and which is a creature of
> Phil...
>
> Your creature is installed where, what package supplies-it how to use-it?

checkpkg is currently available as a svn code checkout only.  What do
people think about releasing the checkpkg from GAR in a package?

Maciej

From phil at bolthole.com  Fri Oct  8 01:28:46 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 7 Oct 2010 16:28:46 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs tetex
In-Reply-To: <AANLkTi=ST1nA9UggTdTPH=41Pw2iYC4bZWmX+gQczh6F@mail.gmail.com>
References: <x6pqvo4hlp.fsf@opencsw.org>
	<AANLkTi=RjjOVL_GuHy6urj+Q_c8hgEv=P4KaTtHe-USY@mail.gmail.com>
	<x6hbgz4wm1.fsf@opencsw.org>
	<AANLkTinx77cbd9r-K5JNY-OSfAa2g1A0-GuT4qWeG_2T@mail.gmail.com>
	<x6lj6a2y1f.fsf@opencsw.org>
	<AANLkTi=ST1nA9UggTdTPH=41Pw2iYC4bZWmX+gQczh6F@mail.gmail.com>
Message-ID: <AANLkTinxPyk-BbLNHVR5ZwURoHiYDLFba8z0Tc6ALnom@mail.gmail.com>

I've always been in favor of it. I think all the gar-related tools
should be put into a nice clean "external" package.
(ie: submitpkg as well)
you'll just have to be creative about name collision on the existing one.


On 10/7/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> [-pkgsubmissions, +maintainers]
>
> No dia 7 de Outubro de 2010 01:43, Peter FELECAN
> <pfelecan at opencsw.org> escreveu:
>>>> Look at the tail of
>>>> login:/home/pfelecan/CSW/logs/tetex-3.0REV2010.10.05-sparc.log
>>>
>>> I looked at it; it doesn't look like checkpkg output to me.[...]
>>
>> Indeed, we may not discuss the same tool. What I'm refering to is
>> /opt/csw/bin/checkpkg supplied by CSWcswutils and which is a creature of
>> Phil...
>>
>> Your creature is installed where, what package supplies-it how to use-it?
>
> checkpkg is currently available as a svn code checkout only.  What do
> people think about releasing the checkpkg from GAR in a package?
>
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From pfelecan at opencsw.org  Fri Oct  8 09:19:05 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 08 Oct 2010 09:19:05 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs tetex
In-Reply-To: <AANLkTinxPyk-BbLNHVR5ZwURoHiYDLFba8z0Tc6ALnom@mail.gmail.com>
	(Philip Brown's message of "Thu, 7 Oct 2010 16:28:46 -0700")
References: <x6pqvo4hlp.fsf@opencsw.org>
	<AANLkTi=RjjOVL_GuHy6urj+Q_c8hgEv=P4KaTtHe-USY@mail.gmail.com>
	<x6hbgz4wm1.fsf@opencsw.org>
	<AANLkTinx77cbd9r-K5JNY-OSfAa2g1A0-GuT4qWeG_2T@mail.gmail.com>
	<x6lj6a2y1f.fsf@opencsw.org>
	<AANLkTi=ST1nA9UggTdTPH=41Pw2iYC4bZWmX+gQczh6F@mail.gmail.com>
	<AANLkTinxPyk-BbLNHVR5ZwURoHiYDLFba8z0Tc6ALnom@mail.gmail.com>
Message-ID: <x6d3rl2lue.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> you'll just have to be creative about name collision on the existing
> one.

newchkpkg
superchkpkg
&c

-- 
Peter

From Joerg.Schilling at fokus.fraunhofer.de  Fri Oct  8 11:53:34 2010
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Fri, 08 Oct 2010 11:53:34 +0200
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <13FA6C60-5D59-4488-AD56-623235333121@opencsw.org>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
	<AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
	<4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>
	<13FA6C60-5D59-4488-AD56-623235333121@opencsw.org>
Message-ID: <4caeea1e.a2X/l0+P4a5Arq+r%Joerg.Schilling@fokus.fraunhofer.de>

Dagobert Michelsen <dam at opencsw.org> wrote:

> > Unfortunately, few OSS authors understand how to correctly deal with  
> > library
> > interface versioning.
>
> This is very interesting. We have a long-standing issue about  
> incompatible
> API-changes to libnet:
>    http://lists.opencsw.org/pipermail/maintainers/2009-March/007191.html
> Could these maps help solve the issue?

This thread unfortunately does not mention what problem exists.

If someone really a function in a way that is not compatible with previous 
versions, you are lost and the only way to deal with the problem is to have 
multiple libs with multiple names.

What you can do with versioned symbols is to flag that there is a version
1.5 foo() but no version 1.2 foo().

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

From maciej at opencsw.org  Fri Oct  8 23:52:39 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 8 Oct 2010 14:52:39 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs tetex
In-Reply-To: <x6d3rl2lue.fsf@opencsw.org>
References: <x6pqvo4hlp.fsf@opencsw.org>
	<AANLkTi=RjjOVL_GuHy6urj+Q_c8hgEv=P4KaTtHe-USY@mail.gmail.com>
	<x6hbgz4wm1.fsf@opencsw.org>
	<AANLkTinx77cbd9r-K5JNY-OSfAa2g1A0-GuT4qWeG_2T@mail.gmail.com>
	<x6lj6a2y1f.fsf@opencsw.org>
	<AANLkTi=ST1nA9UggTdTPH=41Pw2iYC4bZWmX+gQczh6F@mail.gmail.com>
	<AANLkTinxPyk-BbLNHVR5ZwURoHiYDLFba8z0Tc6ALnom@mail.gmail.com>
	<x6d3rl2lue.fsf@opencsw.org>
Message-ID: <AANLkTinLa8=ah_ME9-kY0H7vJhTEUM-AoNA5bCRE3NrU@mail.gmail.com>

No dia 8 de Outubro de 2010 00:19, Peter FELECAN
<pfelecan at opencsw.org> escreveu:
> Philip Brown <phil at bolthole.com> writes:
>
>> you'll just have to be creative about name collision on the existing
>> one.
>
> newchkpkg
> superchkpkg
> &c

I was thinking about just upgrading checkpkg to the newer version.
The current version (the one in GAR) is a functional superset of the
old version (the one in CSWcswutils).  If there are parts of
infrastructure other than GAR that depend on checkpkg's interface
(which has changed slightly), we can review the requirements and
implement backward-compatibility mode.

Are there any parts of infrastructure that depend on checkpkg from CSWcswutils?

From maciej at opencsw.org  Sat Oct  9 00:27:59 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 8 Oct 2010 15:27:59 -0700
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
	<AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
Message-ID: <AANLkTikub0q-jAOQjORvT=LJfpmvrr2827JOXiNhruP8@mail.gmail.com>

No dia 7 de Outubro de 2010 06:55, Philip Brown <phil at bolthole.com> escreveu:
> On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> (Phil wrote)
>>> I think you might do well to go with my original theory, slightly expanded:
>>>
>>> Unless you find a shared object, of filename "lib*.so*", AND it has a
>>> "SONAME", AND that name has a double-numeric rev ?(eg:
>>> libfoo.so.#.#), then you should just leave it alone.
>>
>> I understand and I agree with the first two criteria: It makes sense
>> to separate the library out, if it is named lib*.so*, and has a
>> SONAME. ?I don't get the bit with the double-numeric versions. ?What
>> matters is the presence of SONAME, and the contents is a conventional
>> notation, why would any numbers matter?
>>
>
> (I did explain this previously, but I'll repeat myself for this case)

I didn't mean to make you repeat yourself.  I understand the potential
(depending on the approach of developers) implication of declaring "we
change the API frequently" via including the minor version number and
"we offer a stable API" by including the major version only.  This
tendency is clear to me.

What I meant is that the life cycle of an API-wise unstable library
consists of exactly the same phases as the life cycle of a API-wise
stable library:

1. A SONAME appears
2. We decide to distribute it
3. Binaries start linking to it
4. Time passes, new version of the same library comes along
5. Binaries stop linking to it
6. SONAME goes away

Life cycles of SONAMEs might span shorter or longer time frames, but
are otherwise identical.  Therefore, the packaging policy has no
reason to depend on the API change frequency.  In other words, if you
want to retire your SONAME in a clean and easy way, always put it into
a separate package.

From bwalton at opencsw.org  Sat Oct  9 03:13:14 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 08 Oct 2010 21:13:14 -0400
Subject: [csw-maintainers] call for apache2 testing
In-Reply-To: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
References: <1285813763-sup-5332@pinkfloyd.chass.utoronto.ca>
Message-ID: <1286586241-sup-2463@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Wed Sep 29 22:33:10 -0400 2010:

Hi All,

> Any testing you can provide is appreciated.  I'd prefer that this
> update not blow up web servers. :)

Ok, another request for testing.  I think I've addressed all issues
noted previously and some that weren't.  The experimental repo is now:

http://mirror.opencsw.org/opencsw/experimental/apache2

Changes since the last time:

1. httpd.worker is now delivered in ap2_worker (as it used to be).
   This is so that alternatives support is more robust (eg: actually
   works)
2. Fixed package splitting so the -devel package has the proper files.
3. Pulled apxs and required files out of -devel so they can be used by
   the cswap2mod CAS.
4. Tried to clarify the language used in the postmsg README's to ease
   the transition to alternatives.  I suspect that because
   httpd.worker is actually in ap2_worker most people won't interact
   with alternatives for this task anyway.
5. Generate a dummy ssl certificate at install time if not already
   there.

I've tested both fresh install and update from the current packages
and it all seems to work as I'd expect.

If I don't hear anything back in a few days, I'll push it to the
gate.

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


From bonivart at opencsw.org  Sat Oct  9 20:17:10 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 9 Oct 2010 20:17:10 +0200
Subject: [csw-maintainers] No mirror updates in a week?
Message-ID: <AANLkTikPhbW1=FPNLR24Jydwbq_8+ed0JF_a2iQ0RByX@mail.gmail.com>

Is there some problem or what?

/peter

From dam at opencsw.org  Sun Oct 10 12:56:02 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 10 Oct 2010 12:56:02 +0200
Subject: [csw-maintainers] An idea for a shared libraries policy
In-Reply-To: <4caeea1e.a2X/l0+P4a5Arq+r%Joerg.Schilling@fokus.fraunhofer.de>
References: <AANLkTin6d=YW-v3ouDs437=jD3P==A=fQch3Tt+E=dfA@mail.gmail.com>
	<AANLkTin0OS1qGVmrstgYUd2Vs1cEVG7aDN71MM7goHXB@mail.gmail.com>
	<AANLkTimHSTwXFE_nN8EXaL9D60FAc_AW4TrUd5KAcMu0@mail.gmail.com>
	<AANLkTinFnViUF_u0zsp-7rLrmDKTpvb_U84ZZFFitZtQ@mail.gmail.com>
	<4CA3FFC1.2090805@opencsw.org>
	<AANLkTi=W=6OJcm257X62JLy9pSU42sK7-8bhwWLh8z_L@mail.gmail.com>
	<AANLkTikAc4R31CTMZY+C+bEP7m0FdJD=LMzN5=n_fE51@mail.gmail.com>
	<AANLkTi=GShqRD_=g-maGYkUDBQHB8zGa98vPy2ikZHgZ@mail.gmail.com>
	<AANLkTiny8F6W=AKtkCf7_o9Gq6HB6SSm0KNzw0dVUE4h@mail.gmail.com>
	<4cadd5c8.NbpUM9+1L/rEcOD3%Joerg.Schilling@fokus.fraunhofer.de>
	<13FA6C60-5D59-4488-AD56-623235333121@opencsw.org>
	<4caeea1e.a2X/l0+P4a5Arq+r%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <EAE1A878-31C0-4199-B73F-29A0EC56EBF7@opencsw.org>

Hi J?rg,

Am 08.10.2010 um 11:53 schrieb Joerg Schilling:
> Dagobert Michelsen <dam at opencsw.org> wrote:
>
>>> Unfortunately, few OSS authors understand how to correctly deal with
>>> library
>>> interface versioning.
>>
>> This is very interesting. We have a long-standing issue about
>> incompatible
>> API-changes to libnet:
>>   http://lists.opencsw.org/pipermail/maintainers/2009-March/007191.html
>> Could these maps help solve the issue?
>
> This thread unfortunately does not mention what problem exists.

There are two incompatible versions of libnet.so, both with a SONAME of
libnet.so. So when the newly compiled binaries link against -lnet they
will always get the old one. Additionally, the old library can not be
replaced/moved without breaking compatibility with the ton of legacy
packages compiled against the old (=existing) version of libnet.so

> If someone really a function in a way that is not compatible with  
> previous
> versions, you are lost and the only way to deal with the problem is  
> to have
> multiple libs with multiple names.

...and exactly this is difficult.

> What you can do with versioned symbols is to flag that there is a  
> version
> 1.5 foo() but no version 1.2 foo().

Ah, ok.


Best regads

   -- Dago

From maciej at opencsw.org  Sun Oct 10 23:12:37 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sun, 10 Oct 2010 14:12:37 -0700
Subject: [csw-maintainers] GAR: Checks for shared library names
Message-ID: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>

Hello maintainers and GAR users,

I've just returned from PDT to GMT, and I have a checkpkg-related
announcement:  For the past week I've been working on an update to
checkpkg, which implements the idea for the package naming of shared
libraries.  The discussion is still on-going, but there seems to be
enough consensus to go forward and look how it looks in practice.
During the last week, I've done multiple iterations of analyzing the
whole catalog and adjusting checks.

As always, you can get rid of any errors by either adjusting your
package, or overriding the error.  You aren't required to conform to
everything checkpkg says; but make sure that you understand the issue
before you override any errors.

Here goes the summary:

1. .so files should not be together with shared libraries. GAR
suggests lines to add to the build file:

# (If CSWneon-devel doesn't exist yet)
PACKAGES += CSWneon-devel
PKGFILES_CSWneon-devel += /opt/csw/lib/libneon.so

2. If package contains multiple shared libraries, their versions
should match.  For example, libfoo.so.1.2.3 and libfoo_bar.so.1.2.3
are OK to be together, but libfoo.so.1.2.3 and libfoo.2.1.3 are not.

3. If there are shared libraries in the package, it should be named
after the library.  Checkpkg suggests package names and lines to add
to the build file.

PACKAGES += CSWlibaudiofile0
PKGFILES_CSWlibaudiofile0 += /opt/csw/lib/libaudiofile.so.0.0.2
PKGFILES_CSWlibaudiofile0 += /opt/csw/lib/libaudiofile.so.0.*

I've also written a wiki page with more documentation for the error
tags.  There are descriptions of 3 error tags at the moment.

http://wiki.opencsw.org/checkpkg-error-tags

As always, please mail me in case of any issues.

Maciej

From phil at bolthole.com  Mon Oct 11 06:09:07 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 10 Oct 2010 21:09:07 -0700
Subject: [csw-maintainers] No mirror updates in a week?
In-Reply-To: <AANLkTikPhbW1=FPNLR24Jydwbq_8+ed0JF_a2iQ0RByX@mail.gmail.com>
References: <AANLkTikPhbW1=FPNLR24Jydwbq_8+ed0JF_a2iQ0RByX@mail.gmail.com>
Message-ID: <AANLkTimze3_7sVyBOmOHzig93roZbzMma58SrNJxn5NC@mail.gmail.com>

it WAS a very quiet week. and then I took a little weekend trip the
last two days :)
I'll be releasing stuffs imminently.



On Sat, Oct 9, 2010 at 11:17 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> Is there some problem or what?
>
> /peter
> _______________________________________________
> 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  Mon Oct 11 06:13:20 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 10 Oct 2010 21:13:20 -0700
Subject: [csw-maintainers] GAR: Checks for shared library names
In-Reply-To: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
References: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
Message-ID: <AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>

On Sun, Oct 10, 2010 at 2:12 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> ....
> Here goes the summary:
>
> 1. .so files should not be together with shared libraries.

erm.. I presume you mean,
"the SYMLINK for libxxxx.so ->libxxx.so.# should not go in the
separated-out runtime package for the shared libraries".



> 2. If package contains multiple shared libraries, their versions
> should match. ?For example, libfoo.so.1.2.3 and libfoo_bar.so.1.2.3
> are OK to be together, but libfoo.so.1.2.3 and libfoo.2.1.3 are not.

I dont think it is okay to "mandate" that.
Otherwise, you have to spell out more what to do when braindead
upstream people lump non-matching version together

From phil at bolthole.com  Mon Oct 11 06:18:19 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 10 Oct 2010 21:18:19 -0700
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs tetex
In-Reply-To: <AANLkTinLa8=ah_ME9-kY0H7vJhTEUM-AoNA5bCRE3NrU@mail.gmail.com>
References: <x6pqvo4hlp.fsf@opencsw.org>
	<AANLkTi=RjjOVL_GuHy6urj+Q_c8hgEv=P4KaTtHe-USY@mail.gmail.com>
	<x6hbgz4wm1.fsf@opencsw.org>
	<AANLkTinx77cbd9r-K5JNY-OSfAa2g1A0-GuT4qWeG_2T@mail.gmail.com>
	<x6lj6a2y1f.fsf@opencsw.org>
	<AANLkTi=ST1nA9UggTdTPH=41Pw2iYC4bZWmX+gQczh6F@mail.gmail.com>
	<AANLkTinxPyk-BbLNHVR5ZwURoHiYDLFba8z0Tc6ALnom@mail.gmail.com>
	<x6d3rl2lue.fsf@opencsw.org>
	<AANLkTinLa8=ah_ME9-kY0H7vJhTEUM-AoNA5bCRE3NrU@mail.gmail.com>
Message-ID: <AANLkTinuMQtS-RajRTJQjeQYER959uYZLLo_+JtXzR1+@mail.gmail.com>

On Fri, Oct 8, 2010 at 2:52 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> No dia 8 de Outubro de 2010 00:19, Peter FELECAN
> <pfelecan at opencsw.org> escreveu:
>> Philip Brown <phil at bolthole.com> writes:
>>
>>> you'll just have to be creative about name collision on the existing
>>> one.
>>
>> newchkpkg
>> superchkpkg
>> &c
>
> I was thinking about just upgrading checkpkg to the newer version.
> The current version (the one in GAR) is a functional superset of the
> old version (the one in CSWcswutils). ?If there are parts of
> infrastructure other than GAR that depend on checkpkg's interface
> (which has changed slightly), we can review the requirements and
> implement backward-compatibility mode.
>
> Are there any parts of infrastructure that depend on checkpkg from CSWcswutils?

side comment, semi-related.
I think it might be nice to separate out the python depending stuffs,
into a new package.

not sure what to call it though.

oh btw you already have an "older" version of your python-based checkpkg.
you just keep it at the library level, as "checkpkg.py", it seems like?

or, contrariwise, I wouldnt object to even doing things the opposite
way, and splitting out my "older" stuff, into a differently named,
non-python-depending package.

upgrade paths might get a bit hairy on that though.


> _______________________________________________
> 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  Mon Oct 11 06:20:43 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 10 Oct 2010 21:20:43 -0700
Subject: [csw-maintainers] No mirror updates in a week?
In-Reply-To: <AANLkTimze3_7sVyBOmOHzig93roZbzMma58SrNJxn5NC@mail.gmail.com>
References: <AANLkTikPhbW1=FPNLR24Jydwbq_8+ed0JF_a2iQ0RByX@mail.gmail.com>
	<AANLkTimze3_7sVyBOmOHzig93roZbzMma58SrNJxn5NC@mail.gmail.com>
Message-ID: <AANLkTimnzhTXw3O99CuADmKE_xaYgUOAvPUa3WxdyttD@mail.gmail.com>

oh, PS: there WOULD have been a release thursday, but that dependancy
chain breakage, stopped that.



On Sun, Oct 10, 2010 at 9:09 PM, Philip Brown <phil at bolthole.com> wrote:
> it WAS a very quiet week. and then I took a little weekend trip the
> last two days :)
> I'll be releasing stuffs imminently.
>
>

From maciej at opencsw.org  Mon Oct 11 08:02:59 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 11 Oct 2010 07:02:59 +0100
Subject: [csw-maintainers] GAR: Checks for shared library names
In-Reply-To: <AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>
References: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
	<AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>
Message-ID: <AANLkTimD71W_+pu8+2AtyPukMNKs45TtSiY=wGJ0srKg@mail.gmail.com>

No dia 11 de Outubro de 2010 05:13, Philip Brown <phil at bolthole.com> escreveu:
> On Sun, Oct 10, 2010 at 2:12 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> ....
>> Here goes the summary:
>>
>> 1. .so files should not be together with shared libraries.
>
> erm.. I presume you mean,
> "the SYMLINK for libxxxx.so ->libxxx.so.# should not go in the
> separated-out runtime package for the shared libraries".

Yes, and since the shared libraries should be in a separate package
anyway (in order for the library name and package name to match), they
don't end up in the same package, so they aren't together.

>> 2. If package contains multiple shared libraries, their versions
>> should match. ?For example, libfoo.so.1.2.3 and libfoo_bar.so.1.2.3
>> are OK to be together, but libfoo.so.1.2.3 and libfoo.2.1.3 are not.
>
> I dont think it is okay to "mandate" that.
> Otherwise, you have to spell out more what to do when braindead
> upstream people lump non-matching version together

Here's a short writeup:
http://wiki.opencsw.org/checkpkg-error-tags

It boils down to how are sonames retired: together, or one by one.  If
soname versions don't match, they are most likely to be retired
individually.  Our main operational unit is a package (we can retire a
package, but not half a package), so we need to match up packages and
sonames if we want to retire an individual soname.

By the way, in case of packages such as fltk, where soname versions
are in sync, checkpkg nicely infers the right package name:

sonames:
  libfltk.so.1.1
  libfltk_forms.so.1.1
  libfltk_gl.so.1.1
  libfltk_images.so.1.1

expected pkgname and catalogname:
  CSWlibfltk1-1, libfltk1_1

From maciej at opencsw.org  Mon Oct 11 13:51:42 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 11 Oct 2010 12:51:42 +0100
Subject: [csw-maintainers] checkpkg release
Message-ID: <AANLkTikJfXcStepYhDuMM+MPo+q-2GW37W+BJ1z8t5+-@mail.gmail.com>

No dia 11 de Outubro de 2010 05:18, Philip Brown <phil at bolthole.com> escreveu:
> On Fri, Oct 8, 2010 at 2:52 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> No dia 8 de Outubro de 2010 00:19, Peter FELECAN
>> <pfelecan at opencsw.org> escreveu:
>>> Philip Brown <phil at bolthole.com> writes:
>>>
>>>> you'll just have to be creative about name collision on the existing
>>>> one.
>>>
>>> newchkpkg
>>> superchkpkg
>>> &c
>>
>> I was thinking about just upgrading checkpkg to the newer version.
>> The current version (the one in GAR) is a functional superset of the
>> old version (the one in CSWcswutils). ?If there are parts of
>> infrastructure other than GAR that depend on checkpkg's interface
>> (which has changed slightly), we can review the requirements and
>> implement backward-compatibility mode.
>>
>> Are there any parts of infrastructure that depend on checkpkg from CSWcswutils?
>
> side comment, semi-related.
> I think it might be nice to separate out the python depending stuffs,
> into a new package.
>
> not sure what to call it though.
>
> oh btw you already have an "older" version of your python-based checkpkg.
> you just keep it at the library level, as "checkpkg.py", it seems like?

Yes, it's a Python module only, used by comparepkg and submitpkg; it's
not the checkpkg executable.

> or, contrariwise, I wouldnt object to even doing things the opposite
> way, and splitting out my "older" stuff, into a differently named,
> non-python-depending package.
>
> upgrade paths might get a bit hairy on that though.

If you want to fork and keep the old code around, you probably need to
find a place for it to live.  The currently installed version of
CSWcswutils has a checkpkg snapshot checked into the files/ directory
under the GAR build.

OK, so what do we do now - will you find a new place for the code and
let me know, or are you OK with retrieving the code from the
repository, or do you have your own copy of it?

From phil at bolthole.com  Mon Oct 11 19:22:03 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 11 Oct 2010 10:22:03 -0700
Subject: [csw-maintainers] checkpkg release
In-Reply-To: <AANLkTikJfXcStepYhDuMM+MPo+q-2GW37W+BJ1z8t5+-@mail.gmail.com>
References: <AANLkTikJfXcStepYhDuMM+MPo+q-2GW37W+BJ1z8t5+-@mail.gmail.com>
Message-ID: <AANLkTinKPmO_x4dsoOs97hZtxE_axSBuYJzdbKSGRmfq@mail.gmail.com>

At the moment, the "cswutils" package, is still centered around my
original suite of utilities, which were/are focused on building a
package more manually, without GAR assistance.
it's not just about ye olde 'checkpkg'.

The benefits to the old suite are that it is relatively lightweight,
in that it requires neither python, nor gar, and is self-contained. I
find some value in that.

I also see value in the GAR-based set of utilities, so am trying to
ponder what kind of split makes sense, both at the grouping level, and
at the naming level.

Would it make more sense to move the python/gar based stuff out to a
new package named "garutils"  ?





On 10/11/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>....
>> upgrade paths might get a bit hairy on that though.
>
> If you want to fork and keep the old code around, you probably need to
> find a place for it to live.  The currently installed version of
> CSWcswutils has a checkpkg snapshot checked into the files/ directory
> under the GAR build.
>
> OK, so what do we do now - will you find a new place for the code and
> let me know, or are you OK with retrieving the code from the
> repository, or do you have your own copy of it?
>

From bwalton at opencsw.org  Tue Oct 12 02:59:37 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 11 Oct 2010 20:59:37 -0400
Subject: [csw-maintainers] cswclassutils splitting
Message-ID: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>


Hi All,

I'm just about done with the changes to the GAR recipe will see each
CAS pair of scripts be shipped in a separate package.  As discussed
(quite some time ago) on the list, this will allow changes to one
package to be released without requiring all others to be updated at
the same time.

I've chosen CSWcas-$name as the format of the individual package
names.  Examples include CSWcas-initsmf and CSWcas-pycompile.  I'm
open to better suggestions here, but I think the above is reasonable.

The CSWcswclassutils package will depend on all sub-packages for now
until such time as nothing depends on CSWcswclassutils itself.

The last remaining wrinkle is how to distribute the directory:
/var/opt/csw/cswclassutils.  It's (currently) used by 2 of the CAS
script pairs as a place to write temp files during the CAS.  In the
short term, it can be 'owned' by CSWcswclassutils, but going forward
when dependencies are on the actual CAS required, it won't have
anything that guarantees its presence.

I see a few options for handling this:

1. Include it as part of CSWcommon.
2. Have any script that uses it do:
   [ -d /var/opt/csw/cswclassutils ] || mkdir -p /var/opt/csw/cswclassutils
3. Have the same action as above, but put it in a postinstall script
   for any package requiring the directory.

I personally favour option 2, but would like to hear what others think.

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


From phil at bolthole.com  Tue Oct 12 03:50:23 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 11 Oct 2010 18:50:23 -0700
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimY3Qoa4vmx2iVqxyx3M3x95eyNrc=Z+0r9zd46@mail.gmail.com>

On 10/11/10, Ben Walton <bwalton at opencsw.org> wrote:
>
>
> I see a few options for handling this:
>
> 1. Include it as part of CSWcommon.
> 2. Have any script that uses it do:
>    [ -d /var/opt/csw/cswclassutils ] || mkdir -p /var/opt/csw/cswclassutils
> 3. Have the same action as above, but put it in a postinstall script
>    for any package requiring the directory.
>
> I personally favour option 2, but would like to hear what others think.
>

I think option 2 would be best, when combined with a prototype entry
for it as well.
The whole point of classutils, is to remove postinstall scripts, so
having them trigger one rather goes against the grain :)
Class action scripts should, in my opinion, be very VERY resilient, so
the conditional  mkdir sounds like an exellent safety measure.

From bwalton at opencsw.org  Tue Oct 12 03:54:21 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 11 Oct 2010 21:54:21 -0400
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <AANLkTimY3Qoa4vmx2iVqxyx3M3x95eyNrc=Z+0r9zd46@mail.gmail.com>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
	<AANLkTimY3Qoa4vmx2iVqxyx3M3x95eyNrc=Z+0r9zd46@mail.gmail.com>
Message-ID: <1286848352-sup-190@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Mon Oct 11 21:50:23 -0400 2010:

> I think option 2 would be best, when combined with a prototype entry
> for it as well.

Wouldn't the prototype entry for the same directory in multiple
packages trigger issues with package registration, etc?

> The whole point of classutils, is to remove postinstall scripts, so
> having them trigger one rather goes against the grain :)

That what my thinking as well.

> Class action scripts should, in my opinion, be very VERY resilient,
> so the conditional mkdir sounds like an exellent safety measure.

Agreed.

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


From phil at bolthole.com  Tue Oct 12 17:44:07 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 12 Oct 2010 08:44:07 -0700
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <1286848352-sup-190@pinkfloyd.chass.utoronto.ca>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
	<AANLkTimY3Qoa4vmx2iVqxyx3M3x95eyNrc=Z+0r9zd46@mail.gmail.com>
	<1286848352-sup-190@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTin=9LDtKxkeZdh9L8Wn68sWjwv5eyszCb6=RsXj@mail.gmail.com>

On 10/11/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Mon Oct 11 21:50:23 -0400 2010:
>
>> I think option 2 would be best, when combined with a prototype entry
>> for it as well.
>
> Wouldn't the prototype entry for the same directory in multiple
> packages trigger issues with package registration, etc?
>

Nope. Overlapping directories is an okay situation. It's just files
that are a problem.

From bwalton at opencsw.org  Tue Oct 12 17:51:11 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 12 Oct 2010 11:51:11 -0400
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <AANLkTin=9LDtKxkeZdh9L8Wn68sWjwv5eyszCb6=RsXj@mail.gmail.com>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
	<AANLkTimY3Qoa4vmx2iVqxyx3M3x95eyNrc=Z+0r9zd46@mail.gmail.com>
	<1286848352-sup-190@pinkfloyd.chass.utoronto.ca>
	<AANLkTin=9LDtKxkeZdh9L8Wn68sWjwv5eyszCb6=RsXj@mail.gmail.com>
Message-ID: <1286898637-sup-8488@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Tue Oct 12 11:44:07 -0400 2010:

> > Wouldn't the prototype entry for the same directory in multiple
> > packages trigger issues with package registration, etc?
> 
> Nope. Overlapping directories is an okay situation. It's just files
> that are a problem.

Ok, I'll add the directory to all prototypes that need it and augment
the scripts with the additional check.

Thanks
-Ben

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


From dam at opencsw.org  Tue Oct 12 20:52:38 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 12 Oct 2010 20:52:38 +0200
Subject: [csw-maintainers] nginx needs minimum sparcv8plus
In-Reply-To: <201010122208.35582.ai@vsu.ru>
References: <E1P5hzI-0006ME-4a@sfp-svn-3.v30.ch3.sourceforge.com>
	<201010122117.26881.ai@vsu.ru>
	<D69D72A7-0768-4357-B53A-BB5D8DC04089@opencsw.org>
	<201010122208.35582.ai@vsu.ru>
Message-ID: <17099B6D-ECB3-42F4-B1D9-9D67A3A95339@opencsw.org>

Hi Andy,

Am 12.10.2010 um 20:08 schrieb Andy Igoshin:
> nginx does not support pure v8 arch, only from v8+:
> ---------------------------------------------------
> /opt/studio/SOS11/SUNWspro/bin/cc -c -fast -xipo -xarch=v8 -errwarn= 
> %all -g -
> I/opt/csw/include -I/opt/csw/include/openssl -I src/core -I src/ 
> event -I
> src/event/modules -I src/os/unix -I objs \
>        -o objs/src/core/nginx.o \
>        src/core/nginx.c src/os/unix/ngx_sunpro_sparc64.il
> 22:         .inline ngx_casa,0
> 23:         casa    [%o2] 0x80, %o1, %o0
> 24:         .end
> cg error (as) : "/home/ai/mgar/pkg/nginx/trunk/work/solaris9-sparc/ 
> build-isa-
> sparcv8/nginx-0.8.52/src/os/unix/ngx_sunpro_sparc64.il (template for  
> ngx_casa)",
> line 23 : cannot use SPARC v9 instructions with this target  
> architecture
> cc: cg failed for src/core/nginx.c
> ---------------------------------------------------
>
> may i exclude v8 support from this package?

Wow. Ok, from what I see I suppose you are already using isaexec.
I suggest explicitly not delivering sparcv8 by resetting the sparc
default with
   ISA_DEFAULT_sparc = sparcv8plus
and removing it from
   EXTRA_BUILD_ISAS_sparc
That way it won't even start on sparcv8. cc'ing maintainers@ as this
is of general interest.


Best regards

   -- Dago

>
>
> On Tue of October 12 2010 21:49:45 you wrote:
>> Hi Andy,
>>
>> Am 12.10.2010 um 19:17 schrieb Andy Igoshin:
>>> On Tue of October 12 2010 20:58:57 you wrote:
>>>> Hi Andy,
>>>>
>>>> thanks!
>>>
>>> is it now enough to run only this command?
>>>
>>> gmake platforms
>>
>> Nope.
>>
>>> or these two commands additionally should be run?
>>>
>>> gmake platforms-remerge
>>> gmake platforms-repackage
>>
>> I am unsure what ISA modulations need to be recompiled in your case.
>> Usually I do a full
>>   gmake spotless
>>   gmake platforms
>> before a release if I did some changes to the package build itself.
>>
>>> please remove from /newpkgs packages which i uploaded today.
>>
>> Unfortunately I don't have root on that machine. You can ask
>> Phil to remove it or do it yourself with
>>   ssh bender.opencsw.org
>>   rm /home/newpkgs/nginx*
>> from the host from where you copied your packages.
>>
>>
>> Best regards
>>
>>   -- Dago
>
> -- 
> Andy Igoshin <ai at vsu.ru>                 Voronezh State University
> Phone: +7 (4732) 522406                  Network Operation Center
> Fax:   +7 (4732) 208820                  Voronezh, Russia


From bwalton at opencsw.org  Wed Oct 13 03:28:20 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 12 Oct 2010 21:28:20 -0400
Subject: [csw-maintainers] state of cswclassutils scripts?
Message-ID: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>


Hi All,

THe changes to produce separate packages for each i/r CAS pair are
ready.  The current release is REV=2010.06.15 but there have been
several non-GAR changes to the scripts that ship.  Are cswinitsmf and
cswpreservconf in release shape?  If so, I'd like to push out the
first release of the CSWcas-* version.

When these are released, I've got a minor GAR change in the pipe that
will add the dependencies at the more granular level.

Let me know.

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


From maciej at opencsw.org  Wed Oct 13 14:17:43 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 13 Oct 2010 13:17:43 +0100
Subject: [csw-maintainers] Revisiting the GCC4 Undefined symbol
 __sync_fetch_and_add_4 nonsense
In-Reply-To: <4C8A634E.8030803@opencsw.org>
References: <4C8A634E.8030803@opencsw.org>
Message-ID: <AANLkTimnU_tP+G6xC7TRAZ6PkZ2fhjZ7c_m4z-16X5-w@mail.gmail.com>

Wow, this e-mail remained unanswered for a long time.

No dia 10 de Setembro de 2010 17:56, Geoff Davis <gadavis at opencsw.org> escreveu:
> ?Hi all,
>
> I'm battling with a program called NetCDF that can't be compiled under Sun
> Studio due to problems with the redistribution of the Fortran to C
> libraries.

What's the current status of the Sun Studio build?  I remember Dago
putting together a Fortran library package.  (And discovering that
some binaries weren't build for the architecture they were supposed
to.)

> I'm attempting to compile under GCC4, but I'm getting a link
> error in the C++ bindings where it starts looking for a symbol called
> __sync_fetch_and_add_4. I'm on a Sparc system, so this of course fails.
>
> Roger mentioned that he tweaked the compiler options for GCC4 from -mcpu=v8
> to -m32. I tried this but checkpackage whined that all of my binaries and
> libraries were compiled for v8+ instead of v8 and wanted them in
> arch-specific sub directories.

Is a hardware instruction present in sparcv8+, and not in sparcv8?
Does anyone know?

> Also, I haven't been able to get ahold of Ihsan recently. I actually sent a
> couple of emails to this list last Friday, September 3, but they never
> posted. I'm trying to use the mail.opencsw.org SMTP server instead of my
> work SMTP box in case there is some weird interaction there.

I've seen a commit from Ihsan today.  Did you get hold of him?

From dam at opencsw.org  Wed Oct 13 14:33:27 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 13 Oct 2010 14:33:27 +0200
Subject: [csw-maintainers] Revisiting the GCC4 Undefined symbol
	__sync_fetch_and_add_4 nonsense
In-Reply-To: <AANLkTimnU_tP+G6xC7TRAZ6PkZ2fhjZ7c_m4z-16X5-w@mail.gmail.com>
References: <4C8A634E.8030803@opencsw.org>
	<AANLkTimnU_tP+G6xC7TRAZ6PkZ2fhjZ7c_m4z-16X5-w@mail.gmail.com>
Message-ID: <B98ABBE3-3FC9-417C-ADEE-0ED94E466395@opencsw.org>

Hi,

Am 13.10.2010 um 14:17 schrieb Maciej (Matchek) Blizinski:
> Wow, this e-mail remained unanswered for a long time.
>
> No dia 10 de Setembro de 2010 17:56, Geoff Davis  
> <gadavis at opencsw.org> escreveu:
>>  Hi all,
>>
>> I'm battling with a program called NetCDF that can't be compiled  
>> under Sun
>> Studio due to problems with the redistribution of the Fortran to C
>> libraries.
>
> What's the current status of the Sun Studio build?  I remember Dago
> putting together a Fortran library package.  (And discovering that
> some binaries weren't build for the architecture they were supposed
> to.)
>
>> I'm attempting to compile under GCC4, but I'm getting a link
>> error in the C++ bindings where it starts looking for a symbol called
>> __sync_fetch_and_add_4. I'm on a Sparc system, so this of course  
>> fails.
>>
>> Roger mentioned that he tweaked the compiler options for GCC4 from - 
>> mcpu=v8
>> to -m32. I tried this but checkpackage whined that all of my  
>> binaries and
>> libraries were compiled for v8+ instead of v8 and wanted them in
>> arch-specific sub directories.
>
> Is a hardware instruction present in sparcv8+, and not in sparcv8?
> Does anyone know?

BTW, I am having this same exact error on libtag_gcc now :-(


Best regards

   -- Dago


From maciej at opencsw.org  Wed Oct 13 14:42:00 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 13 Oct 2010 13:42:00 +0100
Subject: [csw-maintainers] Revisiting the GCC4 Undefined symbol
 __sync_fetch_and_add_4 nonsense
In-Reply-To: <B98ABBE3-3FC9-417C-ADEE-0ED94E466395@opencsw.org>
References: <4C8A634E.8030803@opencsw.org>
	<AANLkTimnU_tP+G6xC7TRAZ6PkZ2fhjZ7c_m4z-16X5-w@mail.gmail.com>
	<B98ABBE3-3FC9-417C-ADEE-0ED94E466395@opencsw.org>
Message-ID: <AANLkTikOzz-wVoujBBopMOSd9cPL8Rr=dDnvDSOAOc2x@mail.gmail.com>

No dia 13 de Outubro de 2010 13:33, Dagobert Michelsen
<dam at opencsw.org> escreveu:
>>> Roger mentioned that he tweaked the compiler options for GCC4 from
>>> -mcpu=v8
>>> to -m32. I tried this but checkpackage whined that all of my binaries and
>>> libraries were compiled for v8+ instead of v8 and wanted them in
>>> arch-specific sub directories.
>>
>> Is a hardware instruction present in sparcv8+, and not in sparcv8?
>> Does anyone know?
>
> BTW, I am having this same exact error on libtag_gcc now :-(

Is the sparcv8 support worth the trouble?

From maciej at opencsw.org  Wed Oct 13 15:27:14 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 13 Oct 2010 14:27:14 +0100
Subject: [csw-maintainers] CSW/GAR maintainer world map via Ohloh (once
	again)
In-Reply-To: <4C7187F7.9010508@opencsw.org>
References: <4C7187F7.9010508@opencsw.org>
Message-ID: <AANLkTinz+Z3U9rpE7fd-2GvTRSkwXoiOYp6jJncfsyYM@mail.gmail.com>

No dia 22 de Agosto de 2010 21:26, Sebastian Kayser
<skayser at opencsw.org> escreveu:
> from all over the globe people contribute to OpenCSW. In particular, I
> am going to give a talk about OpenCSW to our Munich OpenSolaris User
> Group this Thursday (...)

How did the talk go?

From maciej at opencsw.org  Wed Oct 13 18:00:59 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 13 Oct 2010 17:00:59 +0100
Subject: [csw-maintainers] Automatically excluding .pyc files
Message-ID: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>

GAR used to automatically exclude the .pyc files from Python packages
(category="python"), but it doesn't do that any more.  Does anyone
know why might that be?

Maciej

From bwalton at opencsw.org  Wed Oct 13 18:12:31 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 12:12:31 -0400
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
Message-ID: <1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 13 12:00:59 -0400 2010:

> GAR used to automatically exclude the .pyc files from Python
> packages (category="python"), but it doesn't do that any more.  Does
> anyone know why might that be?

I adjusted the _PYCOMPILE_FILES path from /opt/csw/lib/python/ to
.../python2.6 the other day as that is where new files are going.
This value is used to exclude the .pyc files.  I guess we need to
extend this value, not replace it?

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


From maciej at opencsw.org  Wed Oct 13 18:35:29 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 13 Oct 2010 17:35:29 +0100
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>

No dia 13 de Outubro de 2010 17:12, Ben Walton <bwalton at opencsw.org> escreveu:
> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 13 12:00:59 -0400 2010:
>
>> GAR used to automatically exclude the .pyc files from Python
>> packages (category="python"), but it doesn't do that any more. ?Does
>> anyone know why might that be?
>
> I adjusted the _PYCOMPILE_FILES path from /opt/csw/lib/python/ to
> .../python2.6 the other day as that is where new files are going.

Unfortunately, files don't go there at the moment.  I have a plan of
making them go there, but it'll take time.

> This value is used to exclude the .pyc files. ?I guess we need to
> extend this value, not replace it?

Yes, I agree.

From bwalton at opencsw.org  Wed Oct 13 18:40:33 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 12:40:33 -0400
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
Message-ID: <1286987968-sup-8563@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 13 12:35:29 -0400 2010:

> Unfortunately, files don't go there at the moment.  I have a plan of
> making them go there, but it'll take time.

When I re-rolled libxslt, the python files for it went in
python2.6/...?  That's what prompted me to update GAR.

Should my change just be plain reverted?  What would cause the .py
files for py_libxslt to end up in the wrong place?

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


From phil at bolthole.com  Wed Oct 13 18:45:44 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 13 Oct 2010 09:45:44 -0700
Subject: [csw-maintainers] state of cswclassutils scripts?
In-Reply-To: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>
References: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimMxv4x69PRz6v40YCU-d7ohbZQanoZ2dDRpDND@mail.gmail.com>

On 10/12/10, Ben Walton <bwalton at opencsw.org> wrote:
>
> Hi All,
>
> THe changes to produce separate packages for each i/r CAS pair are
> ready.  The current release is REV=2010.06.15 but there have been
> several non-GAR changes to the scripts that ship.  Are cswinitsmf and
> cswpreservconf in release shape?  If so, I'd like to push out the
> first release of the CSWcas-* version.
>

I'm not aware of any non-gar changes to cswpreservconf.
(i was PLANNING some changes, but have not coded them yet :-/  )

From bwalton at opencsw.org  Wed Oct 13 18:49:43 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 12:49:43 -0400
Subject: [csw-maintainers] state of cswclassutils scripts?
In-Reply-To: <AANLkTimMxv4x69PRz6v40YCU-d7ohbZQanoZ2dDRpDND@mail.gmail.com>
References: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>
	<AANLkTimMxv4x69PRz6v40YCU-d7ohbZQanoZ2dDRpDND@mail.gmail.com>
Message-ID: <1286988511-sup-9702@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed Oct 13 12:45:44 -0400 2010:

> I'm not aware of any non-gar changes to cswpreservconf.
> (i was PLANNING some changes, but have not coded them yet :-/  )

The svn log show:

------------------------------------------------------------------------
r11130 | theferret | 2010-10-02 17:33:29 +0200 (Sat, 02 Oct 2010) | 2 lines
i.cswpreservconf: fixed syntax err
------------------------------------------------------------------------
r10802 | theferret | 2010-08-24 00:37:00 +0200 (Tue, 24 Aug 2010) | 2 lines
cswclassutils: Added support for CSWDESTDIR to cswpreserveconf

These are both later than the current REV= date for the released
package...

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


From maciej at opencsw.org  Wed Oct 13 18:49:02 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 13 Oct 2010 17:49:02 +0100
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <1286987968-sup-8563@pinkfloyd.chass.utoronto.ca>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<1286987968-sup-8563@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTim6gVsnRG2wGzoLEi=mKnYgDMk1-uod14QBkbub@mail.gmail.com>

No dia 13 de Outubro de 2010 17:40, Ben Walton <bwalton at opencsw.org> escreveu:
> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 13 12:35:29 -0400 2010:
>
>> Unfortunately, files don't go there at the moment. ?I have a plan of
>> making them go there, but it'll take time.
>
> When I re-rolled libxslt, the python files for it went in
> python2.6/...? ?That's what prompted me to update GAR.

That's an anomaly.  Those files won't work with currently packaged Python.

> Should my change just be plain reverted? ?What would cause the .py
> files for py_libxslt to end up in the wrong place?

Perhaps libxslt's build builds the base path for modules on its own
instead of asking Python about it.  For this to work, you need to move
them to the currently used location.

We'll be moving to version-specific directory at some point, but we
aren't there yet.

Can you revert the change?

We could also add a check in checkpkg to prevent this from happening
in the future in the case that any other packages try to put their
files there.

Maciej

From bwalton at opencsw.org  Wed Oct 13 19:03:40 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 13:03:40 -0400
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTim6gVsnRG2wGzoLEi=mKnYgDMk1-uod14QBkbub@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<1286987968-sup-8563@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6gVsnRG2wGzoLEi=mKnYgDMk1-uod14QBkbub@mail.gmail.com>
Message-ID: <1286989367-sup-7037@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 13 12:49:02 -0400 2010:

> That's an anomaly.  Those files won't work with currently packaged
> Python.

Ok, I'll undo my changes (not until this evening though).

> 
> Perhaps libxslt's build builds the base path for modules on its own
> instead of asking Python about it.  For this to work, you need to move
> them to the currently used location.

I've got some other fixes required for py_libxslt anyway, so I'll dig
into this a bit more.

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


From phil at bolthole.com  Wed Oct 13 19:36:55 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 13 Oct 2010 10:36:55 -0700
Subject: [csw-maintainers] state of cswclassutils scripts?
In-Reply-To: <1286988511-sup-9702@pinkfloyd.chass.utoronto.ca>
References: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>
	<AANLkTimMxv4x69PRz6v40YCU-d7ohbZQanoZ2dDRpDND@mail.gmail.com>
	<1286988511-sup-9702@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTik_1umz22y-cX2iPaB97QA1LDNp+F6kghWOTck6@mail.gmail.com>

On 10/13/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Wed Oct 13 12:45:44 -0400 2010:
>
>> I'm not aware of any non-gar changes to cswpreservconf.
>> (i was PLANNING some changes, but have not coded them yet :-/  )
>
> The svn log show:
>
> ------------------------------------------------------------------------
> r11130 | theferret | 2010-10-02 17:33:29 +0200 (Sat, 02 Oct 2010) | 2 lines
> i.cswpreservconf: fixed syntax err
> ------------------------------------------------------------------------
> r10802 | theferret | 2010-08-24 00:37:00 +0200 (Tue, 24 Aug 2010) | 2 lines
> cswclassutils: Added support for CSWDESTDIR to cswpreserveconf
>
> These are both later than the current REV= date for the released
> package...


I dont see how you describe these changes as "non-gar", since they are
in the gar/subversion tree.

From phil at bolthole.com  Wed Oct 13 19:39:50 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 13 Oct 2010 10:39:50 -0700
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
Message-ID: <AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>

On 10/13/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 13 de Outubro de 2010 17:12, Ben Walton <bwalton at opencsw.org>
> escreveu:
>> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 13 12:00:59
>> -0400 2010:
>>
>>> GAR used to automatically exclude the .pyc files from Python
>>> packages (category="python"), but it doesn't do that any more.  Does
>>> anyone know why might that be?
>>
>> I adjusted the _PYCOMPILE_FILES path from /opt/csw/lib/python/ to
>> .../python2.6 the other day as that is where new files are going.
>
> Unfortunately, files don't go there at the moment.  I have a plan of
> making them go there, but it'll take time.
>

wait what?
we've been through this a few times. python files need to be compiled
to a single, consistent place. Altering the dest with numerical
revisions, has caused problems in the past.
Mostly with python-dependant modules/utils.
Unfortunately, I'm not a python expert, so cant explain further... i
just know as release manager, that there were major problems with it,
that adversely affected multiple packages.

From bwalton at opencsw.org  Wed Oct 13 19:40:35 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 13:40:35 -0400
Subject: [csw-maintainers] state of cswclassutils scripts?
In-Reply-To: <AANLkTik_1umz22y-cX2iPaB97QA1LDNp+F6kghWOTck6@mail.gmail.com>
References: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>
	<AANLkTimMxv4x69PRz6v40YCU-d7ohbZQanoZ2dDRpDND@mail.gmail.com>
	<1286988511-sup-9702@pinkfloyd.chass.utoronto.ca>
	<AANLkTik_1umz22y-cX2iPaB97QA1LDNp+F6kghWOTck6@mail.gmail.com>
Message-ID: <1286991557-sup-2224@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed Oct 13 13:36:55 -0400 2010:
> > ------------------------------------------------------------------------
> > r11130 | theferret | 2010-10-02 17:33:29 +0200 (Sat, 02 Oct 2010) | 2 lines
> > i.cswpreservconf: fixed syntax err
> > ------------------------------------------------------------------------
> > r10802 | theferret | 2010-08-24 00:37:00 +0200 (Tue, 24 Aug 2010) | 2 lines
> > cswclassutils: Added support for CSWDESTDIR to cswpreserveconf
> >
> > These are both later than the current REV= date for the released
> > package...

Ummm...because they modify the files (and thus functionality)
delivered.  A GAR change would mean (in the sense I'm using) a change
to the packaging recipe.

Basically, you committed changes to the files that are newer than our
released package.  Have these changes been tested?  Are they ready for
a release?

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


From bwalton at opencsw.org  Wed Oct 13 20:57:08 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 14:57:08 -0400
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pkgconfig, tcsh
In-Reply-To: <201010131846.o9DIkuBX028538@login.bo.opencsw.org>
References: <201010131846.o9DIkuBX028538@login.bo.opencsw.org>
Message-ID: <1286996194-sup-4368@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Wed Oct 13 14:46:56 -0400 2010:

> This is now compiled with 64 bit file offsets for files >2GB
> 
> * tcsh: revision upgrade

...but is it still considered harmful? :)

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


From phil at bolthole.com  Wed Oct 13 21:17:04 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 13 Oct 2010 12:17:04 -0700
Subject: [csw-maintainers] state of cswclassutils scripts?
In-Reply-To: <1286991557-sup-2224@pinkfloyd.chass.utoronto.ca>
References: <1286933055-sup-8026@pinkfloyd.chass.utoronto.ca>
	<AANLkTimMxv4x69PRz6v40YCU-d7ohbZQanoZ2dDRpDND@mail.gmail.com>
	<1286988511-sup-9702@pinkfloyd.chass.utoronto.ca>
	<AANLkTik_1umz22y-cX2iPaB97QA1LDNp+F6kghWOTck6@mail.gmail.com>
	<1286991557-sup-2224@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikbkZOGzeh9zKhStw52-iuxYvNkD=UAY_SUaYqS@mail.gmail.com>

On 10/13/10, Ben Walton <bwalton at opencsw.org> wrote:
....
>> > These are both later than the current REV= date for the released
>> > package...
>
>...
> Basically, you committed changes to the files that are newer than our
> released package.  Have these changes been tested?  Are they ready for
> a release?
>

I believe I gave them some limited testing, and they worked. I was
holding off on release because of my anticipated longer term bigger
changes, but never got around to them.

It should certainly be tested again in the newly generated package.
but yes I believe they are ready for release.

From dam at opencsw.org  Wed Oct 13 21:59:53 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 13 Oct 2010 21:59:53 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pkgconfig, tcsh
In-Reply-To: <1286996194-sup-4368@pinkfloyd.chass.utoronto.ca>
References: <201010131846.o9DIkuBX028538@login.bo.opencsw.org>
	<1286996194-sup-4368@pinkfloyd.chass.utoronto.ca>
Message-ID: <F32214BD-091E-43C0-8541-67D2EAA08D0C@opencsw.org>

Hi Ben,

Am 13.10.2010 um 20:57 schrieb Ben Walton:
> Excerpts from Dagobert Michelsen's message of Wed Oct 13 14:46:56  
> -0400 2010:
>
>> This is now compiled with 64 bit file offsets for files >2GB
>>
>> * tcsh: revision upgrade
>
> ...but is it still considered harmful? :)

C-Shell itself was never considered harmful. C-Shell PROGRAMMING was
(and is more than ever) considered harmful :-)
   http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
...and I just noticed it is written by Tom Christiansen, the Perl- 
?berguru!


Best regards

   -- Dago

From bwalton at opencsw.org  Thu Oct 14 04:24:35 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 22:24:35 -0400
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
Message-ID: <1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed Oct 13 13:39:50 -0400 2010:

> wait what?

> we've been through this a few times. python files need to be
> compiled to a single, consistent place. Altering the dest with
> numerical revisions, has caused problems in the past.

Ok, I'm looking at libxslt python handling right now and it goes to
great lengths to find a version numbered python site-packages and
includes directory.

Looking at my debian box here, I have _only_ version suffixed
directories...there is no generic /usr/lib/python.

$ ls -ld python*
drwxr-xr-x 21 root root 20480 2010-01-23 08:05 python2.5
drwxr-xr-x 23 root root 20480 2010-04-30 07:24 python2.6
drwxr-xr-x 28 root root 20480 2010-09-29 07:35 python3.1

Looking at current9x, we have /opt/csw/include/python (mostly empty)
and /opt/csw/include/python2.6 (the expected files).  We then have
/opt/csw/lib/python2.6 (mostly empty) and /opt/csw/lib/python
(expected set of files).  This is internally inconsistent. :(

So, the question is, why are we _not_ shipping .py files in a version
specific site-packages area?  Is this the general aversion to shipping
multiple python packages to support multiple version simultaneously?

Given the landscape that I see out there, it looks to be logical to
ship a functional python2.5 (maybe not now), python2.6, python3.x, etc
that can co-exist.  If we shipped a python 2.7 (for example only),
we'd have lib/python2.7, include/python2.7 and bin/python2.7
(alternatives could provide the bin/python).

This should make version upgrades of python less problematic for
modules that are built against $current_version.  Similar to what
we're aiming to do with libraries, we could do with interpreters...

Thoughts?

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


From bwalton at opencsw.org  Thu Oct 14 04:31:50 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 13 Oct 2010 22:31:50 -0400
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs pkgconfig, tcsh
In-Reply-To: <F32214BD-091E-43C0-8541-67D2EAA08D0C@opencsw.org>
References: <201010131846.o9DIkuBX028538@login.bo.opencsw.org>
	<1286996194-sup-4368@pinkfloyd.chass.utoronto.ca>
	<F32214BD-091E-43C0-8541-67D2EAA08D0C@opencsw.org>
Message-ID: <1287023091-sup-3621@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Wed Oct 13 15:59:53 -0400 2010:

Hi Dago,

> C-Shell itself was never considered harmful. C-Shell PROGRAMMING was
> (and is more than ever) considered harmful :-)

True. :)

>    http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
> ...and I just noticed it is written by Tom Christiansen, the Perl- 
> ?berguru!

I always enjoy re-reading this.

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


From maciej at opencsw.org  Thu Oct 14 08:21:54 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 14 Oct 2010 07:21:54 +0100
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
	<1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>

No dia 14 de Outubro de 2010 03:24, Ben Walton <bwalton at opencsw.org> escreveu:
> Excerpts from Philip Brown's message of Wed Oct 13 13:39:50 -0400 2010:
>
>> wait what?
>
>> we've been through this a few times. python files need to be
>> compiled to a single, consistent place. Altering the dest with
>> numerical revisions, has caused problems in the past.
>
> Ok, I'm looking at libxslt python handling right now and it goes to
> great lengths to find a version numbered python site-packages and
> includes directory.
>
> Looking at my debian box here, I have _only_ version suffixed
> directories...there is no generic /usr/lib/python.
>
> $ ls -ld python*
> drwxr-xr-x 21 root root 20480 2010-01-23 08:05 python2.5
> drwxr-xr-x 23 root root 20480 2010-04-30 07:24 python2.6
> drwxr-xr-x 28 root root 20480 2010-09-29 07:35 python3.1
>
> Looking at current9x, we have /opt/csw/include/python (mostly empty)
> and /opt/csw/include/python2.6 (the expected files). ?We then have
> /opt/csw/lib/python2.6 (mostly empty) and /opt/csw/lib/python
> (expected set of files). ?This is internally inconsistent. :(
>
> So, the question is, why are we _not_ shipping .py files in a version
> specific site-packages area? ?Is this the general aversion to shipping
> multiple python packages to support multiple version simultaneously?
>
> Given the landscape that I see out there, it looks to be logical to
> ship a functional python2.5 (maybe not now), python2.6, python3.x, etc
> that can co-exist. ?If we shipped a python 2.7 (for example only),
> we'd have lib/python2.7, include/python2.7 and bin/python2.7
> (alternatives could provide the bin/python).
>
> This should make version upgrades of python less problematic for
> modules that are built against $current_version. ?Similar to what
> we're aiming to do with libraries, we could do with interpreters...
>
> Thoughts?

I agree with Ben.  The Python file placement in CSWpython predates my
involvement in the project, so I don't have any opinion on the
problems that were happening in the past.  I have some knowledge about
what is the standard way of packaging Python, and what we're doing is
not it.

Each Python version requires the rebuild of all the modules.  Here's a
sketch of what packages could be named like:

CSWpython (symlink only)
CSWpython-devel (one devel package pointing at the newest Python)
CSWpython26 (specific version of the interpreter)
CSWpython27 (specific version of the interpreter)
CSWpython31 (specific version of the interpreter)
CSWlibpython2_5_1_0 (libpython for 2.5)
CSWlibpython2_6_1_0 (libpython for 2.6)
CSWpy26-foo (Python module for 2.6)
CSWpy27-foo (Python module for 2.7)
CSWpy31-foo (Python module for 3.1)

From dam at opencsw.org  Thu Oct 14 08:32:45 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 14 Oct 2010 08:32:45 +0200
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
	<1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
	<AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>
Message-ID: <6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>

Hi Maciej,

Am 14.10.2010 um 08:21 schrieb Maciej (Matchek) Blizinski:
> Each Python version requires the rebuild of all the modules.  Here's a
> sketch of what packages could be named like:
>
> CSWpython (symlink only)
> CSWpython-devel (one devel package pointing at the newest Python)
> CSWpython26 (specific version of the interpreter)
> CSWpython27 (specific version of the interpreter)
> CSWpython31 (specific version of the interpreter)
> CSWlibpython2_5_1_0 (libpython for 2.5)
> CSWlibpython2_6_1_0 (libpython for 2.6)
> CSWpy26-foo (Python module for 2.6)
> CSWpy27-foo (Python module for 2.7)
> CSWpy31-foo (Python module for 3.1)

Just as a note: Perl is not much different here and we choose to not  
have
a version in all modules. However, that required us to atomically  
rebuild
all modules. Maybe it would be good to have a consistent strategy here?


Best regards

   -- Dago


From maciej at opencsw.org  Thu Oct 14 10:07:06 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 14 Oct 2010 09:07:06 +0100
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
	<1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
	<AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>
	<6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>
Message-ID: <AANLkTikac5GeE=rTycLvKvmj5Ky25qnx+OGnMXi+sNi4@mail.gmail.com>

No dia 14 de Outubro de 2010 07:32, Dagobert Michelsen
<dam at opencsw.org> escreveu:
> Hi Maciej,
>
> Am 14.10.2010 um 08:21 schrieb Maciej (Matchek) Blizinski:
>>
>> Each Python version requires the rebuild of all the modules. ?Here's a
>> sketch of what packages could be named like:
>>
>> CSWpython (symlink only)
>> CSWpython-devel (one devel package pointing at the newest Python)
>> CSWpython26 (specific version of the interpreter)
>> CSWpython27 (specific version of the interpreter)
>> CSWpython31 (specific version of the interpreter)
>> CSWlibpython2_5_1_0 (libpython for 2.5)
>> CSWlibpython2_6_1_0 (libpython for 2.6)
>> CSWpy26-foo (Python module for 2.6)
>> CSWpy27-foo (Python module for 2.7)
>> CSWpy31-foo (Python module for 3.1)
>
> Just as a note: Perl is not much different here and we choose to not have
> a version in all modules. However, that required us to atomically rebuild
> all modules. Maybe it would be good to have a consistent strategy here?

If I have to choose between being consistent with how Perl is packaged
and how Python is packaged, I'd go with the latter.  I don't see any
real benefits for choosing the "one Python" strategy.  At the same
time, I see serious downsides.  For example, if you write any serious
Python code, you write it for a specific version, and you lock it down
to that Python version.  You might migrate it later on to a newer
version, but migration is a separate process.  You quite often need
Python 2.4 to run some scripts, and Python 2.6 to run others.  I might
point out that at some point in time I really wished OpenCSW provided
CSWpython-2.4, because I had scripts that used it specifically.  So,
in short, you would need a really compelling argument to convince me
that "one Python" is better.

From james at opencsw.org  Thu Oct 14 11:28:44 2010
From: james at opencsw.org (James Lee)
Date: Thu, 14 Oct 2010 09:28:44 GMT
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
Message-ID: <20101014.9284400.3615393619@gyor.oxdrove.co.uk>

On 12/10/10, 01:59:37, Ben Walton <bwalton at opencsw.org> wrote regarding 
[csw-maintainers] cswclassutils splitting:

> I'm just about done with the changes to the GAR recipe will see each
> CAS pair of scripts be shipped in a separate package

Please don't.  The CAS can only be installed in the global zone
splitting means every one has to be installed.



James.




From phil at bolthole.com  Thu Oct 14 18:27:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 14 Oct 2010 09:27:29 -0700
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <20101014.9284400.3615393619@gyor.oxdrove.co.uk>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
	<20101014.9284400.3615393619@gyor.oxdrove.co.uk>
Message-ID: <AANLkTinDiW5VuwHhHsboMW0P=GAweF1dN20anwMfsAT8@mail.gmail.com>

On 10/14/10, James Lee <james at opencsw.org> wrote:
> On 12/10/10, 01:59:37, Ben Walton <bwalton at opencsw.org> wrote regarding
> [csw-maintainers] cswclassutils splitting:
>
>> I'm just about done with the changes to the GAR recipe will see each
>> CAS pair of scripts be shipped in a separate package
>
> Please don't.  The CAS can only be installed in the global zone
> splitting means every one has to be installed.
>

there *was* a brief discussion on this a few months ago James (dont
remember HOW many months ago at this point, but...)

the general consensus of people replying, agreed that, given that we
are accumilating more and more separate CAS scripts, it would actually
be less aggravating to security-concious people in the long run, to
split them up.
This is because of the dichotomy between core, ideally stable scripts,
vs up and coming ones.

Lets say a site is very security concious, and only uses a handful of
our package, and they only need one or two of the long time "core" CAS
scripts.
They could install the global-zone cas package once... then go through
a bunch of zone level package upgrades without hassle, over the time
period of a year.

We have multiple updates, to multiple CAS scripts, in the course of
the year. each one generates a "new" cswclassutils package. Which
means that every time that site updates their zone-level packages,
they would "need "to update their back-rev cswclassutils package. For
no reason, from their standpoint. Yet they would still need to do so..
and then security-analyze ALL the scripts in that package.

If the scripts are broken up, then not only should it ideally mean
less frequent updates to relevant CAS packages.. but when updates do
happen, they should be less painful from an audit point of view.

From maciej at opencsw.org  Thu Oct 14 20:55:52 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 14 Oct 2010 19:55:52 +0100
Subject: [csw-maintainers] GAR: Checks for shared library names
In-Reply-To: <AANLkTimD71W_+pu8+2AtyPukMNKs45TtSiY=wGJ0srKg@mail.gmail.com>
References: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
	<AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>
	<AANLkTimD71W_+pu8+2AtyPukMNKs45TtSiY=wGJ0srKg@mail.gmail.com>
Message-ID: <AANLkTinX-9i_-WQA--682JukWpm=QX0cNcwg0+nE-jPy@mail.gmail.com>

I've just pushed a new change to checkpkg:

When it spots a set of sonames that look like good candidates for
splitting out, it prints out suggested GAR lines.  Here's output from
the analysis of CSWnspr:


 * Package CSWnspr contains shared libraries with sonames that don't have
   compatible versions: ['libnspr4.so', 'libplc4.so', 'libplds4.so'].  This
   means that they are best placed in own packages, with each package named
   after library name and version.

# Checkpkg suggests adding the following lines to the GAR recipe:
# This is a summary; see above for details.
# Suggesting how to separate out libnspr4.so
# You will most probably need to further edit these lines. Use with caution!
PACKAGES += CSWlibnspr4
CATALOGNAME_CSWlibnspr4 += libnspr4
PKGFILES_CSWlibnspr4 += /opt/csw/lib/libnspr4.so
PKGFILES_CSWlibnspr4 += /opt/csw/lib/libnspr4.so\.[0-9\.]+
RUNTIME_DEP_PKGS_CSWnspr += CSWlibnspr4

Out of the two lines with libnspr4.so, the first one is based on the
file name, and the latter is based on soname plus a version matching
regex.  It also suggests adding a dependency, to preserve the required
chain of dependencies if this is a modification of an already released
package.

As noted, this is to be used with caution; its purpose is to make it
easier to work with GAR builds, while still thinking about which lines
we put into the Makefiles and why.

Enjoy!

--Maciej

From dam at opencsw.org  Thu Oct 14 21:12:20 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 14 Oct 2010 21:12:20 +0200
Subject: [csw-maintainers] GAR: Checks for shared library names
In-Reply-To: <AANLkTinX-9i_-WQA--682JukWpm=QX0cNcwg0+nE-jPy@mail.gmail.com>
References: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
	<AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>
	<AANLkTimD71W_+pu8+2AtyPukMNKs45TtSiY=wGJ0srKg@mail.gmail.com>
	<AANLkTinX-9i_-WQA--682JukWpm=QX0cNcwg0+nE-jPy@mail.gmail.com>
Message-ID: <5575B096-36CE-4017-B610-72BCAA27F58D@opencsw.org>

Hi Maciej,

Am 14.10.2010 um 20:55 schrieb Maciej (Matchek) Blizinski:
> I've just pushed a new change to checkpkg:
>
> When it spots a set of sonames that look like good candidates for
> splitting out, it prints out suggested GAR lines.  Here's output from
> the analysis of CSWnspr:

This looks very useful.

> * Package CSWnspr contains shared libraries with sonames that don't  
> have
>   compatible versions: ['libnspr4.so', 'libplc4.so',  
> 'libplds4.so'].  This
>   means that they are best placed in own packages, with each package  
> named
>   after library name and version.
>
> # Checkpkg suggests adding the following lines to the GAR recipe:
> # This is a summary; see above for details.
> # Suggesting how to separate out libnspr4.so
> # You will most probably need to further edit these lines. Use with  
> caution!
> PACKAGES += CSWlibnspr4
> CATALOGNAME_CSWlibnspr4 += libnspr4

Would it be much hassle to skip the '+'? There is no usecase for  
having multiple
catalog names.

> PKGFILES_CSWlibnspr4 += /opt/csw/lib/libnspr4.so

Shouldn't this belong to the current CSWnspr? This is the symlink to the
most current one, right?

> PKGFILES_CSWlibnspr4 += /opt/csw/lib/libnspr4.so\.[0-9\.]+
> RUNTIME_DEP_PKGS_CSWnspr += CSWlibnspr4
>
> Out of the two lines with libnspr4.so, the first one is based on the
> file name, and the latter is based on soname plus a version matching
> regex.  It also suggests adding a dependency, to preserve the required
> chain of dependencies if this is a modification of an already released
> package.
>
> As noted, this is to be used with caution; its purpose is to make it
> easier to work with GAR builds, while still thinking about which lines
> we put into the Makefiles and why.


Best regards

   -- Dago


From phil at bolthole.com  Thu Oct 14 22:06:04 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 14 Oct 2010 13:06:04 -0700
Subject: [csw-maintainers] GAR: Checks for shared library names
In-Reply-To: <AANLkTinX-9i_-WQA--682JukWpm=QX0cNcwg0+nE-jPy@mail.gmail.com>
References: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
	<AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>
	<AANLkTimD71W_+pu8+2AtyPukMNKs45TtSiY=wGJ0srKg@mail.gmail.com>
	<AANLkTinX-9i_-WQA--682JukWpm=QX0cNcwg0+nE-jPy@mail.gmail.com>
Message-ID: <AANLkTim_yq+c=vWj_4u5toZGL1O4Ub-OOKyN+dvf2OYi@mail.gmail.com>

On 10/14/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> I've just pushed a new change to checkpkg:
>
> When it spots a set of sonames that look like good candidates for
> splitting out, it prints out suggested GAR lines.  Here's output from
> the analysis of CSWnspr:
>
>
>  * Package CSWnspr contains shared libraries with sonames that don't have
>    compatible versions: ['libnspr4.so', 'libplc4.so', 'libplds4.so'].  This
>    means that they are best placed in own packages, with each package named
>    after library name and version.
>

Hmm.

I think it would be good if you were a little more descriptive about
the non "compatibility".
A little more detail, such as, "different numbering systems"?

Otherwise, the script looks a whole lot smarter than it really is.
After all, how would it "know" if the versions are "compatible" or
not? It sounds like a code analyser, which it is not.

From phil at bolthole.com  Thu Oct 14 22:32:24 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 14 Oct 2010 13:32:24 -0700
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
	<1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
	<AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>
	<6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>
Message-ID: <AANLkTimV1vnQwa1BzuuAzRkE=_hirZEGNKhTxkNhTx+C@mail.gmail.com>

On 10/13/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> Just as a note: Perl is not much different here and we choose to not
> have
> a version in all modules. However, that required us to atomically
> rebuild
> all modules.

I dont think that is accurate.

When we did MAJOR perl upgrades, it required rebuilding everything.
However, we went through quite a through minor version upgrades, and
there was no problem.
(conclusion: perl 5.10 sux :-P  )

From phil at bolthole.com  Thu Oct 14 22:40:50 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 14 Oct 2010 13:40:50 -0700
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTikac5GeE=rTycLvKvmj5Ky25qnx+OGnMXi+sNi4@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
	<1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
	<AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>
	<6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>
	<AANLkTikac5GeE=rTycLvKvmj5Ky25qnx+OGnMXi+sNi4@mail.gmail.com>
Message-ID: <AANLkTimQBuxvJY_nAqx0AKYwNGi+hYcWJU5G7j9LDNnF@mail.gmail.com>

On 10/14/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> ...
> If I have to choose between being consistent with how Perl is packaged
> and how Python is packaged, I'd go with the latter.  I don't see any
> real benefits for choosing the "one Python" strategy.  At the same
> time, I see serious downsides.  For example, if you write any serious
> Python code, you write it for a specific version, and you lock it down
> to that Python version.  You might migrate it later on to a newer
> version, but migration is a separate process.  You quite often need
> Python 2.4 to run some scripts, and Python 2.6 to run others.

That's..... kinda lame.
if python was some small runtime library thingie like berkeleydb, I
would just say okay fine. but python is a major set of packages.

As a comparison... not that sun always does things right, but solaris
10, 2010 ships with one and only one version of python.
(but a very old one. hrm.)

I think that, similar to ruby, we might be best served with a
"primary" version of python, and then some "if you really need it"
versions.
primary version gets /opt/csw/lib/python or whatever.

It should be pointed out that python, being interpreted, is different
from the way we handle shared libraries.  There can be only one
/opt/csw/bin/python. So in some ways, this is the most consistent
thing to do.
If we change /opt/csw/bin/python major version, then we SHOULD have to
recompile everything, methinks.

Does that make sense?

I'll also mention, that if we keep most things in /opt/csw/lib/python,
then a new version of /opt/csw/bin/python, can and should
automatically recompile everthing present there.
(that's the benefit of the unified no-number directory)
So for anything written portably, a version upgrade could be quite transparent.

From bonivart at opencsw.org  Thu Oct 14 22:55:41 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 14 Oct 2010 22:55:41 +0200
Subject: [csw-maintainers] Automatically excluding .pyc files
In-Reply-To: <AANLkTimV1vnQwa1BzuuAzRkE=_hirZEGNKhTxkNhTx+C@mail.gmail.com>
References: <AANLkTinA-6wWXE5JJGk5MC7S-Ehx7dz7EdKwGs8rKMvr@mail.gmail.com>
	<1286986254-sup-8729@pinkfloyd.chass.utoronto.ca>
	<AANLkTim6aUeo+79GSiMHTKLDohLQyto_R4uaJ6=Ds3iE@mail.gmail.com>
	<AANLkTim4stH637qAjB68HEWzSFS35n-FHoJDGZ==K3nS@mail.gmail.com>
	<1287022373-sup-1719@pinkfloyd.chass.utoronto.ca>
	<AANLkTiknfy_T6+Cgki-KCh0Kq23B8gidw6Po5PpXXbH+@mail.gmail.com>
	<6AF6837B-C806-46EA-97A3-ED9AAEA5F1BB@opencsw.org>
	<AANLkTimV1vnQwa1BzuuAzRkE=_hirZEGNKhTxkNhTx+C@mail.gmail.com>
Message-ID: <AANLkTi=Ox=8ZH1SNLjEyHaP=4ioOru2zaswe8zDARJfG@mail.gmail.com>

On Thu, Oct 14, 2010 at 10:32 PM, Philip Brown <phil at bolthole.com> wrote:
> When we did MAJOR perl upgrades, it required rebuilding everything.

Less than 100 of our more than 400 modules contain binaries and
therefore needed to be recompiled.

/peter

From maciej at opencsw.org  Fri Oct 15 00:56:01 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 14 Oct 2010 23:56:01 +0100
Subject: [csw-maintainers] GAR: Checks for shared library names
In-Reply-To: <5575B096-36CE-4017-B610-72BCAA27F58D@opencsw.org>
References: <AANLkTik4sj3RfyodhLGs0x-UuOwp0sEBhvksxCOeX15n@mail.gmail.com>
	<AANLkTikxzE+aKQfPV5kp=GxvPMqJGtVpABO-S28cb_fJ@mail.gmail.com>
	<AANLkTimD71W_+pu8+2AtyPukMNKs45TtSiY=wGJ0srKg@mail.gmail.com>
	<AANLkTinX-9i_-WQA--682JukWpm=QX0cNcwg0+nE-jPy@mail.gmail.com>
	<5575B096-36CE-4017-B610-72BCAA27F58D@opencsw.org>
Message-ID: <AANLkTikJ_LFY7Hp1otL5W2OzcCTawmi_WY7cx9W+HctB@mail.gmail.com>

No dia 14 de Outubro de 2010 20:12, Dagobert Michelsen
<dam at opencsw.org> escreveu:
>> PACKAGES += CSWlibnspr4
>> CATALOGNAME_CSWlibnspr4 += libnspr4
>
> Would it be much hassle to skip the '+'? There is no usecase for having
> multiple
> catalog names.

Done.

>> PKGFILES_CSWlibnspr4 += /opt/csw/lib/libnspr4.so
>
> Shouldn't this belong to the current CSWnspr? This is the symlink to the
> most current one, right?

A very, very long time ago the NSPR/NSS guys decided that they will
embed the indication of API version in the library name, rather than
in the soname version.  They can't get out of it now, so they're stuck
with the actual library name being "libnspr4.so".  Consequently,
libnspr4.so is not a symlink, but the file with actual data.  From my
conversation with one of the developers, if they could change it, they
would.  But it's hard enough so that they don't.  If they every change
the API, they'll create a new library.  I hope it'll be libnspr.so.5,
and not libnspr5.so.

From phil at bolthole.com  Fri Oct 15 01:30:25 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 14 Oct 2010 16:30:25 -0700
Subject: [csw-maintainers] python packages sticking up the queue
Message-ID: <AANLkTi=xrWU_ASn91q9V4pt+X-YnvyVd=oB_g-L+rb8D@mail.gmail.com>

btw: I've "released" the newer python packages it seems... but I dont
feel comfortable releasing any new python packages that depend on this
new stuff, until after some further discussion on the "pyc" thread. I
dont want us to go too far down that road yet, if people decide in a
day or two that it was a mistake.

Everyone with an interest in python, please take a read of that thread
and give your input.

From maciej at opencsw.org  Fri Oct 15 02:00:08 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 15 Oct 2010 01:00:08 +0100
Subject: [csw-maintainers] Support for multiple Python versions
Message-ID: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>

I'm forking the conversation to a new thread.

No dia 14 de Outubro de 2010 21:40, Philip Brown <phil at bolthole.com> escreveu:
> On 10/14/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> ...
>> If I have to choose between being consistent with how Perl is packaged
>> and how Python is packaged, I'd go with the latter. ?I don't see any
>> real benefits for choosing the "one Python" strategy. ?At the same
>> time, I see serious downsides. ?For example, if you write any serious
>> Python code, you write it for a specific version, and you lock it down
>> to that Python version. ?You might migrate it later on to a newer
>> version, but migration is a separate process. ?You quite often need
>> Python 2.4 to run some scripts, and Python 2.6 to run others.
>
> That's..... kinda lame.
> if python was some small runtime library thingie like berkeleydb, I
> would just say okay fine. but python is a major set of packages.
>
> As a comparison... not that sun always does things right, but solaris
> 10, 2010 ships with one and only one version of python.
> (but a very old one. hrm.)

Hard to upgrade by replacing.  Would be easier with an overlap:
introduce the new one, build modules for it, then retire the old one
when the time comes.

> I think that, similar to ruby, we might be best served with a
> "primary" version of python, and then some "if you really need it"
> versions.
> primary version gets /opt/csw/lib/python or whatever.

Sure, that's not a problem.  It can be also driven by alternatives so
users have the choice.

> It should be pointed out that python, being interpreted, is different
> from the way we handle shared libraries. ?There can be only one
> /opt/csw/bin/python. So in some ways, this is the most consistent
> thing to do.
> If we change /opt/csw/bin/python major version, then we SHOULD have to
> recompile everything, methinks.
>
> Does that make sense?

Partly yes - if we introduce a new version of Python, we need to build
all the modules for it.  In certain cases, it's necessary to pick
matching module versions, e.g. module foo in version 1.0 might be
compatible with Python 2.4 to 2.7, while module foo in version 2.0
might be compatible with Python 2.6 to 3.1.  In any case, each Python
version gets its own set of modules, and we need to build them.

However, this does not necessarily mean that we need to remove modules
for the old version of Python and its modules.  We can have
py26_twisted built for Python 2.6 and py27_twisted built for Python
2.7, happily living together in one file system.

> I'll also mention, that if we keep most things in /opt/csw/lib/python,
> then a new version of /opt/csw/bin/python, can and should
> automatically recompile everthing present there.
> (that's the benefit of the unified no-number directory)
> So for anything written portably, a version upgrade could be quite transparent.

The argument here is that you can keep old modules and use them for
the newer version of Python.  While it is potentially possible, not
all modules or programs will work well with a newer version.  Usually,
after a new version is released, other projects are catching up to
stamp out any compatibility issues.  We might get away with leaving
2.6 modules and using them for 2.7, but not with 3.1.

In the meantime, I've built Python 3.1 to try it out.  It passed the
smoke test: can be installed alongside Python 2.6, with both 2.6 and
3.1 versions working fine.

If anyone is interested in testing and/or reviewing, here are the packages:
http://buildfarm.opencsw.org/experimental.html#python-3.1

Maciej

From maciej at opencsw.org  Fri Oct 15 02:03:33 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 15 Oct 2010 01:03:33 +0100
Subject: [csw-maintainers] python packages sticking up the queue
In-Reply-To: <AANLkTi=xrWU_ASn91q9V4pt+X-YnvyVd=oB_g-L+rb8D@mail.gmail.com>
References: <AANLkTi=xrWU_ASn91q9V4pt+X-YnvyVd=oB_g-L+rb8D@mail.gmail.com>
Message-ID: <AANLkTi==aPRZgUMiEtrQn96pqyWsnEB5of_xu=h4amBm@mail.gmail.com>

No dia 15 de Outubro de 2010 00:30, Philip Brown <phil at bolthole.com> escreveu:
> btw: I've "released" the newer python packages it seems... but I dont
> feel comfortable releasing any new python packages that depend on this
> new stuff, until after some further discussion on the "pyc" thread. I
> dont want us to go too far down that road yet, if people decide in a
> day or two that it was a mistake.
>
> Everyone with an interest in python, please take a read of that thread
> and give your input.

By new stuff, do you mean the libraries?  The recent Python update
didn't change any paths, it only separated out the shared libraries
into their own packages.  The topic of supporting multiple Python
versions will become relevant when we start shipping Python 2.7 and/or
3.1.

From bwalton at opencsw.org  Fri Oct 15 03:25:30 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 14 Oct 2010 21:25:30 -0400
Subject: [csw-maintainers] Support for multiple Python versions
In-Reply-To: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
Message-ID: <1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 14 20:00:08 -0400 2010:

> Hard to upgrade by replacing.  Would be easier with an overlap:
> introduce the new one, build modules for it, then retire the old one
> when the time comes.

Lets look at the Debian Python Policy.  It seems pretty sound and I'd
put it forward as a good (proven, working) model:

http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-versions

I like the wording:

"Apart from the default version, legacy versions of Python or beta
versions of future releases may be included as well in the
distribution, as long as they are needed by other packages, or as long
as it seems reasonable to provide them. (Note: For the scope of this
document, Python versions are synonymous to feature releases,
i.e. Python 2.5 and 2.5.1 are sub-minor versions of the same Python
version 2.5, but Python 2.4 and 2.5 are indeed different versions.)"

This makes sense, I think and would also fit with pushing multiple
versions of ruby.  (A separate topic.)

> > I think that, similar to ruby, we might be best served with a
> > "primary" version of python, and then some "if you really need it"
> > versions.  primary version gets /opt/csw/lib/python or whatever.
> 
> Sure, that's not a problem.  It can be also driven by alternatives
> so users have the choice.

Alternatives is the way to go with this.  Newer python versions get a
higher priority and the admin can locally change this preference.

> However, this does not necessarily mean that we need to remove
> modules for the old version of Python and its modules.  We can have
> py26_twisted built for Python 2.6 and py27_twisted built for Python
> 2.7, happily living together in one file system.

Yes.  Python modules/packages should depend on the version number
(major.minor) that they were originally packaged with.  A new python
release can be made and modules updated slowly.  This _should_ allow
for fewer surprises and more stability.

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


From phil at bolthole.com  Fri Oct 15 20:15:18 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 15 Oct 2010 11:15:18 -0700
Subject: [csw-maintainers] Support for multiple Python versions
In-Reply-To: <1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>
References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
	<1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>

On 10/14/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 14 20:00:08
> -0400 2010:
>
>> Hard to upgrade by replacing.  Would be easier with an overlap:
>> introduce the new one, build modules for it, then retire the old one
>> when the time comes.
>
> Lets look at the Debian Python Policy.  It seems pretty sound and I'd
> put it forward as a good (proven, working) model:
>
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-versions
>
> I like the wording:
>....

that is a VERY long document, and it is a front for a VERY complex system.
It is dangerous for you to just quote one small part of it.

Areas of concern: It references something most people, if not all
people, on this list,  are completely unfamiliar with:
debian "python-support" and "python-central" packages.

I suspect there is a whole special framework in that.. somewhat
similar to our current python class action script, but even more
complicated.
Do you want to research and summarize that further for us?
Or Maciej?

From phil at bolthole.com  Fri Oct 15 20:20:07 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 15 Oct 2010 11:20:07 -0700
Subject: [csw-maintainers] python packages sticking up the queue
In-Reply-To: <AANLkTi==aPRZgUMiEtrQn96pqyWsnEB5of_xu=h4amBm@mail.gmail.com>
References: <AANLkTi=xrWU_ASn91q9V4pt+X-YnvyVd=oB_g-L+rb8D@mail.gmail.com>
	<AANLkTi==aPRZgUMiEtrQn96pqyWsnEB5of_xu=h4amBm@mail.gmail.com>
Message-ID: <AANLkTi=Wiq81gGmvayRXmjDvXcubWT3157LiO61R_3eH@mail.gmail.com>

On 10/14/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>
> By new stuff, do you mean the libraries?  The recent Python update
> didn't change any paths, it only separated out the shared libraries
> into their own packages.

oh good. I thought you may have implemented the "lib/python2.6" stuff
you had mentioned.

erm... but ben apparently has.

in py_libxslt

 /opt/csw/lib/python2.6/site-packages

?

From bwalton at opencsw.org  Fri Oct 15 20:28:21 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 15 Oct 2010 14:28:21 -0400
Subject: [csw-maintainers] python packages sticking up the queue
In-Reply-To: <AANLkTi=Wiq81gGmvayRXmjDvXcubWT3157LiO61R_3eH@mail.gmail.com>
References: <AANLkTi=xrWU_ASn91q9V4pt+X-YnvyVd=oB_g-L+rb8D@mail.gmail.com>
	<AANLkTi==aPRZgUMiEtrQn96pqyWsnEB5of_xu=h4amBm@mail.gmail.com>
	<AANLkTi=Wiq81gGmvayRXmjDvXcubWT3157LiO61R_3eH@mail.gmail.com>
Message-ID: <1287167196-sup-1913@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Oct 15 14:20:07 -0400 2010:
> erm... but ben apparently has.
> 
> in py_libxslt
> 
>  /opt/csw/lib/python2.6/site-packages

No, this was the initial cause of the discussion.  When I packaged the
libxslt update, I found it stuck files there and adjusted GAR to make
it pycompile these.  The libxslt installer goes to great lengths in
the configure script to find a version specific lib path...

You can put the *xslt* packages on hold for now if you'd like, until
we've finished the python discussion.

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


From maciej at opencsw.org  Sat Oct 16 01:26:10 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sat, 16 Oct 2010 00:26:10 +0100
Subject: [csw-maintainers] Support for multiple Python versions
In-Reply-To: <AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>
References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
	<1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>
Message-ID: <AANLkTimsaEXCtymYkJQY7a18LyGtF0BH3ONtyzoprNXy@mail.gmail.com>

No dia 15 de Outubro de 2010 19:15, Philip Brown <phil at bolthole.com> escreveu:
> On 10/14/10, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 14 20:00:08
>> -0400 2010:
>>
>>> Hard to upgrade by replacing. ?Would be easier with an overlap:
>>> introduce the new one, build modules for it, then retire the old one
>>> when the time comes.
>>
>> Lets look at the Debian Python Policy. ?It seems pretty sound and I'd
>> put it forward as a good (proven, working) model:
>>
>> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-versions
>>
>> I like the wording:
>>....
>
> that is a VERY long document, and it is a front for a VERY complex system.
> It is dangerous for you to just quote one small part of it.
>
> Areas of concern: It references something most people, if not all
> people, on this list, ?are completely unfamiliar with:
> debian "python-support" and "python-central" packages.
>
> I suspect there is a whole special framework in that.. somewhat
> similar to our current python class action script, but even more
> complicated.
> Do you want to research and summarize that further for us?
> Or Maciej?

I read the descriptions of these two packages:

http://packages.debian.org/sid/python-support
http://packages.debian.org/sid/python-central

The idea seems to be to provide a special mechanism to build modules
that can be used with more than one version of Python (or any version
of Python, not sure yet).  I haven't dissected their internal
workings, but I think that it's generally a way to make the life
easier and remove the need to build and distribute each module for
each Python version.  The first, python-support provides install-time
support such as compilation to bytecode.  The other, python-central,
is a helper tool to build Python modules compatible with multiple
Python versions.

From phil at bolthole.com  Sat Oct 16 02:02:17 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 15 Oct 2010 17:02:17 -0700
Subject: [csw-maintainers] Support for multiple Python versions
In-Reply-To: <AANLkTimsaEXCtymYkJQY7a18LyGtF0BH3ONtyzoprNXy@mail.gmail.com>
References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
	<1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>
	<AANLkTimsaEXCtymYkJQY7a18LyGtF0BH3ONtyzoprNXy@mail.gmail.com>
Message-ID: <AANLkTinuOfnGnd7gmhM-+ekydFUnscfqZMFG563qX497@mail.gmail.com>

On 10/15/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>
> I read the descriptions of these two packages:
>
> http://packages.debian.org/sid/python-support
> http://packages.debian.org/sid/python-central
>
> The idea seems to be to provide a special mechanism to build modules
> that can be used with more than one version of Python (or any version
> of Python, not sure yet).  I haven't dissected their internal
> workings, but I think that it's generally a way to make the life
> easier and remove the need to build and distribute each module for
> each Python version.  The first, python-support provides install-time
> support such as compilation to bytecode.  The other, python-central,
> is a helper tool to build Python modules compatible with multiple
> Python versions.


Interesting. So sounds like their "python-support" is somewhat similar
to our cswpycompile, and python-central, is something that we could
also benefit from (and possibly our cswpycompile could use, or perhaps
not)

From bwalton at opencsw.org  Sat Oct 16 22:36:23 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 16 Oct 2010 16:36:23 -0400
Subject: [csw-maintainers] Support for multiple Python versions
In-Reply-To: <AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>
References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
	<1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>
Message-ID: <1287261216-sup-4015@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Oct 15 14:15:18 -0400 2010:

> that is a VERY long document, and it is a front for a VERY complex
> system.  It is dangerous for you to just quote one small part of it.

It is long, but since the discussion was centred around shipping (or
not) multiple versions of python, the snippet I quoted is germane and
harmless.

If we want to extend the discussion into whether or not we should have
modules get byte-compiled for multiple versions of python (if
present), then yes, I agree more context is required.

> Do you want to research and summarize that further for us?  Or
> Maciej?

Maciej has already done a brief synopsis of the tools, but I contend
that for the original discussion, these are out of scope.

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


From maciej at opencsw.org  Mon Oct 18 12:02:42 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 18 Oct 2010 11:02:42 +0100
Subject: [csw-maintainers] Support for multiple Python versions
In-Reply-To: <1287261216-sup-4015@pinkfloyd.chass.utoronto.ca>
References: <AANLkTim-f1wLdtn4zHHLCfYTkV4WNEQiL+OWS5P82jxw@mail.gmail.com>
	<1287105449-sup-1660@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=0414ANxddd0FQetn-uUNeBE+dRcF=2VJUD-DY@mail.gmail.com>
	<1287261216-sup-4015@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTi=CVnEJvKRtTtKKMR9LuZ1CUD5F_ysAxJNECmDV@mail.gmail.com>

No dia 16 de Outubro de 2010 21:36, Ben Walton <bwalton at opencsw.org> escreveu:
> Excerpts from Philip Brown's message of Fri Oct 15 14:15:18 -0400 2010:
>
>> that is a VERY long document, and it is a front for a VERY complex
>> system. ?It is dangerous for you to just quote one small part of it.
>
> It is long, but since the discussion was centred around shipping (or
> not) multiple versions of python, the snippet I quoted is germane and
> harmless.
>
> If we want to extend the discussion into whether or not we should have
> modules get byte-compiled for multiple versions of python (if
> present), then yes, I agree more context is required.
>
>> Do you want to research and summarize that further for us? ?Or
>> Maciej?
>
> Maciej has already done a brief synopsis of the tools, but I contend
> that for the original discussion, these are out of scope.

Yes, it's true.  These two are additional, time saving tools, it's a
conversation can have after we know will support multiple Python
versions.  If we are still at the stage of deciding whether we are
going to support multiple Python versions, we can leave this
discussion for later.

By the way, has anyone tried the new Python 3.1 packages yet?

http://bit.ly/cCF6ze

From dam at opencsw.org  Mon Oct 18 15:01:24 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 18 Oct 2010 15:01:24 +0200
Subject: [csw-maintainers] Perl module Compress::Raw:Zlib
Message-ID: <ED15682C-D236-4E0F-A65C-60159427D127@opencsw.org>

Hi Peter,

one more issue about the Perl modules: I tried updating pm_iocompress
which needs pm_compressrawzlib 2.030. Although CSWpmcompressrawzlib is
installed the "perl Makefile.PL" bails out. Look at the installed files:

> current9s% grep Compress/Raw /var/sadm/install/contents
> /opt/csw/lib/perl/5.10.1/Compress/Raw d none 0755 root bin CSWperl
> /opt/csw/lib/perl/5.10.1/Compress/Raw/Bzip2.pm f none 0444 root bin  
> 10079 63743 1281517873 CSWperl
> /opt/csw/lib/perl/5.10.1/Compress/Raw/Zlib.pm f none 0444 root bin  
> 42467 27447 1281517873 CSWperl
> ...
> /opt/csw/lib/perl/csw/Compress/Raw d none 0755 root bin  
> CSWpmcompressrawzlib CSWpmcompressrawbz2
> /opt/csw/lib/perl/csw/Compress/Raw/Bzip2.pm f none 0444 root bin  
> 10252 12884 1285096397 CSWpmcompressrawbz2
> /opt/csw/lib/perl/csw/Compress/Raw/Zlib.pm f none 0444 root bin  
> 42585 36736 1279972153 CSWpmcompressrawzlib
> ...

However, as you see from perl -V this path /opt/csw/lib/perl/5.10.1 is
preferred over /opt/csw/lib/perl/csw:

> current9s% /opt/csw/bin/perl -V
> Summary of my perl5 (revision 5 version 10 subversion 1)  
> configuration:
>   Commit id: c7506a7a9dfb58c2663eeaa29d2d48343d8d93f3
>   Platform:
>     osname=solaris, osvers=2.9, archname=sun4-solaris-thread-multi
>     uname='sunos current9s 5.9 generic_virtual sun4u sparc  
> sunw,sparc-enterprise-t5220'
>     config_args=''
>     hint=recommended, useposix=true, d_sigaction=define
>     useithreads=define, usemultiplicity=define
>     useperlio=define, d_sfio=undef, uselargefiles=define,  
> usesocks=undef
>     use64bitint=undef, use64bitall=undef, uselongdouble=undef
>     usemymalloc=n, bincompat5005=undef
>   Compiler:
>     cc='/opt/SUNWspro/bin/cc', ccflags ='-D_REENTRANT -xO3 -m32 - 
> xarch=v8 -xnorunpath -I/opt/csw/include -D_LARGEFILE_SOURCE - 
> D_FILE_OFFSET_BITS=64',
>     optimize='-xO3 -m32 -xarch=v8 -xnorunpath',
>     cppflags='-D_REENTRANT -xO3 -m32 -xarch=v8 -xnorunpath -I/opt/ 
> csw/include'
>     ccversion='Sun C 5.9 SunOS_sparc Patch 124867-15 2010/07/20',  
> gccversion='', gccosandvers=''
>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
>     d_longlong=define, longlongsize=8, d_longdbl=define,  
> longdblsize=16
>     ivtype='long', ivsize=4, nvtype='double', nvsize=8,  
> Off_t='off_t', lseeksize=8
>     alignbytes=8, prototype=define
>   Linker and Libraries:
>     ld='/opt/SUNWspro/bin/cc', ldflags ='-m32 -xarch=v8 -norunpath - 
> L/opt/csw/lib -lperl -L/opt/csw/bdb48/lib -L/opt/csw/lib -L/usr/lib - 
> L/usr/ccs/lib -L/lib'
>     libpth=/usr/lib /usr/ccs/lib /lib /opt/csw/lib
>     libs=-lsocket -lnsl -lgdbm -ldb-4.8 -ldl -lm -lpthread -lc -lperl
>     perllibs=-lsocket -lnsl -ldb-4.8 -ldl -lm -lpthread -lc -lperl
>     libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so. 
> 5.10.1
>     gnulibc_version=''
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R / 
> opt/csw/lib'
>     cccdlflags='-KPIC', lddlflags='-G -L/opt/csw/lib -L/opt/csw/ 
> bdb48/lib -L/usr/lib -L/usr/ccs/lib -L/lib'
>
>
> Characteristics of this binary (from libperl):
>   Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
>                         PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP  
> USE_ITHREADS
>                         USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
>                         USE_SITECUSTOMIZE
>   Built under solaris
>   Compiled at Aug 11 2010 10:53:04
>   @INC:
>     /opt/csw/lib/perl/5.10.1
>     /opt/csw/share/perl/5.10.1
>     /opt/csw/lib/perl/site_perl
>     /opt/csw/share/perl/site_perl
>     /opt/csw/share/perl/site_perl
>     /opt/csw/lib/perl/csw
>     /opt/csw/share/perl/csw
>     /opt/csw/share/perl/csw
>     .


That basically means we need to replace the module from CSWperl or  
reorder
build pathes in CSWperl somehow.


Best regards

   -- Dago



From dam at opencsw.org  Mon Oct 18 15:05:58 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 18 Oct 2010 15:05:58 +0200
Subject: [csw-maintainers] Any news on cswap2mod ?
Message-ID: <FCB3CAFD-5169-420A-986B-2F6BD3BE3B7F@opencsw.org>

Hi,

I would like to close
   https://www.opencsw.org/mantis/view.php?id=4490
Will cswap2mod be released soon?


Best regards

   -- Dago


From bwalton at opencsw.org  Mon Oct 18 15:52:34 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 18 Oct 2010 09:52:34 -0400
Subject: [csw-maintainers] Any news on cswap2mod ?
In-Reply-To: <FCB3CAFD-5169-420A-986B-2F6BD3BE3B7F@opencsw.org>
References: <FCB3CAFD-5169-420A-986B-2F6BD3BE3B7F@opencsw.org>
Message-ID: <1287409928-sup-968@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Mon Oct 18 09:05:58 -0400 2010:

Hi Dago,

> I would like to close
>    https://www.opencsw.org/mantis/view.php?id=4490
> Will cswap2mod be released soon?

I'll push the apache packages tonight.  cswap2mod is part of
CSWapache2.

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


From maciej at opencsw.org  Mon Oct 18 18:38:23 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 18 Oct 2010 17:38:23 +0100
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
Message-ID: <AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>

No dia 2 de Agosto de 2010 09:04, Dagobert Michelsen <dam at opencsw.org> escreveu:
> Other topic: documentation. Having both rdoc and ri docs is quite
> large, most of the time the documentation is much larger in size
> and much, much larger in terms of files. I tend to split it off,
> but the standard _doc and -doc suffixes together with the gem
> prefix would leave only very little space for the actual gem
> name making identification difficult. I tend to increase the
> maximum length of package and catalog names for the sake of
> consistency.

On the package name length topic, opk recently came across
libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
characters long pkgname.  Current restriction in checkpkg is 20
characters for both pkgname and catalogname.  Is it something we
intend to keep at all times, or is it OK to exceed this default in
cases such as this long soname?

From phil at bolthole.com  Mon Oct 18 18:46:33 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 18 Oct 2010 09:46:33 -0700
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
Message-ID: <AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>

On 10/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>
> On the package name length topic, opk recently came across
> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
> characters long pkgname.  Current restriction in checkpkg is 20
> characters for both pkgname and catalogname.  Is it something we
> intend to keep at all times, or is it OK to exceed this default in
> cases such as this long soname?a

Reguarding "at all times"... either something is a limit, or it isnt.
We've gone over this before, multiple times, since the start of CSW.
There needs to be "a limit", it's insane for it to be unlimited.
Whatever we pick as a limit, some things are going to hit it, and will
need to get tweaked.
It doesnt make sense to go upping the limit every time something hits it.
20 chars is the limit for multiple reasons. Some of them include:
- preserving meaningful display on pkginfo
- preserving meaningful display on terminal output
- preserving meaningful display on weekly summaries.

Remember, our version string is now extra long too, so software name
and package name need to be kept short to compensate for that.

From maciej at opencsw.org  Mon Oct 18 19:01:53 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 18 Oct 2010 18:01:53 +0100
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
Message-ID: <AANLkTinGhVN1yMyL5Tgyx9bq15vfdRG-0gDMu1pT4ZSR@mail.gmail.com>

No dia 18 de Outubro de 2010 17:46, Philip Brown <phil at bolthole.com> escreveu:
> On 10/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>>
>> On the package name length topic, opk recently came across
>> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
>> characters long pkgname. ?Current restriction in checkpkg is 20
>> characters for both pkgname and catalogname. ?Is it something we
>> intend to keep at all times, or is it OK to exceed this default in
>> cases such as this long soname?a
>
> Reguarding "at all times"... either something is a limit, or it isnt.
> We've gone over this before, multiple times, since the start of CSW.
> There needs to be "a limit", it's insane for it to be unlimited.

True, there's also the actual technological limit, which is 256 or 255
characters, if I'm not mistaken.  We have our own limit for other
reasons.

> Whatever we pick as a limit, some things are going to hit it, and will
> need to get tweaked.
> It doesnt make sense to go upping the limit every time something hits it.
> 20 chars is the limit for multiple reasons. Some of them include:
> - preserving meaningful display on pkginfo
> - preserving meaningful display on terminal output
> - preserving meaningful display on weekly summaries.

Fair enough.

I'll have to improve checkpkg so that it doesn't first suggest a
package name and then complain that it's too long.  But I don't have
an implementation of a package name shortener.  Does anyone, so I
don't have to reinvent the wheel?

From dam at opencsw.org  Mon Oct 18 19:50:49 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 18 Oct 2010 19:50:49 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
Message-ID: <24FA53ED-53EB-4264-83ED-B896228FE9BD@opencsw.org>

Hi Phil,

Am 18.10.2010 um 18:46 schrieb Philip Brown:
> On 10/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>>
>> On the package name length topic, opk recently came across
>> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a  
>> 24
>> characters long pkgname.  Current restriction in checkpkg is 20
>> characters for both pkgname and catalogname.  Is it something we
>> intend to keep at all times, or is it OK to exceed this default in
>> cases such as this long soname?a
>
> Reguarding "at all times"... either something is a limit, or it isnt.
> We've gone over this before, multiple times, since the start of CSW.
> There needs to be "a limit", it's insane for it to be unlimited.
> Whatever we pick as a limit, some things are going to hit it, and will
> need to get tweaked.
> It doesnt make sense to go upping the limit every time something  
> hits it.
> 20 chars is the limit for multiple reasons. Some of them include:
> - preserving meaningful display on pkginfo

Nope, pkginfo calculates this dynamically in Solaris 10:
   http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/svr4pkg/pkginfo/pkginfo.c
Solaris 9 works the same, I just checked (and even Solaris 8, btw.)

> - preserving meaningful display on terminal output
> - preserving meaningful display on weekly summaries.

In times of RSS the weekly summary should be no argument against
making the package name longer.

> Remember, our version string is now extra long too, so software name
> and package name need to be kept short to compensate for that.

This doesn't help on packaging e.g. Perl modules. Having
catalogname != CPAN upstream name is a *real* burden, IMHO
much larger than having a couple of long lines.


Best regards

   -- Dago


From phil at bolthole.com  Mon Oct 18 20:54:06 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 18 Oct 2010 11:54:06 -0700
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <24FA53ED-53EB-4264-83ED-B896228FE9BD@opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
	<24FA53ED-53EB-4264-83ED-B896228FE9BD@opencsw.org>
Message-ID: <AANLkTikCeMUzf05m1z7p7JOTaQYgq2a80bzzE7pC7A0h@mail.gmail.com>

On 10/18/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>
>> Remember, our version string is now extra long too, so software name
>> and package name need to be kept short to compensate for that.
>
> This doesn't help on packaging e.g. Perl modules. Having
> catalogname != CPAN upstream name is a *real* burden, IMHO
> much larger than having a couple of long lines.


but you already "fixed" this, by agreeing that the description field
(and possibly also some other field I forget) would have the official
upstream full CPAN name.

From dam at opencsw.org  Mon Oct 18 21:07:19 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 18 Oct 2010 21:07:19 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTikCeMUzf05m1z7p7JOTaQYgq2a80bzzE7pC7A0h@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
	<24FA53ED-53EB-4264-83ED-B896228FE9BD@opencsw.org>
	<AANLkTikCeMUzf05m1z7p7JOTaQYgq2a80bzzE7pC7A0h@mail.gmail.com>
Message-ID: <8923987C-7D63-478E-B91B-ADFBF362CDE3@opencsw.org>

Hi Phil,

Am 18.10.2010 um 20:54 schrieb Philip Brown:
> On 10/18/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>>
>>> Remember, our version string is now extra long too, so software name
>>> and package name need to be kept short to compensate for that.
>>
>> This doesn't help on packaging e.g. Perl modules. Having
>> catalogname != CPAN upstream name is a *real* burden, IMHO
>> much larger than having a couple of long lines.
>
> but you already "fixed" this, by agreeing that the description field
> (and possibly also some other field I forget) would have the official
> upstream full CPAN name.

Nope, this is for the admin to find the module. What I am talking
about is fully automated package- and dependency generation.
Restricting the package length to this small limit makes a
database (or list) of CPAN modules vs. package names necesessary
which could otherwise just be calculated from the CPAN name.


Best regards

   -- Dago


From bwalton at opencsw.org  Tue Oct 19 03:12:17 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 18 Oct 2010 21:12:17 -0400
Subject: [csw-maintainers] Any news on cswap2mod ?
In-Reply-To: <FCB3CAFD-5169-420A-986B-2F6BD3BE3B7F@opencsw.org>
References: <FCB3CAFD-5169-420A-986B-2F6BD3BE3B7F@opencsw.org>
Message-ID: <1287450723-sup-8711@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Mon Oct 18 09:05:58 -0400 2010:

> Will cswap2mod be released soon?

Pushed to Phil.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Tue Oct 19 10:35:26 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 19 Oct 2010 09:35:26 +0100
Subject: [csw-maintainers] [gfile 0004578]: man page not formatted
	correctly
In-Reply-To: <c77bd99eab89dfb541c724d4f59451bc@www.opencsw.org>
References: <c77bd99eab89dfb541c724d4f59451bc@www.opencsw.org>
Message-ID: <AANLkTinW+FvOn+8+N+_nNqwaybtYU7Z_xaoeAZhxoGwi@mail.gmail.com>

Hey maintainers,

Here's a bug that was recently filed against gfile:

No dia 19 de Outubro de 2010 02:37, Mantis Bug Tracker
<noreply at opencsw.org> escreveu:
>
> The following issue has been SUBMITTED.
> ======================================================================
> https://www.opencsw.org/mantis/view.php?id=4578
(...)
> ======================================================================
> Project: ? ? ? ? ? ? ? ? ? ?gfile
(...)
> ======================================================================
> Summary: ? ? ? ? ? ? ? ? ? ?man page not formatted correctly
> Description:
> man gfile
> shows a scrambled man page
> ======================================================================

In this case, "scrambled" means lost formatting: the whole manpage is
a monolithic, rectangular block of text.  Here's an example:

http://paste.pocoo.org/show/277304/

Is it a known problem with man pages?  Are there any solutions or workarounds?

From dam at opencsw.org  Tue Oct 19 10:52:07 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 19 Oct 2010 10:52:07 +0200
Subject: [csw-maintainers] [gfile 0004578]: man page not formatted
	correctly
In-Reply-To: <AANLkTinW+FvOn+8+N+_nNqwaybtYU7Z_xaoeAZhxoGwi@mail.gmail.com>
References: <c77bd99eab89dfb541c724d4f59451bc@www.opencsw.org>
	<AANLkTinW+FvOn+8+N+_nNqwaybtYU7Z_xaoeAZhxoGwi@mail.gmail.com>
Message-ID: <32089025-9F27-47AF-A6FE-5C67729FA596@opencsw.org>

Hi Maciej,

Am 19.10.2010 um 10:35 schrieb Maciej (Matchek) Blizinski:
> Here's a bug that was recently filed against gfile:
>
> No dia 19 de Outubro de 2010 02:37, Mantis Bug Tracker
> <noreply at opencsw.org> escreveu:
>>
>> The following issue has been SUBMITTED.
>> =
>> =====================================================================
>> https://www.opencsw.org/mantis/view.php?id=4578
> (...)
>> =
>> =====================================================================
>> Project:                    gfile
> (...)
>> =
>> =====================================================================
>> Summary:                    man page not formatted correctly
>> Description:
>> man gfile
>> shows a scrambled man page
>> =
>> =====================================================================
>
> In this case, "scrambled" means lost formatting: the whole manpage is
> a monolithic, rectangular block of text.  Here's an example:
>
> http://paste.pocoo.org/show/277304/
>
> Is it a known problem with man pages?  Are there any solutions or  
> workarounds?

There are macros in there incompatible with the Solaris nroff
implementation. It happens from time to time:
   https://www.opencsw.org/mantis/view.php?id=1055
Try
   gnroff -man <manpage>
and shipping the page in catX/ for the easiest solution or read and
understand how nroff macros are programmed (recommended by James :-)
and fix the manpage (IIRC pretty hard...)
   http://oreilly.com/openbook/utp/

I vaguely remember we talked about the malformed manpage when I
built GNU file initially but hesitated to release it for this
reason and you did say that you resolved the issue, but I can't
find the discussion ATM... Maybe on IRC?


Best regards

   -- Dago



From maciej at opencsw.org  Tue Oct 19 11:05:28 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 19 Oct 2010 10:05:28 +0100
Subject: [csw-maintainers] The minimal version of gnupg
Message-ID: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>

Working through GPG related packages Dago and I have stumbled upon a
minimal version of GPG series 1.x:

http://www.opencsw.org/packages/gnupg_minimal/

I'm personally unaware of any scenario under which keeping gnupg is a
necessity.  Is anyone on the mailing list aware of any scenario under
which the minimal version of GPG is necessary?  If not, I'd be
inclined to remove this package from the catalog to reduce maintenance
load.

Maciej

From opk at opencsw.org  Tue Oct 19 11:35:18 2010
From: opk at opencsw.org (Oliver Kiddle)
Date: Tue, 19 Oct 2010 11:35:18 +0200 (CEST)
Subject: [csw-maintainers] skencil package
Message-ID: <20101019093518.1935F83B@mail.opencsw.org>

Sorry for the cross-post.

Is anyone still using the skencil package? Anyone mind if it simply
gets deleted?

It is unmaintained upstream in over 4 years, isn't even packaged by Debian
and the only functionality in our current package archive (without my
updated _gtk.so) appears to be printing the following:

ImportError: ld.so.1: python: fatal: relocation error: file /opt/csw/lib/python/site-packages/gtk-2.0/gtk/_gtk.so: symbol PyUnicodeUCS2_DecodeUTF8: referenced symbol not found

I have contacted the current maintainer (Murray Jensen) and he said:
"No worries - I don't use skencil and am happy to see it deleted."

The reason I'd like to have it deleted is that I'm hoping to rename some
of the packages it depends on to fit in with our conventions for python
modules.

Thanks

Oliver

From pfelecan at opencsw.org  Tue Oct 19 11:30:43 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 19 Oct 2010 11:30:43 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
	(Philip Brown's message of "Mon, 18 Oct 2010 09:46:33 -0700")
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTi=WMyrmorWMwa=eH0h1ioR7w9QVNTrrqEpSZVHK@mail.gmail.com>
Message-ID: <x6k4lea5rw.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> On 10/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>>
>> On the package name length topic, opk recently came across
>> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
>> characters long pkgname.  Current restriction in checkpkg is 20
>> characters for both pkgname and catalogname.  Is it something we
>> intend to keep at all times, or is it OK to exceed this default in
>> cases such as this long soname?a
>
> Reguarding "at all times"... either something is a limit, or it isnt.
> We've gone over this before, multiple times, since the start of CSW.
> There needs to be "a limit", it's insane for it to be unlimited.
> Whatever we pick as a limit, some things are going to hit it, and will
> need to get tweaked.
> It doesnt make sense to go upping the limit every time something hits it.
> 20 chars is the limit for multiple reasons. Some of them include:
> - preserving meaningful display on pkginfo
> - preserving meaningful display on terminal output
> - preserving meaningful display on weekly summaries.

C'mon, you cannot be serious. We are entering the second decade of the
21st century... The limit that you arbitrarily impose is 10% of the real
limit. BTW, at the august technical summit we decided that this must
change to reflect the real world. As an example, this impose changing
Perl modules names to unrecognizable viz. upstream.
-- 
Peter

From skayser at opencsw.org  Tue Oct 19 13:38:45 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Tue, 19 Oct 2010 13:38:45 +0200
Subject: [csw-maintainers] [gfile 0004578]: man page not formatted
	correctly
In-Reply-To: <32089025-9F27-47AF-A6FE-5C67729FA596@opencsw.org>
References: <c77bd99eab89dfb541c724d4f59451bc@www.opencsw.org>
	<AANLkTinW+FvOn+8+N+_nNqwaybtYU7Z_xaoeAZhxoGwi@mail.gmail.com>
	<32089025-9F27-47AF-A6FE-5C67729FA596@opencsw.org>
Message-ID: <20101019113845.GA26414@sebastiankayser.de>

* Dagobert Michelsen <dam at opencsw.org> wrote:
> Am 19.10.2010 um 10:35 schrieb Maciej (Matchek) Blizinski:
> >Here's a bug that was recently filed against gfile:
> >
> >No dia 19 de Outubro de 2010 02:37, Mantis Bug Tracker
> ><noreply at opencsw.org> escreveu:
> >>
> >>The following issue has been SUBMITTED.
> >>=
> >>=====================================================================
> >>https://www.opencsw.org/mantis/view.php?id=4578
> >(...)
> >>=
> >>=====================================================================
> >>Project:                    gfile
> >(...)
> >>=
> >>=====================================================================
> >>Summary:                    man page not formatted correctly
> >>Description:
> >>man gfile
> >>shows a scrambled man page
> >>=
> >>=====================================================================
> >
> >In this case, "scrambled" means lost formatting: the whole manpage is
> >a monolithic, rectangular block of text.  Here's an example:
> >
> >http://paste.pocoo.org/show/277304/
> >
> >Is it a known problem with man pages?  Are there any solutions or  
> >workarounds?
> 
> There are macros in there incompatible with the Solaris nroff
> implementation. It happens from time to time:
>   https://www.opencsw.org/mantis/view.php?id=1055
> Try
>   gnroff -man <manpage>
> and shipping the page in catX/ for the easiest solution or read and
> understand how nroff macros are programmed (recommended by James :-)
> and fix the manpage (IIRC pretty hard...)
>   http://oreilly.com/openbook/utp/
> 
> I vaguely remember we talked about the malformed manpage when I
> built GNU file initially but hesitated to release it for this
> reason and you did say that you resolved the issue, but I can't
> find the discussion ATM... Maybe on IRC?

There's some more information on possible man page hickups in

  https://www.opencsw.org/mantis/view.php?id=4280

Sebastian

From skayser at opencsw.org  Tue Oct 19 13:46:35 2010
From: skayser at opencsw.org (Sebastian Kayser)
Date: Tue, 19 Oct 2010 13:46:35 +0200
Subject: [csw-maintainers] [gfile 0004578]: man page not formatted
	correctly
In-Reply-To: <20101019113845.GA26414@sebastiankayser.de>
References: <c77bd99eab89dfb541c724d4f59451bc@www.opencsw.org>
	<AANLkTinW+FvOn+8+N+_nNqwaybtYU7Z_xaoeAZhxoGwi@mail.gmail.com>
	<32089025-9F27-47AF-A6FE-5C67729FA596@opencsw.org>
	<20101019113845.GA26414@sebastiankayser.de>
Message-ID: <20101019114635.GB26414@sebastiankayser.de>

* Sebastian Kayser <skayser at opencsw.org> wrote:
> * Dagobert Michelsen <dam at opencsw.org> wrote:
> > Am 19.10.2010 um 10:35 schrieb Maciej (Matchek) Blizinski:
> > >Here's a bug that was recently filed against gfile:
> > >
> > >No dia 19 de Outubro de 2010 02:37, Mantis Bug Tracker
> > ><noreply at opencsw.org> escreveu:
> > >>
> > >>The following issue has been SUBMITTED.
> > >>=
> > >>=====================================================================
> > >>https://www.opencsw.org/mantis/view.php?id=4578
> > >(...)
> > >>=
> > >>=====================================================================
> > >>Project:                    gfile
> > >(...)
> > >>=
> > >>=====================================================================
> > >>Summary:                    man page not formatted correctly
> > >>Description:
> > >>man gfile
> > >>shows a scrambled man page
> > >>=
> > >>=====================================================================
> > >
> > >In this case, "scrambled" means lost formatting: the whole manpage is
> > >a monolithic, rectangular block of text.  Here's an example:
> > >
> > >http://paste.pocoo.org/show/277304/
> > >
> > >Is it a known problem with man pages?  Are there any solutions or  
> > >workarounds?
> > 
> > There are macros in there incompatible with the Solaris nroff
> > implementation. It happens from time to time:
> >   https://www.opencsw.org/mantis/view.php?id=1055
> > Try
> >   gnroff -man <manpage>
> > and shipping the page in catX/ for the easiest solution or read and
> > understand how nroff macros are programmed (recommended by James :-)
> > and fix the manpage (IIRC pretty hard...)
> >   http://oreilly.com/openbook/utp/
> > 
> > I vaguely remember we talked about the malformed manpage when I
> > built GNU file initially but hesitated to release it for this
> > reason and you did say that you resolved the issue, but I can't
> > find the discussion ATM... Maybe on IRC?
> 
> There's some more information on possible man page hickups in
> 
>   https://www.opencsw.org/mantis/view.php?id=4280

And - for the sake of completeness - here [1], guess it wouldn't hurt to
put this information on the wiki. I had the same 'unformatted block of
text' with autossh and ship a preformatted man page just like Dago
pointed out [2].

Sebastian

[1]http://lists.opencsw.org/pipermail/maintainers/2010-February/011398.html
[2]https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/autossh/trunk/Makefile

From james at opencsw.org  Tue Oct 19 13:54:45 2010
From: james at opencsw.org (James Lee)
Date: Tue, 19 Oct 2010 11:54:45 GMT
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <AANLkTinDiW5VuwHhHsboMW0P=GAweF1dN20anwMfsAT8@mail.gmail.com>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
	<20101014.9284400.3615393619@gyor.oxdrove.co.uk>
	<AANLkTinDiW5VuwHhHsboMW0P=GAweF1dN20anwMfsAT8@mail.gmail.com>
Message-ID: <20101019.11544500.4216623348@gyor.oxdrove.co.uk>

On 14/10/10, 17:27:29, Philip Brown <phil at bolthole.com> wrote regarding Re:
[csw-maintainers] cswclassutils splitting:

> >> I'm just about done with the changes to the GAR recipe will see each
> >> CAS pair of scripts be shipped in a separate package
> >
> > Please don't.  The CAS can only be installed in the global zone
> > splitting means every one has to be installed.
> >

> the general consensus of people replying, agreed that, given that we
> are accumilating more and more separate CAS scripts, it would actually
> be less aggravating to security-concious people in the long run, to
> split them up.
> This is because of the dichotomy between core, ideally stable scripts,
> vs up and coming ones.

> Lets say a site is very security concious, and only uses a handful of
> our package, and they only need one or two of the long time "core" CAS
> scripts.
> They could install the global-zone cas package once... then go through
> a bunch of zone level package upgrades without hassle, over the time
> period of a year.

Aside from the global zone pollution and micro management package issues,
it goes wrong when you add new one or the user needs one that hasn't
been installed.  With a single package it will baulk and not fail in
error.



James.

From maciej at opencsw.org  Tue Oct 19 13:58:36 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 19 Oct 2010 12:58:36 +0100
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
Message-ID: <AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>

No dia 18 de Outubro de 2010 17:38, Maciej (Matchek) Blizinski
<maciej at opencsw.org> escreveu:
> No dia 2 de Agosto de 2010 09:04, Dagobert Michelsen <dam at opencsw.org> escreveu:
>> Other topic: documentation. Having both rdoc and ri docs is quite
>> large, most of the time the documentation is much larger in size
>> and much, much larger in terms of files. I tend to split it off,
>> but the standard _doc and -doc suffixes together with the gem
>> prefix would leave only very little space for the actual gem
>> name making identification difficult. I tend to increase the
>> maximum length of package and catalog names for the sake of
>> consistency.
>
> On the package name length topic, opk recently came across
> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
> characters long pkgname.

opk made this nice histogram of soname lengths, with cumulative
percentages.  You can read it as, e.g. 20.1% of sonames are 12
characters or less.

The relation between soname lengths and package name lengths is that
libfoo.so.1 (11 chars) becomes CSWlibfoo1 (10 chars), so on average we
can expect package names be one character shorter than sonames.  The
exception is when the sonames are of the form libfoo1.so, and in this
case the pkgname length is the same.  Catalognames are 3 characters
shorter, as they don't have the CSW bit.

0 0.0%
1 0.0%
2 0.0%
3 0.0%
4 0.0%
5 0.0%
6 0.0%
7 0.0%
8 0.0%
9 0.2%
10 2.7%
11 9.9%
12 20.1%
13 29.0%
14 39.8%
15 50.5%
16 60.0%
17 66.2%
18 70.2%
19 75.9%
20 79.7%
21 84.6%
22 86.7%
23 89.8%
24 90.9%
25 92.0%
26 92.8%
27 94.3%
28 96.6%
29 97.7%
30 97.9%
31 98.3%
32 98.5%
33 99.1%
34 99.2%
35 99.6%
36 99.8%
37 99.8%
38 100.0%
39 100.0%

Looking at the histogram, 97.9% sonames are 31 characters and less, so
we can fit 98.3% of them into pkgnames with up to 30 characters.  The
current cutoff point is at 84.6%, which I think is too low, leaving
15.4% sonames out.  We could use curtations, but I'd prefer if we
didn't.  If we nevertheless did, I'd like us to have an algorithmic
way of shortening package names.

Thoughts?

From pfelecan at opencsw.org  Tue Oct 19 14:32:46 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 19 Oct 2010 14:32:46 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	(Maciej Blizinski's message of "Tue, 19 Oct 2010 12:58:36 +0100")
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
Message-ID: <x6fww29xch.fsf@opencsw.org>

"Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes:

> No dia 18 de Outubro de 2010 17:38, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> escreveu:
>> No dia 2 de Agosto de 2010 09:04, Dagobert Michelsen <dam at opencsw.org> escreveu:
>>> Other topic: documentation. Having both rdoc and ri docs is quite
>>> large, most of the time the documentation is much larger in size
>>> and much, much larger in terms of files. I tend to split it off,
>>> but the standard _doc and -doc suffixes together with the gem
>>> prefix would leave only very little space for the actual gem
>>> name making identification difficult. I tend to increase the
>>> maximum length of package and catalog names for the sake of
>>> consistency.
>>
>> On the package name length topic, opk recently came across
>> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
>> characters long pkgname.
>
> opk made this nice histogram of soname lengths, with cumulative
> percentages.  You can read it as, e.g. 20.1% of sonames are 12
> characters or less.
>
> The relation between soname lengths and package name lengths is that
> libfoo.so.1 (11 chars) becomes CSWlibfoo1 (10 chars), so on average we
> can expect package names be one character shorter than sonames.  The
> exception is when the sonames are of the form libfoo1.so, and in this
> case the pkgname length is the same.  Catalognames are 3 characters
> shorter, as they don't have the CSW bit.
> [...]
> Looking at the histogram, 97.9% sonames are 31 characters and less, so
> we can fit 98.3% of them into pkgnames with up to 30 characters.  The
> current cutoff point is at 84.6%, which I think is too low, leaving
> 15.4% sonames out.  We could use curtations, but I'd prefer if we
> didn't.  If we nevertheless did, I'd like us to have an algorithmic
> way of shortening package names.
>
> Thoughts?

>From my point of view, the issue with this statistics is that they take
into account what already exist and not what is needed in the future. If
you work on Debian packages names you'll obtain quite different results.

Let the package names be as long as the underlying packaging system
allows.
-- 
Peter

From dam at opencsw.org  Tue Oct 19 14:54:53 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 19 Oct 2010 14:54:53 +0200
Subject: [csw-maintainers] Revisiting the GCC4 Undefined symbol
	__sync_fetch_and_add_4 nonsense
In-Reply-To: <AANLkTikOzz-wVoujBBopMOSd9cPL8Rr=dDnvDSOAOc2x@mail.gmail.com>
References: <4C8A634E.8030803@opencsw.org>
	<AANLkTimnU_tP+G6xC7TRAZ6PkZ2fhjZ7c_m4z-16X5-w@mail.gmail.com>
	<B98ABBE3-3FC9-417C-ADEE-0ED94E466395@opencsw.org>
	<AANLkTikOzz-wVoujBBopMOSd9cPL8Rr=dDnvDSOAOc2x@mail.gmail.com>
Message-ID: <4AAFB443-96DC-4C89-9D02-C601C9B5522E@opencsw.org>

Hi,


Am 13.10.2010 um 14:42 schrieb Maciej (Matchek) Blizinski:
> No dia 13 de Outubro de 2010 13:33, Dagobert Michelsen
> <dam at opencsw.org> escreveu:
>>>> Roger mentioned that he tweaked the compiler options for GCC4 from
>>>> -mcpu=v8
>>>> to -m32. I tried this but checkpackage whined that all of my  
>>>> binaries and
>>>> libraries were compiled for v8+ instead of v8 and wanted them in
>>>> arch-specific sub directories.
>>>
>>> Is a hardware instruction present in sparcv8+, and not in sparcv8?
>>> Does anyone know?
>>
>> BTW, I am having this same exact error on libtag_gcc now :-(
>
> Is the sparcv8 support worth the trouble?

I finally found the issue: this can happen if you define any  
optimization
level > 0. Skipping -O* or using -O0 works and the problem is gone. I
tried to find the specific flag combination triggering the issue but
failed to do so. The current progress is documented at
   http://wiki.opencsw.org/porting-faq#toc5
However, it should be sufficient to continue with the stopped
packaged with this workaround.


Best regards

   -- Dago



From phil at bolthole.com  Tue Oct 19 18:01:34 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 19 Oct 2010 09:01:34 -0700
Subject: [csw-maintainers] cswclassutils splitting
In-Reply-To: <20101019.11544500.4216623348@gyor.oxdrove.co.uk>
References: <1286844623-sup-1368@pinkfloyd.chass.utoronto.ca>
	<20101014.9284400.3615393619@gyor.oxdrove.co.uk>
	<AANLkTinDiW5VuwHhHsboMW0P=GAweF1dN20anwMfsAT8@mail.gmail.com>
	<20101019.11544500.4216623348@gyor.oxdrove.co.uk>
Message-ID: <AANLkTingPgu9EseF_YkfCNU+Tp1riAPk8f9nCNSZYfyq@mail.gmail.com>

On 10/19/10, James Lee <james at opencsw.org> wrote:
> On 14/10/10, 17:27:29, Philip Brown <phil at bolthole.com> wrote regarding Re:
>
>> Lets say a site is very security concious, and only uses a handful of
>> our package, and they only need one or two of the long time "core" CAS
>> scripts.
>> They could install the global-zone cas package once... then go through
>> a bunch of zone level package upgrades without hassle, over the time
>> period of a year.
>
> Aside from the global zone pollution and micro management package issues,
> it goes wrong when you add new one or the user needs one that hasn't
> been installed.  With a single package it will baulk and not fail in
> error.


That is certainly true.
The issue is a "zero sum game". Either one side wins, or the other
does, and there is no middle ground.
So the issue then becomes an issue of what we think the most common cases are.
At the time when the last discussion happened, there had been a LOT of
updates to cswclassxxx scripts. (but not of "core" scripts).  Given
that background, the "common case" seemed to be favouring frequent
updates of lesser/new/non-critical scripts, with stability of "core"
scripts such as cswpreserveconf.
I think that is still the case, although changes are less frequent now.
Would you agree the above is true?

From phil at bolthole.com  Tue Oct 19 18:34:57 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 19 Oct 2010 09:34:57 -0700
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
Message-ID: <AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>

On 10/19/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>
> Looking at the histogram, 97.9% sonames are 31 characters and less, so
> we can fit 98.3% of them into pkgnames with up to 30 characters.  The
> current cutoff point is at 84.6%, which I think is too low, leaving
> 15.4% sonames out.  We could use curtations, but I'd prefer if we
> didn't.  If we nevertheless did, I'd like us to have an algorithmic
> way of shortening package names.
>
> Thoughts?
>

Now show details of how wide output would have to be, for pkg-get -c
or equivalent in pkgutil, if there were no limits.

Currently, the output fits.. just barely... into a standard 80-char screen.

If you take away all limits, the output would probably require
150-char wide screen.

From ihsan at opencsw.org  Tue Oct 19 19:15:50 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Tue, 19 Oct 2010 19:15:50 +0200
Subject: [csw-maintainers] Easify OpenCSW bootstrapping on a server
In-Reply-To: <EA7F2B16-0A2B-4EF7-82D9-C7761D9D9ECC@opencsw.org>
References: <4AC10A87.1090205@opencsw.org>	<6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org>	<4AC1194A.3040308@opencsw.org>	<1A5C1813-4004-4AF3-B99A-996C6D5C7549@opencsw.org>	<AANLkTinvck35SK6G1LO1zVY6OJSns5O0gUXhCPM25hiL@mail.gmail.com>	<4C98DB55.7090807@opencsw.org>	<AANLkTikby1G5G_RrrsKLi_t_CNRu2m_Gf0FMM7wRAXNi@mail.gmail.com>	<4C98EB89.20408@opencsw.org>	<AANLkTinwx6P6KhqQ1RPCOu65siE+5k1Of+a+F=2k_zCF@mail.gmail.com>	<E04D2381-F7B6-403F-BDEF-BD02705170AB@opencsw.org>	<AANLkTin+tT73MuUBfcwNMU-SCT6_Z2aeMKfFmXrkL6ro@mail.gmail.com>
	<EA7F2B16-0A2B-4EF7-82D9-C7761D9D9ECC@opencsw.org>
Message-ID: <4CBDD246.3000808@opencsw.org>

Am 22.09.10 09:15, schrieb Dagobert Michelsen:

> Ihsan: I find it hard to work with the web-archive. Would it be
> possible to set up a public read-only IMAP mailbox with all
> archived postings in it?

I would prefer not to this, because IMAP is not designed to a read only
protocol.

As far the maintainers list is public, there is an NNTP interface from
Gmane: nntp://news.gmane.org/gmane.os.solaris.opencsw.maintainers

It is also possible to download the complete as a monthly mbox file:
http://lists.opencsw.org/pipermail/maintainers/

Up on request, I can provide it also as a single mbox file.




Ihsan

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

From pfelecan at opencsw.org  Tue Oct 19 19:31:54 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 19 Oct 2010 19:31:54 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	(Philip Brown's message of "Tue, 19 Oct 2010 09:34:57 -0700")
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
Message-ID: <x67hhe9jhx.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> On 10/19/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>>
>> Looking at the histogram, 97.9% sonames are 31 characters and less, so
>> we can fit 98.3% of them into pkgnames with up to 30 characters.  The
>> current cutoff point is at 84.6%, which I think is too low, leaving
>> 15.4% sonames out.  We could use curtations, but I'd prefer if we
>> didn't.  If we nevertheless did, I'd like us to have an algorithmic
>> way of shortening package names.
>>
>> Thoughts?
>>
>
> Now show details of how wide output would have to be, for pkg-get -c
> or equivalent in pkgutil, if there were no limits.
>
> Currently, the output fits.. just barely... into a standard 80-char screen.
>
> If you take away all limits, the output would probably require
> 150-char wide screen.

Look how 'dpkg --list' works on debian and adapt. In the meantime, use a
wide terminal... Arbitrary limits are lame when the only reason is lame.
-- 
Peter

From phil at bolthole.com  Tue Oct 19 20:18:00 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 19 Oct 2010 11:18:00 -0700
Subject: [csw-maintainers] The minimal version of gnupg
In-Reply-To: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>
References: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>
Message-ID: <AANLkTikREA+WfjgfagnEk8CnKDmiymhh1Eun4_E+asvL@mail.gmail.com>

On 10/19/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> Working through GPG related packages Dago and I have stumbled upon a
> minimal version of GPG series 1.x:
>
> http://www.opencsw.org/packages/gnupg_minimal/
>
> I'm personally unaware of any scenario under which keeping gnupg is a
> necessity.  Is anyone on the mailing list aware of any scenario under
> which the minimal version of GPG is necessary?  If not, I'd be
> inclined to remove this package from the catalog to reduce maintenance
> load.


packages are rarely "neccessary", but they are often "useful".

It appears that the purpose of the gnupu_minimal" package, got
corrupted in its last rebuild.
It is supposed to avoid dependancies such as openldap_rt.
In theory, even things like the curl_rt, since that itself, also pulls
in openldap_rt.
And that pulls in sasl. and openssl....

Since gnupg is useful in the core of what we do: (pkg-get and pkgutil
both use it), I think it is beneficial to our users to provide a
"minimal" package of it, so as to minimize the number of required
packages to install, before using our package transfer mechanisms
securely.


It would be very nice if you or Dago could rebuild it "properly", with
reduced dependencies.

From maciej at opencsw.org  Tue Oct 19 23:58:37 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 19 Oct 2010 22:58:37 +0100
Subject: [csw-maintainers] The minimal version of gnupg
In-Reply-To: <AANLkTikREA+WfjgfagnEk8CnKDmiymhh1Eun4_E+asvL@mail.gmail.com>
References: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>
	<AANLkTikREA+WfjgfagnEk8CnKDmiymhh1Eun4_E+asvL@mail.gmail.com>
Message-ID: <AANLkTimws-VfDFfprPBkq1-Q9tKTC7b1wM3nZJp+q4Fr@mail.gmail.com>

No dia 19 de Outubro de 2010 19:18, Philip Brown <phil at bolthole.com> escreveu:
> On 10/19/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> Working through GPG related packages Dago and I have stumbled upon a
>> minimal version of GPG series 1.x:
>>
>> http://www.opencsw.org/packages/gnupg_minimal/
>>
>> I'm personally unaware of any scenario under which keeping gnupg is a
>> necessity. ?Is anyone on the mailing list aware of any scenario under
>> which the minimal version of GPG is necessary? ?If not, I'd be
>> inclined to remove this package from the catalog to reduce maintenance
>> load.
>
>
> packages are rarely "neccessary", but they are often "useful".
>
> It appears that the purpose of the gnupu_minimal" package, got
> corrupted in its last rebuild.
> It is supposed to avoid dependancies such as openldap_rt.
> In theory, even things like the curl_rt, since that itself, also pulls
> in openldap_rt.
> And that pulls in sasl. and openssl....

This sounds like a problem stemming from the lack of package
granularity; the libraries alone don't constitute that much of a
problem, I'd say.  If openldap_rt depended only on shared libraries
from sasl, dependencies wouldn't be that prominent.

By the way, I'm wondering how the debian folk make the openldap
package an optional dependency, and whether we can do the same.

> Since gnupg is useful in the core of what we do: (pkg-get and pkgutil
> both use it), I think it is beneficial to our users to provide a
> "minimal" package of it, so as to minimize the number of required
> packages to install, before using our package transfer mechanisms
> securely.

If that's the goal, we could even embed the minimal gpg in the
pkg-get/pkgutil packages the same way wget is embedded there.

From maciej at opencsw.org  Wed Oct 20 10:26:27 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 20 Oct 2010 09:26:27 +0100
Subject: [csw-maintainers] Tools to modify existing packages
Message-ID: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>

I would like to edit an existing unmaintained package, and remove
certain files that I believe shouldn't be there.  Something along the
lines of: gunzip, transform, edit, update the REV tag, update
checksums, put the thing back together, release.  Do people have any
tools to do such open package surgery?

Maciej

From pfelecan at opencsw.org  Wed Oct 20 10:37:02 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 20 Oct 2010 10:37:02 +0200
Subject: [csw-maintainers] Tools to modify existing packages
In-Reply-To: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>
	(Maciej Blizinski's message of "Wed, 20 Oct 2010 09:26:27 +0100")
References: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>
Message-ID: <x639s19s5t.fsf@opencsw.org>

"Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes:

> I would like to edit an existing unmaintained package, and remove
> certain files that I believe shouldn't be there.  Something along the
> lines of: gunzip, transform, edit, update the REV tag, update
> checksums, put the thing back together, release.  Do people have any
> tools to do such open package surgery?

Use the standard packaging tools. Here is a quick recipe that I used for
changing the dependency of gcc3core:

- mkdir gcc3core-x
- gunzip gcc3core-3.4.6\,REV\=2009.06.25-SunOS5.8-i386-CSW.pkg.gz
- pkgtrans gcc3core-3.4.6,REV=2009.06.25-SunOS5.8-i386-CSW.pkg /home/pfelecan/gcc3core-x CSWgcc3core
- make your modifications in the gcc3core-x
- pkgtrans -s ${PWD}/gcc3core-x "${PWD}/gcc3core-3.4.6,REV=2010.05.14-SunOS5.8-i386-CSW.pkg" CSWgcc3core
- gzip -9 "/home/pfelecan/gcc3core-3.4.6,REV=2010.05.14-SunOS5.8-i386-CSW.pkg"

Hope that I didn't forgot something important...
-- 
Peter

From bonivart at opencsw.org  Wed Oct 20 11:22:06 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 20 Oct 2010 11:22:06 +0200
Subject: [csw-maintainers] Tools to modify existing packages
In-Reply-To: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>
References: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>
Message-ID: <AANLkTimS7HYLXDpOOzJfHQ=ca1mWwLHA3Zda-F8sXdVd@mail.gmail.com>

On Wed, Oct 20, 2010 at 10:26 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> I would like to edit an existing unmaintained package, and remove
> certain files that I believe shouldn't be there. ?Something along the
> lines of: gunzip, transform, edit, update the REV tag, update
> checksums, put the thing back together, release. ?Do people have any
> tools to do such open package surgery?

I recently described the steps for a user of pkgutil who needed to
edit pkginfo on some commercial packages.

# gunzip amanda.pkg.gz
# pkgtrans amanda.pkg . all (this will unpack the package)
# cd amanda (the package name just unpacked)
# vi pkginfo (edit especially NAME and VERSION fields to comply with CSW)
# ls -l pkginfo (note size)
# sum pkginfo (note checksum)
# vi pkgmap (edit size (column 4) and checksum (column 5) values of
pkginfo line)
# cd ..
# pkgtrans . newamanda.pkg amanda (re-assemble the package as newamanda.pkg)

In your case you will of course also need to remove the actual files
and corresponding lines in pkgmap.

/peter

From pfelecan at opencsw.org  Wed Oct 20 12:50:42 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 20 Oct 2010 12:50:42 +0200
Subject: [csw-maintainers] Tools to modify existing packages
In-Reply-To: <AANLkTimS7HYLXDpOOzJfHQ=ca1mWwLHA3Zda-F8sXdVd@mail.gmail.com>
	(Peter Bonivart's message of "Wed, 20 Oct 2010 11:22:06 +0200")
References: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>
	<AANLkTimS7HYLXDpOOzJfHQ=ca1mWwLHA3Zda-F8sXdVd@mail.gmail.com>
Message-ID: <x6y69t87el.fsf@opencsw.org>

Peter Bonivart <bonivart at opencsw.org> writes:

> # vi pkginfo (edit especially NAME and VERSION fields to comply with CSW)
> # ls -l pkginfo (note size)
> # sum pkginfo (note checksum)
> # vi pkgmap (edit size (column 4) and checksum (column 5) values of
> pkginfo line)

Thank you. This was the information that I missed and which was solved,
in my case, by Ben...
-- 
Peter

From gadavis at opencsw.org  Thu Oct 21 00:30:09 2010
From: gadavis at opencsw.org (Geoff Davis)
Date: Wed, 20 Oct 2010 15:30:09 -0700
Subject: [csw-maintainers] openldaprc file is missing,
	slapd.conf not found by service start method
In-Reply-To: <47C14F3A-CCC1-49AC-B211-96994EED229D@opencsw.org>
References: <de742a54035908065fc96c823809cc97@www.opencsw.org>
	<47C14F3A-CCC1-49AC-B211-96994EED229D@opencsw.org>
Message-ID: <0C13B931-44E3-4971-8BBA-4B2F6BDA6CB1@opencsw.org>

On Oct 19, 2010, at 11:14 PM, Dagobert Michelsen wrote:

> Hi Geoff,
> 
> Anfang der weitergeleiteten E-Mail:
>> ----------------------------------------------------------------------
>> (0008382) gadavis (developer) - 2010-10-20 00:00
>> https://www.opencsw.org/mantis/view.php?id=4521#c8382
>> ----------------------------------------------------------------------
>> +1 for a fix, this was a frustrating bug to stumble upon.
> 
> Feel free to join the OpenLDAP-team :-) I am really sorry, but I am currently
> arms deep in other (work related) stuff...
> 
> 
> Best regards
> 
> -- Dago


I'd love to jump in to tweak a couple of things about this package, but I have a lot of questions about this Makefile and where files are supposed to be installed.

First question:

Lines 18-21 of the Makefile at r11146 [1]:

DISTFILES  = $(SOURCEFILES)
DISTFILES += CSWoldap.postinstall
DISTFILES += README.CSW openldaprc
DISTFILES += cswopenldap openldap.xml svc-openldap

Why are a bunch of files that are not part of the Sourceforge distribution and that could never be downloaded from Sourceforge being added to the DISTFILES variable? Should those lines be deleted, or is this some special usage of DISTFILES that is undocumented in the GAR Variable Reference? [2] I'm guessing that it's the latter, and that this is a hack to get the files to be placed in $DOWNLOADDIR so that the build process can use them. Is there a "proper" way to do this?

Second question:

The init script [3] and README.CSW [4] both make reference to /opt/csw/etc/openldap as the default configuration directory. However, when I install the package, all of the configuration files end up in /etc/opt/csw/openldap

Same thing with the var stuff - README.CSW talks about /opt/csw/var/openldap but the package actually uses /var/opt/csw/openldap

I get the feeling from watching the maintainers list that the configuration file locations are still up for discussion, but I'd at least like to set some sane working defaults consistent with whatever is mechanism is installing the configuration files.

So which paths should I use as the default configuration file locations in the init script [3] and the default opencswrc file [5]? /etc/opt/csw/openldap and /var/opt/csw/openldap
-OR-
/opt/csw/etc/openldap and /opt/csw/var/openldap

Third question:

The init script [3] talks about a file called openldaprc [5] that isn't being included in this package but does exist in the repository, which is what the original bug [6] was about. It specifically mentions installing openldaprc by hand:

(from lines 14-17 in [3]):
# For example,
#  mkdir -p /etc/opt/csw
#  cp /opt/csw/share/doc/openldap/openldaprc /etc/opt/csw/

Is /opt/csw/share/doc/openldap/openldaprc the correct location for that sample file?

Fourth Question:

Why does the Makefile Line 57 [7] put the Patch files in the docs directory?
EXTRA_DOCS = README.CSW $(PATCHFILES)

Sorry for all of the questions, but I'm still trying to get my head around all of the various rules of thumb that are used here for packaging.

[1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/Makefile?rev=11146#L18
[2] http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference#DownloadSettings
[3] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/files/cswopenldap?rev=11146
[4] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/files/README.CSW?rev=11146
[5] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/files/openldaprc?rev=11146
[6] https://www.opencsw.org/mantis/view.php?id=4521
[7] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/Makefile?rev=11146#L57





From dam at opencsw.org  Thu Oct 21 08:57:53 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 21 Oct 2010 08:57:53 +0200
Subject: [csw-maintainers] openldaprc file is missing,
	slapd.conf not found by service start method
In-Reply-To: <0C13B931-44E3-4971-8BBA-4B2F6BDA6CB1@opencsw.org>
References: <de742a54035908065fc96c823809cc97@www.opencsw.org>
	<47C14F3A-CCC1-49AC-B211-96994EED229D@opencsw.org>
	<0C13B931-44E3-4971-8BBA-4B2F6BDA6CB1@opencsw.org>
Message-ID: <81CC0AF8-CBAF-48F4-8213-0DCF9238F835@opencsw.org>

Hi Geoff,

Am 21.10.2010 um 00:30 schrieb Geoff Davis:
> On Oct 19, 2010, at 11:14 PM, Dagobert Michelsen wrote:
>> Anfang der weitergeleiteten E-Mail:
>>> ----------------------------------------------------------------------
>>> (0008382) gadavis (developer) - 2010-10-20 00:00
>>> https://www.opencsw.org/mantis/view.php?id=4521#c8382
>>> ----------------------------------------------------------------------
>>> +1 for a fix, this was a frustrating bug to stumble upon.
>>
>> Feel free to join the OpenLDAP-team :-) I am really sorry, but I am  
>> currently
>> arms deep in other (work related) stuff...

Well, the package is co-maintainer by Rupert and me but I guess we both
would appreciate some more hands on the package.

> I'd love to jump in to tweak a couple of things about this package,  
> but I have a lot of questions about this Makefile and where files  
> are supposed to be installed.
>
> First question:
>
> Lines 18-21 of the Makefile at r11146 [1]:
>
> DISTFILES  = $(SOURCEFILES)
> DISTFILES += CSWoldap.postinstall
> DISTFILES += README.CSW openldaprc
> DISTFILES += cswopenldap openldap.xml svc-openldap
>
> Why are a bunch of files that are not part of the Sourceforge  
> distribution and that could never be downloaded from Sourceforge  
> being added to the DISTFILES variable? Should those lines be  
> deleted, or is this some special usage of DISTFILES that is  
> undocumented in the GAR Variable Reference? [2] I'm guessing that  
> it's the latter, and that this is a hack to get the files to be  
> placed in $DOWNLOADDIR so that the build process can use them.

It is not a hack, but a necessity for source packages (which we don't  
have yet).

> Is there a "proper" way to do this?

All files used in the package should either be listed in DISTFILES or
PATCHFILES for the following reasons:
- external files are checksummed
- all files will be put/expanded to $(WORKDIR), from where the file  
should
   only be used in the Makefile
- when assembling source packages these are used to define what goes  
into the
   source package.
Sometime ago the DISTFILES where also all checksummed, not only the  
remote ones.

> Second question:
>
> The init script [3] and README.CSW [4] both make reference to /opt/ 
> csw/etc/openldap as the default configuration directory. However,  
> when I install the package, all of the configuration files end up  
> in /etc/opt/csw/openldap
>
> Same thing with the var stuff - README.CSW talks about /opt/csw/var/ 
> openldap but the package actually uses /var/opt/csw/openldap
>
> I get the feeling from watching the maintainers list that the  
> configuration file locations are still up for discussion, but I'd at  
> least like to set some sane working defaults consistent with  
> whatever is mechanism is installing the configuration files.
>
> So which paths should I use as the default configuration file  
> locations in the init script [3] and the default opencswrc file  
> [5]? /etc/opt/csw/openldap and /var/opt/csw/openldap
> -OR-
> /opt/csw/etc/openldap and /opt/csw/var/openldap

/etc/opt/csw and /var/opt/csw. It does not make sense to have the same  
OpenLDAP
in all zones. Please unify all documeted locations.

> Third question:
>
> The init script [3] talks about a file called openldaprc [5] that  
> isn't being included in this package but does exist in the  
> repository, which is what the original bug [6] was about. It  
> specifically mentions installing openldaprc by hand:
>
> (from lines 14-17 in [3]):
> # For example,
> #  mkdir -p /etc/opt/csw
> #  cp /opt/csw/share/doc/openldap/openldaprc /etc/opt/csw/
>
> Is /opt/csw/share/doc/openldap/openldaprc the correct location for  
> that sample file?

Mmhhhh.... or /opt/csw/etc/openldap/openldaprc.CSW ? This could be  
used as a boilerplate
for NFS-installations also.

> Fourth Question:
>
> Why does the Makefile Line 57 [7] put the Patch files in the docs  
> directory?
> EXTRA_DOCS = README.CSW $(PATCHFILES)

Looks like I did this. IIRC I did this to mimic the existing package
from a time without GAR where the patches where not public to go into
the released package for reference. I guess you can just drop that.

> Sorry for all of the questions, but I'm still trying to get my head  
> around all of the various rules of thumb that are used here for  
> packaging.

Sure, no problem :-)


Best regards

   -- Dago


> [1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/Makefile?rev=11146#L18
> [2] http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference#DownloadSettings
> [3] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/files/cswopenldap?rev=11146
> [4] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/files/README.CSW?rev=11146
> [5] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/files/openldaprc?rev=11146
> [6] https://www.opencsw.org/mantis/view.php?id=4521
> [7] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/Makefile?rev=11146#L57
>
>
>
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.


From okiddle at yahoo.co.uk  Thu Oct 21 11:11:05 2010
From: okiddle at yahoo.co.uk (Oliver Kiddle)
Date: Thu, 21 Oct 2010 11:11:05 +0200 (CEST)
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
Message-ID: <20101021091105.5321F33F@mail.opencsw.org>

Philip Brown wrote:
> If you take away all limits, the output would probably require
> 150-char wide screen.

Putting aside the discussion about whether there should be no arbitrary
limits we do have a very real issue at the moment where the new SONAME
based libraries are going to cause us to hit the 20 character limit more
often. I think the SONAME package idea of Maciej's is really good and it
is be worth making compromises to accomodate it. From the histogram, 28
and 30 stick out as good possible candidates for a new limit. 24 would
solve my immediate problem with pygobject.

The pkgutil -c output has been cited in the arguments for a limit so
let's consider it;
CSWzlib                   1.2.5,REV=2010.09.22      1.2.4,REV=2010.03.19
|         |         |         |         |         |         |         |
12345678901234567890123456789012345678901234567890123456789012345678901234567890
                          |         |         |     |         |         |
                          1234567890123456789012345 1234567890123456789012345678

If you assume only one space to divide fields, we currently have 25
characters for the package name, 25 for the installed version and 28 for
the catalogue version. That's with a limit on the package name of 20
characters. So an increase to 28 characters would be possible without
any effect on 80-wide terminal users (take 3 from the catalog column and
reduce the margin to the installed column down to 1). We could make
further space by replacing ",REV=" with a space or other single
character in both versions. That's all without resorting to the dpkg
--list approach of checking $COLUMNS and truncating package names. If we
ever do that, we should add options like dpkg --get-selections where the
output is for the consumption of a script rather than a human.

Oliver

From dam at opencsw.org  Thu Oct 21 11:20:10 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 21 Oct 2010 11:20:10 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <20101021091105.5321F33F@mail.opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
Message-ID: <849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>

Hi Oliver,

Am 21.10.2010 um 11:11 schrieb Oliver Kiddle:
> If we
> ever do that, we should add options like dpkg --get-selections where  
> the
> output is for the consumption of a script rather than a human.

There are other feasible approaches to make it human readable like
defining a maximum column width and either simple concat longer ones
(wouldn't require a special machine-readable option)

CSWmypkg   mypkg    1.2.3,REV=01.01.2001
CSWmylongpackage mylongpackage 2.3.4,REV=01.01.2001
CSWopkg    otherpkg 3.4.5,REV=01.02.2003

or skip with the field to the next line

CSWmypkg   mypkg    1.2.3,REV=01.01.2001
CSWmylongpackage
            mylongpackage
                     2.3.4,REV=01.01.2001
CSWopkg    otherpkg 3.4.5,REV=01.02.2003



Best regards

   -- Dago


From maciej at opencsw.org  Thu Oct 21 15:19:05 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 21 Oct 2010 14:19:05 +0100
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
Message-ID: <AANLkTinACzX-82YO5MJODKFAFSc8XJEL4Y0V3TzN578n@mail.gmail.com>

No dia 21 de Outubro de 2010 10:20, Dagobert Michelsen
<dam at opencsw.org> escreveu:
> Hi Oliver,
>
> Am 21.10.2010 um 11:11 schrieb Oliver Kiddle:
>>
>> If we
>> ever do that, we should add options like dpkg --get-selections where the
>> output is for the consumption of a script rather than a human.
>
> There are other feasible approaches to make it human readable like
> defining a maximum column width and either simple concat longer ones
> (wouldn't require a special machine-readable option)

Yes, I think it's a good thing to distinguish between presentation and
data itself.  Fitting information on a 80-column terminal is a
separate issue from having the information in the first place.  You
can come up with a number of algorithms to fit that information on the
screen.  I believe that having a consistent mapping between sonames
and package names is more valuable than the absence of a text
formatting step.

From phil at bolthole.com  Thu Oct 21 18:31:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 21 Oct 2010 09:31:29 -0700
Subject: [csw-maintainers] The minimal version of gnupg
In-Reply-To: <AANLkTimws-VfDFfprPBkq1-Q9tKTC7b1wM3nZJp+q4Fr@mail.gmail.com>
References: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>
	<AANLkTikREA+WfjgfagnEk8CnKDmiymhh1Eun4_E+asvL@mail.gmail.com>
	<AANLkTimws-VfDFfprPBkq1-Q9tKTC7b1wM3nZJp+q4Fr@mail.gmail.com>
Message-ID: <AANLkTinf-_aCkz+m8zt6vi9s-5_4t6jq1DH4PEj_=wHG@mail.gmail.com>

On Tue, Oct 19, 2010 at 2:58 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> No dia 19 de Outubro de 2010 19:18, Philip Brown <ph....
>>
>> It is supposed to avoid dependancies such as openldap_rt.
>> In theory, even things like the curl_rt, since that itself, also pulls
>> in openldap_rt.
>> And that pulls in sasl. and openssl....
>
> This sounds like a problem stemming from the lack of package
> granularity; the libraries alone don't constitute that much of a
> problem, I'd say. ?If openldap_rt depended only on shared libraries
> from sasl, dependencies wouldn't be that prominent.
>....
>> Since gnupg is useful in the core of what we do: (pkg-get and pkgutil
>> both use it), I think it is beneficial to our users to provide a
>> "minimal" package of it, so as to minimize the number of required
>> packages to install, before using our package transfer mechanisms
>> securely.
>
> If that's the goal, we could even embed the minimal gpg in the
> pkg-get/pkgutil packages the same way wget is embedded there.


first of all: pkg-get does not embed wget. it's a pure script only.

secondly: to avoid pulling in sasl, and openssl, is not fixed by
package granularity. we'd have to create separate versions of openldap
that did not use sasl. and I cant see putting together an openldap
version without openssl, that doesnt make much sense.
It makes more sense to trim the dependencies at the "gpg_minimal" level.
gpg is, in principle, a "local file operation only" utility, that got
extended. if all you want is the "local file only" stuff, all those
other libs are just useless junk.

From phil at bolthole.com  Thu Oct 21 20:43:18 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 21 Oct 2010 11:43:18 -0700
Subject: [csw-maintainers] Tools to modify existing packages
In-Reply-To: <x6y69t87el.fsf@opencsw.org>
References: <AANLkTikZ_nn+5SRHW49BWUsyYbRDG_zTkC6+egGcTr7+@mail.gmail.com>
	<AANLkTimS7HYLXDpOOzJfHQ=ca1mWwLHA3Zda-F8sXdVd@mail.gmail.com>
	<x6y69t87el.fsf@opencsw.org>
Message-ID: <AANLkTineRgC35n5Td-C=7COyPK+yWqQDLzx0aofHRWD9@mail.gmail.com>

at one point, Dago actually had a script that made this easier....

From phil at bolthole.com  Fri Oct 22 00:58:35 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 21 Oct 2010 15:58:35 -0700
Subject: [csw-maintainers] upcoming extention to catalog format: SITEFEATURES
Message-ID: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>

This is mostly an FYI to Peter B, but I'm copying the list as a nicety :)

I'm about to implement something I've been having on the backburner
for a long time:
A SITEFEATURES magic comment, in the catalog

This is not a per-package extention, but a site-wide extension, meant
to be hidden in the comments.

Syntax is as follows:

# SITEFEATURES feat1 feat2 ...

Note that "SITEFEATURES" must be the entirety of "second column" as
per awk definitions.
Each following feature must be a column unto itself, as per awk definitions.


Only planned imminently supported feature is going to be "gzipcatalog".
This specifies, "This site provides the catalog in gzipped format".
That is to say, you can expect to find "catalog.gz" alongside "catalog".

This should make updates a little quicker. 140k vs 500k.

I havent quite implemented it

From bwalton at opencsw.org  Fri Oct 22 03:45:39 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 21 Oct 2010 21:45:39 -0400
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
Message-ID: <1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Oct 21 18:58:35 -0400 2010:

> Only planned imminently supported feature is going to be "gzipcatalog".
> This specifies, "This site provides the catalog in gzipped format".
> That is to say, you can expect to find "catalog.gz" alongside
> "catalog".

So the tools, at first use, download the plain catalog file and for
that run use it.  At the next run, it peeks inside the existing
catalog before fetching the new one?

Wouldn't it be nicer to just gzip the catalog as the default and
provide the uncompressed version for sites that haven't updated
pkgutil/pkg-get yet?  I haven't looked, but I'm guessing that sol9
just doesn't provide the default toolset to do this, making initial
bootstrap more strenuous...?

Alternately, the tools could do:

if gunzip is available and the .gz file is on the mirror, pull it.
else grab the plain file

I'm not seeing the benefit of putting a hint inside the catalog itself
as presumably mirrors aren't going to omit syncing the .gz file.

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


From bwalton at opencsw.org  Fri Oct 22 03:48:19 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 21 Oct 2010 21:48:19 -0400
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
Message-ID: <1287712051-sup-8050@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Thu Oct 21 21:45:39 -0400 2010:

> I'm not seeing the benefit of putting a hint inside the catalog itself
> as presumably mirrors aren't going to omit syncing the .gz file.

...unless we start talking about other future features.  I'm
specifically referring to the initial proposed use.

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


From dam at opencsw.org  Fri Oct 22 08:59:29 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 22 Oct 2010 08:59:29 +0200
Subject: [csw-maintainers] The minimal version of gnupg
In-Reply-To: <AANLkTinf-_aCkz+m8zt6vi9s-5_4t6jq1DH4PEj_=wHG@mail.gmail.com>
References: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>
	<AANLkTikREA+WfjgfagnEk8CnKDmiymhh1Eun4_E+asvL@mail.gmail.com>
	<AANLkTimws-VfDFfprPBkq1-Q9tKTC7b1wM3nZJp+q4Fr@mail.gmail.com>
	<AANLkTinf-_aCkz+m8zt6vi9s-5_4t6jq1DH4PEj_=wHG@mail.gmail.com>
Message-ID: <A624DD1E-0E1F-4E27-AD98-5A200813299B@opencsw.org>

Hi,

Am 21.10.2010 um 18:31 schrieb Philip Brown:
> secondly: to avoid pulling in sasl, and openssl, is not fixed by
> package granularity. we'd have to create separate versions of openldap
> that did not use sasl. and I cant see putting together an openldap
> version without openssl, that doesnt make much sense.
> It makes more sense to trim the dependencies at the "gpg_minimal"  
> level.
> gpg is, in principle, a "local file operation only" utility, that got
> extended. if all you want is the "local file only" stuff, all those
> other libs are just useless junk.

Understood. What about having two versions gpg1 and gpg2 as it is
now or is just one version (the latest gpg2) sufficient?


Best regards

   -- Dago



From maciej at opencsw.org  Fri Oct 22 13:55:40 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 22 Oct 2010 12:55:40 +0100
Subject: [csw-maintainers] A dependency on libsunperf.so.7
Message-ID: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>

Checkpkg looked at CSWpy-numpy today, and said:

CSWpy-numpy:
 * Dependency issues of CSWpy-numpy:
 * SPROpls.2, reasons:
 *  - provides /opt/SUNWspro/lib/libsunperf.so.7 needed by opt/csw/lib/python
   /site-packages/numpy/linalg/lapack_lite.so
 *  - provides /opt/SUNWspro/lib/v8/libsunperf.so.7 needed by
   opt/csw/lib/python/site-packages/numpy/linalg/lapack_lite.so

Do we have any package providing libsunperf.so.7, by any chance?  If
not, can we make one?

Maciej

From ihsan at opencsw.org  Fri Oct 22 14:03:39 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Fri, 22 Oct 2010 14:03:39 +0200
Subject: [csw-maintainers] unbound verrsion
Message-ID: <4CC17D9B.2070205@opencsw.org>

Hello,

Is there a reason why according to the website unbound version is 1.4.5 
is in the repository but only 1.4.1 is available on the mirrors?






Ihsan

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

From maciej at opencsw.org  Fri Oct 22 15:17:47 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 22 Oct 2010 14:17:47 +0100
Subject: [csw-maintainers] unbound verrsion
In-Reply-To: <4CC17D9B.2070205@opencsw.org>
References: <4CC17D9B.2070205@opencsw.org>
Message-ID: <AANLkTi=gYnYGQiUBALBGagyCmNWpQtY=Ut2ufANxPFGt@mail.gmail.com>

No dia 22 de Outubro de 2010 13:03, Ihsan Dogan <ihsan at opencsw.org> escreveu:
> Hello,
>
> Is there a reason why according to the website unbound version is 1.4.5 is
> in the repository but only 1.4.1 is available on the mirrors?

A similar thing happened to libnspr4, it's on the website, but not in
the catalog.  It was sent for release, and rejected because of a file
conflict.

From phil at bolthole.com  Fri Oct 22 17:35:12 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 08:35:12 -0700
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>

On 10/21/10, Ben Walton <bwalton at opencsw.org> wrote:
>
> So the tools, at first use, download the plain catalog file and for
> that run use it.  At the next run, it peeks inside the existing
> catalog before fetching the new one?
>
> Wouldn't it be nicer to just gzip the catalog as the default and
> provide the uncompressed version for sites that haven't updated
> pkgutil/pkg-get yet?

well, for OUR site, both are going to be there from now on, so its not
an either/or thing.

> Alternately, the tools could do:
>
> if gunzip is available and the .gz file is on the mirror, pull it.
> else grab the plain file

That is one approach. I'm not mandating behaviour of other peoples' tools.
However, I personally recommend against it.
Firstly, it's rude to go leaving a bunch of "ERROR: file not found"
log messages on someone else's server. Secondly, its kinda a pain to
mask the fails from [our] user.
(Because if it fails for OTHER reasons, you actually want to show the
errors to the user)

> I'm not seeing the benefit of putting a hint inside the catalog itself
> as presumably mirrors aren't going to omit syncing the .gz file.

This specific feature flag is not primarily for our site. This is
really for the more general case of
"pkg-get compatible sites"

At one time, I was planning to also enable "SITEFEATURES patches", to
allow for a patching scheme I was planning. Unfortunately, the amount
of research required to implement a patching structure, proved to be
too much to fit into my schedule. I only got partway into it.

But who knows.. perhaps other people can come up with other
interesting ideas for a SITEFEATURE also.

From phil at bolthole.com  Fri Oct 22 17:37:43 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 08:37:43 -0700
Subject: [csw-maintainers] unbound verrsion
In-Reply-To: <AANLkTi=gYnYGQiUBALBGagyCmNWpQtY=Ut2ufANxPFGt@mail.gmail.com>
References: <4CC17D9B.2070205@opencsw.org>
	<AANLkTi=gYnYGQiUBALBGagyCmNWpQtY=Ut2ufANxPFGt@mail.gmail.com>
Message-ID: <AANLkTikHCT3G7uXKPJ0iLhxg5=fxPWCwfZvJtPuTiTGO@mail.gmail.com>

On 10/22/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 22 de Outubro de 2010 13:03, Ihsan Dogan <ihsan at opencsw.org>
> escreveu:
>> Hello,
>>
>> Is there a reason why according to the website unbound version is 1.4.5 is
>> in the repository but only 1.4.1 is available on the mirrors?
>
> A similar thing happened to libnspr4, it's on the website, but not in
> the catalog.  It was sent for release, and rejected because of a file
> conflict.


Yup these things happen because of last-minute release integration
issues, and they get rejected, after the registration step..
Sometimes, I dont reregister the older version, because I PRESUME, the
maintainer is going to submit an updated package Real Soon Now.
*cough*.

From phil at bolthole.com  Fri Oct 22 17:38:59 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 08:38:59 -0700
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
Message-ID: <AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>

Check the license, and go ahead and make one.
You know how to check to see "if we have a package for it already". :P



On 10/22/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> Checkpkg looked at CSWpy-numpy today, and said:
>
> CSWpy-numpy:
>  * Dependency issues of CSWpy-numpy:
>  * SPROpls.2, reasons:
>  *  - provides /opt/SUNWspro/lib/libsunperf.so.7 needed by
> opt/csw/lib/python
>    /site-packages/numpy/linalg/lapack_lite.so
>  *  - provides /opt/SUNWspro/lib/v8/libsunperf.so.7 needed by
>    opt/csw/lib/python/site-packages/numpy/linalg/lapack_lite.so
>
> Do we have any package providing libsunperf.so.7, by any chance?  If
> not, can we make one?
>
> Maciej
> _______________________________________________
> 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 Oct 22 17:40:00 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 08:40:00 -0700
Subject: [csw-maintainers] The minimal version of gnupg
In-Reply-To: <A624DD1E-0E1F-4E27-AD98-5A200813299B@opencsw.org>
References: <AANLkTi=gXBV8pCrEj=j+sdhKLKtL_LNb3hXpxHn-=KAO@mail.gmail.com>
	<AANLkTikREA+WfjgfagnEk8CnKDmiymhh1Eun4_E+asvL@mail.gmail.com>
	<AANLkTimws-VfDFfprPBkq1-Q9tKTC7b1wM3nZJp+q4Fr@mail.gmail.com>
	<AANLkTinf-_aCkz+m8zt6vi9s-5_4t6jq1DH4PEj_=wHG@mail.gmail.com>
	<A624DD1E-0E1F-4E27-AD98-5A200813299B@opencsw.org>
Message-ID: <AANLkTim3GeD+hqMAHBcKJVv3U-X=FW4f13pW+YXZ1AOF@mail.gmail.com>

On 10/21/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> Understood. What about having two versions gpg1 and gpg2 as it is
> now or is just one version (the latest gpg2) sufficient?
>

I'm guessing/hoping there is some amount of backward compatibility; if
so, certainly the latest version only, would be sufficient. I'm not a
gpg expert so dont know myself, however.

From bwalton at opencsw.org  Fri Oct 22 18:18:30 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 22 Oct 2010 12:18:30 -0400
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
	<AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
Message-ID: <1287764180-sup-9050@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Oct 22 11:35:12 -0400 2010:

> That is one approach. I'm not mandating behaviour of other peoples' tools.
> However, I personally recommend against it.

Fair enough.  The errors for a missing file wouldn't be nice.  That
being said, you still haven't indicated how this is a useful 'tag' to
embed in the catalog itself?  Why not place a 'hints' file as part of
the mirror that is fetched first.

Are you envisioning sites that don't have a .gz version of the
catalog?  This would be a local site then, running a catalog overlay?

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


From phil at bolthole.com  Fri Oct 22 21:23:10 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 12:23:10 -0700
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <1287764180-sup-9050@pinkfloyd.chass.utoronto.ca>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
	<AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
	<1287764180-sup-9050@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimbCZMQ-BDmKk_LPjHrP0fv+eCyd4vaC-QGG8vO@mail.gmail.com>

On Friday, October 22, 2010, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Oct 22 11:35:12 -0400 2010:
>
>> That is one approach. I'm not mandating behaviour of other peoples' tools.
>> However, I personally recommend against it.
>
> Fair enough. ?The errors for a missing file wouldn't be nice. ?That
> being said, you still haven't indicated how this is a useful 'tag' to
> embed in the catalog itself? ?Why not place a 'hints' file as part of
> the mirror that is fetched first.

because there is much less overhead this way, latency wise




>
> Are you envisioning sites that don't have a .gz version of the
> catalog? ?This would be a local site then, running a catalog overlay?
>

or sunfreeware.com or blastwave or ...

From bwalton at opencsw.org  Fri Oct 22 21:27:46 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 22 Oct 2010 15:27:46 -0400
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <AANLkTimbCZMQ-BDmKk_LPjHrP0fv+eCyd4vaC-QGG8vO@mail.gmail.com>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
	<AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
	<1287764180-sup-9050@pinkfloyd.chass.utoronto.ca>
	<AANLkTimbCZMQ-BDmKk_LPjHrP0fv+eCyd4vaC-QGG8vO@mail.gmail.com>
Message-ID: <1287775504-sup-7904@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Oct 22 15:23:10 -0400 2010:

> > Fair enough. ?The errors for a missing file wouldn't be nice. ?That
> > being said, you still haven't indicated how this is a useful 'tag' to
> > embed in the catalog itself? ?Why not place a 'hints' file as part of
> > the mirror that is fetched first.
> 
> because there is much less overhead this way, latency wise

Well, you need to bootstrap the hint info, so you're either pulling
the unzipped catalog once or pulling the hints file once.  I'm not
seeing the advantage here yet.

As you mentioned, this won't force a behaviour change in pkgutil, so I
don't really care that you're fiddling in the format...I just don't
see the point.

> > Are you envisioning sites that don't have a .gz version of the
> > catalog? ?This would be a local site then, running a catalog overlay?
> >
> 
> or sunfreeware.com or blastwave or ...

Ok, this makes more sense.

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


From phil at bolthole.com  Fri Oct 22 23:05:20 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 14:05:20 -0700
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
Message-ID: <AANLkTimgZLW=66fEFdi1JvZm5mSKBA01khUq7Czu5cE7@mail.gmail.com>

On 10/21/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> or skip with the field to the next line
>
> CSWmypkg   mypkg    1.2.3,REV=01.01.2001
> CSWmylongpackage
>             mylongpackage
>                      2.3.4,REV=01.01.2001
> CSWopkg    otherpkg 3.4.5,REV=01.02.2003
>
>

multi-line output? no way. too annoying to machine/script parse.

From phil at bolthole.com  Fri Oct 22 23:09:04 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 22 Oct 2010 14:09:04 -0700
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTinACzX-82YO5MJODKFAFSc8XJEL4Y0V3TzN578n@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTinACzX-82YO5MJODKFAFSc8XJEL4Y0V3TzN578n@mail.gmail.com>
Message-ID: <AANLkTi=pERR_TmUApjRt=7aZDnpXTGUnnS5mQx3zCUYX@mail.gmail.com>

On 10/21/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>
> Yes, I think it's a good thing to distinguish between presentation and
> data itself.  Fitting information on a 80-column terminal is a
> separate issue from having the information in the first place.  You
> can come up with a number of algorithms to fit that information on the
> screen.  I believe that having a consistent mapping between sonames
> and package names is more valuable than the absence of a text
> formatting step.
>

Lets do a brief cost/benefit analysis here:

Direct mapping of full soname -> package name, with no truncation
+  "benefits" maintainers. Although really only a small subset of
maintainers, working
  on a small subset of packages
- negatively impacts users, via readability issues

Keeping existing limits on lengths:
+  benefits all users by keeping outputs consistently and easily readable.
- means maintainers might have to occasionally do a little extra
searching... ONE TIME,
   until then they put in the dependency lines, and then they'll know
where to go from then on.

From james at opencsw.org  Sat Oct 23 11:57:09 2010
From: james at opencsw.org (James Lee)
Date: Sat, 23 Oct 2010 09:57:09 GMT
Subject: [csw-maintainers] upcoming extention to catalog format:
 SITEFEATURES
In-Reply-To: <AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
	<AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
Message-ID: <20101023.9570900.4027408391@gyor.oxdrove.co.uk>

On 22/10/10, 16:35:12, Philip Brown <phil at bolthole.com> wrote regarding Re:
[csw-maintainers] upcoming extention to catalog format: SITEFEATURES:


> > So the tools, at first use, download the plain catalog file and for
> > that run use it.  At the next run, it peeks inside the existing
> > catalog before fetching the new one?
> >
> > Wouldn't it be nicer to just gzip the catalog as the default and
> > provide the uncompressed version for sites that haven't updated
> > pkgutil/pkg-get yet?

> well, for OUR site, both are going to be there from now on, so its not
> an either/or thing.

> > Alternately, the tools could do:
> >
> > if gunzip is available and the .gz file is on the mirror, pull it.
> > else grab the plain file

> That is one approach. I'm not mandating behaviour of other peoples'
> tools. However, I personally recommend against it.

Seems perfect to me.  Something like:

wget -q ${SITE}/catalog.gz || wget -q ${SITE}/catalog
[ -e catalog.gz ] && gunzip catalog.gz




> Firstly, it's rude to go leaving a bunch of "ERROR: file not found"
> log messages on someone else's server.

You are over sensitive.  Tell this to the browser people about
favicon.ico, the phone people about apple-touch-icon.png, major robots
that don't learn that you have deleted files, or sites that don't update
links when you move pages.

If you are bothered you can learn after one probe about a site and store
the value.




I'm not sure I follow the example in this proposal, to put the gz value
in the file makes no sense because by the time you have the file you
aren't bothered what you should have done, it's too late.  You can save
it for next time although it might have changed by then.  Downloading a
hints file takes longer than probing and failing and getting the truth.
If you are worried about 404s then you won't want to get a hints file
that isn't on someone else's mirrors.



Alternative method, try sending some headers:
$ wget --header 'Accept-Encoding: gzip' ...
...
$ file catalog
catalog:        gzip compressed data - deflate method


and try an "If-Modified-Since: ..." too to save downloading at all.




James.

From dam at opencsw.org  Sat Oct 23 11:57:43 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 23 Oct 2010 11:57:43 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTimgZLW=66fEFdi1JvZm5mSKBA01khUq7Czu5cE7@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTimgZLW=66fEFdi1JvZm5mSKBA01khUq7Czu5cE7@mail.gmail.com>
Message-ID: <93EB6507-AD29-464E-A8BE-293E68FE7087@opencsw.org>

Hi Phil,

Am 22.10.2010 um 23:05 schrieb Philip Brown:
> On 10/21/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>>
>> or skip with the field to the next line
>>
>> CSWmypkg   mypkg    1.2.3,REV=01.01.2001
>> CSWmylongpackage
>>            mylongpackage
>>                     2.3.4,REV=01.01.2001
>> CSWopkg    otherpkg 3.4.5,REV=01.02.2003
>>
>>
>
> multi-line output? no way. too annoying to machine/script parse.

The tool could easily have a --parseable or similar flag. It makes
no sense to forcefully provide a human- and machine-readable
output at the same time when separating them makes lots of sense.


Best regards

   -- DAgo



From dam at opencsw.org  Sat Oct 23 12:00:17 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 23 Oct 2010 12:00:17 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTi=pERR_TmUApjRt=7aZDnpXTGUnnS5mQx3zCUYX@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTinACzX-82YO5MJODKFAFSc8XJEL4Y0V3TzN578n@mail.gmail.com>
	<AANLkTi=pERR_TmUApjRt=7aZDnpXTGUnnS5mQx3zCUYX@mail.gmail.com>
Message-ID: <E08DF394-5CF1-4702-B9B7-36B261D1A0DC@opencsw.org>

Hi Phil,

Am 22.10.2010 um 23:09 schrieb Philip Brown:
> On 10/21/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>>
>> Yes, I think it's a good thing to distinguish between presentation  
>> and
>> data itself.  Fitting information on a 80-column terminal is a
>> separate issue from having the information in the first place.  You
>> can come up with a number of algorithms to fit that information on  
>> the
>> screen.  I believe that having a consistent mapping between sonames
>> and package names is more valuable than the absence of a text
>> formatting step.
>
> Lets do a brief cost/benefit analysis here:
>
> Direct mapping of full soname -> package name, with no truncation
> +  "benefits" maintainers. Although really only a small subset of
> maintainers, working
>  on a small subset of packages

+ benefits users as there is no need to look up a package name at
   all because the name can "just be typed in"

> - negatively impacts users, via readability issues

This can be easily circumvented as I outlined in my previous email.

> Keeping existing limits on lengths:
> +  benefits all users by keeping outputs consistently and easily  
> readable.

No real pro as this can be achieved with longer names too.

> - means maintainers might have to occasionally do a little extra
> searching... ONE TIME,
>   until then they put in the dependency lines, and then they'll know
> where to go from then on.

- this search has to be done *by every user* who wants to install the
   package


Best regards

   -- Dago


From james at opencsw.org  Sat Oct 23 12:03:13 2010
From: james at opencsw.org (James Lee)
Date: Sat, 23 Oct 2010 10:03:13 GMT
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTimgZLW=66fEFdi1JvZm5mSKBA01khUq7Czu5cE7@mail.gmail.com>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTimgZLW=66fEFdi1JvZm5mSKBA01khUq7Czu5cE7@mail.gmail.com>
Message-ID: <20101023.10031300.2761803890@gyor.oxdrove.co.uk>

On 22/10/10, 22:05:20, Philip Brown <phil at bolthole.com> wrote regarding Re:
[csw-maintainers] Packaging gems and package naming conventions:

> > or skip with the field to the next line
> >
> > CSWmypkg   mypkg    1.2.3,REV=01.01.2001
> > CSWmylongpackage
> >             mylongpackage
> >                      2.3.4,REV=01.01.2001
> > CSWopkg    otherpkg 3.4.5,REV=01.02.2003
> >
> >

> multi-line output? no way. too annoying to machine/script parse.

If the package and software names were derivable from each other than
you'd only need to list one of them.



James.

From bwalton at opencsw.org  Sat Oct 23 13:47:56 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 23 Oct 2010 07:47:56 -0400
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <20101023.10031300.2761803890@gyor.oxdrove.co.uk>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTimgZLW=66fEFdi1JvZm5mSKBA01khUq7Czu5cE7@mail.gmail.com>
	<20101023.10031300.2761803890@gyor.oxdrove.co.uk>
Message-ID: <1287834389-sup-3195@pinkfloyd.chass.utoronto.ca>

Excerpts from James Lee's message of Sat Oct 23 06:03:13 -0400 2010:

> If the package and software names were derivable from each other than
> you'd only need to list one of them.

Yes, the catalogname could be something like:
echo $PKGNAME | sed 's/CSW//; s/-/_/g'

That would be really nice, I think.

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


From maciej at opencsw.org  Sun Oct 24 13:21:57 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sun, 24 Oct 2010 12:21:57 +0100
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
Message-ID: <AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>

No dia 22 de Outubro de 2010 16:38, Philip Brown <phil at bolthole.com> escreveu:
> Check the license, and go ahead and make one.
> You know how to check to see "if we have a package for it already". :P

Of course! I simply do:

pkgutil -a | grep libsunperf

And voila! We don't have it.

Checked the license:

http://docs.sun.com/source/820-4155/runtime.libraries.html

libsunperf is listed.  The following bit is worrying:

"""(g) you agree to defend and indemnify Sun and its licensors from
and against any damages, costs, liabilities, settlement amounts and/or
expenses (including attorneys' fees) incurred in connection with any
claim, lawsuit or action by any third party that arises or results
from the use or distribution of any and all Programs and/or
Redistributable."""

What does "you" refer to in this case?  The OpenCSW project, me, or
something else?

From bonivart at opencsw.org  Sun Oct 24 13:35:38 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 24 Oct 2010 13:35:38 +0200
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
	<AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
Message-ID: <AANLkTikCjgUAxVRY1DogDD+KZzmSeCL2zYLFMUs0UgSV@mail.gmail.com>

On Sun, Oct 24, 2010 at 1:21 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> pkgutil -a | grep libsunperf

OT but I see this so often I have to comment on it once in a while,
you don't need to pipe to grep. Filtering is "built-in".

This works the same: "pgkutil -a libsunperf"

Or "pkgutil -c python perl" and so on.

/peter

From rupert at opencsw.org  Sun Oct 24 18:25:27 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 24 Oct 2010 18:25:27 +0200
Subject: [csw-maintainers] sunwspro path changed again in gar/checkpkg:
 /opt/studio or /opt/SUNWspro ?
Message-ID: <AANLkTi=1UymDnBcgywQxFYeO4W5NpSi3va5KPABgS5rn@mail.gmail.com>

hi,

when upgrading subversion to 1.6.13, checkpkg gives:

* CHECKPKG_OVERRIDES_CSWjavasvn +=
bad-rpath-entry|/opt/studio/SOS12/SUNWspro/lib/rw7|opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0
* Unused Override(u'CSWjavasvn', u'bad-rpath-entry',
u'/opt/SUNWspro/lib/rw7 opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0')

is this correct and the sunwspro package path again changed?

rupert.

From dam at opencsw.org  Sun Oct 24 22:00:10 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 24 Oct 2010 22:00:10 +0200
Subject: [csw-maintainers] sunwspro path changed again in gar/checkpkg:
	/opt/studio or /opt/SUNWspro ?
In-Reply-To: <AANLkTi=1UymDnBcgywQxFYeO4W5NpSi3va5KPABgS5rn@mail.gmail.com>
References: <AANLkTi=1UymDnBcgywQxFYeO4W5NpSi3va5KPABgS5rn@mail.gmail.com>
Message-ID: <71B5691A-3358-44EB-B149-487184206F97@opencsw.org>

Hi Rupert,

Am 24.10.2010 um 18:25 schrieb rupert THURNER:
> when upgrading subversion to 1.6.13, checkpkg gives:
>
> * CHECKPKG_OVERRIDES_CSWjavasvn +=
> bad-rpath-entry|/opt/studio/SOS12/SUNWspro/lib/rw7|opt/csw/lib/svn/ 
> libsvnjavahl-1.so.0.0.0
> * Unused Override(u'CSWjavasvn', u'bad-rpath-entry',
> u'/opt/SUNWspro/lib/rw7 opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0')
>
> is this correct and the sunwspro package path again changed?

Note that I know of :-) Maybe the pathes have been pulled in from some
other config-file from an older build?

BTW, Ben is working on the ap2mod CAS which we should use for
installing the module. I waited with the 1.6.12 release for this,
but it looks like I waited too long now that 1.6.13 is out :-)

Do you have an idea on how to best separate a thin svn client
as requested?


Best regards

   -- Dago


From dam at opencsw.org  Sun Oct 24 22:24:58 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 24 Oct 2010 22:24:58 +0200
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
	<AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
Message-ID: <88CBC755-59F5-4E34-AC68-ADE1EF00244A@opencsw.org>

Hi Maciej,

Am 24.10.2010 um 13:21 schrieb Maciej (Matchek) Blizinski:
> No dia 22 de Outubro de 2010 16:38, Philip Brown <phil at bolthole.com>  
> escreveu:
>> Check the license, and go ahead and make one.
>> You know how to check to see "if we have a package for it  
>> already". :P
>
> Of course! I simply do:
>
> pkgutil -a | grep libsunperf
>
> And voila! We don't have it.
>
> Checked the license:
>
> http://docs.sun.com/source/820-4155/runtime.libraries.html
>
> libsunperf is listed.  The following bit is worrying:
>
> """(g) you agree to defend and indemnify Sun and its licensors from
> and against any damages, costs, liabilities, settlement amounts and/or
> expenses (including attorneys' fees) incurred in connection with any
> claim, lawsuit or action by any third party that arises or results
> from the use or distribution of any and all Programs and/or
> Redistributable."""
>
> What does "you" refer to in this case?  The OpenCSW project, me, or
> something else?

Oh come on, we already have CSWsunpath and CSWss12f95rt
which have the same license. James, see you in jail ;-)


Best regards

   -- Dago



From rupert at opencsw.org  Mon Oct 25 01:21:37 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 25 Oct 2010 01:21:37 +0200
Subject: [csw-maintainers] sunwspro path changed again in gar/checkpkg:
 /opt/studio or /opt/SUNWspro ?
In-Reply-To: <71B5691A-3358-44EB-B149-487184206F97@opencsw.org>
References: <AANLkTi=1UymDnBcgywQxFYeO4W5NpSi3va5KPABgS5rn@mail.gmail.com>
	<71B5691A-3358-44EB-B149-487184206F97@opencsw.org>
Message-ID: <AANLkTikZddUxERpJeV491oOL3FAPh10hCbe3V4dP86ty@mail.gmail.com>

this is where i do not know gar enough ... something like:

./configure \
--without-berkeley-db \
--without-apache \
--without-apxs \
--with-ssl

should build the client.

but i am not sure if one just should split the existing package ...
the client files should be probably the same as built e.g. on debian:
  * http://svn.debian.org/wsvn/pkg-subversion/src/1.6.x/debian/libsvn1.install
  * http://svn.debian.org/wsvn/pkg-subversion/src/1.6.x/debian/subversion.install


On Sun, Oct 24, 2010 at 22:00, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Rupert,
>
> Am 24.10.2010 um 18:25 schrieb rupert THURNER:
>>
>> when upgrading subversion to 1.6.13, checkpkg gives:
>>
>> * CHECKPKG_OVERRIDES_CSWjavasvn +=
>>
>> bad-rpath-entry|/opt/studio/SOS12/SUNWspro/lib/rw7|opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0
>> * Unused Override(u'CSWjavasvn', u'bad-rpath-entry',
>> u'/opt/SUNWspro/lib/rw7 opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0')
>>
>> is this correct and the sunwspro package path again changed?
>
> Note that I know of :-) Maybe the pathes have been pulled in from some
> other config-file from an older build?
>
> BTW, Ben is working on the ap2mod CAS which we should use for
> installing the module. I waited with the 1.6.12 release for this,
> but it looks like I waited too long now that 1.6.13 is out :-)
>
> Do you have an idea on how to best separate a thin svn client
> as requested?
>
>
> 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  Mon Oct 25 05:50:49 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 24 Oct 2010 20:50:49 -0700
Subject: [csw-maintainers] upcoming extention to catalog format:
	SITEFEATURES
In-Reply-To: <20101023.9570900.4027408391@gyor.oxdrove.co.uk>
References: <AANLkTimADbzDtWWqACUxJz-m01edSRpidiFoVg3C2w3x@mail.gmail.com>
	<1287711492-sup-1602@pinkfloyd.chass.utoronto.ca>
	<AANLkTikarmay+Dx1e4Vb=9ujzHiwjUcF_NqG1SRvc3MS@mail.gmail.com>
	<20101023.9570900.4027408391@gyor.oxdrove.co.uk>
Message-ID: <AANLkTimjemJC8hcjkOgciV8JWA4FvMm2nmu670RhTsRL@mail.gmail.com>

well James, the thing is, I've occasionally had the misfortune to be
dealing with a mirror site with reasonable throughput but very very
bad latency.
eliminating a needless new connection was something I really wanted at
those times. so , I coded for it.
and as I said, I'm hoping people can come up with even better
sitefeature suggestions

From phil at bolthole.com  Mon Oct 25 06:15:57 2010
From: phil at bolthole.com (Philip Brown)
Date: Sun, 24 Oct 2010 21:15:57 -0700
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
	<AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
Message-ID: <AANLkTinY5UMpubgS6WX-1GHUBtobo36chKeXoXtBBCW1@mail.gmail.com>

On Sunday, October 24, 2010, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> No dia 22 de Outubro de 2010 16:38, Philip Brown <phil at bolthole.com> escreveu:
>> Check the license, and go ahead and make one.
>> You know how to check to see "if we have a package for it already". :P
>
> Of course! I simply do:
>
> pkgutil -a | grep libsunperf
>
> And voila! We don't have it.


actually, I was referring to doing a search for the file via the web
site search. that's the proper canonical way.

From pfelecan at opencsw.org  Mon Oct 25 09:32:31 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 25 Oct 2010 09:32:31 +0200
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTinY5UMpubgS6WX-1GHUBtobo36chKeXoXtBBCW1@mail.gmail.com>
	(Philip Brown's message of "Sun, 24 Oct 2010 21:15:57 -0700")
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
	<AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
	<AANLkTinY5UMpubgS6WX-1GHUBtobo36chKeXoXtBBCW1@mail.gmail.com>
Message-ID: <x6mxq27mnk.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> On Sunday, October 24, 2010, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> No dia 22 de Outubro de 2010 16:38, Philip Brown <phil at bolthole.com> escreveu:
>>> Check the license, and go ahead and make one.
>>> You know how to check to see "if we have a package for it already". :P
>>
>> Of course! I simply do:
>>
>> pkgutil -a | grep libsunperf
>>
>> And voila! We don't have it.
>
>
> actually, I was referring to doing a search for the file via the web
> site search. that's the proper canonical way.

when you can find the search widget: on the current site I didn't found
it.

-- 
Peter

From phil at bolthole.com  Mon Oct 25 17:54:20 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 25 Oct 2010 08:54:20 -0700
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <x6mxq27mnk.fsf@opencsw.org>
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
	<AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
	<AANLkTinY5UMpubgS6WX-1GHUBtobo36chKeXoXtBBCW1@mail.gmail.com>
	<x6mxq27mnk.fsf@opencsw.org>
Message-ID: <AANLkTikp=-iS=Y-1DMi89qSJ2x=PKqy_1FEycoOMw1p-@mail.gmail.com>

yeah I usually put the URL together manually.
opencsw .org/search

On Monday, October 25, 2010, Peter FELECAN <pfelecan at opencsw.org> wrote:
>>
>>
>> actually, I was referring to doing a search for the file via the web
>> site search. that's the proper canonical way.
>
> when you can find the search widget: on the current site I didn't found
> it.
>
> --
> Peter

From pfelecan at opencsw.org  Mon Oct 25 20:44:32 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 25 Oct 2010 20:44:32 +0200
Subject: [csw-maintainers] A dependency on libsunperf.so.7
In-Reply-To: <AANLkTikp=-iS=Y-1DMi89qSJ2x=PKqy_1FEycoOMw1p-@mail.gmail.com>
	(Philip Brown's message of "Mon, 25 Oct 2010 08:54:20 -0700")
References: <AANLkTikSY9g_=Uo9jF-13d523hrvZ11DLE1iJ6R_0Q7w@mail.gmail.com>
	<AANLkTi=tnTTfXgj2jSSJ2syEFOpc38Bvpfn2-woQuY9y@mail.gmail.com>
	<AANLkTi=v9GD5c+nWiCnvBFHEQx+P0whsbLdzZpnwSS=9@mail.gmail.com>
	<AANLkTinY5UMpubgS6WX-1GHUBtobo36chKeXoXtBBCW1@mail.gmail.com>
	<x6mxq27mnk.fsf@opencsw.org>
	<AANLkTikp=-iS=Y-1DMi89qSJ2x=PKqy_1FEycoOMw1p-@mail.gmail.com>
Message-ID: <x6aam26rjj.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> yeah I usually put the URL together manually.
> opencsw .org/search

On the previous site it was located under the packages list. Maybe
William can fix that or give an explicit access somewhere in a logical
place.

> On Monday, October 25, 2010, Peter FELECAN <pfelecan at opencsw.org> wrote:
>>>
>>>
>>> actually, I was referring to doing a search for the file via the web
>>> site search. that's the proper canonical way.
>>
>> when you can find the search widget: on the current site I didn't found
>> it.
>>
>> --
>> Peter
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
>

-- 
Peter

From phil at bolthole.com  Mon Oct 25 23:43:33 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 25 Oct 2010 14:43:33 -0700
Subject: [csw-maintainers] question on libtool and -xnorunpath
Message-ID: <AANLkTimZyAwkLBA0YnLb+RduXAcHE3NvESUGO=-eoLZo@mail.gmail.com>

I've been messing around with some GNU software at work,and I hit the
following issue:

(when you are starting with a full autoconf ./configure type software
distribution...)
Does anyone know how to coax libtool into accepting -norunpath, JUST
at link time?

The program in question uses, in its makefile,

libtool --mode=link --tag=CXX


I cant just use LDFLAGS=-norunpath, because that would break plain C programs
Putting it in CXXFLAGS "works" (after using our libtool patches). but
it is really annoying with the repeated whines from the compiler,
"CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
ignored otherwise"

Has anyone come up with a better solution?

From dam at opencsw.org  Tue Oct 26 11:09:25 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 26 Oct 2010 11:09:25 +0200
Subject: [csw-maintainers] question on libtool and -xnorunpath
In-Reply-To: <AANLkTimZyAwkLBA0YnLb+RduXAcHE3NvESUGO=-eoLZo@mail.gmail.com>
References: <AANLkTimZyAwkLBA0YnLb+RduXAcHE3NvESUGO=-eoLZo@mail.gmail.com>
Message-ID: <E08F798D-3240-4915-A8F7-06023234E417@opencsw.org>

Hi Phil,

Am 25.10.2010 um 23:43 schrieb Philip Brown <phil at bolthole.com>:

> I've been messing around with some GNU software at work,and I hit the
> following issue:
> 
> (when you are starting with a full autoconf ./configure type software
> distribution...)
> Does anyone know how to coax libtool into accepting -norunpath, JUST
> at link time?
> 
> The program in question uses, in its makefile,
> 
> libtool --mode=link --tag=CXX
> 
> 
> I cant just use LDFLAGS=-norunpath, because that would break plain C programs
> Putting it in CXXFLAGS "works" (after using our libtool patches). but
> it is really annoying with the repeated whines from the compiler,
> "CC: Warning: Option -xnorunpath passed to ld, if ld is invoked,
> ignored otherwise"
> 
> Has anyone come up with a better solution?

It is easiest to set CXX=.../CC -norunpath

I changed it this way in gar and it works quite well. Patching ltmain.sh works but is tedious.

Best regards

  -- Dago

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

From phil at bolthole.com  Tue Oct 26 18:08:54 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 26 Oct 2010 09:08:54 -0700
Subject: [csw-maintainers] question on libtool and -xnorunpath
In-Reply-To: <E08F798D-3240-4915-A8F7-06023234E417@opencsw.org>
References: <AANLkTimZyAwkLBA0YnLb+RduXAcHE3NvESUGO=-eoLZo@mail.gmail.com>
	<E08F798D-3240-4915-A8F7-06023234E417@opencsw.org>
Message-ID: <AANLkTikQC204PHjHVvj6tc-t7PvS0=8ow35OCOAxkEOM@mail.gmail.com>

On 10/26/10, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,
>
> .....

*wave*


> It is easiest to set CXX=.../CC -norunpath
>
> I changed it this way in gar and it works quite well. Patching ltmain.sh
> works but is tedious.


Thanks for the suggestion.

it turns out, that my original suggestion did not completely work.
and even setting CXX=CC -norunpath, did not work either.
The #@$#@ thing strips out the arguments to CXX ? !!!
(configure, it would seem)

Even patching ltmain.sh did not work for 100% of the tree!

I ended up doing a combination of patching the generated libtool, and
hacking the generated config.status and forcing a re-run of that.
(both patches were to force CXX=CC - norunpath)


Euuuuchhh....

From phil at bolthole.com  Tue Oct 26 18:29:26 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 26 Oct 2010 09:29:26 -0700
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <E08DF394-5CF1-4702-B9B7-36B261D1A0DC@opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTinACzX-82YO5MJODKFAFSc8XJEL4Y0V3TzN578n@mail.gmail.com>
	<AANLkTi=pERR_TmUApjRt=7aZDnpXTGUnnS5mQx3zCUYX@mail.gmail.com>
	<E08DF394-5CF1-4702-B9B7-36B261D1A0DC@opencsw.org>
Message-ID: <AANLkTi=XOvMLMqZMmWbwvbcDvk782ZQo9-Rz2vMrsvC0@mail.gmail.com>

On 10/23/10, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,

*wave*

>....
>> - means maintainers might have to occasionally do a little extra
>> searching... ONE TIME,
>>   until then they put in the dependency lines, and then they'll know
>> where to go from then on.
>
> - this search has to be done *by every user* who wants to install the
>    package

users dont tend to choose to install the packages we're talking about.
They just install actual user-level software, which happens to pull in the
stupidly-ugly-long::we-love-modules::Cause-its-cool named dependancies.

Users install "bacula" or "lighttpd" or "firefox".

From pfelecan at opencsw.org  Tue Oct 26 19:07:08 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 26 Oct 2010 19:07:08 +0200
Subject: [csw-maintainers] Packaging gems and package naming conventions
In-Reply-To: <AANLkTi=XOvMLMqZMmWbwvbcDvk782ZQo9-Rz2vMrsvC0@mail.gmail.com>
	(Philip Brown's message of "Tue, 26 Oct 2010 09:29:26 -0700")
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
	<44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org>
	<AANLkTimownR_HgFpDWHDnHBb3qW9Cyf4GtUB7GhajvnL@mail.gmail.com>
	<AANLkTik3dsQ04Q7HL8ijVunXgc6LVTwru4p2YZBRky45@mail.gmail.com>
	<AANLkTikCCPKmGqv3ykrYbUgKJNZWZO-NAECbDTRCxzZu@mail.gmail.com>
	<20101021091105.5321F33F@mail.opencsw.org>
	<849C8EE8-FABF-4599-96D3-3ED36E7D5827@opencsw.org>
	<AANLkTinACzX-82YO5MJODKFAFSc8XJEL4Y0V3TzN578n@mail.gmail.com>
	<AANLkTi=pERR_TmUApjRt=7aZDnpXTGUnnS5mQx3zCUYX@mail.gmail.com>
	<E08DF394-5CF1-4702-B9B7-36B261D1A0DC@opencsw.org>
	<AANLkTi=XOvMLMqZMmWbwvbcDvk782ZQo9-Rz2vMrsvC0@mail.gmail.com>
Message-ID: <x662woq3wj.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> On 10/23/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>> Hi Phil,
>
> *wave*
>
>>....
>>> - means maintainers might have to occasionally do a little extra
>>> searching... ONE TIME,
>>>   until then they put in the dependency lines, and then they'll know
>>> where to go from then on.
>>
>> - this search has to be done *by every user* who wants to install the
>>    package
>
> users dont tend to choose to install the packages we're talking about.
> They just install actual user-level software, which happens to pull in the
> stupidly-ugly-long::we-love-modules::Cause-its-cool named dependancies.
>
> Users install "bacula" or "lighttpd" or "firefox".

There are users and users. Some of them are a little bit more
sophisticated that what you imagine...
-- 
Peter

From kester at bender.opencsw.org  Wed Oct 27 10:49:04 2010
From: kester at bender.opencsw.org (Kester Habermann)
Date: Wed, 27 Oct 2010 10:49:04 +0200
Subject: [csw-maintainers] package naming conventions for addons to other
	packages
Message-ID: <20101027084904.GA155@bender.opencsw.org>

Hello,

I wanted to package django-auth-ldap[1] which is an package that may
be using together with Django. I come up with the following name:
  GARNAME = django-auth-ldap
  PACKAGES = CSWpy-django-auth-ldap
  CATALOGNAME = py_django_auth_ldap
checkpkg tells me the name is too long and suggests using
CHECKPKG_OVERRIDES_CSWpy-django-auth-ldap += pkgname-too-long

Any suggestions on how to name such packages to indicate
that they are an extension to something else. Or should
I just put in the override?


Best Regards

Kester


[1] http://pypi.python.org/pypi/django-auth-ldap/

From pfelecan at opencsw.org  Wed Oct 27 11:54:01 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 27 Oct 2010 11:54:01 +0200
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <20101027084904.GA155@bender.opencsw.org> (Kester Habermann's
	message of "Wed, 27 Oct 2010 10:49:04 +0200")
References: <20101027084904.GA155@bender.opencsw.org>
Message-ID: <x6tyk8nepy.fsf@opencsw.org>

Kester Habermann <kester at bender.opencsw.org> writes:

> Hello,
>
> I wanted to package django-auth-ldap[1] which is an package that may
> be using together with Django. I come up with the following name:
>   GARNAME = django-auth-ldap
>   PACKAGES = CSWpy-django-auth-ldap
>   CATALOGNAME = py_django_auth_ldap
> checkpkg tells me the name is too long and suggests using
> CHECKPKG_OVERRIDES_CSWpy-django-auth-ldap += pkgname-too-long
>
> Any suggestions on how to name such packages to indicate
> that they are an extension to something else. Or should
> I just put in the override?

The issue is with the package name, i.e., CSWpy-django-auth-ldap, which
is longer that the current, arbitrary, limit on package names. Using the
override is an useful kludge but not a definitive/final solution. As we
discussed earlier, we must relive all arbitrary limits an conform to the
reality of the underlying package system. However, as so often, that
discussion was drown in noise and the status quo is maintained for a
dubious aesthetic consideration.
-- 
Peter

From bwalton at opencsw.org  Wed Oct 27 13:30:59 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 27 Oct 2010 07:30:59 -0400
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <x6tyk8nepy.fsf@opencsw.org>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
Message-ID: <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter FELECAN's message of Wed Oct 27 05:54:01 -0400 2010:

> reality of the underlying package system. However, as so often, that
> discussion was drown in noise and the status quo is maintained for a
> dubious aesthetic consideration.

+1 for removing the arbitrary limit.  If the pkg* tools can handle it,
so should we.

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


From pfelecan at opencsw.org  Wed Oct 27 13:54:50 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 27 Oct 2010 13:54:50 +0200
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <1288179019-sup-4933@pinkfloyd.chass.utoronto.ca> (Ben Walton's
	message of "Wed, 27 Oct 2010 07:30:59 -0400")
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
Message-ID: <x6pquvonp1.fsf@opencsw.org>

Ben Walton <bwalton at opencsw.org> writes:

> Excerpts from Peter FELECAN's message of Wed Oct 27 05:54:01 -0400 2010:
>
>> reality of the underlying package system. However, as so often, that
>> discussion was drown in noise and the status quo is maintained for a
>> dubious aesthetic consideration.
>
> +1 for removing the arbitrary limit.  If the pkg* tools can handle it,
> so should we.

The significant limit as supported by the packaging system:

#             pkginfo tag: NAME
#             CSW concept: SOFTWARENAME
#
#             Text that specifies the package name (maximum length of
# 			  256 ASCII characters).

This must me implemented as decided during this summer technical
summit. I'm asking the community to act on this pragmatically.

Thank you in advance
-- 
Peter

From phil at bolthole.com  Wed Oct 27 16:36:39 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 27 Oct 2010 07:36:39 -0700
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <x6pquvonp1.fsf@opencsw.org>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
Message-ID: <AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>

On Wednesday, October 27, 2010, Peter FELECAN <pfelecan at opencsw.org>
>
> This must me implemented as decided during this summer technical
> summit. I'm asking the community to act on this pragmatically.
>

"must"??

first of all, the summer meeting did not constitute any binding
authority. it was certainly not advertised as such.

secondly, you invoke "the community": however, "the community" has not
been involved in this. merely a subset of maintainers. not even all
maintainers have authoritatively been polled.

From maciej at opencsw.org  Wed Oct 27 16:43:12 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Wed, 27 Oct 2010 15:43:12 +0100
Subject: [csw-maintainers] The purpose and function of OpenCSW camps
Message-ID: <AANLkTikd46a-ZGjxwYypLKg3vWQJ7woJM9KNLodN5B+i@mail.gmail.com>

No dia 27 de Outubro de 2010 15:36, Philip Brown <phil at bolthole.com> escreveu:
> first of all, the summer meeting did not constitute any binding
> authority. it was certainly not advertised as such.
>
> secondly, you invoke "the community": however, "the community" has not
> been involved in this. merely a subset of maintainers. (...)

This is the second time you raise this.  If the camps have no
authority and are only a mere subset of maintainers, why do we spend
our time and money attending them?

Maciej

From bwalton at opencsw.org  Wed Oct 27 16:46:06 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 27 Oct 2010 10:46:06 -0400
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
Message-ID: <1288190728-sup-2386@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Wed Oct 27 10:36:39 -0400 2010:

> secondly, you invoke "the community": however, "the community" has
> not been involved in this. merely a subset of maintainers. not even
> all maintainers have authoritatively been polled.

Anyone (save yourself) that has piped up has been in favour of
extending the limits though...

Thanks
-Ben

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


From pfelecan at opencsw.org  Wed Oct 27 18:15:28 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 27 Oct 2010 18:15:28 +0200
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	(Philip Brown's message of "Wed, 27 Oct 2010 07:36:39 -0700")
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
Message-ID: <x68w1jobmn.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> On Wednesday, October 27, 2010, Peter FELECAN <pfelecan at opencsw.org>
>>
>> This must me implemented as decided during this summer technical
>> summit. I'm asking the community to act on this pragmatically.
>>
>
> "must"??

Must vs should.

> first of all, the summer meeting did not constitute any binding
> authority. it was certainly not advertised as such.

And who's the "binding authority" in a community?

> secondly, you invoke "the community": however, "the community" has not
> been involved in this. merely a subset of maintainers. not even all
> maintainers have authoritatively been polled.

Alright then I'm asking for a vote on this issue.

By the way, the community, as in the C of OCSW is formed by
maintainers. I am one. You are also one of them and have no binding
authority. I'm saying this by drawing a line in the sand...

-- 
Peter

From bwalton at opencsw.org  Thu Oct 28 01:51:52 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 27 Oct 2010 19:51:52 -0400
Subject: [csw-maintainers] apache2 vs CAS
Message-ID: <1288223176-sup-4964@pinkfloyd.chass.utoronto.ca>


Hi All,

When I initially added cswap2mod CAS to cswclassutils, there were
comments indicating that it shouldn't go there.  I moved it directly
into CSWapache2.  Now, it's biting people with sparse root zones.

So, my thoughts are:

1. Move the scripts back into cswclassutils.
2. Release the updated cswclassutils that is actually a package per
   script pair.

This will still apply pain to those that run with sparse root zones,
but only if they install a package the requires CSWcas-ap2mod.  Of the
default apache package set, that would only be CSWap2suexec.

The only think I don't particularly like here is that the cswap2mod
scripts rely on apxs which isn't available without apache.  Anything
setting a CAS to cswap2mod though should depend on apache, which
provides that, so it's not the end of the world...this could be
handled by checkpkg.

Thoughts?

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


From james at opencsw.org  Thu Oct 28 10:28:30 2010
From: james at opencsw.org (James Lee)
Date: Thu, 28 Oct 2010 08:28:30 GMT
Subject: [csw-maintainers] apache2 vs CAS
In-Reply-To: <1288223176-sup-4964@pinkfloyd.chass.utoronto.ca>
References: <1288223176-sup-4964@pinkfloyd.chass.utoronto.ca>
Message-ID: <20101028.8283000.3245596942@gyor.oxdrove.co.uk>

On 28/10/10, 00:51:52, Ben Walton <bwalton at opencsw.org> wrote regarding
[csw-maintainers] apache2 vs CAS:

> When I initially added cswap2mod CAS to cswclassutils, there were
> comments indicating that it shouldn't go there.  I moved it directly
> into CSWapache2.  Now, it's biting people with sparse root zones.

Use an existing class, probably build[1], then you put nothing of
your own in /usr.

Deliver the files as normal, not with an action on the module as you
attempt now, and use an e build for the modified files.  Notional
only...

f none  /opt/csw/apache2/libexec/libphp5.so
e build /opt/csw/apache2/etc/http.conf

and deliver the apxs commands in http.conf.

!install
$APXS -e $enmod -n $MODNAME $MODFILE

!remove
$APXS -e -A -n $MODNAME $MODFILE




James.


1. http://docs.sun.com/app/docs/doc/817-0406/ch3enhancepkg-39

From phil at bolthole.com  Thu Oct 28 18:09:03 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 28 Oct 2010 09:09:03 -0700
Subject: [csw-maintainers] apache2 vs CAS
In-Reply-To: <20101028.8283000.3245596942@gyor.oxdrove.co.uk>
References: <1288223176-sup-4964@pinkfloyd.chass.utoronto.ca>
	<20101028.8283000.3245596942@gyor.oxdrove.co.uk>
Message-ID: <AANLkTi=L9OQ1sZNpDuEf0hCx5Ahz3wrJxS_4k22vWUzK@mail.gmail.com>

On 10/28/10, James Lee <james at opencsw.org> wrote:
> On 28/10/10, 00:51:52, Ben Walton <bwalton at opencsw.org> wrote regarding
> [csw-maintainers] apache2 vs CAS:
>
>> When I initially added cswap2mod CAS to cswclassutils, there were
>> comments indicating that it shouldn't go there.  I moved it directly
>> into CSWapache2.  Now, it's biting people with sparse root zones.
>
> Use an existing class, probably build[1], then you put nothing of
> your own in /usr.
>[...]
>
> and deliver the apxs commands in http.conf.
>
> !install
> $APXS -e $enmod -n $MODNAME $MODFILE
>
> !remove
> $APXS -e -A -n $MODNAME $MODFILE
>
> 1. http://docs.sun.com/app/docs/doc/817-0406/ch3enhancepkg-39
>

Neat trick.

But I wonder how it will work with sparse zones?

For something with "same config across zones", that would work great.
But with something such as apache, that presumes DIFFERENT configs in each zone
(even though the binaries would be shared), how well will this work?

Might work fine -- pkgadd may call the build action on zone-unique
file --  but needs to be tested to make sure.

From jon.craig at craigslanding.net  Thu Oct 28 18:02:58 2010
From: jon.craig at craigslanding.net (Jonathan Craig)
Date: Thu, 28 Oct 2010 12:02:58 -0400
Subject: [csw-maintainers] Package submission process
Message-ID: <AANLkTimcrR06c_-w_G4WegVqQS5r9sPBuE6D8r6aAhnr@mail.gmail.com>

I'm a new maintainer and I'm stumbling my way through learning to
build/submit packages.  My first project was to build and submit the
perl module "Net::Syslog".  I have a successful "gmake package" that
created a file "pm_netsyslog-0.04,REV=2010.10.27-SunOS5.9-all-UNCOMMITTED.pkg.gz".
 I also ran a "gmake submitpkg", but what if anything it accomplished
I don't know.  Is there a current source of information describing the
model build/test/submit process?

Thanks,

Jon Craig

From maciej at opencsw.org  Thu Oct 28 20:24:51 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 28 Oct 2010 19:24:51 +0100
Subject: [csw-maintainers] Package submission process
In-Reply-To: <AANLkTimcrR06c_-w_G4WegVqQS5r9sPBuE6D8r6aAhnr@mail.gmail.com>
References: <AANLkTimcrR06c_-w_G4WegVqQS5r9sPBuE6D8r6aAhnr@mail.gmail.com>
Message-ID: <AANLkTi=5JQSpz57ScvYHOjF0utUg67u9GjrQ_keHDOGn@mail.gmail.com>

No dia 28 de Outubro de 2010 17:02, Jonathan Craig
<jon.craig at craigslanding.net> escreveu:
> I'm a new maintainer and I'm stumbling my way through learning to
> build/submit packages. ?My first project was to build and submit the
> perl module "Net::Syslog". ?I have a successful "gmake package" that
> created a file "pm_netsyslog-0.04,REV=2010.10.27-SunOS5.9-all-UNCOMMITTED.pkg.gz".
> ?I also ran a "gmake submitpkg", but what if anything it accomplished
> I don't know. ?Is there a current source of information describing the
> model build/test/submit process?

Look at http://wiki.opencsw.org/maintainer-tools

"gmake submitpkg" is different from "submitpkg", in that "gmake
submitpkg" does not submit a package, only tags it in subversion.

The build/test/submit model is largely informal.  It's up to you to
decide how much testing you need for your package.  It's also up to
you to find people to test your package.  When you're satisfied with
testing, you can use submitpkg to send you package to the release
manager.

I'm not entirely happy with this model, but I don't see any easy way
of improving it.  Suggestions are welcome!

Maciej

From phil at bolthole.com  Thu Oct 28 23:39:19 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 28 Oct 2010 14:39:19 -0700
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <x68w1jobmn.fsf@opencsw.org>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
Message-ID: <AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>

On 10/27/10, Peter FELECAN <pfelecan at opencsw.org> wrote:
> Philip Brown <phil at bolthole.com> writes:
>...
>> secondly, you invoke "the community": however, "the community" has not
>> been involved in this. merely a subset of maintainers. not even all
>> maintainers have authoritatively been polled.
>
> Alright then I'm asking for a vote on this issue.
>

That is certainly a better course of action, than a subset of
maintainers having a meeting, that discriminates against other
maintainers by force of physical location, and then declaring "things
'must' change".

However, you are still not being properly considerate of the full community.
The "community" affected here, is the ENTIRE OpenCSW community: both
maintainers *and* users.
Therefore, we should prepare a proper poll that allows for full
participation of the entire community affected.

The poll wording needs to also be openly reviewed for some period of
time, to ensure inclusiveness and fairness.

Are you volunteering to write the initial wording, or are you
requesting someone else draft it?

From bwalton at opencsw.org  Fri Oct 29 01:23:13 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 28 Oct 2010 19:23:13 -0400
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
Message-ID: <1288308110-sup-8945@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Oct 28 17:39:19 -0400 2010:

> However, you are still not being properly considerate of the full community.
> The "community" affected here, is the ENTIRE OpenCSW community: both
> maintainers *and* users.

Seriously?  That would be like Debian polling the audience before
making a change in apt or dpkg.  It's ridiculous.

A vote is good and I support that, but it's a maintainer decision, not
a user one.

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


From bwalton at opencsw.org  Fri Oct 29 02:40:12 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 28 Oct 2010 20:40:12 -0400
Subject: [csw-maintainers] apache2 vs CAS
In-Reply-To: <20101028.8283000.3245596942@gyor.oxdrove.co.uk>
References: <1288223176-sup-4964@pinkfloyd.chass.utoronto.ca>
	<20101028.8283000.3245596942@gyor.oxdrove.co.uk>
Message-ID: <1288312748-sup-5372@pinkfloyd.chass.utoronto.ca>

Excerpts from James Lee's message of Thu Oct 28 04:28:30 -0400 2010:

Hi James,

> Use an existing class, probably build[1], then you put nothing of
> your own in /usr.

I was unaware of this functionality.  I'll look into it.  It just
might do what I want/need.

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


From kester at opencsw.org  Fri Oct 29 09:00:33 2010
From: kester at opencsw.org (Kester Habermann)
Date: Fri, 29 Oct 2010 09:00:33 +0200
Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs
	py_django_auth_ldap, py_django_filter(...)
In-Reply-To: <AANLkTinc+WwzNVV1WqueektRs+o0kN+L06-YCYFptk8K@mail.gmail.com>
References: <20101028152414.D4D7B507@mail.opencsw.org>
	<AANLkTinc+WwzNVV1WqueektRs+o0kN+L06-YCYFptk8K@mail.gmail.com>
Message-ID: <20101029070033.GA27127@bender.opencsw.org>

Hi,

On Thu, Oct 28, 2010 at 02:47:15PM -0700, Philip Brown wrote:
> On 10/28/10, Kester Habermann <kester at opencsw.org> wrote:
> >
> >
> > * py_django_auth_ldap: new package
> >   + py_django_auth_ldap-1.0.6,REV=2010.10.27-SunOS5.9-all-CSW.pkg.gz
> >
> 
> longer than allowed name length contraints.
> Cant accept even if I wanted to, as things stand. Database limits are
> set at 20 chars right now.

As I'm new here, I'm not aksing you to make changes for me. I didn't
know which overrides were acceptable and which weren't and I could have
truncated the name making it barely readable.

Before submitting the package I raised the issue of the limit on the
maintainers list. The general advice I got, was to go ahead wth the
override.  It was not pointed out to me that this would be a show
stopper for accepting the package. If I had known this from the start,
I would not have submitted an "invalid" package.

Making a database field longer should not be problematic or cause data loss.
Something like "ALTER TABLE tablename ALTER COLUMN pkgname TYPE VARCHAR(255);"
should do the job.


Best Regards

Kester

From pfelecan at opencsw.org  Fri Oct 29 11:56:43 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 29 Oct 2010 11:56:43 +0200
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
	(Philip Brown's message of "Thu, 28 Oct 2010 14:39:19 -0700")
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
Message-ID: <x6r5f9miec.fsf@opencsw.org>

Philip Brown <phil at bolthole.com> writes:

> On 10/27/10, Peter FELECAN <pfelecan at opencsw.org> wrote:
>> Philip Brown <phil at bolthole.com> writes:
>>...
>>> secondly, you invoke "the community": however, "the community" has not
>>> been involved in this. merely a subset of maintainers. not even all
>>> maintainers have authoritatively been polled.
>>
>> Alright then I'm asking for a vote on this issue.
>>
>
> That is certainly a better course of action, than a subset of
> maintainers having a meeting, that discriminates against other
> maintainers by force of physical location, and then declaring "things
> 'must' change".

The subset that you mention is composed of 2 board members and the most
active/involved maintainers. I agree that the physical location is an
issue but the meeting was covered by a real-time video stream and a very
detailed discussion which was open to participation. If I'm remembering
correctly you haven't participated in that discussion.

> However, you are still not being properly considerate of the full community.
> The "community" affected here, is the ENTIRE OpenCSW community: both
> maintainers *and* users.

I agree that the users are part of the community, in the large sense of
the word, but with regard to maintenance decisions only maintainers has
a vote; moreover, I consider that only the active foundation maintainers
have a voting right.

> Therefore, we should prepare a proper poll that allows for full
> participation of the entire community affected.
>
> The poll wording needs to also be openly reviewed for some period of
> time, to ensure inclusiveness and fairness.

This is another example of your systematic strategy of drowning a
subject on which you don't agree in noise.

> Are you volunteering to write the initial wording, or are you
> requesting someone else draft it?

Very simple:

Do you, as an active foundation maintainer, agree to relive the current
limit of packages name from the current 20 characters to the 256
characters defined by the current packaging system?

I'm asking all the active foundation maintainers to vote on this issue.

Thank you in advance,

For your information: this is the significant limit as supported by the
packaging system:

 pkginfo tag: NAME
 CSW concept: SOFTWARENAME

 Text that specifies the package name (maximum length of
 256 ASCII characters).

-- 
Peter

From bwalton at opencsw.org  Fri Oct 29 14:54:45 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 29 Oct 2010 08:54:45 -0400
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <x6r5f9miec.fsf@opencsw.org>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
	<x6r5f9miec.fsf@opencsw.org>
Message-ID: <1288356816-sup-3432@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter FELECAN's message of Fri Oct 29 05:56:43 -0400 2010:

> Do you, as an active foundation maintainer, agree to relive the
> current limit of packages name from the current 20 characters to the
> 256 characters defined by the current packaging system?

I agree that the limit should be raised to be 256 as per the
underlying system limits.

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


From phil at bolthole.com  Fri Oct 29 19:02:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 29 Oct 2010 10:02:29 -0700
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <1288356816-sup-3432@pinkfloyd.chass.utoronto.ca>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
	<x6r5f9miec.fsf@opencsw.org>
	<1288356816-sup-3432@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTi=endNN1SWHGH+BSRmBDXmCOg2oE23jUt9k8n7g@mail.gmail.com>

On 10/29/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Peter FELECAN's message of Fri Oct 29 05:56:43 -0400 2010:
>
>> Do you, as an active foundation maintainer, agree to relive the
>> current limit of packages name from the current 20 characters to the
>> 256 characters defined by the current packaging system?
>
> I agree that the limit should be raised to be 256 as per the
> underlying system limits.
>

has anyone verified whether the limit is 256 chars under solaris 9?
I think it was only checked under sol10

From bwalton at opencsw.org  Fri Oct 29 19:09:14 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 29 Oct 2010 13:09:14 -0400
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <AANLkTi=endNN1SWHGH+BSRmBDXmCOg2oE23jUt9k8n7g@mail.gmail.com>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
	<x6r5f9miec.fsf@opencsw.org>
	<1288356816-sup-3432@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=endNN1SWHGH+BSRmBDXmCOg2oE23jUt9k8n7g@mail.gmail.com>
Message-ID: <1288372129-sup-9112@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Oct 29 13:02:29 -0400 2010:

> has anyone verified whether the limit is 256 chars under solaris 9?
> I think it was only checked under sol10

Yes.  It's 256 (identical text to what Peter F posted).

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


From phil at bolthole.com  Fri Oct 29 19:21:23 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 29 Oct 2010 10:21:23 -0700
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
In-Reply-To: <x6r5f9miec.fsf@opencsw.org>
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
	<x6r5f9miec.fsf@opencsw.org>
Message-ID: <AANLkTinkSq4m=cVjmnze2M4FhkFLJFFsjRw-xesq4n7L@mail.gmail.com>

On 10/29/10, Peter FELECAN <pfelecan at opencsw.org> wrote:
>
>> Are you volunteering to write the initial wording, or are you
>> requesting someone else draft it?
>
> Very simple:
>
> Do you, as an active foundation maintainer, agree to relive the current
> limit of packages name from the current 20 characters to the 256
> characters defined by the current packaging system?

It's NOT that simple.
That 256 char limit is for the "NAME" field.

We use that "NAME" field, as the normal "description" alongside the
"software name".
We should reserve at least SOME of that space, for the description.
Remember, the format is

NAME=softname - Brief Description of software goes here

*Also*...
I'm presuming that you also like strong correlation between "software
name" and "package name"

ie:  softwarename => CSWsoftwarename


If the CSWxxx field also has a limit of 256, that means we need to
limit our "softwarename" to be 253, just to be strictly correct.
But if the CSWxxx field has to be smaller... then guess what? either
the software name must be smaller, or you lose the strong correlation.

AAAAnnnd.... surprise... even in solaris 10, it has to be smaller than
256 chars. A *lot* smaller.



from pkginfo(4)
     PKG
   Abbreviation for the package being installed.
   ....
   The abbreviation is limited to a maximum  length  of  32 characters.

Which means that the "software name" can only be a maximum of 29
chars. presuming that you DO want to preserve "strong correlation".

From pfelecan at opencsw.org  Sat Oct 30 16:55:16 2010
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 30 Oct 2010 16:55:16 +0200
Subject: [csw-maintainers] package naming conventions for addons to
	other packages
References: <20101027084904.GA155@bender.opencsw.org>
	<x6tyk8nepy.fsf@opencsw.org>
	<1288179019-sup-4933@pinkfloyd.chass.utoronto.ca>
	<x6pquvonp1.fsf@opencsw.org>
	<AANLkTin9vemZERxR=6rcGzF8heeDTr70uuBnf+LyL39N@mail.gmail.com>
	<x68w1jobmn.fsf@opencsw.org>
	<AANLkTi=f-LxveMX_0A+RAxL_7tgtsASDyo2NhBfVRNao@mail.gmail.com>
	<x6r5f9miec.fsf@opencsw.org>
	<AANLkTinkSq4m=cVjmnze2M4FhkFLJFFsjRw-xesq4n7L@mail.gmail.com>
Message-ID: <x6bp6bn31n.fsf@acm.org>

Philip Brown <phil at bolthole.com> writes:

> On 10/29/10, Peter FELECAN <pfelecan at opencsw.org> wrote:
>>
>>> Are you volunteering to write the initial wording, or are you
>>> requesting someone else draft it?
>>
>> Very simple:
>>
>> Do you, as an active foundation maintainer, agree to relive the current
>> limit of packages name from the current 20 characters to the 256
>> characters defined by the current packaging system?
>
> It's NOT that simple.
> That 256 char limit is for the "NAME" field.
>
> We use that "NAME" field, as the normal "description" alongside the
> "software name".
> We should reserve at least SOME of that space, for the description.
> Remember, the format is
>
> NAME=softname - Brief Description of software goes here
>
> *Also*...
> I'm presuming that you also like strong correlation between "software
> name" and "package name"
>
> ie:  softwarename => CSWsoftwarename
>
>
> If the CSWxxx field also has a limit of 256, that means we need to
> limit our "softwarename" to be 253, just to be strictly correct.
> But if the CSWxxx field has to be smaller... then guess what? either
> the software name must be smaller, or you lose the strong correlation.
>
> AAAAnnnd.... surprise... even in solaris 10, it has to be smaller than
> 256 chars. A *lot* smaller.
>
>
>
> from pkginfo(4)
>      PKG
>    Abbreviation for the package being installed.
>    ....
>    The abbreviation is limited to a maximum  length  of  32 characters.
>
> Which means that the "software name" can only be a maximum of 29
> chars. presuming that you DO want to preserve "strong correlation".
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
>

Given:

uname -a
SunOS current9x 5.9 Generic_122301-52 i86pc i386 i86pc Solaris

man -s4 pkginfo

[...]
NAME  Text that specifies the package name  (maximum  length

SunOS 5.9           Last change: 19 Feb 2003                    1

File Formats                                           pkginfo(4)

           of  256  ASCII  characters). Use the NAME parameter as
           the foundation for describing  the  functionality  and
           purpose  of  the  package;  spell out any acronyms and
           avoid internal product/project code  names.  The  DESC
           parameter  can  then be used to expand the descriptive
           information.  Use  the  NAME  parameter  to  state  as
           specifically as possible the use of the package, why a
           user would need to load it, and so on.

     PKG   Abbreviation for  the  package  being  installed.  All
           characters  in  the abbreviation must be alphanumeric.
           You can also use the - and + characters in the  abbre-
           viation.   The  first character cannot be numeric, a +
           or a -.

           The abbreviation is limited to a maximum length of  32
           characters.  install, new, and all are reserved abbre-
           viations. It is  customary  to  make  the  first  four
           letters  unique to your company, such as the company's
           stock symbol.
[...]

Then:

A package name, i.e CSWsoftwarename, could have 29 characters as a
limit, the CSW prefix taking the remaining 3 characters.

This is confirmed in
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libadm/common/pkgnmchk.c

114 	} else if (count > NON_ABI_NAMELNGTH)

where

 51 #define	NON_ABI_NAMELNGTH	32

and by experiment.

Remark: For a fully Solaris 10 installed system, there is the package
        SUNWevolution-socs-connect-share having PKG length of 32
        characters.

In conclusion, the current limits for our packages are arbitrarily fixed
at 20 when the system limit is 32.

Thus, here is the reformulated call for vote:

Do you, as an active foundation maintainer, agree to relive the current
limit of packages name from the current 20 characters to the 32
characters defined by the current packaging system?

-- 
Peter

From rupert at opencsw.org  Sun Oct 31 11:11:56 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 31 Oct 2010 11:11:56 +0100
Subject: [csw-maintainers] samba: file sparcv8: open failed: No such file or
	directory
Message-ID: <AANLkTintwNozbk2ipNae0mO2tX4_vWdWoqXkkrffFaiP@mail.gmail.com>

hi,

somebody of you did already see this error message?

creating /home/rupert/mgar/pkg/samba/trunk/work/solaris9-sparc/build-isa-sparcv8/samba-3.4.9/source3/exports/libtalloc.syms
Linking shared library bin/libtalloc.so.1
ld: fatal: file sparcv8: open failed: No such file or directory
ld: fatal: file sparcv8: open failed: No such file or directory
ld: fatal: File processing errors. No output written to bin/libtalloc.so.1
gmake[3]: *** [bin/libtalloc.so.1] Error 1

rupert.