jiebi/CodeConvo huggingface dataset:
Code change:
, (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-:

Related discussion:
text: <ins> commit 970fb11a296b5bbdc5e8425851253d2c5913c45e Author: Leon Bottou <leon@bottou.org> Date:   Tue Mar 26 20:36:31 2019 -0400 Fix bug#296 diff --git a/libdjvu/DjVmDir.cpp b/libdjvu/DjVmDir.cpp index a6a39e0..0a0fac6 100644 --- a/libdjvu/DjVmDir.cpp +++ b/libdjvu/DjVmDir.cpp @@ -299,42 +299,44 @@ 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; -        } +      int strings_size=strings.size(); +      strings.resize(strings_size+3); +      memset((char*) strings+strings_size, 0, 4); -         // Copy names into the files +      // Copy names into the files const char * ptr=strings; for(pos=files_list;pos;++pos) { GP<File> file=files_list[pos]; - +         if (ptr >= (const char*)strings + strings_size) +           G_THROW( "DjVu document is corrupted (DjVmDir)" ); file->id=ptr; ptr+=file->id.length()+1; if (file->flags & File::HAS_NAME) { -            file->name=ptr; -            ptr+=file->name.length()+1; -         } else +           file->name=ptr; +           ptr+=file->name.length()+1; +         } +         else { file->name=file->id; } if (file->flags & File::HAS_TITLE) { -            file->title=ptr; -       ptr+=file->title.length()+1; -         } else -       file->title=file->id; -   /* msr debug:  multipage file, file->title is null. +           file->title=ptr; +           ptr+=file->title.length()+1; +         } +         else +         { +           file->title=file->id; +         } +         /* msr debug:  multipage file, file->title is null. DEBUG_MSG(file->name << ", " << file->id << ", " << file->title << ", " << file->offset << ", " << file->size << ", " << file->is_page() << "n"); */ } -         // Check that there is only one file with SHARED_ANNO flag on +      // Check that there is only one file with SHARED_ANNO flag on int shared_anno_cnt=0; for(pos=files_list;pos;++pos) { </ins>
Code change:
, (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-:

Related discussion:
text: <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>
Code change:
, (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-:

Related discussion:
text: <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>
Code change:
, (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-:

Related discussion:
text: <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>
Code change:
, (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-:

Related discussion:
text: <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>
Code change:
, (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-:

Related discussion:
text: 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;
Code change:
, (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-:

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: { 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 = ./.;
Code change:
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.

Related discussion:
text: { 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 = ./.;
Code change:
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

Related discussion:
text: license = licenses.gpl3; maintainers = with maintainers; [ minijackson doronbehar ]; platforms = platforms.all; <del> broken = true; </del> <ins> broken = stdenv.targetPlatform.isDarwin; </ins> }; }
Code change:
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 .

Related discussion:
text: <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>