LibreELEC-RR [ Brave | Spotify | Moonlight | Emulationstation | Retroarch | Pegasus ]

    Quote from SupervisedThinking

    Ramalama

    I'm building RPi4 images at the moment but it'll take some time... tomorrow they should be ready.

    The gtk3-system package should be fine, I've renamed the host gdk-pixbuf command and it still worked so fingers crossed. Of course I would appreciate if the image can be compiled on a minimum build system.

    Have a look at the new modprobe.d conf files for xpad then, it would be nice if you could delete your old ones and the new ones shipped by the image, just delete them, apply an update and they will be restored.

    Just did, and i don't understand it.

    Code
    #################################################################################
# Bind dongle to non-existent module to prevent the mt76x2u driver from loading #
# https://github.com/medusalix/xow/blob/master/install/modprobe.conf            #
#################################################################################
#alias usb:v045Ep02E6d*dc*dsc*dp*ic*isc*ip*in* xow_blacklist
#alias usb:v045Ep02FEd*dc*dsc*dp*ic*isc*ip*in* xow_blacklist

    My modprobe file is gone/deleted, yours is there...

    But the 2 lines are commented out...

    But my controller still works and did worked after boot instantly perfect... =O

    dmesg and the service doesn't report any errors...

    It definitively didn't worked before without the modprobe file...

    Is there some sort like initramfs, where it still uses the "cached" modprobe file?

    EDIT:

    Okay, i think i understand why.

    Just replugged the dongle, while the system is running, and:

    usbfs: interface 0 claimed by mt76x2u while 'xow' sets config

    So it works now only at boot time, if the dongle is already plugged in with boot.

    Seems like the xow service binds the dongle at boot, before "mt76x2u"

    But if you replug/or plugin the dongle after the system is booted, you need the modprobe file xD

    So those 2 lines should be uncommented :D

    Edited 2 times, last by Ramalama: Merged a post created by Ramalama into this post. (April 16, 2021 at 7:12 PM).

    Ramalama

    Yeah well it looks like it always depends on the actual usecase. I'm shipping all files needed but the user need to check & enable the service by themselves since I can't make sure that it won't interfere with any other configuration. But uncommenting some lines or setting individual configs in template files should be hassle-free.

    Pull in the latest changes & test again, xow now should start after kodi is started. As I said I have to find the ideal [Unit] to start it ^^

    will tell you after i recompiled it 😂

    about xow and the modprobe, it probably just needs a hint in the wiki, that's all.

    no one needs to complain, cause it's the only libreelec/"xdistro"kodi that has working xow/xpadneo at all 😂

    About gtk3-system:

    I checked out till here:

    Code
    compiler@le-compiler:~/LibreelecRR$ git log --pretty=oneline
6ce98bc242bf9f7934d06e38cb8b778f07198fae (HEAD -> master-rr, origin/master-rr) xow: tweaks
0e65bca8cf47fb4d37b3bc35cd874ed1fc47391f brave-browser: updated to 1.0.3 / added function to set refresh rate

    and i still get the same error xD

    Sorry xD

    EDIT:

    Wait the error is different this time, it complains about libgdk_pixbuf-2.0.so.0 or about gtk/gtk.gresources.xml, not about the binary anymore xD

    Update xD

    gtk3-system looks fine now, but now we have adwaita-icon-theme xD

    cat LibreelecRR/Compilation_Time.txt

    Start: Fri Apr 16 20:55:03 UTC 2021

    Done: Fri Apr 16 22:42:27 UTC 2021

    Takes around 2h from clone till here xD

    But from now on, i will just build, without the cleanup, should be fine to get through all errors. And then i can build from clean again xD

    But i need finally some sleep, see you tomorrow xD

    Ramalama does installing libgdk-pixbuf2.0-bin solve the problem? Because looks like I either have to add it to the toolchain or to the host system deps ^^

    It's just a matter of how "lazy" I am... I have to check how many extra steps it takes to build my own gdk-pixbuf for the toolchain, so gtk3 can use it at build time without relying on target gdk-pixbuf.

    you don't have to rebuild the whole project, just run:

    PROJECT=Generic ARCH=x86_64 scripts/clean package_name & PROJECT=Generic ARCH=x86_64 scripts/build package_name to rebuild a single package. If it picks up gdk-pixbuf provided by your build host you'll see instant results.

    Well I will check the host build anyway since it's the cleaner approach, never trust the host system if it comes to building the images :D

    oh god, that would have made it easier 🙈

    however, with the libgdk package it seems that it compiles fine.

    i just runned into another error, on another package, but this time i think it comes from, because i installed libgdk and didn't cleaned the build cache or something.

    So let me check, i will reply in 2h 😂

    You can could look in the meantime to this here, if you like it or not, it's basically already done, just have to fine tune it😂

    Libreelec-RR-Scripts/libreelec-rr.sh at main · Ramalama2/Libreelec-RR-Scripts · GitHub

    It's basically just a wrapper for your repo 😂

    Will reply in 2h, cheers 😂

    Ramalama

    don't worry... I didn't know this back in the days > three years ago too & I was rebuilding the dumb way over and over and died through the build until everything was fixed...

    Yeah you have to consider that the packages are linked against each other and so if the host config changes or e.g. you bump a single package which was linked agains libexample.1.14 and then the bumped package install libexample.1.15 you also have to recompile the packages which depend on the lib.

    About the wrapper... whatever floats your boat :D usually the project files include everything you need and args like BUILD_PERIODIC=RR or BUILDER_NAME=ST are optional. All you need is PROJECT=Generic ARCH=x86_64 make image, even PROJECT=Generic ARCH=x86_64 are superflous since it's the default, to kick of building an image since the scripts already handle everything else but obviously you have to tell the makefile which project you want to build.

    Quote from SupervisedThinking

    Ramalama

    don't worry... I didn't know this back in the days > three years ago too & I was rebuilding the dumb way over and over and died through the build until everything was fixed...

    Yeah you have to consider that the packages are linked against each other and so if the host config changes or e.g. you bump a single package which was linked agains libexample.1.14 and then the bumped package install libexample.1.15 you also have to recompile the packages which depend on the lib.

    About the wrapper... whatever floats your boat :D usually the project files include everything you need and args like BUILD_PERIODIC=RR or BUILDER_NAME=ST are optional. All you need is PROJECT=Generic ARCH=x86_64 make image, even PROJECT=Generic ARCH=x86_64 are superflous since it's the default, to kick of building an image since the scripts already handle everything else but obviously you have to tell the makefile which project you want to build.

    Exactly, something like that i got, so im compiling everything now 😂

    I know that your scripts does already everything, that script is just basically to make it easier for myself, i started something i wanted to finish it, there is really not much more to it 😂

    A wiki does the same job 😂

    But on a clean new build environment, all i have todo is dumb run the script and it tells me, to install git+make+create an nonroot user to get started, and does everything else, without me having to fiddle in your repo and forgetting changing stuff that i personally want to cchange, like debloating the kernel 😂

    But tbh, libreelec made already a file for this, which is pretty amazing already to slim the kernel down.

    However, no one needs to use that script, it's just a dumb way for me if i forget everything in a month or so 😂

    --

    Compilation is over 60% already, so far everything looks great with the libgdk package 😂

    Using your latest repo changes (1h ago cloned)

    Cheers

    Ramalama

    Well the build system is IMHO really good if you compare it to others I've seen when digging through emulation related stuff but it's also the result of years of incremental improvements and guys like milhouse did an outstanding job (I hope he's well whereever he is right now!), don't forget all others who also wrote great stuff of course: Contributors to LibreELEC/LibreELEC.tv · GitHub the list is full of "nerds" sharing their expertise which is great.

    In the end you only have to clone the repo, change one line, type in make image and you're done. Everything else is just to pass some infos to the image naming scheme or for identifikation purposes so you know the name of the image you're running.

    About the kernel... well unless you don't want to slim it down to a point where it would only run on your system there is not much to do... the kernel conf is regularly updated and adjusted to only builds stuff a distro like LE really needs.

    All error where linked to gdk-pixbuf so far so I guess it should be fine once it is in place on your host machine.

    With libgdk-pixbuf2.0-bin, compilation went perfectly fine :)

    My head was this:

    Code
    c8fd01496bba529f1f010ee650b09b68c7c66620 (HEAD -> master-rr, origin/master-rr) mesa: drop revert-patch for mesa 21.0.y

    Im going to build and test now the RPi4 xD

    Well I've turned the half distro inside out to build gdk-pixbuf stuff but in the end I would end up with GTK3 & else as host build which isn't worth the hassle ^^ I've added libgdk-pixbuf2.0-bin as dependency to checkdeps and this should be fine.

    Could you remove the package once you've pulled in the latest commit & see if checkdeps asks for the correct file? Cleaning just gtk3-system & build it again should be fine to see if you run into trouble again.

    Quote from SupervisedThinking

    Well I've turned the half distro inside out to build gdk-pixbuf stuff but in the end I would end up with GTK3 & else as host build which isn't worth the hassle ^^ I've added libgdk-pixbuf2.0-bin as dependency to checkdeps and this should be fine.

    Could you remove the package once you've pulled in the latest commit & see if checkdeps asks for the correct file? Cleaning just gtk3-system & build it again should be fine to see if you run into trouble again.

    Well, that didn't worked well xD

    Check the attached logfile xD

    But if i do it myself:

    ----

    I have tested the pi.

    Compilation works perfectly fine!

    XOW - Works perfectly fine!

    xpadneo - (im have a hard times to pair the controller, still didn't managed)

    But that issue has nothing todo with you or libreelec, i had the same hard times to pair it initially with raspbian too.

    But once it paired at connected once, it works forever, just its hard to get there and still weren't successfull...

    So basically i need more time to test it out xD