It is possible to set your keyboard layout in the kernel command line:

Update changelog

Update to PostgreSQL 13.2

Update Element to 1.7.20

1.7.20 has just been released

Incorporate suggestions from @algent:

The manual upgrade process mentioned is different compared to other distros because we don't have different packages for different Postgres versions.
Shall I write some instructions for the Help Center?

Replace conflicts by replaces

In D10145#171375, @JoshStrobl wrote:

In D10145#169759, @silke wrote:

In D10145#169681, @Jacalz wrote:

I see, thanks for looking into the issue. Also, fyi, we probably can't deprecate fuse-exfat as it would mean that users of exfat on the LTS kernels have no support for that filesystem.

Yeah, that's an issue. Proposal:

• Deprecate exfat-utils now.
• Patch udisks for exfatprogs.
• Deprecate fuse-exfat when LTS has native exfat support.

Sounds more sensible. Though isn't that going to break the FAT partitioning on udisks for LTS users? Suppose at some point we have to draw a line.

@chax any updates on updating arm-none-eabi-gcc?

In D10145#169681, @Jacalz wrote:

I see, thanks for looking into the issue. Also, fyi, we probably can't deprecate fuse-exfat as it would mean that users of exfat on the LTS kernels have no support for that filesystem.

In D10145#169595, @JoshStrobl wrote:

In D10145#169594, @Jacalz wrote:

I don't think we can deprecate exfat-utils just yet. This one is not yet supported by Gnome disks (you can't partition using exfat).

I'm not seeing any indication in the source code that they need exfat-utils directly. In fact, if anything this issue provides clear indication that no changes are actually needed.

I have traced the issue with clr-boot-manager back to this commit. I have tested and submitted a PR upstream that fixes this issue.

@algent: I tested this patch with a Yubikey (ykman info) and found no issues.

Add patch to remove various docs

I think one problem that occurs here is that clr-boot-manager silently refuses to mount over a /boot with content:

@Jacalz I was playing around with this a bit, and the userspace utilities don't really seem to depend on the kernel support (although we *definitely* want that as well). Can you try testing the linked differential? Additionally: if you would like to maintain this as well, please comment with the appropriate content and I'll update MAINTAINERS.md!

I'm willing to maintain this, as I use this quite regularly. See the linked revision for an update to the latest version.

Remove unnecessary newlines

In D10065#165097, @JoshStrobl wrote:

Short enough changelog for 0.72.0 that it can be summarized.

Use pkgconfig(hidapi-libusb) instead of hidapi-devel

Works for me when manually reloading with echo 1 | sudo tee -a /sys/devices/system/cpu/microcode/reload (this requires no reboot):

@Jacalz I haven't posted a differential, as I'm waiting on a go-ahead from @JoshStrobl. It is on his to-do list afaik, so we'll just have to be patient :)

P.S. Please don't use 80 columns in the summaries or elsewhere. I updated the summary, guessing it forced wrapping after you added the link.

I have a working fwupd integrated with clr-boot-manager based on my previous comment. The changes are fairly minimal:

Add patch to disable building static library and examples

• Remove static library
• Move man(3) pages to devel

@livingsilver94: I don't think there's a more recent tag that actually builds (see monodevelop #8006). Note that the 8.x releases are described as 'Visual Studio for Mac'. There is a fork in the works (dotdevelop, but I don't think that has any working builds.

@chax I would still like to know what the reasons for blocking this upgrade are. It would be useful if you could create a task for tracking the blocking issues.

Almost two years later, and it looks like fdupes is alive again. Still a useful utility to have imho.

@chax it would probably be useful to create issues tracking blocking issues, so it's visible that and why updates are being blocked.

If all that needed, is to mount the /boot partition before running fwupd, maybe we could consider integrating this with eopkg for the time being, and then sol later on.