Hi Anders, Thanks for your work on this.
Anders Kaseorg wrote: > Now that Git 1.6.6.1 is out, I propose we build git-core 1.6.6.1-1 with > the patch I posted above <http://bugs.debian.org/563882#10>, which lets > the two tests in question expect to fail on ia64 only. >From the log, it looks like git read-tree is working fine, so some of the other tests that use 'git diff --no-index' might be expected to fail, too. The build log stops at t1001. Do we want to suppress t4002, t4011, t4013, t4018, t4033, and t4044 as well? No Itanium porters have arrived to help. Who would confirm then that the result was sane enough for people to use? As a user, I would rather use a v1.6.5 build that works (does it still?) than a v1.6.6 that cannot even pass the early tests in the test suite. > Then ia64 users > can have a package to test this with more easily, Given access to an ia64 to test on, I would gladly test this myself. All it takes is downloading git from http://git-scm.com or the Debian archive, running ‘make test’, and then looking around a little when it fails. I don’t think this is what autobuilders are for. If we want to use buildds instead, the thing to do would be to change '$(MAKE) $(TEST)' to '$(MAKE) -k $(TEST)' in debian/rules. Then the build fails, so we are not screwing over the Itanium users, but at least all the tests are run. > have to wait for us to find an ia64 user and convince them to care (which > we’ve all been unable to do for several weeks). Actually, we don’t need an ia64 user, just a Debian Developer. http://db.debian.org/machines.cgi?host=merulo > As far as I can tell, this test failure was triggered by some kind of > change on the buildd and is not a real regression from the version in > testing, given that it was observed with an earlier version in Ubuntu. By the way, is there a build log for this available? > The only other option I see is to disable the ia64 architecture entirely > for git-core, given that we’re effectively unable to support it. This is the right solution, unless someone out there cares. Personally, I would rather build a package from source so I can diagnose problems as they come than find myself using a version that is both untested and known not to work. Besides, even if we ignore the errors, they would constitute a grave bug that would prevent migration of git to testing, no? Just my two cents, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
