linux-32 package in linux-64 channel

[Bezier89]

https://repo.continuum.io/pkgs/free/linux-64/gsl-2.1-1.tar.bz2

The repodata (under info/index.json) for this package is as follows:

{
  "arch": "x86",
  "build": "1",
  "build_number": 1,
  "depends": [
    "libgcc"
  ],
  "license": "GPL 3",
  "name": "gsl",
  "platform": "linux",
  "subdir": "linux-32",
  "version": "2.1"
}

Note the subdir. This is a linux-32 package in the linux-64 channel.

[msarahan]

Thanks for reporting. We will investigate how this happened.

[Bezier89]

@msarahan more bad packages:

https://repo.continuum.io/pkgs/free/win-32/nsis-3.01-4.tar.bz2 { "arch": "x86_64", "build": "4", "build_number": 4, "depends": [], "license": "Common public License Version 1.0, zlib", "license_family": "Other", "name": "nsis", "platform": "win", "subdir": "win-64", "version": "3.01" }

https://repo.continuum.io/pkgs/free/win-64/conda-build-2.0.7-py27_0.tar.bz2 { "arch": "x86", "build": "py27_0", "build_number": 0, "depends": [ "conda >=4.1", "filelock", "jinja2", "pkginfo", "pycrypto", "python 2.7*", "pyyaml" ], "license": "BSD 3-clause", "name": "conda-build", "platform": "win", "subdir": "win-32", "version": "2.0.7" }

https://repo.continuum.io/pkgs/free/win-64/conda-build-2.0.7-py34_0.tar.bz2 { "arch": "x86", "build": "py34_0", "build_number": 0, "depends": [ "conda >=4.1", "filelock", "jinja2", "pkginfo", "pycrypto", "python 3.4*", "pyyaml" ], "license": "BSD 3-clause", "name": "conda-build", "platform": "win", "subdir": "win-32", "version": "2.0.7" }

https://repo.continuum.io/pkgs/free/win-64/conda-build-2.0.7-py35_0.tar.bz2 { "arch": "x86", "build": "py35_0", "build_number": 0, "depends": [ "conda >=4.1", "filelock", "jinja2", "pkginfo", "pycrypto", "python 3.5*", "pyyaml" ], "license": "BSD 3-clause", "name": "conda-build", "platform": "win", "subdir": "win-32", "version": "2.0.7" }

https://repo.continuum.io/pkgs/free/win-64/pandoc-1.15.2-0.tar.bz2 { "arch": "x86", "build": "0", "build_number": 0, "depends": [], "license": "GPL", "license_family": "GPL2", "name": "pandoc", "platform": "win", "subdir": "win-32", "version": "1.15.2" }

https://repo.continuum.io/pkgs/free/win-64/patch-2.5-0.tar.bz2 { "arch": "x86", "build": "0", "build_number": 0, "depends": [], "license": "GNU2", "name": "patch", "platform": "win", "requires": [], "subdir": "win-32", "version": "2.5" }

https://repo.continuum.io/pkgs/free/win-64/pydot-ng-1.0.0.15-py27_0.tar.bz2 { "arch": "x86", "build": "py27_0", "build_number": 0, "depends": [ "pyparsing", "python 2.7*" ], "license": "MIT", "name": "pydot-ng", "platform": "win", "subdir": "win-32", "version": "1.0.0.15" }

https://repo.continuum.io/pkgs/free/win-64/pydot-ng-1.0.0.15-py34_0.tar.bz2 { "arch": "x86", "build": "py34_0", "build_number": 0, "depends": [ "pyparsing", "python 3.4*" ], "license": "MIT", "name": "pydot-ng", "platform": "win", "subdir": "win-32", "version": "1.0.0.15" }

[mingwandroid]

Some of these are not bugs.

pandoc for example only releases 32-bit Windows builds and since we do not build it from source we have no alternative.

[mingwandroid]

patch and nsis are in this same category.

[msarahan]

I think they are bugs, though. Even if the software's contents are win-32, conda still needs to see them as win-64, right? These are metadata hotfixes that we need to make.

@Bezier89 the thing you may not have in mind is that the "free" channel is deprecated and left for legacy usage only. We only update things on the new "main" channel. The fix we'd apply here would be to apply a metadata hotfix, and to add these packages to our queue of things to rebuild for the main channel, if they are not already there.

[mingwandroid]

I think they are bugs, though

Yes, from some perspectives, but the point is that, even when running on a 64-bit installation, we need this 32-bit software to be installed, and if the metadata were to be corrected the solver would say "no".

[msarahan]

no, I think right now, the solver will be very confused (or maybe not, depending on if that subdir value is actually used, or if it's enough that the file is simply present in the index). Conda doesn't know about the actual bit-ness within the packages. That's our constant here. We need to fix the metadata so that conda's notion of subdir in the metadata is consistent with the index (and actual subdir folder) that it's present in.

[mingwandroid]

ok, I would caution treading carefully though as these packages are currently 'working' by an important definition of the word and any change to them risks breaking that (and those would need to be checked against a range of conda versions too).

[Bezier89]

And the last of them:

https://repo.continuum.io/pkgs/free/win-64/swig-3.0.8-0.tar.bz2 { "arch": "x86", "build": "0", "build_number": 0, "depends": [], "license": "GPL3", "name": "swig", "platform": "win", "requires": [], "subdir": "win-32", "version": "3.0.8" }

https://repo.continuum.io/pkgs/free/win-64/swig-3.0.8-1.tar.bz2 { "arch": "x86", "build": "1", "build_number": 1, "depends": [], "license": "GPLv3", "name": "swig", "platform": "win", "subdir": "win-32", "version": "3.0.8" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.0-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.0" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.1-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.1" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.11-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.11" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.12-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.12" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.15-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.15" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.2-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.2" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.3-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.3" }

https://repo.continuum.io/pkgs/free/noarch/continuum-docs-2.0.4-0.tar.bz2 { "arch": "x86_64", "build": "0", "build_number": 0, "depends": [], "name": "continuum-docs", "platform": "osx", "subdir": "osx-64", "version": "2.0.4" }

I agree with @mingwandroid though, that trying to "fix" these packages may cause unforeseen problems. I mostly wanted to bring it up in case it was indicative of something systemic, but since you say the "free" channel is deprecated, there's probably nothing to do here.

[msarahan]

Great! I'm in favor of leaving this issue open, but not acting on it unless someone reports an issue. We'll probably rebuild these packages in the main channel if we haven't already, and no one will notice these mess-ups.

Thanks again for reporting @Bezier89