tla (dev-util/tla-1.2-r2) don't close data socket's file descriptor, when it didn't find file on ftp server. This can leed to error 227, when accessing large archive. Problem is missing close around line 539 or 1653 in src/tla/libarch/pfs-ftp.c. Reproducible: Always Steps to Reproduce: 1. Build archive with over 1024 versions (or lower ulimit -n). 2. tla abrowse --merges -s -A archive--on--ftp Actual Results: ftp_client_get: error getting file /bluestar/tla/tla--scripts/tla--scripts--1.0/patch-19/log 227: Too many open files Expected Results: Finish abrowse. Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.4.26) ================================================================= System uname: 2.4.26 i686 AMD Duron(tm) Processor Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=athlon -march=i686 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=athlon -march=i686 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox" GENTOO_MIRRORS="http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/hda04/gentoo-var-tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib apache2 apm arts avi berkdb caps cdr crypt cups curl dga divx4linux doc dvd encode esd flac foomaticdb gcj gd gdbm gif gpm gtk gtk2 imagemagick imlib innodb ipv6 java jpeg lcms lesstif libcaca libg++ libwww mad mbox mcal memlimit mikmod mmx mng motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang snmp spell sqlite sse ssl svga tcltk tcpd tetex theora tiff truetype unicode usb vhosts videos wmf x86 xml xml2 xmms xosd xv xvid zlib" Ftp server is wu-ftpd, but I don't think it can make a difference.
I checked the source of the 1.2.1 tarball (see bug #61120) and it doesn't seem to fix it.
It appears that the 1.2.2rc1 (due soon) will fix it: patch-21 FD leak in ps_ftp (Cvetkovic)
1.2.2_rc1 in cvs should fix this. Please reopen if it doesn't.
tla-1.3 still leaks file descriptors ... I didn't checked source file if it's same problem, but assume so.
1.3.3 is in the tree... If this problem persists we need to contact upstream.
Yes, it still has same problem. You mean you didn't contact upstream yet ?
I contact the actual maintainer of tla on gnuarch user to report this bug
Re-assign wrt Bug 136369.
Re-assign wrt Bug 51665; this now lacks a maintainer.
And someone check w/ 1.3.5 please...
Yes, 1.3.5 still leaks ...
Cleaners, I request a vote for this package. This particular bug has not been fixed, GPNL reports no maintainer and no herd. Also it has other open bugs [1] http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=allwords&short_desc=tla&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED [2] http://spaceparanoids.org/gentoo/gpnl/package.php?cat=dev-util&pkg=tla [3] antarus@kyoto ~/gentoo/portage/private/antarus/glep42/eselect $ pquery --raw --revdep=dev-util/tla app-emacs/xtla-0.1_p525 app-emacs/xtla-0.9_p38 app-emacs/xtla-1.0 app-emacs/xtla-1.1 app-emacs/xtla-1.2 dev-util/archway-0.1.1 dev-util/archway-0.2.0 dev-util/archway-0.2.1
Addition, someone from xemacs informs me that xetla also depends on tla.
+1
(In reply to comment #12) > Cleaners, I request a vote for this package. /me votes No > This particular bug has not been fixed, GPNL reports no maintainer and no herd. Like all the other maintainer-needed packages? > Also it has other open bugs > > [1] > http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=allwords&short_desc=tla&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Two of these are requests for new ebuilds, one is a stabilization bug, one is about an eclass, one is about bundled libs being a theoretical security problem, and the last one is this one :) That looks like two real bugs to me, and one is about an eclass unrelated to the package. Upstream still seems to be putting out releases, so it's not like this package is dead, just unmaintained downstream. (Note: please remember to add m-needed to CC when re-assigning a bug to treecleaners) Although arch looks like it could do w/ some tlc, this bug looks trivial to solve. I'll do it.
ping?
(In reply to comment #16) > ping? Well, pinging a developer who's retiring won't fix this I'm afraid, see Bug 153940. With upstream apparently unable to fix the issue, I'm voting for removal again.
+1, nos vamos. Sorry, Ryan.
+1 and masking
did this ever get masked?
(In reply to comment #21) > did this ever get masked? > We still need solutions for: Reverse RDEPEND for dev-util/tla: app-emacs/xtla-1.2.1 dev-util/archway-0.1.1 dev-util/archway-0.2.0 dev-util/archway-0.2.1 I fixed archway ebuilds in bug #230605 @emacs team: Is there a solution for xtla?
(In reply to comment #22) > @emacs team: Is there a solution for xtla? If you are really into removing tla, I agree to let xtla vanish, too. xtla is not really usable, while we have working support for many of the dVCS in Emacs 23 (still in progress). Emacs 23 will not appear before the end of this year I think, the successor of xtla, named dcs (in the Emacs overlay), is not usable either (no releases, just a live ebuild)... So if it is a affair of the heart for you, go on for both.
(In reply to comment #23) > So if it is a affair of the heart for you, go on for both. Masked. Thanks for the response. # Jeremy Olexa <darkside@gentoo.org> (3 Jul 2008) # Masked for removal in ~30 days by treecleaners. bug #59548 # dev-util/tla leaks file descriptors. app-emacs/xtla is not usable and depends # on tla. Please visit the emacs overlay for an alternative. dev-util/tla app-emacs/xtla
(In reply to comment #24) > # Jeremy Olexa <darkside@gentoo.org> (3 Jul 2008) > # Masked for removal in ~30 days by treecleaners. bug #59548 > # dev-util/tla leaks file descriptors. app-emacs/xtla is not usable and depends > # on tla. Please visit the emacs overlay for an alternative. Please adjust your comment: Use >=app-editors/emacs-cvs-23 or app-emacs/dvc (from the Emacs overlay) as a replacement.
(In reply to comment #25) > Please adjust your comment: Use >=app-editors/emacs-cvs-23 or app-emacs/dvc > (from the Emacs overlay) as a replacement. Done. Thanks for the tip.
That doesn't seem as convincing reason for removing, considering the fact you can still use local archives, sftp or webdav (or plain http for read-only access). I though the main reason is something as "tla is not actively developed upstream", which may not even be true.
(In reply to comment #27) > That doesn't seem as convincing reason for removing, considering the fact you > can still use local archives, sftp or webdav (or plain http for read-only > access). I though the main reason is something as "tla is not actively > developed upstream", which may not even be true. > The problem is really two-fold, IMO. 1) This bug has been open since 2004 with no resolution. A few attempts have been made to fix it but have failed. Comment #4 & #6. and 2) No one from Gentoo seems to be interested maintaining it (or fixing the other open bug on it) If you have a valid fix, please do contribute and 'save' this package. Although from the package description there are many alternatives to this package (not sure though). Upstream's last release was in 2006 =/. I'm not sure what to tell you, besides "patches welcome" - but that is too cliche for me ;)
I was arguing about the reason (written by Jeremy Olexa), not about removing. Although I'm not convinced upstream know about this bug, I agree that developement of tla is very slow and the fact that original author is now working on different, "better" version control system is not promising. On the other hand, for peoples who already have archives in this format (like me, of course) converting them to different one is not easy task. I would not recomend tla for new peoples/projects, so masking this (as a sort of heavy warning) makes sense. While originally (in 2004) I though this bug is trivial, later I actually tried to solve it and found that finding where exactly should the descriptor be closed is not so simple. Personally, I chose to use other methods of accessing archives - the local one, to be exact (with fuse it doesn't really need to be local).
Found it, upstream really was notified: http://lists.gnu.org/archive/html/gnu-arch-users/2006-02/msg00092.html
Note: both bzr (althrough only with help of masked bazaar and PyBaz which is not in portage) and mercurial (althrough not with sane symlink support as of dev-util/mercurial-0.9.5-r1) supports automatic import of tla/gnuarch archives WITH HISTORY. (Other tools might have same abilities, this two I've tested.) Perhaps it would be good idea to add this information to the comment/reason.
(In reply to comment #31) > Note: both bzr (althrough only with help of masked bazaar and PyBaz which is > not in portage) and mercurial (althrough not with sane symlink support as of > dev-util/mercurial-0.9.5-r1) supports automatic import of tla/gnuarch archives > WITH HISTORY. (Other tools might have same abilities, this two I've tested.) > Perhaps it would be good idea to add this information to the comment/reason. > Thanks for the information and testing. Hopefully your comment is useful to someone in the future.
sad news. these bugs are hardly enough reason to switch all archives to another SCM :) would it be against some policy to move dev-util/tla to some public overlay, e.g. sunrise (i can do that)?
(In reply to comment #33) > sad news. these bugs are hardly enough reason to switch all archives to another > SCM :) But for maintenance it is...the problem aren't the bugs per se but the unresponsiveness of upstream. Also Bazaar is now the official GNU SCM, obsoleting tla in a way. > would it be against some policy to move dev-util/tla to some public overlay, > e.g. sunrise (i can do that)? No.
i have put the dev-util/tla-1.3.5.ebuild into sunrise. once tla is removed from tree this bug could turn into maintainer-wanted bug for tla.
(In reply to comment #35) > once tla is removed from tree this bug could turn into maintainer-wanted bug > for tla. or an UPSTREAM-wanted? Really, if anyone knows how to fix this and can confirm that the issue is fixed...we can patch it and 'save' tla. Also, I'm pushing out the removal date by 30 days. I screwed up on that one and it will give more time for someone to step up and fix it if they would like.
removed from tree.
reopen for maintainer-wanted (for ebuild in sunrise)
This is dead upstream now too. http://savannah.gnu.org/projects/gnu-arch/ http://lists.gnu.org/archive/html/gnu-arch-users/2008-03/msg00003.html Let's put it to rest.
