...

...

source=("file:/pyre_${pkgver//./_}.sh"

This is not file:// because it is typoed.

But you should use local:// since file:// is an actual makepkg.conf protocol and will be downloaded using curl from an on-disk location.

I'll switch to using the local schema. Is there some resource, such as a man page, which explains it?

"file:/" is intentional, and not a typo. From Wikipedia:

file://path (i.e. two slashes, without a hostname) is never correct, but is often used.

See: https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes? If you like, you can report a bug to the aurweb parser arguing that you'd like to use your RFC 3986 right to an empty URI authority in combination with a permissive file: scheme. But currently, attempting to

On 1/4/19 1:32 PM, JereBear wrote: push that to the AUR will result in failure due to rejecting any source that does not contain the string literal :// and is also not committed to the git repository. Furthermore, makepkg itself does the same thing, and considers file:/path to be a relative filesystem path for "./file:/path", which, since makepg does not support subdirectories (whether that subdirectory name has a ":" in it in a manner reminiscent of RFC 3986 is not relevant) the leading directory will simply be dropped at every point where makepkg attempts to parse it. ... personally I don't see much use for skipping the ://, file:/// works everywhere and is more easily parsed. ... Since the only reason to use any scheme at all is to pass validation for aurweb, you won't notice anything wrong with makepkg. As for local://, it is special-cased in makepkg -- if makepkg sees it, it will not try to handle it as a download url no matter what. You can get a similar result by using sdfsgsgfdiuyicl:// since makepkg does most likely not have a DLAGENTS=() handler for this and will therefore tell you it cannot figure out how to download it... but it's the difference between "unknown download client" and "was not found in the build directory and is not a URL."

Shall I leave both of the variable assignments commented out, so that makepkg.conf is respected, and so that the user is aware of possible solutions? Or do you think it's better practice to omit such comments altogether?

I'm of the opinion people should read the documentation and set PKGEXT=.pkg.tar as described here: https://wiki.archlinux.org/index.php/Makepkg#Use_other_compression_algorithm... Or the next tip which shows how to modify COMPRESSXZ

I've not yet found a technique for configuring makepkg when building in a chroot with makechrootpkg. Here's the command I'm currently using:

makechrootpkg \ -c \ -I /var/cache/pacman/pkg/binkplayer-bin-2.7J-1-x86_64.pkg.tar.xz \ -r /var/lib/archbuild/extra-x86_64/

That's what prompted me to insert these variable assignments into PKGBUILD in the first place, rather than just advising the user to configure makepkg.conf. I'm happy to read a man page or wiki page if there's advice on this topic.

It's too bad that multi-threaded compression is incompatible with reproducible builds. :-(

makechrootpkg is designed to run makepkg in a highly controlled environment suitable for official packaging. It's undesirable for makepkg settings like PKGEXT to leak from a developer's machine into the environment used for uploading packages to the official repos. If you need something else, then don't use extra-x86_64-build, and instead mkarchroot with the makepkg.conf you want to initialize into the chroot. Or use arch-nspawn -M <file> to copy your makepkg.conf over the next time you do chroot administration.

...

...

prepare() { snip! }

This looks very complicated, shouldn't there be a way to tell it to extract to a temporary directory? I'm not overly familiar with makeself installers though.

Your intuition is correct: makeself can extract the blob that it prepends. This command will do so:

pyre-${pkgver//./_}.sh --keep --target data

But GOG games consist of a makeself script, mojosetup installer, and a zip archive containing the game assets, concatenated in that order. As a result, the command above extracts the *mojosetup* installer, not the game itself. Meanwhile, the mojosetup installer is an interactive GUI application that installs the game into the calling user's home directory. Not what I want. As a fall-back solution, I'm stripping the makeself script and mojosetup installer with tail. In the simplest case, it looks like the following:

tail --bytes=+757175 pyre-${pkver//./_}.sh > pyre.zip unzip -d pyre pyre.zip

However, I dislike hard-coding the number of bytes to strip, and I dislike calling unzip and hoping for the best, so most of prepare() is concerned with calculating the number of bytes to strip. I'm happy to explain the byte calculation logic in detail if you like.

I'd happily use pipes so as to avoid a large temporarily zip file:

tail --bytes=+757175 pyre-${pkver//./_}.sh | unzip -d pyre

...but unzip can't read from stdin.

That's quite sad, but if there's no way in makeself to extract the assets zip without using mojosetup, then I guess you're doing the best you can.

symlinking to start.sh is not an option here. :-( Here's the contents of gog-pyre:

#!/usr/bin/env bash

# Setting TERM prevents the application from crashing with "System.Exception: # Magic number is wrong: 542." See: https://github.com/mono/mono/issues/11557 TERM=xterm /opt/gog-pyre/start.sh

I suspect that this workaround is only necessary because Pyre bundles dependencies.

Oh well, it was worth a thought -- but next time you can post the script as well as the PKGBUILD and we'll know what it's doing right off the bat. ;)

Thank you for your time!

Any time! -- Eli Schwartz Bug Wrangler and Trusted User

On 1/4/19 10:45 PM, JereBear wrote:

Interesting. In the strictest case, the first phase of parsing the file scheme could consist of matching ^file:(\/\/([a-z0-9-]+)?)? and providing default values for missing capture groups. But this only makes sense if the file scheme is, well, to be supported. I'll think on this.

Also this would need to be supported in makepkg first, before adding it to aurweb. aurweb is written in python, but makepkg is written in bash.

Thanks for the info about the local pseudo-scheme. I've made a note to file a feature request on bugs.archlinux.org, asking for documentation. (Obligatory "and maybe a patch, but don't count on it.") And I'll switch to using it.

Documentation is always good! You're not the first one to ask about where local:// is documented, I think, but documentation issues are difficult to remember without a bug report when the people most likely to be writing documentation think it is obvious because they've read the implementation. :p

...

makechrootpkg is designed to run makepkg in a highly controlled environment suitable for official packaging. It's undesirable for makepkg settings like PKGEXT to leak from a developer's machine into the environment used for uploading packages to the official repos.

If you need something else, then don't use extra-x86_64-build, and instead mkarchroot with the makepkg.conf you want to initialize into the chroot. Or use arch-nspawn -M <file> to copy your makepkg.conf over the next time you do chroot administration.

Ah-ha! It's good to know the target use case for extra-x86_64-build and makechrootpkg. And I hadn't thought about using separate chroots for public vs private builds, or inserting files with arch-nspawn -M $file. Good stuff.

the different tools have lots of cool options. ;) makechrootpkg lets you use existing chroots configurably created with mkarchroot, extra-x86_64-build is just a convenience script designed for the official repos which: - handles mkarchroot automatically - updates the root/ chroot - hardcodes official defaults that are usually suitable for users too The aurutils AUR helper does contain its own `aur build` wrapper which uses mkarchroot and makechrootpkg directly, while also exposing makepkg.conf as an option. -- Eli Schwartz Bug Wrangler and Trusted User

On 1/6/19 2:00 PM, JereBear wrote:

...

...

Thanks for the info about the local pseudo-scheme. I've made a note to file a feature request on bugs.archlinux.org, asking for documentation. (Obligatory "and maybe a patch, but don't count on it.") And I'll switch to using it.

Documentation is always good! You're not the first one to ask about where local:// is documented, I think, but documentation issues are difficult to remember without a bug report when the people most likely to be writing documentation think it is obvious because they've read the implementation. :p

https://bugs.archlinux.org/task/61294

I noticed another bug when looking at your referenced package. You used local:/// rather than local://, but aurweb displays this as relative to the cgit repository. Since we use php's parse_url() to check if it validates as having an Array ( [scheme] => something ) - but, parse_url() will special-case file:// in order to treat it correctly, and otherwise - parse local://filename as a schema+host, and - parse local:///filename as malformed ("On seriously malformed URLs, parse_url() may return FALSE.") So this completely borks if scheme:/// is used and treats it as local to the cgit repository as the fallback for plain files, since it cannot get an $array['scheme'] from a boolean FALSE. It doesn't look like parse_url() is very suitable here... makepkg does not care either way, since it looks for the final pathname component by discarding everything before the last "/". This is an aurweb bug, as I think we should abort on malformed urls and display them as-is, like we already do for urls that are on the RHS of makepkg's "::" syntax. Or possibly use the same dumb parser we use in the db backend for consistency's sake... ... Also I think all previous cases of people using local:// in a PKGBUILD did not use "/filename", so we were happily parsing it as an authority. You've actually broken the aurweb in a practical way by actually caring about the RFC. :D -- Eli Schwartz Bug Wrangler and Trusted User

On 1/7/19 1:20 PM, JereBear wrote:

...

Also I think all previous cases of people using local:// in a PKGBUILD did not use "/filename", so we were happily parsing it as an authority. You've actually broken the aurweb in a practical way by actually caring about the RFC. :D

That's gratifying!

This bug appears to affect only the aurweb's UI, and not makepkg, so I think it's safe to leave the package as-is.

I'm going to re-read the relevant RFCs over the next few days to make sure I'm not barking up the wrong tree.

BTW I did submit https://lists.archlinux.org/pipermail/aur-dev/2019-January/004619.html which I think should fix this. -- Eli Schwartz Bug Wrangler and Trusted User