Package Details: gtkhash 1.4-5

Git Clone URL: (read-only, click to copy)
Package Base: gtkhash
Description: A GTK+ utility for computing message digests or checksums
Upstream URL:
Keywords: crc32 digest hash md5 sha1 sha256 sha512
Licenses: GPL
Conflicts: gtkhash-caja, gtkhash-nautilus, gtkhash-nemo, gtkhash-thunar
Provides: gtkhash
Submitter: None
Maintainer: Sam-Burgos
Last Packager: Sam-Burgos
Votes: 67
Popularity: 0.37
First Submitted: 2008-05-11 12:46 (UTC)
Last Updated: 2021-12-29 22:22 (UTC)

Pinned Comments

Latest Comments

Boris78 commented on 2022-02-04 08:38 (UTC)

@Sam-Burgos: Great work ... Thank you

walkingstickfan commented on 2021-12-31 13:23 (UTC)

@Sam-Burgos: Outstanding work! Thank you!

Sam-Burgos commented on 2021-12-29 22:32 (UTC)

@walkingstickfan: it has been hard to test about how to detach the standalone application compared to their filemanager plugins, so far I have been testing and it is until recently that I have been able to come up with something (hoping that it works), also as I mentioned a little bit down, the compilation issue was my mistake after letting an escape line there (took me a while and a lot of coffee to see that one)

walkingstickfan commented on 2021-12-29 19:19 (UTC) (edited on 2021-12-29 19:22 (UTC) by walkingstickfan)

@Sam-Burgos: GtkHash runs fine without being tied to any file manager. I fail to understand the need to tie it to any file manager. You mentioned that is the way it's done under Manjaro. Well, under Debian it isn't done that way, so why not follow that philosophy or at least make it easier for end users to opt out of installing a bunch of packages they don't want. @userpuser: You're welcome. I'm glad you found the modification useful.

walkingstickfan commented on 2021-12-29 19:16 (UTC)

There's a bug in the current package release. Following is the error I'm getting when running makepkg -si after stripping out the file manager tie-ins in the PKGBUILD file. Note: I used my modified PKGBUILD for v1.4-2 and was able to install v1.4-4.

checking build system type... Invalid configuration make': machinemake-unknown' not recognized configure: error: /bin/sh build-aux/config.sub make failed ==> ERROR: A failure occurred in build(). Aborting...

Sam-Burgos commented on 2021-12-28 15:54 (UTC)

@GI_Jack @blubbblubb: my mistake, it seems that I somehow left a escape line on the PKGBUILD file and that was causing all the issue, if the issue persists then clean the cache of your AUR helper (or Pamac in case you are using that) and try again, I just updated the package with the corrections

blubbblubb commented on 2021-12-26 12:58 (UTC)

@GI_Jack try removing all trailing whitespaces from the configure lines, that worked for me. (I also removed all dependencies and package names for file managers i'm not running, so i can't say for sure there are no other necessary fixes for anything besides gtkhash and gtkhash-thunar)

GI_Jack commented on 2021-12-26 06:45 (UTC)

package fails:

`` ==> Starting build()... configure: WARNING: you should use --build, --host, --target configure: WARNING: invalid host type: ... checking build system type... config.sub: missing argument checking build system type... config.sub: missing argument Tryconfig.sub --help' for more information. configure: error: /bin/sh build-aux/config.sub failed ==> ERROR: A failure occurred in build(). Aborting...

userpuser commented on 2021-12-25 09:35 (UTC)

@Sam-Burgos Do not be offended, I did not mean anything bad. It's just that these "additions" in the form of mate-desktop, libnautilus etc. are completely superfluous and do not correspond to Arch's philosophy. For me, this option as suggested by @walkingstickfan is more than enough. Thanks anyway for maintaining this package.

Sam-Burgos commented on 2021-12-25 00:03 (UTC)

@rado84: I will add that dependency then, it is strange since probably another package install that libb2 which means that this doesn't require it, either as a make-depends or depends, if that is the case then I will add it

@userpuser @walkingstickfan @tped: there is no need for call other packages as baggage, neither to "insult" them, as a user myself I have Cinnamon installed and I don't use KDE, but that doesn't mean that I consider other DE as "trash", "baggage" or any other thing, so please refrain from insulting each other

@userpuser @walkingstickfan: I have tried to check some options but so far I have copied the way Manjaro does it, if you don't like the package, or you use other AUR helper, feel free to remove the other options, since I have tried to do so in order to prevent that situation with no avail

userpuser commented on 2021-12-24 02:15 (UTC) (edited on 2021-12-24 06:03 (UTC) by userpuser)

I have the same. This package failed on build. Plus, on top of that, it pulls along a bunch of unnecessary packages. I have Cinnamon installed. Why do I need Mate-desktop, Caja, etc. ??? @walkingstickfan Thank you!

rado84 commented on 2021-12-23 22:41 (UTC)

This package failed on build, so I downloaded the source from github and built it manually (requires libb2). Only then the building worked.

walkingstickfan commented on 2021-11-28 10:23 (UTC)

@tped: GTK baggage? Install the Falkon browser and see all of the KDE baggage that gets installed. That's baggage!

walkingstickfan commented on 2021-11-28 10:10 (UTC) (edited on 2021-11-28 10:19 (UTC) by walkingstickfan)

A better way to create the PKGBUILD file, if possible, is to ask the user if they want file manager extensions or not and if so, which ones or all. I was able to modify the PKGBUILD file for v1.4-2 to only install GtkHash, but I have coding experience. Others who don't have coding experience would probably be stumped.

In the interim, for those who only want to install GtkHash, here's the PKGBUILD file to do that:

# Maintainer: carstene1ns <arch carsten-teibes de> -
# Co-Maintainer: Sam Burgos < santiago dot burgos1089 at gmail dot com >
# Contributor: Jan Böhringer <>
# Contributor: Frédérik Paradis <>
# Contributor: GI_Jack <>

pkgdesc="A GTK+ utility for computing message digests or checksums"
arch=('i686' 'x86_64' 'mips64el')



build() {
  cd gtkhash-$pkgver

  echo "${pkgname[@]}"

  ./configure \
    --prefix=/usr \
    --disable-schemas-compile \
    --enable-gtkhash \
    --enable-linux-crypto \
    --enable-nettle \
    --disable-blake2 \
    --with-gtk=3.0 \


  #./configure --prefix=/usr --disable-schemas-compile --enable-gtkhash \
  #            --enable-linux-crypto --enable-nettle --disable-blake2 --with-gtk=3.0 \
  #            --enable-nemo --enable-nautilus --enable-thunar --enable-caja # ← remove FMs here!

package_gtkhash() {

  make -C gtkhash-$pkgver DESTDIR="$pkgdir/" install

tped commented on 2020-11-14 11:40 (UTC)

Thanks Sam. You were right there is a checksum built into Dolphin. GTKHash was more of an old habit for me, I used it a lot. I also see the GTK dependency baggage you mentioned - time to change my habits! Thanks for the research and quick follow-up

Sam-Burgos commented on 2020-11-13 17:16 (UTC)

@tped: it took me a while to investigate but as far as I know Dolphin (KDE file manager) has a built-in checksum function, though I'm not a KDE user but so far I found this particular package on the KDE store, you can try if that works for you because even though gtkhash doesn't necessary has to have a file manager associated (researching how-to as I type) but it has some dependencies to GTK, which might pull some dependencies from that desktop environment that you won't need. Nevertheless I will try to find a way to separate, since this not only depends on me but also the main maintainer

@armadillo: I will check if there is any way we can separate this, so far on my test there shouldn't be any issues regarding installing other file managers (unless Nautilus changed once again the result of "xdg-mime query default inode/directory", which means I have to update it again). If you can help me to send the result of that command so I can recheck it and add it as well

@carstene1ns: Let me see if either I can replicate the old behaviour somehow, or if there is any need to split the packages, I can hep you with the maintenance

tped commented on 2020-11-12 11:52 (UTC) (edited on 2020-11-12 12:12 (UTC) by tped)

Hello. I am recreating my desktop system using Manjaro ARM Plasma on a Raspberry Pi 4. Default file manager is Dolphin.

$ xdg-mime query default inode/directory org.kde.dolphin.desktop

Does gtkhash HAVE to have a file manager dependency? I've always used it as a stand-alone on my x86 machine (Mint) - I appear to have an older version (0.7.0) on that machine

armadillo commented on 2020-10-08 06:21 (UTC)

I'm having trouble getting this package installed correctly on one of my systems. I have Nautilus as my default file manager, but building this package also installs nemo. Nemo then gets set as the default file manager during the build process, and the package installer decides it needs to install the gtkhash extension for Nemo rather than Nautilus. Any thoughts on working around this please, without having to manually edit the package?

carstene1ns commented on 2020-07-23 16:05 (UTC) (edited on 2020-07-23 16:07 (UTC) by carstene1ns)

My 2 cents on the situation:

The general problem is here, that each split package refers to an own desktop environment. The way this PKGBUILD was written, has been for inclusion in the official repos. The packages are built in a clean chroot, all dependencies are satisfied. When installing the user chooses the right file manager plugin and only needs the dependencies for that specific file manager. Users are expected to read a PKGBUILD before building, so they could always remove the unneeded dependencies for their desktop environment.

Nowadays the package has some auto-detection, which is considered bad style. This way it may or may not work, since the mime query is not guaranteed to return the correct thing. Also, it will never be included in official repos this way. However, it may be easier for users with aur helpers (which do not read PKGBUILDs).

I initially thought about creating separate packages for all file manager plugins, this way it would also be easier for the users. However, it increases the maintenance burden a lot, since each package needs to be updated upon release. Also inter-dependencies can cause problems: Think of an old file manager plugin that crashes because the library is newer. You are left with a broken system until you figure out that you did a partial aur update. That is why I opted against it.

agarbathi commented on 2020-07-19 20:35 (UTC)

Can you better explain please, what to do? Maybe with an example! Thank You

Sam-Burgos commented on 2020-07-17 14:12 (UTC)

@rouhannb: I actually saw your comment, the thing is I have also been very busy with my job but I noted and that is one of the pending things to do

As for the other comment this situation is quite tricky, the "old way" was to install the libraries required for all desktop environments (which depending on the configuration of your AUR helper, this might leave you with 2 or more incomplete desktop environments after the build and you having to remove manually the other packages) which was not desired, after checking the comments and being added as co-maintainer I tried to come up with a solution to install the required package and the respective file manager plugin (which I have come so far), leaving this as "either you install all or install one, that's it"

It might be up to the maintainer if he decides to delete the PKGBUILD and create it another way, since I cannot perform much changes and so far this is the only idea (besides delete all and create them once again) that I can use related to this

rouhannb commented on 2020-07-17 06:03 (UTC) (edited on 2020-07-17 06:06 (UTC) by rouhannb)

I’m not exactly sure if you noticed, but I left a comment a few days ago which said that the desktop entry for Nautilus / GNOME Files was incorrect (the correct one is org.gnome.Nautilus.desktop, which is also the output of xdg-mime query default inode/directory). Maybe you just haven’t gotten around to changing it, but you posted a comment the next day, so I’m reminding you just in case you missed it.

Additionally, I’m not exactly sure if setting makedepends in the build() function will accomplish anything, seeing as the package has, well, already started to build. It seems that makepkg only reads makedepends when it sources the PKGBUILD, so (I think) the code that detects which file manager the user has installed and sets makedepends accordingly should be moved outside of build() and into the main area.

rouhannb commented on 2020-07-13 17:17 (UTC)

Line 56 seems to be incorrect; the name of Files’s desktop entry is not nautilus.desktop but org.gnome.Nautilus.desktop.

Shikaku commented on 2020-07-12 21:51 (UTC)

I had to remove the other parts of the pkgbuild and keep gtkhash-thunar, the pkgbuild erroneously tries to build all of the versions for each of the desktop managers and fails

SpectralMemories commented on 2018-09-21 01:27 (UTC)

Hum why do I need to install entire desktop (cinnamon and mate) to install a simple front end? Is this a mistake?

annoyingduck commented on 2018-08-09 01:45 (UTC)

So with the help from user Loqs, we were able to get the package to build and suppress the Thunarx-2 package error. Unfortunately the gtkhash-thunar plugin still no longer appears in Thunar 1.8, even with a rebuild. Here's a link to the forum post discussing the issue: I'd like someone to help in getting the Thunar plugin working again.

annoyingduck commented on 2018-08-05 03:21 (UTC)

Anyone know how to get the Thunar plugin working on the current Thunar version? The hash option has disappeared since the Thunar update.

FredBezies commented on 2018-05-27 16:20 (UTC)

What about using PKGBUILD for twa022 comment? You can enable which filemanager to use.

twa022 commented on 2017-12-25 17:42 (UTC)

Here's another PKGBUILD: supports thunarx-2 (GTK2 thunar from [extra]) or thunarx-3 (GTK3 thunar: thunar-devel or thunar-git) determinted at build time based on which version you have installed. Also supports specifying filemanager plugins to build.

twa022 commented on 2017-12-15 02:06 (UTC)

The plugin works fine with the GTK3 version of thunar, here is a PKGBUILD that supports adjusting the build at compile time depending on installed thunar version:

spinvis commented on 2017-10-21 12:36 (UTC)

Works great, thanks so much. To all the people complaining, read the PKGBUILD before compiling. It ain't hard, stop being lazy.

Plexcon commented on 2017-08-02 08:41 (UTC) (edited on 2017-08-02 08:46 (UTC) by Plexcon)

configure: error: Package requirements (thunarx-2) were not met: No package 'thunarx-2' found ==> ERROR: Se produjo un fallo en build(). Cancelando...

annoyingduck commented on 2017-06-14 18:43 (UTC)

@MorningStarGG The maintainer explains in the comments as to why all file managers & dependencies are installed (it's easier for him to maintain). If you use Pamac and have "remove unrequired dependencies" option selected, just install the gtkhash package, go back into Pamac and click just the file managers you do not need (ex: nautilus, nemo, caja) and let Pamac remove all of those & all of the packages that the GTKhash script pulled in. It's a very simple and quick way to install/update this package. Or you can do it via Pacman (ex: sudo pacman -Rs nautilus nemo caja) which will remove those file managers and all the dependencies including the un-needed gtkhash file manager plugins.

MorningStarGG commented on 2017-06-14 13:04 (UTC)

Ok requiring "caja, libnautilus-extension, nemo" are just totally overboard for this on an XFCE based system, which is generally who would be running Thunar. By requiring those dependencies you bring in some other desktop packages from those related filemanagers and such. It's messy, and just does not need to happen. I went through via yaourt and edited the PKGBUILD before it ran and removed those mentioned above, and installed it just fine without those, and it's working just fine without those. Please fix this.

annoyingduck commented on 2017-05-04 16:06 (UTC)

I forgot to reply back here. Current updated build 1.1-1 has been working perfect with current Thunar on XFCE. All issues resolved, just wanted to note that here.

ncoder-2 commented on 2017-04-22 16:11 (UTC)

Is there a reason to have cinnamon-desktop, nemo, thunar, and a whole lot of other packages as dependencies if someone only has GNOME and wants gtkhash for Nautilus only?

T0t0 commented on 2017-04-20 01:01 (UTC)

There is a problem of dependence. If I chose gtkhash-nemo, I need to install caja, mate-desktop, and thunar ???? I said that I cinnamon.

annoyingduck commented on 2017-02-18 19:39 (UTC)

@carstene1ns the XFCE devs are looking into the issue via bugzilla. Sorry, but I'm not sure how to go about building this using git history. Can it be done via yoaurt or do I download the old version source and build via mkpkg?

carstene1ns commented on 2017-02-11 20:02 (UTC)

annoyingduck: You can use the git history of this repository, just go back one commit. However, I would try contacting upstream to get version 1.0 fixed instead. Not using Thunar here and the caja plugin seems to work for me.

annoyingduck commented on 2017-02-11 16:09 (UTC)

Anyone have a link/package to build version 0.7.0-3 of gtkhash & gtkhash-thunar? New Arch XFCE install and cannot get the 1.0-1 version to work.

pjpreilly commented on 2017-01-18 02:15 (UTC) (edited on 2017-01-18 02:35 (UTC) by pjpreilly)

@annoyingduck I'm gonna open an xfce4 bug report. Add to this as you see fit.

annoyingduck commented on 2017-01-18 01:15 (UTC)

Another note on the Thunar crash: I tested Thunar running on Cinnamon with gtkhash-thunar 1.0-1 and there is NO crash. It's only happening on XFCE which is just weird. @pjprelly notes about the desktop could be a clue, as Thunar has nothing to do with Cinnamon's desktop.

pjpreilly commented on 2017-01-17 18:31 (UTC) (edited on 2017-01-17 19:16 (UTC) by pjpreilly)

Here's what I found as to how the bug works: 1. Restart system 2. Right click on the xfce desktop or any icon on it 3. Click on Properties 4. It works fine & the system will not encounter the bug again in this session. Here's how to see the bug: 1. Restart system 2. Open a folder anywhere (Desktop or launch Thunar) 3. Right click on anything (not a folder, it must be a file) & click on Properties 4. Thunar crashes So, as soon as you do a Properties on the Desktop or anything on the Desktop you will rectify the Thunar crash scenario for the current session. CAN ANYONE CONFIRM THIS?

Stebs commented on 2017-01-13 16:24 (UTC)

> Anyone else having Thunar crash on XFCE when accessing properties on the latest gtkhash-thunar update? Yes: Thunar[29917]: segfault at 7f6a556ec468 ip 00007f6a62cbbcda sp 00007ffd2b2162d0 error 4 in[7f6a62c46000+18b000]

annoyingduck commented on 2017-01-09 19:01 (UTC) (edited on 2017-01-09 19:27 (UTC) by annoyingduck)

Anyone else having Thunar crash on XFCE when accessing properties on the latest gtkhash-thunar update? Removing the plugin restores access to properties, but obviously at the loss of the plugin. FYI - I remove caja/nemo/nautilus and all the dependencies that go with those programs. Edit: I downgraded to the previous build 0.7.0-3 of both gtkhash and gtkhash-thunar and it is working on XFCE. I'm not having issues on the new build for Caja or Nemo on Cinnamon and XFCE, only Thunar.

carstene1ns commented on 2016-03-15 18:43 (UTC) (edited on 2017-01-05 15:09 (UTC) by carstene1ns)

@vith: Because this is a split package. Unfortunately the build system does not support automagic dependencies and therefore i enabled all file manager plugins. I would recommend building in a clean chroot or manually changing the lines 14 and 24 in the PKGBUILD file to not install the unneeded ones.

vith commented on 2016-03-15 14:33 (UTC)

Why does gtkhash-nautilus need cinnamon-desktop and nemo? pacaur output:

zerophase commented on 2015-12-03 16:09 (UTC)

I'm trying to write a nemo_action, so I can just right click and run all of the hashes I'm interested in seeing. I've managed to get files to open in gtkhash, but cannot figure out the command for running the hash options when the file is opened? Is there an argument I need to pass I don't see one in help.

Lillypad commented on 2014-12-31 15:38 (UTC)

I'm sorry it took me so long to post back on this. Thank you very much for your help with this! I shouldn't have been so lazy... You were exactly right about aura. I really appreciate the extra effort of making the video of the build as well. Kudos for the great support!

carstene1ns commented on 2014-11-01 10:37 (UTC)

From what I have read, aura does not have proper split package support, so it cannot find the gtkhash-thunar package. Other aur helpers (aurget!) will map it correctly to this package group. However, without a log from your building attempt, I cannot do much to help you. Please use a pastebin like to upload the output of your makepkg/aur helper session that shows the error. It is also possible to build this package manually (I made the same changes you described to disable the other file manager plugins): Sorry for the late reply, hope this helps.

Lillypad commented on 2014-10-28 14:43 (UTC)

Out of curiosity, I have not been able to get this package to build since it was updated to its current version on 2014-06-13. I am an XFCE user, therefore, only require the thunar plugin. I have tried removing 'nemo' and 'libnautilus-extension' from the makedepends line, and I have removed '--enable-nemo' and 'enable-nautilus' from the configure section. I have also tried only removing '--enable-nemo' and '--enable-nautilus' while leaving the makedepends intact, yet the packages still fails to build. Any thoughts as to why this would occur? Also, I attempted installing gtkhash-thunar, but my aur helper, aura, can not find gtkhash-thunar as a valid aur package. Thanks for any assistance.

carstene1ns commented on 2014-06-13 13:46 (UTC)

This is now a proper split package. All three filemanager plugins are enabled, you need to disable them manually. FYI: You can also install gtkhash and the plugins from my repository, instructions here:

carstene1ns commented on 2013-12-05 02:04 (UTC)

Adopted, corrected and updated to version 0.7.0. If you want to use the filemanager plugins, enable them in the PKGBUILD.

GI_Jack commented on 2013-08-13 21:45 (UTC)

@carstene1ns sorry for not gettin back to you, yes, I've love the packages to get merged. I don't mind enabling nemo support, but not sure how to do that as opposed to just nautilus(which has --enable-nautilus in ./configure)

GI_Jack commented on 2013-08-08 16:54 (UTC)

removed mhash support for now, that seems to be causing the seg fault. I thought I fixed that some time ago, I guess not. There is a patch floating somewherearound to make mhash and gtkhash work, I do not have said patch. with --enable-linux-crypto, however, most commonly used hash algorythms will work. you miss out on haval, gost, and snerfru, which require mhash.

yweb commented on 2013-07-24 12:16 (UTC)

I'm unable to use it with nautilus 3.8.2. When I clic on Proprieties in contextual menu nautilus crashes. I also tried to execute gtkhash in a terminal but I get a segmentation fault. Maybe these two things are directly connected

yweb commented on 2013-07-24 12:09 (UTC)

I'm unable to use it with nautilus 3.8.2. When I clic on Proprieties in contextual menu nautilus crashes. I also tried to execute gtkhash in a terminal but I get a segmentation fault. Maybe these two things are directly connected

mladoux commented on 2013-07-16 02:26 (UTC)

Changes: * Removed nautilus dependency * Removed deprecated --with-mcrypt flag * Fixed directory name TODO: * Update to use new makepkg structure.

carstene1ns commented on 2013-05-11 21:26 (UTC)

Also a 'gtkhash-nemo' package can be added then, so we have 4 packages and the user can decide which one (or two) to install. I see the gtkhash package is currently unmaintained, so it can be changed as well. Just tell me what you think about it, when we have a solution, just someone has to post to the aur mailinglist and the TU's will merge the packages.

carstene1ns commented on 2013-05-11 21:15 (UTC)

Please move everything after first "make" into seperate package() function to comply to AUR guidelines. Also I think it would be a good idea to split this package in two seperate 'gtkhash-thunar' and 'gtkhash-nautilus' packages only providing the plugins and the old 'gtkhash' package only providing the executable.

GI_Jack commented on 2013-05-11 18:25 (UTC)

problem, PKGBUILD used some funny syntax that worked in previous versions: solution: PKGBUILD cleaned up, now uses $srcdir and $pkgdir like its supposed to. added new options to ./configure, clarified dependencies, and wrote some instructions in the comments. please follow the instructions. the plugin exists under the "properties" menu for a file. it adds the tab "digests".

thomasplessner commented on 2013-05-06 12:34 (UTC)

This PKGBUILD doesn't install the gtkhash binary, plugins etc., just schemas. Building from source does work though (although I still haven't figured out how to actually use the Thunar plugin). Can it be corrected, please?

Zeroedout commented on 2013-04-17 08:59 (UTC)

IIRC trusted users should be able to do it.... but worst case scenario send an e-mail to one of the Arch Linux devs?

GI_Jack commented on 2012-10-17 14:24 (UTC)

how can I delete this. I uploaded it by mistake use -withplugins instead.

GI_Jack commented on 2012-10-17 14:24 (UTC)

meh, I forked it for built in support for nautilus and thunar.

GI_Jack commented on 2012-10-17 00:41 (UTC)

in the ./configure line in build() can you add --enable-linux-crypto? Also please add optdepends=('Nautilus' 'Thunar' 'libgcrypt' 'zlib') as per README file.

commented on 2012-06-19 22:14 (UTC)

Thanks stalker254 for your comment. The modification is made.

stalker254 commented on 2012-06-17 07:27 (UTC)

Please add "intltool" in the line depends:"depends=('gtk2' 'mhash' 'gconf' 'intltool').

commented on 2012-05-21 21:10 (UTC)

@dario86 Do you have an archlinux installation on a mips64el cpu?

commented on 2012-05-07 12:44 (UTC)

It works. Thank you.

commented on 2012-05-07 02:28 (UTC)

Thanks dario86 for your comment. The modifications are made.

commented on 2012-05-06 20:42 (UTC)

This package works unmodified on mips64el architecture. Please, replace "arch=('i686' 'x86_64')" with "arch=('i686' 'x86_64' 'mips64el')".

commented on 2012-05-06 20:41 (UTC)

This package requires gconf.