The Problem

Currently, rakudo doesn't have tail call optimization or proper tail calls. It seems tail call optimization is the last puzzle piece that will make raku a proper functional programming language.

Closing for now.

Discussed in https://github.com/netblue30/firejail/discussions/4975

Originally posted by wonbug February 24, 2022 I'm trying to open a PDF file with mupdf in ~/Desktop/

I put all these directives into ~/.config/firejail/mupdf.local:

whitelist ${HOME}/Desktop/
whitelist ${HOME}/Desktop
whitelist ~/Desktop/
whitelist ~/Desktop 

Yet when I try to open the file, I get:

$ /usr/bin/firejail /usr/bin/mupdf ~/Desktop/file.pdf
...
error: cannot open /home/user/Desktop/file.pdf: Permission denied
mupdf: error: cannot open document 

Am I missing something obvious?

Is this really fixed?

If my bookmark manager tries to open multiple bookmarks by launching multiple invocations of firejail --join-or-start=librewolf librewolf URL simultaneously, the first invocation creates librewolf sandbox and some of subsequent invocations end up creating librewolf-PID sandboxes.

If multiple firejail invocations are trying to launch simultaneously with --join-or-start=program, the first invocation should reserve a named sandbox which subsequent invocations wait for before joining the named sandbox.

Because not all invocations of librewolf join the same sandbox, I had to insert

ignore private-tmp
ignore dbus-user 

into librewolf.local in order to launch multiple bookmarks simultaneously on librewolf.

If --join-or-start was good at putting all simultaneous invocations of firejail in one named sandbox, I didn't need to make all librewolf instances share /tmp and dbus with programs outside sandbox.

I installed 0.9.70 and rebooted. I tested librewolf with join-or-start librewolf in librewolf.local.

The issue was reproduced reliably. I still need to ignore private-tmp and dbus-user.

If my bookmark manager tries to open multiple bookmarks by launching multiple invocations of firejail --join-or-start=librewolf librewolf URL simultaneously, the first invocation creates librewolf sandbox and some of subsequent invocations end up creating librewolf-PID sandboxes.

If multiple firejail invocations are trying to launch simultaneously with --join-or-start=program, the first invocation should reserve a named sandbox which subsequent invocations wait for before joining the named sandbox.

Because not all invocations of librewolf join the same sandbox, I had to insert

ignore private-tmp
ignore dbus-user 

into librewolf.local in order to launch multiple bookmarks simultaneously on librewolf.

If --join-or-start was good at putting all simultaneous invocations of firejail in one named sandbox, I didn't need to make all librewolf instances share /tmp and dbus with programs outside sandbox.

I just tested 0.9.70 with join-or-start librewolf in librewolf.local.

The issue is perfectibly reproducible on 0.9.70.

I still need to ignore private-tmp and dbus-user.

If my bookmark manager tries to open multiple bookmarks by launching multiple invocations of firejail --join-or-start=librewolf librewolf URL simultaneously, the first invocation creates librewolf sandbox and some of subsequent invocations end up creating librewolf-PID sandboxes.

If multiple firejail invocations are trying to launch simultaneously with --join-or-start=program, the first invocation should reserve a named sandbox which subsequent invocations wait for before joining the named sandbox.

Because not all invocations of librewolf join the same sandbox, I had to insert

ignore private-tmp
ignore dbus-user 

into librewolf.local in order to launch multiple bookmarks simultaneously on librewolf.

If --join-or-start was good at putting all simultaneous invocations of firejail in one named sandbox, I didn't need to make all librewolf instances share /tmp and dbus with programs outside sandbox.

I will test.

Problem

Some system daemons are started as a non-root user with /dev/null as HOME.

Firejail has difficulties when HOME is /dev/null because include *.local fails when HOME is /dev/null.

Solution

Firejail should be fine with /dev/null as HOME.

Alternatives

I haven't tried AppArmor. Can AppArmor do things that firejail can do? I think AppArmor can be great for system daemons and programs that launch other programs.

System daemons often don't have $HOME. I was trying to sandbox system daemons with firejail.

I thought DoH resolvers without IP addresses were going to use bootstrap resolvers, but they didn't.

I had to manually add IP addresses to resolver stamps by using https://dnscrypt.info/stamps/

I tested again, and the issue seems fixed. I don't understand.

https://janet-lang.org/docs/jpm.html doesn't reflect what's possible now in project.janet.

For example, :tag.

I'm in the process of retiring this github account. Create a new issue if you want.

https://janet-lang.org/docs/jpm.html doesn't reflect what's possible now in project.janet.

For example, :tag.

Closing this for now.

I don't have jpm repository cache. I can't use jpm make-lockfile.

I want to manually write it.

I don't think lockfile is a substitute for proper versioning.

Eliminate packages.

I thought DoH resolvers without IP addresses were going to use bootstrap resolvers, but they didn't.

I had to manually add IP addresses to resolver stamps by using https://dnscrypt.info/stamps/

Are you sure this is completed? mullvad DoH servers still don't have IP addresses.

Delete rakudo infrastructure.

Please add BTC support.

Closing it since I don't use gnucash anymore.

Describe the bug

I'm on b65e22c5a223f1ad7935ecf0a68f16496ba1d1e6

I don't know how to reproduce the issue, yet.

When the issue occurs, if I activate input method, it is deactivated and activated infinitely. I can't type anything.

To Reproduce

Desktop (please complete the following information):

• Desktop: Sway
• Display server type: Wayland

Additional context

The fix for my last issue probably caused this issue.

I will open another issue if I can reproduce it reliably.

Describe the bug

I'm on b65e22c5a223f1ad7935ecf0a68f16496ba1d1e6

I don't know how to reproduce the issue, yet.

When the issue occurs, if I activate input method, it is deactivated and activated infinitely. I can't type anything.

To Reproduce

Desktop (please complete the following information):

• Desktop: Sway
• Display server type: Wayland

Additional context

The fix for my last issue probably caused this issue.

Somehow, I think this issue is probably a sway issue or a qutebrowser issue.

Perhaps, the window focus moves between windows due to a sway bug.

Closing this issue for now.

Describe the bug

I'm on b65e22c5a223f1ad7935ecf0a68f16496ba1d1e6

I don't know how to reproduce the issue, yet.

When the issue occurs, if I activate input method, it is deactivated and activated infinitely. I can't type anything.

To Reproduce

Desktop (please complete the following information):

• Desktop: Sway
• Display server type: Wayland

Additional context

The fix for my last issue probably caused this issue.

I press ctrl+shift+space to toggle input method.

Describe the bug

If I'm on a pure wayland application, moving to an xwayland window results in lots of keypresses. t or any other key is pressed by fcitx5 a lot automatically until I press a key on my keyboard.

Gtk or Qt applications that run on wayland don't cause this issue. Pure wayland applications do.

To Reproduce

• Activate fcitx5 by opening a Qt or Gtk application.
• Open an xwayland window such as
  • env WINIT_UNIX_BACKEND=x11 alacritty
  • st terminal emulator.
• Open a pure wayland window such as
  • alacritty
  • foot terminal emulator
  • env SDL_VIDEODRIVER=wayland dosbox-x
• Move focus back to the previously opened xwayland window by clicking it or with a keyboard shortcut.
• Stop automatic keypresses from fcitx5 by pressing t or any key. Press Ctrl+u to clear the command line.
• Focus on the pure wayland window. Move focus back to the xwayland window again.

Expected behavior

fcitx5 doesn't press t repetitively.

Desktop (please complete the following information):

• Desktop: Sway wayland compositor
• Display server type: wayland
• fcitx5-diagnose.txt

I just tested the git master, and the issue seems to have been fixed. Great Work.

add url to project.janet

Merge pull request #1 from uvtc/patch-1

add url to project.janet

add url to project.janet

Do you use this project?

add url to project.janet

Merge pull request #1 from uvtc/patch-1

add url to project.janet

add url to project.janet

Describe the bug

If I'm on a pure wayland application, moving to an xwayland window results in lots of keypresses. t or any other key is pressed by fcitx5 a lot automatically until I press a key on my keyboard.

Gtk or Qt applications that run on wayland don't cause this issue. Pure wayland applications do.

To Reproduce

• Activate fcitx5 by opening a Qt or Gtk application.
• Open an xwayland window such as
  • env WINIT_UNIX_BACKEND=x11 alacritty
  • st terminal emulator.
• Open a pure wayland window such as
  • alacritty
  • foot terminal emulator
  • env SDL_VIDEODRIVER=wayland dosbox-x
• Move focus back to the previously opened xwayland window by clicking it or with a keyboard shortcut.
• Stop automatic keypresses from fcitx5 by pressing t or any key. Press Ctrl+u to clear the command line.
• Focus on the pure wayland window. Move focus back to the xwayland window again.

Expected behavior

fcitx5 doesn't press t repetitively.

Desktop (please complete the following information):

• Desktop: Sway wayland compositor
• Display server type: wayland
• fcitx5-diagnose.txt

I finally found a way to reproduce the issue reliably with this minimal sway config.

# vim: filetype=i3
set $mod Mod4

exec fcitx5 -dr

bindsym $mod+Return exec /usr/bin/st
bindsym $mod+Shift+Return exec /usr/bin/foot
bindsym $mod+d exec bemenu-run

# move focus
bindsym $mod+h focus left
bindsym $mod+j focus down
bindsym $mod+k focus up
bindsym $mod+l focus right 

1. Press $mod+Shift+Return to launch foot
2. Press exi
3. Press t and Enter "very quickly".
4. Press $mod+Shift+Return to launch foot again
5. Press $mod+Return to launch st