Bug 1906612

Summary: crash on connect
Product: [Fedora] Fedora Reporter: dfxgordon
Component: cura-lulzbotAssignee: Miro Hrončok <mhroncok>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 33CC: mhroncok, spotrh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: cura-lulzbot-3.6.22-2.fc34 cura-lulzbot-3.6.22-2.fc32 cura-lulzbot-3.6.22-2.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-27 01:16:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1785415    
Attachments:
Description Flags
output showing crash handler messages none

Description dfxgordon 2020-12-10 22:31:58 UTC
Created attachment 1738316 [details]
output showing crash handler messages

Description of problem: cura-lulzbot crashes immediately upon trying to connect to the printer.


Version-Release number of selected component (if applicable):
output of dnf list cura-lulzbot is : 1:3.6.22-1.fc33

How reproducible: every time


Steps to Reproduce:
1. freshly install fedora 33
2. run sudo dnf update
3. restart
4. sudo dnf install cura-lulzbot
5. plug in lulzbot mini 2 to a USB port, turn on printer
6. run cura-lulzbot (either from command line or app launcher, doesn't matter)
7. add the printer Lulzbot Mini 2 accepting defaults
8. press monitor button
9. scroll to connect button and press
10. For me the application crashed (closed) immediately

Actual results:
program crashes/closes immediately

Expected results:
Program reports either successful connection or unsuccessful attempt without closing


Additional info:
Running from terminal shows the last message from the crash handler.  Please see attachment.  I also included the output of "groups" and "sudo dnf update --refresh" to show proper (or not) configuration.

Comment 1 Tom "spot" Callaway 2020-12-10 23:42:56 UTC
Okay, one immediate thought (other than to sigh at how ancient and crufty cura-lulzbot is in 2020)... see if you have the 3dprinter-udev-rules package installed. You should, but if those rules aren't active, it might cause the behavior you're seeing. The simplest way to be sure is to reboot (since the rules are loaded then for sure), but if you want to manually reload the rules, I think this (as root) will do the trick:

   udevadm control --reload-rules && udevadm trigger

Then start cura-lulzbot again and see if it crashes when it tries to talk to the printer over USB.

Comment 2 dfxgordon 2020-12-11 12:21:50 UTC
Thank you.
3dprinter-udev-rules.noarch is installed as 0.2.2-4.fc33.
I tried running the manual reload anyway but even with sudo got permission denied (failed to write 'change' to '/sys/devices/LNXSYSTM:00/uevent').
For some reason I could not do "su" either (is that disabled in Fedora?).
Unfortunately behavior of the package is still the same, including after reboot.
Regarding cruftiness, is there a modernized software option on linux for this printer?

Comment 3 Tom "spot" Callaway 2020-12-15 15:41:57 UTC
There is not any other software besides cura-lulzbot to drive the modern Lulzbot printers, which is unfortunate.

I am somewhat concerned that sudo / su do not seem to work for you, as I suspect your system may have bigger problems.

Comment 4 dfxgordon 2020-12-15 20:32:43 UTC
To be clear sudo is not broken in general, e.g., "sudo dnf update" works, which I just ran.  It updated fine (if slow), but printer software behavior is unchanged.

This is a fresh install, only Chrome was added before cura-lulzbot, no other add ons.  The old OS was erased (that was Ubuntu which also could not run cura-lulzbot).

One other strange thing that was happening right out of the box with Fedora is extremely slow downloads while updating; only mention this in case it could be related.

Comment 5 Tom "spot" Callaway 2020-12-15 20:42:01 UTC
Doubtful that your slow downloads are related to this issue. Sorry I don't have more to offer here. :/

Comment 6 dfxgordon 2020-12-15 21:10:58 UTC
OK will try something else then.
FYI I didn't realize the root password is not set on install.  After doing that I can do the "udevadm control --reload-rules && udevadm trigger".  No change.

Comment 7 Miro Hrončok 2020-12-15 21:23:24 UTC
This might ba a Python 3.9 compatibility issue. From the log:

2020-12-10 16:59:06,517 - CRITICAL - [(140648886220608)-MainThread] cura.CrashHandler.__init__ [64]: AttributeError: 'Thread' object has no attribute 'isAlive'

And indeed, https://docs.python.org/3.9/whatsnew/3.9.html

> The isAlive() method of threading.Thread has been removed. It was deprecated since Python 3.8. Use is_alive() instead. https://bugs.python.org/issue37804



Tom, is there an active upstream, or should I just patch this in Fedora?


dfxgordon, could you please try the following workaround and report back if it fixes the issue?

Under root edit the /usr/lib/cura-lulzbot/plugins/USBPrinting/USBPrinterOutputDevice.py file (e.g. via sudo nano). Find all 4 instances of isAlive and replace them with is_alive. Save the file and restart cura-lulzbot.

Comment 8 Tom "spot" Callaway 2020-12-17 20:19:32 UTC
The company that originally created the cura-lulzbot code emptied out all of its staff and was sold to a different company. That new company does seem to have made a few extremely minor commits to the code, but most of my questions to them have either received short answers or no answers. I guess this means they're technically alive though.

Make the patch in Fedora, please, and I'll send it upstream.

Thanks!

Comment 9 dfxgordon 2020-12-18 19:46:50 UTC
Yes, I can confirm that replacing isAlive with is_alive in 4 places fixed the issue.
Thank you!

Comment 10 Fedora Update System 2020-12-18 22:17:37 UTC
FEDORA-2020-2cd9b850e5 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Fedora Update System 2020-12-18 22:17:39 UTC
FEDORA-2020-cf1dae042f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf1dae042f

Comment 12 Fedora Update System 2020-12-18 22:17:39 UTC
FEDORA-2020-8b7bf8276d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b7bf8276d

Comment 13 Fedora Update System 2020-12-19 01:16:32 UTC
FEDORA-2020-8b7bf8276d has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8b7bf8276d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b7bf8276d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2020-12-19 01:20:11 UTC
FEDORA-2020-cf1dae042f has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-cf1dae042f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf1dae042f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 15 Fedora Update System 2020-12-27 01:16:23 UTC
FEDORA-2020-cf1dae042f has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fedora Update System 2020-12-27 01:39:44 UTC
FEDORA-2020-8b7bf8276d has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.