jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { bash, fetchFromGitHub, lib, nodejs, pnpm_9, stdenvNoCC, }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "stylelint-lsp"; version = "2.0.0"; src = fetchFromGitHub { owner = "bmatcuk"; repo = "stylelint-lsp"; rev = "v${finalAttrs.version}"; hash = "sha256-mzhY6MKkXb1jFYZvs/VkGipBjBfUY3GukICb9qVQI80="; }; nativeBuildInputs = [ nodejs pnpm_9.configHook ]; pnpmDeps = pnpm_9.fetchDeps { inherit (finalAttrs) pname version src; hash = "sha256-/QJ4buPOt5KFJxwsQp7L9WYE1RtODj4LMq21l99QwhA="; }; buildPhase = '' runHook preBuild pnpm build runHook postBuild ''; installPhase = '' runHook preInstall mkdir -p $out/{bin,lib/${finalAttrs.pname}} mv {dist,node_modules} $out/lib/${finalAttrs.pname} echo " #!${lib.getExe bash} ${lib.getExe nodejs} $out/lib/${finalAttrs.pname}/dist/index.js $@ " > $out/bin/stylelint-lsp chmod +x $out/bin/stylelint-lsp runHook postInstall ''; meta = with lib; { description = "A stylelint Language Server"; homepage = "https://github.com/bmatcuk/stylelint-lsp"; license = licenses.mit; maintainers = with maintainers; [ gepbird ]; mainProgram = "stylelint-lsp"; platforms = platforms.unix; }; }) </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --An implementation of the Language Server Protocol for . Metadata homepage URL: source URL: license: mit platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: It has a pnpm lockfile for which we for yet, this package request should wait.
Code change:
cp -r ann $out/${python.sitePackages}/ makeWrapper ${lib.getExe python.pkgs.gunicorn} "''${!outputBin}"/bin/machine-learning  <del> --prefix PYTHONPATH : "$out/${python.sitePackages}:$PYTHONPATH"  </del> <ins> --prefix PYTHONPATH : "$out/${python.sitePackages}:${python.pkgs.makePythonPath dependencies}"  </ins> --set-default MACHINE_LEARNING_WORKERS 1  --set-default MACHINE_LEARNING_WORKER_TIMEOUT 120  --set-default MACHINE_LEARNING_CACHE_FOLDER /var/cache/immich 

Related discussion:
text: Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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]:
After bisecting, first bad commit is (
Code change:
systemd.timers.zfs-scrub = { wantedBy = [ "timers.target" ]; <ins> after = [ "multi-user.target" ]; # Apparently scrubbing before boot is complete hangs the system? #53583 </ins> timerConfig = { OnCalendar = cfgScrub.interval; Persistent = "yes";

Related discussion:
text: System hangs during boot when the timer configured via fires during the boot sequence. option. option such that the timer will be due to run immediately upon the next reboot of the system. ; allow sufficient amount of time to pass. Boot the system, observe the system to hang during the boot sequence. system: host os: multi-user?: sandbox: version: channels(pbogdan): nixpkgs:
Does setting help?
but otherwise yes, it does help, thank you.
Hi, I reproduced this on 19.03 yesterday. The unit already contained , so it seems it is not sufficient to fix this. Some data about my system:
Code change:
rustPlatform.buildRustPackage rec { pname = "nsncd"; <del> version = "unstable-2022-11-14"; </del> <ins> version = "unstable-2023-10-26"; # https://github.com/twosigma/nsncd/pull/71 has not been upstreamed # to twosigma/nsncd yet. Using the nix-community fork in the # meantime. </ins> src = fetchFromGitHub { owner = "nix-community"; repo = "nsncd"; <del> rev = "47e580f1db99603df6e212a2e62f18cc970cef40"; hash = "sha256-Nv3MYZcuYgD66BAGs3Tg37s086HAGsaDBFvELqQF3Tk="; </del> <ins> rev =  "d6513421f420e407248c6d0aee39ae2f861a7cec"; hash = "sha256-PykzwpPxMDHJOr2HubXuw+Krk9Jbi0E3M2lEAOXhx2M="; </ins> }; <del> cargoSha256 = "sha256-c1L6nEUBHw1YegmoRrI3WU/bF80Nzbz13hsGlNyBR9o="; </del> <ins> cargoSha256 = "sha256-cUM7rYXWpJ0aMiurXBp15IlxAmf/x5uiodxEqBPCQT0="; </ins> meta = with lib; { description = "the name service non-caching daemon";

Related discussion:
text: only returns the hostname, even when both and are set. Steps to reproduce the behavior: and . . should return the FQDN defined by and . The breakage happens when is used, which is now the default in NixOS after Stopping causes to return the correct value. reproduces the issue. It broke at , which is when became enabled by default. It's still broken on which is at time of writing. Possibly related issues:
This seems to happen because the resolution flow (when nscd is running) looks like: calls , which uses the nodename (), which is the short hostname then calls , which invokes the nss machinery gets the request and processes the request according to the NSS rules; on my NixOS system this is (from systemd) doesn't match (from systemd) does match, and returns a synthesized record; systemd internally determines the hostname for this using only the nodename, so unless the nodename is already the FQDN then we fail here, and it does this before checking /etc/hosts. I wonder if we can fix this by patching out the support in systemd-resolved for looking up the nodename, which will make it fall back to the result from /etc/hosts instead; on NixOS we can (probably) always assume that /etc/hosts will actually have the correct system hostname in it.
No, this is most likely We wanted to polish that PR in the next days, and once merged, bump our nixpkgs pin (and resurrect the upstreaming attempts). If you want, can you check if using nsncd from this PR fixes the problem for you?
Ah, actually, I think I'm just talking out of my ass. systemd-resolved seems to be able to cope with this properly when I query it over DNS, so it probably isn't to blame.
tests fail at that PR. Setting gets a successful build, which then passes the test in , but it fails on the test.
This is a pretty weird behavior. What's (likely) failing here is the IPv6 resolution of . The test does pass on some NixOS setup, like my desktop (and the Ubuntu CI) but does fail on my laptop. I'm still not sure what's happening, is present in .
Code change:
rustPlatform.buildRustPackage rec { pname = "nsncd"; <del> version = "unstable-2022-11-14"; </del> <ins> version = "unstable-2023-10-26"; # https://github.com/twosigma/nsncd/pull/71 has not been upstreamed # to twosigma/nsncd yet. Using the nix-community fork in the # meantime. </ins> src = fetchFromGitHub { owner = "nix-community"; repo = "nsncd"; <del> rev = "47e580f1db99603df6e212a2e62f18cc970cef40"; hash = "sha256-Nv3MYZcuYgD66BAGs3Tg37s086HAGsaDBFvELqQF3Tk="; </del> <ins> rev =  "d6513421f420e407248c6d0aee39ae2f861a7cec"; hash = "sha256-PykzwpPxMDHJOr2HubXuw+Krk9Jbi0E3M2lEAOXhx2M="; </ins> }; <del> cargoSha256 = "sha256-c1L6nEUBHw1YegmoRrI3WU/bF80Nzbz13hsGlNyBR9o="; </del> <ins> cargoSha256 = "sha256-cUM7rYXWpJ0aMiurXBp15IlxAmf/x5uiodxEqBPCQT0="; </ins> meta = with lib; { description = "the name service non-caching daemon";

Related discussion:
text: There's something wrong with some NixOS setup, it'd be nice to fix that as well. By any chance, did you disable systemd-resolved? Thanks for the heads up wrt. . I'll have a look today.
The behavior I described is from the Nix build environment. I used the nixpkgs derivation for nsncd and updated the source to the PR.
Code change:
rustPlatform.buildRustPackage rec { pname = "nsncd"; <del> version = "unstable-2022-11-14"; </del> <ins> version = "unstable-2023-10-26"; # https://github.com/twosigma/nsncd/pull/71 has not been upstreamed # to twosigma/nsncd yet. Using the nix-community fork in the # meantime. </ins> src = fetchFromGitHub { owner = "nix-community"; repo = "nsncd"; <del> rev = "47e580f1db99603df6e212a2e62f18cc970cef40"; hash = "sha256-Nv3MYZcuYgD66BAGs3Tg37s086HAGsaDBFvELqQF3Tk="; </del> <ins> rev =  "d6513421f420e407248c6d0aee39ae2f861a7cec"; hash = "sha256-PykzwpPxMDHJOr2HubXuw+Krk9Jbi0E3M2lEAOXhx2M="; </ins> }; <del> cargoSha256 = "sha256-c1L6nEUBHw1YegmoRrI3WU/bF80Nzbz13hsGlNyBR9o="; </del> <ins> cargoSha256 = "sha256-cUM7rYXWpJ0aMiurXBp15IlxAmf/x5uiodxEqBPCQT0="; </ins> meta = with lib; { description = "the name service non-caching daemon";

Related discussion:
text: In NixOS 22.05, the domain name is not set correctly when is set to . 1) It's working with IPv6: 2) .. but broken without: Obviously, it should work in both cases. The issue seems to be related to : also fixes the problem. Similar issues seem to have been discussed in , and , but it's still broken. Please run and paste the result.
I also seem to have hit this, but do not run , but a customized . I have however not tested removing , as my servers rely on the configuration section to run. Have a feeling it may be a fragile section when changes in happens. Also stopping solves it as well. Running nixos unstable.
I can reproduce this on nixos-unstable (without disabling IPv6), but also managed to get it working when stopping nscd. I found while googling around. And while points out a possible solution[^1], I did not find this to be working for me. [^1]: Effectively translating to
I've also encountered this issue, with the same reproduction and issues as Any idea how to resolve this? I particularly need to be able to set for containers using ...
FWIW, setting to seems to resolve this issue. cc
Hmm, this doesn't make too much sense - I'd assume and should behave the same when it comes to that. They're simply calling out to the same NSS modules to do the work. We do have which tests that works. It currently seems to be failing in the testcase, when run with nsncd, and succeeds when setting to . - cc Let's figure out this regression first, and not draw too early conclusions about this being a "IPv6 is disabled issue".
So, there's definitely something wrong with the current nsncd implementation. Dumping the Nscd socket, we can see that nsncd is lacking some getai entries. Entries that are probably used by hostname to get the FQDN: Let's track and fix this issue on the Nsncd repo.
Code change:
copyq = libsForQt514.callPackage ../applications/misc/copyq { }; <ins> corectrl = libsForQt5.callPackage ../applications/misc/corectrl { }; </ins> coriander = callPackage ../applications/video/coriander { inherit (gnome2) libgnomeui GConf; };

Related discussion:
text: Project description CoreCtrl is a Free and Open Source GNU/Linux application that allows you to control with ease your computer hardware using application profiles. It aims to be flexible, comfortable and accessible to regular users. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux
It looks very complicated. I will look at AUR.
sorry for the late reply thank you very much for looking into it :relaxed:
Well, I will do what I can do. I am not a huge user and packager of such graphical things, but it looks an interesting project to take on. I will do some research.
Code change:
my $extraPerEntryConfig = get("extraPerEntryConfig"); my $extraEntries = get("extraEntries"); my $extraEntriesBeforeNixOS = get("extraEntriesBeforeNixOS") eq "true"; <del> my $extraInitrd = get("extraInitrd"); </del> <ins> my $initrdSecrets = get("initrdSecrets"); </ins> my $splashImage = get("splashImage"); my $configurationLimit = int(get("configurationLimit")); my $copyKernels = get("copyKernels") eq "true";

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
<ins> diff --git a/build.gradle b/build.gradle index c206e2f..b1fda33 100644 --- a/build.gradle +++ b/build.gradle @@ -69,19 +69,7 @@ launch4j { messagesInstanceAlreadyExists="Stirling-PDF is already running." } -spotless { -    java { -        target project.fileTree('src/main/java') -        googleJavaFormat('1.19.1').aosp().reorderImports(false) - -        importOrder('java', 'javax', 'org', 'com', 'net', 'io') -        toggleOffOn() -        trimTrailingWhitespace() -        indentWithSpaces() -        endWithNewline() -    } -} dependencies { //security updates @@ -163,9 +151,6 @@ dependencies { annotationProcessor 'org.projectlombok:lombok:1.18.28' } -tasks.withType(JavaCompile) { -    dependsOn 'spotlessApply' -} compileJava { options.compilerArgs << '-parameters' } </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.
Code change:
<ins> { lib, fetchFromGitHub, rustPlatform }: rustPlatform.buildRustPackage rec { pname = "presenterm"; version = "0.2.0"; src = fetchFromGitHub { owner = "mfontanini"; repo = "presenterm"; rev = version; hash = "sha256-mNWnUUezKIffh5gMgMMdvApNZZTxxB8XrL0jFLyBxuk="; }; cargoHash = "sha256-JLPJLhWN/yXpPIHa+FJ2aQ/GDUFKtZ7t+/8rvR8WNKM="; meta = with lib; { description = "A terminal based slideshow tool"; homepage = "https://github.com/mfontanini/presenterm"; license = licenses.bsd2; maintainers = with maintainers; [ mikaelfangel ]; mainProgram = "presenterm"; }; } </ins>

Related discussion:
text: Project description A terminal based slideshow tool. Metadata homepage URL: source URL: license: bsd 2 clause platforms: unix, linux CC:
- You can follow the status of the pr/package .
Please include presenterm-export as well, or a new presenterm-export package
Code change:
"--with-app-defaults=${placeholder "out"}/share/xscreensaver/app-defaults" ]; <del> postInstall = lib.optionalString forceInstallAllHacks '' </del> <ins> postInstall = '' for bin in $out/bin/*; do wrapProgram "$bin"  --prefix PATH : "$out/libexec/xscreensaver"  --prefix PATH : "${lib.makeBinPath [ coreutils ]}" done '' + lib.optionalString forceInstallAllHacks '' </ins> make -j$NIX_BUILD_CORES -C hacks/glx dnalogo cat hacks/Makefile.in  | grep -E '([a-z0-9]+):[[:space:]]*1[.]o' | cut -d : -f 1 | xargs make -j$NIX_BUILD_CORES -C hacks

Related discussion:
text: Since commit the command is missing. It is used by xscreensaver to display text inside the screensavers like system information and kernel versions. It used to be in the package, as can be seen from this diff: The same applies to which was also removed by that commit Steps to reproduce the behavior: Text is printed when running instead of If applicable, add screenshots to help explain your problem. Add any other context about the problem here. system: host os: multi-user?: sandbox: version: channels(root): channels(pinpox): nixpkgs: Maintainer information:
«removed» here means «same lack of special measures as before» (the lines you cite are just fixes for the installed stuff), but upstream underwent a major rewrite. (Not saying that fix is not most welcome, just that this was not a removal as much as lack of finding out what to do now) Apparently the scripts are there in the tarball, maybe they need manual copying now, not sure
I just noticed it seems to work fine in the previewer application that comes with xscreensaver . E.g.: ! The same screensaver does not work though, when it starts "on it's own" after some idle time. The text then only reads Not sure what the difference is.
xscreensaver-text and others are in $out/libexec/xscreensaver btw speeds up the build of xscreensaver by a lot
Hm, is not in my path, but hacks launched via XScreenSaver proper find text just fine. And the daemon source code implies that is indeed to PATH in a normal situation.
Not sure if it's related, but it is also missing commands like and (output is shown in some of the screensavers). I have enabled xsceensaver with the home-manager option
Code change:
hash = "sha256-i3zml6LyEnUqNcGsQURx3BbEJMlXO+SSa1b/P10jt68="; }; })) <ins> sdkmanager </ins> yamllint ];

Related discussion:
text: Steps to reproduce the behavior: build .#fdroidserver Git bisect predictably found the culprit as , so it is related to the Python 3.12 upgrade. I suspect that all setuptools-based modules are broken; e.g. also stops building. Interestingly, built before, but not after. Not sure what that implies. (Originally I had notified the Python team, but I removed them from this list because I am suspecting this regression may not be the result of any problem with the version flip itself, but the broken packages instead. Sorry.) Notifying from fdroidserver maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<ins> { lib , buildPythonPackage , pythonOlder , fetchFromGitHub , pdm-backend , packaging , pytestCheckHook }: buildPythonPackage rec { pname = "dep-logic"; version = "0.0.4"; pyproject = true; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "pdm-project"; repo = "dep-logic"; rev = version; hash = "sha256-AFiCNzHlo3BADqbjRBruA80cfM6Ytdb+gReEg5hUmro="; }; nativeBuildInputs = [ pdm-backend ]; propagatedBuildInputs = [ packaging ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "dep_logic" ]; meta = { changelog = "https://github.com/pdm-project/dep-logic/releases/tag/${src.rev}"; description = "Python dependency specifications supporting logical operations"; homepage = "https://github.com/pdm-project/dep-logic"; license = lib.licenses.asl20; maintainers = with lib.maintainers; [ tomasajt ]; }; } </ins>

Related discussion:
text: Steps to reproduce the behavior: truststore Output of : Adding to solves this issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
tomli ]; <ins> nativeBuildInputs = [ installShellFiles ]; </ins> nativeCheckInputs = [ pytestCheckHook git

Related discussion:
text: It would be nice if the package included shell completions for bash, zsh, fish. Steps to reproduce the behavior: (In fish): pipx-specific shell completions should show. One problem specific to is that the instructions you get with do not work unless you know to install the binary first (e.g. ). I hope that mimicking would work (though I'd also like completions to be included). I might be able to try that myself at some point, but I'm not very familiar with testing that a patch to works. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
}: buildLuarocksPackage { pname = "luafilesystem"; <del> version = "1.7.0-2"; </del> <ins> version = "1.8.0-1"; </ins> knownRockspec = (fetchurl { <del> url    = "mirror://luarocks/luafilesystem-1.7.0-2.rockspec"; sha256 = "0xivgn8bbkx1g5a30jrjcv4hg5mpiiyrm3fhlz9lndgbh4cnjrq6"; </del> <ins> url    = "mirror://luarocks/luafilesystem-1.8.0-1.rockspec"; sha256 = "18nkaks0b75dmycljg5vljap5w8d0ysdkg96yl5szgzr7nzrymfa"; </ins> }).outPath; src = fetchgit ( removeAttrs (builtins.fromJSON ''{ "url": "https://github.com/keplerproject/luafilesystem", <del> "rev": "de87218e9798c4dd1a40d65403d99e9e82e1cfa0", "date": "2017-09-15T20:07:33-03:00", "path": "/nix/store/20xm4942kvnb8kypg76jl7zrym5cz03c-luafilesystem", "sha256": "0zmprgkm9zawdf9wnw0v3w6ibaj442wlc6alp39hmw610fl4vghi", </del> <ins> "rev": "7c6e1b013caec0602ca4796df3b1d7253a2dd258", "date": "2020-04-22T22:16:42-03:00", "path": "/nix/store/qzjav1cmn4zwclpfs0xzykpbv835d84z-luafilesystem", "sha256": "16hpwhj6zgkjns3zilcg3lxfijm3cl71v39y9n5lbjk4b9kkwh54", </ins> "fetchLFS": false, "fetchSubmodules": true, "deepClone": false,

Related discussion:
text: Version 1.8.0 is available and . It looks like this should be a trivial bump in the luarocks csv. <!-- 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: <!-- 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.7.0-2 desired version: 1.8.0-1 <!-- 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.
Wanna take a stab at it then ? we can help you through the process
Code change:
{ lib , stdenv <del> , boost </del> <ins> , boost175 </ins> , fetchFromGitHub , libpcap , ndn-cxx

Related discussion:
text: The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.