RetroPie 4.3.17 Stretch images

herb_fargus

Just a few notes from my minimal testing:

Didn't realise the scummvm binary wasn't 2.0 yet (would be nice), but runs fine

My gamepad controls are showing up in the terminal after using my gamepad to navigate the setup script.

Eg. ^[A]^[B] etc. Doesn't particularly seem to break anything, just cosmetic.

Supertux has a different package now/seems to want GL. So module will need some tweaking

I'm sure there are others, still testing

dmmarti

@herb_fargus ...ah....thanks...

I didn't notice it was a compile from source instead of the binary option. I only let it run for about 30-45 minutes I think.

I'll start it back up again and just let it do its thing.

Thanks.

BuZz

@herb_fargus said in RetroPie 4.3.11 Stretch images for testing:

Didn't realise the scummvm binary wasn't 2.0 yet (would be nice), but runs fine

Probably didn't rebuild the Stretch binaries after updating scummvm. rebuilding now.

My gamepad controls are showing up in the terminal after using my gamepad to navigate the setup script.

Eg. ^[A]^[B] etc. Doesn't particularly seem to break anything, just cosmetic.

it's because joy2key is left running (a bug that we had a possible fix for, but the fix caused runcommand to get stuck as it ended up waiting forever for a process). I have just made a change that could help (might speed up the python startup time). You will need to re-install runcommand after updating.

Supertux has a different package now/seems to want GL. So module will need some tweaking

Ah - we just install the debs - I tried the new supertux a while ago on Jessie, and it was slow without opengl. I might just have to exclude it for now, or switch to use an older source.

BuZz

@dmmarti said in RetroPie 4.3.11 Stretch images for testing:

I failed to capture my screen output. If you need to see if, I'd be happy to try it again.

Looks like I haven't built a binary for that yet - it may have failed when I built the optional packages and I missed it. I will check after scummvm is rebuilt.

Capturing screen output isn't that useful. Everything gets logged and the logs can be provided if something fails, but it looks like you may be better off sticking with Jessie and leave testing to those who are more familiar with RetroPie/Linux.

Sano

I received today my new SD card.
Stretch image is installed, some minor tweaking (no overlay, disable wifi, migrate root partition), and it works.
Updated and installed some themes and sselph scraper.
Only thing not working ATM are Dualshock3 with bluetooth (native bluez method).
I'll try new @psyke83 method :)
So far, so good.

herb_fargus

Error log from Pixel Desktop Install:

pi@retropie:~ $ cat /dev/shm/runcommand.log 
Parameters: 
Executing: startx -- vt1 -keeptty
xauth:  file /home/pi/.Xauthority does not exist

/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

runs fine if just typing startx in the terminal. It only has issues if trying to run from within the ports menu in ES

herb_fargus

@fluffypillow

This error is given with pegasus-fe after installing on raspbian stretch

/opt/retropie/supplementary/pegasus-fe/pegasus-fe: error while loading shared libraries: libOpenVG.so: cannot open shared object file: No such file or directory

psyke83

@herb_fargus said in RetroPie 4.3.11 Stretch images for testing:

libOpenVG

Temporary workaround: https://github.com/RetroPie/RetroPie-Setup/pull/2294/
If this can be fixed in the binaries, I'll just close this PR without merging.

Darksavior

Is the vc4 video driver used in this build?

fluffypillow

@herb_fargus @psyke83 Thanks, I think I can fix that. Pegasus is currently linked to libEGL/libGLESv2/libOpenVG, so I suppose I should use their libbrcm* version, right? Do we know about why they were removed (or why there were two versions in the first place)?

BuZz

@fluffypillow they were renamed to avoid conflicts with the mesa libs afaik (or something like that). On Jessie both are available, but on stretch only the new names are there. the new names should be used now to work on both Jessie and Stretch. RetroPie ensures that a Jessie install will have the newest package with the new names.

mitu

@fluffypillow @psyke83 gave an easy to understand answer here.

fluffypillow

@BuZz @mitu I see, thank you; I'll start using the new libs then.

bb2k

@herb_fargus

To allow emulationstation to launch Xorg you must edit the file /etc/X11/Xwrapper.config

and replace allowed_users=console

by allowed_users=anybody

bb2k

I use retropie with a rpi3 and a xin-mo controller.

~~Adding usbhid.quirks=0x16c0:0x05e1:0x040 in the cmdline.txt file does not seem to work anymore.~~

forget this post, this tip is working perfectly !

herb_fargus

@bb2k dpkg reconfigure didn't seem to work like it used to, probably changes with systemd.

The following command is the former equivalent

sudo dpkg-reconfigure xserver-xorg-legacy

bb2k

Hello,

Another bug.

Compiling lr-mame or lr-mame-2016 will result of a compil error.
(I managed to compile mame 2016 in retropie in jessie)

here is the error i got for lr-mame :

Archiving libatari.a...
Compiling src/mame/drivers/mpu4union.cpp...
Compiling src/mame/drivers/mpu4vid.cpp...
Compiling src/mame/drivers/bfcobra.cpp...
Compiling src/mame/drivers/bfm_ad5.cpp...
Compiling src/mame/drivers/bfm_sc1.cpp...
Compiling src/mame/drivers/bfm_sc2.cpp...
Compiling src/mame/drivers/bfm_sc4.cpp...
{standard input}: Assembler messages:
{standard input}:76226: Warning: end of file not at end of a line; newline inserted
{standard input}:77479: Error: bad instruction `_znulr8device_te3644_'
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
barcrest.make:802: recipe for target '../../../../libretro/obj/libretro/src/mame/drivers/mpu4sw.o' failed
make[2]: *** [../../../../libretro/obj/libretro/src/mame/drivers/mpu4sw.o] Error 4
Makefile:124: recipe for target 'barcrest' failed
make[1]: *** [barcrest] Error 2
make[1]: *** Waiting for unfinished jobs....
Compiling src/mame/drivers/bfm_sc5.cpp...
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
bfm.make:739: recipe for target '../../../../libretro/obj/libretro/src/mame/drivers/bfm_sc4.o' failed
make[2]: *** [../../../../libretro/obj/libretro/src/mame/drivers/bfm_sc4.o] Error 4
make[2]: *** Waiting for unfinished jobs....
Makefile:127: recipe for target 'bfm' failed
make[1]: *** [bfm] Error 2
makefile:1273: recipe for target 'linux' failed
make: *** [linux] Error 2
Removing additional swap
/home/pi
Could not successfully build lr-mame - MAME emulator - MAME (current) port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mame/mamearcade_libretro.so not found).

Log ended at: Sat 17 Feb 00:58:24 CET 2018
Total running time: 4 hours, 57 mins, 17 secs

BuZz

@bb2k you ran out of memory. Some may need more swap added, but note that experimental emulators are not all yet tested on stretch. I'm currently working through them. Exiting ES may help.

bb2k

@buzz ok managed to compile lrmame-2016 with 1G of swap

I'll try to compile lr-mame as well

Sano

@BuZz Some questions :

do you prefer us to use this image lie we do with our regular setup, or do you have particular things you want to be tested ? (like compilation as @bb2k does) ?
will this image be updated through regular retropie update script, or do we'll have to re-image our SD for new test versions ? AKA basically can I use this image as a base for my main setup (knowing that bugs are likely to occur), or is it better to use it for testing purpose only, without transferring all roms, saves, ... ?