| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Recommended by aszlig to switch from module to package.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far in the games namespace we have just used the callPackage_i686
function from <nixpkgs> instead of our augmented set.
If we just use packages that are available in <nixpkgs> everything is
fine, but as soon as we want to use one of our own packages for
i686-linux we can't simply do that.
One example is the override in the gog.albion derivation which just uses
buildSandbox from the main pkgs attribute set.
We now properly pass through the whole pkgsi686Linux set to the games
namespace, so we can drop that hack for Albion.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
I've pushed this with a few improvements to upstream <nixpkgs> via
commit NixOS/nixpkgs@1cba74dfc1541673f91b91c3ab50dbdce43c764a.
The original pull request was NixOS/nixpkgs#34506.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
This is really not game-specific, so let's put it at the top-level and
also make sure we substitute all the commands we're using there, even
though a few of them are in PATH of stdenv so that it will always work
even when the programs available in stdenv should change someday.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
This is not only useful for packaging games, so let's make it available
from the vuizvui scope, so we can use it from other packages as well.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer use the legacy SSH store protocol for taalo but the new
ssh-ng protocol, which makes the implementation of taalo-build a LOT
less clunky.
It also didn't make sense to have this as a NixOS module when we after
all just emit a static store path without any stuff depending on
configuration options.
The new implementation basically just wraps nix-build and nix-store -r
along with the right NIX_REMOTE variable.
With Nix 1.2 this can also be done with the new "nix build" command
using the --store option, but unfortunately "nix build" doesn't yet have
the same functionality as nix-build.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch, @bendlas
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a bit weird to need to write something like this:
nix-build pkgs -A vuizvui.aszlig.vim
We're already within vuizvui, and the filesystem paths are already
structured in a way so that the above is in pkgs/aszlig/vim, so the need
to add the vuizvui attribute to that seems quite pointless and
unnatural.
I have tested this by evaluating a few machines, tests and packages.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Almost all of the issues we so far needed patches for have been
addressed upstream with the exception of backlight probing.
The reason for this is detailled in the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=96571
In summary, when the I915 driver is built into the kernel, it can't
access the PWM because it's initialized at a later stage.
What we're now doing instead is that we compile i915 as a module and
bake the necessary PWM modules directly into the kernel.
This has the advantage that we no longer need the backlight.patch,
because after all this is already a workaround and having a workaround
that doesn't require us to rebase the patch once a new kernel arrives
seems to be a better solution in my opinion.
With this update we can now revert the reintroduction of kernel 4.12
done in 45bdcd7fc7788316cbad2d7d412e421b230715dc.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
It has been removed by NixOS/nixpkgs@964672dde516d1b9a5d2248db33253dc36.
This kernel version is officially EOL but in order to switch to a newer
kernel I need to rebase the patches first.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Now the pkgs/default.nix is a lot more readable because it has only the
top-level derivations and the callPackageScope invocations for the
corresponding sub-scopes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Tested evaluation using:
nix-instantiate pkgs -A vuizvui.profpatsch.show-qr-code
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should remove a lot of clutter from pkgs/default.nix into
corresponding sub-scopes, eg. pkgs/openlab/default.nix.
Apart from restructuring there is no change of runtime functionality
involved.
Tested by evaluating with "nix-env -f pkgs -qaP".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch, @sternenseemann
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default callPackageWith adds an overrideDerivation attribute, but
that won't work with our new package scopes, so we add an override
attribute by ourselves without the overrideDerivation attribute.
That aside, we now use functionArgs on not only the superset of packages
but also for the scope utility functions (callPackage/callPackage_i686)
that we pass down to our new package scope. If we didn't do that, the
Nix expression of the subscope would always need to define callPackage
and callPackage_i686 in their function arguments, regardless of whether
it's needed or not.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This already has started in e0abe1dbbda54c1f048b5d38df05e1a3289216a6
with @Profpatsch putting his packages into its own namespace, so let's
continue on that and move my crap into my own namespace as well.
The only difference in my approach is that I'm now also using a new
function called callPackageScope, which declutters pkgs/default.nix a
bit and moves the individual callPackage invocations into
aszlig/default.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
This clearly is something currently only @Profpatsch wants, so lets move
it into the user namespace.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
| |
A lot of crap has been accumulated there over the years, so I'm removing
at least the stuff that I have introduced.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
| |
|
|
|
|
| |
pkgs.haskellPackages.gopher-proxy
|
| |
|
|
|
|
| |
Patches for a nicer upload interface were added.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in the previous commit, kernel patches from
boot.kernelPatches are added to the kernel package via .override.
Unfortunately, .override overrides the function arguments of the
expression referenced from callPackage, so having the patches inside the
package expression itself will discard those patches once there is an
override.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed in NixOS/nixpkgs@b3f7d626c164ae591a067f78bfcbb06fc3a588b9.
We are currently stuck in 4.7 with the T100HA because of this upstream
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97529
So let's bring back the expression for Linux 4.7 until there is time for
debugging the mentioned bug.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This now should reflect "all things kernel" and thus could not only
contain patches but other things. If we have so many patches that it
makes sense to namespace them further, we can still use kernel/patches
for that purpose which is way better than "kpatches".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Right now the linking process with wineg++ fails on 64bit and I
currently don't have time to properly look into why this happens.
Another workaround would be to just use patchelf to fix the errors
afterwards, but in the end everything except dwb has to be 32bit anyway.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
| |
I experimented with them, but they didn’t lead to a nice solution.
Sorry for breakage @aszlig.
|
|
|
|
|
|
|
| |
This actually fixes the build of libjreen against Qt 5.6, the rest of
the dependencies work fine with Qt 5.6.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Regression introduced in e0abe1dbbda54c1f048b5d38df05e1a3289216a6.
This causes the evaluation to fail since 5 days now, so I'm commenting
it out until @Profpatsch has either provided the expressions or removed
the callPackage references.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
| |
A script to display current time & battery.
|
|
|
|
| |
A script that executes a nice STACKENBLOCKEN into the air.
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the build for Tomahawk because some of these dependencies
were already refactored in upstream <nixpkgs> and hence we can simply
specify the dependencies directly.
Alongside of this, I've broken out some of the buildInputs into
nativeBuildInputs, so this will stay safe for cross compilation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
| |
By disabling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I didn't get the starcoscard to run with aqbanking so far and the bank
itself is very uncooperative if it comes to giving specific details
about their implementation of FinTS 3.00, so in the end I'm going to
move away from the bank.
But during transition this will work much better than running a Windows
VM (which I didn't have access to in the meantime, so I *had* to get
this running somehow), especially because we can wrap this plugin in
*any* browser that supports NPAPI.
Also, there seems to be some work implementing PPAPI support for
pipelight, but the branch is stale since quite a while:
https://bitbucket.org/mmueller2012/pipelight/branch/ppapi
Going back to the pesky Santander plugin:
In order to support PC/SC-Lite, we need to patch Wine to get support for
the winscard API. We also patch out unixfs, so while there definitely
are better sandboxing options this should suffice so that the plugin
doesn't write garbage on any location of the system (basically it works
entirely read-only).
So in the end we get a nice and small dwb browser, which directly opens
up the login page along with the plugin. The browser is wrapped so that
it only writes to a temporary location, so as soon as it is closed all
the cruft is cleaned up afterwards.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a small helper tool which I specifically use for running NixOS
tests (especially the installer ones) that require <nixpkgs> to be
copied to the store.
What git-detach does is creating a temporary working directory which
only contains a trimmed-down (without untracked files and .git
directory) version of the current Git repository.
So in case of <nixpkgs> this is especially useful to keep down the
closure size whenever the working dir is going to be exported to the
store.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Otherwise, neither nix-env nor packagePlatforms will able to pick up the
nested derivations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
| |
|
|
|
|
|
|
|
|
|
|
| |
New we can reference the games using pkgs.vuizvui.games.*, although game
configuration currently still resorts to using ~/.config/nixgames.nix if
there is no nixpkgs.config.vuizvui.games set. In this vein, this should
also avoid Hydra to try to build those games, because those aren't
publicly available for free.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
SDL 2 has an environment variable called SDL_GAMECONTROLLERCONFIG, which
lists button/axis mappings of various game controllers attached to the
system.
The game controllers are themselves identified using a GUID which is SDL
2 specific and this tool is there to just dump the name of a particular
game controller along with the GUID so it's easier to get the GUID.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
| |
We're going to use it for another machine, so it makes sense to put it
inside the pkgs.vuizvui namespace to be available for all machines.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
We need to add our own patch and don't want to clutter up the kpatches
directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 7f9f88e90b8ab41a97a86fa4ff8a501e0e0eea27.
The reason why I'm reverting this is because while it indeed fixes the
volume mapping, it doesn't fix my main problem that it takes a few
seconds to go from 100% volume to the desired volume level that's
currently set.
So instead of applying this patch and maintaining it until it may
eventually hit mainline, it's better to debug the original issue rather
than applying a patch that _may_ fix an unrelated issue.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following build error:
https://headcounter.org/hydra/build/764598
Of course, we could have fixed this by overriding Lucene++, but we want
to stay on the latest Qt version for Tomahawk anyway.
We no longer need qcaQT5, because that has been packaged upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
It's already in version 4.3-rc5, but the following patch seems to be
more correct:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/096516.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For packageOverrides, we only want to return the vuizvui attribute set
and nothing more. But if we want to import <vuizvui/pkgs>, we want to
have access to <nixpkgs> as well, which is especially useful when using
the <vuizvui> channel.
However, in callPackageWith we're explicitely using the vuizvui
attribute which should override the whole set of <nixpkgs>, so that
references to vuizvui packages don't need to be explicitly namespaced
within vuizvui itself and we can easily override existing packages with
this method as well (like just define a vuizvui package and it overrides
the dependency for all of vuizvui's packages).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This file is just defaulting to <nixpkgs>, but we're going to substitue
it by the channel generator. We also need to make sure that we don't
have any other references to <nixpkgs>, but the latter can best be done
on Hydra's side if we don't make <nixpkgs> available to vuizvui builds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
We're going to create several channels and we don't want to code
duplicates across vuizvui. This essentially not only creates a channel
but also ties it to constituents, which make sure that channels are only
updated whenever all constituent builds are successful.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|