alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2021-09-24T09:37:39Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12607libguestfs: virt-sparsify missing?2021-09-24T09:37:39ZJosep Maria Viñolas Auquerlibguestfs: virt-sparsify missing?Hi, while building libguestfs the packages created are missing some utilities found in libguestfs src as sparsify (virt-sparsify).
Am I missing something or they can't be built on alpine? It seems that some perl modules are missing to bu...Hi, while building libguestfs the packages created are missing some utilities found in libguestfs src as sparsify (virt-sparsify).
Am I missing something or they can't be built on alpine? It seems that some perl modules are missing to build some virt-* tools.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12605gdm: fails to wake up after locking2023-01-29T15:58:55ZDylan Van Asschegdm: fails to wake up after locking# Description
I upgraded to edge to have GNOME 40 and when my desktop is now locked (manually or automatically after X minutes), I cannot wake it up anymore. The screen stays blank. If I switch to another tty using CTRL + F-key, the scr...# Description
I upgraded to edge to have GNOME 40 and when my desktop is now locked (manually or automatically after X minutes), I cannot wake it up anymore. The screen stays blank. If I switch to another tty using CTRL + F-key, the screen turns on and shows me a prompt. If I switch back to the original tty, the GDM greeter is shown.
# What's happening
Pressing a key or moving the mouse doesn't do anything when the desktop is locked.
# What's supposed to happen
Pressing a key or moving the mouse wakes up the desktop and shows the GDM greeter.
# Steps to reproduce
1. Lock the screen
2. Wait until the screen enter low power mode
3. Try to wake it up by moving the mouse or pressing a key on the keyboard.
# Environment
- Alpine Linux edge
- Intel integrated GPU (Mesa Intel® UHD Graphics 630 (CML GT2))
- GNOME 40.0 on Wayland
- GDM 40.0
# Logs
[greeter.log](/uploads/1b0a415a8a2978b4011bb906bed51295/greeter.log)Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10029Let python programs, which install files to /usr/lib/python3.X/, automaticall...2021-05-15T20:46:04ZOliver SmithLet python programs, which install files to /usr/lib/python3.X/, automatically depend on that python versionThis makes it easier to automatically find packages that need to be rebuilt after python was upgraded.This makes it easier to automatically find packages that need to be rebuilt after python was upgraded.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12587Fail2ban: ERROR unexpected EOF while parsing (<string>, line 1)2021-04-08T08:42:58ZEuro DomeniiFail2ban: ERROR unexpected EOF while parsing (<string>, line 1)Full error description:
```
alpin:~# cat /etc/alpine-release
3.13.4
alpin:~# apk version fail2ban
Installed: Available:
fail2ban-0.11.1-r4 = 0.11.1-r4
alpin:~# fail2ban-client -i
Fa...Full error description:
```
alpin:~# cat /etc/alpine-release
3.13.4
alpin:~# apk version fail2ban
Installed: Available:
fail2ban-0.11.1-r4 = 0.11.1-r4
alpin:~# fail2ban-client -i
Fail2Ban v0.11.1 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.
fail2ban> status sshd
2021-04-07 23:00:07,800 fail2ban [454]: ERROR unexpected EOF while parsing (<string>, line 1)
```
Also, encountered in 3.10. Latest working version was 3.7 ( maybe due to the fact that was using python2).
UPDATE:
I've used to test on 3.10 and fail2ban wasn't banning and I've wrongly assumed that 3.13 fails also, if _I've got fail2ban-client -i [474]: ERROR unexpected EOF while parsing (<string>, line 1)_
In fact, 3.13 works
```
# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 2
| `- File list: /var/log/messages
`- Actions
|- Currently banned: 1
|- Total banned: 2
`- Banned IP list: XX.YY.ZZ.WW
```
But there's an interface error.
```
~ # fail2ban-client -i
Fail2Ban v0.11.1 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.
fail2ban> stauts sshd
2021-04-08 08:35:55,028 fail2ban [474]: ERROR unexpected EOF while parsing (<string>, line 1)
```
So, there's a bug, but with low priority and without any impact on blocking functionality.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12582targetcli:adding missing modules for Raspberry PI2021-04-12T16:43:08ZFrancesco Colistatargetcli:adding missing modules for Raspberry PICan we the needed targetcli modules ``target_core_mod`` and ``iscsi_target_mod`` for Raspberry PI be built?`
```
~# apk add targetcli
fetch http://uk.alpinelinux.org/alpine/v3.13/main/aarch64/APKINDEX.tar.gz
fetch http://uk.alpinelinux....Can we the needed targetcli modules ``target_core_mod`` and ``iscsi_target_mod`` for Raspberry PI be built?`
```
~# apk add targetcli
fetch http://uk.alpinelinux.org/alpine/v3.13/main/aarch64/APKINDEX.tar.gz
fetch http://uk.alpinelinux.org/alpine/v3.13/community/aarch64/APKINDEX.tar.gz
(1/43) Installing libffi (3.3-r2)
(2/43) Installing gdbm (1.19-r0)
(3/43) Installing sqlite-libs (3.34.1-r0)
(4/43) Installing python3 (3.8.8-r0)
(5/43) Installing py3-six (1.15.0-r0)
(6/43) Installing py3-configobj (5.0.6-r7)
(7/43) Installing py3-urwid (2.1.2-r0)
(8/43) Installing py3-parsing (2.4.7-r1)
(9/43) Installing py3-configshell (1.1.26-r1)
(10/43) Installing py3-ethtool (0.14-r4)
(11/43) Installing py3-ipaddr (2.2.0-r5)
(12/43) Installing udev-init-scripts (34-r0)
Executing udev-init-scripts-34-r0.post-install
(13/43) Installing udev-init-scripts-openrc (34-r0)
(14/43) Installing eudev-libs (3.2.9-r3)
(15/43) Installing zstd-libs (1.4.5-r3)
(16/43) Installing kmod-libs (28-r0)
(17/43) Installing eudev (3.2.9-r3)
(18/43) Installing eudev-openrc (3.2.9-r3)
(19/43) Installing py3-udev (0.22-r0)
(20/43) Installing py3-rtslib (2.1_p72-r0)
(21/43) Installing py3-simpleparse (2.2.2-r0)
(22/43) Installing libintl (0.20.2-r2)
(23/43) Installing libmount (2.36.1-r1)
(24/43) Installing glib (2.66.7-r1)
(25/43) Installing py3-dbus (1.2.16-r2)
(26/43) Installing libxau (1.0.9-r0)
(27/43) Installing libbsd (0.10.0-r0)
(28/43) Installing libxdmcp (1.1.3-r0)
(29/43) Installing libxcb (1.14-r1)
(30/43) Installing libx11 (1.7.0-r0)
(31/43) Installing libxext (1.3.4-r0)
(32/43) Installing libxrender (0.9.10-r3)
(33/43) Installing brotli-libs (1.0.9-r3)
(34/43) Installing libpng (1.6.37-r1)
(35/43) Installing freetype (2.10.4-r1)
(36/43) Installing fontconfig (2.13.1-r3)
(37/43) Installing pixman (0.40.0-r2)
(38/43) Installing cairo (1.16.0-r2)
(39/43) Installing cairo-gobject (1.16.0-r2)
(40/43) Installing gobject-introspection (1.66.1-r0)
(41/43) Installing py3-gobject3 (3.38.0-r0)
(42/43) Installing targetcli (2.1.53-r0)
(43/43) Installing targetcli-openrc (2.1.53-r0)
Executing busybox-1.32.1-r5.trigger
Executing eudev-3.2.9-r3.trigger
OK: 117 MiB in 156 packages
~# rc-service targetcli start
* Caching service dependencies ... [ ok ]
* Starting targetcli ...
modprobe: module configfs not found in modules.dep
modprobe: module target_core_mod not found in modules.dep
modprobe: module iscsi_target_mod not found in modules.dep
mount: mounting none on /sys/kernel/config failed: Resource busy
b'modprobe: module target_core_mod not found in modules.dep\n' [ !! ]
* ERROR: targetcli failed to start
```
I dont' know if this has already been considered and not worthy to be added.
Thanks.
.: Francescohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12557Handling per-network interface specific services dependancies2021-03-30T22:11:18ZDermot BradleyHandling per-network interface specific services dependanciesCurrently there is no standard way to handle init.d services that depend on specific network interfaces.
However if the Openssh server is configured (in /etc/ssh/sshd_config) to bind to one or more specific IP addresses (via ListenAddre...Currently there is no standard way to handle init.d services that depend on specific network interfaces.
However if the Openssh server is configured (in /etc/ssh/sshd_config) to bind to one or more specific IP addresses (via ListenAddress) the /etc/init.d/sshd script detects this and indicates:
```
You are binding an interface in ListenAddress statement in your sshd_config!
You must add rc_need="net.FOO" to your /etc/conf.d/sshd
where FOO is the interface(s) providing the following address(es):
```
For now, as I am using static IP addressing, I have created multiple scripts in /etc/init.d, one per interface, derived from /etc/init.d/net-online that check that the interface is up, and have added a entry to /etc/conf.d/sshd:
```
rc_need="net-interface-<INTERFACENAME>"
```
which the relevant script then provides. I have also locally added such rc_need entries in the conf.d files for other network daemons that I'm binding to specific network interfaces and it now all works as expected.
This approach obviously works in the situation of knowing which interfaces will exist ahead of time and setting up the init.d scripts for them, and so it doesn't cater for "unknown" dynamic interfaces (i.e. different machines with different numbers or names of interfaces).
In the longer term @kaniini's and @skarnet's vision of s6 and ifupdown-ng would likely give the flexibility to provide per interface services dependancies (indeed per-SSID in the case of WiFi).
In the short to medium term I'm wondering how this issue can be addressed. The fact that the Openssh server package detects the need for a per-interface dependancy implies someone else previously thought of this issue.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12556Could JRuby depend on Jansi 2.x?2021-03-30T09:35:00Zomniomni+alpine@hack.orgCould JRuby depend on Jansi 2.x?Hi, I noticed that our `java-jansi-native` is very old, from 2013, and there exist a few more recent releases, the last from 2018.
However, upstream readme says "The Jansi Native library is deprecated and is now embedded inside Jansi 2....Hi, I noticed that our `java-jansi-native` is very old, from 2013, and there exist a few more recent releases, the last from 2018.
However, upstream readme says "The Jansi Native library is deprecated and is now embedded inside Jansi 2.x".
Should Jansi 2.x (currently 2.3.2) be packaged and `jruby` depend on that instead? I guess that's why `java-jansi-native` is there and would then be removed.Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12554discover-backend-apk: does not find all system updates2021-03-28T12:48:44ZAriadne Conillariadne@ariadne.spacediscover-backend-apk: does not find all system updatesWhen updating the system with Discover, some updates are missed.
For example, Discover says my system is up to date, but `apk list -u` shows 3 pending updates:
```
$ apk list -u
alsa-lib-dev-1.2.4-r2 x86_64 {alsa-lib} (LGPL-2.1-or-late...When updating the system with Discover, some updates are missed.
For example, Discover says my system is up to date, but `apk list -u` shows 3 pending updates:
```
$ apk list -u
alsa-lib-dev-1.2.4-r2 x86_64 {alsa-lib} (LGPL-2.1-or-later) [upgradable from: alsa-lib-dev-1.2.3.2-r1]
kde-cli-tools-5.21.3-r0 x86_64 {kde-cli-tools} ((GPL-2.0-only OR GPL-3.0-only) AND GPL-2.0-or-later AND GPL-2.0-only AND LGPL-2.1-only) [upgradable from: kde-cli-tools-5.20.5-r1]
alsa-lib-1.2.4-r2 x86_64 {alsa-lib} (LGPL-2.1-or-later) [upgradable from: alsa-lib-1.2.3.2-r1]
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/12553Enabling IPv6 in Docker via daemon.json breaks IPv6 connectivity on the host2022-10-16T11:55:37ZMax GashkovEnabling IPv6 in Docker via daemon.json breaks IPv6 connectivity on the host// This is my first time reporting bug to Alpine and I'm terribly sorry if I'm missing something.
Enabling IPv6 in Docker engine via daemon.json breaks IPv6 connectivity. To be exact, Docker removes default IPv6 route upon start.
Envir...// This is my first time reporting bug to Alpine and I'm terribly sorry if I'm missing something.
Enabling IPv6 in Docker engine via daemon.json breaks IPv6 connectivity. To be exact, Docker removes default IPv6 route upon start.
Environment:
```
# cat /etc/alpine-release
3.13.3
# docker info |fgrep 'Server Version'
Server Version: 20.10.3
# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
hostname tpl-alpine-docker
iface eth0 inet6 manual
# cat /etc/docker/daemon.json
{
"ipv6": true,
"fixed-cidr-v6": "fd00::/80"
}
```
IPv6 route table before docker restart with the config above:
```
# ip -6 route show
2400:4153:xxxx:xxxx::/64 dev eth0 metric 256 expires 0sec
fe80::/64 dev eth0 metric 256
default via fe80::ae44:f2ff:fe66:c7d4 dev eth0 metric 1024 expires 0sec
multicast ff00::/8 dev eth0 metric 256
```
Table after docker restart:
```
# ip -6 route show
2400:4153:xxxx:xxxx::/64 dev eth0 metric 256 expires 0sec
fd00::/80 dev docker0 metric 256
fd00::/80 dev docker0 metric 1024
fe80::/64 dev eth0 metric 256
fe80::/64 dev docker0 metric 256
anycast 2400:4153:xxxx:xxxx:: dev eth0 metric 0
anycast fe80:: dev eth0 metric 0
multicast ff00::/8 dev eth0 metric 256
# ping6 google.com
PING google.com (2404:6800:400a:807::200e): 56 data bytes
ping6: sendto: Network unreachable
```
Network seems to be fixed after placing default route back, but to be perfectly frank I don't know IPv6 well enough to be sure that this is correct fix:
```
# ip -6 route replace default via fe80::ae44:f2ff:fe66:c7d4 dev eth0
# ping6 google.com
PING google.com (2404:6800:400a:808::200e): 56 data bytes
64 bytes from 2404:6800:400a:808::200e: seq=0 ttl=116 time=6.018 ms
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10472Not able to install in a AMD CPU based VPS (Alpine version: 3.13.2)2022-11-11T17:36:41ZFengying ZhaoNot able to install in a AMD CPU based VPS (Alpine version: 3.13.2)I tried to install alpine Linux in my VPS by following this [tutorial](https://wiki.alpinelinux.org/wiki/Replacing_non-Alpine_Linux_with_Alpine_remotely).
CPU info:
```
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64...I tried to install alpine Linux in my VPS by following this [tutorial](https://wiki.alpinelinux.org/wiki/Replacing_non-Alpine_Linux_with_Alpine_remotely).
CPU info:
```
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 49
Model name: AMD EPYC 7K62 48-Core Processor
Stepping: 0
CPU MHz: 2595.124
BogoMIPS: 5190.24
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
L3 cache: 16384K
NUMA node0 CPU(s): 0
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 arat
```
After using `dd` command and reboot, Alpine Linux can not work properly.
When I use a 64-bit os image (alpine-virt-3.13.2-x86_64.iso), the kernel panic immediately after rebooting:
![CleanShot_2021-03-23_at_18.21.38_2x](/uploads/f4b6141cbd4951a9f83f4a0b2a035c9b/CleanShot_2021-03-23_at_18.21.38_2x.png)
When I use a 32-bit os image (alpine-virt-3.13.2-x86.iso), I can log into the system, but all the build-in apps (apk, setup-alpine...) does not work properly:
![CleanShot_2021-03-23_at_18.31.21_2x](/uploads/f94bb5087ccf68d839c869c6b7e0b0b8/CleanShot_2021-03-23_at_18.31.21_2x.png)
![CleanShot_2021-03-23_at_18.33.59_2x](/uploads/69b790dd941c9893f087c617c3025013/CleanShot_2021-03-23_at_18.33.59_2x.png)
By the way I have another instance on the same VPS hosting provider with intel CPU, and I can install Alpine Linux to that VPS properly, so I guess the issue is caused by AMD CPU (or virtualization on AMD CPU?).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10740adbdump produces invalid YAML2022-12-21T19:37:21ZAriadne Conillariadne@ariadne.spaceadbdump produces invalid YAMLThe YAML generated by `adbdump` applet does not generate YAML which validates when processed with `yq`.
For example, `./src/apk adbdump ./installed.adb | yq e '.packages[0]'` generates a document which fails validation if coreutils is i...The YAML generated by `adbdump` applet does not generate YAML which validates when processed with `yq`.
For example, `./src/apk adbdump ./installed.adb | yq e '.packages[0]'` generates a document which fails validation if coreutils is installed due to `/usr/bin/[`.
This is probably something @fabled is already aware of, but I figure opening a bug about it is better than not.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10739Split fetch I/O into separate process2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.spaceSplit fetch I/O into separate processIn the beginning, we used to use a separate process for fetches.
I think it would be nice to reimplement this in a way similar to `apt`, where there would be `/lib/apk/methods/http` and so on.
It would also be nice to drop root privile...In the beginning, we used to use a separate process for fetches.
I think it would be nice to reimplement this in a way similar to `apt`, where there would be `/lib/apk/methods/http` and so on.
It would also be nice to drop root privileges when fetching.v3.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/12531perl: crash on cross compile build with gcc 10.2.1_pre2-r0 and musl 1.1.24-r2...2021-03-21T23:03:09ZTherminoel.kuntze@thermi.consultingperl: crash on cross compile build with gcc 10.2.1_pre2-r0 and musl 1.1.24-r2 to AARCH64Crashes in miniperl test (make minitest) at build time
Stack trace:
```
thermi-probook:/aports$ gdb main/perl/src/perl-5.30.3/miniperl miniperl.crash
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: ...Crashes in miniperl test (make minitest) at build time
Stack trace:
```
thermi-probook:/aports$ gdb main/perl/src/perl-5.30.3/miniperl miniperl.crash
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-alpine-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main/perl/src/perl-5.30.3/miniperl...
warning: exec file is newer than core file.
[New LWP 446176]
Core was generated by `./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e <?>'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f6a75497aeb in __stack_chk_fail () from /lib/ld-musl-x86_64.so.1
(gdb) bt
#0 0x00007f6a75497aeb in __stack_chk_fail () from /lib/ld-musl-x86_64.so.1
#1 0x0000556995bb8256 in S_check_type_and_open ()
#2 0x0000556995bb8c4a in S_doopen_pm ()
#3 0x0000556995bbe799 in Perl_pp_require ()
#4 0x0000556995b85fd0 in Perl_runops_standard ()
#5 0x0000556995b1108a in Perl_call_sv ()
#6 0x0000556995b13514 in Perl_call_list ()
#7 0x0000556995af8358 in S_process_special_blocks ()
#8 0x0000556995b0c869 in Perl_newATTRSUB_x ()
#9 0x0000556995b0e53d in Perl_utilize ()
#10 0x0000556995b3bd14 in Perl_yyparse ()
#11 0x0000556995b17070 in perl_parse ()
#12 0x0000556995af7124 in main ()
```
Same with perl version 5.32.1 and 5.30.3.
```
thermi-probook:/aports$ gdb main/perl/src/perl-5.32.1/miniperl miniperl.crash
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-alpine-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main/perl/src/perl-5.32.1/miniperl...
[New LWP 14726]
Core was generated by `./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e <?>'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f6abcaf7aeb in __stack_chk_fail () from /lib/ld-musl-x86_64.so.1
(gdb) bt
#0 0x00007f6abcaf7aeb in __stack_chk_fail () from /lib/ld-musl-x86_64.so.1
#1 0x0000558d312c76e2 in S_check_type_and_open ()
#2 0x0000558d312c8109 in S_doopen_pm ()
#3 0x0000558d312ca702 in Perl_pp_require ()
#4 0x0000558d31294ed8 in Perl_runops_standard ()
#5 0x0000558d3121ac3a in Perl_call_sv ()
#6 0x0000558d3121d042 in Perl_call_list ()
#7 0x0000558d31201494 in S_process_special_blocks ()
#8 0x0000558d312159cd in Perl_newATTRSUB_x ()
#9 0x0000558d31217fed in Perl_utilize ()
#10 0x0000558d3124581b in Perl_yyparse ()
#11 0x0000558d3122101b in perl_parse ()
#12 0x0000558d31200114 in main ()
(gdb)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/12530Upgrade homer-api & homer-ui to 7.x2022-02-19T21:58:11Zomniomni+alpine@hack.orgUpgrade homer-api & homer-ui to 7.xI saw that `homer-ui` has a 7.8.1 release, `community/homer-ui` and `community/homer-api` are at 5.0.6, however I find no recent *Release* for `homer-api` at https://github.com/sipcapture/homer but the default branch is `homer7` and "HOM...I saw that `homer-ui` has a 7.8.1 release, `community/homer-ui` and `community/homer-api` are at 5.0.6, however I find no recent *Release* for `homer-api` at https://github.com/sipcapture/homer but the default branch is `homer7` and "HOMER 7.7 (Seven)" is mentioned at the top of the README.
I think `homer-ui` shouldn't be upgraded to latest release without also upgrading `homer-api` but I won't do it myself right now. I opened this issue to not forget and to inform someone who might want to take this on or comment on it.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12504[BUG] No /dev/zdX ZFS block devices for encrypted datasets after reboot2022-02-11T10:44:19Zbademux[BUG] No /dev/zdX ZFS block devices for encrypted datasets after rebootStep to reproduce:
1. Download latest Extended Alpine https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/x86_64/alpine-extended-3.13.2-x86_64.iso
2. Copy all files from alpine iso to USB drive formatted as a single efi partition.
3. Se...Step to reproduce:
1. Download latest Extended Alpine https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/x86_64/alpine-extended-3.13.2-x86_64.iso
2. Copy all files from alpine iso to USB drive formatted as a single efi partition.
3. Setup Alpine:
```ash
setup-alpine
apk add util-linux nano udev zfs
setup-udev
modprobe zfs
mount -o remount,rw /media/usb
dd if=/dev/random of=/media/usb/var.key bs=1 count=32
zpool create -f -o ashift=12 -o autotrim=on \
-O acltype=posixacl -O canmount=on -O compression=zstd -O dnodesize=auto -O normalization=formD -O relatime=on -O
zfs create -V 8G -b $(getconf PAGESIZE) -o compression=zle -o logbias=throughput -o sync=standard -o primarycache=metadata -o secondarycache=none -o com.sun:auto-snapshot=false -o encryption=aes-256-gcm -o keylocation=file:///media/usb/var.key -o keyformat=raw rpool/swap
udevadm trigger
#check zdX device with ls /dev/zd*
sed -i 's/MOUNT_EXTRA_OPTIONS=""/MOUNT_EXTRA_OPTIONS="-l"/' /etc/conf.d/zfs #load key on mount
rc-update add zfs-import sysinit
rc-update add zfs-mount sysinit
lbu ci && reboot
```
4. after the reboot there is no zdX devices (check zdX device with ls ```/dev/zd* ```)
Sorry for offtopic but it can be related looks like it is mandatory to run ``` zfs load-key -a ``` before encrypted, legacy-mountpoint dataset can be mounted by fstab. It will be nice if ``` zfs load-key -a ``` can be configured by /etc/conf.d/zfshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12486community/qemu: libvirt fails to pick up UEFI firmware2021-03-05T10:34:28ZJohn Longecommunity/qemu: libvirt fails to pick up UEFI firmwareOn Alpine 3.13, libvirt (via virt-manager) fails to detect UEFI firmware. It seems to be caused by a change in the file `/usr/share/qemu/firmware/60-edk2-x86_64.json` owned by the qemu package. On 3.11 and 3.12 this file contained absolu...On Alpine 3.13, libvirt (via virt-manager) fails to detect UEFI firmware. It seems to be caused by a change in the file `/usr/share/qemu/firmware/60-edk2-x86_64.json` owned by the qemu package. On 3.11 and 3.12 this file contained absolute file paths:
```
"filename": "/usr/share/qemu/edk2-x86_64-code.fd"
```
but on 3.13 this has changed to:
```
"filename": "share/qemu/edk2-x86_64-code.fd"
```
The fix is reverting to the old paths.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12482alpine 3.13 installer prints "Partiton id "vfat" is not supported"2021-11-19T14:15:31ZHenrik Riomaralpine 3.13 installer prints "Partiton id "vfat" is not supported"When installing alpine 3.13 in `lvmsys` mode the following is displayed on the screen
```
Partiton id "vfat" is not supported
```
Installation did run to completion and the system booted.
**Note** its an efi boot systemWhen installing alpine 3.13 in `lvmsys` mode the following is displayed on the screen
```
Partiton id "vfat" is not supported
```
Installation did run to completion and the system booted.
**Note** its an efi boot systemhttps://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10714Backport bot2021-05-26T22:16:22ZJ0WIBackport botWould be great to have a bot (similar to [this](https://github.com/rullzer/backportbot)) to create backport MRs from GitLab comments.Would be great to have a bot (similar to [this](https://github.com/rullzer/backportbot)) to create backport MRs from GitLab comments.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12479Cannot get apkovl via HTTPS in netboot virt kernel/ramdisk2021-02-25T23:12:27ZjiribCannot get apkovl via HTTPS in netboot virt kernel/ramdiskalpine-netboot-3.13.2-x86_64.tar.gz
I'm playing with netbooting Alpine Linux and I'd like to get my custom apkovl file via HTTPS but ramdisk fails:
```
+ '[' -z https://gist.github.com/jirib/2f6c054ba73018e9860ac60f784ca899/raw/2b6ebd9...alpine-netboot-3.13.2-x86_64.tar.gz
I'm playing with netbooting Alpine Linux and I'd like to get my custom apkovl file via HTTPS but ramdisk fails:
```
+ '[' -z https://gist.github.com/jirib/2f6c054ba73018e9860ac60f784ca899/raw/2b6ebd9f0d2c3d48b8b36b69708dffce3b544f8b/testbox.apkovl.tar.gz ]
+ is_url https://gist.github.com/jirib/2f6c054ba73018e9860ac60f784ca899/raw/2b6ebd9f0d2c3d48b8b36b69708dffce3b544f8b/testbox.apkovl.tar.gz
+ return 0
+ cat /sys/class/dmi/id/product_uuid
+ MACHINE_UUID=
+ url=https://gist.github.com/jirib/2f6c054ba73018e9860ac60f784ca899/raw/2b6ebd9f0d2c3d48b8b36b69708dffce3b544f8b/testbox.apkovl.tar.gz
+ url=https://gist.github.com/jirib/2f6c054ba73018e9860ac60f784ca899/raw/2b6ebd9f0d2c3d48b8b36b69708dffce3b544f8b/testbox.apkovl.tar.gz
+ ovl=/tmp/testbox.apkovl.tar.gz
+ wget -O /tmp/testbox.apkovl.tar.gz https://gist.github.com/jirib/2f6c054ba73018e9860ac60f784ca899/raw/2b6ebd9f0d2c3d48b8b36b69708dffce3b544f8b/testbox.apkovl.tar.gz
Connecting to gist.github.com (140.82.121.4:443)
ssl_client: gist.github.com: TLS connect failed
wget: error getting response: Connection reset by peer
+ ovl=
```
I see that `initramfs-virt` has no ssl certs at all.
```
$ bsdtar xOf /tmp/alpine-netboot-3.13.2-x86_64.tar.gz boot/initramfs-virt | bsdtar tf - etc/
etc
etc/apk
etc/apk/keys
etc/apk/keys/alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub
etc/apk/keys/alpine-devel@lists.alpinelinux.org-5243ef4b.rsa.pub
etc/apk/keys/alpine-devel@lists.alpinelinux.org-5261cecb.rsa.pub
etc/fstab
etc/group
etc/mdev.conf
etc/modprobe.d
etc/modprobe.d/aliases.conf
etc/modprobe.d/blacklist.conf
etc/modprobe.d/i386.conf
etc/modprobe.d/kms.conf
etc/passwd
```
Adding *ca-certificates** into `pkgs` seems to make no sense as packages are installed after apkovl is downloaded/extracted (which fails).
Wouldn't it make sense to add CA certs? Or am I doing something wrong here?https://gitlab.alpinelinux.org/alpine/aports/-/issues/12478openjdk8 tests fail for octave on x86 as libjava.so cannot find libjvm.so2021-02-26T09:45:41ZDuncan Bellamyopenjdk8 tests fail for octave on x86 as libjava.so cannot find libjvm.soArmv7 has no errors
Extract from octave build log:
```
libinterp/octave-value/ov-class.cc-tst .........................Error occurred during initialization of VM
5962Unable to load native library: Error loading shared library libjvm.s...Armv7 has no errors
Extract from octave build log:
```
libinterp/octave-value/ov-class.cc-tst .........................Error occurred during initialization of VM
5962Unable to load native library: Error loading shared library libjvm.so: No such file or directory (needed by /usr/lib/jvm/java-1.8-openjdk/jre/lib/i386/libjava.so)
5963make[3]: *** [Makefile:31680: check-local] Error 1
```