The software side

[bzar]

The simple solution would be to forego a build service. Let the PND packager do the build himself and provide a place to upload the source tarball.

Simple, but depends on people actually doing that.

A build service also makes sure everything needed to build the package is actually mentioned in the recipe. Even further, it can be made to pretty much do new versions of stuff based on upstream code with a click of a web UI (provided the same recipe still works). No prior dev environment setup or anything needed.

 

[klapse]

The simple solution would be to forego a build service. Let the PND packager do the build himself and provide a place to upload the source tarball.

Simple, but depends on people actually doing that.


A build service also makes sure everything needed to build the package is actually mentioned in the recipe. Even further, it can be made to pretty much do new versions of stuff based on upstream code with a click of a web UI (provided the same recipe still works). No prior dev environment setup or anything needed.

People actually doing that involves no additional work besides a tar command. Learning to use a build service can be hellishly complicated. I learned this from trying to submit packages to Maemo.

Just uploading your tarball is trivial and is the easiest way to ensure that people will actually upload their source.

 

[_jr_]

I agree that a build service adds another meta layer that makes contributions more difficult (at least initially). But on the other hand it offers a lot of value that is difficult to achieve manually (not least promoting proven workflows). I think it could be solved by keeping PND (i.e. something more or less cleanly separated from os packages) with the current repo infrastructure (perhaps with the tarball source option) and adding an optional build service. That way anybody can still upload manually built PNDs and get useful feedback enabling to port it to the build infrastructure.

 

[bzar]

Also this does not have to be one or the other. It can be both too

 

[_jr_]

^That's what I was trying to say Thanks!

 

[Risca]

And now for something completely different

- Firmware Installer

        A generated image usually needs additional configuration to be run on the device itself. (package installation, first run wizard )

I've developed a cross-platform GUI installer for the RasPlex project (with help from the RasPlex community and Win32 Disk Imager). The installer downloads a list of available firmwares from a server (complete with download link, md5 checksum, release notes, etc) and lets the user download and install whatever version of RasPlex they want.

Now, I thought this might be something the OpenPandora and Pyra community could benefit from. The installer could be modified quite easily to download a list of firmwares from a OpenPandora/Pyra/DragonBox/whatever server instead. Maybe add a tick box if the firmware should be installed to flash or run from the SD card.

However, I don't know if this would actually bring anything to the Pyra. Is the current way of updating the OS simple enough already? Comments are welcome

 

[_wb_]

The way to update the OS on the Pyra would be just:


sudo apt-get update
sudo apt-get upgrade
and of course there are "front-ends" available for this too.

 

[_jr_]

A reflashing helper application that runs on Windows/Ubuntu/OSX/whatever and preps the SD card correctly (or does whatever is used for reflashing, perhaps directly via USB) could probably be useful for several people.


edit: clarified that I don't know how reflashing on the Pyra is handled

 

[Risca]

The installer I wrote simply takes a raw (gzipped) firmware image and writes it directly to a SD card.

This allows for the image to have bootloader, ext4 partitions, a picture of ED, experimental rootfs, slackware, or whatever on it and the user doesn't need to know anything about it; it just works.

Note that this is for the initial installation only. It do not support any kind of partiiton mounting, OS updating, etc. Only raw flash (you will loose your settings).

EDIT: There is a big advantage of this approach of overwriting everything. If you want users to test an experimental firmware, you want all the users to have the same configuration. Helps debugging a lot.

 

[freedomdown]

First of all, Sorry for re-opening this thread.

I just heard about the Pyra, and as an owner of the classic Pandora I am excited.

I've been reading some of the discussions, and have been thinking about the new PND format.

I thought I'd share my idea, some of this may have been discussed at some point.

I'm not even sure exactly what the current plan is for it.

Also keep in mind: I am not an expert at this stuff.

PND File format:

What if we have an uncompressed zip file which contains:

- metadata (pxml or whatever)

- icon and screenshots

- actual data folder compressed into a file (perhaps using cramfs or something similar)

This would make it easy to access most of the stuff the OS/launchers need, while providing compression for the actual game data.

This is probably a bad idea, but you could even have it save the appdata to another cramfs file in the zip. But then it would be difficult for the user to access their own save games.

Dependencies:

What if you define a "run-time environment" for people to dynamically link to, but have it separate from what's installed in the OS.

It could be run through chroot or a sandbox system so the games wouldn't need to worry about the latest version of some library being installed for the rest of the linux system to use.

It would be like the Android api versions.

Updating this "run-time environment" would be as easy as having another sandbox to use for newer PNDs. Each PND would specify which run-time version they want. And if the user didn't have that one then they can download it or try to run the PND in a different run-time (after being warned it might not work).

This would also provide some security from something trying to alter anything it shouldn't.

The appdata would be mounted in the sandbox so the app can save stuff there. If it is needed, the actual root filesystem could be accessed through a symbolic link(maybe only the user's home folder, again for security reasons).

The other libraries would be included with the apps (which would be compressed, so it wouldn't be as big of a problem).

The sandbox should work fine with multiple things running at once as everything would have it's own version of the run-time with changes not committed to the actual filesystem.

All that security stuff might be over kill. I've got security on the mind because they had a virus outbreak at work today.

Edit:

I forgot one thing,

You can maybe have a Pandora run-time that has the same libraries and versions as the Pandora has. That way it could speed up porting games to the Pyra, or maybe even allow you to run the older PNDs directly.