- MUST: rpmlint must be run on every package. The output should be posted in the review.

mlt-devel.i386: W: no-documentation
mlt-devel.i386: W: executable-stack /usr/lib/mlt/libmltgtk2.so

Not sure about the first one, no clue what the second one means, but it is probably a problem in the compilation process of the package itself.


- MUST: The package must be named according to the Package Naming Guidelines .

CHECK

- MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption on Package Naming Guidelines .

CHECK 

- MUST: The package must meet the Packaging Guidelines .

BuildRoot needs to follow the guidelines. The following value is recommended.
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)


- MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .

CHECK

- MUST: The License field in the package spec file must match the actual license.

CHECK

- MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.

CHECK

- MUST: The spec file must be written in American English.

CHECK

- MUST: The spec file for the package MUST be legible. If the reviewer is unable to read the spec file, it will be impossible to perform a review. Fedora is not the place for entries into the Obfuscated Code Contest (http://www.ioccc.org/).

CHECK - for some values of legible ;) (next time use better handwriting)

- MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.

No url provided.
MD5 matches with the source package from sourceforge, nonetheless.

- MUST: The package must successfully compile and build into binary rpms on at least one supported architecture.

Tested on i386, works.

- MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: FE-ExcludeArch-x86 , FE-ExcludeArch-x64 , FE-ExcludeArch-ppc , FE-ExcludeArch-ppc64

Not tested on any other architectures.

- MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.

CHECK

- MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.

Not applicable (?)

- MUST: Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is:

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig


CHECK

- MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.

Not Applicable

- MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. Refer to the Guidelines for examples.

CHECK (but someone who does the actual review, please double check)

- MUST: A package must not contain any duplicate files in the %files listing.

CHECK

- MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.

CHECK

- MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} ( or $RPM_BUILD_ROOT ).

CHECK

- MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines .

CHECK

- MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines .

CHECK (code)

- MUST: Large documentation files should go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity)

Not Applicable

- MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.

CHECK

- MUST: Header files must be in a -devel package.

CHECK

- MUST: Static libraries must be in a -static package.

Not applicable

- MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).

Missing (belongs in the %package section for the devel package.

- MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.

CHECK

- MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}

Missing the %{release}

- MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec.

CHECK

- MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. This is described in detail in the desktop files section of the Packaging Guidelines . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

Not applicable

- MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

CHECK

- MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} ( or $RPM_BUILD_ROOT ). See Prepping BuildRoot For %install for details.

CHECK

- MUST: All filenames in rpm packages must be valid UTF-8.

CHECK


SHOULD Items:

- SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.

N/A

- SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.

Missing (how do you do this actually?)

- SHOULD: The reviewer should test that the package builds in mock. See MockTricks for details on how to do this.

Not tested.

- SHOULD: The package should compile and build into binary rpms on all supported architectures.

Not tested

- SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.

It's a library, not going to compile other packages just to test right now.

- SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.

N/A

- SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.

N/A

- SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.

CHECK

- SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Please see File Dependencies in the Guidelines for further information. 

CHECK

***
mlt-devel.i386: W: no-documentation
Does the -devel package need a LICENSE or something? I'd think not since it Requires: the main package.


***
mlt-devel.i386: W: executable-stack /usr/lib/mlt/libmltgtk2.so
I have no clue here.


***
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
I changed my BuildRoot: to that. I had a more commonly used one before.


***
No url provided.
Now using full URL to source:
http://downloads.sourceforge.net/mlt/%{name}-%{version}.tar.gz

***
Not tested on any other architectures.
This package does *not* compile on x86_64, croaking on some assembly... Untested on ppc. I added ExcludeArch: x86_64.

***
To -devel section, added:
Requires: pkgconfig

***
-devel section, fixed:
Requires: %{name} = %{version}-%{release}


Revised packages here (0.3.0-2):
ftp://ftp.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt.spec

(In reply to comment #2)
> Revised packages here (0.3.0-2):
> ftp://ftp.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt.spec

Seems 404 or so.. Also would you provide srpm so that we can download it easily?

Mamoru Tasaka:

Sorry I temporarily had moved that dir. Its back. A SRPM is also available:
http://www.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt.spec
http://www.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt-0.3.0-2.fc9.src.rpm

Well, some quick notes for 0.3.0-2:

* License
  - As far as I checked the whole codes, the license tag
    should be "GPLv2+ and LGPLv2+".

* Groups
  - Is the Group tag "Development/Libraries" proper? (maybe
    "Development/Tools")?

* ExcludeArch
  - Even on ppc this does not build:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=817251
    Some codes seems to be using heavily i386 dependent codes and
    perhaps this package only supports i386?

* compilation flags, debug info
  - compilation flags "-O4 -fomit-frame-pointer -ffast-math"
    makes debugging very difficult and Fedora does not allow these
    flags.
  - Also, automated stripping of binaries is forbidden because
    this prevents from making correct debuginfo rpm.
    For example:
-----------------------------------------------------------------
   425  make[1]: Entering directory `/builddir/build/BUILD/mlt-0.3.0/src/inigo'
   426  install -d "/builddir/build/BUILDROOT/mlt-0.3.0-2.fc10.i386/usr/bin"
   427  install -c -s -m 755 inigo "/builddir/build/BUILDROOT/mlt-0.3.0-2.fc10.i386/usr/bin"
   428  make[1]: Leaving directory `/builddir/build/BUILD/mlt-0.3.0/src/inigo'
-----------------------------------------------------------------
    "install" command option "-s" must be removed.

* %defattr
  - Now we recommend %defattr(-,root,root,-)

* %doc
   - Perhaps "%doc docs/" (not %doc docs/*) is better (this keeps
     directory structure)

* Directory ownership issue
  - The directory %_libdir/%name is not owned by any packages.
  ! By the way should files under %_libdir/%name really be in -devel
    subpackage? Usually these are modules of "main" binary and should
    not be in -devel subpackage.

* rpmlint issue
------------------------------------------------------------------
mlt-devel.i386: W: executable-stack /usr/lib/mlt/libmltgtk2.so
------------------------------------------------------------------
  - "rpmlint -I executable-stack" shows the explanation, however
    I don't know what to do for this...

ping?

pong!

Removing NEEDSPONSOR, as I am sponsoring submitter. 

Jebba: The ping in comment #6 was asking if you had a chance to address the issues mentioned in comment #5.

I was just buying time. :)

0.3.0-3

http://www.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt.spec
http://www.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt-0.3.0-3.fc9.src.rpm

Fixed:
- License: GPLv2+ and LGPLv2+
- Group: Development/Tools
- ExcludeArch: x86_64 s390 s390x ppc ppc64
- %%defattr(-,root,root)
- %%doc docs/
- %%{_libdir}/%%{name} to main package


Punted:
* mlt-devel.i386: W: executable-stack /usr/lib/mlt/libmltgtk2.so

* compilation flags, debug info

I'll be able to fix the compilation flags/debug, but I don't know about the executable-stack.

Thanks!  :)

Well,

* For compilation flags, removing -ffastmath, -fomit-frame-pointer and so on
  can be done (for this package) by:
--------------------------------------------------------------------
%build
sed -i -e '/fomit-frame-pointer/d' configure
sed -i -e '/ffast-math/d' configure
%configure --enable-gpl --disable-sox
---------------------------------------------------------------------

* For preventing binaries from being stripped, changing "install -c -s" to
  "install -c" (in Makefile's in this tarball) will fix it

* For execstack issue, accoding to
  https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Executable_stack
  the following will fix this issue:
---------------------------------------------------------------------
BuildRequires: prelink
....
execstack -c $RPM_BUILD_ROOT%{_libdir}/%{name}/libmltgtk2.so
----------------------------------------------------------------------

* About binaries' names
  - This package installs some files under %_bindir, some of them
    have too generic names (like miracle):
    https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace

    Would you rename binaries' names such as mlt-miracle, for example?

I am the maintainer of MLT. Thank you for packaging it for Fedora. My feedback...

It is possible to make a LGPL version if that is what you really want to do. You probably have to remove sources from your source RPM to do so. All GPL-based plugins are identified by an empty file named "gpl" in their subdirectory (under mlt/src/modules). Also, the albino, humperdink, miracle, and inigo src subdirectories are GPL.

I don't really know the Fedora guidelines, but Development/Libraries seems more appropriate than Development/Tools even though the description uses the word "toolkit."

It should be able to build on PPC, but that is not regularly tested as it has not been convenient for me. Maybe I can use some resource at SourceForge for that. More than likely it is something trivial. x86-dependent code should be optional, and the goal of the configure scripts is to detect PPC and disable things appropriately.

Regarding compilation optimization flags, another user said -O4 was causing segfault on x86-64 (pending my confirmation), and I may fall back to -O2 for the next release. I recognize Fedora's policy, but there are many also building from source who would like optimization. Also, I agree to remove stripping from future releases.

Finally, while I do not consider "miracle" to be generic, I do agree it is somewhat common and certainly unqualified. In fact, I recommend that you do not not install miracle or albino or humperdink. 'inigo' is the core utility that MLT users recognize and whose name I would like to keep. miracle is a rather niche application at this time, and albino and humperdink are companions to miracle. If you do keep miracle for the sake of convenience, then I do not have a problem with you prefacing it with 'mlt-', but again, I'd rather not do that to inigo. Also, I am planning to rename things in the near future while keeping the "MLT" moniker (Media Lovin' Toolkit). I will take Fedora recommendations into consideration for the executables.

* Mon Oct 13 2008 jeff <moe> - 0.3.0-4
- Build without fomit-frame-pointer ffmath
- Add BuildRequires: prelink
- clear-execstack libmltgtk2.so
- Don't strip binaries
- Group: Development/Libraries
- Prefix albino, humperdink, and miracle binaries with mlt-


I think we want GPL version not LGPL version, correct?


Mamoru Tasaka thanks for your help and Dan Dennedy thanks for the comments and for mlt and for kino and...  :)


http://www.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt.spec
http://www.blagblagblag.org/pub/BLAG/developers/jebba/jebbadora/mlt-0.3.0-4.fc9.src.rpm

Compiling for x86_64 build on f9 fails with:

=====================
cc -o have_mmx.o -c have_mmx.S
have_mmx.S: 
Assembler messages:
have_mmx.S:20: 
Error: 
suffix or operands invalid for `push'

...and for pushf, pop, popf...

make[2]: *** [have_mmx.o] Error 1
=====================

I have built mlt Fedora 8 x86_64 with --disable-qimage --disable-mmx and it worked also for rawhide.(0) But in this last case, i also need to disable see in %prep section:
----------
#disable sse unless x86_64
%ifnarch x86_64
sed -i.checksse -e 's|ifndef __DARWIN__|ifdef __DARWIN__|' src/modules/motion_est/filter_motion_est.c
#Note that this conditional is wrong
%endif
--------------
I haven't checked that, but if mmx is used on ppc, then is will certainly fails.
What i expect is mmx should be disabled in all cases unless i686:
%configure \
...
%ifnarch i686
 --disable-mmx \
%endif
So anyone that want to rebuild mlt with theses options can do so with using --target=i686 for the package.

There is lot of modules that aren't built. jack-rack,  frei0r (1) and sox(2) despite this last has been requested as BuildRequires; and there is also others that cannot be in Fedora.
The main interest of mlt using modules is that you can add support for theses module at install step. At the packaging level that would be interesting to have mlt splitted into sub-packages , specially if dependencies are huges (candidate are jack-rack and gtk ). 

About mlt-config, it is not multilibs compliant:
(see l.4: export libdir=/usr/lib64 on lib64 systems)
There are two workarounds, either hack the libdir value (if /usr/lib64 exist then... else /usr/lib...), or rewrite it as a wrapper around pkg-config.
But It would be possible IMO to just delete it and patch the dependent applications (if any ?) to use pkg-config for mlt detection.

(0) http://koji.fedoraproject.org/koji/taskinfo?taskID=879994
  ppc64 still has failed, might be because of asm conditionals, it should work guess.
(1) see https://bugzilla.redhat.com/show_bug.cgi?id=456256
(2) see https://bugzilla.redhat.com/show_bug.cgi?id=226425

Why exactly do you need to disable sse even for x86?
The changes you make to filter_motion_est.c are illogical, but they are effective at suppressing the respective code (since this is not Darwin platform). The top-level Makefile helper config.mak defines a USE_MMX unless --disable-mmx. Does this make more sense?
sed -i.checksse -e 's|ifndef __DARWIN__|if !defined(__DARWIN__) && defined(USE_MMX)|'

mlt-config should be deprecated because pkg-config files are also supplied. However, I do have to convert mlt++ over to pkg-config. I will do that now for the next release. Also, I will check to make sure kdenlive does not use it. I'll consider removing mlt-config as well.

I have also submitted a review request for mlt++

https://bugzilla.redhat.com/show_bug.cgi?id=459979

To Nicolas:
If you have some suggestion and have your own srpm for this package,
would you post it somewhere where we can download it anytime?
(don't use koji site for the place to put your srpm:
 it is deleted within one week or so).

(In reply to comment #15)
> Why exactly do you need to disable sse even for x86?
sse isn't present on all x86 CPU, Thus activating sse on suches CPU is totally forbidden in Fedora for a binary. It is possible to have sse2 activated for a library (see atlas for an example).
> The changes you make to filter_motion_est.c are illogical, but they are
> effective at suppressing the respective code (since this is not Darwin
> platform). The top-level Makefile helper config.mak defines a USE_MMX unless
> --disable-mmx. Does this make more sense?
Yes, this is a hack.
To fix this, it would be better to have a --disable-sse option. so it can be disabled unless x86_64. (as all x86_64 have the sse2 cpu capability).
Of course, as the koji built showned. You cannot set -DARCH_X86 on ppc64, so the cpu detection for the mlt build system should probably redesigned.
> 
> mlt-config should be deprecated because pkg-config files are also supplied.
> However, I do have to convert mlt++ over to pkg-config. I will do that now for
> the next release. Also, I will check to make sure kdenlive does not use it.
> I'll consider removing mlt-config as well.
I haven't tested it yet, but you should note that the last version of sox also have pkg-config support after having dropped any sox-config file in the F-9 version.

(In reply to comment #18)
> I haven't tested it yet, but you should note that the last version of sox also
> have pkg-config support after having dropped any sox-config file in the F-9
> version.

mlt does support sox with pkg-config except the sox 14.1.0 .pc file is wrong:
https://sourceforge.net/tracker/index.php?func=detail&aid=2076270&group_id=10706&atid=310706

Also, after making some changes (svn trunk) to deal with a changed interface, mlt still crashes on latest sox due to invisible changes :(

If you only have a sox 14.1.0 package, then please disable the corresponding mlt module for now: configure --disable-sox. I do plan to fix this prior to the next mlt release.

(In reply to comment #18)
> Of course, as the koji built showned. You cannot set -DARCH_X86 on ppc64, so
> the cpu detection for the mlt build system should probably redesigned.

The mlt xine module should disable itself for ppc64 via src/modules/xine/configure. I have added "ppc64" to its tests in svn:
http://mlt.svn.sourceforge.net/viewvc/mlt/trunk/mlt/src/modules/xine/configure?r1=1121&r2=1185

(In reply to comment #19)
> mlt does support sox with pkg-config except the sox 14.1.0 .pc file is wrong:
> https://sourceforge.net/tracker/index.php?func=detail&aid=2076270&group_id=10706&atid=310706
Why ?
Even if sox.h ends in $(PREFIX)/include , /usr/include will be in the default
path, so the header will be found anyway... It would be better to have sox.h
not in the default path and use -I/usr/include/sox each time sox libraries are
meant to be linked.

for xine:
Indeed, so it is disabled unless %{ix86} and x86_64

SPECS: http://kwizart.fedorapeople.org/SPECS/mlt.spec
SRPMS: http://kwizart.fedorapeople.org/SRPMS/mlt-0.3.0-5.fc8.kwizart.src.rpm
Summary: Toolkit for broadcasters, video editors, media players, transcoders

There is still some work, specially for (at least):
- The multilibs compliance (to split the binaries and the libraries).
- The modules packaged as sub-packages (so the dependencies will be installed as needed - see https://bugzilla.redhat.com/show_bug.cgi?id=457035#c7 for a discution on rpm packaging and modules).
- Have runtime tests to be done.
If the frei0r-devel package isn't ready, it could be possible to enable it later...

I can offer my help as co-maintainer of the package.

kwizart, OK, re: co-maintainer  :)

(In reply to comment #21)
> (In reply to comment #19)
> > mlt does support sox with pkg-config except the sox 14.1.0 .pc file is wrong:
> > https://sourceforge.net/tracker/index.php?func=detail&aid=2076270&group_id=10706&atid=310706
> Why ?
> Even if sox.h ends in $(PREFIX)/include , /usr/include will be in the default
> path, so the header will be found anyway... It would be better to have sox.h
> not in the default path and use -I/usr/include/sox each time sox libraries are
> meant to be linked.

You can debate that with the sox developers, not me; it's not my project. The fact of the matter is that it installs a sox.h to includedir defaulted as $prefix/include, and when the $prefix is not /usr, then the header can not be found by simply using 'pkg-config --cflags'

Anyways, I suppose this problem does not affect your packaging and therefore worth further discussion, but the runtime compatibility problem between mlt and sox 14.1.0 remains.

(In reply to comment #21)
> There is still some work, specially for (at least):
> - The multilibs compliance (to split the binaries and the libraries).

Is there something I should do to facilitate this? I have already fixed up mlt++ to use pkg-config (svn trunk) and submitted a patch to kdenlive.

> - Have runtime tests to be done.
> If the frei0r-devel package isn't ready, it could be possible to enable it
> later...

I do not understand. Is there some upstream change you are suggesting?

What is the status of this bug?

I just wonder if it seems rational to build plugins for applications that cannot goes to fedora  (let's name kino or kdenelive) ?
At least I wonder if we lack libffmpeg support the program would still be usable ?

And what about extending capabilities ?
In my test case, the libavformat module failed to load :
mlt_repository.c, mlt_repository_init: failed to dlopen /usr/lib64/mlt/libmltavformat.so
Whereas the file seems present.

(In reply to comment #26)
> I just wonder if it seems rational to build plugins for applications that
> cannot goes to fedora  (let's name kino or kdenelive) ?

Do you refer to Kino and kdenlive the applications or to the MLT modules named kino and kdenlive? Kino does not use MLT, but kdenlive requires it. The MLT kino module simply contains Kino's DV AVI code. The MLT kdenlive module does not contain anything specific to kdenlive. Rather, it is more of a work area for the kdenlive lead developer to add his own effects to MLT.

> At least I wonder if we lack libffmpeg support the program would still be
> usable ?

MLT is hardly usable at this time without FFmpeg libavformat and libavcodec. There are plans for a gstreamer module, but work has not yet begun. Without FFmpeg, MLT can still be useful for DV only work via libdv and the kino module.

> And what about extending capabilities ?
> In my test case, the libavformat module failed to load :
> mlt_repository.c, mlt_repository_init: failed to dlopen
> /usr/lib64/mlt/libmltavformat.so
> Whereas the file seems present.

Either there are unresolved symbols or some other build error preventing loading. Quite recently, FFmpeg starting requiring libbz2, and depending upon how you configured, that might be missing. You can do a 'ldd $(which ffmpeg)' and 'ldd libmltavformat.so' and compare them.

It looks like the upstream (Dan) made a new release. Who's going to build this package? Dan, is this ready to package now?

There are still some things in Nicolas' comments #18 and #21 that are not addressed because I do not fully understand them. To be honest, I hardly understand anything he writes.
 
- I do not understand why the existing --disable-mmx is not satisfactory; maybe he meant "--disable-sse2" instead of "--disable-sse". But it seems to me all of MLT's usage of MMX is not acceptable to Fedora i386 policy, and I know some of it is not yet compatible with x86-64. So, it seems to me --disable-mmx should be fine as a global option regardless of architecture of the build.

- I know nothing about multilibs.

- Re: "- Have runtime tests to be done." What exactly does that mean? MLT already attempts to dlopen all so in lib/mlt.

Another release is planned before end-of-year.

(In reply to comment #29)
...
> - I do not understand why the existing --disable-mmx is not satisfactory; maybe
> he meant "--disable-sse2" instead of "--disable-sse". But it seems to me all of
> MLT's usage of MMX is not acceptable to Fedora i386 policy, and I know some of
> it is not yet compatible with x86-64. So, it seems to me --disable-mmx should
> be fine as a global option regardless of architecture of the build.
We can build the library twice within one mlt.i386 package for i386. (that's done with the "atlas" package for an example)
- one time with mmx sse sse2 disabled. 
- one other time with mmx sse sse2 enabled. The resulting optimized library will be moved in /usr/lib/sse2 and activated at runtime if the dynamic library loader has detected the running cpu is sse2 capable.

For this feature to be enabled, we need to be sure nothing will hardcode the libraries pathes, and that it will be correctly linked (not dlopened for example).


> - I know nothing about multilibs.
That's a packaging level problem.

> - Re: "- Have runtime tests to be done." What exactly does that mean? MLT
> already attempts to dlopen all so in lib/mlt.
That's really bad. 
We are in $prefix/lib64/mlt on x86_64 ppc64 sparc64 (aka multilibs systems, so not ia64).
It would be easier to use libtool-ltdl, but i don't know how to add support for it easily with you current buildsys. Anyway, you should be able to tweak the dlopening path to be correct.



Once that said, I'm not sure I can support one more split between mlt non-ffmpeg enabled and mlt-freeworld ffmpeg enabled. Is there any package using mlt that can be in Fedora once mlt is in ?

> we need to be sure nothing will hardcode the libraries pathes
...
> > MLT already attempts to dlopen all so in lib/mlt.
> That's really bad. We are in $prefix/lib64/mlt on x86_64 ppc64 sparc64

Sorry for my miscommunication. I did not mean literally "lib/mlt." It is actually *defaulted* to $(libdir)/mlt, where there is a ./configure option --libdir. The application can override this via API, and there is an environment variable as well.

> Once that said, I'm not sure I can support one more split between mlt
> non-ffmpeg enabled and mlt-freeworld ffmpeg enabled.

I don't want this project to be a nuisance with too many configurations. First of all, I think I should split up my ffmpeg module because there are some elements for deinterlace and color space conversion that are unencumbered and then  encumbered format/codec-oriented elements. That would let you or someone else just make a separate package with the encumbered elements similar to gstreamer-ffmpeg. MLT has libdv and libvorbis modules that still make it usable without the encumbered ffmpeg elements. I do not yet think it is necessary to have good, bad, and ugly packages separate from the framework lib, do you? I think the framework and majority of plugin modules can be in one package. In that case, I need to make it easier/possible to separately build the encumbered ffmpeg module. Feedback welcome.

> Is there any package using mlt that can be in Fedora once mlt is in?

kdenlive, which was rewritten for KDE4 and proving to be fairly usable and stable.

(In reply to comment #14)
> I have built mlt Fedora 8 x86_64 with --disable-qimage --disable-mmx and it
> worked also for rawhide.(0) But in this last case, i also need to disable see
> in %prep section:
> ----------
> #disable sse unless x86_64
> %ifnarch x86_64
> sed -i.checksse -e 's|ifndef __DARWIN__|ifdef __DARWIN__|'
> src/modules/motion_est/filter_motion_est.c
> #Note that this conditional is wrong
> %endif

SSE detection should be moved to ./configure and the code containing SSE instructions should be wrapped in #ifdef HAVE_SSE ... #endif. Please ask upstream to do that.

> --------------
> I haven't checked that, but if mmx is used on ppc, then is will certainly
> fails.
> What i expect is mmx should be disabled in all cases unless i686:
> %configure \
> ...
> %ifnarch i686
>  --disable-mmx \
> %endif
> So anyone that want to rebuild mlt with theses options can do so with using
> --target=i686 for the package.

Actually, there are i686 class CPUs without MMX, for example Pentium Pro and there are i586 class CPUs with MMX (Pentium MMX, AMD K6 and K6-2/3). I'd suggest a --with mmx conditional instead. You cannot rely on --target here. Of course, it'd be best handled upstream in a fashion similar to what I've suggested for SSE above.

(In reply to comment #32)

> Actually, there are i686 class CPUs without MMX, for example Pentium Pro and
I'm against to worry about something lower than a PIII specially on a library dedicated for multimedia features.
The current workaround would be to allow a i686 target that can have mmx sse and sse2 enabled on x86_32 arch. CPU that aren't capable of theses optimization should remains with the plain i386 package which is the only package that will be provided within the Fedora repositories.
Once that said, if the i686 target_cpu doesn't fit well for our needs, then we might want to introduce another ix86 varriant as a rpm macro.

But in any cases, 

Please note that the mmx miss on some ix86 CPU are more important in some Via C3 cases than in pentium pro

(In reply to comment #32)
> (In reply to comment #14)
> > I have built mlt Fedora 8 x86_64 with --disable-qimage --disable-mmx and it
> > worked also for rawhide.(0) But in this last case, i also need to disable see
> > in %prep section:
> > ----------
> > #disable sse unless x86_64
> > %ifnarch x86_64
> > sed -i.checksse -e 's|ifndef __DARWIN__|ifdef __DARWIN__|'
> > src/modules/motion_est/filter_motion_est.c
> > #Note that this conditional is wrong
> > %endif
> 
> SSE detection should be moved to ./configure and the code containing SSE
> instructions should be wrapped in #ifdef HAVE_SSE ... #endif. Please ask
> upstream to do that.

I am upstream, and I have done this. I also checked other code assumed to be MMX to make sure it was not using SSE, and it is not.
 
> > --------------
> > I haven't checked that, but if mmx is used on ppc, then is will certainly
> > fails.
> > What i expect is mmx should be disabled in all cases unless i686:

The configure script checks /proc/cpuinfo on Linux to see if "mmx: 1" and "sse: 1" to automatically disable the respective options. However, you are probably cross-compiling to ppc?

> > %configure \
> > ...
> > %ifnarch i686
> >  --disable-mmx \
> > %endif
> > So anyone that want to rebuild mlt with theses options can do so with using
> > --target=i686 for the package.
> 
> Actually, there are i686 class CPUs without MMX, for example Pentium Pro and
> there are i586 class CPUs with MMX (Pentium MMX, AMD K6 and K6-2/3). I'd
> suggest a --with mmx conditional instead. You cannot rely on --target here. Of
> course, it'd be best handled upstream in a fashion similar to what I've
> suggested for SSE above.

There is still a --disable-mmx. It implies --disable-sse.

Do you want to test this from a svn snapshot prior to my next release - planned before end-of-year?

(In reply to comment #31)
> I don't want this project to be a nuisance with too many configurations. First
> of all, I think I should split up my ffmpeg module because there are some
> elements for deinterlace and color space conversion that are unencumbered and
> then  encumbered format/codec-oriented elements. That would let you or someone
> else just make a separate package with the encumbered elements similar to
> gstreamer-ffmpeg. MLT has libdv and libvorbis modules that still make it usable
> without the encumbered ffmpeg elements. I do not yet think it is necessary to

In MLT SVN trunk, I have added a configure option --avformat-no-codecs. This will build the MLT avformat plugin without exposing *any* of the codecs or muxers. This does make a plugin that contains the deinterlace, resampling, and color space converter. The color space converter is required at the moment to make this usable. The --avformat-svn configure option will checkout a specific revision of FFmpeg and then statically link the MLT plugin against it if that makes it any easier (no shared ffmpeg libs to link against).

Someone can then make a mlt-ffmpeg package for rpmfusion.org that does something along the lines of:
./configure ...
make -C src/framework
make -C src/modules/avformat all install

This would put only that plugin into the package, but at this point it is a replacement for the one from the main mlt package. IOW, it shares the same file path/name. Is that a problem?

I added a new configure option --avformat-no-filters to facilitate a codecs and muxers only plugin whose name will not conflict with a "stock" --avformat-no-codecs plugin. Of course, that is for rpmfusion.org or other non-fedora, but just to let you know that this will prevent a plugin filename clash on a mlt-ffmpeg package and relieve any concerns in that regard.

Finally, I have also made changes to mlt and patch to kdenlive to remove all ffmpeg library dependencies from kdenlive to make that easier for acceptance. All of these changes should be in mlt 0.3.4 and kdenlive 0.7.1 due out by the end of the year.

This is one of the slowest progressing bugs I have seen. It doesn't stall, it keeps going, but slow.

Folks, we do need nice applications such as kdenlive in Fedora. Can we boost up the pace a little?

Complaining fellows: What else do we need from mlt upstream? Or is version 0.3.4 good enough for packaging? 

I have a feeling that we are waiting for mlt to be capable of running on some ancient computers.

0.3.6 is here. 

@jebba
Are you still interested in mlt ?

ping someone...

kwizart, I think you should take this package over, otherwise it might take a very long time for it to get done. I can do the review if you want.

I'm sorry to say that jebba's MIA in order to spend more time on other things in life.  IF no one wants to take this over, this bug should be closed.

Hello, I took with Dan about ffmpeg libs in mlt.
So, I have a question:

Can we maybe build kdenlive's RPM on that way it can use mlt (without ffmpeg) if you do not have enabled fusion repo, or with mlt-ffmpeg if you have fusion enabled?

Or on other hand, we must build two kdenlive RPMs. (one with mlt, and one with mlt-ffmpeg). That one without ffmpeg call kdenlive and put on Fedora's repo, and another call kdenlive-ffmpeg and put them on Fusion repo.

I think this is unnecessary mess, and will be better put the mlt, mlt++ and kdenlive to Fusion repo.

kind regards

zarko

Is mlt totally useless without kdenlive? 

Can someone write an application that uses mlt and no ffmpeg? If yes, mlt package belongs to Fedora. Otherwise, we can carry it over to rpmfusion.

This package transferred to RPM Fusion:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=527

Can you close it here?

Fail's legal. It uses ffmpeg, so it's being transferred.

I need this for the most recent synfig, and looking at mlt now, at first glance, I think this can come to Fedora now.  Am I mistaken?