Posts by chewitt

LE runs the current/latest connman release. I'd guess the reason IPv6 support upstream is much the same as ours .. until developers are forced to use IPv6 connections it remains largely uncharted territory. If you ping "wagi" in the #connman IRC channel on freenode he'll be happy to take constructive feedback on what's missing. He's familiar with LE .. we've collaborated on a number of things in recent years.

Correct. Kodi v19 release has been reshaped into an interim release to force/kick-start the Python3 transition and bigger-ticket items like HDR and GBM/V4L2 support will shift to Kodi v20 .. hopefully on something close to the original v19 schedule (not that Kodi ever does formal scheduling).

Amlogic's "Meson 8" platform (S802/805/812) shares a lot of IP with the GXBB (first generation S905) hardware so support in the mainline kernel is in reasonable shape (bootable and usable) apart from a lack of an HDMI driver which is fundamental for mediacentre use. One of the kernel maintainers Martin Blumenstingl continues to poke away at the Meson 8 codebase and (coincidentally) in the last week he got CVBS output working. As long as he continues his efforts I'm confident there will eventually be a Eureka! moment with HDMI that allows us to consider adding back support (and even if we don't do something official - for community images to exist) but until that happens LE 9.0 is the end of the line for those devices. Meson 6 (8726MX) support in the mainline kernel is almost non-existent and those devices are considered obsolete.

Panfrost does not currently support the Mali G31/52 (Bifrost) chips used in G12A/G12B/SM1 hardware and I don't see that changing for a while yet. It's not an issue though as we have all the required blobs and can use those; hence we are shipping two images (AMLGX with lima/panfrost and AMLG12 with blobs) which are working on a range of newer hardware. There are no plans to drop support for S905 and up devices but it is a large task and developers have proper jobs and families so progress comes as it comes; we're not forcing the schedule. We will push a master branch bump to Linux 5.4.x soon; although there are ongoing changes to the video decoding drivers that need corresponding changes to Kodi/ffmpeg so our master branch will not be as usable as Linux 5.2/5.3 was for a while.

You probably need to speak to Eminent. We have nothing to do with the "LibreELEC" images for those devices.

add "ssh" to boot params and the service is forced to start on boot

You can do a hard reset from the LE settings add-on.

In the last 24h panfrost scored it's first "all green" graphics test run on the T820 chip used in the S912 and there are now some Khadas VIM2 boards plumbed into the mesa CI lab to ensure continuous testing of future changes. We are also in the process of switching our Allwinner and Rockchip images over to panfrost. We also found a source for the Linux T820 blobs (albeit not a redistributable one) but with panfrost in a good state I'm no longer chasing the permission to release the files. I'm sure panfrost still has some bugs, but simply being able to real-time chat with developers who are friendly and keen to solve problems is .. the total opposite of using blobs. It's a one-way journey

We dropped the nvidia 304.xx driver required for prehistoric cards around LE 8.0.x but there is a community image kicking around in the forums for 8.2.5. It's no longer possible to build images with that old driver due to ABI changes in Xorg so 8.2.x would the final of final images. An RPi4 would be a massive upgrade

There is no music or commentary on the YouTube videos - the idea is (was) that you looked at the videos. However it would be better to clean install LE instead of trying to migrate an OE install now.

passphrase = password .. although <space> is a valid character so you can have multiple words; hence "pass phrase" is a more accurate description of what's involved. It's also hard to guess what the problem is from your description. You will need to be more specific about what "logging on to my network" means (where in the GUI, etc.)

Anything under /etc is not writeable in LE (as it's part of a read-only squashfs file) but you don't need to touch wpa_supplicant anyway as this is driven by connman which has an easy to use console configuration tool (connmanctl) which writes the service/settings files. Manual configuration to those files will fail unless connman is stopped as connman will overwrite them at any time.

connmanctl
agent on
scan wifi
services
connect wpa_your_network_psk
<enter password>

^ if you insist on configuring from the console that sequence of commands will work. connmanctl is also scriptable but configuration from the GUI is also available. I can't explain why you saw an error, but the GUI is the normal and recommneded way to configure network things.

I'd guesstimate that 0.00001% of our userbase uses a UPS so it's not exactly a big requirement.

If it works, don't fix it. If it stops working .. switch to SMB

Quote from Anard

I have a SFTP server (SSH access) which is for me the easiest way to configure it as it's simple to configure for macOS or Linux

I'm not sure which end you think is simple .. because from here is sounds like you made the whole thing wildly complicated. SMB is perfectly fine for domestic media use. SMB sources take ~30 seconds to setup.

No wiki, only kernel sources. If/when at some future point it makes sense the Pi Foundation will switch over .. but I wouldn't expect that to be a high priority for them. Making perfect software is somewhere on the list, but helping kids learn stuff comes first, and the current assorment of 32-bit code does that job just fine.

auto-update has been enabled for 9.2.0 images - only applies to 9.1.x alpha/beta images

Try adding the IP address for "medias" to /storage/.config/hosts.conf .. because it only has medias-server.