jiebi/CodeConvo huggingface dataset:
Change:
<del> [ { "body-parser": "~1.6.3" } , { "express": "~4.8.3" } , { "request": "~2.34.0" } , { "tar": "~0.1.19" } , { "ws": "~0.4.32" } ] </del>

Discussion:
zed uses the binary release of (at this time still called ), while the newest version is . As this is basically a Chromium binary that can execute arbitrary Javascript and deliberately breaks all sandboxing features, we should at least keep it on a current version. cc I’m pushing an update of to 0.26 at the moment, but the package can’t handle it, so I’m pinning to for the time being.
Hi Thanks a lot for working on this. It's been a while ago since I worked on this part of , but I slightly remember that I had to deal with several outdated versions when dealing with . I'll definitely have a look into this in the next days, hopefully there's a patch by some contributors (or it's easy to file one to fix this). However the project isn't too active, so at least when we suffer from more further breaks or security issues because of severely outdated dependencies, we shouldn't hesitate to mark this package as broken or even drop it entirely (unless there are folks heavily relying on this).
I’d be in favor of a drop; people will complain if they still use it, if that happens we can restore & update, or the package is pulled outside of nixpkgs until someone can push and maintain a recent update.
In fact I agree with you, I've observed this "restore & update" pattern with some bigger applications (especially web-services) and I think that this is unneeded extra-work for the nixpkgs maintainers and release managers before each release. Before I file a patch to either {drop it,mark it as broken} or fix the dependency issue, I'd like to check two things before: is there any active fork? I'd like to ensure that the project is actually dead/unresponsive or does it have a working/maintained fork? check in the IRC if there are active users (I don't use it, I just fixed the derivation to help to get rid of ). If there are any, we should ask them to take over maintenance (or ask them to create their own overlay) I'll try to have a deeper look into it tonight, when I know more and have an actual opinion on how to proceed, I'll leave a comment here.

As far as I know, the author is no longer actively developing Zed anymore: I happen to know him personally, but as far as I know he has no interests in doing any major additional developments any time soon. Of course, I can always ask but I think I already know the answer. :) For me it's fine if it gets removed.
ok I suspected something like this as the last commit was from 2015. In this case I'm also :+1: for dropping it...
just submitted a PR for now, I asked in the IRC if there are any folks using , if I don't get a response, I'd just vote for merging it to master and do a backport to 18.03
Change:
# Remove some broken manpages. rm -rf $out/man/ja* <ins> # Remove embedded freetype to avoid problems like # https://github.com/NixOS/nixpkgs/issues/57733 rm $out/lib/libfreetype.so </ins> # for backward compatibility ln -s $out $out/jre

Discussion:
kodiPlain.aarch64-linux is failing to build on master and release-18.09. This is a problem because new users trying NixOS on their Raspberry Pis won't be able to install Kodi.
was the first failing build on release-18.09. The changes since the last successful build are all JDK/JRE related: suggests a problem with Freetype: build/video/video.a() CTeletextDecoder::EndDecoder(): error: undefined reference to 'FTCManagerDone' build/video/video.a() CTeletextDecoder::RenderCharIntern(TextRenderInfot, int, TextPageAttrt, int, int): error: undefined reference to 'FTCSBitCacheLookup' and I see that from that log file that cmake has managed to grab freetype from the JRE (unexpected!): -- Found FreeType: /nix/store/3vslpb5ksghr02vb58vvpv2c3hv1ig32-adoptopenjdk-jre-hotspot-bin- (found version "22.0.16") Compare that to , in which cmake found freetype from freetype (as expected): -- Found FreeType: /nix/store/p14jcjs9ij0jfd9pgyq7gxpdl8k1kgj1-freetype- (found version "22.0.16")
OpenJDK 11.0.1 did not contain libfreetype, but OpenJDK 11.0.2 does contain libfreetype: i; tar tf $i | grep -i freetype; done OpenJDK11U- OpenJDK11U- jdk-11.0.2+7- jdk-11.0.2+7- OpenJDK11U- jdk-11.0.2+9- jdk-11.0.2+9- ... so of the two aforementioned changes ( ), the upgrade to 11.0.2 likely triggered this: commit .
has been merged to master, and now kodiPlain.aarch64-linux is building ( ). Woo! Let's get this in 18.09 and 19.03
With and being merged, this can be closed :-)
Change:
--param man.output.in.separate.dir 1  --param man.output.base.dir "'$out/share/man/'"  --param man.endnotes.are.numbered 0  <ins> --param man.break.after.slash 1  </ins> ${docbook5_xsl}/xml/xsl/docbook/manpages/docbook.xsl  ./man-pages.xml '';

Discussion:
With a 90-column terminal (half my screen width), "man " fills the screen with stderr warnings, that break completely the 'less' painting of the terminal. Lines are like this: <standard input:: warning [p 2, 163.7i]: can't break line I think it's related to the very long strings of nix file names. In MySQL they got this problem, and they managed to use some docbook tags that improved that: They say: "After further investigation, I think the source of the problem is that <entryis subject to "pernicious mixed content." By wrapping the affected cell within <paratags, better word wrapping occurs and improves the man page output."
Can you provide some more details to reproduce? I can't reproduce this either in a Konsole nor in a TTY - I'm on nixos-unstable, though!
Closing to keep the number of open issues down. You're welcome to re-open with a reproducible case obviously !
On 15.09, xterm on 81 columns, I see full of that. No idea of master.
tv on irc reports to use this, to avoid the noise: It works fine for me, too. Maybe it could go upstream? Time to open the issue?
I can reproduce the warnings like this: The adds to man's nroff command line, which mutes that warning. I'm not sure muting warnings should be the default for NixOS (or nixpkgs's man) because the cause still exists (i.e. lines couldn't be wrapped). Instead, maybe the manpage generation can be tuned.
I can definitely reproduce the error, too. No matter on which version and since a long time. I also investigated rather deeply on how to fix this problem starting from the MySQL Bug linked above. However, I was not able to find a solution that worked. But I don't have much experience in this area so that doesn't mean much. Maybe I can give it an other try at the weekend.
Hmm, it's the Declared by path names that seem to be unbreakable, judging from formatting with a thin terminal and viewing then in a wider one (without re-formatting).
Apparently it's just because slashes aren't considered as possible places to break a line. I've got no idea whether/how that can be changed.
Change:
mainProgram = "fastapi"; license = licenses.mit; maintainers = [ ]; <ins> # This package provides a `fastapi`-executable that is in conflict with the one from # python3Packages.fastapi. Because this package is primarily used for the purpose of # implementing the CLI for python3Packages.fastapi, we reduce the executable's priority priority = 10; </ins> }; }; in self

Discussion:
Not too long ago was updated to have as its dependency. However both python packages have a , so the created from can't successfully build. Steps to reproduce the behavior: to build error: Not exactly sure what should be done, since I'm not familiar with the cli tools. As a workaround you can probably do (listed in meta.maintainers) (author of the that the dependency) <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
runHook postInstall ''; <ins> preFixup = '' mkdir -p $out/bin makeWrapper ${jreWithJavaFX}/bin/java $out/bin/ns-usbloader  --append-flags "-Dprism.order=sw -jar $out/share/java/ns-usbloader.jar"  "''${gappsWrapperArgs[@]}" ''; </ins> desktopItems = [ (makeDesktopItem { type = "Application";

Discussion:
when i click on any button that would open a file picker the program crashes with these errors Steps to reproduce the behavior: to your system configuration and rebuild on "select files" a file picker should open N/A I am using a the session <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Which desktop environment/window manager are you running? Also please attempt running ns-usbloader without root. I shouldn't require it and may be why it's crashing.
I think I know what's wrong, and it's likely package related. I will have a look at this later today.
i'm using plasma-wayland , i forgot to mention it initially but edited the issue later. and i tried both with and without root.
Just want to clarify: I’m getting . Is this the same error or different?
That looks correct, yes. You can try and see if the PR above fixes it.
Change:
psycopg2 pymysql pytestCheckHook <del> ] ++ passthru.optional-dependencies.flask ++ passthru.optional-dependencies.flask-login ++ passthru.optional-dependencies.flask-sqlalchemy ++ passthru.optional-dependencies.flexmock ++ passthru.optional-dependencies.i18n; </del> <ins> ] ++ lib.flatten (builtins.attrValues passthru.optional-dependencies); </ins> <del> # indicate tests that we don't have a database server at hand </del> <ins> # Indicate tests that we don't have a database server at hand </ins> DB = "sqlite"; <ins> disabledTestPaths = [ # Test doesn't support latest SQLAlchemy "tests/plugins/test_flask.py" ]; </ins> pythonImportsCheck = [ "sqlalchemy_continuum" ];

Discussion:
This also breaks the build of which relies on this package. () Please run and paste the result.
Are you using ihatemoney on unstable? I was considering dropping it as very often breaks with the new versions of its dependencies.
I wouldn't mind using ihatemoney from stable, but I'm using unstable by default on my system, and didn't manage to create a working overlay for overriding ihatemoney's version (a python-specific overlay is required, and then IIRC I got an error because ihatemoney is not a python module).
tbh I'm only maintaining it on stable. Overlaying all dependencies to make it work is time consuming so I'm only doing just before a release. If you want to have a try, here is how it can look like:
Change:
inherit src; name = "python${pythonVersion}-${version}-doc"; <ins> patches = optionals (pythonAtLeast "3.9" && pythonOlder "3.10") [ # https://github.com/python/cpython/issues/98366 (fetchpatch { url = "https://github.com/python/cpython/commit/5612471501b05518287ed61c1abcb9ed38c03942.patch"; hash = "sha256-p41hJwAiyRgyVjCVQokMSpSFg/VDDrqkCSxsodVb6vY="; }) ]; </ins> dontConfigure = true; dontBuild = true;

Discussion:
python39 can't be installed Steps to reproduce the behavior: vim python39 to system packages section environment.systemPackages = with pkgs; [ python39 ]; nixos-rebuild switch after executing command Please run and paste the result.
Could you check ?
Reproduces for , does not reproduce for . Given this info and the error itself, I think this will be fixed by backporting python/cpython. I can test this hypothesis and write up a PR in the next few hours.
Change:
# gcc: error: memdbg.o: No such file or directory enableParallelBuilding = false; <del> NIX_CFLAGS_COMPILE = [ "-DJOHN_SYSTEMWIDE=1" ]; </del> postInstall = '' mkdir -p "$out/bin" "$out/etc/john" "$out/share/john" "$out/share/doc/john" "$out/share/john/rules" find -L ../run -mindepth 1 -maxdepth 1 -type f -executable 

Discussion:
Describe the bug I installed john the ripper from the binary cache, and executing it fails with: I have a recent laptop (Thinkpad T480s) with i7-8550U CPUs, but apparently that's not good enough. It would be good to compile john with less demanding requirements for the benefit of most users, and maybe output a message how to compile it yourself on nix systems.
Yeah it looks like one of the builders has this feature so the configure script requires it: It looks like we need to pass the flag.
cc maintainer
backported to 19.09 in .
Change:
--set-interpreter "''$(cat $NIX_CC/nix-support/dynamic-linker)" $i fi if [[ $i =~ libcudart ]]; then <del> rpath2= </del> <ins> patchelf --remove-rpath $i </ins> else rpath2=$rpath:$lib/lib:$out/jre/lib/amd64/jli:$out/lib:$out/lib64:$out/nvvm/lib:$out/nvvm/lib64 <ins> patchelf --set-rpath "$rpath2" --force-rpath $i </ins> fi <del> patchelf --set-rpath "$rpath2" --force-rpath $i </del> done < <(find $out $lib $doc -type f -print0) '';

Discussion:
Cudatoolkit is not working. This is the last lines log: Steps to reproduce the behavior: Cudatoolkit to your systempackages to new version Cudatoolkit build If applicable, add screenshots to help explain your problem. It seems to this is a error in . I think this already merged PR in fix this problem <!-- 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. Maintainer information:
Hey, thanks for pointing this out. You're right that this has already been fixed in patchelf, but it will be a while before the next patchelf release is cut and merged via staging-next. Until then, I think it's worthwhile to work around this - please take a look at and let me know if that fixes your issue.
Cudatoolkit is building. Thanks!
Change:
stegsolve = callPackage ../tools/graphics/stegsolve { }; <del> StormLib = callPackage ../development/libraries/StormLib { }; </del> stxxl = callPackage ../development/libraries/stxxl { }; sv-lang = callPackage ../applications/science/electronics/sv-lang { };

Discussion:
At Darwin: build .#StormLib Log files: aarch64-darwin: x86_64-darwin:
Change:
if path == rootPath || evaluatedPathContent.recurseForDerivations or false || evaluatedPathContent.recurseForRelease or false then dedupResults (lib.mapAttrsToList (name: elem: packagesWithPathInner (path ++ [name]) elem) evaluatedPathContent) else [] <del> else if lib.isList evaluatedPathContent then dedupResults (lib.imap0 (i: elem: packagesWithPathInner (path ++ [i]) elem) evaluatedPathContent) </del> else [] else []; in

Discussion:
Describe the bug Automatically updating fails with the error message shown below. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue seems to be with the attributes , and , which are defined as lists of packages. If they are commented out the update command works. cc for comment.
Weird, I though I have removed support for lists, since they are incompatible with passing attribute path to the update scripts through . Must have gotten lost during rebase. should fix that.
Change:
in stdenv.mkDerivation rec { pname   = "keycloak"; <del> version = "12.0.4"; </del> <ins> version = "13.0.0"; </ins> src = fetchzip { url    = "https://github.com/keycloak/keycloak/releases/download/${version}/keycloak-${version}.zip"; <del> sha256 = "sha256-7DKKpuKPoSKIpfvhCvLzuyepbmixgq0+o+83FKi6Dwc="; </del> <ins> sha256 = "sha256-jpjAPldmJkyXGsokw9MO1u0VysYBXeQ8MamEPWvBGvs="; </ins> }; nativeBuildInputs = [ makeWrapper ];

Discussion:
, CVSSv3=6.5 (nixos-20.09, nixos-unstable) CVSSv3=5.4 (nixos-20.09, nixos-unstable) CVSSv3=5.3 (nixos-20.09, nixos-unstable) CVSSv3=4.9 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc

, CVSSv3=5.4 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) CVSSv3=4.9 (nixos-unstable) Scanned versions: nixos-unstable: . Cc Cc
Fixed in the upcoming release.

, CVSSv3=5.4 (nixos-20.09) Scanned versions: nixos-20.09: . Cc
See also: ,
Fixed in the upcoming release.

, CVSSv3=5.3 (nixos-20.09, nixos-unstable) CVSSv3=4.9 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
See also:
Fixed in the upcoming release.
Change:
++ optionals (versionOlder config.boot.kernelPackages.kernel.version "4.13") [ rtl8723bs-firmware ]; <ins> hardware.wirelessRegulatoryDatabase = true; </ins> }) (mkIf cfg.enableAllFirmware { assertions = [{

Discussion:
Newer kernels (4.15+) can look for wireless regulatory info from (for us this is I think?), replacing the need for user-space helper like . (at least in the common case, I believe) <-- latest CRDA git adds note about this Not the same as the regdb, although I'm not sure the difference is as important for NiXOS'ers compared to other distributions. Info on internal:
I don't want to hijack the thread but my problem may be related. Recently, not sure why, I can't connect to an AP I previously could connect to so I suspect it's my machne (my phone can still access it), thus I've been looking at wifi information. I used to have a plain error then I while now it at least attempt to connect: so I wonder if it's expected on nixos ? NB: it's annoying all these errors when building kernels. do others have it too (I should probably look at hydras rather...
To get the file loaded, you need to add to . ` to see the files. Then you should see the following in : I haven't quite figured out what the best way to set the correct regulatory domain is however... short of just using .
oh great thanks ! that was not obvious. I was looking for a setting to set on boot as a kernel parameter but haven't found it yet. Some interesting read suggests one can embed the kernel in the db as well ?!
Something like this should work: Admittedly not ideal since it only works at module load time though.
Thanks Setting the following gives me the correct wifi config (check with ): Looking through the documents on: It seems to be a bit of a mess.... is an 'old' option, but NetworkManager has no support for setting the reg domain. I think having a module (?) might be a very good idea, and such an option should be to. ArchLinux deals with it by using a custom rule to run when is loaded ([source][al]). [al]: Another idea would be to a option, though that doesn't fix NetworkManager.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me".

This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This should not be stale I think. Should NixOS just add to as default?
cc
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
libappindicator-gtk3 libdbusmenu wayland <del> ]; </del> <ins> ] ++ lib.optional withTTS speechd); </ins> installPhase = '' runHook preInstall

Discussion:
Text-to-speech functionality is not working, according to the this functionality is disabled by default on Linux. I have tried doing what was suggested over there but it didn't work, I assume this has to do with how it is packaged over in Nix. What I tried was entering and then running . Doing worked which confirmed that the dispatcher was working, however, starting discord via terminal with the flag did not fix it for discord.
The same is true of the package which also includes speechd but will not be guaranteed to work, depending on environment (such as the display server you use)
Change:
fluidsynth wayland wayland-protocols ] ++ optional (!stdenv.hostPlatform.isAarch64) live555 ++ optionals withQt5    [ qtbase qtsvg qtx11extras ] <del> ++ optional jackSupport libjack2; </del> <ins> ++ optional jackSupport libjack2 ++ optionals chromecastSupport [ protobuf libmicrodns ]; </ins> nativeBuildInputs = [ autoreconfHook perl pkgconfig removeReferencesTo ];

Discussion:
The current vlc derivation does not include chromecast support. I believe we need to add the flags during the configuration step to enable it by default, which I think is a reasonable thing to do. I tried to do the minimal change myself, but looks like we need some new dependencies that don't exist in nixpkg yet: I'm still fairly new so it will take some learning to figure out what needs to be done to package protobuf-lite (not sure I'll get around to it anytime soon). If anyone else is into making these changes, it would be much appreciated. Or please let me know if I'm off-track here and there's a better way to do this.
You're on the right track. This should work:
Ah, now it builds, and I can see the relevant chromecast features, but it's still not finding the chromecast. Thank you! Sounds like that happens when microdns is not available. I tried adding nssmdns to the derivation but that didn't do the trick. is enabled. Hmmmm.
FWIW (mostly because I like linking things together), but sounds like you're past what is useful from that :). I frequently find chromecast programs on NixOS don't work... especially scanning support... with the firewall enabled. . Should only need mdns support for discovery/scanning, I think :).
Yea I did see that. I don't think it's the firewall, as google-chrome chromecasts fine. Even VLC via flatpak manages to connect to the chromecast (but fails to encode due to some other error). I believe mdns is used to find the chromecast automagically.
Make sure avahi is running and that mdns is set in resolvconf
Avahi is running and nssmdns is enabled, if that's what you mean. Is it working for you? Reading an older VLC PR: Sounds like we need VLC's own libmicrodns packaged before this will work: Edit: Indeed building with :
I managed to package up libmicrodns and it's working now! I'll clean up and send a PR. :) Thanks for the help everyone.
Change:
ruby_3_1 ruby_3_2; <del> ruby = ruby_2_7; rubyPackages = rubyPackages_2_7; </del> <ins> ruby = ruby_3_1; rubyPackages = rubyPackages_3_1; </ins> rubyPackages_2_7 = recurseIntoAttrs ruby_2_7.gems; rubyPackages_3_0 = recurseIntoAttrs ruby_3_0.gems;

Discussion:
So we'll have an EOL for a few months on 22.11, which isn't ideal, but we really shouldn't go into 23.05 like that. Also, does not support , which is why I noticed this when looking into stuff for
Ruby 2.7 support status ended yesterday.
The default is with the merge of :partyingface: Thanks for taking care of this Now… do we want to mark as EOL e.g. through ?
Change:
postPatch = '' <ins> # cython was pinned to fix windows build hangs (pygame-community/pygame-ce/pull/3015) </ins> substituteInPlace pyproject.toml  <ins> --replace-fail '"cython<=3.0.10",' '"cython",'  </ins> --replace-fail '"meson<=1.5.0",' '"meson",'  --replace-fail '"sphinx<=7.2.6",' ""  --replace-fail '"ninja<=1.11.1.1",' ""

Discussion:
Found while reworking SDL2 here: (according to meta.maintainers) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
pdfstudio = callPackage ./common.nix rec { pname = program; year = "2021"; <del> version = "${year}.1.3"; </del> <ins> version = "${year}.2.0"; </ins> desktopName = "PDF Studio"; longDescription = '' PDF Studio is an easy to use, full-featured PDF editing software. This is the standard/pro edition, which requires a license. For the free PDF Studio Viewer see the package pdfstudioviewer.

Discussion:
(shown here with command syntax) Trying that same URL in a browser does indeed get a 404. I guess Qoppa changed how their files or named (or worse, removed them).
Qoppa must have removed the download link for version 2021.1.3. PR upgrades to the latest 2021 version, which fixes the issue.