Bug 433199 - Review Request: anjuta - A GNOME development IDE for C/C++
Review Request: anjuta - A GNOME development IDE for C/C++
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
Depends On: 437675
Blocks: 228351
  Show dependency treegraph
 
Reported: 2008-02-17 10:21 EST by Debarshi Ray
Modified: 2008-05-26 14:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-31 09:37:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
mtasaka: fedora‑review+


Attachments (Terms of Use)
rpmlint of 2.4.1-1.fc10 I see (2.99 KB, text/plain)
2008-05-25 16:13 EDT, Mamoru TASAKA
no flags Details

  None (edit)
Description Debarshi Ray 2008-02-17 10:21:26 EST
Spec URL: http://rishi.fedorapeople.org/anjuta.spec
SRPM URL: http://rishi.fedorapeople.org/anjuta-2.2.3-1.fc8.src.rpm

Description:

Anjuta DevStudio is a versatile Integrated Development Environment (IDE) on
GNOME Desktop Environment and features a number of advanced programming
facilities. These include project management, application and class wizards,
an on-board interactive debugger, powerful source editor, syntax highlighting,
intellisense autocompletions, symbol navigation, version controls, integrated
GUI designing and other tools.

The documentation for this package is in anjuta-doc.
Comment 1 Debarshi Ray 2008-02-17 10:24:25 EST
Due to the absense of autogen in PPC64 this package can not be scratch built in
Koji.
Comment 2 Debarshi Ray 2008-02-17 10:27:49 EST
Anjuta installs some template *.c and *.h which causes some rpmlint warnings:

$ rpmlint anjuta
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/gtk/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/anjuta-plugin/src/plugin.h
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/anjuta-plugin/src/plugin.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/xlib-dock/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/xlib/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/gtk/src/callbacks.h
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/gtk/src/callbacks.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/terminal/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/gnome/src/callbacks.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/gnome/src/callbacks.h
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/xlib-dock/src/wmgeneral.h
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/xlib-dock/src/wmgeneral.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/gnome/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/mkfile/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/sdl/src/main.c
anjuta.x86_64: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/xlib-dock/src/pixmaps.h
anjuta.x86_64: W: devel-file-in-non-devel-package /usr/share/anjuta/indent_test.c
Comment 3 Kevin Kofler 2008-02-18 01:56:40 EST
Seeing how this was rebuilt Aug 29 2007 by rel-eng and Dec 07 2007 by Alex 
Lancaster, and you took it over Dec 6 2007, I'd argue the rereview is not 
necessary unless we're really really pedantic (the last rebuild was 3 months 1 
week before you took it over and the next one was one day after you took it 
over and not by you).
Comment 4 Debarshi Ray 2008-02-18 03:28:01 EST
That is true, but:

+ Since last July none of the newer upstream releases were built and it has been
even longer since Paul last touched it.

+ The last couple of successful re-builds were just "bump the %{release} and
re-build" and did not clean-up any of the cruft that had gathered with time:

* Fri Dec 07 2007 Alex Lancaster <alexlan[AT]fedoraproejct.org> 1:2.2.0-4
- Rebuild for new openssl

* Wed Aug 29 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org>
- 1:2.2.0-3
- Rebuild for selinux ppc32 issue.

If you still think the review is not needed, then I will close it and carry on.
Comment 5 Mamoru TASAKA 2008-02-27 08:56:30 EST
I want to check this package once autogen is imported into Fedora
- BuildRequires changed
- Please try to remove chrpath use
! Note
  You don't have to write || : multiple times on scriptlets.
  The /bin/sh script in scriptlets are called with "set -x", not
  "set -e -x", so the exit status of the last line in the script
  really affects. So simply adding "exit 0" at the last line
  is okay.
  http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/comix/devel/comix.spec
- About this scriptlet:
-------------------------------------------------------------------
%post doc
scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :
-------------------------------------------------------------------
  File entry of -doc subpackage reads:
-------------------------------------------------------------------
%dir %{_datadir}/omf/%{name}-manual
%{_datadir}/omf/%{name}-manual/%{name}-manual-C.omf
-------------------------------------------------------------------
Comment 6 Mamoru TASAKA 2008-02-27 22:05:38 EST
Once you update your srpm, I will review this package.
Comment 8 Debarshi Ray 2008-02-28 14:12:53 EST
(In reply to comment #5)

> - Please try to remove chrpath use

Fixed.

> ! Note
>   You don't have to write || : multiple times on scriptlets.

I do that because Hans had once asked me to do so:
https://bugzilla.redhat.com/show_bug.cgi?id=247417#c19

Is this a problem? If it is, then I will have to fix a number of my existing
packages.

> - About this scriptlet:
> -------------------------------------------------------------------
> %post doc
> scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :
> -------------------------------------------------------------------
>   File entry of -doc subpackage reads:
> -------------------------------------------------------------------
> %dir %{_datadir}/omf/%{name}-manual
> %{_datadir}/omf/%{name}-manual/%{name}-manual-C.omf
> -------------------------------------------------------------------

Fixed.
Comment 9 Mamoru TASAKA 2008-02-29 08:31:45 EST
Just tried to rebuild but it failed at least on x86_64.

http://koji.fedoraproject.org/koji/taskinfo?taskID=478909
Comment 10 Debarshi Ray 2008-03-01 08:59:24 EST
There is a "multi-lib conflicts" bug:
https://bugzilla.redhat.com/show_bug.cgi?id=228351
Comment 11 Debarshi Ray 2008-03-01 09:06:46 EST
Spec: http://rishi.fedorapeople.org/anjuta.spec
SRPM: http://rishi.fedorapeople.org/anjuta-2.2.3-4.fc8.src.rpm
Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=481998

Other methods of removing rpaths are leading to build failures. Reverting to
chrpath.
Comment 12 Mamoru TASAKA 2008-03-01 09:42:35 EST
Well, one of the reason I dislike to use "rpath" commands is that
"rpath" removes all rpaths, which sometimes renders an application
unusable (ex. bug 432468)

For this package, from
http://koji.fedoraproject.org/koji/taskinfo?taskID=482072
--------------------------------------------------------------------------
ERROR   0001: file '/usr/lib64/anjuta/libanjuta-class-gen.so' contains a
standard rpath '/usr/lib64' in [/usr/lib64/anjuta:/usr/lib64]
--------------------------------------------------------------------------
Note that the rpath /usr/lib64/anjuta is _valid_ and I guess this rpath
should not be removed. In short, we should remove just invalid rpath
and leave needed rpath as it is.
Comment 13 Debarshi Ray 2008-03-01 21:17:33 EST
Most of those rpaths  are present in the *.so files representing each of the
plugins provided by Anjuta.

Looking at this screenshot http://rishi.fedorapeople.org/Screenshot-Anjuta.png
of Anjuta running on my Fedora 8 system, I think the plugins are working fine
even without the rpaths being present.

However I do not know how Anjuta actually "loads" the plugins. grepping for
"dlopen" in the Subversion snapshot did not get me anyothing. I will ask upstream.
Comment 14 Debarshi Ray 2008-03-02 05:44:14 EST
According to upstream, the plugins are loaded using GModule's g_module_open and
the path is constructed using the corresponding *.plugin file and $(libdir).
Comment 15 Mamoru TASAKA 2008-03-03 09:43:35 EST
So you mean that rpath can be removed completely?
Comment 16 Debarshi Ray 2008-03-06 04:36:19 EST
Here is what Naba Kumar (original author of Anjuta) has to say on
https://lists.sourceforge.net/lists/listinfo/anjuta-devel :

On Sun, 2008-03-02 at 19:28 +0530, Debarshi Ray wrote:
> > If you remove rpath from anjuta binary, devhelp plugin will stop
> >  working.
>
> Here is a screenshot of Anjuta, with all rpaths removed, running on
> Fedora 8: http://rishi.fedorapeople.org/Screenshot-Anjuta.png
>
May be in fedora 8, the gtkmozembed library path is set somewhere
permanently (e.g. in /etc/ld.so.conf). In other systems, it is
inside /usr/lib/firefox and strangely not all versions of that library
(usually shipped with other mozilla products) work interchangably. You
need to be able to find the same lib used to compile the executable.
That is why both devhelp and anjuta has rpath to ensure that exact lib
is used. Otherwise you get strange crashes if either of these programs
load a different version of that lib (try running anjuta without the
rpath and after installing seamonkey).

In fact, anjuta inherits the same rpath used by devhelp from its
pkgconfig file.
Comment 17 Mamoru TASAKA 2008-03-07 02:26:59 EST
Well, it seems I have to investigate how devhelp plugin is
"load"ed (note that I am not familiar with anjuta!)
Comment 19 Debarshi Ray 2008-03-12 16:55:54 EDT
I am inclined to ship anjuta without the rpaths, until there is any specific bug
about it. Right now the anjuta in F-7, F-8 and devel does not have any rpaths
(including Devhelp plugin) and I am unable to reproduce any problem on my local
Fedora 8 system.

What do you think?
Comment 20 Debarshi Ray 2008-03-12 17:08:13 EDT
Do you have any comments on the "multi-lib conflicts" bug? I am not very
knowledgeable about multi-lib problems.
Comment 21 Mamoru TASAKA 2008-03-15 13:55:16 EDT
Well, I hope I can check your newest srpm within 2 days.

(In reply to comment #20)
> Do you have any comments on the "multi-lib conflicts" bug? I am not very
> knowledgeable about multi-lib problems.

Your Patch1 should solve the multiarch issue.
Comment 22 Mamoru TASAKA 2008-03-16 04:59:57 EDT
For 2.2.3-4:

* rpath issue
  - Removing rpath can be done by the following.
    (ref: bug 432468)
--------------------------------------------------------------
%prep
%setup -q
%patch0 -p1
%patch1 -p1
.......
iconv --from-code ISO8859-1 --to-code UTF-8 ./THANKS \
  --output THANKS.utf-8 && mv THANKS.utf-8 ./THANKS

sed -i.libdir_syssearch -e \
        '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib64 |' \
        configure
sed -i.gecko -e 's|-R\$GECKO_HOME||' configure

# on ppc64, pangox.pc contains rpath linkage
# -R/usr/lib64. Argh!!
mkdir -p PKGCONFIG
sed -e 's|-R/usr/lib64||' %{_libdir}/pkgconfig/pangox.pc > \
	PKGCONFIG/pangox.pc

%build
export PKG_CONFIG_PATH=$(pwd)/PKGCONFIG

%configure ......
--------------------------------------------------------------
    Note:
    1. I don't usually edit libtool but configure because libtool
       is created from configure.
    2. This leaves non-standard rpath on libanjuta-class-gen.so, 
       however this rpath must not be removed.
--------------------------------------------------------------
[tasaka1@localhost anjuta2]$ objdump --headers --private-headers
/usr/lib/anjuta/libanjuta-class-gen.so | grep RPATH
  RPATH       /usr/lib/anjuta
[tasaka1@localhost anjuta2]$ ldd -r /usr/lib/anjuta/libanjuta-class-gen.so |
grep /usr/lib/anjuta
        libanjuta-project-wizard.so =>
/usr/lib/anjuta/libanjuta-project-wizard.so (0x00125000)
--------------------------------------------------------------
    3. GECKO related rpath related to libanjuta-devhelp.so
--------------------------------------------------------------
[tasaka1@localhost anjuta2]$ ldd -r /usr/lib/anjuta/libanjuta-devhelp.so >/dev/null
[tasaka1@localhost anjuta2]$ ldd -r /usr/lib/anjuta/libanjuta-devhelp.so | grep
devhelp
        libdevhelp-1.so.0 => /usr/lib/libdevhelp-1.so.0 (0x0017e000)
--------------------------------------------------------------
       If the linkage on libdevhelp-1.so is correct (on Fedora it seems
       correct), then libanjuta-devhelp.so doesn't have to have rpath
       for GECKO related directory.

* valgrind plugin
  - IMO it is better that you write a comment why you disable
    valgrind plugin (actually it doesn't build because 
    binutils-devel ships non-fPIC-compiled static archives:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=518032 )

! License
  - For files under plugins/editor/scintilla, they have the license
    term like
--------------------------------------------------------------
// Scintilla source code edit control
/** @file AutoComplete.cxx
 ** Defines the auto completion list box.
 **/
// Copyright 1998-2003 by Neil Hodgson <neilh@scintilla.org>
// The License.txt file describes the conditions under which this software may
be distributed.
--------------------------------------------------------------
    However License.txt cannot be found anywhere.
    From http://scintilla.sourceforge.net/License.txt it seems
    MIT (so GPLv2+ compatible), however would you ask the upstream
    to add License.txt from the next version?

(In reply to comment #8)
> > ! Note
> >   You don't have to write || : multiple times on scriptlets.
> 
> I do that because Hans had once asked me to do so:
> https://bugzilla.redhat.com/show_bug.cgi?id=247417#c19
> 
> Is this a problem? If it is, then I will have to fix a number of my existing
> packages.
  - What I mean here is that all || : can be replaced with just adding
    one line of "exit 0" (and with this Hans actually doesn't complain :) )
    Of cource writing multiple || : is not a problem. I just don't want
    to write it many times :)
Comment 23 Mamoru TASAKA 2008-03-26 08:06:51 EDT
ping?
Comment 24 Debarshi Ray 2008-03-27 00:11:41 EDT
> * rpath issue
>   - Removing rpath can be done by the following.
>
> [...]
>
> sed -i.libdir_syssearch -e \
>         '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib64 |' \
>         configure

You seem to have left out /lib. I  added it but that leads to the following
rpmlint error:
anjuta.src:103: E: hardcoded-library-path in /lib

Can't we use /%{lib} or %{_libdir} instead of hardcoding the paths?

> ! License
>   - For files under plugins/editor/scintilla, they have the license
>     term like
> --------------------------------------------------------------
> // Scintilla source code edit control
> /** @file AutoComplete.cxx
>  ** Defines the auto completion list box.
>  **/
> // Copyright 1998-2003 by Neil Hodgson <neilh@scintilla.org>
> // The License.txt file describes the conditions under which this software may
> be distributed.
> --------------------------------------------------------------
>     However License.txt cannot be found anywhere.
>     From http://scintilla.sourceforge.net/License.txt it seems
>     MIT (so GPLv2+ compatible), however would you ask the upstream
>     to add License.txt from the next version?

I have added "and MIT" to the License tag of the main package because this looks
like a multiple licensing scenario (and not mixed licensing).
Comment 26 Mamoru TASAKA 2008-03-27 14:10:37 EDT
For 2.2.4-5:

* License
-----------------------------------------------------------
-License:       GPLv2+
+Release:       5%{?dist}
+# The Scintilla editor plugin is under MIT.
+License:       GPLv2+ and MIT
-----------------------------------------------------------
   - Well, libanjuta-scintilla.la is only used by
     libanjuta-editor.so, which is polluted by GPLv2+ from
     libanjuta.so so the license tag should still be
     GPLv2+ only (there is no libanjuta-scintilla.so in rpm).


* PKGCONFIG
-----------------------------------------------------------
+export PKG_CONFIG_PATH="./PKGCONFIG"
 %configure --disable-static --enable-gtk-doc --enable-devhelp \
   --enable-plugin-glade --enable-graphviz --enable-plugin-sourceview \
   --disable-plugin-valgrind --enable-plugin-subversion \
-  --with-svn-lib=%{_libdir}
+  --with-svn-lib=%{_libdir} PKG_CONFIG_PATH=./PKGCONFIG
------------------------------------------------------------
  - Perhaps the last "PKG_CONFIG_PATH=./PKGCONFIG" (as configure
    option) is not needed.

(In reply to comment #24)
> > * rpath issue
> You seem to have left out /lib. I  added it but that leads to the following
> rpmlint error:
> anjuta.src:103: E: hardcoded-library-path in /lib
> 
> Can't we use /%{lib} or %{_libdir} instead of hardcoding the paths?
  - This is very intentional and here we must ignore this rpmlint
    error.

Other things are okay.
-------------------------------------------------------------------------------
     This package (anjuta) is APPROVED by me (again)
-------------------------------------------------------------------------------

ref:
I once reviewed anjuta however at that time I didn't care about
rpath issue or license issue or so :)
https://bugzilla.redhat.com/show_bug.cgi?id=210464
Comment 27 Debarshi Ray 2008-03-29 10:35:33 EDT
(In reply to comment #26)
> For 2.2.4-5:
> 
> * License
> -----------------------------------------------------------
> -License:       GPLv2+
> +Release:       5%{?dist}
> +# The Scintilla editor plugin is under MIT.
> +License:       GPLv2+ and MIT
> -----------------------------------------------------------
>    - Well, libanjuta-scintilla.la is only used by
>      libanjuta-editor.so, which is polluted by GPLv2+ from
>      libanjuta.so so the license tag should still be
>      GPLv2+ only (there is no libanjuta-scintilla.so in rpm).

Since libanjuta-scintilla.la is included in libanjuta-editor.so, looking at
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines this might be a case
of: "GPLv2+ and (GPLv2+ and MIT)". Some of sort multiple-cum-mixed scenario.

If that is so, shall we split the Scintilla plugin into a separate subpackage
with "(GPLv2+ and MIT)" and leave the main package as "GPLv2+"? Apart from
Scintilla Anjuta can use the GtkSourceView plugin for edting purposes.

What do you think?

> * PKGCONFIG
> [...]
>   - Perhaps the last "PKG_CONFIG_PATH=./PKGCONFIG" (as configure
>     option) is not needed.

Fixed. Silly mistake on my part.
Comment 28 Mamoru TASAKA 2008-03-29 10:52:16 EDT
As said in comment 26, the linkage of libanjuta-editor.so against
libanjuta.so (i.e. libanjuta-editor.so and libanjuta.so are
"not distinct and not independent") renders the license 
of libanjuta-editor.so to GPLv2+.
Comment 29 Mamoru TASAKA 2008-03-31 09:25:30 EDT
When rebuild is done, please close this bug.
By the way I would appreciate it if you would review my
review request (bug 439588)
Comment 30 Debarshi Ray 2008-05-25 14:46:06 EDT
In trying to update Anjuta to 2.4.1 for Fedora 9 and Rawhide I am getting a
large number of rpmlint errors and warnings, which seem spurious to me. Can
someone (Mamoru?) throw an eye over it? The changes are in the devel branch of
the CVS.
Comment 31 Mamoru TASAKA 2008-05-25 16:13:36 EDT
Created attachment 306628 [details]
rpmlint of 2.4.1-1.fc10 I see

rpmlint log of 2.4.1-1.fc10 anjuta binary rpms on i386 I see
is attached. Does this log coincide with what you see?

Then:
A.
anjuta-devel.i386: W: dangling-relative-symlink
/usr/lib/anjuta/libfile-manager.so libfile-manager.so.0.0.0
anjuta-devel.i386: W: dangling-relative-symlink
/usr/lib/anjuta/liblanguage-manager.so liblanguage-manager.so.0.0.0
  - These are symlinks to plugin modules, not system-wide libraries
    and should be main anjuta package, not in -devel package.

B.
anjuta.i386: W: devel-file-in-non-devel-package
/usr/share/anjuta/project/anjuta-plugin/src/plugin.c

and etc
  - I saw these rpmlint also in 2.2.3 era and I guess these  files
    must be main package (per your comment 2)

C.
anjuta.i386: W: non-conffile-in-etc
/etc/gconf/schemas/anjuta-build-basic-autotools-plugin.schemas

 and etc
  - You can just ignore all. Actually gconf schemas files are not config
    file, however perhaps for historical reason they are put under
    /etc.

D.
anjuta-devel.i386: E: only-non-binary-in-usr-lib
 - Perhaps you can ignore this.

E.
anjuta.i386: E: zero-length /usr/share/anjuta/project/mkfile/po/ChangeLog
  - Same as B.
Comment 32 Debarshi Ray 2008-05-25 16:20:15 EDT
(In reply to comment #31)

> rpmlint log of 2.4.1-1.fc10 anjuta binary rpms on i386 I see
> is attached. Does this log coincide with what you see?

Yes.

Thank you for your comments. I will tag and build the package after applying the
fix in A.
Comment 33 Mamoru TASAKA 2008-05-25 16:22:59 EDT
By the way, 
- current anjuta spec file in devel/ repo has
  strange scriptlets wrt gconf schemas files. ([NAME] must
  be correctly replaced!)
Comment 34 Debarshi Ray 2008-05-26 14:56:40 EDT
All fixes in CVS now. Going to tag and build the package now.

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