[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

Hi Anders,

Thanks for your work on this.

Anders Kaseorg wrote:

> Now that Git is out, I propose we build git-core 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

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.

> 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,

Reply to: