Re: [aur-general] Spring cleaning (moving orphaned packages from [community] to AUR)

[Ivy Foster via aur-general]

On 04 Mar 2020, at  2:16 pm -0800, Yardena Cohen via aur-general wrote:
> On Tue, Feb 25, 2020 at 7:23 AM Alexander F Rødseth via aur-general 
>  wrote:
> > privoxy - A web proxy with advanced filtering capabilities.

> I'd hope that privoxy doesn't get dropped - it's necessary for using
> Tor in most cases https://wiki.archlinux.org/index.php/Privoxy

It got adopted the day the message went out, I believe. Note the new
maintainer on [its page][1]. For future reference, you can always
search for packages using Arch's [package search][2].

[1]: https://www.archlinux.org/packages/community/x86_64/privoxy/
[2]: https://www.archlinux.org/packages/


signature.asc
Description: PGP signature

Re: [aur-general] TU resignation - Lukas Jirkovsky (stativ)

[Ivy Foster via aur-general]

On 11 Oct 2019, at  6:32 pm +0200, Morten Linderud via aur-general wrote:
> > So Long, and Thanks for All the Fish

Thanks for your work all these years!

> Added a list of packages maintained solely by stativ. Please adopt as people 
> see fit :)

> λ ~ » /usr/share/archlinux/contrib/package/co-maintainers -m stativ
> ttf-gentium

Adopted.

Cheers,
Ivy

Re: [aur-general] TU application: Daurnimator

[Ivy Foster via aur-general]

On 11 Dec 2018, at 12:10 pm -0800, Daurnimator wrote:
> On Tue, 11 Dec 2018 at 12:04, Robin Broda via aur-general 
>  wrote:
> > On 12/11/18 9:00 PM, Daurnimator wrote:
> > > On Tue, 11 Dec 2018 at 11:45, Alad Wenter via aur-general 
> > >  wrote:
> > >> 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?

> > > The upstream packages do not ship a makefile; they "officially" only
> > > support luarocks for building.

> > You are upstream, you have the power to make a change for the better

> The problem is that there is no nice cross-platform makefile structure
> suitable for lua libraries.

> Each operating system/distro calls the lua shared library something
> different, they all have their own set of required and conflicting
> flags, they all have differing install locations and search paths!

Yikes!

One ugly but workable solution could be to conditionally set variables
in a Makefile. For instance:

ifeq ($(OS),Windows_NT) # for Windows versions >= NT
LUA := C:\Winders\Path\To\Lua.whatever
else
UNAME := $(shell uname -s)
ifeq ($(UNAME),Linux)
LUA := ...
endif
...
endif

Granted, this likely duplicates some of the magic luarocks is doing,
but it would make things simpler for packaging.

Come to think of it, that seems like the sort of thing that could be
done once as boilerplate in, e.g., lua.mk, which you and other
luarines (lua-ites? luans? lua-ers?) could then include in future
Makefiles.

Just spitballing here; lua packaging is weird (-: .

Cheers,
Ivy ("escondida")


signature.asc
Description: PGP signature

Re: [aur-general] TU application: Daurnimator

[Ivy Foster via aur-general]

Thanks for the application, Daurnimator!

Looking at arcan, why do you break it up into so many different
sub-packages? I understand that they provide different tools, but
typically Arch just packages toolsuites together unless there's a
compelling reason to separate some of them.

Also, libarena has https sources/url available.

Cheers,
Ivy ("escondida")


signature.asc
Description: PGP signature

[aur-general] TU Application: Daniel M. Capella

[Ivy Foster via aur-general]

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!


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Daniel M. Capella

[Ivy Foster via aur-general]

The two week discussion period is over! Let the voting period begin!

https://aur.archlinux.org/tu/?id=114


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Daniel M. Capella

[Ivy Foster via aur-general]

I confirm my sponsorship; let the games (or discussion, I guess)
begin!

iff ("escondida")


signature.asc
Description: PGP signature

Re: [aur-general] On TU application, TU participation and community/ package quality

[Ivy Foster via aur-general]

Santiago, thanks for writing up the discussion to date!

On 11 Nov 2018, at  1:29 pm -0500, Santiago Torres-Arias via aur-general wrote:
> 1. Add a council of TU's to introduce oversight on the whole voting
>process

> 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.

I'm pretty new to the whole TU thing, but I'm a little leery of this
idea for a few reasons. As you mention, there are power dynamics at
play once you start getting into things like this.

Perhaps more importantly to the discussion at hand, I would also argue
that such a set-up would do little to take the load off of the handful
of high-participation TUs; if anything, I can see it *adding* to their
load by formalizing their ad-hoc status.

> 2. Increase the minimum number of sponsors per application

This could be helpful, particularly when it comes to giving advice to
newly-appointed TUs.

> 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. 

Granted. With any luck, this very discussion will help *some* with
that issue, but if we go with proposal 2, perhaps participation issues
could be handled as a separate problem altogether. I know that,
personally, I almost never participate in new candidate discussions
simply because I don't feel I have anything to add.

> 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

> 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.

I'm pretty conflicted about this idea, to be honest. Although I'm all
for having some sort of oversight, the cynic in me forsees all kinds
of problems even if you assume that all parties involved are acting in
good faith (which I do choose to assume here).

Even given the existence of TU guidelines, we would probably need to
set up some very specific, enforceable rules in order for this to be
at all workable. Would there need to be a participation quota? How
strict do we really want to be about package popularity? Whose idea of
"high-quality" are we using? Unless there are definite answers, we're
right back where we started, with a set of guidelines to be played by
ear--but now with the added overhead of a subcommittee structure.

Personally, I'm inclined toward simply increasing the number of
sponsors and encouraging sponsors to help their candidates learn the
ropes of proper Trusted Using. If nonparticipation continues to be a
problem, that can be a separate discussion.

Cheers,
Ivy


signature.asc
Description: PGP signature

Re: [aur-general] TU Membership Application

[Ivy Foster via aur-general]

On 07 Nov 2018, at  5:41 pm -0700, Brett Cornwall via aur-general wrote:
> On 11/05/18 07:48pm, Levente Polyak via aur-general wrote:
> > - don't think pkgdesc should ever end with a dot

> The descriptions are often sentences, so would it not reason to end them
> with a period?

In the case of actual sentences, it's just convention to be consistent
with the packages whose descriptions are sentence fragments. It's a
bit arbitrary, granted.

> > - not a big fan of fiddling with PKGEXT even if its "just the AUR" but
> > well
> 
> For a package destined for the repositories I would not fiddle and endeavor
> to reverse such fiddling; however, the compression time for large games is
> enormous only to decompress right after. Should it, for the sake of
> correct-ness, be reversed even for the packages doomed forever to live in
> the AUR?

It's just not the prerogative of the AUR contributor to make that
decision for the end-user who's going to be building the package. They
can very easily configure their own makepkg.conf to use uncompressed
tarballs if they so desire. Basically, a PKGBUILD shouldn't override
makepkg.conf unless there's a very good reason.

Cheers,
Ivy

signature.asc
Description: PGP signature

Re: [aur-general] VCS package guidelines

[Ivy Foster via aur-general]

Eli Schwartz via aur-general  wrote:

> On 03/08/2017 04:06 PM, Ralf Mardorf wrote:
> > On Wed, 8 Mar 2017 18:00:52 -0300, Rafael Fontenelle wrote:
> >> 2017-03-08 17:53 GMT-03:00 Ralf Mardorf :
> >>> my understanding is, that if possible, it should look like this
> >>> 1.2.r3.gabcdef7
> >>> and not alternatively
> >>> 1.2_r3_gabcdef7
> >>> or
> >>> 1.2_3_gabcdef7

> In other words, maintainers of any stripe are absolute dictators over
> their package, as long as they don't commit offenses against the AUR
> package-hosting service itself, which would be grounds for deleting the
> package, and they keep their package up to date with upstream releases,
> which failure to do so is grounds for package orphaning. You (rhet.) can
> (and often do) highly disapprove of their choices, but at the end of the
> day, they cannot be *forced* to do anything.

Of course, you also can't be forced to install a packaging whose
versioning or build options you dislike. PKGBUILDs are trivial to edit
to taste.

I recognize that the AUR ML is a slightly heretical place to suggest
this, but...the AUR is not the end-all-be-all of packaging scripts. If
you don't like what you see there, write your own or edit an existing
one. It'll take you under five minutes if you start from scratch.

In short, if you don't like what you see on the AUR and it's not
actually harmful, ignore it. You'll be happier you did.

iff