Posts by mglae

I'm afraid the used chrome command line options are outdated.

You can start with removing--use-gl=desktop . Forcing LIBVA_DRIVER_NAME='i965' can be an issue too.

Output of systemd units are logged to journal by default and only copied to console.

See StandardOutput= entry of systemd.exec

Quote from bumrufus

i hope someone finds a solution for not updating the repos

Increase Wait for network before starting Kodi in LE-Settings addon from the initial short 10 seconds to fit your needs. The repos are initially updated at startup (and periodically later).

I recommend the max time you are willing to wait when no network is available.

autostart.sh is depending on network-online.target but you have to adjust Wait for network before starting Kodi in LE-Settins addon from the initial short 10 seconds to your needs.

Log messages of autostart.sh can be viewed with journalctl -u kodi-autostart. The status of "Wait for network" is visible with systemctl status kodi-waitonnetwork

Addons are updated independent from releases. Expect it any time after PR commit.

I've created a LE12 fix for this.

Note: you have to revert any script.xbmc.boblight changes after the update is installed.

Err, this does not match your test procedure. Better modify the source if debug is needed.

Quote from ehoitinga

I use the "run" option. Every image build is written freshly to the USB stick. I don't use SFTP/update

Then you also start every build with a fresh BT configuration, the test should be good.

A log comparison between working and not working state may result in additional information.

bluetoothd can be forced to debug mode with (but I don't know how noisy it is):

[Service]
Environment=BLUEZ_DEBUG=--debug

Usually re-pairing is not required. Latest connection is stored in the keyboard and in LE below /storage/.config/bluetooth/. Do you boot "live" or "run"?

Quote from ehoitinga

And what about adding the --enable-hid2hci option

Was not included inLE10 and LE11, so likely not required. But just do the simple test and the question is finally answered.

You do need reliable test procedures for a successful bisect process. Here the test is to connect the keyboard to the test system, nothing is required on the build system.

If the keyboard is detected you do have a "good" case, no questions. But without detection: is this caused by the code error ("bad") or only a temporary fault?

From your experience with working code (even in LE11, LE10 ...): how reliable is the keyboard detected?

Maybe you need more boot tries if you see "bad". This is only a suggestion. Your experience is required to optimize the bisect test procedure.

gobex: const annotate RO arrays, use G_N_ELEMENTS: I'm having some doubts that a change to an obex lib is causing your keyboard error.

There may be false negatives (e.g. detection of the BT keyboard is delayed) interrupting the bisect process.

With using the USB stick you can even avoid the reboot when updating by replacing both KERNEL and SYSTEM with the new generated *.kernel and *.system files.

Just merged #8825.

Add . /etc/profile to include System Tools Addon path.

Change download source:

diff --git a/packages/devel/commons-text/package.mk b/packages/devel/commons-text/package.mk
index c0277ca900..654ba2112a 100644
--- a/packages/devel/commons-text/package.mk
+++ b/packages/devel/commons-text/package.mk
@@ -6,7 +6,7 @@ PKG_VERSION="1.11.0"
 PKG_SHA256="4169cb90571fb28fad4c5eea7c1c994c18f1995452f73e8ea7a86087c0e3822e"
 PKG_LICENSE="Apache-2.0"
 PKG_SITE="https://commons.apache.org/proper/commons-text/"
-PKG_URL="https://dlcdn.apache.org/commons/text/binaries/commons-text-${PKG_VERSION}-bin.tar.gz"
+PKG_URL="https://archive.apache.org/dist/commons/text/binaries/commons-text-${PKG_VERSION}-bin.tar.gz"
 PKG_DEPENDS_TARGET="toolchain"
 PKG_LONGDESC="Apache Commons Text is a library focused on algorithms working on strings"
 PKG_TOOLCHAIN="manual"

Development is always done on master. But don't use branch name master yourself.

Create your own working branch with e.g. checkout -b my_first_working_brach master. If you like to test something else, commit you local changes and create a new branch.

master is only used to follow the official GitHub branch. With special requirements it is of course possible to create your working branch from an older commit.

There is no difference in installer, boot loader and kernel between Generic and Generic-Legacy.

With using 512 byte sector size the syslinux legacy boot loader was now successfully installed and can be used for Legacy Boot.

Regarding UEFI boot: likely your system firmware require an explicit entry for the default EFI loader at "\EFI\BOOT\bootx64.efi". LE rely on having the loader executed by default. See this howto for creating the entry. It may be easier to use a live linux system with efibootmgr.

Better use -L "LibreELEC" on your system, "Windows Boot Manager" may already be used and is required only on the M72e as work around.

If using 11.0.6 the Chrome .deb file was removed.