From pfelecan at opencsw.org  Fri May  1 10:12:11 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Fri, 01 May 2015 10:12:11 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <5542A3F8.1030004@opencsw.org> (Riccardo Mottola's message of
	"Thu, 30 Apr 2015 23:51:52 +0200")
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org> <553FF588.7000500@opencsw.org>
	<553FFC6F.6020905@opencsw.org>
	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>
	<554090C8.6090309@opencsw.org>
	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>
	<5541E127.9070903@opencsw.org> <5542A3F8.1030004@opencsw.org>
Message-ID: <x6y4l83eec.fsf@opencsw.org>

Riccardo Mottola <rmottola at opencsw.org> writes:

> Hi,
>
> Laurent Blume wrote:
>> FWIW, here's what I see on CentOS7:
>> -rw-r--r-- 1 root root 226 10 juin   2014 libpng15.pc
>> lrwxrwxrwx 1 root root  11 11 janv. 20:38 libpng.pc -> libpng15.pc
>>
>> And the current CSW package:
>> lrwxrwxrwx   1 root  root    11 avr  28 09:22 libpng.pc -> libpng16.pc
>> -rw-r--r--   1 root  bin    236 avr  21 15:19 libpng16.pc
>
> but these look the same to me? except that CentOS7 is back one
> release. so why do we want to differ?
> I still think that somehow having N different developer packages is messy.
>
> Isn't libpng.pc looked for after all? We need that symlink.

Yes, we need it and, if I'm reading correctly, Laurent doesn't say the
oposite.

BTW, Debian also has a versioned development package and the neutral
symbolic link. The symbolic link ensures the neutrality with regard to
the version. Thus:

-rw-r--r--  1 root root   251 Nov 27 20:56 libpng12.pc
lrwxrwxrwx  1 root root    11 Nov 27 20:56 libpng.pc -> libpng12.pc

-- 
Peter

From laurent at opencsw.org  Fri May  1 11:17:52 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Fri, 01 May 2015 11:17:52 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <5542A3F8.1030004@opencsw.org>
References: <553F4698.1000009@opencsw.org>	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>	<5541E127.9070903@opencsw.org>
	<5542A3F8.1030004@opencsw.org>
Message-ID: <554344C0.9020400@opencsw.org>

Le 2015/04/30 23:51 +0200, Riccardo Mottola a ?crit:
> but these look the same to me? except that CentOS7 is back one release.
> so why do we want to differ?
> I still think that somehow having N different developer packages is messy.
> 
> Isn't libpng.pc looked for after all? We need that symlink.


The point is having it only for libpng16.pc, so further development use
it, while keeping libpng15.pc for older packages.

Laurent

From dam at opencsw.org  Fri May  1 22:22:59 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 1 May 2015 22:22:59 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <B9B9AE2F-B8CF-41FB-AED9-AC180ECCE7D1@opencsw.org>
References: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>
	<CAF2fwscXm0hjyy4_FP+0mJ4U3SSGw4P7Gc2Gi_Q5a4545swZjg@mail.gmail.com>
	<5279BBF8-1DE2-4FBD-B9B4-9C6057319DD7@opencsw.org>
	<CAF2fwsfWgxPvoYk+APJke6p+1n5F6hfbRa5E-+PzJceEP0hUMA@mail.gmail.com>
	<5536A4A5.9030803@opencsw.org>
	<939EA461-3214-4952-A5AE-7EEAEBE8D9AD@opencsw.org>
	<553756D5.5080900@opencsw.org> <5537FAD6.30703@opencsw.org>
	<B9B9AE2F-B8CF-41FB-AED9-AC180ECCE7D1@opencsw.org>
Message-ID: <1AF1B587-B1CD-4627-8E2A-245D73A8BBB4@opencsw.org>

Hi folks,

Am 24.04.2015 um 12:11 schrieb Dagobert Michelsen:
> Hangs on Solaris 9 in the same way as the package from Yann. So this is really an upstream
> issue?

I just got this information from Oracle support:

> According to Solaris Development, the issue is expected to appear not only in Branded Sol 9 zones, but also on physical systems running Solaris 9 
> Solaris Development pointed out that Solaris 10 is working differently in this part - hence, the issue does not appear in Solaris 10 ( and higher ) 
> 
> All application calling pthread_atfork() from a fork handler can deadlock on Solaris 9. That's the behavior of Solaris 9, and it won't be changed since Solaris 9 has already been EOL'd. 
> 
> Looks like the new openssl has been built by 3rd party. 
> Could you please provide info about the origin of the new new openssl ? 
> If this is 3rd party, did you check already with this vendor ? 

Maybe the threading code has changed?


Best regards

  -- Dago

From pfelecan at opencsw.org  Sat May  2 10:00:30 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 02 May 2015 10:00:30 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <1AF1B587-B1CD-4627-8E2A-245D73A8BBB4@opencsw.org> (Dagobert
	Michelsen's message of "Fri, 1 May 2015 22:22:59 +0200")
References: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>
	<CAF2fwscXm0hjyy4_FP+0mJ4U3SSGw4P7Gc2Gi_Q5a4545swZjg@mail.gmail.com>
	<5279BBF8-1DE2-4FBD-B9B4-9C6057319DD7@opencsw.org>
	<CAF2fwsfWgxPvoYk+APJke6p+1n5F6hfbRa5E-+PzJceEP0hUMA@mail.gmail.com>
	<5536A4A5.9030803@opencsw.org>
	<939EA461-3214-4952-A5AE-7EEAEBE8D9AD@opencsw.org>
	<553756D5.5080900@opencsw.org> <5537FAD6.30703@opencsw.org>
	<B9B9AE2F-B8CF-41FB-AED9-AC180ECCE7D1@opencsw.org>
	<1AF1B587-B1CD-4627-8E2A-245D73A8BBB4@opencsw.org>
Message-ID: <x6lhh72yu9.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi folks,
>
> Am 24.04.2015 um 12:11 schrieb Dagobert Michelsen:
>> Hangs on Solaris 9 in the same way as the package from Yann. So this is really an upstream
>> issue?
>
> I just got this information from Oracle support:
>
>> According to Solaris Development, the issue is expected to appear not
>> only in Branded Sol 9 zones, but also on physical systems running
>> Solaris 9 Solaris Development pointed out that Solaris 10 is working
>> differently in this part - hence, the issue does not appear in
>> Solaris 10 ( and higher )
>> 
>> All application calling pthread_atfork() from a fork handler can
>> deadlock on Solaris 9. That's the behavior of Solaris 9, and it won't
>> be changed since Solaris 9 has already been EOL'd.
>> 
>> Looks like the new openssl has been built by 3rd party.  Could you
>> please provide info about the origin of the new new openssl ?  If
>> this is 3rd party, did you check already with this vendor ?

We are the third party, isn't it?

What I don't get is all the effort that you people put in an EOL'd
system, not only from the point of view of the original supplier but
also from our point of view.

Lately, there is a lot of effort put by Riccardo and others in
supporting things on Solaris 9 and even on Solaris 8...

Please understand me well, I'm not opposing anything that you people do
in this area, it's your time, your energy, but I only hope to avoid
increasing the entropy of our current endeavours.
-- 
Peter

From dam at opencsw.org  Mon May  4 10:17:27 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 4 May 2015 10:17:27 +0200
Subject: GCC 5.1.0
Message-ID: <A5C38439-1307-4081-A966-F5C6E015A222@opencsw.org>

Hi folks,

I made some experimental packages for GCC 5.1.0. They are available from experimental at
  http://buildfarm.opencsw.org/experimental.html#gcc5
The compiler is also installed on experimental10s and experimental10x. GCC5 support in
GAR has been added in r24924, you can select the compile explicitly with
  GARCOMPILER = GCC5
Due to some file collisions the main packages are marked incompatible to their respective
GCC4 counterparts.

Please give them a try and let me know if it works or if you encounter any issues.
Unfortunately the issues we had with GCC 4.9 with respect to GO and gcj are still
present. It looks like errors won?t go away all by themselves?


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150504/c099acbe/attachment-0001.p7s>

From maciej at opencsw.org  Mon May  4 14:00:48 2015
From: maciej at opencsw.org (Maciej =?utf-8?Q?=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 4 May 2015 13:00:48 +0100
Subject: GCC 5.1.0
In-Reply-To: <A5C38439-1307-4081-A966-F5C6E015A222@opencsw.org>
References: <A5C38439-1307-4081-A966-F5C6E015A222@opencsw.org>
Message-ID: <20150504120048.GA13778@gmail.com>

On Mon, May 04, 2015 at 10:17:27AM +0200, Dagobert Michelsen wrote:
> Hi folks,
> 
> I made some experimental packages for GCC 5.1.0. They are available from experimental at
>   http://buildfarm.opencsw.org/experimental.html#gcc5
> The compiler is also installed on experimental10s and experimental10x. GCC5 support in
> GAR has been added in r24924, you can select the compile explicitly with
>   GARCOMPILER = GCC5

Very cool, thanks for doing this!

> Due to some file collisions the main packages are marked incompatible to their respective
> GCC4 counterparts.

This means that when we decide to switch to GCC5, the whole buildfarm will
have to switch at once, and we won't be able to set it at will in the build
recipe.

> Please give them a try and let me know if it works or if you encounter any issues.
> Unfortunately the issues we had with GCC 4.9 with respect to GO and gcj are still
> present. It looks like errors won?t go away all by themselves?

I wish I had the skill to debug this. Just to get a stack trace from the
segfault, you need to compile the golang runtime with debugging symbols. But
this is the crazy GCC build system doesn't just allow you to pass the -g flag.

Does anyone have experience with debugging GCC itself?

Maciej

From rmottola at opencsw.org  Mon May  4 23:14:43 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 04 May 2015 23:14:43 +0200
Subject: freetype update
In-Reply-To: <6A3E2F4A-B7D2-4252-BC21-F8C1ABB3AB4D@opencsw.org>
References: <5540EA8B.8080104@opencsw.org>
	<6A3E2F4A-B7D2-4252-BC21-F8C1ABB3AB4D@opencsw.org>
Message-ID: <5547E143.5060108@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Sure. Want to give the 2.5 branch a try?;-)

I had problems with it, so for now let's use this one. I want to finish 
the gnulinks/binutils/gcc endeavour on solaris9 first.
Or are there needs for 2.5? I thought that if tiwas so many releases 
back there weren't so a minor update was fine already.

Riccardo

From rmottola at opencsw.org  Tue May  5 10:05:56 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 05 May 2015 10:05:56 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <5541E127.9070903@opencsw.org>
References: <553F4698.1000009@opencsw.org>	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>
	<5541E127.9070903@opencsw.org>
Message-ID: <554879E4.8080900@opencsw.org>

Hi,

well, you somehow convinced me that we need a versioned developer 
package. My guts still don't like it, but what you say makes a lot of sense.

Does it work not having the symlink at all? I that case everything is 
fine! If you can confirm that, we can think about removing the symlink. 
If things work like the libraries symlink however it is needed and it is 
better just to upgrade all packages.

Laurent Blume wrote:
>    - respin 1.5 with a versioned -dev,*removing*  the libpng.pc symlink,
> and obsoleting the unversioned -dev (since other current -dev
> dependencies will need that version)
>    - reversion it to 1.6, this time commenting out the symlink removal,
> and of course removing the obsoleting (since future dependencies will
> need to use a versioned -dev)
>    - add a lot of comments in the recipe explaining how to do it for
> future version changes (one last respin of the current version without
> the symlink, then new version with it, the obsoleting is a one-time
> thing, won't be needed further)
>    - check that it all works
>    - warn the maintainers of all packages that have a dependency on
> libpng that they will need to upgrade their BUILD_DEP.

Can we somhow simplify this procedure? Seems a lot of work to me. I see 
not problems

1) respin 1.5 versioned dev without the symlink
2) respin 1.6 versioned dev without the symlink

respinnin a non-versioned dev with "which" comments "where" seems a lot 
of hassle.

How do I actually remove the symlink? The receipe packages it 
automatically. Apparently everything which is not packaged into lipng16 
and utils ends up in dev, so perhaps I need to remove the file after the 
build stage or before the installation stage?

Riccardo

From dam at opencsw.org  Tue May  5 12:24:25 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 5 May 2015 12:24:25 +0200
Subject: freetype update
In-Reply-To: <5547E143.5060108@opencsw.org>
References: <5540EA8B.8080104@opencsw.org>
	<6A3E2F4A-B7D2-4252-BC21-F8C1ABB3AB4D@opencsw.org>
	<5547E143.5060108@opencsw.org>
Message-ID: <1ACB1539-2494-4DF3-885A-ED6CF7EEE7B2@opencsw.org>

Hi Riccardo,

Am 04.05.2015 um 23:14 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> Sure. Want to give the 2.5 branch a try?;-)
> 
> I had problems with it, so for now let's use this one. I want to finish the gnulinks/binutils/gcc endeavour on solaris9 first.
> Or are there needs for 2.5? I thought that if tiwas so many releases back there weren't so a minor update was fine already.

Just a suggestion while you were at it, feel free to skip it if it is more
than changing a line.


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150505/b2b34fbc/attachment.p7s>

From pfelecan at opencsw.org  Tue May  5 19:11:39 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 05 May 2015 19:11:39 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <554879E4.8080900@opencsw.org> (Riccardo Mottola's message of
	"Tue, 05 May 2015 10:05:56 +0200")
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org> <553FF588.7000500@opencsw.org>
	<553FFC6F.6020905@opencsw.org>
	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>
	<554090C8.6090309@opencsw.org>
	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>
	<5541E127.9070903@opencsw.org> <554879E4.8080900@opencsw.org>
Message-ID: <x6a8xj2blg.fsf@opencsw.org>

Riccardo Mottola <rmottola at opencsw.org> writes:

> perhaps I need to remove the file
> after the build stage or before the installation stage?

after the installation and before the merge
-- 
Peter

From laurent at opencsw.org  Tue May  5 19:36:13 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Tue, 05 May 2015 19:36:13 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <554879E4.8080900@opencsw.org>
References: <553F4698.1000009@opencsw.org>	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>	<5541E127.9070903@opencsw.org>
	<554879E4.8080900@opencsw.org>
Message-ID: <5548FF8D.50200@opencsw.org>

Le 2015/05/05 10:05 +0200, Riccardo Mottola a ?crit:
> Hi,
> 
> well, you somehow convinced me that we need a versioned developer
> package. My guts still don't like it, but what you say makes a lot of
> sense.
> 
> Does it work not having the symlink at all?

Maybe. Up to you to prove it. Hey, you broke it ;-)
Personally, seeing Linux distros have it, I think it's needed.

 I that case everything is
> fine! If you can confirm that, we can think about removing the symlink.
> If things work like the libraries symlink however it is needed and it is
> better just to upgrade all packages.

> Can we somhow simplify this procedure? Seems a lot of work to me. I see
> not problems

It's what happens when you start playing with dependencies that impact
other people's work :-)
Don't worry, you're not the first, and this looks pretty easy compared
to some others.

> 
> 1) respin 1.5 versioned dev without the symlink
> 2) respin 1.6 versioned dev without the symlink
> 
> respinnin a non-versioned dev with "which" comments "where" seems a lot
> of hassle.

I don't understand what you tried to say here. FWIW, I'm in favor of the
symlink to be in the most recent version, whatever that is, not having
an additional unversioned package that contains only that link.

Laurent

From rmottola at opencsw.org  Tue May  5 19:49:09 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 05 May 2015 19:49:09 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <5548FF8D.50200@opencsw.org>
References: <553F4698.1000009@opencsw.org>	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>	<5541E127.9070903@opencsw.org>	<554879E4.8080900@opencsw.org>
	<5548FF8D.50200@opencsw.org>
Message-ID: <55490295.10607@opencsw.org>

Hi,

On 05/05/15 19:36, Laurent Blume wrote:
> Le 2015/05/05 10:05 +0200, Riccardo Mottola a ?crit:
>> Hi,
>>
>> well, you somehow convinced me that we need a versioned developer
>> package. My guts still don't like it, but what you say makes a lot of
>> sense.
>>
>> Does it work not having the symlink at all?
> Maybe. Up to you to prove it. Hey, you broke it ;-)
> Personally, seeing Linux distros have it, I think it's needed.

hey, I just upgraded... I didn't "break it" more than the last revision, 
it is just necessary to update a dozen of packages, as happened probably 
last time libpng's soname was upgraded.
>> 1) respin 1.5 versioned dev without the symlink
>> 2) respin 1.6 versioned dev without the symlink
>>
>> respinnin a non-versioned dev with "which" comments "where" seems a lot
>> of hassle.
> I don't understand what you tried to say here. FWIW, I'm in favor of the
> symlink to be in the most recent version, whatever that is, not having
> an additional unversioned package that contains only that link.

Then probably didn't understand your proposal, sorry. Except for actual 
status which we need to recover, supposing that 15 had already a 
versioned package, I would have just upgraded to 16, producing another 
one, but incompatible to the 16, since both would have the symlink?

In other words, the current dev package is fine, except you want it to 
have a versioned name? Let's start with that easy fix.

Do you want then to produce the same versioned package for the old 15 
version, doing a partial revert of the Makefile? Fine too. What is it 
for, if you anyway have a symlink in the 16 version? it would overwrite 
a file.

I can take care of the above steps. But you still have packages 
depending on the "old" unversioned one, right? those need to be updated 
anyway.

Riccardo

From laurent at opencsw.org  Wed May  6 10:00:36 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Wed, 06 May 2015 10:00:36 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <55490295.10607@opencsw.org>
References: <553F4698.1000009@opencsw.org>	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>	<5541E127.9070903@opencsw.org>	<554879E4.8080900@opencsw.org>	<5548FF8D.50200@opencsw.org>
	<55490295.10607@opencsw.org>
Message-ID: <5549CA24.9070404@opencsw.org>

Le 2015/05/05 19:49 +0200, Riccardo Mottola a ?crit:
> hey, I just upgraded... I didn't "break it" more than the last revision,
> it is just necessary to update a dozen of packages, as happened probably
> last time libpng's soname was upgraded.

I was not blaming you. You have to understand that when you're working
with packages that impact the work of other people, you fully assume the
responsibility of not disturbing the work of those people more than
necessary, and fix new issues that appear.

This is tangent to Peter's recent post. We get the feeling that for you,
this is a hobby, you play and learn on obsolete OS's. That's a perfectly
fine and legit reason to work with OpenCSW.
But others still have actual business needs for those packages you are
impacting with your changes. You are very welcome to make those changes,
but you do have to be careful and responsible with them.

> Then probably didn't understand your proposal, sorry. Except for actual
> status which we need to recover, supposing that 15 had already a
> versioned package, I would have just upgraded to 16, producing another
> one, but incompatible to the 16, since both would have the symlink?

No, we don't want both to have the symlink. We want the most recent one
to have the symlink, only the most recent one, so new packages that use
libpng-dev will use that libpng.pc symlink and link to whatever is the
most current one. Yes, they will get an implicit dependency on
libpngXX-dev in the process, but that's apparently the way the libpng
devs want it.
Then, packages that depend on eg libpng15-dev will still be able to use
libpng15.pc

> In other words, the current dev package is fine, except you want it to
> have a versioned name? Let's start with that easy fix.

No, it is not fine.
If you get back to my original post, you will see that my recipes are
broken because they lack the file libpng15.pc.

So you absolutely must respin now a libpng15-dev without the symlink,
that will obsolete libpng-dev, and modify the current libpng-dev so it
becomes libpng16-dev.

> Do you want then to produce the same versioned package for the old 15
> version, doing a partial revert of the Makefile? Fine too. What is it
> for, if you anyway have a symlink in the 16 version? it would overwrite
> a file.

Because the recipes currently need the libpng***15***.pc file, that is
not part of libpng***16***. The symlink is only used for the initial
build of the recipes. Since it points to a versioned file that contains
versioned content, the dependencies of those dependencies will then
later request the versioned content.
If you've not had the time yet, I suggest you have a look at
pkg-config(1) and how it is used to provide build-time informations.

> I can take care of the above steps. But you still have packages
> depending on the "old" unversioned one, right? those need to be updated
> anyway.

Yes, that is precisely why I said you have to contact the maintainers of
the dependencies of your package to make sure that they are aware of
those changes they have to make.

Welcome to dependency hell. It's part of the job :-)

Laurent

From rmottola at opencsw.org  Wed May  6 22:30:03 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 06 May 2015 22:30:03 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <x6a8xj2blg.fsf@opencsw.org>
References: <553F4698.1000009@opencsw.org>
	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>
	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>	<5541E127.9070903@opencsw.org>
	<554879E4.8080900@opencsw.org> <x6a8xj2blg.fsf@opencsw.org>
Message-ID: <554A79CB.1040700@opencsw.org>

Hi,

On 05/05/15 19:11, Peter FELECAN wrote:
> Riccardo Mottola <rmottola at opencsw.org> writes:
>
>> perhaps I need to remove the file
>> after the build stage or before the installation stage?
> after the installation and before the merge

I suppose I need to try my luck in post-install:
I am pretty sure this is the right place, but what directory should 
search the files in? $(WRKSRC) is wrong, DESTDIR too

Riccardo

From dam at opencsw.org  Thu May  7 09:03:58 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 7 May 2015 09:03:58 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <554A79CB.1040700@opencsw.org>
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org> <553FF588.7000500@opencsw.org>
	<553FFC6F.6020905@opencsw.org>
	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>
	<554090C8.6090309@opencsw.org>
	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>
	<5541E127.9070903@opencsw.org> <554879E4.8080900@opencsw.org>
	<x6a8xj2blg.fsf@opencsw.org> <554A79CB.1040700@opencsw.org>
Message-ID: <33EB9B7F-12C7-45BE-BE50-3F36D5507949@opencsw.org>

Hi Riccardo,

> Am 06.05.2015 um 22:30 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> On 05/05/15 19:11, Peter FELECAN wrote:
>> Riccardo Mottola <rmottola at opencsw.org> writes:
>> 
>>> perhaps I need to remove the file
>>> after the build stage or before the installation stage?
>> after the installation and before the merge
> 
> I suppose I need to try my luck in post-install:
> I am pretty sure this is the right place, but what directory should search the files in? $(WRKSRC) is wrong, DESTDIR too

DESTDIR should be right, something like

post-install:
	rm -f $(DESTDIR)$(libdir)/libpng.so
	@$(MAKECOOKIE)

Reminder: configure and build take place inside $(WORKSRC), the installation is
done from $(WORKSRC) to $(DESTDIR), all the $(DESTDIR)s from all modulations
are merged together to $(PKGROOT) from where the package is made.


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150507/93e9e19d/attachment.p7s>

From rmottola at opencsw.org  Thu May  7 10:03:52 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 07 May 2015 10:03:52 +0200
Subject: making versioned libpng-dev
Message-ID: <554B1C68.7080504@opencsw.org>

Hi,

we have agreed to make a versioned libpng-dev and I am proceeding doing 
that. Not everything is clear, but let's do the certain stuff first.

1) make a versioned libpng16-dev, which contains the symlink. I think I 
prepared that.
I get a collision with the unversioned package (obviously, the content 
is exactly the same)

CHECKPKG_OVERRIDES_CSWlibpng16-dev += 
file-collision|/opt/csw/lib/sparcv8plus+vis2/libpng.so|CSWlibpng-dev|CSWlibpng16-dev

the unversioned package needs to removed forever, right? May you do that 
on bot sol. 9 and 10?


2) I did a libpng15-dev, which is a versioned respin of the old 
developer package without the symlink. I created a branch of libpng for 
that.
The package is ready, I think I should build it for solaris 9 & 10 and 
upload it?

Other?

Riccardo

From dam at opencsw.org  Thu May  7 10:23:17 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 7 May 2015 10:23:17 +0200
Subject: making versioned libpng-dev
In-Reply-To: <554B1C68.7080504@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
Message-ID: <61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>

Hi Riccardo,

> Am 07.05.2015 um 10:03 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> we have agreed to make a versioned libpng-dev and I am proceeding doing that. Not everything is clear, but let's do the certain stuff first.
> 
> 1) make a versioned libpng16-dev, which contains the symlink. I think I prepared that.
> I get a collision with the unversioned package (obviously, the content is exactly the same)
> 
> CHECKPKG_OVERRIDES_CSWlibpng16-dev += file-collision|/opt/csw/lib/sparcv8plus+vis2/libpng.so|CSWlibpng-dev|CSWlibpng16-dev
> 
> the unversioned package needs to removed forever, right? May you do that on bot sol. 9 and 10?

No, but obsoleted for now. Add
  OBSOLETED_BY_CSWlibpng16-dev += CSWlibpng-dev
and upload both packages at the same time.

> 2) I did a libpng15-dev, which is a versioned respin of the old developer package without the symlink. I created a branch of libpng for that.
> The package is ready, I think I should build it for solaris 9 & 10 and upload it?

Yes. I suggest uploading all CSWlibpng*-dev packages at the same 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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150507/4b05e295/attachment.p7s>

From rmottola at opencsw.org  Thu May  7 10:43:12 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 07 May 2015 10:43:12 +0200
Subject: making versioned libpng-dev
In-Reply-To: <61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
Message-ID: <554B25A0.6000909@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Hi Riccardo,
>
>> Am 07.05.2015 um 10:03 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>>
>> Hi,
>>
>> we have agreed to make a versioned libpng-dev and I am proceeding doing that. Not everything is clear, but let's do the certain stuff first.
>>
>> 1) make a versioned libpng16-dev, which contains the symlink. I think I prepared that.
>> I get a collision with the unversioned package (obviously, the content is exactly the same)
>>
>> CHECKPKG_OVERRIDES_CSWlibpng16-dev += file-collision|/opt/csw/lib/sparcv8plus+vis2/libpng.so|CSWlibpng-dev|CSWlibpng16-dev
>>
>> the unversioned package needs to removed forever, right? May you do that on bot sol. 9 and 10?
> No, but obsoleted for now. Add
>    OBSOLETED_BY_CSWlibpng16-dev += CSWlibpng-dev
> and upload both packages at the same time.

I did that for 15-dev, but somehow lost it for 16-dev when doing the 
branch :(

>
>> 2) I did a libpng15-dev, which is a versioned respin of the old developer package without the symlink. I created a branch of libpng for that.
>> The package is ready, I think I should build it for solaris 9 & 10 and upload it?
> Yes. I suggest uploading all CSWlibpng*-dev packages at the same time.

Ok I will upload only the dev packages, not the rest. Actually since 
they are platform "all" there is no sparc/intel, there will be four: for 
solaris 9 and for solaris10, one for 15 and one for 16.


Building will take some time, I hope that the next message will be a 
report of upload success :)

Riccardo



From dam at opencsw.org  Thu May  7 10:56:45 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 7 May 2015 10:56:45 +0200
Subject: making versioned libpng-dev
In-Reply-To: <554B25A0.6000909@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
	<554B25A0.6000909@opencsw.org>
Message-ID: <4488B479-EECB-4608-A5C0-D3A148AEE09D@opencsw.org>

Hi,

> Am 07.05.2015 um 10:43 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> Dagobert Michelsen wrote:
>> Hi Riccardo,
>> 
>>> Am 07.05.2015 um 10:03 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>>> 
>>> Hi,
>>> 
>>> we have agreed to make a versioned libpng-dev and I am proceeding doing that. Not everything is clear, but let's do the certain stuff first.
>>> 
>>> 1) make a versioned libpng16-dev, which contains the symlink. I think I prepared that.
>>> I get a collision with the unversioned package (obviously, the content is exactly the same)
>>> 
>>> CHECKPKG_OVERRIDES_CSWlibpng16-dev += file-collision|/opt/csw/lib/sparcv8plus+vis2/libpng.so|CSWlibpng-dev|CSWlibpng16-dev
>>> 
>>> the unversioned package needs to removed forever, right? May you do that on bot sol. 9 and 10?
>> No, but obsoleted for now. Add
>>   OBSOLETED_BY_CSWlibpng16-dev += CSWlibpng-dev
>> and upload both packages at the same time.
> 
> I did that for 15-dev, but somehow lost it for 16-dev when doing the branch :(

You can only have one obsoletion, I suggestto obsolete CSWlibpng-dev
with CSWlibpng16-dev and take out the obsoletion from -15.

>>> 2) I did a libpng15-dev, which is a versioned respin of the old developer package without the symlink. I created a branch of libpng for that.
>>> The package is ready, I think I should build it for solaris 9 & 10 and upload it?
>> Yes. I suggest uploading all CSWlibpng*-dev packages at the same time.
> 
> Ok I will upload only the dev packages, not the rest. Actually since they are platform "all" there is no sparc/intel, there will be four: for solaris 9 and for solaris10, one for 15 and one for 16.

I suggest to make -dev *not* archall by convention. There is the risk of differences which
are hard to detect due to endianess and/or bitwidth. You can then upload all packages at once.
It is mainly important to upload the obsoletion and the obsoleted package at the same time
or you will get errors about duplicate pathes.

> Building will take some time, I hope that the next message will be a report of upload success :)

:-)


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150507/83ecd6f3/attachment.p7s>

From rmottola at opencsw.org  Thu May  7 11:26:32 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 07 May 2015 11:26:32 +0200
Subject: making versioned libpng-dev
In-Reply-To: <4488B479-EECB-4608-A5C0-D3A148AEE09D@opencsw.org>
References: <554B1C68.7080504@opencsw.org>	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>	<554B25A0.6000909@opencsw.org>
	<4488B479-EECB-4608-A5C0-D3A148AEE09D@opencsw.org>
Message-ID: <554B2FC8.9080004@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> You can only have one obsoletion, I suggestto obsolete CSWlibpng-dev
> with CSWlibpng16-dev and take out the obsoletion from -15.

Ah, that's a kind of limitation, I'll remove it from -15 then.

But how can I upload the obsoleted package? I don't have don't have it. 
Please don't make me build another branch just for that, it is a 
nightmare otherwise.

>
>> Ok I will upload only the dev packages, not the rest. Actually since they are platform "all" there is no sparc/intel, there will be four: for solaris 9 and for solaris10, one for 15 and one for 16.
> I suggest to make -dev *not* archall by convention. There is the risk of differences which
> are hard to detect due to endianess and/or bitwidth. You can then upload all packages at once.
> It is mainly important to upload the obsoletion and the obsoleted package at the same time
> or you will get errors about duplicate pathes.

It was already done that way and I left it so, I just versioned the dev 
package. I hope it can be fixed later, I'm actually for gradual 
updating, even if this small update became a big mess.

Riccardo

From dam at opencsw.org  Thu May  7 12:35:32 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 7 May 2015 12:35:32 +0200
Subject: making versioned libpng-dev
In-Reply-To: <554B2FC8.9080004@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
	<554B25A0.6000909@opencsw.org>
	<4488B479-EECB-4608-A5C0-D3A148AEE09D@opencsw.org>
	<554B2FC8.9080004@opencsw.org>
Message-ID: <535B97FC-8818-4DBB-BE48-87E4F2ABD3EE@opencsw.org>

Hi Riccardo,

> Am 07.05.2015 um 11:26 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> You can only have one obsoletion, I suggestto obsolete CSWlibpng-dev
>> with CSWlibpng16-dev and take out the obsoletion from -15.
> 
> Ah, that's a kind of limitation, I'll remove it from -15 then.
> 
> But how can I upload the obsoleted package? I don't have don't have it. Please don't make me build another branch just for that, it is a nightmare otherwise.

The _stub package should be built automatically when you specify
it as obsoleted. Is it not built for you?

>>> Ok I will upload only the dev packages, not the rest. Actually since they are platform "all" there is no sparc/intel, there will be four: for solaris 9 and for solaris10, one for 15 and one for 16.
>> I suggest to make -dev *not* archall by convention. There is the risk of differences which
>> are hard to detect due to endianess and/or bitwidth. You can then upload all packages at once.
>> It is mainly important to upload the obsoletion and the obsoleted package at the same time
>> or you will get errors about duplicate pathes.
> 
> It was already done that way and I left it so, I just versioned the dev package. I hope it can be fixed later, I'm actually for gradual updating, even if this small update became a big mess.

Just take out the ARCHALL, you can do that any time.


Best regards

  ? Dago

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

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

From rmottola at opencsw.org  Thu May  7 15:00:45 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 07 May 2015 15:00:45 +0200
Subject: making versioned libpng-dev
In-Reply-To: <61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
Message-ID: <554B61FD.9010308@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> No, but obsoleted for now. Add
>    OBSOLETED_BY_CSWlibpng16-dev += CSWlibpng-dev
> and upload both packages at the same time.

stupid question: since you told me I can obsolete only once, I removed 
obsoletion from libpng15-dev
Now I get file collisions there.
Should I put override o file collisions? It is a problem that something 
can't be obsoleted twice!

I tried leaving the obsoletion in and in the uncommited package I don't 
get any errors except the fact that it is uncommited. Maybe I did 
understand the double obsoletion you mentioned?
I'd reenable obsoletion also in the 15 version then.

Riccardo


From rmottola at opencsw.org  Thu May  7 20:36:51 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 07 May 2015 20:36:51 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <5549CA24.9070404@opencsw.org>
References: <553F4698.1000009@opencsw.org>	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>	<553FF588.7000500@opencsw.org>	<553FFC6F.6020905@opencsw.org>	<C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>	<554090C8.6090309@opencsw.org>	<DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>	<5541E127.9070903@opencsw.org>	<554879E4.8080900@opencsw.org>	<5548FF8D.50200@opencsw.org>	<55490295.10607@opencsw.org>
	<5549CA24.9070404@opencsw.org>
Message-ID: <554BB0C3.1060100@opencsw.org>

Hi,

On 05/06/15 10:00, Laurent Blume wrote:
> I was not blaming you. You have to understand that when you're working
> with packages that impact the work of other people, you fully assume the
> responsibility of not disturbing the work of those people more than
> necessary, and fix new issues that appear.

no offense taken! It is just that I happened to awaken a problem about 
versioning here.

> This is tangent to Peter's recent post. We get the feeling that for you,
> this is a hobby, you play and learn on obsolete OS's. That's a perfectly
> fine and legit reason to work with OpenCSW.
> But others still have actual business needs for those packages you are
> impacting with your changes. You are very welcome to make those changes,
> but you do have to be careful and responsible with them.

True, my work doesn't depend on these OpenCSW packages. However I strive 
for quality. I am an "upstream developer" and I like to take care about 
the software I like on solaris/sparc and generally I want to make life 
easier for other users, both professional and hobbyists, by providing 
up-to-date packages

I didn't expect that an update would cause such a problem, but now that 
there is a path to the solution.

I hope that after this upgade it will be etter for anybody: the 
versioning is the solution you proposed. Just making it work has some 
itches.


>
> Yes, that is precisely why I said you have to contact the maintainers 
> of the dependencies of your package to make sure that they are aware 
> of those changes they have to make. Welcome to dependency hell. It's 
> part of the job :-)

I hope the current build will provide the necessary packages and that 
they will work. I'll leave the wiki page open for all packages to be 
updated sooner or later!

Riccardo


From rmottola at opencsw.org  Thu May  7 23:33:01 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 07 May 2015 23:33:01 +0200
Subject: making versioned libpng-dev
In-Reply-To: <554B61FD.9010308@opencsw.org>
References: <554B1C68.7080504@opencsw.org>	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
	<554B61FD.9010308@opencsw.org>
Message-ID: <554BDA0D.5040302@opencsw.org>

Hi,

I hope everything is now ready! I have the versioned packaged, per 
achitecture!
The only thing I did differently from what Dago suggested is to obsolete 
the unversioned  from both versioned packages.

csw-upload-pkg png_stub-1.5.13\,REV\=2015.05.07-SunOS5.* 
libpng_dev_stub-1.6.16\,REV\=2
015.05.07-SunOS5.* libpng15_dev-1.5.13\,REV\=2015.05.07-SunOS5.* 
libpng16_dev-1.6.16\,REV\=2015.05.07-SunOS5.*
/opt/csw/bin/csw-upload-pkg is a wrapper, running 
/home/rmottola/opencsw/.buildsys/v2/bin/csw-upload-pkg 
png_stub-1.5.13,REV=2015.05.07-SunOS5.10-all-CSW.pkg.gz 
png_stub-1.5.13,REV=2015.05.07-SunOS5.9-all-CSW.pkg.gz 
libpng_dev_stub-1.6.16,REV=2015.05.07-SunOS5.10-all-CSW.pkg.gz 
libpng_dev_stub-1.6.16,REV=2015.05.07-SunOS5.9-all-CSW.pkg.gz 
libpng15_dev-1.5.13,REV=2015.05.07-SunOS5.10-i386-CSW.pkg.gz 
libpng15_dev-1.5.13,REV=2015.05.07-SunOS5.10-sparc-CSW.pkg.gz 
libpng15_dev-1.5.13,REV=2015.05.07-SunOS5.9-i386-CSW.pkg.gz 
libpng15_dev-1.5.13,REV=2015.05.07-SunOS5.9-sparc-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.07-SunOS5.10-i386-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.07-SunOS5.10-sparc-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.07-SunOS5.9-i386-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.07-SunOS5.9-sparc-CSW.pkg.gz

I get however a big load of errors!!

but where are the real errors?

   /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py 
--catalog-release unstable --os-release SunOS5.11 --catalog-architecture 
sparc c694cd62b284f5b6907c98c5ce30a4ed 69dc56fff4709fba4b3dab15e0514b31 
d6b8c1af39a8821f6ba6b6e3a9ace010 cbb248591e61d94a03f77501e5fa7f8b 
e043cee3b3944523a568eac62c9fb684 19222ae85ddfddf063482509b3d4e9fa 
4d82edf83843859d1e7b335d66c67121

   /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py 
--catalog-release unstable --os-release SunOS5.9 --catalog-architecture 
i386 7adff6cea3d19a8062f74d1c2fba7511 c694cd62b284f5b6907c98c5ce30a4ed 
f1b4ce9c57c62c1c8886834cc0fe30b8 1b274796a2ca59bc7e0588333f5f2d3e


there are a lot of collisions.
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/lib/sparcv8plus+vis2/libpng.so|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/bin/sparcv9/libpng-config|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/bin/libpng-config|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/lib/sparcv9/libpng.so|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/include/pngconf.h|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/share/man/man3/libpng.3|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/lib/sparcv9/pkgconfig/libpng.pc|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/include/png.h|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/lib/libpng.so|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/include/pnglibconf.h|CSWlibpng15-dev|CSWlibpng16-dev
CHECKPKG_OVERRIDES_CSWlibpng15-dev += 
file-collision|/opt/csw/lib/sparcv8plus+vis/libpng.so|CSWlibpng15-dev|CSWlibpng16-dev

(and exactly the reverse, 16 vs 15)

I'm about to throw the towel :(

Riccardo

From jh at opencsw.org  Fri May  8 09:46:08 2015
From: jh at opencsw.org (Jan Holzhueter)
Date: Fri, 08 May 2015 09:46:08 +0200
Subject: Downtime x86 Part of the Buildfarm
Message-ID: <554C69C0.3030704@opencsw.org>

Hi,
I plan to update our ESX infrastructure this afternoon.
So the x86 part needs to be shut down.
Will keep you posted.

Greetings
Jan

From jh at opencsw.org  Fri May  8 21:58:09 2015
From: jh at opencsw.org (Jan Holzhueter)
Date: Fri, 08 May 2015 21:58:09 +0200
Subject: Downtime x86 Part of the Buildfarm
In-Reply-To: <554C69C0.3030704@opencsw.org>
References: <554C69C0.3030704@opencsw.org>
Message-ID: <554D1551.2010300@opencsw.org>

Am 08.05.15 um 09:46 schrieb Jan Holzhueter:
> Hi,
> I plan to update our ESX infrastructure this afternoon.
> So the x86 part needs to be shut down.
> Will keep you posted.

took longer then I thought.
But should all be back now.
If something does not work let me know.

Greetings
Jan



From maciej at opencsw.org  Sun May 10 10:42:22 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 10 May 2015 09:42:22 +0100
Subject: Fwd: New recipe - libasr
In-Reply-To: <20150508095252.GA24532@linutop.my.domain>
References: <20150508095252.GA24532@linutop.my.domain>
Message-ID: <CALtRa-5ihksy+reACyk0MNBZg3Er2ds_rUzCH1eLxats-LOtKQ@mail.gmail.com>

Could anybody pick it up?

--Maciej

---------- Forwarded message ----------
From: Freddy DISSAUX <freddy.dsx at free.fr>
Date: 2015-05-08 10:52 GMT+01:00
Subject: New recipe - libasr
To: users at lists.opencsw.org


Hello,

libasr is a free, simple and portable asynchronous resolver library.

It use some code from  https://java.net/projects/solaris/sources (CDDL).

Hope all rules/licences are respected.


Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150510/73927209/attachment.html>
-------------- next part --------------
Index: libasr/Makefile
===================================================================
--- libasr/Makefile	(revision 0)
+++ libasr/Makefile	(working copy)
@@ -0,0 +1,2 @@
+%:
+	$(MAKE) -C trunk $*
Index: libasr/trunk/Makefile
===================================================================
--- libasr/trunk/Makefile	(revision 0)
+++ libasr/trunk/Makefile	(working copy)
@@ -0,0 +1,59 @@
+# $Id$
+# TODO (release-critical prefixed with !, non release-critical with *)
+#
+NAME = libasr
+VERSION = 201505061057
+GARTYPE = v2
+
+DESCRIPTION = libasr is a free, simple and portable asynchronous resolver library.
+define BLURB
+ libasr is a free, simple and portable asynchronous resolver library.
+ 
+ It allows to run dns queries and perform hostname resolutions in a fully asynchronous fashion. The implementation is thread-less, fork-less, and does not make use of signals or other "tricks" that might get in the developer's way. The API was initially developped for the OpenBSD operating system, where it is natively supported.
+ 
+ This library is intended to bring this interface to other systems. It is originally provided as a support library for the portable version of the OpenSMTPD daemon, but it can be used in any other contexts. It is known to work on the following systems:
+ 
+     * Linux
+     * FreeBSD
+     * NetBSD
+     * DragonFly
+     * MacOSX
+ 
+ The primary source of information about libasr is the github repository.
+endef
+
+MASTER_SITES = http://www.opensmtpd.org/archives/
+DISTFILES  = $(DISTNAME).tar.gz
+
+ifneq ($(GAROSREL),11)
+PATCHFILES += 0001-add-openbsd-compat-getifaddrs.c.patch
+endif
+PATCHFILES += 0002-fix-possible-MAX-redefinition.patch
+
+GARCOMPILER = GNU
+
+PACKAGES += CSWlibasr
+CATALOGNAME_CSWlibasr = libasr
+PKGFILES_CSWlibasr += $(call baseisadirs,$(libdir),libasr\.so(\.\d+)*)
+SPKG_DESC_CSWlibasr += $(DESCRIPTION), libasr.so
+
+PACKAGES += CSWlibasr-dev
+CATALOGNAME_CSWlibasr-dev = libasr_dev
+SPKG_DESC_CSWlibasr-dev += $(DESCRIPTION), development files
+RUNTIME_DEP_PKGS_CSWlibasr-dev += CSWlibasr
+
+CONFIGURE_ARGS = $(DIRPATHS)
+CONFIGURE_ARGS += --with-mantype=man
+
+include gar/category.mk
+
+ifneq ($(GAROSREL),11)
+# ifaddrs.h    taken from https://java.net/projects/solaris/sources/on-src/content/usr/src/head/ifaddrs.h?raw=true
+# getifaddrs.c taken from https://java.net/projects/solaris/sources/on-src/content/usr/src/lib/libsocket/inet/getifaddrs.c?raw=true
+# libsocket_priv.h is a gruik hack
+pre-build-modulated:
+	cp $(FILEDIR)/openbsd-compat/ifaddrs.h $(WORKSRC)/openbsd-compat/
+	cp $(FILEDIR)/openbsd-compat/getifaddrs.c $(WORKSRC)/openbsd-compat/
+	cp $(FILEDIR)/openbsd-compat/libsocket_priv.h $(WORKSRC)/openbsd-compat/
+	@$(MAKECOOKIE)
+endif

Property changes on: libasr/trunk/Makefile
___________________________________________________________________
Added: svn:keywords
## -0,0 +1 ##
+Id
\ No newline at end of property
Index: libasr/trunk/checksums
===================================================================
--- libasr/trunk/checksums	(revision 0)
+++ libasr/trunk/checksums	(working copy)
@@ -0,0 +1 @@
+2a4b768b54892465570ef7488e56b737  libasr-201505061057.tar.gz
Index: libasr/trunk/files/0001-add-openbsd-compat-getifaddrs.c.patch
===================================================================
--- libasr/trunk/files/0001-add-openbsd-compat-getifaddrs.c.patch	(revision 0)
+++ libasr/trunk/files/0001-add-openbsd-compat-getifaddrs.c.patch	(working copy)
@@ -0,0 +1,24 @@
+From cf1d038c260ca6fd161174d6c5c42aaee90b1532 Mon Sep 17 00:00:00 2001
+From: Freddy DISSAUX <dsx at bsdsx.fr>
+Date: Thu, 7 May 2015 09:53:12 +0200
+Subject: [PATCH] add openbsd-compat/getifaddrs.c
+
+---
+ src/Makefile.am | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 286d382..7121b0b 100644
+--- a/src/Makefile.am
++++ b/src/Makefile.am
+@@ -11,6 +11,7 @@ libasr_la_SOURCES +=	$(top_srcdir)/openbsd-compat/strlcat.c
+ libasr_la_SOURCES +=	$(top_srcdir)/openbsd-compat/strlcpy.c
+ libasr_la_SOURCES +=	$(top_srcdir)/openbsd-compat/strsep.c
+ libasr_la_SOURCES +=	$(top_srcdir)/openbsd-compat/strtonum.c
++libasr_la_SOURCES +=	$(top_srcdir)/openbsd-compat/getifaddrs.c
+ 
+ include_HEADERS =	asr.h
+ 
+-- 
+2.3.1
+
Index: libasr/trunk/files/0002-fix-possible-MAX-redefinition.patch
===================================================================
--- libasr/trunk/files/0002-fix-possible-MAX-redefinition.patch	(revision 0)
+++ libasr/trunk/files/0002-fix-possible-MAX-redefinition.patch	(working copy)
@@ -0,0 +1,44 @@
+From 104a97a81ae81b29ae5796f9d1e48463b6305635 Mon Sep 17 00:00:00 2001
+From: Freddy DISSAUX <dsx at bsdsx.fr>
+Date: Fri, 8 May 2015 11:01:26 +0200
+Subject: [PATCH] fix possible MAX redefinition
+
+---
+ src/gethostnamadr_async.c | 4 ++++
+ src/getnetnamadr_async.c  | 2 ++
+ 2 files changed, 6 insertions(+)
+
+diff --git a/src/gethostnamadr_async.c b/src/gethostnamadr_async.c
+index 2d6ecb7..5d34956 100644
+--- a/src/gethostnamadr_async.c
++++ b/src/gethostnamadr_async.c
+@@ -40,8 +40,12 @@
+ 
+ #include "asr_private.h"
+ 
++#ifndef MAXALIASES
+ #define MAXALIASES	35
++#endif
++#ifndef MAXADDRS
+ #define MAXADDRS	35
++#endif
+ 
+ struct hostent_ext {
+ 	struct hostent	 h;
+diff --git a/src/getnetnamadr_async.c b/src/getnetnamadr_async.c
+index ec14262..cc37ef0 100644
+--- a/src/getnetnamadr_async.c
++++ b/src/getnetnamadr_async.c
+@@ -33,7 +33,9 @@
+ 
+ #include "asr_private.h"
+ 
++#ifndef MAXALIASES
+ #define MAXALIASES	16
++#endif
+ 
+ struct netent_ext {
+ 	struct netent	 n;
+-- 
+2.3.1
+
Index: libasr/trunk
===================================================================
--- libasr/trunk	(revision 0)
+++ libasr/trunk	(working copy)

Property changes on: libasr/trunk
___________________________________________________________________
Added: svn:ignore
## -0,0 +1 ##
+work

From rmottola at opencsw.org  Sun May 10 16:27:12 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 10 May 2015 16:27:12 +0200
Subject: making versioned libpng-dev
In-Reply-To: <554BDA0D.5040302@opencsw.org>
References: <554B1C68.7080504@opencsw.org>	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>	<554B61FD.9010308@opencsw.org>
	<554BDA0D.5040302@opencsw.org>
Message-ID: <554F6AC0.9010704@opencsw.org>

Hi,

some update:

Riccardo Mottola wrote:
>
> (and exactly the reverse, 16 vs 15)
>
> I'm about to throw the towel :( 
http://buildfarm.opencsw.org/pkgdb/srv4/28b1a1e3cd85f78f5cd92abbc8b3dc89/

the package collisions between 15 and 16 dev versions are about almost 
all files. Thinking, this can't be different: it is not just the two 
symblonks to package config and the shared object, but all man pages, 
headers...

how can the old versioned dev package coexist at all?  Perhaps you want 
more to make it an empty shell and include only very few files at all. I 
see it difficult to do something like that.

At this point, I don't see a clean way to make this versioned thing, 
perhaps what needs to be done has to be thought again.

Riccardo



From maciej at opencsw.org  Sun May 10 18:39:07 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 10 May 2015 17:39:07 +0100
Subject: making versioned libpng-dev
In-Reply-To: <554F6AC0.9010704@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
	<554B61FD.9010308@opencsw.org> <554BDA0D.5040302@opencsw.org>
	<554F6AC0.9010704@opencsw.org>
Message-ID: <CALtRa-5viLKe_aHb9YQ56L+qpxj4nLwDpBMj3XEnhsbEodyfog@mail.gmail.com>

2015-05-10 15:27 GMT+01:00 Riccardo Mottola <rmottola at opencsw.org>:

> the package collisions between 15 and 16 dev versions are about almost all
> files.


Maybe you can use Alternatives?

https://buildfarm.opencsw.org/trac/wiki/Alternatives

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

From dam at opencsw.org  Sun May 10 19:08:46 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 10 May 2015 19:08:46 +0200
Subject: making versioned libpng-dev
In-Reply-To: <CALtRa-5viLKe_aHb9YQ56L+qpxj4nLwDpBMj3XEnhsbEodyfog@mail.gmail.com>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
	<554B61FD.9010308@opencsw.org> <554BDA0D.5040302@opencsw.org>
	<554F6AC0.9010704@opencsw.org>
	<CALtRa-5viLKe_aHb9YQ56L+qpxj4nLwDpBMj3XEnhsbEodyfog@mail.gmail.com>
Message-ID: <832B2A59-7EAA-453F-8C74-B69F6E60BAE9@opencsw.org>





> Am 10.05.2015 um 18:39 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 
> 2015-05-10 15:27 GMT+01:00 Riccardo Mottola <rmottola at opencsw.org>:
>> the package collisions between 15 and 16 dev versions are about almost all files.
> 
> Maybe you can use Alternatives?
> 
> https://buildfarm.opencsw.org/trac/wiki/Alternatives

Please use alternatives only when absolutely necessary. I suggest taking all from 16 and provide only *15* in 15.

Best regards -- Dago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150510/1abbe8b5/attachment.html>

From rmottola at opencsw.org  Mon May 11 14:34:52 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 11 May 2015 14:34:52 +0200
Subject: libpng15 + dev respin
Message-ID: <5550A1EC.3050100@opencsw.org>

Hi,

especially for Laurent: I was finally able to do a libpng-15 respin with 
its dev versioned dev package.
The dev-package is really minimal but I hope it is enough? IN case 
please add yourself or tell me which precise file to add, one by one, 
explicitely.

I uploaded it successully, perhaps they can be already installed on the 
buildfarm

I am still working on the 16 package: I get a strange error I didn't get 
in the unversioned one and it makes no sense since I did not change 
anything in the content of the packages when versioning. I am doing a 
total clean build on all platforms and it takes a lot of time.

Riccardo

From rmottola at opencsw.org  Mon May 11 16:30:37 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 11 May 2015 16:30:37 +0200
Subject: problem with versioned libpng16 dev respin
Message-ID: <5550BD0D.6040200@opencsw.org>

Hi,

while uploading the new packages, I get this problem:

To see the errors, run:
   /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py 
--catalog-release unstable --os-release SunOS5.11 --catalog-architecture 
i386 c353353fd815aeeef7bfcbfbe9b26d3c b602b1ed6a56070eacaf8f587556d17f 
2576ddf732a227f88b5d03425fa6aebc 82b96ee89206580fcf987793ea98105e 
91b5b03a7a8f907bd6091ccafeff7c75


CHECKPKG_OVERRIDES_CSWlibpng16-dev += 
file-needed-but-no-package-satisfies-it|/opt/csw/lib/pentium_pro/libpng16.so.16.16.0|CSWlibpng16-dev|contains|symlink|/opt/csw/lib/pentium_pro/libpng16.so|which|needs|the|target|file:|/opt/csw/lib/pentium_pro/libpng16.so.16.16.0


I suppose this is a solaris11 problem on the solaris10 package.
Thus it would be:

http://buildfarm.opencsw.org/pkgdb/srv4/2576ddf732a227f88b5d03425fa6aebc/
http://buildfarm.opencsw.org/pkgdb/srv4/b602b1ed6a56070eacaf8f587556d17f/

I see only the standard lib and then amd64 and they both contain 
libpng16.so.16.16.0, as expected sicne it is the core of the package.

What is the matter now? What did change compared to the unversioned 
package? Nothing I see of relevance in the receipe, but teach me wrong.

Riccardo

From dam at opencsw.org  Wed May 13 13:57:07 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 13 May 2015 13:57:07 +0200
Subject: problem with versioned libpng16 dev respin
In-Reply-To: <5550BD0D.6040200@opencsw.org>
References: <5550BD0D.6040200@opencsw.org>
Message-ID: <05D7A39D-7E8A-415B-A64C-7B31EC170D98@opencsw.org>

Hi Riccardo,

> Am 11.05.2015 um 16:30 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> while uploading the new packages, I get this problem:
> 
> To see the errors, run:
>  /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py --catalog-release unstable --os-release SunOS5.11 --catalog-architecture i386 c353353fd815aeeef7bfcbfbe9b26d3c b602b1ed6a56070eacaf8f587556d17f 2576ddf732a227f88b5d03425fa6aebc 82b96ee89206580fcf987793ea98105e 91b5b03a7a8f907bd6091ccafeff7c75
> 
> 
> CHECKPKG_OVERRIDES_CSWlibpng16-dev += file-needed-but-no-package-satisfies-it|/opt/csw/lib/pentium_pro/libpng16.so.16.16.0|CSWlibpng16-dev|contains|symlink|/opt/csw/lib/pentium_pro/libpng16.so|which|needs|the|target|file:|/opt/csw/lib/pentium_pro/libpng16.so.16.16.0
> 
> 
> I suppose this is a solaris11 problem on the solaris10 package.
> Thus it would be:
> 
> http://buildfarm.opencsw.org/pkgdb/srv4/2576ddf732a227f88b5d03425fa6aebc/
> http://buildfarm.opencsw.org/pkgdb/srv4/b602b1ed6a56070eacaf8f587556d17f/
> 
> I see only the standard lib and then amd64 and they both contain libpng16.so.16.16.0, as expected sicne it is the core of the package.
> 
> What is the matter now? What did change compared to the unversioned package? Nothing I see of relevance in the receipe, but teach me wrong.

Are you uploading CSWlibpng16-16 together with CSWlibpng16-dev ? You need to upload both at the same
time or the database won?t know the destination of the .so symlink.


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150513/17632461/attachment.p7s>

From dam at opencsw.org  Wed May 13 14:26:28 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 13 May 2015 14:26:28 +0200
Subject: making versioned libpng-dev
In-Reply-To: <554B61FD.9010308@opencsw.org>
References: <554B1C68.7080504@opencsw.org>
	<61870791-8CF2-4E97-AEB2-62C0D4AE0E7C@opencsw.org>
	<554B61FD.9010308@opencsw.org>
Message-ID: <5C4BC66C-6BBF-4765-ADBA-7CB9BAEA124D@opencsw.org>

Hi Riccardo,

> Am 07.05.2015 um 15:00 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Dagobert Michelsen wrote:
>> No, but obsoleted for now. Add
>> OBSOLETED_BY_CSWlibpng16-dev += CSWlibpng-dev
>> and upload both packages at the same time.
> 
> stupid question: since you told me I can obsolete only once, I removed obsoletion from libpng15-dev
> Now I get file collisions there.
> Should I put override o file collisions? It is a problem that something can't be obsoleted twice!

No, just ignore the error. It will automatically go away when you upload all packages at once.

> I tried leaving the obsoletion in and in the uncommited package I don't get any errors except the fact that it is uncommited. Maybe I did understand the double obsoletion you mentioned?

The trick is the checkpkg will check all produced packages. As you have two Makefiles you have
to think what checkpkg would do when it would check all packages from both Makefiles. You are
hitting a special case. The only relevant check is the one during csw-upload-pkg.


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150513/0d74f5ad/attachment.p7s>

From rmottola at opencsw.org  Wed May 13 16:35:57 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 13 May 2015 16:35:57 +0200
Subject: problem with versioned libpng16 dev respin
In-Reply-To: <05D7A39D-7E8A-415B-A64C-7B31EC170D98@opencsw.org>
References: <5550BD0D.6040200@opencsw.org>
	<05D7A39D-7E8A-415B-A64C-7B31EC170D98@opencsw.org>
Message-ID: <5553614D.2060207@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Are you uploading CSWlibpng16-16 together with CSWlibpng16-dev ? You need to upload both at the same
> time or the database won?t know the destination of the .so symlink.
I tried to upload all regenereated 1.6 packages:
/opt/csw/bin/csw-upload-pkg is a wrapper, running 
/home/rmottola/opencsw/.buildsys/v2/bin/csw-upload-pkg 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz 
libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz 
libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz 
libpng_dev_stub-1.6.16,REV=2015.05.11-SunOS5.10-all-CSW.pkg.gz 
libpng_dev_stub-1.6.16,REV=2015.05.11-SunOS5.9-all-CSW.pkg.gz 
libpng_utils-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz 
libpng_utils-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz 
libpng_utils-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz 
libpng_utils-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz

My question is: why pentium_pro in 
/opt/csw/lib/pentium_pro/libpng16.so.16.16.0' ?
Is this a special rearrangement happening on solaris 11?

Riccardo

this is the full transcript:
Processing 22 file(s). Please wait.
Checking 8 packages against catalog unstable sparc SunOS5.11
Checking 6 packages against catalog unstable sparc SunOS5.9
Checking 6 packages against catalog unstable i386 SunOS5.9
Checking 8 packages against catalog unstable sparc SunOS5.10
Checking 8 packages against catalog unstable i386 SunOS5.10
WARNING 2015-05-13 16:30:56,065 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/lib/pentium_pro/libpng16.so.16.16.0'
Checking 8 packages against catalog unstable i386 SunOS5.11
WARNING 2015-05-13 16:31:18,371 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/lib/pentium_pro/libpng16.so.16.16.0'
Checks failed for the following catalogs:
   - i386 SunOS5.10
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz
     libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng_dev_stub-1.6.16,REV=2015.05.11-SunOS5.10-all-CSW.pkg.gz
     libpng_utils-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
To see the errors, run:
   /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py 
--catalog-release unstable --os-release SunOS5.10 --catalog-architecture 
i386 c353353fd815aeeef7bfcbfbe9b26d3c c353353fd815aeeef7bfcbfbe9b26d3c 
b602b1ed6a56070eacaf8f587556d17f 2576ddf732a227f88b5d03425fa6aebc 
b602b1ed6a56070eacaf8f587556d17f 2576ddf732a227f88b5d03425fa6aebc 
82b96ee89206580fcf987793ea98105e 91b5b03a7a8f907bd6091ccafeff7c75
Or check on the buildfarm:
http://buildfarm.opencsw.org/pkgdb/srv4/c353353fd815aeeef7bfcbfbe9b26d3c/
http://buildfarm.opencsw.org/pkgdb/srv4/c353353fd815aeeef7bfcbfbe9b26d3c/
http://buildfarm.opencsw.org/pkgdb/srv4/b602b1ed6a56070eacaf8f587556d17f/
http://buildfarm.opencsw.org/pkgdb/srv4/2576ddf732a227f88b5d03425fa6aebc/
http://buildfarm.opencsw.org/pkgdb/srv4/b602b1ed6a56070eacaf8f587556d17f/
http://buildfarm.opencsw.org/pkgdb/srv4/2576ddf732a227f88b5d03425fa6aebc/
http://buildfarm.opencsw.org/pkgdb/srv4/82b96ee89206580fcf987793ea98105e/
http://buildfarm.opencsw.org/pkgdb/srv4/91b5b03a7a8f907bd6091ccafeff7c75/
   - i386 SunOS5.11
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz
     libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
     libpng_dev_stub-1.6.16,REV=2015.05.11-SunOS5.10-all-CSW.pkg.gz
     libpng_utils-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz
To see the errors, run:
   /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py 
--catalog-release unstable --os-release SunOS5.11 --catalog-architecture 
i386 c353353fd815aeeef7bfcbfbe9b26d3c c353353fd815aeeef7bfcbfbe9b26d3c 
b602b1ed6a56070eacaf8f587556d17f 2576ddf732a227f88b5d03425fa6aebc 
b602b1ed6a56070eacaf8f587556d17f 2576ddf732a227f88b5d03425fa6aebc 
82b96ee89206580fcf987793ea98105e 91b5b03a7a8f907bd6091ccafeff7c75
Or check on the buildfarm:
http://buildfarm.opencsw.org/pkgdb/srv4/c353353fd815aeeef7bfcbfbe9b26d3c/
http://buildfarm.opencsw.org/pkgdb/srv4/c353353fd815aeeef7bfcbfbe9b26d3c/
http://buildfarm.opencsw.org/pkgdb/srv4/b602b1ed6a56070eacaf8f587556d17f/
http://buildfarm.opencsw.org/pkgdb/srv4/2576ddf732a227f88b5d03425fa6aebc/
http://buildfarm.opencsw.org/pkgdb/srv4/b602b1ed6a56070eacaf8f587556d17f/
http://buildfarm.opencsw.org/pkgdb/srv4/2576ddf732a227f88b5d03425fa6aebc/
http://buildfarm.opencsw.org/pkgdb/srv4/82b96ee89206580fcf987793ea98105e/
http://buildfarm.opencsw.org/pkgdb/srv4/91b5b03a7a8f907bd6091ccafeff7c75/
Your packages have not been submitted to the unstable catalog.



From dam at opencsw.org  Wed May 13 16:57:08 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 13 May 2015 16:57:08 +0200
Subject: problem with versioned libpng16 dev respin
In-Reply-To: <5553614D.2060207@opencsw.org>
References: <5550BD0D.6040200@opencsw.org>
	<05D7A39D-7E8A-415B-A64C-7B31EC170D98@opencsw.org>
	<5553614D.2060207@opencsw.org>
Message-ID: <55B3CBCF-7B68-456C-AE17-410329C54EDC@opencsw.org>

Hi Riccardo,

> Am 13.05.2015 um 16:35 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Dagobert Michelsen wrote:
>> Are you uploading CSWlibpng16-16 together with CSWlibpng16-dev ? You need to upload both at the same
>> time or the database won?t know the destination of the .so symlink.
> I tried to upload all regenereated 1.6 packages:
> /opt/csw/bin/csw-upload-pkg is a wrapper, running /home/rmottola/opencsw/.buildsys/v2/bin/csw-upload-pkg libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz libpng16_16-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz libpng16_dev-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz libpng_dev_stub-1.6.16,REV=2015.05.11-SunOS5.10-all-CSW.pkg.gz libpng_dev_stub-1.6.16,REV=2015.05.11-SunOS5.9-all-CSW.pkg.gz libpng_utils-1.6.16,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz libpng_utils-1.6.16,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz libpng_utils-1.6.16,REV=2015.05.11-SunOS5.9-i386-CSW.pkg.gz libpng_utils-1.6.16,REV=2015.05.11-SunOS5.9-sparc-CSW.pkg.gz
> 
> My question is: why pentium_pro in /opt/csw/lib/pentium_pro/libpng16.so.16.16.0' ?
> Is this a special rearrangement happening on solaris 11?

No, I would consider this an error. Which are the directories from which you built the packages?
Please commit what you have and I?ll 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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150513/418d4b6c/attachment.p7s>

From rmottola at opencsw.org  Wed May 13 17:25:38 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 13 May 2015 17:25:38 +0200
Subject: problem with versioned libpng16 dev respin
In-Reply-To: <55B3CBCF-7B68-456C-AE17-410329C54EDC@opencsw.org>
References: <5550BD0D.6040200@opencsw.org>	<05D7A39D-7E8A-415B-A64C-7B31EC170D98@opencsw.org>	<5553614D.2060207@opencsw.org>
	<55B3CBCF-7B68-456C-AE17-410329C54EDC@opencsw.org>
Message-ID: <55536CF2.9030906@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> No, I would consider this an error. Which are the directories from which you built the packages?
> Please commit what you have and I?ll have a look.

libpng 16 is fully committed. The pkgs, if needed, are in my pkgs directory.
It is trunk, derived from the same stuff I did the previous 
non-versioned one.

thank you,

Riccardo

From jgoerzen at opencsw.org  Fri May 15 20:50:26 2015
From: jgoerzen at opencsw.org (Jake Goerzen)
Date: Fri, 15 May 2015 11:50:26 -0700
Subject: automated catalog signing not running?
Message-ID: <55563FF2.8040604@opencsw.org>

Hi,

   I uploaded some packages with csw-upload-pkg but they have not shown 
up in the unstable catalog yet (haven't got an catalog update email 
notification either).   Also, looks like the mirrors are not updated.  
Perhaps the automated catalog signing is not running?

Best regards,
Jake

jgoerzen at login [login]:~/pkgs > csw-upload-pkg 
tor-0.2.6.7\,REV\=2015.05.11-SunOS5.10-*
/opt/csw/bin/csw-upload-pkg is a wrapper, running 
/home/jgoerzen/opencsw/.buildsys/v2/bin/csw-upload-pkg 
tor-0.2.6.7,REV=2015.05.11-SunOS5.10-i386-CSW.pkg.gz 
tor-0.2.6.7,REV=2015.05.11-SunOS5.10-sparc-CSW.pkg.gz
Processing 2 file(s). Please wait.
Checking 1 package against catalog unstable i386 SunOS5.10
WARNING 2015-05-15 01:24:14,219 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:14,221 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:14,221 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:14,222 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
Checking 1 package against catalog unstable sparc SunOS5.10
WARNING 2015-05-15 01:24:35,483 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:35,484 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:35,485 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:35,486 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
Checking 1 package against catalog unstable i386 SunOS5.11
WARNING 2015-05-15 01:24:52,022 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:52,023 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:52,024 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:24:52,025 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
Checking 1 package against catalog unstable sparc SunOS5.11
WARNING 2015-05-15 01:25:08,543 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:25:08,544 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:25:08,545 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
WARNING 2015-05-15 01:25:08,546 checkpkg_lib.py:658 Did not find 
packages for '/opt/csw/bin/isaexec'
All checks successful. Proceeding.
Inserting tor (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting tor (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting tor (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting tor (sparc SunOS5.10) into catalog unstable sparc SunOS5.11


From dam at opencsw.org  Fri May 15 20:52:56 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 15 May 2015 20:52:56 +0200
Subject: automated catalog signing not running?
In-Reply-To: <55563FF2.8040604@opencsw.org>
References: <55563FF2.8040604@opencsw.org>
Message-ID: <1F341D20-824A-40C4-B2A7-279818060860@opencsw.org>

Hi Jake,

Am 15.05.2015 um 20:50 schrieb Jake Goerzen:
>  I uploaded some packages with csw-upload-pkg but they have not shown up in the unstable catalog yet (haven't got an catalog update email notification either).   Also, looks like the mirrors are not updated.  Perhaps the automated catalog signing is not running?

It is not. I already contacted Ben to restart the daemon.


Best regards

  -- Dago

From jgoerzen at opencsw.org  Fri May 15 20:55:39 2015
From: jgoerzen at opencsw.org (Jake Goerzen)
Date: Fri, 15 May 2015 11:55:39 -0700
Subject: automated catalog signing not running?
In-Reply-To: <1F341D20-824A-40C4-B2A7-279818060860@opencsw.org>
References: <55563FF2.8040604@opencsw.org>
	<1F341D20-824A-40C4-B2A7-279818060860@opencsw.org>
Message-ID: <5556412B.2050709@opencsw.org>

Hi Dago,

On 5/15/2015 11:52 AM, Dagobert Michelsen wrote:
> Hi Jake,
>
> Am 15.05.2015 um 20:50 schrieb Jake Goerzen:
>>   I uploaded some packages with csw-upload-pkg but they have not shown up in the unstable catalog yet (haven't got an catalog update email notification either).   Also, looks like the mirrors are not updated.  Perhaps the automated catalog signing is not running?
> It is not. I already contacted Ben to restart the daemon.
>

Oh okay,  no problems :) I will continue my work once Ben has restart.

Thanks,
Jake

From dam at opencsw.org  Sat May 16 23:47:27 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 16 May 2015 23:47:27 +0200
Subject: Stripping destroys 'go' binaries
Message-ID: <CBF50816-86DD-450E-BFAD-191CD87BD1B2@opencsw.org>

Hi folks,

when fiddling with logstash and logstash-forwarder I noticed that the automatic
stripping in mGAR corrupt executables:

> root at experimental10s [experimental10s]:/home/dam/mgar/pkg/logstash-forwarder/trunk/work/solaris10-sparc > file pkgroot/opt/csw/bin/logstash-forwarder build-isa-sparcv8plus/logstash-forwarder-0.4.0/logstash-forwarder
> pkgroot/opt/csw/bin/logstash-forwarder:       ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped
> build-isa-sparcv8plus/logstash-forwarder-0.4.0/logstash-forwarder:      ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped


Stripped, does not work:

> root at experimental10s [experimental10s]:/home/dam/mgar/pkg/logstash-forwarder/trunk/work/solaris10-sparc > pkgroot/opt/csw/bin/logstash-forwarder 
> no debug info in ELF executable errno -1
> fatal error: no debug info in ELF executable
> 
> runtime stack:
> no debug info in ELF executable errno -1
> panic during panic
> zsh: 23869 exit 3     pkgroot/opt/csw/bin/logstash-forwarder

Freshly compiled with gccgo, not stripped, works:

> root at experimental10s [experimental10s]:/home/dam/mgar/pkg/logstash-forwarder/trunk/work/solaris10-sparc/build-isa-sparcv8plus/logstash-forwarder-0.4.0 > ./logstash-forwarder
> 2015/05/16 23:41:42.699396 fatal: config file must be defined
> zsh: 23856 exit 1     ./logstash-forwarder

This was all compiled with our "broken" gcc 4.9.2.

@Maciej: Would you mind retrying with our infra-script?


Best regards

  -- Dago

From jh at opencsw.org  Sun May 17 10:00:41 2015
From: jh at opencsw.org (=?windows-1252?Q?Jan_Holzh=FCter?=)
Date: Sun, 17 May 2015 10:00:41 +0200
Subject: Stripping destroys 'go' binaries
In-Reply-To: <CBF50816-86DD-450E-BFAD-191CD87BD1B2@opencsw.org>
References: <CBF50816-86DD-450E-BFAD-191CD87BD1B2@opencsw.org>
Message-ID: <55584AA9.5090002@opencsw.org>

Hi,

Am 16.05.15 um 23:47 schrieb Dagobert Michelsen:
> Hi folks,
> 
> when fiddling with logstash and logstash-forwarder I noticed that the automatic
> stripping in mGAR corrupt executables:
> 
>> root at experimental10s [experimental10s]:/home/dam/mgar/pkg/logstash-forwarder/trunk/work/solaris10-sparc > file pkgroot/opt/csw/bin/logstash-forwarder build-isa-sparcv8plus/logstash-forwarder-0.4.0/logstash-forwarder
>> pkgroot/opt/csw/bin/logstash-forwarder:       ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped
>> build-isa-sparcv8plus/logstash-forwarder-0.4.0/logstash-forwarder:      ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
> 
> 
> Stripped, does not work:
> 
>> root at experimental10s [experimental10s]:/home/dam/mgar/pkg/logstash-forwarder/trunk/work/solaris10-sparc > pkgroot/opt/csw/bin/logstash-forwarder 
>> no debug info in ELF executable errno -1
>> fatal error: no debug info in ELF executable
>>
>> runtime stack:
>> no debug info in ELF executable errno -1
>> panic during panic
>> zsh: 23869 exit 3     pkgroot/opt/csw/bin/logstash-forwarder
> 
> Freshly compiled with gccgo, not stripped, works:
> 
>> root at experimental10s [experimental10s]:/home/dam/mgar/pkg/logstash-forwarder/trunk/work/solaris10-sparc/build-isa-sparcv8plus/logstash-forwarder-0.4.0 > ./logstash-forwarder
>> 2015/05/16 23:41:42.699396 fatal: config file must be defined
>> zsh: 23856 exit 1     ./logstash-forwarder
> 
> This was all compiled with our "broken" gcc 4.9.2.

Is this stripped with gnu strip or the SUN one?

GNU tends to brake stuff:
https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/ffmpeg/trunk/Makefile#200

Greetings
Jan








From grzemba at contac-dt.de  Tue May 19 11:02:10 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Tue, 19 May 2015 11:02:10 +0200
Subject: OSQA Google oauth2client problem
In-Reply-To: <bf3d8173715e.555afc01@contac-dt.de>
References: <bf3ddcc23d03.555afb4c@contac-dt.de>
	<bf3df9b064ff.555afb89@contac-dt.de>
	<bf3dfc4c6a40.555afbc5@contac-dt.de>
	<bf3d8173715e.555afc01@contac-dt.de>
Message-ID: <bf3de14f548f.555b1832@contac-dt.de>

Hi

I try to setup login at OSQA (www.opencsw.org/communtity) with Google+ Id but without luck

This is the error:
/opt/csw/lib/python2.7/site-packages/oauth2client/client.py TIME: 2015-05-19 10:37:56,250 MSG: client.py:step2_exchange:2001 Failed to retrieve access token: {
 "error" : "redirect_uri_mismatch"
}

Is there anyone how knows where ist the problem? How can I fix this?

Thanks
Carsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150519/d98caa47/attachment.html>

From rmottola at opencsw.org  Tue May 19 11:46:30 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 19 May 2015 11:46:30 +0200
Subject: libpng15 + dev respin
In-Reply-To: <5550A1EC.3050100@opencsw.org>
References: <5550A1EC.3050100@opencsw.org>
Message-ID: <555B0676.8030500@opencsw.org>

Hi,

Riccardo Mottola wrote:
> Hi,
>
> especially for Laurent: I was finally able to do a libpng-15 respin 
> with its dev versioned dev package.
> The dev-package is really minimal but I hope it is enough? IN case 
> please add yourself or tell me which precise file to add, one by one, 
> explicitely.
>
> I uploaded it successully, perhaps they can be already installed on 
> the buildfarm
>
> I am still working on the 16 package: I get a strange error I didn't 
> get in the unversioned one and it makes no sense since I did not 
> change anything in the content of the packages when versioning. I am 
> doing a total clean build on all platforms and it takes a lot of time.

are the new versioned dev packages actually installed and work? do they 
solve your problems, bring new ones?

Riccardo

From dam at opencsw.org  Tue May 19 11:46:58 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 19 May 2015 11:46:58 +0200
Subject: libpng15 + dev respin
In-Reply-To: <555B0676.8030500@opencsw.org>
References: <5550A1EC.3050100@opencsw.org> <555B0676.8030500@opencsw.org>
Message-ID: <6148A7E0-A55E-45EF-B392-5AC34536A005@opencsw.org>

Hi Riccardo,

Am 19.05.2015 um 11:46 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Riccardo Mottola wrote:
>> Hi,
>> 
>> especially for Laurent: I was finally able to do a libpng-15 respin with its dev versioned dev package.
>> The dev-package is really minimal but I hope it is enough? IN case please add yourself or tell me which precise file to add, one by one, explicitely.
>> 
>> I uploaded it successully, perhaps they can be already installed on the buildfarm
>> 
>> I am still working on the 16 package: I get a strange error I didn't get in the unversioned one and it makes no sense since I did not change anything in the content of the packages when versioning. I am doing a total clean build on all platforms and it takes a lot of time.
> 
> are the new versioned dev packages actually installed and work? do they solve your problems, bring new ones?

I have reproduced your issue about the missing symlink destination which prohibits
an upload of the packages. I am still looking into the issue as the root cause is
not easily visible.


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150519/5806bc99/attachment.p7s>

From rmottola at opencsw.org  Tue May 19 11:56:05 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 19 May 2015 11:56:05 +0200
Subject: libpng15 + dev respin
In-Reply-To: <6148A7E0-A55E-45EF-B392-5AC34536A005@opencsw.org>
References: <5550A1EC.3050100@opencsw.org> <555B0676.8030500@opencsw.org>
	<6148A7E0-A55E-45EF-B392-5AC34536A005@opencsw.org>
Message-ID: <555B08B5.5050804@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> I have reproduced your issue about the missing symlink destination which prohibits
> an upload of the packages. I am still looking into the issue as the root cause is
> not easily visible.

I always discover nasty stuffy :(

Riccardo

From laurent at opencsw.org  Wed May 20 21:25:32 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Wed, 20 May 2015 21:25:32 +0200
Subject: libpng15 + dev respin
In-Reply-To: <5550A1EC.3050100@opencsw.org>
References: <5550A1EC.3050100@opencsw.org>
Message-ID: <555CDFAC.1020701@opencsw.org>

Hello,

The ball has been tackled a bit further, but that rabbit hole is deep.
That one is for Rafi.

Symptom:
In file included from coders/pango.c:71:0:
/opt/csw/include/pango-1.0/pango/pangocairo.h:26:19: fatal error: 
cairo.h: No such file or directory
  #include <cairo.h>

The configure script called:
$ /opt/csw/bin/pkg-config --cflags "cairo-svg"
sh: gnome-config: introuvable
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpng', required by 'cairo', not found

The cause is in cairo.pc:
Requires.private:   gobject-2.0 glib-2.0      pixman-1 >= 0.16.0 
fontconfig >= 2.2.95 freetype2 >= 9.7.3   libpng xrender >= 0.6 x11 xext

It has to be modified in the cairo_dev package to match the library 
used, eg it should be ?libpng15? here (so it picks up libpng15.pc).


Laurent


Le 2015/05/11 14:34 +0200, Riccardo Mottola a ?crit:
> Hi,
>
> especially for Laurent: I was finally able to do a libpng-15 respin with
> its dev versioned dev package.
> The dev-package is really minimal but I hope it is enough? IN case
> please add yourself or tell me which precise file to add, one by one,
> explicitely.
>
> I uploaded it successully, perhaps they can be already installed on the
> buildfarm
>
> I am still working on the 16 package: I get a strange error I didn't get
> in the unversioned one and it makes no sense since I did not change
> anything in the content of the packages when versioning. I am doing a
> total clean build on all platforms and it takes a lot of time.
>
> Riccardo
>




From dam at opencsw.org  Thu May 21 09:32:16 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 21 May 2015 09:32:16 +0200
Subject: libpng15 + dev respin
In-Reply-To: <555CDFAC.1020701@opencsw.org>
References: <5550A1EC.3050100@opencsw.org> <555CDFAC.1020701@opencsw.org>
Message-ID: <57D41111-4A05-4806-9EBD-703165249FD6@opencsw.org>

Hi Laurent,

> Am 20.05.2015 um 21:25 schrieb Laurent Blume <laurent at opencsw.org>:
> 
> Hello,
> 
> The ball has been tackled a bit further, but that rabbit hole is deep.
> That one is for Rafi.
> 
> Symptom:
> In file included from coders/pango.c:71:0:
> /opt/csw/include/pango-1.0/pango/pangocairo.h:26:19: fatal error: cairo.h: No such file or directory
> #include <cairo.h>
> 
> The configure script called:
> $ /opt/csw/bin/pkg-config --cflags "cairo-svg"
> sh: gnome-config: introuvable
> Package libpng was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libpng.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libpng', required by 'cairo', not found
> 
> The cause is in cairo.pc:
> Requires.private:   gobject-2.0 glib-2.0      pixman-1 >= 0.16.0 fontconfig >= 2.2.95 freetype2 >= 9.7.3   libpng xrender >= 0.6 x11 xext
> 
> It has to be modified in the cairo_dev package to match the library used, eg it should be ?libpng15? here (so it picks up libpng15.pc).

Wouldn?t it be better to have the latest CSWlibpng16-dev provide a symlink?
  /opt/csw/lib/pkgconfig/libpng.pc -> libpng16.pc

The import of the unversioned pkgconfig-file seems to have happened some time ago.
Probably some configure-scripts still contain the search for libpng.pc only?


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150521/690ca598/attachment-0001.p7s>

From rmottola at opencsw.org  Thu May 21 09:37:28 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 21 May 2015 09:37:28 +0200
Subject: libpng15 + dev respin
In-Reply-To: <57D41111-4A05-4806-9EBD-703165249FD6@opencsw.org>
References: <5550A1EC.3050100@opencsw.org> <555CDFAC.1020701@opencsw.org>
	<57D41111-4A05-4806-9EBD-703165249FD6@opencsw.org>
Message-ID: <555D8B38.8020408@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Wouldn?t it be better to have the latest CSWlibpng16-dev provide a symlink?
>    /opt/csw/lib/pkgconfig/libpng.pc -> libpng16.pc
>
> The import of the unversioned pkgconfig-file seems to have happened some time ago.
> Probably some configure-scripts still contain the search for libpng.pc only?

it will provide a symlink if I did it right, I can't upload it though, 
for the problem you were looking at, Dago. No guarantee it will solve 
anything, but at least it will be consistent.

Riccardo

From laurent at opencsw.org  Thu May 21 11:48:49 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 21 May 2015 11:48:49 +0200
Subject: libpng15 + dev respin
In-Reply-To: <57D41111-4A05-4806-9EBD-703165249FD6@opencsw.org>
References: <5550A1EC.3050100@opencsw.org> <555CDFAC.1020701@opencsw.org>
	<57D41111-4A05-4806-9EBD-703165249FD6@opencsw.org>
Message-ID: <555DAA01.3000804@opencsw.org>

Le 2015/05/21 09:32 +0200, Dagobert Michelsen a ?crit:
> Wouldn?t it be better to have the latest CSWlibpng16-dev provide a symlink?
>   /opt/csw/lib/pkgconfig/libpng.pc -> libpng16.pc

I thought about that, but no. It really needs libpng15, specifically.
Remember it will also add -lpng15 and other versioned stuff. I don't
want to think about doing a build that uses cairo asking for png15 while
using png16 for the current source.

> The import of the unversioned pkgconfig-file seems to have happened some time ago.
> Probably some configure-scripts still contain the search for libpng.pc only?

I don't think so. I checked, it's the same with CentOS 7.1. It's just
the way it's done is a mess. I don't believe many distros try to do what
we're doing, having two different versions concurrently.

Laurent

From rmottola at opencsw.org  Thu May 21 17:01:56 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 21 May 2015 17:01:56 +0200
Subject: libpng15 + dev respin
In-Reply-To: <555CDFAC.1020701@opencsw.org>
References: <5550A1EC.3050100@opencsw.org> <555CDFAC.1020701@opencsw.org>
Message-ID: <555DF364.2050608@opencsw.org>

Hi,

Laurent Blume wrote:
>
> The cause is in cairo.pc:
> Requires.private:   gobject-2.0 glib-2.0      pixman-1 >= 0.16.0 
> fontconfig >= 2.2.95 freetype2 >= 9.7.3   libpng xrender >= 0.6 x11 xext
>
> It has to be modified in the cairo_dev package to match the library 
> used, eg it should be ?libpng15? here (so it picks up libpng15.pc).

you should have libpng15.pc and libpng16.pc now. What is the problem As 
you describe it it is not in the png package but in the cairo package.

I understand that you want cairo-dev always pick up the current png, but 
"record" which version it is using, e.g.  png15, so that when png16 
comes out it continues to work.

Perhaps rebuilding cairo-dev helps? Perhaps it is not natively possible.


As soon as I can upload the new png packages, the frist person that will 
rebuild cairo will need to update this:

BUILD_DEP_PKGS += CSWlibpng-dev
to
BUILD_DEP_PKGS += CSWlibpng16-dev

I will try that, but I don't know if it will "fix" the issue you are 
seeing, when libpng17 will be out.

Riccardo

From grzemba at contac-dt.de  Fri May 22 14:22:27 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Fri, 22 May 2015 14:22:27 +0200
Subject: merge 64bit sysconfig dir
In-Reply-To: <bbb19e5212da.555f1f54@contac-dt.de>
References: <bbb19e5212da.555f1f54@contac-dt.de>
Message-ID: <bbb1ad706d7c.555f3ba3@contac-dt.de>

Hi, 
is there a special magic to merge file from sysconfigdir? In this case I miss modules-64.conf in pkgroot:

?install-isa-amd64/etc/opt/csw/apache2
install-isa-amd64/etc/opt/csw/apache2/extra
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-manual.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-ssl.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-userdir.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-languages.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-mpm.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-info.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-vhosts.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-dav.conf
install-isa-amd64/etc/opt/csw/apache2/extra/proxy-html.conf
install-isa-amd64/etc/opt/csw/apache2/extra/modules-64.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-multilang-errordoc.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-autoindex.conf
install-isa-amd64/etc/opt/csw/apache2/extra/httpd-default.conf
install-isa-amd64/etc/opt/csw/apache2/envvars
install-isa-amd64/etc/opt/csw/apache2/magic
install-isa-amd64/etc/opt/csw/apache2/mime.types
install-isa-amd64/etc/opt/csw/apache2/envvars-std
install-isa-amd64/etc/opt/csw/apache2/server
install-isa-amd64/etc/opt/csw/apache2/httpd.conf
install-isa-pentium_pro/etc/opt/csw/apache2
install-isa-pentium_pro/etc/opt/csw/apache2/extra
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-vhosts.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/modules-32.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-multilang-errordoc.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-userdir.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-manual.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-languages.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/proxy-html.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-ssl.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-autoindex.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-info.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-default.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-mpm.conf
install-isa-pentium_pro/etc/opt/csw/apache2/extra/httpd-dav.conf
install-isa-pentium_pro/etc/opt/csw/apache2/httpd.conf
install-isa-pentium_pro/etc/opt/csw/apache2/server
install-isa-pentium_pro/etc/opt/csw/apache2/magic
install-isa-pentium_pro/etc/opt/csw/apache2/envvars-std
install-isa-pentium_pro/etc/opt/csw/apache2/envvars
install-isa-pentium_pro/etc/opt/csw/apache2/mime.types
pkgroot/etc/opt/csw/apache2
pkgroot/etc/opt/csw/apache2/envvars.CSW
pkgroot/etc/opt/csw/apache2/httpd.conf.CSW
pkgroot/etc/opt/csw/apache2/mime.types.CSW
pkgroot/etc/opt/csw/apache2/envvars-std.CSW
pkgroot/etc/opt/csw/apache2/extra
pkgroot/etc/opt/csw/apache2/extra/httpd-vhosts.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-ssl.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-default.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-multilang-errordoc.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-mpm.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/modules-32.conf
pkgroot/etc/opt/csw/apache2/extra/proxy-html.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-languages.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-dav.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-autoindex.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-userdir.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-manual.conf.CSW
pkgroot/etc/opt/csw/apache2/extra/httpd-info.conf.CSW
pkgroot/etc/opt/csw/apache2/magic.CSW
pkgroot/etc/opt/csw/apache2/server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150522/e8646c07/attachment.html>

From dam at opencsw.org  Fri May 22 14:38:02 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 22 May 2015 14:38:02 +0200
Subject: merge 64bit sysconfig dir
In-Reply-To: <bbb1ad706d7c.555f3ba3@contac-dt.de>
References: <bbb19e5212da.555f1f54@contac-dt.de>
	<bbb1ad706d7c.555f3ba3@contac-dt.de>
Message-ID: <2FC23A5E-74EA-4C22-8F3E-5B0B7953D300@opencsw.org>

Hi Carsten,

> Am 22.05.2015 um 14:22 schrieb Carsten Grzemba <grzemba at contac-dt.de>:
> 
> Hi, 
> is there a special magic to merge file from sysconfigdir? In this case I miss modules-64.conf in pkgroot:

$(sysconfdir) is not merged from ISA different from the default:
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.mk#779

The existing solution is using /etc/opt/csw/64 for 64 bit applications:
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/pango/trunk/Makefile#141

You could probable try this to achieve the layout you envision:
  EXTRA_MERGE_DIRS_isa-extra += $(sysconfdir)
Please keep in mind that all files from the 64 bit ISA. Or try
  EXTRA_MERGE_DIRS_isa-extra += $(sysconfdir)/apache2/extra/modules-64.conf
for just the file. I haven?t tried it but it should work.


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: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150522/31e0adf2/attachment-0001.p7s>

From rmottola at opencsw.org  Fri May 22 14:43:10 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 22 May 2015 14:43:10 +0200
Subject: error for uncommited when it is
Message-ID: <555F245E.10301@opencsw.org>

Hi,

Even if I remerge & repackage, I do get:

CHECKPKG_OVERRIDES_CSWbinutils += pkginfo-opencsw-repository-uncommitted


however, the repo is commited:

svn status
?       work-old


No differences... where is this information tracked??

Riccardo

From dam at opencsw.org  Fri May 22 14:46:02 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 22 May 2015 14:46:02 +0200
Subject: error for uncommited when it is
In-Reply-To: <555F245E.10301@opencsw.org>
References: <555F245E.10301@opencsw.org>
Message-ID: <F9C7C4DA-EDD5-418F-9ECF-5ED0EBA5714E@opencsw.org>

Hi Riccardo,

Am 22.05.2015 um 14:43 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Even if I remerge & repackage, I do get:
> 
> CHECKPKG_OVERRIDES_CSWbinutils += pkginfo-opencsw-repository-uncommitted
> 
> 
> however, the repo is commited:
> 
> svn status
> ?       work-old
> 
> No differences... where is this information tracked??

When you do ?mgar spotless? it moves work to work-old and removes
that in the background:
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.mk#1014

You just need to wait a while and check with svn status if it 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

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

From rmottola at opencsw.org  Sat May 23 19:36:38 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sat, 23 May 2015 19:36:38 +0200
Subject: binutils: bad placement of files
Message-ID: <5560BAA6.6080300@opencsw.org>

Hi,

I am tyring to rebuild binutils: same release as currently available on 
solaris 10: 2.24, no updates. I want to rebuild it for Solaris 9, I had 
to clean up dependencies for x86/Solaris10 in just a little better way.

During build, I noticed a lot of messages about grep being unsupported: 
they way the package tried to froce GNU grep did not work, Dago 
suggested a new one.

Now I get really a lot of overrides, for hundreds of files:

CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x149.xu
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x155.x
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x155.xbn
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x155.xn
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x155.xr
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x155.xu
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x156.x
CHECKPKG_OVERRIDES_CSWbinutils += 
bad-location-of-file|file=/usr/local/sparc-sun-solaris2.10/lib/ldscripts/msp430x156.xbn

what can be done? they shouldn't go in /usr/local I suppose.

I checked where one of those file is installed now in /opt/csw :
/opt/csw/sparc-sun-solaris2.10/lib/ldscripts/msp430x155.xr

even that is not that nice, but i wonder why they don't go there anymore.

EXTRA_CONFIGURE_EXPORTS += GREP
CONFIGURE_ENV_GREP = /opt/csw/bin/ggrep


maybe this confuses configure path?

Riccardo

From rmottola at opencsw.org  Mon May 25 10:05:42 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 25 May 2015 10:05:42 +0200
Subject: rebuilding gcc4 on solaris 9
Message-ID: <5562D7D6.6000301@opencsw.org>

Hi,

current gcc4 on Solaris 9 is 4.6.3, I failed to build 4.8/4.9 with 
assembler problems.
These problems are apparently caused by outdated binutils and compiler 
used for bootstrap.

I was able to update binutils finally, so that all solaris version have 
2.24 (I'll work on 2.25 later).

I am unable to rebuild gcc 4.6.3, which I found in the branch! I hoped 
it would be a no-brainer, but it is not.

I get this:
checking for installed CLooG ISL... ISL
checking for version 0.16.1 of CLooG... no
configure: error: Unable to find a usable CLooG.  See config.log for 
details.
gmake[1]: *** 
[configure-work/solaris9-sparc/build-isa-sparcv8/gcc-4.6.3/configure] 
Error 1

but CLooG is installed and gcc 4.8/4.9 do not give this error...


application CSWcloog-dev                     cloog_dev - Code Generator 
in the Polyhedral Model, development files
application CSWlibcloog-isl2                 libcloog_isl2 - Code 
Generator in the Polyhedral Model, libcloog-isl.so.2
application CSWlibcloog-isl4                 libcloog_isl4 - Code 
Generator in the Polyhedral Model, libcloog-isl.so.4

Is something mssing?

the configure command line is:
   $ 
/home/rmottola/opencsw/gcc4/branches/gcc-4.6.x/work/solaris9-sparc/build-isa-sparcv8/gcc-4.6.3/configure 
--program-suffix=-4.6 --prefi
x=/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 --with-gnu-as 
--with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld 
--enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw 
--with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --with-ppl=/opt/c
sw --with-cloog=/opt/csw --enable-cloog-backend=isl 
--enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc 
--enable-threa
ds=posix --enable-languages=ada,c,c++,fortran,java,objc 
--with-system-zlib=/opt/csw --with-cpu=v8

the failed check is:

configure:6052: checking for version 0.16.1 of CLooG
configure:6070: /opt/csw/bin/gcc-4.6 -c -g -O2 -I/opt/csw/include 
-DCLOOG_INT_GMP -DCLOOG_ORG -I/opt/csw/include  -I/opt/csw/include -I/op
t/csw/include   conftest.c >&5
conftest.c: In function 'main':
conftest.c:15:5: error: unknown type name 'choke'
configure:6070: $? = 1
configure: failed program was:

but I see the includes:
./include/cloog/cloog.h
./include/cloog/isl/cloog.h

Help!

Riccardo


PS:
I also get these warnings: is the receipe old? what is the problem?
gar/category.mk:24: The categories with no special meaning have been 
renamed to 'default', please remove the CATEGORIES line as for the 
default case this is no longer necessary
gmake[1]: Entering directory 
`/home/rmottola/opencsw/gcc4/branches/gcc-4.6.x'
gar/category.mk:24: The categories with no special meaning have been 
renamed to 'default', please remove the CATEGORIES line as for the 
default case this is no longer necessary




From dam at opencsw.org  Mon May 25 19:00:48 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 25 May 2015 19:00:48 +0200
Subject: rebuilding gcc4 on solaris 9
In-Reply-To: <5562D7D6.6000301@opencsw.org>
References: <5562D7D6.6000301@opencsw.org>
Message-ID: <B4E11D12-8F60-473F-9B95-32A8A2B46A90@opencsw.org>

Hi Riccardo,

Am 25.05.2015 um 10:05 schrieb Riccardo Mottola:
> current gcc4 on Solaris 9 is 4.6.3, I failed to build 4.8/4.9 with assembler problems.
> These problems are apparently caused by outdated binutils and compiler used for bootstrap.
> 
> I was able to update binutils finally, so that all solaris version have 2.24 (I'll work on 2.25 later).
> 
> I am unable to rebuild gcc 4.6.3, which I found in the branch! I hoped it would be a no-brainer, but it is not.
> 
> I get this:
> checking for installed CLooG ISL... ISL
> checking for version 0.16.1 of CLooG... no
> configure: error: Unable to find a usable CLooG.  See config.log for details.
> gmake[1]: *** [configure-work/solaris9-sparc/build-isa-sparcv8/gcc-4.6.3/configure] Error 1
> 
> but CLooG is installed and gcc 4.8/4.9 do not give this error...
> 
> application CSWcloog-dev                     cloog_dev - Code Generator in the Polyhedral Model, development files
> application CSWlibcloog-isl2                 libcloog_isl2 - Code Generator in the Polyhedral Model, libcloog-isl.so.2
> application CSWlibcloog-isl4                 libcloog_isl4 - Code Generator in the Polyhedral Model, libcloog-isl.so.4
> 
> Is something mssing?
> 
> the configure command line is:
> $ /home/rmottola/opencsw/gcc4/branches/gcc-4.6.x/work/solaris9-sparc/build-isa-sparcv8/gcc-4.6.3/configure --program-suffix=-4.6 --prefi
> x=/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 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --with-ppl=/opt/c
> sw --with-cloog=/opt/csw --enable-cloog-backend=isl --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threa
> ds=posix --enable-languages=ada,c,c++,fortran,java,objc --with-system-zlib=/opt/csw --with-cpu=v8
> 
> the failed check is:
> 
> configure:6052: checking for version 0.16.1 of CLooG
> configure:6070: /opt/csw/bin/gcc-4.6 -c -g -O2 -I/opt/csw/include -DCLOOG_INT_GMP -DCLOOG_ORG -I/opt/csw/include  -I/opt/csw/include -I/op
> t/csw/include   conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:15:5: error: unknown type name 'choke'
> configure:6070: $? = 1
> configure: failed program was:
> 
> but I see the includes:
> ./include/cloog/cloog.h
> ./include/cloog/isl/cloog.h
> 
> Help!

Dig deeper. The failing code is given in config.log, copy+paste that and try invoking
gcc manually, if that doesn't help inspect the output of using -E (print output after
preprocessing) and see why the definition of "choke" is missing by following the
gcc header inclusion trail.


Best regards

 -- Dago

From rmottola at opencsw.org  Tue May 26 17:34:42 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 26 May 2015 17:34:42 +0200
Subject: rebuilding gcc4 on solaris 9
In-Reply-To: <B4E11D12-8F60-473F-9B95-32A8A2B46A90@opencsw.org>
References: <5562D7D6.6000301@opencsw.org>
	<B4E11D12-8F60-473F-9B95-32A8A2B46A90@opencsw.org>
Message-ID: <55649292.3090302@opencsw.org>

Hi..

sometimes if you dig to deep....


Dagobert Michelsen wrote:
> Dig deeper. The failing code is given in config.log, copy+paste that and try invoking
> gcc manually, if that doesn't help inspect the output of using -E (print output after
> preprocessing) and see why the definition of "choke" is missing by following the
> gcc header inclusion trail.

configure:6052: checking for version 0.16.1 of CLooG
configure:6070: /opt/csw/bin/gcc-4.6 -c -g -O2 -I/opt/csw/include 
-DCLOOG_INT_GMP -DCLOOG_ORG -I/opt/csw/include  -I/opt/csw/include -
I/opt/csw/include   conftest.c >&5
conftest.c: In function 'main':
conftest.c:15:5: error: unknown type name 'choke'
configure:6070: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h.  */
| #include "cloog/cloog.h"
| int
| main ()
| {
| #if CLOOG_VERSION_MAJOR != 0     || CLOOG_VERSION_MINOR != 16 || 
CLOOG_VERSION_REVISION < 1
|     choke me
|    #endif
|   ;
|   return 0;
| }
configure:6077: result: no
configure:6160: error: Unable to find a usable CLooG.  See config.log 
for details.

| #if CLOOG_VERSION_MAJOR != 0     || CLOOG_VERSION_MINOR < 16     || 
CLOOG_VERSION_REVISION < 1


The test seems to be written to accept ONLY 0.16.x where is > 1

we have:
#define CLOOG_VERSION_MAJOR 0
#define CLOOG_VERSION_MINOR 18
#define CLOOG_VERSION_REVISION 2

What is this dependency for? may I disable it? Or I could try to patch 
the test to accept also new stuff.


Riccardo


From rmottola at opencsw.org  Thu May 28 09:12:14 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 28 May 2015 09:12:14 +0200
Subject: rebuilding gcc4 on solaris 9
In-Reply-To: <B4E11D12-8F60-473F-9B95-32A8A2B46A90@opencsw.org>
References: <5562D7D6.6000301@opencsw.org>
	<B4E11D12-8F60-473F-9B95-32A8A2B46A90@opencsw.org>
Message-ID: <5566BFCE.3030103@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Dig deeper. The failing code is given in config.log, copy+paste that and try invoking
> gcc manually, if that doesn't help inspect the output of using -E (print output after
> preprocessing) and see why the definition of "choke" is missing by following the
> gcc header inclusion trail.

older version need exactly a certain cloog version.

Cloog is only needed for certain high-level optimizations, I disabled 
it. I guess it is easier than trying to have more than one cloog version 
on the system. I tried to patch to use a newer cloog version, but build 
fails.

gcc 4.6.3 is building since yesterday and still going. Unstable9s is not 
that fast apparently:) And I still need x86 too

If it builds successfully I will try to upgrade at least to 4.6.4


How can I build only for solaris9 ? I would prefer not to build 
solaris10 at all!
My question regards solaris x86: I think that a 64bit is always 
required, but solaris 9 doesn't have one so platforms builds on 10 and 
merges in: this would be though a huge time expense. Can it be overridden?

Riccardo

From maciej at opencsw.org  Sat May 30 17:00:10 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 30 May 2015 16:00:10 +0100
Subject: Stripping destroys 'go' binaries
In-Reply-To: <CBF50816-86DD-450E-BFAD-191CD87BD1B2@opencsw.org>
References: <CBF50816-86DD-450E-BFAD-191CD87BD1B2@opencsw.org>
Message-ID: <CALtRa-6jbgT1gczrBdWVfL0yjkAfMMkX+kSTgTojpo8W7ckBRw@mail.gmail.com>

2015-05-16 22:47 GMT+01:00 Dagobert Michelsen <dam at opencsw.org>:
>
> Stripped, does not work:

It is (was?) a known bug / feature.

> @Maciej: Would you mind retrying with our infra-script?

Sorry, I'm not sure what you're asking, which infra-script? The
problem we've experienced with gccgo >=4.9 is not related to
stripping, I did not strip the binary.

Maciej

From bwalton at opencsw.org  Sun May 31 18:35:20 2015
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 31 May 2015 16:35:20 +0000
Subject: Goodbye, Sourceforge!
Message-ID: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>

http://helb.github.io/goodbye-sourceforge/

Shall we move our code?

Thanks
-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150531/1dcc1767/attachment.html>

From ihsan at opencsw.org  Sun May 31 18:46:39 2015
From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=)
Date: Sun, 31 May 2015 18:46:39 +0200
Subject: Goodbye, Sourceforge!
In-Reply-To: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>
References: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>
Message-ID: <556B3AEF.9020203@opencsw.org>

Am 31.05.2015 um 18:35 schrieb Ben Walton:

> http://helb.github.io/goodbye-sourceforge/
> 
> Shall we move our code?

That's definitely a good idea. Most projects have moved to github these
days anyway.



Ihsan

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

From pfelecan at opencsw.org  Sun May 31 19:38:03 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 31 May 2015 19:38:03 +0200
Subject: Goodbye, Sourceforge!
In-Reply-To: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>
	(Ben Walton's message of "Sun, 31 May 2015 16:35:20 +0000")
References: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>
Message-ID: <x6a8wkk5qc.fsf@opencsw.org>

Ben Walton <bwalton at opencsw.org> writes:

> http://helb.github.io/goodbye-sourceforge/
>
> Shall we move our code?

If what's written in the referenced information, why not.
However, it's not such an easy transition mgar and scm wise.
Have we the resources to make such a transition?
-- 
Peter

From dam at opencsw.org  Sun May 31 19:45:15 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 31 May 2015 19:45:15 +0200
Subject: Goodbye, Sourceforge!
In-Reply-To: <x6a8wkk5qc.fsf@opencsw.org>
References: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>
	<x6a8wkk5qc.fsf@opencsw.org>
Message-ID: <5C175F65-2417-4C78-AF02-08D9F3528FFD@opencsw.org>

Hi,

Am 31.05.2015 um 19:38 schrieb Peter FELECAN:
> Ben Walton <bwalton at opencsw.org> writes:
>> http://helb.github.io/goodbye-sourceforge/
>> 
>> Shall we move our code?
> 
> If what's written in the referenced information, why not.
> However, it's not such an easy transition mgar and scm wise.
> Have we the resources to make such a transition?

Well, the initial reason for using SourceForge as SVN repo was from the experience with
Blastwave taking down the repo. I don't think it is reasonable to believe this is a
problem any more. Hosting an SVN repo is not that hard and it would be good to integrate
that into our existing Trac. As we have raw access to the repo the transition for
users should be as easy as an "svn switch". Additionally, I don't think we are in any
hurry, we could also discuss moving to another hoster. Switching the VC (e.g. to Git) is
a completely different issue I would like to keep out of the discussion for now.


Best regards

  -- Dago


From bwalton at opencsw.org  Sun May 31 19:47:35 2015
From: bwalton at opencsw.org (Ben Walton)
Date: Sun, 31 May 2015 17:47:35 +0000
Subject: Goodbye, Sourceforge!
In-Reply-To: <5C175F65-2417-4C78-AF02-08D9F3528FFD@opencsw.org>
References: <CAP30j17x6xHZTt27bdK2edvuRAsLL0M4Nt=jtytwiVDL+6uVcw@mail.gmail.com>
	<x6a8wkk5qc.fsf@opencsw.org>
	<5C175F65-2417-4C78-AF02-08D9F3528FFD@opencsw.org>
Message-ID: <CAP30j15oL1qnhxfjzCWs+NmOSqLLxP4q8oYQk3NHdh8=BvhBxg@mail.gmail.com>

I'm also on with keeping svn as the VCS of record to make the transition
easier. As much as is prefer git,I don't have the energy to drive that
conversion.

A different official source for the repo is all that's needed, IMO.

Thanks
-Ben

On Sun, May 31, 2015, 6:45 PM Dagobert Michelsen <dam at opencsw.org> wrote:

> Hi,
>
> Am 31.05.2015 um 19:38 schrieb Peter FELECAN:
> > Ben Walton <bwalton at opencsw.org> writes:
> >> http://helb.github.io/goodbye-sourceforge/
> >>
> >> Shall we move our code?
> >
> > If what's written in the referenced information, why not.
> > However, it's not such an easy transition mgar and scm wise.
> > Have we the resources to make such a transition?
>
> Well, the initial reason for using SourceForge as SVN repo was from the
> experience with
> Blastwave taking down the repo. I don't think it is reasonable to believe
> this is a
> problem any more. Hosting an SVN repo is not that hard and it would be
> good to integrate
> that into our existing Trac. As we have raw access to the repo the
> transition for
> users should be as easy as an "svn switch". Additionally, I don't think we
> are in any
> hurry, we could also discuss moving to another hoster. Switching the VC
> (e.g. to Git) is
> a completely different issue I would like to keep out of the discussion
> for now.
>
>
> Best regards
>
>   -- Dago
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150531/2f601338/attachment.html>