Debian packaging

[darealshinji]

I've written packaging files based on the files you had published here. Running Lintian on the package shows no errors or warnings for me.

Packaging files plus a .deb package: debian.zip

quickhash_2.7.0-1_amd64.deb:
 new debian package, version 2.0.
 size 1932730 bytes: control archive=1117 bytes.
     814 bytes,    19 lines      control              
    1069 bytes,    14 lines      md5sums              
 Package: quickhash
 Version: 2.7.0-1
 Architecture: amd64
 Maintainer: Ted Smith <tedsmith28@yahoo.co.uk>
 Installed-Size: 6381
 Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.2.5), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libpango-1.0-0 (>= 1.14.0), libx11-6
 Section: misc
 Priority: optional
 Homepage: http://quickhash-gui.org/
 Description: Graphical data hashing tool
  Quickhash is a graphical means for users to easily
  hash data such as text, files, or even disks using Linux
  without knowing command line syntax.
  .
  It can also be used for copying files from one folder to another
  where hashes are computed prior to copying and afterwards.
  .
  Users can compare to files, or compare two folders, using hash
  anaysis to be sure one matches the other

drwxr-xr-x root/root         0 2016-12-22 11:44 ./
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/bin/
-rwxr-xr-x root/root   5863080 2016-12-22 11:44 ./usr/bin/quickhash
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/96x96/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/96x96/apps/
-rw-r--r-- root/root     14664 2016-12-22 11:44 ./usr/share/icons/hicolor/96x96/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/32x32/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/32x32/apps/
-rw-r--r-- root/root      2473 2016-12-22 11:44 ./usr/share/icons/hicolor/32x32/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/48x48/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/48x48/apps/
-rw-r--r-- root/root      4672 2016-12-22 11:44 ./usr/share/icons/hicolor/48x48/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/64x64/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/64x64/apps/
-rw-r--r-- root/root      7434 2016-12-22 11:44 ./usr/share/icons/hicolor/64x64/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/16x16/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/16x16/apps/
-rw-r--r-- root/root      1197 2016-12-22 11:44 ./usr/share/icons/hicolor/16x16/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/128x128/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/128x128/apps/
-rw-r--r-- root/root     22526 2016-12-22 11:44 ./usr/share/icons/hicolor/128x128/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/24x24/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/icons/hicolor/24x24/apps/
-rw-r--r-- root/root      1667 2016-12-22 11:44 ./usr/share/icons/hicolor/24x24/apps/quickhash.png
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/man/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/man/man1/
-rw-r--r-- root/root       435 2016-12-22 11:44 ./usr/share/man/man1/quickhash.1.gz
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/doc/
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/doc/quickhash/
-rw-r--r-- root/root     16601 2016-12-22 10:19 ./usr/share/doc/quickhash/README.txt.gz
-rw-r--r-- root/root    563358 2016-12-22 10:19 ./usr/share/doc/quickhash/UserManual.pdf
-rw-r--r-- root/root       190 2016-12-22 10:11 ./usr/share/doc/quickhash/changelog.Debian.gz
-rw-r--r-- root/root       994 2016-12-21 15:31 ./usr/share/doc/quickhash/copyright
drwxr-xr-x root/root         0 2016-12-22 11:44 ./usr/share/applications/
-rw-r--r-- root/root       226 2016-12-22 11:44 ./usr/share/applications/quickhash.desktop

[tedsmith]

libs/libewf-Linux-x64.so added to v3.3.0 branch in /libs/x64(I only just noticed I didnt have the x64 and x86 subfolders created in Git, as set and defined and expected in the code base. Ive just adjusted it). I've added a couple of comments to your commit just to check I have not mis-understood some of your changes. Let me know if all is good? Thanks as ever for your rapid actions helping with packaging!

(PS..these commits to the packaging and makefile are good as I can merge them to master without it impacting on the program itself and I can prepare a seperate Debian package download for the website, but be aware that no code changes to the program can happen now as I have compiled, prepared, hashed, uploaded and scheduled the release of v3.3.0 on the website. So I wont be recompiling it now until the next version, so please dont commit any new code changes to the v3.3.0 branch which was merged with master last night, and I'll merge your new changes with master tonight).

[tedsmith]

New packages made for v3.3.0 (thanks man). Changes to branch commited to master for Makefile.

[tedsmith]

Hey @darealshinji - not sure if you're still active and wanting to help, but I am struggling, for some reason (having done it last time) with the packager. I've just pushed some updates to the branch for newer versions of Lazxarus, FPC and v3.3.3 of QH that I am trying to build a Deb for. But despite having all the Lazarus stuff installed it breaks out the loop saying I need to install it. Can you advise?

[darealshinji]

I will take a look into it.

[darealshinji]

I have updated the packaging files and the Makefile in the v3.3.3 branch. If the script still thinks you need to install Lazarus you can simply confirm with "Y" to continue anyway.

[tedsmith]

You're a legend!! I'll take a look when I'm back home later. Thanks a million.

[tedsmith]

Gave it a try last night @darealshinji . On my system, the installation paths seem to be : /usr/lib/lazarus/2.2.0/, /usr/share/doc/lazarus/2.2.0 etc. So, when the script is executed, I get :

make[1]: Entering directory '<>' test -f dbases_sqlite.lrs.backup || cp dbases_sqlite.lrs dbases_sqlite.lrs.backup ; /usr/share/lazarus/2.0.12/tools/lazres dbases_sqlite.lrs dbases_sqlite.lfm ; /bin/sh: 1: /usr/share/lazarus/2.0.12/tools/lazres: not found make[1]: [Makefile:40: quickhash] Error 127 make[1]: Leaving directory '<>' dh_auto_build: error: make -j8 returned exit code 2 make: [debian/rules:4: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Lintian checks:

If I look in /usr/share/, there is no 'lazarus' sub folder. Any thoughts??

[darealshinji]

I have updated the Makefile and packaging files to work with Lazarus installed throgh APT.

[tedsmith]

Thanks as always. I did a pull and re-tried but on my system it is still looking for 2.0.12. Example :

/usr/share/lazarus/2.0.12/tools/lazres dbases_sqlite.lrs dbases_sqlite.lfm ; /bin/sh: 1: /usr/share/lazarus/2.0.12/tools/lazres : not found

lazres, on my system, is in /usr/lib/lazarus/2.2.0/tools/lazres

I THINK I configured Lazarus from the Linux Mint v21 package manager.

I hate to ask, but would it be easier (for you primarily) for you to just upload to releases or to email me the debs your system makes?

[darealshinji]

I've updated the Makefile on the v3.3.3 branch, not master branch. But yeah, I can upload the debs later here.

[tedsmith]

Ah! Sorry - I didn't notice that!! Yes, I've merged the changes via pull request to master and pulled with the new makefile, and I now have compiled Deb packages!! A million thanks. Great work as always

[tedsmith]

EditedScripts.zip Trying to package v3.3.4. The package ZVDateTimeCtrls has been removed from the project and pushed to master in favour of TDateTime from DateTimeCtrls unit.

Compiles OK on Windows and OSX and Linux (as binary). But the buildpackage.sh and Makefile are failing to create the debs. First problem was "quilt" is now needed but I solved that by installing the quickly dependancy seperately.

Then I tried removing references to ZVDateTimeCtrls in the scripts (edited versions attached), and "Clean and Build" the project, assuming that would remove any references to ZVDateTimeCtrls but I still get :

Error: (lazbuild) Broken dependency: ZVDateTimeCtrls make[1]: [Makefile:42: quickhash] Error 3 make[1]: Leaving directory '<>' dh_auto_build: error: make -j8 returned exit code 2 make: [debian/rules:4: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

I dont know enough about Linux scripts. Would you mind edited the MakeFile and buildpackage.sh to remove references to ZVDateTimeCtrls? I really want to get all three OS versions out together - Windows, Linux and OSX.

[darealshinji]

I have update the files on the branch v3.3.4 and packaging. I just had to apply some of the changes from quickhash.lpi to quickhash_linux.lpi.

[tedsmith]

OK, some good news and bad news. The good news is, the new version of the build packager works great, thanks. Finally got some time whilst I am off work to compile it. So the deb creates fine now, and it installed OK.

But, there is a snag.

The libewf so file that gets installed does not seem to be the one from the libs/64 master folder. The following are SHA1 hashes that file from the current master branch and the last few versions of the program :

2376c9092754abf401cfa1d17c00801daab4d143 master-libewf-Linux-x64.so 2376c9092754abf401cfa1d17c00801daab4d143 v334-libewf-Linux-x64.so 2376c9092754abf401cfa1d17c00801daab4d143 v333-libewf-Linux-x64.so 2376c9092754abf401cfa1d17c00801daab4d143 v332-libewf-Linux-x64.so

But, the one that ends up in /usr/lib/quickhash/libs/x64/ is :

068241cef71ecfc0f85ea2216482a80e48506f1f /usr/lib/quickhash/libs/x64/libewf-Linux-x64.so

So, having spent two hours today trying to work out what is going on there, do we know how the Debian package is dealing with the /libs/libewf-Linux-x64.so file? Is it being compiled direct from source by the Debian package manager? Or is it copying the SO file from master? If it's the former, then I'd understand how it would be different. But if it is the latter, then how\why is it generating a different version? I only noticed using the environment checker of quickhash, which has the expected hash of the libraries compiled into it, and it then computes the hashes of the libraries it finds with it. In this case, it is expecting 2376c9092754abf401cfa1d17c00801daab4d143 but calculating 068241cef71ecfc0f85ea2216482a80e48506f1f for /usr/lib/quickhash/libs/x64/libewf-Linux-x64.so

The only thing I can see impacting this is in the makefile, but that just looks like paths lookups and hasnt changed in a long time :

PREFIX ?= /usr BIN = quickhash QHARCH ?= x64 LIBEWF = libewf-Linux-$(QHARCH).so

[darealshinji]

Debian packaging automatically strips binaries which I guess even has an effect on already stripped files. I can exclude the file from being stripped.

[tedsmith]

Thank goodness for that! I was worried for a moment it might be more complex - I didnt know that about the stripping. Thanks very much - if you could.

[darealshinji]

However most of your pre-built libraries weren't stripped in the first place:

djcj@djcj:~/Downloads/quickhash/libs
$ file */*
x64/libewf-Linux-x64.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=488027096fb638fbe861e40f8b87a36864d14f47, with debug_info, not stripped
x64/libewf-x64.dll:      PE32+ executable (DLL) (console) x86-64, for MS Windows
x64/libgcc_s_dw2-1.dll:  PE32 executable (DLL) (console) Intel 80386, for MS Windows
x64/libwinpthread-1.dll: PE32+ executable (DLL) (console) x86-64 (stripped to external PDB), for MS Windows
x64/README.txt:          ASCII text
x64/sqlite3-win64.dll:   PE32+ executable (DLL) (console) x86-64, for MS Windows
x64/zlib1.dll:           PE32+ executable (DLL) (console) x86-64 (stripped to external PDB), for MS Windows
x86/libewf-x86.dll:      PE32 executable (DLL) (console) Intel 80386, for MS Windows
x86/libgcc_s_dw2-1.dll:  PE32 executable (DLL) (console) Intel 80386, for MS Windows
x86/libwinpthread-1.dll: PE32+ executable (DLL) (console) x86-64 (stripped to external PDB), for MS Windows
x86/README.txt:          ASCII text
x86/sqlite3-win32.dll:   PE32 executable (DLL) (console) Intel 80386, for MS Windows
x86/zlib1.dll:           PE32 executable (DLL) (console) Intel 80386, for MS Windows

I recommend you to use strip on the .so and the unstripped .dll files.

[tedsmith]

Mmmm. And running strip on libewf-Linux-x64.so results in 6e0211f8fccb4c1fdbacb878271d55e834b0cf80 which is different again to what the Debian stripping resulted though both have caused a resulting file of 1.5M instead of 4.5Mb. This isnt going to be a quick resolve I doubt. Urgh. Just when I thought v3.3.4 was about ready, more work to do.

(the sqlite3-*.dll are direct from the sqlite site so I'm guessing no stripping needed there)

Ted gives up temporarily.

[darealshinji]

Different checksum may come from from different versions of binutils being used? Or Debian packaging runs it with different arguments?

[darealshinji]

I think you didn't use the latest packaging files to create the v3.3.4 package: https://github.com/tedsmith/quickhash/commit/c549f088a8001a8c5b084137bd34a2aecfd67ebb

Those packaging scripts don't strip the library anymore.

Here is the re-built package. The library file inside the package is indeed unmodified, is still has the old checksum.

quickhash_3.3.4-1_amd64-rebuilt-v2.zip

By the way if you want to get the checksum of a file inside you can open it in gdebi and look at the md5sums file:

[tedsmith]

"I think you didn't use the latest packaging files to create the v3.3.4 package" - you're right, because I got all muddled with different branches and commits and in the end, I figured it was better to just ship them as they are and I added a disclaimer about the Linux so file in the form of a ReadMe. But I'll use the updated one for the next release. Thanks.

Thank you for providing a rebuilt package for me. I'll likely replace what I uploaded last night with this one once I've had chance to test it and make sure its all OK.