jiebi/CodeConvo huggingface dataset:
When I try to open the warp-terminal on wayland it crashes without opening any window and get the following logs: Steps to reproduce the behavior: to open warp-terminal happens It should open the warp-terminal window and prompt. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Might be helpful:
Fixed in , I tried running () on KDE Wayland and everything works as expected
A warp-terminal dev has stated that wayland support is explicitly still experimental and off by default for this reason. Please do not open issues concerning configurations that are explicitly unsupported by upstream.
Sorry, I didn't know it was explicitly unsupported by the upstream since it was working before just fine on Wayland. Thanks a lot anyway!
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.
You don't need to open an issue if you're going to make a PR right after.
Apologies, my bad. I was not aware :(. I am only 1 day & 1 PR old here.
A clear and concise description of what the bug is. Steps to reproduce the behavior: created with expected behavior from This might be due to vhs being outdated in nixpkgs. Please run and paste the result.
Nixpkgs has since been updated to the latest version (v0.2.0), and the error still occurs on the latest Nixpkgs commit ()
Any suggestions on a fix?
I believe the fix might be to include as a dependency and ensure that looks for the binary in the same place nix installs it (i.e. it is located in the as chromium):
The PR for this breaks vhs on darwin, since chromium isn't supported on that platform
Thanks for filing a new issue
It would be nice if the package included shell completions for bash, zsh, fish. Steps to reproduce the behavior: (In fish): pipx-specific shell completions should show. One problem specific to is that the instructions you get with do not work unless you know to install the binary first (e.g. ). I hope that mimicking would work (though I'd also like completions to be included). I might be able to try that myself at some point, but I'm not very familiar with testing that a patch to works. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
the strict commit history guidelines require frequent use of , a command which may be unfamiliar to those that are used to projects with more lenient commit guidelines. find or write a high-quality guide to and make it available in <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
So I today I spawned a machine with and satisfyingly the directory was generated with all of the certificates etc that taskwarrior needs, including the clients' certificates. I noticed that the users' keys located at are owned by root with read only permissions for the root user alone. No matter what are and . I'd like to enable the group read those client keys, as well as the file so that I can configure a client easily. Thankfully the group can read the file, but not the client keys. The manual indeed explains that the command: Could be used to get those keys, but I'd like to use syncthing for that to automate the process even further. I got a bit lost while reading the . Specifically, I'm not sure why does always works in the following umask: I mean, ~why not~ - a solution is suggested in . A word of comment will be appreciated. cc .
hangs when given a derivation because of infinite recursion either error or treat it as a string, which all other generators seem to do <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
is there a context where a derivation would even be a valid input for this function? If not perhaps a simple fix would be to test for a derivation as input and simply throw a warning instead of continuing computation.
it shouldn't be possible to use derivation as a attrset for this function, but store paths could be useful which is similar to 's behavior
So this worked without error: I was able to reproduce the issue by just passing your example input above though, and in looks like nesting the derivation deeper also still causes the error. I guess we could map over the input at the start of the function and convert any unconverted derivations to strings before moving on. That should allow us to declare store paths and avoid this issue. Side note: you shouldn't have to restart your system to recover from the error condition; worked for me
I forgot SIGKILL existed. I removed the warning in the description
I have run into a very strange issue. I thought that the following patch should be all that is required to fix this: however even though I confirmed in repl that the conditional evaluates to false when passed `"${hello}", the codepath guarded by the conditional still seems to run anyway and fails with the following error: to add to the confusion, if I push the value one level deeper then it works fine:
i don't think ini support values at top level, or maybe its just the ini generator?
ah okay, then I guess my change is completely ineffective. I'll keep iterating :laughing:
Helm defaults to a kubeVersion 1.20.0, which is 3 years old. Steps to reproduce the behavior: Would expect that helm defaults to a kubeVersion that is apart of the supported Kubernetes compatibility. helm 3.12 should support something similar to kubeVersion 1.25 accorsing to their version skew, The last version of helm to officially support 1.20 was 5 minor version ago Unclear where this default version is being defined. Downloading the corresponding binary directly from (example: ) does not encounter this issue <!-- 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]:
Great timing! I just ran into this issue not to long ago but I'm unsure how to resolve it. (On mobile so I'm going from memory) there is a hard coded version in the helm or something like that, that can be overridden at build time. Presumably the helm team does override it. We can of course override it as well but I'm unsure how we can keep it up to date. It would be a 1 line patch to fix it for now but my question is, is there an automated way to keep it at the same version as whatever the helm team uses
normally helm takes the k8s version from the go k8s client lib and increments the first part by 1 to arrive at the k8s version. On my current dev system the output is as following (debian sid) In go you can directly set via as the Makefile does, but it's not always clear that those things can just be overridden that easily. i'd prepare a patch but i've no idea on how to add some script execution into to fetch the variables :/
I am not sure how to add in script execution either. As a low tech eventual solution, opened a pull request to resolve the issue upstream.
fetch-bower produces truncated nix-store entry when run under nix-build: Looking into the retrieved jquery in the nix store you can see jquery is actually missing: It works fine when trying to manually run it as a regular user: bower- generated by : run nix-build System: (16.09beta172. (Flounder)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: (16.09beta172.)
ping
Sorry for the delay I will test and merge today.
Hello thanks for your detailed report. I am getting slightly different results to you, so more investigation will be necessary. In my environment (NixOS 16.09 channel), there was no hash mismatch. Possibly something caused git to fail to download the jquery package. If it silently fails producing an incorrect result, then that is a bug in bower2nix which could be reported at
I am not sure this due to bower2nix. Fetch-bower is calling git and should handle the error's accordingly, no?
It consistently fails for me both on the latest unstable and 16.09 channels. Can you try updating your channels? My suspect was commit but I wasn't able to revert it cleanly to try it out.
By , I also mean . I have rolled the two programs into one repo. You are definitely right, is calling (indirectly, through the API), and should handle the error. I'm an avid subscriber to 16.09 and especially nixos-unstable, so have tested on those. Obviously it would be easier to fix the error handling if I can make fail myself. Do you have any further info about your setup which might be relevant? E.g. any proxy settings required for git to work. Can I also confirm that you are running before retrying ?
I don't have any proxy settings. Is it possible GitHub is rate limiting requests from bower? I found this thread interesting And yes I am running nix-store --delete before trying nix-build.
Hi are there any additional details I can provide? I am not that familiar with typescript or javascript, but I could try to narrow the issue down with some help.
How to reproduce: Expected output: bower package info json.
Actual output: nothing, not even an error message.
This problem is back. I can reproduce it by following the steps outlined in the top message. (latest nixpkgs-unstable) It did work for me a while ago though, so it looks like a regression. Did some digging around but I cannot figure it out. cc
Good catch, I think I've seen the same issue as well, but didn't bother (lack of time). Could be a different cause, but we have to start somewhere :)
Running produces correct result while -ing the following produces an output without jquery (just meta data)
Figured it out. Git doesn't see SSL certificates. I made it run with this expression I'll try to open a PR to fix this in nixpkgs. I'll also try to open a PR to bower2nix because there is a bug in it - missing SSL cert should not result in exit code 0.
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi Opened PR for this.
Package name: upterm Latest released version: 0.12.0 <!-- Search your package here: --- Current version on the unstable channel: 0.10.0 Current version on the stable/release channel: 0.10.0 <!-- 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. -- tried
Bumping to 0.12
Seems this need the vendor path now.
Every new firefox update/rebuild generates its own (new) profile. This is annoying, as we rebuild firefox whenever any of its dependencies changes. See: Start with the profile manager or with a custom profile
Should not it be just one profile per branch – one for stable, one for beta, one for nightly? Updating should not change the branch.
I thought that too, but at least for me it created 4 profiles already - could be, that the FF beta is not smart enough (yet). Anyway, now it's documented, so people hopefully won't get as confused as I've been when/if they reproduce this.
Can repro as well. Unfortunate!
Not explicit above, but the workaround is: you see "this firefox uses a fresh profile"... quit firefox profile manager with an older profile and "use as default profile" as normal until the next update
Related issue: and workaround:
Firefox 67 is now the stable release, when I upgraded unstable this morning I got hit with this issue, I'd guess a lot of other folks will shortly as well. Could the SNAP_NAME workaround be incorporated into the derivation until there is a fix from Mozilla? If there is a better fix out there then maybe that.
Just got made aware of the issues as well. I'd sway te SNAP_NAME workaround is okayish for now. I will try to get a patch made so that we do not need that in the future and have a proper kill-switch for that... Sorry for the troubles. I missed that during testing the latest release :'(
I opened a PR to add the workaround Will do the backport as soon as someone else can confirm that it works as expected.
Looks like the more general solution has been merged into Firefox and will be deployed with 68+. From The dedicated profiles feature is off when MOZLEGACY_PROFILES is set to 1 at environment level, while the downgrade protection is still enabled. Probably should coordinate a change to that environment variable name with the release of 68, though it looks like the SNAP version would work for a while after as well.
Can we set in the latest firefox now?
We could do that but that wouldn't work with former ESR / tor browser and probably a few other things. In the long run that probably makes sense.
I tried to install Roundcube with an non-local PostgreSQL. The DB user password should be stored in a password file. I ran into problems with this setup: the password file is used in two locations: the Roundcube the systemd that initializes the roundcube database Unfortunately the neccessary file content differs for these two services: the roundcube the passwordfile should only contain the PASSWORD (even without a trailing newline) expects an entry like "hostname:port:database:username:password" () So one of these two services will fail. Setup Roundcube with remote PostgreSQL server and password file for DB user password. My solution for now would be, to add a line to the roundcube Please run and paste the result. Cheers, Andreas
Your solution sounds reasonable to me, if you replace with something that takes into account escaped . Would you mind opening a PR? Tag me on it, I'll review it. As you can see the remote db feature of the module has probably never been used except by you; if you want this use case to be better maintained consider contributing a nixos test exercising it.
Fixed by
When typing something here: <img src="https://user-" width=50%The desktop crashes and you have to re-login (well it's Chinese in the screenshot but I hope you get the idea) <img src="https://user-" width=50%Steps to reproduce the behavior: budgie menu something crash No crash. See above. I don't see this issue before the GNOME 44 update. Probably another issue but I haven't go deep yet. I am on right now, it's nixos-unstable with pull request picked.
Backtrace points to <details</detailsLooks like there are changes on that touches after 10.7.1, I am testing that right now.
I gave the latest HEAD (i.e. ) a try and cannot reproduce the issue so probably some of the commits fixes the issue. I wonder if this can be reproduce by others and if some fixes can be backported before 23.05
Ohhh goooooood and now I am reading , let me make some noise there Edit:
And now I am on , which has glib 2.74 ( has 2.76). This is going to be weird because with G_SLICE=always-malloc I also cannot reproduce the crash (budgie-desktop 10.7.1), so probably not related to the slice allocator. Edit: and it's vala 0.56.4 on (no crash) and 0.56.6 on (crash)
Okay I guess I can basically confirm it's caused by vala update because I am now on and cannnot reproduce the crash, wow it's first time I know valac can really cause issues :seenoevil: Bisect is too painful for my slow laptop :upsidedownface:
Could you try compiling and running this Vala code on the broken version to see if it also crashes? It should do the same thing as the crashing Budgie code, just without crashing your desktop. If this ends up being a Vala issue, we need a minimal reproduction program to send.
Build and run with (assuming you put it in a file called ):
I am now on and my desktop crashes, so the current range is :upsidedownface: I am away from keyboard for the next few hours because it's midnight here but feel free to drop questions :upsidedownface: I built the program with vala 0.56.5, it exits normally with
Well, crap. I was hoping that would crash. Maybe this version when you get back? It's closer to the code in Budgie: Of those commits, the only one that really looks suspicious to me is at a glance.
I am still here (for now) :laughing: but this runs normally for me as well (hmmm can we really guarantee "if I can trigger the desktop crash, then using same vala same laptop same setup we can trigger a crash with some different program"?)
Even when vulkan is installed and working, opening chromium and going to chrome://gpu shows vulkan is disabled. Also chromium logs the following warning: Warning: Couldn't open Info: Couldn't load Vulkan at LoadVulkan () at Initialize () Running confirms that vulkan is installed properly and working. vulkan is installed and working with running chromium and go to chrome://gpu check if vulkan is enabled or disabled. vulakn is enabled in chrome://gpu Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(robert): channels(root): nixpkgs: Maintainer information:
Hey I think you meant to ping the chromium maintainers:
yes thank you!
Not sure if this is actionable, AFAIK Chromium's Vulkan support is still pretty experimental (depending on the platform). Did it even ever work before? Also: X11 or Wayland, which flags are you using for Chromium, and could you provide the full output? might be actionable but apparently it's only a warning so idk... You could use to figure out the complete path where Chromium expects . Relevant parts from the source code: ;l=43;drc= ;l=173;drc=;bpv=0;bpt=1 But since Dawn () is Google's WebGPU implementation this shouldn't even be relevant (yet). Anyway, I'm afraid you're on your own here as I don't have enough time to give it a proper look. (Potentially) also interesting/relevant: ,RAMandSwap,ChromiumWillEatItAll PS: I also finally submitted but that should only be relevant when using SwiftShader.
This issue affects also google-chrome.
seems to be relevant as it's ANGLE's Vulkan wrapper rather than the real libvulkan from the system. I only had a quick look through the source-code but it seems like we should definitely install it (but other Linux distributions don't seem to do it yet). Anyway, could you re-test this once is built by Hydra (maybe I can also give it a go during the weekend)? we already install for Google Chrome so it seems like there are some other issues as well. If you have time to debug/investigate that would be great (my older test system for Google Chrome lacks Vulkan support :o).
great thanks for looking into it!
will definitely try to test it over the weekend
unfortunately it does not seem to fix the problem. I still get the same warning that could not be load
Confirming this is also an issue on google-chrome-beta: (Excuse the unrelated dbus things) I'm not experienced at debugging this kind of thing but happy to give it a shot if there are any hints for where to get started. :) Edit: I did confirm that exists and paths seem valid.
If you have time it would be nice if you or someone else could use strace (or similar tools) to figure out where Chrome/Chromium is looking for . Something like (see - e.g. can be useful as well). It's a bit advanced though. I'm hoping that I can also give it a go soon (currently working on a few other Chromium TODOs).
Below is the strace output if it's any help. Pretty sure just the first ~2 lines are relevant. The first line happens when the browser opens, second line onwards happens after opening and the browser prints: (This is with stable, same thing happens with beta too). <details<summary<codestrace-fe file --timestamps google-chrome-stable OCLOEXEC) = 37 : 17:09:44 openat(ATFDCWD, "/nix/store/abmblk7xs49q0xhgkrp9izhab64jqri6-google-chrome-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/kxs3h7ffg2s061y9s8m00m5c6nbggg6f-libXScrnSaver-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/lbignzjfjydc4zb1d6qal3sjq7km3pqf-libXcomposite-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/6cy62r6hnzq5yqjj347p6dwv9pw21ixy-libxcb-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,
"/nix/store/1pj4gnng9ibcbd3cy4002lnyjwv2sjv3-alsa-lib-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/l9s8gcnh687p4cpkj0ic4ym180lpy9an-libXdamage-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/shjhw9gp0k78abd8mpd6jlgvbk17k2zv-libXtst-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/nfgwb2xk9jhidd4dh2l5j90kiyq17faa-libXrandr-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pb2i4d6q7fai3kiqrw9za8svisyrngh5-libxshmfence-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/6hwhq9szpm65zhcvhfw42gzdlyi7b2rz-gdk-pixbuf-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/aqwqh3drn9bf6qrs70wiyrxaawh1wcnz-systemd-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/iy5g2611yc6y6jzcmpm55bjbskhcydkm-libexif-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/g7y8adgr5fac89kzfx8ddm66253a3idn-pciutils-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,
"/nix/store/19x7vr6vqvqcq1fqpdlk01c2gzb5igdm-curl-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/2jd06jm9lfis3knm615wm3idw86wjr3i-util-linux-2.37.2-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/qlxl487zbn873xqmp7gb3if3g250kdx7-flac-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/019a19l65k3qs88wr6fyznk7dj86a6vg-harfbuzz-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/jvbyjnjh4w8qg7izfq4x5d2wy9lv9461-icu4c-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/f76ccq4s20agzdz3m5fdmrs23r249fzr-libpng-apng-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/ani3r9bxx7il7zn54miylbxdn4lb2si5-libopus-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/ap050qq8w9xnpaijzhh4njhqarilam9c-snappy-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/86dp2ryfg8akpa9r3ylqd3fpdhqhzmxa-speech-dispatcher-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,
"/nix/store/ckqhvpa7mg8181pfhd4gb1k834npjm89-bzip2-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/90v7y17p3s4mqlx8hmd75y5acsq3x9pl-libcap-2.49-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/qk4xw57jvy68ca2aikj1gzbpxg9rigi1-at-spi2-atk-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/b8s1yzzi7s1wpy5j5jqhhv5cw2vhdjxh-at-spi2-core-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/mypff9f5vvf41wrjz76dialpsj2k3wq6-libkrb5-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/4xgbyn6sv265gv86rmjgfypmlhh2rvj8-libdrm-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/csxbwm4sr4swzk7qidp0x3lhlsqg6vw6-mesa-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/wwcpra73jl6hgqxl908k1b0810pd6wv4-libxkbcommon-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/njzhva8b2idhdfzaqr09kq4wfdlddxki-pipewire-0.3.40-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,