Bugzilla Bug 33478

this is a nice filemanager using gtk2, its very light and functionel.
i suggest app-misc/tuxcmd, this ebuild works perfectly and could very well be added directly into portage

Created an attachment (id=20746) [details]
tuxcmd-0.5.70.ebuild

this is the ready ebuild

*** Bug 33844 has been marked as a duplicate of this bug. ***

Source is available for tux commander, though a gtk2forpascal is needed. 

Tux commander is a kylix project, it's not possible to compile it with fpc(
from tuxcmd's main developper).
I suggest to commit the binary based ebuild.

Created an attachment (id=27238) [details]
Ebuild for tuxcmd-bin-0.4.101

this is just a up to date ebuild, with correction on the ebuild's
name,dependencies and some cosmetics changes.

Binary only, similar to other packages already in Portage... I'm not interested
in
maintaining this one.

Created an attachment (id=38418) [details]
updated ebuild to new development version and added installation of plugins

(From update of attachment 38418 [details])
updated ebuild to new development version and added installation of plugins

When will this ebuild be in portage?

@abcdefg: I guess you read Comment #6 ?

Sorry, I'm afraid I don't understand.

@Brandon Hale:

Similar to what packages in portage? I don't know much about ebuilds and portage but if the ebuild works why not add it?

I just saw this filemanager on a screenshot and wanted to try it. I also don't
understand why this ebuild should not be added to the portage tree. People that
don't like binary should not use it, but all other should have the chance to.
It can't be that the missing interest of one developer makes this fail. What a
distri would gentoo be when it didn't include binary only like realplayer,
acroread, nvidia....?

I agree. This piece of software is written in Kylix so it won't gain anything
from recompiling (here are no arch specyfic optimalizations). Creating a source
based package wouldn't make sense. IMHO this should go to portage long time ago.

I agree. This piece of software is written in Kylix so it won't gain anything
from recompiling (here are no arch specyfic optimalizations). Creating a source
based package wouldn't make sense. IMHO this should go to portage long time ago.

http://forums.gentoo.org/viewtopic-t-308672-highlight-tux+commander.html
Here you'll find some users point of view.

*** Bug 112570 has been marked as a duplicate of this bug. ***

Created an attachment (id=88352) [details]
tuxcmd-0.5.88.ebuild

*** Bug 146657 has been marked as a duplicate of this bug. ***

Created an attachment (id=128552) [details]
Offical ebuilds for Tux Commander

Atttached you can find official ebuilds for the latest stable release (v
0.5.103). From now on every new release will come with updated ebuilds. Feel
free to include it in general Portage tree.

There are three ebuilds available:
 # tuxcmd-bin - main application, binaries only (still requires Kylix to
compile, will change for 0.6.x releases)
 # tuxcmd-modules - modules built from source (C, C++)
 # tuxcmd-modules-bin - binary modules (use when troubles compiling from
source)

Reopening, and reassigning to maintainer-wanted..

Either find a maintainer, or if you want to maintain it yourself, feel free to
reopen and join project sunrise, details here:

http://www.gentoo.org/proj/en/sunrise

Thanks. 

WONTFIX.

*** Bug 203049 has been marked as a duplicate of this bug. ***

tuxcmd 0.6.x now require freepascal, 0.6.50 was released on 2008-10-03, and
project is actively developed. It has support for vfs and uses gnome's new
gvfs, has support for archive browsing, it is the only file manager I found
that can do this (besides krusader for kde and mc which I still use). Now, I
know this is a really old bug but you still have official ebuilds with each
release and this is no longer -bin app... My guess is that maintainer would
need only to check new releases and new ebuilds (if maintainer likes this kind
of file managers).

Created an attachment (id=188276) [details]
tuxcmd-bin-0.6.50.ebuild

version bump from previous one, and fixed to
mirror://sourceforge/tuxcmd/tuxcmd-${PV}-bin-i386.tar.bz2"

(From update of attachment 188276 [details])
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# inspired by peazip-1.8.2.ebuild -
http://bugs.gentoo.org/show_bug.cgi?id=178716

inherit eutils

DESCRIPTION="Tux Commander - Fast and Small filemanager using GTK2"
HOMEPAGE="http://tuxcmd.sourceforge.net/"
SRC_URI="mirror://sourceforge/tuxcmd/tuxcmd-${PV}-bin-i386.tar.bz2"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86 -*" # binary distribution, won't work on other arches (possible
amd64 but not tested yet)
RESTRICT="strip"

DEPEND=""
RDEPEND=">=x11-libs/gtk+-2.4.0
         >=dev-libs/glib-2.4.0
         >=x11-libs/pango-1.4.0"

S="${WORKDIR}/${P}"

src_compile() {
        einfo "This is a binary package, no compilation needed"
}

src_install() {
        cd "${WORKDIR}/tuxcmd-${PV}-bin-i386"

#       dobin ${WORKDIR}/tuxcmd

        insinto /opt/tuxcmd
        doins -r ./*

        exeinto /opt/tuxcmd
        doexe tuxcmd

        dosym /opt/tuxcmd/tuxcmd /bin/tuxcmd || die "install failed"
}