db6 license concerns

[Andreas Radke]

I have noticed freswa has bumped BerkeleyDB to
v6 (again) and started pushing rebuilds to staging repo. 

Arch Linux had made this update already in August 2013 and
discussions lead us to revert this back quickly:

https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/JE62DF2DFF4Y4IPTBZOMV3IJXKZXJH3H/

Here you can find some thoughts why 3rd party applications may not be
legally compatible to use the AGPLv3 licensed BDB v6:

https://lwn.net/Articles/557820/
https://fedoraproject.org/wiki/Changes/BerkeleyDB_6

It's pretty questionable if someone is allowed to build and
redistribute packages against the newly AGPLv3 licensed BDB version
without checking and probably changing related application licenses.
But I'm not a lawyer. Most major Linux distributions still stick with
BDB v5 therefore. So we did back then in 2013 until now. Some
distributions have added v6 along v5 and only use it carefully when
upstream projects declare their license AGPLv3 compatible to be usable
with later BDB versions.

Two major concerns I have here:

1) No public discussion happened here or somewhere else before such a
major change. The packager will have known there's something special
with such a long flagged package in core. All major changes affecting
the core repo should really go through some discussion before they
happen.

2) I've immediately raised my concerns pinging freswa at IRC and only
see today the rebuilds went ahead and keep going on. 

That's not how our team should deal such maybe critical step. I don't
want to imagine Arch spending all funded money for some curt fights we
could easily avoid here.

Please start some public discussion why this change happened and why
the concerns of other distributions and our own developers are not
worth to take a small break to think about it again.

-Andy



pgpI2addRo1s9.pgp
Description: Digitale Signatur von OpenPGP

Arch Linux in November 2022

[Levente Polyak]

## Git packaging sources

We made huge progress towards finally being able to
migrate from SVN to Git for package sources. The core
projects responsible for our package build, workflow and
release, namely dbscripts and devtools reached
production grade adjustments to achieve the transition [0][1].

Furthermore we have started to document and outline our
Roadmap with the Git packaging as its first item [2].
This Epic can be followed to outline the full
dependencies including child issues and child epics for
everything that needs to be handled or adjusted
afterwards.

The next stop in this journey will be to propose the
migration with all workflow details to arch-dev-public
in the following days.


## infrastructure

We have migrated our Keycloak 17 intance [3] to the
recommended Quarkus distribution [4] which removes the
/auth from the context-path. This change required all
OAuth clients to be adjusted. Furthermore we are now
monitoring our Keycloak intance with UptimeRobot [5].


## arch-install-scripts

A new version v28 has been released [6] which mostly
contains bugfixes.


## mkinitcpio

Development has moved to the Arch Linux GitLab instance
[7]. A new version v33 has been released [8] with a lot
of improvements. Furthermore the existing test suite has
been heavily extended and migrated to bash bats.


## keyringctl

We have started splitting out the keyringctl [8] python
code from our archlinux-keyring repository so we can
independently develop and release the tooling.

Furthermore we have started testing and will soon
integrate a streamlined way to create new main key
signatures including automatic uid verifications.


## archlinux-keyring

We have replaced one of our main signing key as follows [9][10]:

- added: 69E6 471E 3AE0 6529 7529  832E 6BA0 F5A2 037F 4F41
  dem...@master-key.archlinux.org
- revoked: 159F 3A43 AEB2 46C5 746C  0338 14BC 4F30 B3B9 2EBA
  grazzol...@master-key.archlinux.org


## pacman

Some time ago it was decided to migrate the pacman
development from the Mailing List to the Gitlab instance
hosted by Arch Linux [11]. We have now outlined a plan
[12] for the next steps to finally complete the GitLab
migration.


## repod

A talk about the current state of things will be held
during HIP [13] between 27th - 30th December 2022:
"Pacman can have the cookies and eat the ghosts too" [14]


## RFC

We are formalizing an RFC [15] to declare SPDX license
identifiers in PKGBUILDs. SPDX, or Software Package Data
Exchange, was formed by the Linux Foundation as a well-
defined standard for software bill of material
information.


## Staff

We would like to welcome tpkessler among the Arch Linux
Package Maintainers [16].


[0] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/37
[1] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/126
[2] https://gitlab.archlinux.org/groups/archlinux/-/epics/7
[3] 
https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/655

[4] https://www.keycloak.org/migration/migrating-to-quarkus
[5] https://status.archlinux.org/
[6] https://github.com/archlinux/arch-install-scripts/releases/tag/v28
[7] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio
[8] 
https://lists.archlinux.org/archives/list/arch-proje...@lists.archlinux.org/thread/XI2EBOVL6RS6TQTKCRDY7NY5TDBWRY5H/

[8] https://gitlab.archlinux.org/archlinux/keyringctl
[9] 
https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/178
[10] 
https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/183

[11] https://gitlab.archlinux.org/pacman/pacman
[12] 
https://lists.archlinux.org/archives/list/pacman-...@lists.archlinux.org/thread/XAMX6OEIQZM5BC37MUOPNFZ2RENWYMKU/

[13] https://hip-berlin.de
[14] https://pretalx.c3voc.de/hip-berlin-2022/talk/HCNL3V/
[15] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/16
[16] 
https://lists.archlinux.org/archives/list/aur-gene...@lists.archlinux.org/thread/3HLMZQBHIFASXSCGHCNS3PCP3BMKMMUU/#CFGTPPLUE4RIRHXDUHWJF4SBOEEWQMJ6


OpenPGP_signature
Description: OpenPGP digital signature