alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2021-09-10T06:09:24Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12997zig language version 0.8.1 version bump2021-09-10T06:09:24Zfrogtilezig language version 0.8.1 version bumpCurrent Alpine version is
[0.7.1](https://pkgs.alpinelinux.org/packages?name=zig) but
[0.8.1](https://ziglang.org/download/0.8.1/release-notes.html) is now available.Current Alpine version is
[0.7.1](https://pkgs.alpinelinux.org/packages?name=zig) but
[0.8.1](https://ziglang.org/download/0.8.1/release-notes.html) is now available.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12998community/gnome-boxes: can't create a VM, "this QEMU binary lacks smartcard p...2021-09-12T00:06:37Zknuxifycommunity/gnome-boxes: can't create a VM, "this QEMU binary lacks smartcard passthrough mode support"When creating a VM with a custom ISO in gnome-boxes:
```
** (gnome-boxes:8650): CRITICAL **: 17:44:02.429: osinfo_media_supports_installer_script: assertion 'OSINFO_IS_MEDIA(media)' failed
(gnome-boxes:8650): Boxes-WARNING **: 17:44:02...When creating a VM with a custom ISO in gnome-boxes:
```
** (gnome-boxes:8650): CRITICAL **: 17:44:02.429: osinfo_media_supports_installer_script: assertion 'OSINFO_IS_MEDIA(media)' failed
(gnome-boxes:8650): Boxes-WARNING **: 17:44:02.520: review-page.vala:32: Box setup failed: Failed to create domain: unsupported configuration: this QEMU binary lacks smartcard passthrough mode support
(gnome-boxes:8650): Boxes-CRITICAL **: 17:44:02.520: boxes_assistant_review_page_populate: assertion 'machine != NULL' failed
```
From my understanding, this is caused by boxes trying to force smartcard support despite it being disabled in our qemu build.
I can think of two ways to fix this:
* Disable smartcard support in gnome-boxes; seems like at some point smartcard support detection was done correctly, but this was dropped in [this commit](https://gitlab.gnome.org/GNOME/gnome-boxes/-/commit/6bf871c4e220cb4c32f7d96c143618e6f5b680cb). Reverting it should theoretically fix the issue.
* Edit the QEMU package to enable smartcard support. The main problem with that is that it would require adding an extra package, ``libcacard``.
I tried doing it in both approaches:
* In the case of the first one, the code has changed quite a bit and just reverting the patch doesn't really work; seems to complain about the if statements I added. (Also needed a build info change because the project has moved from autoconf to meson since that commit, but I don't think this is the problem.)
* In the case of the second one, adding ``libcacard`` is problematic because it would require us to put it in main (as ``spice`` itself is in main, and it too has to be updated for this to work), and that would require us to put nss and opensc in main as well (although they don't seem to have any further dependencies in community)... no clue if anyone would ever agree to that :upside_down: See !25160 for an implementation if you're interested.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10045apkbuild-cpan.in: issue with versions containing "v" and module-build2024-02-14T00:52:49ZTimothy Leggeapkbuild-cpan.in: issue with versions containing "v" and module-build@ncopa assign to me I will address:
perl-test-mockmodule's version includes a v and it used the Build.PL script from Module::Build
generating the $metaprefix assumes no embedded v requires something like this to work around and is lik...@ncopa assign to me I will address:
perl-test-mockmodule's version includes a v and it used the Build.PL script from Module::Build
generating the $metaprefix assumes no embedded v requires something like this to work around and is likely needed in several places as the meta.yml is not read properly either:
```
@@ -222,7 +223,12 @@
my $package_func;
my $text = read_file "APKBUILD";
- if (-e "$metaprefix/Build.PL" ) {
+ my $builddir = $apkbuild->{'builddir'};
+ $builddir =~ s/\$srcdir\/\$_pkgreal/src\/$apkbuild->{'_pkgreal'}/;
+ $builddir =~ s/\$pkgver/$apkbuild->{'pkgver'}/;
+ if (-e "$metaprefix/Build.PL" || -e "$builddir/Build.PL") {
$build_func = <<'EOF';
build() {
export CFLAGS=$(perl -MConfig -E 'say $Config{ccflags}')
```Timothy LeggeTimothy Leggehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12999PowerButton does not initiate shutdown2021-09-14T02:00:58ZmozotechPowerButton does not initiate shutdownA short press of the power button should initiate a shutdown/poweroff on x86_64 platforms and this does not happen when using alpine-extended-3.13.6-x86_64 and alpine-extended-3.14.2-x86_64. (Prior versions alpine-extended-3.11.12-x86_64...A short press of the power button should initiate a shutdown/poweroff on x86_64 platforms and this does not happen when using alpine-extended-3.13.6-x86_64 and alpine-extended-3.14.2-x86_64. (Prior versions alpine-extended-3.11.12-x86_64 and alpine-extended-3.12.8-x86_64 work properly and a short press of the power button initiates a 'poweroff').
To reproduce issue install alpine-extended-3.14.2-x86_64 to USB stick, configure to run from RAM using setup-alpine. Briefly pressing the power button does not initiate a poweroff.
To temporarily work round the issue until properly fixed a script in /etc/local.d could be used to remove the 'tiny_power_button' driver then remove and re-add the 'button' driver and then restart the acpid service:
```
#!/bin/sh
# Fix Power Button Event Handling
# Remove 'tiny_power_button' driver to stop it catching the event when PWR button pressed
# Delete and re-add 'button' driver to allow it to handle PWR button event
modprobe -r tiny_power_button
modprobe -r button
modprobe button
service acpid restart
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/13000dnsmasq currently without dbus support2022-06-27T07:29:09ZSeandnsmasq currently without dbus supportcurrently dnsmasq is built in two flavours. Regular and DNSSEC.
Network Manager requires dbus support to be able to launch/control dnsmasq.
I would like to get dbus support included. Obviously adding dbus support to the existing regula...currently dnsmasq is built in two flavours. Regular and DNSSEC.
Network Manager requires dbus support to be able to launch/control dnsmasq.
I would like to get dbus support included. Obviously adding dbus support to the existing regular dnsmasq would create a dbus requirement, which I think is not a good thing.
So I would like to do one of two things, either add a third build/package to the existing dnsmasq package, so regular, DNSSEC and dbus would come out of the same package or add a new package specifically for NetworkManager, something like networkmanager-dnsmasq which would install dnsmasq as a differently named binary and no openrc as it would be exclusive to use for network manager.
Any thoughts/suggestions?Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13001Openssl 3.0 rebuild postmortem2022-07-15T06:22:01ZAndy PostnikovOpenssl 3.0 rebuild postmortemThere was `main/openssl1.1-compat` added via !25146
Few packages expected to fail rebuild on newer `openssl-dev-3.0.0-r0`
example `main/perl-crypt-openssl-rsa/perl-crypt-openssl-rsa-0.32-r1.log`
```
/usr/include/openssl/rsa.h:351:27: n...There was `main/openssl1.1-compat` added via !25146
Few packages expected to fail rebuild on newer `openssl-dev-3.0.0-r0`
example `main/perl-crypt-openssl-rsa/perl-crypt-openssl-rsa-0.32-r1.log`
```
/usr/include/openssl/rsa.h:351:27: note: declared here
351 | OSSL_DEPRECATEDIN_3_0 int RSA_verify(int type, const unsigned char *m,
| ^~~~~~~~~~
make: *** [Makefile:348: RSA.o] Error 1
```
Using `openssl1.1-compat`
- [ ] mariadb https://jira.mariadb.org/browse/CONC-503
- [x] ruby d6ac3fa60dc9afaebc51c7ab495c934edbbe5d3d https://github.com/ruby/openssl/issues/369 - related - !19106
- [x] postgresql 80f174e5804ea6d2fdc42b957c56149589d90838 https://github.com/postgres/postgres/commits/master/contrib/pgcrypto - !24153
- [ ] umurmur https://github.com/umurmur/umurmur/issues/176
- [ ] apk-tools https://github.com/openssl/openssl/issues/16660
Updated
- main/rabbitmq-c: 490ce7621f646776a769676672f90ee1833658de
- nsd !252223.15.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/13002I’m stuck and I hit reboot it doesn’t work it just goes back to checkrain2021-09-25T18:20:23ZYo JoeI’m stuck and I hit reboot it doesn’t work it just goes back to checkrainhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13005tg/telegram-cli exits with error2021-09-14T12:45:16Zfaustritg/telegram-cli exits with errorAfter setting up authentication, I only need to run 'telegram-cli' (from the package 'tg') and wait 2-3 seconds for it to exit with the error below. Previously it didnt't exit by itself, but when I ran 'dialog_list' and the list was over...After setting up authentication, I only need to run 'telegram-cli' (from the package 'tg') and wait 2-3 seconds for it to exit with the error below. Previously it didnt't exit by itself, but when I ran 'dialog_list' and the list was over 2 lines it exited with a similar error.
```
> telegram-cli
Telegram-cli version 1.3.1, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type `show_license'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show_license' for details.
Telegram-cli uses libtgl version 2.0.1
I: config dir=[/4/.telegram-cli]
> Assertion failed: 0 (tgl/structures.c: tglf_fetch_message_media_new: 944)
zsh: illegal hardware instruction telegram-cli
```Leonardo ArenaLeonardo Arenahttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10767apk: HTTPS broken after system update2021-11-10T15:25:45ZMogens Jensenapk: HTTPS broken after system updateAfter updating an Alpine edge x86_64 system, apk no longer works with HTTPS:
```
$ sudo apk update -v
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main/x86_64/APKINDEX.tar.gz
480BD0E0A57F0000:error:0A000086:SSL routines:tls_...After updating an Alpine edge x86_64 system, apk no longer works with HTTPS:
```
$ sudo apk update -v
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main/x86_64/APKINDEX.tar.gz
480BD0E0A57F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1882:
ERROR: https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main: Permission denied
WARNING: Ignoring https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main: No such file or directory
```
For some reason `ca-certificates` was removed during the system update, so changing the mirror to HTTP and reinstalling it fixes the problem.
Should `apk-tools` depend on `ca-certificates` to avoid this problem in the future?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13179apk: HTTPS broken after system update2021-11-10T15:26:08ZMogens Jensenapk: HTTPS broken after system updateAfter updating an Alpine edge x86_64 system, apk no longer works with HTTPS:
```
$ sudo apk update -v
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main/x86_64/APKINDEX.tar.gz
480BD0E0A57F0000:error:0A000086:SSL routines:tls_...After updating an Alpine edge x86_64 system, apk no longer works with HTTPS:
```
$ sudo apk update -v
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main/x86_64/APKINDEX.tar.gz
480BD0E0A57F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1882:
ERROR: https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main: Permission denied
WARNING: Ignoring https://ftp.acc.umu.se/mirror/alpinelinux.org/edge/main: No such file or directory
```
For some reason `ca-certificates` was removed during the system update, so changing the mirror to HTTP and reinstalling it fixes the problem.
Should `apk-tools` depend on `ca-certificates` to avoid this problem in the future?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13007Error loading shared library libcuda.so.1 results in fatal error2021-09-15T02:38:53ZRolly EstabilloError loading shared library libcuda.so.1 results in fatal errorI'm getting an issue when trying to run my service as a docker image. This service uses the deep learning model vgg16. However, when I run my service in my IDE, I don't get the fatal error although I get the same missing library message ...I'm getting an issue when trying to run my service as a docker image. This service uses the deep learning model vgg16. However, when I run my service in my IDE, I don't get the fatal error although I get the same missing library message and my service executes successfully. Below is the full stack trace. Please help. Thanks!
```
Warning: Could not load Loader: java.lang.UnsatisfiedLinkError: no jnijavacpp in java.library.path: [/usr/lib/jvm/java-11-openjdk/lib/server, /usr/lib/jvm/java-11-openjdk/lib, /usr/lib/jvm/java-11-openjdk/../lib, /usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
2021-09-13 18:54:08.214 WARN 1 --- [nio-8443-exec-4] org.nd4j.linalg.factory.Nd4jBackend : Skipped [JCublasBackend] backend (unavailable): java.lang.UnsatisfiedLinkError: /data/?/.javacpp/cache/cuda-10.2-7.6-1.5.3-linux-x86_64.jar/org/bytedeco/cuda/linux-x86_64/libjnicudart.so: Error loading shared library libcuda.so.1: No such file or directory (needed by /data/?/.javacpp/cache/cuda-10.2-7.6-1.5.3-linux-x86_64.jar/org/bytedeco/cuda/linux-x86_64/libjnicudart.so)
2021-09-13 18:54:08.223 INFO 1 --- [nio-8443-exec-4] org.nd4j.linalg.factory.Nd4jBackend : Loaded [CpuBackend] backend
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000000000021c6, pid=1, tid=375
#
# JRE version: OpenJDK Runtime Environment (11.0.11+9) (build 11.0.11+9-alpine-r0)
# Java VM: OpenJDK 64-Bit Server VM (11.0.11+9-alpine-r0, mixed mode, tiered, compressed oops, serial gc, linux-amd64)
# Problematic frame:
# C 0x00000000000021c6
#
# Core dump will be written. Default location: /data/core.1
#
# An error report file with more information is saved as:
# /data/hs_err_pid1.log
#
# If you would like to submit a bug report, please visit:
# https://gitlab.alpinelinux.org/alpine/aports/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/13008libgcrypt < 1.9.4-r0 has medium security vulnerability CVE-2021-40528 (found ...2021-09-15T02:37:44ZMartin Falaticlibgcrypt < 1.9.4-r0 has medium security vulnerability CVE-2021-40528 (found via Twistlock with Alpine v3.12)This vulnerability was flagged on Alpine v3.12. It affects Alpine v3.13 and earlier which use libgcrypt 1.8.8-r0 (only the v3.14 and edge branches appear to have the fixed libgcrypt 1.9.4-r0 at this time).
Vulnerability details are avai...This vulnerability was flagged on Alpine v3.12. It affects Alpine v3.13 and earlier which use libgcrypt 1.8.8-r0 (only the v3.14 and edge branches appear to have the fixed libgcrypt 1.9.4-r0 at this time).
Vulnerability details are available at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40528https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10046sbsigntool: segfaults using openssl-3.0.02021-10-07T10:24:15ZCássiosbsigntool: segfaults using openssl-3.0.0After updating openssl to 3.0.0 sbsign segfaults when trying to sign a EUFI image, breaking secureboot-hook, possibly making the system unbootable.After updating openssl to 3.0.0 sbsign segfaults when trying to sign a EUFI image, breaking secureboot-hook, possibly making the system unbootable.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13069sbsigntool: segfaults using openssl-3.0.02022-07-26T07:55:42ZCássiosbsigntool: segfaults using openssl-3.0.0After updating openssl to 3.0.0 sbsign segfaults when trying to sign a EUFI image, breaking secureboot-hook, possibly making the system unbootable.After updating openssl to 3.0.0 sbsign segfaults when trying to sign a EUFI image, breaking secureboot-hook, possibly making the system unbootable.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13009iso-codes package contains wrong official name for Taiwan2021-09-14T20:56:53ZJulian Großiso-codes package contains wrong official name for TaiwanThe "official name" of the country on Taiwan is wrong. It states "Province of China", which is obviously not its official name. No country would call itself "Province" of another country. The official name is "Republic of China".
Affect...The "official name" of the country on Taiwan is wrong. It states "Province of China", which is obviously not its official name. No country would call itself "Province" of another country. The official name is "Republic of China".
Affected package: iso-codes
Some sources:
- Official government website https://www.taiwan.gov.tw by the RoC Ministry of Foreign Affairs
- You can ask any person living on the Island.
- As an IT person, you might have some hardware labeled "Made in RoC".
- The Hong Kong and the Taiwanese locale both have "中華民國" as a translation, which means "Republic of China".https://gitlab.alpinelinux.org/alpine/aports/-/issues/13010testing/libgpod: Installing libgpod breaks /tmp directory permissions2021-09-15T12:08:09Zknuxifytesting/libgpod: Installing libgpod breaks /tmp directory permissions```
$ sudo apk add libgpod
(1/1) Installing libgpod (0.8.3-r5)
Executing busybox-1.34.0-r3.trigger
Executing eudev-3.2.10-r1.trigger
OK: 5618 MiB in 1355 packages
$ ls -l / | grep tmp
12K drwxr-xr-x 9 root root 12K Sep 15 08:58 tmp
$...```
$ sudo apk add libgpod
(1/1) Installing libgpod (0.8.3-r5)
Executing busybox-1.34.0-r3.trigger
Executing eudev-3.2.10-r1.trigger
OK: 5618 MiB in 1355 packages
$ ls -l / | grep tmp
12K drwxr-xr-x 9 root root 12K Sep 15 08:58 tmp
$ sudo apk del libgpod
(1/1) Purging libgpod (0.8.3-r5)
Executing busybox-1.34.0-r3.trigger
Executing eudev-3.2.10-r1.trigger
OK: 5617 MiB in 1354 packages
$ ls -l / | grep tmp
12K drwxrwxrwt 9 root root 12K Sep 15 08:58 tmp
```
Quick search reveals that some folks had this problem back in 2011, and it was supposedly fixed in Slackware with a patch, [see thread](https://www.linuxquestions.org/questions/slackware-14/%5Bcurrent%5D-libgpod-break-tmp-permissions-856601). No clue where this patch could be found, and I couldn't find anything similar in Debian.
cc @fcolista, you're listed as the maintainer for the libgpod packagehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13011package avif-tools libaom2021-09-16T08:52:02Z杨文 陈package avif-tools libaomavif-tools like avifenc, avifdec https://github.com/joedrago/homebrew-repo/blob/master/Formula/avifenc.rb
avif depends on libaomavif-tools like avifenc, avifdec https://github.com/joedrago/homebrew-repo/blob/master/Formula/avifenc.rb
avif depends on libaomhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13012pcc creates bad executables2021-09-17T07:24:56ZJohn Vogelpcc creates bad executablesA minimal reproducer inlined:
empty.c:
``
int main(void)
{
return 0;
}
``
> ~$ pcc -o empty empty.c
> ~$ ./empty
> Segmentation fault (core dumped)
Backtrace of the issue showed that the executable was crashing in __do_global_ctors_...A minimal reproducer inlined:
empty.c:
``
int main(void)
{
return 0;
}
``
> ~$ pcc -o empty empty.c
> ~$ ./empty
> Segmentation fault (core dumped)
Backtrace of the issue showed that the executable was crashing in __do_global_ctors_aux.
Seemed to me that the problem is that there was a miscomplitation of the start files;
namely they were compiled by gcc, but needed to be compliled by pcc. I may not have the right
of it exactly, but seemed close enough to start from. Some other issues
that I ran into was search path and pic/pie issues at linkage.
I have succeeded in two approaches to fix this. One was to add pcc to pcc-libs makedepends and
add 'CC=pcc' to the make command for building pcc-libs.
This works, but because there is a circular dependency, seems prone to breakage. The second
fix was combine the two aports, allowing to build pcc-libs with the freshly built pcc.
I have attached a patch for the second fix.
[pcc_combined_port.patch](/uploads/4538763151c443367e4e6044546c6f0a/pcc_combined_port.patch)Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13013nettle CVE-2021-35802022-05-21T17:44:48ZMiroslav Machuranettle CVE-2021-3580Hi, according to NVD nettle library up to version 3.7.3 (excluding) is vulnerable to CVE-2021-3580. Affects at least alpine-3.13. Please upgrade the library or apply a fix.
- https://nvd.nist.gov/vuln/detail/CVE-2021-3580Hi, according to NVD nettle library up to version 3.7.3 (excluding) is vulnerable to CVE-2021-3580. Affects at least alpine-3.13. Please upgrade the library or apply a fix.
- https://nvd.nist.gov/vuln/detail/CVE-2021-3580Fabian AffolterFabian Affolterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13014sqlite in Chrome CVE-2021-305692021-09-25T18:19:41ZMiroslav Machurasqlite in Chrome CVE-2021-30569Hi, according to JFrog Xray - sqlite up to 3.36.0 might be vulnerable to CVE-2021-30569. Could you please verify and apply the fix?
References:
- https://nvd.nist.gov/vuln/detail/CVE-2021-30569
- https://sqlite.org/src/info/45f459d2fa4b...Hi, according to JFrog Xray - sqlite up to 3.36.0 might be vulnerable to CVE-2021-30569. Could you please verify and apply the fix?
References:
- https://nvd.nist.gov/vuln/detail/CVE-2021-30569
- https://sqlite.org/src/info/45f459d2fa4be97d
Thanks, Miro