Since virtio-gpu context types are now in upstream kernels, it is now
possible to use Sommelier without patching it or using custom kernels,
so I think it's finally suitable for inclusion in Nixpkgs.
I'm using the same versioning scheme I made up for crosvm here.
Figuring out the version is handled by the update script, which I
adapted from the crosvm one. Sadly there's too many differences
between them to easily merge them into one, so reducing duplication
between them is left as further work.
Closes: https://github.com/NixOS/nixpkgs/pull/95874
Upstream XMonad was using our xmonad patch file for their flake build to
support our nixos module. This would of course break the build upstream
if the version we patched and their master branch diverged. We
[discussed] that it'd make sense to upstream the environment var code.
In the process it seemed sensible to rename the NIX_GHC variable as
well, since it isn't really Nix-specific – it's just a way to set the
GHC binary to execute. This change has been [implemented] upstream in an
unreleased version of xmonad now – meaning we'll be able to drop the
xmonad patch soon!
This also clarifies the situation in nixpkgs a bit: NIX_GHC is easy to
confuse with the environment variable used in the ghcWithPackages
wrapper where it is used to set an alternative prefix for a GHC-wrapper
for applications trying to discover it via e.g. ghc-paths. It is an
implementation detail in this context, as it is in the case of the
xmonad module. Since they are different implementations doing different
things, different names also make sense.
[discussed]: 36d5761b3e
[implemented]: 23f36d7e23
Some source files have "linux-dmabuf-unstable-v1-server.h" header
included, but do not really need it. Thus, that sources do not
have a correctly configured dependency on that header, which is
dynamically generated during the build.
The fix for that error is to remove unneeded #include.
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
Note: I DO NOT resign from nixpkgs, not at all!
However, I like a clean notification inbox and I get a lot of stuff for
packages where I'm only an end-user or don't use them anymore and thus
can't help out that much.
So please consider it a measure to reduce the mental load for me when
going through my notifications ;-)
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: plugin.o:(.bss+0x0): multiple definition of `stam'; panel.o:(.bss+0x20): first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: workspaces.o:src/keyboard.h:93: multiple definition of
`NumLockMask'; client.o:src/keyboard.h:93: first defined here
strictDeps breaks `withGtkWrapper` as, it seems, the setup hook does not
run and `GSETTINGS_SCHEMA_PATH` does not get set so `XDG_DATA_DIRS` is
not updated. Probably other things are broken by it as well. See also
probably related https://github.com/NixOS/nixpkgs/issues/56943
(mentioned from `doc/languages-frameworks/gnome.section.md`).
This partially reverts commit da4707d636.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: screen.o:(.bss+0x40): multiple definition of `fg'; client.o:(.bss+0x40): first defined here
Without thce change build fails on upstream gcc-10 as:
ld: mbtheme.o:/build/matchbox-window-manager-1.2/src/structs.h:229: multiple definition of
`MBAtomEnum'; main.o:/build/matchbox-window-manager-1.2/src/structs.h:229: first defined here
Without the change build on upstream gcc-10 fals as:
ld: i3lock-unlock_indicator.o:/build/source/x86_64-pc-linux-gnu/../../source/unlock_indicator.c:39:
multiple definition of `input_position'; i3lock-i3lock.o:/build/source/x86_64-pc-linux-gnu/../../source/i3lock.c:73: first defined here
Without the change build fails as:
ld: CMakeFiles/awesome.dir/objects/window.c.o:/build/source/build/common/lualib.h:31:
multiple definition of `lualib_dofunction_on_error';
CMakeFiles/awesome.dir/awesome.c.o:/build/source/build/common/lualib.h:31: first defined here
Without the change build fails on -fno-common tollchains as:
$ nix build --impure --expr 'with import ~/nm {}; wmfs.override { stdenv = clang13Stdenv; }'
...
ld: src/log.o:(.bss+0x0): multiple definition of `W'; src/barwin.o:(.bss+0x0): first defined here
ld: src/wmfs.o:(.bss+0x0): multiple definition of `W'; src/barwin.o:(.bss+0x0): first defined here
ld: src/wmfs.o:(.bss+0x10): multiple definition of `event_handle'; src/client.o:(.bss+0x10): first defined here
Sway can be compiled with or without systemd(-logind) and dbus. This
commit exposes that support via the global systemdSupport and
dbusSupport arguments, which are understood by many other nixpkgs
expressions and can be set globally in ~/.config/nixpkgs/config.nix.
This commit also adds a third argument, trayEnabled, which allows to
disable sway's tray. The tray requires dbusSupport and
systemdSupport.
Reviewers of this commit asked for potential use cases. There are
many of them; a very non-exhaustive list includes:
* Use of nixpkgs on operating systems which systemd does not support,
such as MacOS/Darwin, FreeBSD, OpenBSD, or Alpine Linux.
* Use of nixpkgs on *-musl platforms, which systemd does not
officially support (out-of-tree patches to support musl exist for a
few systemd versions).
* Use of sway in situations where dbus is inappropriate, such as
sway's "kiosk mode".
* High-security environments, where the additional attack surface
exposed by dbus outweighs any features it may offer.
This is a very non-exhaustive list.
This commit exposes support for compilation without systemd,
controlled by the global systemdSupport argument. This argument is
understood by many other nixpkgs expressions and can be set globally
in ~/.config/nixpkgs/config.nix.