text:
waveterm: init v0.7.6

Description of changes
This commit adds a new package: Waveterm with version 0.7.6. This also addresses the issue (package request) #280566
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[x] sandbox = relaxed
[x] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Where's the commit initing you as maintainer?

@JohnRTitor It's the very first one

You need to actually modify https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix
See https://github.com/NixOS/nixpkgs/commit/76a55aafc1bf1b1cce70749a99ac173ae745ffd4 as an example commit

Thank you @Marin-Kitagawa ! You beat me to it 🥇 .
I tried cloning your repo and testing the package on my Mac with:
nix-build -A waveterm

But it couldn't found waveterm... How would I go about testing if this derivation works?

From within the repo
cd ./pkgs/applications/terminal-emulators/waveterm
nix-build default.nix

or
cd ./pkgs/applications/terminal-emulators/waveterm
nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'

Tried on my M1 Mac and it fails... Here's the complete log:
this derivation will be built:
  /nix/store/8hbgzijgag9yws96hign55h59qgynl6l-waveterm-0.7.6.drv
building '/nix/store/8hbgzijgag9yws96hign55h59qgynl6l-waveterm-0.7.6.drv'...
Running phase: unpackPhase

7-Zip (z) 23.01 (arm64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
 64-bit arm_v:8 locale=en_US.UTF-8 Threads:8 OPEN_MAX:1048576, ASM

Scanning the drive for archives:
1 file, 235140532 bytes (225 MiB)

Extracting archive: /nix/store/kvsb4dri9x3b8vrmrkd680nzgbm0ma8i-Wave-darwin-universal-0.7.6.dmg

4.apfs
WARNINGS:
There are data after the end of archive

--
Path = /nix/store/kvsb4dri9x3b8vrmrkd680nzgbm0ma8i-Wave-darwin-universal-0.7.6.dmg
Type = Dmg
Physical Size = 235140532
Method = Copy Zero2 ZLIB CRC
Blocks = 649
----
Path = 4.apfs
Size = 815717376
Packed Size = 235093621
Comment = disk image (Apple_APFS : 4)
Method = Copy Zero2 ZLIB CRC
--
Path = 4.apfs
Type = APFS
WARNINGS:
There are data after the end of archive
Physical Size = 815714304
Tail Size = 3072
Name = Wave 0.7.6-universal.apfs
ID = 9755c9ad66a643fba6ac7e965d8ac7b5
Cluster Size = 4096
Created = 2024-06-15 00:31:58.750708096
Modified = 2024-06-15 00:32:05.018548805
Comment =
{
block_size: 4096
fs_index: 0
volume_name: Wave 0.7.6-universal
vol_uuid: 7df71ec31cc34922b74b896cd720229e
incompatible_features: CASE_INSENSITIVE
fs_alloc_count: 159677
num_files: 117
num_directories: 159
num_symlinks: 15
num_other_fsobjects: 0
Num_Attr_Streams: 331
num_snapshots: 0
total_blocks_alloced: 162313
total_blocks_freed: 2688
unmounted: 2024-06-15 00:32:05.018549680
last_modified: 2024-06-15 00:32:05.016064388
formatted_by: newfs_apfs (2236.120.10.0.1)
  timestamp: 2024-06-15 00:31:58.750708096
  last_xid: 2
modified_by[0]: apfs_kext (2236.120.10.0.1)
  timestamp: 2024-06-15 00:32:05.018548805
  last_xid: 9

}

Everything is Ok

Archives with Warnings: 1

Warnings: 1
Folders: 159
Files: 117
Alternate Streams: 331
Alternate Streams Size: 676552
Size:       652740992
Compressed: 235140532
chmod: cannot access 'Waveterm.app': No such file or directory
error: builder for '/nix/store/8hbgzijgag9yws96hign55h59qgynl6l-waveterm-0.7.6.drv' failed with exit code 1;
       last 10 log lines:
       > Archives with Warnings: 1
       >
       > Warnings: 1
       > Folders: 159
       > Files: 117
       > Alternate Streams: 331
       > Alternate Streams Size: 676552
       > Size:       652740992
       > Compressed: 235140532
       > chmod: cannot access 'Waveterm.app': No such file or directory
       For full logs, run 'nix log /nix/store/8hbgzijgag9yws96hign55h59qgynl6l-waveterm-0.7.6.drv'.

I found the problem! Turns out you need to change the sourceRoot attribute to Wave.app. Now it unpacks and installs correctly. The only problem I have now is that when I try to run the program from result/Applications it says it's corrupted...

This happened to me before when I tried packaging Wave. I couldn't find other way that worked excepto for making the derivation impure and unpacking it like this:
unpackPhase = ''
          runHook preUnpack

          # Since the .dmg is using APFS we can't use undmg.
          # I also tried to use _7zz but it corrupts the .app.
          /usr/bin/hdiutil attach $src
          cp -r "/Volumes/Wave ${version}-universal/Wave.app" .
          /usr/bin/hdiutil detach "/Volumes/Wave ${version}-universal"

          runHook postUnpack
        '';

After this changes I can successfully run the app from finder in the result/Applications folder after building the derivation.

Is hdiutil available on nixpkgs? CC @DontEatOreo if there are any other solution

Is hdiutil available on nixpkgs?

Sadly no...
I'm not sure how this should be fixed. A workaround is to right-click and click open; then you will be allowed to actually open the program

(macOS moment...)

I saw the project is open source and it's written in Go, shouldn't we at least try to build it from source for Linux?

I saw the project is open source and it's written in Go, shouldn't we at least try to build it from source for Linux?

I was doing just that but Marin beat me to the PR! My current progress is this, the linux config is obtained from this thread I just merged it with the MacOS that worked for me.
(package.nix)
{
  lib,
  fetchurl,
  stdenvNoCC,
  fetchYarnDeps,
  mkYarnPackage,
  makeWrapper,
  copyDesktopItems,
  fetchFromGitHub,
  buildGoModule,
  breakpointHook,
  electron-bin,
  makeDesktopItem,
}: let
  pname = "waveterm";
  info = lib.importJSON ./info.json;
  genMeta = tag-version: {
    changelog = "https://github.com/wavetermdev/waveterm/releases/tag/v${tag-version}";
    description = "An Open-Source, AI-Native, Terminal Built for Seamless Workflows";
    homepage = "https://github.com/wavetermdev/wavetermn";
    license = lib.licenses.asl20;
    mainProgram = pname;
    platforms = lib.platforms.unix;
  };

  darwin = let
    version = info.darwin.version;
  in
    stdenvNoCC.mkDerivation (
      finalAttrs: {
        inherit pname version;
        meta = genMeta version;

        src = fetchurl {
          inherit (info.darwin) hash;
          url = "https://dl.waveterm.dev/releases/Wave-darwin-universal-${version}.dmg";
        };

        sourceRoot = ".";

        unpackPhase = ''
          runHook preUnpack

          # Since the .dmg is using APFS we can't use undmg.
          # I also tried to use _7zz but it corrupts the .app.
          /usr/bin/hdiutil attach $src
          cp -r "/Volumes/Wave ${version}-universal/Wave.app" .
          /usr/bin/hdiutil detach "/Volumes/Wave ${version}-universal"

          runHook postUnpack
        '';

        installPhase = ''
          runHook preInstall

          mkdir -p $out/Applications
          cp -r *.app $out/Applications
          chmod +x $out/Applications/*.app

          runHook postInstall
        '';
      }
    );

  linux = let
    version = info.linux.version;
    src = fetchFromGitHub {
      owner = "wavetermdev";
      repo = pname;
      rev = "v${version}";
      sha256 = info.linux.hash;
    };
    wavesrv = buildGoModule {
      inherit version src;
      preBuild = ''
        # go: 'go mod vendor' cannot be run in workspace mode. Run 'go work vendor' to vendor the workspace or set 'GOWORK=off' to exit workspace mode.
        # https://github.com/NixOS/nixpkgs/issues/203039
        export GOWORK="off";
      '';
      pname = "${pname}-wavesrv";
      modRoot = "./wavesrv";
      vendorHash = "";
      doCheck = false; # Currently fails at comp_test.go:91: comp-fail: ls f[*] + [foo bar] => [ls foo\ bar [*]] expected[ls 'foo bar' [*]]
    };
    waveshell = buildGoModule {
      inherit version src;
      preBuild = ''
        # go: 'go mod vendor' cannot be run in workspace mode. Run 'go work vendor' to vendor the workspace or set 'GOWORK=off' to exit workspace mode.
        # https://github.com/NixOS/nixpkgs/issues/203039
        export GOWORK="off";
      '';
      pname = "${pname}-waveshell";
      modRoot = "./waveshell";
      vendorHash = "";
    };
    electron = electron-bin;
  in
    mkYarnPackage rec {
      inherit pname src version;
      meta = genMeta version;

      packageJSON = "${src}/package.json";

      env.ELECTRON_SKIP_BINARY_DOWNLOAD = "1";

      offlineCache = fetchYarnDeps {
        yarnLock = "${src}/yarn.lock";
        hash = "";
      };

      nativeBuildInputs = [
        makeWrapper
        copyDesktopItems
        breakpointHook
      ];

      buildPhase = ''
        runHook preBuild

        pushd deps/${pname}
        node_modules/.bin/webpack --env prod
        popd

        runHook postBuild
      '';

      postBuild = ''
        pushd deps/${pname}

        mkdir ./bin
        cp ${wavesrv}/bin/cmd ./bin/wavesrv.amd64
        mkdir ./bin/mshell
        cp ${waveshell}/bin/waveshell ./bin/mshell/mshell-v0.6-linux.amd64

        yarn --offline run electron-builder \
          --dir \
          -l \
          -p never \
          -c electron-builder.config.js \
          -c.electronDist=${electron}/libexec/electron \
          -c.electronVersion=${electron.version}

        popd
      '';

      installPhase = ''
        runHook preInstall

        # resources
        mkdir -p "$out/share/lib/${pname}"
        cp -r ./deps/${pname}/make/*-unpacked/{locales,resources{,.pak}} "$out/share/lib/${pname}"

        # icons
        #install -Dm644 ./deps/${pname}/static/Icon.png $out/share/icons/hicolor/1024x1024/apps/${pname}.png

        # executable wrapper
        makeWrapper '${electron}/bin/electron' "$out/bin/${pname}" \
          --add-flags "$out/share/lib/${pname}/resources/app.asar" \
          --add-flags "\''${NIXOS_OZONE_WL:+\''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}" \
          --inherit-argv0

        runHook postInstall
      '';
      # Do not attempt generating a tarball for contents again.
      # note: `doDist = false;` does not work.
      distPhase = "true";

      desktopItems = [
        (makeDesktopItem {
          name = pname;
          exec = pname;
          icon = pname;
          desktopName = "Wave Terminal";
          genericName = "waveterm";
          comment = meta.description;
          categories = ["System"];
          startupWMClass = pname;
        })
      ];
    };
in
  if stdenvNoCC.isDarwin
  then darwin
  else linux

(info.json)
{
  "linux": {
    "hash": "sha256-cHjBH6oijoAhdk2Ty1sl2GFXUUhfoToTuDUl5VuwKWU=",
    "version": "0.7.6"
  },
  "darwin": {
    "hash": "sha256-b75eQnUteQ767+crVe+gWfBf7PrrEjoNFVTx8s/jTXM=",
    "version": "0.7.6"
  }
}

I don't have a linux! So I can't really test it out, but accroding to the original author it works, just needs to setup the hashes!

That's, if you can conquer scripthaus

I'm not sure how this should be fixed. A workaround is to right-click and click open; then you will be allowed to actually open the program

Can confirm, this opens the application successfully!

That's, if you can conquer scripthaus

hahahaha I tried, but in the end followed the same route ErngWong took, translating the commands in scripthaus to  the native nix building blocks .

Can't we just do if stdenvNoCC.isDarwin then info.darwin.version else info.linux.version for meta? So it becomes
meta = {
  changelog = "https://github.com/wavetermdev/waveterm/releases/tag/v${
    if stdenvNoCC.isDarwin then info.darwin.version else info.linux.version
  }";
  description = "An Open-Source, AI-Native, Terminal Built for Seamless Workflows";
  homepage = "https://github.com/wavetermdev/wavetermn";
  license = lib.licenses.asl20;
  mainProgram = pname;
  platforms = lib.platforms.unix;
};

Can't we just do if stdenvNoCC.isDarwin then info.darwin.version else info.linux.version for meta? So it becomes

I'm on board with this change, don't really have any complaints about it.

Seems like the failing check is because

Look like v0.8 just got released https://waveterm.hashnode.dev/introducing-the-new-wave-terminal-v08

authors: DontEatOreo ElrohirGT JohnRTitor Marin-Kitagawa S1M1S Th1nkK1D


text:
python312Packages.langfuse: 2.36.2 -> 2.43.3

Diff: https://github.com/langfuse/langfuse-python/compare/refs/tags/v2.36.2...v2.43.3
Changelog: https://github.com/langfuse/langfuse-python/releases/tag/refs/tags/v2.43.3
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[x] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 335389 at cae447e0 run on x86_64-linux 1

3 packages built successfully:

open-webui
python311Packages.langfuse
python312Packages.langfuse

Result of nixpkgs-review pr 335389 at cae447e0 run on aarch64-darwin 1

3 packages failed to build:

open-webui
python311Packages.langfuse
python312Packages.langfuse

source: gharchive/pull-request

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
grizzly: 0.4.3 -> 0.4.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/grafana/grizzly/releases.
meta.description for grizzly is: Utility for managing Jsonnet dashboards against the Grafana API
meta.homepage for grizzly is: https://grafana.github.io/grizzly/
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.4.5 in filename of file in /nix/store/jkcdbxppg4mxgfg8mwhb5w9qlh2z8mr7-grizzly-0.4.5

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

grizzly

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/jkcdbxppg4mxgfg8mwhb5w9qlh2z8mr7-grizzly-0.4.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A grizzly https://github.com/r-ryantm/nixpkgs/archive/1ea135a1175a24bd44e65a3f333cc5e253087235.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1ea135a1175a24bd44e65a3f333cc5e253087235#grizzly

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/jkcdbxppg4mxgfg8mwhb5w9qlh2z8mr7-grizzly-0.4.5
ls -la /nix/store/jkcdbxppg4mxgfg8mwhb5w9qlh2z8mr7-grizzly-0.4.5/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

grizzly

Maintainer pings
cc @nrhtr for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 336774 run on aarch64-darwin 1

1 package built:

grizzly

authors: r-ryantm wegank


text:
python312Packages.azure-mgmt-privatedns: 1.1.0 -> 1.2.0

Changelog: https://github.com/Azure/azure-sdk-for-python/blob/azure-mgmt-privatedns_1.2.0/sdk/network/azure-mgmt-privatedns/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 344045 run on x86_64-linux 1

6 packages built:

azure-cli
azure-cli.dist
python311Packages.azure-mgmt-privatedns
python311Packages.azure-mgmt-privatedns.dist
python312Packages.azure-mgmt-privatedns
python312Packages.azure-mgmt-privatedns.dist


text:
python312Packages.mypy-boto3-*: updates

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 350443

x86_64-linux

:fast_forward: 4 packages marked as broken and skipped:

python311Packages.dependency-injector
python311Packages.dependency-injector.dist
python312Packages.dependency-injector
python312Packages.dependency-injector.dist

:x: 2 packages failed to build:

aws-sam-cli
aws-sam-cli.dist

:white_check_mark: 40 packages built:

python311Packages.mypy-boto3-application-insights
python311Packages.mypy-boto3-application-insights.dist
python311Packages.mypy-boto3-athena
python311Packages.mypy-boto3-athena.dist
python311Packages.mypy-boto3-autoscaling
python311Packages.mypy-boto3-autoscaling.dist
python311Packages.mypy-boto3-dms
python311Packages.mypy-boto3-dms.dist
python311Packages.mypy-boto3-ec2
python311Packages.mypy-boto3-ec2.dist
python311Packages.mypy-boto3-eks
python311Packages.mypy-boto3-eks.dist
python311Packages.mypy-boto3-fms
python311Packages.mypy-boto3-fms.dist
python311Packages.mypy-boto3-payment-cryptography-data
python311Packages.mypy-boto3-payment-cryptography-data.dist
python311Packages.mypy-boto3-s3
python311Packages.mypy-boto3-s3.dist
python311Packages.mypy-boto3-wafv2
python311Packages.mypy-boto3-wafv2.dist
python312Packages.mypy-boto3-application-insights
python312Packages.mypy-boto3-application-insights.dist
python312Packages.mypy-boto3-athena
python312Packages.mypy-boto3-athena.dist
python312Packages.mypy-boto3-autoscaling
python312Packages.mypy-boto3-autoscaling.dist
python312Packages.mypy-boto3-dms
python312Packages.mypy-boto3-dms.dist
python312Packages.mypy-boto3-ec2
python312Packages.mypy-boto3-ec2.dist
python312Packages.mypy-boto3-eks
python312Packages.mypy-boto3-eks.dist
python312Packages.mypy-boto3-fms
python312Packages.mypy-boto3-fms.dist
python312Packages.mypy-boto3-payment-cryptography-data
python312Packages.mypy-boto3-payment-cryptography-data.dist
python312Packages.mypy-boto3-s3
python312Packages.mypy-boto3-s3.dist
python312Packages.mypy-boto3-wafv2
python312Packages.mypy-boto3-wafv2.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 350443

x86_64-linux

:fast_forward: 4 packages marked as broken and skipped:

python311Packages.dependency-injector
python311Packages.dependency-injector.dist
python312Packages.dependency-injector
python312Packages.dependency-injector.dist

:white_check_mark: 42 packages built:

aws-sam-cli
aws-sam-cli.dist
python311Packages.mypy-boto3-application-insights
python311Packages.mypy-boto3-application-insights.dist
python311Packages.mypy-boto3-athena
python311Packages.mypy-boto3-athena.dist
python311Packages.mypy-boto3-autoscaling
python311Packages.mypy-boto3-autoscaling.dist
python311Packages.mypy-boto3-dms
python311Packages.mypy-boto3-dms.dist
python311Packages.mypy-boto3-ec2
python311Packages.mypy-boto3-ec2.dist
python311Packages.mypy-boto3-eks
python311Packages.mypy-boto3-eks.dist
python311Packages.mypy-boto3-fms
python311Packages.mypy-boto3-fms.dist
python311Packages.mypy-boto3-payment-cryptography-data
python311Packages.mypy-boto3-payment-cryptography-data.dist
python311Packages.mypy-boto3-s3
python311Packages.mypy-boto3-s3.dist
python311Packages.mypy-boto3-wafv2
python311Packages.mypy-boto3-wafv2.dist
python312Packages.mypy-boto3-application-insights
python312Packages.mypy-boto3-application-insights.dist
python312Packages.mypy-boto3-athena
python312Packages.mypy-boto3-athena.dist
python312Packages.mypy-boto3-autoscaling
python312Packages.mypy-boto3-autoscaling.dist
python312Packages.mypy-boto3-dms
python312Packages.mypy-boto3-dms.dist
python312Packages.mypy-boto3-ec2
python312Packages.mypy-boto3-ec2.dist
python312Packages.mypy-boto3-eks
python312Packages.mypy-boto3-eks.dist
python312Packages.mypy-boto3-fms
python312Packages.mypy-boto3-fms.dist
python312Packages.mypy-boto3-payment-cryptography-data
python312Packages.mypy-boto3-payment-cryptography-data.dist
python312Packages.mypy-boto3-s3
python312Packages.mypy-boto3-s3.dist
python312Packages.mypy-boto3-wafv2
python312Packages.mypy-boto3-wafv2.dist


text:
qtscrcpy: switch to ffmpeg_6

Per the request of https://github.com/NixOS/nixpkgs/pull/340257#issuecomment-2484225666. Tested and seems nothing broken.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thanks. I take it FFmpeg 7 fails? Do you have the error message?

No but the higher the upgrade, the more breaking changes there should be.

We are trying to move away from these old FFmpeg versions entirely. Arch, for instance, ships FFmpeg 4 for compatibility with a few (mostly binary) packages, and FFmpeg 7, but no FFmpeg 6. Old versions should only be pinned where there is a compatibility issue and it is not possible to get a patch from upstream or another distro; please see the advice in pkgs/development/libraries/ffmpeg/default.nix. If it builds with just unversioned ffmpeg, that’s what it should use.
See also the prior work:

https://github.com/NixOS/nixpkgs/pull/326618
https://github.com/NixOS/nixpkgs/pull/336401

This builds:
diff --git a/pkgs/by-name/qt/qtscrcpy/package.nix b/pkgs/by-name/qt/qtscrcpy/package.nix
index 88f13a04d0..88b6f36132 100644
--- a/pkgs/by-name/qt/qtscrcpy/package.nix
+++ b/pkgs/by-name/qt/qtscrcpy/package.nix
@@ -7,7 +7,7 @@
   libsForQt5,
   scrcpy,
   android-tools,
-  ffmpeg_4,
+  ffmpeg,
   makeDesktopItem,
   copyDesktopItems,
 }:
@@ -49,6 +49,8 @@
     substituteInPlace QtScrcpy/sndcpy/sndcpy.sh \
       --replace-fail 'ADB=./adb' "ADB=${lib.getExe' android-tools "adb"}" \
       --replace-fail 'SNDCPY_APK=sndcpy.apk' "SNDCPY_APK=$out/share/qtscrcpy/sndcpy.apk"
+    substituteInPlace QtScrcpy/QtScrcpyCore/src/device/decoder/decoder.cpp \
+      --replace-fail 'avcodec_close(m_codecCtx);' ""
   '';

   nativeBuildInputs = [
@@ -61,7 +63,7 @@
   buildInputs =
     [
       scrcpy
-      ffmpeg_4
+      ffmpeg
     ]
     ++ (with libsForQt5; [
       qtbase

The deprecated avcodec_close is unnecessary given the immediately following avcodec_free_context call. Since we’re already patching this a bunch it seems fine to me and better than pinning FFmpeg 6. Of course an actual .patch file would be better but that’s probably true of some of the existing postPatch already.

authors: Aleksanaa emilazy


text:
slackdump: 2.6.0 -> 2.6.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/rusq/slackdump/releases.
meta.description for slackdump is: Tools for saving Slack's data without admin privileges
meta.homepage for slackdump is: https://github.com/rusq/slackdump
meta.changelog for slackdump is: https://github.com/rusq/slackdump/releases/tag/v2.6.1
Updates performed

Golang update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.6.1 in filename of file in /nix/store/qh5jdzsgsrjfs7h5kkaj6rijwcj3pakl-slackdump-2.6.1

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

slackdump

Instructions to test this update (click to expand)

Either download from the cache:
nix-store -r /nix/store/qh5jdzsgsrjfs7h5kkaj6rijwcj3pakl-slackdump-2.6.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A slackdump https://github.com/r-ryantm/nixpkgs/archive/e1d9c1c2fa68f61761b43ee509d1f424b6073d71.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e1d9c1c2fa68f61761b43ee509d1f424b6073d71#slackdump

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qh5jdzsgsrjfs7h5kkaj6rijwcj3pakl-slackdump-2.6.1
ls -la /nix/store/qh5jdzsgsrjfs7h5kkaj6rijwcj3pakl-slackdump-2.6.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

slackdump

Maintainer pings
cc @Bot-wxt1221 for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


text:
mixxx: 2.0.0 -> 2.1.3

Motivation for this change
Version bump. Switched to releases on GitHub.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build mixxx

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: mixxx
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: mixxx
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3
shrinking /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3/lib/mixxx/plugins/soundsource/libsoundsourcem4a.so
shrinking /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3/lib/mixxx/plugins/vamp/libmixxxminimal.so
shrinking /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3/bin/mixxx
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3/lib  /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3/bin
patching script interpreter paths in /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3
checking for references to /build in /nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3...
/nix/store/6yyy2my5r0alrbn2lyzqvb421xasgvdq-mixxx-2.1.3

Success on aarch64-linux (full log)
Attempted: mixxx
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3
shrinking /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3/lib/mixxx/plugins/vamp/libmixxxminimal.so
shrinking /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3/lib/mixxx/plugins/soundsource/libsoundsourcem4a.so
shrinking /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3/bin/mixxx
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3/lib  /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3/bin
patching script interpreter paths in /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3
checking for references to /build in /nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3...
/nix/store/whdji1vai4w5c8kzc9wvfbdca07y4ilp-mixxx-2.1.3

authors: GrahamcOfBorg Mic92 bfortz


text:
nixos/dhcpcd: Expose less information to servers

Motivation for this change
dhcpcd exposes a lot of information which is IMO not necessary and a possible security risk because of exposed version numbers.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

Sounds OK, superficially – I know almost nothing about dhcpcd or the protocol.

@vcunat To elaborate more: The data is sent during DHCPv6 solicitation (Wireshark Info: Solicit). The package looks like this (look at the last two):

It surely works here with my router, but I don't know if other routers could fail. I doubt it but you never be sure…

I don't think we should make this change because some routers may reject this vendorclassid, and the user cannot override it in extraConfig. As per dhcpcd.conf(5):

vendclass en data
Add the DHCPv6 Vendor Indetifying Vendor Class with the IANA assigned Enterprise Number en with the data.  This option can be set more than once to add more data, but the
behaviour, as per RFC(3925) is undefined if the Enterprise Number differs.

So I'm afraid it's up to the user to set this manually if they want to expose less information.

@xeji So do you think it would be okay if I do it as optionalString?

I could see this being an optional value but it being open to the user to customize. In a datacenter, pxebooting machines could declare some other options to the dhcp server for it to take some other action. But I agree with @xeji that the default shouldn't change.

@cransom That's not a new feature compared to the currently existing extraConfig functionality. I'll close this PR, users can add the appropriate line to their configuration if they wish.

Totally agree. We should rather keep the options clean

authors: cransom dasJ vcunat xeji


text:
clib: 1.8.0 -> 1.8.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/clib/versions.
meta.description for clib is: '"C micro-package manager"'.
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
/nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin/clib passed the binary check.
/nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin/clib-install passed the binary check.
/nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin/clib-search passed the binary check.
3 of 3 passed binary check by having a zero exit code.
3 of 3 passed binary check by having the new version present in output.
found 1.8.1 with grep in /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1
directory tree listing: https://gist.github.com/c8360779a0d874b4cc3500a302928c3c
du listing: https://gist.github.com/211765205f78d8e8889a1bf4c3e29f09

Instructions to test this update (click to expand)

One-time optional setup to skip building using Cachix:

Install cachix from https://cachix.org/
Use r-ryantm's cache:cachix use r-ryantm

Test this update by entering a nix shell, seeing what is inside the
result, and if applicable, running some binaries:
nix-shell --pure -I nixpkgs=https://github.com/r-ryantm/nixpkgs/archive/fa481b1e2b5e7802c748f6b3435524ae8b49deca.tar.gz -p clib
ls -la /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1

cc @jb55 for testing.

Success on x86_64-linux (full log)
Attempted: clib
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1
shrinking /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin/clib-install
shrinking /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin/clib
shrinking /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin/clib-search
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1/bin
patching script interpreter paths in /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1
checking for references to /build in /nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1...
/nix/store/h93dx5jp709sjhsj6wad53zcg4zsm7jm-clib-1.8.1

Success on aarch64-linux (full log)
Attempted: clib
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1
shrinking /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1/bin/clib-search
shrinking /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1/bin/clib-install
shrinking /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1/bin/clib
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1/bin
patching script interpreter paths in /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1
checking for references to /build in /nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1...
/nix/store/nidnn74i3wx25c95zzw14w333xjm0a9a-clib-1.8.1

This doesn't have any functional changes:
  * travis: add @clibbot token
  * Upload Windows binaries to tagged Github Releases (#147)
  * Pre-compiled Windows binaries for future Github releases (#143)

I don't think there's any point in updating it?

Success on x86_64-darwin (full log)
Attempted: clib
Partial log (click to expand)
clang -std=c99 -Ideps -Wall -Wno-unused-function -U__STRICT_ANSI__ -I/nix/store/15l4w4zb9bnhk83z428dh2mk5c11gqqz-curl-7.61.0-dev/include -o clib-search src/clib-search.c deps/occurrences/occurrences.o deps/console-colors/console-colors.o deps/strdup/strdup.o deps/str-ends-with/str-ends-with.o deps/clib-package/clib-package.o deps/substr/substr.o deps/str-starts-with/str-starts-with.o deps/commander/commander.o deps/str-replace/str-replace.o deps/parse-repo/parse-repo.o deps/str-concat/str-concat.o deps/str-flatten/str-flatten.o deps/tempdir/tempdir.o deps/parson/parson.o deps/trim/trim.o deps/asprintf/asprintf.o deps/http-get/http-get.o deps/gumbo-get-elements-by-tag-name/get-elements-by-tag-name.o deps/list/list_iterator.o deps/list/list_node.o deps/list/list.o deps/path-normalize/path-normalize.o deps/path-join/path-join.o deps/gumbo-parser/tokenizer.o deps/gumbo-parser/string_buffer.o deps/gumbo-parser/vector.o deps/gumbo-parser/char_ref.o deps/gumbo-parser/utf8.o deps/gumbo-parser/tag.o deps/gumbo-parser/util.o deps/gumbo-parser/string_piece.o deps/gumbo-parser/error.o deps/gumbo-parser/attribute.o deps/gumbo-parser/parser.o deps/case/case.o deps/gumbo-get-element-by-id/get-element-by-id.o deps/fs/fs.o deps/wildcardcmp/wildcardcmp.o deps/which/which.o deps/wiki-registry/wiki-registry.o deps/mkdirp/mkdirp.o deps/debug/debug.o deps/gumbo-text-content/gumbo-text-content.o -L/nix/store/ii27lrc3r7rz8f2wfxnn22rm2fqk6h9a-curl-7.61.0/lib -lcurl -lnghttp2 -lssh2 -lssh2 -lssl -lcrypto -lssl -lcrypto -lgssapi_krb5 -lresolv -lz
installing
install flags: SHELL=/nix/store/cblfnvb5rmhd2z231mqasn0brzh1hhv4-bash-4.4-p23/bin/bash PREFIX=\$\(out\) install
mkdir -p /nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1/bin
cp -f clib /nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1/bin/clib;  cp -f clib-install /nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1/bin/clib-install;  cp -f clib-search /nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1/bin/clib-search;
post-installation fixup
strip is /nix/store/df6k4mgdjxciy0f637lryp7c9ln7n1m3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1/bin
patching script interpreter paths in /nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1
/nix/store/9qikhlj7ssy13yrkzarp41zi8vj2nqvq-clib-1.8.1

I don't think there's any point in updating it?

I agree it's not necessary. But it shouldn't hurt either, and if we close this the bot will nag us with the same bump again on the next run :smile: . So @jb55 is it ok if we merge anyway?

sure!

authors: GrahamcOfBorg jb55 r-ryantm xeji


text:
nginx: add custom options

Motivation for this change
Add custom options:

logError - Allow to change the location of the default log. For example, redirect to syslog.
preStart - Allow running custom scripts. A way with "systemd.services.nginx.preStart" does not work well.

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

Updated PR, daemon mode not worked.

@GrahamcOfBorg test nginx

Success on aarch64-linux (full log)
Attempted: tests.nginx
Partial log (click to expand)
webserver: exit status 1
syncing
webserver: running command: sync
webserver: exit status 0
test script finished in 12.07s
cleaning up
killing webserver (pid 631)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/xqi22bvarzm6lrk115483nfhhhhhyi15-vm-test-run-nginx

Success on x86_64-linux (full log)
Attempted: tests.nginx
Partial log (click to expand)
webserver: exit status 1
syncing
webserver: running command: sync
webserver: exit status 0
test script finished in 145.51s
cleaning up
killing webserver (pid 600)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/nwqanl66s87fvl42h696r5ncwgglb58c-vm-test-run-nginx

Thanks!

authors: GrahamcOfBorg Izorkin Mic92


text:
tdrop: init at 2019-01-02

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@wedens Also change the version in your commit msg :smile:

Done 🙂

authors: wedens worldofpeace


text:
megahit: init at 1.1.3

This is widely used in bioinformatics for assembling genomes &
metagenomes
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)

Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)

[x] Tested execution of all binary files (usually in ./result/bin/)
Tested main programme, the rest are used internally

[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build megahit

Thanks for the feedback. Corrected & force-pushed the update.

authors: luispedro markuskowa


text:
lua*Packages TLS updates

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via all NixOS test(s) if existing and applicable for the change (look inside nixos/tests)  prosody.x86_64-linux
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] N/A Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after).  A couple kilobytes added.
[ ] N/A, I think. Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I tried generating these, but they wouldn't build, even if I overrode them to depend on openssl.  (I don't know what's wrong.)
So far I've done mainly basic testing around knot-resolver, but even https with TLS 1.3 seemed to work when I added the openssl-1.1 branch locally.

luasec seems to be on luarocks, wouldn't that makes sense to move it to the automated packages instead ?

luaossl too for what it's worth xD . If you are willing to go through the process and have any trouble/question let me know.

Feel free to try.

I tried generating these, but they wouldn't build, even if I overrode them to depend on openssl. (I don't know what's wrong.)

sorry completely missed this. Ok will try.

The generated expression didn't contain openssl reference (not surprising), so I added it to buildInputs via the usual overrides, but they still couldn't find headers from the package.  I was probably doing something wrong, anyway I chose a quicker solution for now.

if you feel confident enough to merge it, let's do it, I will investiage the issue later.
luarocks makes some assumptions on how paths are searched, so for instance if it finds X/include, it will look for the lib in X/lib and ignore Y/lib (or something along these lines IIRC) which is why sometimes it's necessary to specify manually the folders like
    extraConfig = ''
      variables = {
        LIBUUID_INCDIR="${pkgs.lib.getDev pkgs.libuuid}/include";
        LIBUUID_LIBDIR="${pkgs.lib.getLib pkgs.libuuid}/lib";
      }
    '';

upstream didn't seem too excited about "fixing" this. so maybe I could do it in our fork.

It would be best to support and prefer pkg-config to search for dependencies.

I can only agree https://github.com/luarocks/luarocks/issues/514

authors: teto vcunat


text:
yggdrasil: init at 0.3.5

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@gazally cool, do you want to rebase your service on this package or should we wait?
I'm also not sure what buildGoModule does in this context.

I will close this in favor of #63863


text:
networkmanager,modemmanager: fix service symlinks for systemd v243

Motivation for this change
Fixes problems such as:
systemd[1]: Failed to put bus name to hashmap: File exists
systemd[1]: dbus-org.freedesktop.nm-dispatcher.service: Two services allocated for the same bus name org.freedesktop.nm_dispatcher, refusing operation.
Problem is that systemd treats symlinks to files outside the service
path differently, causing our old workaround to look like two separate services.
These symlinks are intended to be a means for manually emulating
the behavior of the Alias= directive in these services.
Unfortunately even making these symlinks relative isn't enough,
since they don't make it to where it matters--
that only makes the links in /etc/static/systemd/system/*
relative, with systemd still being shown non-relative links
in /etc/systemd/system/*.
To fix this, drop all of this at the package level
and instead simply specify the aliases in the NixOS modules.
Also handle the same for modemmanager,
since the networkmanager NixOS module also handles that.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify potential reviewers
cc @worldofpeace

It's strange that we weren't doing this in the first place.
Would this be an issue for 19.09 @dtzWill?

FWIW, looks like the alias symlinks were added in https://github.com/NixOS/nixpkgs/pull/1734 .

merged in 447d625edc3a488deee1c9b2e5890dd974e55ee3, didn't notice it was to master

backported to staging-19.09 5c0ad0e3b2321fe8ecab9da8f710888b7de5df76

authors: dtzWill worldofpeace


text:
pastel: 0.5.3 -> 0.6.1

Motivation for this change
New version of pastel was released.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
me!

@GrahamcOfBorg build pastel

Thanks!
(not backporting for now: the bump itself would be fine, but the package isn't available on release atm)


text:
clightning: 0.7.2.1 -> 0.7.3

Motivation for this change
New release. Requires gettext to build as mentioned in the changelog (https://github.com/ElementsProject/lightning/blob/v0.7.3/CHANGELOG.md).
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] other Linux distributions (ArchLinux)

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @jb55

@jonringer sorry I didn't test on a NixOS machine before. It's fixed now after adding devtools/sql-rewrite.py to the patchShebang list.

all good

oops forgot to push

@GrahamcOfBorg build clightning

authors: jonasnick jonringer


text:
Add patch for haskell-iconv to support GHC 7.10.

This adds a minimal patch to make iconv compile under GHC 7.10. It adds an Applicative instance for a custom data type that has a Monad instance. The patch has been sent upstream.

The patches don't apply: http://hydra.cryp.to/build/915239/nixlog/2/raw

Ah, I notice that a new version of iconv, 0.4.1.3, was released today! This version adds support for GHC 7.10. So the patch of this PR is no longer necessary.
If you want, you can simply revert the changes of this PR, otherwise I can create a new PR to remove the patch file and the lines added to configuration-ghc-7.10.x.nix?

I've pushed a revert in 2f0f30b.

authors: peti rycee


text:
Replace vscode-extensions.ms-vscode.Go with vscode-extensions.golang.Go

Motivation for this change
From the README.md on https://github.com/golang/vscode-go:
"This is the new home for the VS Code Go extension. We just migrated from Microsoft/vscode-go. Learn more about our move on the Go blog."
Things done
I removed the old extension and replaced it with an alias to the new one. Unfortunately this leads to a lot of reformatting and noise (I used nixpkgs-fmt to fix the indentation).

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

is this up-to-date?

The merging of the aliases is wrong and causes  #104783. Sorry about that. I can have a look in ~2 hours, I think.

authors: jonringer priegger


text:
datefudge: work correctly even if GNU date is not in PATH

Examples in manual assumes advanced features from date(1) like "last
Friday", which only available in GNU coreutils version of date(1)
utility. Without this patch, most examples from datefudge(1) manual will
fail in busybox environment, which is confusing.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@ma27 @leenaars

Why not go for a patchless approach and use wrapProgram?

I agree with @dasJ, please wrap the program.

@SuperSandro2000 @dasJ Applied changes.

Result of nixpkgs-review pr 94045 run on x86_64-linux 1

1 package built:

datefudge

authors: KAction SuperSandro2000 dasJ


text:
expect: fix Darwin linkage

expect's build system doesn't seem to provide the proper linker flags
for the expect programs to be able to find libexpect on Darwin. (Stuff
like this should really just use libtool. *sigh*). Setting
DYLD_LIBRARY_PATH is an inelegant hack, but it gets the job done
without risking affecting other platforms.
cc @wkennington

merged

authors: dfoxfranke garbas


text:
glibmm: Add glib to nativeBuildInputs

Motivation for this change
While compiling, glibmm tries to execute glib-compile-schemas, which
requires glib to be in the nativeBuildInputs for cross-platform builds.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build glibmm
@GrahamcOfBorg build pkgsCross.aarch64-multiplatform.glibmm

@GrahamcOfBorg eval

@GrahamcOfBorg build glibmm
@GrahamcOfBorg build pkgsCross.aarch64-multiplatform.glibmm

authors: jonringer kampka


text:
firefox-esr-68: drop

Motivation for this change
Upstream EOL. This also needs a backport to 20.09, because we missed the branch-off on this.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Sounds good to me.
On Thu, Sep 10, 2020, 03:21 WORLDofPEACE notifications@github.com wrote:

@worldofpeace https://github.com/worldofpeace requested your review on:
#97612 https://github.com/NixOS/nixpkgs/pull/97612 firefox-esr-68: drop.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/97612#event-3748456574, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE365BKKBRH3FDBVRDILTDSFASZFANCNFSM4RDUMRQA
.

Either this or just mark it as insecure.  I'm not aware for any particular reasons to keep 68 around a bit longer (as insecure), unlike the situation that was with 52 for example.

Why was 52 kept around? Also, this is the only use of nss_3_44 in nixpkgs. That's an ESR release though and we might need it for Firefox 78 if that becomes incompatible with newer nss releases.

Quantum certainly did have some unpleasant consequences, but it's probably best to refer to past threads like https://github.com/NixOS/nixpkgs/pull/45787

78 has its own branch of nss upstream (3.53), so I don't see why keep 3.44 without FF 68.

BTW, Thunderbird will be an interesting story, as even today's 78 version isn't considered good enough to be default (by upstream) and 68 surely won't be supported for the whole 20.09 cycle.

@ajs124 would you mind also adding the following patch:
From 00cb1b182954d076f814889497c1630641177476 Mon Sep 17 00:00:00 2001
From: Florian Klink <flokli@flokli.de>
Date: Thu, 10 Sep 2020 20:40:16 +0200
Subject: [PATCH] nss_3_44: remove

This was only used for firefox-esr-68.
---
 .../networking/browsers/firefox/packages.nix  |   2 +-
 pkgs/development/libraries/nss/3.44.nix       | 144 ------------------
 .../libraries/nss/85_security_load-3.44.patch |  81 ----------
 pkgs/top-level/aliases.nix                    |   1 +
 pkgs/top-level/all-packages.nix               |   1 -
 5 files changed, 2 insertions(+), 227 deletions(-)
 delete mode 100644 pkgs/development/libraries/nss/3.44.nix
 delete mode 100644 pkgs/development/libraries/nss/85_security_load-3.44.patch

diff --git a/pkgs/applications/networking/browsers/firefox/packages.nix b/pkgs/applications/networking/browsers/firefox/packages.nix
index a024fc359d8..a5c017d9490 100644
--- a/pkgs/applications/networking/browsers/firefox/packages.nix
+++ b/pkgs/applications/networking/browsers/firefox/packages.nix
@@ -1,4 +1,4 @@
-{ config, stdenv, lib, callPackage, fetchurl, nss_3_44 }:
+{ config, stdenv, lib, callPackage, fetchurl }:

 let
   common = opts: callPackage (import ./common.nix opts) {};
diff --git a/pkgs/development/libraries/nss/3.44.nix b/pkgs/development/libraries/nss/3.44.nix
deleted file mode 100644
index ad58bfccaee..00000000000
--- a/pkgs/development/libraries/nss/3.44.nix
+++ /dev/null
@@ -1,144 +0,0 @@
-{ stdenv, fetchurl, nspr, perl, zlib, sqlite, fixDarwinDylibNames, buildPackages }:
-
-let
-  nssPEM = fetchurl {
-    url = "http://dev.gentoo.org/~polynomial-c/mozilla/nss-3.15.4-pem-support-20140109.patch.xz";
-    sha256 = "10ibz6y0hknac15zr6dw4gv9nb5r5z9ym6gq18j3xqx7v7n3vpdw";
-  };
-  version = "3.44.4";
-  underscoreVersion = builtins.replaceStrings ["."] ["_"] version;
-
-in stdenv.mkDerivation rec {
-  pname = "nss";
-  inherit version;
-
-  src = fetchurl {
-    url = "mirror://mozilla/security/nss/releases/NSS_${underscoreVersion}_RTM/src/${pname}-${version}.tar.gz";
-    sha256 = "7ec1a52e20fd9a23e1907eeba8f4f2ecd619dac5d20fa023ec5b4faa1843e847";
-  };
-
-  depsBuildBuild = [ buildPackages.stdenv.cc ];
-
-  nativeBuildInputs = [ perl ];
-
-  buildInputs = [ zlib sqlite ]
-    ++ stdenv.lib.optional stdenv.isDarwin fixDarwinDylibNames;
-
-  propagatedBuildInputs = [ nspr ];
-
-  prePatch = ''
-    xz -d < ${nssPEM} | patch -p1
-  '';
-
-  patches =
-    [
-      # Based on http://patch-tracker.debian.org/patch/series/dl/nss/2:3.15.4-1/85_security_load.patch
-      ./85_security_load-3.44.patch
-      ./ckpem.patch
-    ];
-
-  patchFlags = [ "-p0" ];
-
-  postPatch = stdenv.lib.optionalString stdenv.isDarwin ''
-    substituteInPlace nss/coreconf/Darwin.mk --replace '@executable_path/$(notdir $@)' "$out/lib/\$(notdir \$@)"
-  '';
-
-  outputs = [ "out" "dev" "tools" ];
-
-  preConfigure = "cd nss";
-
-  makeFlags = let
-    # NSS's build systems expects aarch32 to be called arm; if we pass in armv6l/armv7l, it
-    # fails with a linker error
-    cpu = if stdenv.hostPlatform.isAarch32 then "arm" else stdenv.hostPlatform.parsed.cpu.name;
-  in [
-    "NSPR_INCLUDE_DIR=${nspr.dev}/include"
-    "NSPR_LIB_DIR=${nspr.out}/lib"
-    "NSDISTMODE=copy"
-    "BUILD_OPT=1"
-    "SOURCE_PREFIX=\$(out)"
-    "NSS_ENABLE_ECC=1"
-    "USE_SYSTEM_ZLIB=1"
-    "NSS_USE_SYSTEM_SQLITE=1"
-    "NATIVE_CC=${buildPackages.stdenv.cc}/bin/cc"
-  ] ++ stdenv.lib.optionals (!stdenv.isDarwin) [
-    # Pass in CPU even if we're not cross compiling, because otherwise it tries to guess with
-    # uname, which can be wrong if e.g. we're compiling for aarch32 on aarch64
-    "OS_TEST=${cpu}"
-    "CPU_ARCH=${cpu}"
-  ] ++ stdenv.lib.optional (stdenv.hostPlatform != stdenv.buildPlatform) [
-    "CROSS_COMPILE=1"
-    "NSS_DISABLE_GTESTS=1" # don't want to build tests when cross-compiling
-  ] ++ stdenv.lib.optional stdenv.is64bit "USE_64=1"
-    ++ stdenv.lib.optional stdenv.isDarwin "CCC=clang++";
-
-  NIX_CFLAGS_COMPILE = "-Wno-error";
-
-  # TODO(@oxij): investigate this: `make -n check` works but `make
-  # check` fails with "no rule", same for "installcheck".
-  doCheck = false;
-  doInstallCheck = false;
-
-  postInstall = ''
-    rm -rf $out/private
-    mv $out/public $out/include
-    mv $out/*.OBJ/* $out/
-    rmdir $out/*.OBJ
-
-    ln -s lib $out/lib64
-
-    # Upstream issue: https://bugzilla.mozilla.org/show_bug.cgi?id=530672
-    # https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-libs/nss/files/nss-3.32-gentoo-fixups.patch?id=af1acce6c6d2c3adb17689261dfe2c2b6771ab8a
-    NSS_MAJOR_VERSION=`grep "NSS_VMAJOR" lib/nss/nss.h | awk '{print $3}'`
-    NSS_MINOR_VERSION=`grep "NSS_VMINOR" lib/nss/nss.h | awk '{print $3}'`
-    NSS_PATCH_VERSION=`grep "NSS_VPATCH" lib/nss/nss.h | awk '{print $3}'`
-    PREFIX="$out"
-
-    mkdir -p $out/lib/pkgconfig
-    sed -e "s,%prefix%,$PREFIX," \
-        -e "s,%exec_prefix%,$PREFIX," \
-        -e "s,%libdir%,$PREFIX/lib64," \
-        -e "s,%includedir%,$dev/include/nss," \
-        -e "s,%NSS_VERSION%,$NSS_MAJOR_VERSION.$NSS_MINOR_VERSION.$NSS_PATCH_VERSION,g" \
-        -e "s,%NSPR_VERSION%,4.16,g" \
-        pkg/pkg-config/nss.pc.in > $out/lib/pkgconfig/nss.pc
-    chmod 0644 $out/lib/pkgconfig/nss.pc
-
-    sed -e "s,@prefix@,$PREFIX," \
-        -e "s,@MOD_MAJOR_VERSION@,$NSS_MAJOR_VERSION," \
-        -e "s,@MOD_MINOR_VERSION@,$NSS_MINOR_VERSION," \
-        -e "s,@MOD_PATCH_VERSION@,$NSS_PATCH_VERSION," \
-        pkg/pkg-config/nss-config.in > $out/bin/nss-config
-    chmod 0755 $out/bin/nss-config
-  '';
-
-  postFixup = let
-    isCross = stdenv.hostPlatform != stdenv.buildPlatform;
-    nss = if isCross then buildPackages.nss.tools else "$out";
-  in ''
-    for libname in freebl3 nssdbm3 softokn3
-    do '' +
-    (if stdenv.isDarwin
-     then ''
-       libfile="$out/lib/lib$libname.dylib"
-       DYLD_LIBRARY_PATH=$out/lib:${nspr.out}/lib \
-     '' else ''
-       libfile="$out/lib/lib$libname.so"
-       LD_LIBRARY_PATH=$out/lib:${nspr.out}/lib \
-     '') + ''
-        ${nss}/bin/shlibsign -v -i "$libfile"
-    done
-
-    moveToOutput bin "$tools"
-    moveToOutput bin/nss-config "$dev"
-    moveToOutput lib/libcrmf.a "$dev" # needed by firefox, for example
-    rm -f "$out"/lib/*.a
-  '';
-
-  meta = with stdenv.lib; {
-    homepage = "https://developer.mozilla.org/en-US/docs/NSS";
-    description = "A set of libraries for development of security-enabled client and server applications";
-    license = licenses.mpl20;
-    platforms = platforms.all;
-  };
-}
diff --git a/pkgs/development/libraries/nss/85_security_load-3.44.patch b/pkgs/development/libraries/nss/85_security_load-3.44.patch
deleted file mode 100644
index 132d5a96b29..00000000000
--- a/pkgs/development/libraries/nss/85_security_load-3.44.patch
+++ /dev/null
@@ -1,81 +0,0 @@
-diff -ru -x '*~' -x '*.orig' -x '*.rej' nss/cmd/shlibsign/shlibsign.c nss/cmd/shlibsign/shlibsign.c
---- nss/cmd/shlibsign/shlibsign.c	2017-01-04 15:24:24.000000000 +0100
-+++ nss/cmd/shlibsign/shlibsign.c	2017-01-24 14:43:31.030420852 +0100
-@@ -875,6 +875,8 @@
-         goto cleanup;
-     }
-     lib = PR_LoadLibrary(libname);
-+    if (!lib)
-+        lib = PR_LoadLibrary(NIX_NSS_LIBDIR"libsoftokn3.so");
-     assert(lib != NULL);
-     if (!lib) {
-         PR_fprintf(PR_STDERR, "loading softokn3 failed");
-diff -ru -x '*~' -x '*.orig' -x '*.rej' nss/coreconf/config.mk nss/coreconf/config.mk
---- nss/coreconf/config.mk	2017-01-04 15:24:24.000000000 +0100
-+++ nss/coreconf/config.mk	2017-01-24 14:43:47.989432372 +0100
-@@ -202,3 +202,6 @@
-
- # Hide old, deprecated, TLS cipher suite names when building NSS
- DEFINES += -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES
-+
-+# Nix specific stuff.
-+DEFINES += -DNIX_NSS_LIBDIR=\"$(out)/lib/\"
-diff -ru -x '*~' -x '*.orig' -x '*.rej' nss/lib/pk11wrap/pk11load.c nss/lib/pk11wrap/pk11load.c
---- nss/lib/pk11wrap/pk11load.c	2017-01-04 15:24:24.000000000 +0100
-+++ nss/lib/pk11wrap/pk11load.c	2017-01-24 14:45:06.883485652 +0100
-@@ -440,6 +440,13 @@
-          * unload the library if anything goes wrong from here on out...
-          */
-         library = PR_LoadLibrary(mod->dllName);
-+        if ((library == NULL) &&
-+            !rindex(mod->dllName, PR_GetDirectorySeparator())) {
-+            library = PORT_LoadLibraryFromOrigin(my_shlib_name,
-+                (PRFuncPtr) &softoken_LoadDSO,
-+                mod->dllName);
-+        }
-+
-         mod->library = (void *)library;
-
-         if (library == NULL) {
-diff -ru -x '*~' -x '*.orig' -x '*.rej' nss/lib/util/secload.c nss/lib/util/secload.c
---- nss/lib/util/secload.c	2017-01-04 15:24:24.000000000 +0100
-+++ nss/lib/util/secload.c	2017-01-24 14:43:31.030420852 +0100
-@@ -70,9 +70,14 @@
-
-     /* Remove the trailing filename from referencePath and add the new one */
-     c = strrchr(referencePath, PR_GetDirectorySeparator());
-+    if (!c) { /* referencePath doesn't contain a / means that dladdr gave us argv[0]
-+               * and program was called from $PATH. Hack to get libs from NIX_NSS_LIBDIR */
-+        referencePath = NIX_NSS_LIBDIR;
-+        c = (char*) &referencePath[sizeof(NIX_NSS_LIBDIR) - 1]; /* last / */
-+    }
-     if (c) {
-         size_t referencePathSize = 1 + c - referencePath;
--        fullName = (char*)PORT_Alloc(strlen(name) + referencePathSize + 1);
-+        fullName = (char*) PORT_Alloc(strlen(name) + referencePathSize + 5);
-         if (fullName) {
-             memcpy(fullName, referencePath, referencePathSize);
-             strcpy(fullName + referencePathSize, name);
-@@ -82,6 +87,11 @@
- #endif
-             libSpec.type = PR_LibSpec_Pathname;
-             libSpec.value.pathname = fullName;
-+            if ((referencePathSize >= 4) &&
-+                (strncmp(fullName + referencePathSize - 4, "bin", 3) == 0)) {
-+                memcpy(fullName + referencePathSize -4, "lib", 3);
-+            }
-+            strcpy(fullName + referencePathSize, name);
-             dlh = PR_LoadLibraryWithFlags(libSpec, PR_LD_NOW | PR_LD_LOCAL
- #ifdef PR_LD_ALT_SEARCH_PATH
-                                                        /* allow library's dependencies to be found in the same directory
-@@ -89,6 +99,10 @@
-                                                        | PR_LD_ALT_SEARCH_PATH
- #endif
-                                           );
-+            if (! dlh) {
-+                strcpy(fullName + referencePathSize, name);
-+                dlh = PR_LoadLibraryWithFlags(libSpec, PR_LD_NOW | PR_LD_LOCAL);
-+            }
-             PORT_Free(fullName);
-         }
-     }
diff --git a/pkgs/top-level/aliases.nix b/pkgs/top-level/aliases.nix
index 0f21c24af67..4018e5589ae 100644
--- a/pkgs/top-level/aliases.nix
+++ b/pkgs/top-level/aliases.nix
@@ -340,6 +340,7 @@ mapAliases ({
   nix-review = nixpkgs-review; # added 2019-12-22
   nmap_graphical = nmap-graphical;  # added 2017-01-19
   nologin = shadow; # added 2018-04-25
+  nss_3_44 = throw "removed while dropping firefox-esr-68"; # added 2020-09-10
   nxproxy = nx-libs; # added 2019-02-15
   nylas-mail-bin = throw "deprecated in 2019-09-11: abandoned by upstream";
   opencascade_oce = opencascade; # added 2018-04-25
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 81c15de2d15..5fe70a31c68 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -14472,7 +14472,6 @@ in
   };

   nss = lowPrio (callPackage ../development/libraries/nss { });
-  nss_3_44 = lowPrio (callPackage ../development/libraries/nss/3.44.nix { });
   nssTools = nss.tools;

   nss_wrapper = callPackage ../development/libraries/nss_wrapper { };
--
2.28.0

Also, this is the only use of nss_3_44 in nixpkgs.

I thought I checked this… turns out, Thunderbird is using this as of a62d988aeba98dfeb9d6ff7c989bf15db54dee10.
@taku0 does Thunderbird 68.x not compile with more modern NSS, either?

Right, I forgot even though posting about both Thunderbird and this NSS version :-/  IIRC it did fail with newer NSS, meaning we can't drop it just yet.

/cc @NixOS/nixos-release-managers for the 20.09 implications.  (Say, in case they only want FF to be marked as insecure in 20.09.)  With Thunderbird there seems to be not much choice ATM.

/cc @NixOS/nixos-release-managers for the 20.09 implications. (Say, in case they only want FF to be marked as insecure in 20.09.) With Thunderbird there seems to be not much choice ATM.

Thx, I approve of this PR and marked it as blocker.

authors: ajs124 andir flokli vcunat worldofpeace


text:
marwaita-peppermint: 0.3 -> 0.4

Motivation for this change
Update to version 0.4
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/319

As it is a simple package update, tested locally, I am going to merge.

authors: nixos-discourse romildo


text:
Roundup: [oss-security] CVE Request - Multiple vulnerabilities in gdk-pixbuf

Here is a report from the oss-security mailing list for Vulnerability Roundup 27.
Skip to First Email
Instructions:
Identification
Identify if we have the software, in 16.09, 17.03, and unstable. Then determine if we are vulnerable, and make a comment with your findings. It can also be helpful to specify if you think there is a patch, or if it can be fixed via a general update.
Example:
unstable: we are not vulnerable (link to the package)
17.03: we are vulnerable (link to the package)
16.09: we don't have it packaged

IMPORTANT: If you believe there are possibly related issues, bring them up on the parent issue!
Patching
Start by commenting on this issue saying you're working on a patch. This way, we don't duplicate work.
If you open a pull request, tag this issue and the master issue for the roundup.
If you commit the patch directly to a branch, please leave a comment on this issue with the branch and the commit hash, example:
fixed:

release-16.09: abc123

Skip to First Email
Upon Completion ...

[ ] Update Graham's database

Info
Triage Indicator:
-needs-triage +roundup27 thread:0000000000003d51

File Search: https://search.nix.gsc.io/?q=gdk-pixbuf&i=fosho&repos=nixos-nixpkgs
GitHub Search: https://github.com/NixOS/nixpkgs/search?utf8=✓&q=gdk-pixbuf+in%3Apath&type=Code

Should the search term be changed from gdk-pixbuf? Suggest a new package search by commenting:
-suggested:gdk-pixbuf +suggested:correctPackageName thread:0000000000003d51

Known CVEs: CVE-2017-6311, CVE-2017-6312, CVE-2017-6313, CVE-2017-6314

Skip to End
Tue, 21 Feb 2017 17:20:11 +0200 Ariel Zelivanski <ariel.zelivans-at-gmail.com>, CAE-_4r3PgqHs2kVHLTzynYhcffE_AWu1Y8QFM5LXeA8kvMnbrw@mail.gmail.com
Hello,

I just reported several vulnerabilities in gdk-pixbuf. I am adding the
relevant details but you can also refer to the bug reports in the links. If
suitable please assign CVEs.

1. An dangerous integer underflow in io-icns.c [1]
--------------------------------------------------
io-icns.c is the source code for the loader of Macintosh icons.

An integer underflow I found allows an attacker to lead to different calls
to gdk_pixbuf_loader_write with a huge (2^32-1) count (size of buffer) that
can be bigger than the actual size of given buffer. It is possible to give
the loader any data we want so we can call any desired loader that it's
data is recognized. This may lead to various behaviors - multiple
out-of-buffer reads, infinite loops, or allocation attempt with the size.
Possibly other behaviors I did not test for (I didn't really check all
available loaders).

1.1 The bug
-----------
In the load_resources function (io-icns.c:63), inside the size switch (line
101), all the cases set plen or mlen to: blocklen - sizeof
(IcnsBlockHeader);
See lines 109, 117, 127, 134, 139, 146, 151, 158 and 163.
blocklen is set in line 95:

blocklen = GUINT32_FROM_BE (header->size);

There are no checks on the size of blocklen and if it is set to less than
sizeof (IcnsBlockHeader) (should be 8) there is an integer underflow.

This is dangerous because it's value is later passed to
gdk_pixbuf_loader_write (line 262) when size is 256. This allows an
attacker to craft a file that will end up calling to a desired loader with
a bogus size that is much larger than the actual buffer size.

Possible exploits of the bug:
1. Adding a bmp, or a an ico image data after the header will cause an
out-of-buffer read.
2. With a tiff image it would lead to an infinite loop (see bug 2).
3. With a gif, a tga or another icns after the header the code will try to
allocate as much as count bytes (and most likely fail on a size of 2^32-1).
Otherwise if the actual data size is less than 4096 there is an
out-of-bounds read.
4. With another icns it is possible to reach another out-of-bounds
4.1 If this out-of-bounds read gets zeros we will have an infinite loop

2. Infinite loop in io-tiff.c [2]
---------------------------------
This loader for tiff images will try and allocate a buffer as big as size
given to it. It calls the make_available_at_least function to do that.
The problem is in the function itself (from line 499):

if (need_alloc > context->allocated) {
    guint new_size = 1;
    while (new_size < need_alloc)
        new_size *= 2;
...

new_size starts with 1 and multiplies until it is larger or equal to
need_alloc. If need_alloc is larger than 2^31, new_size will become 2^31
and multiply itself in 2, and become 0. This would lead to an infinite loop.

3. Out-of-bounds read on io-ico.c [3]
-------------------------------------
io-ico.c is the source code for the loader of Windows icons.

State->HeaderSize is calculated in line 334:
State->HeaderSize = entry->DIBoffset + INFOHEADER_SIZE
entry->DIBoffset is read directly from the data

An integer overflow seems possible. However in line 336 it is checked if
(State->HeaderSize < 0), to prevent such overflow.
This works when compiling without or with basic optimization (in gcc, -O0
or -O1), but from -O2 this check seems to be ignored. Specifically when
compiled with "O1 -fstrict-overflow -ftree-vrp".
I believe many distributions are building with these flags.

When this is overflown it is possible later to reach a segmentation fault
thanks to an out-of-bounds read of the BIH variable (line 359: BIH =
Data+entry->DIBoffset;).

I tested this both on Arch and on Ubuntu 16.04.1 but it certainly affects
other distributions as well.

4. NULL dereference on gdk-pixbuf-thumbnailer [4]
-------------------------------------------------
This is a bug in gnome-thumbnailer-skeleton.c and it affects only the
latest versions of gdk-pixbuf (since moving the code from gnome-desktop the
the external thumbnailer in gdk-pixbuf[5]).

gnome-thumbnailer-skeleton.c:272 calls file_to_pixbuf. file_to_pixbuf
(gdk-pixbuf-thumbnailer.c:209) calls _gdk_pixbuf_new_from_uri_at_scale,
which calls gdk_pixbuf_loader_get_pixbuf (see gdk-pixbuf-thumbnailer:195).
gdk_pixbuf_loader_get_pixbuf may returns NULL, and it doesn't get a pointer
to an error object to set an error.
So when it returns NULL, on file_to_pixbuf pixbuf will be NULL, and on line
312 printing error->message will result in a NULL deference (error->message
will be 0x0 + 0x8).

5. Impact
---------
These bugs can break many binaries that rely on gdk-pixbuf and I can think
of various ways these bugs can be used maliciously. Obvious applications
are to cause DoS by segmentation faults or possibly by CPU exhaustion (with
the infinite loops) when possible. Besides crashing the thumbnailer and
some other desktop applications that use gdk-pixbuf I also managed to crash
Chromium and Firefox on Ubuntu (on both via their file browser which use
gdk-pixbuf). To see the full list of packages that use gdk-pixbuf on apt
based distributions run `apt-cache rdepends libgdk-pixbuf2.0-0
libgdk-pixbuf2.0-dev`.

Thanks to afl for helping me find bugs 3 and 4.

Links

[1] https://bugzilla.gnome.org/show_bug.cgi?id=779016
[2] https://bugzilla.gnome.org/show_bug.cgi?id=779020
[3] https://bugzilla.gnome.org/show_bug.cgi?id=779012
[4] https://bugzilla.gnome.org/show_bug.cgi?id=778204
[5]
https://git.gnome.org/browse/gdk-pixbuf/commit/?id=06cf4c78067203b78acbfb29862350cdb8200b73
[6] A blog post I wrote about this -
http://mov.sx/2017/02/21/bug-hunting-gdk-pixbuf.html

Skip to End

Tue, 21 Feb 2017 15:42:35 -0500 Leo Famulari <leo-at-famulari.name>, 20170221204235.GA26169@jasmine
On Tue, Feb 21, 2017 at 05:20:11PM +0200, Ariel Zelivanski wrote:
> Hello,
>
> I just reported several vulnerabilities in gdk-pixbuf. I am adding the
> relevant details but you can also refer to the bug reports in the links. If
> suitable please assign CVEs.

As announced previously [0], MITRE is no longer assigning CVEs based on
messages to this list. Will you request the CVE IDs via the new web
form? [1]

[0]
http://seclists.org/oss-sec/2017/q1/351

[1]
https://cveform.mitre.org/

signature.asc
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlispjcACgkQJkb6MLrK
fwiEkA//RoghGrWq90CKZGMaH6MjVnSHjEWrQzTK0Fki9EgVT70NPkwyUrsJZHE/
MwJ4cNtsxgpeEpgQevp2BB0yLoQ9aRKLmuAbuxyCPzdhOtwiFK/tuxLmjNj/IxZ9
+z+/G9tBA4xpH35DVWM5ugYhGmK65YreVtWM1PJ82Jk0YuSt8uKjLEcNxwKsl4la
PJ4ddx7y6Ps7KtPzHQRI7o2PTWD30KbG/mU8APBrZZqj3oZ6Az/D4ds6r7nW3XbJ
dipxW80JuLw+6/YszZ8lqSIsQIAUWromJpYYoP5ztkBZ0N/oHguL1aGBAp2GXFrA
Nw+26lf4tA6REhucMjXZvneKSs/PciSEnRrX5E876JjwMuVvWYyiFoFU723+CtyI
OAR0LYySyoPgZq43Mb3RiXSHmuwSj91FgmRNDs2WBMVsr/EGqZHMjXaXomiQJDgp
bhj3pF0v4R6qenPm71UtiipxPkQtqRnvEKoX1RdcsFhMLF1ZhpxFvCUHOciisZfM
ltjKQXr91JFutK6e7UXkrKKBgvuhXwyM00XokGPisRd7/x4Ce7piGGDu0tTjOV2J
QKGnfleuztqYKa6npNXekUBmcNVskLKsF84mCHqueCi/pJ7/iV6kztwA+zrrVETi
JV2/IhFJ2ejG/kMFnPYfA9cQFTZHztiPUVFa1NWD5abjwbFfyhU=
=FTxv
-----END PGP SIGNATURE-----

Skip to End

Thu, 23 Feb 2017 10:26:35 +0200 Ariel Zelivansky <ariel.zelivans-at-gmail.com>, CAE-_4r1MsrEuyF9cYcJe4bg4PrpD-YYptCq2ycZKYF9fT__Jpg@mail.gmail.com
Leo, thanks for the reference.

I have requested a CVE via the web form and haven't heard from MITRE so
far. Do they usually take time in responding?
Or am I supposed to contact some other CNA?

On Tue, Feb 21, 2017 at 10:42 PM, Leo Famulari <leo@famulari.name> wrote:

> On Tue, Feb 21, 2017 at 05:20:11PM +0200, Ariel Zelivanski wrote:
> > Hello,
> >
> > I just reported several vulnerabilities in gdk-pixbuf. I am adding the
> > relevant details but you can also refer to the bug reports in the links.
> If
> > suitable please assign CVEs.
>
> As announced previously [0], MITRE is no longer assigning CVEs based on
> messages to this list. Will you request the CVE IDs via the new web
> form? [1]
>
> [0]
> http://seclists.org/oss-sec/2017/q1/351
>
> [1]
> https://cveform.mitre.org/
>

--
*Ariel Zelivansky *— 0503990401

Skip to End

Sun, 26 Feb 2017 11:07:10 +0200 Ariel Zelivansky <ariel.zelivans-at-gmail.com>, CAE-_4r1+bd+5utcah-_TEh3CiDWdj=030=COQjtg57GTx997pQ@mail.gmail.com
To keep all the information in one place, the following CVE IDs had been
assigned by MITRE:
CVE-2017-6313 for [1]
CVE-2017-6314 for [2]
CVE-2017-6312 for [3]
CVE-2017-6311 for [4]

On Thu, Feb 23, 2017 at 10:26 AM, Ariel Zelivansky <ariel.zelivans@gmail.com
> wrote:

> Leo, thanks for the reference.
>
> I have requested a CVE via the web form and haven't heard from MITRE so
> far. Do they usually take time in responding?
> Or am I supposed to contact some other CNA?
>
> On Tue, Feb 21, 2017 at 10:42 PM, Leo Famulari <leo@famulari.name> wrote:
>
>> On Tue, Feb 21, 2017 at 05:20:11PM +0200, Ariel Zelivanski wrote:
>> > Hello,
>> >
>> > I just reported several vulnerabilities in gdk-pixbuf. I am adding the
>> > relevant details but you can also refer to the bug reports in the
>> links. If
>> > suitable please assign CVEs.
>>
>> As announced previously [0], MITRE is no longer assigning CVEs based on
>> messages to this list. Will you request the CVE IDs via the new web
>> form? [1]
>>
>> [0]
>> http://seclists.org/oss-sec/2017/q1/351
>>
>> [1]
>> https://cveform.mitre.org/
>>
>
>
>
> --
> *Ariel Zelivansky *— 0503990401 <050-399-0401>
>

Skip to End

The bug reports upstream have been untouched (for the whole time), except for one of them where a patch is proposed by someone.

We have a current version of gdk-pixbuf (preparing another update right now) and upstream still does not care about the issues. They did fix others in a timely manner. In one ticket, somebody asked why a CVE was assigned to this issue… I think we can safely close this.

source: gharchive/issue

authors: fpletz grahamc vcunat

repo: NixOS/security

license: mit

license_source: bigquery


text:
Roundup: [oss-security] jasper: NULL pointer dereference in jpc_tsfb_synthesize (jpc_tsfb.c)

Here is a report from the oss-security mailing list for Vulnerability Roundup 27.
Skip to First Email
Instructions:
Identification
Identify if we have the software, in 16.09, 17.03, and unstable. Then determine if we are vulnerable, and make a comment with your findings. It can also be helpful to specify if you think there is a patch, or if it can be fixed via a general update.
Example:
unstable: we are not vulnerable (link to the package)
17.03: we are vulnerable (link to the package)
16.09: we don't have it packaged

IMPORTANT: If you believe there are possibly related issues, bring them up on the parent issue!
Patching
Start by commenting on this issue saying you're working on a patch. This way, we don't duplicate work.
If you open a pull request, tag this issue and the master issue for the roundup.
If you commit the patch directly to a branch, please leave a comment on this issue with the branch and the commit hash, example:
fixed:

release-16.09: abc123

Skip to First Email
Upon Completion ...

[ ] Update Graham's database

Info
Triage Indicator:
-needs-triage +roundup27 thread:000000000000262e

File Search: https://search.nix.gsc.io/?q=jasper&i=fosho&repos=nixos-nixpkgs
GitHub Search: https://github.com/NixOS/nixpkgs/search?utf8=✓&q=jasper+in%3Apath&type=Code

Should the search term be changed from jasper? Suggest a new package search by commenting:
-suggested:jasper +suggested:correctPackageName thread:000000000000262e

Known CVEs: CVE-2016-10248

Skip to End
Thu, 20 Oct 2016 09:43:40 +0200 Agostino Sarubbo <ago-at-gentoo.org>, 5184269.v1vKSl7Lqd@blackgate
Description:
jasper is an open-source initiative to provide a free software-based reference
implementation of the codec specified in the JPEG-2000 Part-1 standard.

Another round of fuzzing on an updated version (1.900.5) revealed another NULL
pointer access

The complete ASan output:

# imginfo -f $FILE
warning: trailing garbage in marker segment (14 bytes)
warning: not enough tile data (15 bytes)
warning: bad segmentation symbol
warning: bad segmentation symbol
ASAN:DEADLYSIGNAL
=================================================================
==7144==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x7f6d3c37d0b0 bp 0x7ffdc7407a90 sp 0x7ffdc7407a30 T0)
    #0 0x7f6d3c37d0af in jpc_tsfb_synthesize /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_tsfb.c:152:4
    #1 0x7f6d3c2f5140 in jpc_dec_tiledecode /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:1068:3
    #2 0x7f6d3c2e5c40 in jpc_dec_process_sod /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:623:7
    #3 0x7f6d3c2ef294 in jpc_dec_decode /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:390:10
    #4 0x7f6d3c2ef294 in jpc_decode /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_dec.c:254
    #5 0x7f6d3c2bd061 in jp2_decode /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jp2/jp2_dec.c:215:21
    #6 0x7f6d3c24df39 in jas_image_decode /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/base/jas_image.c:380:16
    #7 0x4f1686 in main /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/appl/imginfo.c:188:16
    #8 0x7f6d3b35c61f in __libc_start_main /var/tmp/portage/sys-
libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x418e68 in _init (/usr/bin/imginfo+0x418e68)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/media-
libs/jasper-1.900.5/work/jasper-1.900.5/src/libjasper/jpc/jpc_tsfb.c:152:4 in
jpc_tsfb_synthesize
==7144==ABORTING

Affected version:
1.900.5

Fixed version:
1.900.9

Commit fix:
https://github.com/mdadams/jasper/commit/2e82fa00466ae525339754bb3ab0a0474a31d4bd

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-10-19: bug discovered
2016-10-19: bug reported to upstream
2016-10-20: upstream released the patch and 1.900.9
2016-10-20: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:
https://blogs.gentoo.org/ago/2016/10/20/jasper-null-pointer-dereference-in-jpc_tsfb_synthesize-jpc_tsfb-c/

Skip to End

Mon, 13 Mar 2017 11:31:33 +0100 Agostino Sarubbo <ago-at-gentoo.org>, 2036100.Yz5vC6aIUd@blackgate
On Thursday 20 October 2016 09:43:40 Agostino Sarubbo wrote:
> Permalink:
> https://blogs.gentoo.org/ago/2016/10/20/jasper-null-pointer-dereference-in-j
> pc_tsfb_synthesize-jpc_tsfb-c/

This is CVE-2016-10248

--
Agostino Sarubbo
Gentoo Linux Developer

Skip to End

Master: unaffected
16.09: unaffected
As both has version 2.0.12, which is after this CVE

we have jasper-2.0.10 not jasper-2.0.12, and the patch also needs to be applied to the latest versoin.

fwiw I've merged the .12 update, because they're usually worth updating to. This issue is still one.
The patches I madee are:
master: 6c17ad677c4970c87e8562574ea7e6fbf12b0813
release-16.09: 4368adb6ac631b3bdbb071e96dfc545c1f8f92e1
release-17.03: beab3073c9caec3e6b67558efc6111bb68c7a2ab

authors: Mic92 grahamc ndowens


text:
🛑 libreddit libreddit.spike.codes is down

In 1e30236, libreddit libreddit.spike.codes (https://libreddit.spike.codes) was down:

HTTP code: 0
Response time: 0 ms

Resolved: libreddit libreddit.spike.codes is back up in 4da4480 after 7 minutes.

repo: NoPlagiarism/services-personal-upptime


text:
🛑 AnonymousOverflow ao.vern.cc is down

In dfc4b6b, AnonymousOverflow ao.vern.cc (https://ao.vern.cc) was down:

HTTP code: 0
Response time: 0 ms

Resolved: AnonymousOverflow ao.vern.cc is back up in 4452cf0 after 8 minutes.


text:
🛑 ProxiTok tt.opnxng.com is down

In e0180a9, ProxiTok tt.opnxng.com (https://tt.opnxng.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ProxiTok tt.opnxng.com is back up in ce0c694 after 16 minutes.


text:
🛑 libreddit safereddit.com is down

In 4c366b6, libreddit safereddit.com (https://safereddit.com) was down:

HTTP code: 502
Response time: 254 ms

Resolved: libreddit safereddit.com is back up in 793de88 after 23 hours, 2 minutes.


text:
🛑 librarian (discontinued) lbry.mywire.org is down

In 8123cae, librarian (discontinued) lbry.mywire.org (https://lbry.mywire.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: librarian (discontinued) lbry.mywire.org is back up in 4a37e1d.


text:
Reorganizing the comments into a sane style

Put all the commentary ABOVE each relevant config line
Capitalized some comments, will do more later

Result: Smaller file, easier to read, easier to edit
Extra: This really shouldn't all be in a single file. This should be split up into multiple files. File count is cheap, sanity is not.

Thanks.
I personally actually find it harder to read/find the options vs the comments in your way.
Needs a better visual indication what is a comment and what is a changeable option.
Maybe an empty line before each option, maybe something else... when I'll look at it I'll know.
I'll gladly merge it when a proper indication is added. I too want the comments above - easier to maintain.

Very good point. I'll think up something. Perhaps:
  =begin rdoc
     This option will make your mother very happy.
  =end
  # config.mother = :happy

Work on this today

Alright, I've added some details to the commentary, specifically a default value line. I've also removed the default value from the commented out expression. I feel this will be easier for developers to understand: 1. What the default value was, 2. That the expression needs a value.

authors: NoamB krainboltgreene

repo: NoamB/sorcery


text:
Update README.md

Use SVG badges

Both SVG's work, so if we'd rather use those this should be good to merge.
What would you say the major benefit of switching is, @v-kolesnikov? Are they phasing out png generation in favor of SVG?

What would you say the major benefit of switching is, @v-kolesnikov?

SVG looks better.

Are they phasing out png generation in favor of SVG?

I can not know for sure, but it may very well be.

@Ch4s3, @arnvald?

Hey sorry I'm in holidays until Friday, will respond to all issues then!
On Thursday, 8 September 2016, Josh Buker notifications@github.com wrote:

@Ch4s3 https://github.com/Ch4s3, @arnvald https://github.com/arnvald?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NoamB/sorcery/pull/795#issuecomment-245810896, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAISHEdOc__VKN_KmYvtZKsWaLJ3WwwNks5qoNVHgaJpZM4J0kVm
.

--
Pozdrawiam / Best regards,
Grzegorz Witek

Merged @v-kolesnikov's commit directly onto a slightly bigger README PR, #797.

Merged on Sorcery/sorcery #5

authors: arnvald athix v-kolesnikov


text:
Fix CI failures in rethnet/main

Fix the CI failures in rethnet/main:

Error: Contract with code hash ... does not exist
1.1. This is caused by checking block numbers for safety in CachedRemoteState before caching them and then not having a code in the cache when code_by_hash is called
1.2. Introduced in https://github.com/NomicFoundation/hardhat/pull/4333
1.3. I did a PR to undo the block number safety check in CachedRemoteState, otherwise I’m not sure what’s the best real solution is. A simple idea would be to always cache code hashes, but maybe this has correctness implications elsewhere.
Error: Timeout of 50000ms exceeded
2.1. Test actually succeeds after 5 mins
2.2. This was introduced in https://github.com/NomicFoundation/hardhat/pull/4319
2.3. It seems to make the many get balance and get account info requests
2.4. I’m still trying to figure out the cause of the slow down as the get account info requests are for different addresses, so they were probably not cached before either
Expected block 18030159 to have a timestamp increase of 1, but got 2 instead
3.1. I haven’t looked into this yet

Definition of Done
The above failures are fixed.

Related: https://github.com/NomicFoundation/hardhat/pull/4349

Can't repro failure 3 anymore.

repo: NomicFoundation/rethnet


text:
whether here has some guide by which tell us how to replace the old react-spatial-navigation with the new 'Norigin-Spatial-Navigation'

in my react project, I'm upgrade the old navigation library with the new one, can you please provide me with some guild for that?

Hello @rick-liyue-huang,
There is a guide on this in the README here: https://github.com/NoriginMedia/Norigin-Spatial-Navigation?tab=readme-ov-file#examples
Best of luck with your migration work.

authors: predikament rick-liyue-huang

repo: NoriginMedia/Norigin-Spatial-Navigation


text:
Lagring av teikningar på mareano til shape format

Legge inn mulighet for å lagre teikningane i kartløysinga i shape og andre format.

Tegninger har blitt tatt vekk.

repo: Norwegian-marine-datacentre/mareano


text:
Fix --all on export

yt-fts export "word" --all returns channel not found error

fixed in #38. No idea why this happens

repo: NotJoeMartinez/yt-fts

license: Unlicense


text:
Mount Ouster lidar interface box & wiring

Nominally it seems like the box is powered with 24V DC, but I believe it should work with 12V DC... should double check!

OS! - Rev 7:  https://static.ouster.dev/sensor-docs/hw_user_manual_OS1/hw_common_sections_OS1/os1-overview.html#intro-os1

Important Note regarding power supply for Interface Box: "The OS1 Sensors are designed to operate between 12V and 24V nominal input voltage. A low voltage warning will be triggered if the voltage at the sensor connector drops below 9.5V. The sensor will shut down if this input voltage drops to 9V. The maximum input voltage is 34V for the OS1 sensor."

@meyli1 @5408Andy I know Sasha is out of town, so I just drilled these holes in the lidar box mounting plate. You should be good to go now!

repo: Nova-UTD/hardware


text:
Catalog2Registration - Slow for packages with lots of versions

For packages with lots of versions (RavenDB, FAKE, ...) the catalog2registration process is slow. Optimize it so registration entries are written much faster.

@shishirx34 what's the status on this? Were the changes deployed to prod?

@skofman1  - From what I can gather, Maarten merged the above PR on Aug 1, and from our deployments I do not see there have been any deployments for Catalog2Registration on Prod. These changes seem to be deployed to Int and Dev. For Prod, the deployment seem to be partially done but never completed.
We need to create a task to complete this deployment to Prod.
Should we be doing a regular Jobs deployment similar to Gallery?

@maartenba - I know its been a while, but, do you happen to remember the merged PR https://github.com/NuGet/NuGet.Services.Metadata/pull/80 which has been deployed to Dev and Int is safe to be deployed to Prod?

It should be good :-)

repo: NuGet/NuGetGallery


text:
Log relevant credential object with Register and RequestPasswordReset audits

For an alternate internal IAuditingService implementation the credential type information for Register and RequestPasswordReset audits is necessary.  While it's possible to guess this from all available credentials, it makes sense to log this at the source.

Resolved by #3666 and #3667.


text:
New Project: .NET Single-file Explorer

I've been working with single-file applications lately, and I find myself wanting a tool like NuGet Package Explorer to inspect the bundled contents.
Version 1 of the bundle format is documented here, and version 2 is here.
Like a .nupkg, it's essentially just some metadata and a bunch of .NET files. The layout and View Content (including Plugins) of NuGet Package Explorer could all be reused to create a consistent experience between the two apps.
The code for writing bundles is contained in the Microsoft.NET.HostModel package. Understandably, the code for reading bundles is currently all native.

I'm not opposed to possibly supporting this, but I think it'd be a very large lift as NPE today is tight with the NuGet object model. Happy to discuss a solution if someone wants to jump in and take a look.

Looks like ILSpy implement this.

authors: bricelam clairernovotny


text:
v1.0.0-b2

Additional Details

Version: v1.0.0 (b1)
Last updated: 08 March 2023 08:50 (UTC)

~ Add

SVG component
Footer component
Main- Page route

/

~ Update

SEO
Company [siret] - Page route

/company/[siret]

~ Fix

SEO

✓ This pull request has been approved ✓
Additional Details
Pull number: #3

repo: NuState/NuStateAPI