On 12/22/2014 05:17 PM, Laurent Bercot wrote:
>
> 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 !
>
Too many goodies to process before 2015, for me at least :)
Just a big THANK YOU for now, and happy holidays (if applicable)
Received on Tue Dec 23 2014 - 17:27:14 UTC