Carsten Grzemba | 25 Nov 15:45 2015

mgar branch v2-ips

I like to  contribute some things for IPS and I wondering is v2-ips the last version and can I commit in this branch.


Carsten Grzemba | 13 Nov 12:23 2015

next Camp

Hi folks,

A beautiful summer
has passed. Have anyone an idea for next (winter) camp location?


Carsten Grzemba | 10 Nov 08:25 2015

unstable10x out of space


Can anyone remove the /tmp/build directory on unstable10x

cgrzemba <at> unstable10x:~$ du -sh /tmp/build
 1.3G   /tmp/build
cgrzemba <at> unstable10x:~$ ls -ld /tmp/build
drwxrwxr-x   7 rubyci   csw          531 Jul 31 07:20 /tmp/build


Carsten Grzemba | 6 Nov 10:01 2015

PHP 56 packages

I have packaged PHP 5.6.13 with a mod_php for Apache24 and it works for me for an canto CMS setup.
Shoud we still deliver a mod_php for Apache22?
Is it reasonable to replace the PHP 5.3 package or should we keep this in repository and publish new php56 packages?

Carsten Grzemba | 5 Nov 12:38 2015

OSQA community

Hi folks,

it is some time ago where I have migrated the Google login to oauth2. The login works, unfortunately it does not map the new oauth tokens to the existing logins. So I recommend how whats access to OSQA again, should re register with an new (similar) login name. After that I can copy the new authkey in the previous account and the delete the new login again. Then it should be possible to login with the old login and the new Google oauth2 API and nobody loose the references the the existing threads.


Laurent Blume | 4 Nov 10:11 2015

MySQL issues on Solaris 11/sparc

Hello all,

Dagobert has pointed out that the MySQL packages don't work on Solaris
11/sparc, failing with this error:

This seems t151104  9:56:09 [Note] /opt/csw/libexec/mysqld (mysqld
5.5.46) starting as process 19236 ...
151104  9:56:09 [ERROR] Initialization of transaction delegates failed.
Please report a bug.
151104  9:56:09 [ERROR] Aborting

o be a known bug about which Oracle does not give much of a shit, since
they provide a magical «fix», but no solution.!topic/dimstat/596RKYcVPIQ!topic/dimstat/GiewfGElRZk

The workaround is to use the MySQL 5.6 package in 64 mode. Edit or
create /etc/opt/csw/csw.conf after installing it, and add this line:

I'll make it use 64 bit as default instead of the historical 32 in a respin.
MySQL 5.5 32 bit, MySQL 5.5 64 bit, MySQL 5.6 32 bit, all have the same
issue on Solaris 11/sparc exclusively.

I will not investigate further. If somebody wants to, you're welcome to it.



Carsten Grzemba | 21 Oct 13:43 2015

AP2_MOD magic

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?


Riccardo Mottola | 15 Oct 15:30 2015

libunistring update / soname update


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/ ->

while the existing:
/opt/csw/lib/ ->

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 

Current maintainer would be Dago!


Riccardo Mottola | 8 Oct 19:45 2015

guile / unistr int8 types solaris 9


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:
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 

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 Mottola | 2 Oct 19:19 2015

New Nettle (because of gnutls)


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 Mottola | 1 Oct 19:56 2015

gnutls 3 round 2

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 
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:
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?