alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2023-02-27T01:03:25Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14646rc-service xenqemu status * status: stopped2023-02-27T01:03:25ZPredrag Punosevacrc-service xenqemu status * status: stopped```
gpu5:/var/log# uname -a
Linux gpu5.int.autonlab.org 5.15.94-0-lts #1-Alpine SMP Thu, 16 Feb 2023 21:49:19 +0000 x86_64 Linux
```
```
gpu5:/var/log# apk info|grep xen
xen-libs
xen
xen-hypervisor
xen-qemu
xen-doc
```
```
gpu5:/var/...```
gpu5:/var/log# uname -a
Linux gpu5.int.autonlab.org 5.15.94-0-lts #1-Alpine SMP Thu, 16 Feb 2023 21:49:19 +0000 x86_64 Linux
```
```
gpu5:/var/log# apk info|grep xen
xen-libs
xen
xen-hypervisor
xen-qemu
xen-doc
```
```
gpu5:/var/log# rc-status|grep xen
xenstored [ started ]
xenconsoled [ crashed ]
xenqemu [ crashed ]
```
I am having a hard time with Xen Dom0 fresh installation. The only thing that I see is this in the log files
`Feb 20 18:32:13 gpu5 daemon.info init: process '/sbin/getty -L 0 hvc0 vt100' (pid 5648) exited. Scheduling for restart`
Sure enough a working Dom0 has this
```
xen1:/dev# ls -l /dev/hv*
crw--w---- 1 root root 229, 0 Feb 20 15:30 /dev/hvc0
crw-rw---- 1 root root 229, 1 Feb 20 15:30 /dev/hvc1
crw-rw---- 1 root root 229, 2 Feb 20 15:30 /dev/hvc2
crw-rw---- 1 root root 229, 3 Feb 20 15:30 /dev/hvc3
crw-rw---- 1 root root 229, 4 Feb 20 15:30 /dev/hvc4
crw-rw---- 1 root root 229, 5 Feb 20 15:30 /dev/hvc5
crw-rw---- 1 root root 229, 6 Feb 20 15:30 /dev/hvc6
crw-rw---- 1 root root 229, 7 Feb 20 15:30 /dev/hvc7
```
while the one which keeps crashing on the boot has this
```
gpu5:/dev# ls -l /dev/hv*
ls: /dev/hv*: No such file or directory
```
So it indeed looks like mkinitrd didn't not create '/dev/hvc0' console device inside initrd.
I was able to fix missing hvc terminal device by editing '/etc/inittab' file. This exposed by real problem which is 'xenstored' crash. Please see below
```
Feb 20 21:12:38 gpu5 user.debug : Will stop /usr/lib/xen/bin/qemu-system-i386
Feb 20 21:12:38 gpu5 daemon.err /etc/init.d/xenqemu[15539]: start-stop-daemon: no matching processes found
Feb 20 21:12:38 gpu5 user.debug : Will stop /usr/sbin/xenconsoled
Feb 20 21:12:38 gpu5 user.debug : Will stop PID 5489
Feb 20 21:12:38 gpu5 daemon.err /etc/init.d/xenconsoled[15561]: start-stop-daemon: no matching processes found
Feb 20 21:12:38 gpu5 user.debug : Will stop /usr/sbin/sshd
Feb 20 21:12:38 gpu5 user.debug : Will stop PID 4598
Feb 20 21:12:38 gpu5 user.debug : Sending signal 15 to PID 4598
Feb 20 21:12:38 gpu5 auth.info sshd[4598]: Received signal 15; terminating.
Feb 20 21:12:38 gpu5 user.debug : Will stop /usr/sbin/ntpd
Feb 20 21:12:38 gpu5 user.debug : Will stop PID 4557
Feb 20 21:12:38 gpu5 user.debug : Sending signal 15 to PID 4557
Feb 20 21:12:38 gpu5 daemon.warn /etc/init.d/xenstored[15665]: Xenstore can not be stopped
Feb 20 21:12:38 gpu5 user.debug : Will stop /usr/sbin/crond
Feb 20 21:12:38 gpu5 user.debug : Will stop PID 4498
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/14652"sh: out of range" error message when installing certain packages.2023-02-22T09:54:21ZShyam Sunder"sh: out of range" error message when installing certain packages.I've been noticing a strange error message pop up when adding certain packages (namely `postgresql14-client`, but there might be others) inside a docker container.
Command:
```
apk --no-cache add postgresql14-client
```
Response:
```s...I've been noticing a strange error message pop up when adding certain packages (namely `postgresql14-client`, but there might be others) inside a docker container.
Command:
```
apk --no-cache add postgresql14-client
```
Response:
```shell
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
(1/6) Installing postgresql-common (1.1-r3)
Executing postgresql-common-1.1-r3.pre-install
(2/6) Installing libpq (15.2-r0)
(3/6) Installing ncurses-terminfo-base (6.3_p20221119-r0)
(4/6) Installing ncurses-libs (6.3_p20221119-r0)
(5/6) Installing readline (8.2.0-r0)
(6/6) Installing postgresql14-client (14.7-r0)
Executing busybox-1.35.0-r29.trigger
Executing postgresql-common-1.1-r3.trigger
* Setting postgresql14 as the default version
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.17/main: No such file or directory
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.17/community: No such file or directory
sh: out of range
OK: 11 MiB in 21 packages
```
Note that despite the error message, the package does install fine, and I'm able to run its installed binaries (namely `pg_dump`) just fine.
I have confirmed that this issue can be reproduced on the `v3.15`, `v3.16`, `v3.17`, `edge`, and `latest` tags of the official Alpine Linux Docker images. Note that other packages, such as `apk --no-cache add bash` don't seem to generate this message.
Judging by the nature of the error, I'm suspecting that this is an error in APK, but let me know if this should bug be opened on the postgres package instead.Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14657[Package request: ly (display manager)2023-12-08T12:45:57ZTim[Package request: ly (display manager)https://github.com/fairyglade/ly
Ly is a lightweight TUI (ncurses-like) display manager for Linux and BSD.https://github.com/fairyglade/ly
Ly is a lightweight TUI (ncurses-like) display manager for Linux and BSD.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14662community/dino: Dino segfaults within two seconds.2023-02-27T23:36:54ZHugo Barreracommunity/dino: Dino segfaults within two seconds.I ran dino, set up an account, and it quickly segfaulted.
Now running `dino` segfaults within two seconds of starting.I ran dino, set up an account, and it quickly segfaulted.
Now running `dino` segfaults within two seconds of starting.Galen AbellGalen Abellhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10881slightly bizarre add/upgrade behaviour2023-03-01T12:56:16ZGhost Userslightly bizarre add/upgrade behaviouri don't have a good reproduction for this. what happens is:
- there is a prebuilt CI image that has some 'older' version of a package installed. in this case, the ncurses libraries.
- a CI run starts
- the image runs `apk update`. and t...i don't have a good reproduction for this. what happens is:
- there is a prebuilt CI image that has some 'older' version of a package installed. in this case, the ncurses libraries.
- a CI run starts
- the image runs `apk update`. and there are newer versions of the things already installed.
- the image then does `apk add` of a bunch of stuff that isn't already in `world`.
and it fails with:
```
ERROR: unable to select packages:
ncurses-terminfo-base-6.4_p20230218-r3:
breaks: libmenuw-6.4_p20230225-r0[ncurses-terminfo-base=6.4_p20230225-r0]
libformw-6.4_p20230225-r0[ncurses-terminfo-base=6.4_p20230225-r0]
satisfies: libpanelw-6.4_p20230218-r3[ncurses-terminfo-base=6.4_p20230218-r3]
libncursesw-6.4_p20230218-r3[ncurses-terminfo-base=6.4_p20230218-r3]
libncursesw-6.4_p20230218-r3:
breaks: ncurses-dev-6.4_p20230225-r0[libncursesw=6.4_p20230225-r0]
satisfies: python3-3.11.2-r0[so:libncursesw.so.6]
gettext-libs-0.21.1-r1[so:libncursesw.so.6]
libpanelw-6.4_p20230218-r3[so:libncursesw.so.6]
libmenuw-6.4_p20230225-r0[so:libncursesw.so.6]
pinentry-1.2.1-r0[so:libncursesw.so.6]
readline-8.2.001-r0[so:libncursesw.so.6]
libedit-20221030.3.1-r0[so:libncursesw.so.6]
libformw-6.4_p20230225-r0[so:libncursesw.so.6]
libpanelw-6.4_p20230218-r3:
breaks: ncurses-dev-6.4_p20230225-r0[libpanelw=6.4_p20230225-r0]
satisfies: python3-3.11.2-r0[so:libpanelw.so.6]
```
but, if the `apk add bunch of stuff` is preceded by `apk upgrade`, no errors happen. i don't know what causes this.
to be clear, i don't think there is anything invalid at all in the above packaging. the apkbuild for ncurses is [this](https://git.alpinelinux.org/aports/tree/main/ncurses/APKBUILD?id=0ad370efb53b5a388e82b62b21ec8733b34a7aad). strictly speaking, nothing actually conflicts here (between files/paths), upgrades work fine, etc. the failing CI job is https://gitlab.freedesktop.org/emersion/wlroots/-/jobs/37107011 .
once the CI image 'gets regenerated' so the already-installed packages are the same as the ones in the repositories, everything works fine. at that point, merely bumping the pkgrel with no changes on the above ncurses packages will get the same failure again, on starting the image and running `apk add some stuff`.
this /did/ work before. i think this is a regression in 2.12.11, but i can't point to anything because i don't have a good reproduction setup for this..
of course, merely running `upgrade` first fixes it, but as i understand it the mere `add` should also work?https://gitlab.alpinelinux.org/alpine/aports/-/issues/14666ttyUSB0 assigned to group root with chmod 6002023-09-22T14:18:22ZMarek SierocińskittyUSB0 assigned to group root with chmod 600Hello,
I have installed Alpine 3.14 armhf on a legacy piece of hardware called Pandaboard. Everything works fine except ttyUSB0. When I'm connecting my 3D printer, dmesg shows correctly that ch341 is being used etc and in the end /dev/tt...Hello,
I have installed Alpine 3.14 armhf on a legacy piece of hardware called Pandaboard. Everything works fine except ttyUSB0. When I'm connecting my 3D printer, dmesg shows correctly that ch341 is being used etc and in the end /dev/ttyUSB0 is created. Looking at /etc/mdev.conf, in theory it should be 660 root:dialout, but for some unknown for me reason it's 600 root:root. Of course manually changing it to 660 root:tty makes both avrdude and Octoprint works fine, but it's not an option to manually change it each time on system boot...
Could someone give me a hand with it?
Br,
Marekhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10095package() step getting corrumpted file2023-06-03T04:00:59ZFabricio Silvahi@fabricio.devpackage() step getting corrumpted fileConsider this APKBUILD https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44628/diffs#929507b7288ff63088918552e2a55a9ff5a2e0e6
When I do `abuild -r` or `abuild rootpkg` its generating/copying a corrupted file from my build() ...Consider this APKBUILD https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44628/diffs#929507b7288ff63088918552e2a55a9ff5a2e0e6
When I do `abuild -r` or `abuild rootpkg` its generating/copying a corrupted file from my build() step.
```bash
alpine:~/aports/testing/recyclarr$ abuild rootpkg
>>> recyclarr: Entering fakeroot...
>>> recyclarr*: Running postcheck for recyclarr
>>> recyclarr*: Preparing package recyclarr...
>>> recyclarr*: Stripping binaries
>>> recyclarr*: Scanning shared objects
>>> recyclarr*: Tracing dependencies...
dotnet7-runtime
so:libc.musl-x86_64.so.1
so:libgcc_s.so.1
so:libstdc++.so.6
>>> recyclarr*: Package size: 2.0 KB
>>> recyclarr*: Compressing data...
>>> recyclarr*: Create checksum...
>>> recyclarr*: Create recyclarr-4.3.0-r0.apk
alpine:~/aports/testing/recyclarr$ ls -la pkg/recyclarr/usr/sbin/
total 58
drwxr-xr-x 2 fabricio fabricio 3 Feb 28 09:25 .
drwxr-sr-x 3 fabricio fabricio 3 Feb 28 09:25 ..
-rwxr-xr-x 1 fabricio fabricio 78320 Feb 28 09:25 recyclarr
```
(look to the file size 78320)
But If you do the manually steps, I can see that until the `abuild build` step, my binary is right there and has correct size (and it works if I execute it)
```bash
alpine:~/aports/testing/recyclarr$ abuild unpack
>>> recyclarr: Fetching recyclarr-4.3.0.tar.gz::https://github.com/recyclarr/recyclarr/archive/refs/tags/v4.3.0.tar.gz
>>> recyclarr: Checking sha512sums...
recyclarr-4.3.0.tar.gz: OK
0001-disable-gitversion.patch: OK
>>> recyclarr: Unpacking /var/cache/distfiles/recyclarr-4.3.0.tar.gz...
alpine:~/aports/testing/recyclarr$ abuild prepare
>>> recyclarr: 0001-disable-gitversion.patch
patching file src/Directory.Build.props
patching file src/Recyclarr.Cli/Program.cs
Hunk #1 succeeded at 81 (offset -1 lines).
alpine:~/aports/testing/recyclarr$ abuild build
MSBuild version 17.4.1+fedecea9d for .NET
Determining projects to restore...
All projects are up-to-date for restore.
Recyclarr.Common -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/src/Recyclarr.Common/bin/Release/net7.0/Recyclarr.Common.dll
Recyclarr.TrashLib -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/src/Recyclarr.TrashLib/bin/Release/net7.0/Recyclarr.TrashLib.dll
Recyclarr.Cli -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/src/Recyclarr.Cli/bin/Release/net7.0/linux-musl-x64/recyclarr.dll
Recyclarr.Cli -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/publish/
alpine:~/aports/testing/recyclarr$ ls -la src/recyclarr-4.3.0/publish/
total 3734
drwxr-sr-x 2 fabricio fabricio 3 Feb 28 09:13 .
drwxr-sr-x 10 fabricio fabricio 23 Jan 22 20:51 ..
-rwxr-xr-x 1 fabricio fabricio 6561208 Feb 28 09:36 recyclarr
```
(look to the file size 6561208)
If I run the `abuild rootpkg` now it returns the first statement I show with wrong binary.
I have tried to touch the package() instructions, nothing have work yet. Any advise in what could Im doing wrong?https://gitlab.alpinelinux.org/alpine/aports/-/issues/14670libutempter install issues2023-03-08T10:19:47ZTed Pelas Johanssonlibutempter install issuesPackage is failing and not possible to resolve.
Unsure if there is only missing a backslash in the beginning of the path below, "/usr/" instead of "usr/"?
```
/ # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64...Package is failing and not possible to resolve.
Unsure if there is only missing a backslash in the beginning of the path below, "/usr/" instead of "usr/"?
```
/ # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
v3.17.2-102-gdf04f02cc86 [https://dl-cdn.alpinelinux.org/alpine/v3.17/main]
v3.17.2-108-g44ea995f846 [https://dl-cdn.alpinelinux.org/alpine/v3.17/community]
OK: 17812 distinct packages available
/ # apk add libutempter
(1/1) Installing libutempter (1.2.1-r5)
ERROR: Failed to set ownership on usr/lib/utempter/.apk.544d4e439f1324e2e470375a1f789468f7a2cb318e66e660: Invalid argument
1 error; 361 MiB in 85 packages
/ # apk fix -vi
The following packages will be reinstalled:
libutempter
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]?
(1/1) Reinstalling libutempter (1.2.1-r5)
ERROR: Failed to set ownership on usr/lib/utempter/.apk.544d4e439f1324e2e470375a1f789468f7a2cb318e66e660: Invalid argument
1 error; 85 packages, 1049 dirs, 16189 files, 361 MiB
/ # apk del libutempter
OK: 361 MiB in 84 packages
/ # apk add libutempter
(1/1) Installing libutempter (1.2.1-r5)
ERROR: Failed to set ownership on usr/lib/utempter/.apk.544d4e439f1324e2e470375a1f789468f7a2cb318e66e660: Invalid argument
1 error; 361 MiB in 85 packageshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14690antiquated ffmpeg4 porting list2023-12-21T02:40:06ZGhost Userantiquated ffmpeg4 porting list
- [ ] tvheadend (maybe ported in master)
- [ ] ppsspp-related-things (cannot use 5+ due to fundamental api difference, makes more sense to just vendor this one if it's the only one left)
- [ ] kodi (fixed next major version)
- [ ] moc (...
- [ ] tvheadend (maybe ported in master)
- [ ] ppsspp-related-things (cannot use 5+ due to fundamental api difference, makes more sense to just vendor this one if it's the only one left)
- [ ] kodi (fixed next major version)
- [ ] moc (abandoned project)
- [x] gifski (rust bindings)
- [ ] mediastreamer2 (no idea)
- [x] openmw (next version)
- [ ] vlc (next version (works currently without libva))https://gitlab.alpinelinux.org/alpine/aports/-/issues/14692community/rustup: Rustup pulls compilers that produce broken binaries2023-03-08T13:42:10ZHugo Barreracommunity/rustup: Rustup pulls compilers that produce broken binaries`rustup` allows pulling official (upstream) rust binaries, including nighties.
However, these nightlies produce binaries that SEGFAULT on Alpine. I've tried reporting this upstream, but haven't managed to get the attention of anyone kno...`rustup` allows pulling official (upstream) rust binaries, including nighties.
However, these nightlies produce binaries that SEGFAULT on Alpine. I've tried reporting this upstream, but haven't managed to get the attention of anyone knowledgeable on this:
- https://github.com/rust-lang/rust/issues/107566
- ~~https://github.com/rust-lang/rustup/issues/3113~~ Moved: https://github.com/rust-lang/rust/issues/108878
Additionally, anything linking to `openssl` also SEGFAULTs.
Obviously upstream-provided binaries aren't supported by Alpine (since they're built by someone else). However, `rustup` (who's sole purpose is to manage these binaries) is in the community repos, so my question here is: Does this work for anyone else? Do the above examples build and run?https://gitlab.alpinelinux.org/alpine/aports/-/issues/14697package request: stmp (subsonic terminal music player)2023-03-16T19:13:22ZTimpackage request: stmp (subsonic terminal music player)https://github.com/wildeyedskies/stmp
A terminal client for *sonic music servers. Inspired by ncmpcpp.https://github.com/wildeyedskies/stmp
A terminal client for *sonic music servers. Inspired by ncmpcpp.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14708zsh autocompletion for `pkill` produces garbage2023-03-13T05:37:38ZHugo Barrerazsh autocompletion for `pkill` produces garbage1. Run zsh with zsh-completion
2. Type `pkill ini<tab>`. Pick `init` from the autocompletion options.
The output is something like:
pkill \ \ \ \ 1\ root\ \ \ \ \ \ 0:01\ /sbin/init
It should be something like:
pkill init
I ...1. Run zsh with zsh-completion
2. Type `pkill ini<tab>`. Pick `init` from the autocompletion options.
The output is something like:
pkill \ \ \ \ 1\ root\ \ \ \ \ \ 0:01\ /sbin/init
It should be something like:
pkill init
I don't see any mention of `pkill` in `/usr/share/zsh/site-functions`, so I'm not sure where these completions are coming from. However, they're broken for busybox.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14709urfkill not usable out of the box2023-05-25T22:53:26ZRafael Avila de Espindolaurfkill not usable out of the boxAfter installing the package the log is full of
```
Mar 12 17:15:06 dell daemon.warn URfkill[2835]: <warning> Failed to write persistence data: Failed to create file “/usr/var/lib/urfkill/saved-states.QRBI11”: No such file or directory
`...After installing the package the log is full of
```
Mar 12 17:15:06 dell daemon.warn URfkill[2835]: <warning> Failed to write persistence data: Failed to create file “/usr/var/lib/urfkill/saved-states.QRBI11”: No such file or directory
```
Creating the directory /usr/var/lib/urfkill solves the problem, but the package should probably be configured to use /var, not /usr/var.
The next problem is:
```
Mar 12 19:46:23 dell daemon.warn URfkill[2832]: <warning> GetSeats Failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
```
which is fixed by installing consolekit2, it should probably be a dependency.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/63Appoint new security officer2023-04-12T10:54:56ZKevin DaudtAppoint new security officer@ariadne Stepped down as security officer, @team/security will need a new team lead.@ariadne Stepped down as security officer, @team/security will need a new team lead.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72New architecture LoongArch64 porting2024-03-02T01:51:59ZJingyun 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/tsc/-/issues/65Implement and support Matrix communication rooms/channels2024-02-04T22:14:13ZCarlo LandmeterImplement and support Matrix communication rooms/channelsMore and more projects outside but (in)directly involving Alpine Linux are switching to Matrix.
There has already been some requests for official Alpine Linux Matrix channels/rooms via social media.
Proposal:
* Implement an Alpine Linu...More and more projects outside but (in)directly involving Alpine Linux are switching to Matrix.
There has already been some requests for official Alpine Linux Matrix channels/rooms via social media.
Proposal:
* Implement an Alpine Linux Matrix server based on the second-generation Matrix homeserver [Dendrite](https://github.com/matrix-org/dendrite)
* Create rooms and link to its IRC counterpart on matrix.org OFTC IRC bridge (possible also on Libera)
* Setup a moderation team to help support the rooms
* Evaluate how to combat spam
* Define a policy who can have a alpinelinux.org matrix account
Known issues:
* [Dendrite](https://github.com/matrix-org/dendrite) is still in beta
* [matrix-appservice-irc]( https://github.com/matrix-org/matrix-appservice-irc) does currently not support automatic authentication and for some IRC channels its mandatory to communicateCarlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/77Add Celeste as developer2024-02-04T22:10:34Zomniomni+alpine@hack.orgAdd Celeste as developerSee https://git.alpinelinux.org/aports/log/?qt=author&q=Celeste :upside_down:
In addition to a large volume of quality commits, @Celeste is also pragmatic, friendly and helpful within the project.See https://git.alpinelinux.org/aports/log/?qt=author&q=Celeste :upside_down:
In addition to a large volume of quality commits, @Celeste is also pragmatic, friendly and helpful within the project.https://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/tsc/-/issues/64CET support and general compiler-based hardening2023-09-15T08:00:18ZjvoisinCET support and general compiler-based hardeningIt would be neat to have Alpine binaries built with [CET support](https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-introduction-intel-cet-844137.pdf) by default: it's supported on Intel hardware since [Tiger Lake...It would be neat to have Alpine binaries built with [CET support](https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-introduction-intel-cet-844137.pdf) by default: it's supported on Intel hardware since [Tiger Lake]( https://en.wikipedia.org/wiki/Tiger_Lake ) released in 2020 and AMD [Zen 3]( https://en.wikipedia.org/wiki/Zen_3 ) also released in 2020. CET provides strong control-flow guarantees (~killing [ROP]( https://en.wikipedia.org/wiki/Role-oriented_programming )) on supported hardware, and is equivalent to a `nop` on unsupported one.
- Ubuntu has it since [20.04LTS]( https://wiki.ubuntu.com/Security/Features#cf-protection ) (2020)
- Fedora has it since [Fedora 28]( https://fedoraproject.org/wiki/Changes/HardeningFlags28 ) (2018)
- Windows has it since [Windows 10, version 2004]( https://support.microsoft.com/en-us/topic/november-30-2020-kb4586853-os-builds-19041-662-and-19042-662-preview-8fb07fb8-a7dd-ea62-d65e-3305da09f92e ) (November 2020)
While looking at this, I wondered what hardening-related compilation flags Alpine was using by default, and didn't manage to find a single source of truth:
- [x] `GOFLAGS="-buildmode=pie` is enabled in [abuild.conf]( https://github.com/alpinelinux/abuild/blob/master/abuild.conf ).
- [x] `-stack-protector`: enabled by default via a clang [patch]( https://github.com/alpinelinux/aports/blob/master/main/clang15/30-Enable-stack-protector-by-default-for-Alpine-Linux.patch ), but what about gcc?
- [x] `-D_FORTIFY_SOURCE=2` is apparently enabled by default as per this [commit](https://github.com/alpinelinux/abuild/commit/4e548b722b55714dc1888f1df3a549bca0782081), but cool kids are using `-D_FORTIFY_SOURCE=3` nowadays
- Arch Linux [moved to it ]( https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/17 ) in April 2023
- [x] `-z relro -z now` are apparently enabled by default as per this [commit](https://github.com/alpinelinux/abuild/commit/4e548b722b55714dc1888f1df3a549bca0782081)
- [x] `-fstack-clash-protection`: enabled via https://gitlab.alpinelinux.org/alpine/abuild/-/commit/4f7a2aff7b87cec7dd2783f95b5d6f744244c6c7
- Fedora is using [by default](https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc)
- [x] `-fpie -Wl,-pie` and `-fpic -shared` are [enabled by default](https://gitlab.alpinelinux.org/alpine/tsc/-/issues/64#note_284521)
- [x] `-Werror=format-security` is [enabled as well](https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/default.conf#L2)
- [ ] A decent subset of [UBSan]( https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html ) like `-fsanitize=undefined -fsanitize-minimal-runtime`
- [x] [libstdc++](https://gcc.gnu.org/onlinedocs/libstdc++/) related:
- [x] `GLIBCXX_ASSERTIONS`: enabled via https://gitlab.alpinelinux.org/alpine/abuild/-/commit/44c933da5d8e364d6cd755071f629c05444191df
- Enabled since [January 2023 in gentoo](https://www.gentoo.org/support/news-items/2023-01-01-hardening-fortify-assertions.html)
- [ ] `-ftrivial-auto-var-init=zero`
- Ubuntu is [working on enabling it by default](https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1972043)
- [ ] [libcxx](https://libcxx.llvm.org/) related, added via https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/221
- [x] `_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS`: This macro is used to enable -Wthread-safety annotations on libc++’s `std::mutex` and `std::lock_guard`.
- [x] `_LIBCPP_ENABLE_HARDENED_MODE` to enable the [hardened mode](https://libcxx.llvm.org/Hardening.html#using-hardened-mode).
- It's ~enabled in [Google Chrome](https://bugs.chromium.org/p/chromium/issues/detail?id=1335422)
- [ ] `-fcf-protection`: needs musl support.
It would be great to have the flags and their tradeoffs documented somewhere.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10096apbuild-cpan does not check for dupes in dependencies and does not sort depen...2023-03-14T12:25:03ZDuncan Bellamyapbuild-cpan does not check for dupes in dependencies and does not sort dependencies alphabeticallyusing:
`apkbuild-cpan create Code::TidyAll::Plugin::SortLines::Naturally`
an APKBUILD is created with `perl-code-tidyall` in `depends` and `checkdepends`
also the dependencies are not sorted alphabetically like is suggested when manual...using:
`apkbuild-cpan create Code::TidyAll::Plugin::SortLines::Naturally`
an APKBUILD is created with `perl-code-tidyall` in `depends` and `checkdepends`
also the dependencies are not sorted alphabetically like is suggested when manually creating APKBUILD files, and for ease of maintenance