Wait what People not familiar with Debian will not understand anything in that first paragraph, so let me expand. Know-it-all Debian developers (you know who you are) can skip to the next section. Traditionally, the Debian project (my Linux-based operating system of choice) has prided itself on the self-managed, anarchistic organisation of its packaging. Each package maintainer is the lord of their little kingdom. Some maintainers like to accumulate lots of kingdoms to rule over. (Yes, it really doesn't sound like anarchism when you put it like that. Yes, it's complicated: there's a constitution and voting involved. And yes, we're old.) Therefore, it's really hard to make package maintainers do something they don't want. Typically, when things go south, someone makes a complaint to the Debian Technical Committee (CTTE) which is established by the Debian constitution to resolve such conflicts. The committee is appointed by the Debian Project leader, elected each year (and there's an election coming up if you haven't heard). Typically, the CTTE will then vote and formulate a decision. But here's the trick: maintainers are still free to do whatever they want after that, in a sense. It's not like the CTTE can just break down doors and force maintainers to type code. (I won't go into the details of the why of that, but it involves legal issues and, I think, something about the Turing halting problem. Or something like that.) Anyways. The point is all that is super heavy and no one wants to go there... (Know-it-all Debian developers, I know you are still reading this anyways and disagree with that statement, but please, please, make it true.) ... but sometimes, packages just get lost. Maintainers get distracted, or busy with something else. It's not that they want to abandon their packages. They love their little fiefdoms. It's just there was a famine or a war or something and everyone died, and they have better things to do than put up fences or whatever. So clever people in Debian found a better way of handling such problems than waging war in the poor old CTTE's backyard. It's called the Package Salvaging process. Through that process, a maintainer can propose to take over an existing package from another maintainer, if a certain set of condition are met and a specific process is followed. Normally, taking over another maintainer's package is basically a war declaration, rarely seen in the history of Debian (yes, I do think it happened!), as rowdy as ours is. But through this process, it seems we have found a fair way of going forward. The process is basically like this:

1. file a bug proposing the change
2. wait three weeks
3. upload a package making the change, with another week delay
4. you now have one more package to worry about

Easy right? It actually is! Process! It's magic! It will cure your babies and resurrect your cat!

So how did that go? It went well! The old maintainer was actually fine with the change because his team wasn't using the package anymore anyways. He asked to be kept as an uploader, which I was glad to oblige. (He replied a few months after the deadline, but I wasn't in a rush anyways, so that doesn't matter. It was polite for him to answer, even if, technically, I was already allowed to take it over.) What happened next is less shiny for me though. I totally forgot about the ITS, even after the maintainer reminded me of its existence. See, the thing is the ITS doesn't show up on my dashboard at all. So I totally forgot about it (yes, twice). In fact, the only reason I remembered it was that got into the process of formulating another ITS (1008753, trocla) and I was trying to figure out how to write the email. Then I remembered: "hey wait, I think I did this before!" followed by "oops, yes, I totally did this before and forgot for 9 months". So, not great. Also, the package is still not in a perfect shape. I was able to upload the upstream version that was pending 1.5.0 to clear out the ITS, basically. And then there's already two new upstream releases to upload, so I pushed 1.7.0 to experimental as well, for good measure. Unfortunately, I still can't enable tests because everything is on fire, as usual. But at least my kingdom is growing.

Appendix Just in case someone didn't notice the hyperbole, I'm not a monarchist promoting feudalism as a practice to manage a community. I do not intend to really "grow my kingdom" and I think the culture around "property" of "packages" is kind of absurd in Debian. I kind of wish it would go away. (Update: It has also been pointed out that I might have made Debian seem more confrontational than it actually is. And it's kind of true: most work and interactions in Debian actually go fine, it's only a minority of issues that degenerate into conflicts. It's just that they tend to take up a lot of space in the community, and I find that particularly draining. And I think think our "package ownership" culture is part of at least some of those problems.) Team maintenance, the LowNMU process, and low threshold adoption processes are all steps in the good direction, but they are all opt in. At least the package salvaging process is someone a little more ... uh... coercive? Or at least it allows the community to step in and do the right thing, in a sense. We'll see what happens with the coming wars around the recent tech committee decision, which are bound to touch on that topic. (Hint: our next drama is called "usrmerge".) Hopefully, LWN will make a brilliant article to sum it up for us so that I don't have to go through the inevitable debian-devel flamewar to figure it out. I already wrecked havoc on the #debian-devel IRC channel asking newbie questions so I won't stir that mud any further for now. (Update: LWN, of course, did make an article about usrmerge in Debian. I will read it soon and can then tell you know if it's brilliant, but they are typically spot on.)

Pervasive technology contributes to the idea that the internet is immaterial With their search engine website design, Google has put in place an extremely simple and straightforward user interface. Since then, designers and psychologists have worked on making user interfaces more and more intuitive to use. The buzzwords are usability and user experience design . Besides this optimization of visual interfaces, haptic interfaces have evolved as well, specifically on smartphones and tablets where hand gestures have replaced more clumsy external haptic interfaces such as a mouse. And beyond interfaces, the devices themselves have become smaller and slicker. While in our generation many people have experienced opening a computer tower or a laptop to replace parts, with the side effect of seeing the parts the device is physically composed of, the new generation of end user devices makes this close to impossible, essentially transforming these devices into black boxes, and further contributing to the idea that the internet they are being used to access with would be something entirely intangible.

What do kids in 2022 really know about the internet? So, what do kids of that generation really know about the internet, beyond purely using services they do not control? In order to find out, I decided to interview children between 10 and 18. I conducted 5 interviews with kids aged 9, 10, 12, 15 and 17, two boys and three girls. Two live in rural Germany, one in a German urban area, and two live in the French capital. I wrote the questions in a way to stimulate the interviewees to tell me a story each time. I also told them that the interview is not a test and that there are no wrong answers. Except for the 9 year old, all interviewees possessed both, their own smartphone and their own laptop. All of them used the internet mostly for chatting, entertainment (video and music streaming, online games), social media (TikTok, Instagram, Youtube), and instant messaging. Let me introduce you to their concepts of the internet. That was my first story telling question to them:

If aliens had landed on Earth and would ask you what the internet is, what would you explain to them? The majority of respondents agreed in their replies that the internet is intangible while still being a place where one can do anything and everything . Before I tell you more about their detailed answers to the above question, let me show you how they visualize their internet.

If you had to make a drawing to explain to a person what the internet is, how would this drawing look like? Each interviewee had some minutes to come up with a drawing. As you will see, that drawing corresponds to what the kids would want an alien to know about the internet and how they are using the internet themselves.

Movies, series, videos The youngest respondent, a 9 year old girl, drew a screen with lots of people around it and the words film, series, network, video , as well as a play icon. She said that she mostly uses the internet to watch movies. She was the only one who used a shared tablet and smartphone that belonged to her family, not to herself. And she would explain the net like this to an alien:

"Internet is a er one cannot touch it it s an, er [I propose the word idea ], yes it s an idea. Many people use it not necessarily to watch things, but also to read things or do other stuff."

User interface elements A 10 year old boy represented the internet by recalling user interface elements he sees every day in his drawing: a magnifying glass (search engine), a play icon (video streaming), speech bubbles (instant messaging). He would explain the internet like this to an alien:

"You can use the internet to learn things or get information, listen to music, watch movies, and chat with friends. You can do nearly anything with it."

Another planet A 12 year old girl imagines the internet like a second, intangible, planet where Google, Wikipedia, Facebook, Ebay, or H&M are continents that one enters into.

"And on [the] Ebay [continent] there s a country for clothes, and ,trousers , for example, would be a federal state in that country."

Something that was unique about this interview was that she told me she had an email address but she never writes emails. She only has an email account to receive confirmation emails, for example when doing online shopping, or when registering to a service and needing to confirm one s address. This is interesting because it s an anti-spam measure that might become outdated with a generation that uses email less or not at all.

Home network A 15 year old boy knew that his family s devices are connected to a home router (Freebox is a router from the French ISP Free) but lacked an imagination of the rest of the internet s functioning. When I asked him about what would be behind the router, on the other side, he said what s behind is like a black hole to him. However, he was the only interviewee who did actually draw cables, wifi waves, a router, and the local network. His drawing is even extremely precise, it just lacks the cable connecting the router to the rest of the internet.

Satellite internet A 17 year old girl would explain the internet to an alien as follows:

"The internet goes around the entire globe. One is networked with everyone else on Earth. One can find everything. But one cannot touch the internet. It s like a parallel world. With a device one can look into the internet. With search engines, one can find anything in the world, one can phone around the world, and write messages. [The internet] is a gigantic thing."

This interviewee stated as the only one that the internet is huge. And while she also is the only one who drew the internet as actually having some kind of physical extension beyond her own home, she seems to believe that internet connectivity is based on satellite technology and wireless communication.

Imagine that a wise and friendly dragon could teach you one thing about the internet that you ve always wanted to know. What would you ask the dragon to teach you about? A 10 year old boy said he d like to know how big are the servers behind all of this . That s the only interview in which the word server came up. A 12 year old girl said I would ask how to earn money with the internet. I always wanted to know how this works, and where the money comes from. I love the last part of her question! The 15 year old boy for whom everything behind the home router is out of his event horizon would ask How is it possible to be connected like we are? How does the internet work scientifically? A 17 year old girl said she d like to learn how the darknet works, what hidden things are there? Is it possible to get spied on via the internet? Would it be technically possible to influence devices in a way that one can listen to secret or telecommanded devices? Lastly, I wanted to learn about what they find annoying, or problematic about the internet.

Imagine you could make the internet better for everyone. What would you do first? Asked what she would change if she could, the 9 year old girl advocated for a global usage limit of the internet in order to protect the human brain. Also, she said, her parents spend way too much time on their phones and people should rather spend more time with their children. Three of the interviewees agreed that they see way too many advertisements and two of them would like ads to disappear entirely from the web. The other one said that she doesn t want to see ads, but that ads are fine if she can at least click them away. The 15 year old boy had different ambitions. He told me he would change:

"the age of access to the internet. More and more younger people access the internet ; especially with TikTok there is a recommendation algorithm that can influcence young people a lot. And influencing young people should be avoided but the internet does it too much. And that can be negative. If you don t yet have a critical spirit, and you watch certain videos you cannot yet moderate your stance. It can influence you a lot. There are so many things that have become indispensable and that happen on the internet and we have become dependent. What happens if one day it doesn t work anymore? If we connect more and more things to the net, that s not a good thing."

The internet - Oh, that s what you mean! On a sidenote, my first interview tentative was with an 8 year old girl from my family. I asked her if she uses the internet and she denied, so I abandoned interviewing her. Some days later, while talking to her, she proposed to look something up on Google, using her smartphone. I said: Oh, so you are using the internet! She replied: Oh, that s what you re talking about? I think she knows the word Google and she knows that she can search for information with this Google thing. But it appeared that she doesn t know that the Google search engine is located somewhere else on internet and not on her smartphone. I concluded that for her, using the services on the smartphone is as natural as switching on a light in the house: we also don t think about where the electricity comes from when we do that.

What can we learn from these few interviews? Unsurprisingly, social media, streaming, entertainment, and instant messaging are the main activities kids undertake on the internet. They are completely at the mercy of advertisements in apps and on websites, not knowing how to get rid of them. They interact on a daily basis with algorithms that are unregulated and known to perpetuate discrimination and to create filter bubbles, without necessarily being aware of it. The kids I interviewed act as mere service users and seem to be mostly confined to specific apps or websites. All of them perceived the internet as being something intangible. Only the older interviewees perceived that there must be some kind of physical expansion to it: the 17 year old girl by drawing a network of satellites around the globe, the 15 year old boy by drawing the local network in his home. To be continued

I am old... The only formal timestamp I can put is that my rebuilt .emacs.d git repository has its first commit in 2002. Some people reading this may be born after that time. This means I'm at least significantly older than those people, to put things gently. Clever history nerds will notice that the commit is obviously fake: Git itself did not exist until 2005. But ah-ah! I was already managing my home directory with CVS in 2001! I converted that repository into git some time in 2009, and therefore you can see all my embarrassing history, including changes from two decades ago. That includes my first known .emacs file which is just bizarre to read right now: 200 lines, most of which are "customize" stuff. Compare with the current, 1000+ lines init.el which is also still kind of a mess, but actually shares very little with the original, thankfully. All this to say that in those years (decades, really) of using Emacs, I have had a very different experience than credmp who wrote packages, sent patches, and got name dropping from other developers. My experience is just struggling to keep up with everything, in general, but also in Emacs.

... and Emacs is too fast for me It might sound odd to say, but Emacs is actually moving pretty fast right now. A lot of new packages are coming out, and I can hardly keep up.

• I am not using org mode, but did use it for time (and task) tracking for a while (and for invoicing too, funky stuff).
• I am not using mu4e, but maybe I'm using something better (notmuch) and yes, I am reading my mail in Emacs, which I find questionable from a security perspective. (Sandboxing untrusted inputs? Anyone?)
• I am using magit, but only when coding, so I do end up using git on the command line quite a bit anyways.
• I do have which-key enabled, and reading about it reminded me I wanted to turn it off because it's kind of noisy and I never remember I can actually use it for anything. Or, in other words, I don't even remember the prefix key or, when I do, there's too many possible commands after for it to be useful.
• I haven't setup lsp-mode, let alone Eglot, which I just learned about reading the article. I thought I would be super shiny and cool by setting up LSP instead of the (dying?) elpy package, but I never got around to it. And now it seems lsp-mode is uncool and I should really do eglot instead, and that doesn't help. UPDATE: I finally got tired and switched to lsp-mode. The main reason for choosing it over eglot is that it's in Debian (and eglot is not). (Apparently, eglot has more chance of being upstreamed, "when it's done", but I guess I'll cross that bridge when I get there.) lsp-mode feels slower than elpy but I haven't done any of the performance tuning and this will improve even more with native compilation (see below). I already had lsp-mode partially setup in Emacs so I only had to do this small tweak to switch and change the prefix key (because s-l or mod is used by my window manager). I also had to pin LSP packages to bookworm here and here.
• I am not using projectile. It's on some of my numerous todo lists somewhere, surely. I suspect it's important to getting my projects organised, but I still live halfway between the terminal and Emacs, so it's not quite clear what I would gain.
• I had to ask what native compilation was or why it mattered the first time I heard of it. And when I saw it again in the article, I had to click through to remember.

Overall, I feel there's a lot of cool stuff in Emacs out there. But I can't quite tell what's the best of which. I can barely remember which completion mechanism I use (company, maybe?) or what makes my mini-buffer completion work the way it does. Everything is lost in piles of customize and .emacs hacks that is constantly changing. Because a lot is in third-party packages, there are often many different options and it's hard to tell which one we should be using.

... or at least fast enough And really, Emacs feels fast enough for me. When I started, I was running Emacs on a Pentium I, 166MHz, with 8MB of RAM (eventually upgraded to 32MB, whoohoo!). Back in those days, the joke was that EMACS was an acronym for "Eight Megs, Always Scratching" and now that I write this down, I realize it's actually "Eight Megs, and Constantly Swapping", which doesn't sound as nice because you could actually hear Emacs running on those old hard drives back in the days. It would make a "scratching" noise as the hard drive heads would scramble maniacally to swap pages in and out of swap to make room for the memory-hungry editor. Now Emacs is pretty far down the list of processes in top(1) regardless of how you look at it. It's using 97MB of resident memory and close to 400MB of virtual memory, which does sound like an awful lot compared to my first computer... But it's absolutely nothing compared to things like Signal-desktop, which somehow manages to map a whopping 20.5GB virtual memory. (That's twenty Gigabytes of memory for old timers or time travelers from the past, and yes, that is now a thing.) I'm not exactly sure how much resident memory it uses (because it forks multiple processes), probably somewhere around 300MB of resident memory. Firefox also uses gigabytes of that good stuff, also spread around the multiple processes, per tab. Emacs "feels" super fast. Typing latency is noticeably better in Emacs than my web browser, and even beats most terminal emulators. It gets a little worse when font-locking is enabled, unfortunately, but it's still feels much better. And all my old stuff still works in Emacs, amazingly. (Good luck with your old Netscape or ICQ configuration from 2000.) I feel like an oldie, using Emacs, but I'm really happy to see younger people using it, and learning it, and especially improving it. If anything, one direction I would like to see it go is closer to what web browsers are doing (yes, I know how bad that sounds) and get better isolation between tasks. An attack on my email client shouldn't be able to edit my Puppet code, and/or all files on my system, for example. And I know, fundamentally, that's a really hard challenge in Emacs. But if you're going to treat your editor as your operating system (or vice versa, I lost track of where we are now that there's an Emacs Window Manager, which I do not use), at least we should get that kind of security. Otherwise I'll have to find a new mail client, and that's really something I try to limit to once a decade or so.

• In February Rapha l and the LTS worked on a survey of Debian developers meant to solicit ideas for improvements in the Debian project at large. You can see the results of the initial discussion here in the list of ideas of which there are already over 30.
• The full survey is due to be emailed to Debian Developers shortly.
• In February 2250 was put aside to fund Debian projects.

• Abhijith PA did 10h out of 10h available.
• Anton Gladky did 20h out of 20h available.
• Ben Hutchings did 16h out of 16h available.
• Chris Lamb did 18h out of 18h available.
• Emilio Pozuelo Monfort did 42.75h out of 42.75h available.
• Jeremiah Foster worked 20 hours out of 20 available on LTS administration and 2.9 hours on funded projects.
• Markus Koschany did 30h (out of 40h available), thus carrying over 10h to March.
• Roberto C. S nchez did 12h out of 12h available.
• Sylvain Beucler did 13h (out of 40h available), thus carrying over 27h to March.
• Thorsten Alteholz did 40h out of 40h available.
• Utkarsh Gupta did 15.75h (out of 42.75h available), thus carrying over 27h to March.

• Platinum sponsors:
  • TOSHIBA (for 78 months)
  • GitHub (for 68 months)
  • Civil Infrastructure Platform (CIP) (for 46 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 89 months)
  • Linode (for 83 months)
  • Babiel GmbH (for 72 months)
  • Plat Home (for 71 months)
  • University of Oxford (for 28 months)
  • Deveryware (for 15 months)
  • VyOS Inc (for 10 months)
• Silver sponsors:
  • The Positive Internet Company (for 94 months)
  • Domeneshop AS (for 93 months)
  • Nantes M tropole (for 87 months)
  • Univention GmbH (for 79 months)
  • Universit Jean Monnet de St Etienne (for 79 months)
  • Ribbon Communications, Inc. (for 73 months)
  • Exonet B.V. (for 63 months)
  • Leibniz Rechenzentrum (for 57 months)
  • CINECA (for 46 months)
  • Minist re de l Europe et des Affaires trang res (for 40 months)
  • Cloudways Ltd (for 29 months)
  • Dinahosting SL (for 27 months)
  • Platform.sh (for 22 months)
  • Bauer Xcel Media Deutschland KG (for 21 months)
  • Moxa Intelligence Co., Ltd. (for 16 months)
  • sipgate GmbH (for 13 months)
  • OVH US LLC (for 11 months)
  • Tilburg University (for 11 months)
  • GSI Helmholtzzentrum f r Schwerionenforschung GmbH
  • Telecats BV
  • Soliton Systems K.K.
• Bronze sponsors:
  • Evolix (for 94 months)
  • Seznam.cz, a.s. (for 94 months)
  • Linuxhotel GmbH (for 91 months)
  • Intevation GmbH (for 90 months)
  • Daevel SARL (for 89 months)
  • Bitfolk LTD (for 88 months)
  • Megaspace Internet Services GmbH (for 88 months)
  • Greenbone Networks GmbH (for 87 months)
  • NUMLOG (for 87 months)
  • WinGo AG (for 86 months)
  • Ecole Centrale de Nantes LHEEA (for 83 months)
  • Entr ouvert (for 78 months)
  • Adfinis AG (for 75 months)
  • Laboratoire LEGI UMR 5519 / CNRS (for 70 months)
  • Tesorion (for 70 months)
  • GNI MEDIA (for 69 months)
  • Bearstech (for 61 months)
  • LiHAS (for 61 months)
  • People Doc (for 57 months)
  • Catalyst IT Ltd (for 56 months)
  • Supagro (for 51 months)
  • Demarcq SAS (for 50 months)
  • Universit Grenoble Alpes (for 36 months)
  • TouchWeb SAS (for 28 months)
  • SPiN AG (for 24 months)
  • CoreFiling (for 20 months)
  • Institut des sciences cognitives Marc Jeannerod (for 15 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 11 months)
  • Tem Innovations GmbH (for 6 months)
  • WordFinder.pro (for 6 months)
  • CNRS DT INSU R sif (for 4 months)

• Find a list of packages(failing rebuild and testing with autopkgtest, of reverse dependencies of webpack and nodejs) to fix.
• See if new upstream versions are available that support nodejs16 and webpack5 respectively.
• See if the new upstream version works and doesn't fail while rebuilding or testing with autopkgtest.
• Report bug in Debian if any fails to rebuild or test with autopkgtest.
• Forward bugs upstream if needed.
• Fix packages and forward patches.

Various efforts towards build verifiability have been made to C/C++-based systems, yet the techniques for Java-based systems are not systematic and are often specific to a particular build tool (eg. Maven). In this study, we present a systematic approach towards build verifiability on Java-based systems.

We first define the problem, and then provide insight into the challenges of making real-world software build in a reproducible manner-this is, when every build generates bit-for-bit identical results. Through the experience of the Reproducible Builds project making the Debian Linux distribution reproducible, we also describe the affinity between reproducibility and quality assurance (QA).

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb prepared and uploaded versions 203, 204, 205 and 206 to Debian unstable, as well as made the following changes to the code itself:

• Bug fixes:
  • Fix a file(1)-related regression where Debian .changes files that contained non-ASCII text were not identified as such, therefore resulting in seemingly arbitrary packages not actually comparing the nested files themselves. The non-ASCII parts were typically in the Maintainer or in the changelog text. [ ][ ]
  • Fix a regression when comparing directories against non-directories. [ ][ ]
  • If we fail to scan using binwalk, return False from BinwalkFile.recognizes. [ ]
  • If we fail to import binwalk, don t report that we are missing the Python rpm module! [ ]
• Testsuite improvements:
  • Add a test for recent file(1) issue regarding .changes files. [ ]
  • Use our assert_diff utility where we can within the test_directory.py set of tests. [ ]
  • Don t run our binwalk-related tests as root or fakeroot. The latest version of binwalk has some new security protection against this. [ ]
• Codebase improvements:
  • Drop the _PATH suffix from module-level globals that are not paths. [ ]
  • Tidy some control flow in Difference._reverse_self. [ ]
  • Don t print a warning to the console regarding NT_GNU_BUILD_ID changes. [ ]

In addition, Mattia Rizzolo updated the Debian packaging to ensure that diffoscope and diffoscope-minimal packages have the same version. [ ]

Debian-related updates Vagrant Cascadian wrote to the debian-devel mailing list after noticing that the binutils source package contained unreproducible logs in one of its binary packages. Vagrant expanded the discussion to one about all kinds of build metadata in packages and outlines a number of potential solutions that support reproducible builds and arbitrary metadata. Vagrant also started a discussion on debian-devel after identifying a large number of packages that embed build paths via RPATH when building with CMake, including a list of packages (grouped by Debian maintainer) affected by this issue. Maintainers were requested to check whether their package still builds correctly when passing the -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON directive. On our mailing list this month, kpcyrd announced the release of rebuilderd-debian-buildinfo-crawler a tool to parse the Packages.xz Debian package index file, attempts to discover the right .buildinfo file from buildinfos.debian.net and outputs it in a format that can be understood by rebuilderd. The tool, which is available on GitHub, solves a problem regarding correlating Debian version numbers with their builds. bauen1 provided two patches for debian-cd, the software used to make Debian installer images. This involved passing --invariant and -i deb00001 to mkfs.msdos(8) and avoided embedding timestamps into the gzipped Packages and Translations files. After some discussion, the patches in question were merged and will be included in debian-cd version 3.1.36. Roland Clobus wrote another in-depth status update about status of live Debian images, summarising the current situation that all major desktops build reproducibly with bullseye, bookworm and sid . The python3.10 package was uploaded to Debian by doko, fixing an issue where [.pyc files were not reproducible because the elements in frozenset data structures were not ordered reproducibly. This meant that to creating a bit-for-bit reproducible Debian chroot which included .pyc files was not reproducible. As of writing, the only remaining unreproducible parts of a standard chroot is man-db, but Guillem Jover has a patch for update-alternatives which will likely be part of the next release of dpkg. Elsewhere in Debian, 139 reviews of Debian packages were added, 29 were updated and 17 were removed this month adding to our knowledge about identified issues. A large number of issue types have been updated too, including the addition of captures_kernel_variant, erlang_escript_file, captures_build_path_in_r_rdb_rds_databases, captures_build_path_in_vo_files_generated_by_coq and build_path_in_vo_files_generated_by_coq.

Website updates There were quite a few changes to the Reproducible Builds website and documentation this month as well, including:

• Chris Lamb:
  • Considerably rework the Who is involved? page. [ ][ ]
  • Move the contributors.sh Bash/shell script into a Python script. [ ][ ][ ]
• Daniel Shahaf:
  • Try a different Markdown footnote content syntax to work around a rendering issue. [ ][ ][ ]
• Holger Levsen:
  • Make a huge number of changes to the Who is involved? page, including pre-populating a large number of contributors who cannot be identified from the metadata of the website itself. [ ][ ][ ][ ][ ]
  • Improve linking to sponsors in sidebar navigation. [ ]
  • drop sponsors paragraph as the navigation is clearer now. [ ]
  • Add Mullvad VPN as a bronze-level sponsor . [ ][ ]
• Vagrant Cascadian:
  • Remove a stray parenthesis from the Who is involved? page. [ ]

Upstream patches The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. February s patches included the following:

• Bernhard M. Wiedemann:
  • btop (sort-related issue)
  • complexity (date)
  • giac (update the version with upstreamed date patch)
  • htcondor (use CMake timestamp)
  • libint (readdir system call related)
  • libnet (date-related issue)
  • librime-lua (sort filesystem ordering)
  • linux_logo (sort-related issue)
  • micro-editor (date-related issue)
  • openvas-smb (date-related issue)
  • ovmf (sort-related issue)
  • paperjam (date-related issue)
  • python-PyQRCode (date-related issue)
  • quimb (single-CPU build failure)
  • radare2 (Meson date/time-related issue)
  • radare2 (Rework SOURCE_DATE_EPOCH usage to be portable)
  • siproxd (date, with Sebastian Kemper + follow-up
  • xonsh (Address Space Layout Randomisation-related issue)
  • xsnow (date & tar(1)-related issue)
  • zip (toolchain issue related to filesystem ordering)
• Chris Lamb:
  • #1005029 filed against ltsp (forwarded upstream).
  • #1005197 filed against pcmemtest.
  • #1005825 filed against hatchling.
  • #1005826 filed against mpl-sphinx-theme (forwarded upstream)
  • #1005827 filed against gap-hapcryst.
  • #1005901 filed against tree-puzzle.
  • #1005954 filed against jcabi-aspects.
  • #1005955 filed against paper-icon-theme.
• Roland Clobus:
  • #1006358 filed against libxmlb.
• Vagrant Cascadian:
  • #1005408 filed against wcwidth.
  • #1005420 filed against xir.
  • #1005421 filed against xir.
  • #1005726 filed against ruby-github-markup.
  • #1005727 filed against ruby-tioga.
  • #1005792 filed against btop.
  • #1005793 filed against libadwaita-1.
  • #1005794 filed against snibbetracker.
  • #1006252 filed against cctbx.
  • #1006254 filed against mdnsd.
  • #1006256 filed against gmerlin.
  • #1006302 filed against beav.
  • #1006385 filed against krita.
  • #1006407 filed against qt6-base.
  • #1006455 filed against onevpl-intel-gpu.
  • #1006471 filed against ruby3.0.
  • #1006473 filed against nix.
  • #1006474 filed against foma.
  • #1006476 filed against ruby3.0.

Testing framework The Reproducible Builds project runs a significant testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, the following changes were made:

• Daniel Golle:
  • Update the OpenWrt configuration to not depend on the host LLVM, adding lines to the .config seed to build LLVM for eBPF from source. [ ]
  • Preserve more OpenWrt-related build artifacts. [ ]
• Holger Levsen:
• Temporary use a different Git tree when building OpenWrt as our tests had been broken since September 2020. This was reverted after the patch in question was accepted by Paul Spooren into the canonical openwrt.git repository the next day.
  • Various improvements to debugging OpenWrt reproducibility. [ ][ ][ ][ ][ ]
  • Ignore useradd warnings when building packages. [ ]
  • Update the script to powercycle armhf architecture nodes to add a hint to where nodes named virt-*. [ ]
  • Update the node health check to also fix failed logrotate and man-db services. [ ]
• Mattia Rizzolo:
  • Update the website job after contributors.sh script was rewritten in Python. [ ]
  • Make sure to set the DIFFOSCOPE environment variable when available. [ ]
• Vagrant Cascadian:
  • Various updates to the diffoscope timeouts. [ ][ ][ ]

Node maintenance was also performed by Holger Levsen [ ] and Vagrant Cascadian [ ].

Finally If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

• doveconf to dump dovecot's configuration to see if what it understands matches what I mean
• sieve-test parses sieve scripts: sieve-test file.sieve /dev/null is a quick and dirty syntax check

BACKUP="/srv/backupts/test- date +%Y-%m-d .mbox"
:0c
$BACKUP

apt install dovecot-sieve dovecot-lmtpd

service lmtp  
  unix_listener /var/spool/postfix/private/dovecot-lmtp  
    user = postfix
    group = postfix
    mode = 0666
   
 
protocol lmtp  
  mail_plugins = $mail_plugins sieve
 
plugin  
  sieve = file:~/.sieve;active=~/.dovecot.sieve
 

 plugin  
   sieve = file:~/.sieve;active=~/.dovecot.sieve
+  sieve_plugins = sieve_extprograms
+  sieve_extensions +vnd.dovecot.pipe
+  sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve-pipe
+  sieve_trace_dir = ~/.sieve-trace
+  sieve_trace_level = matching
+  sieve_trace_debug = yes
  

mkdir -p /usr/local/lib/dovecot/sieve-pipe/
(echo "#!/bin/sh'; echo "exec /usr/bin/procmail") > /usr/local/lib/dovecot/sieve-pipe/procmail
chmod 0755 /usr/local/lib/dovecot/sieve-pipe/procmail

require "vnd.dovecot.pipe";
pipe "procmail";

--- a/roles/mailserver/templates/dovecot.conf
+++ b/roles/mailserver/templates/dovecot.conf
@@ -25,6 +25,8 @@
 
+auth_username_format = %Ln
+
 
diff --git a/roles/mailserver/templates/main.cf b/roles/mailserver/templates/main.cf
index d2c515a..d35537c 100644
--- a/roles/mailserver/templates/main.cf
+++ b/roles/mailserver/templates/main.cf
@@ -64,8 +64,7 @@ virtual_alias_domains =
 
-mailbox_command = procmail -a "$EXTENSION"
-mailbox_size_limit = 0
+mailbox_transport = lmtp:unix:private/dovecot-lmtp
 

 plugin  
   sieve = file:~/.sieve;active=~/.dovecot.sieve
   sieve_plugins = sieve_extprograms
-  sieve_extensions +vnd.dovecot.pipe
+  sieve_extensions +vnd.dovecot.pipe +vnd.dovecot.filter
   sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve-pipe
+  sieve_filter_bin_dir = /usr/local/lib/dovecot/sieve-filter
   sieve_trace_dir = ~/.sieve-trace
   sieve_trace_level = matching
   sieve_trace_debug = yes
  

mkdir -p /usr/local/lib/dovecot/sieve-filter/"
(echo "#!/bin/sh'; echo "exec /usr/bin/spamc") > /usr/local/lib/dovecot/sieve-filter/spamc
chmod 0755 /usr/local/lib/dovecot/sieve-filter/spamc

:0 fw
  /usr/bin/spamc
:0
* ^X-Spam-Status: Yes
.spam/

require "vnd.dovecot.filter";
require "fileinto";
filter "spamc";
if header :contains "x-spam-level" "**************"  
    discard;
  elsif header :matches "X-Spam-Status" "Yes,*"  
    fileinto "spam";
 

require "date"
require "variables"
if currentdate :matches "month" "*"   set "month" "$ 1 ";  
if currentdate :matches "year" "*"   set "year" "$ 1 ";  
fileinto :create "$ month -$ year ";

Some surprises

Filters For the last two years, with the exception of one little heart attack, LVM caches have gone very smoothly. Then, last week we upgraded 13 physical servers straight through from stretch to bullseye. It went relatively smoothly for the first half of our servers (the old ones hosting fewer resources). But, after rebooting our first server with lvm caching going on, we noticed that the cached disk wasn t accessible. No problem, we reasoned. We ll just uncache it. Except that didn t work either. We tried every argument we could find on the Internet but lvm insisted that the block device from the SSD volume group (that provides the caching device) was not available. Running pvs showed an unknown device and vgs reported similar errors. Now I started to panic a bit. There was a clean shutdown of the server, so surely all the data had been flushed to the disk. But, how can we get that data? We started a restore from backup process because we really thought that data was gone for ever. Then we had a really great theory: the caching logical volume comes from the SSD volume group, which gets decrypted after the spinning disk volume group. Maybe there s a timing issue? When the spinning disk volume group comes online, the caching logical volume is not yet available. So, we booted into busybox, and manually decrypted the SSD volume first, followed by the spinning disk volume. Alas, no dice. Now that we were fully desperate, we decided to restore the lvm configuration file for the entire spinning disk volume group. This felt kinda risky since we might be damaging all the currently working logical volumes, but it seemed like the only option we had. The main problem was that busybox didn t seem to have the lvm config tool we needed to restore the configuration from our backup (I think it might be there but it was late and we couldn t figure it out). And, our only readily available live install media was a Debian stretch disk via debirf. Debian stretch is pretty old and we really would have preferred to have the most modern tools available, but we decided to go with what we had. And, that was a good thing, because as soon as we booted into stretch and decrypted the disks, the lvm volume suddenly appeared, happy as ever. We uncached it and booted into the host system and there it was. We went to bed confused but relieved. The next morning my co-worker figured it out: filtering. During the stretch days we occassionally ran into an annoying problem: the logical volumes from guests would suddenly pop up on the host. This was mostly annoying but also it made possible some serious mistakes if you accidentally took a volume from a guest and used it on the host. The LVM folks seemed to have noticed this problem and introduced a new default filter that tries to only show you the devices that you should be seeing. Unfortunately for us, this new filter removed logical volumes from the list of available physical volumes. That does make sense for most people. But, not for us. It sounds a bit weird, but our setup looks like this:

• One volume group derived from the spinning disks
• One volume group derived from the SSD disks

Then we carve out logical volumes from each for each guest. Once we discovered LVM caching, we carved out SSD logical volumes to be used as caches for the spinning logical volumes. In restrospect, if we could start over, we would probably do it differently. In any event, once we discovered the problem, we used the handy configuration options in lvm.conf to tweak the filters to include our cache disks and once again, everything is back to working.

Saturated SSDs The other surprise seems unrelated to the upgrade. We have a phsyical server that has been suffering from disk i/o problems despite our use of LVM caching. Our answer, of course, was to add more LVM caches to the spinning logical volumes that seemed to be suffering. But somehow this was making things even worse. Then, we finally just removed the LVM caches from all the spinning disks and presto, disk i/o problems seemed to go away. What? Isn t that the opposite of what s supposed to happen? We re still trying to figure this one out, but it seems that our SSDs are saturated, in which case adding them as a caching volume really is going to make things worse. We re still not sure why they are saturated when none of the SSDs on our other hosts are saturated, but a few theories include:

• They are doing more writing and/or it s a different kind of writing. I m still not sure I quite have the right tool to compare this host with other hosts. And, this host is our only MySQL network database server, hosting hundreds of GBs of database - all writing/reading direclty onto the SSDs.
• They are broken or substanard SSDs (smartctl doesn t uncover any problems but maybe it s a bad model?)

I ll update this post as we learn more but welcome any suggestions in the comments. Update: 2022-03-07 Two more possible causes:

• Our use of the write back feature: LVM cache has a nice feature that caches writes to smooth out writes to the underlying disk. Maybe our disks are simply writing more then can be handled and not using write back is our solution. This server supports a guest with an unusually large disk.
• Maybe we haven t allocated a big enough LVM cache for the given volume so the contents are constantly being ejected?

Procmail is unmaintained procmail is unmaintained. The "Final release", according to Wikipedia, dates back to September 10, 2001 (3.22). That release was shipped in Debian since then, all the way back from Debian 3.0 "woody", twenty years ago. Debian also ships 25 uploads on top of this, with 3.22-21 shipping the "3.23pre" release that has been rumored since at least the November 2001, according to debian/changelog at least:

procmail (3.22-1) unstable; urgency=low
  * New upstream release, which uses the  standard' format for Maildir
    filenames and retries on name collision. It also contains some
    bug fixes from the 3.23pre snapshot dated 2001-09-13.
  * Removed  sendmail' from the Recommends field, since we already
    have  exim' (the default Debian MTA) and  mail-transport-agent'.
  * Removed suidmanager support. Conflicts: suidmanager (<< 0.50).
  * Added support for DEB_BUILD_OPTIONS in the source package.
  * README.Maildir: Do not use locking on the example recipe,
    since it's wrong to do so in this case.
 -- Santiago Vila <sanvila@debian.org>  Wed, 21 Nov 2001 09:40:20 +0100

All Debian suites from buster onwards ship the 3.22-26 release, although the maintainer just pushed a 3.22-27 release to fix a seven year old null pointer dereference, after this article was drafted. Procmail is also shipped in all major distributions: Fedora and its derivatives, Debian derivatives, Gentoo, Arch, FreeBSD, OpenBSD. We all seem to be ignoring this problem. The upstream website (http://procmail.org/) has been down since about 2015, according to Debian bug #805864, with no change since. In effect, every distribution is currently maintaining its fork of this dead program. Note that, after filing a bug to keep Debian from shipping procmail in a stable release again, I was told that the Debian maintainer is apparently in contact with the upstream. And, surprise! they still plan to release that fabled 3.23 release, which has been now in "pre-release" for all those twenty years. In fact, it turns out that 3.23 is considered released already, and that the procmail author actually pushed a 3.24 release, codenamed "Two decades of fixes". That amounts to 25 commits since 3.23pre some of which address serious security issues, but none of which address fundamental issues with the code base.

Procmail is insecure By default, procmail is installed SUID root:mail in Debian. There's no debconf or pre-seed setting that can change this. There has been two bug reports against the Debian to make this configurable (298058, 264011), but both were closed to say that, basically, you should use dpkg-statoverride to change the permissions on the binary. So if anything, you should immediately run this command on any host that you have procmail installed on:

dpkg-statoverride --update --add root root 0755 /usr/bin/procmail

Note that this might break email delivery. It might also not work at all, thanks to usrmerge. Not sure. Yes, everything is on fire. This is fine. In my opinion, even assuming we keep procmail in Debian, that default should be reversed. It should be up to people installing procmail to assign it those dangerous permissions, after careful consideration of the risk involved. The last maintainer of procmail explicitly advised us (in that null pointer dereference bug) and other projects (e.g. OpenBSD, in [2]) to stop shipping it, back in 2014. Quote:

Executive summary: delete the procmail port; the code is not safe and should not be used as a basis for any further work.

I just read some of the code again this morning, after the original author claimed that procmail was active again. It's still littered with bizarre macros like:

#define bit_set(name,which,value) \
  (value?(name[bit_index(which)] =bit_mask(which)):\
  (name[bit_index(which)]&=~bit_mask(which)))

... from regexp.c, line 66 (yes, that's a custom regex engine). Or this one:

#define jj  (aleps.au.sopc)

It uses insecure functions like strcpy extensively. malloc() is thrown around gotos like it's 1984 all over again. (To be fair, it has been feeling like 1984 a lot lately, but that's another matter entirely.) That null pointer deref bug? It's fixed upstream now, in this commit merged a few hours ago, which I presume might be in response to my request to remove procmail from Debian. So while that's nice, this is the just tip of the iceberg. I speculate that one could easily find an exploitable crash in procmail if only by running it through a fuzzer. But I don't need to speculate: procmail had, for years, serious security issues that could possibly lead to root privilege escalation, remotely exploitable if procmail is (as it's designed to do) exposed to the network. Maybe I'm overreacting. Maybe the procmail author will go through the code base and do a proper rewrite. But I don't think that's what is in the cards right now. What I expect will happen next is that people will start fuzzing procmail, throw an uncountable number of bug reports at it which will get fixed in a trickle while never fixing the underlying, serious design flaws behind procmail.

Procmail has better alternatives The reason this is so frustrating is that there are plenty of modern alternatives to procmail which do not suffer from those problems. Alternatives to procmail(1) itself are typically part of mail servers. For example, Dovecot has its own LDA which implements the standard Sieve language (RFC 5228). (Interestingly, Sieve was published as RFC 3028 in 2001, before procmail was formally abandoned.) Courier also has "maildrop" which has its own filtering mechanism, and there is fdm (2007) which is a fetchmail and procmail replacement. Update: there's also mailprocessing, which is not an LDA, but processing an existing folder. It was, however, specifically designed to replace complex Procmail rules. But procmail, of course, doesn't just ship procmail; that would just be too easy. It ships mailstat(1) which we could probably ignore because it only parses procmail log files. But more importantly, it also ships:

• lockfile(1) - conditional semaphore-file creator
• formail(1) - mail (re)formatter

lockfile(1) already has a somewhat acceptable replacement in the form of flock(1), part of util-linux (which is Essential, so installed on any normal Debian system). It might not be a direct drop-in replacement, but it should be close enough. formail(1) is similar: the courier maildrop package ships reformail(1) which is, presumably, a rewrite of formail. It's unclear if it's a drop-in replacement, but it should probably possible to port uses of formail to it easily.

Update: the maildrop package ships a SUID root binary (two, even). So if you want only reformail(1), you might want to disable that with:

dpkg-statoverride --update --add root root 0755 /usr/bin/lockmail.maildrop 
dpkg-statoverride --update --add root root 0755 /usr/bin/maildrop

It would be perhaps better to have reformail(1) as a separate package, see bug 1006903 for that discussion.

The real challenge is, of course, migrating those old .procmailrc recipes to Sieve (basically). I added a few examples in the appendix below. You might notice the Sieve examples are easier to read, which is a nice added bonus.

Conclusion There is really, absolutely, no reason to keep procmail in Debian, nor should it be used anywhere at this point. It's a great part of our computing history. May it be kept forever in our museums and historical archives, but not in Debian, and certainly not in actual release. It's just a bomb waiting to go off. It is irresponsible for distributions to keep shipping obsolete and insecure software like this for unsuspecting users. Note that I am grateful to the author, I really am: I used procmail for decades and it served me well. But now, it's time to move, not bring it back from the dead.

Appendix

Previous work It's really weird to have to write this blog post. Back in 2016, I rebuilt my mail setup at home and, to my horror, discovered that procmail had been abandoned for 15 years at that point, thanks to that LWN article from 2010. I would have thought that I was the only weirdo still running procmail after all those years and felt kind of embarrassed to only "now" switch to the more modern (and, honestly, awesome) Sieve language. But no. Since then, Debian shipped three major releases (stretch, buster, and bullseye), all with the same vulnerable procmail release. Then, in early 2022, I found that, at work, we actually had procmail installed everywhere, possibly because userdir-ldap was using it for lockfile until 2019. I sent a patch to fix that and scrambled to remove get rid of procmail everywhere. That took about a day. But many other sites are now in that situation, possibly not imagining they have this glaring security hole in their infrastructure.

Procmail to Sieve recipes I'll collect a few Sieve equivalents to procmail recipes here. If you have any additions, do contact me. All Sieve examples below assume you drop the file in ~/.dovecot.sieve.

deliver mail to "plus" extension folder Say you want to deliver user+foo@example.com to the folder foo. You might write something like this in procmail:

MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
LOGFILE=$HOME/.procmail.log
VERBOSE=off
EXTENSION=$1            # Need to rename it - ?? does not like $1 nor 1
:0
* EXTENSION ?? [a-zA-Z0-9]+
        .$EXTENSION/

That, in sieve language, would be:

require ["variables", "envelope", "fileinto", "subaddress"];
########################################################################
# wildcard +extension
# https://doc.dovecot.org/configuration_manual/sieve/examples/#plus-addressed-mail-filtering
if envelope :matches :detail "to" "*"  
  # Save name in $ name  in all lowercase
  set :lower "name" "$ 1 ";
  fileinto "$ name ";
  stop;
 

Subject into folder This would file all mails with a Subject: line having FreshPorts in it into the freshports folder, and mails from alternc.org mailing lists into the alternc folder:

:0
## mailing list freshports
* ^Subject.*FreshPorts.*
.freshports/
:0
## mailing list alternc
* ^List-Post.*mailto:.*@alternc.org.*
.alternc/

Equivalent Sieve:

if header :contains "subject" "FreshPorts"  
    fileinto "freshports";
  elsif header :contains "List-Id" "alternc.org"  
    fileinto "alternc";
 

Mail sent to root to a reports folder This double rule:

:0
* ^Subject: Cron
* ^From: .*root@
.rapports/

Would look something like this in Sieve:

if header :comparator "i;octet" :contains "Subject" "Cron"  
  if header :regex :comparator "i;octet"  "From" ".*root@"  
        fileinto "rapports";
   
 

Note that this is what the automated converted does (below). It's not very readable, but it works.

Bulk email I didn't have an equivalent of this in procmail, but that's something I did in Sieve:

if header :contains "Precedence" "bulk"  
    fileinto "bulk";
 

Any mailing list This is another rule I didn't have in procmail but I found handy and easy to do in Sieve:

if exists "List-Id"  
    fileinto "lists";
 

This or that I wouldn't remember how to do this in procmail either, but that's an easy one in Sieve:

if anyof (header :contains "from" "example.com",
           header :contains ["to", "cc"] "anarcat@example.com")  
    fileinto "example";
 

You can even pile up a bunch of options together to have one big rule with multiple patterns:

if anyof (exists "X-Cron-Env",
          header :contains ["subject"] ["security run output",
                                        "monthly run output",
                                        "daily run output",
                                        "weekly run output",
                                        "Debian Package Updates",
                                        "Debian package update",
                                        "daily mail stats",
                                        "Anacron job",
                                        "nagios",
                                        "changes report",
                                        "run output",
                                        "[Systraq]",
                                        "Undelivered mail",
                                        "Postfix SMTP server: errors from",
                                        "backupninja",
                                        "DenyHosts report",
                                        "Debian security status",
                                        "apt-listchanges"
                                        ],
           header :contains "Auto-Submitted" "auto-generated",
           envelope :contains "from" ["nagios@",
                                      "logcheck@",
                                      "root@"])
     
    fileinto "rapports";
 

Automated script There is a procmail2sieve.pl script floating around, and mentioned in the dovecot documentation. It didn't work very well for me: I could use it for small things, but I mostly wrote the sieve file from scratch.

Progressive migration Enrico Zini has progressively migrated his procmail setup to Sieve using a clever way: he hooked procmail inside sieve so that he could deliver to the Dovecot LDA and progressively migrate rules one by one, without having a "flag day". See this explanatory blog post for the details, which also shows how to configure Dovecot as an LMTP server with Postfix.

Other examples The Dovecot sieve examples are numerous and also quite useful. At the time of writing, they include virus scanning and spam filtering, vacation auto-replies, includes, archival, and flags.

Harmful considered harmful I am aware that the "considered harmful" title has a long and controversial history, being considered harmful in itself (by some people who are obviously not afraid of contradictions). I have nevertheless deliberately chosen that title, partly to make sure this article gets maximum visibility, but more specifically because I do not have doubts at this moment that procmail is, clearly, a bad idea at this moment in history.

Developing story I must also add that, incredibly, this story has changed while writing it. This article is derived from this bug I filed in Debian to, quite frankly, kick procmail out of Debian. But filing the bug had the interesting effect of pushing the upstream into action: as mentioned above, they have apparently made a new release and merged a bunch of patches in a new git repository. This doesn't change much of the above, at this moment. If anything significant comes out of this effort, I will try to update this article to reflect the situation. I am actually happy to retract the claims in this article if it turns out that procmail is a stellar example of defensive programming and survives fuzzing attacks. But at this moment, I'm pretty confident that will not happen, at least not in scope of the next Debian release cycle.

$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=hard

1. Math functions taking sNaN and not raising FE_INVALID and returning qNaN. Almost any operation on an sNaN value is supposed to signal an invalid operand and replace that with a qNaN so that further processing doesn't raise another exception. This was fairly easy to fix, just need to use return x + x; instead of return x;.
2. Math functions failing to set errno. I'd recently restructured the math library to get rid of the separate IEEE version of the functions which didn't set errno and missed a couple of cases that needed to use the errno-setting helper functions.
3. Corner cases in string/float conversion, including the need to perform round-to-even for '%a' conversions in printf and supporting negative decimal values for fcvt. This particular exercise led to replacing the ecvtbuf and fcvtbuf APIs with glibc's ecvt_r and fcvt_r versions as those pass explicit buffer lengths, making overflow prevention far more reliable.
4. A bunch of malloc entry points were not handling failure correctly; allocation values close to the maximum possible size caused numerous numeric wrapping errors with the usual consequences (allocations "succeed", but return a far smaller buffer than requested). Also, realloc was failing to check the return value from malloc before copying the old data, which really isn't a good idea.
5. Tinystdio's POSIX support code was returning an error instead of EOF at end of file.
6. Error bounds for the Picolibc math library aren't great; I had to generate Picolibc-specific ulps files. Most functions are between 0 and 3 ulps, but for some reason, the float version of erfc (ercf) has errors as large as 64 ulps. That needs investigation.

• [1] https://www.itpa.org.au/code-of-ethics/

• The western capitalistic system has finally reached end-of-life in 2019 after it almost collapsed already in 2008.
• The western oligarchs as organised in the World Economic Forum were well aware of this and planned a Great Reset of the system through a medical emergency. The goal is to create a new system where the old elite will remain in power.
• There has been no pandemic in 2020 but only a PCR-test that created cases . Age-normalized mortality in most countries was unspectacular in 2020.
• The so called Covid-19 vaccines are extremely dangerous in some batches with harmless batches in between to not raise suspicion: How Bad is My Batch.

• A new step in INN development has been achieved with the migration of the INN project to GitHub. We now make use of the features GitHub provides: issue tracker, pull requests, continuous integration, a user-friendly interface to browse the code, etc. Our Subversion repository has therefore been migrated to Git, and our Trac tickets to the GitHub issue tracker.
• An up-to-date nocem.ctl file is provided with this release. You should manually update your nocem.ctl file with the new information recorded about NoCeM issuers, and make sure the right PGP keys are present on your system.
• Up-to-date control.ctl and moderators files are provided with this release. You should manually update them (notably for the fido7.* hierarchy).
• Added a stricter validation of article numbers given in NNTP commands so that numbers superior to 2^31 are correctly considered invalid. Thanks to Richard Kettlewell for the patch.
• Added a check in rc.news for the existence of the pathrun directory. INN won't start until this directory is writable. Previously, it bailed out quickly after starting, without clear logs about why it failed.
• Fixed parallel builds using make -j. Thanks to Richard Kettlewell for the path.
• nnrpd now properly gathers timer statistics when a compression layer is active.
• nnrpd now properly discards data received from a news client after a timeout when a TLS layer is active. It previously tried to read incoming data before closing the socket, leading to decoding errors from an underlying compression or SASL layer.
• innfeed and ovdb_stat now generate status reports in valid HTML syntax.
• Fixed a bug in the buffindexed overview that prevented it from working on several systems, amongst them FreeBSD. Unsupported, and useless, permission bits were given to semaphores.
• Fixed the detection of library paths at configure time: multilib directories (lib32 or lib64) are now also used if they exist, even it the system does not use multilib. It will notably fix the detection of the OpenSSL 3.0.0 library.
• The tlscertfile parameter in inn.conf now permits the use of a complete certificate chain, instead of necessarily having to use tlscafile for additional certificates.
• Added support for the new OpenSSL 3.0.0 API, which deprecated a few functions.
• The inn.conf default value for tlsprotocols no longer contains TLS versions 1.0 and 1.1, which have been deprecated by RFC 8996.
• A new inn.conf parameter has been added to tune the length of the queue of pending connections to innd, nnrpd and the ovdb overview storage method: the maxlisten parameter now permits configuring their listen backlog, whose previously hard-coded values were 128 for nnrpd and 25 for the others, which was not high enough for some uses. The default value is now 128 for all of them, and configurable in inn.conf. Thanks to Kevin Bowling for the patch.
• The name of seven man pages for routines built in libinn(3) are now prefixed with libinn_ so as not to consume namespace and conflict with other packages (notably, the list(3) and uwildmat(3) man pages are now named libinn_list(3) and libinn_uwildmat(3)).
• Other minor bug fixes and documentation improvements, notably a revised installation checklist and a section summarizing the most used configuration at the beginning of a few complex man pages.

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

• In January we saw a new funded project proposed. The project is meant to bring in a number of changes to the Tryton modules and packages in Debian. Tryton, a full featured, entirely open source business software platform, is supported by its own foundation. You can track the current status of all our funded projects at its dedicated web page.
• Folks continue to add to the Grow Your Ideas project page, that s great.
• In January 2550 was put aside to fund Debian projects.

• Abhijith Pa worked 5 hours out of 5 available.
• Anton Gladky worked 12 hours out of 12 available.
• Ben Hutchings worked 16 hours out of 24 available and carried over 8 for February.
• Chris Lamb worked 18 hours out of 18 available.
• Emilio Pozuelo Monfort worked 55 hours out of 58.25 available and carried over 3.25 for February
• Jeremiah Foster worked 20 hours out of 20 available on LTS administration and 8.3 hours on funded projects.
• Lee Garrett didn t spend any hours in January and carries over 39.25 hours to February
• Markus Koschany worked 34 hours out of 40 available and carried over 6 for February.
• Ola Lundqvist reported via email that they didn t spend any hours in January and carries over 11 from December for a total of 12 hours for February.
• Roberto C. Sanchez worked 9 hours out of 32 available and carried over 23 for February
• Sylvain Beucler worked 22 hours out of 40 available and carried over 14 for February
• Thorsten Alteholz worked 40 hours out of 40 available.
• Utkarsh Gupta worked 58.25 hours out of 58.25 available.

• Platinum sponsors:
  • TOSHIBA (for 77 months)
  • GitHub (for 68 months)
  • Civil Infrastructure Platform (CIP) (for 45 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 88 months)
  • Linode (for 82 months)
  • Babiel GmbH (for 71 months)
  • Plat Home (for 71 months)
  • University of Oxford (for 27 months)
  • Deveryware (for 14 months)
  • VyOS Inc (for 9 months)
• Silver sponsors:
  • The Positive Internet Company (for 93 months)
  • Domeneshop AS (for 92 months)
  • Nantes M tropole (for 86 months)
  • Univention GmbH (for 78 months)
  • Universit Jean Monnet de St Etienne (for 78 months)
  • Ribbon Communications, Inc. (for 72 months)
  • Exonet B.V. (for 62 months)
  • Leibniz Rechenzentrum (for 56 months)
  • CINECA (for 45 months)
  • Minist re de l Europe et des Affaires trang res (for 39 months)
  • Cloudways Ltd (for 29 months)
  • Dinahosting SL (for 27 months)
  • Bauer Xcel Media Deutschland KG (for 21 months)
  • Platform.sh (for 21 months)
  • Moxa Intelligence Co., Ltd. (for 15 months)
  • sipgate GmbH (for 12 months)
  • OVH US LLC (for 10 months)
  • Tilburg University (for 10 months)
  • GSI Helmholtzzentrum f r Schwerionenforschung GmbH
  • Telecats BV
• Bronze sponsors:
  • Evolix (for 93 months)
  • Seznam.cz, a.s. (for 93 months)
  • Intevation GmbH (for 90 months)
  • Linuxhotel GmbH (for 90 months)
  • Daevel SARL (for 88 months)
  • Bitfolk LTD (for 87 months)
  • Megaspace Internet Services GmbH (for 87 months)
  • Greenbone Networks GmbH (for 86 months)
  • NUMLOG (for 86 months)
  • WinGo AG (for 86 months)
  • Ecole Centrale de Nantes LHEEA (for 82 months)
  • Entr ouvert (for 77 months)
  • Adfinis AG (for 74 months)
  • GNI MEDIA (for 69 months)
  • Laboratoire LEGI UMR 5519 / CNRS (for 69 months)
  • Tesorion (for 69 months)
  • Bearstech (for 60 months)
  • LiHAS (for 60 months)
  • People Doc (for 57 months)
  • Catalyst IT Ltd (for 55 months)
  • Supagro (for 50 months)
  • Demarcq SAS (for 49 months)
  • Universit Grenoble Alpes (for 35 months)
  • TouchWeb SAS (for 27 months)
  • SPiN AG (for 24 months)
  • CoreFiling (for 19 months)
  • Institut des sciences cognitives Marc Jeannerod (for 14 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 11 months)
  • Tem Innovations GmbH (for 6 months)
  • WordFinder.pro (for 5 months)
  • CNRS DT INSU R sif (for 4 months)

Changes in version 0.1.7 (2022-02-18)

• Two URLs were updated in 'README.md', and Travis artifacts and badges have been removed (Dirk).
• One unit test file was updated to not trigger a 'LENGTH_1' warning (Dirk closing #76).

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