Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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 freswa (frederik) - Wednesday, 06 May 2020, 13:51 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


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):


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

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

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

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

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

Returns an EMPTY line!

If I modify {print $ 9} to {print $ 8} it returns:

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/

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.

- Gufw window

This task depends upon

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/ | 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/

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/

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/

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

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

which is equal to `ls -ld /usr/lib/python*/site-packages/gufw/ | 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:


Fix the incorrect source code layout gufw.gufw.* and the gufw/ 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/ 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/ | awk '{print $9}'` # from source
LOCATIONS=( "${LOCATIONS[@]}" "/usr/share/gufw/gufw/" ) # deb package

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

And what is this .deb package which isn't using the 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


Note /usr/sbin is symlinked to /usr/bin because of
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