Bug 25173 - Only few translation catalogs are embedded in isodumper + hinder more than one instance
Summary: Only few translation catalogs are embedded in isodumper + hinder more than on...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA6TOO,
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-23 09:13 CEST by papoteur
Modified: 2019-08-20 18:52 CEST (History)
5 users (show)

See Also:
Source RPM: isodumper-1.09
CVE:
Status comment:


Attachments
Running two instances of isodumper, both failes. (172.77 KB, image/png)
2019-07-27 00:45 CEST, Morgan Leijström
Details
IsoDumper lists one additional stick, both as "sde", Updating broken (28.94 KB, image/png)
2019-07-31 18:24 CEST, Morgan Leijström
Details
Empty error popup, v1.13 (65.26 KB, image/png)
2019-08-06 12:00 CEST, Morgan Leijström
Details

Description papoteur 2019-07-23 09:13:14 CEST
Isodumper for example is not translated in French
papoteur 2019-07-23 09:14:20 CEST

Whiteboard: (none) => MGA6TOO, MGA7TOO

Comment 1 David GEIGER 2019-07-24 16:23:38 CEST
So list of packages:


Packages in 6/core/updates_testing:
========================
isodumper-1.10-1.mga6.noarch.rpm
isodumper-qt-1.10-1.mga6.noarch.rpm
isodumper-gtk-1.10-1.mga6.noarch.rpm

Source RPM:
========================
isodumper-1.10-1.mga6.src.rpm



Packages in 7/core/updates_testing:
========================
isodumper-1.10-1.mga7.noarch.rpm
isodumper-qt-1.10-1.mga7.noarch.rpm
isodumper-gtk-1.10-1.mga7.noarch.rpm

Source RPM:
========================
isodumper-1.10-1.mga7.src.rpm

Version: Cauldron => 7
Whiteboard: MGA6TOO, MGA7TOO => MGA6TOO

Comment 2 papoteur 2019-07-24 16:33:35 CEST
Advisory
=================================
Previous release missed some translation catalogues
This release restore them.
=================================
Comment 3 David GEIGER 2019-07-24 18:10:31 CEST
Assigning to QA!

Assignee: geiger.david68210 => qa-bugs

Comment 4 David GEIGER 2019-07-24 18:13:52 CEST
Tested here on mga7 for x86_64, now isodumper is translated again into French!

CC: (none) => geiger.david68210

Comment 5 Morgan Leijström 2019-07-27 00:37:52 CEST
On mga6 yay swedish is back :)
(I had forgotten it once was translated)

Not fully translated though, is it supposed to be?

CC: (none) => fri

Comment 6 Morgan Leijström 2019-07-27 00:45:45 CEST
Created attachment 11218 [details]
Running two instances of isodumper, both failes.

I found an issue i have not tried for before:
An an attempt at being efficient i started two instances, each from separate konsole tabs under Plasma, to burn two different isos to two different USB sticks: both failed! - see attached screenshot;

Both writes fully, but then:

One get mismatch checking the content (but continues making persistence partition anyway)

The other never start checking and i had to close it with Ctrl-C in konsole.


Isodumper should either block starting more than one instance, or handle it.

isodumper-1.10-1.mga6
Comment 7 Morgan Leijström 2019-07-27 00:49:56 CEST
(In reply to Morgan Leijström from comment #5)
> Not fully translated though, is it supposed to be?

__Seen untranslated:
/!\The computed and stored sums don't match
The sha512 sum check is OK and the sum is signed
Adding persistent partition
Added persistent partition
Comment 8 Morgan Leijström 2019-07-29 09:28:01 CEST
Isodumper 1.11 from testing now:

bash-4.3$ isodumper
Traceback (most recent call last):
  File "/bin/isodumper", line 2, in <module>
    from isodumper import isodumper
  File "/usr/lib/python3.5/site-packages/isodumper/isodumper.py", line 51, in <module>
    import psutil
ImportError: No module named 'psutil'
Morgan Leijström 2019-07-29 09:28:50 CEST

CC: (none) => yves.brungard_mageia

Comment 9 Morgan Leijström 2019-07-29 09:46:20 CEST
@ comment 8: tested on mga6 fully updated to testing.
Comment 10 David GEIGER 2019-07-29 14:19:18 CEST
(In reply to Morgan Leijström from comment #8)
> Isodumper 1.11 from testing now:
> 
> bash-4.3$ isodumper
> Traceback (most recent call last):
>   File "/bin/isodumper", line 2, in <module>
>     from isodumper import isodumper
>   File "/usr/lib/python3.5/site-packages/isodumper/isodumper.py", line 51,
> in <module>
>     import psutil
> ImportError: No module named 'psutil'

Should be fixed now!

So list of new updated packages:


Packages in 6/core/updates_testing:
========================
isodumper-1.11-1.1.mga6.noarch.rpm
isodumper-qt-1.11-1.1.mga6.noarch.rpm
isodumper-gtk-1.11-1.1.mga6.noarch.rpm

Source RPM:
========================
isodumper-1.11-1.1.mga6.src.rpm



Packages in 7/core/updates_testing:
========================
isodumper-1.11-1.1.mga7.noarch.rpm
isodumper-qt-1.11-1.1.mga7.noarch.rpm
isodumper-gtk-1.11-1.1.mga7.noarch.rpm

Source RPM:
========================
isodumper-1.11-1.1.mga7.src.rpm
Comment 11 Morgan Leijström 2019-07-29 18:17:37 CEST
bash-4.3$ isodumper
Traceback (most recent call last):
  File "/bin/isodumper", line 5, in <module>
    app = isodumper.IsoDumper()
  File "/usr/lib/python3.5/site-packages/isodumper/isodumper.py", line 448, in __init__
    raise(Exception(_("There is another instance of Isodumper already running.")))
Exception: There is another instance of Isodumper already running.


So i guess the problem about it failing if more than one instance is launched  described in comment #6 now is mitigated.


Problem 1: Launching it from menu or icon etc: the exception is not visible!


Problem 2: If it happens like for me that it once failed, how can a user override it?  Not even a reboot helped.  Remedy shopuld be described in the message.  Or can the mechanism be improved to look for an actual running instance instead?
Comment 12 Morgan Leijström 2019-07-30 11:41:37 CEST
Isodumper 1.12 from testing now:

(In reply to Morgan Leijström from comment #11)
> Problem 1: Launching it from menu or icon etc: the exception is not visible!

Fixed: i get a popup window (running in Plasma)


> Problem 2: If it happens like for me that it once failed, how can a user
> override it?

Fixed: I did not have to to anything, just upgraded to 1.12.  It now start without problem a first instance. Trying to start another i get a popup.  Closing both, i can then launch one again.

Oh now i see 1.13 sowed up now... To be continued ;)
Comment 13 Morgan Leijström 2019-07-30 11:43:52 CEST
What is to be tested now?

Summary: Only few translation catalogs are embedded in isodumper => Only few translation catalogs are embedded in isodumper + hinder more than one instance

Comment 14 papoteur 2019-07-30 11:46:04 CEST
(In reply to Morgan Leijström from comment #12)
> 
> Oh now i see 1.13 sowed up now... To be continued ;)

Hello,
1.12 missed the last translation catalogues. There no other update in 1.13, which is to test.
David will add rpm references.
Comment 15 papoteur 2019-07-30 11:48:14 CEST
Advisory
=================================
Two instances could be launched at the same time, with unexpected results.
Now the second instance is stopped.
Previous release missed some translation catalogues
This release restore them.
=================================
Comment 16 Morgan Leijström 2019-07-30 12:55:53 CEST
mga6 64 bit
OK: More language: swedish
OK: Popup when trying to start more than one instance
OK: Writes mga7 iso to stick, with persistence

Whiteboard: MGA6TOO => MGA6TOO, MGA6-64-OK

Comment 17 Herman Viaene 2019-07-30 15:34:46 CEST
MGA7-64 Plasma in Dutch on Lenovo B50
No installation issues.
Language OK, no therr comments.

CC: (none) => herman.viaene

Comment 18 David GEIGER 2019-07-30 18:19:36 CEST
So, one more the list of new updated packages:


Packages in 6/core/updates_testing:
========================
isodumper-1.13-1.mga6.noarch.rpm
isodumper-qt-1.13-1.mga6.noarch.rpm
isodumper-gtk-1.13-1.mga6.noarch.rpm

Source RPM:
========================
isodumper-1.13-1.mga6.src.rpm



Packages in 7/core/updates_testing:
========================
isodumper-1.13-1.mga7.noarch.rpm
isodumper-qt-1.13-1.mga7.noarch.rpm
isodumper-gtk-1.13-1.mga7.noarch.rpm

Source RPM:
========================
isodumper-1.13-1.mga7.src.rpm
Comment 19 Morgan Leijström 2019-07-31 18:24:40 CEST
Created attachment 11230 [details]
IsoDumper lists one additional stick, both as "sde", Updating broken

See attachment screenshot "IsoDumper shows two sde":

I plugged in  the "SMI USB DISK", then launched IsoDumper.
The "SMI USB DISK" is the only stick actually plugged in.
Also fdisk say that only that stick is connected.

Still IsoDumper lists two sticks - as same drive, /dev/sde which is weird.

The list remains the same even if i close and open IsoDumper, and also if i press "Update" button.  I have been using the two sticks it lists repeatedly since last reboot, and also two sticks not listed.


When i now removed the stick and pressed Update, the list is empty.
When i plug it in again the list show both entries again.

Is this some internal function or can i try to look at wherever it gets the erroneous info from?
Comment 20 Morgan Leijström 2019-07-31 19:42:33 CEST
I fetched that SanDisk Extreme and putting in that too, and pressing Update, both are listed and the latter as sdf which is OK.

Now removing SanDisk Extreme  and pressing Update, it do vanish from list.

So there is some occasional glitch... IsoDumper, kernel, or other thing?

Have not seen this before.

Hmmm, i put it in a USB2 slot this time, but before comment 19 i used it in a USB3 port and it is a USB3+2 stick.
Comment 21 papoteur 2019-07-31 22:22:20 CEST
Hi Morgan,
The information comes from Udisk2, but not directly. It needs two passes to find the device path, and perhaps something is not clean here.
Comment 22 Morgan Leijström 2019-08-06 12:00:28 CEST
Created attachment 11243 [details]
Empty error popup, v1.13

Another quirk:
Today i get empty error message;

I put the stick in,
launched isodumper from the terminal in dolphin,
in isodumper selected the stick and iso file,
pressed button to write, and entered my user pwd,
-> Immediately an empty error message appears!

I will try more later, gotta go now.
Comment 23 Morgan Leijström 2019-08-06 12:17:42 CEST
That was on mga6 64 bit.
Also tested to remove the stick and try again.
Also tested to login as root in terminal, then lunch isodumper.
All the same.
Then writing the stick using dd was no problem, and system boots on stick.
Comment 24 Thomas Andrews 2019-08-18 03:02:52 CEST
Removing the MGA6 OK, as it was for a previous version. If that is in error, feel free to restore it.

Whiteboard: MGA6TOO, MGA6-64-OK => MGA6TOO,
CC: (none) => andrewsfarm

Comment 25 Morgan Leijström 2019-08-18 16:15:31 CEST
I still get that empty error message on my workstation :/ But it may be something is borked on that machine.

On my wifes laptop it works OK.  Same versions installed of everything it needs, both are 64 bit and Plasma...

How does it work for other people?
Comment 26 papoteur 2019-08-19 10:16:28 CEST
Hi Morgan,
I think that the message is that you provide the bad password, it should be the root password. I agree that the behaviour shouldn't be this one. The message should be "Access denied", but it is reset before to be displayed.
You can have a look to /var/log/magiback.log to have perhaps some information about what is wrong. But this part is not yet detailed.
I prepare a new release which enumerates devices in a better manner, I hope, with more debugging information, and which restores displying the "Access denied" message. I'm waiting for my preferred packager who is atm in holidays.
Comment 27 Morgan Leijström 2019-08-20 03:27:49 CEST
Somehow i have it set up so it ask my personal login.
If i enter root pwd it say it is wrong.
When i enter the correct pwd i get empty message and the following in log.  Why is it using server pgp.mit.edu ?


bash-4.3$ tail -f /var/log/magiback.log                                                                                                   
...
DEBUG:gnupg:recv_keys: ('EDCA7A90',)                                                                        
DEBUG:gnupg:21137: gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --keyserver pgp.mit.edu --recv-keys EDCA7A90
DEBUG:gnupg:data copier: <Thread(Thread-19, initial daemon)>, <_io.BytesIO object at 0x7fd873247f68>, <_io.BufferedWriter name=9>
DEBUG:gnupg:closed output, 0 bytes sent                                                                     
DEBUG:gnupg:stderr reader: <Thread(Thread-20, initial daemon)>                                              
DEBUG:gnupg:stdout reader: <Thread(Thread-21, initial daemon)>                                              
DEBUG:gnupg:gpg: requesting key EDCA7A90 from hkp server pgp.mit.edu                                        
DEBUG:gnupg:gpg: no valid OpenPGP data found.                                                               
DEBUG:gnupg:[GNUPG:] NODATA 1                                                                               
DEBUG:gnupg:gpg: Total number processed: 0                                                                  
DEBUG:gnupg:[GNUPG:] IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0                                                 
DEBUG:gnupg:gpg: keyserver communications error: keyserver helper general error                             
DEBUG:gnupg:gpg: keyserver communications error: unknown pubkey algorithm                                   
DEBUG:gnupg:gpg: keyserver receive failed: unknown pubkey algorithm                                         
DEBUG:gnupg:chunk: b"gpgkeys: key EDCA7A90 can't be retrieved\n"                                            
DEBUG:gnupg:recv_keys result: {'imported_rsa': 0, 'results': [{'problem': '0', 'text': 'No valid data found', 'fingerprint': None}], 'n_sigs': 0, 'gpg': <gnupg.GPG object at 0x7fd877eae9b0>, 'data': b"gpgkeys: key EDCA7A90 can't be retrieved\n", 'fingerprints': [], 'imported': 0, 'sec_dups': 0, 'unchanged': 0, 'not_imported': 0, 'sec_imported': 0, 'n_revoc': 0, 'sec_read': 0, 'n_subk': 0, 'count': 0, 'no_user_id': 0, 'n_uids': 0, 'stderr': 'gpg: requesting key EDCA7A90 from hkp server pgp.mit.edu\ngpg: no valid OpenPGP data found.\n[GNUPG:] NODATA 1\ngpg: Total number processed: 0\n[GNUPG:] IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0\ngpg: keyserver communications error: keyserver helper general error\ngpg: keyserver communications error: unknown pubkey algorithm\ngpg: keyserver receive failed: unknown pubkey algorithm\n'}


That said, there may be some strange quirk in my system, as i downgraded to isodumper 1.09 and same behaviour in that version now!

My CPU got old and crashed my system several times more and more often for months until i realised it was not the OS nor memsticks, but the CPU. It is now replaced and the system runs nicely.  But i wonder how much damage it did to any files before i replaced it...
Comment 28 papoteur 2019-08-20 11:15:17 CEST
>  Why is it using server pgp.mit.edu ?
It is used for loading the Mageia's signature, and then check the ISO signature.

The root password is what is needed. How does it say that the password is wrong? If the behaviour is not the same as when you enter user passaword, (blank window) there is still an error elsewhere.
Comment 29 Morgan Leijström 2019-08-20 12:23:45 CEST
Hmm i was using a non-mageia iso.

I use my user password to get into mcc, diskdrake etc, and I believe I am supposed to use it for diskdrake too?

For isodumper launched as normal user, if I enter root password in the dialogue it displays in a red rounded background that password check failed, try again.  There is no output at all in the log file.  If I then enter my user password or just press abort button abort I get the same empty error message, no diference.

And yes I remember the root password correctly, and I can su and then launch isodumper as root.  Then it do not ask for password, but I get the empty error dialogue immediately when I press the write button.

It is problem on this computer and not my other, and it happened recently, and also happens after downgrade to isodumper 1.09.  This system is updated to testing *except* python3-urllib3 https://bugs.mageia.org/show_bug.cgi?id=23880#c9. It may be something else than isodumper that is broken.
Comment 30 Thomas Andrews 2019-08-20 13:37:07 CEST
(In reply to Morgan Leijström from comment #29)
> Hmm i was using a non-mageia iso.
> 
> I use my user password to get into mcc, diskdrake etc, and I believe I am
> supposed to use it for diskdrake too?
> 

Is your user part of the wheel group? I've heard that can cause unusual permission problems with some apps.

A thought... Try creating a new user - Bit Twister would say to call him "junk" - making sure he doesn't belong to any extra groups, and see if the same behavior applies to him. That will tell us if the problem is system-wide or just with the one user.
Comment 31 Morgan Leijström 2019-08-20 16:22:44 CEST
Created a new user, who is only member of his own group, rebooted, logged in as that user -> Same behaviour.

Also tested removing me from wheel, no change.
Comment 32 papoteur 2019-08-20 17:14:52 CEST
1.15 release is coming in testing.
>this new release enumerates devices in a better manner, with more debugging information, and restores displaying the "Access denied" message. 

To be sure that this new release is used after installation, launch as root :
systemctl restart magiback.service
Comment 33 Morgan Leijström 2019-08-20 18:52:52 CEST
(In reply to papoteur from comment #28)
> >  Why is it using server pgp.mit.edu ?
> It is used for loading the Mageia's signature, and then check the ISO
> signature.

IIUC all Mageia isos file names starts with "Mageia-" so maybe it only need to lookup such files, and not trying to look for other isos?

------

isodumper 1.15, restarted magiback.service

The error dialog now show "Reading error./home/morgan/Hämtningar/Mageia-7.1-netinstall-nonfree-i586.iso" 

And other files give corresponding results.  I also tried chmod 777 on it, reseating USB, using another USB although it should not matter...


In log: 
2019-08-20 18:42:38 DEBUG    31157: gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --keyserver pgp.mit.edu --recv-keys EDCA7A90                 
2019-08-20 18:42:38 DEBUG    data copier: <Thread(Thread-26, initial daemon)>, <_io.BytesIO object at 0x7f0efc623678>, <_io.BufferedWriter name=9>                               
2019-08-20 18:42:38 DEBUG    closed output, 0 bytes sent                                                                                                                         
2019-08-20 18:42:38 DEBUG    stderr reader: <Thread(Thread-27, initial daemon)>                                                                                                  
2019-08-20 18:42:38 DEBUG    stdout reader: <Thread(Thread-28, initial daemon)>

Note You need to log in before you can comment on or make changes to this bug.