Bug 428568 - Review Request: synfig - Synfig is a vector based 2D animation package
Review Request: synfig - Synfig is a vector based 2D animation package
Status: CLOSED DUPLICATE of bug 531773
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On: 428567
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-13 09:18 EST by Marc Wiriadisastra
Modified: 2009-10-29 09:32 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-29 08:51:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gdb-session trying to know where does it crash (999 bytes, text/plain)
2008-12-26 09:06 EST, Muayyad Alsadi
no flags Details
backtrace (4.20 KB, text/plain)
2008-12-26 09:07 EST, Muayyad Alsadi
no flags Details
strace ouput while using synfig (252.74 KB, text/plain)
2009-02-04 04:51 EST, Nicolas Chauvet (kwizart)
no flags Details

  None (edit)
Description Marc Wiriadisastra 2008-01-13 09:18:32 EST
Spec URL: http://mwiriadi.fedorapeople.org/packages/synfig/synfig.spec
SRPM URL: http://mwiriadi.fedorapeople.org/packages/synfig/synfig-0.61.07-1.fc8.src.rpm
Description: It is designed to be capable of producing feature-film quality 
animation. It eliminates the need for tweening, preventing the 
need to hand-draw each frame. synfig features spatial and temporal 
resolution independence (sharp and smoothat any resolution or framerate),
 high dynamic range images, and a flexible plugin system.
Comment 1 Jason Tibbitts 2008-01-24 00:29:47 EST
Both links above seem to be 404 for me.
Comment 2 Marc Wiriadisastra 2008-01-24 00:39:06 EST
They are. I'll fix that shortly the reason was I was going to withdraw ETL but
it turned out that upstream has gotten involved.
Comment 3 Marc Wiriadisastra 2008-01-24 00:42:27 EST
Fixed
Comment 4 Nicolas Chauvet (kwizart) 2008-03-05 20:33:53 EST
synfig 0.61.08 is here

You don't need to requires pkgconfig from the main synfig package (only the
-devel one needs pkgconfig)
Same for ImageMagick unless it only uses the ImageMagick binaries.

You are probably missing libtool-ltdl-devel as BuildRrequires, but you cannot
install 
%{_libdir}/libltdl.a
%{_includedir}/ltdl.h
as theses files will conflict with libtool-ltdl-devel

That's uneeded for the -devel package
%post devel -p /sbin/ldconfig
%postun devel -p /sbin/ldconfig
(only elf libraries needed to run ldconfig after install so they can be found by
the programs using it).

Thoses file are needed in the main package:
%{_libdir}/synfig/*.so 
Usually they are in the form libfoo.so and are elf libraries dlopenable by the
libsynfig.so library. This is interesting as if some BR are missing for any
reason (as we cannot have it within the fedora repository) we can build synfig
with the missing BR that can be "dlopened" at runtime by libsynfig.so.
This architecture allow to add "module" functionalities.
On the other hand, if they have the form libfoo.so.0.0.0, then maybe it would be
better to fix this with -avoid-version on the related LDFLAGS.

I cannot go further as the rebuild fails on: (tested on F-9 Rawhide x86_64)
 blur.cpp:134: error: explicit template specialization cannot have a storage class
Comment 5 Marc Wiriadisastra 2008-03-06 06:06:02 EST
http://mwiriadi.fedorapeople.org/packages/synfig/synfig-0.61.08-1.fc9.src.rpm
http://mwiriadi.fedorapeople.org/packages/synfig/synfig.spec

A lot of the issues are fixed. I'm still getting errors from rpmlint due to the
shifting of the *so file
Comment 7 Nicolas Chauvet (kwizart) 2008-03-06 07:22:34 EST
1* URL: please rip off /Main_Page from the url in the case they change the name,
http://synfig.org/ should be enough.

2* BuildRequires - it is usually better to use one line by requirement, so the
BR would be versioned and changes can be seen easily via our cvs. But I leave
this up to you.

3* Remove: Requires:       pkgconfig, ImageMagick

4* %description : Remove the added space from the beginning of the line:
 high dynamic range images, and a flexible plugin system.

5* %package devel
 - BuildRequires is a wrong item from a -devel package, you should only use
Requires:
 - pkgconfig is already provided by ETL-devel, no need to add it twice
 - synfig.pc has Requires:  OpenEXR ETL libxml++-2.6 sigc++-2.0
 you have to add all theses requires using the package name form.
 - Requires:       synfig and %{name} = %{version}-%{release} are the same
requirement, please remove synfig and use %{name} = %{version}-%{release}
(versionned requires), instead.

6* Prevent timestramps changes for installed headers. Use:
 make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"

7* Again, please remove theses lines: (unneeded)
%post devel -p /sbin/ldconfig
%postun devel -p /sbin/ldconfig

8* %doc README doc/ - Theses doc are installed twice (in main and -devel)
if the documentation is big, you may need to split into a separate package.
It also depend if this is development related doc or user doc.

9* Do we really need this file ? ltdl should take care of the available module
%config(noreplace) %{_sysconfdir}/synfig_modules.cfg
can you see where the file (and it's path) is written within the source code ?
At least I don't expect this file is aimed for user edition, so you may need to
only use %config in this case.

10* %{_bindir}/synfig-config same tweak is required from the ETL-config
you will need to keep the timestramps from a reference file using something like
touch -r README $RPM_BUILD_ROOT%{_bindir}/synfig-config (same for ETL-config )

11* mod_imagemagick, mod_magickpp, mod_mng and mod_gradient seems not to have
been built. (mod_libavcodec is expected). you need to figure out why.

vImage ---------------------------> no
ImageMagick ----------------------> no
Magick++ -------------------------> no
...
Using OpenEXR's "half" type ------> no

Look at the config.log to see missing BR or wrong directory search paths for
library detection.

Comment 8 Paul Wise (Debian) 2008-03-06 07:43:59 EST
mod_imagemagick needs ./configure --with-imagemagick or /usr/bin/convert to be
present at build time.

mod_magickpp needs libmagick++ headers to be installed at build time

mod_mng needs libmng headers to be installed at build time

mod_gradient should be always built

mod_libavcodec needs ./configure --with-libavcodec
Comment 9 Marc Wiriadisastra 2008-03-06 09:02:34 EST
(In reply to comment #7)
> 1* URL: please rip off /Main_Page from the url in the case they change the name,
> http://synfig.org/ should be enough.
> 

Done

> 2* BuildRequires - it is usually better to use one line by requirement, so the
> BR would be versioned and changes can be seen easily via our cvs. But I leave
> this up to you.

Done

> 
> 3* Remove: Requires:       pkgconfig, ImageMagick

Done

> 
> 4* %description : Remove the added space from the beginning of the line:
>  high dynamic range images, and a flexible plugin system.

Done

> 
> 5* %package devel
>  - BuildRequires is a wrong item from a -devel package, you should only use
> Requires:
>  - pkgconfig is already provided by ETL-devel, no need to add it twice
>  - synfig.pc has Requires:  OpenEXR ETL libxml++-2.6 sigc++-2.0
>  you have to add all theses requires using the package name form.
>  - Requires:       synfig and %{name} = %{version}-%{release} are the same
> requirement, please remove synfig and use %{name} = %{version}-%{release}
> (versionned requires), instead.

Done

> 
> 6* Prevent timestramps changes for installed headers. Use:
>  make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"

Done

> 
> 7* Again, please remove theses lines: (unneeded)
> %post devel -p /sbin/ldconfig
> %postun devel -p /sbin/ldconfig

Done

> 
> 8* %doc README doc/ - Theses doc are installed twice (in main and -devel)
> if the documentation is big, you may need to split into a separate package.
> It also depend if this is development related doc or user doc.

development and shifted there

> 
> 9* Do we really need this file ? ltdl should take care of the available module
> %config(noreplace) %{_sysconfdir}/synfig_modules.cfg
> can you see where the file (and it's path) is written within the source code ?
> At least I don't expect this file is aimed for user edition, so you may need to
> only use %config in this case.

Needed and left as is with the theory that if someone has modified it I should
not overwrite it.  It will cause less breakage this way I think in the long run.

> 
> 10* %{_bindir}/synfig-config same tweak is required from the ETL-config
> you will need to keep the timestramps from a reference file using something like
> touch -r README $RPM_BUILD_ROOT%{_bindir}/synfig-config (same for ETL-config )
> 

Done 

> 11* mod_imagemagick, mod_magickpp, mod_mng and mod_gradient seems not to have
> been built. (mod_libavcodec is expected). you need to figure out why.
> 
> vImage ---------------------------> no
> ImageMagick ----------------------> no
> Magick++ -------------------------> no
> ...
> Using OpenEXR's "half" type ------> no
> 
> Look at the config.log to see missing BR or wrong directory search paths for
> library detection.

vImage = propietary, ImageMagick and Magick++ yes OpenEXR half slows down synfig
upstream has requested we leave it as is.

http://mwiriadi.fedorapeople.org/packages/synfig/synfig.spec
http://mwiriadi.fedorapeople.org/packages/synfig/synfig-0.61.08-3.fc9.src.rpm
Comment 12 Lorenzo Villani 2008-08-25 11:00:19 EDT
Any progress with this review? I can take it, if it's ok for you.
Comment 13 Marc Wiriadisastra 2008-08-26 06:25:47 EDT
Take it over if you want
Comment 14 Paul Wise (Debian) 2008-09-02 00:24:54 EDT
We plan to make a release of 0.61.09 at the start of October:

http://synfig.org/forums/viewtopic.php?t=204

If Fedora needs to add any changes to make synfig acceptable, NOW is the time to do so. We also welcome you on IRC:

http://synfig.org/Contact
Comment 15 Paul Wise (Debian) 2008-10-23 01:20:34 EDT
New version released, please update. If there are any patches you need, please send them our way.
Comment 16 Muayyad Alsadi 2008-12-26 09:06:40 EST
Created attachment 327854 [details]
gdb-session trying to know where does it crash
Comment 17 Muayyad Alsadi 2008-12-26 09:07:42 EST
Created attachment 327855 [details]
backtrace
Comment 18 Muayyad Alsadi 2008-12-26 09:11:40 EST
I have a problem with it in i386 (some people in IRC told be they don't have it in 64)

the problem goes like this

it render the .sif file successfully (any .sif file .eg for the examples)
and after it finish it SIGFAULT
and that happens even after leaving } of main

I attached a gdb session and gdb backtrace

the problem seems to be while calling the destructor of some class here or there or in gnu c libs
 
#0  0x02081504 in fini_context_translations () at setrans_client.c:217
Comment 19 Muayyad Alsadi 2008-12-26 09:13:00 EST
BTW: there are .src.rpm in http://zelgadis.profusehost.net/files/rpms/SRPMS/
Comment 20 Lubomir Rintel 2009-01-10 12:27:46 EST
New upstream release (stepping in since the original submitter seems unresponsive):

SPEC: http://v3.sk/~lkundrak/SPECS/synfig.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/synfig-0.61.09-1.el5.src.rpm
Comment 21 Lorenzo Villani 2009-01-16 13:04:35 EST
I suggest to add Require: libxml++-devel to synfig-devel subpackage, otherwise synfigstudio won't build (pkg-config fails in mockroot due to missing libxml++-devel)
Comment 22 Lubomir Rintel 2009-01-30 02:54:29 EST
(In reply to comment #21)
> I suggest to add Require: libxml++-devel to synfig-devel subpackage, otherwise
> synfigstudio won't build (pkg-config fails in mockroot due to missing
> libxml++-devel)

That's odd -- it worked for me, in rhel-5. But thanks for the suggestion, I'll add this in the next spin of the package, which is after I get a full review.
Comment 23 Nicolas Chauvet (kwizart) 2009-02-03 15:47:24 EST
this package defines rpath on x86_64 Fedora 10 system :
------------------
ERROR   0001: file '/usr/lib64/synfig/modules/libmod_gradient.so' contains a 
...
ERROR   0001: file '/usr/lib64/synfig/modules/libmod_ppm.so' contains a standard rpath '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/lib64/synfig/modules/liblyr_freetype.so' contains a standard rpath '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/synfig' contains a standard rpath '/usr/lib64' in [/usr/lib64]
------------------
This is because of the generated configure script. This can be avoided with autoreconf -f -i or patching the internal libtool between configure and make with:
---------------
# remove rpath from libtool
sed -i.rpath 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i.rpath 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
---------------
Comment 24 Nicolas Chauvet (kwizart) 2009-02-03 16:30:03 EST
while compiling synfigstudio, it failed at this step:
synfig -q synfig_icon.sif -o 128x128/synfig_icon.png --time 0 -w 128 -h 128
synfig(10044) [22:26:57] info: target name not specified - using png
Segmentation error

It seems that synfig failed at runtime for some reasons.
Comment 25 Muayyad Alsadi 2009-02-03 17:21:20 EST
same problem, please see my traceback
the files are rendered perfectly but the segfault happens while unloading things or something like that

I stepped in the program line by line, and it reached the end } of main without any problem

selinux was disabled on my machine but I got it in the backtrace
Comment 26 Lubomir Rintel 2009-02-04 02:12:49 EST
(In reply to comment #23)
> this package defines rpath on x86_64 Fedora 10 system :

Fixed. Thanks!

(I, in fact, did not test functionality, but I assume removing a standard path from RPATH doesn't have any impact)

(In reply to comment #24)
> while compiling synfigstudio, it failed at this step:
> synfig -q synfig_icon.sif -o 128x128/synfig_icon.png --time 0 -w 128 -h 128
> synfig(10044) [22:26:57] info: target name not specified - using png
> Segmentation error
> 
> It seems that synfig failed at runtime for some reasons.

(In reply to comment #25)
> same problem, please see my traceback

Works for me (el5, but I think I successfully built it in fedora-devel-i386 mock buildroot before).

I'm wondering if mod_avcodec built for you for some reason (ffmpeg-devel installed?). Could you please attach a strace of failing synfig? Get it with:

"strace -o trace.txt -f synfig -q synfig_icon.sif -o 128x128/synfig_icon.png --time 0 -w 128 -h 128"

Thanks!

New package (addresses just the rpath issue):

SPEC: http://v3.sk/~lkundrak/SPECS/synfig.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/synfig-0.61.09-2.el5.src.rpm
Comment 27 Lubomir Rintel 2009-02-04 02:16:07 EST
(In reply to comment #26)
> New package (addresses just the rpath issue):

Not quite true. Fixes Lorenzo's issue as well.
Comment 28 Nicolas Chauvet (kwizart) 2009-02-04 04:51:10 EST
Created attachment 330847 [details]
strace ouput while using synfig

There is few things that I feel as very annoying for 
* First there is the synfig_module.cfg needs:
usually libtool-ltdl modules doesn't need to be hardcoded in such file. That will be hard to extend the functionnalities of synfig if we need to register every module using this. 
* Then, it seems that the modules implementation settle on the needs of the libtool .la files. This is very annoying and needs to be fixed.
Comment 29 Lubomir Rintel 2009-02-05 12:45:55 EST
(In reply to comment #28)
> Created an attachment (id=330847) [details]
> strace ouput while using synfig
> 
> There is few things that I feel as very annoying for 
> * First there is the synfig_module.cfg needs:
> usually libtool-ltdl modules doesn't need to be hardcoded in such file. That
> will be hard to extend the functionnalities of synfig if we need to register
> every module using this. 
> * Then, it seems that the modules implementation settle on the needs of the
> libtool .la files. This is very annoying and needs to be fixed.

Nicolas, could you concentrate on reviewing the package, not the upstream product? Both of these are issues that are indeed worth looking into, but they only the second one seems to be related to packaging to some extent.

I'd like to get this in first and then help upstream solving the issues with their product. See, there's little point in insisting the product is perfect when entering fedora and I doubt whether we'd have any packages at all if we did this for all packages ;)

Thanks for pointing at the issues though, I'll try to follow up on them shortly, but please don't let it block you from doing a full review :o)
Comment 30 Nicolas Chauvet (kwizart) 2009-02-05 13:06:52 EST
well, okay the spec file itself it beautiful.
But in when I'm reviewing a package, then i consider the software as a whole.
(guidelines includes usability tests after all).

Now I've never said that the first issue was a blocker nor that the above remarks constitutes a full review, indeed.

Actually I still need a usability test for ETL at this time...
I will assume it is ok.
Comment 31 Nicolas Chauvet (kwizart) 2009-02-26 12:10:38 EST
any news ?
Comment 32 Kamil Pawlowski 2009-03-03 09:14:20 EST
in synfig.spec:

sed -i.rpath 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' '\n' libtool

should be:

sed -i.rpath 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool

because sed return error
Comment 33 Kamil Pawlowski 2009-03-03 09:27:22 EST
I have the same problem if I try build synfig from spec or by source, this problem stop me from building synfigstudio.

$ gdb synfig
(...)
warning: "/usr/lib/debug/usr/bin/synfig.debug": The separate debug info file has no debug info
(no debugging symbols found)
(no debugging symbols found)
(gdb) r synfig -q synfig_icon.sif -o 128x128/synfig_icon.png --time 0 -w 128 -h 128
Starting program: /usr/bin/synfig synfig -q synfig_icon.sif -o 128x128/synfig_icon.png --time 0 -w 128 -h 128
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff7fcf700 (LWP 3843)]
warning: "/usr/lib/debug/usr/lib64/synfig/modules/libmod_gif.so.debug": The separate debug info file has no debug info
(...) 
 and all other modules give same error too
(...)
I/O warning : failed to load external entity "synfig"
synfig(3843) [15:21:09] error: Standard Exception: Couldn't create parsing context
Unable to open synfig.
Throwing out job...
synfig(3843) [15:21:10] info: target name not specified - using png

Program received signal SIGSEGV, Segmentation fault.

ofcourse i have synfig-debug installed
Comment 34 Lubomir Rintel 2009-03-19 06:46:34 EDT
A few comments and a new package:

1.) Please, no more backtraces of crashes. (Thanks for them though.) I am aware of the problem.

Unfortunately, I can't reproduce it and suspect it's x86_64 specific. I can't do much about it unless I gain access to x86_64, or will be able to do scratch builds against synfig.

I promise I'll deal with the problem once the package is approved, so that synfigstudio (bug #479527) builds. According to review guidelines [1] this is not a review blocker:

MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.
[1] http://fedoraproject.org/wiki/Packaging/ReviewGuidelines

2.) synfig_module.cfg
(In reply to comment #28)
> * First there is the synfig_module.cfg needs:
> usually libtool-ltdl modules doesn't need to be hardcoded in such file. That
> will be hard to extend the functionnalities of synfig if we need to register
> every module using this.

I'm not doing anything about this now. synfig_module.cfg is quite easily machine-modifiable, the same way as shell(5) or maybe even grub.cfg.

It could be argued that it's useless and that synfig should dlopen all dsos from a directory, but on the other hand synfig_module.cfg gives the opportunity to disable modules w/o deleting them. I'm not going to deviate from upstream here, especially in a case like these, where it would remove (probably not much used) functionality.

3.) libtool
(In reply to comment #28)
> * Then, it seems that the modules implementation settle on the needs of the
> libtool .la files. This is very annoying and needs to be fixed.  

That's a design decision. Libtool is useful here, and I highly doubt you'll convince upstream not to use it. All I can do here is include the .la files in -devel to allow external modules, though it would probably violate the guidelines.

--

Nicolas, if I understand your concerns -- are you planning to package a module separately? Are there any external modules? (or you're planning to build mod_libavcodec?).

(In reply to comment #30)
> But in when I'm reviewing a package, then i consider the software as a whole.
> (guidelines includes usability tests after all).

Usability or external linkability? Seriously, while there are minor concerns about adding external modules, the package works well (apart from the x86_64 crash issue) for its intended purpose.

> Now I've never said that the first issue was a blocker nor that the above
> remarks constitutes a full review, indeed.

May I humbly request a full review then? This has been open for some time now, and I'd be very glad if it could have some productive outcome.

--

(In reply to comment #33)
> warning: "/usr/lib/debug/usr/bin/synfig.debug": The separate debug info file
> has no debug info

The new package fixes the use of optflags, so that debugging symbols are generated correctly.

SPEC: http://v3.sk/~lkundrak/SPECS/synfig.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/synfig-0.61.09-3.fc11.src.rpm
Comment 35 Nicolas Chauvet (kwizart) 2009-03-19 07:59:33 EDT
I'm not going to approve this package in this current shape as the comments I've made aren't even planned to be assigned upstream.
Comment 36 Muayyad Alsadi 2009-03-19 14:34:44 EDT
> 1.) Please, no more backtraces of crashes. (Thanks for them though.) I am aware
of the problem.
> Unfortunately, I can't reproduce it and suspect it's x86_64 specific.
mine are on i386

check my tracebacks then because I got them in i386
Comment 37 Kamil Pawlowski 2009-03-19 15:14:22 EDT
Yes, this is x86_64 specific problem, now I use i386 compiled packages on my x86_64 machine and is ok.
Comment 38 Jason Tibbitts 2009-06-23 14:17:21 EDT
Is anything happening with this package?  Any progress on fixing the issues?
Comment 39 Jason Tibbitts 2009-07-01 19:37:12 EDT
No response to the last ping and no progress in many months; closing.
Comment 40 Konstantin Dmitryev 2009-07-06 02:25:51 EDT
(In reply to comment #24)
> while compiling synfigstudio, it failed at this step:
> synfig -q synfig_icon.sif -o 128x128/synfig_icon.png --time 0 -w 128 -h 128
> synfig(10044) [22:26:57] info: target name not specified - using png
> Segmentation error
> 
> It seems that synfig failed at runtime for some reasons.  

That's because synfig is not compatible with latest ffmpeg. Use "--without-libavcodec" option when doing "./configure" for synfig as workaround.
Comment 41 Lubomir Rintel 2009-07-07 05:46:32 EDT
(In reply to comment #38)
> Is anything happening with this package?  Any progress on fixing the issues?  

Are there any outstanding and known issues (guideline violations)?
I was under impression this is just waiting for a reviewer (sorry for not answering the ping).
Comment 42 Lubomir Rintel 2009-07-07 05:46:58 EDT
(In reply to comment #38)
> Is anything happening with this package?  Any progress on fixing the issues?  

Are there any outstanding and known issues (guideline violations)?
I was under impression this is just waiting for a reviewer (sorry for not answering the ping).
Comment 43 Jason Tibbitts 2009-07-07 11:52:17 EDT
Failure of the submitter (Marc Wiriadisastra) to respond to a ping is sufficient reason for this to be closed.  If you (Lubomir) are now submitting this package, you should have opened your own review ticket.

Anyway, isn't the "doesn't work on x86_64 at all" issue sufficiently known?  Ahat about comment #36?  Is that problem fixed as well?
Comment 44 Konstantin Dmitriev 2009-07-08 11:16:09 EDT
> Anyway, isn't the "doesn't work on x86_64 at all" issue sufficiently known? 
Issue "doesn't work on x86_64 at all" is not true. We're using both i386 and x86_64 synfig versions in production. As I have said, in #40 synfig (core) crashes only if built with libavcodec. IIRC, official Fedora repos are not shipping ffmpeg/libavcodec stuff.

Please, state clearly which issues should be fixed upstream.
Comment 45 Konstantin Dmitriev 2009-07-08 11:24:34 EDT
Forgot to mention that we are using synfig/synfigstudio on Fedora 10. ^__^
Comment 46 Julian Aloofi 2009-07-30 14:37:04 EDT
Just some short comments:
I rebuilt the SRPM with mock for fedora-11-i386 and then installed synfig from the output RPM. There is no desktop file. In addition, running synfig from the command line doesn't do anything, except of telling me that I should check out all options using --help.

Is this supposed to be?
Comment 47 Konstantin Dmitriev 2009-07-31 00:01:53 EDT
(In reply to comment #46)
> Is this supposed to be? 

Yes, because "synfig" package is a console tool and core libraries for rendering.
For GUI take a look to "synfigstudio" package - https://bugzilla.redhat.com/show_bug.cgi?id=479527.
Comment 48 Julian Aloofi 2009-07-31 06:29:55 EDT
(In reply to comment #47)
> (In reply to comment #46)
> > Is this supposed to be? 
> 
> Yes, because "synfig" package is a console tool and core libraries for
> rendering.
> For GUI take a look to "synfigstudio" package -
> https://bugzilla.redhat.com/show_bug.cgi?id=479527.  

Ahh, OK, alright then.
Comment 49 Thomas Spura 2009-10-29 08:51:08 EDT
(In reply to comment #43)
> Failure of the submitter (Marc Wiriadisastra) to respond to a ping is
> sufficient reason for this to be closed.  If you (Lubomir) are now submitting
> this package, you should have opened your own review ticket.

Lubomir, this was the next ping, you are missing ;)

Please, close this as a dublicate to your own review request.

Without, this is a 'CANTFIX'.
Comment 50 Lubomir Rintel 2009-10-29 09:27:50 EDT
bug #531773
Comment 51 Susi Lehtola 2009-10-29 09:32:04 EDT

*** This bug has been marked as a duplicate of bug 531773 ***

Note You need to log in before you can comment on or make changes to this bug.