Hide Forgot
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.
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.