jiebi/CodeConvo huggingface dataset:
Change:
in callPackage pkg { nativeBuildInputs = [ intltool ]; buildInputs = [ glib libao libmirage ]; <ins> drvParams.postInstall = '' mkdir -p $out/share/dbus-1/services cp -R ../$pname-$version/service-example $out/share/cdemu substitute  $out/share/cdemu/net.sf.cdemu.CDEmuDaemon.service  $out/share/dbus-1/services/net.sf.cdemu.CDEmuDaemon.service  --replace /bin/true ${coreutils}/bin/true ''; </ins> }

Discussion:
There is no Dbus service file in the derivation outputs. This prevents from starting on demand. It works if it was started manually beforehand. Steps to reproduce the behavior: There should be a message about device slot 0 not loaded. But instead there is an error: This is a regression from at least NixOS 20.09 where this file was present. Apparently some defaults were changed since then.
Thanks for the report, I've also already wondered what broke ... I think what may have changed is that cdemu has stopped installing a service file. See Section 14 in Fortunately, it still provides , so it shouldn't be too hard to generate a service file on our own. From a quick glance, I see two ways: 1) rely on the nixos module, to have dbus activate a systemd service, as in the example 2) come up with a dbus - only solution, similar as before
Yes, according to its git history it was removed in cdemu-daemon 3.2.5. I believe this should be the most straightforward and flexible solution. Also, this is actually recommended by upstream.
Also an issue on my machine. !
Experiencing this as well. New to NixOS, so I'm not sure how much I could contribute to resolve this.
Just in case somebody stumbles upon this, to whom the workaround is not apparent, before a contributor got around to fixing this: After running in a separate terminal, you can use CDEmu normally.
I just got this problem too, tried starting cdemu-deamon manually, but then got: Not really sure what to try next :sweat:
that looks like you don't have the cdemu kernel module loaded. Do you have  and yourself to the group? Also check
Hey! Yes, I have and And: Not sure what this tells me though? Does that look OK?
Interesting. shows the module to be loaded, that's fine. So the command already shows you as part of and also is owned by group cdrom? And you still get permission denied?
should be owned by group and_ also have group permissions .
would appreciate if anybody could test the PR. there are issues with the tray icon not showing, due to xdg resources, but the dbus service should be functional now.

I have this exact issue on the Steam Deck...
Aight, so I thought I might chime into this issue for all those poor souls that have problems with this exact problem: And when you check with : Notice that is empty when it should be mapped to: Solution that worked for me: Check if you have any .conf files in that block , , , , modules from loading. This is common problem nowadays, because of kernel hardening and stuff, so people/distro packagers could disable those for this reason. Sorry for necrobumping, but this is the only github issue that somewhat references this error above.
Change:
in stdenv.mkDerivation rec { pname = "displaylink"; <del> version = "5.3.1.34"; </del> <ins> version = "5.4.0-55.153"; </ins> src = requireFile rec { name = "displaylink.zip"; <del> sha256 = "1c1kbjgpb71f73qnyl44rvwi6l4ivddq789rwvvh0ahw2jm324hy"; </del> <ins> sha256 = "1m2l3bnlfwfp94w7khr05npsbysg9mcyi7hi85n78xkd0xdcxml8"; </ins> message = '' In order to install the DisplayLink drivers, you must first comply with DisplayLink's EULA and download the binaries and sources from here: <del> https://www.displaylink.com/downloads/file?id=1576 </del> <ins> https://www.synaptics.com/node/3751 </ins> Once you have downloaded the file, please use the following commands and re-run the installation:

Discussion:
Describe the bug kernel module fails to build against . To Reproduce Steps to reproduce the behavior: something that depends on (e.g. , add to list) Expected behavior successfully rebuilds and kernel modules that are depending on are working as expected. Additional context It fails to build with (which refers to kernel version at the moment, and is pointing to this version) but successfully builds with for me. Here are logs chunks that have the information about the failure: 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 note that I’m using because I couldn’t build it with . system: host os: multi-user?: sandbox: version: channels(root): channels(wenzel): nixpkgs: The channel pin is: Maintainer information:
fixed in newer version of evdi.
appreciated if you have the time to test it out ;)
This should be merged now, please try again and reopen if the issue persists. :)
sorry, I was busy to test it, but I’m planning to. Do you know if this is going to be backported to ?
Sorry, I will reopen this again. Didn't think about 20.09. I will just check what the best way is to go about that :)
I have opened a backport PR, can you test it out?
Backported and everything, should work fine. Closing. Feel free to reopen if there is still a issue!
sorry, I didn’t have time to test this. Now tested against NixOS 20.09, it compiles with latest kernelPackages and works fine after restart :+1:
Change:
owner = "libfprint"; repo = pname; rev = "v${version}"; <del> sha256 = "0bqzxxb5iq3pdwdv1k8wsx3alirbjla6zgcki55b5p6mzrvk781x"; </del> <ins> sha256 = "sha256-XHfHPffVp0jV3Md9Gui9v/nyOJ/bTWM3+hiR7WdEsgQ="; </ins> }; nativeBuildInputs = [

Discussion:
Package fprintd doesn't build with the latest unstable (currently on commit ). With the following configuration, using ThinkPad X1 Carbon 7th gen: After a to the latest unstable, the compilation gives an error (): Please run and paste the result.
Change:
}; }; <ins> AlgorithmBackoff = buildPerlPackage { pname = "Algorithm-Backoff"; version = "0.009"; src = fetchurl { url = "mirror://cpan/authors/id/P/PE/PERLANCAR/Algorithm-Backoff-0.009.tar.gz"; sha256 = "9f0ffcdf1e65a88022d6412f46ad977ede5a7b64be663009d13948fe8c9d180b"; }; buildInputs = [ TestException TestNumberDelta ]; meta = { homepage = "https://metacpan.org/release/Algorithm-Backoff"; description = "Various backoff strategies for retry"; license = with lib.licenses; [ artistic1 gpl1Plus ]; }; }; </ins> AlgorithmC3 = buildPerlPackage { pname = "Algorithm-C3"; version = "0.11";

Discussion:
sqitchPg 1.3.1 package is missing some dependency: Algorithm::Backoff::Exponential module Steps to reproduce the behavior: 2 concurrent sqitch deployments on the same database Both deployments should succeed by having one wait and retry with exponential backoff. I used to run sqitchPg 1.1.0. After migrating to NixOS 23.05, I now use sqitchPg 1.3.1. Here is what happened: The logs indicates but if fails immediately. The error seem to indicates that it would have succeeded if was packaged with module . Destination locking was introduced in sqitch . Related PR (): <!-- 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.
Could you please try from ?
I use NixOps with flakes to deploy the machine on which I reported the problem. I am not sure of the nix way of testing but here is what I did: I can see that a new version of Sqitch was built and the test ran successfully:
Awesome. Thanks for checking that PR. So it seems that fixes closes this issue, right?
That is correct!
Thank you for fixing this!
Change:
<del> { lib, stdenv, fetchurl, aspell, pkg-config, glib, hunspell, hspell }: stdenv.mkDerivation rec { version = "1.6.1"; pname = "enchant"; src = fetchurl { url = "https://github.com/AbiWord/${pname}/releases/download/${pname}-1-6-1/${pname}-${version}.tar.gz"; sha256 = "1xg3m7mniyqyff8qv46jbfwgchb6di6qxdjnd5sfir7jzv0dkw5y"; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ aspell glib hunspell hspell ]; meta = with lib; { description = "Generic spell checking library"; homepage = "https://abiword.github.io/enchant"; platforms = platforms.unix; badPlatforms = [ "x86_64-darwin" ]; license = licenses.lgpl21; # never built on aarch64-darwin since first introduction in nixpkgs broken = stdenv.isDarwin && stdenv.isAarch64; }; } </del>

Discussion:
Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. &rarr;
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to
Change:
--replace 'lib/libphazor.so' '../../lib/libphazor.so' patchShebangs compile-phazor.sh <ins> substituteInPlace extra/tauonmb.desktop --replace 'Exec=/opt/tauon-music-box/tauonmb.sh' 'Exec=${placeholder "out"}/bin/tauon' </ins> ''; postBuild = ''

Discussion:
Hi, hope I have completed the correct fields! <!-- Initial version of 6.7.1 with updated version at 7.01 --- <!-- There is currently no PR in for this update. --- The Linux desktop music player from the future Name: tauonVersion: 6.7.1Licenses: nix-env -iA current version: 6.7.1 desired version: 7.0.1 HI any update to tauon if you have time, would be greatly appreciated :) I also do not get a tauon icon showing up in gnome 4.x.x and have to exec from the command line instead...wondered if this was by design :)
Tried it out and updated the derivation while at it. I don't think I'll be using this in the long run though, since it seems to have problems with wayland and replaygain inconsistencies between file formats.
I guess it doesn't show up in the gnome dashboard because the derivation does not install a desktop file. There seems to be one in the extra/ dir in the upstream repo but that needs some adapting to work on NixOS.
Thanks for trying, although it seems to be working fine on one of my arch machines running wayland? Don't use replaygain so can't comment. In what way does the desktop file need adjusting, as, in my experience, the tauon dev has been very receptive and amenable in the past. Is the way to test?
It mostly works but I have a mixed-DPI setup and running with the X11 backend in Xwayland is notoriously blurry on scaled monitors which is a bit annoying. The native wayland backend in SDL does not have that problem but SDL also does not handle DPI changes in any way so when moving between screens with different scaling factors, first the viewport goes out of sync with window size and once it relayouts itself it does not rescale for the new DPI. I reported the replaygain issue and that indeed got fixed in a matter of hours. I usually just fetch and build PRs manually but yes, from a glance at the docs seems to do all that in one command.
Thanks for creating heads up v7.1 out overnight if you still have the pull out
v7.1.1 is out and appears to have some of your requested changes included already ...
It indeed is:
Hope the new stuff works
Change:
blugon = callPackage ../applications/misc/blugon { }; <ins> bombadillo = callPackage ../applications/networking/browsers/bombadillo { }; </ins> bombono = callPackage ../applications/video/bombono {}; bomi = libsForQt5.callPackage ../applications/video/bomi {

Discussion:
Project description Bombadillo is a non-web browser for the terminal. It supports several protocols, such as gopher, gemini, and finger. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin
Change:
homepage = "https://espanso.org"; license = licenses.gpl3Plus; maintainers = with maintainers; [ kimat ]; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.unix; </ins> longDescription = '' Espanso detects when you type a keyword and replaces it while you're typing.

Discussion:
Trying to install espanso on osX, there are missing libraries, even after trying to install and Steps to reproduce the behavior: tries to compile fails with The build should work on osX n/a latest osX with nixpkgs 21.15 and nix-darwin Please run and paste the result.
You cannot install libraries (), they need to be to the package definition.
I tried adding them as dependencies, but the build still fails with the same error
I marked this as stale due to inactivity. &rarr;
Change:
let inherit (lib) lists strings trivial; <del> inherit (cudaPackages) cudatoolkit cudaFlags cudaVersion; </del> <ins> inherit (cudaPackages) backendStdenv cudaFlags cudaVersion; </ins> inherit (magmaRelease) version hash supportedGpuTargets; # NOTE: The lists.subtractLists function is perhaps a bit unintuitive. It subtracts the elements

Discussion:
Per , assuming NVIDIA continues with its current compute capability naming scheme, will run into issues with the launch of Blackwell. This is a followup from <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
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:
Change:
''; meta = { <del> description = "A Vulkan-based translation layer for Direct3D 9/10/11"; </del> <ins> description = "Setup script for DXVK"; </ins> homepage = "https://github.com/doitsujin/dxvk"; changelog = "https://github.com/doitsujin/dxvk/releases"; maintainers = [ lib.maintainers.reckenrode ];

Discussion:
In future releases of dxvk the setup script won't be included anymore so this issue is just to notify so something can be figured out for how the nix package should handle it beforehand. (Hope such an issue is okay) See
CC
Thanks for the heads up. The DLLs are already available via a output, but this will break anyone’s set up that relies on . A short term solution would be to vendor the script. Longer term, it would be ideal if there were a way to declaratively create and manage a Wine prefix.
1 has been released with the script removed
I saw that. It can also build natively on Linux, which is interesting. I need to think about how I want to do things and maybe see what other distributions that package it are doing.
God speed
There is a nix-gaming repository that contains such derivation: It also handles vkd3d-proton:
One approach I’m considering is splitting dxvk into dxvk110 (for Darwin and hardware no longer supported by 2.0) and dxvk2x (or just dxvk_2, not sure). The plain DXVK derivation could continue to provide the script (most likely copied from before upstream removed it) while the versioned ones would be built for the native platform only (Linux and Windows). Well, I guess if it builds on Darwin, I can set the platform to then mark it broken on Darwin. I doubt DXVK 2.0 will work on Darwin any time soon. There are a number of extensions DXVK needs that aren’t implemented yet in MoltenVK, and since DXVK is always adding and using new ones, it’s a moving target.
I created to add the script and bump DXVK. It also exposes native builds on Linux.
Change:
def __init__(self, outfile: str) -> None: self.logfile_handle = codecs.open(outfile, "wb") self.xml = XMLGenerator(self.logfile_handle, encoding="utf-8") <del> self.queue: "Queue[Dict[str, str]]" = Queue() </del> <ins> self.queue: Queue[dict[str, str]] = Queue() </ins> self._print_serial_logs = True

Discussion:
-build -A ! Logs: I'm out of context on this. This seems too fundamental to be broken. It is breaking all NixOS tests? Nginx test also fails the same. I could not build using: ! CC Update: Bisect answer was
!
Oh, that was quick, I'm still building ruff on my machine...
A solution has been found is preparing the PR.
Change:
unzip $out/lib/javafx-web-*.jar libjfxwebkit.so -d $out/lib/ DEFAULT_JVM_OPTS=$(sed -n -E "s/^DEFAULT_JVM_OPTS='(.*)'$/1/p" $out/bin/JabRef | sed -e "s|$APP_HOME|$out|g" -e 's/"//g') <ins> runHook postInstall ''; postFixup = '' </ins> rm $out/bin/* <ins> # put this in postFixup because some gappsWrapperArgs are generated in gappsWrapperArgsHook in preFixup </ins> makeWrapper ${jdk}/bin/java $out/bin/JabRef  "''${gappsWrapperArgs[@]}"  --suffix PATH : ${lib.makeBinPath [ xdg-utils ]} 

Discussion:
Regression: File open dialog again results in crash due to missing GSettings schema path. This was previously reported in and fixed in . Steps to reproduce the behavior: on "Open library" icon File open dialog opens. Please run and paste the result.
Change:
propagatedBuildInputs = [ self.qtbase.dev buildPackages.makeBinaryWrapper ] ++ lib.optional stdenv.isLinux self.qtwayland.dev; } ../hooks/wrap-qt-apps-hook.sh; <del> } // lib.optionalAttrs config.allowAliases { # remove before 23.11 overrideScope' = lib.warn "qt5 now uses makeScopeWithSplicing which does not have "overrideScope'", use "overrideScope"." self.overrideScope; </del> }; in makeScopeWithSplicing (generateSplicesForMkScope "qt5") (_: {}) (_: {}) addPackages

Discussion:
For a while now, gives me the trace warning: Not a big deal, but it'd be nice to fix that. Maybe ? as the Qt5 maintainer?
duplicate
Change:
buildInputs = [ rubyEnv rubyEnv.wrappedRuby rubyEnv.bundler ]; <ins> # taken from https://www.redmine.org/issues/33784 # can be dropped when the upstream bug is closed and the fix is present in the upstream release patches = [ ./0001-python3.patch ]; </ins> buildPhase = '' mv config config.dist mv public/themes public/themes.dist

Discussion:
Describe the bug Browsing a hg (mercurial) repository in a redmine project does not work. No repo functionality works when hg is used. To Reproduce Steps to reproduce the behavior: use of the redmine module a local hg repo to which redmine has access. redmine, go to the project settings page and add the local hg repo the repo name, or click on the "repository" tab of the project Now you get to see a 404 page. Expected behavior Normally you should be able to browse the repository. Logs This issue happens both in the current nixos release and in the unstable, but with different errors: In release 20.03 In unstable Additional context The python hg script that is shipped with redmine () seems to be incompatible with the python version is being used when it is called. Possible related upstream bug: Notify maintainers
I've never used so wouldn't know where to start. Can you provide some config that I can reproduce this with and maybe something will occur to me?
Not sure what I can give in terms of config. In order to reproduce you basically do the same as you would with git: And then add it as a repository in the redmine project config, like so: ! EDIT: Not sure if the path should or shoudn't include the at the end, but I didn't get it to work either way. If you then click on the repo link "hg", or on "repository" tab of the project you get: ! I then checked what the error log was with: The following archive has the state directory + also the repo directory as described above + , a database dump of the redmine mysql database (login: admin, password: testtest) To be honest I'm not sure if this can be solved in NixOS at all. We might just have to wait until compatibility with python3 is improved upstream.
Sounds like an upstream bug - have you tried reporting it upstream?
I think it's already reported: But I'll add a comment there linking back here... The patch posted there might solve the issue for us.
I created a draft PR for this, which I verified fixes this issue.

Though I don't know if we really want to carry around a patch ourselves until upstream fixes things... The current mercurial <-redmine situation can't really get any worse, and I don't think this patch can break anything else. But it might also be worth it to wait for a proper fix from upstream.
I think's fine to carry a patch until upstream fixes things if these two things are met: upstream is already aware of the patch - done our patch contains reference to the upstream bug report - not done, left you a suggestion in the PR - see
Change:
systemd.services.vmware = { description = "VMWare Guest Service"; wantedBy = [ "multi-user.target" ]; <ins> after = [ "display-manager.service" ]; unitConfig.ConditionVirtualization = "vmware"; </ins> serviceConfig.ExecStart = "${open-vm-tools}/bin/vmtoolsd"; };

Discussion:
The service seems to be executed before the module is loaded, causing automatic modeswitching not to be enabled. The following is seen in the : Restarting after login resolves the problem, as does adding the following to the guest's configuration: Steps to reproduce the behavior: a nix guest with X11 enabled in vmware fusion windowed mode, resize window by dragging appears stretched/blurry or centered in window (dependent on host configuration). Display resolution is automatically switched to match dimensions of window. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Hey, I'm no longer using VMware with NixOS, so would be great to find new maintainers for the vmware-guest and open-vm-tools. you've worked on vmware support recently. Would any of you be able and interested in taking over?
Change:
vdirsyncer ]; <del> patches = [ # Tests working with latest pytz version, https://github.com/pimutils/khal/pull/1183 (fetchpatch { name = "support-later-pytz.patch"; url = "https://github.com/pimutils/khal/commit/53eb8a7426d5c09478c78d809c4df4391438e246.patch"; sha256 = "sha256-drGtvJlQ3qFUdeukRWCFycPSZGWG/FSRqnbwJzFKITc="; excludes = [ "CHANGELOG.rst" ]; }) ]; </del> postInstall = '' # shell completions installShellCompletion --cmd khal 

Discussion:
Steps to reproduce the behavior: to the branch Please run and paste the result.
Now it doesn't build on unstable as well. This package is pretty fussy with recurring issues.
This is probably the upstream issue:
Note that this error was fixed by , this issue can probably be closed.
indeed succeeds. Upstream also has an open PR for this issue: Should we keep this issue open to undo when the upstream PR is merged or just close this issue here?
I think closing is fine.
It seems like it started to fail again, with a different set of tests: Maybe we should just disable testing on this package?
Now I have issue with not building either as a dependency. I've had tests disabled for a while to deal with the test failures and it's ran alright.
This is extra annoying because you can't override it with an overlay. because the Python packages use .
You can, using note: I had to add the same overlay for , since it also has problems with tests. Both problems seem to be caused by an update to package
was recently.
Should be fixed by