XPost: linux.debian.ports.powerpc 
 From: guillem@debian.org 
  
 Hi! 
  
 On Wed, 2025-09-03 at 22:20:43 +0200, Sebastian Andrzej Siewior wrote: 
 > On 2025-09-03 14:27:14 [+0200], John Paul Adrian Glaubitz wrote: 
 > > FWIW, LLVM still fully supports powerpcspe, so it's not actually a dead 
 > > end. There is also some interest in the community as several New Amiga 
 > > boards used PowerPCSPE-based CPUs. 
 > 
 > Interesting that new e500 based boards are made. It is probably one of 
 > the last available CPUs capable of doing 32bit powerpc. 
 > But reading Amiga I would expect m68k based CPUs not powerpc (especially 
 > this one). Color me surprised. 
 > 
 > Anyway. Realistically speaking you would need 8GiB+ of RAM for a buildd 
 > machine and you would need to boostrap the whole port probably from 
 > scratch as of today. But with llvm only. This could be a challenge 
 > already hoping you don't run into any compiler bugs as we did back then. 
 > Oh. glibc. You need a C library and glibc is probably what you want but 
 >  https://sourceware.org/git/?p=glibc.git;a=commit;h=a053e87849 
 080f7070cf92890e546057236c9c9 
 > 
 > support has been removed here, too. And kernel support but if it is 
 > p2020 based, it shouldn't be that complicated. 
  
 Ah, thanks for the correction about debian-ports (for some reason I 
 misrecalled as if it had become official at some point!), and also about 
 the gcc and glibc status. Will update the local commit where I track 
 this. 
  
 > > So, unless it's really necessary to remove it, I would suggest to keep 
 powerpcspe. 
 > 
 > This is entirely Guillem, I have obviously no saying in this. Also I 
 > don't want to take a project away from anyone. I just tried to show how 
 > much work is probably needed if anyone wants to bring this back to life. 
 > And two key projects dropped their support. 
  
 In general, as long as there's interest, and there is upstream support 
 I have no problem with keeping any architecture, regardless of its 
 official Debian status, etc. But in this case given the removals from 
 gcc and glibc, I think its current fate seems a bit sealed. Also 
 adding the arch definitions back into dpkg is probably the least of 
 the involved work if someone wanted to bring this back to life again. 
  
 About whether there's any necessity to remove architectures, yeah, we 
 could leave them around, but that also has a cost in that it is 
 confusing to expose things that are currently not viable, and that 
 people might end up trying to support and end up placing in package 
 metadata for example, or tooling. 
  
 Thanks, 
 Guillem 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)