-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clicking on the "?" for a Debian package causes infinite "Retrieving information" (and outright crashes on staging) #251
Comments
Log files are only available for transaction operations (install, uninstall, ...). For the info dialog you can launch bauh though a CLI with the parameter |
Try catches are your friend, at least in Java. :P
|
Basically, any button clicking / interaction with the user should be inside a broad try-catch block for any exception so that the application doesn't crash or hang when the user does an action. Like it does here. With a message of something like "An error has occured - " + {errorMessage with error/exception name} + line break + "More details can be found inside log " + {logName and location} + line break + "Please send the log file and fill the Bug Tracking Template when creating a new Issue in https://github.com/vinifmor/bauh/issues/". The log thus made would contain the error / exception name, error message and stacktrace. And perhaps some more information if deemed useful. EDIT: It's also good to have methods for that. Like showErrorMessage(String errorMessage, boolean fatal) and showErrorMessage(Exception exception, boolean fatal) which would gather information from the exception and format it to a string while calling the first method with the string as a parameter. These would then be used in IFs and CATCHes across the application. |
Please, paste the output of the following commands:
|
|
Great. Could you also post the output of |
Third edit, because GitHub somehow managed to maim the secod edit even when I've used quote, so I have to use code.
|
I've published a possible fix. Please, install this bauh version (https://github.com/vinifmor/bauh/archive/63f5c9140cc028f884f201a677a655eb46dd0a34.tar.gz) and let me know if the crash doesn't happen. (check if the size attributes are displayed on the info window as well -> download/installation) |
Seems to be working! But I think that there are errors in the info pane:
That "a" there seems mightly conspicuous: Unless that is correct. Also, the sizes have an invalid decimal separator, it seems like: |
Thank you for the feedback. So the initial info error you mentioned is fixed. This '{a}' is part of the aptitude output. It means additional package to be installed. The bad number encoding in the install output would fit as another issue. But don't bother to open a new one, because I'm going to attach the same encoding fix for all the aptitude calls. |
Yeap!
Oh. Now I'm glad I've said "Unless that is correct." after that. Covering my arse from sounding completely stupid. :P
OK. If it is about Unicode encoding - maybe we should connect those issues somehow (with the one about Unicode encoding that has already been closed), or add that as a comment to there? Wait, does GitHub support linking Issues? Because GitLab does. :P |
Sure... That's a good idea. I'm going to open a general encoding issue and link the related ones. By the way, I've published a fix to the output of the common transactions (install, uninstall, upgrade: https://github.com/vinifmor/bauh/archive/8cea0318ac23e31a8d141edc9512d42ff06ac350.tar.gz |
Seems to be working correctly for Debian... well, actually, no - it looks like the wrong part got outright skipped:
|
The numbers seem to look fine -> |
But those weren't the really broken ones originally, as they read like this:
|
Ah, they didn't appear because the packages are cached. They were downloaded the first time. |
I thought that as well. I guess I will have to check with a random package and hope for the best... Yup, decimal separators are now there. Correctly. I presume these can be changed if locale is changed (I'm still planning to make a Czech version someday)?
|
Actually the main operations are generally executed in English because bauh needs to understand the output to handle common errors. Otherwise we would need a handler for each language in the world. A Czech translation would be welcome :) |
I'm too spoiled from Java. :P AND from being able to modify both sides. Sending parsable objects, enums, exceptions,... AND I guess nobody expected someone to do an über-store and use their backends like you do. :D |
Describe the bug
bauh has been stuck on this for like 20 minutes now:
Duplication notes:
I'm trying to install CopyQ. The reason why the flatpack version of it is selected is that I've used the "?" button first to find out more information about it first (like the last update date). Then I've tried using the "?" for its Debian variant.
I'm going to test the staging version now by using the commands provided in the bug reporting template... OK, there it just crashed without an error when clicking on the "?" button for the Debian version of CopyQ. Nasty.
I can't find the file with logs for bauh. Where is that file located?
Software Environment
bauh version: 0.10.1
O.S: Linux Mint 20.3 Una with Cinnamon; kernel: 5.4.0-107-generic
Python version: Python 3.8.10
Installation method: pip3
The text was updated successfully, but these errors were encountered: