jiebi/CodeConvo huggingface dataset:
Code change:
{ stdenv, fetchFromGitHub , autoreconfHook, docbook2x, pkgconfig , gtk3, dconf, gobject-introspection <del> , ibus, python3 }: </del> <ins> , ibus, python3, wrapGAppsHook }: </ins> stdenv.mkDerivation rec { <del> name = "ibus-table-${version}"; </del> <ins> pname = "ibus-table"; </ins> version = "1.9.21"; src = fetchFromGitHub {

Related discussion:
text: Input methods based on do not work as of , at least on my machine as it is now. Upstream, I think the change comes from , which made start using . Other IBus input methods still work (mozc, hangul, Anthy). It feels as if this should have an easy solution amounting to “do what worked for other packages using ”, but I can't work out what it is that they do that makes them work. It's also believable that from is not being run. 1) 2) Switch to an -base input method (example: from ). Then, the input method is not changed, and the rest of the output is: Alternatively: 1) 2) Try to open the preferences for an -based input method. No preferences are shown. The following error message is printed. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
So, adding to stops the error message, but preference dialogs still do not show and all of the problems with actually using remain.
How did you install and activate the input method? i18n.inputMethod.enabled = "ibus"; = with ; [ table ]; does not seem to be enough.
Change to (ibus-table acts like a framework within a framework, and provides some actual input methods using it). Then, use -Input Method -Add -More... -Others -IPA-X-SAMPA (and maybe another to see the switching behaviour). Then, switch using the key combination from the preferences (I forget what the default is; maybe Ctrl-space). Expected behaviour from IPA-X-SAMPA includes ↦ and ↦ .
Have you managed to reproduce this problem?
I can confirm your observations in Maybe this could be the culprit:
I've found what appears to be a solution, but it's in some sense weird. Looking at other input methods, they seem to use rather than . Replacing the latter with the former on seems to fix the issue. I have no idea, though, why isn't broken on other platforms. is the new package description.
Code change:
sha256 = sha256; }; <del> includeScript = pkgs.writeText "include.php" '' </del> <ins> prePatch = '' dos2unix ./rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php ''; patches = [ ./fix-cve-2022-29360.patch ]; postPatch = '' unix2dos ./rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php ''; includeScript = writeText "include.php" '' </ins> <?php /**

Related discussion:
text: via In short: rainloop, a php-based webmail client, features a trivially exploitable stored xss vulnerability. Upstream is unresponsive, and seem to have ceased development. This page explains how the XSS works and proposes an unofficial patch: Example of an other distro applying this very patch:
Code change:
{ lib, appimageTools, fetchurl, nodePackages }: let pname = "flexoptix-app"; <del> version = "5.11.0"; name = "${pname}-${version}"; </del> <ins> version = "5.12.1"; </ins> src = fetchurl { <del> name = "${name}.AppImage"; </del> <ins> name = "${pname}-${version}.AppImage"; </ins> url = "https://flexbox.reconfigure.me/download/electron/linux/x64/FLEXOPTIX%20App.${version}.AppImage"; <del> hash = "sha256-Nj6S53b4w84qppkGB7lMpJhJlxifaD4acPryuZxY7cM="; </del> <ins> hash = "sha256-ugnJcSFgEEPJ9qxqmRGgW1fraE4E/HbbxpK/00TXPmw="; </ins> }; udevRules = fetchurl {

Related discussion:
text: name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.
Code change:
in stdenv.mkDerivation rec { <del> srcVersion = "apr24a"; version = "20240401_a"; </del> <ins> srcVersion = "sep24a"; version = "20240901_a"; </ins> pname = "gildas"; src = fetchurl {

Related discussion:
text: Steps to reproduce the behavior: Add any other context about the problem here. <!-- 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]:
Code change:
LUA_PATH  = "${lgi}/share/lua/${lua.luaversion}/?.lua;;"; postInstall = '' <del> # Don't use wrapProgram or or the wrapper will duplicate the --search </del> <ins> # Don't use wrapProgram or the wrapper will duplicate the --search </ins> # arguments every restart mv "$out/bin/awesome" "$out/bin/.awesome-wrapped" makeWrapper "$out/bin/.awesome-wrapped" "$out/bin/awesome" 

Related discussion:
text: Cc: First of all, thanks to everyone for working on NixOS. Awesome 4.3 has a module called , it allows It can be used for theming, as shown in . However, the current build does not include the typelib files needed by the module making it unusable. The  implementation uses lgi to obtain via gobject-introspec return require('lgi').Gtk Since the current build does not include the typelib files needed, the above call fails. After some experimentation, I found out that both and are needed. For example: and try to load Gtk: fails with (the package that actually includes the typelib file) and add the folder to the environment variable: fails with and add it to and finally loads. Awesome as window manager to load the example gtk theme awesome the warnings issues by Awesome: I suggest that both and are as build inputs to the awesome package, I tried this out and it actually works. The catch is that the closure size increases by 123.9M: build awesome without gtk3-x11 and atk -99.6M build awesome with gtk3-x11 and atk -223.4M So, instead of adding the packages unconditionally, we could add an optional flag, like e.g. , defaulting to false. In this way, one could always build awesome and add it to . Ideally one could even add something like to the top level , a bit like : If a decision is made, I'd be happy to submit a PR. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: awesome 4.3 (Too long) Compiled against Lua 5.2.4 (running with Lua 5.2) D-Bus support: execinfo support: xcb-randr version: 1.6 LGI version: 0.9.2
It should not be necessary to use , should work just fine. See for docs on , which will populate the environment variable automatically.
Thanks, I'll have a look. For the record, I used because that's where told be the typelib files where. I am still keen on hearing what the correct solution would be regarding how to add support (closure size, optional arguments etc.). Thanks.
thanks for our suggestions.
Code change:
LUA_PATH  = "${lgi}/share/lua/${lua.luaversion}/?.lua;;"; postInstall = '' <del> # Don't use wrapProgram or or the wrapper will duplicate the --search </del> <ins> # Don't use wrapProgram or the wrapper will duplicate the --search </ins> # arguments every restart mv "$out/bin/awesome" "$out/bin/.awesome-wrapped" makeWrapper "$out/bin/.awesome-wrapped" "$out/bin/awesome" 

Related discussion:
text: Here are my thoughts: seems to work as well, the closure size is 222.9M instead of 223.4M seems quite conveniet, but awesome needs additional options in the wrapper and it's unclear to me whether we could do that after introducint uses that seems to have negative effects, see so we may have to look for alternative solutions anyway (Awesome does not seem to use much of GTK anyway as it's not a GTK app)
how could it shrink? can use as described in the doc PR to add more options. , I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment. See for deeper analysis.
¯()/¯ maybe it's got less dependencies built than the one? I see, I somehow missed that. It seems that works OK (I am using this in an overlay on NixOS waiting for the patches to land in the stable channel): In the end, AwesomeWM should not need the whole of gtk, I think that gtk should be made optional so one can turn it on or off. Thanks, I did notice that and I'll keep an eye on it
Code change:
++ cfg.sessionPath; # Fonts. <del> fonts.packages = mkDefault [ </del> <ins> fonts.packages = [ </ins> pkgs.noto-fonts pkgs.hack-font ];

Related discussion:
text: I enabled budgie: = true; I opened Budgie Desktop Settings. ! The font is "None", which is wrong. I expect a font be set. I am on a (neraly) freshly installed NixOS. It would be nice if a "Reset to default" button would be there (or some NixOS "magic" for configuring Budgie), but I did not found anything at Default fonts are listed at
Code change:
++ optional langAda ../gnat-cflags.patch ++ optional langFortran ../gfortran-driving.patch ++ optional (targetPlatform.libc == "musl") ../libgomp-dont-force-initial-exec.patch <del> ++ optional (!crossStageStatic && targetPlatform.isMinGW) (fetchpatch { url = "https://raw.githubusercontent.com/lhmouse/MINGW-packages/${import ../common/mfcgthreads-patches-repo.nix}/mingw-w64-gcc-git/9000-gcc-${majorVersion}-branch-Added-mcf-thread-model-support-from-mcfgthread.patch"; sha256 = "1c449jgm1vx9g4kv82bxmvlgrwb8f6kwkl0gqmjlmhf7f4hjy2nr"; }); </del> <ins> # Obtain latest patch with ../update-mcfgthread-patches.sh ++ optional (!crossStageStatic && targetPlatform.isMinGW) ./Added-mcf-thread-model-support-from-mcfgthread.patch; </ins> javaEcj = fetchurl { # The `$(top_srcdir)/ecj.jar' file is automatically picked up at

Related discussion:
text: Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Code change:
rustPlatform.buildRustPackage rec { pname = "fido2luks"; <del> version = "0.2.20"; </del> <ins> version = "0.2.21"; </ins> src = fetchFromGitHub { owner = "shimunn"; repo = pname; rev = version; <del> sha256 = "04gl7wn38f42mapmkf026rya668vvhm03yi8iqnz31xgggbr2irm"; </del> <ins> sha256 = "sha256-bXwaFiRHURvS5KtTqIj+3GlGNbEulDgMDP51ZiO1w9o="; </ins> }; <del> cargoPatches = [ #https://github.com/shimunn/fido2luks/pull/50 (fetchpatch { name = "libcryptsetup-rs.patch"; url = "https://github.com/shimunn/fido2luks/commit/c87a9bbb4cbbe90be7385d4bc2946716c593b91d.diff"; sha256 = "2IWz9gcEbXhHlz7VWoJNBZfwnJm/J3RRuXg91xH9Pl4="; }) ]; </del> <ins> nativeBuildInputs = [ pkg-config clang ]; </ins> buildInputs = [ cryptsetup ]; <del> nativeBuildInputs = [ pkg-config clang ]; </del> configurePhase = '' export LIBCLANG_PATH="${llvmPackages.libclang.lib}/lib" ''; <del> cargoSha256 = "U/2dAmFmW6rQvojaKSDdO+/WzajBJmhOZWvzwdiYBm0="; </del> <ins> cargoSha256 = "sha256-MPji87jYJjYtDAXO+v/Z4XRtCKo+ftsNvmlBrM9iMTk="; </ins> meta = with lib; { description = "Decrypt your LUKS partition using a FIDO2 compatible authenticator"; homepage = "https://github.com/shimunn/fido2luks"; <del> license = licenses.gpl3; </del> <ins> license = licenses.mpl20; </ins> maintainers = with maintainers; [ prusnak mmahut ]; platforms = platforms.linux; };

Related discussion:
text: The license listed for is incorrect. It has been re-licensed upstream: name: current version: desired version: n/a maintainers: Please tag this issue in your PR.
Fix in (which also updates the package)
Code change:
environment.systemPackages = [ pkgs.curl ]; }; traefik = { config, pkgs, ... }: { <del> docker-containers.nginx = { extraDockerOptions = [ </del> <ins> virtualisation.oci-containers.containers.nginx = { extraOptions = [ </ins> "-l" "traefik.enable=true" "-l" "traefik.http.routers.nginx.entrypoints=web" "-l" "traefik.http.routers.nginx.rule=Host(`nginx.traefik.test`)"

Related discussion:
text: Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
Code change:
makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Related discussion:
text: Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.
Code change:
makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Related discussion:
text: We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.
Code change:
makeFlags = let arch = head (splitString "-" stdenv.system); <del> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> march = { x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64"; i686 = "pentium4"; aarch64 = "armv8-a"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); # Julia requires Pentium 4 (SSE2) or better <del> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; }.${arch} </del> <ins> cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch} </ins> or (throw "unsupported architecture: ${arch}"); <del> # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM # https://github.com/JuliaLang/julia/tree/master/deps/patches </del> in [ "ARCH=${arch}" "MARCH=${march}"

Related discussion:
text: I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in .