Tested mga3_64,

Testing complete for isodumper-0.20.mga3, Ok for me it work fine.

-Isodumper start good (with consolehelper as root and as simple-user on console or on desktop menu entry too)
-testing backup function (create a backup and restore the backup too)
-testing dumping an ISO to my USB stick

--------------------------------------------------------------------------

Tested mga3_32,

Testing complete for isodumper-0.20.mga3, Ok for me it work fine.

-Isodumper start good (with consolehelper as root and as simple-user on console or on desktop menu entry too)
-testing backup function (create a backup and restore the backup too)
-testing dumping an ISO to my USB stick

CC: (none) => geiger.david68210
Whiteboard: (none) => MGA3-64-OK MGA3-32-OK

Sorry guys, it was decided not to open backports for mga3 at this time until the process and policy has been finalised and tested in action in mga4. 

You might ask for an exception to allow this as an update instead of a backport.

CC: (none) => qa-bugs
Assignee: qa-bugs => remi

I'm now submitting IsoDumper as an update to Mageia 3, since there is a consensus about making an exception to the updates policy for it.

--

Suggested advisory:
========================

New isoDumper package added to Mageia 3

IsoDumper is a graphical interface to dump ISO images on USB sticks,
and also provides a functionality to create a backup image of the stick.

It is developed by Mageia contributors, and as such we decide to put it
forward so that Mageia 3 users can use a reliable tool to upgrade to
Mageia 4.1 or Mageia 5.

This new package is included as an update as an exception to Mageia's
updates policy.

========================

Updated packages in core/updates_testing:
========================
isodumper-0.20-1.mga3.noarch

Source RPMs: 
isodumper-0.20-1.mga3.src.rpm

--

As we want to be able to advertise IsoDumper to Mageia 3 users when we release Mageia 4.1 and Mageia 5, I think this update candidate should be tested by more than one person.

Some things that would be nice to test:
- Verify that you can start IsoDumper as root, and also as normal user (it should then ask for the root password)
- Verify that it's properly localised
- Check that it detect your USB stick if it's plugged in when starting, and also it is plugged in afterwards
- Dump an image to the USB stick while also creating a backup image of the stick's content
- Dump an image without creating a backup (you could dump your previous backup)

Have fun! And don't hesitate to give feedback to Papoteur if you do a thorough test of IsoDumper and get ideas of potential improvements :-)

Severity: enhancement => normal
Priority: Low => Normal
Component: Backports => RPM Packages
Assignee: remi => qa-bugs
Depends on: 12766 => (none)
QA Contact: (none) => remi
Summary: Backport Candidate: isodumper 0.20 for Mageia 3 (new package) => Update Candidate: isodumper 0.20 for Mageia 3 (new package)
Whiteboard: MGA3-64-OK MGA3-32-OK => has_procedure

Hi,

From Mageia 3 x86_64 real :

--Install--
$MIRRORLIST: media/core/updates_testing/isodumper-0.20-1.mga3.noarch.rpm
installation de isodumper-0.20-1.mga3.noarch.rpm depuis /var/cache/urpmi/rpms                          
Préparation...                   #####################################################################
      1/1: isodumper             #####################################################################
[root@localhost aranud]# 

--Launch--

As root :
---------
 isodumper
(isodumper.py:22827): libglade-WARNING **: unknown attribute `swapped' for <signal>.

Many warning but it is start.

As user :
----------
$isodumper
Error executing command as another user: Not authorized
This incident has been reported.

Dont start in terminal but start and ask password with shortcut in menu



--Writing--
I don't like, the usb key is grey if the iso is not selected.
We can think, isodumper don't detect the key.

Write and test live mageia 4 kde okay !


--backup--
I don't understand how i can must it ?
I select iso + usbkey and i check the box, i select folder and valid.
The box is unchecked :/

CC: (none) => aranud

I think that the polkit launcher is not actual in Mageia 3. David, can you check ?
For the backup, you must select a directory AND write a name for the file to write. I will check if this can be improved.
Papoteur

When Clicking the button to choose a directory to store a backup the file browser opens beneath the main window. The main window retains focus so it is difficult to see what your are selecting in the file browser.

Adding feedback marker for now.

Whiteboard: has_procedure => has_procedure feedback

That was using lxde in vbox in comment 6.

Also when it is writing to the device the "Write to device" button is grey and dimmed but the "Close" button remains orange and clickable. It doesn't however act as a cancel button, doesn't seem to do anything, so is a bit confusing. Could it possibly either cancel or be greyed like the "Write to device" one.

(In reply to claire robinson from comment #8)
> Also when it is writing to the device the "Write to device" button is grey
> and dimmed but the "Close" button remains orange and clickable. It doesn't
> however act as a cancel button, doesn't seem to do anything, so is a bit
> confusing. Could it possibly either cancel or be greyed like the "Write to
> device" one.

Do you mean that it have a sense to abort the writing process? The process take a long time, but stopping it will leave the key unusable.
Thus I mean greying the Cancel button.
WDYT?

Yes sounds good. It's only a comment though so don't feel you have to. The main issue was the main window retaining focus when the file browser opened beneath it. It made it kind of unusable.

Claire if you agree I suggest to push isodumper-0.21 on mga3 repo (same as mga4), this version fixes a few bugs. I think it would be more appropriate.

It just needs a patch to adapt "usermode" because "polkit agent" is not 100% operational on mga3.

What do you think ?

Completely your decision David. This is a new package so starting at the same version as mga4 does make sense.

As long as it works :)

Ok, thanks

I tested it in preview and it works very well.
so I'll push it on MGA3/Core/Updates_testing.

Ok, new release 0.21 is now submitted on mga3, also I update advisory.
This is the same version as mga4. 
(https://bugs.mageia.org/show_bug.cgi?id=13359#c5)



========================
I'm now submitting IsoDumper as an update to Mageia 3, since there is a consensus about making an exception to the updates policy for it.

See isodumper project changelog : 
https://github.com/papoteur-mga/isodumper/releases/tag/0.21
--

Suggested advisory:
========================

New isoDumper package added to Mageia 3

IsoDumper is a graphical interface to dump ISO images on USB sticks,
and also provides a functionality to create a backup image of the stick.

It is developed by Mageia contributors, and as such we decide to put it
forward so that Mageia 3 users can use a reliable tool to upgrade to
Mageia 4.1 or Mageia 5.

This new package is included as an update as an exception to Mageia's
updates policy.

========================

Updated packages in core/updates_testing:
========================
isodumper-0.21-1.mga3.noarch

Source RPMs: 
isodumper-0.21-1.mga3.src.rpm

--

As we want to be able to advertise IsoDumper to Mageia 3 users when we release Mageia 4.1 and Mageia 5, I think this update candidate should be tested by more than one person.

Some things that would be nice to test:
- Verify that you can start IsoDumper as root, and also as normal user (it should then ask for the root password)
- Verify that it's properly localised
- Check that it detect your USB stick if it's plugged in when starting, and also it is plugged in afterwards
- Dump an image to the USB stick while also creating a backup image of the stick's content
- Dump an image without creating a backup (you could dump your previous backup)

Have fun! And don't hesitate to give feedback to Papoteur if you do a thorough test of IsoDumper and get ideas of potential improvements :-)

(In reply to claire robinson from comment #6)
> When Clicking the button to choose a directory to store a backup the file
> browser opens beneath the main window. The main window retains focus so it
> is difficult to see what your are selecting in the file browser.

I never saw that. I must invesgate for it. Do you mean that it can be related to the window manager ?

@papoteur: Do you want to try to fix the bugs reported in comment 6 and comment 8 and push isodumper 0.22 instead of this update candidate, or should we go on with this one?

For comment #6, I must investigate.
For comment #8, the button is active. I think that the user should be able to stop the writing and the program, although the result on the key will unusable.
Is a window "Do you want really stop the writing?" needed?

(In reply to papoteur from comment #17)
> For comment #8, the button is active. I think that the user should be able
> to stop the writing and the program, although the result on the key will
> unusable.
> Is a window "Do you want really stop the writing?" needed?

I think such a confirmation popup would be nice to have, but maybe it can wait for a later release. Just to be sure, if you abort while writing on the key, you would still be able to retry dumping an ISO on the same USB key, or would you have to play some dark magic to make the key usable again?

The tool writes on the key whatever is the content.

Version 0.22 is yet pushed on github which solves the problem cited on comment #6.
About the comment #8, the application stop with the action of the "Close" button. It is not immediate. Thus I did not modify that.
Papoteur

A new bugfix version of isodumper (0.22) has been issued to fix the bug described in comment 6. The changelog is here: https://github.com/papoteur-mga/isodumper/releases/tag/0.22
This new release also clarifies the license of the isodumper icon (which is LGPLv2+ and is now also provided in SVG format).

Please see comment 14 for a detailed testing procedure, and comment 6 for details about the bug being fixed by the 0.22 update.

I'm pushing this as an update candidate to Mageia 3 and Mageia 4. The advisories will be in the following comment.

Summary: Update Candidate: isodumper 0.21 for Mageia 3 (new package) => Update Candidate: isodumper 0.22 for Mageia 3 (new package) and Mageia 4
Whiteboard: has_procedure feedback => has_procedure
Source RPM: isodumper-0.21-1.mga3 => isodumper-0.22-1.mga3

Suggested advisory for Mageia 3:
========================

New isodumper package added to Mageia 3

IsoDumper is a graphical interface to dump ISO images on USB sticks,
and also provides a functionality to create a backup image of the stick.

It is developed by Mageia contributors, and as such we decide to put it
forward so that Mageia 3 users can use a reliable tool to upgrade to
Mageia 4.1 or Mageia 5.

This new package is included as an update as an exception to Mageia's
updates policy.

References:
- https://raw.githubusercontent.com/papoteur-mga/isodumper/0.22/CHANGELOG
========================

Updated packages in core/updates_testing:
========================
isodumper-0.22-1.mga3.noarch

Source RPMs: 
isodumper-0.22-1.mga3.src.rpm

Suggested advisory for Mageia 4:
========================

Update isodumper package fixes UI window issue

  The main window of Isodumper would not give the focus over
  to the file browser dialog used to set the backup destination folder.
  This made the dialog difficult to use since it could be partly
  hidden by the main window.

  This bugfix releases fixes this issue, and also adds default values
  for the backup name and directory, and an SVG version of the icon together
  with a clarification of its open source license.

References:
- https://raw.githubusercontent.com/papoteur-mga/isodumper/0.22/CHANGELOG
- https://bugs.mageia.org/show_bug.cgi?id=12702#c6
========================

Updated packages in core/updates_testing:
========================
isodumper-0.22-1.mga4.noarch

Source RPMs: 
isodumper-0.22-1.mga4.src.rpm

Testing on Mageia 4 i586.

I followed the procedure in comment 14, everything works as expected. The bug reported in comment 6 has also been fixed.

Whiteboard: MGA3TOO has_procedure => MGA3TOO MGA4-32-OK has_procedure

(In reply to papoteur from comment #20)
> About the comment #8, the application stop with the action of the "Close"
> button. It is not immediate. Thus I did not modify that.

I'm not sure I understand what you mean. I just tried it in isodumper 0.22: if I start writing an ISO on my USB stick, and that I click on "Close" during the process, IsoDumper closes down without asking for confirmation.

I think a confirmation popup should be displayed, to prevent silly mistakes (the "Close" button is big enough that one might inadvertently click on it). This is not critical and could be for a later version though, maybe 0.30?

Testing complete mga4 64

Tested as user & root with and without a USB stick initially inserted. Cancelled a dump in progress. Made a backup, confirm the issue with file selection for the backup is fixed.

(Tip: it creates a backup the full size as the USB stick so allow for enough space where you save it)

Whiteboard: MGA3TOO MGA4-32-OK has_procedure => MGA3TOO MGA4-32-OK mga4-64-ok has_procedure

Testing Mageia i586.  Still some minor issues.

It does start fine, but the window keeps coming up behind the terminal I started it from.

Clicking the Close button closes the program correctly, but clicking the X on the window leaves the program running in the terminal (although the window is gone) so I have to hit Ctrl-C.

Also, if you click Details to expand that part of the window so that you can see it, there's nothing in there.  I guess it'll show something there after you hit Write to device.  Even before you click that, I'd expect to see something, like perhaps the dd command it's about to run.  Anyway, if you then click Details to hide that part of the window, the window flashes...it looks like the window is being destroyed and then redrawn from scratch, which shouldn't be necessary.

Another thing I was concerned about, but didn't test, I had the device and an ISO selected, and then I browsed and ejected the device with dolphin.  IINM, running dd at this point should be unsuccessful, so I was curious as to whether isodumper will repeat the check it makes when it launches to see if the USB device is still present before it actually tries to write to it.

Once I hit write to device, in the Details section (and the log file it creates), while the GUI progress bar goes all the way across, the Details log stops at Wrote: 33% 17301504 bytes (note that I used the Mageia 3 i586/install/images/all.img file to write to the USB disk).  More importantly, the ~/.isodumper directory and log file contained within are owned by root, which really isn't good.

Finally, when it's done writing, a dialog pops up and it says something about "when you close the application," but actually clicking the OK button to close the dialog closes the application, which is unexpected.

I have not yet tested the backup feature.

While I was in favor of allowing the exception to push this package as an update, I would expect it to be far more polished than this if we were going to do that.  I don't believe we can push this in its current state.

Whiteboard: MGA3TOO MGA4-32-OK mga4-64-ok has_procedure => MGA3TOO MGA4-32-OK mga4-64-ok has_procedure feedback

I tried to use it in Mga3 x86_64 on real h/w.

On checking the box to create a backup of the 8GB stick I was using, the button to the right of "Backup In" labelled "(none)" was inoperative.
I have since read comment #6 so I will check that it's not opening under something else (requires reboot so will report back).

Having selected an iso to dump, the filename is only partly shown in the GUI dialog and there is no way to expand the window to enable it to be read properly.
It should be possible to read and check the filename before continuing.

CC: (none) => zen25000

Re-checking from terminal, the backtrace is produced on clicking the button to select a backup directory.:


[baz@jackodesktop ~]$ isodumper

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.

(isodumper.py:3888): libglade-WARNING **: unknown attribute `swapped' for <signal>.
[['Kingston DataTraveler 2.0', '/dev/sdi', '8011087872']]
Traceback (most recent call last):
  File "/usr/lib/isodumper/isodumper.py", line 155, in backup_sel
    self.backup_bname.set_current_folder_uri('file:///home/'+self.user)
AttributeError: IsoDumper instance has no attribute 'user'

Thanks for your deep testing.
I will look for solutions for each point.

(In reply to David Walser from comment #27)
> Testing Mageia i586.  Still some minor issues.
> 
> It does start fine, but the window keeps coming up behind the terminal I
> started it from.
> 
Can you indicate which DE do you use? I never see that in KDE.
Papoteur

> Another thing I was concerned about, but didn't test, I had the device and
> an ISO selected, and then I browsed and ejected the device with dolphin. 
> IINM, running dd at this point should be unsuccessful, so I was curious as
> to whether isodumper will repeat the check it makes when it launches to see
> if the USB device is still present before it actually tries to write to it.
> 
We get an error message "You have not the rights for writing on the device", then the application exits.

Hi,

In view of some small bugs for isodumper-0.22 we plan to provide a new release 0.23 in the next few days (we are still waiting for the translation of the part of the translators Team to push this release).

So please wait until further notice, thank you :)


Regards daviddavid

(In reply to papoteur from comment #30)
> Thanks for your deep testing.
> I will look for solutions for each point.
> 
> (In reply to David Walser from comment #27)
> > Testing Mageia i586.  Still some minor issues.
> > 
> > It does start fine, but the window keeps coming up behind the terminal I
> > started it from.
> > 
> Can you indicate which DE do you use? I never see that in KDE.
> Papoteur

KDE.

Assigning back to papoteur for now to make the QA list shorter :-)

Whiteboard: MGA3TOO has_procedure feedback => MGA3TOO has_procedure
Assignee: qa-bugs => yves.brungard_mageia

I just read about Tuxboot:
http://tuxboot.sourceforge.net/

It says it's "modified from Unetbootin."  Wasn't the purpose of this isodumper to have something like Unetbootin but not broken the way Unetbootin is?  Maybe Tuxboot would meet that need?

It seems to be quite limited, you can only choose from a subset of live distros/tools: http://tuxboot.sourceforge.net/images/Tuxboot-sel-dist.png

I'm not sure about the scope either, I think unetbootin and its like are not needed for compatible for Mageia live ISOs, since the latter can be used out of the box once dumped with dd? I might be mistaken though, I don't really know all the nuances in what makes a media bootable.

(In reply to Rémi Verschelde from comment #36)
> It seems to be quite limited, you can only choose from a subset of live
> distros/tools: http://tuxboot.sourceforge.net/images/Tuxboot-sel-dist.png

Ahh, I did notice that in the screenshot, but I wasn't sure if it let you pick a local ISO.  Maybe it would need to be adapted :o(

> I'm not sure about the scope either, I think unetbootin and its like are not
> needed for compatible for Mageia live ISOs, since the latter can be used out
> of the box once dumped with dd? I might be mistaken though, I don't really
> know all the nuances in what makes a media bootable.

That's the brokenness of Unetbootin I was referring to, I was thinking maybe Tuxboot fixes this and also just does dd, but I don't know for sure.

Papoteur and david_david have issued isodumper 0.23, that should fix most of the issues reported in previous tests on this very bug.

Advisories Coming Soonâ¢.

Assignee: yves.brungard_mageia => qa-bugs
Summary: Update Candidate: isodumper 0.22 for Mageia 3 (new package) and Mageia 4 => Update Candidate: isodumper 0.23 for Mageia 3 (new package) and Mageia 4
Source RPM: isodumper-0.22-1.mga3 => isodumper-0.23-1.mga3

Testing x86_64 MGA4

CC: (none) => tarazed25

Tested on Mageia 4 i586 for isodumper-0.23-1.mga4
Everything seems OK. Start with or without root, with or without USB key at startup, with or without backup.

CC: (none) => patr_and

Testing complete on isodumper 0.23 for mga4 x86_64 I think.  isodumper behaved as expected;

request for root password if started as user

immediate notification and exit if no output device available
That is acceptable isn't it?  Easy enough to plug one in and restart.

previously reported problems not seen

backup function worked fine

bootable iso copy test succeeded - copied and then booted on another machine

All tests from the command line but I also tried launching it from the system menus under KDE4, Gnome, Mate, Cinnamon and IceWM.  These were OK except for IceWM - nothing appeared there after clicking or double-clicking.

Query: how to verify that it is "properly localised"?  Does that just mean using the local language?  What else might there be?

Tested mag3_32,

Testing complete for new isodumper-0.23-1.mga3, Ok for me and nothing to report. All functions seems to work properly.

 kde Mga3-64 [ vbox ] : 
 
- isodumper-0.23-1.mga3.noarch
- luit-1.1.1-3.mga3.x86_64
- xterm-291-2.mga3.x86_64

start from system menu -ok, required password as expected
write to usb [ sdd ] -ok

start from console, require password as expected

:** (process:4541): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:4541): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:4541): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Gtk-Message: Failed to load module "canberra-gtk-module"

attempt to create backup but failed: 

Image : /+1/Mageia-4-x86_64-DVD.iso
Target Device: Lexar USB Flash Drive (/dev/sdd) 7646Mb
Backup in: /+1/backup.iso
Image: /+1/Mageia-4-x86_64-DVD.iso
Target Device: Lexar USB Flash Drive (/dev/sdd) 7646Mb
Executing copy from /dev/sdd to /+1/backup.iso
Writing error.

may be because I am using a Vbox.

lxde Mga3-64 [ Vbox ]:

start from system menu- ok, required passord as expected
write to usb - ok
also wrote a backup without being asked

CC: (none) => westel

It will create a 7646Mb-ish backup iso Ben, the size of your USB stick, did you run out of disk space in the VM?

Testing on MGA3-64 (GNOME) Real Hardware


- isodumper-0.23-1.mga3.noarch

Pour satisfaire les dépendances, le ou les paquetages suivants doivent aussi être installés :

- lib64lvm2app2.2-2.02.98-3.mga3.x86_64
- lib64sgutils2-1.34-2.mga3.x86_64
- luit-1.1.1-3.mga3.x86_64
- pygtk2.0-libglade-2.24.0-4.mga3.x86_64
- udisks-1.0.4-10.1.mga3.x86_64
- xterm-291-2.mga3.x86_64

Un espace additionnel de 2.6Mo sera utilisé.


- Verify that you can start IsoDumper as root, and also as normal user (it should then ask for the root password)

Dumping an iso
Backing up USB stick and dumping an iso
Both work as root or as normal user (after giving root passwd)

USB bootable each time with the proper image.


- Verify that it's properly localised

Everything is displayed in French.


- Check that it detect your USB stick if it's plugged in when starting, and also it is plugged in afterwards

Works


- Dump an image to the USB stick while also creating a backup image of the stick's content

OK. 

One thing to be wary though, when backing up several times the content of the usb stick, the default file is the same ("Verbatim0302.iso")and overwrites the former backup without warning.


- Dump an image without creating a backup (you could dump your previous backup)

Works.


As ben mcmonagle had issues with MGA3-64 in virtualbox, I expect some more testing must be done on MGA3-64

CC: (none) => olchal

Did successful partial testing in mga3 32 and 64 and mga4 32 and 64 and mga5a2 64.  "Partial" because I did not test the backup and restore function for the USB stick.  I also did not start from Menu in mga3 KDE because isodumper didn't show up in the menu as far as I could find.  Otherwise, I started from menu and from CLI and got good results.  I changed to loading a different iso each time and each successfully booted in my workstation.  All 5 tries were from hardware installs.

CC: (none) => petel123123

Testing complete mga3 32

Only issue I can see is that the .isodumper directory and log created in the user home is root owned. Perhaps that could be improved in a future update.

I'll validate this now. Sorry it's taken a long time, it's been used by new QA members as a training bug.

Whiteboard: MGA3TOO has_procedure MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK

Validating. Separate advisories from comment 22 & 23 uploaded for mga3 & 4

12702.mga3.adv
12702.mga4.adv

Could sysadmin please push to 3 & 4 updates

Thanks

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK
CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

Unvalidating for now. We may as well include the fox for root owned logs before introducing it as a new package. Adding bug 14207 as depends.

Keywords: validated_update => (none)
Depends on: (none) => 14207

s/fox/fix/

I just tested 0.23, and most of the bugs I reported earlier were fixed.

I still noticed:
- the progress bar when writing goes all the way across, but the progress in the Details window still goes to 33%, so this part still isn't correct
- clicking OK in the dialog that pops up after the write still unexpectedly closes the application.

Again, I tested writing the all.img file that I used in my previous tests.  I still didn't test the backup feature.

I also tested it with all-nonfree.img, and the progress in the Details window stopped at 50% instead of 33%.

Also, when the ~/.isodumper directory doesn't yet exist, when you click OK in the dialog that pops up after the write, you get this error in the console:
Traceback (most recent call last):
  File "/usr/lib/isodumper/isodumper.py", line 356, in close
    self.write_logfile()
  File "/usr/lib/isodumper/isodumper.py", line 371, in write_logfile
    os.chown(home+'/.isodumper')
TypeError: chown() takes exactly 3 arguments (1 given)

I imagine that'll be fixed in the next update for not putting root owned stuff in the user's home directory.  The other issues I mentioned should be fixed too.  Adding the feedback marker for now.

Whiteboard: MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure feedback

Hi,

I think we'll eventually get there with perseverance :) 

A new patch for mga3 and mga4 is now ready for testing !!

Was corrected the following issues:

- Fix wrong progress steps with small images.
- Fix security issue writing log file.



Updated packages in core/updates_testing:
========================
isodumper-0.23-1.1.mga3.noarch
isodumper-0.23-1.2.mga4.noarch

Source RPMs:
isodumper-0.23-1.1.mga3.src.rpm
isodumper-0.23-1.2.mga4.src.rpm

OK, I tested the newest one, and the progress now goes to 99% in the Details/log.  Technically it should be 100%, but 99% is probably OK :o)

On the dialog that pops up at the end, it still unexpectedly closes the application when you hit OK.  I don't think it should do that, but if that's intended, the text in the dialog should be changed to say that it will do that.  The text ends with "when you close the application" which suggests that's something you'll do by choice, not something it will do when you hit OK.  I noticed in the isodumper.mo file some text for that window if there's an error which says "The application will be closed with this window," which at least does match when it does.  So, I'd prefer to not have it close it at all, but if it's going to, using that wording consistently in the success message would be good.

I've verified that the ~/.isodumper and log file are owned by the user, not root.

Finally, I tested the backup feature for the first time.  I haven't verified the integrity of the data it backed up, but I imagine it used dd like it does for writing, so I have no reason to doubt that.  The only thing that's wrong with the backup feature is that it suggests a ".iso" extension for the file it backs up to, but it's just a raw dump, not an ISO that it's creating, so it shouldn't use that extension.  ".img" would be a better choice.

@Luigi12: You last two points in comment 53 are mostly (relevant) enhancement requests, would you agree to let this long standing update be tested and pushed as is, and maybe file issues on papoteur's github repo?

isodumper 0.23 is already a big improvement for Mageia 4, and a great feature for Mageia 3 which is nearing EOL. Even if we all thrive for quality, maybe we shouldn't be too hard on papoteur's already nice tool and let it as is (many of our supported tools are way buggier than isodumper ;-).

Frankly, I've not seen a bug like the OK button closing the application in any other tool.  I don't have a github account, so could you please pass my comments along to papoteur?

Fixing the OK button thing is going to require string updates and new translations one way or another, so that'll need a new isodumper version.  So, given that, I guess it'd be OK to fix it later.

The ".iso" thing is likely to confuse people and should be easy to fix with a small patch, so hopefully we can at least address that one.

Hello,
Thanks Luigi for your comments, they help to have a good tool.
The application closes after the writing because informations are loaded only at launch, and is not updated after the writing. This is why the application is closed, it can not more do anything. However, I will change this behaviour.
I will check if I can get 100%.
I will change also the extension name for backup to .img .

Hi,

A new release 0.24 for mga3 and mga4 is now ready for testing !!

Was corrected the following issues:

- change the name in .img for backup.
- correction of the index not getting 100%.
- not closing the application after the success writing.
- fix wrong progress steps with small images.
- fix security issue writing log file.
- add output on stdout of logs.



Updated packages in core/updates_testing:
========================
isodumper-0.24-1.mga3.noarch
isodumper-0.24-1.mga4.noarch

Source RPMs:
isodumper-0.24-1.mga3.src.rpm
isodumper-0.24-1.mga4.src.rpm

Confirmed the fix for the .img and the 100%, as well as not closing the application from the OK button in the dialog, thanks!

One issue I did notice, and I think I mentioned this much earlier, although I thought it had been fixed (but maybe I didn't check), was if you click the thing to drop down or collapse the Details box, it destroys and redraws the entire window, which it should not have to do.  This becomes more evident if you move the window on the screen, when you drop-down/collapse, the window get redrawn at the center of the screen.

Finally, I haven't checked the code, but does it only do a dd when it writes the image to the USB drive?  If so, it might be a good idea to do an eject as well (i.e., "eject sdb") to make sure the writes get synced to the device.

(In reply to David Walser from comment #58)
> One issue I did notice, and I think I mentioned this much earlier, although
> I thought it had been fixed (but maybe I didn't check), was if you click the
> thing to drop down or collapse the Details box, it destroys and redraws the
> entire window, which it should not have to do.  This becomes more evident if
> you move the window on the screen, when you drop-down/collapse, the window
> get redrawn at the center of the screen.

I will check that, and if I managed something about that.
> 
> Finally, I haven't checked the code, but does it only do a dd when it writes
> the image to the USB drive?  If so, it might be a good idea to do an eject
> as well (i.e., "eject sdb") to make sure the writes get synced to the device.
The tool doesn't use dd, but has its own writing function (see raw_write). The writing is synced at each buffer bit. There no interest to write all and wait finally the syncing.

Mga4-32

test: invoke from  console without usb plugged in. asked for password
plugged usb in - identified.
write to usb  -ok
details correct to 100%
"ok" closes 2nd info window - ok
"close" closes main window -ok

test: invoke from console with usb plugged in. asked for password
write backup and usb
write to backup - ok,label: "name_of_usb_device".img - ok
details correct to 100%
write to usb - ok
details correct to 100%

test: invoke from root console without usb plugged in.
plugged usb in - identified.
write to usb  -ok
details correct to 100%
"ok" closes 2nd info window - ok
"close" closes main window -ok

test: invoke from root console with usb plugged in
write backup and usb
write to backup - ok,label: "name_of_usb_device".img - ok
details correct to 100%
write to usb - ok
details correct to 100%


clicking  detail arrow causes window to be redrawn at centre of screen if not already there - see comment 58

test: invoke from application launcher-no usb plugged in.
requested password and  identified no usb plugged in
plug in usb, refresh - ok
write backup and usb
write to backup - ok,label: "name_of_usb_device".img - ok
details correct to 100%
write to usb - ok
details correct to 100%

note:"write to device " button when invoked from root console has a different icon than when invoked from application launcher.
if invoked from user console or application launcher, they are the same.

Hi,

A new release (0.25) for mga3 and mga4 is now ready for testing.

This new version fixes windows positions as reported in comment 58.


Updated packages in core/updates_testing:
========================
isodumper-0.25-1.mga3.noarch
isodumper-0.25-1.mga4.noarch

Source RPMs:
isodumper-0.25-1.mga3.src.rpm
isodumper-0.25-1.mga4.src.rpm

Summary: Update Candidate: isodumper 0.24 for Mageia 3 (new package) and Mageia 4 => Update Candidate: isodumper 0.25 for Mageia 3 (new package) and Mageia 4
Source RPM: isodumper-0.24-1.mga3 => isodumper-0.25-1.mga3

It's perfect :D.  Nice job!

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA3-32-OK

Tested on Mageia 4 i586.  I noticed something else (sorry!).  When you click the box to choose what image file to write to the drive, it pops up a GUI file-picker (it's the KDE one in my case).  The sidebar shows "root" (as in root's home directory) and "File system" as the locations you can browse to, so if you want to chose an image file in the regular user's home directory (which will probably the case almost all of the time), you have to go File System > home > username.  It should probably run the file-picker dialog as the user so that it'll have their home directory as one of the location choices.  I think this is possible if it runs with the UID=user's UID and EUID=0.

Created attachment 5575 [details]
User description of IsoDumper

CC: (none) => lewyssmith

Damn! In adding the attachment, all my long notes disappeared...

Testing MGA4 x64 real hardware

Confirm that everything previously noted as working *does*; (and faults). I ran IsoDumper from user & root (su) consoles, and menus; with no USB stick inserted beforehand, and inserted at the 'retry' dialogue; writing an ISO; backing up previously and restoring the USB stick.

I would certainly use this now I know it. My penny's worth...

- The biggest obstacle is the total lack of info: no man entry, no command -h help, no dialogue help. Nothing. You can feel your way for writing ISOs, but the very important USB stick backup & restore is cryptic.
[My contribution is in Comment 64].

- From root (only) console, there is a spurious error message:
# isodumper
Error creating proxy: The connection is closed (g-io-error-quark, 18)

- In the RH drop-down destination device list, if there is only one, this could be pre-displayed. There is no choice in this situation.

- When opting for a USB stick backup, the chooser dialogue for the destination img file is correctly located in the user home directory - even after 'su'.

- I like the default backup filename 'GenericFlashDisk.img'. Says it all.

- POTENTIAL bug: If a USB stick backup is requested, is there a check for sufficient disc space? Many Gigabytes are involved.

- When a [prior] backup is checked, the "Write to device" button is alarming. The operation becomes two phases, and this caption applies only to the second one.

- In the same vein, once clicked, the "all data will be lost" pop-up Warning is inappropriate if a [prior] backup is requested. This warning should not be shown in this circumstance.

- Given the good progress bar, outputting a 'details' line every 1% serves nothing. A final xxxx/xxxx would suffice, and indicate any shortfall.

- Brownie point: I deliberately tried a USB stick too small. This caused the  write operation to abort, tidily but without specific info except the log file reference. The last line of that said why. Could such errors be 'tail'ed  directly into the relevant error window? And could this be spotted sooner?

- Another Brownie point: I backed up a real VFAT format USB stick (Gnome beta EFI boot special), and after overwriting the device with an ISO image, restored it. The result was impeccable; booted as it should. Well done!

This is certainly good to go (preferably with a usage note), accepting that small improvements and a new issue soon are fairly certain. Considering David W's & these small doubts, I refrain from MGA4-64-OKing it.

(In reply to Lewis Smith from comment #65)
> - In the RH drop-down destination device list, if there is only one, this
> could be pre-displayed. There is no choice in this situation.

It could be, but I think it's better as-is.  You have to make a conscious choice of selecting that device.  It makes it less likely that you'll overwrite a device that you didn't mean to.

(In reply to David Walser from comment #63)
> Tested on Mageia 4 i586.  I noticed something else (sorry!).  When you click
> the box to choose what image file to write to the drive, it pops up a GUI
> file-picker (it's the KDE one in my case).  The sidebar shows "root" (as in
> root's home directory) and "File system" as the locations you can browse to,
> so if you want to chose an image file in the regular user's home directory
> (which will probably the case almost all of the time), you have to go File
> System > home > username.  It should probably run the file-picker dialog as
> the user so that it'll have their home directory as one of the location
> choices.  I think this is possible if it runs with the UID=user's UID and
> EUID=0.

Thanks for you comment.
The file-picker is, I think, the GTK one. Changing UID or EUID didn't help me to have other default folders in the left pane of file picker. 
What I can do is to add an entry to the user's home. What do you think about that?
Papoteur

(In reply to Lewis Smith from comment #65)

Thanks too for your comments and suggestion.
 
> - The biggest obstacle is the total lack of info: no man entry, no command
> -h help, no dialogue help. Nothing. You can feel your way for writing ISOs,
> but the very important USB stick backup & restore is cryptic.
> [My contribution is in Comment 64].

You're right, we have already a wiki page https://wiki.mageia.org/en/IsoDumper_Writing_ISO_images_on_USB_sticks
but it's not updated. We are still in development phase.
I didn't learn yet how to write man pages and distribute it.

> 
> - From root (only) console, there is a spurious error message:
> # isodumper
> Error creating proxy: The connection is closed (g-io-error-quark, 18)
I saw it, but this does affect the program.

> 
> - In the RH drop-down destination device list, if there is only one, this
> could be pre-displayed. There is no choice in this situation.
Same remark as Luigi.

> - I like the default backup filename 'GenericFlashDisk.img'. Says it all.
It's come from the name of your device.
> 
> - POTENTIAL bug: If a USB stick backup is requested, is there a check for
> sufficient disc space? Many Gigabytes are involved.
No, there is no check for now. This will be added in 0.3x version

> 
> - When a [prior] backup is checked, the "Write to device" button is
> alarming. The operation becomes two phases, and this caption applies only to
> the second one.
Sure
 
> - In the same vein, once clicked, the "all data will be lost" pop-up Warning
> is inappropriate if a [prior] backup is requested. This warning should not
> be shown in this circumstance.
> 
> - Given the good progress bar, outputting a 'details' line every 1% serves
> nothing. A final xxxx/xxxx would suffice, and indicate any shortfall.
Somebody asked me that. This can be discussed.

> - Brownie point: I deliberately tried a USB stick too small. This caused the
> write operation to abort, tidily but without specific info except the log
> file reference. The last line of that said why. Could such errors be
> 'tail'ed  directly into the relevant error window? And could this be spotted
> sooner?
This modification need more translation work. We will avoid that at this point.
The information is present.

(In reply to papoteur from comment #67)
> (In reply to David Walser from comment #63)
> > Tested on Mageia 4 i586.  I noticed something else (sorry!).  When you click
> > the box to choose what image file to write to the drive, it pops up a GUI
> > file-picker (it's the KDE one in my case).  The sidebar shows "root" (as in
> > root's home directory) and "File system" as the locations you can browse to,
> > so if you want to chose an image file in the regular user's home directory
> > (which will probably the case almost all of the time), you have to go File
> > System > home > username.  It should probably run the file-picker dialog as
> > the user so that it'll have their home directory as one of the location
> > choices.  I think this is possible if it runs with the UID=user's UID and
> > EUID=0.
> 
> Thanks for you comment.
> The file-picker is, I think, the GTK one. Changing UID or EUID didn't help
> me to have other default folders in the left pane of file picker. 
> What I can do is to add an entry to the user's home. What do you think about
> that?
> Papoteur

It certainly didn't appear to be the GTK dialog when run under KDE.  Maybe it's using something that will use the appropriate one for whichever desktop you're logged into (probably the GTK one outside of KDE)?  I don't know if there's a generic way to affect the folder choices no matter which desktop you're in (assuming it can use multiple choosers).  It's a shame just changing the UID wasn't enough to fix it, that's surprising.  If there's no easy fix for it, we can certainly validate this as is for now and revisit that later.

In fact, given that we're running out of time for mga3, I'll OK this for mga4.

Whiteboard: MGA3TOO has_procedure MGA3-32-OK => MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK

Papoteur: thanks for responding.

Second thoughts for the future; my twopence worth (some of which is at least worth the discussion about file chooser windows) for this good program.

Re Comment 66: just a matter of opinion, but I note that the well known & respected XFBurn *does* behave as I suggested (showing the only choice for the write device).

Re Comment 68: 
>> Could such errors be 'tail'ed  directly into the relevant error window?
> This modification need more translation work. We will avoid that at this point.
> The information is present.
Point taken. But I am surprised - impressed - that the log file output is translated. (If it were not, the suggestion would stand up: the info is the same whether tail'd into the error window or looked at in situ).

>> From root (only) console, there is a spurious error message:
>> # isodumper
>> Error creating proxy: The connection is closed (g-io-error-quark, 18)
> I saw it, but this does [not] affect the program.
True. But any error msg is disconcerting, and if it is unimportant, certainly better to hide it.

From Comment 65 [left as-is in Comment 68]
> When ... backup is checked, ... the "all data will be lost" pop-up Warning
> is inappropriate ... This warning should not be shown in this circumstance
This is more serious than leaving the 'Write' button as is. You ask for a backup, and are told *before it is done* that all data will be destroyed. This pop-up is surely easy to skip in this situation.

But in line with David W's "I'll OK this for mga4", I see only x32, so adding x64.

Whiteboard: MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK => MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK MGA4-64-OK

Seeing as this is noarch, it has been sufficiently tested to validate it.  We'll need a final advisory put together and uploaded, so we'll need that before this can be pushed.

Sysadmins please push this to Mageia 3 and Mageia 4 updates_testing once the advisory is available.  Thank you.

Keywords: (none) => validated_update

Advisory for Mageia 3 is in comment 22, with the exception of an updated reference to the changelog of isodumper 0.25:
https://github.com/papoteur-mga/isodumper/blob/0.24/CHANGELOG


Advisory for Mageia 4:
========================

Updated isodumper package fixes several bugs and usability issues

  Log files used to be written to the root directory, this has now been fixed.

  Several improvements have been made to the UI regarding window positions
  and closing behaviour.

  See the referenced changelog for a complete list of improvements.

References:
- https://github.com/papoteur-mga/isodumper/blob/0.24/CHANGELOG
========================

Updated packages in core/updates_testing:
========================
isodumper-0.25-1.mga4.noarch

Source RPMs: 
isodumper-0.25-1.mga4.src.rpm

Advisories uploaded as 12702.mga3.adv and 12702.mga4.adv.

Whiteboard: MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK MGA4-64-OK advisory

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2014-0186.html

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

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2014-0187.html