Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 9:13 PM, peter green <plugwash@p10link.net> wrote:
> Luke Kenneth Casson Leighton wrote:
>>
>> there was a post on the arm-netbook mailing list about a 7W quad-core
>> tegra3-based mini ITX motherboard which could take up to 2gb of RAM.
>> whether it's the usual
>> "let's-put-something-out-there-see-if-anyone-is-actually-interested"
>> style of vapourware or actual reality i'd strongly suggest someone
>> gets onto them and considers putting together a group buy / bulk order
>> just to make it worthwhile their time making a batch, because it's
>> literally the first ARM-based machine i've ever heard about that can
>> actually take 2gb of RAM.
>>
>
> The dell copper machines can supposedly take 8gb per node. Of course when
> they will be available and how much they will cost is anyones guess at this
> point.
... yeh, exactly. whereas kontron's tegra3 motherboards appear, if
you take their advertisement as being honest and at face value, to be
available now. 2gb of RAM is just enough, i've found from experience,
to be able to do debug builds of e.g. webkitgtk or webkitefl (not at
the same time!). that linker phase is 1.4 gb resident RAM required,
increasing to 1.6gb briefly towards the end, for the last minute or
so.
>> (*1) and if someone _really_ wants a debug build of that particular
>> problematic package, on a build and distro port that's still
>> experimental, well, surely they can compile it themselves, using their
>> own resources, yes?
>>
>
> Painful as it is to build them I think we do need the debug symbols for
> things
> like webkit. Without them any bug reports will be basically useless.
ok, so consider this process/procedure, tell me if you see any
fundamental flaws:
* maintainer (whoever) happily spends 18 hours of their personal
machine's life doing manual builds, once in a while. maybe once a
month even.
* build system creates debug-stripped automated (daily?) packages,
churns them out regularly.
* user downloads debug-stripped package, installs, gets on with it, then...
* splat, bug, reports problem, stacktrace is completely useless
* maintainer asks "please download from my home directory a
debug-build i did last {insert manual delay time, week, day, month}
and try again".
or, heck, even the (painful) debug builds could be done automated
using buildd, just once a week/month and kept in a separate
location/server/repository for now. you could even rotate the pain
somewhat by scheduling all of the over-bloated packages to be built
less often but only one being done at any one time, so that they don't
interfere with the building of everything else.
if that truly does become problematic on a per-package basis - large
number of bugreports - then you could always just put that problematic
package back into "hammering the build machines" mode.
/peace.
l.
Reply to: