FS#79267 - [urh] GUI needs python-setuptools to run

Attached to Project: Arch Linux
Opened by Marcell Meszaros (MarsSeed) - Tuesday, 01 August 2023, 17:52 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:19 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Filipe Laíns (FFY00)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: /usr/bin/urh (GUI application) needs python-setuptools during runtime to run.

Installing python-setuptools resolves this and the GUI app can be executed.


Additional info:
* package version(s): [extra]/urh 2.9.4-3


Steps to reproduce:
1) install urh
2) ensure that python-setuptools is not installed (as currently it is not declared in depends)
3) run 'urh' from terminal:

$ urh
Traceback (most recent call last):
File "/usr/bin/urh", line 33, in <module>
sys.exit(load_entry_point('urh==2.9.4', 'console_scripts', 'urh')())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/urh/main.py", line 100, in main
from urh.controller.MainController import MainController
File "/usr/lib/python3.11/site-packages/urh/controller/MainController.py", line 15, in <module>
from urh.controller.dialogs.OptionsDialog import OptionsDialog
File "/usr/lib/python3.11/site-packages/urh/controller/dialogs/OptionsDialog.py", line 16, in <module>
from urh.dev.native import ExtensionHelper
File "/usr/lib/python3.11/site-packages/urh/dev/native/ExtensionHelper.py", line 10, in <module>
from setuptools import Extension
ModuleNotFoundError: No module named 'setuptools'
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:19 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/urh/issues/1
Comment by Marcell Meszaros (MarsSeed) - Tuesday, 01 August 2023, 23:53 GMT
Severity:

* High - The main functionality of the application does not work, less critical security issues, etc.
* Medium - A non-essential functionality does not work, UNIX standards not respected, etc.

Running the /usr/bin/urh GUI is a main functionality of the application. So why did you downgrade the severity from High to Medium, @Toolybird?

If you cannot run the application at all, it's not just a non-essential functionality.
Comment by Toolybird (Toolybird) - Wednesday, 02 August 2023, 01:45 GMT
Please do *NOT* question the judgement of staff who are donating copious amounts of their time for free! I refer you to [1]. Severity is largely meaningless anyway. It should thankfully go away when we move to GitLab issues. The severity is not high IMNSHO when you can solve it in 1 second with a `pacman -S ...'. I have literally looked at *thousands* of issues. If you don't like the job I'm doing, you know what to do. Sheesh!

[1] https://terms.archlinux.org/docs/code-of-conduct/#respect-the-staff
Comment by Marcell Meszaros (MarsSeed) - Wednesday, 02 August 2023, 13:57 GMT
Let me say that I am sorry if I offended you, @Toolybird.

That was not at all my intention, and I regret that I did not express my feedback in a more diplomatic way.

I am grateful to you and all people who work on Arch Linux and every free open-source project in any capacity.

I still think that logically the severity is high, as evaluated per Arch Wiki bug reporting guidelines. No matter that it is simple to fix for someone who knows anything basic about Python packaging on Arch.

Also, simple smoke testing and/or running a namcap analysis is recommended for packagers working with the Arch repo. Correctly setting the severity would serve as a reminder for such.

It's not a matter of politeness. Choosing the 'High' severity is just the reasonable qualifier as per guidelines.

Please don't take my feedback as anything malicious. Thank you for your understanding and your dedicated hard work for the betterment of Arch Linux.

Loading...