Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain <fthain@linux-m68k.org>]

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:

> > Then don't leave it to chance.
> 
> What is supposed to mean? Are you implying that I never tried to address 
> this?
> 

Obviously, it means I'm not interested in your estimation of the chances 
of rejection. But you're still trying to twist my words into a slur. How 
tiresome.

Again, I'd like to see an actual example of upstream developers rejecting 
patches that improve portability of data structures to m68k (and to 16-bit 
systems).

> Did you have a try at fixing any of these?
> 

Would you like me to stop fixing bugs that users actually report, in order 
to fix bugs that only distros complain about?

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

Again, the real problem faced by Debian/m68k and Gentoo/m68k is a shortage 
of manpower. This is not a new problem.

An ABI change will not fix this problem though I do conceed that a 
different ABI could improve the distro's package archive statistics, for 
all that's worth.

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

No, you're not really interested in progress. There's nothing particularly 
novel about running bloated packages in fast emulators.

And yet, I do agree that actual progress would require a new ABI, and 
you've even heard me say so before though you appear to have forgotten. 
https://lists.debian.org/debian-68k/2023/08/msg00023.html

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

If LLVM developers say that their software is inappropriate for an ABI 
that does not have 4-byte minimal alignment (citation needed) then I'd 
accept their judgement on that.

And when I want to run LLVM and its reverse deps on my m68k systems, I'll 
run them under NetBSD/mac68k.

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

Then don't work on it.

My Gentoo/x86 laptop installation is now twenty one years old, is 
up-to-date, and has never had LLVM installed on it. Nor do I miss it.

nippy portage # wc -l /var/log/emerge.log 
409801 /var/log/emerge.log
nippy portage # head /var/log/emerge.log
1063261888: Started emerge on: Sep 11, 2003 06:31:27
1063261888:  *** emerge  >=sys-apps/portage-2.0.25
1063261888:  >>> emerge (1 of 1) sys-apps/portage-2.0.49-r4 to /
1063261888:  === (1 of 1) Cleaning (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261888:  === (1 of 1) Compiling/Merging (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261911:  === (1 of 1) Post-Build Cleaning (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261911:  ::: completed emerge (1 of 1) sys-apps/portage-2.0.49-r4 to /
1063261911:  *** Finished. Cleaning up...
1063261911:  *** exiting successfully.
1063261911:  *** terminating.

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

I'm keen to see where the python requirements were changed. I wasn't able 
to find that document on python.org.

If you don't want to port python 3.13 to m68k that's okay with me. And if 
you're unwilling to port any packages to any quirky architectures, that's 
okay with me too.

But if you still claim that upstream developers require certain alignment 
rules, then you still have to provide evidence for that. Despite all of my 
requests for that evidence, none has been offered.