Aura H2O Yet another telnet/sshd & misc tools package...

[NiLuJe]

The latest update should now feature an update script more resistant to natural disasters ;p.

(And also slightly less hackish manifest parsing, i.e., it's querying a new JSON manifest via jq instead of poking at the HTML index with sed REs. Said (ha!) dirty regexes have moved to the upload script, where I can afford for them to be ugly as sin ;p).

Also, the git build that was punted off to a weird standalone package is now a proper module that can be installed/updated by the script, check the updated documentation.

[NiMa]

Originally Posted by NiLuJe

Also, the git build that was punted off to a weird standalone package is now a proper module that can be installed/updated by the script, check the updated documentation.

Nice, thanks! This will save me time when I'll want to clone some Git repo on the Kobo, instead of using an Alpine minirootfs with Git...

[NiLuJe]

On that note, ssh -A is your friend to forward an ssh-agent .

[Sky17]

Hi NiLuJe! I'm recently giving a look at some of the project you worked on, your Kobo Stuff and Koreader are very useful!

I have a request / question, how to extend Python functionalities? I would like to have more "pip packages" on your bundle. My idea is to run PyBoy, which is a cython Game Boy emulator. It has a dependency to SDL2, which in the end we won't use, but idk if it can be stripped out. Numpy is also required.

GitHub link: https://github.com/Baekalfen/PyBoy

Once the PyBoy package can be bundled on the Kobo, I would like to extend the emulator functionalities with FBInk, to possibly make a very rudimental emulator (or surrender to fps limitation and be happy with it).

How can I cross-compile the package to be compatibile with your python bundle? Or can you consider making an experimental bundle with this package for me?

[NiLuJe]

First of all, I'm going to dash your dreams right away: SDL2 is going to be a no-go, it no longer has a linuxfb video backend.

Secondly, cross-compiling Python/C extensions is... not a fun experience, cf., the rants about that in the Python section of the x-compile script.

numpy, on the other hand, is common enough that it would make sense to bundle it.

[Sky17]

I kind of expected SDL2 was a big problem, but with some editing, maybe it's possible to remove the it, since it already has an headless mode, which likely doesn't use it in any way. The emulator will still update its raw framebuffer data, which I plan to print in some smart way with fbink_print_raw_data.

Anyway, even if I can't run the emulator on the device, I could make some kind of network streaming without the need of external dependencies, running it on another device.

Where can I find a python example of FBInk that uses a very basic GUI with button, recognizing press/release events?

[NiLuJe]

FBInk doesn't do input (because, hahahaha, it's hell on wheels on Kobo), so, that'll be on you (and you can't use libinput because everything is terrible).

@Mavireck did some stuff on that front in the past.

[sherman]

Originally Posted by NiLuJe

Secondly, cross-compiling Python/C extensions is... not a fun experience, cf., the rants about that in the Python section of the x-compile script.

numpy, on the other hand, is common enough that it would make sense to bundle it.

I've been thinking it would be really neat to have a sysroot that could be run with proot and qemu, and has a native compiler. Would make doing python stuff a lot easier IMO. Something like nuitka might even be an option for some people.

I thought about doing it myself, but unsure of how one would need to compile a cross-native compiler with your crosstool-ng setups, and which versions of GCC that would be best to use for such purposes.

[NiLuJe]

@sherman: I've never felt any inclination for the qemu approach myself, but, IIRC, it's been done in the past, I think?

(In which case: all hail BuildRoot \o/).

ct-ng can do cross-native & canadian builds, but since BR handles cross ct-ng TCs, and can build TCs itself, ct-ng -> BR ought to be enough to get you a sysroot with another TC inside.
Might need some minor packaging shenanigans in BR to match the glibc, but that's it.

The TL;DR being: if you intend to build a sysroot, I highly recommend letting BuildRoot handle the heavy lifting (and, as far as I'm concerned, it has the advantage of supporting crosstool-ng TCs without any fuss. Which makes sense, as the original ct-ng creator is a BR maintainer ;p).
(I have no experience with the OpenEmbedded stuff, which appears to be the other alternative if you actually aim to build a real, shippable distro. It's what's used by the reMarkable, and the Kindles started using at least parts of it a few years ago, too).

----

Speaking of Python, since numpy's buildsystem is completely bonkers, and I can now afford to dump Python 2, I went with https://github.com/benfogle/crossenv, and that worked rather well.
I mean, numpy's buildsystem is still bonkers, but it at least convinced it to try to build stuff the right way.

(My previous approach for Python 2 was distutilscross, and that or a funky hack mentioned in a Py 3 issue for Py 3 stuff where that failed).

[sherman]

I guess my concern is how to build a sysroot that is as compatible with the stock Kobo system as possible. Having never actually done this sort of stuff before, I'm a bit lost...

In other words, it may or may not happen.

[NiLuJe]

The main paint-points are the glibc for C, and GCC for C++.

Since I generally don't care as much about C++, given that for simple cases, linking to the STL statically works out well enough, that only leaves matching the glibc version, which is not as problematic, because it's old, not not *ridiculously* old (well, frankly, it *is* kind of ridiculous, but it gets ridiculous-er as far as building goes if you go back further ;p).

And when you *do* care about GCC (i.e., nickeltc), we're *riiiiiight* at the limit before stuff would get *really* messy (i.e., GCC 4.9), so it generally works out well enough.

(As in, I don't think I have anything significantly custom/hacky in place to handle the nickeltc target. But for C++, stuff is kindly starting to tell you to go get a real compiler w/ C++11 support for real nowadays, so, depending on what you want to build, matching the GCC version may actually be *counter*-productive).

Remember that I started all of this to target the Kindle on FW 2.x, and that runs... Linux 2.6.22 on glibc 2.5 . Good luck building that one ;p. (I cheat, because I couldn't, so I went w/ 2.9 and piles of hacks to avoid pulling newer symbols).

[NiMa]

Originally Posted by NiLuJe

@sherman: I've never felt any inclination for the qemu approach myself, but, IIRC, it's been done in the past, I think?

(In which case: all hail BuildRoot \o/).

ct-ng can do cross-native & canadian builds, but since BR handles cross ct-ng TCs, and can build TCs itself, ct-ng -> BR ought to be enough to get you a sysroot with another TC inside.
Might need some minor packaging shenanigans in BR to match the glibc, but that's it.

The TL;DR being: if you intend to build a sysroot, I highly recommend letting BuildRoot handle the heavy lifting (and, as far as I'm concerned, it has the advantage of supporting crosstool-ng TCs without any fuss.

BuildRoot worked like magic with my InkBox/Alpine setup where I needed a chroot environnement with glibc instead of musl
Also, creating a 'shippable' firmware is not that difficult; even diagnostics and recovery in InkBox were not that hard, and once you get the thing working, it likely will not fail for a long time

[Sky17]

Thanks, I think I can try something with the source of Mavireck's Kobo Launcher. Maybe I can manage a client-server approach with sockets and plain Python.

[ucanzeee]

I had my pc screen transferred to my kobo aura one. It's possible. I think it's not that good. Too slow refresh rate, that there is no point of it. How do I roll this back? I want it the old way.

[NiLuJe]

@ucanzeee: You haven't given much to go on, and my crystal ball is broken. I have no idea what you're talking about.