Skaware summer 2018 release #45970
Skaware summer 2018 release #45970
Conversation
They are normally updated in lockstep, this makes maintenance more convenient.
Introduce a `skawarePackages.buildPackage` function that contains the common setup, removing a lot of duplication. In particular, we require that the build directory has to be empty after the `fixupPhase`, to make sure every relevant file is moved to the outputs. A next step would be to deduplicate the `configureFlags` attributes and only require a `skawareInputs` field.
GrahamcOfBorg
added
8.has: package (new)
| name = "${pname}-${version}"; | ||
|
|
||
| src = fetchgit { | ||
| url = "git://git.skarnet.org/${pname}"; |
There was a problem hiding this comment.
Is there a non git protocol alternative (preferable even https)? The git protocol breaks for some of our users because of proxies and has the disadvantage that trust-on-first-use is not secured by https when updating the checksum.
There was a problem hiding this comment.
Yes, I believe we can switch to https. I didn’t have time to do that yesterday.
| fi | ||
| ''; | ||
|
|
||
| meta = { |
There was a problem hiding this comment.
The disadvantage of having meta here though is that nix edit breaks: #45948
There was a problem hiding this comment.
Maybe meta.description could stay in the file itself and all other information is overridden here?
There was a problem hiding this comment.
Huh, that’s bad. I had a hunch there would be tooling that is too dumb for refactoring meta.
There was a problem hiding this comment.
Something like
meta = {
default = ""
} // userMeta;
should work no? And it also has the advantage that the reader does not have to learn about the new function because the API stays the same.
There was a problem hiding this comment.
Hm, after trying it out it looks like I need to have the meta attribute in the package calling the function. I’m not in favor of duplication to support hacks like this. :(
| mv doc $doc/share/doc/s6-networking/html | ||
| ''; | ||
| # remove all s6 executables from build directory | ||
| rm $(find -name "s6-*" -type f -mindepth 1 -maxdepth 1 -executable) |
There was a problem hiding this comment.
Why is cleaning the build directory necessary?
There was a problem hiding this comment.
It’s an experiment of mine, being more strict with how build artifacts are handled. The idea is that every file has to be either moved to an output or deleted.
If a future update introduces e.g. an example folder, the maintainer will be alerted that there’s new files that should probably go to an output.
There was a problem hiding this comment.
Do you think it is a common problem? Did you found any examples where this was the case for Skaware's software?
There was a problem hiding this comment.
I don’t know if it’s a common problem, other builds don’t register when new files are added. I strongly suspect it, since many (many!) packages don’t copy documentation, READMEs, or even manpages to their outputs.
There was a problem hiding this comment.
I am not so sure if many people are reading documentation from the nix store except for man/info pages though, which might be the reason, why it not installed by the build system in the first place. I know that debian has a policy that every command must have a man page.
| "src/**/*" | ||
| "tools/**/*" | ||
| "package/**/*" | ||
| "config.mak" |
There was a problem hiding this comment.
Why do they have be deleted from the source directory?
|
Success on x86_64-darwin (full log) Attempted: skawarePackages.nsss Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: skawarePackages.nsss Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: skawarePackages.nsss Partial log (click to expand)
|
|
@GrahamcOfBorg build skalibs s6-linux-utils execline s6-portable-utils s6-dns s6-networking s6-rc s6 |
|
Success on x86_64-linux (full log) Attempted: skalibs, s6-linux-utils, execline, s6-portable-utils, s6-dns, s6-networking, s6-rc, s6 Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: skalibs, s6-linux-utils, execline, s6-portable-utils, s6-dns, s6-networking, s6-rc, s6 Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: skalibs, execline, s6-portable-utils, s6-dns, s6-networking, s6 The following builds were skipped because they don't evaluate on x86_64-darwin: s6-linux-utils, s6-rc Partial log (click to expand)
|
It should be more performant this way.
|
Success on x86_64-linux (full log) Attempted: skawarePackages.nsss Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: skawarePackages.nsss Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: skawarePackages.nsss Partial log (click to expand)
|
|
Build with new This PR is ready from my side. |
|
Success on x86_64-linux (full log) Attempted: skalibs, s6-linux-utils, execline, s6-portable-utils, s6-dns, s6-networking, s6-rc, s6 Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: skalibs, execline, s6-portable-utils, s6-dns, s6-networking, s6 The following builds were skipped because they don't evaluate on x86_64-darwin: s6-linux-utils, s6-rc Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: skalibs, s6-linux-utils, execline, s6-portable-utils, s6-dns, s6-networking, s6-rc, s6 Partial log (click to expand)
|
Motivation for this change
https://www.mail-archive.com/skaware@list.skarnet.org/msg01217.html
Each package in the skaware stack is structured pretty much exactly the same way, so there was tremendous duplication in the way those packages were defined. This removes most of that duplication.
The commits are incremental and are best reviewed one-by-one.
The nsss package is added, most of the stack supports optionally using this library, this is not yet added (if we want to run the tests for nsss there is a circular dependency on
s6to make things harder).cc other maintainer @pmahoney
Closes #45066.
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)