jiebi/CodeConvo huggingface dataset:
Change:
hash = "sha256-uQKTE36pLO8uhrX794utqaDGUeyqRz6zLCQFA7DYkNc="; }; <del> buildInputs = [ bzip2 lzo openssl zlib ]; </del> <ins> patches = [ # Fix errors on x86_64 and _rotl definition (fetchpatch { name = "0001-fix-compile.patch"; url = "https://aur.archlinux.org/cgit/aur.git/plain/fix-compile.patch?h=quickbms&id=a2e3e4638295d7cfe39513bfef9447fb23154a6b"; hash = "sha256-49fT/L4BNzMYnq1SXhFMgSDLybLkz6KSbgKmUpZZu08="; stripLen = 1; }) ] ++ lib.optional (!opensslSupport) ./0002-disable-openssl.patch; buildInputs = [ bzip2 lzo zlib ] ++ lib.optional (opensslSupport) openssl_1_1; </ins> makeFlags = [ "PREFIX=$(out)" ];

Discussion:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.
Change:
]); sitePackages = ceph-python-env.python.sitePackages; <del> version = "15.2.7"; </del> <ins> version = "15.2.8"; </ins> src = fetchurl { url = "http://download.ceph.com/tarballs/ceph-${version}.tar.gz"; <del> sha256 = "082lpx1rsifjh636zypxy6ccs6nfkcm9azxp5ghvr5mvx9chmyrj"; </del> <ins> sha256 = "1nmrras3g2zapcd06qr5m7y4zkymnr0r53jkpicjw2g4q7wfmib4"; </ins> }; in rec { ceph = stdenv.mkDerivation {

Discussion:
, CVSSv3=7.1 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc Cc Cc
Change:
++ lib.optionals (lib.versionAtLeast version "4.16") [ bison flex ] ++ lib.optional (lib.versionAtLeast version "5.2") pahole; <ins> platformName = stdenv.hostPlatform.linux-kernel.name; </ins> # e.g. "defconfig" <del> kernelBaseConfig = if defconfig != null then defconfig else stdenv.hostPlatform.linux-kernel.baseConfig or "defconfig"; </del> <ins> kernelBaseConfig = if defconfig != null then defconfig else stdenv.hostPlatform.linux-kernel.baseConfig; # e.g. "bzImage" kernelTarget = stdenv.hostPlatform.linux-kernel.target; </ins> makeFlags = lib.optionals (stdenv.hostPlatform.linux-kernel ? makeFlags) stdenv.hostPlatform.linux-kernel.makeFlags ++ extraMakeFlags;

Discussion:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by
Change:
<ins> { "name": "devpod", "private": true, "version": "0.0.0", "type": "module", "scripts": { "dev": "vite", "build": "tsc && vite build", "preview": "vite preview", "tauri": "tauri", "desktop:dev": "tauri dev --config src-tauri/tauri-dev.conf.json", "desktop:dev:debug": "export DEBUG=true; yarn desktop:dev", "desktop:build:dev": "DEBUG=true tauri build --config src-tauri/tauri-dev.conf.json", "desktop:build:debug": "tauri build --debug", "desktop:build": "tauri build --features enable-updater", "format:check": "prettier --check .", "format:fix": "prettier --write .", "types:check": "tsc -p ./tsconfig.json --noEmit" }, "dependencies": { "@chakra-ui/icons": "2.1.1", "@chakra-ui/react": "2.8.1", "@emotion/react": "11.11.1", "@emotion/styled": "11.11.0", "@headlessui/react": "1.7.17", "@tanstack/react-query": "4.36.1", "@tanstack/react-query-devtools": "4.36.1", "@tanstack/react-table": "8.10.7", "@tauri-apps/api": "1.5.0", "dayjs": "1.11.10", "framer-motion": "10.16.4", "markdown-to-jsx": "7.3.2", "react": "18.2.0", "react-dom": "18.2.0", "react-hook-form": "7.47.0", "react-icons": "4.11.0", "react-router": "6.16.0", "react-router-dom": "6.16.0", "tauri-plugin-store-api": "https://github.com/tauri-apps/tauri-plugin-store", "uuid": "9.0.1", "xterm": "5.3.0", "xterm-addon-fit": "0.7.0" }, "devDependencies": { "@tanstack/eslint-plugin-query": "4.36.1", "@tauri-apps/cli": "1.5.2", "@types/node": "18.15.3", "@types/react": "18.2.28", "@types/react-dom": "18.2.13", "@types/uuid": "9.0.5", "@typescript-eslint/eslint-plugin": "5.59.11", "@typescript-eslint/parser": "5.59.11", "@vitejs/plugin-react": "4.1.0", "eslint": "8.44.0", "eslint-config-prettier": "8.8.0", "eslint-config-react-app": "7.0.1", "eslint-plugin-react": "7.32.2", "eslint-plugin-react-hooks": "4.6.0", "prettier": "3.0.3", "typescript": "5.0.4", "vite": "4.4.9" } } </ins>

Discussion:
Project description DevPod is a client-only tool to create reproducible developer environments based on a on any backend. Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: unix, linux
I have opened PR and I would love some help with testing and reviewing :pray:
Change:
buildInputs = [ libffi libxml2 <ins> llvm </ins> zlib ] ++ lib.optionals (!stdenv.isDarwin) [ libclang ]; cmakeFlags = [ <del> (lib.cmakeOptionType "path" "CLANG_RESOURCE_DIR" "${lib.getDev libclang}") </del> <ins> (lib.cmakeOptionType "path" "CLANG_RESOURCE_DIR" "${lib.getLib libclang}/lib/clang/${lib.versions.major libclang.version}") </ins> (lib.cmakeBool "SPHINX_HTML" withHTML) (lib.cmakeBool "SPHINX_MAN" withManual) ] ++ lib.optionals stdenv.isDarwin [ (lib.cmakeOptionType "path" "Clang_DIR" "${lib.getDev libclang}/lib/cmake/clang") ]; <del> # 97% tests passed, 97 tests failed out of 2881 # mostly because it checks command line and nix append -isystem and all doCheck = false; </del> <ins> doCheck = true; </ins> strictDeps = true; <del> # -E exclude 4 tests based on names # see https://github.com/CastXML/CastXML/issues/90 checkPhase = '' runHook preCheck ctest -E 'cmd.cc-(gnu|msvc)-((c-src-c)|(src-cxx))-cmd' runHook postCheck ''; </del> <ins> passthru.tests = testers.testVersion { package = finalAttrs.finalPackage; }; </ins> meta = { homepage = "https://github.com/CastXML/CastXML";

Discussion:
Sometime between 23.11 and now, the binary broke due to a linking issue. Steps to reproduce the behavior:
fixes it of course, but I don't see an obvious less brutal approach.
adding to the works for me.
Good point, somehow thought this was already the case. PR up.
Change:
comment = "Code Editing. Redefined."; genericName = "Text Editor"; exec = "${executableName} %F"; <del> icon = "code"; </del> <ins> icon = "vs${executableName}"; </ins> startupNotify = true; startupWMClass = shortName; categories = [ "Utility" "TextEditor" "Development" "IDE" ];

Discussion:
VSCode/VSCodium's desktop icon (specified in the file) is set to . On the icon theme (the default dark icon theme that comes with Budgie desktop on NixOS), this makes it look like a generic text editor, and not the respective application. The issue appears to arise from how both apps use the same desktop files that were inherited from :   NixOS w/ Budgie desktop Icon theme to Qogir/Qogir-dark VSCodium/VSCode app list VSCode should use the icon VSCodium should use the icon ! My NixOS install is running in a VMWare VM.
Change:
nativeBuildInputs = [ cmake pkg-config intltool gobject-introspection ]; propagatedBuildInputs = [ pcre util-linux libselinux libsepol ]; <ins> meta = { inherit (meta) maintainers license platforms ; description = "CD-ROM image access library"; homepage = "https://cdemu.sourceforge.io/about/libmirage/"; }; </ins> }

Discussion:
Steps to reproduce the behavior: cdemu/vhba on latest nixos-unstable Looks like there's a new vhba module version: <!-- 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]:
broken by
Change:
, libiconv, postgresql, v8_3_16_14, clang, sqlite, zlib, imagemagick , pkgconfig , ncurses, xapian_1_2_22, gpgme, utillinux, fetchpatch, tzdata, icu, libffi , cmake, libssh2, openssl, mysql, darwin, git, perl, gecode_3, curl <del> , libmsgpack, qt48, libsodium, snappy, libossp_uuid, lxc </del> <ins> , libmsgpack, qt48, libsodium, snappy, libossp_uuid, lxc, libpcap </ins> }@args: let

Discussion:
The metasploit package no longer builds. I've updating it myself, but I haven't been very successful. If someone could point out my mistake I would gladly correct it and submit a PR.
Is this issue still relevant? , (pinging you because you are able to close this if necessary)
Looks relevant to me, as there was no commit to metasploit that updates or fixes it. Why do you think I isn't relevant anymore?
Current version: 3.3.1 Last stable version: 4.12 We definitely need a maintainer. is there a tag for ?
Change:
postPatch = '' substituteInPlace audit.bash  <del> --replace 'python3' "${pythonEnv}/bin/python3" </del> <ins> --replace-fail 'python3' "${pythonEnv.interpreter}" </ins> substituteInPlace Makefile  <del> --replace "install --root" "install --prefix ''' --root" </del> <ins> --replace-fail "install --root" "install --prefix ''' --root" </ins> ''; outputs = [ "out" "man" ];

Discussion:
Steps to reproduce the behavior: X <!-- 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:
supportedLocales = mkOption { type = types.listOf types.str; <del> default = builtins.map (l: l + "/UTF-8") (unique ( </del> <ins> default = unique (builtins.map (l: (replaceStrings [ "utf8" "utf-8" "UTF8" ] [ "UTF-8" "UTF-8" "UTF-8" ] l) + "/UTF-8") ( </ins> [ "C.UTF-8" config.i18n.defaultLocale ] ++ (attrValues (filterAttrs (n: v: n != "LANGUAGE") config.i18n.extraLocaleSettings)) )); defaultText = literalExpression '' <del> builtins.map (l: l + "/UTF-8") (unique ( </del> <ins> unique (builtins.map (l: (replaceStrings [ "utf8" "utf-8" "UTF8" ] [ "UTF-8" "UTF-8" "UTF-8" ] l) + "/UTF-8") ( </ins> [ "C.UTF-8" config.i18n.defaultLocale

Discussion:
Steps to reproduce the behavior: the system with the config below This is where the error message comes from. But there hasnt been changed anything recently. nixos-channel UNSTABLE : (This configuration was created by the gui installer and worked fine so far.) If I change the locales to uppercase- Stings it also fails, but with a different error message:
I'm having the same problem
fixed this for me. However it is . In the meantime, you can try setting  manually like so:
It's in unstable now
I updated my system today and still had a similar error When rebuilding I got Full log: I found that in my configuration I have as opposed to Was the naming convention changed at some point?
Seems that glibc normalizes locale codeset names according to [this comment extracted from their codebase][glibc-norm]: Which means that setting and with worked fine before and . However, this is not the case with , since the name of the locale must match the values in [glibc localedata][glibc-supported] and as such anything other than variant will break. We should at least give a warning on and about these changes and the more strict codeset names needed. Since the error that is given to the user right now is not clear on what causes this. [glibc-norm]: ;a=blob;f=locale/programs/localedef.c;h=;hb=HEAD#l561 [glibc-supported]: ;a=blob;f=localedata/SUPPORTED;h=;hb=HEAD
Can confirm, had this happen right now as I tried on nixpkgs/master with some changes for my PR. Changing the capitalization fixed it.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
sha512 = "KI1+qOZu5DcW6wayYHSzR/tXKCDC5Om4s1z2QJjDULzLcmf3DvzS7oluY4HCTrc+9FiKmWUgeNLg7W3uIQvxtQ=="; }; }; <del> "mime-db-1.49.0" = { </del> <ins> "mime-db-1.50.0" = { </ins> name = "mime-db"; packageName = "mime-db"; <del> version = "1.49.0"; </del> <ins> version = "1.50.0"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/mime-db/-/mime-db-1.49.0.tgz"; sha512 = "CIc8j9URtOVApSFCQIF+VBkX1RwXp/oMMOrqdyXSBXq5RWNEsRfyj1kiRnQgmNXmHxPoFIxOroKA3zcU9P+nAA=="; </del> <ins> url = "https://registry.npmjs.org/mime-db/-/mime-db-1.50.0.tgz"; sha512 = "9tMZCDlYHqeERXEHO9f/hKfNXhre5dK2eE/krIvUjZbS2KPcqGDfNShIWS1uW9XOTKQKqK6qbeOci18rbfW77A=="; </ins> }; }; <del> "mime-types-2.1.32" = { </del> <ins> "mime-types-2.1.33" = { </ins> name = "mime-types"; packageName = "mime-types"; <del> version = "2.1.32"; </del> <ins> version = "2.1.33"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/mime-types/-/mime-types-2.1.32.tgz"; sha512 = "hJGaVS4G4c9TSMYh2n6SQAGrC4RnfU+daP8G7cSCmaqNjiOoUY0VHCMS42pxnQmVF1GWwFhbHWn3RIxCqTmZ9A=="; </del> <ins> url = "https://registry.npmjs.org/mime-types/-/mime-types-2.1.33.tgz"; sha512 = "plLElXp7pRDd0bNZHw+nMd52vRYjLwQjygaNg7ddJ2uJtTlmnTCjWuPKxVu6//AdaRuME84SvLW91sIkBqGT0g=="; </ins> }; }; "ms-2.0.0" = {

Discussion:
<!-- 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 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: cryptpad <!-- The current version can be found easily with the same process than 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: 4.9.0 desired version: 4.11.0 <!-- 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.
Change:
inherit (darwin.apple_sdk.frameworks) CoreServices; boost = boost173; # Configure checks for specific version. protobuf = protobuf3_7; <ins> icu =  icu67; </ins> }; mysql_jdbc = callPackage ../servers/sql/mysql/jdbc { };

Discussion:
Describe the bug mysql80 is failing to build To Reproduce latest nixpkgs-unstable ( as of this issue) -build -A mysql80 Expected behavior mysql80 should build successfully Additional context Failure is the following: Notify maintainers Metadata Maintainer information:
Looking online I think it has something to do with icu, but not sure. I tried the following patch: That did not work. Looks very similar to the issue described in
I see you are the maintainer for icu and the gentoo bug describes something that has changed as part of icu 68+
An easy fix would be to downgrade icu for now.
trying locally with icu67
surprised how it got past ofborg though.
Change:
ca = "/etc/nebula/ca.crt"; cert = "/etc/nebula/${name}.crt"; key = "/etc/nebula/${name}.key"; <del> listen = { host = "0.0.0.0"; port = 4242; }; </del> <ins> listen = { host = "0.0.0.0"; port = if (config.services.nebula.networks.smoke.isLighthouse || config.services.nebula.networks.smoke.isRelay) then 4242 else 0; }; </ins> }; } extraConfig

Discussion:
When a "lighthouse" and a regular "roaming" node are on the same network and the default value for () is used, nodes occasionally enter a consistent failure state while trying to connect. I suspect this occurs when Nebula tries to NAT-punch with the local router and always tries to connect to the lighthouse instead of the roaming node. Steps to reproduce the behavior: up a lighthouse node and roaming node -forward port 4242 for the lighthouse node to set a value for in the Nebula config intermittent failures The value of should be required, with a link to Nebula docs: I'm not entirely sure, but logs from the issue indicate the lighthouse-node handshakes are both sending packets to "192.168.1.1:4242", which is port-forwarded to the lighthouse (I'm in a dual-NAT setup unfortunately; this is the IP of the outer NAT). Explicitly setting the port to (to automatically select an ephemeral port) on the roaming nodes immediately fixes the issue. (wrote the initial module with the port default) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on those docs, I think we can solve this without requiring the user to specify the port. Since we know whether a node is a lighthouse via , we could implement a behavior where defaults to for lighthouses and for non-lighthouses: I'm not sure how to get the for this, though. Maybe if the options were , then we could just refer to ? We'd probably also want to include . Thoughts?
My thought is that a change should meet the following requirements: Per set and to something like:Set the actual value appropriately in the module with an expression like the above if the input is null. If (isLighthouse or isRelay) and the final port evaluates to 0, we should warn, since this config will probably result in connectivity issues. There should be a test for this. I am split on whether to backport this. While this is a bug, people may have relied on the default port to NAT port forward from routers to a Nebula node that is not a lighthouse or a relay.

As such the new default may impede connectivity on restrictive NATs, so this is also a breaking change.
Also, good job diagnosing this. I think I've run into this before but didn't know what was causing it.
Per (captured in + ) Given this, it is probably a good idea to both fix and backport this.
Change:
, xorgproto , coreutils # build options <del> , threadSupport ? stdenv.hostPlatform.isx86 , x11Support ? stdenv.hostPlatform.isx86 </del> <ins> , threadSupport ? (stdenv.hostPlatform.isx86 && ! stdenv.hostPlatform.isDarwin) , x11Support ? (stdenv.hostPlatform.isx86 && ! stdenv.hostPlatform.isDarwin) </ins> , dllSupport ? true , withModules ? [ "pcre"

Discussion:
Steps to reproduce the behavior: clisp Fail to build clisp on x86_64-darwin Please run and paste the result.
For context: afaik this was previously marked broken on all darwin systems, so this isn't a regression so much as "we could choose to mark x86_64-darwin broken again". It does work on aarch64-darwin.
Sorry, I wasn't clear. It fails at stage, where the derivation configures modules. I did succeed to build it with Is there any difference in the way to build the package in nixpkgs from this?
Sorry for removing the broken flag on x86_64 when I only tested aarch64.
This is one of those tooling issues IMO. I'm surprised we are allowed to merge PRs with broken builds like this without much noise from CI.
I've been taking a look at this and I think there are two problems: configure phase is failing early in nix build, but not when you run it yourself manually (try --it will get much further than a standard ). I'm not sure what the problem is here. you get past configure, actual build of clisp is still broken with all the currently enabled flags on x86_64-darwin. I have a fix for issue 1, which is cosmetic, but at least it makes the build in nixpkgs "fail consistently". :)
Fixed in .
I can confirm fixes it. Thanks everyone!
Change:
done ''; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Visual MySQL database modeling, administration and querying tool"; longDescription = '' MySQL Workbench is a modeling tool that allows you to design

Discussion:
Steps to reproduce the behavior: Stumbled upon this when upgrading my NixOS flake from to No maintainers so I'll just ping the last person to touch this <!-- 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]:
It broke in this PR merge Okay, the problem's with libxml2, which changed its interface a bit
Okay, I managed to fix the build, will open a PR shortly.
Thank you for writing the fix and creating the PR. Is something holding up the pull request? It's been open for over a week now.
I guess noone really reviewed the PR. I can maybe ask for a review.
I tried building mysql-workbench again today but it is still failing. Is it building properly for you? Or is it something on my end? output of
the pr that fixed this hasn't hit nixos-unstable yet, wait until it does. You can check here
Change:
nativeBuildInputs = [ pkg-config cmake ninja yasm ]; buildInputs = [ <del> libjpeg openssl libopus ffmpeg alsa-lib libpulseaudio protobuf </del> <ins> libjpeg libopus ffmpeg alsa-lib libpulseaudio protobuf </ins> openh264 usrsctp libevent libvpx libX11 libXtst libXcomposite libXdamage libXext libXrender libXrandr libXi glib abseil-cpp pcre util-linuxMinimal libselinux libsepol pipewire

Discussion:
On current , (4.2.4) group voice chat will be stuck on "connecting" forever, while private group voice works. This issue exists when connecting from different countries, using different account, with or without proxy, so it seems not really a "connection issue". a voice chat in a private group. it stuck on "connecting" phase forever. Successfully starts or joins a voice chat. chat and live stream are broken. (one to one) voice chat works without issues. 's version of telegram works. (Its font is broken though) Please run and paste the result.
Change:
pythonPackages = python3Packages; }; <ins> termius = callPackage ../applications/networking/termius { }; </ins> termplay = callPackage ../tools/misc/termplay { }; tewisay = callPackage ../tools/misc/tewisay { };

Discussion:
Project description I'm using Termius everyday because it is quite simple to easy and it allows me to share my ssh keys between my different computers and even my phone. I really like this app and it's possible to get the premium features for free with github student. Currently I have to restart to windows in order to use it and I would really like to be able to use it on nixos too :) Metadata homepage URL: source URL: this is closed source license: I'm not sure but I can ask them platforms: this is an electron app so there is a version for basically every systems
Duplicate of .

Project description A cross-platform SSH client with cloud data sync and more. Metadata homepage URL: source URL: license: unfree platforms: linux
It would be really cool, I need it too!