GNU bug report logs -
#48598
28.0.50; buffer-naming collisions involving bouncers in ERC
Previous Next
Reported by: "J.P." <jp <at> neverwas.me>
Date: Sun, 23 May 2021 01:23:02 UTC
Severity: normal
Tags: patch
Found in version 28.0.50
Fixed in version 29.1
Done: "J.P." <jp <at> neverwas.me>
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 48598 in the body.
You can then email your comments to 48598 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sun, 23 May 2021 01:23:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"J.P." <jp <at> neverwas.me>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 23 May 2021 01:23:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Tags: patch
This follows directly from #40121 "27.0.90; ERC incorrectly reuses
single buffer for channels of same name," which may be related to #30639
"25.1; ERC buffer name not unique, broken on reconnect." [1]
In the first section below, you'll find a handful of summaries
describing user experiences related to this email's subject line. While
these descriptions overlap quite a bit, it's their differences that
reveal the real culprit, which is ERC's use of servers rather than
networks for connection identities.
Additional materials, like logs and screenshots, accompany these
descriptions. They can be found here [2] along with a few other related
scenarios not involving bouncers. Each scenario includes a corresponding
test case that reproduces its problematic behavior. More on testing
further below.
Beware that the summaries themselves are rather matter-of-fact (boring)
and are mostly included for posterity. Unless you're directly impacted
by this bug and looking to make common cause, please just skip to the
main discussion further below. Thanks.
Bug descriptions
~~~~~~~~~~~~~~~~
Nickname: clash-of-chans/bouncer-history
Subject: Intermingled output in channel buffer on connect
Playback: true
Connect to two IRC networks via the same bouncer. Do this by issuing two
separate `erc' invocations. This will create two connections with the
same remote address. The bouncer should send "playback" (logs) for an
identically named channel on both upstream networks. It does this
because it's currently "joined" to (maintaining a presence in) both
channels. A single ERC channel buffer is created showing the log output
from both channels. Live, real-time output continues below the playback.
This is *almost* the same bug as #40121 "ERC incorrectly reuses
single buffer for channels of same name." The difference here is that
the well-known TCP listening address is the same for both connections.
Note that this issue existed prior to Emacs commit
88567ca8ecb505a59157af6338ebe355a304182b "Fix erc-reuse-buffers
behavior." Before that commit, the buffer/process situation looked like
this:
#<buffer 127.0.0.1:16668> #<process erc-127.0.0.1-16668>
#<buffer 127.0.0.1:16668/127.0.0.1> #<process erc-127.0.0.1-16668<1>>
With that commit, the second server's *buffer* name gained a <2>
suffix, but its process name remains unchanged.
Nickname: clash-of-chans/auto-join
Subject: Autojoin module joins wrong channels when using bouncer
Playback: false
Ensure the module `autojoin' is loaded. Connect to an IRC network named
foonet via a bouncer. Join a channel named #chan, and then quit. Connect
to a different network, barnet, via the same bouncer. The same server
buffer is reused. The existing #chan buffer (with foonet's output) is
also reused.
Now reconnect to foonet via the same bouncer. The bouncer sends playback
for #chan <at> foonet, which is displayed in the same unified #chan buffer.
After that, output from both networks is printed in an alternating
fashion.
Nickname: clash-of-chans/rename-buffers
Subject: Channel buffers still collide despite erc-rename-buffers
Playback: false
Ensure the option `erc-rename-buffers' is non-nil. Connect to an IRC
network named foonet via a bouncer. The server buffer is correctly
renamed to match the network "foonet." Join a channel named #chan.
Connect to a different network, barnet, via the same bouncer. This
server buffer is also renamed correctly. Join a channel of the same
name, #chan, on this network. Another buffer is not created. The
existing buffer is not renamed. Output in #chan is intermingled,
displaying content from both networks.
This scenario is identical to "clash-of-chans/bouncer-history," except
for the lack of playback and the `erc-rename-buffers' option.
Nickname: clash-of-chans/uniquify-fail
Subject: Unpredictable intermingling of proxied channels
Playback: true
Remove the `autojoin' module, which is enabled by default. Set the
variable `erc-reuse-buffers' to nil. Connect to two networks via the
same bouncer.
The bouncer sends "playback" for two channels, one from each network.
The channels share the same name, and the bouncer is still subscribed to
both. A single channel buffer displaying intermingled output is created.
The process returned by `get-buffer-process' toggles back and forth
between client processes. This happens whenever a speaker from the "out
of phase" network speaks.
Now, emitting a PART in this unified buffer only leaves one network's
channel (call it "foonet's" channel). And a new channel buffer appears
exclusive to the *surviving* network's channel ("barnet's" channel). The
other, previously intermingled buffer is left inactive. However,
attempting a /join #chan from its input prompt succeeds in reviving
it, meaning the same buffer is reused here (for new output exclusive to
foonet) despite `erc-resuse-buffers' being nil.
Revisiting the other #chan buffer and emitting a PART succeeds in
leaving the channel. However, a subsequent /join #chan in the same
buffer does not create a new buffer. Instead, it causes intermingling to
resume in the *other* channel buffer, the one originally intermingled
and then foonet-only.
This bug is a mashup of two other "clash" scenarios, "buffer-history"
and "uniquify-litter," but it exhibits slightly different `reuse'
behavior.
Nickname: clash-of-chans/uniquify-litter
Subject: Buffer creation unpredictable with identically named channels
Playback: true
Ensure the `autojoin' module is disabled (it's enabled by default). Set
the variable `erc-reuse-buffers' to nil (it's normally t). Connect to
two networks via the same bouncer.
The bouncer sends playback for two channels, one from each network. The
channels share the same name. A single channel buffer is created
displaying intermingled output.
Continuing, emit a PART in the combined buffer, timing it to affect the
first network (call that "foonet"). After a bit, another channel buffer
appears exclusive to the *second* network (call that "barnet"). The
original, unified buffer no longer has an active process.
Visit barnet's #chan buffer (the one automatically created earlier) and
emit a PART and (after a sec) a subsequent JOIN. This should create
another buffer, which is consistent with `erc-reuse-buffers' being off.
But switching back to the now inactive first buffer (the intermingled
one) and sending a /join #chan will *not* create a new buffer. New
output exclusive to foonet will just start appearing below the old,
intermingled stuff.
Nickname: rebuffed/gapless
Subject: Back-to-back bouncer connections, but only the second survives
Playback: true
Make two back-to-back connections to the same bouncer. This bouncer
should be sustaining two upstream IRC-network connections with one
channel joined on each. The channels should have distinct names.
When the second connection completes, two new buffers have been created.
The first is a server buffer whose ~erc-server-process~ belongs to the
second network. The second is a channel buffer whose channel belongs to
the second network. No channel buffers exist for the first network. No
notices or welcome messages from the first network appear anywhere in
the one server buffer.
This issue existed prior to commit 88567ca8 "Fix erc-reuse-buffers
behavior."
Nickname: rebuffed/reuseless
Subject: Bouncer-related server-buffer naming regression
Playback: false
Connect twice to the same bouncer endpoint, once for each of two proxied
upstream networks. No channels are currently joined. When
`erc-reuse-buffers' is disabled, the buffer created for the second
connection clobbers the first, and both connections remain alive.
This issue arose with commit 88567ca8ecb505a59157af6338ebe355a304182b
"Fix erc-reuse-buffers behavior." Before that commit, two buffers would
be created:
#<buffer 127.0.0.1:6667/127.0.0.1> #<process erc-127.0.0.1-6667>
#<buffer 127.0.0.1:6667/127.0.0.1<2>> #<process erc-127.0.0.1-6667<1>>
Whereas now only the second one survives:
#<buffer 127.0.0.1:6667/127.0.0.1> #<process erc-127.0.0.1-6667>
#<buffer 127.0.0.1:6667/127.0.0.1> #<process erc-127.0.0.1-6667<1>>
Note that when `erc-reuse-buffers' is *enabled*, two buffers are indeed
created, as before. Except now, the name of the first is
#<buffer 127.0.0.1:6667> without the slash-host suffix.
What's surprising is that `erc-reuse-buffers' has any effect at all
given that, according to the doc string, the option ought only concern
channel and query buffers. (And this bug is only about server buffers.)
Discussion
~~~~~~~~~~
Thus far, a definitive solution to all or most of the above eludes me.
As such, I can't yet lay claim to a fix despite the patches on offer
below. So if anyone has a smarter/simpler proposal, please don't
hesitate to share, and I'll gladly make way. In fact, I seem to recall
ERC's own maintainer investigating related matters a while back. And so
a comparable, if not superior solution may already be in the works! (Or
perhaps that can be arranged with a little nudging.) :)
Anyhow, for the time being, please consider the attached series of WIP
patches a mere jumping-off point/placeholder to get the ball rolling.
These all depend on a collection of tests and related helpers that I'm
of course willing to rework as needed. A broad rationale for their
inclusion appears below [A].
Some background
Unlike most clients, ERC (to my knowledge) doesn't offer configurable
connection identities, by which I mean persistent, user-adjustable
settings that tie TCP endpoints to "announced" server names and their
networks [3]. This isn't in itself a bad thing, but it invites some
complications where proxies are concerned (not to suggest that such
problems are unique to ERC).
One method for disambiguation used by some clients adopts a pet
convention introduced by popular bouncers, like ZNC. In this scheme, a
unique network identifier and sometimes other details useful to a
bouncer are smuggled into the payload of an early client-initiated
command, like PASS, NICK, or USER. But this practice has not been
standardized. And it's entirely plausible a client won't know which
network it's connecting to until after introductions have been made. I
mention this because I don't think it's worth considering as a primary
solution.
Right now, different parts of the library vary in how they identify
connections. Some rely on the variable `erc-session-server', whose value
originates from the argument passed as the :server parameter of the
entry-point `erc' command. This is an IP address or a host name.
Elsewhere, the network's "announced" name is preferred. This is an
FQDN-like identifier scraped from early banner numerics, like RPL_MYINFO
or RPL_YOURHOST, and stored in the variable `erc-server-announced-name'.
These two server names tend to be used as fallbacks for each other,
though the motivation for favoring one over the other is often a mystery
(to me). Occasionally, the last couple domain components (labels) of an
announced name are used to divine an identity [4]. For example,
foo.gnu.org and bar.gnu.org might be pegged as individual servers on the
same network.
Currently, various places in the library appeal to ERC's `networks'
module (erc-networks.el) for the network identifier. This is often used
for less important purposes such as mode-line info. Under normal
circumstances, the module's API returns a name taken directly from the
NETWORK parameter of the RPL_ISUPPORT numeric. This is a stylized name
potentially containing spaces and other characters [5]. But it's useful,
authoritative info nonetheless.
The current approach
"The only way to do it is connection=network" - Irssi's maintainer [6]
I'd like to believe ERC's authors basically agreed with this, at least
in spirit. And while their whole ad hoc/dynamic way of assigning
connection identities is a bit different, I don't think there's any
reason to abandon it just yet, especially if we strive to place more
emphasis on understanding and applying the evolving standard going
forward.
Here are a couple of assumptions that had better hold if my present
angle of attack is to get us off the ground:
1. There is at most one connection from a client to a network at any
given moment [7]
2. Buffer->network associations cannot change once determined, i.e.,
networks and ERC buffers mate for life, even when disconnected
So, until its network is known, a connection is considered unique but
orphaned. And the moment its network is discovered, any conflicts must
be resolved immediately and propagated throughout the rest of the
program.
With channels and queries, this is relatively straightforward: retain
the behavior exhibited (or at least aspired to) when the option
`erc-rename-buffers' is in effect. Only now, expand its berth to cover
server buffers. Also, make it more precise, and make it the default.
Moreover, mandate that the `networks' module always be loaded because it
provides essential network resolution/normalization functionality upon
which everything else relies. (This is likely already the case anyway,
effectively speaking.)
Of course, at least a few exceptions and what-ifs concerning all of the
above come to mind (or will, most certainly). Here's just one, as an
example, in the form of a Q&A:
Q: Say you connect to a bouncer to do some maintenance or check some
logs without being patched through to an upstream network. In this case,
a network name may never be announced. If another connection is
attempted to the same endpoint, perhaps with the aim of being proxied to
an upstream IRC network, should it be rejected as a dupe or allowed to
proceed? And what should its buffer name be?
A: The second connection should be allowed to complete and should be
considered wholly distinct and unrelated to the first. Its server buffer
should be named after the dialed TCP address and uniquified with an
incremented <n> suffix [8]. But it should adopt the name of the network
once that's discovered. If there's an existing connection for that
network and it's alive, the new one should be dropped immediately and an
error signaled. If buffers from an earlier, now dead connection to that
same network exist, the new connection should inherit those channel and
query buffers along with all relevant data from the server buffer (which
should then be killed off or renamed).
Plenty of other concerns and questions exist, many unresolved. The
accompanying WIP patch set is peppered with comments labeled "ERASE ME"
that pose some of these in context. (Apologies if that's annoying.) The
patches themselves I've refrained from attaching because their combined
size is around 200K (mostly tests). Instead, they're available here [9].
Items still left to address generally involve query buffers, but other
things like &local channels remain unexplored. There are still plenty of
unit tests to be written, and a few loose ends regarding IRC standards
may require additional investigative legwork to nail down completely.
Thanks again,
J.P.
Notes
~~~~~
[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40121
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30639
[2]: https://jpneverwas.gitlab.io/erc-tools/
[3]: Not that the ingredients don't already exist for this sort of
setup. See the variable `net' in the command `erc-server-select'.
[4]: See option `erc-common-server-suffixes' used by functions
`erc-shorten-server-name' and `erc-canonicalize-server-name'.
Indeed, leveraging domain name hierarchies for determining
connection identities a fine idea, and erc-networks.el does it well
enough when performing lookups in a predefined alist. See [5].
With erc-join.el, however, the same basic idea leads to unfortunate
results. See option `erc-autojoin-domain-only'. In the scenario
named clash-of-chans/auto-join, this truncation operation produces
"0.1" because an IP address is used where a host name is expected.
[5]: Characters disallowed in domain names are actually fine for our
purposes. The standard (according to ircdocs, based on the Hardy
draft) states that NETWORK's value should only be used for
informational purposes. Whether you take that to mean it shouldn't
be used for identification purposes is up for debate, but some
influential voices certainly take that view.
I'm unsure what the best course of action is here, but the
`networks' module actually includes another method of identifying
networks, which is currently used as a fallback. And that's to
consult a user option for known networks (it basically associates
domain names with canonical identifiers). Because it offers a means
of escape and because it would only run once per connection, I
don't think there's any harm in elevating its role to pole position
and using the vanity name as a fallback.
[6]: Ailin Nemui (Nei) in conversation with me on #ircdocs, 05/21/2021.
[7]: Legitimate exceptions exist, for example connecting as two
different users to a network through a bouncer to debug a bot.
[8]: We can't use anything derived from the physical connection, such as
the ephemeral local port, because none of that's known at buffer
creation time. Also, this scenario demonstrates why interpreting
the source/prefix from server-originating messages as a network
name is never seen (e.g., :irc.znc.in).
[9]: Web UI (javascript):
https://gitlab.com/jpneverwas/erc-tools/-/tree/master/resources/trunk/wip
Direct download (zip file):
https://gitlab.com/jpneverwas/erc-tools/-/jobs/artifacts/master/download/?job=test:trunk-only-wip
This one ^ redirects to whatever the latest incarnation may be. If
you require diffs, use the web UI or demand that I furnish them.
The ones marked WIP are *not* ready for prime time. If they ever
are, I intend on squashing them down into just one or two.
[A]: Test server and related helpers (a rationale)
The first few patches in this set are meant to lay some groundwork
for a larger undertaking to retrofit ERC with the flexibility
needed to accommodate modern features like IRCv3 capability
negotiation and SASL authentication, which have recently become
fixtures of the living IRC standard. For example, Libera (like
Freenode before it), has begun requiring SASL authentication from
certain IP ranges, which was something formerly demanded only of
TOR users.
The current health of the library is probably on par with at least
a few others of its age in the sense of being "open for extension,
closed for modification." However, many of the newer changes on the
horizon require overhauling vast swaths of the foundation. To my
knowledge, accomplishing that in situ is best handled by fortifying
the library with functional tests. The alternative is finding a
comparable replacement (or creating a greenfield one) and making a
swap at some point.
Not that anyone should care, but I don't in principle subscribe to
the view that blanketing a library with functional tests is always
the best way forward, at least for an IRC client. If the code were
written in a more modern style, with more easily digestible
bite-sized pieces and more controllable side effects, we could be
reasonably certain (with the help of unit tests) that when wired
up, everything would behave as advertised. Unfortunately, that's
not the case with ERC in its present condition.
BTW, these tests will also afford us the breathing room to
temporarily ignore certain issues with core functionality, namely,
things being only half implemented or otherwise not up to spec.
Examples include RPL_ISUPPORT handling, casemapping, and v3 message
tags.
In GNU Emacs 28.0.50 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4)
of 2021-05-18 built on pc
Repository revision: 1276ba75eb0d308b76df34c522bb0d6e059c146e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)
Configured using:
'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
--program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec
--localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
--with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
--with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
--with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-O0 -g3'
LDFLAGS=-Wl,-z,relro
PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
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
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)
Memory information:
((conses 16 51721 6314)
(symbols 48 6601 1)
(strings 32 18223 1958)
(string-bytes 1 611836)
(vectors 16 13547)
(vector-slots 8 178617 7780)
(floats 8 21 45)
(intervals 56 322 0)
(buffers 992 11))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Wed, 02 Jun 2021 11:20:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi, this is just a routine update/checkpoint rather than a bump for
feedback.
I fear that in the rush to cobble together my original report, I may
have given the false impression I was prepared to move quickly on this.
And that in turn may have triggered some frustration with folks eager
for a fix or at least something test drivable amid the mass exodus from
Freenode. For any callousness on my part re over-promising and
under-delivering, please accept my apologies.
Firstly, I wanted to highlight some prior art done in this area by Kevin
(CC'd), who contacted me out of band. I've incorporated their latest
update to erc-join.el in my proposed WIP patch set. It's based on these
discussions [1].
My other changes primarily focus on implementing what I'd only
previously provided half-baked placeholders for, namely
1. Network-based connection identities
2. Support for identical channel and query targets across networks
Other changes are more or less minor tweaks, most reflecting shifts in
my understanding of the living standard [2] and/or the library itself
[3][4].
If I can sign off with an appeal to any and all interested folks: please
step up and collaborate on this bug, even if that means my having to
pass the baton or redo much of what's currently on offer. Thanks.
Notes
~~~~~
[1] https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00088.html
https://lists.gnu.org/archive/html/emacs-devel/2018-02/msg00664.html
[2] Correction: in my original report, I mentioned possible problems
with case mapping in ERC. After seeking out more informed opinions
on the matter, I no longer feel my concerns were entirely justified.
And in any case, they're not worth prioritizing, ATM.
[3] Re my (perhaps wanton) deletion throughout the library of existing
fallback-oriented logic for selecting connection identities.
Currently, there's a lot of attention paid to graceful degradation
in this department with questionable obvious benefit, IMO. Rather
than splitting hairs over inferior/degenerate fallbacks, which ends
up, for example, sewing confusion by shoehorning something like
erc-session-server (the dialed address) into a value basically meant
for networks, why not just opt for precision and blow up when met
with lapses in our understanding of IRC (in hopes of encouraging
quicker, cleaner fixes in the future)?
In the discussion for bug#23438 "24.5; ERC autojoin should use
erc-autojoin-domain-only searching channel keys" (which merged with
bug#25349 "25.1.90; erc join -vs- passwords" and led to a patch),
the participants make this problem pretty plain:
> Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com> writes:
>> Though one thing - I'm not sure whether you even need to use "or"
>> here. Would there ever be a case where erc-session-server is nil,
>> but there is erc-server-announced-name?
> I don't actually know, so I just swapped them out of paranoia.
Not to pick on these fine folks (this kind of equivocal reasoning in
this specific area predates their bug by a decade plus). But going
forward, I think it makes sense to at least note such uncertainty in
the code if not face it head on by dropping this convention of
indiscriminately relying on fallbacks. Worst case scenario: our lack
of IRC know how is betrayed (at everyone's expense, temporarily) and
we're forced to up our game.
With this set of WIP patches, I'm trying to somewhat upend this
"fallback" trend by making a de facto hard dependency of the
networks module (library wide) and delegating to it all duties
concerned with identifying a specific connection.
BTW, their bug itself was of course legitimate, but their solution
didn't account for proxies (e.g., "localhost") or the concept of a
network, really.
[4] To any old timers still using this client: if you would be so kind
as to explain the reasoning behind erc-default-recipients being a
list rather than a single target, that'd be terrific (TIA).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Wed, 09 Jun 2021 14:37:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
> The current approach
>
> "The only way to do it is connection=network" - Irssi's maintainer [6]
>
> I'd like to believe ERC's authors basically agreed with this, at least
> in spirit. And while their whole ad hoc/dynamic way of assigning
> connection identities is a bit different, I don't think there's any
> reason to abandon it just yet, especially if we strive to place more
> emphasis on understanding and applying the evolving standard going
> forward.
This approach seems to have drawbacks, at least in principle. For example, I
don't think it allows to connect and join different channels with different
nicknames at once. Surely, this is not the most straightforward scenario, but
maybe some people would be interested in doing that. I would be interested,
for example. Of course, if the principle above is rooted into ERC, many
changes are going to be needed in practice to allow multiple "sessions", so it
doesn't matter much if the proposal below is at odds with that (it won't
worsen the situation compared to now). Multiple sessions can be dealt with
independently at some later point.
> Here are a couple of assumptions that had better hold if my present
> angle of attack is to get us off the ground:
>
> 1. There is at most one connection from a client to a network at any
> given moment [7]
>
> 2. Buffer->network associations cannot change once determined, i.e.,
> networks and ERC buffers mate for life, even when disconnected
>
> (snip)
I think there are two essential points to be made here:
1. Separate the network (or the session), seen as the user's target, from the
means to connect (directly or through a bouncer, or whatever else). This way,
there is no confusion between the transport part (just a mean) and the session
(which is what matters to the user in terms of context, i.e., which network
I'm in (and channels) and under which identity).
With this, there will be no problem in the scenario where one connects to a
bouncer to do maintenance tasks while there is already a connection to it to
access some other network. There will be two sessions: One for the maintenance
task, designating the bouncer, and one for the other network, each having its
own connection and separate buffers. I think that having a single connection
to the bouncer in this particular case is a refinement that could be
implemented later (or not), unless of course it is absolutely impossible to
have more than one at a time (is it the case with usual bouncers?).
2. Also, buffers should not be associated on the fly to networks, depending on
what the network says. They should be associated to sessions, as a priori
targets specified by the user, with unambiguous (i.e., different buffers for
channels with same name in different sessions) and unchanging names (may be
internal "names" of any form instead of the buffer name, if one wants short
buffer names in common situations). This way there is no "dangling" buffer,
and it is always very clear which buffer belongs to which session, enabling
smarter management in case a session is disconnected and then reconnected, or
log storing.
I don't know precisely which changes 1 and 2 require given the current code,
but I intend to dig that at some point. Unfortunately, I don't think I'll be
able to before weeks, probably even months. At least, I hope we can agree (or
if not, discuss) on these target points.
--
Olivier Certner
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 10 Jun 2021 14:38:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Thanks for taking the time to respond with thoughtful remarks.
Olivier Certner <ocert.dev <at> free.fr> writes:
> This approach seems to have drawbacks, at least in principle. For
> example, I don't think it allows to connect and join different
> channels with different nicknames at once. Surely, this is not the
> most straightforward scenario, but maybe some people would be
> interested in doing that. I would be interested, for example.
Yes, I think it would be nice to either support multiple connections per
network from the get go or leave the door open by providing a flexible
means of determining connection identity. My current approach is rather
inflexible, but I believe the underlying foundation (rooted in the test
suite) robust enough to withstand a quick pivot in most any direction.
> Of course, if the principle above is rooted into ERC, many changes are
> going to be needed in practice to allow multiple "sessions", so it
> doesn't matter much if the proposal below is at odds with that (it
> won't worsen the situation compared to now). Multiple sessions can be
> dealt with independently at some later point.
What I was trying (perhaps failing) to communicate initially was that
the principle above is only ingrained in the library in the sense that
connection = (maybe sometimes dialed server:port
or
maybe sometimes announced.domain.name
or
maybe sometimes NeTwOrK)
whereas I was trying to force a shift to make it solely connection =
network (as massaged by user/library presets).
> 1. Separate the network (or the session), seen as the user's target,
> from the means to connect (directly or through a bouncer, or whatever
> else). This way, there is no confusion between the transport part
> (just a mean) and the session (which is what matters to the user in
> terms of context, i.e., which network I'm in (and channels) and under
> which identity).
This is an important distinction, and it's not unique to IRC in the
least, as I'm sure you know. Divorcing the means of connection from a
connection's identity (or "session" [1]) was among the (perhaps under-)
stated goals. If that wasn't made clear enough, it should've been.
> With this, there will be no problem in the scenario where one connects
> to a bouncer to do maintenance tasks while there is already a
> connection to it to access some other network. There will be two
> sessions: One for the maintenance task, designating the bouncer, and
> one for the other network, each having its own connection and separate
> buffers.
Yes, this is already how I have things currently working. But this all
depends on what we ultimately settle on as determining the start of a
session. Because of what I view as incomplete guidance on this matter
from on high (IETF, docs, etc.), I'm resigned to just following the lead
of the dedicated IRC clients.
BTW, often when I say "bouncer," I actually mean *any* proxy. But in an
effort to keep the bug focused and concrete, I've chosen to stick to
scenarios involving bouncers. But in many contexts, you could easily
swap out "bouncer" for, say, "web proxy" [2].
Also, by abstracting away transport from protocol, as you say, we could
easily, for example, provide "virtual servers" that do within Emacs what
would normally require a proxy. One use case might be something that
provides the chathistory interface [3] and fetches cached logs when a
real server is offline or lacking support. Another example might be a
fake server (like the one I've introduced in these patches) that's
intended solely for testing. Possibilities abound.
> I think that having a single connection to the bouncer in this
> particular case is a refinement that could be implemented later (or
> not), unless of course it is absolutely impossible to have more than
> one at a time (is it the case with usual bouncers?).
If you're talking about multiplexing generally, this requires filtering
and routing in keeping with a chosen proxy protocol (again, doable with
pluggable core components).
> 2. Also, buffers should not be associated on the fly to networks,
> depending on what the network says. They should be associated to
> sessions, as a priori targets specified by the user, with unambiguous
> (i.e., different buffers for channels with same name in different
> sessions) and unchanging names (may be internal "names" of any form
> instead of the buffer name, if one wants short buffer names in common
> situations). This way there is no "dangling" buffer, and it is always
> very clear which buffer belongs to which session, enabling smarter
> management in case a session is disconnected and then reconnected, or
> log storing.
I agree in principle, but in practice, this can only be introduced
optionally without causing overly disruptive churn.
It's easy to forget that this is legacy software, and tradition here
plays an outsize role. And for better or worse, ERC's passive detection
and automatic assigning of connection identities, however quaint, falls
right in line with the DWIM philosophy common throughout Emacs. I
suspect folks feel a certain attachment to this experience that
shouldn't be overlooked. Not saying I wouldn't welcome some other
reality in which this weren't the case.
Almost every popular client out there works the way you say: a priori
designation describes logical destination. AFAIK, this is the only
widely adopted method. Basically, a user declares some unique identifier
up front when dialing the connection (or via configuration). This then
becomes the ID associated with that connection over its lifetime.
So I believe we need to do both for now, both declared *and* discovered.
We can perhaps promote the former as being superior and regard "on the
fly" associations as fully but grudgingly supported. And interpreting
the network's word as gospel for that purpose *should* be adopted in
full instead of only sparingly, which is in large part the source of the
current problems. But again, discovered truth should also be considered
subordinate to whatever a human operator dictates. (IMO.)
If we are to allow multiple connections to networks, as you're
requesting, then adopting discovered network names as session
identifiers won't be enough. For this use case, we may simply end up
requiring declared identifiers. Alternatively, adding nicks as a second
identifying component for this purpose could effectively preclude
intra-network collisions [4], though it may not be worth the added
complexity. That said, it would make it easier to transition to full
"account" awareness [5] once we go v3, at which point many of these
problems may just vanish.
As far as "dangling" buffers are concerned, I'm going to interpret that
as the limbo period between when a connection is dialed and when its
session association has been cemented. Know that this "only" affects
server buffers, which isn't great, but at least that means it won't
happen mid session. But in cases where associations cannot be determined
(such as with the maintenance scenario), a user *must* supply an
identity for the association to survive reconnection. This may be as
simple as passing an extra keyword arg, something like :name, to the
`erc' and `erc-tls' entry point functions.
> I don't know precisely which changes 1 and 2 require given the current
> code, but I intend to dig that at some point. Unfortunately, I don't
> think I'll be able to before weeks, probably even months. At least, I
> hope we can agree (or if not, discuss) on these target points.
I'd like to keep moving aggressively on this. Hopefully you can continue
to participate in design discussions, which should leave little room for
big surprises later on.
Notes
~~~~~
[1] The term "session" is a bit ambiguous but may be the most fitting
for what we want to describe. For now, let's assume one connection
per account per service (here, an IRC network). Multiple connections
for the same account/service pair are not worth speculating over or
supporting at present, IMO. So for our purposes, a session means an
authenticated, healthy connection to a network, for as long as both
properties endure.
[2] These are indeed a thing. They allow a normal client to talk to
servers when denied access to non-HTTP ports.
https://github.com/kiwiirc/webircgateway
[3] https://ircv3.net/specs/extensions/chathistory
[4] While I'd love to use ident and maybe hostname, those aren't
considered reliable as unique account/session identifiers. Also, I
say "account" with reservation here because there's really no such
thing yet. See also 5.
[5] https://ircv3.net/specs/extensions/account-notify
https://raw.githubusercontent.com/quakenet/snircd/master/doc/readme.who
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 19 Jun 2021 03:05:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi,
This is update #2.
I've taken Olivier's suggestions to heart regarding up-front session
identifiers and have attempted to rework my changes around them [1].
This comes in the form of (yet) another keyword parameter to the `erc'
and `erc-tls' entry points. It's currently called :id, for lack of
imagination [2], and it can only be specified in lisp code (rather than
via M-x). When non-nil, it's stored as a symbol in a new session
variable called `erc-session-id'. This value takes precedence over
network display names and dialed/announced servers when identifying
connections and grouping buffers.
What remains are unambiguous, permanent associations completely
disinterested in other session properties, even those given as
authoritative by a remote service [3]. To opt in, a user need only avail
themselves of :id.
While the only concrete use case I've found for this so far is multiple
connections to the same network, providing full support across the board
ensures we leave a lifeline for folks with other edge cases. However,
for normal, everyday use, the interface remains unchanged, and there's
really no reason to take notice of this feature.
The general user experience has improved in terms of associations being
fortified with permanent network designations, meaning they survive
disconnection and decapitation (killing of a server buffer). Among other
things, this means reengaging someone in a reused query buffer is now
doable, assuming the other party is still around and hasn't changed
their nick [4]. Additionally, swapping out TCP endpoints (for example,
moving from proxy to direct connection) or being dealt a different
regional server by a network load balancer should no longer confuse ERC.
Buffers from previous sessions are found and reused.
I'd be happy to expand on anything above or explain any other changes in
detail [5]. If you can, please try these patches. And let me know if it
would make things easier to have the latest set present in thread as
attachments, which I'll gladly make happen [6].
Thanks,
J.P.
Notes
~~~~~
[1] About their other suggestion, which involved decoupling the means of
connection from all protocol logic: I now feel pursuing that here,
in this bug, strays too far off mission. It's quite an endeavor
because it would mean touching everything everywhere, so it'll have
to wait unless someone else wants to take up the call (in which
case, by all means).
[2] Grepping the ERC libraries for \bid\b didn't return anything of
note, so I figured it was free for the taking (suggestions welcome).
[3] IOW, you can sustain multiple simultaneous sessions to the same
network using the same nick, if your network supports multiple
client/device connections.
[4] As I've noted elsewhere, IRCv3 account tags and related features
should improve the situation here.
[5] I've also attempted to unify the auth-source interface a bit. In
doing so, I felt the need to include one of Olivier's patches,
bug#46777: 28.0.50; ERC: NickServ identification: Prompt for
password after other sources, overall simplifications:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46777
[6] My prior misgivings on that front were based on not wanting to
further clutter people's inboxes and overburden gmane. However,
these fears were probably misplaced. I've since found change sets of
similar size (still under 1 MiB) that didn't seem to elicit much in
the way of complaints.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 25 Jun 2021 13:19:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi,
Just a quick update this time (#3).
The download URL for this bug's patches has moved [1], along with their
path in the repo [2].
Not sure how likely it is these changes will be reviewed anytime soon,
but I'm hoping a bit of feedback from folks in the field might up their
prospects. So I've taken to asking anyone affected by this bug to help
out, with no takers just yet [3].
Rather than face the unvarnished truth of my personality/code being to
blame, I've instead decided to lay it all at the feet of modern man and
his general aversion to building Emacs. And so, in an attempt to hack
around this resistance, I've added a package.el-compatible endpoint to
host the latest snapshots.
As with *ELPA, you'd do something like:
(require 'package)
(push '("erc-jp" . "https://jpneverwas.gitlab.io/erc-tools/archive/")
package-archives)
And then:
M-x list-packages RET
Find the bottom-most entry for this bug, which should look like:
erc 48598.20210624.5 available An Emacs Internet Relay Chat client
And hit [Install] in the popup. For updated usage, see:
(info "(erc) Connecting")
Hopefully, this should make for easier test driving. Thanks!
Notes
~~~~~
[1] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
[2] https://gitlab.com/jpneverwas/erc-tools/-/tree/master/resources/trunk/48598/wip
[3] Actually, a few parties *were* willing but were on 27, which these
patches can't be applied to. However, 27 should run the patched
library as a drop-in replacement (and the tests as well, with the
addition of a small shim I'd be happy to provide).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 28 Jun 2021 07:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi JP,
Just a little word to say I should be able to catch up (at least partly) this
week. Thanks for your work in any case.
--
Olivier Certner
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 04 Sep 2021 16:49:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi ERC devs!
I'm writing today to report a bug with erc, due to the urging of neverwas on
#emacs <at> libera.chat. I was told to reference this bug as well:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598
I'm just going to recount what I experienced using ERC to the best of my
remembrance; I haven't used it in about a week or so (see the last commit of my
config using ERC at [1]), having switched to Circe. I'm afraid I didn't
investigate the cause of the problem too thoroughly, so I'm not sure what it
might have been.
- After setting up ZNC on znc.tilde.team, ERC would connect to channels on the
wrong server, e.g. I had #politics <at> tilde.team setup, it would connect to
#politics <at> libera.chat (which doesn't exist, and would redirect to
##politics). This is with the new ERC on Emacs 28, that when connecting to
different servers directly, would /not/ be confused (i.e., two buffers were
created: “#emacs/tilde.chat”, “#emacs/libera.chat”). To be honest, I'd never
used ZNC before either, so it's possible I set /that/ up wrong…
- Re-connection issues: I'm on a laptop so the connection drops in and out.
That's not the problem, but ERC was not so smart with reconnecting. I'd run
/reconnect in a server buffer, or try to map the command over servers, and
it'd reconnect but my nick would be acdw` or similar. I don't think this is
ERC's issue /per se/, but Circe, e.g., handles it better, afaik.
That's really all I remember, I hope this is helpful. ERC is, on the whole,
pretty good, and I might switch back later!
[1]: https://tildegit.org/acdw/emacs/src/commit/f919fd4db37999fb361ab18a27eb57db6a252ad5
--
~ acdw
acdw.net | breadpunk.club/~breadw
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Tue, 07 Sep 2021 21:39:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 48598 <at> debbugs.gnu.org (full text, mbox):
acdw <acdw <at> acdw.net> writes:
> I'm just going to recount what I experienced using ERC to the best of
> my remembrance; I haven't used it in about a week or so (see the last
> commit of my config using ERC at [1]), having switched to Circe.
Thanks a bunch for this, and apologies for the disappointing experience.
Since you're already an apostate, I'll spare you the annoying followup
questions as well as the customary plea to try out my changes (not that
your initial description wasn't plenty thorough enough).
> - After setting up ZNC on znc.tilde.team, ERC would connect to
> channels on the wrong server, e.g. I had #politics <at> tilde.team setup,
> it would connect to #politics <at> libera.chat (which doesn't exist, and
> would redirect to ##politics).
This one is in fact what this entire bug (#48598) is about. On the
surface (at least in your case), the initial blame falls on the autojoin
module, whose flaws any simple half measure might paper over well
enough. But the "confusion" revealed by those flaws runs deeper and
speaks to foundational problems that (IMO) need addressing if ERC is to
remain relevant much longer.
> This is with the new ERC on Emacs 28, that when connecting to
> different servers directly, would /not/ be confused (i.e., two
> buffers were created: “#emacs/tilde.chat”, “#emacs/libera.chat”).
Unfortunately, distinct connections like this aren't immune either. For
example, relinking previously used target buffers can still fail when
endpoints share the same host but different ports.
What's happening in both cases is that ERC makes presumptions about
session semantics based on dialed connection details instead of waiting
for authoritative info to arrive to better inform those decisions. And
for other, truly ambiguous situations, ERC (unlike most clients) doesn't
allow users to declare their intentions upfront but rather insists that
it knows best. Which leads to problems like yours. In ERC's mind, you're
connecting twice to server-network-thingy znc.tilde.team instead of to
networks Libera.Chat and tilde.chat [1].
> To be honest, I'd never used ZNC before either, so it's possible I
> set /that/ up wrong…
ZNC is off the hook here. The problem lies squarely with ERC.
> - Re-connection issues: I'm on a laptop so the connection drops in and
> out. That's not the problem, but ERC was not so smart with
> reconnecting. I'd run /reconnect in a server buffer, or try to map
> the command over servers, and it'd reconnect but my nick would be
> acdw` or similar. I don't think this is ERC's issue /per se/, but
> Circe, e.g., handles it better, afaik.
For this one, I'd have to see some protocol logs before offering
anything of value because a number of factors influence the fate of
reconnection attempts. But just to speculate...
I'm assuming we're talking sans bouncer here (?) because your nick and
authentication status would've remained steady otherwise. I'm also
nixing anything involving client certs [2], based on the config you've
shared. So, ignoring the unlikely possibility you were using auth-source
to supply creds via a repurposed server password [3], I'm going to
assume you were doing the dreaded NickServ dance [4].
But without logs, I can only naively attribute this to some combination
of ERC's rather byzantine reconnect logic [5] and a vague heuristics
failure on the part of the services module in trying to reclaim your
nick. (The smart money's on my being wrong, of course.)
> That's really all I remember, I hope this is helpful. ERC is, on the
> whole, pretty good, and I might switch back later!
Well, if you ever do manage to cast off the spell of that other client
and transmutate back into a disgruntled primate, please take this bug's
proposed changes for a spin [6]. But even if that never happens, the
info you've provided here is very much appreciated. Thanks again.
Notes
~~~~~
[1] If you'll allow me to punctuate that by interjecting with a plug
here for anyone similarly affected: my current patches for this bug
take an aggressive but targeted (meaning still broadly conservative)
approach toward tackling this kind of confusion:
https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
[2] I mention this because there's an outstanding bug in this area:
https://lists.gnu.org/archive/html/emacs-erc/2021-05/msg00002.html
Gone in [1], FWIW (though likely replaced by dozens more!).
[3] In case you're not familiar, this "PASS user:pwd" convention is a
poor man's SASL-like legacy feature/hack supported by some public
networks. An associated netrc entry might look something like:
machine foo.chat login acdw password acdw:mypass
This matters if I'm wrong (and you *were* attempting to use it)
because it should always succeed on servers that allow it. And it
should do so without any limbo period during which you're not fully
authenticated (its reason for existing, AFAICT).
[4] "Dreaded" in the sense that it's vital to a session's health but
relies on servers acting predictably in areas not governed by any
standard.
For example, `erc-nickserv-identify-on-nick-change' can optionally
attempt to identify you to nick services after receiving a NICK
message confirming the successful granting of your nickname, which
is often the polar opposite of what you want, depending on how your
network is configured. But this isn't currently adjustable per
network; like so many thing ERC, it's all or nothing across the
board.
Similarly, `erc-nickserv-identify-autodetect' runs on NOTICE, but
some IRCds send 433 ERR_NICKNAMEINUSE errors straight away before
even letting you engage nick services. This at least obviates the
need to scrape NOTICEs, but it demands a level of flexibility that
erc-services.el just isn't equipped to offer. Accommodating this
would at the very least involve tweaking how `erc-nickserv-identify'
treats `erc-nickserv-alist-use-nick-p', perhaps by caching the most
recently denied nick for use in the next IDENTIFY message.
Luckily, this is a corner-ish case, and most public networks just
speculatively grant whatever nick you've asked for unless it's
already been taken by another connection, in which case you're met
with that familiar uniquifying backtick (courtesy of the default
433/437 handling). Anyhow, with the world moving on to SASL, the
role of the services module will only continue to diminish. And
that's a good thing, IMO.
[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50007
[6] Also available to try in package form (just disregard anything
involving IRCv3):
https://gitlab.com/jpneverwas/erc-v3/-/wikis/home.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 10 Sep 2021 12:44:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Libera.Chat user aindilis recently reported seeing incoming messages
multiple times (once per connection) on an Emacs 26.1 connected to a ZNC
1.7.2 instance. I was able to reproduce this using Emacs 27.2 and ZNC
1.8. What's more, when applying the same repro recipe to a fresh 28 [1],
symptoms differed only superficially [2], suggesting all roads lead to
bug#48598 (and its predecessors). The attached logs paint the whole
picture, but here's a basic rundown:
On 27, with two connections and one "common" channel, only two buffers
are created: a server buffer, claimed by both processes (in a seesawing
tug of war), and a channel buffer, which goes to the most recently
JOIN'ed (here, the second process [3]). As a result, the first process
must resort to using the disputed server buffer for displaying its
orphaned messages. But since that's "shared", it's forced to wait while
messages pile up. And before long, it misses a PONG or two, and a
timeout is triggered to sever the connection [4].
After this, the reconnect facility swoops in and tries to do its job,
but it can only see connection properties belonging to the second
process. That's because all local vars get clobbered whenever `erc-open'
runs. Anyway, the punchline is that ZNC is perfectly happy to serve two
effectively identical connections, which is where all the dupes come
from.
[1] See scratch.log, attached.
[2] Mainly on account of 88567ca8ec "Fix erc-reuse-buffers behavior":
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=88567ca8ec
[3] In the attached logs, the first connection is called "foonet" and
the second "barnet".
[4] Search for "Timeout" in protocol.log (attached). Note that the
logger's labels also get confused, and it's actually foonet's
process that dies.
[chan.log (text/plain, attachment)]
[ibuffer.log (text/plain, attachment)]
[protocol.log (text/plain, attachment)]
[scratch.log (text/plain, attachment)]
[server.log (text/plain, attachment)]
[znc.log (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 16 Oct 2021 21:16:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 48598 <at> debbugs.gnu.org (full text, mbox):
J.P. [2021-06-25 Fri 06:18] wrote:
> [1] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
Tried the patches against Emacs 28.0.60.
The issue of reusing existing buffers for different networks due to same
channel name is gone.
Thank you very much for the code.
--
Daniel Fleischer
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 16 Oct 2021 23:22:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Daniel Fleischer <danflscr <at> gmail.com> writes:
> J.P. [2021-06-25 Fri 06:18] wrote:
>
>> [1] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
>
> Tried the patches against Emacs 28.0.60.
>
> The issue of reusing existing buffers for different networks due to same
> channel name is gone.
>
> Thank you very much for the code.
You're very welcome. I'm delighted you took a sec to report back. Thanks
a million!
(To any other affected folk reading this: please follow suit. I'll be
providing another progress report shortly detailing the latest changes.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 11 Nov 2021 05:25:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> (To any other affected folk reading this: please follow suit. I'll be
> providing another progress report shortly detailing the latest changes.)
This was three weeks ago. Can you post the in-progress patches here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Message #42 received at 48598-quiet <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks. I'll also add the debbugs link to the thread.
[0001-Fall-back-on-dialed-server-names-in-erc-join.patch (text/x-patch, attachment)]
[0002-Don-t-set-erc-server-announced-name-unless-known.patch (text/x-patch, attachment)]
[0003-Require-erc-networks-in-erc.el.patch (text/x-patch, attachment)]
[0004-Update-ISUPPORT-handling-in-ERC.patch (text/x-patch, attachment)]
[0005-Recognize-ascii-and-strict-CASEMAPPINGs-in-ERC.patch (text/x-patch, attachment)]
[0006-Make-ERC-respect-spaces-in-server-passwords.patch (text/x-patch, attachment)]
[0007-Add-helper-to-determine-local-channels-in-ERC.patch (text/x-patch, attachment)]
[0008-Add-eventual-replacement-for-erc-default-recipients.patch (text/x-patch, attachment)]
[0009-Discourage-ill-defined-use-of-buffer-targets-in-ERC.patch (text/x-patch, attachment)]
[0010-Add-ERC-test-server-and-related-resources.patch (text/x-patch, attachment)]
[0011-Add-user-oriented-test-scenarios-for-ERC.patch (text/x-patch, attachment)]
[0012-Update-ERC-scenarios-with-session-centric-naming.patch (text/x-patch, attachment)]
[0013-Address-long-standing-ERC-buffer-naming-issues.patch (text/x-patch, attachment)]
[0014-Register-erc-kill-buffer-function-locally.patch (text/x-patch, attachment)]
[0015-Don-t-call-erc-auto-query-twice-on-PRIVMSG.patch (text/x-patch, attachment)]
[0016-SQUASH-ME-Add-ERC-scenarios-for-session-aware-msg-ha.patch (text/x-patch, attachment)]
[0017-Favor-session-IDs-and-networks-in-erc-join.patch (text/x-patch, attachment)]
[0018-SQUASH-ME-Add-ERC-test-scenarios-for-session-aware-a.patch (text/x-patch, attachment)]
[0019-Standardize-auth-source-queries-in-ERC.patch (text/x-patch, attachment)]
[0020-Make-auth-source-searches-session-ID-aware-in-ERC.patch (text/x-patch, attachment)]
[0021-SQUASH-ME-Add-ERC-test-scenarios-involving-auth-sour.patch (text/x-patch, attachment)]
[0022-SQUASH-ME-Add-ERC-test-scenario-for-erc-cmd-JOIN.patch (text/x-patch, attachment)]
[0023-Update-ERC-s-Info-doc-with-session-ID-related-change.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 11 Nov 2021 10:28:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> "J.P." <jp <at> neverwas.me> writes:
>
>> (To any other affected folk reading this: please follow suit. I'll be
>> providing another progress report shortly detailing the latest changes.)
>
> This was three weeks ago. Can you post the in-progress patches here?
Sorry, three weeks is too long. For others following along, I posted the
patches directly to debbugs to spare you all a patch bomb.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598#42
If that was unnecessary, someone please say so. Thanks.
P.S. I really will be providing a general update/progress report "shortly".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 11 Nov 2021 12:09:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> Sorry, three weeks is too long. For others following along, I posted the
> patches directly to debbugs to spare you all a patch bomb.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598#42
>
> If that was unnecessary, someone please say so. Thanks.
It's great having the patch series in the bug tracker, too -- it's
generally helpful from a code archaeology perspective, where we
frequently look into 20 year old changes and wonder what the reasoning
and history behind it all was, and external URLs have usually died a
long time ago.
So in 20 years time, somebody may be staring at this bug report, and if
that's the case: Hi! Welcome back!
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 11 Nov 2021 15:14:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> "J.P." <jp <at> neverwas.me> writes:
>
> It's great having the patch series in the bug tracker, too -- it's
> generally helpful from a code archaeology perspective, where we
> frequently look into 20 year old changes and wonder what the reasoning
> and history behind it all was, and external URLs have usually died a
> long time ago.
Gotcha. I'll attach them to this upcoming progress report.
> So in 20 years time, somebody may be staring at this bug report, and if
> that's the case: Hi! Welcome back!
o/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 11 Nov 2021 15:17:02 GMT)
Full text and
rfc822 format available.
Message #54 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Update #4
With the six-month anniversary of this bug around the corner, another
progress report seemed appropriate.
Administrative
- I've cleared the /cc list for these updates because everyone on it is
already subscribed to emacs-erc anyway
- The version numbers for the fake ELPA packages introduced in update #3
have changed to something like 5.4.1.48598.20211024.5
- The repo path for the patches has changed as well [1], but the
download URL and the packages.el endpoint are still good [2]
- A checkpoint in the form of a random snapshot accompanies this post
Session IDs
Mentioned in update #2, the addition of an :id param for entry-point
commands `erc' and `erc-tls' remains in place. However, the local
variable `erc-session-id' previously used to store it is no more.
Instead, a composite type called `erc--sid' (currently a struct) takes
care of this, and a local variable called `erc--session' holds the
instances [3].
At the moment, the base scheme for these sessions includes:
1. a timestamp indicating when the session was created
2. a human friendly ID, unique across all sessions
And the default flavor [4] adds a couple more ingredients:
3. a sequence of components from which to construct 2
4. the length of the visible/active portion of 3
Server buffers
The option `erc-rename-buffers' was implemented rather oddly and only
operated on server buffers (which the doc string doesn't mention).
Regardless, this bug's patch set moves to deprecate it and change its
default value to t. But out of respect for tradition, the former
default of nil will still be honored (provided an :id wasn't passed to
`erc-open').
As for anyone unlucky enough to have accidentally set this to the old
default permanently: I suppose they'll have to settle for a more
reliable version of the old <n>-based uniquification behavior (for as
long as they ignore the deprecation warning, anyway). IOW, they too
should be free of any buffer-association problems.
Buffer targets
The variable `erc-default-recipients' and its various helpers can't be
relied upon to produce consistent behavior if we're to respect the
existing API [5]. The aspects in question have been around almost a
quarter century, and even though I'd wager no one's ever used them, we
likely can't go about "fixing" them now. Instead, I've provided what
are hopefully more consistent alternatives for use in newer code. I've
held off on weaving them into existing code, but doing so would free
us from continually checking whether targets are channels or queries.
These "alternatives" are currently just a local variable called
`erc--buffer-target' and a struct called `erc--target'. The former
holds instances of the latter, which is composed of:
1. a string with the original name as received from the server
2. a casemapped symbol for quick `eq' testing
3. a boolean indicating whether this target is a channel
4. a boolean indicating whether this target is a local channel
I didn't add any public getters or setters here either but certainly
can if needed. We could also make 3 and (maybe) 4 distinct subtypes,
but I don't see any clear advantage in doing so.
Auth-source
I've also attempted to unify auth-source lookups and make their
results more predictable based on context. IMO, both the session
parameters and the "type" of credentials sought (NickServ, certfp,
PASS, etc.) really do matter and shouldn't be painted with the same
brush. I'm not terribly enthused by my current approach, so please
offer suggestions/alternatives/shade.
Auto-join
A recent commit improved the situation here for the better [6], but it
also altered the default behavior, which at least one person on Libera
has pointed out. (Actually, with regard to the behavior in question,
the commit merely restored an earlier practice of favoring announced
names over dialed ones.) Anyway, in the spirit of minimizing churn, it
may be more prudent to fall back on *always* matching dialed servers.
I've recently added a patch to that effect as the first in this
series, but it (along with most everything else) needs proper vetting.
Notes
~~~~~
[1] AFAIK, GitLab doesn't provide patch-file based interdiffing, so
comparing iterations is a sad affair, but here's the updated path
anyway:
https://gitlab.com/jpneverwas/erc-tools/-/tree/master/bugs/48598/patches/wip
(I also keep a standalone ERC repo with patches from another bug
applied periodically. If doing the same for this bug would make
staying abreast of changes easier, someone please say so.)
[2] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
[3] I've stuck with the term "session" to describe the kind of logical
IRC connection that outlasts physical connections but (currently)
dies along with Emacs. If someone has a better suggestion, I'm all
ears. For the struct, I went with SID because it's shorter than ESID
(effective) or LSID (logical), etc. Also, all new functions and
variables (save for options) follow the internal double-hyphen
convention. I figure we can always add getters/setters later as
needed.
[4] As things stand, a session can either be "assigned" by the user or
"derived" from session parameters available for discovery by MOTD's
end (the logical connection boundary). For the default "derived"
variant, IDs are rendered as paths, presumably from some hierarchy
whose first two levels are the network and the normalized nick. The
length (4) can normally only be incremented. When it is, the id (2)
is recomputed. The same goes for whenever the components (3) change,
like in the case of a re-NICK.
[5] I'm speaking specifically about the fact that this variable often
holds more than one item and that these can be (but usually aren't)
non-strings. These peculiar facets were present in the very first
commit to the CVS repo back in 2001 and haven't changed since.
https://gitlab.com/jpneverwas/og-erc/-/blame/master/erc.el#L4990
[6] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9bb8d90cdd
[0001-Fall-back-on-dialed-server-names-in-erc-join.patch (text/x-patch, attachment)]
[0002-Don-t-set-erc-server-announced-name-unless-known.patch (text/x-patch, attachment)]
[0003-Require-erc-networks-in-erc.el.patch (text/x-patch, attachment)]
[0004-Update-ISUPPORT-handling-in-ERC.patch (text/x-patch, attachment)]
[0005-Recognize-ascii-and-strict-CASEMAPPINGs-in-ERC.patch (text/x-patch, attachment)]
[0006-Make-ERC-respect-spaces-in-server-passwords.patch (text/x-patch, attachment)]
[0007-Add-helper-to-determine-local-channels-in-ERC.patch (text/x-patch, attachment)]
[0008-Add-eventual-replacement-for-erc-default-recipients.patch (text/x-patch, attachment)]
[0009-Discourage-ill-defined-use-of-buffer-targets-in-ERC.patch (text/x-patch, attachment)]
[0010-Add-ERC-test-server-and-related-resources.patch (text/x-patch, attachment)]
[0011-Add-user-oriented-test-scenarios-for-ERC.patch (text/x-patch, attachment)]
[0012-Update-ERC-scenarios-with-session-centric-naming.patch (text/x-patch, attachment)]
[0013-Address-long-standing-ERC-buffer-naming-issues.patch (text/x-patch, attachment)]
[0014-Register-erc-kill-buffer-function-locally.patch (text/x-patch, attachment)]
[0015-Don-t-call-erc-auto-query-twice-on-PRIVMSG.patch (text/x-patch, attachment)]
[0016-SQUASH-ME-Add-ERC-scenarios-for-session-aware-msg-ha.patch (text/x-patch, attachment)]
[0017-Favor-session-IDs-and-networks-in-erc-join.patch (text/x-patch, attachment)]
[0018-SQUASH-ME-Add-ERC-test-scenarios-for-session-aware-a.patch (text/x-patch, attachment)]
[0019-Standardize-auth-source-queries-in-ERC.patch (text/x-patch, attachment)]
[0020-Make-auth-source-searches-session-ID-aware-in-ERC.patch (text/x-patch, attachment)]
[0021-SQUASH-ME-Add-ERC-test-scenarios-involving-auth-sour.patch (text/x-patch, attachment)]
[0022-SQUASH-ME-Add-ERC-test-scenario-for-erc-cmd-JOIN.patch (text/x-patch, attachment)]
[0023-Update-ERC-s-Info-doc-with-session-ID-related-change.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 14 Mar 2022 13:09:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Update #5.
Naming
The travails of trying to make the term "session" stick in some form or
fashion have led me to abandon the effort entirely. At the end of the
day, it's just too overloaded (not least within ERC itself). Instead,
I've opted to lean on the inherent namespacing provided by the
erc-networks module(/feature) and base everything around the arguably
more ambiguous `erc-networks--id'.
As a consequence, nearly all new naming- and identity-related functions
have been relocated to erc-networks.el and rebranded under its feature
banner. IMO, this is much more maintainable because nearly everything
associated with this initiative now lives under one roof. Moreover,
it's come to my attention that the term "network identity" has been
adopted by an influential project for much the same purpose.
Targets
There's been a change in course with respect to the makeup of internal
buffer-target objects. At the time of the last update (#4), a unified
struct played host to all three flavors: query, channel, and local
channel. I've since decided to err instead on the side of inheritance,
albeit for equally flimsy reasons (like, for example, that it's easier
to dispatch on struct type should the need arise). But the move may
also allow for a more convenient means of separation if we ever want to
track variant-specific state that's also context dependent (e.g.,
detached, parted, etc.) or store miscellaneous ephemera, such as
short-lived timers watching for server-initiated MODE bursts (324/329).
Compat
Additional efforts to unify ERC's interactions with auth-source have
led to the possible need to require erc-compat by default. I've held
off on doing so proactively, but it may end up being inevitable. As a
side note, related changes made to this working version of 5.4.1 by a
well-meaning visitor[1] (obviously unaware that we're tethered to
27) will be nullified by this series.
Riders
I've tacked on another piggyback patch (at least temporarily) for the
same tenuous reason as before: its tests depend on changes introduced
herein. This one, though, affects basic functionality and has to do
with ERC only partially exempting PONGs from flood protection -- PONGs
and any other "forced" outgoing messages. (Un)surprisingly, this issue
has always existed but has only recently come to light due to the
growing popularity of a newish bouncer called Soju and its apparent
practice of using a PING's nonce for ACKing[2]. The end result is ERC
users being unable to transmit during times of heavy aggregate traffic.
And without modern features like `echo-message' available, users are
left to suffer in the dark, wondering what gives.
Until next time,
J.P.
P.S. As always, the attached snapshot is mainly for posterity, and the
latest set can be found elsewhere[3].
[1] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ad5cf84f
[2] https://git.sr.ht/~emersion/soju/tree/fdf97276/item/downstream.go#L604
[3] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
[0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch (text/x-patch, attachment)]
[0002-Allow-exemption-from-flood-penalty-in-erc-backend.patch (text/x-patch, attachment)]
[0003-Don-t-set-erc-server-announced-name-unless-known.patch (text/x-patch, attachment)]
[0004-Require-erc-networks-in-erc.el.patch (text/x-patch, attachment)]
[0005-Update-ISUPPORT-handling-in-ERC.patch (text/x-patch, attachment)]
[0006-Recognize-ascii-and-strict-CASEMAPPINGs-in-ERC.patch (text/x-patch, attachment)]
[0007-Make-ERC-respect-spaces-in-server-passwords.patch (text/x-patch, attachment)]
[0008-Add-helper-to-determine-local-channels-in-ERC.patch (text/x-patch, attachment)]
[0009-Add-eventual-replacement-for-erc-default-recipients.patch (text/x-patch, attachment)]
[0010-Discourage-ill-defined-use-of-buffer-targets-in-ERC.patch (text/x-patch, attachment)]
[0011-Add-ERC-test-server-and-related-resources.patch (text/x-patch, attachment)]
[0012-Address-long-standing-ERC-buffer-naming-issues.patch (text/x-patch, attachment)]
[0013-SQUASH-ME-Add-user-oriented-test-scenarios-for-ERC.patch (text/x-patch, attachment)]
[0014-Register-erc-kill-buffer-function-locally.patch (text/x-patch, attachment)]
[0015-Don-t-call-erc-auto-query-twice-on-PRIVMSG.patch (text/x-patch, attachment)]
[0016-SQUASH-ME-Add-ERC-scenarios-for-identity-aware-msg-h.patch (text/x-patch, attachment)]
[0017-Favor-network-identities-in-erc-join.patch (text/x-patch, attachment)]
[0018-SQUASH-ME-Add-ERC-test-scenarios-for-identity-aware-.patch (text/x-patch, attachment)]
[0019-Standardize-auth-source-queries-in-ERC.patch (text/x-patch, attachment)]
[0020-SQUASH-ME-Add-ERC-test-scenarios-involving-auth-sour.patch (text/x-patch, attachment)]
[0021-SQUASH-ME-Add-ERC-test-scenario-for-erc-cmd-JOIN.patch (text/x-patch, attachment)]
[0022-Update-ERC-s-Info-doc-with-network-ID-related-change.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 09 Apr 2022 21:15:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi people,
I'm seeking feedback on (and perhaps tacit approval for) the following
files and their layout. AFAICT, aside from the whole
test/lisp/foo-tests.el -> lisp/foo.el
correspondence for Make discovery, there doesn't seem to be much in the
way of rigid rules regarding naming, layout, or dependency inclusion.
(For anyone following this bug, none of those aspects has changed
dramatically in the past year or so with regard to these files).
test/lisp/erc
├── erc-d
│ ├── erc-d.el
│ ├── erc-d-i.el
│ ├── erc-d-self.el
│ ├── erc-d-self-resources
│ │ ├── basic.eld
│ │ ├── depleted.eld
│ │ ├── drop-a.eld
│ │ ├── drop-b.eld
│ │ ├── dynamic-barnet.eld
│ │ ├── dynamic.eld
│ │ ├── dynamic-foonet.eld
│ │ ├── dynamic-stub.eld
│ │ ├── eof.eld
│ │ ├── fuzzy.eld
│ │ ├── incremental.eld
│ │ ├── irc-parser-tests.eld
│ │ ├── linger.eld
│ │ ├── linger-multi-a.eld
│ │ ├── linger-multi-b.eld
│ │ ├── no-block.eld
│ │ ├── no-match.eld
│ │ ├── nonstandard.eld
│ │ ├── no-pong.eld
│ │ ├── proxy-barnet.eld
│ │ ├── proxy-foonet.eld
│ │ ├── proxy-solo.eld
│ │ ├── proxy-subprocess.el
│ │ ├── timeout.eld
│ │ └── unexpected.eld
│ ├── erc-d-t.el
│ └── erc-d-u.el
├── erc-join-tests.el
├── erc-networks-tests.el
├── erc-scenarios-common.el
├── erc-scenarios.el
├── erc-scenarios-resources
│ ├── base
│ │ ├── association
│ │ │ ├── bouncer-history
│ │ │ │ ├── barnet.eld
│ │ │ │ └── foonet.eld
│ │ │ ├── multi-net
│ │ │ │ ├── barnet.eld
│ │ │ │ └── foonet.eld
│ │ │ ├── nick-bump
│ │ │ │ ├── renicked-again.eld
│ │ │ │ ├── renicked.eld
│ │ │ │ ├── renicked-foisted-again.eld
│ │ │ │ └── renicked-foisted.eld
│ │ │ ├── reconnect-playback
│ │ │ │ ├── foonet-again.eld
│ │ │ │ └── foonet.eld
│ │ │ └── same-network
│ │ │ ├── chester.eld
│ │ │ ├── tester-again.eld
│ │ │ └── tester.eld
│ │ ├── auth-source
│ │ │ ├── foonet.eld
│ │ │ └── nopass.eld
│ │ ├── channel-buffer-revival
│ │ │ └── foonet.eld
│ │ ├── flood
│ │ │ └── soju.eld
│ │ ├── gapless-connect
│ │ │ ├── barnet.eld
│ │ │ ├── foonet.eld
│ │ │ └── pass-stub.eld
│ │ ├── mask-target-routing
│ │ │ └── foonet.eld
│ │ ├── network-id
│ │ │ ├── bouncer
│ │ │ │ ├── barnet-again.eld
│ │ │ │ ├── barnet-drop.eld
│ │ │ │ ├── barnet.eld
│ │ │ │ ├── foonet-again.eld
│ │ │ │ ├── foonet-drop.eld
│ │ │ │ ├── foonet.eld
│ │ │ │ └── stub-again.eld
│ │ │ └── same-network
│ │ │ ├── chester.eld
│ │ │ └── tester.eld
│ │ ├── reconnect
│ │ │ ├── aborted-dupe.eld
│ │ │ ├── aborted.eld
│ │ │ ├── options-again.eld
│ │ │ ├── options.eld
│ │ │ ├── timer.eld
│ │ │ └── timer-last.eld
│ │ ├── renick
│ │ │ ├── queries
│ │ │ │ ├── bouncer-barnet.eld
│ │ │ │ ├── bouncer-foonet.eld
│ │ │ │ └── solo.eld
│ │ │ └── self
│ │ │ ├── auto.eld
│ │ │ ├── manual.eld
│ │ │ ├── qual-chester.eld
│ │ │ └── qual-tester.eld
│ │ └── reuse-buffers
│ │ ├── channel-buffers
│ │ │ ├── barnet.eld
│ │ │ └── foonet.eld
│ │ └── server-buffers
│ │ ├── barnet.eld
│ │ └── foonet.eld
│ ├── join
│ │ ├── legacy
│ │ │ └── foonet.eld
│ │ ├── network-id
│ │ │ ├── barnet.eld
│ │ │ ├── foonet-again.eld
│ │ │ └── foonet.eld
│ │ └── reconnect
│ │ ├── foonet-again.eld
│ │ └── foonet.eld
│ ├── networks
│ │ └── announced-missing
│ │ └── foonet.eld
│ └── services
│ ├── auth-source
│ │ └── libera.eld
│ └── password
│ └── libera.eld
├── erc-services-tests.el
└── erc-tests.el
The files above introduce around a hundred nontrivial tests that
lengthen the overall running time for the entire Emacs suite by roughly
five minutes on EMBA [1]. Bug#49860 will likely stretch this by another
two. In spite of the cost, their utility extends to indirectly testing
the basic behavioral contracts of other libraries as well. The only
episode in the past year where these encountered any difficulty was in
the immediate wake of
commit 0c7a7433dce1b93a685396986d3a560c9cc291f1
Author: Miha Rihtaršič <miha <at> kamnitnik.top>
Date: Tue May 25 21:01:58 2021 +0200
Try to not prioritise reading from lower file descriptors
* src/process.c (wait_reading_process_output): When looping through
fds, continue from where we left off.
(syms_of_process): Vprocess_prioritize_lower_fds: New variable
(bug#48118).
But that was a good thing because the only tests affected were those
intentionally demonstrating undesirable behavior.
A few of the more relevant patches are attached below, but the full set
is also available [2]. General comments and random spot checks are, of
course, always welcome.
Thanks,
J.P.
[1] https://emba.gnu.org/emacs/emacs/-/jobs/42826
FWIW, it's more like two minutes on normal PCs and commercial cloud
infra, like Gitlab.com's GCP runners.
[2] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
[0016-Add-ERC-test-server-and-related-resources.patch (text/x-patch, attachment)]
[0018-SQUASH-ME-Add-user-oriented-test-scenarios-for-ERC.patch (text/x-patch, attachment)]
[0021-SQUASH-ME-Add-ERC-scenarios-for-identity-aware-msg-h.patch (text/x-patch, attachment)]
[0023-SQUASH-ME-Add-ERC-test-scenarios-for-identity-aware-.patch (text/x-patch, attachment)]
[0025-SQUASH-ME-Add-ERC-test-scenarios-involving-auth-sour.patch (text/x-patch, attachment)]
[0026-SQUASH-ME-Add-ERC-test-scenario-for-erc-cmd-JOIN.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 09 Apr 2022 21:23:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi people,
I Cc'd Damien because a few of these questions involve auth-source-pass,
and also Sam because they recently touched related areas in ERC. But
anyone in the know, please don't hold back. Your input is welcome.
In this bug set, I'm trying to make ERC smarter about how it integrates
with auth-source. The current implementation suffers directly from the
central problem this bug aims to address, namely, ERC's inability to
understand the concept of logical (IRC) connections and how they relate
to physical (TCP) connections.
Strategies stemming from this improved awareness require a prioritizing
of auth-source entries, not only when choosing query parameters but when
filtering returned results. In particular, various compatibility
crutches were required to make auth-source-pass produce output
conforming to the shape and substance delivered by the netrc back end.
The following patch set contains various unsightly machinations meant to
force a more agreeable outcome (agreeable to ERC, that is).
What I'm seeking from you (all) is confirmation that these patches don't
suffer from any glaring misconceptions regarding the API. Note that I'm
certainly *not* requesting any upstream changes, perhaps in part because
ERC is tethered to the past (currently 27.2), so we'd have to wait an
eternity before reaping any reward.
Anyway, when you have a sec, please glance briefly at the following
areas, all of them located in the first patch attached below:
1. The new option `erc-auth-source-parameters-function'.
2. The ERT tests residing in test/lisp/erc/erc-services-tests.el.
Those should convey a feel for the behavior ERC is expecting.
3. The various business-related functions that touch the API in
lisp/erc/erc.el.
4. The ugly adapters touching internal auth-source functions in
lisp/erc/erc-compat.el.
The reaction I'm hoping for is something along the lines of "I see what
you're doing, and no, auth-source doesn't provide that OOTB, so knock
yourself out" or, conversely, "lo, you're going about that all wrong,
use this instead."
Thanks,
J.P.
P.S. For additional context, the full patch series can be found at
https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
and additional integrations involving SASL can be found in #49860.
[0024-Standardize-auth-source-queries-in-ERC.patch (text/x-patch, attachment)]
[0025-SQUASH-ME-Add-ERC-test-scenarios-involving-auth-sour.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sun, 10 Apr 2022 12:50:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> The files above introduce around a hundred nontrivial tests that
> lengthen the overall running time for the entire Emacs suite by roughly
> five minutes on EMBA [1]. Bug#49860 will likely stretch this by another
> two. In spite of the cost, their utility extends to indirectly testing
> the basic behavioral contracts of other libraries as well.
It's a rather significant increase... Perhaps Michael has an opinion
here; added to the CCs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 11 Apr 2022 08:01:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi,
>> The files above introduce around a hundred nontrivial tests that
>> lengthen the overall running time for the entire Emacs suite by roughly
>> five minutes on EMBA [1]. Bug#49860 will likely stretch this by another
>> two. In spite of the cost, their utility extends to indirectly testing
>> the basic behavioral contracts of other libraries as well.
>
> It's a rather significant increase... Perhaps Michael has an opinion
> here; added to the CCs.
On EMBA, tests will run only per subdirectories like test/lisp/erc. As
long as all ERC related tests are located there, these tests are
triggered only when there is a change in lisp/erc/* or
test/lisp/erc/*. No problem.
Furthermore, whole tests are run on EMBA every 8 hours. They last
several hours, an increase by 5-7 minutes doesn't count.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 11 Apr 2022 10:22:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> On EMBA, tests will run only per subdirectories like test/lisp/erc. As
> long as all ERC related tests are located there, these tests are
> triggered only when there is a change in lisp/erc/* or
> test/lisp/erc/*. No problem.
If these tests take five minutes, then they're presumably marked as
expensive, so they won't get run by a normal "make check" anyway? (I
haven't actually checked the patch.)
> Furthermore, whole tests are run on EMBA every 8 hours. They last
> several hours, an increase by 5-7 minutes doesn't count.
Sounds good, then.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 11 Apr 2022 13:30:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> On EMBA, tests will run only per subdirectories like test/lisp/erc. As
>> long as all ERC related tests are located there, these tests are
>> triggered only when there is a change in lisp/erc/* or
>> test/lisp/erc/*. No problem.
Thanks for the lowdown, Michael. The tests that matter live directly
under test/lisp/erc. The deeper ones
test/lisp/erc
├── erc-d
│ ├── erc-d-self.el <~~ like this thing
only target fixtures and other apparati, so they can be skipped if need
be. But if they're swept up for the bigger 8-hourly runs, that's fine
too.
> If these tests take five minutes, then they're presumably marked as
> expensive, so they won't get run by a normal "make check" anyway? (I
> haven't actually checked the patch.)
Lars, thanks for looking at this (and my other bugs). I meant five
minutes in aggregate. The vast majority take fractions of a second, and
the ones that don't mostly reside in a single file (log attached). I
haven't yet tagged any as expensive but certainly can. CONTRIBUTE says
"longer than some few seconds", so I guess maybe a dozen or so in that
EMBA log fit the bill. Should I go ahead and tag them?
[erc-scenarios.log (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 11 Apr 2022 15:35:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> Lars, thanks for looking at this (and my other bugs). I meant five
> minutes in aggregate. The vast majority take fractions of a second, and
> the ones that don't mostly reside in a single file (log attached).
"make -j32 check" takes 22 seconds for me on my build machine, but if
the tests can be run in parallel then the impact won't be great.
> I haven't yet tagged any as expensive but certainly can. CONTRIBUTE
> says "longer than some few seconds", so I guess maybe a dozen or so in
> that EMBA log fit the bill. Should I go ahead and tag them?
Yes, please.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Tue, 12 Apr 2022 07:51:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
Hi,
>>> On EMBA, tests will run only per subdirectories like test/lisp/erc. As
>>> long as all ERC related tests are located there, these tests are
>>> triggered only when there is a change in lisp/erc/* or
>>> test/lisp/erc/*. No problem.
>
> Thanks for the lowdown, Michael. The tests that matter live directly
> under test/lisp/erc. The deeper ones
>
> test/lisp/erc
> ├── erc-d
> │ ├── erc-d-self.el <~~ like this thing
>
> only target fixtures and other apparati, so they can be skipped if need
> be. But if they're swept up for the bigger 8-hourly runs, that's fine
> too.
The test targets for EMBA are generated. If there is a subdirectory
test/lisp/erc/erc-d, a respective target will appear.
The test-all-inotify job covers all tests, also the tests in subsubdirectories.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 15 Apr 2022 13:03:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> writes:
> The test targets for EMBA are generated. If there is a subdirectory
> test/lisp/erc/erc-d, a respective target will appear.
>
> The test-all-inotify job covers all tests, also the tests in subsubdirectories.
>
> Best regards, Michael.
Thanks for patiently explaining yet again. I really should've been more
mindful of your time and studied up a bit before reaching out. But if
you'll allow me more excuses, part of what threw me about the
subdir-discovery situation was that the "normal" stage of the initial
(new branch) pipeline of fix/bug-48598 didn't include a job named
test-lisp-erc-erc-d-inotify [1].
And not that this matters in the slightest, but in an ideal world, *all*
of ERC's stable tests would *always* run (including the expensive ones),
both for jobs in diff-based, push pipelines (test-lisp-erc*-inotify) and
those in the thrice-daily, scheduled ones (test-all-inotify). Also ideal
would be having those tests that live in subdirs of test/lisp/erc (such
as test/lisp/erc/erc-d) run as part of the "main" job
(test-lisp-erc-inotify) rather than only when some change touches their
little area.
FWIW, I've attached some shoddy infra-related patches, mainly as a means
of better illustrating the aforementioned pie-in-the-sky behavior [2].
Regardless, I realize that giving ERC special treatment is likely not in
the cards. As such, I'm planning on rigging up our own CI setup for
testing proposed changes that hit the bug tracker (especially against
older Emacs versions) [3]. When the time comes, any guidance you might
spare will be greatly appreciated.
Thanks,
J.P.
P.S. I'll try and refrain from bothering you again in the (immediate)
future.
[1] https://emba.gnu.org/emacs/emacs/-/pipelines/16954
I suppose that's because it was based on a preexisting
test/infra/test-jobs.yml (?).
[2] That said, a flimsy rationale for the first one might be that it
makes it slightly easier on external tooling trying to leverage
existing in-tree recipes (but that's probably a stretch). Right now,
I'm doing stuff like
make -C test SELECTOR="(...)" check-lisp-foo
everywhere. Not a major hassle, but it'd be nice to skip the
SELECTOR part, especially when invoking Make by hand. (Just a
thought.)
[3] If anyone out there cares, it'll also deploy ERC packages built from
open bug sets to our own little ELPA to make it easier on everyday
folks wanting to give feedback on proposed changes. Actually, we've
already been doing all of this for over a year, only this time
around, the idea is to make it less amateurish and have it run on
Savannah or somewhere other than big cloud infra.
[0001-POC-CHECK-Add-check-expensive-prefixes-for-test-subd.patch (text/x-patch, attachment)]
[0002-POC-CHECK-Allow-check-expensive-target-for-generated.patch (text/x-patch, attachment)]
[0001-POC-GROUP-Allow-shared-triggering-of-subdir-tests.patch (text/x-patch, attachment)]
[test-jobs-check.diff (text/x-patch, attachment)]
[test-jobs-check-want.yml (application/octet-stream, attachment)]
[test-jobs-group.diff (text/x-patch, attachment)]
[test-jobs-group-want.yml (application/octet-stream, attachment)]
[test-jobs-orig.yml (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 15 Apr 2022 15:06:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> Hi Michael,
Hi,
> Thanks for patiently explaining yet again. I really should've been more
> mindful of your time and studied up a bit before reaching out. But if
> you'll allow me more excuses, part of what threw me about the
> subdir-discovery situation was that the "normal" stage of the initial
> (new branch) pipeline of fix/bug-48598 didn't include a job named
> test-lisp-erc-erc-d-inotify [1].
These jobs are included via test/infra/test-jobs.yml. And, as the header
line of this file says, it is generated by "make generate-test-jobs".
I'd like to keep this workflow. If you want a new subdirectory erc/erc-d
being handled, you must regenerate this file, and commit it (maybe this
needs to be explained more descriptively?)
As you see in test/infra/Makefile, we apply already special cases for
subdirectories, namely src, eieio, faceup, so-long, and misc. If we need
to handle other special cases, it shall be in that Makefile.
As I see in your patches, you're going this way.
If it is just about your fix/bug-48598 branch, you can change whatever
you want. Of course, you can test the new emba workflow. But if you,
OTOH, just want to run a test for a given bug, you can provide a short
test/infra/gitlab-ci.yml with one or two jobs exactly for this purpose.
> And not that this matters in the slightest, but in an ideal world, *all*
> of ERC's stable tests would *always* run (including the expensive ones),
> both for jobs in diff-based, push pipelines (test-lisp-erc*-inotify) and
> those in the thrice-daily, scheduled ones (test-all-inotify).
It was a design goal to run only non-expensive tests immediately after
applying changes to the sources, in order to see problems fast. That's
why the expensive tests are located in the fat test-all-inotify job
only, running three timws a day. It is the responsibility of the
developer to decide, whether a test is essential, it shouldn't be tagged
as :expensive-test then.
> Also ideal would be having those tests that live in subdirs of
> test/lisp/erc (such as test/lisp/erc/erc-d) run as part of the "main"
> job (test-lisp-erc-inotify) rather than only when some change touches
> their little area.
Again, there are several sub- and subsubdirectories in test/*. It cannot
be decided by the generator how they depend on each other. One case
waiting for optimization is test/lisp/cedet with several
subsubdirectories.
If you are able to define such dependencies in the Makefile, and specify
for erc
make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d"
as special case, we're done. And if you really insist in running also
expensive tests, apply
make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d SELECTOR='(not (tag :unstable))'"
If you haven't unstable tests, "SELECTOR=t" would work as well.
There is no need to declare additional Makefile targets like
check-expensive-lisp-erc, we have selectors. See for example
test-native-comp-speed0 in test/infra/gitlab-ci.yml.
> FWIW, I've attached some shoddy infra-related patches, mainly as a means
> of better illustrating the aforementioned pie-in-the-sky behavior [2].
> Regardless, I realize that giving ERC special treatment is likely not in
> the cards. As such, I'm planning on rigging up our own CI setup for
> testing proposed changes that hit the bug tracker (especially against
> older Emacs versions) [3]. When the time comes, any guidance you might
> spare will be greatly appreciated.
>
> Thanks,
> J.P.
>
> P.S. I'll try and refrain from bothering you again in the (immediate)
> future.
Thanks for this. These days, I'm affected with some health problems, so
I cannot guarantee any reply in time. That's why I also gave your
patches a cursory reading only, w/o being able to comment on them in
detail just now. But I'll try to reply whenever you have further
proposals; I'm interested in your proposed changes.
> [1] https://emba.gnu.org/emacs/emacs/-/pipelines/16954
>
> I suppose that's because it was based on a preexisting
> test/infra/test-jobs.yml (?).
No, you must regenerate and push test/infra/test-jobs.yml as said above.
> [2] That said, a flimsy rationale for the first one might be that it
> makes it slightly easier on external tooling trying to leverage
> existing in-tree recipes (but that's probably a stretch). Right now,
> I'm doing stuff like
>
> make -C test SELECTOR="(...)" check-lisp-foo
>
> everywhere. Not a major hassle, but it'd be nice to skip the
> SELECTOR part, especially when invoking Make by hand. (Just a
> thought.)
At least for emba recipes, there's no hassle. And also for manual calls
I prefer the SELECTOR approach. In my tramp-tests.el, I have declared
more tags but the "official" ones described in README, so I always need
to discriminmate by SELECTOR. Not a big deal with shell's history.
> [3] If anyone out there cares, it'll also deploy ERC packages built from
> open bug sets to our own little ELPA to make it easier on everyday
> folks wanting to give feedback on proposed changes. Actually, we've
> already been doing all of this for over a year, only this time
> around, the idea is to make it less amateurish and have it run on
> Savannah or somewhere other than big cloud infra.
This I don't understand. Perhaps, we can discuss this later (I have a
vague idea on running CI/CD tests for ELPA packages on emba).
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 16 Apr 2022 01:14:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> These days, I'm affected with some health problems, so I cannot
> guarantee any reply in time.
So sorry to hear about your situation. If there's anything I can help
with in terms of knowledge preservation and continuity of operations,
please let me know. Although my skills are rather limited (relatively
speaking), I am quite adept at being loud and pushy, if that's of any
use.
Best wishes,
J.P.
P.S. I've commented on your other remarks, below, mainly for posterity;
please don't trouble yourself, unless you are bored.
> And, as the header line of this file says, it is generated by "make
> generate-test-jobs". I'd like to keep this workflow. If you want a new
> subdirectory erc/erc-d being handled, you must regenerate this file,
> and commit it (maybe this needs to be explained more descriptively?)
Nah, that header explains things plainly enough. That I saw it and still
managed to miss its broader implications just goes to show that some
people can't be helped.
> If it is just about your fix/bug-48598 branch, you can change whatever
> you want. Of course, you can test the new emba workflow. But if you,
> OTOH, just want to run a test for a given bug, you can provide a short
> test/infra/gitlab-ci.yml with one or two jobs exactly for this purpose.
That's lovely! I'll be (over)doing this from now on.
> It was a design goal to run only non-expensive tests immediately after
> applying changes to the sources, in order to see problems fast. That's
> why the expensive tests are located in the fat test-all-inotify job
> only, running three timws a day. It is the responsibility of the
> developer to decide, whether a test is essential, it shouldn't be tagged
> as :expensive-test then.
I have further thoughts and questions about this (some likely unpopular)
but will save them for another discussion.
> If you are able to define such dependencies in the Makefile, and specify
> for erc
>
> make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d"
>
> as special case, we're done. And if you really insist in running also
> expensive tests, apply
>
> make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d SELECTOR='(not (tag :unstable))'"
>
That's exactly what we (I) do in ERC's external CI/CD. And that's where
I think we ought to leave things, for now (external/independent, that
is). As far as EMBA is concerned, I'd rather just go with the flow and
not rock the boat.
> There is no need to declare additional Makefile targets like
> check-expensive-lisp-erc, we have selectors. See for example
> test-native-comp-speed0 in test/infra/gitlab-ci.yml.
Right. I guess I wrongly convinced myself that SELECTOR was something
meant to be used internally or for edge cases.
> At least for emba recipes, there's no hassle. And also for manual calls
> I prefer the SELECTOR approach. In my tramp-tests.el, I have declared
> more tags but the "official" ones described in README, so I always need
> to discriminmate by SELECTOR. Not a big deal with shell's history.
I am often in an ephemeral container. But copy-pasting is simple enough,
so, no, no hassle. I shouldn't have brought it up. (Forgive me.)
>> [3] If anyone out there cares, it'll also deploy ERC packages built from
>> open bug sets to our own little ELPA to make it easier on everyday
>> folks wanting to give feedback on proposed changes. Actually, we've
>> already been doing all of this for over a year, only this time
>> around, the idea is to make it less amateurish and have it run on
>> Savannah or somewhere other than big cloud infra.
>
> This I don't understand. Perhaps, we can discuss this later (I have a
> vague idea on running CI/CD tests for ELPA packages on emba).
I likewise shouldn't have brought this up either. We (I) have a separate
CI/CD workflow spanning a few interdependent GitLab.com projects.
There's also a package.el-compatible endpoint for (my) ERC patches,
currently located here:
https://jpneverwas.gitlab.io/erc-tools/archive/
Though functional, it's of poor quality (hence "amateurish") and needs
to be redone and relocated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sun, 17 Apr 2022 08:26:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
Hi,
>> If you are able to define such dependencies in the Makefile, and specify
>> for erc
>>
>> make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d"
>>
>> as special case, we're done. And if you really insist in running also
>> expensive tests, apply
>>
>> make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d SELECTOR='(not (tag :unstable))'"
Thinking about,
make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d SELECTOR='$(SELECTOR_EXPENSIVE)'"
is more future-proof. See test/README.
> Best wishes,
> J.P.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 18 Apr 2022 13:27:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi J.P.,
if auth-source-pass doesn't implement auth-source protocol, shouldn't we
try to improve it instead of working around it in all users of the
library? Am I missing something?
Best,
--
Damien Cassou
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 18 Apr 2022 14:26:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi Damien,
Damien Cassou <damien <at> cassou.me> writes:
> if auth-source-pass doesn't implement auth-source protocol, shouldn't we
> try to improve it instead of working around it in all users of the
> library? Am I missing something?
Thanks for getting back to me. I have no idea what the protocol entails.
I blindly based the proposed sketch around the behavior I observed from
the netrc back end alone. But my impressions and expectations may have
been misguided and/or unreasonable because none of those disparities
(between netrc and pass) seems essential to basic everyday use.
That said, if there were an effort to further align pass with netrc in
those other respects, I certainly wouldn't protest. The one catch from
ERC's POV is that we'd have to find a way to offer a suitable
integration experience for the older versions we support, right now 27
and 28. To me, suitable means ideally identical.
What I'd like to do for now is to figure out how realistic the
expectations are that I'm placing on auth-source as a protocol, in case
we want to support more back ends in the future. We're staking a
permanent public interface on these expectations, so I'd like to be as
confident as is reasonably possible. If you'd like, I can try to
summarize those expectations to spare you from having to glean them from
the various snippets I referenced in that last email.
Thanks so much,
J.P.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 18 Apr 2022 14:31:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Thinking about,
>
> make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d SELECTOR='$(SELECTOR_EXPENSIVE)'"
>
> is more future-proof. See test/README.
Ah, so it's right there in black and white, plain as day! Further
evidence I need to be culled from the herd. Thanks (of course).
On a tenuously related note, for some reason, I'm unable to run
make -C test -j<NN> check-lisp-erc ...
without incurring a "'warning: jobserver unavailable: using -j1". Plain
old -j without the <NN> works fine, and other targets I've tried, like
check and check-expensive, seem unaffected.
(Apologies if this is nonsense or old news or should be discussed
elsewhere: a cursory search on the bug tracker and the help list came up
empty, and the few hits on emacs-devel for "jobserver unavailable" were
all build-related red herrings, like [1].)
FWIW, the course of action prescribed by the info node "(make) Error
Messages", namely, prepending a "+", seems to remedy the problem.
diff --git a/test/Makefile.in b/test/Makefile.in
index 3b6e116e65..c0256d770d 100644
--- a/test/Makefile.in
+++ b/test/Makefile.in
@@ -247,7 +247,7 @@ define subdir_template
SUBDIR_TARGETS += check-$(subst /,-,$(1))
.PHONY: check-$(subst /,-,$(1))
check-$(subst /,-,$(1)):
- @${MAKE} check LOGFILES="$(patsubst %.el,%.log, \
+ +@${MAKE} check LOGFILES="$(patsubst %.el,%.log, \
$(patsubst $(srcdir)/%,%,$(wildcard ${srcdir}/$(1)/*.el)))"
endef
Sorry if that's just noise. As you're well aware, I know nothing! Thanks
again.
[1] https://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00720.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 18 Apr 2022 15:25:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi J.P.,
"J.P." <jp <at> neverwas.me> writes:
> If you'd like, I can try to summarize those expectations to spare you
> from having to glean them from the various snippets I referenced in
> that last email.
I don't feel confident enough in this area to give any feedback (and I
don't want to spend too much time getting confident enough). Maybe Ted,
the author of auth-source, could be of a better help?
Best
--
Damien Cassou
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 18 Apr 2022 16:45:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
Hi,
> On a tenuously related note, for some reason, I'm unable to run
>
> make -C test -j<NN> check-lisp-erc ...
>
> without incurring a "'warning: jobserver unavailable: using -j1". Plain
> old -j without the <NN> works fine, and other targets I've tried, like
> check and check-expensive, seem unaffected.
In test/infra/gitlab-ci.yml there is the comment
--8<---------------cut here---------------start------------->8---
# TODO: with make -j4 several of the tests were failing, for
# example shadowfile-tests, but passed without it.
--8<---------------cut here---------------end--------------->8---
I've never investigated what's up.
> FWIW, the course of action prescribed by the info node "(make) Error
> Messages", namely, prepending a "+", seems to remedy the problem.
>
> diff --git a/test/Makefile.in b/test/Makefile.in
> index 3b6e116e65..c0256d770d 100644
> --- a/test/Makefile.in
> +++ b/test/Makefile.in
> @@ -247,7 +247,7 @@ define subdir_template
> SUBDIR_TARGETS += check-$(subst /,-,$(1))
> .PHONY: check-$(subst /,-,$(1))
> check-$(subst /,-,$(1)):
> - @${MAKE} check LOGFILES="$(patsubst %.el,%.log, \
> + +@${MAKE} check LOGFILES="$(patsubst %.el,%.log, \
> $(patsubst $(srcdir)/%,%,$(wildcard ${srcdir}/$(1)/*.el)))"
> endef
If this fixes the problem, pls push the patch. And change the files
under test/infra/ accordingly, please.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 18 Apr 2022 16:53:01 GMT)
Full text and
rfc822 format available.
Message #111 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Damien Cassou <damien <at> cassou.me> writes:
Hi J.P.,
> "J.P." <jp <at> neverwas.me> writes:
>> If you'd like, I can try to summarize those expectations to spare you
>> from having to glean them from the various snippets I referenced in
>> that last email.
>
> I don't feel confident enough in this area to give any feedback (and I
> don't want to spend too much time getting confident enough). Maybe Ted,
> the author of auth-source, could be of a better help?
I have added also another backend to auth-source.el (secrets.el). I'm
not too familiar with the API, but I might be able to answer some basic
questions. Hopefully.
Of course, I cannot beat Ted.
> Best
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Wed, 20 Apr 2022 14:14:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
Damien Cassou <damien <at> cassou.me> writes:
> I don't feel confident enough in this area to give any feedback (and I
> don't want to spend too much time getting confident enough). Maybe Ted,
> the author of auth-source, could be of a better help?
Totally fair! And I see you've already Cc'd Ted. Thanks!
. . .
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I have added also another backend to auth-source.el (secrets.el). I'm
> not too familiar with the API, but I might be able to answer some basic
> questions. Hopefully.
>
> Of course, I cannot beat Ted.
That's very generous. Thank you. In fact, I've been playing around a bit
with the secrets back end and am pleased to report that it satisfies all
of ERCs expectations, making it the latest addition to the roster
alongside netrc, json, and plstore (integration tests for all attached).
While it may be tempting to single out pass, this part from the doc
string for `auth-source-search' says that ignoring :max and returning at
most one result is totally acceptable:
:max N means to try to return at most N items (defaults to 1).
More than N items may be returned, depending on the search and
the backend.
Now, I suppose it's safe to assume those back ends in auth-source.el
already supporting :max will continue to do so forever and that the
proposed kludges for pass [1] are likewise safe (as long as we only ever
apply them to 27 and 28).
What I'd like to know is actually something Damien had had the foresight
to raise initially but that I was too dim to grasp fully in the moment:
> if auth-source-pass doesn't implement auth-source protocol, shouldn't
> we try to improve it instead of working around it in all users of the
> library? Am I missing something?
In truth, without such an addition (adding :max to auth-source-pass),
I'm not sure it makes sense for ERC to shoot for pass support at all. So
ERC aside, would such a change be worthwhile from the perspective of
auth-source, seeing as pass is technically already fully compliant?
Thanks everyone,
J.P.
P.S. A couple minor questions crept up while I was typing this (tacked
on below [2]), but feel free to ignore.
[1] The proposed workarounds currently depend on these internal
functions:
- auth-source-pass--get-attr
- auth-source-pass--disambiguate
- auth-source-pass--find-match-unambiguous
- auth-source-backend-parse-parameters
They also include functionality recently provided by this commit:
commit b09ee1406205e8b6298411b9a18c1cd26e201689
Date: Sun Jun 27 17:36:00 2021 +0200
lisp/auth-source-pass.el: Support multiple hosts in search spec
* lisp/auth-source-pass.el (auth-source-pass-search): Accept a
list of strings for argument HOST.
[2] A couple (non-pass specific) questions:
- Is there anything obvious to watch out for in our integration
tests to avoid contaminating existing ones for auth-source or
secrets?
Right now, the only thing we attend to specifically is let-binding
`auth-source-do-cache' around every test.
- Are there any security-related gotchas to heed when retrieving a
bunch of secrets in bulk and sifting through them?
Currently, results are narrowed to the best candidate, and its
secret is returned as a string for (relatively) immediate
transmission. IOW, I don't think any obvious references to the
discarded ones remain, if that matters.
[0024-Standardize-auth-source-queries-in-ERC.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 21 Apr 2022 07:10:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> Hi all,
Hi,
A general remark: I haven't read the complete bug messages, so in case
I'm missing something pls point me to this. In fact, I'm focussing on
the auth-source releated problems; erc details are not important for me
just now.
Btw, I found it hard to scan a bug report with so many different
problems. Usually, it is more simple to discuss every problem in a
separate bug report, in order not to lose control. Except, all of them
are strongly dependent.
You have said somewhere there is an archive at
<https://jpneverwas.gitlab.io/erc-tools/archive/>. I cannot access this
URL. Is there another URL to be used?
> While it may be tempting to single out pass, this part from the doc
> string for `auth-source-search' says that ignoring :max and returning at
> most one result is totally acceptable:
>
> :max N means to try to return at most N items (defaults to 1).
> More than N items may be returned, depending on the search and
> the backend.
Indeed. In Tramp there are two calls of auth-source-search: One call in
order to retrieve the password, and there I use ':max 1' explicitly (see
`tramp-read-passwd'). And there is another function used for user/host
name completion, not looking for the password, and there I use ':max
most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former
case could refrain from specifying :max.
> Now, I suppose it's safe to assume those back ends in auth-source.el
> already supporting :max will continue to do so forever and that the
> proposed kludges for pass [1] are likewise safe (as long as we only ever
> apply them to 27 and 28).
>
> What I'd like to know is actually something Damien had had the foresight
> to raise initially but that I was too dim to grasp fully in the moment:
>
>> if auth-source-pass doesn't implement auth-source protocol, shouldn't
>> we try to improve it instead of working around it in all users of the
>> library? Am I missing something?
>
> In truth, without such an addition (adding :max to auth-source-pass),
> I'm not sure it makes sense for ERC to shoot for pass support at all. So
> ERC aside, would such a change be worthwhile from the perspective of
> auth-source, seeing as pass is technically already fully compliant?
Making auth-source-pass conform to the auth-source API would always be a
good thing™. I don't know whether there exist already such a bug report,
otherwise I recommend you to write a new report.
> [2] A couple (non-pass specific) questions:
>
> - Is there anything obvious to watch out for in our integration
> tests to avoid contaminating existing ones for auth-source or
> secrets?
I don't believe. Just follow the usual recommendation for ERT tests:
make a temporary environment for the test (for example, create a
temporary auth-source-pass store), run your test, remove test data (for
example, remove the temporary auth-source-pass store). That's how the
tests in auth-source-tests.el and auth-source-pass-tests.el are
designed, IIRC.
Since you don't want to test auth-source-pass functionality explicitly,
you can of course use any other auth-source backend. The scenario is the
same, and you could even provide several test functions like
erc-tests--auth-source-netrc, erc-tests--auth-source-json, and alike.
> Right now, the only thing we attend to specifically is let-binding
> `auth-source-do-cache' around every test.
>
> - Are there any security-related gotchas to heed when retrieving a
> bunch of secrets in bulk and sifting through them?
>
> Currently, results are narrowed to the best candidate, and its
> secret is returned as a string for (relatively) immediate
> transmission. IOW, I don't think any obvious references to the
> discarded ones remain, if that matters.
That sounds OK. Even better would be to use functions for the :secret
token, instead of the secret strings themselves. And call that function
when you need it.
> Thanks everyone,
> J.P.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 21 Apr 2022 13:23:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Btw, I found it hard to scan a bug report with so many different
> problems. Usually, it is more simple to discuss every problem in a
> separate bug report, in order not to lose control. Except, all of them
> are strongly dependent.
Thanks for the thorough remarks, and apologies for the "omnibus" bug
report. I have others pending as well that are actually subsets of this
one, and I really should have done likewise for all this auth-source
business (filed a new, "interdependent" report, that is). Next time,
let's hope I'll be more thoughtful about it.
> You have said somewhere there is an archive at
> <https://jpneverwas.gitlab.io/erc-tools/archive/>. I cannot access
> this URL. Is there another URL to be used?
Sorry for the confusion. That's a package.el-only endpoint without any
browsable HTML, i.e.,
(push '("erc-tools" . "https://jpneverwas.gitlab.io/erc-tools/archive/")
package-archives)
For future reference, the full patch set is available for browsing here:
https://git.neverwas.me/repos/erc-tools/tree/bugs/48598/patches/wip
And is downloadable here:
https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
>> While it may be tempting to single out pass, this part from the doc
>> string for `auth-source-search' says that ignoring :max and returning at
>> most one result is totally acceptable:
>>
>> :max N means to try to return at most N items (defaults to 1).
>> More than N items may be returned, depending on the search and
>> the backend.
>
> Indeed. In Tramp there are two calls of auth-source-search: One call in
> order to retrieve the password, and there I use ':max 1' explicitly (see
> `tramp-read-passwd'). And there is another function used for user/host
> name completion, not looking for the password, and there I use ':max
> most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former
> case could refrain from specifying :max.
Wow, so my lack of communications skills strikes again! What I meant to
say was that from my reading of that doc string (basically the de facto
compliance spec), a *back end* ignoring :max is fair game. But I think
the way I wrote it gave the misleading impression I was saying fair game
from the querying client's perspective. But regardless, the tramp
examples are indeed helpful. So, thanks for those.
> Making auth-source-pass conform to the auth-source API would always be a
> good thing™. I don't know whether there exist already such a bug report,
> otherwise I recommend you to write a new report.
Agreed. Unless Ted or Damien have anything to add, I'm going to remove
support for pass from this patch series (at least for now, even though
my terrible hacks seem to make it gel well enough). I'll later open a
new bug report asking for clarification on the interface and possibly
include a patch for making auth-source-pass :max aware.
> Just follow the usual recommendation for ERT tests: make a temporary
> environment for the test (for example, create a temporary
> auth-source-pass store), run your test, remove test data (for example,
> remove the temporary auth-source-pass store). That's how the tests in
> auth-source-tests.el and auth-source-pass-tests.el are designed, IIRC.
>
> Since you don't want to test auth-source-pass functionality explicitly,
> you can of course use any other auth-source backend. The scenario is the
> same, and you could even provide several test functions like
> erc-tests--auth-source-netrc, erc-tests--auth-source-json, and alike.
Makes total sense. I believe I've ticked most of those boxes already
(having used auth-source-tests.el as a reference, as you wisely
recommend). I should have excerpted that work for highlighting instead
of dropping another biggish patch in that last email. Anyway, here is
the relevant file (in case you're curious), which I believe reflects the
approach you describe:
https://git.neverwas.me/repos/erc-v3/tree/test/erc-services-tests.el?id=00ad7115#n468
>> Currently, results are narrowed to the best candidate, and its
>> secret is returned as a string for (relatively) immediate
>> transmission. IOW, I don't think any obvious references to the
>> discarded ones remain, if that matters.
>
> That sounds OK. Even better would be to use functions for the :secret
> token, instead of the secret strings themselves. And call that function
> when you need it.
Right, currently, outgoing messages are fully baked out before being
enqueued, and the queue itself is fully accessible. Keeping those quasi
thunks around would make more sense to prevent accidental leakage when
printing debug info and dumping to I/O logs. But that would require some
real redesign, which will become easier after a few ponderous
deprecations mature, so perhaps by Emacs 30.
Anyway, I can't thank you enough for taking the time to look at this
stuff. Definitely obliged.
J.P.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 21 Apr 2022 13:29:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> In test/infra/gitlab-ci.yml there is the comment
>
> # TODO: with make -j4 several of the tests were failing, for
> # example shadowfile-tests, but passed without it.
>
> I've never investigated what's up.
Appreciate your highlighting this comment. I agree that it deserves
attention. But without having (yet) observed what it describes, I can't
see how it could be related to the "jobserver unavailable" warning I'm
getting. That's because the latter's only visible effect seems to be
preventing parallel execution entirely, which makes it effectively
degrade any -j<NN> invocation to what we already have in the existing
command line (the one just below that comment in .job-template:script):
make -j4 && make ${make_params}
(BTW, the warning doesn't seem to have any bearing on the exit code.)
>> FWIW, the course of action prescribed by the info node "(make) Error
>> Messages", namely, prepending a "+", seems to remedy the problem.
>
> [...]
>
> If this fixes the problem, pls push the patch. And change the files
> under test/infra/ accordingly, please.
Thanks, I'd be happy to do that.
Although, in light of my observations above, if you think it might make
more sense to solicit additional insights (possibly relating the two), I
could open a new bug instead. Alternatively (or in addition to that), I
could run a few pipelines with the flag set to -j4 for various targets,
perhaps with and without this patch applied, just to refresh and maybe
revise our current understanding. (Just a thought.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 22 Apr 2022 08:55:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
Hi,
>> If this fixes the problem, pls push the patch. And change the files
>> under test/infra/ accordingly, please.
>
> Thanks, I'd be happy to do that.
>
> Although, in light of my observations above, if you think it might make
> more sense to solicit additional insights (possibly relating the two), I
> could open a new bug instead. Alternatively (or in addition to that), I
> could run a few pipelines with the flag set to -j4 for various targets,
> perhaps with and without this patch applied, just to refresh and maybe
> revise our current understanding. (Just a thought.)
Well, you have your own Emacs branch. Perhaps you apply there the
Makefile patch, and add -j4 to the respective make -C test calls in the
gitlab test jobs, and see what happens?
Well, maybe -j2 is more appropriate on emba, because it has two
processors with one core per processor:
--8<---------------cut here---------------start------------->8---
root <at> emba:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 21
Model: 1
Model name: AMD Opteron 62xx class CPU
Stepping: 2
CPU MHz: 2100.024
BogoMIPS: 4200.04
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 64K
L1i cache: 64K
L2 cache: 512K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl extd_apicid tsc_known_freq pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw xop fma4 vmmcall arat
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 22 Apr 2022 09:31:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> Hi Michael,
Hi,
>> You have said somewhere there is an archive at
>> <https://jpneverwas.gitlab.io/erc-tools/archive/>. I cannot access
>> this URL. Is there another URL to be used?
>
> Sorry for the confusion. That's a package.el-only endpoint without any
> browsable HTML, i.e.,
>
> (push '("erc-tools" . "https://jpneverwas.gitlab.io/erc-tools/archive/")
> package-archives)
Indeed, that works, thanks. I've installed erc-5.4.1.48598.0.20220420.474,
which seems to be the most recent version. Unfortunately, it isn't
obvious what has changed wrt vanilla erc, so I must use ediff-directories.
> For future reference, the full patch set is available for browsing here:
>
> https://git.neverwas.me/repos/erc-tools/tree/bugs/48598/patches/wip
>
> And is downloadable here:
>
> https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
Well, this is also good. But for analysis it might be better to read the
files with the patches applied.
>> Indeed. In Tramp there are two calls of auth-source-search: One call in
>> order to retrieve the password, and there I use ':max 1' explicitly (see
>> `tramp-read-passwd'). And there is another function used for user/host
>> name completion, not looking for the password, and there I use ':max
>> most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former
>> case could refrain from specifying :max.
>
> Wow, so my lack of communications skills strikes again!
Oh no, please don't underestimate my lack of English!
> What I meant to
> say was that from my reading of that doc string (basically the de facto
> compliance spec), a *back end* ignoring :max is fair game. But I think
> the way I wrote it gave the misleading impression I was saying fair game
> from the querying client's perspective. But regardless, the tramp
> examples are indeed helpful. So, thanks for those.
I wouldn't call it fair game. With the Tramp examples you have seen,
that a :max property greater than 1 makes sense.
>> Making auth-source-pass conform to the auth-source API would always be a
>> good thing™. I don't know whether there exist already such a bug report,
>> otherwise I recommend you to write a new report.
>
> Agreed. Unless Ted or Damien have anything to add, I'm going to remove
> support for pass from this patch series (at least for now, even though
> my terrible hacks seem to make it gel well enough). I'll later open a
> new bug report asking for clarification on the interface and possibly
> include a patch for making auth-source-pass :max aware.
Yes, please do so. Hacking around bugs will always result in further
trouble mid-term. A bug must be fixed where it happens.
Btw, there are further dficiencies. For example, I believe the pass
backend does not support the :create and :remove properties (last time
I've checked, it were only netrc and secret backends which do). But this
is perhaps not the most important problem.
> Anyway, here is
> the relevant file (in case you're curious), which I believe reflects the
> approach you describe:
>
> https://git.neverwas.me/repos/erc-v3/tree/test/erc-services-tests.el?id=00ad7115#n468
Could you provide the (changed) test files together with the erc
package? This makes it more simple to puzzle all changes together,
instead of accessing different web locations.
> J.P.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 22 Apr 2022 14:25:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Indeed, that works, thanks. I've installed erc-5.4.1.48598.0.20220420.474,
> which seems to be the most recent version. Unfortunately, it isn't
> obvious what has changed wrt vanilla erc, so I must use ediff-directories.
>
> [...]
>
> Well, this is also good. But for analysis it might be better to read the
> files with the patches applied.
Thanks for being brave and taking a look. And you're right, of course:
for sharing purposes, I really ought to keep a full copy of the entire
emacs.git somewhere, with up-to-date branches for all my open bugs.
>> What I meant to
>> say was that from my reading of that doc string (basically the de facto
>> compliance spec), a *back end* ignoring :max is fair game. But I think
>> the way I wrote it gave the misleading impression I was saying fair game
>> from the querying client's perspective. But regardless, the tramp
>> examples are indeed helpful. So, thanks for those.
>
> I wouldn't call it fair game. With the Tramp examples you have seen,
> that a :max property greater than 1 makes sense.
True that. And (I believe) it likewise makes sense for ERC's needs.
> Btw, there are further dficiencies. For example, I believe the pass
> backend does not support the :create and :remove properties (last time
> I've checked, it were only netrc and secret backends which do). But this
> is perhaps not the most important problem.
Hm... I hadn't thought to check but will keep those on my radar.
> Could you provide the (changed) test files together with the erc
> package? This makes it more simple to puzzle all changes together,
> instead of accessing different web locations.
I've added the tests to the (fake) ELPA package you installed earlier.
Appreciate the counsel, as always.
J.P.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Sat, 23 Apr 2022 09:48:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 48598 <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
Hi,
>> Could you provide the (changed) test files together with the erc
>> package? This makes it more simple to puzzle all changes together,
>> instead of accessing different web locations.
>
> I've added the tests to the (fake) ELPA package you installed earlier.
Thanks. I'm now at erc 5.4.1.48598.0.20220422.667.
Starting slowly, just some first comments. It would be great to
distinguish in your package the same way as between the lisp/erc/ and
test/lisp/erc directories in the Emacs git repo. In your package, you
might use a test/ subdirectory, which contains evrything located in
test/lisp/erc of the Emacs git repo.
I'm not sure about the erc-d/ subdirectory. Is it something which is
also in the lisp/erc Emacs directory, or is it only in test/lisp/erc/?
In the latter case, I believe the directory shall contain just a file
test/lisp/erc/erc-d/erc-d-tests.el (currently called erc-d-self.el), and
*all* other files shall be located at test/lisp/erc/erc-d/erc-d-resources/.
Loading the related resource files, you use a pattern like
--8<---------------cut here---------------start------------->8---
(eval-and-compile (let ((dir (getenv "EMACS_TEST_DIRECTORY")))
(when dir
(load (concat dir "/lisp/erc/erc-d/erc-d") nil t)
(load (concat dir "/lisp/erc/erc-d/erc-d-t") nil t))))
--8<---------------cut here---------------end--------------->8---
That looks too complicate. There are the functions ert-resource-directory
and ert-resource-file. You could use something like (untested)
--8<---------------cut here---------------start------------->8---
(eval-and-compile (let ((load-path (cons (ert-resource-directory) load-path)))
(load "erc-d" nil t)
(load "erc-d-t" nil t)))
--8<---------------cut here---------------end--------------->8---
In erc-services-tests.el, I would call the tests
erc--auth-source-search--{standard,announced,overrides}
erc--auth-source-search--netrc-{standard,announced,overrides}, because
they are about this backend. The body of these functions is almost the
same for the different backends; perhaps you can factor it out.
I would mark the tests erc--auth-source-search--pass-* with
":tags '(:unstable)" until the problems in auth-source-pass are solved.
Again, all of this is just cursory reading, I haven't started yet to
read the real code.
> Appreciate the counsel, as always.
>
> J.P.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Mon, 25 Apr 2022 12:06:01 GMT)
Full text and
rfc822 format available.
Message #138 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Starting slowly, just some first comments. It would be great to
> distinguish in your package the same way as between the lisp/erc/ and
> test/lisp/erc directories in the Emacs git repo. In your package, you
> might use a test/ subdirectory, which contains evrything located in
> test/lisp/erc of the Emacs git repo.
I spotted this just before receiving your email and was panicking to fix
it but was obviously way too late. It was all indeed meant to live under
a top-level test/ subdirectory, but I messed up the ELPA recipe royally,
which resulted in the terrible crime scene at hand. Apologies for the
sloppiness.
> I'm not sure about the erc-d/ subdirectory. Is it something which is
> also in the lisp/erc Emacs directory, or is it only in test/lisp/erc/?
> In the latter case, I believe the directory shall contain just a file
> test/lisp/erc/erc-d/erc-d-tests.el (currently called erc-d-self.el), and
> *all* other files shall be located at test/lisp/erc/erc-d/erc-d-resources/.
Even without the aforementioned packaging snafu, the erc-d/ situation is
definitely confusing. That subdir is supposed to house the fake IRC
server that all the "erc-scenarios"-based tests depend on. I initially
tried going with erc-d-tests.el instead of erc-d-self.el for the
server's own tests but hit a Make error because a corresponding library
didn't exist under lisp/erc/. Perhaps I should have tinkered further.
And while moving erc-d/ (minus the tests) under lisp/erc/ would make
things easier in terms of the layout, I'd rather not add more bulk to
Emacs proper without good reason, even though adding it wouldn't really
cause any problems (assuming the symbols are renamed using the internal
"--" convention).
For now, I've moved it to test/lisp/erc/erc-scenarios/resources/erc-d/
and am artificially piggybacking on check-lisp-erc-erc-scenarios via
test/lisp/erc/erc-scenarios/erc-scenarios-meta.el, which does nothing
but load erc-d-self.el (as convoluted as that sounds).
> Loading the related resource files, you use a pattern like
>
> (eval-and-compile (let ((dir (getenv "EMACS_TEST_DIRECTORY")))
> (when dir
> (load (concat dir "/lisp/erc/erc-d/erc-d") nil t)
> (load (concat dir "/lisp/erc/erc-d/erc-d-t") nil t))))
>
>
> That looks too complicate. There are the functions ert-resource-directory
> and ert-resource-file. You could use something like (untested)
>
> (eval-and-compile (let ((load-path (cons (ert-resource-directory) load-path)))
> (load "erc-d" nil t)
> (load "erc-d-t" nil t)))
That environment variable stuff has been driving me bananas! Yours is
much nicer (thanks) and has magically nudged me toward adopting what's
hopefully a less offensive layout, which currently looks like this:
test/lisp/erc/
├── erc-tests.el
...
└── erc-scenarios/
├── erc-scenarios-<foo>.el
├── erc-scenarios-meta.el
...
└── resources/
├── <foo>/...
...
├── erc-d/
│ ├── erc-d.el
│ ...
│ ├── erc-d-self.el
│ └── erc-d-self-resources/...
└── erc-scenarios-common.el
> In erc-services-tests.el, I would call the tests
> erc--auth-source-search--{standard,announced,overrides}
> erc--auth-source-search--netrc-{standard,announced,overrides}, because
> they are about this backend. The body of these functions is almost the
> same for the different backends; perhaps you can factor it out.
Done, thanks. (My ego says I'd have realized this eventually, but that's
probably a lie!)
> I would mark the tests erc--auth-source-search--pass-* with
> ":tags '(:unstable)" until the problems in auth-source-pass are solved.
Oh, I was going to remove those tests completely because they depend on
hacks from lisp/erc/erc-compat.el that I've since deleted. IOW, they're
guaranteed to fail (and so have been disabled). But I left them hanging
around for now in case you had something else in mind.
> Again, all of this is just cursory reading, I haven't started yet to
> read the real code.
Oh, wow! I'm quite floored by the "yet" part (though no expectations, of
course). If you do happen to take a deeper look, please take your time,
and don't sweat the IRC protocol stuff if it gets too annoying. Unlike,
say, dbus, much of IRC is dizzyingly nonsensical and is no longer bound
by any relevant specification (although work is underway in this area).
Sorry again for the packaging snafu. Despite all appearances, I really
do value your time, so please don't let this interfere (too much) with
whatever else is on your plate. You've already helped me so much, and I
owe you a ton!
J.P.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Wed, 27 Apr 2022 12:30:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
"J.P." <jp <at> neverwas.me> writes:
> Hi Michael,
Hi,
I'm now at erc 5.4.1.48598.0.20220425.270. Btw, it is a little bit
tricky to decide which is the recent version, because you have two lines
of patches: erc5.4.1.48598.* and erc 5.4.1.49860.*. The package manager
always offers me to upgrade to the most recent 5.4.1.49860.* version,
and I must pick then the most recent 5.4.1.48598.* version (hoping it is
the proper decision). It might be more obvious to me if you could offer
both erc-48598 and erc-49860 packages in parallel.
> Even without the aforementioned packaging snafu, the erc-d/ situation is
> definitely confusing. That subdir is supposed to house the fake IRC
> server that all the "erc-scenarios"-based tests depend on. I initially
> tried going with erc-d-tests.el instead of erc-d-self.el for the
> server's own tests but hit a Make error because a corresponding library
> didn't exist under lisp/erc/. Perhaps I should have tinkered further.
Indeed, test/Makefile fires an error then. I've pushed a fix to master,
it shall work now with the file name erc-d-tests.el.
> And while moving erc-d/ (minus the tests) under lisp/erc/ would make
> things easier in terms of the layout, I'd rather not add more bulk to
> Emacs proper without good reason, even though adding it wouldn't really
> cause any problems (assuming the symbols are renamed using the internal
> "--" convention).
Yes. Test data and test Elisp files belong to the test/ directory.
> For now, I've moved it to test/lisp/erc/erc-scenarios/resources/erc-d/
> and am artificially piggybacking on check-lisp-erc-erc-scenarios via
> test/lisp/erc/erc-scenarios/erc-scenarios-meta.el, which does nothing
> but load erc-d-self.el (as convoluted as that sounds).
Where is this needed? I don't see any load of erc-scenarios-meta.el.
And even if you need it somewhere, I believe it belongs into the
resources/ subdirectory.
> That environment variable stuff has been driving me bananas! Yours is
> much nicer (thanks) and has magically nudged me toward adopting what's
> hopefully a less offensive layout, which currently looks like this:
>
> test/lisp/erc/
> ├── erc-tests.el
> ...
> └── erc-scenarios/
> ├── erc-scenarios-<foo>.el
> ├── erc-scenarios-meta.el
> ...
> └── resources/
> ├── <foo>/...
> ...
> ├── erc-d/
> │ ├── erc-d.el
> │ ...
> │ ├── erc-d-self.el
> │ └── erc-d-self-resources/...
> └── erc-scenarios-common.el
Looks OK to me except the location of erc-scenarios-meta.el.
>> I would mark the tests erc--auth-source-search--pass-* with
>> ":tags '(:unstable)" until the problems in auth-source-pass are solved.
>
> Oh, I was going to remove those tests completely because they depend on
> hacks from lisp/erc/erc-compat.el that I've since deleted. IOW, they're
> guaranteed to fail (and so have been disabled). But I left them hanging
> around for now in case you had something else in mind.
Well, there seems to be a cut'n'waste error in erc-services-tests.el. See
this fix:
[Message part 2 (text/x-patch, inline)]
*** /home/albinus/.emacs.d/elpa/erc-5.4.1.48598.0.20220425.270/test/erc-services-tests.el.~1~ 2022-04-26 08:38:20.106415131 +0200
--- /home/albinus/.emacs.d/elpa/erc-5.4.1.48598.0.20220425.270/test/erc-services-tests.el 2022-04-27 14:25:08.822978791 +0200
***************
*** 465,471 ****
((symbol-function 'auth-source-pass-entries)
(lambda () (mapcar #'car store))))
! (erc-services-tests--auth-source-announced
#'erc--auth-source-search))))
(ert-deftest erc--auth-source-search--pass-announced ()
--- 465,471 ----
((symbol-function 'auth-source-pass-entries)
(lambda () (mapcar #'car store))))
! (erc-services-tests--auth-source-standard
#'erc--auth-source-search))))
(ert-deftest erc--auth-source-search--pass-announced ()
[Message part 3 (text/plain, inline)]
> Sorry again for the packaging snafu. Despite all appearances, I really
> do value your time, so please don't let this interfere (too much) with
> whatever else is on your plate. You've already helped me so much, and I
> owe you a ton!
No need to sorry! That's what reviews are good for :-)
> J.P.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 28 Apr 2022 08:09:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi,
>> Even without the aforementioned packaging snafu, the erc-d/ situation is
>> definitely confusing. That subdir is supposed to house the fake IRC
>> server that all the "erc-scenarios"-based tests depend on. I initially
>> tried going with erc-d-tests.el instead of erc-d-self.el for the
>> server's own tests but hit a Make error because a corresponding library
>> didn't exist under lisp/erc/. Perhaps I should have tinkered further.
>
> Indeed, test/Makefile fires an error then. I've pushed a fix to master,
> it shall work now with the file name erc-d-tests.el.
I've poked around this problem. Looks like there is a better solution. If
your test directory is not called test/lisp/erc/, but test/lisp/erc-tests/,
you can locate there test packages with an arbitrary name, like
erc-tests.el or erc-d-tests.el, which don't require a corresponding
library under lisp/erc/. This is described in test/README, and it will
work also with older Emacsen.
I revert the aforementioned patch in test/Makefile therefore.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 28 Apr 2022 08:14:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> This is described in test/README, and it will work also with older
> Emacsen.
s/README/file-organization.org/
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Fri, 29 Apr 2022 13:04:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I'm now at erc 5.4.1.48598.0.20220425.270. Btw, it is a little bit
> tricky to decide which is the recent version, because you have two
> lines of patches: erc5.4.1.48598.* and erc 5.4.1.49860.*. The package
> manager always offers me to upgrade to the most recent 5.4.1.49860.*
> version, and I must pick then the most recent 5.4.1.48598.* version
> (hoping it is the proper decision). It might be more obvious to me if
> you could offer both erc-48598 and erc-49860 packages in parallel.
Thanks for the feedback on this. I've done as you suggest and am now
offering both in parallel. As a strange bonus, this has also helped
make the web UI usable:
https://jpneverwas.gitlab.io/erc-tools/archive/
Not that you should care, but when the time comes to redo this setup for
actual use, I'll have to try and reassess whether the behavior we want
is really supported and sustainable. (Hopefully, the ELPA and/or
package.el people will be willing to advise.) At the moment, this
approach of using separate packages feels quite shaky, for example, with
how the shadowing of the built-in ERC happens or how a "main file"
matching the package name (such as erc-5xxxx.el) is expected at various
points. Such wrinkles will have to be ironed out because we'll be adding
packages for bugs in a mostly automated fashion, with the eventual goal
being to allow ordinary folks (some of whom may be new to Emacs) to try
these fixes and report back findings. It kills me that many people offer
to be guinea pigs, but as soon as you mention applying patches: poof!
They're gone.
> Indeed, test/Makefile fires an error then. I've pushed a fix to master,
> it shall work now with the file name erc-d-tests.el.
>
> [From your most recent email]
>
> I've poked around this problem. Looks like there is a better solution.
> If your test directory is not called test/lisp/erc/, but
> test/lisp/erc-tests/, you can locate there test packages with an
> arbitrary name, like erc-tests.el or erc-d-tests.el, which don't
> require a corresponding library under lisp/erc/. This is described in
> test/[file-organization.org], and it will work also with older
> Emacsen.
> I revert the aforementioned patch in test/Makefile therefore.
Thanks a lot for investigating. I was under the mistaken impression that
the -tests/ suffix was reserved for deeper libraries, like those under
lisp/emacs-lisp/. So, with this in mind, I guess it all comes down to
whether we want to
a. keep the erc-scenarios/ subdir or change to a flat layout
b. rename all scenarios using -tests.el, thus requiring a move to
test/lisp/erc-tests/
For (a), staying with the status quo means that tests in erc-resources
are excluded from test-lisp-erc-inotify, though this seems irrelevant
because all scenarios-based tests are expensive anyway. At present, the
only inexpensive tests in that subdir reside in erc-d-self.el. But
having those wait around at most eight hours to run seems fine because
their natural place is alongside those expensive scenarios, I think. As
for actual potential downsides of keeping the subdir, one might be that
it makes ERC the odd man out. AFAICT, no other subdirs with ad hoc names
exist under test/lisp, and there's no mention in file-organization.org
(AFICT) of such names being supported.
For (b), keeping the status quo would mean existing references and
hyperlinks are preserved (a plus, IMO). Since, all tests are still
discovered without undergoing a move, I'm not sure if there's a clear
benefit to the latter other than (again) compliance with established
norms. Specifically, if people might be annoyed at having tests under a
plain test/lisp/erc/ live in files not suffixed by -tests.el, we should
probably appease them.
In the end, any combination is fine by me, really.
>> For now, I've moved it to test/lisp/erc/erc-scenarios/resources/erc-d/
>> and am artificially piggybacking on check-lisp-erc-erc-scenarios via
>> test/lisp/erc/erc-scenarios/erc-scenarios-meta.el, which does nothing
>> but load erc-d-self.el (as convoluted as that sounds).
>
> Where is this needed? I don't see any load of erc-scenarios-meta.el.
>
> And even if you need it somewhere, I believe it belongs into the
> resources/ subdirectory.
Right. The point was to ensure those tests in erc-d-self.el would be
discovered for the check-lisp-erc-erc-scenarios target and also during
the test-all-inotify job (check-expensive). But replacing that "meta"
file with the real thing (erc-d-self.el itself) works just as well and
avoids the indirection. If this is still problematic, I'm fine with
simply hiding erc-d-self.el under resources/ and never running it on
EMBA or just deleting it (along with all its resources).
>> test/lisp/erc/
>> ├── erc-tests.el
>> ...
>> └── erc-scenarios/
>> ├── erc-scenarios-<foo>.el
>> ├── erc-d.self.el <- formerly "meta"
>> ...
>> └── resources/
>> ├── <foo>/...
>> ...
>> ├── erc-d/
>> │ ├── erc-d.el
>> │ ...
>> │ ├── (erc-d-self.el) <- gone
>> │ └── resources/... <- renamed
>> └── erc-scenarios-common.el
>
> Looks OK to me except the location of erc-scenarios-meta.el.
For the sake of contrast, here's what the above would look like without
the subdir and with -tests.el everywhere (although these can be applied
independently):
test/lisp/erc-tests/
├── erc-tests.el
...
├── erc-d-tests.el
├── erc-scenarios-<foo>-tests.el
...
└── resources/
├── <foo>/...
...
├── erc-d/
│ ├── erc-d.el
│ ...
│ └── resources/...
└── erc-scenarios-common.el
> Well, there seems to be a cut'n'waste error in erc-services-tests.el. See
> this fix: [...]
>
> ! (erc-services-tests--auth-source-standard
> #'erc--auth-source-search))))
Sadly typical on my part. Thanks. Is there any preference as to whether
these should stick around even though they're unused? (I had originally
planned on removing them.)
>> Sorry again for the packaging snafu. Despite all appearances, I really
>> do value your time, so please don't let this interfere (too much) with
>> whatever else is on your plate. You've already helped me so much, and I
>> owe you a ton!
>
> No need to sorry! That's what reviews are good for :-)
Definitely! (Always appreciated.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Wed, 25 May 2022 19:30:03 GMT)
Full text and
rfc822 format available.
Message #153 received at 48598 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Update #6.
With the one-year anniversary of this bug finally upon us, it felt only
fitting to furnish yet another (hopefully final) update. I say final
because as long as we're willing to accept the proposed behavior as
mostly correct, a move to iterating on trunk seems (IMO) warranted, if
only to avoid further alienating those who've been patiently awaiting
these and other, dependent changes.
(If you'll recall, this was the only ERC bug to occupy #emacs topic real
estate for weeks on end during all of 27.1.)
To review, this bug set introduces the following items for export:
5 functions
6 options
2 other (everything else is internal)
* lisp/erc/erc.el:
function: `erc-auth-source-search'
Default value of all `erc-auth-source-*-function' options.
Queries `auth-source-search' with params derived from
protocol context, connection properties, and caller
overrides.
function: `erc-compute-user'
Determines first positional arg of IRC "USER" command to
send when not otherwise supplied. Could be internal (IMO);
exported for consistency with "compute-foo" convention.
option: `erc-auth-source-server-function',
`erc-auth-source-join-function'
Functions for querying auth-source in various contexts. See
also `erc-auth-source-services-function' below.
option: `erc-prompt-hidden' and `erc-unhide-query-prompt'
See bug#54826: Prevent duplicate prompts when reconnecting
in ERC.
option: `erc-reconnect-display'
See bug#51753: ERC switches to channel buffer on reconnect.
* lisp/erc/erc-backend.el:
variable: `erc-session-username'
See bug#54824: Add 'user' parameter to ERC entry-point
commands.
* lisp/erc/erc-networks.el:
function: `erc-networks-shrink-ids-and-buffer-names' and
`erc-networks-rename-surviving-target-buffer'
These undo certain uniquifying effects when disambiguation
is no longer relevant. Would be internal if not for being
default members of various buffer-killing hooks.
function: `erc-networks-on-MOTD-end'
Performs primary network-context related setup right before
logical connection formally established.
other: `erc-obsolete-var'
Generic context rewriter.
* lisp/erc/erc-services.el:
option: `erc-auth-source-services-function'
See `erc-auth-source-server-function' above. Should perhaps
be renamed `erc-auth-source-nickserv-function' to avoid
confusion with the latter.
For major behavioral changes and deprecations, please see the updates to
etc/ERC-NEWS in the last patch below. Some of the language is merely
speculative and bears further discussion (in particular, the thing about
a new naming convention for edge functionality). In that same patch,
you'll also find updates to the texinfo doc describing (not so much
changes to but) new behavior for existing options and commands. Other,
less consequential changes of more or less minor disruptive potential
are noted in the commit logs themselves.
And with that, people, I once again implore you:
see something, say something!
Thanks,
J.P.
[0001-Rework-mutual-dependency-between-erc-and-erc-backend.patch (text/x-patch, attachment)]
[0002-Initialize-erc-server-filter-data-in-erc-backend.patch (text/x-patch, attachment)]
[0003-Accept-user-keyword-arg-in-ERC-entry-point-commands.patch (text/x-patch, attachment)]
[0004-Add-some-ERC-test-helpers.patch (text/x-patch, attachment)]
[0005-SQUASH-ME-Remove-duplicate-ERC-prompt-on-reconnect.patch (text/x-patch, attachment)]
[0006-Customize-displaying-of-ERC-buffers-on-reconnect.patch (text/x-patch, attachment)]
[0007-Allow-exemption-from-flood-penalty-in-erc-backend.patch (text/x-patch, attachment)]
[0008-Don-t-set-erc-server-announced-name-unless-known.patch (text/x-patch, attachment)]
[0009-Require-erc-networks-in-erc.el.patch (text/x-patch, attachment)]
[0010-Update-ISUPPORT-handling-in-ERC.patch (text/x-patch, attachment)]
[0011-Recognize-ASCII-and-strict-CASEMAPPINGs-in-ERC.patch (text/x-patch, attachment)]
[0012-Make-ERC-respect-spaces-in-server-passwords.patch (text/x-patch, attachment)]
[0013-Add-helper-to-determine-local-channels-in-ERC.patch (text/x-patch, attachment)]
[0014-Add-eventual-replacement-for-erc-default-recipients.patch (text/x-patch, attachment)]
[0015-Discourage-ill-defined-use-of-buffer-targets-in-ERC.patch (text/x-patch, attachment)]
[0016-Add-ERC-test-server-and-related-resources.patch (text/x-patch, attachment)]
[0017-Address-long-standing-ERC-buffer-naming-issues.patch (text/x-patch, attachment)]
[0018-SQUASH-ME-Add-user-oriented-test-scenarios-for-ERC.patch (text/x-patch, attachment)]
[0019-Register-erc-kill-buffer-function-locally.patch (text/x-patch, attachment)]
[0020-Don-t-call-erc-auto-query-twice-on-PRIVMSG.patch (text/x-patch, attachment)]
[0021-SQUASH-ME-Add-ERC-scenarios-for-identity-aware-msg-h.patch (text/x-patch, attachment)]
[0022-Favor-network-identities-in-erc-join.patch (text/x-patch, attachment)]
[0023-SQUASH-ME-Add-ERC-test-scenarios-for-identity-aware-.patch (text/x-patch, attachment)]
[0024-Standardize-auth-source-queries-in-ERC.patch (text/x-patch, attachment)]
[0025-SQUASH-ME-Add-ERC-test-scenarios-involving-auth-sour.patch (text/x-patch, attachment)]
[0026-SQUASH-ME-Add-ERC-test-scenarios-for-erc-cmd-JOIN.patch (text/x-patch, attachment)]
[0027-Update-ERC-s-Info-doc-with-network-ID-related-change.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48598; Package
emacs.
(Thu, 26 May 2022 05:18:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 48598 <at> debbugs.gnu.org (full text, mbox):
Forgot to include the customary notice of obsolescence. (How dare me.)
So, as always, people, the patches included in that update were merely
intended as a checkpoint for posterity. The latest set can be found
here:
https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz
Thanks.
bug marked as fixed in version 29.1, send any further explanations to
48598 <at> debbugs.gnu.org and "J.P." <jp <at> neverwas.me>
Request was from
"J.P." <jp <at> neverwas.me>
to
control <at> debbugs.gnu.org.
(Sat, 02 Jul 2022 01:22:01 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.
(Sat, 30 Jul 2022 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 341 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.