opkg, opkg GUI and plans on package repository for Kindle Touch

[Nyoxi]

I have added the combined opkg & overlay installer to the first post of this thread. I have also removed the big warning because due to the overlay it isn't really dangerous any more.

I've been also looking at the OpenEmbeded/bitbake and it seems nice. So we can certainly use that.

The good thing is there's not much work to make packages for the WAF apps together with the Launcher integration. I will start by creating the necessary config files and setup and also prepare several packages of existing hacks as an example.

We could also use OpenEmbeded to build complete replacement of the underlaying linux and all the apps/libs later (if we want newer versions or something).

Creating packages for other (compiled, not shell script, not WAF) applications and libraries might be little bit difficult. We have to check if the cross-compile toolchain contains compatible versions of all libraries on KT. If not we will have to downgrade the necessary packages.

[aditya3098]

GUI looks although I still didn't find how to use it. I am repackaging all my WAFs for this system. So, how DO you use the GUI and how should I put my ipks on your repo.

[Nyoxi]

Originally Posted by aditya3098

GUI looks although I still didn't find how to use it. I am repackaging all my WAFs for this system. So, how DO you use the GUI and how should I put my ipks on your repo.

There's still a lot to do on the GUI for it to be usable. Unfortunately I don't have enough time to focus on this together with the other packaging stuff.

Concerning the packaging I suggest you wait a little while. I will try to make things ready by the end of the week. I will also make a wiki page with explanation how to make the packages. The idea is to use OpenEmbeded and BitBake to make it as easy as possible for people to create and maintain a package.

[aditya3098]

Can we try to change the extension to, say, .kth(KindleTouchHack)? (a bit early for this, though)

[Nyoxi]

Changing the extension would be fairly easy to do, but I don't see any reason why we should do that. The format is fairly general and we can pack anything from simple kindle hacks in for of one line script to full stand-alone applications if we want.

[eureka]

I've used overlay created with plain overlay script (from "Overlay ..." thread). But my KT has been updated OTA from 5.0.3 to 5.0.4 with overlay enabled, so Amazon's files has been placed to overlay FS.

There is definitely no harm in this, but I don't like Amazon's files on my overlay, so I've decided to update with real rootfs and then make new overlay.

So I've copied kernel modules from overlay to real rootfs (kernel has been updated in 5.0.4, so after disabling of overlay modules should still match to kernel) and disabled overlay. Sometime later (precisely when I just downloaded 5.0.4 update bundle manually ) KT has been updated OTA again.

Then I made new overlay with bootstrap script from this thread slightly customized for my needs (with using/formatting of already available loop image).

It works fine, thanks again!

Though, there is one problem. rm of files on overlay sometimes produces 'Segmentation fault'. It could be also noticed on removing opkg packages. But I think (wild guess!) it's because of mismatching between mini_fo module and kernel from 5.0.4, so it's not the bug...

OK, there are some more problems When I've tried to install patch package (from NSLU repository), maintainer scripts whined about missing /opt/bin/update-alternatives.

I've fixed it in clone of HG repo at https://bitbucket.org/katey_hack/nyoxi-kindle-packages/ (it's both clone and web-interface URL).

(Also, your repository http://nyoxi.net/files/kindle/packages/ isn't included in opkg.conf in opkg package contained in current bootstrap tarball, is it intentional?)

[Nyoxi]

Originally Posted by eureka

I've used overlay created with plain overlay script (from "Overlay ..." thread). But my KT has been updated OTA from 5.0.3 to 5.0.4 with overlay enabled, so Amazon's files has been placed to overlay FS.

There is definitely no harm in this, but I don't like Amazon's files on my overlay, so I've decided to update with real rootfs and then make new overlay.

This is exactly the harm that has been done. Keeping the updated files on the overlay is not a good idea.

Though, there is one problem. rm of files on overlay sometimes produces 'Segmentation fault'. It could be also noticed on removing opkg packages. But I think (wild guess!) it's because of mismatching between mini_fo module and kernel from 5.0.4, so it's not the bug...

From what we know about the kernel update in 5.0.4 it seems unlikely to cause something like that on it's own. (Unless there's something important we don't know about the kernel update.) Can you confirm it didn't happen in 5.0.3? Also, can you reproduce this reliably on new and fresh overlay image? Can this be the result of the previous OTA update? (You do not specify the exact procedure of recreating the image.)

I for myself don't plan to update to 5.0.4 (or any other version) any time soon so I will need somebody else to investigate.

OK, there are some more problems When I've tried to install patch package (from NSLU repository), maintainer scripts whined about missing /opt/bin/update-alternatives.

I've fixed it in clone of HG repo at https://bitbucket.org/katey_hack/nyoxi-kindle-packages/ (it's both clone and web-interface URL).

Thanks for the changes, I pulled them all. I'll update the package sometime next week.

(Also, your repository http://nyoxi.net/files/kindle/packages/ isn't included in opkg.conf in opkg package contained in current bootstrap tarball, is it intentional?)

Yes, this is intentional. The location of the repository will change and the repository you mentioned will sereve only for my own tests (if at all). For the moment there isn't anything too interesting anyway and anyone interested let's say in the opkg-gui can add the URL to the repository manualy.


Thanks for the report!

[leonard.pitzu]

Hello everybody. I'm new to this forum as i just got a Kindle Touch (WiFi version). I've added a bluetooth module to the kindle, jailbroaken it and written some WAF apps. now i want to do a small app to read some data from the serial port (over bluetooth or so) and display it in the UI. I'd like to do this in JS & HTML but reading the serial port requires a C++ app or a Python script. I'll do all of this (hopefully) but i need to disable first the console from inittab (i need to release the serial to use it as i want). Now... i don't have python (& pyserial) and i have no ideea how to get it. This project seems to provide everything i want so here i am asking for some help :-)
Is there a way of installing Python on a KT? How can i do that (no worries, i am not affraid of loosing my waranty as i just my KT appart and soldered a BT module inside)? I am no stranger to Linux, programming or hardware development but i haven't done much with embedded linux & KT. Probably i'd do it on my own but i have little spare time and there is no point in reinventing the wheel. Also i will share my apps & stuff as soon as it's all functional. just some hints to what i'm doing: i have developed a weather app which reads & displays data from my personal weather station - also developed by me. i currently support chrome, firefox, safari, opera, android, nokia s40 & s60 browsers (all offline apps which fetch the data from the internet when needed and store it localy) and partialy KT. for the KT i also want to add some sensors localy (temperature, pressure, humidity and accelerometer - i can o i do it, no practical reason behind :-P ) and display also local conditions in the same app.

so if anybody has some guides on how to install python & pyserial on the KT or any other hints just let me know.

Thanks,
Leo

[Nyoxi]

Hi Leonard. Unfortunately this project is still in a developement phase and will not help you in any way right now. But you're right, at some point in the future it should provide python easily. Anyway, there already is some thread about python for KT (or Kindles in general?). Dunno if it's in any usable state.

And a notice to everyone: I'm back!

I'll try to move this to some usable state soon. Unless things have changed and this is no longer interesting/wanted.

Unfortunately the new 5.1 update which seems to break everything including a lot of previously working hacks means a huge trouble. It brings to the first place an issue I hoped we wouldn't have to deal with so soon. We need a good and solid way of having different package versions for different versions of the firmware (and kindle for that matter). One way is having different package repository for different version, but this (IMHO) will lead to lot of troubles with people using wrong repository for their kindle. My original idea was to use the 'Architecture' field of a package to differentiate the firmware/kindles. Unfortunately I still don't know if it is possible to hack OpenEmbeded to do that in a clean way (and the OE devs weren't much helpfull here yet). I'll keep looking into that.

If anyone has any other bright idea feel free to share.

[eureka]

@Nyoxi, there is no need in [ab]using of Architecture field. Please, for the sake of correctness, don't introduce confusing differencies with original .deb format. Anyway, you could just use your own field, say, Kindle-Firmware-Version (or, maybe, X-Kindle-Firmware-Version to never conflict with future official fields). It is totally legal: Control files and their fields - User-defined fields.

BTW, if you want to prevent installation of old incompatible (maybe, unsupported) hacks onto new firmware version, then differrent package repos for different firmware versions is the most sane idea. Checking of relevant control file field could be an additional option (enabled by default, but overridable).

OK, as I see, OE writes into .ipk control file only predefined set of fields and it doesn't support user-defined fields, so [ab]using of Architecture field is your best try with standard OE classes. But, still, it's awful solution.

Did you really already setup OE fully for building of packages for Kindle and problem of differentiating packages for some firmware versions is your last barrier?

[Nyoxi]

Originally Posted by eureka

OK, as I see, OE writes into .ipk control file only predefined set of fields and it doesn't support user-defined fields, so [ab]using of Architecture field is your best try with standard OE classes. But, still, it's awful solution.

Yup, that's the problem. No custom fields. Don't take it wrong, I don't like this idea particularily either. Maybe we could patch OE to support custom fields. I'm not sure how difficult it will be or whether OE-devs will like it.

Originally Posted by eureka

Did you really already setup OE fully for building of packages for Kindle and problem of differentiating packages for some firmware versions is your last barrier?

I think there were a few minor other issues, but I don't remember anything now. This has been on ice for more than a month and all the stuff is somewhere in the back of my memory. I'll have to start working and wait for it to come back to the surface.

[eureka]

Originally Posted by Nyoxi

Yup, that's the problem. No custom fields. Don't take it wrong, I don't like this idea particularily either. Maybe we could patch OE to support custom fields. I'm not sure how difficult it will be or whether OE-devs will like it.

Patches for custom fields support are in OE-core mailing list. I hope they will be accepted.

Originally Posted by Nyoxi

I think there were a few minor other issues, but I don't remember anything now. This has been on ice for more than a month and all the stuff is somewhere in the back of my memory. I'll have to start working and wait for it to come back to the surface.

Are you using plain bitbake -b <package> for package building?

[aditya3098]

On firmware 5.1.0:

[root@kindle opkg]# opkg-gui
X11 connection rejected because of wrong authentication.

(opkg-gui:32259): Gtk-WARNING **: cannot open display: localhost:10.0

[twobob]

Well I'm still interested.
For the record.

[qlob]

Me too... This would be nice.