El sáb, 11-06-2011 a las 17:54 +0900, Charles Plessy escribió:
Le Tue, Jun 07, 2011 at 10:10:17PM -0500, Ruben Molina a écrit :
> > El mar, 07-06-2011 a las 22:37 +0900, Charles Plessy escribió:
> > > Le Tue, Jun 07, 2011 at 08:24:30AM -0500, Ruben Molina a écrit :
> > > >
> > > as I sponsored you in the past I can have a look at your package,
but why don't
> > > you use the VCS where it was stored anymore ? It would help to
review your
> >
> > As the package is no longer maintained by a team, I just stopped
using
> > the VCS some time ago.
> >
> > Of course, I will update it if this helps you to review the changes,
but
>
> it is your choice to drop the VCS, but consider that later you may
want
> co-maintainers, so keeping come continuity there may help. Also,
having a
> serie of thematic commits instead of a large debdiff helps to review
the
> package for upload.
>
Sure, especially in fully reworked packages like this one.
I will try to update the VCS, I belive I just need to get familiar with
it a little more.
By the way, why don't you try to become DM ?
>
I will probably do it in the next weeks.
About the update of john, I see that you drop a large number of patches,
and it
> is quite difficult for me to evaluate this. In particular, what
blocks me is
> the removal of the patches that fixed FTBFS on mips. Unfortunately,
the only
> porter box listed on db.debian.org, gabrielli, is unreachable as I
write these
> lines. But still, using the buildds for testing builds is better to
be avoided
> since failures consume their admin's time.
>
I assume your are talking about "05-mipsel.patch" which defines a couple
of new targets in Makefile: linux-mips and linux-mipsel, and provides
some *.h files for them.
Well, there is no rule in debian/rules using those targets, therefore
mips and mipsel are build using a generic target (Please take a look at
the latest available build logs, we are using generic).
If it is not really needed, why 1.6-40.2 FTBFS and 1.6-40.3 builds fine?
For the 'generic' target some benchmarks are used in order to select the
fastest algorithms at build time.
* For the remaining compilation targets, benchmark is not needed,
because we already know the most convenient algorithm for the arch.
* In 1.6-40.* the only compilation targets used were i386 and
alpha.
* There was a bug report (#420980) for 1.6-40.1 about a FTBFS (it
is not clear if all the supported archs were at FTBFS or just ones).
* A new revision (1.6-40.2) was released replacing CLK_TCK by
CLOCKS_PER_SEC
* This new revision still FTBFS in all but i386 and alpha (the bug
was located in the benchmark routine, so, optimized targets were not
affected)
* A new revision (1.6-40.3) was released reverting into 1.6-40.1
and including two different patches:
* The first one uses a different approximation to solve #420980
(Ubuntu's sysconf-based patch).
* The second one is the mips* one which defines a new
target for mips* but does not uses it at debian/rules
* At this stage the FTBFS was solved, but, as the mips*
targets were never used in the debian/rules, I believe they were not
really neeed, and the bug was really solved by the first patch
* Finally, upstream rewrites parts of the benchmark function in
1.7.x.
*
AFAICT the mips.diff was never used. Even if it was useful in order to
solve the bug in mips*, a more generic approach was needed for the
remaining targets, and it was indeed provided by the sysconf-based
patch.
Moreover, the changelog for 1.7.2-1 list some few patches (mips* not
included) and then says:
all other old patches have been kept (but not applied at build-time) for
future reference.
* And then, in 1.7.3.1-1 it is (accidentally?) re-applied as
05-mipsel.patch
I do believe it is not needed at all, but I can be wrong.
Can you ask on the debian-mips mailing list if somebody can test the
build of
> your package that is on mentors.debian.org ?
>
Of course.
I will ask them.
Thank you very much!
Best regards,
Ruben
Attachment:
signature.asc
Description: This is a digitally signed message part