Valentin, could you test the release candidate: https://gitlab.com/gsasl/inetutils/-/jobs/12187544220/artifacts/raw/out/r-guix/inetutils-2.6.15-7f97.tar.xz
Or just git HEAD if it is simpler. /Simon Erik Auerswald <[email protected]> writes: > 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 > >
signature.asc
Description: PGP signature
