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. > > 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 toolchain and glibc. It's very easy to say that you want to keep port upstream but much 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. > > 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. 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 require 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 all > > 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 this > > is true for the others that you are counting to the second group. I think > > 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/db3e33dd8bd956f165436afdbdbf1c653fb3c8e6 > > [3]: > https://github.com/torvalds/linux/commit/9471f1f2f50282b9e8f59198ec6bb738b4ccc009 > > [4]: > https://lore.kernel.org/linux-ia64/20230912060801.95533-1-bg...@linux.ibm.com/T/#t > > Can't all these be attributed to the second group? No, that's individual maintainers fixing individual minor issues. Maintenance 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 areas 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: linux-i...@vger.kernel.org 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 things more complicated due to the intricacies of the architecture that require extra 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 reason why Ruby, OpenJDK and LLVM dropped support for Itanium and I expect more projects 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 point to put this additional burden on upstream maintainers just to be able to compile packages on Debian. In the end, it still boils down to me taking care of all the buildds and the 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/tree/MAINTAINERS#n9936 > [2] > https://github.com/ruby/ruby/commit/d17344cfc56edc4599252041b3ec0d46af0851fd -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
