This seems like an idiotic question, but I can't find documentation on it anywhere.
How do I get a the SHA1 of a RevCommit object?
RevCommit inherits from AnyObjectId which has a getName function.
getName
public final String getName()
Returns:
string form of the SHA-1, in lower case hexadecimal.
Do note that getName()only works with SHA-1 repositories: JGit does not yet work with SHA-256 repositories.
That is why, for instance, Git 2.30 (Q1 2021) does mark the tests that uses JGit not to run unless we are testing with ShA-1 repositories.
See commit ea699b4 (13 Nov 2020) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit d302170, 25 Nov 2020)
t5310-pack-bitmaps: skip JGit tests with SHA256
Signed-off-by: SZEDER Gábor
Reviewed-by: Taylor Blau
In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps are compatible with JGit's bitmaps.
Alas, not even the most recent JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with JGit installed in PATH, then these two tests fail.
Protect these two tests with the SHA1 prereq in order to skip them when testing with SHA256.
Related
PHP v7.2.3
PHP Unit 8.2.3
Codeception 3.0.2
When I try to run tests I get the following error:
Declaration of
Codeception\Test\Test::run(?PHPUnit\Framework\TestResult $result =
NULL) must be compatible with
PHPUnit\Framework\Test::run(?PHPUnit\Framework\TestResult $result =
NULL): PHPUnit\Framework\TestResult in
/var/com/vendor/codeception/codeception/src/Codeception/Test/Test.php
on line 18
When I look at the definition of PHPUnit\Framework\Test::run I see it specifies a return type but Codeception\Test\Test::run does not and this would appear to be the problem.
I've checked back through the version history of both of these files in the respective git repos and it seem these files have been this way for many versions.
After much searching it doesn't seem anyone else has posted the issue which makes me think I'm missing some key insight.
Any light shed on this issue would be much appreciated, thanks!
In the end a fresh install of Symfony latest version and Codeception presented a working solution.
Since this was initially a port from another symfony 3 application (with an older version of codeception) it's likely that there was a misconfig or incompatible package.
The other possible cause which occurred to me later is that the cli for codeception in previous versions of symfony was run from a general bin directory 'bin/codecept' and now we run directly from 'vendor/bin/codecept' its possible that my CI script was referencing an outdated cli.
I would like to use Hadley Wickam's secure package from GitHub.
The example usage isn't explicit about how to create keys and where to store them and I'm messing something up (possibly more than one thing).
I installed the package
# install.packages("devtools")
devtools::install_github("s-u/PKI") # needed for bug fixes not currently on CRAN
devtools::install_github("hadley/secure")
set up a vault folder:
dir.create("vault")
Then the next step is to add a user / key:
secure::add_user("hackr", local_key())
and of course if I literally run that last line as-is it says
Error: No key matches id_rsa
Because I don't have a key. So, I used PuttyGen to create a public/private RSA key pair.
I saved them to my desktop and tried putting the full path in the command above:
secure::add_user("hackr", local_key("C:/Users/hackr/Desktop/r_public_key"))
But that didn't work:
Error: No key matches
Then I tried saving the public key in the vault and doing:
secure::add_user("hackr", local_key("r_public_key"))
but I got the same error. Next I tried putting the public key in the working directory (one directory higher than the vault) but got the same error.
Finally, I tried copying the keys to C:\Users\hackr\.ssh but that also led to the same error.
I suspect I need to save the key somewhere special (in Windows I'm not sure where that would be?) and/or I am using the wrong type of key since PuttyGen is for SSH (?).
It looks like local_key is assuming your key is stored in ~/.ssh (which is a reasonable assumption). By default it assumes that the file is named id_rsa.pub so if you've renamed it then you'll need to pass the name into local_key.
I haven't used this package but always remember those wise words "Hack-R view the source"
The issue is that Hadley's local_key() function is assuming your key is stored in ~/.ssh which is where the commands below will place it by default, and name it id_rsa.pub. If you have a different setup, you can change the defaults, or you could simply follow the steps below.
Step 1
Go to https://help.github.com/articles/generating-an-ssh-key/
Read up. It's useful stuff to know.
It will tell you to do this in the console:
ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
Set a passphrase. Remember it.
Then enter this:
ssh-add ~/.ssh/id_rsa
Enter your passphrase.
Step 2
Your secure::add_user("hackr", local_key()) should work now.
Today's (1 Mar 2016) OpenSSL release has caused the following error when running Plone/Zope
.buildout/eggs/ZODB3-3.10.5-py2.7-linux-x86_64.egg/persistent/cPersistence.so: undefined symbol: SSLv2_method
It's hard to see what's going on since it's a binary file. I also tried updating to ZODB3 3.11.0 which yields the following traceback
.buildout/eggs/ZConfig-2.9.0-py2.7.egg/ZConfig/loader.py", line 217, in schemaComponentSource
package=package)
ZConfig.SchemaResourceError: could not load package ZServer:
.buildout/eggs/zope.security-3.7.4-py2.7-linux-x86_64.egg/zope/security/_proxy.so: undefined symbol: SSLv2_method
Package name: 'ZServer'
File name: 'component.xml'
Package path: None
Is there any workaround for this other than reverting OpenSSL?
zope security is a compiled egg, like all the ones ending with -py2.7-linux-x86_64.egg.
As the traceback says, it cannot find anymore a symbol.
Probably you have to recompile it with the new openssl-dev.
I would try (on a development server first):
backup your compiled egg (mkdir eggs-backup && mv `eggs/zope.security-3.7.4-py2.7-linux-x86_64.egg eggs-backup/)
rerun buildout
This will recompile your missing egg.
Hopefully it works and hopefully it is the only one linked to that library.
Anyway, dependending on the way you patched openssl you may have a lot of other issues (I am thinking about Python, urllib*, curl, wget, ...)
OpenSSL 1.0.2g by default doesn't build with SSLv2 (because of the recent DROWN attack). You may need to manually build it without OPENSSL_NO_SSL2 flag.
(but in fact you shouldn't do this if you're doing some server-related stuff, there is a serious security reason because of which it was disabled, see https://drownattack.com)
I was able to resolve this by upgrading python to 2.7.10+, and then upgrading Pillow and lxml.
Where is the definition of function copyout() in FreeBSD for AMD64?
(http://www.unix.com/man-page/FreeBSD/9/copyout/)
The only place I can find is in sys/sys/systm.h.
The definition/declaration is:
int copyout(const void * __restrict kaddr, void * __restrict udaddr,
size_t len) __nonnull(1) __nonnull(2);
Is it a declaration or a definition? What does __nonnull(1) and __nonnull(2) mean?
That is a function prototype, otherwise known as a declaration. The implementation (definition if you choose) is in the kernel sources. You can find those online, or (if you chose to install sources) on your local FreeBSD machine (under /usr/src/sys). There are actually several copies, depending on the hardware for which the kernel is compiled. (The function names, by the way, are "old" — I encountered them in the mid-1980s, and they were well-known at that point in time).
The kernel source contains several implementations of these functions, depending on the hardware platform. For instance, in FreeBSD 10, the amd64 version is written in assembly language (see SVN in /usr/src/sys/amd64/amd64/support.S for instance). In the same release, I found only one implementation written in C (under the powerpc subtree), and in current source, that has been rewritten. So, to know "where" is the source, you must do some research and find the corresponding source for your hardware platform and release of FreeBSD.
__nonnull is a compiler directive telling it to ensure that the given parameters are not obviously null-pointers. See for example these mailing list comments:
svn commit: r283249 - head/sys/sys
Introduce the gcc/clang nonnull attribute in the signal and pthread headers.
I was considering if a java project could produce 2 jars: one for java7 and one for java6, yes, the source code might use some some java7 new features.
so to generate the java6 jar, the command line would be like:
javac -target 1.6 -bootclasspath jdk1.6.0\lib\rt.jar -extdirs "" MyApp.java
Unfortunately,
It simply emits an error:
javac: target release 1.6 conflicts with default source release 1.7
According to this document, it should be possible for jdk6 vs jdk5, anybody knows why it doesn't work in jdk7 vs jdk6? did I do something wrong, or is it just officially not supported?
Thanks.
AFAIK, the source and target have to be the same. Even for Java 6. The only exception is the source can be 1.1 and the target 1.0.
Given there is little difference in the JVM between the latest JVM for Java 6 and Java 7, I suggest you consider upgrading. Also Java 6 will be, End Of (free) Service in Nov 2012, which three months from now...
Even if it were possible it's generally a bad idea - if you want to be sure your code will work on java 6 then you have to build it on java 6. Each new version of java introduces new classes in the class library, and adds new methods to existing classes, and even if you set your java 7 compiler to generate 6-compatible bytecode it won't catch cases where you call a 7-only method.