iwd and connman are synced up to that of LE13.
Correct there is no b43 in LE12/13. I don’t see the wl driver returning in LE with “patches”, the decision to drop it was only made after the inability to obtain working patches across multiple kernel releases, and lack of support (community) - lots of reading and research done in the PR and issue, with references to the issue.
The wireless positive with LE12.2/13 is the now available upstreamed rtw88 wireless.
Posts by heitbaum
-
-
Here is the background. https://github.com/LibreELEC/LibreELEC.tv/pull/9522. there was some work being done in other patches that may have worked in later kernels, but didn’t work in the LE kernels, so it was dropped.
-
For the Inter DG1, is the following change still necessary?
/flash/syslinux.cfg
It will default to i915 or XE depending on the how the drivers/pciids have been updated by Intel. To swap to the “other driver” will require the force_probe.
-
-
Some change in arguments that I can see. Taking a further look. The addon interface in LE Kodi looks right with a default of 0.0.0.0:8384
Code
Display MoreAug 14 22:13:51 nuc12 systemctl[2790811]: Failed to stop service.system.syncthing.service: Unit service.system.syncthing.service not loaded. Aug 14 22:13:51 nuc12 systemctl[2790813]: Failed to disable unit: Unit service.system.syncthing.service does not exist Aug 14 22:13:51 nuc12 systemctl[2790814]: Created symlink '/storage/.config/system.d/service.system.syncthing.service' → '/storage/.kodi/addons/service.system.syncthing/system.d/service.system.syncthing.service'. Aug 14 22:13:51 nuc12 systemctl[2790814]: Created symlink '/storage/.config/system.d/kodi.target.wants/service.system.syncthing.service' → '/storage/.kodi/addons/service.system.syncthing/system.d/service.system.syncthing.service'. Aug 14 22:13:52 nuc12 systemd[1]: Starting service.system.syncthing.service... Aug 14 22:13:52 nuc12 systemd[1]: Started service.system.syncthing.service. Aug 14 22:13:52 nuc12 sh[2790904]: syncthing: error: unknown flag -o, did you mean one of "-h", "-C", "-D", "-H"? Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Main process exited, code=exited, status=80/n/a Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Failed with result 'exit-code'. Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Scheduled restart job, restart counter is at 1. Aug 14 22:13:52 nuc12 systemd[1]: Starting service.system.syncthing.service... Aug 14 22:13:52 nuc12 systemd[1]: Started service.system.syncthing.service. Aug 14 22:13:52 nuc12 sh[2790978]: syncthing: error: unknown flag -o, did you mean one of "-h", "-C", "-D", "-H"? Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Main process exited, code=exited, status=80/n/a Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Failed with result 'exit-code'. Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Scheduled restart job, restart counter is at 2. Aug 14 22:13:52 nuc12 systemd[1]: Starting service.system.syncthing.service... Aug 14 22:13:52 nuc12 systemd[1]: Started service.system.syncthing.service. Aug 14 22:13:52 nuc12 sh[2791028]: syncthing: error: unknown flag -o, did you mean one of "-h", "-C", "-D", "-H"? Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Main process exited, code=exited, status=80/n/a Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Failed with result 'exit-code'. Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Scheduled restart job, restart counter is at 3. Aug 14 22:13:52 nuc12 systemd[1]: Starting service.system.syncthing.service... Aug 14 22:13:52 nuc12 systemd[1]: Started service.system.syncthing.service. Aug 14 22:13:52 nuc12 sh[2791077]: syncthing: error: unknown flag -o, did you mean one of "-h", "-C", "-D", "-H"? Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Main process exited, code=exited, status=80/n/a Aug 14 22:13:52 nuc12 systemd[1]: service.system.syncthing.service: Failed with result 'exit-code'. Aug 14 22:13:53 nuc12 systemd[1]: service.system.syncthing.service: Scheduled restart job, restart counter is at 4. Aug 14 22:13:53 nuc12 systemd[1]: Starting service.system.syncthing.service... Aug 14 22:13:53 nuc12 systemd[1]: Started service.system.syncthing.service. Aug 14 22:13:53 nuc12 sh[2791127]: syncthing: error: unknown flag -o, did you mean one of "-h", "-C", "-D", "-H"? Aug 14 22:13:53 nuc12 systemd[1]: service.system.syncthing.service: Main process exited, code=exited, status=80/n/a Aug 14 22:13:53 nuc12 systemd[1]: service.system.syncthing.service: Failed with result 'exit-code'. Aug 14 22:13:53 nuc12 systemd[1]: service.system.syncthing.service: Scheduled restart job, restart counter is at 5. Aug 14 22:13:53 nuc12 systemd[1]: service.system.syncthing.service: Start request repeated too quickly. Aug 14 22:13:53 nuc12 systemd[1]: service.system.syncthing.service: Failed with result 'exit-code'. Aug 14 22:13:53 nuc12 systemd[1]: Failed to start service.system.syncthing.service. -
It is only available in the build system. Binaries are downloadable from https://github.com/NixOS/patchelf/releases but I have never tested them, we always build it from source.
-
12.2 has the “latest”. There is a further libheif update that will go into master and 12.2 over the next few days. Not sure if this addresses the issue.
-
12.2 has the latest
-
Any plans to upgrade Docker to 28.3.x in LE12?
Regards!There are dependency issues - so not planned.
-
I have raised a PR. It needed some patching of upstream due to cross compiling and path limit issues. It runs, but I have not testing the TTS. https://github.com/LibreELEC/LibreELEC.tv/pull/10136
-
What does your ldd of your binary show?
You can use patchelf to update your binary to use the same by doing patchelf --add-rpath '${ORIGIN}/../lib.private' ${ADDON_BUILD}/${PKG_ADDON_ID}/bin/* depending on where you locate your binary. If it is in the backup directory as you have shown. Then patchelf --add-rpath '/storage/.kodi/addons/virtual.system-tools/lib.private' backup/pcloud if you put your pcloud binary in /storage/.kodi/addons/virtual.system-tools/bin the '${ORIGIN}/../lib.private' would be correct.
-
-
It can be added. But wouldnt expect it to give a different result to current nightly) as it addresses gcc-15 compile and legacy cflags (for kernel 6.24+)
-
I can’t see anything in the log either. Suggest checking in on the Kodi forum for the “missing” file / folders now that we have ruled out curl itself (that doesn’t mean it still might not be curl - but it will be the api of curl)
-
I would suggest testing if curl or Kodi/curl api is the issue. Kodi Piers (LE13) is in development presently with curl 8.13.0. If there is an issue it would be the right time to get it fixed at the source.
From LE - something like -curl -k --user myusername:mypassword ftps://ftpserver.mine
and check that it is showing you the files you expect, they are accessible ….
- and why / what are the missing files?
What is the common pattern? E.g. Is it path length…. Is it special characters?
if a curl issue, then needs to be raised with the curl team (they release approximately every 2 months)If a Kodi issue then will need to be raised on the Kodi forum with a reproducible case.
but first best share debug logs will be required to analyze further with the current LE13 nightlies.
Also the results of the “locally executed curl”
-
There was no Omega/Piers branches. So just needed to do a manual update. PRs created
-
Display More
I'm trying to add a custom package to a debug build of LibreELEC.
My (WiP) packages/debug/heaptrack/package.mk:Code: packages/debug/heaptrack/package.mk
Display MorePKG_NAME="heaptrack" PKG_VERSION="1.5" #PKG_REV="0" PKG_SHA256="2f87cd1b7da7ef387ba042719119caec4abafa71313e956c19e214e7983d9090" PKG_LICENSE="GPL2" PKG_SITE="https://apps.kde.org/heaptrack/" # https://invent.kde.org/sdk/heaptrack/-/archive/1.5/heaptrack-1.5.tar.bz2 PGK_URL="https://invent.kde.org/sdk/${PKG_NAME}/-/archive/${PKG_VERSION}/${PKG_NAME}-${PKG_VERSION}.tar.bz2" #PKG_DEPENDS_HOST="toolchain:host" PKG_DEPENDS_TARGET="toolchain binutils boost elfutils libunwind zlib zstd" PKG_SHORTDESC="a heap memory profiler" PKG_LONGDESC="Heaptrack traces all memory allocations and annotates these events with stack traces."(And I added it to packages/virtual/debug with a new HEAPTRACK switch.)
When the build gets to this package, it will try to detect the required toolchain (which should be cmake / cmake-make); but the build.LibreELEC-Generic.x86_64-13.0-devel/build/heaptrack-1.5/ directory is empty save for two stamp files.
There is no trace of the heaptrack-1.5.tar.bz2 source file in sources/ (or anywhere), nor any indication in any log that I can find where it would be downloaded.
I've verified the PKG_URL by running scripts/build edited to #!/bin/bash -x and it resolves as expected, and manually wget'ing that URL yields an archive with the source files.
What am I missing / what could be going wrong here?Typo? PGK_URL
-
Here is the changelog. So could be kernel 6.6.63 to 6.6.66. Nothing else stands out.
Comparing f894320...32f8832 · LibreELEC/LibreELEC.tvJust enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.github.com
