On Monday 19 May 2008 13:53, Nicolas Chauvet wrote:
> Fonts
> - The cinelerra package bundles many fonts (used by the title plugins)
> that doesn't seems even redistributable (usually found with the
> mscorefonts package).
> This should be avoided since this will leads to the fonts to be provided
>   twice; and it will save about 6Mb for the cinelerra package.
> Instead cinelerra should scan in the system fonts directory
> (/usr/share/fonts ) for system fonts.
> Actually, it searches for the fonts.dir catalog file expected in each
> directory. In a Fedora system, some fonts package bundled this kind
> of file, but this is deprecated for at least two years. Packages should
> use fontconfig or else to use system fonts.
> The workaround would be to use ttmkfdir mkfontdir in each directories to
> regenerate system fonts.

I'm strongly in favor of removing the font directory from the code. I doubt 
that it's cosher to distribute these fonts.

What is the modern way of finding fonts that are on the system if fonts.dir is 
no longer the way to go?

> LibGL
> The patch is aimed to fix a problem with libGL, but it fails on Fedora
> (that has libGL.so for mesa and even nVidia) - This kind of workaround
> should be handled in the specific distribution as it lead to fails in
> Fedora. (or maybe i haven't used --enable-opengl whereas the configure
> line suggest that it should be autodetected).

Why does it fail? Your patch just removes the Suse-specific hack and only 
leaves the generic test, which comes first anyway. Remember: This is 
configure.in! It's the place where system-specific settings are derived, and 
it's not to be kept clean of system-specificities!

> - sed -i -e 's|linux/time.h|time.h|' configure.in configure
> The configure script test if v4l2 can be built with linux/time.h (and
> fails) but this header isn't specified in the source codec elsewhere.
> Instead time.h is found and the test will succeed if this file is used.

It does not work here with #include <time.h> (Suse 10.1). I need 
<linux/time.h>. It's the types __u32 etc. that are needed. :( What to do?

-- Hannes

_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to