- Aur-general - lists.archlinux.org

[aur-general] I'm wonder is there any tool to list TU's workload?
by Daniel YC Lin 19 Aug '18

19 Aug '18

I guest the TU's workload may be calculated by a. How many packages which he owns. b. How many commits during a past year c. How many bugs required to solved? To print out by graph maybe interesting. These may be calculated by some SQL if owned the access permission of database. For person without permission may pull the packages and bugs listing and git log to get that picture

2 1

[aur-general] TU application - Daniel YC Lin
by Daniel YC Lin 19 Aug '18

19 Aug '18

Hello, My name is Daniel YC Lin, I'm 48 years old and I'm programmer in Taipei, Taiwan. On the forums and irc you can find me as dlintw. As you can see with some of my packages [https://aur.archlinux.org/packages/?O=0&SeB=m&K=dlin& <https://aur.archlinux.org/packages/?O=0&SeB=m&K=dlin&>] I'm interested in packaging for arch related zh-tw locale packages. I've nearly 30 years shell scripts experiences. I've build Archlinux on sh4 CPU about 4-5 years ago. During that experience I've learned from uboot to linux kerenl and all 'base' packages build from scratch. There are no special packages which I wish to put in my repository. I wish to share the loading of Felix Yan for example (gcin) My sponsor is Felix Yan. Best Regards, Daniel Lin

2 3

[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

[aur-general] Keras circular dependency resolution
by Robby Stokoe 31 Jul '18

31 Jul '18

Keras recently moved two of its submodules to separate modules---keras-applications, and keras-preprocessing [1]. These also import keras and will not work without it, nor will keras work without those submodules. Currently the submodule packages depend on keras, but making keras depend on the submodules creates unresolvable circular dependencies. Currently the submodules are listed as optional dependencies of keras with the note that keras will not work without them. This seems like a problem to me. Someone wanting to install keras will be able to do so without installing the submodules but won't be able to use it without them. The only warning will be the optional dependencies which seems insufficient to me. Since both actually depend on the other(s) to work, the only solution I can see is to include them all in the python-keras package. Is there any other way to resolve this? Is it not as big of a deal as I think it is? How would such a change even get implemented? Thanks. [1]: https://github.com/keras-team/keras/pull/10339

2 1

[aur-general] TU application -- Santiago Torres-Arias
by Santiago Torres-Arias 27 Jul '18

27 Jul '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*. > > Apologies for being somewhat late with the ztrawchse review. > > argon2-git: > - CC-0 is, apparently, not common enough to be in the licenses package. > As such, the license should be marked as 'custom:CC-0' and installed > to /usr/share/licenses/$pkgname/ > see how core/argon2 does this > > git-latexdiff: > - unquoted srcdir/pkgdir > - license is not, in fact, GPL > - the source file has a unique name, but then you told makepkg to rename > it to something non-unique. I.. must admit this is new to me... > > in-toto: > - sources seem to come with a testsuite, this should be run in a check() > function > > python-securesystemslib: > - the check() function does not accept depends, this is broken > - multiple depends are deleted and overridden in the package() function > - empty optdepends array can be deleted > - tox doesn't really test what needs testing, code should be tested > using the native testsuite hooked up to the packaged system > dependencies > - license is the literal file (rather than a file within the directory > of this name): /usr/share/licenses/python-securesystemslib > > reprotest: > - multiple depends are deleted and overridden in the package() function > - optdepends could use description of what additional functionality they > provide when installed > Thanks for the feedback! I'll apply this changes as soon as I get back from work :) -Santiago.

1 0

[aur-general] TU Application - Filipe Laíns
by Filipe Laíns 24 Jul '18

24 Jul '18

Hello, My name is Filipe Laíns. You might also know me by my alias, FFY00. I am applying to be a Trusted User with Dan Printzell's (Wild) sponsorship. Let's get to the part where you get to know me a bit more I am a Portuguese student and I use Linux as my main operating system since 2013. I gave Arch a try last year and I've been in love with it's ecosystem ever since. Since then, I started contributing to AUR and I've been maintaining quite a few packages. I am also fairly active in the Open Source community as you can see in my Github profile[1]. I love to help people and that is my main motivation to become a TU. If I do become a Trusted User, one thing I would like to do is to improve the usability of Arch for SDR (software defined raio) development. I think Arch is a great system for this and it's a bit of a shame that one of the most relevant packages (soapysdr) isn't in any official repo. Most of the work to improve the SDR support in Arch has been done by Kyle Keen, and I thank him for that, but I still think we could do a bit more. I don't plan to only maintain SDR related packages. I would like to maintain anything that I use, or anything that is relevant to anyone, really. If it makes someone's life easier it's a win. With that being said, here's a list of packages that I plan to move to community: - soapysdr - soapyrtlsdr - libratbag - piper - tribler - qspectrumanalyzer - pulseaudio-equalizer-ladspa - synology-cloud-station-drive Some comments on the packages, (soapysdr and soapyrtlsdr) soapysdr is a vendor neutral SDR driver[2] and soapyrtlsdr is the rtlsdr plugin for it. The non -git versions of the packages are quite recent so they don't have much votes yet. Their correspondent -git variants have enough votes. (libratbag and piper) libratbag is a DBus daemon to configure gaming mice[3] and piper is a GTK+ app to interface with it. I do not maintain this packages but I contribute to the upstream development. It would be helpful for the project if they were moved to an official repo as we are thinking about changing our CI's base distribution from Fedora to Arch. (tribler) Tribler is a popular torrent client with P2P content discovery[4]. (qspectrumanalyzer) This is a popular spectrum analyser for SDR devices[5]. It uses soapysdr as its default driver so it supports a wide range of SDR devices. (pulseaudio-equalizer-ladspa) This is a pulseaudio equalizer based on a ladspa plugin. It has a nice GTK+ based front-end to configure it. (synology-cloud-station-drive) This is a drive client for Synology devices[6]. I am also interested in adopting the following packages in community: - netcf - znc (packages bellow - probably, depending on my free time) - python2-caja - python2-cheetah - python2-exiv2 - python2-fastimport - python2-ipaddr I think that's it, thanks for bearing with me until the end. Best regards, Filipe Laíns ^.^ [1] https://github.com/FFY00 [2] https://github.com/pothosware/SoapySDR/wiki#features [3] https://github.com/libratbag/libratbag#libratbag [4] https://github.com/Tribler/tribler#tribler [5] https://github.com/xmikos/qspectrumanalyzer#qspectrumanalyzer [6] https://www.synology.com/en-global/releaseNote/CloudStationDrive

5 11