alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-21T12:07:36Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10984meson: openssl_static dependency in libfetch results in double linking2024-03-21T12:07:36ZDaniel Kolesameson: openssl_static dependency in libfetch results in double linkingThe recent changes brought in a libfetch dependency on openssl, however this results in openssl for now harmlessly being linked twice. Worse would be if it tried to link the second openssl statically, which it does not for now. Either wa...The recent changes brought in a libfetch dependency on openssl, however this results in openssl for now harmlessly being linked twice. Worse would be if it tried to link the second openssl statically, which it does not for now. Either way, it should only link once.
potential patch:
```
From 58feb1d66f8ec5e1f607dabd8c83ae725c3dc1ac Mon Sep 17 00:00:00 2001
From: q66 <q66@chimera-linux.org>
Date: Thu, 21 Mar 2024 12:04:58 +0100
Subject: [PATCH] libfetch: fix openssl dependency specification
We shouldn't include the full static linkage as it may accidentally
bring static openssl into the apk link path. We only care about the
includes here, so do that.
---
libfetch/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libfetch/meson.build b/libfetch/meson.build
index 7406fbb..59ea789 100644
--- a/libfetch/meson.build
+++ b/libfetch/meson.build
@@ -38,7 +38,7 @@ libfetch = static_library(
'fetch',
libfetch_src,
c_args: libfetch_cargs,
- dependencies: openssl_static_dep,
+ dependencies: openssl_dep.partial_dependency(compile_args: true, includes: true),
)
libfetch_dep = declare_dependency(
--
2.44.0
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15879testing/wine-staging - WineD3D is broken2024-03-21T10:14:14ZLassebqtesting/wine-staging - WineD3D is broken## Package Information
* Package name: wine-staging
* Package version: 9.4.1-r0
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
## Summary
DirectX games have graphical glitches when using built-in WineD3D DirectX t...## Package Information
* Package name: wine-staging
* Package version: 9.4.1-r0
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
## Summary
DirectX games have graphical glitches when using built-in WineD3D DirectX to OpenGL translation layer. This does not happen with DXVK installed in the prefix.
## Steps to reproduce
- Disable DXVK if installed (change library overrides for dx-related DLLs to built-in in winecfg)
- Run a DirectX game
To make sure that this isn't a bug with mesa-opengl, I decided to run wine with zink. Issue persists.
This does not happen with wine-staging 8.21 (Tested on Arch Linux). And I'm also unable to reproduce this bug on wine 9.0-r0 from community repo.Matthias Ahouansoumatthias@ahouansou.czMatthias Ahouansoumatthias@ahouansou.czhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15898GNOME 46 backgrounds require `libjxl-pixbuf-loader`2024-03-21T07:44:18ZAngelo Verlain ShemaGNOME 46 backgrounds require `libjxl-pixbuf-loader`<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue....<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue.
Also note that this repository is intended for reporting issues with packages.
For other components, separate issue trackers exist:
* Installer issues: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
* Infrastructure issues: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues
* Initramfs issues: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues
-->
## Package Information
* Package name: *libjxl-pixbuf-loader*
* Package version: *0.9.1-r0*
* Alpine version: *3.20.0_alpha20240315*
* Alpine architecture: *x86_64*
## Summary
The new GNOME 46 `gnome-backgrounds` package ships many wallpapers in JXL format. This includes the default wallpaper. However, the package `libjxl-pixbuf-loader` required for loading these files is missing as dependency of `gnome-backgrounds`.
This is a followup to #15863
cc @andypost
## Steps to reproduce
*If applicable, please provide instructions to reproduce the issue.*https://gitlab.alpinelinux.org/alpine/aports/-/issues/15895packaging 'dotnet' based software do we have a standard way yet?2024-03-21T06:53:13ZBjörn Strömbergpackaging 'dotnet' based software do we have a standard way yet?as we have dotnet6-runtime/sdk in v3.18/9 and will have dotnet8-runtime/sdk in v3.20 in a while..
* have there been any packaging of dotnet alpine packages yet to flesh out the gremlins of nuget -> apk when it comes to shared packages?...as we have dotnet6-runtime/sdk in v3.18/9 and will have dotnet8-runtime/sdk in v3.20 in a while..
* have there been any packaging of dotnet alpine packages yet to flesh out the gremlins of nuget -> apk when it comes to shared packages?
* is this something we want?
* or is native (AOT) output good enough?
i know three paths:
* dotnet build with nuget to fetch dependencies (shared libs but duplicated per application, pretty much like how a windows app installation looks, and its horrible waste of space)
* dotnet build with nuget to fetch dependencies (AOT) with native output (much static linking, producing large binaries, with a few so files, not as bad as the previous one. the likely solution in the short term
* apk based install of dynamic libraries from nuget and somehow getting everything to work (sounds like an utopia, but we do it like that with pypi etc so i guess its a question if its worth the work?)
any input in the matter? @ayakael or anyone else using dotnet?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15896community/kgamma5: package no longer exists2024-03-21T05:05:48ZPatrycja Rosaalpine@ptrcnull.mecommunity/kgamma5: package no longer exists`kgamma5` is included in explicitly `setup-desktop` - its removal causes existing setups to keep an orphaned package in apk world, not being able to do anything with it and potentially blocking dependencies, but also making existing inst...`kgamma5` is included in explicitly `setup-desktop` - its removal causes existing setups to keep an orphaned package in apk world, not being able to do anything with it and potentially blocking dependencies, but also making existing installations fail on `apk add` and being very sad about it:
![image](/uploads/e20d3d2c1cd67f63ead23b03619089bb/image.png)Bart RibbersBart Ribbershttps://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10814wiki is not responsive2024-03-20T20:01:52ZAngelo Verlain Shemawiki is not responsiveHello everyone!
I've been consulting the Alpine wiki a lot but found it's very unresponsive and almost unusable on mobile. I didn't know how else to report this issue and hope it will get to the relevant maintainers of the wiki.
For ex...Hello everyone!
I've been consulting the Alpine wiki a lot but found it's very unresponsive and almost unusable on mobile. I didn't know how else to report this issue and hope it will get to the relevant maintainers of the wiki.
For example here is the wiki on mobile:
| alpine wiki | postmarketos wiki |
| ------ | ------ |
| not responsive | responsive |
| ![Screenshot_20240218-050425](/uploads/f7e73dbc80b9f6c57852e28709119ba8/Screenshot_20240218-050425.png) | ![Screenshot_20240218-050419](/uploads/957ac6de222608a5c6d69fd3a8462db3/Screenshot_20240218-050419.png) |
Compared to the postmarketOS wiki:https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10901Enhancement: Simplify the Makefile, don't delete it2024-03-20T19:41:57ZBharatvaj HemanthEnhancement: Simplify the Makefile, don't delete itHi I've been trying to build apk-tools on mac osx but couldn't using the recommended meson build tools. Had an issue with finding the openssl while compiling libfetch. Then I tried with `make` and it didn't work either.
I then wrote a M...Hi I've been trying to build apk-tools on mac osx but couldn't using the recommended meson build tools. Had an issue with finding the openssl while compiling libfetch. Then I tried with `make` and it didn't work either.
I then wrote a Makefile based on the meson.build file and finally I was able to build it for mac.
[Makefile](/uploads/8e594233fa5231bf07cd70bf868009a2/Makefile)
[config.mk](/uploads/4a973489f47456117c30512ff14b9d17/config.mk)
Since `apk` is such a fundamental part of the base system, and as meson requires a separate package of it's own and python. I suggest to keep the Makefile around instead of deleting in the 3.0.0 version. I would like to work on it and maintain it, if the core maintainers agree on this.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10973apk3: unversioned virtual providers are broken2024-03-20T19:28:11ZDaniel Kolesaapk3: unversioned virtual providers are brokenI created 3 packages, `testp`, `testq`, and `testr`. The first two provide an unversioned name `foopkg` while the latter depends on it.
Trying to install `testr` behaves correctly at first:
```
root@cbuild: ~$ apk add testr
ERROR: unab...I created 3 packages, `testp`, `testq`, and `testr`. The first two provide an unversioned name `foopkg` while the latter depends on it.
Trying to install `testr` behaves correctly at first:
```
root@cbuild: ~$ apk add testr
ERROR: unable to select packages:
foopkg (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: testp testq
required by: testr-0.1-r0[foopkg]
```
I get asked to select one of the providers. I install one:
```
root@cbuild: ~$ apk add testp
The following NEW packages will be installed:
testp
After this operation, 4096 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Installing testp (0.1-r0)
OK: 606 MiB in 57 packages
```
However, when I try to install `testr` again after that, I get the following:
```
root@cbuild: ~$ apk add testr
ERROR: unable to select packages:
testp-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testp]
```
Installing the other provider as well breaks in the same way:
```
root@cbuild: ~$ apk add testq
The following NEW packages will be installed:
testq
After this operation, 4096 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Installing testq (0.1-r0)
OK: 606 MiB in 58 packages
root@cbuild: ~$ apk add testr
ERROR: unable to select packages:
testp-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testp]
testq-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testq]
```
The dependency specifications are fine:
```
root@cbuild: ~$ apk info --provides testp
testp-0.1-r0 provides:
foopkg
root@cbuild: ~$ apk info --provides testq
testq-0.1-r0 provides:
foopkg
root@cbuild: ~$ apk info --depends testr
testr-0.1-r0 depends on:
foopkg
```
Specifying the provider at add time does not help either:
```
root@cbuild: ~$ apk add testr testp
ERROR: unable to select packages:
testp-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testp]
testq-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testq]
```v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10982apk3: conflicts are broken since recently2024-03-20T18:37:56ZDaniel Kolesaapk3: conflicts are broken since recentlySome of the recent changes broke package conflicts. Instead, the `!` is stripped and it's considered a dependency. The actual package metadata in adb is still correct.Some of the recent changes broke package conflicts. Instead, the `!` is stripped and it's considered a dependency. The actual package metadata in adb is still correct.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15893community/wezterm: conflicts with community/foot2024-03-20T16:34:33ZIngacommunity/wezterm: conflicts with community/foot## Package Information
* Package name: community/wezterm, community/foot
* Package version: wezterm-20240203.110809-r0 and foot-1.16.2-r1 respectively
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
## Summary
com...## Package Information
* Package name: community/wezterm, community/foot
* Package version: wezterm-20240203.110809-r0 and foot-1.16.2-r1 respectively
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
## Summary
community/wezterm depends on community/wezterm-common which depends on community/wezterm-extra-terminfo which provides /usr/share/terminfo/w/wezterm.
community/foot depends on main/ncurses-terminfo which provides /usr/share/terminfo/w/wezterm.
So now when I have both foot and wezterm upgraded to the latest version, my `apk -s upgrade` produces results like that:
```
(1/3) Upgrading zstd-libs (1.5.5-r8 -> 1.5.5-r9)
(2/3) Upgrading giflib (5.2.1-r5 -> 5.2.2-r0)
(3/3) Upgrading linux-lts (6.6.22-r0 -> 6.6.22-r1)
1 error; 2690 MiB in 607 packages
```
## Steps to reproduce
Not sure if this is reproducible on a fresh install; maybe it just won't let you to install one of these two when another is already installed?
(I had them both installed before that conflict, so it broke for me during the upgrade.)Matthias Ahouansoumatthias@ahouansou.czMatthias Ahouansoumatthias@ahouansou.czhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10980apk3: segfaults since recent updates2024-03-20T15:06:42ZDaniel Kolesaapk3: segfaults since recent updatesTried to update in Chimera from c8c9df1825760e558f44397500af2a2f4bca18d4 to latest master.
Immediately encountered a segfault:
```
root@cbuild: ~$ apk add perl
The following NEW packages will be installed:
less perl
After this operat...Tried to update in Chimera from c8c9df1825760e558f44397500af2a2f4bca18d4 to latest master.
Immediately encountered a segfault:
```
root@cbuild: ~$ apk add perl
The following NEW packages will be installed:
less perl
After this operation, 51 MiB of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/2) Installing less (643-r0)
(2/2) Installing perl (5.38.2-r0)
8% ███████████████ Segmentation fault (core dumped)
root@cbuild: ~$ lldb -c core.12
(lldb) target create --core "core.12"
Core file '/tmp/core.12' (x86_64) was loaded.sl-x86_64.so.1...
(lldb) bt
* thread #1, name = 'apk', stop reason = signal SIGSEGV: address not mapped to object
* frame #0: 0x00007c4e64fcbce1 libapk.so.2`apk_db_dir_prepare(db=0x000059597e8d3830, dir=0x00007c4e644c5c70) at database.c:276:20
frame #1: 0x00007c4e64fd949f libapk.so.2`apk_db_install_file(ectx=0x00007ffec51c63a0, ae=0x00007ffec51c3de8, is=0x0000000000000000) at database.c:2757:3
frame #2: 0x00007c4e64fdb5b4 libapk.so.2`apk_extract_v3_next_file [inlined] apk_extract_v3_directory(ectx=0x00007ffec51c63a0) at extract_v3.c:128:6
frame #3: 0x00007c4e64fdb3dc libapk.so.2`apk_extract_v3_next_file(ectx=0x00007ffec51c63a0) at extract_v3.c:164:8
frame #4: 0x00007c4e64fdb196 libapk.so.2`apk_extract_v3_data_block(db=0x00007ffec51c4088, b=<unavailable>, is=0x00007ffec51c3f60) at extract_v3.c:192:6
frame #5: 0x00007c4e64fbd630 libapk.so.2`adb_m_process at adb.c:244:7
frame #6: 0x00007c4e64fbd22c libapk.so.2`adb_m_process(db=0x00007ffec51c4088, is=0x00007c4e64832f30, expected_schema=<unavailable>, t=0x000059597e8d35b8, cb=<unavailable>) at adb.c:280:9
frame #7: 0x00007c4e64fdaf1d libapk.so.2`apk_extract_v3(ectx=0x00007ffec51c63a0, is=0x00007c4e64f04fc0) at extract_v3.c:253:6
frame #8: 0x00007c4e64fd4fe2 libapk.so.2`apk_db_install_pkg [inlined] apk_extract(ectx=<unavailable>, is=0x00007c4e64f04fc0) at extract_v3.c:292:41
frame #9: 0x00007c4e64fd4fdd libapk.so.2`apk_db_install_pkg [inlined] apk_db_unpack_pkg(db=0x000059597e8d3830, ipkg=0x00007c4e62fd2010, upgrade=<unavailable>, cb=(libapk.so.2`progress_cb at commit.c:129:37), cb_ctx=0x00007ffec51c64c0, script_args=0x00007ffec51c5240) at database.c:2996:6
frame #10: 0x00007c4e64fd4e21 libapk.so.2`apk_db_install_pkg(db=0x000059597e8d3830, oldpkg=0x0000000000000000, newpkg=0x00007c4e6399e610, cb=(libapk.so.2`progress_cb at commit.c:129:37), cb_ctx=0x00007ffec51c64c0) at database.c:3047:7
frame #11: 0x00007c4e64fc880a libapk.so.2`apk_solver_commit_changeset(db=0x000059597e8d3830, changeset=0x00007ffec51c65a0, world=0x00007c4e62a77a40) at commit.c:377:9
frame #12: 0x00007c4e64fca62e libapk.so.2`apk_solver_commit(db=0x000059597e8d3830, solver_flags=0, world=0x00007c4e62a77a40) at commit.c:813:7
frame #13: 0x000059597e861359 apk`add_main(ctx=0x00007c4e651039f0, ac=<unavailable>, args=0x00007c4e65163e50) at app_add.c:209:6
frame #14: 0x000059597e86073a apk`main(argc=1, argv=0x00007ffec51c7348) at apk.c:616:6
frame #15: 0x00007c4e65457bca ld-musl-x86_64.so.1`libc_start_main_stage2(main=(apk`main at apk.c:493), argc=<unavailable>, argv=0x00007ffec51c7338) at __libc_start_main.c:95:7
frame #16: 0x000059597e85fa76 apk`_start + 22
(lldb) p dir->owner
(apk_db_dir_instance *) NULL
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10981apk3: running triggers now always leaves apk in error state2024-03-20T13:40:45ZDaniel Kolesaapk3: running triggers now always leaves apk in error state```
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
E...```
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
Executing base-shells-0.1-r0.trigger
Regenerating /etc/shells...
1 error; 1286 MiB in 145 packages
root@cbuild: ~$ apk fix
After this operation, 0 B of additional disk space will be used.
OK: 1286 MiB in 145 packages
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
Executing base-shells-0.1-r0.trigger
Regenerating /etc/shells...
1 error; 1286 MiB in 145 packages
```
Relevant commit is probably 60fec0bd3de1c3f8f6747fbc170765c69e0de438https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10576setup-desktop: update list of KDE packages2024-03-20T08:22:38ZPatrycja Rosaalpine@ptrcnull.mesetup-desktop: update list of KDE packagesfor example, `kgamma5` no longer existsfor example, `kgamma5` no longer existshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15887Consider renaming community/glycin to glycin-loaders2024-03-20T06:27:45ZNewbyteConsider renaming community/glycin to glycin-loaderscommunity/glycin doesn't actually contain any glycin dynamic libraries but rather just the image loaders. After a chat with upstream the recommendation seems to be naming this package glycin-loaders (which is also what it's packaged as i...community/glycin doesn't actually contain any glycin dynamic libraries but rather just the image loaders. After a chat with upstream the recommendation seems to be naming this package glycin-loaders (which is also what it's packaged as in Debian and Fedora) rather than glycin, which I think makes sense given that the current name makes it sound more like it would contain the actual library.Patrycja Rosaalpine@ptrcnull.mePatrycja Rosaalpine@ptrcnull.mehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15890community/dotnet8 missing the DOTNET_CLI_TELEMETRY_OPTOUT in /etc/profile.d/d...2024-03-20T00:08:40ZBjörn Strömbergcommunity/dotnet8 missing the DOTNET_CLI_TELEMETRY_OPTOUT in /etc/profile.d/dotnet.shthe built packages from 2024.03.14 in community does not default to opting out of telemetry! ping @ayakael
content:
```
# Set location for AppHost lookup
[ -z "$DOTNET_ROOT" ] && export DOTNET_ROOT=/usr/lib/dotnet
# Add dotnet tools di...the built packages from 2024.03.14 in community does not default to opting out of telemetry! ping @ayakael
content:
```
# Set location for AppHost lookup
[ -z "$DOTNET_ROOT" ] && export DOTNET_ROOT=/usr/lib/dotnet
# Add dotnet tools directory to PATH
DOTNET_TOOLS_PATH="$HOME/.dotnet/tools"
case "$PATH" in
*"$DOTNET_TOOLS_PATH"* ) true ;;
* ) PATH="$PATH:$DOTNET_TOOLS_PATH" ;;
esac
# Extract self-contained executables under HOME to avoid multi-user issues from using the default '/var/tmp'
[ -z "$DOTNET_BUNDLE_EXTRACT_BASE_DIR" ] && export DOTNET_BUNDLE_EXTRACT_BASE_DIR="${XDG_CACHE_HOME:-"$HOME"/.cache}/dotnet_bundle_extract"
```
caught this output during the build of dotnet from source
```
#
# Telemetry
# ---------
# The .NET tools collect usage data in order to help us improve your experience.
# It is collected by Microsoft and shared with the community.
# You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
#
```
so the file should export `export DOTNET_CLI_TELEMETRY_OPTOUT=true` system wide on startup since service might be running without telemetry off!
... Microsoft and their damn telemetry ...https://gitlab.alpinelinux.org/alpine/aports/-/issues/15892busybox: not possible to permanently remove klogd user2024-03-19T21:47:08ZNatanael Copabusybox: not possible to permanently remove klogd userCommit b870258c717220a2ea3f8803e54578ee80820979 (main/busybox: run klogd as klogd user and not root) introduced a user named `klogd` that is created from busybox install script. A consequence of this is that users who don't want this use...Commit b870258c717220a2ea3f8803e54578ee80820979 (main/busybox: run klogd as klogd user and not root) introduced a user named `klogd` that is created from busybox install script. A consequence of this is that users who don't want this user on their system can not remove it without it gets recreated on next busybox upgrade. And since it is not really possible to uninstall busybox, it means that it is not really possible to permanently remove the `klogd` user.
Possible solutions:
1. Move the `klogd` user to default `/etc/passwd` provided by `alpine-baselayout`. Users can simply `deluser klogd`, and it will not automatically come back on upgrades. This is the solution I prefer. It is very simple, and the drawback is insignificant (`klogd` user is there by default even if you never install `busybox-openrc`).
2. Move the user creation to `busybox-openrc.pre-install`. Users can avoid creating the `klogd` user with `apk add !busybox-openrc` and not use any of the busybox provided services. There should be alternatives to those, but in this case you cannot use any of the busybox provided services.
3. Split `busybox-openrc`, and ship every service in a separate package. The `klogd` user would be created with `busybox-klogd-openrc` package. I really don't want to do this, because it adds a lot complexity with high risk of unexpected breakages and it has very low benefit.
4. let the install script parse some config where you can disable creation. For example, source `/etc/conf.d/klogd` and see if `command_user=klogd`https://gitlab.alpinelinux.org/alpine/aports/-/issues/15728can’t use pthreads with WASI SDK (by default)2024-03-19T18:30:52Zzamfofexcan’t use pthreads with WASI SDK (by default)I want to be able to compile a C program that uses pthreads to Wasm with something like `clang --target=wasm32-wasi-threads -o main.wasm main.c`, but that does not work. A work around is to specify the sysroot explicitly as `--sysroot /u...I want to be able to compile a C program that uses pthreads to Wasm with something like `clang --target=wasm32-wasi-threads -o main.wasm main.c`, but that does not work. A work around is to specify the sysroot explicitly as `--sysroot /usr/share/wasi-sysroot`. The problem is that the [`APKBUILD` for `wasi-sdk`][APKBUILD] only adds a `.cfg` file for the non‐threads target triple. The fix would (presumably) be to have it also add a similar `.cfg` for the `...-threads` target triple too.
[APKBUILD]: <https://git.alpinelinux.org/aports/tree/main/wasi-sdk/APKBUILD>Patrycja Rosaalpine@ptrcnull.mePatrycja Rosaalpine@ptrcnull.mehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15841Inconsistencies in busybox .initd2024-03-19T17:10:42ZFxzx micInconsistencies in busybox .initdI found some inconsistencies in busybox .initd:
| file | name | variables |
|------|------|-----------|
| acpid.initd | acpid | no |
| crond.initd | crond | $RC_SVCNAME and $SVCNAME |
| dnsd.initd | dnsd | $RC_SVCNAME and $SVCNAME |
| h...I found some inconsistencies in busybox .initd:
| file | name | variables |
|------|------|-----------|
| acpid.initd | acpid | no |
| crond.initd | crond | $RC_SVCNAME and $SVCNAME |
| dnsd.initd | dnsd | $RC_SVCNAME and $SVCNAME |
| httpd.initd | httpd | $RC_SVCNAME and $SVCNAME |
| inetd.initd | inetd | $RC_SVCNAME and $SVCNAME |
| klogd.initd | klogd | no |
| ntpd.initd | ntpd | $RC_SVCNAME and $SVCNAME |
| syslog.initd | syslog | no |
| udhcpd.initd | udhcpd | $RC_SVCNAME and $SVCNAME |
| watchdog.initd | watchdog | no |
Should we unify these and set a standard? Also, should `syslog` be renamed to `syslogd`?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15891testing/ddcci-driver-linux-src fails to build with linux-edge-dev-6.8.1-r02024-03-19T16:40:22ZHugo Barreratesting/ddcci-driver-linux-src fails to build with linux-edge-dev-6.8.1-r0## Package Information
* Package name*: **ddcci-driver-linux-src-0.4.4-r2** and **linux-edge-dev-6.8.1-r0**
* Alpine version*: edge / 3.20.0_alpha20240315
* Alpine architecture*: x86_64
## Summary
```
> doas apk fix ddcci-driver-linux...## Package Information
* Package name*: **ddcci-driver-linux-src-0.4.4-r2** and **linux-edge-dev-6.8.1-r0**
* Alpine version*: edge / 3.20.0_alpha20240315
* Alpine architecture*: x86_64
## Summary
```
> doas apk fix ddcci-driver-linux-src
WARNING: opening /home/hugo/packages/main: No such file or directory
(1/1) Reinstalling ddcci-driver-linux-src (0.4.4-r2)
Executing akms-0.2.1-r0.trigger
akms: Building module ddcci-driver-linux/0.4.4-r2 for kernel 6.8.1-0-edge
WARNING: opening /home/hugo/packages/main: No such file or directory
WARNING: opening /home/hugo/packages/main: No such file or directory
(1/8) Installing libasm (0.191-r0)
(2/8) Installing elfutils-dev (0.191-r0)
(3/8) Installing flex (2.6.4-r6)
(4/8) Installing bison (3.8.2-r1)
(5/8) Installing linux-edge-dev (6.8.1-r0)
(6/8) Installing .akms-build (20240319.154618)
(7/8) Installing bison-doc (3.8.2-r1)
(8/8) Installing flex-doc (2.6.4-r6)
OK: 13718 MiB in 3090 packages
make: Entering directory '/usr/src/linux-headers-6.8.1-0-edge'
CC [M] /var/lib/akms/6.8.1-0-edge/ddcci-driver-linux/0.4.4-r2/build/ddcci/ddcci.o
/usr/src/ddcci-driver-linux-0.4.4/ddcci/ddcci.c: In function 'ddcci_detect':
/usr/src/ddcci-driver-linux-0.4.4/ddcci/ddcci.c:1669:9: error: implicit declaration of function 'strlcpy'; did you mean 'strscpy'? [-Werror=implicit-function-declaration]
1669 | strlcpy(info->type, (outer_addr == DDCCI_DEFAULT_DEVICE_ADDR) ? "ddcci" : "ddcci-dependent", I2C_NAME_SIZE);
| ^~~~~~~
| strscpy
/usr/src/ddcci-driver-linux-0.4.4/ddcci/ddcci.c: At top level:
/usr/src/ddcci-driver-linux-0.4.4/ddcci/ddcci.c:1827:27: error: 'I2C_CLASS_DDC' undeclared here (not in a function); did you mean 'I2C_CLASS_SPD'?
1827 | .class = I2C_CLASS_DDC,
| ^~~~~~~~~~~~~
| I2C_CLASS_SPD
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:243: /var/lib/akms/6.8.1-0-edge/ddcci-driver-linux/0.4.4-r2/build/ddcci/ddcci.o] Error 1
make[1]: *** [/usr/src/linux-headers-6.8.1-0-edge/Makefile:1921: /var/lib/akms/6.8.1-0-edge/ddcci-driver-linux/0.4.4-r2/build/ddcci] Error 2
make: *** [Makefile:240: __sub-make] Error 2
make: Leaving directory '/usr/src/linux-headers-6.8.1-0-edge'
akms: ERROR: Failed to build module ddcci-driver-linux/0.4.4-r2 for 6.8.1-0-edge
akms: ERROR: examine /var/lib/akms/6.8.1-0-edge/ddcci-driver-linux/0.4.4-r2/build
```https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/55Changing the console font in the initfs2024-03-19T16:25:39ZHugo BarreraChanging the console font in the initfsI'm trying to change the console font size on the initfs.
I mostly interact with the console _before_ the main partition is unlocked (providing a passphrase), so [changing the font via an openrc service](https://wiki.alpinelinux.org/wik...I'm trying to change the console font size on the initfs.
I mostly interact with the console _before_ the main partition is unlocked (providing a passphrase), so [changing the font via an openrc service](https://wiki.alpinelinux.org/wiki/Fonts#Changing_the_console_font) is a bit too late.
When cryptsetup tells me that I've provided the wrong password, I sometimes miss this due to the tiny fonts (it low-key bothers me that font size change halfway through boot, although that's not terrible).
I applied this small patch to `initramfs-init`:
```diff
--- initramfs-init.in
+++ /usr/share/mkinitfs/initramfs-init
@@ -574,6 +574,12 @@
$MOCK modprobe -a ata_piix mptspi sr-mod
fi
+if [ -f /usr/share/consolefonts/default.gz ] && [ -x /usr/sbin/setfont ]; then
+ /usr/sbin/setfont -C /dev/tty0 /usr/share/consolefonts/default.gz
+ echo font changed
+ sleep 2
+fi
+
if [ -n "$KOPT_cryptroot" ]; then
cryptopts="-c ${KOPT_cryptroot}"
if [ "$KOPT_cryptdiscards" = "yes" ]; then
```
And added the following to `/etc/mkinitfs/features.d/consolefont.files`:
/usr/share/consolefonts/default.gz
I finally symlinked `default.gz` to a font of my choice (ter-132n.psf.gz), added `consolefont` to `mkinitfs.conf`, and rebuilt my initfs (the default initfs already contains the busybox implementation of `setfont`).
This successfully changed the console font (to one nice and large and easy to read!)!
However, as soon as `nlplug-findfs` runs, the font resets back to the default tiny size. I suspect that this is a side effect of mdev, but haven't been able to pinpoint down the exact cause. I would appreciate any potential guidance at this point.