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 <[email protected]>
 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]

Looks very promising. I'll try to give it a whirl tonight if you like on my own system. Thanks again for your work and efforts.

[tedsmith]

I tested it on my own Linux Mint 17 LTS 64-bit distribution, and it worked perfectly!
So I have uploaded it to my website for others to download and try out, and perhaps with a little refinement I can think about submitting it to the Debian Package maintainers.

http://quickhash-gui.org/download/debian-package-v2-7-0-for-linux/

Thanks again for your help with is. It's awesome.

[tedsmith]

Was just looking at the Debian Package submission process (https://mentors.debian.net/) and I think the deb package has to be signed with a GPG key (https://mentors.debian.net/intro-maintainers).

I have generated a public and private key but I'm not sure what the procedure is for signing the package. Do you know? Am I best sending the key to you or is it a simple step?

[tedsmith]

Hi. Would you please be able to do what you did last time and create a DEB package for v2.8.0 from this published code? I'd appreciate it? By the way, you may or may not have noticed you are listed in the user manual! :-)

Quickhash-DebPackage-v2.8.0.tar.gz

[darealshinji]

Building from the packaging files created by lazbuild didn't work, so I was using my own build files again.
This time I've also added a 32 bit package.

quickhash-2.8.0-debian.zip

[tedsmith]

Superstar!! Thanks so much!! I'll add them to the release when I get the other binaries compiled.

[tedsmith]

Except shortly afterwards I realised there were a few issues still (handle error codes for Windows 10 most notably) so I've had to make some more changes annoyingly. If its OK, I'll get another source code bundle to you if you'd be happy enough to rebuild for me? Or if you can use the Github code, all the better. Sorry to be a nuisance.

[darealshinji]

Here you go:
quickhash-2.8.0-2017-02-15-debian.zip

[darealshinji]

By the way I suggest you to add the packaging files to a new branch, so you always have them available when you need them: https://github.com/darealshinji/quickhash/tree/packaging

[tedsmith]

Thank you once again! I've uploaded the packages to the website.

I take your point about the branches. I'm still trying to get to grips with git generally. I need to get into branching for sure.

[darealshinji]

Should I create a new branch with the packaging files, now that I have write access to your repository?

[tedsmith]

That would be great! Yes please. Ted Sent from Yahoo Mail on Android

[darealshinji]

Here they are on a new branch: https://github.com/tedsmith/quickhash/tree/packaging

[darealshinji]

Debian packages for 2.8.2: qh282-deb.zip

[tedsmith]

Brilliant! Thank you. Added to the website http://quickhash-gui.org/download/quickhash-v2-8-2-debian-packages-for-linux/

[darealshinji]

Newest version: quickhash-2.8.3-debian.zip

[tedsmith]

Brilliant. Thank you sir! Have uploaded to the site.

[darealshinji]

Version 2.8.4: quickhash-2.8.4-debian.zip

[tedsmith]

So fast! Many thanks. Added to the website.

[tedsmith]

Is there any chance you would be able to generate a deb package for v3.0.1 master using your scripts? I'd appreciate it but if not I will look into doing it.

[darealshinji]

Here you go: quickhash-3.0.1-deb.zip

[tedsmith]

Sorry to come back so quickly, but v3.0.2 is out which fixed several bugs but one of them was quite important so I couldn't delay the release. Its committed to master.

[darealshinji]

quickhash-3.0.2-deb.zip

[tedsmith]

@darealshinji v3.0.3 is out, if you are still able to do the honours for me? However, I just discovered after wrapping up a pre-compiled binary up which worked fine within the Lazarus IDE did not work when executed standalone. I initially assumed it was due to the paths changing to the sqlite.so files, but upon inspection, my 64-bit Linux Mint 19.1 system still has the sqlite so files in the very first line where Quickhash looks for it. So it must be something else but I am too knackered to look now having spent several evenings on the trot compiling for the various operating systems

[darealshinji]

I'm currently having some issues compiling it.
Compiling through command line gives this error:
<<BUILDDIR>>/HashLib4Pascal/HashLib/src/Base/HlpConverters.pas(14,3) Fatal: (10022) Can't find unit StrUtils used by HlpConverters
And when I try to load DateTimePicker in the IDE it says it can't find "clocale".

Update:
I figured out the issue were old config files laying around everywhere. It's building now. Will upload .deb packages soon.

[darealshinji]

quickhash_3.0.3-1_deb.zip

[tedsmith]

You're a rock star! It works perfectly on my Linux Mint system. Thanks. I'll get it uploaded to the website over the weekend.

I'm interested to know why the compiled binary I made last night did not work though. Did you have to make any code changes to get it working, or did you just have to do some clean up? If it was code, do I need to merge a commit somewhere?

[darealshinji]

I didn't make any code changes despite ecc79b3 ( 3549e3f is not included in this one). I used the build script from the packaging branch. Maybe the resource files had to be updated? It's always done when building with the make command.

[tedsmith]

I've re-pushed diskspecification.lfm to master. And uprogress and uKnownHashLists are also needed. I'm muddled as to why it wont build for you with Makefile. They're needed in order to facilitate disk data in both Windows & Linux along with hash based lookups from known imported hash lists.

Hopefully you'll be able to build?

Perhaps I should try from my end as I was able to compile the Linux binary with these units etc included. ??

[tedsmith]

@darealshinji I just pulled master to a temp folder and confirm all compiles OK using Lazarus 2.0.10. So that's good. And the program no longer crashes in Disk Hashing tab on Linux if the user right clicks a disk and chooses to view technical data, but it doesn't show anything either (as lteast not on Linux Mint 19.3) but I can work on that for the next release. At least it no longer causes the fatal exception errors. So I am happy for us to compile this into Debian packages as v3.2.0 if you are able to help me there?

[darealshinji]

Here's the package: quickhash_3.1.0-1_amd64-deb.zip
Do you still need a 32 bit package too?
I made 2 pull requests with small changes I had to make to build this package.

[tedsmith]

Thanks man...awesome! Much appreciated.

I've stopped doing 32-bit for Windows and OSX and I see little point these days in continuing it for Linux. Instead I've told users to e-mail me if they desperately need it and I'll compile on an "as is" basis.

[tedsmith]

Oooops - darn...sorry man....it is showing as v3.1.0, but master is at 3.2.0 now. I don't know if that is a typo or if its from one of the project files that maybe I forgot to update. I'm sure I updated it in the "normal" lpi file for exe compilations etc but maybe not in the linux lpi one?

[tedsmith]

@darealshinji hey sir..hope you are well etc.

v3.3.0 is nearing readiness for release. I would like to have compiled exe, .app and .deb on the website by Friday night for a scheduled release on Saturday 29th, which will be the 10 year anniversary of the tool.

It would be great to have Debian packages ready for that and whilst I managed it last time, you seem far better at it than I am. I hoped you could help me out with PREPARING the packaging script in the v3.3.0 branch makefile to ensure the data in the misc folder and the right Lazarus versions etc are set so that when I execute it on Friday night'ish, it all just works?

I will aim to commit the branch to master of course before I run the script. So if you make any changes to the version in the branch we can push those to the branch as well and then I'll merge the lot to master ASAP.

Basically, I use x64 version of Lazarus v2.0.12 now. Freepascal v3.2.0. The e-mail needs to be [email protected]. The version needs to be v3.3.0.

The new logo files in /misc need to be included. And, for Linux 64-bit, there is now a libewf-Linux-x64.so file in a subfolder called /libs/x64 that needs to be included. I've looked at the makefile and it looks like the following values need to be specified :

LAZARUSDIR ?= /usr/share/lazarus/2.0.12/
LAZBUILD := $(LAZARUSDIR)lazbuild
LAZRES := $(LAZARUSDIR)tools/lazres

RESFILES = dbases_sqlite.lrs frmaboutunit.lrs udisplaygrid.lrs unit2.lrs udisplaygrid3.lrs uenvironmentchecker.lrs

But I'm not sure about the new SO file that needs to be added, libewf-Linux-x64.so, in /libs/x64? How do we add that to a Deb? Can we even do so?

I've not been able to compile that library for 32-bit so I'll have to skip a 32-bit Debian package for now until I get time. So all I need for now is the script prepared for 64-bit compilation of a Deb package. Would you be able to help me with that? I'd massively appreciate. But as ever, don't worry if not. I know it is short notice.

Thanks

[darealshinji]

I'll look into it. Honestly, just skip 32 bit Linux at all.

PS: you should better add a link to https://github.com/libyal/libewf in your Readme since that project is LGPL.

[tedsmith]

Re the libewf credit - it is given in the header of ulibewf.pas and user manual. But I'll add it to README too.

Re compiling - it took some doing (for Windows), but eventually managed it for Linux libyal/libewf#152

[darealshinji]

Okay, I pushed commits to the v3.3.0 branch and the packaging branch. Add the Linux library of ewf to the libs directory where the dll files are.

[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:
c549f08

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.