Package Details: handy 0.9.3-1

Git Clone URL: https://aur.archlinux.org/handy.git (read-only, click to copy)
Package Base: handy
Description: Open source and extensible speech-to-text application that works completely offline
Upstream URL: https://github.com/cjpais/Handy
Licenses: MIT
Conflicts: handy-bin
Submitter: barbuk
Maintainer: barbuk
Last Packager: barbuk
Votes: 1
Popularity: 0.87
First Submitted: 2026-01-20 10:00 (UTC)
Last Updated: 2026-07-15 19:16 (UTC)

Latest Comments

1 2 Next › Last »

barbuk commented on 2026-07-10 10:00 (UTC)

Hey @kml93 !

I did some testing with the build. All test were done by building inside a clean chroot.

With the openblas added dependency, /usr/lib/libtranscribe.so.0 correctly resolve libopenblas:

❯ ldd /usr/lib/libtranscribe.so.0 | grep -F blas
    libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f50fe3f8000)

❯ readelf -d /usr/lib/libtranscribe.so.0 | grep -F blas
 0x0000000000000001 (NEEDED)             Shared library: [libopenblas.so.0]

The app built with the openblas dependency is working without patching libtranscribe.

I reproduce the error you had by building handy without openblas, and installing openblas after.

Can you try to rebuild the 0.9.0-3 version ?

kml93 commented on 2026-07-08 23:36 (UTC) (edited on 2026-07-09 06:54 (UTC) by kml93)

Hi @barbuk,

handy 0.9.0 fails to launch even with openblas installed:

$ handy
/usr/bin/handy: symbol lookup error: /usr/lib/libtranscribe.so.0: undefined symbol: cblas_sgemm

libtranscribe.so.0 calls cblas_sgemm (from openblas) but has no NEEDED entry on it, and nothing else in the dependency graph pulls it in. pacman -S --asdeps openblas only helps users who didn't have it yet; for everyone else the runtime link is still missing.

Fix (package(), right after the symlink loop; add patchelf to makedepends):

makedepends=(
  appmenu-gtk-module
  bun
  cargo
  clang
  cmake
  git
  nodejs
+   patchelf
  pkgconf
  pwgen
  shaderc
  vulkan-headers
  spirv-headers
)

for lib in "${libs_to_symlink[@]}"; do
    if [ -f "$pkgdir/usr/lib/$lib" ]; then
      rm -f "$pkgdir/usr/lib/$lib"
    fi
    if [ -f "$pkgdir/usr/lib/$lib.0" ]; then
      rm -f "$pkgdir/usr/lib/$lib.0"
    fi

    versioned_lib=$(find "$pkgdir/usr/lib" -name "$lib.*")

    ln --symbolic --relative "$versioned_lib" "$pkgdir/usr/lib/$lib.0"
    ln --symbolic --relative "$pkgdir/usr/lib/$lib.0" "$pkgdir/usr/lib/$lib"
  done


+ transcribe_real=$(readlink -f "$pkgdir/usr/lib/libtranscribe.so.0")
+ patchelf --add-needed libopenblas.so.0 "$transcribe_real"

# License
install -Dm644 LICENSE -t "$pkgdir/usr/share/licenses/$pkgname/"

Tested on handy 0.9.0-3: app starts normally and readelf -d now shows NEEDED [libopenblas.so.0].

vlfig commented on 2026-07-05 12:00 (UTC)

Only issue for me was missing libopenblas. Fixed with ´pacman -S --asdeps openblas´.

barbuk commented on 2026-07-03 14:12 (UTC)

This is a tauri packaging issue, it should maybe be notified upstream.

It's fixed in the pkgrel 2 by removing the duplicated libs, and doing a symlink.

eli_liam commented on 2026-07-02 18:03 (UTC)

handy 0.9.0-1 appears to install several shared library SONAME files as regular files instead of symlinks, which makes ldconfig warn during unrelated pacman/paru transactions:

ldconfig: /usr/lib/libggml-base.so.0 is not a symbolic link
ldconfig: /usr/lib/libtranscribe.so.0 is not a symbolic link
ldconfig: /usr/lib/libggml.so.0 is not a symbolic link

These files are owned by handy:

/usr/lib/libggml-base.so.0
/usr/lib/libtranscribe.so.0
/usr/lib/libggml.so.0

On my system, the package installs these as regular duplicate files alongside the fully versioned files, e.g. libggml.so, libggml.so.0, and libggml.so.0.15.2 are all regular files with identical hashes.

Could the PKGBUILD preserve or recreate the expected symlink layout during package()? For example:

libggml.so -> libggml.so.0
libggml.so.0 -> libggml.so.0.15.2
libggml.so.0.15.2

Same issue appears to apply to libggml-base and libtranscribe.

kml93 commented on 2026-03-19 23:56 (UTC)

@barbuk Works perfectly, thanks!

barbuk commented on 2026-03-19 13:32 (UTC)

Hey @kml93,

Thanks for the suggestion. Please test the 0.7.12-2 release.

kml93 commented on 2026-03-19 12:28 (UTC) (edited on 2026-03-19 12:28 (UTC) by kml93)

Hi,

package() fails because the path to the deb data is hardcoded to src-tauri/target/, but Cargo respects CARGO_TARGET_DIR which can be set to a different location (e.g. XDG-compliant setups).

Fix (1 line):

-  cp -a src-tauri/target/release/bundle/deb/"${pkgname^}_${pkgver}"_*/data/* "${pkgdir}"
+  cp -a "${CARGO_TARGET_DIR:-src-tauri/target}/release/bundle/deb/${pkgname^}_${pkgver}"_*/data/* "${pkgdir}"

This respects CARGO_TARGET_DIR while keeping the default path as fallback, so it doesn't change behavior for users who don't set it.

Tested on handy 0.7.11.

mahula commented on 2026-03-06 15:21 (UTC)

Yes, it did build and install successfully.

barbuk commented on 2026-03-06 15:09 (UTC)

did it build successfully with an up to date toolchain ?

1 2 Next › Last »