Hi Valentin, this Gnulib commit is included in the current development version, i.e., the git repo. A fresh clone + ./bootstrap should pull it in. For an existing clone, you need a ./bootstrap again to pull in Gnulib changes, I think. That commit should be in the next Inetutils release.
It would be great if you could test if this suffices for the in development Ubuntu 26.04. The ENOENT check when utmp entries are synthesized via Gnulib should be fine as a patch in the Ubuntu and Debian packages of Inetutils 2.6. If the Gnulib change does not suffice to fix the problem, I plan to add the #ifdef-ed ENOENT check with a comment why it is there to Inetutils. Thanks, Erik On Mon, Dec 01, 2025 at 09:35:47AM +0100, Valentin Haudiquet wrote: > Also, a colleague of mine sent me that gnulib commit: > https://github.com/coreutils/gnulib/commit/757345e8bad8cec0e05f9e1a0668232048a6c44c > > That one seems to be missing on inetutils version of gnulib, and as > far as I understand it might provide what we were missing, e.g. the > difference between the login sessions and the real user sessions. That > might be the start of a cleaner implementation, but IMHO checking for > ENOENT seems fine for now. > > Thanks again! > Valentin > > On Mon, 1 Dec 2025 at 09:25, Valentin Haudiquet > <[email protected]> wrote: > > > > Hi! > > > > Thank you for this patch! It works indeed when testing locally, I see > > the messages on tty3 but no errors, and the test passes. I will go > > ahead and push that patch to Ubuntu, and send it to Debian. > > > > We are almost sure now that this bug indeed happens on Debian as well, > > but they missed it because their autopkgtests are ran in containers > > and not VMs, and thus don't have full sessions and utmp entries (in an > > Ubuntu LXC container, the test is a PASS as well). > > > > I'm really happy that the solution was that simple in the end :) > > > > I don't want to be too happy too soon, so I will build that package > > with the patch and start the automated testing. > > > > Are you willing to implement that patch upstream? With the ifdef, it > > should not bother any other system indeed, so it should be fine, > > right? > > > > Thanks! > > Valentin > > > > On Sat, 29 Nov 2025 at 20:53, Erik Auerswald <[email protected]> > > wrote: > > > > > > Hi Valentin, > > > > > > On Tue, Nov 18, 2025 at 03:06:28PM +0100, Erik Auerswald wrote: > > > > On Tue, Nov 18, 2025 at 02:09:40PM +0100, Valentin Haudiquet wrote: > > > > > [...] > > > > > However, I recall from our previous conversations that you would > > > > > not want to implement such a filter because of possible breaks on > > > > > non-GNU systems, right? > > > > > > > > I do not want to break the currently working functionality for systems > > > > with a /var/run/utmp file. I do not like the idea of suppressing a > > > > legitimate error message on those systems just because a newer system > > > > introduces them as a side effect of normal operation. As such I'd > > > > prefer to filter entries without an existing TTY from the results > > > > returned from this new system, but not from the existing one. > > > > > > > > Using "configure --enable-systemd" looks like an easy way for GNU > > > > Inetutils to support user messaging on the newer systems. It would > > > > be great if that just worked, but it doesn't. > > > > > > I may have found a small change to adjust user messaging to a system > > > without "utmp" file when using "--enable-systemd". I think that > > > "configure" prefers to use a "utmp" file if possible, and only falls > > > back to non-utmp compatibility if there is none. > > > > > > On my Ubuntu 22.04 system, which still has a "utmp" file, > > > "READUTMP_USE_SYSTEMD" is never defined: > > > > > > $ ./configure > > > [...] > > > $ grep SYSTEMD config.{status,h} > > > config.status:S["SYSTEMD_CHOICE"]="no" > > > config.h:/* #undef READUTMP_USE_SYSTEMD */ > > > > > > $ ./configure --enable-systemd > > > [...] > > > $ grep SYSTEMD config.{status,h} > > > config.status:S["SYSTEMD_CHOICE"]="yes" > > > config.h:/* #undef READUTMP_USE_SYSTEMD */ > > > > > > How does this look on the development version of Ubuntu 26.04? I would > > > expect that "READUTMP_USE_SYSTEMD" is defined with "--enable-systemd" > > > there, but not without. Could you test this and report back? > > > > > > If this idea is correct, then the attached patch should result in passing > > > "syslogd.sh" and "utmp.sh" tests on the development version of Ubuntu > > > 26.04 when "./configure --enable-systemd" is used. If this works for > > > "syslogd", then this could also work for "talkd", but have neither tested > > > nor looked into "talkd" yet. > > > > > > Could you try the attached patch and report back? The "syslogd" test > > > should pass with and without "VERBOSE=1", and if the test user is logged > > > into a Linux virtual console, e.g., tty3, then the test send messages > > > there with "VERBOSE=1". There should not be any unexpected error messages > > > regarding not existing files. > > > > > > Thanks, > > > Erik
