MiKTeX and proTeXt ⇒ "Not a valid remote package repository" Error

[craigim]

I installed MikTeX 2.7 on my new computer (XP SP3) a couple weeks ago, and transferred my LaTeX documents over from my old laptop. I tried to build my thesis, which uses about 20 packages. Whenever MikTeX tries to install one of the packages, I get a "Not a valid remote package repository" error. I went to the package manager and tried to install the packages manually, but I get the same error there, too. I tried every package repository in the US plus one in Mexico and was getting the same error each time until the MikTeX server decided I was asking too many questions and blocked my IP address. I also tried synchronizing, but to no avail.

When 2.8 was released, I installed it and tried to compile and got the same errors.

Because my IP was blocked, I took my laptop to school and tried to install a package there, and got the same error. So I'm pretty confident that it is not my setup, but I can't find anything about the repositories all being down, and it seems unlikely that they would be down right after the release of a major upgrade.

Just in case it's useful, here is the error output that I got when I tried to install the xcolor package just now.

Code: Select all

MiKTeX Problem Report
Message: Not a valid remote package repository.
Data: http://mirrors.med.harvard.edu/ctan/systems/win32/miktex/tm/packages/
Source: C:\work3\miktex-2.8\Libraries\MiKTeX\PackageManager\PackageManager.cpp
Line: 2368
MiKTeX: 2.8
OS: Microsoft Windows XP Professional Service Pack 3 (build 2600)
SystemAdmin: yes
PowerUser: no
Root0: C:\Documents and Settings\craigim\Application Data\MiKTeX\2.8
Root1: C:\Documents and Settings\craigim\Local Settings\Application Data\MiKTeX\2.8
Root2: C:\Documents and Settings\All Users\Application Data\MiKTeX\2.8
Root3: C:\Program Files\MiKTeX 2.8
UserInstall: C:\Documents and Settings\craigim\Application Data\MiKTeX\2.8
UserConfig: C:\Documents and Settings\craigim\Application Data\MiKTeX\2.8
UserData: C:\Documents and Settings\craigim\Local Settings\Application Data\MiKTeX\2.8
CommonInstall: C:\Program Files\MiKTeX 2.8
CommonConfig: C:\Documents and Settings\All Users\Application Data\MiKTeX\2.8
CommonData: C:\Documents and Settings\All Users\Application Data\MiKTeX\2.8

Anyone have any suggestions?

[lalop]

I get the same error. I was able to switch repositories this morning to correct it, but now they all seem to be "invalid". More precisely:

Code: Select all

MiKTeX Problem Report
Message: Not a valid remote package repository.
Data: http://ftp.math.purdue.edu/mirrors/ctan.org/systems/win32/miktex/tm/packages/
Source: C:\work3\miktex-2.7\Libraries\MiKTeX\PackageManager\PackageManager.cpp
Line: 2170
MiKTeX: 2.7
OS: Microsoft Windows Vista Business Edition, 64-bit Service Pack 1 (build 6001)
SystemAdmin: yes
PowerUser: no
SharedSetup: yes
BinDir: C:\Program Files (x86)\MiKTeX 2.7\miktex\bin
Root0: C:\Users\myname\AppData\Roaming\MiKTeX\2.7
Root1: C:\Users\myname\AppData\Local\MiKTeX\2.7
Root2: C:\ProgramData\MiKTeX\2.7
Root3: C:\Program Files (x86)\MiKTeX 2.7
Install: C:\Program Files (x86)\MiKTeX 2.7
UserConfig: C:\Users\myname\AppData\Roaming\MiKTeX\2.7
UserData: C:\Users\myname\AppData\Local\MiKTeX\2.7
CommonConfig: C:\ProgramData\MiKTeX\2.7
CommonData: C:\ProgramData\MiKTeX\2.7

[localghost]

Make sure that the chosen MiKTeX Repositories are intact. Generally you should choose a repository in your country or at least the nearest one.


Best regards
Thorsten

[lalop]

I just tried some of the intact ones on that list. Same problem.

When I don't run it as administrator and enable it later instead, the error comes up as "Cannot start package manager". Perhaps that helps.

[lalop]

Btw, I can navigate via web browser to the repository's url just fine, they look like giant lists of links and I can download files from it. Miktex just doesn't recognize it as a repository for some reason.

[localghost]

That's annoying and I don't know what to advice. But I may describe how I handle my MiKTeX system (in the rare cases I run Windows). In the past it caused me less trouble.

I always use the MiKTeX Net Installer to download the whole system into a directory of my general software partition. Afterwards I choose this directory as a local repository in the Package Manager. This directory also serves as repository when updating the system. Thus I'm not always dependent on an intact remote repository (though there are quite a lot in my country). This is extremely useful when I use a package in a document that has to be installed subsequently to make the document work. Another advantage is that this subsequent installation is much faster from a local than from a remote repository. Updating this local repository works very easy by starting the Net Installer and choosing the complete download again. The installer loads the current database from the server, compares it with the available package versions and downloads only packages that are new or in updated version on the server.

At the moment this won't help you, but maybe in the future. But this way you always have the complete system on your local machine. The current MikTeX 2.8 system has about 1800 files and occupies about 720MB on the disk.

[craigim]

It must have been a server issue, because all of a sudden, today I can install packages. I didn't change anything, I didn't do anything different, I just gave it "one more try" and the package I previously tried to install and failed, worked (in fact, it was the same package and repository that gave me the error in my message above).

Maybe, while it's working, I'll try downloading all the packages as you suggest. Memory is cheap.

[lalop]

It appears to be working for me as well, which is confounding but I guess ultimately okay.

A complete repository might be good for the enthusiast, but having people download 700mb is not exactly the way to draw new people in. I'd prefer to be able to avoid these "on the fly" errors if possible, because I'm vaguely about drawing other people in as well.

[localghost]

[...] A complete repository might be good for the enthusiast, but having people download 700mb is not exactly the way to draw new people in. I'd prefer to be able to avoid these "on the fly" errors if possible, because I'm vaguely about drawing other people in as well.

I think it's less about enthusiasm but more about pragmatism. Of course you have the freedom of choice. Finally I only made a suggestion and you are not forced to follow it.