It was required for gitlab < 9 which is not supported anymore since some time.
While removinf the V1 the patch was refreshed to cleanly work with version 11.x
This adds roccat-tools and one required dependency (libgaminggear),
which I had laying around since June 2016 but never submitted upstream
until now.
The tools are required if you want to configure one of the hardware
devices from the manufactorer ROCCAT.
Builds for both have been tested against i686-linux, x86_64-linux and
aarch64-linux.
I had this package along with libgaminggear laying around since June
2016[1] and basically just did the setup for the ROCCAT device once and
never touched it again since then. However, I got requests from other
users who might need this, so I decided to finally upstream it along
with using the latest versions.
There were a few hardcoded paths to fix, like eg. /etc/xdg and another
one that used /var/lib/roccat, the latter I moved into $XDG_DATA_HOME
instead.
The reason why I put it in os-specific/linux is that the official site
explicitly states that it's for Linux only and I specified the platforms
attribute accordingly.
[1]: https://gist.github.com/aszlig/3a01c0c23254a68c2be4c6df59e26862
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @devhell
This is a requirement for roccat-tools, which is going to be introduced
soon.
The reason why I'm using propagatedBuildInputs here is because the
pkg-config file lists *all* of the dependencies in Requires and
Requires.private, so those libraries are needed whenever any software
uses that library.
Signed-off-by: aszlig <aszlig@nix.build>
Before, providers were only built indirectly. Since proviers don't
depend on terraform to build they can be moved into their own collection
of packages. This also has the advantage that they can be reached
directly using an attribute path (Eg: terraform-providers.nixos).
Co-authored-by: Wael Nasreddine <wael.nasreddine@gmail.com>
Using a simple algorithm, convert the references to a path in to a
sorted list of dependent paths based on how often they're referenced
and how deep in the tree they live. Equally-"popular" paths are then
sorted by name.
The existing writeReferencesToFile prints the paths in a simple
ascii-based sorting of the paths.
Sorting the paths by graph improves the chances that the difference
between two builds appear near the end of the list, instead of near
the beginning. This makes a difference for Nix builds which export a
closure for another program to consume, if that program implements its
own level of binary diffing.
For an example, Docker Images. If each store path is a separate layer
then Docker Images can be very efficiently transfered between systems,
and we get very good cache reuse between images built with the same
version of Nixpkgs. However, since Docker only reliably supports a
small number of layers (42) it is important to pick the individual
layers carefully. By storing very popular store paths in the first 40
layers, we improve the chances that the next Docker image will share
many of those layers.*
Given the dependency tree:
A - B - C - D -\
\ \ \ \
\ \ \ \
\ \ - E ---- F
\- G
Nodes which have multiple references are duplicated:
A - B - C - D - F
\ \ \
\ \ \- E - F
\ \
\ \- E - F
\
\- G
Each leaf node is now replaced by a counter defaulted to 1:
A - B - C - D - (F:1)
\ \ \
\ \ \- E - (F:1)
\ \
\ \- E - (F:1)
\
\- (G:1)
Then each leaf counter is merged with its parent node, replacing the
parent node with a counter of 1, and each existing counter being
incremented by 1. That is to say `- D - (F:1)` becomes `- (D:1, F:2)`:
A - B - C - (D:1, F:2)
\ \ \
\ \ \- (E:1, F:2)
\ \
\ \- (E:1, F:2)
\
\- (G:1)
Then each leaf counter is merged with its parent node again, merging
any counters, then incrementing each:
A - B - (C:1, D:2, E:2, F:5)
\ \
\ \- (E:1, F:2)
\
\- (G:1)
And again:
A - (B:1, C:2, D:3, E:4, F:8)
\
\- (G:1)
And again:
(A:1, B:2, C:3, D:4, E:5, F:9, G:2)
and then paths have the following "popularity":
A 1
B 2
C 3
D 4
E 5
F 9
G 2
and the popularity contest would result in the paths being printed as:
F
E
D
C
B
G
A
* Note: People who have used a Dockerfile before assume Docker's
Layers are inherently ordered. However, this is not true -- Docker
layers are content-addressable and are not explicitly layered until
they are composed in to an Image.
Thanks to @symphorien for this work, which apart from the update itself
includes a few more fixes and cleanups.
I've tested building and running the upgraded Paperwork and while I
haven't done extensive testing on every little feature it seems to work
so far.
The changes also include an addition to fetchFromGitLab, which allows to
specify a group.
Merges: #46487
