freeshow: init at 1.2.1

[ByteSudoer]

Description of changes

Project description

FreeShow is a free and open-source presentation program that makes it easy to show text on a big screen. It supports stage display, remote control, media, and many other advanced features. It is open-sourced meaning anyone can contribute.

FreeShow exists because the creator found that other simular programs was either expensive or complex to use. He wanted to create a program that was easy to use and affordable for everyone, from small churches to large venues. FreeShow is now used by people all over the world.

Metadata

• homepage URL: https://freeshow.app/
• source URL: https://github.com/ChurchApps/FreeShow
• license: GPL-3.0 license

Closes #332304

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[SigmaSquadron]

Are we sure we can't build FreeShow from source? It seems to just be a Node.JS app.

[ByteSudoer]

We probably could. but I don't see a remarkable benefit since upstream provided an appImage. It makes sure all the dependencies and libraries are hard coded into the package.Maybe the only advantage is that it would extend support to reach windows platforms.

[SigmaSquadron]

I'd rather reduce the amount of new pre-compiled packages on Nixpkgs, but this is a personal preference only, and the diff looks fine otherwise.

[ByteSudoer]

I will try to make it a source based package and if the build succeeds I will update the PR.

[SigmaSquadron]

I'd rather see a source build, to be totally honest. If it proves to be too difficult, the pre-built package is fine, but I'm sure you can do it!

[kd2flz]

Any luck with this?

[pluiedev]

Very very minor nitpicks, should probably call a committer to merge this

[pluiedev]

It won't evaluate for platforms absent from the list of supported platforms anyway

Suggested change

	.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.system}");
	.${stdenv.hostPlatform.system};

[FliegendeWurst]

This is a very common pattern in nixpkgs. I would keep the throw.

[pluiedev]

It's common, but not necessary. See #314224

[pluiedev]

Suggested change

	--replace-warn 'Exec=AppRun' 'Exec=freeshow'
	--replace-warn 'Exec=AppRun' 'Exec=freeshow'

[SigmaSquadron]

I maintain my original review; I'd rather not have more sourceProvenance = binaryNativeCode FOSS apps in Nixpkgs. I'm sure this could become a source build. The Nixpkgs manual has a pretty good section on JS apps, and there are a few examples of similar GUI packages in the tree.

Once more, while I'm confident that you can turn this into a source build, if it proves too difficult or overly time-consuming, then feel free to reply as such and disregard this comment.