[aur-general] [tu-bylaws] [PATCH] add README describing how to update the bylaws
Signed-off-by: Eli Schwartz
---
This is not an amendment to the bylaws themselves, and as such does not
require any sort of vote. But I think this is rather useful to have, as
there is currently not a case of perfect clarity for the administrivium
involved in processing updates. As development of the bylaws happens on
this list, I'm sending it in here. Hope this change makes sense to all.
README.md | 12
1 file changed, 12 insertions(+)
create mode 100644 README.md
diff --git a/README.md b/README.md
new file mode 100644
index 000..262a22c
--- /dev/null
+++ b/README.md
@@ -0,0 +1,12 @@
+# AUR Trusted User Bylaws
+
+This document describes the bylaws which govern the Arch Linux Trusted Users.
+
+Instructions for updating:
+
+- follow the procedure outlined in the bylaws for proposing an update
+- if accepted, push to master branch of this repository and tag the commit
+ "proposal-$num" to correspond with the vote ID at
+ https://aur.archlinux.org/tu/
+- ask one of the aurweb maintainers to run `make` and deploy the resulting
+ `*.html` to `${aurweb_root}/web/html/trusted-user/`
--
2.20.1
Re: [aur-general] What happened to wine-gaming-nine?
On 1/23/19 12:37 AM, Alex Smith via aur-general wrote: > I am curious as to what happened to the AUR package named "wine-gaming- > nine". Did the account behind it get banned? Or was it simply deleted > because it was out of date. > multilib/wine-staging-nine happened -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: OpenPGP digital signature
[aur-general] What happened to wine-gaming-nine?
I am curious as to what happened to the AUR package named "wine-gaming- nine". Did the account behind it get banned? Or was it simply deleted because it was out of date.
Re: [aur-general] [PATCH][tu-bylaws]: raise threshold of sponsors to two
On 1/21/19 8:09 PM, Santiago Torres-Arias via aur-general wrote: > Helloe everyone, > > It's been a week and the result are in: > > Yes:34 > No : 7 > Abstain: 6 > Total :47 > > with a participation 83.93%, the vote to raise the number of TU sponsors > to two has passed. > > Thanks to everyone for voting! > -Santiago Cool, it's official. *puts on aurweb hat* Will deploy ASAP. > On Mon, Jan 14, 2019 at 12:37:38PM -0500, Santiago Torres-Arias via > aur-general wrote: >> Hi, >> >> Sorry I just realized that we're overdue on the vote for this as the >> discussion period is only 5 days. >> >> Let the votes begin! >> -Santiago. >> >> >> On Mon, Jan 07, 2019 at 09:23:12PM -0500, Santiago Torres wrote: >>> The current threshold of applicants has raised some concerns with the TU >>> community regarding the quality of the applications submitted. In order >>> to improve this, increase the threshold of TU sponsors with the >>> following goals: >>> >>> - Have two TUs review the applicants PKBUILDs >>> - Have two TUs actually decide to support this canididate >>> --- >>> tu-bylaws.txt | 13 - >>> 1 file changed, 8 insertions(+), 5 deletions(-) >>> >>> diff --git a/tu-bylaws.txt b/tu-bylaws.txt >>> index d32e06c..e958393 100644 >>> --- a/tu-bylaws.txt >>> +++ b/tu-bylaws.txt >>> @@ -100,11 +100,13 @@ Addition of a TU >>> >>> The addition of a TU may occur at any time. >>> >>> -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 14 days, a quorum of 66%, and a voting period of 7 >>> days. >>> +In order to become a TU, one must first find two sponsoring TUs following >>> the >>> +guidelines outlined below, 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 14 days, a quorum of 66%, and a voting period >>> of 7 >>> +days. >>> >>> >>> SVP( addition_of_TU, 14, 0.66, 7 ); >>> @@ -113,6 +115,7 @@ SVP( addition_of_TU, 14, 0.66, 7 ); >>> If a candidate is rejected by SVP, they may not reapply to become a Trusted >>> User for a period of three months. >>> >>> + >>> Removal of a TU Just going to remove this completely uncontroversial whitespace formatting issue first. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On 23/1/19 12:11 am, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 16:10: On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight. That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used. If the Environment variable is actually the problem, why not just unset them before proceeding? unset GEM_HOME unset BUNDLE_PATH `$(gem env gemdir)` Thanks Macca
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Levente Polyak via aur-general schreef op 2019-01-22 16:10: On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight. That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: >Levente Polyak via aur-general schreef op 2019-01-22 13:40: >> On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general >> wrote: >>> David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: > On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: > Why is use > `$(gem env gemdir)` > > Instead of > > `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. >>> >>> I'm not a TU so take my this with a grain of salt, but I don't think >>> this is the best advice. >>> >>> It's shorter, admittedly, but `gem` spawns a ruby process just as >the >>> `ruby` version does. Using gem doesn't work however when `$GEM_HOME` > >>> is >>> >>> set, since then it reports the contents of that variable. >>> >>> Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` > >>> is >>> >>> more convenient since most users do not build in a clean chroot, and >>> the >>> wiki actually recommends settings that environment variable so quite >a >>> few will have it. >>> >>> Best, >>> >>> Bert Peters. >> >> Which seems silly and the whole section should be removed in the >first >> place. >> Thats what --user-install switch should be for and that should be >> default via /etc/gemrc >> Therefor setting that is just useless fiddling with the system and >> your gems will be searched there as well as it's default gem path >> besides /usr/lib. > >While `gem` obeys that default, `bundle` (ruby-bundler) does not, and >does not >have that default, opting for a global install by default. You can >override >this by manually adding `--path=~/.gem` to every invocation. That's >hardly an >elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: >David Runge schreef op 2019-01-22 12:30: >> On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: >>> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: >>> Why is use >>> `$(gem env gemdir)` >>> >>> Instead of >>> >>> `$(ruby -e'puts Gem.default_dir')` >> It's shorter and you don't have to spawn a ruby process to print >> something, if you can use the gem command directly. > >I'm not a TU so take my this with a grain of salt, but I don't think >this is the best advice. > >It's shorter, admittedly, but `gem` spawns a ruby process just as the >`ruby` version does. Using gem doesn't work however when `$GEM_HOME` is > >set, since then it reports the contents of that variable. > >Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is > >more convenient since most users do not build in a clean chroot, and >the >wiki actually recommends settings that environment variable so quite a >few will have it. > >Best, > >Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
> > * pkgname: avoid composition
> What should I do?
It's more readable and less error-prone to do `pkgname=name` instead of
`pkgname="name${something_else}"`.
> Why is use
> `$(gem env gemdir)`
>
> Instead of
>
> `$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print
something, if you can use the gem command directly.
> > LICENSE.md can be installed using 'install -t'
>
> Why is use
> `install -t`
The upside is, that you can ommit the specific destination (unless you
want to rename the destination file).
e.g. `install -vDm 644 LICENSE -t
"${pkgdir}/usr/share/licenses/${pkgname}/"` creates the directory
"${pkgdir}/usr/share/licenses/${pkgname}/" for you, if it doesn't exist
and will install the source file to that directory, without you having
to specifically name the destination file.
Whereas the following requires you to specify the destination file as
well: `install -vDm 644 LICENSE
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
Not using the `-t` flag is only useful, if you need to rename the
destination file, e.g.:
`install -vDm 644 WEIRDNAME_FOR_A_LICENSE
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
In short: This is shorter and implies the creation of the destination
directory.
Closing: Please use a mail client, that doesn't break threads (i.e.
replies to the thread that was initially created, instead of creating a
new one.
Mailman is somewhat able to order these threads in the list archive, but
in mail clients this is horrible to follow up on (there are now 4
separate threads [1] [2] [3] [4]). Compare the 'In-Reply-To' header in
the messages with those of others.
Aside from that, happy packaging! :)
David
[1] https://lists.archlinux.org/pipermail/aur-general/2018-December/034744.html
[2] https://lists.archlinux.org/pipermail/aur-general/2018-December/034758.html
[3] https://lists.archlinux.org/pipermail/aur-general/2019-January/034799.html
[4] https://lists.archlinux.org/pipermail/aur-general/2019-January/034848.html
--
https://sleepmap.de
signature.asc
Description: PGP signature
Re: [aur-general] Purge of packages orphaned, out-of-date, and last updated before 2017
On 22/1/19 2:18 pm, hagar wrote: On 22/1/19 1:16 pm, Daniel M. Capella via aur-general wrote: Based on the loosely defined "cleanup criteria"[], we're overdue for a little purge. The candidates can be found here: https://aur.archlinux.org/packages/?O=0=nd==on=l=a=250_Orphans=Orphans https://aur.archlinux.org/packages/?O=250=nd=on=l=a=250_Orphans=Orphans Please run `aurphan -a` to see if you have any orphaned AUR packages installed, and do everyone a favor by adopting them. If there are no objections, it will be done this weekend. A reply will be sent for record-keeping with the list of packages prior to deletion. []: https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day#Possible_reasons -- Best, polyzen I'm not sure if I did something wrong? I adopted mingw-w64-freeimage (My first one) I cloned the git and followed the instructions to edit and commit the updated PKGBUILD. All appeared good. Then I realized that I needed to delete the gcc5.patch. When I tried to commit that change al I got was a 403 error? Did I do something wrong or is the package on hold until checked bu a TU? Thanks Macca Sorry, Never mind. My instructions missed the step to edit the .git/config and change the url. Thanks Macca
[aur-general] TU application_R: Metal A-wing (a-wing)
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: > * ruby-websockets-extensions > * pkgname: avoid composition What should I do? > * arch: single quotes missing > * url: use double quotes > * license: single quotes missing > * depends: single quotes missing > * makedepends: single quotes missing > * package(): _gemdir can be derived from $(gem env gemdir), Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` > LICENSE.md can be installed using 'install -t' Why is use `install -t` Instead of `install -D` ``` install --help -D create all leading components of DEST except the last, or all components of --target-directory, then copy SOURCE to DEST -t, --target-directory=DIRECTORY copy all SOURCE arguments into DIRECTORY ``` signature.asc Description: PGP signature
