Immediately after the update to 1.2,1 I noticed that tab completion behaves strange in conjunction with symlinks. $ bash --version GNU bash, version 4.1.7(1)-release (amd64-portbld-freebsd8.1) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> How-To-Repeat: $ mkdir -p /tmp/dir/x/y/z $ ln -s /tmp/dir /tmp/dir-link $ rsync -avP /tmp/dir-li<PRESS TAB> the shell completely freezes.
Responsible Changed From-To: freebsd-ports-bugs->adamw Over to maintainer (via the GNATS Auto Assign Tool)
State Changed From-To: open->feedback Thanks for reporting this unusual behaviour! I'm unable to replicate this. I have two 8-STABLE boxes, a 5.5-RELEASE, and I also tried it on two Macs (macports builds and installs in a similar manner), one running i386 and one x86_64. I'm unable to replicate it on any of those boxes. This could possibly be an amd64 problem, but I have no way of testing that. Also, does this only happen with rsync completion?
Looks like bug-followup@FreeBSD.org got dropped from the Cc: list somehow... On 6 September 2010 09:38, Emanuel Haupt <ehaupt@freebsd.org> wrote: > It seems to be directly related to the rsync completion definition. If > I delete /usr/local/etc/bash_completion.d/rsync the problem is gone. > > Not sure if it's an amd64 issue - I have to see if I can find an i386 > installation somewhere. > > Emanuel Let me know what you find. Please also try it also on another amd64 machine, if you have access to one. In the meantime, should I exclude that file from installation on amd64? # Adam
Adam Weinberger <adamw@adamw.org> wrote: > Looks like bug-followup@FreeBSD.org got dropped from the Cc: list > somehow... > > > On 6 September 2010 09:38, Emanuel Haupt <ehaupt@freebsd.org> wrote: > > It seems to be directly related to the rsync completion definition. > > If I delete /usr/local/etc/bash_completion.d/rsync the problem is > > gone. > > > > Not sure if it's an amd64 issue - I have to see if I can find an > > i386 installation somewhere. > > > > Emanuel > > > Let me know what you find. Please also try it also on another amd64 > machine, if you have access to one. In the meantime, should I exclude > that file from installation on amd64? This seems to be indeed related to amd64. I've tried the same on i386 and the problem didn't occur. Are you aware of a mechanism to exclude certain files by individual configuration from being sourced other than deleting them from /usr/local/etc/bash_completion.d/? A *quick* look at the area arround line 1612 of /usr/local/etc/bash_completion suggests not. Gentoo (oh wonder...) allows you to tweak which bash-completion definitions are sourced via bash-completion-config or eselect: http://www.gentoo-wiki.info/TIP_Use_TAB-completion_when_emerging_packages While I wouldn't hesitate to source every definition on a new machine I wouldn't want to do so on a slower machine because it can easily take 1-2 seconds to source all functions. One solution IMHO could be: - install additional definitions not in /usr/local/etc/bash_completion.d/ but in ${EXAMPLESDIR}/bash_completion.d/ - prompt a message to the user to manually copy wanted definitions to /usr/local/etc/bash_completion.d/ I haven't looked at bash-completion-config [1] yet, but maybe it could be used on FreeBSD as well. [1] http://cblfs.cross-lfs.org/index.php/Bash-completion-config What do you think? Emanuel
I'm not sure I understand the need for conditional loading, and for making users activate completions manually (even after following pkg-mesage). If it causes the shell to freeze, let's just leave it out on amd64 until it works.
The current system of putting files into ${PREFIX}/etc/bash_completion.d/ also lacks the ability to customize the files. If I add my own definitions updates will fail since: @dirrm etc/bash_completion.d Modified files will get removed and have plist checksum mismatches. Also, people with slow CPU's or people that find some completion schema annoying will have to remove the definition files every time the port gets updated.
adamw 2010-09-06 20:30:14 UTC FreeBSD ports repository Modified files: shells/bash-completion Makefile pkg-plist Log: The rsync completion plugin causes the shell to freeze on amd64. Until that gets resolved, I'm disconnecting the rsync plugin from the build on amd64. PR: ports/150322 Submitted by: ehaupt Revision Changes Path 1.21 +13 -2 ports/shells/bash-completion/Makefile 1.4 +1 -1 ports/shells/bash-completion/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Responsible Changed From-To: adamw->ehaupt
While I appreciate your architectural ideas, "does this file need to be disconnected from the build?" is more of a yes/no. I've committed a patch to drop the rsync plugin on amd64. I believe that resolves the issue in the ticket. I'm assigning the ticket over to you, so you can implement a configuration system if you'd like. Your issues seem to be with the inability to edit files installed by a port. I'm afraid I can't help you much there. The port makes it incredibly easy to create your own completions. If someone were so inclined, they could set up their own bash_completion.d directory of links, and modify files in there without disrupting the original files. $ mkdir ~/.completions $ ln -s /usr/local/etc/bash_completions.d/* ~/.completions $ echo "export BASH_COMPLETION_DIR=~/.completions" >> ~/.bashrc Solving everyone's problems isn't the responsibility of the ports tree.
State Changed From-To: feedback->open Other plugins such as ssh were found to hang on amd64. ports/150343 a repocopy of the older version was created to bring back the last working version as a seperate port. Keep this open to keep track of fixing the current version.
By the way, do you guys know whether these issues on amd64 have been reported upstream and wheter they are being worked on?
Adding bug-followup@ back to the CC list. At Sat, 23 Oct 2010 22:41:36 +0200, Emanuel Haupt wrote: > > Raphael Kubo da Costa <kubito@gmail.com> wrote: > > By the way, do you guys know whether these issues on amd64 have been > > reported upstream and wheter they are being worked on? > > Not yet. I haven't found the time to produce a useful bug report. > Please go ahead if you like to report it. Before reporting it upstream, I'm trying to debug it a little bit. Simply typing 'rsync <TAB>' here with the rsync completion, or 'scp <TAB>' cases the shell to freeze. Can you confirm that too?
At Sun, 24 Oct 2010 02:53:23 -0200, Raphael Kubo da Costa wrote: > Before reporting it upstream, I'm trying to debug it a little bit. > > Simply typing 'rsync <TAB>' here with the rsync completion, or 'scp > <TAB>' cases the shell to freeze. Can you confirm that too? Hmm, actually it seems to have already been reported upstream, even though nothing has been done yet: https://alioth.debian.org/tracker/index.php?func=detail&aid=312691&group_id=100114&atid=413095 If you use 'set -v' and 'set -x' and try to get completion for scp or rsync, you can see that the freeze occurs while waiting for something avahi-related. Indeed, if I start avahi-daemon via /usr/local/etc/rc.d/avahi-daemon, I don't get any freezes with rsync completion anymore.
At Sun, 24 Oct 2010 03:20:47 -0200, Raphael Kubo da Costa wrote: > Hmm, actually it seems to have already been reported upstream, even > though nothing has been done yet: > > https://alioth.debian.org/tracker/index.php?func=detail&aid=312691&group_id=100114&atid=413095 So my comment on the upstream bug report seems to have had some effect :) After http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=7d45595 avahi-browse is queried only if COMP_KNOWN_HOSTS_WITH_AVAHI is set (the default is unset). Adam, how about backporting this patch for now and make the port build again on amd64?
Raphael Kubo da Costa <kubito@gmail.com> wrote: > At Sun, 24 Oct 2010 03:20:47 -0200, > Raphael Kubo da Costa wrote: > > Hmm, actually it seems to have already been reported upstream, even > > though nothing has been done yet: > > > > https://alioth.debian.org/tracker/index.php?func=detail&aid=312691&group_id=100114&atid=413095 > > So my comment on the upstream bug report seems to have had some effect > :) Great work! Thanks a lot for tracking this! Emanuel
On Monday 25 October 2010 17:22:07 Emanuel Haupt wrote: > Raphael Kubo da Costa <kubito@gmail.com> wrote: > > At Sun, 24 Oct 2010 03:20:47 -0200, > >=20 > > Raphael Kubo da Costa wrote: > > > Hmm, actually it seems to have already been reported upstream, even > > > though nothing has been done yet: > > >=20 > > > https://alioth.debian.org/tracker/index.php?func=3Ddetail&aid=3D31269= 1&grou > > > p_id=3D100114&atid=3D413095 > >=20 > > So my comment on the upstream bug report seems to have had some effect > >=20 > > :) >=20 > Great work! Thanks a lot for tracking this! >=20 > Emanuel The following patch should prevent the issue from happening: it checks whet= her avahi-daemon is running=20 before calling avahi-browse, and was obtained from that same bug report I h= ave previously mentioned. It removes PORTREVISION, removes the MD5 sum from distinfo and the IGNORE f= or amd64. Could someone review and apply it? =2D-- bash-completion-fix-avahi-daemon.patch begins here --- diff -ruN --exclude=3DCVS /usr/ports/shells/bash-completion/Makefile /tmp/b= ash-completion/Makefile =2D-- /usr/ports/shells/bash-completion/Makefile 2010-09-20 20:09:06.000000= 000 -0300 +++ /tmp/bash-completion/Makefile 2010-11-18 23:37:03.000000000 -0200 @@ -7,7 +7,7 @@ =20 PORTNAME=3D bash-completion PORTVERSION=3D 1.2 =2DPORTREVISION=3D 1 +PORTREVISION=3D 2 PORTEPOCH=3D 1 CATEGORIES=3D shells MASTER_SITES=3D http://bash-completion.alioth.debian.org/files/ @@ -25,10 +25,6 @@ =20 .include <bsd.port.pre.mk> =20 =2D.if ${ARCH} =3D=3D "amd64" =2DBROKEN=3D Hostname completion on amd64 causes bash to freeze. Use shells= /bash-completion-classic=20 instead =2D.endif =2D post-patch: @${REINPLACE_CMD} -e 's|/usr/local|${PREFIX}|g; \ s|/etc/bash_completion|${PREFIX}&|g; \ diff -ruN --exclude=3DCVS /usr/ports/shells/bash-completion/distinfo /tmp/b= ash-completion/distinfo =2D-- /usr/ports/shells/bash-completion/distinfo 2010-09-04 14:51:46.000000= 000 -0300 +++ /tmp/bash-completion/distinfo 2010-11-18 23:43:05.000000000 -0200 @@ -1,3 +1,2 @@ =2DMD5 (bash-completion-1.2.tar.bz2) =3D 88c022a98a02a02293716f840eadd884 SHA256 (bash-completion-1.2.tar.bz2) =3D=20 dd09a86134204e4c6b860bfbd5ee8ac46c6b32a54478b967dcf81e8a7839d354 SIZE (bash-completion-1.2.tar.bz2) =3D 197574 diff -ruN --exclude=3DCVS /usr/ports/shells/bash-completion/files/patch-do_= not_hang_on_avahi_daemon=20 /tmp/bash-completion/files/patch-do_not_hang_on_avahi_daemon =2D-- /usr/ports/shells/bash-completion/files/patch-do_not_hang_on_avahi_da= emon 1969-12-31=20 21:00:00.000000000 -0300 +++ /tmp/bash-completion/files/patch-do_not_hang_on_avahi_daemon 2010-11-18= 23:51:50.000000000=20 =2D0200 @@ -0,0 +1,21 @@ +This patch is related to PR ports/150322. + +When avahi-daemon is not running, bash-completion will hang for some secon= ds +waiting for response from it because of the call to avahi-browse. + +The patch was originally obtained in bash-completion's bug tracker, and was +written by Ville Skytt=E4. + +Reference: https://alioth.debian.org/tracker/?func=3Ddetail&atid=3D413095&= aid=3D312691&group_id=3D100114 + +--- bash_completion 2010-06-16 12:44:20.000000000 -0300 ++++ bash_completion 2010-11-18 23:33:53.000000000 -0200 +@@ -1315,7 +1315,7 @@ + # avahi's services DB. We don't need the name of the service, and if = it + # contains ";", it may mistify the result. But on Gentoo (at least), + # -k isn't available (even if mentioned in the manpage), so... +- if type avahi-browse >&/dev/null; then ++ if type avahi-browse >&/dev/null && PATH=3D"$PATH:/sbin:/usr/sbin:/us= r/local/sbin" avahi-daemon -- check &>/dev/null; then + COMPREPLY=3D( "${COMPREPLY[@]}" $( \ + compgen -P "$prefix$user" -S "$suffix" -W \ + "$( avahi-browse -cpr _workstation._tcp 2>/dev/null | \ =2D-- bash-completion-fix-avahi-daemon.patch ends here ---
Sigh... Somehow the patch ended up looking completely garbled. Here's another attempt. --- bash-completion-fix-avahi-daemon.patch begins here --- diff -ruN --exclude=3DCVS /usr/ports/shells/bash-completion/Makefile /tmp/b= ash-completion/Makefile --- /usr/ports/shells/bash-completion/Makefile 2010-09-20 20:09:06.00000000= 0 -0300 +++ /tmp/bash-completion/Makefile 2010-11-18 23:37:03.000000000 -0200 @@ -7,7 +7,7 @@ =20 PORTNAME=3D bash-completion PORTVERSION=3D 1.2 -PORTREVISION=3D 1 +PORTREVISION=3D 2 PORTEPOCH=3D 1 CATEGORIES=3D shells MASTER_SITES=3D http://bash-completion.alioth.debian.org/files/ @@ -25,10 +25,6 @@ =20 .include <bsd.port.pre.mk> =20 -.if ${ARCH} =3D=3D "amd64" -BROKEN=3D Hostname completion on amd64 causes bash to freeze. Use shells/b= ash-completion-classic instead -.endif - post-patch: @${REINPLACE_CMD} -e 's|/usr/local|${PREFIX}|g; \ s|/etc/bash_completion|${PREFIX}&|g; \ diff -ruN --exclude=3DCVS /usr/ports/shells/bash-completion/distinfo /tmp/b= ash-completion/distinfo --- /usr/ports/shells/bash-completion/distinfo 2010-09-04 14:51:46.00000000= 0 -0300 +++ /tmp/bash-completion/distinfo 2010-11-18 23:43:05.000000000 -0200 @@ -1,3 +1,2 @@ -MD5 (bash-completion-1.2.tar.bz2) =3D 88c022a98a02a02293716f840eadd884 SHA256 (bash-completion-1.2.tar.bz2) =3D dd09a86134204e4c6b860bfbd5ee8ac46= c6b32a54478b967dcf81e8a7839d354 SIZE (bash-completion-1.2.tar.bz2) =3D 197574 diff -ruN --exclude=3DCVS /usr/ports/shells/bash-completion/files/patch-do_= not_hang_on_avahi_daemon /tmp/bash-completion/files/patch-do_not_hang_on_av= ahi_daemon --- /usr/ports/shells/bash-completion/files/patch-do_not_hang_on_avahi_daem= on 1969-12-31 21:00:00.000000000 -0300 +++ /tmp/bash-completion/files/patch-do_not_hang_on_avahi_daemon 2010-11-18= 23:51:50.000000000 -0200 @@ -0,0 +1,21 @@ +This patch is related to PR ports/150322. + +When avahi-daemon is not running, bash-completion will hang for some secon= ds +waiting for response from it because of the call to avahi-browse. + +The patch was originally obtained in bash-completion's bug tracker, and was +written by Ville Skyttä. + +Reference: https://alioth.debian.org/tracker/?func=3Ddetail&atid=3D413095&= aid=3D312691&group_id=3D100114 + +--- bash_completion 2010-06-16 12:44:20.000000000 -0300 ++++ bash_completion 2010-11-18 23:33:53.000000000 -0200 +@@ -1315,7 +1315,7 @@ + # avahi's services DB. We don't need the name of the service, and if = it + # contains ";", it may mistify the result. But on Gentoo (at least), + # -k isn't available (even if mentioned in the manpage), so... +- if type avahi-browse >&/dev/null; then ++ if type avahi-browse >&/dev/null && PATH=3D"$PATH:/sbin:/usr/sbin:/us= r/local/sbin" avahi-daemon --check &>/dev/null; then + COMPREPLY=3D( "${COMPREPLY[@]}" $( \ + compgen -P "$prefix$user" -S "$suffix" -W \ + "$( avahi-browse -cpr _workstation._tcp 2>/dev/null | \ --- bash-completion-fix-avahi-daemon.patch ends here ---
At Fri, 19 Nov 2010 00:10:07 -0200, Raphael Kubo da Costa wrote: > Sigh... Somehow the patch ended up looking completely garbled. Here's > another attempt. Oh well. I guess the patch will never look 100% here, as bug-followup does not seem to look quoted-printable emails, and the patch has UTF-8 characters in it. I have uploaded it to http://people.profusion.mobi/~kubo/freebsd/bash-completion-fix-avahi-daemon.patch
Not the first patch to be eaten by gnats or the mailing list software :) Great sleuthing work, Raphael! Thanks for putting this patch together. Emanuel, when you have some spare cycles can you please test this patch out? Thanks buddy!
I can confirm that the patch submitted by Raphael solves the problem. Nice work and thanks for tracking this! I will remove shells/bash-completion-classic a week after this patch is commited.
Responsible Changed From-To: ehaupt->adamw Over to maintainer of shells/bash-completion.
adamw 2010-11-21 02:48:14 UTC FreeBSD ports repository Modified files: shells/bash-completion Makefile distinfo Added files: shells/bash-completion/files patch-do_not_hang_on_avahi_daemon Log: This patch hopefully fixes bash freezing on amd64 when using host-based completions. Tons of thanks to Raphael Kubo da Costa for identifying the fix and providing us with a patch, and to ehaupt for testing! PR: ports/150322 Submitted by: Raphael Kubo da Costa <kubito@gmail.com> Reviewed by: ehaupt Revision Changes Path 1.23 +1 -5 ports/shells/bash-completion/Makefile 1.15 +0 -1 ports/shells/bash-completion/distinfo 1.1 +21 -0 ports/shells/bash-completion/files/patch-do_not_hang_on_avahi_daemon (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Responsible Changed From-To: adamw->ehaupt Thanks for the testing, Emanuel! I've committed the patch, without modification. I'm transferring this PR back to you so you can decide what to do with bash-completion-classic. Is it redundant now, or is it worth leaving in the tree as a second option for people?
Thanks, Emanuel. I've committed the patch, and transferred the PR back to you. I know you indicated an intent to remove -classic in a week if there are no reported problems with this update. If you do decide that it's worth leaving in the tree as a second option for people, please send me a little blurb to add to pkg-descr so we can inform users of the difference.
State Changed From-To: open->closed Port now works as expected.