alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2020-05-18T07:21:52Zhttps://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/66unwritable ~/.abuild2020-05-18T07:21:52ZBart Ribbersunwritable ~/.abuildSince updating my docker-abuild like 2 weeks ago, I just can't use it anymore... Now everytime I run it I get `Error: unwritable ~/.abuild [drwxr-xr-x]`. If I remove the folder completely, same thing happens. If I set it to chmod 777, sa...Since updating my docker-abuild like 2 weeks ago, I just can't use it anymore... Now everytime I run it I get `Error: unwritable ~/.abuild [drwxr-xr-x]`. If I remove the folder completely, same thing happens. If I set it to chmod 777, same thing happens.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11572gvmd/ospd-openvas incomplete openrc config2020-05-25T06:55:22ZMoegvmd/ospd-openvas incomplete openrc configI did an alpine sys install, changing the repositories to edge in the process and doing a full upgrade afterwards. Then following the great write-up at https://wiki.alpinelinux.org/wiki/Setting_up_GVM11, not everything worked out of the ...I did an alpine sys install, changing the repositories to edge in the process and doing a full upgrade afterwards. Then following the great write-up at https://wiki.alpinelinux.org/wiki/Setting_up_GVM11, not everything worked out of the box.
@fcolista, I'm taking the liberty of notifying you directly as you seem to work with GVM at this time.
# `/etc/init.d/gvmd`
I had to manually add `postgresql` to both `depend` and `after`, otherwise gvmd did occasionally exit, being unable to connect to its database.
Also, I added the following section:
```sh
start_pre()
{
mkdir -p /run/gvmd
chown -Rc gvm /run/gvmd
}
```
This fixes errors about being unable to create the lockfile.
# `/etc/init.d/ospd-openvas`
As above, I added the following to fix lock file issues:
```sh
start_pre()
{
mkdir -p /run/ospd
}
```https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9998Detect broken symlinks after package() phase2020-05-26T18:31:30ZRasmus Thomsenoss@cogitri.devDetect broken symlinks after package() phaseWould be nice if abuild just flat out failed for theseWould be nice if abuild just flat out failed for thesehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11551[libtorrent] Needs a recompile - perpetually crashes due to buggy curl2020-05-27T21:11:09ZKyle Sanderson[libtorrent] Needs a recompile - perpetually crashes due to buggy curl[libtorrent] Needs a recompile - perpetually crashes due to buggy curl
Curl was crashy when libtorrent + rtorrent were built, these apps continually crash on 3.11. Just needs someone to trigger a rebuild and or bump the -r.[libtorrent] Needs a recompile - perpetually crashes due to buggy curl
Curl was crashy when libtorrent + rtorrent were built, these apps continually crash on 3.11. Just needs someone to trigger a rebuild and or bump the -r.Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11571[rpi4] ip=dhcp kernel command doesn't pickup ip because of down link2020-05-30T05:44:02Zflatterlight[rpi4] ip=dhcp kernel command doesn't pickup ip because of down linkHi,
when trying to boot a raspberry pi 4 with a remote apkovl in the kernelcommandline, the added "ip=dhcp" fail and I drop in an emergency shell.
The messages that I get without the "quiet" kernelparameter are
`...
* Obtaining IP via D...Hi,
when trying to boot a raspberry pi 4 with a remote apkovl in the kernelcommandline, the added "ip=dhcp" fail and I drop in an emergency shell.
The messages that I get without the "quiet" kernelparameter are
`...
* Obtaining IP via DHCP (eth0)...:
[2.638995] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[2.641868] bcmgenet fd580000.ethernet eth0: Link is Down
udhcpc: started, v1.31.1
udhcpc: socket(AF_PACKET,2,8): Address family not supported by protocol
failed
initramfs emergency recovery shell launched....
[7.741471] bcmgenet fd580000.ethernet eth0: Linkis Up - 1Gbps/Full - flowcontrol rt/tx`
It looks like the interface only gets up after the dhcp client fails. Where this need to get fixed that first the networkdriver (bcmgenet) gets executed and then the udhcpc gets executed?
Used hardware: raspberry pi 4 with poe hat
used software: current stable alpinelinux 3.11.6 raspberrypi image
If this post is wrong here please advice to the right place.
Thanks for your time.
Flatterlighthttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11136modloop verification fails with apline usb drive when local disk partition ha...2020-06-11T19:50:49Znicomodloop verification fails with apline usb drive when local disk partition has a alpine installationVersion: edge
- Generate Alpine USB drive with a `aports/scripts/mkimg.*` script (my test includes one custom apkovl)
- Boot from the USB Stick
On a clean HDD: Everything works as expected
On a HDD with some local alpine installation ...Version: edge
- Generate Alpine USB drive with a `aports/scripts/mkimg.*` script (my test includes one custom apkovl)
- Boot from the USB Stick
On a clean HDD: Everything works as expected
On a HDD with some local alpine installation (installed via `setup-bootable`):
Verification of modloop fails and the system boots into a broken state
It seems the modloop script at boot just scans the harddisks/mounts (probably before the usb stick itself) and thus chooses the wrong modloop file or at least it fails verification because some files from the local alpine install are used instead of those on the USB stick.
The error message at boot is `"Failed to verify signature of !"`, which indicates `$img` in `openrc/modloop.initd` is empty at the time when it is failing. Right before the error it explcitly showing that it is using the modloop file on /media/sda1/boot/modloop-lts which obviously is not existent. The USB Stick is sdb.
There is no way to restrict the USB alpine to not scan the local HDD. Initially I thought I could achieve this by setting the boot params to something like `alpine_dev=UUID=XXX-USBSTICK:vfat` but nothing works and `openrc/modloop.initd` also does not care about this parameter. Also wrongly I thought the problem was that only the wrong apkovl (local one) is used and because of that I played around with loads of boot parameters like `alpine_dev`, `ovl_dev`, `apkovl` and also combinations of those but nothing helped.
More details:
USB Stick created with:
```bash
profile_blah() {
profile_standard
profile_abbrev="blah"
title="blah"
desc="blah"
hostname="blah"
arch="x86_64"
kernel_addons=""
kernel_cmdline=""
local _k _a
for _k in $kernel_flavors; do
apks="$apks linux-$_k"
done
apks="$apks linux-firmware"
apks="$apks bash cfdisk dialog dosfstools e2fsprogs findutils kbd-bkeymaps openssh-keygen parted syslinux tar vim"
apkovl="genapkovl-blah.sh"
}
```
syslinux part:
```
MENU LABEL blah
KERNEL /boot/vmlinuz-lts
APPEND initrd=/boot/initramfs-lts modloop=/boot/modloop-lts modules=loop,squashfs,sd-mod,usb-storage waitusb=3 quiet
```
The alpine 3.1 with linux3.x.x-grsec locally is installed on /dev/sda1, vfat. USB stick is also vfat.
The (painful) workaround for me is to just delete the local partition table. But I would have to do that with another medium for obvious reasons.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11638community/junit missing dependency to hamcrest library2020-06-15T06:35:54ZHolger Jaekelcommunity/junit missing dependency to hamcrest libraryJUnit 4.12 depends on hamcrest-core 1.3, which is not even available as a package in Alpine. @itoffshore can you please help?JUnit 4.12 depends on hamcrest-core 1.3, which is not even available as a package in Alpine. @itoffshore can you please help?https://gitlab.alpinelinux.org/alpine/aports/-/issues/11669dhcp packet causes invalid mac address for host in arp cache, in virtualbox o...2020-06-19T19:57:15ZGKdhcp packet causes invalid mac address for host in arp cache, in virtualbox on natnetwork, can't ssh host/cifs
Unsure if this affects alpine only or in general to busybox
Its not clear to me what OS should do when a host and DHCP server share an ip-address but have different MAC-address. Fedora/gparted seems resilient to this issue as it has n...
Unsure if this affects alpine only or in general to busybox
Its not clear to me what OS should do when a host and DHCP server share an ip-address but have different MAC-address. Fedora/gparted seems resilient to this issue as it has not be encountered before with them
## Setup
* alpine-3.12 guest in Virtualbox-6.10 in Win 10 (2020.4) host
- VBOX-emulated NAT (10.1.WW.x) with VBOX emulated NAT services, (1 eth0).
This is not the "NAT" adapter but the "NATNetwork" adaptor. The "NAT Network" name is "NatNetworkWW". Then "NatNetworkWW" is configured for host forwarding in VBOX common tools preferences/network.
- smb/cifs shared folder from host, mounted using cifs-utils in alpine
- VBOX emulated network card (intel-pro/virtio-net) does not matter
- kernel linux-lts/linux-virt does not matter
## Symptom
Guest terminal is accessed via VBOX GUI.
* ssh to host from inside guest stops working. Also, new ssh connections cannot be made.
* CIFS/SMB df command, freezes for ~2min on the line of cifs-mount, omits/skips line of the mount
* ls /mnt/sharedir command freeze for ~2min without output
* The invalid arp entry uses a Virtualbox internal MAC address 08:00:27.x.y.z, hinting at a VBOX service such as DHCP-server
Virtualbox, by default, emulates a gateway on 10.1.WW.1, host on 10.1.WW.2, dhcp-server on 10.1.WW.2, first issued IP address is 10.1.WW.15
## Resolution
* one way resolve the problem is to issue "arp -d 10.1.WW.2" and retry commands/connection. After the entry is purged, the issue is temporarily resolved. The spoilt arp/issue reappears within a few minutes.
* final resolution:
The solution was to modify C:\Users\Admin\\.Virtualbox\Virtualbox.xml and change the emulated DHCP address from 10.1.WW.2 to a different IP 10.1.WW.5 and the DHCP range lower-IP-setting to 10.1.WW.15
### debug logs when ssh to host/smb working
```
# # notice that below the arp MAC-Adresses are the same
# arp -a
zzzhost (10.1.WW.2) at 52:XX:54:XX:35:00 [ether] on eth0
? (10.1.WW.1) at 52:XX:54:XX:35:00 [ether] on eth0
# ip route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.1.WW.1 0.0.0.0 UG 202 0 0 eth0
10.1.WW.0 * 255.255.255.0 U 0 0 0 eth0
# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether ZZ:ZZ:9c:b5:2c:14 brd ff:ff:ff:ff:ff:ff
inet 10.1.WW.15/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::13:9cff:feb5:xxxx/64 scope link
valid_lft forever preferred_lft forever
```
### debug logs when ssh to host/smb NOT working
```
# # notice the spurious MAC-Adress for host
zzzhost (10.1.WW.2) at 08:00:27:f9:07:98 [ether] on eth0
? (10.1.WW.1) at 52:XX:54:XX:35:00 [ether] on eth0
# ip route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.1.WW.1 0.0.0.0 UG 202 0 0 eth0
10.1.WW.0 * 255.255.255.0 U 0 0 0 eth0
# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether ZZ:ZZ:9c:b5:2c:14 brd ff:ff:ff:ff:ff:ff
inet 10.1.WW.15/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::13:9cff:feb5:xxxx/64 scope link
valid_lft forever preferred_lft forever
```
### debug logs after resolution
notice the the dhcp-server mac has its own ip-address 10.1.WW.5
```
# arp -a
? (10.1.WW.1) at 52:XX:54:XX:35:00 [ether] on eth0
? (10.1.WW.5) at 08:00:27:9e:52:85 [ether] on eth0
zzzhost (10.1.WW.2) at 52:XX:54:XX:35:00 [ether] on eth0
```
* on boot/login, MAC entry for zzzhost 10.1.WW.2 exists from the beginning
* the MAC entry for gateway 10.1.WW.1 appears after a wget of any webpage
* the MAC entry for dhcpserver 10.1.WW.5 appears after a few minutes
* CIFS/ssh is unaffected no matter the uptime
Also created vbox ticket
https://www.virtualbox.org/ticket/19675
https://gitlab.alpinelinux.org/alpine/aports/-/issues/11673main/grub: grub.trigger fails after apk add2020-06-22T04:37:48Zc705main/grub: grub.trigger fails after apk addHi, running latest edge release "from ram" i.e: from a live iso:
```
Linux alpine 5.4.47-0-lts #1-Alpine SMP Thu, 18 Jun 2020 14:54:31 UTC x86_64 Linux
3.12.0
```
Been having this problem for a week or so now
```
76bc[~]$ sudo apk del...Hi, running latest edge release "from ram" i.e: from a live iso:
```
Linux alpine 5.4.47-0-lts #1-Alpine SMP Thu, 18 Jun 2020 14:54:31 UTC x86_64 Linux
3.12.0
```
Been having this problem for a week or so now
```
76bc[~]$ sudo apk del grub ; sudo apk add grub
(1/1) Purging grub (2.04-r2)
Executing busybox-1.31.1-r21.trigger
OK: 1589 MiB in 484 packages
(1/1) Installing grub (2.04-r2)
Executing busybox-1.31.1-r21.trigger
Executing grub-2.04-r2.trigger
/usr/sbin/grub-probe: error: failed to get canonical path of `tmpfs'.
ERROR: grub-2.04-r2.trigger: script exited with error 1
OK: 1601 MiB in 485 packages
```
Seems the post trigger is borked:
Workaround:
```
76bc[~]$ sudo apk add --no-scripts grub
(1/1) Installing grub (2.04-r2)
OK: 1601 MiB in 485 packages
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/11683cross-compile rust2020-06-24T14:14:44ZAriadne Conillariadne@ariadne.spacecross-compile rustThis issue is tracking discussion & whatever we need to do to make rust cross-compile using the `$CTARGET` variable.
cc @CogitriThis issue is tracking discussion & whatever we need to do to make rust cross-compile using the `$CTARGET` variable.
cc @Cogitrihttps://gitlab.alpinelinux.org/alpine/infra/compose/appstream-generator/-/issues/1Validate AppStream data2020-06-28T19:15:25ZRasmus Thomsenoss@cogitri.devValidate AppStream dataBlocked on https://github.com/ximion/appstream-generator/issues/83Blocked on https://github.com/ximion/appstream-generator/issues/83Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11718main/ldb: test failures on ppc64le2020-07-17T04:52:56ZKevin Daudtmain/ldb: test failures on ppc64leAfter upgrading to [v2.1.4](4f5db102), ldb has [test failures](https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/ldb/ldb-2.1.4-r0.log) on ppc64le
```
Failed to connect to 'mdb://lmdb_free_list_test.ldb' with backend 'mdb':...After upgrading to [v2.1.4](4f5db102), ldb has [test failures](https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/ldb/ldb-2.1.4-r0.log) on ppc64le
```
Failed to connect to 'mdb://lmdb_free_list_test.ldb' with backend 'mdb': Unable to load ltdb cache records for backend 'ldb_mdb backend'
Could not run test: 0x1 != 0
[..]
Could not run test: 0x1 != 0
[ LINE ] --- ../../tests/ldb_lmdb_free_list_test.c:165: error: Failure!Test setup failed
```LeoLeohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11738Package mariadb scripts have bash shebang2020-07-17T11:11:22ZGhost UserPackage mariadb scripts have bash shebangHi,
the following by package mariadb provided scripts have a **bash shebang**.
The package doesn't have a bash dependency.
usr/bin/wsrep_sst_mariabackup
usr/bin/wsrep_sst_mysqldump
usr/bin/wsrep_sst_rsync
usr/bin/wsrep_sst_rsyn...Hi,
the following by package mariadb provided scripts have a **bash shebang**.
The package doesn't have a bash dependency.
usr/bin/wsrep_sst_mariabackup
usr/bin/wsrep_sst_mysqldump
usr/bin/wsrep_sst_rsync
usr/bin/wsrep_sst_rsync_wan
What do you mostly do? Add a **bash dependency** or change the shebang to **/bin/sh and fixing bashism**?
Markushttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10005can't install apk name provided by another apk from local repo2020-07-30T11:58:43ZMichal Artazovcan't install apk name provided by another apk from local repoI'm trying to build a subset of aports repo using `buildrepo` command for my own project. I have my repo in `/data/build/alpine-aports` and it's structure is almost the same as `aports` repo, i.e. there's `/data/build/alpine-aports/main`...I'm trying to build a subset of aports repo using `buildrepo` command for my own project. I have my repo in `/data/build/alpine-aports` and it's structure is almost the same as `aports` repo, i.e. there's `/data/build/alpine-aports/main` directory that contains one directory per package.
I built the entire repo running this command:
```
buildrepo -a /data/build/alpine-aports -d /data/build/alpine-aports/packages main
```
All the apks got built except for lldb which throws an error:
```
ERROR: unsatisfiable constraints:
ninja (virtual):
provided by: samurai
required by: .makedepends-lldb-20200730.114257[ninja]
>>> ERROR: lldb: builddeps failed
>>> lldb: Uninstalling dependencies...
ERROR: No such package: .makedepends-lldb
ERROR: lldb: Failed to build
```
After a little bit of digging I pinpointed the problem. When the apk is built, it first installs the make dependencies, which I can also do directly like this
```
cd main/lldb
APORTSDIR='/data/build/alpine-aports' REPODEST='/data/build/alpine-aports/packages' abuild deps
```
This fails as well with the same error. I dug even deeper and it fails when it's internally running this command:
```
abuild-apk add --wait 30 --repository '/data/build/alpine-aports/packages/main' --virtual .makedepends-lldb --quiet --simulate build-base clang-dev>=10 clang-static>=10 cmake doxygen libedit-dev libffi-dev libxml2-dev linux-headers llvm-dev>=10 llvm-static>=10 ncurses-dev ninja python3-dev swig
```
To make it simpler, since ninja is the problem, I just ran these 2 commands and I got the same error again from both of them:
```
apk add --repository '/data/build/alpine-aports/packages/main' --virtual tmptest ninja
apk add --repository '/data/build/alpine-aports/packages/main' ninja
```
So I can't install ninja from my local repo. Ninja doesn't exist but instead it's provided by samurai which replaced it a while ago. If I try to install it from official Alpine remote repo, it works:
```
apk add ninja
(1/1) Installing samurai (1.1-r0)
Executing busybox-1.31.1-r19.trigger
OK: 341 MiB in 74 packages
```
Also, if I try to install samurai directly from my local repo, it also works:
```
apk add --repository '/data/build/alpine-aports/packages/main' samurai
(1/1) Installing samurai (1.1-r0)
Executing busybox-1.31.1-r19.trigger
OK: 341 MiB in 74 packages
```
So I can install samurai from my local repo, which proves that my local repo isn't broken or something but I can't install ninja. But I can install ninja from remote repo. Very strange.https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10699migrate away from lists.a.o SourceHut implementation2020-08-05T08:56:01ZCarlo Landmetermigrate away from lists.a.o SourceHut implementationlists.a.o is no longer maintained according to the current maintainer.
/cc @kdaudtlists.a.o is no longer maintained according to the current maintainer.
/cc @kdaudtCarlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11834Supporting Multiboot USB Thumb drives2020-08-11T10:53:26ZJerome Landsman Supporting Multiboot USB Thumb drivesProjects like [GLIM](https://github.com/thias/glim/) enable users to create a
MultiBoot USB stick which boot into any one of several distros chosen by the
user.
It work by having the user place one or more Bootable ISOs in a special
dir...Projects like [GLIM](https://github.com/thias/glim/) enable users to create a
MultiBoot USB stick which boot into any one of several distros chosen by the
user.
It work by having the user place one or more Bootable ISOs in a special
directory. Then, GRUB2 scripts provided (by GLIM for example) dynamically
generate menus for the available ISO files. It's extremely convenient for
creating rescue thumb drives, or just keeping all the distros you care about
easily accessible.
Practically all major distros are supported by such projects, including
Ubuntu, Debian, Fedora, Mint, and Arch, etc'. Alpine Linux is currently
missing some simple pieces needed to support it.
To be supported, a distro must expose some basic boot param so that grub can
tell the init process where the ISO file is located. The init script of course
also has to handle this case when the boot param is provided.
I've created a customized init script which implements this. The changes are
quite small. I've tested it by replacing the init script inside
`alpine-standard-3.12.0-x86.iso` and adding a grub script to GLIM which adds
support for Alpine.
The changes from the alpine side cinsist of two new boo params `img_dev` and `img_file` (same as Arch). When passed by grub on the kernel command line, th e init scripts mounts `img_dev` and then loop
mount the `img_file` iso file on it. So, for example, I have
`img_dev=/dev/usbdisk` and `img_file=/boot/iso/alpine/alpine-standard-3.12.0-x86.iso`.
Included are:
1) The modified init script. Changed are marked by `XXX` (3 locations).
2) The grub2 script, for use with GLIM
3) A .png icon for use with GLIM's theme.
only (1) is relevant to Alpine developers, but since users may be interested
in reproducing this immediately, I've included the GLIM files as well.
Attached:
1. [init V3](/uploads/ad8b4c576fef14fa9c361d33c815bfdc/init)
2. [inc-alpine.cfg](/uploads/018fbfcc10abf6e1c6cddc6284174424/inc-alpine.cfg)
3. [alpine.png](/uploads/d20ebb72382f17fd85ce597ee77eb712/alpine.png)https://gitlab.alpinelinux.org/alpine/aports/-/issues/11837cfengine incosistent config dir names2020-08-11T14:24:33ZEleksircfengine incosistent config dir namesThere are 2 dirs that contains cfengine configs: cfengine and libntech.
```
root@cfe-client1:/var/lib# ls -l
total 20
drwxr-xr-x 2 root root 4096 May 29 17:20 apk
drwxr-xr-x 9 root root 4096 Aug 10 22:58 ...There are 2 dirs that contains cfengine configs: cfengine and libntech.
```
root@cfe-client1:/var/lib# ls -l
total 20
drwxr-xr-x 2 root root 4096 May 29 17:20 apk
drwxr-xr-x 9 root root 4096 Aug 10 22:58 cfengine
drwxr-xr-x 11 root root 4096 Aug 10 23:00 libntech
drwxr-xr-x 2 root root 4096 May 29 17:20 misc
drwxr-xr-x 2 root root 4096 May 29 17:20 udhcpd
```
In many installs there is only one dir here **/var/cfengine** (or /var/lib/cfengine) and no /var/lib/libntech. And because of specific way how cfengine handles its configs and evaluate it' variables on agent side i'm unable to run server, say, on centos7 or slackware and manage alpine boxes as clients for this server. In some random places of "promises" where evaluation happen on client side i've got an errors. So cfengine package on alpine can be considered as broken.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11842feat: plank: a simple dock2020-08-14T06:47:47Zsaltedcoffiifeat: plank: a simple dockPlease make and add apk files for plank, plank-docklets and dependences. Plank is a simple dock. Currently incompatible with wayland.
https://github.com/ricotz/plank
https://launchpad.net/plank
Plank requires dependencies some of whi...Please make and add apk files for plank, plank-docklets and dependences. Plank is a simple dock. Currently incompatible with wayland.
https://github.com/ricotz/plank
https://launchpad.net/plank
Plank requires dependencies some of which don't have apk files. I've identified one, bamf:
https://git.launchpad.net/bamf
https://launchpad.net/bamf
Thank you :)https://gitlab.alpinelinux.org/alpine/aports/-/issues/11867testing/perl-io-socket-timeout: test failures on x86, armv72020-08-18T16:35:16ZKevin Daudttesting/perl-io-socket-timeout: test failures on x86, armv7This package has test failures on armv7 and x86
```
# Failed test 'No tests run for subtest "test with no delays and no timeouts"'
# at t/timeout_setsockopt.t line 30.
setsockopt(SO_RCVTIMEO): Invalid argument at /home/buildozer/apo...This package has test failures on armv7 and x86
```
# Failed test 'No tests run for subtest "test with no delays and no timeouts"'
# at t/timeout_setsockopt.t line 30.
setsockopt(SO_RCVTIMEO): Invalid argument at /home/buildozer/aports/testing/perl-io-socket-timeout/src/IO-Socket-Timeout-0.32/blib/lib/IO/Socket/Timeout.pm line 46.
```
It has been disabled for now.
See: https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/perl-io-socket-timeout/perl-io-socket-timeout-0.32-r0.loghttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/9977Add CI checks2020-08-23T14:10:34ZOliver SmithAdd CI checksThe problem from https://gitlab.alpinelinux.org/alpine/abuild/commit/51d9e3bcb9fe99a67059e08d7b6fb6ca6a2b75c2 that made it all the way into Alpine edge could have been prevented with a basic check that builds a small package and tries to...The problem from https://gitlab.alpinelinux.org/alpine/abuild/commit/51d9e3bcb9fe99a67059e08d7b6fb6ca6a2b75c2 that made it all the way into Alpine edge could have been prevented with a basic check that builds a small package and tries to install it.
How about we add something like that, using gitlab CI?
This [hello-world](https://gitlab.com/postmarketOS/pmaports/tree/master/main/hello-world) package could be used for such testing purpose (possibly move the sources to an external location, so it tests downloading as well).