From laurent at opencsw.org  Wed Dec  3 23:09:25 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Wed, 03 Dec 2014 23:09:25 +0100
Subject: IT's time to remove the Solaris 8 packages
Message-ID: <547F8A15.4090606@opencsw.org>

People,

There's another guy on IRC coming to ask for S8 binaries. I think it is 
more than time to remove them from the archive.

I have nothing against him, he asked nicely, But nevertheless, they must go.

At this point, they are more a liability than anything else. All the 
famous vulnerabilities are there, HEARTBLEED, SHELLSHOCK, POODLE, and 
those who've not done the headlines.

The people who come asking for them are following a pattern: they're 
obviously not experimented, and they clearly are not able to assess the 
risks, and *never* in a position to take decision.

Then, their employers follow a similar pattern: they're cheapskates, who 
want to get as much money as possible from obsolete systems with no 
investment in time nor money. They willingly put their customers are 
risk because of their greed.

And lastly, there's an existing alternative, there's SunFreeware, which, 
from a quick look, has much more recent packages.

So frankly, I think we're doing a disservice to everybody by keeping 
those old files online. They should be removed. If a company is 
motivated to revive it and provides resources for it, welcome to it. But 
those files as they stand are just used as an excuse to avoid doing that.

Thanks,

Laurent

From wilbury at opencsw.org  Thu Dec  4 00:18:09 2014
From: wilbury at opencsw.org (Juraj Lutter)
Date: Thu, 04 Dec 2014 00:18:09 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <547F8A15.4090606@opencsw.org>
References: <547F8A15.4090606@opencsw.org>
Message-ID: <547F9A31.5070600@opencsw.org>

On 12/03/14 23:09, Laurent Blume wrote:
> People,
>
> There's another guy on IRC coming to ask for S8 binaries. I think it
> is more than time to remove them from the archive.
>
> I have nothing against him, he asked nicely, But nevertheless, they
> must go.
>
> At this point, they are more a liability than anything else. All the
> famous vulnerabilities are there, HEARTBLEED, SHELLSHOCK, POODLE, and
> those who've not done the headlines.
>
> The people who come asking for them are following a pattern: they're
> obviously not experimented, and they clearly are not able to assess
> the risks, and *never* in a position to take decision.
>
> Then, their employers follow a similar pattern: they're cheapskates,
> who want to get as much money as possible from obsolete systems with
> no investment in time nor money. They willingly put their customers
> are risk because of their greed.
>
> And lastly, there's an existing alternative, there's SunFreeware,
> which, from a quick look, has much more recent packages.
>
> So frankly, I think we're doing a disservice to everybody by keeping
> those old files online. They should be removed. If a company is
> motivated to revive it and provides resources for it, welcome to it.
> But those files as they stand are just used as an excuse to avoid
> doing that.
>


I only can aggree with Laurent.

-- 
Juraj Lutter <wilbury at opencsw.org>


From bwalton at opencsw.org  Thu Dec  4 08:30:49 2014
From: bwalton at opencsw.org (Ben Walton)
Date: Thu, 04 Dec 2014 07:30:49 +0000
Subject: IT's time to remove the Solaris 8 packages
References: <547F8A15.4090606@opencsw.org> <547F9A31.5070600@opencsw.org>
Message-ID: <CAP30j149D8n9q5x8BOwqg_7Ue5K4sVF-rg5MT24ehPZrc_Ew3Q@mail.gmail.com>

Kill them with fire. Arguably Solaris 9 is in them same boat at this
point...

Are there any remaining packages built for Solaris 8 that are in the
dependency tree for modern systems?

Thanks
-Ben

On Wed, Dec 3, 2014, 23:18 Juraj Lutter <wilbury at opencsw.org> wrote:

> On 12/03/14 23:09, Laurent Blume wrote:
> > People,
> >
> > There's another guy on IRC coming to ask for S8 binaries. I think it
> > is more than time to remove them from the archive.
> >
> > I have nothing against him, he asked nicely, But nevertheless, they
> > must go.
> >
> > At this point, they are more a liability than anything else. All the
> > famous vulnerabilities are there, HEARTBLEED, SHELLSHOCK, POODLE, and
> > those who've not done the headlines.
> >
> > The people who come asking for them are following a pattern: they're
> > obviously not experimented, and they clearly are not able to assess
> > the risks, and *never* in a position to take decision.
> >
> > Then, their employers follow a similar pattern: they're cheapskates,
> > who want to get as much money as possible from obsolete systems with
> > no investment in time nor money. They willingly put their customers
> > are risk because of their greed.
> >
> > And lastly, there's an existing alternative, there's SunFreeware,
> > which, from a quick look, has much more recent packages.
> >
> > So frankly, I think we're doing a disservice to everybody by keeping
> > those old files online. They should be removed. If a company is
> > motivated to revive it and provides resources for it, welcome to it.
> > But those files as they stand are just used as an excuse to avoid
> > doing that.
> >
>
>
> I only can aggree with Laurent.
>
> --
> Juraj Lutter <wilbury at opencsw.org>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141204/cad6fe1d/attachment.html>

From tosmi at opencsw.org  Thu Dec  4 10:50:08 2014
From: tosmi at opencsw.org (Toni Schmidbauer)
Date: Thu, 04 Dec 2014 10:50:08 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <547F8A15.4090606@opencsw.org> (Laurent Blume's message of "Wed, 
	03 Dec 2014 23:09:25 +0100")
References: <547F8A15.4090606@opencsw.org>
Message-ID: <86h9xbvj5b.fsf@opencsw.org>

Laurent Blume <laurent at opencsw.org> writes:
> There's another guy on IRC coming to ask for S8 binaries. I think it
> is more than time to remove them from the archive.

+1 

toni

From dam at opencsw.org  Thu Dec  4 15:16:11 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 4 Dec 2014 15:16:11 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <547F8A15.4090606@opencsw.org>
References: <547F8A15.4090606@opencsw.org>
Message-ID: <FD64CBED-3196-4CC3-981A-E115FFEE4538@opencsw.org>

Hi folks,

@Laurent: Please don?t post to maintainers@ and users@ at the same time as it leads to
bounces when people reply to all from users@

> Am 03.12.2014 um 23:09 schrieb Laurent Blume <laurent at opencsw.org>:
> There's another guy on IRC coming to ask for S8 binaries. I think it is more than time to remove them from the archive.
> 
> I have nothing against him, he asked nicely, But nevertheless, they must go.
> 
> At this point, they are more a liability than anything else. All the famous vulnerabilities are there, HEARTBLEED, SHELLSHOCK, POODLE, and those who've not done the headlines.
> 
> The people who come asking for them are following a pattern: they're obviously not experimented, and they clearly are not able to assess the risks, and *never* in a position to take decision.
> 
> Then, their employers follow a similar pattern: they're cheapskates, who want to get as much money as possible from obsolete systems with no investment in time nor money. They willingly put their customers are risk because of their greed.
> 
> And lastly, there's an existing alternative, there's SunFreeware, which, from a quick look, has much more recent packages.
> 
> So frankly, I think we're doing a disservice to everybody by keeping those old files online. They should be removed. If a company is motivated to revive it and provides resources for it, welcome to it. But those files as they stand are just used as an excuse to avoid doing that.

While I do understand your motivation I personally think it is wrong to remove stuff,
regardless of how old it is. I cursed the times when I looked up old stuff like firmware
and it was gone. What has proposed earlier (by Maciej IIRC) was renaming old stuff to
/UNSUPPORTED-USE-ONLY-IF-YOU-ARE-UNPROFESSIONAL/ or similar which I think is ok.
Also not depending on Solaris 8 stuff is good and rebuild or drop stuff from the Solaris 8
catalog. I vaguely remember we had a list of that some time ago but can?t find that any more,
we should link that also from http://buildfarm.opencsw.org.


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/20141204/96f49e3a/attachment-0001.p7s>

From laurent at opencsw.org  Thu Dec  4 16:25:53 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 04 Dec 2014 16:25:53 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <FD64CBED-3196-4CC3-981A-E115FFEE4538@opencsw.org>
References: <547F8A15.4090606@opencsw.org>
	<FD64CBED-3196-4CC3-981A-E115FFEE4538@opencsw.org>
Message-ID: <54807D01.8040104@opencsw.org>

Le 2014/12/04 15:16 +0100, Dagobert Michelsen a ?crit:
> Hi folks,
>
> @Laurent: Please don?t post to maintainers@ and users@ at the same time as it leads to
> bounces when people reply to all from users@

I should have set the reply-to, right.

> While I do understand your motivation I personally think it is wrong to remove stuff,
> regardless of how old it is. I cursed the times when I looked up old stuff like firmware
> and it was gone. What has proposed earlier (by Maciej IIRC) was renaming old stuff to
> /UNSUPPORTED-USE-ONLY-IF-YOU-ARE-UNPROFESSIONAL/ or similar which I think is ok.

I'll be direct: no, it is not ok. I truly thought the same some time 
ago. Since then, I've seen and interacted with many of those requests.

The point is, those people, they /don't give a fuck/. They will not tell 
their customers the risks, nor make an honest assessment of the situation.

I really do not want OpenCSW to be assisting people who are essentially 
scammers, helping them to deceive those who give them money.

You don't understand that attitude, because you're honest, and doing 
your best for your customers. But it's definitely not the case for those 
companies. They're doing the LEAST effort possible, and cashing in on it.
It's not comparable to firmware. A bad OpenBoot cannot be exploited 
remotely to get access to your systems, unlike plenty of those packages 
we're distributing. I understand your past experience, but don't let it 
influence you: your motivations were not the same, at all.

But by all means, again, put a message instead of the catalogs that they 
are welcome to assist in maintaining them. So they will contact us when 
they need. That's what we need, that's what they need, everybody will be 
happy.

Laurent




From rmottola at opencsw.org  Thu Dec  4 19:38:49 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Thu, 04 Dec 2014 19:38:49 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <547F9A31.5070600@opencsw.org>
References: <547F8A15.4090606@opencsw.org> <547F9A31.5070600@opencsw.org>
Message-ID: <5480AA39.3060207@opencsw.org>

Hi,

I'm usually against removing something.. the usage of those packages is 
at the user's risk.
If you think e.g. NetBSD, you can go and download every version up to 
1.x, everything which is not supported anymore is moved into an 
"archive", often not mirrored.

Solaris 8 machines might be used more by by hobbyists or some special 
apps where there is still old hardware running.
Now I understand that if people run it in production it is generally a 
bad thing. So given that, perhaps "archiving" them is not enough?

I said that my intention is to do a re-spin of some core packages: 
compiler, bash and of course openssl/openssh. But I still have my 
troubles getting packages build on solaris 9/10 first.
It shows though that I am not the only one :) But I am not crazy to run 
externally exposed services. Actually, right now I even removed ssh 
access to it, since it surely has a bugy ssl!

Riccardo

From ihsan at opencsw.org  Thu Dec  4 20:02:27 2014
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Thu, 4 Dec 2014 20:02:27 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <547F8A15.4090606@opencsw.org>
References: <547F8A15.4090606@opencsw.org>
Message-ID: <20141204190227.GB61705@dogan.ch>

On Wednesday, 03 Dec 2014 23:09 +0100, Laurent Blume wrote:

> There's another guy on IRC coming to ask for S8 binaries. I think it is 
> more than time to remove them from the archive.

I see your point, but if there is no newer version of a
particular package and if there are no security or functional
issues, I don't see any reason to remove the package.



Ihsan

-- 
ihsan at dogan.ch http://blog.dogan.ch/

From ihsan at opencsw.org  Thu Dec  4 20:07:31 2014
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Thu, 4 Dec 2014 20:07:31 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <20141204190227.GB61705@dogan.ch>
References: <547F8A15.4090606@opencsw.org>
 <20141204190227.GB61705@dogan.ch>
Message-ID: <20141204190731.GC61705@dogan.ch>

Ok, next I have to be more careful with the "list reply"
function. 

On Thursday, 04 Dec 2014 20:02 +0100, Ihsan Dogan wrote:

> On Wednesday, 03 Dec 2014 23:09 +0100, Laurent Blume wrote:
> 
> > There's another guy on IRC coming to ask for S8 binaries. I think it is 
> > more than time to remove them from the archive.
> 
> I see your point, but if there is no newer version of a
> particular package and if there are no security or functional
> issues, I don't see any reason to remove the package.
> 
> 
> 
> Ihsan
> 
> -- 
> ihsan at dogan.ch http://blog.dogan.ch/
> 
-- 
ihsan at dogan.ch http://blog.dogan.ch/

From maciej at opencsw.org  Thu Dec  4 20:36:29 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 4 Dec 2014 19:36:29 +0000
Subject: Some packages are missing bundle information, we need to fix it
Message-ID: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>

Hello maintainers,

Our package integration doesn't work properly because some packages
are missing the bundle information. The list can be seen near the end
of the package promotions page.

http://buildfarm.opencsw.org/package-promotions/promote-packages.html

Would anyone like to volunteer and debug this? Do these packages
actually miss the bundle field? What to do to restore the field?

Then, rebuild and upload packages with the bundle information.

Affected packages:
- flac (multiple packages)
- libmysqlclient18

This should fix the package promotion. By the way, the munich catalog
is broken and this blocks catalog generation. This doesn't prevent us
from uploading fixed packages, but it does block the generation of the
testing catalog.

Maciej

From maciej at opencsw.org  Thu Dec  4 20:42:01 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 4 Dec 2014 19:42:01 +0000
Subject: Some packages are missing bundle information, we need to fix it
In-Reply-To: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
Message-ID: <CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>

2014-12-04 19:36 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> Affected packages:
> - flac (multiple packages)
> - libmysqlclient18

I have an idea why this might be:

A change in the bundle name for a preexisting package. For example,
moving a package from bundle "flac" to bundle "libflac".

Probable fix: revert to the old name of bundle, upload.

From rupert at opencsw.org  Thu Dec  4 21:10:03 2014
From: rupert at opencsw.org (rupert THURNER)
Date: Thu, 4 Dec 2014 21:10:03 +0100
Subject: example for working github configuration
In-Reply-To: <CALtRa-6-HotjYC93KsP8taz0s0i+-U_kCfkXXd0rrAJEHKc9Vw@mail.gmail.com>
References: <CAJs9aZ8ZDUAnhDCQSoRFpRrBJVt5iyXwf-6ju-9gjpn3O3r2vw@mail.gmail.com>
	<CALtRa-6-HotjYC93KsP8taz0s0i+-U_kCfkXXd0rrAJEHKc9Vw@mail.gmail.com>
Message-ID: <CAJs9aZ-yVmVSiTS-ZDcZPzB3ZqeOcJ3EyuAd3Ok9aco=nf4brQ@mail.gmail.com>

On Nov 30, 2014 6:21 PM, "Maciej (Matchek) Blizi?ski" <maciej at opencsw.org>
wrote:
>
> 2014-11-30 12:37 GMT+00:00 rupert THURNER <rupert at opencsw.org>:
> > but i can enter whatever i want, it does not fail on fetching the
> > contents but later on.
>
> Are you looking for a working github configuration, or presenting an
> example of working github configuration?
>

Uh, part of the sentence is missing. It does not work and does not give an
error.

Rupert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141204/34e129ab/attachment.html>

From laurent at opencsw.org  Thu Dec  4 21:21:24 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 04 Dec 2014 21:21:24 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <5480AA39.3060207@opencsw.org>
References: <547F8A15.4090606@opencsw.org> <547F9A31.5070600@opencsw.org>
	<5480AA39.3060207@opencsw.org>
Message-ID: <5480C244.9040002@opencsw.org>

Le 2014/12/04 19:38 +0100, Riccardo Mottola a ?crit:
> Hi,
>
> I'm usually against removing something.. the usage of those packages is
> at the user's risk.
> If you think e.g. NetBSD, you can go and download every version up to
> 1.x, everything which is not supported anymore is moved into an
> "archive", often not mirrored.
>
> Solaris 8 machines might be used more by by hobbyists or some special
> apps where there is still old hardware running.

My point exactly. If they are hobbyists, they have time to help. If they 
run special software, they have resources to help.

I've yet to see somebody coming out as either.

> Now I understand that if people run it in production it is generally a
> bad thing. So given that, perhaps "archiving" them is not enough?
>
> I said that my intention is to do a re-spin of some core packages:
> compiler, bash and of course openssl/openssh. But I still have my
> troubles getting packages build on solaris 9/10 first.
> It shows though that I am not the only one :) But I am not crazy to run
> externally exposed services. Actually, right now I even removed ssh
> access to it, since it surely has a bugy ssl!

ssh does not use ssl.

Laurent



From laurent at opencsw.org  Thu Dec  4 21:25:19 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 04 Dec 2014 21:25:19 +0100
Subject: IT's time to remove the Solaris 8 packages
In-Reply-To: <20141204190227.GB61705@dogan.ch>
References: <547F8A15.4090606@opencsw.org> <20141204190227.GB61705@dogan.ch>
Message-ID: <5480C32F.1000507@opencsw.org>

Le 2014/12/04 20:02 +0100, ?hsan do?an a ?crit:
> I see your point, but if there is no newer version of a
> particular package and if there are no security or functional
> issues, I don't see any reason to remove the package.

Fair enough, but really, how many packages are going to be left there 
once all those with CVE's and their dependencies are removed?
I'm not volunteering to sort them one by one myself, who is?

Laurent





From laurent at opencsw.org  Thu Dec  4 21:57:33 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 04 Dec 2014 21:57:33 +0100
Subject: Some packages are missing bundle information, we need to fix
 it
In-Reply-To: <CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
Message-ID: <5480CABD.4020601@opencsw.org>

Le 2014/12/04 20:42 +0100, Matchek a ?crit:
> 2014-12-04 19:36 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> Affected packages:
>> - flac (multiple packages)
>> - libmysqlclient18
>
> I have an idea why this might be:
>
> A change in the bundle name for a preexisting package. For example,
> moving a package from bundle "flac" to bundle "libflac".
>
> Probable fix: revert to the old name of bundle, upload.

Sorry, but I'll ask the naive question: what's a bundle field and how to 
add it?

Laurent

From jh at opencsw.org  Fri Dec  5 08:48:04 2014
From: jh at opencsw.org (Jan Holzhueter)
Date: Fri, 05 Dec 2014 08:48:04 +0100
Subject: Some packages are missing bundle information, we need to fix
 it
In-Reply-To: <CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
Message-ID: <54816334.40903@opencsw.org>

Am 04.12.14 um 20:42 schrieb Maciej (Matchek) Blizi?ski:
> 2014-12-04 19:36 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>> Affected packages:
>> - flac (multiple packages)
>> - libmysqlclient18
> 
> I have an idea why this might be:
> 
> A change in the bundle name for a preexisting package. For example,
> moving a package from bundle "flac" to bundle "libflac".
> 
> Probable fix: revert to the old name of bundle, upload.
> 

It would more be it does not have a bundle tag maybe?
The old flac is from 2011?

Greetings
Jan



From jh at opencsw.org  Fri Dec  5 08:53:27 2014
From: jh at opencsw.org (Jan Holzhueter)
Date: Fri, 05 Dec 2014 08:53:27 +0100
Subject: Some packages are missing bundle information, we need to fix
 it
In-Reply-To: <54816334.40903@opencsw.org>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
	<54816334.40903@opencsw.org>
Message-ID: <54816477.5080709@opencsw.org>

Am 05.12.14 um 08:48 schrieb Jan Holzhueter:
> Am 04.12.14 um 20:42 schrieb Maciej (Matchek) Blizi?ski:
>> 2014-12-04 19:36 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>>> Affected packages:
>>> - flac (multiple packages)
>>> - libmysqlclient18
>>
>> I have an idea why this might be:
>>
>> A change in the bundle name for a preexisting package. For example,
>> moving a package from bundle "flac" to bundle "libflac".
>>
>> Probable fix: revert to the old name of bundle, upload.
>>
> 
> It would more be it does not have a bundle tag maybe?
> The old flac is from 2011?

Ok they do have bundel names:

and they do differ:

Old:
http://buildfarm.opencsw.org/pkgdb/srv4/e310640cc16d3413ccb7d3f48a137173/

'OPENCSW_BUNDLE': 'libflac',

new:

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

OPENCSW_BUNDLE': 'flac'

but how do you fix that?
Greetings
Jan



From dam at opencsw.org  Fri Dec  5 09:23:17 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 5 Dec 2014 09:23:17 +0100
Subject: Some packages are missing bundle information, we need to fix it
In-Reply-To: <54816477.5080709@opencsw.org>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
	<54816334.40903@opencsw.org> <54816477.5080709@opencsw.org>
Message-ID: <E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>

Hi,

> Am 05.12.2014 um 08:53 schrieb Jan Holzhueter <jh at opencsw.org>:
> 
> Am 05.12.14 um 08:48 schrieb Jan Holzhueter:
>> Am 04.12.14 um 20:42 schrieb Maciej (Matchek) Blizi?ski:
>>> 2014-12-04 19:36 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>>>> Affected packages:
>>>> - flac (multiple packages)
>>>> - libmysqlclient18
>>> 
>>> I have an idea why this might be:
>>> 
>>> A change in the bundle name for a preexisting package. For example,
>>> moving a package from bundle "flac" to bundle "libflac".
>>> 
>>> Probable fix: revert to the old name of bundle, upload.
>> 
>> It would more be it does not have a bundle tag maybe?
>> The old flac is from 2011?
> 
> Ok they do have bundel names:
> 
> and they do differ:
> 
> Old:
> http://buildfarm.opencsw.org/pkgdb/srv4/e310640cc16d3413ccb7d3f48a137173/
> 
> 'OPENCSW_BUNDLE': 'libflac',
> 
> new:
> 
> http://buildfarm.opencsw.org/pkgdb/srv4/fb36d71dd01c5c3289fbce96d2ffc5b0/
> 
> OPENCSW_BUNDLE': 'flac'
> 
> but how do you fix that?

The bundle name default to
  BUNDLE ?= $(NAME)
as used in
  https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.pkg.mk#120
for all packages built by one recipe. We didn?t take much care about bundle names because
they were not important in the past. Essentially I think the bundle name should be ?flac?
for all packages here. However, I don?t understand why changing bundle names prohibits
propagation and therefor is *bad*.


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/20141205/ad52c512/attachment.p7s>

From maciej at opencsw.org  Fri Dec  5 10:05:49 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 05 Dec 2014 09:05:49 +0000
Subject: Some packages are missing bundle information, we need to fix it
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
	<54816334.40903@opencsw.org> <54816477.5080709@opencsw.org>
	<E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>
Message-ID: <CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>

Bundle names changes are not inherently bad, but the package promotion code
can't handle them correctly at the moment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141205/4fab427b/attachment.html>

From jh at opencsw.org  Fri Dec  5 10:14:18 2014
From: jh at opencsw.org (Jan Holzhueter)
Date: Fri, 05 Dec 2014 10:14:18 +0100
Subject: Some packages are missing bundle information, we need to fix
 it
In-Reply-To: <CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>	<54816334.40903@opencsw.org>
	<54816477.5080709@opencsw.org>	<E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>
	<CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>
Message-ID: <5481776A.4000407@opencsw.org>

Am 05.12.14 um 10:05 schrieb Maciej (Matchek) Blizi?ski:
>     Bundle names changes are not inherently bad, but the package
>     promotion code can't handle them correctly at the moment.
> 

so should I push those just manual?
As I think the packages are fine?

Or would that brake new updates still?

Greetings
Jan


From maciej at opencsw.org  Fri Dec  5 10:17:57 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 05 Dec 2014 09:17:57 +0000
Subject: Some packages are missing bundle information, we need to fix it
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
	<54816334.40903@opencsw.org> <54816477.5080709@opencsw.org>
	<E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>
	<CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>
	<5481776A.4000407@opencsw.org>
Message-ID: <CALtRa-6QnScgsFqof9MLpVyP=e4ZDwvdbunn4RofEHojTGDK+w@mail.gmail.com>

You can push them manually, further integration will be fine. The problem
occurs when there are packages with the same pkgname/catalogname but
different bundle name between unstable and munich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141205/cf54434a/attachment.html>

From jh at opencsw.org  Fri Dec  5 10:25:01 2014
From: jh at opencsw.org (Jan Holzhueter)
Date: Fri, 05 Dec 2014 10:25:01 +0100
Subject: Some packages are missing bundle information, we need to fix
 it
In-Reply-To: <CALtRa-6QnScgsFqof9MLpVyP=e4ZDwvdbunn4RofEHojTGDK+w@mail.gmail.com>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>	<54816334.40903@opencsw.org>
	<54816477.5080709@opencsw.org>	<E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>	<CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>	<5481776A.4000407@opencsw.org>
	<CALtRa-6QnScgsFqof9MLpVyP=e4ZDwvdbunn4RofEHojTGDK+w@mail.gmail.com>
Message-ID: <548179ED.8000406@opencsw.org>

Am 05.12.14 um 10:17 schrieb Maciej (Matchek) Blizi?ski:
>     You can push them manually, further integration will be fine. The
>     problem occurs when there are packages with the same
>     pkgname/catalogname but different bundle name between unstable and
>     munich.
> 

I think we don't have so many packages where is happens.

So I just run the curl commands the promote site displays?

Greetings
Jan


From grzemba at contac-dt.de  Fri Dec  5 10:48:29 2014
From: grzemba at contac-dt.de (Carsten Grzemba)
Date: Fri, 05 Dec 2014 10:48:29 +0100
Subject: which compiler should I use
In-Reply-To: <bbb1e2865b25.54817f41@contac-dt.de>
References: <bbb1a01d20a3.54817705@contac-dt.de>
	<bbb1a76946d9.54817743@contac-dt.de>
	<bbb18afc36b5.5481777f@contac-dt.de>
	<bbb1d3e15d85.548177f8@contac-dt.de>
	<bf4d87e34679.54817834@contac-dt.de>
	<bf4da219e6a.54817870@contac-dt.de>
	<bf4db10b5ead.548178ae@contac-dt.de>
	<bf4db3c12637.54817927@contac-dt.de>
	<bf4dd1df2483.54817963@contac-dt.de>
	<bf239cef3305.548179a0@contac-dt.de>
	<bbb1e2865b25.54817f41@contac-dt.de>
Message-ID: <bbb1bb0e2f18.54818d7d@contac-dt.de>

I like to push a new netsnmp package and thought that is a good idea to use GCC for that, but
it delivers a Perl and Python binding and perl says:
perl -V:cc
cc='/opt/SUNWspro/bin/cc';

python2.6 likes: /opt/solarisstudio12.3/bin/cc
python2.7 likes: /opt/csw/bin/gcc4.9

What is the best match?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141205/a0227a8b/attachment.html>

From maciej at opencsw.org  Fri Dec  5 11:10:00 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Fri, 5 Dec 2014 10:10:00 +0000
Subject: Some packages are missing bundle information, we need to fix it
In-Reply-To: <548179ED.8000406@opencsw.org>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
	<54816334.40903@opencsw.org> <54816477.5080709@opencsw.org>
	<E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>
	<CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>
	<5481776A.4000407@opencsw.org>
	<CALtRa-6QnScgsFqof9MLpVyP=e4ZDwvdbunn4RofEHojTGDK+w@mail.gmail.com>
	<548179ED.8000406@opencsw.org>
Message-ID: <CALtRa-6hqSBXcqc9=viwyDXh64M=XTkjSdH0ptwjb7SeanCb8A@mail.gmail.com>

2014-12-05 9:25 GMT+00:00 Jan Holzhueter <jh at opencsw.org>:
> I think we don't have so many packages where is happens.
>
> So I just run the curl commands the promote site displays?

Yes, running the curl commands will do it.

Then we need to think about how we want to handle bundle name changes.
Take this example:

unstable:
CSWfoo / bundle foo
CSWbar / bundle foo
CSWbaz / bundle baz

munich:
CSWfoo / bundle foo
CSWbar / bundle baz
CSWbaz / bundle baz

What should happen and why?

Maciej

From rmottola at opencsw.org  Sun Dec  7 19:23:32 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 07 Dec 2014 19:23:32 +0100
Subject: gnutar vs gtar ?
Message-ID: <54849B24.4050603@opencsw.org>

Hi,

After Dagobert made several changes to gnustep-base (there is stills 
something left), I tried to update also gnustep-gui to his suggestions. 
I wanted, at least locally, go up with his changes to an application and 
see it all works compared to mine.

gnustep-base builds on my box just fine, as on the buildfarm.

while building gnustep-gui on my own box

Making install for bundle libgmodel...
  Installing headers...
  Creating 
/home/multix/code/opencsw/gnustep-gui/trunk/work/install-isa-sparcv8plus//opt/csw/GNUstep/System/Library/Bundles...
  Installing bundle directory...
/bin/sh: gnutar: not found
/bin/sh: gnutar: not found
/opt/csw/GNUstep/System/Library/Makefiles/Instance/Shared/bundle.make:402: 
recipe for target 'shared-instance-bundle-install' failed


bash-4.3$ which gtar
/opt/csw/bin/gtar
bash-4.3$ which gnutar
no gnutar in /opt/csw/bin /usr/bin /usr/ucb /etc .

What's the situation at your place? Who is invoking "gnutar" ? It is not 
something usual, I don't have gnutar on other platforms like NetBSD, but 
gtar.

Riccardo

From rmottola at opencsw.org  Sun Dec  7 19:28:41 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sun, 07 Dec 2014 19:28:41 +0100
Subject: problem committing (from my own box)
Message-ID: <54849C59.2010001@opencsw.org>

Hi,

when trying to commit from my own box, I get this:

bash-4.3$ mgar commit -m "adopt changes made by Dago in gnustep-base"
Committing changes.
Authentication realm: <https://svn.code.sf.net:443> SourceForge User
Password for 'rmottola': **********

svn: E000013: Commit failed (details follow):
svn: E000013: could not begin a transaction

username & password are correct though! Ideas? I was able to commit in 
the past... and i am able to commit from the buidl farm, at least I was 
a couple of days ago.

bash-4.3$ /usr/sbin/ping svn.code.sf.net
svn.code.sf.net is alive


Riccardo

From maciej at opencsw.org  Sun Dec  7 23:31:36 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 7 Dec 2014 22:31:36 +0000
Subject: gnutar vs gtar ?
In-Reply-To: <54849B24.4050603@opencsw.org>
References: <54849B24.4050603@opencsw.org>
Message-ID: <CALtRa-5U+bRhFWVmHSxDW=xg9hfO3oBHa+pynA1ceMe21DvTwg@mail.gmail.com>

2014-12-07 18:23 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
>
> What's the situation at your place? Who is invoking "gnutar" ? It is not something usual, I don't have gnutar on other platforms like NetBSD, but gtar.

It looks like a simple substitution patch for the build files.

If you wanted to do the right thing, you could contact the upstream
and ask them about it.

Maciej

From maciej at opencsw.org  Sun Dec  7 23:34:47 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 7 Dec 2014 22:34:47 +0000
Subject: problem committing (from my own box)
In-Reply-To: <54849C59.2010001@opencsw.org>
References: <54849C59.2010001@opencsw.org>
Message-ID: <CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>

2014-12-07 18:28 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> Authentication realm: <https://svn.code.sf.net:443> SourceForge User
> Password for 'rmottola': **********

You can't commit via https. You need to check out using the read+write
link e.g. from https://sourceforge.net/p/gar/code/HEAD/tree/

From rmottola at opencsw.org  Mon Dec  8 01:06:04 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 08 Dec 2014 01:06:04 +0100
Subject: gnutar vs gtar ?
In-Reply-To: <CALtRa-5U+bRhFWVmHSxDW=xg9hfO3oBHa+pynA1ceMe21DvTwg@mail.gmail.com>
References: <54849B24.4050603@opencsw.org>
	<CALtRa-5U+bRhFWVmHSxDW=xg9hfO3oBHa+pynA1ceMe21DvTwg@mail.gmail.com>
Message-ID: <5484EB6C.9020608@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> It looks like a simple substitution patch for the build files.
>
> If you wanted to do the right thing, you could contact the upstream
> and ask them about it.
I have commit access to upstream myself and have contact to the 
developers, so I could to that myself even.
However, when I did a "source" build myself before attempting packages, 
this did not happen.

gnustep-gui has no single reference to gnutar, it call apparently comes 
down from gnustep-make which checks for available programs during 
configure. I think I never had gnutar on the machine. I can't say for 
the buidfarm, because gnustep-base package is still not complete.

inside gnustep-make configure.ac I found:

AC_CHECK_PROGS(TAR, gnutar gtar, tar)

this should actually check for gnustar first, gtar then.. and as 
fallback use tar, right?

perhaps gnustep-make is configured without the proper environment and 
can't find csw's tar ? But that still would fallback to solaris tar, not 
use gnutar indeed.

Riccardo


Riccardo

From maciej at opencsw.org  Mon Dec  8 00:58:53 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 07 Dec 2014 23:58:53 +0000
Subject: gnutar vs gtar ?
References: <54849B24.4050603@opencsw.org>
	<CALtRa-5U+bRhFWVmHSxDW=xg9hfO3oBHa+pynA1ceMe21DvTwg@mail.gmail.com>
	<5484EB6C.9020608@opencsw.org>
Message-ID: <CALtRa-7iF2X7ysvmi-M0Xn=-ts843E9DX6h1a_fz0vjjwifnYw@mail.gmail.com>

Riccardo Mottola <rmottola at opencsw.org> escreveu no dia Sun Dec 07 2014 at
23:04:25:

> AC_CHECK_PROGS(TAR, gnutar gtar, tar)
>
> this should actually check for gnustar first, gtar then.. and as
> fallback use tar, right?
>

Yes. Are there any logs from this? Did it find gnutar anywhere? If so,
where?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141207/9d4c7437/attachment.html>

From Joerg.Schilling at fokus.fraunhofer.de  Mon Dec  8 11:17:03 2014
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Mon, 8 Dec 2014 11:17:03 +0100
Subject: gnutar vs gtar ?
In-Reply-To: <54849B24.4050603@opencsw.org>
References: <54849B24.4050603@opencsw.org>
Message-ID: <54857a9f.PHh/aZ7/rQOn/Flr%Joerg.Schilling@fokus.fraunhofer.de>

Riccardo Mottola <rmottola at opencsw.org> wrote:

> bash-4.3$ which gtar
> /opt/csw/bin/gtar
> bash-4.3$ which gnutar
> no gnutar in /opt/csw/bin /usr/bin /usr/ucb /etc .
>
> What's the situation at your place? Who is invoking "gnutar" ? It is not 
> something usual, I don't have gnutar on other platforms like NetBSD, but 
> gtar.

The star emulation for gtar is installed as "gnutar" it may be that a script is 
looking for it after it did not find "gtar".

J?rg

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

From maciej at opencsw.org  Wed Dec 10 22:59:58 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 10 Dec 2014 21:59:58 +0000
Subject: Some packages are missing bundle information, we need to fix it
In-Reply-To: <CALtRa-6hqSBXcqc9=viwyDXh64M=XTkjSdH0ptwjb7SeanCb8A@mail.gmail.com>
References: <CALtRa-7tPANe4V9Z26=_bpJ_8aiPsRP2bPSrrpcxwmG-8DgzfA@mail.gmail.com>
	<CALtRa-7QPLC5qxyQqxnf7+1D1WoOBbw4b4pa+OMDvvOpssyxow@mail.gmail.com>
	<54816334.40903@opencsw.org> <54816477.5080709@opencsw.org>
	<E431A13B-2BA4-4E00-9283-64BD531DD917@opencsw.org>
	<CALtRa-48ELmGFCUAHLnKbkjHnj=BO06iMHKy-C1__-AqSyuXeA@mail.gmail.com>
	<5481776A.4000407@opencsw.org>
	<CALtRa-6QnScgsFqof9MLpVyP=e4ZDwvdbunn4RofEHojTGDK+w@mail.gmail.com>
	<548179ED.8000406@opencsw.org>
	<CALtRa-6hqSBXcqc9=viwyDXh64M=XTkjSdH0ptwjb7SeanCb8A@mail.gmail.com>
Message-ID: <CALtRa-5faNHz=BKY_OaiS7VHLerttWNokQ+CYkuheEHzi0vNVQ@mail.gmail.com>

I talked with Laurent and Dago about it on IRC. We considered a few
options. For example we could add a check which would warn you that a
package changes its bundle name. This would require adding an
override, uploading the package and removing the override. Our
conclusion was that bundle name changes are infrequent enough that we
can leave it as is.

Maciej

From jgoerzen at opencsw.org  Thu Dec 11 00:15:09 2014
From: jgoerzen at opencsw.org (Jake Goerzen)
Date: Wed, 10 Dec 2014 15:15:09 -0800
Subject: road block updating sdlimage
Message-ID: <5488D3FD.2070407@opencsw.org>

Hello,

   I can successfully build updated sdlimage packages on unstable10x but 
I'm having trouble building them on unstable10s.  The problem is 
undefined symbol during linking on sparc.   The missing symbols are 
provided by it's self and seem to be included (.libs/IMG_webp.o). Would 
someone take the current recipe for a spin and see if can find what is 
wrong?

Here's a snip of where the compile stops on sparc:


libtool: link: /opt/SUNWspro/bin/cc -G -z defs -h libSDL_image-1.2.so.0 
-o .libs/libSDL_image-1.2.so.0.8.4 .libs/IMG.o .libs/IMG_bmp.o 
.libs/IMG_gif.o .libs/IMG_jpg.o .libs/IMG_lbm.o .libs/IMG_pcx.o 
.libs/IMG_png.o .libs/IMG_pnm.o .libs/IMG_tga.o .libs/IMG_tif.o 
.libs/IMG_xcf.o .libs/IMG_xpm.o .libs/IMG_xv.o .libs/IMG_webp.o   
-R/opt/csw/lib -L/opt/csw/lib -lSDL -lpthread -lposix4 -lc  -m32 
-xarch=sparc -m32 -xarch=sparc
Undefined                       first referenced
  symbol                             in file
WebPInitDecBufferInternal           .libs/IMG_webp.o
WebPGetFeaturesInternal             .libs/IMG_webp.o
WebPInitDecoderConfigInternal       .libs/IMG_webp.o
WebPIDecGetYUVA                     .libs/IMG_webp.o
ld: fatal: symbol referencing errors. No output written to 
.libs/libSDL_image-1.2.so.0.8.4


Best regards,
Jake

From laurent at opencsw.org  Thu Dec 11 10:46:58 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 11 Dec 2014 10:46:58 +0100
Subject: road block updating sdlimage
In-Reply-To: <5488D3FD.2070407@opencsw.org>
References: <5488D3FD.2070407@opencsw.org>
Message-ID: <54896812.6020206@opencsw.org>

Hello,

Just replacing the compiler with GCC4, it builds. Since there's no C++ 
involved AFAICT, I advise you to just do that. It can only be faster in 
any case than using an obsolete, unsupported compiler.

I'm committing that small change so you can fully test.

Laurent

Le 2014/12/11 00:15 +0100, Jake Goerzen a ?crit:
> Hello,
>
>    I can successfully build updated sdlimage packages on unstable10x but
> I'm having trouble building them on unstable10s.  The problem is
> undefined symbol during linking on sparc.   The missing symbols are
> provided by it's self and seem to be included (.libs/IMG_webp.o). Would
> someone take the current recipe for a spin and see if can find what is
> wrong?
>
> Here's a snip of where the compile stops on sparc:
>
>
> libtool: link: /opt/SUNWspro/bin/cc -G -z defs -h libSDL_image-1.2.so.0
> -o .libs/libSDL_image-1.2.so.0.8.4 .libs/IMG.o .libs/IMG_bmp.o
> .libs/IMG_gif.o .libs/IMG_jpg.o .libs/IMG_lbm.o .libs/IMG_pcx.o
> .libs/IMG_png.o .libs/IMG_pnm.o .libs/IMG_tga.o .libs/IMG_tif.o
> .libs/IMG_xcf.o .libs/IMG_xpm.o .libs/IMG_xv.o .libs/IMG_webp.o
> -R/opt/csw/lib -L/opt/csw/lib -lSDL -lpthread -lposix4 -lc  -m32
> -xarch=sparc -m32 -xarch=sparc
> Undefined                       first referenced
>   symbol                             in file
> WebPInitDecBufferInternal           .libs/IMG_webp.o
> WebPGetFeaturesInternal             .libs/IMG_webp.o
> WebPInitDecoderConfigInternal       .libs/IMG_webp.o
> WebPIDecGetYUVA                     .libs/IMG_webp.o
> ld: fatal: symbol referencing errors. No output written to
> .libs/libSDL_image-1.2.so.0.8.4
>
>
> Best regards,
> Jake
>




From laurent at opencsw.org  Thu Dec 11 14:27:05 2014
From: laurent at opencsw.org (Laurent Blume)
Date: Thu, 11 Dec 2014 14:27:05 +0100
Subject: SF commit emails not arriving
Message-ID: <54899BA9.30607@opencsw.org>

Apparently, my own commits don't get an email, though I'm receiving 
those of a few others.

What gives?

Laurent

From jgoerzen at opencsw.org  Thu Dec 11 17:48:17 2014
From: jgoerzen at opencsw.org (Jake Goerzen)
Date: Thu, 11 Dec 2014 08:48:17 -0800
Subject: road block updating sdlimage
In-Reply-To: <54896812.6020206@opencsw.org>
References: <5488D3FD.2070407@opencsw.org> <54896812.6020206@opencsw.org>
Message-ID: <5489CAD1.1070003@opencsw.org>

Hi Laurent,

  Thanks for solving that problem.  I should have thought about trying that.

Cheers,
Jake


On 12/11/14 01:46, Laurent Blume wrote:
> Hello,
>
> Just replacing the compiler with GCC4, it builds. Since there's no C++ 
> involved AFAICT, I advise you to just do that. It can only be faster 
> in any case than using an obsolete, unsupported compiler.
>
> I'm committing that small change so you can fully test.
>
> Laurent
>
> Le 2014/12/11 00:15 +0100, Jake Goerzen a ?crit:
>> Hello,
>>
>>    I can successfully build updated sdlimage packages on unstable10x but
>> I'm having trouble building them on unstable10s.  The problem is
>> undefined symbol during linking on sparc.   The missing symbols are
>> provided by it's self and seem to be included (.libs/IMG_webp.o). Would
>> someone take the current recipe for a spin and see if can find what is
>> wrong?
>>
>> Here's a snip of where the compile stops on sparc:
>>
>>
>> libtool: link: /opt/SUNWspro/bin/cc -G -z defs -h libSDL_image-1.2.so.0
>> -o .libs/libSDL_image-1.2.so.0.8.4 .libs/IMG.o .libs/IMG_bmp.o
>> .libs/IMG_gif.o .libs/IMG_jpg.o .libs/IMG_lbm.o .libs/IMG_pcx.o
>> .libs/IMG_png.o .libs/IMG_pnm.o .libs/IMG_tga.o .libs/IMG_tif.o
>> .libs/IMG_xcf.o .libs/IMG_xpm.o .libs/IMG_xv.o .libs/IMG_webp.o
>> -R/opt/csw/lib -L/opt/csw/lib -lSDL -lpthread -lposix4 -lc  -m32
>> -xarch=sparc -m32 -xarch=sparc
>> Undefined                       first referenced
>>   symbol                             in file
>> WebPInitDecBufferInternal           .libs/IMG_webp.o
>> WebPGetFeaturesInternal             .libs/IMG_webp.o
>> WebPInitDecoderConfigInternal       .libs/IMG_webp.o
>> WebPIDecGetYUVA                     .libs/IMG_webp.o
>> ld: fatal: symbol referencing errors. No output written to
>> .libs/libSDL_image-1.2.so.0.8.4
>>
>>
>> Best regards,
>> Jake
>>
>
>
>


From rmottola at opencsw.org  Fri Dec 12 17:19:32 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Fri, 12 Dec 2014 17:19:32 +0100
Subject: SF commit emails not arriving
In-Reply-To: <54899BA9.30607@opencsw.org>
References: <54899BA9.30607@opencsw.org>
Message-ID: <548B1594.5060009@opencsw.org>

Hi,

Laurent Blume wrote:
> Apparently, my own commits don't get an email, though I'm receiving 
> those of a few others.
>
> What gives?
I noticed that too!

Riccardo

From ihsan at opencsw.org  Fri Dec 12 19:46:55 2014
From: ihsan at opencsw.org (Ihsan Dogan)
Date: Fri, 12 Dec 2014 19:46:55 +0100
Subject: SF commit emails not arriving
In-Reply-To: <548B1594.5060009@opencsw.org>
References: <54899BA9.30607@opencsw.org>
 <548B1594.5060009@opencsw.org>
Message-ID: <20141212184655.GA59775@dogan.ch>

Hi,

On Friday, 12 Dec 2014 17:19 +0100, Riccardo Mottola wrote:

> > Apparently, my own commits don't get an email, though I'm receiving 
> > those of a few others.
> >
> > What gives?
> I noticed that too!

I've noticed that yesterday too. Looks like there was on issue on
Sourceforge, because the mail never arrived on the OpenCSW mail
server.



Ihsan

-- 
ihsan at dogan.ch http://blog.dogan.ch/

From rmottola at opencsw.org  Sat Dec 13 23:47:07 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Sat, 13 Dec 2014 23:47:07 +0100
Subject: gnustep-base, package warnings
In-Reply-To: <0E5E519E-F386-4AAC-B579-206A7DA1A963@opencsw.org>
References: <54654FA3.2000003@opencsw.org>
	<297E2296-5C3F-4540-B203-2A5E2F9E5A3D@opencsw.org>
	<54675EEA.1040006@opencsw.org>
	<A337D37E-B9DB-4B6F-A95A-5F7FCBC4AD52@opencsw.org>
	<5469D591.8060305@libero.it>
	<C72640C6-0797-4643-A7DC-98B7A5993A39@opencsw.org>
	<546F518C.4080602@libero.it>
	<70D156D3-3026-4E65-8703-BB7F427086EF@opencsw.org>
	<0E5E519E-F386-4AAC-B579-206A7DA1A963@opencsw.org>
Message-ID: <548CC1EB.6040805@opencsw.org>

Hi,

sorry for the delays, but packaging was a bit left behind, I tested your 
changes locally, but am blocked by other problems.

>
> CHECKPKG_OVERRIDES_CSWgnustep-base += file-with-bad-content|/usr/local|root/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7
> CHECKPKG_OVERRIDES_CSWgnustep-base += file-with-bad-content|/usr/share|root/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7
> These are for zoneinfo, there are a number of locations used, the only one should be
>    /usr/share/lib/zoneinfo
> and then override the /usr/share, but make sure to skip /usr/local as it is really ugly.
What do you mean here, by skip and override? What actions could I do to 
fix the problem? Fix the sourcecode itself?
I found this inside:

nstzfile.h:#define TZDIR    "/usr/local/etc/zoneinfo" /* Time zone 
object file directory */

>
>> CHECKPKG_OVERRIDES_CSWgnustep-base += no-direct-binding|/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7|is|not|directly|bound|to|soname|libffi.so.5
>> ?
> This is because LD_OPTIONS is not inherited. It is an environment-variable with the value
>         LD_OPTIONS = -R/opt/csw/GNUstep/System/Library/Libraries/$ISALIST -R/opt/csw/GNUstep/System/Library/Libraries -R/opt/csw/lib/$ISALIST -R/opt/csw/lib -M /home/dam/mgar/pkg/.buildsys/v2/gar/lib/map.solaris10 -B direct -z ignore
> Please note the ?-B direct? which is missing in the resulting binaries.
where is it not inherited? while running confiure?

I tried this:

LDFLAGS += -Bdirect

CONFIGURE_ARGS = $(DIRPATHS) $(LDFLAGS)

this yields to this while running "mgar configure":

         [patch-modulated] complete for gnustep-base.
HOME="/home/rmottola" 
PATH="/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin:/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin:/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/sbin:/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/rmottola/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" 
LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" 
bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" 
libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" 
sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" 
localstatedir="/var/opt/csw" libdir="/opt/csw/lib" 
infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" 
includedir="/opt/csw/include" mandir="/opt/csw/share/man" 
docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" 
CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 
-Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" 
LDFLAGS="-Bdirect" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" 
FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" 
F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" 
ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" 
CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" 
CC_VERSION="gcc version 4.9.2 (GCC) " CXX_VERSION="gcc version 4.9.2 
(GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" 
LD_OPTIONS="-R/opt/csw/GNUstep/System/Library/Libraries/\$ISALIST 
-R/opt/csw/GNUstep/System/Library/Libraries -R/opt/csw/lib/\$ISALIST 
-R/opt/csw/lib -M 
/home/rmottola/opencsw/.buildsys/v2/gar/lib/map.solaris10 -B direct -z 
ignore" PKG_CONFIG_PATH="/opt/csw/lib/pkgconfig" 
DESTDIR="/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus" 
&& . /opt/csw/GNUstep/System/Library/Makefiles/GNUstep.sh && cd 
work/solaris10-sparc/build-isa-sparcv8plus/gnustep-base-1.24.7 && 
./configure --prefix=/opt/csw --exec_prefix=/opt/csw 
--bindir=/opt/csw/bin --sbindir=/opt/csw/sbin 
--libexecdir=/opt/csw/libexec --datadir=/opt/csw/share 
--sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share 
--localstatedir=/var/opt/csw --libdir=/opt/csw/lib 
--infodir=/opt/csw/share/info --includedir=/opt/csw/include 
--mandir=/opt/csw/share/man -Bdirect
configure: error: unrecognized option: `-Bdirect'

I can see that -B direct (space) is passed inside LD_OPTIONS, but then 
my options ( I found this variant without spaces in linux forums) make 
it fail.

Are you meaning by "inherited" that this package configure script is 
ignoring LD_OPTIONS? that will be perhaps harder to fix then

Thanks,

Riccardo

From dam at opencsw.org  Sun Dec 14 18:05:06 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 14 Dec 2014 18:05:06 +0100
Subject: gnustep-base, package warnings
In-Reply-To: <548CC1EB.6040805@opencsw.org>
References: <54654FA3.2000003@opencsw.org>
	<297E2296-5C3F-4540-B203-2A5E2F9E5A3D@opencsw.org>
	<54675EEA.1040006@opencsw.org>
	<A337D37E-B9DB-4B6F-A95A-5F7FCBC4AD52@opencsw.org>
	<5469D591.8060305@libero.it>
	<C72640C6-0797-4643-A7DC-98B7A5993A39@opencsw.org>
	<546F518C.4080602@libero.it>
	<70D156D3-3026-4E65-8703-BB7F427086EF@opencsw.org>
	<0E5E519E-F386-4AAC-B579-206A7DA1A963@opencsw.org>
	<548CC1EB.6040805@opencsw.org>
Message-ID: <E68F8309-977C-483A-8AC4-C0C1A6C644FB@opencsw.org>

Hi Riccardo,

> Am 13.12.2014 um 23:47 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> sorry for the delays, but packaging was a bit left behind, I tested your changes locally, but am blocked by other problems.
> 
>> 
>> CHECKPKG_OVERRIDES_CSWgnustep-base += file-with-bad-content|/usr/local|root/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7
>> CHECKPKG_OVERRIDES_CSWgnustep-base += file-with-bad-content|/usr/share|root/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7
>> These are for zoneinfo, there are a number of locations used, the only one should be
>>   /usr/share/lib/zoneinfo
>> and then override the /usr/share, but make sure to skip /usr/local as it is really ugly.
> 
> What do you mean here, by skip and override? What actions could I do to fix the problem? Fix the sourcecode itself?
> I found this inside:
> 
> nstzfile.h:#define TZDIR    "/usr/local/etc/zoneinfo" /* Time zone object file directory */

That means you should use
  CHECKPKG_OVERRIDES_CSWgnustep-base += file-with-bad-content|/usr/share|root/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7
to silence the warning about /usr/share and reinplace/patch the occurrences
of /usr/local as these are probably harmful.

>>> CHECKPKG_OVERRIDES_CSWgnustep-base += no-direct-binding|/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7|is|not|directly|bound|to|soname|libffi.so.5
>>> ?
>> This is because LD_OPTIONS is not inherited. It is an environment-variable with the value
>>        LD_OPTIONS = -R/opt/csw/GNUstep/System/Library/Libraries/$ISALIST -R/opt/csw/GNUstep/System/Library/Libraries -R/opt/csw/lib/$ISALIST -R/opt/csw/lib -M /home/dam/mgar/pkg/.buildsys/v2/gar/lib/map.solaris10 -B direct -z ignore
>> Please note the ?-B direct? which is missing in the resulting binaries.
> where is it not inherited? while running confiure?
> 
> I tried this:
> 
> LDFLAGS += -Bdirect
> 
> CONFIGURE_ARGS = $(DIRPATHS) $(LDFLAGS)
> 
> this yields to this while running "mgar configure":
> 
>        [patch-modulated] complete for gnustep-base.
> HOME="/home/rmottola" PATH="/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin:/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin:/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/sbin:/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/rmottola/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" LDFLAGS="-Bdirect" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" CC_VERSION="gcc version 4.9.2 (GCC) " CXX_VERSION="gcc version 4.9.2 (GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/GNUstep/System/Library/Libraries/\$ISALIST -R/opt/csw/GNUstep/System/Library/Libraries -R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -M /home/rmottola/opencsw/.buildsys/v2/gar/lib/map.solaris10 -B direct -z ignore" PKG_CONFIG_PATH="/opt/csw/lib/pkgconfig" DESTDIR="/home/rmottola/opencsw/gnustep-base/trunk/work/solaris10-sparc/install-isa-sparcv8plus" && . /opt/csw/GNUstep/System/Library/Makefiles/GNUstep.sh && cd work/solaris10-sparc/build-isa-sparcv8plus/gnustep-base-1.24.7 && ./configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man -Bdirect
> configure: error: unrecognized option: `-Bdirect'
> 
> I can see that -B direct (space) is passed inside LD_OPTIONS, but then my options ( I found this variant without spaces in linux forums) make it fail.

You can not just pass arbitrary flags to configure, they must be used in proper
contexts.

> Are you meaning by "inherited" that this package configure script is ignoring LD_OPTIONS? that will be perhaps harder to fix then

I would think so. LD_OPTIONS is not working by being picked up during Makefile execution, but
when the environment variable is assigned the linker picks up the flags automatically prior
to the flags from the commandline.


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/20141214/477772ed/attachment.p7s>

From rmottola at opencsw.org  Tue Dec 16 09:39:46 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Tue, 16 Dec 2014 09:39:46 +0100
Subject: problem committing (from my own box)
In-Reply-To: <CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
Message-ID: <1418719186.987.5.camel@anor>

Hello,

On Sun, 2014-12-07 at 23:34, Maciej (Matchek) Blizi?ski wrote:
> 2014-12-07 18:28 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> > Authentication realm: <https://svn.code.sf.net:443> SourceForge User
> > Password for 'rmottola': **********
> 
> You can't commit via https. You need to check out using the read+write
> link e.g. from https://sourceforge.net/p/gar/code/HEAD/tree/

I never checked out myself, I used "mgar init" ! and I was able to
commit in the past for sure.

I moved aside my current tree and redid a "mgar init", I get this
failure:

A    opencsw/.buildsys/bts/etc/commondirs-i386
A    opencsw/.buildsys/bts/Makefile
A    opencsw/.buildsys/bts/garrc.sample
Checked out revision 24459.
svn: E175013: Unable to connect to a repository at URL
'https://svn.code.sf.net/p/gar/code/csw/mgar/pkg'
svn: E175013: Access to '/p/gar/code/csw/mgar/pkg' forbidden


Did some configuration change? Do I need to perform a check-out manually
instead of mgar init?

If I try your link above:
svn co https://sourceforge.net/p/gar/code/HEAD/tree/

I get:
svn: E175011: Unable to connect to a repository at URL
'https://sourceforge.net/p/gar/code/HEAD/tree'
svn: E175011: Repository moved temporarily to
'http://sourceforge.net/p/gar/code/HEAD/tree'; please relocate


Perhaps this relocation is the reason for failure? Should I check out
from http instead? In the same directory mgar init is configured for?

Thank you

Riccardo


From maciej at opencsw.org  Tue Dec 16 10:53:02 2014
From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=)
Date: Tue, 16 Dec 2014 09:53:02 +0000
Subject: problem committing (from my own box)
In-Reply-To: <1418719186.987.5.camel@anor>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
Message-ID: <20141216095302.GA8836@cotton.home.blizinski.pl>

On Tue, Dec 16, 2014 at 09:39:46AM +0100, Riccardo Mottola wrote:
> Did some configuration change? Do I need to perform a check-out manually
> instead of mgar init?

Ideally we would adjust mgar init to do the right thing.

> If I try your link above:
> svn co https://sourceforge.net/p/gar/code/HEAD/tree/

It's not the URL I suggested; you need to access this link after logging
in, so you get the read+write URL. After you log in, this URL says
explicitly: "Read/Write access".

> I get:
> svn: E175011: Unable to connect to a repository at URL
> 'https://sourceforge.net/p/gar/code/HEAD/tree'
> svn: E175011: Repository moved temporarily to
> 'http://sourceforge.net/p/gar/code/HEAD/tree'; please relocate
> 
> 
> Perhaps this relocation is the reason for failure? Should I check out
> from http instead? In the same directory mgar init is configured for?

SF made a change some months ago. I adjusted my checkout tree by hand,
without mgar, most people probably did.

Riccardo, could you fix mgar init?

Maciej

From rmottola at opencsw.org  Wed Dec 17 13:15:11 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 17 Dec 2014 13:15:11 +0100
Subject: problem committing (from my own box)
In-Reply-To: <20141216095302.GA8836@cotton.home.blizinski.pl>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
	<20141216095302.GA8836@cotton.home.blizinski.pl>
Message-ID: <1418818510.16308.8.camel@anor>

Hi,

On Tue, 2014-12-16 at 10:53, Maciej Blizi?ski wrote:
> On Tue, Dec 16, 2014 at 09:39:46AM +0100, Riccardo Mottola wrote:
> > Did some configuration change? Do I need to perform a check-out manually
> > instead of mgar init?
> 
> Ideally we would adjust mgar init to do the right thing.
> 
> > If I try your link above:
> > svn co https://sourceforge.net/p/gar/code/HEAD/tree/
> 
> It's not the URL I suggested; you need to access this link after logging
> in, so you get the read+write URL. After you log in, this URL says
> explicitly: "Read/Write access".

Yes, sorry... the new SF.net interface is quite confusing, just as a
reference, this is what I get:

svn checkout --username=<username>
svn+ssh://<username>@svn.code.sf.net/p/gar/code/ gar-code

where username is of course mine.

I notice that your link checks out much more than what "mgar init" does,
the two trees are not the same.


> > I get:
> > svn: E175011: Unable to connect to a repository at URL
> > 'https://sourceforge.net/p/gar/code/HEAD/tree'
> > svn: E175011: Repository moved temporarily to
> > 'http://sourceforge.net/p/gar/code/HEAD/tree'; please relocate
> > 
> > 
> > Perhaps this relocation is the reason for failure? Should I check out
> > from http instead? In the same directory mgar init is configured for?
> 
> SF made a change some months ago. I adjusted my checkout tree by hand,
> without mgar, most people probably did.

Can I tweak my svn entries without re-checking out everything again?
Would be nice. That would get me quick working on my packages, together
with the stuff I have not commited yet.

> 
> Riccardo, could you fix mgar init?

Glad... where in the code should I look? If it is just tweaking some
URLs it shouldn't be hard. Is the code inside what "mgar init" checks
out? or d I need csw/mgar/gar

I guess this is all obvious for you long-timers, but it is a big repo
and it slgihtly confuses me.

Riccardo


From maciej at opencsw.org  Wed Dec 17 13:18:23 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Wed, 17 Dec 2014 12:18:23 +0000
Subject: problem committing (from my own box)
In-Reply-To: <1418818510.16308.8.camel@anor>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
	<20141216095302.GA8836@cotton.home.blizinski.pl>
	<1418818510.16308.8.camel@anor>
Message-ID: <CALtRa-7jd9qsDASSgAZs5Gs0cKXUtMa5PRhV36kREJs1-meMCQ@mail.gmail.com>

2014-12-17 12:15 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
>> Riccardo, could you fix mgar init?
>
> Glad... where in the code should I look? If it is just tweaking some
> URLs it shouldn't be hard. Is the code inside what "mgar init" checks
> out? or d I need csw/mgar/gar

Yes, this repo is big, and the code isn't even in it! Look here:

https://sourceforge.net/p/opencsw/code/HEAD/tree/gar-wrapper/

Apart from these two there is at least one more repo that I'm aware of.

From rmottola at opencsw.org  Wed Dec 17 14:56:56 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 17 Dec 2014 14:56:56 +0100
Subject: problem committing (from my own box)
In-Reply-To: <1418818510.16308.8.camel@anor>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
	<20141216095302.GA8836@cotton.home.blizinski.pl>
	<1418818510.16308.8.camel@anor>
Message-ID: <1418824615.204.8.camel@anor>

Hi,

I reply to myself to ask for confirmation:

On Wed, 2014-12-17 at 13:15, Riccardo Mottola wrote:

> > 
> > SF made a change some months ago. I adjusted my checkout tree by hand,
> > without mgar, most people probably did.
> 
> Can I tweak my svn entries without re-checking out everything again?
> Would be nice. That would get me quick working on my packages, together
> with the stuff I have not commited yet.
> 

I suppose the trick is to use "svn relocate" right?

my current svn repo, created by mgar init, has:

URL: https://svn.code.sf.net/p/gar/code/csw/mgar/pkg
Relative URL: ^/csw/mgar/pkg
Repository Root: https://svn.code.sf.net/p/gar/code

and relocate to

svn+ssh://rmottola at svn.code.sf.net/p/gar/code/csw/mgar/pkg

what do you think?

Riccardo


From dam at opencsw.org  Wed Dec 17 15:08:12 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 17 Dec 2014 15:08:12 +0100
Subject: problem committing (from my own box)
In-Reply-To: <1418824615.204.8.camel@anor>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
	<20141216095302.GA8836@cotton.home.blizinski.pl>
	<1418818510.16308.8.camel@anor> <1418824615.204.8.camel@anor>
Message-ID: <06BB9C82-33EC-4AF3-9B4C-41DC90817E27@opencsw.org>

Hi Riccardo,

> Am 17.12.2014 um 14:56 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> I reply to myself to ask for confirmation:
> 
> On Wed, 2014-12-17 at 13:15, Riccardo Mottola wrote:
> 
>>> 
>>> SF made a change some months ago. I adjusted my checkout tree by hand,
>>> without mgar, most people probably did.
>> 
>> Can I tweak my svn entries without re-checking out everything again?
>> Would be nice. That would get me quick working on my packages, together
>> with the stuff I have not commited yet.
>> 
> 
> I suppose the trick is to use "svn relocate" right?
> 
> my current svn repo, created by mgar init, has:
> 
> URL: https://svn.code.sf.net/p/gar/code/csw/mgar/pkg
> Relative URL: ^/csw/mgar/pkg
> Repository Root: https://svn.code.sf.net/p/gar/code
> 
> and relocate to
> 
> svn+ssh://rmottola at svn.code.sf.net/p/gar/code/csw/mgar/pkg
> 
> what do you think?

Exactly, as Sourceforge also describes at
  http://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/


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/20141217/c1236485/attachment.p7s>

From rmottola at opencsw.org  Wed Dec 17 18:40:09 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 17 Dec 2014 18:40:09 +0100
Subject: problem committing (from my own box)
In-Reply-To: <06BB9C82-33EC-4AF3-9B4C-41DC90817E27@opencsw.org>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
	<20141216095302.GA8836@cotton.home.blizinski.pl>
	<1418818510.16308.8.camel@anor> <1418824615.204.8.camel@anor>
	<06BB9C82-33EC-4AF3-9B4C-41DC90817E27@opencsw.org>
Message-ID: <1418838009.204.11.camel@anor>

Hi,

On Wed, 2014-12-17 at 15:08, Dagobert Michelsen wrote:

> > I suppose the trick is to use "svn relocate" right?
> > 
> > my current svn repo, created by mgar init, has:
> > 
> > URL: https://svn.code.sf.net/p/gar/code/csw/mgar/pkg
> > Relative URL: ^/csw/mgar/pkg
> > Repository Root: https://svn.code.sf.net/p/gar/code
> > 
> > and relocate to
> > 
> > svn+ssh://rmottola at svn.code.sf.net/p/gar/code/csw/mgar/pkg
> > 
> > what do you think?
> 
> Exactly, as Sourceforge also describes at
>   http://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/
> 

Just for the record, it worked! I can commit now.

I am updating all gnustep related makefiles to the improvements you did
with gnustep-base.
Though there are still problems with the LD_OPTIONS, I am checking that
everything works, compilig locally uncommited packages and checking that
they do work.

Riccardo


From rmottola at opencsw.org  Wed Dec 17 18:53:00 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 17 Dec 2014 18:53:00 +0100
Subject: problem committing (from my own box)
In-Reply-To: <CALtRa-7jd9qsDASSgAZs5Gs0cKXUtMa5PRhV36kREJs1-meMCQ@mail.gmail.com>
References: <54849C59.2010001@opencsw.org>
	<CALtRa-5Q0GOAUZBop-RXZe-FPZkF5-7PW60+JVTB2ROAMB87Sw@mail.gmail.com>
	<1418719186.987.5.camel@anor>
	<20141216095302.GA8836@cotton.home.blizinski.pl>
	<1418818510.16308.8.camel@anor>
	<CALtRa-7jd9qsDASSgAZs5Gs0cKXUtMa5PRhV36kREJs1-meMCQ@mail.gmail.com>
Message-ID: <1418838780.204.25.camel@anor>

Hi,

On Wed, 2014-12-17 at 13:18, Maciej (Matchek) Blizi?ski wrote:
> 2014-12-17 12:15 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> >> Riccardo, could you fix mgar init?
> >
> > Glad... where in the code should I look? If it is just tweaking some
> > URLs it shouldn't be hard. Is the code inside what "mgar init" checks
> > out? or d I need csw/mgar/gar
> 
> Yes, this repo is big, and the code isn't even in it! Look here:
> 
> https://sourceforge.net/p/opencsw/code/HEAD/tree/gar-wrapper/
> 
> Apart from these two there is at least one more repo that I'm aware of.

I checked out the source code and fount that gar uses these URLs

SVN_SELF=https://svn.code.sf.net/p/opencsw/code/gar-wrapper/mgar
GAR_REPO=https://svn.code.sf.net/p/gar/code/csw/mgar/gar/
PKG_REPO=https://svn.code.sf.net/p/gar/code/csw/mgar/pkg/

I suppose the only one needing a username would be GAR_REPO, but we
don't have the username inside the script to generate the more complex
URL, right?

something like:
GAR_REPO=svn+ssh://$SF_USERNAME at svn.code.sf.net/p/gar/code/csw/mgar/pkg

and then later:
svn co $GAR_REPO "$__buildtree/.buildsys"

becomes:
svn co --username=$SF_USERNAME $GAR_REPO "$__buildtree/.buildsys"

but I don't know where the username should reside, perhaps .garrc?

Riccardo


From bwalton at opencsw.org  Tue Dec 23 11:25:27 2014
From: bwalton at opencsw.org (Ben Walton)
Date: Tue, 23 Dec 2014 10:25:27 +0000
Subject: git for the stable catalog
Message-ID: <CAP30j17jCe1of8K9rgzOMgqnj4QzhFSv-QK_RzxS0kZO8m502A@mail.gmail.com>

Hi All,

I need to update git for the stable catalog to address CVE-2014-9390. I've
rolled 2.2.1 for unstable and released it. The stable catalog currently has
1.8.4.

I can force 2.2.1 to stable, but it's a major version bump and has some
incompatibilities with the 1.8 series. How are others building for stable,
if at all?

Thanks
-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141223/2639b780/attachment.html>

From rupert at opencsw.org  Tue Dec 23 13:43:01 2014
From: rupert at opencsw.org (rupert THURNER)
Date: Tue, 23 Dec 2014 13:43:01 +0100
Subject: example for working github configuration
In-Reply-To: <CALtRa-6-HotjYC93KsP8taz0s0i+-U_kCfkXXd0rrAJEHKc9Vw@mail.gmail.com>
References: <CAJs9aZ8ZDUAnhDCQSoRFpRrBJVt5iyXwf-6ju-9gjpn3O3r2vw@mail.gmail.com>
	<CALtRa-6-HotjYC93KsP8taz0s0i+-U_kCfkXXd0rrAJEHKc9Vw@mail.gmail.com>
Message-ID: <CAJs9aZ9Rv6Zk+7KFF4_A6xwaNQ7vEs7AFQbqCAg9+nPhuS8LfQ@mail.gmail.com>

On Sun, Nov 30, 2014 at 6:20 PM, Maciej (Matchek) Blizi?ski
<maciej at opencsw.org> wrote:
> 2014-11-30 12:37 GMT+00:00 rupert THURNER <rupert at opencsw.org>:
>> but i can enter whatever i want, it does not fail on fetching the
>> contents but later on.
>
> Are you looking for a working github configuration, or presenting an
> example of working github configuration?

i am looking for a working github configuration.

From dam at opencsw.org  Tue Dec 23 23:39:34 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 23 Dec 2014 23:39:34 +0100
Subject: [gar:code] [r24511] - rthurner: trac, ignore checkpkg errors.
In-Reply-To: <3aea3ce5da1fa0a37c312d0dc83ce0d3f5e9d4b7.code@gar.p.sourceforge.net>
References: <3aea3ce5da1fa0a37c312d0dc83ce0d3f5e9d4b7.code@gar.p.sourceforge.net>
Message-ID: <F9B35028-6B25-4B31-BD69-98C11A272FF8@opencsw.org>

Hi Rupert,

> Am 23.12.2014 um 23:29 schrieb Repository GAR Solaris Package Build System code <noreply at code.gar.p.re.sf.net>:
> trac, ignore checkpkg errors. http://sourceforge.net/p/gar/code/24511/

Please do not override the dependency-on-stub error:
  http://wiki.opencsw.org/checkpkg-error-tags#toc17

The package name is now the normalized CSWpy-setuptools instead of CSWpysetuptools.

I can only again point to the above page when there is doubt about when to override
(and when not to) an checkpkg error.


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/20141223/d2272f65/attachment.p7s>

From rmottola at opencsw.org  Wed Dec 24 16:41:46 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Wed, 24 Dec 2014 16:41:46 +0100
Subject: EXTRA_RUNPATH_DIRS, LD_OPTIONS an B direct
Message-ID: <549ADEBA.2050608@opencsw.org>

Hi,

during the building of GNUstep base package, the only mass of warnings I 
have is about two quite similar problems, but proably still different.

CHECKPKG_OVERRIDES_CSWgnustep-base += 
no-direct-binding|/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7|is|not|directly|bound|to|soname|libffi.so.5

This is the library I am building against an existing library.

Now, Dagobert explains to me that the problem is related to LD_OPTIONS 
and the -B direct flag.
My problem is understanding better LD_OPTIONS and their interaction with 
configure.

GNUstep's configure is "LDFLAGs" aware and will push them down to the 
make. LD_OPTIONS is instead just ignored and not messed with (I asked 
some of the GNUstep guys).

I understand that gar tries already to set the correct LD_OPTIONS, but 
they do not get used.

First, what are LD_OPTIONS? They seem to be something quite specific to 
Soalris, similar to LDFLAGS but not equivalent.

How do you handle this with other packages using configure? Is it only 
me running into this problem?


as well as

CHECKPKG_OVERRIDES_CSWgnustep-base += soname-not-found|libgnustep-base.so.1.24|is|needed|by|opt/csw/GNUstep/System/Tools/gdnc

which is different since it is some of the tools against the library itself being built.
Here Dago suggests setting EXTRA_RUNPATH_DIRS.

I added in my Makefile
EXTRA_RUNPATH_DIRS = /opt/csw/GNUstep/System/Library/Libraries

but I still get the warning!


Riccardo


From maciej at opencsw.org  Thu Dec 25 12:05:57 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Thu, 25 Dec 2014 11:05:57 +0000
Subject: git for the stable catalog
References: <CAP30j17jCe1of8K9rgzOMgqnj4QzhFSv-QK_RzxS0kZO8m502A@mail.gmail.com>
Message-ID: <CALtRa-7+vFiztXupmop6NdK0Fx_5x0fcwF0Aqi26b3PHy-Kjxw@mail.gmail.com>

Ben Walton <bwalton at opencsw.org> escreveu no dia Tue Dec 23 2014 at
10:25:46:

> I need to update git for the stable catalog to address CVE-2014-9390. I've
> rolled 2.2.1 for unstable and released it. The stable catalog currently has
> 1.8.4.
>
> I can force 2.2.1 to stable, but it's a major version bump and has some
> incompatibilities with the 1.8 series. How are others building for stable,
> if at all?
>

We had the dublin10s and dublin10x machines, They are now configured to
pull packages from the testing catalog.

Our stable is kiel, which isn't that far out from munich. It's possible
that you can push the same set of packages to stable.

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141225/07f836a2/attachment.html>

From maciej at opencsw.org  Sun Dec 28 20:21:03 2014
From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=)
Date: Sun, 28 Dec 2014 19:21:03 +0000
Subject: Tweet from tomww (@tomww)
Message-ID: <CALtRa-7vsb=yyfwMYBbm0ZcDDgj16KMDx-2CvQ45Wm7db7btfg@mail.gmail.com>

tomww (@tomww) tweetou ?s 7:06 da tarde on dom, Dez 28, 2014:
@phaus
@xattack
@cpj1
@opensolaris
@bahamat
@opencsw
Anyone of you attending #31C3?
Would enjoy talking w/ u about FOSS packages
(https://twitter.com/tomww/status/549280315370635264?s=03)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20141228/5581b223/attachment.html>

From ihsan at opencsw.org  Sun Dec 28 20:37:47 2014
From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=)
Date: Sun, 28 Dec 2014 20:37:47 +0100
Subject: Tweet from tomww (@tomww)
In-Reply-To: <CALtRa-7vsb=yyfwMYBbm0ZcDDgj16KMDx-2CvQ45Wm7db7btfg@mail.gmail.com>
References: <CALtRa-7vsb=yyfwMYBbm0ZcDDgj16KMDx-2CvQ45Wm7db7btfg@mail.gmail.com>
Message-ID: <54A05C0B.5040308@opencsw.org>

Am 28.12.2014 um 20:21 schrieb Maciej (Matchek) Blizi?ski:

> tomww (@tomww) tweetou ?s 7:06 da tarde on dom, Dez 28, 2014:
> @phaus
> @xattack
> @cpj1
> @opensolaris
> @bahamat
> @opencsw
> Anyone of you attending #31C3?
> Would enjoy talking w/ u about FOSS packages
> (https://twitter.com/tomww/status/549280315370635264?s=03)

Unfortunately I couldn't make it to Hamburg. Maybe next year.



Ihsan

-- 
ihsan at dogan.ch        http://blog.dogan.ch/

From dam at opencsw.org  Mon Dec 29 13:17:51 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 29 Dec 2014 13:17:51 +0100
Subject: EXTRA_RUNPATH_DIRS, LD_OPTIONS an B direct
In-Reply-To: <549ADEBA.2050608@opencsw.org>
References: <549ADEBA.2050608@opencsw.org>
Message-ID: <2C4A66BC-EB65-4F7F-B013-21C361147270@opencsw.org>

Hi Riccardo,

> Am 24.12.2014 um 16:41 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> Hi,
> 
> during the building of GNUstep base package, the only mass of warnings I have is about two quite similar problems, but proably still different.
> 
> CHECKPKG_OVERRIDES_CSWgnustep-base += no-direct-binding|/opt/csw/GNUstep/System/Library/Libraries/libgnustep-base.so.1.24.7|is|not|directly|bound|to|soname|libffi.so.5
> 
> This is the library I am building against an existing library.
> 
> Now, Dagobert explains to me that the problem is related to LD_OPTIONS and the -B direct flag.
> My problem is understanding better LD_OPTIONS and their interaction with configure.
> 
> GNUstep's configure is "LDFLAGs" aware and will push them down to the make. LD_OPTIONS is instead just ignored and not messed with (I asked some of the GNUstep guys).
> 
> I understand that gar tries already to set the correct LD_OPTIONS, but they do not get used.
> 
> First, what are LD_OPTIONS? They seem to be something quite specific to Soalris, similar to LDFLAGS but not equivalent.
> 
> How do you handle this with other packages using configure? Is it only me running into this problem?

Please see ld(1):

     LD_OPTIONS

         A default set of options to  ld.  LD_OPTIONS  is  inter-
         preted by ld just as though its value had been placed on
         the command line, immediately following the name used to
         invoke ld, as in:

           ld $LD_OPTIONS ... other-arguments ?

That means if the environment variable is set it is used directly without knowledge
to the build system. Unless the environment is cleared this is always honoured first.
LDFLAGS is not used at all by the linker, it is interpreted by the build system and
then substituted to the option list of the commandline when the linker is called.


> as well as
> 
> CHECKPKG_OVERRIDES_CSWgnustep-base += soname-not-found|libgnustep-base.so.1.24|is|needed|by|opt/csw/GNUstep/System/Tools/gdnc
> 
> which is different since it is some of the tools against the library itself being built.
> Here Dago suggests setting EXTRA_RUNPATH_DIRS.
> 
> I added in my Makefile
> EXTRA_RUNPATH_DIRS = /opt/csw/GNUstep/System/Library/Libraries
> 
> but I still get the warning!

Try ldd -r on libgnustep-base.so.1.24 and see if all libraries are found. If not inspect
with dump -Lv to see the RPATH and make sure all directories with linked libs are in the
RPATH. This is also explained at
  http://wiki.opencsw.org/checkpkg-error-tags#toc54


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/20141229/aca9cd3b/attachment.p7s>

From rmottola at opencsw.org  Mon Dec 29 18:51:55 2014
From: rmottola at opencsw.org (Riccardo Mottola)
Date: Mon, 29 Dec 2014 18:51:55 +0100
Subject: gnutar vs gtar ?
In-Reply-To: <CALtRa-7iF2X7ysvmi-M0Xn=-ts843E9DX6h1a_fz0vjjwifnYw@mail.gmail.com>
References: <54849B24.4050603@opencsw.org>	<CALtRa-5U+bRhFWVmHSxDW=xg9hfO3oBHa+pynA1ceMe21DvTwg@mail.gmail.com>	<5484EB6C.9020608@opencsw.org>
	<CALtRa-7iF2X7ysvmi-M0Xn=-ts843E9DX6h1a_fz0vjjwifnYw@mail.gmail.com>
Message-ID: <54A194BB.8090505@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> Riccardo Mottola <rmottola at opencsw.org <mailto:rmottola at opencsw.org>> 
> escreveu no dia Sun Dec 07 2014 at 23:04:25:
>
>     AC_CHECK_PROGS(TAR, gnutar gtar, tar)
>
>     this should actually check for gnustar first, gtar then.. and as
>     fallback use tar, right?
>
>
> Yes. Are there any logs from this? Did it find gnutar anywhere? If so, 
> where?
the logs showed no errors, however I re-run configure (essentially, I 
redid the package) and now it works. I'd say everything is fine.

Riccardo