aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2023-06-30T07:30:11Zhttps://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/9190imagemagick: disable OpenMP for stability2023-06-02T03:41:50ZAlexander Edlandimagemagick: disable OpenMP for stabilityImageMagick uses OpenMP for improved performance. For some software
linking ImageMagick, this appears to cause segfaults in OpenMP-related
code, but seemingly only when running on certain processors. My testcase
(non-trivial, an uncommit...ImageMagick uses OpenMP for improved performance. For some software
linking ImageMagick, this appears to cause segfaults in OpenMP-related
code, but seemingly only when running on certain processors. My testcase
(non-trivial, an uncommitted aport) exhibits consistent crashes on one
laptop but runs fine on another. Both laptops perform the same minimal
test in a clean chroot with the same packages from edge. The laptop
exhibiting the crashes has an i5-6200U while the seemingly immune laptop
has an i5-6300HQ. The following two stacks have been observed in gdb:
Program received signal SIGSEGV, Segmentation fault.
#0 0x00007ffff4ae0415 in QueueAuthenticPixels () from /usr/lib/libMagickCore-7.Q16HDRI.so.6
#1 0x00007fffe92e7398 in ?? () from /usr/lib/ImageMagick-7.0.8/modules-Q16HDRI/coders/bmp.so
#2 0x00007ffff4b17892 in ReadImage () from /usr/lib/libMagickCore-7.Q16HDRI.so.6
#3 0x00007ffff526d5c2 in Magick::Image::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libMagick++-7.Q16HDRI.so.4
#4 0x00007ffff526d61f in Magick::Image::Image(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libMagick++-7.Q16HDRI.so.4
#5 0x00007ffff54978ef in readCreate (in=in@entry=0x5555557cd580, out=out@entry=0x555555a156e0, userData=<optimized out>, core=0x5555557a2560, vsapi=0x7ffff6ebbe40 <vs_internal_vsapi>) at src/filters/imwri/imwri.cpp:784
#6 0x00007ffff6c9442d in VSPlugin::invoke (this=this@entry=0x5555558d5e20, funcName=..., args=...) at src/core/vscore.cpp:1694
#7 0x00007ffff6c8aaed in invoke (plugin=0x5555558d5e20, name=<optimized out>, args=0x5555557cd580) at src/core/vsapi.cpp:386
#8 0x00007ffff6f30177 in __pyx_pf_11vapoursynth_8Function_2__call__ (__pyx_v_kwargs=0x7ffff58d33a8, __pyx_v_args=0x7ffff7e996a0, __pyx_v_self=0x7ffff58aafc0) at src/cython/vapoursynth.c:39415
#9 __pyx_pw_11vapoursynth_8Function_3__call__ (__pyx_v_self=0x7ffff58aafc0, __pyx_args=0x7ffff7e996a0, __pyx_kwds=<optimized out>) at src/cython/vapoursynth.c:38521
#10 0x00007ffff71e4660 in _PyObject_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#11 0x00007ffff71e4acc in _PyObject_FastCallKeywords () from /usr/lib/libpython3.6m.so.1.0
#12 0x00007ffff727184d in ?? () from /usr/lib/libpython3.6m.so.1.0
#13 0x00007ffff7277626 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#14 0x00007ffff72715a5 in ?? () from /usr/lib/libpython3.6m.so.1.0
#15 0x00007ffff72718d5 in PyEval_EvalCodeEx () from /usr/lib/libpython3.6m.so.1.0
#16 0x00007ffff72718f6 in PyEval_EvalCode () from /usr/lib/libpython3.6m.so.1.0
#17 0x00007ffff6f229d6 in __Pyx_PyExec3 (locals=0x7ffff7f25e10, globals=0x7ffff7f25e10, o=0x7ffff58ef810) at src/cython/vapoursynth.c:79365
#18 vpy_evaluateScript (__pyx_v_se=__pyx_v_se@entry=0x5555557d6960, __pyx_v_script=<optimized out>, __pyx_v_scriptFilename=<optimized out>, __pyx_v_scriptFilename@entry=0x7fffffffe4d8 "red.vpy", __pyx_v_flags=__pyx_v_flags@entry=1) at src/cython/vapoursynth.c:41408
#19 0x00007ffff6f2501b in vpy_evaluateFile (__pyx_v_se=0x5555557d6960, __pyx_v_scriptFilename=<optimized out>, __pyx_v_flags=1) at src/cython/vapoursynth.c:42406
#20 0x00007ffff7b6a198 in vsscript_evaluateFile (handle=0x55555575c210 <se>, scriptFilename=0x7fffffffe4d8 "red.vpy", flags=1) at src/vsscript/vsscript.cpp:160
#21 0x0000555555556bda in main (argc=3, argv=<optimized out>) at src/vspipe/vspipe.cpp:669
Program received signal SIGSEGV, Segmentation fault.
#0 0x00007ffff345bfab in omp_get_max_threads () from /usr/lib/libgomp.so.1
#1 0x00007ffff3ae3bb0 in ?? () from /usr/lib/libMagickCore-7.Q16HDRI.so.6
#2 0x00007ffff3a97540 in MagickCoreGenesis () from /usr/lib/libMagickCore-7.Q16HDRI.so.6
#3 0x00007ffff417a63c in Magick::InitializeMagick(char const*) () from /usr/lib/libMagick++-7.Q16HDRI.so.4
#4 0x00007ffff43af835 in initMagick (vsapi=0x7ffff6ebce40 <vs_internal_vsapi>, core=0x55555584f0c0) at src/filters/imwri/imwri.cpp:73
#5 0x00007ffff43b058f in readCreate (in=in@entry=0x555555a9b120, out=out@entry=0x555555a99f80, userData=<optimized out>, core=0x55555584f0c0, vsapi=0x7ffff6ebce40 <vs_internal_vsapi>) at src/filters/imwri/imwri.cpp:748
#6 0x00007ffff6c9542d in VSPlugin::invoke (this=this@entry=0x5555558eb4c0, funcName=..., args=...) at src/core/vscore.cpp:1694
#7 0x00007ffff6c8baed in invoke (plugin=0x5555558eb4c0, name=<optimized out>, args=0x555555a9b120) at src/core/vsapi.cpp:386
#8 0x00007ffff6f31137 in __pyx_pf_11vapoursynth_8Function_2__call__ (__pyx_v_kwargs=0x7ffff58d0af8, __pyx_v_args=0x7ffff7e96898, __pyx_v_self=0x7ffff58d0ab0) at src/cython/vapoursynth.c:39415
#9 __pyx_pw_11vapoursynth_8Function_3__call__ (__pyx_v_self=0x7ffff58d0ab0, __pyx_args=0x7ffff7e96898, __pyx_kwds=<optimized out>) at src/cython/vapoursynth.c:38521
#10 0x00007ffff71e8410 in _PyObject_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#11 0x00007ffff71e887c in _PyObject_FastCallKeywords () from /usr/lib/libpython3.6m.so.1.0
#12 0x00007ffff72755fd in ?? () from /usr/lib/libpython3.6m.so.1.0
#13 0x00007ffff727b3d6 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#14 0x00007ffff7275355 in ?? () from /usr/lib/libpython3.6m.so.1.0
#15 0x00007ffff7275685 in PyEval_EvalCodeEx () from /usr/lib/libpython3.6m.so.1.0
#16 0x00007ffff72756a6 in PyEval_EvalCode () from /usr/lib/libpython3.6m.so.1.0
#17 0x00007ffff6f23996 in __Pyx_PyExec3 (locals=0x7ffff7f26ab0, globals=0x7ffff7f26ab0, o=0x7ffff58ee780) at src/cython/vapoursynth.c:79365
#18 vpy_evaluateScript (__pyx_v_se=__pyx_v_se@entry=0x5555558a2cc0, __pyx_v_script=<optimized out>, __pyx_v_scriptFilename=<optimized out>, __pyx_v_scriptFilename@entry=0x7fffffffe5c8 "red.vpy", __pyx_v_flags=__pyx_v_flags@entry=1) at src/cython/vapoursynth.c:41408
#19 0x00007ffff6f25fdb in vpy_evaluateFile (__pyx_v_se=0x5555558a2cc0, __pyx_v_scriptFilename=<optimized out>, __pyx_v_flags=1) at src/cython/vapoursynth.c:42406
#20 0x00007ffff7b6a198 in vsscript_evaluateFile (handle=0x55555575c210 <se>, scriptFilename=0x7fffffffe5c8 "red.vpy", flags=1) at src/vsscript/vsscript.cpp:160
#21 0x0000555555556bda in main (argc=3, argv=<optimized out>) at src/vspipe/vspipe.cpp:669
…in addition to the following assert when executing the test outside of
gdb:
Assertion failed: id < (int) cache_info->number_threads (MagickCore/cache.c: QueueAuthenticPixels: 4323)
while I cannot find any similar issues where effort has been made to
uncover the underlying problem, most people seem satisfied with the
“fix” of disabling OpenMP:
- https://www.imagemagick.org/discourse-server/viewtopic.php?t=32516
- https://github.com/termux/termux-packages/issues/1314
- https://stackoverflow.com/questions/2838307/why-is-this-rmagick-call-generating-a-segmentation-fault
contrary to what is mentioned in the termux issue, setting
OMP\_NUM\_THREADS=1 does not prevent the segfault in my scenario,
however building ImageMagick with —disable-openmp does.
*(from redmine: issue id 9190, created on 2018-08-05, closed on 2018-12-20)*
* Changesets:
* Revision a23a75a8962b419f92fe63ba60317496bbfbe712 by Natanael Copa on 2018-08-06T10:19:40Z:
```
main/imagemagick: upgrade to 7.0.8.8 and disable openmp
openmp appears to cause problems on some machines. We disable it
everywhere.
fixes #9190
```
* Revision edd37627b316f881325df6073fb379a4671d366e by Natanael Copa on 2018-11-21T14:37:18Z:
```
main/imagemagick: disable openmp
openmp appears to cause problems on some machines. We disable it
everywhere.
fixes #9190
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/5194Package request: AVRGCC toolchain for atmel MCUs and the Arduino IDE2023-04-30T23:51:21ZScrumpy JackPackage request: AVRGCC toolchain for atmel MCUs and the Arduino IDEIt’s a big task, described here
[http://nongnu.org/avr-libc/user-manual/install\_tools.html](http://nongnu.org/avr-libc/user-manual/install\_tools.html) and
here
[http://avr-eclipse.sourceforge.net/wiki/index.php/The\_AVR\_GCC\_Toolchain...It’s a big task, described here
[http://nongnu.org/avr-libc/user-manual/install\_tools.html](http://nongnu.org/avr-libc/user-manual/install\_tools.html) and
here
[http://avr-eclipse.sourceforge.net/wiki/index.php/The\_AVR\_GCC\_Toolchain](http://avr-eclipse.sourceforge.net/wiki/index.php/The\_AVR\_GCC\_Toolchain)
Sources are here:
[http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/](http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/),
which Arduino patch here
[https://github.com/arduino/toolchain-avr](https://github.com/arduino/toolchain-avr)
The IDE is here: [https://github.com/arduino/Arduino](https://github.com/arduino/Arduino)
*(from redmine: issue id 5194, created on 2016-02-28)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/7780Volume containing apkovl is not remounted according to the apkovl's /etc/fsta...2023-04-30T01:34:09ZalgitbotVolume containing apkovl is not remounted according to the apkovl's /etc/fstab entryTo reproduce:
1) make a new VM, attach the alpine-virtual iso and a blank virtual disk
as /dev/sda
2) run setup-alpine, selecting a data-only install, mounting to /var
3) set LBU\_BACKUPDIR=/var and run lbu commit
4) reboot and o...To reproduce:
1) make a new VM, attach the alpine-virtual iso and a blank virtual disk
as /dev/sda
2) run setup-alpine, selecting a data-only install, mounting to /var
3) set LBU\_BACKUPDIR=/var and run lbu commit
4) reboot and observer that /dev/sda2 is mounted to /media/sda2, not
/var
Cause: The initramfs /init script is supposed to unmount the device that
the apkovl was found on, after it has been unpacked. There is still
logic to unmount a device stored in $ovl\_unmount, but commit
ba27888b4576ceab7413ab9104d0aeda50990832 (which moved the apkovl search
logic out to nlplug-findfs) removed the last line that set that
variable, and as far as I can tell even the old code never unmounted
non-usb devices correctly.
Fix: Set $ovl\_unmount to the apkovl device unless it is used as the
sysroot? (This might cause a conflict if the apkovl is stored on a
boot\_repository device; IDK.)
*(from redmine: issue id 7780, created on 2017-09-01)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/40Encypted apkovls not working on alpine-1.9.0_alpha122023-04-05T01:43:23Zaa latchmEncypted apkovls not working on alpine-1.9.0_alpha12On Alpine 1.9.0\_alpha12, encrypted overlay fails to load.
Error message:
* Loading user settings from /media/sda1/host.apkovl.tar.gz.aes-256-cbc: openssl: can't load library 'libdl.so.0'
failed. Cipher aes-256-cbc not support...On Alpine 1.9.0\_alpha12, encrypted overlay fails to load.
Error message:
* Loading user settings from /media/sda1/host.apkovl.tar.gz.aes-256-cbc: openssl: can't load library 'libdl.so.0'
failed. Cipher aes-256-cbc not supported.
initramfs emergency recovery shell launched. Type 'exit' to continue boot
*(from redmine: issue id 40, created on 2009-06-01, closed on 2009-06-23)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/5302Booting Alpine iso via memdisk2023-03-07T05:22:55Zjkk jkk88Booting Alpine iso via memdiskHi,
for introducing alpine linux to new user it would be nice to see
possibility to boot iso image directly from grub or pxe via memdisk
(without playing with extraction of files from iso). There seems to be
quite good documentation
ht...Hi,
for introducing alpine linux to new user it would be nice to see
possibility to boot iso image directly from grub or pxe via memdisk
(without playing with extraction of files from iso). There seems to be
quite good documentation
http://www.syslinux.org/wiki/index.php?title=MEMDISK and because small
iso size alpine iso is goot candidate for this.
*(from redmine: issue id 5302, created on 2016-03-22)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/1000postgresql-9.1.2-r1 setup broken2023-03-04T23:49:15ZRoger Pau Monnépostgresql-9.1.2-r1 setup brokenWhen performing a clean install of postgresql on Alpine 2.3.6 I get the
following error when executing \`/etc/init.d/postgresql setup\`:
* Creating a new PostgreSQL database cluster ...
mv /var/lib/postgresql/9.1/data/* /var/li...When performing a clean install of postgresql on Alpine 2.3.6 I get the
following error when executing \`/etc/init.d/postgresql setup\`:
* Creating a new PostgreSQL database cluster ...
mv /var/lib/postgresql/9.1/data/* /var/lib/postgresql/9.1/tmp
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
The default database encoding has accordingly been set to SQL_ASCII.
The default text search configuration will be set to "english".
fixing permissions on existing directory /var/lib/postgresql/9.1/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 10
selecting default shared_buffers ... 400kB
creating configuration files ... ok
creating template1 database in /var/lib/postgresql/9.1/data/base/1 ... FATAL: could not read directory "/usr/share/postgresql/timezone": Bad address
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/9.1/data"
* You can use the '/etc/init.d/postgresql' script to run PostgreSQL instead
* of 'pg_ctl'.
*(from redmine: issue id 1000, created on 2012-02-09, closed on 2013-11-11)*Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/21vserver only has 16mb /tmp directory2023-03-04T22:40:32ZCarlo Landmetervserver only has 16mb /tmp directoryWhen i try to run clamav it will fail because it cannot extract the
database to tmp directory because of insufficient space.
I am running vserver 1.7 with 1.9 guest.
*(from redmine: issue id 21, created on 2009-03-30, closed on 2009-...When i try to run clamav it will fail because it cannot extract the
database to tmp directory because of insufficient space.
I am running vserver 1.7 with 1.9 guest.
*(from redmine: issue id 21, created on 2009-03-30, closed on 2009-04-02)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9324Please remove the alternate console entry from /etc/inittab for alpine-virt2023-02-21T02:55:15ZJohn DoePlease remove the alternate console entry from /etc/inittab for alpine-virtThe last line in /etc/inittab for alpine-virt
(ttyS0::respawn:/sbin/getty -L 115200 ttyS0 vt100) should really not be
there.
It generates a loop of incessant dmesg noise when installed on VMWare
esxi and no doubt other virtual installs ...The last line in /etc/inittab for alpine-virt
(ttyS0::respawn:/sbin/getty -L 115200 ttyS0 vt100) should really not be
there.
It generates a loop of incessant dmesg noise when installed on VMWare
esxi and no doubt other virtual installs too.
That line is not present in other builds such as alpine-extended.
This report is based on the current version available on your website
dl-cdn.alpinelinux.org/alpine/v3.8/releases/x86\_64/alpine-virt-3.8.0-x86\_64.iso
*(from redmine: issue id 9324, created on 2018-08-22, closed on 2019-05-12)*
* Relations:
* duplicates #8704https://gitlab.alpinelinux.org/alpine/aports/-/issues/9723snmpd fails to start because it tries to bind a port twice2023-02-07T17:51:35ZMarco Dickertsnmpd fails to start because it tries to bind a port twiceIn Alpine Edge, snmpd fails to start, because it tries to bind the port
twice. I attached a strace output which were generated by starting snmpd
in the terminal:
$ strace -o snmptrace snmpd -Le
I think the relevant lines are 216...In Alpine Edge, snmpd fails to start, because it tries to bind the port
twice. I attached a strace output which were generated by starting snmpd
in the terminal:
$ strace -o snmptrace snmpd -Le
I think the relevant lines are 2163 and 2258
[2163] bind(9, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
...
[2258] bind(8, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address in use)
Seems not consistent to me. I attached my config, too.
*(from redmine: issue id 9723, created on 2018-12-03)*
* Uploads:
* [snmptrace.txt](/uploads/7af51ae36cc1937267873a72eaf73660/snmptrace.txt) strace of the snmpd start
* [snmpd.conf](/uploads/d7540e02517470fca23834cf46f94bb5/snmpd.conf) snmpd configurationhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9260inefficient TLS access in mesa-gl due to workaround for upstream bug2023-02-07T15:55:22ZRich Felkerinefficient TLS access in mesa-gl due to workaround for upstream bugThe commit message here is wrong:
https://git.alpinelinux.org/cgit/aports/commit?id=f8b4641fcb29e11d4142e990427a6066ff693f41
The —disable-glx-tls workaround introduced in that commit uses
pthread\_key\_create/pthread\_\[gs\]etspecific ...The commit message here is wrong:
https://git.alpinelinux.org/cgit/aports/commit?id=f8b4641fcb29e11d4142e990427a6066ff693f41
The —disable-glx-tls workaround introduced in that commit uses
pthread\_key\_create/pthread\_\[gs\]etspecific to access the current GL
context, which is going to go through a couple layers of function calls,
and in principle could fail at runtime if too many keys were already
created when the library is loaded.
The root problem here is an upstream bug in mesa:
https://bugs.freedesktop.org/show\_bug.cgi?id=35268
The right fix is to patch out all instances of
*attribute*((*tls\_model*(“initial-exec”))) from mesa; this patch should
also be pushed upstream. The result will be very slightly (probably not
measurable) slower than with —enable-glx-tls (which only works when mesa
is directly linked, not dlopen’d), but should be a lot faster than with
—disable-glx-tls. It could be very slightly sped back up (probably as
fast as —enable-glx-tls) using TLSDESC (-mtls-dialect=gnu2) on archs
that support it (i386, x86\_64, aarch64, and in the future arm).
*(from redmine: issue id 9260, created on 2018-08-16)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10215Dvoecot LUA support2023-02-07T15:15:28ZPhillip SchichtelDvoecot LUA supportSince Dovecot release 2.3.0 there is support for LUA-script-based
passdbs and userdbs, however this support is currently not being build
in alpine.
In order to enable LUA support just a few changes are necessary:
1. add the lua dev pac...Since Dovecot release 2.3.0 there is support for LUA-script-based
passdbs and userdbs, however this support is currently not being build
in alpine.
In order to enable LUA support just a few changes are necessary:
1. add the lua dev package to makedepends
2. add a lua subpackage
3. add —with-lua=plugin to the \_configure call in build()
4. create the subpackage with the **\_lua**
*(from redmine: issue id 10215, created on 2019-04-08)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/7580ioctl: overflow in implicit constant conversion2023-02-07T15:08:03Zalgitbotioctl: overflow in implicit constant conversionI’m compiling with `-Wall` on 3.6 and get
`overflow in implicit constant conversion` compiler warnings on some
`ioctl()` calls in my code.
Upon investigation, I found
int ioctl (int, int, ...)
in `/usr/include/sys/ioctl.h` and the...I’m compiling with `-Wall` on 3.6 and get
`overflow in implicit constant conversion` compiler warnings on some
`ioctl()` calls in my code.
Upon investigation, I found
int ioctl (int, int, ...)
in `/usr/include/sys/ioctl.h` and the following in
`/usr/include/bits/ioctl.h` (included by the former)
#define _IOC(a,b,c,d) ( ((a)<<30) | ((b)<<8) | (c) | ((d)<<16) )
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U
#define _IO(a,b) _IOC(_IOC_NONE,(a),(b),0)
#define _IOW(a,b,c) _IOC(_IOC_WRITE,(a),(b),sizeof(c))
#define _IOR(a,b,c) _IOC(_IOC_READ,(a),(b),sizeof(c))
#define _IOWR(a,b,c) _IOC(_IOC_READ|_IOC_WRITE,(a),(b),sizeof(c))
If I am not mistaken and assuming a 32-bit `int`, that means that any
second argument passed to `ioctl()` that is created using the `_IOR` or
`_IOWR` macros will be an **unsigned** 32-bit integer with its most
significant bit set and will trigger the warning I observe.
I subscribe to AWARE (All Warnings Are Really Errors) and normally also
set `-Werror` so I really would like to get this fixed.
BTW, most other distributions I compile on define `ioctl()` as
int ioctl (int, unsigned long, ...)
and chaging your declaration to take an `unsigned int` “fixes” this for
me.
*(from redmine: issue id 7580, created on 2017-07-21)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9853lxdm does not restart, scritp are broken2023-02-07T15:07:40ZPICCORO Lenz McKAYlxdm does not restart, scritp are brokenthe lxdm package have buggy and uncomplete implementation..
if try to stop, does not property grab the status of proc:
<code class="text">
root@alpine:~/alpineinstalls/recetas$ rc-service lxdm restart
* Stopping lxdm ...
...the lxdm package have buggy and uncomplete implementation..
if try to stop, does not property grab the status of proc:
<code class="text">
root@alpine:~/alpineinstalls/recetas$ rc-service lxdm restart
* Stopping lxdm ...
* start-stop-daemon: 1 process refused to stop
* Failed to stop lxdm [ !! ]
* ERROR: lxdm failed to stop
root@alpine:~/alpineinstalls/recetas$ rc-service lxdm stop
* Stopping lxdm ...
* start-stop-daemon: 1 process refused to stop
* Failed to stop lxdm [ !! ]
* ERROR: lxdm failed to stop
</code>
as a suggestion must track all the recent patches in sf git lxde
repository and winbuntu patches to resolve it
*(from redmine: issue id 9853, created on 2019-01-13)*Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10356sudo do not respect environment variables for proxy2023-02-07T14:59:11ZOleg Titovsudo do not respect environment variables for proxyI have a setup with proxy enabled. Everything works fine in root shell
and for ordinary user.
Running \`sudo\` brings problem as the proxy corresponding environment
variables are not exported right.
To reproduce the problem I experienc...I have a setup with proxy enabled. Everything works fine in root shell
and for ordinary user.
Running \`sudo\` brings problem as the proxy corresponding environment
variables are not exported right.
To reproduce the problem I experience enable proxy and run \`sudo wget
www.google.com\`, it should block.
Typical problematic use cases are:
1. sudo apk update|upgrade|add
2. abuild -r
In both cases any web operations will be blocked as the proxy
configuration is missed.
A temporary workaround could be to use \`sudo -E\`. I was suggested to
edit /etc/sudoers to include http\_proxy variables.
I consider that setup-proxy could take care of this.
*(from redmine: issue id 10356, created on 2019-04-28)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10078Subversion package missing svnauthz2023-02-07T14:54:40ZTom KostiainenSubversion package missing svnauthzThe svnauthz (or svnauthz-validate) utility is missing from the
subversion package. The tool is important for validating the authz file
when users and groups are managed through such a file. The authz module
itself is already included in...The svnauthz (or svnauthz-validate) utility is missing from the
subversion package. The tool is important for validating the authz file
when users and groups are managed through such a file. The authz module
itself is already included in the apk package.
Based on a brief check, most other distros have included the svnauthz in
their package.
*(from redmine: issue id 10078, created on 2019-03-10)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/16Package 'transmission-1.51-r0' contains deprecated .INSTALL2023-01-08T23:59:22ZNatanael CopaPackage 'transmission-1.51-r0' contains deprecated .INSTALLShould be converted to new style pre/post-install
*(from redmine: issue id 16, created on 2009-03-24, closed on 2009-03-26)*
* Changesets:
* Revision bbd7886cd79ad2060c9199c768991035228905f7 by Carlo Landmeter on 2009-03-25T21:46:06...Should be converted to new style pre/post-install
*(from redmine: issue id 16, created on 2009-03-24, closed on 2009-03-26)*
* Changesets:
* Revision bbd7886cd79ad2060c9199c768991035228905f7 by Carlo Landmeter on 2009-03-25T21:46:06Z:
```
extra/transmission: updated install file to new style.
fixes #16
```Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/33/var/log/lastlog missing2023-01-08T23:59:22ZLeonardo Arena/var/log/lastlog missingssh daemon starting up gives this error:
lastlog\_openseek: Couldn’t stat /var/log/lastlog:No such file or
directory
*(from redmine: issue id 33, created on 2009-05-18, closed on 2009-06-23)*
* Changesets:
* Revision abeb4645b5f35b...ssh daemon starting up gives this error:
lastlog\_openseek: Couldn’t stat /var/log/lastlog:No such file or
directory
*(from redmine: issue id 33, created on 2009-05-18, closed on 2009-06-23)*
* Changesets:
* Revision abeb4645b5f35bfe0876adebe89838e0b39bf471 on 2009-05-18T12:34:26Z:
```
core/openssh: disable lastlog
fixes #33
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/30Alpine_1.9alpha9 - Postfix should use '/usr/lib/postfix' instead of '/usr/lib...2023-01-08T23:59:21ZMika HavelaAlpine_1.9alpha9 - Postfix should use '/usr/lib/postfix' instead of '/usr/libexec/postfix'Reasons are:
- FHS
(http://www.pathname.com/fhs/pub/fhs-2.3.html\#USRLIBLIBRARIESFORPROGRAMMINGANDPA)
- Compability
*(from redmine: issue id 30, created on 2009-05-14, closed on 2009-05-14)*
* Changesets:
* Revision b846d7e...Reasons are:
- FHS
(http://www.pathname.com/fhs/pub/fhs-2.3.html\#USRLIBLIBRARIESFORPROGRAMMINGANDPA)
- Compability
*(from redmine: issue id 30, created on 2009-05-14, closed on 2009-05-14)*
* Changesets:
* Revision b846d7e6a255de4c6ad97c536e0093952abca2f1 on 2009-05-14T12:23:53Z:
```
extra/postfix: use /usr/lib/postfix instead of /usr/libexec/postfix
fixes #30
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/311.9alpha10 - Can not mount floppy2023-01-08T23:59:21ZMika Havela1.9alpha10 - Can not mount floppySeems floppy module is not loaded at boot
*(from redmine: issue id 31, created on 2009-05-16, closed on 2009-05-20)*Seems floppy module is not loaded at boot
*(from redmine: issue id 31, created on 2009-05-16, closed on 2009-05-20)*