Snow Leopard on Unsupported PowerPC Macs

[ChrisCharman]

SLPPC could not see other Macs on the same network, and the other Macs could not see SLPPC. For reference, the network is wired, not wireless, and the machines are all connected on the same subnet. It all works flawlessly under Tiger, Leopard and Snow Leopard, but not under SLPPC, which is a real shame.

File Sharing works as expected on 10A190 running on my intel MacBook test machine - this is either because of the updated binaries (particularly CUPS which you should update first) or it just isn’t broken on intel. I will test on one of the PowerPC machines later.

 

[B S Magnet]

File Sharing works as expected on 10A190 running on my intel MacBook test machine - this is either because of the updated binaries (particularly CUPS which you should update first) or it just isn’t broken on intel. I will test on one of the PowerPC machines later.View attachment 2404014

Although it’s running on Intel (and may not need nearly as many tweaks as the PowerPC deployment to be functional), I’d be curious to learn the version of IOFirewireIP.kext running on both there and on your G5 install of the same. Cheers.

 

[ChrisCharman]

Although it’s running on Intel (and may not need nearly as many tweaks as the PowerPC deployment to be functional), I’d be curious to learn the version of IOFirewireIP.kext running on both there and on your G5 install of the same. Cheers.

Hi @B S Magnet!

Just in the middle of installing an OCZ-Agility3 in one of my Quicksilvers at the moment, then will be transferring a Gigadesigns dual processor upgrade from my Digital Audio along with some other components. I will check and verify the kext later and report back.

 

[mac57mac57]

In response to the question, I took build 10A196.

However, I believe that we may be mixing problems here. The FireWire issue is with Sorbet Leopard. The Snow Leopard PPC (SLPPC) problem is AFP File Sharing.

For the SLPPC File Sharing problem, are there one or more kexts that need to be copied over from Leopard itself (or from Snow Leopard itself, if the kexts in question happen to be Universal binary) in order to enable Ethernet based AFP File Sharing, such that my SLPPC G5 can see other Macs on the LAN and also be seen by them (understanding that not every Mac can see every other Mac due to AFP version issues in some cases).

I have ANOTHER PowerMac G5, this one a G5 Quad, which I can attempt the SLPPC upgrade on. Right now this machine runs Tiger, but it doesn't get much use. It appears that it's cooling system is slowly failing; it runs much hotter than it used to, and this causes the fans to ramp up, creating a degree of noise that is loud enough to be unpleasant.

Nonetheless, it runs, it is solid, and if there is a reasonable chance that all I need to do is change out some kexts to get networking to work, I would be happy to give the SLPPC upgrade another try.

Any and all insights MUCH appreciated!

 

[B S Magnet]

Hi @B S Magnet!

Just in the middle of installing an OCZ-Agility3 in one of my Quicksilvers at the moment, then will be transferring a Gigadesigns dual processor upgrade from my Digital Audio along with some other components. I will check and verify the kext later and report back.

No worries. Absolutely no rush!

 

[B S Magnet]

In response to the question, I took build 10A196.

Could you double-check? There’s a Build 10A96 and a Build 10A190. Cheers.

However, I believe that we may be mixing problems here. The FireWire issue is with Sorbet Leopard. The Snow Leopard PPC (SLPPC) problem is AFP File Sharing.

Yah. Can’t help you with sorbet leopard on this thread.

For AFP on SL-PPC: again, check Table 4 to help get you closer.

There are some things you’ll need to move in place from a standard 10.5.8 source (not the sorbet leopard fan version). For Build 10A96, I found the following may help with that (but keep in mind there may also be something upstream of AFP serving which could be a culprit):

If you’re on 10A96, the problem may be, as @ChrisCharman noted, CUPS/cupsd (though given that pertains to a different stack — print/fax — which includes some networking elements, it probably isn’t the fix for this specifically; still, check Appendix B on links to fix CUPS and Network Time Server). If you’re on Build 10A190, you may want to double-check the version your afpfs and asp_tcp use.

Although I did paste the same version to the 10A190 column (second from right) when I created Table 4 a few years ago, check to verify the version numbers are a match on your installed build (9.0 and 4.7, respectively). If they’re not, then you may need to bring over 9.0 and 4.7 from Build 10A96, not 10.5.8.

I discovered, rather quickly, the kexts for these from 10.5.8 broke AFP. That’s why those lines are red. Red is the “leave what you have in place” marker.

For the SLPPC File Sharing problem, are there one or more kexts that need to be copied over from Leopard itself (or from Snow Leopard itself, if the kexts in question happen to be Universal binary) in order to enable Ethernet based AFP File Sharing, such that my SLPPC G5 can see other Macs on the LAN and also be seen by them (understanding that not every Mac can see every other Mac due to AFP version issues in some cases).

Generally, speaking to my use of 10A96 on a PowerBook G4, I moved over basically every kext, framework, and component highlighted in green on Table 4, as well as the blue ones (mostly pertaining to video cards). I can report I’ve never had trouble with AFP or SMB over ethernet (indeed, my specific PowerBook had a fault on the logic board preventing use of internal AirPort, so I relied entirely on ethernet for LAN stuff).

My own Build of 10A96 is, all things considered, much more stable, versus just after I installed and booted into SL-PPC for the first time. But it also meant I had to do my own testing and documentation, since no one else online had ever done so.

I have ANOTHER PowerMac G5, this one a G5 Quad, which I can attempt the SLPPC upgrade on. Right now this machine runs Tiger, but it doesn't get much use. It appears that it's cooling system is slowly failing; it runs much hotter than it used to, and this causes the fans to ramp up, creating a degree of noise that is loud enough to be unpleasant.

I believe both @barracuda156 and @ChrisCharman use SL-PPC (both with Build 10A190) on their G5s, and I believe at least one of them had the quad G5. (I have an older, mid-2004 DP 2.0, yet since it has 24/7 file serving duty at home, I’ve never tried out any flavour of SL-PPC on it.)

Nonetheless, it runs, it is solid, and if there is a reasonable chance that all I need to do is change out some kexts to get networking to work, I would be happy to give the SLPPC upgrade another try.

That’s the spirit!

Any and all insights MUCH appreciated!

I’m offering what I know here Hopefully some other folks can chime in to assist, especially once we’ve verified whether you’re on 10A96 or 10A190. We know you’re on an A1117 G5, it sounds like, so that’s helpful info.

 

[barracuda156]

File Sharing works as expected on 10A190 running on my intel MacBook test machine - this is either because of the updated binaries (particularly CUPS which you should update first) or it just isn’t broken on intel. I will test on one of the PowerPC machines later.View attachment 2404014

I did not tweak anything in the 10a190 on i386, and I did not see the machine on a local network, as far as I recall. Won’t bet money on that now, need to check.

Great to know it can work!

 

[barracuda156]

In response to the question, I took build 10A196.

However, I believe that we may be mixing problems here. The FireWire issue is with Sorbet Leopard. The Snow Leopard PPC (SLPPC) problem is AFP File Sharing.

For the SLPPC File Sharing problem, are there one or more kexts that need to be copied over from Leopard itself (or from Snow Leopard itself, if the kexts in question happen to be Universal binary) in order to enable Ethernet based AFP File Sharing, such that my SLPPC G5 can see other Macs on the LAN and also be seen by them (understanding that not every Mac can see every other Mac due to AFP version issues in some cases).

I have ANOTHER PowerMac G5, this one a G5 Quad, which I can attempt the SLPPC upgrade on. Right now this machine runs Tiger, but it doesn't get much use. It appears that it's cooling system is slowly failing; it runs much hotter than it used to, and this causes the fans to ramp up, creating a degree of noise that is loud enough to be unpleasant.

Nonetheless, it runs, it is solid, and if there is a reasonable chance that all I need to do is change out some kexts to get networking to work, I would be happy to give the SLPPC upgrade another try.

Any and all insights MUCH appreciated!

Don’t waste the Quad on Tiger LOL
It deserves better.

Unless you plan to build stuff for ppc64 (in which case SL-PPC is not an option), with 10.6 you gonna have a newer software and something like 10k+ prebuilt ports

 

[B S Magnet]

with 10.6 you gonna have a newer software and something like 10k+ prebuilt ports

* so long as one uses Build 10A190.

 

[ChrisCharman]

Hi all! I'm half-way through upgrading the Quicksilver; currently sporting Dual 1.33ghz 7455 with 2mb L3 cache, a Belkin PCI USB 2.0 card, a 120GB OCZ Agility 3 SSD connected via a PATA to SATA bridge adapter, 2 x SATA HDDs for storage connected to a Highpoint PCI SATA Card, 1.5GB SDRAM, DVDRW...and a Geforce2...until the 7800GS is Flashed properly for the second G5 PowerMac at which point i can move over the X800XT.

Suffice it to say that this has taken me a bit more than few hours today, particularly with fresh software installs, so i've not had much time to delve into the File Sharing issues.

That being said, as this system will be another SL_PPC test system (to add to the 2 x iBooks, 2 x Powerbooks, PowerMac G4 Digital Audio, 1 x AGP PMG5, 1 x PCIe G5 and intel MacBook systems i currently use for this project) I have imaged over a fresh 10A190 and applied ONLY the CUPS fix i suggested above. The system is detected now and Screen Sharing works correctly, as well as software update, the Firewall preference pane etc.

File Sharing looks like it requires some more tinkering...when i get a chance i'll see if the results differ on the more modified of my systems.

EDIT:

Thought i’d try one last thing before going to bed. Unchecked afp and selected only smb file sharing and low and behold…

SMB File Sharing fully working on 10A190 replacing only the CUPS binaries detailed earlier in the thread and linked in the wikipost.

 

[B S Magnet]

Hi all! I'm half-way through upgrading the Quicksilver; currently sporting Dual 1.33ghz 7455 with 2mb L3 cache, a Belkin PCI USB 2.0 card, a 120GB OCZ Agility 3 SSD connected via a PATA to SATA bridge adapter, 2 x SATA HDDs for storage connected to a Highpoint PCI SATA Card, 1.5GB SDRAM, DVDRW...and a Geforce2...until the 7800GS is Flashed properly for the second G5 PowerMac at which point i can move over the X800XT.

Suffice it to say that this has taken me a bit more than few hours today, particularly with fresh software installs, so i've not had much time to delve into the File Sharing issues.

That being said, as this system will be another SL_PPC test system (to add to the 2 x iBooks, 2 x Powerbooks, PowerMac G4 Digital Audio, 1 x AGP PMG5, 1 x PCIe G5 and intel MacBook systems i currently use for this project) I have imaged over a fresh 10A190 and applied ONLY the CUPS fix i suggested above. The system is detected now and Screen Sharing works correctly, as well as software update, the Firewall preference pane etc.

File Sharing looks like it requires some more tinkering...when i get a chance i'll see if the results differ on the more modified of my systems.

EDIT:

Thought i’d try one last thing before going to bed. Unchecked afp and selected only smb file sharing and low and behold…

View attachment 2404185

SMB File Sharing fully working on 10A190 replacing only the CUPS binaries detailed earlier in the thread and linked in the wikipost.

View attachment 2404187

NINE machines?! 🤯

You may win grand prize of, well, the world here, of running and testing SL-PPC concurrently on so many variations. I feel like a total dilettante with just the one I’ve used for all my testing. Yours is, certainly, a far more rounded assessment and experience of spotting inter-system quirks with 10A190. That’s outstanding work.

 

[barracuda156]

* so long as one uses Build 10A190.

I do not know a reason why it would not work on any other one in general case. It may not be optimal for 10.6.8 for a few reasons, but should still work. It is likely to work on 10A96, which is behind 10A190, so fallbacks should work exactly the same way.

P. S. Nothing prevents you from trying: MacPorts software tarballs reproduce the structure of a final install, so you do not actually require MacPorts, as long as you have time to move everything in place by hand. Extract any software, put into /opt/local and whats not, do the same for dependencies, and you should have working ports.

 

[mac57mac57]

Whoops! My bad... I went back and re checked. In fact it was 10A190 I installed, not 10A196.

So... I need to do this again anyway. The test machine from last time now boots Sorbet, and needs to be reasonably stable; it runs an internet-visible Gopher server. Instead I will try the SLPPC 10A196 install on my G5 Quad.

Thanks for the pointers, and I will pay careful attention to the Table 4 you have highlighted.

 

[barracuda156]

Whoops! My bad... I went back and re checked. In fact it was 10A190 I installed, not 10A196.

So... I need to do this again anyway. The test machine from last time now boots Sorbet, and needs to be reasonably stable; it runs an internet-visible Gopher server. Instead I will try the SLPPC 10A196 install on my G5 Quad.

Thanks for the pointers, and I will pay careful attention to the Table 4 you have highlighted.

There is no 10A196.

The latest developer build which installs with minimal hacks is 10A190. There is 10A96, which is older and has more stuff broken generally, but perhaps less glitches with Finder in particular.

 

[mac57mac57]

Well... that explains why 10A190 seemed to be newer than what I thought looked like a higher version number, 10A196. Of course, it is "10A96", a lower version number.

I'll still try SLPPC 10A190 again, on the Quad, complete with the extensive kext replacement documented in the shell script provided for this purpose (10.6PPC.sh, or some such.. I have it on my Mac, but I can't double check the name from here on my phone).

Thanks for all the pointers. It never ceases to amaze me how many times I can read something and see it incorrectly. My mind substituted "10A196" every time I read "10A96" and until the above reply, I did not catch the difference. Sheesh!

 

[B S Magnet]

I do not know a reason why it would not work on any other one in general case. It may not be optimal for 10.6.8 for a few reasons, but should still work. It is likely to work on 10A96, which is behind 10A190, so fallbacks should work exactly the same way.

I think it was you who established problems with using Macports on 10A96, but I don’t think we ever came to understand precisely why (odd, in that both it and 190 rely on the same, bundled version of Xcode 3.2 for compiling).

P. S. Nothing prevents you from trying:

Nothing prevents me from trying to build a skyscraper, either — except, well, suitable tools and considerable applied experience.

MacPorts software tarballs reproduce the structure of a final install, so you do not actually require MacPorts, as long as you have time to move everything in place by hand.

Without that experience, there needs to be an “explain this like I’m five” how-to guide on what precisely would need to be moved into place by hand, and how to go about it. See: “building a skyscraper”, but more on the level of “wiring that skyscraper for functioning electricity.”

(Remember: I‘m not a software developer. I’m an urbanist. What I know from tinkering with Macs is supplementary and a function of using them since 1990, and daily since 1994.)

Extract any software, put into /opt/local and whats not, do the same for dependencies, and you should have working ports.

All of this requires a level of applied know-how which many, myself included, lack (especially in knowing just how long that dependencies list is, and what’s in it).

This was, in essence, why package managers like macports, fink, apt, etc., found a lasting purpose: to make it straightforward for the user to add, update, and uninstall packages without having to, remedially, dig into the package manager config itself just to get it from not erroring out on a specific version of an OS environment (all because the package manager maintainers don’t accommodate that OS version with their project).

 

[barracuda156]

I think it was you who established problems with using Macports on 10A96, but I don’t think we ever came to understand precisely why (odd, in that both it and 190 rely on the same, bundled version of Xcode 3.2 for compiling).




Nothing prevents me from trying to build a skyscraper, either — except, well, suitable tools and considerable applied experience.



Without that experience, there needs to be an “explain this like I’m five” how-to guide on what precisely would need to be moved into place by hand, and how to go about it. See: “building a skyscraper”, but more on the level of “wiring that skyscraper for functioning electricity.”

(Remember: I‘m not a software developer. I’m an urbanist. What I know from tinkering with Macs is supplementary and a function of using them since 1990, and daily since 1994.)



All of this requires a level of applied know-how which many, myself included, lack (especially in knowing just how long that dependencies list is, and what’s in it).

This was, in essence, why package managers like macports, fink, apt, etc., found a lasting purpose: to make it straightforward for the user to add, update, and uninstall packages without having to, remedially, dig into the package manager config itself just to get it from not erroring out on a specific version of an OS environment (all because the package manager maintainers don’t accommodate that OS version with their project).

I am not trying to convince you to use MacPorts. I am simply saying that the statement above is incorrect.

By the way, what was established is that on 10A96 building ports is broken. This should not be relevant for installing pre-built ports.

P. S. While I think that nobody should use 10A96 when a better version is there, I will try installing MacPorts and a few pre-built ports just to find out exactly if it works or not. In about an hour.

 

[barracuda156]

Ok, how is 10a96 supposed to be cloned? (Same Disk Utility has no issues with cloning 10a190 dmg.)

 

[B S Magnet]

Ok, how is 10a96 supposed to be cloned? (Same Disk Utility has no issues with cloning 10a190 dmg.)

View attachment 2404516

No idea. Maybe try using Carbon Copy Cloner 3.4.7 instead?

 

[B S Magnet]

I am not trying to convince you to use MacPorts. I am simply saying that the statement above is incorrect.

OK. Are we speaking past one another here? I get the sense we are.

By the way, what was established is that on 10A96 building ports is broken. This should not be relevant for installing pre-built ports.

This presents an issue: an end user has no explicit, up-front way of knowing, when running a port install command, whether a port is pre-built or not. What might just install from a pre-built port on one version of OS X may need to be compiled on another.

A good example is when watching a port with many dependencies install (Qt4 or a browser, for instance): some dependencies download, extract, install, and then move onto the next dependency; the next, however, may end up needing to be compiled on the fly and typically occupy the lion’s share of an installation time of the requested port.

Although the case discussed here relates to Build 10A96, it is not exclusive to 10A96. This happens across every deployment of macports across every version of macOS which macports is supported to operate. It’s mostly that Build 10A96 brings to fore the lack of clarity, when listing or searching for a port, whether that port (on that version of macports; on the machine which that version of macports is running; and on which OS that machine is using; and so on) will just download, extract, and install because it was pre-built in the repository, or whether it will arrive as source code, with scripts in macports which then proceed with building it on-the-fly.

So relevance is not the point; transparency on the macports side, on the state of whether a port will install from pre-built or need to be compiled locally, is.

P. S. While I think that nobody should use 10A96 when a better version is there

That’s a perfectly fair point.

And when I am able and have the time in my life to set aside, to set up and run through all the fixes the folks using 10A190 throughout this thread have shared — along with my own, similar line of QA testing of components (as I did with 10A96) — then I’ll be there with you and most everyone with Build 10A190 (or, if it ever turns up again, new work on Build 10A222 which can reach WindowServer and Finder).

At that time, Build 10A96 can retire to being a (reasonably documented) relic — a forgotten curio.

 

[ChrisCharman]

NINE machines?! 🤯

You may win grand prize of, well, the world here, of running and testing SL-PPC concurrently on so many variations. I feel like a total dilettante with just the one I’ve used for all my testing. Yours is, certainly, a far more rounded assessment and experience of spotting inter-system quirks with 10A190. That’s outstanding work.

Well, the downside has been that each machine has been siloed and efforts and tweaks on each separated and not well documented across time since joining the project at the beginning. This is due to life interrupting me constantly and pesky work getting in the way of my hobby. In an ideal world i’d have all machines setup simultaneously and be able to focus on the project without distraction.

Moving forward my goal is to take everything and move it onto a G-drive that my partner generously bought me as a gift, so that i can boot from Firewire on all the PowerPC machines and USB on the intel using the same images with the same tweaks. Currently I have compiled binaries and disk images on multiple internal and external drives and thumb sticks which is a bit of a headache. I’d also like to document moving the updates and fixes over one at a time so that they can be replicated before trying to release another update package, but again free time is always the limiting factor.

There is no 10A196.

The latest developer build which installs with minimal hacks is 10A190. There is 10A96, which is older and has more stuff broken generally, but perhaps less glitches with Finder in particular.

In fairness @B S Magnet has proven, that by following their table in the wiki, 10A096 can be extremely stable and less glitchy than 10A190 and as 10A096 is technically closer to Leopard (on an ‘under the hood’ level) and more compatible with Leopard components, it is worth consideration for people that want to run a stable Snow Leopard system on PowerPC. The only current caveat being that software development and post Leopard software support like MacPorts is less supported at the moment.

Well... that explains why 10A190 seemed to be newer than what I thought looked like a higher version number, 10A196. Of course, it is "10A96", a lower version number.

I'll still try SLPPC 10A190 again, on the Quad, complete with the extensive kext replacement documented in the shell script provided for this purpose (10.6PPC.sh, or some such.. I have it on my Mac, but I can't double check the name from here on my phone).

Thanks for all the pointers. It never ceases to amaze me how many times I can read something and see it incorrectly. My mind substituted "10A196" every time I read "10A96" and until the above reply, I did not catch the difference. Sheesh!

The pre-made disk images are a good starting point, followed by the steps outlined in the wikipost table, particularly for 10A096.

Ok, how is 10a96 supposed to be cloned? (Same Disk Utility has no issues with cloning 10a190 dmg.)

View attachment 2404516

May be a corrupt .dmg @barracuda156. Try downloading again. It should restore in Disk Utility but if it doesn’t try CCC or SuperDuper.

OK. Are we speaking past one another here? I get the sense we are.



This presents an issue: an end user has no explicit, up-front way of knowing, when running a port install command, whether a port is pre-built or not. What might just install from a pre-built port on one version of OS X may need to be compiled on another.

A good example is when watching a port with many dependencies install (Qt4 or a browser, for instance): some dependencies download, extract, install, and then move onto the next dependency; the next, however, may end up needing to be compiled on the fly and typically occupy the lion’s share of an installation time of the requested port.

Although the case discussed here relates to Build 10A96, it is not exclusive to 10A96. This happens across every deployment of macports across every version of macOS which macports is supported to operate. It’s mostly that Build 10A96 brings to fore the lack of clarity, when listing or searching for a port, whether that port (on that version of macports; on the machine which that version of macports is running; and on which OS that machine is using; and so on) will just download, extract, and install because it was pre-built in the repository, or whether it will arrive as source code, with scripts in macports which then proceed with building it on-the-fly.

So relevance is not the point; transparency on the macports side, on the state of whether a port will install from pre-built or need to be compiled locally, is.



That’s a perfectly fair point.

And when I am able and have the time in my life to set aside, to set up and run through all the fixes the folks using 10A190 throughout this thread have shared — along with my own, similar line of QA testing of components (as I did with 10A96) — then I’ll be there with you and most everyone with Build 10A190 (or, if it ever turns up again, new work on Build 10A222 which can reach WindowServer and Finder).

At that time, Build 10A96 can retire to being a (reasonably documented) relic — a forgotten curio.

I have all of @educovas 10A222 shared files and the disk image, but as they expressed a desire to keep it to themselves, which was extremely unfortunate to say the least, I haven’t re-uploaded them.

The 10A432 build was never shared so that’s something that needs to be recreated. I did manage to build the kernel following the instructions and modifications that were shared but not yet gotten as far as a bootable image. If and when i do i will of course share it here.

I really don’t think 10A096 should be retired. I would like to see all of @B S Magnets work implemented into a disk image for new users to be able to easily restore. If anyone successfully follows the steps in the wiki and creates such an image please share it here so it can be uploaded to the garden.

 

[Doq]

Ok, how is 10a96 supposed to be cloned? (Same Disk Utility has no issues with cloning 10a190 dmg.)

View attachment 2404516

My wild card when dealing with bummy disk images is to mount it, and then use Disk Utility to copy the mount instead of the image.

 

[Edgecrusherr]

I just got my iMac G4 20 inch 1.25GHz back up and running (had a bad PSU). 10A190 has a kernel panic at boot, but 10A96 is working. I've tried searching and reading through this stream, but didn't see if anyone specifically mention if they got full graphics acceleration working in the AGP Nvidia 5200 Ultra that's inside this computer.

I'm going to try to copy over some kext from my 10.5.8 drive, but have a feeling that won't be good enough, and I've only seem the PCI 5200 mentioned as working.

I anyone has any insight on getting this to work will full acceleration, and/or getting 10A190 to boot on this model, I'd appreciate it.

Thanks!

 

[barracuda156]

I just got my iMac G4 20 inch 1.25GHz back up and running (had a bad PSU). 10A190 has a kernel panic at boot, but 10A96 is working. I've tried searching and reading through this stream, but didn't see if anyone specifically mention if they got full graphics acceleration working in the AGP Nvidia 5200 Ultra that's inside this computer.

I'm going to try to copy over some kext from my 10.5.8 drive, but have a feeling that won't be good enough, and I've only seem the PCI 5200 mentioned as working.

I anyone has any insight on getting this to work will full acceleration, and/or getting 10A190 to boot on this model, I'd appreciate it.

Thanks!

10a190 should boot fine. Have you got any non-standard peripherals connected? I get KP if the OS knows about PCIe SSD card installed, otherwise it boots normally, always. The only exception was a short period when one of my RAM modules started dying – the OS really disliked that. Once I figured out the cause and removed corrupt RAM, everything works fine ever since.

 

[barracuda156]

Ok, whoever is running 10a190 at the moment, please consider trying this out: https://forums.macrumors.com/thread...lt-ports-unofficial-testing-welcomed.2433458/

I need some feedback on what works and what does not.