jiebi/CodeConvo huggingface dataset:
We got theses reports of Kubo panicing on startup due to probably an empty field This is a bug in our software however I belive this is also a bug in: Because a Kubo daemon without an API listener is borderline useless, your choice to change to a unix socket () makes sense however I think some default got lost and now it is set to . Given I am not a Nix user myself I got help from to fill in the template, thx :heart:. Steps to reproduce the behavior: to notice it's failing with a panic. After installation Kubo daemon should start and the RPC should be usable by a permissioned user. Please run and paste the result.
/cc (I forgot to fill it in the template and I don't belive GH pings peoples from edits)
Weird that it works on my machine and in the NixOS tests. One of the NixOS tests only has and options set. does quite a lot but I didn't see anything obvious why this should affect the API settings. But maybe it does make a difference and maybe I specified some additional option on my machine makes it also work there. I'll try to reproduce it with just the enable option set in the next couple days. On one machine shows that the field is set to and yet Kubo starts without a problem and can be seen in the log. According to a comment at the top of, , "Enabling this [socket file] will completely override any API listeners configured in your config.". NixOS enables this socket file and overrides with (which is ) plus whatever the user has set in . What I don't know is how systemd communicates this information to Kubo but this seems to work. So in conclusion, I would think that setting the field to in the Kubo config doesn't matter because is enabled, which should override this and specify a socket for the API.
Thx I wasn't aware we even had this feature (or that you could use systemd to configure application sockets in the first place). We have a simple incorrect assumption which is panicking since kubo is configured without listeners. However this is fed by which tries to load as you linked. So if you have a but use something like it should work (AFAIT).
I can't test experimentally that feeding the API through systemd works right now, I'll report later, but it seems to me that the like config is not applied somehow.
I was able to reproduce the problem. Maybe I just need to order the unit after the two socket units. I'll take a closer look in the following days when I have some more time.
This happened to me too on first installation, the reason was that systemd couldn’t bind port 8080 because it is already in use by another service, then started Kubo anyways. So my theory is that Kubo checks if there was a socket made available by systemd and if there was none falls back to trying to read the listen address from the config (which is then null) and then panics in the observed way. For anyone else affected by this, run and check if both sockets were correctly bound when Kubo crashes in this way.
I created , which should fix this.
Bug description nixos-build switch produces a build error due to firebird-2.5.7.-0 while firebird is not explicitly mentioned anywhere in the file... To Reproduce -channel --update -build switch error message a few apps from file hoping that one of them would be asking for firebird to be installed behind the scene at no avail... Expected behavior A clean error free build. Screenshot ... making all in engines/ccgost... g++ -DREENTRANT -I. -I../common -I../common -I./unicode -I./.. -DREENTRANT -DHAVECONFIGH -DULAYOUTIMPLEMENTATION -O -c -DPIC -fPIC -o HebrewLigatureData.o make[2]: Entering directory '/build/openssl-1.0.2u/engines/ccgost' gcc -I../../include -fPIC -DOPENSSLPIC -DOPENSSLTHREADS -DREENTRANT -DDSODLFCN -DHAVEDLFCNH -m64 -DLENDIAN -O3 -Wall -DOPENSSLIA32SSE2 -DOPENSSLBNASMMONT -DOPENSSLBNASMMONT5 -DOPENSSLBNASMGF2m -DRC4ASM -DSHA1ASM -DSHA256ASM -DSHA512ASM -DMD5ASM -DAESASM -DVPAESASM -DBSAESASM -DWHIRLPOOLASM -DGHASHASM -DECPNISTZ256ASM -c -o egosterr.o egosterr.c g++ -DREENTRANT -I. -I../common -I../common -I./unicode -I./.. -DREENTRANT -DHAVECONFIGH -DULAYOUTIMPLEMENTATION -O -c -DPIC -fPIC -o HebrewShaping.o g++ -DREENTRANT -I. -I./common -I./common -I./unicode -I./. -DREENTRANT -DHAVECONFIGH -DULAYOUTIMPLEMENTATION -O -c -DPIC -fPIC -o IndicClassTables.o gcc -I./.
/include -fPIC -DOPENSSLPIC -DOPENSSLTHREADS -DREENTRANT -DDSODLFCN -DHAVEDLFCNH -m64 -DLENDIAN -O3 -Wall -DOPENSSLIA32SSE2 -DOPENSSLBNASMMONT -DOPENSSLBNASMMONT5 -DOPENSSLBNASMGF2m -DRC4ASM -DSHA1ASM -DSHA256ASM -DSHA512ASM -DMD5ASM -DAESASM -DVPAESASM -DBSAESASM -DWHIRLPOOLASM -DGHASHASM -DECPNISTZ256ASM -c -o gost2001keyx.o gost2001keyx.c error: narrowing conversion of '' from 'unsigned int' to 'icu30::IndicClassTable::ScriptFlags' {aka 'int'} [-Wnarrowing] 229 | static const IndicClassTable teluClassTable = {0x0C00, 0x0C6F, 3, TELUSCRIPTFLAGS, teluCharClasses, teluSplitTable}; | ^ error: narrowing conversion of '' from 'unsigned int' to 'icu30::IndicClassTable::ScriptFlags' {aka 'int'} [-Wnarrowing] 231 | static const IndicClassTable kndaClassTable = {0x0C80, 0x0CEF, 4, KNDASCRIPTFLAGS, kndaCharClasses, kndaSplitTable}; | ^ make[4]: [./config/mh-linux:43: IndicClassTables.o] Error 1 make[4]: Leaving directory '/build/Firebird-2.5.7.-0/extern/icu/source/layout' make[3]: [Makefile:98: all-recursive] Error 2 make[3]: Leaving directory '/build/Firebird-2.5.7.-0/extern/icu/source' make[2]: [ libicu] Error 2 make[2]: Leaving directory '/build/Firebird-2.5.7.-0/gen' make[1]: [Makefile:193: externallibraries] Error 2 make[1]: Leaving directory '/build/Firebird-2.5.7.
-0/gen' make: [Makefile:6: firebird] Error 2 builder for '/nix/store/589jgyzjbbn6zl870qswm80pi4xh8ffq-firebird-2.5.7.-0.drv' failed with exit code 2 building '/nix/store/f5v53hni9pnldx4l0v4svxv0ibl62ir3-tor-browser-linux64-9.0.9en-'. cannot build derivation '/nix/store/c1wpclz112ssp5ki6m546llszn144bq8-wt-': 1 dependencies couldn't be built cannot build derivation '/nix/store/8izfzp2k51zz3385cq14ffd31l2c8bwg-fileshelter-': 1 dependencies couldn't be built cannot build derivation '/nix/store/wi7fzbgmwj9rrzm48mlcsvw51lymmcz8-system-': 1 dependencies couldn't be built building '/nix/store/75r17sql3df7jq3azd76w9fjw6870wm6-'. building '/nix/store/0zq0cb92k0w72ri9jb2zd65gzpnhx6fv-udev-'. building '/nix/store/jqc775s8a0m6r6qhwcfssjdya326s6z0-unit-NetworkManager-'. building '/nix/store/bvg0a7ah4bd77s86f16rq7jsl7sh3nxy-unit-NetworkManager-wait-'. building '/nix/store/vbnnzk9kdx828c8vi3pqcjayrf1ja43n-unit-'. building '/nix/store/df1ffd22pbca5x7ya5mwa8prm40mg54p-unit-alsa-'.
cannot build derivation '/nix/store/4375h9w8pmppld22s4jb6ag05riw87vg-xsession-': 1 dependencies couldn't be built cannot build derivation '/nix/store/gi689m2ph1avv6n2svvlzr5d2v2xm4p1-nixos-system-bx26-': 1 dependencies couldn't be built error: build of '/nix/store/gi689m2ph1avv6n2svvlzr5d2v2xm4p1-nixos-system-bx26-' failed Notify Weber <marco-<!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata* system: host os: multi-user?: sandbox: version: channels(root): channels(k): nixpkgs:
This is pulled in as an indirect dependency of via .
I marked this as stale due to inactivity. &rarr;
Versioned QML import paths introduced in will lead to broken kde applications. Issues include visual glitches, disabled mouse scroll, and potentially other functional problems. A temporary workaround exists, but a proper fix is needed. Steps to reproduce the behavior: your nixpkgs to leatest version. a KDE application that uses Kirigami (e.g., KDE Systemsettings). broken behavior (visual glitches, scroll issues). with . (this partly undoes changes) expected behavior. KDE applications run normally without any visual or functional issues. Start application normally: ! ! Start application with : ! Qt related configuration of my system: Although Kvantum is installed, disable it won't fix this issue. Same problem also occurs under breeze theme. <!-- 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]:
Can you post the values of and in the environment you're running it from? Also, does this still happen if running with those variables unset?
Here is my environment. <details</detailsThis still occurs when running with .
Can you run it with and post the log?
As requested, I've attached the relevant logs for analysis: ,captured with , captured with The initial attempt with didn't produce desired logging output. Therefore, I ran it again with the additional setting.
Does it work if you add and to ?
It works. QML components render normally now, under both Breeze and Kvantum themes .
I also encountered this issue. Adding and to alone didn't fix it for me. I needed to set as well for it to work.
Steps to reproduce the behavior: librewolf from nixpkgs master Add any other context about the problem here. Please run and paste the result.
I have the exact same issue but my machine is a little slower :|. Also this means (not just Git ) is now broken.
I also reproduced this on master.
I think it's related to . I'm guessing the crash reporter symbols aren't generated because we disable the crash reporter. Running some tests to confirm.
is the first broken commit on master.
I'm going to close this. The PR by fixes the problem.
Describe the bug fails to build on armv7. It compiles, but then fails one test, making the derivation fail. To Reproduce on armv7. Expected behavior The build completes successfully, passing all tests (except for tests known to be broken). Screenshots Additional context I'm currently trying this on , but with reverted because of . I'm using '<nixpkgs/nixos' since I have a few options set to minimize build times and I'd prefer not bootstrapping from gcc/binutils/etc just to see llvm fail later, but if you insist I can try building it with a clean config. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Note that that is showing the nixpkgs version for my currently running system. I'm trying to build it for a newer version of nixpkgs, listed above. llvm11 failing is currently blocking me from upgrading since I need borgbackup and it has a transitive dependency on llvm11 now (through the Python cryptography module and rust). Maintainer information:
Darktable can make use of OpenCL, but the nix package apparently isn't set up properly to allow this. Run : system: host os: multi-user?: sandbox: version: channels(root): channels(lukas): nixpkgs: OpenCL is set up properly on my system: cc darktable maintainers:
I'd been meaning to fix this for myself for awhile. Should be good now, pending review.
Thanks!
Sorry to revive this, but I am still having this problem in dartable 2.4.4 using intel OpenCL Neo driver. Should ti be already solved? Or the fix is still not present in 2.4.4? Thanks
Disregard (at least partially) my last comment. I was using the snap version in Ubuntu 18.10. Using the deb, OpenCl works. Where should I submit the bug for the snap version?
Steps to reproduce the behavior: diffutils-3.10-riscv64-linux i had suspended the system halfway through the build, and suspected that might have caused an issue, so i ran the build again 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't reproduce this failure on RISC-V hardware. With , the following command runs just fine: Could this be an issue with the emulator you're using or a result of ?
The following command also builds for me. Relevant excerpt of the logs: Could you try running this in your build environment to see whether it's an issue with your emulator or build machine? If it builds, could you improve the reproducing instructions you've given?
I ran that command on a seperate x86 machine and recieved the same build failure
I have successfully reproduced the issue by emulating RISC-V on an x86 machine. So this could be caused by a QEMU bug. I suggest you update the title to make it clear that it only happens with binfmt emulation.
Ok i edited the title
i'm curious why the gnugrep pr was merged, but not this one ? given that confirmed this build failure, but not the other one ?
The other one just got the attention of a committer a bit earlier
was recently updated to use LLVM 4.0, which is rather good news for my use cases. Can we update our version to use this? It also seems they now so perhaps we should switch to using that as well? (maintainer)--LMK your thoughts and if you want to tackle it or want me to (I'd probably get to it this weekend). Thanks!
I'm pretty busy these days but if you're interested in updating it feel free :+1:
Sure thing! Although actually we'll need to actually add LLVM 4.0 first, forgot that wasn't in-tree yet :innocent:. Maybe I'll give that a go as well :+1: (cc )
Incus fails to find when launching a VM. (There is no problem launching a container.) It exits with the error message: Lines 1815-1824 of in the looks for it at or in the path. I think it means that there is a fixup that isn't being done. Steps to reproduce the behavior: (The specific image doesn't seem to matter.) while the VM is created... It exits with the error message above. that is installed at just not being found. Launching a VM should work as expected without the error message. <!-- 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]:
While that path does appear to be hardcoded in Incus, I'm not able to recreate the error on my zfs storage pool. Can you provide more information about your storage setup, including the output of
Never mind I see the problem. Will take some time to get this reviewed, backported, and available to 23.11
Steps to reproduce the behavior: xdg-desktop-portal-hyprland-1.3.3 This issue only recently occurred upon updating to the latest revision. My entire nix config is . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I suspect this is fixed by For some reason has a pkg-config that defines that it has a non-existent include directory, which cmake then later chokes on since it declares it has a dependency on as a package, not a tool.
Indeed. I'm cooking up a PR for this.
When tries to create a volume of type=block, it cannot be created due to the occurrence of . This is because is not registered in . Steps to reproduce the behavior: Create block type volume. If you check nixpkgs for lxd 5.20, you can see other package dependencies that are not present in incus. For example with lvm, this is expected to severely impact the lvm backend. (Currently, it cannot be confirmed because there is no lvm drive.) Can we change it in the same way as lxd? <!-- 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]:
Opened a PR to fix. Sorry about that. Not sure why I dropped these...
The original author of gitless has not committed any code to it since 2021, and the version currently in nixpkgs errors out when trying to do anything useful with it. has forked and continued to develop it though: Package name: gitless Latest released version: 0.9.17 Current version on the unstable channel: 0.8.8 Current version on the stable/release channel: 0.8.8 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.
Thanks for the tag! I'm glad that gitless can live on past the initial MIT research that was conducted. Although it's been a while since I've updated gitless, it has been very useful for my day to day work and I'm committed to fixing bugs in a timely manner.
Sure! I rediscovered gitless (and your fork) on the back of a recent Slack discussion with folks from about the best way to make version control as accessible as possible for newcomers in the research community.
Version V1.3.0.4373 of mwprocapture (the Linux driver for the Magewell Pro Capture family) FTBFS when building against Linux 6.8 or newer. Steps to reproduce the behavior: Add to your Nix configuration. Add to your Nix configuration. Magewell has provided a revised driver update to address this issue. I am working on a pull request for nixpkgs. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Steps to reproduce the behavior: sysdig Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on master () and the error isn't in the log output, can you provide additional info?
Hey, thanks for the response - checking again - it only happens if for me if I enable the sysdig-option in my config not building the sysdig-package - maybe this helps to reproduce and depends on the used kernel-version? I've uploaded the full build log:
Thanks, seems this is the error:
I guess this is already fixed upstream in the drivers () but needs to be to nixpkgs to fix 6.10-kernel builds.
fixes it for me
~Ah 0.38.1 - got released somehow oversaw it should check first if that includes the fix~ 38.1 does not include a driver-bump
Describe the bug When adding to the NixOS configuration the udev rules do not get installed. To Reproduce Steps to reproduce the behavior: mixxx with a DJ controller plugged in. controller is not recognized by mixxx Expected behavior The udev rules are in the correct folder i.e. or and therefore the udev service does not recognizes them. Additional context The fix in worked for me after a little modification (the rules file got renamed). Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Originally, mixxx did the right thing = install udev files to - see Later they changed the behaviour and they install to - see Sigh.
The package with that are automatically fetched carry no license. ` cc
Poking upstream does not seem to yield anything. They did indicate they wouldn't support this use case, so what are you expecting from them?
I talked to the authors of wp4nix and they are happy for new contributions. It would be nice if the wp4nix script would somehow handle license informations, for example by manually defining them. Not quite sure yet how to implement it
If we don't know the licenses to these packages we honestly cannot keep them around. For example, it is absolutely unclear, whether we have a license to even redistribute them. Of course upstream will take patches, but they're not exactly in the same boat we are. I think your attitude towards the whole licensing situation around wp4nix/nc4nix and its resulting packages is alarming.
As written : Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Couldn't we mark them as unfree so they don't get cached on hydra but people can still use them if they want? Unfortunately it seems like the wordpress plugins repository doesn't seem to provide the license information in an easy manner. And I don't know whether it is stored somewhere else or can even be extracted from the derivation without import-from-derivation.
Actuallly we seem to be safe in theory. claims
In an ideal world, that would hold true, but it is up to the user and distributor to validate the final outcome. I therefore think this situation remains unresolved.
Project description cameractrls is a UI for v4l camera settings, like pan/tilt/... on fancy Logitech cameras. Metadata homepage URL: source URL: license: MIT platforms: Linux
Here's a prototype:
I'm using this successfully with the latest version,
Is there any progress with this request?
Please test my PR I don't have the device.
Tbh, I would like to, but I don't know how to test a custom package...
For new CLI: Or
I executed and then nothing happened... I can also not find cameractrls
Check your current directory, there's a symlink to store, and the executable is in
I only tested the gui app and it seems to work fine!
Thanks! What about the others executables? Have you tested all the functionality of the app?
I can only test the the GUI, because I don't know how to use the CLI program. But the GUI is working fine, afaict.
When enabling freshrss and rebuilding, no freshrss systemd service is started. Steps to reproduce the behavior: (as well other requirements for minimal config) (with , for me) The only freshrss units are and . to in browser. Unable to connect. A service with (or something?) is created and runs automatically. The http server is accessible from a browser. I initially tried running in a container, but running on the host OS had the same result Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Freshrss doesn't run as a systemd service. It runs under php-fpm. The associated systemd service is . This is then exposed via nginx. I believe the default nginx configuration will expose freshrss on port 80, so http://localhost may work for your current configuration. The used by nginx for freshrss is . My guess is you'll need to configure it. If you want to access freshrss via "http://localhost:8080" you could use a config like:
Sorry I never responded to this! This worked, thank you.
i guess we can close this then? please report back if i am wrong.
I do agree with qyriad that this could be explicitly documented better, but I don't have any further issue to specifically track
any specific location where you want this documented? where would you look something like this up?
I would probably put in the description of the option.
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!
Linux Kernel 4.7.3 seems broken, as my laptops keyboard doesn't work. experienced by the arch community too: update, reboot - 4.6 and 4.7.2 work, 4.7.3 doesn't nixos-version: (Gorilla) nix-env --version: nix-env (Nix) 1.11.4 nix-instantiate --eval github/nixpkgs -A lib.nixpkgsVersion: ""
Same issue with kernel 4.4.20 (lts). I can no longer enter my cryptsetup password. The reason is that i8042 is no longer integrated in initramfs, I suppose because of: Update: To fix this issue I had to add it to
Thanks, created a quick fix with your solution, which should fix it for everyone
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ) Tested on nixpkgs
PR was merged and made it to nixos-unstable, so this should be fixed