Description of problem:
According to the github pages qt-fsarchiver and qt-fsarchiver-terminal have to be installed.
In the current M9 alpha round 2 the version of qt-fsarchive is 0.8.5.21. When launched it complains that it needs at least version 0.8.5.10 of qt-fsarchiver-terminal, but this M9 has qt-fsarchiver-terminal 0.8.6.7. qt-fsarchive goes on, but the result is that the possible partitions are not listed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Duplicate of bug 28791?
I've read this time more thoroughly that bug, and yes, I could agree it is a dup. But in Comment 16 you state:
"After removing them (and roughly fiddling with the spec file), qt-fsarchiver-0.8.6.7-1.mga8 builds and the partitions show up properly in the main window."
So why do we have now that older not working version in M9 ???????
DavidG (maintainer) did never update the package in Mga8 or cauldron as this package is a PITA to build, see https://bugs.mageia.org/show_bug.cgi?id=28791#c3
I only fiddled around at this time to find out if it is possible to get this fine piece of software to work...it was possible, but not in a way that it could be provided as a package update. So the package maintainer should decide what to do with this piece of software...
Aaah i found something.
there is a spec file for qt-fsarchiver-0.8.6.7-3 but it was never build or pushed to the mirrors. This change was done 6 months ago..
As papoteur did the last change..cc'ing him..
It was when I was apprentice.
Thus I have now submitted to the build system.
If feedback is OK, then I will apply also the changes to Mageia 8.
qt-fsarchiver-0.8.6.7-3.mga9.x86_64.rpm is now built.
Thank you all for working on this. I remember the original bug about it wanting the terminal installed. I thought it had been fixed...
(In reply to papoteur from comment #5)
> Thus I have now submitted to the build system.
> If feedback is OK, then I will apply also the changes to Mageia 8.
Very encouraging. If you do end up doing the M8 fix, please note that on Bug 28791.
I did a short test under a 64bit Plasma cauldron with qt-fsarchiver-0.8.6.7-3.mga9 and qt-fsarchiver-terminal-0.8.6.7-1.mga9.
The initial problems (mentioned in bug 28791) don't occur. The program starts and partitions are shown. More torough test should be done by Herman and other users who use this software regularly.
BUT: It is not possible to start qt-fsarchiver from the the application menu. It fails because of a wrong link. The application menu entry points to /usr/bin/qt-fsarchiver but the real installation is under /usr/bin/qt-fsarchiver
In the last revision of the spec file, the /usr/bin/ path was removed. This change should be reverted...
(In reply to sturmvogel from comment #8)
> The application menu entry points to
> /usr/bin/qt-fsarchiver but the real installation is under
> In the last revision of the spec file, the /usr/bin/ path was removed. This
> change should be reverted...
Sorry for typo:
the real installation is under /usr/sbin/qt-fsarchiver
A new build is done.
Installing qt-fsarchiver pulled in also fsarchiver, and qt-fsarchiver-terminal whose earlier absence (if not installed) caused it not to work. So that is fixed.
Could not find it in LXDE menus anywhere, so launched it from terminal (qt-fsarchiver). It popped a sudo password box, then a note about where to read ints intructions for use, then the UI. No console errors at all.
The UI showed all partitions on the disc (except swap), which was the original complaint.
For me, this is fixed, with many thanks to all who in the past worked on it, and papoteur for this coup de grace.
Will others on this bug please try it also.
I am for closing *this* Cauldron bug Fixed.
Will you do M8 also? If so, please note on *that* bug. Otherwise we can close it WontFix (saying it is due with M9).
(In reply to Lewis Smith from comment #11)
> The UI showed all partitions on the disc (except swap), which was the
> original complaint.
I meant the original complaint was that it did *not* list the disc partitions, but does now; so that also is fixed.
Where can I download the new versions?
(In reply to Herman Viaene from comment #13)
> Where can I download the new versions?
It is on the cauldron mirrors already...
64 bit Plasma Netinstall Vbox machine:
opens fine (from application menu and terminal)
partitions are shown
One problem (don't know if it is related to my Virtualbox install):
I can close the program just fine via the "x" in the upper right corner of the application window. But if i try to close the application via the "Exit" button in the menu bar or in the application...it completely hangs itself and gets unresponsive. Won't close...
Well, here on real hardware, using LxQt, I can close it no problems using:
- the window title bar menu 'X Close'
- the window title bar top-right 'X'
- the application 'Exit' menu
- the application window 'Exit' button
Oh, this time the first time I launched the application (terminal), I got:
"mkdir: cannot create directory ‘/media/sda3’: File exists"
but not subsequently. Previously, comment 11, I reported "No console errors at all". This is not something to worry about, because the application launches OK. Lots of applications put out disconcerting console messages.
> close the application via the "Exit" button in the menu bar
> or in the application...it completely hangs
This looks a VirtualBox problem. What desktop were you using? I can try that.
@Herman : your response please.
I only have access to QA-updates, I don't do cauldron.
For Mageia 8, this is here:
That bug has some very -ve comments, which preumably apply here too.
In the light of which, I tried (Cauldron):
$ sudo qt-fsarchiver
[sudo] password for lewis:
after which it popped its own password dialogue, then nothing happened, the terminal went unresponsive: Ctrl/C had no effect. I could find nothing 'fsarchiver' with ps to kill, but I was able to close the terminal window.
If this package really gets killed off (see bug 28791), then this bug and that one should be closed 'invalid' or 'wontfix'.
Trying this after a looong break:
Cauldron, LXDE, qt-fsarchiver-0.8.6.7-4.mga9
Cannot find it in menus, but:
works. It starts by popping its sudo password dialogue, after which it displays a fully & correctly populated GUI. Looks good to me.
Can other people (esp Herman) confirm or otherwise?
I have an issue here: I don't do sudo.
Even when I run the qt-fsarchiver as root, the program still asks for a sudo password, so I'm getting nowhere.
Remember: older versions did not require sudo.
Lots of programs ask for this password - basically that of the user, like Debian based systems - like MCC, Isodumper. I do not know of any that actually want the *root* password.
It is true that my own user is also a sudoer; I have not tried:
If you input your *user* password, knowing you do not have sudo - does that work?
In other words can you run it as a normal user who is *not* a sudoer with the user password; or does it really insist on that user being a sudoer?
I hope it is just the wording that is bugging you.
Certainly it complains if you try to run it as root. If it asked for, and worked with, the *user* password, like other programs, would that be OK with you?
No, as root or as normal user I never get beyond the message that the sudo password is not correct.
And "Lots of programs ask for this password " ???? I don't know what SW you are using, but I have yet to come across such ones?
Installing qt-fsarchiver on an i586 m9 vb guest shows the message ...
More information on package qt-fsarchiver-0.8.6.7-4.mga9.i586
Important: This application needs that you have sudo configured for your user.
So testing without sudo configured is not appropriate.
Whether sudo asks for the user password or the root password depends on how
it's configured and what groups the user is a member of.
IIRC being a member of either the wheel or adm groups will make it ask for
root password. Otherwise it asks for the user password. I may be wrong on
the details, but do know that group membership affects sudo password
On i586, with my id in the wheel group (don't forget to logout/in after making
group changes), "sudo ls" is working, qt-fsarchiver starts from konsole, and
displays the partitions ok. It also starts ok from the menu (plasma running)
from the entry under tools/system tools.
I started a test saving the / partition to /tmp and it appears to be working,
but have to cancel it due to lack of space. Exit using the X in the top
right works after confirming canceling the running backup.
On x86_64, sudo was not already installed. Selecting qt-fsarchiver in rpmdrake
In the upgrade information for qt-fsarchiver it does display the message
"Important: This application needs that you have sudo configured for your user."
but it does not install sudo.
So a requires on sudo should be added.
(In reply to Herman Viaene from comment #24)
> And "Lots of programs ask for this password " ???? I don't know what SW you
> are using, but I have yet to come across such ones?
You are right. I get confused by the Mageia habit of demanding the user password to get root-like privileges.
I have just tried creating a new virgin user NOT in sudoers, and could not get past the qt-fsarchiver 'sudoer' password. Certainly the user login password did not work.
I just realise that I did not use MCC for this, with its option to create a privileged user - which might suffice.
Having thought a lot about what is happening, I want to close this bug as it was raised - basically, the program did not work at all; but now it nominally does.
Can you please raise a new bug specifically that to use qt-fsarchiver, you have to be a sudoer. This is not fair: like Herman, you may not want to be; or have to be configured as one. The program cannot currently be run as root, either.
The fix for this debatable, and I think should be in the new bug rather than appended to this more general one. I will try it as a privileged (but not sudoer) user - on the new bug.
(In reply to Dave Hodgins from comment #26)
> In the upgrade information for qt-fsarchiver it does display the message
> "Important: This application needs that you have sudo configured for your
> but it does not install sudo.
> So a requires on sudo should be added.
If we get a new bug just on this issue, this requires may not be necessary.
As per comment 25, it is designed to require using sudo and the README.urpmi
file says so. Testing or expecting it to work without sudo is not appropriate.
It should have a requires for sudo, but that's all thats needed to get it to
work in m8. Note that it can not work with ext4 partitions created by m9 and
does not work in m9 because of that.
qt-fsarchiver does not work properly, there is an issue with versions of qt-fsarchiver and qt-fsarchiver-terminal =>
qt-fsarchiver have issues with versions of qt-fsarchiver, qt-fsarchiver-terminal, ext4 versionsCC:
No-one wants a new bug, so this one mutates.
I have just had a look at the parallel bug 28791 - currently 45 comments!. And commenters adding to both bugs.
The M8 situation is I think the same as for M9, which currently comes down to:
* The bizarre password requirement, but Herman has noted how to get round the current need to be a sudoer:
* It does not cope with M9 ext4 partitions:
We have seen this restriction before, forget where. This will be serious, and is very much UPSTREAM.
* No menu entry.
FOR_ERRATA9, IN_ERRATA8Status comment:
Update Errata 8 when out of testing
Thanks for that Morgan.
Update Errata 8 when out of testing =>
If we have to leave this open, we should not leave it with Bugsquad. Assign to pkg-bugs?
And what is the situation with fsarchiver itself?
qt-fsarchiver have issues with versions of qt-fsarchiver, qt-fsarchiver-terminal, ext4 versions =>
qt-fsarchiver wants a sudo password; and does not handle Mageia 9 enhanced ext4
fsarchiver works well, except for the C12 ext4 feature.
This is the best it can get :)
Please don't mix fsarchiver with qt-fsarchiver. qt-fsarchiver bundles its own copy of fsarchiver. I don't really even know why qt-fsarchiver requires fsarchiver.
fsarchiver supports EXT4 orphan_file since 0.8.7 . Unfortunately we only have 0.8.6 ATM, but the support can be patched also to 0.8.6.
Thank you for the enlightenment.
Well then, created
Bug 32137 - fsarchiver update for EXT4 orphan_file feature
I think that if we update qt-fsarchiver, we should try to make it not require fsarchiver. OR have it use the separate package instead of bundled.
It seems strange to me that qt-fsarchiver bundles its own copy of fsarchiver, rather than using the stand-alone product.
As it stands, qt-fsarchiver certainly formally requires fsarchiver. If any follower of this bug (Herman?) uses qt-fsarchiver, and presumably has fsarchiver installed as a dependency, please try removing just pkg fsarchiver with
rpm --nodeps ...
and see whether qt-fsarchiver still works.
It may be that qt-fsarchiver requires indirectly pkgs required directly by fsarchiver, and requires the latter to get them.
I agree with Morgan's last comment above; prefering the second option. But is that an upstream matter? If it is, we have to leave well alone, and drop if possible the requirement from qt-fsarchiver for fsarchiver.
(In reply to Morgan Leijström from comment #33)
> fsarchiver works well, except for the C12 ext4 feature.
> This is the best it can get :)
We deactivated this feature from default formatting in Mageia 9, to avoid such problems. This will probably be activated in future.
qt-fsarchiver wants a sudo password; and does not handle Mageia 9 enhanced ext4 =>
qt-fsarchiver wants a sudo password; and does not handle future enhanced ext4
I'd forgotten that running qt-fsarchiver after using "su -" to become root
After recovering from having various gui programs such as ktorrent left
running without the gui working, I tested qt-fsarchiver again.
qt-fsarchiver does work in m8 without having fsarchiver installed. I didn't
test restoring, just archiving.
(In reply to Lewis Smith from comment #36)
> It seems strange to me that qt-fsarchiver bundles its own copy of
> fsarchiver, rather than using the stand-alone product.
> As it stands, qt-fsarchiver certainly formally requires fsarchiver. If any
> follower of this bug (Herman?) uses qt-fsarchiver, and presumably has
> fsarchiver installed as a dependency, please try removing just pkg
> fsarchiver with
> rpm --nodeps ...
> and see whether qt-fsarchiver still works.
> It may be that qt-fsarchiver requires indirectly pkgs required directly by
> fsarchiver, and requires the latter to get them.
> I agree with Morgan's last comment above; prefering the second option. But
> is that an upstream matter? If it is, we have to leave well alone, and drop
> if possible the requirement from qt-fsarchiver for fsarchiver.
fsarchiver is certainly not required by qt-fsarchiver.
qt-fsarchiver requires qt-fsarchiver-terminal which is basically a copy of fsarchiver built from bundled fsarchiver sources.
(In reply to Jani Välimaa from comment #39)
> fsarchiver is certainly not required by qt-fsarchiver.
In theory, no. But currently:
$ urpmq --requires qt-fsarchiver | grep fsarchiver
so should not the superfluous 'requires' of 'fsarchiver' by 'qt-fsarchiver' be removed?
> qt-fsarchiver-terminal which is basically a copy of fsarchiver
> built from bundled fsarchiver sources
And for qt-fsarchiver-terminal ? :
$ urpmq --requires qt-fsarchiver-terminal | grep fsarchiver
$ urpmq --whatrequires fsarchiver