[Raspbian-devel] Arm bof and raspbian.

[peter green]

I've just watched the stream of the arm bof  (a video will hopefully 
appear at 
http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/ 
but doesn't seem to be available yet). I tried to participate over IRC 
but it doesn't seem I was terriblly successful in doing so (wooky later 
apologised for not watching the correct irc channel).

There were a few proposals, one suggestion was to make armhf-v6 a new 
architecture but while this would solve some problems it would cause 
others and so I don't support it as a way forward. For starters debian 
architectures have traditionally represent ABIs not minimum CPU 
requirements, raspbian packages and debian armhf packages are (supposed 
to be at least) compatible, you just can't run the mixture on a Pi due 
to minimum CPU requirements. Secondly it would leave no upgrade path for 
existing raspbian users.

Another proposal was to expand the package management tools and archive 
infrastructure to support variants of a port with different minimum CPU 
requirements but this seemed to be one of those ideas that sounds good 
in theory but would be a lot of work (with noone voulenteering to 
actually do it) and probablly take several release cycles to do even if 
there was someone to do it due to the number of things it would hit 
(dpkg, apt, higher level package managers, archive infrastructure etc).

Yet another proposal was to simply drop the minimum CPU requirements of 
armhf to support the Pi. This would be in keeping with debian traditions 
of supporting the minimum variant of an architecture but didn't seem 
very popular among people in the room (a show of hands showed about 
twice as many people thinking it was a bad idea as thinking it was a 
good idea). The question was raised as to how much impact this would 
have but noone really had an answer (it's a tricky one to benchmark 
because afaict the biggest disadvantage would be increased cache and 
memory pressure due to increased code size which is often hard to see in 
benchmarks that focus on testing one thing at a time)

At the end of the talk the host (who i'm assuming was wooky from the 
information given before the talk but he isn't someone I recognise by 
face) said something along the lines of "we'd like to help the Pi guys 
but were not sure how". Here are some thoughts on what would help us 
without making radical infrastructure changes.

1: centralise compiler defaults. Having to patch every bloody compiler 
package gets annoying fast and also makes it very difficult to multiarch 
raspbian with official ports of debian due to the version skew it 
creates (in particular with libgcc). I made a post about this to 
debian-gcc last month* but got no response. I've also been talking about 
it on irc with wooky, disussion pasted at the bottom of this email.
2: It would be helpful to us if testing stayed both in a more consistent 
state and closer to unstable. Much of the day to day effort in running 
raspbian is trying to deal with the inconsistencies in testing and/or 
dealing with build failures that have been somehow fixed in unstable but 
where the fix did not make it into testing before the break did. Of 
course I realise there is a compromise here, enforcing strict 
consistency checks on testing (all dependencies satisfiable including 
build-dependencies, exactly one version of each source package) would 
make it even harder to get transitions to go through. Maintainers can 
help here too, was it really nessacery to tie the migration of the 
default gcc change to the D and gold changes?
3: more skilled manpower would also be useful. In particular it would be 
really really helpful if we had a gcc expert who would work with us.

Someone also mentioned that supposedly some people are upset about 
packages missing from raspbian. Last I looked we actually had better 
coverage then the official arm ports but if there is a specific package 
you require that is in one of the official arm ports but not in raspbian 
do get in touch and i'll take a look. After the BoF wooky forwarded an 
email mentioning gnuradio. I'll follow that up seperately, I wont bother 
debian-arm with the reply to that but I will put it on raspbian-devel on 
alioth in case anyone wants to read it.

Finally it's not strictly related to anything else mentioned here but 
someone mentioned a mini-debconf in cambridge, can anyone tell me where 
I can find more details.

* http://lists.debian.org/debian-gcc/2013/07/msg00135.html

Discussion with wooky on #debian-arm after the BoF follows

<wookey> plugwash: I just realised I was only looking in this channel, 
not #debconf-talkroom2
<wookey> apoloigies for that if I missed things. please repost
<plugwash> In response to the comment about people apparently claiming 
things were missing from raspbian.
<plugwash> <plugwash> Last I checked raspbian actually had more stuff in 
it than the official arm ports
<plugwash> <plugwash> if something is in debian jessie and missing from 
raspbian jessie please do tell me
<wookey> plugwash: I will forward the mail I got
<wookey> it seemed odd to me too
<plugwash> In response to the question about what would help us assuming 
we stick with the current situation of raspbian being an unofficial port
<plugwash> <plugwash> One thing i'd really like to see is the 
centralisation of compiler defaults
<plugwash> <plugwash> right now we have to patch a shedload of compiler 
packages individually for raspbian which is a pain in the arse
<wookey> plugwash: mail sent (gnuradio was given as example)
<plugwash> ahh gnuradio :(
<wookey> re compiler defaults. agreed. I've wanted compilers for years 
that could easily have default targets changed, but gcc design doesn;t 
really support that - you have to rebuild
<plugwash> wookey,  It's not having to rebuild that is the problem it's 
having to change the source package
<wookey> plugwash: what other than  gcc package needs to be changed?
<wookey> we could make it easier to find the bit to change in the debian 
poackaging
<wookey> or is it lots of individula packages which set compiler options 
rather than using compiler defaults?
<plugwash> there are a few packages that do override compiler defaults, 
there are also a lot of compiler source packages wooky gcc-4.6 , 
gcc-4.7, gcc.4.8, ghc, gcj-*, gdc-*, fpc, gnat-* and so-on
<plugwash> there is also the big problem that one of the gcc source 
packages builds libgcc which is a key M-A: same library so patching that 
source package causes multiarch issues
<plugwash> It would be *much* easier for us if there was one 
"compiler-defaults" source package that we could change and then just 
rebuild the compiler packages against it
<wookey> OK. But does gcc provide a place to do that? Or is it actually 
lots of different files?
<wookey> would we only be able to do it by adding debian mechanism on 
top of upstream?
<wookey> libgcc1 coming from gcc source package (and not easily 
buildable seaparately) is indeed annoying.
<wookey> there is support for a 'reverse cross' build of just libgcc in 
the packaging (as emdebian uses/used it)
<wookey> If you can work out how to provide such a package I'd certainly 
support adopting it. I'll add this to the crosscompiler agenda notes
* sandeepparitala (~sandeep at 122.252.228.137) has joined #debian-arm
<plugwash> for gcc variants at least the compiler defaults are already 
set by the debian packaging we don't patch any upstream files, it would 
just be a matter of having the debian packaging read them from somewhere 
rather than hardcoding them. For some other compilers it would be 
tricker but worst case we make them look at the gcc defaults and 
translate them somehow. Other compilers are less important too because 
of generally slower release cycles and lack of t
<plugwash> he libgcc problem.
<plugwash> 
http://debdiffs.raspbian.org/main/g/gcc-4.8/gcc-4.8_4.8.0-7+rpi1.debdiff 
shows what we currently have to do to a gcc package