jiebi/CodeConvo huggingface dataset:
Code change:
githubId = 2526296; name = "Adrien Bustany"; }; <ins> abysssol = { name = "abysssol"; email = "abysssol@pm.me"; matrix = "@abysssol:tchncs.de"; github = "abysssol"; githubId = 76763323; }; </ins> acairncross = { email = "acairncross@gmail.com"; github = "acairncross";

Related discussion:
text: Package name: ollama Latest released version: 0.1.20 <!-- Search your package here: --- Current version on the unstable channel: 0.1.17 Current version on the stable/release channel: 0.1.7 <!-- 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 Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
20 was released.[^1] :tada: Had a quick look into the source changes. Seems that patching is required because of the integration of ROCm. [^1]:
I modified the title :-)
21 is going to be released very soon.
I opened
update: 0.1.22 is the latest version.
Seems update can be problematic. I've tried manually download and executing new ollama and encountered a lot of issues connected with ROCM libraries. After adding I've got it to state where it crushes: But before adding it seems also miss new version of because it was asking for but current unstable version have CPU works fine without mentioned ROCM packages.
This appears to have been resolved by . Reopen if it's not.
Code change:
coilmq = buildPythonPackage (rec { <del> name = "coilmq-0.6.1"; </del> <ins> name = "CoilMQ-${version}"; version = "1.0.0"; </ins> src = pkgs.fetchurl { <del> url = "http://pypi.python.org/packages/source/C/CoilMQ/CoilMQ-0.6.1.tar.gz"; sha256 = "9755733bdae33a9d87630232d166a7da2382f68c2cffb3bb81503806e8d310cb"; </del> <ins> url = "http://pypi.python.org/packages/source/C/CoilMQ/${name}.tar.gz"; sha256 = "0wwa6fsqw1mxsryvgp0yrdjil8axyj0kslzi7lr45cnhgp5ab375"; </ins> }; <del> propagatedBuildInputs = with self; [ self.stompclient ]; </del> <ins> propagatedBuildInputs = with self; [ stompclient pythondaemon redis pid]; </ins> <del> preConfigure = '' sed -i '/distribute/d' setup.py ''; </del> <ins> buildInputs = with self; [ pytest six click coverage sqlalchemy ]; </ins> <del> buildInputs = with self; [ self.coverage self.sqlalchemy7 ]; # ValueError: Could not parse auth file: # /tmp/nix-build-.../CoilMQ-0.6.1/coilmq/tests/resources/auth.ini </del> <ins> # The teste data is not included in the distribution </ins> doCheck = false; meta = {

Related discussion:
text: To make sure that we are on the same page: Kernel: System: Nix version: Nixpkgs version: broke legacy packages (only tested with the -set). Multiple options to solve this: revert the commit (an update will eventually have to be done) make sure no-one depends on sqlalchemy legacy versions (this would be the best choice, but can require a big amount of work) re-introduce an outdated version only used by legacy version (I’ll prepare a PR shortly that follows this path) cc
To be complete, the build problem is a test failure: I also checked, we cannot downgrade sqlite only for few pythonPackages, the entire python (and package set) have to be changed. Any preferred way to go?
(We should check if we still need this version, have it removed locally for virtmanager, virtinst as it isn't used, but haven't had the time to push that)
Yes, this is the preferred way to go. I began that but did not finish it yet, and it impacts some important parts (it causes xen to fail) I would prefer not to break because of unsufficient testing from me. This is in progress but could require some time to complete.
FYI xen already fails on
FYI: I switched away from sqlalchemy7 in yesterday.
Apart from virtinst, acd_cli, beaker, coilmq, and geeknote are the only revdeps of sqlalchemy7, as far as I can tell.
I openned to do some cleanup on sqlalchemy7. There still is that explicitly require . The same work will have to be done for and .
This should have remained open.
Using an older version of sqlite requires overriding the derivations of the interpreters.
See
Code change:
"-Wno-error=unused-const-variable" "-Wno-error=misleading-indentation" ]; <ins> makeFlags = if stdenv.hostPlatform == stdenv.buildPlatform then null else "CROSS_COMPILE=${stdenv.cc.targetPrefix}"; </ins> installFlags = "install install-man ASCIIDOC8=1"; preFixup = ''

Related discussion:
text: First failing build (4.9.76, but not always): Latest (4.9.77): Looking through the changes for any obvious culprits...
bisected to (as the first "bad commit"). cc
Reverting the commit on master fixes the build, but need to replace with to at least fix evaluation on cross. Since doesn't seem to build on cross (at least not on any architectures I've tried) I can't tell if this "works", but would be good to fix this on non-cross regardless.
See corresponding PR, this has been handled. Thanks!
Code change:
, MonadRandom, mtl, optparse-applicative, process, random, stm, tasty , tasty-hunit, tasty-quickcheck, temporary, text, transformers , unix, unliftio , unliftio-core, unordered-containers, vector, vector-instances, vty <del> , wl-pprint-annotated, word8, yaml , extra, ListLike, semver </del> <ins> , wl-pprint-annotated, word8, yaml, extra, ListLike, semver </ins> }: mkDerivation rec { pname = "echidna"; <del> version = "1.7.3"; </del> <ins> version = "2.0.2"; </ins> src = fetchFromGitHub { owner = "crytic"; repo = "echidna"; rev = "v${version}"; <del> sha256 = "sha256-NkAAXYa1bbCNUO0eDM7LQbyC3//RRFAKmEHGH2Dhl/M="; </del> <ins> sha256 = "sha256-WmlQWgn4qfRmx3PdzY7wzT9AyU7Re2T1CWJ7yGjcVac="; </ins> }; <ins> # NOTE: echidna is behind with aeson because of hevm, this patch updates # the code to work with the major aeson update that broke the build # it's temporary until hevm version 0.50.0 is released - https://github.com/ethereum/hevm/milestone/1 patches = [ ./echidna-update-aeson.patch ]; </ins> isLibrary = true; isExecutable = true; libraryHaskellDepends = [

Related discussion:
text: <!-- 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.3 desired version: 2.0.2 <!-- 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.
waiting for 0.50.0 release of
I fixed echidna.
Lovely. Thanks you so much for you effort.
Code change:
mpg321 = callPackage ../applications/audio/mpg321 { }; <del> mpc_cli = callPackage ../applications/audio/mpc { </del> <ins> mpc-cli = callPackage ../applications/audio/mpc { </ins> inherit (python3Packages) sphinx; };

Related discussion:
text: The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.
Code change:
}, "zlib": { "url": "https://chromium.googlesource.com/chromium/src/third_party/zlib", <del> "rev": "c876c8f87101c5a75f6014b0f832499afeb65b73", "sha256": "sha256-mwozVo8ymyrYN4tw+/ZnSI+xogSTZQ6PUBba/jQqRkE=" </del> <ins> "rev": "646b7f569718921d7d4b5b8e22572ff6c76f2596", "sha256": "sha256-jNj6SuTZ5/a7crtYhxW3Q/TlfRMNMfYIVxDlr7bYdzQ=" </ins> }, "harfbuzz": { "url": "https://chromium.googlesource.com/external/github.com/harfbuzz/harfbuzz.git", <del> "rev": "4cfc6d8e173e800df086d7be078da2e8c5cfca19", "sha256": "sha256-rrstyAz7Eb8ZgFJZKUASY8nU4YFZAptd5VS9B2cs2Yg=" </del> <ins> "rev": "c053e8f29257814e11ad61493dbbe29f27656de4", "sha256": "sha256-D8DNcZH/oiJqWvfWFHvQ8AwQ3OrMwyZdfGmZ5y30Hvg=" </ins> }, "wuffs": { "url": "https://skia.googlesource.com/external/github.com/google/wuffs-mirror-release-c.git",

Related discussion:
text: Package name: neovide Latest released version: 0.13.0 <!-- Search your package here: --- Current version on the unstable channel: 0.12.2 Current version on the stable/release channel: 0.11.2 <!-- 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. As an additional note, I am currently working on updating Neovide myself. Part of my plans this summer are to begin giving at least two contributions to Nix/NixOS/Nixpkgs each week. I intend to begin maintaining Neovide as part of this goal. Gotta figure out how to A.) apply as a maintainer and B.) figure out if I'm even eligible. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For future issues/prs/etc. where should I add an additional summary/context if I have any? I've sandwiched it between the Note for maintainers... and Add a reaction... sections in this issue.
Code change:
}: let <del> inherit (lib) mkEnableOption mkPackageOption mkOption maintainers; inherit (lib.types) bool str; </del> <ins> inherit (lib) mkEnableOption mkPackageOption mkOption maintainers ; inherit (lib.types) bool port str submodule ; </ins> cfg = config.services.navidrome; settingsFormat = pkgs.formats.json { }; in

Related discussion:
text: Evaluation failure when setting and . Moreover setting any will "remove" the default values for and your system with these options: the failure: System builds, firewall is opened for the default 4533 port. This bug happens because the rather than for each individual setting. <!-- 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]:
the Issue here is the option being null, you can use these options together if is supplied. if you encountered a different eval failure to this please attach it. Yes this is because those options values are supplied as apart of one default of as a whole, I am not aware of a nice way to give them a default independent of the rest of the settings being set or not. would giving this port value a catch for being null be an alright solution? e.g.. if is not set, then use the upstream default ( of 4533 I believe ) I don't really want to separate out these values from the . option so this wont address the removal of default values when setting them yourself to something different, I think this is expected enough* behavior. I think fixing this eval failure condition with simply supplying the default port where isn't supplied is reasonable enough, as anyone who wasnt going to set that in the first place is unlikely to care if its the same value in function either way. In fact i may just remove the default entirely and simply handle the case of no supplied value by assuming the default port (of 4533 ) in the openFirewall rule. I'll PR these changes once I get the time
Code change:
strct = callPackage ../development/python-modules/strct { }; <ins> streamcontroller-plugin-tools = callPackage ../development/python-modules/streamcontroller-plugin-tools { }; </ins> streamdeck = callPackage ../development/python-modules/streamdeck { }; streaming-form-data = callPackage ../development/python-modules/streaming-form-data { };

Related discussion:
text: Project description As discussed in is now EOL and the dev's have moved their effort to . As per the in order for it to work specific need to be set up. We can probably do something similar to what we do for the expression: Metadata homepage URL: source URL: license: GPL3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For people who subscribed to this issue: I opened to add streamcontroller
Code change:
ln -s '${newConfigPath}' "${currentConfigPath}" fi ''; <del> setupRuntimeDir = writeScript "setup-runtime-dirs" '' </del> <ins> setupWorkDir = writeScript "setup-work-dirs" '' # Cleanup previous service ${pkgs.findutils}/bin/find -H "$WORK_DIRECTORY" -mindepth 1 -delete </ins> # Link _diag dir <del> ln -s "$LOGS_DIRECTORY" "$RUNTIME_DIRECTORY/_diag" </del> <ins> ln -s "$LOGS_DIRECTORY" "$WORK_DIRECTORY/_diag" </ins> <del> # Link the runner credentials to the runtime dir ln -s "$STATE_DIRECTORY"/{${lib.concatStringsSep "," runnerCredFiles}} "$RUNTIME_DIRECTORY/" </del> <ins> # Link the runner credentials to the work dir ln -s "$STATE_DIRECTORY"/{${lib.concatStringsSep "," runnerCredFiles}} "$WORK_DIRECTORY/" </ins> ''; in <del> map (x: "${x} ${escapeShellArgs [ stateDir runtimeDir logsDir ]}") [ </del> <ins> map (x: "${x} ${escapeShellArgs [ stateDir workDir logsDir ]}") [ </ins> "+${unconfigureRunner}" # runs as root configureRunner <del> setupRuntimeDir </del> <ins> setupWorkDir </ins> ]; # If running in ephemeral mode, restart the service on-exit (i.e., successful de-registration of the runner)

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Code change:
pyside6 pysocks qrcode <del> qrcode </del> requests stem unidecode

Related discussion:
text: Steps to reproduce the behavior: onionshare <!-- 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]:
The package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:
Code change:
"-X ${prefix}.BuildDate=1980-01-01T00:00:00Z" ]; <ins> nativeBuildInputs = [ fixup_yarn_lock nodejs yarn ]; </ins> tags = [ <ins> "builtinassets" </ins> "nonetwork" "nodocker" "promtail_journal_enabled"

Related discussion:
text: I started grafana-agent in flow mode, and tried to access the http API at http://localhost:. Unfortunately, instead of providing a web interface to debug the current list of components, I get a "404 page not found". Steps to reproduce the behavior: grafana-agent in flow mode. port via HTTP I'd expect grafana-agent to ship with the web interface. Please run and paste the result.
It looks like is what's building the frontend. Unfortunately, the web interface seems managed by yarn (and has a ), so we'd need to first provide a . I tried to have resolve the dependency, but it seems it's not able to:
I manually patched things in to bump to a more recent version, compatible with the react version that's mentioned in , but ugh, I'm not really sure why it's that way. I'll ask upstream.
yeah, sorry, I don't use flow mode (yet?) and the nixos module does not support it either, as far as I am aware. I can try looking into it as well, first, before you raise an issue upstream. While the nixos module might lack support for it (for now?), I believe we should try fix it nonetheless :)
Yeah, we should probably have a second NixOS module for flow mode, it's very different and the existing config structure doesn't make much sense - for now I just did ship my own custom systemd unit for it: But yeah, without the web ui it's quite annoying to debug, so we should probably get that sorted out first, before providing a module and getting more people to use it.
fyi
I tried to move it over, but still seems to be terribly slow when trying to resolve deps and not being able to, so I guess we should stay with yarn.
We should prefer yarn simply due to upstream having an instead of a :) ^
Code change:
vendorHash = "sha256-MqUkGKOzx8Qo9xbD9GdUryVwKjpVUOXFo2x0/2uz8Uk="; proxyVendor = true; # darwin/linux hash mismatch <ins> frontendYarnOfflineCache = fetchYarnDeps { yarnLock = src + "/web/ui/yarn.lock"; hash = "sha256-xJEPubIDjlZQL70UGha1MHbeek6KFPaxZGb5IRgMlTA="; }; </ins> ldflags = let prefix = "github.com/grafana/agent/pkg/build"; in [

Related discussion:
text: I started grafana-agent in flow mode, and tried to access the http API at http://localhost:. Unfortunately, instead of providing a web interface to debug the current list of components, I get a "404 page not found". Steps to reproduce the behavior: grafana-agent in flow mode. port via HTTP I'd expect grafana-agent to ship with the web interface. Please run and paste the result.
It looks like is what's building the frontend. Unfortunately, the web interface seems managed by yarn (and has a ), so we'd need to first provide a . I tried to have resolve the dependency, but it seems it's not able to:
I manually patched things in to bump to a more recent version, compatible with the react version that's mentioned in , but ugh, I'm not really sure why it's that way. I'll ask upstream.
yeah, sorry, I don't use flow mode (yet?) and the nixos module does not support it either, as far as I am aware. I can try looking into it as well, first, before you raise an issue upstream. While the nixos module might lack support for it (for now?), I believe we should try fix it nonetheless :)
Yeah, we should probably have a second NixOS module for flow mode, it's very different and the existing config structure doesn't make much sense - for now I just did ship my own custom systemd unit for it: But yeah, without the web ui it's quite annoying to debug, so we should probably get that sorted out first, before providing a module and getting more people to use it.
fyi
I tried to move it over, but still seems to be terribly slow when trying to resolve deps and not being able to, so I guess we should stay with yarn.
We should prefer yarn simply due to upstream having an instead of a :) ^
Code change:
}; enableSuid = mkOption { type = types.bool; <del> default = true; </del> <ins> # SingularityCE requires SETUID for most things. Apptainer prefers user # namespaces, e.g. `apptainer exec --nv` would fail if built # `--with-suid`: # > `FATAL: nvidia-container-cli not allowed in setuid mode` default = cfg.package.projectName != "apptainer"; defaultText = literalExpression ''config.services.singularity.package.projectName != "apptainer"''; </ins> example = false; description = mdDoc '' Whether to enable the SUID support of Singularity/Apptainer.

Related discussion:
text: singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- 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.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.