Bug 7913

Summary:	tar now being grumpy about -ps options incorrectly used with -c
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Christopher Cox <chrisc>
Component:	core	Assignee:	Christopher Cox <chrisc>
Status:	VERIFIED INVALID	QA Contact:	Bogdan Alexandru Voiculescu <bogdanx.a.voiculescu>
Severity:	major
Priority:	Medium	CC:	bogdanx.a.voiculescu, meta.mr.watcher, meta.watcher, poky.bs.watcher, poky.watcher, richard.purdie, ross.burton
Version:	unspecified
Target Milestone:	1.9
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Christopher Cox 2015-06-20 15:44:28 UTC

Files effected:
 meta/classes/staging.bbclass
 bitbake/lib/bb/fetch2/__init__.py
 meta/lib/oe/path.py
 meta/lib/oe/path.pyc
 meta/classes/package.bbclass
 meta/classes/libc-package.bbclass

Description of error:
 Newer versions of tar will complain (fail) if the -ps options are used in conjunction with the -c (create) option. The -ps options seem to belong in the -x (extraction) phase.

Example:
  tar -cf - -C "$src" -ps . | tar -xf - -C "$dest"
 becomes
  tar -cf - -C "$src" . | tar -xpsf - -C "$dest"

Behaviour:
DEBUG: Executing python function sstate_task_prefunc
DEBUG: Python function sstate_task_prefunc finished
DEBUG: Executing python function do_populate_sysroot
DEBUG: Executing shell function sysroot_stage_all
tar: --same-order option cannot be used with -c
Try 'tar --help' or 'tar --usage' for more information.
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
DEBUG: Python function do_populate_sysroot finished
ERROR: Function failed: sysroot_stage_all (see /u/work/yoctoProject/raspberryPiB
uild/tmp/work/x86_64-linux/quilt-native/0.60-r0/temp/log.do_populate_sysroot.171
88 for further information)

Comment 1 Richard Purdie 2015-06-25 14:38:01 UTC

Which release are you seeing this with? This was fixed in master and at least a couple of releases back if I recall correctly?

Comment 2 Richard Purdie 2015-06-25 14:39:55 UTC

Please let us know which release this was with.

Comment 3 Ross Burton 2015-06-25 14:46:45 UTC

The error includes the path quilt-0.60. This was removed in commit 7579e19:

commit 7579e19c2b67819a6b5b1324567564d1e4125bdc
Author: Chong Lu <Chong.Lu@windriver.com>
Date:   Fri Dec 27 18:17:40 2013 +0800

    quilt: upgrade to 0.61

So what releases did that come from:

$ git tag --contains 7579e19c2b67819a6b5b1324567564d1e4125bdc|grep yocto-
yocto-1.6
yocto-1.6.1
yocto-1.6.2
yocto-1.6.3
yocto-1.7
yocto-1.7.1
yocto-1.7.2
yocto-1.8

I'm guessing the reporter is using 1.5, which is "quite" old now.

Comment 4 Ross Burton 2015-06-25 14:49:43 UTC

Fixed in oe-core 3d5a6d0a480a0fa98260a3b3ffc71b8d9e3e58af:

Date:   Fri Oct 11 23:01:54 2013 +0100
    classes: tar 1.27 fixes

    tar version 1.27 returns:

    tar: --same-order option cannot be used with -c

    with the commandlines we have been using. We can remove the -s option (which
    is --same-order) to remove the error.

Comment 5 Christopher Cox 2015-06-25 15:51:19 UTC

Great question. I utilized: 

  git clone git://git.yoctoproject.org/poky yoctoProject

to retrieve the project instead of a tarball.

I found __version__=1.17.0 in the bitbake script and 1.9x in the Bitbake ChangeLog.

What would be the best method of determining the projects version?

Comment 6 Ross Burton 2015-06-25 15:54:53 UTC

Then "git show" will tell you what commit you're using, and we can use that to determine what release.

But the fact remains that your build is using quilt 0.60, which was removed in 2013, so you're not using master, or 1.8, or 1.7, or 1.6.  Did you switch to a branch after cloning?

Comment 7 Christopher Cox 2015-06-26 21:50:21 UTC

Gad's, was just following the authors instructions without understanding git.
I jumped back to commit 4a36a32567ecfbc7ce7b967803e6e23314953ef5

I thought I was helping by identifying the issue and files involved. I did not know I was utilizing ancient code.

Thanks for the rapid response. 

RESOLVED, FIXED (Long ago)

Comment 8 Ross Burton 2015-06-27 22:26:50 UTC

No problem - always good to file an issue! Thanks for being responsive and getting this closed smoothly.

Also that oe-core commit is *old*, looks like it was part of 1.4.1.  You might want to find newer instructions, or just attempt what you're doing with the latest releases.

Comment 9 Bogdan Alexandru Voiculescu 2015-09-09 11:21:10 UTC

this was a bug fixed "RESOLVED, FIXED (Long ago)"
so it was not a regression, because the reporter used an older git.