bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

[Mark H Weaver]

The problem was fixed upstream in Linux-libre 5.10.21, and presumably
also in 5.11.4, so I'm closing this bug now.

  Mark

bug#46998: wish: package xvfb-run

[Dr. Arne Babenhauserheide]

User-agent: mu4e 1.4.15; emacs 27.1
(emacs:30177): dbind-WARNING **: 01:46:31.849: Could not open X display

http://deb.debian.org/debian/pool/main/x/xorg-server/xorg-server_1.20.10-3.diff.gz

+Usage: $PROGNAME [OPTION ...] COMMAND
+Options:
+DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@"
Dear Guix hackers,

One of my main tools for running graphical programs as part of my build
pipelines is xvfb-run. Since it is not packaged in Guix, I’ve resorted
to manual workarounds, but these have annoying drawbacks:

Xvfb :3 -screen 0 1024x768x16 & time DISPLAY=:3 HOME=/path/to/project/.emacs.d 
emacs …

I now get errors about the maximum number of clients reached, because
the Xvfb does not get reaped after the build:
Maximum number of clients reached
Therefore I would ask whether it would be possible to package xvfb-run.
It is provided as part of the patches of the xorg-package in Debian:

The included xvfb-run and xvfb-run.1:

--- xorg-server-1.20.10.orig/debian/local/xvfb-run
+++ xorg-server-1.20.10/debian/local/xvfb-run
@@ -0,0 +1,191 @@
+#!/bin/sh
+
+# This script starts an instance of Xvfb, the "fake" X server, runs a command
+# with that server available, and kills the X server when done.  The return
+# value of the command becomes the return value of this script.
+#
+# If anyone is using this to build a Debian package, make sure the package
+# Build-Depends on xvfb and xauth.
+
+set -e
+
+PROGNAME=xvfb-run
+SERVERNUM=99
+AUTHFILE=
+ERRORFILE=/dev/null
+XVFBARGS="-screen 0 1280x1024x24"
+LISTENTCP="-nolisten tcp"
+XAUTHPROTO=.
+
+# Query the terminal to establish a default number of columns to use for
+# displaying messages to the user.  This is used only as a fallback in the 
event
+# the COLUMNS variable is not set.  ($COLUMNS can react to SIGWINCH while the
+# script is running, and this cannot, only being calculated once.)
+DEFCOLUMNS=$(stty size 2>/dev/null | awk '{print $2}') || true
+case "$DEFCOLUMNS" in
+*[!0-9]*|'') DEFCOLUMNS=80 ;;
+esac
+
+# Display a message, wrapping lines at the terminal width.
+message () {
+echo "$PROGNAME: $*" | fmt -t -w ${COLUMNS:-$DEFCOLUMNS}
+}
+
+# Display an error message.
+error () {
+message "error: $*" >&2
+}
+
+# Display a usage message.
+usage () {
+if [ -n "$*" ]; then
+message "usage error: $*"
+fi
+cat <>"$ERRORFILE" 2>&1
+fi
+if [ -n "$XVFB_RUN_TMPDIR" ]; then
+if ! rm -r "$XVFB_RUN_TMPDIR"; then
+error "problem while cleaning up temporary directory"
+exit 5
+fi
+fi
+if [ -n "$XVFBPID" ]; then
+kill "$XVFBPID" >>"$ERRORFILE" 2>&1
+fi
+}
+
+# Parse the command line.
+ARGS=$(getopt --options +ae:f:hn:lp:s:w: \
+   --long 
auto-servernum,error-file:,auth-file:,help,server-num:,listen-tcp,xauth-protocol:,server-args:,wait:
 \
+   --name "$PROGNAME" -- "$@")
+GETOPT_STATUS=$?
+
+if [ $GETOPT_STATUS -ne 0 ]; then
+error "internal error; getopt exited with status $GETOPT_STATUS"
+exit 6
+fi
+
+eval set -- "$ARGS"
+
+while :; do
+case "$1" in
+-a|--auto-servernum) SERVERNUM=$(find_free_servernum); AUTONUM="yes" ;;
+-e|--error-file) ERRORFILE="$2"; shift ;;
+-f|--auth-file) AUTHFILE="$2"; shift ;;
+-h|--help) SHOWHELP="yes" ;;
+-n|--server-num) SERVERNUM="$2"; shift ;;
+-l|--listen-tcp) LISTENTCP="" ;;
+-p|--xauth-protocol) XAUTHPROTO="$2"; shift ;;
+-s|--server-args) XVFBARGS="$2"; shift ;;
+-w|--wait) shift ;;
+--) shift; break ;;
+*) error "internal error; getopt permitted \"$1\" unexpectedly"
+   exit 6
+   ;;
+esac
+shift
+done
+
+if [ "$SHOWHELP" ]; then
+usage
+exit 0
+fi
+
+if [ -z "$*" ]; then
+usage "need a command to run" >&2
+exit 2
+fi
+
+if ! command -v xauth >/dev/null; then
+error "xauth command not found"
+exit 3
+fi
+
+# tidy up after ourselves
+trap clean_up EXIT
+
+# If the user did not specify an X authorization file to use, set up a 
temporary
+# directory to house one.
+if [ -z "$AUTHFILE" ]; then
+XVFB_RUN_TMPDIR="$(mktemp -d -t $PROGNAME.XX)"
+AUTHFILE="$XVFB_RUN_TMPDIR/Xauthority"
+# Create empty file to avoid xauth warning
+touch "$AUTHFILE"
+fi
+
+# Start Xvfb.
+MCOOKIE=$(mcookie)
+tries=10
+while [ $tries -gt 0 ]; do
+tries=$(( $tries - 1 ))
+XAUTHORITY=$AUTHFILE xauth source - << EOF >>"$ERRORFILE" 2>&1
+add :$SERVERNUM $XAUTHPROTO $MCOOKIE
+EOF
+# handle SIGUSR1 so Xvfb knows to send a signal when it's ready to accept
+# connections
+trap : USR1
+(trap '' USR1; exec Xvfb ":$SERVERNUM" $XVFBARGS $LISTENTCP -auth 
$AUTHFILE >>"$ERRORFILE" 2>&1) &
+XVFBPID=$!
+
+wait || :
+if kill -0 $XVFBPID 2>/dev/null; then
+break
+elif [ -n "$AUTONUM" ]; then
+# The display is in use so try another one (if '-a' was specified).
+SERVERNUM=$((SERVERNUM + 1))
+SERVERNUM=$(find_free_servernum)
+continue
+

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

[Christopher Baines]

Mark H Weaver  writes:

> Mark H Weaver  writes:
>
>> FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a
>> heads-up about a severe performance regression in Linux-libre 5.10.20,
>> and I suspect the same regression exists in 5.11.3.
>>
>> For details, see the bug report I submitted to the Emacs developers,
>> here: .
>
> I've since confirmed that reverting the two upstream commits mentioned
> in  fixes the performance regression.  I've
> attached a preliminary patch for Guix that reverts those upstream
> commits for linux-libre@5.10, and which I've tested on my system.
>
> I guess that the same fix is also needed for linux-libre@5.11, but I've
> not checked.  I'll leave it to others to try applying the same reverts
> to 5.11.3 if they wish, and to decide what (if anything) should be done
> in Guix about this issue.

Ah, thanks so much for investigating this Mark! I only got as far as
asking around on #emacs.

I can confirm that 5.11.3 is affected, and that reverting to 5.10.19
avoids the issue. I haven't tried your patch yet.


signature.asc
Description: PGP signature

bug#46980: ntfs-3g and setuid root with an external FUSE library

[Abdelhakim Qbaich via Bug reports for GNU Guix]

Hi,

In the default set of desktop services, ntfs-3g is made setuid root:

> (simple-service 'mount-setuid-helpers setuid-program-service-type
> (list (file-append nfs-utils "/sbin/mount.nfs")
>   (file-append ntfs-3g "/sbin/mount.ntfs-3g")))

However, as it is built with:

> "--with-fuse=external" ;use our own FUSE

Running mount.ntfs-3g yields:

> Mount is denied because setuid and setgid root ntfs-3g is insecure
> with the external FUSE library. Either remove the setuid/setgid bit
> from the binary or rebuild NTFS-3G with integrated FUSE support and
> make it setuid root.

-- 
Abdelhakim Qbaich

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

[Bengt Richter]

Hi Mark, et?

On +2021-03-06 21:54:42 -0500, Mark H Weaver wrote:
> Mark H Weaver  writes:
> 
> > FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a
> > heads-up about a severe performance regression in Linux-libre 5.10.20,
> > and I suspect the same regression exists in 5.11.3.
> >
> > For details, see the bug report I submitted to the Emacs developers,
> > here: .
> 
> I've since confirmed that reverting the two upstream commits mentioned
> in  fixes the performance regression.  I've
> attached a preliminary patch for Guix that reverts those upstream
> commits for linux-libre@5.10, and which I've tested on my system.
> 
> I guess that the same fix is also needed for linux-libre@5.11, but I've
> not checked.  I'll leave it to others to try applying the same reverts
> to 5.11.3 if they wish, and to decide what (if anything) should be done
> in Guix about this issue.
> 
>   Mark
> 
> 
> 

Is the vt infrastructure that emacs uses to do Mx shell well virtualized
so that e.g. a native wayland bash repl displaying tile could be plugged in?
(if not, why not? :)

Seems like an html-textarea-like wayland tile could be implemented to
present the bash-stdout for emacs, and also capture it in a shm-pool
for access by emacs as open file or mmap, to do its mode-dependent
indenting and highlighting, then sending that to another text-area vt tile.

Excuse the handwaving, but I think it could be done, from what I've read
about wayland clients and servers.

-- 
Regards,
Bengt Richter
PS. BTW: anybody thought about defining a wayland server to act as guix daemon?
 It already has async threadsafe event loop and manages access-isolated
 pools of memory, and you can define extended protocol for access.

 And on a wayland-based box, this would be available early.
 Early enough for hurd initialization to make use of, I think.
 Daydream? :)