On 11/5/18 7:05 PM, Maxim Baz via aur-general wrote:
- wire-desktop (76): End-to-end encrypted messaging app that works on Windows, Linux, Mac, Android and iPhone. It is free, open-source and available on Github. Although I'm co-maintaining this package on AUR, I was mostly focused on contributing to the project itself: I added proper emoji support (following the latest Unicode standard), emoji autocomplete and improved native notifications on Linux (show user pictures, set urgency hint).
- patching should happen in prepare() - electron packages should use our electron package and don't download it again. (I'm assuming it does btw) - ideally the desktop file should be from upstream or submitted upstream - i686 shouldn't be in the arch=() array for community packages - Just my personal opinion, but what the JavaScript!!!
Thank you for these, I expect making it use system electron will be the most difficult part. Am I right to assume that if for whatever reason it turns out to be impossible to decouple from the bundled electron version, I should keep this package in AUR?
Well, I for one am rather opposed to shipping vendored binaries, especially when it results in bugs like this: https://github.com/electron/electron/issues/13972 And just generally, vendored dependencies are gross. ... It shouldn't be a huge problem, though. See how e.g. atom caprine code cozy-desktop geogebra keybase-gui messengerfordesktop min riot-desktop do it. Also once again, note to self: write some wiki packaging guidelines for this.
- browserpass (31): Browser extension for pass (unix password manager), works in Chromium and Firefox. I became the primary project maintainer about a year ago, and together with another maintainer recently started rewriting it to make the architecture accommodate users' needs. I'm planning to bring this to [community] after the new version is ready (we are aiming to release in December). Also, someone in comments on AUR gave me a cool idea to use split-packages for Chromium and Firefox browsers, I'm going to do this as well (current PKGBUILD installs browserpass for both browsers, even if these browsers are not installed).
No idea, what to make of the Golang stuff, melts my brains. This however semes to not be reproducible? Or does upstream have a lock file for locking it's deps?
The upstream has a lock file, and moreover the sources archive that this package is downloading already contains all dependencies, so that PKGBUILD doesn't have to deal with them — all it has to do is to extract the archive and run `make`.
I'm not a fan of supporting a non-supported component i.e. goole chrome.
Will it be better in your opinion if this was a split package, providing app itself, and then packages for google chrome, chromium and firefox? This was suggested to me earlier, so that the package doesn't create files for browsers that are not even installed.
I guess I could even separate them into completely different PKGBUILDs, bring browserpass, browserpass-config-chromium and browserpass-config-firefox to community and leave browserpass-config-google-chrome in AUR. All these browserpass-config-* packages will provide "browserpass-config", and browserpass will depend on generic "browserpass-config", so that user is required to install at least one.
It is vital for browserpass that configs for all browsers (where user wants to use the app) are installed, it will not function at all without them.
It is a tiny json file, and I see no reason to create split packages for it. At worst, you'll just drop the native messaging host (and extension installation policy) for the google-chrome browser that isn't in the repos.
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...
It's pretty wrong to execute this, mostly because the systemd package installs a universal hook to do so and it's therefore outdated bloat to do so. This is, after all, why we developed hooks for pacman. :) It was originally added in March of this year: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd&id=c2ba1fefa6e393e5cb4d2c19ba65a4ec4c33fb9f
* 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's neither a new rule nor an old rule -- it's an unspoken rule. The AUR is for hosting build recipes, it's logically inconsistent to serve as the upstream source. Moreover, our servers have enough load without also checking into git a lot of source code we never intended to provide hosting services for. Not that we're in imminent danger of overload, but... why add bloat... *puts on aurweb hat* We actually have checks within the backend code to ensure a maximum allowable blob size for any file checked into git. This has been calculated in an effort to be friendly to things like linux kernel .config which can be moderately large (this is the precise example that made us bump the limit from 100KB to 250KB). A linux .config is a thing which is not source code, but package configuration, and thus makes sense to be uploaded directly. In theory it's supposed to be obvious, much like uploading your holiday pictures is obviously against the rules despite not being spelled out. But, we do seem to get people uploading trivial scripts, possibly because they don't feel like bothering with the creation of an additional GitHub repo. :/ -- Eli Schwartz Bug Wrangler and Trusted User