jiebi/CodeConvo huggingface dataset:
crackmapexec fails to run on the unstable branch. Full backtrace : Steps to reproduce the behavior: Should be marked as broken for python 3.12 and above due to not being maintained anymore, it should be recommended to use the maintained fork . If applicable, add screenshots to help explain your problem. I may PR a proper fix later if I find time to do so <!-- 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]:
I don't know if removal was the best choice for this tool but maybe has all the features that had so it's alright. It's just that I'm not aware if there are any bugs that are not in that are in but I understand why removal makes sense since later we'll move onto later version of Python such as 3.13 and further more
As is a fork, I guess that the feature set is comparable or even bigger in the meantime. is still available for 24.05 and could still be used after 24.11 with some magic.
I ran into this issue where didn't have it, it is just a minor issue so it's alright on my side, but not sure if there will be any more issues I'll ran into later :
CMake seems to use ps command internally, but looks like CMake in nix on darwin can not find ps command, so it complains with message "sh: ps: command not found." (very many times) Although this does not seem to harm build, it is desirable if this can be solved quite easily by some simple patch.
I found a similar problem report in macports. Shall we include /bin/ps visible in cmake environment in darwin systems?
Is there no way to hard-code the path of into CMake?
isn't actually in .
The relevant code in cmake is I believe. The package on contains the Apple ps. I'll likely get it building as part of my revamp of the darwin stdenv, and if I'm feeling particularly charitable I might even hook it into cmake. In the mean time, I'd probably just leave this alone, since I don't think we're far off from having a sensible darwin stdenv.
We definitely can't use procps on Darwin since it doesn't have /proc. Also, these warnings are not always harmless: MySQL's startup scripts won't work unless it has ps in scope during the build process. Right now the workaround is this
This was fixed as part of the new darwin stdenv.
Describe the bug , which is depended on by , has been failing to build on both Linux and macOS since / , perhaps since was updated in . of a contemporary build attempt indicate that the immediate problem is that the current version of tokenizers depends on a vendored copy of v0.10.0 of the parkinglot crate, via its cargoDeps dependency. Further research suggests that the -issue reported in the logs was fixed in Amanieu/parkinglot which it looks like is included in v0.10.1 and successors. As a result, I think that someone just needs to refresh tokenizers' (possibly by way of simply updating the package) or, failing that, to try to get it to build with an older version of . (That said, I have yet to test these changes myself, so I don't know if they are truly enough or if additional modifications are required.) To Reproduce Expected behavior The build should succeed. Notify maintainers (also /cc (since this looks like an interaction with and since there is a commit linked to above updating in the scmdiff from the last successful build to the first failing build, per hydra.) Metadata $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(...): nixpkgs: Maintainer information:
Thanks for the bug report (still hoping for Hydra notifications some day)! The linked PR should fix this issue. I am also working on some other PRs to make transformers work on Linux/AArch64 and Darwin/x86_64.
I'm told a lot of people favor Paul Phillips' SBT wrapper over vanilla SBT. We probably ought to have a package for it.
Minus the parts where it auto-downloads sbt for you, I expect
Mmm, I don't know. Isn't it kind of important to be able to auto-download the appropriate version of sbt for each project?
Maybe? Seems hard to keep it Nix-flavored though, given that it wants to retrieve unhashed versions from the outside. I guess we could either patch it to call out to nix to download scala and sbt, or we could leave it alone and users can decide whether they care about Nix-like behavior here.
Describe the bug on macos fails because it can't find . To Reproduce Steps to reproduce the behavior: lean: leanprover. It bails out with OSX 'readlink' command does not support option '-f', please install 'greadlink'. If you use 'brew', you can install 'greadlink' using 'brew install coreutils' Expected behavior No errors. Additional context This is because leanpkg has an : It can be worked around presently by installing . Options I see for fixing the package: depend on on darwin patch out this check, since (presumably) nix provides the GNU anyway fix this upstream by changing the check to not fail under nix (e.g. by having an explicit check for the argument instead of relying on command name), and pull in the fixed version Metadata system: host os: multi-user?: sandbox: version: channels(rob): nixpkgs:
Sounds most easiest to implement and maintain.
Package name: proton-pass Latest released version: 1.22.0 <!-- Search your package here: --- Current version on the unstable channel: 1.20.2 Current version on the stable/release channel: none <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Package name: adbfs-rootless Latest released version: 2023-03-21 <!-- Search your package here: --- Current version on the unstable channel: 2016-10-02 Current version on the stable/release channel: 2016-10-02 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Steps to reproduce the behavior: bsddb3 Python312packages Python 3.12 seems to have removed distutils package but it should be inside setuptools module according Sadly this package is a dependency of several Python packages. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- PS: the package has not maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If bsddb imports distutils, then it is not compatible with Python 3.12. This is something for upstream to solve, but is unlikely to happen:
So all those packages that depend on this package, like must be labeled as broken?
Scrapy claims to support Python 3.12. Are you sure bsddb3 is still in their dependency chain?
Im not sure about that.
I see this merged PR that probably should solve the issue on scrapy... but about bsddb3, it must be removed from python 3.12 package group...
distutils is used in the test of bsddb3 to get the platform data, we patched this behavior in the following PR
Isn't It better to patch the test to avoid using distutils but still having it run ?
Failed to cross compile batctl package for riscv64 using nixpkgs on Ubuntu. Nix is not able to meat the dependency for the package: While the package successfully cross compiles on a NixOS* machine. Steps to reproduce the behavior: nix environment on a Ubuntu machine. and cross compile batctl package for riscv64. Below is the command I am using: attached nix-info not availble on Ubuntu
can you give the version of nix and the revision of nixpkgs (it might be in a file called .git-revision).
is the sandbox enabled, if they're at the same rev
Turns out I couldn't reproduce it because my machine has riscv emulation enabled, the makefile is calling a riscv version of pkg-config. I'm testing a fix to the problem at the moment
I note that the package sets in .[(1)] says [(2)] that the reason to disable "JBIG" is patent concerns, that disabling it removes support for many printers, and that "The patent will expire on April 4, 2012". Given the last, need we still disable this feature? [(1)]: [(2)]:
I don't think so. openSUSE enabled it, too. Other distributions might have done the same, not sure.
A PR that implements this change request would be very welcome. I'd rather not have this issue lying around, though, without someone having committed to actually work on it.
Steps to reproduce the behavior: pkgs.transmission to your environment.systemPackages (or use = true;) build will fail when trying to download a file that does not exist That does not seem to exist (I think, sorry for the @ otherwise) <!-- 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]:
Steps to reproduce the behavior: nix on x86_64-darwin experimental features nix-command and flakes to install nushell v0.75.0 via . Please run and paste the result.
I can confirm the bug, the following PR could resolve it.
that is great news! I am hopeful that can resolve it. I see that you marked this as resolved by . However, this does not seem to have resolved the issue for me. I am still receiving the same error when trying to build :
The ofborg test did pass, see Maybe you have to build it on master? Also, I don't think will help, as the author of that PR.
Hmm, after upgrading nix and updating my nixpkgs-unstable channel, I'm still receiving the same error.
You have to wait for the commit to arrive on nixpkgs-unstable.
Thank you your PR resolved it. the fix is in the nixpkgs-unstable channel. Much appreciated!
, CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.0 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: ,
, CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=5.9 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.3 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:
, CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09) CVSSv3=5.9 (nixos-19.09) CVSSv3=5.5 (nixos-19.09) CVSSv3=5.3 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:
30.1 is also the default version in 20.03 ATM.
I can't figure out which are the problematic lines! 5 and 9 do not seem to be any valid lines considering the error descriptions, or they're the lines in the expanded output(??) - I don't get it. I hope it wasn't something I did here: this /etc/nixos/nixpkgs/ git pull (this was last: ) sudo -i nixos-rebuild switch --fallback System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
Describe the bug Slicing fails on latest Cura (4.3). When trying to slice any model the slicing progress bar will get stuck at about ~20%. I tried various printer presets and the problem persists. From looking at the logs it seems like that CuraEngine is unable to get a value for 'machineheatedbuildvolume', which was To Reproduce Steps to reproduce the behavior: any printer preset any model Slice Cura log relevant parts to the problem seem to be aditional information it seems like , from the nix package, indeed is missing the new setting. For comparison the upstream definition. Metadata Maintainer information:
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.
Describe the bug pciutils is using a really old file which doesn't include any definitions for AMD Radeon 6800 XT cards. When running you get the following output If you get a newer version of the file from https://pci- which update-pciids script in package normally updates (but is disabled in nix package). You get the following: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wil): nixpkgs: Maintainer information:
Should also mention when running strace on lspci it reads the file from /nix/store/464020m9r6mhsivgp9v1bhkyzz5pa0gq-pciutils- and not from hwdata like I originally thought.
Would it make sense to make lspci depend on hwdata and then use from hwdata? cc'ing (who is listed as shadow maintainer of pciutils)
Hmm, makes sense. Except that seems to be in significantly more closures than , so depending on the extra 6+ MB of other data seems significant. Perhaps make put it into a separate output? Or could just copy it as a quick work-around (that's free for people with )
Oh, we can't "just" make multi-output, as it's a fixed-output derivation, but we could fake it through multiple derivations. Maybe just the work-around for simplicity then?
I think the work-around is actually pretty sensible. I'll prepare a pull request :-) Update: Did so, . Once both and are merged, our issue should be resolved.
Thanks for fixing that :). I tried your two updates on my machine and it appears to be resolved. Closing the issue out. Now we just wait for this to get into unstable :).
In is installed if it exists, and the install siliently continues if it doesn't exist. In the service the script is executed unconditionally, even if the script doesn't exist. That breaks suspend with the 465 beta driver, because there the script does not exist. I think we should [ ] fail loudly if it doesn't exist (so that if you close the laptop and put it in a bag, it doesn't catch fire) [ ] figure out where the script went / what the replacement is. CC
I will look into this in an hour or two, have a thing to do soon.
<!-- 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 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: texlive- current version: 2.9.1 desired version: 2.10.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.
Can you tell a bit about your use case?
I knew I forgot something! :smile: I'm using emacs + org-mode, and am using the =unicode-math= package with =stix2-otf= along with lualatex. In order to preview equations, the pipeline goes /However/, =dvisvgm= 2.9.1 doesn't understand the extended font data that lualatex emits (see the comments in ), and so produces corrupt output images. This was fixed in 2.10.1, which was recently released and pushed to CTAN.
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.
The application is crashing when trying to open a file Steps to reproduce the behavior: to open a repository application crashes Supposed to open a file exploer Using KDE Plasma 5 under wayland <!-- 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.
I’m running Gnome 45 under Wayland and the « Open a Repository » feature is working fine. I’ll give a look with KDE Plasma 5 when I have some time.
same here
As in it it works or it does not?
not work kde + wayland
Describe the bug The file has this function: Since this is called for every dependency, we get quadratic complexity. This may cause a non-trivial slowdown - building digikam I noticed it takes a few seconds just to get to , but there might be other causes. It also causes huge amounts of debug output when you add a to (about 600 MB for digikam). We should use an associative array for this like stdenv does (see ). Notify maintainers
We also need to do this in the setup hook for paths seen by .
I marked this as stale due to inactivity. &rarr;
Not stale.
Fixed in .
<!-- 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: materia-kde-theme <!-- 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: desired version: <!-- 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.
Package name: snipaste Latest released version: 2.9.2-Beta <!-- Search your package here: --- Current version on the unstable channel: 2.9-Beta2 Current version on the stable/release channel: n/a <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.
Describe the bug fails on Darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Package builds Additional context Error log: <details<summaryError log</summary</detailsMetadata Please run and paste the result. host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: Possibly related to
On the master branch, I removed the derivation from the nix store with and I built it without substitutes; failed with the same message. This is not caused by , but help me discover it due to the update of the requests python package.
maintainer:
I don't have a way to test on joblib for darwin so this is why I didn't have input on this PR. Is there an easy way to test nixpkgs on darwin? Hackintosh via kvm?
There is that works with some tweaking but I wouldn't describe it as easy. Another option is to ask @ GrahamcOfBorg to do the builds on the PR if there are not too many iterations to do.
The symlinking between the multiple outputs of seems to prevent it from installing. I was looking to install it to have the dig command available. - System: 17.03pre94050. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre94050."
11.4 still doesn't contain :-( How could we have that as default in 16.09? I consider it quite an important feature for + multiple outputs. would you be against porting that PR to 1.11.5 and making that default in 16.09 and master?
+1 for a 1.11.5 Nix release in general :)
Since this seems to be an issue for multiple packages, I am raising the severity on here.
Looks like the same kind of issue as So +1 for Nix 1.11.5 on NixOS 16.09, if that's what it takes to fix this.
ping again about nix-1.11.5 (my comment above).