Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hello-wayland: init at 2020-07-27 #108832

Merged
merged 1 commit into from Jan 9, 2021
Merged

Conversation

alyssais
Copy link
Member

@alyssais alyssais commented Jan 9, 2021

Motivation for this change

This is a program that just displays a static cat picture in a Wayland
window. I packaged it a while ago thinking it wouldn't be useful for
anybody else, but a conversation on IRC today made me realise it would
be!

hello-wayland is very useful as a minimal example when hacking on
Wayland ecosystem stuff -- even if Firefox doesn't work yet,
hello-wayland probably will and that can be useful to guide you in the
right direction!

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

This is a program that just displays a static cat picture in a Wayland
window.  I packaged it a while ago thinking it wouldn't be useful for
anybody else, but a conversation on IRC today made me realise it would
be!

hello-wayland is very useful as a minimal example when hacking on
Wayland ecosystem stuff -- even if Firefox doesn't work yet,
hello-wayland probably will and that can be useful to guide you in the
right direction!
Copy link
Member

@cole-h cole-h left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diff LGTM. Big +1 for using both stdenv and lib, and not just stdenv.lib.


Result of nixpkgs-review pr 108832 run on x86_64-linux 1

1 package built:
  • hello-wayland

@SuperSandro2000
Copy link
Member

Big +1 for using both stdenv and lib, and not just stdenv.lib.

It does not matter if you use the first or the second. It makes literally no difference and is just bike shedding.

@cole-h
Copy link
Member

cole-h commented Jan 9, 2021

There's functionally no difference, you're correct. I just figured that, for a packaging system that places an emphasis on explicit dependencies, we should also be explicit here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants