From maciej at opencsw.org  Thu Jul  1 04:42:42 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 1 Jul 2010 03:42:42 +0100
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>

No dia 30 de Junho de 2010 21:31, Ben Walton <bwalton at opencsw.org> escreveu:
> Excerpts from William Bonnet's message of Wed Jun 30 16:21:51 -0400 2010:
>
> Hi William,
>
>> Would it be possible to display *all* the missing packages instead
>> of outputing the first missing package and exiting ?
>
> I wonder if we shouldn't just have it look for CSWgar-dev, which
> depends on all gar build deps and leave it at that?

I think that William had package-specific build time dependencies in mind.

As a general approach, I think that we could start offloading bits of
functionality from Make to separate executables.  For example:
gar/bin/build-time-dep-test <list of deps>.

The choice would largely depend on language expressiveness.  If it's
easy to clean to code in Make, fine.  If it's not, write a separate
tool in a language of choice (shell/Perl/Python) and call it from
Make.

From phil at bolthole.com  Thu Jul  1 04:55:59 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 30 Jun 2010 19:55:59 -0700
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
Message-ID: <AANLkTin_Jghs20JgHACuHRqukKn19vLiaJTFHdgTTVKg@mail.gmail.com>

On Wednesday, June 30, 2010, Maciej (Matchek) Blizinski <maciej at opencsw.org>
....
>> I wonder if we shouldn't just have it look for e dependencies in mind.
>
> As a general approach, I think that we could start offloading bits of
> functionality from Make to separate executables. ?For example:
> gar/bin/build-time-dep-test <list of deps>.
>

oh pleease yes!
then someday we could make a normal package out of gar.
make is very powerfull, but it's not really supposed to be a
programming language directly.
( reminds me of the old tech joke; emacs is a fine operating system,
but I prefer unix)

and please, make it a language that comes with a standard solaris core install

From william at wbonnet.net  Thu Jul  1 10:14:29 2010
From: william at wbonnet.net (William Bonnet)
Date: Thu, 1 Jul 2010 10:14:29 +0200
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
Message-ID: <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>

Hi

> I think that William had package-specific build time dependencies in mind.

In fact i was in front of the following package

gmake package
pkg A is missing !
sudo pkgutil -y -i A

gmake package
pkg B is missing !
sudo pkgutil -y -i B

gmake package
pkg C is missing !
sudo pkgutil -y -i C

weellll how much more ? ...   it's gonna be a long way until Z ;) 

since all are defined in the Makefile, i was wishing to have all missing prereqs output at once. 

even better, to have a target to install all missing prereqs

and even much more better, to have both ;)

cheers
W.

From bwalton at opencsw.org  Thu Jul  1 14:17:39 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 01 Jul 2010 08:17:39 -0400
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
Message-ID: <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>

Excerpts from William Bonnet's message of Thu Jul 01 04:14:29 -0400 2010:

Hi William,

> since all are defined in the Makefile, i was wishing to have all
> missing prereqs output at once.

I just added check_for_deps to gar/bin.  It's perl script (sorry Phil,
no ksh! :) ).  The attached patch will, I think, integrate it
properly.

Can someone test the patch before I commit?  It works here...

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_for_deps.patch
Type: application/octet-stream
Size: 1593 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20100701/9263bffe/attachment.obj>

From bonivart at opencsw.org  Thu Jul  1 14:27:25 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 1 Jul 2010 14:27:25 +0200
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> 
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com> 
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com>

On Thu, Jul 1, 2010 at 2:17 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from William Bonnet's message of Thu Jul 01 04:14:29 -0400 2010:
>
> Hi William,
>
>> since all are defined in the Makefile, i was wishing to have all
>> missing prereqs output at once.
>
> I just added check_for_deps to gar/bin. ?It's perl script (sorry Phil,
> no ksh! :) ). ?The attached patch will, I think, integrate it
> properly.
>
> Can someone test the patch before I commit? ?It works here...

Seems to work here as well:

bonivart at current9x[trunk]$ gmake update
[===== NOW BUILDING: tnef-1.4.7 =====]
ginstall -d work/solaris9-i386/cookies/global
ginstall -d work/solaris9-i386/download
ginstall -d work/solaris9-i386/download/partial
==> Verifying installed package CSWxz: ok
==> Verifying installed package CSWbzip2: ok
==> Verifying installed package CSWdiffutils: ok
==> Verifying installed package CSWfindutils: ok
==> Verifying installed package CSWgawk: ok
==> Verifying installed package CSWgfile: ok
==> Verifying installed package CSWggrep: ok
==> Verifying installed package CSWgmake: ok
==> Verifying installed package CSWgsed: ok
==> Verifying installed package CSWgtar: ok
==> Verifying installed package CSWpy-cheetah: ok
==> Verifying installed package CSWpy-hachoir-core: ok
==> Verifying installed package CSWpy-hachoir-parser: ok
==> Verifying installed package CSWpy-libmagic: ok
==> Verifying installed package CSWpy-progressbar: ok
==> Verifying installed package CSWpy-sqlobject: ok
==> Verifying installed package CSWpy-yaml: ok
==> Verifying installed package CSWpython: ok
==> Verifying installed package CSWcoreutils: ok
==> Verifying installed package CSWwget: ok
==> Verifying installed package CSWgit: ok
        [prerequisite] complete for tnef.

-- 
/peter

From phil at bolthole.com  Thu Jul  1 15:13:43 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 1 Jul 2010 06:13:43 -0700
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikR6iPjmCU_XWJeRBKI6DG8ZNDeLf1s_9_lF-cA@mail.gmail.com>

perl is in standard core solaris install now, so I'm happy with the choice :)

On Thursday, July 1, 2010, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from William Bonnet's message of Thu Jul 01 04:14:29 -0400 2010:
>
> Hi William,
>
>> since all are defined in the Makefile, i was wishing to have all
>> missing prereqs output at once.
>
> I just added check_for_deps to gar/bin. ?It's perl script (sorry Phil,
> no ksh! :) ). ?The attached patch will, I think, integrate it
> properly.
>

From phil at bolthole.com  Thu Jul  1 18:04:53 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 1 Jul 2010 09:04:53 -0700
Subject: [csw-maintainers] A question of naming, in our svn repository
In-Reply-To: <4A430357-19CF-45CB-BB99-5F8E378E0A6A@opencsw.org>
References: <AANLkTin1AYzKozmEDvGojZJMFgP6DMlRGpPKKJTmHJOd@mail.gmail.com>
	<9337133B-BD50-4A68-B261-2E3F2BCC779B@opencsw.org>
	<AANLkTim-6s28X3cG9TyCkwTOhrrku9dSQcywi2Ts1WoN@mail.gmail.com>
	<8FB41058-6BD3-4589-88CA-ED3C3CD349FE@opencsw.org>
	<AANLkTini7UcFTapLnLipJeHi24pG3VLEzTynJbiNKWI-@mail.gmail.com>
	<4A430357-19CF-45CB-BB99-5F8E378E0A6A@opencsw.org>
Message-ID: <AANLkTilxud3Xkme1pENf_Nzj31xdKmrhMOBAn4Y1s4hv@mail.gmail.com>

On Tue, Jun 29, 2010 at 11:28 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> ...
> You see what patches and options the previous maintainer used and then make
> a GAR recipe with similar options :-) I am currently struggling to rebuild
> x3270 against an updated libicu and my package looks different from the
> existing one - and there is no recipe for me to look at at all.
>
>

So my prior comment still stands:  the packages associated with those
dirs, were not made directly from those files. (through gar, anyways).

Reguardless, I take it then, that you dont object to renaming

xx-yyy  to xx_yyy

to match catalog names, so I will do that when I come across it while
building packages.

From phil at bolthole.com  Thu Jul  1 18:53:22 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 1 Jul 2010 09:53:22 -0700
Subject: [csw-maintainers] Define supported use cases and work from there
In-Reply-To: <AANLkTinYHuHZHFcjXkpt_IRkX3lBM23JdcTgERZ6Wbu7@mail.gmail.com>
References: <AANLkTik1w3Mdv4SFnTNRfplwzhgaR_9SFv-kg5-BB78r@mail.gmail.com>
	<AANLkTin6P3p-gDIehctMRsqZU7LnBBwUHJ_iMR--I1uk@mail.gmail.com>
	<AANLkTinYHuHZHFcjXkpt_IRkX3lBM23JdcTgERZ6Wbu7@mail.gmail.com>
Message-ID: <AANLkTim4GKWF4L75U0HqBXcsv93ZkYciZhD-0sKmwGk2@mail.gmail.com>

Sorry for the late reply...



On Sat, Jun 26, 2010 at 8:57 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Sat, Jun 26, 2010 at 5:53 PM, Philip Brown <phil at bolthole.com> wrote:
>> On Saturday, June 26, 2010, Peter Bonivart <bonivart at opencsw.org> wrote:
>> ....
>>> I suggest that we define which use cases we should support and in
>>> which priority.
>>
>> You make it sound as though this was not previously defined. But it
>> has already been defined, and documented, for over 4 years,
>> approximately....
> Is this documentet? Where? Should we support client utilities only or
> full server daemons?

The following references existed on the old website for a long time,
so please ignore the apparent "newness" of the urls:

http://www.opencsw.org/use-it/
   "For the most part, they are suitable for deployment both locally,
and on an NFS-shared filesystem. Packages usually install their
software under /opt/csw"

http://www.opencsw.org/use-it/sharing-optcsw/

   "The comments on this page are targetted towards sharing /opt/csw
read-only between multiple  machines, or between zones."

There are more. I trust I dont have to dig up more documentation
references for you though?



>
> Maybe someone else than you should come forward for those "big
> enterprises" using NFS since I can only remember you promoting them.
> I've never seen any active maintainer other than you be interested in
> this use case.

There was one other maintainer who was, for quite a while, using a
deployment strategy essentially identical to "shared read-only NFS".
His site was using replication across thousands of machines.
Dont remember his name though.

As a matter of principle, though, it shouldnt matter that it is "only
one maintainer" concerned about an issue. Doesnt matter if it's me, or
someone else. If "one maintainer" is concerned about an issue that
impacts his site, and I personaly dont care about it, i still try to
look for solutions to it.
Just like in the field of QA and bug reporting, where 1 bug report
represents 100 silent users with the same problem; 1 maintainer
potentially represents 100 other sysadmins in the same situation.

> However, it's about more cases than the dreaded NFS.

yes, quite. as I just mentioned above. it also covers replication, and
cross zone deployment strategies of, "mount this, but I dont want to
deal with the overhead of pkg-inherit garbage for 10 zones".

To use one of our competitors as an example:

Someone may choose to share a /usr/local read-only, populated via
sunfreeware packages.
They may share it via nfs, or replication, or zone machine as mentioned above.
THEIR packages will not suffer degredation via this method. (any more
than they already are, anyway ;-)
I'd like to ensure our packages can do just as well in that sort of situation.

I'll also point out that in the non-NFS cases, the argument about "you
shouldnt run demons from NFS anyway" does not apply.

The http://www.opencsw.org/use-it/sharing-optcsw/ mentioned above,
explicitly attempts to remind both users and maintainers, of issues
relating to this sort of deployment.
If you have suggestions to make this stuff better visible to
maintainers, please speak up.

From dam at opencsw.org  Thu Jul  1 19:03:12 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Jul 2010 19:03:12 +0200
Subject: [csw-maintainers] A question of naming, in our svn repository
In-Reply-To: <AANLkTilxud3Xkme1pENf_Nzj31xdKmrhMOBAn4Y1s4hv@mail.gmail.com>
References: <AANLkTin1AYzKozmEDvGojZJMFgP6DMlRGpPKKJTmHJOd@mail.gmail.com>
	<9337133B-BD50-4A68-B261-2E3F2BCC779B@opencsw.org>
	<AANLkTim-6s28X3cG9TyCkwTOhrrku9dSQcywi2Ts1WoN@mail.gmail.com>
	<8FB41058-6BD3-4589-88CA-ED3C3CD349FE@opencsw.org>
	<AANLkTini7UcFTapLnLipJeHi24pG3VLEzTynJbiNKWI-@mail.gmail.com>
	<4A430357-19CF-45CB-BB99-5F8E378E0A6A@opencsw.org>
	<AANLkTilxud3Xkme1pENf_Nzj31xdKmrhMOBAn4Y1s4hv@mail.gmail.com>
Message-ID: <3D46CE61-65EE-431B-A0F9-671D3A905454@opencsw.org>

Hi Phil,

Am 01.07.2010 um 18:04 schrieb Philip Brown:
> On Tue, Jun 29, 2010 at 11:28 PM, Dagobert Michelsen  
> <dam at opencsw.org> wrote:
>> ...
>> You see what patches and options the previous maintainer used and  
>> then make
>> a GAR recipe with similar options :-) I am currently struggling to  
>> rebuild
>> x3270 against an updated libicu and my package looks different from  
>> the
>> existing one - and there is no recipe for me to look at at all.
>
> So my prior comment still stands:  the packages associated with those
> dirs, were not made directly from those files. (through gar, anyways).

Most certainly there were, although I don't know how. The previous  
maintainer
used them.

> Reguardless, I take it then, that you dont object to renaming
>
> xx-yyy  to xx_yyy
>
> to match catalog names, so I will do that when I come across it while
> building packages.

Sure, please continue.


Best regards

   -- Dago


From bonivart at opencsw.org  Thu Jul  1 19:09:32 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 1 Jul 2010 19:09:32 +0200
Subject: [csw-maintainers] Define supported use cases and work from there
In-Reply-To: <AANLkTim4GKWF4L75U0HqBXcsv93ZkYciZhD-0sKmwGk2@mail.gmail.com>
References: <AANLkTik1w3Mdv4SFnTNRfplwzhgaR_9SFv-kg5-BB78r@mail.gmail.com> 
	<AANLkTin6P3p-gDIehctMRsqZU7LnBBwUHJ_iMR--I1uk@mail.gmail.com> 
	<AANLkTinYHuHZHFcjXkpt_IRkX3lBM23JdcTgERZ6Wbu7@mail.gmail.com> 
	<AANLkTim4GKWF4L75U0HqBXcsv93ZkYciZhD-0sKmwGk2@mail.gmail.com>
Message-ID: <AANLkTimUi_IyV-SBDuCyOMCxQAa8JxNd8em9-8kct3Wu@mail.gmail.com>

On Thu, Jul 1, 2010 at 6:53 PM, Philip Brown <phil at bolthole.com> wrote:
> If you have suggestions to make this stuff better visible to
> maintainers, please speak up.

For me, it's not about making it more visible, it's about removing the
"requirement". I wonder how it got there in the first place..?

Just because we (as in you?) have documented something, it doesn't
mean we should stick to it until hell freezes over. We finally dropped
Solaris 8 after all. :-)

I'm not asking for better documentation, I'm asking for us to rethink
what we want to offer. When was the last time we did that?

-- 
/peter

From phil at bolthole.com  Thu Jul  1 20:00:09 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 1 Jul 2010 11:00:09 -0700
Subject: [csw-maintainers] Define supported use cases and work from there
In-Reply-To: <AANLkTimUi_IyV-SBDuCyOMCxQAa8JxNd8em9-8kct3Wu@mail.gmail.com>
References: <AANLkTik1w3Mdv4SFnTNRfplwzhgaR_9SFv-kg5-BB78r@mail.gmail.com>
	<AANLkTin6P3p-gDIehctMRsqZU7LnBBwUHJ_iMR--I1uk@mail.gmail.com>
	<AANLkTinYHuHZHFcjXkpt_IRkX3lBM23JdcTgERZ6Wbu7@mail.gmail.com>
	<AANLkTim4GKWF4L75U0HqBXcsv93ZkYciZhD-0sKmwGk2@mail.gmail.com>
	<AANLkTimUi_IyV-SBDuCyOMCxQAa8JxNd8em9-8kct3Wu@mail.gmail.com>
Message-ID: <AANLkTin_mlKTorvPCVWIbgxZx5YNLbP0muaiPPZf-_B6@mail.gmail.com>

On Thu, Jul 1, 2010 at 10:09 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Thu, Jul 1, 2010 at 6:53 PM, Philip Brown <phil at bolthole.com> wrote:
>> If you have suggestions to make this stuff better visible to
>> maintainers, please speak up.
>
> For me, it's not about making it more visible, it's about removing the
> "requirement". I wonder how it got there in the first place..?
>....
> I'm not asking for better documentation, I'm asking for us to rethink
> what we want to offer. When was the last time we did that?
>
> --

That's where I thought you were really heading, even though you
muddied the waters in your original email by talking about lack of
documentation :-)

So, you are proposing a change in our existing documented list of what
we support.

I have now posted some amount of rationale as to WHY we officially
support what is currently documented; the sharing of /opt/csw across
machines.

If you think we should change that, my suggestion is that you write a
proper proposal for it.
The proposal should ideally contain the following:

- An analysis of benefits for the change
- An analysis of negatives for the change

I'll point out that 'costs' of maintainance for the existing setup are
relatively low, for the average maintainer. First of all,
90%+(guesstimate) of our packages are completely non-affected by the
issue either way.
For the remaining stuff, maintainers just have to follow standards for
where to put stuff. If they do that, they dont have to do any extra
work at all.
The "work" is actually done by the maintainer of the appropriate CSW
utility scripts, in gar, cswclassutils, and now also in the
"alternatives" implementation.

I've handled one of those already: the alternatives implementation.
Gar mostly just hands things off to the other scripts.
So the remaining chunk is in the cswclassutils scripts.
I have already said I will recode the biggest difficulty; the cswinitsmf one.

So its unclear to me who is going to lose out by sticking to existing
standards, and who is going to benefit, if we changed them?

I will also mention an additional negative to change:
We have committed, for many years, to support /opt/csw sharing. (even
though we've done less than a stellar job of it lately). We also have
to consider impact to our credibility, if we decide to revoke it,
without even a major polling of our userbase.

>Just because we (as in you?) have documented something, it doesn't
>mean we should stick to it until hell freezes over. We finally dropped
>Solaris 8 after all. :-)

The ditching sol8 was not a random, "oh we dont feel like putting in
the effort any more" change.
It was part of our pre-existing, documented support life cycle, and
had been known and published for years.

From bwalton at opencsw.org  Fri Jul  2 05:04:02 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 01 Jul 2010 23:04:02 -0400
Subject: [csw-maintainers] cswutils in experimental/bwalton
Message-ID: <1278039796-sup-7331@pinkfloyd.chass.utoronto.ca>


Hi All,

I've placed an update of cswutils in my experimental catalog.  This
update included the checkpkg path issue as well as a few other fixes
from Phil.

If nobody gripes in the next few days, I'll push it for release.

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


From bonivart at opencsw.org  Fri Jul  2 18:09:43 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 2 Jul 2010 18:09:43 +0200
Subject: [csw-maintainers] Define supported use cases and work from there
In-Reply-To: <AANLkTin_mlKTorvPCVWIbgxZx5YNLbP0muaiPPZf-_B6@mail.gmail.com>
References: <AANLkTik1w3Mdv4SFnTNRfplwzhgaR_9SFv-kg5-BB78r@mail.gmail.com> 
	<AANLkTin6P3p-gDIehctMRsqZU7LnBBwUHJ_iMR--I1uk@mail.gmail.com> 
	<AANLkTinYHuHZHFcjXkpt_IRkX3lBM23JdcTgERZ6Wbu7@mail.gmail.com> 
	<AANLkTim4GKWF4L75U0HqBXcsv93ZkYciZhD-0sKmwGk2@mail.gmail.com> 
	<AANLkTimUi_IyV-SBDuCyOMCxQAa8JxNd8em9-8kct3Wu@mail.gmail.com> 
	<AANLkTin_mlKTorvPCVWIbgxZx5YNLbP0muaiPPZf-_B6@mail.gmail.com>
Message-ID: <AANLkTimeDdzMAJcnjIOlMs0QUKIMIDj_VR6WraM3Gwnz@mail.gmail.com>

On Thu, Jul 1, 2010 at 8:00 PM, Philip Brown <phil at bolthole.com> wrote:
> So, you are proposing a change in our existing documented list of what
> we support.

I'm not proposing to change what we support based on what _I_ think.
What I am asking is what the community (read: maintainers) think we
should support. From scratch, not tweaking what you and Dennis wrote
in 2002.

If we come up with the same, then fine. At least it's a community decision then.

-- 
/peter

From maciej at opencsw.org  Sat Jul  3 13:13:56 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sat, 3 Jul 2010 12:13:56 +0100
Subject: [csw-maintainers] Architecture-dependency binary placement policy
Message-ID: <AANLkTinj3hN56zrKzw2CdpR0nJP9p7LCJ97KUqHvrTRt@mail.gmail.com>

In other words, where to put which kind of binaries.  I'm finishing to
integrate a binary file parser into checkpkg and would like to come up
with a set of rules about the binary placement.

Based on previous experience and our the page[1] about architecture
optimization, the policy is as follows:

- binaries in directories named 'bin', 'lib' and 'libexec' must be
either sparcv8 or hardlinks to isaexec
- binaries which are non sparcv8 must be placed in a subdirectory
named after the architecture, with variants allowed; sparcv8plus
binaries can be placed in directories named sparcv8plus,
sparcv8plus+vis, or sparcv8plus+vis2

Is this correct?

[1] http://www.opencsw.org/extend-it/contribute-packages/build-standards/architecture-optimization-using-isaexec-and-isalist/

From bwalton at opencsw.org  Sat Jul  3 17:58:12 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sat, 03 Jul 2010 11:58:12 -0400
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
	<AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com>
Message-ID: <1278172673-sup-152@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Thu Jul 01 08:27:25 -0400 2010:

> Seems to work here as well:

Thanks Peter!  I just committed the change.

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


From phil at bolthole.com  Sat Jul  3 20:47:26 2010
From: phil at bolthole.com (Philip Brown)
Date: Sat, 3 Jul 2010 11:47:26 -0700
Subject: [csw-maintainers] Architecture-dependency binary placement
	policy
In-Reply-To: <AANLkTinj3hN56zrKzw2CdpR0nJP9p7LCJ97KUqHvrTRt@mail.gmail.com>
References: <AANLkTinj3hN56zrKzw2CdpR0nJP9p7LCJ97KUqHvrTRt@mail.gmail.com>
Message-ID: <AANLkTinUrc12g_Svq0MULWE_Nb7_8kiVkNavB_26wYcX@mail.gmail.com>

sounds about right

On Saturday, July 3, 2010, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> In other words, where to put which kind of binaries. ?I'm finishing to
> integrate a binary file parser into checkpkg and would like to come up
> with a set of rules about the binary placement.
>
> Based on previous experience and our the page[1] about architecture
> optimization, the policy is as follows:
>
> - binaries in directories named 'bin', 'lib' and 'libexec' must be
> either sparcv8 or hardlinks to isaexec
> - binaries which are non sparcv8 must be placed in a subdirectory
> named after the architecture, with variants allowed; sparcv8plus
> binaries can be placed in directories named sparcv8plus,
> sparcv8plus+vis, or sparcv8plus+vis2
>
> Is this correct?
>
> [1] http://www.opencsw.org/extend-it/contribute-packages/build-standards/architecture-optimization-using-isaexec-and-isalist/
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From maciej at opencsw.org  Sat Jul  3 23:16:20 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sat, 3 Jul 2010 22:16:20 +0100
Subject: [csw-maintainers] checkpkg: New feature,
	binary architecture vs file placement
Message-ID: <AANLkTikfYbkUhVZz0C-cPZQR1sLE8sbJtcKnYJSMfTO8@mail.gmail.com>

Dear maintainers,

I've pushed[1] a new checkpkg feature: checking binary file
architectures and verifying them against directories.  It implements
our policy described on the website[2], where sparcv8 binaries can be
in bin/, lib/ and libexec/, while sparcv8+ and sparcv9 must be in
respectively named subdirectories.

False positives may occur if binaries reside in non-standard
directories.  If you encounter any, you can add overrides.  However,
please notify me about your case, so I can improve checkpkg.

To enable the new feature, please update your GAR sources.

Maciej

[1] http://sourceforge.net/apps/trac/gar/changeset/10410
[2] http://bit.ly/bJOlfZ

From phil at bolthole.com  Sun Jul  4 00:28:54 2010
From: phil at bolthole.com (Philip Brown)
Date: Sat, 3 Jul 2010 15:28:54 -0700
Subject: [csw-maintainers] checkpkg: New feature,
	binary architecture vs 	file placement
In-Reply-To: <AANLkTikfYbkUhVZz0C-cPZQR1sLE8sbJtcKnYJSMfTO8@mail.gmail.com>
References: <AANLkTikfYbkUhVZz0C-cPZQR1sLE8sbJtcKnYJSMfTO8@mail.gmail.com>
Message-ID: <AANLkTing3QrwYxuudhQwIrvFSwB6r3O_EgPTu6Xeuec8@mail.gmail.com>

one will be
mysql I think.
although theoretically it could be restructured to be compliant

On Saturday, July 3, 2010, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> Dear maintainers,
>
> I've pushed[1] a new checkpkg feature: checking binary file
> architectures and verifying them against directories. ?It implements
> our policy described on the website[2], where sparcv8 binaries can be
> in bin/, lib/ and libexec/, while sparcv8+ and sparcv9 must be in
> respectively named subdirectories.
>
> False positives may occur if binaries reside in non-standard
> directories. ?If you encounter any, you can add overrides. ?However,
> please notify me about your case, so I can improve checkpkg.
>
> To enable the new feature, please update your GAR sources.
>
> Maciej
>
> [1] http://sourceforge.net/apps/trac/gar/changeset/10410
> [2] http://bit.ly/bJOlfZ
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From maciej at opencsw.org  Sun Jul  4 15:59:59 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sun, 4 Jul 2010 14:59:59 +0100
Subject: [csw-maintainers] checkpkg: New feature,
	binary architecture vs 	file placement
In-Reply-To: <AANLkTing3QrwYxuudhQwIrvFSwB6r3O_EgPTu6Xeuec8@mail.gmail.com>
References: <AANLkTikfYbkUhVZz0C-cPZQR1sLE8sbJtcKnYJSMfTO8@mail.gmail.com> 
	<AANLkTing3QrwYxuudhQwIrvFSwB6r3O_EgPTu6Xeuec8@mail.gmail.com>
Message-ID: <AANLkTinfZOL78A_LV5ul5NcGSwZo2X6_Lfr4BaXPWkYh@mail.gmail.com>

No dia 3 de Julho de 2010 23:28, Philip Brown <phil at bolthole.com> escreveu:
> one will be
> mysql I think.
> although theoretically it could be restructured to be compliant

I'm running checkpkg over the whole catalog to find out what the error
reports look like.  There are about 980 false positives, I think I'll
be able to fix most of them today.

Maciej

From bonivart at opencsw.org  Mon Jul  5 00:11:05 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 5 Jul 2010 00:11:05 +0200
Subject: [csw-maintainers] Error in weekly package summary
Message-ID: <AANLkTinrN5wykudX_iXAfK9hyvdVyvXOQ-G65WKVQkFB@mail.gmail.com>

I just got the weekly announcement mail and it had this in it:

"mailscanner:4.78.17.1,REV=2009.10.01 - A Free Anti-Virus and Anti-Spam Filter"

That's the old package already released, I have just submitted 4.79 so
either that version should be listed or no mailscanner entry at all.

-- 
/peter

From bonivart at opencsw.org  Mon Jul  5 20:15:30 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 5 Jul 2010 20:15:30 +0200
Subject: [csw-maintainers] /testing milter-greylist
Message-ID: <AANLkTilY0edtd0R4EekZl2M9fp3wfVbslxx0c9_sDMnl@mail.gmail.com>

Hi,

I have built a new version of this greylisting package for Sendmail
(and maybe Postfix). It supports both GeoIP and SPF2 to validate the
senders. I would appreciate it if someone could help with testing on
an actual mail server. All my clients have change stops during the
summer so I have only done local tests on vbox.

More info about milter-greylist is available here:
http://milter-greylist.wikidot.com/. It uses an in-memory db and it's
very flexible to configure.

You can find the packages here:
http://mirror.opencsw.org/experimental.html#bonivart.

-- 
/peter

From phil at bolthole.com  Mon Jul  5 22:13:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 5 Jul 2010 13:13:29 -0700
Subject: [csw-maintainers] Error in weekly package summary
In-Reply-To: <AANLkTinrN5wykudX_iXAfK9hyvdVyvXOQ-G65WKVQkFB@mail.gmail.com>
References: <AANLkTinrN5wykudX_iXAfK9hyvdVyvXOQ-G65WKVQkFB@mail.gmail.com>
Message-ID: <AANLkTikhY0El1Lkj3xYyxzZuUeW0l89uEEUVLt8jbPwM@mail.gmail.com>

yeah I had halfway put in new one then backed it out when I wrote
comments. this gave a false positive for the update scanner.
I think new one is in now though?

On Sunday, July 4, 2010, Peter Bonivart <bonivart at opencsw.org> wrote:
> I just got the weekly announcement mail and it had this in it:
>
> "mailscanner:4.78.17.1,REV=2009.10.01 - A Free Anti-Virus and Anti-Spam Filter"
>
> That's the old package already released, I have just submitted 4.79 so
> either that version should be listed or no mailscanner entry at all.
>
> --
> /peter
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From bonivart at opencsw.org  Mon Jul  5 22:17:22 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 5 Jul 2010 22:17:22 +0200
Subject: [csw-maintainers] Error in weekly package summary
In-Reply-To: <AANLkTikhY0El1Lkj3xYyxzZuUeW0l89uEEUVLt8jbPwM@mail.gmail.com>
References: <AANLkTinrN5wykudX_iXAfK9hyvdVyvXOQ-G65WKVQkFB@mail.gmail.com> 
	<AANLkTikhY0El1Lkj3xYyxzZuUeW0l89uEEUVLt8jbPwM@mail.gmail.com>
Message-ID: <AANLkTikvcGYrXugeOgT56Qy42GcD6Go1GIHlhlySTcmp@mail.gmail.com>

On Mon, Jul 5, 2010 at 10:13 PM, Philip Brown <phil at bolthole.com> wrote:
> yeah I had halfway put in new one then backed it out when I wrote
> comments. this gave a false positive for the update scanner.
> I think new one is in now though?

Yes, it's in now, I just checked. :-)

-- 
/peter

From william at wbonnet.net  Tue Jul  6 13:56:18 2010
From: william at wbonnet.net (William Bonnet)
Date: Tue, 6 Jul 2010 13:56:18 +0200
Subject: [csw-maintainers] Proposal : decommissioning desktop support for
	Solaris 9
Message-ID: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>

Hi,

We recently experienced many problems with the CSW X11 libs I pushed forward. Especially we had to step back because of the loss of 3D acceleration. 

After switching back to Sun's lib, i'm still in front of several problems to compile recent applications against Sun's lib on Solaris 9 (especially Mozilla's stuff). I'm afraid that we will still have this kind of problems as long as we will keep compatibility with  X11 version provided Solaris 9.

As you may know, Sun's Beijing team released recent Firefox version. These builds are Solaris 10 only. On my own i made some tests with seamonkey (it was not the latest). It needs libs update on Solaris 9, but compiles almost out of the box on Solaris 10. This situation, will not improve in the next months, and i'm pretty sure it is the same for other software stacks.

This lead me to the following proposal. I think it may be the time to think about dropping desktop support for Solaris 9. Or at least to focus on providing Solaris 10 only packages for desktop applications in recent version. 

Of course existing packages would be kept in the repository, but no longer updated. And non desktop packages are out of the scope of this proposal ! 

IMHO most of desktop users are Solaris 10 users. There are certainly a few Solaris 9 users. This mean they will have to stick to existing version (FF3, TB2, etc.). Anyways current situation, makes me uncertain about the possibility to deliver anything else than these versions... Thus, better update for Solaris 10 users, instead of keeping everyone at Solaris 9 level. 

Feedback and thoughts are welcome :)

cheers
W.


From william at wbonnet.net  Tue Jul  6 14:55:36 2010
From: william at wbonnet.net (William Bonnet)
Date: Tue, 6 Jul 2010 14:55:36 +0200
Subject: [csw-maintainers] Summer camp 2010 : List of hotel available
Message-ID: <1B198847-C614-4154-ADF4-8DEB3141E362@wbonnet.net>

Hi

I have updated the wiki page with a list of hotel. All are close to the meeting room (5 to 10 minutes walking).

http://wiki.opencsw.org/summercamp-2010

cheers
W.


From phil at bolthole.com  Tue Jul  6 17:21:40 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 6 Jul 2010 08:21:40 -0700
Subject: [csw-maintainers] Proposal : decommissioning desktop support
	for Solaris 9
In-Reply-To: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
Message-ID: <AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>

On Tue, Jul 6, 2010 at 4:56 AM, William Bonnet <william at wbonnet.net> wrote:
> .... On my own i made some tests with seamonkey (it was not the latest). It needs libs update on Solaris 9, but compiles almost out of the box on Solaris 10. This situation, will not improve in the next months, and i'm pretty sure it is the same for other software stacks.
>
> This lead me to the following proposal. I think it may be the time to think about dropping desktop support for Solaris 9. Or at least to focus on providing Solaris 10 only packages for desktop applications in recent version.

Ah,, wow.. that's a huge proposal!

and I think a bit premature.

Even **sun**(beijing) had to ship "updated libs", with its firefox!
This up-to-date libs problem, is not going away. It has been around
since the beginning of CSW, and is even covered in our FAQ!
( http://www.opencsw.org/about/faq/, "Why dont you guys use Sun
packages of..." )

Even that aside... I think this is more of a firefox-specific problem.
firefox is a disgustingly bloated,non-portably written ... beast.
If you wished to only update firefox on sol10... I would allow those
packages through.
That being said, the majority of desktop software still compiles
relatively easily on sol9, and the other stuff with some small amount
of work (1-2 patches per piece of software).

So long as there are people willing to tackle the "needs work"
packages, I dont see why we would want to "officially" abandon sol9
desktop.

It is in fact, the area where we are most needed, in a way.
Since it is easier to compile that stuff directly on sol10, there is
less "need" for 3rd parties to provide sol10 packages of that stuff.
Sol9 users "need" us more.

From bonivart at opencsw.org  Tue Jul  6 23:25:47 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 6 Jul 2010 23:25:47 +0200
Subject: [csw-maintainers] Proposal : decommissioning desktop support
	for Solaris 9
In-Reply-To: <AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> 
	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
Message-ID: <AANLkTilPqh_6RikwP_hUh-kmBtovzD4mf0aaohrhCQuK@mail.gmail.com>

On Tue, Jul 6, 2010 at 5:21 PM, Philip Brown <phil at bolthole.com> wrote:
> It is in fact, the area where we are most needed, in a way.
> Since it is easier to compile that stuff directly on sol10, there is
> less "need" for 3rd parties to provide sol10 packages of that stuff.
> Sol9 users "need" us more.

By that logic we should immediately pick up Solaris 8 again... ;-)

-- 
/peter

From william at wbonnet.net  Wed Jul  7 01:25:47 2010
From: william at wbonnet.net (William Bonnet)
Date: Wed, 07 Jul 2010 01:25:47 +0200
Subject: [csw-maintainers] Proposal : decommissioning desktop support
 for Solaris 9
In-Reply-To: <AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
Message-ID: <4C33BB7B.6020107@wbonnet.net>

Hi

> Even **sun**(beijing) had to ship "updated libs", with its firefox!
>    
Yes, but they don't provide a full X11 stack with their Firefox, do they 
? otherwise they should also provide Solaris 9 binaries...

> Even that aside... I think this is more of a firefox-specific problem.
>    

I'm not really sure about this. It's also a Qt problem, thus a KDE 
problem.  It's also already a Xfce problem, and I'm sure soon or later 
it will be a gnome problem when you'll try to get the latest version. 
Even if some time you can patch the software to make it run under 
Solaris 9, i'm not really sure it's any longer worth the effort.

> So long as there are people willing to tackle the "needs work"
> packages, I dont see why we would want to "officially" abandon sol9
> desktop.
>    

Because IMHO Solaris 9 desktop users are very few, regarding to Solaris 
10 users, because we will not remove existing packages from catalog, and 
because it takes a loooonnggg time to produce Solaris 9 packages for 
some software. I cannot remember how many hours and night i spent 
patching Xfce code and mozilla stuff to finally release only FF3.0

Today the compilation of the up to date mozilla stack under solaris 9 
reached a dead end if we don't update X11.Mozilla is not the only 
software stack which is concerned. But even if it was, it's a good 
reason to me. If we cannot provide a recent browser and mail agent, it's 
a real problem to me as a desktop user.  Especially, if our policy 
prevent us to do the upgrade and force me to use Sun's contributed build 
instead of our build.

Maybe dropping Solaris 9 support for desktop is a bit fast. We should 
take in account the number of Solaris 9 users (do we have statistics 
about this ? or is it time to make Lutefisk publicly available ?), and 
we should take in account which software can be updated under solaris 9 
or not.

Packages which are easy to update could be kept up to date according to 
the maintainer will and time, but IMHO Solaris 10 should go mainstream 
as desktop target. Actually i feel like if we were stuck with this 
version which prevent us to do some updates. So what is the worst thing ?

To provide only a very few update to everyone. This means not providing 
up to date software to the majority of desktop users (which are running 
Sol10).

or to go mainstream with Solaris 10, provide up to date packages for 
this platform, and to provide what we can for Solaris 9

BTW this would also save a lot of patching and porting effort ;)

cheers
W.



From bwalton at opencsw.org  Wed Jul  7 01:53:54 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 06 Jul 2010 19:53:54 -0400
Subject: [csw-maintainers] Proposal : decommissioning desktop support
	for Solaris 9
In-Reply-To: <AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
Message-ID: <1278460236-sup-2831@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Tue Jul 06 11:21:40 -0400 2010:

Hi Phil,

> It is in fact, the area where we are most needed, in a way.  Since
> it is easier to compile that stuff directly on sol10, there is less
> "need" for 3rd parties to provide sol10 packages of that stuff.
> Sol9 users "need" us more.

This is true iff there are sol9 desktop users.  Do we have any sense
that there are sol9 desktop folks out there?  I'd be surprised if
there were many.

Even if there are a few, forcing[1] a desktop upgrade to run software
is less of an issue than forcing a server upgrade.

Thanks
-Ben

[1] They can continue to run the currently available, but increasingly
    outdated versions if they wish.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From james at opencsw.org  Wed Jul  7 10:02:08 2010
From: james at opencsw.org (James Lee)
Date: Wed, 07 Jul 2010 08:02:08 GMT
Subject: [csw-maintainers] Proposal : decommissioning desktop support
 for Solaris 9
In-Reply-To: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
Message-ID: <20100707.8020800.2956226871@gyor.oxdrove.co.uk>

On 06/07/10, 12:56:18, William Bonnet <william at wbonnet.net> wrote regarding 
[csw-maintainers] Proposal : decommissioning desktop support for Solaris 9:

> This lead me to the following proposal. I think it may be the time
> to think about dropping desktop support for Solaris 9. Or at least
> to focus on providing Solaris 10 only packages for desktop
> applications in recent version.

> Of course existing packages would be kept in the repository, but
> no longer updated. And non desktop packages are out of the scope
> of this proposal !

> IMHO most of desktop users are Solaris 10 users. There are certainly
> a few Solaris 9 users. This mean they will have to stick to existing
> version (FF3, TB2, etc.). Anyways current situation, makes me
> uncertain about the possibility to deliver anything else than these
> versions... Thus, better update for Solaris 10 users, instead of
> keeping everyone at Solaris 9 level.

I and one other person I know run Solaris desktop on 8/9 and not 10
because CPR reboot works on 7/8/9 but not on Solaris 10.

This is such a clear advantage to a desktop it's worth 2 versions of
Firefox.  Although I actually run my browser from a remote Solaris 10
machine so I can use a later version, also because browsers leak
memory restarting daily helps.  Everything else I like to have running
exactly where I left it. 



James.



From phil at bolthole.com  Wed Jul  7 18:54:02 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 7 Jul 2010 09:54:02 -0700
Subject: [csw-maintainers] Proposal : decommissioning desktop support
	for Solaris 9
In-Reply-To: <4C33BB7B.6020107@wbonnet.net>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
	<4C33BB7B.6020107@wbonnet.net>
Message-ID: <AANLkTimk9w3DLqh6QkidAc0jU2hdDPhZc46U0BYtDkHb@mail.gmail.com>

On Tuesday, July 6, 2010, William Bonnet <william at wbonnet.net> wrote:
> Hi
>
>
> Even **sun**(beijing) had to ship "updated libs", with its firefox!
>
>
> Yes, but they don't provide a full X11 stack with their Firefox, do they ?



we don't have to provide a full stack either. that was a mistake on our part .


as proof of concept, would you please recompile firefox... the old 3.0
version you already had patched ... using our newer gtk libs and
WITHOUT cswx11?

if I'm right,this should be easy for you. perhaps this will make you
feel more comfortable about things.
I'd try it myself, but the odd things you did in gar made it not easy
for ME to follow what you did :)

From william at wbonnet.net  Thu Jul  8 00:27:58 2010
From: william at wbonnet.net (William Bonnet)
Date: Thu, 08 Jul 2010 00:27:58 +0200
Subject: [csw-maintainers] Proposal : decommissioning desktop support
 for Solaris 9
In-Reply-To: <AANLkTimk9w3DLqh6QkidAc0jU2hdDPhZc46U0BYtDkHb@mail.gmail.com>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>	<4C33BB7B.6020107@wbonnet.net>
	<AANLkTimk9w3DLqh6QkidAc0jU2hdDPhZc46U0BYtDkHb@mail.gmail.com>
Message-ID: <4C34FF6E.3070007@wbonnet.net>

Hi

> we don't have to provide a full stack either. that was a mistake on our part .
>   
well maybe... i was away for a few weeks, so i may have missed some 
reasons. Was there another reason than loosing 3D accel ?
> as proof of concept, would you please recompile firefox... the old 3.0
> version you already had patched ... using our newer gtk libs and
> WITHOUT cswx11?
>   
Which machine should i use ?

I tried to compile on current9x and testing9x it does not work on both 
machines.
> I'd try it myself, but the odd things you did in gar made it not easy
> for ME to follow what you did :)
>   
I surely did odd things with the X11 libs :) but hopefully there was GAR 
... even for you ;)

cheers
W.


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

http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix
http://www.opencsw.org 	 Community SoftWare for Solaris
http://www.guses.org     French speaking Solaris User Group



From phil at bolthole.com  Thu Jul  8 01:47:24 2010
From: phil at bolthole.com (Philip Brown)
Date: Wed, 7 Jul 2010 16:47:24 -0700
Subject: [csw-maintainers] Proposal : decommissioning desktop support
	for Solaris 9
In-Reply-To: <4C34FF6E.3070007@wbonnet.net>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
	<4C33BB7B.6020107@wbonnet.net>
	<AANLkTimk9w3DLqh6QkidAc0jU2hdDPhZc46U0BYtDkHb@mail.gmail.com>
	<4C34FF6E.3070007@wbonnet.net>
Message-ID: <AANLkTik5T6muO2mQ9dM4RAN0sTLbxRZPtTHizcd1Xvl_@mail.gmail.com>

> I'd try it myself, but the odd things you did in gar made it not easy
> for ME to follow what you did :)
>
>
> I surely did odd things with the X11 libs :) but hopefully there was GAR ... even for you ;)
>



I tried using your gar stuff... or at least whatever was in trunk...
and it kept gettng wierd on me.
this was with cswx11 I think.

maybe you could start with a "clean" gar, but with your source patches
, for 3.0 and see how it goes.
the one change is no xcb

current9 machines should work. if not please list errors

From william at wbonnet.net  Thu Jul  8 11:19:43 2010
From: william at wbonnet.net (William Bonnet)
Date: Thu, 8 Jul 2010 11:19:43 +0200
Subject: [csw-maintainers] Proposal : decommissioning desktop support
	for Solaris 9
In-Reply-To: <AANLkTik5T6muO2mQ9dM4RAN0sTLbxRZPtTHizcd1Xvl_@mail.gmail.com>
References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net>
	<AANLkTimdvVliJhvKaUMK3_UnrqBNWhkc0Ohs_5iGMmS1@mail.gmail.com>
	<4C33BB7B.6020107@wbonnet.net>
	<AANLkTimk9w3DLqh6QkidAc0jU2hdDPhZc46U0BYtDkHb@mail.gmail.com>
	<4C34FF6E.3070007@wbonnet.net>
	<AANLkTik5T6muO2mQ9dM4RAN0sTLbxRZPtTHizcd1Xvl_@mail.gmail.com>
Message-ID: <CECDF614-9930-42F9-8898-788D6077D59D@wbonnet.net>

Hi Phil

> I tried using your gar stuff... or at least whatever was in trunk...
> and it kept gettng wierd on me.
> this was with cswx11 I think.

I've started to do some cleaning and rebuild from firefox/trunk

i'll send the result this evening

cheers
W.



From maciej at opencsw.org  Thu Jul  8 14:10:49 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 8 Jul 2010 13:10:49 +0100
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <1278172673-sup-152@pinkfloyd.chass.utoronto.ca>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> 
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com> 
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> 
	<AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com> 
	<1278172673-sup-152@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTinUFh8w7q2CPOrnG6tIbzMtyMtquFLEcBE1dmt-@mail.gmail.com>

It seems to me that the command is run every time, there's no caching.
 It doesn't take much time to run, but it still could be cached, I
think.  Thoughts?

From bwalton at opencsw.org  Thu Jul  8 14:46:51 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 08 Jul 2010 08:46:51 -0400
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <AANLkTinUFh8w7q2CPOrnG6tIbzMtyMtquFLEcBE1dmt-@mail.gmail.com>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
	<AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com>
	<1278172673-sup-152@pinkfloyd.chass.utoronto.ca>
	<AANLkTinUFh8w7q2CPOrnG6tIbzMtyMtquFLEcBE1dmt-@mail.gmail.com>
Message-ID: <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 08:10:49 -0400 2010:
> It seems to me that the command is run every time, there's no caching.
>  It doesn't take much time to run, but it still could be cached, I
> think.  Thoughts?

It wasn't previously cached was it?  (Hoping I didn't add a regression
even though it would still run quickly...)  I agree that it could be
cached with a cookie.  I'll have a look at that tonight.

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


From maciej at opencsw.org  Thu Jul  8 15:07:39 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 8 Jul 2010 14:07:39 +0100
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> 
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com> 
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> 
	<AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com> 
	<1278172673-sup-152@pinkfloyd.chass.utoronto.ca>
	<AANLkTinUFh8w7q2CPOrnG6tIbzMtyMtquFLEcBE1dmt-@mail.gmail.com> 
	<1278593150-sup-9694@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTim8Ybf3gwnoL_JrfJnq-d_W-qNd03YoscF8RK68@mail.gmail.com>

No dia 8 de Julho de 2010 13:46, Ben Walton <bwalton at opencsw.org> escreveu:
> Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 08:10:49 -0400 2010:
>> It seems to me that the command is run every time, there's no caching.
>> ?It doesn't take much time to run, but it still could be cached, I
>> think. ?Thoughts?
>
> It wasn't previously cached was it? ?(Hoping I didn't add a regression
> even though it would still run quickly...) ?I agree that it could be
> cached with a cookie. ?I'll have a look at that tonight.

It was cached, it had to be.  We couldn't have stood it if it wasn't.
The new check is fast enough, but I noticed the output to the screen,
so I asked.

From bwalton at opencsw.org  Thu Jul  8 16:57:32 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 08 Jul 2010 10:57:32 -0400
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <AANLkTim8Ybf3gwnoL_JrfJnq-d_W-qNd03YoscF8RK68@mail.gmail.com>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
	<AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com>
	<1278172673-sup-152@pinkfloyd.chass.utoronto.ca>
	<AANLkTinUFh8w7q2CPOrnG6tIbzMtyMtquFLEcBE1dmt-@mail.gmail.com>
	<1278593150-sup-9694@pinkfloyd.chass.utoronto.ca>
	<AANLkTim8Ybf3gwnoL_JrfJnq-d_W-qNd03YoscF8RK68@mail.gmail.com>
Message-ID: <1278601030-sup-8536@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 09:07:39 -0400 2010:

> It was cached, it had to be.  We couldn't have stood it if it
> wasn't.  The new check is fast enough, but I noticed the output to
> the screen, so I asked.

Ok.  I'll correct this tonight.  Thanks for noticing it.

Thanks
-Ben

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


From maciej at opencsw.org  Thu Jul  8 18:31:17 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 8 Jul 2010 17:31:17 +0100
Subject: [csw-maintainers] cswinitsmf vs custom SMF manifests vs pkgutil
Message-ID: <AANLkTik3OUVmDK5AHSpvxtcicRgV4192bAI9rireKUlO@mail.gmail.com>

There's a problem that I discovered.  The first symptom is that after
an upgrade done by pkgutil, there is a SMF service that is in the
maintenance state, even though all the dependencies are installed.
I've pulled it apart and discovered that it's caused by a combination
of 3 things:

1. If CSWfoo depends on CSWbar and both are to be upgraded, pkgutil
can remove CSWbar from under CSWfoo; if CSWfoo is running from SMF, it
goes into the maintenance state because it misses CSWbar
2. If a custom SMF manifest is used, r.cswinitsmf doesn't remove the
manifest from SMF
3. If there is an existing manifest during installation, which is the
maintenance state, i.cswinitsmf imports the new manifest, but only
calls 'enable' on it.  This means that the service remains in the
maintenance state until 'svcadm clear' is issued.

I can fix problems 2 and 3.  Peter, would you mind looking at the first problem?

Maciej

From phil at bolthole.com  Thu Jul  8 18:46:25 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 8 Jul 2010 09:46:25 -0700
Subject: [csw-maintainers] cswinitsmf vs custom SMF manifests vs pkgutil
In-Reply-To: <AANLkTik3OUVmDK5AHSpvxtcicRgV4192bAI9rireKUlO@mail.gmail.com>
References: <AANLkTik3OUVmDK5AHSpvxtcicRgV4192bAI9rireKUlO@mail.gmail.com>
Message-ID: <AANLkTilSbHitWAB-EiZmi7TKQT4Gt75tdFRPtB868l7V@mail.gmail.com>

On Thu, Jul 8, 2010 at 9:31 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> ... I've pulled it apart and discovered that it's caused by a combination
> of 3 things:
>
> 1. If CSWfoo depends on CSWbar and both are to be upgraded, pkgutil
> can remove CSWbar from under CSWfoo; if CSWfoo is running from SMF, it
> goes into the maintenance state because it misses CSWbar
> 2. If a custom SMF manifest is used, r.cswinitsmf doesn't remove the
> manifest from SMF
> 3. If there is an existing manifest during installation, which is the
> maintenance state, i.cswinitsmf imports the new manifest, but only
> calls 'enable' on it. ?This means that the service remains in the
> maintenance state until 'svcadm clear' is issued.
>
> I can fix problems 2 and 3. ?Peter, would you mind looking at the first problem?
>

I would suggest and request that the solution be implemented in a
transport neutral fashion:

ideally, it should be something that works with manual "pkgrm/pkgadd".
ie: an adjustment to cswinitsmf, rather than elsewhere.

From maciej at opencsw.org  Fri Jul  9 10:08:00 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 9 Jul 2010 09:08:00 +0100
Subject: [csw-maintainers] cswinitsmf vs custom SMF manifests vs pkgutil
In-Reply-To: <AANLkTilSbHitWAB-EiZmi7TKQT4Gt75tdFRPtB868l7V@mail.gmail.com>
References: <AANLkTik3OUVmDK5AHSpvxtcicRgV4192bAI9rireKUlO@mail.gmail.com> 
	<AANLkTilSbHitWAB-EiZmi7TKQT4Gt75tdFRPtB868l7V@mail.gmail.com>
Message-ID: <AANLkTikDN687RQx_1OErZeXdcXZmrQ0bGYe-BJlG5Nvr@mail.gmail.com>

No dia 8 de Julho de 2010 17:46, Philip Brown <phil at bolthole.com> escreveu:
> On Thu, Jul 8, 2010 at 9:31 AM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> ... I've pulled it apart and discovered that it's caused by a combination
>> of 3 things:
>>
>> 1. If CSWfoo depends on CSWbar and both are to be upgraded, pkgutil
>> can remove CSWbar from under CSWfoo; if CSWfoo is running from SMF, it
>> goes into the maintenance state because it misses CSWbar
>> 2. If a custom SMF manifest is used, r.cswinitsmf doesn't remove the
>> manifest from SMF
>> 3. If there is an existing manifest during installation, which is the
>> maintenance state, i.cswinitsmf imports the new manifest, but only
>> calls 'enable' on it. ?This means that the service remains in the
>> maintenance state until 'svcadm clear' is issued.
>>
>> I can fix problems 2 and 3. ?Peter, would you mind looking at the first problem?
>>
>
> I would suggest and request that the solution be implemented in a
> transport neutral fashion:
>
> ideally, it should be something that works with manual "pkgrm/pkgadd".
> ie: an adjustment to cswinitsmf, rather than elsewhere.

Yes, that's the idea.  These are 3 independent issues, there will be 3
independent fixes.

From ihsan at opencsw.org  Fri Jul  9 12:46:15 2010
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Fri, 09 Jul 2010 12:46:15 +0200
Subject: [csw-maintainers] unexpected mail server outage
Message-ID: <4C36FDF7.9000802@opencsw.org>

Hello,

FYI:
There was an unexpected mail server outage of approx. 10 minutes. Other 
services (website) were not affected by this.



Ihsan

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

From bwalton at opencsw.org  Fri Jul  9 16:31:25 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 09 Jul 2010 10:31:25 -0400
Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at
	once
In-Reply-To: <AANLkTim8Ybf3gwnoL_JrfJnq-d_W-qNd03YoscF8RK68@mail.gmail.com>
References: <4C2BA75F.5090003@wbonnet.net>
	<1277929832-sup-5707@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjzmYwhkOQjviR6SO0rEitXf9O0b1zqMoWhLWG@mail.gmail.com>
	<1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net>
	<1277986547-sup-6149@pinkfloyd.chass.utoronto.ca>
	<AANLkTinfRaIAyXwRic8j9X9DpO0CqUr4e8DcBURstEp_@mail.gmail.com>
	<1278172673-sup-152@pinkfloyd.chass.utoronto.ca>
	<AANLkTinUFh8w7q2CPOrnG6tIbzMtyMtquFLEcBE1dmt-@mail.gmail.com>
	<1278593150-sup-9694@pinkfloyd.chass.utoronto.ca>
	<AANLkTim8Ybf3gwnoL_JrfJnq-d_W-qNd03YoscF8RK68@mail.gmail.com>
Message-ID: <1278685870-sup-3099@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 09:07:39 -0400 2010:

> It was cached, it had to be.  We couldn't have stood it if it
> wasn't.  The new check is fast enough, but I noticed the output to
> the screen, so I asked.

This should be resolved now.

Thanks
-Ben

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


From bwalton at opencsw.org  Fri Jul  9 19:03:50 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 09 Jul 2010 13:03:50 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
Message-ID: <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Mon Jun 21 19:47:19 -0400 2010:

Hi Phil,

> CSWcommon is 'fixing' things the wrong way, by papering over bugs in
> other packages[1]...it's cancelling an intended feature of
> gettext/libintl and doing only half the job at that.  Let's fix this
> _properly_ instead of adding another layer of papier macher.

Is there an update for CSWcommon in the pipe to address this?  I'd
like to get the coreutils package working properly.

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


From phil at bolthole.com  Fri Jul  9 21:02:18 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Jul 2010 12:02:18 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>

On Fri, Jul 9, 2010 at 10:03 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Ben Walton's message of Mon Jun 21 19:47:19 -0400 2010:
>
> Hi Phil,
>
>> CSWcommon is 'fixing' things the wrong way, by papering over bugs in
>> other packages[1]...it's cancelling an intended feature of
>> gettext/libintl and doing only half the job at that. ?Let's fix this
>> _properly_ instead of adding another layer of papier macher.
>
> Is there an update for CSWcommon in the pipe to address this? ?I'd
> like to get the coreutils package working properly.
>

nothing active at the moment.

As I said earlier in the thread, this requires some research. its "on
my list", but as a very low priority.
Research should look into WHY some locales have the symlinks for
LC_MESSAGES == LC_TIME, and some do not.
Even in the package of your "own" that you are complaining about: some
symlink, and some do not.

There may be some actual known standard or something, in the realm of
locales, that makes this a good idea, and actually BREAKS certain
things if not done.
This is my vague 7-year-fuzzy-memory of the thing. Possibly something
to do with time/date comparisons and display.

And honestly, can you really see me manually putting together umpteen
symlinks into the common prototype package.. and NOT doing all of
them... unless I had a fairly good reason at the time?  I think you
know me better than that by now. :) My usual preference would be to
either just put in empty directories, or symlink everything.

From bwalton at opencsw.org  Sat Jul 10 02:05:37 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 09 Jul 2010 20:05:37 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
Message-ID: <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Jul 09 15:02:18 -0400 2010:

Hi Phil,

> Research should look into WHY some locales have the symlinks for
> LC_MESSAGES == LC_TIME, and some do not.

I suspect that you added symlinks in CSWcommon for the locales
delivered by the packages that were broken and no other locales.  That
makes sense given what you were attempting to do.

> Even in the package of your "own" that you are complaining about:
> some symlink, and some do not.

Use of LC_TIME is discouraged, but not invalid.  Most packages won't
deliver anything but LC_MESSAGES, which is why this hasn't been hit
until now.  The coreutils case provides symlinks to make the domains
equal too.  (I realize I could fix this in coreutils, I just don't
think that's the best solution.)

> There may be some actual known standard or something, in the realm
> of locales, that makes this a good idea, and actually BREAKS certain
> things if not done.

Not according to the documentation I read (eg: the official
libintl/gettext stuff).

> This is my vague 7-year-fuzzy-memory of the thing. Possibly
> something to do with time/date comparisons and display.

What you did when you added the links in CSWcommon allows programs
that referenced localizations in the LC_TIME domain to function even
though they hadn't properly provided those files.  This would have
been the result of either improper programming (they used LC_TIME when
LC_MESSAGES should have been used) or improper installation routines
(the install should have provided either files or symlinks on its
own).  While it was easier to work around this in CSWcommon, that
allowed the packages themselves to remain broken.

I wonder if this may have originated with the original CSWtextutils,
CSWgfile and CSWshutils packages...?

> And honestly, can you really see me manually putting together
> umpteen symlinks into the common prototype package.. and NOT doing
> all of them... unless I had a fairly good reason at the time?  I
> think you know me better than that by now. :) My usual preference
> would be to either just put in empty directories, or symlink
> everything.

Yes, I do.  I also know that you're likely to err toward the
correctness side of things rather than the easiest route in all
cases...that's what I'm attempting here.  While there aren't likely
many programs using LC_TIME in any serious fashion, there is the
possibility that they could (until it becomes officially deprecated,
but that's hard to do...).

I'll make the offer that if you update CSWcommon to be more correct
and not break CSWcoreutils, I'll re-roll any package that breaks as a
result with a _minimum_ of a manual insertion of the required proper
directories and symlinks and possible a version upgrade/garification.

Thoughts?

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


From phil at bolthole.com  Sat Jul 10 04:42:15 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 9 Jul 2010 19:42:15 -0700
Subject: [csw-maintainers] [csw-buildfarm] running mkheaders for gcc4
In-Reply-To: <1278727782-sup-6502@pinkfloyd.chass.utoronto.ca>
References: <1278727782-sup-6502@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimjihhSF-IzpT7RwJLZUvIl4BNZUopduxQC19Q2@mail.gmail.com>

hmmm
this is something that probably needs to be automatically run in each
zone, if there is a global zone and a sol9 container zone. I wonder if
that happens on pkgadd on gcc4?
hmmm... but if it's a sparse zone it would fail since output is under
/opt, not var I think?
oh-oh...


On Friday, July 9, 2010, Ben Walton <bwalton at opencsw.org> wrote:
>
> I'm about to run gcc4's included (news to me) mkheaders. ?I _think_
> this will get us over the hump for building things that were broken
> with sol9.
>
> Stay tuned.
>

From bwalton at opencsw.org  Sat Jul 10 04:53:49 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 09 Jul 2010 22:53:49 -0400
Subject: [csw-maintainers] [csw-buildfarm] running mkheaders for gcc4
In-Reply-To: <AANLkTimjihhSF-IzpT7RwJLZUvIl4BNZUopduxQC19Q2@mail.gmail.com>
References: <1278727782-sup-6502@pinkfloyd.chass.utoronto.ca>
	<AANLkTimjihhSF-IzpT7RwJLZUvIl4BNZUopduxQC19Q2@mail.gmail.com>
Message-ID: <1278730342-sup-7105@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Jul 09 22:42:15 -0400 2010:

> this is something that probably needs to be automatically run in
> each zone, if there is a global zone and a sol9 container zone. I
> wonder if that happens on pkgadd on gcc4?

It doesn't get triggered by pkgadd for gcc4, but Peter F's gcc3 does
trigger it that way.

> hmmm... but if it's a sparse zone it would fail since output is
> under /opt, not var I think?  oh-oh...

Yes, this is true, afaik.

For what it's worth, I've been able to build ruby again after running
it, so aside from potential delivery issues, it's a good step forward.

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


From rupert at opencsw.org  Sun Jul 11 16:14:06 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Sun, 11 Jul 2010 16:14:06 +0200
Subject: [csw-maintainers] chkpkg error, or gmake clean platforms error?
Message-ID: <AANLkTika8E46JSQtzTKgEyR3gqQQbeU30EzpZgc2DofV@mail.gmail.com>

hi,

when building the new version of mercurial, 1.6, i did, on build9s:

1. change the version numer from 1.5.4 to 1.6
2. gmake makesums
3. gmake clean platforms

and it endet with

CSWmercurial:
 * The package installs files into /opt/csw/lib/python. For example,
   '/opt/csw/lib/python/site-packages'. However, the pkgname doesn't start
   with 'CSWpy-'.
 * The package installs files into /opt/csw/lib/python. For example,
   '/opt/csw/lib/python/site-packages'. However, the catalogname doesn't start
   with 'py_'.
Applying the overrides and analyzing the results.
100% |#########################################################################|
If any of the reported errors were false positives, you can
override them pasting the lines below to the GAR recipe.
CHECKPKG_OVERRIDES_CSWmercurial +=
filename-version-does-not-match-pkginfo-version|filename=1.6,REV=2010.07.11|pkginfo=1.5.4,REV=2010.06.01
Please note that checkpkg isn't suggesting you should
use these overrides.  It only informs what the overrides could
look like.  You need to understand what are the reported issues about
and use your best judgement to decide whether to fix the underlying
problems or override them.
ERROR: Modular checks are reporting errors.
To run checkpkg in the debug mode, add the '-d' flag, for example:
After you modify any overrides, you need to do gmake remerge repackage
or gmake platforms-remerge platforms-repackage.
gmake: *** [pkgcheck] Error 2
gmake: Leaving directory `/home/rupert/mgar/pkg/mercurial/trunk'
Connection to current9x closed.
gmake: *** [platforms] Error 2
rupert at current9s ~/mgar/pkg/mercurial/trunk


where does this error come from?

rupert

From maciej at opencsw.org  Sun Jul 11 17:38:57 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sun, 11 Jul 2010 16:38:57 +0100
Subject: [csw-maintainers] chkpkg error, or gmake clean platforms error?
In-Reply-To: <AANLkTika8E46JSQtzTKgEyR3gqQQbeU30EzpZgc2DofV@mail.gmail.com>
References: <AANLkTika8E46JSQtzTKgEyR3gqQQbeU30EzpZgc2DofV@mail.gmail.com>
Message-ID: <AANLkTinyYu6jGaM8zmGA2DZEvn1v40TGsJ9qrHc_NZgo@mail.gmail.com>

No dia 11 de Julho de 2010 15:14, rupert THURNER <rupert at opencsw.org> escreveu:
> hi,
>
> when building the new version of mercurial, 1.6, i did, on build9s:
>
> 1. change the version numer from 1.5.4 to 1.6
> 2. gmake makesums
> 3. gmake clean platforms

The 'gmake clean' command has performed clean on your current host
(probably current9s), and on this host only.  The error you saw was
thrown on current9x.  If you look at the error message you got, you'll
see the sequence: the error is emitted, and the connection to
current9x is closed.

gmake: Leaving directory `/home/rupert/mgar/pkg/mercurial/trunk'
Connection to current9x closed.
gmake: *** [platforms] Error 2
rupert at current9s

As a general rule, you would do:

gmake makesums
gmake replatforms

The 'replatforms' target performs 'clean' on all hosts.

Maciej

From ja at opencsw.org  Sun Jul 11 19:55:25 2010
From: ja at opencsw.org (Juergen Arndt)
Date: Sun, 11 Jul 2010 19:55:25 +0200
Subject: [csw-maintainers] Munin 1.4.5 in experimental
Message-ID: <0D0D6119-7AEC-4A83-B733-AB955BAED071@opencsw.org>

Hi there,

there are new packages for Munin available from
http://mirror.opencsw.org/experimental.html#ja

Feedback is very welcome.

Juergen

-- 
Juergen Arndt


From rupert at opencsw.org  Mon Jul 12 05:04:17 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 12 Jul 2010 05:04:17 +0200
Subject: [csw-maintainers] dead link on packages page
Message-ID: <AANLkTikML5dcXa6YSC4SazK1VKfujmk_1VtvQ9tc_s_y@mail.gmail.com>

hi,

http://www.opencsw.org/packages/ contains a dead link onto the testing
area, this should probably go into experimental?

rupert.

From maciej at opencsw.org  Mon Jul 12 18:16:03 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 12 Jul 2010 17:16:03 +0100
Subject: [csw-maintainers] XML processing tools on bare Solaris 10
Message-ID: <AANLkTimUf4RhLthnUBh1gjYLaEcnB4lEV0sgaF4VlZri@mail.gmail.com>

In order to resolve the problem with cswinitsmf with custom manifests,
XML processing is necessary.  I tried Perl, but the XML::DOM package
is not installed by default.  Are there any in-built XML processing
tools available in CAS on Solaris 10?  (Solaris 9 doesn't have SMF, so
no need for XML processing there.)

Maciej

From phil at bolthole.com  Mon Jul 12 18:54:45 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Jul 2010 09:54:45 -0700
Subject: [csw-maintainers] XML processing tools on bare Solaris 10
In-Reply-To: <AANLkTimUf4RhLthnUBh1gjYLaEcnB4lEV0sgaF4VlZri@mail.gmail.com>
References: <AANLkTimUf4RhLthnUBh1gjYLaEcnB4lEV0sgaF4VlZri@mail.gmail.com>
Message-ID: <AANLkTilu5sIzuMEqA3cAbdkRg6Iah3M4SoKH-Q3UaQmF@mail.gmail.com>

On 7/12/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> In order to resolve the problem with cswinitsmf with custom manifests,
> XML processing is necessary.  I tried Perl, but the XML::DOM package
> is not installed by default.  Are there any in-built XML processing
> tools available in CAS on Solaris 10?  (Solaris 9 doesn't have SMF, so
> no need for XML processing there.)
>

What is the exact problem you are trying to solve?

surely, [Full XML Dom-compliant buzzwordBlahBlahBlah] is not neccessary.
worst case.. use the smf libraries and utils themselves?

From phil at bolthole.com  Mon Jul 12 23:14:51 2010
From: phil at bolthole.com (Philip Brown)
Date: Mon, 12 Jul 2010 14:14:51 -0700
Subject: [csw-maintainers] new gnome stuffs
Message-ID: <AANLkTinub7rHRWm_GlDKXs58-avLCXM9YyeCLdXmiTKG@mail.gmail.com>

FYI, I released my pending libbonobo, blah blah other gnome low-level
foundation stuffs that were sitting in experimental for a month.

From bwalton at opencsw.org  Tue Jul 13 03:06:28 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 12 Jul 2010 21:06:28 -0400
Subject: [csw-maintainers] de-listed packages...?
Message-ID: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca>


Hi All,

I was looking at the list of packages affected by an 'update all'
action on the buildfarm and found the following.  I assume that these
have all been pulled from the catalog, but if someone wouldn't mind
piping up if they know the full story on the packages, I'd appreciate
it.

CSWglibmmdevel            2.16.4,REV=2008.12.03     not in catalog           
CSWglibmmrt               2.16.4,REV=2008.12.02     not in catalog           
CSWgtkmm2                 2.2.12                    not in catalog           
CSWgtkmmdevel             2.12.5,REV=2008.12.03     not in catalog           
CSWgtkmmrt                2.12.5,REV=2008.12.02     not in catalog           
CSWhachoir-parser         1.2.1,REV=2010.01.15      not in catalog           
CSWlibsigc++rt            2.2.3,REV=2008.12.01      not in catalog           
CSWpmdigest               1.16,REV=2009.08.10       not in catalog           
CSWpmlistmoreut           0.22,REV=2007.03.17       not in catalog           
CSWpmmodulebuild          0.33,REV=2009.06.08       not in catalog           
CSWrenderproto            0.9.3,REV=2009.05.29      not in catalog           
CSWxextproto              7.1.1,REV=2009.09.17      not in catalog           

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


From bwalton at opencsw.org  Tue Jul 13 03:12:45 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 12 Jul 2010 21:12:45 -0400
Subject: [csw-maintainers] [RFC] splitting cswclassutils
Message-ID: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>


Hi All,

I'd like to propose that cswclassutils be split as follows:

1. Each i/r script pair becomes a separate package named CSWcu-foo
2. CSWclassutils becomes an empty package depending on all CSWcu-foo
   packages.  It will only change when we add/remove a CSWcu-foo
   package.

This would make bug tracking nicer as it currently burdens Peter B
even when he's not the author/maintainer of the script in question.
It should also make coordination of the package easier as one person
isn't repsonsible for ensuring that all separate script updates have
been tested before asking for a new release, etc.

(I think this was suggested a few weeks back, but I'm formalizing the
rfc.)

Thoughts?

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


From maciej at opencsw.org  Tue Jul 13 09:32:09 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Jul 2010 08:32:09 +0100
Subject: [csw-maintainers] XML processing tools on bare Solaris 10
In-Reply-To: <AANLkTilu5sIzuMEqA3cAbdkRg6Iah3M4SoKH-Q3UaQmF@mail.gmail.com>
References: <AANLkTimUf4RhLthnUBh1gjYLaEcnB4lEV0sgaF4VlZri@mail.gmail.com> 
	<AANLkTilu5sIzuMEqA3cAbdkRg6Iah3M4SoKH-Q3UaQmF@mail.gmail.com>
Message-ID: <AANLkTilLTrUvEM5Qh44_4vXzlPDiHN3NBRRrdNPBo-Sm@mail.gmail.com>

No dia 12 de Julho de 2010 17:54, Philip Brown <phil at bolthole.com> escreveu:
> On 7/12/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> In order to resolve the problem with cswinitsmf with custom manifests,
>> XML processing is necessary. ?I tried Perl, but the XML::DOM package
>> is not installed by default. ?Are there any in-built XML processing
>> tools available in CAS on Solaris 10? ?(Solaris 9 doesn't have SMF, so
>> no need for XML processing there.)
>>
>
> What is the exact problem you are trying to solve?

`OoAwwrrrhhhhh... "Do. Or do not. there is no Try"'
     --Philip Brown, ca. 2010

;-)

> surely, [Full XML Dom-compliant buzzwordBlahBlahBlah] is not neccessary.
> worst case.. use the smf libraries and utils themselves?

Good suggestion about the SMF utilities. svccfg inventory <file>
outputs the list of service fmris.

[1] http://lists.opencsw.org/pipermail/maintainers/2010-March/011569.html

From maciej at opencsw.org  Tue Jul 13 09:34:31 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Jul 2010 08:34:31 +0100
Subject: [csw-maintainers] de-listed packages...?
In-Reply-To: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca>
References: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTik4X0InU_YQtifP6JpPNeWYldX711Kx04wW64hs@mail.gmail.com>

No dia 13 de Julho de 2010 02:06, Ben Walton <bwalton at opencsw.org> escreveu:
> CSWhachoir-parser ? ? ? ? 1.2.1,REV=2010.01.15 ? ? ?not in catalog

Has been renamed to CSWpy-hachoir-parser.  The old one can be removed.

From maciej at opencsw.org  Tue Jul 13 09:51:54 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Jul 2010 08:51:54 +0100
Subject: [csw-maintainers] [RFC] splitting cswclassutils
In-Reply-To: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimK4hoO_p5qqQ24OqkRYXxViEkUl9cFKkCEubJM@mail.gmail.com>

No dia 13 de Julho de 2010 02:12, Ben Walton <bwalton at opencsw.org> escreveu:
> This would make bug tracking nicer as it currently burdens Peter B
> even when he's not the author/maintainer of the script in question.
> It should also make coordination of the package easier as one person
> isn't repsonsible for ensuring that all separate script updates have
> been tested before asking for a new release, etc.

I support the general idea.  There's a variant of this approach that
I'd suggest: instead of splitting off all the packages at once, we can
be splitting them off one by one as needed.  Once we do that, most of
easy scripts will be in CSWcswclassutils, while CAS that benefit from
well-defined ownership would live in separate packages.

Thinking about checkpkg, I'd like checkpkg to verify the dependencies
on CSWcu-* files.  How would we detect the dependencies on specific
CSWcu-* packages?  I see two simple solutions:

- a hardcoded mapping between class names and individual packages
- cswfoo CAS always lives in CSWcu-foo, for example cswinitsmf lives
in CSWcu-initsmf

Maciej

From james at opencsw.org  Tue Jul 13 10:42:51 2010
From: james at opencsw.org (James Lee)
Date: Tue, 13 Jul 2010 08:42:51 GMT
Subject: [csw-maintainers] [RFC] splitting cswclassutils
In-Reply-To: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
Message-ID: <20100713.8425100.2303544286@gyor.oxdrove.co.uk>

On 13/07/10, 02:12:45, Ben Walton <bwalton at opencsw.org> wrote regarding 
[csw-maintainers] [RFC] splitting cswclassutils:


> I'd like to propose that cswclassutils be split as follows:

> 1. Each i/r script pair becomes a separate package named CSWcu-foo
> 2. CSWclassutils becomes an empty package depending on all CSWcu-foo
>    packages.  It will only change when we add/remove a CSWcu-foo
>    package.

> This would make bug tracking nicer as it currently burdens Peter B
> even when he's not the author/maintainer of the script in question.
> It should also make coordination of the package easier as one person
> isn't repsonsible for ensuring that all separate script updates have
> been tested before asking for a new release, etc.

CSWcswclassutils has to be manually installed in the global zone,
splitting it will make package management harder.

Having a single responsible person should be a good thing, like having
a prime contractor.  The best way to reduce the maintainer burden is
to stop fiddling with it.



James.

From bonivart at opencsw.org  Tue Jul 13 11:40:35 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 13 Jul 2010 11:40:35 +0200
Subject: [csw-maintainers] de-listed packages...?
In-Reply-To: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca>
References: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTiky5BEh--C0xQHVQ_FaAe9rWE87tdvRgYMmGXlC@mail.gmail.com>

On Tue, Jul 13, 2010 at 3:06 AM, Ben Walton <bwalton at opencsw.org> wrote:
>
> Hi All,
>
> I was looking at the list of packages affected by an 'update all'
> action on the buildfarm and found the following. ?I assume that these
> have all been pulled from the catalog, but if someone wouldn't mind
> piping up if they know the full story on the packages, I'd appreciate
> it.
>
> CSWpmdigest ? ? ? ? ? ? ? 1.16,REV=2009.08.10 ? ? ? not in catalog

Included in Perl 5.10.1.

> CSWpmlistmoreut ? ? ? ? ? 0.22,REV=2007.03.17 ? ? ? not in catalog

Renamed to CSWpmlistmoreutils.

> CSWpmmodulebuild ? ? ? ? ?0.33,REV=2009.06.08 ? ? ? not in catalog

Included in Perl 5.10.1.

You can remove all three.

-- 
/peter

From maciej at opencsw.org  Tue Jul 13 16:26:49 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Jul 2010 15:26:49 +0100
Subject: [csw-maintainers] Providing parent directories for pkgmap entries
Message-ID: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>

I've found an interesting issue and I can't decide whether it's a
problem or not. If you look at the list of files here:
http://www.opencsw.org/search/vsftpd/ -- there is a directory named
/opt/csw/var/empty/vsftpd, but the directory  /opt/csw/var/empty is
provided by neither vsftpd nor any of its dependencies.  During
installation, /opt/csw/var/empty gets created. On uninstallation, the
/opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty
is not.

Is not providing the parent directory a bug?

From phil at bolthole.com  Tue Jul 13 17:42:56 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 08:42:56 -0700
Subject: [csw-maintainers] [RFC] splitting cswclassutils
In-Reply-To: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTilBN9jsLRb1oUgNitcWfB0gQbuiXujIDZz7UIxR@mail.gmail.com>

thank you for officially writing this up.
I second it, with the one amendment of removing the "-"

On Monday, July 12, 2010, Ben Walton <bwalton at opencsw.org> wrote:
>
> Hi All,
>
> I'd like to propose that cswclassutils be split as follows:
>
> 1. Each i/r script pair becomes a separate package named CSWcu-foo
> 2. CSWclassutils becomes an empty package depending on all CSWcu-foo
>  ? packages. ?It will only change when we add/remove a CSWcu-foo
>  ? package.
>
> This would make bug tracking nicer as it currently burdens Peter B
> even when he's not the author/maintainer of the script in question.
> It should also make coordination of the package easier as one person
> isn't repsonsible for ensuring that all separate script updates have
> been tested before asking for a new release, etc.
>
> (I think this was suggested a few weeks back, but I'm formalizing the
> rfc.)
>
> Thoughts?
>
> Thanks
> -Ben
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From phil at bolthole.com  Tue Jul 13 17:55:37 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 08:55:37 -0700
Subject: [csw-maintainers] [RFC] splitting cswclassutils
In-Reply-To: <20100713.8425100.2303544286@gyor.oxdrove.co.uk>
References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca>
	<20100713.8425100.2303544286@gyor.oxdrove.co.uk>
Message-ID: <AANLkTimL9ZhwHi800oF5-7kb-mX-4cH7wsmXe5PGyL7A@mail.gmail.com>

On 7/13/10, James Lee <james at opencsw.org> wrote:
>
> CSWcswclassutils has to be manually installed in the global zone,
> splitting it will make package management harder.
>
> Having a single responsible person should be a good thing, like having
> a prime contractor.  The best way to reduce the maintainer burden is
> to stop fiddling with it.


There's a tradeoff involved.
Yes, there's "more stuff to install in global zone".
However, once it is done initially... there is potentialy much less change.

Some of the more recent additions, were very volatile in change rate.
A cautious site, could have avoided any global changes whatsoever, if
they did not happen to use one of the packages that used the class
action script being tweaked.

It also allows more choices at the site-local level.
This way, it would be easier for a site to override ONE particular
class action script
(for example, with their own package that had date set for
REV=3000.0.0), yet otherwise get normal updates for the other ones.

At the moment, they would have to keep reviewing all 22 scripts, on
every update to classutils.

From phil at bolthole.com  Tue Jul 13 18:02:01 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 09:02:01 -0700
Subject: [csw-maintainers] Providing parent directories for pkgmap
	entries
In-Reply-To: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
References: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
Message-ID: <AANLkTilaGMRpXx-Oc79932ePQIfl9KJgETCzLFKVCaX6@mail.gmail.com>

On 7/13/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> I've found an interesting issue and I can't decide whether it's a
> problem or not. If you look at the list of files here:
> http://www.opencsw.org/search/vsftpd/ -- there is a directory named
> /opt/csw/var/empty/vsftpd, but the directory  /opt/csw/var/empty is
> provided by neither vsftpd nor any of its dependencies.  During
> installation, /opt/csw/var/empty gets created. On uninstallation, the
> /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty
> is not.
>
> Is not providing the parent directory a bug?


Well, there's a bigger problem in that it is using "/opt/csw/var" in
the first place :-/

Other than that, I think the more general question of leaving
directories around, depends on where they are and what is in them.
If it was somewhere else, such as /var/opt/csw, I dont think it would
be much of a big deal.

From phil at bolthole.com  Tue Jul 13 18:25:08 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 09:25:08 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>

On 7/9/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Jul 09 15:02:18 -0400 2010:
>
> Hi Phil,
>
>> Research should look into WHY some locales have the symlinks for
>> LC_MESSAGES == LC_TIME, and some do not.
>
> I suspect that you added symlinks in CSWcommon for the locales
> delivered by the packages that were broken and no other locales.  That
> makes sense given what you were attempting to do.
>


well, trouble is, we no longer know definitively what I was
"attempting to do" :-}


>>[Phil wrote]
>> Even in the package of your "own" that you are complaining about:
>> some symlink, and some do not.

Actually, I just looked in coreutils again.

and... it's inconsistent.
for example, it provides

1 d none /opt/csw/share/locale/nb 0755 root bin
1 d none /opt/csw/share/locale/nb/LC_MESSAGES 0755 root bin
1 f none /opt/csw/share/locale/nb/LC_MESSAGES/coreutils.mo 0644 root
bin 29201 33503 1277688854
1 d none /opt/csw/share/locale/nb/LC_TIME 0755 root bin
1 s none /opt/csw/share/locale/nb/LC_TIME/coreutils.mo=../LC_MESSAGES/coreutils.mo

but only
1 f none /opt/csw/share/locale/lt/LC_MESSAGES/coreutils.mo 0644 root
bin 38282 41078 1277688854
1 d none /opt/csw/share/locale/lt/LC_TIME 0755 root bin
1 s none /opt/csw/share/locale/lt/LC_TIME/coreutils.mo=../LC_MESSAGES/coreutils.mo


(no 'd' entry for the lt directory itself. Erm.. that's because of
deduplication with
  cswcommon, I suppose? But still, inconsistency==not good)

Yes I realize the irony of me saying that, given cswcommon.  I WOULD
like consistency there also. Trying to think of ways to get there.

It would appear, that my initial glance and claim that coreutils only
symlinked SOME
LC_TIME entries, was incorrect. It seems to me note, that it symlinks
ALL of them.

I also think it likely that cswcommon was, as you say, tracking the
locales from coreutils predecessors.

Given these "new" facts, I'd like to make the following proposal,
similar to the one you made:

1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES
2. cswcommon gets a README file mentioning that the reason for the
LC_TIME links,
    is to track coreutils local stuffs (and that as more locales get added, more
    dirs and LC_TIME symlinks should be added to it)

3. coreutils then gets to skip its LC_TIME symlinks.

Hmm. there should probably also be a reverse comment in coreutils,
 "If new locales pop up that are not in cswcommon, then cswcommon
should be updated".
It might even be nice to have an AUTOMATED check, for "Hey, new
locale! update cswcommon!"

From maciej at opencsw.org  Tue Jul 13 18:29:03 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Jul 2010 17:29:03 +0100
Subject: [csw-maintainers] Providing parent directories for pkgmap
	entries
In-Reply-To: <AANLkTilaGMRpXx-Oc79932ePQIfl9KJgETCzLFKVCaX6@mail.gmail.com>
References: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com> 
	<AANLkTilaGMRpXx-Oc79932ePQIfl9KJgETCzLFKVCaX6@mail.gmail.com>
Message-ID: <AANLkTikU3KFVYTaxSZ3GcqKUNUvtk2cf08uVu1nYQAU9@mail.gmail.com>

No dia 13 de Julho de 2010 17:02, Philip Brown <phil at bolthole.com> escreveu:
> Well, there's a bigger problem in that it is using "/opt/csw/var" in
> the first place :-/

That's easy enough to catch.  Will add a new check.

> Other than that, I think the more general question of leaving
> directories around, depends on where they are and what is in them.
> If it was somewhere else, such as /var/opt/csw, I dont think it would
> be much of a big deal.

I would like to determine whether it makes sense to check for these.
It might not be a significant issue, but still potentially nice to
catch.

From maciej at opencsw.org  Tue Jul 13 18:31:29 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 13 Jul 2010 17:31:29 +0100
Subject: [csw-maintainers] Check for the nrpe-like cases
Message-ID: <AANLkTimoalhtlGAaJiE3blxoUoRdZi1uyhVxo6Did3EZ@mail.gmail.com>

Following up on the missing directories topic and the nrpe case.  The
problem occurs when the three conditions are met:

1. The file is not of the 'none' class
2. It's not a directory
3. Nothing provides the parent directory

I'm thinking of adding a check for this particular condition.  Any thoughts?

From bwalton at opencsw.org  Tue Jul 13 18:51:54 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 13 Jul 2010 12:51:54 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
Message-ID: <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Tue Jul 13 12:25:08 -0400 2010:

> and... it's inconsistent.
> for example, it provides

> (no 'd' entry for the lt directory itself. Erm.. that's because of
> deduplication with
>   cswcommon, I suppose? But still, inconsistency==not good)

Right.  The prototype provides a symlink from each LC_TIME to the
corresponding LC_MESSAGES.  It's only after installation that it gets
inconsistent.

> 1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES
> 2. cswcommon gets a README file mentioning that the reason for the
> LC_TIME links,
>     is to track coreutils local stuffs (and that as more locales get added, more
>     dirs and LC_TIME symlinks should be added to it)
> 
> 3. coreutils then gets to skip its LC_TIME symlinks.

...Can you re-read that and then tell me it makes sense from a
maintenance point of view?

So now, you're proposing that we _extend_ the current breakage (in the
event some package actually needs separate LC_TIME/LC_MESSAGES which
is VALID)?  Not only does this continue to take away from what gettext
has to offer, but it doubles the maintenance burden for these
directories...in a non-automated way.

I'm counter-proposing this:

1. Remove all share/locale/* from cswcommon
2. Keep coreutils as it is.
3. Fix packages (if any remaining) that break as a result, which is a
   rather trivial thing to do.

Thoughts?

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


From phil at bolthole.com  Tue Jul 13 21:58:19 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 12:58:19 -0700
Subject: [csw-maintainers] Providing parent directories for pkgmap
	entries
In-Reply-To: <AANLkTikU3KFVYTaxSZ3GcqKUNUvtk2cf08uVu1nYQAU9@mail.gmail.com>
References: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
	<AANLkTilaGMRpXx-Oc79932ePQIfl9KJgETCzLFKVCaX6@mail.gmail.com>
	<AANLkTikU3KFVYTaxSZ3GcqKUNUvtk2cf08uVu1nYQAU9@mail.gmail.com>
Message-ID: <AANLkTikoJ70OjKVrq266A3ELyNqMxFSjt9dix2WVo4Vl@mail.gmail.com>

Given that this was created "on the fly" (I presume), I think it would
be incredibly difficult to catch with any certainty at pkg creation
time.
I dont think it's worth your effort.

(Now, if we actually had a dedicated "QA team", who went around
testing all this stuff, I might suggest putting stuff like this on
their plate. But for something for "checkpkg" to catch... I dont think
its worth it.


On 7/13/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 13 de Julho de 2010 17:02, Philip Brown <phil at bolthole.com> escreveu:
>> Well, there's a bigger problem in that it is using "/opt/csw/var" in
>> the first place :-/
>
> That's easy enough to catch.  Will add a new check.
>
>> Other than that, I think the more general question of leaving
>> directories around, depends on where they are and what is in them.
>> If it was somewhere else, such as /var/opt/csw, I dont think it would
>> be much of a big deal.
>
> I would like to determine whether it makes sense to check for these.
> It might not be a significant issue, but still potentially nice to
> catch.
> _______________________________________________
> 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 Jul 13 21:58:56 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 12:58:56 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>

On 7/13/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Tue Jul 13 12:25:08 -0400 2010:
>
>> and... it's inconsistent.
>> for example, it provides
>
>> (no 'd' entry for the lt directory itself. Erm.. that's because of
>> deduplication with
>>   cswcommon, I suppose? But still, inconsistency==not good)
>
> Right.  The prototype provides a symlink from each LC_TIME to the
> corresponding LC_MESSAGES.  It's only after installation that it gets
> inconsistent.
>
>> 1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES
>> 2. cswcommon gets a README file mentioning that the reason for the
>> LC_TIME links,
>>     is to track coreutils local stuffs (and that as more locales get
>> added, more
>>     dirs and LC_TIME symlinks should be added to it)
>>
>> 3. coreutils then gets to skip its LC_TIME symlinks.
>
> ...Can you re-read that and then tell me it makes sense from a
> maintenance point of view?
>
> So now, you're proposing that we _extend_ the current breakage (in the
> event some package actually needs separate LC_TIME/LC_MESSAGES which
> is VALID)?  Not only does this continue to take away from what gettext
> has to offer, but it doubles the maintenance burden for these
> directories...in a non-automated way.
>
> I'm counter-proposing this:
>
> 1. Remove all share/locale/* from cswcommon
> 2. Keep coreutils as it is.
> 3. Fix packages (if any remaining) that break as a result, which is a
>    rather trivial thing to do.
>
> Thoughts?
>
> Thanks
> -Ben
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From phil at bolthole.com  Tue Jul 13 22:02:21 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 13 Jul 2010 13:02:21 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
Message-ID: <AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>

>> I'm counter-proposing this:
>>
>> 1. Remove all share/locale/* from cswcommon
>> 2. Keep coreutils as it is.
>> 3. Fix packages (if any remaining) that break as a result, which is a
>>    rather trivial thing to do.


(again, from fuzzy memory..) I dont think its so much that "packages break".
It's that when users try to do something "interesting" with LC_TIME,
then almost *all* packages "break", unless there is the symlink from
LC_TIME->messages.
Which is presumably why I put the symlink into common, rather than
having one particular package 'fix" this.

odd example: Lets say you wanted your regular locale to be "X", but
for some reason, wanted your time handling to be in the style of
locale "Y".
(For example, if you're stuck in yankee land, but actually like ISO
time format standards ;-)

This can only happen, if you actually HAVE "LC_TIME" directories, I think?

From bwalton at opencsw.org  Wed Jul 14 03:44:59 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 13 Jul 2010 21:44:59 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
Message-ID: <1279071647-sup-2856@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Tue Jul 13 16:02:21 -0400 2010:

> It's that when users try to do something "interesting" with LC_TIME,
> then almost *all* packages "break", unless there is the symlink from
> LC_TIME->messages.

If that were true then wouldn't setting LC_TIME to a locale that isn't
currently installed also "break" things?

> This can only happen, if you actually HAVE "LC_TIME" directories, I
> think?

I don't think that's true.

You're still overlooking the fact that symlinking the directories is
removing the ability of a program to deliver separate .mo files for
the various categories (_CTYPE, _MONETARY and _NUMERIC are also
options a program might use).

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


From james at opencsw.org  Wed Jul 14 10:32:55 2010
From: james at opencsw.org (James Lee)
Date: Wed, 14 Jul 2010 08:32:55 GMT
Subject: [csw-maintainers] Providing parent directories for pkgmap
 entries
In-Reply-To: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
References: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
Message-ID: <20100714.8325500.1948303005@gyor.oxdrove.co.uk>

On 13/07/10, 15:26:49, Maciej "(Matchek)" Blizinski <maciej at opencsw.org>
wrote regarding [csw-maintainers] Providing parent directories for pkgmap
entries:

> I've found an interesting issue and I can't decide whether it's a
> problem or not. If you look at the list of files here:
> http://www.opencsw.org/search/vsftpd/ -- there is a directory named
> /opt/csw/var/empty/vsftpd, but the directory  /opt/csw/var/empty is
> provided by neither vsftpd nor any of its dependencies.  During
> installation, /opt/csw/var/empty gets created. On uninstallation, the
> /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty
> is not.

> Is not providing the parent directory a bug?

Not if the parent directory is in a parent package, notably CSWcommon.
CSWcommon has directories surely to avoid duplicating directories in
sub packages, eg, avoiding 1000 entries for /opt/csw/bin in the package
database.

Note, most don't include common directories:
$ pkgchk -lp /opt/csw/bin
...



James.

From bonivart at opencsw.org  Wed Jul 14 10:52:50 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 14 Jul 2010 10:52:50 +0200
Subject: [csw-maintainers] Providing parent directories for pkgmap
	entries
In-Reply-To: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
References: <AANLkTiltL7nbHXyAGLhn7_Wx9w9pf5xWGr0zyL3jzlr3@mail.gmail.com>
Message-ID: <AANLkTinJImr29VLeFXouz6ARmCKBUvOvGaqOf0wmWkEr@mail.gmail.com>

On Tue, Jul 13, 2010 at 4:26 PM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
> I've found an interesting issue and I can't decide whether it's a
> problem or not. If you look at the list of files here:
> http://www.opencsw.org/search/vsftpd/ -- there is a directory named
> /opt/csw/var/empty/vsftpd, but the directory ?/opt/csw/var/empty is
> provided by neither vsftpd nor any of its dependencies. ?During
> installation, /opt/csw/var/empty gets created. On uninstallation, the
> /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty
> is not.
>
> Is not providing the parent directory a bug?

Sun recommends putting all needed directories in the none class so
they will be created first (of course also before files in the none
class). However, I think pkgadd is smart enough to create missing
directories on the fly which is what happened here. Since there's no
entry in the pkgmap for this directory (and pkgadd doesn't use
installf for missing dirs?) pkgrm will not clean it up.

This is probably only a problem when using CAS. With a simple "cp src
dest" we will get in trouble with missing dirs like in the case of
nrpe.

-- 
/peter

From bwalton at opencsw.org  Thu Jul 15 00:33:58 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 14 Jul 2010 18:33:58 -0400
Subject: [csw-maintainers] buildfarm updates
Message-ID: <1279146726-sup-155@pinkfloyd.chass.utoronto.ca>


Hi All,

I'm about to update the buildfarms to current.  I'll send another mail
when the updates are complete.

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


From bwalton at opencsw.org  Thu Jul 15 01:27:54 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 14 Jul 2010 19:27:54 -0400
Subject: [csw-maintainers] buildfarm updates
In-Reply-To: <1279146726-sup-155@pinkfloyd.chass.utoronto.ca>
References: <1279146726-sup-155@pinkfloyd.chass.utoronto.ca>
Message-ID: <1279150063-sup-9876@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Wed Jul 14 18:33:58 -0400 2010:

> I'm about to update the buildfarms to current.  I'll send another mail
> when the updates are complete.

This is now complete.

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


From phil at bolthole.com  Thu Jul 15 19:09:54 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 15 Jul 2010 10:09:54 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1279071647-sup-2856@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<1279071647-sup-2856@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTimVz7EvesHw0HHFWlLvuS_vaxbBmZKidm3yxZCw@mail.gmail.com>

On 7/13/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Tue Jul 13 16:02:21 -0400 2010:
>
>> It's that when users try to do something "interesting" with LC_TIME,
>> then almost *all* packages "break", unless there is the symlink from
>> LC_TIME->messages.
>
> If that were true then wouldn't setting LC_TIME to a locale that isn't
> currently installed also "break" things?
>


yes. but there's a difference between,
"It doesnt work because there's nothing to work with",
vs
"it doesnt work, because opencsw didnt put in a little effort to
connect the dots to what's already there".

> I don't think that's true.
>
> You're still overlooking the fact that symlinking the directories is
> removing the ability of a program to deliver separate .mo files for
> the various categories (_CTYPE, _MONETARY and _NUMERIC are also
> options a program might use).
>


Show me a program that delivers a separate .mo file for LC_TIME.
An actual FILE, that is different from files it delivers in other
directories, rather than a symlink.

From bwalton at opencsw.org  Thu Jul 15 19:26:22 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 15 Jul 2010 13:26:22 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTimVz7EvesHw0HHFWlLvuS_vaxbBmZKidm3yxZCw@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<1279071647-sup-2856@pink floyd.chass.utoronto.ca>
	<AANLkTimVz7EvesHw0HHFWlLvuS_vaxbBmZKidm3yxZCw@mail.gmail.com>
Message-ID: <1279214703-sup-3791@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Jul 15 13:09:54 -0400 2010:

> yes. but there's a difference between,
> "It doesnt work because there's nothing to work with",
> vs
> "it doesnt work, because opencsw didnt put in a little effort to
> connect the dots to what's already there".

I guess you do know better than the people that designed
gettext/libintl afterall.

> Show me a program that delivers a separate .mo file for LC_TIME.  An
> actual FILE, that is different from files it delivers in other
> directories, rather than a symlink.

There aren't any (you know because you searched before typing).
That's not the point.  The point is that there could be.  The system
allows for it and the kludge you're trying to hold on to breaks this.

-Ben

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


From bwalton at opencsw.org  Thu Jul 15 19:51:31 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 15 Jul 2010 13:51:31 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTimVz7EvesHw0HHFWlLvuS_vaxbBmZKidm3yxZCw@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<1279071647-sup-2856@pink floyd.chass.utoronto.ca>
	<AANLkTimVz7EvesHw0HHFWlLvuS_vaxbBmZKidm3yxZCw@mail.gmail.com>
Message-ID: <1279216215-sup-818@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Thu Jul 15 13:09:54 -0400 2010:

> > If that were true then wouldn't setting LC_TIME to a locale that isn't
> > currently installed also "break" things?
> 
> yes. but there's a difference between,

You also missed what I was aiming at here...I'm saying that things
_don't_ break if you set LC_TIME to a bad value.  At least not
anything that I tried broke.  Got a counterexample that shows
something that _does_ break?

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


From phil at bolthole.com  Fri Jul 16 23:43:50 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 16 Jul 2010 14:43:50 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1279216215-sup-818@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<AANLkTimVz7EvesHw0HHFWlLvuS_vaxbBmZKidm3yxZCw@mail.gmail.com>
	<1279216215-sup-818@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>

On Thu, Jul 15, 2010 at 10:51 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Thu Jul 15 13:09:54 -0400 2010:
>
>> > If that were true then wouldn't setting LC_TIME to a locale that isn't
>> > currently installed also "break" things?
>>
>> yes. but there's a difference between,
>
> You also missed what I was aiming at here...I'm saying that things
> _don't_ break if you set LC_TIME to a bad value. ?At least not
> anything that I tried broke. ?Got a counterexample that shows
> something that _does_ break?
>

sorry about the misinterpretation of what you wrote.
what I wrote is still basically the same either way though.
Things dont technically "break" in the crash sense. But they dont
"work right". they just revert to as if it was not set in the first
place.


Would you mind doing a little research&inquiry into why specifically
the coreutils people provided those symlinks, please?

As in, finding out from them what specifically works, with their links
in place, and what breaks,if they are not in place?

From bwalton at opencsw.org  Sun Jul 18 23:32:09 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 18 Jul 2010 17:32:09 -0400
Subject: [csw-maintainers] Fwd: OpenCSW question about package docbookxsl
Message-ID: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca>

Hi All,

Is there a good way of dealing with this type of form spam from the
Wordpress side?

Thanks
-Ben

--- Begin forwarded message from xqottf ---
From: xqottf <xqottf at iwdbcj.com>
To: bwalton <bwalton at opencsw.org>
Date: Sun, 18 Jul 2010 16:13:10 -0400
Subject: OpenCSW question about package docbookxsl

BWQWCb  <a href=\"http://pxchmjoxibgh.com/\">pxchmjoxibgh</a>, [url=http://vgdnojivajsd.com/]vgdnojivajsd[/url], [link=http://iwrwxhlkncmn.com/]iwrwxhlkncmn[/link], http://dnogpsxnmekm.com/
--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From maciej at opencsw.org  Mon Jul 19 00:43:13 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Sun, 18 Jul 2010 23:43:13 +0100
Subject: [csw-maintainers] Fwd: OpenCSW question about package docbookxsl
In-Reply-To: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca>
References: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTi=er_wtrPV02ZaqhOB2Brb010nuFmGe0WUZoLoX@mail.gmail.com>

No dia 18 de Julho de 2010 22:32, Ben Walton <bwalton at opencsw.org> escreveu:
> Is there a good way of dealing with this type of form spam from the
> Wordpress side?

Maybe reCaptcha?

From maciej at opencsw.org  Mon Jul 19 10:50:53 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Mon, 19 Jul 2010 09:50:53 +0100
Subject: [csw-maintainers] New features in checkpkg
Message-ID: <AANLkTikpEnn7ffwtonkAre4Z9iymvRUNYcV=Hurg8Cr7@mail.gmail.com>

I've just pushed a relatively big update[1] to checkpkg.  Here's the
summary of changes:

* understands alternative dependencies; if two packages provide
foo.so.1, dependency on any of them is sufficient

* offers better on-screen messages, e.g. explains the specifics of
every soname-not-found error, or a needed dependency

* supports $ORIGIN in RPATH, including relative paths such as "$ORIGIN/.."

* performance tweaks allow it to process the whole catalog in ~90
minutes including extracting all packages, or in 30 minutes for
incremental updates

* uses database backend for package stats storage


You may purge your whole ~/.checkpkg directories.

To get the update, please update your GAR sources.  As always, if
there are any problems after the update, please contact me on #opencsw
or via e-mail.

Maciej

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

From bwalton at opencsw.org  Mon Jul 19 17:22:31 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Mon, 19 Jul 2010 11:22:31 -0400
Subject: [csw-maintainers] Fwd: OpenCSW question about package docbookxsl
In-Reply-To: <AANLkTi=er_wtrPV02ZaqhOB2Brb010nuFmGe0WUZoLoX@mail.gmail.com>
References: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=er_wtrPV02ZaqhOB2Brb010nuFmGe0WUZoLoX@mail.gmail.com>
Message-ID: <1279552925-sup-7424@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej (Matchek) Blizinski's message of Sun Jul 18 18:43:13 -0400 2010:

> Maybe reCaptcha?

That would be a worthwhile plugin...Any of the wordpress folks think
it would be ok to incorporate?

Thanks
-Ben

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


From maciej at opencsw.org  Tue Jul 20 15:43:15 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 20 Jul 2010 14:43:15 +0100
Subject: [csw-maintainers] New features in checkpkg
In-Reply-To: <AANLkTikpEnn7ffwtonkAre4Z9iymvRUNYcV=Hurg8Cr7@mail.gmail.com>
References: <AANLkTikpEnn7ffwtonkAre4Z9iymvRUNYcV=Hurg8Cr7@mail.gmail.com>
Message-ID: <AANLkTilxR26Hs4uahZlwMq8bD6YYBKohNH9BD1UYV2xK@mail.gmail.com>

Just committed two new features:

1. Allowing missing libm.so.2 (64-bit binaries can't find it on Solaris 9 x86).

2. Checking the actual architecture of binaries.

There are 3 places in a package which the architecture is declared:
the file name, the pkginfo and the content of the binary.  So far only
the first two were checked.  From now on, all three must be in sync
for the package to pass.

From bonivart at opencsw.org  Tue Jul 20 18:04:30 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 20 Jul 2010 18:04:30 +0200
Subject: [csw-maintainers] Problems with ftp.df.lth.se mirror
Message-ID: <AANLkTin7HqYoPrra07aQux9v_JC_EaPJO87qxvSZ4yee@mail.gmail.com>

The Swedish mirror has had a major HW-problem and is finally up again
but it seems to be unable to sync from us. This is a manual connection
they did:

klump% rsync rsync.opencsw.org::csw
@ERROR: access denied to csw from ftp.df.lth.se (194.47.250.18)
rsync error: error starting client-server protocol (code 5) at
main.c(1522) [receiver=3.0.3]

Do we only allow syncing from certain IP-addresses? They have switched
from 194.47.250.22 to .18.

-- 
/peter

From phil at bolthole.com  Tue Jul 20 18:37:36 2010
From: phil at bolthole.com (Philip Brown)
Date: Tue, 20 Jul 2010 09:37:36 -0700
Subject: [csw-maintainers] Problems with ftp.df.lth.se mirror
In-Reply-To: <AANLkTin7HqYoPrra07aQux9v_JC_EaPJO87qxvSZ4yee@mail.gmail.com>
References: <AANLkTin7HqYoPrra07aQux9v_JC_EaPJO87qxvSZ4yee@mail.gmail.com>
Message-ID: <AANLkTikrV-cYgi4iebjZCIvLoQhJjBkARBoSBrBTkQcj@mail.gmail.com>

it's whatever they supplied, either name or ip.
apparently they previously supplied ip instead of name. do you know if
they'd like to switch to name?

On Tuesday, July 20, 2010, Peter Bonivart <bonivart at opencsw.org> wrote:
> The Swedish mirror has had a major HW-problem and is finally up again
> but it seems to be unable to sync from us. This is a manual connection
> they did:
>
> klump% rsync rsync.opencsw.org::csw
> @ERROR: access denied to csw from ftp.df.lth.se (194.47.250.18)
> rsync error: error starting client-server protocol (code 5) at
> main.c(1522) [receiver=3.0.3]
>
> Do we only allow syncing from certain IP-addresses? They have switched
> from 194.47.250.22 to .18.
>
> --
> /peter
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From bonivart at opencsw.org  Tue Jul 20 18:50:50 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 20 Jul 2010 18:50:50 +0200
Subject: [csw-maintainers] Problems with ftp.df.lth.se mirror
In-Reply-To: <AANLkTikrV-cYgi4iebjZCIvLoQhJjBkARBoSBrBTkQcj@mail.gmail.com>
References: <AANLkTin7HqYoPrra07aQux9v_JC_EaPJO87qxvSZ4yee@mail.gmail.com> 
	<AANLkTikrV-cYgi4iebjZCIvLoQhJjBkARBoSBrBTkQcj@mail.gmail.com>
Message-ID: <AANLkTin3cAycH3AUpqoIpytvqWfHS5FNpj8PJGOQT2vd@mail.gmail.com>

On Tue, Jul 20, 2010 at 6:37 PM, Philip Brown <phil at bolthole.com> wrote:
> it's whatever they supplied, either name or ip.
> apparently they previously supplied ip instead of name. do you know if
> they'd like to switch to name?

Name seems more robust.

-- 
/peter

From bwalton at opencsw.org  Thu Jul 22 03:54:55 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 21 Jul 2010 21:54:55 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<AANLkTimVz7EvesHw0HHFWlL vuS_vaxbBmZKidm3yxZCw@mail.gmail.com>
	<1279216215-sup-818@pinkfloyd.chass.utoronto.ca>
	<AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
Message-ID: <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Jul 16 17:43:50 -0400 2010:

> what I wrote is still basically the same either way though.

No.  It isn't.  What's you've done is wrong.  In the technical sense.
It goes against the grain of what gettext is trying to provide.

> Things dont technically "break" in the crash sense. But they dont
> "work right". they just revert to as if it was not set in the first
> place.

Right.  This is the _intended_ behaviour.

> Would you mind doing a little research&inquiry into why specifically
> the coreutils people provided those symlinks, please?

I'm not going to bother them with this.  I had previously combed
through the code and there are places where they explicitly set the
category to LC_TIME though.

> As in, finding out from them what specifically works, with their
> links in place, and what breaks,if they are not in place?

This is doing nothing but wasting my time.  I've already read through
the gettext docs.  The symlinks at the directory level are the wrong
approach here.  I'll pose a question for you to research instead.
What happens if all of the following are true:

1. CSWcommon continues providing the directory level symlinks making
   LC_TIME/$foo equivalent to LC_MESSAGES/$foo.
2. A package delivers locale files for one of the locales for which #1
   above is true.
3. The package in #2 intends to deliver separate .mo files, which is
   perfectly withing the gettext specifications.

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


From phil at bolthole.com  Thu Jul 22 19:28:32 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 22 Jul 2010 10:28:32 -0700
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org>
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org>
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com>
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com>
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com>
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com>
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com>
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com>
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com>
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com>
	<AANLkTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com>
Message-ID: <AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com>

Mrrrr... accidentallysent this only to Maciej. Resending:


On 7/22/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 22 de Julho de 2010 15:48, Dagobert Michelsen <dam at opencsw.org>
> escreveu:
>>
>> is not that exact. Maybe Maciej has a more accurate information about
>> packages
>> linking to /opt/csw/lib/libdb-4.7.so
>
> I don't have yet code to create such report, I'm not that far away
> from it either.

the old search webpage already included that functionality. and
happily, the new search appears to have inherited it :)

putting in libdb-4.7.so in the file search, and using "exact match",
will give you a list of packages that have that specific name in the
"NEEDED" section of the ELF header thingamajigs.

Currently, that would appear to be:

   ---------

The following packages are depending on the library libdb-4.7.so.
Package
CSWap2modperl
CSWbdb47
CSWirssi
CSWmodperl
CSWooocore
CSWperl
CSWpmberkeleydb
CSWpython
CSWruby

From maciej at opencsw.org  Thu Jul 22 20:36:31 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Thu, 22 Jul 2010 19:36:31 +0100
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org> 
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org> 
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com> 
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com> 
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com> 
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com> 
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com> 
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com> 
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com> 
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com> 
	<AANLkTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com> 
	<AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com>
Message-ID: <AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com>

No dia 22 de Julho de 2010 18:28, Philip Brown <phil at bolthole.com> escreveu:
> Mrrrr... accidentallysent this only to Maciej. Resending:
>
>
> On 7/22/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> No dia 22 de Julho de 2010 15:48, Dagobert Michelsen <dam at opencsw.org>
>> escreveu:
>>>
>>> is not that exact. Maybe Maciej has a more accurate information about
>>> packages
>>> linking to /opt/csw/lib/libdb-4.7.so
>>
>> I don't have yet code to create such report, I'm not that far away
>> from it either.
>
> the old search webpage already included that functionality. and
> happily, the new search appears to have inherited it :)
>
> putting in libdb-4.7.so in the file search, and using "exact match",
> will give you a list of packages that have that specific name in the
> "NEEDED" section of the ELF header thingamajigs.

Let's suppose you had a binary needing libdb-4.7.so, with the following RPATH:

/opt/csw/lib:/opt/csw/bdb47/lib

It would get listed on in your search, even though it doesn't depend
on the library in /opt/csw/lib.

From phil at bolthole.com  Thu Jul 22 21:20:56 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 22 Jul 2010 12:20:56 -0700
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org>
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org>
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com>
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com>
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com>
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com>
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com>
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com>
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com>
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com>
	<AANLkTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com>
	<AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com>
	<AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com>
Message-ID: <AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com>

On 7/22/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 22 de Julho de 2010 18:28, Philip Brown <phil at bolthole.com> escreveu:
>
>>
>> the old search webpage already included that functionality. and
>> happily, the new search appears to have inherited it :)
>>
>> putting in libdb-4.7.so in the file search, and using "exact match",
>> will give you a list of packages that have that specific name in the
>> "NEEDED" section of the ELF header thingamajigs.
>
> Let's suppose you had a binary needing libdb-4.7.so, with the following
> RPATH:
>
> /opt/csw/lib:/opt/csw/bdb47/lib
>
> It would get listed on in your search, even though it doesn't depend
> on the library in /opt/csw/lib.


I'm not sure I understand why you are writing this. So, I will add
more information and hopefully clear things up.

First off, let me say that the existing library search is not
"perfect". It does not cover all possible library search cases.
However, it does cover a particular set of interest very well:

If a library has a unique "SONAME", then it will tell you fairly
accurately which packages have something depending on that SONAME.

Please note: pure "SONAME".  Which is a standalone filename, that has
no RPATH component to it.o

So, since dbd4.7 does have a unique SONAME of libdb-47.so, it
accurately tells us which packages need that library.  Which I thought
was the original question.

It is unfortunately confusing, because the current interface is
through the "filename" search field, which is bad and misleading.
But that being said, the library dependancy function is quite useful :)

From maciej at opencsw.org  Fri Jul 23 09:18:28 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 23 Jul 2010 08:18:28 +0100
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org> 
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org> 
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com> 
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com> 
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com> 
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com> 
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com> 
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com> 
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com> 
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com> 
	<AANLkTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com> 
	<AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com> 
	<AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com> 
	<AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com>
Message-ID: <AANLkTikiFAR6v_X2rfmHQijxtqBtuuW9LoZm1w8zkK80@mail.gmail.com>

No dia 22 de Julho de 2010 20:20, Philip Brown <phil at bolthole.com> escreveu:
> I'm not sure I understand why you are writing this. So, I will add
> more information and hopefully clear things up.
>
> First off, let me say that the existing library search is not
> "perfect". It does not cover all possible library search cases.
> However, it does cover a particular set of interest very well:
>
> If a library has a unique "SONAME", then it will tell you fairly
> accurately which packages have something depending on that SONAME.
>
> Please note: pure "SONAME". ?Which is a standalone filename, that has
> no RPATH component to it.o
>
> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it
> accurately tells us which packages need that library. ?Which I thought
> was the original question.

Close, but not exactly.  The original question was: "can we retire
CSWbdb?"  The follow up question was "which packages would break if
the /opt/csw/lib/libdb-4.7.so symlink were removed?

The same SONAME is currently provided by two paths, and we're looking
for packages with binaries that meet two criteria:

1. need libdb-47.so
2. don't have /opt/csw/bdb47/lib in the RPATH

From dam at opencsw.org  Fri Jul 23 12:08:30 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 23 Jul 2010 12:08:30 +0200
Subject: [csw-maintainers] Election of a new board
References: <253E9EDF-0B03-4DAA-8116-F8916F379DA8@baltic-online.de>
Message-ID: <A1D5A404-22CA-4B73-837C-FF5B0F5382EA@opencsw.org>

Fellow maintainers,

first I want to apologize for not pushing the election process of the
board earlier as hard as it would have been necessary. To get this
thing ahead I have set up a wiki page at
   http://wiki.opencsw.org/BoardElection
where all candidates can introduce themselves and can outline what
they intend to do if they are elected. Please set up your applications
timely, so the election can take place end of August.


Best regards

  -- Dago

From maciej at opencsw.org  Fri Jul 23 14:35:50 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 23 Jul 2010 13:35:50 +0100
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTikiFAR6v_X2rfmHQijxtqBtuuW9LoZm1w8zkK80@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org> 
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org> 
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com> 
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com> 
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com> 
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com> 
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com> 
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com> 
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com> 
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com> 
	<AANLkTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com> 
	<AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com> 
	<AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com> 
	<AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com> 
	<AANLkTikiFAR6v_X2rfmHQijxtqBtuuW9LoZm1w8zkK80@mail.gmail.com>
Message-ID: <AANLkTinJcrOR9iCtUw676HjiEmmZtV5xRTFvxiVw1hZ3@mail.gmail.com>

No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski
<maciej at opencsw.org> escreveu:
> No dia 22 de Julho de 2010 20:20, Philip Brown <phil at bolthole.com> escreveu:
>> I'm not sure I understand why you are writing this. So, I will add
>> more information and hopefully clear things up.
>>
>> First off, let me say that the existing library search is not
>> "perfect". It does not cover all possible library search cases.
>> However, it does cover a particular set of interest very well:
>>
>> If a library has a unique "SONAME", then it will tell you fairly
>> accurately which packages have something depending on that SONAME.
>>
>> Please note: pure "SONAME". ?Which is a standalone filename, that has
>> no RPATH component to it.o
>>
>> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it
>> accurately tells us which packages need that library. ?Which I thought
>> was the original question.
>
> Close, but not exactly. ?The original question was: "can we retire
> CSWbdb?" ?The follow up question was "which packages would break if
> the /opt/csw/lib/libdb-4.7.so symlink were removed?"
>
> The same SONAME is currently provided by two paths, and we're looking
> for packages with binaries that meet two criteria:
>
> 1. need libdb-47.so
> 2. don't have /opt/csw/bdb47/lib in the RPATH

I've examined the packages and here are the two packages that would
break if CSWbdb were removed:

CSWap2modperl
CSWmodperl

Maciej

From dam at opencsw.org  Fri Jul 23 14:47:23 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 23 Jul 2010 14:47:23 +0200
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTinJcrOR9iCtUw676HjiEmmZtV5xRTFvxiVw1hZ3@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org>
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org>
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com>
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com>
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com>
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com>
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com>
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com>
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com>
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com>
	<AANL kTim75v5w7Oaub3Uf58XlHU1Gm83T5nUM6iATChop@mail.gmail.com>
	<AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com>
	<AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com>
	<AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com>
	<AANLkTikiFAR6v_X2rfmHQijxtqBtuuW9LoZm1w8zkK80@mail.gmail.com>
	<AANLkTinJcrOR9iCtUw676HjiEmmZtV5xRTFvxiVw1hZ3@mail.gmail.com>
Message-ID: <177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org>

Hi Maciej,

Am 23.07.2010 um 14:35 schrieb Maciej (Matchek) Blizinski:
> No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> escreveu:
>> No dia 22 de Julho de 2010 20:20, Philip Brown <phil at bolthole.com>  
>> escreveu:
>>> I'm not sure I understand why you are writing this. So, I will add
>>> more information and hopefully clear things up.
>>>
>>> First off, let me say that the existing library search is not
>>> "perfect". It does not cover all possible library search cases.
>>> However, it does cover a particular set of interest very well:
>>>
>>> If a library has a unique "SONAME", then it will tell you fairly
>>> accurately which packages have something depending on that SONAME.
>>>
>>> Please note: pure "SONAME".  Which is a standalone filename, that  
>>> has
>>> no RPATH component to it.o
>>>
>>> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it
>>> accurately tells us which packages need that library.  Which I  
>>> thought
>>> was the original question.
>>
>> Close, but not exactly.  The original question was: "can we retire
>> CSWbdb?"  The follow up question was "which packages would break if
>> the /opt/csw/lib/libdb-4.7.so symlink were removed?"
>>
>> The same SONAME is currently provided by two paths, and we're looking
>> for packages with binaries that meet two criteria:
>>
>> 1. need libdb-47.so
>> 2. don't have /opt/csw/bdb47/lib in the RPATH
>
> I've examined the packages and here are the two packages that would
> break if CSWbdb were removed:
>
> CSWap2modperl
> CSWmodperl

Ok, then I'll remove CSWbdb from the current/ on the buildfarm.


Best regards

   -- Dago


From phil at bolthole.com  Sat Jul 24 02:47:29 2010
From: phil at bolthole.com (Philip Brown)
Date: Fri, 23 Jul 2010 17:47:29 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<1279216215-sup-818@pinkfloyd.chass.utoronto.ca>
	<AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
	<1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>

On 7/21/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Jul 16 17:43:50 -0400 2010:
>
>> Would you mind doing a little research&inquiry into why specifically
>> the coreutils people provided those symlinks, please?
>
> I'm not going to bother them with this.  I had previously combed
> through the code and there are places where they explicitly set the
> category to LC_TIME though.

Okay, so then you know for a fact that having "LC_TIME" properly
supported, is useful.
 ....


>
>> As in, finding out from them what specifically works, with their
>> links in place, and what breaks,if they are not in place?
>
> This is doing nothing but wasting my time.  I've already read through
> the gettext docs.  The symlinks at the directory level are the wrong
> approach here.


that's your opinion. I have a different opinion.
I am open to listening to further facts on why you have your opinion.
But it seems you are not interested in gathering more facts.



  I'll pose a question for you to research instead.
> What happens if all of the following are true:
>
> 1. CSWcommon continues providing the directory level symlinks making
>    LC_TIME/$foo equivalent to LC_MESSAGES/$foo.
> 2. A package delivers locale files for one of the locales for which #1
>    above is true.
> 3. The package in #2 intends to deliver separate .mo files, which is
>    perfectly withing the gettext specifications.
>

Then I'd be happy to reconsider things.

Given, however, that this has not happened in the (6?) (7?) years i've
been doing this, I'm thinking this is quite unlikely :)

So until either that happens, or you wish to dig up more information
on why coreutils decided on using symlinks instead of separate files
AND that information indicates the current cswcommon behaviour is
bad... current behaviour will stay.  WIth the addition that cswcommon
should be modified to have ALL LC_TIME dirs symlinked, rather than
only partially.

From bonivart at opencsw.org  Sat Jul 24 21:27:13 2010
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 24 Jul 2010 21:27:13 +0200
Subject: [csw-maintainers] Problem with mirror updates?
Message-ID: <AANLkTik7X6gpJIX6QtuQ3Ixf0NvDyQMYcWcBbPF4wCBQ@mail.gmail.com>

Despite a bunch of packages being "batched" the last few days I see no
updates on the mirrors since July 15th.

-- 
/peter

From phil at bolthole.com  Sun Jul 25 00:46:49 2010
From: phil at bolthole.com (Philip Brown)
Date: Sat, 24 Jul 2010 15:46:49 -0700
Subject: [csw-maintainers] Problem with mirror updates?
In-Reply-To: <AANLkTik7X6gpJIX6QtuQ3Ixf0NvDyQMYcWcBbPF4wCBQ@mail.gmail.com>
References: <AANLkTik7X6gpJIX6QtuQ3Ixf0NvDyQMYcWcBbPF4wCBQ@mail.gmail.com>
Message-ID: <AANLkTi=WNSS135hxw9WmibUwnGiohbsSw1zq8o1pXd2r@mail.gmail.com>

awwright. I was hoping to get a fixed version of unbound for this
batch but I guess I'll release it now anyway

On Saturday, July 24, 2010, Peter Bonivart <bonivart at opencsw.org> wrote:
> Despite a bunch of packages being "batched" the last few days I see no
> updates on the mirrors since July 15th.
>
> --
> /peter
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From bwalton at opencsw.org  Sun Jul 25 17:17:11 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 25 Jul 2010 11:17:11 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<1279216215-sup-818@pinkf loyd.chass.utoronto.ca>
	<AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
	<1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>
	<AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>
Message-ID: <1280067662-sup-5757@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Jul 23 20:47:29 -0400 2010:
> > I'm not going to bother them with this.  I had previously combed
> > through the code and there are places where they explicitly set the
> > category to LC_TIME though.
> 
> Okay, so then you know for a fact that having "LC_TIME" properly
> supported, is useful.
>  ....

Right.  The key word here is properly.  I'm aiming for a solution that
is both functional _and_ future proof.  The proposal is also in the
spirit of how gettext is intended to work.

> >> As in, finding out from them what specifically works, with their
> >> links in place, and what breaks,if they are not in place?
> >
> > This is doing nothing but wasting my time.  I've already read through
> > the gettext docs.  The symlinks at the directory level are the wrong
> > approach here.
> 
> 
> that's your opinion. I have a different opinion.
> I am open to listening to further facts on why you have your opinion.
> But it seems you are not interested in gathering more facts.

What are you talking about?  I'm the only one that has brought facts
into this discussion.  You're resorting to hand-waving, undefined
references to vague memories of why you added these links and
decisions by fiat.  (Sadly the third is expected behaviour...the first
two are what I find out of character here.)

I on the other hand have read the gettext docs, an action which I
think is more germane to the issue than pestering the coreutils folks
about their specific use of gettext.  After all, we're discussing a
gettext problem here, not a coreutils problem.  The coreutils package
simply brought to light the error.

Have you, by the way, read the gettext docs?  Recently?

I've clearly outlined why your solution is wrong, why it hasn't yet
harmed anything and why my proposed solution is better technically.
(That is in addition to being less work overall, btw.)

You seem stuck on the fact that providing symlinks at the directory
level is somehow going to magically improve the gettext capability of
all packages.  It won't.

It only 'fixes' packages which have a defect in that they set a
category for gettext and then fail to provide .mo files there.  This
is a package bug.  In every day use though, it's no different than
when a program is only partially translated.  Programs don't crash
when you set the locale to a value for which your app hasn't provided
.mo files...regardless of the category.

> > 1. CSWcommon continues providing the directory level symlinks making
> >    LC_TIME/$foo equivalent to LC_MESSAGES/$foo.
> > 2. A package delivers locale files for one of the locales for which #1
> >    above is true.
> > 3. The package in #2 intends to deliver separate .mo files, which is
> >    perfectly withing the gettext specifications.
> >
> 
> Then I'd be happy to reconsider things.
> 
> Given, however, that this has not happened in the (6?) (7?) years i've
> been doing this, I'm thinking this is quite unlikely :)

It has happened now.  CSWcoreutils is using the gettext system in a
valid manner and your actions in CSWcommon have caused a conflict.  A
symlink is a separate file.  The directory level symlinks prevent a
package from delivering files in a manner consistent with what gettext
allows for.

> So until either that happens, or you wish to dig up more information
> on why coreutils decided on using symlinks instead of separate files
> AND that information indicates the current cswcommon behaviour is
> bad... current behaviour will stay.  WIth the addition that
> cswcommon should be modified to have ALL LC_TIME dirs symlinked,
> rather than only partially.

Why short change the system here?  What makes LC_TIME more special
than LC_NUMERIC and the other various categories?

Your argument is flaky.  It's like saying: I know this function has a
segfault but nobody calls this function with arguments that trigger
the crash.  I'm not fixing the segfault...

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


From rupert at opencsw.org  Mon Jul 26 13:00:28 2010
From: rupert at opencsw.org (rupert THURNER)
Date: Mon, 26 Jul 2010 13:00:28 +0200
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org> 
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org> 
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com> 
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com> 
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com> 
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com> 
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com> 
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com> 
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com> 
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com> 
	<AANLkTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com> 
	<AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com> 
	<AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com> 
	<AANLkTikiFAR6v_X2rfmHQijxtqBtuuW9LoZm1w8zkK80@mail.gmail.com> 
	<AANLkTinJcrOR9iCtUw676HjiEmmZtV5xRTFvxiVw1hZ3@mail.gmail.com> 
	<177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org>
Message-ID: <AANLkTikLNKPdEJUt68iH-FfuS3wd5AcwUhRY=mdn6WV2@mail.gmail.com>

many thanks, now it gets one step further. the error is that configure
tries to use an old db_open (dbopen) ... but i could not figure out
where it gets the idea to try this:

rupert at current9s:~/mgar/pkg/apr-util/trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9
$ /opt/studio/SOS12/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=v8
-xnorunpath -mt -I/opt/csw/include -DSOLARIS2=9
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE
-I/opt/csw/bdb47/include -m32 -xarch=v8 -norunpath -L/opt/csw/lib
-L/opt/csw/bdb47/lib conftest.c -ldb  -lrt
cc: Warning: illegal option -norunpath
"conftest.c", line 33: warning: statement not reached
Undefined                       first referenced
 symbol                             in file
dbopen                              conftest.o
ld: fatal: Symbol referencing errors. No output written to conftest



and one hint was there:
  http://old.nabble.com/undefined-symbol-dbopen-for-BerkeleyDB.4.7-td20439750.html

and another hint here:
http://monkey.org/~dugsong/dsniff/faq.html#Make%20dies%20with%20undefined%20symbol%20{{EX:dbopen}}%20or%20{{EX:__db185_open}}%22

    2.5. Make dies with undefined symbol dbopen  or __db185_open"?
    Be sure to build Berkeley DB with ./configure --enable-compat185.


the program is:

$ cat conftest.c
/* confdefs.h.  */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_UNISTD_H 1
#define HAVE_LBER_H 1
#define HAVE_LDAP_H 1
#define LDAP_SET_REBIND_PROC_THREE 1
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char dbopen ();
int
main ()
{
return dbopen ();
  ;
  return 0;
}






On Fri, Jul 23, 2010 at 14:47, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Maciej,
>
> Am 23.07.2010 um 14:35 schrieb Maciej (Matchek) Blizinski:
>>
>> No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski
>> <maciej at opencsw.org> escreveu:
>>>
>>> No dia 22 de Julho de 2010 20:20, Philip Brown <phil at bolthole.com>
>>> escreveu:
>>>>
>>>> I'm not sure I understand why you are writing this. So, I will add
>>>> more information and hopefully clear things up.
>>>>
>>>> First off, let me say that the existing library search is not
>>>> "perfect". It does not cover all possible library search cases.
>>>> However, it does cover a particular set of interest very well:
>>>>
>>>> If a library has a unique "SONAME", then it will tell you fairly
>>>> accurately which packages have something depending on that SONAME.
>>>>
>>>> Please note: pure "SONAME". ?Which is a standalone filename, that has
>>>> no RPATH component to it.o
>>>>
>>>> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it
>>>> accurately tells us which packages need that library. ?Which I thought
>>>> was the original question.
>>>
>>> Close, but not exactly. ?The original question was: "can we retire
>>> CSWbdb?" ?The follow up question was "which packages would break if
>>> the /opt/csw/lib/libdb-4.7.so symlink were removed?"
>>>
>>> The same SONAME is currently provided by two paths, and we're looking
>>> for packages with binaries that meet two criteria:
>>>
>>> 1. need libdb-47.so
>>> 2. don't have /opt/csw/bdb47/lib in the RPATH
>>
>> I've examined the packages and here are the two packages that would
>> break if CSWbdb were removed:
>>
>> CSWap2modperl
>> CSWmodperl
>
> Ok, then I'll remove CSWbdb from the current/ on the buildfarm.
>
>
> Best regards
>
> ?-- Dago
>
>

From dam at opencsw.org  Mon Jul 26 13:14:00 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 26 Jul 2010 13:14:00 +0200
Subject: [csw-maintainers] BerkeleyDB upgrade
In-Reply-To: <AANLkTikLNKPdEJUt68iH-FfuS3wd5AcwUhRY=mdn6WV2@mail.gmail.com>
References: <C2783926-199E-4446-900A-54A34E8C6BFA@opencsw.org>
	<4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org>
	<F5BB8EA2-485D-4397-AE43-BC1433E4B22E@opencsw.org>
	<AANLkTinUwWbxracKtT7GV1MNd6qpHs-MjoLr2opnYfAa@mail.gmail.com>
	<AANLkTimvZFBaWWs-k1kWo9H1swEWbi3NFo4jPiChx3Ly@mail.gmail.com>
	<47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org>
	<AANLkTikg4xwHRFtGPJuxaosJnfEjeyQP_TWdD7rASuuW@mail.gmail.com>
	<515B314C-A719-498C-8861-DF71A52E513B@opencsw.org>
	<AANLkTimZZTTBYz8mNNvXb2_uUBBUS9YGXCkZ5Ot2xrYE@mail.gmail.com>
	<D369BB78-22E3-4FDE-87A9-0EE6DCA86B66@opencsw.org>
	<AANLkTikaypLhyEcC7wLfhqczEqF9_Tg1cuQhQN7FiH8_@mail.gmail.com>
	<28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org>
	<AANLkTimAp6bfuJ2ekGgGHkuFwxrafnrco9rjkLR-2_y5@mail.gmail.com>
	<89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org>
	<AANLkTileBP52cnv2yvlY7F_F6usiMVh9MaWjqVAQB0v0@mail.gmail.com>
	<A29CC6C2-F189-4D5A-BAD5-8A952FADD88B@opencsw.org>
	<AANLkTimzKoZCi=5cgpoTHs7O-AVREQm-07dN=Od7i1ME@mail.gmail.com>
	<AANL kTilU9ModHfedNJzTe7yjsQG8MPlVsE0Q189_4ApQ@mail.gmail.com>
	<AANLkTi=sARXv4=-Fx_V9Tox6hTmr_j31SE_E37BdsMBx@mail.gmail.com>
	<AANLkTin5P3oADbyuxfCEutIcunVSnlsVUvmFINE5pLJl@mail.gmail.com>
	<AANLkTikiFAR6v_X2rfmHQijxtqBtuuW9LoZm1w8zkK80@mail.gmail.com>
	<AANLkTinJcrOR9iCtUw676HjiEmmZtV5xRTFvxiVw1hZ3@mail.gmail.com>
	<177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org>
	<AANLkTikLNKPdEJUt68iH-FfuS3wd5AcwUhRY=mdn6WV2@mail.gmail.com>
Message-ID: <91F3A15F-74C5-4248-A017-11B73F7D4AF1@opencsw.org>

Hi Rupert,

Am 26.07.2010 um 13:00 schrieb rupert THURNER:
> many thanks, now it gets one step further. the error is that configure
> tries to use an old db_open (dbopen) ... but i could not figure out
> where it gets the idea to try this:

Please commit what you have and tell me the svn path so I can have a  
look.


Best regards

   -- Dago

From maciej at opencsw.org  Wed Jul 28 00:50:00 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Tue, 27 Jul 2010 23:50:00 +0100
Subject: [csw-maintainers] unixodbc-2.3.0 is available for testing
Message-ID: <AANLkTi=41W4JmXdfdKnNYa4m-FOCJkduwPoXsET2ZC5t@mail.gmail.com>

Are there any unixodbc users here?  Version 2.3.0 (updated from
2.2.14) is available for testing:

http://mirror.opencsw.org/experimental.html#maciej

Maciej

From bwalton at opencsw.org  Wed Jul 28 01:50:07 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 27 Jul 2010 19:50:07 -0400
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<1279216215-sup-818@pinkf loyd.chass.utoronto.ca>
	<AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
	<1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>
	<AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>
Message-ID: <1280274477-sup-699@pinkfloyd.chass.utoronto.ca>

Excerpts from Philip Brown's message of Fri Jul 23 20:47:29 -0400 2010:

> that's your opinion. I have a different opinion.
> I am open to listening to further facts on why you have your opinion.
> But it seems you are not interested in gathering more facts.

More facts have now been gathered.  This is from the gettext list:

--snip--
From: Bruno Haible <bruno at clisp.org>
Subject: Re: a question about distribution packaging
Date: Wed, 28 Jul 2010 01:31:56 +0200
References: <1280191508-sup-3360 at pinkfloyd.chass.utoronto.ca>
In-Reply-To: <1280191508-sup-3360 at pinkfloyd.chass.utoronto.ca>
Message-Id: <201007280131.57776.bruno at clisp.org>

Hi,

Ben Walton wrote:
> I'm hoping that someone can provide an authoritative answer on whether
> or not it is valid to ship $share_dir/locale/$LANG/LC_TIME (or
> LC_NUMERIC, etc) as a symlink pointed at LC_MESSAGES.
> 
> My viewpoint after reading the docs is that the symlink at the
> directory level is not valid.  While it's rare (and somewhat
> discouraged) that a package would deliver a separate .mo file in the
> LC_TIME directory, it is valid for the package to do so.  The
> directory-level symlink would prevent distributing separate .mo files.

I agree with your viewpoint. In a private discussion with Paul Eggert from
2002-01-15 to 2002-01-17, I came to the same conclusion and added the
EXTRA_LOCALE_CATEGORIES to the Makevars file for po/ directories. coreutils
uses this hook as a way of installing a file into
$share_dir/locale/$LANG/LC_TIME since November 2002.

> The alternate viewpoint is that LC_TIME symlinks haven't harmed
> anything in the 6+ years they've been shipped this way, so continuing
> (and expanding) the practice is acceptable.

A package can decide to install different .mo files in
  $share_dir/locale/$LANG/LC_MESSAGES/domain.mo
  $share_dir/locale/$LANG/LC_TIME/domain.mo

The gettext Makefile infrastructure currently does not support this
situation (it only supports installing the same .mo file as
  $share_dir/locale/$LANG/LC_MESSAGES/domain.mo
  $share_dir/locale/$LANG/LC_TIME/domain.mo)
but packages could get into this situation if they use their own Makefiles.

A single package that puts a symlink from LC_TIME to LC_MESSAGES breaks all
other packages that want to use this approach. Therefore it is not a good
idea to put this symlink.

Bruno
--snip--

Good enough?

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


From dam at opencsw.org  Wed Jul 28 09:26:13 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 28 Jul 2010 09:26:13 +0200
Subject: [csw-maintainers] Packaging up OraToolkit
In-Reply-To: <4C4F0F0C.5000205@opencsw.org>
References: <4C4A011F.40304@opencsw.org>
	<15137A99-519A-4DCA-9F4D-9EC91318BD31@opencsw.org>
	<4C4F0F0C.5000205@opencsw.org>
Message-ID: <B610B4F8-4FAF-42E8-8CCE-427EECCAC426@opencsw.org>

Hi David,

(adding maintainers@ to see if more people are interested in the  
package)

Am 27.07.2010 um 18:53 schrieb David D'Acquisto:
> Dagobert Michelsen wrote:
>> Am 23.07.2010 um 22:52 schrieb David D'Acquisto:
>>> i was considering packing my open source project www.oratoolkit.ch  
>>> with OpenCSW.
>>>
>>> Unfortunately I came to the result that I do not have many benefits.
>>
>> What kind of benefits did you expect? Of course your package will  
>> be much easier to
>> install for admins using OpenCSW.
>>
>
> Yes, this could be but when I meet Ihsan once he told me that with  
> OpenCSW there are some constraints which you have to follow. As far  
> as I know the installation directory has to be in /opt/opencsw or  
> whereever and the thing is that i am supporting different platforms  
> like Linux, AIX, HP-UX and Solaris. To make it easy I kept the  
> installation path for all platforms the same and choosed /opt/oracle/ 
> otk as the base install directory.

Correct. This is for consistency of the OpenCSW environment in total.

> This also because I am using appctl framework (http://appctl.sourceforge.net 
> ) which I am quite familiar.

I see. On Solaris the integration in the system-wide SMF would be  
favorable as all Solaris
admins must know that anyway and the functionality is comparable.

> When I say that I don't see many benefits from it then you should  
> also look it from package maintainer / developer point of view. This  
> is related with some work effort and I see there not many benefits  
> of supporting two packaging frameworks for Solaris. Time is precious  
> and therefore it makes for me only sense that someone who is  
> familiar with OpenCSW and Oracle should be responsible for the  
> package maintenance. I have the feeling that I am definitely the  
> wrong one.

I understand your problem. For myself I maintain the SE Toolkit and  
indeed make two kinds of
packages: the "legacy" one which installs into /opt/RICHPse as it  
always has been and an OpenCSW
one with OpenCSW standard pathes.

> As written in the last email I am however willing to contribute and  
> to make software changes to support it but not willing to take the  
> lead in the package maintenance. So, tell me how we proceed.

This is great. I'll see that we find someone to package it.

Jochen? ;-)

>>> With  this email I would like to say that you can delete my  
>>> account daviddac. Furthermore if there will be one day a package  
>>> maintainer interested in maintaining oratoolkit with OpenCSW then  
>>> feel free to contact me.
>>
>> This my indeed be the case.


Best regards

   -- Dago



From dam at opencsw.org  Wed Jul 28 09:31:13 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 28 Jul 2010 09:31:13 +0200
Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip
In-Reply-To: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca>
References: <AANLkTim4-yziO8vrvqsvoM+0B35t8BS_gF_A6yzr4D-1@mail.gmail.com>
	<1280278827-sup-1945@pinkfloyd.chass.utoronto.ca>
Message-ID: <E47F8E97-D307-4DF2-B4CD-A5D988A4782C@opencsw.org>

Hi,

Am 28.07.2010 um 03:01 schrieb Ben Walton:
> Excerpts from Maciej (Matchek) Blizinski's message of Tue Jul 27  
> 02:11:27 -0400 2010:
>
>> Can we remove the xmms package from the buildfarm?
>
> It's now removed, but this left a dangling dependency.  CSWfaad2
> depends on xmms which I found strange.  Then I looked at the file list
> delivered.  faad2 is dropping in:
>
> /opt/csw/lib/xmms
> /opt/csw/lib/xmms/Input
> /opt/csw/lib/xmms/Input/libmp4.a
> /opt/csw/lib/xmms/Input/libmp4.la
> /opt/csw/lib/xmms/Input/libmp4.so
>
> This should have been shipped as a separate faad2-xmms package.  I'm
> not going to worry about this.

Right. I made an approach to redo it but mpeg4ip is missing which  
needs some
in-depth know how about autoconf as some serious patching is required.
If someone is interested to help just let me know and I can point out  
the
specific issue there.


Best regards

   -- Dago


From dam at opencsw.org  Wed Jul 28 09:42:15 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 28 Jul 2010 09:42:15 +0200
Subject: [csw-maintainers] packaging gems
In-Reply-To: <1280286258-sup-3785@pinkfloyd.chass.utoronto.ca>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<1280286258-sup-3785@pinkfloyd.chass.utoronto.ca>
Message-ID: <672BC96C-3532-4397-8C56-569621C38FC0@opencsw.org>

Hi Ben,

Am 28.07.2010 um 05:05 schrieb Ben Walton:
> Excerpts from Ben Walton's message of Tue Jul 27 20:47:49 -0400 2010:
>
>> http://fedoraproject.org/wiki/Packaging/Ruby
>
> I've done some more groundwork (based on the rbgems category you
> started this morning Dago) toward getting gem packages.
>
> More to be done yet, but I was able to crank out a package from
> gem-rake/trunk.

Like for the CPAN stuff I introduced a new directory
   pkg/rbgems
so the directory names can keep the original GEM name.

I noticed you removed the forced addition of the GEM name to  
SPKG_DESC. I added
that to conform to the CPAN convention. Did you have a specific reason  
for
removing it? I find it valuable to have the original GEM name in the  
description
so I can grep for it on "pkginfo".


Best regards

   -- Dago



From dam at opencsw.org  Wed Jul 28 09:45:33 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 28 Jul 2010 09:45:33 +0200
Subject: [csw-maintainers] packaging gems
In-Reply-To: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
Message-ID: <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>

Hi Ben,

Am 28.07.2010 um 02:47 schrieb Ben Walton:
> Since you've both expressed interest in this recently, would you mind
> reading the gem-specific bits of the following guide from the fedora
> project?
>
> http://fedoraproject.org/wiki/Packaging/Ruby
>
> I'm curious about why they move the .so files out of the gemdir and
> into the sitearch dir.  Do you have any ideas about why this would be
> beneficial...?

Sorry, no clue. We could easily mimic this by looking into ARCHALL and
then setting the parameter accordingly.

BTW, there is
   http://rubyforge.org/projects/gem2rpm/
Maybe this can be used to rip out the dependencies and stuff to make
an initial GAR Makefile?


Best regards

   -- Dago

From dam at opencsw.org  Wed Jul 28 12:19:25 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 28 Jul 2010 12:19:25 +0200
Subject: [csw-maintainers] Packaging Ruby GEMs
Message-ID: <B2B2D2BB-84DB-470C-BF8F-9AB7A633B97C@opencsw.org>

Hi,

I just started a new project:
   http://mirror.opencsw.org/experimental.html#rubygems
Anybody feel free to jump in!


Best regards

   -- Dago


From bwalton at opencsw.org  Thu Jul 29 05:07:56 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 28 Jul 2010 23:07:56 -0400
Subject: [csw-maintainers] packaging gems
In-Reply-To: <1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
	<1280367168-sup-198@pinkfloyd.chass.utoronto.ca>
Message-ID: <1280372747-sup-1107@pinkfloyd.chass.utoronto.ca>

Excerpts from Ben Walton's message of Wed Jul 28 22:07:08 -0400 2010:

> How about the attached script?  It likely needs a bit of work yet, but
> it hits the basics.

A small update to use the exposed Gems api to grab the spec file
instead of spawning `gem specification ...` externally.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gem2pkg
Type: application/octet-stream
Size: 871 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20100728/638f044c/attachment.obj>

From phil at bolthole.com  Fri Jul 30 02:19:09 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 29 Jul 2010 17:19:09 -0700
Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip
In-Reply-To: <E47F8E97-D307-4DF2-B4CD-A5D988A4782C@opencsw.org>
References: <AANLkTim4-yziO8vrvqsvoM+0B35t8BS_gF_A6yzr4D-1@mail.gmail.com>
	<1280278827-sup-1945@pinkfloyd.chass.utoronto.ca>
	<E47F8E97-D307-4DF2-B4CD-A5D988A4782C@opencsw.org>
Message-ID: <AANLkTi=yG4GdzTZq1vvp_x21cUEMaz5DD970H2RzE2k5@mail.gmail.com>

xmms is ugly. and somewhat orphaned I heard. and there is xmms2. and...
its messy. so anyone else is hereby cordially invited to take it over :-D


On 7/28/10, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi,
>
> Am 28.07.2010 um 03:01 schrieb Ben Walton:
>> Excerpts from Maciej (Matchek) Blizinski's message of Tue Jul 27
>> 02:11:27 -0400 2010:
>>
>>> Can we remove the xmms package from the buildfarm?
>>
>> It's now removed, but this left a dangling dependency.  CSWfaad2
>> depends on xmms which I found strange.  Then I looked at the file list
>> delivered.  faad2 is dropping in:
>>
>> /opt/csw/lib/xmms
>> /opt/csw/lib/xmms/Input
>> /opt/csw/lib/xmms/Input/libmp4.a
>> /opt/csw/lib/xmms/Input/libmp4.la
>> /opt/csw/lib/xmms/Input/libmp4.so
>>
>> This should have been shipped as a separate faad2-xmms package.  I'm
>> not going to worry about this.
>
> Right. I made an approach to redo it but mpeg4ip is missing which
> needs some
> in-depth know how about autoconf as some serious patching is required.
> If someone is interested to help just let me know and I can point out
> the
> specific issue there.
>
>
> Best regards
>
>    -- Dago
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>

From phil at bolthole.com  Fri Jul 30 02:29:02 2010
From: phil at bolthole.com (Philip Brown)
Date: Thu, 29 Jul 2010 17:29:02 -0700
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <1280067662-sup-5757@pinkfloyd.chass.utoronto.ca>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<AANLkTikA3M3URHS__I9yRBJL4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
	<1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>
	<AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>
	<1280067662-sup-5757@pinkfloyd.chass.utoronto.ca>
Message-ID: <AANLkTi=Jix6QswkbH=XqY0a0eV7Cj2q1jT6iY3rwp+__@mail.gmail.com>

On 7/25/10, Ben Walton <bwalton at opencsw.org> wrote:
>
> I on the other hand have read the gettext docs, an action which I
> think is more germane to the issue than pestering the coreutils folks
> about their specific use of gettext.

I see that you didnt seem to want to "bother" them about why they are
doing what they do,
but you seem fine bothering them to ask an opinion about what I'm doing.
This seems inappropriate to me.


>...
>> Given, however, that this has not happened in the (6?) (7?) years i've
>> been doing this, I'm thinking this is quite unlikely :)
>
> It has happened now.  CSWcoreutils is using the gettext system in a
> valid manner and your actions in CSWcommon have caused a conflict. A
> symlink is a separate file.

No it is not a "file". it is a symlink. I chose my words very specifically.
While what you say is true in the context of OS implementation, we're
talking about packaging.
In the context of packaging, a file is not a symlink.
"s" vs "f", after all.



>> So until either that happens, or you wish to dig up more information
>> on why coreutils decided on using symlinks instead of separate files
>> AND that information indicates the current cswcommon behaviour is
>> bad... current behaviour will stay.  WIth the addition that
>> cswcommon should be modified to have ALL LC_TIME dirs symlinked,
>> rather than only partially.
>
> Why short change the system here?  What makes LC_TIME more special
> than LC_NUMERIC and the other various categories?

Go ask the coreutils people that first, why THEY decide to add a
symlink for it, and thus *they* think LC_TIME is "more special than
LC_NUMERIC and the other various categories".
You've already seen fit to bug them once already now.
You seem to think their opinion is more valid than mine here; so then,
ask them their opinion on why THEY think this also!


Meanwhile, I'm updating common to at least be consistent with the
symlinks, as I said i would.

From dam at opencsw.org  Fri Jul 30 15:33:00 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 30 Jul 2010 15:33:00 +0200
Subject: [csw-maintainers] bad interactions with CSWcommon
In-Reply-To: <AANLkTi=Jix6QswkbH=XqY0a0eV7Cj2q1jT6iY3rwp+__@mail.gmail.com>
References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca>
	<AANLkTikwOJs2ShSndDTLEbF-g3S5YEA1Bo-8Q4Qd70a6@mail.gmail.com>
	<1276994755-sup-5700@pinkfloyd.chass.utoronto.ca>
	<AANLkTil7PTJkh6P9L0NPPZRl7VHrc1O7aRcFQf9EEloU@mail.gmail.com>
	<1277040073-sup-8018@pinkfloyd.chass.utoronto.ca>
	<AANLkTilemzosIEgx8oVhupOQXNHUp6Lxhq3OomFOHYwm@mail.gmail.com>
	<1277042624-sup-3749@pinkfloyd.chass.utoronto.ca>
	<AANLkTimSTOs5t7Zy9Vft0CfaJiqcKLhhRmG4pbG2LTUe@mail.gmail.com>
	<1277047002-sup-479@pinkfloyd.chass.utoronto.ca>
	<1277163839-sup-3934@pinkfloyd.chass.utoronto.ca>
	<1278694982-sup-8536@pinkfloyd.chass.utoronto.ca>
	<AANLkTikYz_QiYzQaA9UXQpeoerJXZJgIOgugr7gLPiOL@mail.gmail.com>
	<1278720335-sup-4347@pinkfloyd.chass.utoronto.ca>
	<AANLkTinkoe3gQhA9q1_eVlEZj95tzqi_d71vGPfqxp00@mail.gmail.com>
	<1279039635-sup-5121@pinkfloyd.chass.utoronto.ca>
	<AANLkTiloNqXmg-0gJD7zkXIOJi1ekfGv9SBYV0ME8_6_@mail.gmail.com>
	<AANLkTikqJ7tQP9Chkzu_3iIG4ug2e787mYRLIoDipXuh@mail.gmail.com>
	<AANLkTikA3M3URHS__I9yRBJ L4fuWfAlF_mUvwEw_B6RE@mail.gmail.com>
	<1279763277-sup-1503@pinkfloyd.chass.utoronto.ca>
	<AANLkTikefa3pPsuiP-6HKB_85N-iq1wey-1Nq4nX5OgY@mail.gmail.com>
	<1280067662-sup-5757@pinkfloyd.chass.utoronto.ca>
	<AANLkTi=Jix6QswkbH=XqY0a0eV7Cj2q1jT6iY3rwp+__@mail.gmail.com>
Message-ID: <1C65B122-CECE-49F7-8C83-784091BBCB3C@opencsw.org>

Hi,

Am 30.07.2010 um 02:29 schrieb Philip Brown:

> On 7/25/10, Ben Walton <bwalton at opencsw.org> wrote:
>>
>> I on the other hand have read the gettext docs, an action which I
>> think is more germane to the issue than pestering the coreutils folks
>> about their specific use of gettext.
>
> I see that you didnt seem to want to "bother" them about why they are
> doing what they do,
> but you seem fine bothering them to ask an opinion about what I'm  
> doing.
> This seems inappropriate to me.

Bruno has a vast knowledge in this area (to be exact, he is the
upstream maintainer of GNU gettext). If he says "don't make symlinks"
than it is definitely the right thing to not make symlinks. At least
this sounds like a better argument than "we introduced it for reasons
long forgotten and never had a problem until now and therefore spread
what we have and ignore the problem that just arose as it can be worked
around".


Best regards

   -- Dago

From maciej at opencsw.org  Fri Jul 30 15:42:54 2010
From: maciej at opencsw.org (Maciej (Matchek) Blizinski)
Date: Fri, 30 Jul 2010 14:42:54 +0100
Subject: [csw-maintainers] Maciej on vacations until the 11th of August
Message-ID: <AANLkTinqZRGo4n9KS_R-a4J9uCsXWnfNNA1ZS8HLzePd@mail.gmail.com>

I'm going for vacations starting today, and I'll be back on-line on
the 11th of August.

Maciej

From bwalton at opencsw.org  Thu Jul 29 04:07:08 2010
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 28 Jul 2010 22:07:08 -0400
Subject: [csw-maintainers] packaging gems
In-Reply-To: <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca>
	<9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org>
Message-ID: <1280367168-sup-198@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Wed Jul 28 03:45:33 -0400 2010:
> BTW, there is
>    http://rubyforge.org/projects/gem2rpm/
> Maybe this can be used to rip out the dependencies and stuff to make
> an initial GAR Makefile?

How about the attached script?  It likely needs a bit of work yet, but
it hits the basics.

There is a wrinkle with gem packaging that I alluded to in
irc...dependency hell the likes the world hasn't seen in a long time.

Gems can declare dependencies on other gems, including locking down to
a specific version of that gem.  While it's easy to say "ok, we'll
just ensure we always update in steps that 'fit'" that won't work in
practice as you may find things like (encountered today):

redmine depends on the gem rack = 1.0.1 and complains loudly if you
have some other version.  It also depends on rails 2.3.5 and does the
same.

So...ok, no problem, we'll package multiple versions of gems.  How do
we do this sanely?  Would our rails gem be rails235?  Would our rails
gems simply deliver rails 2.3.5 and 2.3.8 (current) in a single
package?

The first is nasty and ambiguous.  The second may work, but makes it
hard to know when versions can be dropped from the package.

We could make the argument that we only package gems that will
play nicely with each other, but this could rule out various gems from
being packaged.  Think of the case where we've already pushed rails
(at 2.3.8) and now somebody wants to package redmine[1].

Thoughts?

Thanks
-Ben

[1] This can be worked around as redmine will ship release tarballs
    with the full rails stack in the vendor/ dir, but that's not the
    point here.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gem2pkg
Type: application/octet-stream
Size: 881 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20100728/5c8a3c80/attachment-0001.obj>