jiebi/CodeConvo huggingface dataset:
Change:
<ins> { stdenv, fetchPypi, buildPythonPackage, tqdm }: buildPythonPackage rec { pname = "proglog"; version = "0.1.9"; src = fetchPypi { inherit pname version; sha256 = "13diln950wk6nnn4rpmzx37rvrnpa7f803gwygiwbq1q46zwri6q"; }; propagatedBuildInputs = [ tqdm ]; meta = with stdenv.lib; { description = "Logs and progress bars manager for Python"; homepage = https://github.com/Edinburgh-Genome-Foundry/Proglog; license = licenses.mit; }; } </ins>

Discussion:
is broken in current 19.03 nixpkgs: Attempt to build , this also fails if I pull in the with something like system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Seems like the package was updated in but the list of its dependencies was not. I fixed it in
Change:
dataDir = mkOption { type = types.path; default = "/var/lib/tayga"; <del> description = "Directory for persistent data"; </del> <ins> description = "Directory for persistent data."; </ins> }; tunDevice = mkOption { type = types.str; default = "nat64"; <del> description = "Name of the nat64 tun device"; </del> <ins> description = "Name of the nat64 tun device."; }; mappings = mkOption { type = types.attrsOf types.str; default = {}; description = "Static IPv4 -> IPv6 host mappings."; example = literalExpression '' { "192.168.5.42" = "2001:db8:1:4444::1"; "192.168.5.43" = "2001:db8:1:4444::2"; "192.168.255.2" = "2001:db8:1:569::143"; } ''; </ins> }; }; }; config = mkIf cfg.enable { <ins> assertions = [ { assertion = allUnique (attrValues cfg.mappings); message = "Neither the IPv4 nor the IPv6 addresses must be entered twice in the mappings."; } ]; </ins> networking.interfaces."${cfg.tunDevice}" = { virtual = true; virtualType = "tun";

Discussion:
When using the provided tayga service, it's not really possible to setup explicit mappings. This seems like an oversight. N/A Some sort of should exist. N/A It is possible to workaround the issue by sticking them into but... uh yeah anyway. :sweat_smile: <!-- 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:
yambar = callPackage ../applications/misc/yambar { }; <ins> yambar-hyprland-wses = callPackage ../applications/misc/yambar-hyprland-wses { }; </ins> polyphone = libsForQt5.callPackage ../applications/audio/polyphone { }; portfolio = callPackage ../applications/office/portfolio {

Discussion:
Project description Enable to show workspaces. Metadata homepage URL: source URL: license: mit apache platforms: linux
I'm using Yambar on the unstable version with the + It's displaying workspaces correctly.
Thank you, didn't think to check unstable :~)
Ah I think I forgot what this issue was about, I'm looking specifically for packaging of a rust binary that listens for workspace info from hyprland's IPC.
Alright, I'm currently working on it. !
TYVM!
Change:
<del> diff --git a/packages/flutter_tools/lib/src/flutter_cache.dart b/packages/flutter_tools/lib/src/flutter_cache.dart index 252021cf78..e50ef0885d 100644 --- a/packages/flutter_tools/lib/src/flutter_cache.dart +++ b/packages/flutter_tools/lib/src/flutter_cache.dart @@ -51,14 +51,6 @@ class FlutterCache extends Cache { registerArtifact(IosUsbArtifacts(artifactName, this, platform: platform)); } registerArtifact(FontSubsetArtifacts(this, platform: platform)); -    registerArtifact(PubDependencies( -      logger: logger, -      // flutter root and pub must be lazily initialized to avoid accessing -      // before the version is determined. -      flutterRoot: () => Cache.flutterRoot!, -      pub: () => pub, -      projectFactory: projectFactory, -    )); } } </del>  No newline at end of file

Discussion:
Package name: flutter Latest released version: 3.24.1 <!-- Search your package here: --- Current version on the unstable channel: 3.22.2 Current version on the stable/release channel: 3.22.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
CC
Already being done

Package name: flutter (stable, but also beta) Latest released version: 3.24.0 <!-- Search your package here: --- Current version on the unstable channel: 3.22.2 (beta version: 3.23.0) Current version on the stable/release channel: 3.22.0 <!-- 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]:
CC has been a blocker for updates since it affects the update script but it is close to being ready.
Hmm, hopefully this can be resolved soon, as it's quite critical for my work.
Yeah, I hope to have it done soon. It's close. Unfortunately, I just don't always have enough time.
Yeah, of course! Take your time :)
Hey, since the blocker is merged, how is it looking with updating the flutter version? :) No worries, if you're too busy right now
I plan on doing that on my next day off work which will be Thursday.
Change:
let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.1.4"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {

Discussion:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Change:
<ins> { cabal, blazeHtml, blazeMarkup, cmdargs, deepseq, filepath, hjsmin , indents, json, mtl, pandoc, parsec, shakespeare, text , transformers }: cabal.mkDerivation (self: { pname = "Elm"; version = "0.8.0.3"; sha256 = "0zai8glmkiqramivgz405zh385cz166gpry2yl29g37dxpwxffzb"; isLibrary = true; isExecutable = true; buildDepends = [ blazeHtml blazeMarkup cmdargs deepseq filepath hjsmin indents json mtl pandoc parsec shakespeare text transformers ]; meta = { homepage = "http://elm-lang.org"; description = "The Elm language module"; license = self.stdenv.lib.licenses.bsd3; platforms = self.ghc.meta.platforms; }; }) </ins>

Discussion:
Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:
Change:
description = "Functional sed for JSON"; maintainers = with lib.maintainers; [ fgaz ]; homepage = "https://github.com/chrisdone/jl"; <del> # jl needs to be updated to work with aeson-2.0. # As far as I can tell, there is unfortunately no where to report issues upstream # for us to be able to track when upstream adds aeson-2.0 support. hydraPlatforms = lib.platforms.none; broken = true; </del> }

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
Thank you for reporting this issue; I can reproduce it. The problem is not in the warning displayed in the last 10 log lines, but in an earlier error: Unfortunately I don't think that I will be able to contribute further to this issue.
I'm aware of this failure, but fixing it will require a bit of patching. Upstream didn't update the package to ghc 9 yet. Right now I don't have much time to do that, so in the meantime you could install it from stable, where it does build. Please change the title to something like "jl: build failure due to ghc 9"
This has been correctly marked broken in . See also where there was a small amount of discussion about marking this broken.
I've created an upstream .
The PR is now merged, and the package is now on Hackage for the first time. However, since it's not been to Stackage Nightly yet, it won't make its way into for quite some time. I'll update the derivation to use the new version directly from Hackage.
Change:
}: let <del> version = "0.92.1"; </del> <ins> version = "0.93.0"; </ins> in rustPlatform.buildRustPackage {

Discussion:
Package name: nushell Latest released version: 0.93.0 <!-- Search your package here: --- Current version on the unstable channel: 0.92.1 Current version on the stable/release channel: 0.87.0 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looks like I was mentioned, or not..... :)
Thanks for the update! In it says without the r in the middle. Maybe you should correct that.
Sorry that was a bad joke ;) Nope, it's not a mistake. is indeed a maintainer of this package. Their last update package update () was 3 years ago, back in April 2021. Their last PR to Nixpkgs was in Nov 2021. They still seem to be active in Nixpkgs in reviewing PRs (last review being in February this year). I happened to see this update request and decided to make a PR :)
Change:
{ stdenv, lib, tlpdb, bin, tlpdbxz, tl , installShellFiles , coreutils, findutils, gawk, getopt, ghostscript_headless, gnugrep <del> , gnumake, gnupg, gnused, gzip, ncurses, perl, python3, ruby, zip </del> <ins> , gnumake, gnupg, gnused, gzip, html-tidy, ncurses, perl, python3, ruby, zip </ins> }: oldTlpdb:

Discussion:
I'm trying to produce html and epub files from a LaTeX document with the ht tools and it looks like they don't work properly. Given the following simple input, with a PDF file , the commands and give the following errors In both cases the output is produced, but the image is missing. <!-- 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.
How did you install TeXLive / which version of TeXLive do you have installed? It looks like you have 2 commands missing: and . I ran the same commands (on your test file) and only got the second error which was easily fixed for me by installing the package from the repos (seems to be an optional dependency, so not part of TeXLive per se). seems to be part of all the current unstable TeXLive packages, but none of the 23.05 TeXLive packages.
Indeed I'm on the 20.05 channel. I installed with the following in my NixOS is not a problem, as you mentioned. It's just that causes the problem. The TeXLive version is (in nixpkgs). I see the following in the store .
Ok thanks. Just to confirm, are you on or did you mean to say ?
Yes, sorry. I'm on .
cc this must have been fixed by the recent changes to scripts packaging? Is this is a wontfix for 23.05?
The script should work now on unstable, I see listed among the binaries on However is most likely an external dependency that must be to the path via .
PS: I'll try slip an extra link in the 23.05 , since 23.11 is still some time away. (It should be enough to add to the loop that reads from – not in directly as it would cause a useless rebuild – so if somebody has a moment to do it before me, go ahead!)
Thanks for the rapid fix!
Change:
sha256 = "1x9sybknzsfxp9z0pvw9dx80732ynyap57y03p7xwwjbcrnjla57"; }; <ins> dontWrapGApps = true; </ins> # there is also a build.gradle, but it only seems to be used to vendor 3rd party libraries # and is not able to build the application itself buildPhase = ''

Discussion:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.
Change:
lib = gcc_multi_sysroot; }; } '' <del> mkdir -p $out/lib/gcc </del> <ins> mkdir -p $out/lib{,64}/gcc </ins> <del> ln -s ${combine gcc64}/lib/gcc/* $out/lib/gcc/ </del> <ins> ln -s ${combine gcc64}/lib/gcc/* $out/lib64/gcc/ </ins> ln -s ${combine gcc32}/lib/gcc/* $out/lib/gcc/ # XXX: This shouldn't be needed, clang just doesn't look for "i686-unknown" ln -s $out/lib/gcc/i686-unknown-linux-gnu $out/lib/gcc/i686-pc-linux-gnu

Discussion:
Describe the bug Currently on a local checkout of , is incapable of linking i686 code. If attempting to do so, finds only the x8664 variants of some of the crucial compiler dependencies. I think this is a relevant failure, started failing 2020-07-03. To Reproduce Steps to reproduce the behavior: to build a 32-bit binary in a derivation via (specifically this stdenv, not just ) Linker will be unable to find any of the gcc dependencies (, , , , …) Expected behavior The code compiles fine without any problems. () Screenshots (Code is a derivation I've been working on, shouldn't matter for this bug.) ! Additional context Fetching a shell with and running the same command works fine. Notify maintainers Don't know who or what broke it, only that it did break at some point. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(bt1cn): nixpkgs: (I know I should update my system) Maintainer information:
I've also encountered this problem, but I switched to and forgot about it.
It's unfortunately not that easy for my use case, I am trying to package something that specifically requires Clang capable of linking both 64-bit and 32-bit code. I rebased my derivation on a checkout of (last known-good commit for this test) and the build indeed progresses past the first 32-bit linking. I'll try to figure out the exact commit that broke this when I have abit more time at hand.
Oh sorry, I meant that I forgot to report an issue because I found a workaround. I didn't mean to suggest it as a solution. I would still prefer to use so I will spend some time looking into this too.
Been running a git bisect since yesterday, still need to do the final build but it seems like it's homing in on being the breaking commit.
Bisect indeed blames . CC because you committed it, can you take a closer look at this?
Yes this is my fault and I need to fix it.
Has there been any progress on fixing this? It would be great to have working again before the 20.09 release.
I found to be the first commit introducing the break.
I marked this as stale due to inactivity.

&rarr;
Still broken, see
Are there any updates on the issue or what we could do to help speed up the development of a fix? For reference, I have tried to use from the current master branch: EDIT: Referencing in
The following patch fixes the issue but we are currently working on a refactoring of the multilib wrappers in .
can you please test the PR and confirm if it fixes the issue on your end? Thank you!
Change:
++ optional (withOVMF) "--with-system-ovmf=${OVMF.fd}/FV/OVMF.fd" ++ optional (withInternalOVMF) "--enable-ovmf"; <del> patches = [ (xsaPatch { name = "213-4.8"; sha256 = "0ia3zr6r3bqy2h48fdy7p0iz423lniy3i0qkdvzgv5a8m80darr2"; }) (xsaPatch { name = "214"; sha256 = "0qapzx63z0yl84phnpnglpkxp6b9sy1y7cilhwjhxyigpfnm2rrk"; }) (xsaPatch { name = "217"; sha256 = "1khs5ilif14dzcm7lmikjzkwsrfzlmir1rgrgzkc411gf18ylzmj"; }) (xsaPatch { name = "218-4.8/0001-gnttab-fix-unmap-pin-accounting-race"; sha256 = "0r363frai239r2wmwxi48kcr50gbk5l64nja0h9lppi3z2y3dkdd"; }) (xsaPatch { name = "218-4.8/0002-gnttab-Avoid-potential-double-put-of-maptrack-entry"; sha256 = "07wm06i7frv7bsaykakx3g9h0hfqv96zcadvwf6wv194dggq1plc"; }) (xsaPatch { name = "218-4.8/0003-gnttab-correct-maptrack-table-accesses"; sha256 = "0ad0irc3p4dmla8sp3frxbh2qciji1dipkslh0xqvy2hyf9p80y9"; }) (xsaPatch { name = "219-4.8"; sha256 = "16q7kiamy86x8qdvls74wmq5j72kgzgdilryig4q1b21mp0ij1jq"; }) (xsaPatch { name = "220-4.8"; sha256 = "0214qyqx7qap5y1pdi9fm0vz4y2fbyg71gaq36fisknj35dv2mh5"; }) (xsaPatch { name = "221"; sha256 = "1mcr1nqgxyjrkywdg7qhlfwgz7vj2if1dhic425vgd41p9cdgl26"; }) (xsaPatch { name = "222-1"; sha256 = "0x02x4kqwfw255638fh2zcxwig1dy6kadlmqim1jgnjgmrvvqas2"; }) (xsaPatch { name = "222-2-4.8"; sha256 = "1xhyp6q3c5l8djh965g1i8201m2wvhms8k886h4sn30hks38giin"; }) (xsaPatch { name = "224-4.8/0001-gnttab-Fix-handling-of-dev_bus_addr-during-unmap"; sha256 = "1k326yan5811qzyvpdfkv801a19nyd09nsqayi8gyh58xx9c21m4"; }) (xsaPatch { name = "224-4.8/0002-gnttab-never-create-host-mapping-unless-asked-to"; sha256 = "06nj1x59bbx9hrj26xmvbw8z805lfqhld9hm0ld0fs6dmcpqzcck"; }) (xsaPatch { name = "224-4.8/0003-gnttab-correct-logic-to-get-page-references-during-m"; sha256 = "0kmag6fdsskgplcvzqp341yfi6pgc14wvjj58bp7ydb9hdk53qx2"; }) (xsaPatch { name = "224-4.8/0004-gnttab-__gnttab_unmap_common_complete-is-all-or-noth"; sha256 = "1ww80pi7jr4gjpymkcw8qxmr5as18b2asdqv35527nqprylsff9f"; }) ]; </del> <ins> patches = with xsa; flatten [ XSA_231 XSA_232 XSA_233 XSA_234_48 XSA_236 XSA_237_48 XSA_238 XSA_239 XSA_240_48 XSA_241 XSA_242 XSA_243_48 XSA_244 XSA_245 ]; </ins> # Fix build on Glibc 2.24. NIX_CFLAGS_COMPILE = "-Wno-error=deprecated-declarations";

Discussion:
is no longer operational so the following expressions will break: System: 17.09.1789. (Hummingbird) Nix version: nix-env (Nix) 1.11.15 Nixpkgs version: 17.09.1789. Sandboxing enabled: build-use-sandbox = false
Change:
]; environment.variables = { <del> GTK_IM_MODULE = "fcitx"; QT_IM_MODULE = "fcitx"; </del> XMODIFIERS = "@im=fcitx"; QT_PLUGIN_PATH = [ "${fcitx5Package}/${pkgs.qt6.qtbase.qtPluginPrefix}" ]; <ins> } // lib.optionalAttrs (!cfg.waylandFrontend) { GTK_IM_MODULE = "fcitx"; QT_IM_MODULE = "fcitx"; </ins> } // lib.optionalAttrs cfg.ignoreUserConfig { SKIP_FCITX_USER_PATH = "1"; };

Discussion:
Upon login, Fcitx5 presents a popup notification telling me to unset and . This is specifically in the Plasma 6 (alpha) Wayland session. The environment variables appear to be set in the Fcitx5 NixOS module. also for ibus. I'm not sure if the other IMEs are supposed to work on Wayland at all. (nixos-unstable with Plasma 6 alpha from nix-community/kde2nix)
It's mostly impossible to detect if the user is currently using the plasma wayland session (unless with some custom profile scripts). Maybe we should add an option allowing disabling the automatic configuration of these environment variables.
FWIW Plasma 6 defaults the "plasma" session to wayland. The X11 session is renamed to "plasmax11". At least Plasma has some startup script generated by nix, I think at that point it might be known whether it is Wayland or not?
But users can still choose the session to use upon login right? However the current fcitx5 nixos module unconditionally sets these variables, without a runtime detection mechanism.
Is that possible to detect that at runtime, with something like ?
Well that's the part. But I'd rather let the users decide than trying to act smart. There are both pros and cons of using the immodules or not.
That's why I pointed out the startup script from the plasma module.
I mean it's not a must (or even should, IMO) that you unset and for the wayland session. The input method story is very complicated, with different applications/compositors/input methods supporting different protocols of varying compatibility and functionality. Setting these variables by default in most cases, won't worsen the situation. You may read https://fcitx- for some background.
Hmm, I see. Maybe they could be set with so users or other modules can easily override them?
Reasonable, but empty string and unset do have different meaning regarding these variables. So I think a blanket option to unset then entirely is more desirable.
Is there any temporary workaround? I can't find out how to unset it, I don't think there is way besides making it blank which might work?

I am confused as to how to get IME to work on Hyprland or Wayland at all though, if I can't get Japanese IME to work it's a complete deal breaker for me personally Edit, this worked for me personally. Using Fcitx on GTK crashes my Hyprland, but seems the QT one works fine? I am super confused now. But glad to see that IME support seems to be baked into Wayland itself somewhat I just hope it makes it work just as well as Windows in the far future: Also you will need this at the top of your file where you set it
If hyprland crashes, that's a hyprland issue, the fcitx5 gtk immodule works fine on most other platforms, such as sway.