alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-11-14T10:30:08Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14189community/gnome-control-center: Segfault during startup on aarch642022-11-14T10:30:08ZAirtowercommunity/gnome-control-center: Segfault during startup on aarch64As the title says, with GTK 4.8.0 gnome-control-center segfaults during startup on aarch64 (e.g. Pinephone). This issue is a summary of a collective effort on postmarketOS chat (@Arnavion, Piraty, Newbyte, and myself). Note that pmOS use...As the title says, with GTK 4.8.0 gnome-control-center segfaults during startup on aarch64 (e.g. Pinephone). This issue is a summary of a collective effort on postmarketOS chat (@Arnavion, Piraty, Newbyte, and myself). Note that pmOS used 4.6.6 before the 4.8.0 update. The crash _isn't_ reproducible on armv7, I don't know about other architectures.
The log during the crash doesn't say much, but hints at a NULL pointer:
```
(gnome-control-center:9814): GLib-GObject-WARNING **: 18:38:36.337: invalid class cast from (NULL) pointer to 'GObject'
Segmentation fault
```
Backtrace from GDB (with `gtk4.0-dbg` and `glib-dbg` installed):
```
#0 0x0000fffff75aa014 in gdk_texture_dispose (object=0xfffff163b800)
at ../gdk/gdktexture.c:287
#1 0x0000fffff7d2c710 in g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3636
#2 g_object_unref (_object=0xfffff163b800) at ../gobject/gobject.c:3553
#3 0x0000fffff7377e74 in gtk_icon_paintable_finalize (object=0xfffff176a160)
at ../gtk/gtkicontheme.c:3532
#4 0x0000fffff7d2c7d0 in g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3678
#5 g_object_unref (_object=0xfffff176a160) at ../gobject/gobject.c:3553
#6 0x0000fffff75053c8 in gtk_icon_helper_invalidate (self=0xfffff1ff5680)
at ../gtk/gtkiconhelper.c:338
#7 0x0000fffff73840e8 in gtk_image_system_setting_changed (
widget=0xfffff1f9dc50, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkimage.c:1184
#8 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#9 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#10 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#11 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#12 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#13 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#14 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#15 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#16 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#17 0x0000fffff74b8590 in gtk_widget_real_system_setting_changed (
widget=<optimized out>, setting=GTK_SYSTEM_SETTING_ICON_THEME)
at ../gtk/gtkwidget.c:4976
#18 0x0000fffff74be380 in gtk_system_setting_changed (display=0xfffff2bf40c0,
setting=GTK_SYSTEM_SETTING_ICON_THEME) at ../gtk/gtkwidget.c:10684
#19 0x0000fffff7377a20 in theme_changed_idle__mainthread_unlocked (
user_data=0xfffff208c760) at ../gtk/gtkicontheme.c:1318
#20 0x0000fffff7c350e8 in g_main_dispatch (context=0xfffff7995f10)
at ../glib/gmain.c:3417
#21 g_main_context_dispatch (context=0xfffff7995f10) at ../glib/gmain.c:4135
#22 0x0000fffff7c35348 in g_main_context_iterate (
context=context@entry=0xfffff7995f10, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4211
#23 0x0000fffff7c35430 in g_main_context_iteration (
context=context@entry=0xfffff7995f10, may_block=may_block@entry=1)
#24 0x0000fffff7e59d50 in g_application_run (application=0xfffff3235110,
argc=<optimized out>, argv=0xfffffffff7b8) at ../gio/gapplication.c:2569
#25 0x0000aaaaaaafe2ec in main ()
```
The icon being processed in `gtk_icon_paintable_finalize` varies, but it's always in there, presumably the first icon to be processed. I'll quote the chat for the rest to make sure I don't leave out anything important:
> <Arnavion> Weird, that line is G_OBJECT_CLASS (gdk_texture_parent_class)->dispose (object) where G_OBJECT_CLASS eventually expands to a call to g_type_check_class_cast(gdk_texture_parent_class), so given the bt that would indicate gdk_texture_parent_class is NULL, but gdb says it's a valid GObjectClass
>
> <Arnavion> Hah, adding a breakpoint on gdk_texture_dispose reveals that a) gdk_texture_parent_class is not NULL, and b) now g-c-c comes up
>
> <Arnavion> So there must be a race between threads for when gdk_texture_parent_class gets initialized
>
> <airtower> Okay, that's fascinating! :D
>
> <Arnavion> airtower, Piraty: Can you try it too? `break gdk_texture_dispose`, wait for it to get hit once, and then keep `c`ing it. It'll break six or seven times and then g-c-c should come up
>
> <Piraty> yep, there it is
>
> <airtower> Yep, works for me too.
>
> <Arnavion> I assume gdk_texture_parent_class gets defined by gobject macro magic because I can't find any other occurence of it, so I don't know how it's initialized...
>
> <Arnavion> airtower: Piraty: Unfortunately all my attempts to catch the situation where that global is NULL don't work. Any breakpoint that's complicated enough to only stop when that global is NULL or $x0 register is NULL introduces enough slowness that the race doesn't happenhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/58DT_RELR2023-04-11T14:46:54ZGhost UserDT_RELRmusl now has DT_RELR support in https://git.musl-libc.org/cgit/musl/commit/?id=d32dadd60efb9d3b255351a3b532f8e4c3dd0db1 (so it will be in the next release)
glibc added it in https://github.com/bminor/glibc/commit/e895cff59aa562cad83fa...musl now has DT_RELR support in https://git.musl-libc.org/cgit/musl/commit/?id=d32dadd60efb9d3b255351a3b532f8e4c3dd0db1 (so it will be in the next release)
glibc added it in https://github.com/bminor/glibc/commit/e895cff59aa562cad83fa0fdd187bfe4b45312d5 , in the 2.36 release
binutils supports setting this at link time (`-z pack-relative-relocs`) since 2.38. ld.lld added it in LLVM 15 (soon to be available). (prior to 15, it has it via `--pack-dyn-relocs=relr`)
there is a lot written about this new linker feature here: https://maskray.me/blog/2021-10-31-relative-relocations-and-relr . it has all the info you might want to know. (do read it!)
this issue is a proposal to enable this by default (via either LDFLAGS in abuild.conf or some form of binutils/lld default cmdline editing, former preferred). it would have to wait for the next musl release (or that patch can be backported, i have verified it works (if the support doesn't work, the binaries with RELR sections segfault instantly in the loader))
the main benefits are size. practically everything shrinks 5-8% in size with no gotcha. see the linked article for more details.
the main issue would be time travel compatibility. without backporting the musl patch to stable releases, or first waiting until things within reason all have the support (prior to toggling the linker flag), people using binaries from edge on stable would just have them segfault. we don't support this (mixing edge with stable), obviously, but practically everyone ends up doing it (much to my annoyance). so, i think it would be best to backport it one release (3.16) and then have it in 3.17 naturally and toggle it then for edge (after 3.17), or, alternatively, toggle it for edge before 3.17 if we backport the patches earlier. all the times can change depending on when musl makes a release , unless we backport it early
i have not tested if this feature is secretly broken outside of x86_64- maybe the other arches aren't ready for it.
overall, it's a free optimisation without much downside, that relies on relatively-new libc loading support. i don't see a reason to not enable it by default once musl supports it.
the time-travel issue needs more consideration- see some discussion in https://github.com/llvm/llvm-project/issues/53775 for instance. not sure if we can also implement a lockouthttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14166GTK 4 + Rust apps crash on ARMv72023-03-19T22:17:00ZNewbyteGTK 4 + Rust apps crash on ARMv7All GTK 4 + Rust apps that I've tested (Amberol, Karlender) crash on launch on ARMv7 with the following error:
```
fungus:~$ amberol
thread 'main' panicked at 'Failed to retrieve template child. Please check that it has been bound and h...All GTK 4 + Rust apps that I've tested (Amberol, Karlender) crash on launch on ARMv7 with the following error:
```
fungus:~$ amberol
thread 'main' panicked at 'Failed to retrieve template child. Please check that it has been bound and has a #[template_child] attribute.', /home/buildozer/aports/community/amberol/src/cargo/registry/src/github.com-1285ae84e5963aae/gtk4-0.4.8/src/subclass/widget.rs:1305:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted
```
```
fungus:~$ karlender
[2022-09-05 11:54:29 ERROR gtk_rust_app] Warning: Could not find messages for locale "", text domain: Err(TranslationNotFound("")), TEXT_DOMAIN: Err(NotPresent)
thread 'main' panicked at 'Failed to retrieve template child. Please check that it has been bound and has a #[template_child] attribute.', /home/buildozer/.cargo/registry/src/github.com-1285ae84e5963aae/gtk4-0.4.8/src/subclass/widget.rs:1305:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted
```
I've not reported this upstream yet as their template wants a minimal example that reproduces it and I've not got around to making one.3.18.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/14143Cannot use OTG-enabled devices (CONFIG_USB_OTG)2022-11-11T09:41:20ZDorin BombeaCannot use OTG-enabled devices (CONFIG_USB_OTG)Connecting a rather new Android Phone results in the following errors:
**dmesg | grep usb**
```
[ 1893.022166] usb 1-3: new high-speed USB device number 43 using xhci_hcd
[ 1893.166390] usb 1-3: Dual-Role OTG device on non-HNP port
[ 18...Connecting a rather new Android Phone results in the following errors:
**dmesg | grep usb**
```
[ 1893.022166] usb 1-3: new high-speed USB device number 43 using xhci_hcd
[ 1893.166390] usb 1-3: Dual-Role OTG device on non-HNP port
[ 1893.166668] usb 1-3: set a_alt_hnp_support failed: -32
[ 1893.289215] usb 1-3: new high-speed USB device number 44 using xhci_hcd
[ 1893.433040] usb 1-3: Dual-Role OTG device on non-HNP port
[ 1893.433408] usb 1-3: set a_alt_hnp_support failed: -32
[ 1893.433497] usb usb1-port3: attempt power cycle
[ 1894.249199] usb 1-3: new high-speed USB device number 45 using xhci_hcd
[ 1894.269763] usb 1-3: Dual-Role OTG device on non-HNP port
[ 1894.270200] usb 1-3: set a_alt_hnp_support failed: -32
[ 1894.392530] usb 1-3: new high-speed USB device number 46 using xhci_hcd
[ 1894.417276] usb 1-3: Dual-Role OTG device on non-HNP port
[ 1894.417783] usb 1-3: set a_alt_hnp_support failed: -32
[ 1894.417878] usb usb1-port3: unable to enumerate USB device
```
From what I read online this has to do with the kernel config option _CONFIG_USB_OTG=y_
I don't know if this is on purpose or not, if it is I'd like to know the reasoning behind it, at least for the x86_64 platform it seems to me that it wouldn't be a widely used option.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14098Libressl conflicting with openssl alpine Edge once again2022-08-14T16:59:29ZAmirul IslamLibressl conflicting with openssl alpine Edge once againHi there
On the latest alpine:edge docker image the package libressl and openssl are conflicting once again..
Here is my docker instructions:
Ps I didn't install openssl or libressl manually but maybe it tried to install from dependen...Hi there
On the latest alpine:edge docker image the package libressl and openssl are conflicting once again..
Here is my docker instructions:
Ps I didn't install openssl or libressl manually but maybe it tried to install from dependencies:
```
RUN echo "@testing http://dl-cdn.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories && \
echo "@community http://dl-cdn.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories && \
apk update && apk upgrade && \
apk add --upgrade --no-cache \
musl-dev qbittorrent python3-dev busybox \
qbittorrent-nox py3-pip py3-lxml aria2 p7zip xz curl pv jq ffmpeg \
musl-locales neofetch git make g++ gcc automake zip unzip autoconf \
libtool curl-dev libsodium-dev crypto++ crypto++-dev \
c-ares-dev sqlite-dev freeimage-dev swig boost-dev \
libpthread-stubs zlib-dev libpq-dev libffi-dev py3-virtualenv libffi \
bash alpine-sdk clang clang-dev dpkg cmake ccache
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/14088Fails to build rust crates on CI build-riscv64-emulated due to SSL CA error2023-02-20T20:17:47ZJakub JirutkaFails to build rust crates on CI build-riscv64-emulated due to SSL CA errorExample: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/796564
```
Updating crates.io index
Downloading crates ...
error: failed to download from `https://crates.io/api/v1/crates/serde_json/1.0.83/download`
Caused by:
[77] P...Example: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/796564
```
Updating crates.io index
Downloading crates ...
error: failed to download from `https://crates.io/api/v1/crates/serde_json/1.0.83/download`
Caused by:
[77] Problem with the SSL CA cert (path? access rights?) (error setting certificate file: /etc/ssl/certs/ca-certificates.crt)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/14085main/doas: create the /etc/doas.conf symlink regardless of migration2023-05-16T12:36:47ZPatrycja Rosaalpine@ptrcnull.memain/doas: create the /etc/doas.conf symlink regardless of migrationcurrently, alpine uses an entirely different behaviour than any other distros (at least until the [upstream merge request][1] gets merged **and** distributions switch to using the same directory alpine picked)
if a user picks a guide th...currently, alpine uses an entirely different behaviour than any other distros (at least until the [upstream merge request][1] gets merged **and** distributions switch to using the same directory alpine picked)
if a user picks a guide that says "edit `/etc/doas.conf`" or reads the manpages (`doas(1)`, `doas.conf(5)`), they will end up editing a file that doesn't actually affect the behaviour.
to solve this, either a symlink from `/etc/doas.conf` to `/etc/doas.d/doas.conf` would have to be added regardless whether the file existed previously or `/etc/doas.d/doas.conf` exists, or the behaviour would have to be changed to treat `/etc/doas.conf` as another file that's read alongside `/etc/doas.d/*.conf` and treated as equal
[1]: https://github.com/Duncaen/OpenDoas/pull/71Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10074dependency conflict coreutils 9.0 and ucspi-tcp6 1.0.52022-09-13T00:11:02ZTherminoel.kuntze@thermi.consultingdependency conflict coreutils 9.0 and ucspi-tcp6 1.0.5```
apk add coreutils -l
ERROR: unable to select packages:
coreutils-9.0-r2:
conflicts: ucspi-tcp6-1.05-r0[cmd:date=9.0-r2] ucspi-tcp6-1.05-r0[cmd:who=9.0-r2]
satisfies: world[coreutils]
ucspi-tcp6-1.05-r0:
conflicts: cor...```
apk add coreutils -l
ERROR: unable to select packages:
coreutils-9.0-r2:
conflicts: ucspi-tcp6-1.05-r0[cmd:date=9.0-r2] ucspi-tcp6-1.05-r0[cmd:who=9.0-r2]
satisfies: world[coreutils]
ucspi-tcp6-1.05-r0:
conflicts: coreutils-9.0-r2[cmd:date] coreutils-9.0-r2[cmd:who]
satisfies: world[ucspi-tcp6]
```
Root cause is this:
```
/ # apk --no-network info -e -a coreutils | grep who
cmd:who
cmd:whoami
usr/bin/who
usr/bin/whoami
/ # apk --no-network info -a coreutils | grep who
cmd:who
cmd:whoami
usr/bin/who
usr/bin/whoami
cmd:who=9.0-r2
cmd:whoami=9.0-r2
/ # apk --no-network info -a ucspi-tcp6 | grep who
cmd:who
usr/bin/who@
cmd:who=1.05-r0
```
The `provides` part of the package for ucspi-tcp6 contains the one for `who`, although it packages `who@`.
The problem occurs because coreutils 9.0 package "who" in a specific version now.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14063Transition to php812022-10-31T17:10:12ZAndy PostnikovTransition to php81PHP [8.2.0](https://wiki.php.net/todo/php82) is coming on November 23 2022 and 8.0 going out of [active support](https://www.php.net/supported-versions.php) in a month but the same time release of 3.17 planed
Moreover starting from PHP...PHP [8.2.0](https://wiki.php.net/todo/php82) is coming on November 23 2022 and 8.0 going out of [active support](https://www.php.net/supported-versions.php) in a month but the same time release of 3.17 planed
Moreover starting from PHP 8.1 has official support of OpenSSL 3 https://www.php.net/manual/en/openssl.requirements.php
Transition require to upgrade all packages to use `php81` as dependency
- [x] switch default_php to 81
- [x] update all dependent packages to use 8.1
- [x] fix the list of failing ones that still does not work with 8.1
Broken ones
- `community/bareos` not clear #14262
- ~~`community/baculum` https://www.bacula.org/bacula-release-13-0-0/ still depends on 8.0 !40019~~
- ~~`community/nextcloud23` - will be phased out !40163~~
- ~~`community/drupal7` - next year phased out https://www.drupal.org/project/drupal/issues/3224299~~
- ~~`community/phpldapadmin` will be done one day https://github.com/leenooks/phpLDAPadmin/issues/150~~3.17.0https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10073versioned cmd: providers make it impossible to use provider_priority2022-08-07T19:30:21ZGhost Userversioned cmd: providers make it impossible to use provider_prioritycurrently, the default cmd: providers have a version appended. so, for instance, both mandoc and man-db provide:
```
sumire < apk info -P mandoc
mandoc-1.14.6-r4 provides:
cmd:man=1.14.6-r4
sumire < apk info -P man-db
man-db-2.10.2-r...currently, the default cmd: providers have a version appended. so, for instance, both mandoc and man-db provide:
```
sumire < apk info -P mandoc
mandoc-1.14.6-r4 provides:
cmd:man=1.14.6-r4
sumire < apk info -P man-db
man-db-2.10.2-r1 provides:
cmd:man=2.10.2-r1
```
this then means that adding a provider_priority to each is worthless- if something depends on `cmd:man`, they will always pull in man-db, because it has a bigger version, and the priority is ignored entirely, because the priority is only used for things without a version.
this goes for a lot of uses of provider_priority= , as it's only useful if you make your own provides="randomstuffhere" virtual, as otherwise the embedded versions will make it failhttps://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/137Official Alpine image for Google Compute Engine ( GCE )2023-10-18T01:12:37ZAnit SharmaOfficial Alpine image for Google Compute Engine ( GCE )Looking into a request to run Alpine OS on GCE.
So far have not seen any resource to deploy the same, hence raising this issue to check if this is a part of current roadmap or has a beta version / tentative release date.Looking into a request to run Alpine OS on GCE.
So far have not seen any resource to deploy the same, hence raising this issue to check if this is a part of current roadmap or has a beta version / tentative release date.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14049community/linux-edge: zswap is not enabled on x86_642022-08-24T19:30:31ZGhost Usercommunity/linux-edge: zswap is not enabled on x86_64funnily, it is enabled on riscv64/aarch64:
```
CONFIG_ZSWAP=y
```
for reference, zswap is zram with a backing swap devicefunnily, it is enabled on riscv64/aarch64:
```
CONFIG_ZSWAP=y
```
for reference, zswap is zram with a backing swap deviceMilan P. StanićMilan P. Stanićhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10070checkapk soname diff does not work with busybox2023-06-26T01:27:26ZGhost Usercheckapk soname diff does not work with busyboxthe check is currently:
```sh
diff "../filelist-$_pkgname-old" "../filelist-$_pkgname" | awk '/>.*\.so/{$1 = ""; print $0}' | while read i; do
echo "${i}: " "$(objdump -p "$i" | grep SONAME)"
done
```
this assumes the diff starts wi...the check is currently:
```sh
diff "../filelist-$_pkgname-old" "../filelist-$_pkgname" | awk '/>.*\.so/{$1 = ""; print $0}' | while read i; do
echo "${i}: " "$(objdump -p "$i" | grep SONAME)"
done
```
this assumes the diff starts with '>', which is not supported in busybox diff, as it supports unified diffs only.
to work with both, diff -U3 should be used, and the awk should be amendedhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14035setup-alpine: disabling setup-user in ANSWERFILE2022-11-08T16:33:18Zmacmpisetup-alpine: disabling setup-user in ANSWERFILEWith new `setup-user` and related `USEROPTS` in `ANSWERFILE`, it is not possible properly disable user account creation in setup-`alpine -f ANSWERFILE`.\
Indeed `USEROPTS=none` creates user none !...
`USEROPTS=-h` can serve as a workaro...With new `setup-user` and related `USEROPTS` in `ANSWERFILE`, it is not possible properly disable user account creation in setup-`alpine -f ANSWERFILE`.\
Indeed `USEROPTS=none` creates user none !...
`USEROPTS=-h` can serve as a workaround but some proper option would be nice.
Overall, a more consistent `OPTS` mechanism would be nice to disable features (sometimes unset variables, sometimes `none`, etc..).
i.e: `setup-interface` also needs to be touched: no option to just keep as-is
How about having a common option (`-i`, `-I`, or else) for each setup-* (or their calling steps within `setup-alpine`) to ignore?https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10761Sign into MediaWiki using GitLab OAuth22022-07-23T01:36:19ZPatrycja Rosaalpine@ptrcnull.meSign into MediaWiki using GitLab OAuth2there seems to be an extension for this already: https://www.mediawiki.org/wiki/Extension:OAuth2_Clientthere seems to be an extension for this already: https://www.mediawiki.org/wiki/Extension:OAuth2_Clienthttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14001Package nextcloud-serverinfo dependency issues2022-07-11T13:02:04ZblueskyPackage nextcloud-serverinfo dependency issuesI run into two problems - missing dependency package and disabled php function. This is on Alpine 3.16 running Nextcloud 24 installed using **php-fpm** as documented on [link](https://wiki.alpinelinux.org/wiki/Nextcloud) - serverinfo re...I run into two problems - missing dependency package and disabled php function. This is on Alpine 3.16 running Nextcloud 24 installed using **php-fpm** as documented on [link](https://wiki.alpinelinux.org/wiki/Nextcloud) - serverinfo requires **files_sharing** package and should have a dependency for it.
The second problem is that /etc/php8/php-fpm.d/nextcloud.conf by default disables **shell_exec()** php build-in function, required by serverinfo - hope Google indexes this page and saves time for the next person trying to solve this problem.Leonardo ArenaLeonardo Arenahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13991HPE Gen9 530FLR-SFP+ bnx2x firmware failure netboot2023-11-28T16:02:17ZMarcHPE Gen9 530FLR-SFP+ bnx2x firmware failure netbootWe have problems with the netboot version of alpine not reconizing the 530FLR-SFP+ network cards. These cards need the bnx2x firmware/driver.
In the PXE boot line we added `modules=bnx2x` but it still fails to reconize the networkcard.
S...We have problems with the netboot version of alpine not reconizing the 530FLR-SFP+ network cards. These cards need the bnx2x firmware/driver.
In the PXE boot line we added `modules=bnx2x` but it still fails to reconize the networkcard.
So we modified the init file in a bit so we could get into singlemode (shell) before the configure_ip stuff.
Uppon testing, modprobe is unable to load the bnx2x firmware with error:
```shell
modprobe: ERROR: could not insert 'bnx2x': Unknown symbol in module, or unknown parameter (see dmesg)
```
note, dmesg is empty no errors.
Also tried the newer kernel (5.15.52-0-lts, building our own initramfs) but no luck.
Any good ideas?
Update:
```
/ # modprobe -v bnx2x
insmod /lib/modules/5.15.41-0-lts/kernel/lib/libcrc32c.ko
modprobe: ERROR: could not insert 'bnx2x': Unknown symbol in module, or unknown parameter (see dmesg)
```
Update:
Verified not working on edge, 3.16, 3.14, 3.10https://gitlab.alpinelinux.org/alpine/aports/-/issues/13981Raspberry Pi 4: depmod: WARNING: could not open modules.builtin.modinfo2022-07-08T11:49:13ZOleg TitovRaspberry Pi 4: depmod: WARNING: could not open modules.builtin.modinfoRunning `apk upgrade` produces following warning:
```
rpi4b:~# apk upgrade
fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
fet...Running `apk upgrade` produces following warning:
```
rpi4b:~# apk upgrade
fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/aarch64/APKINDEX.tar.gz
(1/1) Upgrading linux-rpi4 (5.15.51-r0 -> 5.15.52-r0)
Executing busybox-1.35.0-r17.trigger
Executing kmod-30-r0.trigger
Executing mkinitfs-3.6.1-r3.trigger
==> initramfs: creating /boot/initramfs-rpi4
depmod: WARNING: could not open modules.builtin.modinfo at /tmp/mkinitfs.MakEee/lib/modules/5.15.52-0-rpi4: No such file or directory
OK: 107 MiB in 82 packages
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10852dependency conflict coreutils 9.0 and ucspi-tcp6 1.0.52022-08-05T12:49:24ZTherminoel.kuntze@thermi.consultingdependency conflict coreutils 9.0 and ucspi-tcp6 1.0.5```
apk add coreutils -l
ERROR: unable to select packages:
coreutils-9.0-r2:
conflicts: ucspi-tcp6-1.05-r0[cmd:date=9.0-r2] ucspi-tcp6-1.05-r0[cmd:who=9.0-r2]
satisfies: world[coreutils]
ucspi-tcp6-1.05-r0:
conflicts: cor...```
apk add coreutils -l
ERROR: unable to select packages:
coreutils-9.0-r2:
conflicts: ucspi-tcp6-1.05-r0[cmd:date=9.0-r2] ucspi-tcp6-1.05-r0[cmd:who=9.0-r2]
satisfies: world[coreutils]
ucspi-tcp6-1.05-r0:
conflicts: coreutils-9.0-r2[cmd:date] coreutils-9.0-r2[cmd:who]
satisfies: world[ucspi-tcp6]
```
Root cause is this:
```
/ # apk --no-network info -e -a coreutils | grep who
cmd:who
cmd:whoami
usr/bin/who
usr/bin/whoami
/ # apk --no-network info -a coreutils | grep who
cmd:who
cmd:whoami
usr/bin/who
usr/bin/whoami
cmd:who=9.0-r2
cmd:whoami=9.0-r2
/ # apk --no-network info -a ucspi-tcp6 | grep who
cmd:who
usr/bin/who@
cmd:who=1.05-r0
```
The `provides` part of the package for ucspi-tcp6 contains the one for `who`, although it packages `who@`.
The problem occurs because coreutils 9.0 package "who" in a specific version now.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13960remove edge4virt flavor from linux-edge2022-09-24T06:44:02ZMilan P. Stanićremove edge4virt flavor from linux-edgeAFAIK no one use linux-edge4virt flavor of kernel so I think it should be removedAFAIK no one use linux-edge4virt flavor of kernel so I think it should be removedMilan P. StanićMilan P. Stanić