jiebi/CodeConvo huggingface dataset:
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.
Describe the bug Seems like some updates to pango broke a few packages Among the broken ones: ettercap (see ) pangox-compat (which anydesk needs) probably a few more To Reproduce Steps to reproduce the behavior: to build ettercap or anydesk from master will fail to build with some pango-related errors Expected behavior It should work Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Also remmina is broken But doesn't seem to depend on pango directly, so unsure which dependency actually is broken
Here's an issue for pangox-compat
Lutris is broken too - not an urgent requirement but just making you fine folks aware!
Not sure why Lutris is broken, but Lutris-unwrap is fine.
It's a failure in the dependency chain, in this case .
no longer depends on on its master branch: We should probably switch to that. should not be needed in according to the README in , I suspect it was only there because we did not propagate it until ebassi also suggests switching to HEAD and says we need not worry about ABI changes:
Not having pangox_compat fixed is definitively still an issue. Can this be re-opened?
After , the only program depending on this is anydesk and openmodelica which is broken.
So it breaks anydesk thus either we mark anydesk as broken or we fix that?
Anydesk shouldn't use this deprecated library. Yes, we can mark it as broken.
<!-- 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 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: miller <!-- The current version can be found easily with the same process as 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: 5.10.3 desired version: 6.1.0 miller is now written in Go; there's still a configure script and a makefile, but I don't know if it's now more complicated to package because of fetching dependencies in a reproducible way or whatever. <!-- 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.
When I try to open a file dialog in Bitwig Studio 4.1.0 I am getting that error: I can manually start from command line and I'm seeing the file dialog and it returns the selected file. Unsure if this is of any use but is the decompiled class that calls . Steps to reproduce the behavior: bitwig (or open any other file dialog in bitwig) GTK file dialog opens Maintainer information: EDIT: more information
I am not a maintainer of bitwig sudio. Just because I changed some lines does not make me knowledgeable about this issue.
Sorry for that. I just did what the bug report template told me:
I played a little bit around with that problem. It seems to be connected to a change of to . further references: As a quick workaround you can launch the application with: is using an embedded version of java 16.
/cc
The cause may be here: We must not wrap :
Two ways to fix: Fix the embedded JDK. Replace the embedded JDK with package.
Thanks for having a look into this. I guess we should fix the embedded JDK as it's the way how it is shipped and it should be a compatible version. I tried to add to which does not improve the situation.
I tried to do the same thing and I noticed that the exact error message changed to: but I can still run . Not sure what that means. EDIT: I've found in another package that they do run patchelf on jspawnhelper. I've also this to the postFixup: and that made it work. Not sure if this is the most elegant way to do it but I can open a PR and we can discuss that there. Thanks :)
introduced systemd syscall filtering which seems overly restrictive for common use cases. We use for coverage reports of our Rust projects which makes use of the ptrace(2) system call (denied by ). Android projects commonly rely on which uses chown(2) (denied by ). In my opinion, those use cases are too common and should work out of the box. Also, workflow failures are difficult to debug if syscall filtering (or any hardening) steps in. I'd suggest to revise the syscall filtering: Also, it might help with debugging or employing a custom hardening configuration if we add a module option which defaults to . Please run and paste the result.
I agree that if the hardening make github-runner not to work as expected or as "standard" installation, we should remove them or make them optional with new option Do you want it to default to ? Maybe better with so it work as expected out of box?
also noted problems with makefile workflows in that I have been able to reproduce. I am sorry I did not catch this when making the changes originally. My usecase was running binaries on uncommon targets (e.g. ) connected over USB; and I only had light testing for other usecases. I have since a makefile test to the runner I use for testing package/module updates and will add a coverage workflow now too. I am ok with removing the harderning entirely, or making it more permissive. I only this because at the time I thought it would be a sane default for majority of applications. I would prefer we keep some hardening. Most people probably do not want a CI process to change the clock, hostname, or reboot the system entirely. I have been working on this in the background since reported issues; this is what I have come up with so far, I have not tested it with yet (will do that later this weekend); but it does allow and debug related tools such as to function. In addition to changes should also be changed to so that nix does not emit warnings when running.
:+1: :+1: Yes, all this hardening is already available and entirely optional! Every user is free to add anything to that they want.
I understand that NixOS developers are super keen on hardening, which is generally good, but for certain applications I just don't think it makes sense to go over the top... or even provide "curated" selections behind 'enableHardening' type flags. CI software is so broad I think we're providing more trouble and confusion than value here. My personal recommendation for this specific module is to follow what suggested as a reasonable default and let users decide any hardening they want for themselves. But I'm not the maintainer of this module in NixOS, just a user, so I defer to those who are volunteering their time to maintain this module :bowing_man:
PR to fix is here: Mentions do not generate notifications, just making a comment so that anyone subscribed to this issue gets a notification.
low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.
Hi, I'm a Keybase developer and some of our users reported that the Nix packages were out of date. Keybase 4.1.0 was released a while ago, so I believe these need to be updated: Additionally, the KBFS nix should point to the new remote, with , and be on the same version as the other packages (4.1.0). Please let me know if you have any questions, happy to answer! Thanks. N/A N/A
if the users are using the stable branch, then the update will need to be backported. Otherwise if they are unstable then it should be just a few short moments ;)
KBFS has not been updated as directed here.
Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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]:
After bisecting, first bad commit is (
System hangs during boot when the timer configured via fires during the boot sequence. option. option such that the timer will be due to run immediately upon the next reboot of the system. ; allow sufficient amount of time to pass. Boot the system, observe the system to hang during the boot sequence. system: host os: multi-user?: sandbox: version: channels(pbogdan): nixpkgs:
Does setting help?
but otherwise yes, it does help, thank you.
Hi, I reproduced this on 19.03 yesterday. The unit already contained , so it seems it is not sufficient to fix this. Some data about my system:
Package name: rnnoise Latest released version: 0.2 <!-- Search your package here: --- Current version on the unstable channel: 2021-01-22 Current version on the stable/release channel: 2021-01-22 <!-- 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. Tried building with but it got a missing file. There’s also warning about not using SSE3/AVX/AVX2, but Nix only supports the bottom of the barrel, common x86 instructions, but I usually compile this one out with some flags. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [^1] or offering a non-proprietary, non-US-corporate-controlled mirror for this free software project. I wish to delete this Microsoft account in the future, but I need more projects like this to support alternative methods to send patches & contribute.
The missing file is downloaded as part of the '' It looks like they a step to the build process.
Perhaps it can be fetched using fetchurl/fetchpatch?
You're correct. The relevant file is retrieved in the script . It fetches a single file from the URL , where the version is extracted from the file , currently set to . Hence, we can emulate the download script and execute something similar to:
Alternatively you could use instead of a separate model + . While we are at it, we should be using the main repository instead just Microsoft GitHub which is explicitly listed as a mirror, not the primary code forge. Something like Referencing both mirrors would be more resilient for when one of these platforms goes down.
Made a PR , but still having trouble designing a .
only returns the hostname, even when both and are set. Steps to reproduce the behavior: and . . should return the FQDN defined by and . The breakage happens when is used, which is now the default in NixOS after Stopping causes to return the correct value. reproduces the issue. It broke at , which is when became enabled by default. It's still broken on which is at time of writing. Possibly related issues:
This seems to happen because the resolution flow (when nscd is running) looks like: calls , which uses the nodename (), which is the short hostname then calls , which invokes the nss machinery gets the request and processes the request according to the NSS rules; on my NixOS system this is (from systemd) doesn't match (from systemd) does match, and returns a synthesized record; systemd internally determines the hostname for this using only the nodename, so unless the nodename is already the FQDN then we fail here, and it does this before checking /etc/hosts. I wonder if we can fix this by patching out the support in systemd-resolved for looking up the nodename, which will make it fall back to the result from /etc/hosts instead; on NixOS we can (probably) always assume that /etc/hosts will actually have the correct system hostname in it.
No, this is most likely We wanted to polish that PR in the next days, and once merged, bump our nixpkgs pin (and resurrect the upstreaming attempts). If you want, can you check if using nsncd from this PR fixes the problem for you?
Ah, actually, I think I'm just talking out of my ass. systemd-resolved seems to be able to cope with this properly when I query it over DNS, so it probably isn't to blame.
tests fail at that PR. Setting gets a successful build, which then passes the test in , but it fails on the test.
This is a pretty weird behavior. What's (likely) failing here is the IPv6 resolution of . The test does pass on some NixOS setup, like my desktop (and the Ubuntu CI) but does fail on my laptop. I'm still not sure what's happening, is present in .
In NixOS 22.05, the domain name is not set correctly when is set to . 1) It's working with IPv6: 2) .. but broken without: Obviously, it should work in both cases. The issue seems to be related to : also fixes the problem. Similar issues seem to have been discussed in , and , but it's still broken. Please run and paste the result.
I also seem to have hit this, but do not run , but a customized . I have however not tested removing , as my servers rely on the configuration section to run. Have a feeling it may be a fragile section when changes in happens. Also stopping solves it as well. Running nixos unstable.
I can reproduce this on nixos-unstable (without disabling IPv6), but also managed to get it working when stopping nscd. I found while googling around. And while points out a possible solution[^1], I did not find this to be working for me. [^1]: Effectively translating to
I've also encountered this issue, with the same reproduction and issues as Any idea how to resolve this? I particularly need to be able to set for containers using ...
FWIW, setting to seems to resolve this issue. cc
Hmm, this doesn't make too much sense - I'd assume and should behave the same when it comes to that. They're simply calling out to the same NSS modules to do the work. We do have which tests that works. It currently seems to be failing in the testcase, when run with nsncd, and succeeds when setting to . - cc Let's figure out this regression first, and not draw too early conclusions about this being a "IPv6 is disabled issue".
So, there's definitely something wrong with the current nsncd implementation. Dumping the Nscd socket, we can see that nsncd is lacking some getai entries. Entries that are probably used by hostname to get the FQDN: Let's track and fix this issue on the Nsncd repo.
Steps to reproduce the behavior: build .#fdroidserver Git bisect predictably found the culprit as , so it is related to the Python 3.12 upgrade. I suspect that all setuptools-based modules are broken; e.g. also stops building. Interestingly, built before, but not after. Not sure what that implies. (Originally I had notified the Python team, but I removed them from this list because I am suspecting this regression may not be the result of any problem with the version flip itself, but the broken packages instead. Sorry.) Notifying from fdroidserver maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Version 1.8.0 is available and . It looks like this should be a trivial bump in the luarocks csv. <!-- 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 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: <!-- The current version can be found easily with the same process as 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: 1.7.0-2 desired version: 1.8.0-1 <!-- 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.
Wanna take a stab at it then ? we can help you through the process
When defining the desktop shortcut that gets installed globally doesn't point to the correct executable. The executable that it points to is the one of the non-wrapped package, causing any plugins that are installed to fail to load. Steps to reproduce the behavior: the following in a launching the application from your desktop menu/launcher the command pallete inside of the program in - THIS fails HOWEVER, if we launch octave from the commandline instead by issuing the command, everything works as it should. When you launch octaveFull from the desktop menu it should behave the same as if it was launched from the commandline. When launched from the OS desktop menu. ! When launched from the command-line ! Inside of your octave-env derivation that's generated when you do a system rebuild, theres a file located, there you'd be able to see that the wrong executable path is used for it. Please fix 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]:
Thanks for the report! Indeed we never thought about this detail. I pushed a fix in . Here's how I tested it: And note how the paths in the line above is the same as the path to the wrapping derivation (from ). I also checked with that I can in the GUI. Your approval on will be welcomed.
Will take a while to build as I don't use unstable, there's a ton of dependencies
Describe the bug I have configured the new ACME module (from 20.03) and after a rebuild nothing happened. I expected to have a certificate or a (failed) certificate request, but neither of these happened. Apparently I have to wait four days until my certificates would automatically appear, that is a bit long. To Reproduce Steps to reproduce the behavior: a certificate through certificate request doesn't happen before the systemd-timer is due Expected behavior I should have a certificate as soon as possible. Metadata Maintainer information:
presumably you have a service which requires this certificate. You should make that service require your certificate service. Both and services do this with their options and could demonstrate for you how to do this. If any part of what I said isn't clear, or any part of the code please do not hesitate to ask for details.
Got it, I can make that work. But is that really the intended behaviour?
Would you want each certificate to renew each and every time you rebuilt your system? That sounds like much more of a problem. You could always manually execute the certificate service any time you want, but the intention is that you utilize systemd and make services depend on other services. Why provision a certificate unless you need it. If you need it, declare it so and it will be provisioned.
It wouldn't renew on every rebuild: Starting the renew service doesn't do anything if no renew is needed. I think having the certificate be created when a rebuild is done sounds reasonable. I think it might simply be a matter of adding to the acme services.
That and also making sure on boot that the certificate is in order is also a good practice.
thanks for clarifying that. I think I was mistaking the implementation which did attempt to renew every time it was called, if I recall correctly :thinking:
remarkable-mouse doesn't work for me, exiting with the following traceback: Digging through github issues led me to , and the following traceback: I guess this is a problem with screeninfo's packaging, but I'm unsure what exactly the issue is, or how to fix it; maybe related to ? screeninfo (and, by extension, remarkable-mouse) should work. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
As far as I know there is no infrastructure in place that lets (in ) work correctly, since it has no knowledge about the Nix store or the buildInputs of screeninfo. There used to be a call which replaced all findlibrary calls with store paths, but it was removed in I think the two load_library related substitutions need to be back in (compare with , which contains comparable code).
Replacing calls seems sensible, I will try to make a PR. A workaround for now (e.g. for remarkable-mouse users) is to set $LDLIBRARY_PATH to , but that probably isn't usable within the library itself.