Re: [arch-projects] [arch-ports] [devtools] Rebasing devtools32 to contribute upstream
Hi Luke, yeah, sure, we/I can switch to a rebasing workflow. Thanks for the suggestion. In retrospect, I have no Idea anymore, why I started with a merging workflow :-/ Cheers, Erich On 15.01.2018 18:24, Luke Shumaker wrote: > Hi all, > > As the maintainer of Parabola's devtools, I know that with a merging > workflow, it can be a huge pain to rebase out changes to have patchset > that you can contribute upstream. > > If any of the Arch Linux 32 team ever decide that you want to > contribute changes from devtools32 into upstream devtools, I expect > that you will find the "lukeshu/rebase/archlinux32" branch of > https://git.parabola.nu/packages/devtools-par.git/ to be useful. It > is simply devtools32's "master" branch, rebased so that it looks like > it used a rebasing workflow instead of a merging workflow. > > I'll generally keep it up-to-date as I keep an eye out for anything > that I might want to backport into Parabola. (And indeed, there's > already one such change > https://lists.archlinux.org/pipermail/arch-projects/2018-January/004704.html ) > signature.asc Description: OpenPGP digital signature
[arch-projects] [archweb] Origin of konami.js
Hi Dan, I'm sorry to bother you. In archweb commit bec4e79 (2013-02-09), you added `sitestatic/konami.min.js`. It is apparently https://github.com/snaptortoise/konami-js commit ec0f686 run through UglifyJS 2.2, but with a few modifications (below) made first. Would it be correct to assume that you are the author of those modifications? If so, would you consent to re-licensing the modifications to be under the MIT license; reflecting the upstream license change in konami-js?? --- diff a/konami.js b/konami.js --- a/konami.js +++ b/konami.js @@ -56,7 +56,7 @@ load: function(link){ this.orig_keys = this.keys; konami.addEvent(document,"touchmove",function(e){ - if(e.touches.length == 1 && konami.iphone.capture==true){ + if(e.touches.length == 1 && konami.iphone.capture===true){ var touch = e.touches[0]; konami.iphone.stop_x = touch.pageX; konami.iphone.stop_y = touch.pageY; @@ -66,7 +66,7 @@ } }); konami.addEvent(document,"touchend",function(evt){ - if (konami.iphone.tap==true) konami.iphone.check_direction(link); + if (konami.iphone.tap===true) konami.iphone.check_direction(link); },false); konami.addEvent(document,"touchstart", function(evt){ konami.iphone.start_x = evt.changedTouches[0].pageX @@ -76,12 +76,12 @@ }); }, check_direction: function(link){ - x_magnitude = Math.abs(this.start_x-this.stop_x) - y_magnitude = Math.abs(this.start_y-this.stop_y) - x = ((this.start_x-this.stop_x) < 0) ? "RIGHT" : "LEFT"; - y = ((this.start_y-this.stop_y) < 0) ? "DOWN" : "UP"; - result = (x_magnitude > y_magnitude) ? x : y; - result = (this.tap==true) ? "TAP" : result; + var x_magnitude = Math.abs(this.start_x-this.stop_x) + var y_magnitude = Math.abs(this.start_y-this.stop_y) + var x = ((this.start_x-this.stop_x) < 0) ? "RIGHT" : "LEFT"; + var y = ((this.start_y-this.stop_y) < 0) ? "DOWN" : "UP"; + var result = (x_magnitude > y_magnitude) ? x : y; + result = (this.tap===true) ? "TAP" : result; if (result==this.keys[0]) this.keys = this.keys.slice(1,this.keys.length) if (this.keys.length==0) { -- Happy hacking, ~ Luke Shumaker
Re: [arch-projects] [devtools] [PATCH 5/7] lib/common.sh: Adjust to work properly with `set -u`
On Mon, 15 Jan 2018 12:25:22 -0500, Eli Schwartz via arch-projects wrote: > > [1 Re: [arch-projects] [devtools] [PATCH 5/7] lib/common.sh: Adjust to work > properly with `set -u` ] > [1.1 ] > On 01/15/2018 11:57 AM, Luke Shumaker wrote: > > From: Luke Shumaker > > > libmakepkg does not work with `set -u`; but mostly because of the include > > guards! So we just need to temporarily disable `set -u` (nounset) while > > loading libmakepkg. Instead of introducing a new variable, just store the > > initial nounset status in _INCLUDE_COMMON_SH; rather than a useless > > fixed-string "true". > > Would it make sense to fix this in libmakepkg instead? devtools are not > the only project that would reuse libmakepkg components. Also, working > towards having makepkg be able to use set -u could be interesting. Long-term: It absolutely would make sense. But libmakepkg has a lot slower release schedule than devtools/libretools, and I needed to get a release out :) libretools has a few consumers of common.sh that `set -u`; the switch to libmakepkg would have broken them otherwise. -- Happy hacking, ~ Luke Shumaker
Re: [arch-projects] [devtools] [PATCH 3/7] arch-nspawn: make sure that makepkg.conf is always parsed as text
On Mon, 15 Jan 2018 12:11:29 -0500, Eli Schwartz wrote: > > On 01/15/2018 11:57 AM, Luke Shumaker wrote: > > From: Luke Shumaker > > > > https://lists.parabola.nu/pipermail/dev/2017-June/005576.html > > --- > > arch-nspawn.in | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch-nspawn.in b/arch-nspawn.in > > index c55f498..3949ee1 100644 > > --- a/arch-nspawn.in > > +++ b/arch-nspawn.in > > @@ -107,7 +107,7 @@ fi > > build_mount_args > > copy_hostconf > > > > -eval "$(grep '^CARCH=' "$working_dir/etc/makepkg.conf")" > > +eval "$(grep -a '^CARCH=' "$working_dir/etc/makepkg.conf")" > > > > [[ -z $nosetarch ]] || unset CARCH > > I'm curious, in what situation were you having grep parse makepkg.conf > as not text? Some unicode in a comment near the top was tripping it up (this was on the box of a Spanish-speaking developer). > I also wonder whether we should source makepkg.conf in a subshell and > printf the relevant variables... I have no problem with that. -- Happy hacking, ~ Luke Shumaker
[arch-projects] [devtools] [PATCH] makechrootpkg: Do not copy the user keyring into the chroot.
Since commit 75fdff1811a0487f82c75b2e260da905102b4eea we no longer run integrity checks inside the chroot anyway, so this is no longer needed and will never be used. Signed-off-by: Eli Schwartz --- makechrootpkg.in | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/makechrootpkg.in b/makechrootpkg.in index 511e519..9c79171 100644 --- a/makechrootpkg.in +++ b/makechrootpkg.in @@ -180,12 +180,7 @@ prepare_chroot() { printf >>"$copydir/etc/group" 'builduser:x:%d:\n' "$builduser_gid" printf >>"$copydir/etc/passwd" 'builduser:x:%d:%d:builduser:/build:/bin/bash\n' "$builduser_uid" "$builduser_gid" - $install -d "$copydir"/{build,build/.gnupg,startdir,{pkg,srcpkg,src,log}dest} - - for x in .gnupg/pubring.{kbx,gpg}; do - [[ -r $USER_HOME/$x ]] || continue - $install -m 644 "$USER_HOME/$x" "$copydir/build/$x" - done + $install -d "$copydir"/{build,startdir,{pkg,srcpkg,src,log}dest} sed -e '/^MAKEFLAGS=/d' -e '/^PACKAGER=/d' -i "$copydir/etc/makepkg.conf" for x in BUILDDIR=/build PKGDEST=/pkgdest SRCPKGDEST=/srcpkgdest SRCDEST=/srcdest LOGDEST=/logdest \ -- 2.15.1
Re: [arch-projects] [devtools] [PATCH 7/7] makechrootpkg: Put "keyserver-options auto-key-retrieve" in gpg.conf
On 01/15/2018 11:57 AM, Luke Shumaker wrote: > From: Luke Shumaker > > This allows signature verification by `makepkg --verifysource`, `git > verify-tag`, and such without requiring the user to manually retrieve > the keys first. > > This is based off of devtools32 commit 009695b (2017-06-27) by > Erich Eckner . There are 2 differences from that > commit: > - In this version, gpg.conf is owned by builduser, not by root > - In this version, we don't keep appending duplicate lines if we >re-use a chroot We use --skipinteg inside the chroot anyway, since 75fdff1811a0487f82c75b2e260da905102b4eea -- but this reminds me I need to submit my patch to disable copying of the keyring altogether. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-projects] [devtools] Rebasing devtools32 to contribute upstream
Hi all, As the maintainer of Parabola's devtools, I know that with a merging workflow, it can be a huge pain to rebase out changes to have patchset that you can contribute upstream. If any of the Arch Linux 32 team ever decide that you want to contribute changes from devtools32 into upstream devtools, I expect that you will find the "lukeshu/rebase/archlinux32" branch of https://git.parabola.nu/packages/devtools-par.git/ to be useful. It is simply devtools32's "master" branch, rebased so that it looks like it used a rebasing workflow instead of a merging workflow. I'll generally keep it up-to-date as I keep an eye out for anything that I might want to backport into Parabola. (And indeed, there's already one such change https://lists.archlinux.org/pipermail/arch-projects/2018-January/004704.html ) -- Happy hacking, ~ Luke Shumaker
Re: [arch-projects] [devtools] [PATCH 5/7] lib/common.sh: Adjust to work properly with `set -u`
On 01/15/2018 11:57 AM, Luke Shumaker wrote: > From: Luke Shumaker > libmakepkg does not work with `set -u`; but mostly because of the include > guards! So we just need to temporarily disable `set -u` (nounset) while > loading libmakepkg. Instead of introducing a new variable, just store the > initial nounset status in _INCLUDE_COMMON_SH; rather than a useless > fixed-string "true". Would it make sense to fix this in libmakepkg instead? devtools are not the only project that would reuse libmakepkg components. Also, working towards having makepkg be able to use set -u could be interesting. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-projects] [devtools] [PATCH 3/7] arch-nspawn: make sure that makepkg.conf is always parsed as text
On 01/15/2018 11:57 AM, Luke Shumaker wrote: > From: Luke Shumaker > > https://lists.parabola.nu/pipermail/dev/2017-June/005576.html > --- > arch-nspawn.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch-nspawn.in b/arch-nspawn.in > index c55f498..3949ee1 100644 > --- a/arch-nspawn.in > +++ b/arch-nspawn.in > @@ -107,7 +107,7 @@ fi > build_mount_args > copy_hostconf > > -eval "$(grep '^CARCH=' "$working_dir/etc/makepkg.conf")" > +eval "$(grep -a '^CARCH=' "$working_dir/etc/makepkg.conf")" > > [[ -z $nosetarch ]] || unset CARCH I'm curious, in what situation were you having grep parse makepkg.conf as not text? I also wonder whether we should source makepkg.conf in a subshell and printf the relevant variables... -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-projects] [devtools] [PATCH 5/7] lib/common.sh: Adjust to work properly with `set -u`
From: Luke Shumaker Support for working with `set -u` was broken by 94160d6. Egg on my face; I'm the one who wants `set -u` support, and I'm the author of that commit! libmakepkg does not work with `set -u`; but mostly because of the include guards! So we just need to temporarily disable `set -u` (nounset) while loading libmakepkg. Instead of introducing a new variable, just store the initial nounset status in _INCLUDE_COMMON_SH; rather than a useless fixed-string "true". While we're at it, disable POSIX-mode (just in case we're running as "sh" instead of "bash"), since libmakepkg uses bash-isms that won't parse in POSIX mode. --- lib/common.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/common.sh b/lib/common.sh index a3c2ec2..821f8df 100644 --- a/lib/common.sh +++ b/lib/common.sh @@ -4,10 +4,12 @@ # License: Unspecified [[ -z ${_INCLUDE_COMMON_SH:-} ]] || return 0 -_INCLUDE_COMMON_SH=true +_INCLUDE_COMMON_SH="$(set +o|grep nounset)" +set +u +o posix # shellcheck disable=1091 . /usr/share/makepkg/util.sh +$_INCLUDE_COMMON_SH # Avoid any encoding problems export LANG=C -- 2.15.1
[arch-projects] [devtools] [PATCH 7/7] makechrootpkg: Put "keyserver-options auto-key-retrieve" in gpg.conf
From: Luke Shumaker This allows signature verification by `makepkg --verifysource`, `git verify-tag`, and such without requiring the user to manually retrieve the keys first. This is based off of devtools32 commit 009695b (2017-06-27) by Erich Eckner . There are 2 differences from that commit: - In this version, gpg.conf is owned by builduser, not by root - In this version, we don't keep appending duplicate lines if we re-use a chroot --- makechrootpkg.in | 1 + 1 file changed, 1 insertion(+) diff --git a/makechrootpkg.in b/makechrootpkg.in index a6c54cc..d2a0477 100644 --- a/makechrootpkg.in +++ b/makechrootpkg.in @@ -186,6 +186,7 @@ prepare_chroot() { [[ -r $USER_HOME/$x ]] || continue $install -m 644 "$USER_HOME/$x" "$copydir/build/$x" done + $install -m644 /dev/stdin "$copydir/build/.gnupg/gpg.conf" <<<'keyserver-options auto-key-retrieve' sed -e '/^MAKEFLAGS=/d' -e '/^PACKAGER=/d' -i "$copydir/etc/makepkg.conf" for x in BUILDDIR=/build PKGDEST=/pkgdest SRCPKGDEST=/srcpkgdest SRCDEST=/srcdest LOGDEST=/logdest \ -- 2.15.1
[arch-projects] [devtools] [PATCH 2/7] makechrootpkg: Fix anti-pattern when checking for enabled features
From: Eli Schwartz Don't use error-prone logic e.g. foo=true; if $foo ... This completely fails to act as expected when the variable is unset because of unrelated bugs. While this merely causes the default behavior to be "false" rather than "true" in such cases, it is better to fail to enable explicitly requested behavior (which will be noticed by the user) than to simply upgrade to this behavior for free (which may not seem to have any obvious cause). Signed-off-by: Eli Schwartz Reviewed-by: Luke Shumaker --- makechrootpkg.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/makechrootpkg.in b/makechrootpkg.in index 02c91bc..c7fe076 100644 --- a/makechrootpkg.in +++ b/makechrootpkg.in @@ -165,7 +165,7 @@ prepare_chroot() { local keepbuilddir=$3 local run_namcap=$4 - $keepbuilddir || rm -rf "$copydir/build" + [[ $keepbuilddir = true ]] || rm -rf "$copydir/build" local builduser_uid builduser_gid builduser_uid="${SUDO_UID:-$UID}" @@ -208,7 +208,7 @@ EOF declare -p SOURCE_DATE_EPOCH 2>/dev/null printf '_chrootbuild "$@" || exit\n' - if $run_namcap; then + if [[ $run_namcap = true ]]; then declare -f _chrootnamcap printf '_chrootnamcap || exit\n' fi -- 2.15.1
[arch-projects] [devtools] [PATCH 1/7] makechrootpkg: Fix unconditionally running namcap
From: Eli Schwartz Fixes regression in 2fd5931a8c67289a8a4acd327b3ce99a5d64c8c7 $run_namcap will always be set to "" `if $not_a_var; then ...; fi` is always truthful when $not_a_var is unset or equal to "" and the `then` clause will always be run. I'm not sure why global state variables need to be cloned locally for their sole explicit purpose. But for now this patch implements the minimum necessary work to properly pass the "do I want namcap" variable into prepare_chroot() according to the current logic flow. Note that I have still not thorougly tested makechrootpkg. Signed-off-by: Eli Schwartz Reviewed-by: Luke Shumaker --- makechrootpkg.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/makechrootpkg.in b/makechrootpkg.in index 511e519..02c91bc 100644 --- a/makechrootpkg.in +++ b/makechrootpkg.in @@ -409,7 +409,7 @@ main() { download_sources "$copydir" "$makepkg_user" - prepare_chroot "$copydir" "$USER_HOME" "$keepbuilddir" + prepare_chroot "$copydir" "$USER_HOME" "$keepbuilddir" "$run_namcap" if arch-nspawn "$copydir" \ --bind="$PWD:/startdir" \ -- 2.15.1
[arch-projects] [devtools] [PATCH 4/7] arch-nspawn: Remove pointless $(echo ...) subshell
From: Luke Shumaker --- arch-nspawn.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch-nspawn.in b/arch-nspawn.in index 3949ee1..7a7a274 100644 --- a/arch-nspawn.in +++ b/arch-nspawn.in @@ -91,7 +91,7 @@ copy_hostconf () { cp -T "$file" "$working_dir$file" done - sed -r "s|^#?\\s*CacheDir.+|CacheDir = $(echo -n "${cache_dirs[@]}")|g" -i "$working_dir/etc/pacman.conf" + sed -r "s|^#?\\s*CacheDir.+|CacheDir = ${cache_dirs[*]}|g" -i "$working_dir/etc/pacman.conf" } # }}} -- 2.15.1
[arch-projects] [devtools] [PATCH 0/7] Backports from Parabola v20180103
From: Luke Shumaker These are the commits in Parabola's developer tools v20180103 that are not in upstream devtools that I think are upstreamable. There's no real theme to them. Some of theme have been seen on this mailing list before. (I appologize that I waited 2 weeks to send this; I didn't send it right away, then I forgot.) Eli Schwartz (2): makechrootpkg: Fix unconditionally running namcap makechrootpkg: Fix anti-pattern when checking for enabled features Luke Shumaker (5): arch-nspawn: make sure that makepkg.conf is always parsed as text arch-nspawn: Remove pointless $(echo ...) subshell lib/common.sh: Adjust to work properly with `set -u` makechrootpkg: Adjust to work properly with `set -e` makechrootpkg: Put "keyserver-options auto-key-retrieve" in gpg.conf arch-nspawn.in | 4 ++-- lib/common.sh| 4 +++- makechrootpkg.in | 9 + 3 files changed, 10 insertions(+), 7 deletions(-) -- Happy hacking, ~ Luke Shumaker
[arch-projects] [devtools] [PATCH 3/7] arch-nspawn: make sure that makepkg.conf is always parsed as text
From: Luke Shumaker https://lists.parabola.nu/pipermail/dev/2017-June/005576.html --- arch-nspawn.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch-nspawn.in b/arch-nspawn.in index c55f498..3949ee1 100644 --- a/arch-nspawn.in +++ b/arch-nspawn.in @@ -107,7 +107,7 @@ fi build_mount_args copy_hostconf -eval "$(grep '^CARCH=' "$working_dir/etc/makepkg.conf")" +eval "$(grep -a '^CARCH=' "$working_dir/etc/makepkg.conf")" [[ -z $nosetarch ]] || unset CARCH -- 2.15.1
[arch-projects] [devtools] [PATCH 6/7] makechrootpkg: Adjust to work properly with `set -e`
From: Luke Shumaker This worked properly until eab5aba. --- makechrootpkg.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/makechrootpkg.in b/makechrootpkg.in index c7fe076..a6c54cc 100644 --- a/makechrootpkg.in +++ b/makechrootpkg.in @@ -205,7 +205,7 @@ EOF { printf '#!/bin/bash\n' declare -f _chrootbuild - declare -p SOURCE_DATE_EPOCH 2>/dev/null + declare -p SOURCE_DATE_EPOCH 2>/dev/null || true printf '_chrootbuild "$@" || exit\n' if [[ $run_namcap = true ]]; then -- 2.15.1
Re: [arch-projects] [archweb] Licensing issues with JS code
On 01/14/18 at 08:34pm, Luke Shumaker wrote: > On Sun, 16 Jul 2017 23:46:01 -0400, > Andrew Gregory via arch-projects wrote: > > > > On 07/09/17 at 11:21am, Jelle van der Waa wrote: > > > Looking at the issue on the bugtracker, I'm not sure what you want to > > > achieve? personally I don't see any point in upgrading to GPLv3. > > > > Presumably, the main thing they want to achieve license compliance. > > GPLv2 is not compatible with GPLv3 or Apache 2.0. If archweb includes > > components under those licenses, it may be in violation. > > Indeed. We believe that archweb is in violation. > > In the linked bug, I commented off-the-cuff that I didn't believe that > the 1st-party GPLv2 code interacted with the 3rd-party GPLv3 or Apache > 2.0 code in a way that required license compatibility. > > Upon further review of release_2017-01-02 (the last release that > Parabola has merged, and thus the last that I am familiar enough with > to speak confidently about), I no longer believe that to be true. > > > > A listing of all 3rd-party JS, and its license: > > - Bootstrap 2.1.1 (+change from Dan McGee) : Apache 2.0 > - jQuery 1.8.3 : MIT > - tablesorter[1] 2.7: MIT / GPL > dual-license > - D3 3.0.6 : 3-clause BSD > - konami.js[2] c0f686e (+change from unknown author[3]) : GPLv3 > > [1]: https://github.com/Mottie/tablesorter > [2]: https://github.com/snaptortoise/konami-js > [3]: > https://git.parabola.nu/server/parabolaweb.git/plain/Makefile.d/konami.js.patch?h=archweb-generic > > Note that without even being concerned with license compatibility, > archweb is currently in violation of konami.js, as it does not > include, link to, or in any way provide instructions on how to obtain > non-minified source code. This is especially grievous, as it includes > (minor) changes that are not present in any non-minified version that > I have found. (We already patch to fix this in Parabola's fork; after > identifying the minifier used (UglifyJS 2.2), I backed-out to > reproduce the source changes (which I linked above).) > > Now, as Andrew Gregory agreed, the GPLv3 and Apache 2.0 licenses of > konami.js and Bootstrap are incompatible with archweb's GPLv2 license. > The 3rd-party files of concern are: > > retro/static/2013/bootstrap-typeahead.min.1aacd3d7f4db.js > retro/static/2013/konami.min.e165c814457d.js > sitestatic/bootstrap-typeahead.js > sitestatic/konami.min.js > > Additionally, the following file includes both 1st-party GPLv2 code, > and minified versions of bootstrap-typeahead.js and konami.js: > > sitestatic/homepage.js I'm happy to drop the whole konami.js code, it's a gimmick and doesn't really serve a purpose. The bootstrap stuff is harder, only required for typeahead and I remember messing with an alternative which was MIT but that might require a jQuery update. That should fix all the issues I think. > > This 3rd-party code is called by GPLv2-licensed archweb code in the > files: > > retro/templates/retro/index-2013-03-07.html > templates/public/index.html > sitestatic/homepage.js > > > > As Eli Schwartz noted elsewhere in the thread, after it was copied in > to archweb, konami.js has since re-licensed to the MIT license. > However, that does not cover the changes of unknown authorship that > were present when konami.js was first add to archweb. There's a good > chance that the author there is Dan McGee (who added the file to > archweb), but I'm not certain of that. > > | Proposed path forward: Confirm with Dan that he is the author of > | the changes, and that he agrees to license them under the MIT > | license. From there, simply backport the license change from > | upstream commit ece43a5. > > Bootstrap has also since re-licensed so that 3.1 and later are MIT > licensed; however, bootstrap-typeahead.js was only ever present in > Bootstrap 2.x; and was therefore not covered in the re-license. > > | Possible path forward (proposed by Jelle van der Waa): Modify > | homepage.js and index-2013-03-07.html to use the MIT-licensed > | horsey[4] instead of bootstrap-typeahead.js. > | > | [4]: https://github.com/bevacqua/horsey > > | Possible path forward: Contact the 7 authors of > | bootstrap-typeahead.js and confirm that they agree to license it > | under the MIT license. I believe all 7 of them agreed to this for > | other Bootstrap code that they were authors of; so presumably this > | is something they are agreeable to. > > -- > Happy hacking, > ~ Luke Shumaker -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-projects] [archweb] Licensing issues with JS code
On 01/15/18 at 12:56am, Eli Schwartz via arch-projects wrote: > On 01/15/2018 12:07 AM, Luke Shumaker wrote: > > From what I see, that's a minority position, but of course I run in > > FSF circles, so my perception is a bit skewed. :P > > > > If that's the official position that the archweb team wants to take, I > > won't argue. > > I dunno what jelle/angvp/the gang would say, I do know that my personal > opinion is markedly skewed. :p I don't think we care largely care/cared. But this is probably something we should resolve. > >> I'll be watching this list and the Pull Requests page on archweb's > >> github with anticipation. ;) > > > > Wait, archweb is on GitHub? :P > > > > Is a GitHub PR the preferred method, or is the usual git-send-email to > > this ML preferred? > > > > (Though I have to be honest: this is on my TODO list, but fairly low > > priority on it) > > Arch Linux has a Github organization: https://github.com/archlinux > > A few things are mirrored there, and a couple new projects have their > primary home there. > Archweb specifically is primarily developed there via pull requests. > Unlike other Arch projects, it is the preferred workflow of archweb > developers/contributors. > Though I am sure git-send-email to this ML will still get through. :) Yeah PR's are preferred, they get tested automatically too. I'll respond on the other mail about the violating files :) -- Jelle van der Waa signature.asc Description: PGP signature