From rmottola at opencsw.org  Wed Apr  1 17:21:42 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 01 Apr 2015 17:21:42 +0200
Subject: problem uploading a package due to solaris 11
In-Reply-To: <551A490D.8060003@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>	<20150329171000.GA5734@cotton.home.blizinski.pl>	<55185956.1000108@opencsw.org>	<20150329203329.GB15776@quince>
	<551A490D.8060003@opencsw.org>
Message-ID: <551C0D06.9060806@opencsw.org>

Hi,

I ask again... since only Maciej gave a hint.

Riccardo Mottola wrote:
> xcursor is resolved:
>         libXcursor.so.1 => /usr/openwin/lib/libXcursor.so.1
>
> it is resolved to a different place in solaris11s, perhaps checkpkg 
> doesn't know about that?
no one has a hint about this? The warning I am getting.. since the 
library is resolved on both solaris version, but to different positions. 
Could that be the issue? checkpkg?

Or maybe it is something totally unrelated.

Riccardo

From dam at opencsw.org  Thu Apr  2 15:42:41 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 2 Apr 2015 15:42:41 +0200
Subject: problem uploading a package due to solaris 11
In-Reply-To: <551C0D06.9060806@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<20150329171000.GA5734@cotton.home.blizinski.pl>
	<55185956.1000108@opencsw.org> <20150329203329.GB15776@quince>
	<551A490D.8060003@opencsw.org> <551C0D06.9060806@opencsw.org>
Message-ID: <BEC7C32F-EFDF-4B75-A034-AD9F833D64E8@opencsw.org>

Hi Riccardo,

> Am 01.04.2015 um 17:21 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> I ask again... since only Maciej gave a hint.
> 
> Riccardo Mottola wrote:
>> xcursor is resolved:
>>        libXcursor.so.1 => /usr/openwin/lib/libXcursor.so.1
>> 
>> it is resolved to a different place in solaris11s, perhaps checkpkg doesn't know about that?
> no one has a hint about this? The warning I am getting.. since the library is resolved on both solaris version, but to different positions. Could that be the issue? checkpkg?
> 
> Or maybe it is something totally unrelated.

Maybe the Solaris 11 machine needs to be reinventorized regarding to installed files,
I vaguely remember I did that quite some time ago, at the moment I am running the steps
from
  http://wiki.opencsw.org/checkpkg

pkgdb system-metadata-to-disk
pkgdb import-system-metadata SunOS5.11 sparc


It may take some time to finish.


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/20150402/1e33268e/attachment.p7s>

From rmottola at opencsw.org  Fri Apr  3 19:22:27 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 03 Apr 2015 19:22:27 +0200
Subject: problem uploading a package due to solaris 11
In-Reply-To: <BEC7C32F-EFDF-4B75-A034-AD9F833D64E8@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>	<20150329171000.GA5734@cotton.home.blizinski.pl>	<55185956.1000108@opencsw.org>
	<20150329203329.GB15776@quince>	<551A490D.8060003@opencsw.org>
	<551C0D06.9060806@opencsw.org>
	<BEC7C32F-EFDF-4B75-A034-AD9F833D64E8@opencsw.org>
Message-ID: <551ECC53.20003@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> pkgdb system-metadata-to-disk
> pkgdb import-system-metadata SunOS5.11 sparc
>
>
> It may take some time to finish.


thank you Dago, let me know when to retry.

Riccardo

PS: any new for the solaris 9 boxen?

From dam at opencsw.org  Fri Apr  3 23:46:25 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 3 Apr 2015 23:46:25 +0200
Subject: problem uploading a package due to solaris 11
In-Reply-To: <551ECC53.20003@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<20150329171000.GA5734@cotton.home.blizinski.pl>
	<55185956.1000108@opencsw.org> <20150329203329.GB15776@quince>
	<551A490D.8060003@opencsw.org> <551C0D06.9060806@opencsw.org>
	<BEC7C32F-EFDF-4B75-A034-AD9F833D64E8@opencsw.org>
	<551ECC53.20003@opencsw.org>
Message-ID: <E36B1AFF-8C87-4AFF-9186-8E186F25FFB3@opencsw.org>

Hi Riccardo,

> Am 03.04.2015 um 19:22 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Dagobert Michelsen wrote:
>> pkgdb system-metadata-to-disk
>> pkgdb import-system-metadata SunOS5.11 sparc
>> 
>> 
>> It may take some time to finish.
> 
> thank you Dago, let me know when to retry.

This took quite some time but is finished now. Please test on unstable11s, if that works
I?ll also re-inventorize unstable11x.

> PS: any new for the solaris 9 boxen?

After the this package database sync is done I will reboot the machine, if I had maintenance
on the machine I would now open a case. It looks like there is some kind of weird locking
which makes a process hang during fork.


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/20150403/faecf18f/attachment.p7s>

From rmottola at opencsw.org  Sat Apr  4 12:56:41 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sat, 04 Apr 2015 12:56:41 +0200
Subject: problem uploading a package due to solaris 11
In-Reply-To: <E36B1AFF-8C87-4AFF-9186-8E186F25FFB3@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>	<20150329171000.GA5734@cotton.home.blizinski.pl>	<55185956.1000108@opencsw.org>
	<20150329203329.GB15776@quince>	<551A490D.8060003@opencsw.org>
	<551C0D06.9060806@opencsw.org>	<BEC7C32F-EFDF-4B75-A034-AD9F833D64E8@opencsw.org>	<551ECC53.20003@opencsw.org>
	<E36B1AFF-8C87-4AFF-9186-8E186F25FFB3@opencsw.org>
Message-ID: <551FC369.3060206@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> This took quite some time but is finished now. Please test on 
> unstable11s, if that works I?ll also re-inventorize unstable11x. 

I retried uploading and went fine! No problem with the x86 package. 
Perhaps the inventory was alrady fine?
gnustep back packages uploaded :)


>> PS: any new for the solaris 9 boxen?
> After the this package database sync is done I will reboot the machine, if I had maintenance
> on the machine I would now open a case. It looks like there is some kind of weird locking
> which makes a process hang during fork.
>
Ok.

Riccardo

From dam at opencsw.org  Sat Apr  4 23:39:08 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 4 Apr 2015 23:39:08 +0200
Subject: problem uploading a package due to solaris 11
In-Reply-To: <551FC369.3060206@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<20150329171000.GA5734@cotton.home.blizinski.pl>
	<55185956.1000108@opencsw.org> <20150329203329.GB15776@quince>
	<551A490D.8060003@opencsw.org> <551C0D06.9060806@opencsw.org>
	<BEC7C32F-EFDF-4B75-A034-AD9F833D64E8@opencsw.org>
	<551ECC53.20003@opencsw.org>
	<E36B1AFF-8C87-4AFF-9186-8E186F25FFB3@opencsw.org>
	<551FC369.3060206@opencsw.org>
Message-ID: <90600595-CFE6-41A3-A272-A625B8F297FE@opencsw.org>

Hi Riccardo,

> Am 04.04.2015 um 12:56 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Dagobert Michelsen wrote:
>> This took quite some time but is finished now. Please test on unstable11s, if that works I?ll also re-inventorize unstable11x. 
> 
> I retried uploading and went fine! No problem with the x86 package. Perhaps the inventory was alrady fine?
> gnustep back packages uploaded :)

I am glad to hear that :-) Please continue to be inquisitive and persistent,
sometimes the requests really get lost in the daily mail and putting
unfinished things back on the menu is really important to get things done
(as you saw in this case!)


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/20150404/cef9e098/attachment.p7s>

From dam at opencsw.org  Sun Apr  5 19:41:33 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 5 Apr 2015 19:41:33 +0200
Subject: hang when building packages on unstable9s
In-Reply-To: <20150329202152.GA15776@quince>
References: <20150329170312.GA5394@cotton.home.blizinski.pl>
	<11656a12396ff75b2079959eac57ab17@fuchur.local>
	<20150329182320.GA1688@quince>
	<49E2E1F8-3EEE-4CB1-82CA-251ACC0A02AE@opencsw.org>
	<20150329202152.GA15776@quince>
Message-ID: <D6804739-434F-4408-8C9D-63575D24C6CC@opencsw.org>

Hi folks,

Am 29.03.2015 um 22:21 schrieb Maciej Blizi?ski <maciej at opencsw.org>:
> On Sun, Mar 29, 2015 at 10:19:58PM +0200, Dagobert Michelsen wrote:
>> Am 29.03.2015 um 20:23 schrieb Maciej Blizi?ski via buildfarm <buildfarm at lists.opencsw.org>:
>>> Hangs in unstable9x too.
>> 
>> This is very strange as unstable9s uses a loopback filesystem and unstable10s works
>> fine as far as I can tell. The testing I did worked fine, do you have a specific recipe
>> I can run to reproduce the issue? I would like to understand the problem before booting
>> the whole farm.
> 
> I've submitted my changes, try building pkg/arc/trunk. This triggers the
> problem for me.

I just rebooted the global zone where NFS, login, unstable10s and others are hosted
and the problem is still present. One more good reason to not boot servers if there
is a problem :-)

The situation looks like this at the moment: On unstable9s some specific
commands are stuck during fork while the machine continues to run and
login and some commands are still possible. Here is the process tree and
stack for one of the hanging commands, maybe someone has a striking idea.

unstable9s# ptree 18150
16482 /usr/lib/ssh/sshd
  16816 /usr/lib/ssh/sshd
    16823 /usr/lib/ssh/sshd
      16826 -zsh
        17145 /bin/bash /opt/csw/bin/mgar package
          17182 gmake -I /home/dam/mgar/pkg/.buildsys/v2 package
            18150 gmake GAR_PLATFORM=solaris9-sparc MODULATION=isa-sparcv8 ISA=
              18519 /bin/sh -c ( if ggrep -q 'diff --git' /home/dam/mgar/pkg/ar
                18520 /bin/sh -c ( if ggrep -q 'diff --git' /home/dam/mgar/pkg/
                  18525 git am --ignore-space-change --ignore-whitespace /home/
                    18527 git am --ignore-space-change --ignore-whitespace /hom

unstable9s# pstack 18527
18527:  git am --ignore-space-change --ignore-whitespace /home/dam/mgar/pkg/ar
 ff3dcba4 lwp_park (0, 0, 0)
 ff3d3d3c s9_lwp_park (0, 0, 0, 0, 0, 0) + 6c
 ff3dcb08 s9_handler (0, 0, 0, 0, 0, 0) + 90
 feca11bc mutex_lock_queue (fecb8c04, 0, feda0428, 0, 0, 0) + 104
 feca18cc mutex_lock_internal (0, 0, fecb0000, 0, 0, 0) + 610
 fed78440 atfork_append (0, 0, fef1d060, feda0424, feda0428, 0) + 4
 fed785ac pthread_atfork (0, 0, fef1d060, fffbf8dc, 40400, 406e0) + 24
 fef1d0dc ???????? (fef1d060, fef63a18, 0, 6000, fef63a18, 6000)
 fed78788 run_postfork_child (feda0410, feda0428, 23854, fec9cfa8, 5, 0) + 24
 fec9cfa8 fork1    (1, 1afc8, 0, 0, 0, 0) + f4
 fec9d05c fork     (0, 4, ffbff4a8, 223544, 1b5d80, 0) + 28
 00151534 start_command (ffbff58c, 0, 9, 0, 0, 0) + 220
 00151b80 run_command (ffbff58c, 0, 20, 0, 8, 8) + 4
 00151cac run_command_v_opt (ffbff748, 28, 1e6c00, 223544, 1b5d80, 0) + 14
 000212a8 ???????? (ffbff748, ffffffff, 1fc000, 223544, 1aadd0, 0)
 00021308 ???????? (ffbff724, ffbff728, ffbffb80, 1dadc8, 0, 1b5000)
 00021448 main     (ffbff748, ffbff724, 1fc818, 1b6fe8, ffbff728, ffbff890) + f8
 0001f840 _start   (0, ffbff744, 1, ff3dca78, ff3ee850, ff3ee000) + 108


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/20150405/6030d237/attachment.p7s>

From dam at opencsw.org  Sun Apr  5 20:02:29 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 5 Apr 2015 20:02:29 +0200
Subject: hang when building packages on unstable9s
In-Reply-To: <D6804739-434F-4408-8C9D-63575D24C6CC@opencsw.org>
References: <20150329170312.GA5394@cotton.home.blizinski.pl>
	<11656a12396ff75b2079959eac57ab17@fuchur.local>
	<20150329182320.GA1688@quince>
	<49E2E1F8-3EEE-4CB1-82CA-251ACC0A02AE@opencsw.org>
	<20150329202152.GA15776@quince>
	<D6804739-434F-4408-8C9D-63575D24C6CC@opencsw.org>
Message-ID: <5DEC295B-C394-4938-BCDF-66DA16B146C5@opencsw.org>

Hi folks,

Am 05.04.2015 um 19:41 schrieb Dagobert Michelsen <dam at opencsw.org>:
> Am 29.03.2015 um 22:21 schrieb Maciej Blizi?ski <maciej at opencsw.org>:
>> On Sun, Mar 29, 2015 at 10:19:58PM +0200, Dagobert Michelsen wrote:
>>> Am 29.03.2015 um 20:23 schrieb Maciej Blizi?ski via buildfarm <buildfarm at lists.opencsw.org>:
>>>> Hangs in unstable9x too.
>>> 
>>> This is very strange as unstable9s uses a loopback filesystem and unstable10s works
>>> fine as far as I can tell. The testing I did worked fine, do you have a specific recipe
>>> I can run to reproduce the issue? I would like to understand the problem before booting
>>> the whole farm.
>> 
>> I've submitted my changes, try building pkg/arc/trunk. This triggers the
>> problem for me.
> 
> I just rebooted the global zone where NFS, login, unstable10s and others are hosted
> and the problem is still present. One more good reason to not boot servers if there
> is a problem :-)
> 
> The situation looks like this at the moment: On unstable9s some specific
> commands are stuck during fork while the machine continues to run and
> login and some commands are still possible. Here is the process tree and
> stack for one of the hanging commands, maybe someone has a striking idea.
> 
> unstable9s# ptree 18150
> 16482 /usr/lib/ssh/sshd
>  16816 /usr/lib/ssh/sshd
>    16823 /usr/lib/ssh/sshd
>      16826 -zsh
>        17145 /bin/bash /opt/csw/bin/mgar package
>          17182 gmake -I /home/dam/mgar/pkg/.buildsys/v2 package
>            18150 gmake GAR_PLATFORM=solaris9-sparc MODULATION=isa-sparcv8 ISA=
>              18519 /bin/sh -c ( if ggrep -q 'diff --git' /home/dam/mgar/pkg/ar
>                18520 /bin/sh -c ( if ggrep -q 'diff --git' /home/dam/mgar/pkg/
>                  18525 git am --ignore-space-change --ignore-whitespace /home/
>                    18527 git am --ignore-space-change --ignore-whitespace /hom
> 
> unstable9s# pstack 18527
> 18527:  git am --ignore-space-change --ignore-whitespace /home/dam/mgar/pkg/ar
> ff3dcba4 lwp_park (0, 0, 0)
> ff3d3d3c s9_lwp_park (0, 0, 0, 0, 0, 0) + 6c
> ff3dcb08 s9_handler (0, 0, 0, 0, 0, 0) + 90
> feca11bc mutex_lock_queue (fecb8c04, 0, feda0428, 0, 0, 0) + 104
> feca18cc mutex_lock_internal (0, 0, fecb0000, 0, 0, 0) + 610
> fed78440 atfork_append (0, 0, fef1d060, feda0424, feda0428, 0) + 4
> fed785ac pthread_atfork (0, 0, fef1d060, fffbf8dc, 40400, 406e0) + 24
> fef1d0dc ???????? (fef1d060, fef63a18, 0, 6000, fef63a18, 6000)
> fed78788 run_postfork_child (feda0410, feda0428, 23854, fec9cfa8, 5, 0) + 24
> fec9cfa8 fork1    (1, 1afc8, 0, 0, 0, 0) + f4
> fec9d05c fork     (0, 4, ffbff4a8, 223544, 1b5d80, 0) + 28
> 00151534 start_command (ffbff58c, 0, 9, 0, 0, 0) + 220
> 00151b80 run_command (ffbff58c, 0, 20, 0, 8, 8) + 4
> 00151cac run_command_v_opt (ffbff748, 28, 1e6c00, 223544, 1b5d80, 0) + 14
> 000212a8 ???????? (ffbff748, ffffffff, 1fc000, 223544, 1aadd0, 0)
> 00021308 ???????? (ffbff724, ffbff728, ffbffb80, 1dadc8, 0, 1b5000)
> 00021448 main     (ffbff748, ffbff724, 1fc818, 1b6fe8, ffbff728, ffbff890) + f8
> 0001f840 _start   (0, ffbff744, 1, ff3dca78, ff3ee850, ff3ee000) + 108

Just FYI: the same issue happens for buildbot slave and probably other applications:

buildbot at unstable9s :~/slave > pstack 20922
20922:  /opt/csw/bin/python2.7 /opt/csw/bin/buildslave start .
 ff3dcba4 lwp_park (0, 0, 0)
 ff3d3d3c s9_lwp_park (0, 0, 0, 0, 0, 0) + 6c
 ff3dcb08 s9_handler (0, 0, 0, 0, 0, 0) + 90
 ff1e11bc mutex_lock_queue (ff1f8c04, 0, ff1c0428, 0, 0, 0) + 104
 ff1e18cc mutex_lock_internal (0, 0, ff1b0000, 0, 0, 0) + 610
 ff198440 atfork_append (0, 0, fe7bd060, ff1c0424, ff1c0428, 0) + 4
 ff1985ac pthread_atfork (0, 0, fe7bd060, fffbf8dc, 40400, 406e0) + 24
 fe7bd0dc ???????? (fe7bd060, fe803a18, 0, 6000, fe803a18, 6000)
 ff198788 run_postfork_child (ff1c0410, ff1c0428, 23854, ff1dcfa8, b59ec740, fede1060) + 24
 ff1dcfa8 fork1    (1, 1afc8, ff0d7db0, feeca000, b59ec740, 0) + f4
 ff1dd05c fork     (fede81c0, fede1060, fee58c00, ff0e11a8, ff0c1614, 1) + 28
 ff05bd60 posix_fork (0, 0, a8c4eefc, 11aa90, ff0d9c78, 1) + 18
 ff0167bc PyEval_EvalFrameEx (fe4868a0, 0, 0, fedd5925, 20ab0, fe4869e8) + 556c
 ff017f5c PyEval_EvalFrameEx (fe5b4bf0, 0, fe4868a4, fedee4b6, 20ab0, 20ab0) + 6d0c
 ff017f5c PyEval_EvalFrameEx (feddc030, 0, 0, fedbc785, 20ab0, 20ab0) + 6d0c
 ff018c28 PyEval_EvalCodeEx (fee4dcc8, fee589c0, feddc030, 0, 0, 0) + 91c
 ff018ddc PyEval_EvalCode (fee4dcc8, fee589c0, fee589c0, ff0e1080, fed39488, ffffffff) + 28
 ff03d540 PyRun_FileExFlags (ff1c01f4, ffbffbd3, 97fa8, fee589c0, fee589c0, fee4dcc8) + 7c
 ff03e120 PyRun_SimpleFileExFlags (ffbffbe6, ffbffbd3, 1, ffbffa24, ff1c01f4, fee56f10) + e4
 ff053848 Py_Main  (1, ffbffa8c, ff0e3af8, 0, ff1c01f4, 0) + d3c
 000105c0 _start   (0, ffbffa8c, 1, ff3dca78, ff3ee850, ff3ee000) + 5c


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/20150405/9f81bbb3/attachment-0001.p7s>

From dam at opencsw.org  Sun Apr  5 20:04:59 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 5 Apr 2015 20:04:59 +0200
Subject: Main server on farm rebooted
Message-ID: <7BD60DD1-1F50-4281-9654-BA2504332A0F@opencsw.org>

Hi folks,

the main server on the farm has been rebooted, as always: if you encounter
something suspicuous just let me know!


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/20150405/3ddb1978/attachment.p7s>

From rmottola at opencsw.org  Mon Apr  6 09:55:57 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 06 Apr 2015 09:55:57 +0200
Subject: Fwd: OpenCSW catalog update report
In-Reply-To: <3lKz7m4Zmxzjx@mail.opencsw.org>
References: <3lKz7m4Zmxzjx@mail.opencsw.org>
Message-ID: <55223C0D.5040903@opencsw.org>

Hi,

I just got the attached message. Is this due to the server farm reboot? 
The new libffi packages could not be upgraded because they did conflict 
with gcc and I haven't gotten around yet to build a better gcc due to 
many issues.

Is this a bogus message or do we now have incompatible packages?

Riccardo
-------------- next part --------------
An embedded message was scrubbed...
From: Catalog update notifier <noreply at opencsw.org>
Subject: OpenCSW catalog update report
Date: Mon,  6 Apr 2015 06:16:04 +0200 (CEST)
Size: 2505
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150406/06ea035d/attachment.eml>

From dam at opencsw.org  Mon Apr  6 20:52:42 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 6 Apr 2015 20:52:42 +0200
Subject: strange lockups on sol. 9 machines
In-Reply-To: <551421E5.8090002@opencsw.org>
References: <551421E5.8090002@opencsw.org>
Message-ID: <D95CDE55-2C73-4799-8929-155EFAE6B141@opencsw.org>

Hi Riccardo,

Am 26.03.2015 um 16:12 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> did you have perhaps time investigating why I got those lockups on the solaris 9 build hosts?

Yes. As I wrote earlier it is some kind of locking problem. The stacktrace looks
like this:

unstable9s% pstack 15521
15521:  git am --ignore-space-change --ignore-whitespace /home/dam/mgar/pkg/ar
 ff3dcba4 lwp_park (0, 0, 0)
 ff3d3d3c s9_lwp_park (0, 0, 0, 0, 0, 0) + 6c
 ff3dcb08 s9_handler (0, 0, 0, 0, 0, 0) + 90
 feca11bc mutex_lock_queue (fecb8c04, 0, feda2408, 0, 0, 0) + 104
 feca18cc mutex_lock_internal (0, 0, fecb0000, 0, 0, 0) + 610
 fed78a28 atfork_append (0, 0, fef1d060, feda2404, feda2408, 0) + 4
 fed78b94 pthread_atfork (0, 0, fef1d060, fffbf8dc, 40400, 406e0) + 24
 fef1d0dc ???????? (fef1d060, fef63a18, 0, 6000, fef63a18, 6000)
 fed78d70 run_postfork_child (feda23f0, feda2408, 2526c, fec9cfa8, 5, 0) + 24
 fec9cfa8 fork1    (1, 1afc8, 0, 0, 0, 0) + f4
 fec9d05c fork     (0, 4, ffbff3b8, 223544, 1b5d80, 0) + 28
 00151534 start_command (ffbff49c, 0, 9, 0, 0, 0) + 220
 00151b80 run_command (ffbff49c, 0, 20, 0, 8, 8) + 4
 00151cac run_command_v_opt (ffbff658, 28, 1e6c00, 223544, 1b5d80, 0) + 14
 000212a8 ???????? (ffbff658, ffffffff, 1fc000, 223544, 1aadd0, 0)
 00021308 ???????? (ffbff634, ffbff638, ffbffa90, 1dadc8, 0, 1b5000)
 00021448 main     (ffbff658, ffbff634, 1fc818, 1b6fe8, ffbff638, ffbff7a0) + f8
 0001f840 _start   (0, ffbff654, 1, ff3dca78, ff3ee850, ff3ee000) + 108

I just updated unstable9s to the latest Solaris 9 patchcluster with no change in
behaviour. If anyone has suggestions I am all ears.


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/20150406/f2925113/attachment.p7s>

From rmottola at opencsw.org  Tue Apr  7 16:13:43 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 07 Apr 2015 16:13:43 +0200
Subject: strange lockups on sol. 9 machines
In-Reply-To: <D95CDE55-2C73-4799-8929-155EFAE6B141@opencsw.org>
References: <551421E5.8090002@opencsw.org>
	<D95CDE55-2C73-4799-8929-155EFAE6B141@opencsw.org>
Message-ID: <5523E617.7030409@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Hi Riccardo,
>
> Am 26.03.2015 um 16:12 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>> did you have perhaps time investigating why I got those lockups on the solaris 9 build hosts?
> Yes. As I wrote earlier it is some kind of locking problem. The stacktrace looks
> like this:
>
> unstable9s% pstack 15521
> 15521:  git am --ignore-space-change --ignore-whitespace /home/dam/mgar/pkg/ar
>   ff3dcba4 lwp_park (0, 0, 0)
>   ff3d3d3c s9_lwp_park (0, 0, 0, 0, 0, 0) + 6c
>   ff3dcb08 s9_handler (0, 0, 0, 0, 0, 0) + 90
>   feca11bc mutex_lock_queue (fecb8c04, 0, feda2408, 0, 0, 0) + 104
>   feca18cc mutex_lock_internal (0, 0, fecb0000, 0, 0, 0) + 610
>   fed78a28 atfork_append (0, 0, fef1d060, feda2404, feda2408, 0) + 4
>   fed78b94 pthread_atfork (0, 0, fef1d060, fffbf8dc, 40400, 406e0) + 24
>   fef1d0dc ???????? (fef1d060, fef63a18, 0, 6000, fef63a18, 6000)
>   fed78d70 run_postfork_child (feda23f0, feda2408, 2526c, fec9cfa8, 5, 0) + 24
>   fec9cfa8 fork1    (1, 1afc8, 0, 0, 0, 0) + f4
>   fec9d05c fork     (0, 4, ffbff3b8, 223544, 1b5d80, 0) + 28
>   00151534 start_command (ffbff49c, 0, 9, 0, 0, 0) + 220
>   00151b80 run_command (ffbff49c, 0, 20, 0, 8, 8) + 4
>   00151cac run_command_v_opt (ffbff658, 28, 1e6c00, 223544, 1b5d80, 0) + 14
>   000212a8 ???????? (ffbff658, ffffffff, 1fc000, 223544, 1aadd0, 0)
>   00021308 ???????? (ffbff634, ffbff638, ffbffa90, 1dadc8, 0, 1b5000)
>   00021448 main     (ffbff658, ffbff634, 1fc818, 1b6fe8, ffbff638, ffbff7a0) + f8
>   0001f840 _start   (0, ffbff654, 1, ff3dca78, ff3ee850, ff3ee000) + 108
>
> I just updated unstable9s to the latest Solaris 9 patchcluster with no change in
> behaviour. If anyone has suggestions I am all ears.

Since it happens on both SPARC ad x86... I wonder when and why it 
started happening? It used to work, since I built several packages. Did 
we update mgar? or one of the packages it depends upon?

If the trace is GIT, I suppose it locks when mgar invokes GIT. Thus the 
problem would be git or one of its dependencies, did we update them?

Riccardo


From rmottola at opencsw.org  Tue Apr  7 20:41:18 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 07 Apr 2015 20:41:18 +0200
Subject: hang when building packages on unstable9s
In-Reply-To: <D6804739-434F-4408-8C9D-63575D24C6CC@opencsw.org>
References: <20150329170312.GA5394@cotton.home.blizinski.pl>
	<11656a12396ff75b2079959eac57ab17@fuchur.local>
	<20150329182320.GA1688@quince>
	<49E2E1F8-3EEE-4CB1-82CA-251ACC0A02AE@opencsw.org>
	<20150329202152.GA15776@quince>
	<D6804739-434F-4408-8C9D-63575D24C6CC@opencsw.org>
Message-ID: <552424CE.3050904@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> The situation looks like this at the moment: On unstable9s some specific
> commands are stuck during fork while the machine continues to run and
> login and some commands are still possible. Here is the process tree and
> stack for one of the hanging commands, maybe someone has a striking idea.

no striking idea.. but apart from what I already asked, git git-related 
updates, here some ideas.

1) Unstable9x? I got problems there too
2) can you reproduce this git problem in a minimal repo and try this on 
the NFS and then a physical filesystem?

Just to rule out and confirm some hypotheses that are flying around.


Riccardo

From rmottola at opencsw.org  Wed Apr  8 15:18:27 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 08 Apr 2015 15:18:27 +0200
Subject: gcc 4.9 on solaris 9 sparc (alignment)
In-Reply-To: <5509D923.10805@opencsw.org>
References: <5509D923.10805@opencsw.org>
Message-ID: <55252AA3.2040501@opencsw.org>

Hi,

I attempted a build of gcc 4.8.4 on Solaris 9 SPARC and I get the same 
errors a below, that version was officially supported and worked and is 
a good package candidate. I wonder thus why we are having this problem.

<...>
ld: fatal: relocation error: R_SPARC_32: file .libs/compatibility.o: 
symbol __gxx_personality_v0: offset 0xe0387 is non-aligned
<...>
and many more

thus I start to fear it is some problem with our linker/AS chain ... 
peple reported this apparently when boostrapping with older version of 
gcc, but our is gcc4 already.

Riccardo

Riccardo Mottola wrote:
> Hi,
>
> while trying to build gcc 4.9 on solaris9 sparc I get the alignment 
> errors pasted below.
>
> I did some research, people got this on older versions on solaris with 
> old linkers, but the posts are very old. I am bootstrapping with gcc 
> 4.6 instead.
>
> Do you have clues? ideas?
>
> It is officially reported to still build:
> https://gcc.gnu.org/gcc-4.9/buildstat.html
>
> Riccardo
>
>
> libtool: link: 
> /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/xgcc 
> -shared-libgcc 
> -B/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc 
> -nostdinc++ 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src/.libs 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/libsupc++/.libs 
> -B/opt/csw/sparc-sun-solaris2.9/bin/ 
> -B/opt/csw/sparc-sun-solaris2.9/lib/ -isystem 
> /opt/csw/sparc-sun-solaris2.9/include -isystem 
> /opt/csw/sparc-sun-solaris2.9/sys-include    -shared -nostdlib 
> /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crti.o 
> /usr/ccs/lib/values-Xa.o 
> /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crtbegin.o 
> .libs/compatibility.o .libs/compatibility-debug_list.o 
> .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o 
> .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o 
> .libs/compatibility-chrono.o .libs/compatibility-condvar.o  -Wl,-z 
> -Wl,allextract ../libsupc++/.libs/libsupc++convenience.a 
> ../src/c++98/.libs/libc++98convenience.a 
> ../src/c++11/.libs/libc++11convenience.a -Wl,-z -Wl,defaultextract 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/libsupc++/.libs 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src/.libs 
> -lm -lrt 
> -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc 
> -L/opt/csw/sparc-sun-solaris2.9/bin 
> -L/opt/csw/sparc-sun-solaris2.9/lib -L/usr/ccs/lib -lgcc_s -lc -lgcc_s 
> -lc 
> /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crtend.o 
> /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crtn.o 
> -Wl,-M -Wl,libstdc++-symbols.ver-sun   -Wl,-h -Wl,libstdc++.so.6 -o 
> .libs/libstdc++.so.6.0.20
> ld: fatal: relocation error: R_SPARC_32: file .libs/compatibility.o: 
> symbol __gxx_personality_v0: offset 0xf94df is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> .libs/compatibility-chrono.o: symbol __gxx_personality_v0: offset 
> 0xf975f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(atexit_thread.o): symbol 
> __gxx_personality_v0: offset 0xf981b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(eh_alloc.o): symbol 
> __gxx_personality_v0: offset 0xf9d83 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o): symbol 
> __gxx_personality_v0: offset 0xfa0af is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(eh_personality.o): symbol 
> __gxx_personality_v0: offset 0xfa203 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(eh_ptr.o): symbol 
> __gxx_personality_v0: offset 0xfa30f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(eh_terminate.o): symbol 
> __gxx_personality_v0: offset 0xfa44b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(eh_tm.o): symbol 
> __gxx_personality_v0: offset 0xfa57f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(guard.o): symbol 
> __gxx_personality_v0: offset 0xfa91b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(new_opnt.o): symbol 
> __gxx_personality_v0: offset 0xfab73 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(new_opv.o): symbol 
> __gxx_personality_v0: offset 0xfabab is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(vec.o): symbol 
> __gxx_personality_v0: offset 0xfaf57 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../libsupc++/.libs/libsupc++convenience.a(vterminate.o): symbol 
> __gxx_personality_v0: offset 0xfb137 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(bitmap_allocator.o): symbol 
> __gxx_personality_v0: offset 0xfb283 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(pool_allocator.o): symbol 
> __gxx_personality_v0: offset 0xfbab7 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(mt_allocator.o): symbol 
> __gxx_personality_v0: offset 0xfbec3 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(codecvt.o): symbol 
> __gxx_personality_v0: offset 0xfc2cf is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(complex_io.o): symbol 
> __gxx_personality_v0: offset 0xfc4bb is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ctype.o): symbol 
> __gxx_personality_v0: offset 0xfc607 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ios.o): symbol 
> __gxx_personality_v0: offset 0xfc857 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ios_failure.o): symbol 
> __gxx_personality_v0: offset 0xfc97f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ios_init.o): symbol 
> __gxx_personality_v0: offset 0xfca2b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(locale.o): symbol 
> __gxx_personality_v0: offset 0xfce53 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(locale_init.o): symbol 
> __gxx_personality_v0: offset 0xfd147 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(localename.o): symbol 
> __gxx_personality_v0: offset 0xfd2c7 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(stdexcept.o): symbol 
> __gxx_personality_v0: offset 0xfd837 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(strstream.o): symbol 
> __gxx_personality_v0: offset 0xfdbd7 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(istream.o): symbol 
> __gxx_personality_v0: offset 0xfe26f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(valarray.o): symbol 
> __gxx_personality_v0: offset 0xfe4df is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ctype_members.o): symbol 
> __gxx_personality_v0: offset 0xfe7d3 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(monetary_members.o): symbol 
> __gxx_personality_v0: offset 0xfea03 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(numeric_members.o): symbol 
> __gxx_personality_v0: offset 0xfeb5f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(time_members.o): symbol 
> __gxx_personality_v0: offset 0xfec0f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(basic_file.o): symbol 
> __gxx_personality_v0: offset 0xfed27 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(c++locale.o): symbol 
> __gxx_personality_v0: offset 0xfee8f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ext-inst.o): symbol 
> __gxx_personality_v0: offset 0xff24b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ios-inst.o): symbol 
> __gxx_personality_v0: offset 0xff7b7 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(iostream-inst.o): symbol 
> __gxx_personality_v0: offset 0xffc23 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(istream-inst.o): symbol 
> __gxx_personality_v0: offset 0xffe5b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(locale-inst.o): symbol 
> __gxx_personality_v0: offset 0x101063 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(misc-inst.o): symbol 
> __gxx_personality_v0: offset 0x102d87 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(ostream-inst.o): symbol 
> __gxx_personality_v0: offset 0x102f73 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(sstream-inst.o): symbol 
> __gxx_personality_v0: offset 0x103b4f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(streambuf-inst.o): symbol 
> __gxx_personality_v0: offset 0x104843 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++98/.libs/libc++98convenience.a(wlocale-inst.o): symbol 
> __gxx_personality_v0: offset 0x1053d3 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(chrono.o): symbol 
> __gxx_personality_v0: offset 0x106ef7 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(debug.o): symbol 
> __gxx_personality_v0: offset 0x10707b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(functexcept.o): symbol 
> __gxx_personality_v0: offset 0x10749f is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(future.o): symbol 
> __gxx_personality_v0: offset 0x107817 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(regex.o): symbol 
> __gxx_personality_v0: offset 0x107ae7 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(fstream-inst.o): symbol 
> __gxx_personality_v0: offset 0x107f9b is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(string-inst.o): symbol 
> __gxx_personality_v0: offset 0x108e63 is non-aligned
> ld: fatal: relocation error: R_SPARC_32: file 
> ../src/c++11/.libs/libc++11convenience.a(wstring-inst.o): symbol 
> __gxx_personality_v0: offset 0x10a013 is non-aligned
> collect2: error: ld returned 1 exit status
> gmake[6]: *** [libstdc++.la] Error 1
>


From maciej at opencsw.org  Wed Apr  8 16:13:43 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 8 Apr 2015 15:13:43 +0100
Subject: gcc 4.9 on solaris 9 sparc (alignment)
In-Reply-To: <55252AA3.2040501@opencsw.org>
References: <5509D923.10805@opencsw.org> <55252AA3.2040501@opencsw.org>
Message-ID: <CALtRa-4hhHPHSm-Y3s2QYOUBk+_5O=qpVSQbct26CgV5YsGsHA@mail.gmail.com>

2015-04-08 14:18 GMT+01:00 Riccardo Mottola <rmottola at opencsw.org>:
>
> ld: fatal: relocation error: R_SPARC_32: file .libs/compatibility.o: symbol __gxx_personality_v0: offset 0xe0387 is non-aligned

It's the same error I was getting when attempting to build on Solaris 9.

When I talked to the GCC developers, they wanted me to build it in the
most vanilla way possible, without GAR or anything like that. They
even wanted me to build internal versions of libraries GCC depends on.
You could see whether if a vanilla build works for you.

Maciej

From rmottola at opencsw.org  Thu Apr  9 10:07:04 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 09 Apr 2015 10:07:04 +0200
Subject: latest available version of binutils for 9
Message-ID: <55263328.1000605@opencsw.org>

Hi,

how can I know which is the latest version of binutils for solaris 9?

This is what is installed on unstable9s:
rmottola at unstable9s :~/opencsw/gcc4 > pkginfo -l CSWbinutils
    PKGINST:  CSWbinutils
       NAME:  binutils - GNU binary utilities: gas, gld, gprof, and others
   CATEGORY:  application
       ARCH:  sparc
    VERSION:  2.22,REV=2012.06.14

If I go here:
http://www.opencsw.org/packages/CSWbinutils/

I see latest, but it says only about solaris 10? it is not clear which 
versions are built for the various solaris versions.

Riccardo

PS: the GCC problem could be related to binutils and mixing the tools.

From dam at opencsw.org  Thu Apr  9 11:28:15 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 9 Apr 2015 11:28:15 +0200
Subject: latest available version of binutils for 9
In-Reply-To: <55263328.1000605@opencsw.org>
References: <55263328.1000605@opencsw.org>
Message-ID: <AA71B849-11E9-45C7-A89F-682DEF979FB0@opencsw.org>

Hi Riccardo,

> Am 09.04.2015 um 10:07 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> how can I know which is the latest version of binutils for solaris 9?
> 
> This is what is installed on unstable9s:
> rmottola at unstable9s :~/opencsw/gcc4 > pkginfo -l CSWbinutils
>   PKGINST:  CSWbinutils
>      NAME:  binutils - GNU binary utilities: gas, gld, gprof, and others
>  CATEGORY:  application
>      ARCH:  sparc
>   VERSION:  2.22,REV=2012.06.14
> 
> If I go here:
> http://www.opencsw.org/packages/CSWbinutils/
> 
> I see latest, but it says only about solaris 10? it is not clear which versions are built for the various solaris versions.

You can get the specific revision and path with pkgparam:

> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/collectd/trunk > pkgparam CSWbinutils OPENCSW_REPOSITORY             
> https://svn.code.sf.net/p/gar/code/csw/mgar/pkg/binutils/trunk at 24045

You can then navigate back either with OpenGrok or Trac and see the recipe:
  https://buildfarm.opencsw.org/source/history/opencsw/csw/mgar/pkg/binutils/trunk/Makefile
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/binutils/trunk/Makefile?r=16881


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/20150409/3dee76b8/attachment-0001.p7s>

From rmottola at opencsw.org  Thu Apr  9 11:36:13 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 09 Apr 2015 11:36:13 +0200
Subject: latest available version of binutils for 9
In-Reply-To: <AA71B849-11E9-45C7-A89F-682DEF979FB0@opencsw.org>
References: <55263328.1000605@opencsw.org>
	<AA71B849-11E9-45C7-A89F-682DEF979FB0@opencsw.org>
Message-ID: <5526480D.1000507@opencsw.org>

Hi Dago,

Dagobert Michelsen wrote:
> You can then navigate back either with OpenGrok or Trac and see the recipe:
>    https://buildfarm.opencsw.org/source/history/opencsw/csw/mgar/pkg/binutils/trunk/Makefile
>    https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/binutils/trunk/Makefile?r=16881

right, I can also check the current Makefile, but how can I know which 
was the latest version built and available for solaris 9?

Riccardo

From dam at opencsw.org  Thu Apr  9 11:46:11 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 9 Apr 2015 11:46:11 +0200
Subject: latest available version of binutils for 9
In-Reply-To: <5526480D.1000507@opencsw.org>
References: <55263328.1000605@opencsw.org>
	<AA71B849-11E9-45C7-A89F-682DEF979FB0@opencsw.org>
	<5526480D.1000507@opencsw.org>
Message-ID: <C33849F9-E0B5-4F33-A174-EE95358417DB@opencsw.org>

Hi Riccardo,

> Am 09.04.2015 um 11:36 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Dagobert Michelsen wrote:
>> You can then navigate back either with OpenGrok or Trac and see the recipe:
>>   https://buildfarm.opencsw.org/source/history/opencsw/csw/mgar/pkg/binutils/trunk/Makefile
>>   https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/binutils/trunk/Makefile?r=16881
> 
> right, I can also check the current Makefile, but how can I know which was the latest version built and available for solaris 9?

You can take a look at the catalog:
  https://mirror.opencsw.org/opencsw/unstable/sparc/5.10/


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/20150409/bdfd158f/attachment.p7s>

From rmottola at opencsw.org  Thu Apr  9 14:57:38 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 09 Apr 2015 14:57:38 +0200
Subject: latest available version of binutils for 9
In-Reply-To: <C33849F9-E0B5-4F33-A174-EE95358417DB@opencsw.org>
References: <55263328.1000605@opencsw.org>	<AA71B849-11E9-45C7-A89F-682DEF979FB0@opencsw.org>	<5526480D.1000507@opencsw.org>
	<C33849F9-E0B5-4F33-A174-EE95358417DB@opencsw.org>
Message-ID: <55267742.1080706@opencsw.org>

Hi Dago,


sorry for asking may questions  :)

Dagobert Michelsen wrote:
> You can take a look at the catalog:
>    https://mirror.opencsw.org/opencsw/unstable/sparc/5.10/
this contains mixed packages, both for solaris 9 s for 10, even for 
solaris 8! but no binutils,

However, here:
https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/

I find binutils:
binutils-2.22,REV=2012.06.14-SunOS5.9-sparc-CSW.pkg.gz 
<https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/binutils-2.22%2cREV%3d2012.06.14-SunOS5.9-sparc-CSW.pkg.gz>

Which is actually rather old. I completed a build including on unstable 
9s! I will attempt 9x.
However,  I get this:

home/rmottola/opencsw/.buildsys/v2/gar//gar.pkg.mk:946: *** You are 
building this package on a non-requested platform host 'unstable9s'. The 
following platform

I suppose that I need to add the targets to the receipe, right? That 
means however a commit and a new package and this brings our unstable9 
machines to hang due to git :(

Riccardo


From dam at opencsw.org  Thu Apr  9 15:04:29 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 9 Apr 2015 15:04:29 +0200
Subject: latest available version of binutils for 9
In-Reply-To: <55267742.1080706@opencsw.org>
References: <55263328.1000605@opencsw.org>
	<AA71B849-11E9-45C7-A89F-682DEF979FB0@opencsw.org>
	<5526480D.1000507@opencsw.org>
	<C33849F9-E0B5-4F33-A174-EE95358417DB@opencsw.org>
	<55267742.1080706@opencsw.org>
Message-ID: <FFBD7152-2C7D-4A0B-B473-1A3297C470F0@opencsw.org>

Hi Riccardo,

Am 09.04.2015 um 14:57 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> sorry for asking may questions  :)

No problem :)

> Dagobert Michelsen wrote:
>> You can take a look at the catalog:
>>   https://mirror.opencsw.org/opencsw/unstable/sparc/5.10/
> this contains mixed packages, both for solaris 9 s for 10, even for solaris 8! but no binutils,
> 
> However, here:
> https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/

Thats what I actually meant.

> I find binutils:
> binutils-2.22,REV=2012.06.14-SunOS5.9-sparc-CSW.pkg.gz <https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/binutils-2.22%2cREV%3d2012.06.14-SunOS5.9-sparc-CSW.pkg.gz>
> 
> Which is actually rather old. I completed a build including on unstable 9s! I will attempt 9x.
> However,  I get this:
> 
> home/rmottola/opencsw/.buildsys/v2/gar//gar.pkg.mk:946: *** You are building this package on a non-requested platform host 'unstable9s'. The following platform
> 
> I suppose that I need to add the targets to the receipe, right? That means however a commit and a new package and this brings our unstable9 machines to hang due to git :(

Right, and it will probably hang. I opened a case and at the moment we are making
good progress.


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/20150409/65b70981/attachment.p7s>

From rmottola at opencsw.org  Thu Apr  9 15:17:40 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 09 Apr 2015 15:17:40 +0200
Subject: gcc 4.9 on solaris 9 sparc (alignment)
In-Reply-To: <CALtRa-4hhHPHSm-Y3s2QYOUBk+_5O=qpVSQbct26CgV5YsGsHA@mail.gmail.com>
References: <5509D923.10805@opencsw.org> <55252AA3.2040501@opencsw.org>
	<CALtRa-4hhHPHSm-Y3s2QYOUBk+_5O=qpVSQbct26CgV5YsGsHA@mail.gmail.com>
Message-ID: <55267BF4.5080304@opencsw.org>

Hi Maiej,

Maciej (Matchek) Blizi?ski wrote:
> It's the same error I was getting when attempting to build on Solaris 9.
>
> When I talked to the GCC developers, they wanted me to build it in the
> most vanilla way possible, without GAR or anything like that. They
> even wanted me to build internal versions of libraries GCC depends on.
> You could see whether if a vanilla build works for you.
I haven't tried that yet, since it is a lot of work :) But what would 
mgar make different from vanilla?

I tried 4.8.4 with no difference, I tried using ccs as (we already force 
the ccs linker right now)
  This old thread https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15267

1. with Sun as + Sun ld,
2. with GNU as + GNU ld,
3. with GNU as + Sun ld + easy workaround

we were attempting 3). I don't know which the workaround is, but I tried 1) and failed.

I then check this:
https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01668.html

TGC is I suppose thew new name from the old sunfreeware stuff. They got 4.9 to build and test, 4.8 too as well.


GNU as 2.23.1
Sun ld 5.9-1.401 (112963-36)
gmp 5.1.3
mpfr 3.1.2
mpc 1.0.1
isl 0.11.2
cloog 0.18.0

Our GNU is older, I already ot 2.24 to compile, as soon as the solaris9 "hang" problem is solved, I can commit that, we have 2.22 in fact.
Can you check what solaris linker we have? Older perhaps?

I don't know and don't think the other dependencies are relevant.

They configured like this:
configure flags: --enable-obsolete --prefix=/usr/tgcware --with-local-prefix=/usr/tgcware/gcc49
  --bindir=/usr/tgcware/gcc49/bin --mandir=/usr/tgcware/gcc49/man --infodir=/usr/tgcware/gcc49/info
--disable-nls
  --enable-shared
  --enable-threads=posix
  --with-gmp=/usr/tgcware --with-mpfr=/usr/tgcware --with-mpc=/usr/tgcware --with-cloog=/usr/tgcware --with-isl=/usr/tgcware --with-cloog-backend=isl
  --without-gnu-ld --with-ld=/usr/ccs/bin/ld
  --with-gnu-as --with-as=/usr/tgcware/bin/gas
  --enable-languages=all,ada,obj-c++,go --with-x --enable-java-awt=xlib --with-cpu=v9 --with-pkgversion='tgcware 4.9.1-1' --with-bugurl=http://jupiterrise.com/tgcware


They use GNU as and sun linker, so it should work for us too! So let's see if LD is the latest version and if I can bring the AS on par.

THe only relevant differences with us I see are:
--disable-nls
  --enable-shared
--with-cpu=v9
  

We explicitely enable nls, however it should not matter I think. But 
what about "shared"?

Riccardo

From rmottola at opencsw.org  Thu Apr  9 16:22:24 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 09 Apr 2015 16:22:24 +0200
Subject: building binutils : gnu grep
Message-ID: <55268B20.1050501@opencsw.org>

Hi,

I tried building binutils 2.24 (current) on solaris 9 sparc and x86.

Build completes. However I see this:

mv -f .deps/eelf32lppclinux.Tpo .deps/eelf32lppclinux.Po
LIB_PATH='' /bin/bash ./genscripts.sh "." "/opt/csw/lib" "/opt/csw" 
"/opt/csw" i386-pc-solaris2.9 i386-pc-solaris2.9 i386-pc-solaris2.9 
"elf_i386_sol2 elf_i386_ldso elf_i386 elf_x86_64_sol2 elf_x86_64 
elf_l1om elf_k1om" "/usr/local/lib /usr/ccs/lib /lib /usr/lib" no yes 
elf32lppcnto ""
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
<..snip..>

This makes me doubt of the quality of the final product.

I suppose we need ggrep (gnu grep) here.
In the receipe I see this commented line:

# We need GNU grep
#PATH := /opt/csw/gnu:$(PATH)


Some other came to the same conclusion!

I don't see a configure parameter, but what tricks could be ther? I 
thought of GREP=/opt/csw/bin/ggrep

But where should I put that?

Riccardo

From wilbury at opencsw.org  Thu Apr  9 16:34:04 2015
From: wilbury at opencsw.org (Juraj Lutter)
Date: Thu, 09 Apr 2015 16:34:04 +0200
Subject: building binutils : gnu grep
In-Reply-To: <55268B20.1050501@opencsw.org>
References: <55268B20.1050501@opencsw.org>
Message-ID: <55268DDC.2010502@opencsw.org>

I used to patch configure and/or configure.ac and/or Makefile.in, et al.


On 04/09/15 16:22, Riccardo Mottola wrote:
> Hi,
>
> I tried building binutils 2.24 (current) on solaris 9 sparc and x86.
>
> Build completes. However I see this:
>
> mv -f .deps/eelf32lppclinux.Tpo .deps/eelf32lppclinux.Po
> LIB_PATH='' /bin/bash ./genscripts.sh "." "/opt/csw/lib" "/opt/csw"
> "/opt/csw" i386-pc-solaris2.9 i386-pc-solaris2.9 i386-pc-solaris2.9
> "elf_i386_sol2 elf_i386_ldso elf_i386 elf_x86_64_sol2 elf_x86_64
> elf_l1om elf_k1om" "/usr/local/lib /usr/ccs/lib /lib /usr/lib" no yes
> elf32lppcnto ""
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> grep: illegal option -- q
> Usage: grep -hblcnsviw pattern file . . .
> grep: illegal option -- q
> <..snip..>
>
> This makes me doubt of the quality of the final product.
>
> I suppose we need ggrep (gnu grep) here.
> In the receipe I see this commented line:
>
> # We need GNU grep
> #PATH := /opt/csw/gnu:$(PATH)
>
>
> Some other came to the same conclusion!
>
> I don't see a configure parameter, but what tricks could be ther? I
> thought of GREP=/opt/csw/bin/ggrep
>
> But where should I put that?
>
> Riccardo


-- 
Juraj Lutter <wilbury at opencsw.org>


From rmottola at opencsw.org  Thu Apr  9 18:36:05 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 09 Apr 2015 18:36:05 +0200
Subject: building binutils : gnu grep
In-Reply-To: <55268B20.1050501@opencsw.org>
References: <55268B20.1050501@opencsw.org>
Message-ID: <5526AA75.6070401@opencsw.org>

Hi,

Riccardo Mottola wrote:
> I don't see a configure parameter, but what tricks could be ther? I 
> thought of GREP=/opt/csw/bin/ggrep

for the record, passing GREP to CONFIGURE_ARGS seems to do the trick. Neat.

Riccardo

From dam at opencsw.org  Mon Apr 13 07:51:35 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 13 Apr 2015 07:51:35 +0200
Subject: Question about checkpkg issue
Message-ID: <3CEB5766-C354-4A71-B001-3BFAF4D68CF2@opencsw.org>

Hi,

I am having a problem with a package during checkpkg:

> WARNING 2015-04-13 07:44:17,562 rest.py:281 Blob 'elfdump' for 'a3ed69299e63163092ae7f055f9ee27c' was not found in the database
> Traceback (most recent call last):
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 268, in <module>
>     main()
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 215, in main
>     exit_code, screen_report, tags_report = check_manager.Run()
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/checkpkg_lib.py", line 937, in Run
>     return super(CheckpkgManager2, self).Run()
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/checkpkg_lib.py", line 301, in Run
>     errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list)
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/checkpkg_lib.py", line 921, in GetAllTags
>     function(pkgs_data, check_interface, logger=logger, messenger=messenger)
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/package_checks.py", line 331, in SetCheckLibraries
>     depchecks.Libraries(*check_args)
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/dependency_checks.py", line 245, in Libraries
>     binary_elf_info = error_mgr.GetElfdumpInfo(binary_md5)
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/checkpkg_lib.py", line 514, in GetElfdumpInfo
>     return ElfinfoBlobToStruct(elfdump_data)
>   File "/home/dam/mgar/pkg/.buildsys/v2/gar/lib/python/checkpkg_lib.py", line 178, in ElfinfoBlobToStruct
>     symbols = elfdump_data['symbol table']
> TypeError: 'NoneType' object is unsubscriptable
> /home/dam/mgar/pkg/.buildsys/v2/gar//gar.pkg.mk:1075: recipe for target 'pkgcheck' failed
> gmake[1]: *** [pkgcheck] Error 2
> gmake[1]: Leaving directory '/home/dam/mgar/pkg/jdk8/trunk'
> /home/dam/mgar/pkg/.buildsys/v2/gar//gar.pkg.mk:1120: recipe for target 'platforms' failed
> gmake: *** [platforms] Error 2
> zsh: 19457 exit 2     mgar platforms


Is the checked file to be in the package database?

> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/jdk8/trunk > gzip -c -d /home/dam/staging/build-13.Apr.2015/jre8-1.8.0_40,REV=2015.04.13-SunOS5.10-sparc-CSW.pkg.gz | gmd5sum
> 4ae5b58fb6f52e540c825124a6753aad  -

However, the data cannot be found:
  http://buildfarm.opencsw.org/pkgdb/srv4/4ae5b58fb6f52e540c825124a6753aad/struct-dump/

How can I find out why the data of the file with md5 a3ed69299e63163092ae7f055f9ee27c
is missing?


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/20150413/5a36e51f/attachment.p7s>

From rmottola at opencsw.org  Mon Apr 13 23:18:52 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 13 Apr 2015 23:18:52 +0200
Subject: package name casing
Message-ID: <552C32BC.9020804@opencsw.org>

Hi,

I get this warning:
CHECKPKG_OVERRIDES_CSWFTP += catalogname-not-lowercase

It gets from here:
NAME = FTP


which is also the name of the DISTFILES, etc.

Is this a critical thing? may I override or may I specify a different 
catalog name, e.g. gs_ftp ? How?

Riccardo

From dam at opencsw.org  Tue Apr 14 09:42:04 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 14 Apr 2015 09:42:04 +0200
Subject: package name casing
In-Reply-To: <552C32BC.9020804@opencsw.org>
References: <552C32BC.9020804@opencsw.org>
Message-ID: <C12DCEB4-630D-4E92-A22D-BD9BBF1009B4@opencsw.org>

Hi Riccardo,

> Am 13.04.2015 um 23:18 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> I get this warning:
> CHECKPKG_OVERRIDES_CSWFTP += catalogname-not-lowercase
> 
> It gets from here:
> NAME = FTP
> 
> which is also the name of the DISTFILES, etc.
> 
> Is this a critical thing? may I override or may I specify a different catalog name, e.g. gs_ftp ? How?

I added the description for the tag on the wiki page. I suggest to explicitly set e.g.
  PACKAGES += CSWgs-ftp
where the catalog name is derived from that. Please do not override it as uppercase characters
are reserved due to pkginfo(4).


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/20150414/0116a3a8/attachment.p7s>

From maciej at opencsw.org  Thu Apr 16 19:31:43 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 16 Apr 2015 10:31:43 -0700
Subject: gcc 4.9 on solaris 9 sparc (alignment)
In-Reply-To: <55267BF4.5080304@opencsw.org>
References: <5509D923.10805@opencsw.org> <55252AA3.2040501@opencsw.org>
	<CALtRa-4hhHPHSm-Y3s2QYOUBk+_5O=qpVSQbct26CgV5YsGsHA@mail.gmail.com>
	<55267BF4.5080304@opencsw.org>
Message-ID: <CALtRa-7jK+nLk9AT9qRBF+AN6eBvijrP_KNXzf9h5DF=NTDrkA@mail.gmail.com>

2015-04-09 6:17 GMT-07:00 Riccardo Mottola <rmottola at opencsw.org>:

> They use GNU as and sun linker, so it should work for us too! So let's see
> if LD is the latest version and if I can bring the AS on par.
>
> THe only relevant differences with us I see are:
> --disable-nls
>  --enable-shared
> --with-cpu=v9
>
> We explicitely enable nls, however it should not matter I think. But what
> about "shared"?
>

It's been a long time since I've done any of it, and I've forgotten it all.
One lesson is would be: Write more comments in the build file; when you do
something, explain why you're doing it.

My experience with the GCC package is that it just takes a long time (and
you need a lot of disk quota to store all the builds) to try a number of
variations and see what the results are. Keep posting the mailing list with
your further findings!

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

From rmottola at opencsw.org  Fri Apr 17 12:34:24 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 17 Apr 2015 12:34:24 +0200
Subject: progress on solaris 9
Message-ID: <5530E1B0.4070708@opencsw.org>

Hi,

are there any news regarding solaris 9? I just tried rebuilding libpng 
and I still got the hang problem. It seems to be quite nasty!

I have thus for now stopped about bigger packages like binutils which 
stops my attempts about gcc.

Riccardo

From dam at opencsw.org  Fri Apr 17 16:02:46 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 17 Apr 2015 16:02:46 +0200
Subject: progress on solaris 9
In-Reply-To: <5530E1B0.4070708@opencsw.org>
References: <5530E1B0.4070708@opencsw.org>
Message-ID: <0CD48516-404C-4456-8E4A-BD5819A8849D@opencsw.org>

Hi Riccardo,

Am 17.04.2015 um 12:34 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> are there any news regarding solaris 9? I just tried rebuilding libpng and I still got the hang problem. It seems to be quite nasty!

The issue has been found: libcrypt 1.0.1m from OpenSSL. After downgrading the CSWlibssl1-0-0
package to 1.0.1l everything works as expected again.


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/20150417/8fc7e447/attachment.p7s>

From pfelecan at opencsw.org  Sat Apr 18 09:37:17 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 18 Apr 2015 09:37:17 +0200
Subject: cannot check packages
Message-ID: <x67ft999aq.fsf@opencsw.org>

Maybe a build stack issue ?

INFO 2015-04-17 21:45:25,928 package_stats.py:132 Juicing the svr4 package stream files...
  0% ETA:  --:--:-- |                                                         |
CRITICAL 2015-04-17 22:11:23,593 shell.py:55 
CRITICAL 2015-04-17 22:11:23,595 shell.py:56 INFO 2015-04-17 21:50:33,085 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/0da78e09757e0d09d24954990b35f811/' HTTP code: 500
INFO 2015-04-17 21:55:43,122 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/0da78e09757e0d09d24954990b35f811/' HTTP code: 500
INFO 2015-04-17 22:00:53,152 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/0da78e09757e0d09d24954990b35f811/' HTTP code: 500
INFO 2015-04-17 22:06:03,181 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/0da78e09757e0d09d24954990b35f811/' HTTP code: 500
INFO 2015-04-17 22:11:13,211 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/0da78e09757e0d09d24954990b35f811/' HTTP code: 500
Traceback (most recent call last):
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/collect_pkg_metadata.py", line 623, in <module>
    unpacked = unpacker.CollectStats(force_unpack=options.force_unpack)
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/collect_pkg_metadata.py", line 594, in CollectStats
    self.md5_sum):
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/retry_decorator.py", line 39, in fn
    raise last_exception
lib.python.rest.RestCommunicationError: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/0da78e09757e0d09d24954990b35f811/' HTTP code: 500

Traceback (most recent call last):
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar//bin/../lib/python/checkpkg2.py", line 268, in <module>
    main()
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar//bin/../lib/python/checkpkg2.py", line 174, in main
    md5_sums_from_files = collector.CollectStatsFromCatalogEntries(entries, False)
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/package_stats.py", line 158, in CollectStatsFromCatalogEntries
    stderr=stderr_file)
  File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/shell.py", line 60, in ShellCommand
    % (args, retcode, ' '.join(pipes.quote(x) for x in args)))
lib.python.shell.ShellError: Running ['/home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/collect_pkg_metadata.py', '--input', '/home/pfelecan/staging/build-17.Apr.2015/gdb-7.9,REV=2015.04.17-SunOS5.10-sparc-CSW.pkg.gz'] has failed, error code: 1. To find out why the command failed, please run it in the foreground, like this: /home/pfelecan/opencsw/.buildsys/v2/gar/gar/lib/python/collect_pkg_metadata.py --input /home/pfelecan/staging/build-17.Apr.2015/gdb-7.9,REV=2015.04.17-SunOS5.10-sparc-CSW.pkg.gz
/home/pfelecan/opencsw/.buildsys/v2/gar/gar//gar.pkg.mk:1020: recipe for target 'pkgcheck' failed

-- 
Peter

From dam at opencsw.org  Sat Apr 18 12:04:54 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 18 Apr 2015 12:04:54 +0200
Subject: cannot check packages
In-Reply-To: <x67ft999aq.fsf@opencsw.org>
References: <x67ft999aq.fsf@opencsw.org>
Message-ID: <2CB0D509-6269-46F9-B69E-6D5A5AF469F6@opencsw.org>

Hi Peter,

> Am 18.04.2015 um 09:37 schrieb Peter FELECAN <pfelecan at opencsw.org>:
> 
> Maybe a build stack issue ?

Sometimes the webserver with the python engine has problem, I restart it. Would you mind
trying again?


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/20150418/c51cf110/attachment.p7s>

From pfelecan at opencsw.org  Sat Apr 18 13:37:59 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 18 Apr 2015 13:37:59 +0200
Subject: cannot check packages
In-Reply-To: <2CB0D509-6269-46F9-B69E-6D5A5AF469F6@opencsw.org> (Dagobert
	Michelsen's message of "Sat, 18 Apr 2015 12:04:54 +0200")
References: <x67ft999aq.fsf@opencsw.org>
	<2CB0D509-6269-46F9-B69E-6D5A5AF469F6@opencsw.org>
Message-ID: <x6383x8y5k.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
>> Am 18.04.2015 um 09:37 schrieb Peter FELECAN <pfelecan at opencsw.org>:
>> 
>> Maybe a build stack issue ?
>
> Sometimes the webserver with the python engine has problem, I restart it. Would you mind
> trying again?

Now it's alright.

Thank you.
-- 
Peter

From pfelecan at opencsw.org  Sat Apr 18 17:30:12 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 18 Apr 2015 17:30:12 +0200
Subject: incorrect warning during check and upload
Message-ID: <x6y4lp78u3.fsf@opencsw.org>

This message appears when checking or uploading:

Checking 1 package against catalog unstable i386 SunOS5.10

WARNING 2015-04-18 17:25:34,256 checkpkg_lib.py:658 Did not find packages for '/opt/csw/bin/isaexec'
WARNING 2015-04-18 17:25:34,257 checkpkg_lib.py:658 Did not find packages for '/opt/csw/bin/isaexec'

However, it's fallacious as the incriminated binary has a package which
is in the catalog.

N.B. I don't know where to fill a bug report, consequently I'm doing it here.
-- 
Peter

From maciej at opencsw.org  Sat Apr 18 18:06:04 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 18 Apr 2015 09:06:04 -0700
Subject: incorrect warning during check and upload
In-Reply-To: <x6y4lp78u3.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
Message-ID: <CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>

2015-04-18 8:30 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
> WARNING 2015-04-18 17:25:34,256 checkpkg_lib.py:658 Did not find packages for '/opt/csw/bin/isaexec'

To be fair, there isn't a package which would contain the
/opt/csw/bin/isaxec file. Checkpkg has no way of knowing what happens
in Turing Complete postinstall scripts.

Maciej

From dam at opencsw.org  Sat Apr 18 22:26:27 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sat, 18 Apr 2015 22:26:27 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
Message-ID: <83037D2C-EA5E-4BE8-A3D7-15BD57CA9CA7@opencsw.org>

Hi Peter,

Am 18.04.2015 um 18:06 schrieb Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 2015-04-18 8:30 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
>> WARNING 2015-04-18 17:25:34,256 checkpkg_lib.py:658 Did not find packages for '/opt/csw/bin/isaexec'
> 
> To be fair, there isn't a package which would contain the
> /opt/csw/bin/isaxec file. Checkpkg has no way of knowing what happens
> in Turing Complete postinstall scripts.

Indeed, the CSWisaexec package is a special package from Phil which takes /usr/lib/isaexec
and makes a copy of it dynamically during postinstall and then uses installf to register it.
Unfortunately that can?t really be tracked. The message is safe to ignore.


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/20150418/cf243465/attachment.p7s>

From pfelecan at opencsw.org  Sat Apr 18 22:38:37 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sat, 18 Apr 2015 22:38:37 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat,
	18 Apr 2015 09:06:04 -0700")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
Message-ID: <x6twwd6uk2.fsf@opencsw.org>

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

> 2015-04-18 8:30 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
>> WARNING 2015-04-18 17:25:34,256 checkpkg_lib.py:658 Did not find packages for '/opt/csw/bin/isaexec'
>
> To be fair, there isn't a package which would contain the
> /opt/csw/bin/isaxec file. Checkpkg has no way of knowing what happens
> in Turing Complete postinstall scripts.

Well, it's still fallacious as there is a package. Turing or not.
Given that it's a warning it's not bothering me but this way it's
complete and available for other wondering souls.
-- 
Peter

From maciej at opencsw.org  Sat Apr 18 22:47:25 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sat, 18 Apr 2015 13:47:25 -0700
Subject: incorrect warning during check and upload
In-Reply-To: <x6twwd6uk2.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
Message-ID: <CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>

2015-04-18 13:38 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
> Well, it's still fallacious as there is a package. Turing or not.

What do you mean precisely by "there is a package"? What criteria do
you have in mind?

Maciej

From pfelecan at opencsw.org  Sun Apr 19 09:35:04 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 19 Apr 2015 09:35:04 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat,
	18 Apr 2015 13:47:25 -0700")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
Message-ID: <x6pp707eqf.fsf@opencsw.org>

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

> 2015-04-18 13:38 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
>> Well, it's still fallacious as there is a package. Turing or not.
>
> What do you mean precisely by "there is a package"? What criteria do
> you have in mind?

an OpenCSW package, CSWisaexec, which is still present in the catalog
and on which depend 118 other packages

-- 
Peter

From rmottola at opencsw.org  Sun Apr 19 10:36:42 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 19 Apr 2015 10:36:42 +0200
Subject: progress on solaris 9
In-Reply-To: <0CD48516-404C-4456-8E4A-BD5819A8849D@opencsw.org>
References: <5530E1B0.4070708@opencsw.org>
	<0CD48516-404C-4456-8E4A-BD5819A8849D@opencsw.org>
Message-ID: <5533691A.50401@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> The issue has been found: libcrypt 1.0.1m from OpenSSL. After downgrading the CSWlibssl1-0-0
> package to 1.0.1l everything works as expected again.
aha, good that you nailed it down! Perhaps it needs to be fixed in 
OpnSSL? Or at least reported?

I got strange errors, but similar to Peter's, I see they are solved for 
him and thus will retry.

Thanks for the patience.

Riccardo

From rmottola at opencsw.org  Sun Apr 19 11:05:38 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 19 Apr 2015 11:05:38 +0200
Subject: libpng update 16
Message-ID: <55336FE2.6030108@opencsw.org>

Hi,

I undeterook the effort to update libpng, I have not yet commited 
anything, I understand that it is delicate about so-names and other 
issues and I don't want to mess up since I am not the maintainer.
I want to have it working on solaris 9 & 10.

I have the patch pasted below, any comments? If you prefer, I can commit.
I essentially replaced 15 verywhere with 16, that should give a new soname

I think I get a reasonable result:


However I get this warning:
CHECKPKG_OVERRIDES_CSWlibpng-dev += missing-dependency|CSWlibz1

http://buildfarm.opencsw.org/pkgdb/srv4/0bf6255600e4f6656533564e33a5b9a9/

I think the culprit is:

1 s none /opt/csw/lib/libpng.so=libpng16.so
1 s none /opt/csw/lib/libpng16.so=libpng16.so.16.16.0

is the second linkk correct? Or should it be in the


which makes no sense, a dev package should not depend on a library, at 
most it could depend on its -dev library, but I don't think that is the 
error message, right?


Riccardo



+++ Makefile    (working copy)
@@ -1,4 +1,4 @@
-# Copyright 2009 OpenCSW
+# Copyright 2009-2015 OpenCSW
  # Distributed under the terms of the GNU General Public License v2
  # $Id$
  #
@@ -10,7 +10,7 @@
  #   pentium_pro

  NAME = libpng
-VERSION = 1.5.13
+VERSION = 1.6.16
  GARTYPE = v2
  DESCRIPTION = The official library for Portable Network Graphics 
format (PNG)
  define BLURB
@@ -27,19 +27,26 @@
  EXTRA_BUILD_ISAS += sparcv8plus+vis2
  EXTRA_BUILD_ISAS += pentium_pro

+#where can we build?
+PACKAGING_PLATFORMS += solaris9-sparc
+PACKAGING_PLATFORMS += solaris9-i386
+PACKAGING_PLATFORMS += solaris10-sparc
+PACKAGING_PLATFORMS += solaris10-i386
+
+
  PACKAGES = CSWlibpng-dev
  SPKG_DESC_CSWlibpng-dev = $(DESCRIPTION), development files
-RUNTIME_DEP_PKGS_CSWlibpng-dev += CSWlibpng15-15
+RUNTIME_DEP_PKGS_CSWlibpng-dev += CSWlibpng16-16

-PACKAGES += CSWlibpng15-15
-CATALOGNAME_CSWlibpng15-15 = libpng15_15
-PKGFILES_CSWlibpng15-15 += $(call 
baseisadirs,$(libdir),libpng15\.so\.15(\.\d+)*)
-SPKG_DESC_CSWlibpng15-15 += $(DESCRIPTION), libpng15.so.15
-RUNTIME_DEP_PKGS_CSWlibpng += CSWlibpng15-15
-RUNTIME_DEP_PKGS_CSWlibpng15-15 += CSWlibz1
+PACKAGES += CSWlibpng16-16
+CATALOGNAME_CSWlibpng16-16 = libpng16_16
+PKGFILES_CSWlibpng16-16+= $(call 
baseisadirs,$(libdir),libpng16\.so\.16(\.\d+)*)
+SPKG_DESC_CSWlibpng16-16 += $(DESCRIPTION), libpng16.so.16
+RUNTIME_DEP_PKGS_CSWlibpng += CSWlibpng16-16
+RUNTIME_DEP_PKGS_CSWlibpng16-16 += CSWlibz1

  # The CSWpng package must also pull in libpng.so.3 and libpng12.so.0
-OBSOLETED_BY_CSWlibpng15-15 = CSWpng
+OBSOLETED_BY_CSWlibpng16-16 = CSWpng


From maciej at opencsw.org  Sun Apr 19 15:33:40 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 06:33:40 -0700
Subject: incorrect warning during check and upload
In-Reply-To: <x6pp707eqf.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
Message-ID: <CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>

2015-04-19 0:35 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
> an OpenCSW package, CSWisaexec, which is still present in the catalog
> and on which depend 118 other packages

Yes, but why CSWisaexec in particular and not some other package?

From maciej at opencsw.org  Sun Apr 19 15:39:07 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 06:39:07 -0700
Subject: libpng update 16
In-Reply-To: <55336FE2.6030108@opencsw.org>
References: <55336FE2.6030108@opencsw.org>
Message-ID: <CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>

2015-04-19 2:05 GMT-07:00 Riccardo Mottola <rmottola at opencsw.org>:
> However I get this warning:
> CHECKPKG_OVERRIDES_CSWlibpng-dev += missing-dependency|CSWlibz1

Try to scroll up in your terminal, checkpkg says exactly why it thinks
dependencies are needed.

From pfelecan at opencsw.org  Sun Apr 19 16:57:26 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 19 Apr 2015 16:57:26 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun,
	19 Apr 2015 06:33:40 -0700")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
Message-ID: <x6h9sc6u95.fsf@opencsw.org>

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

> 2015-04-19 0:35 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
>> an OpenCSW package, CSWisaexec, which is still present in the catalog
>> and on which depend 118 other packages
>
> Yes, but why CSWisaexec in particular and not some other package?

For the first part of your question:

# pkgchk -l -p /opt/csw/bin/isaexec
CSWisaexec

# pkgutil --listfile isaexec
/opt/csw/bin/isaexec

As for the second part, you take the risk to fail Turing's test ;-)
But why not, indeed?

Anyway, the warning annoys me because there is too much noise already.
It warns me about what?
-- 
Peter

From maciej at opencsw.org  Sun Apr 19 18:12:46 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 09:12:46 -0700
Subject: incorrect warning during check and upload
In-Reply-To: <x6h9sc6u95.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
Message-ID: <CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>

2015-04-19 7:57 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
> For the first part of your question:
>
> # pkgchk -l -p /opt/csw/bin/isaexec
> CSWisaexec

I found the corresponding part from the postinstall script:

installf $PKGINST /opt/csw/bin/isaexec f

This is how pkgchk knows which package provides /opt/csw/bin/isaexec.

Some possibilities are:

1. Try to track down what postinstall does (but how?)
2. Modify CSWisaexec to provide a fake pkgmap entry (how?)
3. Distribute our own isaexec binary, compiled from external source (Illumos?)
4. Write our own isaexec

> As for the second part, you take the risk to fail Turing's test ;-)
> But why not, indeed?
>
> Anyway, the warning annoys me because there is too much noise already.
> It warns me about what?

It goes like this:

1. your package contains a hardlink to a file, and will likely not
work without it
2. it makes sense to check which package provides this file
3. we look at pkgmap of all packages to find the right one

The warning is generic, it warns you that your package depends on a
file, but we don't know what to suggest to fulfill that dependency.
Normally you find out what package that is and you suggest adding it
as a dependency. But what if you cannot find that package? You display
a warning.

Maciej

From pfelecan at opencsw.org  Sun Apr 19 19:15:10 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Sun, 19 Apr 2015 19:15:10 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun,
	19 Apr 2015 09:12:46 -0700")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
Message-ID: <x6d2306nvl.fsf@opencsw.org>

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

> 2015-04-19 7:57 GMT-07:00 Peter FELECAN <pfelecan at opencsw.org>:
>> For the first part of your question:
>>
>> # pkgchk -l -p /opt/csw/bin/isaexec
>> CSWisaexec
>
> I found the corresponding part from the postinstall script:
>
> installf $PKGINST /opt/csw/bin/isaexec f
>
> This is how pkgchk knows which package provides /opt/csw/bin/isaexec.
>
> Some possibilities are:
>
> 1. Try to track down what postinstall does (but how?)
> 2. Modify CSWisaexec to provide a fake pkgmap entry (how?)
> 3. Distribute our own isaexec binary, compiled from external source (Illumos?)
> 4. Write our own isaexec

the fourth possibility seems to me the most adequate; by the way, it's
not rocket science; however, having a look to SUN's c/o Illumos
implementation is worthy as much more cmplete (hah, Alan is here again
but not in the correct sense, consequently is just a bot) than what we
have today.

>> As for the second part, you take the risk to fail Turing's test ;-)
>> But why not, indeed?
>>
>> Anyway, the warning annoys me because there is too much noise already.
>> It warns me about what?
>
> It goes like this:
>
> 1. your package contains a hardlink to a file, and will likely not
> work without it
> 2. it makes sense to check which package provides this file
> 3. we look at pkgmap of all packages to find the right one

yes, I agree

> The warning is generic, it warns you that your package depends on a
> file, but we don't know what to suggest to fulfill that dependency.
> Normally you find out what package that is and you suggest adding it
> as a dependency. But what if you cannot find that package? You display
> a warning.

also agreed; however, this warning can be silenced when the CSWisaexec
will have a map; by the way, I've seen that you just acted in that
direction.

-- 
Peter

From rmottola at opencsw.org  Sun Apr 19 19:45:23 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 19 Apr 2015 19:45:23 +0200
Subject: updated binutils for solaris 9
Message-ID: <5533E9B3.6060000@opencsw.org>

Hi,

I attempted to build current binutils on solaris 9 sparc.

During build I get these Warnings:
WARNING 2015-04-19 14:32:11,270 checkpkg_lib.py:311 Not saving an error 
for CSWgdb.
WARNING 2015-04-19 14:32:11,272 checkpkg_lib.py:311 Not saving an error 
for CSWgnulinks.
WARNING 2015-04-19 14:32:11,273 checkpkg_lib.py:311 Not saving an error 
for CSWgnulinks.
the last being repeated many times.

Anyway, the final errors I get are:

CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/nm|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/size|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/strings|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/objcopy|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/ld|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/ar|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/addr2line|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/c++filt|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/strip|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/as|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/ranlib|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/readelf|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/objdump|CSWbinutils|CSWgnulinks
CHECKPKG_OVERRIDES_CSWbinutils += 
file-collision|/opt/csw/gnu/gprof|CSWbinutils|CSWgnulinks


What's the matter here? Why is everything fine on sol. 10?

Riccardo

From maciej at opencsw.org  Sun Apr 19 19:48:08 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 10:48:08 -0700
Subject: updated binutils for solaris 9
In-Reply-To: <5533E9B3.6060000@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>
Message-ID: <CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>

2015-04-19 10:45 GMT-07:00 Riccardo Mottola <rmottola at opencsw.org>:
> What's the matter here? Why is everything fine on sol. 10?

Maybe gnulinks were not updated for Solaris 9?

http://buildfarm.opencsw.org/pkgdb/srv4/4b2128388844389ad0a86c07ca12a33f/

You could update gnulinks and publish at the same time. (one
csw-uploadpkg command).

Maciej

From rmottola at opencsw.org  Sun Apr 19 19:50:50 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 19 Apr 2015 19:50:50 +0200
Subject: checkpkg warnings II
Message-ID: <5533EAFA.3080807@opencsw.org>

Hi,

while doing a csw-upload (from login) I seem to get similar warnings 
than duing mgar on solaris 9:

WARNING 2015-04-19 19:48:11,144 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,146 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,146 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,147 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,148 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,149 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,150 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,151 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,152 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,153 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,154 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,155 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,156 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
WARNING 2015-04-19 19:48:11,156 checkpkg_lib.py:311 Not saving an error 
for CSWprojectcenter.
<...>

The uploads were marked as successful though.

Riccardo

From maciej at opencsw.org  Sun Apr 19 19:56:29 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 10:56:29 -0700
Subject: Please test CSWisaexec
Message-ID: <CALtRa-4-Mqw65k_GQ9cjjkn7R6LgZe6P9-AX4z5XXBcqTpXvXA@mail.gmail.com>

Hello maintainers,

isaexec is a small but important package responsible for executing
architecture specific variants of binaries on the filesystem. I looked
at the package we have now, and thought I'd do it in a simpler way.
The new package passed my first tests. It's such an important package,
that I'd like to hear from people who tested it before I push it into
unstable.

pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/maciej -i isaexec

Maciej

From maciej at opencsw.org  Sun Apr 19 20:01:57 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 11:01:57 -0700
Subject: checkpkg warnings II
In-Reply-To: <5533EAFA.3080807@opencsw.org>
References: <5533EAFA.3080807@opencsw.org>
Message-ID: <CALtRa-4_aSmsxD96PpbwvOFkCdB5b4hpEw5jWGNJJhWWbOZm9A@mail.gmail.com>

2015-04-19 10:50 GMT-07:00 Riccardo Mottola <rmottola at opencsw.org>:
> WARNING 2015-04-19 19:48:11,144 checkpkg_lib.py:311 Not saving an error for
> CSWprojectcenter.

I realized it doesn't make sense to display this as a warning. I've
demoted it to debug level, please sync your client.

From rmottola at opencsw.org  Sun Apr 19 20:04:17 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 19 Apr 2015 20:04:17 +0200
Subject: libpng update 16
In-Reply-To: <CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>
References: <55336FE2.6030108@opencsw.org>
	<CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>
Message-ID: <5533EE21.4020205@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-04-19 2:05 GMT-07:00 Riccardo Mottola<rmottola at opencsw.org>:
>> >However I get this warning:
>> >CHECKPKG_OVERRIDES_CSWlibpng-dev += missing-dependency|CSWlibz1
> Try to scroll up in your terminal, checkpkg says exactly why it thinks
> dependencies are needed.
>

I see:

* Dependency issues of CSWlibpng-dev:
  * CSWlibz1 is needed by CSWlibpng-dev, because:
  *  - opt/csw/bin/png-fix-itxt needs the libz.so.1 soname
  *  - opt/csw/bin/pngfix needs the libz.so.1 soname
  * RUNTIME_DEP_PKGS_CSWlibpng-dev += CSWlibz1



I have no clue what those files are, but "bin" makes me think they 
shouldn't be in "-dev" ?

Riccardo

From maciej at opencsw.org  Sun Apr 19 20:06:58 2015
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 19 Apr 2015 11:06:58 -0700
Subject: libpng update 16
In-Reply-To: <5533EE21.4020205@opencsw.org>
References: <55336FE2.6030108@opencsw.org>
	<CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>
	<5533EE21.4020205@opencsw.org>
Message-ID: <CALtRa-7y8baEjiHL2pnkx0M0uORy-mKuLXkYi6vf1-+sWcs1mw@mail.gmail.com>

2015-04-19 11:04 GMT-07:00 Riccardo Mottola <rmottola at opencsw.org>:
> * Dependency issues of CSWlibpng-dev:
>  * CSWlibz1 is needed by CSWlibpng-dev, because:
>  *  - opt/csw/bin/png-fix-itxt needs the libz.so.1 soname
>  *  - opt/csw/bin/pngfix needs the libz.so.1 soname
>  * RUNTIME_DEP_PKGS_CSWlibpng-dev += CSWlibz1
>
> I have no clue what those files are, but "bin" makes me think they shouldn't
> be in "-dev" ?

Either in -dev, or in a separate package, depending what they are. You
need to find that out. Looking at prior art (e.g. Debian) is a good
idea.

Putting them in -dev is the simplest, and in such a case it is
necessary for -dev to depend on CSWlibz1.

Maciej

From rmottola at opencsw.org  Mon Apr 20 09:34:55 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 20 Apr 2015 09:34:55 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
References: <5533E9B3.6060000@opencsw.org>
	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
Message-ID: <5534AC1F.80806@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-04-19 10:45 GMT-07:00 Riccardo Mottola<rmottola at opencsw.org>:
>> >What's the matter here? Why is everything fine on sol. 10?
> Maybe gnulinks were not updated for Solaris 9?
>
> http://buildfarm.opencsw.org/pkgdb/srv4/4b2128388844389ad0a86c07ca12a33f/
>
> You could update gnulinks and publish at the same time. (one
> csw-uploadpkg command).

I am not yet uploading the binutils packages, still building & checking 
them.

I have rebuilt gnulinks though, should I upload that one and afterwards 
continue work on binutils or would this cause problems? What is this 
"links" package?

Riccardo

From rmottola at opencsw.org  Mon Apr 20 10:26:36 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 20 Apr 2015 10:26:36 +0200
Subject: libpng update 16
In-Reply-To: <CALtRa-7y8baEjiHL2pnkx0M0uORy-mKuLXkYi6vf1-+sWcs1mw@mail.gmail.com>
References: <55336FE2.6030108@opencsw.org>	<CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>	<5533EE21.4020205@opencsw.org>
	<CALtRa-7y8baEjiHL2pnkx0M0uORy-mKuLXkYi6vf1-+sWcs1mw@mail.gmail.com>
Message-ID: <5534B83C.8000509@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> Either in -dev, or in a separate package, depending what they are. You
> need to find that out. Looking at prior art (e.g. Debian) is a good
> idea.
>
> Putting them in -dev is the simplest, and in such a case it is
> necessary for -dev to depend on CSWlibz1.

I did some research. Debian doesn't have them in any packages.

They are utility programs:

*pngfix*

	

tests, optimizes and optionally fixes the zlib header in PNG files. 
Optionally, when fixing, strips ancillary chunks from the file.

*png-fix-itxt*

	

fixes PNG files that have an incorrect length field in the iTXt chunks.



Thus strictly speaking not something for developer but for users. A 
separate package, like png-utils ?
Perhaps it is not worth the effort and w can just slap then in -dev or 
even exclude them as apparently others do?

Both for me are fine.

Riccardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150420/7879e81e/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Mon Apr 20 13:38:49 2015
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 20 Apr 2015 13:38:49 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <x6d2306nvl.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
Message-ID: <5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>

Peter FELECAN <pfelecan at opencsw.org> wrote:

> > This is how pkgchk knows which package provides /opt/csw/bin/isaexec.
> >
> > Some possibilities are:
> >
> > 1. Try to track down what postinstall does (but how?)
> > 2. Modify CSWisaexec to provide a fake pkgmap entry (how?)
> > 3. Distribute our own isaexec binary, compiled from external source (Illumos?)
> > 4. Write our own isaexec
>
> the fourth possibility seems to me the most adequate; by the way, it's
> not rocket science; however, having a look to SUN's c/o Illumos
> implementation is worthy as much more cmplete (hah, Alan is here again
> but not in the correct sense, consequently is just a bot) than what we
> have today.

It is not trivial if you like to create secure code that fits into a single 
page.

BTW: I created na isaexec implementation based on the Sun implementation.
This was reworked not to depend on a libc function (as recent OpenSolaris 
sources) and it still fits into a single page.

J?rg

-- 
 EMail:joerg at schily.net                    (home) J?rg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

From dam at opencsw.org  Mon Apr 20 14:23:03 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 20 Apr 2015 14:23:03 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <5534AC1F.80806@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>
	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
	<5534AC1F.80806@opencsw.org>
Message-ID: <F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>

Hi Riccardo,

Am 20.04.2015 um 09:34 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Maciej (Matchek) Blizi?ski wrote:
>> 2015-04-19 10:45 GMT-07:00 Riccardo Mottola<rmottola at opencsw.org>:
>>> >What's the matter here? Why is everything fine on sol. 10?
>> Maybe gnulinks were not updated for Solaris 9?
>> 
>> http://buildfarm.opencsw.org/pkgdb/srv4/4b2128388844389ad0a86c07ca12a33f/
>> 
>> You could update gnulinks and publish at the same time. (one
>> csw-uploadpkg command).
> 
> I am not yet uploading the binutils packages, still building & checking them.
> 
> I have rebuilt gnulinks though, should I upload that one and afterwards continue work on binutils or would this cause problems? What is this "links" package?

Updating gnulinks is tricky. It goes like this: /opt/csw/gnu contains links to
GNU programs without the ?g?-prefix. Historically these links were shipped by
CSWgnulinks. Then we got smarter and each packages shipped his own links
(like CSWgmake ships /opt/csw/gnu/make) and they were removed one by one from
CSWgnulinks. Both the updated package (e.g. CSWgmake) and CSWgnulinks need to
be updated in sync and uploaded in the same run. As there have been no releases
on Solaris 9 you need to investigate starting from the version of CSWgnulinks
shipped in Solaris 9 which links have been updated and upload only that to
Solaris 9 catalog. I suggest you undo the change to gnulinks/trunk and make
a new branch for Solaris 9. Please keep in mind at the moment the Solaris 9
catalog works and it should prio 1 to not leave it in broken state.


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/20150420/fe0a3331/attachment-0001.p7s>

From rmottola at opencsw.org  Mon Apr 20 14:43:43 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 20 Apr 2015 14:43:43 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>	<5534AC1F.80806@opencsw.org>
	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>
Message-ID: <5534F47F.2050008@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Updating gnulinks is tricky. It goes like this: /opt/csw/gnu contains links to
> GNU programs without the ?g?-prefix. Historically these links were shipped by
> CSWgnulinks. Then we got smarter and each packages shipped his own links
> (like CSWgmake ships /opt/csw/gnu/make) and they were removed one by one from
> CSWgnulinks. Both the updated package (e.g. CSWgmake) and CSWgnulinks need to
> be updated in sync and uploaded in the same run. As there have been no releases
> on Solaris 9 you need to investigate starting from the version of CSWgnulinks
> shipped in Solaris 9 which links have been updated and upload only that to
> Solaris 9 catalog. I suggest you undo the change to gnulinks/trunk and make
> a new branch for Solaris 9. Please keep in mind at the moment the Solaris 9
> catalog works and it should prio 1 to not leave it in broken state.

If I understand correctly, it means that gnulinks shouldn't be necessary 
and that I need to remove link after link if i update the packages on 
Solaris 9 and for now I should remove only the things provided by 
binutils and in the future new stuff i would try to update?

Explain e more about the branch, I think this is the part I asked many 
times on how to handle diversities between solaris versions, right?
Tell me how to work with branches in mgar... like how to do it, branch 
each single package? I suppos we want to have some sort of "solaris 9" 
branch and keep the differences as small as possible

Riccardo


From dam at opencsw.org  Mon Apr 20 14:50:00 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 20 Apr 2015 14:50:00 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <5534F47F.2050008@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>
	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
	<5534AC1F.80806@opencsw.org>
	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>
	<5534F47F.2050008@opencsw.org>
Message-ID: <2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>

Hi Riccardo,

> Am 20.04.2015 um 14:43 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> Updating gnulinks is tricky. It goes like this: /opt/csw/gnu contains links to
>> GNU programs without the ?g?-prefix. Historically these links were shipped by
>> CSWgnulinks. Then we got smarter and each packages shipped his own links
>> (like CSWgmake ships /opt/csw/gnu/make) and they were removed one by one from
>> CSWgnulinks. Both the updated package (e.g. CSWgmake) and CSWgnulinks need to
>> be updated in sync and uploaded in the same run. As there have been no releases
>> on Solaris 9 you need to investigate starting from the version of CSWgnulinks
>> shipped in Solaris 9 which links have been updated and upload only that to
>> Solaris 9 catalog. I suggest you undo the change to gnulinks/trunk and make
>> a new branch for Solaris 9. Please keep in mind at the moment the Solaris 9
>> catalog works and it should prio 1 to not leave it in broken state.
> 
> If I understand correctly, it means that gnulinks shouldn't be necessary and that I need to remove link after link if i update the packages on Solaris 9 and for now I should remove only the things provided by binutils and in the future new stuff i would try to update?

Right.

> Explain e more about the branch, I think this is the part I asked many times on how to handle diversities between solaris versions, right?
> Tell me how to work with branches in mgar... like how to do it, branch each single package? I suppos we want to have some sort of "solaris 9" branch and keep the differences as small as possible

That depends. For gnulinks the packages are completely different so I would
just make a copy of trunk to branches/solaris9. For other packages which share
almost all of the code you may add the PACKAGING_PLATFORMS and use conditional
assignments. If in doubt, branch for Solaris 9 as the changes are usually not
needed in Solaris 10 and essentially the focus is going forward to 11.


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/20150420/a953fd13/attachment.p7s>

From dam at opencsw.org  Mon Apr 20 15:06:30 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 20 Apr 2015 15:06:30 +0200
Subject: libpng update 16
In-Reply-To: <55336FE2.6030108@opencsw.org>
References: <55336FE2.6030108@opencsw.org>
Message-ID: <0EC8102F-BF9B-4D4D-95E6-1137C13C6F4C@opencsw.org>

Hi Riccardo,

Am 19.04.2015 um 11:05 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> I undeterook the effort to update libpng, I have not yet commited anything, I understand that it is delicate about so-names and other issues and I don't want to mess up since I am not the maintainer.
> I want to have it working on solaris 9 & 10.
> 
> I have the patch pasted below, any comments? If you prefer, I can commit.
> I essentially replaced 15 verywhere with 16, that should give a new soname.

> # The CSWpng package must also pull in libpng.so.3 and libpng12.so.0
> -OBSOLETED_BY_CSWlibpng15-15 = CSWpng
> +OBSOLETED_BY_CSWlibpng16-16 = CSWpng

This is tricky. You must not change CSWpng. That is a legacy package that needs to pull in
the libs in the comment because legacy packages may rely on these. I suggest you
completely remove the obsoletion.


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/20150420/6db1e9c3/attachment.p7s>

From dam at opencsw.org  Mon Apr 20 15:07:00 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 20 Apr 2015 15:07:00 +0200
Subject: libpng update 16
In-Reply-To: <5534B83C.8000509@opencsw.org>
References: <55336FE2.6030108@opencsw.org>
	<CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>
	<5533EE21.4020205@opencsw.org>
	<CALtRa-7y8baEjiHL2pnkx0M0uORy-mKuLXkYi6vf1-+sWcs1mw@mail.gmail.com>
	<5534B83C.8000509@opencsw.org>
Message-ID: <0392DEE7-E16E-4EAB-86AF-D8E17E696336@opencsw.org>


> Am 20.04.2015 um 10:26 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> Maciej (Matchek) Blizi?ski wrote:
>> Either in -dev, or in a separate package, depending what they are. You
>> need to find that out. Looking at prior art (e.g. Debian) is a good
>> idea.
>> 
>> Putting them in -dev is the simplest, and in such a case it is
>> necessary for -dev to depend on CSWlibz1.
> 
> I did some research. Debian doesn't have them in any packages.
> 
> They are utility programs:
> pngfix
> 
> tests, optimizes and optionally fixes the zlib header in PNG files. Optionally, when fixing, strips ancillary chunks from the file. 
> 
>  <>png-fix-itxt             
> 
> fixes PNG files that have an incorrect length field in the iTXt chunks.
> 
> 
> 
> Thus strictly speaking not something for developer but for users. A separate package, like png-utils ?
> Perhaps it is not worth the effort and w can just slap then in -dev or even exclude them as apparently others d

I suggest CSWlibpng-util.


Best regards

  ? Dago


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150420/7e62d533/attachment-0001.html>
-------------- 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/20150420/7e62d533/attachment-0001.p7s>

From dam at opencsw.org  Mon Apr 20 15:22:45 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 20 Apr 2015 15:22:45 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
Message-ID: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>

Hi folks,

I want to raise the issue about OpenSSL 1.0.1m again. On Sparc we have now
two serious issues:

- BIND fails with crypto failure
  https://www.opencsw.org/mantis/view.php?id=5237
- Solaris 9 applications have issues with hangs in unrelated code. This has been seen
  at least in GIT and Python

How do we proceed here? While I do notice that it would be good to provide a working 1.0.1m
the status quo is that bad that I would suggest rolling back to 1.0.1l at least on Sparc
if the issue can not be resolved in a reasonable timeframe.


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/20150420/d7e31666/attachment.p7s>

From pfelecan at opencsw.org  Mon Apr 20 19:29:12 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Mon, 20 Apr 2015 19:29:12 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	(Joerg Schilling's message of "Mon, 20 Apr 2015 13:38:49 +0200")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <x64moa7lp3.fsf@opencsw.org>

Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> writes:

> Peter FELECAN <pfelecan at opencsw.org> wrote:
>
>> > This is how pkgchk knows which package provides /opt/csw/bin/isaexec.
>> >
>> > Some possibilities are:
>> >
>> > 1. Try to track down what postinstall does (but how?)
>> > 2. Modify CSWisaexec to provide a fake pkgmap entry (how?)
>> > 3. Distribute our own isaexec binary, compiled from external source (Illumos?)
>> > 4. Write our own isaexec
>>
>> the fourth possibility seems to me the most adequate; by the way, it's
>> not rocket science; however, having a look to SUN's c/o Illumos
>> implementation is worthy as much more cmplete (hah, Alan is here again
>> but not in the correct sense, consequently is just a bot) than what we
>> have today.
>
> It is not trivial if you like to create secure code that fits into a single 
> page.
>
> BTW: I created na isaexec implementation based on the Sun implementation.
> This was reworked not to depend on a libc function (as recent OpenSolaris 
> sources) and it still fits into a single page.

Wouldn't be nice that you include your implementation in our isaexec
package?
-- 
Peter

From yann at pleiades.fr.eu.org  Mon Apr 20 22:09:44 2015
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 20 Apr 2015 22:09:44 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>
References: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>
Message-ID: <CAF2fwscXm0hjyy4_FP+0mJ4U3SSGw4P7Gc2Gi_Q5a4545swZjg@mail.gmail.com>

Hi everybody,

I still don't have enough time work on it but my advice would be to first
try to recompile the openssl sparc package with all upstream Oracle patches
disabled to ensure that check if it is an openssl upstream problem or not.

Patches to disabled are: openssl-1.0.1m-fork_safe.patch,
openssl-1.0.1m-pkcs11-engine.patch, openssl-1.0.1m-wanboot.patch,
openssl-1.0.1m-t4-engine.sparc.5.11.patch,
openssl-1.0.1e-t4-engine-sparcv9+vis.sparc.5.11.patch.

I will try to answer questions from whoever can work on this.

Yann


2015-04-20 15:22 GMT+02:00 Dagobert Michelsen <dam at opencsw.org>:

> Hi folks,
>
> I want to raise the issue about OpenSSL 1.0.1m again. On Sparc we have now
> two serious issues:
>
> - BIND fails with crypto failure
>   https://www.opencsw.org/mantis/view.php?id=5237
> - Solaris 9 applications have issues with hangs in unrelated code. This
> has been seen
>   at least in GIT and Python
>
> How do we proceed here? While I do notice that it would be good to provide
> a working 1.0.1m
> the status quo is that bad that I would suggest rolling back to 1.0.1l at
> least on Sparc
> if the issue can not be resolved in a reasonable timeframe.
>
>
> Best regards
>
>   ? Dago
>
> --
> "You don't become great by trying to be great, you become great by wanting
> to do something,
> and then doing it so hard that you become great in the process." - xkcd
> #896
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150420/eed94e50/attachment.html>

From dam at opencsw.org  Mon Apr 20 22:11:32 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 20 Apr 2015 22:11:32 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <CAF2fwscXm0hjyy4_FP+0mJ4U3SSGw4P7Gc2Gi_Q5a4545swZjg@mail.gmail.com>
References: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>
	<CAF2fwscXm0hjyy4_FP+0mJ4U3SSGw4P7Gc2Gi_Q5a4545swZjg@mail.gmail.com>
Message-ID: <5279BBF8-1DE2-4FBD-B9B4-9C6057319DD7@opencsw.org>

Hi Yann,

> Am 20.04.2015 um 22:09 schrieb Yann Rouillard <yann at pleiades.fr.eu.org>:
> 
> Hi everybody,
> 
> I still don't have enough time work on it but my advice would be to first try to recompile the openssl sparc package with all upstream Oracle patches disabled to ensure that check if it is an openssl upstream problem or not.
> 
> Patches to disabled are: openssl-1.0.1m-fork_safe.patch, openssl-1.0.1m-pkcs11-engine.patch, openssl-1.0.1m-wanboot.patch, openssl-1.0.1m-t4-engine.sparc.5.11.patch, openssl-1.0.1e-t4-engine-sparcv9+vis.sparc.5.11.patch.
> 
> I will try to answer questions from whoever can work on this.

I just had a discussion with Laurent about the rebuild: are there any special precautions to be
taken or can it just be built by ?mgar spotless && mgar platforms??


Best regards

  ? Dago

> 
> Yann
> 
> 
> 2015-04-20 15:22 GMT+02:00 Dagobert Michelsen <dam at opencsw.org <mailto:dam at opencsw.org>>:
> Hi folks,
> 
> I want to raise the issue about OpenSSL 1.0.1m again. On Sparc we have now
> two serious issues:
> 
> - BIND fails with crypto failure
>   https://www.opencsw.org/mantis/view.php?id=5237 <https://www.opencsw.org/mantis/view.php?id=5237>
> - Solaris 9 applications have issues with hangs in unrelated code. This has been seen
>   at least in GIT and Python
> 
> How do we proceed here? While I do notice that it would be good to provide a working 1.0.1m
> the status quo is that bad that I would suggest rolling back to 1.0.1l at least on Sparc
> if the issue can not be resolved in a reasonable timeframe.
> 
> 
> 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
> 
> 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150420/f786b6b3/attachment-0001.html>
-------------- 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/20150420/f786b6b3/attachment-0001.p7s>

From yann at pleiades.fr.eu.org  Mon Apr 20 22:24:00 2015
From: yann at pleiades.fr.eu.org (Yann Rouillard)
Date: Mon, 20 Apr 2015 22:24:00 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <5279BBF8-1DE2-4FBD-B9B4-9C6057319DD7@opencsw.org>
References: <C34DE9BB-2336-4678-9B10-B6E520BF107D@opencsw.org>
	<CAF2fwscXm0hjyy4_FP+0mJ4U3SSGw4P7Gc2Gi_Q5a4545swZjg@mail.gmail.com>
	<5279BBF8-1DE2-4FBD-B9B4-9C6057319DD7@opencsw.org>
Message-ID: <CAF2fwsfWgxPvoYk+APJke6p+1n5F6hfbRa5E-+PzJceEP0hUMA@mail.gmail.com>

No special precaution I think.
You can speed the rebuild by using mgar platforms-fast or mgar package-fast
but that is not required.

Yann

2015-04-20 22:11 GMT+02:00 Dagobert Michelsen <dam at opencsw.org>:

> Hi Yann,
>
> Am 20.04.2015 um 22:09 schrieb Yann Rouillard <yann at pleiades.fr.eu.org>:
>
> Hi everybody,
>
> I still don't have enough time work on it but my advice would be to first
> try to recompile the openssl sparc package with all upstream Oracle patches
> disabled to ensure that check if it is an openssl upstream problem or not.
>
> Patches to disabled are: openssl-1.0.1m-fork_safe.patch,
> openssl-1.0.1m-pkcs11-engine.patch, openssl-1.0.1m-wanboot.patch,
> openssl-1.0.1m-t4-engine.sparc.5.11.patch,
> openssl-1.0.1e-t4-engine-sparcv9+vis.sparc.5.11.patch.
>
> I will try to answer questions from whoever can work on this.
>
>
> I just had a discussion with Laurent about the rebuild: are there any
> special precautions to be
> taken or can it just be built by ?mgar spotless && mgar platforms??
>
>
> Best regards
>
>   ? Dago
>
>
> Yann
>
>
> 2015-04-20 15:22 GMT+02:00 Dagobert Michelsen <dam at opencsw.org>:
>
>> Hi folks,
>>
>> I want to raise the issue about OpenSSL 1.0.1m again. On Sparc we have now
>> two serious issues:
>>
>> - BIND fails with crypto failure
>>   https://www.opencsw.org/mantis/view.php?id=5237
>> - Solaris 9 applications have issues with hangs in unrelated code. This
>> has been seen
>>   at least in GIT and Python
>>
>> How do we proceed here? While I do notice that it would be good to
>> provide a working 1.0.1m
>> the status quo is that bad that I would suggest rolling back to 1.0.1l at
>> least on Sparc
>> if the issue can not be resolved in a reasonable timeframe.
>>
>>
>> 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
>>
>>
>
> --
> "You don't become great by trying to be great, you become great by wanting
> to do something,
> and then doing it so hard that you become great in the process." - xkcd
> #896
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150420/2a598c76/attachment.html>

From rmottola at opencsw.org  Tue Apr 21 08:54:46 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 21 Apr 2015 08:54:46 +0200
Subject: gs_terminal: error on sol11 upload
Message-ID: <5535F436.2050401@opencsw.org>

Hi,

I built gs_terminal (new name) and it pkg check is now fine.

While uploading, I get an error on solaris 11:

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

Where is the problem? Aren't all the errors properly overridden?

Riccardo

From rmottola at opencsw.org  Tue Apr 21 09:19:01 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 21 Apr 2015 09:19:01 +0200
Subject: libpng update 16
In-Reply-To: <0392DEE7-E16E-4EAB-86AF-D8E17E696336@opencsw.org>
References: <55336FE2.6030108@opencsw.org>	<CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>	<5533EE21.4020205@opencsw.org>	<CALtRa-7y8baEjiHL2pnkx0M0uORy-mKuLXkYi6vf1-+sWcs1mw@mail.gmail.com>	<5534B83C.8000509@opencsw.org>
	<0392DEE7-E16E-4EAB-86AF-D8E17E696336@opencsw.org>
Message-ID: <5535F9E5.1050808@opencsw.org>

Hi,


Dagobert Michelsen wrote:
>
>
> I suggest CSWlibpng-util.

Agreed! It is fine to make this an optional package and I did not 
version it, I think this is best.

I just added:
PKGFILES_CSWlibpng-utils += $(bindir)/pngfix
PKGFILES_CSWlibpng-utils += $(bindir)/png-fix-itxt


Somehow now the "-dev" pkg is not generated anymore:
http://buildfarm.opencsw.org/pkgdb/srv4/

There are no files list for -dev, I suppose it works as a "catch all" 
for all files not included in other packages? Why doesn't that work 
anymore ?

libpng itself is specified by:
PKGFILES_CSWlibpng16-16+= $(call 
baseisadirs,$(libdir),libpng16\.so\.16(\.\d+)*)

I get however a mysterious package called "png_stub", I suppose this is 
the obsoletion that I have disabled as Dago suggested.

Riccardo


Riccardo

From dam at opencsw.org  Tue Apr 21 09:31:34 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 21 Apr 2015 09:31:34 +0200
Subject: gs_terminal: error on sol11 upload
In-Reply-To: <5535F436.2050401@opencsw.org>
References: <5535F436.2050401@opencsw.org>
Message-ID: <44879726-6399-4BE2-BCDE-A09648D7B5E8@opencsw.org>

Hi Riccardo,

> Am 21.04.2015 um 08:54 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> I built gs_terminal (new name) and it pkg check is now fine.
> 
> While uploading, I get an error on solaris 11:
> 
> http://buildfarm.opencsw.org/pkgdb/srv4/f47caf0dc670ddd53fc49ddbd1b4067a/
> 
> Where is the problem? Aren't all the errors properly overridden?

The pkgdb data looks fine. What errors are listed on Solaris 11 upload?


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/20150421/125f2f24/attachment.p7s>

From dam at opencsw.org  Tue Apr 21 09:39:46 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 21 Apr 2015 09:39:46 +0200
Subject: libpng update 16
In-Reply-To: <5535F9E5.1050808@opencsw.org>
References: <55336FE2.6030108@opencsw.org>
	<CALtRa-6omDUAX3kD4J5Lq5T2W1KKDkuDditT1BPmpCypjaPCZQ@mail.gmail.com>
	<5533EE21.4020205@opencsw.org>
	<CALtRa-7y8baEjiHL2pnkx0M0uORy-mKuLXkYi6vf1-+sWcs1mw@mail.gmail.com>
	<5534B83C.8000509@opencsw.org>
	<0392DEE7-E16E-4EAB-86AF-D8E17E696336@opencsw.org>
	<5535F9E5.1050808@opencsw.org>
Message-ID: <DCE4273F-4955-4B3A-8393-894B7FA464CE@opencsw.org>

Hi Riccardo,

> Am 21.04.2015 um 09:19 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> 
>> I suggest CSWlibpng-util.
> 
> Agreed! It is fine to make this an optional package and I did not version it, I think this is best.
> 
> I just added:
> PKGFILES_CSWlibpng-utils += $(bindir)/pngfix
> PKGFILES_CSWlibpng-utils += $(bindir)/png-fix-itxt
> 
> Somehow now the "-dev" pkg is not generated anymore:
> http://buildfarm.opencsw.org/pkgdb/srv4/
> 
> There are no files list for -dev, I suppose it works as a "catch all" for all files not included in other packages? Why doesn't that work anymore ?

Pssssttt?. +=

Suggestion: *Always* use += on variables that can carry multiple values.
That way mistakes like the above or line-reorderings are much easier.

> libpng itself is specified by:
> PKGFILES_CSWlibpng16-16+= $(call baseisadirs,$(libdir),libpng16\.so\.16(\.\d+)*)
> 
> I get however a mysterious package called "png_stub", I suppose this is the obsoletion that I have disabled as Dago suggested.

Yes.


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/20150421/0c8afcb8/attachment-0001.p7s>

From Joerg.Schilling at fokus.fraunhofer.de  Tue Apr 21 11:29:13 2015
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Tue, 21 Apr 2015 11:29:13 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <x64moa7lp3.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	<x64moa7lp3.fsf@opencsw.org>
Message-ID: <55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>

Peter FELECAN <pfelecan at opencsw.org> wrote:

> > It is not trivial if you like to create secure code that fits into a single 
> > page.
> >
> > BTW: I created na isaexec implementation based on the Sun implementation.
> > This was reworked not to depend on a libc function (as recent OpenSolaris 
> > sources) and it still fits into a single page.
>
> Wouldn't be nice that you include your implementation in our isaexec
> package?

Yesterday in the afternoon, I send my source to Dagobert. The next schilytools 
source tarball will include the current state of the source from 2010. I did 
not yet publish it as I originally planned to include BSD, Linux amd Mac OS X 
support first.

J?rg

-- 
 EMail:joerg at schily.net                    (home) J?rg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

From rmottola at opencsw.org  Tue Apr 21 16:44:15 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 21 Apr 2015 16:44:15 +0200
Subject: libpng update 16
In-Reply-To: <0EC8102F-BF9B-4D4D-95E6-1137C13C6F4C@opencsw.org>
References: <55336FE2.6030108@opencsw.org>
	<0EC8102F-BF9B-4D4D-95E6-1137C13C6F4C@opencsw.org>
Message-ID: <5536623F.2080803@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> This is tricky. You must not change CSWpng. That is a legacy package that needs to pull in
> the libs in the comment because legacy packages may rely on these. I suggest you
> completely remove the obsoletion.
>
>
> Best regards
Jolly good! All checks passed, no error tags reported.

build for 4 architectures completed! took hell of a long time :)

All uploaded fine!

I hope they will be fine for you all! 1.6.16 had important security issues.

I see they released .17 in the meanwhile (took me weeks for this png 
upgrade), but it is a minor upgrade and it should be smoother to 
upgrade, let us see first if it works fine.

Riccardo

From pfelecan at opencsw.org  Tue Apr 21 19:01:31 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 21 Apr 2015 19:01:31 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>
	(Joerg Schilling's message of "Tue, 21 Apr 2015 11:29:13 +0200")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	<x64moa7lp3.fsf@opencsw.org>
	<55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <x6zj615sb8.fsf@opencsw.org>

Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> writes:

> Peter FELECAN <pfelecan at opencsw.org> wrote:
>
>> > It is not trivial if you like to create secure code that fits into a single 
>> > page.
>> >
>> > BTW: I created na isaexec implementation based on the Sun implementation.
>> > This was reworked not to depend on a libc function (as recent OpenSolaris 
>> > sources) and it still fits into a single page.
>>
>> Wouldn't be nice that you include your implementation in our isaexec
>> package?
>
> Yesterday in the afternoon, I send my source to Dagobert. The next schilytools 
> source tarball will include the current state of the source from 2010. I did 
> not yet publish it as I originally planned to include BSD, Linux amd Mac OS X 
> support first.

Thank you.

Dago, can you update our sources with what Joerg sent you?
TIA
-- 
Peter

From rmottola at opencsw.org  Tue Apr 21 20:03:58 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 21 Apr 2015 20:03:58 +0200
Subject: gs_terminal: error on sol11 upload
In-Reply-To: <44879726-6399-4BE2-BCDE-A09648D7B5E8@opencsw.org>
References: <5535F436.2050401@opencsw.org>
	<44879726-6399-4BE2-BCDE-A09648D7B5E8@opencsw.org>
Message-ID: <5536910E.6080906@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> The pkgdb data looks fine. What errors are listed on Solaris 11 upload?

I just retried.


This is my console output:
Checking 1 package against catalog unstable i386 SunOS5.10
Checking 1 package against catalog unstable sparc SunOS5.10
Checking 1 package against catalog unstable i386 SunOS5.11
Checking 1 package against catalog unstable sparc SunOS5.11
Checks failed for the following catalogs:
   - i386 SunOS5.10
     gs_terminal-0.9.8,REV=2015.04.21-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 5669095268ebb681b28b716f9359adf8
Or check on the buildfarm:
http://buildfarm.opencsw.org/pkgdb/srv4/f47caf0dc670ddd53fc49ddbd1b4067a/
   - i386 SunOS5.11
     gs_terminal-0.9.8,REV=2015.04.21-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 5669095268ebb681b28b716f9359adf8
Or check on the buildfarm:
http://buildfarm.opencsw.org/pkgdb/srv4/f47caf0dc670ddd53fc49ddbd1b4067a/
Your packages have not been submitted to the unstable catalog.

Checking the catalog from console fails (login box):
<y --catalog-release unstable --os-release SunOS5.11 
--catalog-architecture i386 5669095268ebb681b28b716f9359adf8 Traceback 
(most recent call last):
   File 
"/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", 
line 16, in <module>
     from lib.python import checkpkg_lib
ImportError: No module named lib.python


Checking the supplied link (wow, this is my fix!)
http://buildfarm.opencsw.org/pkgdb/srv4/f47caf0dc670ddd53fc49ddbd1b4067a/

shows about the same thin I already showed.

Riccardo

From laurent at opencsw.org  Tue Apr 21 21:27:33 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Tue, 21 Apr 2015 21:27:33 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <CAF2fwsfWgxPvoYk+APJke6p+1n5F6hfbRa5E-+PzJceEP0hUMA@mail.gmail.com>
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>
Message-ID: <5536A4A5.9030803@opencsw.org>

Don't feel alone:

https://mta.openssl.org/pipermail/openssl-users/2015-April/001080.html

Though I don't see a relationship.

Dagobert: I put together a build of the package using GCC, if you want 
to give it a try.

http://buildfarm.opencsw.org/experimental.html#laurent

Laurent

Le 2015/04/20 22:24 +0200, Yann Rouillard a ?crit:
> No special precaution I think.
> You can speed the rebuild by using mgar platforms-fast or mgar
> package-fast but that is not required.
>
> Yann
>
> 2015-04-20 22:11 GMT+02:00 Dagobert Michelsen <dam at opencsw.org
> <mailto:dam at opencsw.org>>:
>
>     Hi Yann,
>
>>     Am 20.04.2015 um 22:09 schrieb Yann Rouillard
>>     <yann at pleiades.fr.eu.org <mailto:yann at pleiades.fr.eu.org>>:
>>
>>     Hi everybody,
>>
>>     I still don't have enough time work on it but my advice would be
>>     to first try to recompile the openssl sparc package with all
>>     upstream Oracle patches disabled to ensure that check if it is an
>>     openssl upstream problem or not.
>>
>>     Patches to disabled are: openssl-1.0.1m-fork_safe.patch,
>>     openssl-1.0.1m-pkcs11-engine.patch, openssl-1.0.1m-wanboot.patch,
>>     openssl-1.0.1m-t4-engine.sparc.5.11.patch,
>>     openssl-1.0.1e-t4-engine-sparcv9+vis.sparc.5.11.patch.
>>
>>     I will try to answer questions from whoever can work on this.
>
>     I just had a discussion with Laurent about the rebuild: are there
>     any special precautions to be
>     taken or can it just be built by ?mgar spotless && mgar platforms??
>
>
>     Best regards
>
>        ? Dago
>
>>
>>     Yann
>>
>>
>>     2015-04-20 15:22 GMT+02:00 Dagobert Michelsen <dam at opencsw.org
>>     <mailto:dam at opencsw.org>>:
>>
>>         Hi folks,
>>
>>         I want to raise the issue about OpenSSL 1.0.1m again. On Sparc
>>         we have now
>>         two serious issues:
>>
>>         - BIND fails with crypto failure
>>         https://www.opencsw.org/mantis/view.php?id=5237
>>         - Solaris 9 applications have issues with hangs in unrelated
>>         code. This has been seen
>>           at least in GIT and Python
>>
>>         How do we proceed here? While I do notice that it would be
>>         good to provide a working 1.0.1m
>>         the status quo is that bad that I would suggest rolling back
>>         to 1.0.1l at least on Sparc
>>         if the issue can not be resolved in a reasonable timeframe.
>>
>>
>>         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
>>
>>
>
>     --
>     "You don't become great by trying to be great, you become great by
>     wanting to do something,
>     and then doing it so hard that you become great in the process." -
>     xkcd #896
>
>




From dam at opencsw.org  Wed Apr 22 09:23:39 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 22 Apr 2015 09:23:39 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <x6zj615sb8.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	<x64moa7lp3.fsf@opencsw.org>
	<55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>
	<x6zj615sb8.fsf@opencsw.org>
Message-ID: <09BF82EB-14AA-4296-880B-AA2FEDD9D231@opencsw.org>

Hi Peter,

Am 21.04.2015 um 19:01 schrieb Peter FELECAN <pfelecan at opencsw.org>:
> Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> writes:
>> Peter FELECAN <pfelecan at opencsw.org> wrote:
>>>> It is not trivial if you like to create secure code that fits into a single 
>>>> page.
>>>> 
>>>> BTW: I created na isaexec implementation based on the Sun implementation.
>>>> This was reworked not to depend on a libc function (as recent OpenSolaris 
>>>> sources) and it still fits into a single page.
>>> 
>>> Wouldn't be nice that you include your implementation in our isaexec
>>> package?
>> 
>> Yesterday in the afternoon, I send my source to Dagobert. The next schilytools 
>> source tarball will include the current state of the source from 2010. I did 
>> not yet publish it as I originally planned to include BSD, Linux amd Mac OS X 
>> support first.
> 
> Thank you.
> 
> Dago, can you update our sources with what Joerg sent you?

Essentially yes, but I am want to make a step back: the initial problem was that
isaexec could not be found during checkinstall and we are now working on a CSW-specific
implementation. This seems wrong to me. Can?t we trick checkpkg in thinking isaexec is
provided and stick with the current implementation? Like, make isaexec a symlink first
and then replace it with a copy of system isaexec followed by installf?


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/20150422/7fab6849/attachment-0001.p7s>

From dam at opencsw.org  Wed Apr 22 09:27:07 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 22 Apr 2015 09:27:07 +0200
Subject: gs_terminal: error on sol11 upload
In-Reply-To: <5536910E.6080906@opencsw.org>
References: <5535F436.2050401@opencsw.org>
	<44879726-6399-4BE2-BCDE-A09648D7B5E8@opencsw.org>
	<5536910E.6080906@opencsw.org>
Message-ID: <469C164E-C046-450C-AC5E-D411F83B01C3@opencsw.org>

Hi Riccardo,

Am 21.04.2015 um 20:03 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> The pkgdb data looks fine. What errors are listed on Solaris 11 upload?
> 
> I just retried.
> 
> This is my console output:
> Checking 1 package against catalog unstable i386 SunOS5.10
> Checking 1 package against catalog unstable sparc SunOS5.10
> Checking 1 package against catalog unstable i386 SunOS5.11
> Checking 1 package against catalog unstable sparc SunOS5.11
> Checks failed for the following catalogs:
>  - i386 SunOS5.10
>    gs_terminal-0.9.8,REV=2015.04.21-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 5669095268ebb681b28b716f9359adf8
> Or check on the buildfarm:
> http://buildfarm.opencsw.org/pkgdb/srv4/f47caf0dc670ddd53fc49ddbd1b4067a/
>  - i386 SunOS5.11
>    gs_terminal-0.9.8,REV=2015.04.21-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 5669095268ebb681b28b716f9359adf8
> Or check on the buildfarm:
> http://buildfarm.opencsw.org/pkgdb/srv4/f47caf0dc670ddd53fc49ddbd1b4067a/
> Your packages have not been submitted to the unstable catalog.
> 
> Checking the catalog from console fails (login box):
> <y --catalog-release unstable --os-release SunOS5.11 --catalog-architecture i386 5669095268ebb681b28b716f9359adf8 Traceback (most recent call last):
>  File "/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", line 16, in <module>
>    from lib.python import checkpkg_lib
> ImportError: No module named lib.python

You need to set
  export PYTHON_PATH=/home/rmottola/opencsw/.buildsys/v2

Also please also show the actual csw-upload-pkg so I can retry that on my own.


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/20150422/deb431e8/attachment.p7s>

From dam at opencsw.org  Wed Apr 22 09:30:40 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 22 Apr 2015 09:30:40 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <5536A4A5.9030803@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>
Message-ID: <939EA461-3214-4952-A5AE-7EEAEBE8D9AD@opencsw.org>

Hi Laurent,

> Am 21.04.2015 um 21:27 schrieb Laurent Blume <laurent at opencsw.org>:
> 
> Don't feel alone:
> 
> https://mta.openssl.org/pipermail/openssl-users/2015-April/001080.html
> 
> Though I don't see a relationship.
> 
> Dagobert: I put together a build of the package using GCC, if you want to give it a try.
> 
> http://buildfarm.opencsw.org/experimental.html#laurent

I installed it on ?web? and BIND now works. Looks good to me. Would you mind respinning the rest?


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/20150422/bff4d74d/attachment.p7s>

From laurent at opencsw.org  Wed Apr 22 10:07:49 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Wed, 22 Apr 2015 10:07:49 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <939EA461-3214-4952-A5AE-7EEAEBE8D9AD@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>
Message-ID: <553756D5.5080900@opencsw.org>

Le 2015/04/22 09:30 +0200, Dagobert Michelsen a ?crit:
> I installed it on ?web? and BIND now works. Looks good to me. Would you mind respinning the rest?


Sure.
Do note that I replaced the sparcv8plus+vis target by simple
sparcv8plus. The former implies adding a patch unsupported by upstream,
potentially adding issues we obviously don't have resources to deal
with. I'll stick with vanilla OpenSSL.

Laurent

From grzemba at contac-dt.de  Wed Apr 22 14:34:19 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Wed, 22 Apr 2015 14:34:19 +0200
Subject: apache24 prefork only
In-Reply-To: <bbb1db436d30.5537952e@contac-dt.de>
References: <bbb1a8bafe3.553794b5@contac-dt.de>
	<bbb18a7a2ab6.553794f2@contac-dt.de>
	<bbb1db436d30.5537952e@contac-dt.de>
Message-ID: <bbb1a91577.5537b16b@contac-dt.de>

Hi Dago,

I think we should remove the 
--with-mpm=prefork 
configure option in apache24 because it prevents the build the shared mpm modules and builds only a static linked prefork server

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

From dam at opencsw.org  Wed Apr 22 14:46:34 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 22 Apr 2015 14:46:34 +0200
Subject: apache24 prefork only
In-Reply-To: <bbb1a91577.5537b16b@contac-dt.de>
References: <bbb1a8bafe3.553794b5@contac-dt.de>
	<bbb18a7a2ab6.553794f2@contac-dt.de>
	<bbb1db436d30.5537952e@contac-dt.de>
	<bbb1a91577.5537b16b@contac-dt.de>
Message-ID: <E0BA302F-E588-40CF-A4C3-470510A25FAB@opencsw.org>

Hi Carsten,

Am 22.04.2015 um 14:34 schrieb Carsten Grzemba <grzemba at contac-dt.de>:
> Hi Dago,
> 
> I think we should remove the 
> --with-mpm=prefork 
> configure option in apache24 because it prevents the build the shared mpm modules and builds only a static linked prefork server

Sure, feel free to enhance the package.


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/20150422/6ce58317/attachment-0001.p7s>

From pfelecan at opencsw.org  Wed Apr 22 18:44:22 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Wed, 22 Apr 2015 18:44:22 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <09BF82EB-14AA-4296-880B-AA2FEDD9D231@opencsw.org> (Dagobert
	Michelsen's message of "Wed, 22 Apr 2015 09:23:39 +0200")
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	<x64moa7lp3.fsf@opencsw.org>
	<55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>
	<x6zj615sb8.fsf@opencsw.org>
	<09BF82EB-14AA-4296-880B-AA2FEDD9D231@opencsw.org>
Message-ID: <x6zj603yft.fsf@opencsw.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Peter,
>
> Am 21.04.2015 um 19:01 schrieb Peter FELECAN <pfelecan at opencsw.org>:
>> Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> writes:
>>> Peter FELECAN <pfelecan at opencsw.org> wrote:
>>>>> It is not trivial if you like to create secure code that fits into a single 
>>>>> page.
>>>>> 
>>>>> BTW: I created na isaexec implementation based on the Sun implementation.
>>>>> This was reworked not to depend on a libc function (as recent OpenSolaris 
>>>>> sources) and it still fits into a single page.
>>>> 
>>>> Wouldn't be nice that you include your implementation in our isaexec
>>>> package?
>>> 
>>> Yesterday in the afternoon, I send my source to Dagobert. The next schilytools 
>>> source tarball will include the current state of the source from 2010. I did 
>>> not yet publish it as I originally planned to include BSD, Linux amd Mac OS X 
>>> support first.
>> 
>> Thank you.
>> 
>> Dago, can you update our sources with what Joerg sent you?
>
> Essentially yes, but I am want to make a step back: the initial problem was that
> isaexec could not be found during checkinstall and we are now working on a CSW-specific
> implementation. This seems wrong to me. Can?t we trick checkpkg in thinking isaexec is
> provided and stick with the current implementation? Like, make isaexec a symlink first
> and then replace it with a copy of system isaexec followed by installf?

1. the implementation that we have is minimalist, having a more complete
   one is not a luxury;
2. take advantage of the required chnage to increase the quality of the
   package's content;
3. I don't get what you wish to do; what "system isaexec"? I don't see
   one on my Solaris 10.

If you don't have the time do do it, send me the source and I'll do it.
-- 
Peter

From laurent at opencsw.org  Wed Apr 22 21:47:34 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Wed, 22 Apr 2015 21:47:34 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <553756D5.5080900@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>
Message-ID: <5537FAD6.30703@opencsw.org>

Done, same place:

http://buildfarm.opencsw.org/experimental.html#laurent

The Solaris 9 GCC target doesn't appear too well maintained either. 
Unsurprisingly.

Laurent

From rmottola at opencsw.org  Thu Apr 23 08:50:09 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 23 Apr 2015 08:50:09 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>	<5534AC1F.80806@opencsw.org>	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>	<5534F47F.2050008@opencsw.org>
	<2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>
Message-ID: <55389621.4020902@opencsw.org>

Hi Dago,

Dagobert Michelsen wrote:
> That depends. For gnulinks the packages are completely different so I would
> just make a copy of trunk to branches/solaris9. For other packages which share
> almost all of the code you may add the PACKAGING_PLATFORMS and use conditional
> assignments. If in doubt, branch for Solaris 9 as the changes are usually not
> needed in Solaris 10 and essentially the focus is going forward to 11.

I see. I disabled solaris 9 from the trunk package again.

Could you explain like to a newbie "copy of trunk to branches/solaris9"

1) is solaris9 the "official" name we use?
2) by copy do you mean "cd pencsw/binutils" and there just "cp trunk 
branches/solaris9" ?
3) how do I work on this branch when I'm on solaris9 machines?

I understand the above procedure is some sort of svn shortcut and 
creates a branch for each package. I thought we had some kind of "tree" 
setup.

Thank you, I do not want to make errors.

Riccardo

From rmottola at opencsw.org  Thu Apr 23 09:02:44 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 23 Apr 2015 09:02:44 +0200
Subject: gs_terminal: error on sol11 upload
In-Reply-To: <469C164E-C046-450C-AC5E-D411F83B01C3@opencsw.org>
References: <5535F436.2050401@opencsw.org>	<44879726-6399-4BE2-BCDE-A09648D7B5E8@opencsw.org>	<5536910E.6080906@opencsw.org>
	<469C164E-C046-450C-AC5E-D411F83B01C3@opencsw.org>
Message-ID: <55389914.2050107@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> You need to set
>    export PYTHON_PATH=/home/rmottola/opencsw/.buildsys/v2

since I kept forgetting, I added it to my .bash_profile !

However, I still get:
rmottola at login [login]:~/pkgs > 
/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py 
--catalog-release unstable --os-release SunOS5.11 --catalog-architecture 
i386 5669095268ebb681b28b716f9359adf8
Traceback (most recent call last):
   File 
"/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", 
line 16, in <module>
     from lib.python import checkpkg_lib
ImportError: No module named lib.python

>
> Also please also show the actual csw-upload-pkg so I can retry that on my own.

the upload command is simply:

csw-upload-pkg gs_terminal-0.9.8\,REV\=2015.04.21-SunOS5.10-*

from inside my pkg  directory on the login host. I am supposed to upload 
from the login host, right? That's where the upload utility is.


Riccardo

From dam at opencsw.org  Fri Apr 24 11:29:05 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 24 Apr 2015 11:29:05 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <x6zj603yft.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	<x64moa7lp3.fsf@opencsw.org>
	<55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>
	<x6zj615sb8.fsf@opencsw.org>
	<09BF82EB-14AA-4296-880B-AA2FEDD9D231@opencsw.org>
	<x6zj603yft.fsf@opencsw.org>
Message-ID: <96A133C7-DB8E-4F62-9336-A9432C0065AE@opencsw.org>

Hi Peter,

Am 22.04.2015 um 18:44 schrieb Peter FELECAN <pfelecan at opencsw.org>:
> Dagobert Michelsen <dam at opencsw.org> writes:
>> Hi Peter,
>> Am 21.04.2015 um 19:01 schrieb Peter FELECAN <pfelecan at opencsw.org>:
>>> Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> writes:
>>>> Peter FELECAN <pfelecan at opencsw.org> wrote:
>>>>>> It is not trivial if you like to create secure code that fits into a single 
>>>>>> page.
>>>>>> 
>>>>>> BTW: I created na isaexec implementation based on the Sun implementation.
>>>>>> This was reworked not to depend on a libc function (as recent OpenSolaris 
>>>>>> sources) and it still fits into a single page.
>>>>> 
>>>>> Wouldn't be nice that you include your implementation in our isaexec
>>>>> package?
>>>> 
>>>> Yesterday in the afternoon, I send my source to Dagobert. The next schilytools 
>>>> source tarball will include the current state of the source from 2010. I did 
>>>> not yet publish it as I originally planned to include BSD, Linux amd Mac OS X 
>>>> support first.
>>> 
>>> Thank you.
>>> 
>>> Dago, can you update our sources with what Joerg sent you?
>> 
>> Essentially yes, but I am want to make a step back: the initial problem was that
>> isaexec could not be found during checkinstall and we are now working on a CSW-specific
>> implementation. This seems wrong to me. Can?t we trick checkpkg in thinking isaexec is
>> provided and stick with the current implementation? Like, make isaexec a symlink first
>> and then replace it with a copy of system isaexec followed by installf?
> 
> 1. the implementation that we have is minimalist, having a more complete
>   one is not a luxury;

Not really. Our implementation uses the isaexec shipped with Solaris and that
implementation has no known issues.

> 2. take advantage of the required chnage to increase the quality of the
>   package's content;

I don?t see a problem with the contents, just that checkpkg does not know the
path because it is done in postinstall with installf.

> 3. I don't get what you wish to do; what "system isaexec"? I don't see
>   one on my Solaris 10.

/usr/lib/isaexec


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/20150424/cbdab1a3/attachment.p7s>

From dam at opencsw.org  Fri Apr 24 12:04:27 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 24 Apr 2015 12:04:27 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <55389621.4020902@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>
	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
	<5534AC1F.80806@opencsw.org>
	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>
	<5534F47F.2050008@opencsw.org>
	<2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>
	<55389621.4020902@opencsw.org>
Message-ID: <93934E04-F505-467F-AAC4-A3DCB137EE02@opencsw.org>

Hi Riccardo,

> Am 23.04.2015 um 08:50 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi Dago,
> 
> Dagobert Michelsen wrote:
>> That depends. For gnulinks the packages are completely different so I would
>> just make a copy of trunk to branches/solaris9. For other packages which share
>> almost all of the code you may add the PACKAGING_PLATFORMS and use conditional
>> assignments. If in doubt, branch for Solaris 9 as the changes are usually not
>> needed in Solaris 10 and essentially the focus is going forward to 11.
> 
> I see. I disabled solaris 9 from the trunk package again.

I just looked: you can just leave trunk alone as Solaris 10 unstable does not ship
gnulinks any more.

> Could you explain like to a newbie "copy of trunk to branches/solaris9"
> 
> 1) is solaris9 the "official" name we use?

Well, there is no official naming for branches. Just name it with a sensible name,
?solaris9? looks fine for me.

> 2) by copy do you mean "cd pencsw/binutils" and there just "cp trunk branches/solaris9? ?

Please always use ?svn? commands to keep the history, e.g.
  svn cp trunk branches/solaris9

> 3) how do I work on this branch when I'm on solaris9 machines?

Just ?cd gnulinks/branches/solaris9? and work as you would have been in trunk/

> I understand the above procedure is some sort of svn shortcut and creates a branch for each package. I thought we had some kind of "tree" setup.

The tree is more like a convention, not a strict specification. We don?t have
a strict setup for Solaris-version-specific packages.


Best regards

  ? Dago

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

-------------- 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/20150424/67428a34/attachment-0001.p7s>

From dam at opencsw.org  Fri Apr 24 12:11:08 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 24 Apr 2015 12:11:08 +0200
Subject: OpenSSL 1.0.1m considered harmful on Sparc
In-Reply-To: <5537FAD6.30703@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>
Message-ID: <B9B9AE2F-B8CF-41FB-AED9-AC180ECCE7D1@opencsw.org>

Hi Laurent,

> Am 22.04.2015 um 21:47 schrieb Laurent Blume <laurent at opencsw.org>:
> 
> Done, same place:
> 
> http://buildfarm.opencsw.org/experimental.html#laurent
> 
> The Solaris 9 GCC target doesn't appear too well maintained either. Unsurprisingly.

I just tried this package:

unstable9s# pkginfo -l CSWlibssl1-0-0
   PKGINST:  CSWlibssl1-0-0
      NAME:  libssl1_0_0 - Openssl 1.0 runtime libraries
  CATEGORY:  application
      ARCH:  sparc
   VERSION:  1.0.1m,REV=2015.04.22
    VENDOR:  http://www.openssl.org/source/ packaged for CSW by Laurent Blume
    PSTAMP:  laurent at unstable9s-20150422212905
  INSTDATE:  Apr 24 2015 12:05
   HOTLINE:  http://www.opencsw.org/bugtrack/
     EMAIL:  laurent at opencsw.org
    STATUS:  completely installed
     FILES:       61 installed pathnames
                   7 directories
                  42 executables
               14902 blocks used (approx)

Hangs on Solaris 9 in the same way as the package from Yann. So this is really an upstream
issue?


Best regards

  ? Dago

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

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

From Joerg.Schilling at fokus.fraunhofer.de  Fri Apr 24 12:52:11 2015
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Fri, 24 Apr 2015 12:52:11 +0200
Subject: incorrect warning during check and upload
In-Reply-To: <x6zj603yft.fsf@opencsw.org>
References: <x6y4lp78u3.fsf@opencsw.org>
	<CALtRa-5dzUhkHS9_8_yTYmQShun12AGWFX7WzF2XPZ+NS__O3w@mail.gmail.com>
	<x6twwd6uk2.fsf@opencsw.org>
	<CALtRa-6S_gVSKQt_jrE_WUcQRX5LdD-qqT8qEJk2vc0cChi9rg@mail.gmail.com>
	<x6pp707eqf.fsf@opencsw.org>
	<CALtRa-65bS=CYWLjeecXFd45mFWuALKacOCDVoWxKTj=hcA2SQ@mail.gmail.com>
	<x6h9sc6u95.fsf@opencsw.org>
	<CALtRa-6FaWLD+=ywyKuissNMLL9vT+iqN2BCWoK7J0eDNEDTHg@mail.gmail.com>
	<x6d2306nvl.fsf@opencsw.org>
	<5534e549.t89lspNW6hLAkfW5%Joerg.Schilling@fokus.fraunhofer.de>
	<x64moa7lp3.fsf@opencsw.org>
	<55361869.GmAeD51rp6ETAX0U%Joerg.Schilling@fokus.fraunhofer.de>
	<x6zj615sb8.fsf@opencsw.org>
	<09BF82EB-14AA-4296-880B-AA2FEDD9D231@opencsw.org>
	<x6zj603yft.fsf@opencsw.org>
Message-ID: <553a205b.H87Pf7PH6v1ynJkI%Joerg.Schilling@fokus.fraunhofer.de>

Peter FELECAN <pfelecan at opencsw.org> wrote:

> 1. the implementation that we have is minimalist, having a more complete
>    one is not a luxury;
> 2. take advantage of the required chnage to increase the quality of the
>    package's content;
> 3. I don't get what you wish to do; what "system isaexec"? I don't see
>    one on my Solaris 10.
>
> If you don't have the time do do it, send me the source and I'll do it.

I just published my portable isaexec implementation in schilytools at:

	https://sourceforge.net/projects/schilytools/files/

It is published "as is" in the latest state from 2010. It could also work on 
FreeBSD, Mac OS X and Linux but it does not yet. You need to chdir "isaexec"
and to call smake to compile it.

J?rg

-- 
 EMail:joerg at schily.net                    (home) J?rg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

From rmottola at opencsw.org  Sun Apr 26 10:21:33 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 26 Apr 2015 10:21:33 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <93934E04-F505-467F-AAC4-A3DCB137EE02@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>	<5534AC1F.80806@opencsw.org>	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>	<5534F47F.2050008@opencsw.org>	<2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>	<55389621.4020902@opencsw.org>
	<93934E04-F505-467F-AAC4-A3DCB137EE02@opencsw.org>
Message-ID: <553CA00D.4030609@opencsw.org>

Hi,

Dagobert Michelsen wrote:
>
> I just looked: you can just leave trunk alone as Solaris 10 unstable does not ship
> gnulinks any more.

I see, perhaps we shouldn't need it on solaris 9 either? I'm checking:

#GLINKPKGS =  CSWbinutils CSWggetopt CSWgwhois

further down:
                 for p in $(GLINKPKGS); do \

this means this package shouldn't contain anything right now: no GLINKPKGS.

The package contains:

1 s none /opt/csw/gnu/addr2line=../bin/gaddr2line
1 s none /opt/csw/gnu/ar=../bin/gar
1 s none /opt/csw/gnu/as=../bin/gas
1 s none /opt/csw/gnu/c++filt=../bin/gc++filt
1 s none /opt/csw/gnu/getopt=../bin/ggetopt
1 s none /opt/csw/gnu/gprof=../bin/ggprof
1 s none /opt/csw/gnu/ld=../bin/gld
1 s none /opt/csw/gnu/nm=../bin/gnm
1 s none /opt/csw/gnu/objcopy=../bin/gobjcopy
1 s none /opt/csw/gnu/objdump=../bin/gobjdump
1 s none /opt/csw/gnu/ranlib=../bin/granlib
1 s none /opt/csw/gnu/readelf=../bin/greadelf
1 s none /opt/csw/gnu/size=../bin/gsize
1 s none /opt/csw/gnu/strings=../bin/gstrings
1 s none /opt/csw/gnu/strip=../bin/gstrip
1 s none /opt/csw/gnu/whois=../bin/gwhois


I would say that if I update binutils getopt and whois for solaris 9, we 
can throw away this package on Solaris 9 too, do you agree?

>> Could you explain like to a newbie "copy of trunk to branches/solaris9"
>>
>> 1) is solaris9 the "official" name we use?
> Well, there is no official naming for branches. Just name it with a sensible name,
> ?solaris9? looks fine for me.

I will keep this "lesson" in mind when I need to e.g. branch gcc to 
4.8/4.9 "forever" on Solaris 9.
I suppose this is what I also will need when branching for solaris 8 
eventually.


Riccardo

From rmottola at opencsw.org  Sun Apr 26 17:07:06 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 26 Apr 2015 17:07:06 +0200
Subject: package problem, unreachable host 192.168.1.6
Message-ID: <553CFF1A.8010401@opencsw.org>

Hi,

while I wait for confirmation that issuing new versions of binutils, 
getopt and whois for solaris 9 is the way to get rid of gnulinks, I 
attempted a build of getopt.

I tried twice and I get this error:

INFO 2015-04-26 16:29:35,017 package_stats.py:132 Juicing the svr4 
package stream files...
CRITICAL 2015-04-26 16:30:30,768 shell.py:55 |
CRITICAL 2015-04-26 16:30:30,770 shell.py:56 INFO 2015-04-26 
16:29:40,560 retry_decorator.py:35 Retry, exception: (7, 'Failed to 
connect to 192.168.1.6: Connection refused')
INFO 2015-04-26 16:29:50,565 retry_decorator.py:35 Retry, exception: (7, 
'Failed to connect to 192.168.1.6: Connection refused')
INFO 2015-04-26 16:30:00,570 retry_decorator.py:35 Retry, exception: (7, 
'Failed to connect to 192.168.1.6: Connection refused')
INFO 2015-04-26 16:30:10,575 retry_decorator.py:35 Retry, exception: (7, 
'Failed to connect to 192.168.1.6: Connection refused')
INFO 2015-04-26 16:30:20,579 retry_decorator.py:35 Retry, exception: (7, 
'Failed to connect to 192.168.1.6: Connection refused')
Traceback (most recent call last):
   File 
"/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", 
line 623, in <module>
     unpacked = unpacker.CollectStats(force_unpack=options.force_unpack)
   File 
"/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", 
line 594, in CollectStats
     self.md5_sum):
   File 
"/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/retry_decorator.py", 
line 39, in fn
     raise last_exception
pycurl.error: (7, 'Failed to connect to 192.168.1.6: Connection refused')

Traceback (most recent call last):
   File 
"/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", 
line 268, in <module>
     main()
   File 
"/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", 
line 174, in main
     md5_sums_from_files = 
collector.CollectStatsFromCatalogEntries(entries, False)
   File 
"/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/package_stats.py", 
line 158, in CollectStatsFromCatalogEntries
     stderr=stderr_file)
   File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/shell.py", 
line 60, in ShellCommand
     % (args, retcode, ' '.join(pipes.quote(x) for x in args)))
lib.python.shell.ShellError: Running 
['/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py', 
'--input', 
'/home/rmottola/pkgs/ggetopt-1.1.5,REV=2015.04.26-SunOS5.9-sparc-UNCOMMITTED.pkg.gz'] 
has failed, error code: 1. To find out why the command failed, please 
run it in the foreground, like this: 
/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py 
--input 
/home/rmottola/pkgs/ggetopt-1.1.5,REV=2015.04.26-SunOS5.9-sparc-UNCOMMITTED.pkg.gz
gmake: *** [pkgcheck] Error 2


I don't know which host is 192.168.1.6 but it appears to have issues.

Riccardo

From dam at opencsw.org  Sun Apr 26 19:29:34 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 26 Apr 2015 19:29:34 +0200
Subject: package problem, unreachable host 192.168.1.6
In-Reply-To: <553CFF1A.8010401@opencsw.org>
References: <553CFF1A.8010401@opencsw.org>
Message-ID: <30024002-4FDC-4D4B-84ED-87FC704FB695@opencsw.org>

Hi Riccardo,

> Am 26.04.2015 um 17:07 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> while I wait for confirmation that issuing new versions of binutils, getopt and whois for solaris 9 is the way to get rid of gnulinks, I attempted a build of getopt.
> 
> I tried twice and I get this error:
> 
> INFO 2015-04-26 16:29:35,017 package_stats.py:132 Juicing the svr4 package stream files...
> CRITICAL 2015-04-26 16:30:30,768 shell.py:55 |
> CRITICAL 2015-04-26 16:30:30,770 shell.py:56 INFO 2015-04-26 16:29:40,560 retry_decorator.py:35 Retry, exception: (7, 'Failed to connect to 192.168.1.6: Connection refused')
> INFO 2015-04-26 16:29:50,565 retry_decorator.py:35 Retry, exception: (7, 'Failed to connect to 192.168.1.6: Connection refused')
> INFO 2015-04-26 16:30:00,570 retry_decorator.py:35 Retry, exception: (7, 'Failed to connect to 192.168.1.6: Connection refused')
> INFO 2015-04-26 16:30:10,575 retry_decorator.py:35 Retry, exception: (7, 'Failed to connect to 192.168.1.6: Connection refused')
> INFO 2015-04-26 16:30:20,579 retry_decorator.py:35 Retry, exception: (7, 'Failed to connect to 192.168.1.6: Connection refused')
> Traceback (most recent call last):
>  File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 623, in <module>
>    unpacked = unpacker.CollectStats(force_unpack=options.force_unpack)
>  File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 594, in CollectStats
>    self.md5_sum):
>  File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/retry_decorator.py", line 39, in fn
>    raise last_exception
> pycurl.error: (7, 'Failed to connect to 192.168.1.6: Connection refused')
> 
> Traceback (most recent call last):
>  File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 268, in <module>
>    main()
>  File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 174, in main
>    md5_sums_from_files = collector.CollectStatsFromCatalogEntries(entries, False)
>  File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/package_stats.py", line 158, in CollectStatsFromCatalogEntries
>    stderr=stderr_file)
>  File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/shell.py", line 60, in ShellCommand
>    % (args, retcode, ' '.join(pipes.quote(x) for x in args)))
> lib.python.shell.ShellError: Running ['/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py', '--input', '/home/rmottola/pkgs/ggetopt-1.1.5,REV=2015.04.26-SunOS5.9-sparc-UNCOMMITTED.pkg.gz'] has failed, error code: 1. To find out why the command failed, please run it in the foreground, like this: /home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py --input /home/rmottola/pkgs/ggetopt-1.1.5,REV=2015.04.26-SunOS5.9-sparc-UNCOMMITTED.pkg.gz
> gmake: *** [pkgcheck] Error 2
> 
> 
> I don't know which host is 192.168.1.6 but it appears to have issues.

That is the squid proxy on ?web?. It crashed once in a while, I?ll test a new
version when the updated package is ready. For now I restarted the service.


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/20150426/c16016af/attachment-0001.p7s>

From rmottola at opencsw.org  Sun Apr 26 22:17:49 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 26 Apr 2015 22:17:49 +0200
Subject: nonexistent dependency
Message-ID: <553D47ED.5060304@opencsw.org>

Hi,

I am rebuilding gwhois so that in theory I could remove gnulinks from 
solaris 9 too (I hope you can confirm this).

However, in gwhois I get these warnings:

CHECKPKG_OVERRIDES_CSWgwhois += pkginfo-opencsw-repository-uncommitted
CHECKPKG_OVERRIDES_CSWgwhois += 
dependency-on-nonexistent-package|CSWpm-net-libidn


I see the package here:
http://www.opencsw.org/packages/CSWpm-net-libidn

Is this packages not installed on unstable9s/unstable9x or is it missing 
totally there and it is a new dependency?

Riccardo

From dam at opencsw.org  Sun Apr 26 22:19:47 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 26 Apr 2015 22:19:47 +0200
Subject: nonexistent dependency
In-Reply-To: <553D47ED.5060304@opencsw.org>
References: <553D47ED.5060304@opencsw.org>
Message-ID: <8A065110-88CF-4AB2-AC89-BA0C35787147@opencsw.org>

Hi Riccardo,

Am 26.04.2015 um 22:17 schrieb Riccardo Mottola:
> I am rebuilding gwhois so that in theory I could remove gnulinks from solaris 9 too (I hope you can confirm this).
> 
> However, in gwhois I get these warnings:
> 
> CHECKPKG_OVERRIDES_CSWgwhois += pkginfo-opencsw-repository-uncommitted
> CHECKPKG_OVERRIDES_CSWgwhois += dependency-on-nonexistent-package|CSWpm-net-libidn
> 
> I see the package here:
> http://www.opencsw.org/packages/CSWpm-net-libidn

The view is Solaris 10 i386 only.

> Is this packages not installed on unstable9s/unstable9x or is it missing totally there and it is a new dependency?

It does not exist on Solaris 9:

dam at login [login]:/export/mirror/opencsw-official/unstable > ls -l */5.9/pm*idn*
-rw-rw-r--  11 web      web        11194 Jul 12  2010 i386/5.9/pm_idnapunycode-1.001,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
-rw-r--r--  11 web      web        17776 Mrz  8  2011 i386/5.9/pm_net_idn_encode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
-rw-r--r--  11 web      web         8199 Mrz  8  2011 i386/5.9/pm_netidnencode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
-rw-rw-r--  11 web      web        11061 Jul 12  2010 i386/5.9/pm_netidnnameprep-1.100,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
-rw-rw-r--  11 web      web        11194 Jul 12  2010 sparc/5.9/pm_idnapunycode-1.001,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
-rw-r--r--  11 web      web        17776 Mrz  8  2011 sparc/5.9/pm_net_idn_encode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
-rw-r--r--  11 web      web         8199 Mrz  8  2011 sparc/5.9/pm_netidnencode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
-rw-rw-r--  11 web      web        11061 Jul 12  2010 sparc/5.9/pm_netidnnameprep-1.100,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz


Best regards

  -- Dago

From dam at opencsw.org  Mon Apr 27 09:21:31 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 27 Apr 2015 09:21:31 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <553CA00D.4030609@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>
	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
	<5534AC1F.80806@opencsw.org>
	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>
	<5534F47F.2050008@opencsw.org>
	<2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>
	<55389621.4020902@opencsw.org>
	<93934E04-F505-467F-AAC4-A3DCB137EE02@opencsw.org>
	<553CA00D.4030609@opencsw.org>
Message-ID: <A9B3A380-95A6-4E9B-94CF-D9EE0837B067@opencsw.org>

Hi Riccardo,

> Am 26.04.2015 um 10:21 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> Dagobert Michelsen wrote:
>> 
>> I just looked: you can just leave trunk alone as Solaris 10 unstable does not ship
>> gnulinks any more.
> 
> I see, perhaps we shouldn't need it on solaris 9 either? I'm checking:
> 
> #GLINKPKGS =  CSWbinutils CSWggetopt CSWgwhois
> 
> further down:
>                for p in $(GLINKPKGS); do \
> 
> this means this package shouldn't contain anything right now: no GLINKPKGS.
> 
> The package contains:
> 
> 1 s none /opt/csw/gnu/addr2line=../bin/gaddr2line
> 1 s none /opt/csw/gnu/ar=../bin/gar
> 1 s none /opt/csw/gnu/as=../bin/gas
> 1 s none /opt/csw/gnu/c++filt=../bin/gc++filt
> 1 s none /opt/csw/gnu/getopt=../bin/ggetopt
> 1 s none /opt/csw/gnu/gprof=../bin/ggprof
> 1 s none /opt/csw/gnu/ld=../bin/gld
> 1 s none /opt/csw/gnu/nm=../bin/gnm
> 1 s none /opt/csw/gnu/objcopy=../bin/gobjcopy
> 1 s none /opt/csw/gnu/objdump=../bin/gobjdump
> 1 s none /opt/csw/gnu/ranlib=../bin/granlib
> 1 s none /opt/csw/gnu/readelf=../bin/greadelf
> 1 s none /opt/csw/gnu/size=../bin/gsize
> 1 s none /opt/csw/gnu/strings=../bin/gstrings
> 1 s none /opt/csw/gnu/strip=../bin/gstrip
> 1 s none /opt/csw/gnu/whois=../bin/gwhois
> 
> 
> I would say that if I update binutils getopt and whois for solaris 9, we can throw away this package on Solaris 9 too, do you agree?

Yes, please remove CSWgnulinks from the Solaris 9 catalog prior to pusinh the updated CSWbinutils.


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/20150427/fb3d4fd3/attachment.p7s>

From dam at opencsw.org  Mon Apr 27 10:12:06 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 27 Apr 2015 10:12:06 +0200
Subject: gs_terminal: error on sol11 upload
In-Reply-To: <55389914.2050107@opencsw.org>
References: <5535F436.2050401@opencsw.org>
	<44879726-6399-4BE2-BCDE-A09648D7B5E8@opencsw.org>
	<5536910E.6080906@opencsw.org>
	<469C164E-C046-450C-AC5E-D411F83B01C3@opencsw.org>
	<55389914.2050107@opencsw.org>
Message-ID: <BA8B2F03-2BF2-48A1-A191-B454CA8D2147@opencsw.org>

Hi Riccardo,

> Am 23.04.2015 um 09:02 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> Dagobert Michelsen wrote:
>> You need to set
>>   export PYTHON_PATH=/home/rmottola/opencsw/.buildsys/v2
> 
> since I kept forgetting, I added it to my .bash_profile !

I keep forgetting, too: it is PYTHONPATH, not PYTHON_PATH :-P

Here is the error:

CHECKPKG_OVERRIDES_CSWgs-terminal += binary-architecture-does-not-match-placement|file=opt/csw/GNUstep/Local/Applications/Terminal.app/Terminal|arch_id=3|arch_name=i386


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/20150427/d582ab10/attachment.p7s>

From rmottola at opencsw.org  Mon Apr 27 14:42:33 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 27 Apr 2015 14:42:33 +0200
Subject: building / packaging CSWpm-net-libidn
Message-ID: <553E2EB9.2030905@opencsw.org>

Hi,

since CSWpm-net-libidn is missing on Solaris 9, I wanted to build it, so 
that I can rebuild gwhois and cleanup all the gnulinks stuff with fresh 
packages.

I issue "mgar build package" and get:
gmake: Entering directory 
`/home/rmottola/opencsw/cpan/Net-LibIDN/trunk/work/build-isa-sparcv8/Net-LibIDN-0.12'
gmake: *** No targets specified and no makefile found.  Stop.
gmake: Leaving directory 
`/home/rmottola/opencsw/cpan/Net-LibIDN/trunk/work/build-isa-sparcv8/Net-LibIDN-0.12'
gmake[1]: *** [build-work/build-isa-sparcv8/Net-LibIDN-0.12/Makefile] 
Error 2
gmake[1]: Leaving directory `/home/rmottola/opencsw/cpan/Net-LibIDN/trunk'
gmake: *** [build-isa-sparcv8] Error 2


Is there some special caveat for perl packages?
Why does gwhois depend on a perl package at all?

Thank you

Riccardo

From dam at opencsw.org  Mon Apr 27 14:52:24 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 27 Apr 2015 14:52:24 +0200
Subject: building / packaging CSWpm-net-libidn
In-Reply-To: <553E2EB9.2030905@opencsw.org>
References: <553E2EB9.2030905@opencsw.org>
Message-ID: <9610EC2F-7BBE-46ED-A3D5-D56BCF8A791D@opencsw.org>

Hi Riccardo,

> Am 27.04.2015 um 14:42 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> since CSWpm-net-libidn is missing on Solaris 9, I wanted to build it, so that I can rebuild gwhois and cleanup all the gnulinks stuff with fresh packages.
> 
> I issue "mgar build package" and get:
> gmake: Entering directory `/home/rmottola/opencsw/cpan/Net-LibIDN/trunk/work/build-isa-sparcv8/Net-LibIDN-0.12'
> gmake: *** No targets specified and no makefile found.  Stop.
> gmake: Leaving directory `/home/rmottola/opencsw/cpan/Net-LibIDN/trunk/work/build-isa-sparcv8/Net-LibIDN-0.12'
> gmake[1]: *** [build-work/build-isa-sparcv8/Net-LibIDN-0.12/Makefile] Error 2
> gmake[1]: Leaving directory `/home/rmottola/opencsw/cpan/Net-LibIDN/trunk'
> gmake: *** [build-isa-sparcv8] Error 2

Because there is no Makefile because the configure phase fails. Just take a look
at the buildlog:

>  ==> Running Makefile.PL in work/solaris9-sparc/build-isa-sparcv8/Net-LibIDN-0.12
> ( cd work/solaris9-sparc/build-isa-sparcv8/Net-LibIDN-0.12 ; \
>     HOME="/home/dam" PATH="/home/dam/mgar/pkg/.buildsys/v2/gar/bin/sos12-wrappers:/home/dam/mgar/pkg/cpan/Net-LibIDN/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/bin:/home/dam/mgar/pkg/cpan/Net-LibIDN/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/bin:/home/dam/mgar/pkg/cpan/Net-LibIDN/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/sbin:/home/dam/mgar/pkg/cpan/Net-LibIDN/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/SUNWspro/bin:/home/dam/mgar/pkg/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodi
> r="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-xO3 -m32 -xarch=v8" CXXFLAGS="-xO3 -m32 -xarch=v8" LDFLAGS="-m32 -xarch=v8 -L/opt/csw/lib" FFLAGS="-xO3 -m32 -xarch=v8" FCFLAGS="-xO3 -m32 -xarch=v8" F77="/opt/SUNWspro/bin/f77" FC="/opt/SUNWspro/bin/f95" ASFLAGS="" OPTFLAGS="-xO3 -m32 -xarch=v8" CC="/opt/SUNWspro/bin/cc" CXX="/opt/SUNWspro/bin/CC" CC_HOME="/opt/SUNWspro" CC_VERSION="Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11" CXX_VERSION="Sun C++ 5.9 SunOS_sparc Patch 124863-30 2012/07/11" GARCH="sparc" GAROSREL="5.9" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -B direct -z ignore -L/opt/csw/lib -lperl" PKG_CONFIG_PATH="/opt/csw/lib/pkgconfig" DESTDIR="/home/dam/mgar/pkg/cpan/Net-LibIDN/trunk/work/solaris9-sparc/install-isa-sparcv8"  PERL5LIB= PERL_MM_USE_DEFAULT=1  /opt/csw/bin/perl Makefile.PL \
>         --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man  INSTALLDIRS=vendor  )
> Unknown option: prefix
> Unknown option: exec_prefix
> Unknown option: bindir
> Unknown option: sbindir
> Unknown option: libexecdir
> Unknown option: datadir
> Unknown option: sysconfdir
> Unknown option: sharedstatedir
> Unknown option: localstatedir
> Unknown option: libdir
> Unknown option: infodir
> Unknown option: includedir
> Unknown option: mandir
> cc: Warning: illegal option -norunpath

^^^^ This is the problem, the compiler on Solaris 9 does not understand it.

> "__test1.c", line 1: cannot find include file: <idna.h>
> "__test1.c", line 8: warning: implicit function declaration: idna_to_ascii_8z
> cc: acomp failed for __test1.c
> gcc: error: unrecognized option '-norunpath'
> This module requires GNU Libidn, which could not be found.
>         [configure-modulated] complete for Net-LibIDN.
> 
> Is there some special caveat for perl packages?

No :-)

> Why does gwhois depend on a perl package at all?

I guess you need to investigate.


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/20150427/8e030001/attachment-0001.p7s>

From laurent at opencsw.org  Tue Apr 28 10:36:40 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Tue, 28 Apr 2015 10:36:40 +0200
Subject: Brokenness caused by libpng update
Message-ID: <553F4698.1000009@opencsw.org>

Hello,

The recent libpng update to 1.6 has broken building every package
indirectly depending on it: the .pc files referenced the 1.5 version,
which has now disappeared.

I already can't rebuild ImageMagick, because librsvg's .pc complains. I
can't rebuilt librsvg, because gdk_pixbuf's .pc complains.

Note that because of the way those .pc are used in the configure
scripts, the errors happen during building, and look unrelated, eg:

rsvg.h:31:25: fatal error: glib-object.h: No such file or directory

Even though the glib-object.h is present.

That's because the CFLAGS are improperly set, due to configure not
catching the error while setting them:

$ /opt/csw/bin/pkg-config --cflags gdk-pixbuf-2.0
sh: gnome-config: introuvable
Package libpng15 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng15.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpng15', required by 'GdkPixbuf', not found

Riccardo, since you upgraded, can you please list those issues and
contact each maintainer, in order to fix the dependencies in the right
order?

Thanks,

Laurent

From rmottola at opencsw.org  Tue Apr 28 21:13:05 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 28 Apr 2015 21:13:05 +0200
Subject: nonexistent dependency
In-Reply-To: <8A065110-88CF-4AB2-AC89-BA0C35787147@opencsw.org>
References: <553D47ED.5060304@opencsw.org>
	<8A065110-88CF-4AB2-AC89-BA0C35787147@opencsw.org>
Message-ID: <553FDBC1.9060302@opencsw.org>

Hi Dagobert,

I understand a little more: gwhois is a perl scritp, thus it requires 
that certain perl module to work. In turn I am unable to build that perl 
module for a variety of reasons.

But what is my original intent? remove gnulinks. Now since any new app 
needs to provde the equivalent link itself, do I really need to rebuild 
gwhois? It is most probably broken.

look here:

gwhois-4.7.10-SunOS5.8-sparc-CSW.pkg.gz

It is so old it comes from solaris 5.8? On 5.10
http://www.opencsw.org/packages/CSWgwhois/

shows no reverse dependencies. Perhaps it is for now a safe wish to lest 
it "rest"? Ir remains there, just without a gwhois -> whois link.

Riccardo

On 04/26/15 22:19, Dagobert Michelsen wrote:
> Hi Riccardo,
>
> Am 26.04.2015 um 22:17 schrieb Riccardo Mottola:
>> I am rebuilding gwhois so that in theory I could remove gnulinks from solaris 9 too (I hope you can confirm this).
>>
>> However, in gwhois I get these warnings:
>>
>> CHECKPKG_OVERRIDES_CSWgwhois += pkginfo-opencsw-repository-uncommitted
>> CHECKPKG_OVERRIDES_CSWgwhois += dependency-on-nonexistent-package|CSWpm-net-libidn
>>
>> I see the package here:
>> http://www.opencsw.org/packages/CSWpm-net-libidn
> The view is Solaris 10 i386 only.
>
>> Is this packages not installed on unstable9s/unstable9x or is it missing totally there and it is a new dependency?
> It does not exist on Solaris 9:
>
> dam at login [login]:/export/mirror/opencsw-official/unstable > ls -l */5.9/pm*idn*
> -rw-rw-r--  11 web      web        11194 Jul 12  2010 i386/5.9/pm_idnapunycode-1.001,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
> -rw-r--r--  11 web      web        17776 Mrz  8  2011 i386/5.9/pm_net_idn_encode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
> -rw-r--r--  11 web      web         8199 Mrz  8  2011 i386/5.9/pm_netidnencode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
> -rw-rw-r--  11 web      web        11061 Jul 12  2010 i386/5.9/pm_netidnnameprep-1.100,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
> -rw-rw-r--  11 web      web        11194 Jul 12  2010 sparc/5.9/pm_idnapunycode-1.001,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
> -rw-r--r--  11 web      web        17776 Mrz  8  2011 sparc/5.9/pm_net_idn_encode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
> -rw-r--r--  11 web      web         8199 Mrz  8  2011 sparc/5.9/pm_netidnencode-1.100,REV=2011.03.08-SunOS5.9-all-CSW.pkg.gz
> -rw-rw-r--  11 web      web        11061 Jul 12  2010 sparc/5.9/pm_netidnnameprep-1.100,REV=2010.07.10-SunOS5.9-all-CSW.pkg.gz
>
>


From rmottola at opencsw.org  Tue Apr 28 21:19:56 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 28 Apr 2015 21:19:56 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <553F4698.1000009@opencsw.org>
References: <553F4698.1000009@opencsw.org>
Message-ID: <553FDD5C.5060504@opencsw.org>

Hi Laurent,

On 04/28/15 10:36, Laurent Blume wrote:
> Hello,
>
> The recent libpng update to 1.6 has broken building every package
> indirectly depending on it: the .pc files referenced the 1.5 version,
> which has now disappeared.

sorry if I did something wrong. I tried my best upgrading libpng and 
asked for confirmation in the receipe changes.

what are these .pc files? perhaps package-config? Are they part of libpng?

Should I change something in libpng? I have seen that a new, minor 1.6 
release is out so I planned an update anyway, although it is minor and 
not a security concern like this update was.


> I already can't rebuild ImageMagick, because librsvg's .pc complains. I
> can't rebuilt librsvg, because gdk_pixbuf's .pc complains.
>
> Note that because of the way those .pc are used in the configure
> scripts, the errors happen during building, and look unrelated, eg:
>
> rsvg.h:31:25: fatal error: glib-object.h: No such file or directory
>
> Even though the glib-object.h is present.
>
> That's because the CFLAGS are improperly set, due to configure not
> catching the error while setting them:
>
> $ /opt/csw/bin/pkg-config --cflags gdk-pixbuf-2.0
> sh: gnome-config: introuvable
> Package libpng15 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libpng15.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libpng15', required by 'GdkPixbuf', not found

but is this a problem with the reverse dependencies on libpng? Is this 
just a matter of rebuilding them?

> Riccardo, since you upgraded, can you please list those issues and
> contact each maintainer, in order to fix the dependencies in the right
> order?

Sure, how do I do it best, how do I have a list of those issues?
libpng-dev has  just once reverse dependency, however

http://www.opencsw.org/packages/CSWlibpng15-15/

shows 49 reverese dependencies, many of them don't appear to have a 
maintainer/uploader.

Thank you,

Riccardo

From rmottola at opencsw.org  Tue Apr 28 21:21:23 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 28 Apr 2015 21:21:23 +0200
Subject: updated binutils for solaris 9
In-Reply-To: <A9B3A380-95A6-4E9B-94CF-D9EE0837B067@opencsw.org>
References: <5533E9B3.6060000@opencsw.org>	<CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>	<5534AC1F.80806@opencsw.org>	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>	<5534F47F.2050008@opencsw.org>	<2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>	<55389621.4020902@opencsw.org>	<93934E04-F505-467F-AAC4-A3DCB137EE02@opencsw.org>	<553CA00D.4030609@opencsw.org>
	<A9B3A380-95A6-4E9B-94CF-D9EE0837B067@opencsw.org>
Message-ID: <553FDDB3.7060908@opencsw.org>

Hi,

On 04/27/15 09:21, Dagobert Michelsen wrote:
> Yes, please remove CSWgnulinks from the Solaris 9 catalog prior to pusinh the updated CSWbinutils.
>

can I do it myself? how do I do it? thanks.

Riccardo

From laurent at opencsw.org  Tue Apr 28 21:26:24 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Tue, 28 Apr 2015 21:26:24 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <553FDD5C.5060504@opencsw.org>
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
Message-ID: <553FDEE0.8020106@opencsw.org>

Le 2015/04/28 21:19 +0200, Riccardo Mottola a ?crit:
> sorry if I did something wrong. I tried my best upgrading libpng and
> asked for confirmation in the receipe changes.

Nothing wrong, it's just the fun of handling dependencies. I've dealt
with such things in the past too.

> what are these .pc files? perhaps package-config? Are they part of libpng?

USed by pkg-config(1).

> Should I change something in libpng? I have seen that a new, minor 1.6
> release is out so I planned an update anyway, although it is minor and
> not a security concern like this update was.

No, you only need to deal with organizing the rebuild of deps impacted
by it.

> but is this a problem with the reverse dependencies on libpng? Is this
> just a matter of rebuilding them?

Yep.

> Sure, how do I do it best, how do I have a list of those issues?
> libpng-dev has  just once reverse dependency, however

The website should tell you which packages depend on linpng, check their
.pc files for inclusion of libpng15 as a dependency there.

> http://www.opencsw.org/packages/CSWlibpng15-15/
> 
> shows 49 reverese dependencies, many of them don't appear to have a
> maintainer/uploader.

List them and check if they have -config scripts or .pc files that could
need a rebuild with 1.6.

Laurent

 

From dam at opencsw.org  Tue Apr 28 21:39:05 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 28 Apr 2015 21:39:05 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <553FDEE0.8020106@opencsw.org>
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org>
Message-ID: <C6662F07-5BBC-4F20-9AC6-7C520BC205EB@opencsw.org>

Hi Riccardo,

> Am 28.04.2015 um 21:26 schrieb Laurent Blume <laurent at opencsw.org>:
> 
> Le 2015/04/28 21:19 +0200, Riccardo Mottola a ?crit:
>> sorry if I did something wrong. I tried my best upgrading libpng and
>> asked for confirmation in the receipe changes.
> 
> Nothing wrong, it's just the fun of handling dependencies. I've dealt
> with such things in the past too.

:-D

>> Should I change something in libpng? I have seen that a new, minor 1.6
>> release is out so I planned an update anyway, although it is minor and
>> not a security concern like this update was.
> 
> No, you only need to deal with organizing the rebuild of deps impacted
> by it.

That means kicking other maintainers to fix their packages. A similar project
was the OpenSSL rebuild:
  http://wiki.opencsw.org/project-openssl

I suggest you make a similar page and track progress.


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/20150428/bb714120/attachment.p7s>

From rmottola at opencsw.org  Tue Apr 28 22:31:01 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 28 Apr 2015 22:31:01 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <C6662F07-5BBC-4F20-9AC6-7C520BC205EB@opencsw.org>
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org>
	<C6662F07-5BBC-4F20-9AC6-7C520BC205EB@opencsw.org>
Message-ID: <553FEE05.2050009@opencsw.org>

Hi,

On 04/28/15 21:39, Dagobert Michelsen wrote:
> I suggest you make a similar page and track progress.

It is an immense task just to populate the project page... at least, I 
am doing via the thing I hate most: copy&paste with a browser.

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

The list is long up to 49... but you can already check.
Maybe some packages are not needed anymore and can be removed.

Riccardo

From rmottola at opencsw.org  Tue Apr 28 23:03:04 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 28 Apr 2015 23:03:04 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <553FDEE0.8020106@opencsw.org>
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org>
Message-ID: <553FF588.7000500@opencsw.org>

Hi,

On 04/28/15 21:26, Laurent Blume wrote:
> The website should tell you which packages depend on linpng, check their
> .pc files for inclusion of libpng15 as a dependency there.

it is actually CSWlibpng15-15 (for 1.5.13) thus I copied and created 
CSWlibpng16-16

why the -15 actually? CSWlibpng15 would have been enough?

it justconfused me since the release 1.6.16, once 1.6.17 comes out, this 
fallout won't happen I hope: it remains CSWlibpng16-16, doesn't it?

Riccardo

From laurent at opencsw.org  Tue Apr 28 23:32:31 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Tue, 28 Apr 2015 23:32:31 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <553FF588.7000500@opencsw.org>
References: <553F4698.1000009@opencsw.org>
	<553FDD5C.5060504@opencsw.org>	<553FDEE0.8020106@opencsw.org>
	<553FF588.7000500@opencsw.org>
Message-ID: <553FFC6F.6020905@opencsw.org>

Le 2015/04/28 23:03 +0200, Riccardo Mottola a ?crit:
> Hi,
> 
> On 04/28/15 21:26, Laurent Blume wrote:
>> The website should tell you which packages depend on linpng, check their
>> .pc files for inclusion of libpng15 as a dependency there.
> 
> it is actually CSWlibpng15-15 (for 1.5.13) thus I copied and created
> CSWlibpng16-16

Sorry, I was talking specifically about the libpng15.pc file, that
others' .pc files depend on.

> why the -15 actually? CSWlibpng15 would have been enough?

Because they versioned both the library name and its soname, and mgar
concatenates them automatically.

> it justconfused me since the release 1.6.16, once 1.6.17 comes out, this
> fallout won't happen I hope: it remains CSWlibpng16-16, doesn't it?

Should be fine. Probably.

Actually, maybe the error here was to have libpng-dev not be
libpng15-dev. Maybe that could have worked.

Laurent

From rmottola at opencsw.org  Tue Apr 28 23:52:47 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 28 Apr 2015 23:52:47 +0200
Subject: freetype - fails to detect compiler on 5.9
Message-ID: <5540012F.9000506@opencsw.org>

Hi,

I want to (re)build freetype on 5.9 and I get a strange problem:
No compiler gets detected.

this is the config log:

configure:3312: checking for gcc
configure:3339: result: /opt/solarisstudio12.3/bin/cc
configure:3568: checking for C compiler version
configure:3577: /opt/solarisstudio12.3/bin/cc --version >&5
/home/rmottola/opencsw/fontconfig/trunk/work/build-isa-sparcv8/fontconfig-2.11.0
/configure: /opt/solarisstudio12.3/bin/cc: No such file or directory


the path is bogus though, I suppose the correct one would be:
/opt/studio/SOS12/SUNWspro/bin/cc

but how does it get picked up?


Riccardo

From jgoerzen at opencsw.org  Wed Apr 29 00:49:10 2015
From: jgoerzen at opencsw.org (jgoerzen)
Date: Tue, 28 Apr 2015 15:49:10 -0700
Subject: freetype - fails to detect compiler on 5.9
In-Reply-To: <5540012F.9000506@opencsw.org>
References: <5540012F.9000506@opencsw.org>
Message-ID: <55400E66.1060904@opencsw.org>

Hi Riccardo,

On 4/28/2015 2:52 PM, Riccardo Mottola wrote:
> Hi,
>
> I want to (re)build freetype on 5.9 and I get a strange problem:
> No compiler gets detected.
>
> this is the config log:
>
> configure:3312: checking for gcc
> configure:3339: result: /opt/solarisstudio12.3/bin/cc
> configure:3568: checking for C compiler version
> configure:3577: /opt/solarisstudio12.3/bin/cc --version >&5
> /home/rmottola/opencsw/fontconfig/trunk/work/build-isa-sparcv8/fontconfig-2.11.0 
>
> /configure: /opt/solarisstudio12.3/bin/cc: No such file or directory
>
>
> the path is bogus though, I suppose the correct one would be:
> /opt/studio/SOS12/SUNWspro/bin/cc
>
> but how does it get picked up?
>
>
> Riccardo

    It gets picked up from what ever you have set in your recipe for 
GARCOMPILER.  Studio 12.3 is not installed on unstable9s/x  (see 
/etc/SETUP on login host).    I would set GARCOMPILER = SUN in your gar 
recipe or remove it and try again.

Regards,
Jake



From dam at opencsw.org  Wed Apr 29 07:01:03 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 29 Apr 2015 07:01:03 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <553FFC6F.6020905@opencsw.org>
References: <553F4698.1000009@opencsw.org> <553FDD5C.5060504@opencsw.org>
	<553FDEE0.8020106@opencsw.org> <553FF588.7000500@opencsw.org>
	<553FFC6F.6020905@opencsw.org>
Message-ID: <C953871D-FA90-455B-B2BD-87D694F3F16B@opencsw.org>





> Am 28.04.2015 um 23:32 schrieb Laurent Blume <laurent at opencsw.org>:
> 
> Le 2015/04/28 23:03 +0200, Riccardo Mottola a ?crit:
>> Hi,
>> 
>>> On 04/28/15 21:26, Laurent Blume wrote:
>>> The website should tell you which packages depend on linpng, check their
>>> .pc files for inclusion of libpng15 as a dependency there.
>> 
>> it is actually CSWlibpng15-15 (for 1.5.13) thus I copied and created
>> CSWlibpng16-16
> 
> Sorry, I was talking specifically about the libpng15.pc file, that
> others' .pc files depend on.
> 
>> why the -15 actually? CSWlibpng15 would have been enough?
> 
> Because they versioned both the library name and its soname, and mgar
> concatenates them automatically.
> 
>> it justconfused me since the release 1.6.16, once 1.6.17 comes out, this
>> fallout won't happen I hope: it remains CSWlibpng16-16, doesn't it?
> 
> Should be fine. Probably.
> 
> Actually, maybe the error here was to have libpng-dev not be
> libpng15-dev. Maybe that could have worked

I suggest to rename CSWlibpng15-dev to CSWlibpng-dev and make an obsoleting prior to rebuild the world.

Best regards -- Dago

From grzemba at contac-dt.de  Wed Apr 29 09:25:11 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Wed, 29 Apr 2015 09:25:11 +0200
Subject: set ISA depend path in GAR recipe
In-Reply-To: <bf23ffd0192d.55408756@contac-dt.de>
References: <bf23d70c6c20.554084be@contac-dt.de>
	<bf23c9cd4909.554084fc@contac-dt.de>
	<bf239715968.55408538@contac-dt.de>
	<bf23be803a25.55408575@contac-dt.de>
	<bf23dfd44fed.55408719@contac-dt.de>
	<bf23ffd0192d.55408756@contac-dt.de>
Message-ID: <bf1cdbe7252d.5540a377@contac-dt.de>

I set

CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd

to get /opt/csw/sbin/amd64/httpd on x86 64bit build but it expand to: 

configure: error: /opt/csw/sbin/pentium_pro/httpd not found

on 
?==> Running configure in work/build-isa-amd64/admin-389-admin-1.1.38

What's going wrong there? 
Is there a GAR variable which will set to "" on 32bit and amd64 or sparcv9 on 64bit build?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150429/438e6f58/attachment.html>

From grzemba at contac-dt.de  Wed Apr 29 10:00:07 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Wed, 29 Apr 2015 10:00:07 +0200
Subject: 64bit Apache24
In-Reply-To: <bf1cea862be6.55408f74@contac-dt.de>
References: <bf1c9a333c5.55408ebc@contac-dt.de>
	<bf1cc1104f53.55408ef9@contac-dt.de>
	<bf1cd5955c9c.55408f35@contac-dt.de>
	<bf1cea862be6.55408f74@contac-dt.de>
Message-ID: <bf1cbe647c2d.5540aba7@contac-dt.de>

there two things we should do before release the 64bit Apache24:
- in httpd.conf must fixed the path for LoadModule for the 64bit modules. 
 Should we deliver there two httpd.conf files?
- we should add a SVC property to select the 32bit or 64bit httpd to start
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150429/f61d80f9/attachment.html>

From wilbury at opencsw.org  Wed Apr 29 10:03:23 2015
From: wilbury at opencsw.org (Juraj Lutter)
Date: Wed, 29 Apr 2015 10:03:23 +0200
Subject: 64bit Apache24
In-Reply-To: <bf1cbe647c2d.5540aba7@contac-dt.de>
References: <bf1c9a333c5.55408ebc@contac-dt.de>	<bf1cc1104f53.55408ef9@contac-dt.de>	<bf1cd5955c9c.55408f35@contac-dt.de>	<bf1cea862be6.55408f74@contac-dt.de>
	<bf1cbe647c2d.5540aba7@contac-dt.de>
Message-ID: <5540904B.2060305@opencsw.org>

On 04/29/15 10:00, Carsten Grzemba wrote:
> - we should add a SVC property to select the 32bit or 64bit httpd to
> start 

PostgreSQL does it in the way where they have two instances in one FMRI
(:32_bit, :64bit)

We probably can go like this.

Then, PHP also needs to be updated for Apache24 compatibility :-)

j.



-- 
Juraj Lutter <wilbury at opencsw.org>


From rmottola at opencsw.org  Wed Apr 29 10:05:28 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 29 Apr 2015 10:05:28 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <C953871D-FA90-455B-B2BD-87D694F3F16B@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>
Message-ID: <554090C8.6090309@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> I suggest to rename CSWlibpng15-dev to CSWlibpng-dev and make an obsoleting prior to rebuild the world.

Laurent is suggesting the opposite... but that would contradict common 
way of having a single dev package which is always up to date. That's 
also how other packaging systems to it usually.

Riccardo

From rmottola at opencsw.org  Wed Apr 29 10:42:17 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 29 Apr 2015 10:42:17 +0200
Subject: freetype - fails to detect compiler on 5.9
In-Reply-To: <55400E66.1060904@opencsw.org>
References: <5540012F.9000506@opencsw.org> <55400E66.1060904@opencsw.org>
Message-ID: <55409969.9020404@opencsw.org>

Hi Jake,

jgoerzen wrote:
>
>    It gets picked up from what ever you have set in your recipe for 
> GARCOMPILER.  Studio 12.3 is not installed on unstable9s/x (see 
> /etc/SETUP on login host).    I would set GARCOMPILER = SUN in your 
> gar recipe or remove it and try again. 

the receipe has "no setting", this means that the host on the buildfarm 
is not set up correct?
Adding the setting fixes it and should do no harm.

Riccardo

From rmottola at opencsw.org  Wed Apr 29 16:28:27 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 29 Apr 2015 16:28:27 +0200
Subject: freetype update
Message-ID: <5540EA8B.8080104@opencsw.org>

Hi,

I have set the GARCOMPILER on freetype and built it for sol9 and sol10.
I have also updated the version to the latest 2.4 (same major soname 
version 6!).

I hope it is not such a problem like libpng to update it? No fallout...

I haven't touched anything else... the current Maintainer is Dago.

freetype2_stub-2.4.12,REV=2015.04.29-SunOS5.10-all-CSW.pkg.gz
freetype2_stub-2.4.12,REV=2015.04.29-SunOS5.9-all-CSW.pkg.gz
libfreetype6-2.4.12,REV=2015.04.29-SunOS5.10-i386-CSW.pkg.gz
libfreetype6-2.4.12,REV=2015.04.29-SunOS5.10-sparc-CSW.pkg.gz
libfreetype6-2.4.12,REV=2015.04.29-SunOS5.9-i386-CSW.pkg.gz
libfreetype6-2.4.12,REV=2015.04.29-SunOS5.9-sparc-CSW.pkg.gz
libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.10-i386-CSW.pkg.gz
libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.10-sparc-CSW.pkg.gz
libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.9-i386-CSW.pkg.gz
libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.9-sparc-CSW.pkg.gz

may I upload?

Riccardo

From maciej at opencsw.org  Wed Apr 29 21:54:15 2015
From: maciej at opencsw.org (Maciej =?utf-8?Q?=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 29 Apr 2015 12:54:15 -0700
Subject: updated binutils for solaris 9
In-Reply-To: <553FDDB3.7060908@opencsw.org>
References: <CALtRa-70bmr1Ps5reeVbxBMQexQQWEGNqZAUdTH+C6A0isOwkQ@mail.gmail.com>
	<5534AC1F.80806@opencsw.org>
	<F125C642-E88E-4DE1-8CC1-A29E3A6285B2@opencsw.org>
	<5534F47F.2050008@opencsw.org>
	<2B8E2E80-7E1C-4542-A270-AF76FA6C2F9B@opencsw.org>
	<55389621.4020902@opencsw.org>
	<93934E04-F505-467F-AAC4-A3DCB137EE02@opencsw.org>
	<553CA00D.4030609@opencsw.org>
	<A9B3A380-95A6-4E9B-94CF-D9EE0837B067@opencsw.org>
	<553FDDB3.7060908@opencsw.org>
Message-ID: <20150429195415.GA14313@gmail.com>

On Tue, Apr 28, 2015 at 09:21:23PM +0200, Riccardo Mottola wrote:
> Hi,
> 
> On 04/27/15 09:21, Dagobert Michelsen wrote:
> >Yes, please remove CSWgnulinks from the Solaris 9 catalog prior to pusinh the updated CSWbinutils.
> >
> 
> can I do it myself? how do I do it? thanks.

Look into mgar/v2/lib/python for files named "remove" or similar. There was a
tool with some safeguards, but use it with care. If you're not sure, post the
options you want to run it with.

From maciej at opencsw.org  Wed Apr 29 22:17:42 2015
From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=)
Date: Wed, 29 Apr 2015 13:17:42 -0700
Subject: set ISA depend path in GAR recipe
In-Reply-To: <bf1cdbe7252d.5540a377@contac-dt.de>
References: <bf23d70c6c20.554084be@contac-dt.de>
	<bf23c9cd4909.554084fc@contac-dt.de>
	<bf239715968.55408538@contac-dt.de>
	<bf23be803a25.55408575@contac-dt.de>
	<bf23dfd44fed.55408719@contac-dt.de>
	<bf23ffd0192d.55408756@contac-dt.de>
	<bf1cdbe7252d.5540a377@contac-dt.de>
Message-ID: <20150429201742.GA15500@gmail.com>

On Wed, Apr 29, 2015 at 09:25:11AM +0200, Carsten Grzemba wrote:
> I set
> 
> CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd

Can you tell a bit more about the problem you're solving? I know you're
working on the 64-bit Apache.

Can you use isaexec?

If you can't or don't use isaexec, why do you want to create directories
compliant with isaexec?

Can you define your own names for httpd, like /opt/csw/sbin/httpd-32 and
/opt/csw/bin/httpd-64?

From grzemba at contac-dt.de  Thu Apr 30 09:11:55 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Thu, 30 Apr 2015 09:11:55 +0200
Subject: set ISA depend path in GAR recipe
In-Reply-To: <bf4db739505d.5541d58e@contac-dt.de>
References: <bf23d70c6c20.554084be@contac-dt.de>
	<bf23c9cd4909.554084fc@contac-dt.de>
	<bf239715968.55408538@contac-dt.de>
	<bf23be803a25.55408575@contac-dt.de>
	<bf23dfd44fed.55408719@contac-dt.de>
	<bf23ffd0192d.55408756@contac-dt.de>
	<bf1cdbe7252d.5540a377@contac-dt.de>
	<20150429201742.GA15500@gmail.com> <bf4d996b178e.5541d460@contac-dt.de>
	<bf4db528735b.5541d49d@contac-dt.de>
	<bf4deab63f4.5541d4d9@contac-dt.de>
	<bf4de99e6a1d.5541d515@contac-dt.de>
	<bf4df5e6694f.5541d552@contac-dt.de>
	<bf4db739505d.5541d58e@contac-dt.de>
Message-ID: <bf4dc35852f7.5541f1db@contac-dt.de>

isaexec or alternative works only for bins .? There are some cases where other configs want to now the right isa path.
In my case 389-admin is a package which depends on apache24. Because directory server should run on 64bit I want to build also the admin libraries and tools in 64bit.

btw: BUILD_ISAS is for me a possible gar variable.

Am 29.04.15 schrieb Maciej Blizi?ski  <maciej at opencsw.org>:
> On Wed, Apr 29, 2015 at 09:25:11AM +0200, Carsten Grzemba wrote:
> > I set
> > 
> > CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd
> 
> Can you tell a bit more about the problem you're solving? I know you're
> working on the 64-bit Apache.
> 
> Can you use isaexec?
> 
> If you can't or don't use isaexec, why do you want to create directories
> compliant with isaexec?
> 
> Can you define your own names for httpd, like /opt/csw/sbin/httpd-32 and
> /opt/csw/bin/httpd-64?
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150430/66fc353e/attachment.html>

From grzemba at contac-dt.de  Thu Apr 30 09:32:26 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Thu, 30 Apr 2015 09:32:26 +0200
Subject: set ISA depend path in GAR recipe
In-Reply-To: <bf4df1bf2973.5541da5d@contac-dt.de>
References: <bf23d70c6c20.554084be@contac-dt.de>
	<bf23c9cd4909.554084fc@contac-dt.de>
	<bf239715968.55408538@contac-dt.de>
	<bf23be803a25.55408575@contac-dt.de>
	<bf23dfd44fed.55408719@contac-dt.de>
	<bf23ffd0192d.55408756@contac-dt.de>
	<bf1cdbe7252d.5540a377@contac-dt.de>
	<20150429201742.GA15500@gmail.com> <bf4dab4b7773.5541d8f1@contac-dt.de>
	<bf4dfc7e1344.5541d92d@contac-dt.de>
	<bf4df1bf2973.5541da5d@contac-dt.de>
Message-ID: <bf4dd9d07fa4.5541f6aa@contac-dt.de>

For that:
> in httpd.conf must fixed the path for LoadModule for the 64bit modules. 
> Should we deliver there two httpd.conf files?
How do linux distros handle this?


Am 29.04.15 schrieb Maciej Blizi?ski  <maciej at opencsw.org>:
> On Wed, Apr 29, 2015 at 09:25:11AM +0200, Carsten Grzemba wrote:
> > I set
> > 
> > CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd
> 
> Can you tell a bit more about the problem you're solving? I know you're
> working on the 64-bit Apache.
> 
> Can you use isaexec?
> 
> If you can't or don't use isaexec, why do you want to create directories
> compliant with isaexec?
> 
> Can you define your own names for httpd, like /opt/csw/sbin/httpd-32 and
> /opt/csw/bin/httpd-64?
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150430/4e6f8085/attachment-0001.html>

From dam at opencsw.org  Thu Apr 30 09:35:02 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 09:35:02 +0200
Subject: nonexistent dependency
In-Reply-To: <553FDBC1.9060302@opencsw.org>
References: <553D47ED.5060304@opencsw.org>
	<8A065110-88CF-4AB2-AC89-BA0C35787147@opencsw.org>
	<553FDBC1.9060302@opencsw.org>
Message-ID: <0BBEC265-50D5-4C83-90BB-439723EED798@opencsw.org>

Hi Riccardo,

> Am 28.04.2015 um 21:13 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi Dagobert,
> 
> I understand a little more: gwhois is a perl scritp, thus it requires that certain perl module to work. In turn I am unable to build that perl module for a variety of reasons.
> 
> But what is my original intent? remove gnulinks. Now since any new app needs to provde the equivalent link itself, do I really need to rebuild gwhois? It is most probably broken.
> 
> look here:
> 
> gwhois-4.7.10-SunOS5.8-sparc-CSW.pkg.gz
> 
> It is so old it comes from solaris 5.8? On 5.10
> http://www.opencsw.org/packages/CSWgwhois/
> 
> shows no reverse dependencies. Perhaps it is for now a safe wish to lest it "rest"? Ir remains there, just without a gwhois -> whois link.

As a last ressort I guess that would be ok, although you may contact Juraj who maintains
the current CSWgwhois and see why there are no module dependencies and either recompile
gwhois on Solaris 9 or probably rebuild CSWgnulinks with just this symlink *if* CSWgwhois
is functional. If it is broken and cannot be rebuild it should probably removed and gnulinks
dropped.


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/20150430/825bcabd/attachment.p7s>

From dam at opencsw.org  Thu Apr 30 09:42:33 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 09:42:33 +0200
Subject: 64bit Apache24
In-Reply-To: <5540904B.2060305@opencsw.org>
References: <bf1c9a333c5.55408ebc@contac-dt.de>
	<bf1cc1104f53.55408ef9@contac-dt.de>
	<bf1cd5955c9c.55408f35@contac-dt.de>
	<bf1cea862be6.55408f74@contac-dt.de>
	<bf1cbe647c2d.5540aba7@contac-dt.de> <5540904B.2060305@opencsw.org>
Message-ID: <916B8245-2347-4DA2-B3BE-63C1DE2414C2@opencsw.org>

Hi,

> Am 29.04.2015 um 10:03 schrieb Juraj Lutter <wilbury at opencsw.org>:
> 
> On 04/29/15 10:00, Carsten Grzemba wrote:
>> - we should add a SVC property to select the 32bit or 64bit httpd to
>> start 
> 
> PostgreSQL does it in the way where they have two instances in one FMRI
> (:32_bit, :64bit)

And with the instance the config-file could be passed as property.

> We probably can go like this.
> 
> Then, PHP also needs to be updated for Apache24 compatibility :-)

Once the rest has been settled PHP should be doable.


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/20150430/ad4330ea/attachment.p7s>

From laurent at opencsw.org  Thu Apr 30 09:42:45 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 30 Apr 2015 09:42:45 +0200
Subject: set ISA depend path in GAR recipe
In-Reply-To: <20150429201742.GA15500@gmail.com>
References: <bf23d70c6c20.554084be@contac-dt.de>	<bf23c9cd4909.554084fc@contac-dt.de>	<bf239715968.55408538@contac-dt.de>	<bf23be803a25.55408575@contac-dt.de>	<bf23dfd44fed.55408719@contac-dt.de>	<bf23ffd0192d.55408756@contac-dt.de>	<bf1cdbe7252d.5540a377@contac-dt.de>
	<20150429201742.GA15500@gmail.com>
Message-ID: <5541DCF5.5050607@opencsw.org>

Le 2015/04/29 22:17 +0200, Matchek a ?crit:
> On Wed, Apr 29, 2015 at 09:25:11AM +0200, Carsten Grzemba wrote:
>> I set
>>
>> CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd
> 
> Can you tell a bit more about the problem you're solving? I know you're
> working on the 64-bit Apache.
> 
> Can you use isaexec?

I'm not in favor of using isaexec indiscriminately for server apps. This
is IMO a choice that should be made explicitly by the admin, because
it's not neutral.

I'm speaking from the MySQL viewpoint, where an automatic choice 32/64
bit choice by the OS can effectively break a DB (it's the one area where
the database are not guaranteed to be binary-compatible).
I can see it easily being needed on Apache too, since not all modules
are going to be equally available.

> If you can't or don't use isaexec, why do you want to create directories
> compliant with isaexec?

Because it satisfies the principle of least astonishment in the
organization of binaries :-)

> Can you define your own names for httpd, like /opt/csw/sbin/httpd-32 and
> /opt/csw/bin/httpd-64?

I think the issue is that the HTTPD_ROOT would still be the same for
both, and that's the basis on which the default httpd.conf picks up the
modules/*.so files (which would have to be 32 or 64).

Would there be an environment value that could be used in the httpd.conf
to make an if clause that would load either of 2 blocks, one for 32, one
for 64, or maybe reset the HTTPD_ROOT, like what they do eg for varied
httpd engines?

Laurent

From dam at opencsw.org  Thu Apr 30 09:46:45 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 09:46:45 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <554090C8.6090309@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>
Message-ID: <DBDFE095-3546-445B-A42C-9E92A23AB0AB@opencsw.org>

Hi Riccardo,

Am 29.04.2015 um 10:05 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> I suggest to rename CSWlibpng15-dev to CSWlibpng-dev and make an obsoleting prior to rebuild the world.
> 
> Laurent is suggesting the opposite... but that would contradict common way of having a single dev package which is always up to date. That's also how other packaging systems to it usually.

Ah yes, I guess I took the contents wrong. As the *-config and pkgconfig-files
explicitly contain the version number the development package must stick to it.
So I too favor for bringing back CSWlibpng16-dev


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/20150430/10d314f3/attachment.p7s>

From dam at opencsw.org  Thu Apr 30 09:49:33 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 09:49:33 +0200
Subject: freetype - fails to detect compiler on 5.9
In-Reply-To: <55409969.9020404@opencsw.org>
References: <5540012F.9000506@opencsw.org> <55400E66.1060904@opencsw.org>
	<55409969.9020404@opencsw.org>
Message-ID: <F7CDD555-98FE-4027-A2D5-F871FBEEBF3B@opencsw.org>

Hi Riccardo,

Am 29.04.2015 um 10:42 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> jgoerzen wrote:
>> 
>>   It gets picked up from what ever you have set in your recipe for GARCOMPILER.  Studio 12.3 is not installed on unstable9s/x (see /etc/SETUP on login host).    I would set GARCOMPILER = SUN in your gar recipe or remove it and try again. 
> 
> the receipe has "no setting", this means that the host on the buildfarm is not set up correct?
> Adding the setting fixes it and should do no harm.

Haha, we never had a default for Solaris 8:
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.conf.mk#99

Feel free to add
  GARCOMPILER-SUN-5.8 = SOS12


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/20150430/a69234af/attachment-0001.p7s>

From grzemba at contac-dt.de  Thu Apr 30 09:57:28 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Thu, 30 Apr 2015 09:57:28 +0200
Subject: set ISA depend path in GAR recipe
In-Reply-To: <bf3dd8883f8.5541e066@contac-dt.de>
References: <bf23d70c6c20.554084be@contac-dt.de>
	<bf23c9cd4909.554084fc@contac-dt.de>
	<bf239715968.55408538@contac-dt.de>
	<bf23be803a25.55408575@contac-dt.de>
	<bf23dfd44fed.55408719@contac-dt.de>
	<bf23ffd0192d.55408756@contac-dt.de>
	<bf1cdbe7252d.5540a377@contac-dt.de>
	<20150429201742.GA15500@gmail.com> <5541DCF5.5050607@opencsw.org>
	<bf3d8b9975f8.5541df75@contac-dt.de>
	<bf3db9f31d13.5541dfb1@contac-dt.de>
	<bf3da42b5d01.5541dfed@contac-dt.de>
	<bf3d82891610.5541e029@contac-dt.de>
	<bf3dd8883f8.5541e066@contac-dt.de>
Message-ID: <bf3d80ccffe.5541fc88@contac-dt.de>

As mentioned previously BUILD_ISAS helps in my case but it is pentium_pro or sparcv8 on 32bit. 
A better solution whould be a GAR variable which 
is empty on 32bit build = ""
and on 64bit build = /64
Do we have such GAR variable already?

Am 30.04.15 schrieb Laurent Blume  <laurent at opencsw.org>:
> Le 2015/04/29 22:17 +0200, Matchek a ?crit:
> > On Wed, Apr 29, 2015 at 09:25:11AM +0200, Carsten Grzemba wrote:
> >> I set
> >>
> >> CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd
> > 
> > Can you tell a bit more about the problem you're solving? I know you're
> > working on the 64-bit Apache.
> > 
> > Can you use isaexec?
> 
> I'm not in favor of using isaexec indiscriminately for server apps. This
> is IMO a choice that should be made explicitly by the admin, because
> it's not neutral.
> 
> I'm speaking from the MySQL viewpoint, where an automatic choice 32/64
> bit choice by the OS can effectively break a DB (it's the one area where
> the database are not guaranteed to be binary-compatible).
> I can see it easily being needed on Apache too, since not all modules
> are going to be equally available.
> 
> > If you can't or don't use isaexec, why do you want to create directories
> > compliant with isaexec?
> 
> Because it satisfies the principle of least astonishment in the
> organization of binaries :-)
> 
> > Can you define your own names for httpd, like /opt/csw/sbin/httpd-32 and
> > /opt/csw/bin/httpd-64?
> 
> I think the issue is that the HTTPD_ROOT would still be the same for
> both, and that's the basis on which the default httpd.conf picks up the
> modules/*.so files (which would have to be 32 or 64).
> 
> Would there be an environment value that could be used in the httpd.conf
> to make an if clause that would load either of 2 blocks, one for 32, one
> for 64, or maybe reset the HTTPD_ROOT, like what they do eg for varied
> httpd engines?
> 
> Laurent
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150430/b1084185/attachment.html>

From laurent at opencsw.org  Thu Apr 30 10:00:39 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 30 Apr 2015 10:00:39 +0200
Subject: Brokenness caused by libpng update
In-Reply-To: <DBDFE095-3546-445B-A42C-9E92A23AB0AB@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>
Message-ID: <5541E127.9070903@opencsw.org>

Le 2015/04/30 09:46 +0200, Dagobert Michelsen a ?crit:
> Ah yes, I guess I took the contents wrong. As the *-config and pkgconfig-files
> explicitly contain the version number the development package must stick to it.
> So I too favor for bringing back CSWlibpng16-dev

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


So here is a proposal:
  - 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.


I'm not the one doing it, so up to you :-)

Laurent


Laurent
  -


From dam at opencsw.org  Thu Apr 30 10:03:59 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 10:03:59 +0200
Subject: freetype update
In-Reply-To: <5540EA8B.8080104@opencsw.org>
References: <5540EA8B.8080104@opencsw.org>
Message-ID: <6A3E2F4A-B7D2-4252-BC21-F8C1ABB3AB4D@opencsw.org>

Hi Riccardo,

> Am 29.04.2015 um 16:28 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> I have set the GARCOMPILER on freetype and built it for sol9 and sol10.
> I have also updated the version to the latest 2.4 (same major soname version 6!).
> 
> I hope it is not such a problem like libpng to update it? No fallout...
> 
> I haven't touched anything else... the current Maintainer is Dago.
> 
> freetype2_stub-2.4.12,REV=2015.04.29-SunOS5.10-all-CSW.pkg.gz
> freetype2_stub-2.4.12,REV=2015.04.29-SunOS5.9-all-CSW.pkg.gz
> libfreetype6-2.4.12,REV=2015.04.29-SunOS5.10-i386-CSW.pkg.gz
> libfreetype6-2.4.12,REV=2015.04.29-SunOS5.10-sparc-CSW.pkg.gz
> libfreetype6-2.4.12,REV=2015.04.29-SunOS5.9-i386-CSW.pkg.gz
> libfreetype6-2.4.12,REV=2015.04.29-SunOS5.9-sparc-CSW.pkg.gz
> libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.10-i386-CSW.pkg.gz
> libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.10-sparc-CSW.pkg.gz
> libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.9-i386-CSW.pkg.gz
> libfreetype_dev-2.4.12,REV=2015.04.29-SunOS5.9-sparc-CSW.pkg.gz
> 
> may I upload?

Sure. Want to give the 2.5 branch a try? ;-)


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/20150430/d314f2f1/attachment.p7s>

From dam at opencsw.org  Thu Apr 30 10:22:28 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 10:22:28 +0200
Subject: freetype - fails to detect compiler on 5.9
In-Reply-To: <F7CDD555-98FE-4027-A2D5-F871FBEEBF3B@opencsw.org>
References: <5540012F.9000506@opencsw.org> <55400E66.1060904@opencsw.org>
	<55409969.9020404@opencsw.org>
	<F7CDD555-98FE-4027-A2D5-F871FBEEBF3B@opencsw.org>
Message-ID: <2B534E80-E102-441A-B664-04CAACCD2471@opencsw.org>

Hi,

> Am 30.04.2015 um 09:49 schrieb Dagobert Michelsen <dam at opencsw.org>:
> 
> Hi Riccardo,
> 
> Am 29.04.2015 um 10:42 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>> jgoerzen wrote:
>>> 
>>>  It gets picked up from what ever you have set in your recipe for GARCOMPILER.  Studio 12.3 is not installed on unstable9s/x (see /etc/SETUP on login host).    I would set GARCOMPILER = SUN in your gar recipe or remove it and try again. 
>> 
>> the receipe has "no setting", this means that the host on the buildfarm is not set up correct?
>> Adding the setting fixes it and should do no harm.
> 
> Haha, we never had a default for Solaris 8:
>  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.conf.mk#99
> 
> Feel free to add
>  GARCOMPILER-SUN-5.8 = SOS12

I shouldn?t post before first coffee, you are working on Solaris *9* which already
has Sun Studio 12 as default. If 12.3 is invoked it is pulled in from somewhere else,
your local .garrc?


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/20150430/d2b902e2/attachment.p7s>

From dam at opencsw.org  Thu Apr 30 10:26:58 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 10:26:58 +0200
Subject: set ISA depend path in GAR recipe
In-Reply-To: <bf3d80ccffe.5541fc88@contac-dt.de>
References: <bf23d70c6c20.554084be@contac-dt.de>
	<bf23c9cd4909.554084fc@contac-dt.de>
	<bf239715968.55408538@contac-dt.de>
	<bf23be803a25.55408575@contac-dt.de>
	<bf23dfd44fed.55408719@contac-dt.de>
	<bf23ffd0192d.55408756@contac-dt.de>
	<bf1cdbe7252d.5540a377@contac-dt.de>
	<20150429201742.GA15500@gmail.com> <5541DCF5.5050607@opencsw.org>
	<bf3d8b9975f8.5541df75@contac-dt.de>
	<bf3db9f31d13.5541dfb1@contac-dt.de>
	<bf3da42b5d01.5541dfed@contac-dt.de>
	<bf3d82891610.5541e029@contac-dt.de>
	<bf3dd8883f8.5541e066@contac-dt.de>
	<bf3d80ccffe.5541fc88@contac-dt.de>
Message-ID: <5703973D-78AD-4A20-BB47-7D17C71A3541@opencsw.org>

Hi Carsten,

> Am 30.04.2015 um 09:57 schrieb Carsten Grzemba <grzemba at contac-dt.de>:
> 
> As mentioned previously BUILD_ISAS helps in my case but it is pentium_pro or sparcv8 on 32bit. 
> A better solution whould be a GAR variable which 
> is empty on 32bit build    = ""
> and on 64bit build             = /64
> Do we have such GAR variable already?

Yes, that is $(ISABINDIR):
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.conf.mk#562


Best regards

  ? Dago

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150430/ba3e723c/attachment-0001.html>
-------------- 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/20150430/ba3e723c/attachment-0001.p7s>

From dam at opencsw.org  Thu Apr 30 11:06:34 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Apr 2015 11:06:34 +0200
Subject: GCC 5.1
Message-ID: <396FD6F6-596F-48EB-8483-004C98FC98C7@opencsw.org>

Hi folks (and especially Maciej),

I am fiddling with GCC 5.1 and get some file collisions with GCC 4. I am not sure how to
best proceed here as these are non-versioned libs and devel-stuff. I tend to make them
incompatible with the corresponding GCC 4 packages. Thoughts?


CHECKPKG_OVERRIDES_CSWgcc5g++ += file-collision|/opt/csw/lib/libstdc++.a|CSWgcc4g++|CSWgcc5g++
CHECKPKG_OVERRIDES_CSWgcc5g++ += file-collision|/opt/csw/lib/sparcv9/libstdc++.a|CSWgcc4g++|CSWgcc5g++
CHECKPKG_OVERRIDES_CSWgcc5g++ += file-collision|/opt/csw/lib/libstdc++.so|CSWgcc4g++|CSWgcc5g++
CHECKPKG_OVERRIDES_CSWgcc5g++ += file-collision|/opt/csw/lib/sparcv9/libstdc++.so|CSWgcc4g++|CSWgcc5g++
CHECKPKG_OVERRIDES_CSWgcc5g++ += file-collision|/opt/csw/lib/libstdc++.la|CSWgcc4g++|CSWgcc5g++
CHECKPKG_OVERRIDES_CSWgcc5g++ += file-collision|/opt/csw/lib/sparcv9/libstdc++.la|CSWgcc4g++|CSWgcc5g++
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/share/info/gcj.info|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/lib-gnu-awt-xlib.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/sparcv9/logging.properties|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/libgcj.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/security/classpath.security|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/sparcv9/lib-gnu-awt-xlib.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/sparcv9/libgij.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/sparcv9/security/classpath.security|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/sparcv9/libgcj.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/libgcj-tools.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/libgij.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/sparcv9/libgcj-tools.la|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5java += file-collision|/opt/csw/lib/logging.properties|CSWgcc4java|CSWgcc5java
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/libobjc_gc.la|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/sparcv9/libobjc_gc.la|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/libobjc.a|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/libobjc_gc.so|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/sparcv9/libobjc.a|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/sparcv9/libobjc_gc.so|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/libobjc.la|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/sparcv9/libobjc.la|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/sparcv9/libobjc_gc.a|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/libobjc_gc.a|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/libobjc.so|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5objc += file-collision|/opt/csw/lib/sparcv9/libobjc.so|CSWgcc4objc|CSWgcc5objc
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/lib/sparcv9/libgfortran.so|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/share/info/gfortran.info|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/lib/sparcv9/libgfortran.la|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/lib/sparcv9/libgfortran.a|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/lib/libgfortran.so|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/lib/libgfortran.a|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5gfortran += file-collision|/opt/csw/lib/libgfortran.la|CSWgcc4gfortran|CSWgcc5gfortran
CHECKPKG_OVERRIDES_CSWgcc5core += shared-lib-pkgname-mismatch|file=opt/csw/lib/libgomp-plugin-host_nonshm.so.1.0.0|soname=libgomp-plugin-host_nonshm.so.1|pkgname=CSWgcc5core|expected=CSWlibgomp-plugin-host-nonshm1
CHECKPKG_OVERRIDES_CSWgcc5core += shared-lib-pkgname-mismatch|file=opt/csw/lib/sparcv9/libgomp-plugin-host_nonshm.so.1.0.0|soname=libgomp-plugin-host_nonshm.so.1|pkgname=CSWgcc5core|expected=CSWlibgomp-plugin-host-nonshm1
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/sv/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gnat_ugn.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgcj.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/el/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/fi/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgomp.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgij.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libitm.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libitm.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgomp.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/lib-gnu-awt-xlib.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/man/man7/gpl.7|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/hr/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/vi/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/fr/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/zh_TW/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/es/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/de/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gnat_rm.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/vi/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/fr/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgcj.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgo.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/libgomp.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgomp.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libatomic.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libssp_nonshared.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/lib-gnu-awt-xlib.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libssp.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libatomic.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libatomic.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gccint.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/be/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/zh_TW/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/sr/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/nl/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libitm.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgo.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgij.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/de/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/uk/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgcj.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libsupc++.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/ru/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgomp.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgomp.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/tr/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgomp.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/clearcap.map|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/nl/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libssp.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libatomic.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libitm.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/id/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libsupc++.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/libitm.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libssp_nonshared.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgcj-tools.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/tr/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgo.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgomp.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/zh_CN/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libsupc++.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/pt_BR/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libatomic.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgo.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgfortran.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libssp.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libitm.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/zh_CN/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gccgo.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/cppinternals.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libsupc++.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/da/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgcj-tools.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/eo/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gnat-style.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libatomic.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/es/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/ja/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/be/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgcc-unwind.map|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libssp.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgcc_s.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/fi/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgomp.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gccinstall.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/man/man7/fsf-funding.7|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/cp-tools.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/ru/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libitm.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/da/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/sv/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libitm.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgo.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/id/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/ja/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/cpp.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/ca/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libssp.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgobegin.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgo.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/libquadmath.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libitm.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libgfortran.spec|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgcc_s.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libssp.so|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/man/man7/gfdl.7|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libssp_nonshared.la|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/sparcv9/libgobegin.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/lib/libssp_nonshared.a|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/sr/LC_MESSAGES/gcc.mo|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/info/gcc.info|CSWgcc4core|CSWgcc5core
CHECKPKG_OVERRIDES_CSWgcc5core += file-collision|/opt/csw/share/locale/el/LC_MESSAGES/cpplib.mo|CSWgcc4core|CSWgcc5core


BTW: Everything is commited in pkg/gcc5/trunk just in case anybody else wants to try :-)


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/20150430/22df0841/attachment.p7s>

From rmottola at opencsw.org  Thu Apr 30 11:35:31 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 30 Apr 2015 11:35:31 +0200
Subject: freetype - fails to detect compiler on 5.9
In-Reply-To: <2B534E80-E102-441A-B664-04CAACCD2471@opencsw.org>
References: <5540012F.9000506@opencsw.org>
	<55400E66.1060904@opencsw.org>	<55409969.9020404@opencsw.org>	<F7CDD555-98FE-4027-A2D5-F871FBEEBF3B@opencsw.org>
	<2B534E80-E102-441A-B664-04CAACCD2471@opencsw.org>
Message-ID: <5541F763.405@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> I shouldn?t post before first coffee, you are working on Solaris *9* which already
> has Sun Studio 12 as default. If 12.3 is invoked it is pulled in from somewhere else,
> your local .garrc?

coffee.. cappuccino.. tea, black tea...
I still have Solaris 8 on my to-do list, but this was sol. 9.

My garrc has no compiler related settings. It only sets packager, mail, 
spkg and such stuff. I checked my "env" and see nothing related either.

The new package with explicit

GARCOMPILER = SUN

works. So.. we may leave this problem resting until the next package fails :)

Riccardo


From laurent at opencsw.org  Thu Apr 30 11:47:53 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 30 Apr 2015 11:47:53 +0200
Subject: GCC 5.1
In-Reply-To: <396FD6F6-596F-48EB-8483-004C98FC98C7@opencsw.org>
References: <396FD6F6-596F-48EB-8483-004C98FC98C7@opencsw.org>
Message-ID: <5541FA49.5020508@opencsw.org>

Le 2015/04/30 11:06 +0200, Dagobert Michelsen a ?crit:
> Hi folks (and especially Maciej),
> 
> I am fiddling with GCC 5.1 and get some file collisions with GCC 4. I am not sure how to
> best proceed here as these are non-versioned libs and devel-stuff. I tend to make them
> incompatible with the corresponding GCC 4 packages. Thoughts?

Incompatible seems good. The only other way is having a separate
/opt/csw/gcc5 dir, and that was given up a long time ago, right?

BTW, relevant read:

http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/


Laurent
 

From rmottola at opencsw.org  Thu Apr 30 23:51:52 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 30 Apr 2015 23:51:52 +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: <5542A3F8.1030004@opencsw.org>

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.

Riccardo

From rmottola at opencsw.org  Thu Apr 30 23:56:25 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 30 Apr 2015 23:56:25 +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: <5542A509.1080607@opencsw.org>

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
Gentoo's setup is exactly the same. But gentoo points that old libraries 
are kept for binary compatibilities and you are expected to build always 
against latest, which looks the only safe to do.
Otheriwse we need what Gentoo calls "slots" that means both versions can 
co-exist, but it means hiding stuff in subdirectories and that is really 
a mess and causes massive headache: most packages need to be patched 
with extra include paths.

Riccardo