Spec Name or Url: http://laurence.bernard.pagesperso-orange.fr/eric/scidavis.spec SRPM Name or Url: http://laurence.bernard.pagesperso-orange.fr/eric/scidavis-0.1.2-1.fc8.src.rpm Description: SciDAVis is a user-friendly data analysis and visualization program primarily aimed at high-quality plotting of scientific data. It strives to combine an intuitive, easy-to-use graphical user interface with powerful features such as Python scriptability.
$ rpmlint scidavis-0.1.2-1.fc8.src.rpm nothing $ rpmlint scidavis-manual-0.1.2-1.fc8.i386.rpm nothing $ rpmlint scidavis-debuginfo-0.1.2-1.fc8.i386.rpm nothing $ rpmlint scidavis-0.1.2-1.fc8.i386.rpm scidavis.i386: W: non-conffile-in-etc /etc/scidavisrc.pyc scidavis.i386: W: non-conffile-in-etc /etc/scidavisrc.pyo scidavis.i386: W: non-conffile-in-etc /etc/scidavisrc.py From upstream "The reason why scidavisrc.py is in /etc is that we consider it to be a configuration file (and, to the best of my knowledge, /etc is the standard location for system-wide config files). Like many other config files, it can be overridden on a per-user basis by creating a file ~/.scidavisrc.py. Maybe scidavisrc.pyo and scidavisrc.pyc are not exactly config files; but then again, files like /etc/modprobe.conf and /etc/mtab are also auto-generated."
rpm -i scidavis-0.1.2-1.fc8.src.rpm warning: user tanguy-e does not exist - using root warning: group tanguy-e does not exist - using root warning: user tanguy-e does not exist - using root warning: group tanguy-e does not exist - using root warning: user tanguy-e does not exist - using root warning: group tanguy-e does not exist - using root error: unpacking of archive failed on file /home/nbecker/RPM/SOURCES/scidavis-0.1.2_translations_2008-02-03.tar.bz2;47c455cb: cpio: read
Could you retry to download it ? It seems the package on the website was bad. It's now solved.
1.) URLs from download from sourceforge Please use "http://download.sourceforge.net/sourceforge/..." instead of a specific mirror. Source0: http://dfn.dl.sourceforge.net/sourceforge/scidavis/%{name}-%{version}.tar.bz2 Source1: http://dfn.dl.sourceforge.net/sourceforge/scidavis/scidavis-0.1.2_translations_2008-02-03.tar.bz2 Source2: http://dfn.dl.sourceforge.net/sourceforge/scidavis/scidavis-manual-0.1_2008-02-28.tar.bz2 2.) Try to specify an URL for these: Source5: application-x-scidavis.svg Source6: application-x-scidavis-32x32.png Source7: application-x-scidavis-48x48.png Source8: application-x-scidavis-128x128.png Or at least a comment where did you get those. Is it needed to include the pngs? 3.) Correct the names of the patches: Patch0: scidavis-translations.patch Patch1: scidavis-pro.patch Patch2: scidavis-manual.patch name-version-what.patch; where version is the version you generated those against 4.) Is this needed? %package manual ... Requires: %{name} Why does manual depend on the package? 5.) X-Fedora category is deprecated, no? --add-category X-Fedora \ 6.) Does this work? Source1: http://dfn.dl.sourceforge.net/sourceforge/scidavis/scidavis-0.1.2_translations_2008-02-03.tar.bz2 .. tar -xf %{SOURCE1} -C %{buildroot}%{_datadir}/%{name}/ Is source1 really a bzipped tarball? Why don't you unpack it with -j? 7.) Handle documentation properly. Don't do this. Use %doc in %files. install -d %{buildroot}%{_datadir}/doc/%{name}-%{version}/ tar -xf %{SOURCE2} -C %{buildroot}%{_datadir}/doc/%{name}-%{version}/ install -pm 644 CHANGES %{buildroot}%{_datadir}/doc/%{name}-%{version}/ install -pm 644 README %{buildroot}%{_datadir}/doc/%{name}-%{version}/ install -pm 644 gpl.txt %{buildroot}%{_datadir}/doc/%{name}-%{version}/ It also needs some more work in %files regarding files in %doc 8.) Don't these overlap? %{_libdir}/scidavis/ %{_libdir}/scidavis/plugins/* and %{_datadir}/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg %{_datadir}/icons/hicolor/*/mimetypes/application-x-scidavis* I will continue the review once you address these. Thanks!
(In reply to comment #4) For the moment i just update the spec file not the src.rpm file because i have some more question regarding your comments > 1.) URLs from download from sourceforge > > Please use "http://download.sourceforge.net/sourceforge/..." instead of a > specific mirror. > > Source0: > http://dfn.dl.sourceforge.net/sourceforge/scidavis/%{name}-%{version}.tar.bz2 > Source1: > http://dfn.dl.sourceforge.net/sourceforge/scidavis/scidavis-0.1.2_translations_2008-02-03.tar.bz2 > Source2: > http://dfn.dl.sourceforge.net/sourceforge/scidavis/scidavis-manual-0.1_2008-02-28.tar.bz2 > Ok > 2.) Try to specify an URL for these: > > Source5: application-x-scidavis.svg > Source6: application-x-scidavis-32x32.png > Source7: application-x-scidavis-48x48.png > Source8: application-x-scidavis-128x128.png > > Or at least a comment where did you get those. > Is it needed to include the pngs? > They come from the svn version. I had some exchange with upstream about how to handle desktop and mime and this will be incuded in the next version. > 3.) Correct the names of the patches: > > Patch0: scidavis-translations.patch > Patch1: scidavis-pro.patch > Patch2: scidavis-manual.patch > > name-version-what.patch; where version is the version you generated those against Ok > > 4.) Is this needed? > > %package manual > ... > Requires: %{name} > > Why does manual depend on the package? You are right. Deleted. > > 5.) X-Fedora category is deprecated, no? > > --add-category X-Fedora \ > > 6.) Does this work? > > Source1: > http://dfn.dl.sourceforge.net/sourceforge/scidavis/scidavis-0.1.2_translations_2008-02-03.tar.bz2 > .. > tar -xf %{SOURCE1} -C %{buildroot}%{_datadir}/%{name}/ > > Is source1 really a bzipped tarball? Why don't you unpack it with -j? > Yes this works but i added the -j > > 7.) Handle documentation properly. > > Don't do this. Use %doc in %files. > > install -d %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > tar -xf %{SOURCE2} -C %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > install -pm 644 CHANGES %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > install -pm 644 README %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > install -pm 644 gpl.txt %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > > It also needs some more work in %files regarding files in %doc This was my biggest problem and i suspect this is because i don't do the thing correctly. When i put : %files %defattr(-,root,root,-) %doc CHANGES README gpl.txt ... i don't know how to handle the tar.bz2 manual in %files manual So here i need some help > > 8.) Don't these overlap? > > %{_libdir}/scidavis/ > %{_libdir}/scidavis/plugins/* > > and > > %{_datadir}/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg > %{_datadir}/icons/hicolor/*/mimetypes/application-x-scidavis* > > You are right! > I will continue the review once you address these. > > Thanks!
(In reply to comment #5) > (In reply to comment #4) > > 1.) URLs from download from sourceforge > Ok Thanks, the changes are fine. > > 2.) Try to specify an URL for these: > > > > Source5: application-x-scidavis.svg > > Source6: application-x-scidavis-32x32.png > > Source7: application-x-scidavis-48x48.png > > Source8: application-x-scidavis-128x128.png > > > > Or at least a comment where did you get those. > > Is it needed to include the pngs? > > > > They come from the svn version. I had some exchange with upstream about how to > handle desktop and mime and this will be incuded in the next version. This still doesn't seem correct to me. Is this the file? http://scidavis.svn.sourceforge.net/viewvc/*checkout*/scidavis/trunk/icons/scidavis-icon.svg?revision=709 If yes, please either specify it in Source: and rename when installing it, or at least put a comment above it. And the pngs -- are they needed? When it comes to icons; SVG is generally sufficient. > > 3.) Correct the names of the patches: > Ok Thanks. > > 4.) Is this needed? > > Why does manual depend on the package? > > You are right. Deleted. Thanks. > > 5.) X-Fedora category is deprecated, no? > > > > --add-category X-Fedora \ I see it vanished; thanks. > > 6.) Does this work? > > Is source1 really a bzipped tarball? Why don't you unpack it with -j? > > Yes this works but i added the -j Wow, I would never say it would; if not on FreeBSD with libarchive :o) > > 7.) Handle documentation properly. > > > > Don't do this. Use %doc in %files. > > > > install -d %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > > tar -xf %{SOURCE2} -C %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > > install -pm 644 CHANGES %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > > install -pm 644 README %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > > install -pm 644 gpl.txt %{buildroot}%{_datadir}/doc/%{name}-%{version}/ > > > > It also needs some more work in %files regarding files in %doc > > > This was my biggest problem and i suspect this is because i don't do the thing > correctly. > When i put : > %files > %defattr(-,root,root,-) > %doc CHANGES README gpl.txt > ... > > i don't know how to handle the tar.bz2 manual in %files manual > > So here i need some help How about untarring it in %prep after %setup of Source0? Either just untar it to directory where you are after it, or make some constructive use of %setup macro. It can take a variety of useful, yet somewhat tricky options: see [1]. [1] http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html > > 8.) Don't these overlap? > You are right! Ok. Thanks for your improvements to the spec file, I'll continue the review once doc files are properly dealt with. Feel free to ask for help if you need any.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > 1.) URLs from download from sourceforge > > Ok > > Thanks, the changes are fine. > > > > 2.) Try to specify an URL for these: > > > > > > Source5: application-x-scidavis.svg > > > Source6: application-x-scidavis-32x32.png > > > Source7: application-x-scidavis-48x48.png > > > Source8: application-x-scidavis-128x128.png > > > > > > Or at least a comment where did you get those. > > > Is it needed to include the pngs? > > > > > > > They come from the svn version. I had some exchange with upstream about how to > > handle desktop and mime and this will be incuded in the next version. > > This still doesn't seem correct to me. Is this the file? > http://scidavis.svn.sourceforge.net/viewvc/*checkout*/scidavis/trunk/icons/scidavis-icon.svg?revision=709 > > If yes, please either specify it in Source: and rename when installing it, or at > least put a comment above it. > > And the pngs -- are they needed? When it comes to icons; SVG is generally > sufficient. The files are from http://scidavis.svn.sourceforge.net/viewvc/scidavis/branches/current_stable/scidavis/icons/ and it seems that the svg file is not sufficient > > How about untarring it in %prep after %setup of Source0? > Either just untar it to directory where you are after it, or make some > constructive use of %setup macro. It can take a variety of useful, yet somewhat > tricky options: see [1]. > > [1] http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html It seems now doc are better handled but i have a problem : the scidavis-manual package have the doc in /usr/share/doc/scidavis-manual-0.1.2/ but the scidavis binary file will look for manual in /usr/share/doc/scidavis-0.1.2/manual/ is it possible to do this ? > Thanks for your improvements to the spec file, I'll continue the review once doc > files are properly dealt with. Feel free to ask for help if you need any. Thanks
Up
> > > > 2.) Try to specify an URL for these: > > > > > > > > Source5: application-x-scidavis.svg > > > > Source6: application-x-scidavis-32x32.png > > > > Source7: application-x-scidavis-48x48.png > > > > Source8: application-x-scidavis-128x128.png > > > > > > > > Or at least a comment where did you get those. > > > > Is it needed to include the pngs? > > > > > > > > > > They come from the svn version. I had some exchange with upstream about how to > > > handle desktop and mime and this will be incuded in the next version. > > > > This still doesn't seem correct to me. Is this the file? > > > http://scidavis.svn.sourceforge.net/viewvc/*checkout*/scidavis/trunk/icons/scidavis-icon.svg?revision=709 > > > > If yes, please either specify it in Source: and rename when installing it, or at > > least put a comment above it. > > > > And the pngs -- are they needed? When it comes to icons; SVG is generally > > sufficient. > > The files are from > http://scidavis.svn.sourceforge.net/viewvc/scidavis/branches/current_stable/scidavis/icons/ > and it seems that the svg file is not sufficient http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup SVG should be sufficient. Can you please describe in details how didn't it work for you? > > How about untarring it in %prep after %setup of Source0? > > Either just untar it to directory where you are after it, or make some > > constructive use of %setup macro. It can take a variety of useful, yet somewhat > > tricky options: see [1]. > > > > [1] http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html > > It seems now doc are better handled but i have a problem : the scidavis-manual > package have the doc in /usr/share/doc/scidavis-manual-0.1.2/ but the scidavis > binary file will look for manual in /usr/share/doc/scidavis-0.1.2/manual/ > > is it possible to do this ? If the binary looks for manual, you can safely install the manual in /usr/share/doc/scidavis-0.1.2/manual/, while nor being marked %doc. Another solution would be to patch the program.
(In reply to comment #9) http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup > > SVG should be sufficient. Can you please describe in details how didn't it work > for you? If i only install the svg icon. The icon used is very small and not readable comparing with the 48x48 one used when it is present. > > If the binary looks for manual, you can safely install the manual in > /usr/share/doc/scidavis-0.1.2/manual/, while nor being marked %doc. > > Another solution would be to patch the program. Maybe i could let it like this because when you try to see the manual for the first time from the gui you can select the good rep if the rep is not find automatically. The next version will have the possibility to change the default doc location at the compilation time.
> If i only install the svg icon. The icon used is very small and not readable That's a bug in the DE you're using. That said, it is still a very good idea for packages to provide at least one bitmap icon (say at 48x48).
I'm using standard gnome fedora installation ... But i think also it's good to provide also some bitmap icons.
Is it possible to finish this review to include the package in the F9 release ?
Okay, rest of the review. I am horribly sorry for the delay: 1.) Desktop file $ desktop-file-validate /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop: warning: boolean key "Terminal" in group "Desktop Entry" has value "0", which is deprecated: boolean values should be "false" or "true" /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop: error: value "application/x-scidavis" for string list key "MimeType" in group "Desktop Entry" does not have a semicolon (';') as trailing character $ * Desktop file: the Categories tag should not contain X-Fedora any more (wiki: Packaging/Guidelines#desktop) 2.) Duplicate files warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1 warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0 warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0.0 warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1 warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0 warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0.0 warning: File listed twice: /usr/share/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg 3.) SPEC file formatting scidavis.src: W: mixed-use-of-spaces-and-tabs (spaces: line 92, tab: line 1) 4.) Just rm or %exclude .pyc and .pyo (unless they are needed) rpmlint of scidavis: scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyc scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyo scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.py 5.) Dependencies * As scidavis ships icons in the hicolor directory, it should have "Requires: hicolor-icon-theme" Most of these are fairly trivial; 5. and 4. are probably most important.
I update srpm and spec file without changing the release number. (In reply to comment #14) > Okay, rest of the review. I am horribly sorry for the delay: > > 1.) Desktop file > > $ desktop-file-validate /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop > /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop: warning: key "Encoding" in > group "Desktop Entry" is deprecated > /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop: warning: boolean key > "Terminal" in group "Desktop Entry" has value "0", which is deprecated: boolean > values should be "false" or "true" > /home/lkundrak/rpmbuild/SOURCES/scidavis.desktop: error: value > "application/x-scidavis" for string list key "MimeType" in group "Desktop Entry" > does not have a semicolon (';') as trailing character > $ > > * Desktop file: the Categories tag should not contain X-Fedora any more > (wiki: Packaging/Guidelines#desktop) > Ok > 2.) Duplicate files > > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1 > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0 > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0.0 > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1 > warning: > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0 > warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0.0 > warning: > File listed twice: > /usr/share/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg I can't reproduce this > > 3.) SPEC file formatting > > scidavis.src: W: mixed-use-of-spaces-and-tabs (spaces: line 92, tab: line 1) > Ok > 4.) Just rm or %exclude .pyc and .pyo (unless they are needed) > > rpmlint of scidavis: > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyc > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyo > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.py These files are needed see comment 1 about this. > > 5.) Dependencies > > * As scidavis ships icons in the hicolor directory, it should have "Requires: > hicolor-icon-theme" > Ok > Most of these are fairly trivial; 5. and 4. are probably most important.
(In reply to comment #15) > > 2.) Duplicate files > > > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1 > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0 > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0.0 > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1 > > warning: > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0 > > warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0.0 > > warning: > > File listed twice: > > /usr/share/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg > > I can't reproduce this I am wondering if this is x86_64 specific? Could you please attach your build log? > > 4.) Just rm or %exclude .pyc and .pyo (unless they are needed) > > > > rpmlint of scidavis: > > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyc > > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyo > > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.py > > These files are needed see comment 1 about this. Even the .pyo and .pyc? I highly doubt that -- have you tried excluding them?
Created attachment 303050 [details] Build log
(In reply to comment #16) > (In reply to comment #15) > > > 2.) Duplicate files > > > > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1 > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0 > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational0.so.1.0.0 > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1 > > > warning: > > > File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0 > > > warning: File listed twice: /usr/lib64/scidavis/plugins/libfitRational1.so.1.0.0 > > > warning: > > > File listed twice: > > > /usr/share/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg > > > > I can't reproduce this > > I am wondering if this is x86_64 specific? Could you please attach your build log? see attached file > > > > 4.) Just rm or %exclude .pyc and .pyo (unless they are needed) > > > > > > rpmlint of scidavis: > > > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyc > > > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.pyo > > > scidavis.x86_64: W: non-conffile-in-etc /etc/scidavisrc.py > > > > These files are needed see comment 1 about this. > > Even the .pyo and .pyc? I highly doubt that -- have you tried excluding them? You are right. Now i drop their.
(In reply to comment #18) > > > > File listed twice: > > > > /usr/share/icons/hicolor/scalable/mimetypes/application-x-scidavis.svg > > > > > > I can't reproduce this > > > > I am wondering if this is x86_64 specific? Could you please attach your build log? > > see attached file Well i386, so it is arch specific. Leave this open, we'll resolve it later. APPROVED
New Package CVS Request ======================= Package Name: scidavis Short Description: Scientific Data Analysis and Visualization Owners: tanguy Branches: F-7 F-8 EL-5 InitialCC: Cvsextras Commits: yes
I assume you wanted a F-9 branch as well? cvs done (with F-9 branch added).
Package build fine for F-8 and F-9. I request an update for F-8 but for F-9 i don't know. Do you think it's still possible to ask rel-eng to include it in F9-final ? It fails for devel (F-10) http://koji.fedoraproject.org/koji/getfile?taskID=577314&name=build.log but i can't understand why. Help ? It fails for F-7 http://koji.fedoraproject.org/koji/getfile?taskID=577305&name=root.log because qwtplot3d-qt4-devel does not exist so i think qwtplot3d-devel has not been rebuilt against qt4. Maybe i can let this build as this beacause F-7 will reach end of life quite soon ? It fails also for EL-5 http://buildsys.fedoraproject.org/logs/fedora-5-epel/38814-scidavis-0.1.2-1.el5/ppc/root.log because PyQt4-devel and qwtplot3d-qt4-devel. For this build i'm not sure what to do. Maybe the best would be to bugzilla these packages to ask the maintainer to build their for EL-5?
(In reply to comment #22) > Package build fine for F-8 and F-9. > I request an update for F-8 but for F-9 i don't know. Do you think it's still > possible to ask rel-eng to include it in F9-final ? I think so. Request tagging into f9 final as described in [1], and explain that it is not really a freeze break, as the package was not frozen given it is a new package. [1] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy > It fails for devel (F-10) > http://koji.fedoraproject.org/koji/getfile?taskID=577314&name=build.log but i > can't understand why. Help ? Can't find -lssl. Hm, I think it should be a part of openssl-devel -- try adding it to BuildRequires. > It fails for F-7 > http://koji.fedoraproject.org/koji/getfile?taskID=577305&name=root.log because > qwtplot3d-qt4-devel does not exist so i think qwtplot3d-devel has not been > rebuilt against qt4. Maybe i can let this build as this beacause F-7 will reach > end of life quite soon ? > It fails also for EL-5 > http://buildsys.fedoraproject.org/logs/fedora-5-epel/38814-scidavis-0.1.2-1.el5/ppc/root.log > because PyQt4-devel and qwtplot3d-qt4-devel. For this build i'm not sure what to > do. Maybe the best would be to bugzilla these packages to ask the maintainer to > build their for EL-5? Yep, I won't worry about F-7, since noone should really be using it in three weeks, but if you want this to go to EPEL, probably the best thing you can do is to ask the respective maintainers to create EL-5 branches via bugzilla. Note that in case they won't respond or won't want to maintian EL-5 branches, you can request and maintain the branches you need as well.
(In reply to comment #23) > (In reply to comment #22) > > Package build fine for F-8 and F-9. > > I request an update for F-8 but for F-9 i don't know. Do you think it's still > > possible to ask rel-eng to include it in F9-final ? > > I think so. Request tagging into f9 final as described in [1], and explain that > it is not really a freeze break, as the package was not frozen given it is a new > package. > > [1] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy It's ok > > > It fails for devel (F-10) > > http://koji.fedoraproject.org/koji/getfile?taskID=577314&name=build.log but i > > can't understand why. Help ? > > Can't find -lssl. Hm, I think it should be a part of openssl-devel -- try adding > it to BuildRequires. I add openssl-devel to BR and now it builds fine but i don't understand why i have to add this between F-9 and devel ... > > > It fails for F-7 > > http://koji.fedoraproject.org/koji/getfile?taskID=577305&name=root.log because > > qwtplot3d-qt4-devel does not exist so i think qwtplot3d-devel has not been > > rebuilt against qt4. Maybe i can let this build as this beacause F-7 will reach > > end of life quite soon ? > > It fails also for EL-5 > > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/38814-scidavis-0.1.2-1.el5/ppc/root.log > > because PyQt4-devel and qwtplot3d-qt4-devel. For this build i'm not sure what to > > do. Maybe the best would be to bugzilla these packages to ask the maintainer to > > build their for EL-5? > > Yep, I won't worry about F-7, since noone should really be using it in three > weeks, but if you want this to go to EPEL, probably the best thing you can do is > to ask the respective maintainers to create EL-5 branches via bugzilla. Note > that in case they won't respond or won't want to maintian EL-5 branches, you can > request and maintain the branches you need as well. I will not worry about F-7 and EL-5 because it seems quite difficult to have have it built against EL-5!
> I add openssl-devel to BR and now it builds fine but i don't understand why i > have to add this between F-9 and devel ... One possible explanation is that openssl-devel was part of buildsys-build group, but no longer is. That would make sense, as Fedora tends to prefer NSS library to OpenSSL for cryptography. I am not sure about that though. > I will not worry about F-7 and EL-5 because it seems quite difficult to have > have it built against EL-5! Are there more difficulties other than presence of those packages? I can assist if needed.
(In reply to comment #25) > > I add openssl-devel to BR and now it builds fine but i don't understand why i > > have to add this between F-9 and devel ... > > One possible explanation is that openssl-devel was part of buildsys-build group, > but no longer is. That would make sense, as Fedora tends to prefer NSS library > to OpenSSL for cryptography. I am not sure about that though. > > > > I will not worry about F-7 and EL-5 because it seems quite difficult to have > > have it built against EL-5! > > Are there more difficulties other than presence of those packages? I can assist > if needed. see https://bugzilla.redhat.com/show_bug.cgi?id=443782 and https://bugzilla.redhat.com/show_bug.cgi?id=443783