pseudo 1.6.0

pseudo 1.6.0 is a moderately significant update. It should actually be better in a number of ways. Performance may be slightly improved by changes to how debugging messages are generated. Debugging output is dramatically improved. Extended attributes are supported.

I don't really feel this can be tested adequately without pretty broad exposure, so I'm leaving the 1.5.1 recipe in-tree in this update, so people can go back if they have problems.

The following changes since commit 6acd4fc8d5e642b5c6c75fcc40dd8f37caf7ddcf:

lib/oe/image.py: check the rootfs size against IMAGE_ROOTFS_MAXSIZE (2014-07-10 17:37:41 +0100)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib seebs/pseudo16
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/pseudo16

Peter Seebach (1):
pseudo_1.6.0.bb: uprev to pseudo 1.6

 meta/recipes-devtools/pseudo/pseudo.inc      |    4 ----
 meta/recipes-devtools/pseudo/pseudo_1.5.1.bb |    4 ++++
 meta/recipes-devtools/pseudo/pseudo_1.6.0.bb |   10 ++++++++++
 meta/recipes-devtools/pseudo/pseudo_git.bb   |    4 ++--
 4 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.6.0.bb

This uprevs pseudo to 1.6. This merges in all of the existing fixes, and also adds partial support for extended attributes, including storing arbitrary extended attributes in the database, and also interpreting the posix permissions ACLs as chmod requests.

---
 meta/recipes-devtools/pseudo/pseudo.inc      |    4 ----
 meta/recipes-devtools/pseudo/pseudo_1.5.1.bb |    4 ++++
 meta/recipes-devtools/pseudo/pseudo_1.6.0.bb |   10 ++++++++++
 meta/recipes-devtools/pseudo/pseudo_git.bb   |    4 ++--
 4 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.6.0.bb

index 42738ab..cf321ed 100644
@@ -9,10 +9,6 @@ SECTION = "base"
 LICENSE = "LGPL2.1"
 DEPENDS = "sqlite3"
 
-SRC_URI_append_class-nativesdk = " file://symver.patch"
-
-SRC_URI_append_class-native = " file://symver.patch"
-
 FILES_${PN} = "${prefix}/lib/pseudo/lib*/libpseudo.so ${bindir}/* ${localstatedir}/pseudo ${prefix}/var/pseudo"
 FILES_${PN}-dbg += "${prefix}/lib/pseudo/lib*/.debug"
 INSANE_SKIP_${PN} += "libdir"

index 47291fd..8d562ec 100644
@@ -10,6 +10,10 @@ SRC_URI = " \
     file://pseudo-fchmodat-permissions.patch \
 "
 
+SRC_URI_append_class-nativesdk = " file://symver.patch"
+
+SRC_URI_append_class-native = " file://symver.patch"
+
 SRC_URI[md5sum] = "5ec67c7bff5fe68c56de500859c19172"
 SRC_URI[sha256sum] = "3b896f592f4d568569bd02323fad2d6b8c398e16ca36ee5a8947d2ff6c1d3d52"
 

new file mode 100644
index 0000000..e92c4d7
@@ -0,0 +1,10 @@
+require pseudo.inc
+
+SRC_URI = " \
+    http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2 \
+"
+
+SRC_URI[md5sum] = "78c3f8aa8efe8cf15a2b21261174e3b6"
+SRC_URI[sha256sum] = "e24f526443b31c3292ec5ba04950d230b5388e8983c7e192e9e489c007f3dba3"
+
+PSEUDO_EXTRA_OPTS ?= "--enable-force-async"

index 66fc85f..ef258fa 100644
@@ -1,7 +1,7 @@
 require pseudo.inc
 
-SRCREV = "b9eb2b5633b5a23efe72c950494728d93c2b5823"
-PV = "1.5.1+git${SRCPV}"
+SRCREV = "512b84fb539c970464a93107995edf0e775d13fa"
+PV = "1.6.0+git${SRCPV}"
 
 DEFAULT_PREFERENCE = "-1"
 

1.7.1

The extended attributes code means adding build-dependency on attr.

Which leads onto the discussion as to whether we add attr-native to the build for pseudo-native, or use ASSUME_PROVIDED and document that the host needs to provide it.

Ross

Well, since my builds worked without adding the dependency, I guess I would go with ASSUME_PROVIDED since that was what I did, apparently.

I admit to not having been aware that it was possible to lack xattr support in a modernish Linux.

-s

Listen, get this.  Nobody with a good compiler needs to be justified.

The issue is the lack of the xattr headers from what I saw, not the xattr support itself and we're missing what looks like a single define. For the complexity, I did wonder if we should ship a default...

Adding in the xattr-native dependency may well be easier than updating the docs on dependencies on all the different distros.

Cheers,

Richard

Hmm. We could in theory add a test to the configure script for the header, and just hard-code that value in a couple of places. I don't think we actually need the header for much else. I don't know how stable that value is across distros or anything, though. I assume it's pretty stable.

The main thing is that I've tried to avoid making dependencies on compile checks like "can I compile something using this header" because those are annoying and slow.

-s

Listen, get this.  Nobody with a good compiler needs to be justified.

Thinking about this more, the default alone wouldn't do it, I'd have to either drop the header or make it conditional, which I'd sort of prefer not to do. Checks for header availability are a pain.

So should I resubmit with the attr-native dependency? I don't know how much build time that will impose, but I assume not very much.

-s

Listen, get this.  Nobody with a good compiler needs to be justified.

Please do, the build time for attr-native is minimal in the scheme of things.

Ross