I am compiling a linux-based system using yocto. one of the steps of the compilation (using bitbake) fails while unpacking a ZIP file. The command that is failing is the following:
unzip -q -o '/absolute/path/to/file.zip'
Which return failed with return value 81
I have checked the meaning of unzip's code 81 which means: testing or extraction of one or more files failed due to unsupported compression methods or unsupported decryption.
The same unzip command works when run from a terminal.
Is there a way yo check the cause of the error 81? In other words, which is the unsupported compression method or unsupported decryption?
More information:
I have run unzip -v file.zip and found that compression method is
BZip2 which should be supported.
The file is not encrypted.
The file is not password protected
Yocto unzip is not built with bzip2 support. Assuming that the file can be opened with bzip2 tool (and as pmqs comments this may be an incorrect assumption), I think it should just start working if you rename the file so that the format is recognised and the correct tool gets used. Something like this:
SRC_URI = "http://example.com/download/fname-${PV}.zip;downloadfilename=fname-${PV}.bz2"
Use Zip-Ada. It supports Deflate, Deflate64, BZip2 and LZMA for decompression.
Related
Trying to set up instance of Facebook CTF on an AWS EC2 instance running Ubuntu 16.04 and am running into the following error when doing the quick setup.
xz: (stdin): File format not recognized
tar: Child died with signal 13
tar: Error is not recoverable: exiting now
curl: (23) Failed writing body (390 != 16384)
Traced the error to function in /extra/lib.sh where install_union is being called from /extra/provision.sh
function dl_pipe() {
local __url=$1
curl --retry 5 --retry-delay 15 -sSL "$__url"
}
function install_unison() {
cd /
dl_pipe "https://www.archlinux.org/packages/extra/x86_64/unison/download/" | sudo tar Jx
}
The URL links to a tar.zst file that I am able to download directly but am unclear why the shell script cannot. Thoughts?
The script can download it but assumes it is something that it isn't.
The J flag of (GNU) tar tries to decompress the file using xz prior parsing it. But the file is actually zstd and not xz compressed. Hence xz doesn't recognize the format.
It looks like Arch Linux's packages have been switched to use zstd instead of xz some time ago: https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Pacman-Zstd-Near
But the question is why you (or the script) want(s) to install an Arch Linux package on Ubuntu. There should be a package for Unison for Ubuntu. Try to just use that.
Or, if you (or the script) insist(s) using the Arch Linux package, try to install the Ubuntu package for zstd (or clone https://github.com/facebook/zstd and compile it yourself) and change the line in question to
dl_pipe "https://www.archlinux.org/packages/extra/x86_64/unison/download/" | zstd -d | sudo tar x
Or change the URL in the script so that it points to a (possibly older) package that still uses xz compression.
I am trying to build Parsec_3.0 dedup workload on skylake server with gcc (Debian 6.3.0-18+deb9u1) 6.3.0. I managed to build streamcluster and canneal successfully without issues, however with dedup I get the error, when using same command: parsecmgmt -a build -p dedup
ERROR:
installing man1/smime.1
smime.pod around line 272: Expected text after =item, not a number
same with lines: 276, 280, 285, 289
POD document had syntax errors at /usr/bin/pod2man line 70.
make: *** [install_docs] Error 255
Makefile:680: recipe for target 'install_docs' failed
[PARSEC] Error: env PATH=/usr/bin:/home/akhorguani/parsec/parsec-3.0/bin:/usr/lo
cal/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/sbin:/opt/dell/srvadmin/b
in:/usr/local/cuda/bin:/grid5000/code/bin:/home/akhorguani/parsec/parsec-3.0/bin
/usr/bin/make install failed.
In /usr/bin/pod2man line 70 is " print " $files[1]\n" if $verbose; ". But it's predefined file from the host machine so I don't think it would contain errors, most likely I might need to change something in parsec files.
So maybe anyone had faced the same problem and can help to fix it?
As jww mentioned, the error is due to some syntax errors on POD files from the SSL library that parsec uses. I had the same error and managed to build by replacing all instances of =item followed by a number with =item C<Number> in the POD files.
The files you need to modify are on the following folders:
$ folder-where-you-installed-parsec/pkgs/libs/ssl/src/doc/apps
$ folder-where-you-installed-parsec/pkgs/libs/ssl/src/doc/ssl
You can see the changes you need to do in this github gist.
I did the changes by hand but you can probably make a script that reads the files and fixes it for you.
I believe that the issue is platform specific because my colleague built it without any problems with Manjaro linux, while I'm using Ubuntu 18.04.
Eduardo's answer worked for me!
It seems the gist is out of date as ome of pod files have changed in the newer PARSEC version.
sed -i.bak 's/item \([0-9]\+\)/item C<\1>/g' *
The script above carries out needed transformation. Run it from apps and ssl folders
I'm new to Gromacs (and protein-analysis coding in general, but have some experience with python-based code). I'm trying to convert a .ene file received from pyDock to a more readable format (it currently opens
When I try to use different commands that the gromacs guide says accept .ene files (gmx eneconv and gmx dump), for example
gmx eneconv -f project.ene -o converted.edr
and
gmx dump -e project.ene -om read.mdp
I get the error
File 'project.ene' cannot be used by GROMACS because it does not have a recognizable extension.
The following extensions are possible for this option:
.edr
I have updated my OS and re-installed gromacs. My installation is working according to the 'Getting Started' page.
I am also open to suggestions for other programs to open and read the .ene file type.
Thanks!
"ene" is short for "energy" which contains binary data for energy, temperature, volume, etc, and is only used in older version of Gromacs. In new version of Gromacs this is replaced by "edr" file which contains portable binary data. See "gmx dump -h", you will find the following lines:
Options to specify output files:
-o [<.edr>] (fixed.edr)
Energy file
If you insist on using ene file, you should install an older version of Gromacs.
I am trying to install the Net::LDAP module on an OEL box using CPAN, but I get the following error:
[root ~]# cpan -i Net::LDAP
CPAN: Storable loaded ok
Going to read /root/.cpan/sources/authors/01mailrc.txt.gz
Could not pipe[ --decompress --stdout /root/.cpan/sources/authors/01mailrc.txt.gz |]: No such file or directory at /usr/lib/perl5/5.8.8/CPAN.pm line 5726.
Can someone please guide me on how to troubleshoot this?
CPAN needs to be configured before you can use it to install stuff.
There should be a whole bunch of stuff under
/root/.cpan
Generally cpan gets this stuff automatically, but for some reason it's
not there on your machine. In particular it needs this file.
/root/.cpan/sources/authors/01mailrc.txt.gz
If that file is there, then cpan man be missing the gzip binary needed to uncompress that file.
Hi i am trying to install bugzilla on my mediatemple server, i am totally a novice when i comes to cmmd line so have found a tutorial on-line which was going well till i tried to upgrade the above.
the below is the message i get in the command line and after looking on-line for about an hour i cant seem to find a resolution to the issue. basically i am stuck on where to go now to upgrade what its asking
Installing Archive::Tar version 1.76...
Running install for module 'Archive::Tar'
Running make for B/BI/BINGOS/Archive-Tar-1.76.tar.gz
CPAN: Digest::SHA loaded ok (v5.62)
CPAN: Compress::Zlib loaded ok (v1.42)
Checksum for /root/.cpan/source/authors/id/B/BI/BINGOS/Archive-Tar-1.76.tar.gz ok
CPAN: Archive::Tar loaded ok (v1.3901)
You have Archive::Tar 1.3901, but 1.50 or later is recommended. Please upgrade.
Uncompressed /root/.cpan/source/authors/id/B/BI/BINGOS/Archive-Tar-1.76.tar.gz successfully
Using Tar:/bin/tar xvf "Archive-Tar-1.76.tar":
Couldn't untar Archive-Tar-1.76.tar
CPAN: File::Temp loaded ok (v0.22)
CPAN: CPAN::Meta loaded ok (v2.110930001)
CPAN: Time::HiRes loaded ok (v1.9717)
Package seems to come without Makefile.PL.
(The test -f "/root/.cpan/build/BINGOS-J_TqCf/Makefile.PL" returned false.)
Writing one on our own (setting NAME to ArchiveTar)
Had problems unarchiving. Please build manually
Skipping test because of notest pragma
Running make install
Make had some problems, won't install
Manually install a new Archive::Tar version first. It looks like it's trying to use /bin/tar to untar the Archive::Tar package it downloaded, but failing to do so, perhaps because that's not the correct location of your tar binary.
Use which tar to find out where tar is on your system - it may be /usr/bin/tar, in which case, it's looking in the wrong place.
If you're using CPAN.pm for this, you can correct the path to tar with the following from the CPAN.pm shell (which you can get to with cpan or perl -MCPAN -e shell:
o conf tar '/usr/bin/tar'
o conf commit
(Using whatever path which tar gave you.)