# I tried to update the packages and now it won't rebuild
**URL:** https://discourse.nixos.org/t/i-tried-to-update-the-packages-and-now-it-wont-rebuild/80244
**Category:** Help
**Created:** [September 23, 2026, 5:09pm UTC](https://discourse.nixos.org/t/i-tried-to-update-the-packages-and-now-it-wont-rebuild/80244 "2026-09-23T17:09:38Z")
**Posts on this page:** 9
**Page:** 1
I tried to install openjdk25 but it said that the variable wasn’t found. Turns out i have had an unupdated system/channel for some time now (25.05 instead of 26.05) even thougth I have ran `sudo nix-channel --update` and `sudo nixos-rebuild switch --upgrade` multiple times. Each time it just showed verison 25.05 again.
I have checked many topics on this site and tried a couple things:
First I changed the `NIX_PATH` variable to `/nix/var/nix/profiles/per-user/root/channels` as stated in [this post](https://discourse.nixos.org/t/nixos-packages-are-not-upgrading-even-though-i-am-certainly-configured-to-unstable-system-state/59828/13) (and tried many other variations that also didn’t work, both with and without export and many other things). I belive then it stopped rebuilding and throwing an error like this:
> **Error message**
>
> ```auto
> [francesccs@nixos:~]$ sudo nixos-rebuild switch
> warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixos' does not exist, ignoring
> error:
> … while calling the 'import' builtin
> at «string»:1:6:
> 1| with import {}; config.system.build.nixos-rebuild
> | ^
>
> … while realising the context of a path
>
> … while calling the 'findFile' builtin
> at «string»:1:13:
> 1| with import {}; config.system.build.nixos-rebuild
> | ^
>
> error: file 'nixpkgs/nixos' was not found in the Nix search path (add it using $NIX_PATH or -I)
> building Nix...
> warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixos' does not exist, ignoring
> error: file 'nixpkgs/nixos' was not found in the Nix search path (add it using $NIX_PATH or -I)
> warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixos' does not exist, ignoring
> error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
> warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixos' does not exist, ignoring
> error: file 'nixpkgs/nixos/modules/installer/tools/nix-fallback-paths.nix' was not found in the Nix search path (add it using $NIX_PATH or -I)
> /tmp/nixos-rebuild.10pRm0/nix
> warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixos' does not exist, ignoring
> error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
> building the system configuration...
> warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixos' does not exist, ignoring
> error: file 'nixpkgs/nixos' was not found in the Nix search path (add it using $NIX_PATH or -I)
>
> ```
(Note that this is the error that I get now so possibley a bit diferent to what I got then but I remeber it almost identical)
Then I tried updating the channels. This is what I did:
1. Added the worng channel
2. Deleted the wrong channel
3. Added the 26.05 channel (with no name, wich idk if it causes issues)
4. Removed the original 25.05 channel
When getting errors again trying to rebuild I visited the folders on the `NIX_PATH` and saw that the `/nix/var/nix/profiles/per-user/root/channels` was empty. There were also 3 other folders named “channels-_number_-link” with numbers 1 to 3. Number 1 and 2 were pretty simmilar except that 2 had a database file that 1 didn’t have. Number 3 had nothing but a license on it.
I then saw that folder `channels-2-link` had 36 nesting folders of nixpckgs containing a copy of it’s root folder. Then I visited a post that said it was normal so I kind of ignore it now, but I don’t know what to set the `NIX_PATH` variable anymore.
Now I have checked the `/nix/var/nix/profiles/per-user/root/channels` folder again and it now contains a folder named **`nixos-26.05`**. I tried rebuilding again but it still doesn’t work. Now there is also a new folder named _`channels-4-link`_.
---
Could you also share how you write your configuration? I’ve seen people make this mistake where they use flakes but try to “update” by using `nix-channel`, so I’d like to make sure that isn’t the case for you.
---
```auto
[francesccs@nixos:/]$ nix-channel --list
[francesccs@nixos:/]$ sudo nix-channel --list
[sudo] password for francesccs:
nixos-26.05 https://channels.nixos.org/nixos-26.05
```
Without sudo it shows nothing and with it only the 26.05 channel that I added.
---
I think your channel is named wrong:
> **[Changing Nixpkgs version - Updating NixOS - Official NixOS Wiki](https://wiki.nixos.org/wiki/Updating_NixOS#Changing_Nixpkgs_version)**
>
> To see what is the latest channel available, see https://channels.nixos.org/.
Pretty sure you want `nix-channel --add https://channels.nixos.org/nixos-26.05 nixos` and you probably left off the `nixos` at the end so it took the name `nixos-26.05` instead. Run as root or with `sudo`.
I’ll also add that this is a great time to evaluate adding some form of input pinning. Ergonomics with `npins` is pretty good and I’ve been eying `nixtamal`. That way you never have the type of issue you have been experiencing.
---
Thank you! I have done that successfully and now it produces a different error. (which is a very big step in the right direction).
```auto
[francesccs@nixos:/]$ sudo nix-channel --list
nixos https://channels.nixos.org/nixos-26.05
```
This is the error that I get now:
> **Errors**
>
> ```auto
> [francesccs@nixos:/etc/nixos]$ sudo nixos-rebuild switch --upgrade
> unpacking 1 channels...
> unpacking 1 channels...
> building the system configuration...
> error:
> … while calling the 'derivationStrict' builtin
> at «nix-internal»/derivation-internal.nix:37:12:
> 36|
> 37| strict = derivationStrict drvAttrs;
> | ^
> 38|
>
> … while evaluating derivation 'nixos-system-nixos-26.05.10478.1bc55b9def81'
> whose name attribute is located at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/make-derivation.nix:647:11
>
> … while evaluating attribute 'buildCommand' of derivation 'nixos-system-nixos-26.05.10478.1bc55b9def81'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/nixos/modules/system/activation/top-level.nix:63:7:
> 62| allowSubstitutes = false;
> 63| buildCommand = systemBuilder;
> | ^
> 64|
>
> … while evaluating the option `environment.etc.dbus-1.source':
>
> (stack trace truncated; use '--show-trace' to show the full, detailed trace)
>
> error: Refusing to evaluate package 'electron-39.8.10' in /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/development/tools/electron/binary/generic.nix:50 because it is marked as insecure
>
> Known issues:
> - Electron version 39.8.10 is EOL
>
> You can install it anyway by allowing this package, using the
> following methods:
>
> a) To temporarily allow all insecure packages, you can use an environment
> variable for a single invocation of the nix tools:
>
> $ export NIXPKGS_ALLOW_INSECURE=1
>
> Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
> then pass `--impure` in order to allow use of environment variables.
>
> b) for `nixos-rebuild` you can add ‘electron-39.8.10’ to
> `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
> like so:
>
> {
> nixpkgs.config.permittedInsecurePackages = [
> "electron-39.8.10"
> ];
> }
>
> c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
> ‘electron-39.8.10’ to `permittedInsecurePackages` in
> ~/.config/nixpkgs/config.nix, like so:
>
> {
> permittedInsecurePackages = [
> "electron-39.8.10"
> ];
> }
> Command 'nix-build '' --attr config.system.build.toplevel --no-out-link' returned non-zero exit status 1.
>
> ```
On the first error I guess I could do the “show trace” thing. On the second error I don’t know if I can somehow make it not use the unsafe package of electron (I do not have it in my config) or if I should just allow it as unsafe.
Here is the error with “–show-trace”:
> **Error with “–show-trace”**
>
> ```auto
> [francesccs@nixos:/etc/nixos]$ sudo nixos-rebuild switch --upgrade --show-trace
> unpacking 1 channels...
> unpacking 1 channels...
> building the system configuration...
> error:
> … while calling the 'derivationStrict' builtin
> at «nix-internal»/derivation-internal.nix:37:12:
> 36|
> 37| strict = derivationStrict drvAttrs;
> | ^
> 38|
>
> … while evaluating derivation 'nixos-system-nixos-26.05.10478.1bc55b9def81'
> whose name attribute is located at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/make-derivation.nix:647:11
>
> … while evaluating attribute 'buildCommand' of derivation 'nixos-system-nixos-26.05.10478.1bc55b9def81'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/nixos/modules/system/activation/top-level.nix:63:7:
> 62| allowSubstitutes = false;
> 63| buildCommand = systemBuilder;
> | ^
> 64|
>
> … while calling the 'getAttr' builtin
> at «nix-internal»/derivation-internal.nix:50:17:
> 49| value = commonAttrs // {
> 50| outPath = builtins.getAttr outputName strict;
> | ^
> 51| drvPath = strict.drvPath;
>
> … while calling the 'derivationStrict' builtin
> at «nix-internal»/derivation-internal.nix:37:12:
> 36|
> 37| strict = derivationStrict drvAttrs;
> | ^
> 38|
>
> … while evaluating derivation 'etc'
> whose name attribute is located at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/make-derivation.nix:647:11
>
> … while evaluating attribute 'buildCommand' of derivation 'etc'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/build-support/trivial-builders/default.nix:81:17:
> 80| enableParallelBuilding = true;
> 81| inherit buildCommand name;
> | ^
> 82| passAsFile = ["buildCommand"] ++ (derivationArgs.passAsFile or []);
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/nixos/modules/system/etc/etc.nix:56:11:
> 55| mkdir -p "$out/etc"
> 56| ${lib.concatMapStringsSep "\n" (
> | ^
> 57| etcEntry:
>
> … while calling 'concatMapStringsSep'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:262:13:
> 261| concatMapStringsSep =
> 262| sep: f: list:
> | ^
> 263| concatStringsSep sep (map f list);
>
> … while calling the 'concatStringsSep' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:263:5:
> 262| sep: f: list:
> 263| concatStringsSep sep (map f list);
> | ^
> 264|
>
> … while calling anonymous lambda
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/nixos/modules/system/etc/etc.nix:57:11:
> 56| ${lib.concatMapStringsSep "\n" (
> 57| etcEntry:
> | ^
> 58| lib.escapeShellArgs [
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/nixos/modules/system/etc/etc.nix:58:11:
> 57| etcEntry:
> 58| lib.escapeShellArgs [
> | ^
> 59| "makeEtcEntry"
>
> … while calling 'concatMapStringsSep'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:262:13:
> 261| concatMapStringsSep =
> 262| sep: f: list:
> | ^
> 263| concatStringsSep sep (map f list);
>
> … while calling the 'concatStringsSep' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:263:5:
> 262| sep: f: list:
> 263| concatStringsSep sep (map f list);
> | ^
> 264|
>
> … while calling 'escapeShellArg'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:1201:5:
> 1200| escapeShellArg =
> 1201| arg:
> | ^
> 1202| let
>
> … while evaluating a branch condition
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:1205:5:
> 1204| in
> 1205| if match "[[:alnum:],._+:@%/-]+" string == null then
> | ^
> 1206| "'${replaceString "'" "'\\''" string}'"
>
> … while calling the 'match' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:1205:8:
> 1204| in
> 1205| if match "[[:alnum:],._+:@%/-]+" string == null then
> | ^
> 1206| "'${replaceString "'" "'\\''" string}'"
>
> … while evaluating the second argument passed to builtins.match
>
> … while calling the 'toString' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:1203:16:
> 1202| let
> 1203| string = toString arg;
> | ^
> 1204| in
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/nixos/modules/system/etc/etc.nix:61:16:
> 60| # Force local source paths to be added to the store
> 61| "${etcEntry.source}"
> | ^
> 62| etcEntry.target
>
> … while calling anonymous lambda
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/attrsets.nix:1192:17:
> 1191| mapAttrs (
> 1192| name: value:
> | ^
> 1193| if isAttrs value && cond value then recurse (path ++ [name]) value else f (path ++ [name]) value
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/attrsets.nix:1193:85:
> 1192| name: value:
> 1193| if isAttrs value && cond value then recurse (path ++ [name]) value else f (path ++ [name]) value
> | ^
> 1194| );
>
> … while calling anonymous lambda
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:283:71:
> 282| # For definitions that have an associated option
> 283| declaredConfig = mapAttrsRecursiveCond (v: !isOption v) (_: v: v.value) options;
> | ^
> 284|
>
> … while evaluating the attribute 'value'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1167:7:
> 1166| // {
> 1167| value = addErrorContext "while evaluating the option `${showOption loc}':" value;
> | ^
> 1168| inherit (res.defsFinal') highestPrio;
>
> … while evaluating the option `environment.etc.dbus-1.source':
>
> … while evaluating the attribute 'mergedValue'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1264:5:
> 1263| # Type-check the remaining definitions, and merge them. Or throw if no definitions.
> 1264| mergedValue =
> | ^
> 1265| if isDefined then
>
> … while evaluating a branch condition
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1273:14:
> 1272| checkedAndMerged.value
> 1273| else if all (def: type.check def.value) defsFinal then
> | ^
> 1274| type.merge loc defsFinal
>
> … while calling the 'all' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1273:17:
> 1272| checkedAndMerged.value
> 1273| else if all (def: type.check def.value) defsFinal then
> | ^
> 1274| type.merge loc defsFinal
>
> … while calling anonymous lambda
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1273:22:
> 1272| checkedAndMerged.value
> 1273| else if all (def: type.check def.value) defsFinal then
> | ^
> 1274| type.merge loc defsFinal
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1273:27:
> 1272| checkedAndMerged.value
> 1273| else if all (def: type.check def.value) defsFinal then
> | ^
> 1274| type.merge loc defsFinal
>
> … while calling 'check'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/types.nix:723:11:
> 722| check =
> 723| x:
> | ^
> 724| let
>
> … in the right operand of the AND (&&) operator
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/types.nix:740:11:
> 739| && (inStore == null || inStore == isInStore)
> 740| && (absolute == null || absolute == isAbsolute);
> | ^
> 741| };
>
> … in the right operand of the OR (||) operator
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/types.nix:740:32:
> 739| && (inStore == null || inStore == isInStore)
> 740| && (absolute == null || absolute == isAbsolute);
> | ^
> 741| };
>
> … while calling the 'substring' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/types.nix:733:26:
> 732| );
> 733| isAbsolute = substring 0 1 (toString x) == "/";
> | ^
> 734| isExpectedType = (
>
> … while calling the 'toString' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/types.nix:733:41:
> 732| );
> 733| isAbsolute = substring 0 1 (toString x) == "/";
> | ^
> 734| isExpectedType = (
>
> … while calling the 'getAttr' builtin
> at «nix-internal»/derivation-internal.nix:50:17:
> 49| value = commonAttrs // {
> 50| outPath = builtins.getAttr outputName strict;
> | ^
> 51| drvPath = strict.drvPath;
>
> … while calling the 'derivationStrict' builtin
> at «nix-internal»/derivation-internal.nix:37:12:
> 36|
> 37| strict = derivationStrict drvAttrs;
> | ^
> 38|
>
> … while evaluating derivation 'dbus-1'
> whose name attribute is located at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/make-derivation.nix:647:11
>
> … while evaluating attribute 'serviceDirectories' of derivation 'dbus-1'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/by-name/ma/makeDBusConf/package.nix:19:13:
> 18| {
> 19| inherit serviceDirectories suidHelper apparmor;
> | ^
> 20| preferLocalBuild = true;
>
> … while calling anonymous lambda
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/types.nix:781:26:
> 780| headError = checkDefsForError check loc defs;
> 781| value = map (x: x.optionalValue.value or x.mergedValue) evals;
> | ^
> 782| valueMeta.list = map (v: v.checkedAndMerged.valueMeta) evals;
>
> … while evaluating the attribute 'optionalValue.value'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/modules.nix:1330:41:
> 1329|
> 1330| optionalValue = if isDefined then { value = mergedValue; } else { };
> | ^
> 1331| };
>
> (11 duplicate frames omitted)
>
> … while evaluating derivation 'system-path'
> whose name attribute is located at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/make-derivation.nix:647:11
>
> … while evaluating attribute 'chosenOutputs' of derivation 'system-path'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/build-support/buildenv/default.nix:116:9:
> 115|
> 116| chosenOutputs = map (drv: {
> | ^
> 117| paths =
>
> … while evaluating list element at index 43
>
> … while evaluating attribute 'paths'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/build-support/buildenv/default.nix:117:11:
> 116| chosenOutputs = map (drv: {
> 117| paths =
> | ^
> 118| # First add the usual output(s): respect if user has chosen explicitly,
>
> … while evaluating list element at index 0
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/build-support/buildenv/default.nix:117:11:
> 116| chosenOutputs = map (drv: {
> 117| paths =
> | ^
> 118| # First add the usual output(s): respect if user has chosen explicitly,
>
> … while calling the 'getAttr' builtin
> at «nix-internal»/derivation-internal.nix:50:17:
> 49| value = commonAttrs // {
> 50| outPath = builtins.getAttr outputName strict;
> | ^
> 51| drvPath = strict.drvPath;
>
> … while calling the 'derivationStrict' builtin
> at «nix-internal»/derivation-internal.nix:37:12:
> 36|
> 37| strict = derivationStrict drvAttrs;
> | ^
> 38|
>
> … while evaluating derivation 'logseq-0.10.15'
> whose name attribute is located at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/make-derivation.nix:647:11
>
> … while evaluating attribute 'installPhase' of derivation 'logseq-0.10.15'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/by-name/lo/logseq/package.nix:249:3:
> 248|
> 249| installPhase = ''
> | ^
> 250| runHook preInstall
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/by-name/lo/logseq/package.nix:255:5:
> 254| ''
> 255| + lib.optionalString stdenv.hostPlatform.isLinux ''
> | ^
> 256| install -Dm644 static/icons/logseq.png "$out/share/icons/hicolor/512x512/apps/logseq.png"
>
> … while calling 'optionalString'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/strings.nix:766:26:
> 765| */
> 766| optionalString = cond: string: if cond then string else "";
> | ^
> 767|
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/by-name/lo/logseq/package.nix:261:19:
> 260|
> 261| makeWrapper ${lib.getExe electron} $out/bin/logseq \
> | ^
> 262| --add-flags $out/share/logseq/resources/app \
>
> … while calling 'getExe'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/meta.nix:527:5:
> 526| getExe =
> 527| x:
> | ^
> 528| getExe' x (
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/meta.nix:528:5:
> 527| x:
> 528| getExe' x (
> | ^
> 529| x.meta.mainProgram or (
>
> … while calling 'getExe''
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/meta.nix:573:8:
> 572| getExe' =
> 573| x: y:
> | ^
> 574| assert assertMsg (isDerivation x)
>
> … in the condition of the assert statement
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/lib/customisation.nix:414:13:
> 413| outPath =
> 414| assert condition;
> | ^
> 415| drv.${outputName}.outPath;
>
> … while evaluating the attribute 'handled'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/check-meta.nix:710:9:
> 709| valid = "no";
> 710| handled = handle {
> | ^
> 711| inherit attrs meta;
>
> … from call site
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/check-meta.nix:710:19:
> 709| valid = "no";
> 710| handled = handle {
> | ^
> 711| inherit attrs meta;
>
> … while calling 'handle'
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/check-meta.nix:651:5:
> 650| handle =
> 651| {
> | ^
> 652| attrs,
>
> … while calling the 'seq' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/check-meta.nix:685:5:
> 684| # Give all warnings first, then error if any
> 685| builtins.seq (foldl' giveWarning null warnings) withError;
> | ^
> 686|
>
> … while calling the 'throw' builtin
> at /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/stdenv/generic/check-meta.nix:673:13:
> 672| else
> 673| throw msg;
> | ^
> 674|
>
> error: Refusing to evaluate package 'electron-39.8.10' in /nix/store/16p5yr3m9p0y7ain2gin15rnnbbh0nyp-nixos-26.05/nixos/pkgs/development/tools/electron/binary/generic.nix:50 because it is marked as insecure
>
> Known issues:
> - Electron version 39.8.10 is EOL
>
> You can install it anyway by allowing this package, using the
> following methods:
>
> a) To temporarily allow all insecure packages, you can use an environment
> variable for a single invocation of the nix tools:
>
> $ export NIXPKGS_ALLOW_INSECURE=1
>
> Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
> then pass `--impure` in order to allow use of environment variables.
>
> b) for `nixos-rebuild` you can add ‘electron-39.8.10’ to
> `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
> like so:
>
> {
> nixpkgs.config.permittedInsecurePackages = [
> "electron-39.8.10"
> ];
> }
>
> c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
> ‘electron-39.8.10’ to `permittedInsecurePackages` in
> ~/.config/nixpkgs/config.nix, like so:
>
> {
> permittedInsecurePackages = [
> "electron-39.8.10"
> ];
> }
> Command 'nix-build '' --attr config.system.build.toplevel --no-out-link --show-trace' returned non-zero exit status 1.
>
> ```
Thanks to all of you so far for the help!
---
> [@NotAPotteryMaster](#):
>
> ```auto
> nixpkgs.config.permittedInsecurePackages = [
> "electron-39.8.10"
> ];
>
> ```
TL;DR: add this to your config or remove logseq.
Pro tip: grep the `--show-trace` output for `while evaluating derivation` to see an oftentimes more useful trace.
See:
>
>
> \### Nixpkgs version
>
> \- Stable (26.05)
>
> \### Describe the bug
>
> error: Refusing to …evaluate package 'electron-39.8.10' in /nix/store/snzg7swkp0vsd2qch9izsbmxnyb13ca0-source/pkgs/development/tools/electron/binary/generic.nix:50 because it is marked as insecure
>
> Known issues:
> - Electron version 39.8.10 is EOL
>
> Getting this error because Logseq has an input of electron\_39 and that was marked insecure in https://github.com/NixOS/nixpkgs/pull/521310
>
> I'm also seeing this issue for bitwarden-desktop, and am currently overriding the input to electron\_40 in my config.
> I would be happy to contribute the fix! Might need a little direction as I haven't worked with nixpkgs before.
>
> \### Steps to reproduce
>
> Add logseq to home.packages and configuration build should fail.
> Not sure how one would reproduce this from a nixpkgs repo.
>
> \### Expected behaviour
>
> Build successfully without errors
>
> \### Screenshots
>
> \_No response\_
>
> \### Relevant log output
>
> \`\`\`console
>
> \`\`\`
>
> \### Additional context
>
> \_No response\_
>
> \### System metadata
>
> - system: \`"x86\_64-linux"\`
> - host os: \`Linux 6.12.80, NixOS, 25.11 (Xantusia), 25.11.20260410.54170c5\`
> - multi-user?: \`yes\`
> - sandbox: \`yes\`
> - version: \`nix-env (Nix) 2.31.4\`
> - nixpkgs: \`/nix/store/m5dr0w2wb9lca77ar3idab31szd6mix7-source\`
>
> \### Notify maintainers
>
> @TomaSajt
>
> \---
>
> \*\*Note for maintainers:\*\* Please tag this issue in your pull request description. (i.e. \`Resolves #ISSUE\`.)
>
>
> \### I assert that this issue is relevant for Nixpkgs
>
> \- \[x\] I assert that this is a bug and not a support request.
> \- \[x\] I assert that this is not a \[duplicate of an existing issue\](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+label%3A%220.kind%3A+bug%22+-label%3A%226.topic%3A+darwin%22+-label%3A%226.topic%3A+nixos%22).
> \- \[x\] I assert that I have read the \[NixOS Code of Conduct\](https://github.com/NixOS/.github/blob/master/CODE\_OF\_CONDUCT.md) and agree to abide by it.
> \- \[x\] I assert that I have read the \[automation/AI policy\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#automationai-policy) and that this issue report complies with it.
>
> \### Is this issue important to you?
>
> Add a :+1: \[reaction\] to \[issues you find important\].
>
> \[reaction\]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
> \[issues you find important\]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
>
>
> Fixes #32.
>
> \## What changed
>
> Upgrades Electron 41.7.1 → 43.4.1 and restores plug…in loading, plugin HTTP, and local asset
> loading — all three broken by the newer Chromium. No change to what a plugin is allowed to reach.
>
> 1. \*\*Electron 41.7.1 → 43.4.1.\*\* 41.x reached end of life on 2026-08-25; 43.x is supported to
> 2027-01-05. \`better-sqlite3\` 12.10.0 no longer compiles against Electron 43's V8
> (\`SetNativeDataProperty\` is ambiguous against the three overloads now in \`v8-template.h\`);
> 13.0.3 fixes that and ships N-API prebuilds, so it no longer needs an \`electron-rebuild\` pass
> per Electron major. \`node-abi\` bumped to 4.33.0. 43 rather than 44 because 44.0.0 was two days
> old when this was prepared and 43.4.1 is a matured patch line; 44 is a straightforward
> follow-up once it has settled.
>
> 2. \*\*Renderer served over \`lsp://\` instead of \`file://\`.\*\* Electron 40 tightened opaque-origin
> rules: a \`file://\` renderer makes the parent origin opaque, which breaks the \`postMessage\`
> handshake plugin iframes rely on, so \*\*no plugin loads at all\*\*. \`lsp://\` can no longer serve
> static app files from one flat root, so routes are namespaced into \`/plugins/\` (dot-root
> installs) and \`/external/\/\` (plugins installed elsewhere), with everything
> else resolving against \`\_\_dirname\`. The bare legacy form \`lsp://logseq.io/\/...\` is still
> accepted — themes register under it and their URLs are persisted in \`preferences.json\` and
> \`localStorage\`, so rejecting it silently breaks every installed theme on upgrade. Ported from
> logseq/logseq#12741.
>
> 3. \*\*Plugin HTTP restored, two ways.\*\* Serving the renderer over \`lsp://\` gives plugin frames a
> real tuple origin, so Chromium began enforcing CORS on requests they make; under \`file://\`
> none applied and the same calls worked. Most endpoints a plugin talks to send no
> \`Access-Control-Allow-Origin\` at all (ordinary web pages, local APIs such as Zotero or
> Syncthing) or omit the plugin's custom client header from \`Access-Control-Allow-Headers\`.
> Observed breakage: Readwise sync, url-title-tagger, and Syncthing/Zotero-backed plugins
> (logseq/logseq#12736).
> - \*\*A \`fetch\` bridge in the SDK\*\* (\`LSPlugin.user.ts\`) routes http(s) \`fetch\` from a plugin
> frame through the main process, which sidesteps the browser's CORS layer rather than
> relaxing it. The \`:httpRequest\` handler gains \`includeResponse\` so the bridge can rebuild a
> real \`Response\` with its status, headers and URL. Anything the bridge cannot carry
> faithfully keeps the native implementation instead of being silently altered: non-http(s)
> URLs (\`lsp://\` assets, \`data:\`, \`blob:\`, relative paths), \`credentials: 'include'\` (a
> main-process request has no cookies), and a non-string body such as \`FormData\`, \`Blob\` or
> \`ArrayBuffer\` (the handler would JSON-serialise it into \`{}\`). \`AbortSignal\` is wired
> through to the host's own abort path, and an abort is never retried on the native path.
> - \*\*A permissive CORS response for plugin frames\*\* covers what the bridge cannot: XHR, and
> anything issued before the bridge installs. It publishes
> \`Access-Control-Expose-Headers: \*\` alongside the wildcard origin, since under \`file://\` a
> plugin could read every response header and the CORS-safelisted six are not enough for the
> \`Link\`/\`ETag\`/\`X-RateLimit\` headers real APIs answer with.
>
> 4. \*\*Local assets served over \`assets://\` instead of \`file://\`.\*\* The third thing the origin
> move breaks, and the one that is hardest to read from its symptom. Chromium refuses a
> \`file://\` subresource from the non-file \`lsp://logseq.com\` origin, but
> \`frontend.handler.assets/normalize-asset-resource-url\` still built \`file://\` URLs — a
> builder that had always been correct and stayed correct-\*looking\*. Three faces:
> - \*\*PDFs fail with a message that blames the file.\*\* pdf.js maps a request that failed at the
> network layer to \`Missing PDF "file:///…pdf"\` whenever the URL is \`file:\`
> (\`status === 0 && url.startsWith("file:")\`), so a \*blocked read\* and a \*deleted file\* are
> indistinguishable to the user. The file is on disk and readable the whole time.
> - \*\*Alias-path images fail silently\*\* — same builder, \`\\` \`naturalWidth\` 0, no error a
> user ever sees.
> - \*\*Plugin themes fail, via a rewrite that used to be the fix.\*\* \`assets-theme-to-file\`
> deliberately rewrote an \`assets://\` theme URL (SDK \`\_loadConfigThemes\`) to \`file://\` before
> \`injectTheme\` added the \`\\`; the link now errors and the theme silently
> never applies. Over \`assets://\` the stylesheet loads, applies, \*\*and\*\* resolves its own
> relative \`url()\` references, so the rewrite has no purpose left and is removed rather than
> left as an identity function.
>
> Images inside the graph kept working throughout, which is why this was easy to miss: the app
> has \*\*two\*\* asset-URL builders and only \`editor/make-asset-url\` already produced \`assets://\`.
> Fixed in the builder rather than at the PDF viewer, so all three faces are covered at once.
>
> \`assets://\` gains \`supportFetchAPI\` + \`corsEnabled\` — it is a different origin from
> \`lsp://logseq.com\`, so the renderer reading it is a cross-origin request Chromium otherwise
> refuses outright. \`standard\` deliberately \*\*stays false\*\*: under a standard scheme Chromium
> reparses the URL and an absolute path's leading slash becomes the \*\*hostname\*\*
> (\`assets:///home/x\` arrives as host \`home\`, path \`/x\`; on Windows the drive letter becomes the
> host), which resolves to a relative path that only works by accident.
>
> 5. \*\*\`logseq.Request\` initiates over \`postMessage\`.\*\* It used
> \`Experiments.invokeExperMethod\`, which does a synchronous \`window.top.logseq\` read — that
> throws for a plugin iframe on a different origin than the host, i.e. every \`:effect false\`
> plugin, so requests never started. Ported from logseq/logseq#12753. The abort path already
> went through the caller.
>
> 6. \*\*A string request body is no longer double-encoded.\*\* \`handler.cljs\` ran \`JSON.stringify\`
> over a body that was already a string, breaking the common
> \`fetch(url, {body: JSON.stringify(x)})\` shape.
>
> 7. \*\*Path containment on the \`lsp://\` handler\*\* (\`resolveWithin\`), plus a startup allowlist of
> legitimate external plugin roots — and the same containment for \`assets://\` (below).
>
> \## Why the CORS relaxation is not a new capability
>
> A \*\*wildcard\*\* origin is published, deliberately, not the echoed request origin. The browser
> rejects \`\*\` for credentialed requests, so cookie-bearing cross-origin reads stay blocked. Echoing
> the origin would let a plugin read another site's authenticated responses — a real escalation.
>
> Beyond that it grants nothing new: any plugin can already issue unrestricted HTTP via
> \`logseq.Request\` → \`exper\_request\` → \`node-fetch\` in the main process, with no CORS at all.
> Browser CORS was never a boundary against a hostile plugin here, only a tax on honest ones using
> plain \`fetch\`. Unlike \`webSecurity: false\`, the same-origin policy for DOM access and
> mixed-content blocking are untouched.
>
> The relaxation is scoped and fails closed:
>
> \- Only plugin frames — the main renderer is \*\*also\*\* \`lsp://logseq.com\` (\`electron.html\`), so
> matching on the scheme alone would relax the app's own requests. Plugin paths are matched
> specifically.
> \- Only \`xhr\`/\`other\` resource types, which are the ones that read a cross-origin body.
> \- Identity is resolved in \`onBeforeRequest\`, where the frame is still alive, and recorded against
> the webRequest id. Electron documents \`details.frame\` as nullable once a frame has navigated or
> been destroyed, which is exactly the state it can be in at \`onHeadersReceived\` time. Anything
> not positively attributed is left untouched.
> \- The \`onBeforeRequest\` listener \*\*never cancels a request\*\*; it only records attribution, so
> plugin network reach is exactly what it was before.
>
> \## Why path containment is part of this PR
>
> The \`/external/\/\` route is new here, and it takes the directory to serve from
> \*\*out of the URL\*\*. \`resolveWithin\` verifies that the file stays inside the root it was given —
> but the URL chose that root, so a request naming \`~/.ssh\` and the file \`id\_ed25519\` passes
> containment cleanly. Containment answers "is the file inside the directory?", never "may you read
> that directory at all?".
>
> So a URL may only name a root the app already knows about: \`preferences.json\`'s \`externals\` — the
> SDK's own record of installed external plugins — plus \`\/tmp\`, where the SDK generates
> the entry document for a plugin whose package \`main\` is a \`.js\` file. That second one is not
> optional: such a plugin addresses its generated entry with \*its own\* directory as the root, which
> is never an "external", so without it the entry is refused and the plugin does not load. The tmp
> dir is app-controlled rather than named by the URL, so trusting it adds no reach.
>
> The list is seeded at startup and re-read when the handler meets a root it does not recognise
> (throttled to once a second, so a stream of bogus roots cannot hammer the disk). A root still
> unknown after that re-read is refused.
>
> Re-reading is not enough for a \*\*first\*\* install, and load order is why: \`PluginLocal#load()\`
> mounts the plugin's frame — which fetches its entry document and then the plugin's own scripts
> over \`lsp://\` — \*before\* \`LSPluginCore\` registers it and writes \`preferences.json\`. At that
> moment the file is not yet a record of anything, so nothing on disk can authorise the plugin
> being installed. The authority there is the directory the user picked, so the
> load-unpacked-plugin flow gets its own IPC (\`:openPluginDirDialog\`) that opens the same dialog
> and allows the chosen directory for the rest of the session; from the next launch
> \`preferences.json\` covers it. It is deliberately not a renderer-callable "trust this path" API —
> the only path it ever accepts is one the main process watched the user choose in a file dialog.
>
> Without any of this the PR would introduce a wider traversal than the one that exists today; the
> pre-existing traversal in the plugin branch is closed by the same \`resolveWithin\` call.
>
> \## Why \`assets://\` containment is part of this PR
>
> Turning on \`corsEnabled\` is what makes the scheme \*readable\* by \`fetch\`/XHR, and the handler
> serves a path named in the URL with no containment at all before this. The boundary that matters
> is \*\*plugin frames\*\*: a plugin frame receives no preload bridge, so it cannot reach the app's IPC,
> which makes \`assets://\` its only route to a local file. Measured in the suite — a plugin frame
> could read an arbitrary file outside the graph and see the bytes.
>
> So requests are refused unless the path lands inside a registered root: the graph directories,
> which the main process learns first-hand in \`set-current-graph!\`, plus the asset alias
> directories the user picked in Settings. The alias list lives in renderer storage, so it arrives
> over \`:setAssetsAliasDirs\` and is mirrored into main's \`configs.edn\` — that mirror is what makes
> the roots known at startup, before the renderer gets a chance to push them. A refusal returns
> \`ERR\_FILE\_NOT\_FOUND\`, exactly as the \`lsp://\` handler does, so it is not a probe oracle.
>
> Net effect is \*\*stricter\*\* than before this PR: the scheme previously served any absolute path on
> disk to any frame as a subresource.
>
> \## Release-build trap worth knowing
>
> \`src/electron/electron/utils.js\` is Closure-compiled under \`:advanced\` in a \*\*release\*\* build,
> which renames any \`path.\*\` \*\*property\*\* it has no extern for. \`path.sep\` and \`path.relative\` both
> compile to mangled keys that are \`undefined\` on Node's real \`path\` object, so a containment check
> written with \`path.sep\` silently returns null for \*everything\* — including the app's own
> \`electron.html\`, giving a blank window. Containment is therefore done with plain string ops. A dev
> \`cljs compile\` does \*\*not\*\* rename properties and cannot catch this; only a \`release\` build will.
>
> The same renaming bites a property read on \*\*parsed data\*\*, where there is nothing to write an
> extern against: \`preferences.json\`'s \`externals\`, read as \`prefs.externals\`, compiled to a mangled
> key that is \`undefined\` on the real object — so only the tmp root was seeded and every plugin
> installed outside the dot-root was refused. It is read as \`prefs\['externals'\]\`; a string literal
> cannot be renamed. This one was caught by running the packaged app, not by the suite, so there is
> a guard over the compiled output for it too. Note the trap inside the trap: a pseudo-named build
> spells the \*broken\* form \`.$externals$\`, which still contains the word, so grepping the bundle for
> \`externals\` proves nothing — the guard asserts the absence of the mangled form.
>
> The scheme \*\*privilege tables\*\* are the same trap once more, in a third shape. They are plain JS
> object literals in \`utils.js\` handed straight to \`registerSchemesAsPrivileged\`, and Electron reads
> those keys by their real names — so a renamed key does not error, it registers the scheme with
> \*\*default\*\* privileges. \`assets://\` would quietly lose \`supportFetchAPI\` + \`corsEnabled\` and every
> asset read would start failing again, in release builds only. The keys are quoted, and a guard
> over the compiled output asserts they survive.
>
> \`externs.js\` gains \`onBeforeRequest\` / \`resourceType\` / \`frame\` for the same reason — without them
> the call fails at runtime with \`$onBeforeRequest$ is not a function\`, which aborts app setup
> \*before\* the \`main\` IPC channel registers, leaving the renderer dead on arrival. Registration is
> additionally wrapped so a failure degrades to "no attribution" rather than taking the app down.
>
> \## Testing instructions
>
> \`\`\`bash
> yarn install
> yarn test:electron-js # new; also chained into \`yarn test\`
> \`\`\`
>
> 76 cases, of which 68 run under bare \`node --test\` — no Electron, no browser, no build step.
>
> The plugin half (46 cases) covers \`resolveWithin\` containment (traversal, absolute-looking paths,
> the sibling-directory \`startsWith\` trap), the external-root allowlist and both the re-seed and
> user-chosen-root paths into it, which requests get relaxed (all three plugin frame forms; the app
> frame explicitly not), and the CORS header rewrite itself. Verified green on Node 22 and 24.
>
> The asset half (30 cases, Node 24) covers the \`assets://\` resolver — traversal, encoded
> traversal, sibling-prefix roots, malformed escapes, the \`/C:/…\` Windows form — and the scheme
> privileges, including that \`standard\` is false and the keys survive \`:advanced\`.
>
> \*\*8 of those cases boot a real Electron\*\* (\`asset-protocol.test.mjs\`), because the bug they guard
> is not a wrong value a pure function could catch: the builder was \*correct\* and stayed
> correct-looking after the origin moved underneath it. Only a real renderer at a real origin can
> assert "this asset is actually fetchable". They assert both halves of the contract — an in-root
> asset \*\*is\*\* fetchable from the app's own origin, and a file outside every root is \*\*not\*\*,
> including from a plugin frame. The out-of-root file is created on disk on purpose, so a refusal
> proves \*containment\* rather than \*absence\* — the exact confusion the original bug turned on.
> There is also a canary asserting the renderer origin really is \`lsp://logseq.com\`, since the
> \`file://\` assertion means nothing otherwise.
>
> Those 8 need the Electron binary. With none present they \*\*skip\*\* rather than fail, and never
> trigger a download from inside a test (\`require('electron')\` would download, which a test must
> not do). Point them at an unpacked dist with \`ELECTRON\_OVERRIDE\_DIST\_PATH\`.
>
> \*\*Be aware they therefore SKIP in CI today, and I have not claimed otherwise.\*\* From Electron 42
> the npm package downloads the binary on first use rather than in a postinstall script, so
> \`yarn install\` does not prime it, and the \`Run Electron main-process tests\` step has no display
> either. The skip is visible in the log —
> \`﹣ assets:// scheme contract # no Electron binary available\` — rather than silent, and the 68
> pure cases do run. Making the other 8 run in CI needs the binary primed plus \`xvfb-run\`; I have
> left that out rather than push an unverified workflow change, since I have no way to test a CI
> runner from here. Happy to add it if a maintainer wants it, or to take a pointer on how this repo
> prefers to handle GUI-dependent tests.
>
> The suite was mutation-checked: replacing the containment check with a naive \`startsWith\`, and
> widening frame matching to the whole \`lsp://\` scheme, each turn it red.
>
> Four of the cases are guards over the \*\*compiled\*\* output, since none of the release-build traps
> above is observable any other way. They read \`static/electron.js\` when it exists and was built
> with pseudo-names (\`clojure -M:cljs release electron --debug\`); with no such build present there
> is nothing to inspect and they no-op, so they protect a developer who has just run a debug release
> build and nobody else. When the build \*is\* observable, a missing marker \*\*fails\*\* rather than
> skipping — an earlier version of this guard used a marker that matched no build at all and so
> passed unconditionally.
>
> The suite is wired into \`.github/workflows/build.yml\` as its own step, since that job runs
> \`yarn cljs:test\` directly rather than \`yarn test\`.
>
> Also run: \`clojure -M:clj-kondo --lint src/electron\` — 0 errors (one pre-existing unused-referral
> warning in \`utils.cljs\`, unchanged by this PR).
>
> \*\*A release build has been run and verified\*\*: \`resolveWithin\` compiles to plain string
> comparisons with \`path.resolve\`/\`path.join\` intact and no \`path.sep\`, the \`externals\` read
> survives unmangled, \`onBeforeRequest\` / \`onHeadersReceived\` / \`responseHeaders\` / \`resourceType\`
> all survive unrenamed, and the scheme privilege tables compile to
> \`{standard:!1, secure:!1, bypassCSP:!1, supportFetchAPI:!0, corsEnabled:!0}\` with the key names
> intact.
>
> Exercised manually on a packaged Linux/aarch64 build: 15 dot-root plugins across both the
> \`logseq.com/plugins/\` and \`logseq.io/plugins/\` routes; themes rendering correctly (checked
> against 0.10.15 with an A/B of computed styles over CDP); Readwise sync, i.e. plugin HTTP, working
> again; both external plugins loading over the \`/external/\` route — one with an HTML entry and one
> with a \`.js\` entry, freshly installed through \*Load unpacked plugin\* and again after a restart, so
> both the dialog and the \`preferences.json\` paths into the root list are covered; and a
> FTS5/trigger/\`MATCH\` smoke test of \`better-sqlite3\` 13 under Electron 43.
>
> For the asset fix specifically, a packaged Linux/aarch64 build was installed and used: a PDF asset
> in a journal page, which reproduced \`Missing PDF\` beforehand, now opens. The alias-image and
> plugin-theme faces were verified in the Electron harness rather than by hand — I have no
> alias-directory or \`assets://\`-theme plugin set up to click through.
> \*\*macOS and Windows packaging are untested\*\* — I don't have the hardware.
>
> \## Upgrade note for release notes
>
> The renderer origin moves from \`file://\` to \`lsp://logseq.com\`, and \`localStorage\` is keyed by
> origin, so UI preferences silently reset to defaults on first launch after upgrading. The visible
> one is \`radix-color\` returning to \`logseq\`, which activates the built-in Solarized background and
> overrides theme plugins; sidebar widths reset the same way. Nothing is lost — the graph and
> \`~/.logseq\*\` are untouched — but it looks alarming without a note.
>
> \## Known limitations
>
> \- A bridged response is rebuilt rather than streamed: the body is buffered and base64
> round-tripped, and \`redirected\`/\`type\` are not reconstructed (\`status\`, \`statusText\`, headers
> and \`url\` are). Requests the bridge declines — \`credentials: 'include'\`, non-string bodies —
> take the native path and are therefore subject to CORS as any web page would be.
> \- A server that does not answer \`OPTIONS\` still fails preflight for a non-simple XHR. Bridged
> \`fetch\` is unaffected, so this is confined to plugins issuing XHR directly.
> \- \`assets://\` containment is path resolution, not \`realpath\`, so a symlink \*inside\* a registered
> root that points outside it is followed. Shared with \`resolveWithin\`, and not a new exposure:
> anything under a graph root is already readable through the app's own file IPC. Tightening it
> needs an async \`realpath\` per request and would still race the filesystem.
> \- An asset link a user authored as an explicit \`file:///…\` URL in their markdown still passes
> through untouched and still will not load. Rewriting those would route arbitrary user-named
> paths through the asset scheme, which is a separate decision from fixing URL \*construction\*.
>
> \## Scope
>
> Deliberately excluded: the per-plugin network permission model this work was originally built
> alongside. It restricts plugins \*\*more\*\* than today's behaviour and is not required by the
> upgrade — it belongs in its own PR with its own discussion. This PR restores parity and nothing
> else.
>
>
> This is the new db based Logseq! I'm not sure how much issue it causes if you tr…y this out but go back to using the old version.
>
> Things have changed in the packaging since the last release.
>
> First, we're using pnpm now, so the tooling had to be switched up. Using pnpm is a bit cleaner than yarn, but both have their pros and cons.
>
> Second, the number of git repo based clojure dependencies have increased significantly, so instead of manually patching in each git repo source, I opted to dive into the source code of the clojure CLI to figure out how to trick it into using prefetched git dependencies.
> The main trick was just letting it first clone everything into it's normal location and then strip down the bare repos into the smallest form that the CLI still thinks is valid.
>
> Third, there is a new cli tool, which would be installed to the PATH upon running the desktop app, but I patched it out and added it into $out/bin. Though, this means that I had to rename the desktop app's executable name to something else.
>
> This CLI app is generated from OCaml, so I had to add some unpackaged OCaml packages to passthru.
>
> Electron 40+ support was fixed in https://github.com/logseq/logseq/pull/12741
>
> TODO: figure out how to circumvent the \`venv\` logic inside the package.
>
>
>
>
>
> \## Things done
>
>
>
> \- Built on platform:
> - \[\] x86\_64-linux
> - \[\] aarch64-linux
> - \[\] x86\_64-darwin
> - \[\] aarch64-darwin
> \- Tested, as applicable:
> - \[\] \[NixOS tests\] in \[nixos/tests\].
> - \[\] \[Package tests\] at \`passthru.tests\`.
> - \[\] Tests in \[lib/tests\] or \[pkgs/test\] for functions and "core" functionality.
> \- \[\] Ran \`nixpkgs-review\` on this PR. See \[nixpkgs-review usage\].
> \- \[\] Tested basic functionality of all binary files, usually in \`./result/bin/\`.
> \- Nixpkgs Release Notes
> - \[\] Package update: when the change is major or breaking.
> \- NixOS Release Notes
> - \[\] Module addition: when adding a new NixOS module.
> - \[\] Module update: when the change is significant.
> \- \[\] Fits \[CONTRIBUTING.md\], \[pkgs/README.md\], \[maintainers/README.md\] and other READMEs.
>
> \[NixOS tests\]: https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests
> \[Package tests\]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests
> \[nixpkgs-review usage\]: https://github.com/Mic92/nixpkgs-review#usage
>
> \[CONTRIBUTING.md\]: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md
> \[lib/tests\]: https://github.com/NixOS/nixpkgs/blob/master/lib/tests
> \[maintainers/README.md\]: https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md
> \[nixos/tests\]: https://github.com/NixOS/nixpkgs/blob/master/nixos/tests
> \[pkgs/README.md\]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md
> \[pkgs/test\]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/test
---
After adding that and removing another problematic package, it has rebuild and updated successfully (even tho it showed some errors).
Thank you all for all of your help!