One of our packages (NCL) is no longer available upstream, and was
tagged as restrictive so that we don't have a mirror of the source. D.
Macks is of the opinion that we could actually distribute the new
version (after some legwork).
However, it claims to want libpng 1.2.23:
http://www.ncl.ucar.edu/Download/build_from_src.shtml
(also it appears that if we want to update NCAR Graphics to the latest
upstream version it's the same source code)

Alexander K. Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The treeline package works OK for PowerPCs, but doesn't yet work on
> Intel, because we don't have an Intel-compliant PyQt package (currently
> unmaintained). To get that, we also need to update our SIP package
> (also unmaintained), and I have no Intel box on which to test it, and my
> schedule is heavily oversubscribed until May.
>
> You can see where this is going: if somebody would like to help me out
> here, I won't stop them.
I'll start flailing at it. My schedule is only heavily oversubscribed
until March :-)
Dave
--
David Reiser
dbreiser@...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The treeline package works OK for PowerPCs, but doesn't yet work on
Intel, because we don't have an Intel-compliant PyQt package (currently
unmaintained). To get that, we also need to update our SIP package
(also unmaintained), and I have no Intel box on which to test it, and my
schedule is heavily oversubscribed until May.
You can see where this is going: if somebody would like to help me out
here, I won't stop them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHoevaB8UpO3rKjQ8RAgUdAJ9voEQykiLbbCSdwSPYdkouqACvuACaAiQB
tAHHtH4rVjjH8J+M3wPWhHs=
=uuLR
-----END PGP SIGNATURE-----

On Jan 30, 2008 2:19 PM, Jed Frechette <jdfrech@...> wrote:
>
> On Jan 30, 2008, at 11:07 AM, Charles Lepple wrote:
>
> > On Jan 30, 2008 12:20 PM, Jed Frechette <jdfrech@...> wrote:
> >> All of the rst2* scripts crash with:
> >> "ImportError: No module named docutils.core"
> >>
> >> I gather that this is because docutils' CompileScript used /usr/bin/
> >> python to build the package, which modified the shebang lines. Is
> >> this
> >> intentional or should it be using %p/bin/python like the
> >> InstallScript.
> >
> > Can you send me a build log (off-list)? I am not seeing this on my
> > systems.
>
> Sent, although I'm not sure it is very helpful.
>
> If I download the source and build it manually the shebang line for
> the scripts in build/scripts-2.5 gets modified from "#!/usr/bin/env
> python" to the hardcoded path for whatever version of python I call
> "setup.py build" with.
Just committed a fix. Thanks again for pointing that out, and to
dmacks for the reminder on what to look for.
--
- Charles Lepple

On Jan 30, 2008 3:04 PM, Daniel Macks <dmacks@...> wrote:
> On Jan 30, 2008 12:20 PM, Jed Frechette <jdfrech@...> wrote:
> > All of the rst2* scripts crash with:
> > "ImportError: No module named docutils.core"
> >
> > I gather that this is because docutils' CompileScript used /usr/bin/
> > python to build the package, which modified the shebang lines. Is
> > this
> > intentional or should it be using %p/bin/python like the
> > InstallScript.
>
> That latter is exactly how almost all fink-packaged python packages
> are done. If one explicitly says "/usr/bin/python", one gets many
> things specifically tailored for that python interp, including
> library, executable, and other pathname settings and also details
> specific to the python-version. If one wants to tailor to a different
> python interp and/or version, must specify it as early as possible in
> the whole packaging process: there may be lots of differences in the
> build phase, rather than just "where to install the actual lib files".
My fault - I knew I had changed something to use
"%p/bin/python%type_raw[python] setup.py" but apparently I missed
changing the CompileScript.
--
- Charles Lepple

On Jan 30, 2008 12:20 PM, Jed Frechette <jdfrech@...> wrote:
> All of the rst2* scripts crash with:
> "ImportError: No module named docutils.core"
>
> I gather that this is because docutils' CompileScript used /usr/bin/
> python to build the package, which modified the shebang lines. Is
> this
> intentional or should it be using %p/bin/python like the
> InstallScript.
That latter is exactly how almost all fink-packaged python packages
are done. If one explicitly says "/usr/bin/python", one gets many
things specifically tailored for that python interp, including
library, executable, and other pathname settings and also details
specific to the python-version. If one wants to tailor to a different
python interp and/or version, must specify it as early as possible in
the whole packaging process: there may be lots of differences in the
build phase, rather than just "where to install the actual lib files".
dan
--
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

On Jan 30, 2008, at 11:07 AM, Charles Lepple wrote:
> On Jan 30, 2008 12:20 PM, Jed Frechette <jdfrech@...> wrote:
>> All of the rst2* scripts crash with:
>> "ImportError: No module named docutils.core"
>>
>> I gather that this is because docutils' CompileScript used /usr/bin/
>> python to build the package, which modified the shebang lines. Is
>> this
>> intentional or should it be using %p/bin/python like the
>> InstallScript.
>
> Can you send me a build log (off-list)? I am not seeing this on my
> systems.
Sent, although I'm not sure it is very helpful.
If I download the source and build it manually the shebang line for
the scripts in build/scripts-2.5 gets modified from "#!/usr/bin/env
python" to the hardcoded path for whatever version of python I call
"setup.py build" with.
This seems to be some distutils cleverness [1].
Best,
[1] http://docs.python.org/dist/node11.html
--
Jed Frechette
University of New Mexico Lidar Lab
http://www.unm.edu/~lidar

On Jan 30, 2008 12:20 PM, Jed Frechette <jdfrech@...> wrote:
> All of the rst2* scripts crash with:
> "ImportError: No module named docutils.core"
>
> I gather that this is because docutils' CompileScript used /usr/bin/
> python to build the package, which modified the shebang lines. Is this
> intentional or should it be using %p/bin/python like the InstallScript.
Can you send me a build log (off-list)? I am not seeing this on my systems.
'fink -l rebuild docutils-py2_' (either -py24 or -py25, as appropriate).
thanks,
--
- Charles Lepple

Thanks for working on this I really appreciate it. I am just getting
back to this now and ran in to a new issue with the rst2* scripts.
On Jan 12, 2008, at 12:34 PM, Charles Lepple wrote:
> Along these lines, the Fink docutils package currently does not depend
> on a specific version of Python (it explicitly uses /usr/bin/python in
> a few places). This isn't bad for a standalone tool, but it means that
> when someone upgrades to a version with stuff in site-packages, it
> will pull in a whole Fink python package if they don't have one
> already.
All of the rst2* scripts crash with:
"ImportError: No module named docutils.core"
I gather that this is because docutils' CompileScript used /usr/bin/
python to build the package, which modified the shebang lines. Is this
intentional or should it be using %p/bin/python like the InstallScript.
Best,
--
Jed Frechette
University of New Mexico Lidar Lab
http://www.unm.edu/~lidar

It's first-come first-served. In principle a newer-yet lib_version could go
back to the default locations, provided that the original pango1-xft2-dev was
totally expurgated--the -shlibs could stay around for compatibility.
However, this brings up something I've been curious about. Since a fair
number of packages are set up such that things that build against them look
for a common root directory under which there are include/ and lib/
(pilot-link10 is an example I'm familiar with), I'm curious why we don't also
allow for a simpler directory tree in such cases, e.g. a %p%N
with %p%N/include and %p%N/lib . That way each libversion can just go in its
own %N subdirectory of %p .
On Monday 28 January 2008 10:47:29 pm wgscott@... wrote:
> Thanks very much for answering those questions. It is a bit ironic I guess
> that in the pangocairo branch the pangocairo library gets hidden. I'm
> certainly no expert, but as long as everthing is getting upgraded in one
> cohort, wouldn't this be a good time to give the newer package the default
> locations?
>
> On Sun, 27 Jan 2008 13:37:56 -0500
> "Alexander K. Hansen" <akh@...> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> William Scott wrote:
> | Hi folks:
> |
> | A package I am maintaing, coot, in its latest development phase
> | (which I try to participate in), requires gtk+2 v. 2.10 or higher,
> | which therefore requires the fink "pangocairo" branch, which in turn
> | continues to mystify me (despite having read the fink wiki "The
> | Great Gnome Update" page
>
>
> http://wiki.finkproject.org/index.php/Fink:Packaging:The_Great_Gnome_Update
>
> | ).
> |
> |
> |
> | I have a few very basic questions:
> |
> | 1. Is there an estimated date of release, or goal for one?
>
> "soon"
>
> | 2. What is the story with fink package pango1-xft2-ft219-dev and
> | pango1-xft2-dev ? Why does only the first one provide
> | libpangocairo, and if the two conflict and replace one another, why
> | does the first one hide stuff in /sw/lib/pango-ft219/lib ?
>
> They're development packages for two vintages of pango1. In
> accordance with our shared library policy, the development packages should
> conflict, and the libraries have to be able to coexist, so
> pango1-xft2-ft219-shlibs installs its libraries in
> /sw/lib/pango-ft219/lib. The -dev package probably installs there so
> that there's a common root directory for the headers and the
> libraries.
>
> | 3. I've used PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:$
> | {PKG_CONFIG_PATH} to get coot's configure to find pangocairo.pc,
> | which it then does. Later in the compilation, libtool tries to find
> | all the associated libtool files (libpangocairo-1.0.la,
> | libpango-1.0.la and so forth) in /sw/lib and fails. Similarly, it
> | starts looking for pangocairo.pc and pango.pc in /sw/lib and fails.
> | I made symbolic links as a work-around, but obviously that isn't a
> | viable solution. So my questions are:
> |
> | a) Is pango1-xft2-ft219-dev obsolete and/or depreciated in favor of
> | pango1-xft2-dev ? If so, what should I tell the author of coot to
> | do about this? Which one should we be aiming to use a year from now?
>
> It's the other way around. The "ft219" means that it uses
> "freetype219", which corresponds to newer versions of freetype2.
>
> | b) How do I force libtool to do the right thing?
> |
> |
> | For what it is worth, coot has about 150 dependencies, which apart
> | from the above, all seem to work well enough to enable it to
> | compile.
> |
> | Thanks.
> |
> | Bill Scott
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHnM+BB8UpO3rKjQ8RAvniAJwM0OMmBDnYnClombZmiWBTfNnZmACfQzDz
> a+lz85+PpKd1QBsWFqdZY4k=
> =gCDT
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Fink-devel mailing list
> Fink-devel@...
> http://news.gmane.org/gmane.os.apple.fink.devel
--
Alexander K. Hansen
akh AT finkproject DOT org
Fink User Liaison and Documenter

Thanks very much for answering those questions. It is a bit ironic I guess that in the pangocairo branch the pangocairo library gets hidden. I'm certainly no expert, but as long as everthing is getting upgraded in one cohort, wouldn't this be a good time to give the newer package the default locations?
On Sun, 27 Jan 2008 13:37:56 -0500
"Alexander K. Hansen" <akh@...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Scott wrote:
| Hi folks:
|
| A package I am maintaing, coot, in its latest development phase (which
| I try to participate in), requires gtk+2 v. 2.10 or higher, which
| therefore requires the fink "pangocairo" branch, which in turn
| continues to mystify me (despite having read the fink wiki "The Great
| Gnome Update" page
http://wiki.finkproject.org/index.php/Fink:Packaging:The_Great_Gnome_Update
| ).
|
|
|
| I have a few very basic questions:
|
| 1. Is there an estimated date of release, or goal for one?
|
"soon"
| 2. What is the story with fink package pango1-xft2-ft219-dev and
| pango1-xft2-dev ? Why does only the first one provide libpangocairo,
| and if the two conflict and replace one another, why does the first
| one hide stuff in /sw/lib/pango-ft219/lib ?
They're development packages for two vintages of pango1. In accordance
with our shared library policy, the development packages should
conflict, and the libraries have to be able to coexist, so
pango1-xft2-ft219-shlibs installs its libraries in
/sw/lib/pango-ft219/lib. The -dev package probably installs there so
that there's a common root directory for the headers and the libraries.
|
| 3. I've used PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:$
| {PKG_CONFIG_PATH} to get coot's configure to find pangocairo.pc,
| which it then does. Later in the compilation, libtool tries to find
| all the associated libtool files (libpangocairo-1.0.la,
| libpango-1.0.la and so forth) in /sw/lib and fails. Similarly, it
| starts looking for pangocairo.pc and pango.pc in /sw/lib and fails. I
| made symbolic links as a work-around, but obviously that isn't a
| viable solution. So my questions are:
|
| a) Is pango1-xft2-ft219-dev obsolete and/or depreciated in favor of
| pango1-xft2-dev ? If so, what should I tell the author of coot to do
| about this? Which one should we be aiming to use a year from now?
|
It's the other way around. The "ft219" means that it uses
"freetype219", which corresponds to newer versions of freetype2.
| b) How do I force libtool to do the right thing?
|
|
| For what it is worth, coot has about 150 dependencies, which apart
| from the above, all seem to work well enough to enable it to compile.
|
| Thanks.
|
| Bill Scott
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHnM+BB8UpO3rKjQ8RAvniAJwM0OMmBDnYnClombZmiWBTfNnZmACfQzDz
a+lz85+PpKd1QBsWFqdZY4k=
=gCDT
-----END PGP SIGNATURE-----

On Monday 28 January 2008 06:56:12 am Aleix Conchillo Flaqu=E9 wrote:
> Hi,
>
> I am maintaing the ECL package which should be updated to its latest
> version as the current Fink version does not compile on Leopard.
>
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D414256&aid=3D186221=
3&group_
>id=3D17203
>
> Thanks in advance,
>
> Aleix
>
>
>=20
Not so fast. :-)
I got the following validation message with the package:
=2E..
Validating .deb dir /sw2/src/fink.build/root-ecl-0.9j-p1-1...
Error: package contains a dylib with no corresponding Shlibs entry=20
(/sw2/lib/libecl.dylib -> /sw2/lib//libecl.dylib 0.0.0)
If this is a private library, add '!/sw2/lib/libecl.dylib' to the=20
Shlibs field.
=2E..
And it appears that there are header files in it, too. Are people supposed=
to=20
build against this and link to the library? If not, then no real problem. =
=20
Otherwise some reworking will be required.
=2D-=20
Alexander K. Hansen
akh AT finkproject DOT org
=46ink User Liaison and Documenter

On Jan 26, 2008, at 12:08 PM, Daniel Macks wrote:
> Do we have any guideline or best-practices for how to structure
> (splitoffs, etc) a package that has plugins? By "plugins", I mean
> runtime-loaded modules or other components that can be removed without
> harming the overall program (other than losing the functionality they
> provide).
>
> I can think of several...would be nice to have some sort of uniformity
> so users know what to expect (or at least a way to find what they
> want) (or at least "get uesd to" one way) (or at least post this as a
> canned answer when a package behaves in a way a user doesn't expect or
> like).
>
> 1. Have the plugin as part of the parent package (example: imagemagick
> and its librsvg plugin). Pro 1: installing imagemagick gets a fully
> featured package, because the plugins that support standard features
> are always present. Pro 2: easy to package if the module's build is
> already implemented as part of the parent build process, because the
> parts of the distro are built all together. Con: possibly large
> dependency chain for just one of the plugins, so package looks bloated
> if user does not need that feature.
>
> 2. Have the plugin as a splitoff of the parent package. Pro 1: binary
> users don't have bloated dependencies for the main package. Pro 2:
> pretty easy to package. Con 1: source users still need the whole
> dependency chain. Con 2: users need to know to install the plugin
> (looks like "parent doesn't work right") and perhaps have weird
> effects if the installed versions of the plugin and the parent get out
> of sync (plugins are often laxer about interface stability because
> they often aren't designed as stand-alone/modular public components).
>
> 3. Have the plugin as part of the library that supports it (example:
> evince and its plugin for nautilus). Pro 1: even source users of the
> parent don't have dependency bloat. Pro 2: Easy to package if the
> plugin build is already implemented as part of the library build
> process. Con 1: users of the parent need to know to install the
> plugin. Con 2: users of the library get a dependency chain for a
> package unrelated to the library.
>
> 4. Plugin as splitoff of library. Like #3, solving #3 con 2 and
> solving #3 con #2 for binary users.
>
> 5. Build plugin as an entirely separate package (example: mozilla's
> librsvg plugin). Pro 1: no dependency bloat for anyone (caveat: con
> 2). Con 1: need to know to install. Con 2: need to hack parent to
> disable plugin build, including avoiding complaining if dependencies
> for it are missing. Con 3: things that "look like" simple plugins may
> also involve code in main program (plugin isn't as runtime-modular as
> it appears) (related to cons 2 & 4). Con 4: need to hack a way to
> build the module itself without building the parent package (typically
> involves lots of makefile and flag adjustments).
>
> dan
>
> --
> Daniel Macks
> dmacks@...
> http://www.netspace.org/~dmacks
>
I think I would prefer #2 or #4. I think 5 is too much work for the
benefits. And probably too hard for me to do :).
I'm not sure I know what I'm talking about yet, but libgda3
(pangocairo) might be a good example of what might get in the way in
terms of bloat. It looks like the 'providers' in libgda might be
plugins. They do have to be configured and made, but at first glance
they might not be linked in the main shlibs, and they do seem to live
in a subdirectory of their own. I suspect, though, if I configure the
mysql 'provider', configure is going to go looking for mysql headers
to link the provider against. I'm sure I don't want to build the whole
list of providers by default if that's the case. I think having to
explain that a user needs libgda4-shlibs and libgda4-mysql or libgda-
whateverbackend isn't too difficult for maintainers or users. As it
happens, the somewhat bare libgda + libgda4-shlibs provides an sqlite
provider as default. (Maybe even libgda-shlibs by itself -- I just
started messing with this this week.)
Dave
--
David Reiser
dbreiser@...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Scott wrote:
| Hi folks:
|
| A package I am maintaing, coot, in its latest development phase (which
| I try to participate in), requires gtk+2 v. 2.10 or higher, which
| therefore requires the fink "pangocairo" branch, which in turn
| continues to mystify me (despite having read the fink wiki "The Great
| Gnome Update" page
http://wiki.finkproject.org/index.php/Fink:Packaging:The_Great_Gnome_Update
| ).
|
|
|
| I have a few very basic questions:
|
| 1. Is there an estimated date of release, or goal for one?
|
"soon"
| 2. What is the story with fink package pango1-xft2-ft219-dev and
| pango1-xft2-dev ? Why does only the first one provide libpangocairo,
| and if the two conflict and replace one another, why does the first
| one hide stuff in /sw/lib/pango-ft219/lib ?
They're development packages for two vintages of pango1. In accordance
with our shared library policy, the development packages should
conflict, and the libraries have to be able to coexist, so
pango1-xft2-ft219-shlibs installs its libraries in
/sw/lib/pango-ft219/lib. The -dev package probably installs there so
that there's a common root directory for the headers and the libraries.
|
| 3. I've used PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:$
| {PKG_CONFIG_PATH} to get coot's configure to find pangocairo.pc,
| which it then does. Later in the compilation, libtool tries to find
| all the associated libtool files (libpangocairo-1.0.la,
| libpango-1.0.la and so forth) in /sw/lib and fails. Similarly, it
| starts looking for pangocairo.pc and pango.pc in /sw/lib and fails. I
| made symbolic links as a work-around, but obviously that isn't a
| viable solution. So my questions are:
|
| a) Is pango1-xft2-ft219-dev obsolete and/or depreciated in favor of
| pango1-xft2-dev ? If so, what should I tell the author of coot to do
| about this? Which one should we be aiming to use a year from now?
|
It's the other way around. The "ft219" means that it uses
"freetype219", which corresponds to newer versions of freetype2.
| b) How do I force libtool to do the right thing?
|
|
| For what it is worth, coot has about 150 dependencies, which apart
| from the above, all seem to work well enough to enable it to compile.
|
| Thanks.
|
| Bill Scott
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHnM+BB8UpO3rKjQ8RAvniAJwM0OMmBDnYnClombZmiWBTfNnZmACfQzDz
a+lz85+PpKd1QBsWFqdZY4k=
=gCDT
-----END PGP SIGNATURE-----

Hi folks:
A package I am maintaing, coot, in its latest development phase (which
I try to participate in), requires gtk+2 v. 2.10 or higher, which
therefore requires the fink "pangocairo" branch, which in turn
continues to mystify me (despite having read the fink wiki "The Great
Gnome Update" page http://wiki.finkproject.org/index.php/Fink:Packaging:The_Great_Gnome_Update
).
I have a few very basic questions:
1. Is there an estimated date of release, or goal for one?
2. What is the story with fink package pango1-xft2-ft219-dev and
pango1-xft2-dev ? Why does only the first one provide libpangocairo,
and if the two conflict and replace one another, why does the first
one hide stuff in /sw/lib/pango-ft219/lib ?
3. I've used PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:$
{PKG_CONFIG_PATH} to get coot's configure to find pangocairo.pc,
which it then does. Later in the compilation, libtool tries to find
all the associated libtool files (libpangocairo-1.0.la,
libpango-1.0.la and so forth) in /sw/lib and fails. Similarly, it
starts looking for pangocairo.pc and pango.pc in /sw/lib and fails. I
made symbolic links as a work-around, but obviously that isn't a
viable solution. So my questions are:
a) Is pango1-xft2-ft219-dev obsolete and/or depreciated in favor of
pango1-xft2-dev ? If so, what should I tell the author of coot to do
about this? Which one should we be aiming to use a year from now?
b) How do I force libtool to do the right thing?
For what it is worth, coot has about 150 dependencies, which apart
from the above, all seem to work well enough to enable it to compile.
Thanks.
Bill Scott

Do we have any guideline or best-practices for how to structure
(splitoffs, etc) a package that has plugins? By "plugins", I mean
runtime-loaded modules or other components that can be removed without
harming the overall program (other than losing the functionality they
provide).
I can think of several...would be nice to have some sort of uniformity
so users know what to expect (or at least a way to find what they
want) (or at least "get uesd to" one way) (or at least post this as a
canned answer when a package behaves in a way a user doesn't expect or
like).
1. Have the plugin as part of the parent package (example: imagemagick
and its librsvg plugin). Pro 1: installing imagemagick gets a fully
featured package, because the plugins that support standard features
are always present. Pro 2: easy to package if the module's build is
already implemented as part of the parent build process, because the
parts of the distro are built all together. Con: possibly large
dependency chain for just one of the plugins, so package looks bloated
if user does not need that feature.
2. Have the plugin as a splitoff of the parent package. Pro 1: binary
users don't have bloated dependencies for the main package. Pro 2:
pretty easy to package. Con 1: source users still need the whole
dependency chain. Con 2: users need to know to install the plugin
(looks like "parent doesn't work right") and perhaps have weird
effects if the installed versions of the plugin and the parent get out
of sync (plugins are often laxer about interface stability because
they often aren't designed as stand-alone/modular public components).
3. Have the plugin as part of the library that supports it (example:
evince and its plugin for nautilus). Pro 1: even source users of the
parent don't have dependency bloat. Pro 2: Easy to package if the
plugin build is already implemented as part of the library build
process. Con 1: users of the parent need to know to install the
plugin. Con 2: users of the library get a dependency chain for a
package unrelated to the library.
4. Plugin as splitoff of library. Like #3, solving #3 con 2 and
solving #3 con #2 for binary users.
5. Build plugin as an entirely separate package (example: mozilla's
librsvg plugin). Pro 1: no dependency bloat for anyone (caveat: con
2). Con 1: need to know to install. Con 2: need to hack parent to
disable plugin build, including avoiding complaining if dependencies
for it are missing. Con 3: things that "look like" simple plugins may
also involve code in main program (plugin isn't as runtime-modular as
it appears) (related to cons 2 & 4). Con 4: need to hack a way to
build the module itself without building the parent package (typically
involves lots of makefile and flag adjustments).
dan
--
Daniel Macks
dmacks@...
http://www.netspace.org/~dmacks

hi there
I'm working on java bindings for xine (libxine-java.sourceforge.net)
and just felt positive enough to call it a release. it works on mac os
x and linux. I've fixed a bug in libxine which would produce wrong
colors on PowerPC if the Mac OS X Video is used. As far as I know
there is hardly a video player which uses this. Anyway, the fix is
upstream. I've also compiled the muxine.c example player which uses
X11. This one works fine on my stock 10.5.1 without any changes to the
xine makefiles. At least that's the PowerPC view. But the guy which
has re-written the mac native output is using some intel, so I'm
confident that most (if not all) parts of xine are working very well
on mac.
can you try to provide an updated 1.1.9.1 (this one includes the
powerpc output fix) ?
thanks,
matthias ringwald
On 11.12.2007, at 15:15, TheSin wrote:
> thanks for the info, now that I know it's in the ffmpeg lib I'll have
> it fixed once I'm done with php 5.2.5, which I hope will be today,
> then I'll start on libxine. I already fixed most of the ASM in ffmpeg
> pkg, so i should be able to use the same patch for xine.
>>

Hi Damian,
Good shot! But I have the same problem with fonts: launching Rome =20
Total War with:
$ export LD_LIBRARY_PATH=3D/sw/lib
$ wine /Volumes/Rome_TW_CD1/Launch.exe
I only get crosses and zapf-dingbats-like symbols in all buttons.
I have 10.5.1, with X11.app 2.1.1 - (xorg-server 1.3.0-apple5)
Jean
Le 4 janv. 08 =E0 20:55, Damian Dimmich a =E9crit :
> Hi Michal,
>
> What version of X and OsX are you running?
>
> I've only tested against 2.1.1 XQuartz (based on x.org 7.2ish) from =20=
> here
> http://trac.macosforge.org/projects/xquartz and Leopard. I don't
> actually have 10.4 machine to test on - that and the 10.4 X was =20
> really
> buggy and may have to do with problems with that?
>
> Also, what apps is this happening with?
>
> Cheers,
> Damian
>
> Michal Suchanek wrote:
>> On 31/12/2007, Damian Dimmich <djd20@...> wrote:
>>
>>> Hi All,
>>>
>>> I went ahead and made an info file for wine 0.9.52 - pulled it and =20=
>>> it
>>> seems to work very well - better than the .44 version as that one =20=
>>> had
>>> something busted with the fonts it was using (at least on my =20
>>> system).
>>> This has been tested on Leopard.
>>>
>>
>> On 10.4 the .9.44 version was sort of working. It would redo some =20
>> font
>> metrics over and over (at least once on every program start so =20
>> running
>> anything took ages).
>>
>> The .9.52 from the package tracker builds and runs but it fails to
>> hide windows. Maybe it's my window manager but all windows that are
>> normally unmapped (closed but possibly not destroyed completely) =20
>> never
>> go away once shown. This includes various dialogs and a splash =20
>> screen.
>> I have tried a single application that uses its own dialogs, probaly
>> no comclt stuff.
>>
>> Thanks
>>
>> Michal
>>
>
>
> =
-------------------------------------------------------------------------
> 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/
> _______________________________________________
> Fink-devel mailing list
> Fink-devel@...
> http://news.gmane.org/gmane.os.apple.fink.devel
>