On Mon, 2024-10-28 at 19:29 +1100, Finn Thain wrote: > On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote: > > > > > > > That seems to imply that someone requires that those packages are > > > ported. But without a bug report from such a user, to say the package > > > is broken or missing, one must question the real requirement. > > > > People have tried this in the past and it was an endless effort. It's > > not that it hasn't been tried. And there is zero chance that any of > > these projects accept such patches to support unusual alignment. > > > > Then don't leave it to chance.
What is supposed to mean? Are you implying that I never tried to address this? Did you have a try at fixing any of these? > > Why does my word not count here? It's not that this problem is new. > > > > Your opinion does not count here because the question was about upstream > patch refusals. I'm genuinely interested to see the patch reviews. After > all, many alignment patches have already been merged. Of course my opinion counts here because I am doing the majority of the work on Debian m68k these days. > Without being able to see the actual response from upstream developers, I > can only assume that they have either misunderstood the issue or they have > simply decided their users would not be served by an m68k port. Do you > agree that upstream developers generally know their users requirements > better than distros do? Again, this has been tried in the past and I'm tired of discussing this. This kind of discussion doesn't really help resolving this problem. > > You can also ask Andreas who maintained openSUSE on m68k for a while and > > had to carry lots of local patches. > > > > > If upstream QT or Java developers decide that their software is "not > > > for us", they may well have a point. Those packages are not installed > > > on my m68k systems, FWIW. > > > > This is isn't just about runtime dependencies but also build > > dependencies which is why I linked the statistics page in Debian. A lot > > of packages in Debian/m68k can currently not be built because they have > > a transitive dependency on Rust, OpenJDK, Qt, GNOME and so on. > > > > That's one reason why source distros are a better fit for small systems > than binary distros are. You can't fix this basic problem with an ABI > change. Gentoo has the same problem with Linux m68k and they want to perform the switch as well. So it's not just my personal opinion here. > > > OTOH, as I've said before, if upstream developers (like Arnd) are > > > looking ahead to 128-bit platforms then they will be paying attention > > > to alignment rules. They should be inclined to favour explicit struct > > > definitions over implicit alignment, don't you think? > > > > Debian just transitioned all of their 32-bit architectures to time64_t > > except for i386. Do you know why they did that even though 128-bit CPUs > > are practically around the corner? > > > > Perhaps they have explained their actions? Do you have an opinion? My opinion is that people expect 32-bit targets to not dissolve in thin air in 2038. The fact that i386 was not touch is simply because of the huge library of pre-compiled software for the platform which doesn't exist in that form on m68k. So that's not an argument to switch the natural alignment. > > > > I understand that this might be a painful transition, but I don't > > > > see any other way to keep the m68k port alive in the foreseeable > > > > future unless we fix this problem which keeps blocking the port. > > > > > > > > You can see how the Debian m68k port has been falling behind because > > > > of the alignment issues in these statistics: > > > > https://buildd.debian.org/stats/graph-ports-big.png > > > > > > > > > > I could imagine a viable transition to a new ABI driven by widespread > > > user demand or involvement. But not by distro stats or maintainer > > > preference. > > > > Well, I'm doing the work, so I get to make the decisions here, no? > > > > Sure. Please refer to my previous email about the m68k ABI du jour and > fragmentation. What fragmentation? The vast majority of people interested in this architecture want to progress and not keep the status quo forever. And the switch is simply inevitable which is why Chewi has pitched a proposal on this list as well. > > > Absent the right conditions, perhaps it is best focus limited porter > > > and developer effort on patching only those packages that are really > > > required. > > > > Thanks, but I tried that and it doesn't work. I don't want to continue > > spending hours on trying to figure out how to fix alignment problems and > > then maybe send an email here and there to just never get an answer. > > > > You're somehow implying that I'm requesting this change because I'm just > > lazy. > > > > You're somehow twisting my words into a slur. You know that I value your > alignment patches because I've said so before. Thanks again for your > efforts. Look, the problem is that this is a) an endless effort and b) in some cases simply not feasible. Codebases like LLVM are completely built around a natural alignment of at least four bytes and it's simply impossible to work around that. There are so many other things I would like to work on and I simply consider it a waste of time and resources to work on the same problem over and over again just because we cannot agree on finally fixing the underlying issue. As of now, Debian/m68k will miss the transition to Python 3.13 because the new version requires 4-byte alignment and absolutely no one is willing to help me fix this issue. All I'm getting is "wise" advise on the quality of "Have you tried turning it off and on again?". Endlessly frustrated, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
