Thanks, to you and to everyone who has already reached out to me on IRC, it is a pleasure to meet all of you!

...

... Also, as a TU I want to help finishing TODO "BUILDINFO rebuild" [4] if it's not completed earlier.

Sadly, or thankfully - depending on how you look at it ;) - the BUILDINFO rebuild is pretty much outside of our control as TUs, as almost all remaining packages are outside of [community]. All except for cinnamon-desktop and cjs, that is. *nudge @eschwartz*

I see, well I'm happy to hear this :)

...

- 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).

Another Electron app? oof... That one would have to be devendored first, anyways - right now it is using a bundled Electron :(

I'm not particularly happy with it being an Electron app myself, but it's a great app nonetheless. The developers clearly said they hear the feedback, but they have no time to rewrite it. There have been community efforts to create a Qt client, but unfortunately nobody is actively looking into it :( Good catch about de-vendoring, I took a note, thank you.

...

- gocryptfs (18): Encrypted overlay filesystem, an alternative for encfs.

Just curious - how does this differ to ecryptfs?

I have to admin I'm not an expert, but this looks like an interesting comparison: https://nuetzlich.net/gocryptfs/comparison/ Personally I came across it when I was looking for a cross-platform solution that I could safely sync via cloud across multiple machines, and gocryptfs proved to be working very well :)

- 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.

Just as a final note, heftig on IRC pointed out that EmojiOne license will probably not allow us to distribute the font. I'm trying to get hold of anyone in EmojiOne team to confirm, but until further notice **ttf-emojione will remain on AUR**. Cheers, Maxim Baz

Woohoo, reviews :) Thank you for your time Jelle!

...

- kak-lsp: de-facto official plugin that adds LSP support for kakoune editor.

- You should pass --locked to, so that the Cargo.lock file is adhered. (reproducibility)

Nice one, added!

- The package has 3 votes, the TU guidelines define that a package with atleast 10 votes can be moved. Something to keep in mind, note that since it benefits kakoune it's fair to add it.

Right, I was aware of this guideline at the time of writing, I added it because kakoune's author himself names kak-lsp as the de-facto official package to use for LSP, he confirmed that kakoune itself will never implement this, but will always refer users to a plugin. Since kakoune is in [community], kak-lsp must be too.

...

- 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?

...

- 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.

I also wonder what's with the weird location /etc/opt/chrome?

This is the predefined path that all developers of native components must respect, it is documented in docs [1] (search for "Linux (system-wide)"). These paths are also predefined for all other existing browsers that implement this functionality.

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.

...

- 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 ;)

Also, I'm not sure if we can package it, since I can't grasp the laywerspeak in license-free.pdf

You are right, heftig on IRC has already pointed out this to me. I contacted EmojiOne to confirm, so far received no response. It stays in AUR until I manage to clarify this.

...

- 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...

Systemd units should go into /usr/lib/systemd/system not /etc, that's for user configuration!

Nice catch, fixed!

Seeing you are active upstream, why doesn't it ship with a simple Makefile? :)

Hehe, great question, will take care of this a bit later :)

...

- python-black (10): Python code formatter that quickly gains popularity, I see it being adopted more and more in the community of Python developers, so I want it to be available in [community] repo.

- yay for tests being run! - license is installed in the wrong directory:Missing custom license directory (usr/share/licenses/python-black)

Cannot take credit for adding test run as I'm not maintainer of this package, but I want to move it to community as I think it's worth it. Noted your comment!

...

- gocryptfs (18): Encrypted overlay filesystem, an alternative for encfs.

Did you mean to leave a comment on gocryptfs package?

* 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! ;)

- Did you know lddd exists?

Yes :) The goal of this tool is different, lddd tries to be 100% correct at a cost of running veeeeery slowly, while this package doesn't set the 100% correctness as a goal - instead it promises to be "good enough" and _fast_. It takes 10 seconds on my laptop to run, and so far it was always able to notify me about broken packages that need a rebuild. I run this tool every time I install new updates, so that I can instantly detect if an upgrade broke some AUR packages. I'm extremely happy with this little script :) By the way, giving a shout-out to Robin Broda who helped me writing this tool ;)

* i3ipc-python> * yubikey-touch-detector * snap-pac-grub

- Missing license, namcap warns about it.

Thanks, fixed!

Probably missed a few things!

I appreciate your review! Cheers, Maxim Baz 1: https://developer.chrome.com/apps/nativeMessaging#native-messaging-host-loca... 2: https://wiki.archlinux.org/index.php/Arch_User_Repository 3: https://wiki.archlinux.org/index.php/Creating_packages 4: https://wiki.archlinux.org/index.php/Arch_package_guidelines

Hi, I didn’t read everything yet because I lack the time for this, but… Le 06/11/2018 à 02:13, Levente Polyak via aur-general a écrit :

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 :/

is wrong. We have managed to do that in cozy-stack, gitea and matterbridge to only cite a few (also in mattermost, but the corresponding code is not committed anywhere since this is an AUR package not maintained by one of us). We should update Go guidelines to tell about this and also trimming the path (since the bug with it seems to have vanished somehow). *starts a Foxboron invocation ritual* Regards, Bruno

Le 06/11/2018 à 10:36, Levente Polyak via aur-general a écrit :

On November 6, 2018 10:24:43 AM GMT+01:00, Bruno Pagani wrote:

...

...

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 :/ is wrong. We have managed to do that in cozy-stack, gitea and matterbridge to only cite a few (also in mattermost, but the corresponding code is not committed anywhere since this is an AUR

Le 06/11/2018 à 02:13, Levente Polyak via aur-general a écrit : package not maintained by one of us).

We should update Go guidelines to tell about this and also trimming the path (since the bug with it seems to have vanished somehow). *starts a Foxboron invocation ritual*

That's awesome news, please indeed document the dark ritual needed to achieve this, there are lots of packages that can benefit from it.

This would be good to have ready before jelle finishes the TODO list for PIE and RELRO that's been worked on.

Basically, you have to pass `-ldflags "-extldflags ${LDFLAGS}"` to the go compiler. Theoretically, you should be able to do it using GOFLAGS (env var that is carried over), but my experience shows that if they are multiple instance of `-ldflags` on the line (e.g. those from GOFLAGS and those added by the project), only the latest is taken into account (Foxboron is currently looking at this to understand why this is happening). So in practice, we had two cases so far: 1. Your PKGBUILD calls `go` directly to compile the project, then what you want to do is something like this https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... or that https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa.... 2. You use some sort of upstream Makefile, then you will likely need to patch it if they use `-ldflags` in it (e.g. https://git.archlinux.org/svntogit/community.git/tree/trunk/gitea-ldflags.pa... or https://paste.xinu.at/Iatt/). If we manage to understand why settings those things in GOFLAGS does not work, we should be able to set the appropriate GOFLAGS in makepkg.conf. :) Regards, Bruno

Hi William, Le 11/11/2018 à 15:07, William Gathoye a écrit :

Hello Bruno,

...

is wrong. We have managed to do that in cozy-stack, gitea and matterbridge to only cite a few (also in mattermost, but the corresponding code is not committed anywhere since this is an AUR package not maintained by one of us). Thanks for mentioning Mattermost about this topic. As you know, I'm the

On 6/11/18 10:24, Bruno Pagani via aur-general wrote: maintainer of this package, I wanted to know whether I should apply modification about my package?

If that's the case, please discuss this further in the comment area of mattermost.[1]

Have a nice week-end.

[1] https://aur.archlinux.org/packages/mattermost/

Well, then I invite you to read my comments posted there on October 22th and November 2nd. ;) Regards, Bruno

On 11/6/18 2:22 AM, Eli Schwartz via aur-general wrote:

On 11/5/18 7:05 PM, Maxim Baz via aur-general wrote:

...

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

Ah, somehow wasn't really aware that we also do this for daemon-reload... well then, mv my previous paragraph about this to /dev/null :P cheers, Levente

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

I see your point and in general I agree, but in this specific case of ttf-emojione I was actually trying not to teach people how to create symlinks in conf.d folder, but rather to let them know that this config _exists_. This fontconfig file is not shipped by upstream (nor will it ever be - upstream only provides assets), instead this is something I made personally with the goal of making it part of the package. If this is not something you feel strongly about, I would much prefer to keep the .install file as it is — as a packager I want to make users of my package as happy as possible, and in my mind letting them know immediately after installation that the package won't work properly unless they also deal with provided fontconfig file is a good move — and if they want to learn more about fontconfig, I'm sure they will visit our awesome ArchWiki.

Levente said: why should you? Systemctl warns you itself about this whenever you would do something that could require a daemon-relload.

Eli said: 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.

You are both right, I didn't know about the universal hook, but even if it didn't exist systemctl will warn about this anyway, so makes sense removing the .install file.

It indeed is a rule and obviously we need to make it very clear. It's neither a new rule nor an old rule -- it's an unspoken rule.

Alright, let's please add this to the wiki, I'm sure I'm not the first person to break this rule :) I wanted to add it myself, but "Arch package guidelines" page is write-protected.

...

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?

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.

Awesome, the presence of this number of packages that have already went down this road inspires me :)

...

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.

I hear your feedback, let's postpone this discussion to the time when I'm ready with browserpass v3, I will not be updating PKGBUILD or moving it to community until then anyway. Finally, thanks for sharing the info about PIE and RELRO, this is interesting. Cheers, Maxim Baz

Thanks Levente! A lot of little gems, will take care of these as well.

But before we start, can't resist mumbling a small 'meh' for all this non build content hosted in the AUR. meh.

meh taken, meh addressed! Both tools live on Github now :P

kak-lsp: - someone should push a non git go-langserver so this packages doesn't need to recommend an optdepends on a git package

That someone is me, but the developers of go-langserver aren't good at making periodic releases. I'm trying to change this, but right now the time has not come for non-git package yet. Hopefully soon! However, I've just realized that -git package provides "go-langserver", so it should be okay for kak-lsp to depend on "go-langserver" directly.

rmtrash - ok at least im sure this .install classifies as not mandatory for a package to work, right? :P

You've got me here :) This .install file indeed has nothing to do about making the package work, thus removing. Cheers, Maxim Baz

Yo! The vote is over, and the results are inn! Yes: 33 No: 10 Abstain: 9 Participation: 100%(!!!) Congratulations! I have update your AUR account :) Pleaase follow the TODO and poke me for any questions you have going forward! https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f... -- Morten Linderud PGP: 9C02FF419FECBE16

Le 20/11/2018 à 15:18, Eli Schwartz via aur-general a écrit :

On 11/20/18 6:30 AM, Morten Linderud via aur-general wrote:

...

Yo! The vote is over, and the results are inn!

Yes: 33 No: 10 Abstain: 9 Participation: 100%(!!!) (That would be pretty neat. But I'm super confused, since aurweb says we had 53 TUs and now we have 54, but only 52 total votes. Sooooo close...) Seems like a bug indeed, City-busz is the one that did not vote apparently.