Bug#988581: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
Rob Browning writes:
>> My emacs get stuck with 100% cpu when started from a directory ending with
>> ".tar".
>>
>> For example, the following commands trigger the error:
>> - mkdir test.tar
>> - cd test.tar
>> - emacs
I can reproduce this on Debian/bullseye on the trunk, too -- Emacs uses
100% CPU and can't be interrupted with `C-g'.
strace seems to say that it's inflooping like this:
pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) =
15
[pid 70536] fstat(15, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(15, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 512) = 512
[pid 70536] lseek(15, 0, SEEK_SET) = 0
[pid 70536] newfstatat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc",
{st_mode=S_IFREG|0644, st_size=24503, ...}, 0) = 0
[pid 70536] newfstatat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.el", {st_mode=S_IFREG|0644,
st_size=28504, ...}, 0) = 0
[pid 70536] fcntl(15, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
[pid 70536] fstat(15, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(15, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 4096) = 4096
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) =
16
[pid 70536] fstat(16, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(16, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 512) = 512
[pid 70536] lseek(16, 0, SEEK_SET) = 0
[pid 70536] newfstatat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.el", {st_mode=S_IFREG|0644,
st_size=28504, ...}, 0) = 0
[pid 70536] fcntl(16, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
[pid 70536] fstat(16, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(16, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 4096) = 4096
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) =
17
[pid 70536] fstat(17, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] close(17) = 0
[pid 70536] close(16) = 0
[pid 70536] close(15) = 0
[pid 70536] close(14) = 0
[pid 70536] close(13) = 0
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD,
"/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
I have not tried to debug further, but this strace seems to indicate
that this might be Tramp-related, so I've added Michael to the CCs --
perhaps it'll be immediately obvious to him what the problem is. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size
Eli Zaretskii writes: > I do: there's no bug here -- window-width is documented to return a > value in terms of the frame's canonical character width (i.e. it uses > the dimensions of the frame's default font). And that doesn't change > when you change the font only for a single buffer. > > However, window-width can be asked to return the value in pixels, if > someone wants that, and then one can compute the width in units of any > other, larger or smaller, font. > > IOW, if some applications produce unexpected or unpleasant effects > when the buffer text is resized, those applications need to be > sensitive to such resizing. But changing the semantics of a veteran > API like suggested here is a non-starter, as it would definitely break > gobs of existing code. Yeah, that's true. I had completely forgotten that C-x C-+ only affects the current buffer, so resizing the window on that command would be nonsensical. So I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size
積丹尼 Dan Jacobson writes: > Emacs needs to update window-width when the user updates the text size. I think that makes sense. Anybody got an opinion here? I'm not sure how this would be implemented, though. Where's the code that computes the pixel width upon startup? I guess that code would have to be run again to compute the new width... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Daniel Kahn Gillmor writes: > So in the scenario above, Bob's cert is still overall valid (because it > has a valid certification over the correct UserID+key from Alice), even > though the ca...@example.org UserID is invalid. > > I don't know mml-mode or elisp well enough to dig into the code and fix > this part of the problem quickly, but if someone has patches that i can > look at that would point to where it might be changed, i'd be happy to > try to review them. I'm also mostly unfamiliar with the mml encryption code, but perhaps Jens could take a peek at this? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.
Kurt Roeckx writes: > From what I understand, it is (or was) possible to configure > things in such a way that it uses s_client to set up SSL, even > when it's configured to use gnutls. You should never use s_client > for that. s_client is a debug tool. It does create an SSL > connection for you, but in an insecure way. Emacs has built-in TLS support these days, so s_client is only used if the user (for some weird reason or other) has built or installed a version of Emacs without TLS support. I think that should probably be removed, because it's less secure than users would expect. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#798817: bug#21519: Gnus displays remote html content by default
Lars Ingebrigtsen writes: > Rob Browning writes: > >>> Gnus displays remote HTML content, such as (tracking) images, by >>> default. I noticed this when reading [1] on debian-user@l.d.o. >>> >>> Most other mail clients (Evolution, Icedove) disallow remote content >>> by default and require explicit confirmation. I think gnus should >>> follow this example. >>> >>> Ansgar >>> >>> [1] >>> https://lists.debian.org/55f42a0a712cf_70bf3fc4828aabc09192...@prod-rs-r13.mail >> >> Additional information here: https://bugs.debian.org/798817 > > Gnus displays external images in newsgroups, but not in mail. Were you > reading a news group? More information was requested, but no response was given within a month, so I'm closing this bug report. If the problem still exists, please reopen this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#759400: bug#18392: Bug#759400: emacs24-nox: segfault when saving emacs lisp file
Rob Browning writes: > Stefan Monnier writes: > >> Could you check whether the same problem shows up for the 24.4 pretest >> (i.e. 24.3.93)? Also, worthwhile would be to test to see if building >> with different optimization settings changes the result. > > Of course, I should have done this initially, but I just tried a clean > emacs-24.4.tar.xz build, and assuming I didn't make any mistakes, that > worked fine, so I need to investigate further on the Debian side. > > Thanks for the help. Ok; closing this report in the Emacs bug tracker. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#798817: bug#21519: Gnus displays remote html content by default
Rob Browning writes: >> Gnus displays remote HTML content, such as (tracking) images, by >> default. I noticed this when reading [1] on debian-user@l.d.o. >> >> Most other mail clients (Evolution, Icedove) disallow remote content >> by default and require explicit confirmation. I think gnus should >> follow this example. >> >> Ansgar >> >> [1] >> https://lists.debian.org/55f42a0a712cf_70bf3fc4828aabc09192...@prod-rs-r13.mail > > Additional information here: https://bugs.debian.org/798817 Gnus displays external images in newsgroups, but not in mail. Were you reading a news group? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#769340: bug#19035: Bug#769340: GNUS Mails marked read after connection dropps
Rob Browning writes: >> I have had a strange problem with gnus now several times. After >> trying to load a group in gnus -- if the connection dies while doing >> so -- I sometimes end up with the whole imap folder marked as read. I >> consider this read information important user data and it's almost as >> paoinfull as loosing email outright I think this should be fixed in git Gnus now (and in the Emacs trunk soon). It's a bit difficult to test though. Should probably be backported to emacs-24, too. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#159785: message-goto-gcc
jida...@jidanni.org writes: > Dear b...@gnus.org, please make and bind message-goto-gcc . Well, Gcc is a Gnus thing, so it would be odd for Message to have such a command. So it would have to be a Gnus command. But is a keystroke for going to that header all that useful, anyway? I've never felt the need myself... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
