The graphical authentication window in both qt and gtk versions is too small to provide useful information (e.g., that root password is being requested). See attached screenshot from up-to-date Cauldron and E24 DE.
Created attachment 11687 [details] isodumper authentication popup
Assigning to papoteur.
CC: (none) => geiger.david68210Assignee: bugsquad => yves.brungard_mageia
Hello, This dialog is not provided by isodumper, but by a polkit agent I think you can found the culprit with: ps -aux |grep policykit
You can try also from a user console to launch: mcc you should get a similar dialog.
Created attachment 11691 [details] Authentication popup - MCC
Created attachment 11692 [details] Authenticate drakrpm OK, the question is why both this and the MCC authentication popups both appear with full text displayed. In E24 the EFL polkit agent has been improved and integrated into Enlightenment, so to some extent it is an upstream issue. However, before I report there, is there some reason that drakrpm and mcc both trigger adequate sized windows but isodumper does not?
A thousand apologies from and much eating of crow by the idiot reporting the "bug". It turns out that this is my error. The problem lies in using the earlier E23 default theme modified with E branding. This was apparently addressed in the default E24 theme as changing to that solved the problem. Now to update the Mageia-branded E theme before Mga8 release . . . And apologies for the noise.
Not a bug.
Status: NEW => RESOLVEDResolution: (none) => INVALID
No problem, And what the dialog looks like, now?
Resolution: INVALID => FIXED
Created attachment 11693 [details] Isodumper auth with default E24 Turns out to be a good question as I did not notice until checking the screenshot that the agent pops up in English. An untranslated string for isodumper, python3 . . .?
Created attachment 11694 [details] Earlier them - format Oops, I make a poor tester! There are two different authentication windows! My last tests were actually based on requesting a format from the main isodumper window. That works properly with the current Mageia theme as shown in this screen capture. HOWEVER, if the action is to copy an iso to a USB, the too small window opens. I DK if this can be replicated in other DEs, but this is not related to the E theme after all.
Reopening based on subsequent tests and until we can clarify more. The question implied by the last post is: what is different about the calls to polkit from the two different points of isodumper?
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
Created attachment 11695 [details] Terminal output - write to USB Note line 15 where this error appears: <ERR> [Gtk] libyui-gtk:0 (): gtk_window_resize: assertion 'width > 0' failed
Created attachment 11696 [details] Terminal output - format USB For comparison: note there is no window resize error
The format feature use a shell command with a prefix of pkexec command. The copy feature use a communication with a backend through DBus. Interactive password asking is triggered by DBus. This is why behaviour can be different.
(In reply to aguador from comment #13) > Created attachment 11695 [details] > Terminal output - write to USB > > Note line 15 where this error appears: > > <ERR> [Gtk] libyui-gtk:0 (): gtk_window_resize: assertion 'width > 0' failed I don't think this is related. Password dialog is not provided by libyui, nor isodumper.
Created attachment 11697 [details] Authentication windows in LXQt In my case, window is not too small, but there is no message, what is not very fun.
Not too small, but still the text in the frame is not fully produced either. I think I have exceeded my level of incompetence here. :-D Maybe there is a hint in the code that calls the polkit agent in MCC? Everything else I have tried calling for authentication displays properly: gparted, administer networks (from netapplet) . . .
Hello, I found what is bad. The configuration file for polkit was not build with translated messages, but was the model with a _message tag. A correction is coming.
Fantastic! That must have taken some hunting. I'll watch for the update. Best, Roy (BTW I was thinking about this today and wondering about asking upstream given that Mate polkit agent seemed to handle things well. I'm really glad you found it.)
Correction is now in cauldron, with 1.18 release
I was afraid of that. I just updated today and used isodumper to create a Plasma live USB -- and the same problem in both Gtk and Qt. Verification of the Mageia 8 alpha also hung at 99% and I had to kill the process, but that may be a different issue as it worked correctly in a test with another iso.
>the same problem in both Gtk and Qt. Which problem do you speak here? The window size or the hang at 99%? I hit also the hang à 99%, which is another problem.
Sorry, I shouldn't have mentioned the hang. No, the polkit window size is just as small as before. I don't know why as I am sure that you've tested it. It would be nice to know if the issue appears with other languages or desktops that are not using the Mate or KDE authentication packages.
Created attachment 11728 [details] Authentication window E24 Perfect!
Works like a charm, including on the SHA3 verification on Mageia 8.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Advisory ============================= Release 1.19 fix problem that SHA3-512 provides sum in upper case while isodumper was computing it with lower case. Thus check was always false. Logic of signature is also improved. It adds parsing of arguments from command line (use python-manatools, new dependency). It fix installation of config file for polkit (mga#26776) =============================
Assignee: yves.brungard_mageia => qa-bugs
List of packages: Packages in 7/core/updates_testing: ======================== isodumper-1.19-1.mga7.noarch.rpm isodumper-qt-1.19-1.mga7.noarch.rpm isodumper-gtk-1.19-1.mga7.noarch.rpm python3-manatools-0.0.3-1.mga7.noarch.rpm Source RPM: ======================== isodumper-1.19-1.mga7.src.rpm python-manatools-0.0.3-1.mga7.src.rpm
Version: Cauldron => 7
I downloaded all four packages using the qarepo tool, then attempted to update using MCC. And I got an error message that isodumper couldn't be updated because of an unsatisfied python3-manatools, even though it was right there in the local repo. I checked, and prior to attempting the update, the current python3-manatools was not installed. It looks like python3-manatools is not being pulled in as a new dependency unless it's already installed.
CC: (none) => andrewsfarm
python3-manatools is a required dependency: $ urpmq --requires isodumper isodumper: config(isodumper)[== 1.19-1.mga7] isodumper: isodumper-gui isodumper: libyui9-mga-ncurses isodumper: libyui9-ncurses isodumper: polkit isodumper: python(abi)[== 3.7] isodumper: python3 isodumper: python3-gnupg isodumper: python3-gobject3 isodumper: python3-manatools isodumper: python3-parted isodumper: python3-psutil isodumper: python3-pydbus isodumper: python3-yui isodumper: typelib(GLib) isodumper: udisks2 $ urpmq --whatrequires python3-manatools isodumper
@TJ, regarding comment 29. Tried this using the MageiaUpdate route. Installed the version 1.6.1 packages and made sure that python3-manatools was not installed. Enabled updates-testing and ran $ urpmi.update -a $ MageiaUpdate That presented python3-manatools as a dependency so I went ahead with the update and python3-manatools was installed. That looked fine and isodumper started up OK but on checking the installed RPMs I found that isodumper-gui was not there. It is not listed in the updates so I had not checked to see if there was a version already installed. MageiaUpdate would not have looked for an updated version if it were not but if it is an explicit dependency (requires) then it should have picked it up I would have thought, and the same would apply to python3-manatools in your case.
CC: (none) => tarazed25
$ sudo urpmi isodumper-gui In order to satisfy the 'isodumper-gtk|isodumper-qt|isodumper-gtk|isodumper-qt|isodumper-gtk|isodumper-qt|isodumper-gtk|isodumper-qt|isodumper-qt|isodumper-gtk|isodumper-gtk|isodumper-qt' dependency, one of the following packages is needed: 1- isodumper-gtk-1.19-1.mga7.noarch: IsoDumper for GTK (to upgrade) 2- isodumper-qt-1.19-1.mga7.noarch: IsoDumper for Qt (to upgrade) What is your choice? (1-2) 1 Package isodumper-gtk-1.19-1.mga7.noarch is already installed Marking isodumper-gtk as manually installed, it won't be auto-orphaned writing /var/lib/rpm/installed-through-deps.list
$ rpm -q isodumper-gui package isodumper-gui is not installed $ urpmq --requires isodumper | grep gui | uniq isodumper: isodumper-gui
So that means that isodumper-gui is a throwaway package, only needed for isodumper installation. Not a problem, and not related to the python3-manatools issue.
Just tried again, this time with another system. Going to describe what I'm doing, step by step. 1. Went to MCC, and checked for installation of python3-manatools. The package didn't appear on the repos at all. 2. Used qarepo to download the four packages into a local repo. All four packages were downloaded. 3. Went to MCC's Mageia Update, and got the following message: Sorry, the following packages cannot be selected: - isodumper-1.19-1.mga7.noarch (due to conflicts with python3-manatools-0.0.3-1.mga7.noarch, due to conflicts with python3-manatools-0.0.3-1.mga7.noarch) - isodumper-gtk-1.19-1.mga7.noarch - isodumper-qt-1.19-1.mga7.noarch (due to unsatisfied isodumper[== 1.19-1.mga7]) 4. Mageia Update would not let me select any of the isodumper packages, citing the above problem. 5. Cancelled the update, went back and looked, and python3-manatools is now listed, because it is in the local repo. But, when I go to install it manually, I see this message: Sorry, the following package cannot be selected: - python3-manatools-0.0.3-1.mga7.noarch (due to unsatisfied python3.7dist(python-gettext)) Methinks there is yet another dependency that wasn't listed here.
This is getting a bit strange. Before the MageiaUpdate I had tried : $ sudo urpmi python3-manatools To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") python3-argparse 1.4.0 2.mga7 noarch (medium "Core Updates") python3-yaml 5.3.1 1.mga7 x86_64 (medium "Core Updates Testing") python3-gettext 4.0 3.mga7 noarch python3-manatools 0.0.3 1.mga7 noarch 1004KB of additional disk space will be used. 292KB of packages will be retrieved. Proceed with the installation of the 4 packages? (Y/n) n And during MageiaUpdate retrieving rpm files from medium "Core Updates Testing"... $MIRRORLIST: media/core/updates_testing/isodumper-qt-1.19-1.mga7.noarch.rpm $MIRRORLIST: media/core/updates_testing/python3-gettext-4.0-3.mga7.noarch.rpm $MIRRORLIST: media/core/updates_testing/python3-manatools-0.0.3-1.mga7.noarch.rpm It is difficult to see what might be the difference between our two procedures except that I used a mirror and you used a local repository, which might not have been fully populated.
I used the list from Comment 28 when I used qarepo. Note that it does not contain python3-gettext, which you drew in from updates-testing. When I add python3-gettext to the qarepo list, Mageia Update then gives me this: The following 6 packages are going to be installed: - isodumper-1.19-1.mga7.noarch - isodumper-qt-1.19-1.mga7.noarch - python3-argparse-1.4.0-2.mga7.noarch - python3-gettext-4.0-3.mga7.noarch - python3-manatools-0.0.3-1.mga7.noarch - python3-yaml-5.3.1-1.mga7.x86_64 And the update proceeds without incident. the python3-gettext package belongs on the list from Comment 28. Otherwise, it could be left behind when the update is pushed. It's happened before. This is just the sort of thing qarepo was designed to catch. I have not tested the update itself yet. That will have to wait a while, for when I come back in from work.
Good work TJ. Mageia still needs QA!
64-bit Plasma system. Ran isodumper-QT from the menu. As it should, It told me there was no device. Inserted a fresh 8GB flash drive and hit refresh. The gui appeared. Dumped a Mageia 8 Live Xfce iso to the flash drive, and then rebooted into the result. All was good. Rebooted into the main system, and ran isodumper from the command line this time. Formatted the flash drive to FAT32. Removed the drive, and inserted one already containing a M8 iso. backed up the drive to my hard drive, then "restored" it to a different flash drive. Everything "just worked." No "hangs," and authentication windows were the proper size. Looks OK here, but I'm holding the OK and validation until the missing python3-gettext package is added to the list of rpms.
Forgot to mention, at the end of the image restoration the gui disappeared without telling me I could remove the drive, and I received this message in Konsole: g-io-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.DeviceBusy: Cannot eject drive in use: Device /dev/sdd1 is mounted (36) I have occasionally seen "crashes" like this before with isodumper, but this is the first time I've seen it when running from the command line. It's inelegant, but it doesn't affect the function, as it doesn't happen until the end of the process. I don't think it's serious enough to stop this update.
List of packages: Packages in 7/core/updates_testing: ======================== isodumper-1.19-1.mga7.noarch.rpm isodumper-qt-1.19-1.mga7.noarch.rpm isodumper-gtk-1.19-1.mga7.noarch.rpm python3-manatools-0.0.3-1.mga7.noarch.rpm python3-gettext-4.0-3.mga7.noarch.rpm Source RPM: ======================== isodumper-1.19-1.mga7.src.rpm python-manatools-0.0.3-1.mga7.src.rpm python-gettext-4.0-3.mga7.src.rpm
Thank you, David. Giving this a 64-bit OK, and validating. Advisory in Comment 27, with updated package list in Comment 41.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA7-64-OKCC: (none) => sysadmin-bugs
(In reply to Thomas Andrews from comment #40) > Forgot to mention, at the end of the image restoration the gui disappeared > without telling me I could remove the drive, An aside from my experience in Cauldron not directly related to testing: I have used this version of isodumper several times now, running it in one workspace while doing other things, only to return to be a bit disconcerted at finding . . . nothing, as it had terminated successfully. It seems more natural not only to have the OK to remove the drive, but to be able to view the processing information, even though it means manually closing the window. That information might include noting which md/shasums were successfully verified. For consideration in a future version as the current version is great as is.
Advisory ============================= Release 1.20 fix problem that SHA3-512 provides sum in upper case while isodumper was computing it with lower case. Thus check was always false. Logic of signature is also improved. It adds parsing of arguments from command line (use python-manatools, new dependency). It fix installation of config file for polkit (mga#26776) It fix also a crash when trying to eject if automatic mounting is enabled (mga#26974) =============================
CC: (none) => yves.brungard_mageia
New updated list of packages: Packages in 7/core/updates_testing: ======================== isodumper-1.20-1.mga7.noarch.rpm isodumper-qt-1.20-1.mga7.noarch.rpm isodumper-gtk-1.20-1.mga7.noarch.rpm python3-manatools-0.0.3-1.mga7.noarch.rpm python3-gettext-4.0-3.mga7.noarch.rpm Source RPM: ======================== isodumper-1.20-1.mga7.src.rpm python-manatools-0.0.3-1.mga7.src.rpm python-gettext-4.0-3.mga7.src.rpm
I was seeing the crash situation on two of my systems, but I have been running this version for several days now, and have dumped several isos to flash drives without a single crash. The OK and validation are still valid. Updated advisory information in Comment 44 and Comment 45.
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0160.html