jiebi/CodeConvo huggingface dataset:
Code change:
The Zen kernel is failing to build for me since the update to 5.18, and so I thought I'd open an issue since I can't seem to find any existing info about it. Bisected to system: host os: multi-user?: sandbox: version: channels(root): channels(alex): nixpkgs:
Looks like it didn't build even in the CI of : But, we already have a new version: Cc (since you're always the one to bump it)
Unfortunately 5.18.1 doesn't seem to build either for me. :( Given that the file in question hasn't been touched in months, I'm wondering if this has something to do with the move to C11 for the 5.18 kernel. But that's just a guess. I can think of two possible quick solutions: Include a patch that adds a comment Ignore that warning everywhere in the kernel
Staging recently got change to avoid Werror-style failures.
Given that that change will take a bit to get to master, do you think it would make sense to set for just the zen kernel in the meantime? Or even just revert and move it to staging so that it gets merged when the change does? I'm asking because—while it's not too much trouble to add patches to my personal NixOS configuration—right now the zen kernel is broken for everyone, and so it might be a good idea to get it back to a working state in the meantime. I'm not sure how many people use the zen kernel though, it seems to be not very many, and so if it's better to just leave it as-is for a bit that's fine too; I don't really know how such things are usually handled in nixpkgs and am trying to learn. :)
I'd say setting for zen kernel is perfectly fine. Should be a matter of adding it to Do you want to give it a try and propose a PR? AFAIU you already run that kernel version and have a chance to validate it if still boots. You could also add a TODO to remove it once staging is merged.
should've gone to master and/or be merged with the next kernel bump or something if the rebuilds were that critical which I don't think they are. We could cherry-pick it if we need it now.
I made , but it's late here so I don't have time to test it properly and am waiting to open a PR until I can do so. It at least builds though. I figured while I was at it I should also bump the version to 5.18.1-zen1, but in hindsight maybe I should wait until the mainline kernel is updated to 5.18.1 in nixpkgs? Anyway, I'll test it when I have time tomorrow evening, make any necessary changes, and open a PR, unless we decide to cherry-pick ? That seems like a nicer solution to me personally, but I don't really have a strong preference.
I finally got around to testing this and opened a PR: :). I'm personally in favor of cherry-picking , though.

Related discussion:
text: let # having the full version string here makes it easier to update <del> modDirVersion = "5.18.0-zen1"; </del> <ins> modDirVersion = "5.18.1-zen1"; </ins> parts = lib.splitString "-" modDirVersion; version = lib.elemAt parts 0; suffix = lib.elemAt parts 1;
Code change:
The Zen kernel is failing to build for me since the update to 5.18, and so I thought I'd open an issue since I can't seem to find any existing info about it. Bisected to system: host os: multi-user?: sandbox: version: channels(root): channels(alex): nixpkgs:
Looks like it didn't build even in the CI of : But, we already have a new version: Cc (since you're always the one to bump it)
Unfortunately 5.18.1 doesn't seem to build either for me. :( Given that the file in question hasn't been touched in months, I'm wondering if this has something to do with the move to C11 for the 5.18 kernel. But that's just a guess. I can think of two possible quick solutions: Include a patch that adds a comment Ignore that warning everywhere in the kernel
Staging recently got change to avoid Werror-style failures.
Given that that change will take a bit to get to master, do you think it would make sense to set for just the zen kernel in the meantime? Or even just revert and move it to staging so that it gets merged when the change does? I'm asking because—while it's not too much trouble to add patches to my personal NixOS configuration—right now the zen kernel is broken for everyone, and so it might be a good idea to get it back to a working state in the meantime. I'm not sure how many people use the zen kernel though, it seems to be not very many, and so if it's better to just leave it as-is for a bit that's fine too; I don't really know how such things are usually handled in nixpkgs and am trying to learn. :)
I'd say setting for zen kernel is perfectly fine. Should be a matter of adding it to Do you want to give it a try and propose a PR? AFAIU you already run that kernel version and have a chance to validate it if still boots. You could also add a TODO to remove it once staging is merged.
should've gone to master and/or be merged with the next kernel bump or something if the rebuilds were that critical which I don't think they are. We could cherry-pick it if we need it now.
I made , but it's late here so I don't have time to test it properly and am waiting to open a PR until I can do so. It at least builds though. I figured while I was at it I should also bump the version to 5.18.1-zen1, but in hindsight maybe I should wait until the mainline kernel is updated to 5.18.1 in nixpkgs? Anyway, I'll test it when I have time tomorrow evening, make any necessary changes, and open a PR, unless we decide to cherry-pick ? That seems like a nicer solution to me personally, but I don't really have a strong preference.
I finally got around to testing this and opened a PR: :). I'm personally in favor of cherry-picking , though.

Related discussion:
text: owner = "zen-kernel"; repo = "zen-kernel"; inherit rev; <del> sha256 = "sha256-A0QrY1REbRODnHtmyNqVaiLhDgYCECevfHZCxtoQ9kU="; </del> <ins> sha256 = "sha256-LCLfLE85NifuskYl2dxLOJEsUNHLegF8ecYyU4xOCtY="; </ins> }; structuredExtraConfig = with lib.kernel; { ZEN_INTERACTIVE = yes; <ins> # TODO: Remove once #175433 reaches master # https://nixpk.gs/pr-tracker.html?pr=175433 WERROR = no; </ins> }; extraMeta = {
Code change:
I setup the server quite a while ago. I recognized that the service is not running. As I normally do auto update I saw that the process failed as the configuration changed. After rebuild + switch the service fails to start: Steps to reproduce the behavior: Service be able to start. I tried to 1) chmod +w -still fails and permissions are somehow adjusted 2) delete -file is created, startup still fails
Digged a little bit deeper: The error is thrown by the pre-start script. It seems that my installation is missing the which causes some gitea command to generate it and write it into . Which fails as the file is set to non writable by the pre-start script.

Related discussion:
text: function gitea_setup { cp -f ${configFile} ${runConfig} <del> if [ ! -e ${secretKey} ]; then </del> <ins> if [ ! -s ${secretKey} ]; then </ins> ${gitea}/bin/gitea generate secret SECRET_KEY > ${secretKey} fi # Migrate LFS_JWT_SECRET filename <del> if [[ -e ${oldLfsJwtSecret} && ! -e ${lfsJwtSecret} ]]; then </del> <ins> if [[ -s ${oldLfsJwtSecret} && ! -s ${lfsJwtSecret} ]]; then </ins> mv ${oldLfsJwtSecret} ${lfsJwtSecret} fi <del> if [ ! -e ${oauth2JwtSecret} ]; then </del> <ins> if [ ! -s ${oauth2JwtSecret} ]; then </ins> ${gitea}/bin/gitea generate secret JWT_SECRET > ${oauth2JwtSecret} fi <del> if [ ! -e ${lfsJwtSecret} ]; then </del> <ins> if [ ! -s ${lfsJwtSecret} ]; then </ins> ${gitea}/bin/gitea generate secret LFS_JWT_SECRET > ${lfsJwtSecret} fi <del> if [ ! -e ${internalToken} ]; then </del> <ins> if [ ! -s ${internalToken} ]; then </ins> ${gitea}/bin/gitea generate secret INTERNAL_TOKEN > ${internalToken} fi
Code change:
I've been using PipeWire+JACK with until now. I'd like to switch to , but the service crashes at startup. The key error in the logs seems to be: . The result is that : (1) I have no sound, (2) I see no volume control knob in GNOME, (3) I see no devices appear in or any other JACK patchbay tools. Here's (hopefully) all relevant build configuration: Here are some logs: It seems others haven't run into this. What could I be doing wrong? Steps to reproduce the behavior: the above build configuration in the computer the above-written commands to view relevant logs I expect to the service to start, and to have sound.
Do you need a systemwide setup? That seems to be the issue here.
My use case is: I use virtual machines that run as another user (for security), but I want them to have sound. Using allows this, and it's the only (secure) solution I'm aware of.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Thanks for this patch. I was finally able to test it. Unfortunately, I still have the issue. Your patch removed the "" error, but the wireplumber service still fails to start. Here's some evidence that your patch is applied: Here's the failure output/logs: According to the "" shouldn't be a problem because wireplumber shouldn't require X11. Looking more broadly at logs, there's this:
There have been some dbus related fixes in Wireplumber master, can you try that?
: I don't know how to cherry-pick from wireplumber; I only recently learned to cherry pick your pull request. I suppose I can wait until the next release. Maybe I should open this as an issue against wireplumber? Also, this crash only occurs with . Can you offer insight into what this means, so I can best phrase my question? I think the pipewire socket moves to a different what else? Does pipewire and/or wireplumber run as a different user? Anything else?
should get this fixed for good.
Also, if you don't know what does, you should probably disable it, as it's not a well supported configuration.

Related discussion:
text: ] ++ lib.optional config.security.rtkit.enable "rtkit"; description = "Pipewire system service user"; isSystemUser = true; <ins> home = "/var/lib/pipewire"; createHome = true; </ins> }; groups.pipewire.gid = config.ids.gids.pipewire; };
Code change:
Fonts are missing, square characters are displayed ! Steps to reproduce the behavior: vmware-workstation vmware workstation or player I started a discussion on <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --/cc
I can reproduce this, probably related to some missing font in freshly installed systems
I launched vmware with FC_DEBUG=8, but I'm not able to interpret these errors messages, hope this can help
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I found reason for missing fonts, it just loads from instead of system path and vmware's config points to wrong FHS paths, removing file fixes it, i will make a PR with fix, thanks.
I confirm that deleting fixes the issue. Thanks a lot !

Related discussion:
text: cp -r $unpacked/sbin/* $out/bin/ cp -r $unpacked/lib/libconf $out/lib/vmware/ <ins> rm $out/lib/vmware/libconf/etc/fonts/fonts.conf </ins> cp -r $unpacked/lib/bin $out/lib/vmware/ cp -r $unpacked/lib/lib $out/lib/vmware/ cp -r $unpacked/lib/scripts $out/lib/vmware/
Code change:
Building fails when rebuilding system configuration. System configuration should build successfully with on kernel 5.18 There are no current maintainers. This appears to be a repetition of
Arch Linux appears to have a new patch here: Attempting to apply it has failed for me. I tried this block: Maybe someone who helped solve this the last time can comment?
Already have a PR up .
Looks like an issue with the patch for 5.17. Try replacing it with this one:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: ./linux-5.6.patch # source: https://gist.github.com/joanbm/5c640ac074d27fd1d82c74a5b67a1290 ./linux-5.9.patch <del> # source: https://github.com/archlinux/svntogit-community/blob/5ec5b248976f84fcd7e3d7fae49ee91289912d12/trunk/012-linux517.patch </del> <ins> # source: https://github.com/archlinux/svntogit-community/blob/33b4bd2b9e30679b03f5d7aa2741911d914dcf94/trunk/012-linux517.patch </ins> ./linux-5.17.patch <ins> # source: https://github.com/archlinux/svntogit-community/blob/2e1fd240f9ce06f500feeaa3e4a9675e65e6b967/trunk/013-linux518.patch ./linux-5.18.patch ./pedantic-fix.patch </ins> ./null-pointer-fix.patch ./gcc.patch ];
Code change:
Building fails when rebuilding system configuration. System configuration should build successfully with on kernel 5.18 There are no current maintainers. This appears to be a repetition of
Arch Linux appears to have a new patch here: Attempting to apply it has failed for me. I tried this block: Maybe someone who helped solve this the last time can comment?
Already have a PR up .
Looks like an issue with the patch for 5.17. Try replacing it with this one:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: <ins> diff -u -r a/src/shared/linux_osl.c b/src/shared/linux_osl.c --- a/src/shared/linux_osl.c	2022-05-24 20:51:15.662604980 +0000 +++ b/src/shared/linux_osl.c	2022-05-24 21:13:38.264472425 +0000 @@ -599,6 +599,8 @@ va = kmalloc(size, GFP_ATOMIC | __GFP_ZERO); if (va) *pap = (ulong)__virt_to_phys(va); +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	va = dma_alloc_coherent(&((struct pci_dev *)osh->pdev)->dev, size, (dma_addr_t*)pap, GFP_ATOMIC); #else va = pci_alloc_consistent(osh->pdev, size, (dma_addr_t*)pap); #endif @@ -612,6 +614,8 @@ #ifdef __ARM_ARCH_7A__ kfree(va); +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	dma_free_coherent(&((struct pci_dev *)osh->pdev)->dev, size, va, (dma_addr_t)pa); #else pci_free_consistent(osh->pdev, size, va, (dma_addr_t)pa); #endif @@ -623,7 +627,11 @@ int dir; ASSERT((osh && (osh->magic == OS_HANDLE_MAGIC))); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	dir = (direction == DMA_TX)? DMA_TO_DEVICE: DMA_FROM_DEVICE; +#else dir = (direction == DMA_TX)? PCI_DMA_TODEVICE: PCI_DMA_FROMDEVICE; +#endif #if defined(__ARM_ARCH_7A__) && defined(BCMDMASGLISTOSL) if (dmah != NULL) { @@ -641,7 +649,11 @@ ASSERT(totsegs + nsegs <= MAX_DMA_SEGS); sg->page_link = 0; sg_set_buf(sg, PKTDATA(osh, skb), PKTLEN(osh, skb)); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +				dma_map_single(&((struct pci_dev *)osh->pdev)->dev, PKTDATA(osh, skb), PKTLEN(osh, skb), dir); +#else pci_map_single(osh->pdev, PKTDATA(osh, skb), PKTLEN(osh, skb), dir); +#endif } totsegs += nsegs; totlen += PKTLEN(osh, skb); @@ -656,7 +668,11 @@ } #endif +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	return (dma_map_single(&((struct pci_dev *)osh->pdev)->dev, va, size, dir)); +#else return (pci_map_single(osh->pdev, va, size, dir)); +#endif } void BCMFASTPATH @@ -665,8 +681,13 @@ int dir; ASSERT((osh && (osh->magic == OS_HANDLE_MAGIC))); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	dir = (direction == DMA_TX)? DMA_TO_DEVICE: DMA_FROM_DEVICE; +	dma_unmap_single(&((struct pci_dev *)osh->pdev)->dev, (uint32)pa, size, dir); +#else dir = (direction == DMA_TX)? PCI_DMA_TODEVICE: PCI_DMA_FROMDEVICE; pci_unmap_single(osh->pdev, (uint32)pa, size, dir); +#endif } #if defined(BCMDBG_ASSERT) </ins>
Code change:
Steps to reproduce the behavior:
Can you check if has an effect?
I've got this error:
Please check the full log of that build and look for ( catching the actual error) and any preceding lines with (actual error from the compiler). What you posted are just harmless warnings and (an error has occurred somewhere else so needs to quit).
Upstream issue:

Related discussion:
text: url = "https://hg.mozilla.org/releases/mozilla-esr102/raw-rev/1fa20fb474f5d149cc32d98df169dee5e6e6861b"; sha256 = "sha256-eCisKjNxy9SLr9KoEE2UB26BflUknnR7PIvnpezsZeA="; }) <ins> ] ++ lib.optionals (lib.versionAtLeast version "91" && stdenv.hostPlatform.system == "i686-linux") [ # Fixes i686 build, https://bugzilla.mozilla.org/show_bug.cgi?id=1729459 ./fix-float-i686.patch </ins> ]; nativeBuildInputs = [
Code change:
Steps to reproduce the behavior:
Can you check if has an effect?
I've got this error:
Please check the full log of that build and look for ( catching the actual error) and any preceding lines with (actual error from the compiler). What you posted are just harmless warnings and (an error has occurred somewhere else so needs to quit).
Upstream issue:

Related discussion:
text: <ins> diff --git a/modules/fdlibm/src/math_private.h b/modules/fdlibm/src/math_private.h index 51d79f9c2ec59..fafd7d6fc1e0d 100644 --- a/modules/fdlibm/src/math_private.h +++ b/modules/fdlibm/src/math_private.h @@ -30,5 +30,9 @@ * Adapted from https://github.com/freebsd/freebsd-src/search?q=__double_t */ +#if defined __FLT_EVAL_METHOD__ && (__FLT_EVAL_METHOD__ == 2) +typedef long double      __double_t; +#else typedef double      __double_t; +#endif typedef __double_t  double_t; /* </ins>  No newline at end of file
Code change:
nicely describes the issue and the fix Steps to reproduce the behavior: salt on to run it errors salt working and may be of interest to ;) <!-- 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.

Related discussion:
text: { lib , python3 , openssl <ins> , fetchpatch </ins> # Many Salt modules require various Python modules to be installed, # passing them in this array enables Salt to find them. , extraInputs ? []
Code change:
nicely describes the issue and the fix Steps to reproduce the behavior: salt on to run it errors salt working and may be of interest to ;) <!-- 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.

Related discussion:
text: patches = [ ./fix-libcrypto-loading.patch <ins> (fetchpatch { url = "https://github.com/saltstack/salt/commit/6ec8b90e402ff3fa8f27c7da70ece898592416bc.patch"; hash = "sha256-OQCJeG12cp2EZ0BErp6yqsqhv023923rVFDHAFUfF6c="; }) </ins> ]; postPatch = ''
Code change:
tig crash on macOS (m1) Steps to reproduce the behavior: -shell -p tig ANYGITREPO type "/" to enter search mode Don't crash ! Exception Type: EXCBADACCESS (SIGSEGV) Exception Codes: KERNINVALIDADDRESS at 0x082a0d5c00ab0a2b -0x00000d5c00ab0a2b (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x082a0d5c00ab0a2b Exception Note: EXCCORPSENOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [] VM Region Info: 0xd5c00ab0a2b is not in any region. Bytes after previous region: Bytes before following region: REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) - [384.0G] ---/--- SM=NUL ...(unallocated) ---GAP OF 0x5f9000000000 BYTES MALLOCNANO - [128.0M] rw-/rwx SM=PRV Thread 0 Crashed:: Dispatch queue: 0 ??? 0x100b84c6c rlinitterminalio + 272 1 ??? 0x100b84c60 rlinitterminalio + 260 2 ??? 0x100b6fc2c readlineinitializeeverything + 164 3 ??? 0x100b6edd0 rlinitialize + 44 4 ??? 0x100b6ed48 readline + 36 5 ??? 0x100981ce4 readprompt + 80 6 ??? 0x10098aaa0 searchview + 56 7 ??? 0x100971680 main + 2608 8 dyld 0x100d61088 start + 516 <!-- 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.

Related discussion:
text: inherit (darwin.apple_sdk.frameworks) Security; }; <del> tig = callPackage ../applications/version-management/git-and-tools/tig { }; </del> <ins> tig = callPackage ../applications/version-management/git-and-tools/tig { readline = readline81; }; </ins> tilemaker = callPackage ../applications/misc/tilemaker { };
Code change:
Noticed while debugging hash errors for . Since got merged via (bisect log further down), doesn't produce fully deterministic results anymore. Sometimes I get an identical hash, several times in a row even? But often it's different. It is worth noting that the fetcher output has changed after that commit. Using as an example, the final line has been replaced by for the main repository + every fetched submodule. Steps to reproduce the behavior: (current master at the time of writing) repl: multiple times and you should get a different hash eventually. "Best" combo I got so far is 3 identical hashes before a different one. Hashes shouldn't randomly be different. It would be understandable if the not-yet-deterministic was used, but this happens even with . Changing hashes: ! ! Changed output: (last identical lines are highlighted) ! Bisect log: Bisection done with . uses with , which uses under the hood, but the hash change should be observable by directly using as well. CC (commit author) CC (PR merger) Please run and paste the result.
I did a quick investigation. First of all: I was able to produce the same results as the OP on my machine. My initial investigation led me to believe that this behavior is caused by 2 bugs. One introduced by commit and the other one being unrelated to this commit. The bug introduced by the commit in question is that seems to use in situations where it shouldn't. The second bug is that specifying produces non deterministic results. Evidence for this is provided by the following experiment: I checked out a revision of that was before No I ran the same experiment as the OP suggested but instead of using I used . As you can see I got two different results for the same call. I suggest that should be reverted to mitigate the damage by the bug it introduced. I don't know well enough to do anything about "the other bug".
This is a .
Pinning this until the fix has made its way into and staging.
Thanks a lot to everyone involved in investigating and fixing this! Also, I'm sorry for breaking this in the first place!
Don't take all the credit for yourself. We broke this together ^^
I'm seeing behavior that I think may be related to this issue. Please consider the derivation contained within the following flake: Changing the dummy value of results in different suggested replacement values. It seems to me that any value except for the corrected one should result in the same suggestion. Furthermore, all suggestions do build successfully (so the allowed values of are not unique) but the only one that actually respects is the empty string case. This may indicate a separate problem with .

Related discussion:
text: fi done <del> if test -n $deepClone; then leaveDotGit=true fi </del> if test -z "$url"; then usage fi