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