aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2024-01-19T23:56:03Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2Can I add an issue without creating an account?2024-01-19T23:56:03ZNathan AngelacosCan I add an issue without creating an account?Looks Like I have to be a registered user to create an account.
Is there a way to make anonymous bug reports?
*(from redmine: issue id 2, created on 2009-03-10, closed on 2009-03-16)*
* Relations:
* relates #9081Looks Like I have to be a registered user to create an account.
Is there a way to make anonymous bug reports?
*(from redmine: issue id 2, created on 2009-03-10, closed on 2009-03-16)*
* Relations:
* relates #9081https://gitlab.alpinelinux.org/alpine/aports/-/issues/490Provide special group with read access to /proc2023-11-14T14:35:50ZDuane HughesProvide special group with read access to /procThis is needed by processes (such as zabbix\_agentd) that require read
access to /proc directory. Sounds like some config option needs to be
enabled in the grsec kernel.
*(from redmine: issue id 490, created on 2010-12-07, closed on 20...This is needed by processes (such as zabbix\_agentd) that require read
access to /proc directory. Sounds like some config option needs to be
enabled in the grsec kernel.
*(from redmine: issue id 490, created on 2010-12-07, closed on 2010-12-09)*
* Changesets:
* Revision b868fd504bdc0d6abede6b4ca4892405d9810560 on 2010-12-07T14:18:13Z:
```
main/linux-grsec: enable grsecurity proc usergroup
All users in group number 700 will be able to see all process info,
network related stuff and kernel symbols.
ref #490
```
* Revision a946e1cdc42ee7b7f804f46b818e029a2d7856cb on 2010-12-08T15:57:50Z:
```
main/linux-grsec: use GID=30 for readproc
http://lists.alpinelinux.org/alpine-devel/1214.html
ref #490
```
* Revision 91e51d6b6b4494617573c0a3f3c08e09d3e81647 on 2010-12-09T08:14:45Z:
```
main/linux-grsec: enable grsecurity proc usergroup
All users in group number 700 will be able to see all process info,
network related stuff and kernel symbols.
ref #490
(cherry picked from commit b868fd504bdc0d6abede6b4ca4892405d9810560)
```
* Revision 4bdbac4b4c6b5504c1b20b02af2de31bc983f802 on 2010-12-09T08:14:54Z:
```
main/linux-grsec: use GID=30 for readproc
http://lists.alpinelinux.org/alpine-devel/1214.html
ref #490
(cherry picked from commit a946e1cdc42ee7b7f804f46b818e029a2d7856cb)
```Alpine 2.1.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/3313dbus-daemon-launch-helper is installed setuid root as part of dbus package2023-11-08T14:21:42ZRich Felkerdbus-daemon-launch-helper is installed setuid root as part of dbus packagedbus-daemon-launch-helper is needed only for “D-BUS System Activation”,
a feature similar to systemd activation where dbus actually starts
daemons itself rather than having them started through the init system
with the proper initial pri...dbus-daemon-launch-helper is needed only for “D-BUS System Activation”,
a feature similar to systemd activation where dbus actually starts
daemons itself rather than having them started through the init system
with the proper initial privileges, which obviously require a setuid
helper. This is described in:
http://dbus.freedesktop.org/doc/system-activation.txt
Such a setup is almost certainly an undesirable risk in a hardened
environment, and it’s not clear that it’s needed or useful at all with
proper use of OpenRC. Thus, dbus-daemon-launch-helper should not be
installed setuid by default. Moving it to a separate package (e.g.
dbus-system-activation) may be an appropriate solution.
*(from redmine: issue id 3313, created on 2014-08-27)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/1046testing/usb-modeswitch: script installed in wrong location2023-10-24T21:16:38ZNatanael Copatesting/usb-modeswitch: script installed in wrong locationIt appears that the udev rule tries to execute /lib/udev/usb\_modeswitch
which is a directory.
Mar 8 13:07:15 epoxy kern.warn kernel: [ 12.603814] usb 2-3: usbfs: process 1147 (usb_modeswitch) did not claim interface 0 before use...It appears that the udev rule tries to execute /lib/udev/usb\_modeswitch
which is a directory.
Mar 8 13:07:15 epoxy kern.warn kernel: [ 12.603814] usb 2-3: usbfs: process 1147 (usb_modeswitch) did not claim interface 0 before use
Mar 8 13:07:22 epoxy daemon.err udevd[1169]: failed to execute '/lib/udev/usb_modeswitch' 'usb_modeswitch --driver-bind /devices/pci0000:00/0000:00:03.1/usb2/2-3/2-3:1.0 12d1/1506/0': Permission denied
Mar 8 13:07:22 epoxy daemon.err udevd[1170]: failed to execute '/lib/udev/usb_modeswitch' 'usb_modeswitch --symlink-name /devices/pci0000:00/0000:00:03.1/usb2/2-3/2-3:1.0/ttyUSB0/tty/ttyUSB0 12d1 1506 ': Permission denied
Mar 8 13:07:22 epoxy daemon.err udevd[1171]: failed to execute '/lib/udev/usb_modeswitch' 'usb_modeswitch --symlink-name /devices/pci0000:00/0000:00:03.1/usb2/2-3/2-3:1.4/ttyUSB3/tty/ttyUSB3 12d1 1506 ': Permission denied
Mar 8 13:07:22 epoxy daemon.err udevd[1173]: failed to execute '/lib/udev/usb_modeswitch' 'usb_modeswitch --symlink-name /devices/pci0000:00/0000:00:03.1/usb2/2-3/2-3:1.2/ttyUSB1/tty/ttyUSB1 12d1 1506 ': Permission denied
Mar 8 13:07:22 epoxy daemon.err udevd[1174]: failed to execute '/lib/udev/usb_modeswitch' 'usb_modeswitch --symlink-name /devices/pci0000:00/0000:00:03.1/usb2/2-3/2-3:1.3/ttyUSB2/tty/ttyUSB2 12d1 1506 ': Permission denied
This is most likely because the APKBUILD creates
$pkgdir/lib/udev/usb\_modeswitch directory during prepare phase. I guess
there are somethign like:
`install usb_modewitch.sh /lib/udev/usb_modeswitch` in the make file.
Since the target exist as a direcotry the script is installed in there.
Removing the mkdir line should probably fix it.
*(from redmine: issue id 1046, created on 2012-03-12, closed on 2012-05-09)*
* Changesets:
* Revision 23d8dd2d13e5d92b606af30f639064db7ae5c0f6 by Natanael Copa on 2012-03-12T15:58:46Z:
```
testing/usb-modeswitch: upgrade to 1.2.3
also fixes #1046
```Leonardo ArenaLeonardo Arenahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/7834[3.4] libgcrypt: Missing input validation for X25519 curve (CVE-2017-0379)2023-10-19T22:31:13ZAlicha CH[3.4] libgcrypt: Missing input validation for X25519 curve (CVE-2017-0379)Libgcrypt before 1.8.1 does not properly consider Curve25519
side-channel attacks,
which makes it easier for attackers to discover a secret key, related to
cipher/ecc.c and mpi/ec.c.
### References:
https://nvd.nist.gov/vuln/detail/C...Libgcrypt before 1.8.1 does not properly consider Curve25519
side-channel attacks,
which makes it easier for attackers to discover a secret key, related to
cipher/ecc.c and mpi/ec.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2017-0379
https://eprint.iacr.org/2017/806
### Patch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=da780c8183cccc8f533c8ace8211ac2cb2bdee7b
*(from redmine: issue id 7834, created on 2017-09-14, closed on 2017-09-19)*
* Relations:
* parent #7831
* Changesets:
* Revision 3189f66bd0bf5c00883e527600243bc084badd61 by Natanael Copa on 2017-09-19T09:00:29Z:
```
main/libgcrypt: security upgrade to 1.7.9 (CVE-2017-0378)
fixes #7834
```3.4.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12crond doesnt seem to succesfully execute run-parts2023-10-18T19:57:20Zalgitbotcrond doesnt seem to succesfully execute run-partsWhen i try to run run-parts manually it doesn’t seem to work either
*(from redmine: issue id 12, created on 2009-03-22, closed on 2009-03-23)*When i try to run run-parts manually it doesn’t seem to work either
*(from redmine: issue id 12, created on 2009-03-22, closed on 2009-03-23)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9extra/squid: add logrotate script2023-10-18T19:57:20ZNatanael Copaextra/squid: add logrotate scriptsquid logs tend to be big. add a logrotate script and add logrotate to
depends. then things will just work, as long as squid is running.
*(from redmine: issue id 9, created on 2009-03-18, closed on 2009-04-02)*
* Changesets:
* Revis...squid logs tend to be big. add a logrotate script and add logrotate to
depends. then things will just work, as long as squid is running.
*(from redmine: issue id 9, created on 2009-03-18, closed on 2009-04-02)*
* Changesets:
* Revision 206861582c4bf8ad92aee9f04bf4171893fb56b1 on 2009-04-02T08:23:12Z:
```
extra/squid: add logrotate script
fixes #9
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/6upgrade extra/libpng to atleast 1.2.352023-10-18T19:57:20ZNatanael Copaupgrade extra/libpng to atleast 1.2.35Security upgrade
\[ 1 \] CVE-2008-5907
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5907
\[ 2 \] CVE-2008-6218
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6218
\[ 3 \] CVE-2009-0040
http://cve.mitre.org/cg...Security upgrade
\[ 1 \] CVE-2008-5907
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5907
\[ 2 \] CVE-2008-6218
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6218
\[ 3 \] CVE-2009-0040
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0040
*(from redmine: issue id 6, created on 2009-03-16, closed on 2009-03-16)*Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/5upgrade core/curl to atleast 7.19.42023-10-18T19:57:20ZNatanael Copaupgrade core/curl to atleast 7.19.4this is a security upgrade
http://curl.haxx.se/docs/adv\_20090303.html
*(from redmine: issue id 5, created on 2009-03-16, closed on 2009-03-18)*this is a security upgrade
http://curl.haxx.se/docs/adv\_20090303.html
*(from redmine: issue id 5, created on 2009-03-16, closed on 2009-03-18)*Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4testing if anonymous can submit new issues2023-10-18T19:57:20Zalgitbottesting if anonymous can submit new issuesI think they can, but there is no way for anonymous to leave an email
address or something.
*(from redmine: issue id 4, created on 2009-03-11, closed on 2009-03-16)*I think they can, but there is no way for anonymous to leave an email
address or something.
*(from redmine: issue id 4, created on 2009-03-11, closed on 2009-03-16)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295gettext 0.20.2 - test-canonicalize-lgpl2023-09-19T14:25:04ZLeogettext 0.20.2 - test-canonicalize-lgpl```txt
test-canonicalize-lgpl.c:211: assertion 'strcmp (result1, "/") == 0' failed
Aborted (core dumped)
FAIL test-canonicalize-lgpl (exit status: 134)
``````txt
test-canonicalize-lgpl.c:211: assertion 'strcmp (result1, "/") == 0' failed
Aborted (core dumped)
FAIL test-canonicalize-lgpl (exit status: 134)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/13361dcc package on 3.15 has almost blank nonfunctioning init script2023-09-14T10:33:26Zxpufxdcc package on 3.15 has almost blank nonfunctioning init scriptalpine-release 3.15.0 / dcc-openrc-2.3.168-r0
https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/dcc/dcc.initd
Starting with this script would cause a syntax error. I guess it expects something in the start() block. Wh...alpine-release 3.15.0 / dcc-openrc-2.3.168-r0
https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/dcc/dcc.initd
Starting with this script would cause a syntax error. I guess it expects something in the start() block. When that block was removed it can't find some directores it needs for pid files etc in /var/run. I don't know enough to write a custom script and solve all the issues.
Instead, I was able to get the full init script from gentoo and start dcc with it. (Gentoo's script seemed to need /etc/dcc/dcc_conf. I worked around that issue by symlinking /etc/dcc to /var/dcc)https://gitlab.alpinelinux.org/alpine/aports/-/issues/8233Apache is running a threaded MPM, but your PHP Module is not compiled to be t...2023-09-12T10:38:19ZThomas SchneiderApache is running a threaded MPM, but your PHP Module is not compiled to be threadsafeHi,
I have installed a (lean) LAMP Server.
I want to use *php-fpm* and found this wiki page:
https://wiki.alpinelinux.org/wiki/Apache\_with\_php-fpm
However, when comment line LoadModule mpm\_prefork\_module
modules/mod\_mpm\_prefo...Hi,
I have installed a (lean) LAMP Server.
I want to use *php-fpm* and found this wiki page:
https://wiki.alpinelinux.org/wiki/Apache\_with\_php-fpm
However, when comment line LoadModule mpm\_prefork\_module
modules/mod\_mpm\_prefork.so and uncomment line \#LoadModule
mpm\_event\_module modules/mod\_mpm\_event.so I get this error:
~\# apachectl configtest
\[Sat Dec 02 10:23:46.920215 2017\] \[php7:crit\] \[pid 1255:tid
140551487437640\] Apache is running a threaded MPM, but your PHP Module
is not compiled to be threadsafe. You need to recompile PHP.
AH00013: Pre-configuration failed
What’s causing this error?
THX
*(from redmine: issue id 8233, created on 2017-12-02)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12302Alpine zone on SmartOS upgraded to 3.13 can't reboot anymore2023-09-09T21:12:13ZJan VlachAlpine zone on SmartOS upgraded to 3.13 can't reboot anymoreI'm running lots of alpine linux zones on Joyent's SmartOS since version 3.5, always only changing the version in /etc/apk/repositories and doing upgrade. Everything always worked just fine, many thanks for that!
I've upgraded my first ...I'm running lots of alpine linux zones on Joyent's SmartOS since version 3.5, always only changing the version in /etc/apk/repositories and doing upgrade. Everything always worked just fine, many thanks for that!
I've upgraded my first zone from 3.12 to 3.13 now and I have problems with reboot after I boot into 3.13 userspace:
```
66c60285-54af-ee40-ca60-904aade29c33:~# reboot
reboot: (null): Operation not permitted
66c60285-54af-ee40-ca60-904aade29c33:~# strace -s 65535 -f reboot
execve("/sbin/reboot", ["reboot"], 0x7fffffeffc58 /* 14 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7fffef38db48) = 0
set_tid_address(0x7fffef38df90) = 12430
brk(NULL) = 0x1000
brk(0x3000) = 0x3000
mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1000
mprotect(0x7fffef38a000, 4096, PROT_READ) = 0
mprotect(0x7fffef456000, 16384, PROT_READ) = 0
getuid() = 0
nanosleep({tv_sec=0, tv_nsec=0}, 0x7fffffeffb50) = 0
sync() = 0
kill(1, SIGTERM) = -1 EPERM (Operation not permitted)
access("/proc/meminfo", F_OK) = 0
write(2, "reboot: (null): Operation not permitted\n", 40reboot: (null): Operation not permitted
) = 40
exit_group(1 <unfinished ...>
+++ exited with 1 +++
66c60285-54af-ee40-ca60-904aade29c33:~# kill -1 1
ash: can't kill pid 1: Operation not permitted
```
All these work just fine on anything <= 3.12, including sending TERM to init process.
Any idea what's happening here?
Thank you,
JVhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/35Quagga Autonomous System Number Remote Denial Of Service Vulnerability2023-08-13T23:17:36Ziilluzion _Quagga Autonomous System Number Remote Denial Of Service Vulnerability**Alpine Linux related**: All *quagga-0.99.xx* packages in Alpine Linux
releases up to *alpine-1.9.0\_alpha9*
**Severity**: Medium
**Potential loss type**: Availability
**Patch available**: Yes
**Vulnerability description**:
>The...**Alpine Linux related**: All *quagga-0.99.xx* packages in Alpine Linux
releases up to *alpine-1.9.0\_alpha9*
**Severity**: Medium
**Potential loss type**: Availability
**Patch available**: Yes
**Vulnerability description**:
>The BGP daemon (bgpd) in Quagga 0.99.11 and earlier allows remote
attackers to cause a denial of service (crash) via an AS path containing
ASN elements whose string representation is longer than expected, which
triggers an assert error.
**References**:
- DEBIAN: http://www.debian.org/security/2009/dsa-1788
- MLIST: http://marc.info/?l=quagga-dev&m=123364779626078&w=2
- CONFIRM: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526311
- XF: http://xforce.iss.net/xforce/xfdb/50317
- UBUNTU: http://www.ubuntu.com/usn/usn-775-1
- SECTRACK: http://www.securitytracker.com/id?1022164
- BID: http://www.securityfocus.com/bid/34817
- OSVDB: http://www.osvdb.org/54200
- MLIST: http://www.openwall.com/lists/oss-security/2009/05/01/2
- MLIST: http://www.openwall.com/lists/oss-security/2009/05/01/1
- MANDRIVA:
http://www.mandriva.com/security/advisories?name=MDVSA-2009:109
- MISC: http://thread.gmane.org/gmane.network.quagga.devel/6513
- SECUNIA: http://secunia.com/advisories/35061
- SECUNIA: http://secunia.com/advisories/34999
*(from redmine: issue id 35, created on 2009-05-21, closed on 2009-06-23)*Natanael CopaNatanael Copa2009-05-28https://gitlab.alpinelinux.org/alpine/aports/-/issues/10140main/musl libc6-compat broken for most libraries on x86_642023-07-03T03:13:32ZX Xanonidmain/musl libc6-compat broken for most libraries on x86_64With
https://git.alpinelinux.org/aports/commit/main/musl/APKBUILD?id=7b32fee49798e36cb5a7dfde30183f9717472cf6
`/lib64` was changed to a separate folder.
Before `/lib64` was a symlink to `/lib`.
Now `ld-linux-x86-64.so.2` is only creat...With
https://git.alpinelinux.org/aports/commit/main/musl/APKBUILD?id=7b32fee49798e36cb5a7dfde30183f9717472cf6
`/lib64` was changed to a separate folder.
Before `/lib64` was a symlink to `/lib`.
Now `ld-linux-x86-64.so.2` is only created as
`/lib64/ld-linux-x86-64.so.2` and therefore no longer available in
`/lib/ld-linux-x86-64.so.2`.
Unfortunately, `/lib64` is not in the default `LD_LIBRARY_PATH`. As a
result of this, loading of libraries built with glibc is broken in
alpine >= 3.9 (except for those libraries who refer explicitly to
/lib64/ld-linux-x86-64.so.2).
This caused https://github.com/docker-flink/docker-flink/issues/69 .
*(from redmine: issue id 10140, created on 2019-03-20)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/8741xpra start doesn't read /etc/xpra/xorg.conf2023-06-30T23:34:25Zalgitbotxpra start doesn't read /etc/xpra/xorg.confI’ve installed xpra in alpine docker container, but I think this issue
also appears in a normal install.
When I use <code>xpra start —bind-tcp=0.0.0.0:10000 —daemon=no
—start-child=xclock</code>, it failed with reason:
<code class=...I’ve installed xpra in alpine docker container, but I think this issue
also appears in a normal install.
When I use <code>xpra start —bind-tcp=0.0.0.0:10000 —daemon=no
—start-child=xclock</code>, it failed with reason:
<code class="text">
/etc/xpra/conf.d # xpra start --bind-tcp=0.0.0.0:10000 --daemon=no --start-child=xclock
Warning: running as root
Failed to rename log file "/tmp/Xorg.S159.log" to "/tmp/Xorg.S159.log": No such file or directory
X.Org X Server 1.19.5
Release Date: 2017-10-12
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.45-0-grsec x86_64 Alpine Linux
Current Operating System: Linux bb7312faa016 4.9.76-gentoo-r1 #27 SMP Sun Mar 11 14:27:21 CST 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.76-gentoo-r1 root=UUID=cf0a3df4-4e99-49f0-b46c-12904e489dd5 ro domdadm
Build Date: 07 November 2017 03:08:54PM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/Xorg.S159.log", Time: Tue Mar 27 10:51:31 2018
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory)
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/tmp/Xorg.S159.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
InitException: xpra_Xdummy did not provide a display number using -displayfd
xpra initialization error:
xpra_Xdummy did not provide a display number using -displayfd
2018-03-27 10:51:39,466 closing TCP socket 0.0.0.0:10000
</code>
Digging into /tmp/Xorg.S159.log gives me this:
<code class="text">
[ 2610.559] (EE) Unable to locate/open config file: "/home/buildozer/aports/community/xpra/pkg/xpra/etc/xpra/xorg.conf"
[ 2610.559] (EE) Unable to locate/open config directory: "/root/.xpra/xorg.conf.d"
[ 2610.559] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 2610.559] (==) No Layout section. Using the first Screen section.
[ 2610.559] (==) No screen section available. Using defaults.
[ 2610.559] (**) |-->Screen "Default Screen Section" (0)
[ 2610.559] (**) | |-->Monitor "<default monitor>"
</code>
It seems that it tried to read the Xorg config file from
<code>/home/buildozer/aports/community/xpra/pkg/xpra/etc/xpra/xorg.conf</code>.
So I added <code>-config /etc/xpra/xorg.conf</code> to
<code>/etc/xpra/conf.d/55\_server\_x11.conf</code> like the following
<code class="text">
/etc/xpra/conf.d # tail 55_server_x11.conf
# xvfb = /usr/bin/Xorg -noreset -nolisten tcp \
# +extension GLX +extension RANDR +extension RENDER \
# -auth $XAUTHORITY \
# -logfile auto/Xorg.${DISPLAY}.log \
# -configdir ${HOME}/.xpra/xorg.conf.d \
# -config /home/buildozer/aports/community/xpra/pkg/xpra/etc/xpra/xorg.conf
#
# Selecting virtual X server:
#xvfb = xpra_Xdummy -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d -config /home/buildozer/aports/community/xpra/pkg/xpra/etc/xpra/xorg.conf
xvfb = xpra_Xdummy -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d -config /home/buildozer/aports/community/xpra/pkg/xpra/etc/xpra/xorg.conf -config /etc/xpra/xorg.conf
</code>
and then it works.
*(from redmine: issue id 8741, created on 2018-03-27)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10525Unmounting /media/usb fails during shutdown if udev is running2023-06-30T07:30:11ZLubos DolezalUnmounting /media/usb fails during shutdown if udev is runningAttachments show two cases:
*unmounting\_with-udev*: udev (and udev-trigger) was previously started
in the sysinit runlevel.
*unmounting\_without-udev*: udev (and udev-trigger) was stopped before
shutdown.
Installed udev packages:
u...Attachments show two cases:
*unmounting\_with-udev*: udev (and udev-trigger) was previously started
in the sysinit runlevel.
*unmounting\_without-udev*: udev (and udev-trigger) was stopped before
shutdown.
Installed udev packages:
udev-init-scripts-32-r2
udev-init-scripts-openrc-32-r2
eudev-libs-3.2.7-r0
eudev-3.2.7-r0
/proc/mounts: https://pastebin.com/hzvQirkg
*(from redmine: issue id 10525, created on 2019-05-31)*
* Uploads:
* ![unmounting_with-udev](/uploads/b31f0ed8a657e91eba51b03d46bc9339/unmounting_with-udev.png)
* ![unmounting_without-udev](/uploads/64ce364123ae64e23a15f08eab02fe36/unmounting_without-udev.png)3.12.1Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11602Libvirt service (libvirtd) not starting correctly since upgrading Alpine from...2023-06-26T05:36:29ZFernando Casas SchössowLibvirt service (libvirtd) not starting correctly since upgrading Alpine from 3.11.6 to 3.12.0Hi there,
Last weekend I updated two KVM hosts (x86_64) running Alpine 3.11.6 to 3.12.0.
Since upgrading libvirt service (libvirtd) is not starting correctly.
Two processes of libvirtd are spawned and interaction with libvirt (ie: virsh...Hi there,
Last weekend I updated two KVM hosts (x86_64) running Alpine 3.11.6 to 3.12.0.
Since upgrading libvirt service (libvirtd) is not starting correctly.
Two processes of libvirtd are spawned and interaction with libvirt (ie: virsh or remotely over TLS) doesn't work. If you run a virsh command, the command will just hang for a long time until I press ctrl+c to stop it.
If I manually kill one of the libvirtd processes, libvirt seems to start working again. I can execute virsh commands without any issues, same with remote access.
I found this other issue that may be related but I'm not really sure: [11361](https://gitlab.alpinelinux.org/alpine/aports/-/issues/11361)
The problem is not only happening at startup, I'm still investigating but even while libvirt is already running, after sometime a second process is spawned (don't know why yet) and libvirt stops working again. I need to connect to the KVM host, kill the new libvirtd process that was spawned, and operation resumes as usual.
Any ideas?
Thanks.3.12.1Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9921dovecot-pigeonhole-plugin (sieve) not functional (on armhf only?)2023-06-21T10:49:00Zalgitbotdovecot-pigeonhole-plugin (sieve) not functional (on armhf only?)As soon as a user logs in, dlopen() complaints with the following
error:
Error relocating /usr/lib/dovecot/lib90\_sieve\_plugin.so:
mail\_deliver\_get\_return\_address: symbol not found
As a result, the client cannot connect. It is ir...As soon as a user logs in, dlopen() complaints with the following
error:
Error relocating /usr/lib/dovecot/lib90\_sieve\_plugin.so:
mail\_deliver\_get\_return\_address: symbol not found
As a result, the client cannot connect. It is irrespective of the client
using sieve or not, in other words, as soon as this plugin is enabled,
dovecot becomes useless because it cannot accept new IMAP connections.
Version 2.3.3-r0
Platform: armhf.
I don’t know if this occurs on other platforms as well.
*(from redmine: issue id 9921, created on 2019-01-26, closed on 2019-05-09)*3.9.4Natanael CopaNatanael Copa