alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-01-29T06:58:59Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9418ModSecurity-Nginx2024-01-29T06:58:59ZAdam MossModSecurity-NginxHello,
Would it be possible to create a package for the \`ModSecurity-Nginx\`
connector?
Source URL is https://github.com/SpiderLabs/ModSecurity-nginx
Thanks
*(from redmine: issue id 9418, created on 2018-09-13)*Hello,
Would it be possible to create a package for the \`ModSecurity-Nginx\`
connector?
Source URL is https://github.com/SpiderLabs/ModSecurity-nginx
Thanks
*(from redmine: issue id 9418, created on 2018-09-13)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/7780Volume containing apkovl is not remounted according to the apkovl's /etc/fsta...2023-04-30T01:34:09ZalgitbotVolume containing apkovl is not remounted according to the apkovl's /etc/fstab entryTo reproduce:
1) make a new VM, attach the alpine-virtual iso and a blank virtual disk
as /dev/sda
2) run setup-alpine, selecting a data-only install, mounting to /var
3) set LBU\_BACKUPDIR=/var and run lbu commit
4) reboot and o...To reproduce:
1) make a new VM, attach the alpine-virtual iso and a blank virtual disk
as /dev/sda
2) run setup-alpine, selecting a data-only install, mounting to /var
3) set LBU\_BACKUPDIR=/var and run lbu commit
4) reboot and observer that /dev/sda2 is mounted to /media/sda2, not
/var
Cause: The initramfs /init script is supposed to unmount the device that
the apkovl was found on, after it has been unpacked. There is still
logic to unmount a device stored in $ovl\_unmount, but commit
ba27888b4576ceab7413ab9104d0aeda50990832 (which moved the apkovl search
logic out to nlplug-findfs) removed the last line that set that
variable, and as far as I can tell even the old code never unmounted
non-usb devices correctly.
Fix: Set $ovl\_unmount to the apkovl device unless it is used as the
sysroot? (This might cause a conflict if the apkovl is stored on a
boot\_repository device; IDK.)
*(from redmine: issue id 7780, created on 2017-09-01)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/15892busybox: not possible to permanently remove klogd user2024-03-19T21:47:08ZNatanael Copabusybox: not possible to permanently remove klogd userCommit b870258c717220a2ea3f8803e54578ee80820979 (main/busybox: run klogd as klogd user and not root) introduced a user named `klogd` that is created from busybox install script. A consequence of this is that users who don't want this use...Commit b870258c717220a2ea3f8803e54578ee80820979 (main/busybox: run klogd as klogd user and not root) introduced a user named `klogd` that is created from busybox install script. A consequence of this is that users who don't want this user on their system can not remove it without it gets recreated on next busybox upgrade. And since it is not really possible to uninstall busybox, it means that it is not really possible to permanently remove the `klogd` user.
Possible solutions:
1. Move the `klogd` user to default `/etc/passwd` provided by `alpine-baselayout`. Users can simply `deluser klogd`, and it will not automatically come back on upgrades. This is the solution I prefer. It is very simple, and the drawback is insignificant (`klogd` user is there by default even if you never install `busybox-openrc`).
2. Move the user creation to `busybox-openrc.pre-install`. Users can avoid creating the `klogd` user with `apk add !busybox-openrc` and not use any of the busybox provided services. There should be alternatives to those, but in this case you cannot use any of the busybox provided services.
3. Split `busybox-openrc`, and ship every service in a separate package. The `klogd` user would be created with `busybox-klogd-openrc` package. I really don't want to do this, because it adds a lot complexity with high risk of unexpected breakages and it has very low benefit.
4. let the install script parse some config where you can disable creation. For example, source `/etc/conf.d/klogd` and see if `command_user=klogd`https://gitlab.alpinelinux.org/alpine/aports/-/issues/15877py3-cryptography 42.0.5 - to mitigate CVE scanners2024-03-17T09:38:41ZBrandt, Sebastian (ITO-PC)py3-cryptography 42.0.5 - to mitigate CVE scanners<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue....<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue.
Also note that this repository is intended for reporting issues with packages.
For other components, separate issue trackers exist:
* Installer issues: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
* Infrastructure issues: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues
* Initramfs issues: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues
-->
## Package Information
* Package name: *py3-cryptography*
* Package version: *41.0.7-r0*
* Alpine version: *3.19.1*
* Alpine architecture: *aarch64*
## Summary
CVE-2023-50782 and CVE-2024-26130 are within the current version not fixed. We would need to update at least to 42.0.4, so that CVE scanners are happy. Latest version currently is 42.0.5Duncan BellamyDuncan Bellamyhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/79Establish a policy in case of aports developer inactivity2024-03-02T10:02:34ZPatrycja Rosaalpine@ptrcnull.meEstablish a policy in case of aports developer inactivityvaguely inspired by https://wiki.gentoo.org/wiki/Project:Retirement:
> **Inactivity retirement.** Happens after roughly 12-16 months of inactivity and four warning mails. The exact timeline and process depends on the developer's prior ac...vaguely inspired by https://wiki.gentoo.org/wiki/Project:Retirement:
> **Inactivity retirement.** Happens after roughly 12-16 months of inactivity and four warning mails. The exact timeline and process depends on the developer's prior activity and current situation.
currently we have 24 members of the Developers team. of those, 5 haven't been seen since 2020, some spanning all the way back to 2018, and one [not having any recorded activity since the migration to GitLab][1]; and yet, they hold full commit rights to aports, and could push changes at any time
[1]: https://gitlab.alpinelinux.org/Shizhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15718release checklist 3.19.12024-01-26T21:26:20ZNatanael Coparelease checklist 3.19.1* [x] check that kernel version are in sync (eg linux-lts and linux-rpi)
* [x] check that raspberrypi-bootloader is up-to-date
* [x] create new milestone https://gitlab.alpinelinux.org/groups/alpine/-/milestones
* [x] change milestone to...* [x] check that kernel version are in sync (eg linux-lts and linux-rpi)
* [x] check that raspberrypi-bootloader is up-to-date
* [x] create new milestone https://gitlab.alpinelinux.org/groups/alpine/-/milestones
* [x] change milestone to version-next on all unresolved issues
* [x] set version in main/alpine-base. see git log for commit message format
* [x] `git tag -a <version>`
* [x] before git push, verify that builders are idle. don’t push until they are
* [x] `git push && git push --tags`
* [x] write release notes and publish on alpinelinux.org
* [x] update alpine-mksite/alpine-releases.conf.yaml
* [x] verify that builders complete the release build successfully (check if release is uploaded to dl-master)
* [x] sign releases
* [x] make docker image release PR
* [ ] publish cloud images
* [x] update topic in IRC channels
* [x] update https://wiki.alpinelinux.org/wiki/Template:AlpineLatest
* [x] send release announcement to ~alpine/announce@lists.alpinelinux.org
* [x] post a tweet (https://tweetdeck.twitter.com)
* [x] post a toot (https://fosstodon.org/)
* [ ] Celebratehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15699bootstrap fail on musl-dev2024-01-20T00:00:25ZPopobootstrap fail on musl-devI use bootstrap.sh in aport, after long time to build tool, I got error.
export BARCH=arm-linux;CBUILDROOT=\~/sysroot-$BARCH \~/aports/scripts/bootstrap.sh $BARCH
any suggestion ?
```plaintext
Executing busybox-1.36.1-r15.trigger
OK: ...I use bootstrap.sh in aport, after long time to build tool, I got error.
export BARCH=arm-linux;CBUILDROOT=\~/sysroot-$BARCH \~/aports/scripts/bootstrap.sh $BARCH
any suggestion ?
```plaintext
Executing busybox-1.36.1-r15.trigger
OK: 1184 MiB in 495 packages
(1/1) Purging .hostdepends-binutils-unknown (20240119.213324)
OK: 0 MiB in 0 packages
>>> binutils-unknown: Updating the main/armhf repository index...
>>> binutils-unknown: Signing the index...
>>> musl-dev: Building main/musl-dev 1.2.4_git20230717-r5 (using abuild 3.12.0-r0) started Sat, 20 Jan 2024 06:59:26 +0800
>>> musl-dev: Checking sanity of /home/admin/aports/main/musl/APKBUILD...
>>> musl-dev: Analyzing dependencies...
>>> musl-dev: Installing for build:
fetch http://alpine.ccns.ncku.edu.tw/alpine/v3.19/main/armhf/APKINDEX.tar.gz
fetch http://alpine.ccns.ncku.edu.tw/alpine/v3.19/community/armhf/APKINDEX.tar.gz
fetch http://alpine.cs.nycu.edu.tw/v3.19/main/armhf/APKINDEX.tar.gz
fetch http://alpine.cs.nycu.edu.tw/v3.19/community/armhf/APKINDEX.tar.gz
WARNING: creating empty virtual package
(1/1) Installing .makedepends-musl-dev (20240119.225946)
OK: 1184 MiB in 496 packages
>>> musl-dev: Installing for host:
WARNING: opening /home/admin/packages//main: No such file or directory
WARNING: creating empty virtual package
(1/1) Installing .hostdepends-musl-dev (20240119.225948)
OK: 0 MiB in 1 packages
>>> musl-dev: Cleaning up srcdir
>>> musl-dev: Cleaning up pkgdir
>>> musl-dev: Cleaning up tmpdir
>>> musl-dev: Fetching musl-83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz::https://git.musl-libc.org/cgit/musl/snapshot/83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1040k 100 1040k 0 0 191k 0 0:00:05 0:00:05 --:--:-- 239k
>>> musl-dev: Fetching musl-83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz::https://git.musl-libc.org/cgit/musl/snapshot/83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz
>>> musl-dev: Checking sha512sums...
musl-83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz: OK
handle-aux-at_base.patch: OK
remove-dns-63-records-limit.patch: OK
0001-elf.h-add-typedefs-for-Elf-_Relr.patch: OK
0002-remove-non-prototype-declaration-of-basename-from-st.patch: OK
ldconfig: OK
__stack_chk_fail_local.c: OK
getconf.c: OK
getent.c: OK
iconv.c: OK
>>> musl-dev: Unpacking /var/cache/distfiles/musl-83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz...
>>> musl-dev: handle-aux-at_base.patch
patching file src/env/__init_tls.c
Hunk #1 succeeded at 72 (offset 6 lines).
Hunk #2 succeeded at 84 (offset 5 lines).
>>> musl-dev: remove-dns-63-records-limit.patch
patching file src/network/dns_parse.c
>>> musl-dev: 0001-elf.h-add-typedefs-for-Elf-_Relr.patch
patching file include/elf.h
>>> musl-dev: 0002-remove-non-prototype-declaration-of-basename-from-st.patch
patching file include/string.h
>>> musl-dev: Entering fakeroot...
make: Nothing to be done for 'install-headers'.
>>> musl-dev*: Running postcheck for musl-dev
find: /home/admin/aports/main/musl/pkg/musl-dev: No such file or directory
find: /home/admin/aports/main/musl/pkg/musl-dev: No such file or directory
find: /home/admin/aports/main/musl/pkg/musl-dev: No such file or directory
find: /home/admin/aports/main/musl/pkg/musl-dev: No such file or directory
find: /home/admin/aports/main/musl/pkg/musl-dev: No such file or directory
/home/admin/aports/main/musl/pkg/musl-dev (No such file or directory)
>>> musl-dev*: Preparing package musl-dev...
/usr/bin/abuild: cd: line 2642: can't cd to /home/admin/aports/main/musl/pkg/musl-dev: No such file or directory
>>> ERROR: musl-dev*: prepare_package failed
>>> ERROR: musl-dev: rootpkg failed
>>> musl-dev: Uninstalling dependencies...
(1/1) Purging .makedepends-musl-dev (20240119.225946)
OK: 1184 MiB in 495 packages
(1/1) Purging .hostdepends-musl-dev (20240119.225948)
OK: 0 MiB in 0 packages
alpine-rpi:~$ uname -ar
Linux alpine-rpi 6.6.12-0-rpi #1-Alpine Wed Jan 17 15:24:31 UTC 2024 armv6l Linux
alpine-rpi:~$ ls -alt /var/cache/distfiles/
total 27192
drwxrwxrwx 2 root abuild 4096 Jan 20 06:59 .
-rw-r--r-- 1 admin admin 1065537 Jan 20 06:59 musl-83b858f83b658bd34eca5d8ad4d145f673ae7e5e.tar.gz
-rw-r--r-- 1 admin admin 26765692 Jan 20 04:35 binutils-2.41.tar.xz
drwxr-xr-x 8 root root 4096 Jan 20 02:21 ..
alpine-rpi:~$
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15634Include SUPPORT_END in /etc/os-release2024-02-21T13:26:16ZMatthew SloweInclude SUPPORT_END in /etc/os-releaseIt would be really helpful for system integrators to have easy access to End Of Support dates in a programattic way.
`systemd` r252 added support [ref](https://newreleases.io/project/github/systemd/systemd/release/v252) for the `SUPPORT...It would be really helpful for system integrators to have easy access to End Of Support dates in a programattic way.
`systemd` r252 added support [ref](https://newreleases.io/project/github/systemd/systemd/release/v252) for the `SUPPORT_END` value in `/etc/os-release`:
```
* os-release gained a new field SUPPORT_END=YYYY-MM-DD to inform the
user when their system will become unsupported.
```
I realise Alpine Linux doesn't use `systemd` however the convention exists and would be useful.
[manpage for this](https://www.man7.org/linux/man-pages/man5/os-release.5.html) includes:
```
SUPPORT_END=
The date at which support for this version of the OS ends.
(What exactly "lack of support" means varies between vendors,
but generally users should assume that updates, including
security fixes, will not be provided.) The value is a date in
the ISO 8601 format "YYYY-MM-DD", and specifies the first day
on which support is not provided.
For example, "SUPPORT_END=2001-01-01" means that the system
was supported until the end of the last day of the previous
millennium.
Added in version 252.
```
Could this be included in the non-edge release files?Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15554package dependency: Composer force install older PHP2024-03-25T21:41:38Zmem76package dependency: Composer force install older PHPAs of the release of Alpine Linux 3.19 the package `composer` has a hard dependency on php82, and unnecessarily installs php82 when it it runable with php83
Installed PHP packages:
- php82
- php82-common
- php82-curl
- php82-iconv
- p...As of the release of Alpine Linux 3.19 the package `composer` has a hard dependency on php82, and unnecessarily installs php82 when it it runable with php83
Installed PHP packages:
- php82
- php82-common
- php82-curl
- php82-iconv
- php82-mbstring
- php82-openssl
- php82-phar
- php82-zip
Request: Have the composer package dependent on `php82 || php83`, or if the package system do not support this create two version. One for PHP 8.2 and one for PHP8.3.Dave HallDave Hallhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15546release checklist for 3.19.02023-12-18T10:36:43ZNatanael Coparelease checklist for 3.19.0* [x] check that kernel version are in sync (eg linux-lts and linux-rpi)
* [x] verify that the following packages are up-to-date (no release candidates):
- [x] abuild
- [x] mkinitfs
- [x] alpine-conf
- [x] mdev-conf
* [x] check t...* [x] check that kernel version are in sync (eg linux-lts and linux-rpi)
* [x] verify that the following packages are up-to-date (no release candidates):
- [x] abuild
- [x] mkinitfs
- [x] alpine-conf
- [x] mdev-conf
* [x] check that raspberrypi-bootloader is up-to-date
* [x] create new milestone https://gitlab.alpinelinux.org/groups/alpine/-/milestones
* [x] change milestone to version-next on all unresolved issues
* [x] create a release notes draft
* [x] set version in main/alpine-base. see git log for commit message format
* [x] `git tag -a <version>`
* [x] before git push, verify that builders are idle. don’t push until they are
* [x] `git push && git push origin <version>`
* [x] For new stable branch
* [x] create new remote stable branch: `git checkout -b 3.19-stable && git push --set-upstream origin 3.19-stable`
* [x] on each builder do:
* [x] `cd ~/aports && git fetch origin && git checkout -b 3.19-stable -t origin/3.19-stable`
* [x] `doas sed -i -e 's/git_branch=master/git_branch=3.19-stable/' /etc/conf.d/mqtt-exec.aports-build`
* [x] Wait til build server is idle
* [x] reboot
* [x] write release notes and publish on alpinelinux.org
* [x] update alpine-mksite/alpine-releases.conf.yaml
* [x] change the latest-stable symlink on dl-master.alpinelinux.org
* [x] verify that builders complete the release build successfully (check if release is uploaded to dl-master)
* [x] sign releases
* [x] make docker image release PR (https://github.com/docker-library/official-images)
* [x] update topic in IRC channels
* [x] send release announcement to <~alpine/announce@lists.alpinelinux.org>
* [x] Make sure pkgs.alpinelinux.org syncs the new release
* [x] Invalidate /alpine/latest-stable/* on dl-cdn
* [x] post a tweet (https://tweetdeck.twitter.com)
* [x] post a toot (https://fosstodon.org/home)
* [x] alpine cloud images
* [x] Celebrate 🎉https://gitlab.alpinelinux.org/alpine/aports/-/issues/15503Release Notes for 3.192023-12-07T12:17:23ZCarl ChaveRelease Notes for 3.19Not sure how release notes are usually updated so feel free to close this whenever, but, I noticed in IRC:
> 2023-11-19 15:03:08 dari https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0 looks short, no drastic changes? :)
...Not sure how release notes are usually updated so feel free to close this whenever, but, I noticed in IRC:
> 2023-11-19 15:03:08 dari https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0 looks short, no drastic changes? :)
One thing that might need to be mentioned is the perl upgrade to 5.38:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/485743.19.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15472package request: llvm-bolt2023-11-15T21:45:45ZAlexander Zaitsevpackage request: llvm-boltLLVM BOLT is a binary optimizer - a tool that optimizes your program after the compilation process. More information about that you can read at https://research.facebook.com/publications/bolt-a-practical-binary-optimizer-for-data-centers...LLVM BOLT is a binary optimizer - a tool that optimizes your program after the compilation process. More information about that you can read at https://research.facebook.com/publications/bolt-a-practical-binary-optimizer-for-data-centers-and-beyond. Applying BOLT to the binaries helps with achieving better performance for different applications - more information about that you can find at https://gitlab.alpinelinux.org/alpine/aports/-/issues/15465 .
Other distros like Fedora and Solus already provide `llvm-bolt` in their repositories: https://repology.org/project/llvm-bolt/versions.
Since LLVM BOLT is a [part](https://github.com/llvm/llvm-project/blob/main/bolt/README.md) of the LLVM project, it can be built by "simply" enabling `bolt` project during CMake configuration.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15341Python 3.122024-03-28T01:43:33ZAndy PostnikovPython 3.12New release https://docs.python.org/3.12/whatsnew/3.12.htmlNew release https://docs.python.org/3.12/whatsnew/3.12.html3.20.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15260New architecture LoongArch64 porting2023-09-12T01:53:58ZJingyun HuaNew architecture LoongArch64 portingHi all,
The purpose of creating this issue is to discuss with the community the addition of the new architecture LoongArch port to the aports project.
In March this year, we began to transplant the alpine Linux edge version (commit: 31...Hi all,
The purpose of creating this issue is to discuss with the community the addition of the new architecture LoongArch port to the aports project.
In March this year, we began to transplant the alpine Linux edge version (commit: 31aac06d3eaf0ff86c42eb5e4793fd9215fd3c79) on the LoongArch64 platform. The transplantation status at that time was: the bootstrap process was completed, minirootfs was built and produced, and the basic system construction of Alpine Linux was completed locally. Considering that the upstream of musl does not yet support the LoongAarch64 architecture, so we paused after building about 12000 apk packages.
Recently, the musl community mail has received new feedback on LoongArch64 architecture support. Judging from the feedback, the patch is basically qualified. Therefore, I recently built the alpine system based on the community's latest aports source code. The bootstrap phase is currently about to be completed. In this build, I'm using the latest patch for musl from loongarch64's upstream commit 0001-add-loongarch64-port-v7.patch (https://www.openwall.com/lists/musl/2023/04/18/1).
And I have one questions want to discuss:
Can we submit LoongArch64 support for aports before musl upstream doesn't support LoongArch64?
We very much hope to share our results with the community and look forward to contributing to the alpine community. After the above questions are solved, I think we can make an aports porting plan.Thanks!
A bit of introduction on the LoongArch:
1、Introduction
LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V. LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit version (LA32S) and a 64-bit version (LA64).
Loongson and LoongArch documentations:
https://github.com/loongson/LoongArch-Documentation
2、Upstream software supports LoongArch
Kernel、Gcc、Glibc、Binutils、Gdb、Llvm、Rust、Golang have merged by upstream(github) projects and so on.
For examples,
Kernel: https://www.kernel.org/doc/html/latest/
Gcc: https://gcc.gnu.org/gcc-12/changes.html
Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html
Gdb: https://sourceware.org/gdb/
Binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch
Llvm: https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target
Rust: https://github.com/rust-lang/rust
Golang: https://go.dev/doc/go1.19
3、operating systems supports LoongArch
debian: https://wiki.debian.org/Ports/loong64
gentoo: https://wiki.gentoo.org/wiki/Project:LoongArch
archlinux: https://loongarchlinux.org/
fedora:https://github.com/fedora-remix-loongarchhttps://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/45Cannot import zroot": a pool with that name already exists, still boots2023-08-23T20:59:58ZJulie KoubováCannot import zroot": a pool with that name already exists, still bootsHey, I'm getting these messages during boot (before OpenRC starts) and they are bothering me a little. The system boots normally. It seems like it is a known issue (!78). Does anyone understand the root cause? How could this be fixed?
...Hey, I'm getting these messages during boot (before OpenRC starts) and they are bothering me a little. The system boots normally. It seems like it is a known issue (!78). Does anyone understand the root cause? How could this be fixed?
```
cannot import '0123456789abdcdefguid': a pool with that name already exists
use the form 'zroot import <pool | id> <newpool>' to give it a new name
cannot import 'zroot': a pool with that name already exists
use the form 'zroot import <pool | id> <newpool>' to give it a new name
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15193HashiCorp license change2023-11-27T10:00:32ZLeon MarzHashiCorp license changeHashiCorp just changed the license of its software to the Business Source License 1.1 (SPDX identifier `BUSL-1.1`) [[1]](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license)[[2]](https://www.hashicorp.com/license-faq)...HashiCorp just changed the license of its software to the Business Source License 1.1 (SPDX identifier `BUSL-1.1`) [[1]](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license)[[2]](https://www.hashicorp.com/license-faq)[[3]](https://www.hashicorp.com/bsl). This change affects:
- community/terraform
- community/packer
- community/vault
- community/consul
- community/nomad
As a [not-yet-member of the-not-yet-official license team](https://gitlab.alpinelinux.org/alpine/tsc/-/issues/6), I would like to try to clarify the new license a bit:
__The new license is not open source.__
On the SPDX license page [[4]](https://spdx.org/licenses/BUSL-1.1.html), the notes clearly states:
> The Business Source License [...] is not an Open Source license.
This sentence also appears on the MariaDB page of the license [[5]](https://mariadb.com/bsl11/), who created it in the first place.
Fedora gives further evidence, as this license is in the list of Not-Allowed Licenses [[6]](https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/).
---
> The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work.
The word that makes this license not opensource is `non-production`, which violates point 6 of the OSD [[7]](https://opensource.org/osd/) as well as the proposed Alpine license policy [[8]](https://gitlab.alpinelinux.org/lmarz/license-policy/-/blob/main/policy.md) "No Discrimination Against Fields of Endeavor". Production is a part of a Field of Endeavor, often a business.
In conclusion, I don't think we can allow the new versions of HashiCorps software in aports. I would suggest to not update these packages as long as no one complains, since the current versions are still open source. When the demand gets high we could switch to forks which are still active and look like they might be further maintained.
---
[1] https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
[2] https://www.hashicorp.com/license-faq
[3] https://www.hashicorp.com/bsl
[4] https://spdx.org/licenses/BUSL-1.1.html
[5] https://mariadb.com/bsl11/
[6] https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/
[7] https://opensource.org/osd/
[8] https://gitlab.alpinelinux.org/lmarz/license-policy/-/blob/main/policy.md3.19.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15135Dnsmasq[1] config error is REFUSED (EDE: not ready) for dnsmasq version > 2.8...2023-09-06T13:42:03ZPurushotham PDnsmasq[1] config error is REFUSED (EDE: not ready) for dnsmasq version > 2.85-r3When we upgrade dnsmasq to `2.89-r3` on `alpine 3.18` our docker container has stopped responding and showing error message as `config error is REFUSED (EDE: not ready)`. But if we try using dnsmasq version `2.85-r3` our docker container...When we upgrade dnsmasq to `2.89-r3` on `alpine 3.18` our docker container has stopped responding and showing error message as `config error is REFUSED (EDE: not ready)`. But if we try using dnsmasq version `2.85-r3` our docker container is responding and working good. We are supposed to use `2.89-r3` version to avoid vulnerabilities.
Can someone please help us resolve this blocking issue?https://gitlab.alpinelinux.org/alpine/tsc/-/issues/68Differentiate different "tiers" of architecture support2024-02-05T20:38:43ZSören TempelDifferentiate different "tiers" of architecture supportThis came up in the TSC meeting on the 27th of April while discussing #66. In this meeting, a proposal was made to differentiate different tiers of architecture support (similar to [Rust's platform support](https://doc.rust-lang.org/nigh...This came up in the TSC meeting on the 27th of April while discussing #66. In this meeting, a proposal was made to differentiate different tiers of architecture support (similar to [Rust's platform support](https://doc.rust-lang.org/nightly/rustc/platform-support.html)) were some architectures (ideally the less popular ones) are only supported on a “best-effort” basis. For architectures of a lower tier we may also only support the latest -stable release. This issue exists to gather comments on this proposal and to ensure that we pick-up this discussion again at some point.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10887feature to keep old/previous package when upgrading kernel2024-02-23T12:28:43ZNatanael Copafeature to keep old/previous package when upgrading kernelTwo problems:
- when kernel package is upgraded, modprobe will stop working til machine is rebooted, because old kernel modules were deleted.
- it would be nice to keep old kernel around for a while, in case new kernel is broken. For ex...Two problems:
- when kernel package is upgraded, modprobe will stop working til machine is rebooted, because old kernel modules were deleted.
- it would be nice to keep old kernel around for a while, in case new kernel is broken. For example as `/boot/vmlinuz-lts.old`
Possible solution:
We could have a virtual `.old` or `.previous` package. When flagged packages (`linux-lts`would have a flag of some sort) apk would on upgrade transfer ownership of the old package to this virtual package. Files that would be deleted are kept, and files that would be replaced could get a `.old` suffix.
The result would be that `/lib/modules/<old-version>` are transferred to virtual `linux-lts.old`, and `/boot/vmlinuz-lts` are kept as `/boot/vmlinuz-lts.old`. User can then chose to keep this til next time linux-lts is upgraded or for example clean up .old as last step during bootup. (for example `apk del '*.old'` or similar)
This way `modprobe` will continue work after an `apk upgrade` and user can have a vmlinuz-lts.old fallback in boot loader in case new kernel is broken.
Any package could be flagged with 'keep-old' but I think it mostly makes sense for linux kernels.backloghttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14704linux-lts 5.15.99-r0 (amd64) fails to boot on ThinkPad X2202023-03-13T18:25:40ZKalle A. Sandströmksandstr@iki.filinux-lts 5.15.99-r0 (amd64) fails to boot on ThinkPad X220Bootup fails at "Loading hardware drivers..." with a blank display. Backlight is on. System doesn't respond to any ctrl-alt console switching combination. Magic SysRq does work for causing a system reboot.
Bug previously absent in ~~5.1...Bootup fails at "Loading hardware drivers..." with a blank display. Backlight is on. System doesn't respond to any ctrl-alt console switching combination. Magic SysRq does work for causing a system reboot.
Bug previously absent in ~~5.15.90~~ 5.15.94.
There is another error message during bootup from the script that prints "Setting console font [ter-120b.psf.gz] ...", which reads "setfont: ERROR kdfontop.c:151 put_font_kdfontop: ioctl(KDFONTOP): Invalid argument", followed by "ERROR: consolefont failed to start". This suggests something broke in framebuffer console support for the Sandy Bridge platform in between LTS patch revisions.
**Fixed** by 5.15.102-r0 at the latest.Natanael CopaNatanael Copa