-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi all,
I'm applying to be a Trusted User; Foxboron has kindly sponsored me and has been mentoring me on the specifics over the last couple of months.
I've been using Arch since 2010, having been present in #archlinux almost the whole time! Before that I was a Xubuntu user from approximately 2005. Before that I had flirted with Linux a few times, I think my first exploration of Linux was of Lindows back in 2001.
With my programming hat on, I mainly use C and Lua, I'm quite heavily involved in the Lua community. I would like to become a trusted user with the primary goal of improving Arch's Lua packages.
With my sysadmin hat on, I'm an admin at hashbang.sh, an online hackerspace/incubator. Amoung other services, we run public shell servers with a fully open configuration. At $DAYJOB roles I've been responsible for packaging and deployment on various Linuxes.
With my networking hat on, I maintain a few nodes in Melbourne Wireless, a city-wide wireless network. This has taught me quite a lot about networking hardware and given me the chance to play with routing protocols. I also joined dn42 which is for lack of a better explanation "an internet of VPN tunnels".
If accepted as a TU, I'd like to (co)maintain:
- lua-expat - lua-filesystem - luajit - luarocks
Other packages I'd be happy to co-maintain are:
- awesome - jq - keepassxc - love - lua51-bitop - pcsclite - prosody - rlwrap - tig
Regards, Daurnimator
On Thu, Nov 29, 2018 at 02:03:33AM +1100, Daurnimator wrote:
I'm applying to be a Trusted User; Foxboron has kindly sponsored me and has been mentoring me on the specifics over the last couple of months.
Yo!
I confirm my sponsorship of Daurnimator!
Because of the recent discussion regarding the TU application process, I'll also write some words. Might be a good first step in the right direction.
Daurnimator reached out to Barthalion, Antonio and Anatol (I think) on the 6th of September regarding the current state of our LUA packages where he wanted to help improve the situation. Barthalion threw me into the mail chain on the 12th of September, and I have been following up on him since then :)
I have also done two reviews of his AUR packages to the best of my ability (I don't know LUA very well). One when we initially started talking in September, and last one before the application was sent. Most of the "errors" where stylistic, and some mistakes when downloading sources where they where not named properly. They have been fixed and daurnimator has also sought advice in #archlinux-aur when my explanations where not on point.
All-in-all I have a very positive experience with working with him during this process.
As of the recent discussions; We could try the "co-sponsorship" before the voting process? Say one or two people confirm they think the voting process should be continued after the discussion has ended?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 29 Nov 2018 at 02:20, Morten Linderud via aur-general <aur- general@archlinux.org> wrote:
I confirm my sponsorship of Daurnimator!
Thank you for sponsoring!
Also, I was just informed that a TU application should contain links :D
Me:
AUR profile: https://aur.archlinux.org/account/daurnimator/ Github: https://github.com/daurnimator/ Personal site: https://daurnimator.com/ Twitter: https://twitter.com/daurnimator
Projects:
Hashbang: https://hashbang.sh/ https://github.com/hashbang/ Fengari: https://fengari.io/ Melbourne Wireless: https://melbournewireless.org.au/
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
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")
On Tue, 11 Dec 2018 at 12:25, Ivy Foster via aur-general aur-general@archlinux.org wrote:
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.
arcan is a display server/protocol like x11 or wayland.
The upstream releases include demo programs and misc tools. IMO including them all in one package would be like including xeyes in the xorg-server package: very few users would find it useful. Other pieces like arcan-acfgfs bring in dependencies (in this example: fuse3) that are not necessary for the protocol as a whole.
Also, libarena has https sources/url available.
Will update.
On Wed, Nov 28, 2018 at 04:20:22PM +0100, Morten Linderud via aur-general wrote:
As of the recent discussions; We could try the "co-sponsorship" before the voting process? Say one or two people confirm they think the voting process should be continued after the discussion has ended?
There was no negative nor positive reply to this. So I'll omit this and go for the voting period.
Sorry for the delay as the reproducible builds summit took up most of my day :)
https://lists.archlinux.org/pipermail/aur-general/2018-November/034669.html
There's no positive or negative reply to it, because there's still questions left unanswered.
1. Coderobe's comment on use of sed in iup went disregarded. [1] (It appears the https source was addressed, and Daurnimator commented on the static linking.)
2. We don't know why luarocks would be a "runtime dependency" or why this would be problematic in the first place. [2]
3. We don't know why the argument on using pkg-config in LUA should be dismissed. [3]
Considering the questions are relevant regarding the use of bare gcc lines (!) in PKGBUILDs a candidate may want to add to [community], I'd say it's especially important to answer them. (From a more personal perspective, I'm interested in generally competent Lua package maintainers, as I consider to use the language in some of my projects.)
Now it's almost too late with the voting period already started...
Alad
[1] https://lists.archlinux.org/pipermail/aur-general/2018-December/034694.html [2] https://lists.archlinux.org/pipermail/aur-general/2018-December/034702.html [3] https://lists.archlinux.org/pipermail/aur-general/2018-December/034708.html
On 12/13/18 8:46 PM, Alad Wenter via aur-general wrote:
There's no positive or negative reply to it, because there's still questions left unanswered.
- Coderobe's comment on use of sed in iup went disregarded. [1] (It
appears the https source was addressed, and Daurnimator commented on the static linking.)
- We don't know why luarocks would be a "runtime dependency" or why
this would be problematic in the first place. [2]
This seems to me to be the most important issue. There are other software languages which don't use Makefiles and pkg-config -- I referenced two of them above, their names are "python" and "ghc". They also come with officially blessed mechanisms to use as a standardized build system, and apparently luarocks serves this role for lua.
The luarocks github repository has references to CFLAGS, so it seems to support that already. It does *not* have references to LDFLAGS or CPPFLAGS, not sure what to think of that... it's possible to export CFLAGS="$CPPFLAGS $CFLAGS $LDFLAGS" before building I guess? 🤔
- We don't know why the argument on using pkg-config in LUA should be
dismissed. [3]
This is relevant, I believe, given that daurnimator appears to be a member of both the lua and luarocks organizations on github, and presumably has some degree of influence.
And I do sort of think that pushing things like this to upstream attention is kind of important from a packaging perspective. If I were a lua user rather than an idle bystander who happened to notice something odd being discussed, I would definitely be aggressively advocating for this upstream.
Considering the questions are relevant regarding the use of bare gcc lines (!) in PKGBUILDs a candidate may want to add to [community], I'd say it's especially important to answer them.
It's especially important to answer them given that the candidate's application stated "the primary goal of improving Arch's Lua packages", but so far we have not been told what that means and can only guess based on what others have observed of his PKGBUILDs.
Foxboron, you said your candidate reached out to some people people via email to discuss "the current state of our LUA packages where he wanted to help improve the situation". Was this discussed during that private email conversation?
Daurnimator, can you elaborate on your plans?
I would be very interested to know if the improvements under consideration extend beyond merely packaging some greater numerical count of lua packages.
(From a more personal perspective, I'm interested in generally competent Lua package maintainers, as I consider to use the language in some of my projects.)
Now it's almost too late with the voting period already started...
Hmm, does anyone know who plans to do this sort of review and ask these questions? Given I at least have more or less retired myself from doing so, and even after our fancy vote about giving us more time for it we still ended up not discussing anything until 21 hours before the discussion period ended, I genuinely have no clue what criteria we're supposed to use when casting our votes.
Sorry for delayed reply, I've been travelling.
On Fri, 14 Dec 2018 at 14:44, Eli Schwartz via aur-general aur-general@archlinux.org wrote:
The luarocks github repository has references to CFLAGS, so it seems to support that already. It does *not* have references to LDFLAGS or CPPFLAGS, not sure what to think of that... it's possible to export CFLAGS="$CPPFLAGS $CFLAGS $LDFLAGS" before building I guess?
It does have LIBFLAG which I believe should be contain LDFLAGS. See https://github.com/luarocks/luarocks/issues/429
- We don't know why the argument on using pkg-config in LUA should be
dismissed. [3]
This is relevant, I believe, given that daurnimator appears to be a member of both the lua and luarocks organizations on github, and presumably has some degree of influence.
Note that I am only a reviewer/maintainer for both orgs, I do not control any decision making processes. I can, of course, suggest things, but so can everyone else!
And I do sort of think that pushing things like this to upstream attention is kind of important from a packaging perspective. If I were a lua user rather than an idle bystander who happened to notice something odd being discussed, I would definitely be aggressively advocating for this upstream.
Lua has a very diverse set of users, including those that - refuse to use anything more modern than C89 - are game developers - use windows - are using lua on a microcontroller - refuse to be in the same room as autotools - say that libtool is the only way to package libraries - refuse to be in the same room as libtool - are super performance sensitive Trying to solve packaging and ecosystem issues is very difficult in such an environment.
By being a trusted user I hope that it adds substance behind some upstream reform, where the response has sometimes been "we will only change this if a majority of distros agree".
Considering the questions are relevant regarding the use of bare gcc lines (!) in PKGBUILDs a candidate may want to add to [community], I'd say it's especially important to answer them.
It's especially important to answer them given that the candidate's application stated "the primary goal of improving Arch's Lua packages", but so far we have not been told what that means and can only guess based on what others have observed of his PKGBUILDs.
Foxboron, you said your candidate reached out to some people people via email to discuss "the current state of our LUA packages where he wanted to help improve the situation". Was this discussed during that private email conversation?
Daurnimator, can you elaborate on your plans?
I don't have a full answer for this yet! It's not as if I intend to go in and change everything on the first day I'm a TU. Problems need to be proposed, existing solutions need to be investigated, and I'll try to come to agreement with other distro maintainers, as well as other arch TUs.
On 12/16/18 11:27 PM, Daurnimator wrote:
It does have LIBFLAG which I believe should be contain LDFLAGS. See https://github.com/luarocks/luarocks/issues/429
I don't know what this means. Does it or doesn't it? Shall I assume that its being open for several years with no activity at all means tht it does *not* respect LDFLAGS without overloading them into CFLAGS, and that there's no intention to ever change this?
This is relevant, I believe, given that daurnimator appears to be a member of both the lua and luarocks organizations on github, and presumably has some degree of influence.
Note that I am only a reviewer/maintainer for both orgs, I do not control any decision making processes. I can, of course, suggest things, but so can everyone else!
This strips the word of all meaning, but okay, apparently the organization in question means nothing. Got it.
And I do sort of think that pushing things like this to upstream attention is kind of important from a packaging perspective. If I were a lua user rather than an idle bystander who happened to notice something odd being discussed, I would definitely be aggressively advocating for this upstream.
Lua has a very diverse set of users, including those that
- refuse to use anything more modern than C89
- are game developers
- use windows
- are using lua on a microcontroller
- refuse to be in the same room as autotools
- say that libtool is the only way to package libraries
- refuse to be in the same room as libtool
- are super performance sensitive
Trying to solve packaging and ecosystem issues is very difficult in such an environment.
Autotools and libtool build systems traditionally don't handle pkg-config at all, except if autotools is the parent software executing the "sed" command on a pkg-config file. So I guess, oddly enough, everyone can agree on this!
I'm finding it very hard to imagine why c89, game developers, microcontroller users, or people who care about performance would be at all opposed to distributing an inert text file. I guess Windows users might feel like it is a waste, but it's still hardly controversial.
Can you clarify what any of this has to do with anything? Why would anyone feel hurt by this? How does this answer my observation that it's something to push upstream?
By being a trusted user I hope that it adds substance behind some upstream reform, where the response has sometimes been "we will only change this if a majority of distros agree".
I'm sure that, Trusted User or not, you can point to any number of cross-distro policies to agree to. And you hardly need to be a Trusted User to write good lua packaging documentation and point to how wonderful having standard pkg-config files are.
I'm afraid I simply don't see how this has any bearing on anything. If the lua developers claim that a majority of distros fail to agree that pkg-config files describing the lua distribution are a good thing, then they're simply arguing for the sake of arguing, and no proofs will ever be enough for them.
I really, really hope this application is not *just* about being able to wave your credentials as a TU at the lua developers. But so far you've failed to specify what your other tangible goals are. :(
It's especially important to answer them given that the candidate's application stated "the primary goal of improving Arch's Lua packages", but so far we have not been told what that means and can only guess based on what others have observed of his PKGBUILDs.
Foxboron, you said your candidate reached out to some people people via email to discuss "the current state of our LUA packages where he wanted to help improve the situation". Was this discussed during that private email conversation?
Daurnimator, can you elaborate on your plans?
I don't have a full answer for this yet! It's not as if I intend to go in and change everything on the first day I'm a TU.
My takeaway from this is that you have not come into your application with any answer at all, and intend to begin work only after being elected. A pity, since PKGBUILD standards are a hobby of mine and I would have liked to take a look at something which is actually there to be looked at, at least as a beginning.
I guess the lack of an answer explains why your AUR packages lack the answer you say you applied as a TU in order to fix in [community].
Problems need to be proposed, existing solutions need to be investigated, and I'll try to come to agreement with other distro maintainers, as well as other arch TUs.
I literally don't even parse the paragraph. As far as I can tell we have lots of proposed problems, and no existing solutions at all. Am I totally misreading this and there is, in fact, some solution(s) to be discussing? Is there some hidden meaning in this paragraph I don't quite grok?
As far as coming to agreement with other distributions, distributions have never "agreed" on how to package upstream code. It's hardly agreeing if code in general comes with one method approved by upstream by which to build it -- it's just obeying upstream. As for agreeing with Arch TUs, I thought this whole application process was supposed to be about you having ideas due to the lack of significant knowledge or care by any existing TUs.
I just really want to understand what this all means here.
- You applied saying you are a knowledgeable lua person and wish to make the quality of lua within our official repositories, better.
- Now you're telling us you don't actually have any ideas but you hope that we do and you can agree with our ideas? Or that you have no ideas right now but if elected as a TU you will commit to having some?
...
When I first opened this application I was like "hey, cool, person wants to make lua PKGBUILDs better. Sounds fascinating, I wonder what his ideas are". Well, by the time I finally responded no ideas were forthcoming, but instead I'm getting lots of evasion and "If anyone would like to help out with this I'm all ears" and "Problems need to be proposed, existing solutions need to be investigated".
I'm a simple person, which is in part why I like Arch, because there's supposed to be this culture of just, like, getting things done. Something is wrong? Fix it. Come up with ideas and assert them, win people over by the practicality and usefulness of your suggestions. Especially when no one else has any opinions, so if you don't proactively fix it yourself it will never be fixed.
Go-getters are awesome.
This ceremonial desire to quintuple-check with I'm not even sure who anymore, while remaining utterly vague on your professed *primary goal*, is just making me confused and uninterested in this whole thread. I no longer believe in your OP.
On Mon, 17 Dec 2018 at 17:23, Eli Schwartz eschwartz@archlinux.org wrote:>
I'm finding it very hard to imagine why c89, game developers, microcontroller users, or people who care about performance would be at all opposed to distributing an inert text file. I guess Windows users might feel like it is a waste, but it's still hardly controversial.
Can you clarify what any of this has to do with anything? Why would anyone feel hurt by this? How does this answer my observation that it's something to push upstream?
It's a fight against a long standing effort to reduce the number of files in the release tarball. You would have seen e.g. http://lua-users.org/lists/lua-l/2008-09/msg00186.html in my earlier links
By being a trusted user I hope that it adds substance behind some upstream reform, where the response has sometimes been "we will only change this if a majority of distros agree".
I'm sure that, Trusted User or not, you can point to any number of cross-distro policies to agree to. And you hardly need to be a Trusted User to write good lua packaging documentation and point to how wonderful having standard pkg-config files are.
Previous efforts (not by myself) have failed because distro packagers have not enacted proposed changes. Lua community members have come up with suggestions and schemes, but unless they are implemented by a distro then they are forgotten. Across most distributions, lua maintainers seem to be absentee.
I'm afraid I simply don't see how this has any bearing on anything. If the lua developers claim that a majority of distros fail to agree that pkg-config files describing the lua distribution are a good thing, then they're simply arguing for the sake of arguing, and no proofs will ever be enough for them.
I really, really hope this application is not *just* about being able to wave your credentials as a TU at the lua developers. But so far you've failed to specify what your other tangible goals are. :(
As I stated in my application, I planned my initial tasks as maintaining - lua-expat - lua-filesystem - luajit - luarocks
luarocks in particular has been sitting out of date and unmaintained for a while https://github.com/luarocks/luarocks/issues/946 is what prompted me to resume my stalled TU application.
My takeaway from this is that you have not come into your application with any answer at all, and intend to begin work only after being elected. A pity, since PKGBUILD standards are a hobby of mine and I would have liked to take a look at something which is actually there to be looked at, at least as a beginning.
... snip ...
Go-getters are awesome.
The initial email mentioned was aiming to come to an agreement about version suffixes and paths for lua packages across distros (see the earlier linked spreadsheet for the inconsistencies https://docs.google.com/spreadsheets/d/1Z_oM8LgwyGAsfof6_FbbBJlY-wCA6DfadwZb... ) I would not be unable to immediately fix this as a TU because the lua package is in extra.
I was told that there were no TUs with much Lua experience, and that it would be nice to have a trusted user to review Lua changes/packages with knowledge and care of the Lua community. This would reduce the phenomenon of the "Absentee business owner"
On 17/12/2018 07.53, Daurnimator wrote:
I was told that there were no TUs with much Lua experience, and that it would be nice to have a trusted user to review Lua changes/packages with knowledge and care of the Lua community. This would reduce the phenomenon of the "Absentee business owner"
And I stand by my opinion. It's ridiculous to think that one person, even if member of GitHub organization (which may or may not mean anything), can single-handedly affect decision of either project. It's difficult even here at Arch, and we are one of smaller teams.
I fail to understand how discussion got where it is now. Is sponsorship process about packaging quality and candidate in general or pushing some agenda through projects that applicant is helping with?
Bartłomiej
On 17/12/2018 08.23, Bartłomiej Piotrowski via aur-general wrote:
can single-handedly affect decision of either project
s/either/entire/
I haven't had my coffee yet.
Em dezembro 17, 2018 5:23 Bartłomiej Piotrowski via aur-general escreveu:
I fail to understand how discussion got where it is now. Is sponsorship process about packaging quality and candidate in general or pushing some agenda through projects that applicant is helping with?
I don't believe I have to say this, but we should probably write somewhere how the applicant will be evaluated. Because asking the applicant about something they don't really have control over is ridiculous, to say the least.
I know we have this [0], but it is not enough. Are we going to start asking applicants questions not related to packaging and arch? Then at least lets make sure they can prepare for it. Or, preferably, can we please focus on packaging?
Regards, Giancarlo Razzolini
[0] https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU?
On 12/17/18 1:23 AM, Bartłomiej Piotrowski via aur-general wrote:
And I stand by my opinion. It's ridiculous to think that one person, even if member of GitHub organization (which may or may not mean anything), can single-handedly affect decision of either project. It's difficult even here at Arch, and we are one of smaller teams.
While I agree that this is a completely valid opinion regarding large packaging jobs like GNOME and so forth, Lua and Lua libs are hardly that. Not to discount the Lua developers that exist within the Arch community, but it's unlikely that a decision to change such packages would impact nearly as many people as some of our other package sets, nor should it require as large of a consensus among the developers/TUs to make such changes. Upstream input into the packaging process *is* useful, provided it doesn't suggest throwing all semblance of standardization out the window.
What this means for the application, I'm not sure. If this is (as a few others have mentioned) an attempt to join the team as a means to gain political sway upstream, then I think we can all agree that the answer here is pretty straightforward. If we step back and give the applicant the benefit of the doubt however, then all I see is a well-informed and well-intentioned Lua user who could do great things for our package ecosystem—not acting as a lone wolf, but as a member of a greater team.
Brad
Yo!
The vote is over and the results are inn!
Yes: 22 No: 15 Abstain: 12 Participation: 89.09%
Congratulations! I have updated the AUR account.
Please follow the TODO and poke me with any questions you have :)
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f...
On Fri, 21 Dec 2018 at 21:03, Morten Linderud via aur-general aur-general@archlinux.org wrote:
Yo!
The vote is over and the results are inn!
Yes: 22 No: 15 Abstain: 12 Participation: 89.09%
Congratulations! I have updated the AUR account.
Please follow the TODO and poke me with any questions you have :)
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f...
-- Morten Linderud PGP: 9C02FF419FECBE16
Thankyou all!
On 12/21/18 5:03 AM, Morten Linderud via aur-general wrote:
Yo!
The vote is over and the results are inn!
Yes: 22 No: 15 Abstain: 12 Participation: 89.09%
Congratulations! I have updated the AUR account.
Please follow the TODO and poke me with any questions you have :)
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f...
Congratulations, Daurnimator, and don't let my doubts stop you from doing cool things. :)
Your keyring task is now open on the bugtracker, and I've upgraded your account to Trusted User and Member statuses in the Community and Keyring projects, respectively.
On 11/29/18 at 02:03am, Daurnimator wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi all,
I'm applying to be a Trusted User; Foxboron has kindly sponsored me and has been mentoring me on the specifics over the last couple of months.
I've been using Arch since 2010, having been present in #archlinux almost the whole time! Before that I was a Xubuntu user from approximately 2005. Before that I had flirted with Linux a few times, I think my first exploration of Linux was of Lindows back in 2001.
With my programming hat on, I mainly use C and Lua, I'm quite heavily involved in the Lua community. I would like to become a trusted user with the primary goal of improving Arch's Lua packages.
With my sysadmin hat on, I'm an admin at hashbang.sh, an online hackerspace/incubator. Amoung other services, we run public shell servers with a fully open configuration. At $DAYJOB roles I've been responsible for packaging and deployment on various Linuxes.
With my networking hat on, I maintain a few nodes in Melbourne Wireless, a city-wide wireless network. This has taught me quite a lot about networking hardware and given me the chance to play with routing protocols. I also joined dn42 which is for lack of a better explanation "an internet of VPN tunnels".
If accepted as a TU, I'd like to (co)maintain:
- lua-expat
- lua-filesystem
- luajit
- luarocks
Other packages I'd be happy to co-maintain are:
- awesome
- jq
- keepassxc
- love
- lua51-bitop
- pcsclite
- prosody
- rlwrap
- tig
What's your AUR account?
aur-general@lists.archlinux.org