jiebi/CodeConvo huggingface dataset:
Change:
]; nativeBuildInputs = [ perl pkg-config ]; <del> buildInputs = [ libtool libxml2 openssl libuv nghttp2 jemalloc ] </del> <ins> buildInputs = [ libidn2 libtool libxml2 openssl libuv nghttp2 jemalloc ] </ins> ++ lib.optional stdenv.isLinux libcap ++ lib.optional enableGSSAPI libkrb5 ++ lib.optional enablePython (python3.withPackages (ps: with ps; [ ply ]));

Discussion:
outputs something like "187183230175148230" instead of Chinese when it should output Chinese. Steps to reproduce the behavior: of the terminal use a command similar to the following Can output Chinese normally <img width="803" alt="image" src=""The terminal is the one that comes with the gnome desktop. <img width="803" alt="image" src=""<!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<del> { lib, stdenv, fetchurl, fetchpatch, pkg-config, intltool, xorg, pcre, gst_all_1, glib , xosd, libnotify, enchant, wrapGAppsHook, gdk-pixbuf }: </del> <ins> { stdenv , lib , fetchurl , fetchpatch , autoreconfHook , intltool , pkg-config , wrapGAppsHook , enchant , gdk-pixbuf , glib , gst_all_1 , libnotify , pcre , xorg , xosd }: </ins> stdenv.mkDerivation { <del> pname = "xneur"; version = "0.20.0"; </del> <ins> pname = "xneur"; version = "0.20.0"; </ins> src = fetchurl { url = "https://github.com/AndrewCrewKuznetsov/xneur-devel/raw/f66723feb272c68f7c22a8bf0dbcafa5e3a8a5ee/dists/0.20.0/xneur_0.20.0.orig.tar.gz";

Discussion:
Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
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 issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. &rarr;
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to
Change:
<ins> #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl wget jq yarn2nix yarn common-updater-scripts set -eu -o pipefail scriptDir=$(cd "${BASH_SOURCE[0]%/*}" && pwd) nixpkgs=$(realpath "$scriptDir"/../../../..) newest_version="$(curl -s https://www.pgadmin.org/versions.json | jq -r .pgadmin4.version)" old_version=$(nix-instantiate --eval -E "(import "$nixpkgs" { config = {}; overlays = []; }).pgadmin4.version" | tr -d '"') url="https://ftp.postgresql.org/pub/pgadmin/pgadmin4/v${newest_version}/source/pgadmin4-${newest_version}.tar.gz" if [[ $newest_version == $old_version ]]; then echo "Already at latest version $newest_version" exit 0 fi echo "New version: $newest_version" pushd $(mktemp -d --suffix=-pgadmin4-updater) wget $url tar -xzf "pgadmin4-$newest_version.tar.gz" cd "pgadmin4-$newest_version/web" yarn2nix > yarn.nix cp yarn.nix yarn.lock package.json "$nixpkgs/pkgs/tools/admin/pgadmin/" popd update-source-version pgadmin4 "$newest_version" --print-changes </ins>

Discussion:
Steps to reproduce the behavior: pgadmin.service Add any other context about the problem here. Please run and paste the result.
I know. The PR needs to be merged.
seems like it might be some time before this gets fixed. In the meantime, is there a way I could force my system to use an older version of pgadmin? I'm using flakes for my system config.
The way I do it, is to maintain my own fork of and cherry-pick PR's like that. An older version will not work, because they will run into similar errors. You could only run an older version of . This is a problem due to updated dependencies in nixpkgs. I re-requested an review from and/or maybe someone else has time to review/commit the PR.
OK I got it working for now by changing my as follows: Please let me know if that's a terrible idea in your opinion ...
No, not really. I use my branch which I regularly update, which includes my cherry-picked commits. The commit you picked reflects the status of at the time of the commit of pgadmin (and obviously the changes to pgadmin) You just need to be aware that due to the pinning, a will not update currently and should probably be reverted once the PR got merged.
thanks that's what I'll do!
I'm a little fuzzy on what happens next here. Am I seeing correctly that this problem is still not resolved?
The PR needs to be merged. AFAIK everything is done with the PR
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Got it working using in my flake.
Change:
}; ``` <ins> ::: {.tip} A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update): ```nix passthru.updateScript = nix-update-script { }; ``` For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases). ::: </ins> ##### How update scripts are executed? {#var-passthru-updateScript-execution} Update scripts are to be invoked by `maintainers/scripts/update.nix` script. You can run `nix-shell maintainers/scripts/update.nix` in the root of Nixpkgs repository for information on how to use it. `update.nix` offers several modes for selecting packages to update (e.g. select by attribute path, traverse Nixpkgs and filter by maintainer, etc.), and it will execute update scripts for all matched packages that have an `updateScript` attribute.

Discussion:
is undocumented. Add it to the manual. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]:
Here you can find the source: So basically it runns on your package with some .
Change:
sed <"etc/lua.pc" >"$out/lib/pkgconfig/lua.pc" -e "s|^prefix=.*|prefix=$out|" mv "doc/"*.{gif,png,css,html} "$out/share/doc/lua/" rmdir $out/{share,lib}/lua/5.1 $out/{share,lib}/lua <ins> wrapProgram $out/bin/lua  --set LUA_PATH  '"$HOME/.nix-profile/lib/lua/5.1/?.lua;$HOME/.nix-profile/share/lua/5.1/?.lua"'  --set LUA_CPATH '"$HOME/.nix-profile/lib/lua/5.1/?.so;$HOME/.nix-profile/share/lua/5.1/?.so"' </ins> ''; meta = {

Discussion:
Lua is looking for modules within the wrong path: instead of Within the nix expression the correct path for is set: Also the prefixes in are correct. What can I do? How can I change this behavior? I tried to add a setup-hook with an but that didn't work. Any suggestions?
Change:
}; <del> config.options = mkMerge [ </del> <ins> config.options = let inInitrd = utils.fsNeededForBoot config; in mkMerge [ </ins> (mkIf config.autoResize [ "x-systemd.growfs" ]) (mkIf config.autoFormat [ "x-systemd.makefs" ]) (mkIf (utils.fsNeededForBoot config) [ "x-initrd.mount" ]) <ins> (mkIf # With scripted stage 1, depends is implemented by sorting 'config.system.build.fileSystems' (lib.length config.depends > 0 && (inInitrd -> moduleArgs.config.boot.initrd.systemd.enable)) ( map ( x: "x-systemd.requires-mounts-for=${optionalString inInitrd "/sysroot"}${x}" ) config.depends ) ) </ins> ]; };

Discussion:
systemd doesn't respect the option for file systems. Usually this is ok because systemd will mount file systems in the correct topological ordering. The option is useful because it allows you to express dependencies on e.g. the file systems that an FS's lower/upper/work directories exist on. This test should hang forever. Instead, it exits cleanly. The service never exits, so is never mounted, and therefore should never be mounted. So the test should hang. This is also a problem for systemd stage 1, but it's worse because we also have to account for the prefix. We can fix this by adding options for every dependency, and prefixing for the systemd stage 1 file systems.
Do we even need the option? I don't think it's particularly useful. The overlay also shouldn't be a concern since anymore.
Well, currently literally only does anything in scripted stage 1. In stage 2 and in systemd stage 1, you have to use , which is what the stuff does. That's fine, but it's an incompatibility between scripted and systemd stage 1. So we need to either deprecate it or implement it, and it's really easy to implement (I just need to fixup ). It's a handy convenience for people I guess, though far from a necessary one.
Change:
pyshp #mapbox-vector-tile pypng <ins> #pyconll </ins> fonttools #sas7bdat #xport

Discussion:
Package name: visidata Latest released version: 3.0 Current version on the unstable channel: 2.11.1 Current version on the stable/release channel: 2.11.1Release post: Changelog: The new version and its tests seems to want pyconll and a fork of savReaderWriter as new dependencies. The package is also missing a attribute. 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]:
Change:
description = "ConnMan VPN service"; wantedBy = [ "multi-user.target" ]; after = [ "syslog.target" ]; <del> before = [ "connman" ]; </del> <ins> before = [ "connman.service" ]; </ins> serviceConfig = { Type = "dbus"; BusName = "net.connman.vpn";

Discussion:
With the nixos system fails to build, with the following message: <!-- 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.
Caused by .
Change:
### DEVELOPMENT / GO # the unversioned attributes should always point to the same go version <del> go = go_1_18; buildGoModule = buildGo118Module; buildGoPackage = buildGo118Package; </del> <ins> go = go_1_19; buildGoModule = buildGo119Module; buildGoPackage = buildGo119Package; </ins> go_1_17 = callPackage ../development/compilers/go/1.17.nix ({ inherit (darwin.apple_sdk.frameworks) Foundation Security;

Discussion:
Golang releases once every 6 month and supports the latest two releases. These are currently 1.19 was released on 2022/08/02 1.18 was released on 2022/03/15 and will be EOL around 2023/03, two months before 22.11's EOL. Cf.
Besides fixing or pinning broken builds/nixosTests would need to check vendor hashes are reproducible or fix/pin them as well. The PR for 1.18 has more detail about what needs to be done when changing the default :
How do we handle packages pinned with ?
They need to be fixed to not use 1.17 or eventually they'll be marked as broken when 1.17 is removed. Likely that most of the packages still on 1.17 require upstream fixes.
Would we accept a PR that pins every existing user of to and switching the default to on master. This would change the default for new modules and allow piecemeal work on migrating all existing modules. I'm not against a single effort like , but I don't think I could set aside the time to manage something like that, and I'm interested in helping out.
As the two active go maintainers, can both of you clarify whether you will take care of the required update?
I'll do it this week.
I'll count that as a check-in for . Thanks!
I've rechecked vendor hashes after the staging-next merge, no breakage. As hydra catches up I'll continue fixing/pinning any other breakage from 1.19 that I didn't catch initially.
Which version of NixOS Docker image has/will have Go 1.19?
Go 1.19 is on NixOS unstable right now and will be part of NixOS 22.11. I'm not sure about the base of your docker images though.
Change:
systemd.services.dd-agent = { description = "Datadog agent monitor"; <del> path = [ pkgs."dd-agent" pkgs.python pkgs.sysstat pkgs.procps ]; </del> <ins> path = [ pkgs."dd-agent" pkgs.python pkgs.sysstat pkgs.procps pkgs.gohai ]; </ins> wantedBy = [ "multi-user.target" ]; serviceConfig = { ExecStart = "${pkgs.dd-agent}/bin/dd-agent foreground";

Discussion:
Expected output: empty gohai can be found here: This holds for nixpkgs master.
I've submitted to fix this issue. We've worked around it until this is released by adding the derivation to our NixOS configuration repository and adding it to the unit's path, like so: NixOS will merge that option together with the already existing derivations on the unit's path, so it doesn't break the existing configuration. We've been running this change on a dozen or so live-servers and it works fine.
pull request was merged.
The fix is now in 18.03 :)
Change:
<ins> diff --git a/Bio/SeqIO/SeqXmlIO.py b/Bio/SeqIO/SeqXmlIO.py index 8fe75ebb728..6758317d05f 100644 --- a/Bio/SeqIO/SeqXmlIO.py +++ b/Bio/SeqIO/SeqXmlIO.py @@ -498,11 +498,12 @@ def iterate(self, handle): if not text: break parser.feed(text) +        # Closing the parser ensures that all XML data fed into it are processed +        parser.close() # We have reached the end of the XML file; # send out the remaining records yield from records records.clear() -        parser.close() class SeqXmlWriter(SequenceWriter): </ins>

Discussion:
Minimal flake to reproduce the issue: : : Disabling install checks using fixes the issue. If you uncomment the commented overlay in the minimal flake I provided, the build will succeed and the package will work properly.
+1 Same issue with same log. (tagging, as you are in maintainers list)
Looks like a bug upstream:
As per the Biopython issue linked, Debian sid is failing in the same way. Specifically, converting two annotated sequence files (one in EMBL format, one in Genbank format) into SeqXML format and then attempting to read this XML file back fails. Narrower tests from that issue: File expected is here (with .txt to the filename): This seems to fail (but shouldn't): This appears to be something breaking via the XML SAX expat parser. Can you see anything relevant which has changed on your platform to help narrow this down?
Hi, I tracked this issue down to a upgrade from 2.5.0 to 2.6.1 from Debian testing to sid. [Debian CI] suggests this could also cause regression in Python tests. Is this consistent with what you observe on Nix? If so, I strongly believe the root cause of the Biopython issue is ingrained in a bad interaction between the newer expat version and the Python interpreter, notably: [Debian CI]: In hope this helps, Étienne.
I can confirm that latest 1.84-dev works. We have to wait for update to be tagged. Until then, you can modify on to use
We have a few NumPy 2.0 test incompatibilities to fix (due to their scalar repr changes), and then we want to release Biopython 1.84 which would include the libexpat fix (moving a close earlier):
Change:
"RandomFields" "rareNMtests" "rAverage" <ins> "RclusTool" </ins> "Rcmdr" "RcmdrPlugin_coin" "RcmdrPlugin_depthTools"

Discussion:
Describe the bug The installation of the package RclusTool freezes just after this message: To Reproduce Steps to reproduce the behavior: Additional context I am the main maintainer of this package. This issue may be related to the fact that our package requires a X server (issue already noticed with mac os X). I have some difficulties to build the package with Nixos.This may be related too : Metadata** Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(hebert): nixpkgs:
I marked this as stale due to inactivity. &rarr;
I took a look at this and attached to the R process during the byte compilation. Looks like it's stuck in an infinite loop that continuously looks through the r-tcltk2 package files. Other packages that depend on tcltk2 (PDE) seem to work fine, so something specific to RclusTool is triggering this.
Yeah it was missing from the list of packages requiring X.
Thanks for your answer. I will think about giving another chance to Nixos. (I went back to Linux, because I couldn’t use R and its packages properly…) Regards, Pierre Hébert
No worries, you can always run Nix on top of your current distribution and see if R is suitable for your needs without installing NixOS. A healthy R ecosystem is very important to me as we use R heavily in my lab. Tag me in on any R related issues you might have and I'll do my best to resolve them.
Change:
meta = oldAttrs.meta // { # ModuleNotFoundError: No module named 'distutils' <del> broken = true; </del> <ins> broken = stdenv.isDarwin; # still broken on darwin </ins> }; });

Discussion:
Steps to reproduce the behavior: joplin I ping another package's maintainer, sorry. also I can't find maintainer of that package. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
}; }; <ins> makeGitDep = { pname, version, repository, sha256, }: { inherit pname version; src = fetchgit { url = repository; rev = version; inherit sha256; }; }; </ins> lockJson = if lib.isPath dubLock then lib.importJSON dubLock else dubLock; <ins> depsRaw = lib.mapAttrsToList (pname: args: { inherit pname; } // args) lockJson.dependencies; </ins> <del> lockedDeps = lib.mapAttrsToList ( pname: { version, sha256 }: makeDubDep { inherit pname version sha256; } ) lockJson.dependencies; </del> <ins> dubDeps = map makeDubDep (lib.filter (args: !(args ? repository)) depsRaw); gitDeps = map makeGitDep (lib.filter (args: args ? repository) depsRaw); </ins> # a directory with multiple single element registries # one big directory with all .zip files leads to version parsing errors

Discussion:
fails to build a lockfile with dependencies in the format (). Here's the error: any repository whose contains a dependency that fetches from Git, e.g. , e.g. . a few moments, then see error. A generated lockfile containing the Git dependency. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for reporting this bug, I'll try to extend the lockfile logic later today, (the current one is pretty primitive, as you might have seen)
Change:
{ stdenv, fetchFromGitHub, fetchpatch, ftgl, glew, asciidoc , cmake, ninja, libGLU, libGL, zlib, python, expat, libxml2, libsigcxx, libuuid, freetype , libpng, boost, doxygen, cairomm, pkgconfig, libjpeg, libtiff <del> , gettext, intltool, perl, gtkmm2, glibmm, gtkglext, pangox_compat, libXmu }: </del> <ins> , gettext, intltool, perl, gtkmm2, glibmm, gtkglext, libXmu }: </ins> stdenv.mkDerivation rec { version = "0.8.0.6";

Discussion:
Describe the bug Seems like some updates to pango broke a few packages Among the broken ones: ettercap (see ) pangox-compat (which anydesk needs) probably a few more To Reproduce Steps to reproduce the behavior: to build ettercap or anydesk from master will fail to build with some pango-related errors Expected behavior It should work Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Also remmina is broken But doesn't seem to depend on pango directly, so unsure which dependency actually is broken
Here's an issue for pangox-compat
Lutris is broken too - not an urgent requirement but just making you fine folks aware!
Not sure why Lutris is broken, but Lutris-unwrap is fine.
It's a failure in the dependency chain, in this case .
no longer depends on on its master branch: We should probably switch to that. should not be needed in according to the README in , I suspect it was only there because we did not propagate it until ebassi also suggests switching to HEAD and says we need not worry about ABI changes:
Not having pangox_compat fixed is definitively still an issue. Can this be re-opened?
After , the only program depending on this is anydesk and openmodelica which is broken.
So it breaks anydesk thus either we mark anydesk as broken or we fix that?
Anydesk shouldn't use this deprecated library. Yes, we can mark it as broken.
Change:
in buildEnv { name = "ihaskell-with-packages"; <del> paths = [ ihaskellEnv ipython (abort "ihaskell is currently broken. See https://github.com/NixOS/nixpkgs/issues/22047.")]; </del> <ins> paths = [ ihaskellEnv ipython ]; </ins> postBuild = '' . "${makeWrapper}/nix-support/setup-hook" ln -s ${ihaskellSh}/bin/ihaskell-notebook $out/bin/.

Discussion:
IHaskell is not GHC 8 compatible, and so it doesn't build on 16.09 onwards. Instead I get this error: System: 16.09.1512. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1512.
Thanks for filing an issue! I see you already filed the GHC 8 incompatibility upstream. You could try the following patch: but it'll require re-building substantial amounts of old code that are no longer being build by hydra. If it works we can apply the patch, otherwise I think I'd vote for removing the package. What do you think?
After applying your patch, I'm getting an error building (). Is there an easy workaround for this? I'm hopeful that IHaskell will gain GHC 8 compatibility in the near term, so I'd rather not remove the package :smile:
Reading I doubt there is. In order to save other people time maybe we should at least add an assert with an informative message and a link to this bug so other people won't lose time trying to install ihaskell?
Sure, that's a good idea.
I can't see an easy way of disabling ihaskell, so I suggest removal, followed by re-introduction when fixed. - would you be able to own this?
I've created a pull request.
I am experiencing a similar error on current nixos-unstable channel ...