Spec URL: https://raphgro.fedorapeople.org/review/qt/qparted/qparted.spec SRPM URL: https://raphgro.fedorapeople.org/review/qt/qparted/qparted-0.6.1-0.1.20141001gitd53d64f.fc21.src.rpm Description: Visual partition editor based on Qt framework Fedora Account System Username: raphgro rawhide: https://copr-be.cloud.fedoraproject.org/results/raphgro/playground/fedora-rawhide-x86_64/qparted-0.6.1-0.1.20141001gitd53d64f.fc21/ Open issues: - Desktop icon not visible in Cinnamon (and other DE?). That's low priority due to qparted will be used mostly for the lxqt spin. - Support for usermode (consolehelper) is discouraged. Therefore it is disabled in spec file. - Upstream should provide a proper and complete Makefile rule for install (via qmake).
qtparted seems to be stalled due to inactive upstream. So I decided to package the fork from github. Mostly cause we need a mostly complete partition editor for the new LXQt spin.
rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=8822097
qparted doesn't look all that active either, but at least it's not completely dead for years like upstream qtparted.
# FIXME Qt5? Just tested if it would build with Qt5, but it doesn't. So for the time being you don't have to bother with it. I think it still needs some work. The application window title refers to "QtParted" instead of "Qparted". This is confusing. Moreover, the tarball contains *.ts files which are not compiled and installed as *.ts yet. (In reply to Raphael Groner from comment #1) > Mostly cause we need a mostly complete partition editor for > the new LXQt spin. Is a partition editor really a basic part of a graphical desktop environment? Besides the need to work with partitions during the installation, it is actually not needed. I would discourage everybody to change partitions while the system is running, and this wouldn't work anyway on all partitions. The better way is to boot a live medium. Then it doesn't matter whether a Qt or GTK or whatever based partition editor is used. To summarize, Qparted doesn't have any advantages, and in fact it is just as dead as Qtparted. In the Github repo I see only the initial commits and quite a few fixes (mostly referring to the name change), but no real progress.
(In reply to Mario Blättermann from comment #4) > contains *.ts files which are not compiled and installed as *.ts yet. > Of course I meant "installed as *.qm".
Consistently, use %{qmake_qt4} instead of %{_qt4_qmake} here as well, as stated in https://bugzilla.redhat.com/show_bug.cgi?id=1187869#c2 .
NotReady cause some upstream work required before can continue with the review, see comment #4 for details.
(In reply to Mario Blättermann from comment #4) … > I think it still needs some work. The application window title refers to > "QtParted" instead of "Qparted". This is confusing. Reported to upstream: https://github.com/ZZYZX/qparted/issues/3 > Moreover, the tarball contains *.ts files which are not compiled and installed as *.ts yet. Not sure about what you mean. Those *.ts files seem to get build into the binary via QML magically. I've done a smoke test and get a german UI, so I assume localization to work well. - General discussion about Qt5 and a need for any partition editor should not go into this bug meant as a review request. Thanks a lot for your help.
(In reply to Raphael Groner from comment #8) > > Moreover, the tarball contains *.ts files which are not compiled and installed as *.ts yet. > > Not sure about what you mean. Those *.ts files seem to get build into the > binary via QML magically. I've done a smoke test and get a german UI, so I > assume localization to work well. > I didn't get a German interface... Normally, *.ts files will be compiled with lrelease (from the Qt Linguist toolchain) and the *.qm ones installed in %{_datadir}/%{name}/locale/*. > General discussion about Qt5 and a need for any partition editor should not > go into this bug meant as a review request. Yes, you are right. But mentioning Qt5 was only responding to the FIXME line in your spec. Well, would be nice to see any progress upstream, but for the time being there's no advantage in comparison with Qtparted.
There are a lot of open bugs for qtparted. Mario, can you reproduce especially bug #885365 (fail with USB stick in general)?
(In reply to Raphael Groner from comment #10) > Mario, can you reproduce especially bug #885365 (fail with USB stick in > general)? If you mean whether this is also the case in qparted: Yes, it is impossible to do anything with an USB stick. Just tried the following: Connected a 4GB stick with a FAT32 filesystem. The device will be mounted automatically. Qparted doesn't detect the stick only if it is already connected (and mounted!) when Qparted starts. Then, Qparted is unable to unmount it, this has to be done manually. Similar to Gparted, I can delete the partition virtually and click then on File → Commit to apply the changes. Result: Qparted crashes. Terminal output: Backtrace has 20 calls on stack: 20: /lib64/libparted.so.2(ped_assert+0x44) [0x3689e0d2f4] 19: /lib64/libparted.so.2() [0x3689e120f8] 18: qparted() [0x445fa6] 17: qparted() [0x41ce66] 16: qparted() [0x440d8c] 15: qparted() [0x42fa5b] 14: qparted() [0x44dac2] 13: /lib64/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x32c) [0x33bff9a25c] 12: /lib64/libQtGui.so.4(_ZN7QAction9activatedEi+0x41) [0x368a5c1871] 11: /lib64/libQtGui.so.4(_ZN7QAction8activateENS_11ActionEventE+0x9c) [0x368a5c332c] 10: /lib64/libQtGui.so.4() [0x368aa1504d] 9: /lib64/libQtGui.so.4() [0x368aa19a09] 8: /lib64/libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x298) [0x368a61b118] 7: /lib64/libQtGui.so.4(_ZN5QMenu5eventEP6QEvent+0x6b) [0x368aa1d9db] 6: /lib64/libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x8c) [0x368a5c7efc] 5: /lib64/libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x41f) [0x368a5ceabf] 4: /lib64/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8d) [0x33bff8570d] 3: /lib64/libQtGui.so.4(_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb+0x15f) [0x368a5ce11f] 2: /lib64/libQtGui.so.4() [0x368a6448ca] 1: /lib64/libQtGui.so.4(_ZN12QApplication15x11ProcessEventEP7_XEvent+0x60c) [0x368a642f2c] A bug has been detected in GNU Parted. Refer to the web site of parted http://www.gnu.org/software/parted/parted.html for more information of what could be useful for bug submitting! Please email a bug report to bug-parted containing at least the version (3.2) and the following message: Assertion (old_disk != NULL) at disk.c:255 in function ped_disk_duplicate() failed. Aborted (core dumped) It's obviously no bug in Qparted, rather in GNU parted. But probably Gparted handles USB media differently, so that it works there.
USB storage is currently not supported. That is a show stopper for this review. https://github.com/ZZYZX/qparted/issues/4
Mario, please try to reproduce comment #11 in Fedora 22. I could access my stick with QtParted but it's retired cause of dead upstream (log of 2015-06-10).
Upstream seems nearly dead.