[aur-general] TU application: Maxim Baz
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.ht... 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/
Yo! On Mon, Oct 29, 2018 at 01:16:46PM +0100, Maxim Baz via aur-general wrote:
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
On Mon, Oct 29, 2018 at 2:17 PM Maxim Baz via aur-general <aur-general@archlinux.org> wrote:
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.
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]:
All sound good to me.
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:
I'll be happy to have a comaintainer for prettier ;) Good luck! J. Leclanche
On 10/29/18 1:16 PM, Maxim Baz via aur-general wrote:
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!
... 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*
- 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 :(
- 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!
- gocryptfs (18): Encrypted overlay filesystem, an alternative for encfs.
Just curious - how does this differ to ecryptfs?
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
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
On 10/29/18 at 01:16pm, Maxim Baz via aur-general wrote:
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! Just a few comments on your packages:
- 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.
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).
- 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!!!
- 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.
- 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
- 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? :)
- 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)
- 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
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 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
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
On November 6, 2018 10:24:43 AM GMT+01:00, Bruno Pagani <bruno.n.pagani@gmail.com> wrote:
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*
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
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 <bruno.n.pagani@gmail.com> wrote:
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*
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
Hello Bruno, On 6/11/18 10:24, Bruno Pagani via aur-general wrote:
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 <william@gathoye.be>
Hi William, Le 11/11/2018 à 15:07, William Gathoye a écrit :
Hello Bruno,
On 6/11/18 10:24, Bruno Pagani via aur-general wrote:
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.
Well, then I invite you to read my comments posted there on October 22th and November 2nd. ;) Regards, Bruno
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/syst...
* 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
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/syst...
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
On 11/5/18 8:33 PM, Levente Polyak via aur-general wrote:
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/syst...
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
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
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
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 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
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
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...)
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...
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
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.
On 11/20/18 12:30 PM, Morten Linderud via aur-general wrote:
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...
Thank you everyone!
participants (9)
-
Bruno Pagani
-
Eli Schwartz
-
Jelle van der Waa
-
Jerome Leclanche
-
Levente Polyak
-
Maxim Baz
-
Morten Linderud
-
Robin Broda
-
William Gathoye