Due to the absense of autogen in PPC64 this package can not be scratch built in
Koji.

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

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).

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.

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
-------------------------------------------------------------------

Once you update your srpm, I will review this package.

Spec: http://rishi.fedorapeople.org/anjuta.spec
SRPM: http://rishi.fedorapeople.org/anjuta-2.2.3-3.fc8.src.rpm

(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.

Just tried to rebuild but it failed at least on x86_64.

http://koji.fedoraproject.org/koji/taskinfo?taskID=478909

There is a "multi-lib conflicts" bug:
https://bugzilla.redhat.com/show_bug.cgi?id=228351

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.

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.

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.

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).

So you mean that rpath can be removed completely?

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.

Well, it seems I have to investigate how devhelp plugin is
"load"ed (note that I am not familiar with anjuta!)

You can follow the discussion here:
http://sourceforge.net/mailarchive/forum.php?thread_name=3170f42f0803011824r11d9d22bn4cbf4756d56d8ee8%40mail.gmail.com&forum_name=anjuta-devel

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?

Do you have any comments on the "multi-lib conflicts" bug? I am not very
knowledgeable about multi-lib problems.

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.

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 :)

ping?

> * 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).

Spec: http://rishi.fedorapeople.org/anjuta.spec
SRPM: http://rishi.fedorapeople.org/anjuta-2.2.3-5.fc8.src.rpm

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

(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.

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+.

When rebuild is done, please close this bug.
By the way I would appreciate it if you would review my
review request (bug 439588)

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.

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.

(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.

By the way, 
- current anjuta spec file in devel/ repo has
  strange scriptlets wrt gconf schemas files. ([NAME] must
  be correctly replaced!)

All fixes in CVS now. Going to tag and build the package now.