livi: init at 0.0.6

[mksafavi]

Description of changes

source URL: https://gitlab.gnome.org/guidog/livi

closes #295373

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.05 Release Notes (or backporting 23.05 and 23.11 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.

[mksafavi]

Thanks for reviewing this.

should be in nativeBuildInputs

I think I'm confused about this. I read the nix documentation about nativeBuildInputs and buildInputs. If I understand it correctly nativeBuildInputs are build time dependencies that are arch dependent. They make it possible to cross compile for other systems too. buildInputs are the runtime dependencies. right?

I have an issue with this packages. It requires gstreamer on runtime. I assumed adding gst_all_1 packages to buildInputs would fix that.
But It seems like that's not the case. If I create a shell with livi, it can't find gst elements.
Do I need to do anything specific to include gst in the derivation?

Not adding yourself to maintainers?

I thought it should be better if a user of the app becomes the maintainer. That being said, I'm ok with maintaining it myself too.

[Aleksanaa]

I have an issue with this packages. It requires gstreamer on runtime. I assumed adding gst_all_1 packages to buildInputs would fix that. But It seems like that's not the case. If I create a shell with livi, it can't find gst elements. Do I need to do anything specific to include gst in the derivation?

Oh you forgot to add wrapGAppsHook4 to nativeBuildInputs. Gstreamer packages add $GST_PLUGIN_SYSTEM_PATH_1_0 but don't create a wrapper themselves. wrapGAppsHook4 can handle it for you. If you use other wrappers, you have to manually append it.

I thought it should be better if a user of the app becomes the maintainer. That being said, I'm ok with maintaining it myself too.

That's not the case. Just others will ping you for issues and build failures, and you can deal with automatic updates yourself.

[mksafavi]

Oh you forgot to add wrapGAppsHook4 to nativeBuildInputs. Gstreamer packages add $GST_PLUGIN_SYSTEM_PATH_1_0 but don't create a wrapper themselves. wrapGAppsHook4 can handle it for you. If you use other wrappers, you have to manually append it.

Thanks. adding wrapGAppsHook4 fixed the issue.

That's not the case. Just others will ping you for issues and build failures, and you can deal with automatic updates yourself.

I added myself to the maintainers.

Also, I squashed the commits and fixed the messages. I think it should fit the CONTRIBUTING.md now.

[Aleksanaa]

These gst packages should be in buildInputs

[mksafavi]

Oh. I miss interpreted the previous review and instead of moving the last line, I moved the whole highlighted section into nativeBuildInput. I'll fix this.
How do you know which packages should get into buildInputs?

[Aleksanaa]

I should admit that I mostly go by feel. Packages that are used at build time should go in nativeBuildInputs, and packages that are linked or called at runtime should go in buildInputs. If you want a very accurate representation, you can add strictDeps = true to this package (recommended), in this way if you don't do it correctly, you'll fail to build.

[Aleksanaa]

gtk4 and libadwaita should also be in buildInputs

[Aleksanaa]

Suggested change

	license = licenses.gpl3;
	license = licenses.gpl3Plus;

[mksafavi]

I think it should be changed into gpl3Only based on this https://gitlab.gnome.org/guidog/livi/-/blob/main/COPYING
It seems like gpl3 is deprecated but I didn't get any warnings in the build.
Do you know why my builds don't care about the meta section? It was the same with the maintainer field as well. I didn't notice any issues with it but Borg caught it and failed.

[Aleksanaa]

I think it should be changed into gpl3Only based on this https://gitlab.gnome.org/guidog/livi/-/blob/main/COPYING

It's at the top of c source files. Also the flathub uses gpl3Plus.

It seems like gpl3 is deprecated but I didn't get any warnings in the build.
Do you know why my builds don't care about the meta section? It was the same with the maintainer field as well. I didn't notice any issues with it but Borg caught it and failed.

Because It does not use these sections.

[Aleksanaa]

lgtm. Please squash your commits into livi: init at 0.0.6 (except adding maintainer)

[mksafavi]

Should I order the args alphabetically here?
I noticed that some packages put builtins like lib, stdenv,... first and then order the deps alphabetically.

[Aleksanaa]

Not needed. You can also sort them in the order they are used. It's up to you. But lib should be placed in first order.