The software side

Discussion in 'Pyra OS (Debian GNU/Linux)' started by aTc, Feb 2, 2014.

  1. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,446
    Location:
    Finland
    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.
     
    Last edited by a moderator: Feb 24, 2014
  2. klapse

    klapse Central Scrutinizer

    Joined:
    Aug 30, 2012
    Messages:
    1,932
    Location:
    Germany
    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.
     
    Last edited by a moderator: Feb 24, 2014
  3. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    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.
     
  4. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,446
    Location:
    Finland
    Also this does not have to be one or the other. It can be both too :)
     
  5. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    ^That's what I was trying to say :) Thanks!
     
  6. Risca

    Risca Still Fresh

    Joined:
    Sep 25, 2011
    Messages:
    5
    And now for something completely different

    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 :)
     
  7. _wb_

    _wb_ Microbe Staff Member

    Joined:
    Apr 5, 2012
    Messages:
    5,387
    Location:
    Brussels, Belgium
    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.
     
    comradekingu likes this.
  8. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    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
     
    Last edited by a moderator: Mar 23, 2014
  9. Risca

    Risca Still Fresh

    Joined:
    Sep 25, 2011
    Messages:
    5
    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.
     
    Last edited by a moderator: Mar 24, 2014
    klapse and FBnil like this.
  10. freedomdown

    freedomdown Still Fresh

    Joined:
    Feb 5, 2011
    Messages:
    15
    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.
     
    Last edited by a moderator: Jun 7, 2014

Share This Page

Loading...