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.
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.
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?
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.
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.
Doubtful that your slow downloads are related to this issue. Sorry I don't have more to offer here. :/
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.
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.
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!
Yes, I can confirm that replacing isAlive with is_alive in 4 places fixed the issue. Thank you!
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.
FEDORA-2020-cf1dae042f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf1dae042f
FEDORA-2020-8b7bf8276d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b7bf8276d
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.
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.
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.
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.