Package Details: apex-bin 0.16.0-5

Git Clone URL: (read-only, click to copy)
Package Base: apex-bin
Description: Build, deploy, and manage AWS Lambda functions with ease (with Go support!).
Upstream URL:
Keywords: apex aws lambda
Licenses: MIT
Provides: apex,
Submitter: ik_5
Maintainer: None
Last Packager: ik_5
Votes: 1
Popularity: 0.000000
First Submitted: 2017-02-01 14:42
Last Updated: 2017-11-16 21:21

Required by (0)

Sources (2)

Latest Comments

ik_5 commented on 2017-11-16 21:16

solved :)

ik_5 commented on 2017-11-16 18:39

sorry, i didn't have time this week to go over it.
I'm now experiencing few issues uploading the changes.
You can find them at:

Until I'll figure it out, what is wrong.
Please note, that the way you suggested, works only 90%.
There are few issues that I had with it:

A. Non unique name, made it to use both sources the same, causing the current error I have:

remote: error: The following errors occurred when parsing .SRCINFO in commit
remote: error: 750d6e57ec6c91b897bde319b7d9a744ce934d02:
remote: error: line 1: failed to parse line: "local name apex_linux_amd64"

and I can't fix it at the moment (looking for ways to fix it).

So my solution was something in the middle, between what you have suggested, and what that makepkg liked.

Thank you btw :)

viraptor commented on 2017-11-16 09:47

Just in case - I meant that the original issue I had is still not solved in 0.16.0-2. The commit I linked fixes the naming and solves it.

viraptor commented on 2017-11-11 23:54

Thanks for looking into this. I meant a fix like this:

It stops the file being downloaded with the same name between different versions.

ik_5 commented on 2017-11-10 13:32

viraptor I hope that I was able to fix it for you.
I'ved learned something new, thank you :)

viraptor commented on 2017-11-10 10:15

Ok, the problem happened again on the upgrade and I think I know what's the reason. See

> File names of downloaded sources should be globally unique, because the SRCDEST variable could be the same directory for all packages. This can be ensured by specifying an alternative source name with the syntax source=('filename::fileuri'), where the chosen filename should be related to the package name:

Since the apex binary has the same name for each version, an upgrade fails for me when I'm using something like pacaur for the build. (but works on clean checkout, or after killing the cache)

So something like this should help (the mv command also needs to change to match).


You can also skip the condition by setting both source_x86_64 and source_i686 (and shasums)

viraptor commented on 2017-07-16 09:33

Weird... removing the cache and running `pacaur -S apex-bin` again worked. I wonder if it could be due to the filename not changing.

ik_5 commented on 2017-07-15 14:47

downloaded the files again, and the checksum did not change.
% sha256sum apex*
14e6792335a96bf880b35388c15b30f61375e6e0e3d679d861649df80e824a55 apex_linux_386
14ec8deceef3854a6cb0e48b3eb18cd29fcadd9175633561e3f7a52d1bdd95df apex_linux_amd64

Can you please try to download it from here:

And see what are the checksum you are getting.

viraptor commented on 2017-07-15 06:35

There's an issue with the checksums: (in v0.15.0-1)

==> Validating source files with sha256sums...
apex_linux_amd64 ... FAILED