Isodumper for example is not translated in French
Whiteboard: (none) => MGA6TOO, MGA7TOO
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 => 7Whiteboard: MGA6TOO, MGA7TOO => MGA6TOO
Advisory ================================= Previous release missed some translation catalogues This release restore them. =================================
Assigning to QA!
Assignee: geiger.david68210 => qa-bugs
Tested here on mga7 for x86_64, now isodumper is translated again into French!
CC: (none) => geiger.david68210
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
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
(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
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'
CC: (none) => yves.brungard_mageia
@ comment 8: tested on mga6 fully updated to testing.
(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
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?
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 ;)
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
(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.
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. =================================
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
MGA7-64 Plasma in Dutch on Lenovo B50 No installation issues. Language OK, no therr comments.
CC: (none) => herman.viaene
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
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?
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.
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.
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.
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.
Removing the MGA6 OK, as it was for a previous version. If that is in error, feel free to restore it.
CC: (none) => andrewsfarmWhiteboard: MGA6TOO, MGA6-64-OK => MGA6TOO,
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?
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.
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...
> 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.
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.
(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.
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.
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
(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)>
So it is not forgotten, adding the tip here from tmp on discuss list: "eject" informs the kernel that the device should be dismounted, and then the kernel flushes out the block-level writes before dismounting it. So before telling user it is done, issue "eject /dev/sdx" (change x) I think this should be done before verifying it - and then remount it and verify - so it is not cached data we are verifying, but true flash reads. (And lastly ejected again)
(In reply to Morgan Leijström from comment #34) > So it is not forgotten, adding the tip here from tmp on discuss list: > > "eject" informs the kernel that the device should be dismounted, and then > the kernel flushes out the block-level writes before dismounting it. > > So before telling user it is done, issue "eject /dev/sdx" (change x) > > I think this should be done before verifying it - and then remount it and > verify - so it is not cached data we are verifying, but true flash reads. > (And lastly ejected again) I would prefer a separate report as enhancement wish. Don't forget that for now a important feature (translations) is broken and is waiting for this update. Thanks Papoteur
OK: Bug 25347 - Isodumper fail to flush before verify and telling all is done. Not "enhancement" because i think it is worse than translation miss... ;) For the other problems that only I seem to see and only on this machine, i am inclined to let it go, and lets try more later. - Unless there is some progress on that soonish.
There will no be progress soonish about flushing. This update is not a regression against isodumper as released with Mageia 7. I think this update should be released.
Updated o version 1.15 in Mageia 7 Plasma 64-bit. Installation was normal. Ran it, dumped an iso to a usb stick. All looked OK. Good for 64-bit M7.
Whiteboard: MGA6TOO, => MGA6TOO, MGA7-64-OK
Same test with M6, same result. Marking this OK and validating. Suggested advisory in Comment 2, but I'm not sure it is still adequate for all the changes that have been made since this bug was started.
Whiteboard: MGA6TOO, MGA7-64-OK => MGA6TOO, MGA7-64-OK MGA6-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory ================================= Two instances could be launched at the same time, with unexpected results. Now the second instance is stopped. Enumeration of removable drives has been reworked to be more reliable. Previous release missed some translation catalogues This release restore them. =================================
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2019-0113.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED