Mysterious ssh public key authentication failure? Check /var/log/secure. You will probably see a permission problem such as that your home directory cannot be group writable (which is annoying).
A simple
$ chmod g-w ~
fixed this for me.
Nice one from a colleague:
perl -wne 'while(/[\w\.\-]+@[\w\.\-]+\w+/g){print "$&\n"}'
I should probably get set up with a snippet library for this kind of thing.
This comes to me word-of-mouth.
It seems there’s a longstanding bug/feature in the firewall routemap that causes the ipv6 localhost link to fail, and then the v4 link is tried, and succeeds. Apache is bound to both, but Windows won’t route the v6 link correctly.
There are a couple of solutions here, including turning off ipv6 in Windows. It’s probably easiest just to explicitly define “localhost” in C:\Windows\System32\drivers\hosts. Uncommment the 127.0.0.1 line:
127.0.0.1 localhost
# ::1 localhost
Although Symfony’s original baked-in test framework, Lime, is being replaced by PHPUnit in Symfony 2, I figure I should post a fix for those, like me, who will be stuck for the foreseeable future in Symfony 1.x with an older suite of tests.
In general, Lime works pretty well except when running multiple tests in the harness. For example, when you run a specific test or tests:
$ ./symfony test-unit util
1..14
# isEmailValid()
ok 1 - returns an integer
ok 2 - test@test.com is a valid email address
ok 3 - test@test is not a valid email address
...
Lime plays along nicely. But when you run all of your tests via the test harness like so:
$ ./symfony test-unit
happyTest......................................................dubious
Test returned status 1
sillyTest......................................................dubious
Test returned status 1
...
the results can be dubious.
“Dubious” here means that the test crashed somehow during execution and so Lime doesn’t know if it would have passed or failed. To see what’s going on, pop open symfony/vendor/lime/lime.php. Depending on your version, you should see a block like the following inside lime_harness->run():
ob_start(array($this, 'process_test_output'));
passthru(sprintf('%s -d html_errors=off -d open_basedir= -q "%s" 2>&1', $this->php_cli, $file), $return);
ob_end_clean();
Never mind that the above passthu may not work on Windows (see ticket #5437), if you comment-out the output buffering and run your tests again, you’re likely to discover that Symfony can’t autoload Symfony libraries, base classes, or what-have-you; for example:
$ ./symfony test-unit
Fatal error: Class 'sfCore' not found in D:\app\test\unit\happyTest.php on line 8
Call Stack:
0.0004 70248 1. {main}() D:\app\test\unit\happyTest.php:0
The easiest fix is to work around this whole executing tests via passthru nonsense. A good old “include”, like Pake does when you run one test at-a-time, will do just fine. Patch lime.php:
ob_start(array($this, 'process_test_output'));
$return = include($file);
ob_end_clean();
Then add a “return 0;” to the end of each of your tests. (Yes, the Lime harness expects zero to indicate success..)
Now the harness should run just fine:
$ ./symfony test-unit
happyTest......................................................ok
sillyTest......................................................ok
All tests successful.
Files=2, Tests=10
Of course, this will break the harness for the functional tests, but that’s a fix for another post.
Not sure if this is a little more clear in later releases of Symfony, but in 1.0.x the load-data task, as outlined in the documentation and cookbook, is somewhat vague.
If you’re appending a fixture to an existing database, here’s what you want to do:
$ php symfony propel-load-data <APPLICATION_NAME> [<ENVIRONMENT_NAME>] <FIXTURES_DIR_OR_FILE> append
so usually I do something like this:
$ php symfony propel-load-data frontend data/fixtures/import_data.yml append
I’m actually not sure how ENVIRONMENT_NAME would come in to play.. Either this is a way to select per-environment fixture data (probably), or per-environment databases to which to apply the data.
From Wired. The zombie bill came back form the dead the same day that Egypt shut down it’s Internet.
What happened to the whole rooftop mesh network concept, anyway?
This has been bugging me for awhile. Recent versions of Emacs save _flymake files “inplace”, meaning in the same directory as the source file. Problem is, Flymake has a tendency to crash, leaving behind the corpses of various _flymake files, which in turn cause version control annoyances, automated build issues, unusual problems with caching in web frameworks, etc.
There’s an obscure FlymakeRuby entry on the EmacsWiki with a suggested fix, repeated here:
(defun flymake-create-temp-intemp (file-name prefix)
"Return file name in temporary directory for checking FILE-NAME.
This is a replacement for `flymake-create-temp-inplace'. The
difference is that it gives a file name in
`temporary-file-directory' instead of the same directory as
FILE-NAME.
For the use of PREFIX see that function.
Note that not making the temporary file in another directory
\(like here) will not if the file you are checking depends on
relative paths to other files \(for the type of checks flymake
makes)."
(unless (stringp file-name)
(error "Invalid file-name"))
(or prefix
(setq prefix "flymake"))
(let* ((name (concat
(file-name-nondirectory
(file-name-sans-extension file-name))
"_" prefix))
(ext (concat "." (file-name-extension file-name)))
(temp-name (make-temp-file name nil ext))
)
(flymake-log 3 "create-temp-intemp: file=%s temp=%s" file-name temp-name)
temp-name))
Add this to lisp/progmodes/flymake.el in your Emacs distro, and then call it from the init method corresponding to your target language. PHP, for example:
;;;; php-specific init-cleanup routines
(defun flymake-php-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-intemp))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "php" (list "-f" local-file "-l"))))
Note that 'flymake-create-temp-inplace has been replaced with 'flymake-create-temp-intemp. Be sure to remove or recompile the corresponding flymake.elc file.
Now _flymake junk will be saved to where you have defined temporary-file-directory in .emacs. In my case:
(setq temporary-file-directory "~/.emacs.d/tmp/")
Yay. Much less annoying.
So you’re working in an older version of Symfony (or maybe even a newer one..), trying to refactor some common code into a partial. Maybe something simple like this from within a global partial?:
include_partial('status');
And suddenly connections to the database start falling down with errors along the lines of:
SQLException: No database selected [Native Error: MySQL server has gone away]
In reality this is a problem with Symfony’s error reporting from within global partials. Do you actually mean?:
include_partial('global/status');
Remember that even if you’re in a global partial, Symfony doesn’t really know that’s where you are.
Go go backup brain:
$ find -type f ¦ wc -l
As found elsewhere on the net.
The Huffington Post is doing a good job of keeping on top of the Kill Switch. The kill switch concept was originally part of the Bush2-era Project for a New American Century where they called for increased control over space and cyberspace. Which is essentially increased control over the flow of information and populations.
A cyber kill switch would be a prerequisite for any kind of martial law declaration.