(This message may arrive as a duplicate, because my ISP sucks and appears to have lost the first one. Sorry about the noise if it miraculously recovers it.)
Hello everyone, Christmas has arrived! The December 2014 skarnet.org release is ready. (For once, I held to the deadline I had set for myself. Yes, this is an accomplishment.) There are not many functional changes - every package does, on the outside, fairly - or exactly - the same thing as it did before. But this release is still a major milestone, because it sets the foundation for future work: - The build system of skarnet.org packages is now configure/make/make install, which is easier to understand and use for most people. I hope this will encourage more users to give my software a try, and more distributions to package it. If you've always hated my previous build system, rejoice: it's gone for good. If you've always hated autotools, don't worry: I have not switched to autotools, and never will. Slashpackage installations are still supported, even if they are not the default anymore. Slashpackage-enabled installations will call binaries with absolute paths (unversioned for inter-package dependencies and versioned for intra-package dependencies), whereas not-slashpackage-enabled ones will call binaries by name and rely on the PATH environment variable, even for intra-package dependencies. - The set of sysdeps tested by the skalibs configuration process has been entirely changed and modernized. Old tests have been removed, new ones have been added as needed to address portability issues of 2014 instead of ones of 2002. Cross-compilation is easier than ever. - Packages now put their header files in their own subdirectory of /usr/include, to avoid cluttering the header namespace. For instance, the skalibs headers' main entry point is <skalibs/skalibs.h>. By default, packages also put their static library files in their own subdirectory of /usr/lib. This can be a pain for linking, but it is cleaner, and the ./configure default does the appropriate magic to make it just work. - Packages should now compile and run as-is on Linux i386/x86_64/ARM, FreeBSD, OpenBSD, NetBSD, Solaris and MacOS X. Cross-platform compatibility should be a formality, but it's really not - some systems really go out of their way to interpret standards in the most demented way possible (I'm looking at you, FreeBSD) and ensuring good, reproducible behaviour on supposedly POSIX OSes is a lot more work than it appears; it is today as it was 15 years ago, if not worse. Nevertheless, I now have access to a few systems for testing, and can make sure everything works before releasing. A big thank you to Zoltán Árpádffy for http://polarhome.com/ . - Packages are now tracked by git. Every package has its publicly accessible repository on git.skarnet.org. I haven't yet set up a web interface, because I can't figure out how cgit is supposed to compile, but I may get to it soon if there's demand. (Disclaimer: I curse a lot in commit logs. Do not follow day-to-day development if you're offended by profanity. Definitely do not follow it if you're a BSD kernel/libc developer.) A word of warning: skarnet.org packages need at least GNU make 4.0 to compile now. Some distributions see fit to only package GNU make 3.82, which is four years old, or even GNU make 3.81, which is eight years old. GNU make 4.0 is more than one year old (and 4.1 has been released two months ago); I figured one year should be enough for people to update their development tools. If you don't have 4.0+, or do not have GNU make at all, it's not a sin: BSD users should be pitied and helped, not scorned. Just know that GNU make is a breeze to install manually: it's incredibly clean, compact, and easy to compile, for a GNU package. I definitely had a very good surprise there. On to the details! skalibs-2.0.0.0 --------------- * Lots and lots of changes, most of them internal, some of them not so much. Overall, skalibs has been simplified. I think. * Only one big library now ("-lskarnet") instead of several small ones. This makes it easier for shared libraries junkies, and simplifies compilation altogether. * It's a major number change. No compatibility ensured with previous versions; expect serious nasal demons if you don't properly port stuff to skalibs 2. If you have software depending on skalibs and want to upgrade, please ask for help on the list. Most of the upgrade is straightforward or scriptable, but some parts will be tricky. * For once, I'm glad to have slacked on documentation. I would have had to rewrite a significant part of it. I did rewrite a part of it anyway. And no, I didn't complete it. Sorry: code is more fun to write than doc. (Unless it's BSD compatibility code, of course.) I'm totally willing to answer questions about skalibs interfaces on the list, though, to make up for the ever lacking documentation. * The biggest addition is skalibs/unixmessage.h: easy message-passing across processes. Messages can include file descriptors. skalibs/skaclient.h has been rewritten around it. s6-svwait is using it. skabus will use it. It works on decent implementations of the sendmsg() standard... and on braindead ones too. I'm pretty proud of it, and if you knew the horrors I've been through to make it work everywhere, you'd be proud too. http://skarnet.org/software/skalibs/ git://git.skarnet.org/skalibs execline-2.0.0.0 ---------------- * No functional changes. Due to the underlying change in skalibs, some execline programs may use posix_spawn() instead of fork(), so they may be marginally more efficient on some systems or have slightly different error messages. Nothing remarkable. * Binary location information is available in <execline/config.h>: EXECLINE_BINPREFIX is the versioned prefix (you should not use that one) and EXECLINE_EXTBINPREFIX is the unversioned one (which you should use). This is useful for script generators: to generate an execline script, you would start with "#!" EXECLINE_EXTBINPREFIX "execlineb". An empty EXECLINE_EXTBINPREFIX means that there's no guaranteed installation path, and the programs should be found via the PATH environment variable - PATH search works in shebang lines too. (Even on BSD. Miracles happen.) Other packages use the same mechanism for binary location information, but it's obviously more important for execline. http://skarnet.org/software/execline/ git://git.skarnet.org/execline s6-portable-utils-2.0.0.0 ------------------------- * No changes, just a port to skalibs-2.0.0.0. http://skarnet.org/software/s6-portable-utils/ git://git.skarnet.org/s6-portable-utils s6-linux-utils-2.0.0.0 ---------------------- * No changes, just a port to skalibs-2.0.0.0. http://skarnet.org/software/s6-linux-utils/ git://git.skarnet.org/s6-linux-utils s6-2.0.0.0 ---------- * Internal changes and cosmetic fixes all over. * s6-supervise's ./event fifodir is now created private to s6-supervise's gid instead of public. This prevents trivial DoSsing. * A readiness notification helper program, s6-notifywhenup, has been added, as well as support for the 'U' event in s6-svwait. This allows services running under programs such as s6-[ipc|tcp]server* to benefit from accurate state tracking. http://skarnet.org/software/s6/ git://git.skarnet.org/s6 s6-dns-2.0.0.0 ---------------------- * Minor fixes in s6dns-engine and skadns. http://skarnet.org/software/s6-dns/ git://git.skarnet.org/s6-dns s6-networking-2.0.0.0 ---------------------- * Minor fixes all over. * Serious bugfix in minidentd. Nobody noticed it malfunctioning in years, not even myself, and that is actually a good thing: the less people use IDENT, the better. http://skarnet.org/software/s6-networking/ git://git.skarnet.org/s6-networking And that's it for today. Please keep sending your bug reports, feature requests, comments, etc., to the list. Planned future work ------------------- This is always subject to changes, suggestions, adjustments. - Short term: * a synchronous option for s6-svc: do not return before the command has taken effect. * a fd-holding daemon + client library, to add to the s6 toolbox * network utilities as the need arises. (Currently stuck with an optic fiber ISP that doesn't understand DHCP leases, so I need to build a router that actually works.) - Mid term: * fd-passing options to s6-[tcp|ipc]server* to take advantage of the fd-holding daemon (for instance to upgrade s6-networking without service interruption) * skabus * trivial cgroups support for s6 on Linux * a complete stage 1 init script for Linux systems - Long term: * a service dependency manager over s6, using script generators * a thorough study of the features people find useful in systemd, and if possible, a sane/Unixish implementation of those features * communication about that work * world domination Merry Christmas, if applicable, and happy New Year, if applicable, to everyone ! -- Laurent