stupid question ..... Linux raspberrypi 6.0.0-rc1-v8+ #2 SMP PREEMPT Fri Aug 19 14:48:09 CEST 2022 aarch64 GNU/Linux I am using gnome on a raspberrypi4 8GB ram (arm64) without problems. Will this removal affect me ?
On Thu, Aug 25, 2022 at 12:21 PM Simon McVittie <s...@debian.org> wrote: > Package: rele...@debian.org > Severity: normal > User: release.debian....@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-...@lists.debian.org, > debian-gtk-gn...@lists.debian.org > > The plan is for Debian 12 to release with GNOME 43, which is currently in > beta upstream. Beta versions of individual GNOME 43 packages are gradually > making their way into either unstable if they are not disruptive, or > experimental if they are. One of the new packages we need is an update > to gjs, GNOME's JavaScript environment, which depends on mozjs102 > (Spidermonkey), the latest stable-branch of Mozilla's JavaScript engine. > > mozjs102 makes more use of atomic operations, which are available on > all architectures except for armel (because armel is ARMv5, and useful > atomics are ARMv6 or ARMv7 instructions). This has led to a few different > failure modes when building mozjs102 on armel (#1017979, #1017961). > Even if we can solve them eventually, I think delaying GNOME 43 for the > benefit of machines that are not powerful enough to run GNOME would be > doing a disservice to our users. > > So I think we need to be looking at the possibility of doing > architecture-specific removals of gjs and dependent packages from armel. > Based on prior experience of similar architecture-specific removals from > s390x when mozjs was compiling-but-broken on that architecture, I think > this would involve: > > - removing gjs > - removing gnome-shell (and its extensions) > - removing gdm3 > - either hacking gnome-panel to be able to compile without gdm3, or > removing it > - either hacking meta-gnome3 to install a non-GNOME display manager and > the GNOME Flashback desktop environment (basically a GNOME 2 fork) > instead of real GNOME, or leaving it unmodified but accepting that > gnome-core and therefore task-gnome-desktop are uninstallable on armel > - disabling a subset of unit tests in src:ostree (which want gjs) > - removing leaf apps written in JavaScript, such as polari > > Obviously that's quite a bit of churn, mostly in packages that, in > practice, have never been useful to run on the 2009-2010 plug computers > that seem to be the main use-case for armel. > > Is armel a realistic candidate for being a Debian 12 release > architecture? It's already lacking other important packages like Firefox, > and if it ceased to be treated as a release architecture very soon, > then we wouldn't have to do all this work to coax GNOME into testing > despite armel. > > Or, failing that, is it still the release team's position that all task > packages are required to be installable on all architectures, and that it > is preferable to have a task install the wrong things rather than have > it be uninstallable? If we could have task-gnome-desktop and gnome-core > just be uninstallable on armel, and have the testing machinery accept > and ignore that, then that would seem more honest than having to modify > them like we did for s390x[1]. > > As with my previous work on mozjs + s390x, it is worth noting that I > am not an ARM porter or an ARM desktop user, my only armel machine is > no longer supported as of Debian 11 and was never able to run GNOME > in any case, and I have no special knowledge of mozjs. However, the > release-architecture constraints demand that someone sorts this out > before we can have a new GNOME release in testing, and I am someone, so > I'm doing my best. Anyone with useful knowledge of these architectures > and packages is very welcome to help! > > Thanks, > smcv > > [1] https://lists.debian.org/debian-release/2018/12/msg00287.html > >
