jiebi/CodeConvo huggingface dataset:
Usage: upper --alpha A --beta B - lower SELF upper --alpha A --beta B - lower --self SELF _ FireTest.testFireObjectWithDict _ self = <fire.firetest.FireTest testMethod=testFireObjectWithDictdef testFireObjectWithDict(self): self.assertEqual( fire.Fire(tc.TypedProperties, command=['delta', 'echo']), 'E') self.assertEqual( component = <class 'fire.testcomponents.TypedProperties'command = ['delta', 'echo', 'lower'], name = '' def Fire(component=None, command=None, name=None): """This function, Fire, is the main entrypoint for Python Fire. Executes a command either from the argument or from by recursively traversing the target object 's members consuming arguments, evaluating functions, and instantiating classes as it goes. When building a CLI with Fire, your main method should call this function. Args: component: The initial target component. command: Optional. If supplied, this is the command executed. If not supplied, then the command is taken from instead. This can be a string or a list of strings; a list of strings is preferred. name: Optional. The name of the command as entered at the command line. Used in interactive mode and for generating the completion script. Returns: The result of executing the Fire command. Execution begins with the initial target component. The component is updated by using the command arguments to either access a member of the current component, call the current component (if it's a function), or instantiate the current component (if it's a class). When all arguments are consumed and there's no function left to call or class left to instantiate, the resulting current component is the final result. Raises: ValueError: If the command argument is supplied, but not a string or a sequence of arguments. FireExit: When Fire encounters a FireError, Fire will raise a FireExit with code 2. When used with the help or trace flags, Fire will raise a FireExit with code 0 if successful. """ name = name or ([0]) # Get args as a list. if isinstance(command, six.stringtypes): args = (command) elif isinstance(command, (list, tuple)): args = command elif command is None: # Use the command line args by default if no command is specified.
args = [1:] else: raise ValueError('The command argument must be a string or a sequence of ' 'arguments.') # Determine the calling context. caller = ()[1] callerframe = caller[0] callerglobals = callerframe.fglobals callerlocals = callerframe.flocals context = {} (callerglobals) (callerlocals) componenttrace = Fire(component, args, context, name) if componenttrace.HasError(): for helpflag in ['-h', '--help']: if helpflag in componenttrace.elements[-1].args: command = '{cmd} -- --help'.format(cmd=componenttrace.GetCommand()) print(('WARNING: The proper way to show help is {cmd}.n' 'Showing help anyway.n').format((command)), ) print('Fire trace:n{trace}n'.format(trace=componenttrace), ) result = componenttrace.GetResult() print( helputils.HelpString(result, componenttrace, componenttrace.verbose), ) E 2 FireExit ----------------------------- Captured stdout call ----------------------------- E ----------------------------- Captured stderr call ----------------------------- Fire trace: Initial component Instantiated class "TypedProperties" (/private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-) Accessed property "delta" Accessed property "echo" Accessed property "lower" ('The function received no value for the required argument:', 'self') Type: builtinfunctionormethod String form: <built-in method lower of str object at 0x1100c7340Docstring: Return a copy of the string converted to lowercase.
Usage: delta echo lower SELF delta echo lower --self SELF __ HelpUtilsTest.testHelpStringBuiltin _ self = <fire.helputilstest.HelpUtilsTest testMethod=testHelpStringBuiltindef testHelpStringBuiltin(self): helpstring = helputils.HelpString('test'.upper) self.assertIn('Type: builtinfunctionormethod', helpstring) self.assertIn('String form: <built-in method upper of', helpstring) E AssertionError: 'Usage: [VARS ...] [--KWARGS ...]' not found in 'Type: builtinfunctionormethodnString form: <built-in method upper of str object at 0x11028d458nDocstring: Return a copy of the string converted to uppercase.nnUsage: SELFn --self SELF' AssertionError _ InspectUtilsTest.testGetFullArgSpecFromBuiltin _ self = <fire.inspectutilstest.InspectUtilsTest testMethod=testGetFullArgSpecFromBuiltindef testGetFullArgSpecFromBuiltin(self): spec = inspectutils.GetFullArgSpec('test'.upper) E AssertionError: Lists differ: ['self'] != [] E E First list contains 1 additional elements.
E First extra element 0: E 'self' E E - ['self'] E + [] AssertionError =============================== warnings summary =============================== /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- DeprecationWarning: 'U' mode is deprecated self.fromlines = open(fromfile, 'U').readlines() /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- DeprecationWarning: 'U' mode is deprecated self.tolines = open(tofile, 'U').readlines() -- Docs: ============== 4 failed, 156 passed, 12 warnings in 1.80 seconds =============== builder for '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-' failed with exit code 1 error: build of '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-' failed nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(abathur): nixpkgs: FWIW, I'm also running bash 5 () as my default shell atm, but I see the same error when I manually run launch a bash 4 () shell to run this in. I haven't updated channel in a bit but I don't see any open/recent issue or PR.
Relevant snippet while building it fails with I copied over the for debugging, this is the full output: Steps to reproduce the behavior: snippet as flake default output Build should succeed and images should be loadable via Patching the as follows: fixes the problem, but would probably hide other cp errors. Maybe the behavior of coreutils/cp changed in the recent versions. At least the current manual states it will fail silently. I'm using a linux-builder on my machine.
Thank you for reporting this. I’ll try to replicate this locally. The lines do not look like errors to me. It looks like is informing that those files already exist in the output and thus are skipped (--no-clobber). However, if the build is failing there’s something going wrong.
Thank you for linking the manual. It looks like will exit with a non-zero status code in case of files that are already present now. The coreutils changelog states that now reproduces the behavior had at the time I wrote the mergeImages script. I was able to build by changing to . I don't know how to best go about obtaining the behavior everywhere, should the flag be dependent on the version of somehow? Maybe we can just assume that in will be a new version from now so that we can use everywhere? Given that all files that are present in both docker images apart from the and repositories files should be content addressed the only issue with removing is that time is spent unnecessarily writing content that's already present, so removing the flag altogether might make sense.
Thanks for investigating! I'm not familiar with the backward compatibility policy of the nix ecosystem, but I would assume that the most recent version of can assume most recent coreutils. Might happen that someone is overlaying old coreutils but then you might just need to overlay the old too, if you can pinpoint it down to coreutils cp.
True, but then apparently they have a legacy software problem, in which case they should use overrides only where it is necessary, instead of a blanket override in an overlay. It is not realistic to expect all of Nixpkgs to work with arbitrary changes. The cost of such compat logic isn't worth it; certainly not in this case, until proven otherwise. If they contribute a full time maintainer it is worth it, and if they have a legacy software problem they probably can.
Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.
gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc
Steps to reproduce the behavior: FWIW: my fix is here, - but it is using a fork of . If somebody has the time to create a minimal patch on top of the current source, please feel free to. Please run and paste the result.
Looks like you are on a good path. Unfortunately I have no access to Apple hardware at all, but would be happy to merge a PR.
Yes, is working on it. There is a more active fork of luabind here: - how about we switch to using it? It'll obviate a bunch of patches as well.
I agree, sounds sensible.
XOrg crashes when certain applications are launched. More details here: Steps to reproduce the behavior: any of the IntelliJ IDEs. You may have to set anti aliasing to greyscale. Xorg will crash. Xorg doesn't crash. This is the bug: It looks like a security fix caused this regression. Ubuntu has already applied patches that fix this for Xorg and Xwayland: see this message from the above Ubuntu thread: NixOS should use the same patches until this is fixed upstream in XOrg. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Sounds like this will be addressed by this update:
xwayland too: looks like updating xorg and xwayland to their latest versions will do the trick then
xwayland was bumped to the latest version in PR
Installing results in a broken application that exits on startup with the message "GEGL operation missing! Glimpse requires the GEGL operation "gegl:introspect". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for Glimpse." Steps to reproduce the behavior: to Glimpse Glimpse should work! works fine for me. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Thanks for the report, Unfortunately I cannot reproduce your issue. Neither on as you reported nor on current . Could you elaborate on your setup a bit? Which window manager/desktop environment are you using? Is it possible that you modified glimpse in an overlay? I'm running Sway (Wayland) and deleted and before testing to make sure I didn't have any leftover state in my home directory.
I'm using i3wm (with no separate desktop manager); I installed Glimpse by adding it to environment.systemPackages in , I don't think there's any chance I did anything special with overlays there. I can't think of anything else I've done that might have affected this – I only installed NixOS a few days ago. I do have Home Manager installed, so I guess is it possible that something I've installed via that is causing a problem? (I don't have that much stuff installed, though, I don't think.) on my system is a tmpfs, so if something put a file outside of /nix or /home on install and is expecting it to still be there then it'll be unhappy, but I think I tried running Glimpse immediately after installing it with and it didn't work even then, so it shouldn't be anything related to that. Deleting changes the icon in the popup, which is weird, it looks like this if that directory isn't present at statup: ! and like this if I leave the directory there: ! but nothing else seems to change. (I noticed there's a directory in and , but removing it doesn't seem to do anything.)
aha, I found the problem: works just fine, and adding graphviz to environment.systemPackages fixes it permanently. see e.g.
Steps to reproduce the behavior: (warning: veeery long) Seems caused by Also previously reported (if I'm reading the many thousands of lines of output right) to be another instance of Breaks: .
This appears to have been fixed somewhere between and
I have no idea how you tested, but after a (pulling branch), I fail to build this same package. Now with the newer hash: I vote for this issue to be marked as "prematurely-closed", and thus re-opened.
debugpy was blocking my nixos rebuilds through . Updating to resolved it for me. That's about all the testing I did at the time, and figured it was good. Sorry about that.
Yep! Looks like this is related to flaky process test timeouts (which are more likely to fail on less powerful / overworked devices). should fix this!
You can checkout to see when the fix will be applied to the channel you're using.
Project description Flawfinder is a simple program that scans C/C++ source code and reports potential security flaws. It can be a useful tool for examining software for vulnerabilities, and it can also serve as a simple introduction to static source code analysis tools more generally. It is designed to be easy to install and use. Flawfinder supports the Common Weakness Enumeration (CWE) and is officially CWE-Compatible. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
could you please test Thanks
Works for me on NixOS. I wrote a simple c program that it found the vuln in: where it gave:
<!-- 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: <!-- The current version can be found easily with the same process than 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: 4.6.3 desired version: 4.11.2 <!-- 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.
Not all the executables of the /contrib directory are patched, so some functionalities of the theorem prover fail. For instance, running the Sledgehammer tool (subwindow in the bottom bar of Isabelle starting window) always fail with: The directory: The sub directories marked with a star contain the x64 executables I tried to execute manually and I got: "Not such file or directory" Run Isabelle and try to use Sledgehammer. Then try to execute the executables in the marked directories, and you will obtain "Not such file or directory". System: 16.03.1171. (Emu) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1171." I am definitely new to NixOS, but with my nonexistent experience I think at least two solutions are available: 1) I can substitute the broken software with the packaged one, as it is done with Java and Polyml in the Isabelle2016 derivation; 2) I can patch the executables with patchelf (hopefully). I did not have time to try these so far, but I was wondering how difficult would be the 2nd: I think that using (1) can potentially break Isabelle since we would use different versions of the software in /contrib. You guys are amazing! Thanks a lot for NixOS!!! It is the most elegant OS I ever tried!
Hello, after some experimenting, I found a hack to make Isabelle work in Nixos Emu x64: this derivation substitutes the broken provers and rebuilds the exec-process executable. What I do not like of this solution: the provers are not the same (versions) of the Isabelle distribution, and this works only for x64 -- if you use a 32 bit you have just to change (take away the_64 bit from the target directory name) the derivation after the comment in the postPatch phase. However it works. Hopefully someone more expert than me can propose a better solution! Thanks again!!
<!-- 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: 2.1.1 desired version: 2.1.3 <!-- 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. It seems that this version has a few changed dependencies ( instead of )
fails when building the wheel for pip. (Building the wheel for wheel succeeds.) Steps to reproduce the behavior: Build succeeds as it does for regular Python: (there are no maintainers given)
Which branch is this on?
~Can't reproduce this on master nor on nixos-22.05.~ pypy version succeeds, pypy3 version fails. master and nixos-22.05
Probably also on 21.11. -No, 21.11 is fine. -
Encountered on Nixpkgs 21.11 system: host os: multi-user?: sandbox: version: nixpkgs:
Bisected to the 7.3.7 update. Newer pypy3 versions exhibit the same problem. Our pypy3 package set is clearly unmaintained. cc
Fixed in .
The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .
Package name: sqlx-cli Latest released version: 0.7.3 <!-- Search your package here: --- Current version on the unstable channel: 0.7.1 Current version on the stable/release channel: 0.7.1 <!-- 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]:
I'll take a look at this tomorrow. Thanks for the ping.
Project description This allows applications like Discord that use xwayland to capture Wayland windows. Metadata homepage URL: source URL: license: GPL2+ platforms: Linux
I wanted to test this and packaged it my config repo. I'm not interested in being a maintainer, but I can submit a PR or someone else can feel free to use mine as a base. The project is definitely beta though cause it segfaulted when resizing Dolphin and crashed Plasma entirely.
If this is the wrong place to post, please let me know. I can see the package here under However I'm getting the following error after adding to systemPackages when switching:
I guess you jsut want to "cherry-pick" xwaylandvideobridge from unstable, but the rest of your system follows e.g. stable by default? First you add unstable channel if not already done and refresh the package definitions: Import it in your And then you add it to your systemPackages via .
Describe the bug getting when trying to scan over network (scanning from the , scanner device connected to via usb) To Reproduce Steps to reproduce the behavior: server config: client config: on the : choose the network scanner : stops scanning immediately, server logs have an entry: from Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Guessing here, looking at the commit log for the service definition, apologies for pinging a lot of people: Metadata Please run and paste the result. server (managed via nixpkgs): client: Maintainer information:
I marked this as stale due to inactivity. &rarr;
Please test
nice ! will do in few days as I'm moving house :)
Hi just tested it now and it works very well !
approve the pr
Describe the bug The recent Haskell generic-builder changes for Darwin (in particular according to bisect) have broken . To Reproduce from a nixpkgs at or later on Darwin. This fails with . Additional context is a pure Haskell package, that depends on , which is what actually uses the C dynamic library. So the problem seems to be that fails to include the C library in its closure. Interestingly, this C library has filename not , even though it looks exactly like a dylib as far as I can tell (I'm not expert in macOS linking): So I can see why would fail to be included into by . However, I don't see why broke it. Nothing to do with the C or Haskell packages involved has changed for months. Updating the generic-builder to include as well as files does fix the problem for me, and seems benign, so I'll submit a PR for that. But I don't feel I understand everything going on here, so I'm opening the issue in case more qualified folks can identify a better root cause fix. Metadata system: host os: multi-user?: sandbox: version: channels(simon): nixpkgs: Maintainer information: Ping from the original changes - thanks for all your efforts!
Just noting here that there is some useful discussion .