jiebi/CodeConvo huggingface dataset:
Package name: fragments Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2.0.2 Current version on the stable/release channel: 2.0.2 <!-- 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.
should provide a QT client to freeciv, which is probably named if I had to guess. Steps to reproduce the behavior: only gtk client installed (see below) A executable. If applicable, add screenshots to help explain your problem. ! -( does not exist) ! The installed is indeed a gtk client. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (You were the last person to commit, so I choose you :) ) (I don't believe the listed maintainer exists). Please run and paste the result. Maintainer information:
It's not possible to lock screen in xfce unless "xlockmore" is installed. in in XFCE and try to lock without success and then retry to lock System: NixOS Emu Nix version: 1.11.2 Nixpkgs version: "16.03.973."
I think that's because there is no blessed lock screen for XFCE. tries XScreenSaver, GNOME Screensaver, XLock and SLock -- in that order.
Has a situation like this (multiple optional but at least one required dependency on an executable) already been handled in NixOS?
I think this is generally resolved by some kind of switch, but we have to add one. Something like of ...
I kept as-is: see
I think the issue may be resolved. At least with (as of 2023-09-17) lock screen is possible without having installed.
Project description linux-wallpaperengine aims to reproduce the background functionality of Wallpaper Engine on Linux systems. There already is a wallpaper-engine implementation packaged, but it only works on KDE, while this project should work with most Wayland-compositors and window-managers. Metadata homepage URL: source URL: license: gpl3 platforms: linux I tried to package it myself, but the "just compare with other packages" approach of the nixpkgs documentation was very confusing to me. If someone can point me to other documentation or anything helpful I'd be happy to try it again.
Sort of, it still runs under X fyi My rough process: check the repo of whatever you're packaging to see what language and tooling it uses read the nixpkgs manual for the language and tooling that you're building with find examples of other expressions in nixpkgs that use the same tooling to get an idea of the structure use something like to generate the boilerplate for the expression , get an error, use to find the required dependency (repeat this step until there are no more build errors) submit PR
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. Add a :+1: [reaction] to [issues you find important].
PR:
I've hit the same bug as described in The root of the problem seems to be missing configuration file which should be placed somewhere and made accessible by . It is used by, for example, in Emacs. cc
cc
I'm just getting this warning: Otherwise the output seems normal to me, but I've never really used the utility.
Oh, I see, is still a problem, as it used to be in Debian.
Actually, that config file is provided by package, so if I include it in , it works fine even with . Still, it's a bit confusing that the core provides binary but doesn't fully support it.
I currently can't see a simple way how to improve that.
I am not able to use on because it does not accept the option . In the command line I get: Is it related to this issue, or should I report a new issue?
cc When explicitly adding to there are checksum errors. The following patch fixes it for me: With that, does not give the error anymore.
Oh, no, they're updating files in-place on the only mirror. Many of them won't download anymore :angry:
Better discuss the mirroring stuff at this thread:
triage: this might have been fixed in the meantime, is that so?
it's still necessary to explicitly add the package, otherwise the problem persists.
Could anyone, please, provide steps to reproduce?
The "chktex -v" works for me, I have installed with .
works in but not .
This issue still persists as of today under the tetex scheme. the addition of the chktex package is mandatory to not get this error. I was getting this error in emacs: chktex: WARNING -- Could not find global resource file. chktex: ERROR -- Illegal verbosity level. I didn't thought that this was a NixOS related issue so this thread was quite hard to stumble upon.
I can't reproduce:
I guess I forgot . If I include that then it just gives "chktex: command not found". So how do I trigger the issue?
Steps to reproduce the behavior: try to install/build the package using nix-shell or nixos the Domain is no longer configured. Teamspeak Download Pages redirects to this place: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You might want to check out
Not merged yet
As a workaround, until this is fixed in nixpkgs: The file is still available at the Internet Archive. You can fetch it from there and write it into the store, with something like this:
After commit, just enabling does not work because node-red package is under Steps to reproduce the behavior: enable Pull package correctly ! I think the package option should be something like this instead of easy fix I guess I don't know where is found for nixos modules <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
on Hydra: cc
Since it's been building for me, checked if I was sitting on any changes and while the commit message doesn't indicate that it fixes anything (eep), it does seem to fix this issue: Don't remember enough details to justify it fully offhand (again d'oh for not writing it down at the time hehe) but hopefully this helps work towards a suitable resolution :).
Naturally this breaks in as well.
Yep, broken for me too. Haven't had time to tinker yet.
I have the same problem, but the commit mentioned fixes it for me.
So are we just waiting for this commit to be in the unstable channels?
A Go program compiled using nix-shell returns an error when running on a separate server and trying to load a timezone file. file with: $nix-shell $<inside shellgo build $exit $ ./app # name of the app you just created 2019/01/25 20:04:58 All went well: America/NewYork Now copy this file to another computer #./app 2019/01/26 01:01:34 could not load new york locationopen /nix/store/0596k27r6pacyx4jp1bcn8zqyjhji52l-go- no such file or directory The error includes the zip name due to internal reasons the Go team has, but the real problem is that nix replaced with I would be more than happy to send a Pull Request if you agree with the proposed solution of prepending instead of replacing. $ nix-shell -p nix-info --run "nix-info -m" these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked): /nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info copying path '/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info' from ''... system: host os: multi-user?: sandbox: version: channels(diego): nixpkgs: version is nixos-unstable-2019-01-22 The file replaces the path that the go runtime looks for the timezone information. Original Go code is: But nix changes the first entry, for This works fine if you end up running your go application in the same nix env you compiled it, but when you deploy your go program to a separate server, the path, that can look like isn't present on the separate server and then the lookup fails. is a very common path in Linux distributions. A better way to solve this would be to prepend the nix only path, as the first entry, and then keep and the other entries as they are in the original go source code. The benefits are that those who compile and run in the same nix environment will use the nix path, but those who deploy somewhere else won't have to do any extra work.
I doubt anyone ever considered support for non-Nix and therefore I will mark it also as . I'll leave it open for now as maybe it can be supported (I doubt it).
would you accept a PR with my proposed solution? It won't hurt nix deployments but will help a use case of building a go program in nix but deploying outside of nix.
cross referencing a thread on the mailing list about this ticket/issue so both conversations are linked.
Your explanation and proposed solution seem to be very reasonable to me. I suggest that you submit a PR.
Project description An end-to-end encrypted, peer-to-peer file storage, sharing and communication network. It's written in Java and uses IPFS. A bit similar to Nextcloud. Metadata homepage URL: source URL: license: AGPL3 platforms: linux (JVM)
Related:
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still important
I marked this as stale due to inactivity. &rarr;
Still important
I marked this as stale due to inactivity. &rarr;
I've a working package of peergos. after some testing i've experienced it a little buggy, so i don't want to push it into release. Let's see what i can do as it's my first package. The example bug: after i've created task, clicking "tasks" from left menu forces me to create new task. However thecreated task is visible in my drive.
Thanks!
Virtualbox corrupts guest filesystems by randomly flipping bits when the guest writes data to the virtual hard disks. virtualbox on the host with a new virtual machine for linux 2.6/3.x/4.x with default settings (1GiB RAM, 8GiB harddisk). "Insert" a linux live medium into the virtual CD drive. The virtual hard disk should be placed on a filesystem on a physical hard disk (the bug cannot be triggered if the virtual hard disk is placed on a tmpfs, see below). the machine and open a root shell after booting. these commands inside the guest's root shell to write random data onto the hard disk, then read it back and compare it: Caution: This will overwrite anything on the guest's virtual hard disk The shown hashes should match, but in 90% of test runs, they won't. This bug makes virtualbox quite unreliable: It is still possible to install NixOS inside a virtualbox, but during installation, Nix will report a couple of checksum failures, and sometimes the installation is to be tried more then once. After that, random failures of random programs occur. If btrfs is used, this will also complain about checksum errors. After observing this on my production machine with NixOS 22.05, I tried narrowing down the offending commit. To this end, I adapted the nixpkgs minimal live cd build recipe to build an image with virtualbox installed on it, and built this agains different nixpkgs versions. So most of my tests have been performed on a test machine booted from a usb flash drive. The offending commit seems to be . I guess that commit brings in some kernel patch, which is incompatible with the way virtualbox handles disk images. The bug occurs when the host's filesystem containing the disk image is or . In both cases, I tried with freshly created filesystems. The bug does not occur if the disk image is on (or it occurs with very low probablity). I haven't tried any other filesystems on the host. Just to be sure there isn't a general problem with virtualization: I failed to reproduce the bug with qemu and a qcow2 disk image. So it seems to be a virtualbox-only problem.
I observed the bug on three different machines (two desktop machines with NixOS 22.05 and NixOS 21.11, and one laptop with NixOS 21.11). I was also able to reproduce the bug with a linux live cd inside the guest. So the bug can probably be triggered by any linux in the guest. I haven't, however, tried with anything else (e.g. Windows). I was also able to reproduce the bug with a live iso based on (currently ), i.e., with virtualbox 6.1.30 (as opposed to virtualbox 6.1.34 from , currently ). By default, the virtual disk controller has it's checkmark "Use Host I/O cache" turned off in the vm config dialog. Turning it on doesn't help (). I cannot reproduce the bug with these linux kernel versions (all checked with current ) (4.19.247) (5.4.198) (5.18.4) So users of these kernel branches are safe ... until the breaking kernel patch also reaches these branches. <details<summaryFor the record: This is the build recipe I'm using for the live iso</summary<p</p</detailsMaybe I can try to bisect inside the kernel sources, but the compile-reboot-test cycle is quite slow on my machine. Strangely, I cannot find any reports about similar behaviour. The closest report might be . It would be interesting for me if this bug can be reproduced/verified by someone else. I'm not sure if this should be considered a kernel bug (the kernel should probably not change the way disk writes are handled), or a virtualbox bug (at the moment I don't know of any other software affected). kernel maintainer team: virtualbox maintainer: (by the way: I'm surprised there's only one maintainer for virtualbox. Thanks for your good work, ; I'm a heavy user!) This is my production system, which also shows that bug. But I did most of the tests to reproduce the bug and narrow down the cause with live iso images based on current ().
I bisected the linux kernel tree to find as the cause for the guest data corruption. Googling the commit's hash leads to this issue in the VirtualBox bug tracker.
According to the information therein, the bug only occurs on some CPU models. The issue there also contains two patches: from This one fixes the problem on linux 5.18. It got already included in nixpkgs' master branch with . It is on it's way to being backported to NixOS 22.05 with . Note that this patch contains several clauses and does not fix the problem on earlier LTS kernel versions. from This one fixes the problem on linux 5.18+, but also on LTS kernel versions. I tested the following combinations with (currently on , where VirtualBox 6.1.34 with and linux 5.15.51 are used by default): VirtualBox version & patch 5.18.8 -----------------------------:------: 6.1.34 + OK 6.1.34 + OK I also tested the following combinations with (currently on , where VirtualBox 6.1.30 and linux 5.15.49 are used by default): VirtualBox version & patch 5.18.6 -----------------------------:------------: 6.1.30 won't build 6.1.34 + OK 6.1.34 + OK To replace VirtualBox 6.1.30 with 6.1.34, I cherry-picked . All tests have been performed on an Intel Core i5-4460 as host, by repeatedly writing/reading 4GiB of random data onto/from a virtual hard disk. Based on these tests, I suggest to use VirtualBox 6.1.34 with the in NixOS 22.05 and in NixOS unstable, as currently, both channels will exhibit the bug in their default configurations (i.e., with kernel 5.15). I will submit a pull request for master shortly.
qimgv fails to build when . Steps to reproduce the behavior: No build errors. N/A. N/A. Maintainer information:
I am working on a patch to OpenCV to fix this issue correctly. In the meantime, you can replace with and it will build and operate properly. On my system I also had to add to to stop it crashing when I tried to open a file dialog but maybe that is just because I run Nix on Ubuntu instead of NixOS.
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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: gping <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.2.1 desired version: 1.2.6 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them.
It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source.