Question:
, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:

<ins> commit b1f4e1b2187d9e5010cd01ceccf20b4a11ce723f Author: Leon Bottou <leon@bottou.org> Date:   Tue Mar 26 20:45:46 2019 -0400 fix for bug #297 diff --git a/libdjvu/DjVmDir.cpp b/libdjvu/DjVmDir.cpp index 0a0fac6..5a49015 100644 --- a/libdjvu/DjVmDir.cpp +++ b/libdjvu/DjVmDir.cpp @@ -309,7 +309,7 @@ DjVmDir::decode(const GP<ByteStream> &gstr) { GP<File> file=files_list[pos]; if (ptr >= (const char*)strings + strings_size) -           G_THROW( "DjVu document is corrupted (DjVmDir)" ); +           G_THROW( ByteStream::EndOfFile ); file->id=ptr; ptr+=file->id.length()+1; if (file->flags & File::HAS_NAME) diff --git a/libdjvu/GBitmap.cpp b/libdjvu/GBitmap.cpp index 0e487f0..c2fdbe4 100644 --- a/libdjvu/GBitmap.cpp +++ b/libdjvu/GBitmap.cpp @@ -890,11 +890,13 @@ GBitmap::read_rle_raw(ByteStream &bs) int c = 0; while (n >= 0) { -      bs.read(&h, 1); +      if (bs.read(&h, 1) <= 0) +        G_THROW( ByteStream::EndOfFile ); int x = h; if (x >= (int)RUNOVERFLOWVALUE) { -          bs.read(&h, 1); +          if (bs.read(&h, 1) <= 0) +            G_THROW( ByteStream::EndOfFile ); x = h + ((x - (int)RUNOVERFLOWVALUE) << 8); } if (c+x > ncolumns) </ins>


Question:
, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:

<ins> commit e15d51510048927f172f1bf1f27ede65907d940d Author: Leon Bottou <leon@bottou.org> Date:   Mon Apr 8 22:25:55 2019 -0400 bug 299 fixed diff --git a/libdjvu/GContainer.h b/libdjvu/GContainer.h index 96b067c..0140211 100644 --- a/libdjvu/GContainer.h +++ b/libdjvu/GContainer.h @@ -550,52 +550,61 @@ public: template <class TYPE> void GArrayTemplate<TYPE>::sort(int lo, int hi) { -  if (hi <= lo) -    return; -  if (hi > hibound || lo<lobound) -    G_THROW( ERR_MSG("GContainer.illegal_subscript") ); TYPE *data = (TYPE*)(*this); -  // Test for insertion sort -  if (hi <= lo + 50) +  while(true) { -      for (int i=lo+1; i<=hi; i++) +      if (hi <= lo) +        return; +      if (hi > hibound || lo<lobound) +        G_THROW( ERR_MSG("GContainer.illegal_subscript") ); +      // Test for insertion sort +      if (hi <= lo + 50) { -          int j = i; -          TYPE tmp = data[i]; -          while ((--j>=lo) && !(data[j]<=tmp)) -            data[j+1] = data[j]; -          data[j+1] = tmp; +          for (int i=lo+1; i<=hi; i++) +            { +              int j = i; +              TYPE tmp = data[i]; +              while ((--j>=lo) && !(data[j]<=tmp)) +                data[j+1] = data[j]; +              data[j+1] = tmp; +            } +          return; } -      return; -    } -  // -- determine suitable quick-sort pivot -  TYPE tmp = data[lo]; -  TYPE pivot = data[(lo+hi)/2]; -  if (pivot <= tmp) -    { tmp = pivot; pivot=data[lo]; } -  if (data[hi] <= tmp) -    { pivot = tmp; } -  else if (data[hi] <= pivot) -    { pivot = data[hi]; } -  // -- partition set -  int h = hi; -  int l = lo; -  while (l < h) -    { -      while (! (pivot <= data[l])) l++; -      while (! (data[h] <= pivot)) h--; -      if (l < h) +      // -- determine median-of-three pivot +      TYPE tmp = data[lo]; +      TYPE pivot = data[(lo+hi)/2]; +      if (pivot <= tmp) +        { tmp = pivot; pivot=data[lo]; } +      if (data[hi] <= tmp) +        { pivot = tmp; } +      else if (data[hi] <= pivot) +        { pivot = data[hi]; } +      // -- partition set +      int h = hi; +      int l = lo; +      while (l < h) { -          tmp = data[l]; -          data[l] = data[h]; -          data[h] = tmp; -          l = l+1; -          h = h-1; +          while (! (pivot <= data[l])) l++; +          while (! (data[h] <= pivot)) h--; +          if (l < h) +            { +              tmp = data[l]; +              data[l] = data[h]; +              data[h] = tmp; +              l = l+1; +              h = h-1; +            } +        } +      // -- recurse, small partition first +      //    tail-recursion elimination +      if (h - lo <= hi - l) { +        sort(lo,h); +        lo = l; // sort(l,hi) +      } else { +        sort(l,hi); +        hi = h; // sort(lo,h) } } -  // -- recursively restart -  sort(lo, h); -  sort(l, hi); } template<class TYPE> inline TYPE& </ins>


Question:
, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:

<ins> commit 9658b01431cd7ff6344d7787f855179e73fe81a7 Author: Leon Bottou <leon@bottou.org> Date:   Mon Apr 8 22:55:38 2019 -0400 fix bug #298 diff --git a/libdjvu/GBitmap.h b/libdjvu/GBitmap.h index e8e0c9b..ca89a19 100644 --- a/libdjvu/GBitmap.h +++ b/libdjvu/GBitmap.h @@ -566,7 +566,7 @@ GBitmap::operator[](int row) { if (!bytes) uncompress(); -  if (row<0 || row>=nrows) { +  if (row<0 || row>=nrows || !bytes) { #ifndef NDEBUG if (zerosize < bytes_per_row + border) G_THROW( ERR_MSG("GBitmap.zero_small") ); @@ -581,7 +581,7 @@ GBitmap::operator[](int row) const { if (!bytes) ((GBitmap*)this)->uncompress(); -  if (row<0 || row>=nrows) { +  if (row<0 || row>=nrows || !bytes) { #ifndef NDEBUG if (zerosize < bytes_per_row + border) G_THROW( ERR_MSG("GBitmap.zero_small") ); </ins>


Question:
, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:

<ins> commit c8bec6549c10ffaa2f2fbad8bbc629efdf0dd125 Author: Leon Bottou <leon@bottou.org> Date:   Thu Oct 17 22:20:31 2019 -0400 Fixed bug 309 diff --git a/libdjvu/IW44EncodeCodec.cpp b/libdjvu/IW44EncodeCodec.cpp index 00752a0..f81eaeb 100644 --- a/libdjvu/IW44EncodeCodec.cpp +++ b/libdjvu/IW44EncodeCodec.cpp @@ -405,7 +405,7 @@ filter_fv(short *p, int w, int h, int rowsize, int scale) int y = 0; int s = scale*rowsize; int s3 = s+s+s; -  h = ((h-1)/scale)+1; +  h = (h>0) ? ((h-1)/scale)+1 : 0; y += 1; p += s; while (y-3 < h) diff --git a/tools/ddjvu.cpp b/tools/ddjvu.cpp index 6d0df3b..7109952 100644 --- a/tools/ddjvu.cpp +++ b/tools/ddjvu.cpp @@ -279,7 +279,7 @@ render(ddjvu_page_t *page, int pageno) prect.h = (ih * 100) / dpi; } /* Process aspect ratio */ -  if (flag_aspect <= 0) +  if (flag_aspect <= 0 && iw>0 && ih>0) { double dw = (double)iw / prect.w; double dh = (double)ih / prect.h; </ins>


Question:
, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:

buildInputs = [ libjpeg libtiff librsvg libiconv ]; <ins> patches = [ ./CVE-2019-18804.patch # This one is needed to make the following # two CVE patches apply cleanly ./fix_hongfuzz_crash.patch ./CVE-2019-15142.patch ./CVE-2019-15143.patch ./CVE-2019-15144.patch ./CVE-2019-15145.patch ]; </ins> meta = with stdenv.lib; { description = "A library and viewer for the DJVU file format for scanned images"; homepage = http://djvu.sourceforge.net;


Question:
, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:

<ins> commit 89d71b01d606e57ecec2c2930c145bb20ba5bbe3 Author: Leon Bottou <leon@bottou.org> Date:   Fri Jul 13 08:46:22 2018 -0400 fix hongfuzz crash. diff --git a/libdjvu/DjVmDir.cpp b/libdjvu/DjVmDir.cpp index d322323..a6a39e0 100644 --- a/libdjvu/DjVmDir.cpp +++ b/libdjvu/DjVmDir.cpp @@ -299,7 +299,13 @@ DjVmDir::decode(const GP<ByteStream> &gstr) memcpy((char*) strings+strings_size, buffer, length); } DEBUG_MSG("size of decompressed names block=" << strings.size() << "n"); - +      if (strings[strings.size()-1] != 0) +        { +         int strings_size=strings.size(); +         strings.resize(strings_size+1); +         strings[strings_size] = 0; +        } + // Copy names into the files const char * ptr=strings; for(pos=files_list;pos;++pos) diff --git a/libdjvu/miniexp.cpp b/libdjvu/miniexp.cpp index 6a5cd90..828addc 100644 --- a/libdjvu/miniexp.cpp +++ b/libdjvu/miniexp.cpp @@ -1065,7 +1065,7 @@ print_c_string(const char *s, char *d, int flags, size_t len) c = (unsigned char)(*s++); if (char_quoted(c, flags)) { -          char buffer[10]; +          char buffer[16]; /* 10+1 */ static const char *tr1 = ""tnrbf"; static const char *tr2 = ""tnrbf"; buffer[0] = buffer[1] = 0; diff --git a/tools/csepdjvu.cpp b/tools/csepdjvu.cpp index 7ed13ad..fab9472 100644 --- a/tools/csepdjvu.cpp +++ b/tools/csepdjvu.cpp @@ -1834,7 +1834,7 @@ main(int argc, const char **argv) ByteStream::create(GURL::Filename::UTF8(arg),"rb"); BufferByteStream ibs(*fbs); do { -                char pagename[16]; +                char pagename[20]; sprintf(pagename, "p%04d.djvu", ++pageno); if (opts.verbose > 1) DjVuPrintErrorUTF8("%s","--------------------n"); </ins>


Question:
Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: -build -A chefdk ./result/bin/chef ./result/bin/knife Expected behavior The chef executable is there but is broken, the knife executable isn't even present. Additional context broke chef, it worked before that commit. I've bisected it down to that changeset. Problem for me is that I don't know ruby or the ruby ecosystem... This is a problem in 19.09 as well. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
cc
I also ran into this; I tried to debug and build it myself locally but it never seemed to rebuild when I ran in my local copy of nixpkgs. Even so, showed just the binary and nothing else. Eventually I tried the following diff to force a new build: Which caused to actually rebuild, and for some reason the rest of the binaries showed up in even with no other changes: I'm relatively new to nix, so not sure why bumping the version changes anything.
Interesting find! Just changing to makes it work as well, even without adding a version to the end of it. I tried keeping and adding a separate attribute but no such luck. There's something odd going on with I'd say.
So what seems to happen is that bundlerEnv is two different things depending if you have a or a . Maybe there's a bug in there somewhere: But I made PR's to revert to using instead for now.
Seems like this is still/again a problem ( missing) on NixOS 21.11 since it has been again mass-replaced in
After initial testing this seems to work. Are there any downsides to using here? (except for the fact that we need to list out executables to be exposed)
I don't know the ruby tooling in nix enough to know if there's any downsides or upsides of making that change. however, I'm not sure why version is removed? If you would make a PR of that we could ask someone with more ruby insights.
Sure, I can do that next week. IIRC / changes behaviour depending on existence of param. If it is missing, it'll be pulled in from relevant gemfiles in anyways.
Sounds good to me, I'm currently running my install from nixos 19.09, because it was the latest release where I found it working :wink: I guess that's the power of Nix, but it's not a good thing to have broken packages like this. So ping me when you have that PR open and I'll test it it and possibly merge it :)
Heyho, any updates on this? :) I finally also migrated my work laptop to NixOS and just ran into this because the binary is missing. I am not at all experienced with neither Nix or NixOS but just renaming to in the appears to fix the problem, the presence of the version variable apparently doesn't have any impact on the result.

{ lib, bundlerEnv, bundlerUpdateScript, ruby, perl, autoconf }: bundlerEnv { <del> pname = "chef-dk"; version = "4.13.3"; </del> <ins> name = "chef-dk-4.13.3"; # Do not change this to pname & version until underlying issues with Ruby # packaging are resolved ; see https://github.com/NixOS/nixpkgs/issues/70171 </ins> inherit ruby; gemdir = ./.;


Question:
Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: -build -A chefdk ./result/bin/chef ./result/bin/knife Expected behavior The chef executable is there but is broken, the knife executable isn't even present. Additional context broke chef, it worked before that commit. I've bisected it down to that changeset. Problem for me is that I don't know ruby or the ruby ecosystem... This is a problem in 19.09 as well. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
cc
I also ran into this; I tried to debug and build it myself locally but it never seemed to rebuild when I ran in my local copy of nixpkgs. Even so, showed just the binary and nothing else. Eventually I tried the following diff to force a new build: Which caused to actually rebuild, and for some reason the rest of the binaries showed up in even with no other changes: I'm relatively new to nix, so not sure why bumping the version changes anything.
Interesting find! Just changing to makes it work as well, even without adding a version to the end of it. I tried keeping and adding a separate attribute but no such luck. There's something odd going on with I'd say.
So what seems to happen is that bundlerEnv is two different things depending if you have a or a . Maybe there's a bug in there somewhere: But I made PR's to revert to using instead for now.
Seems like this is still/again a problem ( missing) on NixOS 21.11 since it has been again mass-replaced in
After initial testing this seems to work. Are there any downsides to using here? (except for the fact that we need to list out executables to be exposed)
I don't know the ruby tooling in nix enough to know if there's any downsides or upsides of making that change. however, I'm not sure why version is removed? If you would make a PR of that we could ask someone with more ruby insights.
Sure, I can do that next week. IIRC / changes behaviour depending on existence of param. If it is missing, it'll be pulled in from relevant gemfiles in anyways.
Sounds good to me, I'm currently running my install from nixos 19.09, because it was the latest release where I found it working :wink: I guess that's the power of Nix, but it's not a good thing to have broken packages like this. So ping me when you have that PR open and I'll test it it and possibly merge it :)
Heyho, any updates on this? :) I finally also migrated my work laptop to NixOS and just ran into this because the binary is missing. I am not at all experienced with neither Nix or NixOS but just renaming to in the appears to fix the problem, the presence of the version variable apparently doesn't have any impact on the result.

{ lib, bundlerEnv, bundlerUpdateScript, ruby_2_4, perl, autoconf }: bundlerEnv { <del> pname = "chef-dk"; </del> <ins> name = "chef-dk-2.4.17"; </ins> ruby = ruby_2_4; gemdir = ./.;


Question:
Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise. (for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though

rustPlatform.buildRustPackage rec { pname = "sequoia"; <del> version = "0.10.0"; </del> <ins> version = "0.11.0"; </ins> src = fetchFromGitLab { owner = "sequoia-pgp"; repo = pname; rev = "v${version}"; <del> sha256 = "0gvczghyik56jlnb8cz7jg2l3nbm519gf19g7l5blxci3009v23d"; </del> <ins> sha256 = "1k0pr3vn77fpfzyvbg7xb4jwm6srsiws9bsd8q7i3hl6j56a880i"; </ins> }; <del> cargoSha256 = "0dk9sjcbmygbdpwqnah5krli1p9j5hahgiqrca9c0kfpfiwgx62q"; </del> <ins> cargoSha256 = "15bhg7b88rq8p0bn6y5wwv2l42kqb1qyx2s3kw0r0v0wadf823q3"; </ins> nativeBuildInputs = [ pkgconfig


Question:
Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise. (for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though

license = licenses.gpl3; maintainers = with maintainers; [ minijackson doronbehar ]; platforms = platforms.all; <del> broken = true; </del> <ins> broken = stdenv.targetPlatform.isDarwin; </ins> }; }


Question:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

<ins> diff --git a/src/main/cpp/option_processor.cc b/src/main/cpp/option_processor.cc index 8f8f15685f..a7ae52d1e4 100644 --- a/src/main/cpp/option_processor.cc +++ b/src/main/cpp/option_processor.cc @@ -56,7 +56,7 @@ OptionProcessor::OptionProcessor( : workspace_layout_(workspace_layout), startup_options_(std::move(default_startup_options)), parse_options_called_(false), -      system_bazelrc_path_(BAZEL_SYSTEM_BAZELRC_PATH) {} +      system_bazelrc_path_("@bazelSystemBazelRCPath@") {} OptionProcessor::OptionProcessor( const WorkspaceLayout* workspace_layout, </ins>


Question:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

, autoPatchelfHook , file , substituteAll <ins> , writeTextFile </ins> }: let


Question:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

''; }; <ins> bazelRC = writeTextFile { name = "bazel-rc"; text = '' build --override_repository=${remote_java_tools.name}=${remote_java_tools} build --distdir=${distDir} startup --server_javabase=${runJdk} # load default location for the system wide configuration try-import /etc/bazel.bazelrc ''; }; </ins> in stdenv.mkDerivation rec { pname = "bazel";


Question:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

src = ./strict_action_env.patch; strictActionEnvPatch = defaultShellPath; }) <ins> # bazel reads its system bazelrc in /etc # override this path to a builtin one (substituteAll { src = ./bazel_rc.patch; bazelSystemBazelRCPath = bazelRC; }) </ins> ] ++ lib.optional enableNixHacks ./nix-hacks.patch;


Question:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

mv runfiles.bash.tmp tools/bash/runfiles/runfiles.bash patchShebangs . <del> # bazel reads its system bazelrc in /etc # override this path to a builtin one substituteInPlace  src/main/cpp/option_processor.cc  --replace BAZEL_SYSTEM_BAZELRC_PATH ""$out/etc/bazelrc"" </del> ''; in lib.optionalString stdenv.hostPlatform.isDarwin darwinPatches + genericPatches;


Question:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

cp ./bazel_src/scripts/packages/bazel.sh $out/bin/bazel mv ./bazel_src/output/bazel $out/bin/bazel-real <del> wrapProgram "$out/bin/bazel" --add-flags --server_javabase="${runJdk}" # generates the system bazelrc # warning: the name of the repository depends on the system, hence # the reference to .name mkdir $out/etc echo "build --override_repository=${remote_java_tools.name}=${remote_java_tools}" > $out/etc/bazelrc echo "build --distdir=${distDir}" >> $out/etc/bazelrc </del> # shell completion files mkdir -p $out/share/bash-completion/completions $out/share/zsh/site-functions mv ./bazel_src/output/bazel-complete.bash $out/share/bash-completion/completions/bazel


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

source-sans-pro ]; <ins> ## Enable soft realtime scheduling, only supported on wayland ## security.wrappers.".gnome-shell-wrapped" = { source = "${pkgs.gnome3.gnome-shell}/bin/.gnome-shell-wrapped"; capabilities = "cap_sys_nice=ep"; }; systemd.user.services.gnome-shell-wayland = let gnomeShellRT = with pkgs.gnome3; pkgs.runCommand "gnome-shell-rt" {} '' mkdir -p $out/bin/ cp ${gnome-shell}/bin/gnome-shell $out/bin sed -i "s@${gnome-shell}/bin/@${config.security.wrapperDir}/@" $out/bin/gnome-shell ''; in { # Note we need to clear ExecStart before overriding it serviceConfig.ExecStart = ["" "${gnomeShellRT}/bin/gnome-shell"]; # Do not use the default environment, it provides a broken PATH environment = mkForce {}; }; </ins> # Adapt from https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/gnome-3-32/elements/core/meta-gnome-core-shell.bst environment.systemPackages = with pkgs.gnome3; [ adwaita-icon-theme


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

{ fetchurl, fetchpatch, substituteAll, stdenv, pkgconfig, gnome3, gettext, gobject-introspection, upower, cairo <del> , pango, cogl, clutter, libstartup_notification, zenity, libcanberra-gtk3 </del> <ins> , pango, cogl, json-glib, libstartup_notification, zenity, libcanberra-gtk3 </ins> , ninja, xkeyboard_config, libxkbfile, libxkbcommon, libXtst, libinput , gsettings-desktop-schemas, glib, gtk3, gnome-desktop , geocode-glib, pipewire, libgudev, libwacom, xwayland, meson


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

, wrapGAppsHook , sysprof , desktop-file-utils <ins> , libcap_ng </ins> }: stdenv.mkDerivation rec {


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

propagatedBuildInputs = [ # required for pkgconfig to detect mutter-clutter libXtst <ins> json-glib libcap_ng </ins> ]; nativeBuildInputs = [


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

buildInputs = [ glib gobject-introspection gtk3 gsettings-desktop-schemas upower <del> gnome-desktop cairo pango cogl clutter zenity libstartup_notification </del> <ins> gnome-desktop cairo pango cogl zenity libstartup_notification </ins> geocode-glib libinput libgudev libwacom libcanberra-gtk3 zenity xkeyboard_config libxkbfile libxkbcommon pipewire xwayland


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

]; patches = [ <ins> # Drop inheritable cap_sys_nice, to prevent the ambient set from leaking # from mutter/gnome-shell, see https://github.com/NixOS/nixpkgs/issues/71381 ./drop-inheritable.patch </ins> # TODO: submit upstream ./0001-build-use-get_pkgconfig_variable-for-sysprof-dbusdir.patch (substituteAll {


Question:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

<ins> From e9c772e265b2293af031c79f4bbc99b5847dfe3c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tor=20Hedin=20Br=C3=B8nner?= <torhedinbronner@gmail.com> Date: Sat, 19 Oct 2019 13:26:05 +0200 Subject: [PATCH] drop inheritable Adapted from https://gitlab.gnome.org/GNOME/mutter/commit/c53c47ae123b03cc66044d2b846342123ecb3a01 We only want to drop inheritable though, to prevent the ambient set leaking further than gnome-shell. --- config.h.meson    |  3 +++ meson.build       |  5 +++++ meson_options.txt |  6 ++++++ src/core/main.c   | 11 +++++++++++ src/meson.build   |  1 + 5 files changed, 26 insertions(+) diff --git a/config.h.meson b/config.h.meson index 0bab71848..202fb7ed1 100644 --- a/config.h.meson +++ b/config.h.meson @@ -58,6 +58,9 @@ /* Xwayland applications allowed to issue keyboard grabs */ #mesondefine XWAYLAND_GRAB_DEFAULT_ACCESS_RULES +/* Defined if libcap-ng is available */ +#mesondefine HAVE_LIBCAPNG + /* XKB base prefix */ #mesondefine XKB_BASE diff --git a/meson.build b/meson.build index 3322bd3b1..01c8020fa 100644 --- a/meson.build +++ b/meson.build @@ -35,6 +35,7 @@ libstartup_notification_req = '>= 0.7' libcanberra_req = '>= 0.26' libwacom_req = '>= 0.13' atk_req = '>= 2.5.3' +libcapng_req = '>= 0.7.9' # optional version requirements udev_req = '>= 228' @@ -125,6 +126,7 @@ xau_dep = dependency('xau') ice_dep = dependency('ice') atk_dep = dependency('atk', version: atk_req) libcanberra_dep = dependency('libcanberra', version: libcanberra_req) +libcapng_dep = dependency('libcap-ng', required: get_option('libcapng')) # For now always require X11 support have_x11 = true @@ -256,6 +258,7 @@ have_core_tests = false have_cogl_tests = false have_clutter_tests = false have_installed_tests = false +have_libcapng = libcapng_dep.found() if have_tests have_core_tests = get_option('core_tests') @@ -361,6 +364,7 @@ cdata.set('HAVE_LIBWACOM', have_libwacom) cdata.set('HAVE_SM', have_sm) cdata.set('HAVE_STARTUP_NOTIFICATION', have_startup_notification) cdata.set('HAVE_INTROSPECTION', have_introspection) +cdata.set('HAVE_LIBCAPNG', have_libcapng) cdata.set('HAVE_PROFILER', have_profiler) xkb_base = xkeyboard_config_dep.get_pkgconfig_variable('xkb_base') @@ -443,6 +447,7 @@ output = [ '        Startup notification..... ' + have_startup_notification.to_string(), '        Introspection............ ' + have_introspection.to_string(), '        Profiler................. ' + have_profiler.to_string(), +  '        libcap-ng................ ' + have_libcapng.to_string(), '', '    Tests:', '', diff --git a/meson_options.txt b/meson_options.txt index 73aa7adde..8bfaacd9a 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -152,3 +152,9 @@ option('xwayland_grab_default_access_rules', value: 'gnome-boxes,remote-viewer,virt-viewer,virt-manager,vinagre,vncviewer,Xephyr', description: 'Comma delimited list of applications ressources or class allowed to issue X11 grabs in Xwayland' ) + +option('libcapng', +  type: 'feature', +  value: 'auto', +  description: 'Enable libcap-ng support' +) diff --git a/src/core/main.c b/src/core/main.c index 7f4f666d2..b27968f13 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -66,6 +66,10 @@ #include <girepository.h> #endif +#ifdef HAVE_LIBCAPNG +#include <cap-ng.h> +#endif + #if defined(HAVE_NATIVE_BACKEND) && defined(HAVE_WAYLAND) #include <systemd/sd-login.h> #endif /* HAVE_WAYLAND && HAVE_NATIVE_BACKEND */ @@ -673,6 +677,12 @@ meta_run (void) if (!meta_display_open ()) meta_exit (META_EXIT_ERROR); +#ifdef HAVE_LIBCAPNG +  capng_clear(CAPNG_SELECT_BOTH); +  capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SYS_NICE); +  capng_apply(CAPNG_SELECT_BOTH); +#endif + g_main_loop_run (meta_main_loop); meta_finalize (); diff --git a/src/meson.build b/src/meson.build index 90d80734f..a9fffa2c2 100644 --- a/src/meson.build +++ b/src/meson.build @@ -18,6 +18,7 @@ mutter_pkg_deps = [ glib_dep, gsettings_desktop_schemas_dep, gtk3_dep, +  libcapng_dep, pango_dep, ] -- 2.23.0 </ins>


Question:
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?

<del> { mkDerivation, lib, fetchurl, qtbase, qttools, qmake }: </del> <ins> { mkDerivation, lib, fetchurl, qtbase, qtsvg, qttools, qmake }: </ins> let inherit (lib) getDev; in


Question:
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?

nativeBuildInputs = [ qmake qttools ]; <del> buildInputs = [ qtbase ]; </del> <ins> buildInputs = [ qtbase qtsvg ]; </ins> qmakeFlags = [ "LRELEASE_EXECUTABLE=${getDev qttools}/bin/lrelease" <ins> "PLUGINDIR=${placeholder "out"}/${qtbase.qtPluginPrefix}" </ins> ]; <del> preConfigure = '' qmakeFlags+=" PLUGINDIR=$out/$qtPluginPrefix" ''; </del> enableParallelBuilding = true; meta = with lib; {


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

{ stdenv , fetchFromGitHub <ins> , fetchpatch </ins> , cairo , graphicsmagick , pkg-config


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

, python3 , which , zopfli <del> , fetchpatch </del> <ins> , noto-fonts-emoji </ins> }: let version = "12.1.2"; <del> # Cannot use noto-fonts-emoji.src since it is too old # and still tries to use vendored pngquant. notoSrc = fetchFromGitHub { name = "noto"; owner = "googlefonts"; repo = "noto-emoji"; rev = "833a43d03246a9325e748a2d783006454d76ff66"; sha256 = "1g6ikzk8banm3ihqm9g27ggjq2mn1b1hq3zhpl13lxid6mp60s4a"; }; </del> twemojiSrc = fetchFromGitHub { name = "twemoji"; owner = "twitter";


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

sha256 = "0vzmlp83vnk4njcfkn03jcc1vkg2rf12zf5kj3p3a373xr4ds1zn"; }; <del> python = python3.withPackages (pp: with pp; [ nototools ]); </del> in stdenv.mkDerivation rec { pname = "twitter-color-emoji"; inherit version; srcs = [ <del> notoSrc </del> <ins> noto-fonts-emoji.src </ins> twemojiSrc ]; <del> sourceRoot = notoSrc.name; </del> <ins> sourceRoot = noto-fonts-emoji.src.name; </ins> postUnpack = '' chmod -R +w ${twemojiSrc.name} <del> mv ${twemojiSrc.name} ${notoSrc.name} </del> <ins> mv ${twemojiSrc.name} ${noto-fonts-emoji.src.name} </ins> ''; nativeBuildInputs = [


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

graphicsmagick pkg-config pngquant <del> python </del> <ins> python3 python3.pkgs.nototools </ins> which zopfli ]; patches = [ <del> # Port to python3 (fetchpatch { url = "https://src.fedoraproject.org/rpms/twitter-twemoji-fonts/raw/3bc176c10ced2824fe03da5ff561e22a36bf8ccd/f/noto-emoji-port-to-python3.patch"; sha256 = "1b91abd050phxlxq7322i74nkx16fkhpw14yh97r2j4c7fqarr2q"; }) (fetchpatch { url = "https://src.fedoraproject.org/rpms/twitter-twemoji-fonts/raw/3bc176c10ced2824fe03da5ff561e22a36bf8ccd/f/noto-emoji-python3.patch"; sha256 = "0mw2c748izb6h9a19jwc0qxlb6l1kj6k8gc345lpf7lfcxfl7l59"; }) </del> <ins> # ImageMagick -> GrahphicsMagick </ins> (fetchpatch { url = "https://src.fedoraproject.org/rpms/twitter-twemoji-fonts/raw/3bc176c10ced2824fe03da5ff561e22a36bf8ccd/f/noto-emoji-use-gm.patch"; sha256 = "0yfmfzaaiq5163c06172g4r734aysiqyv1s28siv642vqzsqh4i2";


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

pname = "scfbuild"; version = "1.0.3"; <ins> format = "other"; </ins> src = fetchFromGitHub { <del> owner = "eosrei"; </del> <ins> owner = "13rac1"; </ins> repo = "scfbuild"; rev = "9acc7fc5fedbf48683d8932dd5bd7583bf922bae"; sha256 = "1zlqsxkpg7zvmhdjgbqwwc9qgac2b8amzq8c5kwyh5cv95zcp6qn"; }; <del> phases = [ "unpackPhase" "installPhase" "fixupPhase" ]; </del> <ins> patches = [ # Convert to Python 3 # https://github.com/13rac1/scfbuild/pull/19 ./python-3.patch ]; </ins> propagatedBuildInputs = [ pyyaml fonttools fontforge ]; installPhase = '' <ins> runHook preInstall </ins> mkdir -p $out/${python.sitePackages} cp -r scfbuild $out/${python.sitePackages} cp -r bin $out <ins> runHook postInstall </ins> ''; meta = with lib; { description = "SVGinOT color font builder"; <del> homepage = https://github.com/eosrei/scfbuild; </del> <ins> homepage = https://github.com/13rac1/scfbuild; </ins> license = licenses.gpl3; maintainers = with maintainers; [ abbradar ]; };


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

<ins> --- a/bin/scfbuild +++ b/bin/scfbuild @@ -1,4 +1,4 @@ -#!/usr/bin/env python2 +#!/usr/bin/env python3 # -*- coding: utf-8 -*- from __future__ import (absolute_import, division, print_function, --- a/scfbuild/builder.py +++ b/scfbuild/builder.py @@ -287,8 +287,8 @@ def _add_name_record(self, text, name_id, platform_id, plat_enc_id, lang_id): # TODO: The installed version of fontTools doesn't have # table__n_a_m_e.setName(). record = NameRecord() -        # PyYAML creates strings, force to Unicode -        record.string = unicode(text) +        # PyYAML creates strings, which are unicode as of Python3 +        record.string = text record.nameID = name_id record.platformID = platform_id record.platEncID = plat_enc_id --- a/scfbuild/fforge.py +++ b/scfbuild/fforge.py @@ -84,7 +84,7 @@ def add_glyphs(font, svg_filepaths, conf): u_ids = [int(u_id, 16) for u_id in filename.split("-")] # Example: (0x1f441, 0x1f5e8) -            u_str = ''.join(map(unichr, u_ids)) +            u_str = ''.join(map(chr, u_ids)) # Example: "U0001f441U0001f5e8" # Replace sequences with correct ZWJ/VS16 versions as needed --- a/scfbuild/main.py +++ b/scfbuild/main.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python2 +#!/usr/bin/env python3 # -*- coding: utf-8 -*- # SCFBuild is released under the GNU General Public License v3. index 0000000..99418b5 --- /dev/null +++ b/scfbuild/requirements.txt @@ -0,0 +1,2 @@ +fonttools>=3.41.2 +PyYAML>=5.1 </ins>


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

qtbase = qt4; }; <del> scfbuild = python2.pkgs.callPackage ../tools/misc/scfbuild { }; </del> <ins> scfbuild = python3.pkgs.callPackage ../tools/misc/scfbuild { }; </ins> scriptaculous = callPackage ../development/libraries/scriptaculous { };


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

<del> { stdenv, fetchgit, fontforge, pythonFull }: </del> <ins> { stdenv, fetchgit, fontforge, python3 }: </ins> stdenv.mkDerivation rec { pname = "rictydiminished-with-firacode";


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

nativeBuildInputs = [ fontforge <del> (pythonFull.withPackages (ps: [ </del> <ins> (python3.withPackages (ps: [ </ins> ps.jinja2 ps.py3to2 ps.fonttools


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

<del> { stdenv, fetchFromGitHub, fontforge, pythonPackages, python }: </del> <ins> { stdenv, fetchFromGitHub, fontforge, python3Packages, python3 }: </ins> stdenv.mkDerivation rec { pname = "liberation-sans-narrow";


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

sha256 = "1qw554jbdnqkg6pjjl4cqkgsalq3398kzvww2naw30vykcz752bm"; }; <del> buildInputs = [ fontforge pythonPackages.fonttools python ]; </del> <ins> buildInputs = [ fontforge python3Packages.fonttools python3 ]; </ins> installPhase = '' find . -name '*Narrow*.ttf' -exec install -m444 -Dt $out/share/fonts/truetype {} ;


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

<del> { stdenv, fetchFromGitHub, python2Packages, fontforge }: </del> <ins> { stdenv, fetchFromGitHub, python3Packages}: </ins> stdenv.mkDerivation rec { pname = "xits-math";


Question:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

sha256 = "043g0gnjc7wn1szvrs0rc1vvrq1qmhqh45b0y2kwrlxsgprpv8ll"; }; <del> nativeBuildInputs = [ fontforge ] ++ (with python2Packages; [ python fonttools ]); </del> <ins> nativeBuildInputs = (with python3Packages; [ python fonttools fontforge ]); </ins> postPatch = '' rm *.otf


Question: Describe the bug The stable channel was last updated 5 days before. The blocking issue seems to be the build of nlohmannjson timing out. To Reproduce Steps to reproduce the behavior: to local nixpkgs repo: latest changes: stable channel: : That works, so there is no actual issue with the build. The problem is that a test times out on the CI: Maintainer information:

"-DJSON_MultipleHeaders=ON" ]; <del> doCheck = stdenv.hostPlatform == stdenv.buildPlatform; </del> <ins> # A test cause the build to timeout https://github.com/nlohmann/json/issues/1816 #doCheck = stdenv.hostPlatform == stdenv.buildPlatform; doCheck = false; </ins> postInstall = "rm -rf $out/lib64";


Question:
p4merge is unable to start due to missing library. results in:
cc
Fixed by backporting

# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}


Question:
Describe the bug The latest macvim fails to install with a build error like below I think this change is the cause: The previous version builds fine. To Reproduce the channel to the latest one. or update macvim: or will see the error back to the previous generation: works fine Expected behavior Should install/update fine. Screenshots N/A Additional context macOS 10.14.6 (18G87) Metadata Please run and paste the result. Maintainer information:
cc:
Huh, it builds on my 10.14.6 machine, I wonder what the difference is. Also looking through the build output right now I see on the link command for MacVim. Did you customize macvim, or just build it as-is?
I guess the link command for the binary doesn't include , just the one for .
I don't have any customizations.
Ok I’ll look into adding the right flag to the Vim link step when I can.
Can you test and let me know if that fixes it?
Will do but I'm quite new to nix and don't know how to apply that change to my local nix env. Any pointers?
Normally I'd suggest using to build it, but that builds with the sandbox and macvim can't build with the full sandbox (it requires the sandbox to be off or in ). Given that, what you can do is just check out the PR branch. If you have a git checkout of nixpkgs this can be done with . Then you can run to build macvim from that checkout. If this succeeds it'll create a symlink in the current directory that contains the build results. You could in theory install this into your environment too if you like, with .
Can do or
worked. Thanks, & !
Thank you for testing. I will merge the fix now.

"--with-tclsh=${tcl}/bin/tclsh" "--with-tlib=ncurses" "--with-compiledby=Nix" <ins> "LDFLAGS=-headerpad_max_install_names" </ins> ]; makeFlags = ''PREFIX=$(out) CPPFLAGS="-Wno-error"'';


Question:
, (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
CVE-2019-: Fixed at version 0.60.8 (nixos-19.09, nixos-20.03, nixos-unstable).

in stdenv.mkDerivation rec { <del> name = "aspell-0.60.6.1"; </del> <ins> name = "aspell-0.60.8"; </ins> src = fetchurl { url = "mirror://gnu/aspell/${name}.tar.gz"; <del> sha256 = "1qgn5psfyhbrnap275xjfrzppf5a83fb67gpql0kfqv37al869gm"; </del> <ins> sha256 = "1wi60ankalmh8ds7nplz434jd7j94gdvbahdwsr539rlad8pxdzr"; </ins> }; <del> patches = [ (fetchpatch { # remove in >= 0.60.7 name = "gcc-7.patch"; url = "https://github.com/GNUAspell/aspell/commit/8089fa02122fed0a.diff"; sha256 = "1b3p1zy2lqr2fknddckm58hyk95hw4scf6hzjny1v9iaic2p37ix"; }) (fetchpatch { name = "CVE-2019-17544.patch"; url = "https://github.com/GNUAspell/aspell/commit/80fa26c74279fced8d778351cff19d1d8f44fe4e.patch"; sha256 = "0k5dnh8gcb7chnyx7jgkksqmz2hm05hmrvcd0znsfib975pvp4rg"; }) ] ++ stdenv.lib.optional searchNixProfiles ./data-dirs-from-nix-profiles.patch; </del> <ins> patches = stdenv.lib.optional searchNixProfiles ./data-dirs-from-nix-profiles.patch; </ins> postPatch = '' patch interfaces/cc/aspell.h < ${./clang.patch} ''; <del> nativeBuildInputs = [ perl ]; </del> <ins> buildInputs = [ perl ]; </ins> doCheck = true;


Question:
, (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also: ,
09 updated in (staging ATM, but should get into channel within days). I trust the bump solves all these CVEs.


Question:
Describe the bug git fails to build on darwin Metadata nixpkgs at Maintainer information:
cc
example hydra log: culprit failing tests:

# As of 2.19.0, t5562 refers to #!/usr/bin/perl patchShebangs t/t5562/invoke-with-content-length.pl <ins> '' + stdenv.lib.optionalString stdenv.isDarwin '' # XXX: Some tests added in 2.24.0 fail. # Please try to re-enable on the next release. disable_test t7816-grep-binary-pattern </ins> '' + stdenv.lib.optionalString stdenv.hostPlatform.isMusl '' # Test fails (as of 2.17.0, musl 1.1.19) disable_test t3900-i18n-commit


Question: Nixpkgs has 0.11.6, the latest release is 0.11.8

stdenv.mkDerivation rec { pname = "gnunet"; <del> version = "0.11.6"; </del> <ins> version = "0.11.8"; </ins> src = fetchurl { url = "mirror://gnu/gnunet/${pname}-${version}.tar.gz"; <del> sha256 = "1gspr1lh885sb9r2anh7bi4zan3zjqx33lpyhq9hm2g0n5ip187q"; </del> <ins> sha256 = "1zkmcq75sfr3iyg8rgxp9dbl7fwsvc1a71rc0vgisghcbrx1n7yj"; </ins> }; enableParallelBuilding = true;


Question: Describe the bug I'm installing send2trash Python lib from the unstable channel. It should be the 1.5.0 version, but it 1.4.2 in fact. To Reproduce Steps to reproduce the behavior: write the following: send2trash buld results: Expected behavior The expected result should be: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Link to the nix package

owner = "hsoft"; repo = "send2trash"; rev = version; <del> sha256 = "1w502i5h8xaqf03g6h95h4vs1wqfv6kg925dn63phrwmg1hfz2xx"; </del> <ins> sha256 = "1c76zldhw2ay7q7r00nnzcampjz9lkqfcbzqpm0iqp5i6bmmv30v"; </ins> }; doCheck = !stdenv.isDarwin;