Trouble running Hawck on openSUSE

[lgbaldoni]

I'm finalising the package and after a clean reinstallation I've noticed that hawck-user-setup hangs. I don't understand why it checks not to be run as root only to try and run usermod which is usually in sbin.

Second and far less important question, why is the .desktop file not being installed into applications?

[snyball]

The gui has been deprecated for a while, and is pending removal so the desktop file is no longer installed.

It needs to know your $HOME directory and $(whoami) and must therefore be executed with the desktop user account. I've been meaning to just do it on first time running hawck-macrod which would eliminate that extra step but haven't gotten around to it.

As to why it hangs, it might be the pkexec, or the notify-send, but you could insert some echos to pin it down.

[lgbaldoni]

Ok, I believe this patch does the trick for me. Do you think it would be compatble with arch and everything else?

Also I plan on having Hawck included in the next openSUSE Leap release, which tests do you recommend I run before submitting a final package?

[lgbaldoni]

Sorry, the second part of the patch is incredibly silly:/

[snyball]

@lgbaldoni ~~usermod isn't placed in sbin on all distros,~~ we could do this:

USERMOD="$(command -v usermod)"
if ! command -v usermod; then
    ## For openSUSE
    USERMOD=/usr/sbin/usermod
fi

if ! [ -f "$USERMOD" ]; then
    echo "Unable to find usermod binary"
    exit 1
fi

if ! pkexec "$USERMOD" -aG hawck-input-share "$(whoami)"; then
     notify-send --icon=hawck \
             --app-name="Hawck" \
             "Unable to authenticate, is a polkit authentication agent running?"
     echo "Do you have a PolicyKit Authentication agent running?"
     ## TODO: Write document detailing how to run the polkit daemon, depending on distro
     echo "See: https://github.com/snyball/path/to/document"
fi

You could also override $PATH but I think it's OK to just special-case usermod in this case.

Also, it is currently using pkexec because of the original plan to have it executed non-interactively from hawck-macrod, (where sudo won't work because we don't have a terminal.) But I've procrastinated on that simple change because people sometimes neither have a working polkit nor notification daemon running and would then be in the dark about why it doesn't work.

The script should probably just be rewritten to use sudo + echo when run with no arguments, and pkexec + notify-send when executed with a non-interactive command-line argument (which will be given when hawck-macrod runs it.)

For now, I think it should look like this:

USERMOD="$(command -v usermod)"
if ! command -v usermod; then
    ## For openSUSE
    USERMOD=/usr/sbin/usermod
fi

if ! [ -f "$USERMOD" ]; then
    echo "Unable to find usermod binary"
    exit 1
fi

sudo "$USERMOD" -aG hawck-input-share "$(whoami)"

[snyball]

@lgbaldoni As far as tests go, Hawck unfortunately doesn't have a good full-system automated testing method. But you could try running the examples from the README to see if they work with the openSUSE package.

[snyball]

@lgbaldoni Hold up, is usermod placed in sbin on all distros? I had assumed it wasn't but, it seems to be in both /usr/bin and /usr/sbin on Arch. So your original patch is fine actually.

[lgbaldoni]

Debian, Fedora and Ubuntu all have usermod in /usr/sbin.

polkit daemons are a different story, I fear. On my system (openSUSE Leap 15.2) I see

/usr/lib64/libexec/polkit-kde-authentication-agent-1
/usr/lib/polkit-gnome-authentication-agent-1
/usr/lib/polkit-1/polkitd
/usr/lib/polkit-1/polkit-agent-helper-1

On openSUSE Tumbleweed I see

/usr/lib64/libexec/polkit-kde-authentication-agent-1:
/usr/libexec/polkit-1/polkit-agent-helper-1:
/usr/libexec/polkit-1/polkitd:

On Debian stable:

/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/policykit-1/polkitd
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
/usr/lib/x86_64-linux-gnu/libexec/polkit-kde-authentication-agent-1

On Fedora stable:

/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib/polkit-1/polkitd
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
/usr/lib/x86_64-linux-gnu/libexec/polkit-kde-authentication-agent-1

So, I don't think nudging the daemon directly is going to be a viable option :smirk:

I admit I know very little about the matter, but wouldn't sudo systemctl restart polkit be a universal option? EDIT: no, it would not if sudo is not installed.

[snyball]

@lgbaldoni A hardcoded /usr/sbin path won't work for nix/guix though, and I'm planning on packaging Hawck for guix.

So it should try finding it in $PATH first and then falling back to the /usr/sbin/usermod path.

As for the polkit stuff, we can drop it for now and use sudo instead. Then I'll rewrite the script to also take a noninteractive option later to have it executed from hawck-macrod. We can assume that sudo is in $PATH.

[lgbaldoni]

The trouble with command -v is that it also returns aliases. How about USERMOD="$(which usermod 2>/dev/null)" instead ?

[snyball]

I don't think the file contains any bashisms, so we could also just make it run with #!/bin/sh (the which command is ubiquitus but not standardized.) Then we don't have to worry about any aliases.

[snyball]

I think I'll just settle with this one to end the bikeshedding:

if ! groups | tr " " "\n" | grep "^hawck-input-share\$"; then
    SBIN_USERMOD=/usr/sbin/usermod
    USERMOD=usermod
    if ! command -v "$USERMOD" ; then
       if [ -f "$SBIN_USERMOD" ]; then
           USERMOD="$SBIN_USERMOD"
       else
           echo "Unable to locate usermod."
           exit 1
       fi
    fi
    sudo "$USERMOD" -aG hawck-input-share "$(whoami)"
fi

[snyball]

Resolved as of dce518ee4d92f9beca4b022730e0f2024d2cecb5

[lgbaldoni]

Still not done. bin/hawck-git/hawck-git.install contains groupadd hawck-input-share, but hawck-*.service want to run the daemons with the hawck-input group. So, which one is it?

[snyball]

@lgbaldoni The daemon runs as the hawck-input user, both the desktop user and the hawck-input user are members of the hawck-input-share group for UNIX socket communication.

TLDR: It runs as the hawck-input user and group.

[lgbaldoni]

Let me see if I understand correctly:

the user hawck-input must belong to the hawck-input, hawck-input-share and uinput groups, whereas the desktop user only to hawck-input-share, correct? If so, this is not reflected in hawck-git.install.

[snyball]

@lgbaldoni Pretty much but also input.

Can you post a diff showing what you expect post_install should do?

[lgbaldoni]

Can you post a diff showing what you expect post_install should do?

I believe this would suffice:

--- hawck-git.install.orig      2021-01-30 19:28:45.123413647 +0100
+++ hawck-git.install   2021-01-30 19:29:12.081030872 +0100
@@ -2,6 +2,8 @@ post_install() {
     useradd hawck-input
     usermod -aG input hawck-input
     usermod --home "/var/lib/hawck-input" hawck-input
+    groupadd hawck-input
+    usermod -aG hawck-input hawck-input
     groupadd hawck-input-share
     usermod -aG hawck-input-share hawck-input
     groupadd uinput

I also pass -K UID_MIN=501 -K UID_MAX=999 to useradd to avoid seeing the service user in the login list in sddm (also -K GID_MIN=501 -K GID_MAX=999 to groupadd, for further finesse).

I'm having two problems now:

~> hawck-add .local/share/hawck/scripts/example.hwk 
lua5.3: ./LLib/Keymap.lua:312: No such key: h
stack traceback:
        [C]: in function 'error'
        ./LLib/Keymap.lua:312: in function 'Keymap.getKeysym'
        (...tail calls...)
        ./LLib/Hawck.lua:69: in function 'key'
        /home/user/.local/share/hawck/scripts/example.lua:10: in local 'fn'
        ./LLib/match.lua:71: in field 'new'
        /home/user/.local/share/hawck/scripts/example.lua:8: in main chunk
        [C]: in ?

And at some point after launching hawck.inputd via systemctl:

Error in realpath() unable to find absolute path to: /dev/input/by-id

Via libnotify and on every console on the system.

[snyball]

@lgbaldoni If you give me some instructions on how to try the package out in an openSUSE VM then I can track it down more easily.

[lgbaldoni]

The most up-to-date one is in my home project on OBS. From here you can either add said repository or download the rpm and install it by hand.

For clarity, I've been using the rolling release (Tumbleweed) to test Hawck.

[snyball]

Ok, I might have some time to take a look at it tomorrow, then I'll post my findings here.

[snyball]

@lgbaldoni Also, the repo-name is Hawck but the package name should probably be hawck, unless upper-case naming is standard for openSUSE of course (honestly I regret the capital-letter naming of the repo but it's too late to change it now because it would break links.)

It's a really small issue, so if it's difficult to change then don't worry about it.

[lgbaldoni]

I wondered about that and upstream has usually the last word on it. When I created it I had my doubts and chose the github name :slightly_frowning_face:

I'm glad you told me, there's still time to change it.

[lgbaldoni]

Hi, any news?

[snyball]

@lgbaldoni Didn't have time to look at it last week, but it looks like I'll be able to take a look at it over the next few days.

[lgbaldoni]

Any news? I might have to remove it from the openSUSE repository if not working.

[snyball]

@lgbaldoni Sorry about the slow pace, I've been more busy than I expected this month but this is on my todo-list as soon as I have time. Thank you for the patience so far and the work on packaging, I'll let you know when I've tracked down the problem.

[lgbaldoni]

@snyball Of course, paid work, study and family always come first. Right now the deadline for Leap 15.3 has passed, so there is no hurry (I was probably being overly optimistic).

In any case, users willl be able to install Hawck from the OBS equivalent of a PPA.

[Corey-Keller]

I am also having the same issue as @lgbaldoni (also on OpenSUSE Tumbleweed, using the latest git release)

When I run hawck-add ~/.config/hawck/scripts/example.hwk whose contents is just the Testing it out example from the readme (C-a - > the character 'b')

lua5.3: ./LLib/Keymap.lua:312: No such key: a
stack traceback:
        [C]: in function 'error'
        ./LLib/Keymap.lua:312: in function 'Keymap.getKeysym'
        (...tail calls...)
        ./LLib/Hawck.lua:69: in function 'key'
        /home/me/.local/share/hawck/scripts/example.lua:2: in main chunk
        [C]: in ?

[lgbaldoni]

No apparent change as of today (version 20220204.625d840)

~> hawck-add ~/.config/hawck/scripts/example.hwk
lua5.3: ./LLib/Keymap.lua:312: No such key: h
stack traceback:
        [C]: in function 'error'
        ./LLib/Keymap.lua:312: in function 'Keymap.getKeysym'
        (...tail calls...)
        ./LLib/Hawck.lua:69: in function 'key'
        /home/user/.local/share/hawck/scripts/example.lua:10: in local 'fn'
        ./LLib/match.lua:71: in field 'new'
        /home/user/.local/share/hawck/scripts/example.lua:8: in main chunk
        [C]: in ?

[cw9000]

What I found is that /usr/share/kbd/keymaps/xkb/us.map.gz uses Unicode codes to specify the letters. keycode 35 = +U+0068 +U+0048 +U+0068 +U+0048 BackSpace BackSpace BackSpace BackSpace Meta_h Meta_H ...

a snippet from /usr/share/hawck/LLib/Keymap.lua around line 195 shows:

local alt_code, alt_name = line:match(".*keycode *([0-9]+) *= *([a-zA-Z0-9+]+)") <<-- here we see the regex
                                           
      -- We only care about the plain ones for now.
      if modifiers[1] == "plain" then
        code, name, rest = alt_code, alt_name, ""
      end
    end


    if code and name and name ~= "nul" then
      -- Some keys are formatted as '+A' where A is a literal character,
      -- we just remove this plus.
      local is_letter = false

      if name:sub(1, 1) == "+" then         <<-- here we see the + being taken off
       is_letter = true
        name = name:sub(2)
      end

so the table has the key "U+0068" as opposed to "h" While I am fine just replacing keys with their unicode counter parts, maybe not everyone would

The problem appears to be that the map being used when selecting lang=us is /usr/share/kbd/keymaps/xkb/us.map.gz but it might be better to use: /usr/share/kbd/keymaps/i386/qwerty/us.map.gz we can see this file includes "qwerty-layout" looking at /usr/share/kbd/keymaps/i386/include/qwerty-layout.inc we can see keycode 35 = h

going back to /usr/share/hawck/LLib/Keymap.lua around line 266:

  local p = io.popen(("find %s -name '*map.gz'"):format(u.shescape(kbmap_path)))
  local keymap_rx = ".*/([a-z0-9]+)/([a-z0-9]+)/([a-z0-9-]+)%.k?map%.gz"     <-- regex for map files
  local keymaps = {}
  for line in p:lines() do
    local machine, layout, lang = line:match(keymap_rx)
    if machine then
      keymaps[lang] = line
    end
  end
  p:close()
  return keymaps
end

on one's own machine you might try replacing that first grouping for the regex with (i386) as opposed to ([a-z0-9]+) the rest of the regex can stay. Again, this is just to get it to work on opensuse (15.4 right now). This isn't for production.