alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2023-01-24T18:06:43Zhttps://gitlab.alpinelinux.org/alpine/council/-/issues/7How to handle monetary contributions2023-01-24T18:06:43ZNatanael CopaHow to handle monetary contributionsSometimes people and organizations contact me and ask how to give monetary contributions. How do we handle those?Sometimes people and organizations contact me and ask how to give monetary contributions. How do we handle those?https://gitlab.alpinelinux.org/alpine/aports/-/issues/12865kodi-19.1-r0 segfault2021-08-05T10:52:03ZTim Cooperkodi-19.1-r0 segfaultkodi-standalone and frequently crashes while running.
kodi-19.1-r0
mesa-dri-classic-21.1.2-r0
```
Thread 1 "kodi-gbm" received signal SIGSEGV, Segmentation fault.
0x00007f2fb26346a7 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so...kodi-standalone and frequently crashes while running.
kodi-19.1-r0
mesa-dri-classic-21.1.2-r0
```
Thread 1 "kodi-gbm" received signal SIGSEGV, Segmentation fault.
0x00007f2fb26346a7 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
(gdb) bt
#0 0x00007f2fb26346a7 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#1 0x00007f2fb2639d5f in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#2 0x00007f2fb262e695 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#3 0x00007f2fb262f6f3 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#4 0x00007f2fb275607c in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#5 0x00007f2fb27554d1 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#6 0x0000564e2aac897b in CLinuxRendererGLES::DrawBlackBars() ()
#7 0x0000564e2aac8a7b in CLinuxRendererGLES::RenderUpdate(int, int, bool, unsigned int, unsigned int) ()
#8 0x0000564e2aac2200 in CRenderManager::Render(bool, unsigned int, unsigned int, bool) ()
#9 0x0000564e2ae96fc4 in CApplicationPlayer::Render(bool, unsigned int, bool) ()
#10 0x0000564e2ab4ad90 in CGUIWindowFullScreen::Render() ()
#11 0x0000564e2ad28eff in CGUIControl::DoRender() ()
#12 0x0000564e2ad6f78a in CGUIWindow::DoRender() ()
#13 0x0000564e2ad72b89 in CGUIWindowManager::RenderPass() const ()
#14 0x0000564e2ad72db3 in CGUIWindowManager::Render() ()
#15 0x0000564e2ae802d6 in CApplication::Render() ()
#16 0x0000564e2aef4387 in CXBApplicationEx::Run(CAppParamParser const&) ()
#17 0x0000564e2a901e5d in main ()
```https://gitlab.alpinelinux.org/alpine/tsc/-/issues/2deadline for packages in testing2023-11-08T07:26:24ZAriadne Conillariadne@ariadne.spacedeadline for packages in testingFrequently, `testing` gets packages contributed to it which never leave and just bitrot.
I would like to propose a deadline for packages in `testing`: they either get moved to `community` or `main`, or they get removed within some time ...Frequently, `testing` gets packages contributed to it which never leave and just bitrot.
I would like to propose a deadline for packages in `testing`: they either get moved to `community` or `main`, or they get removed within some time limit.
I think a deadline will also motivate packagers to more actively participate in the maintenance of their packages.
Thoughts?Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12850Package Request: py3-pytorch2024-02-19T18:38:38ZJ0WIPackage Request: py3-pytorch- https://pytorch.org/
- https://github.com/pytorch/pytorch- https://pytorch.org/
- https://github.com/pytorch/pytorchhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12848Package Request: py3-keras2022-09-28T11:34:09ZJ0WIPackage Request: py3-keras- https://keras.io/
- https://github.com/keras-team/keras- https://keras.io/
- https://github.com/keras-team/kerashttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12846XHCI controllers in QEMU do not work with USB redirection2022-08-10T19:00:06ZJohn SmithXHCI controllers in QEMU do not work with USB redirectionWhen I try to set up USB redirection for a QEMU VM, using the recommended "qemu-xhci" controller does not work. On the host, I get a "Speed mismatch" warning. On the guest, the USB device is not detected, and I get -110 errors in dmesg.
...When I try to set up USB redirection for a QEMU VM, using the recommended "qemu-xhci" controller does not work. On the host, I get a "Speed mismatch" warning. On the guest, the USB device is not detected, and I get -110 errors in dmesg.
This also happens with the "nec-usb-xhci" controller.
However, when I start the same VM with the same launch parameters on an Arch Linux install, I'm not encountering any issue.
Using the integrated controller on a q35 board ("-machine q35,usb=on") and removing the XHCI controller works, but then the performance is subpar. When trying to use both controllers, I'm getting the same errors.
My QEMU launch parameters:
```
qemu-system-x86_64 \
-smp sockets=1,cores=6,threads=1 \
-m 16G \
-cpu host,kvm=on \
-machine q35,accel=kvm,kernel_irqchip=on,vmport=off,sata=off,usb=off,graphics=off,firmware=/usr/share/ovmf/bios.bin \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-mem-prealloc \
-rtc base=utc,clock=host \
-device vfio-pci,host=01:00.0 \
-device virtio-blk-pci,id=blkos,discard=on,drive=osdisk \
-drive file=/dev/vg0/vmdisk,format=raw,if=none,discard=unmap,aio=native,cache=none,id=osdisk \
-netdev user,id=net4,ipv6=off \
-device virtio-net-pci,netdev=net4 \
-device qemu-xhci \
-device usb-host,vendorid=0x0bb4,productid=0x2210 \
-device usb-host,vendorid=0x0bb4,productid=0x2134 \
-device usb-host,vendorid=0x0bb4,productid=0x0306 \
-device usb-host,vendorid=0x0bb4,productid=0x2c87 \
-nographic \
-vga none \
-display none
```
Relevant guest dmesg output:
```
[ 30.769814] usb 5-4: New USB device found, idVendor=0409, idProduct=55aa, bcdDevice= 1.01
[ 30.769827] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 30.769834] usb 5-4: Product: QEMU USB Hub
[ 30.769839] usb 5-4: Manufacturer: QEMU
[ 30.769843] usb 5-4: SerialNumber: 314159-0000:00:08.0-4
[ 30.771176] hub 5-4:1.0: USB hub found
[ 30.771397] hub 5-4:1.0: 8 ports detected
[ 30.998127] usb 5-3: new full-speed USB device number 3 using xhci_hcd
[ 31.190125] usb 5-4.1: new full-speed USB device number 4 using xhci_hcd
[ 36.402124] usb 5-3: unable to read config index 0 descriptor/all
[ 36.402136] usb 5-3: can't read configurations, error -110
[ 36.682119] usb 5-3: new full-speed USB device number 5 using xhci_hcd
[ 42.033696] usb 5-3: unable to read config index 0 descriptor/all
[ 42.033708] usb 5-3: can't read configurations, error -110
[ 42.034928] usb usb5-port3: attempt power cycle
[ 42.385206] usb 5-3: new full-speed USB device number 6 using xhci_hcd
[ 47.665443] usb 5-3: unable to read config index 0 descriptor/all
[ 47.665454] usb 5-3: can't read configurations, error -110
[ 47.952141] usb 5-3: new full-speed USB device number 7 using xhci_hcd
```
I'm using Alpine Edge with the LTS kernel, with everything updated to the latest version (linux 5.10.50-0-lts, QEMU 6.0.0).https://gitlab.alpinelinux.org/alpine/aports/-/issues/12842no network on EspressoBin v7 EMMC with alpine-uboot-3.14.0-aarch642021-07-16T09:27:49ZKerma Géraldno network on EspressoBin v7 EMMC with alpine-uboot-3.14.0-aarch64I have modified `/etc/network/interfaces` as following :
```
auto eth0 ...I have modified `/etc/network/interfaces` as following :
```
auto eth0
iface eth0 inet manual
auto lo
iface lo inet loopback
auto wan
iface wan inet dhcp
pre-up /sbin/ifconfig wan up
auto lan1
iface lan1 inet dhcp
pre-up /sbin/ifconfig lan1 up
auto lan0
iface lan0 inet dhcp
pre-up /sbin/ifconfig lan0 up
```
But I get errors on restarting networking :
`alpine:~# /etc/init.d/networking restart`
```
* WARNING: you are stopping a boot service
* Stopping chronyd ...
[ ok ]
* Stopping networking ...
* lo ...
[ ok ]
* eth0 ...
[ ok ]
* Starting networking ...
* lo ...
[ ok ]
* eth0 ...
ip: ioctl 0x8913 failed: No such device
ip: can't find device 'eth0'
[ ok ]
* wan ...
ifconfig: ioctl 0x8913 failed: No such device
ifup: failed to change interface wan state to 'up'
[ !! ]
* lan1 ...
ifconfig: ioctl 0x8913 failed: No such device
ifup: failed to change interface lan1 state to 'up'
[ !! ]
* lan0 ...
ifconfig: ioctl 0x8913 failed: No such device
ifup: failed to change interface lan0 state to 'up'
[ !! ]
alpine:~# * Starting chronyd ...
[ ok ]
alpine:~#
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/12841dmesg mass logs on EspressoBin v7 EMMC with alpine-uboot-3.14.0-aarch642021-07-19T05:59:33ZKerma Géralddmesg mass logs on EspressoBin v7 EMMC with alpine-uboot-3.14.0-aarch64My first successful boot of alpine linux !
On EspressoBin v7 EMMC :
u-boot command line used to boot from usb stick (FAT32) filled with alpine-uboot-3.14.0-aarch64.tar.gz :
```
usb reset
load usb 0:1 $kernel_addr_r /efi/boot/bootaa64.efi...My first successful boot of alpine linux !
On EspressoBin v7 EMMC :
u-boot command line used to boot from usb stick (FAT32) filled with alpine-uboot-3.14.0-aarch64.tar.gz :
```
usb reset
load usb 0:1 $kernel_addr_r /efi/boot/bootaa64.efi
load usb 0:1 $fdt_addr_r /boot/dtbs-lts/marvell/armada-3720-espressobin-v7-emmc.dtb
bootefi $kernel_addr_r $fdt_addr_r
```
... BOOT OK Linux lts
```
Welcome to Alpine Linux 3.14
Kernel 5.10.43-0-lts on an aarch64 (/dev/ttyMV0)
alpine login: root
Welcome to Alpine!
The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <http://wiki.alpinelinux.org/>.
You can setup the system with the command: setup-alpine
You may change this message by editing /etc/motd.
```
dmesg give me mass of these 3 messages :
```
[ 209.288645] libphy: mdio: probed
[ 209.530371] mv88e6085 d0032004.mdio-mii:01: switch 0x3410 detected: Marvell 88E6341, revision 0
[ 209.530991] xenon-sdhci d00d0000.sdhci: Got CD GPIO
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/12840Kernel Panic on EspressoBin Ultra with alpine-uboot-3.14.0-aarch642021-07-15T07:30:52ZKerma GéraldKernel Panic on EspressoBin Ultra with alpine-uboot-3.14.0-aarch64```
[ 44.796570] ------------[ cut here ]------------
[ 44.801393] WARNING: CPU: 1 PI...```
[ 44.796570] ------------[ cut here ]------------
[ 44.801393] WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:624 rcu_eqs_enter.constprop.0+0x74/0x7c
[ 44.810382] Modules linked in: af_packet efi_pstore mwifiex_pcie mwifiex cfg80211 mv88e6xxx cpufreq_dt dsa_core rfkill armada_37xx_cpufreq phylink bridge stp llc ipv6 ahci_mvebu libahci_platform p
[ 44.864440] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 5.10.43-0-lts #1-Alpine
[ 44.873246] Hardware name: Marvell mvebu_armada-37xx/mvebu_armada-37xx, BIOS 2017.03-armada-18.09.1-g51aa6c4772 09/18/2019
[ 44.884652] pstate: 200003c5 (nzCv DAIF -PAN -UAO -TCO BTYPE=--)
[ 44.890861] pc : rcu_eqs_enter.constprop.0+0x74/0x7c
[ 44.895990] lr : rcu_idle_enter+0x1c/0x30
[ 44.900124] sp : ffff800011ad3f20
[ 44.903541] x29: ffff800011ad3f20 x28: 0000000000000000
[ 44.909023] x27: 0000000000000000 x26: ffff000000203c80
[ 44.914505] x25: 0000000000000000 x24: 0000000000000000
[ 44.919988] x23: ffff80001131b2f8 x22: ffff800010fc6670
[ 44.925474] x21: ffff80001131b2c0 x20: 0000000000000001
[ 44.930959] x19: ffff800010fb2000 x18: 0000000000000030
[ 44.936448] x17: 0000000000000000 x16: 0000000000000000
[ 44.941944] x15: ffffffffffffffff x14: 0000000000000000
[ 44.947466] x13: 0000000000000008 x12: 0000000000000040
[ 44.953016] x11: ffff000000401240 x10: 0000000000001a00
[ 44.958567] x9 : ffff8000109ff578 x8 : ffff0000002056e0
[ 44.964117] x7 : 00000000000000e3 x6 : 000000006f38e88f
[ 44.969668] x5 : 00ffffffffffffff x4 : ffff80002edc3000
[ 44.975216] x3 : 4000000000000002 x2 : 4000000000000000
[ 44.980765] x1 : ffff800010fc8900 x0 : ffff00003fd8b900
[ 44.986316] Call trace:
[ 44.988911] rcu_eqs_enter.constprop.0+0x74/0x7c
[ 44.993731] rcu_idle_enter+0x1c/0x30
[ 44.997566] default_idle_call+0x48/0x180
[ 45.001760] do_idle+0x238/0x2b0
[ 45.005143] cpu_startup_entry+0x34/0xa0
[ 45.009251] secondary_start_kernel+0x144/0x180
[ 45.013975] ---[ end trace e27e442d9407cb40 ]---
```https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/16multidisk crypt support2022-08-11T16:17:56Zmrpropermultidisk crypt supportI have a somewhat complicated setup which involves:
1. /boot on a usb that is luks encrypted
2. 2+ nvme disks luks encrypted with LVM over the top
3. logical volume root sitting inside 2.
4. /boot has a keyfile in the root "crypto_keyfil...I have a somewhat complicated setup which involves:
1. /boot on a usb that is luks encrypted
2. 2+ nvme disks luks encrypted with LVM over the top
3. logical volume root sitting inside 2.
4. /boot has a keyfile in the root "crypto_keyfile.bin" which is the key to unlock 2.
The problem:
"cryptroot" expects a singular blockdevice to contain the root filesystem, irrespective of the separated boot, with lvm striped over multiple luks crypted disks there is no current way to make sure multiple disks are decrypted first
I've been working on a patch that is actually a combination of a couple things:
https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/54
https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/57
But by adding 2 new style kopts
- cryptboot - this is for setting a UUID for unlocking a boot device that is mounted at /cryptboot during init
- cryptbootkey - this is for setting a path to a keyfile within the /cryptboot mount for unlocking cryptdevices
- cryptdevices - this is a list of UUID's/LABEL's
With the above you would set your root=/dev/vg0/root (or whatever it is)
setup cryptboot/cryptbootkey cryptdevices etc with the appropriate values.
The problem im having is that nlplug-findfs wants to do more than i want it to.
for example if i use:
```
+ for dev in $KOPT_cryptroot; do
+ case "$dev" in
+ UUID=*) mapping="luks-${dev#UUID=}";;
+ LABEL=*) mapping="luks-${dev#LABEL=}";;
+ *) mapping="luks-$(echo "$dev" | sed 's/\//-/g')";;
+ esac
+ echo "Unlocking $dev as $mapping"
+ nlplug-findfs $cryptopts -p /sbin/mdev ${KOPT_debug_init:+-d} -c "$dev" -m "$mapping" $KOPT_root
```
and that disk happens to be an lvm pv, it will try and activate it and break (because my example i have a root as a raid1 logical volume on 2 x striped pv's
If this is of interest or someone knows a better way of accomplishing this id be super excited to look into ithttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12816Package request: libraqm2021-07-03T12:48:39ZJ0WIPackage request: libraqmhttps://github.com/HOST-Oman/libraqm/
Required by `main/py3-pillow` 8.2.0+.https://github.com/HOST-Oman/libraqm/
Required by `main/py3-pillow` 8.2.0+.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12813lxc-attach causing unprivileged containers run by non-root to immediately cra...2021-11-22T22:14:15ZCheddoleumlxc-attach causing unprivileged containers run by non-root to immediately crash in Alpine 3.14Following on from this report in the LXC forum: [https://discuss.linuxcontainers.org/t/lxc-4-0-9-lxc-attach-cannot-allocate-memory/11171/6](https://discuss.linuxcontainers.org/t/lxc-4-0-9-lxc-attach-cannot-allocate-memory/11171/6), this ...Following on from this report in the LXC forum: [https://discuss.linuxcontainers.org/t/lxc-4-0-9-lxc-attach-cannot-allocate-memory/11171/6](https://discuss.linuxcontainers.org/t/lxc-4-0-9-lxc-attach-cannot-allocate-memory/11171/6), this seems now to be an Alpine issue.
After upgrading to 3.14, the command lxc-attach -n \<container\> results in an error dump including the string "Out of memory":
`lxc-attach: klystron: attach.c: lxc_attach: 1571 Out of memory - Failed to clone attached process
`
Upon checking the status of the container it is found to be not running. A trace of the command is attached below.
Retested using a snapshot of the previous, problem-free Alpine 3.13 installation, using the 4.0.9 lxc tools as distributed with Alpine 3.14, the problem is not reproducible; so the problem does not seem to be with lxc 4.0.9.
[klystron-strace.txt](/uploads/b65ae51a12c998d7200997aac6230664/klystron-strace.txt)https://gitlab.alpinelinux.org/alpine/aports/-/issues/12810the openrc script for miniupnpd is not working2021-07-04T18:09:20ZFengying Zhaothe openrc script for miniupnpd is not workinghttps://gitlab.alpinelinux.org/alpine/lua-aports/-/issues/3Subcommand to return names of parent packets of dependencies2021-06-29T23:48:10ZTherminoel.kuntze@thermi.consultingSubcommand to return names of parent packets of dependenciesIt'd be great to have something like that because recursive-deps right now only returns the verbatim $makedepends instead of the packages that build the particular $makedepends
E.g.
foo makedepends on bar-dev
The command should return ...It'd be great to have something like that because recursive-deps right now only returns the verbatim $makedepends instead of the packages that build the particular $makedepends
E.g.
foo makedepends on bar-dev
The command should return bar, instead of bar-dev.
That way one can use the output of the subcommand for a simple for loop to build all the dependencies and the packet itself.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12805patch asterisk dns resolver2023-03-23T20:59:49Z杨文 陈patch asterisk dns resolverasterisk use res_ninit which musl do not impl, can follow this [path](https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-connectivity/connman/connman/0002-resolve-musl-does-not-implement-res_ninit.patch) to fix th...asterisk use res_ninit which musl do not impl, can follow this [path](https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-connectivity/connman/connman/0002-resolve-musl-does-not-implement-res_ninit.patch) to fix the problem [here](https://github.com/asterisk/asterisk/blob/b4347c486150653ec7ce1d129e8f9017c69344da/main/dns.c#L583)
fix this error
```
ERROR[4641]: res_pjsip/config_system.c:267 system_create_resolver_and_set_nameservers: There are no local system nameservers configured, resorting to system resolution
ERROR[4641]: res_pjsip/config_system.c:267 system_create_resolver_and_set_nameservers: There are no local system nameservers configured, resorting to system resolution
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12804mkimg: standard image to boot on Intel/AMD devices2021-06-28T16:51:56ZKasper Kmkimg: standard image to boot on Intel/AMD devicesStandard image is not bootable as Extended, which is by design.
Since Extended includes a lot more stuff than to just make it boot with ramfs on baremetal, it would be nice to include Intel/AMD microcodes in the Standard image.Standard image is not bootable as Extended, which is by design.
Since Extended includes a lot more stuff than to just make it boot with ramfs on baremetal, it would be nice to include Intel/AMD microcodes in the Standard image.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10033Add script to automatically rebuild packages depending on a specific .so2021-10-13T20:46:27ZSören TempelAdd script to automatically rebuild packages depending on a specific .soWhat comes up a lot on IRC is people asking how to rebuild packages on soname version bumps. I think several developers have scripts in their `~/bin` for this purpose. Maybe it makes sense to add one of them to abuild itself to make it m...What comes up a lot on IRC is people asking how to rebuild packages on soname version bumps. I think several developers have scripts in their `~/bin` for this purpose. Maybe it makes sense to add one of them to abuild itself to make it more obvious/easier for people to automate package rebuilds.
Thoughts?
I personally have the following script from @ncopa in my `~/bin`:
```shell
#!/bin/sh
prog=$0
usage() {
cat <<EOF
rebuilds and commits packages since given commit
list of packages is read from stdin
usage: $prog: <since commit> <commit message>
example:
apk search -r --origin --exact -q foo-libs | $prog affadeadbeef 'rebuild against foo-libs-1.0'
EOF
exit 1
}
skip_noarch=false
dryrun=false
ignore_error=false
while getopts "nac" opt; do
case $opt in
n) dryrun=true;;
a) skip_noarch=true;;
c) ignore_error=true;;
esac
done
shift $(($OPTIND - 1))
[ $# -lt 2 ] && usage
since=$1
shift
msg=$1
shift
echo "reading packages from stdin..."
pkgs=$(while read i; do echo ${i##*/}; done)
echo "considering: $pkgs"
dirs=
for dir in $(ap builddirs $pkgs); do
if $skip_noarch && grep -q '^arch=.*noarch' $dir/APKBUILD; then
echo "skipping due to noarch: $dir"
continue
fi
changes=$(git log --format=oneline ${since}.. -- $dir)
[ -n "$changes" ] && continue
dirs="$dirs $dir"
done
echo "Rebuilding: $dirs" | tr ' ' '\n'
if $dryrun; then
exit 0
fi
for dir in $dirs; do
name=${dir##*/}
repodir=${dir%/*}
repo=${repodir##*/}
cd $dir
apkgrel -g -a ./APKBUILD
git add APKBUILD \
&& git commit -m "$repo/$name: $msg" \
|| { if ! $ignore_error; then exit 1; fi; }
done
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/12796Major upgrade of Ceph version is not mentioned in the 3.14.0 release notes2022-05-03T21:40:11ZAlain van HoofMajor upgrade of Ceph version is not mentioned in the 3.14.0 release notesThe upgrade of the Ceph packages from 15.x to 16.x is not mentioned in the SIGNIFICANT UPDATES part of the release notes. It has impact (high) in Ceph installations. So next time when a major Ceph version is upgraded, can it be put it in...The upgrade of the Ceph packages from 15.x to 16.x is not mentioned in the SIGNIFICANT UPDATES part of the release notes. It has impact (high) in Ceph installations. So next time when a major Ceph version is upgraded, can it be put it in the SIGNIFICANT UPDATES part of the release notes?Duncan BellamyDuncan Bellamyhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12792JRE/JDK 11 malfunctions on aarch642021-07-08T20:50:09ZJesse ChanJRE/JDK 11 malfunctions on aarch64`openjdk11` does not work properly on aarch64 platform.
It stuck randomly, seemingly related to network functions.
I observe the issue while trying to port Bazel to Alpine Linux (!22578).
Very interestingly, checks have been disabled...`openjdk11` does not work properly on aarch64 platform.
It stuck randomly, seemingly related to network functions.
I observe the issue while trying to port Bazel to Alpine Linux (!22578).
Very interestingly, checks have been disabled on the platform for a long while due to "These get stuck on the builders :/". (b039d1012b3676731ed179778f2732f7beebd611)
`openjdk13` is the first version that does not "stuck". `openjdk8` probably works as well given that the old Bazel aport uses it, and there was a successful aarch64 Bazel build.
Further investigation is needed, but here is all the info I have at the moment.
cc: @bratkartoffelSimon Fsimon-alpine@fraho.euSimon Fsimon-alpine@fraho.euhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12787Package request: npm-current2021-08-20T00:59:34ZLauri SvanPackage request: npm-currentAlpine Linux already packages Node.js 16.x as `nodejs-current`. While this is great, it is little to no use without having the associated package manager `npm`, which currently has the base `nodejs` (e.g. version 14) as a dependency.
Th...Alpine Linux already packages Node.js 16.x as `nodejs-current`. While this is great, it is little to no use without having the associated package manager `npm`, which currently has the base `nodejs` (e.g. version 14) as a dependency.
The suggestion is to build Node.js 16.x linked version as `npm-current`. The naming would be consistent with the other package and could easily be updated in tandem with updating `nodejs-current`
Node.js 16 is will be the actively maintained version starting next fall, https://nodejs.org/en/about/releases/ and I think it would be good if alpine packages were prepared for that.