Re: Arm bof and raspbian.
+++ peter green [2013-08-16 11:53 +0100]:
[Answering the other half of this mail:]
> 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.
I don't think this is an easy matter, but it does deserve
consideration. I'll talk to doko some more, and reply in the thread
you already started.
> 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?
This is a general debian problem, which affects all sorts of people in
different ways, and derivative distros (that try to track unstable),
in the way you describe. We had several sessions on derivative
distributions at this debconf, and it was a pity that no-one from
rasbian was able to participate in those to discuss these things in
person. There are no easy solutions to this issue, but debian is very
keen to get feedback from derivatives on what we can do, and has set
up channels (pabs derivatives outreach work).
For me at least some specific examples of the sorts of problems you
are seeing would be helpful. Getting individual maintainers to think beyond
debian about transitions is something that will take a while to
change, and needs feedback to keep it in their heads.
> 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.
gcc experts with any spare cycles are in short supply :-) We did have
some useful disussions in yesterday's various BOFs, and during the
week which are somewhat relevant (about supporting mingw, arm-none and
linux cross-compilers in the archive, as well as having co-installable
native compilers), which helps find out who knows what and spread
knowledge. doko is pretty-much full already, but is amenable to
merging sensible support for whatever is needed, so long as someone
else does the basic work. The debian-toolchain list exists for collecting
gcc-releated expertise, and I guess we should use it more. <fx: wookey
checks he is subscribed>
>
> 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.
https://wiki.debconf.org/wiki/Miniconf-UK/2013
This would be a great place to discuss these matters further.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: