Red Hat Bugzilla – Bug 1208911
Review Request: doublecmd - Twin-panel (commander-style) file manager
Last modified: 2017-12-12 18:32:30 EST
Spec URL: https://raphgro.fedorapeople.org/review/qt/doublecmd-qt/doublecmd-qt.spec SRPM URL: https://raphgro.fedorapeople.org/review/qt/doublecmd-qt/doublecmd-qt-0.6.1-1.20150402svn5941.fc21.src.rpm Description: Twin-panel (commander-style) file manager (Qt4) Fedora Account System Username: raphgro rawhide scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=9408616 ==> ERROR: Broken dependency: KASComp 1.8>KASComp 1.8 f22 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=9408636 ==> OK As a base doublecmd-gtk.spec from vondruch is used cause the links in the original request (bug #989791) are dead. There are some rpmlint errors about the plugin binaries. Not sure how to fix, help would be very appreciated. +++ This bug was initially created as a clone of Bug #989791 +++ Spec URL: http://cicku.me/doublecmd-qt4.spec SRPM URL: http://cicku.me/doublecmd-qt4-0.5.6-1.fc20.src.rpm Description: Double Commander is a cross platform open source file manager with two panels side by side. It is inspired by Total Commander and features some new ideas. Here are some key features of Double Commander: - Unicode support - All operations working in background - Multi-rename tool - Tabbed interface - Custom columns - Internal text editor (F4) with syntax hightlighting - Built in file viewer (F3) to view files of in hex, binary or text format - Archives are handled like subdirectories. You can easily copy files to and from archives. Supported archive types: ZIP, TAR GZ, TGZ, LZMA and also BZ2, RPM, CPIO, DEB, RAR. - Extended search function with full text search in any files - Configurable button bar to start external programs or internal menu commands - Total Commander WCX, WDX and WLX plug-ins support - File operations logging Fedora Account System Username: cicku --- Additional comment from Mario Blättermann on 2013-08-04 21:58:56 CEST --- A *.desktop file needs to be installed explicitely or validated: http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage Besides that, desktop-file-utils are needed as a build requirement. The package contains the file /usr/bin/doublecmd. The same file is in the package doublecmd-gtk2 (bug #989792), which would cause a package conflict. You have added a Conflicts: tag to both packages, but I wouldn't recommend this really. You should try to package both from the same source rpm instead and rename the files appropriately. If you would do so, you could move the files shared between the two versions to a -common subpackage (noarch), such as docs, icons, man pages, wherever possible. --- Additional comment from Christopher Meng on 2013-08-05 03:21:50 CEST --- (In reply to Mario Blättermann from comment #1) > A *.desktop file needs to be installed explicitely or validated: > http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage Fixed. > The package contains the file /usr/bin/doublecmd. The same file is in the > package doublecmd-gtk2 (bug #989792), which would cause a package conflict. > You have added a Conflicts: tag to both packages, but I wouldn't recommend > this really. You should try to package both from the same source rpm instead > and rename the files appropriately. If you would do so, you could move the > files shared between the two versions to a -common subpackage (noarch), such > as docs, icons, man pages, wherever possible. I understand your meaning, but the fact is that Lazarus only supports one widgetset(gtk2 or qt) in one time, so I cannot build them in one src rpm, ./build.sh beta qt if then I run ./build.sh beta gtk2, the newly built things will override the generated qt files. This also happen in another package I haven't submitted. --- Additional comment from Michael Schwendt (Fedora Packager Sponsors Group) on 2013-08-05 10:23:18 CEST --- At the end of %prep you could copy the builddir contents to a second builddir. --- Additional comment from Christopher Meng on 2013-08-05 11:11:30 CEST --- (In reply to Michael Schwendt from comment #3) > At the end of %prep you could copy the builddir contents to a second > builddir. After consulting with upstream, they said that I can use another way: ./build.sh beta gtk2 ./build.sh save gtk2 and ./build.sh beta qt ./build.sh save qt then install/linux/install.sh gtk2 from saved gtk2 and install/linux/install.sh qt4 from saved qt4. Is it alright? I don't have time today, tomorrow may have a try. --- Additional comment from Michael Schwendt (Fedora Packager Sponsors Group) on 2013-08-16 21:35:44 CEST --- > Is it alright? Dunno. I haven't examined the source code that much. One more general way is to create a copy of the source tree (e.g. in %prep), so you get two trees which you can configure differently (likely with a strict set of --enable-foo/--disable-foo options). --- Additional comment from Mario Blättermann on 2013-10-20 20:00:27 CEST --- Is there any decision made how to proceed with doublecmd? In any case, you should close one ticket of doublecmd-qt and doublecmd-gtk. It would be odd to generate to srpms for the two packages. --- Additional comment from Mario Blättermann on 2013-10-31 20:05:33 CET --- Any progress here...? --- Additional comment from Mario Blättermann on 2013-11-16 16:32:25 CET --- (In reply to Mario Blättermann from comment #7) > Any progress here...? Same question again...? Anyway, you should open a new review ticket for doublecmd and mark doublecmd-qt4 and doublecmd-gtk2 as duplicates. In fact both of the current tickets are NotReady. --- Additional comment from Raphael Groner on 2014-03-28 15:16:19 CET --- (In reply to Mario Blättermann from comment #7) > Any progress here...? http://vondruch.fedorapeople.org/doublecmd/ --- Additional comment from Raphael Groner on 2014-12-11 18:14:40 CET --- Should I take the request by clone this bug and closing? --- Additional comment from Raphael Groner on 2015-02-05 16:16:04 CET --- Hi Christopher, are you still interested in mainting this package? If not, I would suggest to consider this as a dead review, unfortunately. --- Additional comment from Raphael Groner on 2015-02-25 17:03:52 CET --- Ping? Again? --- Additional comment from Christopher Meng on 2015-02-26 04:14:39 CET --- (In reply to Raphael Groner from comment #12) > Ping? Again? --- Additional comment from Raphael Groner on 2015-03-30 16:32:31 CEST --- WTF? What's this here? No progress since monthes. Sorry to raise and sound unfriendly but this issue here is generally no acceptable process. --- Additional comment from Raphael Groner on 2015-04-03 22:34:08 CEST --- Taking over here. Closing.
Raphael, Thanks for taking this for a review. I have never tried to push Double Commander through it, since I am not sure about its bundling. Nevertheless, if you are serious about this review, would you mind to adjust your spec to have actually doublecmd-gtk and doublecmd-qt subpackages? Doing just doublecmd-qt or doublecmd-gtk review would be missed opportunity IMO. Thanks.
Hi Vit. Sure, we can add the gtk2 build. In past, there were those two separate requests that never got more feedback. Therefore I continued to do so with the separation. What bundling are you talking about?
The plugins ships with some bundled libraries, if I am not mistaken. Not sure how much of the code is original and how much of it is just copied from somewhere. Also, the components are tricky. This is how Delphi/Lazarus works, but typically, this code is taken from somewhere and just copied into the project. It should be probably discussed with FPC.
* Sun Apr 26 2015 Raphael Groner <> - 0.6.2-0.1.20150426svn6000 - revision 6000 - add build for gtk2 - split into subpackages SPEC: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd.spec SRPM: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd-0.6.2-0.1.20150426svn6000.fc21.src.rpm rawhide scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=9575854 ==> FTBFS, bug #1215643 ERROR: Broken dependency: KASComp 1.8>KASComp 1.8 f22 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=9575922 ==> FTBFS, bug #1215643 f21 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=9576041 ==> OK f20 scratch (without Suggests): http://koji.fedoraproject.org/koji/taskinfo?taskID=9576067 ==> OK (In reply to Vít Ondruch from comment #3) > The plugins ships with some bundled libraries, if I am not mistaken. Not > sure how much of the code is original and how much of it is just copied from > somewhere. Upstream says it is GPLv2 or LGPLv2 with exception for the Lazarus libraries. I do not see any problem here. > Also, the components are tricky. This is how Delphi/Lazarus works, but > typically, this code is taken from somewhere and just copied into the > project. It should be probably discussed with FPC. Hmm ok. Maybe poking arout at FPC could be useful somehow.
f20 scratch (without Suggests): http://koji.fedoraproject.org/koji/taskinfo?taskID=9576272 ==> FTBFS TExternalToolList.Run Exception: /builddir/build/BUILD/doublecmd-r6000/components/doublecmd/dcprocessutf8.pas(24,5) Fatal: Can't find unit UTF8Process used by DCProcessUtf8
It turns out that lazbuild needs a bugfix to get some doublecmd build success. > Lazarus 1.4 has a bug in lazbuild utility. I wrote about it to Lazarus > bugtracker and it was fixed (revisions 48892,48893). This fix will be > included in Lazarus 1.4.2 .
Upstream announced version 0.6.2 beta. I'll try to update the package soon. http://doublecmd.sourceforge.net/mantisbt/changelog_page.php?version_id=34 If there'll still be build issues as it turns out for the r6000 checkout, we should continue this review with the 0.6.1 stable version.
Waiting for availability of new lazbuild, see comment #6.
SPEC: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd.spec SRPM: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd-0.6.4-1.fc22.src.rpm Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10418932
Last time I discussed the .zdli with upstream, they insisted that we should distribute also the .zdli, although we have possibly debuginfo available and that we should use the "beta" target for build. I know that it seems to be duplicated information, on the other hand, there is code in DoubleCmd, which can consume the .zdli and should be able to provide some better crash reports for end users as well for upstream. In the end, it is up to you, I just sharing the information ...
(In reply to Vít Ondruch from comment #10) > Last time I discussed the .zdli with upstream, they insisted that we should > distribute also the .zdli, although we have possibly debuginfo available and > that we should use the "beta" target for build. I know that it seems to be > duplicated information, on the other hand, there is code in DoubleCmd, which > can consume the .zdli and should be able to provide some better crash > reports for end users as well for upstream. Okay, fixed. Thanks for this information. Though, I don't see any reason why "beta" target is needed, do you mean to put in Release? Version 0.6.4 is official with no beta hint at all, the zero in front of version should be enough identification for any beta thought of upstream. * Tue Jul 21 2015 Raphael Groner <> - 0.6.4-2 - distribute zdli files for crash reports - avoid duplicated documentation and binaries - improve shell logging SPEC: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd.spec SRPM: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd-0.6.4-2.fc22.src.rpm Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10424505
FTBFS for arch i686: … + /usr/bin/lazbuild src/doublecmd.lpi --bm=beta --widgetset=gtk2 --cpu=i386 … TProject.DoLoadStateFile Statefile not found: /builddir/build/BUILD/doublecmd-0.6.4/units/i386-linux-gtk2/doublecmd.compiled TBuildManager.CheckIfPackageNeedsCompilation No state file for Project TExternalTool.DoExecute Title="Project: Executing command before" Process.CurrentDirectory="/builddir/build/BUILD/doublecmd-0.6.4/src/" Executable="/builddir/build/BUILD/doublecmd-0.6.4/src/_getsvnrev.cmd" Params: /usr/lib/lazarus/ An unhandled exception occurred at $00000008 : EAccessViolation : Access violation $00000008 $081710A7 $081722CE $0805F4D2 An unhandled exception occurred at $0806FDD1 : EInOutError : $0806FDD1 $08065998 $0808D015 $08060634 $080A12E5 $0806383E $081710A7 $081722CE $0805F4D2 Really strange cause that does not happen with arch x86_64.
(In reply to Raphael Groner from comment #11) > Though, I don't see any reason why "beta" target is needed, do you mean to > put in Release? Version 0.6.4 is official with no beta hint at all, the zero > in front of version should be enough identification for any beta thought of > upstream. I think that the "beta" builds everything, including the plugins (you do this in separate step) and debug information. Not sure what and if there is any other difference, but I doubt that. (In reply to Raphael Groner from comment #12) > FTBFS for arch i686: It builds in Rawhide and F21 at least [1], but the F22 build is broken ATM (it is actually Rawhide build, have to wait till Lazarus lands in updates for F22 :/ ). [1] https://copr.fedoraproject.org/coprs/vondruch/doublecmd/
> [1] https://copr.fedoraproject.org/coprs/vondruch/doublecmd/ I decided to not like building from subversion, at least not for an official package and if there's no patch needed. FTBFS is magically fixed. But ARM seems to partly build for ages (duration is >1 day), maybe we should consider to use an ExcludeArch here. Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10424958
I'm thinking about using alternative command to make 2 packages existing in one system. Thoughts?
I'm also against that as default doublecmd is built with gtk2 widget.
Christopher, what are you talking about? The difference between qt and gtk2 is handled with subpackages. I fail to see any trouble with that.
naming: ok licensing: ok sources: ok 926bd7bea6bccd2c618d97d39cc7d4ad doublecmd-0.6.4-src.tar.gz 1. MUST use desktop-file-install or desktop-file-validate for application .desktop files, see http://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files macros: ok scriptlets: ok (n/a) 2. SHOULD reconsider the need for -plugins subpkg, what's the use-case for this optional component (rather than just including it all in the main pkg)? 3. SHOULD include only one (or none?) of these in the main pkg, Suggests: %{name}-qt = %{version}-%{release} Suggests: %{name}-gtk = %{version}-%{release} Including both doesn't give dnf any hint/help as to which to pick by default.
ping?
Sorry for the long delay, this request got somehow lost under the table. SPEC: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd.spec SRPM: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd-0.6.6-1.fc23.src.rpm Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=11872752 * Mon Nov 16 2015 Raphael Groner <> - 0.6.6-1 - new upstream version - add desktop-file-validate - remove obsolete Suggests - split plugins into optional subpackages - add more documentation For plugins, please notice the additional (but proprietary?) documentation: http://doublecmd.sourceforge.net/site/eng/plugins.html Those zip files are part of Total commander API documentation, and so can not be part of our packages, there's no obvious license.
Another update due to execution of licensecheck and rpmlint. SPEC: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd.spec SRPM: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd-0.6.6-1.fc23.src.rpm Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=11886103 * Tue Nov 17 2015 Raphael Groner <> - 0.6.6-1 - new upstream version - add desktop-file-validate - remove obsolete Suggests - split plugins into optional subpackages - add more documentation - improve license specification - fix rpmlint warnings No idea how to fix those rpmlint errors with the plugins: E: shared-lib-without-dependency-information (several binaries) E: library-not-linked-against-libc (ftp.wfx) For plugins, please notice the additional (but proprietary?) documentation: http://doublecmd.sourceforge.net/site/eng/plugins.html Those zip files are part of Total commander API documentation, and so can not be part of our packages, there's no obvious license.
Created attachment 1095627 [details] licensecheck.txt
Created attachment 1095628 [details] rpmlint.txt
raphgro's scratch build of doublecmd-0.6.6-2.fc23.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=11895688
SPEC: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd.spec SRPM: https://raphgro.fedorapeople.org/review/doublecmd/doublecmd-0.6.6-2.fc23.src.rpm Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=11895688 * Wed Nov 18 2015 Raphael Groner <> - 0.6.6-2 - disable qt build on arm architectures
ARM support is not the best in fpc 2.x series, there's the new upstream version 3.0 of fpc that could make things better.
Sadly to say but there no senseful news to expect from upstream. . Qt4 development has stopped, Qt4Pas is still in no good stable state at upstream. . Gtk2 is in maintainance mode mostly and can not be expected to get new features. . fpc (Free Pascal Compiler) still has severe issues with ARM support in general. Closing. Feel free to reopen or restart a new review request if you still think doublecmd should be packaged officially.
clearing flags
Double Commander is still in development - new version 0.8.0 arrived:) https://sourceforge.net/p/doublecmd/news/2017/12/double-commander-080-beta-released/ Sadly it still is not available in Fedora repos... It is because of commercial Total Commander dependencies? Why not put it in rpmfusion.org repo?
The main reason is that it is written in FPC/Lazarus, which is not a mainstream programming language, and which is fairly poorly maintained upstream. There are bindings (and corresponding backends for the cross-toolkit widget abstraction) only for Qt 4 and GTK+ 2, which are both deprecated. The GTK+ 3 backend is still in alpha stage, there is no mention of a Qt 5 or GTK+ 4 backend at all. So essentially, comment #27 still applies, 2 years later (which also means that the code has become even more outdated).
(In reply to Daniel Laskowski from comment #29) > Double Commander is still in development - new version 0.8.0 arrived:) > https://sourceforge.net/p/doublecmd/news/2017/12/double-commander-080-beta- > released/ > > Sadly it still is not available in Fedora repos... It is because of > commercial Total Commander dependencies? It has nothing to do with TC IMO. The comment 1 and comment 3 explains my concerns. But generally, somebody would have to be dedicated enough to get it into Fedora. > Why not put it in rpmfusion.org repo? It is available in Copr [1], but even there it needs some maintenance ... [1] https://copr.fedorainfracloud.org/coprs/vondruch/doublecmd/
(In reply to Kevin Kofler from comment #30) > The main reason is that it is written in FPC/Lazarus, which is not a > mainstream programming language, and which is fairly poorly maintained > upstream. Probably you are right that this application is poorly maintained, but from user point of view: "it just works". And, surprisingly, it is working very stable and in the same way on Fedora (installed from opensuse standalone rpm file) and Windows. I even abandoned licensed Total Commander for it. Now I could use the same file manager in work (Windows) and in home (Linux with Windows VMs) with very similar configuration... It would be great to have it in official repo or in rpmfusion.org. I would even try to pack it by myself, but I'm afraid that my programming skills are too weak. Also looking on previous abandoned attempts - it looks like Fedora packaging process is too repressive.
It is not the application that's poorly maintained, it's the programming language (and its standard libraries). This means that packaging applications written in it are a PITA to package.
It looks like there is actually a Qt 5 interface now: http://wiki.lazarus.freepascal.org/Qt5_Interface but I did not find it yesterday because it is not linked from anywhere in the Free Pascal wiki. It is also not packaged in Fedora yet, I see only a qt4pas package, no qt5pas. I think packaging doublecmd will have to start from taking care of the FPC and Lazarus packaging.