Search Results: "ed"

1 November 2022

Dirk Eddelbuettel: tint 0.1.4 on CRAN: Miscellaneous Updates

A new version 0.1.4 of the tint package arrived at CRAN today. tint provides a style not unlike Tufte for use in html and pdf documents created from markdown. The github repo shows several examples in its README, more as usual in the package documentation. This is the first release in over two years and it brings a few incremental changes which are described in detail below. The trigger was an email from CRAN desiring compacted pdf files inside the package sources. Which, coincidentally, was made a default about a year ago in the build.r script from littler I use to make packages. But as we had not updated tint this has not reached CRAN. So there. The set of changes follows, which includes a helpful contributed PR for which we are always thankful. I also improved table rendering, most other changes are packaging mechanics.

Changes in tint version 0.1.4 (2022-11-01)
  • Added continuous integration at GitHub using run.sh
  • Non-margin reference in html mode now have an improved display (David Selby and Dirk in #47)
  • The LaTeX package array is now installed for improved table support (Dirk addressing #48)
  • Minor updates made the package directory and README.md
  • GitHub Actions were updated to checkout version 3.
  • Several http:// URLs were updated to https://

Courtesy of CRANberries, there is a comparison to the previous release. More information is on the tint page. For questions or comments use the issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel: RcppXts 0.0.5 on CRAN: Maintenance

A new maintenance release 0.0.6 of RcppXts is now on CRAN. The RcppXts package demonstrates how to access the export C API of xts which we contributed a looong time ago. This release, like so many these days, was triggered by clang-15 wanting to see a void in an otherwise argument-less signature. We also updated a GitHub Action to avoid another nag from there. The NEWS entries follow.

Changes in version 0.0.6 (2022-08-05)
  • One function prototype was updated for clang-15.
  • GitHub Actions were updated to checkout version 3.

Courtesy of my CRANberries, there is also a diffstat report for this release. A bit more information about the package is available here as well as at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Paul Tagliamonte: Decoding LDPC: k-Bit Brute Forcing

Before you go on: I've been warned off implementing this in practice on a few counts; namely, the space tradeoff isn't worth it, and it's unlikely to correct meaningful errors. I'm going to leave this post up, but please do take the content with a very large grain of salt!
My initial efforts to build a PHY and Data Link layer from scratch using my own code have been progressing nicely since the initial BPSK based protocol I ve documented under the PACKRAT series. As part of that, I ve been diving deep into FEC, and in particular, LDPC. I won t be able to do an overview of LDPC justice in this post with any luck that ll come in a later post to come as part of the RATPACK series, so some knowledge is assumed. As such this post is less useful for those looking to learn about LDPC, and a bit more targeted to those who enjoy talking and thinking about FEC.
Hey, heads up! - This post contains extremely unvalidated and back of the napkin quality work without any effort to prove this out generally. Hopefully this work can be of help to others, but please double check anything below if you need it for your own work!
While implementing LDPC, I ve gotten an encoder and checker working, enough to use LDPC like a checksum. The next big step is to write a Decoder, which can do error correction. The two popular approaches for the actual correction that I ve seen while reading about LDPC are Belief Propagation, and some class of linear programming that I haven t dug into yet. I m not thrilled at how expensive this all is in software, so while implementing the stack I ve been exploring every shady side ally to try and learn more about how encoders and decoders work, both in theory - and in practice.

Processing an LDPC Message Checking if a message is correct is fairly straightforward with LDPC (as with encoding, I ll note). As a quick refresher given the LDPC H (check) matrix of width N, you can check your message vector (msg) of length N by multipling H and msg, and checking if the output vector is all zero. 
 // scheme contains our G (generator) and
 // H (check) matrices.
 scheme :=  G: Matrix ... , H: Matrix ... 
// msg contains our LDPC message (data and
 // check bits).
 msg := Vector ... 
// N is also the length of the encoded
 // msg vector after check bits have been
 // added.
 N := scheme.G.Width
// Now, let's generate our 'check' vector.
 ch := Multiply(scheme.H, msg)
We can now see if the message is correct or not: 
 // if the ch vector is all zeros, we know
 // that the message is valid, and we don't
 // need to do anything.
 if ch.IsZero()  
// handle the case where the message
 // is fine as-is.
 return ...
 
// Expensive decode here
This is great for getting a thumbs up / thumbs down on the message being correct, but correcting errors still requires pulling the LDPC matrix values from the g (generator) matrix out, building a bipartite graph, and iteratively reprocessing the bit values, until constraints are satisfied and the message has been corrected. This got me thinking - what is the output vector when it s not all zeros? Since 1 values in the output vector indicates consistency problems in the message bits as they relate to the check bits, I wondered if this could be used to speed up my LDPC decoder. It appears to work, so this post is half an attempt to document this technique before I put it in my hot path, and half a plea for those who do like to talk about FEC to tell me what name this technique actually is.

k-Bit Brute Forcing Given that the output Vector s non-zero bit pattern is set due to the position of errors in the message vector, let s use that fact to build up a table of k-Bit errors that we can index into. 
 // for clarity's sake, the Vector
 // type is being used as the lookup
 // key here, even though it may
 // need to be a hash or string in
 // some cases.
 idx := map[Vector]int 
for i := 0; i < N; i++  
// Create a vector of length N
 v := Vector 
v.FlipBit(i)
// Now, let's use the generator matrix to encode
 // the data with checksums, and then use the
 // check matrix on the message to figure out what
 // bit pattern results
 ev := Multiply(scheme.H, Multiply(v, scheme.G))
idx[ev] = i
This can be extended to multiple bits (hence: k-Bits), but I ve only done one here for illustration. Now that we have our idx mapping, we can now go back to the hot path on Checking the incoming message data: 
 // if the ch vector is all zeros, we know
 // that the message is valid, and we don't
 // need to do anything.
 if ch.IsZero()  
// handle the case where the message
 // is fine as-is.
 return ...
 
errIdx, ok := idx[ch]
if ok  
msg.FlipBit(errIdx)
// Verify the LDPC message using
 // H again here.
 return ...
 
// Expensive decode here
Since map lookups wind up a heck of a lot faster than message-passing bit state, the hope here is this will short-circuit easy to solve errors for k-Bits, for some value of k that the system memory can tolerate.

Does this work? Frankly I have no idea. I ve written a small program and brute forced single-bit errors in all bit positions using random data to start with, and I ve not been able to find any collisions in the 1-bit error set, using the LDPC matrix from 802.3an-2006. Even if I was to find a collision for a higher-order k-Bit value, I m tempted to continue with this approach, and treat each set of bits in the Vector s bin (like a hash-table), checking the LDPC validity after each bit set in the bin. As long as the collision rate is small enough, it should be possible to correct k-Bits of error faster than the more expensive Belief Propagation approach. That being said, I m not entirely convinced collisions will be very common, but it ll take a bit more time working through the math to say that with any confidence. Have you seen this approach called something official in publications? See an obvious flaw in the system? Send me a tip, please!

Jonathan Dowland: Halloween playlist 2022

I hope you had a nice Halloween! I've collected together some songs that I've enjoyed over the last couple of years that loosely fit a theme: ambient, instrumental, experimental, industrial, dark, disconcerting, etc. I've prepared a Spotify playlist of most of them, but not all. The list is inline below as well, with many (but not all) tracks linking to Bandcamp, if I could find them there. This is a bit late, sorry. If anyone listens to something here and has any feedback I'd love to hear it. (If you are reading this on an aggregation site, it's possible the embeds won't work. If so, click through to my main site) Spotify playlist: https://open.spotify.com/playlist/3bEvEguRnf9U1RFrNbv5fk?si=9084cbf78c364ac8; The list, with Bandcamp embeds where possible: Some sources
  1. Via Stuart Maconie's Freak Zone
  2. Via Mary Anne Hobbs
  3. Via Lose yourself with
  4. Soma FM - Doomed (Halloween Special)

Russ Allbery: Review: What Makes This Book So Great

Review: What Makes This Book So Great, by Jo Walton
Publisher: Tor
Copyright: January 2014
ISBN: 0-7653-3193-4
Format: Hardcover
Pages: 447
Jo Walton, in addition to being an excellent science fiction and fantasy writer, is a prodigious reader and frequent participant in on-line SFF book discussion going back to the Usenet days. This book is a collection of short essays previously published on Tor.com between July 2008 and February 2011. The unifying theme is that Walton regularly re-reads her favorite books, and each essay (apart from some general essays on related topics) is about why this specific book is one that she re-reads, and (as the title says) what makes it so great. Searching for the title of one of the essays turns it up on Tor.com still, so this is one of those collections that you don't have to buy since you can read its contents on-line for free. That said, it looks like these essays were from before Tor.com started classifying posts into series, so it's going to be challenging to track them down in the huge number of other articles Walton has written for the site. (That said, you can't go far wrong by reading any of her essays at random.) I read these essays as they were originally published, so this was also a re-read for me, but it had been a while. I'm happy to report that they were just as much fun the second time. In the introduction and in the final essay of this collection, Walton draws a distinction between what she's doing, criticism, and reviewing. As someone else who writes about books (in a far more amateur fashion), I liked this distinction. The way I'd characterize it is that criticism is primarily about the work: taking it apart to see what makes it tick, looking for symbolism and hidden meanings, and comparing and contrasting other works that are tackling similar themes. I've often finished a work of criticism and still had no idea if the author enjoyed reading the work being criticized or not, since that isn't the point. Reviewing is assistance to consumers and focuses more on the reader: would you enjoy this book? Is it enjoyable to read? Does it say something new? What genre and style is it in, so that you can match that to your tastes? Talking about books is neither of those things, although it's a bit closer to reviewing. But the emphasis is on one's personal enjoyment instead of attempting to review a product for others. When I talk about books with friends, I talk primarily about what bits I liked, what bits I didn't like, where the emotional beats were for me, and what interesting things the book did that surprised me or caught my attention. One can find a review in there, and sometimes even criticism, but the focus and the formality is different. (And, to be honest, my reviews are more on the "talking about the book" side than fully proper reviews.) These essays are indeed talking about books. They're all re-reads; in some cases the first re-read, but more frequently the latest of many re-reads. There are lots of spoilers, which makes for bad reviews (the target audience of a review hasn't read the book yet) but good fodder for conversations about books. (The spoilers are mostly marked, but if you're particularly averse to spoilers, you'll need to read carefully.) Most of the essays are about a single book, but there are a few on more general topics, such as Walton's bafflement that anyone would skim a novel. Since these are re-reads, and the essays collected here are more than a decade old, the focus is on older books. Some of them are famous: Vinge's A Fire Upon the Deep and A Deepness in the Sky, early Le Guin, Samuel Delaney's SF novels, Salmon Rushdie's Midnight's Children. Some of them are more obscure. C.J. Cherryh, for example, is a writer who never seems to get much on-line attention, but who is one of Walton's favorites. Most of the essays stand alone or come in small clusters about a writer, often sprinkled through the book instead of clumped together. (The book publishes the essays in the same order they originally appeared on Tor.com.) The two largest groups of essays are re-readings of every book in Steven Brust's Vlad Taltos universe (including Brokedown Palace and the Paarfi books) up to Jhegaala, and every book in Lois McMaster Bujold's Miles Vorkosigan series up to Diplomatic Immunity. This is fitting: those are two of the great series of science fiction, but don't seem to be written about nearly as much as I would expect. There are over 130 essays in a 447 page book, so there's a lot of material here and none of them outlive their welcome. Walton has a comfortable, approachable style that bubbles with delight and appreciation for books. I think it's impossible to read this collection without wanting to read more, and without adding several more books to the ever-teetering to-read pile. This is perhaps not the best source of reading recommendations if you dislike spoilers, although it can be used for that if you read carefully. But if you love listening to conversations about the genre and talking about how books bounce off each other, and particularly if you have read most of these books already or don't mind spoilers, this collection is a delight. If you're the type of SFF reader who likes reading the reviews in Locus or is already reading Tor.com, highly recommended. Rating: 8 out of 10

Paul Wise: FLOSS Activities October 2022

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

Issues

Review

Administration
  • Debian BTS: unarchive/reopen/triage bugs for reintroduced packages nautilus-image-converter, swift-im, runit-services
  • Debian IRC: removed 2 spammers from OFTC, disable anti-spam channel modes for some channels
  • Debian servers: restart processes due to OOM
  • Debian wiki: approve accounts

Communication
  • Initiate discussion about the apt hook protocol
  • Respond to queries from Debian users and contributors on the mailing lists and IRC

Sponsors All work was done on a volunteer basis.

Louis-Philippe V ronneau: Montreal's Debian & Stuff - October 2022

Our local Debian user group gathered on Sunday October 30th to chat, work on Debian and do other, non-Debian related hacking :) This time around, we met at EfficiOS's1 offices. As you can see from the following picture, it's a great place and the view they have is pretty awesome. Many thanks for hosting us! The view from EfficiOS' offices, overlooking the Mont-Royal This was our 4th meeting this year and once again, attendance was great: 10 people showed up to work on various things. Following our bi-monthly schedule, our next meeting should be in December, but I'm not sure it'll happen. December can be a busy month here and I will have to poke our mailing list to see if people have the spoons for an event. This time around, I was able to get a rough log of the Debian work people did: pollo: mjeanson: viashimo: lavamind: anarcat: babelouest: tvaz: As always, thanks to the Debian project for granting us a budget to buy some food!
  1. Makers of the awesome LTTng project, amongst other things.

Dirk Eddelbuettel: RcppRedis 0.2.2 on CRAN: Maintenance and Enhancement

A new minor release 0.2.2 of our RcppRedis package arrived on CRAN this evening. RcppRedis is one of several packages connecting R to the fabulous Redis in-memory datastructure store (and much more). RcppRedis does not pretend to be feature complete, but it may do some things faster than the other interfaces, and also offers an optional coupling with MessagePack binary (de)serialization via RcppMsgPack. The package has carried production loads for several years now. This packages now brings a neat enhancement to the real-time data plotter code (and example) I have been using with for a while now. Paul Murrell kindly suggested dev.hold() and dev.flush() when I inquired how to minimize flicker from frequent updated. And this is perfect. I can now keep several data displays on during market hours without being distracted by flicker . It just updates, smooth as silk. Also included in the release are the usual two updates so en vogue these days: a (sole) sprinkling of void to appease clang-15, and an update the GitHub Action for checkout. Both silence some nags we would rather not see. The detailed changes list follows.

Changes in version 0.2.2 (2022-10-31)
  • Thanks to a suggestion by Paul Murrell, the real-time chart demo now uses dev.hold() and.flush() for flicker-free updates.
  • One function prototype was updated for clang-15.
  • GitHub Actions were updated to checkout version 3.

Courtesy of CRANberries, there is also a diffstat report for this release. More information is on the RcppRedis page. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

31 October 2022

Scarlett Gately Moore: KDE Gear Snaps fixes and new releases

Another continuation of https://www.scarlettgatelymoore.dev/kde-gear-snaps-round-3 ! This week I solved a few more problems. sudo snap install hunspell-dictionaries sudo snap connect lokalize:hunspell-dictionaries-plug hunspell-dictionaries:hunspell-dictionaries
Kdenlive with Glaximate animations!
More coming tomorrow! Please consider donating! Helps keep the lights on so I can get more Kool software out to you. https://www.patreon.com/sgmoore Cash App $ScarlettMoore0903 Stripe: https://buy.stripe.com/28o16y3PHcISfaE8ww

Jonathan Dowland: Cosey Fanni Tutti - Guitar/Amplitude

I haven't posted a crate digging picture for a while: Amongst other distractions, I needed to replace my turntable needle. The dead needle lasted me about 20 years, although a fair chunk of that was not spent not doing anything.
yellow 7inch record playing
I love Cosey Fanni Tutti's solo work, as well as her stuff with Chris Carter and some other collaborations: although I was familiar with Throbbing Gristle, it was the live experiment Carter Tutti Void and the recording of it pressed as Transverse that got me interested. "Tutti" was one of my top albums of 2019. Her autobiography Art, Sex, Music was fascinating. I haven't read the follow-up, Re-Sisters yet, but it's on my list. The Arena documentary she was involved with DELIA DERBYSHIRE: THE MYTHS AND THE LEGENDARY TAPES was fabulous. I've yet to hear Tutti's soundtrack album taken from it. This morning's record is a 7" from Electronic Sound magazine with two dark ambient instrumental pieces.

Alastair McKinstry: An Bord Plean la conceded that the N6 Galway City Ring Road was in ...

An Bord Plean la conceded that the N6 Galway City Ring Road was in contravention with the National Climate Action plan.
In planning for how we adapt to and mitigate climate change, the UN IPCC AR6 report summarised the state of research globally and modelled nearly 3000 scenarios. The scenarios that kept us below 2 degrees of warming (our Paris agreement commitments) overwhelmingly depended on a move away from car-dependent societies and relied on car-free cities. This report was signed off by every world government. All EU and national modelling agrees. Accordingly our national Climate Action plan prepares for this global move from cars. It involves a reduction in car traffic, heavy investment in public transport and active travel (walking and cycling). This is essential as the research shows this works, and takes up to 84% less energy for transport in cities. The N6GCRR plan ignored this, and assumed an increase in car traffic of up to 49%. It in practice would have locked in car dependency when we don t expect there to be enough materials (lithium, etc for batteries) or energy to support that number of cars.
Across Europe and the world we have seen how to move from cars in cities: rail, reliable bus services with dedicated bus corridors; safe, segregated cycle lanes, public space design that enables walking, cycling by keeping distances short the 15 minute city concept of having schools, shops, transport hubs less than 15 minutes from your door. From Paris, removing 40% of cars from the city, now removing a lane from the Peripherique (its ring road), to Korea where expressways in cities have been removed to improve traffic as part of its better design. In Ireland, Dublin has seen a 49% drop in peak-time traffic over recent decades with improved public transport and cycling. But in Galway we ve ignored all this: not a kilometre of segregated cycle lane added, as there has been an over 80% drop in pupils cycling to school since the 1980s, amplifying traffic as parents commute to drop them to school, making roads more dangerous. No bus route passes over the Quincentennial bridge. Rather than fix the traffic in Galway, a ring road would induce more traffic as the existing Bothar na dTreabh / Quincintennial bridge did; the current road opened up Knocknacarra for development; a new motorway to Barna would open up Barna for more development. This is zombie planning: a roads plan from the 1990s lives on, while our County Development Plan has moved the focus to creating new satellite towns in Ardaun and Garraun instead. When all new business wants to be on the East, the new developments need to be near them; new schools are being built on the East, not the West. Rail is being double-tracked to Oranmore (and on to Athenry) to provide commuter rail to Renmore and the growing towns. This reduces the demand for cross-city commuting. Active travel and public transport development in the city has been stalled awaiting the ring road. This needs to be implemented as quickly as possible. The bus corridor from Salthill (via the schools) to Oranmore (via the businesses at Ballybrit, Parkmore) needs to be completed; this will involve a bus lane on the bridge. The N6GCRR said this was impossible without a new bridge for cars; Dublin s experience with the quays shows otherwise. If we get a fraction of the drop Dublin has seen, the traffic problem will be solved, as shown when the schools are out for holidays. The NTA and Galway councils have been stuck in thinking from 30 years ago. They assume that traffic cannot be reduced, only added; the ABP inspector agreed, despite overwhelming evidence elsewhere. We need to implement what has been shown to work elsewhere as quickly as possible; the funding is in place but the will and vision to do so has been lacking.

Dirk Eddelbuettel: RcppGSL 0.3.12 on CRAN: Maintenance

A new release 0.3.12 of RcppGSL is now on CRAN. The RcppGSL package provides an interface from R to the GNU GSL by relying on the Rcpp package. This release accomodates, just like so many other releases this week, the more stringent views of clang-15 about what a correct function prototype is. While we were at it, an updatet to GitHub Actions was made as well. The NEWS entry follows:

Changes in version 0.3.12 (2022-10-30)
  • Two function prototypes were updated for clang-15.
  • GitHub Actions were updated to checkout version 3.

Courtesy of CRANberries, a summary of changes in the most recent release is also available. More information is on the RcppGSL page. Questions, comments etc should go to the issue tickets at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel: RcppBDT 0.2.6 on CRAN: Maintenance

A minor maintenance release for the RcppBDT package is now on CRAN. The RcppBDT package is an early adopter of Rcpp and was one of the first packages utilizing Boost and its Date_Time library. The now more widely-used package anytime is a direct descentant of RcppBDT. This release accomodates, just like so many other releases this week, the more stringent views of clang-15 about what a correct function prototype is. While we were at it, an updatet to GitHub Actions was made as well. The NEWS entry follows:

Changes in version 0.2.6 (2022-10-30)
  • A function prototype was updated for clang-15.
  • GitHub Actions were updated to checkout version 3.

Courtesy of my CRANberries, there is also a diffstat report for this release. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel: RApiDatetime 0.0.7 on CRAN: Maintenance

A new release of our RApiDatetime package is now on CRAN. RApiDatetime provides a number of entry points for C-level functions of the R API for Date and Datetime calculations. The functions asPOSIXlt and asPOSIXct convert between long and compact datetime representation, formatPOSIXlt and Rstrptime convert to and from character strings, and POSIXlt2D and D2POSIXlt convert between Date and POSIXlt datetime. Lastly, asDatePOSIXct converts to a date type. All these functions are rather useful, but were not previously exported by R for C-level use by other packages. Which this package aims to change. This release accomodates, just like so many other releases this week, the more stringent views of clang-15 about what a correct function prototype is. While we were at, updates to GitHub Actions and https URL were made as well.

Changes in RApiDatetime version 0.0.7 (2022-10-30)
  • A function prototype was updated for clang-15.
  • GitHub Actions were updated to checkout version 3.
  • Several remaining http:// URLs were converted to https://.

Courtesy of my CRANberries, there is are comparisons to the previous release. More information is on the rapidatetime page. For questions or comments please use the issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

30 October 2022

Utkarsh Gupta: FOSS Activites in October 2022

Here s my (thirty-seventh) monthly but brief update about the activities I ve done in the F/L/OSS world.

Debian
This was my 46th month of actively contributing to Debian. I became a DM in late March 2019 and a DD on Christmas 19! \o/ There s a bunch of things I do, both, technical and non-technical. Here are the things I did this month:

Debian Uploads
  • ruby-espeak (1.1.0-1) - New upstream version, v1.1.0.

Other $things:
  • Being an AM for Arun Kumar, process #1024. Process completed. \o/
  • Sponsoring stuff for non-DDs.
  • Mentoring for newcomers.
  • Moderation of -project mailing list.

Ubuntu
This was my 21st month of actively contributing to Ubuntu. Now that I joined Canonical to work on Ubuntu full-time, there s a bunch of things I do! \o/ I mostly worked on different things, I guess. I was too lazy to maintain a list of things I worked on so there s no concrete list atm. Maybe I ll get back to this section later or will start to list stuff from the fall, as I was doing before. :D

Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my thirty-seventh month as a Debian LTS and twenty-eighth month as a Debian ELTS paid contributor.
I worked for 35.00 hours for LTS and 25.00 hours for ELTS.

LTS CVE Fixes and Announcements:
  • Issued DLA 3146-1, fixing CVE-2022-2928 and CVE-2022-2929, for isc-dhcp.
    For Debian 10 buster, these problems have been fixed in version 4.4.1-2+deb10u2.
  • Issued DLA 3165-1, fixing CVE-2022-43680, for expat.
    For Debian 10 buster, these problems have been fixed in version 2.2.6-2+deb10u6.
  • Issued DLA 3166-1, fixing CVE-2022-29970, for ruby-sinatra.
    For Debian 10 buster, these problems have been fixed in version 2.0.5-4+deb10u1.
  • Uploaded dropbear to fix CVE-2021-36369 in buster. Waiting for ELTS upload to issue the DLA. But will do soon now.
  • src:joblib is a bit painful - having to backport patches to Py2. :/
  • Started to look at other set of packages.

ELTS CVE Fixes and Announcements:
  • Issued ELA 715-1, fixing CVE-2022-43680, for expat.
    For Debian 9 stretch, these problems have been fixed in version 2.2.0-2+deb9u7.
    For Debian 8 jessie, these problems have been fixed in version 2.1.0-6+deb8u10.
  • Issued ELA 716-1, fixing CVE-2018-25045 and CVE-2020-25626, for djangorestframework.
    For Debian 9 stretch, these problems have been fixed in version 3.4.0-2+deb9u1.
  • Uploaded dropbear to fix CVE-2021-36369 in buster. Waiting for ELTS upload, too. But some backporting problems. :/
  • src:joblib is a bit painful - having to backport patches to Py2. :/
  • Started to look at other set of packages.

Other (E)LTS Work:
  • Triaged joblib, dropbear, ruby-sinatra, djangorestframework, isc-dhcp, and expat.
  • Reverted Mark freerdp CVEs wrongly affecting freerdp <2.0.0 in the ELTS tracker.
  • Helped and assisted new contributors joining Freexian (LTS/ELTS).
  • Answered questions (& discussions) on IRC (#debian-lts and #debian-elts) and Matrix.
  • Participated and helped fellow members with their queries via private mail and chat.
  • General and other discussions on LTS private and public mailing list.
  • Attended the monthly meeting held on Jitsi on October 27th.
Until next time.
:wq for today.

29 October 2022

Dirk Eddelbuettel: littler 0.3.17 on CRAN: Maintenance

max-heap image The eighteenth release of littler as a CRAN package just landed, following in the now sixteen year history (!!) as a package started by Jeff in 2006, and joined by me a few weeks later. littler is the first command-line interface for R as it predates Rscript. It allows for piping as well for shebang scripting via #!, uses command-line arguments more consistently and still starts faster. It also always loaded the methods package which Rscript only started to do in recent years. littler lives on Linux and Unix, has its difficulties on macOS due to yet-another-braindeadedness there (who ever thought case-insensitive filesystems as a default were a good idea?) and simply does not exist on Windows (yet the build system could be extended see RInside for an existence proof, and volunteers are welcome!). See the FAQ vignette on how to add it to your PATH. A few examples are highlighted at the Github repo, as well as in the examples vignette. This release, coming just a few weeks since the last release in August, heeds to clang-15 a updates one signature to a proper interface. It also contains one kindly contributed patch updating install2.r (and installBioc.r) to cope with a change in R-devel. The full change description follows.

Changes in littler version 0.3.17 (2022-10-29)
  • Changes in package
    • An internal function prototype was updated for clang-15.
  • Changes in examples
    • The install2.r and installBioc. were updated for an update in R-devel (Tatsuya Shima and Dirk in #104).

My CRANberries service provides a comparison to the previous release. Full details for the littler release are provided as usual at the ChangeLog page, and also on the package docs website. The code is available via the GitHub repo, from tarballs and now of course also from its CRAN page and via install.packages("littler"). Binary packages are available directly in Debian as well as soon via Ubuntu binaries at CRAN thanks to the tireless Michael Rutter. Comments and suggestions are welcome at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Mike Hommey: Announcing git-cinnabar 0.5.11 and 0.6.0rc2

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. Get version 0.5.11 on github. Or get version 0.6.0rc2 on github. What s new in 0.5.11? What s new in 0.6.0rc2?

Russ Allbery: California general election

As usual with these every-two-year posts, probably of direct interest only to California residents. Maybe the more obscure things we're voting on will be a minor curiosity to people elsewhere. Apologies to Planet Debian readers for the explicitly political post because I'm too lazy to change my blog software to do more fine-grained post classification. For what it's worth, most of the discussion here will be about the more fiddly and nuanced things we vote on, not on the major hot-button proposition. As in 2020, I'm only going to cover the ballot propositions, as all of the state-wide and most of the district races are both obvious to me and boring to talk about. The hyperlocal races are more interesting this year, but the number of people who would care and who are also reading this blog is essentially nonexistent, so I won't bother writing them up. This year, everything except Proposition 1 is an initiative (not put on the ballot by the legislature), which means I default to voting against them because they're usually poorly-written. Proposition 1: YES. Adds reproductive rights to the California state constitution. I'm fairly sure everyone reading this has already made up their mind on this topic and certainly nothing will ever change my mind, so I'll leave it at that. Proposition 26: YES. This mushes two different things together in an unhelpful way: allowing sports betting at some racetracks, and allowing a wider variety of gambling on tribal lands. I have no strong opinion about the former (I'll get into that more with the next proposition). For the latter, my starting point is that Native American tribes are and should be treated like independent governments with their own laws (which is what we promised them by treaty and then have systematically and maliciously betrayed ever since). I am not a citizen of any of the tribes and therefore fundamentally I should not get a say on this. I'm not a big fan of gambling or of the companies they're likely to hire to run casinos, but it should be their land and their decision. Proposition 27: NO. This, on the other hand, is about on-line sports betting outside of tribal lands, and looks to be a lot more about corruption and corporate greed. I am fairly dubious that outlawing gambling in general is that good of an idea. I think the harms are overstated given the existence of even wilder forms of gambling (crypto and financial derivatives) that are perfectly legal, and I'm always suspicious of attempting to solve social problems with police and prohibition systems. If there were a ballot proposition to simply legalize gambling in California, I'd have to think hard about that. But this is not that. This requires companies that want to offer on-line gambling to pay substantial up-front costs (which will restrict this to only huge gambling companies). In return, they are allowed entry into what is essentially a state-constructed partial monopoly. As usual, there's a typical vice tax deal attached where those companies are taxed to fund some program (in this case, homeless services and mental health treatment), but these sorts of taxes tend to be regressive in effect. We could just tax richer people like me to pay for those services instead. I'm also dubious that the money for homelessness will be used to build housing, which is what we need to do to address the problem. Proposition 28: YES. Sets aside money for art and music funding in public and charter schools. This is a reluctant yes because this sort of law should not be done via proposition; it should be done through a normal legislative process that balances all of the priorities for school funding. But despite the broken process by which this was put forward, it seems like a reasonable law and no one is opposing it, so okay, fine. Proposition 29: NO. The attempt to force all dialysis clinics to have licensed doctors on site is back again. Everything about the way dialysis health care is provided in California makes me angry. We should have a state health care system similar to the NHS. We should open dialysis clinics based on the number of people requiring dialysis in that area. Every one of them should be unionized. We absolutely should not allow for-profit companies to have primary responsibility for basic life-saving medical care like dialysis. But this proposition does not solve any of those problems, and what it claims to do is false. It claims that by setting credential requirements on who has to be on-site at a dialysis clinic, the clinics will become safer. This is simply not true, for all of the reasons discussed in Still Not Safe. This is not how safety works. The safest person to do dialysis is someone with extensive experience in performing dialysis, who has seen all the problems and has an intuition for what to watch out for. That has less to do with credentials than with good training specifically in dialysis, apprenticeship, and practice, not to mention reasonable hours and good pay so that the workers are not stressed. Do I think the private dialysis clinics are likely doing a good job with this? Hah. (Do I think dialysis clinics run by large medical non-profits would do a good job with this? Also hah.) But this would enshrine into law a fundamentally incorrect solution to the problem that makes dialysis more expensive without addressing any of the other problems with the system. It's the same tactic that was used on abortion clinics, with the same bogus argument that having people with specific credentials on-site would make them safer. It was false then and it's still false now. I would agree with better regulation of dialysis clinics, but this specific regulation is entirely wrong-headed. Also, while this isn't an overriding factor, I get annoyed when the same proposition shows up again without substantial changes. For matters of fundamental rights, okay, sure. But for technical regulation fixes like this one, the proponents should consider taking no for an answer and trying a different approach. Like going to the legislature, which is where this kind of regulation should be designed anyway. Proposition 30: YES. Raises taxes on the personal income of extremely rich Californians (over $2 million in income in one year) to fund various climate change mitigation programs. This is another reluctant yes vote, because once again this shouldn't be done by initiative and should be written properly by the legislature. I also don't like restricting tax revenue to particular programs, which reduce budget flexibilty to no real purpose. It's not important to me that these revenues go to these specific programs, although the programs seem like good ones to fund. But the reality remains that wealthy Silicon Valley executives are undertaxed and the only way we can ever manage to raise taxes is through voting for things like this, so fine. Proposition 31: NO. The Calfornia legislature banned the sale of flavored vape products. If NO beats YES on this proposition, that ban will be overturned. Drug prohibition has never, ever worked, and yet we keep trying it over and over again in the hope that this time we'll get a different outcome. As usual, the pitch in favor of this is all about the children, specifically the claim that flavored tobacco products are only about increasing their appeal to kids because... kids like candy? Or something? I am extremely dubious of this argument; it's obvious to me from walking around city streets that adults prefer the flavored products as well and sale to kids is already prohibited and unchanged by this proposition. I don't like vaping. I wish people would stop, at least around me, because the scent is obnoxious and the flavored stuff is even more obnoxious, even apart from whatever health problems it causes. But I'm never going to vote for drug prohibition because drug prohibition doesn't work. It just creates a black market and organized crime and makes society overall worse. Yes, the tobacco companies are some of the worst corporations on the planet, and I hope they get sued into oblivion (and ideally prosecuted) for all the lying they do, but I'm still not going to vote for prohibition. Even the best kind of prohibition that only outlaws sale and not possession. Also, secondarily but still significant, bans like this just frustrate a bunch of people and burn good will and political capital, which we should be trying to preserve to tackle far more important problems. The politics of outlawing people's pleasures for their own good are not great. We have a lot of serious problems to deal with; maybe let's not pick fights we don't have to.

Dirk Eddelbuettel: gettz 0.0.5 on CRAN: Maintenance

A minor routine update 0.0.5 of gettz arrived on CRAN overnight. gettz provides a possible fallback in situations where Sys.timezone() fails to determine the system timezone. That happened when e.g. the file /etc/localtime somehow is not a link into the corresponding file with zoneinfo data in, say, /usr/share/zoneinfo. Since the package was written (in the fall of 2016), R added a similar extended heuristic approach itself. This release updates a function signature to satisfy the more stringent tests by clang-15, updates the GitHub Action checkout code to suppress a nag, and changes a few remaining http documentation links to https. As with the previous releses: No functional changes, no new code, or new features. Courtesy of my CRANberries, there is a comparison to the previous release. More information is on the gettz page. For questions or comments use the issue tracker off the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Fran ois Marier: Making the mounting of an encrypted /home optional on a home server

I have a computer that serves as a home server as well as a desktop machine. It has an encrypted home directory to protect user files and, in the default configuration, that unfortunately interferes with unattended reboots since someone needs to be present to enter the encryption password. Here's how I added a timeout and made /home optional on that machine. I started by adding a one-minute timeout on the password prompt by adding timeout=60 in my /etc/crypttab: 
crypt  UUID=7e12c123-abcd-5555-8c40-900d1f8cc281  none  luks,timeout=60
then I made /home optional by adding nofail to the appropriate mount point in /etc/fstab: 
/dev/mapper/crypt  /home  ext4  nodev,noatime,nosuid,nofail  0  2
Before that, the password prompt would timeout but the system would be unable to boot since one of the required partitions had failed to mount. Now, to ensure that I don't accidentally re-create home directories for users when the system is mounted without a /home, I made the /home directory on the non-encrypted drive read-only: 
umount /home
cd /home
chmod a-w .
Finally, with all of this in place, I was now happy to configure the machine to automatically reboot after a kernel panic by putting the following in /etc/sysctl.d/local.conf: 
# Automatic reboot 10 seconds after a kernel panic
kernel.panic = 10
since I know that the machine will come back up just fine and that all services will be running. I simply won't be able to log into that machine as any other user than root until I manually unlock and mount /home.

Next.

Previous.