On Apr 21, 2010, at 9:06 PM, Jack Howarth wrote:
> On Wed, Apr 21, 2010 at 07:17:03PM -0700, Trevor Harmon wrote:
>> On Apr 20, 2010, at 11:06 AM, Jack Howarth wrote:
>>
>>> Why hasn't classpath been upgraded to gcc44 yet?
>>
>> I've not had a reason to do so, and nobody requested it.
>>
>> Tr
On Wed, Apr 21, 2010 at 07:17:03PM -0700, Trevor Harmon wrote:
> On Apr 20, 2010, at 11:06 AM, Jack Howarth wrote:
>
> > Why hasn't classpath been upgraded to gcc44 yet?
>
> I've not had a reason to do so, and nobody requested it.
>
> Trevor
Trevor,
The recent trend with gcc4X package depe
On Apr 20, 2010, at 11:06 AM, Jack Howarth wrote:
> Why hasn't classpath been upgraded to gcc44 yet?
I've not had a reason to do so, and nobody requested it.
Trevor
--
___
On Apr 20, 2010, at 11:35 AM, Jack Howarth wrote:
> One other question, do the packages that require gclasspath currently
> work fine on i386 and x86_64 fink?
I believe the only package that requires gclasspath is jamvm, but I've not
tested it on x86_64.
Trevor
---
Jean-François Mertens wrote:
[]
> [ Under melina, "options_machine FC_name" or "options_machine LINKER"
> currently yield just the plain "gfortran", and nothing in done in the
> info file
> to force this. ]
That's right, melina simply needs a working gfortran and a working C
compiler. The ideal
On Apr 20, 2010, at 6:01 AM, Jean-François Mertens wrote:
> For gclasspath, from reading its DescPackaging,
> the dep is not needed.
> So it might be best to switch that dep to a Recommends..
> _ Trevor ?
gclasspath is dependent on gcc43 because both packages provide some of the same
files (e.g.
On Tue, Apr 20, 2010 at 10:55:50AM -0700, Trevor Harmon wrote:
> On Apr 20, 2010, at 6:01 AM, Jean-François Mertens wrote:
>
> > For gclasspath, from reading its DescPackaging,
> > the dep is not needed.
> > So it might be best to switch that dep to a Recommends..
> > _ Trevor ?
>
> gclasspath is
On Tue, Apr 20, 2010 at 10:55:50AM -0700, Trevor Harmon wrote:
> On Apr 20, 2010, at 6:01 AM, Jean-François Mertens wrote:
>
> > For gclasspath, from reading its DescPackaging,
> > the dep is not needed.
> > So it might be best to switch that dep to a Recommends..
> > _ Trevor ?
>
> gclasspath is
Am 20.04.2010 um 17:33 schrieb JF Mertens:
> Jean-François Mertens wrote:
>>
>> I'd suggest just use update-alternatives...
>
> Max Horn wrote:
>>
>> The correct solution would be to just use update-alternatives.
>
>
> Done now for libffi.
> Jack, you can basically copy it for gcc45;
> just
Jean-François Mertens wrote:
>
> I'd suggest just use update-alternatives...
Max Horn wrote:
>
> The correct solution would be to just use update-alternatives.
Done now for libffi.
Jack, you can basically copy it for gcc45;
just use 50 for priority (same priority
might possibly confuse update-a
On 20 Apr 2010, at 15:27, Jack Howarth wrote:
> On Tue, Apr 20, 2010 at 03:01:21PM +0200, Jean-François Mertens wrote:
> I have been pondering the idea of adding a gcc45-dev splitoff
> that would contain the %p/bin compiler symlinks so that the
> Conflicts
Depends
> could be changed from gcc4x t
On Tue, Apr 20, 2010 at 03:01:21PM +0200, Jean-François Mertens wrote:
>
> On 19 Apr 2010, at 21:03, Peter O'Gorman wrote:
>
>> What was the solution for the issue of some packages having depends on
>> gcc44?
>
> Had this problem only with gclasspath and melina
> "de facto" solution was clearly to
On 19 Apr 2010, at 21:03, Peter O'Gorman wrote:
> What was the solution for the issue of some packages having depends on
> gcc44?
Had this problem only with gclasspath and melina
"de facto" solution was clearly to use --forece-depends,
then switched deps of 2 pkgs and rebuild them.
I don't thin
Am 16.04.2010 um 03:22 schrieb Jean-François Mertens:
>
>>> On Thu, Apr 15, 2010 at 05:53:57AM +0200, Jean-François Mertens
>>> wrote:
Hi Jack,
I just updated libffi to check on that;
I guess the same conflict will remain,
so _ either the 2 manpages are essentii
On 04/19/2010 02:13 PM, Jack Howarth wrote:
> On Mon, Apr 19, 2010 at 02:03:42PM -0500, Peter O'Gorman wrote:
>> What was the solution for the issue of some packages having depends on
>> gcc44?
>>
>> Sorry, didn't get around to doing this yet, weekend was much too sunny.
>>
>> Peter
>
> Peter,
>
On Mon, Apr 19, 2010 at 02:03:42PM -0500, Peter O'Gorman wrote:
> What was the solution for the issue of some packages having depends on
> gcc44?
>
> Sorry, didn't get around to doing this yet, weekend was much too sunny.
>
> Peter
Peter,
If these are packages which expect to access the FSF g
What was the solution for the issue of some packages having depends on
gcc44?
Sorry, didn't get around to doing this yet, weekend was much too sunny.
Peter
--
Download Intel® Parallel Studio Eval
Try the new software too
On 16 Apr 2010, at 15:04, Jack Howarth wrote:
> Jean-Francois,
> Are you testing with the gcc45 packaging I posted last night
> that now uses update-alternatives for the offending man pages?
No _this was with the previous version (parallel builds (both
on 32bit and 64bit fink) of gcc take some
>> On Thu, Apr 15, 2010 at 05:53:57AM +0200, Jean-François Mertens
>> wrote:
>>>
>>> Hi Jack,
>>>
>>> I just updated libffi to check on that;
>>> I guess the same conflict will remain,
>>> so _ either the 2 manpages are essentiially equivalent,
>>> ad then a mutual "Replaces" would suffice,
>>>
Copying the original msg below, since I forgot to cc the list.
Making gcc45 and libffi conflict would seem exagerated to me _
all pkgs that bdep on libffi would block if a user has gcc45
installed, and the user would first have to manually remove
gcc45 _ and restore it manually after..
For what se
I have updated the gcc45 packaging to 4.5.0-1000
since gcc 4.5.0 was released today. I've not tested
the packaging yet but here should be no issues left
other than the conflict with libffi. It is unclear
to me what the proper fix is for that (ie who should
own the manpage for ffi).
Jack
21 matches
Mail list logo
