alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2023-11-08T07:26:24Zhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/2deadline for packages in testing2023-11-08T07:26:24ZAriadne Conillariadne@ariadne.spacedeadline for packages in testingFrequently, `testing` gets packages contributed to it which never leave and just bitrot.
I would like to propose a deadline for packages in `testing`: they either get moved to `community` or `main`, or they get removed within some time ...Frequently, `testing` gets packages contributed to it which never leave and just bitrot.
I would like to propose a deadline for packages in `testing`: they either get moved to `community` or `main`, or they get removed within some time limit.
I think a deadline will also motivate packagers to more actively participate in the maintenance of their packages.
Thoughts?Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/1Move sudo to community2023-05-15T10:47:47ZAriadne Conillariadne@ariadne.spaceMove sudo to community## Summary
At present, `sudo` is in the `main` repository, which requires us to provide security support for 2 years. Upstream `sudo` does not provide an "LTS" lifecycle, so this requires either performing security upgrades during the ...## Summary
At present, `sudo` is in the `main` repository, which requires us to provide security support for 2 years. Upstream `sudo` does not provide an "LTS" lifecycle, so this requires either performing security upgrades during the maintenance lifecycle, or backporting security fixes by hand.
## Benefit to Alpine
Prior to the creation of the security team, there was an unofficial preference to push `doas` as the preferred pivot tool for Alpine. This reinforces that messaging.
Additionally, we do not have to support `sudo` for a 2 year lifecycle, since there are no LTS branches for it.
## Contingency Plan
If there is a problem with implementing this plan, we will move `sudo` back to `main` from `community`, but no such problem is expected.
## Documentation
This will need to be documented in the release notes. We should recommend `doas` as the preferred pivot tool, noting that `sudo` is available in `community` if explicitly wanted.
## Owners
@kdaudt and @kaniini will implement this change on behalf of @team/security.
## Timeline
We would like to implement this change within the next few weeks, with TSC approval.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10485License2022-05-23T12:23:25ZGhost UserLicensehttps://pkgs.alpinelinux.org/package/edge/main/x86_64/alpine-conf Says Alpine-conf is MIT License but there is no License file.
Is it OK to Fork this as it is under MIT License?https://pkgs.alpinelinux.org/package/edge/main/x86_64/alpine-conf Says Alpine-conf is MIT License but there is no License file.
Is it OK to Fork this as it is under MIT License?https://gitlab.alpinelinux.org/alpine/aports/-/issues/12725sway doesn't work after upgrade to 1.62021-06-06T10:33:23ZLeon Marzsway doesn't work after upgrade to 1.6A weird issue happened after upgrading to wlroots 0.13.0 and sway 1.6. When I started `sway` in the login shell, the screen froze and it only displayed the shell. I couldn't find any logs that could tell me that something went wrong, so ...A weird issue happened after upgrading to wlroots 0.13.0 and sway 1.6. When I started `sway` in the login shell, the screen froze and it only displayed the shell. I couldn't find any logs that could tell me that something went wrong, so I can't give much more information. I had no problem with sway 1.5. The issue could also lie in another package that was updated at the same time (around June 1st) but glancing through the git log I couldn't find another relevant package. Running `sway --debug` also didn't output something relevant before freezing. I suspect that this is a problem with alpinelinux because sway 1.6 has already been out for a whilehttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10732apk policy: add feature to hold/pin packages2022-12-21T19:37:22ZJ0WIapk policy: add feature to hold/pin packagesI'd like to prevent apk from installing or upgrading specific packages.
Use cases are preventing apk from overriding custom builds or prevent a specific broken update while others keep updating.I'd like to prevent apk from installing or upgrading specific packages.
Use cases are preventing apk from overriding custom builds or prevent a specific broken update while others keep updating.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10721install_if doesn't work when package is only installed through provides2022-12-21T20:45:59ZLuca Weissinstall_if doesn't work when package is only installed through providesI've written a test case in form of apk-tools tests for this issue:
Test case:
```diff
diff --git a/test/installif6.repo b/test/installif6.repo
new file mode 100644
index 0000000..7313f77
--- /dev/null
+++ b/test/installif6.repo
@@ -0,0...I've written a test case in form of apk-tools tests for this issue:
Test case:
```diff
diff --git a/test/installif6.repo b/test/installif6.repo
new file mode 100644
index 0000000..7313f77
--- /dev/null
+++ b/test/installif6.repo
@@ -0,0 +1,34 @@
+C:Q1C4uoV7SdMdDhYg4OCVmI71D8HIA=
+P:qt5-qtbase
+V:1
+S:1
+I:1
+p:so:libQt5Core.so.5
+
+C:Q1hdUpqRv5mYgJEqW52UmVsvmyysF=
+P:wayland-libs-client
+V:1
+S:1
+I:1
+p:so:libwayland-client.so.0
+
+C:Q1EyN5AdpAOBJWKMR89pp/C66o+OE=
+P:peruse
+V:1
+S:1
+I:1
+D:so:libQt5Core.so.5
+
+C:Q1eVpkasfqZAukAXFYbgwt4xAMZWU=
+P:sway
+V:1
+S:1
+I:1
+D:so:libwayland-client.so.0
+
+C:Q1/hQ3eH2AguTwJVGOz+keypXhXKY=
+P:qt5-qtwayland
+V:1
+S:1
+I:1
+i:wayland-libs-client qt5-qtbase
diff --git a/test/installif6.test b/test/installif6.test
new file mode 100644
index 0000000..37297e9
--- /dev/null
+++ b/test/installif6.test
@@ -0,0 +1,10 @@
+@ARGS
+--test-repo installif6.repo
+add sway peruse
+@EXPECT
+(1/5) Installing qt5-qtbase (1)
+(2/5) Installing peruse (1)
+(3/5) Installing wayland-libs-client (1)
+(4/5) Installing qt5-qtwayland (1)
+(5/5) Installing sway (1)
+OK: 0 MiB in 0 packages
```
Actual result:
```
FAIL: installif6.test
--- -
+++ .installif6.test.got
@@ -1,6 +1,5 @@
-(1/5) Installing qt5-qtbase (1)
-(2/5) Installing peruse (1)
-(3/5) Installing wayland-libs-client (1)
-(4/5) Installing qt5-qtwayland (1)
-(5/5) Installing sway (1)
+(1/4) Installing qt5-qtbase (1)
+(2/4) Installing peruse (1)
+(3/4) Installing wayland-libs-client (1)
+(4/4) Installing sway (1)
OK: 0 MiB in 0 packages
FAIL: 1 of 76 test cases failed
```
If either qt5-qtbase or wayland-libs-client is installed into world explicitly, then qt5-qtwayland is also installed but with this test case it doesn't.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10713[Feature request] Add mirrors fallbacking2022-12-21T18:50:52Zmmkhitaryan[Feature request] Add mirrors fallbackingSometimes a mirror can be inaccessible because of a mirror maintenance etc. It would be cool if a mirror is not accesible, alpine package manager retried the same package, but on other mirror.
If I have repo list like:
/etc/apk/reposit...Sometimes a mirror can be inaccessible because of a mirror maintenance etc. It would be cool if a mirror is not accesible, alpine package manager retried the same package, but on other mirror.
If I have repo list like:
/etc/apk/repositories ```
http://nl.alpinelinux.org/alpine/v3.7/main
http://mirror.yandex.ru/mirrors/alpine/
```
The package manager tries to download package from mirror.yandex.ru. If package manager can not reach the server because of network error, it retries downloading, but with a mirror upper (nl.alpinelinux.org).v3.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/11901Firefox segfaults on Wayland2021-01-17T01:03:20ZTaner TasFirefox segfaults on WaylandI was experiencing freeze at startup problems on Wayland when I was upgraded to firefox-80.0-r0. After last firefox-80.0-**r1** upgrade, I can't run Firefox on Wayland anymore. It quits with segfault immediately. I also tried with fresh ...I was experiencing freeze at startup problems on Wayland when I was upgraded to firefox-80.0-r0. After last firefox-80.0-**r1** upgrade, I can't run Firefox on Wayland anymore. It quits with segfault immediately. I also tried with fresh profile but no use.
When I do `unset MOZ_ENABLE_WAYLAND`, Firefox runs fine.Milan P. StanićMilan P. Stanićhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11818wpa_supplicant should also support TLS 1.1 and 1.22020-09-01T16:00:37ZStefan Paetowwpa_supplicant should also support TLS 1.1 and 1.2The wpa_supplicant shipping with Alpine apparently builds with TLS 1.0 support only.
See the following lines that are commented out (by default):
https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/wpa_supplicant/config#L3...The wpa_supplicant shipping with Alpine apparently builds with TLS 1.0 support only.
See the following lines that are commented out (by default):
https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/wpa_supplicant/config#L310
https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/wpa_supplicant/config#L317
Those lines should be uncommented and the package rebuilt to be able to take advantage of TLS 1.1/1.2 (although TLS 1.1 is also considered obsolete as of March 2020).Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11522ImageMagick number of supported formats: 02020-11-06T07:58:42ZjuliemarsImageMagick number of supported formats: 0Hi
I hope this is the right place, I discovered this issue in the linuxserver letsencrypt docker image (https://github.com/linuxserver/docker-letsencrypt/issues/445) and they suggested I post it to you.
Expected Behavior
The ImageMagi...Hi
I hope this is the right place, I discovered this issue in the linuxserver letsencrypt docker image (https://github.com/linuxserver/docker-letsencrypt/issues/445) and they suggested I post it to you.
Expected Behavior
The ImageMagick module is not working, in phpinfo I can see that it says "ImageMagick number of supported formats: 0" this is preventing some functions needing this library from working.
If I disable the ImageMagick.ini file the system falls back to GD and works fine.
Nothing is logged in the docker or NGINX/php log for this error either.
I have deleted and recreated the container and image and tried on 2 different docker installs and issue remains on both.
Current Behavior
Images do not load generating a 500 error.
![image](/uploads/f18596106a3b0e3e49c193f07fc3036a/image.png)
Steps to Reproduce
Setup new image
Use ImageMagick module (webtress uses this)
See 500 error/no image (webtress logs Cannot create thumbnail NoDecodeDelegateForThisImageFormat `PNG'"
they have advised the following:
"We have this php module installed: https://pkgs.alpinelinux.org/package/v3.11/community/x86_64/php7-pecl-imagick
It pulls in the imagemagick-libs: https://pkgs.alpinelinux.org/package/v3.11/community/x86_64/imagemagick-libs
That's why php is listing the imagemagick library version. But no idea why it's not finding any supported formats."
Any ideas?Andy PostnikovAndy Postnikovhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11351RFC: disable TLS < 1.22024-03-22T16:23:02ZJ0WIRFC: disable TLS < 1.2Debian [disabled TLS < 1.2](https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html) in Buster, followed by other distros.
I suggest to disable TLS < 1.2 by default for OpenSSL/GnuTLS/NSS in the next release.Debian [disabled TLS < 1.2](https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html) in Buster, followed by other distros.
I suggest to disable TLS < 1.2 by default for OpenSSL/GnuTLS/NSS in the next release.Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11128gcc: memcpy on armv7 is much slower than on armhf2022-02-21T22:09:07ZPavel Demingcc: memcpy on armv7 is much slower than on armhfI recently switched from armhf to armv7 and noticed that memcpy on armv7 is much slower than on armhf.
Here is a simple test:
```
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define N 131072
int main()...I recently switched from armhf to armv7 and noticed that memcpy on armv7 is much slower than on armhf.
Here is a simple test:
```
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define N 131072
int main()
{
int i;
clock_t time[2];
void *src = malloc(N);
void *dst = malloc(N);
time[0] = clock();
for(i = 0; i < N; ++i)
{
memcpy(dst, src, N);
}
time[1] = clock();
printf("time: %ld\n", time[1] - time[0]);
return 0;
}
```
and the results:
```
armhf:~# time ./test
time: 7310658
real 0m 7.31s
user 0m 7.31s
sys 0m 0.00s
```
```
armv7:~# time ./test
time: 12973756
real 0m 12.97s
user 0m 12.97s
sys 0m 0.00s
```
I suspect the source of the problem is the `--with-mode=thumb` flag on [line 235 in gcc/APKBUILD](https://git.alpinelinux.org/aports/tree/main/gcc/APKBUILD#n235).
Would it be possible to replace `--with-mode=thumb` with `--with-mode=arm`?https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9985Allow downloading sources with Git2021-04-28T11:29:19ZBart RibbersAllow downloading sources with GitSometimes upstream projects require submodules but don't make release tarballs which include them. It would be nice to be able to clone the sources recursively in those cases instead so not every subproject has to be manually specified.
...Sometimes upstream projects require submodules but don't make release tarballs which include them. It would be nice to be able to clone the sources recursively in those cases instead so not every subproject has to be manually specified.
Besides being able to set a giturl, it should allow checking out a version or specific commit.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11080[radvd] Shutting down radvd stops/breaks IPv6 forwarding2021-08-10T14:50:46ZNico Schottelius[radvd] Shutting down radvd stops/breaks IPv6 forwardingWhen shutting down radvd, ipv6 forwarding is turned off, even though it was on before radvd was started:
```
[11:02] router1.place6:~# sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 1
[11:02] router1.place6:~# /etc/i...When shutting down radvd, ipv6 forwarding is turned off, even though it was on before radvd was started:
```
[11:02] router1.place6:~# sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 1
[11:02] router1.place6:~# /etc/init.d/radvd start; sleep 3; /etc/init.d/radvd stop; sysctl net.ipv6.conf.a
ll.forwarding
* Enabling IPv6 forwarding ... [ ok ]
* Starting IPv6 Router Advertisement Daemon ... [ ok ]
* Stopping IPv6 Router Advertisement Daemon ... [ ok ]
* Disabling IPv6 forwarding ... [ ok ]
net.ipv6.conf.all.forwarding = 0
[11:03] router1.place6:~#
```
This breaks every router which has to start/stop radvd occasionally.
I see the code block for start/and stop
```
# start
if [ "${FORWARD}" != "no" ]; then
ebegin "Enabling IPv6 forwarding"
sysctl -w "${SYSCTL_FORWARD}=1" >/dev/null
eend $?
fi
# stop
if [ "${FORWARD}" != "no" ]; then
ebegin "Disabling IPv6 forwarding"
sysctl -w "${SYSCTL_FORWARD}=0" > /dev/null
eend $?
fi
```
I think the logic in the init script is a bit weird.
* If FORWARD=yes and forwarding was enabled before, it clears it on exit
* FORWARD=no does not really disable forwarding
* Other distros don't have the radvd init script modify the sysctl by default and radvd just fails to start if forwarding is not enabled.
** I would have expected similar behaviour here
* Enabling ipv6 forwarding without knowing it also might have unwanted side effects (i.e. forwarding to networks that are configured, but not yet firewalled).
So my proposals (in order) are:
* Remove the FORWARD= logic from radvd as it's unexpected and has potentially complex side effects
* If we want to keep it, set it to FORWARD=no by default OR
* restore the before radvd situation on exit (but this might ugly and still not as intended)
** might not have been enabled before starting radvd
** then the user modifies / uses forwarding which works due to radvd side effect
** radvd is stopped -> other services of the user breakNatanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10668Differentiate DNS/TCP/HTTP level errors for more accurate error diagnostics2022-12-21T20:13:48ZLuca WeissDifferentiate DNS/TCP/HTTP level errors for more accurate error diagnosticsFrom looking at the message I cannot tell what failed during the operation. Is my internet connection down? Does the remote server not respond? Does the server return a 404? A 500? Is this something completely different?
apk shouldn't o...From looking at the message I cannot tell what failed during the operation. Is my internet connection down? Does the remote server not respond? Does the server return a 404? A 500? Is this something completely different?
apk shouldn't output generic error messages but exactly what happens so a user can fix the issue.v3.1https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10640Use different favicons on our sites2019-10-22T06:23:16ZNatanael CopaUse different favicons on our sitesIt would be nice to have different favicons on the different sites, so its easier to find the right tab.
Some options:
- use alpine logo in different colors for different sites
- use alpine logo with some emblem
the main site, alpineli...It would be nice to have different favicons on the different sites, so its easier to find the right tab.
Some options:
- use alpine logo in different colors for different sites
- use alpine logo with some emblem
the main site, alpinelinux.org, could use the favicon as it is.
* [ ] Create favicons
* [ ] Change build.alpinelinux.org
* [ ] Change gitlab.alpinelinux.org
* [ ] Change wiki.alpinelinux.org
* [ ] Change pkgs.alpinelinux.org
* [ ] Change git.alpinelinux.org
* [ ] Change docs.alpinelinux.org
* [ ] Change lists.alpinelinux.org
* [ ] Change mirrors.alpinelinux.org
* [ ] Change netbox.alpin.pw
* [ ] Change wiki.alpin.pw
* [ ] Change zabbix.alpin.pwhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10653"apk info" output could be a lot nicer looking2024-03-22T13:03:31ZLuca Weiss"apk info" output could be a lot nicer lookingEspecially when multiple versions of the same package are available, the output is really hard to read:
```
$ apk info mesa-dev
mesa-dev-9999-r8 description:
[c41545c2f523e9f29e94317d5378045618ba6f67] Mesa DRI OpenGL library (development...Especially when multiple versions of the same package are available, the output is really hard to read:
```
$ apk info mesa-dev
mesa-dev-9999-r8 description:
[c41545c2f523e9f29e94317d5378045618ba6f67] Mesa DRI OpenGL library (development files)
mesa-dev-9999-r8 webpage:
https://www.mesa3d.org
mesa-dev-9999-r8 installed size:
2609152
mesa-dev-9999-r7 description:
[19.1.0] Mesa DRI OpenGL library (development files)
mesa-dev-9999-r7 webpage:
https://www.mesa3d.org
mesa-dev-9999-r7 installed size:
2576384
mesa-dev-19.1.2-r1 description:
Mesa DRI OpenGL library (development files)
mesa-dev-19.1.2-r1 webpage:
https://www.mesa3d.org
mesa-dev-19.1.2-r1 installed size:
2576384
```v3.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/10627clang requires a few gcc libraries, which supposed to be privided by compiler-rt2021-01-29T01:16:23ZTrevis Schifferclang requires a few gcc libraries, which supposed to be privided by compiler-rtHello, I noticed something strange.
Some of the crt files should come from compiler-crt, but these ones come
with gcc:
crtprec32.o
crtendS.o
crtbeginS.o
crtfastmath.o
crtprec64.o
crtbeginT.o
crtprec80.o
...Hello, I noticed something strange.
Some of the crt files should come from compiler-crt, but these ones come
with gcc:
crtprec32.o
crtendS.o
crtbeginS.o
crtfastmath.o
crtprec64.o
crtbeginT.o
crtprec80.o
crtbegin.o
crtend.o
Above libs are not usable without gcc libs (Thus I guess GPL is still
enforced?).
b17wise@eula47 /tmp % clang Hello.c -o hello -fuse-ld=/usr/bin/ld.lld
ld.lld: error: cannot open crtbeginS.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtendS.o: No such file or directory
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
b17wise@eula47 /tmp % sudo apk add gcc
[sudo] password for b17wise:
(1/8) Installing binutils (2.32-r0)
(2/8) Installing isl (0.18-r0)
(3/8) Installing libgomp (8.3.0-r0)
(4/8) Installing libatomic (8.3.0-r0)
(5/8) Installing mpfr3 (3.1.5-r1)
(6/8) Installing mpc1 (1.1.0-r0)
(7/8) Installing gcc (8.3.0-r0)
(8/8) Installing gcc-zsh-completion (5.7.1-r0)
Executing busybox-1.30.1-r2.trigger
OK: 2012 MiB in 482 packages
b17wise@eula47 /tmp % clang Hello.c -o hello -fuse-ld=/usr/bin/ld.lld
b17wise@eula47 /tmp % ./hello
Hello, Alpine
b17wise@eula47 /tmp % apk info -L gcc | grep -e *crtendS*
b17wise@eula47 /tmp % apk info -L gcc | grep crt
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbegin.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtend.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbeginT.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtbeginS.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec32.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec80.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtprec64.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtendS.o
usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/crtfastmath.o
Full log can be found here: http://0x0.st/z2k6.txt
Also there was an issue raised in 2017: https://reviews.llvm.org/D28791
*(from redmine: issue id 10627, created on 2019-06-27)*3.10.6https://gitlab.alpinelinux.org/alpine/aports/-/issues/10116apache and mod_dav_svn segfaulting2021-11-17T13:54:26Zmatthew sporlederapache and mod_dav_svn segfaulting\#Dockerfile
FROM alpine:3.8
RUN apk add --no-cache apache2 mod_dav_svn subversion apache2-webdav apache2-utils curl
COPY subversion.conf /etc/apache2/conf.d/
COPY svnaccess.htpasswd svn_authz /etc/apache2/
RUN \
...\#Dockerfile
FROM alpine:3.8
RUN apk add --no-cache apache2 mod_dav_svn subversion apache2-webdav apache2-utils curl
COPY subversion.conf /etc/apache2/conf.d/
COPY svnaccess.htpasswd svn_authz /etc/apache2/
RUN \
sed -i 's@PidFile "/run/apache2/httpd.pid"@PidFile "/tmp/httpd.pid"@g' /etc/apache2/conf.d/mpm.conf && \
sed -i 's@#EnableMMAP off@EnableMMAP off@g' /etc/apache2/httpd.conf && \
sed -i 's@ErrorLog logs/error.log@ErrorLog /dev/stderr@g' /etc/apache2/httpd.conf && \
sed -i 's@Listen 80@Listen 6666@g' /etc/apache2/httpd.conf && \
sed -i 's@CustomLog logs/access.log combined@CustomLog /dev/stdout combined@g' /etc/apache2/httpd.conf;
\#subversion.conf
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
<VirtualHost *:6666>
ServerName _default_
<Directory /var/www/svn>
Require all granted
</Directory>
<Location /repos>
DAV svn
SVNParentPath /var/www/svn
AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /etc/apache2/svnaccess.htpasswd
Require valid-user
AuthzSVNAccessFile /etc/apache2/svn_authz
</Location>
</VirtualHost>
\#\#\#\#the result
curl localhost:6666/repos/mysvn
\[Thu Mar 14 13:44:56.510692 2019\] \[core:notice\] \[pid 1\] AH00052:
child pid 8 exit signal Segmentation fault (11)
------------------------------------------------------------------------
This doesn’t happen on 3.7. ldd isn’t helpful with apache modules for
some reason (but probably unrelated since it is the same as 3.7)
3.9 is also impacted.
*(from redmine: issue id 10116, created on 2019-03-14)*3.8.5Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9539Can't mount BTRFS volume using fstab2024-03-27T19:28:59ZLouis MatthijssenCan't mount BTRFS volume using fstabI installed Alpine on <code>/dev/sda</code> in <code>sys</code> mode
using <code>ext4</code>. Then I created a <code>btrfs</code> volume on
<code>/dev/sdb</code> and <code>/dev/sdc</code> using:
apk add btrfs-progs
modprobe btrf...I installed Alpine on <code>/dev/sda</code> in <code>sys</code> mode
using <code>ext4</code>. Then I created a <code>btrfs</code> volume on
<code>/dev/sdb</code> and <code>/dev/sdc</code> using:
apk add btrfs-progs
modprobe btrfs && echo btrfs > /etc/modules
mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc
mkdir /data && mount /dev/sdb /data
This is working fine. Now I add this mount to <code>/etc/fstab</code>
like this:
UUID=da110dca-aed5-48b8-a5b6-c1b41c10c419 /data btrfs defaults 0 0
On reboot I get the following error:
mount: mounting /dev/sdc on /data failed: Invalid argument
Output of <code>dmesg</code>:
[ 5.950849] BTRFS: device fsid da110dca-aed5-48b8-a5b6-c1b41c10c419 devid 2 transid 12 /dev/sdc
[ 5.952786] BTRFS info (device sdc): disk space caching is enabled
[ 5.952791] BTRFS info (device sdc): has skinny extents
[ 5.954055] BTRFS warning (device sdc): devid 1 uuid 6a45e7d4-78df-4263-be09-b83a3a15e6e0 is missing
[ 5.954063] BTRFS error (device sdc): failed to read the system array: -5
[ 6.002364] BTRFS error (device sdc): open_ctree failed
I fixed this by adding <code>/sbin/btrfs device scan</code> to the top
of the <code>start</code> method in <code>/etc/init.d/localmount</code>.
However, I have a feeling that this command is already ran on boot but
only *after* mounting <code>/etc/fstab</code>, because when I simply run
<code>mount /dev/sdb /data</code> right after booting it’s working.
It seems that this command is being called if the root file system is
<code>btrfs</code> (see \#6903); I think this should also be done if
there is any other <code>btrfs</code> file system in
<code>/etc/fstab</code>.
*(from redmine: issue id 9539, created on 2018-10-08)*Natanael CopaNatanael Copa