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

Issue:
Wrong source url for pango when doing `spack fetch -D r` (with 2 walkarounds).
When doing `spack mirror create -D r` Spack tried to download the pango 1.41 from http://ftp.gnome.org/pub/GNOME/sources/pango/1.40/pango-1.41.0.tar.xz instead of http://ftp.gnome.org/pub/GNOME/sources/pango/1.41/pango-1.41.0.tar.xz . 


```
...

Adding package gobject-introspection@1.49.2 to mirror
==> gobject-introspection@1.49.2 : already added
==> Adding package pango@1.41.0 to mirror
==> Fetching http://ftp.gnome.org/pub/GNOME/sources/pango/1.40/pango-1.41.0.tar.xz

curl: (22) The requested URL returned error: 404 Not Found
==> Warning: Error while fetching pango@1.41.0
  Failed to fetch file from URL: http://ftp.gnome.org/pub/GNOME/sources/pango/1.40/pango-1.41.0.tar.xz
==> Adding package zlib@1.2.11 to mirror
==> zlib@1.2.11 : already added

...
```

The walkaround is to either `spack mirror create -D r ^pango@1.40` (which works correctly) or with `spack fetch pango`:

```
# spack fetch pango
spack fetch pango
==> Fetching http://ftp.gnome.org/pub/GNOME/sources/pango/1.40/pango-1.41.0.tar.xz
curl: (22) The requested URL returned error: 404 Not Found
==> Fetching from http://ftp.gnome.org/pub/GNOME/sources/pango/1.40/pango-1.41.0.tar.xz failed.
spack inst==> Fetching http://ftp.gnome.org/pub/gnome/sources/pango/1.41/pango-1.41.0.tar.xz
######################################################################## 100,0%
```

And after that `spack fetch -D r` works and problem heals itself automatically.


I tried to fix the seemingly trivial problem myself, but it looks like the effective pango URL is generated programmatically somewhere in the code, and at this stage I am helpless.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/pango/package.py b/var/spack/repos/builtin/packages/pango/package.py
--- a/var/spack/repos/builtin/packages/pango/package.py
+++ b/var/spack/repos/builtin/packages/pango/package.py
@@ -51,6 +51,10 @@ class Pango(AutotoolsPackage):
     depends_on("glib")
     depends_on('gobject-introspection')
 
+    def url_for_version(self, version):
+        url = "http://ftp.gnome.org/pub/GNOME/sources/pango/{0}/pango-{1}.tar.xz"
+        return url.format(version.up_to(2), version)
+
     def configure_args(self):
         args = []
         if self.spec.satisfies('+X'):


Test patch:
Repository: spack/spack

Issue:
R installation: tcltk capability missing
Summary

### Expected Result

tcltk capability should be true

### Actual Result

tcltk capability is false

### Steps to reproduce the issue

```console
$ spack install r +X
$ module load r-3.4...
$ R
$ > capabilities("tcltk")
$ FALSE
...
```
1. tcl & tk listed as dependence, so by default R should be compiled with tcltk option
2. Default installtion didn't work, so added '--with-tcltk" to config_args, still got the same result


### Information on your system

Centos 7, gcc 7.2


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/r/package.py b/var/spack/repos/builtin/packages/r/package.py
--- a/var/spack/repos/builtin/packages/r/package.py
+++ b/var/spack/repos/builtin/packages/r/package.py
@@ -96,11 +96,16 @@ def configure_args(self):
         spec   = self.spec
         prefix = self.prefix
 
+        tclConfig_path = join_path(spec['tcl'].prefix.lib, 'tclConfig.sh')
+        tkConfig_path = join_path(spec['tk'].prefix.lib, 'tkConfig.sh')
+
         config_args = [
             '--libdir={0}'.format(join_path(prefix, 'rlib')),
             '--enable-R-shlib',
             '--enable-BLAS-shlib',
-            '--enable-R-framework=no'
+            '--enable-R-framework=no',
+            '--with-tcl-config={0}'.format(tclConfig_path),
+            '--with-tk-config={0}'.format(tkConfig_path),
         ]
 
         if '+external-lapack' in spec:


Test patch:
Repository: spack/spack

Issue:
MPICH git broken; needs submodules
`mpich@develop` is broken (presumably since October 30, 2017), since it now requires submodules.
The fix is to add `submodules=True` to the the `version()` command:

```diff
-version('develop', git='git://github.com/pmodels/mpich')
+version('develop', git='git://github.com/pmodels/mpich', submodules=True)
```

### Expected Result

MPICH compiles and installs correctly. 

### Actual Result

I get an error about missing submodules.

### Steps to reproduce the issue

```console
$ spack install mpich@develop
```

### Information on your system

Arch Linux x86_64, but not truly important—this is a package problem.


Discussion:
Can you submit the PR?

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/mpich/package.py b/var/spack/repos/builtin/packages/mpich/package.py
--- a/var/spack/repos/builtin/packages/mpich/package.py
+++ b/var/spack/repos/builtin/packages/mpich/package.py
@@ -42,7 +42,7 @@ class Mpich(AutotoolsPackage):
     version('3.1.1', '40dc408b1e03cc36d80209baaa2d32b7')
     version('3.1',   '5643dd176499bfb7d25079aaff25f2ec')
     version('3.0.4', '9c5d5d4fe1e17dd12153f40bc5b6dbc0')
-    version('develop', git='git://github.com/pmodels/mpich')
+    version('develop', git='git://github.com/pmodels/mpich', submodules=True)
 
     variant('hydra', default=True,  description='Build the hydra process manager')
     variant('pmi',   default=True,  description='Build with PMI support')


Test patch:
Repository: spack/spack

Issue:
`spack versions` picking up URL from patch list
I'm seeing some strange behavior with the nwchem package. If you hack the package to add:
```python
url = "http://www.nwchem-sw.org/images/Nwchem-6.6.revision27746-src.2015-10-20.tar.gz"
```
and run:
```
$ spack versions nwchem
==> Error: Couldn't detect version in: http://www.nwchem-sw.org/images/Notdir_fc.patch.gz
```
This URL comes from `urls_for_patches`. Any idea why it would be picked up instead of the package-level `url`?


Discussion:
maybe @alalazo has an idea, he fixed patches in https://github.com/LLNL/spack/pull/2039
Whoa, I missed this and it dates back to February! Confirmed.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/nwchem/package.py b/var/spack/repos/builtin/packages/nwchem/package.py
--- a/var/spack/repos/builtin/packages/nwchem/package.py
+++ b/var/spack/repos/builtin/packages/nwchem/package.py
@@ -70,9 +70,9 @@ class Nwchem(Package):
         ]
     }
     # Iterate over patches
-    for condition, urls in urls_for_patches.items():
-        for url, sha256, archive_sha256 in urls:
-            patch(url, when=condition, level=0, sha256=sha256, archive_sha256=archive_sha256)
+    for __condition, __urls in urls_for_patches.items():
+        for __url, __sha256, __archive_sha256 in __urls:
+            patch(__url, when=__condition, level=0, sha256=__sha256, archive_sha256=__archive_sha256)
 
     def install(self, spec, prefix):
         scalapack = spec['scalapack'].libs


Test patch:
Repository: spack/spack

Issue:
Cannot specify hash with spack view

### Summary

I have multiple versions of hdf5 install, and I would like to create a view with just one of them.  Specifying the hash is the recommended way according to the documentation, but it does not seem to work.

### Expected Result

 I expect one of these options create a view:
Short hash:
```
spack view --verbose  symlink myview /fuqfcbe
spack view --verbose  symlink myview ^/fuqfcbe
```

Full hash:
```
spack view --verbose symlink myview /fuqfcbeakt2ecpn23xe3vcpimohc2gxe
spack view --verbose symlink myview ^/fuqfcbeakt2ecpn23xe3vcpimohc2gxe
```

### Actual Result

All permutations give the same result:
```
> spack view --verbose symlink myview ^/fuqfcbeakt2ecpn23xe3vcpimohc2gxe
==> Error: ^/fuqfcbeakt2ecpn23xe3vcpimohc2gxe matches multiple packages.
  Matching packages:
    hyfdeo5 binutils@2.29.1%clang@9.0.0-apple arch=darwin-sierra-x86_64
    uxdgzdu bison@3.0.4%clang@9.0.0-apple arch=darwin-sierra-x86_64
    5vyj7l5 bison@3.0.4%clang@9.0.0-apple arch=darwin-sierra-x86_64
    ...
```

### Steps to reproduce the issue

Any multiple versions of a package should work.  For me, I have 3 versions of hdf5 with the one I want to install being chosen because it has mpich.  `hdf5^mpich` did not work for me either.

```
> spack find --long hdf5
==> 4 installed packages.
-- darwin-sierra-x86_64 / clang@9.0.0-apple ---------------------
cdpvfjh hdf5@1.10.0-patch1  fuqfcbe hdf5@1.10.1  nfpaht4 hdf5@1.10.1  52sviwf hdf5@1.10.1
```
### System info

 1.  Darwin (MacOS 10.12.6)
 2. My version of spack is latest git develop branch.



Discussion:

Resolving patch:
diff --git a/lib/spack/spack/cmd/view.py b/lib/spack/spack/cmd/view.py
--- a/lib/spack/spack/cmd/view.py
+++ b/lib/spack/spack/cmd/view.py
@@ -172,6 +172,7 @@ def setup_parser(sp):
 def view(parser, args):
     'Produce a view of a set of packages.'
 
+    specs = spack.cmd.parse_specs(args.specs)
     path = args.path[0]
 
     view = YamlFilesystemView(
@@ -189,18 +190,18 @@ def view(parser, args):
 
     elif args.action in actions_link:
         # only link commands need to disambiguate specs
-        specs = [spack.cmd.disambiguate_spec(s) for s in args.specs]
+        specs = [spack.cmd.disambiguate_spec(s) for s in specs]
 
     elif args.action in actions_status:
         # no specs implies all
-        if len(args.specs) == 0:
+        if len(specs) == 0:
             specs = view.get_all_specs()
         else:
-            specs = relaxed_disambiguate(args.specs, view)
+            specs = relaxed_disambiguate(specs, view)
 
     else:
         # status and remove can map the name to packages in view
-        specs = relaxed_disambiguate(args.specs, view)
+        specs = relaxed_disambiguate(specs, view)
 
     with_dependencies = args.dependencies.lower() in ['true', 'yes']
 


Test patch:
Repository: spack/spack

Issue:
libxcb: Add the python 2 dependency
Otherwise the installation in a Python 3 environment fails.


Discussion:
P.S. See #4145 and #4063 for more history.
Update: It looks like a new version of `libxcb` has been released that has Python 3 support. I'll add that and see if I can patch older versions to also work. Seems like the only problem is tabs vs. spaces.

Update update: replacing tabs with spaces wasn't the only problem. I don't want to dig into it too much, but the latest version of `libxcb` should work fine.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/libxcb/package.py b/var/spack/repos/builtin/packages/libxcb/package.py
--- a/var/spack/repos/builtin/packages/libxcb/package.py
+++ b/var/spack/repos/builtin/packages/libxcb/package.py
@@ -32,19 +32,29 @@ class Libxcb(AutotoolsPackage):
     extensibility."""
 
     homepage = "https://xcb.freedesktop.org/"
-    url      = "https://xcb.freedesktop.org/dist/libxcb-1.11.tar.gz"
+    url      = "https://xcb.freedesktop.org/dist/libxcb-1.13.tar.gz"
 
-    version('1.12', '95eee7c28798e16ba5443f188b27a476')
-    version('1.11', '1698dd837d7e6e94d029dbe8b3a82deb')
+    version('1.13',   '3ba7fe0a7d60650bfb73fbf623aa57cc')
+    version('1.12',   '95eee7c28798e16ba5443f188b27a476')
     version('1.11.1', '118623c15a96b08622603a71d8789bf3')
+    version('1.11',   '1698dd837d7e6e94d029dbe8b3a82deb')
 
     depends_on('libpthread-stubs')
     depends_on('libxau@0.99.2:')
     depends_on('libxdmcp')
 
+    # libxcb 1.X requires xcb-proto >= 1.X
     depends_on('xcb-proto', type='build')
+    depends_on('xcb-proto@1.13:', when='@1.13:1.13.999', type='build')
+    depends_on('xcb-proto@1.12:', when='@1.12:1.12.999', type='build')
+    depends_on('xcb-proto@1.11:', when='@1.11:1.11.999', type='build')
+
     # TODO: uncomment once build deps can be resolved separately
-    # depends_on('python@2:2.8', type='build')
+    # See #7646, #4145, #4063, and #2548 for details
+    # libxcb 1.13 added Python 3 support
+    # depends_on('python', type='build')
+    # depends_on('python@2:2.8', when='@:1.12', type='build')
+
     depends_on('pkgconfig', type='build')
     depends_on('util-macros', type='build')
 
diff --git a/var/spack/repos/builtin/packages/xcb-proto/package.py b/var/spack/repos/builtin/packages/xcb-proto/package.py
--- a/var/spack/repos/builtin/packages/xcb-proto/package.py
+++ b/var/spack/repos/builtin/packages/xcb-proto/package.py
@@ -30,12 +30,14 @@ class XcbProto(AutotoolsPackage):
     generate the majority of its code and API."""
 
     homepage = "http://xcb.freedesktop.org/"
-    url      = "http://xcb.freedesktop.org/dist/xcb-proto-1.11.tar.gz"
+    url      = "http://xcb.freedesktop.org/dist/xcb-proto-1.13.tar.gz"
 
+    version('1.13', '0cc0294eb97e4af3a743e470e6a9d910')
     version('1.12', '5ee1ec124ea8d56bd9e83b8e9e0b84c4')
     version('1.11', 'c8c6cb72c84f58270f4db1f39607f66a')
 
     # TODO: uncomment once build deps can be resolved separately
+    # See #7646, #4145, #4063, and #2548 for details
     # extends('python')
 
     patch('xcb-proto-1.12-schema-1.patch', when='@1.12')


Test patch:
Repository: spack/spack

Issue:
Must activating an activated package be an error?
I have a script that I run that installs all of the things that I want.  With a bit of care (e.g. not re-adding compilers) it's safe to re-run it.  My normal MO is to just add new packages to the list and fire it up, things that are already built are simply skipped over.

Now that `aspell6-en` is an extension of `aspell` I activate it as part of the script.  If I re-run the script it fails when it tries to activate it a second time:

```
-bash-4.2$ bin/spack-install.sh
==> aspell6-en is already installed in /home/hartzell/spack/opt/spack/linux-centos7-x86_64/gcc-5.5.0/aspell6-en-2017.01.22-0-2dh6xidgk2ucjcs32uc3t7pak34kl5sy
==> Error: Package aspell6-en/lc4v24f is already activated.
```

I'd like a way to 

- activate a package without causing an error if it's already activated;
- ask is a package is activated so that I can avoid reactivating it; or
- some other mechanism to have a script run idempotently.




Discussion:

Resolving patch:
diff --git a/lib/spack/spack/package.py b/lib/spack/spack/package.py
--- a/lib/spack/spack/package.py
+++ b/lib/spack/spack/package.py
@@ -949,7 +949,10 @@ def provides(self, vpkg_name):
         """
         True if this package provides a virtual package with the specified name
         """
-        return any(s.name == vpkg_name for s in self.provided)
+        return any(
+            any(self.spec.satisfies(c) for c in constraints)
+            for s, constraints in self.provided.items() if s.name == vpkg_name
+        )
 
     @property
     def installed(self):


Test patch:
diff --git a/lib/spack/spack/test/concretize.py b/lib/spack/spack/test/concretize.py
--- a/lib/spack/spack/test/concretize.py
+++ b/lib/spack/spack/test/concretize.py
@@ -515,3 +515,12 @@ def test_regression_issue_7239(self):
         # Mimics asking the build interface from a build interface
         build_interface = s['mpileaks']['mpileaks']
         assert llnl.util.lang.ObjectWrapper in type(build_interface).__mro__
+
+    @pytest.mark.regression('7705')
+    def test_regression_issue_7705(self):
+        # spec.package.provides(name) doesn't account for conditional
+        # constraints in the concretized spec
+        s = Spec('simple-inheritance~openblas')
+        s.concretize()
+
+        assert not s.package.provides('lapack')
Repository: spack/spack

Issue:
Don't Build Docs by Default!
In general... Spack packages should not build documentation unless asked to do so (eg. with a `+docs` variant).  Reasons:
1. Building docs can involve large/annoying dependencies (`doxygen`, `latex`, etc.)
2. Users don't usually want docs except for packages near the top of the DAG for a particular user's needs.  CGAL might be a great and clever system; but people installing stuff five levels up just don't care.
3. Even if a packages is close to the top, users often just rely on on-line docs anyway.

I'm guilty of not following this advice (need to fix for `glint2` and `icebin` packages).



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/flux/package.py b/var/spack/repos/builtin/packages/flux/package.py
--- a/var/spack/repos/builtin/packages/flux/package.py
+++ b/var/spack/repos/builtin/packages/flux/package.py
@@ -36,7 +36,7 @@ class Flux(AutotoolsPackage):
     version('master', branch='master',
             git='https://github.com/flux-framework/flux-core')
 
-    variant('doc', default=True, description='Build flux manpages')
+    variant('doc', default=False, description='Build flux manpages')
 
     depends_on("zeromq@4.0.4:")
     depends_on("czmq@2.2:")


Test patch:
Repository: spack/spack

Issue:
Must activating an activated package be an error?
I have a script that I run that installs all of the things that I want.  With a bit of care (e.g. not re-adding compilers) it's safe to re-run it.  My normal MO is to just add new packages to the list and fire it up, things that are already built are simply skipped over.

Now that `aspell6-en` is an extension of `aspell` I activate it as part of the script.  If I re-run the script it fails when it tries to activate it a second time:

```
-bash-4.2$ bin/spack-install.sh
==> aspell6-en is already installed in /home/hartzell/spack/opt/spack/linux-centos7-x86_64/gcc-5.5.0/aspell6-en-2017.01.22-0-2dh6xidgk2ucjcs32uc3t7pak34kl5sy
==> Error: Package aspell6-en/lc4v24f is already activated.
```

I'd like a way to 

- activate a package without causing an error if it's already activated;
- ask is a package is activated so that I can avoid reactivating it; or
- some other mechanism to have a script run idempotently.




Discussion:
I'd vote for a "I know what I'm doing be quiet `spack`" flag rather than removing the error. It's likely that activating an already activated package isn't what the user intended to do.

But in general it might be useful to implement a more interactive mode of spack, i.e. instead of failing on an exception ask the user whether she wants to ignore it.

edit: @hartzell `-f` sometimes suppresses errors like this, did you try `spack activate -f aspell-en`?

I'd vote for removing the error altogether. This is in line with how `spack install` works. Like @hartzell, I frequently wrote scripts that would loop through a set of packages and `install` + `activate` all of them.

We should still have some output of course. Something like "foo is already activated", just like the current "foo is already installed" message. But it shouldn't have an exit code of 1.
@healther -- `-f` doesn't help:

```
-bash-4.2$ ~/spack/bin/spack activate aspell6-en
==> Error: Package aspell6-en/lc4v24f is already activated.
-bash-4.2$ ~/spack/bin/spack activate -f aspell6-en
==> Error: Package aspell6-en/lc4v24f is already activated.
-bash-4.2$ echo $?
1
```

Resolving patch:
diff --git a/lib/spack/spack/cmd/activate.py b/lib/spack/spack/cmd/activate.py
--- a/lib/spack/spack/cmd/activate.py
+++ b/lib/spack/spack/cmd/activate.py
@@ -59,7 +59,8 @@ def activate(parser, args):
         layout = YamlViewExtensionsLayout(args.view, spack.store.layout)
 
     if spec.package.is_activated(extensions_layout=layout):
-        tty.die("Package %s is already activated." % specs[0].short_spec)
+        tty.msg("Package %s is already activated." % specs[0].short_spec)
+        return
 
     spec.package.do_activate(extensions_layout=layout,
                              with_dependencies=not args.force)


Test patch:
Repository: spack/spack

Issue:
Default font of white for spack stdout messages a bit hard to read on a white background



Discussion:
This is fixed by 73774c1.  Message text is now just bold instead of bold white.


Resolving patch:
diff --git a/var/spack/repos/builtin/packages/r-htmltable/package.py b/var/spack/repos/builtin/packages/r-htmltable/package.py
--- a/var/spack/repos/builtin/packages/r-htmltable/package.py
+++ b/var/spack/repos/builtin/packages/r-htmltable/package.py
@@ -35,13 +35,15 @@ class RHtmltable(RPackage):
     compatible with HTML/'LaTeX'."""
 
     homepage = "https://CRAN.R-project.org/package=htmlTable"
-    url      = "https://cran.rstudio.com/src/contrib/htmlTable_1.9.tar.gz"
+    url      = "https://cran.rstudio.com/src/contrib/htmlTable_1.11.2.tar.gz"
     list_url = "https://cran.r-project.org/src/contrib/Archive/htmlTable"
 
+    version('1.11.2', '473e6d486e7714f8dd7f16a31480c896')
     version('1.9', '08c62c19e1ffe570e7d8fa57db5094b9')
 
     depends_on('r-stringr', type=('build', 'run'))
-    depends_on('r-knitr', type=('build', 'run'))
-    depends_on('r-magrittr', type=('build', 'run'))
+    depends_on('r-knitr@1.6:', type=('build', 'run'))
+    depends_on('r-magrittr@1.5:', type=('build', 'run'))
     depends_on('r-checkmate', type=('build', 'run'))
     depends_on('r-htmlwidgets', type=('build', 'run'))
+    depends_on('r-rstudioapi@0.6:', type=('build', 'run'), when="@1.11.0:")


Test patch:
Repository: spack/spack

Issue:
spack info can't handle URLs containing @ symbol
```console
$ spack info bcl2fastq2
Package:   bcl2fastq2

Description:
    The bcl2fastq2 Conversion Software converts base call (BCL) files from a
    sequencing run into FASTQ files.

Homepage: https://support.illumina.com/downloads/bcl2fastq-conversion-software-v2-18.html

Tags: 
    None

Preferred version:  
==> Error: invalid color specifier: 'u' in '@c    2.19.1.403    @.ftp://webdata2:webdata2@ussd-ftp.illumina.com/downloads/software/bcl2fastq/bcl2fastq2-v2.19.1-tar.zip
'
```
It looks like we need to wrap existing `@`'s with a double `@@`.


Discussion:
Found another interesting example:
```console
$ spack info mpix-launch-swift
Package:   mpix-launch-swift

Description:
    Library that allows a child MPI application to be launched inside a
    subset of processes in a parent MPI application.

Homepage: https://bitbucket.org/kshitijvmehta/mpix_launch_swift

Tags: 
    None

Preferred version:  
    develop    [git] https://kshitijvmehtaitbucket.org/kshitijvmehta/mpix_launch_swift.git

Safe versions:  
    develop    [git] https://kshitijvmehtaitbucket.org/kshitijvmehta/mpix_launch_swift.git

Variants:
    None

Installation Phases:
    install

Build Dependencies:
    mpi  stc  swig  tcl

Link Dependencies:
    mpi  stc  tcl

Run Dependencies:
    None

Virtual Packages: 
    None
```
The URL here is:
https://kshitijvmehta@bitbucket.org/kshitijvmehta/mpix_launch_swift.git

Since `@b` is an actual color code (blue) it strips out the b and highlights the rest of the line in blue.

Resolving patch:
diff --git a/lib/spack/spack/cmd/info.py b/lib/spack/spack/cmd/info.py
--- a/lib/spack/spack/cmd/info.py
+++ b/lib/spack/spack/cmd/info.py
@@ -156,7 +156,7 @@ def print_text_info(pkg):
     color.cprint('')
     color.cprint(section_title('Description:'))
     if pkg.__doc__:
-        color.cprint(pkg.format_doc(indent=4))
+        color.cprint(color.cescape(pkg.format_doc(indent=4)))
     else:
         color.cprint("    None")
 
@@ -195,14 +195,14 @@ def print_text_info(pkg):
         preferred = sorted(pkg.versions, key=key_fn).pop()
 
         f = fs.for_package_version(pkg, preferred)
-        line = version('    {0}'.format(pad(preferred))) + str(f)
+        line = version('    {0}'.format(pad(preferred))) + color.cescape(f)
         color.cprint(line)
         color.cprint('')
         color.cprint(section_title('Safe versions:  '))
 
         for v in reversed(sorted(pkg.versions)):
             f = fs.for_package_version(pkg, v)
-            line = version('    {0}'.format(pad(v))) + str(f)
+            line = version('    {0}'.format(pad(v))) + color.cescape(f)
             color.cprint(line)
 
     color.cprint('')


Test patch: