Arch Linux User Repository

Fork changed to lighterowl/transgui

The original repo seems almost lost any maintainer (last tag from Oct 12, 2019)

If you don't wan't use the @lighterowl fork, please use revision 43d0835ef0514c4526d2e0e0e25213efe8f33ef1

k0ste, here's the PKGBUILD which uses the transgui-sdk package for compilation. That package contains the same FPC and Lazarus versions as those used by the Docker image. This way, users compiling transgui from AUR are going to end up with binaries containing the same functionality as the ones available from GitHub.

# Maintainer: Konstantin Shalygin <k0ste@k0ste.ru>
# Contributor: Konstantin Shalygin <k0ste@k0ste.ru>
# Contributor: Dobroslaw Kijowski <dobo90_at_gmail.com>
# Contributor: Paul N. Maxwell <msg.maxwel@gmail.com>

pkgbase='transgui'
pkgname=("${pkgbase}-qt")
pkgver='5.18.7.f'
pkgrel=2
pkgdesc='Transmission BitTorrent client'
arch=('x86_64')
_url="https://github.com/lighterowl"
url="${_url}/${pkgbase}"
license=("GPL")
makedepends=(git transgui-sdk=1.3)
source=("git+${url}.git#tag=v5.18.7.f"
        "${pkgbase}.desktop")
sha256sums=('SKIP'
            '6ee61ee4b01445ef67cc76abaee051c17043b57a743a977a2528a4c78a9a638b')

source /opt/transgui-sdk/source.me

prepare() {
  cd "$pkgbase"
  git submodule update --init
  git checkout -- buildinfo.pas

  # https://github.com/transmission-remote-gui/transgui/issues/1486
  sed -i -e 's|h <> INVALID_HANDLE_VALUE|h >= 0|' "main.pas"

  local -r build=$(git rev-list --abbrev-commit --max-count=1 HEAD)
  sed -i "s/@GIT_COMMIT@/$build/" buildinfo.pas
}

package_transgui-qt() {
  depends=('qt5pas')
  conflicts=('transgui-gtk2-git' 'transgui-qt4-git' 'transmission-remote-gui-qt4'
             'transmission-remote-gui-gtk2' 'transmission-remote-gui-bin' 'transgui-gtk')

  cd "${srcdir}/${pkgbase}"

  install -dm0755 "${pkgdir}/usr/share/${pkgbase}/lang"
  install -dm0755 "${pkgdir}/usr/share/doc/${pkgbase}"
  install -Dm0755 "units/${pkgbase}" -t "${pkgdir}/usr/bin"
  install -Dm0644 "lang/${pkgbase}".* "${pkgdir}/usr/share/${pkgbase}/lang"
  install -Dm0644 "README.md" -t "${pkgdir}/usr/share/doc/${pkgbase}"
  install -Dm0644 "LICENSE" -t "${pkgdir}/usr/share/doc/${pkgbase}"
  install -Dm0644 "${pkgbase}.png" -t "${pkgdir}/usr/share/pixmaps"
  install -Dm0644 "../${pkgbase}.desktop" -t "${pkgdir}/usr/share/applications"

  rm "${pkgdir}/usr/share/${pkgbase}/lang/${pkgbase}.template"
}

build() {
  cd "$pkgbase"

  lazbuild "${pkgbase}.lpi" \
  --build-mode=Release \
  --widgetset=qt5
}

check() {
  cd "${pkgbase}/test"

  lazbuild "transguitest.lpi"
  ./units/transguitest -a
}

As noted previously, this only describes transgui-qt as I don't test or support GTK in any way.

Also, neither Qt6 nor GTK are officially supported as widgetsets. Qt5 is the only one I build and run myself. Qt6 crashes on exit for some reason, GTK looks good and seems to work OK in general but I don't use it at all.

Thanks for switching this package to my fork, k0ste. I'm an Arch user myself but I've never used the AUR for transgui as I just copy the locally-compiled binary straight to /usr/bin.

The problem with this PKGBUILD right now is that it uses "base" lazarus and fpc packages. Transgui uses its own version of Lazarus (though compiles fine with the base version too, it just causes one functionality to be unavailable) and FPC. FPC is the more critical one as the current stable release, 3.2.2, contains two bugs related to JSON parsing. They manifest themselves only with characters outside the BMP in JSON strings. See https://github.com/transmission-remote-gui/transgui/issues/1378#issuecomment-1445511385 for more information.

Unfortunately, I see no easy way out of this as long as AUR/PKGBUILD is concerned. The GitHub workflows (for Windows and macOS) just compile the necessary FPC and Lazarus versions from scratch which is not perfect but thanks to caching it's not done literally every time a new build is started. Doing something similar in a PKGBUILD doesn't sound possible because FPC unfortunately depends on configuration files in the user's home directory (unless this can be overridden somehow), and also, where would such a cache be stored?

The workflow for Linux builds everything inside a Docker container that contains the whole toolchain (https://hub.docker.com/r/lighterowl/transgui-sdk), but I've never tried building inside a container within a PKGBUILD. Also, requiring Docker for building something from AUR sounds a bit overkill.

Perhaps a better idea would be to add transgui-sdk as a separate PKGBUILD, use the scripts already available in https://github.com/lighterowl/transgui-sdk for building the toolchain, and install it to /opt/transgui-sdk or somewhere similar so they don't conflict with fpc and lazarus. transgui-sdk can be then added as this package's makedepend instead of fpc and lazarus.

This, however, means that transgui-sdk will still use and/or mess up the configuration files in the user's home directory. :-(

@Nebulosa thanks! Your improvements included 👍

@a821 this issue should be resolved, try to build!

Fork changed to lighterowl/transgui

The original repo seems almost lost any maintainer (last tag from Oct 12, 2019)

If you don't wan't use the @lighterowl fork, please use revision 43d0835ef0514c4526d2e0e0e25213efe8f33ef1

Hi, it fails to build in a clean chroot (log: https://0x0.st/8JcY.log). See also this forum post (https://bbs.archlinux.org/viewtopic.php?id=305393)

I had cleaned up the PKGBUILD for myself. Hope that you find something useful.

Btw, it builds and works with gtk3 but it has a lot of artifacts in UI for now.

I don't mind the patch, but why downloading a random 11MB binary external patch when you can clone the upstream repo? You can use the repo in a non-VCS package.

Again - I don't mind if you do that. I don't do that (VCS? things)

I don't mind the patch, but why downloading a random 11MB binary external patch when you can clone the upstream repo? You can use the repo in a non-VCS package.

@abouvier some users turned to me, in personal messages, with a request to add a patch or switch to the fork [1]. I do not consider fork, the same good solution with a lively project, it is better for me if someone backport commits from fork to the upstream. This is a public project, if the upstream does not listen to the requests of users to make a release [2], we are still trying to improve user experience. If you personally do not need a patch, you can easily turn it off in the PKGBUILD. If you are ready to support the -git option for the package, I cannot stop you 👨‍🔧

[1] https://github.com/lighterowl/transgui

[2] https://github.com/transmission-remote-gui/transgui/issues/1428