Hi Maxim, On 11/6/18 1:05 AM, Maxim Baz via aur-general wrote:
You might want to use go-pie btw, to actually have PIE support
browserpass W: ELF file ('usr/bin/browserpass') lacks FULL RELRO, check LDFLAGS. browserpass W: ELF file ('usr/bin/browserpass') lacks PIE.
Nice, will investigate this.
well replace go with go-pie is all you can do there, you can't (yet) fix RELRO for go :/
- ttf-emojione (33): Colorful emoji font from EmojiOne. I created a Docker image that is able to compile the font out of image assets, and configured a Travis job for EmojiOne team so that the font is automatically being compiled on every commit and attached to every Github release.
The .install scriptlet shouldn't contain documentation.
Just to confirm, this is not as much documentation as a description of a command that user needs to run to make this package work.
I guess I could create a wiki page for EmojiOne and put there the command to run, but how do I let people know that they must visit the wiki? People expect to install the font and see it working, but it won't happen until they install fontconfig file.
I've had positive experience with using .install files to inform people what else they need to do after installation, not a single person complained in comments on AUR about problems with font! :)
Also, just saw that wiki [4] encourages to echo important directions that are needed to make package work, I believe my .install files fall under this category ;)
This is certainly something that is totally debatable and after all we are not Debian that does everything imaginable automagically and f.e. reloads all kind of stuff. The general statement that .install is not meant for documentation is correct, if this falls under the category of being well suited for .install is interpretation and debatable. Personally i don't see basic fontconfig knowledge to fall under this category and IMO its documentation that could be stuffed as well in /usr/share/doc/${pkgname}. After all, our users are expected to be able to search the wiki, people over the whole net claim we have the best linux wiki out there after all :p
- grub-btrfs (15): Detects and includes btrfs snapshots in GRUB menu, allowing to easily boot in any existing snapshot. I personally use grub-btrfs in combination with snap-pac and snap-pac-grub for seamless integration with snapper and pacman.
The .install scriptlet shouldn't really contain documentation. Ideally that should be found on the wiki or in the man pages.
Same question here, but actually worth confirming with you: is it a bad practice to execute "systemctl daemon-reload" in post_install() function? I've seen people do that, but so far I was refraining from executing any commands in .install files.
Creating a wiki page that would only tell people to run "systemctl daemon-reload" after installation sounds wrong...
Yes, it is bad practice to use .install file to warn about "systemctl daemon-reload". You also don't need a wiki page for that, why should you? Systemctl warns you itself about this whenever you would do something that could require a daemon-relload. This is knowledge that is expected to be gained. We are not debian that does this automatically, and if so, it should rather be discussed on arch-dev-public to get a pacman hook support (which IMO we don't need much).
* rebuild-detector: * snap-pac-grub:
- Source should not be hosted on the AUR
I will move to Github since it simplifies collaboration, but I also want to confirm if this is a new rule? I don't see this being mentioned on wiki [2,3,4], unless I'm blind :/
If it is a rule, let's add it to the wiki! ;)
It indeed is a rule and obviously we need to make it very clear. AUR package tree is not meant to store the actual non-build-related sources, signatures, tarballs or similar artifacts. AUR is not a storage and actual sources belong elsewhere. cheers, Levente