Romeo Theriault | 31 Oct 00:41 2014

Process to hand over maintenance of packages?

Hello, I was (still am?) the maintainer of the pysalt and a few of it's dependencies. (zeromq, msgpack, etc...) I haven't been keeping them up to date since my organization ended up not using salt for configuration management. I have someone, Bill Ramthun, who is interested in taking over the maintenance of these packages. What is the proper procedure that we should follow to allow this to happen?

Thank you,
Romeo
Dagobert Michelsen | 30 Oct 10:25 2014

Update of the buildfarm

Hi folks,

I will be updating the buildfarm today which requires downtime. Please stand by.

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

Attachment (smime.p7s): application/pkcs7-signature, 3266 bytes
rupert THURNER | 28 Oct 07:52 2014

Fwd: [CMake 0015219]: cmake does not compile any more since 3.0.0

Fyi, how should we handle this?

---------- Forwarded message ----------
From: "Mantis Bug Tracker" <mantis-61JfyZBJ/oEzbFkASNGCRdBPR1lH4CV8@public.gmane.org>
Date: Oct 27, 2014 2:03 PM
Subject: [CMake 0015219]: cmake does not compile any more since 3.0.0
To: <rupert.thurner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc:


A NOTE has been added to this issue.
======================================================================
http://www.cmake.org/Bug/view.php?id=15219
======================================================================
Reported By:                rupert
Assigned To:
======================================================================
Project:                    CMake
Issue ID:                   15219
Category:                   Development
Reproducibility:            always
Severity:                   block
Priority:                   low
Status:                     new
======================================================================
Date Submitted:             2014-10-26 03:27 EDT
Last Modified:              2014-10-27 09:03 EDT
======================================================================
Summary:                    cmake does not compile any more since 3.0.0
Description:
hi, i am trying to package cmake for opencsw, and i am unsure what got changed
in 3.0.0 to not make it compile any more. maybe also our buildsystem is guilty.

"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.h",
line 394: syntax error before or at: data_ahead
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.h",
line 394: warning: old-style declaration or incorrect type for: data_ahead
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.h",
line 395: warning: old-style declaration or incorrect type for: data_behind
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h",
line 124: warning: no explicit type given
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h",
line 124: syntax error before or at: _nc_Copy_Type
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h",
line 124: warning: old-style declaration or incorrect type for: _nc_Copy_Type
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h",
line 132: warning: no explicit type given
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h",
line 132: syntax error before or at: _nc_Internal_Validation
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h",
line 132: warning: old-style declaration or incorrect type for:
_nc_Internal_Validation
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c",
line 71: improper member use: status
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c",
line 72: improper member use: makearg
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c",
line 73: improper member use: copyarg
"/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c",
line 74: improper member use: freearg
cc: acomp failed for
/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c
Source/CursesDialog/form/CMakeFiles/cmForm.dir/build.make:54: recipe for target
'Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o' failed
gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error
2
gmake[2]: Leaving directory
'/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2'
CMakeFiles/Makefile2:1665: recipe for target
'Source/CursesDialog/form/CMakeFiles/cmForm.dir/all' failed
gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2
gmake[1]: Leaving directory
'/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2'
Makefile:147: recipe for target 'all' failed
gmake: *** [all] Error 2
gmake: Leaving directory
'/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2'
/home/rupert/opencsw/.buildsys/v2/gar//gar.lib.mk:874: recipe for target
'build-work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Makefile' failed
gmake[1]: ***
[build-work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Makefile] Error 2
gmake[1]: Leaving directory '/home/rupert/opencsw/cmake/trunk'
gar/gar.mk:198: recipe for target 'merge-isa-pentium_pro' failed
gmake: *** [merge-isa-pentium_pro] Error 2

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015166 cc: acomp failed for Source/CursesDialo...
======================================================================

----------------------------------------------------------------------
 (0037073) Brad King (manager) - 2014-10-27 09:03
 http://www.cmake.org/Bug/view.php?id=15219#c37073
----------------------------------------------------------------------
See http://www.cmake.org/Bug/view.php?id=15166#c36840.  Basically we need
someone to submit a nightly testing build following instructions here:

 http://www.cmake.org/Wiki/CMake/Git/Dashboard

One can bootstrap first with -DBUILD_CursesDialog=OFF to get a ctest capable of
submitting the nightly build.

Issue History
Date Modified    Username       Field                    Change
======================================================================
2014-10-26 03:27 rupert         New Issue
2014-10-27 09:00 Brad King      Relationship added       related to 0015166
2014-10-27 09:03 Brad King      Note Added: 0037073
======================================================================

Riccardo Mottola | 23 Oct 19:10 2014

problems when building gnustep base on intel

Hi,

I am trying to build gnustep base on solaris 10 x86 (because it was 
suggested to use intel to check dependencies and well, it needs to work 
anyway

On that 10x, I get this problem, during configure:
checking ffi.h usability... yes
checking ffi.h presence... yes
checking for ffi.h... yes
checking for forwarding callback in runtime... yes
checking FFI library usage... configure: error: The ffi library (libffi) 
does not appear to be working.  Perhaps it's missing or you need a more 
recent version.  Version 3.0.9 or later should work, and you can find a 
link to it n the list of packages for download at 
http://www.gnustep.org/resources/sources.html
Makefile:60: recipe for target 'configure-sourcegs' failed

it says:
configure:10307: checking FFI library usage
configure:10328: /opt/csw/bin/gcc-4.9 -o conftest -O2 -pipe -m32 
-march=pentiumpro -I/opt/csw/include -I/opt/csw/GNUstep/Local
/Library/Headers -I/opt/csw/GNUstep/Local/Library/Headers 
-I/opt/csw/GNUstep/System/Library/Headers -I/opt/csw/include -m32
-march=pentiumpro -L/opt/csw/lib 
-L/opt/csw/GNUstep/Local/Library/Libraries 
-L/opt/csw/GNUstep/Local/Library/Libraries -L/opt/
csw/GNUstep/System/Library/Libraries conftest.c -L/opt/csw/lib/ffi 
-lffi   -lnsl -lrt -ldl  -lpthread -lz >&5
configure:10328: $? = 0
configure:10328: ./conftest
./configure: line 1865: 29082 Segmentation Fault      (core dumped) 
./conftest$ac_exeext
configure:10328: $? = 139
configure: program exited with status 139

I tried to simulate this by compiling the test with a similar command line:
/opt/csw/bin/gcc-4.9 -O2 -pipe -m32 -march=pentiumpro -I/opt/csw/include 
-I/opt/csw/GNUstep/Local/Library/Headers 
-I/opt/csw/GNUstep/Local/Library/Headers 
-I/opt/csw/GNUstep/System/Library/Headers -I/opt/csw/include 
-L/opt/csw/lib -L/opt/csw/GNUstep/Local/Library/Libraries 
-L/opt/csw/GNUstep/Local/Library/Libraries 
-L/opt/csw/GNUstep/System/Library/Libraries  -L/opt/csw/lib/ffi -lffi   
-lnsl -lrt -ldl  -lpthread -lz config.ffi.c

and indeed running a.out gets a segfault.

The trace is not very useful...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfef74204 in ffi_closure_SYSV_inner () from /opt/csw/lib/libffi.so.5
(gdb) bt
#0  0xfef74204 in ffi_closure_SYSV_inner () from /opt/csw/lib/libffi.so.5
#1  0xfef74542 in ffi_closure_SYSV () from /opt/csw/lib/libffi.so.5
#2  0x08050ff7 in main ()

The box, which is not mine, has:
application CSWlibffi-dev                    libffi_dev - A portable 
foreign function interface library - developer package
application CSWlibffi4                       libffi4 - The GNU Compiler 
Collection, libffi.so.4
application CSWlibffi5                       libffi5 - A portable 
foreign function interface library - libffi.so.5

the latter seems to be used. (CSW are the OpenCSW packages).

Any clues?

On solaris 10 SPARC configure ends successfully.

Riccardo

Oliver Kiddle | 16 Oct 11:45 2014

terminfo entries for rxvt-unicode

I've just updated the build recipes in gar for rxvt-unicode. It does now
build but the lack of terminfo entries for it means that it remains
fairly useless. Even without a Solaris package, terminfo entries would
be really useful just because I tend to use rxvt-unicode on Linux and
ssh to a Solaris box. Ideally, they should be in CSWterminfo. I've had
trouble getting them to work. They are available under doc/etc in the
rxvt-unicode source tarball.

Is anyone able to get them working? How should we package them?

Oliver

Maciej (Matchek) Bliziński | 13 Oct 14:26 2014

Removing stale packages

We have a stale package report:

http://buildfarm.opencsw.org/obsolete-pkgs/stale-packages.html

It is updated once every 24h. You can see that there is a number of
packages which have not been updated for 4 years or more. Sometimes
the upstream development stops, so there's nothing new to release, but
this only applies to a small fraction of software projects. Many
upstream projects are active, but corresponding packages are not
updated. Dropping old packages has been debated in the past, and the
main points were:

- Keeping old/stale packages can be good, because they can be useful to someone.
- Keeping old/stale packages can be bad, because they are often
unused, untested, somebody tries to use them, they don't work, and
people think that if one package is broken, most of packages are.

- Deleting old/stale packages can be bad, because we take away
packages that could be potentially useful to someone.
- Deleting old/stale packages can be good, because when a package is
not there, potential new maintainers are motivated to rebuild/update
them. As a backup, allpkgs still contains all of the old packages in
case somebody has their back against the wall.

In previous years we've put more weight on the upsides of keeping old
packages, but I'd like to emphasize the negatives, and suggest that
hoarding really hurts us. We would be better off deleting as many old,
unmaintained packages as possible. It would help us if we had an
equivalent of Debian popcon, but this has been attempted and wasn't
deployed. I don't think we have resources to do that. Maybe instead,
we can do something simple, like getting the list of packages that can
be deleted (already exists in the stale packages report), and creating
an internet poll, where people could mark packages they use / care
about. (Note: only packages with no reverse dependencies would be
listed.) We would circulate the poll around users <at>  and announce <at> , and
after two weeks or so of collecting the data, we would drop packages
that nobody cares about. All of this is easy to do.

Thoughts?

Maciej

Maciej (Matchek) Bliziński | 10 Oct 12:58 2014

Boost and GCC

Hello Maintainers,

I heard unfavorable opinions about /opt/csw/gxx. Our general direction is to switch to GCC and build C++ libraries into /opt/csw. Boost is one of the biggest C++ libraries we have. Do we want to move it to /opt/csw?

Maciej
Dagobert Michelsen | 10 Oct 09:40 2014

Re: New package request : fdupes

Hi Laurent,

Am 10.10.2014 um 09:27 schrieb Laurent Blume via pkgrequests <pkgrequests@...>:
> Le 2014/10/10 08:48 +0200, Dagobert Michelsen Via Pkgrequests a écrit:
>> There is also samefile:
>>   http://www.opencsw.org/packages/samefile/
> 
> This one appears to be in need of a recipe...

Yes, it is the only package from Othmar Wigger who is a founding member of OpenCSW.
It fact it is a program from the obfuscated C contest and he only submitted it
because the initial rule was at least one maintained package. He always was more
kind of a moral supporter and advocate of OpenCSW :-)

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

Attachment (smime.p7s): application/pkcs7-signature, 3267 bytes
Carsten Grzemba | 2 Oct 08:24 2014
Picon

ld: fatal: relocations remain against allocatable but non-writable sections -- on linking dtrace probes

I have seen on different projects (TCL, PHP, ...) that there are problems to link dtrace userland probes on Solaris. The problem is that the linker complains if it has to link the dtrace compiled object with gcc compiled PIC objects (position independent code).
Now I have the problem if I attempt to add dtrace probes in Python.

Has anybody a solution for this problem?
<at> Laurent: Do you has the dtrace support now in TCL8?

Jan Holzhueter | 29 Sep 11:52 2014

Linker Problem on Sparc Servers. (after Kernel update)

Hi,
maybe I missed it during my vacation.
But looks like Oracle fixed something in that area:

https://support.oracle.com/epmos/faces/BugDisplay?_afrLoop=189010529288142&id=18175522&_afrWindowMode=0&_adf.ctrl-state=m8erilfzj_153

Bug 18175522 : WITH 147147-26 -ZIGNORE WRONGLY KEEPS LIBRARIES FOR
DEPENDENCY COMPENSATION

Thats patched with latest Kernel:

150400-16.

Maybe it's worth a try.

Yann did you ever hear back from them about the case you opened?

Greetings
Jan

Carsten Grzemba | 29 Sep 09:03 2014
Picon

Re: Mysql hickups. (was The Python web apps throw 500s)


Am 26.09.14 schrieb Laurent Blume <laurent <at> opencsw.org>:
I will look into it.
For now, be careful that I'm going to push a new package that will overwrite it (now that MySQL works, the MySQL packages could be created :-)

My first idea is that it could be handled automatically, following this rough outline:
  - CSW package installs cswservice:default
  - users can create cswservice:otherinstance if they wish
  - on package removal, cswservice:* are handled by CAS (instead of just the :default)
  - so on updates, all are stopped/restarted. Only :default is updated, the others stay of course the responsibility of their creators

Makes sense?
Yes, this sounds good.


Laurent

Le 2014/09/26 16:15 +0200, Carsten Grzemba a écrit:
>mysql trac is online again.
>
>I have changed /etc/opt/csw/init.d/cswmysql5 for support instances:
>
>root <at> mysql [mysql]:/etc/opt/csw/init.d > diff cswmysql5.org cswmysql5
>41c41,42
>< datadir=
>---
> > datadir=`/bin/svcprop -p config/datadir ${SMF_FMRI} 2>/dev/null`
> > defaults=`/bin/svcprop -p config/defaults ${SMF_FMRI} 2>/dev/null`
>293a295,299
> > if [ ! -z "$defaults" ]
> > then
> >     defaults_args="--defaults-file=$defaults"
> >     extra_args="$defaults_args $extra_args"
> > fi
>323c329
><       $bindir/mysqld_safe --datadir="$datadir"
>--pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 &
>---
> >       $bindir/mysqld_safe $defaults_args --datadir="$datadir"
>--pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 &
>
>I don't if it is the best place for do this but this kind is a usual way.
> <at> Laurent: what do you mean, would you incorporate this script change in
>your package?
>
>Am 26.09.14 schrieb *Jan Holzhueter * <jh <at> opencsw.org>:
>>Hi,
>>had some time to debug it :)
>>
>>Simple problem someone somehow updated the mysql Packege on our mysql
>>zone.
>>
>>That caused an update from Mysql Version 5.0 to 5.5 (all praise whom
>>they like that this did not cause any database problems )
>>
>>But with this the my.cnf file moved from /opt/csw/mysql5 to /etc/opt/csw
>>but without any migration script. So some default was loaded with did
>>not fit our environment. I fixed that now.
>>It should not give those errors anymore I hope.
>>
>> <at> Carsten your mysql trac database needs to be looked at. To do the
>>update the cswmysql5:trac Service is broken now and starts not your
>>database anymore. I disabled it for now. If you have the time please
>>fix it.
>>
>>Greetings
>>Jan
>>
>>




Gmane