Notices by Alan Coopersmith (alanc@fosstodon.org), page 3

In #OracleSolaris 11.4.69, the default/etc/ssh/sshd_config file has added "Include /etc/ssh/sshd_config.d/*.conf" so you can just drop new config fragments in that directory via IPS/ansible/puppet/etc. instead of having to edit the existing configs. The equivalent was also done for the ssh_config file, if you need to do things like enable old algorithms to ssh to hosts running older ssh versions.

Like many other OS distros, we've adopted the mechanism from PEP 668 <https://peps.python.org/pep-0668/> in #OracleSolaris 11.4.69 to keep the system python packages isolated from changes installed by users via pip. We've also started bundling pipx to make it easier to install python applications to virtual environments. https://blogs.oracle.com/solaris/post/python-package-management-going-forward explains more about this.

The ps command in #OracleSolaris 11.4.69 now accepts the -I flag to display the start time ("STIME") column in an ISO 8601 format. Alternatively, the sitime keyword can be passed to the -o option to specify a start time in an ISO 8601 format.

@cks sadly, after nearly 4 decades we're still fixing issues around NumLock handling even in the software from @XOrgFoundation itself:
https://gitlab.freedesktop.org/xorg/app/xcalc/-/merge_requests/11

@netbsd I know the feeling… 8-)

Today I learned (re-learned?) that jmp_buf and sigjmp_buf are the same size in GNU libc on Linux, but vastly different sizes in the #Solaris libc:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/228

(Fortunately we no longer ship this driver in #OracleSolaris, so this is just academic interest to me, not a bug I need to patch.)

Nice, since the #Solaris <rpc/auth.h> declares user2netname() as taking a 'char [MAXNETNAMELEN + 1]' argument, gcc 13 complains if you pass a 'char [MAXNETNAMELEN]' to it:

https://gitlab.freedesktop.org/xorg/app/xhost/-/merge_requests/7

Twenty years (plus a few weeks) already?

https://lwn.net/Articles/79302/ - "7 Apr 2004 - X.Org Foundation Announces Formation and First Release"

Soon @XOrgFoundation will be old enough to drink in the US...

When Casper was designing the rough equivalent in #Solaris, the least privilege system, he tried to prevent this. For instance, PRIV_FILE_DAC_WRITE won’t let you write to a file owned by UID 0 unless your euid is 0 or you already have all privileges (equivalent to root access).
https://mastodon.social/@vegard/112365131001894332

As the maintainer of the xf86-input-mouse driver for Xorg, I promise to never add any LLM/AI prompt generator code to our mouse driver.
https://mstdn.social/@osnews/112322994452930780

@flameeyes it doesn't look like anyone ever suggested the Austin Group add strcasestr to the standard, so I went ahead and did that now:
https://austingroupbugs.net/view.php?id=1818

Of course, they're busy finalizing the POSIX.1-202x / UnixV8 / XPG8 revision right now, so it would be years before this could make the version after that.

So the maintainer of our GNU emacs packages for #OracleSolaris was testing the upgrade to version 29, and asked me why every time he displayed emacs from a SPARC server to his x86 desktop, the X server crashed.

He filed a bug with upstream for it:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69762

but it turns out it was Xorg upstream where the bug really was, and it was actually a security vulnerability in the byte-swapping code, which we announced today:
https://lists.x.org/archives/xorg-announce/2024-April/003497.html

@rst @dalias @leftpaddotpy @raito if you don’t trust the maintainer, then you simply cannot use the software, whether it uses autotools or not, but generating the files doesn’t stop the maintainer from putting malicious stuff in configure.ac, Makefile.am, or one of the .m4 files that generates the shell scripts and commands run to build.

@josephholsten @dalias and that check fails in the autoconf world unless the files are generated by the build automation, as they'll differ depending on the build environment used to generate them. (Yes, autoconf is not the system we'd design today, it's one that was designed decades ago for a different world.)

@rst @leftpaddotpy @raito @dalias except that won't work as there will be differences in the generated files unless you have the exact same versions of autoconf, automake, libtool, and every package that delivers its own m4 macros into /usr/share/aclocal.

@dalias autoconf complicates this by putting generated files in release tarballs that aren’t in git, and which won’t match the versions you generate locally unless you use the exact same versions of autoconf, auto make, libtool, and all associated macros, as the xz hack made clear. Other build systems (like meson) that don’t need you to distribute files that aren’t in git will simplify this.

@dalias as one of the primary maintainers of the ~260 X.Org packages, I think our existing plan to port them to meson so the tarball contents are the git checkout without generated files is going to be easier than modifying our processes to check in the autoconf output (which we'd probably want to do in the CI pipeline so it doesn't keep changing depending on the distro/version used by each contributor).

SPARC & x64 machines running #OracleSolaris 11.4 SRU's have been added to the GNU Compile Farm for use by FOSS developers: https://portal.cfarm.net/news/50#

Thanks to the Center for Biotechnology (CeBiTec) at Bielefeld University in Germany for setting up and hosting these machines. The R740 is a donation from de.NBI Cloud Bielefeld, while the T8-1 is a permanent loan from Oracle Corporation.

@jperkin we ship gccgo in Solaris because it has a SPARC backend while Google’s go compiler does not, but that shouldn’t matter for illumos (except for the SPARC forks of Tribblix & OpenIndiana).

@lanodan @unixben @PCOWandre X.Org Foundation since January 2004. XFree86 ran in parallel to the industry consortiums before that (and for a short time later, but pretty much everyone moved from XFree86 to Xorg in 2004/2005 timefram and XFree86 was basically dead by 2008).