Re: [arch-projects] [arch-ports] [devtools] Rebasing devtools32 to contribute upstream

[Erich Eckner]

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

[Luke Shumaker]

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`

[Luke Shumaker]

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

[Luke Shumaker]

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.

[Eli Schwartz via arch-projects]

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

[Eli Schwartz via arch-projects]

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

[Luke Shumaker]

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`

[Eli Schwartz via arch-projects]

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

[Eli Schwartz via arch-projects]

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`

[Luke Shumaker]

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

[Luke Shumaker]

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

[Luke Shumaker]

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

[Luke Shumaker]

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

[Luke Shumaker]

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

[Luke Shumaker]

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

[Luke Shumaker]

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`

[Luke Shumaker]

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

[Jelle van der Waa]

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

[Jelle van der Waa]

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