Thorsten,
Geert Uytterhoeven dixit:
I second that. In general, I would say that bootloaders don't matter that much
(to have in the official Debian archives).
Even then, bugtracking is an issue. And, for arch:any packages,
automated builds for e.g. amd64.
Launchpad could provide the former. Maybe even the latter, if
we ask nicely. If there is no disagreement about that, I guess
I’ll ask by the end of the month.
Regarding bug tracking, I fully support your proposal to ask LP for help
with a solution.
I fear I don't get your point about arch: any packages and automated
builds. What exactly is the problem?
For all of you that have followed linux-m68k, you will have seen a huge
amount of activity related to merging coldfire MMU and generic MMU code
on the kernel side. As far as the userland side is concerned, I remember
TLS support being suggested as solution to support generic m68k and
coldfire binaries. Your work on TLS would mean that is at least withing
reach now?
As for setting up autobuilders using sbuild and buildd - while I am sure
that can be done both on emulated hardware and real hardware, the core
problem for bootstrapping a port with a huge lot of the archive unbuilt
is the build database. By far the most annoying thing about buildd used
to be packages failing to build because the build dependencies were
uninstallable. Finding out which build dependency was at fault was a
time consuming manual process that could only be carried out post-mortem
on an idle autobuilder. Sorting of build priorities based on
availability of depencencies was suggested as a solution to this
problem, but as long as I has to do with autobuilders this was never
solved.
Unless that problem is tackled I don't see much point in setting up
autobuilders. I don't have a clear solution in mind - ideally the build
database host would have to check whether all build dependencies can be
satisfied before placing a package in the needs-build state, and log the
correct dependencies as conditionals for the dep-wait state otherwise.
That way, packages should only fail to install their build dependencies
if the actual buildd chroot is not sufficiently clean (handling of that
could be improved by doing a dry-run install of all build dependencies
by buildd before the real thing).
Keeping an up-to-date baseline package list for the build chroots is a
crucial requirement for all the above, of course. We even could get the
existing hosted m68k hardware (crest and kullervo) back up and running
once a streamlined build database is available. But these autobuilders
need somebody to inspect build logs, sign package uploads and such.
Without these things in place, sorting out real build failures (source
or toolchain related) from avoidable chaff is just too much of a
distraction for me to consider at this time. (My boss is overseas on
research leave, adding to my workload, and I'm facing a complex lab
remodeling including moving a bunch of highly sensitive equipment early
next year. Planning ought to have started at least a year ago for this.
Go figure! This time next year is the earliest I can look at spending
time on m68k autobuilding.)
For the present, trying to keep up with Geert's pace of kernel releases
and merging my Atari patches is all I can cope with, sorry.
Cheers,
Michael
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
