Bug 244597 - Review Request: rkward - Graphical frontend for R language
Review Request: rkward - Graphical frontend for R language
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Chitlesh GOORAH
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-17 18:06 EDT by Pierre-Yves
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.4.7-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-13 13:07:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
chitlesh: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)
R (823 bytes, patch)
2007-08-07 16:39 EDT, Chitlesh GOORAH
no flags Details | Diff

  None (edit)
Description Pierre-Yves 2007-06-17 18:06:53 EDT
Spec URL: http://pingoured.dyndns.org/public/RPM/rkward/rkward.spec
SRPM URL: http://pingoured.dyndns.org/public/RPM/rkward/rkward-0.4.7-1.fc6.src.rpm
Description:
RKWard aims to provide an easily extensible, easy to use IDE/GUI for the
R-project. RKWard tries to combine the power of the R-language with the
(relative) ease of use of commercial statistics tools. Long term plans
include integration with office suites

I am seeking for a sponsor :-)
Comment 1 Roberto Bagnara 2007-07-03 09:16:57 EDT
Here is a pre-review for your review request.  As you will see, it is almost OK,
but a few of the "MUST" items need attention.

> - MUST: rpmlint must be run on every package.
>         The output should be posted in the review.

$ rpmlint -i rkward-0.4.7-1.fc6.src.rpm
W: rkward strange-permission rkward.spec 0755
A file that you listed to include in your package has strange
permissions. Usually, a file should have 0644 permissions.

W: rkward rpm-buildroot-usage %build mkdir -p $RPM_BUILD_ROOT%{_libdir}/R/library
$RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
will break short circuiting.

The first warning is easy to fix.  The second one boils down to the
question: what is that mkdir for?


> - MUST: The package must be named according to the Package Naming Guidelines.

OK.

> - MUST: The spec file name must match the base package %{name},
          in the format %{name}.spec unless your package has an exemption
          on Package Naming Guidelines.

OK.

> - MUST: The package must meet the Packaging Guidelines.

OK.

> - MUST: The package must be licensed with an open-source compatible license
>   and meet other legal requirements as defined in the legal section of
>   Packaging Guidelines.

OK.

> - MUST: The License field in the package spec file must match the actual
>         license.

OK.

> - MUST: If (and only if) the source package includes the text of the
>         license(s) in its own file, then that file, containing the text
>         of the license(s) for the package must be included in %doc.

OK: COPYING is included in %doc.

>- - MUST: The spec file must be written in American English.

OK.

> - MUST: The spec file for the package MUST be legible. If the reviewer
>   is unable to read the spec file, it will be impossible to perform
>   a review. Fedora is not the place for entries into the Obfuscated
>   Code Contest (http://www.ioccc.org/).

OK.

> - MUST: The sources used to build the package must match the
>         upstream source, as provided in the spec URL. Reviewers should use
>         md5sum for this task. If no upstream URL can be specified for this
>         package, please see the Source URL Guidelines for how to deal with
>         this.

OK.

> - MUST: The package must successfully compile and build into binary rpms
>   on at least one supported architecture.

OK.

> - MUST: If the package does not successfully compile, build or work
>         on an architecture, then those architectures should be
>         listed in the spec in ExcludeArch. Each architecture listed in
>         ExcludeArch needs to have a bug filed in bugzilla, describing the
>         reason that the package does not compile/build/work on that
>         architecture. The bug number should then be placed in a comment, next
>         to the corresponding ExcludeArch line. New packages will not have
>         bugzilla entries during the review process, so they should put this
>         description in the comment until the package is approved, then file
>         the bugzilla entry, and replace the long explanation with the bug
>         number. (Extras Only) The bug should be marked as blocking one (or
>         more) of the following bugs to simplify tracking such issues:
>         FE-ExcludeArch-x86, FE-ExcludeArch-x64, FE-ExcludeArch-ppc,
>         FE-ExcludeArch-ppc64

It works on x86 and x86_64, I don't know about other architectures.

> - MUST: All build dependencies must be listed in BuildRequires,
>         except for any that are listed in the exceptions section of Packaging
>         Guidelines; inclusion of those as BuildRequires is optional. Apply
>         common sense.

OK.

> - MUST: The spec file MUST handle locales properly. This is done
>         by using the %find_lang macro. Using %{_datadir}/locale/* is strictly
>         forbidden.

OK.

> - MUST: Every binary RPM package which stores shared library
>         files (not just symlinks) in any of the dynamic linker's default
>         paths, must call ldconfig in %post and %postun. If the package has
>         multiple subpackages with libraries, each subpackage should also have
>         a %post/%postun section that calls /sbin/ldconfig. An example of the
>         correct syntax for this is:
>
>         %post -p /sbin/ldconfig
>
>         %postun -p /sbin/ldconfig

These are missing.  Yet the package installs rkward.so.

> - MUST: If the package is designed to be relocatable, the packager
>         must state this fact in the request for review, along with the
>         rationalization for relocation of that specific package. Without
>         this, use of Prefix: /usr is considered a blocker.

OK.

> - MUST: A package must own all directories that it creates. If it
>   does not create a directory that it uses, then it should require a
>   package which does create that directory. The exception to this are
>   directories listed explicitly in the Filesystem Hierarchy Standard
>   (http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to
>   assume that those directories exist.

OK.

> - MUST: A package must not contain any duplicate files in the %files listing.

OK.

> - MUST: Permissions on files must be set properly. Executables
>         should be set with executable permissions, for example. Every %files
>         section must include a %defattr(...) line.

See the warnings given by rpmlint.

> - MUST: Each package must have a %clean section, which contains
>         rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

OK.

> - MUST: Each package must consistently use macros, as described in the
>         macros section of Packaging Guidelines.

The package uses the variable style (e.g., $RPM_BUILD_ROOT) almost
consistently, with only two occurrences of %{buildroot}: these should
probably become $RPM_BUILD_ROOT.

> - MUST: The package must contain code, or permissable content. This
>   is described in detail in the code vs. content section of Packaging
>   Guidelines.

OK.

> - MUST: Large documentation files should go in a -doc
>         subpackage. (The definition of large is left up to the packager's
>         best judgement, but is not restricted to size. Large can refer to
>         either size or quantity)

OK.

> - MUST: If a package includes something as %doc, it must not affect
>         the runtime of the application. To summarize: If it is in %doc,
>         the program must run properly if it is not present.

OK.

> - MUST: Header files must be in a -devel package.

OK.

> - MUST: Static libraries must be in a -static package.

OK.

> - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'
>         (for directory ownership and usability).

OK.

> - MUST: If a package contains library files with a suffix
>         (e.g. libfoo.so.1.1), then library files that end in .so
>         (without suffix) must go in a -devel package.

OK.

> - MUST: In the vast majority of cases, devel packages must require
          the base package using a fully versioned dependency:
          Requires: %{name} = %{version}-%{release}

OK.

> - MUST: Packages must NOT contain any .la libtool archives, these should
>         be removed in the spec.

> - MUST: Packages containing GUI applications must include a
>         %{name}.desktop file, and that file must be properly installed with
>         desktop-file-install in the %install section. This is described in
>         detail in the desktop files section of Packaging Guidelines. If you
>         feel that your packaged GUI application does not need a .desktop
>         file, you must put a comment in the spec file with your explanation.

How is rkward.desktop installed?

> - MUST: Packages must not own files or directories already owned by
          other packages. The rule of thumb here is that the first
          package to be installed should own the files or directories
          that other packages may rely upon. This means, for example,
          that no package in Fedora should ever share ownership with
          any of the files or directories owned by the filesystem or
          man package. If you feel that you have a good reason to own
          a file or directory that another package owns, then please
          present that at package review time.

OK.

> - MUST: At the beginning of %install, each package MUST run
>         rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
>         See Prepping BuildRoot For %install for details.

OK.

> - MUST: All filenames in rpm packages must be valid UTF-8.

OK.
Comment 2 Roberto Bagnara 2007-07-03 12:09:38 EDT
I wrote:
> > - MUST: Every binary RPM package which stores shared library
> >         files (not just symlinks) in any of the dynamic linker's default
> >         paths, must call ldconfig in %post and %postun. If the package has
> >         multiple subpackages with libraries, each subpackage should also have
> >         a %post/%postun section that calls /sbin/ldconfig. An example of the
> >         correct syntax for this is:
> >
> >         %post -p /sbin/ldconfig
> >
> >         %postun -p /sbin/ldconfig
>
> These are missing.  Yet the package installs rkward.so.

Please forget about this: rkward.so is not installed in one of the
dynamic linker's default paths.  Sorry.
Comment 3 Pierre-Yves 2007-07-03 12:54:32 EDT
Ok thanks for your comments, I thinks I took all of them into account :-)

There are the new spec file and the new srpm:

SPEC:
http://pingoured.dyndns.org/public/RPM/rkward/rkward.spec
SRPM:
http://pingoured.dyndns.org/public/RPM/rkward/rkward-0.4.7-2.fc6.src.rpm

Thanks
Comment 4 Roberto Bagnara 2007-07-03 16:06:57 EDT
There is one last warning that you may want to get rid of:

$ rpmlint -i rkward-0.4.7-2.x86_64.rpm 
W: rkward dangling-relative-symlink /usr/share/doc/HTML/en/rkward/common ../common
The relative symbolic link points nowhere.

All the rest seems OK to me.
Comment 5 Pierre-Yves 2007-07-03 18:21:46 EDT
Hi,

Based on that review, I do not know if there is anyway to get rid of that warning...

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222589

It is seems to be a features of some KDE packages...

Anyway, thanks for your review :-)
Comment 6 Jason Tibbitts 2007-07-03 19:58:04 EDT
Dangling relative symlinks are OK as long as the symlink destinations are
contained within the dependencies.  So once this package and all of its
dependencies are installed, those symlinks must all point somewhere.

Any package that uses the KDE help system will trigger this rpmlint complaint.

Dealing with rpmlint complaints is something of an art; some packages come up
clean, which is great but it doesn't necessarily mean that the pakage is OK. 
Some packages elicit all kinds of warnings but are quite acceptable.  The trick
is to understand the source of the complaints and to understand whether they
point to an actual packaging problem.
Comment 7 Pierre-Yves 2007-07-05 05:18:44 EDT
After set up the rpm, I can do 
ll /usr/share/doc/HTML/en/rkward/

in which I can find:
lrwxrwxrwx 1 root root      9 2007-07-04 09:19 common -> ../common

I guess the link is working... (I have the same on the dolphin package)
Comment 8 Pierre-Yves 2007-07-10 12:06:44 EDT
Any news ??
Comment 9 Roberto Bagnara 2007-07-12 03:26:55 EDT
Everything seems OK to me.  But I am unsure I have the authority to approve the
package.  I will try to find out (an additional problem is that I will be
traveling  until July 22).
Comment 10 Pierre-Yves 2007-07-31 02:20:30 EDT
I am back from hollidays, and you ??
Comment 11 Pierre-Yves 2007-07-31 02:44:58 EDT
Based on this list it seems that you have been sponsored so you should be able
to approve the package:
https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&role_type=user&format=html
You can have a look there
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
and there
http://fedoraproject.org/wiki/PackageReviewProcess
Comment 12 Pierre-Yves 2007-08-07 14:49:21 EDT
ping ?
Comment 13 Chitlesh GOORAH 2007-08-07 16:36:41 EDT
#001: License should NOW be GPLv2+
https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00108.html

#002: missing %post and %postun:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda

%post
touch --no-create %{_datadir}/icons/locolor
touch --no-create %{_datadir}/icons/crystalsvg

%postun
touch --no-create %{_datadir}/icons/locolor
touch --no-create %{_datadir}/icons/crystalsvg

#003: rm -f ${RPM_BUILD_ROOT}%{_datadir}/apps/katepart/syntax/r.xml
${RPM_BUILD_ROOT} should be $RPM_BUILD_ROOT

#004: 
diff -Naur /var/tmp/rkward-0.4.7-2-root-chitlesh/usr/lib/R/library/R.css /usr/lib/R/library/R.css
see patch rkward-rcss.patch
I won't block this for approval.
But however, I would like that you file a bug against the package R stating 
that he/she should apply that patch! (added me as CC: please)
Reason: better integration :)

#005: remove the useless comment (though I won't block this for approval) :
#mkdir -p ${RPM_BUILD_ROOT}%{_libdir}/R

#006: you can remove CXXFLAGS="$RPM_OPT_FLAGS" from the spec file. As the 
optflags are already pulled out as shown below:
if 
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/kde -I/usr/lib/qt-3.3/include -I.   -DQT_THREAD_SUPPORT  -D_REENTRANT -DQT_NO_ASCII_CAST  -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common  -MT 
rkeditordataframe.o -MD -MP -MF ".deps/rkeditordataframe.Tpo" -c -o 
rkeditordataframe.o rkeditordataframe.cpp; \
        then mv -f ".deps/rkeditordataframe.Tpo" ".deps/rkeditordataframe.Po"; 
else rm -f ".deps/rkeditordataframe.Tpo"; exit 1; fi

#007: BuildRequires
remove :
*   R from the BR as R-devel already requires R
*   qt-devel from the BR as kdebase-devel requires kdelibs-devel and 
kdelibs-devel requires qt-devel

In the future you can use: 
rpm -qR R-devel
R = 2.5.1
[..]
to know whether R or any other package depends on it.

#008: %doc
missing TODO and AUTHORS in %doc

#009: rpath
http://fedoraproject.org/wiki/Packaging/Guidelines?highlight=%28rpath%29#head-7cea8c7aa96400a4687e843156354476434ff883
add
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' 
libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
after %configure even though you added --disable-rpath (I don't trust it :) )

I'm taking up the review.
Comment 14 Chitlesh GOORAH 2007-08-07 16:39:48 EDT
Created attachment 160854 [details]
R
Comment 15 Chitlesh GOORAH 2007-08-07 16:43:33 EDT
(In reply to comment #4)
> There is one last warning that you may want to get rid of:
> 
> $ rpmlint -i rkward-0.4.7-2.x86_64.rpm 
> W: rkward 
dangling-relative-symlink /usr/share/doc/HTML/en/rkward/common ../common
> The relative symbolic link points nowhere.
> 
> All the rest seems OK to me.
> 

Jason Tibbitts's answer should be enough.

while :
rpmlint rkward
you'll no longer find that warning.
Comment 16 Pierre-Yves 2007-08-07 17:04:58 EDT
You can find here
http://www.pingoured.fr/public/RPM/rkward/R.R
A R script that should give you the following graph
http://www.pingoured.fr/public/RPM/rkward/plot.png
Comment 17 Pierre-Yves 2007-08-07 17:42:27 EDT
The new spec file
http://www.pingoured.fr/public/RPM/rkward/rkward.spec

The new SRPM
http://www.pingoured.fr/public/RPM/rkward/rkward-0.4.7-3.fc6.src.rpm

I am just not really sure about the diff.
Let me know if it needs any changes.

Thanks for the review
Comment 18 Pierre-Yves 2007-08-07 17:57:05 EDT
There are the new SRPM
http://www.pingoured.fr/public/RPM/rkward/rkward-0.4.7-4.fc6.src.rpm

and the spec
http://www.pingoured.fr/public/RPM/rkward/rkward.spec

Thanks for the review :-)
Comment 19 Chitlesh GOORAH 2007-08-07 17:58:52 EDT
MUST Items:

- MUST: rpmlint's output is clean except one symbolic warning
- MUST: The package is named according to the Package Naming Guidelines.
- MUST: The spec file name matches the base package %{name}
- MUST: The package meets the Packaging Guidelines.
- MUST: The package is licensed (GPL) with an open-source compatible license 
and meet other legal requirements as defined in the legal section of Packaging
Guidelines.
- MUST: The License field in the package spec file matches the actual license.
- MUST: the source package includes the text of the license(s) in its own 
file, then that file, containing the text of the license(s) for the package is
included in %doc.
- MUST: The spec file must be written in American English.
- MUST: The spec file for the package is be legible. 
- MUST: The sources used to build the package must matches the upstream 
source, as provided in the spec URL.
- MUST: The package successfully compiles and builds into binary rpms on at
least i386.
- MUST: All build dependencies is listed in BuildRequires.
- MUST: The spec file handles locales properly.
- MUST: If the package does not contain shared library files located in the
dynamic linker's default paths
- MUST: the package is not designed to be relocatable
- MUST: the package owns all directories that it creates.
- MUST: the package does not contain any duplicate files in the %files 
listing.
- MUST: Permissions on files are set properly.
- MUST: The package has a %clean section, which contains rm -rf %{buildroot} 
(or $RPM_BUILD_ROOT).
- MUST: The package consistently uses macros, as described in the macros 
section of Packaging Guidelines.
- MUST: The package contains code, or permissable content. This is described 
in detail in the code vs. content section of Packaging Guidelines.
- MUST: There are no Large documentation files
- MUST: %doc does not affect the runtime of the application. To summarize: If 
it is in %doc, the program must run properly if it is not present.
- MUST: There are no Header files or static libraries 
- MUST: The package does not contain library files with a suffix 
- MUST: Package does NOT contain any .la libtool archives
- MUST: Package containing GUI applications includes a %{name}.desktop file, 
and that file must be properly installed with desktop-file-install in 
the %install section.
- MUST: Package does not own files or directories already owned by other 
packages. 

SHOULD Items:

 - SHOULD: The source package does include license text(s) as COPYING
 - SHOULD: mock builds succcessfully in i386.
 - SHOULD: The reviewer tested that the package functions as described. A
package should not segfault instead of running, for example.
 - SHOULD: No subpackages present.

APPROVED
Comment 20 Chitlesh GOORAH 2007-08-07 18:01:19 EDT
PS: can you review #251190 (gds2pov - GDS2 layout file to POV-Ray conversion) 
for me ? :)
Comment 21 Pierre-Yves 2007-08-07 18:07:06 EDT
New Package CVS Request
=======================
Package Name: rkward
Short Description: Graphical frontend for R language
Owners: pingoufc4@yahoo.fr
Branches: FC-6 F-7
InitialCC:
Comment 22 Jason Tibbitts 2007-08-07 18:31:30 EDT
CVS done.
Comment 23 Fedora Update System 2007-08-08 11:28:54 EDT
rkward-0.4.7-4.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Chitlesh GOORAH 2007-08-08 16:33:03 EDT
you can now close this bug :)
Comment 25 Fedora Update System 2007-08-13 13:06:57 EDT
rkward-0.4.7-4.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

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