internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: conda/conda

Issue:
Conda <=4.7.10 does not respect repodata_fns condarc setting
<!--
Hi!  Read this; it's important.

This is an issue tracker for conda -- the package manager.  File feature requests
for conda here, as well as bug reports about something conda has messed up.

If your issue is a bug report for:
  * a specific conda package from Anaconda ('defaults' channel):
      ==> file at https://github.com/ContinuumIO/anaconda-issues
  * a specific conda package from conda-forge:
      ==> file at the corresponding feedstock under https://github.com/conda-forge
  * repo.anaconda.com access and service:
      ==> file at https://github.com/ContinuumIO/anaconda-issues
  * anaconda.org access and service:
      ==> file at https://anaconda.org/contact/report
  * commands under 'conda build':
      ==> file at https://github.com/conda/conda-build
  * commands under 'conda env':
      ==> please file it here!
  * all other conda commands that start with 'conda':
      ==> please file it here!

If you continue on,

   **please include all requested information below.**

If a maintainer determines the information is required to understand 
your issue, and if it is not provided, your issue may be
closed automatically.

-->

## Current Behavior
<!-- What actually happens?
     If you want to include console output, please use "Steps to Reproduce" below. -->

Setting ``repodata_fns`` in condarc has no effect on conda's behavior

```
repodata_fns:
  - repodata.json
```

### Steps to Reproduce
<!-- If the current behavior is a bug, please provide specific, minimal steps to independently reproduce.
     Include the exact conda commands that reproduce the issue and their output between the ticks below. -->
```

```


## Expected Behavior
<!-- What do you think should happen? -->


## Environment Information
<details open><summary><code>`conda info`</code></summary><p>
<!-- between the ticks below, paste the output of 'conda info' -->

```

```
</p></details>


<details open><summary><code>`conda config --show-sources`</code></summary><p>
<!-- between the ticks below, paste the output of 'conda config --show-sources' -->

```

```
</p></details>


<details><summary><code>`conda list --show-channel-urls`</code></summary><p>
<!-- between the ticks below, paste the output of 'conda list --show-channel-urls' -->

```

```
</p></details>



Discussion:

Resolving patch:
diff --git a/conda/cli/install.py b/conda/cli/install.py
--- a/conda/cli/install.py
+++ b/conda/cli/install.py
@@ -225,8 +225,8 @@ def install(args, parser, command='install'):
 
     repodata_fns = args.repodata_fns
     if not repodata_fns:
-        repodata_fns = ["current_repodata.json", "repodata.json"]
-    elif REPODATA_FN not in repodata_fns:
+        repodata_fns = context.repodata_fns
+    if REPODATA_FN not in repodata_fns:
         repodata_fns.append(REPODATA_FN)
 
     for repodata_fn in repodata_fns:


Test patch:
Repository: conda/conda

Issue:
conda raises bogus NotWritableError exception for a bogus attempt to chown to root
This isn't a dupe (well it is a dupe of #7109) but the issue still persists.

#7180 fixed the problem in one section of code, but the same problematic snippet is present here:

https://github.com/conda/conda/blob/master/conda/gateways/disk/update.py#L121
conda raises bogus NotWritableError exception for a bogus attempt to chown to root
This isn't a dupe (well it is a dupe of #7109) but the issue still persists.

#7180 fixed the problem in one section of code, but the same problematic snippet is present here:

https://github.com/conda/conda/blob/master/conda/gateways/disk/update.py#L121


Discussion:
This is pretty straightforward, and I'd be happy to fix it, I'd just like some feedback from the conda team first.  Thanks!
Sure, it seems like you have a fix identified, and that's most welcome.  Deduplicating code or otherwise fixing this problem would be very helpful, and we'd appreciate it.
This is pretty straightforward, and I'd be happy to fix it, I'd just like some feedback from the conda team first.  Thanks!
Sure, it seems like you have a fix identified, and that's most welcome.  Deduplicating code or otherwise fixing this problem would be very helpful, and we'd appreciate it.

Resolving patch:
diff --git a/conda/gateways/disk/update.py b/conda/gateways/disk/update.py
--- a/conda/gateways/disk/update.py
+++ b/conda/gateways/disk/update.py
@@ -109,17 +109,17 @@ def touch(path, mkdir=False, sudo_safe=False):
                     mkdir_p(dirpath)
             else:
                 assert isdir(dirname(path))
-            try:
-                fh = open(path, 'a')
-            except:
-                raise
-            else:
-                fh.close()
-                if sudo_safe and not on_win and os.environ.get('SUDO_UID') is not None:
-                    uid = int(os.environ['SUDO_UID'])
-                    gid = int(os.environ.get('SUDO_GID', -1))
-                    log.trace("chowning %s:%s %s", uid, gid, path)
-                    os.chown(path, uid, gid)
-                return False
+            with open(path, 'a'):
+                pass
+            # This chown call causes a false positive PermissionError to be
+            # raised (similar to #7109) when called in an environment which
+            # comes from sudo -u.
+            #
+            # if sudo_safe and not on_win and os.environ.get('SUDO_UID') is not None:
+            #     uid = int(os.environ['SUDO_UID'])
+            #     gid = int(os.environ.get('SUDO_GID', -1))
+            #     log.trace("chowning %s:%s %s", uid, gid, path)
+            #     os.chown(path, uid, gid)
+            return False
     except (IOError, OSError) as e:
         raise NotWritableError(path, e.errno, caused_by=e)


Test patch:
Repository: conda/conda

Issue:
get_python_version_for_prefix in prefix_data.py doesn't handle two digit minor version
The function `get_python_version_for_prefix` silently truncates two digit minor version numbers. For example, if the Python version number is 3.10, it will return "3.1", which can cause some packages to be installed in the incorrect location.

Of course, there isn't a Python 3.10 yet -- I ran into this while experimenting. FWIW, the accepted [PEP 602](https://www.python.org/dev/peps/pep-0602/) suggests that 3.10 will be the version after 3.9 (as opposed to 4.0). 

https://github.com/conda/conda/blob/2cdd7ab052c2b96c088137f52dc40c613e99ce33/conda/core/prefix_data.py#L370-L380


Discussion:

Resolving patch:
diff --git a/conda/core/prefix_data.py b/conda/core/prefix_data.py
--- a/conda/core/prefix_data.py
+++ b/conda/core/prefix_data.py
@@ -376,6 +376,8 @@ def get_python_version_for_prefix(prefix):
     next_record = next(py_record_iter, None)
     if next_record is not None:
         raise CondaDependencyError("multiple python records found in prefix %s" % prefix)
+    elif record.version[3].isdigit():
+        return record.version[:4]
     else:
         return record.version[:3]
 


Test patch:
Repository: conda/conda

Issue:
__linux virtual package
<!--
Hi!  Read this; it's important.

This is an issue tracker for conda -- the package manager.  File feature requests
for conda here, as well as bug reports about something conda has messed up.

Anaconda Community Code of Conduct: https://www.anaconda.com/community-code-of-conduct/

If your issue is a feature request for:
  * a specific conda package from Anaconda ('defaults' channel):
      ==> file at https://github.com/ContinuumIO/anaconda-issues
  * a specific conda package from conda-forge:
      ==> file at the corresponding feedstock under https://github.com/conda-forge
  * repo.anaconda.com access and service:
      ==> file at https://github.com/ContinuumIO/anaconda-issues
  * anaconda.org access and service:
      ==> file at https://anaconda.org/contact/report
  * commands under 'conda build':
      ==> file at https://github.com/conda/conda-build
  * commands under 'conda env':
      ==> please file it here!
  * all other conda commands that start with 'conda':
      ==> please file it here!

-->

Hi,

currently, there are `__unix` and` __linux` virtual packages. It would be nice to have one for Linux a well.

Based on #10214 I would assume this to be something along the lines of:

```python
if is_linux:
    rec = _make_virtual_package('__linux')
    index[rec] = rec
```

Happy to create the PR but just wanted to check first if that'd be the correct approach?


Discussion:

Resolving patch:
diff --git a/conda/core/index.py b/conda/core/index.py
--- a/conda/core/index.py
+++ b/conda/core/index.py
@@ -172,6 +172,8 @@ def _supplement_index_with_system(index):
     libc_family, libc_version = context.libc_family_version
     is_linux = context.subdir.startswith("linux-")
     if is_linux:
+        rec = _make_virtual_package('__linux')
+        index[rec] = rec
         if not (libc_family and libc_version):
             # Default to glibc when using CONDA_SUBDIR var
             libc_family = "glibc"


Test patch:
Repository: zulip/zulip

Issue:
Check for .git in Vagrantfile to avoid building dev VM from production tarballs.
Possibly I am missing something. I have Vagrant installed on a local Ubuntu 14.04 host, with the latest virtual box installed. Doing `Vagrant up`worked fine. However, inside the Vagrant container, there is no `./tools/run-dev.py`.

```
$ /srv/zulip $ sudo vagrant ssh -- -L9991:localhost:9991
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.16.0-38-generic x86_64)
 * Documentation:  https://help.ubuntu.com/
Last login: Tue Oct  6 12:48:44 2015 from 10.0.3.1
(zulip-venv)vagrant@vagrant-base-trusty-amd64:~$ cd /srv/zulip
(zulip-venv)vagrant@vagrant-base-trusty-amd64:/srv/zulip$ source /srv/zulip-venv/bin/activate
(zulip-venv)vagrant@vagrant-base-trusty-amd64:/srv/zulip$ ./tools/run-dev.py --interface=''
-bash: ./tools/run-dev.py: No such file or directory
```

Is this a know issue?



Discussion:
That is quite weird for the development environment.  Can you run `git status` inside /srv/zulip?  In theory that should just be a clone of the git repository with a few files added...

Hmm, that's where I went wrong:

```
(zulip-venv)vagrant@vagrant-base-trusty-amd64:/srv/zulip$ git status
fatal: Not a git repository (or any of the parent directories): .git
```

I downloaded the server install from https://www.zulip.com/dist/releases. I imagine i should be cloning https://github.com/zulip/zulip.git

Yes, exactly, there's two setup models:

(1) Zulip production server tarball, which has the javascript all built, etc from https://www.zulip.com/dist/releases
(2) Zulip development environment, where you want a git repository so you can easily test changes as you write commits for them, which uses vagrant

We should probably add a test in the Vagrantfile to confirm .git exists so other folks don't run into this problem.  I'll rename this issue to fixing that problem.


Resolving patch:
diff --git a/provision.py b/provision.py
--- a/provision.py
+++ b/provision.py
@@ -51,6 +51,12 @@
 VENV_PATH="/srv/zulip-venv"
 ZULIP_PATH="/srv/zulip"
 
+if not os.path.exists(os.path.join(os.path.dirname(__file__), ".git")):
+    print "Error: No Zulip git repository present at /srv/zulip!"
+    print "To setup the Zulip development environment, you should clone the code"
+    print "from GitHub, rather than using a Zulip production release tarball."
+    sys.exit(1)
+
 # TODO: Parse arguments properly
 if "--travis" in sys.argv:
     ZULIP_PATH="."


Test patch:
Repository: zulip/zulip

Issue:
Dependency on `wget` not declared
Attempting to provision in a minimal LXC container on Ubuntu 14.04:

```
Traceback (most recent call last):
  File "/srv/zulip/provision.py", line 182, in <module>
    sys.exit(main())
  File "/srv/zulip/provision.py", line 98, in main
    sh.wget(
  File "/usr/lib/python2.7/dist-packages/pbs.py", line 543, in __getattr__
    return self.env[name]
  File "/usr/lib/python2.7/dist-packages/pbs.py", line 495, in __missing__
    return Command._create(k)
  File "/usr/lib/python2.7/dist-packages/pbs.py", line 239, in _create
    if not path: raise CommandNotFound(program)
pbs.CommandNotFound: wget
```



Discussion:

Resolving patch:
diff --git a/provision.py b/provision.py
--- a/provision.py
+++ b/provision.py
@@ -36,6 +36,8 @@
         "git",
         "npm",
         "yui-compressor",
+        "wget",
+        "ca-certificates",      # Explicit dependency in case e.g. wget is already installed
         "puppet",               # Used by lint-all
         "gettext",              # Used by makemessages i18n
     ]


Test patch:
Repository: zulip/zulip

Issue:
Make `scripts/setup/generate-secrets -d` use existing setting values
Currently, `generate-secrets -d` regenerates all the secret keys each time it is run, modifying zproject/settings.py, which means that if you use the same Zulip checkout for both a development VM on the host and a Vagrant guest, every time you provision on the Vagrant guest, you need to rebuild the database (to match the new keys).  I think this would also affect someone using both Docker and Vagrant with the same checkout (as I imagine happens with some frequency when testing).



Discussion:
I think this would be pretty reasonable to do while still preserving the fact that it'll automatically add new settings by just checking whether `OUTPUT_SETTINGS_FILENAME` already exists, and if it does, parse the file and use the existing values if already present.

This would also have the nice side effect of making `scripts/setup/generate-settings` no longer dangerous to run on an already setup production server (right now, it will permanently delete all the secrets!).


Resolving patch:
diff --git a/scripts/setup/generate_secrets.py b/scripts/setup/generate_secrets.py
--- a/scripts/setup/generate_secrets.py
+++ b/scripts/setup/generate_secrets.py
@@ -8,6 +8,8 @@
 os.environ['DJANGO_SETTINGS_MODULE'] = 'zproject.settings'
 
 from django.utils.crypto import get_random_string
+import six
+
 from zerver.lib.utils import generate_random_token
 
 os.chdir(os.path.join(os.path.dirname(__file__), '..', '..'))
@@ -31,6 +33,21 @@ def generate_django_secretkey():
     chars = 'abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)'
     return get_random_string(50, chars)
 
+def get_old_conf(output_filename):
+    if not os.path.exists(output_filename):
+        return {}
+
+    secrets_file = six.moves.configparser.RawConfigParser()
+    secrets_file.read(output_filename)
+
+    def get_secret(key):
+        if secrets_file.has_option('secrets', key):
+            return secrets_file.get('secrets', key)
+        return None
+
+    fields = AUTOGENERATED_SETTINGS + ['secret_key', 'camo_key']
+    return {name: get_secret(name) for name in fields}
+
 def generate_secrets(development=False):
     if development:
         OUTPUT_SETTINGS_FILENAME = "zproject/dev-secrets.conf"
@@ -42,12 +59,16 @@ def generate_secrets(development=False):
     def config_line(var, value):
         return "%s = %s\n" % (var, value)
 
+    old_conf = get_old_conf(OUTPUT_SETTINGS_FILENAME)
     for name in AUTOGENERATED_SETTINGS:
-        lines.append(config_line(name, generate_random_token(64)))
+        lines.append(config_line(name, old_conf.get(name, generate_random_token(64))))
+
+    secret_key = old_conf.get('secret_key', generate_django_secretkey())
+    lines.append(config_line('secret_key', secret_key))
 
-    lines.append(config_line('secret_key', generate_django_secretkey()))
-    camo_key = get_random_string(64)
+    camo_key = old_conf.get('camo_key', get_random_string(64))
     lines.append(config_line('camo_key', camo_key))
+
     if not development:
         # Write the Camo config file directly
         generate_camo_config_file(camo_key)


Test patch:
Repository: zulip/zulip

Issue:
Running casper tests while run-dev.py is running doesn't work
The failure mode is hanging at "Logging in" in 00-login.js, and this seems to be easily reproducible.

This is a recent regression (this used to work) and would be great to debug.



Discussion:
So the way this is supposed to work is that the casper tests call `run-dev.py --test`, which is supposed to use a totally independent set of ports/interfaces/etc. from the normal `run-dev.py`.  I suspect we regressed this behavior somehow recently (possibly in 98d5f64f365e6c7008190a8ed88d59392ed35d1c).

I investigated this, and indeed, it is caused by `webpack` having some sort of lock that prevents running two copies of webpack on the same codebase.

I haven't figured out a way to work around this yet to actually fix the bug :(.


Resolving patch:
diff --git a/tools/run-dev.py b/tools/run-dev.py
--- a/tools/run-dev.py
+++ b/tools/run-dev.py
@@ -74,7 +74,6 @@ def patched_finish(self):
 # Pass --nostatic because we configure static serving ourselves in
 # zulip/urls.py.
 cmds = [['./tools/compile-handlebars-templates', 'forever'],
-        ['./tools/webpack', '--watch', '--port', str(webpack_port)],
         ['python', 'manage.py', 'rundjango'] +
           manage_args + ['localhost:%d' % (django_port,)],
         ['python', 'manage.py', 'runtornado'] +
@@ -82,7 +81,14 @@ def patched_finish(self):
         ['./tools/run-dev-queue-processors'] + manage_args,
         ['env', 'PGHOST=localhost', # Force password authentication using .pgpass
          './puppet/zulip/files/postgresql/process_fts_updates']]
-
+if options.test:
+    # Webpack doesn't support 2 copies running on the same system, so
+    # in order to support running the Casper tests while a Zulip
+    # development server is running, we use webpack in production mode
+    # for the Casper tests.
+    subprocess.check_call('./tools/webpack')
+else:
+    cmds += [['./tools/webpack', '--watch', '--port', str(webpack_port)]]
 for cmd in cmds:
     subprocess.Popen(cmd)
 
diff --git a/zproject/settings.py b/zproject/settings.py
--- a/zproject/settings.py
+++ b/zproject/settings.py
@@ -754,6 +754,7 @@ def get_secret(key):
 }
 
 if PIPELINE:
+    # This is also done in test_settings.py, see comment there..
     JS_SPECS['app']['source_filenames'].append('js/bundle.js')
 
 app_srcs = JS_SPECS['app']['source_filenames']


Test patch:
diff --git a/zproject/test_settings.py b/zproject/test_settings.py
--- a/zproject/test_settings.py
+++ b/zproject/test_settings.py
@@ -11,6 +11,10 @@
                         "TEST_NAME": "django_zulip_tests",
                         "OPTIONS": {"connection_factory": TimeTrackingConnection },}
 
+# In theory this should just go in zproject/settings.py inside the `if
+# PIPELINE` statement, but because zproject/settings.py is processed
+# first, we have to add it here as a hack.
+JS_SPECS['app']['source_filenames'].append('js/bundle.js')
 
 if "TORNADO_SERVER" in os.environ:
     # This covers the Casper test suite case
Repository: zulip/zulip

Issue:
Use options available in the latest mypy
With mypy's new `--scripts-are-modules` and `-i` options, we can make running mypy much faster (and the Travis CI output much cleaner).  The main challenge with `--scripts-are-modules` is that we need to annotate or exclude a bunch of files since we weren't previously running the scripts with `--disallow-untyped-defs`.  The main challenge with `-i` is that we need to make sure we put the cache in `.gitignore` properly, probably by just specifying a path under `var/`.

We're already using a new enough version of mypy for both of these.



Discussion:

Resolving patch:
diff --git a/scripts/lib/node_cache.py b/scripts/lib/node_cache.py
--- a/scripts/lib/node_cache.py
+++ b/scripts/lib/node_cache.py
@@ -5,7 +5,7 @@
 from os.path import dirname, abspath
 
 if False:
-    from typing import Optional, List, Tuple
+    from typing import Optional, List, IO, Tuple
 
 from scripts.lib.zulip_tools import subprocess_text_output, run
 
@@ -17,7 +17,7 @@
     NPM_CACHE_PATH = "/home/travis/zulip-npm-cache"
 
 def setup_node_modules(npm_args=None, stdout=None, stderr=None, copy_modules=False):
-    # type: (Optional[List[str]], Optional[str], Optional[str], Optional[bool]) -> None
+    # type: (Optional[List[str]], Optional[IO], Optional[IO], Optional[bool]) -> None
     sha1sum = hashlib.sha1()
     sha1sum.update(subprocess_text_output(['cat', 'package.json']).encode('utf8'))
     sha1sum.update(subprocess_text_output(['npm', '--version']).encode('utf8'))
@@ -42,7 +42,7 @@ def setup_node_modules(npm_args=None, stdout=None, stderr=None, copy_modules=Fal
         run(cmd, stdout=stdout, stderr=stderr)
 
 def do_npm_install(target_path, npm_args, stdout=None, stderr=None, copy_modules=False):
-    # type: (str, List[str], Optional[str], Optional[str], Optional[bool]) -> None
+    # type: (str, List[str], Optional[IO], Optional[IO], Optional[bool]) -> None
     cmds = [
         ["sudo", "rm", "-rf", target_path],
         ['sudo', 'mkdir', '-p', target_path],


Test patch:
Repository: zulip/zulip

Issue:
Add a --force option to tools/test-all.
If present, it should pass the `--force` option on to the scripts that take it. I believe these are `lint-all`, `test-backend`, and `test-js-with-node`.

Currently, one can run each of the individual tests in `tools/test-all` without provisioning, but not directly via `tools/test-all --force`. Running `tools/test-all` without provisioning also gives the currently misleading instruction `If you really know what you are doing, use --force to run anyway.` (The message is being printed by `lint-all`.)


Discussion:
Yeah this is a good idea.
Currently working at this..

Resolving patch:
diff --git a/tools/test-help-documentation.py b/tools/test-help-documentation.py
--- a/tools/test-help-documentation.py
+++ b/tools/test-help-documentation.py
@@ -1,5 +1,6 @@
 #!/usr/bin/env python
 from __future__ import print_function
+import optparse
 import os
 import sys
 import subprocess
@@ -19,6 +20,11 @@
 
 os.environ["EXTERNAL_HOST"] = "localhost:9981"
 
+parser = optparse.OptionParser()
+parser.add_option('--force', default=False,
+                  action="store_true",
+                  help='Run tests despite possible problems.')
+(options, args) = parser.parse_args()
 
 def assert_server_running(server):
     # type: (subprocess.Popen) -> None
@@ -45,7 +51,12 @@ def server_is_up(server):
     log.write('\n\n')
 else:
     log = open(LOG_FILE, 'w')
-server = subprocess.Popen(('tools/run-dev.py', '--test'), stdout=log, stderr=log)
+
+run_dev_server_command = ['tools/run-dev.py', '--test']
+if options.force:
+    run_dev_server_command.append('--force')
+server = subprocess.Popen(run_dev_server_command, stdout=log, stderr=log)
+
 sys.stdout.write('Waiting for test server')
 try:
     while not server_is_up(server):


Test patch:
diff --git a/frontend_tests/run-casper b/frontend_tests/run-casper
--- a/frontend_tests/run-casper
+++ b/frontend_tests/run-casper
@@ -123,7 +123,10 @@ def run_tests(realms_have_subdomains, files):
         remote_debug = "--remote-debugger-port=7777 --remote-debugger-autorun=yes"
 
     # Run this not through the shell, so that we have the actual PID.
-    server = subprocess.Popen(('tools/run-dev.py', '--test'),
+    run_dev_server_command = ['tools/run-dev.py', '--test']
+    if options.force:
+        run_dev_server_command.append('--force')
+    server = subprocess.Popen(run_dev_server_command,
                               stdout=log, stderr=log)
 
     ret = 1