jiebi/CodeConvo huggingface dataset:
When adding to and running , emacs 25 builds and fails with 4 unexpected TRAMP mode test errors: The full output contains null bytes and weird control characters that don't let me paste this into a gist easily. Is that part of the test or indicative of the problem? cc
ok... i think this will contain the build output? again if i open it in emacs there are lots of control characters. had to zip so github wouldn't complain.
I disabled for emacs25pre, for now, on my system. I hope this will be resolved upstream before next release ...
It's quite possible that tramp-related tests fail because there is no proper networking support in the build chroot, i.e. it's not possible to resolve host names or service names. Another source of trouble could be the lack of an UTF-8 capable locale in our default build environment. Anyhow, it would be really good to report those errors upstream to make sure that the next Emacs release has them fixed in one way or another.
I've been working with the Tramp author for the past several days about these failures, and we've identified that the problem is somewhere in the environment that the tests are presented with, but we don't yet know what exactly. I'm still digging into it.
This is the content of on my system: It has set to , which does not exist. This path should point to the include directory of vulkan-headers package. Also, the package contain headers that include headers from vulkan-headers package. Should the pc file for glfw3 add vulkan-headers to the include path? Metadata system: host os: multi-user?: sandbox: version: channels(saga): nixpkgs:
Ping (Vulkan maintainer), I'm seeing when building anything depending on vulkan-loader using pkgconfig.
Thanks for the ping! Drafted Please confirm that this solves the problem.
Reported via email by a Nix user without a GitHub account. Build fines. In the attempt to build GNU octave for aarch64 darwin. Maintainer information:
I would suggest opening an issue but I guess that's not an option.
Perhaps, but it seems peculiar that the user "is not able to compile a simple test program" - as if there's a bug in our compiler . Related issues: Perhaps the user should try this edit to Nixpkgs: So even on Darwin the compiler that will be used will be gcc, to play nicely with gfortran.
The suggestion to use is good; I think couldn't possibly work otherwise. Beyond that, I have no idea.
But doesn't it work on x86_64 Darwin?
perhaps you could help us - does arpack and/or octave build currently on x8664 Darwin?
Any news here? This also affects other derivations (e.g. openspecfun). arpack does build on x86_64-darwin.
This issue should be renamed "gfortran broken on aarch64-darwin", as it is not specific to arpack:
See – but we should really fix this in gfortran, rather than requiring every derivation to copy/paste the line.
cc To summarize, we should set: In stdenv somehow.. Perhaps this should go here:
We probably don't want to globally disable stack protector support, though; this only affects gfortran. Seems like we'd want to have the cc-wrapper for gfortran (on aarch64-darwin) to never inject the options, either through a option, or in the cc- script itself. Actually fixing whatever goes wrong in the toolchain would be preferable, of course.
Here's a proposal:
Project description "Linux/macOS media player based on GStreamer and GTK" gstreamer rust Metadata homepage URL: source URL: license: MIT platforms: linux
I tried to package glide and it's building successfully but the timestamps and the progress bar at the bottom aren't working. My progress is at if someone else is willing to look into it but I'm not sure how to debug this.
Nice, thanks Sadly, I think you made it further than me: heh
I couldn't really find anything about
I pulled your branch but it doesn't launch for me. Just the .
Stuck here I think maybe updating the registry would help, but I'd better waiting for the next release if possible...
Describe the bug Since the recent commit ( ledger fails to build on Darwin. To Reproduce or similar. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(steve): channels(root): nixpkgs: Maintainer information:
if you don't need python. do you mind trying to build it with it off?
the error you're seeing is that a header from package isn't able to be found. I don't have a darwin machine to see why these two are different
Thanks. I don't need to work around it particularly, more interested in identifying a fix. I think the issue is that it's somehow picking up the system python: so probably some of the handling is broken, and indeed there are a few suspicious portions in the output I pasted, e.g. and subsequently:
I got the same cmake warnings, upstream needs to update some of their files. I'm not familiar enough with nix-darwin to have it NOT pull in system python
The version of AWSCLI in master is 1.32.58. This version requires botocore==1.34.58, however the version of botocore in master is 1.34.87 AWSCli botocore pin: This started happening after changing my to Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This should be fixed by , which syncs botocore, awscli, and boto3.
Using with and any packages depending on results in the following error: However, packages not depending on work fine, as does running on packages depending on and entering the manually. Steps to reproduce the behavior: the following flake: and that fails while succeeds. To be dropped in a with packages depending on . <!-- 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.
While I could reproduce your case with nixos-22.05, on master, in both cases, I get dropped to a python shell, not a hy shell. Here is a version of your flake that overrides the so that you land in a hy repl. But I think it would be better to put this into eventually.
I'd done that with , but hadn't thought to do it with ; it works! Thanks! Should one of us submit a pull request?
Or perhaps would want to?
Not really, if you want to open a PR I can review/merge.
Sorry, the instructions for contributing are a little confusing to me; could someone give me a summary of steps I need to take?
Also, I just realized I don't know how to merge this with ...
And my own problem was fixed after changing the way the flake apps were made; thanks for all the help!
Describe the bug Trying to run mutagen results in an error: The mutagen- which is supposed to have binaries for different platforms is missing. To Reproduce mutagen a mutagen session Metadata system: host os: multi-user?: sandbox: version: channels(alex): channels(root): nixpkgs: Maintainer information:
Hey, author of Mutagen here, super excited to see a Nix package for it! I just thought I'd mention that the bundle currently needs to be placed in the same directory as the executable itself. This is something I've been meaning to improve for a while now (by allowing it to be put in a directory), but I haven't had a chance to implement it yet, mostly because it's a little tricky to get right with package managers like Homebrew that symlink binaries into a different target location. I'm not very familiar with Nix, but I'm sure that it would prefer to avoid having this tarball in the directory. So I'm happy to push ahead on trying to support the -based layout if that's helpful here (or perhaps something more general if NixOS prefers a different layout).
cc
A quick update: Mutagen v0.11.2 and later support looking for the bundle in a directory (assuming a Filesystem Hierarchy Standard layout), so a layout of the form: should now work (in addition to the option of installing the bundle directly alongside the executable). This also works in a -style setup where the binary is symlinked into a larger directory.
Thanks! Is the available for direct download?
The bundle ships as part of the official releases (e.g. in the ). It needs to be kept in sync with the version of the binary being installed, but it should work just fine with a binary built locally, so long as the versions are the same (to the patch level). The bundle can also be built locally, but doing so requires running a custom script inside the Mutagen source tree that performs the necessary cross-compilation (this bundle is a collection of cross-compiled binaries that get injected to remote systems to facilitate file synchronization and network forwarding). I'm not sure the best way of handling that in the context of the NixOS packaging system. Perhaps there are some custom hooks available?
At the moment, this script doesn't have a flag for building just this bundle (it will only be built as part of a full set of release bundles for all platforms), though I suppose such a flag could be . One of the downsides of doing the cross-compilation locally on Linux (or any non-macOS system) is that the C FFI bindings needed for efficient filesystem watching on macOS won't be available, so file synchronization between NixOS systems and macOS systems will suffer. That might not be a huge loss, though. This is why the Homebrew packages just use the official pre-built release bundles as their "source code." It's a bit non-idiomatic, but it saves on local build times and allows for cross-compiled binaries with C FFI support. Of course, I totally understand if that doesn't work with the NixOS package philosophy, in which case just building the bundle locally is probably the best bet.
As a reference point, here's what the Mutagen Homebrew formula looks like:
I agree, setting up the cross-compilation would not be trivial so the nix derivation must download the prebuilt agents binaries from somewhere while still being able to build the agent on the platform it is running on. I see three possibilities: (No changes on the mutagen side). Nix derivation downloads the full mutagen release and extracts . the version number to the and add it to the downloads. The nix derivation would just download it. the individual downloads for the agents similarly to for all the platforms and have the nix derivation create the itself. That way it would be very easy to even parametrize it to only download the agents the user wants and the nix derivation would supply the binary for the platform it is running on.
All three options are reasonable ideas, though I would prefer to avoid (3) since it would significantly increase the number of assets attached to each GitHub release (which is probably already too high). The individual agent binaries for linux/amd64 that you mentioned are sort of a special case for some experimental container integration features, so I'd prefer to avoid expanding them to every platform.
I also don't know if many users want to go through the trouble of filtering the remote platform support that they want, though if that's something users are interested in then I'm certainly willing to try to support that.<sup1</supOption (2) is possible without too much effort, though I don't think it adds much value over option (1). Additionally, if option (1) is already going to be used to download the release bundle, it might as well just pull the binary out of the release bundle as well and save the complexity of a local build. In any case, the current package should have the build of removed since it won't really be of any use. Let me know if option (1) will work and if there's anything I can do to help. <sup1</supI think a better long-term solution is to provide two download variants: a "full" agent bundle that includes all platforms and a "slim" agent bundle that just includes commonly used platforms. P.S. Thanks for helping to support this!
Given the usual problems with pre-compiled binaries, reading the discussion above I thought we might have another problem : nixos needing its own agent in mutagen- But to my surprise, the amd64 binaries work on nixos without the need to patch the ELF interpreter or anything else, it seems that everything is self-contained with no external dependencies. So why not make a binary installation directly?
I can open a brand new issue about this, but wanted to get a quick check from you about a problem I'm having with this. I'm getting the following when extracting an agent: The libexec path appears to be appended to the directory for some reason. I don't know if this is an issue w/ nixpkgs or mutagen but would be happy to help track it down and (maybe) fix it. So, it looks like the file is there, but the search path is treating the absolute path for as if it was relative to the path. I suspect it has to do with the liberal usage of symlinks in nix tripping something up. I'm just too new to golang and nix to have any idea how to fix this.
Hey I believe this is fixed in Mutagen (thanks to who reported it in mutagen-io/mutagen and fixed it in mutagen-io/mutagen).
It looks like the corresponding NixOS package needs to be updated — we're currently at Mutagen v0.16.4. If you want to open a NixOS/nixpkgs PR for that, that's probably the way to go. Feel free to @ mention me in that PR, otherwise I'll see if I can find some time to open it during this week.
Thanks for the information. :) I spent some time yesterday trying to get my local system running on Mutagen 0.16.4. I got it working in terms of correctly locating the agents, but I noted in the PR that it isn't working for docker containers because Mutagen running as root does not seem to be able to find Docker installed via nix. I'm happy to move any additional discussion to .
I never really noticed this until today, but apparently the discord task bar icon (if you have one, I am on KDE) is supposed to have a notification badge, I have included a screenshot. The discord task bar icon should include a badge for the number of unread notifications ! Today I was setting up a system for someone else who was new to Linux, I installed Discord via flatpak, and then they asked me about the badge (since it is present on Windows but not on the ). From a little searching, it seems that Discord needs to ba available in the system, so on Kubuntu this was fixed by doing . Since is already in , it might just be a matter of adding it to the ?
Huh. I don't think I ever knew one was supposed to be there either. I see an unread indicator (red circle in the top corner, no number), so that works fine, but I don't think I've ever seen a number. Assuming that would be all it would take, sounds like a pretty simple PR that would be a good addition.
I have made a clone of and it does seem that all that was need was to add the library to . I found it to be a bit ugly myself since I had over 1000 unread notifications, and it seems disabling it is only possible outside the application. On for example, you have to go to and tick off "Show notification badges". Running the current from afterwords does not remove the badges, it only freezes them in place, as in marking notifications as read will not update the number, so this is also cached somewhere outside , meaning this couldn't be a toggleable functionality via an .
Recently variety stops working on NixOS. Pictures are downloaded well but the wallpaper can't be changed and can only be set in system setting. That's because of the hardcoded shebang which is taken from on the first installation. So when the bash is updated the script can't find it. It should be set as something like . Not sure if this is a nixos bug. Steps to reproduce the behavior: variety bash It works after the bash update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
IIRC now we use . I am patching it now.
We should mention in nixos manual Chapter 6 that options can be dicovered with and It will help newbs learn how to discover packages more easily. As a new user, I was sticking everything I wanted inside of the array, and I didn't not realize that is a better route to take because it configures many things automatically. For example, results in also being installed as well as features enabled, while writing does not. This will be helpful to new users.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Deluge 1.3.12 is incompatible with current libtorrent-rasterbar 1.1 introduced in . There are a few exceptions thrown in the log and several core features do not work as expected, e.g. seeding torrents get queued, although queues are disabled. The Deluge team does not plan to fix this, but it looks like libtorrent might in version 1.1.1. References: System: 16.09pre87431. Nix version: 1.11.2 Nixpkgs version: 16.09pre87431.
Should we include an older version of libtorrent-rasterbar in the repos alongside current? We can point deluge to use it instead.
Yes, that would probably best in the meantime. 1.0.9 should work as expected.
Looks like the PR that fixes this has been merged.
In this blog post [1], Google states that after March 15, 2021, they will be limiting access to various Google APIs that they are now describing as "private" and "only intended for Google's use". The most notable of this apparently includes "Chrome sync" which allows syncing bookmarks / browser history / etc. across multiple browsers logged-in to a given Google account. Additionally, emails [2] have been sent out to chromium maintainers from other Linux distros stating that users of their chromium-based browser will no longer be able to sign in to their Google accounts. They recommend these chromium-based browsers remove and from the build configuration, or alternatively, set at startup. Did we get a similar email as the one shown in [2]? [1] [2] CC
Further discussion With actual "answer" edit looks like this was cross-posted across two lists... I was confused by the interface... the content was already in the previous link. Basically, unless Google backtracks, the API key will become unusable for a distro-level deployment. We could continue providing the derivation, with bring-your-own API keys. This would be expensive to build for end-users. I wonder if the keys are trivially replaceable in the resulting binary though. If they are, we could produce prebuilt unusable binaries, and let users "finish" the build with their own keys. edit: The archlinux devs state that . Pinging and as we probably will have to apply the same resolution to 20.09.
Some will poo-poo the thought because "not FLOSS" and similar ideologies, let's think about end-users first here. We're smaller than those distros, but if there's a common front to talk with Google about it, we should participate or approve of such a This will end-up hurting a part of our end-users.
Personally, I don't use chrome. Google does, what google wants. I don't think we have much of a choice, and will just provide what we can. I'm sure users will be aware that the limitation exists regardless of platform.
Yes, we should be able to pass these API keys from the environment instead of baking them in.
Package name: tutanota-desktop Latest released version: 3.110.0 <!-- Search your package here: --- Current version on the unstable channel: 3.108.12 Current version on the stable/release channel: 3.98.20 <!-- 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.
Package name: Latest released version: 0.0.22.post7 <!-- Search your package here: --- Current version on the unstable channel: (This version never existed but whatever!) 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 Note for maintainers: Please tag this issue in your PR. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
let me know if you have time to test
Project description hwatch - A modern alternative to the command, records the differences in execution results (Rust, currently distributed via [Homebrew], [MacPorts], [Arch Linux AUR], and [Rust]) At the moment hwatch is only available for on nixpkgs Metadata source URL: license: MIT platforms: All
It has been available since 22.11:
That's weird, it didn't work for me when I tried it last time so I switched it to homebrew via nix-darwin. Let me retry
I see the issue, it's Linux only
updated, thank you!
could you take a look at ?
Approved, thank you for being awesome
<details<summary<codenix log /nix/store/xglq4zgrfjp92jrjn1d740wgssrzbqpy-python3.10-tpm2-pytss-</code</summary</detailsSeems to be the same error as , but the current (as of ) has the supposed fix (). Maybe one of the other patches since then ( ) re-introduced the build failure? Please run and paste the result.
I can confirm this failure
I am also hitting this issue. Both of the above mentioned commits build for me.
Build failure was introduced with
From the commits from that merge, narrowed it down to
Followed merges back up to , though both parents have the failure there... :(
I have this issue too. This is my error message: This is the full log:
I have the problem, too
I don't have a patch for it yet, but adding -DFORTIFYSOURCE=0 to this list gets it to build.
Unless I'm mistaken, that was the fix applied by &mdash; first patch in the list here:
It only add on L207, not on L187
[deleted]
Yeah, the overlay I build isn't working for me either. Not sure where I was that made it work...
find out it and u will be the hero hhh
Ok, found the exact PR causing the issue:
The issue is that nixpkgs now forces the fortify setting, ignoring whats set in project's files. So old method of disabling fortify for just one invocation is not enough I've been trying to use and then setting fortify settings in the environment, but that is not working. With , the package builds, but with that set, it seems that trying to enable fortification in the environment has no effect. So not sure how to enable fortify for the built object files.
The overlay I'm using until there is a better fix is:
Sorry for the lag, I'm out in holidays with family without much internet. I posted a fix in but I'm not sure I'll be able to follow up on it.
The doesn't start 'cause probably the wlroots it's causing a compatibility issue. Everytime that i try start river, it doesn't open. I searched on official repository and i found this issue: The current river's version on nixpkgs repository use wlroots 0.13.0, however the available on repository it's 0.14.1. Maintainers:
I'm not maintainer for months so I don't really care.
I'll get to updating it in about ~2 hours.
Steps to reproduce the behavior: <!-- 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.
This is due to the upgrade to Rust 1.65 in I'm sorry for the inconvenience and will take care of fixing this. The caveat is that I need to fix my system first, which I broke somehow trying to install the new version of nix
Thank you very much!