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] PKGBUILD(s) Review

[Ivy Foster]

On 22 Feb 2018, at  7:45  +0530, Ankit R Gadiya wrote:
> Hi everyone,
> 
> I added two new PKGBUILD(s) today in the AUR, both are plugins for vim.
> Any advice, suggestions or feedback will be greatly appreciated.
> And if anybody would like the *-git versions of these I will be more
> then happy to add them as well.
> 
> 1. ranger-vim: https://aur.archlinux.org/packages/ranger-vim/
> 2. tcomment-vim: https://aur.archlinux.org/packages/tcomment-vim/
> 
>   install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/plugin/tcomment.vim" 
> \
>   "${pkgdir}/usr/share/vim/vimfiles/plugin/tcomment.vim"
>   install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/doc/tcomment.txt" \
>   "${pkgdir}/usr/share/vim/vimfiles/doc/tcomment.txt"
>   install -Dm755 
> "${srcdir}/${pkgname/-/_}-${pkgver}/autoload/tcomment.vim" \
>   "${pkgdir}/usr/share/vim/vimfiles/autoload/tcomment.vim"

Normally I wouldn't actually comment on this niggle, but I'd argue
that it's often best to optimize for legibility.

Now, there are definitely religious differences on this point. The
names of the packages are almost certainly not going to change (unlike
the versions), so personally, I'd say that "tcomment-vim" is going to
be immediately clearer to the reader than $pkgname, and "tcomment_vim"
is *definitely* going to be clearer than "${pkgname/-/_}" (and the use
of the shell replacement is what inspired me to make this comment).
Granted, it's not going to be *difficult* to figure out, but there you
go. Anything else others already mentioned.

Cheers,
iff

Re: [aur-general] TU application: Ivy Foster

[Ivy Foster]

On 10 Feb 2018, at  1:02  +0100, Alad Wenter via aur-general wrote:
> the proposal has been accepted. Congratulations!

Awesome! Thanks, y'all.

Ivy


signature.asc
Description: PGP signature

Re: [aur-general] TU application: Ivy Foster

[Ivy Foster]

On 01 Feb 2018, at  8:29  +0100, Levente Polyak via aur-general wrote:
> On January 30, 2018 11:37:42 PM GMT+01:00, Ivy Foster <i...@escondida.tk> 
> wrote:
> >I'll have some time free tomorrow to get you a proper answer and/or
> >fix; for now, I'm just letting you know I got your email!

> Hey, any news from respecting LDFLAGS and if needed just purge parts of it? 
> I'm specially interested in seeing full relro.

Hey, Levente. Sorry for the delay!

For cgo, since upstream pulled in the patches I submitted, LDFLAGS are
properly picked up and we have full relro.

libbulletml was a bit tougher. I wound up throwing out Debian's
patches to upstream's Makefile and just rewriting the Makefile from
scratch. Hopefully either Debian or the dev will be interested in
accepting the new Makefile; until word comes back, it's [in the AUR
git repo][1]. This also grants full relro.

I've yet to run checksec on my other packages, but intend to do so.
I'm not sure yet what to do about some of its feedback, notably
thinking that some binaries aren't ELF files (so no PIE feedback
given) or the number of unfortified...things.

Thanks again for your feedback!

Ivy

[1]: https://aur.archlinux.org/cgit/aur.git/tree/?h=libbulletml


signature.asc
Description: PGP signature

Re: [aur-general] TU application: Ivy Foster

[Ivy Foster]

On 28 Jan 2018, at  9:33  +0100, Levente Polyak via aur-general wrote:
> Hey, good luck and such

Thanks!

> Just noticed [some interesting points]

I'll have some time free tomorrow to get you a proper answer and/or
fix; for now, I'm just letting you know I got your email!

Thanks,
Ivy

Re: [aur-general] TU application: Ivy Foster

[Ivy Foster]

On 27 Jan 2018, at 10:40  +0100, Christian Rebischke via aur-general wrote:
> On Fri, Jan 26, 2018 at 03:23:08PM -0600, Ivy Foster wrote:
> Hello Ivy,
> Do you plan to adopt some orphans as well?

Definitely!

Quickly scanning through the list, a few stand out to me...though they
generally don't look as though they need updates right away.

- bmake
- cd-discid (if I were to crab this one, I'd probably also take
cddb_get, even though I've had little luck with cddb results)
- ispell
- libcdaudio
- unicode-character-database

Beyond that, I'd say "sure, if it looks interesting or necessary" and
"I can at least update and then re-orphan this thing I don't use".

iff

[aur-general] TU application: Ivy Foster

[Ivy Foster]

On 27 Jan 2018, at  9:39  +0100, Pierre Neidhardt,
Andrew Crerar, and Johannes Löthberg wrote:
> [some very nice things]

Thanks!

Re: [aur-general] TU application: Ivy Foster

[Ivy Foster]

On 26 Jan 2018, at  4:35  -0500, Eli Schwartz via aur-general wrote:
> On 01/26/2018 04:23 PM, Ivy Foster wrote:
> > I'm writing to apply to be a TU, and Alad Wenter has kindly agreed to
> > be my sponsor.

> It is great to see you take the plunge, I wish you the best of luck!

Thanks!

> > Arch has always been a rewarding community to contribute to, and I
> > figure that maintaining some packages and generally helping out could
> > be a good way to contribute a bit more.
> > 
> > If accepted to be a TU, my plan of action is as follows:
> > 1. Go mad with power^U
> > 1. Bring a handful of packages into [community] (see below)
> > 2. Help out with rebuilds and package updates where that does not
> > involve stepping on toes
> > 3. Continue to submit occasional patches to Arch projects
> > 4. Help with to-do lists. [...]

> Sounds like a (wo)man after my own heart!

Woman, and glad to hear it!

> This reminds me I still have so much to do... like all that https/gpg stuff.

There's always more to do, I guess.

> > Thanks for your consideration, and I'm of course happy to answer
> > questions and address critiques.

> But overall, quite good!

Thanks!

> > - ledger
> > This program is super useful, and I doubt I'm the only one who
> > dreads every boost update because this takes so long to build!

> Lukas has beaten you to it: https://packages.archlinux.org/ledger

I replied to this elsewhere already, but that's great news (-: . In
related news, I've [poked upstream][1] to see about a new release, since
there's been a year's worth of bugfixes! They're into it.

# Critiques & Responses

> We discussed this on IRC already, I'll have to check and see how you've
> adapted to my suggestions.

I've addressed most of them; see responses inline. Of course,
onlookers should judge each fix to make sure it's not a "fix" instead.

## cgo-git

> 2018-01-25 07:07:51 PMguysI noticed something immediately, 
> cgo-git has
> a custom:cgo-git license, but it is really an ISC license.
> 2018-01-25 07:08:15 PMguysAnd it installs the whole source code in
> /usr/share/licenses/ instead of using sed to extract it or something. :p
> 2018-01-25 07:09:25 PMguysI'd just extract the first few lines 
> using
> sed, until I hit the first  */ and call it a day

I've changed the license to ISC and used sed to extract the license
from the source. I've also [submitted a patch upstream][2] creating a
separate LICENSE file.

> 2018-01-25 07:11:25 PMguysAlso, the upstream Makefile is terrible 
> and
> should use CFLAGS properly :p
> 2018-01-25 07:12:27 PMguysI want pull requests to fix this :p

[Pull request submitted][3].

> 2018-01-25 07:14:28 PMguysfist, should be upgraded to use HTTPS 
> since
> their website upgrades you anyway

[Done][4].

## frotz-dumb-git / frotz-ncurses-git

> 2018-01-25 07:27:55 PMguysfrotz-git conflicts and *replaces* 
> frotz,
> which is wrong, it should provide it instead
> 2018-01-25 07:28:23 PMguysreplaces means that if you pacman -Syu 
> and
> find it in a repo, it gets synced as a replacement for what you
> currently have...

> 2018-01-25 07:29:11 PMguysI can hardly read the sed line you use 
> in
> pkgver()
> 2018-01-25 07:29:22 PMguyssed 's,-\(.*\)-,.r\1.,'
> 2018-01-25 07:29:30 PMguyswrong place to use , as separators!
> 2018-01-25 07:33:03 PMguysBut anyway, to modify 2.44-196-gf3ceac9
> could just use the standard sed line from the wiki page
> 2018-01-25 07:34:05 PMescondida   that one *I* can hardly read (-:

> 2018-01-25 07:35:48 PMguysUse of sed to modify more than three 
> things
> in prepare should be strictly prohibited; use a patch file

[All fixed][5]. I still refuse to use the sed line from the wiki page,
because I'm a big weirdo.

## libbulletml & rrootage

> 2018-01-25 07:39:48 PMguys> # upstream does not provide checksums,
> though Debian does for their patches
> 2018-01-25 07:40:04 PMguysThis is not a reason to disable checks 
> for
> download errors.

I've [added checksums][6], along with a note not to place too much
trust in them since they're mine and not the developer's.

> 2018-01-25 07:41:09 PMguysWhy does libbulletml.so need to modify
> CFLAGS CXXFLAGS :(
> 2018-01-25 07:41:21 PMguysAnd why does it overwrite LDFLAGS, 
> instead?
> 2018-01-25 07:41:41 PMguysDoes it derp on the LDFLAGS from 
> makepkg.conf?
> 2018-01-25 07:42:17 PMguysWhy does it create libbulletml.a 
> anyway, if
> makepkg automatically strips staticlibs?

This library's build process 

Re: [aur-general] TU application: Ivy Foster

[Ivy Foster]

On 26 Jan 2018, at 10:31  +0100, Alad Wenter via aur-general wrote:
> Note: If possible please add a short reply with a GPG signature.

My mistake! Here's my official, signed reply.

Eli Schwartz wrote:
> Lukas has beaten you to it: https://packages.archlinux.org/ledger

That is excellent news!

Thanks,
Ivy

signature.asc
Description: PGP signature

[aur-general] TU application: Ivy Foster

[Ivy Foster]

Hi, folks,

I'm writing to apply to be a TU, and Alad Wenter has kindly agreed to
be my sponsor.

I've been an Arch user for the last 10 years or so. Some of you may
know me from IRC or the forums, where I use the nick escondida.
Lately, I've been much less active on IRC, but have contributed a
handful of patches to pacman. I also maintain [a few buildscripts][1]
in the AUR.

Arch has always been a rewarding community to contribute to, and I
figure that maintaining some packages and generally helping out could
be a good way to contribute a bit more.

If accepted to be a TU, my plan of action is as follows:
1. Go mad with power^U
1. Bring a handful of packages into [community] (see below)
2. Help out with rebuilds and package updates where that does not
involve stepping on toes
3. Continue to submit occasional patches to Arch projects
4. Help with to-do lists. Off the top of my head, taking a quick look
at current to-do lists with actual outstanding items:


https://www.archlinux.org/todo/packages-with-out-of-repositories-dependencies/
I'd be interested both in simply weeding out those
with inappropriate deps and in bringing in deps I'd
consider actually useful, such as tcllib for tcl-remind.

https://www.archlinux.org/todo/source-retirement/
https://www.archlinux.org/todo/codegooglecom-retirement/
I wouldn't mind tracking down lost sources.

Thanks for your consideration, and I'm of course happy to answer
questions and address critiques.

Cheers,
Ivy "escondida" Foster

# Packages

If I'm accepted, there are a handful of packages I already have in
mind to bring to the repos:

- [bemenu][2]
Though dmenu is already available, bemenu is a solid
alternative for X, Wayland or terminals.

- [farbfeld][3]
An oddball but interesting new image format

- [frotz][4]
I don't know about you guys, but I think that text adventures
are positively xyzzy.

- [ledger][5]
This program is super useful, and I doubt I'm the only one who
dreads every boost update because this takes so long to build!

- [muttprint][6]
I don't always print emails, but when I do, I use muttprint.

- [opendoas][7]
OpenBSD's much simpler alternative to sudo is now available
for Linux.

- [physlock][8]
A tty screen locker

- [sndio][9]
OpenBSD's excellent and simple sound system is now available
as a userspace daemon for Linux, and a surprising number of
things can build against it easily.

Note that if I did bring this in, I wouldn't be including my
very basic XDG basedir patch (see AUR scripts). I'm going to
try and submit a better one upstream, and if that fails,
then...oh, well, I guess.

- [t-prot][10]
It's just a simple script, but as a mutt user, it comes very
much in handy for making many emails more legible.

- [translate-shell][11]
Very useful for simplifying or scripting translation tasks
(not that you should be counting on google translate to handle
anything longer than a few words, but still)

- [xurls][12]
Saves you the trouble of parsing strings to find links

# Links

[1]: https://aur.archlinux.org/packages/?SeB=m=escondida
[2]: https://github.com/Cloudef/bemenu
[3]: https://tools.suckless.org/farbfeld/
[4]: http://frotz.sourceforge.net/
[5]: https://www.ledger-cli.org
[6]: http://muttprint.sourceforge.net/
[7]: https://github.com/Duncaen/OpenDoas
[8]: https://github.com/muennich/physlock
[9]: http://www.sndio.org/
[10]: http://www.escape.de/~tolot/mutt/
[11]: https://www.soimort.org/translate-shell/
[12]: https://github.com/mvdan/xurls

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

Re: [aur-general] Deletion of orphaned packages on AUR4

[Ivy Foster]

On 11 Aug 2015, at  3:48 pm +0200, Johannes Dewender wrote:
 [snip]

 I uploaded both to AUR3 and also to AUR4.
 I maintain the free branch, because I think this is the better variant.
 Having the original on AUR would be good, so I also updloaded these, but
 I personally don't want to maintain these.

 There are however some users that still want to use the original.
 There aren't many changes either, since the original doesn't have
 releases often.
 (the free branch has lots of releases)

If and only if there is somebody who still wants to use the
original, they'll upload and maintain a PKGBUILD
themselves. So it is with any package.

Remember, Arch assumes a baseline of competence--or at least
willingness to read--on the part of the user, and Arch's
packaging tools are dead simple if you actually bother to
learn them. There's no need to upload scripts to the AUR on
behalf of some nebulous concept of the average user, because
the average Arch user can do it themselves if they want to.
Have some faith in your fellow users, and let's all work to
make the new AUR less of a horrible mess than the old one.

iff