[gccsdk] ctorrent port for the autobuilder
John.Tytgat at aaug.net
Sat Mar 31 09:36:39 PDT 2007
In message <20070331154720.GB20090 at chiark.greenend.org.uk>
Theo Markettos <theo at markettos.org.uk> wrote:
> I might be willing to help out.
> Do you have an idea of which packages are in need of updating?
A nice start would be the 'cli' ones. Not maybe because they are the most
urgent ones (although you can argue that) but because they tend to be most
of the time simple and small and would allow you to get the hang of
Autobuiler itself. And of course you can immediately try out the binaries
in RISC OS.
With a 'developer' hat on, I would say the 'libraries' ones and these can
be a bit tricky. The biggest problem is that these are very dependent on
each other so the build order is important. I'm not so happy with the
current way of enforcing their dependancies (driven by the 'depends' file)
as this is rather labour intensive to keep up to date and usually very error
prone. Ideally this would be derived directly from the APT database for
those projects fetched via apt-get (that's a nice project on its own IMHO).
Other ideas to tackle the dependency issue in a better way are more than
> And is there an 'official' upstream? When the
> autobuilder grabs sources using apt, it grabs from whatever the system source
> repository is. It would make sense to standardise on an upstream... the
> trouble is that Debian 'stable' is rather old, and people doing autobuilder
> development probably want 'testing' or 'unstable' but those aren't
> necessarily good for users. Perhaps use Ubuntu? But then I'm never quite
> sure what Canonical have done to the Debian sources.
We had this discussion mid last year and settled down to 'Debian unstable'
seen we don't have enough hands to follow more than one stream. And
'unstable' would allow us to make our Autobuilder patches faster obsolete
after submitting them upstream and getting them accepted.
I plan to update 'Using GCCSDK' wiki page a bit with this info tomorrow.
> (who is also playing with a few ideas wrt making GCCSDK easier to run
> when they don't have much Linux experience)
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc