Arch Linux User Repository

@dreieck I have updated the package to not bundle ffmpeg anymore following this upstream issue. Vdhcoapp can only use the local ffmpeg because its path is hardcoded. The package uses symlinks for now and I am waiting for Vdhcoapp to properly support using the system's ffmpeg.

I also added the provides and conflicts variables.

Thanks for your suggestions

PKGBUILD has

+sha256sums=('89444b3672573a64cb748774164474226bbc25c342f1324720d5cf8f2b4e5fdc'

deb (https://github.com/aclap-dev/vdhcoapp/releases/download/v2.0.3/vdhcoapp-2.0.3-linux-x86_64.deb) has

$ sha256sum vdhcoapp-2.0.3-linux-x86_64.deb
bd288efbd562aa450b3b142b9ad1221b83a4ea510eb840ef3f5a3c499bbb6471  vdhcoapp-2.0.3-linux-x86_64.deb

Work-around until maintainer resolves this issue:

$ makepkg -g
==> Retrieving sources...
  -> Found vdhcoapp-2.0.3-linux-x86_64.deb
  -> Found vdhcoapp-install.hook
  -> Found vdhcoapp-remove.hook
  -> Found vdhcoapp-user-install.hook
  -> Found vdhcoapp-user-remove.hook
==> Generating checksums for source files...
sha256sums=('bd288efbd562aa450b3b142b9ad1221b83a4ea510eb840ef3f5a3c499bbb6471'
            'a2b56e6ae3f7f8933e20762baa90e69f63f0802b2e6d213b51e0bc68843e5d27'
            '3287859986d67e15e269965676bf9c75d1e853ea0ec97695811072fb8f10a7a8'
            'a74a57aac6b2e76ded9524599d3047486f9f2d8f820c5114ad41209c8117ab35'
            'fddf971ed2d6d976cd6ce34f9f04c9c2d18c03112eccda44ccf887cda0344b7c')

vdhcoapp-2.0.3-linux-x86_64.deb is failing sha256 check:

==> Validating source files with sha256sums...
    vdhcoapp-2.0.3-linux-x86_64.deb ... FAILED
    vdhcoapp-install.hook ... Passed
    vdhcoapp-remove.hook ... Passed
    vdhcoapp-user-install.hook ... Passed
    vdhcoapp-user-remove.hook ... Passed
==> ERROR: One or more files did not pass the validity check!

Thank you @trinitronx for looking into these issues, I have merged your commits!

@Paragoumba: Happy this helped to get things into a better working state. I just noticed and fixed one other small issue due to an oversight on my part for users who run pacman frontends such as pamac.

A few users of Manjaro reported that the post-install hook didn't seem to run for them when using pamac. It turns out that SUDO_USER is not set in this case because pamac uses PolicyKit via pkttyagent to authenticate & escalate privileges. Symptoms of this can be seen in /var/log/pacman.log and looks like:

[2023-10-12T13:06:11-0600] [ALPM-SCRIPTLET] sudo: unknown user /usr/bin/vdhcoapp
[2023-10-12T13:06:11-0600] [ALPM-SCRIPTLET] sudo: error initializing audit plugin sudoers_audit

Unfortunately in this case, there is no equivalent polkit environment variable for determining the user installing the package. (If anyone knows more, let me know if I'm missing some hidden method for finding this in a libalpm hook. env did not print any useful variables in the hook's runtime environment when I tested it.)

So, in this case, perhaps the sane default would be to fallback on uid 1000 given that most people using vdhcoapp-bin are going to be single-user desktop users rather than one of many multi-user seats.

I pushed a bugfix branch up here: trinitronx/vdhcoapp-bin#3 Feel free to review the changes

To pull & merge:

# If remote not already added
git remote add trinitronx https://gitlab.archlinux.org/trinitronx/vdhcoapp-bin.git

git fetch trinitronx fix-pamac-user-hook
git checkout -b fix-pamac-user-hook trinitronx/fix-pamac-user-hook
git checkout master
git merge fix-pamac-user-hook

@alexdandrea While I do agree with your opinion, — I also prefer not to have my personal user-files be affected in any way without consent. — I think the current state of package is better than before.

I suggest that instead of automatically calling the registration for the user who is running the install, instead a message to be displayed that informs about the necessary steps.

If a user needs the registration to happen for a different user, he/she has no knownledge about what to do because it was hidden. Also, I would prefer not to have my personal user-files be affected in any way without consent :-)

Thank you @trinitronx for looking into these issues, I have merged your commits!

Thank you @trinitronx.

Used your fix-user-install-hook and it works.

@Paragoumba: I also believe that I may have just found a fix for the user-level JSON files install issue. After running the post-install hook as $SUDO_USER, the Firefox plugin now can find the companion app binary!

Fixes pushed to fix-user-install-hook branch here. This includes fixes from packaging-fixes branch as well.

To pull & merge:

git remote add trinitronx https://gitlab.archlinux.org/trinitronx/vdhcoapp-bin.git
git fetch trinitronx fix-user-install-hook
git checkout -b fix-user-install-hook trinitronx/fix-user-install-hook
git checkout master
git merge fix-user-install-hook

The just-released PKGBUILD 2.0.1-1 has broken symlink:

lrwxrwxrwx 1 root root 67 Sep 28 17:37 /usr/bin/vdhcoapp -> /opt/net.downloadhelper.coapp/bin/net.downloadhelper.coapp-linux-64

It looks like it should now be pointing to: /opt/vdhcoapp/vdhcoapp

Additionally, the *.hook files are never installed to /usr/share/libalpm/hooks

So, they're never actually run on post-install & pre-remove. Although, it looks like to get the Firefox browser extension to find it, I still had to manually run: /usr/bin/vdhcoapp install ... as my local user account. After that, going into the extension & clicking "Recheck" found it. Not sure why the --system flag doesn't appear to work so the browser extension can find it properly. Maybe it's something to do with the browser profile pre-existing? Maybe the hook should also run sudo -u $SUDO_USER /usr/bin/vdhcoapp install --user or suggest that the user run: /usr/bin/vdhcoapp install --user manually?

I've fixed these issues and have it working in a bugfix branch over on my ArchLinux GitLab. You can review the changes here

Feel free to pull & merge from my branch:

git remote add trinitronx https://gitlab.archlinux.org/trinitronx/vdhcoapp-bin.git
git fetch trinitronx packaging-fixes
git checkout -b packaging-fixes trinitronx/packaging-fixes
git checkout master
git merge packaging-fixes

@dreieck I have updated the package to not bundle ffmpeg anymore following this upstream issue. Vdhcoapp can only use the local ffmpeg because its path is hardcoded. The package uses symlinks for now and I am waiting for Vdhcoapp to properly support using the system's ffmpeg.

I also added the provides and conflicts variables.

Thanks for your suggestions