Package Details: flashplayer-standalone-debug 32.0.0.465-2

Git Clone URL: https://aur.archlinux.org/flashplayer-standalone-debug.git (read-only, click to copy)
Package Base: flashplayer-standalone-debug
Description: Standalone, debug version of Adobe Flash Player
Upstream URL: https://www.adobe.com/support/flashplayer/debug_downloads.html
Licenses: custom
Submitter: J4913
Maintainer: eientei95
Last Packager: eientei95
Votes: 17
Popularity: 0.77
First Submitted: 2012-06-07 23:02 (UTC)
Last Updated: 2021-10-19 01:58 (UTC)

Latest Comments

1 2 Next › Last »

eientei95 commented on 2021-10-19 02:07 (UTC)

Updated to match PKGBUILD from flashplayer-standalone

J4913 commented on 2021-06-06 11:56 (UTC)

Disowned - I no longer use this.

CyberShadow commented on 2018-07-25 03:11 (UTC)

I guess the problem manifests not with makechrootpkg, but aurutils which uses it, then. Thanks for fixing.

J4913 commented on 2018-07-24 19:32 (UTC)

I see, looks like this is a feature added after the package was created (though that's not really an excuse since it was added 3.5 years ago...). However, I tried it out and had no problem building in chroot:

mkdir ~/chroot
mkarchroot -C /etc/pacman.conf ~/chroot/root base-devel
makechrootpkg -r ~/chroot -- -sr

I suspect you missed either the -C option from mkarchroot or the -s option from makepkg (as passed through by makechrootpkg).

I'll switch to using depends_x86_64 regardless.

CyberShadow commented on 2018-07-20 05:06 (UTC) (edited on 2018-07-20 05:07 (UTC) by CyberShadow)

Hello again,

Currently, this package cannot be built in a chroot (e.g. using makechrootpkg). This is because of the line:

[ "$CARCH" = "x86_64" ] && depends=(lib32-gtk2 lib32-libxt lib32-nss lib32-curl)

It causes .SRCINFO to not be properly updated, so the dependencies aren't satisfied in the chroot.

I think the correct way to do this is using depends_x86_64. See man 5 PKGBUILD.

CyberShadow commented on 2017-04-20 20:40 (UTC)

Seems to work nicely, thanks!

J4913 commented on 2017-04-20 18:51 (UTC)

Sure, it's worth a try. The package now downloads the source archive to a filename which includes the package version. I don't use a caching AUR helper to test, so you'll find out if it works properly next time there's an update. (For what it's worth, this feels like a workaround for an issue that should be resolved in makepkg or the AUR helpers instead, instead of every affected package. For example, maybe they could just store the package checksums and compare those to new PKGBUILDs.)

CyberShadow commented on 2017-04-20 03:33 (UTC)

Hi J4913, do you think it would make sense to use the filename:: syntax in the PKGBUILD source, to avoid the problem with AUR helpers? Because the filename never changes, e.g. pacaur doesn't redownload the file, and simply fails at the hash check. If you place the pkgver in the download filename, this problem would be avoided. https://wiki.archlinux.org/index.php/PKGBUILD#source

J4913 commented on 2016-11-18 08:44 (UTC)

No problem. Consider filing a bug with your AUR helper (or whatever else provides your package cache). I suspect the issue might be caused by the fact that the download URL doesn't change between releases - Adobe just provides the new file on the same URL.

monodromy commented on 2016-11-18 07:31 (UTC)

I flagged it, and you are right---I get the right md5sum. I cleared my package cache and now it installs properly. Thanks!

1 2 Next › Last »