Google docs has some tab feature.
I received a note that my script addTodayDate may need to be modified to handle the feature. tabs API.
But then I don't think I need it yet, so I will just use the default tab.
Welcome to the August 2024 report from the Reproducible Builds project!
Our reports attempt to outline what we ve been up to over the past month, highlighting news items from elsewhere in tech where they are related. As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.
Table of contents:
The free software newspaper of record, Linux Weekly News, published an in-depth article based on Holger Levsen s talk, Reproducible Builds: The First Eleven Years which was presented at the recent DebConf24 conference in Busan, South Korea.
Titled The history, status, and plans for reproducible builds and written by Jake Edge, LWN s article not only summarises Holger s talk and clarifies its message but it links to external information as well. Holger s original talk can also be watched on the DebConf24 webpage (direct .webm link and his HTML slides are available also). There are also a significant number of comments on LWN s page as well.
Holger Levsen also headed a scheduled discussion session at DebConf24 on Preserving *other* build artifacts addressing a topic where a number of Debian packages are (or would like to) produce results that are neither the .deb files, the build logs nor the logs of CI tests. This is an issue for reproducible builds as this 4th type of build artifact are typically shipped within the binary .deb packages, and are invariably non-deterministic; thus making the .deb files unreproducible. (A direct .webm link and HTML slides are available).
Peter Eisentraut wrote a detailed blog post on the subject of The new PostgreSQL 17 make dist . Like many projects, the PostgreSQL database has previously pre-built parts of its GNU Autotools build system: the reason for this is a mix of convenience and traditional practice . Peter astutely notes that this arrangement in the build system is quite tricky as:
You need to carefully maintain the different states of clean source code , partially built source code , and fully built source code , and the commands to transition between them.However, Peter goes on to mention that:
a lot more attention is nowadays paid to the software supply chain. There are security and legal reasons for this. When users install software, they want to know where it came from, and they want to be sure that they got the right thing, not some fake version or some version of dubious legal provenance.And cites the XZ Utils backdoor as a reason to care about transparent and reproducible ways of distributing and communicating a source tarball and provenance. Because of this, intermediate build artifacts are now henceforth essentially disallowed from PostgreSQL distribution tarballs.
In Debian this month, 30 reviews of Debian packages were added, 17 were updated and 10 were removed this month adding to our knowledge about identified issues. One issue type was added by Chris Lamb, too. [ ]
In addition, an issue was filed to update the Salsa CI pipeline (used by 1,000s of Debian packages) to no longer test for reproducibility with reprotest s build_path variation. Holger Levsen provided a rationale for this change in the issue, which has already been made to the tests being performed by tests.reproducible-builds.org.
In Arch Linux this month, Jelle van der Waa published a short blog post on the topic of Investigating creating reproducible images with mkosi, motivated by the desire to make it possible for anyone to re-recreate the official Arch cloud image bit-by-bit identical on their own machine as per [the] reproducible builds definition. In addition, Jelle filed a patch for pacman, the Arch Linux package manager, to respect the SOURCE_DATE_EPOCH environment variable when installing a package.
In openSUSE news, Bernhard M. Wiedemann published another report for that distribution.
In Android news, the IzzyOnDroid project added 49 new rebuilder recipes and now features 256 total reproducible applications representing 21% of the total offerings in the repository. IzzyOnDroid is an F-Droid style repository for Android apps[:] applications in this repository are official binaries built by the original application developers, taken from their resp. repositories (mostly GitHub).
codegen-units = 16 default and resulting in a bug being filed in the Rust issue tracker. [ ]
armhf architecture, enquiring how they might gain temporary access to such a machine in order to perform some deeper testing. [ ]
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb released versions 274, 275, 276 and 277, uploaded these to Debian, and made the following changes as well:
dumppdf(1) in more cases, avoiding situations where we fallback to a binary diff. [ ]RuntimeError exceptions when importing the PyPDF library so that it, or, crucially, its transitive dependencies, cannot not cause diffoscope to traceback at runtime and build time. [ ]marshal.load( ) of precompiled Python bytecode as it, alas, inherently unsafe. Replace for now with a brief summary of the code section of .pyc. [ ][ ]dumppdf(1). [ ]test_python.py: the fixture for this test is fixed. [ ][ ]test_zip text fixtures and definitions to support new changes to the Perl IO::Compress library. [ ]
There were a rather substantial number of improvements made to our website this month, including:
SOURCE_DATE_EPOCH [ ], fixing the test statistics link [ ], adjusting the Google Summer of Code application link [ ], a link to a Debian bug [ ], and removed a dead link to the debhelper utility [ ].jekyll-sitemap plugin to create a sitemap for the website. [ ] .lead directive appearing in the page. [ ]man2html patch on the SOURCE_DATE_EPOCH documentation page. [ ]agama-integration-tests (uses a random TCP-port number in .lock file)ca-certificates-mozilla:ca-certificates-mozilla-prebuiltcosmic (hash order issue)openSUSE (meta-issue to test reproducibility in the openSUSE Build Service)pop-launcher (parallelism-related issue)post (toolchain-issue, avoiding Rust parallelism)rpm-config-SUSE (date-related issue)rust (Rust toolchain issue)weblate (build gets stuck)bind9-docgnome-maps
The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In August, a number of changes were made by Holger Levsen, including:
openssl-provider-legacy package for the Debian unstable environments for running diffoscope due to Debian bug #1078944. [ ][ ][ ][ ]armhf architecture nodes as being down due to proxy down. [ ][ ]index-buildinfo for the builtin-pho script with the -q switch. [ ]ruby-jekyll-sitemap package as it is now used in the website [ ], Roland Clobus updated the script to build Debian live images to treat openQA issues as warnings [ ], and Vagrant Cascadian marked the cbxi4b node as down [ ].
#reproducible-builds on irc.oftc.net.
rb-general@lists.reproducible-builds.org
For their 30th anniversary (ish; the Covid pandemic pushed the date out a bit) British electronic music duo Orbital released the compilation 30 something. The track list mostly looks like a best hits list, which given their prior compilation celebrating 20 years looks much the same would appear superfluous. However, they ve rearranged and re-recorded all their songs for 30, to reflect their live arrangements. The reworkings are sufficiently distinct from the original versions (in some cases I prefer them) and elevate the release. The couple of new tracks are also fun, and many of the remixes on the second disc are worth a listen too.
Another (again somewhat minor) maintenance release of the RcppCNPy
package arrived on CRAN earlier
today.
RcppCNPy
provides R with read and write access to NumPy files thanks to the cnpy library by Carl Rogers
along with Rcpp for the glue to R.
A change in the most recent Rcpp
appears to cause void functions wrapper via Rcpp Modules to
return NULL, as opposed to being silent. That tickles
discrepancy between the current output and the saved (reference) output
of one test file, leading CRAN to display a NOTE which we were asked to
take care of. Done here in this release and now that we know we will
also look into restoring the prior Rcpp behaviour. Other small changes
involved standard maintenance for continuous integration and updates to
files README.md and DESCRIPTION. More details are below.
CRANberries also provides a diffstat report for the latest release. As always, feedback is welcome and the best place to start a discussion may be the GitHub issue tickets page. If you like this or other open-source work I do, you can now sponsor me at GitHub.Changes in version 0.2.13 (2024-09-03)
- A test script was updated to account for the fact that it now returns a few instances of NULL under current Rcpp.
- Small package maintenance updates have been made to the README and DESCRIPTION files as well as to the continuous integration setup.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
And here is the new logo:
Much better, I would say :)
This post is a review for Computing Reviews for Free and open source software and other market failures , a article published in Communications of the ACMUnderstanding the free and open-source software (FOSS) movement has, since its beginning, implied crossing many disciplinary boundaries. This article describes FOSS s history, explaining its undeniable success throughout the 1990s, and why the movement today feels in a way as if it were on autopilot, lacking the steam it once had. The author presents several examples of different industries where, as it happened with FOSS in computing, fundamental innovations happened not because the leading companies of each field are attentive to customers needs, but to a certain degree, despite them not even considering those needs, it is typically due to the hubris that comes from being a market leader. Kemp exemplifies his hypothesis by presenting the messy landscape of the commercial, mutually incompatible systems of Unix in the 1980s. Different companies had set out to implement their particular flavor of open Unix computers, but with clear examples of vendor lock-in techniques. He speculates that, if we had been able to buy a reasonably priced and solid Unix for our 32-bit PCs nobody would be running FreeBSD or Linux today, except possibly as an obscure hobby. He states that the FOSS movement was born out of the utter market failure of the different Unix vendors. The focus of the article shifts then to the FOSS movement itself: 25 years ago, as FOSS systems slowly gained acceptance and then adoption in the serious market and at the center of the dot-com boom of the early 2000s, Linux user groups (LUGs) with tens of thousands of members bloomed throughout the world; knowing this history, why have all but a few of them vanished into oblivion? Kemp suggests that the strength and vitality that LUGs had ultimately reflects the anger that prompted technical users to take the situation into their own hands and fix it; once the software industry was forced to change, the strongly cohesive FOSS movement diluted. The frustrations and anger of [information technology, IT] in 2024, Kamp writes, are entirely different from those of 1991. As an example, the author closes by citing the difficulty of maintaining despite having the resources to do so an aging legacy codebase that needs to continue working year after year.
Dear Debian community,
this are my bits from DPL for August.
Happy Birthday Debian
On 16th of August Debian celebrated its 31th birthday. Since I'm
unable to write a better text than our great publicity team I'm
simply linking to their article for those who might have missed it:
https://bits.debian.org/2024/08/debian-turns-31.html
Removing more packages from unstable
Helmut Grohne argued for more aggressive package removal and
sought consensus on a way forward. He provided six examples of processes
where packages that are candidates for removal are consuming valuable
person-power. I d like to add that the Bug of the Day initiative (see
below) also frequently encounters long-unmaintained packages with popcon
votes sometimes as low as zero, and often fewer than ten.
Helmut's email included a list of packages that would meet the suggested
removal criteria. There was some discussion about whether a popcon vote
should be included in these criteria, with arguments both for and
against it. Although I support including popcon, I acknowledge that
Helmut has a valid point in suggesting it be left out.
While I ve read several emails in agreement, Scott Kitterman made
a valid point "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn t lead
to unwanted removals. However, I don t see "someone" stepping up to file
RM bugs against other maintainers' packages. As long as we have strict
ownership of packages, many people are hesitant to touch a package, even
for fixing it. Asking for its removal might be even less well-received.
Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
In this aspect the opinion of Niels Thykier is interesting: "As
much as I want automation, I do not mind the prototype starting as a
semi-automatic process if that is what it takes to get started."
The urgency of the problem to remove packages was put by CharlesPlessy
into the words: "So as of today, it is much less work to
keep a package rotting than removing it." My observation when trying to
fix the Bug of the Day exactly fits this statement.
I would love for this discussion to lead to more aggressive removals
that we can agree upon, whether they are automated, semi-automated, or
managed by a person processing an automatically generated list
(supported by an objective procedure). To use an analogy: I ve found
that every image collection improves with aggressive pruning. Similarly,
I m convinced that Debian will improve if we remove packages that no
longer serve our users well.
DEP14 / DEP18
There are two DEPs that affect our workflow for maintaining
packages particularly for those who agree on using Git for Debian
packages. DEP-14 recommends a standardized layout for Git packaging
repositories, which benefits maintainers working across teams and makes
it easier for newcomers to learn a consistent repository structure.
DEP-14 stalled for various reasons. Sam Hartman suspected it might
be because 'it doesn't bring sufficient value.' However, the assumption
that git-buildpackage is incompatible with DEP-14 is incorrect, as
confirmed by its author, Guido G nther. As one of the two key tools
for Debian Git repositories (besides dgit) fully supports DEP-14, though
the migration from the previous default is somewhat complex.
Some investigation into mass-converting older formats to DEP-14 was
conducted by the Perl team, as Gregor Hermann pointed out..
The discussion about DEP-14 resurfaced with the suggestion of DEP-18.
Guido G nther proposed the title Encourage Continuous Integration and Merge
Request-Based Collaboration for Debian Packages ,
which more accurately reflects the DEP's technical intent.
Otto Kek l inen, who initiated DEP-18 (thank you, Otto), provided a good
summary of the current status. He also assembled a very helpful
overview of Git and GitLab usage in other Linux distros.
More Salsa CI
As a result of the DEP-18 discussion, Otto Kek l inen suggested
implementing Salsa CI for our top popcon packages.
I believe it would be a good idea to enable CI by default across Salsa
whenever a new repository is created.
Progress in Salsa migration
In my campaign, I stated that I aim to reduce the number of
packages maintained outside Salsa to below 2,000. As of March 28, 2024,
the count was 2,368. Today, it stands at 2,187 (UDD query: SELECT DISTINCT
count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;).
After a third of my DPL term (OMG), we've made significant progress,
reducing the amount in question (369 packages) by nearly half. I'm
pleased with the support from the DDs who moved their packages to Salsa.
Some packages were transferred as part of the Bug of the Day initiative
(see below).
Bug of the Day
As announced in my 'Bits from the DPL' talk at DebConf, I started
an initiative called Bug of the Day. The goal is to train newcomers
in bug triaging by enabling them to tackle small, self-contained QA
tasks. We have consistently identified target packages and resolved at
least one bug per day, often addressing multiple bugs in a single
package.
In several cases, we followed the Package Salvaging procedure outlined
in the Developers Reference. Most instances were either welcomed by
the maintainer or did not elicit a response. Unfortunately, there was
one exception where the recipient of the Package Salvage bug expressed
significant dissatisfaction. The takeaway is to balance formal
procedures with consideration for the recipient s perspective.
I'm pleased to confirm that the Matrix channel has seen an increase
in active contributors. This aligns with my hope that our efforts would
attract individuals interested in QA work. I m particularly pleased
that, within just one month, we have had help with both fixing bugs and
improving the code that aids in bug selection.
As I aim to introduce newcomers to various teams within Debian, I also
take the opportunity to learn about each team's specific policies
myself. I rely on team members' assistance to adapt to these policies. I
find that gaining this practical insight into team dynamics is an
effective way to understand the different teams within Debian as DPL.
Another finding from this initiative, which aligns with my goal as DPL,
is that many of the packages we addressed are already on Salsa but have
not been uploaded, meaning their VCS fields are not published. This
suggests that maintainers are generally open to managing their packages
on Salsa. For packages that were not yet on Salsa, the move was
generally welcomed.
Publicity team wants you
The publicity team has decided to resume regular meetings to coordinate
their efforts. Given my high regard for their work, I plan to attend
their meetings as frequently as possible, which I began doing with the
first IRC meeting.
During discussions with some team members, I learned that the team could
use additional help. If anyone interested in supporting Debian with
non-packaging tasks reads this, please consider introducing yourself to
debian-publicity@lists.debian.org. Note that this is a publicly archived
mailing list, so it's not the best place for sharing private
information.
Kind regards
Andreas.
All but about four hours of my Debian contributions this month were
sponsored by
Freexian. (I ended up going a bit over my 20% billing limit this month.)
You can also support my work directly via
Liberapay.
man-db and friends
I released libpipeline
1.5.8 and
man-db 2.13.0.
Since autopkgtests are great for making sure we spot regressions caused by
changes in dependencies, I added one to man-db that runs the upstream tests
against the installed package. This required some preparatory work
upstream, but otherwise was surprisingly easy to do.
OpenSSH
I fixed the various 9.8 regressions I mentioned last
month: socket activation, libssh2, and
Twisted. There were a few other regressions reported too: TCP wrappers
support,
openssh-server-udeb,
and xinetd were all broken by changes
related to the listener/per-session binary split, and I fixed all of those.
Once all that had made it through to testing, I finally uploaded the first
stage of my plan to split out GSS-API
support: there
are now openssh-client-gssapi and openssh-server-gssapi packages in
unstable, and if you use either GSS-API authentication or key exchange then
you should install the corresponding package in order for upgrades to
trixie+1 to work correctly. I ll write a release note once this has reached testing.
Multiple identical results from getaddrinfo
I expect this is really a bug in a chroot creation script somewhere, but I
haven t been able to track down what s causing it yet. My sbuild chroots,
and apparently Lucas Nussbaum s as well, have an /etc/hosts that looks
like this:
$ cat /var/lib/schroot/chroots/sid-amd64/etc/hosts
127.0.0.1 localhost
127.0.1.1 [...]
127.0.0.1 localhost ip6-localhost ip6-loopback
::1 rather than 127.0.0.1; but things
mostly work anyway, since most code doesn t really care which protocol it
uses to talk to localhost. However, a few things try to set up test
listeners by calling getaddrinfo("localhost", ...) and binding a socket
for each result. This goes wrong if there are duplicates in the resulting
list, and the test output is typically very confusing: it looks just like
what you d see if a test isn t tearing down its resources correctly, which
is a much more common thing for a test suite to get wrong, so it took me a
while to spot the problem.
I ran into this in both python-asyncssh
(#1052788, upstream
PR) and Ruby
(ruby3.1/#1069399,
ruby3.2/#1064685,
ruby3.3/#1077462, upstream
PR). The latter took a while
since Ruby isn t one of my languages, but hey, I ve tackled much harder
side quests. I
NMUed ruby3.1 for this since it was showing up as a blocker for openssl
testing migration, but haven t done the other active versions (yet, anyway).
OpenSSL vs. cryptography
I tend to care about openssl migrating to testing promptly, since openssh
uploads have a habit of getting stuck on it otherwise.
Debian s OpenSSL packaging recently split out some legacy code (cryptography
that s no longer considered a good idea to use, but that s sometimes needed
for compatibility) to an openssl-legacy-provider package, and added a
Recommends on it. Most users install Recommends, but package build
processes don t; and the Python cryptography package requires this code
unless you set the CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1 environment variable,
which caused a bunch of packages that build-depend on it to fail to build.
After playing whack-a-mole setting that environment variable in a few
packages build process, I decided I didn t want to be caught in the middle
here and filed an upstream
issue to see if I could
get Debian s OpenSSL team and cryptography s upstream talking to each other
directly. There was some moderately spirited discussion and the issue
remains open, but for the time being the OpenSSL team has effectively
reverted the
change
so it s no longer a pressing problem.
GCC 14 regressions
Continuing from last month, I fixed build
failures in pccts (NMU) and
trn4.
Python team
I upgraded alembic, automat, gunicorn, incremental, referencing, pympler
(fixing compatibility with Python >=
3.10), python-aiohttp, python-asyncssh
(fixing CVE-2023-46445,
CVE-2023-46446, and
CVE-2023-48795), python-avro,
python-multidict (fixing a build failure with GCC
14), python-tokenize-rt, python-zipp,
pyupgrade, twisted (fixing CVE-2024-41671
and CVE-2024-41810), zope.exceptions,
zope.interface, zope.proxy, zope.security, and zope.testrunner to new
upstream versions. In the process, I added myself to Uploaders for
zope.interface; I m reasonably comfortable with the Zope Toolkit and I seem
to be gradually picking up much of its maintenance in Debian.
A few of these required their own bits of yak-shaving:
Multi-Arch: foreign tagging
(python-importlib-metadata,
python-typing-extensions,
python-zipp).
I fixed build failures in pipenv,
python-stdlib-list,
psycopg3, and
sen, and fixed autopkgtest failures in
autoimport
(upstream PR),
python-semantic-release
and rstcheck.
Upstream for zope.file (not in Debian) filed an issue about a test failure
with Python 3.12,
which I tracked down to a Python 3.12 compatibility
PR in zope.security.
I made python-nacl build reproducibly (upstream
PR).
I moved aliased files from / to /usr in timekpr-next
(#1073722).
Installer team
I applied a patch from Ubuntu to make os-prober support building with the
noudeb profile (#983325).
Another short status update of what happened on my side last month.
Quite a bit of time went
into helping organize the FrOSCon FOSS on Mobile dev room (day 1, day 2, summary) but that was all worth it and fun - so was releasing Phosh 0.41.0 (which incidetally happened right before FrOScon). A three years old MR to xdg-spec to add call categories landed (thanks Matthias) allowing us to finally provide proper feedback for e.g. IM calls too. The rest was some OSK improvements (around Indic language support via varnam and layout configuration), some Cell Broadcast advancements (thanks to NGI0 for supporting this) but also some fixes. Here's the details:
Phosh
varnam_learn() for better completions in the varnam completer (MR)| Publisher: | Harper |
| Copyright: | 2022 |
| Printing: | October 2023 |
| ISBN: | 0-06-331484-3 |
| Format: | Kindle |
| Pages: | 295 |
font-display property to swap in @font-face rules. This method
allows browsers to initially render text using a fallback font, then replace it
with the web font after loading. While this improves the LCP score, it causes
content reflow and layout shifts if the fallback and web fonts are not
metrically compatible. These shifts negatively affect the CLS score. CSS
provides properties to address this issue by overriding font metrics when using
fallback fonts: size-adjust,
ascent-override, descent-override,
and line-gap-override.
Two comprehensive articles explain each property and their computation methods
in detail: Creating Perfect Font Fallbacks in CSS and Improved font
fallbacks.
size-adjust property to match the width of your custom font with
the fallback font. With a proportional font, it is not possible to achieve a
perfect match.
ascent-override property. Aim to align the final dot of the
last paragraph while monitoring the font s baseline. For more precise
adjustment, disable the option.
descent-override property. The goal is to make the two boxes
match. You may need to alternate between this and the previous property for
optimal results.
line-gap-override property. This step is typically
not required.
This tool is not available from the Atom feed.
@font-face font-family: Merriweather; font-style: normal; font-weight: 400; src: url("../fonts/merriweather.woff2") format("woff2"); font-display: swap; @font-face font-family: "Fallback for Merriweather"; src: local("Noto Serif"), local("Droid Serif"); size-adjust: 98.3%; ascent-override: 99%; descent-override: 27%; @font-face font-family: "Fallback for Merriweather"; src: local("Georgia"); size-adjust: 106%; ascent-override: 90.4%; descent-override: 27.3%; font-family: Merriweather, "Fallback for Merriweather", serif;
| Series: | Discworld #41 |
| Publisher: | Harper |
| Copyright: | 2015 |
| Printing: | 2016 |
| ISBN: | 0-06-242998-1 |
| Format: | Trade paperback |
| Pages: | 276 |
"Well," said Tiffany, "there's too much to be done and not enough people to do it." The smile that the kelda gave her was a strange one. The little woman said, "Do ye let them try? Ye mustn't be afraid to ask for help. Pride is a good thing, my girl, but it will kill you in time."And that's before an earth-shattering change in the world of witches, one that leaves Tiffany shuttling between Lancre and the Chalk trying to be too many things to too many people. Plus the kelda is worried some deeper trouble is brewing. And then Tiffany gets an exiled elven queen who has never understood the worth of other people dumped on her, and has to figure out what to do with her. The starting idea is great. I continue to be impressed with how well Pratchett handles Tiffany's coming-of-age story. Finding one's place in the world isn't one lesson or event; it's layers of them, with each new growth in responsibility uncovering new things to learn that are often quite different from the previous problems. Tiffany has worked through child problems, adolescent problems, and new adulthood problems. Now she's on a course towards burnout, which is exactly the kind of problem Tiffany would have given her personality. Even better, the writing at the start of The Shepherd's Crown is tight and controlled and sounds like Pratchett, which was a relief after the mess of Raising Steam. The contrast is so sharp that I found myself wondering if parts of this book had been written earlier, or if Pratchett found a new writing or editing method. The characters all sound like themselves, and although some of the turns of phrase are not quite as sharp as in earlier books, they're at least at the level of Snuff. Unfortunately, it doesn't last. There are some great moments and some good quotes, but the writing starts to slip at about the two-thirds point, the sentences began to meander, the characters start repeating the name of the person they're talking to, and the narration becomes increasingly strained. It felt like Pratchett knew the emotional tone he wanted to evoke but couldn't find a subtle way to express it, so the story and the characters start to bludgeon the reader with Grand Statements. It's never as bad as Raising Steam, but it doesn't slip smoothly off the page to rewrite your brain the way that Pratchett could at his best. What makes this worse is that the plot is not very interesting. I wanted to read a book about Tiffany understanding burnout, asking for help, and possibly also about mental load and how difficult delegation is. There is some movement in that direction: she takes on some apprentices, although we don't see as much of her interactions with them as I'd like, and there's an intriguing new male character who wants to be a witch. I wish Pratchett had been able to give Geoffrey his own book. He and his goat were the best part of the story, but it felt rushed and I think he would have had more impact if the reader got to see him develop his skills over time the way that we did with Tiffany. But, alas, all of that is side story to the main plot, which is about elves. As you may know from previous reviews, I do not get along with Pratchett's conception of elves. I find them boring and too obviously evil, and have since Lords and Ladies. Villains have never been one of Pratchett's strengths, and I think his elves are my least favorite. One of the goals of this book is to try to make them less one-note by having Tiffany try to teach one of them empathy, but I didn't find any of the queen's story arc convincing. If Pratchett had pulled those threads together with something more subtle, emotional, and subversive, I think it could have worked, but instead we got another battle royale, and Lords and Ladies did that better.
"Granny never said as she was better than others. She just got on with it and showed 'em and people worked it out for themselves."And so we come to the end. I wish I could say that the quality held up through the whole series, and it nearly did, but alas it fell apart a bit at the end. Raising Steam I would skip entirely. The Shepherd's Crown is not that bad, but it's minor Pratchett that's worth reading mainly because it's the send-off (and there are a lot of reasons within the story to think Pratchett knew that when writing it). There are a few great lines, some catharsis, and a pretty solid ending for Tiffany, but it's probably not a book that I'll re-read. Content warning: major character death. Special thanks to Emmet Asher-Perrin, whose Tor.com/Reactor re-read of all of Discworld got me to pick the series up again and finally commit to reading all of it. I'm very glad I did. Rating: 6 out of 10
A shiny new release 0.2.4 of pkgKitten
arrived on CRAN earlier, and
has also been been uploaded to Debian. pkgKitten
makes it simple to create new R packages via a simple function
invocation. A wrapper kitten.r exists in the littler
package to make it even easier.
This release contains several improvements to the (optional) setup of
the (wonderful) tinytest package,
now supports the (now mandatory) Authors@R and polished a few aspect
around the package repository and continuous integrations.
The set of changes follows.
More details about the package are at the pkgKitten webpage, the pkgKitten docs site, and the pkgKitten GitHub repo. Courtesy of CRANberries, there is also a diffstat report for the most recent release. If you like this or other open-source work I do, you can sponsor me at GitHub.Changes in version 0.2.4 (2024-08-30)
- The .Rbuildignore stanza now includes .github
- The support of and usage illustrations of tinytest are much enhanced (Paul Hudor in #18 adressing #19 and #20)
- The .gitignore file now includes C++ related files
- Improvements and polish to badges and continuous integration
- The DESCRIPTION file now contains an Authors@R entry
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
It (was) that time of year again - last weekend we hosted a bunch
of nice people at our place in Cambridge for the annual Debian
UK OMGWTFBBQ!
Lots of friends, lots of good food and drink. Of course lots of
geeky discussions about Debian, networking, random computer languages
and... screws? And of course some card games to keep us
laughing into each night!
Many thanks to a number of awesome friendly people for again
sponsoring the important refreshments for the weekend. It's
hungry/thirsty work celebrating like this!
This whole experience expanded my world view. There s so much to see and explore and understand. Looking forward to DebConf25 in Brest, France.
PS - Shoutout to abbyck (aka hamCK)!
| Publisher: | Tor |
| Copyright: | 2023 |
| ISBN: | 1-250-24410-2 |
| Format: | Kindle |
| Pages: | 116 |
The fairy was the greenish-tan color of mushroom stems and her skin bruised blue-black, like mushroom flesh. She had a broad, frog-like face and waterweed hair. She was neither beautiful nor made of malice, as many of the Fair Folk are said to be.There is a princess asleep in a tower, surrounded by a wall of thorns. Toadling's job is to keep anyone from foolishly breaking in. At first, it was a constant struggle and all that she could manage, but with time, the flood of princes slowed to a trickle. A road was built and abandoned. People fled. There was a plague. With any luck, the tower was finally forgotten. Then a knight shows up. Not a very rich knight, nor a very successful knight. Just a polite and very persistent knight who wants to get into the tower that Toadling does not want him to get into. As you might have guessed, this is a Sleeping Beauty retelling. As you may have also guessed from the author, or from the cover text that says "not all curses should be broken," this version is a bit different. How and why it departs from the original is a surprise that slowly unfolds over the course of the story, in parallel to a delicate, cautious, and delightfully kind-hearted conversation between the knight and the fairy. If you have read a T. Kingfisher story before, particularly one of her fractured fairy tales, you know what to expect. Toadling is one of her typical well-meaning, earnest, slightly awkward protagonists who is just trying to do the right thing in a confusing world full of problems and dangers. She's constantly overwhelmed and yet she keeps going, because what else is there to do. Like a lot of Kingfisher's writing, it's a story about quiet courage from someone who doesn't consider herself courageous. One of the twists this time is that the knight is a character from a similar vein: doggedly unwilling to leave any problem alone, but equally determined to try to be kind. The two of them together make for a story with a gentle and rather melancholy tone. We do, eventually, learn the whole backstory of the tower, the wall of thorns, and Toadling. There is a god, a rather memorable one, who is frustratingly cryptic in the way that gods are. There are monsters who are more loving than most humans. There are humans who turn out to be surprisingly decent when it matters. And, like most of Kingfisher's writing, there is a constant awareness of how complicated the world is, how full it is of people who are just trying to get through each day, and how heavy of burdens people can shoulder when they don't see another way. This story pulled me right in. It is not horror, although there are a few odd bits like there always are in Kingfisher stories. Your largest risk as a reader is that it might make you cry if stories about earnest people doing their best in overwhelming situations hit you that way. My primary complaint is that there was nowhere near enough ending for me. After everything I learned about the characters, I wanted to spend some time with them outside of the bounds of the story. Kingfisher points the reader in a direction and then leaves the rest to your imagination, and I can see why she chose that story construction, but I wanted more catharsis than I got. That complaint aside, this is quintessential T. Kingfisher, and I am unsurprised that it won a Hugo. If you've read any of her other fractured fairy tales, or the 2023 Hugo winner for best novel, you know the sort of stories she tells, and you probably know whether you will like this. I am one of the people who like this. Rating: 8 out of 10
Next.