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

[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 7 days
by Levente Polyak 17 Aug '18

17 Aug '18

From: anthraxx <anthraxx(a)archlinux.org> Signed-off-by: Levente Polyak <anthraxx(a)archlinux.org> --- The discussion period for the addition of a new TU is too short. After having some chats on this topic with multiple TUs it seemed like a general consensus to extended the dicussion period to 14 days, hence this proposal. 5 days are rarely enough to discuss all details with the applicant taking into account that f.e. lots of packages need to be reviewed. Once feedback was given to the applicant there shall be enough time to work through it, potentially research, apply and/or discuss things out of the feedback. Given the fact that many people, including the applicant, may be in the middle of a work week (or otherwise busy), having only 5 days to do one or multiple feedback loops is unrealistic and too much pressure. Considering the fact that it is an essential part for a TU to be able to decide on the vote as well as for the applicant to have enough time and the possibility to respond properly to the input an adjusted discussion period of 14 days shall be appropriate. --- tu-bylaws.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 27e4804..d32e06c 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -104,10 +104,10 @@ In order to become a TU, one must first find a sponsoring TU, and arrange privately with them to announce their candidacy on the https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general] mailing list. Following the announcement, standard voting procedure commences with a -discussion period of 5 days, a quorum of 66%, and a voting period of 7 days. +discussion period of 14 days, a quorum of 66%, and a voting period of 7 days. ---- -SVP( addition_of_TU, 5, 0.66, 7 ); +SVP( addition_of_TU, 14, 0.66, 7 ); ---- If a candidate is rejected by SVP, they may not reapply to become a Trusted -- 2.18.0

1 0

[aur-general] intellij-idea-community-edition
by Simon Legner 14 Aug '18

14 Aug '18

Hi Arch! (I'm not sure whether I'm posting to the correct mailing list.) I'm a happy user of IntelliJ IDEA. Unfortunately, the community package intellij-idea-community-edition is out-of-date most of the time. As of writing, it has been updated at 2018-07-10 and flagged again on 2018-07-12. In the meanwhile, the versions 2018.1.6, 2018.2, 2018.2.1 have been released. Since I found updates to be smooth, updating the community package should be easy as well. Could any TU step in as (co)maintainer of this package to bring updates closer to the time? Thank you! Simon

4 4

[aur-general] Wrong ownership notification
by Florian Bruhin 10 Aug '18

10 Aug '18

Hi, I just got this mail (20180810075103.49C2E2BF27(a)luna.archlinux.org) about a package I'm maintaining: ----- Forwarded message from notify(a)aur.archlinux.org ----- Date: Fri, 10 Aug 2018 07:51:03 +0000 (UTC) From: notify(a)aur.archlinux.org To: archlinux.org(a)the-compiler.org Subject: AUR Ownership Notification for openhsr-connect-git The package openhsr-connect-git [1] was adopted by purboo [2]. [1] https://aur.archlinux.org/pkgbase/openhsr-connect-git/ [2] https://aur.archlinux.org/account/purboo/ ----- End forwarded message ----- However, the package never was orphaned, and at least in the AUR webinterface I'm still listed as a maintainer... huh? Florian -- https://www.qutebrowser.org | me(a)the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/

3 3

[aur-general] php-redis
by Bjoern Franke 10 Aug '18

10 Aug '18

Hi, what happened to php-redis? Only php70-redis, phpredis-git and a legacy version remain in the AUR, and I also do not see any deletion request in the request archives. Kind regards Bjoern

2 1

[aur-general] TU application -- Santiago Torres-Arias
by Santiago Torres-Arias 06 Aug '18

06 Aug '18

Hello everyone, Formalities first, Christian Rebischke (Shibumi) is sponsoring my application, although I'd like to thank so many people for their feedback, help, guidance and counsel in all-things-Arch*. My name is Santiago Torres-Arias[1], and I'm a Mexican PhD candidate from New York University. My research focuses on securing the dev-ops pipeline/supply chain, which includes work on package manager security, version control system security, securing container orchestrators, reproducible builds, so on and so forth. It is not a coincidence that all of these relate strongly with Linux; I believe the Linux environment pretty much shaped my professional career since I was in High School. I've been a GNU/Linux user for more than I can remember, although I started using it exclusively circa 2011. I started using Debian, Mint and Ubuntu interchangeably for a couple of years and, as time passed, I started to develop personal scripts and unscrew my deterministically-broken distro (I still remember my hook to fix the fglrx install every time X was updated). This experience threw me to the other side, and for a while I thought I could maintain my own LFS-based distribution with scripts of this sort, which led me to learn a lot about what *not* to do when managing packages. However, It was when I finally decided to give Arch a serious try (around 2014) that I found myself enamored with not only the toolchains, but the community and the philosophy behind the distribution --- I'm now a strong supporter of the Arch Way(tm) thanks to all the leasons learned through the winding roads of linux-system-administration. Although I've always been an assiduous user of the AUR, not only using but writing my own PKGBUILDs, It was only until recently (about 8 months now), that I've been working towards becoming more familiar with the package ecosystem with the end goal of becoming a TU. I've received feedback from many members on the community on how to fix, extend and follow best practices on writing PKGBUILDS which I believe has improved their quality[2]. Besides maintaining packages I've been contributing to other aspects of the Arch Linux ecosystem for about three years now. I've participated in the security team almost since its inception, by providing code to the tracker, tracking CVE's and sending advisories. Likewise, I've been a tester for more than a year. I've also participated (although not as much as I've wanted) on the archlinux-reproducible efforts. Finally, I've worked along with shibumi and Pierre in making an automated build of an official Archlinux Docker image. Beyond Arch Linux, I'm a committer to projects like reproducible-builds.org[3], Briar[4], neomutt[5], and The Update Framework (TUF)[6], among others[7]. There are two main reasons for this application to become a TU. First, I want to contribute *more* to a community that has given me so much, and I'm certain that helping packaging tools for everyone in the community repository will only improve the overall user experience. Second, and most importantly, I want to expand the offer of packages in the official repositories. Concretely, I want to maintain the following packages: - Orphaned packages (I'm a regular user of these): - giblib (currently on extra) - python-pylint (currently on extra) - uthash - znc - cvf - netctl (?! currently on core, so I suspect I can't maintain this one) - python-opencl/pyopencl-headers - I'd love to co-maintain some packages that have a packager right now**: - radare-cutter - hub - rtl-sdr - maven - I intend to move the following packages from the AUR: - reprotest - git-latexdiff - python-rstr - python2-grip - inxi - plex-fonts Needless to say, I'm open to discussion on this list. I can extend it with any suggested packages, or discard any packages that aren't deemed popular enough. On a less technical, serious note, I love playing guitar! I have a band and we play progressive, shoegaze, and math-rock. I also like cycling, and reading on pretty much anything. I'm a Rust fanboy and I'm re-learning Verilog, as I'm hoping to play around with the RISC-V ISA and emulate TPM's and other trusted hardware designs. Thanks, -Santiago (Sangy) Torres-Arias [1] https://badhomb.re [2] https://aur.archlinux.org/account/sangy [3] https://reproducible-builds.org [4] https://neomutt.org/feature/new-mail#7-%C2%A0credits [5] https://briarproject.org [6] https://theupdateframework.com [7] https://github.com/santiagotorres * Thanks to eschwartz, shibumi, anthraax, jelle, rgacogne, Foxboron, pid1, Tigrmesh, meskarune et al.! ** This is the first time I make this public, so there's no commitment from the current packager at all

5 12