http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Zarko Pintar changed:
What|Removed |Added
Blocks||528
--
Configure bugmail: http://bugz
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Zarko Pintar changed:
What|Removed |Added
Blocks||30
--
Configure bugmail: http://bugzi
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Zarko Pintar changed:
What|Removed |Added
Blocks||529
--
Configure bugmail: http://bugz
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Orcan Ogetbil changed:
What|Removed |Added
CC||oget.fed...@gmail.com
--- Comment #1
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #2 from Zarko Pintar 2009-04-09 08:27:49
---
(In reply to comment #1)
> A few initial notes:
>
> * Can't we enable mmx at least for x86_64 ?
Yes we can :) Enabled is now
>
> * Please make use of the %{name} macro for consiste
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #3 from Orcan Ogetbil 2009-04-11 21:12:18
---
(In reply to comment #2)
> (In reply to comment #1)
> > A few initial notes:
> >
> > * Can't we enable mmx at least for x86_64 ?
>
> Yes we can :) Enabled is now
>
Okay, but we do
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #4 from Zarko Pintar 2009-04-11 23:17:17
---
>
> Okay, but we don't want that for ppc/ppc64 architectures. Now, looking at the
> configure script I don't see a --enable-mmx flag. It is already enabled by
> default. You just need
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #5 from Kevin Kofler 2009-04-12 11:34:25
---
If there's no runtime detection, enabling MMX on i586 breaks old 586-class CPUs
(e.g. the original Pentium).
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=em
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #6 from Orcan Ogetbil 2009-04-13 04:17:03
---
(In reply to comment #5)
> If there's no runtime detection, enabling MMX on i586 breaks old 586-class
> CPUs
> (e.g. the original Pentium).
>
Yes, but the question is: Does this so
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Jarod Wilson changed:
What|Removed |Added
CC||ja...@wilsonet.com
--- Comment #7 from
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Jussi Lehtola changed:
What|Removed |Added
CC||jussi.leht...@iki.fi
--- Comment #8 f
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #9 from Zarko Pintar 2009-04-13 11:30:33
---
(In reply to comment #6)
> (In reply to comment #5)
> > If there's no runtime detection, enabling MMX on i586 breaks old 586-class
> > CPUs
> > (e.g. the original Pentium).
> >
>
>
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #10 from Zarko Pintar 2009-04-13 16:09:12
---
Now I reslove MMX problem, and demo files.
> The group for the main package should probably be System
> Environment/Libraries.
> Right?
MLT is a framework, so it is a development s
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #12 from Zarko Pintar 2009-04-14 12:02:55
---
(In reply to comment #11)
> freir0-plugins is now available in fedora.
>
Good! :)
So, I'll add frei0r-plugins into mlt build.
Currently, I'm preparing my development environment (
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
NicolasChauvet changed:
What|Removed |Added
CC||kwiz...@gmail.com
--- Comment #11 fr
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #13 from Zarko Pintar 2009-04-15 15:55:37
---
- New MLT version 0.3.8
- Tested for upcoming Fedora 11
- Rpmlint:
mlt.i586: W: shared-lib-calls-exit /usr/lib/libmiracle.so.0.3.8
e...@glibc_2.0
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Orcan Ogetbil changed:
What|Removed |Added
Blocks|2 |3
Status|NEW
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #15 from NicolasChauvet 2009-04-16 10:21:57 ---
*
>* src/modules/jackrack/plugin_mgr.c has
> /usr/local/lib/ladspa:/usr/lib/ladspa
>hardcoded, which won't work on 64bit systems. Please fix this.
The same would be needed for frei
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #16 from Zarko Pintar 2009-04-16 10:57:04
---
(In reply to comment #14)
> * rpmlints:
> mlt.i586: W: shared-lib-calls-exit /usr/lib/libmiracle.so.0.3.8
> e...@glibc_2.0
>
> So this isn't removed in this release. What happen
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #17 from Orcan Ogetbil 2009-04-16 17:12:25
---
(In reply to comment #16)
> (In reply to comment #14)
> > * Each package must consistently use macros, as described in the macros
> > section
> > of Packaging Guidelines .
> > Pleas
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #18 from Orcan Ogetbil 2009-04-16 17:14:22
---
(In reply to comment #15)
> *
> >* src/modules/jackrack/plugin_mgr.c has
> > /usr/local/lib/ladspa:/usr/lib/ladspa
> >hardcoded, which won't work on 64bit systems. Please fix this.
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #19 from Zarko Pintar 2009-04-16 22:05:39
---
Here is the answer from MLT developer about renaming binaries:
Citation:
> Please, can you look at:
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=527
If you rename executables, es
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #20 from Orcan Ogetbil 2009-04-16 22:16:46
---
Well, you can match kdenlive to use the correct binaries if that's the problem.
Just out of curiousity, how many miracles do we have in Fedora? :)
--
Configure bugmail: http://bu
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #21 from Zarko Pintar 2009-04-16 22:45:56
---
(In reply to comment #20)
> Well, you can match kdenlive to use the correct binaries if that's the
> problem.
>
Yes, but isn't is a so-called "bypass". Renaming original binaries f
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #22 from Orcan Ogetbil 2009-04-16 22:53:02
---
(In reply to comment #21)
>
> So, I still think that abandon renaming in spec file is better solution.
>
>
I'm fine with that. I don't think "miracle" is too common of a name. Th
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #23 from Zarko Pintar 2009-04-16 23:02:03
---
>
> I'm fine with that. I don't think "miracle" is too common of a name. There are
> many more common names we already have, like "/usr/bin/play" of the sox
> package, or "/usr/bin/
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #24 from Orcan Ogetbil 2009-04-17 01:18:21
---
(In reply to comment #23)
>
> I can exclude "miracle" from package until Dan resolve this binary in next
> SVN.
> I can patch MLT than
>
> Or, if you have some better solution
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #25 from Orcan Ogetbil 2009-04-17 05:32:44
---
* I also missed this: These lines
# Don't optimize (breaks debugging)
sed -i -e '/fomit-frame-pointer/d' configure
sed -i -e '/ffast-math/d' configure
should go to %prep
-
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #26 from Zarko Pintar 2009-04-17 13:18:07
---
(In reply to comment #14)
>
> * src/modules/jackrack/plugin_mgr.c has
>/usr/local/lib/ladspa:/usr/lib/ladspa
> hardcoded, which won't work on 64bit systems. Please fix this.
>
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #27 from NicolasChauvet 2009-04-17 13:27:04 ---
(In reply to comment #26)
> (In reply to comment #14)
>
> >
> > * src/modules/jackrack/plugin_mgr.c has
> >/usr/local/lib/ladspa:/usr/lib/ladspa
> > hardcoded, which won't work
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #28 from Zarko Pintar 2009-04-17 13:29:23
---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #14)
> >
> > >
> > > * src/modules/jackrack/plugin_mgr.c has
> > >/usr/local/lib/ladspa:/usr/lib/l
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #29 from Kevin Kofler 2009-04-17 15:45:35
---
Because it's your job as a packager to make things work out of the box.
Requiring the user to set environment variables is just plain not acceptable.
You could set them in /etc/profi
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #30 from Orcan Ogetbil 2009-04-17 15:51:58
---
(In reply to comment #26)
> (In reply to comment #14)
>
> >
> > * src/modules/jackrack/plugin_mgr.c has
> >/usr/local/lib/ladspa:/usr/lib/ladspa
> > hardcoded, which won't work
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #31 from Zarko Pintar 2009-04-17 16:07:18
---
>
> and what will set the LADSPA_PATH during runtime? No, just patch (or sed) it
> up, and there won't be no worries.
My mistake...
but if I put in spec some like this:
%post
/sbi
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #32 from Rex Dieter 2009-04-17 16:12:07 ---
Re:%post hack for env variables
That'll set it only for the *install* environment, not runtime for all users.
ie, won't work (as-is). fixing properly as suggested is a much preferred
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #33 from Zarko Pintar 2009-04-17 16:14:27
---
(In reply to comment #32)
> Re:%post hack for env variables
>
> That'll set it only for the *install* environment, not runtime for all users.
> ie, won't work (as-is). fixing prope
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #34 from Orcan Ogetbil 2009-04-17 17:09:30
---
(In reply to comment #31)
> >
> > and what will set the LADSPA_PATH during runtime? No, just patch (or sed) it
> > up, and there won't be no worries.
>
> My mistake...
> but if I p
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #35 from Orcan Ogetbil 2009-04-17 17:10:50
---
Created an attachment (id=163)
--> (http://bugzilla.rpmfusion.org/attachment.cgi?id=163)
adds .note.GNU-stack section
--
Configure bugmail: http://bugzilla.rpmfusion.org/userpref
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #36 from NicolasChauvet 2009-04-17 17:26:02 ---
(In reply to comment #34)
...
> It's okay, you learn with experience. It will be enough to change the line
>ladspa_path = g_strdup ("/usr/local/lib/ladspa:/usr/lib/ladspa");
> in
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #37 from Dan Horák 2009-04-17 17:40:03 ---
(In reply to comment #36)
> (In reply to comment #34)
> ...
> > It's okay, you learn with experience. It will be enough to change the line
> >ladspa_path = g_strdup ("/usr/local/lib/l
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #38 from Kevin Kofler 2009-04-17 17:43:53
---
Searching both lib and lib64 won't work if both the 32-bit and the 64-bit
version of the library are installed.
The correct solution is to write a patch which looks *only* in the lib
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #39 from Zarko Pintar 2009-04-17 17:44:55
---
(In reply to comment #36)
> (In reply to comment #34)
> ...
> > It's okay, you learn with experience. It will be enough to change the line
> >ladspa_path = g_strdup ("/usr/local/l
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #40 from Zarko Pintar 2009-04-17 17:48:36
---
(In reply to comment #38)
> Searching both lib and lib64 won't work if both the 32-bit and the 64-bit
> version of the library are installed.
>
> The correct solution is to write a p
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #41 from Kevin Kofler 2009-04-17 17:52:31
---
Yes, that's what I mean.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #42 from Orcan Ogetbil 2009-04-17 17:55:24
---
(In reply to comment #38)
> Searching both lib and lib64 won't work if both the 32-bit and the 64-bit
> version of the library are installed.
>
This is the plugin directory. No lad
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #43 from Zarko Pintar 2009-04-18 00:28:00
---
> ! All relevant doc files should be packaged. ./src/modules/motion_est/README
> can go to the %doc of the main package
How I can elegantly solve this?
I tried with this:
%doc AUTH
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #44 from Orcan Ogetbil 2009-04-18 01:26:46
---
(In reply to comment #43)
> > ! All relevant doc files should be packaged. ./src/modules/motion_est/README
> > can go to the %doc of the main package
>
> How I can elegantly solve t
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #45 from Kevin Kofler 2009-04-18 01:29:17
---
> How I can elegantly solve this?
[snip]
> cp: will not overwrite just-created
> `/builddir/build/BUILDROOT/mlt-0.3.8-2.fc10.i386/usr/share/doc/mlt-0.3.8/README'
> with `src/modules/m
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #46 from Zarko Pintar 2009-04-18 23:42:14
---
Here are the newest files:
Spec:
http://wiki.open.hr/~zpintar/fedora-11/RPMFusion/SPECS/mlt.spec
SRPM:
http://wiki.open.hr/~zpintar/fedora-11/RPMFusion/SRPMS/mlt-0.3.8-2.fc10.src.rpm
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #47 from Orcan Ogetbil 2009-04-20 01:50:21
---
The package looks a lot better in shape now. The remaining problems are:
1- shared-lib-calls-exit
2- the segfaults
3- unused-direct-shlib-dependency
You could do the fixes yourself
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #48 from Zarko Pintar 2009-04-20 08:22:57
---
(In reply to comment #47)
> The package looks a lot better in shape now. The remaining problems are:
>
> 1- shared-lib-calls-exit
> 2- the segfaults
> 3- unused-direct-shlib-dependen
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #49 from Dan Horák 2009-04-20 08:28:18 ---
(In reply to comment #47)
> The package looks a lot better in shape now. The remaining problems are:
>
> 1- shared-lib-calls-exit
I usually ask upstream whether it is intended behaviour
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #50 from Kevin Kofler 2009-04-21 05:15:15
---
If the package was built against Qt 4.5, it won't run against 4.4.
This is going to become a non-issue very soon as Qt 4.5 is now queued for
stable.
--
Configure bugmail: http://b
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #51 from Zarko Pintar 2009-05-01 15:09:48
---
Huh, some new infos about MLT and Segmentation faults under F10.
I successfully localize a problem.
So, this Faults happens only if build MLT with ffmpeg-devel package.
Without ffmpe
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #52 from Orcan Ogetbil 2009-05-01 19:15:44
---
So, mlt is not compatible with older versions of ffmpeg. Then it's okay if you
are going to submit it to F-11+.
The unused-direct-shlib-dependency can probably be fixed by
sed -
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #53 from Kevin Kofler 2009-05-07 04:18:36
---
IMHO we'll want the kdenlive stack at least on F10 too (F9 is almost EOL, so
maybe not worth bothering), so I think we really need a solution for the
mlt/ffmpeg issue (though it shoul
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #54 from Kevin Kofler 2009-05-07 04:20:48
---
Oh, and can you please produce a backtrace for those segfaults, using GDB
and/or Valgrind?
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You a
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #55 from Zarko Pintar 2009-05-07 09:33:15
---
(In reply to comment #52)
> So, mlt is not compatible with older versions of ffmpeg. Then it's okay if you
> are going to submit it to F-11+.
My primary target is F11, but I want als
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #56 from Zarko Pintar 2009-05-07 13:24:43
---
(In reply to comment #52)
>
> The unused-direct-shlib-dependency can probably be fixed by
>sed -i -e 's| -lm | -Wl,--as-needed\0|' src/framework/Makefile
> in %prep. This is insp
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #57 from Orcan Ogetbil 2009-05-07 21:02:43
---
(In reply to comment #56)
>
> Rpmlint do not report warning, but this fix produces error when I try call
> miracle binary:
>
> F10-x86_64 arch:
> mlt_repository_init: failed to dlo
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #58 from Zarko Pintar 2009-05-07 22:20:06
---
> > NO MORE Seg. faults on F10 branch with my machine! (I do not know why) So,
> > please can you check this, too?
> >
>
> I still get the segfaults on F-10.
>
Yes, at home I get
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Orcan Ogetbil changed:
What|Removed |Added
Blocks|3 |2
--- Comment #59 from Orcan Ogetbil
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #60 from Zarko Pintar 2009-05-08 08:12:09
---
(In reply to comment #59)
>
> I'm not going to write a patch after such a response. In fact, I'm not willing
> to support this guy and I'm resigning from the review. If there's anyon
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Dan Dennedy changed:
What|Removed |Added
CC||d...@dennedy.org
--- Comment #61 from D
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #62 from Zarko Pintar 2009-05-08 23:45:16
---
(In reply to comment #61)
> Dear Zarko and Orcan,
>
> I am sorry if my comments offended you. It may be known to some that I am not
> particularly fond of some Fedora policies. Howev
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #63 from Kevin Kofler 2009-05-09 00:27:11
---
I don't see how calling exit() from a shared lib would be a review blocker!
rpmlint warns about it because it is not a nice thing to do, but:
* this is an upstream issue,
* in most ca
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #64 from Dan Dennedy 2009-05-10 07:33:53 ---
Zarko,
Please adapt the RPM spec to my newly organized source tree and test it. You
need to first git clone git://dennedy.org/mlt.git. If you want to make a
mlt-0.3.9.tar.gz, then just
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #65 from Zarko Pintar 2009-05-11 14:32:22
---
(In reply to comment #64)
> Zarko,
> Please adapt the RPM spec to my newly organized source tree and test it. You
> need to first git clone git://dennedy.org/mlt.git. If you want to m
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #66 from Kevin Kofler 2009-05-11 15:01:09
---
This:
> /usr/bin/ld: MltConsumer.o: relocation R_X86_64_32 against `a local symbol'
> can
not be used when making a shared object; recompile with -fPIC
is the same bug as this:
>
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #67 from Dan Dennedy 2009-05-11 20:00:02 ---
I have applied the noexec-stack patch and added PIC flags to the building of
libmlt++. Please update!
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #68 from Zarko Pintar 2009-05-11 23:01:16
---
(In reply to comment #67)
> I have applied the noexec-stack patch and added PIC flags to the building of
> libmlt++. Please update!
>
I am.
For now, under i386 architecture no more
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #69 from Dan Dennedy 2009-05-12 09:11:24 ---
If you ask gdb for a backtrace or 'where' you get nothing more? If so, please
send me the command you are running and the strace output.
--
Configure bugmail: http://bugzilla.rpmfusi
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #70 from Zarko Pintar 2009-05-12 11:34:15
---
(In reply to comment #69)
> If you ask gdb for a backtrace or 'where' you get nothing more? If so, please
> send me the command you are running and the strace output.
>
This is a ba
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #71 from Dan Horák 2009-05-12 11:41:15 ---
(In reply to comment #70)
> (In reply to comment #69)
> > If you ask gdb for a backtrace or 'where' you get nothing more? If so,
> > please
> > send me the command you are running and th
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #72 from Zarko Pintar 2009-05-12 12:01:08
---
(In reply to comment #71)
> Zarko, you should install at least mlt-debuginfo (directly with rpm) and
> debuginfos for libselinux (via "debuginfo-install libselinux") to get somewhat
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #73 from Zarko Pintar 2009-05-12 12:03:23
---
And, this is from gdb, but before backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0097f7c4 in fini_context_translations () at setrans_client.c:243
243 f
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #74 from Kevin Kofler 2009-05-12 14:16:58
---
Ah, this appears to be the same crash on exit we're seeing with KDE 3 apps
using ffmpeg (Kaffeine and K3b with the -freeworld plugins installed). We've
tracked it down to something ca
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #75 from Zarko Pintar 2009-05-12 15:03:51
---
(In reply to comment #74)
> Ah, this appears to be the same crash on exit we're seeing with KDE 3 apps
> using ffmpeg (Kaffeine and K3b with the -freeworld plugins installed). We've
>
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #76 from Zarko Pintar 2009-05-13 09:04:11
---
Here is the latest build:
http://wiki.open.hr/~zpintar/fedora-11/RPMFusion/SPECS/mlt.spec
http://wiki.open.hr/~zpintar/fedora-11/RPMFusion/SRPMS/mlt-0.3.9-2.fc11.src.rpm
There is no
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #77 from Dan Dennedy 2009-05-13 10:17:20 ---
> In the source we still have two licenses (GPL and LGPL) but which is right?
Both. libmlt, libmlt++, and some modules are LGPL. Some other modules and melt
are GPL. The GPL modules mu
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #78 from Zarko Pintar 2009-05-13 10:33:59
---
(In reply to comment #77)
>
> Next steps for me are to release this. I already provided a patch for kdenlive
> to deal with mlt changes.
>
Ok, than I'm waiting for some Fedora's r
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #79 from Zarko Pintar 2009-05-18 15:07:35
---
Stable release of MLT 0.4.0 is out
Here is the latest build:
http://wiki.open.hr/~zpintar/fedora-11/RPMFusion/SPECS/mlt.spec
http://wiki.open.hr/~zpintar/fedora-11/RPMFusion/SRPMS/ml
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #80 from Orcan Ogetbil 2009-05-20 07:35:34
---
Upon Zarko's personal request I had a look at this last version of the package.
- The license tag is fine. Some parts of the software is GPL, some part is
LGPL.
* The segfault on F
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #81 from Zarko Pintar 2009-05-20 08:44:14
---
(In reply to comment #80)
>
> * The segfault on F-10 persists (just run /usr/bin/mlt)
Yes, but please can you read Kevin's comment (comment #74) about this
segfaults. He compared th
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #82 from Jussi Lehtola 2009-05-20 09:46:57
---
(In reply to comment #81)
> LDFLAGS has -lmlt option enabled for this library, or I'm seeing something
> completely wrong, or -lmlt and -lm isn't same (I think that's -lmlt is the
>
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #83 from Dan Dennedy 2009-05-20 09:57:05 ---
I fixed the linking of libmltmotionest.so with libm, and I fixed the license in
the comment header in src/mlt++/config.h to be consistent with the rest of the
files in that dir. These a
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #84 from Dan Dennedy 2009-05-20 10:01:05 ---
Also, there is no "license" for the demo/ directory. It's mainly just example
command lines.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You a
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #85 from Zarko Pintar 2009-05-20 10:28:01
---
(In reply to comment #83)
>Can
> you try passing --disable-mmx and --disable-sse to configure for the ppc
> build?
Yeah, I did.
Here are new files:
http://wiki.open.hr/~zpintar/fed
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #86 from Orcan Ogetbil 2009-05-20 19:11:54
---
Zarko,
Could you backport the -lm and the config.h license patches from the trunk?
http://mltframework.org/gitweb/mlt.git?p=mltframework.org/mlt.git;a=commitdiff_plain;h=8d7eab075dc
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #87 from Zarko Pintar 2009-05-20 22:42:59
---
(In reply to comment #86)
> Zarko,
> Could you backport the -lm and the config.h license patches from the trunk?
> Now, we need to set the license tag for the devel subpackage to LGP
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Orcan Ogetbil changed:
What|Removed |Added
Blocks|2, 30 |3
--- Comment #88 from Orcan Ogetbil
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #89 from Zarko Pintar 2009-05-21 22:53:03
---
(In reply to comment #88)
> Thanks Dan and Zarko. I think this is the best we can do for the time being.
Thanks to you, too. :)
>
> Zarko, it is a good practice to add a comment fo
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #90 from Orcan Ogetbil 2009-05-21 23:14:54
---
(In reply to comment #89)
> (In reply to comment #88)
> >
> > Zarko, it is a good practice to add a comment for each patch and additional
> > source file (if there's any), indicatin
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #91 from Zarko Pintar 2009-05-22 12:08:03
---
(In reply to comment #90)
> I meant, commenting about the patches/additional sources where you actually
> declare them
Okay, I fixed this now, see:
http://wiki.open.hr/~zpintar/fe
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Orcan Ogetbil changed:
What|Removed |Added
Blocks|3 |4
--- Comment #92 from Orcan Ogetbil
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Zarko Pintar changed:
What|Removed |Added
Blocks||33
--- Comment #93 from Zarko Pintar
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Thorsten Leemhuis changed:
What|Removed |Added
Blocks|33 |
--- Comment #94 from Thorsten Le
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
Martin Strigl changed:
What|Removed |Added
CC||m...@friendlynet.at
--- Comment #95 f
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #96 from Dan Dennedy 2009-05-27 09:34:12 ---
Thank you for finding and reporting that stupid typo. I have fixed it upstream.
Zarko, I expect there will be a 0.4.2 version shortly.
--
Configure bugmail: http://bugzilla.rpmfusi
http://bugzilla.rpmfusion.org/show_bug.cgi?id=527
--- Comment #97 from Zarko Pintar (grof) 2009-05-27
09:37:37 ---
(In reply to comment #96)
> Thank you for finding and reporting that stupid typo. I have fixed it
> upstream.
>
> Zarko, I expect there will be a 0.4.2 version shortly.
>
1 - 100 of 105 matches
Mail list logo
