From pfelecan at opencsw.org  Tue Jul  3 15:06:43 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Tue, 3 Jul 2012 15:06:43 +0200 (CEST)
Subject: [csw-maintainers] please review tex_metauml recipe, license issue
Message-ID: <10c5bd90efb4910b10261b3691ad8892.squirrel@mail.opencsw.org>

I'm struggling with the definition of the license for this package and I'm
somewhat lost.

Can somebody have a look and enlighten me?

TIA

From bwalton at opencsw.org  Tue Jul  3 15:49:05 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 03 Jul 2012 09:49:05 -0400
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
	signed" when using GPG
Message-ID: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>


We could eliminate the passphrase expiry in the signing daemon
altogether.  That would mean the only time the passphrase is required
is at daemon startup.

Thoughts?

Thanks
-Ben


--- Begin forwarded message from John Clizbe ---
From: John Clizbe <jpclizbe at tx.rr.com>
To: Questions and discussions <users at lists.opencsw.org>
Date: Tue, 03 Jul 2012 09:34:21 -0400
Subject: [csw-users] pkgutil says "Catalog is not signed" when using GPG

The error is back. Encountered it last week and thought it might resolve
itself. Still getting it today.

-bash-3.00# pkgutil -uU
=> Fetching new catalog and descriptions
(http://mirror.opencsw.org/opencsw/unstable/sparc/5.10) if available ...
Catalog
/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_sparc_5.10 is
not signed! Check your mirror settings or disable use_gpg in pkgutil.conf.
--- End forwarded message ---
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From dam at opencsw.org  Tue Jul  3 16:16:42 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 3 Jul 2012 16:16:42 +0200
Subject: [csw-maintainers] please review tex_metauml recipe,
	license issue
In-Reply-To: <10c5bd90efb4910b10261b3691ad8892.squirrel@mail.opencsw.org>
References: <10c5bd90efb4910b10261b3691ad8892.squirrel@mail.opencsw.org>
Message-ID: <2AA98F6E-8EA6-4B9C-9873-7F03305C55E8@opencsw.org>

Hi Peter,

Am 03.07.2012 um 15:06 schrieb pfelecan at opencsw.org:
> I'm struggling with the definition of the license for this package and I'm
> somewhat lost.
> 
> Can somebody have a look and enlighten me?

The problem was the adjustment of WORKSRC which is also used in deriving the license.
I adjust this here:
  http://sourceforge.net/apps/trac/gar/changeset/18625

Additionally, I clarified it in the GAR variable reference:
  https://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference?action=diff&version=75


Best regards

  -- Dago	

From dam at opencsw.org  Tue Jul  3 17:09:21 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 3 Jul 2012 17:09:21 +0200
Subject: [csw-maintainers] Trac at SourceForge
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
Message-ID: <55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>

Hi folks,

I just got the attached email stating that the hosted apps will be shut down
on September 1, 2012. For OpenCSW this means essentially Trac. I am not sure yet
on how to best proceed. We could relatively easy migrate to a self-hosted Trac,
but probably we should take a step back and rethink what the project needs on a
broader basis now that effort is needed anyway. For now I would like to collect
thoughts on the topic :-)


Best regards

  -- Dago

Anfang der weitergeleiteten E-Mail:

> Von: "SourceForge.net Team" <noreply at sourceforge.net>
> Datum: 3. Juli 2012 16:20:30 MESZ
> An: dagobert at familie-michelsen.de
> Betreff: Hosted Apps Retirement
> 
> In case you missed it ...
> 
> We wanted to be sure you were aware of some upcoming changes to the
> SourceForge project hosting service.
> 
> One or more of your projects use the Hosted Apps service. On September 1,
> 2012, the Hosted Apps service will reach the end of its life and be shut
> down. The reasons for this are discussed in the blog post, at
> http://sourceforge.net/blog/hosted-apps-retirement/  and in the wiki, at
> https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/ 
> 
> 
> Over the coming days, we'll be publishing more documents about how to
> migrate your apps to your own project web space, so that none of your data
> is lost in this transition. We want to be sure that your project can
> continue to operate without interruption, so if you have any concerns,
> difficulty with migration, or just want to chat, please send us a note
> (communityteam at sourceforge.net).
> 
> Please watch the wiki page
> (https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/)
> for further updates about this process. We'll be back in touch as it gets
> closer to the deadline, or if anything about the plan changes.
> 
> Thanks again for being part of the SourceForge community.
> 
> ----------------------------------------------------------------------
> SourceForge.net has made this mailing to you as a registered user of
> the SourceForge.net site to convey important information regarding
> your SourceForge.net account or your use of SourceForge.net services.
> 
> We make a small number of directed mailings to registered users each
> year regarding their account or data, to help preserve the security of
> their account or prevent loss of data or service access.
> 
> If you have concerns about this mailing please contact our Support
> team per: http://sourceforge.net/support


From bwalton at opencsw.org  Tue Jul  3 17:14:28 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 03 Jul 2012 11:14:28 -0400
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
Message-ID: <1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Tue Jul 03 11:09:21 -0400 2012:

> that effort is needed anyway. For now I would like to collect
> thoughts on the topic :-)

As effort is now required, what about switching to Github?

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


From wilbury at opencsw.org  Tue Jul  3 17:25:01 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Tue, 03 Jul 2012 17:25:01 +0200
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
	<1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
Message-ID: <4FF30ECD.7020202@opencsw.org>

On 07/03/2012 05:14 PM, Ben Walton wrote:
> Excerpts from Dagobert Michelsen's message of Tue Jul 03 11:09:21 -0400 2012:
> 
>> that effort is needed anyway. For now I would like to collect
>> thoughts on the topic :-)
> 
> As effort is now required, what about switching to Github?

Does it provide Trace-like interface? If not, I can provide computing
power to host Trac.

otis

-- 
Juraj Lutter <wilbury at opencsw.org>

From bwalton at opencsw.org  Tue Jul  3 17:28:28 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 03 Jul 2012 11:28:28 -0400
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <4FF30ECD.7020202@opencsw.org>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
	<1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
	<4FF30ECD.7020202@opencsw.org>
Message-ID: <1341329277-sup-2771@pinkfloyd.chass.utoronto.ca>

Excerpts from Juraj Lutter's message of Tue Jul 03 11:25:01 -0400 2012:

> Does it provide Trace-like interface? If not, I can provide
> computing power to host Trac.

It should be feature equivalent, I think.

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


From dam at opencsw.org  Tue Jul  3 17:31:36 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 3 Jul 2012 17:31:36 +0200
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
	<1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
Message-ID: <7CB6D836-4F9E-4642-9035-6617FFCC3CA1@opencsw.org>

Hi Ben,

Am 03.07.2012 um 17:14 schrieb Ben Walton:
> Excerpts from Dagobert Michelsen's message of Tue Jul 03 11:09:21 -0400 2012:
>> that effort is needed anyway. For now I would like to collect
>> thoughts on the topic :-)
> 
> As effort is now required, what about switching to Github?

The question you are asking is "should be switch from SVN to Git?"
We had some discussions about this topic earlier about switching,
the main issue is IMHO the layout of the repo. I opened a wiki
page to track discussion progress:
  http://wiki.opencsw.org/project-migration


Best regards

  -- Dago

From bwalton at opencsw.org  Tue Jul  3 17:36:54 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 03 Jul 2012 11:36:54 -0400
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <7CB6D836-4F9E-4642-9035-6617FFCC3CA1@opencsw.org>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
	<1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
	<7CB6D836-4F9E-4642-9035-6617FFCC3CA1@opencsw.org>
Message-ID: <1341329665-sup-7113@pinkfloyd.chass.utoronto.ca>

Excerpts from Dagobert Michelsen's message of Tue Jul 03 11:31:36 -0400 2012:

Hi Dago,

> The question you are asking is "should be switch from SVN to Git?"
> We had some discussions about this topic earlier about switching,
> the main issue is IMHO the layout of the repo. I opened a wiki page
> to track discussion progress:
> http://wiki.opencsw.org/project-migration

Yes, I'm proposing a more broad-scoped change, but only since it's
opportunistic.  The wiki page will be a good help.  I'll look at
filling in some thoughts later this evening.

A lot of changes would be required for such a migration...

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


From pfelecan at opencsw.org  Tue Jul  3 19:16:20 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 03 Jul 2012 19:16:20 +0200
Subject: [csw-maintainers] please review tex_metauml recipe,
	license issue
In-Reply-To: <2AA98F6E-8EA6-4B9C-9873-7F03305C55E8@opencsw.org> (Dagobert
	Michelsen's message of "Tue, 3 Jul 2012 16:16:42 +0200")
References: <10c5bd90efb4910b10261b3691ad8892.squirrel@mail.opencsw.org>
	<2AA98F6E-8EA6-4B9C-9873-7F03305C55E8@opencsw.org>
Message-ID: <x6mx3gbw9n.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 03.07.2012 um 15:06 schrieb pfelecan at opencsw.org:
>> I'm struggling with the definition of the license for this package and I'm
>> somewhat lost.
>> 
>> Can somebody have a look and enlighten me?
>
> The problem was the adjustment of WORKSRC which is also used in deriving the license.
> I adjust this here:
>   http://sourceforge.net/apps/trac/gar/changeset/18625

Thank you for the modification

> Additionally, I clarified it in the GAR variable reference:
>   https://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference?action=diff&version=75

Thank you for the documentation
-- 
Peter

From bonivart at opencsw.org  Tue Jul  3 21:14:47 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 3 Jul 2012 21:14:47 +0200
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
 signed" when using GPG
In-Reply-To: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
Message-ID: <CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>

On Tue, Jul 3, 2012 at 3:49 PM, Ben Walton <bwalton at opencsw.org> wrote:
> We could eliminate the passphrase expiry in the signing daemon
> altogether.  That would mean the only time the passphrase is required
> is at daemon startup.
>
> Thoughts?

Or at least send mail to multiple recipients (including list) when
time is running out.

From bwalton at opencsw.org  Wed Jul  4 03:12:15 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 03 Jul 2012 21:12:15 -0400
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
	signed" when using GPG
In-Reply-To: <CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
	<CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
Message-ID: <1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Tue Jul 03 15:14:47 -0400 2012:

> Or at least send mail to multiple recipients (including list) when
> time is running out.

I'd need to check, but I don't think we have access to much more than
a binary ack/nack status from the gpg agent.  The mail does go to
multiple people currently but only two are able to act.  Sending the
notices to the list would only be spam, I think.  If people want to
see these messages though, please let me know.

Thanks
-Ben

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


From bonivart at opencsw.org  Wed Jul  4 10:57:27 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 4 Jul 2012 10:57:27 +0200
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
 signed" when using GPG
In-Reply-To: <1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
	<CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
	<1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>
Message-ID: <CABY0g1WyXZoiFoNQA-F4+ex=E5aJyx+Fuqiou-ZuFvvrGVtsag@mail.gmail.com>

On Wed, Jul 4, 2012 at 3:12 AM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Peter Bonivart's message of Tue Jul 03 15:14:47 -0400 2012:
>
>> Or at least send mail to multiple recipients (including list) when
>> time is running out.
>
> I'd need to check, but I don't think we have access to much more than
> a binary ack/nack status from the gpg agent.  The mail does go to
> multiple people currently but only two are able to act.  Sending the
> notices to the list would only be spam, I think.  If people want to
> see these messages though, please let me know.

It's always bad when users are the first to know of a problem.

From maciej at opencsw.org  Wed Jul  4 11:06:07 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 4 Jul 2012 10:06:07 +0100
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
 signed" when using GPG
In-Reply-To: <CABY0g1WyXZoiFoNQA-F4+ex=E5aJyx+Fuqiou-ZuFvvrGVtsag@mail.gmail.com>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
	<CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
	<1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>
	<CABY0g1WyXZoiFoNQA-F4+ex=E5aJyx+Fuqiou-ZuFvvrGVtsag@mail.gmail.com>
Message-ID: <CALtRa-4dAbCW0ndr3a1O_7dkyfX7FpTB7rfQK1RJ6Z92Gbrb-Q@mail.gmail.com>

2012/7/4 Peter Bonivart <bonivart at opencsw.org>:
> It's always bad when users are the first to know of a problem.

One thing we could do is stop the push if catalogs aren't signed.

From bonivart at opencsw.org  Wed Jul  4 11:27:33 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Wed, 4 Jul 2012 11:27:33 +0200
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
 signed" when using GPG
In-Reply-To: <CALtRa-4dAbCW0ndr3a1O_7dkyfX7FpTB7rfQK1RJ6Z92Gbrb-Q@mail.gmail.com>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
	<CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
	<1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>
	<CABY0g1WyXZoiFoNQA-F4+ex=E5aJyx+Fuqiou-ZuFvvrGVtsag@mail.gmail.com>
	<CALtRa-4dAbCW0ndr3a1O_7dkyfX7FpTB7rfQK1RJ6Z92Gbrb-Q@mail.gmail.com>
Message-ID: <CABY0g1Vb1OtTwmR1ztDbP_M5R-Acp-4vxv7+hYaWyzT97MMcEA@mail.gmail.com>

On Wed, Jul 4, 2012 at 11:06 AM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2012/7/4 Peter Bonivart <bonivart at opencsw.org>:
>> It's always bad when users are the first to know of a problem.
>
> One thing we could do is stop the push if catalogs aren't signed.

Yes, that's better than pushing a "bad" catalog. If we now e-mailed
the list or any other people than the two being able to sign the
catalog we would still not get anything done most likely since they
already received an e-mail and for unknown reason didn't sign it in
time. Now more people would know but still not being able to help,
that's not good.

Maybe Ben's suggestion about only entering the password on daemon
startup is better. Assuming the daemon is stable we would avoid this
even though it hasn't happened frequently.

/peter

From dam at opencsw.org  Wed Jul  4 12:18:55 2012
From: dam at opencsw.org (dam at opencsw.org)
Date: Wed, 4 Jul 2012 12:18:55 +0200 (CEST)
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <4FF30ECD.7020202@opencsw.org>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
	<1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
	<4FF30ECD.7020202@opencsw.org>
Message-ID: <3fcbba780062fe113558f3bff85ca9ef.squirrel@mail.opencsw.org>

Hi Juraj,

> On 07/03/2012 05:14 PM, Ben Walton wrote:
>> Excerpts from Dagobert Michelsen's message of Tue Jul 03 11:09:21 -0400
>> 2012:
>>
>>> that effort is needed anyway. For now I would like to collect
>>> thoughts on the topic :-)
>>
>> As effort is now required, what about switching to Github?
>
> Does it provide Trace-like interface? If not, I can provide computing
> power to host Trac.

If you have a fast x86 machine with some disk space and good internet
connectivity it may be worthwhile to move /community (or the whole
webservice?) there as the speed is currently not satisfactory.


Best regards

  -- Dago


From bwalton at opencsw.org  Wed Jul  4 13:22:53 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 Jul 2012 07:22:53 -0400
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
	signed" when using GPG
In-Reply-To: <CALtRa-4dAbCW0ndr3a1O_7dkyfX7FpTB7rfQK1RJ6Z92Gbrb-Q@mail.gmail.com>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
	<CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
	<1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>
	<CABY0g1WyXZoiFoNQA-F4+ex=E5aJyx+Fuqiou-ZuFvvrGVtsag@mail.gmail.com>
	<CALtRa-4dAbCW0ndr3a1O_7dkyfX7FpTB7rfQK1RJ6Z92Gbrb-Q@mail.gmail.com>
Message-ID: <228a8f97-6dea-44b9-8617-33ebd18520b6@email.android.com>

I think this would be a good thing to do.

Thanks
-Ben

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> wrote:

2012/7/4 Peter Bonivart <bonivart at opencsw.org>:
> It's always bad when users are the first to know of a problem.

One thing we could do is stop the push if catalogs aren't signed.
_____________________________________________

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

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

From wilbury at opencsw.org  Wed Jul  4 13:25:32 2012
From: wilbury at opencsw.org (Juraj Lutter)
Date: Wed, 04 Jul 2012 13:25:32 +0200
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <3fcbba780062fe113558f3bff85ca9ef.squirrel@mail.opencsw.org>
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
	<1341328432-sup-4369@pinkfloyd.chass.utoronto.ca>
	<4FF30ECD.7020202@opencsw.org>
	<3fcbba780062fe113558f3bff85ca9ef.squirrel@mail.opencsw.org>
Message-ID: <4FF4282C.4050600@opencsw.org>

On 07/04/2012 12:18 PM, dam at opencsw.org wrote:
> Hi Juraj,
> 
>> On 07/03/2012 05:14 PM, Ben Walton wrote:
>>> Excerpts from Dagobert Michelsen's message of Tue Jul 03 11:09:21 -0400
>>> 2012:
>>>
>>>> that effort is needed anyway. For now I would like to collect
>>>> thoughts on the topic :-)
>>>
>>> As effort is now required, what about switching to Github?
>>
>> Does it provide Trace-like interface? If not, I can provide computing
>> power to host Trac.
> 
> If you have a fast x86 machine with some disk space and good internet
> connectivity it may be worthwhile to move /community (or the whole
> webservice?) there as the speed is currently not satisfactory.

Oh yes, we can move /community, I can arrange a zone for this and do the
actual move.



-- 
Juraj Lutter <wilbury at opencsw.org>

From pfelecan at opencsw.org  Wed Jul  4 14:55:04 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Wed, 4 Jul 2012 14:55:04 +0200 (CEST)
Subject: [csw-maintainers] netpbm: development package issues
Message-ID: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>

I'm directing this here because libnetpbm10 and libnetpbm_dev are not
available in Mantis...

The development package doesn't contain the /opt/csw/lib/libnetpbm.so
component which blocks linking in a standard way when building a dependent
binary.

Please, can we have the 2 packages added to Mantis and include the above
mentioned component to the corresponding development package.

BTW, a full verification of Mantis must be a good thing to do periodically.

TIA

From dam at opencsw.org  Wed Jul  4 15:05:36 2012
From: dam at opencsw.org (dam at opencsw.org)
Date: Wed, 4 Jul 2012 15:05:36 +0200 (CEST)
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>
References: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>
Message-ID: <fb99c994d4d6147a906ae78cc09d00f0.squirrel@mail.opencsw.org>

Hi Peter,

> I'm directing this here because libnetpbm10 and libnetpbm_dev are not
> available in Mantis...
>
> The development package doesn't contain the /opt/csw/lib/libnetpbm.so
> component which blocks linking in a standard way when building a dependent
> binary.

The problem is that the upstream installation is missing the .so
completely. I'll have a look.


Best regards

  -- Dago

From bwalton at opencsw.org  Wed Jul  4 16:32:50 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 Jul 2012 10:32:50 -0400
Subject: [csw-maintainers] Fwd: [csw-users] pkgutil says "Catalog is not
	signed" when using GPG
In-Reply-To: <CABY0g1Vb1OtTwmR1ztDbP_M5R-Acp-4vxv7+hYaWyzT97MMcEA@mail.gmail.com>
References: <1341323263-sup-2223@pinkfloyd.chass.utoronto.ca>
	<CABY0g1U9ScU4-4fhyjvqDynDJe4jzahL+u3P1dDsoPVB+ws9-Q@mail.gmail.com>
	<1341364203-sup-5953@pinkfloyd.chass.utoronto.ca>
	<CABY0g1WyXZoiFoNQA-F4+ex=E5aJyx+Fuqiou-ZuFvvrGVtsag@mail.gmail.com>
	<CALtRa-4dAbCW0ndr3a1O_7dkyfX7FpTB7rfQK1RJ6Z92Gbrb-Q@mail.gmail.com>
	<CABY0g1Vb1OtTwmR1ztDbP_M5R-Acp-4vxv7+hYaWyzT97MMcEA@mail.gmail.com>
Message-ID: <1341412276-sup-3935@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Wed Jul 04 05:27:33 -0400 2012:

> Maybe Ben's suggestion about only entering the password on daemon
> startup is better. Assuming the daemon is stable we would avoid this
> even though it hasn't happened frequently.

The daemon does seem stable, I think, so having no expiry on the
passphrase is likely a good option.  We should also abort the push on
signature failure though.  Both of those things together should
provide a much smoother experience.  In the event of signature
failure, mail to the list might be warranted as that's a true anomaly
instead of a periodic event.

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


From pfelecan at opencsw.org  Wed Jul  4 19:59:30 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 04 Jul 2012 19:59:30 +0200
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <fb99c994d4d6147a906ae78cc09d00f0.squirrel@mail.opencsw.org>
	(dam@opencsw.org's message of "Wed, 4 Jul 2012 15:05:36 +0200 (CEST)")
References: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>
	<fb99c994d4d6147a906ae78cc09d00f0.squirrel@mail.opencsw.org>
Message-ID: <x67gujbe65.fsf@opencsw.org>

dam at opencsw.org writes:

> Hi Peter,
>
>> I'm directing this here because libnetpbm10 and libnetpbm_dev are not
>> available in Mantis...

And this can be addressed?

>> The development package doesn't contain the /opt/csw/lib/libnetpbm.so
>> component which blocks linking in a standard way when building a dependent
>> binary.
>
> The problem is that the upstream installation is missing the .so
> completely. I'll have a look.

Well, it's just a symbolic link to create in post-install-modulated and
filtered in the development package content, isn't it?
-- 
Peter

From pfelecan at opencsw.org  Wed Jul  4 20:05:05 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 04 Jul 2012 20:05:05 +0200
Subject: [csw-maintainers] request of takeover for pmfilemagic
Message-ID: <x63957bdwu.fsf@opencsw.org>

Is there a Perl specialist for taking over CSWpmfilemmagic? I need this
for updating namazu but I'm short in resources for a Perl package...
-- 
Peter

From dam at opencsw.org  Wed Jul  4 20:07:01 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 4 Jul 2012 20:07:01 +0200
Subject: [csw-maintainers] request of takeover for pmfilemagic
In-Reply-To: <x63957bdwu.fsf@opencsw.org>
References: <x63957bdwu.fsf@opencsw.org>
Message-ID: <DC7DA795-5AB1-4031-9FCD-74A696EF6644@opencsw.org>

Hi Peter,

Am 04.07.2012 um 20:05 schrieb Peter FELECAN:
> Is there a Perl specialist for taking over CSWpmfilemmagic? I need this
> for updating namazu but I'm short in resources for a Perl package...

Sure, I'll take care of this.


Best regards

  -- Dago



From pfelecan at opencsw.org  Wed Jul  4 20:12:16 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 04 Jul 2012 20:12:16 +0200
Subject: [csw-maintainers] Trac at SourceForge
In-Reply-To: <55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org> (Dagobert
	Michelsen's message of "Tue, 3 Jul 2012 17:09:21 +0200")
References: <E1Sm3xu-00012Y-Vv@sog-mx-2.v43.ch3.sourceforge.com>
	<55CE4077-A54F-4CD8-87FA-61A1D30F61ED@opencsw.org>
Message-ID: <x6y5mz9z0f.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> I just got the attached email stating that the hosted apps will be shut down
> on September 1, 2012. For OpenCSW this means essentially Trac. I am not sure yet
> on how to best proceed. We could relatively easy migrate to a self-hosted Trac,
> but probably we should take a step back and rethink what the project needs on a
> broader basis now that effort is needed anyway. For now I would like to collect
> thoughts on the topic :-)

If I'm understanding correctly the situation, SF is decommissioning their
applications, among which Trac. However the user can migrate Trac in
their "web space": what's that?

Still, they will continue to provide
subversion hosting. As you said, is quite easy to migrate the Trac for
our repository, on their infrastructure or on ours. This need to be done
before September.

Lets do that and brainstorm about a bigger change, such as migrating to
git, splitting the repository in smaller chunks, &c.

Consequently, for the moment we should just:

- consider the target of the migration, SF or external;
- call for volunteers for doing the migration before August 31.

My 2 obolo?
-- 
Peter

From dam at opencsw.org  Wed Jul  4 20:20:12 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 4 Jul 2012 20:20:12 +0200
Subject: [csw-maintainers] request of takeover for pmfilemagic
In-Reply-To: <DC7DA795-5AB1-4031-9FCD-74A696EF6644@opencsw.org>
References: <x63957bdwu.fsf@opencsw.org>
	<DC7DA795-5AB1-4031-9FCD-74A696EF6644@opencsw.org>
Message-ID: <512238E4-5C9E-45E7-8AAC-D4CCE8A13C16@opencsw.org>

Hi Peter,

Am 04.07.2012 um 20:07 schrieb Dagobert Michelsen:
> Am 04.07.2012 um 20:05 schrieb Peter FELECAN:
>> Is there a Perl specialist for taking over CSWpmfilemmagic? I need this
>> for updating namazu but I'm short in resources for a Perl package...
> 
> Sure, I'll take care of this.

I just pushed it. It currently does not depend on libmagic_data
which may or may not be a good idea. Should I add the dep?


Best regards

  -- Dago

From maciej at opencsw.org  Wed Jul  4 21:42:14 2012
From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=)
Date: Wed, 4 Jul 2012 20:42:14 +0100
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <x67gujbe65.fsf@opencsw.org>
References: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>
	<fb99c994d4d6147a906ae78cc09d00f0.squirrel@mail.opencsw.org>
	<x67gujbe65.fsf@opencsw.org>
Message-ID: <20120704194214.GA4416@quince.home.blizinski.pl>

On Wed, Jul 04, 2012 at 07:59:30PM +0200, Peter FELECAN wrote:
> dam at opencsw.org writes:
> 
> > Hi Peter,
> >
> >> I'm directing this here because libnetpbm10 and libnetpbm_dev are not
> >> available in Mantis...
> 
> And this can be addressed?

I'm wondering why it's even the case. The integration from catalogs to
mantis is automated, so everything that's in the catalog should also be
in mantis. Or there should be some error messages in the logs. I guess
Ben will have a better idea.

From bwalton at opencsw.org  Thu Jul  5 03:46:18 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 04 Jul 2012 21:46:18 -0400
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <20120704194214.GA4416@quince.home.blizinski.pl>
References: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>
	<fb99c994d4d6147a906ae78cc09d00f0.squirrel@mail.opencsw.org>
	<x67gujbe65.fsf@opencsw.org>
	<20120704194214.GA4416@quince.home.blizinski.pl>
Message-ID: <1341452643-sup-887@pinkfloyd.chass.utoronto.ca>

Excerpts from Maciej Blizi?ski's message of Wed Jul 04 15:42:14 -0400 2012:

> > >> I'm directing this here because libnetpbm10 and libnetpbm_dev are not
> > >> available in Mantis...
> > 
> > And this can be addressed?
> 
> I'm wondering why it's even the case. The integration from catalogs
> to mantis is automated, so everything that's in the catalog should
> also be in mantis. Or there should be some error messages in the
> logs. I guess Ben will have a better idea.

The mantis handling is different than the web database.  The web
database is a clean rebuild from a current catalog.  This eliminated
all of the cruft that had accumulated.  The mantis database is more
involved though, so I've never done a clean rebuild.

I should do a cross reference between a current catalog and the
packages in the database and correct errors though.  While I'm at it,
is it worth completely removing packages that no longer exist?  Right
now, when a package is renamed or removed, I simply mark the package
as hidden.

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


From dam at opencsw.org  Thu Jul  5 09:20:30 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 5 Jul 2012 09:20:30 +0200
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <x67gujbe65.fsf@opencsw.org>
References: <9a7fa9e859d68c6438c41f51da718d79.squirrel@mail.opencsw.org>
	<fb99c994d4d6147a906ae78cc09d00f0.squirrel@mail.opencsw.org>
	<x67gujbe65.fsf@opencsw.org>
Message-ID: <5E1EC418-4E28-4D09-B0DB-726DA9327960@opencsw.org>

Hi Peter,

Am 04.07.2012 um 19:59 schrieb Peter FELECAN:
> dam at opencsw.org writes:
>>> I'm directing this here because libnetpbm10 and libnetpbm_dev are not
>>> available in Mantis...
> 
> And this can be addressed?
> 
>>> The development package doesn't contain the /opt/csw/lib/libnetpbm.so
>>> component which blocks linking in a standard way when building a dependent
>>> binary.
>> 
>> The problem is that the upstream installation is missing the .so
>> completely. I'll have a look.
> 
> Well, it's just a symbolic link to create in post-install-modulated and
> filtered in the development package content, isn't it?

It is :-) Done.


Best regards

  -- Dago

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


From romeotheriault at opencsw.org  Thu Jul  5 10:37:09 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Wed, 04 Jul 2012 22:37:09 -1000
Subject: [csw-maintainers] zeromq build failing on i386: Too many open
 files (signaler.cpp:300)
In-Reply-To: <6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org>
References: <7400c3c55913.4fe16734@contac-dt.de>
	<740085ac3aa9.4fe18368@contac-dt.de>
	<2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org>
	<CAHo7ehVF1B4QuWKtLV3BgVLTPVwNic_E2VdESc0zXf=k-UTqYg@mail.gmail.com>
	<CAHo7ehVR3eRugENKO2pyJEyk_Cc8c5deexidA-2zZWm19Bq_2g@mail.gmail.com>
	<6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org>
Message-ID: <CAHo7ehW7v3V1Ws2sHQ8FVxWF4yV63v=M93rWSU3oF=8hjqb7Dw@mail.gmail.com>

Hi Dago,

On Wed, Jun 20, 2012 at 8:12 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Does this mean the build depends on your home directory? That would be bad.
> I suggest using
>   file/bash_profile
>   DISTFILES += bash_profile
>   BASH_ENV=$(WORKSRC)/bash_profile
> to make the recipe portable.

I'm just getting back to this after a vacation. I found that I needed
to use the $(WORKDIR) variable to get the correct directory containing
the file I need to source. So I'm doing this in my Makefile:

DISTFILES  += set-ulimit-for-build-test
EXTRA_TEST_ENV += BASH_ENV=$(WORKDIR)/set-ulimit-for-build-test

So the BASH_ENV is now being expanded like so, during the testing phase:

BASH_ENV=work/solaris9-i386/build-isa-i386/set-ulimit-for-build-test

The problem is that bash cannot find the 'set-ulimit-for-build-test'
file since it doesn't know where the "work" directory is. If I set
this instead:

EXTRA_TEST_ENV +=
BASH_ENV=~/opencsw/zeromq/trunk/$(WORKDIR)/set-ulimit-for-build-test

it works as expected but I'm having to hard-code the
"~/opencsw/zeromq/trunk/" part of the path.

Do you have any suggestions on how I might be able to get this to work
without hard-coding "~/opencsw/zeromq/trunk/" ?

Thank you,
Romeo

From dam at opencsw.org  Thu Jul  5 11:31:04 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 5 Jul 2012 11:31:04 +0200
Subject: [csw-maintainers] zeromq build failing on i386: Too many open
	files (signaler.cpp:300)
In-Reply-To: <CAHo7ehW7v3V1Ws2sHQ8FVxWF4yV63v=M93rWSU3oF=8hjqb7Dw@mail.gmail.com>
References: <7400c3c55913.4fe16734@contac-dt.de>
	<740085ac3aa9.4fe18368@contac-dt.de>
	<2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org>
	<CAHo7ehVF1B4QuWKtLV3BgVLTPVwNic_E2VdESc0zXf=k-UTqYg@mail.gmail.com>
	<CAHo7ehVR3eRugENKO2pyJEyk_Cc8c5deexidA-2zZWm19Bq_2g@mail.gmail.com>
	<6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org>
	<CAHo7ehW7v3V1Ws2sHQ8FVxWF4yV63v=M93rWSU3oF=8hjqb7Dw@mail.gmail.com>
Message-ID: <1B36A53F-B4CC-47DB-B8ED-5860E19EF404@opencsw.org>

Hi Romeo,

Am 05.07.2012 um 10:37 schrieb Romeo Theriault:
> On Wed, Jun 20, 2012 at 8:12 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> Does this mean the build depends on your home directory? That would be bad.
>> I suggest using
>>  file/bash_profile
>>  DISTFILES += bash_profile
>>  BASH_ENV=$(WORKSRC)/bash_profile
>> to make the recipe portable.
> 
> I'm just getting back to this after a vacation. I found that I needed
> to use the $(WORKDIR) variable to get the correct directory containing
> the file I need to source. So I'm doing this in my Makefile:
> 
> DISTFILES  += set-ulimit-for-build-test
> EXTRA_TEST_ENV += BASH_ENV=$(WORKDIR)/set-ulimit-for-build-test
> 
> So the BASH_ENV is now being expanded like so, during the testing phase:
> 
> BASH_ENV=work/solaris9-i386/build-isa-i386/set-ulimit-for-build-test
> 
> The problem is that bash cannot find the 'set-ulimit-for-build-test'
> file since it doesn't know where the "work" directory is. If I set
> this instead:
> 
> EXTRA_TEST_ENV +=
> BASH_ENV=~/opencsw/zeromq/trunk/$(WORKDIR)/set-ulimit-for-build-test
> 
> it works as expected but I'm having to hard-code the
> "~/opencsw/zeromq/trunk/" part of the path.
> 
> Do you have any suggestions on how I might be able to get this to work
> without hard-coding "~/opencsw/zeromq/trunk/" ?

Try
  EXTRA_TEST_ENV += BASH_ENV=$(abspath $(WORKDIR)/set-ulimit-for-build-test)


Best regards

  -- Dago



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


From dam at opencsw.org  Thu Jul  5 18:21:11 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 05 Jul 2012 16:21:11 -0000
Subject: [csw-maintainers] Package browser enhancement (was Re: Bug in
	HTML	on our website)
In-Reply-To: <4D054DAD.9010606@wbonnet.net>
References: <AANLkTimHhtLBDvpstMs+K7Am7tbVH2fHt6Rm_MeCd72o@mail.gmail.com>	<4D010193.7060105@wbonnet.net>
	<20101209164001.GJ30288@sebastiankayser.de>
	<4D054DAD.9010606@wbonnet.net>
Message-ID: <B4AE8454-CBAA-47E9-A2E4-060078C1108F@opencsw.org>

An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120705/f6eafef4/attachment.html>

From ghenry at opencsw.org  Thu Jul  5 18:37:22 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Thu, 05 Jul 2012 18:37:22 +0200
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling perl
	module
Message-ID: <4FF5C2C2.2090007@opencsw.org>

hello all,

this is my first tentative to compile a perl module.
The result of "mgar package" is:
gmake: *** [pkgcheck] Error 2


i looked all the messages, and i don't understand where is the error. 
The only things i noticed are the warning:
...
mkp: Processing prototype
mkp: WARNING: Using existing CSWpmclassfactutil.prototype-i386
mkp: Processing depend
mkp: WARNING: Using existing CSWpmclassfactutil.depend
mkp: Processing pkginfo
mkp: WARNING: Using existing CSWpmclassfactutil.pkginfo
...
## Processing pkginfo file.
WARNING: missing directory entry for </opt>
WARNING: missing directory entry for </opt/csw>
WARNING: missing directory entry for </opt/csw/share>
WARNING: missing directory entry for </opt/csw/share/doc>
WARNING: missing directory entry for </opt/csw/share/man>
## Attempting to volumize 15 entries in pkgmap.
...

and what is the meaning of:
* Unused Override: CSWpmclassfactutil: surplus-dependency
* Unused Override: CSWpmclassfactutil: 
pkginfo-description-not-starting-with-uppercase


i found the pkg here:
http://buildfarm.opencsw.org/pkgdb/srv4/3a2d15a832a24cbc755ad2fb71203862/

the file name is:
pm_classfactutil-1.7,REV=2012.07.05-SunOS5.9-all-UNCOMMITTED.pkg.gz

why do i have "UNCOMMITTED" in the name?

thanks in advance for help,

gerard

From bwalton at opencsw.org  Thu Jul  5 18:47:07 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 05 Jul 2012 12:47:07 -0400
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling
	perl module
In-Reply-To: <4FF5C2C2.2090007@opencsw.org>
References: <4FF5C2C2.2090007@opencsw.org>
Message-ID: <1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>

Excerpts from Gerard Henry's message of Thu Jul 05 12:37:22 -0400 2012:

Hi Gerard,

> and what is the meaning of:
> * Unused Override: CSWpmclassfactutil: surplus-dependency
> * Unused Override: CSWpmclassfactutil: 
> pkginfo-description-not-starting-with-uppercase

This is telling you that you've overridden checkpkg in two cases that
aren't necessary.  That likely means that the previous issues were
fixed in the recipe.

> the file name is:
> pm_classfactutil-1.7,REV=2012.07.05-SunOS5.9-all-UNCOMMITTED.pkg.gz
> 
> why do i have "UNCOMMITTED" in the name?

This is because you have uncommitted work in your recipe.  If you
commit it so that it's public in the sf.net repository, and then do:

mgar remerge repacakge

You should get a file with -CSW instead of -UNCOMMITTED.

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


From romeotheriault at opencsw.org  Fri Jul  6 02:02:07 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Thu, 05 Jul 2012 14:02:07 -1000
Subject: [csw-maintainers] zeromq build failing on i386: Too many open
 files (signaler.cpp:300)
In-Reply-To: <1B36A53F-B4CC-47DB-B8ED-5860E19EF404@opencsw.org>
References: <7400c3c55913.4fe16734@contac-dt.de>
	<740085ac3aa9.4fe18368@contac-dt.de>
	<2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org>
	<CAHo7ehVF1B4QuWKtLV3BgVLTPVwNic_E2VdESc0zXf=k-UTqYg@mail.gmail.com>
	<CAHo7ehVR3eRugENKO2pyJEyk_Cc8c5deexidA-2zZWm19Bq_2g@mail.gmail.com>
	<6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org>
	<CAHo7ehW7v3V1Ws2sHQ8FVxWF4yV63v=M93rWSU3oF=8hjqb7Dw@mail.gmail.com>
	<1B36A53F-B4CC-47DB-B8ED-5860E19EF404@opencsw.org>
Message-ID: <CAHo7ehUix5PxHzJwsJKXKLGZvDZCjYJ6zY2iojjHvDMdGj_CyA@mail.gmail.com>

On Wed, Jul 4, 2012 at 11:31 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Try
>   EXTRA_TEST_ENV += BASH_ENV=$(abspath $(WORKDIR)/set-ulimit-for-build-test)

Works perfectly, thank you.

Romeo

From romeotheriault at opencsw.org  Fri Jul  6 05:52:27 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Thu, 05 Jul 2012 17:52:27 -1000
Subject: [csw-maintainers] csw-upload-pkg problems
Message-ID: <CAHo7ehW8J6=Wv5wBzvegH3t3JkHOTZtZwMVXXA19T7bCDbzR2g@mail.gmail.com>

Hi, I'm trying to upload my packages to unstable with the
csw-upload-pkg tool but am getting 401 errors:

Processing 2 file(s). Please wait.
Traceback (most recent call last):
  File "/opt/csw/bin/csw-upload-pkg", line 627, in <module>
    uploader.Upload()
  File "/opt/csw/bin/csw-upload-pkg", line 155, in Upload
    file_in_allpkgs, file_metadata = self._GetSrv4FileMetadata(md5_sum)
  File "/opt/csw/bin/csw-upload-pkg", line 426, in _GetSrv4FileMetadata
    raise RestCommunicationError("Received HTTP code {0}".format(http_code))
__main__.RestCommunicationError: Received HTTP code 401


I'm trying to upload like so:

csw-upload-pkg "libzmq1-2.2.0,REV=2012.07.06-SunOS5.9-i386-CSW.pkg.gz"
"libzmq1_dev-2.2.0,REV=2012.07.06-SunOS5.9-i386-CSW.pkg.gz"
"libzmq1-2.2.0,REV=2012.07.06-SunOS5.9-sparc-CSW.pkg.gz"
"libzmq1_dev-2.2.0,REV=2012.07.06-SunOS5.9-sparc-CSW.pkg.gz"

Is there something I'm missing?

Thanks,
Romeo

From ghenry at opencsw.org  Fri Jul  6 07:32:59 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Fri, 06 Jul 2012 07:32:59 +0200
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling
 perl module
In-Reply-To: <1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
References: <4FF5C2C2.2090007@opencsw.org>
	<1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
Message-ID: <4FF6788B.8000609@opencsw.org>

On 07/05/12 06:47 PM, Ben Walton wrote:
> This is telling you that you've overridden checkpkg in two cases that
> aren't necessary.  T

hummm i'm a newbie to mgar and i'm sure that i didn't it explicitly. The 
only thing i did is to modify the Makefile.
What files are concerned by these overrides ?

thanks

gerard

From maciej at opencsw.org  Fri Jul  6 10:13:04 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 6 Jul 2012 09:13:04 +0100
Subject: [csw-maintainers] csw-upload-pkg problems
In-Reply-To: <CAHo7ehW8J6=Wv5wBzvegH3t3JkHOTZtZwMVXXA19T7bCDbzR2g@mail.gmail.com>
References: <CAHo7ehW8J6=Wv5wBzvegH3t3JkHOTZtZwMVXXA19T7bCDbzR2g@mail.gmail.com>
Message-ID: <CALtRa-6LR63jPn5nknfrip72B4TbMytTTQUBb6cTRE7MGB0Kyw@mail.gmail.com>

2012/7/6 Romeo Theriault <romeotheriault at opencsw.org>:
> Is there something I'm missing?

HTTP 401 means lack of authorization. I'll see if the upload password
is set up correctly.

From bonivart at opencsw.org  Fri Jul  6 10:19:49 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 6 Jul 2012 10:19:49 +0200
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling
 perl module
In-Reply-To: <4FF6788B.8000609@opencsw.org>
References: <4FF5C2C2.2090007@opencsw.org>
	<1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
	<4FF6788B.8000609@opencsw.org>
Message-ID: <CABY0g1Wj1znda1kZOiw7_RBkag94BUanwKUymJVwJ6NjmLYuuw@mail.gmail.com>

On Fri, Jul 6, 2012 at 7:32 AM, Gerard Henry <ghenry at opencsw.org> wrote:
> On 07/05/12 06:47 PM, Ben Walton wrote:
>>
>> This is telling you that you've overridden checkpkg in two cases that
>> aren't necessary.  T
>
>
> hummm i'm a newbie to mgar and i'm sure that i didn't it explicitly. The
> only thing i did is to modify the Makefile.
> What files are concerned by these overrides ?

Those are default overrides for the cpan category that didn't apply in
your case. Don't think twice about it. :)

From maciej at opencsw.org  Fri Jul  6 10:26:04 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 6 Jul 2012 09:26:04 +0100
Subject: [csw-maintainers] csw-upload-pkg problems
In-Reply-To: <CALtRa-6LR63jPn5nknfrip72B4TbMytTTQUBb6cTRE7MGB0Kyw@mail.gmail.com>
References: <CAHo7ehW8J6=Wv5wBzvegH3t3JkHOTZtZwMVXXA19T7bCDbzR2g@mail.gmail.com>
	<CALtRa-6LR63jPn5nknfrip72B4TbMytTTQUBb6cTRE7MGB0Kyw@mail.gmail.com>
Message-ID: <CALtRa-67UuYWbcL3+a=gD0i9PkPfyyAgz_88=agFaPBwQ3ZG7A@mail.gmail.com>

2012/7/6 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 2012/7/6 Romeo Theriault <romeotheriault at opencsw.org>:
>> Is there something I'm missing?
>
> HTTP 401 means lack of authorization. I'll see if the upload password
> is set up correctly.

That was it. Fixed, please try again.

From ghenry at opencsw.org  Fri Jul  6 14:47:09 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Fri, 06 Jul 2012 14:47:09 +0200
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling
 perl module
In-Reply-To: <1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
References: <4FF5C2C2.2090007@opencsw.org>
	<1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
Message-ID: <4FF6DE4D.1020907@opencsw.org>

On 07/05/12 06:47 PM, Ben Walton wrote:
> This is because you have uncommitted work in your recipe.  If you
> commit it so that it's public in the sf.net repository, and then do:
>
> mgar remerge repacakge
>
> You should get a file with -CSW instead of -UNCOMMITTED.

are you sure?

-bash-4.2$ /opt/csw/bin/mgar  remerge repackage
...
## Packaging complete.
mkp: exec( pkgtrans -s /home/ghenry/spool.5.9-i386 
/tmp/pm_classfactutil-1.7,REV=2012.07.06-SunOS5.9-all-UNCOMMITTED.pkg 
CSWpmclassfactutil )
Transferring <CSWpmclassfactutil> package instance
mkp: exec( gzip -9 -f 
/tmp/pm_classfactutil-1.7,REV=2012.07.06-SunOS5.9-all-UNCOMMITTED.pkg )
mkp: exec( mv 
/tmp/pm_classfactutil-1.7,REV=2012.07.06-SunOS5.9-all-UNCOMMITTED.pkg.gz 
/home/ghenry/staging/build-06.Jul.2012 )
mkp: exec( rm -rf /home/ghenry/spool.5.9-i386/CSWpmclassfactutil )
INFO:root:Juicing the svr4 package stream files...
...
and on the web:
http://buildfarm.opencsw.org/pkgdb/srv4/

UNCOMMITTED yet

From maciej at opencsw.org  Fri Jul  6 14:48:23 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 6 Jul 2012 13:48:23 +0100
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling
 perl module
In-Reply-To: <4FF6DE4D.1020907@opencsw.org>
References: <4FF5C2C2.2090007@opencsw.org>
	<1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
	<4FF6DE4D.1020907@opencsw.org>
Message-ID: <CALtRa-4Drrpzo6wKbMDB7G-y8c3HhiknUrvOn5fPXxh75Tpwtw@mail.gmail.com>

2012/7/6 Gerard Henry <ghenry at opencsw.org>:
> and on the web:
> http://buildfarm.opencsw.org/pkgdb/srv4/
>
> UNCOMMITTED yet

What's the output of "svn status"?

From ghenry at opencsw.org  Fri Jul  6 16:45:50 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Fri, 06 Jul 2012 16:45:50 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
Message-ID: <4FF6FA1E.3000303@opencsw.org>

hello all,

i need this perl module because:
http://lists.katipo.co.nz/public/koha/2008-November/015867.html

i don't find it into the repository, or perhaps am i wrong?
pm_cgi_application   CSWpm-cgi-application 4.31,REV=2011.03.09 
54.9 KB
pm_cgi_session       CSWpm-cgi-session    4.43,REV=2011.03.06 
73.3 KB
pm_cgiapp            CSWpmcgiapp          4.31,REV=2011.03.09 
3.8 KB
pm_cgiappdisp        CSWpmcgiappdisp      1.04,REV=2006.05.29 
10.6 KB
pm_cgiapplogdisp     CSWpmcgiapplogdisp   1.00,REV=2006.05.29 
8.8 KB
pm_cgisession        CSWpmcgisession      4.43,REV=2011.03.06 
1.6 KB

is it possible to have it or can i create it? in that case, how to do?
go to the dir CGI-Session? or a new dir ?

thanks in advance,


From bwalton at opencsw.org  Fri Jul  6 16:48:33 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 06 Jul 2012 10:48:33 -0400
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FF6FA1E.3000303@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
Message-ID: <1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>

Excerpts from Gerard Henry's message of Fri Jul 06 10:45:50 -0400 2012:

Hi Gerard,

> is it possible to have it or can i create it? in that case, how to
> do?  go to the dir CGI-Session? or a new dir ?

If it doesn't exist, you're always welcome to create a package for
it.  In that case, a directory at the same level as the rest of the
perl modules is appropriate.

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


From ghenry at opencsw.org  Fri Jul  6 16:54:17 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Fri, 06 Jul 2012 16:54:17 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
Message-ID: <4FF6FC19.5020708@opencsw.org>

On 07/06/12 04:48 PM, Ben Walton wrote:
> Excerpts from Gerard Henry's message of Fri Jul 06 10:45:50 -0400 2012:
>
> Hi Gerard,
>
>> is it possible to have it or can i create it? in that case, how to
>> do?  go to the dir CGI-Session? or a new dir ?
>
> If it doesn't exist, you're always welcome to create a package for
> it.  In that case, a directory at the same level as the rest of the
> perl modules is appropriate.
>
ok as most of the perl modules needed by compiled were done by peter 
bonivart, i'm waiting if he can suggest the best way.


From dam at opencsw.org  Fri Jul  6 17:11:36 2012
From: dam at opencsw.org (dam at opencsw.org)
Date: Fri, 6 Jul 2012 17:11:36 +0200 (CEST)
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FF6FC19.5020708@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
Message-ID: <6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>

Hi Gerard,

> Excerpts from Gerard Henry's message of Fri Jul 06 10:45:50 -0400 2012:
> ok as most of the perl modules needed by compiled were done by peter
> bonivart, i'm waiting if he can suggest the best way.

Please try
  cd cpan/
  ./makemake CGI::Session::Serialize::yaml
Then
  cd CGI-Session-Serialize-yaml/trunk
and work towards a releasable package with
  mgar spotless
  mgar package
  (debug)
  ...
and finally
  mgar commit -m "Initial commit"
  mgar repackage

Best regards

  -- Dago

From bonivart at opencsw.org  Fri Jul  6 17:13:57 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Fri, 6 Jul 2012 17:13:57 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FF6FC19.5020708@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
Message-ID: <CABY0g1U18jYC0SK7MD1W6RupmnmxQGbbsUT8CVrWkAfedx9jjQ@mail.gmail.com>

On Fri, Jul 6, 2012 at 4:54 PM, Gerard Henry <ghenry at opencsw.org> wrote:
> On 07/06/12 04:48 PM, Ben Walton wrote:
>>
>> Excerpts from Gerard Henry's message of Fri Jul 06 10:45:50 -0400 2012:
>>
>> Hi Gerard,
>>
>>> is it possible to have it or can i create it? in that case, how to
>>> do? ?go to the dir CGI-Session? or a new dir ?
>>
>>
>> If it doesn't exist, you're always welcome to create a package for
>> it. ?In that case, a directory at the same level as the rest of the
>> perl modules is appropriate.
>>
> ok as most of the perl modules needed by compiled were done by peter
> bonivart, i'm waiting if he can suggest the best way.

You seem to have looked for it, the closest one is CGI::Session,
there's a chance it contains this submodule so go to
http://www.opencsw.org/packages/CSWpm-cgi-session/ and browse the
files to see if that's the case. It isn't, then go to CPAN, look up
this module, http://search.cpan.org/~rsavage/CGI-Session-Serialize-yaml-4.26,
seems to be a separate module for it so go ahead and create a new
package. Dagos makemake should work nicely for this.

/peter

From ghenry at opencsw.org  Fri Jul  6 17:28:27 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Fri, 06 Jul 2012 17:28:27 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
Message-ID: <4FF7041B.1000808@opencsw.org>

On 07/06/12 05:11 PM, dam at opencsw.org wrote:
>   cd cpan/
>    ./makemake CGI::Session::Serialize::yaml
> Then
>    cd CGI-Session-Serialize-yaml/trunk


it doesn't work:

> -bash-4.2$ ./makemake CGI::Session::Serialize::yaml
> Expanding CPAN module name
> -bash-4.2$ cd CGI-Session-Serialize-yaml/trunk
> -bash: cd: CGI-Session-Serialize-yaml/trunk: No such file or directory

do i have to create this dir before?

From dam at opencsw.org  Fri Jul  6 21:23:19 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 6 Jul 2012 21:23:19 +0200
Subject: [csw-maintainers] gmake: *** [pkgcheck] Error 2 when compiling
	perl module
In-Reply-To: <CALtRa-4Drrpzo6wKbMDB7G-y8c3HhiknUrvOn5fPXxh75Tpwtw@mail.gmail.com>
References: <4FF5C2C2.2090007@opencsw.org>
	<1341506732-sup-1590@pinkfloyd.chass.utoronto.ca>
	<4FF6DE4D.1020907@opencsw.org>
	<CALtRa-4Drrpzo6wKbMDB7G-y8c3HhiknUrvOn5fPXxh75Tpwtw@mail.gmail.com>
Message-ID: <6F9A5341-B7CB-450B-AF0B-E462A507A050@opencsw.org>

Hi Gerard,

Am 06.07.2012 um 14:48 schrieb Maciej (Matchek) Blizi?ski:
> 2012/7/6 Gerard Henry <ghenry at opencsw.org>:
>> and on the web:
>> http://buildfarm.opencsw.org/pkgdb/srv4/
>> 
>> UNCOMMITTED yet
> 
> What's the output of "svn status"?

To be precise: "svn status" must not give any output for UNCOMMITTED to go away.


Best regards

  -- Dago



From dam at opencsw.org  Fri Jul  6 21:36:28 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 6 Jul 2012 21:36:28 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FF7041B.1000808@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
Message-ID: <895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>

Hi Gerard,

Am 06.07.2012 um 17:28 schrieb Gerard Henry:
> On 07/06/12 05:11 PM, dam at opencsw.org wrote:
>>  cd cpan/
>>   ./makemake CGI::Session::Serialize::yaml
>> Then
>>   cd CGI-Session-Serialize-yaml/trunk
> 
> it doesn't work:
> 
>> -bash-4.2$ ./makemake CGI::Session::Serialize::yaml
>> Expanding CPAN module name
>> -bash-4.2$ cd CGI-Session-Serialize-yaml/trunk
>> -bash: cd: CGI-Session-Serialize-yaml/trunk: No such file or directory
> 
> do i have to create this dir before?

No, for me it looks like the below snippet. Looking at makemake I am not sure
where it can possibly stop without a notice or anything. Where did you try it?
Please repeat the execution on unstable9s to see if that was the cause.
Next actions would be to install pm_cgi_session which I just did.


Best regards

  -- Dago

> unstable9s% ./makemake CGI::Session::Serialize::yaml
> Expanding CPAN module name
> Analyzing filename
> Getting DSLIP
> Getting distribution file
> Processing META.yml
> - build dependencies
> Packages for module 'Test::More': CSWperl
> Packages for module 'File::Spec': CSWperl
> Packages for module 'Test::Pod': CSWpmtestpod
> ERROR: Found package name 'CSWpmtestpod' is not consistent to the canonical 'CSWpm-test-pod', please invoke  makemake Test::Pod
> - runtime dependencies
> Packages for module 'CGI::Session': CSWpm-cgi-session
> ERROR: The needed package CSWpm-cgi-session is not installed
> Packages for module 'CGI::Session::ErrorHandler': CSWpm-cgi-session
> ERROR: The needed package CSWpm-cgi-session is not installed
> /home/dam/mgar/pkg/cpan
> A         CGI-Session-Serialize-yaml
> A         CGI-Session-Serialize-yaml/tags
> A         CGI-Session-Serialize-yaml/branches
> A         CGI-Session-Serialize-yaml/trunk
> A         CGI-Session-Serialize-yaml/trunk/files
> A         CGI-Session-Serialize-yaml/trunk/Makefile
> A         CGI-Session-Serialize-yaml/trunk/checksums
> property 'svn:ignore' set on 'CGI-Session-Serialize-yaml/trunk'
> 
> Your package is set up for editing at CGI-Session-Serialize-yaml/trunk
> Writing GAR Makefile
>  ==> Removing work/solaris9-sparc/cookies/global
>  ==> Removing work/solaris9-sparc/build-global
> mv: cannot access work/solaris9-sparc/build-global
> gmake: [imageclean] Error 2 (ignored)
>  ==> Removing /home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-global
> mv: cannot access work
> gmake: [spotless] Error 2 (ignored)
> [===== NOW BUILDING: CGI-Session-Serialize-yaml-4.26 =====]
> ginstall -d work/solaris9-sparc/cookies/global
> ginstall -d work/solaris9-sparc/download
> ginstall -d work/solaris9-sparc/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
> ==> Verifying installed package CSWpmtestpod: ok
>         [prerequisite] complete for CGI-Session-Serialize-yaml.
>  ==> Grabbing work/solaris9-sparc/download/CGI-Session-Serialize-yaml-4.26.tgz
>         ==> Trying file://files/CGI-Session-Serialize-yaml-4.26.tgz
>         ==> Trying file:///home/src/CGI-Session-Serialize-yaml-4.26.tgz
>         ==> Trying http://search.cpan.org/CPAN/authors/id/R/RS/RSAVAGE/CGI-Session-Serialize-yaml-4.26.tgz
> --2012-07-06 21:25:17--  http://search.cpan.org/CPAN/authors/id/R/RS/RSAVAGE/CGI-Session-Serialize-yaml-4.26.tgz
> Resolving proxy (proxy)... 192.168.1.6
> Connecting to proxy (proxy)|192.168.1.6|:3128... connected.
> Proxy request sent, awaiting response... 302 Moved Temporarily
> Location: http://mirror.netcologne.de/cpan/authors/id/R/RS/RSAVAGE/CGI-Session-Serialize-yaml-4.26.tgz [following]
> --2012-07-06 21:25:17--  http://mirror.netcologne.de/cpan/authors/id/R/RS/RSAVAGE/CGI-Session-Serialize-yaml-4.26.tgz
> Reusing existing connection to proxy:3128.
> Proxy request sent, awaiting response... 200 OK
> Length: 5386 (5.3K) [application/x-gzip]
> Saving to: `work/solaris9-sparc/download/partial/CGI-Session-Serialize-yaml-4.26.tgz'
> 
>      0K .....                                                 100%  111M=0s
> 
> 2012-07-06 21:25:18 (111 MB/s) - `work/solaris9-sparc/download/partial/CGI-Session-Serialize-yaml-4.26.tgz' saved [5386/5386]
> 
>         [fetch] complete for CGI-Session-Serialize-yaml.
> Checksums made for CGI-Session-Serialize-yaml-4.26.tgz
> 29f35caaf1de910c0a99bdc9b2f05264  CGI-Session-Serialize-yaml-4.26.tgz
> [===== NOW BUILDING: CGI-Session-Serialize-yaml-4.26 =====]
>         [prerequisite] complete for CGI-Session-Serialize-yaml.
>         [fetch] complete for CGI-Session-Serialize-yaml.
>  ==> Running checksum on CGI-Session-Serialize-yaml-4.26.tgz
> 29f35caaf1de910c0a99bdc9b2f05264  CGI-Session-Serialize-yaml-4.26.tgz
> file CGI-Session-Serialize-yaml-4.26.tgz passes checksum test!
>         [checksum] complete for CGI-Session-Serialize-yaml.
>         [checksum-global] complete for CGI-Session-Serialize-yaml.
>         [checksum-modulated] complete for CGI-Session-Serialize-yaml.
> ginstall -d work/solaris9-sparc/build-global
> [===== NOW BUILDING: CGI-Session-Serialize-yaml-4.26 MODULATION global: ISA= =====]
>  ==> Copying work/solaris9-sparc/download/CGI-Session-Serialize-yaml-4.26.tgz
>         [extract-modulated] complete for CGI-Session-Serialize-yaml.
> [===== Building modulation 'isa-sparcv8' on host 'unstable9s' =====]
> gmake GAR_PLATFORM=solaris9-sparc MODULATION=isa-sparcv8  ISA=sparcv8  merge-modulated 
> gmake[1]: Entering directory `/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk'
> gmake -s MODULATION=global checksum
> gmake[2]: Entering directory `/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk'
> [===== NOW BUILDING: CGI-Session-Serialize-yaml-4.26 =====]
>         [prerequisite] complete for CGI-Session-Serialize-yaml.
>         [fetch] complete for CGI-Session-Serialize-yaml.
>         [checksum] complete for CGI-Session-Serialize-yaml.
> gmake[2]: Leaving directory `/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk'
>         [checksum-global] complete for CGI-Session-Serialize-yaml.
>         [checksum-modulated] complete for CGI-Session-Serialize-yaml.
> ginstall -d work/solaris9-sparc/build-isa-sparcv8
> [===== NOW BUILDING: CGI-Session-Serialize-yaml-4.26 MODULATION isa-sparcv8: ISA=sparcv8 =====]
>  ==> Extracting work/solaris9-sparc/download/CGI-Session-Serialize-yaml-4.26.tgz
>  ==> Snapshotting extracted source tree with git
> Initialized empty Git repository in /home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26/.git/
> [master (root-commit) b847ab7] Upstream 4.26
>  11 files changed, 401 insertions(+)
>  create mode 100644 Build.PL
>  create mode 100644 CHANGES
>  create mode 100644 Changelog.ini
>  create mode 100644 INSTALL
>  create mode 100644 MANIFEST
>  create mode 100644 META.yml
>  create mode 100644 Makefile.PL
>  create mode 100644 README
>  create mode 100644 lib/CGI/Session/Serialize/yaml.pm
>  create mode 100644 t/g4_dbfile_yaml.t
>  create mode 100644 t/pod.t
> Switched to a new branch 'csw'
>         [extract-modulated] complete for CGI-Session-Serialize-yaml.
> Tagging top of current csw patch stack...
>         [patch-modulated] complete for CGI-Session-Serialize-yaml.
>  ==> Running Build.PL in work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26
> ( cd work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26 ; \
>     HOME="/home/dam" PATH="/home/dam/mgar/pkg/.buildsys/v2/gar/bin/sos12-wrappers:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/bin:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/bin:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/sbin:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/SUNWspro/bin:/home/dam/mgar/pkg/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-xO3 -m32 -xarch=v8" CXXFLAGS="-xO3 -m32 -xarch=v8" LDFLAGS="-m32 -xarch=v8 -L/opt/csw/lib" FFLAGS="-xO3 -m32 -xarch=v8" FCFLAGS="-xO3 -m32 -xarch=v8" F77="/opt/SUNWspro/bin/f77" FC="/opt/SUNWspro/bin/f95" ASFLAGS="" OPTFLAGS="-xO3 -m32 -xarch=v8" CC="/opt/SUNWspro/bin/cc" CXX="/opt/SUNWspro/bin/CC" CC_HOME="/opt/SUNWspro" CC_VERSION="Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11" CXX_VERSION="Sun C++ 5.9 SunOS_sparc Patch 124863-29 2012/04/04" GARCH="sparc" GAROSREL="5.9" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -L/opt/csw/lib -lperl" PKG_CONFIG_PATH="/opt/csw/lib/pkgconfig" DESTDIR="/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8"  PERL5LIB= PERL_MM_USE_DEFAULT=1  /opt/csw/bin/perl Build.PL \
>         installdirs=vendor  --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man  )
> Checking prerequisites...
>   requires:
>     !  CGI::Session is not installed
>     !  CGI::Session::ErrorHandler is not installed
> 
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the versions
> of the modules indicated above before proceeding with this installation
> 
> Created MYMETA.yml and MYMETA.json
> Creating new 'Build' script for 'CGI-Session-Serialize-yaml' version '4.26'
>         [configure-modulated] complete for CGI-Session-Serialize-yaml.
>  ==> Running Build in work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26
> ( cd work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26 ; HOME="/home/dam" PATH="/home/dam/mgar/pkg/.buildsys/v2/gar/bin/sos12-wrappers:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/bin:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/bin:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/sbin:/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/SUNWspro/bin:/home/dam/mgar/pkg/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-xO3 -m32 -xarch=v8" CXXFLAGS="-xO3 -m32 -xarch=v8" LDFLAGS="-m32 -xarch=v8 -L/opt/csw/lib" FFLAGS="-xO3 -m32 -xarch=v8" FCFLAGS="-xO3 -m32 -xarch=v8" F77="/opt/SUNWspro/bin/f77" FC="/opt/SUNWspro/bin/f95" ASFLAGS="" OPTFLAGS="-xO3 -m32 -xarch=v8" CC="/opt/SUNWspro/bin/cc" CXX="/opt/SUNWspro/bin/CC" CC_HOME="/opt/SUNWspro" CC_VERSION="Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11" CXX_VERSION="Sun C++ 5.9 SunOS_sparc Patch 124863-29 2012/04/04" GARCH="sparc" GAROSREL="5.9" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -L/opt/csw/lib -lperl"  PERL5LIB= ./Build )
> Building CGI-Session-Serialize-yaml
>  ==> Running Build test in work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26
> t/g4_dbfile_yaml.t .. Can't locate CGI/Session/Test/Default.pm in @INC (@INC contains: /home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26/blib/lib /home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26/blib/arch /opt/csw/lib/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/lib/perl/csw /opt/csw/share/perl/csw /opt/csw/share/perl/csw /opt/csw/lib/perl/5.10.1 /opt/csw/share/perl/5.10.1 .) at t/g4_dbfile_yaml.t line 8.
> BEGIN failed--compilation aborted at t/g4_dbfile_yaml.t line 8 (#1)
>     (F) You said to do (or require, or use) a file that couldn't be
>     found. Perl looks for the file in all the locations mentioned in @INC,
>     unless the file name included the full path to the file.  Perhaps you
>     need to set the PERL5LIB or PERL5OPT environment variable to say where
>     the extra library is, or maybe the script needs to add the library name
>     to @INC.  Or maybe you just misspelled the name of the file.  See
>     perlfunc/require and lib.
>     
> Uncaught exception from user code:
>         Can't locate CGI/Session/Test/Default.pm in @INC (@INC contains: /home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26/blib/lib /home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk/work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26/blib/arch /opt/csw/lib/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/lib/perl/csw /opt/csw/share/perl/csw /opt/csw/share/perl/csw /opt/csw/lib/perl/5.10.1 /opt/csw/share/perl/5.10.1 .) at t/g4_dbfile_yaml.t line 8.
> BEGIN failed--compilation aborted at t/g4_dbfile_yaml.t line 8.
>  at t/g4_dbfile_yaml.t line 8
> t/g4_dbfile_yaml.t .. Dubious, test returned 2 (wstat 512, 0x200)
> No subtests run 
> t/pod.t ............. ok   
> 
> Test Summary Report
> -------------------
> t/g4_dbfile_yaml.t (Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: No plan found in TAP output
> Files=2, Tests=1,  1 wallclock secs ( 0.15 usr  0.06 sys +  1.32 cusr  0.15 csys =  1.68 CPU)
> Result: FAIL
> Failed 1/2 test programs. 0/1 subtests failed.
> gmake[1]: *** [test-work/solaris9-sparc/build-isa-sparcv8/CGI-Session-Serialize-yaml-4.26/Build] Error 255
> gmake[1]: Leaving directory `/home/dam/mgar/pkg/cpan/CGI-Session-Serialize-yaml/trunk'
> gmake: *** [merge-isa-sparcv8] Error 2
> Bad file number at ./makemake line 269.
> unstable9s% 
> 
> 


From romeotheriault at opencsw.org  Fri Jul  6 21:46:29 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Fri, 06 Jul 2012 09:46:29 -1000
Subject: [csw-maintainers] csw-upload-pkg problems
In-Reply-To: <CALtRa-67UuYWbcL3+a=gD0i9PkPfyyAgz_88=agFaPBwQ3ZG7A@mail.gmail.com>
References: <CAHo7ehW8J6=Wv5wBzvegH3t3JkHOTZtZwMVXXA19T7bCDbzR2g@mail.gmail.com>
	<CALtRa-6LR63jPn5nknfrip72B4TbMytTTQUBb6cTRE7MGB0Kyw@mail.gmail.com>
	<CALtRa-67UuYWbcL3+a=gD0i9PkPfyyAgz_88=agFaPBwQ3ZG7A@mail.gmail.com>
Message-ID: <CAHo7ehU455QvWMr99YW0WsVicNTcuXq+C_6kzqhcuXcDk7Jzng@mail.gmail.com>

On Thu, Jul 5, 2012 at 10:26 PM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2012/7/6 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> 2012/7/6 Romeo Theriault <romeotheriault at opencsw.org>:
>>> Is there something I'm missing?
>>
>> HTTP 401 means lack of authorization. I'll see if the upload password
>> is set up correctly.
>
> That was it. Fixed, please try again.

Bingo, that was it. Thank you very much.

Romeo

From ghenry at opencsw.org  Sat Jul  7 09:32:20 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Sat, 07 Jul 2012 09:32:20 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
Message-ID: <4FF7E604.6050204@opencsw.org>

On 07/06/12 09:36 PM, Dagobert Michelsen wrote:
> No, for me it looks like the below snippet. Looking at makemake I am not sure
> where it can possibly stop without a notice or anything. Where did you try it?
> Please repeat the execution on unstable9s to see if that was the cause.
> Next actions would be to install pm_cgi_session which I just did.
>

very strange for me:
ghenry at unstable9s :~/opencsw/cpan > ./makemake
Please supply the module name as a parameter.
Baling out...
ghenry at unstable9s :~/opencsw/cpan > ./makemake TOTO
Expanding CPAN module name
and nothing else

ghenry at unstable9s :~/opencsw/cpan > ./makemake CGI::Session::Serialize::yaml
Expanding CPAN module name
ghenry at unstable9s :~/opencsw/cpan >

i'm not very friendly with perl, and i don't know how to debug what's 
happen? Is there a verbose mode?
in makemake:
     31  ### Variables ###
     32  my ( $verbose, $logfile, $pgm );

i don't understand where is the logfile? and who set $verbose?


thanks

gerard

From bonivart at opencsw.org  Sat Jul  7 09:57:12 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 7 Jul 2012 09:57:12 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FF7E604.6050204@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
Message-ID: <CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>

On Sat, Jul 7, 2012 at 9:32 AM, Gerard Henry <ghenry at opencsw.org> wrote:
> On 07/06/12 09:36 PM, Dagobert Michelsen wrote:
>>
>> No, for me it looks like the below snippet. Looking at makemake I am not
>> sure
>> where it can possibly stop without a notice or anything. Where did you try
>> it?
>> Please repeat the execution on unstable9s to see if that was the cause.
>> Next actions would be to install pm_cgi_session which I just did.
>>
>
> very strange for me:
> ghenry at unstable9s :~/opencsw/cpan > ./makemake
> Please supply the module name as a parameter.
> Baling out...
> ghenry at unstable9s :~/opencsw/cpan > ./makemake TOTO
> Expanding CPAN module name
> and nothing else
>
> ghenry at unstable9s :~/opencsw/cpan > ./makemake CGI::Session::Serialize::yaml
> Expanding CPAN module name
> ghenry at unstable9s :~/opencsw/cpan >
>
> i'm not very friendly with perl, and i don't know how to debug what's
> happen? Is there a verbose mode?
> in makemake:
>     31  ### Variables ###
>     32  my ( $verbose, $logfile, $pgm );
>
> i don't understand where is the logfile? and who set $verbose?

You and Dago can debug this but there's also other options.

You can do the package the old fashioned way, i.e. with mgar newpkg
and looking at a similar Makefile, e.g. CGI::Session.

Also you can let others, e.g. me, do the modules and you concentrate
on Koha itself.

/peter

From ghenry at opencsw.org  Sat Jul  7 10:04:39 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Sat, 07 Jul 2012 10:04:39 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
Message-ID: <4FF7ED97.5010908@opencsw.org>

On 07/07/12 09:57 AM, Peter Bonivart wrote:
> Also you can let others, e.g. me, do the modules and you concentrate
> on Koha itself.

Sure! very thanks, i like very much this option, because koha is a 
nigthmare when upgrading (even on linux)

gerard

From bonivart at opencsw.org  Sat Jul  7 10:07:35 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sat, 7 Jul 2012 10:07:35 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FF7ED97.5010908@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
Message-ID: <CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>

On Sat, Jul 7, 2012 at 10:04 AM, Gerard Henry <ghenry at opencsw.org> wrote:
> On 07/07/12 09:57 AM, Peter Bonivart wrote:
>>
>> Also you can let others, e.g. me, do the modules and you concentrate
>> on Koha itself.
>
>
> Sure! very thanks, i like very much this option, because koha is a nigthmare
> when upgrading (even on linux)

Could you please update the old project page on the wiki? I assume
most of it is still current but we need to know if there's more
modules needed that we don't have and if those we have are too old.

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

/peter

From pfelecan at opencsw.org  Sat Jul  7 15:21:07 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 07 Jul 2012 15:21:07 +0200
Subject: [csw-maintainers] Solaris versions on the public build farm
Message-ID: <x6ipdzaerg.fsf@opencsw.org>

I spent some time battling with the build of libxvidcore. The issue was
quite opaque until I discovered that the linker on the public build farm
has not the same version as on my private build farm (which is pure
Solaris 10 U10).

On the public build farm, the linker is of version 5.10-1.500 when on
the private build-farm, the verion of the linker is 5.10-1.1505. The
incriminated difference is the support of long options in the more
recent linker, particularly --soname as an alias of -h; the long option
can be found in the GNU linker, -soname variation. This has confused the
build system as myself. For me the issue is solved but can raise
confusion for others as many upstream projects, xvid being part of them,
has patched their build system to support the latest Solaris versions...

Can we have an assessment of the versions installed in the public build
farm? Ideally we should have the last versions, isn't it?
-- 
Peter

From bonivart at opencsw.org  Sun Jul  8 07:00:33 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 8 Jul 2012 07:00:33 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
Message-ID: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>

I was building CSWpm-cgi-session-serialize-yaml and got the following:

INFO:root:Juicing the svr4 package stream files...
100% |#########################################################################|
INFO:root:Unwrapping candies...
100% |#########################################################################|
INFO:root:Tasting candies one by one...
WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
attempt to process datastream failed
WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:    - package
<CSWpm-cgi-session-serialize-yaml> not in datastream
WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
unable to complete package transfer
100% |#########################################################################|
INFO:root:Tasting them all at once...
INFO:root:Stuffing the candies under the pillow...
Traceback (most recent call last):                                             |
  File "/home/bonivart/opencsw/.buildsys/v2/gar//bin/checkpkg", line
197, in <module>
    main()
  File "/home/bonivart/opencsw/.buildsys/v2/gar//bin/checkpkg", line
158, in main
    exit_code, screen_report, tags_report = check_manager.Run()
  File "/home/bonivart/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py",
line 824, in Run
    return super(CheckpkgManager2, self).Run()
  File "/home/bonivart/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py",
line 256, in Run
    arch=sqo_arch)
  File "/opt/csw/lib/python/site-packages/sqlobject/main.py", line
1226, in __init__
    self._create(id, **kw)
  File "/opt/csw/lib/python/site-packages/sqlobject/main.py", line
1271, in _create
    self.set(**kw)
  File "/opt/csw/lib/python/site-packages/sqlobject/main.py", line 1079, in set
    kw[name] = dbValue = from_python(value, self._SO_validatorState)
  File "/opt/csw/lib/python/site-packages/sqlobject/col.py", line 568,
in from_python
    (self.name, type(value), value), value, state)
formencode.api.Invalid: expected a str or a unicode in the UnicodeCol
'tag_info', got <type 'int'> 1 instead
gmake: *** [pkgcheck] Error 2

I then shortened the package and catalog name slightly and the error
went away. I assume this is because Solaris package tools truncate the
name or something, or is it in GAR?

/peter

From Joerg.Schilling at fokus.fraunhofer.de  Sun Jul  8 12:03:25 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Sun, 08 Jul 2012 12:03:25 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
Message-ID: <4ff95aed.CWbt8XNHc4zFO2Nk%Joerg.Schilling@fokus.fraunhofer.de>

Peter Bonivart <bonivart at opencsw.org> wrote:

> I was building CSWpm-cgi-session-serialize-yaml and got the following:

>
> I then shortened the package and catalog name slightly and the error
> went away. I assume this is because Solaris package tools truncate the
> name or something, or is it in GAR?
>

The limit is 32 bytes, I don't remember whether this includes the null byte.

I am planning to change this for Schillix-ON to 64 or 128 in order to allow 
longer descriptive names such as in IPS.

J?rg

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

From romeotheriault at opencsw.org  Sun Jul  8 13:39:52 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Sun, 08 Jul 2012 01:39:52 -1000
Subject: [csw-maintainers] Use of <stdbool.h> is valid only in a c99
	compilation environment.
Message-ID: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>

Hello, I'm trying to build a python package called msgpack-python.
There are some parts in C that are compiled during the build. Using
the the Sun 'cc' I get this error when building it:

"/usr/include/stdbool.h", line 42: #error: "Use of <stdbool.h> is
valid only in a c99 compilation environment."

I've googled extensively and have tried piles of different
"EXTRA_CFLAGS" (e.g.-std=c99, -xc99=all, -D_STDC_C99 ) but to no
avail. I can't seem to get past this. Does anyone have any suggestion
on how I might work past this problem?

I also tried building the package against gcc and I get this error:

gcc-4.7: error: language code=pic32 not recognized

which I believe is because python was built against the sun 'cc'
compiler. If I manually remove that pic32 CFLAG the package compiles
successfully. Assuming I can't get the program to build against sun's
C compiler, how can I exclude the "pic32" CFLAG so I can get the
package to build against gcc?

Thanks for any help,
Romeo

From dam at opencsw.org  Sun Jul  8 16:25:24 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 8 Jul 2012 16:25:24 +0200
Subject: [csw-maintainers] Use of <stdbool.h> is valid only in a c99
	compilation environment.
In-Reply-To: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>
References: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>
Message-ID: <36F163E9-AA02-4531-B374-DD0D708CDB55@opencsw.org>

Hi Romeo,

Am 08.07.2012 um 13:39 schrieb Romeo Theriault:
> Hello, I'm trying to build a python package called msgpack-python.
> There are some parts in C that are compiled during the build. Using
> the the Sun 'cc' I get this error when building it:
> 
> "/usr/include/stdbool.h", line 42: #error: "Use of <stdbool.h> is
> valid only in a c99 compilation environment."
> 
> I've googled extensively and have tried piles of different
> "EXTRA_CFLAGS" (e.g.-std=c99, -xc99=all, -D_STDC_C99 ) but to no
> avail. I can't seem to get past this. Does anyone have any suggestion
> on how I might work past this problem?

First guess: make sure the flags actually make it to the compiler invocation.
If in doubt please commit what you have so I can have a look.

> I also tried building the package against gcc and I get this error:
> 
> gcc-4.7: error: language code=pic32 not recognized
> 
> which I believe is because python was built against the sun 'cc'
> compiler. If I manually remove that pic32 CFLAG the package compiles
> successfully. Assuming I can't get the program to build against sun's
> C compiler, how can I exclude the "pic32" CFLAG so I can get the
> package to build against gcc?

This is probably added during configure-time, so there is probably not
an easy answer besides "find where it is added and remove it".


Best regards

  -- Dago

From bwalton at opencsw.org  Sun Jul  8 16:26:13 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 08 Jul 2012 10:26:13 -0400
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
Message-ID: <1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter Bonivart's message of Sun Jul 08 01:00:33 -0400 2012:

> I then shortened the package and catalog name slightly and the error
> went away. I assume this is because Solaris package tools truncate
> the name or something, or is it in GAR?

The limit was 20 chars and we upped it to 32 a while back.  The
truncation happens in GAR, iirc.  It matches the capability of the
underlying package tools though so we can't currently extend it
further.

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


From skayser at opencsw.org  Sun Jul  8 16:28:16 2012
From: skayser at opencsw.org (Sebastian Kayser)
Date: Sun, 8 Jul 2012 16:28:16 +0200
Subject: [csw-maintainers] Use of <stdbool.h> is valid only in a c99
	compilation environment.
In-Reply-To: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>
References: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>
Message-ID: <20120708142816.GA15609@sebastiankayser.de>

Hi Romeo,

* Romeo Theriault <romeotheriault at opencsw.org> wrote:
> Hello, I'm trying to build a python package called msgpack-python.
> There are some parts in C that are compiled during the build. Using
> the the Sun 'cc' I get this error when building it:
> 
> "/usr/include/stdbool.h", line 42: #error: "Use of <stdbool.h> is
> valid only in a c99 compilation environment."
> 
> I've googled extensively and have tried piles of different
> "EXTRA_CFLAGS" (e.g.-std=c99, -xc99=all, -D_STDC_C99 ) but to no
> avail. I can't seem to get past this. Does anyone have any suggestion
> on how I might work past this problem?

I am not too familiar with the c99 details, but if changing the flags is
actually the cure to your problem, here's what I'd do. The error message
looks like it's emitted by the preprocessor invocation which can be
tweaked with EXTRA_CPPFLAGS (EXTRA_CFLAGS is passed to the compiler
only). Using that should already give you better results. You can use
"mgar modenv" to verify the invocation flags without actually running
the build.

For how exactly to tweak the flags. Usually there's a good chance that
other people have already run into a similar problem and have solved it.
Try searching the existing build recipes for "99", maybe that gives you
the solution right away.

HTH

Sebastian

From bonivart at opencsw.org  Sun Jul  8 16:47:02 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 8 Jul 2012 16:47:02 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
Message-ID: <CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>

On Sun, Jul 8, 2012 at 4:26 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Peter Bonivart's message of Sun Jul 08 01:00:33 -0400 2012:
>
>> I then shortened the package and catalog name slightly and the error
>> went away. I assume this is because Solaris package tools truncate
>> the name or something, or is it in GAR?
>
> The limit was 20 chars and we upped it to 32 a while back.  The
> truncation happens in GAR, iirc.  It matches the capability of the
> underlying package tools though so we can't currently extend it
> further.

That's OK but I would like to get a proper error for it, not that
checkpkg collapses. :) Maybe GAR could tell me if it changes stuff on
the fly or maybe we could put it in mgar.

/peter

From maciej at opencsw.org  Sun Jul  8 16:54:41 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 8 Jul 2012 15:54:41 +0100
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
	<CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
Message-ID: <CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>

2012/7/8 Peter Bonivart <bonivart at opencsw.org>
>
> That's OK but I would like to get a proper error for it, not that
> checkpkg collapses. :) Maybe GAR could tell me if it changes stuff on
> the fly or maybe we could put it in mgar.

One failure mode I would guess is that one check in package_checks.py
is passing an int instead of a unicode or a string object.

Try adding this patch and recreating the problem:

diff --git a/gar/v2/lib/python/checkpkg_lib.py
b/gar/v2/lib/python/checkpkg_lib.py
index 17f07aa..e319ec8 100644
--- a/gar/v2/lib/python/checkpkg_lib.py
+++ b/gar/v2/lib/python/checkpkg_lib.py
@@ -249,7 +249,7 @@ class CheckpkgManagerBase(SqlobjectHelperMixin):
             srv4_file=db_stat_objs_by_pkgname[e.pkgname],
             pkgname=e.pkgname,
             tag_name=e.tag_name,
-            tag_info=e.tag_info,
+            tag_info=unicode(e.tag_info),
             msg=e.msg,
             os_rel=sqo_os_rel,
             catrel=sqo_catrel,

What extra error tag do you get after adding this patch?

From bonivart at opencsw.org  Sun Jul  8 17:43:50 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 8 Jul 2012 17:43:50 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
	<CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
	<CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>
Message-ID: <CABY0g1VAXzh-uQFwU=SF-nb+tSMBTt=yaofZ73Sq1dP0046pew@mail.gmail.com>

On Sun, Jul 8, 2012 at 4:54 PM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2012/7/8 Peter Bonivart <bonivart at opencsw.org>
>>
>> That's OK but I would like to get a proper error for it, not that
>> checkpkg collapses. :) Maybe GAR could tell me if it changes stuff on
>> the fly or maybe we could put it in mgar.
>
> One failure mode I would guess is that one check in package_checks.py
> is passing an int instead of a unicode or a string object.
>
> Try adding this patch and recreating the problem:
>
> diff --git a/gar/v2/lib/python/checkpkg_lib.py
> b/gar/v2/lib/python/checkpkg_lib.py
> index 17f07aa..e319ec8 100644
> --- a/gar/v2/lib/python/checkpkg_lib.py
> +++ b/gar/v2/lib/python/checkpkg_lib.py
> @@ -249,7 +249,7 @@ class CheckpkgManagerBase(SqlobjectHelperMixin):
>              srv4_file=db_stat_objs_by_pkgname[e.pkgname],
>              pkgname=e.pkgname,
>              tag_name=e.tag_name,
> -            tag_info=e.tag_info,
> +            tag_info=unicode(e.tag_info),
>              msg=e.msg,
>              os_rel=sqo_os_rel,
>              catrel=sqo_catrel,
>
> What extra error tag do you get after adding this patch?

It doesn't blow up now which is good but it still doesn't tell me what's wrong:

INFO:root:Juicing the svr4 package stream files...
100% |#########################################################################|
INFO:root:Unwrapping candies...
100% |#########################################################################|
INFO:root:Tasting candies one by one...
WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
attempt to process datastream failed
WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:    - package
<CSWpm-cgi-session-serialize-yaml> not in datastream
WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
unable to complete package transfer
100% |#########################################################################|
INFO:root:Tasting them all at once...
INFO:root:Stuffing the candies under the pillow...
100% |#########################################################################|
CSWpm-cgi-session-serialize-yaml:
If any of the reported errors were false positives, you can override them
pasting the lines below to the GAR recipe.
CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml += pkgchk-failed-with-code|1
CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml +=
pkginfo-opencsw-repository-uncommitted|None

I assume the truncation happened before checkpkg gets a hold of the
package, that's why I suggested a check in mgar or GAR.

From maciej at opencsw.org  Sun Jul  8 17:59:35 2012
From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=)
Date: Sun, 8 Jul 2012 16:59:35 +0100
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <CABY0g1VAXzh-uQFwU=SF-nb+tSMBTt=yaofZ73Sq1dP0046pew@mail.gmail.com>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
	<CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
	<CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>
	<CABY0g1VAXzh-uQFwU=SF-nb+tSMBTt=yaofZ73Sq1dP0046pew@mail.gmail.com>
Message-ID: <20120708155935.GA14220@quince.home.blizinski.pl>

On Sun, Jul 08, 2012 at 05:43:50PM +0200, Peter Bonivart wrote:
> It doesn't blow up now which is good but it still doesn't tell me what's wrong:

How does it not tell you?

> INFO:root:Juicing the svr4 package stream files...
> 100% |#########################################################################|
> INFO:root:Unwrapping candies...
> 100% |#########################################################################|
> INFO:root:Tasting candies one by one...
> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
> attempt to process datastream failed
> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:    - package
> <CSWpm-cgi-session-serialize-yaml> not in datastream
> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
> unable to complete package transfer
> 100% |#########################################################################|
> INFO:root:Tasting them all at once...
> INFO:root:Stuffing the candies under the pillow...
> 100% |#########################################################################|
> CSWpm-cgi-session-serialize-yaml:
> If any of the reported errors were false positives, you can override them
> pasting the lines below to the GAR recipe.

Just read this bit:

> CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml += pkgchk-failed-with-code|1
> CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml +=
> pkginfo-opencsw-repository-uncommitted|None

"pkgchk-failed-with-code|1" means that pkgchk (/usr/sbin/pkgchk) failed
with system error code equal to 1.

> I assume the truncation happened before checkpkg gets a hold of the
> package, that's why I suggested a check in mgar or GAR.

checkpkg shouldn't crash either way.

Fix committed in r18664.

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

Just to make sure everyone is aware: pkgchk != checkpkg (sic!)

/usr/sbin/pkgchk: Sun utility from the SUNWpkgcmdsu package. This is the
one you use map from files to packages on a Solaris system (pkgchk -l -p foo)

checkpkg: OpenCSW utility designed to check OpenCSW packages. Lives in
GAR sources.

Maciej

From bonivart at opencsw.org  Sun Jul  8 18:05:46 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 8 Jul 2012 18:05:46 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <20120708155935.GA14220@quince.home.blizinski.pl>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
	<CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
	<CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>
	<CABY0g1VAXzh-uQFwU=SF-nb+tSMBTt=yaofZ73Sq1dP0046pew@mail.gmail.com>
	<20120708155935.GA14220@quince.home.blizinski.pl>
Message-ID: <CABY0g1XkFOA-phUzEzj7A3NiWwHaCH8hNUZfRaU-YzThT1wHsw@mail.gmail.com>

On Sun, Jul 8, 2012 at 5:59 PM, Maciej Blizi?ski <maciej at opencsw.org> wrote:
> On Sun, Jul 08, 2012 at 05:43:50PM +0200, Peter Bonivart wrote:
>> It doesn't blow up now which is good but it still doesn't tell me what's wrong:
>
> How does it not tell you?

I don't think it's obvious how to correct the problem. Not in
datastream == pkgname too long?

>> INFO:root:Juicing the svr4 package stream files...
>> 100% |#########################################################################|
>> INFO:root:Unwrapping candies...
>> 100% |#########################################################################|
>> INFO:root:Tasting candies one by one...
>> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
>> attempt to process datastream failed
>> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:    - package
>> <CSWpm-cgi-session-serialize-yaml> not in datastream
>> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
>> unable to complete package transfer
>> 100% |#########################################################################|
>> INFO:root:Tasting them all at once...
>> INFO:root:Stuffing the candies under the pillow...
>> 100% |#########################################################################|
>> CSWpm-cgi-session-serialize-yaml:
>> If any of the reported errors were false positives, you can override them
>> pasting the lines below to the GAR recipe.
>
> Just read this bit:
>
>> CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml += pkgchk-failed-with-code|1
>> CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml +=
>> pkginfo-opencsw-repository-uncommitted|None
>
> "pkgchk-failed-with-code|1" means that pkgchk (/usr/sbin/pkgchk) failed
> with system error code equal to 1.

Even reading the man page for pkgchk I only get this:

     >0    An error occurred.

>> I assume the truncation happened before checkpkg gets a hold of the
>> package, that's why I suggested a check in mgar or GAR.
>
> checkpkg shouldn't crash either way.
>
> Fix committed in r18664.
>
> http://sourceforge.net/apps/trac/gar/changeset/18664
>
> Just to make sure everyone is aware: pkgchk != checkpkg (sic!)
>
> /usr/sbin/pkgchk: Sun utility from the SUNWpkgcmdsu package. This is the
> one you use map from files to packages on a Solaris system (pkgchk -l -p foo)
>
> checkpkg: OpenCSW utility designed to check OpenCSW packages. Lives in
> GAR sources.

Well, that's why I suggested a check before checkpkg gets executed...

From maciej at opencsw.org  Sun Jul  8 19:01:33 2012
From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=)
Date: Sun, 8 Jul 2012 18:01:33 +0100
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <CABY0g1XkFOA-phUzEzj7A3NiWwHaCH8hNUZfRaU-YzThT1wHsw@mail.gmail.com>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
	<CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
	<CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>
	<CABY0g1VAXzh-uQFwU=SF-nb+tSMBTt=yaofZ73Sq1dP0046pew@mail.gmail.com>
	<20120708155935.GA14220@quince.home.blizinski.pl>
	<CABY0g1XkFOA-phUzEzj7A3NiWwHaCH8hNUZfRaU-YzThT1wHsw@mail.gmail.com>
Message-ID: <20120708170133.GA16174@quince.home.blizinski.pl>

On Sun, Jul 08, 2012 at 06:05:46PM +0200, Peter Bonivart wrote:
> On Sun, Jul 8, 2012 at 5:59 PM, Maciej Blizi?ski <maciej at opencsw.org> wrote:
> > On Sun, Jul 08, 2012 at 05:43:50PM +0200, Peter Bonivart wrote:
> >> It doesn't blow up now which is good but it still doesn't tell me what's wrong:
> >
> > How does it not tell you?
> 
> I don't think it's obvious how to correct the problem. Not in
> datastream == pkgname too long?

We'd need to see what's actually there in the datastream with a too long
package name. If the package is not there, then checkpkg tells the right
thing. Do you have a broken datastream around? Let's look at it.

> >> INFO:root:Juicing the svr4 package stream files...
> >> 100% |#########################################################################|
> >> INFO:root:Unwrapping candies...
> >> 100% |#########################################################################|
> >> INFO:root:Tasting candies one by one...
> >> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
> >> attempt to process datastream failed
> >> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:    - package
> >> <CSWpm-cgi-session-serialize-yaml> not in datastream
> >> WARNING:CSWpm-cgi-session-serialize-yaml-CheckPkgchk:pkgchk: ERROR:
> >> unable to complete package transfer
> >> 100% |#########################################################################|
> >> INFO:root:Tasting them all at once...
> >> INFO:root:Stuffing the candies under the pillow...
> >> 100% |#########################################################################|
> >> CSWpm-cgi-session-serialize-yaml:
> >> If any of the reported errors were false positives, you can override them
> >> pasting the lines below to the GAR recipe.
> >
> > Just read this bit:
> >
> >> CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml += pkgchk-failed-with-code|1
> >> CHECKPKG_OVERRIDES_CSWpm-cgi-session-serialize-yaml +=
> >> pkginfo-opencsw-repository-uncommitted|None
> >
> > "pkgchk-failed-with-code|1" means that pkgchk (/usr/sbin/pkgchk) failed
> > with system error code equal to 1.
> 
> Even reading the man page for pkgchk I only get this:
> 
>      >0    An error occurred.



> >> I assume the truncation happened before checkpkg gets a hold of the
> >> package, that's why I suggested a check in mgar or GAR.
> >
> > checkpkg shouldn't crash either way.
> >
> > Fix committed in r18664.
> >
> > http://sourceforge.net/apps/trac/gar/changeset/18664
> >
> > Just to make sure everyone is aware: pkgchk != checkpkg (sic!)
> >
> > /usr/sbin/pkgchk: Sun utility from the SUNWpkgcmdsu package. This is the
> > one you use map from files to packages on a Solaris system (pkgchk -l -p foo)
> >
> > checkpkg: OpenCSW utility designed to check OpenCSW packages. Lives in
> > GAR sources.
> 
> Well, that's why I suggested a check before checkpkg gets executed...

Yes, that would certainly help. checkpkg can only examine .pkg files.

From bonivart at opencsw.org  Sun Jul  8 19:17:17 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 8 Jul 2012 19:17:17 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <20120708170133.GA16174@quince.home.blizinski.pl>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<1341757408-sup-6598@pinkfloyd.chass.utoronto.ca>
	<CABY0g1XUKn=vX-maZDJLWoRUXJR-B+yFF90H7ko3D_H9vgLScg@mail.gmail.com>
	<CALtRa-6Km7B2SJT0TCCoYE9vGwBH=NGkdKtcYo=kOoOOmZCyNQ@mail.gmail.com>
	<CABY0g1VAXzh-uQFwU=SF-nb+tSMBTt=yaofZ73Sq1dP0046pew@mail.gmail.com>
	<20120708155935.GA14220@quince.home.blizinski.pl>
	<CABY0g1XkFOA-phUzEzj7A3NiWwHaCH8hNUZfRaU-YzThT1wHsw@mail.gmail.com>
	<20120708170133.GA16174@quince.home.blizinski.pl>
Message-ID: <CABY0g1XsAMSLo1x_qG+hFbDVt2SYHgcRZD6XEBVVZ9ia_oL9hg@mail.gmail.com>

On Sun, Jul 8, 2012 at 7:01 PM, Maciej Blizi?ski <maciej at opencsw.org> wrote:
> On Sun, Jul 08, 2012 at 06:05:46PM +0200, Peter Bonivart wrote:
>> On Sun, Jul 8, 2012 at 5:59 PM, Maciej Blizi?ski <maciej at opencsw.org> wrote:
>> > On Sun, Jul 08, 2012 at 05:43:50PM +0200, Peter Bonivart wrote:
>> >> It doesn't blow up now which is good but it still doesn't tell me what's wrong:
>> >
>> > How does it not tell you?
>>
>> I don't think it's obvious how to correct the problem. Not in
>> datastream == pkgname too long?
>
> We'd need to see what's actually there in the datastream with a too long
> package name. If the package is not there, then checkpkg tells the right
> thing. Do you have a broken datastream around? Let's look at it.

I don't see anything obviously wrong with it:

bonivart at login[build.2012-07-08]$ pkgtrans
pm_cgi_session_serialize_yaml-4.26\,REV\=2012.07.08-SunOS5.9-all-UNCOMMITTED.pkg
.

The following packages are available:
  1  CSWpm-cgi-session-serialize-yaml
pm_cgi_session_serialize_yaml - CGI-Session-Serialize-yaml: Serializer
for CGI::Session
                                          (all) 4.26,REV=2012.07.08

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:
Transferring <CSWpm-cgi-session-serialize-yaml> package instance

bonivart at login[build.2012-07-08]$ more CSWpm-cgi-session-serialize-yaml/pkginfo
PKG=CSWpm-cgi-session-serialize-yaml
NAME=pm_cgi_session_serialize_yaml - CGI-Session-Serialize-yaml: Serializer for
CGI::Session
ARCH=all
VERSION=4.26,REV=2012.07.08
CATEGORY=application
VENDOR=http://search.cpan.org/~rsavage/CGI-Session-Serialize-yaml packaged for C
SW by Peter Bonivart
EMAIL=bonivart at opencsw.org
PSTAMP=bonivart at unstable9x-20120708173803
CLASSES=none
HOTLINE=http://www.opencsw.org/bugtrack/
OPENCSW_CATALOGNAME=pm_cgi_session_serialize_yaml
OPENCSW_MODE64=32
OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cpan
/CGI-Session-Serialize-yaml/trunk at UNCOMMITTED
OPENCSW_BUNDLE=CGI-Session-Serialize-yaml
OPENCSW_OS_RELEASE=SunOS5.9
OPENCSW_OS_ARCH=i386
PERL_MODULE_NAME=CGI-Session-Serialize-yaml
WORKDIR_FIRSTMOD=../build-isa-i386

bonivart at login[build.2012-07-08]$ cd CSWpm-cgi-session-serialize-yaml/
bonivart at login[CSWpm-cgi-session-serialize-yaml]$ ls -l
total 11
drwxr-xr-x   2 bonivart csw            6 Jul  8 19:07 install
-rw-r--r--   1 bonivart csw          776 Jul  8 17:38 pkginfo
-rw-r--r--   1 bonivart csw         1329 Jul  8 17:38 pkgmap
drwxr-xr-x   3 bonivart csw            3 Jul  8 19:07 root

bonivart at login[CSWpm-cgi-session-serialize-yaml]$ more
root/opt/csw/share/perl/csw/CGI/Session/Serialize/yaml.pm
package CGI::Session::Serialize::yaml;

use strict;
use CGI::Session::ErrorHandler;
...

So I can pkgtrans it without a problem and all the content seems to be
there, also GAR doesn't seem to have changed anything, the full name
is in pkginfo so maybe it's just some of the pkg tools not being able
to handle it, pkgtrans not being one of them.

From romeotheriault at opencsw.org  Mon Jul  9 08:24:29 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Sun, 08 Jul 2012 20:24:29 -1000
Subject: [csw-maintainers] Use of <stdbool.h> is valid only in a c99
 compilation environment.
In-Reply-To: <20120708142816.GA15609@sebastiankayser.de>
References: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>
	<20120708142816.GA15609@sebastiankayser.de>
Message-ID: <CAHo7ehXvO0v5osQLsWoKVsVWXadY_BokH79+7h+VNgeRcFdtJw@mail.gmail.com>

On Sun, Jul 8, 2012 at 4:28 AM, Sebastian Kayser <skayser at opencsw.org> wrote:
> I am not too familiar with the c99 details, but if changing the flags is
> actually the cure to your problem, here's what I'd do. The error message
> looks like it's emitted by the preprocessor invocation which can be
> tweaked with EXTRA_CPPFLAGS (EXTRA_CFLAGS is passed to the compiler
> only). Using that should already give you better results. You can use
> "mgar modenv" to verify the invocation flags without actually running
> the build.
>
> For how exactly to tweak the flags. Usually there's a good chance that
> other people have already run into a similar problem and have solved it.
> Try searching the existing build recipes for "99", maybe that gives you
> the solution right away.


Thank you Sebastian and Dago both, for your suggestions. I've not had
a chance to look at this again but you've both given me more to look
into. I'll follow up on this thread once I've had some more time to
play with this.

Thanks,
Romeo

From ghenry at opencsw.org  Mon Jul  9 10:12:48 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Mon, 09 Jul 2012 10:12:48 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
Message-ID: <4FFA9280.8020506@opencsw.org>

On 07/07/12 10:07 AM, Peter Bonivart wrote:
> Could you please update the old project page on the wiki? I assume
> most of it is still current but we need to know if there's more
> modules needed that we don't have and if those we have are too old.
>
> http://wiki.opencsw.org/project-koha


hello peter,

i did it and put in red the missing modules on my machine. I'm using the 
perlmodver.pl script to find the missing modules.
Actually, the missing one are:
Module                Installed       CPAN
Authen::CAS::Client           -       0.05 *
Business::ISBN                -       2.05 *
CGI::Session::Driver::memcached          -       0.04 *
CGI::Session::Serialize::yaml          -       4.26 *
DBD::SQLite2                  -       0.33 *
DateTime::Format::ICal          -       0.09 *
Email::Date                   -      1.103 *
Gravatar::URL                 -       1.06 *
HTTP::OAI                     -       3.28 *
Lingua::Stem::Snowball          -      0.952 *
Locale::Currency::Format          -       1.30 *
Locale::PO                    -       0.21 *
MARC::Crosswalk::DublinCore          -       0.02 *
Memoize::Memcached            -       0.03 *
Modern::Perl                  - 1.20120521 *
PDF::API2::Simple             -   1.001004 *
PDF::Table                    -   0.009005 *
Template                      -       2.24 *
Text::CSV::Encoded            -       0.10 *
UNIVERSAL::require            -       0.13 *
XML::SAX::Writer              -       0.53 *

Can i use your CGI::Session::Serialize::yaml freshly created?

thanks in advance,

gerard

From bonivart at opencsw.org  Mon Jul  9 10:38:20 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 9 Jul 2012 10:38:20 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFA9280.8020506@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
Message-ID: <CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>

On Mon, Jul 9, 2012 at 10:12 AM, Gerard Henry <ghenry at opencsw.org> wrote:
> hello peter,
>
> i did it and put in red the missing modules on my machine. I'm using the
> perlmodver.pl script to find the missing modules.
> Actually, the missing one are:

Thanks for updating the page. So we only need some new modules, all
old ones are still OK, no updates needed?

From bonivart at opencsw.org  Mon Jul  9 10:39:50 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 9 Jul 2012 10:39:50 +0200
Subject: [csw-maintainers] Checkpgk error when having too long names
In-Reply-To: <4ff95aed.CWbt8XNHc4zFO2Nk%Joerg.Schilling@fokus.fraunhofer.de>
References: <CABY0g1XXaDoT7SWVGG9H9Tb=nRqRzku2+gdYKDcjMT4Ac49i6w@mail.gmail.com>
	<4ff95aed.CWbt8XNHc4zFO2Nk%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CABY0g1WtHriOiyXRvwsBP-2Vh2+SkMGWpfUXLccVK_2WbRmFcA@mail.gmail.com>

On Sun, Jul 8, 2012 at 12:03 PM, Joerg Schilling
<Joerg.Schilling at fokus.fraunhofer.de> wrote:
> The limit is 32 bytes, I don't remember whether this includes the null byte.

I think it does because I can't use 32 chars, only 31.

From dam at opencsw.org  Mon Jul  9 11:06:41 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 9 Jul 2012 11:06:41 +0200
Subject: [csw-maintainers] Solaris versions on the public build farm
In-Reply-To: <x6ipdzaerg.fsf@opencsw.org>
References: <x6ipdzaerg.fsf@opencsw.org>
Message-ID: <4C91F539-C685-4240-9A31-4827BDB96574@opencsw.org>

Hi Peter,

Am 07.07.2012 um 15:21 schrieb Peter FELECAN:
> I spent some time battling with the build of libxvidcore. The issue was
> quite opaque until I discovered that the linker on the public build farm
> has not the same version as on my private build farm (which is pure
> Solaris 10 U10).
> 
> On the public build farm, the linker is of version 5.10-1.500 when on
> the private build-farm, the verion of the linker is 5.10-1.1505. The
> incriminated difference is the support of long options in the more
> recent linker, particularly --soname as an alias of -h; the long option
> can be found in the GNU linker, -soname variation. This has confused the
> build system as myself. For me the issue is solved but can raise
> confusion for others as many upstream projects, xvid being part of them,
> has patched their build system to support the latest Solaris versions...
> 
> Can we have an assessment of the versions installed in the public build
> farm? Ideally we should have the last versions, isn't it?

Yes, sort of :-) The farm could use some new patches and I also need to shuffle
around some zones as the rpool is getting full. Unfortunately I have quite some
work load at the moment so it may take some days. If you need it desperately
I can apply just the patch manually.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120709/a5581fa0/attachment.p7s>

From ghenry at opencsw.org  Mon Jul  9 11:14:16 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Mon, 09 Jul 2012 11:14:16 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
Message-ID: <4FFAA0E8.4010700@opencsw.org>

On 07/09/12 10:38 AM, Peter Bonivart wrote:
> On Mon, Jul 9, 2012 at 10:12 AM, Gerard Henry<ghenry at opencsw.org>  wrote:
>> hello peter,
>>
>> i did it and put in red the missing modules on my machine. I'm using the
>> perlmodver.pl script to find the missing modules.
>> Actually, the missing one are:
>
> Thanks for updating the page. So we only need some new modules, all
> old ones are still OK, no updates needed?

  i hope, the problem with koha is that it doesn't work actually without 
CGI::Session::Serialize::yaml. After that, i need to do some tests to 
verify evertything is ok.
I forgot that now koha is bundled with a script called 
koha_perl_deps.pl, but strangely, this script gives me two more missing 
packages. The interest is that it show the required modules, in case you 
have few time:

koha at catalogue2:~/koha-3.06.05$ ./koha_perl_deps.pl -m
                                               Installed 
Required          Module is
Module Name                                   Version           Version 
            Required
--------------------------------------------------------------------------------------------
Authen::CAS::Client                           0 *               0.05 
                 Yes
Business::ISBN                                0 *               2.05 
                 Yes
CGI::Session::Driver::memcached               0 *               0.04 
                 No
CGI::Session::Serialize::yaml                 0 *               4.2 
                 Yes
DBD::SQLite2                                  0 *               0.33 
                 No
DateTime::Format::ICal                        0 *               0.09 
                 Yes
Email::Date                                   0 *               1.103 
                 Yes
GD                                            0 *               2.39 
                 No
Graphics::Magick                              0 *               1.3.05 
                 No
Gravatar::URL                                 0 *               1.03 
                 No
HTTP::OAI                                     0 *               3.2 
                 Yes
Lingua::Stem::Snowball                        0 *               0.952 
                 Yes
Locale::Currency::Format                      0 *               1.28 
                 Yes
Locale::PO                                    0 *               0.17 
                 Yes
MARC::Crosswalk::DublinCore                   0 *               0.02 
                 Yes
Memoize::Memcached                            0 *               0.03 
                 No
Modern::Perl                                  0 *               1.03 
                 Yes
PDF::API2::Simple                             0 *               1 
                 Yes
PDF::Table                                    0 *               0.9.3 
                 Yes
Template                                      0 *               2.22 
                 Yes
Text::CSV::Encoded                            0 *               0.09 
                 Yes
UNIVERSAL::require                            0 *               0.13 
                 No
XML::SAX::Writer                              0 *               0.44 
                 Yes

--------------------------------------------------------------------------------------------
Total modules reported: 23                      * Module is missing or 
requires an upgrade.

From bonivart at opencsw.org  Mon Jul  9 11:22:06 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 9 Jul 2012 11:22:06 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFAA0E8.4010700@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
Message-ID: <CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>

On Mon, Jul 9, 2012 at 11:14 AM, Gerard Henry <ghenry at opencsw.org> wrote:
>  i hope, the problem with koha is that it doesn't work actually without
> CGI::Session::Serialize::yaml. After that, i need to do some tests to verify
> evertything is ok.
> I forgot that now koha is bundled with a script called koha_perl_deps.pl,
> but strangely, this script gives me two more missing packages. The interest
> is that it show the required modules, in case you have few time:

Ok, good. I will start putting modules in experimental/koha
(http://buildfarm.opencsw.org/experimental.html#koha). With the
instructions there you can install them on your system.

From ghenry at opencsw.org  Mon Jul  9 12:07:59 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Mon, 09 Jul 2012 12:07:59 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
Message-ID: <4FFAAD7F.2070601@opencsw.org>

On 07/09/12 11:22 AM, Peter Bonivart wrote:
> On Mon, Jul 9, 2012 at 11:14 AM, Gerard Henry<ghenry at opencsw.org>  wrote:
>>   i hope, the problem with koha is that it doesn't work actually without
>> CGI::Session::Serialize::yaml. After that, i need to do some tests to verify
>> evertything is ok.
>> I forgot that now koha is bundled with a script called koha_perl_deps.pl,
>> but strangely, this script gives me two more missing packages. The interest
>> is that it show the required modules, in case you have few time:
>
> Ok, good. I will start putting modules in experimental/koha
> (http://buildfarm.opencsw.org/experimental.html#koha). With the
> instructions there you can install them on your system.

good, the pm_cgi_session_serializ_yaml is ok for me.


From bonivart at opencsw.org  Mon Jul  9 17:09:40 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Mon, 9 Jul 2012 17:09:40 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFAAD7F.2070601@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFAAD7F.2070601@opencsw.org>
Message-ID: <CABY0g1VeNWgcOT+3cNEcUQQH_NWQJC6zPEvnR8jcamGyv4jBww@mail.gmail.com>

I've built some of it and updated the wiki page. Takes time though
since almost everything I want to build needs something we don't yet
have.

From pfelecan at opencsw.org  Mon Jul  9 18:54:52 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 09 Jul 2012 18:54:52 +0200
Subject: [csw-maintainers] Solaris versions on the public build farm
In-Reply-To: <4C91F539-C685-4240-9A31-4827BDB96574@opencsw.org> (Dagobert
	Michelsen's message of "Mon, 9 Jul 2012 11:06:41 +0200")
References: <x6ipdzaerg.fsf@opencsw.org>
	<4C91F539-C685-4240-9A31-4827BDB96574@opencsw.org>
Message-ID: <x6a9z8an8j.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> If you need it desperately I can apply just the patch manually.

There is no rush needed; I found a generic solution to my issue.

Thank you
-- 
Peter

From dam at opencsw.org  Tue Jul 10 13:10:00 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 10 Jul 2012 13:10:00 +0200
Subject: [csw-maintainers] Issue with checkpkg
Message-ID: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>

Hi,

I have an issue with checkpkg:

> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/pkgmap
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/pkginfo
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/root/opt/csw/share/doc/pm_cgi_session_driver_memcached/license
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/root/opt/csw/share/man/man3/CGI::Session::Driver::memcached.3perl
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/root/opt/csw/share/perl/csw/CGI/Session/Driver/memcached.pm
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/install/checkpkg_override
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/install/copyright
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/install/cswpm-meta.yml
> /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac/install/depend
> ## Validating control scripts.
> ## Packaging complete.
> mkp: exec( pkgtrans -s /home/dam/spool.5.9-sparc /tmp/pm_cgi_session_driver_memcached-0.04,REV=2012.07.10-SunOS5.9-all-UNCOMMITTED.pkg CSWpm-cgi-session-driver-memcac )
> Transferring <CSWpm-cgi-session-driver-memcac> package instance
> mkp: exec( pigz -9 -f /tmp/pm_cgi_session_driver_memcached-0.04,REV=2012.07.10-SunOS5.9-all-UNCOMMITTED.pkg )
> mkp: exec( mv /tmp/pm_cgi_session_driver_memcached-0.04,REV=2012.07.10-SunOS5.9-all-UNCOMMITTED.pkg.gz /home/dam/staging/build-10.Jul.2012 )
> mkp: exec( rm -rf /home/dam/spool.5.9-sparc/CSWpm-cgi-session-driver-memcac )
> INFO:root:Juicing the svr4 package stream files...
> 100% |#################################################################################################################################|
> INFO:root:Unwrapping candies...
> 100% |#################################################################################################################################|
> INFO:root:Tasting candies one by one...
> 100% |#################################################################################################################################|
> INFO:root:Tasting them all at once...
> INFO:root:Stuffing the candies under the pillow...
> Traceback (most recent call last):                                                                                                     |
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar//bin/checkpkg", line 197, in <module>
>     main()
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar//bin/checkpkg", line 158, in main
>     exit_code, screen_report, tags_report = check_manager.Run()
>   File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/checkpkg_lib.py", line 824, in Run
>     return super(CheckpkgManager2, self).Run()
>   File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/checkpkg_lib.py", line 252, in Run
>     tag_info=unicode(e.tag_info, "utf-8"),
> TypeError: coercing to Unicode: need string or buffer, NoneType found
> gmake: *** [pkgcheck] Error 2

This looks like an artifact from the previous change to allow utf8. Any ideas?


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120710/13f564f7/attachment.p7s>

From maciej at opencsw.org  Tue Jul 10 13:27:33 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 10 Jul 2012 12:27:33 +0100
Subject: [csw-maintainers] Issue with checkpkg
In-Reply-To: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>
References: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>
Message-ID: <CALtRa-68RUBZnAbb64DkYs9-Fa2W0ghqNJ+hefo5aPAmkmmnOw@mail.gmail.com>

2012/7/10 Dagobert Michelsen <dam at opencsw.org>

> This looks like an artifact from the previous change to allow utf8. Any
> ideas?


Yes, it's a breakage caused by a change intended to fix the other issue.
Something that would work for all cases. We first prepare a variable that
is either unicode or None:

tag_info = e.tag_info
if tag_info is not None:
  tag_info = unicode(tag_info, "utf-8")

And then we store that variable in the database:

(...) tag_info=tag_info)

Dago, I'll let you figure out the details. If the fix works, please commit.

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

From dam at opencsw.org  Tue Jul 10 14:19:24 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 10 Jul 2012 14:19:24 +0200
Subject: [csw-maintainers] Issue with checkpkg
In-Reply-To: <CALtRa-68RUBZnAbb64DkYs9-Fa2W0ghqNJ+hefo5aPAmkmmnOw@mail.gmail.com>
References: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>
	<CALtRa-68RUBZnAbb64DkYs9-Fa2W0ghqNJ+hefo5aPAmkmmnOw@mail.gmail.com>
Message-ID: <ED2FB291-E455-41B7-8645-408D9BDD7641@opencsw.org>

Hi Maciej,

Am 10.07.2012 um 13:27 schrieb Maciej (Matchek) Blizi?ski:
> 2012/7/10 Dagobert Michelsen <dam at opencsw.org>
> This looks like an artifact from the previous change to allow utf8. Any ideas?
> 
> Yes, it's a breakage caused by a change intended to fix the other issue. Something that would work for all cases. We first prepare a variable that is either unicode or None:
> 
> tag_info = e.tag_info
> if tag_info is not None:
>   tag_info = unicode(tag_info, "utf-8")
> 
> And then we store that variable in the database:
> 
> (...) tag_info=tag_info)
> 
> Dago, I'll let you figure out the details. If the fix works, please commit.

Harhar, still trying to make a Python programmer out of me? ;-)
  https://sourceforge.net/apps/trac/gar/changeset/18696


Best regards

  -- Dago


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120710/6e7302d9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120710/6e7302d9/attachment.p7s>

From pfelecan at opencsw.org  Tue Jul 10 14:42:21 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Tue, 10 Jul 2012 14:42:21 +0200 (CEST)
Subject: [csw-maintainers] GAR: when the master site is github or similar
Message-ID: <6f160d86b10f6eaacd4c4ca63099a3b5.squirrel@mail.opencsw.org>

This is the second time that I encounter a project that moved to github
and there is no more an archive containing the distribution; at least this
is what I understand.

How do you manage this situation?

From maciej at opencsw.org  Tue Jul 10 14:53:14 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 10 Jul 2012 13:53:14 +0100
Subject: [csw-maintainers] GAR: when the master site is github or similar
In-Reply-To: <6f160d86b10f6eaacd4c4ca63099a3b5.squirrel@mail.opencsw.org>
References: <6f160d86b10f6eaacd4c4ca63099a3b5.squirrel@mail.opencsw.org>
Message-ID: <CALtRa-6i6Ki5Cwv15tysdbD2+KtzbkGepnRhSApb-RdWqoLrsw@mail.gmail.com>

2012/7/10 <pfelecan at opencsw.org>
>
> This is the second time that I encounter a project that moved to github
> and there is no more an archive containing the distribution; at least this
> is what I understand.
>
> How do you manage this situation?

There was a way to obtain a URL to a tarball with a snapshot of
sources. The file names were rather annoying though.

Maciej

From ghenry at opencsw.org  Tue Jul 10 16:13:29 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Tue, 10 Jul 2012 16:13:29 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
Message-ID: <4FFC3889.8000803@opencsw.org>

On 07/09/12 11:22 AM, Peter Bonivart wrote:
> Ok, good. I will start putting modules in experimental/koha
> (http://buildfarm.opencsw.org/experimental.html#koha). With the
> instructions there you can install them on your system.

hello peter,

i have trouble with
http://buildfarm.opencsw.org/experimental/koha/pm_business_isbn_data-20081208,REV=2012.07.09-SunOS5.9-all-CSW.pkg.gz

the system doesn't see it installed. All others packages are ok:
CSWpm-email-date pm_email_date ok
CSWpm-datetime-format-ical ok
CSWpm-authen-cas-client ok


gerard

From bwalton at opencsw.org  Tue Jul 10 16:15:42 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 10 Jul 2012 10:15:42 -0400
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFC3889.8000803@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFC3889.8000803@opencsw.org>
Message-ID: <1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>

Excerpts from Gerard Henry's message of Tue Jul 10 10:13:29 -0400 2012:

Hi Gerard,

> http://buildfarm.opencsw.org/experimental/koha/pm_business_isbn_data-20081208,REV=2012.07.09-SunOS5.9-all-CSW.pkg.gz
> 
> the system doesn't see it installed. All others packages are ok:
> CSWpm-email-date pm_email_date ok
> CSWpm-datetime-format-ical ok
> CSWpm-authen-cas-client ok

Is this on the buildfarm?  You can request package installation by
sending mail to buildfarm at .  I'll add this one now though.

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 10 16:20:29 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 10 Jul 2012 15:20:29 +0100
Subject: [csw-maintainers] Issue with checkpkg
In-Reply-To: <ED2FB291-E455-41B7-8645-408D9BDD7641@opencsw.org>
References: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>
	<CALtRa-68RUBZnAbb64DkYs9-Fa2W0ghqNJ+hefo5aPAmkmmnOw@mail.gmail.com>
	<ED2FB291-E455-41B7-8645-408D9BDD7641@opencsw.org>
Message-ID: <CALtRa-4nfxDLeq6GU-eXQHWrN4sDYp2LnmUd3DuLz6Y7U+ktTw@mail.gmail.com>

2012/7/10 Dagobert Michelsen <dam at opencsw.org>:
> Dago, I'll let you figure out the details. If the fix works, please commit.
>
> Harhar, still trying to make a Python programmer out of me? ;-)
>   https://sourceforge.net/apps/trac/gar/changeset/18696

Looks like I successfully got my foot in the door! :-)

From ghenry at opencsw.org  Tue Jul 10 16:21:31 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Tue, 10 Jul 2012 16:21:31 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFC3889.8000803@opencsw.org>
	<1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>
Message-ID: <4FFC3A6B.6030705@opencsw.org>

On 07/10/12 04:15 PM, Ben Walton wrote:
> Excerpts from Gerard Henry's message of Tue Jul 10 10:13:29 -0400 2012:
>
> Hi Gerard,
>
>> http://buildfarm.opencsw.org/experimental/koha/pm_business_isbn_data-20081208,REV=2012.07.09-SunOS5.9-all-CSW.pkg.gz
>>
>> the system doesn't see it installed. All others packages are ok:
>> CSWpm-email-date pm_email_date ok
>> CSWpm-datetime-format-ical ok
>> CSWpm-authen-cas-client ok
>
> Is this on the buildfarm?  You can request package installation by
> sending mail to buildfarm at .  I'll add this one now though.
>

ok i'm agree


From ghenry at opencsw.org  Tue Jul 10 17:01:37 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Tue, 10 Jul 2012 17:01:37 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <1341931807-sup-8357@pinkfloyd.chass.utoronto.ca>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFC3889.8000803@opencsw.org>
	<1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>
	<4FFC3A6B.6030705@opencsw.org>
	<1341931807-sup-8357@pinkfloyd.chass.utoronto.ca>
Message-ID: <4FFC43D1.1010409@opencsw.org>

On 07/10/12 04:51 PM, Ben Walton wrote:

>
> It looks like this package isn't pushed to the unstable catalog yet so
> I can't install it for you.  If you push it, I'll install it.  The
> policy is that we don't install anything that isn't in the catalog on
> the unstable* hosts.  (We had problems in the past.)
>
strange, because following the page:
http://buildfarm.opencsw.org/experimental.html#koha

and doing:
pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/koha -i 
<catalogname>

it worked excepted for pm_business_isbn-data

but perhaps it is a misunderstanding with Peter, i notice that
ISBN::Business
and
ISBN::Business::Data
are different modules

it seems that Peter compiled the last one. I need the first one

From bwalton at opencsw.org  Tue Jul 10 17:05:41 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 10 Jul 2012 11:05:41 -0400
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFC43D1.1010409@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFC3889.8000803@opencsw.org>
	<1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>
	<4FFC3A6B.6030705@opencsw.org>
	<1341931807-sup-8357@pinkfloyd.chass.utoronto.ca>
	<4FFC43D1.1010409@opencsw.org>
Message-ID: <1341932647-sup-7979@pinkfloyd.chass.utoronto.ca>

Excerpts from Gerard Henry's message of Tue Jul 10 11:01:37 -0400 2012:

Hi Gerard,

> strange, because following the page:
> http://buildfarm.opencsw.org/experimental.html#koha
> 
> and doing:
> pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/koha -i 
> <catalogname>

These are experimental repositories.  They're not part of the unstable
catalog at this point.  If you place packages into
/home/experimental/foo/ on the buildfarm, there will be a new catalog
for that experimental repo created so you can easily install the
packages.  They're not part of the unstable catalog until someone
csw-upload-pkg's them though.

We use the experimental repos to quickly share test packages (eg: for
a user requested bugfix, etc).

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


From pfelecan at opencsw.org  Tue Jul 10 19:58:28 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 10 Jul 2012 19:58:28 +0200
Subject: [csw-maintainers] GAR: when the master site is github or similar
In-Reply-To: <CALtRa-6i6Ki5Cwv15tysdbD2+KtzbkGepnRhSApb-RdWqoLrsw@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue,
	10 Jul 2012 13:53:14 +0100")
References: <6f160d86b10f6eaacd4c4ca63099a3b5.squirrel@mail.opencsw.org>
	<CALtRa-6i6Ki5Cwv15tysdbD2+KtzbkGepnRhSApb-RdWqoLrsw@mail.gmail.com>
Message-ID: <x6txxf8pmj.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> 2012/7/10 <pfelecan at opencsw.org>
>>
>> This is the second time that I encounter a project that moved to github
>> and there is no more an archive containing the distribution; at least this
>> is what I understand.
>>
>> How do you manage this situation?
>
> There was a way to obtain a URL to a tarball with a snapshot of
> sources. The file names were rather annoying though.

Well, maybe for some very small projects I can put the relevant stuff in
the files directory. What do you think?
-- 
Peter

From bwalton at opencsw.org  Tue Jul 10 20:06:19 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 10 Jul 2012 14:06:19 -0400
Subject: [csw-maintainers] GAR: when the master site is github or similar
In-Reply-To: <x6txxf8pmj.fsf@opencsw.org>
References: <6f160d86b10f6eaacd4c4ca63099a3b5.squirrel@mail.opencsw.org>
	<CALtRa-6i6Ki5Cwv15tysdbD2+KtzbkGepnRhSApb-RdWqoLrsw@mail.gmail.com>
	<x6txxf8pmj.fsf@opencsw.org>
Message-ID: <1341943408-sup-1638@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter FELECAN's message of Tue Jul 10 13:58:28 -0400 2012:

> Well, maybe for some very small projects I can put the relevant stuff in
> the files directory. What do you think?

If you can avoid it, it'd be better in the long run.  Does your github
project have the 'zip' download link?  I just checked one that I keep
an eye on and found:

https://github.com/karelzak/util-linux/zipball/stable/v2.21


That would break down to:

https://github.com/$(GITHUB_USER)/$(GARNAME)/zipball/$(GITHUB_BRANCH)

If you define the GITHUB_* variables in your recipe, GAR could easily
be extended to have something like:

MASTERSITES += $(GITHUB_SITES)

to match SF_MIRRORS, GNU_MIRRORS, etc that do essentially the same
thing albeit with fewer variables in most cases.

We're going to run into this more and more often, I suspect so it
wouldn't hurt to spend the effort.

Thoughts?

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


From bonivart at opencsw.org  Tue Jul 10 21:19:23 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Tue, 10 Jul 2012 21:19:23 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFC43D1.1010409@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFC3889.8000803@opencsw.org>
	<1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>
	<4FFC3A6B.6030705@opencsw.org>
	<1341931807-sup-8357@pinkfloyd.chass.utoronto.ca>
	<4FFC43D1.1010409@opencsw.org>
Message-ID: <CABY0g1V1j5V3qcsNRzxyTuE5mWrTHYLhm5kBkjrUXPKkRas7kQ@mail.gmail.com>

There were dependencies needed for most of the packages needed for Koha. I
don't remember the specifics, I'm in Germany on holiday right now and will
be back late this week. I'll take a look then, there's plenty more modules
needed as well, I'm focusing on the required ones.

/peter

Sorry for top-posting, sending this from my phone, very time consuming to
edit. I appreciate that the gmail app now lets me change sender so I can
send to this list, has not been possible on the go before.

On Tuesday, July 10, 2012, Gerard Henry wrote:

> On 07/10/12 04:51 PM, Ben Walton wrote:
>
>
>> It looks like this package isn't pushed to the unstable catalog yet so
>> I can't install it for you.  If you push it, I'll install it.  The
>> policy is that we don't install anything that isn't in the catalog on
>> the unstable* hosts.  (We had problems in the past.)
>>
>>  strange, because following the page:
> http://buildfarm.opencsw.org/**experimental.html#koha<http://buildfarm.opencsw.org/experimental.html#koha>
>
> and doing:
> pkgutil -t http://buildfarm.opencsw.org/**opencsw/experimental/koha<http://buildfarm.opencsw.org/opencsw/experimental/koha>-i <catalogname>
>
> it worked excepted for pm_business_isbn-data
>
> but perhaps it is a misunderstanding with Peter, i notice that
> ISBN::Business
> and
> ISBN::Business::Data
> are different modules
>
> it seems that Peter compiled the last one. I need the first one
> ______________________________**_________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/**mailman/listinfo/maintainers<https://lists.opencsw.org/mailman/listinfo/maintainers>
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120710/24759336/attachment.html>

From bwalton at opencsw.org  Thu Jul 12 03:27:29 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 11 Jul 2012 21:27:29 -0400
Subject: [csw-maintainers] perl status
Message-ID: <1342056394-sup-859@pinkfloyd.chass.utoronto.ca>


Hi Guys,

Has there been any status change on perl updates now that we've
declared solaris 9 dead?  Will this help with the 64-bit work that was
going on?

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


From yann at pleiades.fr.eu.org  Thu Jul 12 23:54:14 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Thu, 12 Jul 2012 23:54:14 +0200
Subject: [csw-maintainers] Openssl migration: status update for group 1
Message-ID: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>

Hi everybody,

I have again some spare cycles and I want to use them on the openssl
migration so we don't delay indefinitely the release of the group 1.
So here a quick status update:

22 packages are now waiting to be updated or dropped in the group 1, before
we can release the already updated packages.

   - *claws_htmlviewer, claws_mail and libetpan*: I didn't have any
   objection against the removal of these packages, so I will proceed.


   - *boincclient, boinclibs and boincmanager*: Maciej proposed to drop
   these packages, I will ping the maintainer about this but I propose to
   follow this idea unless the maintainer answers or someone else steps up.


   - *gnucash: *Peter, have you been able to made some progress on this
   package ?


   - *libserf0_0 and xmlrpc_c*: Dago noticed that theses packages don't
   have any reverse dependancies, I will remove them unless someone objects.


   - *libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: *Dago, you
   began to work on these libraries. Have you made some progress ? (FYI, I am
   currently trying to continue to work on gnomevfs2).


   - *icecast:* Dago you are the maintainer of this package, do you need
   some help to update it ?


   - *libneon26*: Dago proposed to rebuild or drop as only gstplugins_bad
   depend of this package. Any objection to the removal of gstplugins_bad ?


   - *ooocore:* I had no answer from James, I will ping him again but I
   propose to remove the package from unstable if don't have a quick
   answer. Anyway, the package has not been updated since nearly 3 years.


   - *courier_imap:* juraj, you stepped up to takeover this package. Have
   you made some progress ?


   - *proftpd:* I will directly ping the maintainer and I will try to
   update the existing recipe and I will upload an updated version of the
   package even if the maintainer doesn't answer.


   - *dovecot:* I will directly ping the maintainer to see if he can update
   the package quickly or if he needs some help.


   - *postfix: *as agreed with Juraj, I updated the recipe and compiled the
   package. Juraj can you test and release the package ?


   - *hobbit:* the package has not been updated for 5 years. I propose to
   remove this package from unstable unless someone quickly steps up to
   takeover the package.


   - *libpq:* packages depending on libpq should be recompiled with libpq5.


Thanks in advance for your answers and feedbacks,


Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120712/465ee6ff/attachment.html>

From bwalton at opencsw.org  Fri Jul 13 00:15:58 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 12 Jul 2012 18:15:58 -0400
Subject: [csw-maintainers] Openssl migration: status update for group 1
In-Reply-To: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
References: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
Message-ID: <4182d0c3-eb05-403b-8f01-80c499173769@email.android.com>

Hi Yann,

Your assessments are all sound in my view. Let's get group one out the door asap.

I'll be away until the 20th or I'd step in with some effort too.

Thanks
-Ben

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

Hi everybody,


I have again some spare cycles and I want to use them on the openssl migration so we don't delay indefinitely the release of the group 1.

So here a quick status update:


22 packages are now waiting to be updated or dropped in the group 1, before we can release the already updated packages.

claws_htmlviewer, claws_mail and libetpan: I didn't have any objection against the removal of these packages, so I will proceed.boincclient, boinclibs and boincmanager: Maciej proposed to drop these packages, I will ping the maintainer about this but I propose to follow this idea unless the maintainer answers or someone else steps up.gnucash: Peter, have you been able to made some progress on this package ?libserf0_0 and xmlrpc_c: Dago noticed that theses packages don't have any reverse dependancies, I will remove them unless someone objects.libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: Dago, you began to work on these libraries. Have you made some progress ? (FYI, I am currently trying to continue to work on gnomevfs2). icecast: Dago you are the maintainer of this package, do you need some help to update it ?libneon26: Dago proposed to rebuild or drop as only gstplugins_bad depend of this package. Any objection to the removal of gstplugins_bad ?ooocore: I had no answer from James, I will ping him again but I propose to remove the package from unstable if don't have a quick answer. Anyway, the package has not been updated since nearly 3 years.courier_imap: juraj, you stepped up to takeover this package. Have you made some progress ?proftpd: I will directly ping the maintainer and I will try to update the existing recipe and I will upload an updated version of the package even if the maintainer doesn't answer.dovecot: I will directly ping the maintainer to see if he can update the package quickly or if he needs some help.postfix: as agreed with Juraj, I updated the recipe and compiled the package. Juraj can you test and release the package ?hobbit: the package has not been updated for 5 years. I propose to remove this package from unstable unless someone quickly steps up to takeover the package.libpq: packages depending on libpq should be recompiled with libpq5. 


Thanks in advance for your answers and feedbacks,



Yann





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120712/71719e62/attachment-0001.html>

From yann at pleiades.fr.eu.org  Fri Jul 13 00:34:02 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Fri, 13 Jul 2012 00:34:02 +0200
Subject: [csw-maintainers] Issue with checkpkg
In-Reply-To: <ED2FB291-E455-41B7-8645-408D9BDD7641@opencsw.org>
References: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>
	<CALtRa-68RUBZnAbb64DkYs9-Fa2W0ghqNJ+hefo5aPAmkmmnOw@mail.gmail.com>
	<ED2FB291-E455-41B7-8645-408D9BDD7641@opencsw.org>
Message-ID: <CAF2fwseQAM8h8kS-DRVB7iyTz-Mg_5gh6g96-Pj+JbWWSYctnQ@mail.gmail.com>

Hi,

I am still running into a checkpkg unicode problem while building gnomevfs2:

Traceback (most recent call last):########
                                                                           |
  File "/home/yann/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197, in
<module>
    main()
  File "/home/yann/opencsw/.buildsys/v2/gar//bin/checkpkg", line 158, in
main
    exit_code, screen_report, tags_report = check_manager.Run()
  File "/home/yann/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line
827, in Run
    return super(CheckpkgManager2, self).Run()
  File "/home/yann/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line
250, in Run
    tag_info=unicode(tag_info, "utf-8")
TypeError: decoding Unicode is not supported


It seems tag_info can also already be unicode.

When I use checkpkg on gnomevfs, it fails when processing the following
error:
    CheckpkgTag('CSWgnomevfs2', 'missing-dependency', u'CSWlibsmbclient0')

u'CSWlibsmbclient0' is already unicode, hence the error.

I commited a quick fix to be able to continue to work and to potentially
unblock other maintainers:
http://sourceforge.net/apps/trac/gar/changeset/18716/csw/mgar/gar/v2/lib/python

Maciej could you have a look to tell if there is a better way to fix this ?
Should all tag_info be str instead of unicode ?

Thanks in advance,

Yann


2012/7/10 Dagobert Michelsen <dam at opencsw.org>

> Hi Maciej,
>
> Am 10.07.2012 um 13:27 schrieb Maciej (Matchek) Blizi?ski:
>
> 2012/7/10 Dagobert Michelsen <dam at opencsw.org>
>
>> This looks like an artifact from the previous change to allow utf8. Any
>> ideas?
>
>
> Yes, it's a breakage caused by a change intended to fix the other issue.
> Something that would work for all cases. We first prepare a variable that
> is either unicode or None:
>
> tag_info = e.tag_info
> if tag_info is not None:
>   tag_info = unicode(tag_info, "utf-8")
>
> And then we store that variable in the database:
>
> (...) tag_info=tag_info)
>
> Dago, I'll let you figure out the details. If the fix works, please commit.
>
>
> Harhar, still trying to make a Python programmer out of me? ;-)
>   https://sourceforge.net/apps/trac/gar/changeset/18696
>
>
> Best regards
>
>   -- Dago
>
>
>  --
> "You don't become great by trying to be great, you become great by wanting
> to do something,
> and then doing it so hard that you become great in the process." - xkcd
> #896
>
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/3857fa88/attachment.html>

From maciej at opencsw.org  Fri Jul 13 03:22:36 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 13 Jul 2012 02:22:36 +0100
Subject: [csw-maintainers] Issue with checkpkg
In-Reply-To: <CAF2fwseQAM8h8kS-DRVB7iyTz-Mg_5gh6g96-Pj+JbWWSYctnQ@mail.gmail.com>
References: <32B51EE3-5FBC-4873-9181-EEB393BAE296@opencsw.org>
	<CALtRa-68RUBZnAbb64DkYs9-Fa2W0ghqNJ+hefo5aPAmkmmnOw@mail.gmail.com>
	<ED2FB291-E455-41B7-8645-408D9BDD7641@opencsw.org>
	<CAF2fwseQAM8h8kS-DRVB7iyTz-Mg_5gh6g96-Pj+JbWWSYctnQ@mail.gmail.com>
Message-ID: <CALtRa-4H_sYKYULjzEjjTs8HTsHSEznRUYLspi3rCZw1313zag@mail.gmail.com>

2012/7/12 Yann Rouillard <yann at pleiades.fr.eu.org>:
> Hi,
>
> I am still running into a checkpkg unicode problem while building gnomevfs2:
>
> Traceback (most recent call last):########
> |
>   File "/home/yann/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197, in
> <module>
>     main()
>   File "/home/yann/opencsw/.buildsys/v2/gar//bin/checkpkg", line 158, in
> main
>     exit_code, screen_report, tags_report = check_manager.Run()
>   File "/home/yann/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line
> 827, in Run
>     return super(CheckpkgManager2, self).Run()
>   File "/home/yann/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line
> 250, in Run
>     tag_info=unicode(tag_info, "utf-8")
> TypeError: decoding Unicode is not supported
>
>
> It seems tag_info can also already be unicode.
>
> When I use checkpkg on gnomevfs, it fails when processing the following
> error:
>     CheckpkgTag('CSWgnomevfs2', 'missing-dependency', u'CSWlibsmbclient0')
>
> u'CSWlibsmbclient0' is already unicode, hence the error.
>
> I commited a quick fix to be able to continue to work and to potentially
> unblock other maintainers:
> http://sourceforge.net/apps/trac/gar/changeset/18716/csw/mgar/gar/v2/lib/python

Thanks for the fix!

> Maciej could you have a look to tell if there is a better way to fix this ?
> Should all tag_info be str instead of unicode ?

I'm not aware of a better way.

Fields in the database are stored in unicode, so if yo u pass it a
str, it'll try to decode it using the ascii codec, and will fail if
there are any extended characters.

Maciej

From dam at opencsw.org  Fri Jul 13 11:07:14 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 13 Jul 2012 11:07:14 +0200
Subject: [csw-maintainers] Openssl migration: status update for group 1
In-Reply-To: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
References: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
Message-ID: <B9CA98E3-80AD-45DD-A7E5-A24BAE911E18@opencsw.org>

Hi Yann,

Am 12.07.2012 um 23:54 schrieb Yann Rouillard:
> I have again some spare cycles and I want to use them on the openssl migration so we don't delay indefinitely the release of the group 1.
> So here a quick status update:
> 
> 22 packages are now waiting to be updated or dropped in the group 1, before we can release the already updated packages.
> claws_htmlviewer, claws_mail and libetpan: I didn't have any objection against the removal of these packages, so I will proceed.
> boincclient, boinclibs and boincmanager: Maciej proposed to drop these packages, I will ping the maintainer about this but I propose to follow this idea unless the maintainer answers or someone else steps up.
> gnucash: Peter, have you been able to made some progress on this package ?
> libserf0_0 and xmlrpc_c: Dago noticed that theses packages don't have any reverse dependancies, I will remove them unless someone objects.
> libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: Dago, you began to work on these libraries. Have you made some progress ? (FYI, I am currently trying to continue to work on gnomevfs2).

Not yet, and I will also be away until end of next week :-(
> icecast: Dago you are the maintainer of this package, do you need some help to update it ?

I have reworked it, but I wanted to fix all open bugs at the same time. I could release
a version right now, but the SMF manifest is still missing.

> libneon26: Dago proposed to rebuild or drop as only gstplugins_bad depend of this package. Any objection to the removal of gstplugins_bad ?

The problem is that neon_stub (CSWneon) depends on libneon26 and lots of packages still depend on CSWneon, so this requires
a rebuild of neon dropping foreign dependency to libneon26. Catalog integrity as a whole should be taken a close look when
dropping packages. I think package chains like this are currently not looked by default.

> ooocore: I had no answer from James, I will ping him again but I propose to remove the package from unstable if don't have a quick answer. Anyway, the package has not been updated since nearly 3 years.
> courier_imap: juraj, you stepped up to takeover this package. Have you made some progress ?
> proftpd: I will directly ping the maintainer and I will try to update the existing recipe and I will upload an updated version of the package even if the maintainer doesn't answer.
> dovecot: I will directly ping the maintainer to see if he can update the package quickly or if he needs some help.
> postfix: as agreed with Juraj, I updated the recipe and compiled the package. Juraj can you test and release the package ?
> hobbit: the package has not been updated for 5 years. I propose to remove this package from unstable unless someone quickly steps up to takeover the package.

IIRC J?rgen wanted to take a look at this.

> libpq: packages depending on libpq should be recompiled with libpq5. 
This affects the following packages:

aide	Advanced Intrusion Detection Environment
courier_auth	Generic authentication API for Courier mail services
dovecot	Secure IMAP server
php5_pdopgsql	The pdopgsql extention for PHP5
php5_pgsql	The pgsql extention for PHP5
pm_dbdpg

I think most of them are already rebuild.


Best regards

  -- Dago
> 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/aabbb9d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/aabbb9d4/attachment-0001.p7s>

From pfelecan at opencsw.org  Fri Jul 13 11:41:38 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Fri, 13 Jul 2012 11:41:38 +0200 (CEST)
Subject: [csw-maintainers] netpbm: development package issues
Message-ID: <091be328f62991753b8c75ba09f877e1.squirrel@mail.opencsw.org>

Raising again this issue:
- the inclusion of the generic .so was made 8 days ago
- the package wasn't uploaded
- the package is not installed on the build farm
Can somebody with su power solve this? I have 4 packages waiting for this...

TIA


From bwalton at opencsw.org  Fri Jul 13 13:29:24 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Fri, 13 Jul 2012 07:29:24 -0400
Subject: [csw-maintainers] away until the 23rd
Message-ID: <1342178660-sup-6414@pinkfloyd.chass.utoronto.ca>


Hi All,

I won't be available for any buildfarm requests until the 23rd as I'll
be away at a cottage.

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


From dam at opencsw.org  Fri Jul 13 16:56:37 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 13 Jul 2012 16:56:37 +0200
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <091be328f62991753b8c75ba09f877e1.squirrel@mail.opencsw.org>
References: <091be328f62991753b8c75ba09f877e1.squirrel@mail.opencsw.org>
Message-ID: <273728AE-A388-4067-9503-E49376B5AB47@opencsw.org>

Hi Peter,

Am 13.07.2012 um 11:41 schrieb pfelecan at opencsw.org:
> Raising again this issue:
> - the inclusion of the generic .so was made 8 days ago
> - the package wasn't uploaded
> - the package is not installed on the build farm
> Can somebody with su power solve this? I have 4 packages waiting for this...


Sorry, I got distracted, thanks for pinging again. I have rebuild and
pushed the package now and replaced the version on the build farm.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/7d4aa591/attachment.p7s>

From pfelecan at opencsw.org  Fri Jul 13 19:55:40 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 13 Jul 2012 19:55:40 +0200
Subject: [csw-maintainers] netpbm: development package issues
In-Reply-To: <273728AE-A388-4067-9503-E49376B5AB47@opencsw.org> (Dagobert
	Michelsen's message of "Fri, 13 Jul 2012 16:56:37 +0200")
References: <091be328f62991753b8c75ba09f877e1.squirrel@mail.opencsw.org>
	<273728AE-A388-4067-9503-E49376B5AB47@opencsw.org>
Message-ID: <x6ehof8s0z.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> I have rebuild and pushed the package now and replaced the version on
> the build farm.

Thank you
-- 
Peter

From yann at pleiades.fr.eu.org  Fri Jul 13 23:19:31 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Fri, 13 Jul 2012 23:19:31 +0200
Subject: [csw-maintainers] Openssl migration: status update for group 1
In-Reply-To: <B9CA98E3-80AD-45DD-A7E5-A24BAE911E18@opencsw.org>
References: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
	<B9CA98E3-80AD-45DD-A7E5-A24BAE911E18@opencsw.org>
Message-ID: <CAF2fwsfE-X0eOUZUXvMsEN0W_LuaSVQOLwsQsm_6GmvD6UVzCQ@mail.gmail.com>

Hi Dago,

2012/7/13 Dagobert Michelsen <dam at opencsw.org>
>
>
>    - *libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: *Dago, you
>    began to work on these libraries. Have you made some progress ? (FYI, I am
>    currently trying to continue to work on gnomevfs2).
>
>
> Not yet, and I will also be away until end of next week :-(
>

Did you have some compilation problems on the first three packages ? I can
help so we can make some progress while you are away.



>
>    - *icecast:* Dago you are the maintainer of this package, do you need
>    some help to update it ?
>
>
> I have reworked it, but I wanted to fix all open bugs at the same time. I
> could release
> a version right now, but the SMF manifest is still missing.
>

If it was already missing before, it would be better to release now this
new version linked with openssl 1.0.


>
>
>    - *libneon26*: Dago proposed to rebuild or drop as only gstplugins_bad
>    depend of this package. Any objection to the removal of gstplugins_bad ?
>
>
> The problem is that neon_stub (CSWneon) depends on libneon26 and lots of
> packages still depend on CSWneon, so this requires
> a rebuild of neon dropping foreign dependency to libneon26. Catalog
> integrity as a whole should be taken a close look when
> dropping packages. I think package chains like this are currently not
> looked by default.
>

According to the webpage, the reverse dependancies of libneon26 are
only: gstplugins_bad, ooocore and pysvn.
Are there other reverse dependancies not shown ?

Maciej, you are the maintainer of pysvn. Could you rebuild it again
libneon27 ?


>
>    - *hobbit:* the package has not been updated for 5 years. I propose to
>    remove this package from unstable unless someone quickly steps up to
>    takeover the package.
>
>
> IIRC J?rgen wanted to take a look at this.
>
>
>    - *libpq:* packages depending on libpq should be recompiled with
>    libpq5.
>
> This affects the following packages:
>
> aide <http://www.opencsw.org/packages/aide>Advanced Intrusion Detection
> Environmentcourier_auth <http://www.opencsw.org/packages/courier_auth>Generic
> authentication API for Courier mail servicesdovecot<http://www.opencsw.org/packages/dovecot>Secure
> IMAP serverphp5_pdopgsql <http://www.opencsw.org/packages/php5_pdopgsql>The
> pdopgsql extention for PHP5php5_pgsql<http://www.opencsw.org/packages/php5_pgsql>The
> pgsql extention for PHP5pm_dbdpg<http://www.opencsw.org/packages/pm_dbdpg>
>
> I think most of them are already rebuild.
>

I just checked and courier_auth, dovecot and pm_dbdpg still have to be
rebuilt.

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/7d0ca199/attachment-0001.html>

From yann at pleiades.fr.eu.org  Fri Jul 13 23:25:17 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Fri, 13 Jul 2012 23:25:17 +0200
Subject: [csw-maintainers] Experimental gnomevfs2 packages
Message-ID: <CAF2fwsdUg3hHvjvG5D2g2GeE59EzHCuXUh4L14igTDXxEFh+9Q@mail.gmail.com>

Hi,

I just put updated gnomevfs2 packages in my experimental repository.
I had some problem with the test checks after the compilation phase and I
don't have a working desktop setup to check if there is really a problem
with this package.

Could you someone try to install the gnomevfs2 package  and check if it
work correctly ?
pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i
gnomevfs2

The packages using gnomevfs2 are gvim, gthumb, grip, gnucash.
I suppose you would have to check if local and remote file access.

Thanks in advance for any help,

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/412a42b6/attachment.html>

From dam at opencsw.org  Fri Jul 13 23:26:07 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 13 Jul 2012 23:26:07 +0200
Subject: [csw-maintainers] Openssl migration: status update for group 1
In-Reply-To: <CAF2fwsfE-X0eOUZUXvMsEN0W_LuaSVQOLwsQsm_6GmvD6UVzCQ@mail.gmail.com>
References: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
	<B9CA98E3-80AD-45DD-A7E5-A24BAE911E18@opencsw.org>
	<CAF2fwsfE-X0eOUZUXvMsEN0W_LuaSVQOLwsQsm_6GmvD6UVzCQ@mail.gmail.com>
Message-ID: <CF5A1747-F98E-4BAC-845C-D7FF36977D0A@opencsw.org>

Hi Yann,

Am 13.07.2012 um 23:19 schrieb Yann Rouillard:
> 2012/7/13 Dagobert Michelsen <dam at opencsw.org>
>> libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: Dago, you began to work on these libraries. Have you made some progress ? (FYI, I am currently trying to continue to work on gnomevfs2).
> 
> Not yet, and I will also be away until end of next week :-(
> 
> Did you have some compilation problems on the first three packages ? I can help so we can make some progress while you are away.

Please do, I have everything committed.
>> icecast: Dago you are the maintainer of this package, do you need some help to update it ?
> 
> I have reworked it, but I wanted to fix all open bugs at the same time. I could release
> a version right now, but the SMF manifest is still missing.
> 
> If it was already missing before, it would be better to release now this new version linked with openssl 1.0.

Ok, it only needs a respin, running now.

>> libneon26: Dago proposed to rebuild or drop as only gstplugins_bad depend of this package. Any objection to the removal of gstplugins_bad ?
> 
> The problem is that neon_stub (CSWneon) depends on libneon26 and lots of packages still depend on CSWneon, so this requires
> a rebuild of neon dropping foreign dependency to libneon26. Catalog integrity as a whole should be taken a close look when
> dropping packages. I think package chains like this are currently not looked by default.
> 
> According to the webpage, the reverse dependancies of libneon26 are only: gstplugins_bad, ooocore and pysvn. 
> Are there other reverse dependancies not shown ?

*Scratches head* I don't think so, but I thought it were more. I don't see a reason now,
so I suggest to just proceed dropping.

> Maciej, you are the maintainer of pysvn. Could you rebuild it again libneon27 ?
>  
>> hobbit: the package has not been updated for 5 years. I propose to remove this package from unstable unless someone quickly steps up to takeover the package.
> 
> IIRC J?rgen wanted to take a look at this.
> 
>> libpq: packages depending on libpq should be recompiled with libpq5. 
> 
> This affects the following packages:
> 
> aide	 Advanced Intrusion Detection Environment
> courier_auth	 Generic authentication API for Courier mail services
> dovecot	 Secure IMAP server
> php5_pdopgsql	 The pdopgsql extention for PHP5
> php5_pgsql	 The pgsql extention for PHP5
> pm_dbdpg
> 
> I think most of them are already rebuild.
> 
> I just checked and courier_auth, dovecot and pm_dbdpg still have to be rebuilt.

Ok.

Best regards

  -- Dago


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/04fa5098/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120713/04fa5098/attachment-0001.p7s>

From pfelecan at opencsw.org  Sat Jul 14 15:33:50 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 14 Jul 2012 15:33:50 +0200
Subject: [csw-maintainers] Openssl migration: status update for group 1
In-Reply-To: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
	(Yann Rouillard's message of "Thu, 12 Jul 2012 23:54:14 +0200")
References: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
Message-ID: <x6a9z28o1t.fsf@opencsw.org>

Yann Rouillard <yann at pleiades.fr.eu.org> writes:

>    - *gnucash: *Peter, have you been able to made some progress on this
>    package ?

Yes: slowly progressing on dependencies; maybe next wee I can start a
first tentative. I let you know.
-- 
Peter

From pfelecan at opencsw.org  Sat Jul 14 15:38:12 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 14 Jul 2012 15:38:12 +0200
Subject: [csw-maintainers] Experimental gnomevfs2 packages
In-Reply-To: <CAF2fwsdUg3hHvjvG5D2g2GeE59EzHCuXUh4L14igTDXxEFh+9Q@mail.gmail.com>
	(Yann Rouillard's message of "Fri, 13 Jul 2012 23:25:17 +0200")
References: <CAF2fwsdUg3hHvjvG5D2g2GeE59EzHCuXUh4L14igTDXxEFh+9Q@mail.gmail.com>
Message-ID: <x6629q8nuj.fsf@opencsw.org>

Yann Rouillard <yann at pleiades.fr.eu.org> writes:

> The packages using gnomevfs2 are gvim, gthumb, grip, gnucash.

grip: ok
gnucash: to be determined later.

-- 
Peter

From bonivart at opencsw.org  Sun Jul 15 16:57:00 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Sun, 15 Jul 2012 16:57:00 +0200
Subject: [csw-maintainers] need help for CGI::Session::serialize::yaml
In-Reply-To: <4FFC43D1.1010409@opencsw.org>
References: <4FF6FA1E.3000303@opencsw.org>
	<1341586074-sup-3370@pinkfloyd.chass.utoronto.ca>
	<4FF6FC19.5020708@opencsw.org>
	<6045deafa2a2819457ad2522f018e5f0.squirrel@mail.opencsw.org>
	<4FF7041B.1000808@opencsw.org>
	<895C2308-1917-4BA1-92B0-C1770E5AB60A@opencsw.org>
	<4FF7E604.6050204@opencsw.org>
	<CABY0g1V8YkH83L_OVEfvLBG5FvvqM1YjX1d0AkpEWWb3YGkuCw@mail.gmail.com>
	<4FF7ED97.5010908@opencsw.org>
	<CABY0g1VQFB-TrqmGNu9E+APO+vH2cKbXPTG2jTnN-xTX+1Qbjg@mail.gmail.com>
	<4FFA9280.8020506@opencsw.org>
	<CABY0g1UMF=_HQh-mK32U=tbLvPR3+at5desoOofax8dx5CM2nw@mail.gmail.com>
	<4FFAA0E8.4010700@opencsw.org>
	<CABY0g1VOFz_92x18i9qyOE+SomDK2ZkW8H7YdDZaTpyTeYa3-g@mail.gmail.com>
	<4FFC3889.8000803@opencsw.org>
	<1341929696-sup-3235@pinkfloyd.chass.utoronto.ca>
	<4FFC3A6B.6030705@opencsw.org>
	<1341931807-sup-8357@pinkfloyd.chass.utoronto.ca>
	<4FFC43D1.1010409@opencsw.org>
Message-ID: <CABY0g1VWTFwN4Cg4QAd9kDzHy00jJd+AczP1+PKC4=uDVRwHXg@mail.gmail.com>

On Tue, Jul 10, 2012 at 5:01 PM, Gerard Henry <ghenry at opencsw.org> wrote:
> strange, because following the page:
> http://buildfarm.opencsw.org/experimental.html#koha
>
> and doing:
> pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/koha -i
> <catalogname>
>
> it worked excepted for pm_business_isbn-data
>
> but perhaps it is a misunderstanding with Peter, i notice that
> ISBN::Business
> and
> ISBN::Business::Data
> are different modules
>
> it seems that Peter compiled the last one. I need the first one

I built both. ISBN::Business::Data is a dependency of ISBN::Business
so if you want the latter you do:

# pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/koha -i
pm_business_isbn

It will install both for you, I just tried it and it worked without
problem, if you have problems please state exactly what you did.

I have also made an empty koha package to pull in all dependencies
needed so you can experiment with Koha yourself on your local machine.
But the deps aren't right because it's based on two year old info when
we tried this the last time. I will fix that so it's easier to get all
deps in one go.

Anyway, I have built a few more deps needed and filed upgrade bugs on
two packages maintained by Dago. It's not that much left now, looks
like eight modules plus probably a few deps for those as usual.

/peter

From dam at opencsw.org  Sun Jul 15 22:04:32 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 15 Jul 2012 22:04:32 +0200
Subject: [csw-maintainers] Openssl migration: status update for group 1
In-Reply-To: <CAF2fwscnjcniC3Oe=NEO+g6AXcT3PrXixos==J245=BFRm6MKw@mail.gmail.com>
References: <CAF2fwsd=B0styi8ONL4ya5Bd_FrU728U=huQ2MY-mUh-C6JFjA@mail.gmail.com>
	<B9CA98E3-80AD-45DD-A7E5-A24BAE911E18@opencsw.org>
	<CAF2fwsfE-X0eOUZUXvMsEN0W_LuaSVQOLwsQsm_6GmvD6UVzCQ@mail.gmail.com>
	<CF5A1747-F98E-4BAC-845C-D7FF36977D0A@opencsw.org>
	<CAF2fwscnjcniC3Oe=NEO+g6AXcT3PrXixos==J245=BFRm6MKw@mail.gmail.com>
Message-ID: <4C2076B4-2C06-46AA-A461-327BB177ED44@opencsw.org>

Hi,

Am 14.07.2012 um 23:58 schrieb Yann Rouillard:
>> According to the webpage, the reverse dependancies of libneon26 are only: gstplugins_bad, ooocore and pysvn. 
>> Are there other reverse dependancies not shown ?
> 
> *Scratches head* I don't think so, but I thought it were more. I don't see a reason now,
> so I suggest to just proceed dropping.

FYI: I just dropped ooocommon and ooocore (the last two remaining OpenOffice packages) from unstable.

Additionally, I dropped the then-obsolete libicu42 and libicu.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120715/312ed175/attachment.p7s>

From romeotheriault at opencsw.org  Mon Jul 16 02:36:42 2012
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Sun, 15 Jul 2012 14:36:42 -1000
Subject: [csw-maintainers] Use of <stdbool.h> is valid only in a c99
 compilation environment.
In-Reply-To: <CAHo7ehXvO0v5osQLsWoKVsVWXadY_BokH79+7h+VNgeRcFdtJw@mail.gmail.com>
References: <CAHo7ehWU==ynLaUphggj3SP_iWV7Cg3hhaJQB2azuy=aAq29Xg@mail.gmail.com>
	<20120708142816.GA15609@sebastiankayser.de>
	<CAHo7ehXvO0v5osQLsWoKVsVWXadY_BokH79+7h+VNgeRcFdtJw@mail.gmail.com>
Message-ID: <CAHo7ehXSNUoS9Qjpz9kZO3TWeKeFJthVBf3fKP37gV4W6oRj=g@mail.gmail.com>

On Sun, Jul 8, 2012 at 8:24 PM, Romeo Theriault
<romeotheriault at opencsw.org> wrote:
>
> On Sun, Jul 8, 2012 at 4:28 AM, Sebastian Kayser <skayser at opencsw.org> wrote:
> > I am not too familiar with the c99 details, but if changing the flags is
> > actually the cure to your problem, here's what I'd do. The error message
> > looks like it's emitted by the preprocessor invocation which can be
> > tweaked with EXTRA_CPPFLAGS (EXTRA_CFLAGS is passed to the compiler
> > only). Using that should already give you better results. You can use
> > "mgar modenv" to verify the invocation flags without actually running
> > the build.
> >
> > For how exactly to tweak the flags. Usually there's a good chance that
> > other people have already run into a similar problem and have solved it.
> > Try searching the existing build recipes for "99", maybe that gives you
> > the solution right away.
>
> Thank you Sebastian and Dago both, for your suggestions. I've not had
> a chance to look at this again but you've both given me more to look
> into. I'll follow up on this thread once I've had some more time to
> play with this.


Thought I'd follow up on this. I'm unfortunately still unable to
figure out how to get msgpack-python to compile with SunStudio cc. I
asked this here [1] and got some suggestions that got me a bit further
(I think) but am still unable to fully compile the software.
Basically, I'm able to get past the stdbool.h error by using these
EXTRA_CPPFLAGS += -D_XPG6 -xc99 but now seem to be running into other
errors that to my junior eye seems to be related to some C standard
compatibility.

Errors like so:

"msgpack/unpack_template.h", line 205: "default" outside switch
"msgpack/unpack_template.h", line 207: undefined label: _fixed_trail_again

I've grepped through the Makefiles of the other opencsw packages for
other tips and have tried a bunch with no more luck. If anyone else
has any suggestions I'm all ears.

If I really can't get msgpack-python to compile with cc I think I've
figured out how I can get it to compile with gcc, but one thing I'm
worried about is using a gcc compiled python module with a cc compiled
python (and any other programs that may try to use it and were
compiled with cc). Does anyone know if this is likely to cause any
problems? Or should this be fine? Linking problems?

Again, any insight in this area is greatly appreciated.

Thank you,

[1] http://stackoverflow.com/questions/11462527/building-msgpack-python-on-solaris-10-use-of-stdbool-h-is-valid-only-in-a-c9

Romeo

From yann at pleiades.fr.eu.org  Mon Jul 16 23:40:44 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 16 Jul 2012 23:40:44 +0200
Subject: [csw-maintainers] OpenSSL project task order
In-Reply-To: <A0C2374E-52ED-4E00-BE89-722C273DEBF8@opencsw.org>
References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org>
	<CAF2fwscDyzE91PA61KMq-8gE+n1oKYOzhhnMbhuCQvrEUFjsDg@mail.gmail.com>
	<A0C2374E-52ED-4E00-BE89-722C273DEBF8@opencsw.org>
Message-ID: <CAF2fwsePrcOoRp=-R88T9vZ08yZERFV7MNNh3kj=iiy47PZczg@mail.gmail.com>

Hi Dago,

2012/6/20 Dagobert Michelsen <dam at opencsw.org>

> Hi Yann,
>
> [...]
>
>
> > As said before, it would be helpful to know when the dual runtime
> linking is really a problem, this would maybe help to significantly
> simplify the coordination work.
> >
> > Does someone know what happens exactly when a program is linked with two
> different libraries at runtime by the way of one of its dependancy ?
>
> The worst thing would be having two sets of global variables saving state
> for the different
> versions.
>
>
I made some checks and it seems it is worse than that. When both openssl
0.9.8 and openssl 1.0.0 are linked at runtime, only one of the two
libraries will be really used (if exported symbols are the same in both
versions).

I did: LD_DEBUG=all  LD_BIND_NOW=1 /opt/csw/bin/cadaver
after having reinstalled the libneon27 linked with openssl 0.9.8.

The result is that every symbol is linked with openssl 1.0.0 even for neon
that was linked against openssl 0.9.8 at compile time:
01278: binding file=/opt/csw/lib/i386/libneon.so.27 to
file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_pending'
01278: binding file=/opt/csw/lib/i386/libneon.so.27 to
file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_get_error'
01278: binding file=/opt/csw/lib/i386/libneon.so.27 to
file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_read'
[...]

even libssl0.9.8 is linked against libcrypto.so.1.0.0:
binding file=/opt/csw/lib/pentium_pro/libssl.so.0.9.8 to
file=/opt/csw/lib/i386/libcrypto.so.1.0.0: symbol 'EVP_sha224'
[...]

It means that we are lucky that every packages dual linked with ssl0.9.8
and ssl1.0.0 already uploaded to unstable works. I suppose it just works
because openssl 1.0.0 and 0.9.8 are ABI compatibles enough so that it works
in most cases.


I suppose one possible solution to this problem would be to use versioned
symbols. This was already mentioned in a previous thread I think. Does
someone have some insights about the pros and cons of versioned symbols ?
Of course this would imply a new painful transition for openssl...


BTW, I also noticed that cadaver was directly linked with openssl 1.0.0
although it doesn't use any symbols from the ssl library. I will check
exactly why but I suppose if would be an interesting additional check for
checkpkg. Has anyone already looked in that problem ?


Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120716/a03cc91a/attachment-0001.html>

From maciej at opencsw.org  Tue Jul 17 12:13:49 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 17 Jul 2012 11:13:49 +0100
Subject: [csw-maintainers] The --remove option is now gone from
	csw-upload-pkg
Message-ID: <CALtRa-5ihDn5snVATtzTrYssEwdCXncR2Rpo=tHocrLsB8Ui9g@mail.gmail.com>

The --remove option for csw-upload-pkg was unintuitive and dangerous,
so I removed it. For package removals, there is now a separate utility
which can do it safely, checking for reverse dependencies. Hat tip to
Carsten who has laid down the foundation code for it.

For most practical purposes, maintainers do not need to perform
package removals. To avoid file collisions between old and new
packages, it's enough to create an empty package and upload it.

Maciej

From pfelecan at opencsw.org  Tue Jul 17 19:02:58 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 17 Jul 2012 19:02:58 +0200
Subject: [csw-maintainers] The --remove option is now gone from
	csw-upload-pkg
In-Reply-To: <CALtRa-5ihDn5snVATtzTrYssEwdCXncR2Rpo=tHocrLsB8Ui9g@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue,
	17 Jul 2012 11:13:49 +0100")
References: <CALtRa-5ihDn5snVATtzTrYssEwdCXncR2Rpo=tHocrLsB8Ui9g@mail.gmail.com>
Message-ID: <x6wr222ud9.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> For package removals, there is now a separate utility
> which can do it safely, checking for reverse dependencies.

And which is the name of that fabulous utility?
-- 
Peter

From maciej at opencsw.org  Tue Jul 17 19:25:17 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 17 Jul 2012 18:25:17 +0100
Subject: [csw-maintainers] The --remove option is now gone from
	csw-upload-pkg
In-Reply-To: <x6wr222ud9.fsf@opencsw.org>
References: <CALtRa-5ihDn5snVATtzTrYssEwdCXncR2Rpo=tHocrLsB8Ui9g@mail.gmail.com>
	<x6wr222ud9.fsf@opencsw.org>
Message-ID: <CALtRa-7i6_O9YH8_naXz+Yat9Cg-NQjdapSikfEXJxVc8Yj_cw@mail.gmail.com>

2012/7/17 Peter FELECAN <pfelecan at opencsw.org>:
> "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:
>
>> For package removals, there is now a separate utility
>> which can do it safely, checking for reverse dependencies.
>
> And which is the name of that fabulous utility?

?Safe remove package?.

http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/safe_remove_package.py

From ghenry at opencsw.org  Wed Jul 18 15:45:47 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Wed, 18 Jul 2012 15:45:47 +0200
Subject: [csw-maintainers] perl modules for  koha
Message-ID: <5006BE0B.5040301@opencsw.org>

hello all,

i opened a new thread that continues the precedent one:
http://lists.opencsw.org/pipermail/maintainers/2012-July/016977.html

on the wiki page:
http://wiki.opencsw.org/project-koha
there is Koha 4.10.05, is it a typo? actually koh is 3.x, the latest 
release is 3.8.2:
http://download.koha-community.org/

trying to do the install with all the opencsw packages, i got:
Warning: prerequisite CGI::Session::Driver::memcached 0.04 not found.
Warning: prerequisite DBD::SQLite2 0.33 not found.
Warning: prerequisite DateTime::Event::ICal 0.08 not found.
Warning: prerequisite DateTime::Format::DateParse 0.04 not found.
Warning: prerequisite DateTime::Set 0.28 not found.
Warning: prerequisite Graphics::Magick 1.3.05 not found.
Warning: prerequisite Gravatar::URL 1.03 not found.
Warning: prerequisite HTTP::OAI 3.2 not found.
Warning: prerequisite Lingua::Stem::Snowball 0.952 not found.
Warning: prerequisite Locale::Currency::Format 1.28 not found.
Warning: prerequisite Locale::PO 0.17 not found.
Warning: prerequisite MARC::Crosswalk::DublinCore 0.02 not found.
Warning: prerequisite Memoize::Memcached 0.03 not found.
Warning: prerequisite Modern::Perl 1.03 not found.
Warning: prerequisite PDF::API2::Simple 1 not found.
Warning: prerequisite PDF::Table 0.9.3 not found.
Warning: prerequisite Readonly 1.03 not found.
Warning: prerequisite Readonly::XS 1.02 not found.
Warning: prerequisite Template 2.22 not found.
Warning: prerequisite Template::Plugin::HtmlToText 0.03 not found.
Warning: prerequisite Text::CSV::Encoded 0.09 not found.
Warning: prerequisite UNIVERSAL::require 0.13 not found.
Warning: prerequisite XML::SAX::Writer 0.44 not found.

that's 23 packages,


gerard

From dam at opencsw.org  Wed Jul 18 22:55:29 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 18 Jul 2012 22:55:29 +0200
Subject: [csw-maintainers] perl modules for  koha
In-Reply-To: <5006BE0B.5040301@opencsw.org>
References: <5006BE0B.5040301@opencsw.org>
Message-ID: <DF6A12D9-63AA-4329-BBEE-38F39FFE9A82@opencsw.org>

Hi Gerard,

Am 18.07.2012 um 15:45 schrieb Gerard Henry:
> trying to do the install with all the opencsw packages, i got:
> Warning: prerequisite CGI::Session::Driver::memcached 0.04 not found.
> Warning: prerequisite DBD::SQLite2 0.33 not found.
> Warning: prerequisite DateTime::Event::ICal 0.08 not found.
> Warning: prerequisite DateTime::Format::DateParse 0.04 not found.
> Warning: prerequisite DateTime::Set 0.28 not found.
> Warning: prerequisite Graphics::Magick 1.3.05 not found.
> Warning: prerequisite Gravatar::URL 1.03 not found.
> Warning: prerequisite HTTP::OAI 3.2 not found.
> Warning: prerequisite Lingua::Stem::Snowball 0.952 not found.
> Warning: prerequisite Locale::Currency::Format 1.28 not found.
> Warning: prerequisite Locale::PO 0.17 not found.
> Warning: prerequisite MARC::Crosswalk::DublinCore 0.02 not found.
> Warning: prerequisite Memoize::Memcached 0.03 not found.
> Warning: prerequisite Modern::Perl 1.03 not found.
> Warning: prerequisite PDF::API2::Simple 1 not found.
> Warning: prerequisite PDF::Table 0.9.3 not found.
> Warning: prerequisite Readonly 1.03 not found.
> Warning: prerequisite Readonly::XS 1.02 not found.
> Warning: prerequisite Template 2.22 not found.
> Warning: prerequisite Template::Plugin::HtmlToText 0.03 not found.
> Warning: prerequisite Text::CSV::Encoded 0.09 not found.
> Warning: prerequisite UNIVERSAL::require 0.13 not found.
> Warning: prerequisite XML::SAX::Writer 0.44 not found.
> 
> that's 23 packages,


Would you mind updating the wiki page with the latest insights and update
the dependencies as you see fit?


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120718/53a67226/attachment.p7s>

From ghenry at opencsw.org  Thu Jul 19 10:25:02 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Thu, 19 Jul 2012 10:25:02 +0200
Subject: [csw-maintainers] perl modules for  koha
In-Reply-To: <DF6A12D9-63AA-4329-BBEE-38F39FFE9A82@opencsw.org>
References: <5006BE0B.5040301@opencsw.org>
	<DF6A12D9-63AA-4329-BBEE-38F39FFE9A82@opencsw.org>
Message-ID: <5007C45E.6000201@opencsw.org>

On 07/18/12 10:55 PM, Dagobert Michelsen wrote:
> Hi Gerard,
>
> Am 18.07.2012 um 15:45 schrieb Gerard Henry:
>> trying to do the install with all the opencsw packages, i got:
>> Warning: prerequisite CGI::Session::Driver::memcached 0.04 not found.
>> Warning: prerequisite DBD::SQLite2 0.33 not found.
>> Warning: prerequisite DateTime::Event::ICal 0.08 not found.
>> Warning: prerequisite DateTime::Format::DateParse 0.04 not found.
>> Warning: prerequisite DateTime::Set 0.28 not found.
>> Warning: prerequisite Graphics::Magick 1.3.05 not found.
>> Warning: prerequisite Gravatar::URL 1.03 not found.
>> Warning: prerequisite HTTP::OAI 3.2 not found.
>> Warning: prerequisite Lingua::Stem::Snowball 0.952 not found.
>> Warning: prerequisite Locale::Currency::Format 1.28 not found.
>> Warning: prerequisite Locale::PO 0.17 not found.
>> Warning: prerequisite MARC::Crosswalk::DublinCore 0.02 not found.
>> Warning: prerequisite Memoize::Memcached 0.03 not found.
>> Warning: prerequisite Modern::Perl 1.03 not found.
>> Warning: prerequisite PDF::API2::Simple 1 not found.
>> Warning: prerequisite PDF::Table 0.9.3 not found.
>> Warning: prerequisite Readonly 1.03 not found.
>> Warning: prerequisite Readonly::XS 1.02 not found.
>> Warning: prerequisite Template 2.22 not found.
>> Warning: prerequisite Template::Plugin::HtmlToText 0.03 not found.
>> Warning: prerequisite Text::CSV::Encoded 0.09 not found.
>> Warning: prerequisite UNIVERSAL::require 0.13 not found.
>> Warning: prerequisite XML::SAX::Writer 0.44 not found.
>>
>> that's 23 packages,
>
>
> Would you mind updating the wiki page with the latest insights and update
> the dependencies as you see fit?
>

i'm lost with this wiki page. I don't understand what is koha 4.10.05, 
and where the PREREQ_PM ddo come from ?
in koha 3.8.2 (the official latest release), the file Makefile.PL contains:
               PREREQ_PM    => $koha_pm->prereq_pm,
not a detailed list of prerequisite packages.
In fact, the only valid method to find missing packages is to use a perl 
script bundled with koha, called koha_perl_deps.pl. and documented here: 
http://perldoc.koha-community.org/koha_perl_deps.html

imho, it'll be better to interpret the result of this script to know 
what package needs to be available.

gerard



From grzemba at contac-dt.de  Thu Jul 19 15:39:10 2012
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Thu, 19 Jul 2012 15:39:10 +0200
Subject: [csw-maintainers] Reinplacement processing
Message-ID: <7460fb5c7a14.50082a1e@contac-dt.de>

Hi,

the following 

REINPLACE_USRSHARE += $(prefix)/share/gtk-doc/html/gstreamer-plugins-0.10/.*
REINPLACE_WHEN_USRSHARE = postinstall

do not work in gstreamer package. Can I use wildcard for REINPLACE to process all files in the directory?

--
Carsten Grzemba
Tel.:?? +49 3677 64740
Mobil: +49 171 9749479
Fax::?? +49 3677 6474111
Email: carsten.grzemba at contac-dt.de
contac Datentechnik GmbH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120719/3cfa98b8/attachment-0001.html>

From pfelecan at opencsw.org  Thu Jul 19 15:39:58 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Thu, 19 Jul 2012 15:39:58 +0200 (CEST)
Subject: [csw-maintainers] csw-upload-pkg error
Message-ID: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>

Trying to upload a package set I get the following:

pfelecan at login [login]:~ > /opt/csw/bin/checkpkg --catalog-release
unstable --os-release SunOS5.11 --architecture sparc
f6f54be73d6d090f8df454e6c32fe2f6 cf3921795f570ead891dd5a188a56bcf
39e4429ce46ba7dc12c3fb285a25017e a74c1ea82d070f8da732a99fa986c0a7
ab182651de4a03661cdc9fa9b8fc7ebd 97e121b27a83316f98cbb4734e07753e
b9bc1d9df9184320195c19dea0eb8ed7
INFO:root:Unwrapping candies...
100%
|#########################################################################|
INFO:root:Tasting candies one by one...
100%
|#########################################################################|
INFO:root:Tasting them all at once...
INFO:root:Stuffing the candies under the pillow...
Traceback (most recent call last):                                        
    |
  File "/opt/csw/bin/checkpkg", line 197, in <module>
    main()
  File "/opt/csw/bin/checkpkg", line 158, in main
    exit_code, screen_report, tags_report = check_manager.Run()
  File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 824, in Run
    return super(CheckpkgManager2, self).Run()
  File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 252, in Run
    tag_info=unicode(e.tag_info, "utf-8"),
TypeError: coercing to Unicode: need string or buffer, NoneType found

Can a knowledgeable person advise please?

TIA

From maciej at opencsw.org  Thu Jul 19 16:01:58 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 19 Jul 2012 15:01:58 +0100
Subject: [csw-maintainers] csw-upload-pkg error
In-Reply-To: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
References: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
Message-ID: <CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>

I thought Yann fixed it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120719/0f67fbb5/attachment.html>

From yann at pleiades.fr.eu.org  Thu Jul 19 16:24:27 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Thu, 19 Jul 2012 16:24:27 +0200
Subject: [csw-maintainers] csw-upload-pkg error
In-Reply-To: <CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>
References: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
	<CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>
Message-ID: <CAF2fwsd+Zy7vccEQt7UuKp_GDBzRnvZc7bCf7rbHV1-Q7pL4fA@mail.gmail.com>

I fixed it in the the svn tree but Peter is using the checkpkg provided by
a package:  /opt/csw/bin/checkpkg

Yann

2012/7/19 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>

> I thought Yann fixed it.
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120719/16d3d16d/attachment.html>

From maciej at opencsw.org  Thu Jul 19 16:29:04 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 19 Jul 2012 15:29:04 +0100
Subject: [csw-maintainers] csw-upload-pkg error
In-Reply-To: <CAF2fwsd+Zy7vccEQt7UuKp_GDBzRnvZc7bCf7rbHV1-Q7pL4fA@mail.gmail.com>
References: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
	<CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>
	<CAF2fwsd+Zy7vccEQt7UuKp_GDBzRnvZc7bCf7rbHV1-Q7pL4fA@mail.gmail.com>
Message-ID: <CALtRa-4TUWczfOuqZ2cXdS41ud+Mf=QkhegHgqW=m7gpRi-rcw@mail.gmail.com>

I did do a release and installed it on login. Aha! Not upgraded on the
buildfarm.

Also, /opt/csw/bin/checkpkg is broken! Don't use it. Use the one from gar
sources. And make sure to check your package before uploading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120719/d3750c50/attachment.html>

From maciej at opencsw.org  Thu Jul 19 16:52:39 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 19 Jul 2012 15:52:39 +0100
Subject: [csw-maintainers] csw-upload-pkg error
In-Reply-To: <CALtRa-4TUWczfOuqZ2cXdS41ud+Mf=QkhegHgqW=m7gpRi-rcw@mail.gmail.com>
References: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
	<CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>
	<CAF2fwsd+Zy7vccEQt7UuKp_GDBzRnvZc7bCf7rbHV1-Q7pL4fA@mail.gmail.com>
	<CALtRa-4TUWczfOuqZ2cXdS41ud+Mf=QkhegHgqW=m7gpRi-rcw@mail.gmail.com>
Message-ID: <CALtRa-5WJ_x+dZOotrXXRFjG8kmdb2V4kM8ChK3Ur0RJOPnpKg@mail.gmail.com>

2012/7/19 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>
> I did do a release and installed it on login. Aha! Not upgraded on the buildfarm.

On the second thought, cswutils should only be installed on login.

> Also, /opt/csw/bin/checkpkg is broken! Don't use it. Use the one from gar sources. And make sure to check your package before uploading.

I removed it from login so that it doesn't mislead people.

From pfelecan at opencsw.org  Thu Jul 19 19:33:35 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Thu, 19 Jul 2012 19:33:35 +0200
Subject: [csw-maintainers] csw-upload-pkg error
In-Reply-To: <CALtRa-5WJ_x+dZOotrXXRFjG8kmdb2V4kM8ChK3Ur0RJOPnpKg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu,
	19 Jul 2012 15:52:39 +0100")
References: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
	<CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>
	<CAF2fwsd+Zy7vccEQt7UuKp_GDBzRnvZc7bCf7rbHV1-Q7pL4fA@mail.gmail.com>
	<CALtRa-4TUWczfOuqZ2cXdS41ud+Mf=QkhegHgqW=m7gpRi-rcw@mail.gmail.com>
	<CALtRa-5WJ_x+dZOotrXXRFjG8kmdb2V4kM8ChK3Ur0RJOPnpKg@mail.gmail.com>
Message-ID: <x6mx2v3bbk.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> 2012/7/19 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>
>> I did do a release and installed it on login. Aha! Not upgraded on the buildfarm.
>
> On the second thought, cswutils should only be installed on login.
>
>> Also, /opt/csw/bin/checkpkg is broken! Don't use it. Use the one from
>> gar sources. And make sure to check your package before uploading.
>
> I removed it from login so that it doesn't mislead people.

It doesn't mislead people anymore but csw-upload-pkg doesn't work
anymore as it calls what you removed.

Either install checkpkg through its package, if any, or write down the
procedure to upload a package; until now, the procedure was to use
csw-upload-pkg on login...
-- 
Peter

From maciej at opencsw.org  Thu Jul 19 19:48:44 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 19 Jul 2012 18:48:44 +0100
Subject: [csw-maintainers] csw-upload-pkg error
In-Reply-To: <x6mx2v3bbk.fsf@opencsw.org>
References: <43cb1a671eee066be4531676de3a0519.squirrel@mail.opencsw.org>
	<CALtRa-4J6LkAZ+xZRcbTLttJwDh=Zpf72mha9uEqhNpLGZvPcQ@mail.gmail.com>
	<CAF2fwsd+Zy7vccEQt7UuKp_GDBzRnvZc7bCf7rbHV1-Q7pL4fA@mail.gmail.com>
	<CALtRa-4TUWczfOuqZ2cXdS41ud+Mf=QkhegHgqW=m7gpRi-rcw@mail.gmail.com>
	<CALtRa-5WJ_x+dZOotrXXRFjG8kmdb2V4kM8ChK3Ur0RJOPnpKg@mail.gmail.com>
	<x6mx2v3bbk.fsf@opencsw.org>
Message-ID: <CALtRa-4u9SyTp6FbcDQY8oiFCGkyZ2UGKtqL6Kk2v6KocUMq+A@mail.gmail.com>

2012/7/19 Peter FELECAN <pfelecan at opencsw.org>:
> "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:
>
>> 2012/7/19 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>
>>> I did do a release and installed it on login. Aha! Not upgraded on the buildfarm.
>>
>> On the second thought, cswutils should only be installed on login.
>>
>>> Also, /opt/csw/bin/checkpkg is broken! Don't use it. Use the one from
>>> gar sources. And make sure to check your package before uploading.
>>
>> I removed it from login so that it doesn't mislead people.
>
> It doesn't mislead people anymore but csw-upload-pkg doesn't work
> anymore as it calls what you removed.
>
> Either install checkpkg through its package, if any, or write down the
> procedure to upload a package; until now, the procedure was to use
> csw-upload-pkg on login...

Yes, you're right. Unfortunately, we can't remove /opt/csw/bin/checkpkg.

The part of /opt/csw/bin/checkpkg that's broken is the pkgtrans part.
So /opt/csw/bin/checkpkg can analyze a package if the metadata are
already imported. If it's a package that was never seen before, the
checkpkg from the sources must be used.

Of course we want to restore the ability of /opt/csw/bin/checkpkg to
import unseen packages, but it's generally been a problem. But the
workaround is simple: just run checkpkg from gar sources. Once that's
done, /opt/csw/bin/checkpkg will not try to pkgtrans the package and
the upload will work (provided there are no errors).

For now, I restored /opt/csw/bin/checkpkg. I'll dig into it when have
a little time, unless somebody else beats me to it.

Maciej

From dam at opencsw.org  Thu Jul 19 22:41:34 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 19 Jul 2012 22:41:34 +0200
Subject: [csw-maintainers] Reinplacement processing
In-Reply-To: <7460fb5c7a14.50082a1e@contac-dt.de>
References: <7460fb5c7a14.50082a1e@contac-dt.de>
Message-ID: <890247A4-AE56-4F6C-ADF2-73C516E4530F@opencsw.org>

Hi Carsten,

Am 19.07.2012 um 15:39 schrieb Carsten Grzemba:
> the following 
> 
> REINPLACE_USRSHARE += $(prefix)/share/gtk-doc/html/gstreamer-plugins-0.10/.*
> REINPLACE_WHEN_USRSHARE = postinstall
> 
> do not work in gstreamer package. Can I use wildcard for REINPLACE to process all files in the directory?


This should work. Are you sure the path is correct? If in double please commit what you have
and I have a look.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120719/765d5284/attachment-0001.p7s>

From grzemba at contac-dt.de  Fri Jul 20 09:08:58 2012
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Fri, 20 Jul 2012 09:08:58 +0200
Subject: [csw-maintainers] Reinplacement processing
In-Reply-To: <7490c674fc0.50090409@contac-dt.de>
References: <7490c674fc0.50090409@contac-dt.de>
Message-ID: <74908f4c1c41.5009202a@contac-dt.de>

I have figured out that normal shell wildcard is working:

REINPLACE_USRSHARE += $(prefix)/share/gtk-doc/html/gstreamer-plugins-0.10/*

Regards, 

Am 19.07.12, schrieb Dagobert Michelsen  <dam at opencsw.org>:
> Hi Carsten,
> 
> Am 19.07.2012 um 15:39 schrieb Carsten Grzemba:
> > the following 
> > 
> > REINPLACE_USRSHARE += $(prefix)/share/gtk-doc/html/gstreamer-plugins-0.10/.*
> > REINPLACE_WHEN_USRSHARE = postinstall
> > 
> > do not work in gstreamer package. Can I use wildcard for REINPLACE to process all files in the directory?
> 
> 
> This should work. Are you sure the path is correct? If in double please commit what you have
> and I have a look.
> 
> 
> Best regards
> 
> ? -- Dago
> 
> -- 
> "You don't become great by trying to be great, you become great by wanting to do something,
> and then doing it so hard that you become great in the process." - xkcd #896
> 
> 
> 
--
Carsten Grzemba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120720/7c7798c4/attachment.html>

From pfelecan at opencsw.org  Fri Jul 20 13:24:18 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Fri, 20 Jul 2012 13:24:18 +0200 (CEST)
Subject: [csw-maintainers] QA pages update status
Message-ID: <2d21273af5804d5b657ab7636057cae9.squirrel@mail.opencsw.org>

I was wandering on the QA pages and I take a look on my own QA page,
http://www.opencsw.org/qa/maintainer/pfelecan/ and realize that these are
not updated since some time; e.g. mine is completely out of date...

Can a knowledgeable person assess this?


From pfelecan at opencsw.org  Fri Jul 20 13:28:54 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Fri, 20 Jul 2012 13:28:54 +0200 (CEST)
Subject: [csw-maintainers] TCL package(s)
Message-ID: <13f52135c283057fb851e75c83baf429.squirrel@mail.opencsw.org>

As I'm working to the migration of the gdb recipe from a private to a GAR
based one, I fell for the old issue of the "private" headers that should
be provided by the tcl package. Exploring the state of the current
packages I discovered that there was work on a "garification": there is a
tcl84 and a tcl85 (why 2 of them I cannot understand) but there was no
release of the resulting packages. Dag and/or Roger, can you give us a
status?

TIA


From dam at opencsw.org  Fri Jul 20 18:37:30 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 20 Jul 2012 18:37:30 +0200
Subject: [csw-maintainers] QA pages update status
In-Reply-To: <2d21273af5804d5b657ab7636057cae9.squirrel@mail.opencsw.org>
References: <2d21273af5804d5b657ab7636057cae9.squirrel@mail.opencsw.org>
Message-ID: <AF19B0A7-930F-4EB8-94A7-3D2D2104386E@opencsw.org>

Hi Peter,

Am 20.07.2012 um 13:24 schrieb pfelecan at opencsw.org:
> I was wandering on the QA pages and I take a look on my own QA page,
> http://www.opencsw.org/qa/maintainer/pfelecan/ and realize that these are
> not updated since some time; e.g. mine is completely out of date...
> 
> Can a knowledgeable person assess this?

The problem is that William is basically the only one who knows how this works.
I suggest we address this in a joint action on the next camp. If you (or anyone
else) wants to have a look I am sure we can hand over the credentials.


Best regards

  -- Dago


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120720/710b3566/attachment.p7s>

From dam at opencsw.org  Fri Jul 20 18:41:37 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 20 Jul 2012 18:41:37 +0200
Subject: [csw-maintainers] TCL package(s)
In-Reply-To: <13f52135c283057fb851e75c83baf429.squirrel@mail.opencsw.org>
References: <13f52135c283057fb851e75c83baf429.squirrel@mail.opencsw.org>
Message-ID: <7BE9540D-3047-41A5-B71B-FBC8E1880988@opencsw.org>

Hi Peter,

Am 20.07.2012 um 13:28 schrieb pfelecan at opencsw.org:
> As I'm working to the migration of the gdb recipe from a private to a GAR
> based one, I fell for the old issue of the "private" headers that should
> be provided by the tcl package. Exploring the state of the current
> packages I discovered that there was work on a "garification": there is a
> tcl84 and a tcl85 (why 2 of them I cannot understand) but there was no
> release of the resulting packages. Dag and/or Roger, can you give us a
> status?

The Tcl/Tk packages for 8.5 are ready for release as far as I know. However,
I have no idea how the modules or scripts work as I am not a Tcl person,
so all reps need to be inspected before the update. The new package features
32/64 bit and all bells and whistles. Last time Igor Galic lend me a hand
testing but unfortunately we didn't finish the job. Maybe we need again some
joint action. Roger got some time off from the project and he is not probably
ready to come back yet.


Best regards

  -- Dago


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120720/db88b738/attachment.p7s>

From dam at opencsw.org  Sat Jul 21 17:48:04 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 21 Jul 2012 17:48:04 +0200
Subject: [csw-maintainers] Update of pysvn
Message-ID: <CC36246B-88B3-4C9B-A6AE-D575FFFC91F8@opencsw.org>

Hi folks,

I did some more research for the OpenSSL update which requires action on libneon.so.26.
This is a transitive dependency of pysvn depending on neon depending on libneon.so.26 and .27,
so to obsolete neon and libneon.so.26 the rebuild of pysvn is needed. I took a look with
a Makefile update but got stuck at an error which may be easy so solve for someone with
more Python skills than me:

> (cd work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Source \
>         && HOME="/home/dam" PATH="/home/dam/mgar/pkg/.buildsys/v2/gar/bin/sos12-wrappers:/home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin:/home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin:/home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/sbin:/home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/SUNWspro/bin:/home/dam/mgar/pkg/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-xO3 -m32 -xarch=sparc" CXXFLAGS="-xO3 -m32 -xarch=sparc" LDFLAGS="-m32 -xarch=sparc -L/opt/csw/lib" FFLAGS="-xO3 -m32 -xarch=sparc" FCFLAGS="-xO3 -m32 -xarch=sparc" F77="/opt/SUNWspro/bin/f77" FC="/opt/SUNWspro/bin/f95" ASFLAGS="" OPTFLAGS="-xO3 -m32 -xarch=sparc" CC="/opt/SUNWspro/bin/cc" CXX="/opt/SUNWspro/bin/CC" CC_HOME="/opt/SUNWspro" CC_VERSION="Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11" CXX_VERSION="Sun C++ 5.9 SunOS_sparc Patch 124863-29 2012/04/04" GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib" PKG_CONFIG_PATH="/opt/csw/lib/pkgconfig" DESTDIR="/home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/install-isa-sparcv8plus"  python setup.py configure \
>                 --apr-inc-dir=/opt/csw/include \
>                 --apr-lib-dir=/opt/csw/lib \
>                 --apu-inc-dir=/opt/csw/include \
>                 --svn-bin-dir=/opt/csw/bin \
>                 --svn-inc-dir=/opt/csw/include/subversion-1 \
>                 --svn-lib-dir=/opt/csw/lib/svn \
> )
> Info: Configure for python 2.6.8 in exec_prefix /opt/csw
> Info: Found  PyCXX include in /home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Import/pycxx-6.2.4
> Info: Found  PyCXX include in /home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Import/pycxx-6.2.4
> Info: Found   PyCXX Source in /home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Import/pycxx-6.2.4/Src
> Info: Found    SVN include in /opt/csw/include/subversion-1
> Info: Found    SVN library in /opt/csw/lib/svn
> Info: Found        SVN bin in /opt/csw/bin
> Info: Found    APR include in /opt/csw/include
> Info: Found    APR include in /opt/csw/include
> Info: Found    APR library in /opt/csw/lib
> Info: Building against SVN 1.7.5
> Info: Found  PyCXX include in /home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Import/pycxx-6.2.4
> Info: Found  PyCXX include in /home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Import/pycxx-6.2.4
> Info: Found   PyCXX Source in /home/dam/mgar/pkg/lang-python/pysvn/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pysvn-1.7.6/Import/pycxx-6.2.4/Src
> Info: Found    SVN include in /opt/csw/include/subversion-1
> Info: Found    SVN library in /opt/csw/lib/svn
> Info: Found        SVN bin in /opt/csw/bin
> Info: Found    APR include in /opt/csw/include
> Info: Found    APR include in /opt/csw/include
> Info: Found    APR library in /opt/csw/lib
> Info: Building against SVN 1.7.5
> Info: Using tool chain SunOsCompilerGCC
> ('Error:', "Cannot addVar name 'LDLIBS' value '-L%(svn_lib_dir)s -Wl,--rpath -Wl,%(svn_lib_dir)s -lsvn_client-1 -lsvn_diff-1 -lsvn_repos-1 -lresolv -lexpat -lneon' - 'svn_lib_dir'")
> gmake[1]: *** [configure-pysvn] Error 1
> gmake[1]: Leaving directory `/home/dam/mgar/pkg/lang-python/pysvn/trunk'
> gmake: *** [merge-isa-sparcv8plus] Error 2

I have committed what I have at pkg/lang-python/pysvn/trunk.


Best regards

  -- Dago


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120721/9ac62614/attachment-0001.p7s>

From yann at pleiades.fr.eu.org  Sun Jul 22 03:03:15 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jul 2012 03:03:15 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
Message-ID: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>

Hi everyone,

I am trying to enable symbol versioning with openssl because I think it
would be a better solution to avoid in the future the current difficulties
we are facing with the openssl migration.
However I have some difficulties to have it working and I am not yet sure
it will effectively solves the problem.

I thought that, with symbol versoning, libraries and program linked with
libssl0.9.8 or libssl1.0.0 would always be linked with the correct library
even in runtime dual-linking situation, because the linked would detect
that the one library wants the symbol from the 0.9.8 library only and the
other one wants the same symbol but from the 1.0.0 library.

It doesn't seem to work exactly as I expected, I still some additional
tests to do to understand but I would definitely welcome any light on this
subject.

I compiled a version of openssl for Solaris >=10 x86 in my experimental
repository for those who would like to try:
pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann-i
libssl1_0_0 libssl_dev openssl_utils

Here are some information I've found:
http://docs.oracle.com/cd/E23824_01/html/821-1602/solarisabi-6.html#solarisabi-8
http://docs.oracle.com/cd/E19082-01/819-0690/chapter5-84101/index.html

Here is the details of the tests I've done.

- I first tried to test if a binary linked with the symbol versioned libssl
would work with the unversioned one. I expected that it would'nt work.

To test that, I kept the openssl binary linked with the symbols versioned
libssl and downgraded libssl to the unversioned one.
After that, ldd clearly showed that the installed library was lacking the
good version of the library.

# ldd /opt/csw/bin/openssl
        libssl.so.1.0.0 =>       /opt/csw/lib/i386/libssl.so.1.0.0
        libssl.so.1.0.0 (OPENSSL_1.0.1) =>       (version not found)
        libcrypto.so.1.0.0 =>    /opt/csw/lib/i386/libcrypto.so.1.0.0
        libcrypto.so.1.0.0 (OPENSSL_1.0.1) =>    (version not found)
[...]

but openssl still worked correctly !!

I was able to launch it, it works and with verbose linking information, I
clearly saw that ld.so linked openssl with libssl, although it clearly
noticed that it wanted the version OPENSSL_1.0.1 of the library.

# LD_DEBUG=all LD_BIND_NOW=1 /opt/csw/bin/openssl
[...]
01133: version needed processing: file=/opt/csw/bin/openssl
01133:             file                        version
01133:             libssl.so.1.0.0             OPENSSL_1.0.1
[...]
01133: binding file=/opt/csw/bin/openssl to
file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'i2d_SSL_SESSION'
[...]

and the libssl definitely didn't have the OPENSSL_1.0.1 version

# pvs -s /opt/csw/lib/libssl.so.1.0.0
(nothing)


- I tried then to test if binary linked with the unversioned library would
work with the versioned one.

I installed openssl_utils from the unstable repository and installed the
libssl1-0-0 package from my experimental repository.
Again openssl worked perfectly, and didn't complain at all, although libssl
did implement the versioned symbols:

# pvs -s /opt/csw/lib/libssl.so.1.0.0
[...]
        libssl.so.1.0.0:
                _GLOBAL_OFFSET_TABLE_;
                _etext;
                _DYNAMIC;
                _edata;
                _end;
                _PROCEDURE_LINKAGE_TABLE_;
        OPENSSL_1.0.0:
                SSL_get_shared_ciphers;
                SSL_set_bio;
[...]
       OPENSSL_1.0.1:
                SSL_CTX_set_srp_client_pwd_callback;
[...]


That's less a problem here, because that would ease the migration to a
libssl with symbol versioning and allow third binaries to use our libssl
library even if they didn't compile against it.

But I still don't understand how this it is supposed to work and I am not
quite sure it will prevent an library linked with libsslX to link with
libsslX+1 at runtime.

It seems the linker consider that an unversioned symbol can be linked to
any versioned one.

I will try to compile a libssl0.9.8 with symbol versioning to really test
if this would help during a library migration.

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120722/94030da5/attachment.html>

From pfelecan at opencsw.org  Sun Jul 22 12:17:18 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 22 Jul 2012 12:17:18 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	(Yann Rouillard's message of "Sun, 22 Jul 2012 03:03:15 +0200")
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
Message-ID: <x6a9ys2j81.fsf@opencsw.org>

Yann Rouillard <yann at pleiades.fr.eu.org> writes:

> I will try to compile a libssl0.9.8 with symbol versioning to really test
> if this would help during a library migration.

This is the most probable solution, i.e., to have only versioned
libraries installed; it will let binaries compiled with non versioned
libraries to execute, which is what we wish, isn't it? However, which
library is used is pending a test; I bet 2 drachmas that the highest
version is used...

-- 
Peter

From yann at pleiades.fr.eu.org  Sun Jul 22 20:02:18 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jul 2012 20:02:18 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <x6a9ys2j81.fsf@opencsw.org>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
Message-ID: <CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>

So I did the tests and ... it doesn't work.

I recompiled libssl0.9.8 with symbol versioning enabled.
I recompiled libneon against this libssl0.9.8 library.
I recompiled cadaver against libssl1.0.0 with symbol versioning enabled.

The result is:

- libssl0.9.8 compiled fine with symbol versioning enabled:

# pvs /opt/csw/lib/libssl.so.0.9.8
        libcrypto.so.0.9.8 (OPENSSL_0.9.8);
        libc.so.1 (SUNW_0.7, SUNWprivate_1.1);
        libssl.so.0.9.8;
        OPENSSL_0.9.8;

- the libneon27 effectively registered the dependancy on the OPENSSL_0.9.8
symbols:

# pvs -r /opt/csw/lib/libneon.so.27.2.6
        libssl.so.0.9.8 (OPENSSL_0.9.8);
        libcrypto.so.0.9.8 (OPENSSL_0.9.8);
[...]

- but the linker still links the libneon ssl symbols with openssl 1.0.0
when I launch cadaver:
# LD_DEBUG=all /opt/csw/bin/cadaver

[...]
18581: version needed processing: file=/opt/csw/lib/i386/libneon.so.27
18581:             file                        version
18581:             libssl.so.0.9.8             OPENSSL_0.9.8
18581:
[...]
18581: binding file=/opt/csw/lib/i386/libneon.so.27 to
file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_pending'
[...]


So I am really surprised but the conclusion is that solaris symbol
versoning doesn't help in this case.
It seems the version check is only done to see if the whole library can be
loaded (and only if the application/library and the library both use
versioning), but it is not used after to link the symbols.

>From what I understood, symbol versioning in Linux works at the symbol
level and would effectively help to prevent the kind of problem we have
here.

But for now I don't see a way to avoid the same painful transition in the
future. I still welcome any light on symbol versioning because I may have
missed something.

Yann










2012/7/22 Peter FELECAN <pfelecan at opencsw.org>

> Yann Rouillard <yann at pleiades.fr.eu.org> writes:
>
> > I will try to compile a libssl0.9.8 with symbol versioning to really test
> > if this would help during a library migration.
>
> This is the most probable solution, i.e., to have only versioned
> libraries installed; it will let binaries compiled with non versioned
> libraries to execute, which is what we wish, isn't it? However, which
> library is used is pending a test; I bet 2 drachmas that the highest
> version is used...
>
> --
> Peter
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120722/fa7b1c1d/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Sun Jul 22 20:19:00 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Sun, 22 Jul 2012 20:19:00 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
Message-ID: <500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> It seems the version check is only done to see if the whole library can be
> loaded (and only if the application/library and the library both use
> versioning), but it is not used after to link the symbols.
>
> From what I understood, symbol versioning in Linux works at the symbol
> level and would effectively help to prevent the kind of problem we have
> here.

I am not sure whether you have different expectations than what symbol 
versioning is.

What problem do you have and how do you like to solve it?

Symbol versioning cannot heal incompatible changes.

Symbol versioning however allows to link against an older version of the 
library at runtime than the one that was used at compile time - given that the 
user does not need the new features of younger library versions.

J?rg

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

From yann at pleiades.fr.eu.org  Sun Jul 22 22:08:25 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Sun, 22 Jul 2012 22:08:25 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>

Hi Joerg,

2012/7/22 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> > It seems the version check is only done to see if the whole library can
> be
> > loaded (and only if the application/library and the library both use
> > versioning), but it is not used after to link the symbols.
> >
> > From what I understood, symbol versioning in Linux works at the symbol
> > level and would effectively help to prevent the kind of problem we have
> > here.
>
> I am not sure whether you have different expectations than what symbol
> versioning is.
>

Well I expected it to work more like it does on Linux (more details below).


>
> What problem do you have and how do you like to solve it?
>

Here is the problem I want to solve:
     application APP1 is linked against libB.so.2 and libC.so.1
     libC.so.1 is linked against libB.so.1
     libB.so.1 and libB.so.2 have incompatible sonames.

     At runtime, I want:
        - APP1 libB symbols to be linked against libB.so.2,
        - libC.so.1 libB symbols to be linked against libB.so.1.

     Currently, what I have is:
        - APP1 libB symbols linked against libB.so.2 (that's ok),
        - libC.so.1 libB symbols linked against libB.so.2 (that's not good)


The reason I want this is that I would like to be able to gracefully handle
a library soname upgrade for libraries like openssl.
Currently as openssl is directly linked by a lot of libraries and binaries,
when you provide a new library (with incompatible soname), you have to
recompile and upload all the reverse-dependant packages at the same time to
be sure not to have a situation like described above.

This takes a lot of time and needs a lot of coordination.



>
> Symbol versioning cannot heal incompatible changes.


> Symbol versioning however allows to link against an older version of the
> library at runtime than the one that was used at compile time - given that
> the
> user does not need the new features of younger library versions.
>

Yes I do understand that. It allows a binary compiled against openssl 1.0.1
to work against openssl 1.0.0 if the binary only used functions compatibles
with openssl 1.0.0 (openssl 1.0.1 and openssl 1.0.0 provide the same soname
libssl1.0.0 but openssl 1.0.1 may have added new functions).
And if the binary used a openssl 1.0.1 specific function, the linker will
prevent you from running the binary on a computer with the openssl 1.0.0
library, even though the openssl 1.0.0 provides the same soname.

But I also expected the symbol versioning to work at the symbol level (and
not at the library level) so the linker will also use that information to
understand against which library each symbol must be linked, in case the
same symbol is provided by two libraries loaded at runtime.

This is how it works under Linux.

Do you know how to achieve this under Solaris, or how to solve the general
library upgrade problem in a general manner ?

Thanks in advance for your answer.


To explain how it works under Linux, here is a real exemple:

 - I have a neon library directly linked against libcrypto and libssl 0.9.8

# objdump -xT /usr/lib/libneon.so.27.2.6
[...]
  NEEDED               libcrypto.so.0.9.8
  NEEDED               libssl.so.0.9.8
[...]
0000000000000000      DF *UND* 0000000000000000  OPENSSL_0.9.8 SSLeay
[...]

 - I have a cadaver binary directly linked against libneon and libcrypto
1.0.0
# objdump -xT /usr/bin/cadaver
[...]
  NEEDED               libcrypto.so.1.0.0
  NEEDED               libneon.so.27
[...]
0000000000000000      DF *UND* 0000000000000000  OPENSSL_1.0.0 SSLeay
[...]

 - at runtime, both libcrypto libraries are loaded and the linker correctly
link cadaver and libneon with the good version of the library:
# LD_DEBUG=all LD_BIND_NOW=1 cadaver
[...]
     21796:     file=libcrypto.so.1.0.0 [0];  needed by cadaver [0]
     21796:     find library=libcrypto.so.1.0.0 [0]; searching
     21796:      search cache=/etc/ld.so.cache
     21796:       trying file=/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
[...]
     21796:     file=libcrypto.so.0.9.8 [0];  needed by
/usr/lib/libneon.so.27 [0]
     21796:     find library=libcrypto.so.0.9.8 [0]; searching
     21796:      search cache=/etc/ld.so.cache
     21796:       trying file=/lib/x86_64-linux-gnu/libcrypto.so.0.9.8
[...]
     21796:     binding file /usr/lib/libneon.so.27 [0] to
/lib/x86_64-linux-gnu/libcrypto.so.0.9.8 [0]: normal symbol `SSLeay'
[OPENSSL_0.9.8]
[...]
     21796:     binding file cadaver [0] to
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 [0]: normal symbol `SSLeay'
[OPENSSL_1.0.0]
[...]



Yann





>
> J?rg
>
> --
>  EMail:joerg at schily.net                  (home) J?rg Schilling D-13353
> Berlin
>        js at cs.tu-berlin.de                (uni)
>        joerg.schilling at fokus.fraunhofer.de (work) Blog:
> http://schily.blogspot.com/
>  URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120722/95470d4e/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Mon Jul 23 12:44:34 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 23 Jul 2012 12:44:34 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
Message-ID: <500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> Well I expected it to work more like it does on Linux (more details below).

versioned libraries have been introduced on Solaris nearly 20 ears ago. They 
have been introdiuced recently on Linux and ti me, it seems that Linux copied 
the Solaris model after they had a really strange intermediate solution.

> Here is the problem I want to solve:
>      application APP1 is linked against libB.so.2 and libC.so.1
>      libC.so.1 is linked against libB.so.1
>      libB.so.1 and libB.so.2 have incompatible sonames.
>
>      At runtime, I want:
>         - APP1 libB symbols to be linked against libB.so.2,
>         - libC.so.1 libB symbols to be linked against libB.so.1.
>
>      Currently, what I have is:
>         - APP1 libB symbols linked against libB.so.2 (that's ok),
>         - libC.so.1 libB symbols linked against libB.so.2 (that's not good)

Why is this not good? Is libB.so.2 incompatible to libB.so.1?


> The reason I want this is that I would like to be able to gracefully handle
> a library soname upgrade for libraries like openssl.
> Currently as openssl is directly linked by a lot of libraries and binaries,
> when you provide a new library (with incompatible soname), you have to
> recompile and upload all the reverse-dependant packages at the same time to
> be sure not to have a situation like described above.
>
> This takes a lot of time and needs a lot of coordination.

A library upgrade works easy if the author of the library is careful, keeps 
the same soname and does not introduce incompatible changes but only compatible 
enhancements.

> > Symbol versioning however allows to link against an older version of the
> > library at runtime than the one that was used at compile time - given that
> > the
> > user does not need the new features of younger library versions.
> >
>
> Yes I do understand that. It allows a binary compiled against openssl 1.0.1
> to work against openssl 1.0.0 if the binary only used functions compatibles
> with openssl 1.0.0 (openssl 1.0.1 and openssl 1.0.0 provide the same soname
> libssl1.0.0 but openssl 1.0.1 may have added new functions).
> And if the binary used a openssl 1.0.1 specific function, the linker will
> prevent you from running the binary on a computer with the openssl 1.0.0
> library, even though the openssl 1.0.0 provides the same soname.
>
> But I also expected the symbol versioning to work at the symbol level (and
> not at the library level) so the linker will also use that information to
> understand against which library each symbol must be linked, in case the
> same symbol is provided by two libraries loaded at runtime.

Library versioning works at symbol level. Maybe your mapfile is not correct.
Given the fact that the same mapfiles work on Solaris and Linux, I am not 
convinced that Linux is different.

> This is how it works under Linux.
>
> Do you know how to achieve this under Solaris, or how to solve the general
> library upgrade problem in a general manner ?
>
> Thanks in advance for your answer.
>
>
> To explain how it works under Linux, here is a real exemple:
>
>  - I have a neon library directly linked against libcrypto and libssl 0.9.8
>
> # objdump -xT /usr/lib/libneon.so.27.2.6
> [...]
>   NEEDED               libcrypto.so.0.9.8
>   NEEDED               libssl.so.0.9.8
> [...]
> 0000000000000000      DF *UND* 0000000000000000  OPENSSL_0.9.8 SSLeay
> [...]
>
>  - I have a cadaver binary directly linked against libneon and libcrypto
> 1.0.0
> # objdump -xT /usr/bin/cadaver
> [...]
>   NEEDED               libcrypto.so.1.0.0
>   NEEDED               libneon.so.27
> [...]
> 0000000000000000      DF *UND* 0000000000000000  OPENSSL_1.0.0 SSLeay
> [...]
>
>  - at runtime, both libcrypto libraries are loaded and the linker correctly
> link cadaver and libneon with the good version of the library:
> # LD_DEBUG=all LD_BIND_NOW=1 cadaver
> [...]
>      21796:     file=libcrypto.so.1.0.0 [0];  needed by cadaver [0]
>      21796:     find library=libcrypto.so.1.0.0 [0]; searching
>      21796:      search cache=/etc/ld.so.cache
>      21796:       trying file=/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> [...]
>      21796:     file=libcrypto.so.0.9.8 [0];  needed by
> /usr/lib/libneon.so.27 [0]
>      21796:     find library=libcrypto.so.0.9.8 [0]; searching
>      21796:      search cache=/etc/ld.so.cache
>      21796:       trying file=/lib/x86_64-linux-gnu/libcrypto.so.0.9.8
> [...]
>      21796:     binding file /usr/lib/libneon.so.27 [0] to
> /lib/x86_64-linux-gnu/libcrypto.so.0.9.8 [0]: normal symbol `SSLeay'
> [OPENSSL_0.9.8]
> [...]
>      21796:     binding file cadaver [0] to
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 [0]: normal symbol `SSLeay'
> [OPENSSL_1.0.0]
> [...]

SSLeay may have version tags for more than version but there cannot be 
different SSLeay implementations.

J?rg

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

From yann at pleiades.fr.eu.org  Mon Jul 23 13:09:21 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 13:09:21 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>

Hi Joerg,

2012/7/23 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> > Here is the problem I want to solve:
> >      application APP1 is linked against libB.so.2 and libC.so.1
> >      libC.so.1 is linked against libB.so.1
> >      libB.so.1 and libB.so.2 have incompatible sonames.
> >
> >      At runtime, I want:
> >         - APP1 libB symbols to be linked against libB.so.2,
> >         - libC.so.1 libB symbols to be linked against libB.so.1.
> >
> >      Currently, what I have is:
> >         - APP1 libB symbols linked against libB.so.2 (that's ok),
> >         - libC.so.1 libB symbols linked against libB.so.2 (that's not
> good)
>
> Why is this not good? Is libB.so.2 incompatible to libB.so.1?
>
>
Yes they are incompatible. libB.so.2 has a different soname, it is not ABI
compatible with libB.so.1



> > The reason I want this is that I would like to be able to gracefully
> handle
> > a library soname upgrade for libraries like openssl.
> > Currently as openssl is directly linked by a lot of libraries and
> binaries,
> > when you provide a new library (with incompatible soname), you have to
> > recompile and upload all the reverse-dependant packages at the same time
> to
> > be sure not to have a situation like described above.
> >
> > This takes a lot of time and needs a lot of coordination.
>
> A library upgrade works easy if the author of the library is careful, keeps
> the same soname and does not introduce incompatible changes but only
> compatible
> enhancements.
>

Well, libraries authors change the soname from time to time when they don't
want to maintain the ABI compatibility for some reason.
I do agree there should not be any problem if the soname is kept and if the
ABI compatibility is maintained by the authors.
But the case here is a library upgrade with a soname/ABI modification.


> > > Symbol versioning however allows to link against an older version of
> the
> > > library at runtime than the one that was used at compile time - given
> that
> > > the
> > > user does not need the new features of younger library versions.
> > >
> >
> > Yes I do understand that. It allows a binary compiled against openssl
> 1.0.1
> > to work against openssl 1.0.0 if the binary only used functions
> compatibles
> > with openssl 1.0.0 (openssl 1.0.1 and openssl 1.0.0 provide the same
> soname
> > libssl1.0.0 but openssl 1.0.1 may have added new functions).
> > And if the binary used a openssl 1.0.1 specific function, the linker will
> > prevent you from running the binary on a computer with the openssl 1.0.0
> > library, even though the openssl 1.0.0 provides the same soname.
> >
> > But I also expected the symbol versioning to work at the symbol level
> (and
> > not at the library level) so the linker will also use that information to
> > understand against which library each symbol must be linked, in case the
> > same symbol is provided by two libraries loaded at runtime.
>
> Library versioning works at symbol level. Maybe your mapfile is not
> correct.
> Given the fact that the same mapfiles work on Solaris and Linux, I am not
> convinced that Linux is different.
>

Yes, its works at the symbol level but:
  - the linker doesn't seem to use that information when it links a given
symbol, it only uses it to check wether or not it can load a library,
  - it is not registered at the symbol level in the solaris elf file (that
could perfectly work without it, but it seems that the version is stored
for each symbol in Linux elf files).

But I may have done something wrong, you could have a look at my previous
email to see the tests I made (I showed the output of pvs to check if the
symbol versioning information was there) and I just commited my
modifications so you can have a look on svn:
 - the mapfiles are here:
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.engines
 ,
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libssl
 and
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libcrypto

 - the modification I've made are in this patch:
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/0007-enables-symbols-versioning.patch?revision=18832&view=markup
   Basically I've just added the "-M" option.


>
> SSLeay may have version tags for more than version but there cannot be
> different SSLeay implementations.
>

Well it is the case here.
 - libcrypto.so.0.9.8 provides the SSLeay symbol.
 - libcrypto.so.1.0.0 also provides the SSLeay symbol.
 - but these 2 libraries are not ABI compatibles so we're not supposed to
link against libcrypto.so.1.0.0 a SSLeay symbol present in a binary that
was compiled against libcrypto.so.0.9.8.

Tell me if I understand something wrong here.

Thanks for your

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/e002da18/attachment-0001.html>

From yann at pleiades.fr.eu.org  Mon Jul 23 13:30:49 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 13:30:49 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
Message-ID: <CAF2fwsc9nnpRR6K+fyxDJ2aaiaFqMdMA_-BGjWx9Mg3zzWP8Gg@mail.gmail.com>

>
> Well it is the case here.
>  - libcrypto.so.0.9.8 provides the SSLeay symbol.
>  - libcrypto.so.1.0.0 also provides the SSLeay symbol.
>  - but these 2 libraries are not ABI compatibles so we're not supposed to
> link against libcrypto.so.1.0.0 a SSLeay symbol present in a binary that
> was compiled against libcrypto.so.0.9.8.
>

BTW, openssl 1.0.0 seems definitely not ABI compatible with 0.9.8 according
to
http://www.upstream-tracker.org/compat_reports/openssl/0.9.8x_to_1.0.0/abi_compat_report.html#Symbol_Problems_High

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/4a27196c/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Mon Jul 23 14:02:33 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 23 Jul 2012 14:02:33 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
Message-ID: <500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> > Given the fact that the same mapfiles work on Solaris and Linux, I am not
> > convinced that Linux is different.
> >
>
> Yes, its works at the symbol level but:
>   - the linker doesn't seem to use that information when it links a given
> symbol, it only uses it to check wether or not it can load a library,
>   - it is not registered at the symbol level in the solaris elf file (that
> could perfectly work without it, but it seems that the version is stored
> for each symbol in Linux elf files).
>
> But I may have done something wrong, you could have a look at my previous
> email to see the tests I made (I showed the output of pvs to check if the
> symbol versioning information was there) and I just commited my
> modifications so you can have a look on svn:
>  - the mapfiles are here:
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.engines
>  ,
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libssl
>  and
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libcrypto

You may like to look at the map file from libschily:

ftp://ftp.berlios.de/pub/schily/

You did not use nested definitions.

J?rg

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

From Joerg.Schilling at fokus.fraunhofer.de  Mon Jul 23 14:05:06 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 23 Jul 2012 14:05:06 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwsc9nnpRR6K+fyxDJ2aaiaFqMdMA_-BGjWx9Mg3zzWP8Gg@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<CAF2fwsc9nnpRR6K+fyxDJ2aaiaFqMdMA_-BGjWx9Mg3zzWP8Gg@mail.gmail.com>
Message-ID: <500d3df2.wsES+0IDKPFkZRIw%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> >
> > Well it is the case here.
> >  - libcrypto.so.0.9.8 provides the SSLeay symbol.
> >  - libcrypto.so.1.0.0 also provides the SSLeay symbol.
> >  - but these 2 libraries are not ABI compatibles so we're not supposed to
> > link against libcrypto.so.1.0.0 a SSLeay symbol present in a binary that
> > was compiled against libcrypto.so.0.9.8.
> >
>
> BTW, openssl 1.0.0 seems definitely not ABI compatible with 0.9.8 according
> to
> http://www.upstream-tracker.org/compat_reports/openssl/0.9.8x_to_1.0.0/abi_compat_report.html#Symbol_Problems_High

And you are really sure that this works with Linux?

Linux should also suffer from the incompatibilities.

It looks like you need to supply both libraries.


J?rg

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

From yann at pleiades.fr.eu.org  Mon Jul 23 14:31:45 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 14:31:45 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwse1wcX2VM3YfouOtiOeKWjpgDkEMJHM=H5cx4G_b2+=eA@mail.gmail.com>

2012/7/23 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
>
> >  - the mapfiles are here:
> >
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.engines
> >  ,
> >
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libssl
> >  and
> >
> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libcrypto
>
> You may like to look at the map file from libschily:
>
> ftp://ftp.berlios.de/pub/schily/
>
> You did not use nested definitions.
>

Maybe I don't get what nested definitions are but I thought I did. In both
files, I have this:

     OPENSSL_1.0.0 {
global:
[...]
};
     OPENSSL_1.0.1 {
global:
[...]
} OPENSSL_1.0.0;

Is this what we are talking about ?


Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/7dd092d6/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Mon Jul 23 14:43:15 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 23 Jul 2012 14:43:15 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwse1wcX2VM3YfouOtiOeKWjpgDkEMJHM=H5cx4G_b2+=eA@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwse1wcX2VM3YfouOtiOeKWjpgDkEMJHM=H5cx4G_b2+=eA@mail.gmail.com>
Message-ID: <500d46e3.D7eggkChQE4Ot3GL%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> > ftp://ftp.berlios.de/pub/schily/
> >
> > You did not use nested definitions.
> >
>
> Maybe I don't get what nested definitions are but I thought I did. In both
> files, I have this:
>
>      OPENSSL_1.0.0 {
> global:
> [...]
> };
>      OPENSSL_1.0.1 {
> global:
> [...]
> } OPENSSL_1.0.0;
>
> Is this what we are talking about ?

This is not nested.

This is why I pointed you to my mal files.

J?rg

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

From yann at pleiades.fr.eu.org  Mon Jul 23 14:47:21 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 14:47:21 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500d3df2.wsES+0IDKPFkZRIw%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<CAF2fwsc9nnpRR6K+fyxDJ2aaiaFqMdMA_-BGjWx9Mg3zzWP8Gg@mail.gmail.com>
	<500d3df2.wsES+0IDKPFkZRIw%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwsfc1aArCfrbxe+K-mD7Ho7daZprhW7t2-sWWaJU8j3qAg@mail.gmail.com>

2012/7/23 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> > BTW, openssl 1.0.0 seems definitely not ABI compatible with 0.9.8
> according
> > to
> >
> http://www.upstream-tracker.org/compat_reports/openssl/0.9.8x_to_1.0.0/abi_compat_report.html#Symbol_Problems_High
>
> And you are really sure that this works with Linux?
>
> Linux should also suffer from the incompatibilities.
>

Well I am sure this works with Linux because I did the tests, the example I
previously gave about Linux:   (
http://lists.opencsw.org/pipermail/maintainers/2012-July/017068.html ) is a
real life example (although I had to recompile packages to re-create the
situation).

And it doesn't seem Debian had to follow the same painfull process for the
transition, because they have used symbol versioning for a long time:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622134



> It looks like you need to supply both libraries.
>

Yes I need to, but only one of them is really used at runtime under Solaris
and at least one library or binary is linked against the wrong ssl version
at runtime. That's the problem I am trying to fix.

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/d884ce24/attachment-0001.html>

From yann at pleiades.fr.eu.org  Mon Jul 23 14:53:43 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 14:53:43 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500d46e3.D7eggkChQE4Ot3GL%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwse1wcX2VM3YfouOtiOeKWjpgDkEMJHM=H5cx4G_b2+=eA@mail.gmail.com>
	<500d46e3.D7eggkChQE4Ot3GL%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwsfNQABMyG6g3fJz5gKhWbwkruMw+QdhRV-9fRmKw7aZPg@mail.gmail.com>

2012/7/23 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> > > ftp://ftp.berlios.de/pub/schily/
> > >
> > > You did not use nested definitions.
> > >
> >
> > Maybe I don't get what nested definitions are but I thought I did. In
> both
> > files, I have this:
> >
> >      OPENSSL_1.0.0 {
> > global:
> > [...]
> > };
> >      OPENSSL_1.0.1 {
> > global:
> > [...]
> > } OPENSSL_1.0.0;
> >
> > Is this what we are talking about ?
>
> This is not nested.
>

Can you explain me what nested means or give me a link to some
documentation ?
BTW, does that nesting thing would solve the problem ?


>
> This is why I pointed you to my mal files.
>

There a lot of mapfiles in schilly. I had a look at libschily-mapvers but I
still don't get what I've done wrong by looking at this file.
Did I miss something or do I need to look elsewhere ?

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

From Joerg.Schilling at fokus.fraunhofer.de  Mon Jul 23 15:04:02 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 23 Jul 2012 15:04:02 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwsfNQABMyG6g3fJz5gKhWbwkruMw+QdhRV-9fRmKw7aZPg@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwse1wcX2VM3YfouOtiOeKWjpgDkEMJHM=H5cx4G_b2+=eA@mail.gmail.com>
	<500d46e3.D7eggkChQE4Ot3GL%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsfNQABMyG6g3fJz5gKhWbwkruMw+QdhRV-9fRmKw7aZPg@mail.gmail.com>
Message-ID: <500d4bc2.ZqxWWe7DQdsKIifn%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> > > Maybe I don't get what nested definitions are but I thought I did. In
> > both
> > > files, I have this:
> > >
> > >      OPENSSL_1.0.0 {
> > > global:
> > > [...]
> > > };
> > >      OPENSSL_1.0.1 {
> > > global:
> > > [...]
> > > } OPENSSL_1.0.0;
> > >
> > > Is this what we are talking about ?
> >
> > This is not nested.
> >
>
> Can you explain me what nested means or give me a link to some
> documentation ?
> BTW, does that nesting thing would solve the problem ?
>
>
> >
> > This is why I pointed you to my mal files.
> >
>
> There a lot of mapfiles in schilly. I had a look at libschily-mapvers but I
> still don't get what I've done wrong by looking at this file.
> Did I miss something or do I need to look elsewhere ?

Sorry, I was looking wrong: you seem to have a chain of versions.

J?rg

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

From pfelecan at opencsw.org  Mon Jul 23 15:24:05 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Mon, 23 Jul 2012 15:24:05 +0200 (CEST)
Subject: [csw-maintainers] GAR: CONFIGURE_ARGS specific to an ISA
Message-ID: <2331a1d82d0d6a20ec28e1da190dfd48.squirrel@mail.opencsw.org>

When building a package for wich the BUILD64 flag is activated, how can I
have different content for CONFIGURE_ARGS for a specific ISA?

Concretely, building gdb with python bindings is possible only for a 32
bit version as out Python offering has no 64 bit version yet. However, gdb
built on 32 bit can debug 64 bit processes and I wish to have the python
binding available at least for that ISA (e.g. debugging Qt programs is
more easy with python scripts).

TIA


From dam at opencsw.org  Mon Jul 23 15:28:00 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 23 Jul 2012 15:28:00 +0200
Subject: [csw-maintainers] GAR: CONFIGURE_ARGS specific to an ISA
In-Reply-To: <2331a1d82d0d6a20ec28e1da190dfd48.squirrel@mail.opencsw.org>
References: <2331a1d82d0d6a20ec28e1da190dfd48.squirrel@mail.opencsw.org>
Message-ID: <A8950780-37EC-4699-8276-2FF5996A40EA@opencsw.org>

Hi Peter,

Am 23.07.2012 um 15:24 schrieb pfelecan at opencsw.org:
> When building a package for wich the BUILD64 flag is activated, how can I
> have different content for CONFIGURE_ARGS for a specific ISA?

That is easy:
  CONFIGURE_ARGS-32 = abc
  CONFIGURE_ARGS-64 = def
  CONFIGURE_ARGS += $(CONFIGURE_ARGS-$(MEMORYMODEL))
or something similar.

> Concretely, building gdb with python bindings is possible only for a 32
> bit version as out Python offering has no 64 bit version yet. However, gdb
> built on 32 bit can debug 64 bit processes and I wish to have the python
> binding available at least for that ISA (e.g. debugging Qt programs is
> more easy with python scripts).


I suggest you proceed this way until we get the tcl 8.5 with 32/64 released.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/86855e40/attachment.p7s>

From yann at pleiades.fr.eu.org  Mon Jul 23 16:30:24 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 16:30:24 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500d4bc2.ZqxWWe7DQdsKIifn%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<500d3d59.oo9hr7bmeY4SIeDo%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwse1wcX2VM3YfouOtiOeKWjpgDkEMJHM=H5cx4G_b2+=eA@mail.gmail.com>
	<500d46e3.D7eggkChQE4Ot3GL%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsfNQABMyG6g3fJz5gKhWbwkruMw+QdhRV-9fRmKw7aZPg@mail.gmail.com>
	<500d4bc2.ZqxWWe7DQdsKIifn%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwsdO1BAMqNf68=izp-s=nhvp_PMEr5EPPyvpZfQKS_Mf+A@mail.gmail.com>

Maybe an interesting mail to read:
http://mail.opensolaris.org/pipermail/opensolaris-arc/2008-September/011388.html

Yann

2012/7/23 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> > > > Maybe I don't get what nested definitions are but I thought I did. In
> > > both
> > > > files, I have this:
> > > >
> > > >      OPENSSL_1.0.0 {
> > > > global:
> > > > [...]
> > > > };
> > > >      OPENSSL_1.0.1 {
> > > > global:
> > > > [...]
> > > > } OPENSSL_1.0.0;
> > > >
> > > > Is this what we are talking about ?
> > >
> > > This is not nested.
> > >
> >
> > Can you explain me what nested means or give me a link to some
> > documentation ?
> > BTW, does that nesting thing would solve the problem ?
> >
> >
> > >
> > > This is why I pointed you to my mal files.
> > >
> >
> > There a lot of mapfiles in schilly. I had a look at libschily-mapvers
> but I
> > still don't get what I've done wrong by looking at this file.
> > Did I miss something or do I need to look elsewhere ?
>
> Sorry, I was looking wrong: you seem to have a chain of versions.
>
> J?rg
>
> --
>  EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353
> Berlin
>        js at cs.tu-berlin.de                (uni)
>        joerg.schilling at fokus.fraunhofer.de (work) Blog:
> http://schily.blogspot.com/
>  URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/bc239038/attachment-0001.html>

From pfelecan at opencsw.org  Mon Jul 23 19:52:25 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 23 Jul 2012 19:52:25 +0200
Subject: [csw-maintainers] GAR: CONFIGURE_ARGS specific to an ISA
In-Reply-To: <A8950780-37EC-4699-8276-2FF5996A40EA@opencsw.org> (Dagobert
	Michelsen's message of "Mon, 23 Jul 2012 15:28:00 +0200")
References: <2331a1d82d0d6a20ec28e1da190dfd48.squirrel@mail.opencsw.org>
	<A8950780-37EC-4699-8276-2FF5996A40EA@opencsw.org>
Message-ID: <x6vche1i1y.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 23.07.2012 um 15:24 schrieb pfelecan at opencsw.org:
>> When building a package for wich the BUILD64 flag is activated, how can I
>> have different content for CONFIGURE_ARGS for a specific ISA?
>
> That is easy:
>   CONFIGURE_ARGS-32 = abc
>   CONFIGURE_ARGS-64 = def
>   CONFIGURE_ARGS += $(CONFIGURE_ARGS-$(MEMORYMODEL))
> or something similar.

Thank you. IMHO this is good candidate for an example in the "Building
multiple ISA" documentation page. Also, documenting MEMORYMODEL as a
read only environment variable is appropriate.

>> Concretely, building gdb with python bindings is possible only for a 32
>> bit version as out Python offering has no 64 bit version yet. However, gdb
>> built on 32 bit can debug 64 bit processes and I wish to have the python
>> binding available at least for that ISA (e.g. debugging Qt programs is
>> more easy with python scripts).
>
>
> I suggest you proceed this way until we get the tcl 8.5 with 32/64 released.

Note that my variability concerns Python and not TCL; for TCL the issue
is the missing "private" headers which should be provided by the TCL
development package.
-- 
Peter

From yann at pleiades.fr.eu.org  Mon Jul 23 21:14:29 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 23 Jul 2012 21:14:29 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
Message-ID: <CAF2fwsfB-oef4758E1YdjG-1i4=0vzqtw9JQ5AX+LRjv2mgVGw@mail.gmail.com>

>
> Yes, its works at the symbol level but:
>   - the linker doesn't seem to use that information when it links a given
> symbol, it only uses it to check wether or not it can load a library,
>   - it is not registered at the symbol level in the solaris elf file (that
> could perfectly work without it, but it seems that the version is stored
> for each symbol in Linux elf files).
>

Seems I was wrong on the last point. Solaris definitely stores the version
for each symbol. You can get the information through pvs:

# pvs -ors /opt/csw/lib/libneon.so.27.2.6
[...]
/opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
SSL_set_ex_data;
/opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
SSL_write;
/opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
SSL_load_error_strings;
/opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
SSL_accept;
/opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
SSL_new;
[...]

I am very surprised that the linker doesn't use that information at runtime
to link the symbol.

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

From yann at pleiades.fr.eu.org  Tue Jul 24 00:15:17 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Tue, 24 Jul 2012 00:15:17 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwsfB-oef4758E1YdjG-1i4=0vzqtw9JQ5AX+LRjv2mgVGw@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<CAF2fwsfB-oef4758E1YdjG-1i4=0vzqtw9JQ5AX+LRjv2mgVGw@mail.gmail.com>
Message-ID: <CAF2fwseq4RFNMU7MeJxZuj=SjuLG3EV5s=AYb7SWc5zdAy=gpA@mail.gmail.com>

Oh, I think I've found something interesting.

To have the linker works as I expect, I have to enable Direct Linking. Here
are some links about it:
http://docs.oracle.com/cd/E19963-01/html/819-0690/aehzq.html
https://blogs.oracle.com/msw/entry/library_bindings_let_s_be
https://blogs.oracle.com/rie/entry/direct_binding_now_the_default

The problem is that the exemples explains how to enable direct linking when
you compile a binary against a program but it doesn't tell if it's possible
to compile a library in order to require direct linking when a program
tries to link with it.

I tried to change the mapfile like this (for openssl 0.9.8):
  OPENSSL_0.9.8 {
          global:
                  BIO_f_ssl = DIRECT;
                  BIO_new_buffer_ssl_connect = DIRECT;
                  BIO_new_ssl = DIRECT;
                  BIO_new_ssl_connect = DIRECT;
   [...]

But it didn't work so far.
I might require every library / program that link with openssl to enable
direct linking but that would be more intrusive.

I am still searching but any help is welcome.

Yann



2012/7/23 Yann Rouillard <yann at pleiades.fr.eu.org>

> Yes, its works at the symbol level but:
>>   - the linker doesn't seem to use that information when it links a given
>> symbol, it only uses it to check wether or not it can load a library,
>>   - it is not registered at the symbol level in the solaris elf file
>> (that could perfectly work without it, but it seems that the version is
>> stored for each symbol in Linux elf files).
>>
>
> Seems I was wrong on the last point. Solaris definitely stores the version
> for each symbol. You can get the information through pvs:
>
> # pvs -ors /opt/csw/lib/libneon.so.27.2.6
> [...]
> /opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
> SSL_set_ex_data;
> /opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
> SSL_write;
> /opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
> SSL_load_error_strings;
> /opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
> SSL_accept;
> /opt/csw/lib/libneon.so.27.2.6 -        libssl.so.0.9.8 (OPENSSL_0.9.8):
> SSL_new;
> [...]
>
> I am very surprised that the linker doesn't use that information at
> runtime to link the symbol.
>
> Yann
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120724/e2a78a73/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Tue Jul 24 11:29:58 2012
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Tue, 24 Jul 2012 11:29:58 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <CAF2fwseq4RFNMU7MeJxZuj=SjuLG3EV5s=AYb7SWc5zdAy=gpA@mail.gmail.com>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<CAF2fwsfB-oef4758E1YdjG-1i4=0vzqtw9JQ5AX+LRjv2mgVGw@mail.gmail.com>
	<CAF2fwseq4RFNMU7MeJxZuj=SjuLG3EV5s=AYb7SWc5zdAy=gpA@mail.gmail.com>
Message-ID: <500e6b16.PtJsqX/C4ALAOJZe%Joerg.Schilling@fokus.fraunhofer.de>

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> Oh, I think I've found something interesting.
>
> To have the linker works as I expect, I have to enable Direct Linking. Here
> are some links about it:
> http://docs.oracle.com/cd/E19963-01/html/819-0690/aehzq.html
> https://blogs.oracle.com/msw/entry/library_bindings_let_s_be
> https://blogs.oracle.com/rie/entry/direct_binding_now_the_default

Looks good.

> The problem is that the exemples explains how to enable direct linking when
> you compile a binary against a program but it doesn't tell if it's possible
> to compile a library in order to require direct linking when a program
> tries to link with it.

A library is bound by calling:

cc -o libname -dy -G -ztext -h soname -M mapfile *.o -lneeded-libs

I see no problem to add -Bdirect to this commandline.

> I tried to change the mapfile like this (for openssl 0.9.8):
>   OPENSSL_0.9.8 {
>           global:
>                   BIO_f_ssl = DIRECT;
>                   BIO_new_buffer_ssl_connect = DIRECT;
>                   BIO_new_ssl = DIRECT;
>                   BIO_new_ssl_connect = DIRECT;
>    [...]
>
> But it didn't work so far.
> I might require every library / program that link with openssl to enable
> direct linking but that would be more intrusive.

Wouldn't it be sufficient to just make the high level libs and the final binary 
use -Bdirect?

J?rg

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

From grzemba at contac-dt.de  Tue Jul 24 12:33:07 2012
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Tue, 24 Jul 2012 12:33:07 +0200
Subject: [csw-maintainers] Please review build recipe for python project xpra
Message-ID: <728094297921.500e9603@contac-dt.de>

Hi,

can some body have a look on 
 
csw/mgar/pkg/lang-python/xpra/trunk/Makefile

it works but it looks a little confused about the install target. It seems to be that the
$ python setup.py install 
step always does a build before.
Can I configure this more elegantly?

--
Carsten Grzemba
Tel.:?? +49 3677 64740
Mobil: +49 171 9749479
Fax::?? +49 3677 6474111
Email: carsten.grzemba at contac-dt.de
contac Datentechnik GmbH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120724/50c4553e/attachment-0001.html>

From maciej at opencsw.org  Tue Jul 24 21:58:26 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Tue, 24 Jul 2012 20:58:26 +0100
Subject: [csw-maintainers] Please review build recipe for python project
	xpra
In-Reply-To: <728094297921.500e9603@contac-dt.de>
References: <728094297921.500e9603@contac-dt.de>
Message-ID: <CALtRa-5gpYgKUeMAHpSCG-RCDjfv8sFNPsSaR-5B7V_V5a1XVw@mail.gmail.com>

2012/7/24 Carsten Grzemba <grzemba at contac-dt.de>:
> it works but it looks a little confused about the install target. It seems
> to be that the
> $ python setup.py install
> step always does a build before.
> Can I configure this more elegantly?

It could be the way the xpra build system is written (I haven't looked).

From dam at opencsw.org  Wed Jul 25 13:55:06 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 25 Jul 2012 13:55:06 +0200
Subject: [csw-maintainers] Please review build recipe for python project
	xpra
In-Reply-To: <CALtRa-5gpYgKUeMAHpSCG-RCDjfv8sFNPsSaR-5B7V_V5a1XVw@mail.gmail.com>
References: <728094297921.500e9603@contac-dt.de>
	<CALtRa-5gpYgKUeMAHpSCG-RCDjfv8sFNPsSaR-5B7V_V5a1XVw@mail.gmail.com>
Message-ID: <1692191B-3E44-4DAD-83B6-9E2A1A9946C5@opencsw.org>

Hi Carsten,

Am 24.07.2012 um 21:58 schrieb Maciej (Matchek) Blizi?ski:
> 2012/7/24 Carsten Grzemba <grzemba at contac-dt.de>:
>> it works but it looks a little confused about the install target. It seems
>> to be that the
>> $ python setup.py install
>> step always does a build before.
>> Can I configure this more elegantly?
> 
> It could be the way the xpra build system is written (I haven't looked).

The include should be always before the first added rule or strange things can happen.
I reordered it and made some tiny fixed. Some suggestions:
- Do not build against OpenCSW X11 as it is hazardous
- Move xpra out of lang-python, this is for python modules or things with CSWpy- prefix
  whereas xpra seems to be a normal program which just happens to be written in python.
- Try to build it on the packages installed on the build farm, if it compiles and there
  are further issues please post so I can have a look and reproduce the issue.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120725/4fe3838d/attachment.p7s>

From pfelecan at opencsw.org  Wed Jul 25 18:44:55 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 25 Jul 2012 18:44:55 +0200
Subject: [csw-maintainers] goffice take over?
Message-ID: <x6ehnz23js.fsf@opencsw.org>

I'm re-packaging gnucash by migrating from a private recipe to a GAR
based recipe.

The new version of gnucash needs the goffice package. I've seen that
some effort was spent on packaging goffice but there were never a
release. Besides, the recipe is not working. Consequently I transformed
the recipe in an operational one and now I'm approaching the finalization
for goffice 0.8.15.

If nobody is opposed by my takeover, I can release a new version this
week.

Note that, for the moment, I didn't commit the changes.
-- 
Peter

From bwalton at opencsw.org  Wed Jul 25 18:48:40 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 25 Jul 2012 12:48:40 -0400
Subject: [csw-maintainers] goffice take over?
In-Reply-To: <x6ehnz23js.fsf@opencsw.org>
References: <x6ehnz23js.fsf@opencsw.org>
Message-ID: <1343234889-sup-8072@pinkfloyd.chass.utoronto.ca>

Excerpts from Peter FELECAN's message of Wed Jul 25 12:44:55 -0400 2012:

Hi Peter,

> If nobody is opposed by my takeover, I can release a new version this
> week.

If the package was never released, I think it's fair game...especially
if you've fixed it and can get it out in short order! :)

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


From grzemba at contac-dt.de  Wed Jul 25 19:08:13 2012
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Wed, 25 Jul 2012 19:08:13 +0200
Subject: [csw-maintainers] Please review build recipe for python project
 xpra
In-Reply-To: <1692191B-3E44-4DAD-83B6-9E2A1A9946C5@opencsw.org>
References: <728094297921.500e9603@contac-dt.de>
	<CALtRa-5gpYgKUeMAHpSCG-RCDjfv8sFNPsSaR-5B7V_V5a1XVw@mail.gmail.com>
	<1692191B-3E44-4DAD-83B6-9E2A1A9946C5@opencsw.org>
Message-ID: <7400dcd148a9.5010441d@contac-dt.de>

Hi,



I will try to build without CSW X11. But xpra needs also a newer Xvfb so I guess I have to build xorg-server.?



Thanks,


Am 25.07.12, schrieb Dagobert Michelsen  <dam at opencsw.org>:
> Hi Carsten,
> 
> Am 24.07.2012 um 21:58 schrieb Maciej (Matchek) Blizi?ski:
> > 2012/7/24 Carsten Grzemba <grzemba at contac-dt.de>:
> >> it works but it looks a little confused about the install target. It seems
> >> to be that the
> >> $ python setup.py install
> >> step always does a build before.
> >> Can I configure this more elegantly?
> > 
> > It could be the way the xpra build system is written (I haven't looked).
> 
> The include should be always before the first added rule or strange things can happen.
> I reordered it and made some tiny fixed. Some suggestions:
> - Do not build against OpenCSW X11 as it is hazardous
> - Move xpra out of lang-python, this is for python modules or things with CSWpy- prefix
> ? whereas xpra seems to be a normal program which just happens to be written in python.
> - Try to build it on the packages installed on the build farm, if it compiles and there
> ? are further issues please post so I can have a look and reproduce the issue.
> 
> 
> Best regards
> 
> ? -- Dago
> 
> -- 
> "You don't become great by trying to be great, you become great by wanting to do something,
> and then doing it so hard that you become great in the process." - xkcd #896
> 
> 
> 
--
Carsten Grzemba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120725/f4913def/attachment.html>

From yann at pleiades.fr.eu.org  Wed Jul 25 19:49:09 2012
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Wed, 25 Jul 2012 19:49:09 +0200
Subject: [csw-maintainers] Symbol versioning for openssl ?
In-Reply-To: <500e6b16.PtJsqX/C4ALAOJZe%Joerg.Schilling@fokus.fraunhofer.de>
References: <CAF2fwsf5txv=1X-kRYm7jMGqRYQ+mrZJ7bDidW8zR5BUCagVKg@mail.gmail.com>
	<x6a9ys2j81.fsf@opencsw.org>
	<CAF2fwseAjTaxU0s88PtFRCkC__NWoO6N1bRpyip1QBDkwdmzpg@mail.gmail.com>
	<500c4414.+w5N92xQVE7Dvt1u%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwsc0kC00Ks1j-XUGM9DZOB2sxCQBvX1o1VCFoKhMLJWtoA@mail.gmail.com>
	<500d2b12.WfFNZLlfHdy5GmkJ%Joerg.Schilling@fokus.fraunhofer.de>
	<CAF2fwscZ9nLyyw2SbqHgvBknBmfX=WYfqCPu_Ekpm=YkHqdcMg@mail.gmail.com>
	<CAF2fwsfB-oef4758E1YdjG-1i4=0vzqtw9JQ5AX+LRjv2mgVGw@mail.gmail.com>
	<CAF2fwseq4RFNMU7MeJxZuj=SjuLG3EV5s=AYb7SWc5zdAy=gpA@mail.gmail.com>
	<500e6b16.PtJsqX/C4ALAOJZe%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <CAF2fwscsfJ5_U5egdnwcJDPGRiJoPXTAqafsBbayC+rxKCSfsw@mail.gmail.com>

2012/7/24 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> > The problem is that the exemples explains how to enable direct linking
> when
> > you compile a binary against a program but it doesn't tell if it's
> possible
> > to compile a library in order to require direct linking when a program
> > tries to link with it.
>
> A library is bound by calling:
>
> cc -o libname -dy -G -ztext -h soname -M mapfile *.o -lneeded-libs
>
> I see no problem to add -Bdirect to this commandline.
>

Yes, but I need to ask for a modification of builds of every package linked
against ssl.
That's more difficult than to only make a modification in openssl.

It might also cause some problem if direct linking should be used against
libssl but not against another lib (you can workaround this by using "-z
direct -lssl" I think that we would need to insert this).
But I think there must not be many cases where direct linking is a problem.


>
> > I tried to change the mapfile like this (for openssl 0.9.8):
> >   OPENSSL_0.9.8 {
> >           global:
> >                   BIO_f_ssl = DIRECT;
> >                   BIO_new_buffer_ssl_connect = DIRECT;
> >                   BIO_new_ssl = DIRECT;
> >                   BIO_new_ssl_connect = DIRECT;
> >    [...]
> >
> > But it didn't work so far.
> > I might require every library / program that link with openssl to enable
> > direct linking but that would be more intrusive.
>
> Wouldn't it be sufficient to just make the high level libs and the final
> binary
> use -Bdirect?
>

Well after having read what "-B direct" is, I think it would be a even
better idea to enable it for all packages in Opencsw.
That is supposed to more efficient and that would solve runtime dual
linking problem for every library without having to enable symbol
versioning (symbol versioning is a good thing but is more work, I still
have to figure how to easily manage and update this file for openssl).

I am trying to gather some more information and I will send a proposal.


BTW, a real-life test with neon linked against openssl 0.9.8 with "-B
direct" shows that it works:
# LD_DEBUG=all,detail cadaver
[...]
01175: file=/opt/csw/bin/cadaver;  add binding to:
01175:     file=/opt/csw/lib/i386/libssl.so.1.0.0   [ NEEDED ]
[...]
01175: version needed processing: file=/opt/csw/lib/libneon.so.27
01175:             file                        version
01175:             libcrypto.so.0.9.8          OPENSSL_0.9.8
01175:
01175: file=/opt/csw/lib/libneon.so.27;  add binding to:
01175:     file=/opt/csw/lib/libcrypto.so.0.9.8   [ NEEDED ]
[...]
01175: 1: binding file=/opt/csw/lib/libneon.so.27 (0xfecbe86b:0x1e86b) at
plt[349]:full to file=/opt/csw/lib/libssl.so.0.9.8 (0xfe4f2f30:0x32f30):
symbol 'SSL_load_error_strings'  (direct)
01175: 1: binding file=/opt/csw/lib/libneon.so.27 (0xfecbe870:0x1e870) at
plt[350]:full to file=/opt/csw/lib/libssl.so.0.9.8 (0xfe4fd9f0:0x3d9f0):
symbol 'SSL_library_init'  (direct)
[...]

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120725/9bea3d72/attachment-0001.html>

From bwalton at opencsw.org  Thu Jul 26 03:08:19 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Wed, 25 Jul 2012 21:08:19 -0400
Subject: [csw-maintainers] updating testing10s
Message-ID: <1343264869-sup-8228@pinkfloyd.chass.utoronto.ca>


Hi All,

FYI, I'm updating a pile of packages on testing10s.  If you'd like me
to revert anything later, let me know.

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


From ghenry at opencsw.org  Thu Jul 26 08:36:47 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Thu, 26 Jul 2012 08:36:47 +0200
Subject: [csw-maintainers] perl modules and koha project
Message-ID: <5010E57F.4020207@opencsw.org>

hello all,

anybody can take a look at my last post here:
http://lists.opencsw.org/pipermail/maintainers/2012-July/017048.html

thanks in advance for help,

gerard

From pfelecan at opencsw.org  Thu Jul 26 08:46:51 2012
From: pfelecan at opencsw.org (pfelecan at opencsw.org)
Date: Thu, 26 Jul 2012 08:46:51 +0200 (CEST)
Subject: [csw-maintainers] please review gdb's recipe; catalog and ISA issues
Message-ID: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>

I have 2 issues with the newly released gdb package:

1. only the Solaris 9 catalog was updated, as it can be observed:

    csw-upload-pkg staging/build-25.Jul.2012/gdb*
    Processing 2 file(s). Please wait.
    Uploading
'staging/build-25.Jul.2012/gdb-7.4.1,REV=2012.07.25-SunOS5.9-i386-CSW.pkg.gz'
    Uploading
'staging/build-25.Jul.2012/gdb-7.4.1,REV=2012.07.25-SunOS5.9-sparc-CSW.pkg.gz'
    Checking 1 package(s) against catalog unstable sparc SunOS5.9
    Checking 1 package(s) against catalog unstable i386 SunOS5.9
    All checks successful. Proceeding.
    Inserting gdb (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
    Inserting gdb (sparc SunOS5.9) into catalog unstable sparc SunOS5.9

2. this being my first GAR multiple ISA package I am a little bit lost:

    For example, in the i386 package, there are binaries in /opt/csw/bin
    and in /opt/csw/bin/amd64. However, they are "regular" binaries, i.e.,
    without a mechanism to select the corresponding ISA when executed.


Please review the recipe as there are possible issues which explain the
above.

TIA


From bonivart at opencsw.org  Thu Jul 26 09:45:31 2012
From: bonivart at opencsw.org (Peter Bonivart)
Date: Thu, 26 Jul 2012 09:45:31 +0200
Subject: [csw-maintainers] perl modules and koha project
In-Reply-To: <5010E57F.4020207@opencsw.org>
References: <5010E57F.4020207@opencsw.org>
Message-ID: <CABY0g1WqoPTpmS42B2oTzBOqtO-XNV00QymA++se6ZZ6B5UzRQ@mail.gmail.com>

On Thu, Jul 26, 2012 at 8:36 AM, Gerard Henry <ghenry at opencsw.org> wrote:
> hello all,
>
> anybody can take a look at my last post here:
> http://lists.opencsw.org/pipermail/maintainers/2012-July/017048.html
>
> thanks in advance for help,

The latest release on koha.org is 4.10.05, that's why I used it and it
doesn't have that script by the way. You're now posting another url
with an older release, couldn't you have corrected that earlier before
I put in like 25 hours doing Perl modules for the wrong version?

From maciej at opencsw.org  Thu Jul 26 10:13:31 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 26 Jul 2012 09:13:31 +0100
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
Message-ID: <CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>

2012/7/26 <pfelecan at opencsw.org>
>
> 1. only the Solaris 9 catalog was updated, as it can be observed:
>
>     csw-upload-pkg staging/build-25.Jul.2012/gdb*
>     Processing 2 file(s). Please wait.
>     Uploading
>
> 'staging/build-25.Jul.2012/gdb-7.4.1,REV=2012.07.25-SunOS5.9-i386-CSW.pkg.gz'
>     Uploading
>
> 'staging/build-25.Jul.2012/gdb-7.4.1,REV=2012.07.25-SunOS5.9-sparc-CSW.pkg.gz'
>     Checking 1 package(s) against catalog unstable sparc SunOS5.9
>     Checking 1 package(s) against catalog unstable i386 SunOS5.9
>     All checks successful. Proceeding.
>     Inserting gdb (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
>     Inserting gdb (sparc SunOS5.9) into catalog unstable sparc SunOS5.9

Are there different versions of gdb in the 5.9 and 5.10 catalogs?

From ghenry at opencsw.org  Thu Jul 26 12:27:35 2012
From: ghenry at opencsw.org (Gerard Henry)
Date: Thu, 26 Jul 2012 12:27:35 +0200
Subject: [csw-maintainers] perl modules and koha project
In-Reply-To: <CABY0g1WqoPTpmS42B2oTzBOqtO-XNV00QymA++se6ZZ6B5UzRQ@mail.gmail.com>
References: <5010E57F.4020207@opencsw.org>
	<CABY0g1WqoPTpmS42B2oTzBOqtO-XNV00QymA++se6ZZ6B5UzRQ@mail.gmail.com>
Message-ID: <50111B97.5030006@opencsw.org>

On 07/26/12 09:45 AM, Peter Bonivart wrote:

> The latest release on koha.org is 4.10.05, that's why I used it and it

ok i understand the misunderstanding, you look at:
http://www.koha.org/

and i (and others deploying koha):
http://koha-community.org/

the first one is driven by LibLime, not the community. Sorry to haven't 
see this weeks ago.
For me it'll be better to:
"to find missing packages is to use a perl
script bundled with koha, called koha_perl_deps.pl. and documented here:
http://perldoc.koha-community.org/koha_perl_deps.html

and interpret the result of this script to know what package needs to be 
available."

gerard





From dam at opencsw.org  Thu Jul 26 14:39:45 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jul 2012 14:39:45 +0200
Subject: [csw-maintainers] Please review build recipe for python project
	xpra
In-Reply-To: <7400dcd148a9.5010441d@contac-dt.de>
References: <728094297921.500e9603@contac-dt.de>
	<CALtRa-5gpYgKUeMAHpSCG-RCDjfv8sFNPsSaR-5B7V_V5a1XVw@mail.gmail.com>
	<1692191B-3E44-4DAD-83B6-9E2A1A9946C5@opencsw.org>
	<7400dcd148a9.5010441d@contac-dt.de>
Message-ID: <3D6BF63E-6EC2-4F86-9DF2-DBC7CEC08D2F@opencsw.org>

Hi Carsten,

Am 25.07.2012 um 19:08 schrieb Carsten Grzemba:
> I will try to build without CSW X11. But xpra needs also a newer Xvfb so I guess I have to build xorg-server.?

We tried that some time ago but it didn't prove useful as by the time you link to
just CSW X11 which lacks some acceleration features. Is it really not possible to
use the lib from Solaris 10? Or just use this one lib form our X11?


Best regards

  -- Dago

> 
> Thanks,
> 
> 
> Am 25.07.12, schrieb Dagobert Michelsen <dam at opencsw.org>:
>> 
>> Hi Carsten,
>> 
>> Am 24.07.2012 um 21:58 schrieb Maciej (Matchek) Blizi?ski:
>> > 2012/7/24 Carsten Grzemba <grzemba at contac-dt.de>:
>> >> it works but it looks a little confused about the install target. It seems
>> >> to be that the
>> >> $ python setup.py install
>> >> step always does a build before.
>> >> Can I configure this more elegantly?
>> > 
>> > It could be the way the xpra build system is written (I haven't looked).
>> 
>> The include should be always before the first added rule or strange things can happen.
>> I reordered it and made some tiny fixed. Some suggestions:
>> - Do not build against OpenCSW X11 as it is hazardous
>> - Move xpra out of lang-python, this is for python modules or things with CSWpy- prefix
>>   whereas xpra seems to be a normal program which just happens to be written in python.
>> - Try to build it on the packages installed on the build farm, if it compiles and there
>>   are further issues please post so I can have a look and reproduce the issue.
>> 
>> 
>> Best regards
>> 
>>   -- Dago
>> 
>> -- 
>> "You don't become great by trying to be great, you become great by wanting to do something,
>> and then doing it so hard that you become great in the process." - xkcd #896
>> 
> --
> Carsten Grzemba
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120726/6e86f48a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120726/6e86f48a/attachment-0001.p7s>

From dam at opencsw.org  Thu Jul 26 14:42:54 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 26 Jul 2012 14:42:54 +0200
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
Message-ID: <F67EE976-7820-4E30-808F-54B097B9B33A@opencsw.org>

Hi Peter,

Am 26.07.2012 um 08:46 schrieb pfelecan at opencsw.org:
> I have 2 issues with the newly released gdb package:
?
> 2. this being my first GAR multiple ISA package I am a little bit lost:
> 
>    For example, in the i386 package, there are binaries in /opt/csw/bin
>    and in /opt/csw/bin/amd64. However, they are "regular" binaries, i.e.,
>    without a mechanism to select the corresponding ISA when executed.

Yes, the default mode when using extra ISAs is manual selection of binaries.
You can use
  ISAEXEC = 1
to turn on automatic execution of the "best" binary, here all binaries are
confined to their arch subdirectories and the one in bin/sbin/libexec is
a hardlink to isaexec.

Other options like alternatives have also been discussed, but are unsuitable
most of the time.


Best regards

  -- Dago

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2351 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120726/2c413d97/attachment.p7s>

From bwalton at opencsw.org  Thu Jul 26 16:07:38 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 26 Jul 2012 10:07:38 -0400
Subject: [csw-maintainers] cswinitsmf and alternate root's
Message-ID: <1343311552-sup-4985@pinkfloyd.chass.utoronto.ca>


Hi All,

I was updating some csw packages in an alternate boot environment last
night and hit a snag with services handled by cswinitsmf.  It was
updating service states in the live boot environment, not the
alternate.

I think the following patch addresses this, but I'd appreciate more
eyes on it.

Thanks
-Ben

Index: CSWcswclassutils.i.cswinitsmf
===================================================================
--- CSWcswclassutils.i.cswinitsmf	(revision 18857)
+++ CSWcswclassutils.i.cswinitsmf	(working copy)
@@ -23,6 +23,7 @@
 # 2009-08-10 Fix autoenable bug (Bug ID 0003785)
 # 2010-10-25 Fix grep bug in FMRI 'dot in name' detection (Bug ID 0004588)
 # 2011-04-21 Read absolute state value instead of defaulting to enabled
+# 2012-07-26 Better handle -R (alt root) for BE patching, etc. -bw
 
 DEBUG=		# clear to disable debug, set to anything to enable
 SVCDIR=/var/opt/csw/svc
@@ -110,11 +111,11 @@
     testpath=$SVCDIR/manifest
     for i in `echo $FMRI | sed 's/\// /g'`; do
       testpath=$testpath/$i
-      if [ ! -d $testpath ]; then
+      if [ ! -d $PKG_INSTALL_ROOT/$testpath ]; then
         echo Creating $testpath ...
-        /usr/bin/mkdir $testpath
-        /usr/bin/chown root:bin $testpath
-        /usr/bin/chmod 755 $testpath
+        /usr/bin/mkdir $PKG_INSTALL_ROOT/$testpath
+        /usr/bin/chown root:bin $PKG_INSTALL_ROOT/$testpath
+        /usr/bin/chmod 755 $PKG_INSTALL_ROOT/$testpath
         /usr/sbin/installf -c cswinitsmf $PKGINST $testpath d 755 root bin
       fi
     done
@@ -122,10 +123,10 @@
       echo FMRI: $FMRI
     fi
     echo Creating service script in $SVCDIR/method/svc-$service ...
-    /usr/bin/ln -s $dest $SVCDIR/method/svc-$service
+    /usr/bin/ln -s $dest $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service
     /usr/sbin/installf -c cswinitsmf $PKGINST $SVCDIR/method/svc-$service=$dest s
-    /usr/bin/chmod 755 $SVCDIR/method/svc-$service
-    /usr/bin/chown root:bin $SVCDIR/method/svc-$service
+    /usr/bin/chmod 755 $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service
+    /usr/bin/chown root:bin $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service
 
     MANIFEST=
     if [ "`grep '^#MANIFEST' $dest`" ]; then
@@ -136,7 +137,7 @@
       echo Creating manifest ...
       # Add first part of manifest
       MANIFEST=$SVCDIR/manifest/$FMRI/$service.xml
-      cat > $MANIFEST << EOF
+      cat > $PKG_INSTALL_ROOT/$MANIFEST << EOF
 <?xml version='1.0'?>
 <!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
 <!--
@@ -185,8 +186,8 @@
 EOF
 
       # Add restart option to manifest if service script supports it
-      if [ "`/usr/bin/egrep 'restart.?\)' $SVCDIR/method/svc-$service`" ]; then
-        cat >> $MANIFEST << EOF
+      if [ "`/usr/bin/egrep 'restart.?\)' $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service`" ]; then
+        cat >> $PKG_INSTALL_ROOT/$MANIFEST << EOF
   <exec_method
     type='method'
     name='restart'
@@ -198,8 +199,8 @@
       fi
 
       # Add refresh option to manifest if service script supports it
-      if [ "`/usr/bin/egrep 'refresh.?\)' $SVCDIR/method/svc-$service`" ]; then
-        cat >> $MANIFEST << EOF
+      if [ "`/usr/bin/egrep 'refresh.?\)' $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service`" ]; then
+        cat >> $PKG_INSTALL_ROOT/$MANIFEST << EOF
   <exec_method
     type='method'
     name='refresh'
@@ -211,14 +212,14 @@
       fi
 
       # Add last part of manifest
-      cat >> $MANIFEST << EOF
+      cat >> $PKG_INSTALL_ROOT/$MANIFEST << EOF
 </service>
 
 </service_bundle>
 EOF
       /usr/sbin/installf -c cswinitsmf $PKGINST $MANIFEST f 644 root bin
-      /usr/bin/chmod 644 $MANIFEST
-      /usr/bin/chown root:bin $MANIFEST
+      /usr/bin/chmod 644 $PKG_INSTALL_ROOT/$MANIFEST
+      /usr/bin/chown root:bin $PKG_INSTALL_ROOT/$MANIFEST
     else
       # Custom manifest
       echo Using custom manifest ...
@@ -230,8 +231,10 @@
 
     # Register with SMF
     echo Configuring service in SMF ...
-    /usr/sbin/svccfg import $MANIFEST > /dev/null 2>&1
-    /usr/sbin/svcadm disable svc:/$FMRI/$service > /dev/null 2>&1
+    chroot ${PKG_INSTALL_ROOT:-/} /usr/sbin/svccfg import $MANIFEST > /dev/null 2>&1
+    if [ "${PKG_INSTALL_ROOT:-/}" != "/" ]; then
+	/usr/sbin/svcadm disable svc:/$FMRI/$service > /dev/null 2>&1
+    fi
     echo $PKGINST is using Service Management Facility. The FMRI is svc:/$FMRI/$service:default
 
     # Start service
@@ -244,7 +247,7 @@
     # enable the service if it was enabled before, OR if $daemon = yes and AUTOENABLE is set
     # previous SMF state always takes precedence
     # note: autoenable_daemons and autoenable_$service controls $daemon, $AUTOENABLE is set by the package itself
-    if [ "$SMF_STATE" = "enabled" ] || [ "$daemon" = "yes" -a "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then
+    if [ "$SMF_STATE" = "enabled" ] || [ "$daemon" = "yes" -a "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" -a "${PKG_INSTALL_ROOT:-/}" = "/" ]; then
       echo "Clearing svc:/$FMRI/$service in case it's in the maintenance state..."
       /usr/sbin/svcadm clear svc:/$FMRI/$service > /dev/null 2>&1
       echo Enabling svc:/$FMRI/$service ...
@@ -257,7 +260,7 @@
 
     # Create link to /etc/init.d
     echo /etc/init.d/$service
-    /usr/bin/ln -s $dest /etc/init.d/$service
+    /usr/bin/ln -s $dest ${PKG_INSTALL_ROOT}/etc/init.d/$service
     /usr/sbin/installf -c cswinitsmf $PKGINST /etc/init.d/$service=$dest s
 
     # Create rc-symlinks if enabled
@@ -301,12 +304,12 @@
       for i in $RC_KLEV; do
         echo /etc/rc$i.d/K$RC_KNUM$service
         /usr/sbin/installf -c cswinitsmf $PKGINST /etc/rc$i.d/K$RC_KNUM$service=/etc/init.d/$service s
-        /bin/ln -s /etc/init.d/$service /etc/rc$i.d/K$RC_KNUM$service
+        /bin/ln -s /etc/init.d/$service ${PKG_INSTALL_ROOT}/etc/rc$i.d/K$RC_KNUM$service
       done
       for i in $RC_SLEV; do
         echo /etc/rc$i.d/S$RC_SNUM$service
         /usr/sbin/installf -c cswinitsmf $PKGINST /etc/rc$i.d/S$RC_SNUM$service=/etc/init.d/$service s
-        /bin/ln -s /etc/init.d/$service /etc/rc$i.d/S$RC_SNUM$service
+        /bin/ln -s /etc/init.d/$service ${PKG_INSTALL_ROOT}/etc/rc$i.d/S$RC_SNUM$service
       done
 
       # Start service
@@ -317,8 +320,10 @@
       if [ "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then
         echo Starting $service ...
         # fix permissions temporarily since 644 is used until verification
-        /usr/bin/chmod 744 /etc/init.d/$service
-        /etc/init.d/$service start > /dev/null 2>&1
+        /usr/bin/chmod 744 ${PKG_INSTALL_ROOT}/etc/init.d/$service
+	if [ "${PKG_INSTALL_ROOT:-/}" = "/" ]; then
+            /etc/init.d/$service start > /dev/null 2>&1
+	fi
       fi
     fi
   fi
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302


From jh at opencsw.org  Thu Jul 26 16:19:10 2012
From: jh at opencsw.org (Jan Holzhueter)
Date: Thu, 26 Jul 2012 16:19:10 +0200
Subject: [csw-maintainers] cswinitsmf and alternate root's
In-Reply-To: <1343311552-sup-4985@pinkfloyd.chass.utoronto.ca>
References: <1343311552-sup-4985@pinkfloyd.chass.utoronto.ca>
Message-ID: <501151DE.2040904@opencsw.org>

Hi,
see inline:

Am 26.07.12 16:07, schrieb Ben Walton:

> Index: CSWcswclassutils.i.cswinitsmf
> ===================================================================
> --- CSWcswclassutils.i.cswinitsmf	(revision 18857)
> +++ CSWcswclassutils.i.cswinitsmf	(working copy)
> @@ -23,6 +23,7 @@
>  # 2009-08-10 Fix autoenable bug (Bug ID 0003785)
>  # 2010-10-25 Fix grep bug in FMRI 'dot in name' detection (Bug ID 0004588)
>  # 2011-04-21 Read absolute state value instead of defaulting to enabled
> +# 2012-07-26 Better handle -R (alt root) for BE patching, etc. -bw
>  
>  DEBUG=		# clear to disable debug, set to anything to enable
>  SVCDIR=/var/opt/csw/svc
> @@ -110,11 +111,11 @@
>      testpath=$SVCDIR/manifest
>      for i in `echo $FMRI | sed 's/\// /g'`; do
>        testpath=$testpath/$i
> -      if [ ! -d $testpath ]; then
> +      if [ ! -d $PKG_INSTALL_ROOT/$testpath ]; then
>          echo Creating $testpath ...
> -        /usr/bin/mkdir $testpath
> -        /usr/bin/chown root:bin $testpath
> -        /usr/bin/chmod 755 $testpath
> +        /usr/bin/mkdir $PKG_INSTALL_ROOT/$testpath
> +        /usr/bin/chown root:bin $PKG_INSTALL_ROOT/$testpath
> +        /usr/bin/chmod 755 $PKG_INSTALL_ROOT/$testpath
>          /usr/sbin/installf -c cswinitsmf $PKGINST $testpath d 755 root bin
>        fi
>      done
> @@ -122,10 +123,10 @@
>        echo FMRI: $FMRI
>      fi
>      echo Creating service script in $SVCDIR/method/svc-$service ...
> -    /usr/bin/ln -s $dest $SVCDIR/method/svc-$service
> +    /usr/bin/ln -s $dest $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service
>      /usr/sbin/installf -c cswinitsmf $PKGINST $SVCDIR/method/svc-$service=$dest s
> -    /usr/bin/chmod 755 $SVCDIR/method/svc-$service
> -    /usr/bin/chown root:bin $SVCDIR/method/svc-$service
> +    /usr/bin/chmod 755 $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service
> +    /usr/bin/chown root:bin $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service
>  
>      MANIFEST=
>      if [ "`grep '^#MANIFEST' $dest`" ]; then
> @@ -136,7 +137,7 @@
>        echo Creating manifest ...
>        # Add first part of manifest
>        MANIFEST=$SVCDIR/manifest/$FMRI/$service.xml
> -      cat > $MANIFEST << EOF
> +      cat > $PKG_INSTALL_ROOT/$MANIFEST << EOF
>  <?xml version='1.0'?>
>  <!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
>  <!--
> @@ -185,8 +186,8 @@
>  EOF
>  
>        # Add restart option to manifest if service script supports it
> -      if [ "`/usr/bin/egrep 'restart.?\)' $SVCDIR/method/svc-$service`" ]; then
> -        cat >> $MANIFEST << EOF
> +      if [ "`/usr/bin/egrep 'restart.?\)' $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service`" ]; then
> +        cat >> $PKG_INSTALL_ROOT/$MANIFEST << EOF
>    <exec_method
>      type='method'
>      name='restart'
> @@ -198,8 +199,8 @@
>        fi
>  
>        # Add refresh option to manifest if service script supports it
> -      if [ "`/usr/bin/egrep 'refresh.?\)' $SVCDIR/method/svc-$service`" ]; then
> -        cat >> $MANIFEST << EOF
> +      if [ "`/usr/bin/egrep 'refresh.?\)' $PKG_INSTALL_ROOT/$SVCDIR/method/svc-$service`" ]; then
> +        cat >> $PKG_INSTALL_ROOT/$MANIFEST << EOF
>    <exec_method
>      type='method'
>      name='refresh'
> @@ -211,14 +212,14 @@
>        fi
>  
>        # Add last part of manifest
> -      cat >> $MANIFEST << EOF
> +      cat >> $PKG_INSTALL_ROOT/$MANIFEST << EOF
>  </service>
>  
>  </service_bundle>
>  EOF
>        /usr/sbin/installf -c cswinitsmf $PKGINST $MANIFEST f 644 root bin
> -      /usr/bin/chmod 644 $MANIFEST
> -      /usr/bin/chown root:bin $MANIFEST
> +      /usr/bin/chmod 644 $PKG_INSTALL_ROOT/$MANIFEST
> +      /usr/bin/chown root:bin $PKG_INSTALL_ROOT/$MANIFEST
>      else
>        # Custom manifest
>        echo Using custom manifest ...
> @@ -230,8 +231,10 @@
>  
>      # Register with SMF
>      echo Configuring service in SMF ...
> -    /usr/sbin/svccfg import $MANIFEST > /dev/null 2>&1
> -    /usr/sbin/svcadm disable svc:/$FMRI/$service > /dev/null 2>&1
> +    chroot ${PKG_INSTALL_ROOT:-/} /usr/sbin/svccfg import $MANIFEST > /dev/null 2>&1
> +    if [ "${PKG_INSTALL_ROOT:-/}" != "/" ]; then
> +	/usr/sbin/svcadm disable svc:/$FMRI/$service > /dev/null 2>&1
> +    fi
>      echo $PKGINST is using Service Management Facility. The FMRI is svc:/$FMRI/$service:default


I'm not sure if this works.
Can you import a manifest without the smf service running the in BE?

Greetings
Jan



From bwalton at opencsw.org  Thu Jul 26 16:30:52 2012
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 26 Jul 2012 10:30:52 -0400
Subject: [csw-maintainers] cswinitsmf and alternate root's
In-Reply-To: <501151DE.2040904@opencsw.org>
References: <1343311552-sup-4985@pinkfloyd.chass.utoronto.ca>
	<501151DE.2040904@opencsw.org>
Message-ID: <1343313003-sup-4870@pinkfloyd.chass.utoronto.ca>

Excerpts from Jan Holzhueter's message of Thu Jul 26 10:19:10 -0400 2012:

Hi Jan,

> I'm not sure if this works.
> Can you import a manifest without the smf service running the in BE?

That's a good point.  In my head, I thought the import would be ok,
but the state toggle might not...I'll do some reading on that.

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


From pfelecan at opencsw.org  Thu Jul 26 20:06:21 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Thu, 26 Jul 2012 20:06:21 +0200
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu,
	26 Jul 2012 09:13:31 +0100")
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
	<CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>
Message-ID: <x6394e1joi.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> 2012/7/26 <pfelecan at opencsw.org>
>>
>> 1. only the Solaris 9 catalog was updated, as it can be observed:
>>
>>     csw-upload-pkg staging/build-25.Jul.2012/gdb*
>>     Processing 2 file(s). Please wait.
>>     Uploading
>>
>> 'staging/build-25.Jul.2012/gdb-7.4.1,REV=2012.07.25-SunOS5.9-i386-CSW.pkg.gz'
>>     Uploading
>>
>> 'staging/build-25.Jul.2012/gdb-7.4.1,REV=2012.07.25-SunOS5.9-sparc-CSW.pkg.gz'
>>     Checking 1 package(s) against catalog unstable sparc SunOS5.9
>>     Checking 1 package(s) against catalog unstable i386 SunOS5.9
>>     All checks successful. Proceeding.
>>     Inserting gdb (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
>>     Inserting gdb (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
>
> Are there different versions of gdb in the 5.9 and 5.10 catalogs?

The current catalog for 5.10 contains:

gdb 7.2,REV=2011.01.21 CSWgdb
gdb-7.2,REV=2011.01.21-SunOS5.10-i386-CSW.pkg.gz
c989477b46f213cd3cad5f8bc94a2afd 7875885

The current catalog for 5.9 contains:

gdb 7.4.1,REV=2012.07.25 CSWgdb
gdb-7.4.1,REV=2012.07.25-SunOS5.9-i386-CSW.pkg.gz
9f59919acb1431599da962e7a71648f8 8203950

The previous versions contained for all platforms:

gdb 7.2,REV=2011.01.21 CSWgdb

-- 
Peter

From pfelecan at opencsw.org  Thu Jul 26 20:07:28 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Thu, 26 Jul 2012 20:07:28 +0200
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <F67EE976-7820-4E30-808F-54B097B9B33A@opencsw.org> (Dagobert
	Michelsen's message of "Thu, 26 Jul 2012 14:42:54 +0200")
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
	<F67EE976-7820-4E30-808F-54B097B9B33A@opencsw.org>
Message-ID: <x6y5m6z99b.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Am 26.07.2012 um 08:46 schrieb pfelecan at opencsw.org:
>> I have 2 issues with the newly released gdb package:
> ?
>> 2. this being my first GAR multiple ISA package I am a little bit lost:
>> 
>>    For example, in the i386 package, there are binaries in /opt/csw/bin
>>    and in /opt/csw/bin/amd64. However, they are "regular" binaries, i.e.,
>>    without a mechanism to select the corresponding ISA when executed.
>
> Yes, the default mode when using extra ISAs is manual selection of binaries.
> You can use
>   ISAEXEC = 1
> to turn on automatic execution of the "best" binary, here all binaries are
> confined to their arch subdirectories and the one in bin/sbin/libexec is
> a hardlink to isaexec.
>
> Other options like alternatives have also been discussed, but are unsuitable
> most of the time.

Thank you.

I'm choosing the ISAEXEC = 1 path as it's similar with what I delivered
in the previous package.

-- 
Peter

From maciej at opencsw.org  Thu Jul 26 20:42:56 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 26 Jul 2012 19:42:56 +0100
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <x6394e1joi.fsf@opencsw.org>
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
	<CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>
	<x6394e1joi.fsf@opencsw.org>
Message-ID: <CALtRa-4=gZsdqi7ymqpk59nDU0ataY1dKUkSYd=+kfpRw920ZA@mail.gmail.com>

2012/7/26 Peter FELECAN <pfelecan at opencsw.org>
>
> The previous versions contained for all platforms:
>
> gdb 7.2,REV=2011.01.21 CSWgdb

The version might be the same, but the svr4 packages could be
different. csw-upload-pkg tries to keep things constant: if they were
the same, they stay the same. If they were different, they stay
different.

I think the dublin catalog contains the previous state of the unstable
catalog. You can check the md5 sums using the rest interface, e.g.:

function get_md5 {
curl -s \
  "http://buildfarm.opencsw.org/pkgdb/rest/catalogs/$2/$3/$4/catalognames/$1/" \
  | python -c "import json, sys; print json.loads(sys.stdin.read())['md5_sum']"
}

for arch in sparc i386; do
  for os_rel in 9 10 11; do
    printf "%06s %02s " "$arch" "$os_rel"
    get_md5 gdb dublin "$arch" "SunOS5.$os_rel"
  done
done

If you run this script, you'll get:

 sparc  9 7971e31461b53638d7813407fab4765b
 sparc 10 09cccf8097e982dadbd717910963e378
 sparc 11 09cccf8097e982dadbd717910963e378
  i386  9 538eadd41b92393c0a65bf320defb3eb
  i386 10 c989477b46f213cd3cad5f8bc94a2afd
  i386 11 c989477b46f213cd3cad5f8bc94a2afd

Which shows that versions in the 5.9 catalogs are different from
versions in the 5.10 catalog.

If the behavior of csw-upload-pkg was surprising, maybe it was because
of too much magic? I think we talked about this, and the suggestions
from maintainers were to have csw-upload-pkg do what it's currently
doing.

Maciej

From grzemba at contac-dt.de  Fri Jul 27 09:32:50 2012
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Fri, 27 Jul 2012 09:32:50 +0200
Subject: [csw-maintainers] Please review build recipe for python project
 xpra, X11 libs
In-Reply-To: <7420c3455741.501243eb@contac-dt.de>
References: <7420c3455741.501243eb@contac-dt.de>
Message-ID: <74209f812d23.50126042@contac-dt.de>

Hi Dago,

Am 26.07.12, schrieb Dagobert Michelsen  <dam at opencsw.org>:
> 
> 
> 
> 
> Hi Carsten,
> 
> Am 25.07.2012 um 19:08 schrieb Carsten Grzemba:
> 
> > I will try to build without CSW X11. But xpra needs also a newer Xvfb so I guess I have to build xorg-server.?
> > 
> 
> 
> We tried that some time ago but it didn't prove useful as by the time you link to
> just CSW X11 which lacks some acceleration features. Is it really not possible to
> use the lib from Solaris 10? Or just use this one lib form our X11?
> 
> 
> 
> 
> 
> 
Do you mean only libX11 or also all the others:

BUILD_DEP_PKGS += CSWlibxtstdevel
BUILD_DEP_PKGS += CSWlibxfixesdevel
BUILD_DEP_PKGS += CSWlibxcompositedev
BUILD_DEP_PKGS += CSWlibxdamagedevel
BUILD_DEP_PKGS += CSWlibxrandrdevel
BUILD_DEP_PKGS += CSWx11recordproto
BUILD_DEP_PKGS += CSWlibxextdevel
BUILD_DEP_PKGS += CSWx11fixesproto
BUILD_DEP_PKGS += CSWx11compositeproto
BUILD_DEP_PKGS += CSWx11damageproto
BUILD_DEP_PKGS += CSWx11randrproto

There are a lot of which is not contained in Solaris10 (at least missing pc-files).


> 
> 
> 
> 
> 
> 
> 
> 
> Best regards
> 
> 
> ? -- Dago
> 
> 
> > 
> > 
> > 
> > Thanks,
> > 
> > 
> > Am 25.07.12, schrieb Dagobert Michelsen  <dam at opencsw.org>:
> > > Hi Carsten,
> > > 
> > > Am 24.07.2012 um 21:58 schrieb Maciej (Matchek) Blizi?ski:
> > > > 2012/7/24 Carsten Grzemba <grzemba at contac-dt.de>:
> > > >> it works but it looks a little confused about the install target. It seems
> > > >> to be that the
> > > >> $ python setup.py install
> > > >> step always does a build before.
> > > >> Can I configure this more elegantly?
> > > > 
> > > > It could be the way the xpra build system is written (I haven't looked).
> > > 
> > > The include should be always before the first added rule or strange things can happen.
> > > I reordered it and made some tiny fixed. Some suggestions:
> > > - Do not build against OpenCSW X11 as it is hazardous
> > > - Move xpra out of lang-python, this is for python modules or things with CSWpy- prefix
> > > ? whereas xpra seems to be a normal program which just happens to be written in python.
> > > - Try to build it on the packages installed on the build farm, if it compiles and there
> > > ? are further issues please post so I can have a look and reproduce the issue.
> > > 
> > > 
> > > Best regards
> > > 
> > > ? -- Dago
> > > 
> > > -- 
> > > "You don't become great by trying to be great, you become great by wanting to do something,
> > > and then doing it so hard that you become great in the process." - xkcd #896
> > > 
> > > 
> > > 
> > --
> > Carsten Grzemba
> > 
> > _______________________________________________
> > maintainers mailing list
> > maintainers at lists.opencsw.org
> > https://lists.opencsw.org/mailman/listinfo/maintainers
> > .:: This mailing list's archive is public. ::.
> 
> 
> 
> --?
> "You don't become great by trying to be great, you become great by wanting to?do something,
> and then doing it so hard that you become great in the process." - xkcd #896
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
--
Carsten Grzemba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120727/014c3fbf/attachment.html>

From pfelecan at opencsw.org  Fri Jul 27 18:48:01 2012
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 27 Jul 2012 18:48:01 +0200
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <CALtRa-4=gZsdqi7ymqpk59nDU0ataY1dKUkSYd=+kfpRw920ZA@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu,
	26 Jul 2012 19:42:56 +0100")
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
	<CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>
	<x6394e1joi.fsf@opencsw.org>
	<CALtRa-4=gZsdqi7ymqpk59nDU0ataY1dKUkSYd=+kfpRw920ZA@mail.gmail.com>
Message-ID: <x6txwtywu6.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> writes:

> Which shows that versions in the 5.9 catalogs are different from
> versions in the 5.10 catalog.

Yes, they were different in content as I provided, manually, 32 and 64
bit with isaexec. 

> If the behavior of csw-upload-pkg was surprising, maybe it was because
> of too much magic? I think we talked about this, and the suggestions
> from maintainers were to have csw-upload-pkg do what it's currently
> doing.

Maybe. Anyhow, I succeeded to insert the new packages in all the
relevant catalogs by doing:

csw-upload-pkg staging/build-27.Jul.2012/gdb-7.4.1*
csw-upload-pkg --os-release=5.10 staging/build-27.Jul.2012/gdb-7.4.1*
csw-upload-pkg --os-release=5.11 staging/build-27.Jul.2012/gdb-7.4.1*

Et voil?
-- 
Peter

From maciej at opencsw.org  Fri Jul 27 19:43:41 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 27 Jul 2012 18:43:41 +0100
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <x6txwtywu6.fsf@opencsw.org>
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
	<CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>
	<x6394e1joi.fsf@opencsw.org>
	<CALtRa-4=gZsdqi7ymqpk59nDU0ataY1dKUkSYd=+kfpRw920ZA@mail.gmail.com>
	<x6txwtywu6.fsf@opencsw.org>
Message-ID: <CALtRa-61C0kZu4wZkDkZDWMV7=Le588SLTAC+Z=J+jMxjFg29w@mail.gmail.com>

2012/7/27 Peter FELECAN <pfelecan at opencsw.org>:
>> If the behavior of csw-upload-pkg was surprising, maybe it was because
>> of too much magic? I think we talked about this, and the suggestions
>> from maintainers were to have csw-upload-pkg do what it's currently
>> doing.
>
> Maybe.

I managed to dig out the relevant e-mail, but it was off the list, so
I can't link to it, unfortunately.

> Anyhow, I succeeded to insert the new packages in all the
> relevant catalogs by doing:
>
> csw-upload-pkg staging/build-27.Jul.2012/gdb-7.4.1*
> csw-upload-pkg --os-release=5.10 staging/build-27.Jul.2012/gdb-7.4.1*
> csw-upload-pkg --os-release=5.11 staging/build-27.Jul.2012/gdb-7.4.1*

Yes, this is the way to change the 5.9/5.10 state between
different/same packages.

Maciej

From maciej at opencsw.org  Fri Jul 27 20:31:18 2012
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 27 Jul 2012 19:31:18 +0100
Subject: [csw-maintainers] please review gdb's recipe;
	catalog and ISA issues
In-Reply-To: <CALtRa-61C0kZu4wZkDkZDWMV7=Le588SLTAC+Z=J+jMxjFg29w@mail.gmail.com>
References: <762f7bde05fa4440254b00579a35a19f.squirrel@mail.opencsw.org>
	<CALtRa-42VxuaV_qyLeYUxf=fOCjHjLq102TQE0UW76Q9ZMrJFg@mail.gmail.com>
	<x6394e1joi.fsf@opencsw.org>
	<CALtRa-4=gZsdqi7ymqpk59nDU0ataY1dKUkSYd=+kfpRw920ZA@mail.gmail.com>
	<x6txwtywu6.fsf@opencsw.org>
	<CALtRa-61C0kZu4wZkDkZDWMV7=Le588SLTAC+Z=J+jMxjFg29w@mail.gmail.com>
Message-ID: <CALtRa-4OEWKOSe_TaicYny7dkxQFH=DHm1Z741HipoULcA4gMg@mail.gmail.com>

csw-upload-pkg needs to provide feedback to the user: why is it doing
one thing and not the other. Especially with cases where 5.9 and 5.10
catalog contain a package with the same version and release date, but
built on different OS versions.

Somewhere in this function:

http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/csw_upload_pkg.py#L197

...there needs to be code added to report what's happening.

Maciej

From ja at opencsw.org  Sun Jul 29 21:17:20 2012
From: ja at opencsw.org (Juergen Arndt)
Date: Sun, 29 Jul 2012 21:17:20 +0200
Subject: [csw-maintainers] How to package MoinMoinWiki
Message-ID: <7B941387-99FD-4F5A-AB43-E5A225668889@opencsw.org>

Hi all,

I'm trying to build a package for the MoinMoinWiki [1]. The package itself is functional, but I have a few questions, how to do it right.

(1) The MoinMoinWiki stores it's information in the file system, not in a database. So where would be a good place to store all the - user created - wiki sites?
(1.1) By default, the wiki want's to store the sites under /opt/csw/share/moin/data.
(1.2) In $HOME of an own user and group for the wiki engine. The user's $HOME would be /export/home/<moin user> and the user's group <moin group> would have read / write permissions. The webserver's user has to be added to <moin group>.
(1.3) One could say, the data should be stored somewhere under /var , as it is "variable". In fact, it would be the same as (1.2) with $HOME=/var/...
(1.4) It's absolutely up to the user to decide where to create data directories and to configure the wiki accordingly. I think, this is the way, Debian does it.

Maybe (1.4) would be the best way to do it, as the user has full flexibility. Of course, (1.2) would be more convenient.

(2) What would be the right name for the package / catalog? The MoinMoinWiki is written in python. mgar suggests CSWpy-<...> and as a catalog name py_<...>. I also read [2], but as my python knowledge is very close to zero, an advice will be very appreciated. 
For orientation I took a look at Debian, there the package is called python-moinmoin. This would be equivalent to CSWpy-<...> if I'm not wrong.
So, what about CSWpy-moinmoin?

Regards,
Juergen

[1] http://moinmo.in/
[2] http://wiki.opencsw.org/python-packages-naming

-- 
Juergen Arndt