jiebi/CodeConvo huggingface dataset:
Change:
src = fetchurl { url = "https://github.com/wireapp/wire-desktop/releases/download/" <del> + "macos%2F${version}/Wire.pkg"; inherit sha256; </del> <ins> + "macos%2F${version}/Wire.pkg"; inherit hash; </ins> }; buildInputs = [

Discussion:
wire-desktop will show the login screen after a few seconds on startup, even after clearing and logging into a new session. Steps to reproduce the behavior: Wire not already logged into an account, log in a few seconds UI will redirect to the login screen with no way to return to the normal UI for your logged-in account To be able to navigate the account UI without interruption. !
has experienced this same problem. This didn't seem to resolve the problem either. The macOS version has kept working over all the bumps. Maybe the wire-desktop deb has accrued a new dependency that we're not providing?
I tried again with the flag to see the browser console, and there wasn't anything helpful in there.
theres multiple dev tools levels in the wire app. can you try this should get more substantive logs
That's more like it!
This looks interesting: [:1213/.:INFO:CONSOLE(55)] "%c [2022-12-12 20:34:49] color:; font-weight:bold; Redirecting to login after connectivity verification. Reason: multiple_tabs", source: (55) [2022-12-12 20:34:49] Navigating inside <webview. URL: *&id=-dead-beef-dead-
I ran the same log line, and in my case, didn't see that multiple tabs error message. Seems to be an unrelated red herring. But I could see the "GPU process crashed. Will reload the window" in both mine and your logs.
It's probably a long shot, but could this possibly be related to electron/electron?
why do you think it's related? The issue complains about silent fallback to software rendering, but no crash. In the , I see most of the rendering to be disabled / software rendering too: …but even slow software rendering doesn't seem to work.
I also ran into this issue after upgrading nixos (unstable). I even tried the latest version .
Same issue with 3.30.3016. What GPU do you use?
Its the AMD GPU integrated into Ryzen 7 4800H.

In case someone really wants to get around this: I could get wire-desktop running by deleting these lines:
The docs of the deprecated mention "it isn't always because it's crashed": I sent a PR at , which uses the recommended event handler, removed the call, and more logging of the event details.
Yup, the suspicion was right :-) With the above PR applied, logs the following event details: … which clearly isn't a gpu rendering crash, at least nothing where reloading the GUI would help much. It also seems to recover. A new release with the fix can be found at
has been updated to include the fixed version. , can you take a look?
Change:
stabber = callPackage ../misc/stabber { }; <ins> stacer = libsForQt5.callPackage ../tools/system/stacer { }; </ins> starcharts = callPackage ../servers/misc/starcharts { }; staticjinja = with python3.pkgs; toPythonApplication staticjinja;

Discussion:
Project description Stacer is an open source system optimizer and application monitor that helps users to manage entire system with different aspects, its an all in one system utility. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux
Change:
curlWithGnuTls dbus expat <del> ffmpeg </del> <ins> ffmpeg_4 # Requires libavcodec < 59 as of 1.2.9.743.g85d9593d </ins> fontconfig freetype gdk-pixbuf

Discussion:
A clear and concise description of what the bug is. You can browse files and it'll show them but playing a song (in my case an MP3 file) results in this error: On the next start, the song is greyed out. I've d it and it seems to try (and fail?) to load libavcodec. That might be why. is in spotify's library path but somehow it's not loading. Investigating now. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Fallout from , PR incoming.
Change:
, file , substituteAll , writeTextFile <ins> , writeShellApplication </ins> }: let

Discussion:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!
Change:
<ins> diff --git a/include/internal/cryptlib.h b/include/internal/cryptlib.h index 329ef62..9a8df64 100644 --- a/include/internal/cryptlib.h +++ b/include/internal/cryptlib.h @@ -56,7 +56,7 @@ DEFINE_LHASH_OF(MEM); # ifndef OPENSSL_SYS_VMS #  define X509_CERT_AREA          OPENSSLDIR #  define X509_CERT_DIR           OPENSSLDIR "/certs" -#  define X509_CERT_FILE          OPENSSLDIR "/cert.pem" +#  define X509_CERT_FILE          "/etc/ssl/certs/ca-certificates.crt" #  define X509_PRIVATE_DIR        OPENSSLDIR "/private" #  define CTLOG_FILE              OPENSSLDIR "/ct_log_list.cnf" # else </ins>

Discussion:
We don't seem to have a sane default in openssl 1.1. Example: Compare to openssl 1.0.2 (default ATM): The problem also propagates to (and probably elsewhere). Of course, the CA path can be overridden via parameters and/or env vars, but we do need a sane default, too. With 1.0.2 we apply to get default, whereas with 1.1 I can't see any similar change. I haven't dug deep so far. I guess you won't remember why you "dropped" the patch in ? EDIT: I see the patched file has moved in upstream source tree.
Change:
nix-serve = callPackage ../tools/package-management/nix-serve { }; <ins> nix-serve-ng = haskell.lib.compose.justStaticExecutables haskellPackages.nix-serve-ng; </ins> nix-simple-deploy = callPackage ../tools/package-management/nix-simple-deploy { }; alejandra = callPackage ../tools/nix/alejandra { };

Discussion:
Project description Metadata homepage URL: source URL: license: bsd3 platforms: linux
it will be packaged automatically for the haskellPackages package set.
Change:
bonzomatic = callPackage ../applications/editors/bonzomatic { }; <ins> booster = callPackage ../applications/system/booster {}; </ins> bottles = callPackage ../applications/misc/bottles/fhsenv.nix { }; bottles-unwrapped = callPackage ../applications/misc/bottles { };

Discussion:
I see that you started working on a new initramfs generator here I wonder if you are interested to look at my project called Booster is a small and fast initramfs. It does not require external libraries (it is a static go binary) and generates a minimalistic image (no systemd, no even libc by default). It supports root filesystem encryption, clevis-type binding, remote unlocking, etc... It is currently packaged at Arch, Void, Alpine Linuxes and tested at Fedora as well. I am happy to answer your questions about the project. Metadata homepage URL: source URL: license: MIT platforms: linux
We are currently moving towards using systemd in initrd for NixOS, but if you would like to package in Nix for inclusion in nixpkgs, a PR would be welcome. In theory we could include a NixOS option for using instead in NixOS's initrd, but I don't expect we'll be able to maintain 3 different initrd infrastructures (the old shell script infra, the new systemd infra, and a new booster infra)
If you provide some framework that allows integrating pluggable initrd then it should work. The framework should be able to call the initrd hooks on events like "kernel updated", "package updated". Many distros use this technique - Arch, Debian, Fedora, ... the framework itself needs to be created by nixos team. But it is relatively simple and stable codebase. I do not expect much effort to maintain this code. As of maintenance itself - I'll be happy to do it for NixOS users the same way as I currently do for Arch/Void/Alpine users.
Change:
''; }; <ins> settings = mkOption { type = types.attrsOf types.anything; default = {}; description = lib.mdDoc '' Structural Wordpress configuration. Refer to <https://developer.wordpress.org/apis/wp-config-php> for details and supported values. ''; example = literalExpression '' { WP_DEFAULT_THEME = "twentytwentytwo"; WP_SITEURL = "https://example.org"; WP_HOME = "https://example.org"; WP_DEBUG = true; WP_DEBUG_DISPLAY = true; WPLANG = "de_DE"; FORCE_SSL_ADMIN = true; AUTOMATIC_UPDATER_DISABLED = true; } ''; }; mergedConfig = mkOption { readOnly = true; default = mergeConfig config; defaultText = literalExpression '' { DISALLOW_FILE_EDIT = true; AUTOMATIC_UPDATER_DISABLED = true; } ''; description = lib.mdDoc '' Read only representation of the final configuration. ''; }; </ins> extraConfig = mkOption { type = types.lines; default = "";

Discussion:
Some wordpress applications, , assume this variable is present, even if they do not use it. I am unclear if this is undefined behaviour or a convention, but I have had to set to get wordpress to not crash after activating the plugin. Could we use or as the fallback, instead of leaving it undefined? Steps to reproduce the behavior: Please run and paste the result.
We should check what the Wordpress installer does in this case and if is usually written into
I have not manually tested it, but as best as I can grok, they set whatever the user provides, so seems more canonical?
Tested in a VM and you're right, setting DB_PASSWORD to '' seems to be the default case ! We should fix that and add a comment in the Wordpress module that this is the default behavior. Thanks for pointing that issue out!
Trying to fix this in this PR
Change:
stdenv.mkDerivation rec { name = "file-${version}"; <del> version = "5.35"; </del> <ins> version = "5.36"; </ins> src = fetchurl { urls = [ "ftp://ftp.astron.com/pub/file/${name}.tar.gz" "https://distfiles.macports.org/file/${name}.tar.gz" ]; <del> sha256 = "0ijm1fabm68ykr1zbx0bxnka5jr3n42sj8y5mbkrnxs0fj0mxi1h"; </del> <ins> sha256 = "0ya330cdkvfi2d28h8gvhghj4gnhysmifmryysl0a97xq2884q7v"; </ins> }; nativeBuildInputs = stdenv.lib.optional (stdenv.hostPlatform != stdenv.buildPlatform) file;

Discussion:
, (nixos-unstable) (nixos-unstable) (nixos-unstable) (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
Fixed in staging (again) via PR
Change:
# Make sure the notification email setting applies ./notification_email.patch <ins> # Change the path to the public directory reported by Discourse # to its real path instead of the symlink in the store, since # the store path won't be matched by any nginx rules ./public_dir_path.patch </ins> ]; postPatch = ''

Discussion:
A URL like generates the following error log: Steps to reproduce the behavior: to download a file that has been uploaded Should download the file Are you seeing this problem on your non-beta versions of Discourse? It looks like maybe the X-Accel-Mapping isn't applying and then the request to download a file is getting fed back into Rails.
I've confirmed this is also an issue on Discourse 2.7.5 for NixOS.
This can be fixed with: However, I think this is probably a bad fix as is, because you might be able to trick discourse into serving arbitrary files in the /nix store. Two possible solutions: Discourse so it serves files with paths like /run/discourse instead a much more specific location regex in nginx to mitigate the issue I noted above Do you have any other ideas?
This works and should be safer:
My hunch is that it's both safer and cleaner to patch Discourse. If I follow the code correctly, I believe this is what would need to be changed to just return : There is already a match in place in the nginx config, so nothing more should be necessary.
That's the same place I followed the code to, so that is probably correct. I'll look into patching it.
Change:
distutils_extra simplejson readline glance cheetah lockfile httplib2 # !!! should libvirt be a build-time dependency?  Note that # libxml2Python is a dependency of libvirt.py. <del> libvirt libxml2Python </del> <ins> libvirt libxml2Python urlgrabber </ins> ]; buildInputs =

Discussion:
I've just started using nixos, and so far everything is working perfectly apart from Agda. I see that previous issues, and concerned compilation of the stdlib and agdaPrelude, but I cannot get Agda to compile anything at all. Even for a simple file, not dependent on any libraries, I get the following error message: /nix/store/26hl2dmpk05m5bgybvp42686rfmcgzl8-Agda-2.5.2-data/share/ghc-8.0.2/x86_64-linux-ghc-8.0.2/Agda- openBinaryFile: permission denied (Read-only file system) Looking in this directory tells me that Agda has not been able to compile its base libraries as it is unable to write its .agdai files in the directory. I've no idea how to solve this. I've tried both installing via my and also using nix-env. Neither seems to make a difference. I have GHC installed only via nix-env. nix-env -f "<nixpkgs" -iA haskellPackages.Agda agda System: 17.09pre112899. (Hummingbird) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: "17.09pre112899." Sandboxing enabled: true Any help would be much appreciated!
I can confirm the issue. As a temporary workaround I've used the Agda package from an older nixpkgs revision by adding a package override to my { packageOverrides = pkgs : let fetchNixPkgs = { rev, sha256 }: pkgs.fetchFromGitHub { inherit sha256 rev; owner = "NixOS"; repo = "nixpkgs-channels"; }; pinnedPkgs = import (fetchNixPkgs { rev = ""; sha256 = "0kf5babd9y7r5wz4982m637x65lh8m4qma6gpc9mix1bxp2bvh8q"; }) {}; in { pinned = pinnedPkgs; }; } and installing it via nix-env -f "<nixpkgs" -iA pinned.haskellPackages.Agda For details on the workaround see .
Thanks that worked a treat.

I doubt I would have ever come up with this solution myself. To install the standard library will I have to do the same thing and use an older version of nixpkgs?
You're welcome! For the standard library I've used the same workaround, i.e. installing , and made sure emacs runs the Agda executable with as described in the last section of .
Again, thanks to installing the libraries is also easy via this method. I'm going to leave this issue open though as it is a workaround rather than a solution.
Change:
<del> { lib , buildPythonApplication , fetchFromGitHub , setuptools-scm , setuptools , vdf , pillow , substituteAll , writeShellScript , steam-run , winetricks , yad , pytestCheckHook , nix-update-script , extraCompatPaths ? "" </del> <ins> { lib, buildPythonApplication, fetchFromGitHub, substituteAll, writeShellScript, steam-run, fetchpatch2, setuptools-scm, setuptools, vdf, pillow, winetricks, yad, pytestCheckHook, nix-update-script, extraCompatPaths ? "", </ins> }: buildPythonApplication rec { pname = "protontricks"; <del> version = "1.11.1"; </del> <ins> version = "1.12.0"; </ins> src = fetchFromGitHub { owner = "Matoking"; <del> repo = pname; rev = version; sha256 = "sha256-a40IAFrzQ0mogMoXKb+Lp0fPc1glYophqtftigk3nAc="; </del> <ins> repo = "protontricks"; rev = "refs/tags/${version}"; hash = "sha256-dCb8mcwXoxD4abJjLEwk5tGp65XkvepmOX+Kc9Dl7fQ="; </ins> }; patches = [

Discussion:
Package name: protontricks Latest released version: 1.12.0 <!-- Search your package here: --- Current version on the unstable channel: 1.11.1 Current version on the stable/release channel: 1.11.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Solves the following bug / problem Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
unset 'configureFlagsArray[i]' fi done <del> configureFlagsArray+=( "--enable-profile-use=cross" "--with-pgo-profile-path="$TMPDIR/merged.profdata"" "--with-pgo-jarlog="$TMPDIR/jarlog"" ) </del> <ins> appendToVar configureFlags --enable-profile-use=cross appendToVar configureFlags --with-pgo-profile-path=$TMPDIR/merged.profdata appendToVar configureFlags --with-pgo-jarlog=$TMPDIR/jarlog </ins> ${lib.optionalString stdenv.hostPlatform.isMusl '' LDFLAGS="$OLD_LDFLAGS" unset OLD_LDFLAGS

Discussion:
Please see the build logs of librewolf here: You can find for the first build. The second build should have set, but it's not there. I also think the current way of doing PGO can be improved. I am working on splitting the derivation into two, one for profile generation and one for profile use, which should also make investigating this problem easier. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
So for some reason extending does not affect the resulting configure flags. Not yet sure why.
Bisected to commit Author: Artturin <: Wed Jun 1 00:34:59 2022 +0300 stdenv: support opt-in _structuredAttrs Co-authored-by: Robin Gloster <: print message if structuredAttrs is enabled stdenv: add append reduces the chance of a user doing it wrong fix nix develop issue output hooks don't work yet in nix develop though making $outputs be the same on non-structuredAttrs and structuredAttrs is too much trouble. lets instead make a function that gets the output names reading environment file '/nix/store/2x7m69a2sm2kh0r6v0q5s9z1dh41m4xf-xz-5.2.5-env-bin' nix: std::string Common::makeRcScript(nix::ref<nix::Store, const BuildEnvironment&, const Path&): Assertion `outputs != ()' failed.

use a function to get all output names instead of using $outputs copy env functionality from .../cluster/nomad- | 2 +- pkgs/build-support/bintools- | 4 +- pkgs/build-support/release/nix- | 2 +- pkgs/build-support/setup-hooks/auto- | 2 +- pkgs/build-support/setup-hooks/move- | 12 +- pkgs/build-support/setup-hooks/multiple- | 34 ++-- .../setup-hooks/patch-ppd-files/patch-ppd- | 2 +- pkgs/build-support/setup- | 21 +- pkgs/build-support/setup-hooks/win-dll- | 2 +- pkgs/build-support/testers/expect- | 2 +- pkgs/data/icons/catppuccin- | 2 +- | 2 +- | 2 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 2 +- .../darwin/signing-utils/auto-sign- | 2 +- pkgs/stdenv/generic/default- | 4 + pkgs/stdenv/generic/make- | 31 ++- | 222 ++++++++++++++++----- | 2 +- 29 files changed, 272 insertions(+), 120 deletions(-)
Change:
, runtimeShell, gsettings-desktop-schemas }: let <del> versionSuffix = "20190508150240.6614a49937"; </del> <ins> versionSuffix = "20190612201656.952fee6c59"; </ins> in stdenv.mkDerivation rec { name = "keybase-gui-${version}"; <del> version = "4.0.0"; # Find latest version from https://prerelease.keybase.io/deb/dists/stable/main/binary-amd64/Packages </del> <ins> version = "4.1.0"; # Find latest version from https://prerelease.keybase.io/deb/dists/stable/main/binary-amd64/Packages </ins> src = fetchurl { url = "https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/keybase_${version + "-" + versionSuffix}_amd64.deb"; <del> sha256 = "1fj92gxwfd6909r79prsq760b9s50js1iip5c01621hz9y39jd6m"; </del> <ins> sha256 = "0jwxw75yz7sbvfqw2aksa3p7jlcv817743fl59qk6rq1x9ag6qpx"; </ins> }; nativeBuildInputs = [

Discussion:
Hi, I'm a Keybase developer and some of our users reported that the Nix packages were out of date. Keybase 4.1.0 was released a while ago, so I believe these need to be updated: Additionally, the KBFS nix should point to the new remote, with , and be on the same version as the other packages (4.1.0). Please let me know if you have any questions, happy to answer! Thanks. N/A N/A
if the users are using the stable branch, then the update will need to be backported. Otherwise if they are unstable then it should be just a few short moments ;)
KBFS has not been updated as directed here.
Change:
buildGoModule rec { pname = "zk"; <del> version = "0.8.0"; </del> <ins> version = "0.9.0"; </ins> src = fetchFromGitHub { owner = "mickael-menu"; repo = "zk"; rev = "v${version}"; <del> sha256 = "sha256-lTg5jB3krZWmCn3wWoAwzqBji1AyTTTVf/BphC7Mr5s="; </del> <ins> sha256 = "sha256-AXKIi70evf581lMwfbfxm8hFCzsnhKRQgnIEZQFS75A="; </ins> }; vendorSha256 = "sha256-m7QGv8Vx776TsN7QHXtO+yl3U1D573UMZVyg1B4UeIk=";

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: zk <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.8.0 desired version: 0.9.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
--zsh <($out/bin/starship completions zsh) ''; <del> cargoHash = "sha256-Q1VY9RyHEsQAWRN/upeG5XJxJfrmzj5FQG6GBGrN0xU="; </del> <ins> cargoHash = "sha256-hs0ImaozKH6QcUfts+oseUqecg7bGX5cx50ixnNamW8="; </ins> preCheck = '' HOME=$TMPDIR

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: starship <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.11.0 desired version: 1.12.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.