| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just moving the overrides into the base profile isn't enough here,
as we wouldn't be able to refer to packages anymore, because the global
nixpkgs.config override is now gone.
Instead, we're now putting pkgs.vuizvui.* into the NixOS module system
by a new profiles/common.nix, which is used unconditionally for all
machines.
Of course, the result of this is that we now need to change all
references to vuizvui-related packages, which also is a good thing,
because we will no longer shadow existing packages from upstream
nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's currently only BeeHive, but our goal is to dissolve labernix step
by step until nothing is left.
Also, we're now no longer namespace the pkgs with vuizvui directly in
the package list. Before it wasn't even namespaced correctly (except for
inside pkgs/ directly) and we did override the packages using the dirty
approach in overrides/.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Gets rid of my own crap in the vuizvui pkgs namespace and makes it
easier for other users to selectively use my Vim configuration.
It's still not as fleshed out as I wish it would be, but let's do that
later if needed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
I'm including the whole file here, because it's easier to move it to
<nixpkgs> once version 0.9.0 is finally released.
This finally gets rid of the damn phonon dependency which cased most of
my playback issues so far.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
We now no longer override the package included in <nixpkgs>, but build
it completely from the upstream Git repository and do our patches right
after the fetchgit.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Basically this is just an old script I wrote to separate and merge color
information from the actual ASCII arts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The main reason for doing this is to avoid collisions with other vim
variants in <nixpkgs> which are expecting an .override attribute.
Moving it into pkgs/ entirely also has the advantage of being properly
namespaced rather than "all over the place" and we also don't clash
anymore with existing Vim packages.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found "nixconf" a little big too generic and thus not unlikely enough
to someday collide with something in <nixpkgs>. That's why I chose the
name "vuizvui" as a Bavarion word (actually _two_ words: "vui zvui") for
"far too much", in terms of the opposite of "nix" - which means
"nothing".
A possible downside for choosing this name is that it might be
jawbreaker to some English native speakers out there, but I don't really
care if the pronunciation is correct nor do I expect to get a lot of
public attention on this repository.
And yes, for English native speakers, a pronunciation like "fui-tsui" is
probably okay as well :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
This is going to be needed as the main application for my lighting
laptop :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|