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

Frank Scheiner <[email protected]> Thu, 28 Sep 2023 08:15:52 +0200
Newsgroups gmane.linux.debian.ports.ia64
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------OjPtlmAX25ob3tsUScXKWS0l
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello Adrian,

On 27.09.23 21:57, John Paul Adrian Glaubitz wrote:
> On Wed, 2023-09-27 at 21:15 +0200, Frank Scheiner wrote:
>> Again for Linux, Linus had a different opinion back in February and als=
o
>> backed that with information provided by `git log [...]`:
>>
>> ```
>> [...]
>>
>> IOW, I'm more worried about "ia64 makes it a pain to make _generic_
>> changes".
>>
>> IOW, doing something like this:
>>
>>       git log -p --no-merges --since=3D1.year arch/ia64/
>>
>> to see what kind of pain ia64 parts of patches have caused, about a
>> third of them are that "look, somebody cared about ia64 explicitly".
>>
>> And then the rest are trivial fixups for generic changes that aren't
>> any different from any other architecture. The only half-way
>> complicated one is the SET_FS removal, and I don't think it was any
>> worse than most other architectures.
>>
>> IOW, it doesn't look like ia64 causes any huge issues _per_se_. I
>> suspect alpha continues to be more of a pain.
>>
>> That said, it's entirely possible I've missed some particular painpoint=
.
>>
>> But when it's actively known to be broken and nobody has time or
>> interest to look at it, at that point the "it doesn't look any more
>> painful than other architectures" becomes kind of moot.
>> ```
>
> You're talking about the kernel here only though and not the toolchain
> or glibc.

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.

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

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.

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.

> Do we just want to ignore these forever and just build glibc manually al=
l
> the time with the testsuite disabled?

See further above, one at a time.

>> 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 ia64
>> 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.
>>
>> 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 with
>> both of them to keep ia64 going. Together we have the machines **and**
>> the expertise.
>
> I'm not doing any relevant ia64 upstream maintenance and I don't think t=
his
> is true for the others that you are counting to the second group. I thin=
k
> it would be dishonest to claim that anyone in this group is doing actual
> maintenance at the moment.

Strong words, looks like we've come to the bottom of it.

But is it not maintenance when the second group's changes touch ia64 and
so they adapt ia64 at the same time?

Was [2] not maintenance? And was [3] not also maintenance? And is [4]
not maintenance?

[2]:
https://github.com/torvalds/linux/commit/db3e33dd8bd956f165436afdbdbf1c653=
fb3c8e6

[3]:
https://github.com/torvalds/linux/commit/9471f1f2f50282b9e8f59198ec6bb738b=
4ccc009

[4]:
https://lore.kernel.org/linux-ia64/[email protected].=
com/T/#t

Can't all these be attributed to the second group?

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

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.

[5]: https://lore.kernel.org/all/[email protected]/

[6]:
https://lore.kernel.org/linux-ia64/[email protected]=
g/

Cheers,
Frank

>> [1] https://buildd.debian.org/status/fetch.php?pkg=3Dglibc&arch=3Dia64&=
ver=3D2.38-3&stamp=3D1694223476&raw=3D0

--------------OjPtlmAX25ob3tsUScXKWS0l
Content-Type: text/plain; charset=UTF-8; name="ia64-glibc-builds.txt"
Content-Disposition: attachment; filename="ia64-glibc-builds.txt"
Content-Transfer-Encoding: base64

aHR0cHM6Ly9idWlsZGQuZGViaWFuLm9yZy9zdGF0dXMvZmV0Y2gucGhwP3BrZz1nbGliYyZh
cmNoPWlhNjQmdmVyPTIuMzgtMyZzdGFtcD0xNjk0MjIzNDc2JnJhdz0wCgpTdW1tYXJ5IG9m
IHRlc3QgcmVzdWx0czoKICAgIDE4NSBGQUlMCiAgIDQ0MjQgUEFTUwogICAgIDY1IFVOU1VQ
UE9SVEVECiAgICAgMTggWEZBSUwKICAgICAgNiBYUEFTUwoKOTUsOTggJSBQQVNTCgpodHRw
czovL2J1aWxkZC5kZWJpYW4ub3JnL3N0YXR1cy9mZXRjaC5waHA/cGtnPWdsaWJjJmFyY2g9
aWE2NCZ2ZXI9Mi4zNy0xMCZzdGFtcD0xNjk0ODY5Mjg3JnJhdz0wCgpTdW1tYXJ5IG9mIHRl
c3QgcmVzdWx0czoKICAgIDE4NSBGQUlMCiAgIDQzODAgUEFTUwogICAgIDYzIFVOU1VQUE9S
VEVECiAgICAgMTggWEZBSUwKICAgICAgNiBYUEFTUwoKOTUsOTQgJSBQQVNTCgpodHRwczov
L2J1aWxkZC5kZWJpYW4ub3JnL3N0YXR1cy9mZXRjaC5waHA/cGtnPWdsaWJjJmFyY2g9aWE2
NCZ2ZXI9Mi4zNi05JnN0YW1wPTE2ODU5MTAxMzQmcmF3PTAKClN1bW1hcnkgb2YgdGVzdCBy
ZXN1bHRzOgogICAgMTkwIEZBSUwKICAgNDM1NyBQQVNTCiAgICAgNjIgVU5TVVBQT1JURUQK
ICAgICAxOCBYRkFJTAogICAgICA2IFhQQVNTCgo5NSw4MiAlIFBBU1MKCmh0dHBzOi8vYnVp
bGRkLmRlYmlhbi5vcmcvc3RhdHVzL2ZldGNoLnBocD9wa2c9Z2xpYmMmYXJjaD1pYTY0JnZl
cj0yLjM1LTMmc3RhbXA9MTY2NTMxNDY1NSZyYXc9MAoKU3VtbWFyeSBvZiB0ZXN0IHJlc3Vs
dHM6CiAgICAxOTggRkFJTAogICA0MzMwIFBBU1MKICAgICA1OSBVTlNVUFBPUlRFRAogICAg
IDE4IFhGQUlMCiAgICAgIDYgWFBBU1MKCjk1LDYyICUgUEFTUwoKaHR0cHM6Ly9idWlsZGQu
ZGViaWFuLm9yZy9zdGF0dXMvZmV0Y2gucGhwP3BrZz1nbGliYyZhcmNoPWlhNjQmdmVyPTIu
MzQtOCZzdGFtcD0xNjYyODU1NzgzJnJhdz0wCgpTdW1tYXJ5IG9mIHRlc3QgcmVzdWx0czoK
ICAgIDE5NyBGQUlMCiAgIDQwOTUgUEFTUwogICAgIDU1IFVOU1VQUE9SVEVECiAgICAgMTgg
WEZBSUwKICAgICAgNiBYUEFTUwoKOTUsNDEgJSBQQVNTCgpodHRwczovL2J1aWxkZC5kZWJp
YW4ub3JnL3N0YXR1cy9mZXRjaC5waHA/cGtnPWdsaWJjJmFyY2g9aWE2NCZ2ZXI9Mi4zMy04
JnN0YW1wPTE2NTc5NzQyMDgmcmF3PTAKClN1bW1hcnkgb2YgdGVzdCByZXN1bHRzOgogICAg
MTkyIEZBSUwKICAgMzk1OSBQQVNTCiAgICAgNDcgVU5TVVBQT1JURUQKICAgICAxNiBYRkFJ
TAogICAgICA3IFhQQVNTCgo5NSwzNyAlIFBBU1MKCmh0dHBzOi8vYnVpbGRkLmRlYmlhbi5v
cmcvc3RhdHVzL2ZldGNoLnBocD9wa2c9Z2xpYmMmYXJjaD1pYTY0JnZlcj0yLjMyLTUmc3Rh
bXA9MTYzODcyNTgwMyZyYXc9MAoKU3VtbWFyeSBvZiB0ZXN0IHJlc3VsdHM6CiAgICAxODYg
RkFJTAogICAzOTMxIFBBU1MKICAgICAzNCBVTlNVUFBPUlRFRAogICAgIDE3IFhGQUlMCiAg
ICAgIDcgWFBBU1MKCjk1LDQ4ICUgUEFTUwoKaHR0cHM6Ly9idWlsZGQuZGViaWFuLm9yZy9z
dGF0dXMvZmV0Y2gucGhwP3BrZz1nbGliYyZhcmNoPWlhNjQmdmVyPTIuMzEtMTcmc3RhbXA9
MTYyOTc1MzQ1MCZyYXc9MAoKU3VtbWFyeSBvZiB0ZXN0IHJlc3VsdHM6CiAgICAyNjUgRkFJ
TAogICA0NzkzIFBBU1MKICAgICAyOSBVTlNVUFBPUlRFRAogICAgIDE3IFhGQUlMCiAgICAg
IDcgWFBBU1MKCjk0LDc2ICUgUEFTUwoKaHR0cHM6Ly9idWlsZGQuZGViaWFuLm9yZy9zdGF0
dXMvZmV0Y2gucGhwP3BrZz1nbGliYyZhcmNoPWlhNjQmdmVyPTIuMzAtOCZzdGFtcD0xNTg5
NDE4NDA5JnJhdz0wCgpTdW1tYXJ5IG9mIHRlc3QgcmVzdWx0czoKICAgIDI5MCBGQUlMCiAg
IDU2MjMgUEFTUwogICAgIDMwIFVOU1VQUE9SVEVECiAgICAgMTcgWEZBSUwKICAgICAgNyBY
UEFTUwoKOTUsMDkgJSBQQVNTCgpodHRwczovL2J1aWxkZC5kZWJpYW4ub3JnL3N0YXR1cy9m
ZXRjaC5waHA/cGtnPWdsaWJjJmFyY2g9aWE2NCZ2ZXI9Mi4yOS0xMCZzdGFtcD0xNTgwODcx
OTkyJnJhdz0wCgpTdW1tYXJ5IG9mIHRlc3QgcmVzdWx0czoKICAgIDI5MCBGQUlMCiAgIDU1
MjYgUEFTUwogICAgIDIyIFVOU1VQUE9SVEVECiAgICAgMTcgWEZBSUwKICAgICAgNyBYUEFT
UwoKOTUsMDEgJSBQQVNTCgpodHRwczovL2J1aWxkZC5kZWJpYW4ub3JnL3N0YXR1cy9mZXRj
aC5waHA/cGtnPWdsaWJjJmFyY2g9aWE2NCZ2ZXI9Mi4yOC0xMCZzdGFtcD0xNTU4MjI5NzM2
JnJhdz0wCgpTdW1tYXJ5IG9mIHRlc3QgcmVzdWx0czoKICAgIDI5MCBGQUlMCiAgIDU1MDIg
UEFTUwogICAgIDIwIFVOU1VQUE9SVEVECiAgICAgMTcgWEZBSUwKICAgICAgNyBYUEFTUwoK
OTQsOTkgJSBQQVNTCgpodHRwczovL2J1aWxkZC5kZWJpYW4ub3JnL3N0YXR1cy9mZXRjaC5w
aHA/cGtnPWdsaWJjJmFyY2g9aWE2NCZ2ZXI9Mi4yNy04JnN0YW1wPTE1NDA4NTc0MTkmcmF3
PTAKClN1bW1hcnkgb2YgdGVzdCByZXN1bHRzOgogICAgMjgzIEZBSUwKICAgNTMwOCBQQVNT
CiAgICAgMTggVU5TVVBQT1JURUQKICAgICAxNiBYRkFJTAogICAgICA3IFhQQVNTCgo5NCw5
MyAlIFBBU1MKCmh0dHBzOi8vYnVpbGRkLmRlYmlhbi5vcmcvc3RhdHVzL2ZldGNoLnBocD9w
a2c9Z2xpYmMmYXJjaD1pYTY0JnZlcj0yLjI2LjkwMDAlMkIyMDE4MDEyNy43ZTIzYTdkZC0w
ZXhwZXJpbWVudGFsMCZzdGFtcD0xNTE3MTI2ODkyJnJhdz0wCgpTdW1tYXJ5IG9mIHRlc3Qg
cmVzdWx0czoKICAgIDI4NyBGQUlMCiAgIDUyOTcgUEFTUwogICAgIDE2IFVOU1VQUE9SVEVE
CiAgICAgMTYgWEZBSUwKICAgICAgNyBYUEFTUwoKOTQsODYgJSBQQVNTCg==

--------------OjPtlmAX25ob3tsUScXKWS0l--