I am trying to install Bugzilla. For that Strawberry perl, Microsoft IIS, MySQL are installed with latest versions. Followed guidelines given on Bugzilla installation page for windows.
Whenever I run checksetup.pl, all necessary perl modules related to Bugzilla are installed correctly. Only three optional modules were not installed (perl-ldap, mod_perl and Apache-SizeLimit). And then it is showing an error:
Undefined subroutine utf8::SWASHNEW called at Bugzilla/Util.pm line 109.
Move back to Strawberry Perl 5.28.2.1 from 5.30.0.1
I had same problem. This fixed.
I managed to fix this by applying the first of the following patch
(use
locate Safe.pm
to find the offending file)
DISCLAIMER - AT YOUR OWN RISK
Perl on github, patch for bug 17291
Related
I am new to programmer world so i want to learn so many things, and about what i want to ask, can i install orafce in postgresql? I mean all the tutorial always show use BigSql but iam using from enterprise DB. I am already try take orafce.dll from bigsql but it can't read because not specified procedure.
ERROR: could not load library "C:/Program Files/PostgreSQL/9.5/lib/orafce.dll": The specified procedure could not be found.
and i already try from other source but still got some error
ERROR: could not find function "plvlex_tokens" in file "C:/Program Files/PostgreSQL/9.5/lib/orafce.dll"
It was a bug in Orafce windows build. Should be fixed by last build.
The simple directions found all over the internet for installing Core using OPAM no longer work. What is the new way to install and use Core?
I think I tracked the problem down to a message on the ocaml-core mailing list about renaming several dependencies https://groups.google.com/forum/#!topic/ocaml-core/Te6LTiNBO08.
Paired down, the widely published installation instructions amount to two steps after installing opam itself:
$ opam install core
$ cat >> ~/.ocamlinit <<EOF
#use "topfind";;
#thread;;
#camlp4o;;
#require "core.top";;
#require "core.syntax";;
EOF
Following these directions result in an error about the "sexprlib.syntax" package missing when using ocaml (or corebuild, utop, etc).
Failing directions can be found in this widely referenced ebook
https://github.com/realworldocaml/book/wiki/Installation-Instructions#setting-up-and-using-utop
and are reflected in directions here on Stackoverflow in questions such as:
Ocaml utop library paths, Core module
What is the new way to set up Core?
opam install core no longer seems to be sufficient since it does not pull in the new syntax packages. I am not sure if this is a dependency bug or not.
The recommended ocamlinit settings also seem wrong.
I found that the core 113.24.00 is defective and all the installation instructions on the net as of this writing are out of date.
Users must make the following corrective steps:
Remove all #require references to packages ending in .syntax from ~/.ocamlinit.
Make your own corebuild script without any references to syntax packages
as found at https://github.com/janestreet/core/blob/master/corebuild.
You may also remove the #camlp4o;; line from your .ocamlinit as this library is no longer required by Core.
I am trying to run pyramid application on google's app engine using buildout. I followed this link gae_buildout and got struck while running the buildout. Its shows "setuptools not found error" despite of seetuptools being installed in the virtual environment. I tried few work arounds and nothing turned fruitful, any thoughts on this ?
Find the error trace below. I am using pyramid 1.4 version.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 1942, in main
getattr(buildout, command)(args)
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 622, in install
installed_files = self[part]._call(recipe.install)
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 1366, in _call
return f()
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 377, in install
self.copy_packages(ws, temp_dir)
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 284, in copy_packages
self.write_pkg_resources(ws, lib)
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 267, in write_pkg_resources
assert len(setuptools_eggs) == 1, "setuptools not found"
AssertionError: setuptools not found
Got the same (Ubuntu 12.04) and finally solved the problem by changing ae-sdk-version to 1.8.0 from buildout.cfg
Open buildout.cfg and change the line:
ae-sdk-version=1.7.5
to:
ae-sdk-version=1.8.0
...or the latest one from here. Now seems to be 1.8.5, but 1.8.0 worked for me.
The problem in fact comes because PyPI is not serving last version of pyramid_appengine. It's serving 0.8.1 and should be (latest) 0.8.2-a2. You can download and install in your virtualenv the latest version in a tarball from here: https://pypi.python.org/pypi/pyramid_appengine/
So here's another solution.
It seems that rod.recipe.appengine doesn't work with the setuptools versions of the system, and it doesn't download the last version in that buildout. So the solution is to force to download a newer version of setuptools that rod.recipe.appengine likes.
Edit the versions.cfg file (should appear just the [versions] tag) and add the following line:
[versions]
setuptools = 1.1.7
(other older versions work as well, I tested successfully with 0.9.8)
And now seems to work easier without needing the mentioned patches (thanks Tom) that are harder to update.
This happened to me as well.
I started looking at the code and noticed it was explicitly looking for an egg install of setuptools, and none of the places I had installations of it were eggs for some reason.
I decided I'd go delete them from my site-packages and re-run the tools to download them, and after only killing the copy in my virtual env, and re-running the bootstrap and buildout, it got the egg and everything started working fine.
I'm using Collabnate Subversion Edge.
I'm getting below error when trying to access URL http://localhost:3343/csvn.
Collbnate is set up on Windows Server 2008.
HTTP ERROR: 503
Problem accessing /csvn/. Reason:
Service Unavailable
Powered by Jetty://
How to solve it?
I spent two days fighting with the same problem. It turned out that CollabNet Subversion Edge 4.0.11 does not support Java 8.
The following procedure helped me make CN Subverion Edge 4.0.11 work again on Windows 7:
1) Uninstall CollabNet Subversion
2) Uninstall Java 8 (I had Java 7 and 6 side by side, so after uninstalling the 8, 7 picked up after I added it to PATH variable. It is important to add it at the very beginning of the path, otherwise Windows\System32\java.exe will be taken, which was not good for me also)
3) Install CollabNet Subverion (the important thing is to uncheck the "Run CollabNet ..." check box in the final screen. It looks like the installer is still creating files at the end and only after I have clicked OK in the final screen the needed configuration files have been created in data/conf folder.
4) Make sure that data/conf/httpd.conf file is created. If it is there, got to services (services.msc) and start server manually
Now launch the browser and navigate to localhost:3343/csvn.
Good luck.
1) Install Java 7
2) In file \csvn\svcwrapper\conf\wrapper.conf change from #wrapper.java.command.maxVersion=1.6 to wrapper.java.command.maxVersion=1.7
3) Run \csvn\svcwrapper\bat\runConsole.bat
Good luck.
Check in c:/csvn/data/logs for a log that starts with "console". Then find the error(s) and check what is wrong.
Did you try restarting the service ?
I had the same issue, CollabNet Subversion Edge version 4.0.4. In my case the problem was updating the JAVA_HOME from JDK 1.6 to JDK 1.7.
I finally resolved it changing the file:
C:\PROGRA~1\csvn\svcwrapper\conf\wrapper.conf
I changed the value of the property: wrapper.java.command:java
wrapper.java.command=C:/PROGRA~1/Java/jdk1.6.0_45/bin/java
So the csvn now runs with 1.6 as before. And it works again as a service automatically.
Good luck!!
There's an alternative issue that results in the same error: The database may get corrupted. This is what just happened to me. The above answers where not working in this case. As Subversion Edge 5.0.1 comes bundled with jre8, it would be rather strange if it weren't able to run against it.
To solve the problem, I had to patch the database (luckily, the user database c:\csvn\data\csvn-production-hsqldb.script is a plain text sql file).
Backup files in c:\csvn\data
Delete csvn-production-hsqldb.script and start the service (should come up now)
Exit the service
Save the file which is automatically recreated now
Compare your old file and the new working one
Replace every line starting with INSERT INTO QRTZ in your database with the corresponding lines from the working copy
Copy the new files to the proper place
Start the service
Hope it worked
I had this problem too. Upgrade to SubversionEdge 5.1.4 solved the issue.
We encounter this problem with CollabNet Subversion Edge 3.3.1 every time we patch our JDK 6 install (e.g. IAVM update). We need to install JDK 7 and 8 on this machine also so the installers are confusing the version information in the Windows Registry (not too much of a surprise there). Even if we update JDK 6 last, it gets weird too.
Nevertheless, it turns out the Subversion Console uses the Windows Registry to locate the Java install to launch the Console service. Updating the registry entry HKLM\SOFTWARE\JavaSoft\Java Development Kit\CurrentVersion to 1.6 and having a proper install of JDK 1.6 will restore console operation.
When installing DNN 04.09.02 upgrade (from DNN 4.8.4) I receive System.IndexOutOfRangeException: PermanentRedirect error and cannot install the upgrade. How do I get around this so I can install the upgrade?
This thread might help you:
It looks like you have to update it manually... steps are described there.
Also check this thread, might be due to AD if AD is used.
I've re-posted the following from the thread provided by kitsune. Source
First try the following in your browser. Replace "www.yourdomain.com" with your domain:
http://www.yourdomain.com/install/install.aspx?mode=install
If that doesn't work (which it didn't for me) then try the following steps (copied from Chris on that thread).
To manually run the SQL portion of the upgrade you'll need to run each upgrade script between your version and 4.9.2. I upgraded from 4.9.0 to 4.9.2 so I performed the following:
On the web server open the directory: \Providers\DataProviders\SqlDataProvider
Determine which files need to be run. Basically, all of the versions after your old version. In my case I needed to run the files 04.09.00.SqlDataProvider, 04.09.01.SqlDataProvider and 04.09.02.SqlDataProvider.
Open the SQL files in a text editor and replace "{databaseOwner}" (usually with "dbo.") and "{objectQualifier}" (usually with "", but sometimes "DNN4" or some other object prefix)
Run those SQL files in version order using SQL Management Studio.
Assuming those scripts ran without an error then the site should be ready to use.