I just want to get the ball rolling. What do we need? How do we get a real working repository for the OpenPandora?
There is space and bandwidth out there right?
We know we're not entirely at ground zero because there's a working OE build environment somewhere that's making the firmware image. We just need to put it to use packaging everything from over at the Angstrom repo (and maybe Debian, too) with the Pandora's unique needs in mind.
Tell me what needs to be done and point me in the right direction, I'll make time to make this happen.
Am Wed, 9 Mar 2011 21:44:30 -0500 hat Mindlord mindlord@gmail.com geschrieben:
Hi and welcome :)
I just want to get the ball rolling. What do we need? How do we get a real working repository for the OpenPandora? There is space and bandwidth out there right?
There's enough space and bandwidth on our server, yes.
We know we're not entirely at ground zero because there's a working OE build environment somewhere that's making the firmware image. We just need to put it to use packaging everything from over at the Angstrom repo (and maybe Debian, too) with the Pandora's unique needs in mind. Tell me what needs to be done and point me in the right direction, I'll make time to make this happen.
Well, right now the server takes the recipe for the OpenPandora firmware image, bakes the IPKs from that and creates a flashable image. Therefore, we only have a repo for all the stuff that's in the default firmware.
That one works well, though, I tried upgrading vanilla Pandora and updated it to Hotfix 4 with opkg upgrade :) The repo can be found here: http://openpandora.org/feeds/
Basically, if we want all OE packages in there so that the user can install non-included things as well, we'd need to setup the server so that it bakes all other packages from our OE Clone (http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=summary) as well, but doesn't include them in the image, but only in the feeds.
Once that has happened, we can easily switch the Pandora to use our feeds.
Basically, if we want all OE packages in there so that the user can install non-included things as well, we'd need to setup the server so that it bakes all other packages from our OE Clone (http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=summary) as well, but doesn't include them in the image, but only in the feeds.
Once that has happened, we can easily switch the Pandora to use our feeds.
No need to include all OE packages. The opkg config files (in /etc/opkg/) let you specify multiple feeds at different priorities. The arch.conf file lists feed names and relative priorities, while *-feed.conf gives the corresponding URL for each feed. Simply set the Pandora feed as the highest priority and the Angstrom feeds lower; that way, all Angstrom packages are accessible unless there's a Pandora-specific version that supersedes it. Of course, not all Angstrom packages will necessarily work next to Pandora packages. But if a package is found to need Pandora-specific fixes, the fixed version can be added to the Pandora feed.
I hope that helps.
Randy Heydon
Hi Randy,
Basically, if we want all OE packages in there so that the user can install non-included things as well, we'd need to setup the server so that it bakes all other packages from our OE Clone (http://git.openpandora.org/cgi-
bin/gitweb.cgi?p=openembedded.git;a=su
mmary) as well, but doesn't include them in the image, but only in the feeds.
Once that has happened, we can easily switch the Pandora to use our feeds.
No need to include all OE packages. The opkg config files (in /etc/opkg/)
let
you specify multiple feeds at different priorities. The arch.conf file
lists feed
names and relative priorities, while *-feed.conf gives the corresponding
URL
for each feed. Simply set the Pandora feed as the highest priority and
the
Angstrom feeds lower; that way, all Angstrom packages are accessible
unless
there's a Pandora-specific version that supersedes it. Of course, not all Angstrom packages will necessarily work next to Pandora packages. But if
a
package is found to need Pandora-specific fixes, the fixed version can be added to the Pandora feed.
That is exactly how I plan to setup the .next stuff. At the moment the builds just point off to the Angstrom repos but the plan is to use the OpenPandora ones at the top and the main Angstrom ones 2nd. We can also choose to mirror all of Angstroms repo is we want.
Angstrom already builds packages for the OpenPandora machine type (or compatible generic ARMv7) so we just need to push up the changes from .next into mainline (most important really is kernel and kernel config so it cascades down the build and is pretty close to what we ship in the firmware) that is really no big deal at all, once things are working well of course.
None of this unfortunately gets us away from NAND abuse and people filling it up with packages, that was the initial problem that had us shy away from pushing OPKG and this model with the 1st release ;).
Mindlord,
Regarding Debian packages, you may want to mail the guys maintaining that work to ask them how they want to tackle the problem (cc the list by all means).
Regards,
John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 10.03.2011 09:09, schrieb John Willis:
That is exactly how I plan to setup the .next stuff. At the moment the builds just point off to the Angstrom repos but the plan is to use the OpenPandora ones at the top and the main Angstrom ones 2nd. We can also choose to mirror all of Angstroms repo is we want.
Considering that the pandora firmware is likely to always be based on a snapshot of angstrom and angstrom might significantly differ in its packages (due to normal development) what is available in the current pandora firmware I think it would make sense to have a mirror of the angstrom repo (feeds, that is) based upon the versions of progs that are shipped on the pandora. So that eg stuff is liked against the same boost, jpeg, ... version.
Another benefit would be a possible increase of download speeds since the angstrom servers appear to be freaking slow (at least for me).
Angstrom already builds packages for the OpenPandora machine type (or compatible generic ARMv7) so we just need to push up the changes from .next into mainline (most important really is kernel and kernel config so it cascades down the build and is pretty close to what we ship in the firmware) that is really no big deal at all, once things are working well of course.
The only issue is making sure that we are actually staying close to current angstrom, which will require constant efforts that can't be guaranteed to happen "fast enough", so IMO the only way (when allowing to install extra packages using opkg at all and not just updates of the default packages!) would be to have our own mirror of angstrom packages compiled against the pandora libs.
None of this unfortunately gets us away from NAND abuse and people filling it up with packages, that was the initial problem that had us shy away from pushing OPKG and this model with the 1st release ;).
Personally I would not mind too much if there was no way to use opkg for *anything* besides updating the default firmware packages. Summing up the options that I see possible (while making sure that it is not too easy to break the system using an opkg update && opkg upgrade without modifying the opkg config files):
1) Create our own feeds for "all of angstrom" in a pandora specific way. This would require to create an additional feed or something like this mirroring all of angstrom and building it ourselves against the angstrom version on the pandora. Advantages of this: * Packages installed from the repo are very likely to not be broken due to wrong dyn linking. * You *can* actually use opkg without the fear that some important system libs will be replaced with versions breaking other progs. * Rather fast download speeds for the packages. Disadvantages of this: * Someone has to do the work to create the additional feed. * When creating the stuff the way that is used to generate the current firmware has to be checked to make sure that not too many (any) wrong things are added there. This should be a one time effort to make sure that the recipes are okay. * More bandwidth will be used on EDs servers. * It would be a mirror of the angstrom packages that would require someone to work on keeping stuff in sync and porting relevant security fixes over. This fragmentation of angstrom might be problematic, not sure. * Is is easy to swamp the nand with those packages, so some easy "cleanup solution" that is not flashing would be cool (some "automatically remove all opkg packages that don't belong to the default firmware" or the likes). * Is there enough CPU time available on the servers to compile *all* the stuff? There are some really huge packages part of the angstrom repos and building them will require some time...
2) Limit the pandora (in the default config) to only install packages from openpandora.org without mentioning the default angstrom package feed. Advantages: * It is less easy to destroy the system by upgrading some single packages using opkg to install something new. * Since there are currently only the firmware files available, swamping the nand is more difficult (okay, installing all -dev and -static packages *would* still fill the nand up...). * No additional work required to keep the stuff updated beside the work already done for the firmware. Disadvantages: * No huge repo of packages directly available (even if the packages might not work (at all)).
Personally I think that '1' would make most sense, if we find someone to get stuff set up to work and got enough resources (cpu time and bandwidth). What we should do anyway is add the "firmware feed" in the opkg config files as "main feed" (aka highest priority). Cheers, Nils Kneuper aka Ivanovic
Am Wed, 9 Mar 2011 23:30:35 -0500 hat Randy Heydon randy.heydon@clockworklab.net geschrieben:
Well, the reason the repo turned up here was because our current system is too old compared to the recent Angström.
Some developer installed the HF5 image and wanted to setup gcc for compiling on the Pandora, same way he did it before, but it lead to a completely broken system. Same issue if you just install firefox.
The Angström feed is now incompatible with our base OS, that's why we can't simply use them for the packages we don't have.
However, as DJWillis planned the feeds properly working for .next, that's some good news here :)
Basically, if we want all OE packages in there so that the user can install non-included things as well, we'd need to setup the server so that it bakes all other packages from our OE Clone (http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=summary) as well, but doesn't include them in the image, but only in the feeds.
Once that has happened, we can easily switch the Pandora to use our feeds.
No need to include all OE packages. The opkg config files (in /etc/opkg/) let you specify multiple feeds at different priorities. The arch.conf file lists feed names and relative priorities, while *-feed.conf gives the corresponding URL for each feed. Simply set the Pandora feed as the highest priority and the Angstrom feeds lower; that way, all Angstrom packages are accessible unless there's a Pandora-specific version that supersedes it. Of course, not all Angstrom packages will necessarily work next to Pandora packages. But if a package is found to need Pandora-specific fixes, the fixed version can be added to the Pandora feed.
I hope that helps.
Randy Heydon _______________________________________________ Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Until that gets resolved I still recommend..
For on-device toolchain, some options:
o run HF5 on NAND, and HF4 on SD; go nuts with opkg on the SD one; then when you need to do app-testingm your nand is still 'clean', so that if your app runs, you know it should work on user non-dev devices. (This is how I've always recommended development for on-device toolchains, just not it seems apparent it can be useful to run one hotfix back :/)
o 'stuckie extends' or other jail madness :) I've been using these a lot the last few months, since I reflash my nand a few times a week it seems, and usion a jail-to-SD means my install persists across flashes.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.