GNU bug report logs - #18924
visiting files in relocated Bazaar lightweight checkout

Previous Next

Package: emacs;

Reported by: Bernardo <bernardo.bacic <at> pobox.com>

Date: Sun, 2 Nov 2014 02:21:01 UTC

Severity: minor

Tags: notabug

Found in version 25.0.50

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18924 in the body.
You can then email your comments to 18924 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Sun, 02 Nov 2014 02:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernardo <bernardo.bacic <at> pobox.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 02 Nov 2014 02:21:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bernardo <bernardo.bacic <at> pobox.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; visiting files in Bazaar workarea
Date: Sun, 02 Nov 2014 12:44:56 +1100
There is a *lightweight* Bazaar checkout in my workarea and at present
there is no network connection to the Bazaar repository. If Emacs is
started with
  $ emacs -Q readme.txt

it tries to connect to the remote server using Tramp, the echo area
shows:

 Tramp: Waiting for prompts from remote shell

and after a ~1 minute timeout it stops trying, without loading the file.
The echo area shows:
  Process died

If the .bzr directory is renamed to something else, the file loads
normally.
A workaround that was suggested is not to use Bazaar lightweight
checkouts.

--
Rgds, Bernardo



In GNU Emacs 25.0.50.2 (i686-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2014-11-01 on deb
Repository revision: monnier <at> iro.umontreal.ca-20141031213535-qjsn4pytrlkd3uus
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux 7.7 (wheezy)

Configured using:
 `configure --with-gif=no'

Configured features:
XPM JPEG TIFF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_AU.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

Memory information:
((conses 8 74932 5741)
 (symbols 24 18021 0)
 (miscs 20 38 158)
 (strings 16 11090 3904)
 (string-bytes 1 295195)
 (vectors 8 9349)
 (vector-slots 4 394141 3268)
 (floats 8 71 255)
 (intervals 28 244 146)
 (buffers 520 11)
 (heap 1024 37047 410))




Changed bug title to 'visiting files in Bazaar lightweight checkouts with no net connection' from '25.0.50; visiting files in Bazaar workarea' Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Sun, 02 Nov 2014 02:24:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Sun, 02 Nov 2014 02:46:01 GMT) Full text and rfc822 format available.

Message #10 received at 18924 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Bernardo <bernardo.bacic <at> pobox.com>
Cc: 18924 <at> debbugs.gnu.org
Subject: Re: bug#18924: 25.0.50; visiting files in Bazaar workarea
Date: Sat, 01 Nov 2014 22:44:57 -0400
Bernardo wrote:

> There is a *lightweight* Bazaar checkout in my workarea and at present
> there is no network connection to the Bazaar repository. If Emacs is
> started with
>   $ emacs -Q readme.txt
>
> it tries to connect to the remote server using Tramp

I can't reproduce this. I did:

bzr checkout --lightweight bzr://bzr.savannah.nongnu.org/drupal-el/trunk

(A nice, tiny repository.)

Then disconnected from the net. emacs -Q drupal.el works fine.

I have no idea why Tramp would try to get involved. Perhaps it is
something specific to your configuration.

> A workaround that was suggested is not to use Bazaar lightweight
> checkouts.

Irrespective of this issue, I would certainly recommend just forgetting
that lightweight checkouts exist; but YMMV of course.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Sun, 02 Nov 2014 05:41:02 GMT) Full text and rfc822 format available.

Message #13 received at 18924 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Bernardo <bernardo.bacic <at> pobox.com>
Cc: 18924 <at> debbugs.gnu.org
Subject: Re: bug#18924: 25.0.50; visiting files in Bazaar workarea
Date: Sun, 02 Nov 2014 01:40:47 -0400
> There is a *lightweight* Bazaar checkout in my workarea and at present
> there is no network connection to the Bazaar repository. If Emacs is
> started with
>   $ emacs -Q readme.txt

> it tries to connect to the remote server using Tramp, the echo area
> shows:

If you (setq debug-on-error t debug-on-quit t) and hit C-g during this,
do you get a backtrace?  If so, can you show it to us?


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Sun, 02 Nov 2014 17:45:01 GMT) Full text and rfc822 format available.

Message #16 received at 18924 <at> debbugs.gnu.org (full text, mbox):

From: Bernardo <bernardo.bacic <at> pobox.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca> Glenn Morris <rgm <at> gnu.org>
Cc: 18924 <at> debbugs.gnu.org
Subject: Re: bug#18924: 25.0.50; visiting files in Bazaar workarea
Date: Sun, 02 Nov 2014 19:18:54 +1100
hi,

>
> If you (setq debug-on-error t debug-on-quit t) and hit C-g during this,
> do you get a backtrace?  If so, can you show it to us?
>

sure, see below for the backtrace; however, i've got some clues about
what's going on and if i'm right it's not really Emacs' problem but my
dodgy practice of copying the workareas around

so the wider picture is like this - at work we have a project with a
Bazaar repository sitting on a LAN PC and most of people using
'lightweight' Bazaar checkout (i.e. no local history of changes).

to complicate things further the application builds under both GNU/Linux
and Windows so people will have two checkouts in their respective OSes

i don't have access to office LAN from home and sometimes i zip the
whole workarea in order to (mostly) read code living in the dark corners
of the project that i know very little about; well i was convinced i've
zipped up the GNU/Linux workarea, but that's probably not the case; once
unzipped on my home Debian PC the .bzr points to a badly formed path
(i.e. starting with Windows drive letter + the ':' character which is
mapped to a network drive/directory) to the Bazaar repository; well, it
looks like this confuses the hell out of 'tramp' when trying to look at
this repository;

i'm fairly confident this is the cause of the problem; apologies for all
the confusion caused

i forgot all about the 'lightweight' checkout (it was fist performed
years ago when the project started) until Eli mentioned it in the
Emacs-Help group/list

not sure if you guys want to address this "issue" but here's the
backtrace as requested


Debugger entered--Lisp error: (quit)
  signal(quit nil)
  tramp-maybe-open-connection([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
  tramp-send-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil] "test 0 2>/dev/null; echo tramp_exit_status $?")
  tramp-send-command-and-check([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil] "test 0")
  tramp-get-test-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
  tramp-find-file-exists-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
  tramp-get-file-exists-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
  tramp-sh-handle-file-exists-p(#("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
  apply(tramp-sh-handle-file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
  tramp-sh-file-name-handler(file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
  apply(tramp-sh-file-name-handler file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
  tramp-file-name-handler(file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
  file-exists-p(#("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
  vc-bzr-working-revision("/home/one/Projects/Apple/Application/readme.txt")
  apply(vc-bzr-working-revision "/home/one/Projects/Apple/Application/readme.txt")
  vc-call-backend(Bzr working-revision "/home/one/Projects/Apple/Application/readme.txt")
  vc-working-revision("/home/one/Projects/Apple/Application/readme.txt" Bzr)
  vc-default-mode-line-string(Bzr "/home/one/Projects/Apple/Application/readme.txt")
  apply(vc-default-mode-line-string Bzr "/home/one/Projects/Apple/Application/readme.txt")
  vc-call-backend(Bzr mode-line-string "/home/one/Projects/Apple/Application/readme.txt")
  vc-mode-line("/home/one/Projects/Apple/Application/readme.txt" Bzr)
  vc-find-file-hook()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer readme.txt> "~/Projects/Apple/Application/readme.txt" nil nil "~/Projects/Apple/Application/readme.txt" (8653796 2065))
  find-file-noselect("/home/one/Projects/Apple/Application/readme.txt" nil nil nil)
  find-file("/home/one/Projects/Apple/Application/readme.txt")
  command-line-1(("--eval" "(setq debug-on-error t debug-on-quit t)" "readme.txt"))
  command-line()
  normal-top-level()


--
Rgds, Bernardo




Changed bug title to 'visiting files in relocated Bazaar lightweight checkout' from 'visiting files in Bazaar lightweight checkouts with no net connection' Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 03 Nov 2014 00:28:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Mon, 11 Nov 2019 14:23:02 GMT) Full text and rfc822 format available.

Message #21 received at 18924 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Bernardo <bernardo.bacic <at> pobox.com>
Cc: Glenn Morris <rgm <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 18924 <at> debbugs.gnu.org
Subject: Re: bug#18924: 25.0.50; visiting files in Bazaar workarea
Date: Mon, 11 Nov 2019 15:22:01 +0100
Hi Michael,

See below a bug report related to Tramp.  AFAICT, you never replied in
this discussion, so I'm not sure if it's on your radar or not.

Best regards,
Stefan Kangas

Bernardo <bernardo.bacic <at> pobox.com> writes:

> hi,
>
>>
>> If you (setq debug-on-error t debug-on-quit t) and hit C-g during this,
>> do you get a backtrace?  If so, can you show it to us?
>>
>
> sure, see below for the backtrace; however, i've got some clues about
> what's going on and if i'm right it's not really Emacs' problem but my
> dodgy practice of copying the workareas around
>
> so the wider picture is like this - at work we have a project with a
> Bazaar repository sitting on a LAN PC and most of people using
> 'lightweight' Bazaar checkout (i.e. no local history of changes).
>
> to complicate things further the application builds under both GNU/Linux
> and Windows so people will have two checkouts in their respective OSes
>
> i don't have access to office LAN from home and sometimes i zip the
> whole workarea in order to (mostly) read code living in the dark corners
> of the project that i know very little about; well i was convinced i've
> zipped up the GNU/Linux workarea, but that's probably not the case; once
> unzipped on my home Debian PC the .bzr points to a badly formed path
> (i.e. starting with Windows drive letter + the ':' character which is
> mapped to a network drive/directory) to the Bazaar repository; well, it
> looks like this confuses the hell out of 'tramp' when trying to look at
> this repository;
>
> i'm fairly confident this is the cause of the problem; apologies for all
> the confusion caused
>
> i forgot all about the 'lightweight' checkout (it was fist performed
> years ago when the project started) until Eli mentioned it in the
> Emacs-Help group/list
>
> not sure if you guys want to address this "issue" but here's the
> backtrace as requested
>
> Debugger entered--Lisp error: (quit)
>   signal(quit nil)
>   tramp-maybe-open-connection([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
>   tramp-send-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil] "test 0 2>/dev/null; echo tramp_exit_status $?")
>   tramp-send-command-and-check([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil] "test 0")
>   tramp-get-test-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
>   tramp-find-file-exists-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
>   tramp-get-file-exists-command([#("scp" 0 3 (tramp-default t)) nil "H" "/Bzr/Apple/Application/.bzr/branch/format" nil])
>   tramp-sh-handle-file-exists-p(#("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>   apply(tramp-sh-handle-file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>   tramp-sh-file-name-handler(file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>   apply(tramp-sh-file-name-handler file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>   tramp-file-name-handler(file-exists-p #("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>   file-exists-p(#("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>   vc-bzr-working-revision("/home/one/Projects/Apple/Application/readme.txt")
>   apply(vc-bzr-working-revision "/home/one/Projects/Apple/Application/readme.txt")
>   vc-call-backend(Bzr working-revision "/home/one/Projects/Apple/Application/readme.txt")
>   vc-working-revision("/home/one/Projects/Apple/Application/readme.txt" Bzr)
>   vc-default-mode-line-string(Bzr "/home/one/Projects/Apple/Application/readme.txt")
>   apply(vc-default-mode-line-string Bzr "/home/one/Projects/Apple/Application/readme.txt")
>   vc-call-backend(Bzr mode-line-string "/home/one/Projects/Apple/Application/readme.txt")
>   vc-mode-line("/home/one/Projects/Apple/Application/readme.txt" Bzr)
>   vc-find-file-hook()
>   run-hooks(find-file-hook)
>   after-find-file(nil t)
>   find-file-noselect-1(#<buffer readme.txt> "~/Projects/Apple/Application/readme.txt" nil nil "~/Projects/Apple/Application/readme.txt" (8653796 2065))
>   find-file-noselect("/home/one/Projects/Apple/Application/readme.txt" nil nil nil)
>   find-file("/home/one/Projects/Apple/Application/readme.txt")
>   command-line-1(("--eval" "(setq debug-on-error t debug-on-quit t)" "readme.txt"))
>   command-line()
>   normal-top-level()
>
>
> --
> Rgds, Bernardo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Mon, 11 Nov 2019 15:01:02 GMT) Full text and rfc822 format available.

Message #24 received at 18924 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Glenn Morris <rgm <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Bernardo <bernardo.bacic <at> pobox.com>, 18924 <at> debbugs.gnu.org
Subject: Re: bug#18924: 25.0.50; visiting files in Bazaar workarea
Date: Mon, 11 Nov 2019 15:59:34 +0100
Stefan Kangas <stefan <at> marxist.se> writes:

> Hi Michael,

Hi Stefan,

> See below a bug report related to Tramp.  AFAICT, you never replied in
> this discussion, so I'm not sure if it's on your radar or not.

No, this bug report is new to me. Due to limited time, I don't read all
bug reports. They get my attention if they have a buzzword in their
headline, like "tramp" or "remote".

Or if somebody points me to this :-)

I believe the OP gave already a proper analysis. Due to the way he has
handled his bazaar repository (copying from an MS Windows host to a
GNU/Linux host), he has wrong file names. In the backtrace, we see

>>   file-exists-p(#("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))

Tramp has been involved due to the drive letter "H:", interpreting it as
host name.

After all, it looks like a pilot error. I would close it as notabug.

> Best regards,
> Stefan Kangas

Best regards, Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18924; Package emacs. (Mon, 11 Nov 2019 15:17:02 GMT) Full text and rfc822 format available.

Message #27 received at 18924 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Glenn Morris <rgm <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Bernardo <bernardo.bacic <at> pobox.com>, 18924 <at> debbugs.gnu.org
Subject: Re: bug#18924: 25.0.50; visiting files in Bazaar workarea
Date: Mon, 11 Nov 2019 16:16:02 +0100
tags 18924 + notabug
close 18924
thanks

Michael Albinus <michael.albinus <at> gmx.de> writes:

> No, this bug report is new to me. Due to limited time, I don't read all
> bug reports. They get my attention if they have a buzzword in their
> headline, like "tramp" or "remote".
>
> Or if somebody points me to this :-)

OK.  I'll just point you to it if I see any other tramp related bugs
in the future. :-)

> I believe the OP gave already a proper analysis. Due to the way he has
> handled his bazaar repository (copying from an MS Windows host to a
> GNU/Linux host), he has wrong file names. In the backtrace, we see
>
>>>   file-exists-p(#("/scp:H:/Bzr/Apple/Application/.bzr/branch/format" 1 4 (tramp-default t)))
>
> Tramp has been involved due to the drive letter "H:", interpreting it as
> host name.
>
> After all, it looks like a pilot error. I would close it as notabug.

Thanks for taking a look.  I'll close it now.

Best regards,
Stefan Kangas




Added tag(s) notabug. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Mon, 11 Nov 2019 15:17:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 18924 <at> debbugs.gnu.org and Bernardo <bernardo.bacic <at> pobox.com> Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Mon, 11 Nov 2019 15:17:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 10 Dec 2019 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 109 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.