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.
