I recently upgraded to a 7900 XTX on Debian stable, as well. I’m running the newest kernel from Debian’s backports repo (6.6, I think), and I didn’t have that same problem.

I did have other problems with OpenCL, though. I made a thread about this and solved it with some trouble. Check my post history if you’re interested. I hope it helps. I can take a closer look at my now-working system for comparison if you have further issues.

IT WORKS NOW! I will need time to run additional tests, but the gist of my solution was:

1. Backport llvm-18 from sid following the guide you linked at https://wiki.debian.org/SimpleBackportCreation

2. After compiling and installing all those deb files, I then installed the “jammy” version of amdgpu-install_6.0.60002-1.deb from https://www.amd.com/en/support/linux-drivers

3. Downloaded the latest kernel sources from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, and simply copied all the files from its lib/firmware/amdgpu folder into my system’s /lib/firmware/amdgpu. Got that idea from https://discussion.fedoraproject.org/t/amdgpu-doesnt-seem-to-function-with-navi-31-rx-7900-xtx/72647

4. sudo update-initramfs -u && sudo reboot

I’m not totally sure it step 3 was sane or necessary. Perhaps the missing piece before that was that I needed to manually update my initramfs? I’ve tried like a million things at this point and my system is dirty, so I will probably roll back to my snapshot from before all of this and attempt to re-do it with the minimal steps, when I have time.

Anyway, I was able to run a real-world OpenCL benchmark, and it’s crazy-fast compared to my old GTX 1080. Actually a bigger difference than I expected. Like 6x.

THANKS FOR THE HELP!

Thanks for the links! I’ve never attempted making my own backport before. I’ll give it a shot. I might also try re-upgrading to sid to see if I can wrangle it a little differently. Maybe I don’t actually need mesa-opencl-ics if I’m installing AMD’s installer afterwards anyway. At least, I found something to that effect in a different but similar discussion.

Update: I upgraded to Sid. Unfortunately, mesa-opencl-icd depends on libclc-17, which uninstalls -18. So I can’t get OpenCL working while the correct libclc is installed.

No idea where to go from here. I’ll probably restore my Bookworm snapshot, since I don’t want to be on Sid if it doesn’t solve this problem.

Update: Running amdgpu-install did not provide those files. There were a few errors regarding vulkan packages when I attempted, I guess because it’s assuming Ubuntu repos. Trying with just opencl and not vulkan succeded, but still clinfo reported the missing files.

I don’t think I can get this working without a whole newer llvm.

Ah, somehow I didn’t see 18 there and only looked at 17. Thanks!

I tried pulling just the one package from the sid repo, but that created a cascade of dependencies, including all of llvm. I was able to get those files installed but not able to get clinfo to succeed. I also tried installing llvm-19 from the repo at https://apt.llvm.org/, with similar results. clinfo didn’t throw the fatal errors anymore, but it didn’t work, either. It still reported Number of devices 0 and OpenCL-based tools crashed anyway. Not with the same error, but with something generic about not finding a device or possibly having corrupt drivers.

Should I bite the bullet and do a full ugprade to sid, or is there some way to this more precisely that won’t muck up Bookworm?

Can you explain more about your workflow? Do the Nix packages have their own isolated dependency resolution? How does it work when Debian packages depend on a library you get from Nix, or vice-versa?

Thanks, that’s good advice. There are lower-numbered gfx* files in there. 900, 902, 904, 906. No 1030 or 1100. Same after reinstalling.

Looks like these files are actually provided by the libclc-15 package. libclc-16 has the same set of files. Even libclc-17 from sid has the same files. So I guess upgrading to testing/unstable wouldn’t help.

apt-file search gfx1100-amdgcn-mesa-mesa3d.bc yields no results, so I guess I need to go outside of the Debian repos. I’ll try the AMD package tonight.

Oh yes, definitely. I think this is why Mozilla has not made this the default behavior in Firefox; there will always be the risk of false-positives breaking copied links, so it’s important that people know that there’s some kind of mutation happening.

ClearURLs uses a JSON file with site-specific regex patterns and rules. In theory I could customize this for myself, or better yet submit a pull request on their GitHub. If I have time I’ll look into it.

Personally, I have found this feature to be too limited. I still use the ClearURLs extension, which is more effective in my experience.

However, neither one is a silver bullet. Here’s an example I just took from Amazon (I blocked out some values with X’s):

Original URL:
https://www.amazon.com/Hydro-Flask-Around-Tumbler-Trillium/dp/B0C353845H/ref=XXXX?qid=XXXXXXXXXX&refinements=p_XXXXXXXXXXXXX&rps=1&s=sporting-goods&sr=XXX

Using Firefox’s “copy link without site tracking” feature:
https://www.amazon.com/Hydro-Flask-Around-Tumbler-Trillium/dp/B0C353845H/ref=XXXX?qid=XXXXXXXXXX&refinements=p_XXXXXXXXXXXXX&rps=1&s=sporting-goods

Using ClearURLs:
https://www.amazon.com/Hydro-Flask-Around-Tumbler-Trillium/dp/B0C353845H?refinements=p_XXXXXXXXXXXXX&rps=1

The ideal, canonical URL, which no tools I’m familiar with will reliably generate:
https://www.amazon.com/dp/B0C353845H

Longer but still fully de-personalized URL:
https://www.amazon.com/Hydro-Flask-Around-Tumbler-Trillium/dp/B0C353845H

If anybody knows a better solution that works with a wide variety of sites, please share!

This is correct, albeit not universal.

KDE has a predefined schedule for “release candidates”, which includes RC2 later this month. So “RC1” is clearly not going to be the final version. See: https://community.kde.org/Schedules/February_2024_MegaRelease

This is at least somewhat common. In fact, it’s the same way the Linux kernel development cycle works. They have 7 release candidates, released on a weekly basis between the beta period and final release. See: https://www.kernel.org/category/releases.html

In the world of proprietary corporate software, I more often see release candidates presented as potentially final; i.e. literal candidates for release. The idea of scheduling multiple RCs in advance doesn’t make sense in that context, since each one is intended to be the last (with fingers crossed).

It’s kind of splitting hairs, honestly, and I suspect this distinction has more to do with the transparency of open-source projects than anything else. Apple, for example, may indeed have a schedule for multiple macOS RCs right from the start and simply choose not to share that information. They present every “release candidate” as being potentially the final version (and indeed, the final version will be the same build as the final RC), but in practice there’s always more than one. Also, Apple is hardly an ideal example to follow, since they’ve apparently never even heard of semantic version numbering. Major compatibility-breaking changes are often introduced in minor point releases. It’s infuriating. But I digress.

A non-smartphone, that is, a cell phone like the ones that today’s parents had when we were young and with which we made calls and sent text messages, was enough for us, and it did not cause addiction.

That’s not the way I remember it. Texting addiction was a thing. That’s how Twitter became popular; it was basically a way to broadcast SMS to friends at first.

I guess it’s a matter of degrees.

Ad-based services are the real problem here, I think. You don’t hear people complaining about Wikipedia addiction.

All the time. Not always by choice!

A lot of my work involves writing scripts for systems I do not control, using as light a touch as is realistically possible. I know for a fact Python is NOT installed on many of my targets, and it doesn’t make sense to push out a whole Python environment of my own for something as trivial as string manipulation.

awk is super powerful, but IMHO not powerful enough to justify its complexity, relative to other languages. If you have the freedom to use Python, then I suggest using that for anything advanced. Python skills will serve you better in a wider variety of use cases.

Thank you for saving me the trouble of investigating this as an option.

No reason to tolerate proprietary licenses when there are so many viable FLOSS solutions out there.

Sadly, there’s no official LineageOS for the OnePlus 10 or 11 series. I remember back with the 7 series it was officially supported on launch, and OnePlus sent units to open source developers. I don’t think OnePlus cares that much about the development community anymore.

https://wiki.lineageos.org/devices/#oneplus

Can’t be arsed.

It means you don’t care to put in the effort required.

https://dictionary.cambridge.org/dictionary/english/arsed

These are not “normal” tablets, but Boox’s line of ePaper-based readers are the only Android tablets that distinguish themselves sufficiently in my already-large family of devices. I’ve used “normal” tablets with full-color LCD/OLED displays, on both the Android and iPadOS side, but I rarely find a good use for them. I’ve found them to sit in an awkward space with neither the convenience of my phone, nor the utility of my laptop.

The ePaper-based tablets are ideal for reading, but I do not relegate them merely to the “e-reader” category because they allow you to install Google Play and run basically any Android app. This makes them more flexible and powerful than most e-readers.

It comes with a built-in browser optimized for monochrome, and you can also install third-party alternatives like EinkBro.

That said, it’s only for advanced users, and it’s not a perfectly smooth experience. Just getting Google Play running on it requires jumping through some hoops, and you will find that most Android apps simply don’t work well on a monochrome display (though Boox does offer color models, I have not used them myself).

I was hoping, for example, to use my Boox tablet to play Go, but despite the fact that Go is very much a “black and white” game, most of the apps use shading and colors that look like absolute ass on a black and white display. Some of them do not properly support the 4:3 aspect ratio either. So I don’t want to set unreasonable expectations here. These are niche devices.

Despite these drawbacks, I really appreciate having an ePaper device. It complements my device family (phone, laptop, etc.) in a way other tablets do not.

I used to run Tumbleweed with KDE on my Nvidia system. I found the rolling release structure of Tumbleweed to cause extra work for me, because kernel updates came frequently and occasionally broke the Nvidia drivers. As a workaround, I ended up pinning my kernel to an old version.

Nvidia drivers have been at least a little troublesome on every distro I’ve used, particularly with the additional CUDA libraries.

One nice thing about Suse is that it uses BTRFS by default, and you can use snapper to revert your whole system if something goes wrong. So if Nvidia shits the the bed after an update, it’s easy to roll back. Most distros default to ext4 and do not have snapshot support by default, which feels like living in the stone age to me after using Suse and BTRFS.

Of course you CAN set up BTRFS and snapshots in any distro, but that’s a lot to ask for a beginner with Linux. I strongly recommend choosing a distro that does that for you, like Suse.

Thanks! Do you know if there’s a way to set it to use fixed high-contrast colors? Mine changes based on web page content and is almost always lower contrast than I’d like.

The github page has more context than the F-Droid listing.

API Key

This application uses the AudD® service as a Music Recognition API. You need a special API token provided by AudD® to use the application. If you don’t have one, you can sign up for a free API token. You can add the key on the onboarding or preferences screen, or just set it in local.properties.

There is also the option to use the app without a token, but please note that this will restrict the number of daily recognitions that can be performed.

The AudD web site says:

Music recognition API for both content analysis and in-app music recognition costs from $2 to $5 per 1000 requests. First 300 requests for free.