I've installed bugzilla Win32InstallPackages
https://wiki.mozilla.org/Bugzilla:Win32InstallPackages
its pretty easy, just download Bugzilla-Setup-3.4.8.exe file, follow steps and keep pressing Next button. It installs everything (Apache, MySql, Perl, Bugzilla) and works perfect. Just start using bugzilla through this url localhost
Now I want to upgrade this with some stable latest release which is 4.4. I am using Bazaar repository to download at my local PC from here http://bzr.mozilla.org/bugzilla/4.4/
Bazaar explorer creates trunk folder inside C:\Bugzilla\trunk and downloaded all source code inside the trunk directory.
When I've copied all the files from trunk folder and replaced with existing files at C:\Bugzilla\ then it doesn't work.
Now I am getting following error message when I am trying to open bugzilla by writing localhost/ into address bar.
500 Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, admin#example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Could you please help me how to upgrade bugzilla on my local machine ?
There are upgrade instructions that can be followed. Also check your apache logs to find out what the 500 error is really about.
Related
I have been using the TFS plugin for eclipse with my companies TFS server for several months. Last week, my laptop crashed while eclipse was open and a connection to the TFS was present. Now, every time I launch eclipse, I get an error stating a connection could not be made to the server, throwing a NullPointerException.
To try to fix this, I cleaned eclipse from my system and removed the installed plugin and then reinstalled eclipse and the TFS plugin. Now, I am no longer getting this connection error on launch. I added the original TFS to the list of servers in eclipse and it can see all of the projects (see http://i.imgur.com/SbgyuRx.png).
However, trying to use any of the projects leads to a screen with an error message saying Error querying workspaces: null. The error log shows the plugin in question as com.microsot.tfs.client.common, with the stack trace saying An exception stack trace is not available.
I am using the same exact plugin installation that I originally used. I have no idea why I'm getting these errors.
The error logs may be helpful. You can view them by going to Help > Team Explorer Everywhere Support, then clicking on the Logs tab.
Ultimately, though, this is probably some corrupt configuration files. TEE performs some various background tasks and I suspect one of those was interrupted in the middle of some file I/O when your computer crashed. Deleting the cache directory may be helpful:
~/.microsoft/Team Foundation
When you restart Eclipse, you should get a dialog box that indicates that your TFS server information cannot be located, but when you reconnect to that TFS server, your projects should return to being TFS managed.
So I have been banging my head against the wall for days on this one. When I initially set up Subclipse and first connected to my local SVN repo, everything worked great. Not sure what's changed since then, but now I keep getting errors when trying to access the repo.
In SVN Repository Exploring perspective, if I double-click on my repo I get a popup that says "Problem Occured - Folder " does not exist remotely". In my console, I get this error:
Connection refused
svn: Unable to connect to a repository at URL 'svn://userid#localhost/home/userid/myrepository/java'
svn: Can't connect to host 'localhost': Connection refused
I have:
Eclipse Juno
Ubuntu 12.04
Subversion 1.7.8
I initially started off with Subclipse 1.6 and JavaHL 1.6 but have since upgraded to Subclipse 1.8.3/JavaHL 1.7.8.1 in my efforts to get everything working again.
I even uninstalled Eclipse and reinstalled, re-installed Subclipse and JavaHL, adding the JavaHL path to eclpise.ini... still can't access the repo.
I was accessing the repo locally in subclipse via "svn://userid#localhost/svn/home/userid/myrepository/java". I can access this repo locally from the command line just fine, and I can access this repo from another machine on my network using svn+ssh just fine.
What am I missing?
If the repository is local, you should be using a URL like file:///home/userID/myrepository/java
To use the svn:// protocol you must have svnserve running. The URL would then be something like:
svn://localhost/myrepository/java
When you use the svn+ssh:// protocol, the SSH daemon starts and launches svnserve in --tunnel mode within the SSH session. So it does not need or use a normal svnserve daemon server that may be running.
FWIW, it would probably be a good idea to run svnserve, but that means you will also need to configure it. But I would not use file:// URL using SVNKit. If you use JavaHL exclusively, then it is fine, but I would not let SVNKit write directly to my repository. Even though they do a great job testing and maintaining compatibility it is just easier to run svnserve and let SVNKit talk to it via the protocol.
I'm following the instructions for installing Ardor3D as an Eclipse Project Set via Subclipse; instructions at:
http://www.ardor3d.com/wiki/svneclipsetutorial
I installed Subclipse from
http://subclipse.tigris.org/
and installed fine. If I go to Eclipse's Preferences and Team|SVN I can see that the SVN Interface Client is JavaHL, and hence installed fine.
However, when I come to checkout the code at:
http://ardorlabs.svn.cvsdude.com/Ardor3Dv1
by selecting New|Other|SVN|Check Projects from SVN I get the following error message:
RA layer request failed
svn: Unable to connect to a repository at URL 'http://ardorlabs.svn.cvsdude.com/Ardor3Dv1'
svn: OPTIONS of 'http://ardorlabs.svn.cvsdude.com/Ardor3Dv1': could not connect to server (http://ardorlabs.svn.cvsdude.com)
I know the URL is valid as I can install the above fine on my work m/c of WinXP. However, the same installation on my personal laptop of Win7 fails to connect.
I tried temporarily disabling the firewall and it still fails.
I've tried playing around with the config and server files in:
C:\Documents and Settings\Administrator\Application Data\Subversion
but to be honest not 100% sure as what to change, if anything as I'm not using proxy settings.
If there's an expert out there who's knows the solution to this problem I would greatly appreciate hearing from you.
Thanks
Graham
PS. I find the error message "RA layer request failed" confusing as the URL is valid.
I had exactly the same problem, which turned out to be caused by a proxy server. The solution to my problem was to configure subversion to work with the proxy server, however it was not obvious how to do this.
You should have a directory similar to : C:\Documents and Settings\UserName\Application Data\Subversion
In that directory there will be a file called servers.
I un-commented and edited the following entries and my subversion is now working fine with Eclipse:
http-proxy-host
http-proxy-port
http-proxy-username
http-proxy-password
Why exactly you can't configure this through Eclipse is abit of a mystery, but there you go.
Another user account could login, I got the error as described above. The difference was the Proxy setting which was missing in my account. It is stored per user in the Registry and I could easily change this in the Tortoise SVN config.
We encountered this error with our server. While we were able to successfully access the CollabNet 5 SVN admin console, navigating to the repository to browse it from the admin console would fail. We also were not able to connect from Subclipse clients.
The problem turned out we were not hitting the correct port on the server. We had reconfigured the default port from 80 to 4343 and the admin console reported the changed setting but the server was still running on 80.
For what it's worth, in order for the configuration change to stick, we had to bring the repo server down and make the change in the admin console and then restart the machine. We were then able to browse the repo from the link in the admin console.
I have a strange problem. I have set up a Mercurial server using the hgweb.cgi script. The script runs in a subfolder on my Apache webserver, and I use Apache basicauth to enforce authentication.
When I try to pull from my server using hg.exe on Windows, command line, it works fine. Also the push, incoming and outgoing commands are working. In Aptana, pushing and pulling also works fine.
Next step for me was to set up Mercurial in Netbeans. I cannot get it to work because I cannot authenticate. Netbeans keeps asking me for the un/pw combination. The attached window keeps popping up. No matter what I do, in the end I have to click the 'Cancel' button and I end up with an error:
Mercurial Pull
--------------
INFO Pulling From: http://user:****#server.nl:8080/hg/kate ...
ERROR Command failed:
Command: [hg, incoming, -v, --bundle, C:\wamp\www\Thorium\Kate_bundle0, --repository, C:\wamp\www\Thorium\Kate, http://user:****#server.nl:8080/hg/kate]
Output: [abort: http authorization required]
INFO: End of Mercurial Pull
Link to the error message
After hours of searching for the solutions... I finally got it to work. For everybody else who experiences this problem: an update of the TortoiseHG mercurial client fixed my problems! Apperently, Netbeans 7.0.1 and TortoiseHG 2.1.2 are not compatible. Updating to TortoiseHG 2.1.4 did the trick.
When using a local NuGet server, whenever I try to install an individual package from that server, all I get is this error: "The remote server returned an error: (404) Not Found."
The packages are all there in the filesystem and the feed itself sees all the packages appropriately. I can even browse the package directly!
What am I missing?
I did just upgrade from NuGet server 1.4 to 1.5, but I've seen this happen before. Touching the package files used to help, but that does not appear to be the case now.
EDIT: Actually, I hadn't seen that exact error before...I've seen this one, intermittently, that touching the package tended to fix.
On Windows Server 2008, I was having the same issue. I switched the Application Pool from "ASP.NET v4.0 Classic" to "ASP.NET v4.0". The install-package command worked fine after the change.
sigh...
http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx
EDIT: In case the link ever dies...I am hosting my NuGet server in IIS6, which wasn't set up to properly handle extensionless URLs. And since the semantics of downloading individual packages changed from a direct file link to an extensionless route, I started getting 404s. Adding the wildcard mapping described in the article fixed it instantly.
I've been trying to figure this for a couple of hours...
Checked the IIS logs and discovered that URLScan was blocking the route:
GET /Rejected-By-UrlScan ~/api/v2/package/
URLScan doesn't accept any route not starting with '/'. The best I could do was to remove the URLScan from the list of ISAPI filters for the website in the IIS Manager.
I was having the same issue on Windows Server 2008.
Problem was in my own package MyPackage.nupkg that I saved without version.
MyPackage was visible in PackageManager but it was getting 404 error on install.
Fix:
I saved it with name MyPackage.1.0.0.nupkg (1.0.0 is current version) and problem was fixed.
I had the same problem, srv 2008 R2. Changed the application pool to Integrated from Classic and all works fine now.
My problem was same as image above. I could go to the site on url
http://localhost:3407/nuget/Packages
but not
http://localhost:3407/api/v2/package/{package name}/1.0.0.0
I encountered this error while trying to download Signal-R after update Nuget, however it was just that I had not checked the "Allow Nuget to download missing packages during build" option in package manager settings. Once that was that set it all worked fine again.
It could be this as well -
You are trying to refer to a url like : http://yourdomain/application/nuget/packages
Then you should change it to :
http://yourdomain/application/nuget
This is a common mistake.