Ubuntu Linux (22.04, and 23.10) and Racket documentation?

This, obviously is not a Racket problem, but maybe somebody has seen this before, and can offer a fix.

Yesterday, and today, I installed several Linux distros on my computer, just to see if my math-quiz package works everywhere. So they are all freshly installed distros, without any modifications, and the first thing I did was to install Racket (directly off of Racket download site), and install it in Unix style (that I always do).
Next I opened DrRacket window, and with Package Manager installed math-quiz.
When math-quiz was started, first I opened the documentation /scribblings/math-quiz.html file. Results are as follows:

My previously installed Mint (Cinnamon) - works OK
Newly installed Fedora (Gnome) - works OK
Newly installed Manjaro (Plasma) - works OK
Newly installed Ubuntu 23.10 - does not work! - 23-10 Trashed after that.
Newly installed Ubuntu 22.04 - does not work! But it's worse than just math-quiz!
On Ubuntu 22,04 I also tried to access Racket help desk. Also does not work!
The errors displayed by Firefox are following:

The file at /var/tmp/plt-sendurl-contents-file-16993613621699361362870.html is not readable.
It may have been removed, moved, or file permissions may be preventing access.

This is Racket help desk, and below is for math-quiz:

The file at /home/hrvoje064/.local/share/racket/8.10/pkgs/math-quiz/scribblings/math-quiz.html is not readable.
It may have been removed, moved, or file permissions may be preventing access.

I did not check Racket help desk file, but I run some tests on math-quiz file:
The file can be opened with any ordinary editor (in place), but Firefox (I also tried Opera) will not open the file, even if directly clicking on it in the scribblings folder.
Further to this I tested (following the path in error message all the way up to my home folder), and Firefox will not open any files that are in a path starting with .local

Is there a way to fix this? Or I just forget about Ubuntu?

Ubuntu 22.04 changed its default firefox package to come from a Snap instead of a traditional Debian package. Snaps apply some sandboxing to applications by default, which is probably what is interfering with opening these files in Firefox.

Changes like this are among the reasons I moved my systems from Kubuntu to Debian Bookworm, so I am probably not the best source for a solution, but there are a few possible directions to explore:

  1. I'm nearly certain there is a mechanism you can use to configure the sandboxing applied to the Firefox Snap. I don't know what that mechanism is for Snaps: with Flatpak, which has similar issues in this respect, you can use an application like Flatseal; CLI commands including flatpak override and flatpak permission-set; or a Plasma 5.27 system settings page.
  2. If there were a different way of doing things that would work better out-of-the-box with Snap- and/or Flatpak-based browsers, Racket could consider adopting it in the future, if it wouldn't be disruptive in the cases that already work well. At least we could document what permissions you need to set somewhere.
  3. Distribution packagers of Racket (including those who maintain the Snap and Flatpak packages of Racket) might be in a position to apply some integration settings in their packaging. Hypothetically, I could imagine a package of Racket that applied the needed sandbox settings when it was installed and removed them if it was uninstalled—but I could also imagine the complexity of this quickly getting unreasonable.
1 Like

Thank you for pointing me in the right direction, namely that the problem is the snap packaging system.
Anyway, I have found one solution to this particular problem on Ubuntu:
I installed apt based firefox:

sudo add-apt-repository ppa:mozillateam/ppa

sudo apt update

echo '
Package: firefox*
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001
' | sudo tee /etc/apt/preferences.d/Mozilla

sudo apt install firefox

echo 'Unattended-Upgrade::Allowed-Origins:: "LP-PPA-mozillateam:${distro_codename}";' | sudo tee /etc/apt/apt.conf.d/51unattended-upgrades-firefox

This all from: https://www.makeuseof.com/ways-install-firefox-on-ubuntu/

However this is not enough, after restarting, I had to type this:

sudo snap disable firefox

Finally after this, firefox started working normally. Both Racket Help Desk and math-quiz scribble docs can be opened.

However, this is just too much BS for me, so I'll trash Ubuntu, and install Debian (which I did use many years ago), before Ubuntu existed.

Seeing https://github.com/racket/racket/pull/4817 reminded me of another possibility:

  1. You can control how Racket tries to open files in a browser by setting the 'external-browser Racket preference, which could be a way to experiment and find something that works.

It also reminded me of the fact that the default is to use xdg-open, and it seems quite that xdg-open ought to arrange to actually open file it's told to open. Or, to put it another way, I think the right place to apply integration settings would be in the way the firefox package configures xdg-open when firefox is the user's preferred browser package. This might be worth a bug report to the Ubuntu maintainers of xdg-open and/or firefox, especially if we could reproduce it using the racket package from Ubuntu.

1 Like

You can control how Racket tries to open files in a browser by setting the 'external-browser Racket preference, which could be a way to experiment and find something that works.

Except this will not work in Ubuntu, unless you do for each new browser, what I did with Firefox. I did try (before I got your first answer here) with 3 other browsers, which I of-course downloaded via Ubuntu GUI software installer, and all refused to load any files in directory path that starts with . , as in /home/.local/share/racket/...
Therefore setting 'external-browser in a program would not help.

Hmm. This seems discouraging.

I'm overdue to upgrade from Ubuntu 18.04 LTS. I haven't upgraded because (a) lazy/busy but also (b) what Ubuntu is doing with snaps, and against alternatives like flatpak.

Then I'd read about the idea of using Debian Bookworm as a stable core system -- plus snap/flatpak/whatever to get super new versions of apps like Firefox and LibreOffice.

(IIUC Firefox ESR from distros is older than Firefox from say flatpak. The ESR has security fixes, but maybe I want other new features. Ditto for LibreOffice; maybe I want latest for best MS interop.)

So that seemed great, and was going to be my plan.

But now it sounds like this might not work so well?

p.s. I really like the option of sandboxing, but I want full control, not the snap/flatpak/whatever creator.

The snap version of Racket has this limitation; can't access dot directories. It's frustrating for me when people try to use it with Racket Mode (which by default gets its .rkt files installed under ~/.emacs.d/elpa/, meaning snap racket not allowed to access).

Although maybe this is a reasonable default limitation for the snap, AFAIK an end user isn't allowed to override this, not even in some "sudo" fashion, which seems weird.

This is roughly what I have done. I have been extremely happy with Debian Bookworm.

As far as newer apps:

  1. Bookworm is actually more recent than Ubuntu 22.04 LTS. I had not realized at first that they have basically been sustaining an every-other-year cadence for releases, which is much more frequent than had been by preconception. (I had previously used Debian c. 2004.) I am surprised at how few things I have wanted to update separately.
  2. For Firefox specifically:
    • I am currently using Firefox ESR, which as you say has security fixes but is slower to get new features.
    • When I was still on Kubuntu, I had been using Firefox via Flatpak, and it was not bad: there were a few annoying run-ins with the sandbox, but they were relatively rare, and overriding defaults is easy. For example, checking the box for "All User Files" and/or "All System Files" would avoid the issues in this thread:
    • I've installed Firefox Developer Edition by just clicking the download button on Firefox Developer Edition, unpacking the tarball, and adding a .desktop file to point to it. It keeps itself up-to-date the same way Firefox does on Mac and Windows.
  3. For applications generally:
    • There is an official Debian Backports repository that covers a lot of software, including LibreOffice. A particular advantage is that they take care to ensure a smooth upgrade path to the next Debian release.
    • I've also found Flatpak a good option more broadly. (I've used many more applications that way than are listed in the screenshot above.) There are valid critiques of Flatpak in some respects, but it is pragmatically useful, and it doesn't have the problems that make me uncomfortable with Snaps. (The most egregious one, IMO, is that the Snap server is not free software, so Snap is only usable with Canonical's repository.)
    • I also have a number of applications installed via Guix. To be fair, Guix definitely has a significant learning curve. Among other interesting features, I have found its support for declarative home environment configuration useful in keeping things organized and consistent across multiple machines: sort of the next step from keeping my dotfiles under version control. The temporary shells also make it easy to not install things I only want to run occasionally or in specific contexts. Guix does not itself apply any sandboxing for built applications (if you build software, it does do that in an isolated environment), though it has features for creating sandboxes when you want to. It is also definitely the most customizable option, especially for lovers of parentheses.
    • The option I miss most from Ubuntu is the abundance of PPAs. Some third-party repositories are generic enough to "just work", though: I get Signal this way. I've also followed the instructions from CreatePackageFromPPA - Debian Wiki and SimpleBackportCreation - Debian Wiki to package a few things myself, but I'd like to find a more automated way to do this, especially for keeping things updated.
1 Like

Thanks for all the great information and advice!!

  • The newness of Bookworm, as well as its more pragmatic approach to drivers, got my interest.

  • Firefox ESR might be plenty new-enough for me, for awhile. Also why didn't I think of the dev edition. Nice.

  • Those flatpak permission controls look lovely, and a lot more than snap offers (IIUC), so that's encouraging.


In a sense, my ideal system would be ChromeOS with (what used to be called) Crouton. Just without Chrome or Google. :slight_smile:

I want a laptop with a core of just-works wifi, suspend, great battery life, etc. I want that core to change as little as possible. On top of that I want to install whatever from wherever. Fedora Silverblue sounds in that ballpark? But Bookworm + flatpak might be close enough, was my thinking. Your post encourages me to try that plan after all.


Guix... well. It reminds me of paredit. I tried to learn and stick with paredit, but gave up, twice over the years. Finally it stuck on the third try. Technomancy had a great tweet ~= "If paredit isn't for you, you need to become the kind of person paredit is for."

I feel like I really ought to become the kind of person guix is for... someday.

Seriously temp shells is something I might like as a cleaner way to try things on various permutations of versions of Racket and Emacs. Maybe that's the carrot I'll use to become a better person, someday.

I installed Epiphany on my Ubuntu system and set the preference and it works for me.