Re: Willing to test IA64 builds of Debian and kernel with other distributions if needed

Hello!

On Thu, 2023-09-28 at 08:15 +0200, Frank Scheiner wrote:
> > You're talking about the kernel here only though and not the toolchain
> > or glibc.
>=20
> IIUC the kernel is the key, w/o support for ia64 in the kernel the
> remainder is not needed and will drop support, too. Tackling everything
> at once seems futile, tackling one at a time could make the difference.
> And to make it work we have take care of the kernel first.

That doesn't mean you will easily find someone to take care of the toolchai=
n
and glibc. It's very easy to say that you want to keep port upstream but mu=
ch
harder to do the actual work.

> > In glibc, for example, many of the tests are failing [1] with
> > one of the glibc upstream maintainers telling me there is zero chance
> > these issues are going to be fixed.
>=20
> I went through a lot of logs starting in 2018 (always taking the highest
> release version of the different minor versions with tests enabled) and
> the pass rate is actually better now - although by a small number - not
> worse than in 2018 (see attached file). It's touching 96 % PASS rate for
> 2.38-3.
>=20
> And it could be a good idea to check the details of the tests failing,
> as for example hppa has 78 enabled tests less than ia64 for this
> version. Maybe a specific portion of the 185 tests failing of 4424 + 185
> tests enabled (leaving aside XFAIL and XPASS) for ia64 are (just)
> unsupported.

Well, I talked to Adhemerval from glibc upstream regarding this and he said=
 there
is no chance that these issues are going to be fixed because that would req=
uire a
lot of work due to a potential ABI breakage. You would need to find a glibc=
 expert
to fix the math failures.

> > Do we just want to ignore these forever and just build glibc manually a=
ll
> > the time with the testsuite disabled?
>=20
> See further above, one at a time.
>=20
> > > If I interpret it correctly there seem to be two distinct groups of
> > > upstream developers in this regard: the ones that have to work on ia6=
4
> > > as part of their work area and want it gone loudly and the ones that
> > > just work on ia64 as part of their work area and keep going.
> > >=20
> > > The people here (You for sure, Pedro, Dimitri, me and maybe Mike, too
> > > and maybe others, too) and there (Tomas) would surely like to work wi=
th
> > > both of them to keep ia64 going. Together we have the machines **and*=
*
> > > the expertise.
> >=20
> > I'm not doing any relevant ia64 upstream maintenance and I don't think =
this
> > is true for the others that you are counting to the second group. I thi=
nk
> > it would be dishonest to claim that anyone in this group is doing actua=
l
> > maintenance at the moment.
>=20
> Strong words, looks like we've come to the bottom of it.
>=20
> But is it not maintenance when the second group's changes touch ia64 and
> so they adapt ia64 at the same time?
>=20
> Was [2] not maintenance? And was [3] not also maintenance? And is [4]
> not maintenance?
>=20
> [2]:
> https://github.com/torvalds/linux/commit/db3e33dd8bd956f165436afdbdbf1c65=
3fb3c8e6
>=20
> [3]:
> https://github.com/torvalds/linux/commit/9471f1f2f50282b9e8f59198ec6bb738=
b4ccc009
>=20
> [4]:
> https://lore.kernel.org/linux-ia64/[email protected]=
.com/T/#t
>=20
> Can't all these be attributed to the second group?

No, that's individual maintainers fixing individual minor issues. Maintenan=
ce means
you have a person dedicated to take care of a certain piece of code making =
sure it
continues to function and that will also keep the APIs updated when other a=
reas of
the code get changed.

Being a maintainer needs a lot of dedication. Testing the kernel from time =
to time
and reporting bugs is not really maintenance.

> Maybe a detailed look at `git log` for the last two years can shed some
> light on the actual details.

It's enough to check the status of the MAINTAINERS file [1]:

IA64 (Itanium) PLATFORM
L:	[email protected]
S:	Orphan
F:	Documentation/arch/ia64/
F:	arch/ia64/

> Or maybe you didn't understand what I meant with "Together we have the
> machines **and** the expertise."? Do you presume that the first group
> doesn't want to work with us even with a maintainer in place? The very
> first argument of Ard in [5] and [6] was that there's no maintainer for
> ia64.

No, the core argument that multiple people brought up is that ia64 makes th=
ings
more complicated due to the intricacies of the architecture that require ex=
tra
kludges which make the code more complex and harder to refactor.

And this isn't just in the kernel, this affects all projects. This is the r=
eason
why Ruby, OpenJDK and LLVM dropped support for Itanium and I expect more pr=
ojects
to follow suit. Other architectures like m68k or sparc64 don't require such=
 extra
kludges, they just work with the generic architecture support in Ruby.

And, I'm sorry, I have to admit that I must agree with Ard. There is no poi=
nt to
put this additional burden on upstream maintainers just to be able to compi=
le packages
on Debian.

In the end, it still boils down to me taking care of all the buildds and th=
e packages
and making sure that ia64 doesn't fall behind. And I have to admit that it'=
s becoming
exhausting having to do that all on my own.

I tried getting Ruby fixed again on ia64 because that blocks a lot of other=
 packages but
eventually gave up because the changes [2] are just too huge to adopt them =
to Ruby 3.x.

Adrian

> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr=
ee/MAINTAINERS#n9936
> [2] https://github.com/ruby/ruby/commit/d17344cfc56edc4599252041b3ec0d46a=
f0851fd

--=20
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913