Re: armel port status report
2008/3/4, Riku Voipio <riku.voipio@iki.fi>:
> On Tue, Mar 04, 2008 at 03:12:47PM +0000, Martin Guy wrote:
> > plus 5 that are not currently flagged to be built on arm* architectures.
> please file bugs against the respectice packages if those are mistakes.
Of course.
> > If I understand correctly, the fastest way to improve the mainline
> > armel port would be to schedule the packages for building that are
> > known to work on armel, but whose binaries are missing:
>
> Well you don't understand correctly. There is already hundreds of
> out-of-date packages scheduled for building so scheduling uncompiled
> packages is pointless until we get more buildd's. Getting more buildd's
> is also being worked on, so don't worry.
I don't see rebuilding yet another version of all the various gcc's as
being more important than building a package that is absent from the
archive.
> *FIXING* bugs and submitting patches to BTS. See ltrace as a great
> example what would be really usefull. Just listing problems or filing
> bugreports (without patchehs) does not get the port anywhere fast...
Sure. But first we should know which are the buggy packages - I have
uncovered dozens of new ones - how can we know where the most progress
can be made in the least time?
I know it seems nasty of me to list yet more broken things, if we are
trying to make everything look nice, but the alternative is hiding
problems or ignoring them, which means that they will remain broken.
In the end, I presume, what is left on that list forms the agenda of a
last-minute bug-squashing-party, so it's not pointless.
Let me explain where I personally am coming from:
I am paid a small, fixed number of working hours to increase the
likelihood of armel achieving release certification before the
deadline. When that number of hours is exhausted, I will go away again
until July.
For myself, I could happily spend all those hours fixing one small and
interesting broken package, but that would do very little as far as
certification is concerned.
At present, I can see two bulk ways of getting many package working on armel:
1) identify the packages that are missing but known to work on armel,
and prioritoze them on the buildds. Other than the lists I posted, I
have found another dozen inter-dependent packages that will build if
you build them in the right order. The next step would be to identify
all packages that are absent by a programmatic comparison of the
Sources and Packages files and the repository itself. quinn-diff
should do this, but is let down by its data file from 2003, and it
seems to have been abandoned by its maker.
2) After that, next greatest profit is to tackle the unfortunate
practice of listing Architectures in the "Binary" section of each
source packages' control file, which means that an unknown number of
packages appear to build on armel, but do not in fact produce any
binary packages (or omit some).
"Unknown", because the per-binary arch-specification does not appear
in the main Sources file, and "unfortunate" because to find them one
has to download every single source package, unpack it and examine the
debian/control file, then for the positive matches, file bugs against
the ones that have architecture lists that should include armel but
don't. Thanks to the local LUG I now have the bandwidth resources to
do that.
There may be a less automatic strategy that uses less brute force and
more eyeball-work, but I'm inclined to automate it as far as possible.
These are both lots of boring work for me, but it gets a greater
number of packages working on armel per hour than fixing one or two
difficult ones.
If there is no buildd admin who will take advantage of the info I
discover to achieve our (common!) goal - armel lenny certification,
then there is no point me attacking the first of the above two, so I
guess I will just do the second one and hope that the buildds get
round to the non-existent packages eventually. But I think the results
we achieve, as far as getting closer to lenny certification is
concerned, will be less than the maximum that we could obtain by
working together.
M
Reply to: