Modifications to build .deb package

[lyc1]

Hello,

I'd like to maintain .deb package for Ubuntu.

FreeFileSync uses its own configuration folders to read Resources.dat,
Languages files and to write user configuration. These are incompatible with
building .deb package.

Would it be possible to use wxStandardPaths::GetDataDir for languages,
GetResourcesDir for Resource.dat and GetUserDataDir to store user generated
files ?

Moreover, Makefile is missing "install" target which is very useful to build
.deb package, where install prefix is configurable.
Maybe a reworked build system based on Makefile.in + configure could be
necessary (i don't know much about that).

I well want to provide patches and test results on Ubuntu, but I need your
help to understand FFS organization.

Thanks

[Zenju]

Hi lyc1!

> I'd like to maintain .deb package for Ubuntu.
Alright, let's go for this.

> Would it be possible to use wxStandardPaths::GetDataDir for languages,
GetResourcesDir > for Resource.dat and GetUserDataDir to store user generated
files ?
Yes, I'll adapt file loading accordingly. There is just one thing to consider:
For Windows there are two types of FFS: "installer-based" and "portable". For
Linux there is only "portable". The main differentiator between the two when
it comes to Linux is: Where is user configuration/data supposed to be saved?
So we would need some means to determine whether FFS is running portable or
installer-based.
I'm thinking about something like: If FFS binary is located "bin" directory it
is installer-based version, else portable.

> Moreover, Makefile is missing "install" target which is very useful to build
.deb
> package, where install prefix is configurable.
> Maybe a reworked build system based on Makefile.in + configure could be
necessary (i
> don't know much about that).
I'm not sure if Makefile.in is required, it may be that adding an "install"
target is sufficient.

Regards, Zenju

[lyc1]

> The main differentiator between the two when it
> comes to Linux is: Where is user configuration/data
> supposed to be saved?

Hum, what is a user configuration/data for you ?

FFS remembers last user ui appearance, in a xml file. Such a file could to go
to GetUserDataDir().

User configuration files could go where the he want to save them, with default
value sets to GetDocumentsDir() or GetUserDataDir() for eg.

According to the doc:

wxStandardPaths::GetUserDataDir
* Unix: ~/.appname
* Windows: C:\Documents and Settings\username\Application Data\appname
* Mac: ~/Library/Application Support/appname

wxStandardPaths::GetDocumentsDir
* Unix: ~ (the home directory)
* Windows: C:\Documents and Settings\username\Documents
* Mac: ~/Documents


wxApp::GetAppName() should be set too ("FreeFileSync" or "freefilesync")

> If FFS binary is located "bin" directory it is installer-based version, else
portable.

It could work.

> it may be that adding an "install" target is sufficient.

During .deb build, install prefix is set to a temporary folder (thanks to
configure) in order to build the binary package later. So this needs to be
configurable.
But a user which wants to install it manually, will just sets prefix to /usr
(default) or /usr/local

Lyc1

[Zenju]

> Hum, what is a user configuration/data for you ?
Configuration data the program creates by default:
LastRun.ffs_gui
LastRun.ffs_real
GlobalSettings.xml
Logs\* (default directory)
Error.txt

> User configuration files could go where the he want to save them, with
default value
> sets to GetDocumentsDir() or GetUserDataDir() for eg.
I use wxFilePicker control for this, at least in Windows it remembers the last
selection, so this should be okay.

>> If FFS binary is located "bin" directory it is installer-based version,
else portable.
>It could work.
This solution doesn't seem to be very elegant. But I don't see a better one
right now.

> it may be that adding an "install" target is sufficient.

> During .deb build, install prefix is set to a temporary folder (thanks to
configure) in > order to build the binary package later. So this needs to be
configurable.
> But a user which wants to install it manually, will just sets prefix to /usr
(default)
> or /usr/local
Okay, then we'd need a "configure" file for setting the installation path (if
nothing else).

[lyc1]

> Configuration data the program creates by default:
> LastRun.ffs_gui
> LastRun.ffs_real
> GlobalSettings.xml
> Logs\* (default directory)
> Error.txt

Ok => GetUserDataDir()

> >> If FFS binary is located "bin" directory it is installer-based
> version, else portable.
> >It could work.
> This solution doesn't seem to be very elegant. But I don't see a better
> one right now.

I don't understand what are the differences between installer-based and
portable version.
File structures are not the same ?

> Okay, then we'd need a "configure" file for setting the installation
> path (if nothing else).

I think it's the main missing configuration settings, with "make install"
target.

.deb packaging is ready, I'm just waiting for theses modifications. I'll setup
an Ubuntu PPA as soon as it will work.

[Zenju]

> I don't understand what are the differences between installer-based and
portable version.
> File structures are not the same ?
Exactly, in portable mode all files are saved into the directory containing
the binary. Usecase is carrying FFS around on a USB-stick. For Linux this
might not be so common, but it doesn't cost me anything to support it.

> I think it's the main missing configuration settings, with "make install"
target.
> .deb packaging is ready, I'm just waiting for theses modifications. I'll
setup an Ubuntu
> PPA as soon as it will work.
Is it possible to also set application icons?
Today I'm trying to finalize v3.3 and hopefully release it. Perhaps I find the
time to include the changes to file loading also.

[lyc1]

> > File structures are not the same ?
> Exactly, in portable mode all files are saved into the directory
> containing the binary. Usecase is carrying FFS around on a USB-stick.
> For Linux this might not be so common, but it doesn't cost me anything
> to support it.

FFS is currently "installed" for testing purpose on my usb key (Linux
compilation).
It works perfectly :)

May be you could implement the opposite idea : why not testing "FFS is in
portable mode" instead of testing "FFS is in installer-based mode" ?
Ubuntu installation will be a kinf of installer-based mode too.

If FFS find Resources.dat or folder of languages beside executable file, it is
in portable mode, isn't it ?


> > I'll setup an Ubuntu
> > PPA as soon as it will work.
> Is it possible to also set application icons?

What do you mean ?

> Today I'm trying to finalize v3.3 and hopefully release it. Perhaps I
> > find the time to include the changes to file loading also.

If it's not ready for 3.3, I'll work with CVS HEAD of FFS.

[Zenju]

> If FFS find Resources.dat or folder of languages beside executable file, it
is in
> portable mode, isn't it ?
Good idea. Seems to be more safe than checking whether path of binary ends
with a "\bin", or checking directly against "\usr\bin" or "\usr\local\bin".

> Is it possible to also set application icons?
> What do you mean ?
In Windows each binary contains an icon resource. For Linux there is an analog
approach requiring registering icon files in some special folders. I don't
know if such registering belongs into a .deb package, but if it does, it would
be nice.

> If it's not ready for 3.3, I'll work with CVS HEAD of FFS.
CVS isn't maintained anymore, instead you can use the current source-files
that come along with each releas as a .zip package.

[lyc1]

> > Is it possible to also set application icons?
> > What do you mean ?
> In Windows each binary contains an icon resource. For Linux there is
> an analog approach requiring registering icon files in some special
> folders. I don't know if such registering belongs into a .deb package,
> but if it does, it would be nice.

FFS will be available in Ubuntu "Application=>Accessories" menu with its own
usual icon.
I'll provide you FreeFileSync.desktop file later.

[lyc1]

> > If it's not ready for 3.3, I'll work with CVS HEAD of FFS.
> CVS isn't maintained anymore, instead you can use
> the current source-files that come along with each releas as a .zip package.

Hum, I will have to wait 3.4 release since you released 3.3 version yesterday.
In the future, It would be good to be able to have daily sources snapshots
available, or better scm access, in order to test packaging before each
release.

Other modifications I will do :
- disable by default checking of new version
- disable menu entry to check new version

Later (external dev, but may need FFS improvements) :
- Default association between .ffs_gui extension and FFS
- Nautilus extension with menu entry such as "Synchronize this folder with FreeFileSync"

[Zenju]

> Hum, I will have to wait 3.4 release since you released 3.3 version
yesterday.
> In the future, It would be good to be able to have daily sources snapshots
available, or better scm access, in order to test
> packaging before each release.
I didn't find the time yesterday to include the adaptions to file loading, but
will implement it today. Then I'll post a link the the sources here, so that
you can test. In the long run I think it won't be necessary to have daily
snapshots when it comes to packaging, as the algorithms, once implemented,
should prove to be stable.

> Other modifications I will do :
> - disable by default checking of new version
> - disable menu entry to check new version
Why disable update-checks?

> Default association between .ffs_gui extension and FFS
Would be nice.

> Nautilus extension with menu entry such as "Synchronize this folder with
FreeFileSync"
I'm not sure, if there is valid usecase for this. But even if, it would need
to have an option to select if this change is applied.

[lyc1]

> I didn't find the time yesterday to include the adaptions to file
> loading, but will implement it today. Then I'll post a link the the
> sources here, so that you can test.

Ok, take your time, theses modifications are not urgent.

> In the long run I think it won't be necessary to have daily
> snapshots when it comes to packaging, as the algorithms, once
> implemented, should prove to be stable.

Ok.

> Why disable update-checks?

Update check is system-wide and manage centrally on Ubuntu (on Linux in
general).
When FFS will be updated, Ubuntu package will be updated on its PPA, and, in a
day, all users will receive this new version.
This is a typical behavior on Linux.

For eg., Firefox or Thunderbird never tell me they will be updated. Automatic
update-check is disabled and delegated to Ubuntu update system.

> > Nautilus extension with menu entry such as "Synchronize this folder
> > with FreeFileSync"
> I'm not sure, if there is valid usecase for this. But even if, it
> would need to have an option to select if this change is applied.

This is a feature often requested for Unison, another synchronization tool,
very popular on Ubuntu.
But Unison :
- can't be translated easily
- hard to configure for Ubuntu's beginners
- UI is very poor and very hard to extend because it is written in ocaml (?)

But I'll think about that really later.

[Zenju]

> and, in a day, all users will receive this new version.
That's really cool! So I will disable update checks and links for the
installer-version, but keep it for portable.

[lyc1]

> So I will disable update checks and links for the installer-version, but
keep it for portable.

What about installer-based users ?

Maybe you could control this with a config file, specific for this feature. If
it exists and contains a specified value, doesn't check or display anything
about update. This file could be stored in GetLocalDataDir (executable dir on
Windows, /etc/FreeFileSync on Linux)
I could provide this file especially for the Ubuntu deb packaging.

[Zenju]

> What about installer-based users ?
You mean giving an option whether they want the regular update-checks
additionally? Shouldn't be necessary if the .deb package handles all updates,
should it? I think in the installer-based version it would be kind of
redundant having two kinds of update-checks.

[lyc1]

> > What about installer-based users ?
> You mean giving an option whether they
> want the regular update-checks additionally?
> Shouldn't be necessary if the .deb package handles all updates, should it?

Ubuntu update system will handle update-check and update of FFS alone. So FFS
update-check has to be disabled.
If you can disable this feature without any side effect on Windows platform,
it's ok for me.

[Zenju]

Windows build won't interfere. I'll have this update check active in general
with Linux installer version being the only exception.

[Zenju]

Alright, I've patched file loading for Linux. Here is the new structure for
the installer-based version:

Binary:
FreeFileSync
RealtimeSync

Resources (wxStandardPaths::GetResourcesDir())
Languages\*.lng
Help\*
Compare_Complete.wav
Sync_Complete.wav
Resources.dat
Changelog.txt
License.txt
Styles.rc

Generated files (wxStandardPaths::GetUserDataDir)
LastRun.ffs_gui
LastRun.ffs_real
GlobalSettings.xml
Logs\* (default directory)
Error.txt

In Linux portable mode all files are read and written to the current working
directory. The algorithm to detect portable is: "portable" <=> not "binary
path ends with \bin". This ensures that if it is in any other directory, FFS
assumes portable mode by default, no matter if resources files reside besides
binary or not.

Additionally update checks have been disabled for Linux installer-based
version.

Updated source:
[404, Invalid URL: http://www.file-upload.net/download-2221782/Sourcecode_v3.4_RC.zip.html]

Regards, Zenju

[lyc1]

> Updated source:
> [404, Invalid URL: http://www.file-upload.net/download-2221782/Sourcecode_v3.4_RC.zip.html]

It works great, either as portable mode or dispatched through /usr/local/bin,
/usr/local/share/FreeFileSync and /home/<USER>/.FreeFileSync

Update-check is disabled as expected.

Will you work on improving configure/Makefile (install) or should I do it
myself (with later contribution to FFS) ?

[Zenju]

> Will you work on improving configure/Makefile (install) or should I do it
myself (with later contribution to FFS)?
You can make the adaptions to the makefile, I'll then incorporate them into
the current sources.

[lyc1]

Here we are, FFS is packaged as .deb file for Ubuntu.
It is available here :
[404, Invalid URL: https://launchpad.net/%7Edlecan/%2Barchive/ffs]

I had to improve Makefile in order to support install target, I had to create
.desktop file (Ubuntu menu configuration), create a 48x48px FFS logo png image
and restore FreeFileSync.xpm

I can contribute Makefile, 48x48px image. How ?
Moreover, freefilesync.desktop, freefilesync.xpm and freefilesync48x48.png
have to be lower-cased.

Other packaging stuff related to .deb will be available under GPLv3 and stored
into Ubuntu Launchpad SCM.

[Zenju]

Great! I'll be testing this. About the files you created: You can simply send
them per mail or upload them somewhere and send me the link.

Regards, Zenju

[Zenju]

The .deb package seems to working fine!

I've included the makefile into the sources and also updated the makefile for
RealtimeSync:

[404, Invalid URL: http://www.file-upload.net/download-2243670/FFS_v3.4_RC2.rar.html]

- Is it possible to include RealtimeSync also?
- Could you register file extensions and icons for *.ffs_gui, *.ffs_batch and *.ffs_real?

Thanks, Zenju

[lyc1]

> Is it possible to include RealTimeSync also?
Yes, I'll packaged it as separate bundle.
Name : "freefilesync-realtimesync"

> Could you register file extensions and icons for *.ffs_gui, *.ffs_batch and
*.ffs_real?
It should be already done for .ffs_gui :)
If it doesn't work, it's a bug.
I'll try on a clean Ubuntu installation.

[Zenju]

>Yes, I'll packaged it as separate bundle.
In this case there is one caveat: Currently RTS relies on "ossp_uuid" already
having compiled completely by FFS make. So the RTS makefile needs to be made
smarter, to also include "ossp_uuid". But the dependency in FFS makefile
(currently) is not correct:
target "FreeFileSync" depends on "ossp_uuid", while in fact only
"shared/guid.cpp" should depend on "ossp_uuid".
Could this be fixed by having "shared/guid.dep" depend on both
"shared/guid.cpp" AND "ossp_uuid" (possibly without removing "shared/guid.cpp"
from file list)? Hope I could make my point clear. :)

> It should be already done for .ffs_gui :)
Yes, association is okay, but it doesn't have an icon associated with it. And
the other extensions, *.ffs_batch and *.ffs_real are not registered.

Regards, Zenju

[lyc1]

> In this case there is one caveat: Currently RTS relies on "ossp_uuid"
> already
> having compiled completely by FFS make. So the RTS makefile needs to
> be made smarter, to also include "ossp_uuid". But the dependency in FFS
> makefile (currently) is not correct: target "FreeFileSync" depends on
> "ossp_uuid", while in fact only "shared/guid.cpp" should depend on
> "ossp_uuid". Could this be fixed by having "shared/guid.dep" depend on
> both "shared/guid.cpp" AND "ossp_uuid" (possibly without removing
> "shared/guid.cpp" from file list)?
> Hope I could make my point clear. :)

Hum, it a bit dark for me. It seems to be a compiled-time issue, so doing a
third party package which includes ossp_uuid (libfreefilesync ?) doesn't help.
I don't know what to do but I think it would be good to package FFS and RTS in
separate debs.

> Yes, association is okay, but it doesn't have an icon associated with
> it. And the other extensions, *.ffs_batch and *.ffs_real are not
> registered.
Ok for the icon, I'm going to see how to do that.

*.ffs_batch and *.ffs_real have to be registered with FFS too ? or later with RTS ?

[Zenju]

> I don't know what to do but I think it would be good to package FFS and RTS
in separate debs.
Forget the point I mentioned (for now)! We're lucky here, the point I
mentioned currently is not relevant! (An older release however had this
dependency, but for v3.3 I had reworked this algorithm, so that right now, we
should be fine.)

> *.ffs_batch and *.ffs_real have to be registered with FFS too ? or later
with RTS ?
If you provide two distinct packages *.ffs_batch would go with FFS and
*.ffs_real with RTS.
But the question is, do we really need two packages? The only difference
between FFS and RTS is the executable, all other files are shared between the
two. So I think it makes sense to also publish them together. This is the way
the Windows-installer is designed, so it would be nice to have this approach
harmonized with Linux.

[lyc1]

> This is the way the Windows-installer is designed, so
> it would be nice to have this approach harmonized with Linux.

Users are not the same, it isn't so important that both bundles look alike.
Anyway, next days, I'll push a new version of the deb package which will
include RealtimeSync executable.

[Zenju]

Alright, thank you!

[lyc1]

I published a new versio of the deb package a few time ago.

It includes :
- FFS 3.4rc2
- Realtimesync
- New modifications in Makefile (better clean target)
- PNG menu icons are automatically extracted from .ico files instead of using xpm files

In Makefile, I had to change this
cd shared/ossp_uuid && make clean

by this :
cd shared/ossp_uuid && chmod +x configure && chmod +x shtool && ./configure
--with-cxx --disable-shared && make clean

I'll do later icon associated with ffs files.

During deb packaging, I can see these warnings :
dpkg-shlibdeps: warning: dependency on libwx_gtk2u_richtext-2.8.so.0 could be
avoided if "debian/freefilesync/usr/bin/RealtimeSync
debian/freefilesync/usr/bin/FreeFileSync" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_baseu_xml-2.8.so.0 could be
avoided if "debian/freefilesync/usr/bin/RealtimeSync
debian/freefilesync/usr/bin/FreeFileSync" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_gtk2u_aui-2.8.so.0 could be
avoided if "debian/freefilesync/usr/bin/RealtimeSync
debian/freefilesync/usr/bin/FreeFileSync" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_gtk2u_xrc-2.8.so.0 could be
avoided if "debian/freefilesync/usr/bin/RealtimeSync
debian/freefilesync/usr/bin/FreeFileSync" were not uselessly linked against it
(they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libwx_gtk2u_qa-2.8.so.0 could be
avoided if "debian/freefilesync/usr/bin/RealtimeSync
debian/freefilesync/usr/bin/FreeFileSync" were not uselessly linked against it
(they use none of its symbols).

Do you know how to remove them ?