jiebi/CodeConvo huggingface dataset:
The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.
Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?
I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.
Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.
Steps to reproduce the behavior: trueseeing dependency check fails due to missing termcolor. Full logs : <summary<details<preSourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing pypa-build-hook Using pypaBuildPhase Sourcing python-runtime-deps-check-hook Using pythonRuntimeDepsCheckHook Sourcing pypa-install-hook Using pypaInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook Sourcing python-catch-conflicts- { "action": "setPhase", "phase": "unpackPhase" } Running phase: unpackPhase unpacking source archive /nix/store/p05bg72wb6ihkj9jjmdgzsnjifd0m0ar-source source root is source setting SOURCEDATEEPOCH to timestamp of file { "action": "setPhase", "phase": "patchPhase" } Running phase: patchPhase { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" } Running phase: updateAutotoolsGnuConfigScriptsPhase { "action": "setPhase", "phase": "configurePhase" } Running phase: configurePhase no configure script, doing nothing { "action": "setPhase", "phase": "buildPhase" } Running phase: buildPhase Executing pypaBuildPhase Creating a wheel... Getting build dependencies for wheel... Building wheel... Successfully built trueseeing-2.1.9-py3-none- Finished creating a wheel... Finished executing pypaBuildPhase { "action": "setPhase", "phase": "pythonRuntimeDepsCheckHook" } Running phase: pythonRuntimeDepsCheckHook Executing pythonRuntimeDepsCheck Checking runtime dependencies for trueseeing-2.1.9-py3-none- termcolor not installed </pre</details</summaryAdd any other context about the problem here. <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: I believe trueseeing is missing the termcolor dependency hence the failure happening during the build.
I can try and PR a fix but I did not try and reproduce the bug under NixOS. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems a lot of other packages have broken in similar ways, mitmproxy, ioccheck, theharvester but they all fail due to missing runtime dependencies or version of modules that are not meeting constraints.
I had the same issue with mitmproxy and found this issue because you've mentioned it here. ~git bisect for mitmproxy pointed to this commit for me: ~ Edit: apologies, I used git bisect wrongly. The first bad commit seems to be .
This seems relevant:
That shouldn't change whether or not a package builds.
Yeah, my nightly session of bisecting for pointed to , which is from . I guess affected packages do have to be fixed one-by-one manually.
shadowsocks-v2ray-plugin doesn't work anymore in nixos-unstable. Try to use it with shadowsocks-rust. Here what I have in logs: It works. If applicable, add screenshots to help explain your problem. Add any other context about the problem here.
Version from works.
Looks like it got updated again: :)
cc
Just a note - it seems v2ray plugin is not maintained, but maybe can be used instead.
Configuration summary shows several incorrect paths: liblouis tables can probably be easily corrected, not sure what to do about cups dom socket and font directory. nixpkgs: cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Steps to reproduce the behavior: alternatively (the output is the same) Found this while trying to build on my mac I also tested this running on my nixos work computer instead of via a remote builder and got the same result. <!-- 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. Though the actual building is done by a remote builder with .
Fortunately it seemed OK after a quick glance, on x86_64-linux at least. Feel free to review.
Yep, this seems to have fixed it, thanks :) building a static lmdb seems to work for at least x86_64-linux and aarch64-darwin. I'll continue my adventure of trying to get murmur to build statically
twmnd does not launch because qt5 library path is missing. Install the twmn package and run twmnd. twmnd works when I manually set the LDLIBRARYPATH to <qtbase/lib. System: NixOS 16.09.931. Nix version: 1.11.4 Nixpkgs version:16.09.931.
I noticed the same or similar thing when trying to run twmnd as a systemd user service. It just SIGABRTs: I could reproduce with Although works fine... So clearly there is some impurity in my local environment which is making twmnd work "by accident?" Possibly related?:
the attribute inside a user-level systemd service seems to be ignored. I have three observations to suggest this. With this snippet from (service details aren't important, just for concreteness) If I run , I see batterycheck.service, but no corresponding timer. If I run , I again see the .service file, but no timer file. If I remove the startAt line and run , I can see from the output that no new environment is being built. I'm pretty sure that this functionality used to work several months ago, when I created this unit definition.
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:
Describe the bug gitea fails to start due to a too restrictive systemd setup To Reproduce Looks like is a bit too restrictive. :smile:
ping
Removing the blacklist of and gets us past the test, I think, but there's still problems with the socket.
Judging from this error output: it looks like it fails in prescript during in Interestingly enough, there is a right underneath that, in which does not seem to be the issue. This does not look like an issue with Gitea itself, since it fails during the service pre script. Since the and will only be run if the configuration is managed by nix, the tests pass if I set in the test config. (unfortunatly I don't know much about systemd services and especially systemd sanboxing, so I'm not sure if the information from above is useful or not)
Any chance the service is broken too? I recently updated and service failed to start. I haven't dug into it yet... I may have seen something about a database permission issue.
Temporary fix for someone who using bleeding-edge Gitea:
This doesn't solve the issue for me. I get the following output:
Pretty strange. It works for me (). You can try to disable it at all () and if it'll still not work then just change in the same way all other parameters to default values that were introduced in . p.s. probably there's must be something like a mkForceRemove, but I haven't found anything in manual.
Ok the fix is actually working, I just had an own AmbientCapabilities definition in my configuration which didn't play nicely with the new options.
For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.
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 I'd like to work in this issue. First one with documentation so I will probably need to understand a few things first.
Thanks, let us know if you need help!
Hi thanks for picking this up. Are you still working on this? If you're stuck, you could create a draft PR so someone can help, or if you've changed your mind that's also ok.
Hi Sorry for late reply. I worked a little bit, on and off during the holidays, I do not finished yet, I had some problems during the build of the documentation, but from what I read (pandoc output) I made some mistakes during the file conversion. For now, I didn't commit, It's on my personal computer only. As the week is a little difficult, I'll see if I finish it at the weekend. (Maybe I should have asked for this issue just now, just see 14 days ago and I was like "What ?! That was 2 weeks ago ?!" LOL) Thanks for asking!
Hi I followed your suggestion to create a draft PR, at the moment I'm stuck in two things, the first is how to create a note and the second reference errors during the build of the documentation. For the first, pandoc created notes with the following formats: , in this case I should use the default way to create notes in markdown (using ) or wrap this in docbook way? If I remove the references that generate the error below, I can verify that using the markdown format, this note is styled differently from the rest of the documentation. And for the build errors, here is log: For this I tried per but build fails with same error. Any help is appreciated.
Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. &rarr;
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?
I'm using NixOS "/ on tmpfs" mode, so I persist my dconf by using a module of home-manager. When I persist the state of GNOME app drawer, I need to write down desktop file name to .nix config. But currently, Android Studio's desktop contains a string of version, this because contains . Details: I also notice used in icon too, which will cause icon file contains version string, I think we can remove them too. If maintainer agrees, I will make a PR to deal with this. Also, I noticed another maintainer deleted the account: Maybe I can send him / her an E-mail for asking what happened, and drop the maintainer info.
On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.
Enabling fails with: Steps to reproduce the behavior: and enable Nextcloud The notify_push service starts. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Hm, I thought I had tested that. Can you test if it works if you modify the module to drop the parameters from the script where it executes ?
Doesn't work either. I don't know PHP, but it seems that is unable to parse the inline function.
Yeah, notify_push is written in rust and doesn't actually execute php to parse the config, which is why this doesn't work.
Upon further investigation, dropping only works. Dropping the whole result a failure with: It needs an option to set .
can be set like . Maybe we should transition away from putting a function into the nextcloud config and just modify the file in the setup service.
it works, but if the Redis URL has a password it ends up in the Nix store.
I have the same and I can't reproduce this issue.
do you have the line in your ? I think the reason is because I'm using an external DB and S3 storage.
If you have passwords used in the config the nixos module does inject that lookup function. In the initial PR of notifypush was already a discussion how to handle that, and there was already a suggestion to drop I dont remember why it was not done there, i basically withed to non password authentication (as everything is running on the same machine anyways, so using the socket solved the issue back then, so i forgot about it).
nope, I am using socket authentication.
After switching from 21.11 to unstable and a clean reboot ts3client crashes as soon as it tries to access the microphone. Steps to reproduce the behavior: to current unstable ts3client to a server or click Options -Recording -Test Not crash when using microphone Attached the coredump i am receiving. I am using pipewire in this context, but i can't circumscribe the issue on pipewire as other applications still work and are able to record without issues, also switching pipewire out and use pulseaudio seem not to solve the issue. I tried to overlay the package with libForQt512 (just playing around with it) as one of the differences between stable and unstable are version changes on qt libraries. But that did not fix anything. I have also tried the flatpack version, to check it there is something wrong with my pipewire config, but the flatpack version runs fine. Switching back the nixpkg from unstable to 21.11 and rebooting fixes the issue, so at least would tackle it down to changes related with changes in unstable. As stable and unstable ship the same ts3client version it has to be somehow related in between, or (hopefully not) just on my machine. I would not rule out that the issue is somewhere on my side. Please run and paste the result.
Running the version of a previous nixpkgs works just fine, even with an up-to-date environment. It must be a problem with the ts3 drv itself. I'll hopefully have time to run a bisect later.
Bad is which is a staging-next merge. Bisecting staging-next now...
Bad is . (Note: Injecting a cached qtwebengine saves a lot of time here and doesn't falsify results.)