Bug 31586

Starts just fine 
isodumper-1.43-1.mga9
isodumper-qt-1.43-1.mga9


In an old bug it was a not properly synced mirror:
https://bugs.mageia.org/show_bug.cgi?id=30951

@Paul
Please confirm the circumstances of the failure you report in the light of what follows below. And say what desktop you are using (looks like Plasma).
Did you Cancel the 'no devices found' dialogue with no USB inserted?
With a USB inserted, does it work?
If not, suggest you un-install the application(s), clear any orphans, and re-install them, they do work in most situations.

isodumper-1.43-1.mga9
isodumper-qt-1.43-1.mga9
Using LXDE.

Playing with these *without a USB inserted*, I did manage to get errors:
 $ isodumper --gtk
This popped the dialogue only (no main application window):
 "Warning, No target devices were found, Refresh|Cancel",
Clicked Cancel:
 Segmentation fault (core dumped)

 $ isodumper --qt
Popped a main application window, completely blank, and the same dialogue as noted above. Clicking Cancel:
terminate called after throwing an instance of 'YUIDialogStackingOrderException'
  what():  Dialog stacking order violated
Aborted (core dumped)

With both versions, if the 'no devices' dialogue is responded "Refresh":
- still no USB, repeats the dialogue
- USB inserted, continues normally
In both versions, with a USB inserted, the application started OK.

Assigning to DavidG as the registered maintainer, CC'ing papoteur who mostly deals with isodumper.

Source RPM: (none) => isodumper-1.43-1.mga9.src.rpm,
Assignee: bugsquad => geiger.david68210
Summary: isodumper don't start => isodumper[-qt] crashes if no USB stick is inserted, and the 'no devices' dialogue is cancelled.
CC: (none) => lewyssmith, yves.brungard_mageia

I don't reproduce the crash of comment 1, but the one from comment 2.
Release 1.44 is coming for fixing the latest. I hope it will fix also the first.

The crashes are slightly different between the two versions gtk/qt, but provoked by the identical method of replying "Quit" or "Cancel" to the 'no device found' dialogue.

I will test the new version, look forward.

After upgrading two separate M8 Plasma installs to Cauldron, using the beta1 round 6 test CI iso, I am seeing the same failure as Comment 0. 

I was doing upgrades to look for problems to fix before the release.

One upgrade had to have clamav removed before it would complete; the other, which never had clamav in the first place, completed with no apparent problems. I haven't tried it on a "clean" install yet.

CC: (none) => andrewsfarm

With a new install of isodumper and dependencies, I'm seeing the same behavior as Comment 2. That's on a different install on the same hardware as the second system of Comment 5.

To repeat: 

In a Plasma-only M9 install that was upgraded from an M8 install, the upgraded isodumper refuses to start, either from the Plasma menu or the command line. 

In a Plasma-only M9 "clean" install, installing isodumper with dependencies will launch, but will crash if "canceled" with no usb device present.

It would appear that the upgrade script for isodumper and/or its dependencies needs work, too. We'll need to get to the bottom of this before the official release. Should I open a different bug, or do we use this one for that issue?

What about dnfdragora? I presume that the migration problem is in libyui libraries, thus dnfdragora could be affected in the same manner.

What are the installed libyui packages?
On my side
 rpm -qa |grep yui
lib64yui-mga16-1.2.1-4.mga9
lib64yui-mga-ncurses16-1.2.0-2.mga9
lib64yui-mga-qt16-1.2.0-2.mga9
libyui-ncurses-tools-4.4.4-2.mga9
lib64yui16-4.4.4-2.mga9
lib64yui-ncurses16-4.4.4-2.mga9
lib64yui-qt16-4.4.4-2.mga9
python3-yui-4.4.4-2.mga9
lib64yui-gtk16-2.52.3-2.mga9
lib64yui-mga-gtk16-1.2.0-6.mga9

Mageia 8 upgraded to Mageia 9 :
rpm -qa |grep yui gives : 

lib64yui9-qt-2.49.11-2.mga7
lib64yui12-mga-ncurses-1.1.0-4.mga8
lib64yui9-3.4.2-1.mga7
lib64yui12-mga-qt-1.1.0-4.mga8
lib64yui12-gtk-2.49.0-5.mga8
python3-yui-4.4.4-2.mga9
lib64yui12-ncurses-2.55.0-2.mga8
lib64yui9-mga-1.0.8-3.mga7
lib64yui12-mga-1.1.0-3.mga8
lib64yui12-qt-2.53.0-6.mga8
lib64yui9-mga-qt-1.0.5-2.mga7
lib64yui16-4.4.4-2.mga9
lib64yui12-3.10.0-3.mga8
lib64yui12-mga-gtk-1.1.0-5.mga8
lib64yui-mga16-1.2.1-4.mga9

And isodumper is still crashing.

Will try to remove the mg7 and mg8 rpm

It works !
urpme lib64yui9-qt-2.49.11-2.mga7 lib64yui12-mga-ncurses-1.1.0-4.mga8 lib64yui9-3.4.2-1.mga7 lib64yui12-mga-qt-1.1.0-4.mga8 lib64yui12-gtk-2.49.0-5.mga8 lib64yui12-ncurses-2.55.0-2.mga8 lib64yui9-mga-1.0.8-3.mga7 lib64yui12-mga-1.1.0-3.mga8 lib64yui12-qt-2.53.0-6.mga8 lib64yui9-mga-qt-1.0.5-2.mga7 lib64yui12-3.10.0-3.mga8 lib64yui12-mga-gtk-1.1.0-5.mga8

This removes also isodumper by dependencies.

Then urpmi isodumper and it's OK : the program starts.

I have mga8 packages as well, but nothing for mga7:

$ rpm -qa |grep yui
lib64yui12-3.10.0-3.mga8
lib64yui12-mga-qt-1.1.0-4.mga8
lib64yui12-ncurses-2.55.0-2.mga8
lib64yui12-qt-2.53.0-6.mga8
lib64yui12-mga-1.1.0-3.mga8
lib64yui12-mga-ncurses-1.1.0-4.mga8
lib64yui16-4.4.4-2.mga9
lib64yui-mga16-1.2.1-4.mga9
python3-yui-4.4.4-2.mga9

Going now to try removing them...

I used drakrpm to do the deed. Asking to remove the first installed mga8 library brought up all the others, as well as isodumper. Re-installing isodumper gives me this:

$  rpm -qa |grep yui
lib64yui16-4.4.4-2.mga9
lib64yui-mga16-1.2.1-4.mga9
python3-yui-4.4.4-2.mga9
lib64yui-ncurses16-4.4.4-2.mga9
lib64yui-qt16-4.4.4-2.mga9
lib64yui-mga-qt16-1.2.0-2.mga9
lib64yui-mga-ncurses16-1.2.0-2.mga9

Isodumper launches now, but still closes if "canceled" with no usb device present. In the terminal:

$ isodumper --qt
terminate called after throwing an instance of 'YUIDialogStackingOrderException'
  what():  Dialog stacking order violated
Aborted (core dumped)

rpm -qa|grep yui
python3-yui-4.4.4-2.mga9
lib64yui16-4.4.4-2.mga9
lib64yui-mga16-1.2.1-4.mga9
lib64yui-ncurses16-4.4.4-2.mga9
lib64yui-qt16-4.4.4-2.mga9
lib64yui-mga-qt16-1.2.0-2.mga9
lib64yui-mga-ncurses16-1.2.0-2.mga9
 
Same as you but no crash when cancelled with no usb device.

Thanks papoteur for the quick work.

On a Cauldron system, LXDE:
 isodumper-1.44-1.mga9
 isodumper-gtk-1.44-1.mga9
 isodumper-qt-1.44-1.mga9

Trying it WITHOUT a USB plugged in, as per comment 2:

GTK
Displayed the correct populated application window, plus the "No target devices were found" dialogue:
- Refresh re-displayed it.
- Cancel did NOT crash:
 $ isodumper --gtk
(python3:111358): dbind-WARNING **: 20:52:37.228: Couldn't connect to accessibility bus: Failed to connect to socket /root/.cache/at-spi/bus_0: Permission denied
UDisks2 OK

QT
Displayed the correct populated application window, plus the "No target devices were found" dialogue:
- Refresh re-displayed it.
- Cancel did NOT crash:
 $ isodumper --qt
(python3:111529): dbind-WARNING **: 20:56:12.021: Couldn't connect to accessibility bus: Failed to connect to socket /root/.cache/at-spi/bus_0: Permission denied
UDisks2 OK

To me this looks all fixed re the reported bug. Except for TJ's comment 13...

Are the 'libyui' packages still a problem, comment 6 onwards. TJ suggested a new bug for those upgrade issues; do you want that Yves?

Note the change to the package naming scheme between mga8 and mga9. 

The mga8 packages in Comment 12 are all of the form "lib64yui12-xxxx" while the mga9 replacements in Comment 13 are all of the form "lib64yui-xxxx16". I'm not talking about the change from "12" to "16" but to the position of the numbers in the package name.

Could this be why the upgrade script failed?

(In reply to Thomas Andrews from comment #16)
> Note the change to the package naming scheme between mga8 and mga9. 
> 
> The mga8 packages in Comment 12 are all of the form "lib64yui12-xxxx" while
> the mga9 replacements in Comment 13 are all of the form "lib64yui-xxxx16".
> I'm not talking about the change from "12" to "16" but to the position of
> the numbers in the package name.
> 
> Could this be why the upgrade script failed?

Yes, it's probably a problem of change in migration path, which seems incomplete, thus a packaging question.

I have put all the M9 SRPMs in t-heir header field.
These libyui & related pkgs are with Angelo, so assigning this bug to him. Papoteur also touches them, he is already CC'd.

Provisionally flagging for Errat9.

Assignee: geiger.david68210 => anaselli
Keywords: (none) => FOR_ERRATA9
Summary: isodumper[-qt] crashes on installation migrated from Mageia 8 => isodumper[-qt] crashes on installation migrated from Mageia 8, due to libyui etc naming changes
Source RPM: isodumper-1.43-1.mga9.src.rpm, => libyui-4.4.4-2.mga9.src.rpm, libyui-mga-1.2.1-4.mga9.src.rpm, libyui-mga-qt-1.2.0-2.mga9.src.rpm, libyui-mga-ncurses-1.2.0-2.mga9.src.rpm

Isodumper-XXX requires unversioned libyui-XXX (and libyui-mga-XXX).

Both, mga8 lib(64)yui12-XXX and mga9 lib(64)yui-XXX16, provides libyui-XXX so the requirement is fulfilled even with the older version.

I've added a bit more strict requirements to isodumper pkgs for libyui pkgs to somehow avoid this later. Required version is defined during the build time. This means isodumper should be rebuilt after libyui-mga pkg lib majors are later changed. libyui-mga pkgs pulls libyui pkgs.

IIUC same would have been happened even with lib(64)yui12-XXX to lib(64)yui16-XXX lib major change if some libyui pkgs with old lib majors would have been installed before installing isodumper.

I think crash on comment#0 is related to libyui update. new package contents and new versioning have probably broken something.
Old libs usually aren't a problem, but with bindings (as perl-yui or python-yui are) could. So maybe this time an obsoleted or some other way to remove them should be used. @wally wdyt?

No obsoletes needed, just more strict requires. See comment 19.

isodumper-1.44-3.mga9 with recent libyui updates with added provides should handle the issue.

and what about dnfdragora and manafirewall? Are they affected too?

(In reply to Angelo Naselli from comment #23)
> and what about dnfdragora and manafirewall? Are they affected too?
Yes.

I keep getting this message when I try to update:

Sorry, the following package cannot be selected:

- isodumper-qt-1.44-3.mga9.noarch (due to unsatisfied libyui-mga-qt16)

Now that I look at it better, I see that it's looking for libyui-mga-qt16, the 32-bit library, and I have the lib64 version installed. It would find it if I were to activate the 32-bit repos, but I don't think that's what we want, is it?

isodumper-gtk installs with no problems.

The message from comment 25 was still there this morning, but after removing isodumper and isodumper-gtk, and updating the package database, it had magically disappeared when I went back to drakrpm and asked to install isodumper-qt.

I presume we can close this as solved?

TJ did some fiddling to get round his problem. We need a straight M8-M9 upgrade containing isodumper-qt to be sure. I will try one if I have enough time.

I just tried an upgrade of a mga8-64 Plasma guest in VirtualBox. I used the last round of beta2 test CI iso, but with supplementary media active to simulate as accurately as I can at this point the next round of isos that will include Gnome 44.1.

The upgrade needed two passes, and there are some problems with it, but none of them appeared to be related to this bug. After booting to a running desktop, I tried running "isodumper --qt" and the gui came up, telling me I needed a usb key. I canceled, and isodumper quietly closed.

So, I would say this is solved for the qt version, as far as I can tell at this time. However, the problems I encountered with the update involved Gnome/Gtk- related packages, so until those are fixed the Gtk version might not run. I did not try that.

@Lewis: Another test, done by another party, certainly wouldn't hurt.

Thanks for your patient tests, which now look good.
I will try an upgrade if & when I have the time to organise it!

No problems have been reported after the release. We can now close this.

Status: NEW => RESOLVED
Resolution: (none) => FIXED