FS#66556 - [gufw] Gufw won't start

Attached to Project: Community Packages
Opened by Arek (Domker_) - Wednesday, 06 May 2020, 00:10 GMT
Last edited by Levente Polyak (anthraxx) - Thursday, 14 January 2021, 23:20 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

After the Gufw upgrade (to 20.04.1-1), it can't be started.
I probably found the cause of the problem.


This is the PREVIOUS bash script to run Gufw v19.10.0-2 (/usr/bin/gufw-pkexec):

#!/bin/bash
LOCATIONS=(
"/usr/lib/python3.8/site-packages/gufw/gufw.py"
"/usr/lib/python3.8/dist-packages/gufw/gufw.py"
"/usr/share/gufw/gufw/gufw.py"
)

for ((i = 0; i < ${#LOCATIONS[@]}; i++))
do
if [[ -e "${LOCATIONS[${i}]}" ]]; then
python3 ${LOCATIONS[${i}]} $1
fi
done



This is the CURRENT Gufw v20.04.1-1 launch script:

#!/bin/bash
LOCATIONS=`ls -ld /usr/lib/python*/site-packages/gufw/gufw.py | awk '{print $9}'` # from source
LOCATIONS=( "${LOCATIONS[@]}" "/usr/share/gufw/gufw/gufw.py" ) # deb package

for ((i = 0; i < ${#LOCATIONS[@]}; i++))
do
if [[ -e "${LOCATIONS[${i}]}" ]]; then
python3 ${LOCATIONS[${i}]} $1
fi
done



When I run manually:
ls -ld /usr/lib/python*/site-packages/gufw/gufw.py | awk '{print $9}'

Returns an EMPTY line!

If I modify {print $ 9} to {print $ 8} it returns:
/usr/lib/python3.8/site-packages/gufw/gufw.py

After modifying the script in this way, Gufw runs without problems.

Without "awk", it returns:
-rw-r--r-- 1 root root 1079 04-29 10:12 /usr/lib/python3.8/site-packages/gufw/gufw.py


Python3 doesn't get the correct path to the script, so there is no error information when trying to run Gufw.

Additional info:
* gufw 20.04.1-1

Operating System: Arch Linux
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.69.0
Qt Version: 5.14.2
Kernel Version: 5.6.10-arch1-1
OS Type: 64-bit


Steps to reproduce:
1) Type in console: gufw
2) Polkit window shows up, type password
3) Nothing happens, and no errors.

Expected:
- Gufw window

This task depends upon

Closed by  Levente Polyak (anthraxx)
Thursday, 14 January 2021, 23:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  21.04.0-1
Comment by Arek (Domker_) - Wednesday, 06 May 2020, 00:37 GMT
Using "awk" like this is bad practice:
ls -ld /usr/lib/python*/site-packages/gufw/gufw.py | awk '{print $9}'

Output without "awk" if You have English system language:
-rw-r--r-- 1 root root 1079 April 29 10:12 /usr/lib/python3.8/site-packages/gufw/gufw.py

9nt argument is the path.

Output without "awk" if You have e.g. Polish system language:
-rw-r--r-- 1 root root 1079 04-29 10:12 /usr/lib/python3.8/site-packages/gufw/gufw.py

9nt argument - nothing, because the date is in a different format: "April 29" vs "04-29" (there are no spaces and "awk" counts incorrectly)

Comment by SpacingBat3 (SpacingBat3) - Monday, 29 June 2020, 20:32 GMT
Possible fix would be use:
ls /usr/lib/python*/site-packages/gufw/gufw.py

instead of:
ls -ld /usr/lib/python*/site-packages/gufw/gufw.py | awk '{print $9}'

The output of `ls /usr/lib/python*/site-packages/gufw/gufw.py` is (for example with python 3.8 installed):
/usr/lib/python3.8/site-packages/gufw/gufw.py

which is equal to `ls -ld /usr/lib/python*/site-packages/gufw/gufw.py | awk '{print $9}'` output when `LC_ALL=C` variable is set

In conclusion, I don't know why the script uses `ls` with `-ld` parameter (at least with -l).
Also, using ls with -d parameter will work.
Comment by Eli Schwartz (eschwartz) - Sunday, 13 September 2020, 04:25 GMT
Upstream's launch script is pretty terrible due to this "ls" use among others. Can you open a bug report upstream recommending:

preferred:

Fix the incorrect source code layout gufw.gufw.* and the gufw/gufw.py script clash by making all code importable as gufw.*
Add a main() entry point and import it in the bin/ script, or alternatively move gufw/gufw.py into bin/gufw-pkexec

not preferred:

at least use echo instead of ls -ld, and thereby drop the pipe to awk.
Comment by Eli Schwartz (eschwartz) - Sunday, 13 September 2020, 04:27 GMT
LOCATIONS=`ls -ld /usr/lib/python*/site-packages/gufw/gufw.py | awk '{print $9}'` # from source
LOCATIONS=( "${LOCATIONS[@]}" "/usr/share/gufw/gufw/gufw.py" ) # deb package


The first line isn't even an array, lol.

And what is this .deb package which isn't using the setup.py to install, it should be fixed instead of using terrible hacks.
Comment by Chigozirim Chukwu (FirstAirBender) - Thursday, 05 November 2020, 19:55 GMT
The problem is in the file: /usr/share/polkit-1/actions/com.ubuntu.pkexec.gufw.policy

The key `org.freedesktop.policykit.exec.path` was set to `/usr/bin/gufw-pkexec`.
However, the program is actually installed in `/usr/sbin/gufw-pkexec`.

I corrected this, and now the program works as expected

EDIT:

Note /usr/sbin is symlinked to /usr/bin because of https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/.
However, my `~/.xsessionrc` was appending /sbin/ and /usr/sbin to the PATH. This is why it initially looked like gufw-pkexec was installed in `/usr/sbin/gufw-pkexec`

The new solution is to comment out ~/.xsessionrc and undo what I had intially done in /usr/share/polkit-1/actions/com.ubuntu.pkexec.gufw.policy.

Now the program is running as expected

Loading...