This attribute was supposed to be set on derivations, to make the
release tools recurse into them. The remaining uses were all on regular
attrsets, though, so this is safe to remove.
Due to Nix bug <https://github.com/NixOS/nix/issues/11503>,
`builtins.filterSource` and chroot stores interact in a confusing
and broken way that breaks `lib.fileset`. This means that uses of
the API inside Nixpkgs keep breaking the NixOS installer, blocking
the channel. The resulting error messages are inscrutable (they look
like “the installer test is trying to download `curl`…?” and
eventually bottom out in a derivation that has the wrong `outPath`
because of the chroot store causing an incorrect `lib.fileset` result).
Whenever this happens, someone (well, in practice K900 or I)
has to bisect the change that introduced it and remove the use of
`lib.fileset`. This has happened at least three times in the past
four months (I believe I might actually be missing one here, but
these are the ones I remember and could easily dig up):
* <https://github.com/NixOS/nixpkgs/pull/340046>
* <https://github.com/NixOS/nixpkgs/pull/352491>
* <https://github.com/NixOS/nixpkgs/pull/369459>
The options I see here are:
1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is
fixed. This is the approach taken here. External users of Nixpkgs
can continue to use the API as normal, but using it from within
something that affects any release jobset `outPath`s will cause an
evaluation failure with a hopefully‐helpful error message.
2. Forbid `lib.fileset` and also all of the other library APIs that use
`builtins.filterSource`. I’m happy to do this, but so far none of
those have broken the installer, so I decided to start small and
worry about the others if they end up causing a problem in practice.
3. Forbid `builtins.filterSource` directly. This is hard and would
require more invasive `builtins.scopedImport` crimes to do at
evaluation time. I think this would realistically have to be done in
something like nixpkgs-vet instead and I didn’t have much luck
shoehorning a check like this into that codebase when I tried.
4. Fix the Nix bug. This would be great! But also it doesn’t seem to be
happening any time soon, it seems difficult to fix in a way that
doesn’t subtly break compatibility with the previous semantics, and
arguably the fix would need backporting all the way back to 2.3
given our minimum version policy.
5. Do nothing; have people continue to innocuously use `lib.fileset`
throughout Nixpkgs, breaking the installer whenever one of them
sneaks in to that closure, causing the channel to be blocked and
requiring expensive bisections to narrow down the inscrutable test
failure to the package using `lib.fileset`, which then needs moving
back off it. This sucks for the people who keep having to track it
down, holds back important channel bumps, and the criteria for when
it’s okay to use `lib.fileset` are not realistically possible to
teach to all contributors.
I'd be happy to work on (2) as an alternative; (3) would be difficult
and seems like overkill, (4) is not really something I trust myself
to do and wouldn’t address the immediate problem, and (5) isn’t
sustainable. I think that the current approach here is the best
trade‐off for now, as `lib.fileset` seems to be the only prominent
user of the `builtins.filterSource` API that works with full store
paths, exposing it to the Nix bug. It’s unfortunate to lose the
nice API, but since we can’t rely on it to produce correct results
and the channels keep getting blocked as a result, I don’t think
we really have an alternative right now.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
Having multiple attributes point to the same derivation makes debugging
harder because you often cannot just grep the canonical attribute name.
It is even annoying when multiple aliases are chained.
Having Hydra build aliases is recognized as redundant
2d0a7c4eee
so let’s do the same with their evaluation.
This commit will make Hydra ignore aliases when evaluating.
A nice benefit of this is that it will allow us to warn users when
an attribute is renamed, to assist them with early migration. Since
tracing messages during evaluation are not allowed because of Hydra,
we can currently only choose between having a silent alias and throwing.
This was last attempted in 2018 but ended up being reverted
because of widespread use of aliases that was not caught by CI:
8c025c67d5
CI has since been improved:
cda5aa2ac7
For some reason I had the impression this option existed, but it doesn't.
Sadly `nixpkgs.config` is a freeform type attrset, that wouldn't even
bark at me, so I didn't notice this will testing.
Home Assistant is a big part of nixpkgs python ecosystem and how I
started participating in python maintenance.
Recently it started including `openssl_1_1` in its transitive dependency
closure, which resulted in its exclusion from python-updates.
This is detrimental to the health of the `home-assistant` ecosystem,
since it would not be built and tested anymore.
Permitting `openssl_1_1` for python-updates, as was done for
`release.nix`, will allow me to get in contact with the upstream, to
hopefully arrive at a favorable outcome.
cherrytree - A hierarchical note taking application, featuring rich text
and syntax highlighting, storing data in a single xml or sqlite file.
This commit also adds PyGtkSourceView - a Python wrapper for the GtkSourceView widget library.
Official page http://www.giuspen.com/cherrytree
I think this makes sense, because now all the plugins will be gnome3 gtk3
based, the same way nm-applet is.
I also removed networkmanager_pptp_gnome variation of networkmanager_pptp
package, because i think no variation is needed and gnome support should
be on by default like in other packages.
Some packages in the llvm suite (e.g. compiler-rt) cannot be built
separate from the build of llvm, and while some others (e.g. clang) can
the combined build is much better tested (we've had to work around
annoying issues before). So this puts llvm, clang, clang-tools-extra,
compiler-rt, lld, lldb, and polly all into one big build (llvmFull).
This build includes a static llvm, as dynamic is similarly less tested
and has known failures.
This also updates libc++ and dragonegg. libc++ now builds against
libc++abi as a separate package rather than building it during the
libc++ build.
The clang purity patch is gone. Instead, we simply set --sysroot to
/var/empty for pure builds, as all impure paths are either looked up in
the gcc prefix (which we hard-code at compile time) or in the sysroot.
This also means that if NIX_ENFORCE_PURITY is 0 then clang will look in
the normal Linux paths by default, which is the proper behavior IMO.
polly required an updated isl. When stdenv-updates is merged, perhaps we
can update the isl used by gcc and avoid having two versions.
Since llvm on its own is now separate from the llvm used by clang, I've
removed myself as maintainer from llvm and will leave maintenance of
that to those who are interested in llvm separate from clang.
Signed-off-by: Shea Levy <shea@shealevy.com>
In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
