Just FYI to close this thread. In an attempt to duplicate the problem on a G4 Cube, I noticed that there were no issues with "apt-get upgrade" followed by "apt-get dist-upgrade". So I just copied the Cube's rootfs to the G4 PowerMac MDD, configured the hostname and network, restored the correct SMP kernel and modules, and everything is working.
-Stan ----- On 1/22/24 8:24 AM, Stan Johnson wrote: > Hi Adrian, > > Please see the last paragrraph of the message; it may provide a clue for > ppc (and probably ppc64). > > Mr. Simon McVittie seems to be saying that debian-devel isn't the right > place for these kinds of issues, since Debian 8 was the last supported > version of Debian for ppc. Perhaps the bug report he submitted will > address the problem. > > -Stan > > -------- Forwarded Message -------- > Subject: Re: X-Windows on PPC in Debian SID > Resent-Date: Mon, 22 Jan 2024 10:49:25 +0000 (UTC) > Resent-From: debian-de...@lists.debian.org > Date: Mon, 22 Jan 2024 10:49:01 +0000 > From: Simon McVittie <s...@debian.org> > To: debian-de...@lists.debian.org > > On Sun, 21 Jan 2024 at 17:14:11 -0700, Stan Johnson wrote: >> The bottom line is that there appears to be a dependency issue in Debian >> SID at the moment > > You can't *necessarily* draw this conclusion from a failure to > upgrade. You are using powerpc, which is a "ports" architecture that is > not really part of the Debian release process any more: > > The last supported release for 32-bit PowerPC is Debian 8 ("jessie"). > — https://www.debian.org/ports/powerpc/ > > For reference, Debian 8 "jessie" reached end-of-life in 2018. > > powerpc enthusiasts continue to compile packages from the unstable (sid) > rolling release on powerpc, but "ports" architectures are not supported by > the Debian project as a whole. The mailing list for the big-endian powerpc > and ppc64 ports (and the little-endian ppc64el architecture, which *is* > supported) is debian-powerpc. > > It is common for potentially large categories of packages to be temporarily > uninstallable in unstable, particularly in "ports" architectures, and you > cannot expect upgrades to go smoothly at all times. I would personally > suggest using an interactive apt user interface like aptitude to get a > better idea of what depends on what and why. > >> that makes wdm (and other X-Windows packages such as >> the Xorg server) dependent on systemd, even if systemd is already >> installed, regardless of whether systemd is being used as the init > > systemd is the default init system in Debian, and also provides the > default implementation of several other important systemd services > like logind. If you have chosen not to use systemd, you can expect > that you will have to take steps to select other non-default packages > (for example dbus-x11 instead of dbus-user-session, and libpam-elogind > instead of libpam-systemd). apt will not necessarily be able to do this > automatically. > > Trying this on amd64, it appears that the problem you encountering is > probably that libelogind, elogind's partial replacement for libsystemd, > does not appear to provide all of the functions required by the current > versions of important packages like procps: procps currently requires > libsystemd0 (>= 254), and libelogind only provides a replacement for > version 252. I've reported this libelogind limitation as a bug in > elogind. > > smcv >