headers
Chris Dolan | 1 Oct 04:35
Favicon
Gravatar

Re: unison packages

On Sep 28, 2007, at 2:04 PM, Alexey Zakhlestin wrote:

> I think, that I read, somewhere, that 2.27 is protocol-compatible with
> 2.13… (though I may be wrong)

The changelog is here:
   http://www.seas.upenn.edu/~bcpierce/unison//download/releases/beta/ 
unison-2.27.29-manual.html#news
and does not mention anything protocol-related.

FWIW, I've been using Fink's 2.13.16-1004 daily with many different  
configs and have had no problems.  I endorse a move to stable.

Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 6 comments |
headers
Alexander Hansen | 1 Oct 04:54
Favicon

new octplot package and some updates to fltk

I have package description files for Octplot ( http://octplot.sf.net ), 
a plotting interface for Octave, in my experimental area:

https://finch.finkdeveloper.net/svn/users/akh/experimental/octplot-project

The package is varianted both for Aqua and X11.

As part of this effort, since Octplot uses FLTK, I've gone ahead and 
updated our aqua-based fltk package to a more modern version, as well as 
renaming it to fltk-aqua and having it build shared libraries instead of 
just static ones.  These libraries are properly install_named (and 
installed in a protected location) so that fltk-aqua-shlibs can indeed 
coexist properly with fltk-x11-shlibs.  The package description files 
for these are in the above location, along with Conflict/Replace updates 
for fltk and fltk-x11 (maintainer for the latter cc'ed). 

I welcome any feedback before I commit the packages.

--

-- 
Alexander K. Hansen
akh AT finkproject DOT org
Fink User Liaison and Documenter

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |
headers
Alexander Hansen | 1 Oct 12:34
Picon
Gravatar

Re: unison packages

On 9/30/07, Chris Dolan <chris <at> chrisdolan.net> wrote:
> On Sep 28, 2007, at 2:04 PM, Alexey Zakhlestin wrote:
>
> > I think, that I read, somewhere, that 2.27 is protocol-compatible with
> > 2.13… (though I may be wrong)
>
> The changelog is here:
>    http://www.seas.upenn.edu/~bcpierce/unison//download/releases/beta/
> unison-2.27.29-manual.html#news
> and does not mention anything protocol-related.
>
> FWIW, I've been using Fink's 2.13.16-1004 daily with many different
> configs and have had no problems.  I endorse a move to stable.
>
> Chris

I've moved lablgtk and unison to stable.

--

-- 
Alexander K. Hansen
akh AT finkproject DOT org
Fink User Liaison and Documenter

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 5 comments |
headers
Jack Howarth | 1 Oct 17:54
Picon
Gravatar

fftw3-3.1.2-1 and Leopard

   I've placed an updated package for fftw3 on fink
tracking. The current packaging depends on g95 which
won't build on Leopard due to its dependency on
odcctools590. I believe the best fix for this is
to migrate fftw3 to build against gfortran (since
looking forward we are better off with that than
g95 in all areas...speed, features, reliability).
Another reason to avoid g95 in Leopard is its
current dependency on the ancient gcc-core-4.0.3
tarball. Anyone who follows gcc development will
be well aware that darwin9 specific fixes are
almost all in gcc 4.2 branch, but none in gcc 4.1
branch or gcc 4.0 branch. The g95 developer should
be nudged to support building against a gcc release
which is designed to support darwin9.
               Jack
ps If we have to use a gcc 4.0.x tarball for
g95, I wonder if we shouldn't consider using
the gcc-core-4.0.4 tarball or perhaps even
a svn pull of the FSF gcc apple compiler branch.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |
headers
Pierre-Henri Lavigne | 1 Oct 22:08
Picon
Favicon

Error while compiling Gnash


Good day all,

I'm late... I'm late... Groochy to be ill xD 

While googling it seems to be a known bug - odd most of time I found talkings to build universal app
 :
 g++ -g -O2 -D_THREAD_SAFE -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -o
.libs/gparser parser.o -Wl,-bind_at_load  -L/sw/lib -L/usr/X11R6/lib -L/sw/lib/freetype219/lib/
../server/.libs/libgnashserver.dylib -L/sw/lib/system-openssl/lib -L/usr/lib
-L/sw/lib/freetype219/lib ../libbase/.libs/libgnashbase.dylib
../backend/.libs/libgnashbackend.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/server/.libs/libgnashserver.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libamf/.libs/libgnashamf.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libgeometry/.libs/libgnashgeo.dylib
-lfontconfig /sw/lib/libpangox-1.0.dylib /sw/lib/libpango-1.0.dylib /sw/lib/libatk-1.0.dylib
../libamf/.libs/libgnashamf.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libbase/.libs/libgnashbase.dylib
/sw/lib/libjpeg.dylib /sw/lib/libcurl.dylib -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support
-lcom_err -lresolv /sw/lib/libssh2.dylib -lssl -lcrypto
 /sw/lib/libltdl.dylib -ldl -lboost_date_time -lboost_thread /sw/lib/libgstbase-0.10.dylib
/sw/lib/libgstpbutils-0.10.dylib /sw/lib/libgstreamer-0.10.dylib
/sw/lib/libgobject-2.0.dylib /sw/lib/libgmodule-2.0.dylib /sw/lib/libgthread-2.0.dylib
/sw/lib/libxml2.dylib -lpthread /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib -lc
/sw/lib/libiconv.dylib -lz -lX11 -lXi -lm
/usr/bin/ld: Undefined symbols:
_FT_Done_Face
_FT_Done_FreeType
_FT_Init_FreeType
_FT_Load_Char
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexander K. Hansen | 1 Oct 22:22
Favicon

Re: Error while compiling Gnash

Pierre-Henri Lavigne wrote:
> Good day all,
>
> I'm late... I'm late... Groochy to be ill xD 
>
> While googling it seems to be a known bug - odd most of time I found talkings to build universal app
>  :
>  g++ -g -O2 -D_THREAD_SAFE -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -o
.libs/gparser parser.o -Wl,-bind_at_load  -L/sw/lib -L/usr/X11R6/lib -L/sw/lib/freetype219/lib/
../server/.libs/libgnashserver.dylib -L/sw/lib/system-openssl/lib -L/usr/lib
-L/sw/lib/freetype219/lib ../libbase/.libs/libgnashbase.dylib
../backend/.libs/libgnashbackend.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/server/.libs/libgnashserver.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libamf/.libs/libgnashamf.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libgeometry/.libs/libgnashgeo.dylib
-lfontconfig /sw/lib/libpangox-1.0.dylib /sw/lib/libpango-1.0.dylib /sw/lib/libatk-1.0.dylib
../libamf/.libs/libgnashamf.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libbase/.libs/libgnashbase.dylib
/sw/lib/libjpeg.dylib /sw/lib/libcurl.dylib -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support
-lcom_err -lresolv /sw/lib/libssh2.dylib -lssl -lcrypto
>  /sw/lib/libltdl.dylib -ldl -lboost_date_time -lboost_thread /sw/lib/libgstbase-0.10.dylib
/sw/lib/libgstpbutils-0.10.dylib /sw/lib/libgstreamer-0.10.dylib
/sw/lib/libgobject-2.0.dylib /sw/lib/libgmodule-2.0.dylib /sw/lib/libgthread-2.0.dylib
/sw/lib/libxml2.dylib -lpthread /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib -lc
/sw/lib/libiconv.dylib -lz -lX11 -lXi -lm
> /usr/bin/ld: Undefined symbols:
> _FT_Done_Face
> _FT_Done_FreeType
> _FT_Init_FreeType
> _FT_Load_Char
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Costabel | 1 Oct 22:59
Picon

Re: Error while compiling Gnash

Alexander K. Hansen wrote:
> Pierre-Henri Lavigne wrote:
>> Good day all,
>>
>> I'm late... I'm late... Groochy to be ill xD 
>>
>> While googling it seems to be a known bug - odd most of time I found talkings to build universal app
>>  :
>>  g++ -g -O2 -D_THREAD_SAFE -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -o
.libs/gparser parser.o -Wl,-bind_at_load  -L/sw/lib -L/usr/X11R6/lib -L/sw/lib/freetype219/lib/
../server/.libs/libgnashserver.dylib -L/sw/lib/system-openssl/lib -L/usr/lib
-L/sw/lib/freetype219/lib ../libbase/.libs/libgnashbase.dylib
../backend/.libs/libgnashbackend.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/server/.libs/libgnashserver.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libamf/.libs/libgnashamf.dylib
/sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libgeometry/.libs/libgnashgeo.dylib
-lfontconfig /sw/lib/libpangox-1.0.dylib /sw/lib/libpango-1.0.dylib /sw/lib/libatk-1.0.dylib
../libamf/.libs/libgnashamf.dylib /sw/src/fink.build/gnash-0.8.1-1/gnash-0.8.1/libbase/.libs/libgnas
 hbase.dylib /sw/lib/libjpeg.dylib /sw/lib/libcurl.dylib -lgssapi_krb5 -lkrb5 -lk5crypto
-lkrb5support -lcom_err -lresolv /sw/lib/libssh2.dylib -lssl -lcrypto
>>  /sw/lib/libltdl.dylib -ldl -lboost_date_time -lboost_thread /sw/lib/libgstbase-0.10.dylib
/sw/lib/libgstpbutils-0.10.dylib /sw/lib/libgstreamer-0.10.dylib
/sw/lib/libgobject-2.0.dylib /sw/lib/libgmodule-2.0.dylib /sw/lib/libgthread-2.0.dylib
/sw/lib/libxml2.dylib -lpthread /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib -lc
/sw/lib/libiconv.dylib -lz -lX11 -lXi -lm
>> /usr/bin/ld: Undefined symbols:
>> _FT_Done_Face
>> _FT_Done_FreeType
>> _FT_Init_FreeType
>> _FT_Load_Char
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack Howarth | 2 Oct 00:05
Picon
Gravatar

only allows things to BuildDepend on it

   I have discovered while revising the gromacs-mpi packaging
that 'fink -m --build-as-nobody rebuild gromacs-mpi-openmpi'
produces the error...

WARNING: The package gromacs-mpi-openmpi-dev Depends on openmpi-dev,
	 but openmpi-dev only allows things to BuildDepend on it.

I could change the Depends line from...

SplitOff2: <<
Package: %N-dev
Conflicts: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
Replaces: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
Depends: (%type_pkg[handler] = lammpi) lammpi-dev (>= 7.1.2-1000), (%type_pkg[handler] = openmpi)
openmpi-dev, fftw3-shlibs

to

SplitOff2: <<
Package: %N-dev
Conflicts: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
Replaces: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
Depends: fftw3-shlibs

However this will decouple the gromacs-mpi-*-dev package from its associated
mpi-dev package (allowing gromacs-mpi-lammpi-dev to be installed with
openmpi-dev and gromacs-mpi-openmpi-dev to be installed with lammpi-dev).
Should I just ignore this error? Thanks in advance for any advice.
            Jack
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jean-François Mertens | 2 Oct 02:10
Picon
Favicon

Re: only allows things to BuildDepend on it


On 02 Oct 2007, at 00:05, Jack Howarth wrote:

> I could change the Depends line from...
> to
>
> SplitOff2: <<
> Package: %N-dev
> Conflicts: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi- 
> openmpi-dev
> Replaces: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi- 
> openmpi-dev
> Depends: fftw3-shlibs
right !
>
> However this will decouple the gromacs-mpi-*-dev package from its  
> associated
> mpi-dev package (allowing gromacs-mpi-lammpi-dev to be installed with
> openmpi-dev and gromacs-mpi-openmpi-dev to be installed with lammpi- 
> dev).
> Should I just ignore this error? Thanks in advance for any advice.
correct too !
fink currently allows for no form of recursivity in builddeps _
i.e., any pkg that builddepends on gromacs-xyz-dev
has also to builddepend on {open,lam}mpi-dev _ and the right
one !

This assumes that nothing in the -dev pkgs is needed at runtime !

JF Mertens
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander K. Hansen | 2 Oct 02:59
Favicon

Re: only allows things to BuildDepend on it

Jack Howarth wrote:
>    I have discovered while revising the gromacs-mpi packaging
> that 'fink -m --build-as-nobody rebuild gromacs-mpi-openmpi'
> produces the error...
>
> WARNING: The package gromacs-mpi-openmpi-dev Depends on openmpi-dev,
> 	 but openmpi-dev only allows things to BuildDepend on it.
>
>
> I could change the Depends line from...
>
> SplitOff2: <<
> Package: %N-dev
> Conflicts: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
> Replaces: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
> Depends: (%type_pkg[handler] = lammpi) lammpi-dev (>= 7.1.2-1000), (%type_pkg[handler] = openmpi)
openmpi-dev, fftw3-shlibs
>
> to
>
> SplitOff2: <<
> Package: %N-dev
> Conflicts: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
> Replaces: gromacs-mpi-dev, gromacs-mpi-lammpi-dev, gromacs-mpi-openmpi-dev
> Depends: fftw3-shlibs
>
> However this will decouple the gromacs-mpi-*-dev package from its associated
> mpi-dev package (allowing gromacs-mpi-lammpi-dev to be installed with
> openmpi-dev and gromacs-mpi-openmpi-dev to be installed with lammpi-dev).
> Should I just ignore this error? Thanks in advance for any advice.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane