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.000000 |
| First Submitted: | 2019-02-28 18:10 (UTC) |
| Last Updated: | 2024-08-04 16:20 (UTC) |
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.
LDFLAGSin 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_ENABLEDalong 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=0globally, 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
makepkgdirectly. 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_ENABLEDhere since we are runninggo builddirectly and not through aMakefileor 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
-uflag 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.