aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2024-01-20T00:00:25Zhttps://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/15698use of GStreamer videosink "xvimagesink" causes an immediate close of user se...2024-01-22T21:08:16Zfduncanhuse of GStreamer videosink "xvimagesink" causes an immediate close of user session (KDE Plasma 5.27 /Alpine both 3.19 AND Edge)When using KDE with X11, (on Intel X86_64 desktop, System Disk Alpine , both 3.19 and Edge)
```
gst-launch-1.0 videotestsrc ! videoconvert ! xvimagesink
```
immediately terminates the user session, with return to sddm login screen
/va...When using KDE with X11, (on Intel X86_64 desktop, System Disk Alpine , both 3.19 and Edge)
```
gst-launch-1.0 videotestsrc ! videoconvert ! xvimagesink
```
immediately terminates the user session, with return to sddm login screen
/var/log/messages only shows
```
Jan 18 15:20:05 [host] user.notice libddcutil[3617]: libddcutil terminating.
Jan 18 15:20:05 [host] authpriv.info : pam_unix(sddm:session): session closed for user
```
* Does not happen if xvimagesink is replaced by ximagesink in KDE/X11
* No problems with xvimagesink in KDE/Wayland.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15697As of alpine 3.19 a docker container with xorg /tmp/.X11-unix mounted cannot ...2024-01-19T17:48:01ZR. David MurrayAs of alpine 3.19 a docker container with xorg /tmp/.X11-unix mounted cannot open unix:0.0I have a docker container running Alpine 3.18 that mounts /tmp/.X11-unix in order to talk to the host X display. This works fine. After rebuilding the docker container with 3.19 and no other changes, I get an error that the application...I have a docker container running Alpine 3.18 that mounts /tmp/.X11-unix in order to talk to the host X display. This works fine. After rebuilding the docker container with 3.19 and no other changes, I get an error that the application "cannot open display: unix:0.0". The Dockerfile does not specify versions for anything other than alpine itself (FROM alpine:3.19), so it would be using the versions automatically pulled via that image base.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15694Entries automatically added to repository file2024-01-19T10:02:37ZCyclisme 24Entries automatically added to repository file3.19 on x86_64 bare metal - installed new as 3.17 then immediately upgraded to 3.19.
The `/etc/apk/repository` file has had additional `community` entries automagically added to it. Saw a similar report on IRC a few days ago.
What is ...3.19 on x86_64 bare metal - installed new as 3.17 then immediately upgraded to 3.19.
The `/etc/apk/repository` file has had additional `community` entries automagically added to it. Saw a similar report on IRC a few days ago.
What is really odd is the tags for Edge/main are being used for the first three Edge/community.
```
#/media/sdb/apks
https://dl-cdn.alpinelinux.org/alpine/v3.19/main
https://dl-cdn.alpinelinux.org/alpine/v3.19/community
https://dl-cdn.alpinelinux.org/alpine/v3.19/community
https://dl-cdn.alpinelinux.org/alpine/v3.19/community
https://dl-cdn.alpinelinux.org/alpine/v3.19/community
@em https://dl-cdn.alpinelinux.org/alpine/edge/main
@em https://dl-cdn.alpinelinux.org/alpine/edge/community
@em https://dl-cdn.alpinelinux.org/alpine/edge/community
@em https://dl-cdn.alpinelinux.org/alpine/edge/community
@ec https://dl-cdn.alpinelinux.org/alpine/edge/community
@et https://dl-cdn.alpinelinux.org/alpine/edge/testing
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15689The sddm package requires xorg-server2024-01-18T09:58:12ZGil PedersenThe sddm package requires xorg-serverSDDM can now (since 0.20.0) work under Wayland, given the right configuration. As such, it should probably not require `xorg-server` and possibly also not `dbus-x11`.
What would be a sensible way to split this off?SDDM can now (since 0.20.0) work under Wayland, given the right configuration. As such, it should probably not require `xorg-server` and possibly also not `dbus-x11`.
What would be a sensible way to split this off?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15688CVE-2023-40392024-01-18T04:04:52ZJeremy JiCVE-2023-4039Package: gcc
OS: 3.16
CVE: CVE-2023-4039
Impacted versions: <2023-09-12
Discovered: less than an hour ago
Published: more than 4 months ago
A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows...Package: gcc
OS: 3.16
CVE: CVE-2023-4039
Impacted versions: <2023-09-12
Discovered: less than an hour ago
Published: more than 4 months ago
A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables. The default behavior when the stack-protector detects an overflow is to terminate your application, resulting in controlled loss of availability. An attacker who can exploit a buffer overflow without triggering the stack-protector might be able to change program flow control to cause an uncontrolled loss of availability or to go further and affect confidentiality or integrity.
Hi @ariadne Could you help to fix the CVE?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15684CVE-2023-51767 and CVE-2023-487952024-02-02T16:22:47ZJeremy JiCVE-2023-51767 and CVE-2023-48795Package: openssh
OS: 3.16
CVE: CVE-2023-51767 and CVE-2023-48795
CVE-2023-51767 :
Impacted versions: <=9.6
Discovered: less than an hour ago
Published: 24 days ago
OpenSSH through 9.6, when common types of DRAM are used, might allow r...Package: openssh
OS: 3.16
CVE: CVE-2023-51767 and CVE-2023-48795
CVE-2023-51767 :
Impacted versions: <=9.6
Discovered: less than an hour ago
Published: 24 days ago
OpenSSH through 9.6, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges.
CVE-2023-48795:
Impacted versions: <9.6
Discovered: less than an hour ago
Published: 30 days ago
The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH\'s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SS
Hi @ncopa The openssh has two CVE, could you help to fix them?Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15681Installing KVM and qemu-system-x86_64 fails: no such package: required by wor...2024-02-20T21:57:29Zdan danInstalling KVM and qemu-system-x86_64 fails: no such package: required by world[qemu-system-x86_64]![kvm_fails_always_on_alpine](/uploads/282d6a0f0776f9d12785f5a88efb66be/kvm_fails_always_on_alpine.png)
Tried on the latest Alpine 3.19 and the previous 3.17 versions.
No way of installing KVM and Qemu![kvm_fails_always_on_alpine](/uploads/282d6a0f0776f9d12785f5a88efb66be/kvm_fails_always_on_alpine.png)
Tried on the latest Alpine 3.19 and the previous 3.17 versions.
No way of installing KVM and Qemuhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15677package request: GeoGebra2024-01-16T12:34:08ZJulian Großpackage request: GeoGebraMany (if not most) German schools and universities use GeoGebra. Currently (at least on aarch64), the only version available on Alpine Linux/postmarketOS is the web version at https://www.geogebra.org/classic.
While the packages have a c...Many (if not most) German schools and universities use GeoGebra. Currently (at least on aarch64), the only version available on Alpine Linux/postmarketOS is the web version at https://www.geogebra.org/classic.
While the packages have a custom license, the source is licensed under GPL. (See the "How is GeoGebra licensed" section: https://www.geogebra.org/license)
An example for a distribution package is the official Debian package: https://packages.debian.org/source/trixie/geogebra
The source is available here: https://github.com/geogebra/geogebrahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15676community/nyxt: the package seems to require mesa-gles2024-03-02T04:31:43ZDaniele Parisicommunity/nyxt: the package seems to require mesa-glesI installed the package and run it: A gray window appeared with nothing on it, on the console there were error messages complaining about something missing related to GLES. I installed mesa-gles and it works now. So mesa-gles is required...I installed the package and run it: A gray window appeared with nothing on it, on the console there were error messages complaining about something missing related to GLES. I installed mesa-gles and it works now. So mesa-gles is required somehow, but I don't know if it should be dependency of nyxt itself or some of nyxt's dependencies (webkit?).
```
Couldn't open libGLESv2.so.2: Error loading shared library libGLESv2.so.2: No such file or directory
<WARN> [19:54:38] Warning: Web process terminated for buffer 6524 (opening ) because it crashed
```Will Sinatrawpsinatra@gmail.comWill Sinatrawpsinatra@gmail.comhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15670nextcloud-client arm v62024-01-17T12:17:51Zdaniel dallasnextcloud-client arm v6feature request to have this package built form arm v6 as well.
My docker build just didn't work on a raspberry pi zero w...
it did build on my other raspberry pi zero w2 earlier.feature request to have this package built form arm v6 as well.
My docker build just didn't work on a raspberry pi zero w...
it did build on my other raspberry pi zero w2 earlier.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15665Suggestions to make ly login manager work2024-01-11T02:19:05ZdxrobertsonSuggestions to make ly login manager workOn an up to date alpine release 3.19.0 I downloaded:
http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/ly-0.6.0-r1.apk
http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/ly-openrc-0.6.0-r1.apk
**INSTALL:**
`apk -i ...On an up to date alpine release 3.19.0 I downloaded:
http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/ly-0.6.0-r1.apk
http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/ly-openrc-0.6.0-r1.apk
**INSTALL:**
`apk -i add --allow-untrusted ly-0.6.0-r1.apk ly-openrc-0.6.0-r1.apk`
**USE:**
disable existing lightdm login manager (rc-update del lightdm default)
`rc-service ly start`
attempt login, get error:
Error BEFORE /etc/X11/Xwrapper.config file created:
[ 182.884] (--) controlling tty is VT number 7, auto-enabling KeepTty
[ 182.885] (EE)
Fatal server error:
[ 182.885] (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
[ 182.885] (EE)
[ 182.885] (EE)
research this and determine /etc/X11/Xwrapper.config is needed.
**FIX:**
create /etc/X11/Xwrapper.config:
needs_root_rights = yes
also note changes needed to /etc/ly/config.ini:
shutdown_cmd = /sbin/poweroff
restart_cmd = /sbin/reboot
tty = 7
**USE AFTER FIX:**
`rc-update add ly default`
all works-
can login with no difference from lightdm login
F1 and F2 poweroff and reboot workhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15658Can build date in alpine package database be used as an indicator of new chan...2024-01-10T09:43:19ZMoullishaCan build date in alpine package database be used as an indicator of new changes?I need to fetch all the package names from alpine database. But I want the fetching operation to be done only if a new package has been added or some changes have been done. For this purpose can I use build date as an indicator of whethe...I need to fetch all the package names from alpine database. But I want the fetching operation to be done only if a new package has been added or some changes have been done. For this purpose can I use build date as an indicator of whether or not any changes were made to the package?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15656Libreoffice-calc doesn't bundle a JRE2024-01-22T08:56:04Zbgregs514Libreoffice-calc doesn't bundle a JRE**Version Information:**
`libreoffice-calc-7.6.3.1-r0 x86_64`
**Expected Behavior:**
Install `libreoffice-calc` with `apk add libreoffice-calc` and begin to use the application.
**Actual Behavior:**
After installing the application,...**Version Information:**
`libreoffice-calc-7.6.3.1-r0 x86_64`
**Expected Behavior:**
Install `libreoffice-calc` with `apk add libreoffice-calc` and begin to use the application.
**Actual Behavior:**
After installing the application, attempting to run `libreoffice-calc` with `libreoffice --calc` from the terminal results in the LibreOffice splash screen appearing and hanging indefinitely. The following text is printed to the console:
```
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
```
**Proposed Solution:**
`libreoffice-calc` (and other LibreOffice sub-packages) should depend on a default JRE package if none is present.Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15653apk: provide a more reliable way for post-upgrade warnings2024-02-26T22:53:32ZRudolf Polzerapk: provide a more reliable way for post-upgrade warningsRight now packages that want to tell the user about important manual steps can only do so by a post-upgrade warning. This is e.g. being discussed on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58567
This is fragile - u...Right now packages that want to tell the user about important manual steps can only do so by a post-upgrade warning. This is e.g. being discussed on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58567
This is fragile - users may simply miss the warning among all the other apk output.
Thus I propose some way for packages to warn the user about potentially necessary manual steps, such as (in decreasing order of implementation complexity):
- A separate apk stage that runs after upgrading and triggers, and is intended to primarily show warnings. It has to come after triggers, as some triggers (e.g. akms) can output many screenfuls and thus hide important warnings.
- A convention that all "important warnings" output by a post-upgrade script must start with a specific prefix, and a change to apk so it collects those during upgrading and repeats them at the end as a final output.
- So basically, a trivial but very dirty implementation:
```
#!/bin/sh
# apk.sh - apk wrapper that repeats important warnings
warnings=$(apk "$@" 2>&1 | tee /dev/stderr | grep ^WARNING:)
echo "$warnings"
```
- A convention that package scripts (including triggers) shall not write anything to stdout/stderr unless it is critically important (or at least be limited to a single line of output); other output could go to syslog or similar places instead. On my system this would primarily impact grub's and akms's triggers, which then would no longer print to stdout/stderr, but just write their progress output to syslog. In case of akms it might make sense to have at least a single line of progress that's refreshed but doesn't advance to the next line.
Long-term it could also make sense to have pre-upgrade and pre-install warnings, which apk would (as IIRC there is a policy that apk shall be non-interactive by default) normally just print prior to installing anything, but there could be an apk flag to make them blocking and wait for an enter press. In fact, the existing -i flag of apk could also enable these. Could even also add a flag to apk that fails the upgrade if a preinstall warning exists (that way, adventurous people could run apk upgrade from a cronjob).Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15652Failed to bootstrap.sh aarch642024-02-10T17:38:58ZAndré ZwingFailed to bootstrap.sh aarch64When trying `bootstrap.sh aarch64`. I got:
```
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: warning: -z pack-relative-relocs ignored
aarch64-alpine-linux-musl-ar: 'u' modifier ignored sinc...When trying `bootstrap.sh aarch64`. I got:
```
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: warning: -z pack-relative-relocs ignored
aarch64-alpine-linux-musl-ar: 'u' modifier ignored since 'D' is the default (see 'U')
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: warning: -z pack-relative-relocs ignored
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: warning: -z pack-relative-relocs ignored
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: warning: libgmp.so.10, needed by ./.libs/libisl.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: ./.libs/libisl.so: undefined reference to '__gmpz_get_si'
...
/usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: ./.libs/libisl.so: undefined reference to '__gmpz_get_d'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1796: isl_polyhedron_sample] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:2135: all-recursive] Error 1
make: *** [Makefile:1622: all] Error 2
ERROR: isl26: build failed
isl26: Uninstalling dependencies...
```
see here: https://github.com/AndreRH/hangover/actions/runs/7438447313/job/20271005450Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15651Issue with Python multiprocessing in Alpine container2024-01-23T07:54:58ZJan DunkIssue with Python multiprocessing in Alpine containerI ran into an issue with Python on Alpine. First I thought it was related to limits on nof but that's not the case. I can have many files open in the container (tested up to 15k). On the host OS it is running fine. Tried older versions ...I ran into an issue with Python on Alpine. First I thought it was related to limits on nof but that's not the case. I can have many files open in the container (tested up to 15k). On the host OS it is running fine. Tried older versions but these show the same behaviour.
Steps to reproduce:
`docker run -it alpine:3.19 /bin/sh`
```
apk update && apk upgrade
apk add --no-cache py3-pip
cat <<EOF > test.py
import multiprocessing
import time
import subprocess
if __name__ == '__main__':
queues = []
print((subprocess.check_output(['cat', '/proc/1/limits'])).decode())
for i in range(1000):
print(f"Appending multiprocessing.Queue() n. {i} ", end="")
queues.append(multiprocessing.Queue())
print("ok")
time.sleep(0.1)
print("all ok")
EOF
python3 test.py
```
Error
```
Appending multiprocessing.Queue() n. 84 ok
Appending multiprocessing.Queue() n. 85 Traceback (most recent call last):
File "test.py", line 10, in <module>
queues.append(multiprocessing.Queue())
File "/usr/lib/python3.7/multiprocessing/context.py", line 102, in Queue
return Queue(maxsize, ctx=self.get_context())
File "/usr/lib/python3.7/multiprocessing/queues.py", line 47, in __init__
self._wlock = ctx.Lock()
File "/usr/lib/python3.7/multiprocessing/context.py", line 67, in Lock
return Lock(ctx=self.get_context())
File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 162, in __init__
SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 59, in __init__
unlink_now)
OSError: [Errno 24] No file descriptors available
```
Any suggestions?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15648Request: LXC template for installing Alpine in unpriv container on non-Alpine...2024-01-07T19:17:10ZPeter ListerRequest: LXC template for installing Alpine in unpriv container on non-Alpine hostI have a Turris Omnia router, armv7l / armhf architecture. The installed OS is Turris OS, based on OpenWRT, which includes LXC version 4.0.12
I have successfully installed Alpine in several LXC containers from the repo.turris.cz server....I have a Turris Omnia router, armv7l / armhf architecture. The installed OS is Turris OS, based on OpenWRT, which includes LXC version 4.0.12
I have successfully installed Alpine in several LXC containers from the repo.turris.cz server. They work beautifully for services within my home network and I am a very happy Alpine user. However, these containers are all privileged. I would now like to container to run a server which would have some exposure to the routed Internet and obviously wish this to be unprivileged.
The two repos preconfigured by Turris OS were: repo.turris.cz, which (as I write) now has damaged or empty images; and linuxcontainers.org which seems not to host images for armhf at all. Neither of these are Alpine's problem, obviously, but I clearly can't rely on either as a source for my Alpine installs.
So I copied the LXC template and config file from Alpine's `lxc-templates-legacy-alpine` package to the Turris host. I added a line to the template to map armv7l architecture to armhf and tried `lxc-create -t alpine`. The template immediately found the latest build (3.18) and installed directly from an Alpine mirror; a few seconds later I had a perfectly working minimal Alpine system - but in a privileged container. Wonderful!
I then attempted to create (running as root) an *unprivileged* container by adding `/etc/sub[ug]id` maps and matching `lxc.idmap` keys to the host's LXC default config (as documented in linuxcontainers.org/lxc/getting-started). Unfortunately, I discovered that the Alpine template refuses to install an unprivileged container.
```plaintext
ERROR: This template can't be used for unprivileged containers.
ERROR: You may want to try the "download" template instead.
```
These messages are unhelpful. There is no obvious reason why I should not be able to install images in an unprivileged container: indeed this would seem to be a common use for a minimal Alpine install. Suggesting that I use the download template rather misses the point of why I'm trying to build directly from a reliable Alpine mirror.
At the end of LXC's "[getting started](http://linuxcontainers.org/lxc/getting-started)" page, there is a short list of links after the heading "Distribution LXC documentation" - there is no link for Alpine and I can't see anything on the Alpine web pages which indicates how to install Alpine in an unprivileged LXC container.
Would it be possible to:
* Update the Alpine LXC template to support unprivileged containers
* And package this template so that it's clearly up to date and not marked "legacy"
* Provide information on using this template from non-Alpine hosts.
* Provide linuxcontainers.org with a link to that information which they can add to their "getting started" page.
To be clear, I am aware that LXD/Incus defaults to unprivileged containers; Turris OS supports LXC and I am happy using LXC for my minimal system.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15646package request: cargo-deny2024-02-20T21:55:26ZPaolo Barbolinipackage request: cargo-deny**Project**: https://github.com/EmbarkStudios/cargo-deny
**Description**: Cargo plugin for linting Rust dependencies
**License**: MIT OR Apache-2.0**Project**: https://github.com/EmbarkStudios/cargo-deny
**Description**: Cargo plugin for linting Rust dependencies
**License**: MIT OR Apache-2.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15645lftp: Package URL links to spam/scam2024-01-07T14:31:05Zroberteikermannlftp: Package URL links to spam/scamThe package lftp links to a Projectwebsite that is not functional.
![image](/uploads/ba3d0f8e59e5b8bd607bde7491ad2d45/image.png)
![image](/uploads/6f99ae49af17679af95e87a47e1a002c/image.png)
This one could be a better project site: htt...The package lftp links to a Projectwebsite that is not functional.
![image](/uploads/ba3d0f8e59e5b8bd607bde7491ad2d45/image.png)
![image](/uploads/6f99ae49af17679af95e87a47e1a002c/image.png)
This one could be a better project site: https://lftp.yar.ru/Carlo LandmeterCarlo Landmeter