Following is the error I am getting when I tried 'git svn rebase':
Byte order is not compatible at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 380, at /usr/lib/perl5/5.10/Memoize/Storable.pm line 21
The version of perl I am running is:
$ perl --version
This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
(with 12 registered patches, see perl -V for more detail)
When I searched the web for "Byte order is not compatible" and I get numerous hits that shows the Perl doc that says:
What this means is that if you have
data written by Storable 1.x running
on perl 5.6.0 or 5.6.1 configured with
64 bit integers on Unix or Linux then
by default this Storable will refuse
to read it, giving the error Byte
order is not compatible. If you have
such data then you you should set
$Storable::interwork_56_64bit to a
true value to make this Storable read
and write files with the old header.
You should also migrate your data, or
any older perl you are communicating
with, to this current version of
Storable.
What I don't know is, how to set this '$Storable::interwork_56_64bit' to true. Can you please let me know how to do it?
I started getting this error message. I'm using a git repository that lives in a Max OS X partition. I sometimes access it from OS X (64 bit), and sometimes access it from a VM that's running a 32 bit version of Linux. It looks like there's a cache file that is stored in a machine-dependent format.
After doing some digging, I believe you can work around the error by blowing away all of the .db files stored in .git/svn/.caches. This should be a slightly more surgical approach than blowing away the entire svn directory.
This happened to me recently on my Mac. I'm not sure what caused it, but the standard git-svn "fix" of blowing away the metadata and updating worked for me:
% mv .git/svn .git/svn.bak
% git svn fetch
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
.git/svn
(required for this version (1.7.1) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
Rebuilding .git/svn/refs/remotes/bg-threads-1.1/.rev_map.a5d90c62-d51d-0410-9f91-bf5351168976 ...
r5758 = 545e176a13e87d44a2750ff5f06959088efc9e5b
...
I suspect one potential cause of this is using a git repository with svn data that's been fetched on one machine and then subsequently archived up and downloaded for use on another machine.
In my case it was fetched on CentOS and then transplanted to an Ubuntu machine - both 64-bit installs but perhaps some little detail of their Perl configuration is different. Or perhaps a package update changed something.
Related
I have some code using an old perl version on a live server and I want to get it working on a new activestate installation on my laptop. I am getting an error message complaining about Win32::NetResource not being there. I have tried to locate it on activestate, but have failed. The current version is 5.34 but the working system that presumably has the module is on 5.26.
Another server with a recent starawberry perl doesn't have the module either - worried that it might not be supported any longer.
I've had as few issues trying to upgrade postgresql-server. I've reverted back to the older version now (9.0.3) and the service is running and accessible via pgadmin/other gui tools.
However, I can't access it via the psql command (as user postgres). This may be possibly because the psql binary seems to be missing. I feel this may have happened when I uninstalled a version of postgres that I had intended to revert to.
I can't reinstall version 9.0.3 because the repo is no longer valid.
Is there any way I can install only the psql binary file and nothing else. I was considering copying the psql binary file from another server, although because the other servers have different versions of postgresql, I'm not sure if this is a good idea (?)
I think psql binaries didn't disapear from your system.
It's just that you had symbolic links from /usr/bin to your 9.0.3 binaries.
When you installed a newer version, this links where replaced to point to the new version and when you uninstalled it, they were dropped.
Try locate to find your binaries. Then you would be able to recreate your symbolic links in /usr/bin.
If you want to try 9.0.3 - you can always build it from source:
https://www.postgresql.org/ftp/source/v9.0.3/
But many distros package pqsl-client seperate from the server and you can use a newer version of psql instead (or at least try).
There are also archives of almost any distro out there and you could fetch that single rpm/deb packge from there.
I have a package I just updated to use setuptools_scm and found the version number is wrong in readthedocs.
http://sshuttle.readthedocs.org/en/v0.77/ shows:
Version: 0.78.dev0+ng083293e.d20160304
however as version 083293e has the 0.77 tag, the version string should be just 0.77
It looks like readthedocs might be making changes to my source code before building.
I have looked at the readthedocs build logs, and it seems to have the correct version at one stage (0.77), however this is before it builds the documentation.
Processing dependencies for sshuttle==0.77
Finished processing dependencies for sshuttle==0.77
The build logs don't mention the version while building the documentation.
Is it possible to solve this?
Thanks
I see that you're building this project.
Clearly, something is mutating the repository state before the version is determined. You can replicate similar behavior by mutating one of the files prior to building the docs yourself:
(sshuttle) $ python setup.py --version
0.77
(sshuttle) $ cat >> setup.py
# a comment
(sshuttle) $ python setup.py --version
0.78.dev0+ng083293e.d20160403
In the read the docs docs, there's a description of the process.
There, you can see the steps RTD does, namely, (a) run setup.py install then (b) install requirements in requirements.txt.
I've confirmed that neither of those steps should be mutating the repo state.
What it doesn't explain, however, is where that 'version' comes from, or what update_imported_docs does. I suspect the issue lies in something subtle that read the docs is doing that modifies the repo.
Here's one place where the conf.py file gets modified.
Perhaps adding docs/conf.py to your .gitignore will allow those changes to be ignored and thus not dirty your working state when calculating the project version.
https://github.com/pypa/setuptools_scm/issues/84 has been updated to record this
we will be working with the sphinx team to provide a automated/painless version of this process
The documentation for setuptools_scm now has instructions on how to use with readthedocs:
It is discouraged to use setuptools_scm from sphinx itself, instead
use pkg_resources after editable/real installation:
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])
The underlying reason is, that
services like readthedocs sometimes change the workingdirectory for
good reasons and using the installed metadata prevents using needless
volatile data there.
This avoids the need to use kluges as per the other answer.
I’m a mere mortal using Cygwin on Win7 and wanting to develop perl scripts using SOAP::lite. Installation instructions I found at soaplite.com directed me to start with perl –MCPAN –e shell before attempting an > install SOAP::lite
The newb in me didn’t appreciate that my windows user profile has a space character in it and the CPAN set-up seemed to go all horribly wrong around the point where the script was writing make files for local::lib, MYMETA.yml and MYYMETA.json. I got “no such file or directory” messages quoting only the portion of the path that followed the space in my user profile.
$ uname -a
CYGWIN_NT-6.1 UKLHRL00020 2.0.4(0.287/5/3) 2015-06-09 12:22 x86_64 Cygwin
$ cpan --version
Loading internal null logger. Install Log::Log4perl for logging messages
/usr/bin/cpan version 1.61 calling Getopt::Std::getopts (version 1.06 [paranoid]),
running under Perl version 5.14.4.
[Now continuing due to backward compatibility and excessive paranoia.
See ``perldoc Getopt::Std'' about $Getopt::Std::STANDARD_HELP_VERSION.]
Nothing to install!
When I ran perl –MCPAN –e shell for the first time, it did report “Warning: You do not have write permission for Perl library directories.” and I elected for the default option [local::lib] for the approach to be taken.
So what can I do next?
Looking closer at the Cygwin’s setup-x86_64.exe, a search for “cpan” lists eight packages under the perl category for perl-CPAN-* and perl-Parse-CPAN*, which are all set to “Skip”. The package perl-CPANMeta: Perl distribution CPAN-Meta is version 2.150001-1 from cygwin.mirrors.pair.com. Since this is not installed yet, but the installed Perl5 has some knowledge of an old CPAN, I need to know if it is safe to install the latest and will it work with a space in my profile? Do I need to remove the old CPAN, and how?
You probably want to update to the latest version of ExtUtils::MakeMaker, recent versions contain various fixes for paths containing spaces. This should fix these issues.
I'm running 32-bit Windows 7 Starter on a cheap netbook. I used to do most of my experimental coding in ActiveState Perl but switched to node.js and stopped using Perl for some time.
I had kept my Perl up to date despite not using it so had the latest version, 5.15.3 Build 1604.
Today I found something I wanted try out in Perl but ran into some problems I'd never seen before.
The perl -V command in the console would lock up without outputting anything.
I uninstalled Perl, reinstalled, did a Windows update, and rebooted my machine but now I get a system error dialog:
The dialog is followed by this error in the console:
Can't load 'C:/Perl/site/lib/auto/Win32/Win32.dll' for module Win32: load_file:The specified module could not be found at C:/Perl/lib/DynaLoader.pm line 191.
at C:/Perl/lib/ActivePerl/Config.pm line 405.
Simple things work in perl, such as printing a literal string. ActiveState's package manager tool, ppm, seems to work fine.
I tried doing a "repair" on the installation through the control panel, but this changed nothing.
After posting the question I've noticed mentions perl512.dll!
For some reason, even though I had uninstalled and reinstalled Perl 5.15.3 something was tying it to Perl version 5.12.X ...
Since ppm was working I tried ppm upgrade Win32 and got:
Win32 0.49 (have 0.44)
Downloading Win32-0.49...done
Unpacking Win32-0.49...done
Generating HTML for Win32-0.49...done
Updating files in user area...done
2 files deleted
1 file installed
4 files updated
Perl -V now works in the console. I can't say I really understand what was going on though.