Open darealshinji opened 7 years ago
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.
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.
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?
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! :-)
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.
Superstar!! Thanks so much!! I'll add them to the release when I get the other binaries compiled.
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.
Here you go: quickhash-2.8.0-2017-02-15-debian.zip
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
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.
Should I create a new branch with the packaging files, now that I have write access to your repository?
That would be great! Yes please.
Ted
Sent from Yahoo Mail on Android
Here they are on a new branch: https://github.com/tedsmith/quickhash/tree/packaging
Debian packages for 2.8.2: qh282-deb.zip
Brilliant! Thank you. Added to the website http://quickhash-gui.org/download/quickhash-v2-8-2-debian-packages-for-linux/
Newest version: quickhash-2.8.3-debian.zip
Brilliant. Thank you sir! Have uploaded to the site.
Version 2.8.4: quickhash-2.8.4-debian.zip
So fast! Many thanks. Added to the website.
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.
Here you go: quickhash-3.0.1-deb.zip
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 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
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.
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?
I didn't make any code changes despite https://github.com/tedsmith/quickhash/commit/ecc79b35b23968c5bc8f6401bf0d7ecedc4f6f58 ( https://github.com/tedsmith/quickhash/commit/3549e3fad9fb55092bd9610a32d1815a77fe1759 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.
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.
This may be the issue I tried to fix in https://github.com/tedsmith/quickhash/commit/3549e3fad9fb55092bd9610a32d1815a77fe1759 . I discovered that if I run the 32 bit binary on my 64 bit system, it picks the first library present and tries to use that one. But that would be the 64 bit library in /usr/lib/x86_64-linux-gnu
which doesn't work with 32 bit binaries.
Here it says:
For SQLDB database connectors, at least recent FPC versions try to load some default library names, but may fail. Using SQLDBLibraryLoader, you can specify the exact filename to load.
Does that mean there's a way to let this being handled automatically? And if not, maybe it's better to iterate through the paths and actually try to load all the libraries present (currently it seems to pick the first existing library and only checks that one). Here's what I mean in pseudo code:
SQLitePaths = '/usr/lib/x86_64-linux-gnu/libsqlite3.so.0',
'/usr/lib/i386-linux-gnu/libsqlite3.so.0',
...
'/lib/libsqlite3.so.0';
for each libPath in SQLitePaths
begin
if fileExists(libPath) then
begin
SQLDB.LoadLibrary(libPath)
if SQLDB.LibraryWasLoaded then
begin
stop checking and continue with the database stuff...
end
end
end
if not SQLDB.LibraryWasLoaded then
begin
error: cannot find/load the sqlite library
end
but loading all the libraries present seems extreme? I'll try and get round to trying out the latest commit on Linux Mint 19 later and see how it gets on there.
Is there no way to link the app directly against libsqlite3?
Im not sure about that one. Ill see if I can find out.
Meanwhile note the new branch, v3.0.4. The unti2.lfm main form got fubarred somehow with everything being right aligned. So I've taken the v3.0.3 version and overwritten it in the v3.0.4 branch.
Please could you compile the debs again for v.3.0.4 this time? Sorry it was soon after 3.0.3 but there were few things I and other users did not like.
thank you sir.
@darealshinji v3.1.0 has been committed to master. Could you do your usual Debian package wrap up for me please when you can?
@darealshinji I've updated packaging branch for v3.1.0 and adjusted the e-mail address etc. I've attempted to run the build script but it still asks for v1.8.x of Lazarus, whereas v3.1.0 was built with v2.0.4 of Lazarus. I assumed there would be a variable in the script where I could just update what it was looking for but I can't see where it looks for the version. So I tried removing the version check part and saved it and then re-ran the buildscript. But it failed with :
Makefile:39: recipe for target 'quickhash' failed
make[1]: [quickhash] Error 127
make[1]: Leaving directory '<
Not sure where I go next? Can you help me?
https://github.com/tedsmith/quickhash/pull/61 fixes your issue.
Note: those packages were build using the patch from https://github.com/tedsmith/quickhash/pull/62
Thanks man! You're a diamond as ever.
I'm trying to build version 3.2.0 but it fails because diskspecification.lfm
is missing:
(3104) Compiling diskspecification.pas
/home/djcj/Downloads/quickhash-tmp/diskspecification.pas(38,1) Error: (9031) Can't open resource file "/home/djcj/Downloads/quickhash-tmp/diskspecification.lfm"
/home/djcj/Downloads/quickhash-tmp/diskspecification.pas(38,1) Fatal: (10026) There were 1 errors compiling module, stopping
In order to compile it with the Makefile I had to re-add quickhash_linux.lpi, uKnownHashLists.pas and uprogress.lfm. And I had to remove the unit diskspecification.
Update: I made a PR
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. ??
@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?
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.
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.
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?
@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 tedsmith@quickhash-gui.org. 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
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.
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 https://github.com/libyal/libewf/issues/152
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.
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