From dam at opencsw.org  Thu Oct  1 08:53:03 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Oct 2015 08:53:03 +0200
Subject: gnutls - texi problems^
In-Reply-To: <8d1f11f1c1e5c2cea848b8eec47c1f93@think>
References: <8d1f11f1c1e5c2cea848b8eec47c1f93@think>
Message-ID: <B0574445-AF04-4DB0-88FE-563BC49A2765@opencsw.org>

Hi Riccardo,

Am 29.09.2015 um 17:52 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> On 2015-09-29 16:36:50 +0200 Riccardo Mottola <rmottola at opencsw.org> wrote:
>> I have updated the texinfo package so that it matches the solaris 10 version. I still get the same errors.
>> What woul dbe the macro package you are referring to? perhaps that needs updating too.
> 
> I found that several people on the internet had a similar porblem. It appears a problem with "nm"
> 
> is there a way to ensure that
> /opt/csw/sparc-sun-solaris2.9/bin/nm
> 
> is used instead of
> /opt/csw/bin/nm
> 
> some receipe variable? Apart this I have no other clues.

I am afraid you need to look in the configure scripts and Makefiles of texinfo to answer that.


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/20151001/1ffc74e4/attachment.p7s>

From rmottola at opencsw.org  Thu Oct  1 14:01:40 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 01 Oct 2015 14:01:40 +0200
Subject: gnutls - texi problems
In-Reply-To: <B0574445-AF04-4DB0-88FE-563BC49A2765@opencsw.org>
Message-ID: <46ea13152ae92a3b41803e6709bdc307@think>

Hi Dagobert,

On 2015-10-01 08:53:03 +0200 Dagobert Michelsen <dam at opencsw.org> 
wrote:

> Hi Riccardo,
> 
>> I found that several people on the internet had a similar porblem. 
>> It 
>> appears a problem with "nm"
>> 
>> is there a way to ensure that
>> /opt/csw/sparc-sun-solaris2.9/bin/nm
>> 
>> is used instead of
>> /opt/csw/bin/nm
>> 
>> some receipe variable? Apart this I have no other clues.
> 
> I am afraid you need to look in the configure scripts and Makefiles 
> of 
> texinfo to answer that.

NM=gnm fixes "that" problem. However the texinfo problems are of 
totally different nature.

I found mention of a backport patch in debian and found the actuall 
commit in gnutls repository. With newer versions of perl some 
expressions work unreliably depending on the order. I backported and 
added the patch directly from the official repository.

compilation on both solaris 9 and 10  sparc are successful. Trying out 
x86 now where I have the strange platform problem. I'm executing "mgar 
platforms" right now.

I think it is better for the sake to update the solaris10 packages 
too, even if in the past they built.

Riccardo


From rmottola at opencsw.org  Thu Oct  1 14:58:22 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 01 Oct 2015 14:58:22 +0200
Subject: gnutls - solaris9 x86 build
In-Reply-To: <<<<d6f482d0c939d6b7bde24086f9c410bd@think>>>>
Message-ID: <1dbb9f907185a5b9b48b68cf20b4099f@think>

Hi,

having backported the texinfo patch, now I have everything fine on 
solaris 9 and 10... sparc!
So most dependencies should be right in the receipe.


On 2015-09-30 21:44:58 +0200 Riccardo Mottola <rmottola at opencsw.org> 
wrote:

> Hi,
> 
> I'm still struggling to rebuild gnutls on solaris9. I tried running 
> on x86 
> instead of sparc and get this:
> 
> /home/rmottola/opencsw/.buildsys/v2/gar//gar.conf.mk:555: *** The ISA 
> 'amd64' 
> can not be build on this kernel with the arch 'i386'.  Stop.
> gmake[1]: Leaving directory `/home/rmottola/opencsw/gnutls/trunk'
> 
> 
> I thus think there is something wrong with the receipe?
> 
> could this be the problem?
> BUILD64_LIBS_ONLY = 1

Instead of "mgar build" directly on 9x, I issued "mgar platforms" and 
then apparently with some magic everything builds, but I do get at the 
end:

CHECKPKG_OVERRIDES_CSWlibgnutls26 += 
soname-not-found|libgcc_s.so.1|is|needed|by|opt/csw/lib/amd64/libgnutlsxx.so.27.0.0
CHECKPKG_OVERRIDES_CSWlibgnutls26 += 
soname-not-found|libgcc_s.so.1|is|needed|by|opt/csw/lib/amd64/libgnutls-extra.so.26.22.6
CHECKPKG_OVERRIDES_CSWlibgnutls26 += 
soname-not-found|libgcc_s.so.1|is|needed|by|opt/csw/lib/amd64/libgnutls.so.26.22.6
CHECKPKG_OVERRIDES_CSWlibgnutls26 += 
soname-not-found|libstdc++.so.6|is|needed|by|opt/csw/lib/amd64/libgnutlsxx.so.27.0.0

and this makes me shudder.. what is going on? amd64 build on intel 
9... not finding the gcc library?

That said, I did run
find /opt/csw/lib -name libgcc_s.so.\*


on solaris 9s:
/opt/csw/lib/libgcc_s.so.1
/opt/csw/lib/libgcc_s.so.2.95.3
/opt/csw/lib/sparcv9/libgcc_s.so.1

on solaris10s:
/opt/csw/lib/libgcc_s.so.1
/opt/csw/lib/sparcv9/libgcc_s.so.1

looks fine, except for the old 2.95 library

on solaris 9x?
/opt/csw/lib/libgcc_s.so.1
/opt/csw/lib/libgcc_s.so.2.95.3


well, the 64bit is missing. But obvious, it is not a 64bit os! :)
And now?
I remembr you told me there was some kind of trick about faking 64bit 
on solaris9.. but not that it actually attempted to build.
What is wrong with this receipe?

Riccardo


From dam at opencsw.org  Thu Oct  1 13:52:52 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Oct 2015 13:52:52 +0200
Subject: gnutls - solaris9 x86 build
In-Reply-To: <1dbb9f907185a5b9b48b68cf20b4099f@think>
References: <1dbb9f907185a5b9b48b68cf20b4099f@think>
Message-ID: <C1E4E5BC-0937-4BA4-89CF-5040C0D5926B@opencsw.org>

Hi Riccardo,

Am 01.10.2015 um 14:58 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> having backported the texinfo patch, now I have everything fine on solaris 9 and 10... sparc!
> So most dependencies should be right in the receipe.
> 
> On 2015-09-30 21:44:58 +0200 Riccardo Mottola <rmottola at opencsw.org> wrote:
> 
>> Hi,
>> I'm still struggling to rebuild gnutls on solaris9. I tried running on x86 instead of sparc and get this:
>> /home/rmottola/opencsw/.buildsys/v2/gar//gar.conf.mk:555: *** The ISA 'amd64' can not be build on this kernel with the arch 'i386'.  Stop.
>> gmake[1]: Leaving directory `/home/rmottola/opencsw/gnutls/trunk'
>> I thus think there is something wrong with the receipe?
>> could this be the problem?
>> BUILD64_LIBS_ONLY = 1
> 
> Instead of "mgar build" directly on 9x, I issued "mgar platforms" and then apparently with some magic everything builds, but I do get at the end:
> 
> CHECKPKG_OVERRIDES_CSWlibgnutls26 += soname-not-found|libgcc_s.so.1|is|needed|by|opt/csw/lib/amd64/libgnutlsxx.so.27.0.0
> CHECKPKG_OVERRIDES_CSWlibgnutls26 += soname-not-found|libgcc_s.so.1|is|needed|by|opt/csw/lib/amd64/libgnutls-extra.so.26.22.6
> CHECKPKG_OVERRIDES_CSWlibgnutls26 += soname-not-found|libgcc_s.so.1|is|needed|by|opt/csw/lib/amd64/libgnutls.so.26.22.6
> CHECKPKG_OVERRIDES_CSWlibgnutls26 += soname-not-found|libstdc++.so.6|is|needed|by|opt/csw/lib/amd64/libgnutlsxx.so.27.0.0
> 
> and this makes me shudder.. what is going on? amd64 build on intel 9... not finding the gcc library?
> 
> That said, I did run
> find /opt/csw/lib -name libgcc_s.so.\*
> 
> on solaris 9s:
> /opt/csw/lib/libgcc_s.so.1
> /opt/csw/lib/libgcc_s.so.2.95.3
> /opt/csw/lib/sparcv9/libgcc_s.so.1
> 
> on solaris10s:
> /opt/csw/lib/libgcc_s.so.1
> /opt/csw/lib/sparcv9/libgcc_s.so.1
> 
> looks fine, except for the old 2.95 library
> 
> on solaris 9x?
> /opt/csw/lib/libgcc_s.so.1
> /opt/csw/lib/libgcc_s.so.2.95.3
> 
> well, the 64bit is missing. But obvious, it is not a 64bit os! :)
> And now?
> I remembr you told me there was some kind of trick about faking 64bit on solaris9.. but not that it actually attempted to build.
> What is wrong with this receipe?

The issue is that Solaris 9 x86 is 32 bit only - there is no 64 bit Kernel!
We usually made packages for Solaris 9 with 32 bit that also included 64 bit
that would be used on Solaris 10 when there was no dedicated package for
Solaris 10 in addition to the Solaris 9 package.

When you have separate packages for Solaris 9 and 10 you should disable
64 bit for Solaris 9 x86 with a snippet like this:

> # Enable 64 bits, but not for Solaris 9 x86
> BUILD64_5.9_sparc  = 1
> BUILD64_5.10_sparc = 1
> BUILD64_5.9_i386   =
> BUILD64_5.10_i386  = 1
> BUILD64 = $(BUILD64_$(GAROSREL)_$(GARCH))


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/20151001/66074fd4/attachment-0001.p7s>

From dam at opencsw.org  Thu Oct  1 13:57:27 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Oct 2015 13:57:27 +0200
Subject: gnutls - texi problems
In-Reply-To: <46ea13152ae92a3b41803e6709bdc307@think>
References: <46ea13152ae92a3b41803e6709bdc307@think>
Message-ID: <59B5CC81-BBC3-4DBA-8DB3-ED01EA8E4D4E@opencsw.org>

Hi Riccardo,

Am 01.10.2015 um 14:01 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> NM=gnm fixes "that" problem. However the texinfo problems are of totally different nature.

Your recipe is lacking this important line:

  CONFIGURE_ARGS = $(DIRPATHS)

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/20151001/f3c0a1e7/attachment.p7s>

From rmottola at opencsw.org  Thu Oct  1 17:20:27 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 01 Oct 2015 17:20:27 +0200
Subject: gnutls - texi problems
In-Reply-To: <59B5CC81-BBC3-4DBA-8DB3-ED01EA8E4D4E@opencsw.org>
Message-ID: <15a1d8e936c176cbf6b5f04776dadcf4@think>

Hi,

On 2015-10-01 13:57:27 +0200 Dagobert Michelsen <dam at opencsw.org> 
wrote:

> Hi Riccardo,
> 
> Am 01.10.2015 um 14:01 schrieb Riccardo Mottola 
> <rmottola at opencsw.org>:
>> NM=gnm fixes "that" problem. However the texinfo problems are of 
>> totally 
>> different nature.
> 
> Your recipe is lacking this important line:

Actually, I think it is  your receipe :) or Yann's to be precise.

https://www.opencsw.org/package/gnutls/

what I wonder is that here current version is 3.1.5, while I see the 
receipe of 2.12.23 (which required a backport)

I still want to have this version available on both solaris 9 & 10 to 
fix my gnustep builds, however the next step would have been to 
upgrade to 3.x series.

I see that there is a gnutls3 directory.  I think I am working on the 
wrong package: an upload of a new 2.12 would break the "dev" part.

Better check my stuff.... I better spend having gnutls3 on solaris9 
then. The package names instead of a branch confused me.

> 
>   CONFIGURE_ARGS = $(DIRPATHS)

I see it : just before --disable-guile

Riccardo


From dam at opencsw.org  Thu Oct  1 15:26:07 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Oct 2015 15:26:07 +0200
Subject: gnutls - texi problems
In-Reply-To: <15a1d8e936c176cbf6b5f04776dadcf4@think>
References: <15a1d8e936c176cbf6b5f04776dadcf4@think>
Message-ID: <7B8AA3DE-2E84-486C-96EE-975CAE01ABCA@opencsw.org>

Hi Riccardo,

Am 01.10.2015 um 17:20 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> On 2015-10-01 13:57:27 +0200 Dagobert Michelsen <dam at opencsw.org> wrote:
>> 
>> Am 01.10.2015 um 14:01 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>>> NM=gnm fixes "that" problem. However the texinfo problems are of totally different nature.
>> Your recipe is lacking this important line:
> 
> Actually, I think it is  your receipe :) or Yann's to be precise.
> 
> https://www.opencsw.org/package/gnutls/
> 
> what I wonder is that here current version is 3.1.5, while I see the receipe of 2.12.23 (which required a backport)

That is for the 2.x branch, GNUTLS3 is in gnutls3/

> I still want to have this version available on both solaris 9 & 10 to fix my gnustep builds, however the next step would have been to upgrade to 3.x series.
> 
> I see that there is a gnutls3 directory.  I think I am working on the wrong package: an upload of a new 2.12 would break the "dev" part.
> 
> Better check my stuff.... I better spend having gnutls3 on solaris9 then. The package names instead of a branch confused me.
> 
>>  CONFIGURE_ARGS = $(DIRPATHS)
> 
> I see it : just before --disable-guile

Ok.

GnuTLS3 is hard to compile on Solaris. I took a stab every once in a while but
always lost track at some point. Making GnuTLS3 work on Solaris at all together
with upstream would be quite some good time spent IMHO.


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/20151001/2fff5778/attachment.p7s>

From rmottola at opencsw.org  Thu Oct  1 19:56:34 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 01 Oct 2015 19:56:34 +0200
Subject: gnutls 3 round 2
Message-ID: <df65d3694b975d9b87a951338dffc150@think>

Hi Dagobert (and hi to everybody else too),

since gnutls is important, let's bite the 3.x series.

I noticed you just commited some small tweaks. I have imported your 
BUILD64 suggestion into this branch.

Current status for me is on solaris 9:
serv.c: In function 'listen_socket':
serv.c:774:40: error: 'IPV6_V6ONLY' undeclared (first use in this 
function)
serv.c:774:40: note: each undeclared identifier is reported only once 
for each function it appears in

while solaris10 bails out just little later with:

   CXX      ex-cxx.o
In file included from /usr/include/sys/time.h:421:0,
                  from ../../gl/sys/time.h:39,
                  from /usr/include/sys/select.h:23,
                  from ../../gl/sys/select.h:36,
                  from /usr/include/sys/types.h:629,
                  from ../../gl/sys/types.h:27,
                  from ../../gl/stdio.h:58,
                  from ../../gl/wchar.h:71,
                  from /opt/csw/include/c++/4.9.2/cwchar:44,
                  from /opt/csw/include/c++/4.9.2/bits/postypes.h:40,
                  from /opt/csw/include/c++/4.9.2/iosfwd:40,
                  from /opt/csw/include/c++/4.9.2/ios:38,
                  from /opt/csw/include/c++/4.9.2/ostream:38,
                  from /opt/csw/include/c++/4.9.2/iostream:39,
                  from ex-cxx.cpp:2:
../../gl/stdio.h:1034:1: error: 'char* gets(char*)' conflicts with a 
previous declaration
  _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
  ^
In file included from /usr/include/stdio.h:66:0,
                  from ../../gl/stdio.h:43,
                  from ../../gl/wchar.h:71,
                  from /opt/csw/include/c++/4.9.2/cwchar:44,
                  from /opt/csw/include/c++/4.9.2/bits/postypes.h:40,
                  from /opt/csw/include/c++/4.9.2/iosfwd:40,
                  from /opt/csw/include/c++/4.9.2/ios:38,
                  from /opt/csw/include/c++/4.9.2/ostream:38,
                  from /opt/csw/include/c++/4.9.2/iostream:39,
                  from ex-cxx.cpp:2:
/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/include-fixed/iso/stdio_iso.h:242:14: 
note: previous declaration 'char* std::gets(char*)'
  extern char *gets(char *);
               ^
Makefile:1968: recipe for target 'ex-cxx.o' failed


the receipe is for 3.1.24

The gnutls website states;
current stable: 3.3.18
next stable (what does this mean, unstable?) 3.4.5

should we try out directly 3.3 or any reason to remain on 3.1 ? did 
things get even worse solaris-wise for newer releases?

Riccardo


From dam at opencsw.org  Thu Oct  1 18:24:44 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 1 Oct 2015 18:24:44 +0200
Subject: gnutls 3 round 2
In-Reply-To: <df65d3694b975d9b87a951338dffc150@think>
References: <df65d3694b975d9b87a951338dffc150@think>
Message-ID: <99D4D566-1D2E-46B2-ADE1-3B6A1F35944C@opencsw.org>

Hi Riccardo,

Am 01.10.2015 um 19:56 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Hi Dagobert (and hi to everybody else too),
> 
> since gnutls is important, let's bite the 3.x series.
> 
> I noticed you just commited some small tweaks. I have imported your BUILD64 suggestion into this branch.
> 
> Current status for me is on solaris 9:
> serv.c: In function 'listen_socket':
> serv.c:774:40: error: 'IPV6_V6ONLY' undeclared (first use in this function)
> serv.c:774:40: note: each undeclared identifier is reported only once for each function it appears in
> 
> while solaris10 bails out just little later with:
> 
>  CXX      ex-cxx.o
> In file included from /usr/include/sys/time.h:421:0,
>                 from ../../gl/sys/time.h:39,
>                 from /usr/include/sys/select.h:23,
>                 from ../../gl/sys/select.h:36,
>                 from /usr/include/sys/types.h:629,
>                 from ../../gl/sys/types.h:27,
>                 from ../../gl/stdio.h:58,
>                 from ../../gl/wchar.h:71,
>                 from /opt/csw/include/c++/4.9.2/cwchar:44,
>                 from /opt/csw/include/c++/4.9.2/bits/postypes.h:40,
>                 from /opt/csw/include/c++/4.9.2/iosfwd:40,
>                 from /opt/csw/include/c++/4.9.2/ios:38,
>                 from /opt/csw/include/c++/4.9.2/ostream:38,
>                 from /opt/csw/include/c++/4.9.2/iostream:39,
>                 from ex-cxx.cpp:2:
> ../../gl/stdio.h:1034:1: error: 'char* gets(char*)' conflicts with a previous declaration
> _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
> ^
> In file included from /usr/include/stdio.h:66:0,
>                 from ../../gl/stdio.h:43,
>                 from ../../gl/wchar.h:71,
>                 from /opt/csw/include/c++/4.9.2/cwchar:44,
>                 from /opt/csw/include/c++/4.9.2/bits/postypes.h:40,
>                 from /opt/csw/include/c++/4.9.2/iosfwd:40,
>                 from /opt/csw/include/c++/4.9.2/ios:38,
>                 from /opt/csw/include/c++/4.9.2/ostream:38,
>                 from /opt/csw/include/c++/4.9.2/iostream:39,
>                 from ex-cxx.cpp:2:
> /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/include-fixed/iso/stdio_iso.h:242:14: note: previous declaration 'char* std::gets(char*)'
> extern char *gets(char *);
>              ^
> Makefile:1968: recipe for target 'ex-cxx.o' failed
> 
> the receipe is for 3.1.24
> 
> The gnutls website states;
> current stable: 3.3.18
> next stable (what does this mean, unstable?) 3.4.5
> 
> should we try out directly 3.3 or any reason to remain on 3.1 ? did things get even worse solaris-wise for newer releases?

Just jump to the latest version, we can then see how the soname works out, GnuTLS 3 still ships with a .so.28 sonar AFAIK.


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/20151001/c8ea3ebe/attachment-0001.p7s>

From laurent at opencsw.org  Thu Oct  1 19:20:22 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 1 Oct 2015 19:20:22 +0200
Subject: gnutls 3 round 2
In-Reply-To: <df65d3694b975d9b87a951338dffc150@think>
References: <df65d3694b975d9b87a951338dffc150@think>
Message-ID: <560D6B56.8090505@opencsw.org>

Riccardo,

While you work in the past, your computer time is two hours in the
future, you might want to fix it:

for <laurent at bender.opencsw.org>; Thu,  1 Oct 2015 17:57:15 +0200 (CEST)
Date: Thu, 01 Oct 2015 19:56:34 +0200

Regards,

Laurent

From rmottola at opencsw.org  Fri Oct  2 19:19:30 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 02 Oct 2015 19:19:30 +0200
Subject: New Nettle (because of gnutls)
Message-ID: <a4cba2ada43411cfca71fbafd3fa4639@think>

Hi,

my attempts to update gnutls won't be that smooth: first thing, we 
need at least nettle 3.1.1.

The good news? I got it packaging on solaris 9&10 and x86&amd64&sparc!

Bad news? a new so-name version for both nettle (5) and hogweed (4).

May I csw-upload the packages? CUrrenlty they would be of Dagobert .

Riccardo


From dam at opencsw.org  Fri Oct  2 17:21:49 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 2 Oct 2015 17:21:49 +0200
Subject: New Nettle (because of gnutls)
In-Reply-To: <a4cba2ada43411cfca71fbafd3fa4639@think>
References: <a4cba2ada43411cfca71fbafd3fa4639@think>
Message-ID: <6F52FAC1-A3D1-43B2-A205-509E1D3FCBCB@opencsw.org>

Hi Riccardo,

> Am 02.10.2015 um 19:19 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> my attempts to update gnutls won't be that smooth: first thing, we need at least nettle 3.1.1.
> 
> The good news? I got it packaging on solaris 9&10 and x86&amd64&sparc!
> 
> Bad news? a new so-name version for both nettle (5) and hogweed (4).
> 
> May I csw-upload the packages? CUrrenlty they would be of Dagobert .

Sure, please do. I don?t expect breakages here.


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/20151002/d676be40/attachment.p7s>

From rmottola at opencsw.org  Fri Oct  2 20:49:00 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 02 Oct 2015 20:49:00 +0200
Subject: New Nettle (because of gnutls)
In-Reply-To: <6F52FAC1-A3D1-43B2-A205-509E1D3FCBCB@opencsw.org>
Message-ID: <9fa38fa1658c80e278c1d58bf0edebfd@think>

Hi Dago,

excellent, let's hope it is all good and no havoc!

On 2015-10-02 17:21:49 +0200 Dagobert Michelsen <dam at opencsw.org> wrote:


> 
> Sure, please do. I don?t expect breakages here.


uploaded! may you install everything, including 9s and 9x? 

Inserting libnettle6 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting libhogweed4 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
Inserting libnettle6 (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting libnettle_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting libnettle_utils (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting libhogweed4 (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
Inserting libnettle6 (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting libhogweed4 (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
Inserting libnettle6 (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting libnettle_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting libnettle_utils (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting libhogweed4 (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
Inserting libnettle6 (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libnettle_dev (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libnettle_utils (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libhogweed4 (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
Inserting libnettle6 (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting libhogweed4 (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
Inserting libnettle6 (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting libnettle_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting libnettle_utils (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting libhogweed4 (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
Inserting libnettle6 (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting libhogweed4 (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
Inserting libnettle6 (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting libnettle_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting libnettle_utils (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting libhogweed4 (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
Inserting libnettle6 (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting libnettle_dev (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting libnettle_utils (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
Inserting libhogweed4 (sparc SunOS5.9) into catalog unstable sparc SunOS5.9


Thank you,

Riccardo


From dam at opencsw.org  Sun Oct  4 21:43:34 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 4 Oct 2015 21:43:34 +0200
Subject: New Nettle (because of gnutls)
In-Reply-To: <9fa38fa1658c80e278c1d58bf0edebfd@think>
References: <9fa38fa1658c80e278c1d58bf0edebfd@think>
Message-ID: <200B0E36-7F0E-401B-8964-8E17D0246CF1@opencsw.org>

Hi Riccardo,

Am 02.10.2015 um 20:49 schrieb Riccardo Mottola:
> uploaded! may you install everything, including 9s and 9x? 
> 
> Inserting libnettle6 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
> Inserting libhogweed4 (i386 SunOS5.9) into catalog unstable i386 SunOS5.10
> Inserting libnettle6 (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
> Inserting libnettle_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
> Inserting libnettle_utils (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
> Inserting libhogweed4 (i386 SunOS5.10) into catalog unstable i386 SunOS5.10
> Inserting libnettle6 (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
> Inserting libhogweed4 (i386 SunOS5.9) into catalog unstable i386 SunOS5.11
> Inserting libnettle6 (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
> Inserting libnettle_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
> Inserting libnettle_utils (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
> Inserting libhogweed4 (i386 SunOS5.10) into catalog unstable i386 SunOS5.11
> Inserting libnettle6 (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
> Inserting libnettle_dev (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
> Inserting libnettle_utils (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
> Inserting libhogweed4 (i386 SunOS5.9) into catalog unstable i386 SunOS5.9
> Inserting libnettle6 (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
> Inserting libhogweed4 (sparc SunOS5.9) into catalog unstable sparc SunOS5.10
> Inserting libnettle6 (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
> Inserting libnettle_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
> Inserting libnettle_utils (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
> Inserting libhogweed4 (sparc SunOS5.10) into catalog unstable sparc SunOS5.10
> Inserting libnettle6 (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
> Inserting libhogweed4 (sparc SunOS5.9) into catalog unstable sparc SunOS5.11
> Inserting libnettle6 (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
> Inserting libnettle_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
> Inserting libnettle_utils (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
> Inserting libhogweed4 (sparc SunOS5.10) into catalog unstable sparc SunOS5.11
> Inserting libnettle6 (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
> Inserting libnettle_dev (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
> Inserting libnettle_utils (sparc SunOS5.9) into catalog unstable sparc SunOS5.9
> Inserting libhogweed4 (sparc SunOS5.9) into catalog unstable sparc SunOS5.9

Done.


Best regards

  -- Dago

From rmottola at opencsw.org  Mon Oct  5 18:35:25 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 5 Oct 2015 18:35:25 +0200
Subject: gnutls 3 round 2
In-Reply-To: <99D4D566-1D2E-46B2-ADE1-3B6A1F35944C@opencsw.org>
References: <df65d3694b975d9b87a951338dffc150@think>
	<99D4D566-1D2E-46B2-ADE1-3B6A1F35944C@opencsw.org>
Message-ID: <5612A6CD.5060809@opencsw.org>

Hi All,

Dagobert Michelsen wrote:
> Just jump to the latest version, we can then see how the soname works out, GnuTLS 3 still ships with a .so.28 sonar AFAIK.
after a new libnettle, getting back to GnuTLS 3.4.5 which would be latest.

Things look compilcated... I'm playing with options to get the minimal 
stuff, we can in case analyze them later.

Building on solaris 10x fails with:

copying selected object files to avoid basename conflicts...
   CC       psk.o
   CCLD     psktool
ld: fatal: file /opt/csw/lib/libopts.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to .libs/psktool

anyone has already encountered a similar problem?

According to:
https://blogs.oracle.com/rie/entry/wrong_elf_class_requires_consistent

it could be a problem with compiler flag consistency, but I don't set 
those flags, mgar sets them.

Riccardo

From dam at opencsw.org  Mon Oct  5 22:25:11 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 5 Oct 2015 22:25:11 +0200
Subject: gnutls 3 round 2
In-Reply-To: <5612A6CD.5060809@opencsw.org>
References: <df65d3694b975d9b87a951338dffc150@think>
	<99D4D566-1D2E-46B2-ADE1-3B6A1F35944C@opencsw.org>
	<5612A6CD.5060809@opencsw.org>
Message-ID: <C4A2E12E-9E8D-4B1C-8425-F22BF93F69D0@opencsw.org>

Hi Riccardo,

Am 05.10.2015 um 18:35 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> Just jump to the latest version, we can then see how the soname works out, GnuTLS 3 still ships with a .so.28 sonar AFAIK.
> after a new libnettle, getting back to GnuTLS 3.4.5 which would be latest.
> 
> Things look compilcated... I'm playing with options to get the minimal stuff, we can in case analyze them later.
> 
> Building on solaris 10x fails with:
> 
> copying selected object files to avoid basename conflicts...
>  CC       psk.o
>  CCLD     psktool
> ld: fatal: file /opt/csw/lib/libopts.so: wrong ELF class: ELFCLASS32
> ld: fatal: file processing errors. No output written to .libs/psktool
> 
> anyone has already encountered a similar problem?

Yes, this is a standard problem when something for a 64 bit build is picked up
in 32 bit, either because no 64 bit version is there or because some wrong path
pickup. Look for /opt/csw/lib instead of /opt/csw/lib/64.


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/20151005/3319d371/attachment-0001.p7s>

From rmottola at opencsw.org  Tue Oct  6 09:58:57 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 6 Oct 2015 09:58:57 +0200
Subject: gnutls 3 round 2
In-Reply-To: <C4A2E12E-9E8D-4B1C-8425-F22BF93F69D0@opencsw.org>
References: <df65d3694b975d9b87a951338dffc150@think>
	<99D4D566-1D2E-46B2-ADE1-3B6A1F35944C@opencsw.org>
	<5612A6CD.5060809@opencsw.org>
	<C4A2E12E-9E8D-4B1C-8425-F22BF93F69D0@opencsw.org>
Message-ID: <56137F41.4080308@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> Yes, this is a standard problem when something for a 64 bit build is picked up
> in 32 bit, either because no 64 bit version is there or because some wrong path
> pickup. Look for /opt/csw/lib instead of /opt/csw/lib/64.

You are right:
rmottola at unstable10x [global]:~ > ls /opt/csw/lib/libopt*
/opt/csw/lib/libopts.so          /opt/csw/lib/libopts.so.25.15.1
/opt/csw/lib/libopts.so.25

rmottola at unstable10x [global]:~ > ls /opt/csw/lib/64/libopt*
/opt/csw/lib/64/libopt*: No such file or directory


I suppose libopts was not build in 64bit version? This would imply we 
can't compile gnutls as 64bit, I suppose this this undesirable.

I'll try adding 64bit to libobpts  I hope this doesn't get a deep 
rebuild nightmare. I will ping Peter in case, it is his package.

Riccardo

From pfelecan at opencsw.org  Tue Oct  6 18:46:33 2015
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 06 Oct 2015 18:46:33 +0200
Subject: gnutls 3 round 2
In-Reply-To: <56137F41.4080308@opencsw.org> (Riccardo Mottola's message of
	"Tue, 6 Oct 2015 09:58:57 +0200")
References: <df65d3694b975d9b87a951338dffc150@think>
	<99D4D566-1D2E-46B2-ADE1-3B6A1F35944C@opencsw.org>
	<5612A6CD.5060809@opencsw.org>
	<C4A2E12E-9E8D-4B1C-8425-F22BF93F69D0@opencsw.org>
	<56137F41.4080308@opencsw.org>
Message-ID: <x64mi454ie.fsf@opencsw.org>

Riccardo Mottola <rmottola at opencsw.org> writes:

> I suppose libopts was not build in 64bit version? This would imply we
> can't compile gnutls as 64bit, I suppose this this undesirable.

I tried but get stuck with no solution at that moment. Sorry, I don't
remember what was the issue.

> I'll try adding 64bit to libobpts  I hope this doesn't get a deep
> rebuild nightmare. I will ping Peter in case, it is his package.

Please do.
-- 
Peter

From rmottola at opencsw.org  Thu Oct  8 19:45:31 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 8 Oct 2015 19:45:31 +0200
Subject: guile / unistr int8 types solaris 9
Message-ID: <5616ABBB.6060803@opencsw.org>

Hi,

since I want a new GnuTLS updated for all platforms, including for 
security reasons, I need a new libopts 64bit which comes from autogen 
which does not rebuild and would need also a 64bit guile.
Trying to rebuild guile (old version or minor updated one) on solaris 9 
gives the following error:

In file included from ../lib/stdint.h:78:0,
                  from ../libguile/scmconfig.h:24,
                  from ../libguile/__scm.h:54,
                  from ../libguile/_scm.h:68,
                  from chars.c:31:
/opt/csw/lib/gcc/sparc-sun-solaris2.9/4.6.4/include/stdint.h:34:23: 
error: conflicting types for 'unistring_int8_t'
/opt/csw/include/unistring/stdint.h:107:21: note: previous declaration 
of 'unistring_int8_t' was here

can someone help me out? I do not fully understand: there is a lot of 
magic for the problematic stdint.h headers of many platforms.
It looks actually about the same file over and over reused in these GNU 
projects.


unistring_int8_t : is defined only once in unistring! it has a private 
name and is:

typedef signed char unistring_int8_t;



the cited gcc stdint.h at line 34 defines:

typedef __INT8_TYPE__ int8_t;

where is the catch??

Riccardo

From rmottola at opencsw.org  Thu Oct 15 15:30:13 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 15 Oct 2015 15:30:13 +0200
Subject: libunistring update / soname update
Message-ID: <561FAA65.1040007@opencsw.org>

Hi,

in the TLS "udpate" effort I backtracked to Guile... which doesn't build 
on solaris 9 due to some strange header issue with clashes between gcc 
and libunistring.

First thing, I rebuilt libunistring and tweaked the receipt in the 
update: seems fine.

Perhaps it does make sense to install them even if there is no change? I 
think that just rebuilding with a more recent gcc might help, since the 
header got "patched" differently.

Second: why not just update? upstream went from 0.9.3 to 0.9.5.


Now I see in the package:

work/solaris9-sparc/pkgroot/opt/csw/lib/libunistring.so -> 
libunistring.so.2.0.0

while the existing:
/opt/csw/lib/libunistring.so -> libunistring.so.0.1.2


a bit strange that with a minor revision we jump from 0.1 to 2.0! but...

May I update the package without issues? or would you suggest a respin 
of the older? I don't want to cause havoc.
I would also rename the packahe from libunistring0 to libunistring2 of 
course.

Current maintainer would be Dago!

Riccardo

From dam at opencsw.org  Thu Oct 15 15:37:43 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 15 Oct 2015 15:37:43 +0200
Subject: libunistring update / soname update
In-Reply-To: <561FAA65.1040007@opencsw.org>
References: <561FAA65.1040007@opencsw.org>
Message-ID: <8D5C0DA1-7C0B-4704-A8A1-7CD4232405F0@opencsw.org>

Hi Riccardo,

Am 15.10.2015 um 15:30 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> in the TLS "udpate" effort I backtracked to Guile... which doesn't build on solaris 9 due to some strange header issue with clashes between gcc and libunistring.
> 
> First thing, I rebuilt libunistring and tweaked the receipt in the update: seems fine.
> 
> Perhaps it does make sense to install them even if there is no change? I think that just rebuilding with a more recent gcc might help, since the header got "patched" differently.

Feel free to rebuild.

> Second: why not just update? upstream went from 0.9.3 to 0.9.5.
> 
> 
> Now I see in the package:
> 
> work/solaris9-sparc/pkgroot/opt/csw/lib/libunistring.so -> libunistring.so.2.0.0
> 
> while the existing:
> /opt/csw/lib/libunistring.so -> libunistring.so.0.1.2
> 
> a bit strange that with a minor revision we jump from 0.1 to 2.0! but?

This happens when people don?t understand the soname versioning:
  https://autotools.io/libtool/version.html

> May I update the package without issues? or would you suggest a respin of the older? I don't want to cause havoc.
> I would also rename the packahe from libunistring0 to libunistring2 of course.

Always look for reverse deps! It is just Guild, so just respin.


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/20151015/7de13218/attachment.p7s>

From rmottola at opencsw.org  Thu Oct 15 15:53:53 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 15 Oct 2015 15:53:53 +0200
Subject: libunistring update / soname update
In-Reply-To: <8D5C0DA1-7C0B-4704-A8A1-7CD4232405F0@opencsw.org>
References: <561FAA65.1040007@opencsw.org>
	<8D5C0DA1-7C0B-4704-A8A1-7CD4232405F0@opencsw.org>
Message-ID: <561FAFF1.6020902@opencsw.org>

Hi,

Dagobert Michelsen wrote:

> This happens when people don?t understand the soname versioning:
>    https://autotools.io/libtool/version.html
>
>> May I update the package without issues? or would you suggest a respin of the older? I don't want to cause havoc.
>> I would also rename the packahe from libunistring0 to libunistring2 of course.
>
> Always look for reverse deps! It is just Guild, so just respin.
>

wait - I intended "respin" to rebuld the current version.

Do you mean that or should I proceed to make a libunistring2 package?
I suppose that in that case I also need to make a "obsoletes", right?


Thanks,

Riccardo

From dam at opencsw.org  Thu Oct 15 17:11:03 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 15 Oct 2015 17:11:03 +0200
Subject: libunistring update / soname update
In-Reply-To: <561FAFF1.6020902@opencsw.org>
References: <561FAA65.1040007@opencsw.org>
	<8D5C0DA1-7C0B-4704-A8A1-7CD4232405F0@opencsw.org>
	<561FAFF1.6020902@opencsw.org>
Message-ID: <E762A5CE-4A57-484F-A21C-14BEC1B84EB7@opencsw.org>

Hi Ricardo,

Am 15.10.2015 um 15:53 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> This happens when people don?t understand the soname versioning:
>>   https://autotools.io/libtool/version.html
>> 
>>> May I update the package without issues? or would you suggest a respin of the older? I don't want to cause havoc.
>>> I would also rename the packahe from libunistring0 to libunistring2 of course.
>> 
>> Always look for reverse deps! It is just Guild, so just respin.
>> 
> 
> wait - I intended "respin" to rebuld the current version.
> 
> Do you mean that or should I proceed to make a libunistring2 package?

Just bump to libunistring2.

> I suppose that in that case I also need to make a "obsoletes", right?

What do you want to obsolete? This is a new SONAME, hence new package name.
I see no obsoletion here.


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/20151015/d87f4e7e/attachment-0001.p7s>

From rmottola at opencsw.org  Fri Oct 16 10:24:27 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 16 Oct 2015 10:24:27 +0200
Subject: libunistring update / soname update
In-Reply-To: <E762A5CE-4A57-484F-A21C-14BEC1B84EB7@opencsw.org>
References: <561FAA65.1040007@opencsw.org>
	<8D5C0DA1-7C0B-4704-A8A1-7CD4232405F0@opencsw.org>
	<561FAFF1.6020902@opencsw.org>
	<E762A5CE-4A57-484F-A21C-14BEC1B84EB7@opencsw.org>
Message-ID: <5620B43B.3050603@opencsw.org>

Hi,

Dagobert Michelsen wrote:
> What do you want to obsolete? This is a new SONAME, hence new package name.
> I see no obsoletion here.
>

I thought the -dev package. Howver, I got no conflicts.

Riccardo


From dam at opencsw.org  Fri Oct 16 14:32:07 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 16 Oct 2015 14:32:07 +0200
Subject: libunistring update / soname update
In-Reply-To: <5620B43B.3050603@opencsw.org>
References: <561FAA65.1040007@opencsw.org>
	<8D5C0DA1-7C0B-4704-A8A1-7CD4232405F0@opencsw.org>
	<561FAFF1.6020902@opencsw.org>
	<E762A5CE-4A57-484F-A21C-14BEC1B84EB7@opencsw.org>
	<5620B43B.3050603@opencsw.org>
Message-ID: <ABA2C6B2-E1BF-4B82-83A2-7E6200C80688@opencsw.org>

Hi Riccardo,

Am 16.10.2015 um 10:24 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Dagobert Michelsen wrote:
>> What do you want to obsolete? This is a new SONAME, hence new package name.
>> I see no obsoletion here.
> 
> I thought the -dev package. Howver, I got no conflicts.

This is because the library just has a new soname. You are replacing the
existing -dev package, why should there be a collision? You don?t keep
the old dev-package. This would only be the case when it would be possible
to have two development versions at the same time.


Best regards

  ? Dago

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

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

From rmottola at opencsw.org  Fri Oct 16 18:22:14 2015
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 16 Oct 2015 18:22:14 +0200
Subject: guile / unistr int8 types solaris 9
In-Reply-To: <5616ABBB.6060803@opencsw.org>
References: <5616ABBB.6060803@opencsw.org>
Message-ID: <56212436.6070904@opencsw.org>

Hi,

does someone have a clue on how to fix this? and if the fix can actually 
be done in guile itself.
I hoped that a new and rebuilt version of unistr would help, but it jsut 
shifted the problem of 1 line.

In file included from ../lib/stdint.h:78:0,
                  from ../libguile/scmconfig.h:24,
                  from ../libguile/__scm.h:54,
                  from ../libguile/_scm.h:68,
                  from chars.c:31:
/opt/csw/lib/gcc/sparc-sun-solaris2.9/4.6.4/include/stdint.h:34:23: 
error: conflicting types for 'unistring_int8_t'
/opt/csw/include/unistring/stdint.h:106:21: note: previous declaration 
of 'unistring_int8_t' was here


What I do not understand is how a "gcc" header stdint.h can conflict 
with something in another library... when this has a private name, that 
is unistring_int8_t? In gcc it has the "standard" name:
  line 34 is in fact:

typedef __INT8_TYPE__ int8_t;


Riccardo


From grzemba at contac-dt.de  Wed Oct 21 13:43:06 2015
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Wed, 21 Oct 2015 13:43:06 +0200
Subject: AP2_MOD magic
Message-ID: <beed88486b46.5627966a@contac-dt.de>

Hi Ben,

I like to package PHP 5.6 for Apache24. After some fight against the resurrection of the directory /opt/csw/apache2 I found out that in gar is a AP2_MOD magic implemented ;)

Do you think that is still contemporary? Should we create an similar AP24_MOD magic?

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