jiebi/CodeConvo huggingface dataset:
Code change:
stdenv.mkDerivation rec { pname = "authenticator"; <del> version = "4.1.6"; </del> <ins> version = "4.2.0"; </ins> src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "World"; repo = "Authenticator"; rev = version; <del> hash = "sha256-fv7Np3haRCJABlJocKuu+1jevHYrdo+VyiQBpRmHs2g="; </del> <ins> hash = "sha256-Nv4QE6gyh42Na/stAgTIapV8GQuUHCdL6IEO//J8dV8="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-8GddlDM1lU365GXdrKNhO331/y1p3Om5uZfVLy8TBGI="; </del> <ins> hash = "sha256-IS9jdr19VvgX6M1OqM6rjE8veujZcwBuOTuDm5mDXso="; </ins> }; nativeBuildInputs = [

Related discussion:
text: The application fails to start with the following error: Steps to reproduce the behavior: to run the application The application should start and work properly.
Same issue with  (
I was looking at fractal-next as well, and found possibly related - [HELP] "Failed to retrieve template child" for Rust 1.67.0-nightly - Dec 4, 2022 - closed with Fixed in 0.5.3 a day later.
Ah, I see. There is a related PR for Amberol:
What commit did you build from? I’d like to bisect
My first try of fractal-next was about a week ago and it was failing already. I've tried HEAD and branch () although I'm not entlrely sure is the correct way to refer to that branch.
if you’re updating the version to point to an unreleased version the should
Indeed, thanks. What I meant was that I'm not entirely sure that setting in to (via ) does indeed let me build from a branch. I could not find a definitive reference for that, but it seems to work. I've the rust backtrace to - Draft: general: Use AdwDualPaneView and AdwAdaptiveState_
Hi there :) This is an unfortunate gtk-rs bug, and there's nothing to do on the app side for this. In addition, draft MRs are not expected to be packaged. That MR in particular depends on unstable libadwaita features and unstable bindings.
Is the gtk-rs package version something I can control? I was under the impression that this is managed in . I understand the branches/merge-requests I tried are not to be packaged. I'm merely trying to get fractal-next to run at all, as element is unusable on my phone.
In it is the minimum version we want to use. The pinned version (the one that is compiled) is in , and it is currently  on . This issue should have been fixed in . I don't know much about packaging for Nix but looking at the diff you posted , have you tried with the whole commit hash? Also don't you need to update the sha256 hash?
We’re not building from , we’re building from . I’m gonna check if we can just bump the version in to and leave it at that.
(how naive of me.
Code change:
stdenv.mkDerivation rec { pname = "authenticator"; <del> version = "4.1.6"; </del> <ins> version = "4.2.0"; </ins> src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "World"; repo = "Authenticator"; rev = version; <del> hash = "sha256-fv7Np3haRCJABlJocKuu+1jevHYrdo+VyiQBpRmHs2g="; </del> <ins> hash = "sha256-Nv4QE6gyh42Na/stAgTIapV8GQuUHCdL6IEO//J8dV8="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-8GddlDM1lU365GXdrKNhO331/y1p3Om5uZfVLy8TBGI="; </del> <ins> hash = "sha256-IS9jdr19VvgX6M1OqM6rjE8veujZcwBuOTuDm5mDXso="; </ins> }; nativeBuildInputs = [

Related discussion:
text: maybe just building from is better)
Opened a PR that should solve this, assuming it's accepted. In the meantime you can use it in an overlay if you want a fix now.
You were right - thanks for the hint! - I was indeed still building fractal-next from before the fix :disappointed:
Code change:
'' # Following is required to prevent a build error: # ninja: error: '/nix/store/z8z04p0ph48w22rqzx7ql67gy8cyvidi-SDKs/MacOSX10.12.sdk/usr/include/mach/exc.defs', needed by 'gen/third_party/crashpad/crashpad/util/mach/excUser.c', missing and no known rule to make it <del> + (optionalString (lib.versionAtLeast qtCompatVersion "5.11") '' </del> <ins> + '' </ins> substituteInPlace src/3rdparty/chromium/third_party/crashpad/crashpad/util/BUILD.gn  --replace '$sysroot/usr' "${darwin.xnu}" <del> '') </del> <ins> '' </ins> + '' # Apple has some secret stuff they don't share with OpenBSM substituteInPlace src/3rdparty/chromium/base/mac/mach_port_broker.mm 

Related discussion:
text: Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.
Code change:
postPatch = '' # relax version bounds <del> sed -i 's/([A-z0-9]*)~=.*$/1/' setup.cfg </del> <ins> sed -i -E 's/([A-z0-9]*)~=[^;]*(.*)/12/' setup.cfg </ins> ''; <del> propagatedBuildInputs = with python3.pkgs; [ bitmath certifi cheroot cryptography filetype flask flask-babel flask-caching flask-compress flask-session flask-themes2 js2py pycurl semver setuptools ]; </del> <ins> dependencies = with python3.pkgs; [ bitmath certifi cheroot cryptography filetype flask flask-babel flask-caching flask-compress flask-session flask-themes2 pycurl semver setuptools ] ++ (if pythonOlder "3.12" then [ js2py ] else [ dukpy ]); </ins> <del> passthru = { optional-dependencies = { plugins = with python3.pkgs; [ beautifulsoup4 # for some plugins colorlog # colorful console logging pillow # for some CAPTCHA plugin send2trash # send some files to trash instead of deleting them slixmpp # XMPP plugin ]; }; </del> <ins> optional-dependencies = { plugins = with python3.pkgs; [ beautifulsoup4 # for some plugins colorlog # colorful console logging pillow # for some CAPTCHA plugin send2trash # send some files to trash instead of deleting them slixmpp # XMPP plugin ]; }; </ins> <del> tests = { inherit (nixosTests) pyload; }; </del> <ins> passthru.tests = { inherit (nixosTests) pyload; </ins> }; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Free and open-source download manager with support for 1-click-hosting sites"; homepage = "https://github.com/pyload/pyload"; <del> license = licenses.agpl3Plus; maintainers = with maintainers; [ ruby0b ]; </del> <ins> license = lib.licenses.agpl3Plus; maintainers = with lib.maintainers; [ ruby0b ]; </ins> mainProgram = "pyload"; }; }

Related discussion:
text: Steps to reproduce the behavior: pyload-ng <!-- 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]:
Thank you for notifying me, the failure is caused by the lib not yet working on python 3.12. Apparently the git upstream of pyload replaced it with which I'm packaging in , so once that's done I'll get around to updating pyload (will probably have to switch to the git version since they rarely upload new releases to pypi). For now you can override the python version as a workaround:
The override works great. Thanks!
Code change:
thrift beautifulsoup4 markdown2 <del> sqlalchemy7 </del> <ins> sqlalchemy </ins> html2text evernote ];

Related discussion:
text: To make sure that we are on the same page: Kernel: System: Nix version: Nixpkgs version: broke legacy packages (only tested with the -set). Multiple options to solve this: revert the commit (an update will eventually have to be done) make sure no-one depends on sqlalchemy legacy versions (this would be the best choice, but can require a big amount of work) re-introduce an outdated version only used by legacy version (I’ll prepare a PR shortly that follows this path) cc
To be complete, the build problem is a test failure: I also checked, we cannot downgrade sqlite only for few pythonPackages, the entire python (and package set) have to be changed. Any preferred way to go?
(We should check if we still need this version, have it removed locally for virtmanager, virtinst as it isn't used, but haven't had the time to push that)
Yes, this is the preferred way to go. I began that but did not finish it yet, and it impacts some important parts (it causes xen to fail) I would prefer not to break because of unsufficient testing from me. This is in progress but could require some time to complete.
FYI xen already fails on
FYI: I switched away from sqlalchemy7 in yesterday.
Apart from virtinst, acd_cli, beaker, coilmq, and geeknote are the only revdeps of sqlalchemy7, as far as I can tell.
I openned to do some cleanup on sqlalchemy7. There still is that explicitly require . The same work will have to be done for and .
This should have remained open.
Using an older version of sqlite requires overriding the derivations of the interpreters.
See
Code change:
if (scalar (keys %unitsToStop) > 0) { print STDERR "stopping the following units: ", join(", ", @unitsToStopFiltered), "n" if scalar @unitsToStopFiltered; <del> system("systemctl", "stop", "--", sort(keys %unitsToStop)); # FIXME: ignore errors? </del> <ins> # Use current version of systemctl binary before daemon is reexeced. system("/run/current-system/sw/bin/systemctl", "stop", "--", sort(keys %unitsToStop)); # FIXME: ignore errors? </ins> } print STDERR "NOT restarting the following changed units: ", join(", ", sort(keys %unitsToSkip)), "n"

Related discussion:
text: When executing switch-to-configuration in a pure environment it fails: I am calling switch-to-configuration via systemd-run to active a new profile using the Hail update tool. The actual executed script is as follows: Actual output: <preactivating the configuration... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up /etc... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up tmpfiles Too few arguments. sh: systemctl: command not found </preThe script works if I pass on the PATH and LOCALE_ARCHIVE environment variables: System: (NixOS: 17.09pre-git (Hummingbird)) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: nixos-unstable (Commit ) Sandboxing enabled: no (Related Hail issue: )
Code change:
{ lib <ins> , stdenv </ins> , buildPythonPackage , fetchFromGitHub , fetchurl

Related discussion:
text: Steps to reproduce the behavior: -env -iA (full output here: ) 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.
The error is not in pgcli but in psycopg which tries to import a .so which does not work under darwin.
Code change:
massren = callPackage ../tools/misc/massren { }; <ins> mat2 = with python3.pkgs; toPythonApplication mat2; </ins> maxcso = callPackage ../tools/archivers/maxcso {}; medusa = callPackage ../tools/security/medusa { };

Related discussion:
text: Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection
Code change:
<del> { lib, stdenv, pkgs, fetchurl, wrapGAppsHook, gvfs, gtk3, atomEnv }: </del> <ins> { lib, stdenv, pkgs, fetchurl, wrapGAppsHook, glib, gtk3, atomEnv }: </ins> let versions = {

Related discussion:
text: Describe the bug It is not possible to delete files in atom. To Reproduce Steps to reproduce the behavior: to delete a file Expected behavior This action should not result in an error. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
gvfs-trash has been removed for a few years () after several years of deprecation period. For the atom issue, this is likely a duplicate of
Ah thank you for this, I will update the title and description accordingly
You can try installing globally. That contains command, which is ’s successor and most programs support it. Not sure about Atom though.
Code change:
, libpng, glib, lvm2, libXrandr, libXinerama, libopus, qtbase, qtx11extras , qttools, qtsvg, qtwayland, pkg-config, which, docbook_xsl, docbook_xml_dtd_43 , alsa-lib, curl, libvpx, nettools, dbus, substituteAll, gsoap, zlib <ins> , fetchpatch </ins> # If open-watcom-bin is not passed, VirtualBox will fall back to use # the shipped alternative sources (assembly). , open-watcom-bin

Related discussion:
text: Virtualbox corrupts guest filesystems by randomly flipping bits when the guest writes data to the virtual hard disks. virtualbox on the host with a new virtual machine for linux 2.6/3.x/4.x with default settings (1GiB RAM, 8GiB harddisk). "Insert" a linux live medium into the virtual CD drive. The virtual hard disk should be placed on a filesystem on a physical hard disk (the bug cannot be triggered if the virtual hard disk is placed on a tmpfs, see below). the machine and open a root shell after booting. these commands inside the guest's root shell to write random data onto the hard disk, then read it back and compare it: Caution: This will overwrite anything on the guest's virtual hard disk The shown hashes should match, but in 90% of test runs, they won't. This bug makes virtualbox quite unreliable: It is still possible to install NixOS inside a virtualbox, but during installation, Nix will report a couple of checksum failures, and sometimes the installation is to be tried more then once. After that, random failures of random programs occur. If btrfs is used, this will also complain about checksum errors. After observing this on my production machine with NixOS 22.05, I tried narrowing down the offending commit. To this end, I adapted the nixpkgs minimal live cd build recipe to build an image with virtualbox installed on it, and built this agains different nixpkgs versions. So most of my tests have been performed on a test machine booted from a usb flash drive. The offending commit seems to be . I guess that commit brings in some kernel patch, which is incompatible with the way virtualbox handles disk images. The bug occurs when the host's filesystem containing the disk image is or . In both cases, I tried with freshly created filesystems. The bug does not occur if the disk image is on (or it occurs with very low probablity). I haven't tried any other filesystems on the host. Just to be sure there isn't a general problem with virtualization: I failed to reproduce the bug with qemu and a qcow2 disk image. So it seems to be a virtualbox-only problem.
Code change:
, libpng, glib, lvm2, libXrandr, libXinerama, libopus, qtbase, qtx11extras , qttools, qtsvg, qtwayland, pkg-config, which, docbook_xsl, docbook_xml_dtd_43 , alsa-lib, curl, libvpx, nettools, dbus, substituteAll, gsoap, zlib <ins> , fetchpatch </ins> # If open-watcom-bin is not passed, VirtualBox will fall back to use # the shipped alternative sources (assembly). , open-watcom-bin

Related discussion:
text: I observed the bug on three different machines (two desktop machines with NixOS 22.05 and NixOS 21.11, and one laptop with NixOS 21.11). I was also able to reproduce the bug with a linux live cd inside the guest. So the bug can probably be triggered by any linux in the guest. I haven't, however, tried with anything else (e.g. Windows). I was also able to reproduce the bug with a live iso based on (currently ), i.e., with virtualbox 6.1.30 (as opposed to virtualbox 6.1.34 from , currently ). By default, the virtual disk controller has it's checkmark "Use Host I/O cache" turned off in the vm config dialog. Turning it on doesn't help (). I cannot reproduce the bug with these linux kernel versions (all checked with current ) (4.19.247) (5.4.198) (5.18.4) So users of these kernel branches are safe ... until the breaking kernel patch also reaches these branches. <details<summaryFor the record: This is the build recipe I'm using for the live iso</summary<p</p</detailsMaybe I can try to bisect inside the kernel sources, but the compile-reboot-test cycle is quite slow on my machine. Strangely, I cannot find any reports about similar behaviour. The closest report might be . It would be interesting for me if this bug can be reproduced/verified by someone else. I'm not sure if this should be considered a kernel bug (the kernel should probably not change the way disk writes are handled), or a virtualbox bug (at the moment I don't know of any other software affected). kernel maintainer team: virtualbox maintainer: (by the way: I'm surprised there's only one maintainer for virtualbox. Thanks for your good work, ; I'm a heavy user!) This is my production system, which also shows that bug. But I did most of the tests to reproduce the bug and narrow down the cause with live iso images based on current ().
I bisected the linux kernel tree to find as the cause for the guest data corruption. Googling the commit's hash leads to this issue in the VirtualBox bug tracker.
Code change:
, libpng, glib, lvm2, libXrandr, libXinerama, libopus, qtbase, qtx11extras , qttools, qtsvg, qtwayland, pkg-config, which, docbook_xsl, docbook_xml_dtd_43 , alsa-lib, curl, libvpx, nettools, dbus, substituteAll, gsoap, zlib <ins> , fetchpatch </ins> # If open-watcom-bin is not passed, VirtualBox will fall back to use # the shipped alternative sources (assembly). , open-watcom-bin

Related discussion:
text: According to the information therein, the bug only occurs on some CPU models. The issue there also contains two patches: from This one fixes the problem on linux 5.18. It got already included in nixpkgs' master branch with . It is on it's way to being backported to NixOS 22.05 with . Note that this patch contains several clauses and does not fix the problem on earlier LTS kernel versions. from This one fixes the problem on linux 5.18+, but also on LTS kernel versions. I tested the following combinations with (currently on , where VirtualBox 6.1.34 with and linux 5.15.51 are used by default): VirtualBox version & patch 5.18.8 -----------------------------:------: 6.1.34 + OK 6.1.34 + OK I also tested the following combinations with (currently on , where VirtualBox 6.1.30 and linux 5.15.49 are used by default): VirtualBox version & patch 5.18.6 -----------------------------:------------: 6.1.30 won't build 6.1.34 + OK 6.1.34 + OK To replace VirtualBox 6.1.30 with 6.1.34, I cherry-picked . All tests have been performed on an Intel Core i5-4460 as host, by repeatedly writing/reading 4GiB of random data onto/from a virtual hard disk. Based on these tests, I suggest to use VirtualBox 6.1.34 with the in NixOS 22.05 and in NixOS unstable, as currently, both channels will exhibit the bug in their default configurations (i.e., with kernel 5.15). I will submit a pull request for master shortly.
Code change:
This chapter describes tools for creating various types of images. </para> <xi:include href="images/appimagetools.xml" /> <del> <xi:include href="images/dockertools.xml" /> </del> <ins> <xi:include href="images/dockertools.section.xml" /> </ins> <xi:include href="images/ocitools.xml" /> <xi:include href="images/snaptools.xml" /> </chapter>

Related discussion:
text: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi I'd like to work in this issue. First one with documentation so I will probably need to understand a few things first.
Thanks, let us know if you need help!
Hi thanks for picking this up. Are you still working on this? If you're stuck, you could create a draft PR so someone can help, or if you've changed your mind that's also ok.
Hi Sorry for late reply. I worked a little bit, on and off during the holidays, I do not finished yet, I had some problems during the build of the documentation, but from what I read (pandoc output) I made some mistakes during the file conversion. For now, I didn't commit, It's on my personal computer only. As the week is a little difficult, I'll see if I finish it at the weekend. (Maybe I should have asked for this issue just now, just see 14 days ago and I was like "What ?! That was 2 weeks ago ?!" LOL) Thanks for asking!
Hi I followed your suggestion to create a draft PR, at the moment I'm stuck in two things, the first is how to create a note and the second reference errors during the build of the documentation. For the first, pandoc created notes with the following formats: , in this case I should use the default way to create notes in markdown (using ) or wrap this in docbook way? If I remove the references that generate the error below, I can verify that using the markdown format, this note is styled differently from the rest of the documentation. And for the build errors, here is log: For this I tried per but build fails with same error. Any help is appreciated.
Code change:
removeReferencesTo unzip ] <del> ++ optionals withQt5 [ wrapQtAppsHook ]; </del> <ins> ++ optionals withQt5 [ wrapQtAppsHook ] ++ optionals waylandSupport [ wayland wayland-protocols ]; </ins> enableParallelBuilding = true;

Related discussion:
text: Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
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:
Here is the updated wrap that also addresses the desktop file