[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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@ 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: