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.