SHR Maintainer's guide

About this guide

This guide is written to explain how things are supposed to be done, with notes where we currently fall short.

Currently the emphasis is on laying out a method for running (maintaining) the shr testing distribution; as this is where the biggest hole is. Shr-unstable is mentioned for completeness, but it is more part of ongoing bleeding edge development than "maintenance" and should therefore be documented in detail elsewhere. Shr unstable is largely considered here for its role as an upstream source for shr testing.

Shr stable will not exist until the process for shr testing is established so again is only mentioned for completeness and to set out a strategy for the future.

See also

Getting started

Being a maintainer involves being reasonably sure that what you create will build successfully and work for others, so you probably should make sure you can build shr from scratch on your own pc. Start here, doing as much as you feel you need to:

  • read and Building SHR
  • create a local copy (following the above instructions)
  • check it builds locally
  • ideally flash your new image to your neo (from shr-unstable/tmp/deploy/images/)
  • point your neo to your home made feeds (I suggest overriding the buildhost ip in /etc/hosts on you neo), and running apache on your build box to serve the feeds (serving up the contents of shr-unstable/tmp/deploy/ipk/)

The different versions of SHR


  • latest commits, likely to regularly break, ideal for collecting bug reports :-)
  • already actively maintained

Ideally this will have a clean upgrade through opkg, though there are occasional breakages and workarounds posted to the mailing lists.


Based on a snapshot of shr-unstable with only bugfixes and somewhat tested improvements pulled in.

Full details at ShrTesting


Not begun, though occasionally requested.

This will likely be a an older version of shr-testing, with only bug fixes and security fixes applied.

A means of upgrade for those on the old shr-s is to be provided.

Shr-s has an even stricter set of requirements an update must meet to be made available than for shr-t.

The process for creating pre-release and release versions of shr-s is the same as for shr-t with the difference that the source for shr-s is shr-t rather than shr-u.

Who's who

Beta testers for shr-t

Potential maintainers

Previous maintainers


  • documented process for cycling versions (perhaps like debian does where unstable is copied to testing, testing becomes stable, and the old stable goes into maintenance mode, all on a rough schedule)
  • documented process (especially communications method for agreeing) for including packages, bugfixes, updates etc.
  • information on where shr-t code, patches, bugs, builds, images and packages are hosted and how to gain read / read-write access.
  • process for gaining maintainership status


current difficulties

  • due to the high right of churn it is currently hard to keep even a testing version vaguely stable, often being faced with a bugfix being presented as a complete rewrite (potentially incompatible with other items thus forcing wholesale package upgrades or introducing new bugs due to immaturity of the new code).
  • there are packages set to always use the latest revision of the upstream source, which is going to make pinning down versions a little tricky. - email on the subject of upstream versions.

alternative approaches

It is possible that we could leverage debian's existing build systems, community structure etc by getting the debian phone working sufficiently to make shr-t irrelevant. Some work has already been undertaken along this line of work. There is however no issue with pursuing both approaches simultaneously therefore generating more choice for fso users. There is also the hackable:1 project should you particularly want to use debian.

Further reading

Last modified 9 years ago Last modified on Oct 20, 2010, 8:46:23 PM