Hello! I just tested that release candidate and the syslogd.sh test is a PASS locally, on my machine.
This means that we will be able to drop the patch when this is out! It would need more automated testing that I can't start outside of a debian package, but I'm sure those would pass as well. Thank you for pointing me to that :) PS: I was not aware that inetutils was easily available on this gitlab mirror :) this is nice to know. -- Valentin On Mon, 1 Dec 2025 at 12:14, Simon Josefsson <[email protected]> wrote: > > 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 > > > >
