Bug 1208911 - Review Request: doublecmd - Twin-panel (commander-style) file manager
Review Request: doublecmd - Twin-panel (commander-style) file manager
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On: 1247925 1209477 1215643
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2015-04-03 16:57 EDT by Raphael Groner
Modified: 2017-01-27 10:38 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 989791
Environment:
Last Closed: 2015-12-16 11:22:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
licensecheck.txt (105.58 KB, text/plain)
2015-11-17 14:39 EST, Raphael Groner
no flags Details
rpmlint.txt (2.11 KB, text/plain)
2015-11-17 14:40 EST, Raphael Groner
no flags Details

  None (edit)
Description Raphael Groner 2015-04-03 16:57:46 EDT
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.
Comment 1 Vít Ondruch 2015-04-07 02:16:41 EDT
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.
Comment 2 Raphael Groner 2015-04-07 11:00:32 EDT
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?
Comment 3 Vít Ondruch 2015-04-08 04:33:01 EDT
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.
Comment 4 Raphael Groner 2015-04-27 07:34:39 EDT
* 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.
Comment 5 Raphael Groner 2015-04-27 07:59:35 EDT
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
Comment 6 Raphael Groner 2015-05-01 08:51:38 EDT
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 .
Comment 7 Raphael Groner 2015-05-10 05:16:36 EDT
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.
Comment 8 Raphael Groner 2015-07-14 14:02:07 EDT
Waiting for availability of new lazbuild, see comment #6.
Comment 10 Vít Ondruch 2015-07-21 01:54:14 EDT
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 ...
Comment 11 Raphael Groner 2015-07-21 05:21:35 EDT
(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
Comment 12 Raphael Groner 2015-07-21 05:34:47 EDT
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.
Comment 13 Vít Ondruch 2015-07-21 06:11:12 EDT
(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/
Comment 14 Raphael Groner 2015-07-21 07:16:27 EDT
> [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
Comment 15 Christopher Meng 2015-07-23 05:13:29 EDT
I'm thinking about using alternative command to make 2 packages existing in one system.

Thoughts?
Comment 16 Christopher Meng 2015-07-23 05:15:00 EDT
I'm also against that as default doublecmd is built with gtk2 widget.
Comment 17 Raphael Groner 2015-07-23 11:04:45 EDT
Christopher, what are you talking about?

The difference between qt and gtk2 is handled with subpackages. I fail to see any trouble with that.
Comment 18 Rex Dieter 2015-10-21 11:58:25 EDT
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.
Comment 19 Rex Dieter 2015-11-16 07:49:11 EST
ping?
Comment 20 Raphael Groner 2015-11-16 16:19:54 EST
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.
Comment 21 Raphael Groner 2015-11-17 14:02:58 EST
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.
Comment 22 Raphael Groner 2015-11-17 14:39 EST
Created attachment 1095627 [details]
licensecheck.txt
Comment 23 Raphael Groner 2015-11-17 14:40 EST
Created attachment 1095628 [details]
rpmlint.txt
Comment 24 Upstream Release Monitoring 2015-11-18 17:46:54 EST
raphgro's scratch build of doublecmd-0.6.6-2.fc23.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=11895688
Comment 25 Raphael Groner 2015-11-18 17:56:42 EST
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
Comment 26 Raphael Groner 2015-11-26 15:42:28 EST
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.
Comment 27 Raphael Groner 2015-12-16 11:22:26 EST
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.
Comment 28 Rex Dieter 2017-01-27 10:38:19 EST
clearing flags

Note You need to log in before you can comment on or make changes to this bug.