From GNUtoo at cyberdimension.org  Fri Apr  1 22:23:44 2022
From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli)
Date: Sat, 2 Apr 2022 00:23:44 +0200
Subject: [Dev] Migrating Parabola infrastructure from the old server to
 newtron
In-Reply-To: <87r16ij2da.wl-lukeshu@lukeshu.com>
References: <20220328232503.561885c1@primarylaptop.localdomain>
 <87r16ij2da.wl-lukeshu@lukeshu.com>
Message-ID: <20220402002344.06c08fb5@primarylaptop.localdomain>

On Wed, 30 Mar 2022 20:13:21 -0600
Luke Shumaker <lukeshu at lukeshu.com> wrote:
> > - Why do we need a configuration management tool to generate the
> >   packages? Would migrating the packages generated by holo to more
> >   standard PKGBUILDS inside abslibre in a separate config
> > repository be a good idea? So far I found several advantages in
> > doing that:
> 
> We aren't using `holo-build`; just the core of Holo--they *are*
> standard PKGBUILDs.  Well, they `source common.sh` which is a few
> shell functions that I found useful for writing config-oriented
> PKGBUILDs.

By non-standard I wanted to convey the fact that:
- I've managed to build them with makepkg but they don't work (yet)
  with libremakepkg. So they are different from the PKGBUILDs we have
  in abslibre from that reguard. They also require some work to
  integrate in the structure used by abslibre.
- In addition they are not made in the same way PKGBUILDs are typically
  made so while makepkg accepts them, they look less familiar to
  developers.

The fact that they share code is really interesting. Unfortunately I've
not managed to integrate that well with libremakepkg, so I will
probably not be able to use something like that for the u-boot packages
yet.

> So what Holo does for us is provide a pacman post-install hook that
> gives us a way to patch files owned by other packages.
I understand the point now. Thanks a lot.

This means that if we add them in abslibre they would conflict with the
configuration from existing packages.

And if we have part in abslibre and part in holo config repository, we
end up having too much parallel systems.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220402/5c261967/attachment.sig>

From lukeshu at lukeshu.com  Sat Apr  2 17:21:04 2022
From: lukeshu at lukeshu.com (Luke Shumaker)
Date: Sat, 02 Apr 2022 11:21:04 -0600
Subject: [Dev] Migrating Parabola infrastructure from the old server to
 newtron
In-Reply-To: <20220331194709.04ce363b@parabola.localdomain>
References: <20220328232503.561885c1@primarylaptop.localdomain>
 <87r16ij2da.wl-lukeshu@lukeshu.com>
 <20220331194709.04ce363b@parabola.localdomain>
Message-ID: <87pmlzz9j3.wl-lukeshu@lukeshu.com>

On Thu, 31 Mar 2022 17:47:09 -0600,
bill-auger wrote:
> 
> On Wed, 30 Mar 2022 20:13:21 -0600 Luke wrote:
> >  1. The *are* included in https://winston.parabola.nu/backup/
> >  2. And also mirroring config.git should be sufficient
> 
> i think gnutoo's intention is less about backup of live data; but
> to codify the initial server setup and config, and make it
> reproducible ("winston in a can")

Right, I'm not talking about the live config (though that is of course
backed up too).  The sources are backed up via Git backups, and the
mirroring the built config packages as part of the main repos is
somewhat moot because they are already in the backups of `/srv`.

> 
>                                                    the etckeeper
> store appears to be only local to etckeeper (not under ~/git) -
> etckeeper supports pushing to a remote repo; but none is defined

Note that their are secrets checked in to etckeeper, so if it gets
pushed to a remote repo, then that remote repo must be private.

-- 
Happy hacking,
~ Luke Shumaker

From pagure at pagure.io  Wed Apr  6 13:13:16 2022
From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=)
Date: Wed,  6 Apr 2022 13:13:16 +0000 (GMT)
Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2341=3A_libre/iceweasel_98=2E?=
 =?utf-8?b?MC4x?=
In-Reply-To: <abslibre-pull-request-45847ae9ce7a4d4fae0dcc836e58141a@pagure.io>
Message-ID: <abslibre-pull-request-45847ae9ce7a4d4fae0dcc836e58141a/close/1649250796.0@pagure.io>


grizzlyuser closed without merging a pull-request against the project: `abslibre` that you
are following.

Closed pull-request:

``
libre/iceweasel 98.0.1
``

https://pagure.io/abslibre/pull-request/41

From pagure at pagure.io  Wed Apr  6 13:17:52 2022
From: pagure at pagure.io (=?utf-8?q?Grizzly_User?=)
Date: Wed,  6 Apr 2022 13:17:52 +0000 (GMT)
Subject: [Dev] =?utf-8?q?=5Babslibre=5D_PR_=2342=3A_libre/iceweasel=3A_Up?=
 =?utf-8?q?date_to_99=2E0_according_to_upstream_changes?=
Message-ID: <abslibre-pull-request-8c3bc5a3587d4d0eb5f28d597f99491a@pagure.io>


grizzlyuser opened a new pull-request against the project: `abslibre` that you are following:
``
libre/iceweasel: Update to 99.0 according to upstream changes
``

To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/42

From nobody at parabola.nu  Wed Apr 13 04:05:47 2022
From: nobody at parabola.nu (Parabola Website Notification)
Date: Wed, 13 Apr 2022 04:05:47 -0000
Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date
Message-ID: <20220413040547.3710385.85310@winston.parabola.nu>

eliotreyna at disroot.org wants to notify you that the following packages may be out-of-date:


* iceweasel 1:99.0-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/


The user provided the following additional text:

Firefox source code has been updated to the version 99.0.1.

It includes a couple of bugfixes: Bengali rendering and drag and drop function in Download panel.

For more detailed info, please go to the link below:

https://www.mozilla.org/en-US/firefox/99.0.1/releasenotes/

Thanks.


From nobody at parabola.nu  Fri Apr 22 05:52:38 2022
From: nobody at parabola.nu (Parabola Website Notification)
Date: Fri, 22 Apr 2022 05:52:38 -0000
Subject: [Dev] Orphan Libre package [linux-libre-hardened] marked out-of-date
Message-ID: <20220422055238.3710382.54336@winston.parabola.nu>

a.reviewer1234 at yahoo.com wants to notify you that the following packages may be out-of-date:


* linux-libre-hardened 5.15.12.hardened1-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened/
* linux-libre-hardened-docs 5.15.12.hardened1-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened-docs/
* linux-libre-hardened-headers 5.15.12.hardened1-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-hardened-headers/


The user provided the following additional text:

5.17.4 released


From bill-auger at peers.community  Sat Apr 23 03:19:19 2022
From: bill-auger at peers.community (bill-auger)
Date: Fri, 22 Apr 2022 23:19:19 -0400
Subject: [Dev] recent parabola changes to 'pacman'
Message-ID: <20220422231919.3959e96b@parabola.localdomain>

pacman 6.0.1 was released in september - it is quite overdue for
an upgrade - i wanted to discuss some of the recent parabola
changes - i have let it slide; because i though that ovruni was
maintainer of 'pacman' and would upgrade it eventually - i just
noticed though, that lukeshu is listed as maintainer, which
would explain why no one upgraded it recently

--------

the first item is to remove the dependency on
'archlinux32-keyring' - that package has been particularly
troublesome over the years. - a recurring source of installation
bug reports - it is needed only for a few packages
('pcmciautils' is the only one that i know of)

at one time, 'pcmciautils' was considered essential (it is still
in the 'base' package group on i686) - after arch dropped it, it
was still required by openrc; but is not anymore - i convinced
the arch32 team that it was still an important package for i686;
and they decided to adopt it - it is needed for some old 64bit
laptops also; so isacdaavid and i decided to make 'pacman'
depend 'archlinux32-keyring' and 'archlinuxarm-keyring', to
simply things (or so we thought)

this the original log message:
> commit 6647f647074142d2d335694c76284bb720040131
> Author:     Isaac David
> AuthorDate: Tue Nov 14 18:44:01 2017 -0600
>
> people keep forgeting to install archlinux{arm,32}-keyring
> for foreign-architecture pacstrap/librechroot on x86_64.
>
> as for dbscripts, this also allows us to reuse arch=(any)
> packages from whatever distro in whatever architecture, in the
> remote scenario where ALARM or Arch32 updates one such package
> before x86_64 Arch does.

based on that rationale (plus supporting PCMCIA hardware), i
dont think the recurring problems are justified - that is, i
would expect many fewer (or no) bug reports if pacman did not
depend on 'archlinux32-keyring' - it would also remove the need
for arch users to install the equally problematic
'archlinux32-keyring-transition' when migrating

ive been considering this for a while; but there is something
curious about it - 'pacman' has depended on
'archlinuxarm-keyring' for as long (although isacdaavid's
rationale is the only reason for that); but that one has never
been a problem - granted that the keyring has never changed (the
expiry from 2014 is infinite) and there is no
'archlinuxarm-keyring-transition' package; but that does
not explain, why dont arch users need to install a transitional
keyring package when migrating to parabola - so it may be nice
to solve that mystery too - i would not want to be burying an
elusive bug by doing this

--------

the second item i would like to discuss is regarding this change
(not yet built):

https://git.parabola.nu/abslibre.git/commit/?id=2c1ed4889d421b96887fffe2a4945a26bdc21733

the log message is very detailed, so i wont repeat it - i think
this should be handled differently - although 'auto' is not
relevant to parabola at this time, it may be in the future - an
alternate implementation which would satisfy GNUtoo's concern,
is to make the change to the /usr/share/ files using sed in the
PKGBUILD, leaving 'auto' in the installed /etc/pacman.conf

https://git.parabola.nu/abslibre.git/commit/?id=aa6da95c797fc1e208b5d6e79f7c7645132a3989

--------

just to remind myself, there is a third change to add a
keyring updater init script for openrc - it does not need
discussion (but feel free) - there has been one for systemd
since 2014; but it was never done for openrc

From bill-auger at peers.community  Sat Apr 23 03:27:04 2022
From: bill-auger at peers.community (bill-auger)
Date: Fri, 22 Apr 2022 23:27:04 -0400
Subject: [Dev] recent parabola changes to 'pacman'
In-Reply-To: <20220422231919.3959e96b@parabola.localdomain>
References: <20220422231919.3959e96b@parabola.localdomain>
Message-ID: <20220422232704.53d03a93@parabola.localdomain>

FWIW, there was a bug in my change - i just fixed it

> local pacman_conf="$pkgdir/usr/share/pacman/defaults/pacman.conf.$carch"
> sed -i "s|^Architecture = .*|Architecture = ${carch}|" "${pacman_conf}"

From bill-auger at peers.community  Sat Apr 23 03:42:47 2022
From: bill-auger at peers.community (bill-auger)
Date: Fri, 22 Apr 2022 23:42:47 -0400
Subject: [Dev] recent parabola changes to 'pacman'
In-Reply-To: <20220422232704.53d03a93@parabola.localdomain>
References: <20220422231919.3959e96b@parabola.localdomain>
 <20220422232704.53d03a93@parabola.localdomain>
Message-ID: <20220422234247.60ae328f@parabola.localdomain>

presuming that someone will ask why is the archlinux32 keyring
so troublesome - i really dont know; but it has been troublesome
for as long as i have been with parabola - they seem to change
keys too often - it seems like every new keyring package is not
installable - i have discussed it with them; but never resolved
it

ive found it simplest to pull the package each time it is
upgraded, and re-package it myself - but i never realize that
needs to happen, until another bug report comes in - another
alternative would be to add erich and abaumann to the parabola
keyring; but it probably would not help, if they keep changing
keys

finally,i should mention that removing 'archlinux32-keyring'
form pacman's deps, only solves the problem for x86_64 - whatever
future troubles that package gives us, will always affect people
trying to install parabola i686

From GNUtoo at cyberdimension.org  Sun Apr 24 21:41:16 2022
From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli)
Date: Sun, 24 Apr 2022 23:41:16 +0200
Subject: [Dev] recent parabola changes to 'pacman'
In-Reply-To: <20220422231919.3959e96b@parabola.localdomain>
References: <20220422231919.3959e96b@parabola.localdomain>
Message-ID: <20220424234116.685edf01@primarylaptop.localdomain>

On Fri, 22 Apr 2022 23:19:19 -0400
bill-auger <bill-auger at peers.community> wrote:
> the first item is to remove the dependency on
> 'archlinux32-keyring' - that package has been particularly
> troublesome over the years. - a recurring source of installation
> bug reports - it is needed only for a few packages
> ('pcmciautils' is the only one that i know of)
Should we also build all these keyring packages? 

If you don't keep your system up to date enough the keyring becomes
impossible to upgrade safely. You end up needing the new keyring
package to install the new keyring package as upstream changed keys
somehow and that the transition package is gone.

Not keeping system up to date can easily happen with computers that you
stop using (like single board computers) and that you use again to do
tests for instance.

> the second item i would like to discuss is regarding this change
> (not yet built):
> 
> https://git.parabola.nu/abslibre.git/commit/?id=2c1ed4889d421b96887fffe2a4945a26bdc21733
> 
> the log message is very detailed, so i wont repeat it - i think
> this should be handled differently - although 'auto' is not
> relevant to parabola at this time, it may be in the future - an
> alternate implementation which would satisfy GNUtoo's concern,
> is to make the change to the /usr/share/ files using sed in the
> PKGBUILD, leaving 'auto' in the installed /etc/pacman.conf
> 
> https://git.parabola.nu/abslibre.git/commit/?id=aa6da95c797fc1e208b5d6e79f7c7645132a3989
Apparently my commit message wasn't complete enough: I only talked
about pacstrap, but using arch-chroot to chroot into a 32bit
installation from a computer running a 64bit kernel and running 
'pacman -Syu' inside also results in pacman trying to download
and install 64bit packages (and failing).

As I see it, if we have some auto-detection, if it is done at the
installation time (and not each time we run pacman) and that the
detection result is then hardcoded pacman.conf, it would probably
make both auto-detection and chroot/pacstrap work.

This way chrooting will always work consistently and users won't have
mixes of different architectures. 

Users wanting to upgrade from an architecture to another one will then
have to do the switch manually. 

Before, switching from 64bit to 32bit was not officially supported by
Arch, so it's not a bad idea to have things like that be a conscious
choice of users.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220424/51f874c5/attachment.sig>

From bill-auger at peers.community  Mon Apr 25 10:56:03 2022
From: bill-auger at peers.community (bill-auger)
Date: Mon, 25 Apr 2022 06:56:03 -0400
Subject: [Dev] recent parabola changes to 'pacman'
In-Reply-To: <20220424234116.685edf01@primarylaptop.localdomain>
References: <20220422231919.3959e96b@parabola.localdomain>
 <20220424234116.685edf01@primarylaptop.localdomain>
Message-ID: <20220425065603.464ef537@parabola.localdomain>

On Sun, 24 Apr 2022 23:41:16 +0200 Denis wrote:
> Should we also build all these keyring packages? 

only the arch32 keyring has ever been a problem - i have been
rebuilding it whenever someone reports the problem


> If you don't keep your system up to date enough the keyring becomes
> impossible to upgrade safely. You end up needing the new keyring
> package to install the new keyring package

that is true; but this happens too often - the problem is
usually noticed on the install ISOs - the alternative is to
rebuild all 32bit ISOs, every time the arch32 keyring changes -
thats much more work than rebuilding the keyring; and totally
unnecessary otherwise


> Users wanting to upgrade from an architecture to another one will then
> have to do the switch manually. 

i must agree - when i first setup my arch32 VM, the first time i
ran pacman -Syu, it upgraded most of the entire system - i
keep it for testing bugs in parabola i686, before reporting
them upstream - so, i had to revert it to i686 and pacman -Syuu
- i do not like auto-magic either - i agree that changing
arches should be a conscious decision

the only good reason to keep auto, is because thats what the
arch pacman.conf has - i am comfortable with deviating from that
- your hard-coded implementation is better - the auto-detect
install hook approach would actually introduce a bug - install
hooks should not modify owned files - those files are hashed at
build time - when a package is upgraded, it checks files
installed under /etc ( or may only those in the backup=() array,
im not sure) to determine if they have been modified - if it
is not modified but that file is going to change, it installs
the new one as *.pacnew - if the file is modifed by an install
hook, it will never match the hash

From GNUtoo at cyberdimension.org  Wed Apr 27 00:13:32 2022
From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli)
Date: Wed, 27 Apr 2022 02:13:32 +0200
Subject: [Dev] Update on the PKGBUILDs license
Message-ID: <20220427021332.079d3e33@primary_laptop>

Hi,

Since the bug #2862[1] (Clarify the copyright status of PKGBUILDs) that
was opened one year ago we got some feedback.

Several people tended to consider that PKGBUILDs were not copyrightable
or wanted to have a license with something similar. And at least one
Arch contributor stated that the PKGBUILD made by that person made were
released under the unlicense[1].

So I propose to add a commit with a README stating that the PKGBUILDS
added after the commit adding this README are under the CC0 license.

The CC0 license has been choosen as it's a license that is really close
to the public domain, and that probably works in all jurisdictions.

We need a license instead of just telling that the work is under the
pulbic domain because some countries don't have a notion of public
domain or different notions of public domain, so work added to the
public domain might not work in theses countries or be nonfree in
practice.

Since adding a README cannot be done retrospectively, and that we
already have PKGBUILDs in the abslibre repository, I am also looking
for people to agree to relicense their past contribution under the CC0.

So I'm seeking two things here:
- A consensus on if it's OK to add this README.
- The agreement from the people having contributions in abslibre to
  relicense their contributions in abslibre to the CC0.

So far, the following people agreed to relicense their contributions to
the CC0 license:
- bill-auger 
- Denis 'GNUtoo' Carikli

References:
-----------
[1]https://labs.parabola.nu/issues/2862

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220427/dcba2a55/attachment.sig>

From GNUtoo at cyberdimension.org  Wed Apr 27 00:40:56 2022
From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli)
Date: Wed, 27 Apr 2022 02:40:56 +0200
Subject: [Dev] Update on the PKGBUILDs license
In-Reply-To: <20220427021332.079d3e33@primary_laptop>
References: <20220427021332.079d3e33@primary_laptop>
Message-ID: <20220427024056.22113360@primary_laptop>

On Wed, 27 Apr 2022 02:13:32 +0200
Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:
> So far, the following people agreed to relicense their contributions
> to the CC0 license:
> - bill-auger 
> - Denis 'GNUtoo' Carikli

On #parabola on liberachat we also got Freemor that agreed:
> 02:31 < Freemor> re: PKGBUILD license - I'm fine with both the CC) and
the README

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220427/512b5639/attachment.sig>

From bill-auger at peers.community  Wed Apr 27 00:42:27 2022
From: bill-auger at peers.community (bill-auger)
Date: Tue, 26 Apr 2022 20:42:27 -0400
Subject: [Dev] Update on the PKGBUILDs license
In-Reply-To: <20220427024056.22113360@primary_laptop>
References: <20220427021332.079d3e33@primary_laptop>
 <20220427024056.22113360@primary_laptop>
Message-ID: <20220426204227.515ec6f9@parabola.localdomain>

testing

From andreas at grapentin.org  Wed Apr 27 05:38:35 2022
From: andreas at grapentin.org (Andreas Grapentin)
Date: Wed, 27 Apr 2022 07:38:35 +0200
Subject: [Dev] Update on the PKGBUILDs license
In-Reply-To: <20220427024056.22113360@primary_laptop>
References: <20220427021332.079d3e33@primary_laptop>
 <20220427024056.22113360@primary_laptop>
Message-ID: <20220427053835.6mpfplh4qokytexr@arch-kevin>


I also agree with all future and previous contributions to the PKGBUILDs
being licensed under the CC0.

Best,
Andreas

On Wed, Apr 27, 2022 at 02:40:56AM +0200, Denis 'GNUtoo' Carikli wrote:
> On Wed, 27 Apr 2022 02:13:32 +0200
> Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:
> > So far, the following people agreed to relicense their contributions
> > to the CC0 license:
> > - bill-auger 
> > - Denis 'GNUtoo' Carikli
> 
> On #parabola on liberachat we also got Freemor that agreed:
> > 02:31 < Freemor> re: PKGBUILD license - I'm fine with both the CC) and
> the README
> 
> Denis.



> _______________________________________________
> Dev mailing list
> Dev at lists.parabola.nu
> https://lists.parabola.nu/mailman/listinfo/dev


-- 

------------------------------------------------------------------------------
my GPG Public Key:                 https://files.grapentin.org/.gpg/public.key
------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220427/e5edc13d/attachment.sig>

From dev at lists.parabola.nu  Wed Apr 27 13:56:15 2022
From: dev at lists.parabola.nu (n41nb39)
Date: Wed, 27 Apr 2022 09:56:15 -0400
Subject: [Dev] {Spam?} ***Request For Supplies - Die Plates*** from n41nb39
Message-ID: <E1nji9P-0007eE-RO@host.wfdns.com>

An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220427/f02a8b54/attachment.htm>

From wael at waelk.tech  Thu Apr 28 06:07:54 2022
From: wael at waelk.tech (Wael Karram)
Date: Thu, 28 Apr 2022 09:07:54 +0300
Subject: [Dev] [libreboot-util] PKGBUILD
Message-ID: <20220428090754.3463a00a.wael@waelk.tech>

Hello,
Per bill-auger's request on Packaging Issue #3208 I have attached the finalized
PKGBUILD patch for libreboot-util.
In the end, it has all the discussed binaries getting compiled (ectool,
superiotool, nvramtool and bucts).

It was agreed that even though bucts is specific to x60(s) and t60(s) it would
be packaged with the rest of the binaries now and the package can be split
later if needed, as it is decently small and this will cause less clutter.
Libreboot sources are being used (instead of upstream Coreboot) as they are
assured to be FSDG-compatible, FOSS and de-blobbed.

Note that to get the package to compile, Leah Rowe's GPG key has to be imported
(info at minifree.org).

Additionally, note that while nvramtool is already packaged in the repos (this
PKGBUILD was built off of its PKGBUILD), in the packaging request bill-auger
suggested that there is no point to add a replaces entry now as that package is
still rather new.

-- 
Kind Regards,
Wael Karram.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libreboot-util.patch
Type: text/x-patch
Size: 3310 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220428/bb5d69ca/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220428/bb5d69ca/attachment.sig>

From bill-auger at peers.community  Thu Apr 28 09:37:19 2022
From: bill-auger at peers.community (bill-auger)
Date: Thu, 28 Apr 2022 05:37:19 -0400
Subject: [Dev] Update on the PKGBUILDs license
In-Reply-To: <20220427053835.6mpfplh4qokytexr@arch-kevin>
References: <20220427021332.079d3e33@primary_laptop>
 <20220427024056.22113360@primary_laptop>
 <20220427053835.6mpfplh4qokytexr@arch-kevin>
Message-ID: <20220428053719.29a9e5fd@parabola.localdomain>

as i mentioned to gnutoo on IRC, in order to do this properly,
we will need some cooperation from arch - i did some research
and have prepared an email to send to arch - anyone who is
interested, please read it over and offer critique or corrections

------------------------------------------------------------
re: the license of the ABS tree

There is a conventional concept called: "inbound<->outbound"
licensing, for software contributions. Github for example,
recognizes it and makes it explicit in their TOS. Roughly
speaking, if the project has no explicit policy regarding the
license of contributions, then all contributions are implicitly
considered to be offered under the main license of the project.
I intend to make the case that Arch could use this common
understanding, and Arch's own existing policies, as
justification to freely license the ABS tree and all of the AUR,
with minimal effort or arguments from contributors.

It is my understanding from discussing this with one Arch TU,
that the consensus among the Arch team, is a subtle twist to
that "inbound<->outbound" convention. Namely, that build recipes
are considered to not copyrightable, based on the "threshold of
originality" rule-of-thumb of copyright. Therefore, if that is
and was the consensus, then all contributions were accepted into
Arch under that presumption (ie: the main license of the project
is implicitly: "This is not copyrightable. Please do not claim
otherwise").

That may not be or may not be valid implicitly, but i think that
Arch has grounds to make it explicit, and to license all ABS and
AUR build recipes, retroactively (we believe that CC0 is the
ideal option in this case). If some contributions were offered
without that presumption; then frankly, Arch has "shot itself in
the foot", by failing to make the terms of contribution and
derivation explicit from the beginning. This issue should not be
ignored forever. It only gets more difficult to fix over time.

It would be very difficult for anyone to claim: "I did not know
or did not intend, that these would be shared freely, for use
and modification by anyone in the world". It is generally
assumed by Arch users, that every contributor to every recipe in
Arch and AUR knows fully, that the work will be published freely
for the public use, and that anyone with a copy, is most likely
to have taken it, specifically with intent to modify it, and
that no special permission is required to do so.

If contributors did not know that. They were either foolish, or
they were planting a hidden copyright bomb on the project.
Whether ignorantly or maliciously, i think that could be
considered to be "entrapment" by legal experts. Such
contributions should be identified, and if the contributor does
not agree to a CC0 license, the contribution should be deleted
and re-written. If the re-written code happens to be identical
to the original, that only underlines the original presumption
that it was not copyrightable in the first place.

Likewise, every package maintainer assumes that all
contributions are offered freely. If any contributor were to
state in advance, that other people should not be allowed to
modify the recipe, we would all hope that the contribution would
be rejected on the face of it. Arch should protect it's users by
making that an explicit policy. Arch would also be protecting
itself in that way; because then, anything adopted from AUR into
Arch, would be unambiguously acceptable.

I could find little which could be construed as policy on the
matter; but i found a few points of reference, which demonstrate
that the intent of unfettered re-distribution and modifications,
always existed, at least implicitly.

------------------------------------------------------------

Copying:
* Arch allows anyone to clone the ABS repo,
  without special permission.
* The wiki gives instructions on how to do so.

------------------------------------------------------------

Modifying:
* The "Trademark Policy" explicitly encourages modifications
  and derivatives.
* The "Arch Build System" wiki article lists this as an
  intended use-case.

from
https://wiki.archlinux.org/title/Arch_Build_System#Use_cases:
> Its use cases are:
> * Customize existing packages to fit your needs (e.g. enabling or disabling options, patching).
> * Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD.

------------------------------------------------------------

Sharing:
* The issue of "sharing" was not as easy to find evidence for.
  Although Arch clearly allows anyone to clone the ABS repo, and
  instructs how to do so, i could find nothing that states what
  down-streams are permitted to do with it, other than modifying
  for personal use. However, the "Code of Conduct" and "Trademark
  Policy" recognize that complete system derivatives exist and
  are not problematic for Arch, if the trademark policy is
  honored and Arch is not burdened with user support.

from
https://terms.Archlinux.org/docs/code-of-conduct/#Arch-linux-distribution-support-only:
> These distributions often use different packages, package versions, repositories,
> or make custom system configurations silently.

from
https://wiki.Archlinux.org/title/DeveloperWiki:TrademarkPolicy:
> ... we encourage customisation and derivation of Arch Linux, ...

------------------------------------------------------------

Contributions:
* The DeveloperWiki makes it clear that all AUR submissions
  are contributions to Arch proper.

from
https://wiki.archlinux.org/title/DeveloperWiki:Package_Submittal_Rules:
> Once a contributor uploads a package to the AUR they are considered the contributor.
> The act of uploading the package can be considered a donation or patch submittal.
> Everyone acknowledges that the package was created by the contributor,
> but it is now the property Arch Linux.

------------------------------------------------------------

Conclusions:
* Granted that PKGBUILDs are essential to any pacman-based
  distro, for Arch to encourage derivatives, implies that
  derivatives have permission to modify and re-distribute the
  packaging recipes.
* All of this evidence points to the conclusion, that Arch build
  recipes are intended to be freely re-distributable and
  modifiable; and that this is commonly understood by all users
  and contributors to the recipes. We are only trying to make
  these implications explicit, in order to clarify the legal
  ambiguity.

------------------------------------------------------------

We have started doing so within Parabola; but we can only apply
it to contributions offered to Parabola specifically. PKGBUILDs
are fairly ubiquitous though. What i will call "the pacman
ecosystem", is truly shared across many distros. That is,
PKGBUILDs from Arch and AUR tend to flow down to derivatives and
cross-pollinate between them. I think it is safe to say that
most PKGBUILDs in most pacman-based distros were taken, in full
or in part, from Arch or other projects.

In order for Parabola to achieve the ultimate goal of clear
licensing of all recipes, will require the cooperation of Arch,
or at least a clear statement of intent. If Arch adopted this
goal for itself, all other pacman-based distros could inherit the
benefit.

An example policy or statement of intent could be as simple as
this:

  We believe that software build recipes are not copyrightable.
  However, our recipes are all offered under the terms of the
  CC0 1.0 Universal license preemptively, despite that we
  believe the license to be inapplicable. Note that some build
  recipes include patches taken from their respective upstream
  projects. Those are assumed to be under the upstream license.

  If you have contributed to ArchLinux or the Arch User
  Repository in the past, and you disagree with this policy,
  please contact us immediately, and your contributions will be
  deleted.

I am not legal expert; but i think that would make a strong case
against anyone who contests it. It is essentially a DMCA
"take-down" policy. Furthermore, anyone who contests it, must
first demonstrate that the contribution meets the "threshold of
originality", which would be as difficult to argue for, as the
claim: "I did not know that my work would be shared and
modified".

I believe that the evidence thus far, has been sufficient to
suggest, that Arch could do this immediately, with minimal
effort or arguments from contributors. On the other hand, I did
find one reference which could be sufficient on it's own.

Section "5.2. Contribution Licenses" of the Arch TOS, touches
upon licensing:

from https://terms.Archlinux.org/docs/terms-of-service/:
> In the case of a contribution of software to an Arch Linux Project
> via GitLab or otherwise, you agree to license the contribution
> under the Project?s license. If the Project does not state a license,
> you agree to license it under the terms of the GNU General Public License version 3.

That is fairly unambiguous, except for the following subtleties:
* Is the ABS tree an "Arch Linux Project"?
* What is that project?s license?

The "DeveloperWiki:Projects" wiki article does not list ABS; but
I found that at least some team members, consider ABS to be an
"Arch Linux Project". The protected "Arch IRC channels" wiki
article gives the topic of the #archlinux-projects IRC channel
as:
> Projects development and discussion (mkinitcpio, abs, dbscripts, devtools?)

That alone, if true, could resolve the ambiguity, trivially.
Contribution to the ABS tree are licensed GPLv3, implicitly, per
the existing TOS. Of course, the GPL is somewhat overkill for
shell scripts. The CC0 is more appropriate and probably most
agreeable to all; so that is our recommendation, if the ABS tree
is not already considered to be an "Arch Linux Project".

From bill-auger at peers.community  Fri Apr 29 04:26:49 2022
From: bill-auger at peers.community (bill-auger)
Date: Fri, 29 Apr 2022 00:26:49 -0400
Subject: [Dev] Update on the PKGBUILDs license
In-Reply-To: <20220428053719.29a9e5fd@parabola.localdomain>
References: <20220427021332.079d3e33@primary_laptop>
 <20220427024056.22113360@primary_laptop>
 <20220427053835.6mpfplh4qokytexr@arch-kevin>
 <20220428053719.29a9e5fd@parabola.localdomain>
Message-ID: <20220429002649.6ef3b584@parabola.localdomain>

gnutoo has added some license headers to PKGBUILDs of this form:

> # Copyright (C) 2019,2020 Andreas Grapentin <andreasXgrapentin.org>
> # Copyright (C) 2019,2020,2021 bill-auger <bill-augerXprogrammer.net>
> # This program is free software: you can redistribute it and/or modify
> # it under the terms of the CC0 1.0 License.
> # Maintainer: Andreas Grapentin <andreasXgrapentin.org>
> # Contributor: bill-auger <bill-augerXprogrammer.net>

that looks noisy to me - for one thing, it is redundant - 
each contributor would be listed twice

id like to suggest using the SPDX format instead:
> # SPDX-License-Identifier: CC0-1.0
> # Maintainer: Andreas Grapentin <andreasXgrapentin.org>
> # Contributor: bill-auger <bill-augerXprogrammer.net>

when i tried this, i noticed that my editor recognized it
and gives it a special color - that suggest to me that
these headers are widely known/acceptable these days
there is a lot of buzz in the libre community about REUSE,
which favors SPDX - i think we should encourage it

From bill-auger at peers.community  Fri Apr 29 04:34:15 2022
From: bill-auger at peers.community (bill-auger)
Date: Fri, 29 Apr 2022 00:34:15 -0400
Subject: [Dev] [libreboot-util] PKGBUILD
In-Reply-To: <20220428090754.3463a00a.wael@waelk.tech>
References: <20220428090754.3463a00a.wael@waelk.tech>
Message-ID: <20220429003415.0616ad96@parabola.localdomain>

noting that redmine is tracking this
https://labs.parabola.nu/issues/3208