Discussion:
[aur-general] TU application: Maxim Baz
Maxim Baz via aur-general
2018-10-29 12:16:46 UTC
Permalink
Hello everyone,

My name is Maxim Baz, and with Morten Linderud (Foxboron) as my sponsor
(who I was referred to by Alad Wenter) I'm applying to become a Trusted User.

According to the git history of my dotfiles, I've been using Linux
for around 3 years and Arch Linux for around 2 years. I'm quite active
open-source contributor, especially on Github as you can see on my profile
page [1]. Some of my currently favorite projects where I both contribute
code and participate in discussions are: browserpass, wire-desktop, kitty,
kakoune, spaceship-prompt, and undoubtedly aurutils. I also once submitted
a small patch [2] to pacman-contrib that got merged.

During the day I work at Microsoft, where I am also using Arch Linux and
building software that runs on Linux in production.

In my mind, packaging is one of the best ways to do good for Arch Linux
community. Luckily there are tools that make this easy: I use Alad's aurutils
and always build in chroot, fixing broken PKGBUILDs on the fly and sharing
my fixes with package maintainers on AUR; to manage my own AUR packages [3]
(except for the very few) I now use aurpublish tool by Eli Schwartz.

Maintaining 'chromium-vaapi' in particular showed me how important it is to
keep a valid up-to-date PKGBUILD for a tool that many people rely on every
day, as well as how useful it is to provide precompiled binaries for apps
that require lots of time and/or resources to compile — this is how my
package 'chromium-vaapi-bin' was born.

One aspect of packaging that always interested me is security and
trust. Firstly, I have recently stumbled upon the idea of "reproducible builds"
and I love it, Eli Schwartz and Morten Linderud briefly introduced me to
the current efforts and I'm planning to get more involved in this area. In
particular, I'm interested in the user-facing side of things, figuring out
how to integrate this with pacman and how to let regular users benefit from
reproducible builds the most. Also, as a TU I want to help finishing TODO
"BUILDINFO rebuild" [4] if it's not completed earlier. Secondly, to maintain
people's trust in Trusted Users we should never use http to fetch sources
unless a verification method (such as a gpg signature) is also available,
that's why I also want to help burning down a corresponding TODO "Use gpg
signatures and https sources" [5].

Another thing I would do as TU is I would like to maintain and co-maintain
packages for some Language Servers (if the current maintainers don't
object). Language Server Protocol is a very cool concept (designed by
Microsoft :P), it defines a protocol used between programming languages
and editors to add features like autocomplete, go to definitions,
code formatting and much more. Language servers themselves are being developed
by community and are already supported by many editors like vim, neovim
and kakoune. I am planning to start with the following packages:

- bash-language-server: already in [community], I'd like to co-maintain it

- python-language-server and python-jsonrpc-server: already in [community],
I'd like to co-maintain them

- go-langserver: the most feature-rich language server at the moment,
to bring it to [community] I started the discussion with the upstream
maintainers about tagging releases

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

I would also like to move some AUR packages to [community], in particular
these ones have good amount of votes and in my mind deserve to be promoted to
[community]:

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

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

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

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

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

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

For all of the above, I'm being active on their Github pages and monitoring
new releases using urlwatch.

Finally I would like to co-maintain some of the packages that are already in
[community] if the current maintainers don't object, I use them myself and
participate in their development:

- kakoune
- kitty
- prettier
- py3status
- urlwatch

Sometimes I flag these packages as outdated, but I could just as well bump
the versions myself.


The above is the bare minimum, I reserve the right to discover more cool
projects to maintain and co-maintain :P


Cheers,
Maxim Baz


1: https://github.com/maximbaz
2: https://lists.archlinux.org/pipermail/pacman-contrib/2018-February/000079.html
3: https://github.com/maximbaz/pkgbuilds
4: https://www.archlinux.org/todo/buildinfo-rebuild/
5: https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
Morten Linderud via aur-general
2018-10-29 12:23:20 UTC
Permalink
Yo!
Post by Maxim Baz via aur-general
My name is Maxim Baz, and with Morten Linderud (Foxboron) as my sponsor
(who I was referred to by Alad Wenter) I'm applying to become a Trusted User.
I confirm my sponsorship of Maxim. Let the discussion period begin :)
--
Morten Linderud
PGP: 9C02FF419FECBE16
Jerome Leclanche
2018-10-29 15:16:36 UTC
Permalink
On Mon, Oct 29, 2018 at 2:17 PM Maxim Baz via aur-general
Post by Maxim Baz via aur-general
During the day I work at Microsoft, where I am also using Arch Linux and
building software that runs on Linux in production.
Boy, times have changed.
Post by Maxim Baz via aur-general
I would also like to move some AUR packages to [community], in particular
these ones have good amount of votes and in my mind deserve to be promoted to
All sound good to me.
Post by Maxim Baz via aur-general
Finally I would like to co-maintain some of the packages that are already in
[community] if the current maintainers don't object, I use them myself and
I'll be happy to have a comaintainer for prettier ;)

Good luck!

J. Leclanche
Alad Wenter via aur-general
2018-10-29 17:47:20 UTC
Permalink
For the record, I confirm that I support Maxim's application. I referred
him to Morten as my time schedule did not allow sponsoring a new candidate.

Best of luck!

Alad
Robin Broda via aur-general
2018-10-29 18:13:51 UTC
Permalink
Post by Maxim Baz via aur-general
Hello everyone,
My name is Maxim Baz, and with Morten Linderud (Foxboron) as my sponsor
(who I was referred to by Alad Wenter) I'm applying to become a Trusted User.
Great that you're applying!
Post by Maxim Baz via aur-general
...
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].
Post by Maxim Baz via aur-general
- 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 :(
Post by Maxim Baz via aur-general
- 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).
Nice!
Post by Maxim Baz via aur-general
- gocryptfs (18): Encrypted overlay filesystem, an alternative for encfs.
Just curious - how does this differ to ecryptfs?
Post by Maxim Baz via aur-general
For all of the above, I'm being active on their Github pages and monitoring
new releases using urlwatch.
Release monitoring is a big plus. nice!


Good luck :P
--
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Maxim Baz via aur-general
2018-10-29 19:00:25 UTC
Permalink
Thanks, to you and to everyone who has already reached out to me on IRC,
it is a pleasure to meet all of you!
Post by Robin Broda via aur-general
Post by Maxim Baz via aur-general
...
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].
I see, well I'm happy to hear this :)
Post by Robin Broda via aur-general
Post by Maxim Baz via aur-general
- 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.
Post by Robin Broda via aur-general
Post by Maxim Baz via aur-general
- 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 :)
Post by Robin Broda via aur-general
- 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
Jelle van der Waa
2018-11-05 20:11:47 UTC
Permalink
Post by Maxim Baz via aur-general
Hello everyone,
My name is Maxim Baz, and with Morten Linderud (Foxboron) as my sponsor
(who I was referred to by Alad Wenter) I'm applying to become a Trusted User.
During the day I work at Microsoft, where I am also using Arch Linux and
building software that runs on Linux in production.
Woot!
Post by Maxim Baz via aur-general
- 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)
- 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.
Post by Maxim Baz via aur-general
I would also like to move some AUR packages to [community], in particular
these ones have good amount of votes and in my mind deserve to be promoted to
- 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!!!
Post by Maxim Baz via aur-general
- 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?

I'm not a fan of supporting a non-supported component i.e. goole chrome.
I also wonder what's with the weird location /etc/opt/chrome?

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.
Post by Maxim Baz via aur-general
- 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. I'm also not
sure if we can package it, since I can't grasp the laywerspeak in
license-free.pdf
Post by Maxim Baz via aur-general
- 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.

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

Seeing you are active upstream, why doesn't it ship with a simple
Makefile? :)
Post by Maxim Baz via aur-general
- 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)
Post by Maxim Baz via aur-general
- gocryptfs (18): Encrypted overlay filesystem, an alternative for encfs.
Packages in the AUR

* rmtrash:

The .install script shouldn't really contain documentation. But usually
only creates users.

* rebuild-detector:

- Source should not be hosted on the AUR
- Missing MIT LICENSE, should be installed and provided upstream
- Did you know lddd exists?

* i3ipc-python

- Missing custom license, namcap warns about it.

* yubikey-touch-detector

- Missing custom license, namcap warns about it.
- Documentation on .install

* snap-pac-grub

- Source should not be hosted on the AUR
- Missing MIT LICENSE, should be installed and provided upstream


Probably missed a few things!
--
Jelle van der Waa
Maxim Baz via aur-general
2018-11-06 00:05:15 UTC
Permalink
Woohoo, reviews :) Thank you for your time Jelle!
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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!
Post by Jelle van der Waa
- 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.
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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?
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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`.
Post by Jelle van der Waa
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.
Post by Jelle van der Waa
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.
Post by Jelle van der Waa
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.
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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 ;)
Post by Jelle van der Waa
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.
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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...
Post by Jelle van der Waa
Systemd units should go into /usr/lib/systemd/system not /etc, that's
for user configuration!
Nice catch, fixed!
Post by Jelle van der Waa
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 :)
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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!
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- gocryptfs (18): Encrypted overlay filesystem, an alternative for encfs.
Did you mean to leave a comment on gocryptfs package?
Post by Jelle van der Waa
- 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! ;)
Post by Jelle van der Waa
- 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 ;)
Post by Jelle van der Waa
* i3ipc-python> * yubikey-touch-detector
* snap-pac-grub
- Missing license, namcap warns about it.
Thanks, fixed!
Post by Jelle van der Waa
Probably missed a few things!
I appreciate your review!


Cheers,
Maxim Baz


1: https://developer.chrome.com/apps/nativeMessaging#native-messaging-host-location
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
Levente Polyak via aur-general
2018-11-06 01:13:34 UTC
Permalink
Hi Maxim,
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
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 :/
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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).
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
- 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
Bruno Pagani via aur-general
2018-11-06 09:24:43 UTC
Permalink
Hi,

I didn’t read everything yet because I lack the time for this, but

Post by Levente Polyak via aur-general
Hi Maxim,
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
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
Levente Polyak via aur-general
2018-11-06 09:36:00 UTC
Permalink
Post by Jelle van der Waa
Post by Levente Polyak via aur-general
Hi Maxim,
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
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.
Post by Levente Polyak via aur-general
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
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
Post by Levente Polyak via aur-general
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*
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.

Cheers,
Levente
Bruno Pagani via aur-general
2018-11-06 13:16:34 UTC
Permalink
Post by Levente Polyak via aur-general
Post by Jelle van der Waa
Post by Levente Polyak via aur-general
Hi Maxim,
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
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.
Post by Levente Polyak via aur-general
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
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
Post by Levente Polyak via aur-general
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*
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=packages/matterbridge
or that
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/cozy-stack.

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.patch?h=packages/gitea
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
William Gathoye
2018-11-11 14:07:41 UTC
Permalink
Hello Bruno,
Post by Bruno Pagani via aur-general
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
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/
--
William Gathoye
<***@gathoye.be>
Bruno Pagani via aur-general
2018-11-11 14:10:11 UTC
Permalink
Hi William,
Post by William Gathoye
Hello Bruno,
Post by Bruno Pagani via aur-general
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
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
Eli Schwartz via aur-general
2018-11-06 01:22:57 UTC
Permalink
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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.
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
Post by Maxim Baz via aur-general
- 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`.
Post by Jelle van der Waa
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.
Post by Maxim Baz via aur-general
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
Post by Maxim Baz via aur-general
Post by Jelle van der Waa
- 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
Levente Polyak via aur-general
2018-11-06 01:33:34 UTC
Permalink
Post by Eli Schwartz via aur-general
Post by Maxim Baz via aur-general
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. :)
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
Eli Schwartz via aur-general
2018-11-06 01:35:31 UTC
Permalink
Post by Levente Polyak via aur-general
Post by Eli Schwartz via aur-general
Post by Maxim Baz via aur-general
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. :)
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
Ah, it seems we've become Debian too. When did that happen...
--
Eli Schwartz
Bug Wrangler and Trusted User
Maxim Baz via aur-general
2018-11-06 16:55:19 UTC
Permalink
Post by Levente Polyak via aur-general
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.
Post by Levente Polyak via aur-general
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.
Post by Levente Polyak via aur-general
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.
Post by Levente Polyak via aur-general
Post by Maxim Baz via aur-general
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 :)
Post by Levente Polyak via aur-general
Post by Maxim Baz via aur-general
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
Levente Polyak via aur-general
2018-11-06 18:29:40 UTC
Permalink
Hi Maxim,

some feedback to your packages that others did not yet bring up (so
pelase go through jelle's as well, i did not include them again):

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


browserpass:
- just a nitpick, but entry point is always $srcdir so if there is no
reason to do so, its just line-noise when calling 'cd' on each step.

chromium-vaapi:
- just the same tiny nitpick about cd-ing into $srcdir

chromium-vaapi-bin:
- this should also provide chromium-vaapi

grub-btrfs:
- conflicts on a git variant doesn't belong here. always the
other way around
- sources must be unique when f.e. stored in a global place,
always prefix artifacts like v$pkgver.tar.gz with
$pkgname-$pkgver.tar.gz::
- no need to distribute GPL3 license, they are common and therefore
nothing put storage waste.

i3ipc-python:
- don't provide yourself, doesn't do anything
- conflicts on a git variant doesn't belong here. always the
other way around
- same tiny nitpick about cd-ing into $srcdir
- upstream has tests, why not call whem via checkdepends and py.test?

kak-lsp:
- someone should push a non git go-langserver so this packages doesn't
need to recommend an optdepends on a git package
- same tiny nitpick about cd-ing into $srcdir

lscolors-git
- should pull over TLS via git+https://
- should have proper provides/conflicts
- still not a fan of those verbose docs in .install

rmtrash
- ok at least im sure this .install classifies as not mandatory
for a package to work, right? :P
- just the same tiny nitpick about cd-ing into $srcdir
- this is bash, it should have arch=(any)

wire-desktop
- conflicts on a -bin variant doesn't belong here. always the
other way around
- this source prefix is literally useless it should be unique
like $pkgname-$pkgver.tar.gz::
- same tiny nitpick about cd-ing into $srcdir
- patching should be done in prepare()
- ending pkgdesc with a dot is meh
- hunspell-en optdepends does not exist

wire-desktop-beta:
- conflicts is total bogus, should only have 'wire-desktop' as
does provides
- this source prefix is literally useless it should be unique
like $pkgname-$pkgver.tar.gz::
- same tiny nitpick about cd-ing into $srcdir
- patching should be done in prepare()
- ending pkgdesc with a dot is meh
- hunspell-en optdepends does not exist

wire-desktop-git:
- makedepends on git is missing
- should pull via git+https over TLS
- conflicts is bogus, should only have 'wire-desktop' as
does provides
- same tiny nitpick about cd-ing into $srcdir
- hunspell-en optdepends does not exist

yubikey-touch-detector:
- should be build via go-pie


cheers,
Levente
Maxim Baz via aur-general
2018-11-06 22:14:12 UTC
Permalink
Thanks Levente! A lot of little gems, will take care of these as well.
Post by Levente Polyak via aur-general
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
Post by Levente Polyak via aur-general
- 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.
Post by Levente Polyak via aur-general
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
Morten Linderud via aur-general
2018-11-13 11:15:37 UTC
Permalink
Yo!

The discussion period is over and the voting has begun!

Great review session everyone, and I hope we can see more things like that in
the future :)

https://aur.archlinux.org/tu/?id=113
--
Morten Linderud
PGP: 9C02FF419FECBE16
Morten Linderud via aur-general
2018-11-20 11:30:26 UTC
Permalink
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_for_new_Trusted_Users
--
Morten Linderud
PGP: 9C02FF419FECBE16
Eli Schwartz via aur-general
2018-11-20 14:18:04 UTC
Permalink
Post by Morten Linderud via aur-general
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...)
Post by Morten Linderud via aur-general
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_for_new_Trusted_Users
Congratulations, Maxim! I have upgraded your bugtracker account to
Trusted User status for the Community Packages project, and added you as
a Member to the internal Keyring project (and subscribed you to the
relevant bug).
--
Eli Schwartz
Bug Wrangler and Trusted User
Bruno Pagani via aur-general
2018-11-20 14:23:42 UTC
Permalink
Post by Eli Schwartz via aur-general
Post by Morten Linderud via aur-general
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.
Maxim Baz via aur-general
2018-11-20 20:30:05 UTC
Permalink
Post by Morten Linderud via aur-general
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_for_new_Trusted_Users
Thank you everyone!

Loading...