GNOME Commander is a "two-pane" graphical file manager for the GNOME desktop environment. Reproducible: Always Steps to Reproduce:
Created attachment 160465 [details] gnome-extra/gnome-commander-1.2.6 Proposed ebuild. Note: doesn't build with LDFLAGS="-Wl,--as-needed"
*** Bug 16550 has been marked as a duplicate of this bug. ***
I may be convinced to add this to portage, but before that can happen, the --as-needed problem should be solved (someone else might be convinced without that I guess). An initial quick review of the ebuild revealed this: * G2CONF should be in pkg_setup, because it's not a simple flag passing but includes use_with calls. Not nice for global scope * Probably missing a few build time dependencies. pkg-config most likely for example * I got stuff like gnome-cmd-tags-doc.cc:476: undefined reference to `gsf_input_mmap_new' even with USE=-gsf and the linker command leading to that included -L/usr/lib /usr/lib/libgsf-1.so
Just to add that their release comes with ebuild that is maintained by them I guess, http://gcmd.rootnode.net/trunk/data/gnome-commander.ebuild and it does filter-ldflags -Wl,--as-needed
well, they should fix it properly. I'm big on supporting --as-needed, and as I said, someone else might not be and might add it with it broken. That said, I didn't spell it out, but I might be fixing this myself once I have time for that, so someone else doing it will just speed up getting into portage...
Created attachment 161964 [details] gnome-commander-1.2.7.ebuild
Bump to gnome-commander-1.2.7
Ok, some review then on that 1.2.7 ebuild > inherit gnome2 flag-o-matic flag-o-matic not necessary once --as-needed is fixed (then eutils is more likely to be needed of course) > SRC_URI="http://ftp.gnome.org/pub/GNOME/sources/${PN}/1.2/${P}.tar.bz2"; This is a standard GNOME infrastructure hosted download location, it should be omit - the gnome2.eclass will take care of it. > KEYWORDS="~alpha ~amd64 ~ia64 ~ppc ~ppc64 ~sparc ~x86" KEYWORDS should only be for arches that have been tested by the author himself/herself > USE_DESC=" > exif: add support for Exif and IPTC > gsf: add support for OLE, OLE2 and ODF > id3: add support for ID3, Vorbis, FLAC and APE > python: add support for python plugins" There is no such variable, this would be part of metadata.xml instead per GLEP56 > RDEPEND=">=x11-libs/gtk+-2.8.0 > >=dev-libs/glib-2.6.0 > >=gnome-base/libgnomeui-2.4.0 > >=gnome-base/libgnome-2.4.0 > >=gnome-base/gnome-vfs-2.0 > || ( > app-admin/gamin > app-admin/fam > ) There's virtual/fam for this. I suppose gnome-commander isn't using GIO yet? also gnome-vfs itself includes file monitoring API, isn't that used or is FAM API really used directly? > DEPEND="${RDEPEND} > dev-util/intltool > dev-util/pkgconfig" intltool and pkgconfig typically come with a minimal version. This is handle via an argument to IT_PROG_INTLTOOL and such usually. If not then, the m4 macros usually declare a minimum version themselves that can be seen from aclocal.m4, and that depends on what versions m4 file was used to generate the tarball. pkgconfig is nitpicking though, as unless it uses a recent feature of it, the oldest version in tree is good enough anyway. For intltool often a specific version is requested - for example if po/LINGUAS is used for declaring the supported linguas (instead of ALL_PO in configure.ac/in), then typically that implies a >=intltool-0.35.0 if I recall right, and that should be reflected as the argument to IT_PROG_INTLTOOL by upstream in that case. > DOCS="AUTHORS BUGS ChangeLog NEWS README TODO" Does BUGS contain anything useful? > pkg_setup() { > G2CONF=" ${G2CONF} > $(use_with exif exiv2) > $(use_with gsf libgsf) > $(use_with id3 taglib) Not fond of that lining up there. > $(use_enable python python)" Doubling "python" not necessary, it defaults to the same as first argument if omitted > filter-ldflags -Wl,--as-needed Wrong indentation for filter-ldflags line as it's not a continuation of G2CONF; though of course it shouldn't be necessary to be here at all. For some things I like the 1.2.6 ebuild better, for other things the 1.2.7 one, will need to look closer. Also, I think I didn't spell it out quite well, but the missing references I got in the build (as in end of comment #3) suggest that at least gsf is automagical in configure and my USE=-gsf was not honored, and that should be fixed (and other automagical things - http://www.gentoo.org/proj/en/qa/automagic.xml )
Works great here... 1.2.7 on x86 Thank you!
on hardened too :]
align ebuild requests to same values
On my system x86_64 without Gnome I has error "configure: error: gnome-doc-utils >= 0.3.2 not found". I fix this with add to ebuild in RDEPEND section string ">=app-text/gnome-doc-utils-0.14.2"
@Frederic: can you fix that progLamer said ? (put gnome-doc-utils in DEPEND and not RDEPEND) thanks in advance ;)
Created attachment 199574 [details] gnome-commander-1.2.8.ebuild Hi, Version bump : 1.2.8 Added corrections asked by progLamer and Romain, and added "pdf" USE flag to enable or disable optional PDF support. Compiles and runs like a charm on ~x86.
Hi, Version bump : 1.2.8.1 (BTW, 1.2.8.2 is soon to be released I believe.) I'll attach my 1.2.8.1 ebuild next. This compiles and runs fine for me under ~x86. I'd like to speak up -- if anyone is monitoring this new package request! -- to ask that this be added. Perhaps it could be placed in the gnome layman overlay for testing and eventual stable addition to portage? I claim this is warranted because: 1.) This is an official Gnome project, with VCS at git.gnome.org; 2.) This is a mature project, being at least five years old; 3.) This is an actively developed project, and has both stable and testing branches in VCS; 4.) It provides (another) easy method to browse and access SMB shares for Gnome, among other features. HTH. TIA. Clemmitt
Created attachment 204812 [details] Updated ebuild for Gnome-Commander V1.2.8.1 This is an updated ebuild for the latest stable version of Gnome-Commander. It's identical to the above 1.2.8 ebuild (hat tip to Hubert Mercier et al) with minor indentation clean-up to suit my tastes :^) HTH.
Created attachment 205002 [details] app-misc/gnome-commander-1.2.8.2.ebuild since 1.2.8.2 bugfix is out, I'm proposing this new ebuild. As you can see, it is a simpler version of previously published ones. * EAPI has been updated to 2; * Versions have been removed, since versions in portage are sufficient; * filter-flags has been removed (I was not able to find gcmd site ebuild, the last update seems 1y old, on my systems the package has been built without problems using LDFLAGS="-Wl,--as-needed"); * popppler dependency has been changed * I've put G2CONF back to global. Maybe I'm wrong, but -- since setting G2CONF is a configuration operation -- it should be done in src_configure. But src_configure should set G2CONF, then call gnome2_src_configure. IMO, it is trickier than declaring G2CONF. * IMO, app-misc is better suited than gnome-extra (app-misc holds other file managers)
G2CONF should be in pkg_setup, declaring G2CONf with use_with and use_enable in global scope is a major QA problem as it will slow down sourcing of the ebuild which happens a lot when doing regular emerge operations.
(In reply to comment #18) > G2CONF should be in pkg_setup, declaring G2CONf with use_with and use_enable in > global scope is a major QA problem as it will slow down sourcing of the ebuild > which happens a lot when doing regular emerge operations. > +1 - RDEPEND isn't defined, so it defaults to the value of DEPEND, ie RDEPEND="${DEPEND}", which is annoying because pkgconfig and intltool are required at buildtime and not at runtime.
> - RDEPEND isn't defined, so it defaults to the value of DEPEND, ie > RDEPEND="${DEPEND}", which is annoying because pkgconfig and intltool are > required at buildtime and not at runtime. > I'm sorry, I've uploaded the wrong version of my file. My intention was to use RDEPEND=${DEPEND}. Even if you're right about buildtime/runtime situation, quoting from http://devmanual.gentoo.org/general-concepts/dependencies/index.html "The DEPEND ebuild variable should specify any dependencies which are required to unpack, patch, compile or install the package" and so I put those deps in DEPEND.
Created attachment 205024 [details] fixed ebuild fixed version. additional fix: wrong slot dependency for python.
(In reply to comment #21) > Created an attachment (id=205024) [details] > fixed ebuild > > fixed version. > additional fix: wrong slot dependency for python. I've used this ebuild from Michelangelo (having decided not to use the ebuilds provided inside the gnome-commander tarballs -- contributors here arguably know more about details of Gentoo and portage :^), and it builds fine and Works For Me. My thanks to Michelangelo Scopelliti. Clemmitt
Created attachment 207634 [details, diff] asneeded.patch make it linkable with LDFLAGS="-Wl,--as-needed" btw probably its good idea to send this patch to the upstream.
Only bugfix-releases since 2009, severe usage problems, closing.
Hi, > Only bugfix-releases since 2009, severe usage problems, closing. Please, could you be a bit more precise ? I use it very often, without any major problem in its later version (1.2.8.6)... Thanks,
*** Bug 327161 has been marked as a duplicate of this bug. ***
I don't see a problem either. Didn't used it a long time, but as long upstream fixes bugs (as-needed) there shouldn't be a problem to have the ebuild.
(In reply to comment #23) > Created an attachment (id=207634) [details] > asneeded.patch > btw probably its good idea to send this patch to the upstream. As of version 1.2.8.6, this patch is now included in upstream source. I'll attach a working ebuild for v. 1.2.8.6 next. It just eliminates the patching of the source. HTH. Clemmitt
Created attachment 240191 [details] Ebuild for gnome-extra/gnome-commander v. 1.2.8.6 Ebuild which eliminates asneeded.patch required in prior ebuilds.
btw, its in my overlay already for a long time. layman -a rion
Created attachment 257652 [details] gnome-commander-1.2.8.9.ebuild version 1.2.8.9 was released gnome-commander 1.2.8.9 --------------- Bug fixes: * ... New features: * Support for shell-style wildcards in quick search
1.2.8.11 just released; http://ftp.gnome.org/pub/GNOME/sources/gnome-commander/1.2/gnome-commander-1.2.8.11.changes I just renamed the 1..2.8.9 ebuild and it installs and runs fine on ~amd64
Created attachment 283975 [details] gnome-commander-1.2.8.12.ebuild New version of gnome-commander is available. Unfortunetly it does not install properly with python 3 therefore ebuild adds explisit setting of python 2
A new version 1.2.8.13 was released, but it is only on the mailing list: http://lists.nongnu.org/archive/html/gcmd-devel/2011-08/msg00000.html Renaming the last ebuild worked fine.
Created attachment 310853 [details] gnome-commander-1.2.8.15.ebuild
Created attachment 369962 [details] gnome-commander-1.4.ebuild I prepared a new ebuild with EAPI=5. Can somebody have a look at it? The main difference to the previous ebuild from karpi is that I removed the SRC_URI, as it is not necessary. This ebuild is preliminary as GNOME Commander version 1.4 will be released not until March 2014.
Hello, its great, that this project still lives. I have try your ebuild quickly and its look like sources not yet available: (maybe until March 2014 as you mentioned.. .) >>> Downloading 'http://ftp.gnome.org/pub/gnome/sources/gnome-commander/1.4/gnome-commander-1.4.tar.xz' --2014-02-09 18:56:45-- http://ftp.gnome.org/pub/gnome/sources/gnome-commander/1.4/gnome-commander-1.4.tar.xz Resolving ftp.gnome.org... 130.239.18.173, 130.239.18.165, 130.239.18.163, ... Connecting to ftp.gnome.org|130.239.18.173|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2014-02-09 18:56:45 ERROR 404: Not Found.
Created attachment 374550 [details] gnome-commander-1.4.1.ebuild I made a small change in this ebuild, compared to the last one. Now, if python is selected, gnome-vfs-python is installed, too. Otherwise, python plugins won't work.
(In reply to Uwe Scholz from comment #38) > Created attachment 374550 [details] > gnome-commander-1.4.1.ebuild > > I made a small change in this ebuild, compared to the last one. > > Now, if python is selected, gnome-vfs-python is installed, too. Otherwise, > python plugins won't work. ==>python? ( =dev-lang/python-2* dev-python/gnome-vfs-python ) I don't think you need teh python-2* dependency there. This covered already in the PYTHON_DEPEND line. ==>RDEPEND="${ALL_DEPEND}" What is ALL_DEPEND? Why do you need to enforce the +gsf flag?
Thank you for your reply! (In reply to Markos Chandras from comment #39) > ==>python? ( =dev-lang/python-2* > dev-python/gnome-vfs-python ) > > I don't think you need teh python-2* dependency there. This covered already > in the PYTHON_DEPEND line. Thanks, I changed that. > ==>RDEPEND="${ALL_DEPEND}" > > What is ALL_DEPEND? Good question! At this point I realized that my ebuilds have been a mess. So I spent some time rebuilding it with the help of the Gentoo Development manual. ALL_DEPEND is now gone. Furthermore, I added some more dependencies. The minimal versions are are given by configure.ac from the Gnome Commander project. > Why do you need to enforce the +gsf flag? I didn't. This was a mistake, I set it back to "gsf". Thank you. I also created a metadata.xml file. Can somebody have a look at it?
Created attachment 374868 [details] gnome-commander-1.4.1.ebuild
Created attachment 374870 [details] metadata.xml This is my first trial of a metadata. A review would be nice.
(In reply to Uwe Scholz from comment #41) > Created attachment 374868 [details] > gnome-commander-1.4.1.ebuild I think this looks good now. Any reason you are filtering --as-needed? I see you are the upstream of the package, so maybe you can fix it? :)
(In reply to Uwe Scholz from comment #42) > Created attachment 374870 [details] > metadata.xml > > This is my first trial of a metadata. A review would be nice. Overall it looks ok. A few things are missing: 1) <herd>proxy-maintainers</herd> so we are CC'd on bugs too 2) <description>Proxy maintainer. Assign bugs to him</description> in your <maintainer> tags. This will inform the bug-wranglers to assign bugs to you. Minor issues anyway, so I will add it to the tree probably during the weekend.
Created attachment 375118 [details] metadata.xml Added <herd> and <description> tags in metadata.xml
Created attachment 375120 [details] gnome-commander-1.4.1.ebuild The --as-needed filter is a relict of the very first ebuild, created by the former maintainer Piotr. I wasn't sure what to do with it, so I inserted it again. (It was accidentally deleted by me in one of my first ebuilds). But now I checked the build process of the package with and without LDFLAGS="-Wl,--as-needed" and it runs without any error in both cases. Because of a statement here (1) it is okay to remove it now, as you suggested, Markos. (1) https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed#How_to_use_--as-needed
(In reply to Uwe Scholz from comment #46) > Created attachment 375120 [details] > gnome-commander-1.4.1.ebuild > > The --as-needed filter is a relict of the very first ebuild, created by the > former maintainer Piotr. I wasn't sure what to do with it, so I inserted it > again. (It was accidentally deleted by me in one of my first ebuilds). > > But now I checked the build process of the package with and without > LDFLAGS="-Wl,--as-needed" and it runs without any error in both cases. > Because of a statement here (1) it is okay to remove it now, as you > suggested, Markos. > > (1) > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed#How_to_use_- > -as-needed The autotools eclass needs to be removed because you do not use it at all. Also, it seems the dependencies are not correct. I am getting this when I am trying to build it here. configure: error: Package requirements ( unique-1.0 >= 0.9.3 ) were not met: No package 'unique-1.0' was found
Created attachment 375888 [details] gnome-commander-1.4.1.ebuild (In reply to Markos Chandras from comment #47) > The autotools eclass needs to be removed because you do not use it at all. Done. Thanks for the hint. > Also, it seems the dependencies are not correct. I am getting this when I am > trying to build it here. > > configure: error: Package requirements ( unique-1.0 >= 0.9.3 ) were not met: > > No package 'unique-1.0' was found The problem here was that portage installed libunique-3.x. I was faced with the same problem today. Two weeks ago it worked, I guess because of other dependencies in my system. GCMD is based on libunique 1.x, so I restrict the ebuild to use libunique slot 1. Installing GCMD should work now. Thanks for your time!
Created attachment 376206 [details, diff] repoman-stuff.patch I just call repoman (repoman full .) to check the ebuild. === RepoMan scours the neighborhood... ebuild.badheader 1 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: Invalid Gentoo/GPL License on line: 2 ebuild.minorsyn 2 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: Trailing whitespace error on line: 43 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: Trailing whitespace error on line: 51 inherit.deprecated 1 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: please migrate from 'python' to 'python-r1 / python-single-r1 / python-any-r1' on line: 9 === The "ebuild.badheader" and "ebuild.minorsyn" is fixed by the attached patch.
Created attachment 376208 [details, diff] repoman-stuff.patch I just call repoman (repoman full .) to check the ebuild. === RepoMan scours the neighborhood... ebuild.badheader 1 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: Invalid Gentoo/GPL License on line: 2 ebuild.minorsyn 2 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: Trailing whitespace error on line: 43 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: Trailing whitespace error on line: 51 inherit.deprecated 1 gnome-extra/gnome-commander/gnome-commander-1.4.1.ebuild: please migrate from 'python' to 'python-r1 / python-single-r1 / python-any-r1' on line: 9 === The stuff is fixed by the attached patch. You also need the python patch (or a better one) to build the package if you use python3 as system python interpreter.
Created attachment 376244 [details] gnome-commander-1.4.1.ebuild Thank you, I committed your patch. I didn't know the repoman-command till now. I chose python-r1 instead of python-single-r1 as the python plugins in Gnome Commander could run with more than one of the installed Python interpreters. I hope I got the choice right.
(In reply to Uwe Scholz from comment #51) > Created attachment 376244 [details] > gnome-commander-1.4.1.ebuild > > Thank you, I committed your patch. I didn't know the repoman-command till > now. > > I chose python-r1 instead of python-single-r1 as the python plugins in Gnome > Commander could run with more than one of the installed Python interpreters. > I hope I got the choice right. This looks good now. Can we also have a metadata.xml documenting the local use flags such as 'gsf'?
(In reply to Markos Chandras from comment #52) > (In reply to Uwe Scholz from comment #51) > > Created attachment 376244 [details] > > gnome-commander-1.4.1.ebuild > > > > Thank you, I committed your patch. I didn't know the repoman-command till > > now. > > > > I chose python-r1 instead of python-single-r1 as the python plugins in Gnome > > Commander could run with more than one of the installed Python interpreters. > > I hope I got the choice right. > > This looks good now. Can we also have a metadata.xml documenting the local > use flags such as 'gsf'? Sorry I missed the attached metadata.xml
+*gnome-commander-1.4.1 (03 May 2014) + + 03 May 2014; Markos Chandras <hwoarang@gentoo.org> + +gnome-commander-1.4.1.ebuild, +metadata.xml: + Initial commit thanks to Uwe Scholz <u.scholz83@gmx.de> on bug #231885. He + will also act as proxy-maintainer
Thanks Markos and Markus for you help with this. It's great to have GCMD in portage.
