Ah, nevermind. I forgot to enable libsystemd. With libsystemd enabled, the test still fails...
On Wed, 3 Dec 2025 at 09:45, Valentin Haudiquet <[email protected]> wrote: > > 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 > > > > > >
