[Raspbian-devel] Status of raspbian.

[peter green]

It has come to my attention that you are planning to do a 
session at debconf on "status of the arm ports" and you have
included raspbian in your list of arm ports.

I won't be at debconf this year (I'm kinda busy at the moment 
and I don't notice it was on until too late) maybe next year
but I thought you might appreciate being filled in on the 
status of raspbian before your session. Feel free to use
this information as you see fit (some of it may not be
relavent).

I'm ccing this to raspbian-devel because others may be
interested too. 

Arcitecture name:
  Raspbian uses the armhf architecture name and I have always
  belived this is the correct thing to do. Precendent from both
  ubuntu and debian itself is that architecture names represent
  a cpu family/abi rather than a specific level of minimum CPU 
  requirements. While raspbian is a bit unusual in that it 
  changed the requirements downwards rather than upwards I
  belive the principle still holds.

  Having said that it would be good if there were better ways
  of handling ports that were compatible but had different
  minimum CPU requirements. Debian currently has no way of
  representing this.

Infrastructure:
  Raspbian lives on it's own infrastructure and given the
  shared port name, the slightly unusual operating nature
  of the project (following testing and stable unlike most 
  unofficial ports which follow sid) and the large number
  of users I expect it to stay that way.

  Bytemark have very generously supplied us with a dedicated 
  server some time ago (thanks guys) and will hopefully be 
  replacing it with a better one soon. This server hosts most 
  services for raspbian (archive.raspbian.org,
  mirrordirector.raspbian.org, www.raspbian.org,
  buildd.raspbian.org, snapshot.raspbian.org etc) They have 
  also spoken about providing a build cluster but the details
  of that have not been worked out yet. Currently raspbian
  wheezy is built by a build cluster in mikes basement (8x 
  IMX53-START-R) while jessie is built by a build cluster at my 
  flat (1x nitrogen6x with 2GB option, 1x wandboard quad)

  We may also like to look into expanding to another provider.
  I wish bytemark every success but relying on a single provider
  doesn't seem like the best thing long term. If anyone is
  interested in donating hosting please do get in touch.


Personell: 
  Currently raspbian is being basically run by me alone. I don't
  want to give others access to the infrastructure right now 
  because things are rather hacky in places and some of the
  tools I wrote for raspbian give output that is misleading to
  say the least. Having said that I'd really appreciate people
  in the following categories.

  1: bug triagers, people who can go through the bug 
     reports we get on our launchpad project and sort them into
     bugs that should be pushed to debian, bugs that should be
     pushed to the raspberry pi foundation, and bugs that
     actually need to be dealt with in raspbian.
  2: people to look after particular tricky packages, for
     example web browsers, compilers etc. I try my best but i'm
     not an expert in any of them and hacking up (say) a new
     version of ghc so it builds on raspbian when I don't know
     any haskell can be a major time sink. Similarly for merging
     the raspberry pi foundation's kernel work with the debian
     kernel packaging to produce debian style kernels for 
     raspbian.

Raspbian itself:
  Raspbian seems pretty healthy at the moment, we are following
  jessie with relatively few difficulties. The fact we only have
  two autobuilders working on jessie may cause some delays when
  large transitions land but afaict that hasn't really happened
  yet.
  
  gcc 4.6 seems to suffer from some internal compiler errors. 
  So-far we have mostly dealt with these by pointing the affected 
  packages at newer versions of gcc (4.7 for wheezy 4.8 for 
  jessie. It will be interesting to see how the ICE rate  changes
  once 4.8 enters jessie. As I mentioned in the personell
  section a gcc expert who is prepared to take ICEs in raspbian 
  and push them upstream (or better still fix them) would be
  appreciated.