Search Criteria
Package Details: gotify-cli 2.3.2-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/gotify-cli.git (read-only, click to copy) |
---|---|
Package Base: | gotify-cli |
Description: | A command line interface for pushing messages to gotify/server |
Upstream URL: | https://github.com/gotify/cli |
Keywords: | android notify push |
Licenses: | MIT |
Submitter: | nicoulaj |
Maintainer: | flipee |
Last Packager: | flipee |
Votes: | 4 |
Popularity: | 0.000201 |
First Submitted: | 2019-02-28 18:10 (UTC) |
Last Updated: | 2024-08-04 16:20 (UTC) |
Dependencies (3)
- glibc (glibc-gitAUR, glibc-linux4AUR, glibc-eacAUR, glibc-eac-binAUR, glibc-eac-rocoAUR)
- git (git-gitAUR, git-glAUR) (make)
- go (go-gitAUR, gcc-go-gitAUR, gcc-go-snapshotAUR, gcc-go) (make)
Latest Comments
plexman commented on 2023-01-13 22:56 (UTC)
I'm getting this error while building in clean chroot:
matthias.lisin commented on 2020-11-11 11:33 (UTC)
Sadly the error message is not always clear.
LDFLAGS
in particular is not a problem since makepkg will force it's own value (see/etc/makepkg.conf
, but I know what you mean and I agree that the user has to be aware of his own environment. I secretly hopeCGO_ENABLED
along with the otherCGO_*
flags will be enforced by makepkg in the future, although I read (or heard) it's very unlikely.flipee commented on 2020-11-11 01:30 (UTC)
It's a good point, but I think that in this scenario the user is responsible. I mean, if users export
CGO_ENABLED=0
globally, they should know what they are doing or at least for some reason this is intended.It's like changing
LDFLAGS
. There's no way to prevent such things (which is actually good).matthias.lisin commented on 2020-11-11 00:02 (UTC) (edited on 2020-11-11 00:03 (UTC) by matthias.lisin)
Sorry, should make this more clear: I mean that some Arch users have CGO_ENABLED=0 exported in their environments, not the upstream project.
If you see building in clean chroot as a requirement, then I agree that it's unnecessary. The env variable is still picked up when running
makepkg
directly. In this specific case it still builds, but with side-effects like partial relro (see namcap, checksec)This decision is up to you. I had some "works for me" moments in the past, so I started including it for Golang packages.
flipee commented on 2020-11-10 23:41 (UTC)
Hey @matthias.lisin, thanks for the feedback.
Well spotted! UTC enforced now.
There's no need to enforce
CGO_ENABLED
here since we are runninggo build
directly and not through aMakefile
or something.matthias.lisin commented on 2020-11-10 22:28 (UTC) (edited on 2020-11-10 22:33 (UTC) by matthias.lisin)
Hi flipee, thanks for adopting this package. PKGBUILD looks really good, I really appreciate. The only thing you missed is the
-u
flag fordate
.Edit: (this is debatable) I also like to force
CGO_ENABLED=1
, as some Go developers have CGO_ENABLED=0 exported in their environments and the build can break for them.