Xcode 9.1 (9B55) failed to export with error of Stripping extended attributes failed and below error message:
/usr/bin/xattr -crs /var/folders/mm/h01jykrs7gv9w7jjb0yt609w0000gp/T/XcodeDistPipeline.FZT/Root/Payload/GitSmartHome.app" exited with a non-zero status. The /usr/bin/xattr tool may be damaged.
In IDEDistributionPipeline.log, can see below error:
2017-11-01 14:02:24 +0000
2017-11-01 14:02:24 +0000 Running /usr/bin/xattr '-crs' '/var/folders/mm/h01jykrs7gv9w7jjb0yt609w0000gp/T/XcodeDistPipeline.U1x/Root/Payload/GitSmartHome.app'
2017-11-01 14:02:24 +0000 option -c not recognized
usage: xattr [-lz] file [file ...]
xattr -p [-lz] attr_name file [file ...]
xattr -w [-z] attr_name attr_value file [file ...]
xattr -d attr_name file [file ...]
The first form lists the names of all xattrs on the given file(s).
The second form (-p) prints the value of the xattr attr_name.
The third form (-w) sets the value of the xattr attr_name to attr_value.
The fourth form (-d) deletes the xattr attr_name.
options:
-h: print this help
-l: print long format (attr_name: attr_value)
-z: compress or decompress (if compressed) attribute value in zip format
2017-11-01 14:02:24 +0000 2017-11-01 14:02:24 +0000
2017-11-01 14:02:24 +0000 /usr/bin/xattr exited with 64
I searched and tried a lot from the web before see this error, the question is how to fix or reinstall xattr or python of original MacOS?
Does re-install High Sierra fix that?
Your advice is appreciated.
Hello，Has your problem been resolved ? I get the same problem with you.
I have a solution that maybe help you.
I run cmd "/usr/bin/xattr -crs ***" in terminal and get:
python version 2.7.14 can't run /usr/bin/xattr. Try the alternative(s):
/usr/bin/xattr-2.7 (uses python 2.7)
then I run cmd
$ sudo mv xattr xattr_bak
$ sudo mv xattr-2.7 xattr
it worked in my xcode9.1.
Related
I am working in a CentOS environment and am setting up perlbrew (App::perlbrew/0.87) locally. I've essentially been following the steps here. I have set up perlbrew similarly in the past and no issues, but now am having a strange problem. It is worth noting that I was able to set up perlbrew and install perl locally on the same machine, same environment, for a different user.
The problem is this, perlbrew is installed, but cannot install any version of perl because after downloading the dist it fails to extract the tar.gz.
Here is some information about the install. Perlbrew and cpanm seem to be in place and functioning fine.
-bash-4.1$ env | grep PERL
PERLBREW_SHELLRC_VERSION=0.87
PERLBREW_ROOT=/my/home/dir/perl5/perlbrew
PERLBREW_HOME=/my/home/dir/.perlbrew
-bash-4.1$ env | grep perl
OLDPWD=/my/home/dir/perl5/perlbrew
PERLBREW_ROOT=/my/home/dir/perl5/perlbrew
PATH=/my/home/dir/perl5/perlbrew/bin:/usr/local/bin:/bin:...
PWD=/my/home/dir/perl5/perlbrew/dists
PERLBREW_HOME=/my/home/dir/.perlbrew
-bash-4.1$ which perlbrew
~/perl5/perlbrew/bin/perlbrew
My .bash_profile contains only:
source ~/perl5/perlbrew/etc/bashrc
-bash-4.1$ perlbrew available
perl-5.31.6
perl-5.30.1
perl-5.28.2
perl-5.26.3
perl-5.24.4
...
However, when I try to install, I start getting errors from tar.
-bash-4.1$ perlbrew install perl-5.30.1
tar: perl-5.30.1/.dir-locals.el: Cannot close: Permission denied
tar: perl-5.30.1/.dir-locals.el: Cannot utime: Permission denied
tar: perl-5.30.1/.lgtm.yml: Cannot close: Permission denied
tar: perl-5.30.1/.lgtm.yml: Cannot utime: Permission denied
...
it goes on and on for every file.
I think the key output here is:
Failed to extract /my/home/dir/perl5/perlbrew/dists/perl-5.30.1.tar.gz at /my/home/dir/perl5/perlbrew/bin/perlbrew line 1631
If I navigate to where perlbrew downloads the dist and try to extract it manually, it fails.
-bash-4.1$ cd /my/home/dir/perl5/perlbrew/dists/
-bash-4.1$ ll
total 17308
drwxrwxrwx. 4 myUserID myGroup 11776 Dec 2 15:10 perl-5.30.1
-rwxrwxrwx. 1 myUserID myGroup 17712574 Nov 25 14:46 perl-5.30.1.tar.gz
-bash-4.1$ tar -xvf perl-5.30.1.tar.gz
perl-5.30.1/
perl-5.30.1/.dir-locals.el
tar: perl-5.30.1/.dir-locals.el: Cannot close: Permission denied
tar: perl-5.30.1/.dir-locals.el: Cannot utime: Permission denied
perl-5.30.1/.lgtm.yml
tar: perl-5.30.1/.lgtm.yml: Cannot close: Permission denied
tar: perl-5.30.1/.lgtm.yml: Cannot utime: Permission denied
perl-5.30.1/.metaconf-exclusions.txt
The perl-5.30.1 directory is created and files are made but they are not really extracted. It's just full of 0kb files where everything should be.
I've tested tar by creating tarballs from files I create and zipping and unzipping and whatnot, everything seems to work there fine. All the files are owned by my user/group, so I don't get why I can't extract this file.
Does anyone know what could be the cause of this behavior?
EDIT: This was actually done on a different machine configured the same way as it turns out!
I want to note again that I was able to successfully perform the install on a different user by the same method on the same machine and didn't run into this issue.
One user, #DavidMitchell commented about additional permissions shown by ls -lZ that might influence things. Note that I am using SGE on this machine and have to qlogin to process most tasks.
Before and after qlogins:
In the perl/dist folder before qlogin.
-bash-4.1$ ls -lZ
-rwxrwxrwx. myUser myGroup system_u:object_r:nfs_t:s0 perl-5.30.1.tar.gz
AFTER qlogin
-bash-4.2$ ls -lZ
-rwxrwxrwx myUser MyGroup ? perl-5.30.1.tar.gz
So there's a '?' there, so that's interesting. I checked on another machine and user with successful installation and it seems to show the same thing though, so maybe this isn't the issue. Will continue to look into it further, appreciate any further advice!
I'm currently trying to integrate a package from github which implements a MTP-responder in userspace.
I'm using buildroot 2017.08.
I have created both Config.in and umtprd.mk files with the following content.
I also patch sources in order to replace some fields' value into the configuration file given with the package.
Config.in
$ cat Config.in
config BR2_PACKAGE_UMTPRD
bool "umtprd"
help
umtprd is a deamon, checking USB connection and start MTP communication.
https://github.com/viveris/uMTP-Responder
if BR2_PACKAGE_UMTPRD
config BR2_PACKAGE_UMTPRD_TAG
string "git version of umtprd package"
default "master"
help
Must be the name of the branch/tag :
https://github.com/viveris/uMTP-Responder
endif #BR2_PACKAGE_UMTPRD
umtprd.mk
$ cat umtprd.mk
UMTPRD_VERSION = $(BR2_PACKAGE_UMTPRD_TAG)
UMTPRD_SITE_METHOD = git
UMTPRD_SITE = https://github.com/viveris/uMTP-Responder
define UMTPRD_BUILD_CMDS
$(MAKE) CFLAGS="-DUSE_SYSLOG" CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(#D)
endef
define UMTPRD_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(#D)/umtprd $(TARGET_DIR)/usr/bin
$(INSTALL) -D -m 0755 $(#D)/conf/umtprd*.sh $(TARGET_DIR)/usr/bin
$(INSTALL) -D -m 0755 $(#D)/conf/S98uMTPrd $(TARGET_DIR)/etc/init.d
mkdir -p $(TARGET_DIR)/etc/umtprd
$(INSTALL) -D -m 0644 $(#D)/conf/umtprd.conf $(TARGET_DIR)/etc/umtprd/
endef
$(eval $(generic-package))
Patch
$ cat 0001-configuration.patch
diff -Naur a/conf/umtprd.conf b/conf/umtprd.conf
--- a/conf/umtprd.conf 2018-12-22 14:58:25.000000000 +0100
+++ b/conf/umtprd.conf 2019-01-10 10:31:06.069769073 +0100
## -11,8 +11,7 ##
#storage command : Create add a storage entry point. Up to 16 entry points supported
#Syntax : storage "PATH" "NAME"
-storage "/" "root folder"
-storage "/home" "home folder"
+storage "<path>" "<name>"
# Set the USB manufacturer string
## -20,11 +19,11 ##
# Set the USB Product string
-product "The Viveris Product !"
+product "<product_string>"
# Set the USB Serial number string
-serial "01234567"
+serial "<serial>"
# Set the USB interface string. Should be always "MTP"
First build
When I first execute make, the package is successfully downloaded, extracted, patched, built and installed.
$ make
>>> umtprd umtprd-0.9.7 Downloading
[...]
warning: refname 'umtprd-0.9.7' is ambiguous.
WARNING: no hash file for umtprd-umtprd-0.9.7.tar.gz
>>> umtprd umtprd-0.9.7 Extracting
[...]
>>> umtprd umtprd-0.9.7 Patching
Applying 0001-configuration.patch using patch:
patching file conf/umtprd.conf
>>> umtprd umtprd-0.9.7 Configuring
>>> umtprd umtprd-0.9.7 Building
[...]
>>> umtprd umtprd-0.9.7 Installing to target
[...]
>>> Finalizing target directory
[...]
>>> Sanitizing RPATH in target tree
[...]
>>> Copying overlay <path_to_overlay>
>>> Executing post-build script <post_build_script>
>>> Generating root filesystem image rootfs.tar
[...]
>>> Executing post-image script <post_image_script>
Later build
However if I run make again without removing the folder output/build/umtprd-umtprd-0.9.7 buildroot tries to extract and patch the sources again.
In that case the patch obviously fails, thus the compiling process is stopped and images are not generated.
$ make
WARNING: no hash file for umtprd-umtprd-0.9.7.tar.gz
>>> umtprd umtprd-0.9.7 Extracting
[...]
>>> umtprd umtprd-0.9.7 Patching
Applying 0001-configuration.patch using patch:
Error: duplicate filename '0001-configuration.patch'
Conflicting files are:
already applied: <path_to_patch>/0001-configuration.patch
to be applied : <path_to_patch>/0001-configuration.patch
package/pkg-generic.mk:191 : la recette pour la cible « <path_to_buildroot>/output/build/umtprd-"umtprd-0.9.7"/.stamp_patched » a échouée
make: *** [<path_to_buildroot>/output/build/umtprd-"umtprd-0.9.7"/.stamp_patched] Erreur 1
I have check inside the build directory and all .stamp files seems to be there so I don't understand why buildroot re-extract, re-patch and re-build the package since configuration and sources haven't changed.
$ ls -la output/build/umtprd-umtprd-0.9.7/.stamp_*
-rw-r--r-- 1 <user> <user> 0 janv. 10 14:58 output/build/umtprd-umtprd-0.9.7/.stamp_built
-rw-r--r-- 1 <user> <user> 0 janv. 10 14:58 output/build/umtprd-umtprd-0.9.7/.stamp_configured
-rw-r--r-- 1 <user> <user> 0 janv. 10 15:05 output/build/umtprd-umtprd-0.9.7/.stamp_downloaded
-rw-r--r-- 1 <user> <user> 0 janv. 10 15:05 output/build/umtprd-umtprd-0.9.7/.stamp_extracted
-rw-r--r-- 1 <user> <user> 0 janv. 10 14:58 output/build/umtprd-umtprd-0.9.7/.stamp_patched
-rw-r--r-- 1 <user> <user> 0 janv. 10 14:58 output/build/umtprd-umtprd-0.9.7/.stamp_target_installed
The problem can be solved by removing the build folder output/build/umtprd-umtprd-0.9.7 but I shouldn't have to do it, thus I would like to understand why buildroot is re-extracting and re-patching sources.
What did I do wrong here ?
You don't seem to be doing anything wrong, but indeed, Buildroot is not supposed to re-extract and re-patch this package. So there must be something happening between your two "make" invocations that cause this to happen.
Could you provide the full log (unmodified) of the following sequence of commands:
make
ls -la output/build/umtprd-umtprd-0.9.7/.stamp_*
make
Thanks.
You should change the following:
UMTPRD_VERSION = $(call qstrip,$(BR2_PACKAGE_UMTPRD_TAG))
The Kconfig variable BR2_PACKAGE_UMTPRD_TAG contains quotes, its value is e.g. "master" including the quotes. For make, quotes are nothing special. So in the dependency chain, it will look for a stamp file output/build/umtprd-"master"/.stamp_extracted. However, when the stamp file is created, it goes through the shell which removes the quotes, so the actual file created is output/build/umtprd-master. Thus, make thinks that the stamp file doesn't exist yet.
Note that it is not just the extraction that is repeated, also the download. However, in the download step there is an additional check that skips the download if the file-to-be-downloaded exists already.
I found that using a tarball archive avoid the package from beeing extracted and patched a second time.
Hopefully tags are available as tarball releases into this github repository.
Here is the .mk I have used in order to achieve it
$ cat umtprd.mk
################################################################################
#
# umtprd deamon for Davey Bickford board Base.
#
################################################################################
UMTPRD_SOURCE = $(BR2_PACKAGE_UMTPRD_TAG).tar.gz
UMTPRD_SITE = https://github.com/viveris/uMTP-Responder/archive
define UMTPRD_BUILD_CMDS
$(MAKE) CFLAGS="-DUSE_SYSLOG" CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(#D)
endef
define UMTPRD_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(#D)/umtprd $(TARGET_DIR)/usr/bin
$(INSTALL) -D -m 0755 $(#D)/conf/umtprd*.sh $(TARGET_DIR)/usr/bin
$(INSTALL) -D -m 0755 $(#D)/conf/S98uMTPrd $(TARGET_DIR)/etc/init.d
mkdir -p $(TARGET_DIR)/etc/umtprd
$(INSTALL) -D -m 0644 $(#D)/conf/umtprd.conf $(TARGET_DIR)/etc/umtprd/
endef
$(eval $(generic-package))
I think the problem comes from naming conventions as the following results seems to show
Downloading from archive ==> WORKS
Having dl/umtprd-0.9.7.tar.gz and output/build/umtprd
Downloading from tag ==> DOESN'T WORK
Having dl/umtprd-umtprd-0.9.7.tar.gz and output/build/umtprd-umtprd-0.9.7
I'm trying to download a tar.gz file from a github repo with curl, but it's evidently downloading plain ASCII and so I can't unzip or untar the file (as evidenced by the file command - see the third line of my stack trace below).
One other important detail is that this is running inside an AWS CodeBuild instance. However, I can download this with curl just fine on my mac and it is a proper tar.gz file.
Here's the command I'm running:
curl -Lk0s https://github.com/gohugoio/hugo/releases/download/v0.49/hugo_0.49_Linux-64bit.tar.gz -o /tmp/hugo.tar.gz
The full stack trace is:
[Container] 2018/12/03 05:39:44 Running command curl -Lk0s https://github.com/gohugoio/hugo/releases/download/v0.49/hugo_0.49_Linux-64bit.tar.gz -o /tmp/hugo.tar.gz
[Container] 2018/12/03 05:39:45 Running command file /tmp/hugo.tar.gz
/tmp/hugo.tar.gz: ASCII text, with no line terminators ***[NB. This is the output of the file command]***
[Container] 2018/12/03 05:39:45 Running command tar xvf /tmp/hugo.tar.gz -C /tmp
tar: This does not look like a tar archive
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
[Container] 2018/12/03 05:39:45 Command did not exit successfully tar xvf /tmp/hugo.tar.gz -C /tmp exit status 2
[Container] 2018/12/03 05:39:45 Phase complete: INSTALL Success: false
[Container] 2018/12/03 05:39:45 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: tar xvf /tmp/hugo.tar.gz -C /tmp. Reason: exit status 2
What am I doing wrong here?
-L works for me:
curl -L https://github.com/gohugoio/hugo/releases/download/v0.49/hugo_0.49_Linux-64bit.tar.gz -o /tmp/hugo.tar.gz
I tried it without any flags first and it downloaded the redirection page.
Added -L to follow redirects and the result was a well-formed, complete .tar.gz file that decompressed perfectly. The result was a folder with a few files in it:
$ ls -l
total 41704
-rw-r--r-- 1 xxxxxxxxxxx staff 11357 Sep 24 05:54 LICENSE
-rw-r--r-- 1 xxxxxxxxxxx staff 6414 Sep 24 05:54 README.md
-rwxr-xr-x 1 xxxxxxxxxxx staff 21328256 Sep 24 06:03 hugo
UPDATE: I didn't at first try your set of params (-Lk0s) assuming it wouldn't work for me either. But I just now tried it and it works for me. I get the same .tar.gz that I got with -L and it decompresses accurately. Please cat the contents of the text file that gets downloaded and show at least some of it here. It's probably an error of some sort being sent back as plain text or html.
I'm a bit confused with the -c flag using bunzip2.
The following line of code works well:
ls -l
-> -rw-r--r-- 1 root root 163 Oct 25 13:06 access_logs.tar.bz2
bunzip2 -c access_logs.tar.bz2 | tar -t
When I would attempt to use this code without the -c flag:
bunzip2 access_logs.tar.bz2 | tar -t
I get the message:
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
But when showing the list ls -l:
-rw-r--r-- 1 root root 10240 Oct 25 13:06 access_logs.tar
Documentation says:
The left side of the pipeline is bunzip –c access_logs.tbz, which
decompresses the file but the (-c option) sends the output to the
screen. The output is redirected to tar –t.
According to the manual:
-c --stdout
Compress or decompress to standard output.
It seems that the decompression also works without the -c flag?
I'm confused about what you're confused about. You observed the answers to your questions, as well as read it in the documentation.
Without -c, bunzip2 will decompress the xx.gz file and save the results as the file xx. With the -c, it will not create a file, but rather send the result to stdout. If you have a pipe, |, then instead of being printed to the terminal (which would be a mess), it becomes the input to the program on the right side of the pipe.
You cant check file information type:
file access_logs.tar.bz2
Check manual: link
I wanted read coreutils info, but I could not find it. Now, I wonder where the info documents in my computer (mac or linux). I want to know how I can install info files.
Thank you,
SangChul
I suppose you entered info coreutils on the command line, which returned the info top directory instead of the coreutils info page? In that case, here is what I would do (on ubuntu 15.10, and probably on any GNU/Linux OS).
Download the coreutils info document from the gnu project:
wget http://www.gnu.org/software/coreutils/manual/coreutils.info.tar.gz
Extract the (compressed) tar archive that you downloaded:
tar xf coreutils.info.tar.gz
Re-compress the resulting info file:
gzip coreutils.info
Prepare the resulting file with the right attributes:
chmod 644 coreutils.info.gz
sudo chown root:root coreutils.info.gz
and move it into the info directory:
sudo mv coreutils.info.gz /usr/share/info
Now, the command
info coreutils
should work.
If you want to have a hypertext link to coreutils in the info top page then do:
sudo install-info --info-dir=/usr/share/info --info-file=/usr/share/info/coreutils.info.gz
I find this somewhere that I do not know where it was.
strings `which info` | grep /info
This would print out some default info directories that had been compiled with the info command. One can also export a shell variable called INFOPATH with info directories you want.