We are using OPUS Make in our build infrastructure. (Basically traditional make with some wrappers around I guess)
Our codebase is mostly Java and I have been making changes and building for many months now. No issues.
Suddenly, a couple of days back, when I tried to build,i started seeing this error:
OPUS MAKE: Unknown status. Stop.
I see this error no matter what I try to build. More imp - it looks like it is not even trying to actually compile my code and for some reason just stops before with the above error.
I tried doing a clean build. Even manually cleaned up all old generated build files. Still did not work.
I even tried restarting my environment itself. Restarted Clearcase. Still no use.
I see there is a way to build with debug information. Did that also make -d
However, that did not give any useful info either. Just the same line as above. I was hoping that it would give some debug logs or some error code that I could use to solve the problem.
I see there is an option: make -n. That comes out clean. But from the name, it looks like it does not even attempt to run the build itself.
Please suggest what the issue could be.
thx - Om
"Unknown status" means that a shell command in a target returned a status that make did not understand. Run with -d to see which command is failing. And debug that shell command.
This question is related to I need help upgrading OroCommerce to 4.1.1.
I'm getting several errors related to extended entities... I believe there must be something wrong with cache building but I can't find the root cause (nor a solution :( ).
I checked the db structure in my production server against the VM where everything is working just fine and I can't see any significant difference (meaning the new fields such as digitalAsset_id for oro_attachment_file table or wysiwyg for oro_fallback_localization_val are there).
I just run an extra php bin/console oro:migration:load --force -e prod it didn't make a difference...
Edit:
Just checked the differences in the var/cache directory of both installations and in fact I see that the VM version has the methods that are missing from the prod one.
I uploaded the working code into the production server and re run the platform upgrade but I'm still running into issues.
In case oro:migration:load command (or oro:platform:update that actually triggers migration load) failed for the first time, you have to:
fix errors,
restore from the database dump
and run the command again.
Otherwise, there could be migrations that end up with errors,
but on the second run, they are not executed again, which could lead to the mess with the database schema, entity metadata, or entity config.
Also oro:migration:load command is not self-sufficient. There could be a need to warm up some entity configuration after the schema change. Please, try to run oro:platform:update, even if all the migrations are already executed, it would try to warm up all the caches and could fix an error.
I tried everything.I set the path variable.But nothing worked.Then i tried using ng command by running command line in administrator mode.And it worked.But it doesn't work untill i run it as administrator.Can anyone help me overcome this?
You shouldn't not use administrator privileges for npm installs, it may cause to a lot of problems. use this link as official guide
Recently installed .oh-my-zsh on a new machine on which RVM was already installed.
Noticed that in several of my Rails project directories, I now see this instead of the actual name of the project directory:
➜ ~RVM_PROJECT_PATH git:(master)
All other behavior seems normal, but I'm finding it difficult to pin down the cause in the .oh-my-zsh configuration.
it is a bug in your Zsh, to avoid it use %1/ in PROMPT instead of %. or %C or %1~
more info: https://github.com/wayneeseguin/rvm/issues/3091
this bug should be fixed in zsh 5.0.7 ... or with this https://github.com/robbyrussell/oh-my-zsh/pull/3252
oh-my-zsh has been updated to fix this issue. Forcing an upgrade of oh-my-zsh fixed the problem for me.
$ source ~/.oh-my-zsh/tools/upgrade.sh
So, I was really struggling with this for a while. I'm not using oh-my-zsh, just straight zsh, but had the same issues. Upgraded a lot of stuff. After digging through this huge script and trying lots of suggestions, this finally worked for me:
hash -rd
I just put this before I set my variable holding the directory. My config now looks like this:
30 hash -rd
31 local promptsize=${#${():---(${PR_GEMSET}${PR_BRANCH})---()--}}
32 local pwdsize=${#${(%):-%~}}
Note that the issue was with the %~. Just thought I'd share what worked for me.
You can write this on console, my problem is solved.
PROMPT='%F{green}%1/ ${vcs_info_msg_0_}$ '
Jupitor$ bundle exec rake db:create db:migrate
APP_development already exists
rake aborted!
PG::Error: ERROR: invalid value for parameter "TimeZone": "UTC"
: SET time zone 'UTC'
I keep getting this error when trying to migrate to my postgres database.
help would be much appreciated!
I had the same problem using the Postgres.app from Heroku. Rebooting my Mac solved it.
Restarting postgresql works.
To restart if you've installed it using homebrew, brew info postgresql will tell you to:
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
brew services restart postgresql
Try restarting the server. I updated Postgresql through Homebrew but forgot to restart the server and got this same problem. I believe it's due to the client and server versions not matching. psql started with:
$ psql
psql (9.1.4, server 9.1.2)
Type "help" for help.
Based on #MathiasJ's answer, instead of rebooting my entire machine, I ran
brew services restart postgresql#9.6
and my subsequent rake db:create worked perfectly.
I don't think I deserve any points for that but rebooting my Postgres.app (which is better than rebooting the whole system) solved it for me. The app doesn't show up on the Dock, you can find it on the navbar at the top of your window. Hope it helps anyway.
What actually happened is that you upgraded the postgresql server and cleaned-up your old folders but you haven't restarted your postgresql server. The server searched for the timezones files in the deleted dir
If nothing else fixes and you happen to be using homebrew, chances are you have issues with current links.
Assuming you have two Postgres versions installed, make sure you unlink and then link again. In my case, I needed the two versions working in order to run pg_upgrade. I have postgresql95 and postgresql so I did:
$ brew unlink postgresql
$ brew unlink postgresql95
$ brew link postgresql95
$ brew link --overwrite postgresql
That got me both working at same time. Hope it becomes helpful as it took me a good while to figure that out!
I also had this problem.
Login to the database then issue:
set time zone utc;
In my case restarting the database didn't help. Updating tzdata (apt-get install tzdata) did the trick for me.
just restarting the database helped. Homebrew updated my Postgres installation and I did not restart yet.
I had a similar problem after updating time zone information, that is, downloading the IANA database and compiling using zic.
My problem actually began after restarting PostgreSQL. I got invalid value for parameter TimeZone: UTC and restarting again did nothing to solve the problem.
It turns out my time zone information was completely messed up after the update. I had dangling symbolic links in /usr/share/zoneinfo. From a psql console, I got:
mydb=# SELECT * FROM pg_timezone_names;
ERROR: could not stat "/usr/share/zoneinfo/PRC": No such file or directory
I deleted all such dangling symlinks. After doing this, at least I could get SELECT * FROM pg_timezone_names to work, but still got the same invalid value... error.
What finally solved the problem for me was creating a new symlink:
cd /usr/share/zoneinfo
ln -s Etc/UTC UTC
After this, SET time zone 'UTC' worked correctly.
brew services restart postgresql did not fix for me. I'm sure rebooting would've worked, but I wanted to figure out the cause of the issue.
I believe the issue was caused for me because of two conflicting versions of postgresql.
I already had postgresql running with brew services, and then installed postgresql#11 which left postgresql running in brew services even after I uninstalled postgresql.
I fixed this by stopping the postgresql brew service, even though it wasn't listed in brew services list.
Steps to reproduce:
$ brew install postgresql
$ brew services start postgresql
$ brew install postgresql#11
$ brew uninstall postgresql
$ brew services start postgresql#11
How to fix:
$ brew services stop postgresql
Update: issue appears to have been deleted.
Opened an issue on Homebrew requesting that a formula's service should automatically be stopped upon uninstall.
Just a quick reference for those that are not using Postgres.app, but that start psql from the command line or through launchctl. You'll need to adjust the following for where you have your Postgres data and log files located at:
pg_ctl stop
pg_ctl start -D /usr/local/pgsql/data/ -l /usr/local/pgsql/log/server.log
For everyone using homebrew.
brew services restart postgresql did not fix for me too.
Rebooting fixed the issue. Thank you #JBallin, what you said is right.
Apparently, a similar thing also happens with Java/JDBC while connecting to Postgres.
The solution there is to tell JDBC to report the correct user timezone to Postgres while getting the connection.
So, explicitly mention the user timezone while starting the program helps:
java -Duser.timezone=America/Los_Angeles com.example.MyMainClass
Note:
Adding this here because this happens to be the first result on Google for this issue with connecting to Postgres!
Source:
This comment by Yuriy on the Jira support forum:
https://community.atlassian.com/t5/Jira-questions/invalid-value-for-parameter-quot-TimeZone-quot-quot-US-Pacific/qaq-p/839426