Package Details: gtkhash 1.5-3

Git Clone URL: https://aur.archlinux.org/gtkhash.git (read-only, click to copy)
Package Base: gtkhash
Description: A GTK+ utility for computing message digests or checksums
Upstream URL: https://github.com/tristanheaven/gtkhash
Keywords: crc32 digest hash md5 sha1 sha256 sha512
Licenses: GPL
Conflicts: gtkhash-caja, gtkhash-nautilus, gtkhash-nemo, gtkhash-thunar
Provides: gtkhash
Submitter: None
Maintainer: Santi-Burgos
Last Packager: Santi-Burgos
Votes: 68
Popularity: 0.52
First Submitted: 2008-05-11 12:46 (UTC)
Last Updated: 2023-06-06 00:32 (UTC)

Pinned Comments

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 9 Next › Last »

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> - http://git.io/ctPKG
# Co-Maintainer: Sam Burgos < santiago dot burgos1089 at gmail dot com >
# Contributor: Jan Böhringer <janboe@gmail.com>
# Contributor: Frédérik Paradis <fredy_14@live.fr>
# Contributor: GI_Jack <GI_Jack@hushmail.com>

pkgbase=gtkhash
pkgname=(
  gtkhash
)
pkgver=1.4
pkgrel=2
pkgdesc="A GTK+ utility for computing message digests or checksums"
arch=('i686' 'x86_64' 'mips64el')
url="https://github.com/tristanheaven/gtkhash"
license=('GPL')

makedepends=(
    'dconf'
    'gtk3'
    'intltool' 
    'librsvg' 
    'nettle'
    'xdg-utils'
)

source=("${url}/releases/download/v$pkgver/$pkgname-$pkgver.tar.xz")
sha256sums=('20b57dbb8f6c6d7323f573c111a11640603a422c5f9da7b302a4981e4adc37c4')

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 \

  make

  #./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!
  #make
}

package_gtkhash() {
  depends=(
    'dconf'
    'gtk3' 
    'nettle'
  )

  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

Santi-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