alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-05-18T13:17:23Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13812crypt/sys install to nvme through setup-alpine failed to boot2022-05-18T13:17:23Zkeencrypt/sys install to nvme through setup-alpine failed to bootUsing Alpine 3.15 extended on Lenovo Yoga 730-13ikb using EFI and NVME drive. All out-of-the-box configuration with setup-alpine. "sys" install with no encryption booted fine. crypt/sys disk options failed to boot, but no errors were rep...Using Alpine 3.15 extended on Lenovo Yoga 730-13ikb using EFI and NVME drive. All out-of-the-box configuration with setup-alpine. "sys" install with no encryption booted fine. crypt/sys disk options failed to boot, but no errors were reported during install. Had to mount installed file systems from live environment and use chroot to edit mkinitfs.conf to include "nvme" and run mkinitfs to fix.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13810/etc/pam.d/sddm-autologin requires pam_tally2.so, which breaks autologin2022-05-14T22:18:12ZNoName/etc/pam.d/sddm-autologin requires pam_tally2.so, which breaks autologinAs the title states pam_tally2.so is set to required in /etc/pam.d/sddm-autologin which results in autologin not working, you'll instead be stuck with a blackscreen. A quick look inside /var/log/messages indicates that this library doesn...As the title states pam_tally2.so is set to required in /etc/pam.d/sddm-autologin which results in autologin not working, you'll instead be stuck with a blackscreen. A quick look inside /var/log/messages indicates that this library doesn't exist.
I have therefore set it to optional and that seems to fix autologin.
Is this library even relevant to the autologin feature?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13804[Package proposal] openvpn-respawn-openrc2022-05-12T18:22:54Zblt[Package proposal] openvpn-respawn-openrcNot an issue but a proposal.
I experimented an issue with a not accessible remote server for a couple of weeks before I can got onsite. Server using openvpn and the server in the other end got a radius issue. The openvpn client was kill...Not an issue but a proposal.
I experimented an issue with a not accessible remote server for a couple of weeks before I can got onsite. Server using openvpn and the server in the other end got a radius issue. The openvpn client was killed and no more attempted were made.
I created a supervised version of existing openvpn-openrc to prevent this to happen, asking here first if it does make sense to propose a new package and if there is a better way to do that (I am not a dev). My tweaks are on #supervised part and on reload, all the rest is the same
Thanks!
```
#!/sbin/openrc-run
# supervised
retry="TERM/10/KILL/5/SIGTERM"
supervisor="supervise-daemon"
respawn_max=0
extra_commands="checkconfig"
extra_started_commands="reload stats"
description_reload="Reload OpenVPN using SIGUSR1"
description_stats="Dump OpenVPN statistics to syslog"
instance_name=${RC_SVCNAME#*.}
[ "$instance_name" != "openvpn" ] \
&& name="OpenVPN ($instance_name)" \
|| name="OpenVPN"
# Upper case variables are for backward compatibility with Alpine < v3.8.
: ${cfgdir:=${VPNDIR:-"/etc/openvpn"}}
: ${cfgfile:="$cfgdir/$instance_name.conf"}
: ${detect_client:="${DETECT_CLIENT:-yes}"}
: ${up_script:="$cfgdir/up.sh"}
: ${down_script:="$cfgdir/down.sh"}
: ${peer_dns:=${PEER_DNS:-"yes"}}
pidfile="/run/$RC_SVCNAME.pid"
command="/usr/sbin/openvpn"
## --daemon $instance_name
command_args="
--config $cfgfile
--writepid $pidfile
--setenv RC_SVCNAME $RC_SVCNAME
--setenv PEER_DNS $peer_dns
$command_args"
required_dirs="$cfgdir"
required_files="$cfgfile"
depend() {
need localmount net
use dns
after bootmisc
}
checkconfig() {
# Note: This is not just a check; we need to detect the mode both for
# "start" and "checkconfig" commands, that's why it's here.
if [ -z "$client_mode" ] && yesno "$detect_client"; then
cfgfile_has_option 'remote' \
&& client_mode=yes \
|| client_mode=no
fi
if [ ! -e /dev/net/tun ]; then
if ! modprobe tun; then
eerror "TUN/TAP support is not available in this kernel"
return 1
fi
fi
if [ -h /dev/net/tun ] && [ -c /dev/misc/net/tun ]; then
ebegin "Detected broken /dev/net/tun symlink, fixing"
rm -f /dev/net/tun
ln -s /dev/misc/net/tun /dev/net/tun
eend $?
fi
if yesno "$client_mode"; then
local f; for f in "$up_script" "$down_script"; do
[ -r "$f" ] || { eerror "'$f' is not readable"; return 1; }
done
# Warn about setting scripts as we override them
if cfgfile_has_option "(up|down)"; then
ewarn "WARNING: You have defined your own up/down scripts"
ewarn "As you're running as a client, we now force Alpine specific"
ewarn "scripts to be run for up and down events."
ewarn "These scripts will call /etc/openvpn/$RC_SVCNAME-{up,down}.sh"
ewarn "where you can put your own code."
fi
# Warn about the inability to change ip/route/dns information when
# dropping privs
if cfgfile_has_option "user"; then
ewarn "WARNING: You are dropping root privileges!"
ewarn "As such openvpn may not be able to change ip, routing"
ewarn "or DNS configuration."
fi
fi
}
start_pre() {
checkconfig || return 1
if yesno "$client_mode"; then
command_args="$command_args
--up-delay
--up-restart
--down-pre
--script-security 2
--up $up_script
--down $down_script"
start_inactive="yes"
else
# Run as openvpn unless otherwise specified.
cfgfile_has_option "user" || command_args="$command_args --user openvpn"
cfgfile_has_option "group" || command_args="$command_args --group openvpn"
fi
# If the config file does not specify the cd option, we do.
# But if we specify it, we override the config option which we do not want.
if cfgfile_has_option "cd"; then
command_args="$command_args --cd $cfgdir"
fi
}
start() {
# If we are re-called by the up.sh script, then we don't actually want
# to start OpenVPN. We do this so we can "start" ourselves from
# inactive (from the up.sh script) which then triggers other
# services to start which depend on us.
yesno "$IN_BACKGROUND" && return 0
default_start
}
stop() {
# If we are re-called by the down.sh script, then we don't actually
# want to stop OpenVPN.
if yesno "$IN_BACKGROUND"; then
mark_service_inactive "$RC_SVCNAME"
return 0
fi
default_stop
}
reload() {
ebegin "Reloading $name"
${supervisor} ${RC_SVCNAME} --signal HUP
eend $?
}
stats() {
ebegin "Dumping $name statistics to syslog"
start-stop-daemon --signal USR2 --pidfile "$pidfile"
eend $?
}
cfgfile_has_option() {
grep -Eq "^\s*$1\s" "$cfgfile"
}
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/13803Package request: strike2022-05-11T23:43:29ZAntoni Aloy TorrensPackage request: strikeStrike is a simple minimal IDE for the Linux phones. Code, build, and run from the phone.
Source code: https://invent.kde.org/maui/strikeStrike is a simple minimal IDE for the Linux phones. Code, build, and run from the phone.
Source code: https://invent.kde.org/maui/strikehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13802[Package request] kmonad2022-09-13T08:13:13ZTim[Package request] kmonadhttps://github.com/kmonad/kmonad
KMonad is an advanced tool that lets you infinitely customize and extend the functionalities of almost any keyboard.https://github.com/kmonad/kmonad
KMonad is an advanced tool that lets you infinitely customize and extend the functionalities of almost any keyboard.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/48Architecture-specific teams2022-12-19T16:15:22ZSören TempelArchitecture-specific teamsEvery now and then we ran into issues which only affect specific architectures and occasionally require more in-depth knowledge of a specific architecture in order to address them (e.g. https://gitlab.alpinelinux.org/alpine/aports/-/issu...Every now and then we ran into issues which only affect specific architectures and occasionally require more in-depth knowledge of a specific architecture in order to address them (e.g. https://gitlab.alpinelinux.org/alpine/aports/-/issues/13702, https://gitlab.alpinelinux.org/alpine/aports/-/issues/13692, …).
For these kinds of issues it would be helpful to have a group of people (i.e. an Alpine team) which takes care of specifically maintaining the Alpine port for a certain architectures. This team can then be contacted in case of architecture-specific issues. This is especially useful for less common architectures (e.g. ppc64le, s390x, …).
I therefore purpose that each architecture, officially supported by Alpine, needs an associated Alpine team of active contributors and developers which can be contacted in case of architecture specific issues and (ideally) also test and use Alpine on the architecture. I would propose adding this to the requirements of the [Criteria for a formal release](https://gitlab.alpinelinux.org/alpine/tsc/-/blob/master/minutes/2021-11-09.md#criteria-for-a-formal-release).
Related: #44, #46Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13781Possible Bug: PyGObject misbehaving surfaced by GNOME Builder2022-05-06T13:15:13ZSaijin-NaibPossible Bug: PyGObject misbehaving surfaced by GNOME BuilderIn testing the latest build of GNOME Builder, it was revealed that one of the built-in Extensions (rstcheck) was not functioning properly, despite working properly in the flatpak builds.
It was suggested by the maintainer of Builder tha...In testing the latest build of GNOME Builder, it was revealed that one of the built-in Extensions (rstcheck) was not functioning properly, despite working properly in the flatpak builds.
It was suggested by the maintainer of Builder that this might be an issue happening in PyGObject for some reason.
https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/1669Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/docs/user-handbook/-/issues/2"Getting a Graphical Environment" Instructs Installing Nonexistent Package2022-10-25T17:14:12ZJacenBoy"Getting a Graphical Environment" Instructs Installing Nonexistent PackageIn the ["Getting a Graphical Environment" section of the "Post Installation Recommendations" page](https://docs.alpinelinux.org/user-handbook/0.1a/Working/post-install.html#_getting_a_graphical_environment) users are instructed to instal...In the ["Getting a Graphical Environment" section of the "Post Installation Recommendations" page](https://docs.alpinelinux.org/user-handbook/0.1a/Working/post-install.html#_getting_a_graphical_environment) users are instructed to install the `alpine-desktop` package. Trying to install thing with apk gives a "no such package" error. Should either remove this section or update it with more accurate/more clear instructions.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13776xscreensaver in 3.15 complains about being too old2022-05-05T23:22:44ZGray Wolfxscreensaver in 3.15 complains about being too oldWhen running xscreensaver in 3.15, it complains both on startup and on the lock screen that it is too old and should be updated.When running xscreensaver in 3.15, it complains both on startup and on the lock screen that it is too old and should be updated.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13774[Package Request] Pronterface2022-05-04T20:05:42ZWeston Miller[Package Request] PronterfaceThis is simple host software for 3D printing.
https://github.com/kliment/PrintrunThis is simple host software for 3D printing.
https://github.com/kliment/Printrunhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13766main/zsh: no -dev package with headers2022-05-01T05:42:20ZPatrycja Rosaalpine@ptrcnull.memain/zsh: no -dev package with headerszsh allows loading dynamic modules with `zmodload`; unfortunately, even though there are [some modules in aports](https://pkgs.alpinelinux.org/contents?file=*.so&path=%2Fusr%2Flib%2Fzsh%2F5.8.1%2Fzsh&name=&branch=edge), they're only buil...zsh allows loading dynamic modules with `zmodload`; unfortunately, even though there are [some modules in aports](https://pkgs.alpinelinux.org/contents?file=*.so&path=%2Fusr%2Flib%2Fzsh%2F5.8.1%2Fzsh&name=&branch=edge), they're only built within the zsh aport as subpackages and the headers are not being packaged at allJakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13763Package request: k0s2022-05-08T23:12:00ZHoang NguyenPackage request: k0sA lightweight Kubernetes distribution.
Homepage: https://k0sproject.io/
Preferably built with Kubernetes components bundled in the binary.A lightweight Kubernetes distribution.
Homepage: https://k0sproject.io/
Preferably built with Kubernetes components bundled in the binary.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/mkinitfs/-/issues/24https urls for apkovl= and alpine_repo= broken in 3.152022-04-27T06:54:00Zsbrudenellhttps urls for apkovl= and alpine_repo= broken in 3.15I'm trying to use the current netboot images. Using an ipxe config like this:
```
kernel http://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/vmlinuz-virt modules=loop,squashfs nomodeset apkovl=https://f004.backblazeb2.com/...I'm trying to use the current netboot images. Using an ipxe config like this:
```
kernel http://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/vmlinuz-virt modules=loop,squashfs nomodeset apkovl=https://f004.backblazeb2.com/file/sbrudenell-netboot/test.apkovl.tar.gz alpine_repo=https://dl-cdn.alpinelinux.org/alpine/v3.15/main modloop=https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/modloop-virt
initrd http://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/initramfs-virt
```
The initramfs contains mkinitfs v3.6.0:
```
Alpine Init 3.6.0-r0
```
After !89 it seems like the https urls should work, but I get errors:
```
Connecting to f004.backblazeb2.com (149.137.128.16:443)
ssl_client: f004.backblazeb2.com: certificate verification failed: unable to get local issuer certificate
wget: error getting response: Connection reset by peer
...
* Installing packages to root filesystem: fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz
140234374155080:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1914:
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.15/main: Permission denied
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.15/main: No such file or directory
```
The ca bundle is present at `/etc/ssl`, but libcrypto is looking in `/etc/ssl1.1`:
```
/ # strace -f wget https://google.com 2>&1 | grep /etc/ssl
[pid 689] open("/etc/ssl1.1/cert.pem", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/c06d5c68.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/1001acf7.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/5ad8a5d6.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/5ad8a5d6.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
```
It looks like ssl dependencies and files are in flux in recent versions.
In 3.15:
* `ssl_client` depends on `libretls`, which depends on `libcrypto1.1` and `ca-certificates-bundle`
* `ca-certificates-bundle` provides `/etc/ssl/certs`
* `libcrypto1.1` provides `/etc/ssl1.1/certs` which symlinks to `/etc/ssl/certs`
* `libcrypto1.1` defaults to `/etc/ssl1.1` for the ssl dir
In edge:
* Dependencies are actively changing. I saw that `ssl_client` switched from depending on `libretls` to `libcrypto1.1` directly, between the time I did `docker run -it alpine:edge` and `apk upgrade` within the container :smile:
* `libcrypto1.1` doesn't provide `/etc/ssl1.1`, but does provide files (not certificates) in `/etc/ssl`
* `libcrypto3` provides `/etc/ssl3`. `/etc/ssl3/certs` symlinks to `/etc/ssl/certs`. No packages depend on `libcrypto3`/`openssl3` currently.
So it seems like `/etc/ssl` is the "canonical" ssl dir, but a default install uses indirection through `/etc/ssl1.1`, *only* in 3.15.
Seems like it would be consistent to change `libcrypto1.1` to load certificates from `/etc/ssl` in 3.15 like it does in other branches, but this seems like a dangerous change.
I can imagine two fixes to the `init` issue:
1. Change the ssl includes in the network feature to wildcards, something like `/etc/ssl*/certs.pem` and `/etc/ssl*/certs`
2. Add `export SSL_CERT_DIR=/etc/ssl/certs; export SSL_CERT_FILE=/etc/ssl/certs.pem` to `init`, as a workaround for 3.15.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13746ERROR: librbd-16.2.7-r5: trying to overwrite usr/lib/librbd.so.1 owned by lib...2022-04-25T10:31:40ZBart RibbersERROR: librbd-16.2.7-r5: trying to overwrite usr/lib/librbd.so.1 owned by librbd17-17.1.0-r0.This happened on several machines nowThis happened on several machines nowhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13735main/fortify-headers does not seem to be a big fan of LTO2023-04-30T15:07:44ZGhost Usermain/fortify-headers does not seem to be a big fan of LTOwhen compiling quite a few c++ programs with -flto, some part of the build process will usually fail with something along the lines of:
```
/usr/include/fortify/stdio.h:70:28: error: inlining failed in call to 'always_inline' 'vsnprin...when compiling quite a few c++ programs with -flto, some part of the build process will usually fail with something along the lines of:
```
/usr/include/fortify/stdio.h:70:28: error: inlining failed in call to 'always_inline' 'vsnprintf': function body can be overwritten at link time
```
some things mistakenly don't actually use lto when trying to currently, then fail with the above. for instance, in community/alembic:
```
CXXFLAGS="$CXXFLAGS -flto -fno-ipa-cp"
cmake -B build -G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE=Release \
-DUSE_HDF5=ON
cmake --build build
```
however, this doesn't actually enable lto. to enable it with cmake you would usually do something along the lines of `-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON`, and then when you do that, you get the above error.
some other aports that fail in the exact same way:
testing/gnuradio (the -U_FORTIFY_SOURCE is there because it implicitly sets lto in cmake, and without disabling either lto or fortify, it fails in the same way)
community/rocksdb (with the -DCMAKE flag above..)
really, most things i try that are c++ fail in this same way.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10511lbu: support backups of multiple hosts on one device2022-05-13T06:04:11ZRoland Pabellbu: support backups of multiple hosts on one deviceI have two computers running apline and would like to use the same usb stick to save their lbu backup files. But lbu complains when there are two apkovl files present:
~~~
two:/mnt# lbu ci
The following apkovl file(s) were found:
/media...I have two computers running apline and would like to use the same usb stick to save their lbu backup files. But lbu complains when there are two apkovl files present:
~~~
two:/mnt# lbu ci
The following apkovl file(s) were found:
/media/usb/one.apkovl.tar.gz
/media/usb/two.apkovl.tar.gz
Please use -d to replace.
~~~
I understand that apkovl is the active file, since backup_apkovl() in lbu replaces "apkovl" with the date.
But I think the functionality could easily be enabled if lbu would only consider files starting with the hostname, which is true almost everywhere except in these 3 occasions in function cmd_commit():
~~~
line 453: local rmfiles=$(ls "$mnt/"*.apkovl.tar.gz* 2>/dev/null)
line 460: [ -z "$DRYRUN" ] && rm "$mnt/"*.apkovl.tar.gz*
line 463: lines=$(ls -1 "$mnt"/*.apkovl.tar.gz* 2>/dev/null)
~~~
I changed these locally to `${hostname}.*.apkovl.tar.gz` and that works as expected.
What I don't know is: Is this by design? Should there ever only be one apkovl file on any given device?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13732QUESTION: Automatic/Unattended installation2023-12-02T23:35:57ZCarlo CorradiniQUESTION: Automatic/Unattended installation_Sorry for posting a question, but I've searched for a possible solution without success._
I've created a custom ISO following [How to make a custom ISO image with mkimage](https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_imag..._Sorry for posting a question, but I've searched for a possible solution without success._
I've created a custom ISO following [How to make a custom ISO image with mkimage](https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage) and I'd like to completely automate the installation when the system boots up.
I've tried creating a custom `genapkovl` (following [genapkovl-dhcp.sh](https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/genapkovl-dhcp.sh) example and [this tutorial](https://wejn.org/2022/04/alpinelinux-unattended-install/)) that creates a file under _/etc/local.d_ and executes it on boot (added via `rc_add local boot`).
The script in _/etc/local.d_ runs `setup-alpine` with a preconfigured answerfile.
Unfortunately, the overall procedure does not work 😥
I've tried everything without success.
Any help is greatly appreciated 🥳
Thanks! 🤗https://gitlab.alpinelinux.org/alpine/aports/-/issues/13731community/dnscrypt-proxy: run as 'dnscrypt' interferes with dnscrypt-proxy op...2022-04-19T23:11:42ZDannycommunity/dnscrypt-proxy: run as 'dnscrypt' interferes with dnscrypt-proxy opening port 53Context: this is an issue in installing _dnscrypt-proxy_ on PostmarketOS. AFAICT it uses this repository.
See https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/dnscrypt-proxy/dnscrypt-proxy.initd#L8
_dnscrypt-proxy_,...Context: this is an issue in installing _dnscrypt-proxy_ on PostmarketOS. AFAICT it uses this repository.
See https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/dnscrypt-proxy/dnscrypt-proxy.initd#L8
_dnscrypt-proxy_, by default, opens port `53` for TCP and UDP. The openrc-init procedure runs dnscrypt-proxy as user `dnscrypt` causing it to fail initialization due to missing privileges. _dnscrypt-proxy_ can be configured to perform privilege lowering to a specified username in the configuration, but not commandline.
Errors become visible with `command_background="no"`. (And there is probably an easier way.)https://gitlab.alpinelinux.org/alpine/aports/-/issues/13730community/hyphen: support more languages2022-04-19T17:57:43ZJohannes Arnoldcommunity/hyphen: support more languagesCurrently, [hyphen](/community/hyphen/APKBUILD) only has a [hyphen-en](https://pkgs.alpinelinux.org/package/edge/community/x86_64/hyphen-en) subpackage, which appears to link all language dictionaries to `hyph_en_US.dic`.
Would it be po...Currently, [hyphen](/community/hyphen/APKBUILD) only has a [hyphen-en](https://pkgs.alpinelinux.org/package/edge/community/x86_64/hyphen-en) subpackage, which appears to link all language dictionaries to `hyph_en_US.dic`.
Would it be possible to have subpackages which link a specific language to its dictionary? I question the efficacy of "faking" over 20 other languages' hyphenation to US-American.Timo TeräsTimo Teräs