jiebi/CodeConvo huggingface dataset:
Code change:
When typing something here: <img src="https://user-" width=50%The desktop crashes and you have to re-login (well it's Chinese in the screenshot but I hope you get the idea) <img src="https://user-" width=50%Steps to reproduce the behavior: budgie menu something crash No crash. See above. I don't see this issue before the GNOME 44 update. Probably another issue but I haven't go deep yet. I am on right now, it's nixos-unstable with pull request picked.
Backtrace points to <details</detailsLooks like there are changes on that touches after 10.7.1, I am testing that right now.
I gave the latest HEAD (i.e. ) a try and cannot reproduce the issue so probably some of the commits fixes the issue. I wonder if this can be reproduce by others and if some fixes can be backported before 23.05
Ohhh goooooood and now I am reading , let me make some noise there Edit:
And now I am on , which has glib 2.74 ( has 2.76). This is going to be weird because with G_SLICE=always-malloc I also cannot reproduce the crash (budgie-desktop 10.7.1), so probably not related to the slice allocator. Edit: and it's vala 0.56.4 on (no crash) and 0.56.6 on (crash)
Okay I guess I can basically confirm it's caused by vala update because I am now on and cannnot reproduce the crash, wow it's first time I know valac can really cause issues :seenoevil: Bisect is too painful for my slow laptop :upsidedownface:
Could you try compiling and running this Vala code on the broken version to see if it also crashes? It should do the same thing as the crashing Budgie code, just without crashing your desktop. If this ends up being a Vala issue, we need a minimal reproduction program to send. Build and run with (assuming you put it in a file called ):
I am now on and my desktop crashes, so the current range is :upsidedownface: I am away from keyboard for the next few hours because it's midnight here but feel free to drop questions :upsidedownface: I built the program with vala 0.56.5, it exits normally with
Well, crap. I was hoping that would crash. Maybe this version when you get back? It's closer to the code in Budgie: Of those commits, the only one that really looks suspicious to me is at a glance.
I am still here (for now) :laughing: but this runs normally for me as well (hmmm can we really guarantee "if I can trigger the desktop crash, then using same vala same laptop same setup we can trigger a crash with some different program"?)

Related discussion:
text: gnome.gnome-bluetooth_1_0 gnome.gnome-settings-daemon gnome.mutter <ins> gnome.zenity </ins> graphene gtk3 ibus
Code change:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that

Related discussion:
text: source 'https://rubygems.org' gem 'jekyll' <ins> gem 'jekyll-feed' </ins> gem 'jekyll-paginate' gem 'rdiscount' gem 'RedCloth' <ins> gem 'minima' </ins>
Code change:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that

Related discussion:
text: GEM remote: https://rubygems.org/ specs: <del> RedCloth (4.2.9) colorator (0.1) ffi (1.9.10) jekyll (3.0.1) colorator (~> 0.1) </del> <ins> RedCloth (4.3.2) addressable (2.5.0) public_suffix (~> 2.0, >= 2.0.2) colorator (1.1.0) ffi (1.9.18) forwardable-extended (2.6.0) jekyll (3.4.1) addressable (~> 2.4) colorator (~> 1.0) </ins> jekyll-sass-converter (~> 1.0) jekyll-watch (~> 1.1) kramdown (~> 1.3) liquid (~> 3.0) mercenary (~> 0.3.3) <ins> pathutil (~> 0.9) </ins> rouge (~> 1.7) safe_yaml (~> 1.0) <del> jekyll-sass-converter (1.4.0) sass (~> 3.4) jekyll-watch (1.3.0) listen (~> 3.0) </del> <ins> jekyll-feed (0.9.1) jekyll (~> 3.3) </ins> jekyll-paginate (1.1.0) <del> kramdown (1.9.0) </del> <ins> jekyll-sass-converter (1.5.0) sass (~> 3.4) jekyll-watch (1.5.0) listen (~> 3.0, < 3.1) kramdown (1.13.2) </ins> liquid (3.0.6) <del> listen (3.0.5) rb-fsevent (>= 0.9.3) rb-inotify (>= 0.9) mercenary (0.3.5) rb-fsevent (0.9.7) rb-inotify (0.9.5) </del> <ins> listen (3.0.8) rb-fsevent (~> 0.9, >= 0.9.4) rb-inotify (~> 0.9, >= 0.9.7) mercenary (0.3.6) minima (2.1.0) jekyll (~> 3.3) pathutil (0.14.0) forwardable-extended (~> 2.6) public_suffix (2.0.5) rb-fsevent (0.9.8) rb-inotify (0.9.8) </ins> ffi (>= 0.5.0) <del> rdiscount (2.1.8) rouge (1.10.1) </del> <ins> rdiscount (2.2.0.1) rouge (1.11.1) </ins> safe_yaml (1.0.4) <del> sass (3.4.20) </del> <ins> sass (3.4.23) </ins> PLATFORMS ruby
Code change:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that

Related discussion:
text: DEPENDENCIES RedCloth jekyll <ins> jekyll-feed jekyll-paginate minima </ins> rdiscount BUNDLED WITH <del> 1.10.6 </del> <ins> 1.14.4 </ins>
Code change:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that

Related discussion:
text: <del> { stdenv, lib, bundlerEnv, ruby_2_2, curl }: </del> <ins> { stdenv, lib, bundlerEnv, ruby }: </ins> bundlerEnv rec { name = "jekyll-${version}"; <del> version = "3.0.1"; ruby = ruby_2_2; gemdir = ./.; </del> <ins> version = (import gemset).jekyll.version; inherit ruby; gemfile = ./Gemfile; lockfile = ./Gemfile.lock; gemset = ./gemset.nix; </ins> meta = with lib; { description = "Simple, blog aware, static site generator";
Code change:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that

Related discussion:
text: [ darwin.apple_sdk.frameworks.CoreServices ]; }; <ins> # disable bundle install as it can't install anything in addition to what is # specified in pkgs/applications/misc/jekyll/Gemfile anyway. Also do chmod_R # to compensate for read-only files in site_template in nix store. jekyll = attrs: { postInstall = '' installPath=$(cat $out/nix-support/gem-meta/install-path) sed -i $installPath/lib/jekyll/commands/new.rb  -e 's@Exec.run("bundle", "install"@Exec.run("true"@'  -e 's@FileUtils.cp_r site_template + "/.", path@FileUtils.cp_r site_template + "/.", path; FileUtils.chmod_R "u+w", path@' ''; }; </ins> # note that you need version >= v3.16.14.8, # otherwise the gem will fail to link to the libv8 binary. # see: https://github.com/cowboyd/libv8/pull/161
Code change:
Package name: tracker-miners Latest released version: 3.5.1 Current version on the unstable channel: 3.5.0 <p</p- The package update itself is trivial, but I got stuck at addressing . There is now a ioctl check that runs: The program seems to build fine, but does not exit with 0: This makes the Btrfs subvolume feature disabled: I am not sure where to get start to enable this since in they decide this will be a hard check on next major bump (well, it should be possible to opt-out but it should be possible I guess). :seeno_evil: Note for maintainers: Please tag this issue in your PR.
I am getting , even though I do not use BTRFS so I assume this depends on the kernel version of the builder? (I am using .) That does not really sound like a good idea since users can use completely different kernel version than Hydra. Maybe it should be an and the check performed only when it is . Though I am not sure what the consequences are when incorrectly configured is used. Maybe it will need to be a runtime check instead?
I saved the program as a separate and compiled & ran with as root user and it exits with 1 for me as well. says I am on 6.3.0. I use btrfs so as root runs fine for me (if that matters). Hmmm then this is weird since it sounds like is introduced (is this the correct place to check such info?). But later I found in the BTRFS subvolumes feature is disabled as well :thinking: Edit: Looks like the fedora link is broken,
Apparently, it falls back to success since I do not use BTRFS: (both inside and outside the sandbox) <details<summaryModified <codetest.c</code</summary</detailsSo that does not really sound like a good test. Edit: I .
Hmmm now I wonder if their original idea is to check whether the code , probably knowing is there is already enough? (I assume they are not supporting < 2.6.34 kernels then I expect all linux should have it?) It looks like they already has some .
Could you try running the modified in build sandbox to find out why specifically it fails for you?
This is using and putting in : This is not in builder sandbox and run as root:
The fix is now merged upstream:

Related discussion:
text: { stdenv , lib , fetchurl <ins> , fetchpatch </ins> , asciidoc , docbook-xsl-nons , docbook_xml_dtd_45
Code change:
Package name: tracker-miners Latest released version: 3.5.1 Current version on the unstable channel: 3.5.0 <p</p- The package update itself is trivial, but I got stuck at addressing . There is now a ioctl check that runs: The program seems to build fine, but does not exit with 0: This makes the Btrfs subvolume feature disabled: I am not sure where to get start to enable this since in they decide this will be a hard check on next major bump (well, it should be possible to opt-out but it should be possible I guess). :seeno_evil: Note for maintainers: Please tag this issue in your PR.
I am getting , even though I do not use BTRFS so I assume this depends on the kernel version of the builder? (I am using .) That does not really sound like a good idea since users can use completely different kernel version than Hydra. Maybe it should be an and the check performed only when it is . Though I am not sure what the consequences are when incorrectly configured is used. Maybe it will need to be a runtime check instead?
I saved the program as a separate and compiled & ran with as root user and it exits with 1 for me as well. says I am on 6.3.0. I use btrfs so as root runs fine for me (if that matters). Hmmm then this is weird since it sounds like is introduced (is this the correct place to check such info?). But later I found in the BTRFS subvolumes feature is disabled as well :thinking: Edit: Looks like the fedora link is broken,
Apparently, it falls back to success since I do not use BTRFS: (both inside and outside the sandbox) <details<summaryModified <codetest.c</code</summary</detailsSo that does not really sound like a good test. Edit: I .
Hmmm now I wonder if their original idea is to check whether the code , probably knowing is there is already enough? (I assume they are not supporting < 2.6.34 kernels then I expect all linux should have it?) It looks like they already has some .
Could you try running the modified in build sandbox to find out why specifically it fails for you?
This is using and putting in : This is not in builder sandbox and run as root:
The fix is now merged upstream:

Related discussion:
text: stdenv.mkDerivation rec { pname = "tracker-miners"; <del> version = "3.5.0"; </del> <ins> version = "3.5.2"; </ins> src = fetchurl { url = "mirror://gnome/sources/${pname}/${lib.versions.majorMinor version}/${pname}-${version}.tar.xz"; <del> sha256 = "F5ZmA9xDKphSa0kFhqSKzX+fWZNfeJXfxRcppGppAaM="; </del> <ins> sha256 = "QPuR+svZRo4m6+zHEdg2Mc2K6TkcYV1o27A8vKsbbGk="; </ins> }; <ins> patches = [ # Use cc.has_header_symbol to check for BTRFS_IOC_INO_LOOKUP # https://github.com/NixOS/nixpkgs/issues/228639 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/c08fbe0650d4a2ae915a21764f54c02eda9406d5.patch"; sha256 = "U81+yfg2sUkKl4tKMeB7pXJRNSeIE+2loT3/bvnhoKM="; }) ]; </ins> nativeBuildInputs = [ asciidoc docbook-xsl-nons
Code change:
Given you have PHP installed on your host and one installed in your Nix shell + symfony-cli, eg. with these packages , running will always prefer PHP installed by host. This is not an issue with Nix per se but symfony-cli, but I suggest here that symfony-cli package should be patched so that this does not happen. Steps to reproduce the behavior: Terminal 1 terminal 2 Curl statement should return PHP/8.2.5, as that's the one installed by Nix. Not 8.1.2. Current workaround is replacing symfony-cli with which strips out everything {php}/bin Please run and paste the result.
That does not make sense. Why does Symfony not use the correct PHP from PATH? I would expect any proper PATH respecting program to return the same thing as .
I agree after making a couple of tests, I believe that wrapping the binary with the PHP path is not necessary... Check the screenshot in
I don't know, but this is what they use for discovery of php versions I've not dig depeer than having a brief looks though. And I have to remind that this is about command. command does look to be honoring $PATH correctly.
Does this means that does not employ the same mechanism for locating in the and commands? which seems totally uncommon. It would be nice to have the confirmation from one of the maintainers ( ?)
I've prepared a patch at I hope they will merge it soon. Otherwise we should consider adding a patch for this here.
I think this issue can be closed now.
Yup, thanks again!
After thinking twice, the issue will be definitely fixed as soon as you publish a new tag and we provide an update in Nix, I'll leave it open in the meantime.
7 has been released now.
PR is made, I'll wait for the CI to be done before merging and closing this issue.

Related discussion:
text: buildGoModule rec { pname = "symfony-cli"; <del> version = "5.5.6"; vendorHash = "sha256-AfgDsd4W8wV0GeymD9SLeHtOeFP9qbFy+GTdMxQSkDA="; </del> <ins> version = "5.5.7"; vendorHash = "sha256-OXV/hTSHJvYfe2SiFamkedC01J/DOgd8I60yIpQToos="; </ins> src = fetchFromGitHub { owner = "symfony-cli"; repo = "symfony-cli"; rev = "v${version}"; <del> sha256 = "sha256-lE8RBjBXucL0DJjEnBLbHqOVE6g358rwmaEUqU6QhOw="; </del> <ins> hash = "sha256-LC6QQIVHllBRu8B6XfV8SuTB3O+FmqYr+LQnVmLj2nU="; </ins> }; ldflags = [
Code change:
Given you have PHP installed on your host and one installed in your Nix shell + symfony-cli, eg. with these packages , running will always prefer PHP installed by host. This is not an issue with Nix per se but symfony-cli, but I suggest here that symfony-cli package should be patched so that this does not happen. Steps to reproduce the behavior: Terminal 1 terminal 2 Curl statement should return PHP/8.2.5, as that's the one installed by Nix. Not 8.1.2. Current workaround is replacing symfony-cli with which strips out everything {php}/bin Please run and paste the result.
That does not make sense. Why does Symfony not use the correct PHP from PATH? I would expect any proper PATH respecting program to return the same thing as .
I agree after making a couple of tests, I believe that wrapping the binary with the PHP path is not necessary... Check the screenshot in
I don't know, but this is what they use for discovery of php versions I've not dig depeer than having a brief looks though. And I have to remind that this is about command. command does look to be honoring $PATH correctly.
Does this means that does not employ the same mechanism for locating in the and commands? which seems totally uncommon. It would be nice to have the confirmation from one of the maintainers ( ?)
I've prepared a patch at I hope they will merge it soon. Otherwise we should consider adding a patch for this here.
I think this issue can be closed now.
Yup, thanks again!
After thinking twice, the issue will be definitely fixed as soon as you publish a new tag and we provide an update in Nix, I'll leave it open in the meantime.
7 has been released now.
PR is made, I'll wait for the CI to be done before merging and closing this issue.

Related discussion:
text: $GOPATH/bin/symfony-cli ''; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Symfony CLI"; homepage = "https://github.com/symfony-cli/symfony-cli"; <del> license = licenses.agpl3Plus; maintainers = with maintainers; [ drupol ]; </del> <ins> license = lib.licenses.agpl3Plus; </ins> mainProgram = "symfony"; <ins> maintainers = with lib.maintainers; [ drupol ]; </ins> }; }
Code change:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, git, makeWrapper, openssl, coreutils, util-linux, gnugrep, gnused, gawk }: </del> <ins> { lib, stdenv, fetchFromGitHub, git, makeWrapper, openssl, coreutils, util-linux, gnugrep, gnused, gawk, testers, transcrypt }: </ins> stdenv.mkDerivation rec { pname = "transcrypt"; <del> version = "1.1.0"; </del> <ins> version = "2.2.3"; </ins> src = fetchFromGitHub { owner = "elasticdog"; repo = "transcrypt"; rev = "v${version}"; <del> sha256 = "1dkr69plk16wllk5bzlkchrzw63pk239dgbjhrb3mb61i065jdam"; </del> <ins> sha256 = "+B8CYHDneDd0GwiTwQK6YVScDMKao2JXFpGk9PY6/EE="; </ins> }; nativeBuildInputs = [ makeWrapper ]; buildInputs = [ git openssl coreutils util-linux gnugrep gnused gawk ]; <del> patches = [ ./helper-scripts_depspathprefix.patch ]; </del> installPhase = '' install -m 755 -D transcrypt $out/bin/transcrypt install -m 644 -D man/transcrypt.1 $out/share/man/man1/transcrypt.1
Code change:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.

Related discussion:
text: chmod +x $out/bin/transcrypt-depspathprefix ''; <ins> passthru.tests.version = testers.testVersion { package = transcrypt; command = "transcrypt --version"; version = "transcrypt ${version}"; }; </ins> meta = with lib; { description = "Transparently encrypt files within a Git repository"; longDescription = ''