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.
Both links above seem to be 404 for me.
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.
Fixed
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
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
http://mwiriadi.fedorapeople.org/packages/synfig/synfig.spec http://mwiriadi.fedorapeople.org/packages/synfig/synfig-0.61.08-2.fc9.src.rpm Done.
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.
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
(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
http://mwiriadi.fedorapeople.org/packages/synfig/synfig.spec http://mwiriadi.fedorapeople.org/packages/synfig/synfig-0.61.08-4.fc9.src.rpm
http://mwiriadi.fedorapeople.org/packages/synfig/synfig-0.61.08-5.fc9.src.rpm http://mwiriadi.fedorapeople.org/packages/synfig/synfig.spec
Any progress with this review? I can take it, if it's ok for you.
Take it over if you want
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
New version released, please update. If there are any patches you need, please send them our way.
Created attachment 327854 [details] gdb-session trying to know where does it crash
Created attachment 327855 [details] backtrace
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
BTW: there are .src.rpm in http://zelgadis.profusehost.net/files/rpms/SRPMS/
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
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)
(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.
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 ---------------
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.
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
(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
(In reply to comment #26) > New package (addresses just the rpath issue): Not quite true. Fixes Lorenzo's issue as well.
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.
(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)
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.
any news ?
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
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
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
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.
> 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
Yes, this is x86_64 specific problem, now I use i386 compiled packages on my x86_64 machine and is ok.
Is anything happening with this package? Any progress on fixing the issues?
No response to the last ping and no progress in many months; closing.
(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.
(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).
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?
> 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.
Forgot to mention that we are using synfig/synfigstudio on Fedora 10. ^__^
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?
(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.
(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.
(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'.
bug #531773
*** This bug has been marked as a duplicate of bug 531773 ***