jiebi/CodeConvo huggingface dataset:
Change:
, electron-unwrapped , wrapGAppsHook , makeWrapper <ins> , gsettings-desktop-schemas , glib , gtk3 , gtk4 </ins> }: stdenv.mkDerivation {

Discussion:
In element-desktop, clicking on a picture to open it externally, crashes the application:
The pre-built is using wrapGAppsHook So it should be a ok solution for the source built too.
It already was using that (see ), but the hook did not work properly and additional buildInputs were missing.
Change:
echo "Obtaining SSH keys..." mkdir -m 0700 -p /root/.ssh AUTH_KEYS=$(${mktemp}) <del> ${wget} -O $AUTH_KEYS --header="Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/sshKeys </del> <ins> ${wget} -O $AUTH_KEYS http://metadata.google.internal/computeMetadata/v1/instance/attributes/sshKeys </ins> if [ -s $AUTH_KEYS ]; then # Read in key one by one, split in case Google decided

Discussion:
Unable to download the public google cloud image, Can confirm the other very outdated images are downloadable. The bucket object is not world readable.
Would really appreciate a fix to this, combined with I can't create a working vm. edit: worked around.
Having the same issue
Where did you get the link from? I think the URI should be: gs://nixos-cloud-images/nixos-image-18.03..-x86_64-
This page There is definitely a new image someone too. The bucket url you listed is not public either. To be honest, I didn't trust those images and built my own. I made this issue to benefit other people.
I have removed that image, as the nixos-images bucket is an old bucket. Probably got upload accidentally, when the creation script referred to it still. I tried generating a new image, however, that has issues connecting via ssh (nixops), as some code was removed from nixpkgs that downloads SSH host key from metadata in . I might have time to look into that next week. Not sure yet what the correct way forward is.
I'll have look at the issue in nixops this weekend.
Is there a new 18.03 image now ? I can't seem to find a link to it in the nixpkgs repo.
I think the issue preventing the image generation was fixed now. Otherwise, afaik takes care of updating the images, so better ask him if there is anything else pending ?
(25 days ago) mentions an image from May 29 currently being present, after these comments, but still quite old, and for 18.03, 18.09 is still missing. Closing this issue in favour of .
Change:
def _get_option_parser(): parser = optparse.OptionParser('%prog [options] sources') parser.add_option('', "--quiet", <del> @@ -200,6 +233,10 @@ match the namespace prefix.""") </del> <ins> @@ -209,6 +242,10 @@ </ins> parser.add_option("", "--filelist", action="store", dest="filelist", default=[], help="file containing headers and sources to be scanned")

Discussion:
For some packages, a wrong path to the library is generated. For example, produces an extra directory: Now, the typelib path is supposed to be addressed by It only works when typelibdir is an absolute path but apparently that is not the problem here (it is ). Possibly a bug in the ? This is how the gir file is built (add to expression): Nixpkgs
Indeed, the patch is the problem. The supplied regex matched too eagerly: Simple change should fix it.
Hmm, right it cannot be as simple as adding two slashes it would just match
Hmm, so lets see if I understand this correctly. We want to distinguish between two cases: link is to the and we want the absolute path link is not to the nix store and we only want the soname The original pattern in will produce only sonames, correctly extracting the left hand side of the ldd output (the upstream comment for is rather confusing as it seems to use the wrong library name which doesn't produce any match at all, so I'm assuming they mean `libpangoft2-1). Would it make sense to patch instead, so we don't have to implement control flow in a regular expression? So something like this: where is specifically made to extract the absolute path. Not sure if this is relevant as you've already created a fix which should work okay as I'm assuming nix mostly runs on GNU systems? But I'm thinking it might make things easier.
Yep. Yes, unless you use OpenBSD or something. They meant . Library name would also match , I guess they assume there will be no such library. A problem might occur with gspell, which has as the library name which would also match but only if you linked against both. Yes this would be the cleanest, it will even allow to fix the upstream the two aforementioned bugs without us having to update the thing. I was too focused on regex composition to consider using two functions.
Change:
dontDisableStatic = true; # postgis config directory assumes /include /lib from the same root for json-c library <del> NIX_LDFLAGS = "-L${lib.getLib json_c}/lib"; </del> <ins> NIX_LDFLAGS = "-L${lib.getLib json_c}/lib" # Work around https://github.com/NixOS/nixpkgs/issues/166205. + lib.optionalString (stdenv.cc.isClang && stdenv.cc.libcxx != null) " -l${stdenv.cc.libcxx.cxxabi.libName}"; </ins> preConfigure = '' sed -i 's@/usr/bin/file@${file}/bin/file@' configure

Discussion:
Steps to reproduce the behavior: nix-build -A Full build log at <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(steve): channels(root): nixpkgs: ` Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I am sorry, I can't help with Darwin. would you please help us ? Thank you.
I can reproduce this, but I'm in way over my head, I don't think I can help fix it. I'll put down everything I found out, hopefully it will help someone else. It seems all the undined symbols are from the C++ standard library. The common solution for an error like that is to add to the linker flags, but checking the linker invocation shows that it is already present. (twice, in fact) See below for the full invocation of the compiler and linker for the failing file: <details</detailsI tried to go back and find the latest version that still builds. FIrst idea was , one commit before the upgrade to 3.4.0 was merged. There was no postgres16 then, but with postgres14 it builds fine: Next suspect was , which was the upgrade to 3.4.0. That one was cached, so the upgrade itself is not the culprit: Next one was , the commit where was first . It built fine as well, so postgres16 isn't the culprit either. Then I tried current master, but with postgres_14. That also fails with the exact same error as above. I tried to start a bisect, but that requires rebuilding everything multiple times as nothing is cached. Just checking the hydra builds, I can see that as first to fail and was last to succeed, but between those two are over 1400 commits. This was just a few days ago. Bisecting is also difficult because netcdf, one of postgis' dependencies, also fails to build sometimes, so you have to do it manually to differentiate between those two kinds of failures.
The problem is Fixed in .
Great thanks and .
Can somebody rebase with latest master and test on Darwin ?
Done, see my comment there.

It was already based on master at the time, so that shouldn’t be the issue. The failure was due to some PostgreSQL packages using on Linux, which doesn’t use libc++ (resulting in being null). I pushed an updated PR taking that into account.
Change:
noise-repellent = callPackage ../applications/audio/noise-repellent { }; <ins> noisetorch = callPackage ../applications/audio/noisetorch { }; </ins> notary = callPackage ../tools/security/notary { }; notify-osd = callPackage ../applications/misc/notify-osd { };

Discussion:
Project description NoiseTorch is an easy to use open source application for Linux with PulseAudio. It creates a virtual microphone that suppresses noise, in any application. Metadata homepage URL: source URL: license: gpl3 platforms: linux language: go
I'll try to package it myself soon.
For those who want to try now before the package is merged go build works ok:
Change:
version = "19.0.6"; sha256 = "sha256-pqqIayE0OyTailtd2zeYi+G1APjv/YHqyO8jCpq7KJg="; extraVulnerabilities = [ <del> "Nextcloud 19 is still supported, but CVE-2020-8259 & CVE-2020-8152 are unfixed!" </del> <ins> "Nextcloud 19 is still supported, but CVE-2020-8259 & CVE-2020-8152 are unfixed! Please note that both CVEs only affect the file encryption module which is turned off by default. Alternatively, `pkgs.nextcloud20` can be used." </ins> ]; };

Discussion:
In line of the nextcloud nixos module the current default is nextcloud 19. On the one hand, this is not represented in the documentation. On the other, this yields the error that there are unpatched security issues.
Retroactively changing the default on 20.09 is not just a breaking change, but effectively breaks the upgrade path from 20.03: the problem with Nextcloud (and the main reason for this complex package-selection thing) is that they don't support upgrades across multiple major releases (i.e. you can't go from v18 to v20). The whole point of this option is that one can install an arbitrary Nextcloud version while we (as maintainers) can set "conservative" defaults for working upgrade paths. In your case it would be sufficient to set . Regarding CVE-2020-8259 and CVE-2020-8152: both vulnerabilities affect the encryption module which is turned off by default (IIRC it can only be enabled in the admin UI anyways). It's unfortunate that Nextcloud upstream doesn't care about older yet still active majors and rates security issues as "Low" even though the CVEs are rated as "High" by e.g. NIST, but that's where we are. In other words: if you don't use the affected features it's still OK to use (which can be allowed by setting .
I see your point, thanks. The issue is that I, as a user, install Nextcloud and see a security warning. Given the above, maybe the message could state that you may use the option and use nextcloud20. Would that be feasible? Or given the fact that 21.03 is 'around the corner' would it be worth it?
why did you mark this as security-relevant? Both CVEs in question are disclosed by upstream and will warn about them by default. This is merely an issue with documentation and helpful warnings IMHO.
The issue seems to be about undocumented path towards using nextcloud while staying secure
Yes, it's about documentation, no immediate action is pending to fix a security issue! Nextcloud versions with known vulnerabilities yield an evaluation error, this is primarily about suggesting what to do if one stumbles upon this.
Change:
<ins> diff --git a/scripts/fetchPufferfish.sh b/scripts/fetchPufferfish.sh index bf2574e0..42582806 100755 --- a/scripts/fetchPufferfish.sh +++ b/scripts/fetchPufferfish.sh @@ -11,10 +11,6 @@ CURR_DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd ) EXTERNAL_DIR=${CURR_DIR}/../external INSTALL_DIR=${CURR_DIR}/../external/install -if [ -d ${EXTERNAL_DIR}/pufferfish ] ; then -    rm -fr ${EXTERNAL_DIR}/pufferfish -fi - if [ -d ${INSTALL_DIR}/include/pufferfish ] ; then rm -fr ${INSTALL_DIR}/include/pufferfish fi @@ -23,42 +19,10 @@ if [ -d ${INSTALL_DIR}/src/pufferfish ] ; then rm -fr ${INSTALL_DIR}/src/pufferfish fi -SVER=salmon-v1.10.2 -#SVER=develop -#SVER=sketch-mode - -EXPECTED_SHA256=f225b74833f71dcf767a565345224357fb091f90ce79717abc836814d9ccd101 - -mkdir -p ${EXTERNAL_DIR} -curl -k -L https://github.com/COMBINE-lab/pufferfish/archive/${SVER}.zip -o ${EXTERNAL_DIR}/pufferfish.zip - -hashcheck="" -if exists sha256sum; then -	hashcheck="sha256sum" -elif exists shasum; then -	hashcheck="shasum -a256" -else -	unset hashcheck -fi - - -if [ -z "${hashcheck-}" ]; then -    echo "Couldn't find shasum command; can't verify contents of downloaded pufferfish"; -else - -    if [[ $SVER != develop && $SVER != onetbb ]]; then -        echo "${EXPECTED_SHA256}  ${EXTERNAL_DIR}/pufferfish.zip" | ${hashcheck} -c - || { echo "pufferfish.zip did not match expected SHA1! Exiting."; exit 1; } -    else -        echo "not testing sha since pulling from develop" -    fi -fi - - -rm -fr ${EXTERNAL_DIR}/pufferfish -unzip ${EXTERNAL_DIR}/pufferfish.zip -d ${EXTERNAL_DIR} -mv ${EXTERNAL_DIR}/pufferfish-${SVER} ${EXTERNAL_DIR}/pufferfish mkdir -p ${INSTALL_DIR}/include/pufferfish +# This is needed later when pufferfish is compiled for Salmon +cp -r ${pufferFishSrc} ${EXTERNAL_DIR}/pufferfish cp ${EXTERNAL_DIR}/pufferfish/include/ProgOpts.hpp ${INSTALL_DIR}/include/pufferfish cp ${EXTERNAL_DIR}/pufferfish/include/BooPHF.hpp ${INSTALL_DIR}/include/pufferfish </ins>

Discussion:
Salmon is a bioinformatics tool to produce a highly accurate, transcript level quantification estimates from short-read RNA-seq data. It's mostly written in C++. There's a similar tool already in nixpkgs (Kallisto), but they both have a few unique features, so packaging Salmon is still useful. It's also quite a popular tool. homepage URL: source URL: license: GLP v3.0 platforms: linux, others?
I started packaging it, and made good progress. It's a way for me to learn Nix, but may need a few pointers to get it done
Open a draft PR, then.
Change:
pytest-shutil = callPackage ../development/python-modules/pytest-shutil { }; <ins> pytest-spec = callPackage ../development/python-modules/pytest-spec { }; </ins> python-status = callPackage ../development/python-modules/python-status { }; python-string-utils = callPackage ../development/python-modules/python-string-utils { };

Discussion:
Project description Library pytest-spec is a pytest plugin to display test execution output like a SPECIFICATION. Metadata homepage URL: source URL: license: GPL-2.0 platforms: unix, linux, darwin, ...
Change:
# mkfs.ext4 -L nixos /dev/sda1 # mkswap -L swap /dev/sda2 # swapon /dev/sda2 <del> # mkfs.fat -F 32 -L boot /dev/sda3        # <lineannotation>(for UEFI systems only)</lineannotation> </del> <ins> # mkfs.fat -F 32 -n boot /dev/sda3        # <lineannotation>(for UEFI systems only)</lineannotation> </ins> # mount /dev/disk/by-label/nixos /mnt <ins> # mkdir -p /mnt/boot                      # <lineannotation>(for UEFI systems only)</lineannotation> </ins> # mount /dev/disk/by-label/boot /mnt/boot # <lineannotation>(for UEFI systems only)</lineannotation> # nixos-generate-config --root /mnt # nano /mnt/etc/nixos/configuration.nix

Discussion:
1/ The manual contains this command but it should be as doesn't accept the -L flag and it will warn when using lowercase 2/ the manual recommands but this gives "unknown filesystem type LVM2_member` for lvm 3/ it says to mount a drive in /mnt/boot but the folder doesn't exist 4/ apparently nixos-generate-config doesn't setup the root filesystem with LLVM: "the fileSystems option does not specify your root file system" Other propositions: Add useOSProber in the nixos-generate-config I know nixos targets more advanced users but I guess this can still be improved
The LVM example is meant as an additional way to explore. Simply following the command in the order presented is not promising. I'd suggest to leave out the logical volume setup code. Users with LVM knowledge probably know how to operate and friends. For users without LVM knowledge this is probably misleading.
thanks for the fixes !
Change:
python3.pkgs.buildPythonApplication rec { pname = "waypaper"; <del> version = "1.5"; </del> <ins> version = "1.9"; </ins> src = fetchFromGitHub { owner = "anufrievroman"; repo = "waypaper"; rev = "refs/tags/${version}"; <del> hash = "sha256-lK4TygR9cwEHcnrC0E5vE7Jor6afEiM9TmEgGXj+hNA="; </del> <ins> hash = "sha256-6hv+f2fbrbLodJIRHl5MYTkiZ51iZOAK42Vg73zSw/E="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: waypaper Latest released version: 1.9 <!-- Search your package here: --- Current version on the unstable channel: 1.5 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.
Change:
++ lib.optional (!cgiSupport) "--disable-cgi" ++ lib.optional (!cliSupport) "--disable-cli" ++ lib.optional fpmSupport    "--enable-fpm" <del> ++ lib.optional pearSupport [ "--with-pear=$(out)/lib/php/pear" "--enable-xml" "--with-libxml" ] </del> <ins> ++ lib.optional pearSupport [ "--with-pear" "--enable-xml" "--with-libxml" ] </ins> ++ lib.optionals (pearSupport && (lib.versionOlder version "7.4")) [ "--enable-libxml" "--with-libxml-dir=${libxml2.dev}"

Discussion:
Describe the bug On NixOS 20.09 and unstable, is not in the search path, even though it is installed with the php package. To Reproduce Steps to reproduce the behavior: [example from 20.09 system] Expected behavior [example from 20.03 system] Additional context Debugging with reveals that on 20.09, php is searching in , then , which fails. On 20.03, it searches in , then , which succeeds. On 20.09 and unstable, php74 and php73 both fail. On 20.03, php73 (the default) works, but php74 fails, but I believe it fails for a different reason. This line is new since release-20.03. At first glance, it seems as though is resolving to null here, but I'm not sure what to replace it with: Notify maintainers Metadata Maintainer information:
Thanks for reporting this issue! Your guess was right on spot and it was a really simple fix it seems :slightlysmilingface: As you may have seen: Right after 20.03 branched off we started a big refactoring of the PHP ecosystem. So bugs and issues was to be expected :slightlysmilingface:
Change:
.PHONY: clean clean: <del> rm -f ${MD_TARGETS} .version manual-full.xml functions/library/locations.xml </del> <ins> rm -f ${MD_TARGETS} .version manual-full.xml functions/library/locations.xml functions/library/generated </ins> rm -rf ./out/ ./highlightjs .PHONY: validate

Discussion:
with new versions of deps - build is broken. Example of error instance: Full log: This creates a blocker for contributors to the manual. To contribute to NixPkgs manual, it is required to build the manual () before creating a pull request. I want to contribute some section. By the process - I need to pass a successful build. The manual on the master branch is currently broken, building it on my setup. Errors ask me to make changes, which doc maintainers probably know what to do about. system: host os: multi-user?: sandbox: version: channels(root): channels(pyro): nixpkgs:
Maybe this is due to manual being built on the current stable branch?
Even on the job builds and most likely will build for you as well but I confirm that in indeed is broken.
BTW, I believe this earlier message is closer to the root of the problem:
Yes, this was to in but the was forgotten. cc
Gonna take a look at this. Edit: PR to fix it is up at
if you are still having issues on master (or a revision where is merged) make sure you before using , and otherwise, re-open with more details.
Change:
<ins> diff --git a/configure.py b/configure.py index 25ca951ac..454140420 100755 --- a/configure.py +++ b/configure.py @@ -36,13 +36,16 @@ tempfile.tempdir = "./build/tmp" configure_args = str.join(' ', [shlex.quote(x) for x in sys.argv[1:]]) -for line in open('/etc/os-release'): -    key, _, value = line.partition('=') -    value = value.strip().strip('"') -    if key == 'ID': -        os_ids = [value] -    if key == 'ID_LIKE': -        os_ids += value.split(' ') +try: +    for line in open('/etc/os-release'): +        key, _, value = line.partition('=') +        value = value.strip().strip('"') +        if key == 'ID': +            os_ids = [value] +        if key == 'ID_LIKE': +            os_ids += value.split(' ') +except FileNotFoundError: +    os_ids = ["linux"] # distribution "internationalization", converting package names. </ins>

Discussion:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!
Change:
gegl = callPackage ../development/libraries/gegl { inherit (darwin.apple_sdk.frameworks) OpenCL; <del> libraw = libraw_0_20; </del> }; gensio = callPackage ../development/libraries/gensio {};

Discussion:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.
Change:
{ stdenv, fetchurl, cmake, ninja, llvm_5, llvm_8, curl, tzdata , python, libconfig, lit, gdb, unzip, darwin, bash <del> , callPackage, makeWrapper, targetPackages </del> <ins> , callPackage, makeWrapper, runCommand, targetPackages </ins> , bootstrapVersion ? false , version ? "1.17.0" , ldcSha256 ? "1aag5jfrng6p4ms0fs90hjbv9bcj3hj8h52r68c3cm6racdajbva"

Discussion:
Describe the bug The ldc package (1.17.0) is currently failing to build properly in the unstable branch. It looks like the following is the culprit: To Reproduce Steps to reproduce the behavior: done! Expected behavior The package should build and install cleanly. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(chrisaw): nixpkgs: cc
Right, looks like is commit introducing the failure. The relied on shell expansion which no longer happens, so we get this: Instead of this:
cc
is right. So a fix could be to use but I find the hardcoded /build quite ugly. The path doesn't need to be in /build but I put it there to make sure it's not a file used by some other process. Switching from /build to /tmp or whatever is for this reason not a good solution.
I'm not sure with the changes for structured attrs we could use shell expansion for like before. Perhaps could comment since the fix looks obvious.
Right CMake does not interpolate environment variable, this was oversight on our part. Looks like was in and I agree that hardcoding is not a good idea but the presence of feels like a hack too. What is ts purpose? If the string imports are generated by the build system, I would expect them to be found without any extra flags. And if they are generated us during bootstrapping, I would expect them to be in a separate derivation, making referencing them work without variable interpolation. If we cannot get rid of the , we should move the flag to until we can.
Looks like the flag is needed for Could we copy the file to a build system’s natural directory like or something, so that the flag could be omitted?
The flag is the only possibility to get the tzdata path into the library. See for the code in the library. Where the file is doesn't matter but I don't see any better location as $PWD for now.
Is not it possible to put it to directory or something?
Yes but I still need to get the full path to it for -J and there is no default directory so you could omit the -J if you mean that. See point 3 in .