November 2018 - Aur-general - lists.archlinux.org

[aur-general] ttf-google-webfonts{,-distilled,-git,-hg} mess
by Jason St. John 19 Jun '19

19 Jun '19

I am the current maintainer of the AUR package ttf-google-webfonts-hg[4], and I'm bothered by the mess of various packages there are for Google's Web Fonts project. It's not at all KISS in its current state. There are currently four different AUR packages[1][2][3][4] that essentially supply the same files, and all four packages conflict with each other. Around August of 2012, the package named ttf-google-webfonts[1] was orphaned, and user w0ng created a GitHub repository[5] that mirrors the Mercurial repository[6] on Google Code (why?). Then, the new maintainer changed the original ttf-google-webfonts package from a VCS-type package that simply lacked "-hg" in the name to a package that pulls tarballs from w0ng's GitHub repo[5]. As you can see in the comments for ttf-google-webfonts[1], this has caused all sorts of confusion and messages about the package being out-of-date or having invalid checksums. To get around these issues, user epinephrine created the package ttf-google-webfonts-git[3] that clones w0ng's GitHub repo[5] instead of pulling tarballs from it, which significantly reduces the maintenance required on the package. Then, user Gently created a package named ttf-google-webfonts-distilled[2] that pulls a tarball from w0ng's GitHub repo[5] and only installs a small subset of the fonts therein. Shortly after ttf-google-webfonts[1] was changed from being a Mercurial-based package and not liking the direction that the package was taking, I reuploaded the original ttf-google-webfonts package as ttf-google-webfonts-hg[4] for people that simply wanted the old package back that uses the actual Google Web Fonts repository to download the files. To clean up this mess, I propose that ttf-google-webfonts-distilled[2] and ttf-google-webfonts-git[3] be deleted outright, for what should be obvious reasons. I also propose that ttf-google-webfonts[1] be deleted because of how frequently the Web Fonts project is updated and because the project lacks version numbers. If people really feel strongly about keeping that maintenance nightmare, then let them have it, but I really don't see what advantage it provides over the original ttf-google-webfonts-hg[4] other than one less makedepends. I apologize for the huge email, but this situation really is a mess. [1] https://aur.archlinux.org/packages/ttf-google-webfonts/ [2] https://aur.archlinux.org/packages/ttf-google-webfonts-distilled/ [3] https://aur.archlinux.org/packages/ttf-google-webfonts-git/ [4] https://aur.archlinux.org/packages/ttf-google-webfonts-hg/ [5] https://github.com/w0ng/googlefontdirectory [6] https://code.google.com/p/googlefontdirectory/ Jason

14 23

[aur-general] TU Application: Daniel M. Capella
by Daniel M. Capella 03 Jan '19

03 Jan '19

Hello, My name is Daniel M. Capella (aka polyzen), and I am applying to be a Trusted User with Ivy Foster's sponsorship. My current main interest lies in Rustlang-based blockchain/distributed app/cryptocurrency implementations; half for the tech, half so I can escape the world of indentured slavery, fearlessly. My dream for the future is to write software that will help increase the pace it takes science to build the world of tomorrow -- whatever that means. I watch too much sci fi. I hope you like lists as much as I apparently do. ---- Stats: - Arch vanilla user since 2013. ALARM user for my home servers since perhaps a year or two before then. For completion's sake, even before that I had used Ubuntu and Archbang. This year I will be getting the LPIC-2[1] certificate (may or may not be related to my LPIC-1 expiring this year ^^). - Held a workshop called "Git for Gits"[2] with meskarune under the Arch Linux Classroom. The class is (very) slowly being revamped for further sessions. - Coordinated AUR Cleanup Day 2017[3]. The original plan was for this to occur every other year, but the previous one was in 2010. I hope to continue the tradition of this occurring biennially. - Co-maintainer of pacman-contrib. Funny story: when I requested Git access, Florian gave it to me thinking I was Kyrias. ^^ I had a habit of nick (IRC) hopping back then. - Arch Linux Tester when I remember that's a thing I signed up for. - Relatively active with IRC and bug tracker support. - Very active with upstreams WRT packaging and then some. ---- Here follows the packages I'd like to move to and/or co-maintain in Community: - Packages I already maintain: - Automatic exception: - espeak-ng (accessibility) See also <https://bugs.archlinux.org/task/60618>. - Popular: - firefox-ublock-origin - firefox-umatrix - pulseaudio-dlna - python-black Maxim already plans to add this to the repos, but I would like to (co-)maintain this, being the original submitter (before it was merged into python-black due to the naming convention). - razercfg/razerd - 1% usage on pkgstats: - firefox-bookmarkdupes - firefox-multiple-tab-handler - firefox-referer-control - firefox-stylus - firefox-tab-flip-for-tree-style-tab - Firefox-tree-style-tab - termdown - tty-solitaire See <https://github.com/mpereira/tty-solitaire/issues/29>. - There was consensus from a few TU's in #archlinux-aur on considering the popularity of release variants: - Popular: - shaderc (-git) See also <https://bugs.archlinux.org/task/58582>. - 1% usage on pkgstats: - gmailieer (-git) - termtosvg (-git) - Other users' AUR packages: - Popular: - alot - hsetroot - python-proselint - ttf-symbola - yamllint - 1% usage on pkgstats: - python-vint - skim - Repo packages: - Orphans in Extra that I have installed: - ttf-indic-otf - vulkan-icd-loader - Packages I submitted to the AUR that were adopted or were added to the repos without checking the AUR first :p: - asp - fd - newsboat ---- Notes from Ivy that may come up in reviews: - “These Node.js and mkchromecast packages give me nightmares.”: ..Okay, actually that was my response when he brought them up. mkchromecast has a setup.py for its next release. npm packages have no hope. I've had to change chown invocations far too many times. Please don't hate me. - “This isn't a technical critique; more of an aesthetic one that you probably shouldn't listen to. It would be slightly amusing to add firefox as an optdepends to firefox-* (-:”: firefox was removed as a dep for these to make it easier for people to use them with Palemoon and such. - Go package LDFLAGS: Will take care of this. - “hangups: "sed -i 's/==/>=/g' setup.py" -- why? Also, has that change been submitted upstream? It's minor, but if it fixes something it's probably worthwhile”: Has to be done for pinned outdated dependencies. - “razercfg: have you submitted that tmpfile.conf upstream? Also, re: the install file, I'm pretty sure that ldconfig happens automagically, and systemd-udev-reload.hook should handle reloading udev rules”: Will take care of this. - “shaderc: there were a lot of patches in prepare(), which I can say from experience probably won't go over super well. I'm guessing these probably are waiting on acceptance or something?”: See <https://github.com/google/shaderc/issues/392#issuecomment-427442293> and <https://github.com/google/shaderc/issues/424>. - “no need for install -m755; -m755 is the default”: Taking care of this. ---- Some notes of my own that could be added to the guidelines: - My Rust packages use published crates if available, eg.: `source=("diskus-$pkgver.tar.gz::https://crates.io/api/v1/crates/diskus/$pkgver/download")` `--locked` will be used for those in due time: <https://github.com/rust-lang/cargo/issues/5654> - Similarly I source published npm packages, eg.: `source=("https://registry.npmjs.org/$pkgname/-/$pkgname-$pkgver.tgz")` - The following can be used for GitHub releases (where $url is eg. <https://github.com/LegNeato/asciinema-rs>): - Before: `source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")` - After: `source=("$url/archive/v$pkgver/$pkgname-v$pkgver.tar.gz")` ---- Future activities in mind: - Automated release notifications, perhaps once we're closer to automated builds. Maybe with <https://release-monitoring.org/>. - AL onboarding site, unless a wiki article is sufficient. Could be nice to make <https://www.rustaceans.org/findwork> work with Bugzilla. ---- Thank you all for your consideration. Best, Daniel M. Capella / dmc / polyzen [1]: https://www.lpi.org/our-certifications/summary-of-certifications [2]: https://archwomen.org/media/project_classroom/classlogs/2016-07-16-git_for_… [3]: https://lists.archlinux.org/pipermail/aur-general/2017-September/033557.html

9 16

[aur-general] TU application: Daurnimator
by Daurnimator 23 Dec '18

23 Dec '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, I'm applying to be a Trusted User; Foxboron has kindly sponsored me and has been mentoring me on the specifics over the last couple of months. I've been using Arch since 2010, having been present in #archlinux almost the whole time! Before that I was a Xubuntu user from approximately 2005. Before that I had flirted with Linux a few times, I think my first exploration of Linux was of Lindows back in 2001. With my programming hat on, I mainly use C and Lua, I'm quite heavily involved in the Lua community. I would like to become a trusted user with the primary goal of improving Arch's Lua packages. With my sysadmin hat on, I'm an admin at hashbang.sh, an online hackerspace/incubator. Amoung other services, we run public shell servers with a fully open configuration. At $DAYJOB roles I've been responsible for packaging and deployment on various Linuxes. With my networking hat on, I maintain a few nodes in Melbourne Wireless, a city-wide wireless network. This has taught me quite a lot about networking hardware and given me the chance to play with routing protocols. I also joined dn42 which is for lack of a better explanation "an internet of VPN tunnels". If accepted as a TU, I'd like to (co)maintain: - lua-expat - lua-filesystem - luajit - luarocks Other packages I'd be happy to co-maintain are: - awesome - jq - keepassxc - love - lua51-bitop - pcsclite - prosody - rlwrap - tig Regards, Daurnimator -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEHiYzy/cw8s5ux6twRbQpqPnZ0ioFAlv+qPYACgkQRbQpqPnZ 0ireMBAAg61vyyRBh0vbib22kCvfucbqFjzYV/E1gkgDpFo27tgZmBLvysA4AfhU wJQoyCDYJsGMzDC9sLmydmv9GG/QDtySYNia5HHglA8SE/EaNotS8lp1YEjRK0Pu GYpwksjQXRxexDvESsAdNatEh97/6SLbjy3zwGD+EJ7lMQ4LAWgFqW+w1a+u8o1l wnIt4CnSRk2gOuPVI3M3Ueub7/0afZvGp78GERtQ2DwRkUGxxmP7YQ1DtG/NPHzv KJMiCCHr2s+2ZTH4ajEzXOMg3zo6gZkG1/S7Y8MHo+l5lc3WOryBzfFOhQCbLCZb tl1d0bsue9+XIgR9taCog1pW+gYnpahBubl0XZQHg3v9YhepD78rAyhhx6VdfaxH ab6LY1tG16Jeh6QsxVX41+NHVFkEWIGnTVLnHvw4WV1l+I69jr6SB27PjTrwaPM9 d84ZDOUsTurSdTSL1VdCJCJopUQzD1YeHeNURyDfUtcf9FWR0EtPMvIj8+5X8hD+ homfISWdeZeBZ5pbwOgela4hKTdHuMTaJwkEP3DuqdqLKEWqM42WetBArfwEZsUV 4PfdyFjekAKcVJbPxmMSgw3NsPpUtYAEDLYo7U/WVOGtM6lxzL1yo2XTlPoEVqw7 3jDS/BcRpoBP8rvO2umEIz6b9/+EEVc0mtYEql3jxtfahEoA3pM= =bIKy -----END PGP SIGNATURE-----

9 19

[aur-general] A Positive Tale about an out-of-date Package
by Luca Corbatto 04 Dec '18

04 Dec '18

Hi everyone, I hope you don't mind, but after all these "discussions" lately I thought I'd step out of the undergrowth, brush myself off and just tell a little tale of how dealing with out-of-date packages can go in this community. So grab a cup of your favorite beverage and have a relaxed read. A little while back I came across the software synergy. Arch Linux being Arch Linux, of course, has a package for it! Hurray I thought, no need to package it myself. So I went and installed it. Sadly I realized it is quite out of date. At this point I can't remember if it was me who flagged it or if it was already flagged. Regardless, I thought "Maybe the maintainer is already on it, let's give them some time." After, I believe, about two weeks I thought, well let's take a look at the maintainers account aaand wow! According to the package search they are listed as maintainer on 591 packages! No wonder if a package or two fall through the cracks. So I looked in the PKGBUILD and found the email address of the maintainer. I quickly emailed them along the lines of "Hey, I noticed the synergy package has been out of date for a while. I also see you have tons of packages to maintain. Want some help with synergy?". Quite quickly I got a reply (paraphrasing) "Oh sorry about that, I had forgotten about that package. Some help would be amazing, here's a link to a github repository where I keep my packages. Feel free to open a pull request.". To github! Synergy was stubborn as they have lot's of bundled dependencies that all want to be unraveled. It was a journey in which I deepened my knowledge about CMake, learned to curse project maintainers that don't think about us packaging-people and eventually even learned a few more details about packaging for Arch Linux. After some time the pull request was ready. The package maintainer had to add a little spit and polish, after which it was merged and released into the wild. No further flagging or requesting necessary. So to all newbies out there that may have gotten scared by what was going on in the mailing lists lately: Don't be afraid! As far as I have perceived it so far, this is a welcoming and supportive community with great people working on a great (if not the best) Linux distribution. Thank you Anthraxxx for the lovely interactions we had in the course of working on the synergy package! Hope this can shed some positivity. Best regards, Luca (targodan)

2 1

[aur-general] On TU application, TU participation and community/ package quality
by Santiago Torres-Arias 29 Nov '18

29 Nov '18

On TU applications, TU participation and package quality: ========= Many Trusted Users have brought up their concerns regarding the lack of proper vetting of packages put forward by new TU's, the small participation of TUs in their duties* and the declining quality of packages in the community/ repository. As a consequence, we've decided to bring forward proposals to tackle the following issues: ## Issues * Existing Trusted Users are not followed closely in their actions, and the quality of some packages for instance is more than questionable. * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. * There is a general feeling of decreasing/not high enough quality in the packages provided in the community/ repository. * The implication of some TUs in the distribution is very limited outside of packaging. ### current proposals (simplified) The discussion #archlinux-tu channel has yielded three general possibilities: 1. Add a council of TU's to introduce oversight on the whole voting process 2. Increase the minimum number of sponsors per application 3. Create a working group of TU's to review recent applications and warn TU's that do *not* appear to be performing their duties appropriately Consider that these need not be the only possibilities and any further proposals should be also brought up. ## Proposals ### TU council Creating a council of TUs who, by means of experience and involvement, make sure the approval of new TU's is properly reviewed. As such, this council will be in charge of voting in and/or sponsoring a new TU applicant. This raises questions about the horizontal power structure of the TU community. The consequences of bringing a hierarchy like this need to be discussed, as more than one TU is concerned of the implications of this model. The means for election for such a council are yet to be discussed, as the feasibility of this measure is to be discussed first. ### Minimum number of sponsors An alternative to a TU council is to increase the minimum number of sponsors for a TU application. This has been the case in other communities that experienced rapid growth (e.g., CNCF) and may help increase oversight and preparation of newer applicants. Variants of this model can be considered too. For example, a buddy system in which new applicants need both an experienced TU and a new TU as sponsors may also help preparing new TU's with the process of preparing applicants. However, one question raised during the discussion is whether this model is enough to warrant the goals outlined above. Namely, this measure doesn't seem to tackle the lack of participation of the broader TU community when reviewing new TU applications. ### Oversight committee Finally, a third proposal (and the one I'm championing) is to generate an elected organism within the TU community to overlook the performance of Trusted Users on the duties they agreed to fulfill. This oversight committee would track the activities of individual TUs and ensure that they are in fact participating in reviews, submitting proper high-quality PKGBUILDS, and moving packages to and from the AUR when the package's popularity changes. The methods by which this committee would enforce better TU participation are still to be discussed, but issuing warnings and probably bring cases to the broader TU community regarding an underperforming TU may be sufficient and nondisruptive. ## Conclusions The proposals above serve as a first step to discuss and iteratve over ideas on how to improve TU participation, applications and package quality. With this in mind, discussion of the applicability of these (or any other proposal) alone or on tandem should follow suit. Thanks! -Santiago P.S.: sorry for the legalose tone. I've probably spent too much time this week going through governance documents for different communitites. P.S.: Some of the ideas put forward is my interpretation of the text after going through the irc logs. Please correct me if my interpretation is wrong or incomplete. * e.g., reviewing PKGBUILDs or going through AUR requests

15 19

[aur-general] Change pkgbase of AUR package
by Michael Straube 27 Nov '18

27 Nov '18

Hi All, I want to remove the python3 package from the python-visitor split package [1], since it's already in [community]. Will simply changing the pkgbase/pkgname and pushing be enough? change: pkgbase=python-visitor pkgname=('python2-visitor' 'python-visitor') to: pkgname=python2-visitor Or do I need to upload a new python2-visitor package and file merge/delete request for the actual python-visitor split package? [1] https://aur.archlinux.org/pkgbase/python-visitor Best regards, Michael

2 2

[aur-general] Orphan request: concourse-fly-bin
by Julien Nicoulaud 26 Nov '18

26 Nov '18

Hi, Is it possible to orphan the concourse-fly-bin package ( https://aur.archlinux.org/packages/concourse-fly-bin) or at least add me as co- maintainer (https://aur.archlinux.org/account/nicoulaj) ? The maintainer did not update it despite my repeated demands (2018-11-07, 2018-11-16, 2018-11-19). Cheers, Julien

3 3

[aur-general] Spam Account
by Morgan Adamiec 23 Nov '18

23 Nov '18

Another spam account: https://aur.archlinux.org/account/markwilliamson/

2 1

[aur-general] TU application: Maxim Baz
by Maxim Baz 21 Nov '18

21 Nov '18

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.h… 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/

9 23

[aur-general] TU Membership Application
by Brett Cornwall 17 Nov '18

17 Nov '18

I am being sponsored by dvzrv. I've been working in the AUR since 2014 as 'Ainola'. I've had a few of my packages adopted into [community], such as gnome-mpv, csound, and qutecsound (the latter two being adopted by dvzrv). I am also an active contributor to the LibreOffice infrastructure team. I would like to get valuable tools promoted into [community], such as residualvm or the 'pass' plasmoid (after prodding upstream to have a formal release). Other packages that I do not maintain in the AUR would be ripe for picking as well, such as sc-controller or ttf-lato. I would also work with dvzrv on maintaining pro-audio packages, many of which were abandoned when SpepS left.

8 25