Version 28.1
Hi Robert,
Robert Pluim writes:
> Michael> Michael Albinus writes:
> Michael> Hi Robert,
>
> >>> Thanks for that. It works for me now with emacs-27 (but not on
> master).
> >>
> >> Thanks for the feedba
Michael Albinus writes:
Hi Robert,
>> Thanks for that. It works for me now with emacs-27 (but not on master).
>
> Thanks for the feedback. My patch is dedicated to the emacs-27 branch
> only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
> prepar
Robert Pluim writes:
> Thanks for that. It works for me now with emacs-27 (but not on master).
Thanks for the feedback. My patch is dedicated to the emacs-27 branch
only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
prepare a similar patch for master.
One step after the ot
Robert Pluim writes:
Hi Robert,
> Michael> The appended patch should fix it. It is towards the emacs-27
> Michael> branch. Although there won't be a Tramp 27.3 in the future,
> Debian (and
> Michael> other distributions) might patch its distributed Emacs 27.2.
>
> emacs-27 is still
Michael Albinus writes:
Hi,
>> Michael, this is emacs signalling an error for a recursive load,
>> apparently forever.
>
> Ahh, thanks. This gives me some ideas for check.
The appended patch should fix it. It is towards the emacs-27
branch. Although there won't be a T
Robert Pluim writes:
Hi Robert,
> I have a backtrace from gdb that might shed some light.
>
> Michael, this is emacs signalling an error for a recursive load,
> apparently forever.
Ahh, thanks. This gives me some ideas for check.
> Robert
Best regards, Michael.
Lars Ingebrigtsen writes:
Hi Lars,
>>> My emacs get stuck with 100% cpu when started from a directory ending with
>>> ".tar".
Sure, this is the Tramp archive handler. But it shall be invoked only
when the file name ends with ".tar/" - see the trailing slash.
>>> For example, the following comm
Package: libdebbugs-perl
Severity: wishlist
Dear Maintainer,
When querying bug status, the field fixed_date is not set. We would
like to use it for statistical reasons. (Similar for found_date, but
less important.)
Furthermore, there doesn't seem to exist a data field telling when a
bug has been
Don Armstrong writes:
Hi Don,
>> Good idea. Shall I raise a (wishlist) bug report about?
>
> There's a wishlist bug for it right now:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712979
Thanks. I've just subscribed to this bug.
> I like this approach better, but I'd suggest that we do s
Don Armstrong writes:
> 1) Returning large attachments in get_mail_log() would be fairly
> surprising to existing users of that interface; it should really return
> some kind of record of the MIME structure which could then be retrieved
> using a second interface
>
> 2) MIME messages are much mor
Don Armstrong writes:
Hi Don,
> There are two main reasons why I didn't really complete this part of the
> interface:
>
> 1) Returning large attachments in get_mail_log() would be fairly
> surprising to existing users of that interface; it should really return
> some kind of record of the MIME s
Don Armstrong writes:
Hi Don,
>> The get_bug_log operation of the SOAP API truncates some messages. For
>> example, look at the 4th message (indexing from 0) in bug 25235. In
>> the web interface,
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25235#17 , one can see
>> that the message has 2 p
Michael Albinus writes:
> Due to this wrong Content-Type: header, my Debbugs/SOAP client
> (debbugs.el from GNU Emacs) refuses to work for get_bug_log(25235).
This does not seem to be a bug in the debbugs server; it is rather a
problem in the soap-client.el package of Emacs. I've su
Hi,
> The get_bug_log operation of the SOAP API truncates some messages. For
> example, look at the 4th message (indexing from 0) in bug 25235. In the
> web interface, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25235#17 ,
> one can see that the message has 2 parts, but the get_bug_log SOAP
> op
Source: debbugs
Severity: normal
Dear Maintainer,
This bug has been reported to the GNU debbugs server, see
https://debbugs.gnu.org/32941>:
The get_bug_log operation of the SOAP API truncates some messages. For
example, look at the 4th message (indexing from 0) in bug 25235. In the
web interface
Sean Whitton writes:
> Dear mentors,
Hi Sean,
> I am looking for a sponsor for my package emacs-async.
>
> * Package name: emacs-async
> Version : 1.6
> Upstream Author : John Wiegley
> * URL : https://github.com/jwiegley/emacs-async
> * License : GPL-2+
>
gregor herrmann writes:
> Unfortunately this didn't turn out as expected, the issues with
> #635018 are still there with soap-lite 1.08 and your patch.
> Seems to be something different ...
Thanks for letting me know. If time permits, I'll check whether I can
reproduce the examples from #635018.
gregor herrmann writes:
> This reminds me of #635018 which is making my unhappy since I first
> stumbled over it; does this look like it's the same issue?
Yes, seems to be the same one according to message #15. You can simply
try my patch (or a different one) and see whether this is fixed as wel
Package: libdebbugs-perl
Severity: normal
Tags: patch
Dear Maintainer,
I'm reporting this to the debbugs installation on
debbugs.gnu.org. Don't know the version, but
/usr/share/perl5/SOAP/Transport/HTTP.pm reports $VERSION = 0.714;
When a soap request is send to that server, and the reponse cont
sh key dbus-return-values-table :ignore) :ignore)
>> (read-event nil nil 0.1))
>>
>> While the dbus message failure is ultimately a gnome issue, this
>> should fail more gracefully.
This piece of code has been changed:
revno: 108593
committer: Michael Albinus
bran
Joey Schulze <[EMAIL PROTECTED]> writes:
> Michael Albinus wrote:
>> > I received this via the Debian bug tracking system. Comments?
>>
>> That ought to be resolved in Tramp 2.1 already. I'll see whether I can
>> backport it to Tramp 2.0 (which
Sven Joachim <[EMAIL PROTECTED]> writes:
> Hello,
Hi,
> I received this via the Debian bug tracking system. Comments?
That ought to be resolved in Tramp 2.1 already. I'll see whether I can
backport it to Tramp 2.0 (which is used in Emacs 22).
However, I don't know how it could be distributed
Jari Aalto <[EMAIL PROTECTED]> writes:
> When searching a package:
>
> apt-cache search tramp
>
> The 1st line of debian/control::Description is displayed:
>
> remote file access in Emacs
Emacs != GNU Emacs. Tramp is also for XEmacs.
Furthermore, the update of Tramp is stalled in Debian
"Trent W. Buck" <[EMAIL PROTECTED]> writes:
> Recently, /sudo::/ stopped working on my home Debian Sid (unstable)
> workstation, even with -Q. My home network uses NIS and a
> root-squashed NFS /home. At work, also using NIS and root-squashed
> NFS /home, I cannot reproduce this problem on Debia
Romain Francoise <[EMAIL PROTECTED]> writes:
> I don't agree, removing emacs21 from the archive will not remove it
> from the users' systems so upgrading tramp will not suddenly install
> xemacs21. And forcing users to install emacs21 | xemacs21 alongside
> tramp on new installs is good, it will
Brett Carter <[EMAIL PROTECTED]> writes:
> Package: tramp
> Version: 1:2.0.55-1
> Severity: grave
> Justification: renders package unusable
>
> Using the xemacs21 package in unstable:
> ii xemacs21 21.4.20-2 highly customizable text editor
>
> Tramp fails to open a remote file via scp
Toby Speight <[EMAIL PROTECTED]> writes:
> Yes, this works for me. :-)
OK, I've committed the patch to Tramp CVS. Will appear with Tramp
2.0.55, which is planned for next week.
> Thanks for looking at this one.
Thanks for reporting, and best regards, Michael.
--
To UNSUBSCRIBE, email to [EM
Toby Speight <[EMAIL PROTECTED]> writes:
> I've just tried with "emacs -q" and I'm having trouble reproducing
> this. But in my main Emacs (same version, etc), it's failing. I have
> a lot more stuff running in my main one (Gnus, BBDB, w3, Mule-UCS,
> ...), so it's hard to pin down what's happen
Toby Speight <[EMAIL PROTECTED]> writes:
> Package: tramp
> Version: 1:2.0.54-2
> Severity: important
>
> Once Tramp is running, some commands fail - such as `M-,'
> (`tags-loop-continue'), which gives the following stack trace:
I see the problem in the backtrace, but I haven't been able to
repro
Romain Francoise <[EMAIL PROTECTED]> writes:
> Hmm, so this is not a bug in Tramp after all? Michael?
No, it isn't. I've added some words about zsh prompt setting into the
Tramp manual (in fact, this is the recipe I've pointed to). Will be
available with Tramp 2.0.54.
Best regards, Michael.
-
Tom Rauchenwald <[EMAIL PROTECTED]> writes:
> I had the same problem.
> I think the problem is this line:
>> # ^M^Msanctum ttypts/10 ~ #
This reminds me of a recent discussion on the emacs-devel mailing
list. Looks like you (and Jürgen, the original poster) are us
Reuben Thomas <[EMAIL PROTECTED]> writes:
> Using tramp to load multiple remote files with the same name, I found
> I kept getting "this file has an auto-recover file" messages. On
> investigation, this seemed not to be true; rather, for a file foo,
> tramp was using /tmp/#foo# as the auto-recover
=?utf-8?Q?J=C3=BCrgen?= Erhard <[EMAIL PROTECTED]> writes:
> And the *tramp...* buffer says
>
>
> # ^M^Msanctum ttypts/10 ~ #
>
> That's an empty line, then a sharp with space... the first ^M (an
> actual CR, not a "^M" ;) is in column 79. End of buffer is after
=?UTF-8?Q?J=C3=BCrgen?= Erhard <[EMAIL PROTECTED]> writes:
> To me it looks like it times out, and defaults to "Login failed" (even
> though the docs say you only get that when you get a login error from
> the target system, if I read the source right, it seems to be the
> default when it cannot r
"=?UTF-8?Q?J=C3=BCrgen?= A. Erhard" <[EMAIL PROTECTED]> writes:
> I only get a Login Failed after a while. Target machine is, well,
> same machine since it's the su: method. Password is correct.
>
> Disabling all (microscopic) customizations didn't change a thing.
Could you, please, apply "M-x
Hans-Josef Koehler <[EMAIL PROTECTED]> writes:
> Package: tramp
> Version: 1:2.0.52-2
>
> When I try to access a file on a remote Solaris-9-system via
> ssh-method I got the following error:
>
> tramp-handle-file-attributes: Wrong type argument: number-or-marker-p,
> illegal
>
> Accessing a file o
Romain Francoise <[EMAIL PROTECTED]> writes:
> Whoops, looks like Tramp 2.0.50 broke compatibility with emacs20, I
> think this change is the culprit:
>
> (tramp-set-auto-save-file-modes): Use octal integer code #o600
> instead of octal character code ?\600. The latter resulted in a
>
Ferenc Wagner <[EMAIL PROTECTED]> writes:
>>> And really,
>>>
>>> (file-modes "diag.txt") => nil
>>> (file-modes "/tmp/#diag.txt#") => 436
>>
>> That's what I suspected. The fix would be simple (call `set-file-modes´
>> only when `file-modes´ returns non-nil).
>>
>> Nevertheless, I'm curious to kn
Ferenc Wagner <[EMAIL PROTECTED]> writes:
> Debugger entered--Lisp error: (wrong-type-argument integerp nil)
> set-file-modes("/tmp/#diag.txt#" nil)
> tramp-set-auto-save-file-modes()
> run-hooks(auto-save-hook)
>
> And really,
>
> (file-modes "diag.txt") => nil
> (file-modes "/tmp/#diag.txt
Ferenc Wagner <[EMAIL PROTECTED]> writes:
> Hi,
Hi,
> if I leave my editor idle for a while, I start getting a beep every 30
> seconds accompanied with the message
>
> tramp-set-auto-save-file-modes: Wrong type argument: integerp, nil
>
> in my *Messages* buffer.
Could you, please, evaluate (se
Frédéric Bothamy <[EMAIL PROTECTED]> writes:
> Hello Michael and Jerome,
Hi Frédéric,
> The specific problem described is indeed solved with Tramp 2.0.48. But
> there is another one if I try to insert in a tramp buffer the result
> from a command, garbage is inserted. Here are the steps to repro
Michael Albinus <[EMAIL PROTECTED]> writes:
> Michael Albinus <[EMAIL PROTECTED]> writes:
>
>>> So, I guess I could make this into a wishlist bug for updating the
>>> permissions
>>> if they have been altered on the remote system? :-)
>>
&
Frédéric Bothamy <[EMAIL PROTECTED]> writes:
> Hello,
Hi,
> - I get the following error message in the *Messages* buffer:
> tramp-file-name-for-operation: unknown file I/O primitive: shell-command
>
> I found a message from Michael Albinus on emacs-pretest-bug mailing li
Jürgen A. Erhard <[EMAIL PROTECTED]> writes:
> http://lists.gnu.org/archive/html/tramp-devel/2005-02/msg2.html
>
> Found it through Google, I had the same error when trying to close Emacs.
>
> The microscopic patch fixed it.
Tramp 2.0.48 has been released, including that patch.
Best regards,
Michael Albinus <[EMAIL PROTECTED]> writes:
>> So, I guess I could make this into a wishlist bug for updating the
>> permissions
>> if they have been altered on the remote system? :-)
>
> I will check how Emacs 22 handles it (it has been changed there
> toget
Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:
>> Could you, please, check whether the auto-save file exists _before_
>> you start editing? The access rights will be set only creating that
>> file; afterwards they are not touched.
>
> Ah, OK, that probably does explain something. Something really wei
Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:
> Hi and thanks for the response!
Hi,
> As you might have seen, a mail to [EMAIL PROTECTED] opens a new bug, so you
> may not
> want to use that... :-)
I haven't seen a NEW bug, Debian's BTS should handle this the right
way I believe. But you're rig
Kjetil Kjernsmo <[EMAIL PROTECTED]> writes:
> Package: tramp
> Version: 1:2.0.47-1
> Severity: normal
> Tags: security
>
> I just noticed that when I edited a buffer /su::/etc/apache/axkit.conf
> and file /tmp/#axkit.conf# was created. axkit.conf is owned by root:root
> on my system, and is readab
48 matches
Mail list logo
