It is pretty compatible. You just won't have thumb-compiled benefits, such as binaries size.

Not sure I got the question right, but running non-thumb binaries should be safe in general, assuming the binaries itself are harmless .

I am waiting iDont to send me the source code of latest bb-power, as soon as I have it, I will compile and upload it in -thumb repo.

Thanks for clarification, nevertheless, i will wait for the thumb version.

According to this post, only compiling with GCC 4.7 reduces the file size a lot. Is it planned to upgrade the autobuilder toolchain to 4.7?

According to my experience, this is not the case usually. And TBH autobuilder is way offtopic here. Neither I am the one who is taking care of it

I only compiled about 6 programs (non-thumb), mainly Qt related. Maybe they benefit more from GCC 4.7 than other programs (size wise). Some emulators I compiled where also slightly smaller.

If freemangordon says it is not his experience I will not argue with him, because he compiled a huge amount of software using GCC 4.7. I guess my general judgment was a bit premature for that matter

anyway, new small update is out, check first post for changelog

5.1-thumb1 was the first of all the updates i've done (all pr, cssu, cssu-t, last 4/5 thumb) where device failed to automatically reboot. other than that, it seems to be ok

Alert, Alert. Stuck in reboot loop after update. I suspect, that it's same problem, as reported earlier by other user - updating of system-services package (I haven't tried to update it manually - as fix for lacking dependency was coming, anyway).

It seems, that some people doesn't have problems, but some are stuck in dead loop. I have access to shell console (backupmenu's one), and I would like to help investigating cause. Any ideas, where to start?

I've also tried looking into framebuffer's output, but it looks normal to the point, when framebuffer disappear (and five dots should appear). Hoever, no five dots, and after a while, framebuffer appear again, with shitdown-related messages (nothing interesting about what might went wrong).

It's a pity, that we don't have any possibility to redirect framebuffer output to a log file - it would be both more convenient (file instead of screen-hunting) and useful (would include things obscured from screen).

/Estel

// Edit

As I've tried it on 2 devices - just to be sure, that report is valid (on my main device, I always use fapman for updates, so I always compare results by installing HAM-way, on 2nd device) - I would like to keep one in this state for debugging help, but I would also like to bring at least one (presumably, my main one) to working state.

Any hints? I'm aware of theory, but I never had need for doing it in practice. I'm right, that taking older version of system-services (that worked), unpacking it, and - from recovery shell - manually replacing files, should bring device to runable state? Any caveats?

The update from -thumb0 directly to -thumb2 went smoothly here using HAM, incl. reboot.