From grzemba at contac-dt.de  Thu Oct  2 08:24:04 2014
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Thu, 02 Oct 2014 08:24:04 +0200
Subject: ld: fatal: relocations remain against allocatable but non-writable
	sections -- on linking dtrace probes
In-Reply-To: <bbb2c0f2c43.542cef6b@contac-dt.de>
References: <bbb2f6fe7dec.542cedc5@contac-dt.de>
	<bbb2d62a5d2d.542cee01@contac-dt.de>
	<bbb2b22945d9.542cee3e@contac-dt.de>
	<bbb2d61744ac.542cee7a@contac-dt.de>
	<bbb2bd0a773c.542ceeb6@contac-dt.de>
	<bbb2d5781950.542ceef2@contac-dt.de>
	<bbb2f2675a12.542cef2e@contac-dt.de>
	<bbb2c0f2c43.542cef6b@contac-dt.de>
Message-ID: <bbb2d40e3c4c.542d0ba4@contac-dt.de>

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?
@Laurent: Do you has the dtrace support now in TCL8?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141002/bdf300d8/attachment.html>

From laurent at opencsw.org  Thu Oct  2 10:37:28 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 02 Oct 2014 10:37:28 +0200
Subject: ld: fatal: relocations remain against allocatable but non-writable
	sections -- on linking dtrace probes
In-Reply-To: <bbb2d40e3c4c.542d0ba4@contac-dt.de>
References: <bbb2f6fe7dec.542cedc5@contac-dt.de>	<bbb2d62a5d2d.542cee01@contac-dt.de>	<bbb2b22945d9.542cee3e@contac-dt.de>	<bbb2d61744ac.542cee7a@contac-dt.de>	<bbb2bd0a773c.542ceeb6@contac-dt.de>	<bbb2d5781950.542ceef2@contac-dt.de>	<bbb2f2675a12.542cef2e@contac-dt.de>	<bbb2c0f2c43.542cef6b@contac-dt.de>
	<bbb2d40e3c4c.542d0ba4@contac-dt.de>
Message-ID: <542D0EC8.8080900@opencsw.org>

Le 2014/10/02 08:24 +0200, Carsten Grzemba a ?crit:
> 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?
> @Laurent: Do you has the dtrace support now in TCL8?



I merely dusted off the recipe at the time because I had a specific 
need, but I've not done any effort to improve it. I'm not a TCL user myself.

Laurent

From dam at opencsw.org  Fri Oct 10 09:40:13 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 10 Oct 2014 09:40:13 +0200
Subject: New package request : fdupes
In-Reply-To: <54378A49.3000805@opencsw.org>
References: <201410081844.s98IiUDx011705@www.opencsw.org>	<201410091126.s99BQrQj021967@login.bo.opencsw.org>
	<320321A8-DF36-4302-91D5-F89A98A3066A@opencsw.org>
	<54378A49.3000805@opencsw.org>
Message-ID: <26AA1DEB-80AE-490A-9801-63654D3FBF67@opencsw.org>

Hi Laurent,

Am 10.10.2014 um 09:27 schrieb Laurent Blume via pkgrequests <pkgrequests at lists.opencsw.org>:
> 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

-------------- 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/20141010/d9cdce8a/attachment-0001.p7s>

From maciej at opencsw.org  Fri Oct 10 12:58:10 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 10 Oct 2014 11:58:10 +0100
Subject: Boost and GCC
Message-ID: <CALtRa-56ZCmwi2j3TgYdbfy6qZOpBrWTFnQNH0SR5cJCD=_Z7Q@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141010/0a3359ab/attachment.html>

From laurent at opencsw.org  Fri Oct 10 14:23:55 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Fri, 10 Oct 2014 14:23:55 +0200
Subject: Boost and GCC
In-Reply-To: <CALtRa-56ZCmwi2j3TgYdbfy6qZOpBrWTFnQNH0SR5cJCD=_Z7Q@mail.gmail.com>
References: <CALtRa-56ZCmwi2j3TgYdbfy6qZOpBrWTFnQNH0SR5cJCD=_Z7Q@mail.gmail.com>
Message-ID: <5437CFDB.1090409@opencsw.org>

Le 2014/10/10 12:58 +0200, Matchek a ?crit:
> 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?

I see there is a libpcre.so there, wouldn't that conflict?

I'm glad of the move to GCC, but I'm reluctant to do it in a way that 
would be a problem for people who need to build stuff with Studio, 
whether fully in OpenCSW or not.

I was trying to build MySQL 5.7, which uses boost, and apparently it 
could pick it up in its current location (albeit not use it, too old).

So I'd keep it that way unless there's a significant issue (ie, not ?it 
doesn't look cool?).

Laurent



From maciej at opencsw.org  Mon Oct 13 14:26:12 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 13 Oct 2014 13:26:12 +0100
Subject: Removing stale packages
Message-ID: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>

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@ and announce@, 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

From laurent at opencsw.org  Mon Oct 13 14:33:31 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Mon, 13 Oct 2014 14:33:31 +0200
Subject: Removing stale packages
In-Reply-To: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>
References: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>
Message-ID: <543BC69B.6090809@opencsw.org>

Le 2014/10/13 14:26 +0200, Matchek a ?crit:
> - 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.

I somewhat disagree on just that point. If a stale package is not a 
blocking dependency for another, and has no overly sensitive breakage 
(eg security), I think it's better to keep it.

In my view, it's psychologically easier to get somebody to fix something 
already present than if they have the feeling they start from scratch 
(even though the actual work here is often the same if there is no recipe).
Maybe because they can see it has worked in the past, so they can do it 
again?

Laurent

From maciej at opencsw.org  Mon Oct 13 14:42:48 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 13 Oct 2014 13:42:48 +0100
Subject: Removing stale packages
In-Reply-To: <543BC69B.6090809@opencsw.org>
References: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>
	<543BC69B.6090809@opencsw.org>
Message-ID: <CALtRa-6d3HjjskVgn828ewCxgJcF26CtwxoatRyXgx==tJEx0g@mail.gmail.com>

2014-10-13 13:33 GMT+01:00 Laurent Blume <laurent at opencsw.org>:
> I somewhat disagree on just that point. If a stale package is not a blocking
> dependency for another, and has no overly sensitive breakage (eg security),
> I think it's better to keep it.
>
> In my view, it's psychologically easier to get somebody to fix something
> already present than if they have the feeling they start from scratch (even
> though the actual work here is often the same if there is no recipe).
> Maybe because they can see it has worked in the past, so they can do it
> again?

Yes, I see what you mean. What we would want to signal to people is
that there is nobody taking care of this package and there will not be
anybody caring about this package, unless they do it. Package not being
in the catalog does send that message (I hope).

Which approach works better, should be possible to determine
empirically, but I don't have a good idea how. Maybe looking at the
past. Around 2010/2011 we had an influx of new people taken on the
project, followed by most of them not releasing any packages ever.
We've done some package cleanups, and there wasn't much reaction
either. I got contacted once about "why was this package removed?",
and it did not result in a new maintainer joining the project, so I
only have depressing examples for both approaches.

Maciej

From laurent at opencsw.org  Mon Oct 13 15:22:42 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Mon, 13 Oct 2014 15:22:42 +0200
Subject: Removing stale packages
In-Reply-To: <CALtRa-6d3HjjskVgn828ewCxgJcF26CtwxoatRyXgx==tJEx0g@mail.gmail.com>
References: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>	<543BC69B.6090809@opencsw.org>
	<CALtRa-6d3HjjskVgn828ewCxgJcF26CtwxoatRyXgx==tJEx0g@mail.gmail.com>
Message-ID: <543BD222.5000902@opencsw.org>

Le 2014/10/13 14:42 +0200, Matchek a ?crit:
> Yes, I see what you mean. What we would want to signal to people is
> that there is nobody taking care of this package and there will not be
> anybody caring about this package, unless they do it. Package not being
> in the catalog does send that message (I hope).

I'm afraid the message is too direct: ?go away, nothing for you here?. 
Considering the requests, few people look long for a solution.

> Which approach works better, should be possible to determine
> empirically, but I don't have a good idea how. Maybe looking at the
> past. Around 2010/2011 we had an influx of new people taken on the
> project, followed by most of them not releasing any packages ever.
> We've done some package cleanups, and there wasn't much reaction
> either. I got contacted once about "why was this package removed?",
> and it did not result in a new maintainer joining the project, so I
> only have depressing examples for both approaches.

Look, there are no two ways around the facts: Solaris is a dying platform.
S10 has less than 4 years left. Anecdotal evidence shows that it is used 
more and more as a kind of sadistic punishment to people with no 
sufficient skill to administer it properly, let alone build stuff on it. 
S11 is becoming an appliance, and anyway, at this point, its unsupported 
FOSS is still good enough (yes, it will be completely rotten in a few 
years, just like for S10, but that will take time to sink in: many 
people actually believe Oracle supports all that stuff, poor souls).

It won't get better, and sooner or later, we'll all have to find other 
hobbies. Unless maybe we get to the COBOL situation where some companies 
are forced to pay insane amounts to train people to keep using legacy 
systems. But I doubt it, it's not that irreplaceable.

Laurent

From pfelecan at opencsw.org  Tue Oct 14 19:41:50 2014
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 14 Oct 2014 19:41:50 +0200
Subject: Removing stale packages
In-Reply-To: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon,
	13 Oct 2014 13:26:12 +0100")
References: <CALtRa-7B=Zp-ua2mRTgZ8yqMn4ai9SoCy2b0GQhMiB-cErehTg@mail.gmail.com>
Message-ID: <x6ppdu7dlt.fsf@opencsw.org>

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

> [...] 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@ and announce@, 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.

It's probably a good strategy although I'm agreeing with Laurent's
opinion(s).

Maybe, before doing that we should consider an internal poll to
decide. The question should be quite simple: "are you for or against
removing from the catalog stale packages, not having reverse
dependencies not candidates for removal, older than Y years?" where Y
should be determined beforehand.

What do you think as good value for Y?

As a last note, the recipe must be preserved for a removed package, thus
somebody can resurrect it if wished.
-- 
Peter

From opk at opencsw.org  Thu Oct 16 11:45:56 2014
From: opk at opencsw.org (Oliver Kiddle)
Date: Thu, 16 Oct 2014 11:45:56 +0200 (CEST)
Subject: terminfo entries for rxvt-unicode
Message-ID: <201410160945.s9G9juQh013470@login.bo.opencsw.org>

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

From maciej at opencsw.org  Thu Oct 16 12:48:15 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 16 Oct 2014 11:48:15 +0100
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
Message-ID: <CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>

2014-10-16 10:45 GMT+01:00 Oliver Kiddle <opk at opencsw.org>:
> 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 agree. A modular and easy for us way would be to create
CSWterminfo-rxvt-unicode and make CSWterminfo depend on it.

Maciej

From opk at opencsw.org  Thu Oct 16 23:12:59 2014
From: opk at opencsw.org (Oliver Kiddle)
Date: Thu, 16 Oct 2014 23:12:59 +0200 (CEST)
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
Message-ID: <201410162112.s9GLCx3R017975@login.bo.opencsw.org>

Maciej wrote:
> I agree. A modular and easy for us way would be to create
> CSWterminfo-rxvt-unicode and make CSWterminfo depend on it.

Ok. I've done that and put CSWterminfo-rxvt-unicode in experimental.
Does it look right? If I redo CSWterminfo with the extra dependency, can
I upload that without the rest of ncurses or would that cause problems?
Or would the ncurses maintainer (Dago?) prefer that I leave it to them?

The rxvt-unicode package also seems to create a stub to obsolete an old
CSWurxvt package. Is that still needed if I upload CSWrxvt-unicode. I
can't find any CSWrxvt-unicode or CSWurxvt in any of the past stable
releases though it seems to have been in gar since 2009.

Currently, it is only building without support for the perl plugins
which is a bit of a pity. Any help with getting that to work would be
appreciated.

Also, on the subject of ncurses, the comment at the top of the Makefile
for it suggests linking to libtinfo5 but we don't seem to have that
library. It perhaps needs configure --with-termlib. Does the transition
scheme perhaps not work so well for us due to Solaris direct binding?
The comment has a link that can't be read without an account signup but
I'm assuming it is probably similar to this:
  https://enc.com.au/2011/09/30/ncurses-library-split/

Oliver

From dam at opencsw.org  Fri Oct 17 09:29:40 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 17 Oct 2014 09:29:40 +0200
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <201410162112.s9GLCx3R017975@login.bo.opencsw.org>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
	<201410162112.s9GLCx3R017975@login.bo.opencsw.org>
Message-ID: <CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>

Hi Oliver,

Am 16.10.2014 um 23:12 schrieb Oliver Kiddle <opk at opencsw.org>:
> Maciej wrote:
>> I agree. A modular and easy for us way would be to create
>> CSWterminfo-rxvt-unicode and make CSWterminfo depend on it.
> 
> Ok. I've done that and put CSWterminfo-rxvt-unicode in experimental.
> Does it look right? If I redo CSWterminfo with the extra dependency, can
> I upload that without the rest of ncurses or would that cause problems?
> Or would the ncurses maintainer (Dago?) prefer that I leave it to them?

No, please go ahead. Where is CSWterminfo-rxvt-unicode built from?
I suggest you just rebuild and update ncurses and push it, I tend to
like giving away maintainership for packages :-)

> The rxvt-unicode package also seems to create a stub to obsolete an old
> CSWurxvt package. Is that still needed if I upload CSWrxvt-unicode. I
> can't find any CSWrxvt-unicode or CSWurxvt in any of the past stable
> releases though it seems to have been in gar since 2009.
> 
> Currently, it is only building without support for the perl plugins
> which is a bit of a pity. Any help with getting that to work would be
> appreciated.

Just post the issue on maintainers and we see what we can do.

> Also, on the subject of ncurses, the comment at the top of the Makefile
> for it suggests linking to libtinfo5 but we don't seem to have that
> library. It perhaps needs configure --with-termlib. Does the transition
> scheme perhaps not work so well for us due to Solaris direct binding?
> The comment has a link that can't be read without an account signup but
> I'm assuming it is probably similar to this:
>  https://enc.com.au/2011/09/30/ncurses-library-split/

Indeed, the widechar split has been some time ago.


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/20141017/0fffdb36/attachment.p7s>

From opk at opencsw.org  Mon Oct 20 17:01:38 2014
From: opk at opencsw.org (Oliver Kiddle)
Date: Mon, 20 Oct 2014 17:01:38 +0200 (CEST)
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
	<201410162112.s9GLCx3R017975@login.bo.opencsw.org>
	<CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>
Message-ID: <201410201501.s9KF1bp6012837@login.bo.opencsw.org>

On 17 Oct, Dagobert Michelsen wrote:
> 
> No, please go ahead. Where is CSWterminfo-rxvt-unicode built from?
> I suggest you just rebuild and update ncurses and push it, I tend to
> like giving away maintainership for packages :-)

CSWterminfo-rxvt-unicode is built together with rxvt-unicode. This makes
sense because the terminfo sources for it come in the urxvt source
distribution.
I'm not too thrilled to pick up maintainership on common libraries. I'll
upload it but don't wait for me if later work is needed on ncurses.

> > Currently, it is only building without support for the perl plugins
> > which is a bit of a pity. Any help with getting that to work would be
> > appreciated.

I finally got this to build.

It gets compile options by running: $PERL -MExtUtils::Embed -e ccopts
That seems to lack -I/opt/csw/lib/perl/5.10.1/CORE but also used
-xarch=sparc which is for suncc and not g++. Is the lack of the include
perhaps an issue with our perl package?

> >  https://enc.com.au/2011/09/30/ncurses-library-split/
> 
> Indeed, the widechar split has been some time ago.

This is a different split: they separated the curses part from the
terminfo part.

Oliver

From maciej at opencsw.org  Mon Oct 20 18:43:02 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Mon, 20 Oct 2014 17:43:02 +0100
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <201410201501.s9KF1bp6012837@login.bo.opencsw.org>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
	<201410162112.s9GLCx3R017975@login.bo.opencsw.org>
	<CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>
	<201410201501.s9KF1bp6012837@login.bo.opencsw.org>
Message-ID: <CALtRa-6BENojQTVkOKMg6st6WoNwrOkKgGeL8c4s8ZCtRz6v+A@mail.gmail.com>

2014-10-20 16:01 GMT+01:00 Oliver Kiddle <opk at opencsw.org>:
> I'm not too thrilled to pick up maintainership on common libraries.

To all maintainers: Can't we just agree and throw out the concept of
package ownership? It deters people from contributing, and with our
steadily dwindling headcount, deterrence is the last thing we want.

From pfelecan at opencsw.org  Tue Oct 21 19:57:18 2014
From: pfelecan at opencsw.org (Peter FELECAN)
Date: Tue, 21 Oct 2014 19:57:18 +0200
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <CALtRa-6BENojQTVkOKMg6st6WoNwrOkKgGeL8c4s8ZCtRz6v+A@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon,
	20 Oct 2014 17:43:02 +0100")
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
	<201410162112.s9GLCx3R017975@login.bo.opencsw.org>
	<CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>
	<201410201501.s9KF1bp6012837@login.bo.opencsw.org>
	<CALtRa-6BENojQTVkOKMg6st6WoNwrOkKgGeL8c4s8ZCtRz6v+A@mail.gmail.com>
Message-ID: <x6siihgvb5.fsf@opencsw.org>

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

> 2014-10-20 16:01 GMT+01:00 Oliver Kiddle <opk at opencsw.org>:
>> I'm not too thrilled to pick up maintainership on common libraries.
>
> To all maintainers: Can't we just agree and throw out the concept of
> package ownership? It deters people from contributing, and with our
> steadily dwindling headcount, deterrence is the last thing we want.

Agreed. There is only maintenanceship. Anyway, the recipes are
public. The infrastructure is private but with easy access on
request. Lets experiment without ownership.
-- 
Peter

From rmottola at opencsw.org  Thu Oct 23 19:10:37 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 23 Oct 2014 19:10:37 +0200
Subject: problems when building gnustep base on intel
Message-ID: <5449368D.5000401@opencsw.org>

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



From rupert at opencsw.org  Tue Oct 28 07:52:11 2014
From: rupert at opencsw.org (rupert THURNER)
Date: Tue, 28 Oct 2014 07:52:11 +0100
Subject: Fwd: [CMake 0015219]: cmake does not compile any more since 3.0.0
In-Reply-To: <3f094989a187d9417abd7c14fb1e8124@www.cmake.org>
References: <6520a05f8eec83d5e29fe79a7f56ff7e@www.cmake.org>
	<3f094989a187d9417abd7c14fb1e8124@www.cmake.org>
Message-ID: <CAJs9aZ95WmS5eY5ub2Sn1amzyQHsga32m=zrCGVxD5otu6qshg@mail.gmail.com>

Fyi, how should we handle this?
---------- Forwarded message ----------
From: "Mantis Bug Tracker" <mantis at public.kitware.com>
Date: Oct 27, 2014 2:03 PM
Subject: [CMake 0015219]: cmake does not compile any more since 3.0.0
To: <rupert.thurner at gmail.com>
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
======================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141028/e3487530/attachment.html>

From opk at opencsw.org  Wed Oct 29 13:59:46 2014
From: opk at opencsw.org (Oliver Kiddle)
Date: Wed, 29 Oct 2014 13:59:46 +0100 (CET)
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <201410201501.s9KF1bp6012837@login.bo.opencsw.org>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
	<201410162112.s9GLCx3R017975@login.bo.opencsw.org>
	<CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>
	<201410201501.s9KF1bp6012837@login.bo.opencsw.org>
Message-ID: <201410291259.s9TCxkYv017134@login.bo.opencsw.org>

The one thing that is holding me off with finishing rxvt-unicode is that
it appears to have a dependency on CSWintl on sparc only. This makes it
hard to please checkpkg.

I think this comes from the gdk-pixbuf dependency: on either sparc or x86:
  % /opt/csw/bin/pkg-config gdk-pixbuf-2.0 --libs
  -L/opt/csw/lib -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl

libintl is not actually needed but on sparc it appears to include some
static initialisation code that prevents -Wl,-zignore from stripping it.

What's the best way to handle this?

I could patch the configure script to remove -lintl from the checkpkg
output, I could try to find a way to make the dependency conditional in
the Makefile. Or perhaps the gdk_pixbuf package could be changed.

Oliver

From dam at opencsw.org  Wed Oct 29 18:19:06 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 29 Oct 2014 18:19:06 +0100
Subject: terminfo entries for rxvt-unicode
In-Reply-To: <201410291259.s9TCxkYv017134@login.bo.opencsw.org>
References: <201410160945.s9G9juQh013470@login.bo.opencsw.org>
	<CALtRa-7h21gfN5EjQe7hnPsEPVrsP_vaNA3q9tPMwXOKt2i8mw@mail.gmail.com>
	<201410162112.s9GLCx3R017975@login.bo.opencsw.org>
	<CAC40243-0210-43B9-BCAE-C1E1848B99AC@opencsw.org>
	<201410201501.s9KF1bp6012837@login.bo.opencsw.org>
	<201410291259.s9TCxkYv017134@login.bo.opencsw.org>
Message-ID: <3FBBF0AD-F333-4C8D-B080-D4A8F1342100@opencsw.org>

Hi Oliver,

> Am 29.10.2014 um 13:59 schrieb Oliver Kiddle <opk at opencsw.org>:
> 
> The one thing that is holding me off with finishing rxvt-unicode is that
> it appears to have a dependency on CSWintl on sparc only. This makes it
> hard to please checkpkg.
> 
> I think this comes from the gdk-pixbuf dependency: on either sparc or x86:
>  % /opt/csw/bin/pkg-config gdk-pixbuf-2.0 --libs
>  -L/opt/csw/lib -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl
> 
> libintl is not actually needed but on sparc it appears to include some
> static initialisation code that prevents -Wl,-zignore from stripping it.
> 
> What's the best way to handle this?
> 
> I could patch the configure script to remove -lintl from the checkpkg
> output, I could try to find a way to make the dependency conditional in
> the Makefile. Or perhaps the gdk_pixbuf package could be changed.

-z ignore is currently broken on Sparc, I will install the patch hopefully
tomorrow and you can retry. If the issue persists I suggest adding the
dependency and overriding it at the same time. You will get an unnecessary
override on i386 but thats not a problem.


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/20141029/da1fa0df/attachment-0001.p7s>

From dam at opencsw.org  Thu Oct 30 10:25:48 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Oct 2014 10:25:48 +0100
Subject: Update of the buildfarm
Message-ID: <7FAD0F07-2B95-478D-B22E-F8BAE1C7B71E@opencsw.org>

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

-------------- 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/20141030/794d63b7/attachment.p7s>

From maciej at opencsw.org  Thu Oct 30 10:43:05 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 30 Oct 2014 09:43:05 +0000
Subject: Inactive maintainer accounts have been retired
In-Reply-To: <CALtRa-70MuwAhogDhryrU-satHveed4BVj299+cEWgVGDENZ+Q@mail.gmail.com>
References: <CALtRa-70MuwAhogDhryrU-satHveed4BVj299+cEWgVGDENZ+Q@mail.gmail.com>
Message-ID: <CALtRa-6_XxzfCzHXKKDR-7fzFBz11jqCUqEJojan2p+KLT3Y0A@mail.gmail.com>

2014-10-30 9:42 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> Hello OpenCSW maintainers and users,
>
> We've done a cleanup of maintainer accounts.
>
> Some maintainer accounts were not active for a long time. If a
> maintainer did not upload a package in the last 2 years, we've changed
> the account status to 'Retired'. This allows our website to display
> information which is closer to the truth.
>
> Changing status to retired is a reversible operation, so if anybody
> wants to come back and build packages, please do!
>
> Many thanks go to Ben for handling it.
>
> Maciej

From dam at opencsw.org  Thu Oct 30 21:31:49 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 30 Oct 2014 21:31:49 +0100
Subject: Update of the buildfarm
In-Reply-To: <7FAD0F07-2B95-478D-B22E-F8BAE1C7B71E@opencsw.org>
References: <7FAD0F07-2B95-478D-B22E-F8BAE1C7B71E@opencsw.org>
Message-ID: <938D7B31-9A9B-4971-B44C-6C339CCC3BB5@opencsw.org>

Hi folks,

> Am 30.10.2014 um 10:25 schrieb Dagobert Michelsen <dam at opencsw.org>:
> I will be updating the buildfarm today which requires downtime. Please stand by.

Most of the farm is running again, I will reattach the rest in the next hours.
Please let me know if you encounter anything suspicious.

@Maciej, Ben: Can you please restart signing?


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/20141030/fd769e2d/attachment.p7s>

From maciej at opencsw.org  Thu Oct 30 23:26:35 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 30 Oct 2014 22:26:35 +0000
Subject: Update of the buildfarm
References: <7FAD0F07-2B95-478D-B22E-F8BAE1C7B71E@opencsw.org>
	<938D7B31-9A9B-4971-B44C-6C339CCC3BB5@opencsw.org>
Message-ID: <CALtRa-5GR1rAD=r+ynZRQ43yuCzxK8bYvvLWuAwnnL-aCX4xTg@mail.gmail.com>

Dagobert Michelsen <dam at opencsw.org> escreveu no dia Thu Oct 30 2014 at
20:32:01:

> @Maciej, Ben: Can you please restart signing?
>

Done!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141030/831c69fb/attachment.html>

From romeotheriault at opencsw.org  Fri Oct 31 00:41:43 2014
From: romeotheriault at opencsw.org (Romeo Theriault)
Date: Thu, 30 Oct 2014 13:41:43 -1000
Subject: Process to hand over maintenance of packages?
Message-ID: <CAHo7ehXAGaW1Fk5hvH2chOuJ7g=t0449f7yOHF+RPbbzKGLEbQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141030/57c0d607/attachment.html>

From dam at opencsw.org  Fri Oct 31 10:04:05 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 31 Oct 2014 10:04:05 +0100
Subject: Process to hand over maintenance of packages?
In-Reply-To: <CAHo7ehXAGaW1Fk5hvH2chOuJ7g=t0449f7yOHF+RPbbzKGLEbQ@mail.gmail.com>
References: <CAHo7ehXAGaW1Fk5hvH2chOuJ7g=t0449f7yOHF+RPbbzKGLEbQ@mail.gmail.com>
Message-ID: <879CF1D2-756B-4411-842A-BC1D9AD0B968@opencsw.org>

Hi Romeo,

> Am 31.10.2014 um 00:41 schrieb Romeo Theriault <romeotheriault at opencsw.org>:
> 
> 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


I suggest Bill writes to board at opencsw.org with his intended user name and ssh public key and sourceforge user name and
I?ll set up the config, then he can respin/update the packages and release them.


Thanks for your contributions!

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/20141031/757cc41d/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/20141031/757cc41d/attachment-0001.p7s>