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.
It's not that I'm not speaking from experience having maintained the
m68k port in Debian the past 10 years. The Gentoo folks will tell you
the same.
Those are the most important projects from the tip of my head, but
they are already the biggest blockers. There is no chance that the
upstream maintainers will adjust their packages for 16-bit
alignment, so these will be forever broken on m68k if we don't
switch.
I'm curious to see such a refusal in context, presumably as a result
of patch review, in an upstream project bug tracker.
I'm not actually expecting to see good patches refused by core
projects like Python. (Note that MicroPython is available for
commercially active CPUs like the PIC16 family, which are 8-bit
processors with 16-bit address bus.)
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.
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?
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.
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?
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.
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.
