From Newsgroup: muc.lists.freebsd.ports

Hi, thank you for the reply

the last upstream release of whowatch dates back to 2018

So upstream is basically unmaintained.

While the last official release dates back to 2018, I do see some
repository activity as recently as 2025. However, given the lack of
releases and the absence of clear ongoing maintenance or
responsiveness, it still seems reasonable to treat upstream as
effectively unmaintained from a ports perspective.

Does it make sense to patch whowatch to use utmpx/utx on FreeBSD, even
if this results in a significant, one-time overhaul of the codebase?

If you would do that, I suggest to get in touch with upstream and
upstream those patches, and if possible, take over upstream.

I can try to engage with upstream and explore this option, but at the
moment I cannot commit to taking over long-term upstream maintenance
due to uncertain availability.

If a port uses interfaces that are effectively obsolete on newer releases, then the port is deprecated if the RELEASE which still supports it
is EOL. Probably even a bit earlier...

Based on this guidance, I plan to proceed with deprecating
sysutils/whowatch due to its reliance on the obsolete wtmp interface. Separately from the port, I may experiment with an utmpx-based update
in a personal fork to assess feasibility. This would be exploratory
only and without any timeline or commitment. If such an approach later
proves viable and sustainable, the situation can be revisited;
otherwise, the deprecation will stand.
On Wed, Jan 7, 2026 at 2:44rC>PM Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

IrCOm currently working on updating whowatch on FreeBSD from version 1.4 to 1.8.6, and IrCOve run into a few concerns regarding long-term viability and platform compatibility.

[...]

whowatch depends on wtmp, which appears to be deprecated or no longer
maintained on FreeBSD 15.0-RELEASE, with utmp/utx being the preferred
interface

the last upstream release of whowatch dates back to 2018

So upstream is basically unmaintained.

Does it make sense to patch whowatch to use utmpx/utx on FreeBSD, even
if this results in a significant, one-time overhaul of the codebase?

If you would do that, I suggest to get in touch with upstream and
upstream those patches, and if possible, take over upstream.

Is it more appropriate to leave the port as-is (or mark it deprecated)
and instead focus effort on adopting or maintaining a different, more
actively maintained tool?

Yes, this seems more appropriate. The search for a different tool
can become quite burdensome, so it would be very helpful if you did that.

In general, what is the FreeBSD projectrCOs preferred practice when a port
depends on interfaces that are effectively obsolete on newer releases?

If a port uses interfaces that are effectively obsolete on newer releases, then the port is deprecated if the RELEASE which still supports it
is EOL. Probably even a bit earlier...

--
pi@FreeBSD.org +49 171 3101372 Now what ?

--
Best Regards,
Jishan Alam
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Does it make sense to patch whowatch to use utmpx/utx on FreeBSD, even >> if this results in a significant, one-time overhaul of the codebase?

If you can do that, I'd like to try it out.

I may explore this experimentally in a personal repository to assess feasibility. This would be exploratory only and without any commitment
or timeline. If it leads to something usable, IrCOll follow up on the
list.
--
Best Regards,
Jishan Alam
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Jishan Alam <jishanalam9128@gmail.com> wrote:

Hi, thank you for the reply

the last upstream release of whowatch dates back to 2018

So upstream is basically unmaintained.

While the last official release dates back to 2018, I do see some
repository activity as recently as 2025. However, given the lack of
releases and the absence of clear ongoing maintenance or
responsiveness, it still seems reasonable to treat upstream as
effectively unmaintained from a ports perspective.

The host in URL in the port doesn't exist when I try it!

Based on this guidance, I plan to proceed with deprecating
sysutils/whowatch due to its reliance on the obsolete wtmp interface.

When FreeBSD changed to utmpx, a whole bunch of commands were added to
help you read it.

man getutxent

will list this, and other related commands.

So they job may be easier than you first think.

Cheers, Jamie


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Miroslav Lachman <000.fbsd@quip.cz> wrote:

I don't know it this is of any help (I am not the C dev), but I just
found this patch for version 1.4 for utmpx

https://github.com/pld-linux/whowatch/blob/master/whowatch-utmpx.patch

That just seems to be a patch to alter the filename, and some of the
variable names, but not much else.

Even if that works, it would be better to use the utmpx functions (getutxent) etc.
rather than open and read the file directly.

Cheers, Jamie


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--0000000000001f39b70647f2826b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

On Fri, Jan 9, 2026 at 6:07=E2=80=AFAM Miroslav Lachman <000.fbsd@quip.cz> = wrote:

I made a quick update for port, if anybody what to test it from the
ports tree, see attached patch. If you apply it, remove "files" subdir
before running "make".

Thank you for preparing and sharing the port patch. I=E2=80=99ve reviewed i=
t
locally and can confirm that it builds and runs as expected. However, since
the upstream code is still unstable, I=E2=80=99d prefer to hold off on comm= itting
it for now.

Your fixed version of whowatch runs, but it has different UI from the
old version 1.4, and the older version had colors for characters used
for tree branches. As I understand, it has nothing to do with your utmpx
fix, it was probably made by original author.

That matches my understanding as well. I haven=E2=80=99t used whowatch prio=
r to
working on this update, so I don=E2=80=99t have historical context for the =
UI
changes beyond what=E2=80=99s present in the upstream code.

One issue I found is that on one machine it does not display process
[o]wner info, it shows -1 instead. I don't know why. On the other
machine it shows the correct owner info. Botch machines are 14.3 amd64.
On botch machines I tried to run it as normal user and as root.

Thanks for pointing this out. I=E2=80=99ll take a closer look at how the ow= ner
information is parsed and will follow up once I have a better understanding
of what=E2=80=99s causing the discrepancy.


In parallel, I=E2=80=99ve been making progress on the sysinfo issue. It tur=
ns out
the existing implementation is largely Linux-specific, relying on /proc/*, which doesn=E2=80=99t translate well to FreeBSD. To address this, I=E2=80=
=99m redesigning
the sysinfo layer to be more OS-neutral by introducing abstract interfaces
with OS-specific implementations. On Linux this will continue to use /proc, while on FreeBSD it will rely on the sysctl API.

I=E2=80=99ve pushed the latest changes to my branch and will continue worki=
ng
through the remaining sysinfo components. It=E2=80=99s a fairly broad chang=
e, but
now that the structure is in place, the rest should be straightforward.

Repository branch: https://github.com/Zedai00/whowatch/tree/freebsd-utmpx-experiment

--=20
Best Regards,
Jishan Alam

--0000000000001f39b70647f2826b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br>On Fri, Jan 9, 2026 at 6:07=E2=80=AFAM Miro= slav Lachman &lt;<a href=3D"mailto:000.fbsd@quip.cz">000.fbsd@quip.cz</a>&g=
t; wrote:</div><div><br>&gt; I made a quick update for port, if anybody wha=
t to test it from the<br>&gt; ports tree, see attached patch. If you apply = it, remove &quot;files&quot; subdir<br>&gt; before running &quot;make&quot;= .<br><br>Thank you for preparing and sharing the port patch. I=E2=80=99ve r= eviewed it locally and can confirm that it builds and runs as expected. How= ever, since the upstream code is still unstable, I=E2=80=99d prefer to hold=
off on committing it for now.<br><br>&gt; Your fixed version of whowatch r= uns, but it has different UI from the<br>&gt; old version 1.4, and the olde=
r version had colors for characters used<br>&gt; for tree branches. As I un= derstand, it has nothing to do with your utmpx<br>&gt; fix, it was probably=
made by original author.<br><br>That matches my understanding as well. I h= aven=E2=80=99t used whowatch prior to working on this update, so I don=E2= =80=99t have historical context for the UI changes beyond what=E2=80=99s pr= esent in the upstream code.<br><br>&gt; One issue I found is that on one ma= chine it does not display process<br>&gt; [o]wner info, it shows -1 instead=
. I don&#39;t know why. On the other<br>&gt; machine it shows the correct o= wner info. Botch machines are 14.3 amd64.<br>&gt; On botch machines I tried=
to run it as normal user and as root.<br><br>Thanks for pointing this out.=
I=E2=80=99ll take a closer look at how the owner information is parsed and=
will follow up once I have a better understanding of what=E2=80=99s causin=
g the discrepancy.<br><br><br>In parallel, I=E2=80=99ve been making progres=
s on the sysinfo issue. It turns out the existing implementation is largely=
Linux-specific, relying on /proc/*, which doesn=E2=80=99t translate well t=
o FreeBSD. To address this, I=E2=80=99m redesigning the sysinfo layer to be=
more OS-neutral by introducing abstract interfaces with OS-specific implem= entations. On Linux this will continue to use /proc, while on FreeBSD it wi=
ll rely on the sysctl API.<br><br>I=E2=80=99ve pushed the latest changes to=
my branch and will continue working through the remaining sysinfo componen= ts. It=E2=80=99s a fairly broad change, but now that the structure is in pl= ace, the rest should be straightforward.<br><br>Repository branch: <a href= =3D"https://github.com/Zedai00/whowatch/tree/freebsd-utmpx-experiment">http= s://github.com/Zedai00/whowatch/tree/freebsd-utmpx-experiment</a><br><br>--=
<br>Best Regards,<br>Jishan Alam</div></div>

--0000000000001f39b70647f2826b--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--00000000000059aa050648014b24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 10, 2026 at 2:34=E2=80=AFAM Miroslav Lachman <000.fbsd@quip.cz>=
wrote:

If you are interested I have access to one old machine with working
whowatch 1.4 so I can make a few screenshots with the old UI and send it
to you privately. I think there are a few details which were nicer in
the old version.

That'll be appreciated. I can open an issue in my repo and attach the image
for future reference.

Do you think you will be able to make [d]etails also working on FreeBSD? [d]etails and [s]ysinfo is new to this version, they were not there in
the version 1.4. But there was [c]md which turns On / Off showing long command line options of the running processes or process name only. So
for shell scripts you see just "sh" or "/home/user/bin/myscript.sh -t -b my-arg"

[d]etails is working in FreeBSD-15.0 on the other hand it's not working in linux, another issue to look at.
I've gotta start opening up issues to track them better.

[s]ysinfo is also progressing but the caveat here is linux exposes all the details through /proc/* files,
and it has lots of information which is directly dumped by "whowatch" to
the sysinfo panel, But FreeBSD does not have any files like that, So I had
to manually find API's for equivalent information, and turns out Linux and FreeBSD file system is implemented in different manner such that Linux has
much more informations such as buffers, slab etc which doesn't exist in
FreeBSD as far as I know correct me if I'm wrong, So I've only been able to
add the values which I can find the direct equivalent of and I don't think
we can get more far than that. Even the things I've added is a sort of
hacky if i can say but it works.
So far the values I've converted are
=E2=94=82MEMORY: =E2= =94=82

=E2=94=82MemTotal: 4158792 kB =E2= =94=82

=E2=94=82MemFree: 3914304 kB =E2= =94=82

=E2=94=82MemAvailable: 3917292 kB =E2= =94=82

=E2=94=82Active: 19804 kB =E2= =94=82

=E2=94=82Inactive: 2988 kB =E2= =94=82

=E2=94=82Cached: 0 kB =E2= =94=82

=E2=94=82SwapTotal: 1048536 kB =E2= =94=82

=E2=94=82SwapUsed: 384868 kB =E2= =94=82

=E2=94=82SwapFree: 663668 kB =E2= =94=82
whereas the equivalent in Linux is the whole /proc/meminfo.
So I'm just gonna leave it at that, For now the goal is to touch every
feature to assess what can work and what cannot, and later dive deep in the feature for improvement.

as always if anyone wants to try it out the repo is in sync with my work
Repo: https://github.com/Zedai00/whowatch/tree/freebsd-utmpx-experiment
--=20
Best Regards,
Jishan Alam

--00000000000059aa050648014b24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sat, Jan 10, 2026 at 2:34=E2=80=AFAM Miroslav L= achman &lt;<a href=3D"mailto:000.fbsd@quip.cz">000.fbsd@quip.cz</a>&gt; wro= te:<br><br>&gt; If you are interested I have access to one old machine with=
working<br>&gt; whowatch 1.4 so I can make a few screenshots with the old =
UI and send it<br>&gt; to you privately. I think there are a few details wh= ich were nicer in<br>&gt; the old version.<br><br>That&#39;ll be appreciate=
d. I can open an issue in my repo and attach the image for future reference= .<br><br><br>&gt; Do you think you will be able to make [d]etails also work= ing on FreeBSD?<br>&gt; [d]etails and [s]ysinfo is new to this version, the=
y were not there in<br>&gt; the version 1.4. But there was [c]md which turn=
s On / Off showing long<br>&gt; command line options of the running process=
es or process name only. So<br>&gt; for shell scripts you see just &quot;sh= &quot; or &quot;/home/user/bin/myscript.sh -t -b<br>&gt; my-arg&quot;<br><b= r>[d]etails is working in FreeBSD-15.0 on the other hand it&#39;s not worki=
ng in linux, another issue to look at.<br>I&#39;ve gotta start opening up i= ssues to track them better.<br><br>[s]ysinfo is also progressing but the ca= veat here is linux exposes all the details through /proc/* files,<br>and it=
has lots of information which is directly dumped by &quot;whowatch&quot; t=
o the sysinfo panel, But FreeBSD does not have any files like that, So I ha=
d to manually find API&#39;s for equivalent information, and turns out Linu=
x and FreeBSD file system is implemented in different manner such that Linu=
x has much more informations such as buffers, slab etc which doesn&#39;t ex= ist in FreeBSD as far as I know correct me if I&#39;m wrong, So I&#39;ve on=
ly been able to add the values which I can find the direct equivalent of an=
d I don&#39;t think we can get more far than that. Even the things I&#39;ve=
added is a sort of hacky if i can say but it works.<br>So far the values I= &#39;ve converted are<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =E2=94=82MEMORY: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0=E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=82MemTotal: 4158792 kB=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=82MemFree: 3= 914304 kB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =94=82MemAvailable: 3917292 kB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =E2=94=82Active: 19804 kB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=82 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =E2=94=82Inactive: 2988 kB =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=82Cached: 0 kB =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =94=82SwapTotal: 1048536 kB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=94=82 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =E2=94=82SwapUsed: 384868 kB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=94=82 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =E2=94=82SwapFree: 663668 kB =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =E2=94=82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>whereas the equival= ent in Linux is the whole /proc/meminfo.<br>So I&#39;m just gonna leave it =
at that, For now the goal is to touch every feature to assess what can work=
and what cannot, and later dive deep in the feature for improvement.<br><b= r>as always if anyone wants to try it out the repo is in sync with my work<= br>Repo: <a href=3D"https://github.com/Zedai00/whowatch/tree/freebsd-utmpx-= experiment">https://github.com/Zedai00/whowatch/tree/freebsd-utmpx-experime= nt</a><br>-- <br>Best Regards,<br>Jishan Alam</div>

--00000000000059aa050648014b24--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2