Bug 434973 - Review Request: scidavis
Review Request: scidavis
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-26 11:58 EST by Eric Tanguy
Modified: 2009-01-07 13:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-25 12:58:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
lkundrak: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
Build log (397.33 KB, text/plain)
2008-04-20 07:07 EDT, Eric Tanguy
no flags Details

  None (edit)
Description Eric Tanguy 2008-02-26 11:58:48 EST
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.
Comment 1 Eric Tanguy 2008-02-26 12:07:56 EST
$ 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."
Comment 2 Neal Becker 2008-02-26 13:10:02 EST
 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
Comment 3 Eric Tanguy 2008-02-26 13:31:03 EST
Could you retry to download it ? It seems the package on the website was bad.
It's now solved.
Comment 4 Lubomir Kundrak 2008-03-08 07:45:22 EST
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!
Comment 5 Eric Tanguy 2008-03-08 13:44:33 EST
(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!

Comment 6 Lubomir Kundrak 2008-03-09 06:51:11 EDT
(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.
Comment 7 Eric Tanguy 2008-03-09 11:59:05 EDT
(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
Comment 8 Eric Tanguy 2008-03-16 04:44:44 EDT
Up
Comment 9 Lubomir Kundrak 2008-03-24 10:38:26 EDT
> > > > 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.
Comment 10 Eric Tanguy 2008-03-24 12:05:45 EDT
(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.
Comment 11 Rex Dieter 2008-03-24 12:20:28 EDT
> 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).
Comment 12 Eric Tanguy 2008-03-25 14:12:15 EDT
I'm using standard gnome fedora installation ...
But i think also it's good to provide also some bitmap icons.
Comment 13 Eric Tanguy 2008-03-30 10:38:35 EDT
Is it possible to finish this review to include the package in the F9 release ?
Comment 14 Lubomir Kundrak 2008-04-19 13:54:20 EDT
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.
Comment 15 Eric Tanguy 2008-04-20 03:20:11 EDT
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.

Comment 16 Lubomir Kundrak 2008-04-20 05:02:33 EDT
(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?
Comment 17 Eric Tanguy 2008-04-20 07:07:33 EDT
Created attachment 303050 [details]
Build log
Comment 18 Eric Tanguy 2008-04-20 07:09:13 EDT
(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.
Comment 19 Lubomir Kundrak 2008-04-20 11:03:34 EDT
(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
Comment 20 Eric Tanguy 2008-04-20 11:36:54 EDT
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
Comment 21 Kevin Fenzi 2008-04-22 13:13:02 EDT
I assume you wanted a F-9 branch as well? 

cvs done (with F-9 branch added).
Comment 22 Eric Tanguy 2008-04-23 04:13:16 EDT
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?
Comment 23 Lubomir Kundrak 2008-04-23 04:59:30 EDT
(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.
Comment 24 Eric Tanguy 2008-04-23 12:27:40 EDT
(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!

Comment 25 Lubomir Kundrak 2008-04-23 12:45:48 EDT
> 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.
Comment 26 Eric Tanguy 2008-04-23 12:54:06 EDT
(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

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