The PowerPC Debian Wiki

[barracuda156]

@barracuda156 has apparantly had the same thought as me 🙂

Make fzf optional to avoid requiring Go · Issue #104 · Benexl/yt-x

@Benexl Could we make fzf optional? Requiring it means this cannot be used on any platform where Go is broken (a lot of macOS versions, any Linux or *BSD on 32-bit powerpc, etc.).

github.com

@Lastic @Matias_

I have a drop-in for fzf now: https://github.com/macos-powerpc/powerpc-ports/blob/main/sysutils/fzfpp/Portfile
Or without ports: https://github.com/barracuda156/fzfpp

However, a) it supports a subset of features, and to support a new app extra work may be needed; b) the actual code is generated with Claude Code, I only gave instructions on design and did testing, so the code may contain bugs and is likely not optimized well. I just wanted a tool to address a specific problem, it is not a full-featured replacement. It has only been tested with 4 apps at the moment: viu (fastanime), ani-cli, ytsurf, por-cli.

 

[barracuda156]

mplayer
ffmpeg
fzf

all fail because of conflicting dependencies, anybody got a clue how I can get these installed/working ?

As mentioned above, fzf cannot be compiled on ppc due to a broken Go, however you may not really need it, since there are alternatives, and in many cases apps using fzf by default provide fallback options (sentaku, rofi, fnf).

As for the rest, you may consider using a proper ports manager which supports Linux. One choice is https://github.com/RJVB/lnxports (MacPorts/PPCPorts-compatible) and another is https://github.com/drecklypkg/dreckly (a portable fork of NetBSD’s pkgsrc).

 

[Lastic]

@Lastic @Matias_

I have a drop-in for fzf now: https://github.com/macos-powerpc/powerpc-ports/blob/main/sysutils/fzfpp/Portfile
Or without ports: https://github.com/barracuda156/fzfpp

However, a) it supports a subset of features, and to support a new app extra work may be needed; b) the actual code is generated with Claude Code, I only gave instructions on design and did testing, so the code may contain bugs and is likely not optimized well. I just wanted a tool to address a specific problem, it is not a full-featured replacement. It has only been tested with 4 apps at the moment: viu (fastanime), ani-cli, ytsurf, por-cli.

Trying to get yt-x running , I stumbled into the rabbit-hole of fzf alternatives.

Tried skim but not feature compliant enough with fzf.

Was now battling matchmaker-cli which looked promising but depends on nucleo which uses part of boxcar and AtomicU64 declarations...

Have seen your name pop-up on quite a few AtomicU64 github comments so I knew I was on the right track 🙂

Didn't know ytsurf so will give that a try and your fzfpp

 

[barracuda156]

Launching SDL applications or glxinfo , I get an LLVM ERROR: Relocation type not implemented yet!
Anybody got a clue what the issue is with LLVM ?

@Lastic You probably have mesa compiled with enabled llvmpipe, and that is broken, because LLVM has no support for JIT on ppc. Either rebuild mesa without llvmpipe or use runtime args to avoid using it.

Some powerpc-darwin notes can be found here: https://github.com/macos-powerpc/po...9710c276c96a28c08/x11/mesa/Portfile#L162-L167
I guess Linux has a similar issue in a case of ppc.

 

[barracuda156]

Trying to get yt-x running , I stumbled into the rabbit-hole of fzf alternatives.

Tried skim but not feature compliant enough with fzf.

I don’t think an API-compatible alternative exists, though I did not investigate rust options, since that is a pain to compile on ppc (if possible at all). That was the reason for me to bother with making such an alternative, which would be portable.

Was now battling matchmaker-cli which looked promising but depends on nucleo which uses part of boxcar and AtomicU64 declarations...

Have seen your name pop-up on quite a few AtomicU64 github comments so I knew I was on the right track 🙂

32-bit ppc does not support 64-bit atomics on hardware level, only via libatomic in gcc (and possibly via compiler-rt in clang, but not on macOS). So you may have a trouble with rust code requiring that.

Didn't know ytsurf so will give that a try and your fzfpp

I found ytcui quite pleasant to use, works even on old macOS, should work on Linux:

Upstream: https://github.com/MilkmanAbi/ytcui
Port: https://github.com/macos-powerpc/powerpc-ports/blob/main/www/ytcui/Portfile

This does not require fzf or alike.

If you use ytsurf, it defaults to fzf (usable with fzfpp too), otherwise you can run it as `ytsurf --sentaku`. See: https://github.com/Stan-breaks/ytsurf/issues/8

 

[barracuda156]

Trying to get yt-x running , I stumbled into the rabbit-hole of fzf alternatives.

I think I added missing stuff into fzf++ for it to work with yt-x. Cannot try on powerpc or Linux now, but at least on modern macOS yt-x is usable with it (streaming and downloading, I did not try every other feature that exists).

 

[barracuda156]

I think I added missing stuff into fzf++ for it to work with yt-x. Cannot try on powerpc or Linux now, but at least on modern macOS yt-x is usable with it (streaming and downloading, I did not try every other feature that exists).

For some reason on older systems bash scripts-based apps (yt-x, ytsurf) do not want to stream from YouTube to mpv. It did not work with ytsurf, and now the same with yt-x. At the same time downloading works (also like with ytsurf).

On modern macOS streaming works fine in both apps.