- Aur-general - lists.archlinux.org

[aur-general] AUR rate limiting
by Drew DeVault 22 Dec '18

22 Dec '18

Following up from IRC. Hello! I run a public build service which has Arch Linux support and uses yay to install AUR packages when requested. I recently had some users running up against the AUR rate limit. The current rate limit window (1 day) seems a bit strict. Would it be possible to apply the rate limit hourly? Today it's 4000 requests per day, but ~166 requests per hour would be a similar load on the server but a bit more forgiving, users would only have to wait an hour before attempting their builds again. The long term solution is probably to mirror the AUR or adjust the approach to try and minimize API requests (perhaps by cloning the repos and sorting out dependencies by sourcing the PKGBUILDs.... would be a bit involved). Any thoughts or advice? -- Drew DeVault

7 9

Re: [aur-general] TU application: Daurnimator
by Alad Wenter 18 Dec '18

18 Dec '18

On 12/11/18 8:30 PM, Alad Wenter wrote: > Since the discussion period is about to end without much discussion... > > Right now the rate of new applications is very high - about 2 new > applications per month. That makes a thorough review difficult. > > Considering the positive experiences of the sponsor, it would be a shame > to let a voting period pass. That said, I'm not sure we have sufficient > information - at present - to proceed with such a voting period in a > meaningful manner. > > So about Foxboron's question for confirmation: "Say one or two people > confirm they think the voting process should be continued after the > discussion has ended?" - I don't know. > > Alad Let's try to get the ball rolling by asking some questions. 1. When I look at LUA modules, I see that most are available on "luarocks", which is apparently a package manager for LUA. Can you leverage this to make more LUA modules available on Arch? 2. You have some AUR packages for LUA modules of your own making, yet they hardcode gcc lines instead of using a Makefile. [1] (At least they respect $CFLAGS and $LDFLAGS, I guess.) Why? 3. I have no idea on what some of your more complicated packages do, or why they would require said complexity, e.g. iup. [2] Perhaps you could explain a bit on that regard. 4. Related to the above, there are no current packaging guidelines for LUA packages. [3] Do you plan on starting an effort (possibly with other LUA package maintainers) to remedy this? [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lua-compat53 [2] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=iup [3] https://wiki.archlinux.org/index.php/Arch_package_guidelines#Additional_gui… Alad

6 19

[aur-general] Building mingw packages
by hagar 15 Dec '18

15 Dec '18

Good morning All, I have been cleaning up my build system and building all my packages. In doing so I have come across a problem that affects all mingw packages that nuse gcc. mingw-w64-gcc is built with --disable-dw2-exceptions however it would seem that windows is a dwarf system, so mingw-w64-gcc should have been built with --disable-sjlj-exceptions. This most affects the building of mingw-w64-rust which wont build on a sjlj mingw system. And there are a large number of packages that depend on mingw-w64-rust. My question's are - 1. Should mingw-w64-gcc, mingw-w64-gcc-bootstrap and mingw-w64-fs be changed to reflect this so that all mingw64 packages are built the same way? 2. mingw-w64-rust is being installed to /opt/rust, should it be instead installed to /usr/x86_64-w64-mingw32 and /usr/i686-w64-mingw32, as are all the other mingw packages? Thanks Macca ||

1 0

Re: [aur-general] Could someone help with maintenance of bgyorgy's packages?
by Muflone 15 Dec '18

15 Dec '18

> Hi all, > > Balló György (bgyorgy) was inactive for more than 2 months, I emailed to him > without success. Could someone help with maintenance of his packages? In > particular, gpxsee-5.18 package has been flagged out-of-date since > 2018-09-23. New gpxsee 6.0, 6.1, 6.2, 6.3, 7.0 have released since then. Balló György is alive and the gpxsee 7.0-1 was updated on 2018-12-11. -- Fabio Castelli aka Muflone

1 0

[aur-general] gnome-shell-extension-desktop-icons
by Stefano Capitani 12 Dec '18

12 Dec '18

Hi there, sorry if isn't the right mailing list for this request or discussion feel free to point me in the right mailing list or move this. I ask if is possible to change this package https://aur.archlinux.org/packages/gnome-shell-extension-desktop-icons/ because not reflect the real state of this package: i think is better adding the -git suffix since is build from git. I have already asked to change the name of the package ( you can see the request in the comments ). I have ready a pkgbuild for build fixed package ( based on gitlab tag ) because i have build for Manjaro but i can't pushing here since i have this issue. Thank you in advance -- Greetings Stefano Capitani

1 0

[aur-general] Help with python-magic-wormhole PKGBUILD
by Storm Dragon 12 Dec '18

12 Dec '18

Howdy, I have had a few people post that they are having trouble with this since it became a split package. Currently, I am unable to reproduce the problems. I have installed it both with yay and with makepkg. I do see one who tried to install it as a group, and since both provide the same package, that would conflict, but they should be able to install either python2-magic-wormhole or python-magic-wormhole. I Can't find anything wrong with the PKGBUILD. Can someone please take a look and let me know if there's anything I can do to make it work better for these people who are having problems? https://aur.archlinux.org/pkgbase/magic-wormhole/ Thanks, Storm -- Powered by Arch Linux! I am registered Linux user number 508465: https://linuxcounter.net/user/508465.html get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 How to load Windows on your machine in 2 minutes or less: http://www.youtube.com/watch?v=FVbf9tOGwno "Death or glory i will find, Rebellion on my mind." Grave Digger - Rebellion (The Clans Are Marching)

3 10

[aur-general] TU Application: Daniel M. Capella
by Ivy Foster 06 Dec '18

06 Dec '18

Hello, everyone! The results are in! Congratulations, Daniel! Welcome to the team. Stats: 34 Yes 6 No 7 Abstain Cheers, Ivy ("escondida") P.S.: Please forgive the broken threading; I foolishly cleaned out too much of my inbox last week!

2 1

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

03 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