Arm bof and raspbian.
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@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
Reply to: