aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2024-03-28T07:48:06Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15924virt-manager support for pytest 82024-03-28T07:48:06ZLeonardo Arenavirt-manager support for pytest 8virt-manager does not pass tests with pytest 8.x
This has been reported upstream: https://github.com/virt-manager/virt-manager/issues/648virt-manager does not pass tests with pytest 8.x
This has been reported upstream: https://github.com/virt-manager/virt-manager/issues/6483.20.0Leonardo ArenaLeonardo Arenahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15852gdm keyboard layout cannot be changed2024-03-13T17:15:27Zviba1gdm keyboard layout cannot be changed**Issue Description**
After installing GNOME on Alpine Linux and setting up the display manager to use GDM3, it has been observed that the login screen is set to QWERTY keyboard layout by default. This makes it impossible for users who d...**Issue Description**
After installing GNOME on Alpine Linux and setting up the display manager to use GDM3, it has been observed that the login screen is set to QWERTY keyboard layout by default. This makes it impossible for users who do not have a QWERTY keyboard or prefer another layout (such as AZERTY) to log in at first attempt. The problem persists even when trying to change the layout from the login screen, which does not provide any option to switch to an alternative keyboard layout.
**Steps to reproduce:**
Install gnome on alpine : [https://wiki.alpinelinux.org/wiki/GNOME](https://wiki.alpinelinux.org/wiki/GNOME)
Attempt to log in with non-QWERTY keyboard layout.
**Expected result:**
The GDM3 interface should allow users to choose their preferred keyboard layout during initial login before entering their password, regardless of whether they are using a QWERTY, AZERTY, DVORAK, or other keyboard layout.
**Actual result:**
GDM3 defaults to QWERTY keyboard layout without providing options to change it at the login screen, making it difficult or impossible for some users to enter their credentials correctly and complete the login process successfully.
**Additional information:**
Once a user logs in and opens their desktop session, GDM3 considers the correct keyboard layout configured in GNOME. However, upon reboot or disconnection of the user, the error recurs where only the QWERTY keyboard layout is available at the GDM3 login screen. Investigation is needed to address why GDM3 fails to remember the last used keyboard layout across boots or disconnects.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15846bemenu with wayland backend broken on phosh2024-03-24T07:57:45ZArnav Singhbemenu with wayland backend broken on phosh[bemenu v0.6.20 wants `zwlr_layer_shell_v1` v3](https://github.com/Cloudef/bemenu/commit/6bcffe408c1519834ed00abec4030b9d49f9a52c) but [phoc v0.36.0 only provides v2.](https://gitlab.gnome.org/World/Phosh/phoc/-/blob/v0.36.0/src/desktop....[bemenu v0.6.20 wants `zwlr_layer_shell_v1` v3](https://github.com/Cloudef/bemenu/commit/6bcffe408c1519834ed00abec4030b9d49f9a52c) but [phoc v0.36.0 only provides v2.](https://gitlab.gnome.org/World/Phosh/phoc/-/blob/v0.36.0/src/desktop.c?ref_type=tags#L57) (Newer phoc v0.37.0 or even its main branch also only provide v2.)
```sh
$ printf 'asd\nqwe\n' | WAYLAND_DEBUG=1 bemenu
[2920359.323] wl_registry@2.global(9, "zwlr_layer_shell_v1", 2)
[2920359.393] -> wl_registry@2.bind(9, "zwlr_layer_shell_v1", 3, new id [unknown]@6)
[2920362.814] wl_display@1.error(wl_registry@2, 0, "invalid version for global zwlr_layer_shell_v1 (9): have 2, wanted 3")
wl_registry@2: error 0: invalid version for global zwlr_layer_shell_v1 (9): have 2, wanted 3
```Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14954adduser shows uid '200' in use when the gid is in use2023-06-02T08:35:37ZSven Kirmessadduser shows uid '200' in use when the gid is in use`adduser` incorrectly reports the uid 200 to be already in use - the actual problem is that it tries to create a group with gid 200 and the gid is already in use.
The error message should read `adduser: gid '200' in use` or maybe even `...`adduser` incorrectly reports the uid 200 to be already in use - the actual problem is that it tries to create a group with gid 200 and the gid is already in use.
The error message should read `adduser: gid '200' in use` or maybe even `adduser: gid '200' in use by group nofiles` to make it clear what the problem is.
```
$ docker run --rm -it alpine sh
/ # adduser -u 200 test
adduser: uid '200' in use
/ # grep 200 /etc/passwd /etc/group
/etc/group:nofiles:x:200:
/ # adduser -u 200 -G nofiles -D test
```Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14592occasional hang on shutdown2023-01-27T11:25:58ZDominique Martinetoccasional hang on shutdownHello,
we've recently started using alpine on a slow arm board. Things mostly work fine, but running reboot or poweroff sometimes hang (looping reboot in a loop made our board hang once every 3 days or so, lovely bug to reproduce, espec...Hello,
we've recently started using alpine on a slow arm board. Things mostly work fine, but running reboot or poweroff sometimes hang (looping reboot in a loop made our board hang once every 3 days or so, lovely bug to reproduce, especially as most of the userspace is gone by the time the openrc process is stuck)
We've had the problem on alpine 3.16 and still have it on 3.17.
After analysis openrc is stuck in a malloc call, most certainly because it calls free() in its signal handler (and handles SIGCHLD while still allocating more stuff)
I've written about it directly on openrc issue tracker: https://github.com/OpenRC/openrc/issues/589
(analysis/earlier discussion on musl list here: https://www.openwall.com/lists/musl/2023/01/23/1 -- linked in openrc issue)
I'll send openrc a patch in a few days; might as well track this here as well meanwhile.
(Also, a couple of open questions:
- I guess people using rc_parallel are rare?
- I've read we wanted to convert to s6 eventually, but haven't seen anything concrete -- now I'm looking again I see s6-rc/s6-linux-init in main, are there known users of it on bare metal? s6-linux-init with openrc probably does not make that much sense speedup-wise but is probably easy enough to do, I'll probably give s6-rc a try in the next few weeks....)https://gitlab.alpinelinux.org/alpine/aports/-/issues/14525Problem with rxvt-unicode after upgrade to 9.31-r02023-01-21T17:54:47ZMogens JensenProblem with rxvt-unicode after upgrade to 9.31-r0After upgrading rxvt-unicode to 9.31-r0, several empty lines are now present at the top when opening a new terminal:
```
mogensj@localhost:~$
```
Normally no empty lines are present:
```
mogensj@localhost:~$
```
This is on the dwm ...After upgrading rxvt-unicode to 9.31-r0, several empty lines are now present at the top when opening a new terminal:
```
mogensj@localhost:~$
```
Normally no empty lines are present:
```
mogensj@localhost:~$
```
This is on the dwm window manager.
Anyone have an idea what could cause this?https://gitlab.alpinelinux.org/alpine/aports/-/issues/14162edge/helix: tree-sitter-grammars package out of sync.2024-01-22T18:37:36ZGregory Oakesedge/helix: tree-sitter-grammars package out of sync.The grammars provided by the package `tree-sitter-grammars` have an incompatible API with the currently packaged version of the package `helix`. The upstream solution to this is either to bundle the grammar files or for the user to compi...The grammars provided by the package `tree-sitter-grammars` have an incompatible API with the currently packaged version of the package `helix`. The upstream solution to this is either to bundle the grammar files or for the user to compile them with the assistance of helix (`hx -g fetch && hx -g build`). The former seems to be intentionally disabled as per the [APKBUILD](https://gitlab.alpinelinux.org/alpine/aports/-/blob/7a15b4127fc8075161d7b7448783035a023f400f/community/helix/APKBUILD#L28). The latter attempts to fetch into a root owned directory (`/usr/lib/tree-sitter`) which conflicts with the `tree-sitter-*` family of packages.
I don't personally have the bandwidth to spin up a build environment for Alpine, but I would like to propose a few options:
1. Update helix and going forward expect testing against each other is done when merging changes to `tree-sitter-*` or `helix` packages.
2. Bundle enable bundling the grammars in helix's APKBUILD and permit them to drift from the `tree-sitter-*` packages.
3. Move the [symlink](https://gitlab.alpinelinux.org/alpine/aports/-/blob/7a15b4127fc8075161d7b7448783035a023f400f/community/helix/APKBUILD#L56) in helix's APKBUILD to point to `/usr/local/share/helix-grammars` thus permitting the use of `hx -g fetch && hx -g build` without conflicting with the `tree-sitter-*` packages
# Expected
Helix would load without error the grammars shipped as part of the package `tree-sitter-grammar`.
# Actual
```console
$ hx foo.bash
thread 'main' panicked at 'Could not parse queries for language "bash". Are your grammars out of sync? Try running 'hx --grammar fetch' and 'hx --grammar build'. This query could not be parsed: QueryError { row: 48, column: 3, offset: 520, message: "expansion_flags", kind: NodeType }', helix-core/src/syntax.rs:384:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted
```Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14105GCC 12: Target specific option mismatch when inlining memcpy call2023-09-16T07:21:10ZSören TempelGCC 12: Target specific option mismatch when inlining memcpy callWhile trying to install the Haskell [Text package](https://hackage.haskell.org/package/text) using cabal I ran into the following error:
```
In file included from /usr/include/c++/12.1.1/cstring:42,
from simdutf.h:7,
...While trying to install the Haskell [Text package](https://hackage.haskell.org/package/text) using cabal I ran into the following error:
```
In file included from /usr/include/c++/12.1.1/cstring:42,
from simdutf.h:7,
from simdutf.cpp:4:
/usr/include/fortify/string.h: In function 'size_t simdutf::scalar::{anonymous}::utf16_to_utf8::convert_valid(const char16_t*, size_t, char*)':
/usr/include/fortify/string.h:39:27: error: inlining failed in call to 'always_inline' 'void* memcpy(void*, const void*, size_t)': target specific option mismatch
39 | _FORTIFY_FN(memcpy) void *memcpy(void *__od, const void *__os, size_t __n)
| ^~~~~~
simdutf.cpp:8578:15: note: called from here
8578 | ::memcpy(&v, data + pos, sizeof(uint64_t));
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This can be reproduced outside cabal with the following commands:
```
$ git clone https://github.com/haskell/text
$ git checkout 8f3c3fb577ba3d06849edfa4b92af0e36f0ec00f
$ cd simdutf
$ g++ -O2 -std=c++17 -c simdutf.cpp
```
Observations:
* This seems to be a regression introduced with the GCC 12 upgrade since the code compiled fine prior to that
* The issues disappears when compiling the code with `-march=native`, e.g. `g++ -O2 -march=native -std=c++17 -c simdutf.cpp`
Reporting this here to gather more information.
Furthermore, since Text is a popular Haskell package, this will cause us issues when rebuilding software like `pandoc` in the future.
Potentially related: #13735https://gitlab.alpinelinux.org/alpine/aports/-/issues/14079busybox acpid: ignores events if input event numbering is not contiguous2022-08-18T20:07:09Zmacmpibusybox acpid: ignores events if input event numbering is not contiguousHave noticed a problem with busybox `acpid` input scan in `/dev/input/event*`\
All is fine as long as event numbering is contiguous, but if there is a "hole" in-between, `acpid` does not take inputs after the hole.\
Exemple below where `...Have noticed a problem with busybox `acpid` input scan in `/dev/input/event*`\
All is fine as long as event numbering is contiguous, but if there is a "hole" in-between, `acpid` does not take inputs after the hole.\
Exemple below where `fuser` shows `event0` and `event1` are handled, but `event3` is ignored (`event2` missing), despite restarting `acpid`.
```
$ service acpid status
* status: started
$ ls /dev/input/
event0 event1 event3 mice mouse0
$ pidof acpid
4530
$ fuser /dev/input/event3
$ fuser /dev/input/event0
4530
$ fuser /dev/input/event1
4530
$ service acpid restart
* Stopping busybox acpid ... [ ok ]
* Starting busybox acpid ... [ ok ]
$ fuser /dev/input/event3
$ fuser /dev/input/event0
4613
```
This is quite annoying in situations where devices may come & go (like bluetooth keyboards, AVRCP,...), and therefore create such holes in event numbering.\
@jirutka any clue?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13754zabbix - we must hit refresh several times from screen elements2022-05-02T17:19:00ZPICCORO Lenz McKAYzabbix - we must hit refresh several times from screen elementsthe current alpine stable release (until 2023 it has LTS), has zabbix pacakge with some problems into the map desinger
we must hit several times f5 when there's lot of elements in screen, cos an alert said that width are invalid
![imag...the current alpine stable release (until 2023 it has LTS), has zabbix pacakge with some problems into the map desinger
we must hit several times f5 when there's lot of elements in screen, cos an alert said that width are invalid
![imagen](/uploads/91a62cef7f1f499d049e3928d8ddd3b4/imagen.png)https://gitlab.alpinelinux.org/alpine/aports/-/issues/13506Management agent version is not detected in Xen Orchestra2022-02-07T14:18:21ZForzaManagement agent version is not detected in Xen OrchestraHi,
I am not able to see the Management version in XCP-ng Center or in XOA using xe-guest-utilities-7.30.0-r2 on Alpine 3.14 and Alpine 3.15.
This is how it looks like from XOA:
![image](/uploads/0b7f714b6500aa390ecabcae9d23b69d/image...Hi,
I am not able to see the Management version in XCP-ng Center or in XOA using xe-guest-utilities-7.30.0-r2 on Alpine 3.14 and Alpine 3.15.
This is how it looks like from XOA:
![image](/uploads/0b7f714b6500aa390ecabcae9d23b69d/image.png)
This is how it looks like from XCP-ng Center - it fails to detect management agent:
![image](/uploads/ea0001c3833f3823e58c8f798fea79a9/image.png)
According to the developers of Xen Orchestra, there seems to be some missing strings compiled in the xe-guest-utilities: https://xcp-ng.org/forum/topic/5059/alpine-3-14-not-detected-correctly/3?_=1644241915917https://gitlab.alpinelinux.org/alpine/aports/-/issues/13480main/eudev: intermittent error after unplugging USB drive2022-01-28T23:31:18ZMogens Jensenmain/eudev: intermittent error after unplugging USB driveOn an Alpine edge x86_64 system, I noticed the following error in dmesg output, after unplugging a USB flash drive:
`udevd[2042]: inotify_add_watch(7, /dev/sda, 10) failed: No such file or directory`
The drive does not need to be mount...On an Alpine edge x86_64 system, I noticed the following error in dmesg output, after unplugging a USB flash drive:
`udevd[2042]: inotify_add_watch(7, /dev/sda, 10) failed: No such file or directory`
The drive does not need to be mounted, just inserting and removing it will generate the error, but not always, maybe 6 out of 10 times.
I don't know if this is a serious problem or just a harmless message, but it's not something I have seen before.Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13399community/retroarch: on a small screen, clicks happen higher than they're don...2022-01-08T16:00:18ZMike Banoncommunity/retroarch: on a small screen, clicks happen higher than they're done (+ can't exit without pkill)Experienced on Pinephone _(so - a smaller screen than Desktop)_Experienced on Pinephone _(so - a smaller screen than Desktop)_https://gitlab.alpinelinux.org/alpine/aports/-/issues/12971Kernel segfault when probing VIA VT6122 10/100/1000 driver2024-01-30T12:43:30ZJ RBKernel segfault when probing VIA VT6122 10/100/1000 driverAttempting to install Alpine-3.14.2 via USB always resulted in a kernel panic ( https://imgur.com/a/9vAaePD)
downloaded 3.12.8 and successfully booted, installed, rebooted.
change the repositories to use 3.14 and upgraded on-disk insta...Attempting to install Alpine-3.14.2 via USB always resulted in a kernel panic ( https://imgur.com/a/9vAaePD)
downloaded 3.12.8 and successfully booted, installed, rebooted.
change the repositories to use 3.14 and upgraded on-disk install, rebooted and again experienced a kernel panic.
edited boot parameters at grub to include init=/bin/ash and booted to edit /etc/rc.conf to enable interactive mode.
In doing so, aspects of networking, especially probing the associated driver, result in a kernel panic.
via-velocity is the module associated with the onboard VIA VT6122 Gigabit Ethernet controller.
Re-installing with 3.12.8 for nowNatanael CopaNatanael Copahttps://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/aports/-/issues/12783testing/guile-reader: missing /usr/lib/libguile-reader.so2024-03-26T13:20:46ZGeorge Hopkinstesting/guile-reader: missing /usr/lib/libguile-reader.so`guile-reader` does not ship with the symlink `/usr/lib/libguile-reader.so` which is needed for Guile to load the library:
```text
In unknown file:
4 (primitive-load-path "system/reader" #<procedure 7f148d…>)
In system/reader....`guile-reader` does not ship with the symlink `/usr/lib/libguile-reader.so` which is needed for Guile to load the library:
```text
In unknown file:
4 (primitive-load-path "system/reader" #<procedure 7f148d…>)
In system/reader.scm:
64:0 3 (_)
In unknown file:
2 (load-extension "/usr/lib/libguile-reader" "scm_reader_…")
In system/foreign-library.scm:
183:4 1 (load-foreign-library _ #:extensions _ # _ #:search-path …)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure load-foreign-library: file: "/usr/lib/libguile-reader", message: "file not found"
```
Temporary fix: `ln -s libguile-reader.so.1 /usr/lib/libguile-reader.so`Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12368Raspberry Pi fails to boot when volume label is "boot" (e.g. after overwritin...2022-07-31T00:10:53ZAlex Xu (Hello71)Raspberry Pi fails to boot when volume label is "boot" (e.g. after overwriting Raspbian)Raspberry Pi fails to boot and repeatedly blinks LED 7 times, meaning "kernel not found". If `BOOT_UART=1` is set, the messages "Failed to load &#39;boot/initramfs-rpi&#39; - initramfs disabled" and "No compatible kernel found" are print...Raspberry Pi fails to boot and repeatedly blinks LED 7 times, meaning "kernel not found". If `BOOT_UART=1` is set, the messages "Failed to load 'boot/initramfs-rpi' - initramfs disabled" and "No compatible kernel found" are printed to serial. This is caused by the volume label being "boot", which Raspbian/Raspberry Pi OS have in their official images: https://github.com/RPi-Distro/pi-gen/blob/225f69828fa05361d6028edf2d7a69db73fe2b45/export-image/prerun.sh#L77.
Many, many users have fallen for this: #10302, #10443, #10930, #12031, #12066, and #12361 at least, plus most likely #9979, #10407, and #11779.
The direct fix is to set the volume label to anything other than "boot". mkfs.fat sets the volume label to "NO NAME" by default, and I don't think any major operating systems use "boot". To change an existing filesystem from Linux, fatlabel will do the job: `fatlabel /dev/sdX ALPINE` for example. However, I think we should rename the boot directory in order to mitigate this footgun. In the long term, I agree that we should move to image-based distribution anyways.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12242GDC broken on 32-bit2022-08-20T10:44:58ZLeoGDC broken on 32-bit```
meson.build:1:0: ERROR: Executables created by D compiler gdc are not runnable.
``````
meson.build:1:0: ERROR: Executables created by D compiler gdc are not runnable.
```Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12090Golang 1.12 code can't convert JST timezone on an alpine docker image with a...2020-12-13T11:54:03Zdeveloper-kikikaikaiGolang 1.12 code can't convert JST timezone on an alpine docker image with a tzdata later 2020c-r0Hi, I'm using an alpine docker image && golang 1.12. It has some codes to convert JST timezone.
It had been running to convert JST timezone such as `2020-11-08 00:04:05 +0900 JST` before the middle of the last month.
But it hasn't b...Hi, I'm using an alpine docker image && golang 1.12. It has some codes to convert JST timezone.
It had been running to convert JST timezone such as `2020-11-08 00:04:05 +0900 JST` before the middle of the last month.
But it hasn't been running from the end of the last month. It converts as `2020-11-07 15:04:05 +0000 +0000`.
I've tried to use some images in a [code](https://github.com/developer-kikikaikai/alpine_tzdata_investigation), and gotten following results. It seems to be on the `alpine`, `tzdata later 2020c-r0` and `go 1.12`.
|go version|docker image|tzdata|result|note|
|:----|:-----|:----|:----|:---|
|1.12|alpine 3.12.1|tzdata 2020c-r0|failure|Please look the versions at [dockerhub](https://hub.docker.com/_/alpine) and [alpine package](https://pkgs.alpinelinux.org/packages?name=tzdata&branch=v3.12)|
|1.12|alpine 3.10.3|tzdata 2020c-r0|failure||
|1.12|alpine edge|tzdata 2020d-r0|failure||
|1.12|alpine 3.8|tzdata 2020a-r0|success||
|1.12|ubuntu 20.04|tzdata 2020d-0ubuntu0.20.04|success|Please look the versions at [dockerhub](https://hub.docker.com/_/ubuntu) and [Ubuntu packages](https://packages.ubuntu.com/focal/tzdata)|
|1.15.4(golang:alpine image)|alpha 3.12.1|tzdata 2020c-r0|success|Please look the golang version at [golang dockerhub]|
|1.13|alpine 3.12.1|tzdata 2020c-r0|success||
I'm glad if I can use the latest alpine and go 1.12 with correct timezone conversion.
(I can avoid it if I use golang over 1.13, or use tzdata2020a-r0 (getting from 2020a-r0 as the [Dockerfile](https://github.com/developer-kikikaikai/alpine_tzdata_investigation/blob/master/Dockerfile.success.usetzdata-2020a).)https://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
```LeoLeo