close
  • Pl chevron_right

    Making Debian available

    pubsub.slavino.sk / planetdebian · Tuesday, 26 January, 2021 - 15:41 · 1 minute

This is the subject of an interesting thread on the debian-devel mailing list.

It started with ".. The current policy of hiding other versions of Debian is limiting the adoption of your OS by people like me.."

It seems that this user managed to contact us developers and give us some important information how we can improve the user experience. The following discussion shows that all our users need non-free firmware to get their wireless network cards run.

Do we provide such installation images for our users?

Sure. We build them regularly, host them on our servers, we also sign the hash sum with our official signing key. But we hide them very well and still call them unofficial. Why? I would like to have a more positive name for those images. Ubuntu has the HWE (Hardware Enablement) kernel. Maybe Debian firmware enablement images?

We should better promote the images that fits best for our users.

BTW, the URL for all these useful images is https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/

Since I'm not using the Debian installer or live image often, I thought my own installation tool would already do better. In FAI , I install the package firmware-linux-nonfree if I need some nonfree firmware. But it appears that this package does not depend on any WiFi firmware package. Oops. So, I've filed a bug report #980758 and propose to add another meta package that depends on a list of firmware packages for WiFi cards.

I've now added a workaround to the FAIme service . You can now generate fully automated customized installation images including nonfree firmware for the stable and testing release. The stable release images can also use a newer kernel and firmware from backports. All other package are still from stable. Another useful image variant in my opinion.

Debian FAIme


Značky: #Debian

  • Pl chevron_right

    Review: The City We Became

    pubsub.slavino.sk / planetdebian · Tuesday, 26 January, 2021 - 04:11 · 5 minutes

Review: The City We Became , by N.K. Jemisin

Series: The Great Cities Trilogy #1
Publisher: Orbit
Copyright: March 2020
ISBN: 0-316-50985-X
Format: Kindle
Pages: 449

At an unpredictable point after a city has accumulated enough history, character, and sense of itself, it is born as a living creature. It selects an avatar who both embodies the city and helps it be born. But in that moment of birth, a city is at its most vulnerable, and that is when the Enemy attacks.

The birth of cities and the Enemy attacks have happened for millennia, so the cities that have survived the process have developed a system. The most recently born goes to assist the avatar with the birthing process and help fight off Enemy attacks. But the process has become riskier and the last two cities have failed to be born, snuffed out in natural disasters despite that support.

Now, it's New York City's turn. It selects its avatar and survives the initial assault with the help of São Paulo. But something still goes wrong, and it is severely injured in the process. Complicating matters, now there are five more avatars, one for each borough, who will have to unite to fight off the Enemy. And, for the first time, the Enemy has taken human form and is attacking with reason and manipulation and intelligence, not just force.

The City We Became has a great premise: take the unique sense of place that defines a city and turn it into a literalized character in a fantasy novel. The avatars are people who retain their own lives and understanding (with one exception that I'll get to in a moment), but gain an awareness of the city they represent. They can fight and repair their city through sympathetic magic and metaphor made real. The prelude that introduces this concept (adapted from Jemisin's earlier short story "The City Born Great" ) got too gonzo for me, but once Jemisin settles into the main story and introduces avatars with a bit more distance from the city they represent, the premise clicked.

The execution, on the other hand, I thought was strained. The biggest problem is that the premise requires an ensemble cast of five borough avatars, the primary avatar, São Paulo, and the Enemy. That's already a lot, but for the story to work each avatar has to be firmly grounded in their own unique experience of New York, which adds family members, colleagues, and roommates. That's too much to stuff into one novel, which means characters get short shrift. For example, Padmini, the avatar of Queens, gets a great introductory scene and a beautiful bit of characterization that made her one of my favorite characters, but then all but disappears for the remainder of the book. She's in the scenes, but not in a way that matters. Brooklyn and Aislyn get moments of deep characterization, but there's so much else going on that they felt rushed. And what ever happened to Manny's roommate?

The bulk of the characterization in this book goes to Broncha, the Bronx avatar, a Lenape woman and a tough-as-nails administrator of a community art museum and maker space. The dynamics between her and her co-workers, her mentorship of Veneza, and her early encounters with the Woman in White are my favorite parts of the book. I thought she and Brooklyn were a useful contrast: two very different ways of finding a base of power in the city without letting go of one's ideals.

But before we get to Broncha, we first meet Manny, the Manhattan avatar. Thematically, I thought what Jemisin did here was extremely clever. Manny's past is essentially erased at the start of the book, making him the reader insert character to start making sense of this world. This parallels the typical tourist experience of arriving in Manhattan and trying to use it to make sense of New York. He's disconnected from the rest of the city because he's the dangerous newcomer with power but not a lot of understanding, which works with my model of the political dynamics of Manhattan.

Unfortunately, he's not an interesting person . I appreciated what was happening at the metaphorical layer, but Manny veers between action hero and exposition prompt, and his amnesia meant I never got enough sense of him as a character to care that much about what happened to him. I thought his confrontation with the Woman in White near the start of the book, which establishes the major villain of the book, felt clunky and forced compared to her later encounters with the other characters.

The Woman in White, though, is a great villain. It's clear from earlier on that the Enemy is Lovecraftian, but the Woman in White mixes mad scientist glee, manic enthusiasm, and a child-like amusement at the weirdness of humanity into the more typical tropes of tentacles, corruption, and horrific creatures. One of my qualms about reading this book is that I'm not a horror fan and don't enjoy the mental images of unspeakable monsters, but the Woman in White puts such a fascinating spin on them that I enjoyed the scenes in which she appeared. I think the book was at its best when she was trying to psychologically manipulate the characters or attack them with corrupted but pre-existing power structures. I was less interested when it turned into an action-movie fight against animated monsters.

The other place Jemisin caught me by surprise is too much of a spoiler to describe in detail (and skip the next paragraph in its entirety if you want to avoid all spoilers):

Jemisin didn't take the moral conflict of the book in the direction I was expecting. This book is more interested in supporting the people who are already acting ethically than in redeeming people who make bad choices. That produces a deus ex machina ending that's a bit abrupt, but I appreciated the ethical stance.

Overall, I thought the premise was great but the execution was unsteady and a bit overstuffed. There are some great characters and some great scenes, but to me they felt disjointed and occasionally rushed. You also need to enjoy characters taking deep pride in the feel of a specific place and advocating for it with the vigor of a sports rivalry, along with loving descriptions of metaphors turned into magical waves of force. But, if you can roll with that, there are moments of real awe. Jemisin captured for me the joy that comes from a deeply grounded sense of connection to a place.

Recommended, albeit with caveats, if you're in the mood for reading about people who love the city they live in.

This is the first book of a planned trilogy and doesn't resolve the main conflict, but it reaches a satisfying conclusion. The title of the next book has not yet been announced at the time of this review.

Rating: 7 out of 10


Značky: #Debian

  • Pl chevron_right

    nspawn-runner: support for image selection

    pubsub.slavino.sk / planetdebian · Monday, 25 January, 2021 - 15:49

.gitlab-ci.yml supports 'image' to allow selecting in which environment the script gets run. The documentation says "Used to specify a Docker image to use for the job", but it's clearly a bug in the documentation, because we can do it with nspawn-runner, too.

It turns out that most of the environment variables available to CI runs are also available to custom runner scripts. In this case, the value passed as image can be found as $CUSTOM_ENV_CI_JOB_IMAGE in the custom runner scripts environment.

After some experimentation I made this commit that makes every chroot under /var/lib/nspawn-runner available as an image:

# Set up 3 new images for CI jobs:
nspawn-runner chroot-create buster
nspawn-runner chroot-create bullseye
nspawn-runner chroot-create sid

That's it, CI scripts can now use image: buster , image: bullseye or image: sid , as they please. You can manually set up other chroots under /var/lib/nspawn-runner and they'll be automatically available.

You can also now choose a default image in config.toml in case the CI script doesn't specify one:

prepare_args = ["--verbose", "prepare", "--default-image=buster"]

Značky: #Debian

  • Pl chevron_right

    Help needed: clean up and submit KMS driver for Geode LX to LKML

    pubsub.slavino.sk / planetdebian · Monday, 25 January, 2021 - 14:33 · 1 minute

Ever since X.org switched to rootless operation, the days of the Geode X.org driver have been numbered. The old codebase dates back from Geode's early days at Cyrix, was then updated by NSC to add support for their new GX2 architecture, from which AMD dropped GX1 support and added support for their new LX architecture. To put it mildly, that codebase is a serious mess.

However, at least the LX code comes with plenty of niceties, such as being able to detect when it runs on an OLPC XO-1 and to probe DCC pins to determine the optimal display resolution on other hardware. This still doesn't make the codebase cruft-free.

Anyhow, most Linux distributions have dropped support for anything older than i686 with PAE, which essentially means that the GX2 code is just for show. Debian is one of very few distributions whose x86-32 port still ships with i686 without PAE. In fact, the lowest common denominator kernel on i386 is configured for Geode (LX).

A while back, someone had started working on a KMS driver for the Geode LX. Through word of mouth, I got my hands on a copy of their Git tree. The driver worked reasonably well, but the codebase needs some polishing before it could be included in the Linux kernel tree.

Hence this call for help:

Is there anyone with good experience of the LKML coding standards who would be willing to clean up the driver's code and submit the patch to the LKML?


Značky: #Debian

  • Pl chevron_right

    Review: Laziness Does Not Exist

    pubsub.slavino.sk / planetdebian · Monday, 25 January, 2021 - 05:00 · 3 minutes

Review: Laziness Does Not Exist , by Devon Price

Publisher: Atria Books
Copyright: January 2021
ISBN: 1-9821-4013-5
Format: Kindle
Pages: 216

The premise of Laziness Does Not Exist is in the title: Laziness as a moral failing does not exist. It is a misunderstanding of other problems with physical or psychological causes, a belief system that is used to extract unsustainable amounts of labor, an excuse to withdraw our empathy, and a justification for not solving social problems. Price refers to this as the Laziness Lie, which they define with three main tenets:

  1. Your worth is your productivity.
  2. You cannot trust your own feelings and limits.
  3. There is always more you could be doing.

This book (an expansion of a Medium article ) makes the case against all three tenets using the author's own burnout-caused health problems as the starting argument. They then apply that analysis to work, achievements, information overload, relationships, and social pressure. In each case, Price's argument is to prioritize comfort and relaxation, listen to your body and your limits, and learn who you are rather than who the Laziness Lie is trying to push you to be.

The reader reaction to a book like this will depend on where the reader is in thinking about the problem. That makes reviewing a challenge, since it's hard to simulate a reader with a different perspective. For myself, I found the content unobjectionable, but largely repetitive of other things I've read. The section on relationships in particular will be very familiar to Captain Awkward readers, just not as pointed. Similarly, the chapter on information overload is ground already covered by Digital Minimalism , among other books. That doesn't make this a bad book, but it's more of a survey, so if you're already well-read on this topic you may not get much out of it.

The core assertion is aggressive in part to get the reader to argue with it and thus pay attention, but I still came away convinced that laziness is not a useful word. The symptoms that cause us to call ourselves lazy — procrastination, burnout, depression, or executive function problems, for example — are better understood without the weight of moral reproach that laziness carries. I do think there is another meaning of laziness that Price doesn't cover, since they are aiming this book exclusively at people who are feeling guilty about possibly being lazy, and we need some term for people who use their social power to get other people to do all their work for them. But given how much the concept of laziness is used to attack and belittle the hard-working or exhausted, I'm happy to replace "laziness" with "exploitation" when talking about that behavior.

This is a profoundly kind and gentle book. Price's goal is to help people be less hard on themselves and to take opportunities to relax without guilt. But that also means that it stays in the frame of psychological analysis and self-help, and only rarely strays into political or economic commentary. That means it's more useful for taking apart internalized social programming, but less useful for thinking about the broader political motives of those who try to convince us to working endlessly and treat all problems as personal responsibilities rather than political failures. For that, I think Anne Helen Peterson's Can't Even is the more effective book. Price also doesn't delve much into history, and I now want to read a book on the origin of a work ethic as a defining moral trait.

One truly lovely thing about this book is that it's quietly comfortable with human variety of gender and sexuality in a way that's never belabored but that's obvious from the examples that Price uses. Laziness Does Not Exist felt more inclusive in that way, and to some extent on economic class, than Can't Even .

I was in the mood for a book that takes apart the political, social, and economic motivations behind convincing people that they have to constantly strive to not be lazy, so the survey nature of this book and its focus on self-help made it not the book for me. It also felt a bit repetitive despite its slim length, and the chapter structure didn't click for me. But it's not a bad book, and I suspect it will be the book that someone else needs to read.

Rating: 6 out of 10


Značky: #Debian

  • Pl chevron_right

    Raspbian/Raspberry PI OS with initrd

    pubsub.slavino.sk / planetdebian · Monday, 25 January, 2021 - 01:33 · 2 minutes

Background

While Raspbian, ahem, Raspberry PI OS is mostly Debian, the biggest difference is the kernel, both in terms of code and packaging.

The packaging is weird since it needs to deal with the fact that there’s no bootloader per se, the firmware parses /boot/config.txt and depending on the setting of 64bit and/or kernel line, it loads a specific file. Normally, one of kernel7.img , kernel7l.img or kernel8.img . While this configuration file supports an initrd, it doesn’t have a clean way to associate an initrd with a kernel, but rather you have to (like for the actual kernel) settle on a hard-coded initrd name.

Due to this, the normal way of using an initrd doesn’t work, and one has to do two things:

  • enable building initrd’s at all
  • settle on the naming for the initrd
  • ensure the initrd is updated correctly

There are quite a few of forum threads about this, but there’s no official support for this. The best link I found was this Stack Exchange post , which goes most of the way, but fails at the third point above.

My trivial solution

Instead of naming tricks the above post suggests, I settled on having a fixed name. It risks boot failure when the kernel architecture will change, which could be worked around with hard-coded kernel too, but I haven’t done that yet.

First, enable initrd creation/update in /etc/default/raspberrypi-kernel , like the post says. Uncomment INITRD=yes , but not the RPI_INITRD . This will enable creating/updating the initrd when the kernel package is installed and/or other packages trigger it via hooks.

Second, naming: choose an initrd name. I have simply this in my config.txt :

initramfs initrd.img followkernel

So the value is fully hard-coded, and the actual work is done in the next part.

Last, add an initramfs -hook in (e.g.) /etc/initramfs/post-update.d/rpi-initrd . Note that, by default (unless other packages have created it), the /etc/initramfs directory doesn’t exist. It’s not the confusingly-named /etc/initramfs-tools/ directory, which is related to building the initrd, but rather to doing things with the (already built) initrd. This directory is briefly explain in the Debian kernel-handbook guide .

This is my contents:

#!/bin/bashABI="$1"INITRD="$2"BOOTDIR="$(dirname"$INITRD")"# Note: the match below _must_ be synced with the boot kernelif [["$ABI"== *-v8+ ]]; thenecho"Building v8l+ image, updating top initrd"cp -p "$INITRD""$BOOTDIR/initrd.img"fi

This script seems to me much simpler, so in principle less chance of bugs, than all the renaming and editing config.txt I saw in that stack exchange post. As far as I know, all one needs to care about is to sync the ABI passed to this hook with the kernel one is running, and since there is only one kernel version installed at a time on Raspbian (as there’s no versioning in the kernel names), this should work correctly.

With this hook, the update also works correctly when packages trigger initrd updates, not only when new kernels are installed.

Note that the cp there is needed since the book partition is FAT, so no symbolic links/hard links allowed.

Happy initrd’ing!


Značky: #Debian

  • Pl chevron_right

    Miscellaneous news links

    pubsub.slavino.sk / planetdebian · Sunday, 24 January, 2021 - 23:00

Some curious news.

Here's a scam that targets terrorists: The Doomsday Scam .

On the general topic of scams, a List of confidence tricks .

Then two news involving bread:

And a last one about how people needed to rename human genes to work around Excel bugs features:


Značky: #Debian

  • Pl chevron_right

    prrd 0.0.4: More tweaks

    pubsub.slavino.sk / planetdebian · Saturday, 23 January, 2021 - 22:31 · 1 minute

prrd facilitates the parallel running [of] reverse dependency [checks] when preparing R packages. It is used extensively for Rcpp , RcppArmadillo , RcppEigen , BH , and possibly others.

prrd screenshot image

The key idea of prrd is simple, and described in some more detail on its webpage and its GitHub repo . Reverse dependency checks are an important part of package development that is easily done in a (serial) loop. But these checks are also generally embarassingly parallel as there is no or little interdependency between them (besides maybe shared build depedencies). See the (dated) screenshot (running six parallel workers, arranged in split byobu session).

This release brings several smaller tweaks and improvements to the summary report that had accumulated in my use since the last realease last April. We also updated the CI runners as one does these days.

The release is summarised in the NEWS entry:

Changes in prrd version 0.0.4 (2021-01-23)

  • Report summary mode is now compact, more robust and reports extended CRAN summaries. (Dirk via several changes)

  • Continuous Integration now uses run.sh from r-ci

My CRANberries provides the usual summary of changes to the previous version . See the aforementioned webpage and its repo for details. For more 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.


Značky: #Debian