Re: [OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 20:52, Robert Yang wrote:


And when remove file2, but file1's permission is changed, it should
be considered as a bug.


I'm not sure of that. My interpretation would be that hard linking under 
pseudo to files which weren't created under the same pseudo database is
user error; that's not how the database is intended to work. That said, 
it's pretty trivial to add the things to it.


Although I'd like to know more about the use cases for these, because it
occurs to me that the qualifier "same pseudo database" points out 
another

possible failure mode: Would any of those files that are being linked to
be getting linked to from *more than one* pseudo database? Because if 
they were, that would be a thing I haven't been planning for and I don't 
know

whether it'd work sanely.

-s
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 18:36, Mark Hatle wrote:

Would it makes sense to track the xattrs and linked files and such 
using some

type of inode reference (virtual or otherwise)?

Since in the case of a hard link, on a normal Linux style filesystem, 
there will
be a single inode that has a reference count higher then 1.  Thus you 
can know
the modes, xattrs, etc for that inode.. then the file points to the 
inode with
reference counts.  (this might require a rework on internal 
structures.. but

also might solve the problem.)


Well, that *is* how we track xattrs. And everything else, we do use 
device and inode, but, we maintain one row for each path, and delete the 
individual path rows.


This gets back to one of the original design goals, which was to avoid
all the horrific things that happen to fakeroot because it's only 
tracking
device/inode. We *want* the multiple path entries so we can report 
apparent database problems.


(Side note: There's some performance optimizations that have reduced 
stability/robustness, and I have plans involving making pseudo smarter
about those, and/or allowing configuration to prefer being more 
cautious.)


-s
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 17:55, Richard Purdie wrote:


The trouble is that for speed, we do create trees of hardlinked files
and play games with those and sstate amongst other things.


Yeah. One concern would be ownership: If the things we're hardlinking to
weren't created/tracked by pseudo initially, they're going to show up as 
owned by the actual user doing the build. So hardlinks to them will 
also.


So it may be more reasonable to just create those things under pseudo
also, in which case they're already tracked.


Its
obviously faster to do this than make physical copies of the files.
Given what I know of the code paths, I suspect that tracking the 
source

of a hardlink would make life much easier for us. Obviously we can go
and start adding "chown -R" calls everywhere but that seems a little
ugly to me and doesn't do performance any favours.



Is there any significant downside if we do track the source of
hardlinks?


Hmm. I'm not sure. It'll make things more complicated, but only 
marginally. The net impact would be fewer surprises in common cases, but 
the uncommon cases would get *really* weird. But it seems reasonable.

(At least for the case where there isn't an existing entry.) I'll
poke at this a bit, I think.

-s
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] systemd: split systemd-container

[ChenQi]

ping

On 07/14/2016 11:25 AM, Chen Qi wrote:

The following changes since commit da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6:

   useradd-staticids: use map() instead of imap() (2016-07-12 23:11:57 +0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd-container
   
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-container

Chen Qi (1):
   systemd: split systemd-container

  meta/recipes-core/systemd/systemd_230.bb | 35 +---
  1 file changed, 32 insertions(+), 3 deletions(-)



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta][PATCH] python-native: Compute prefix based on staging area

[Kyle Russell]

python-native should not assume that prefix points to the native
sysroot, and instead use STAGING_LIBDIR to determine prefix, since
python-native may be used to compile non-native python modules for the
target sysroot.

Computing an incorrect prefix causes unintended build behavior,
especially on setuptools packages.  A setuptools package may declare
setup_requires dependencies in its setup.py.  setuptools makes sure
these setup_requires dependencies are available during do_compile.
The bitbake recipes for these setuptools packages also express these
setup_requires dependencies as DEPENDS.

Since python's sysconfig computes the prefix from where python-native
was compiled, setuptools only searches the native sysroot for packages
that satisfy its setup_requires dependencies, while bitbake satisfies
its DEPENDS for the packages by populating the target sysroot.  Since
setuptools was being mislead by prefix on where to look for its
dependencies, it would try to download pypi packages into the compiling
package's workdir when it didn't find them in the native sysroot.
Instead, prefix should instruct setuptools to look in the target sysroot
to satisfy its setup_requires dependencies so setuptools can take
advantage of the DEPENDS satisfied by bitbake.

Note that a similar approach has already been patched for the
distutils.sysconfig module in python-native, but sysconfig was moved out
of distutils in Python 2.7 and >= 3.2, which appears to be why the previous
patch does not impact setuptools.

Signed-off-by: Kyle Russell 
---
 ...g.py-prefix-should-be-inside-staging-area.patch | 32 ++
 .../python/python-native_2.7.11.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python-native/0001-sysconfig.py-prefix-should-be-inside-staging-area.patch

diff --git 
a/meta/recipes-devtools/python/python-native/0001-sysconfig.py-prefix-should-be-inside-staging-area.patch
 
b/meta/recipes-devtools/python/python-native/0001-sysconfig.py-prefix-should-be-inside-staging-area.patch
new file mode 100644
index 000..27f191f
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python-native/0001-sysconfig.py-prefix-should-be-inside-staging-area.patch
@@ -0,0 +1,32 @@
+From 47e1df99c073ba50213f5b5f78ea36828668001f Mon Sep 17 00:00:00 2001
+From: Kyle Russell 
+Date: Thu, 28 Jul 2016 09:15:45 -0400
+Subject: [PATCH] sysconfig.py: prefix should be inside staging area
+
+Similar to the distutils fix for correct prefix handling for the sysroot
+layout, but applies to the sysconfig API moved out of distutils in
+Python 2.7 and >=3.2.
+
+Upstream-Status: Inappropriate [embedded specific]
+---
+ Lib/sysconfig.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Lib/sysconfig.py b/Lib/sysconfig.py
+index ffc55ba..1cb4107 100644
+--- a/Lib/sysconfig.py
 b/Lib/sysconfig.py
+@@ -89,8 +89,8 @@ _SCHEME_KEYS = ('stdlib', 'platstdlib', 'purelib', 
'platlib', 'include',
+ _PY_VERSION = sys.version.split()[0]
+ _PY_VERSION_SHORT = sys.version[:3]
+ _PY_VERSION_SHORT_NO_DOT = _PY_VERSION[0] + _PY_VERSION[2]
+-_PREFIX = os.path.normpath(sys.prefix)
+-_EXEC_PREFIX = os.path.normpath(sys.exec_prefix)
++_PREFIX = '/'.join(os.environ['STAGING_LIBDIR'].split('/')[:-1])
++_EXEC_PREFIX = '/'.join(os.environ['STAGING_LIBDIR'].split('/')[:-1])
+ _CONFIG_VARS = None
+ _USER_BASE = None
+ _PYTHONBUILDDIR = os.environ.get("PYTHONBUILDDIR", None)
+-- 
+1.9.3
+
diff --git a/meta/recipes-devtools/python/python-native_2.7.11.bb 
b/meta/recipes-devtools/python/python-native_2.7.11.bb
index 31192ca..d7160b0 100644
--- a/meta/recipes-devtools/python/python-native_2.7.11.bb
+++ b/meta/recipes-devtools/python/python-native_2.7.11.bb
@@ -18,6 +18,7 @@ SRC_URI += "\
 file://parallel-makeinst-create-bindir.patch \
 file://revert_use_of_sysconfigdata.patch \
 file://avoid_parallel_make_races_on_pgen.patch \
+
file://0001-sysconfig.py-prefix-should-be-inside-staging-area.patch \
"
 S = "${WORKDIR}/Python-${PV}"
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta][PATCH] python-native: Compute prefix based on staging area

[Kyle Russell]

This patch is based off the jethro branch, which is where I encountered the 
issue.
I haven't had a chance to check this on master yet, so it's not clear to me 
whether
or not this is still an issue there.  I was hoping for some feedback on whether 
or
not this patch would be feasible for jethro, and whether or not it has already 
been
addressed in newer versions of the python-native recipe.

Kyle Russell (1):
  python-native: Compute prefix based on staging area

 ...g.py-prefix-should-be-inside-staging-area.patch | 32 ++
 .../python/python-native_2.7.11.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python-native/0001-sysconfig.py-prefix-should-be-inside-staging-area.patch

-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert "lttng-tools: filter random filename of ptest output"

[Nathan Lynch]

On 08/01/2016 08:33 PM, Paul Eggleton wrote:
> Hi Nathan,
> 
> On Fri, 22 Jul 2016 15:53:46 Nathan Lynch wrote:
>> This reverts commit 29a8c45be2862be02afe2ebbc5c026a42f351990.
>>
>> A few things wrong with this change:
>>
>> 1. It patches a patch (runtest-2.4.0.patch).
>> 2. It introduces deviations from the desired ptest output format.
>> 3. It discards PASS: lines from the test output; I *want* to see those.
>> 4. The upstream status of "pending" is incorrect; I do not see this
>>patch on the lttng-dev mailing list (not that it would apply anyway).
> 
> FYI, "pending" doesn't mean "pending acceptance", it means "pending 
> determination" so it was probably correct here - not that that makes any 
> difference to the other reasons for reverting. "Pending" is perhaps a bit of 
> a 
> poor term though. In any event the reference is here in case you need it:
> 
>   
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

Thanks for the pointer, I think I was indeed conflating pending and
submitted.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Robert Yang]

On 08/02/2016 06:55 AM, Richard Purdie wrote:

On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote:

On 1 Aug 2016, at 15:01, Richard Purdie wrote:


No, we're actually expecting it to retain the mode it was given via
the
hardlink under pseudo.

This is what a real world system would do and in this case we could
track it via pseudo since pseudo is loaded when the hardlink is
created. It would be unreasonable for pseudo to track all hardlinks
but
tracking ones created under it does seem reasonable?


Hmm. Well, strictly speaking, the link created under pseudo *does*
get
tracked. Hmm. But an implicit request to track also the thing linked
to
is not a horrible idea. Although you'd still be able to beat it:

$ touch file1
$ ln file1 file2
$ pseudo
# ln file2 file3
# chmod 777 file3
# rm file2 file3
# ls -l file1

The general case of "find everything this link also refers to" is
clearly out of scope.


Agreed.


  That said... Hmm. I think my main feeling is, if we want
to link to the file, and we want the changes to the linked file to
survive, we should probably either create that file under pseudo, or
explicitly claim it with pseudo when we start wanting to do the
tracking.
(You can trivially do this to a tree with chown -R root tree).


The trouble is that for speed, we do create trees of hardlinked files
and play games with those and sstate amongst other things. Its
obviously faster to do this than make physical copies of the files.
Given what I know of the code paths, I suspect that tracking the source
of a hardlink would make life much easier for us. Obviously we can go
and start adding "chown -R" calls everywhere but that seems a little
ugly to me and doesn't do performance any favours.

Is there any significant downside if we do track the source of
hardlinks?


AFAIK, no.

And when remove file2, but file1's permission is changed, it should
be considered as a bug.

// Robert



Cheers,

Richard





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert "lttng-tools: filter random filename of ptest output"

[Paul Eggleton]

Hi Nathan,

On Fri, 22 Jul 2016 15:53:46 Nathan Lynch wrote:
> This reverts commit 29a8c45be2862be02afe2ebbc5c026a42f351990.
> 
> A few things wrong with this change:
> 
> 1. It patches a patch (runtest-2.4.0.patch).
> 2. It introduces deviations from the desired ptest output format.
> 3. It discards PASS: lines from the test output; I *want* to see those.
> 4. The upstream status of "pending" is incorrect; I do not see this
>patch on the lttng-dev mailing list (not that it would apply anyway).

FYI, "pending" doesn't mean "pending acceptance", it means "pending 
determination" so it was probably correct here - not that that makes any 
difference to the other reasons for reverting. "Pending" is perhaps a bit of a 
poor term though. In any event the reference is here in case you need it:

  
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Mark Hatle]

On 8/1/16 5:55 PM, Richard Purdie wrote:
> On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote:
>> On 1 Aug 2016, at 15:01, Richard Purdie wrote:
>>
>>> No, we're actually expecting it to retain the mode it was given via
>>> the
>>> hardlink under pseudo.
>>>
>>> This is what a real world system would do and in this case we could
>>> track it via pseudo since pseudo is loaded when the hardlink is
>>> created. It would be unreasonable for pseudo to track all hardlinks
>>> but
>>> tracking ones created under it does seem reasonable?
>>
>> Hmm. Well, strictly speaking, the link created under pseudo *does*
>> get 
>> tracked. Hmm. But an implicit request to track also the thing linked
>> to 
>> is not a horrible idea. Although you'd still be able to beat it:
>>
>>  $ touch file1
>>  $ ln file1 file2
>>  $ pseudo
>>  # ln file2 file3
>>  # chmod 777 file3
>>  # rm file2 file3
>>  # ls -l file1
>>
>> The general case of "find everything this link also refers to" is 
>> clearly out of scope.
> 
> Agreed.
> 
>>  That said... Hmm. I think my main feeling is, if we want
>> to link to the file, and we want the changes to the linked file to
>> survive, we should probably either create that file under pseudo, or 
>> explicitly claim it with pseudo when we start wanting to do the 
>> tracking.
>> (You can trivially do this to a tree with chown -R root tree).
> 
> The trouble is that for speed, we do create trees of hardlinked files
> and play games with those and sstate amongst other things. Its
> obviously faster to do this than make physical copies of the files.
> Given what I know of the code paths, I suspect that tracking the source
> of a hardlink would make life much easier for us. Obviously we can go
> and start adding "chown -R" calls everywhere but that seems a little
> ugly to me and doesn't do performance any favours.
> 
> Is there any significant downside if we do track the source of
> hardlinks?

Would it makes sense to track the xattrs and linked files and such using some
type of inode reference (virtual or otherwise)?

Since in the case of a hard link, on a normal Linux style filesystem, there will
be a single inode that has a reference count higher then 1.  Thus you can know
the modes, xattrs, etc for that inode.. then the file points to the inode with
reference counts.  (this might require a rework on internal structures.. but
also might solve the problem.)

--Mark

> Cheers,
> 
> Richard
> 
> 
> 
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] multilib support on Jethro: populate_sdk help

[Nemicolopterus Crypticus]

Ok, I've made some progress.
I'm running
$bitbake lib32- -c populate_sdk

and it proceeds for a while.
We do have a few packages that are not ready to be built as 32-bit, and
those fail as compiler errors.

Is there a way to temporarily remove them from the list of packages to be
built?
Poking around I found DEFAULT_PREFERENCE*, but that looks like it's not
quite what I'm looking for.

Is there any easy way to quickly disable a particular package from an image
build?

* http://www.embeddedlinux.org.cn/OEManual/recipes_defaultpreference.html


On Fri, Jul 29, 2016 at 1:30 PM, Nemicolopterus Crypticus <
ncrypti...@gmail.com> wrote:

> Added: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10054
>
>
> Please let me know if I can try anything else or provide more info.
>
> In the meantime, I'm going to try to disable multilib, and only build the
> ARMv7 version of the SDK.
>
>
> On Fri, Jul 29, 2016 at 12:07 PM, Khem Raj  wrote:
>
>>
>> On Jul 29, 2016, at 10:48 AM, Nemicolopterus Crypticus <
>> ncrypti...@gmail.com> wrote:
>>
>> Hello all,
>>
>> We are having issues with our generated SDK files. We're using the jethro
>> branch, and have enabled multilib (see relevant portion of local.conf
>> below).
>>
>> I can succesfully run the command to generate the SDK:
>> $ bitbake  -c populate_sdk
>>
>> But the output is incorrect. *While the aarch sysroots look good, the
>> sysroots for arm are completely missing. The environment setup script ends
>> up pointing to non-existent compilers. *Please let me know if you need
>> more information!
>>
>>
>> Thanks for report. It will be good if you can open a bugzilla entry for
>> this. So it can be tracked.
>>
>>
>> Steps to reproduce:
>> $ bitbake  -c populate_sdk
>> $ cp tmp/deploy/sdk/.sh /test/directory
>> $ cd /test/directory
>> $ bash .sh
>> $ ls sysroots/
>> aarch64-poky-linux/   x86_64-pokysdk-linux/
>>
>> Note the missing ARM directories.
>>
>> Also, the setup script for arm sets this as the command for compiler:
>>  12 export CC="arm-pokymllib32-linux-gnueabi-gcc
>>
>> But that compiler doesn't exist anywhere in the folder where I installed
>> everything, or environment!
>>
>> So it appears that it's not completely or correctly packaging everything
>> for ARMv7.
>>
>> The documentation does mention some environment variables
>> ,
>> but it's not clear how those related to multilib.
>>
>> For instance, none of our recipes have "SDKIMAGE_FEATURES" defined, but
>> clearly the aarch64 sysroots are getting populated correctly (we
>> succesfully compiled and ran a simple hello world).
>>
>> *Can anyone point me to an example, or discuss a successful use of
>> "multilib" on the Jethro branch (given desparate brainstorming below),
>> share some more verbose documentation, or ask follow-up questions?*
>>
>>
>> _
>> Desperate brainstorming below:
>> I did find this years-old patch:
>> https://patchwork.openembedded.org/patch/30941/
>> Notably, the do_populate_sdk method in
>> poky/meta/classes/populate_sdk_base.bbclass iterates over the values listed
>> in the MULTILIB_VARIANTS variable:
>>
>> +variants = d.getVar("MULTILIB_VARIANTS", True) or ""+   for item in 
>> variants.split():+  # Load overrides from 'd' to avoid having to 
>> reset the value...+overrides = d.getVar("OVERRIDES", False) 
>> + ":virtclass-multilib-" + item+   localdata.setVar("OVERRIDES", 
>> overrides)+   bb.data.update_data(localdata)+ 
>> bb.build.exec_func("create_sdk_files", localdata)
>>
>>
>>
>> The latest version in Jethro does not have anything equivalent to that,
>> but I did not dig deeply into the code or the commit history.
>>
>>
>>
>>
>> __
>> More data:
>>
>> local.conf relevant section:
>> #
>> # Multilib configuration
>> #
>> # This sets any packages preprended with lib32- to be built with
>> # the armv7a tuning (32 bit) instead of 64 bit aarch.
>> #
>> require conf/multilib.conf
>> MULTILIBS = "multilib:lib32"
>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Richard Purdie]

On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote:
> On 1 Aug 2016, at 15:01, Richard Purdie wrote:
> 
> > No, we're actually expecting it to retain the mode it was given via
> > the
> > hardlink under pseudo.
> > 
> > This is what a real world system would do and in this case we could
> > track it via pseudo since pseudo is loaded when the hardlink is
> > created. It would be unreasonable for pseudo to track all hardlinks
> > but
> > tracking ones created under it does seem reasonable?
> 
> Hmm. Well, strictly speaking, the link created under pseudo *does*
> get 
> tracked. Hmm. But an implicit request to track also the thing linked
> to 
> is not a horrible idea. Although you'd still be able to beat it:
> 
>   $ touch file1
>   $ ln file1 file2
>   $ pseudo
>   # ln file2 file3
>   # chmod 777 file3
>   # rm file2 file3
>   # ls -l file1
> 
> The general case of "find everything this link also refers to" is 
> clearly out of scope.

Agreed.

>  That said... Hmm. I think my main feeling is, if we want
> to link to the file, and we want the changes to the linked file to
> survive, we should probably either create that file under pseudo, or 
> explicitly claim it with pseudo when we start wanting to do the 
> tracking.
> (You can trivially do this to a tree with chown -R root tree).

The trouble is that for speed, we do create trees of hardlinked files
and play games with those and sstate amongst other things. Its
obviously faster to do this than make physical copies of the files.
Given what I know of the code paths, I suspect that tracking the source
of a hardlink would make life much easier for us. Obviously we can go
and start adding "chown -R" calls everywhere but that seems a little
ugly to me and doesn't do performance any favours.

Is there any significant downside if we do track the source of
hardlinks?

Cheers,

Richard




-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] dpkg: put start-stop-daemon into a separate package

[Joe Slater]

This is useful for supplying start-stop-daemon to
images that do not include busybox.

Signed-off-by: Joe Slater 
---
 meta/recipes-devtools/dpkg/dpkg.inc |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
b/meta/recipes-devtools/dpkg/dpkg.inc
index da6985c..5897801 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -72,4 +72,14 @@ RPROVIDES_update-alternatives-dpkg += "update-alternatives"
 PACKAGES += "${PN}-perl"
 FILES_${PN}-perl = "${libdir}/perl"
 
+# Split out start-stop-daemon to its own package.  Note that it
+# is installed in a different directory than the one used for
+# the bitbake version.
+#
+PACKAGES =+ "${PN}-start-stop"
+FILES_${PN}-start-stop = "${sbindir}/start-stop-daemon"
+
+RDEPENDS_${PN} += "${PN}-start-stop"
+
+
 BBCLASSEXTEND = "native"
-- 
1.7.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 15:01, Richard Purdie wrote:

No, we're actually expecting it to retain the mode it was given via 
the

hardlink under pseudo.

This is what a real world system would do and in this case we could
track it via pseudo since pseudo is loaded when the hardlink is
created. It would be unreasonable for pseudo to track all hardlinks 
but

tracking ones created under it does seem reasonable?


Hmm. Well, strictly speaking, the link created under pseudo *does* get 
tracked. Hmm. But an implicit request to track also the thing linked to 
is not a horrible idea. Although you'd still be able to beat it:


$ touch file1
$ ln file1 file2
$ pseudo
# ln file2 file3
# chmod 777 file3
# rm file2 file3
# ls -l file1

The general case of "find everything this link also refers to" is 
clearly out of scope. That said... Hmm. I think my main feeling is, if 
we want

to link to the file, and we want the changes to the linked file to
survive, we should probably either create that file under pseudo, or 
explicitly claim it with pseudo when we start wanting to do the 
tracking.

(You can trivially do this to a tree with chown -R root tree).

-s
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Richard Purdie]

On Mon, 2016-08-01 at 13:17 -0500, Seebs wrote:
> On 1 Aug 2016, at 3:57, Robert Yang wrote:
> 
> > How about we track the src when hardlink, for example:
> 
> I don't think I like this.
> 
> Fundamentally, the problem here is making a hard link to a file
> outside 
> of pseudo, and then modifying the file.
> 
> Consider, if you will, what happens if you replace "chmod 0777 file2"
> with:
>   # echo "# last line" >> file2
> 
> The problem here isn't pseudo's tracking; it's that we're making a
> hard 
> link to a file, modifying the hard link, deleting the hard link, and 
> expecting the original file to have the same attributes it had before
> this all happened.

No, we're actually expecting it to retain the mode it was given via the
hardlink under pseudo. 

This is what a real world system would do and in this case we could
track it via pseudo since pseudo is loaded when the hardlink is
created. It would be unreasonable for pseudo to track all hardlinks but
tracking ones created under it does seem reasonable?

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Snaps on Yocto/OpenEmbedded

[Otavio Salvador]

On Mon, Aug 1, 2016 at 4:14 PM, Simon Fels  wrote:
> On 01.08.2016 16:06, Bruce Ashfield wrote:
>>
>>
>> On Mon, Aug 1, 2016 at 7:32 AM, Simon Fels > > wrote:
>>
>> Hey everyone,
>>
>> I've worked on a new layer recently which brings snaps to any
>> Yocto/OpenEmbedded based system.
>>
>> If you have never heard about snaps yet you will find most details at
>> http://snapcraft.io/ but generally snaps are a new packaging format made
>> with security and fast updates in mind and allows applications to be
>> packaged once but run everywhere no matter of the distribution used or a
>> particular device type.
>>
>> The layer is currently named meta-snappy and is available at
>> https://github.com/morphis/meta-snappy
>>
>>
>> I had a quick browse this morning, and one question that jumped to mind was
>> if the oe-meta-go layer was causing problems for go/go-cross support ? I was
>> carrying some go/go-inc changes in meta-virtualization as well, but recent 
>> reports
>> are that oe-meta-go should work for everything now.
>>
>> I'm just asking, since it doesn't make sense for meta-virt or other layers to
>> continue to carry go build infrastructure when it could be unified.
> When I started to put meta-snappy together I ran into different problems
> with oe-meta-go and then reused what you put into meta-virt. I have the
> point on my TODO list to check if we can just switch to oe-meta-go
> rather than shipping go-cross on our own.

The meta-golang seems to be the most up to date one. Likely the best
one to try to converge as a single place for go-cross provider.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] grub2.inc: run autogen.sh before configure

[Burton, Ross]

On 1 August 2016 at 02:54,  wrote:

> When adding new source files from upstream the autogen.sh
> script needs to be run
>

This results in this change:

packages/corei7-64-poky-linux/grub-efi/grub-efi: PKGSIZE changed from
6787555 to 7524227 (+10%)
  * FILELIST: added "/usr/sbin/grub-sparc64-setup"
packages/corei7-64-poky-linux/grub-efi/grub-efi: FILELIST: added
"/usr/sbin/grub-sparc64-setup"
packages/corei7-64-poky-linux/grub/grub-dbg: PKGSIZE changed from 26159624
to 28829025 (+10%)
packages/corei7-64-poky-linux/grub/grub: PKGSIZE changed from 5942339 to
6679011 (+12%)
  * FILELIST: added "/usr/sbin/grub-sparc64-setup"
packages/corei7-64-poky-linux/grub/grub: FILELIST: added
"/usr/sbin/grub-sparc64-setup"

Is this intentional?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Snaps on Yocto/OpenEmbedded

[Simon Fels]

On 01.08.2016 16:06, Bruce Ashfield wrote:
> 
> 
> On Mon, Aug 1, 2016 at 7:32 AM, Simon Fels  > wrote:
> 
> Hey everyone,
> 
> I've worked on a new layer recently which brings snaps to any
> Yocto/OpenEmbedded based system.
> 
> If you have never heard about snaps yet you will find most details at
> http://snapcraft.io/ but generally snaps are a new packaging format made
> with security and fast updates in mind and allows applications to be
> packaged once but run everywhere no matter of the distribution used or a
> particular device type.
> 
> The layer is currently named meta-snappy and is available at
> https://github.com/morphis/meta-snappy
> 
> 
> I had a quick browse this morning, and one question that jumped to mind was
> if the oe-meta-go layer was causing problems for go/go-cross support ? I was
> carrying some go/go-inc changes in meta-virtualization as well, but recent 
> reports
> are that oe-meta-go should work for everything now.
> 
> I'm just asking, since it doesn't make sense for meta-virt or other layers to
> continue to carry go build infrastructure when it could be unified.
When I started to put meta-snappy together I ran into different problems
with oe-meta-go and then reused what you put into meta-virt. I have the
point on my TODO list to check if we can just switch to oe-meta-go
rather than shipping go-cross on our own.

regards,
Simon



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Snaps on Yocto/OpenEmbedded

[Simon Fels]

On 01.08.2016 15:55, Khem Raj wrote:
> Simon
> 
> On Mon, Aug 1, 2016 at 5:32 AM, Simon Fels  wrote:
>> Hey everyone,
>>
>> I've worked on a new layer recently which brings snaps to any
>> Yocto/OpenEmbedded based system.
>>
>> If you have never heard about snaps yet you will find most details at
>> http://snapcraft.io/ but generally snaps are a new packaging format made
>> with security and fast updates in mind and allows applications to be
>> packaged once but run everywhere no matter of the distribution used or a
>> particular device type.
>>
>> The layer is currently named meta-snappy and is available at
>> https://github.com/morphis/meta-snappy
>>
>> It comes with some basic instructions how to get quickly started. A
>> basic tour through the snap system and how to use it is available at
>> http://snapcraft.io/
>>
>> If you have any questions, bugs or contributions feel free to get in
>> contact with me.
> 
> Thank you for announcing your layer, I would also suggest that you
> publish the layer
> to layerindex as well. at layers.openembedded.org
> 
> since thats where most of folks go to find layers.

That was already on my list and is done now.

regards,
Simon




-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 3:57, Robert Yang wrote:


How about we track the src when hardlink, for example:


I don't think I like this.

Fundamentally, the problem here is making a hard link to a file outside 
of pseudo, and then modifying the file.


Consider, if you will, what happens if you replace "chmod 0777 file2"
with:
# echo "# last line" >> file2

The problem here isn't pseudo's tracking; it's that we're making a hard 
link to a file, modifying the hard link, deleting the hard link, and 
expecting the original file to have the same attributes it had before

this all happened.

-s
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

Trying to remember what my dad said about "Ask a silly question..."

Steve

On Mon, Aug 1, 2016 at 10:24 AM, Burton, Ross  wrote:
>
> On 1 August 2016 at 18:22, Stephen Arnold 
> wrote:
>>
>> That's actually not a bad idea, but I need to crank out another
>> abstract today (the deadline for special session snuck up on me).  We
>> kinda needed this for a project, but I think a tiny print server is
>> always useful.  What's your plan?
>
>
> Well my plan was:
>
> 1) say that someone should create meta-printing
> 2) watch someone create meta-printing
> 3) delete everything printing related in oe-core
>
> I can help a bit on (2) I guess...  Fan Xin, would you or anyone else at
> Fujitsu (as you clearly have interest here) be able to help?
>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Burton, Ross]

On 1 August 2016 at 18:22, Stephen Arnold 
wrote:

> That's actually not a bad idea, but I need to crank out another
> abstract today (the deadline for special session snuck up on me).  We
> kinda needed this for a project, but I think a tiny print server is
> always useful.  What's your plan?
>

Well my plan was:

1) say that someone should create meta-printing
2) watch someone create meta-printing
3) delete everything printing related in oe-core

I can help a bit on (2) I guess...  Fan Xin, would you or anyone else at
Fujitsu (as you clearly have interest here) be able to help?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

That's actually not a bad idea, but I need to crank out another
abstract today (the deadline for special session snuck up on me).  We
kinda needed this for a project, but I think a tiny print server is
always useful.  What's your plan?

Steve

On Mon, Aug 1, 2016 at 10:16 AM, Burton, Ross  wrote:
> Hi,
>
> On 1 August 2016 at 18:13, Stephen Arnold 
> wrote:
>>
>> Thanks, our timing is great (since I just did the same thing on
>> Saturday but didn't send anything to the list yet).  Still have some
>> testing to do to see if it actually works; recipes are here:
>>
>> https://github.com/sarnold/meta-small-arm-extra/commits/master
>
>
> Literally ten minutes ago I was wondering if there was any interest in
> ripping the obviously broken CUPS/ghostscript/etc out of oe-core and into a
> meta-printing layer that someone could actually maintain.  Would you be
> interested in that?
>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Burton, Ross]

Hi,

On 1 August 2016 at 18:13, Stephen Arnold 
wrote:

> Thanks, our timing is great (since I just did the same thing on
> Saturday but didn't send anything to the list yet).  Still have some
> testing to do to see if it actually works; recipes are here:
>
> https://github.com/sarnold/meta-small-arm-extra/commits/master
>

Literally ten minutes ago I was wondering if there was any interest in
ripping the obviously broken CUPS/ghostscript/etc out of oe-core and into a
meta-printing layer that someone could actually maintain.  Would you be
interested in that?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Stephen Arnold]

Thanks, our timing is great (since I just did the same thing on
Saturday but didn't send anything to the list yet).  Still have some
testing to do to see if it actually works; recipes are here:

https://github.com/sarnold/meta-small-arm-extra/commits/master

On Mon, Aug 1, 2016 at 4:01 AM, Fan Xin  wrote:
> The foomatic-filters community is inactive and foomatic-filter package is 
> unmaintained.
> (http://www.gossamer-threads.com/lists/gentoo/user/288184)
>
> The foomatic-rips is moved from foomatic-filters to cups-filters and
> maintained by cups-filters according to the cups-filter's NEWS.
> (http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/NEWS)
>
> Signed-off-by: Fan Xin 
> ---
>  .../cups-filters-1.8.2-disable-ijs.patch   | 65 
> ++
>  .../foomatic/cups-filters_1.8.3.bb | 34 +++
>  .../packagegroups/packagegroup-core-lsb.bb |  2 +-
>  3 files changed, 100 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
>  create mode 100644 meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
>
> diff --git 
> a/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
>  
> b/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
> new file mode 100644
> index 000..0a0a6ad
> --- /dev/null
> +++ 
> b/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
> @@ -0,0 +1,65 @@
> +=== modified file 'Makefile.am'
> +--- Makefile.am2016-02-10 15:16:33 +
>  Makefile.am2016-03-02 20:46:26 +
> +@@ -490,7 +490,6 @@
> +   bannertopdf \
> +   commandtoescpx \
> +   commandtopclx \
> +-  pdftoijs \
> +   sys5ippprinter \
> +   pdftops \
> +   pdftoraster \
> +@@ -499,6 +498,10 @@
> +   texttopdf \
> +   urftopdf \
> +   rastertopdf
> ++if ENABLE_IJS
> ++pkgfilter_PROGRAMS += \
> ++  pdftoijs
> ++endif
> + if ENABLE_GHOSTSCRIPT
> + pkgfilter_PROGRAMS += \
> +   gstoraster
> +@@ -846,9 +849,12 @@
> +   ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd \
> +   ppd/Generic-PDF_Printer-PDF.ppd \
> +   ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd \
> +-  ppd/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd \
> +   ppd/Ricoh-PDF_Printer-PDF.ppd \
> +   ppd/textonly.ppd
> ++if ENABLE_IJS
> ++ppd_DATA += \
> ++  ppd/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd
> ++endif
> + if ENABLE_GHOSTSCRIPT
> + ppd_DATA += \
> +   ppd/pxlcolor.ppd \
> +=== modified file 'configure.ac'
> +--- configure.ac   2016-02-11 13:59:52 +
>  configure.ac   2016-03-02 21:18:05 +
> +@@ -443,7 +443,7 @@
> + ])
> + PKG_CHECK_MODULES([FREETYPE], [freetype2], [AC_DEFINE([HAVE_FREETYPE_H], 
> [1], [Have FreeType2 include files])])
> + PKG_CHECK_MODULES([FONTCONFIG], [fontconfig >= 2.0.0])
> +-PKG_CHECK_MODULES([IJS], [ijs])
> ++PKG_CHECK_MODULES([IJS], [ijs], [have_ijs=yes], [have_ijs=no])
> + PKG_CHECK_MODULES([POPPLER], [poppler >= 0.18])
> + PKG_CHECK_MODULES([ZLIB], [zlib])
> + AC_DEFINE([HAVE_LIBZ], [], [Define that we use zlib])
> +@@ -489,6 +489,15 @@
> +   [enable_ghostscript="$enableval"],
> +   [enable_ghostscript=yes]
> + )
> ++AC_ARG_ENABLE([ijs],
> ++  [AS_HELP_STRING([--disable-ijs], [Disable filters using IJS.])],
> ++  [enable_ijs="$enableval"],
> ++  [enable_ijs=yes]
> ++)
> ++AS_IF([test "x$enable_ijs" = "xyes" -a "x$have_ijs" != "xyes"], [
> ++   AC_MSG_ERROR([IJS not found, but requested.])
> ++])
> ++AM_CONDITIONAL(ENABLE_IJS, test "x$enable_ijs" = "xyes")
> + AC_ARG_WITH([pdftops],
> +   [AS_HELP_STRING([--with-pdftops=value], [Set which pdftops to use 
> (gs,pdftops,pdftocairo,acroread,hybrid).])],
> +   [with_pdftops="$withval"],
> +
> diff --git a/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb 
> b/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
> new file mode 100644
> index 000..4eef7ef
> --- /dev/null
> +++ b/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
> @@ -0,0 +1,34 @@
> +SUMMARY = "OpenPrinting printer support - filters"
> +DESCRIPTION = "CUPS is a standards-based, open source printing system \
> +developed by Apple Inc. for Mac OS® X and other UNIX®-like operating 
> systems. \
> +CUPS uses the Internet Printing Protocol ("IPP") and provides System V and \
> +Berkeley command-line interfaces, a web interface, and a C API to manage 
> printers \
> +and print jobs. \
> + \
> +This package consists of filters used by the printer spoolers \
> +to convert the incoming PostScript data into the printer's native \
> +format using a printer-specific, but spooler-independent PPD file. \
> +"
> +
> +DEPENDS += "cups tiff lcms freetype fontconfig poppler qpdf"
> +PR = "r0"
> +
> +LICENSE = "GPLv2 & LGPLv2 & MIT & GPLv2+ & GPLv3"
> +LIC_FILES_CHKSUM = 
> 

Re: [OE-core] [PATCH 2/5] cronie: upgrade to 1.5.1

[Burton, Ross]

On 1 August 2016 at 17:35, Alejandro Hernandez <
alejandro.hernan...@linux.intel.com> wrote:

> Interesting, it didnt break on my build, I'll dig up whats going on
>

You didn't do a build with PAM enabled (DISTRO_FEATURES_append=" pam").

I usually have PAM enabled locally but forgot.  It's worth checking if the
patch needs to be PAM-specific or if we're safe to always apply it.  As
it's patching PAM configuration I expect we can always apply it as it won't
be installed if PAM is disabled.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] cronie: upgrade to 1.5.1

[Alejandro Hernandez]

On 07/29/2016 01:49 AM, Richard Purdie wrote:

On Wed, 2016-07-27 at 21:52 +, Alejandro Hernandez wrote:

Signed-off-by: Alejandro Hernandez <
alejandro.hernan...@linux.intel.com>
---
  meta/recipes-extended/cronie/{cronie_1.5.0.bb => cronie_1.5.1.bb} |
4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
  rename meta/recipes-extended/cronie/{cronie_1.5.0.bb =>
cronie_1.5.1.bb} (95%)

diff --git a/meta/recipes-extended/cronie/cronie_1.5.0.bb
b/meta/recipes-extended/cronie/cronie_1.5.1.bb
similarity index 95%
rename from meta/recipes-extended/cronie/cronie_1.5.0.bb
rename to meta/recipes-extended/cronie/cronie_1.5.1.bb
index 697501a..99b2bb5 100644
--- a/meta/recipes-extended/cronie/cronie_1.5.0.bb
+++ b/meta/recipes-extended/cronie/cronie_1.5.1.bb
@@ -23,8 +23,8 @@ SRC_URI = "
https://fedorahosted.org/releases/c/r/cronie/cronie-${PV}.tar.gz \
  PAM_SRC_URI = "file://crond_pam_config.patch"
  PAM_DEPS = "libpam libpam-runtime pam-plugin-access pam-plugin
-loginuid"
  
-SRC_URI[md5sum] = "9db75e1884d83a45e002d145c6c54d45"

-SRC_URI[sha256sum] =
"9cf0e3f4f5042a9c09413d62c8e0c055e12401f70b112465f0f81f2c84ebfb3f"
+SRC_URI[md5sum] = "910e6effcc032998b0a49fbd46322e18"
+SRC_URI[sha256sum] =
"6c73666102a6b5d35e2eaf1bd06925f2d4b0cef8d3323c37286dda3089a85338"
  
  inherit autotools update-rc.d useradd systemd

https://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/buil
ds/841/steps/BuildImages/logs/stdio

and it killed multiple other builds:

http://errors.yoctoproject.org/Errors/Latest/Autobuilder/?filter=7cb0ca
b0765669856e359f21a19c47383dcfe84c=commit

Cheers,

Richard

Interesting, it didnt break on my build, I'll dig up whats going on
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] python-setuptools: Upgrade to v 25.1.0

[Alejandro Hernandez]

On 07/28/2016 04:39 PM, Richard Purdie wrote:

On Thu, 2016-07-28 at 18:00 +, Alejandro Hernandez wrote:

LICENCE checksum did not change, it is emebedded on the setup.py
file,
this file changed, so the line number where we get the checksum
changed.

Signed-off-by: Alejandro Hernandez <
alejandro.hernan...@linux.intel.com>
---
  meta/recipes-devtools/python/python-setuptools.inc |  6 ++--
  .../python/python-setuptools_22.0.5.bb | 38 
--
  .../python/python-setuptools_25.1.0.bb | 38
++
  3 files changed, 41 insertions(+), 41 deletions(-)
  delete mode 100644 meta/recipes-devtools/python/python
-setuptools_22.0.5.bb
  create mode 100644 meta/recipes-devtools/python/python
-setuptools_25.1.0.bb

This patch results in:

ERROR: python3-setuptools-22.0.5-r0 do_fetch: Checksum failure fetching 
https://files.pythonhosted.org/packages/source/s/setuptools/setuptools-22.0.5.tar.gz
ERROR: python3-setuptools-22.0.5-r0 do_fetch: Function failed: Fetcher failure 
for URL: 
'https://files.pythonhosted.org/packages/source/s/setuptools/setuptools-22.0.5.tar.gz'.
 Checksum mismatch!
File: '/media/build3/sources/setuptools-22.0.5.tar.gz' has md5 checksum 
869f3029dcc66a64ba39875e2a2f044a when a4814dead37e74a86883c66f7d420d73 was 
expected
File: '/media/build3/sources/setuptools-22.0.5.tar.gz' has sha256 checksum 
19aad19471052d5daefe96f2c1fa2e88dcdb17488bf8708d7e6356881ea833cb when 
6a0f8111feb5a3438c6309cda49810a16d23e73c173331281edc37dd1374d1d5 was expected
If this change is expected (e.g. you have upgraded to a new version without 
updating the checksums) then you can use these lines within the recipe:
SRC_URI[md5sum] = "869f3029dcc66a64ba39875e2a2f044a"
SRC_URI[sha256sum] = 
"19aad19471052d5daefe96f2c1fa2e88dcdb17488bf8708d7e6356881ea833cb"
Otherwise you should retry the download and/or check with upstream to determine 
if the file has become corrupted or otherwise unexpectedly modified.

ERROR: Logfile of failure stored in: 
/media/build1/poky/build/tmp/work/core2-64-poky-linux/python3-setuptools/22.0.5-r0/temp/log.do_fetch.131527
ERROR: Task 
/media/build1/poky/meta/recipes-devtools/python/python3-setuptools_22.0.5.bb:do_fetch
 
(/media/build1/poky/meta/recipes-devtools/python/python3-setuptools_22.0.5.bb:do_fetch)
 failed with exit code '1'

Since I suspect there is a common file between python and python3...


Oh sorry, I forgot to rename the python3-setuptools bb file, sending it 
soon.


Cheers,

Richard


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2 1/1] selftest/runtime-test.py: Add test for testexport SDK feature

[mariano . lopez]

From: Mariano Lopez 

This adds test_testexport_sdk() to test the SDK feature
of testexport in the CI in order to avoid breaking it.

[YOCTO #9765]

Signed-off-by: Mariano Lopez 
---
 meta-selftest/lib/oeqa/runtime/selftest.py | 24 +
 meta/lib/oeqa/selftest/runtime-test.py | 41 ++
 2 files changed, 65 insertions(+)

diff --git a/meta-selftest/lib/oeqa/runtime/selftest.py 
b/meta-selftest/lib/oeqa/runtime/selftest.py
index b9c9b23..a7e58ab3 100644
--- a/meta-selftest/lib/oeqa/runtime/selftest.py
+++ b/meta-selftest/lib/oeqa/runtime/selftest.py
@@ -1,9 +1,13 @@
+import os
+
 from oeqa.oetest import oeRuntimeTest, skipModule
+from oeqa.utils.commands import runCmd
 from oeqa.utils.decorators import *
 
 class Selftest(oeRuntimeTest):
 
 @skipUnlessPassed("test_ssh")
+@tag("selftest_package_install")
 def test_install_package(self):
 """
 Summary: Check basic package installation functionality.
@@ -18,6 +22,7 @@ class Selftest(oeRuntimeTest):
 self.assertEqual(status, 0, msg="socat is not installed")
 
 @skipUnlessPassed("test_install_package")
+@tag("selftest_package_install")
 def test_verify_unistall(self):
 """
 Summary: Check basic package installation functionality.
@@ -29,3 +34,22 @@ class Selftest(oeRuntimeTest):
 
 (status, output) = self.target.run("socat -V")
 self.assertNotEqual(status, 0, msg="socat is still installed")
+
+@tag("selftest_sdk")
+def test_sdk(self):
+
+result = runCmd("env -0")
+sdk_path = search_sdk_path(result.output)
+self.assertTrue(sdk_path, msg="Can't find SDK path")
+
+tar_cmd = os.path.join(sdk_path, "tar")
+result = runCmd("%s --help" % tar_cmd)
+
+def search_sdk_path(env):
+for line in env.split("\0"):
+(key, _, value) = line.partition("=")
+if key == "PATH":
+for path in value.split(":"):
+if "pokysdk" in path:
+return path
+return ""
diff --git a/meta/lib/oeqa/selftest/runtime-test.py 
b/meta/lib/oeqa/selftest/runtime-test.py
index b8e1be1..c2d5b45 100644
--- a/meta/lib/oeqa/selftest/runtime-test.py
+++ b/meta/lib/oeqa/selftest/runtime-test.py
@@ -43,6 +43,46 @@ class TestExport(oeSelfTest):
 failure = True if 'FAIL' in result.output else False
 self.assertNotEqual(True, failure, 'ping test failed')
 
+def test_testexport_sdk(self):
+"""
+Summary: Check sdk functionality for testexport.
+Expected: 1. testexport directory must be created.
+  2. SDK tarball must exists.
+  3. Uncompressing of tarball must succeed.
+  4. Check if the SDK directory is added to PATH.
+  5. Run tar from the SDK directory.
+Product: oe-core
+Author: Mariano Lopez 
+"""
+
+features = 'INHERIT += "testexport"\n'
+# These aren't the actual IP addresses but testexport class needs 
something defined
+features += 'TEST_SERVER_IP = "192.168.7.1"\n'
+features += 'TEST_TARGET_IP = "192.168.7.1"\n'
+features += 'TEST_SUITES = "ping"\n'
+features += 'TEST_SUITES_TAGS = "selftest_sdk"\n'
+features += 'TEST_EXPORT_SDK_ENABLED = "1"\n'
+features += 'TEST_EXPORT_SDK_PACKAGES = "nativesdk-tar"\n'
+self.write_config(features)
+
+# Build tesexport for core-image-minimal
+bitbake('core-image-minimal')
+bitbake('-c testexport core-image-minimal')
+
+# Check for SDK
+testexport_dir = get_bb_var('TEST_EXPORT_DIR', 'core-image-minimal')
+sdk_dir = get_bb_var('TEST_EXPORT_SDK_DIR', 'core-image-minimal')
+tarball_name = "%s.sh" % get_bb_var('TEST_EXPORT_SDK_NAME', 
'core-image-minimal')
+tarball_path = os.path.join(testexport_dir, sdk_dir, tarball_name)
+self.assertEqual(os.path.isfile(tarball_path), True, "Couldn't find 
SDK tarball: %s" % tarball_path)
+
+# Run runexported.py
+runexported_path = os.path.join(testexport_dir, "runexported.py")
+testdata_path = os.path.join(testexport_dir, "testdata.json")
+cmd = "%s %s" % (runexported_path, testdata_path)
+result = runCmd(cmd)
+self.assertEqual(0, result.status, 'runexported.py returned a non 0 
status')
+
 
 class TestImage(oeSelfTest):
 
@@ -57,6 +97,7 @@ class TestImage(oeSelfTest):
 
 features = 'INHERIT += "testimage"\n'
 features += 'TEST_SUITES = "ping ssh selftest"\n'
+features += 'TEST_SUITES_TAGS = "selftest_package_install"\n'
 self.write_config(features)
 
 # Build core-image-sato and testimage
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

[OE-core] [PATCHv2 0/1] Add selftest to test testexport's SDK feature

[mariano . lopez]

From: Mariano Lopez 

This adds a new selftest for testexport in the CI to avoid
breaking SDK functionality.

All dependencies are in master now:

Changes in v2:

- Refactor test to avoid environment modification/restoration.
- Tested in local autobuilders.

The following changes since commit 5203cfe6a9b6d12153426bf7b8d9834c9c4efba2:

  ref-manual: Removed redundant "and" (2016-08-01 12:15:01 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib mariano/bug9765v2
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mariano/bug9765v2

Mariano Lopez (1):
  selftest/runtime-test.py: Add test for testexport SDK feature

 meta-selftest/lib/oeqa/runtime/selftest.py | 24 +
 meta/lib/oeqa/selftest/runtime-test.py | 41 ++
 2 files changed, 65 insertions(+)

-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] want to verify proper use of run-postinsts, if i may

[Burton, Ross]

On 29 July 2016 at 12:54, Robert P. J. Day  wrote:

>   it's not just package post stuff here, i'm looking at run-postinsts
> to do a *lot* of subsequent setup of the target system -- effectively
> downloading and installing the entire proprietary application.
>

I wouldn't target run-postinst directly here, but either write your own
recipe shipping an init script that self-destructs, or has a postinst that
defers using so it runs on first boot.

I'm not very happy with the layout of run-postinsts so may end up changing
it in the next release cycle.  Assuming things about it - such as the name
of the package or where to drop scripts - could bite you in the future.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-oe][PATCH] mozjs: Fix incorrect usage of PN.

[Jeremy Puhlman]

When building mutlilib, using ${PN} in the middle of the package name
creates incorrect package names:

lib32-liblib32-mozjs
lib32-liblib32-mozjs.shlibdeps

Which in turn breaks license.bbclass during image creation.

Signed-off-by: Jeremy Puhlman 
---
 meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb 
b/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb
index 02d5694..f147714 100644
--- a/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb
+++ b/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb
@@ -59,8 +59,8 @@ do_unpack() {
 }
 
 
-PACKAGES =+ "lib${PN}"
-FILES_lib${PN} += "${libdir}/lib*.so"
+PACKAGES =+ "lib${BPN}"
+FILES_lib${BPN} += "${libdir}/lib*.so"
 FILES_${PN}-dev += "${bindir}/js17-config"
 
 # Fails to build with thumb-1 (qemuarm)
-- 
2.6.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] Set READELF for cross compilation

[Jeremy Puhlman]

In the case of using an external toolchain that supports multilib
compilation with a single binary, TARGET_PREFIX is the same for both main
and multilib abis. Without READELF exported, python3 assumes it is
either the readelf for ${BUILD_SYS}-readelf. Exporting cross readelf
fixes the build issue.

checking LDLIBRARY... libpython$(LDVERSION).so
checking for i586-montavistamllib32-linux-ranlib...
x86_64-montavista-linux-ranlib
checking for i586-montavistamllib32-linux-ar...
x86_64-montavista-linux-ar
checking for i586-montavistamllib32-linux-readelf... no
checking for readelf... readelf
configure: WARNING: using cross tools not prefixed with host triplet

Signed-off-by: Jeremy Puhlman 
---
 meta/conf/bitbake.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index af3b181..9bf9bbb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -471,6 +471,7 @@ export OBJCOPY = "${HOST_PREFIX}objcopy"
 export OBJDUMP = "${HOST_PREFIX}objdump"
 export STRINGS = "${HOST_PREFIX}strings"
 export NM = "${HOST_PREFIX}nm"
+export READELF = "${HOST_PREFIX}readelf"
 PYTHON = "${@sys.executable}"
 
 export BUILD_CC = "${CCACHE}${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
-- 
2.6.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] Fix random python backtrace in mutlilib handling code.

[Jeremy Puhlman]

newval is not defined in all cases. Set to None and check if it is set.

  File
"/local/foo/builds/x86/layers/openembedded-core/meta/classes/multilib_global.bbclass",
line 90, in preferred_ml_updates(d=):
 if not d.getVar(newname, False):
>d.setVar(newname, localdata.expand(newval))
 # Avoid future variable key expansion
UnboundLocalError: local variable 'newval' referenced before assignment

Signed-off-by: Jeremy Puhlman 
---
 meta/classes/multilib_global.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/multilib_global.bbclass 
b/meta/classes/multilib_global.bbclass
index 67dc72b..11ae268 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -72,6 +72,7 @@ def preferred_ml_updates(d):
 pkg = pkg.replace("virtual/", "")
 virt = "virtual/"
 for p in prefixes:
+newval = None
 if pkg != "kernel":
 newval = p + "-" + val
 
@@ -86,7 +87,7 @@ def preferred_ml_updates(d):
 
 # implement alternative multilib name
 newname = localdata.expand("PREFERRED_PROVIDER_" + virt + p + "-" 
+ pkg)
-if not d.getVar(newname, False):
+if not d.getVar(newname, False) and newval != None:
 d.setVar(newname, localdata.expand(newval))
 # Avoid future variable key expansion
 provexp = d.expand(prov)
-- 
2.6.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] piglit: fix build failure with gold linker

[Maxin B. John]

When we use gold linker while DISTRO set to "nodistro", piglit build
fails with the following error:

| ../../../../lib/libpiglitutil_gl.so.0: error: undefined reference to
'dlsym'
| ../../../../lib/libpiglitutil_gl.so.0: error: undefined reference to
'dlerror'
| ../../../../lib/libpiglitutil_gl.so.0: error: undefined reference to
'dlopen'
| collect2: error: ld returned 1 exit status

Fix it by providing '-ldl' to LDFLAGS.

[YOCTO #9851]

Signed-off-by: Maxin B. John 
---
 meta/recipes-graphics/piglit/piglit_git.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/piglit/piglit_git.bb 
b/meta/recipes-graphics/piglit/piglit_git.bb
index 811f7af..df90c4d 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -30,6 +30,8 @@ do_compile[dirs] =+ "${B}/temp/"
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[freeglut] = "-DPIGLIT_USE_GLUT=1,-DPIGLIT_USE_GLUT=0,freeglut,"
 
+LDFLAGS_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'-ldl', '', d)}"
+
 do_configure_prepend() {
if [ "${@bb.utils.contains('PACKAGECONFIG', 'freeglut', 'yes', 'no', d)}" = 
"no" ]; then
 sed -i -e "/^#.*include $/d" 
${S}/src/piglit/glut_wrap.h
-- 
2.4.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Burton, Ross]

On 1 August 2016 at 15:07, Bruce Ashfield  wrote:

> Not a large dependency, but it does bring to mind the question if this
> could be conditional on the type of image being built ? via  distro
> feature, some other mechanism ?
>

Exactly this: image building adds dependencies automatically based on what
is actually being used, so can the kernel do this too?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Bruce Ashfield]

On Mon, Aug 1, 2016 at 8:32 AM, Trevor Woerner  wrote:

> If the initramfs image is type lzo, then a native lzop is needed.
>


Not a large dependency, but it does bring to mind the question if this
could be conditional on the type of image being built ? via  distro
feature, some other mechanism ?

Bruce


>
> Signed-off-by: Trevor Woerner 
> ---
>  meta/classes/kernel.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index fa76a14..db42744 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -1,7 +1,7 @@
>  inherit linux-kernel-base kernel-module-split
>
>  PROVIDES += "virtual/kernel"
> -DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc
> kmod-native depmodwrapper-cross bc-native"
> +DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc
> kmod-native depmodwrapper-cross bc-native lzop-native"
>
>  S = "${STAGING_KERNEL_DIR}"
>  B = "${WORKDIR}/build"
> --
> 2.9.2
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Snaps on Yocto/OpenEmbedded

[Bruce Ashfield]

On Mon, Aug 1, 2016 at 7:32 AM, Simon Fels  wrote:

> Hey everyone,
>
> I've worked on a new layer recently which brings snaps to any
> Yocto/OpenEmbedded based system.
>
> If you have never heard about snaps yet you will find most details at
> http://snapcraft.io/ but generally snaps are a new packaging format made
> with security and fast updates in mind and allows applications to be
> packaged once but run everywhere no matter of the distribution used or a
> particular device type.
>
> The layer is currently named meta-snappy and is available at
> https://github.com/morphis/meta-snappy
>
>
I had a quick browse this morning, and one question that jumped to mind was
if the oe-meta-go layer was causing problems for go/go-cross support ? I was
carrying some go/go-inc changes in meta-virtualization as well, but recent
reports
are that oe-meta-go should work for everything now.

I'm just asking, since it doesn't make sense for meta-virt or other layers
to
continue to carry go build infrastructure when it could be unified.

Bruce


> It comes with some basic instructions how to get quickly started. A
> basic tour through the snap system and how to use it is available at
> http://snapcraft.io/
>
> If you have any questions, bugs or contributions feel free to get in
> contact with me.
>
> regards,
> Simon
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Snaps on Yocto/OpenEmbedded

[Khem Raj]

Simon

On Mon, Aug 1, 2016 at 5:32 AM, Simon Fels  wrote:
> Hey everyone,
>
> I've worked on a new layer recently which brings snaps to any
> Yocto/OpenEmbedded based system.
>
> If you have never heard about snaps yet you will find most details at
> http://snapcraft.io/ but generally snaps are a new packaging format made
> with security and fast updates in mind and allows applications to be
> packaged once but run everywhere no matter of the distribution used or a
> particular device type.
>
> The layer is currently named meta-snappy and is available at
> https://github.com/morphis/meta-snappy
>
> It comes with some basic instructions how to get quickly started. A
> basic tour through the snap system and how to use it is available at
> http://snapcraft.io/
>
> If you have any questions, bugs or contributions feel free to get in
> contact with me.

Thank you for announcing your layer, I would also suggest that you
publish the layer
to layerindex as well. at layers.openembedded.org

since thats where most of folks go to find layers.

>
> regards,
> Simon
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Trevor Woerner]

If the initramfs image is type lzo, then a native lzop is needed.

Signed-off-by: Trevor Woerner 
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fa76a14..db42744 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -1,7 +1,7 @@
 inherit linux-kernel-base kernel-module-split
 
 PROVIDES += "virtual/kernel"
-DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native depmodwrapper-cross bc-native"
+DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native depmodwrapper-cross bc-native lzop-native"
 
 S = "${STAGING_KERNEL_DIR}"
 B = "${WORKDIR}/build"
-- 
2.9.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Snaps on Yocto/OpenEmbedded

[Simon Fels]

Hey everyone,

I've worked on a new layer recently which brings snaps to any
Yocto/OpenEmbedded based system.

If you have never heard about snaps yet you will find most details at
http://snapcraft.io/ but generally snaps are a new packaging format made
with security and fast updates in mind and allows applications to be
packaged once but run everywhere no matter of the distribution used or a
particular device type.

The layer is currently named meta-snappy and is available at
https://github.com/morphis/meta-snappy

It comes with some basic instructions how to get quickly started. A
basic tour through the snap system and how to use it is available at
http://snapcraft.io/

If you have any questions, bugs or contributions feel free to get in
contact with me.

regards,
Simon
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [][PATCH v2] init-install*: /etc/mtab make a link rather than a copy

[Belal, Awais]

Hi Khem,

> also check if /proc/mounts exists as well here.
I just sent a v3 to address this.

BR,
Awais


From: Khem Raj [raj.k...@gmail.com]
Sent: Friday, July 29, 2016 11:56 PM
To: Belal, Awais
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [][PATCH v2] init-install*: /etc/mtab make a link rather 
than a copy

> On Jul 29, 2016, at 3:22 AM, Awais Belal  wrote:
>
> Using a copy would only make management of devices erroneous
> and makes the system unstable in some scenarios as tools will
> have to manipulate both files separately. A link ensures that
> both files /proc/mounts and /etc/mtab will have the same
> information at all times and this is how it is handled
> on newer systems where there is such a need. Same is
> suggested by busybox.
>
> Signed-off-by: Awais Belal 
> ---
> meta/recipes-core/initrdscripts/files/init-install-efi.sh | 2 +-
> meta/recipes-core/initrdscripts/files/init-install.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
> b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> index f564f4e..8b996ca 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -123,7 +123,7 @@ mkdir -p /tmp
>
> # Create /etc/mtab if not present
> if [ ! -e /etc/mtab ]; then
> -cat /proc/mounts > /etc/mtab
> +ln -sf /proc/mounts /etc/mtab
> fi
>
> disk_size=$(parted ${device} unit mb print | grep '^Disk .*: .*MB' | cut -d" 
> " -f 3 | sed -e "s/MB//")
> diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
> b/meta/recipes-core/initrdscripts/files/init-install.sh
> index 72ce92b..2362c53 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install.sh
> @@ -119,7 +119,7 @@ fi
>
> mkdir -p /tmp
> if [ ! -L /etc/mtab ]; then

also check if /proc/mounts exists as well here.

> -cat /proc/mounts > /etc/mtab
> +ln -sf /proc/mounts /etc/mtab
> fi
>
> disk_size=$(parted ${device} unit mb print | grep '^Disk .*: .*MB' | cut -d" 
> " -f 3 | sed -e "s/MB//")
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [[PATCH v3] init-install*: /etc/mtab make a link rather than a copy

[Awais Belal]

Using a copy would only make management of devices erroneous
and makes the system unstable in some scenarios as tools will
have to manipulate both files separately. A link ensures that
both files /proc/mounts and /etc/mtab will have the same
information at all times and this is how it is handled
on newer systems where there is such a need. Same is
suggested by busybox.

Signed-off-by: Awais Belal 
---
 meta/recipes-core/initrdscripts/files/init-install-efi.sh | 4 ++--
 meta/recipes-core/initrdscripts/files/init-install.sh | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index f564f4e..c5db2f0 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -122,8 +122,8 @@ umount ${device}* 2> /dev/null || /bin/true
 mkdir -p /tmp
 
 # Create /etc/mtab if not present
-if [ ! -e /etc/mtab ]; then
-cat /proc/mounts > /etc/mtab
+if [ ! -e /etc/mtab ] && [ -e /proc/mounts ]; then
+ln -sf /proc/mounts /etc/mtab
 fi
 
 disk_size=$(parted ${device} unit mb print | grep '^Disk .*: .*MB' | cut -d" " 
-f 3 | sed -e "s/MB//")
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 72ce92b..bf92acb 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -118,8 +118,8 @@ if [ ! -b /dev/loop0 ] ; then
 fi
 
 mkdir -p /tmp
-if [ ! -L /etc/mtab ]; then
-cat /proc/mounts > /etc/mtab
+if [ ! -L /etc/mtab ] && [ -e /proc/mounts ]; then
+ln -sf /proc/mounts /etc/mtab
 fi
 
 disk_size=$(parted ${device} unit mb print | grep '^Disk .*: .*MB' | cut -d" " 
-f 3 | sed -e "s/MB//")
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/8] replace xtscal with xinput-calibrator

[Maxin B. John]

ping ..

On Tue, Jul 12, 2016 at 05:07:35PM +0300, Maxin B. John wrote:
> Remove xtscal in preference of xinput-calibrator
> 
> [YOCTO #9365]
> 
> Maxin B. John (8):
>   xtscal: remove recipe
>   x11-common: replace xtscal with xinput-calibrator
>   pointercal-xinput: add a dummy calibration file for qemu
>   pointercal: remove recipe
>   tslib: replace pointercal with pointercal-xinput
>   packagegroup-core-x11-base.bb: replace pointercal with
> pointercal-xinput
>   layer.conf: remove pointercal
>   distro_alias.inc: remove pointercal and xtscal references
> 
>  meta/conf/distro/include/distro_alias.inc  |   3 -
>  meta/conf/layer.conf   |   1 -
>  meta/recipes-bsp/pointercal/pointercal/COPYING |   2 -
>  meta/recipes-bsp/pointercal/pointercal/pointercal  |   0
>  .../pointercal/pointercal/qemuarm/pointercal   |   1 -
>  .../pointercal/pointercal/qemuarmv6/pointercal |   1 -
>  .../pointercal/pointercal/qemuarmv7/pointercal |   1 -
>  .../pointercal/pointercal/qemumips/pointercal  |   1 -
>  .../pointercal/pointercal/qemuppc/pointercal   | Bin 36 -> 0 bytes
>  .../pointercal/pointercal/qemux86-64/pointercal|   1 -
>  .../pointercal/pointercal/qemux86/pointercal   |   1 -
>  meta/recipes-bsp/pointercal/pointercal_0.0.bb  |  22 -
>  .../packagegroups/packagegroup-core-x11-base.bb|   2 +-
>  meta/recipes-graphics/tslib/tslib_1.1.bb   |   2 +-
>  meta/recipes-graphics/x11-common/x11-common_0.1.bb |   2 +-
>  .../pointercal-xinput/qemuall/pointercal.xinput|   2 +
>  .../xtscal/xtscal/30xTs_Calibrate.sh   |  13 -
>  .../xtscal/xtscal/change-cross.patch   |  18 -
>  meta/recipes-graphics/xtscal/xtscal/cleanup.patch  | 621 
> -
>  .../xtscal/dso_linking_change_build_fix.patch  |  27 -
>  meta/recipes-graphics/xtscal/xtscal_0.6.3.bb   |  33 --
>  21 files changed, 5 insertions(+), 749 deletions(-)
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal/COPYING
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal/pointercal
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal/qemuarm/pointercal
>  delete mode 100644 
> meta/recipes-bsp/pointercal/pointercal/qemuarmv6/pointercal
>  delete mode 100644 
> meta/recipes-bsp/pointercal/pointercal/qemuarmv7/pointercal
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal/qemumips/pointercal
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal/qemuppc/pointercal
>  delete mode 100644 
> meta/recipes-bsp/pointercal/pointercal/qemux86-64/pointercal
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal/qemux86/pointercal
>  delete mode 100644 meta/recipes-bsp/pointercal/pointercal_0.0.bb
>  create mode 100644 
> meta/recipes-graphics/xinput-calibrator/pointercal-xinput/qemuall/pointercal.xinput
>  delete mode 100644 meta/recipes-graphics/xtscal/xtscal/30xTs_Calibrate.sh
>  delete mode 100644 meta/recipes-graphics/xtscal/xtscal/change-cross.patch
>  delete mode 100644 meta/recipes-graphics/xtscal/xtscal/cleanup.patch
>  delete mode 100644 
> meta/recipes-graphics/xtscal/xtscal/dso_linking_change_build_fix.patch
>  delete mode 100644 meta/recipes-graphics/xtscal/xtscal_0.6.3.bb
> 
> -- 
> 2.4.0
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] Replace foomatic-filters with cups-filters

[Fan Xin]

The foomatic-filters community is inactive and foomatic-filter package is 
unmaintained.
(http://www.gossamer-threads.com/lists/gentoo/user/288184)

The foomatic-rips is moved from foomatic-filters to cups-filters and
maintained by cups-filters according to the cups-filter's NEWS.
(http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/NEWS)

Signed-off-by: Fan Xin 
---
 .../cups-filters-1.8.2-disable-ijs.patch   | 65 ++
 .../foomatic/cups-filters_1.8.3.bb | 34 +++
 .../packagegroups/packagegroup-core-lsb.bb |  2 +-
 3 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
 create mode 100644 meta/recipes-extended/foomatic/cups-filters_1.8.3.bb

diff --git 
a/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
 
b/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
new file mode 100644
index 000..0a0a6ad
--- /dev/null
+++ 
b/meta/recipes-extended/foomatic/cups-filters/cups-filters-1.8.2-disable-ijs.patch
@@ -0,0 +1,65 @@
+=== modified file 'Makefile.am'
+--- Makefile.am2016-02-10 15:16:33 +
 Makefile.am2016-03-02 20:46:26 +
+@@ -490,7 +490,6 @@
+   bannertopdf \
+   commandtoescpx \
+   commandtopclx \
+-  pdftoijs \
+   sys5ippprinter \
+   pdftops \
+   pdftoraster \
+@@ -499,6 +498,10 @@
+   texttopdf \
+   urftopdf \
+   rastertopdf
++if ENABLE_IJS
++pkgfilter_PROGRAMS += \
++  pdftoijs
++endif
+ if ENABLE_GHOSTSCRIPT
+ pkgfilter_PROGRAMS += \
+   gstoraster
+@@ -846,9 +849,12 @@
+   ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd \
+   ppd/Generic-PDF_Printer-PDF.ppd \
+   ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd \
+-  ppd/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd \
+   ppd/Ricoh-PDF_Printer-PDF.ppd \
+   ppd/textonly.ppd
++if ENABLE_IJS
++ppd_DATA += \
++  ppd/HP-PhotoSmart_Pro_B8300-hpijs-pdftoijs.ppd
++endif
+ if ENABLE_GHOSTSCRIPT
+ ppd_DATA += \
+   ppd/pxlcolor.ppd \
+=== modified file 'configure.ac'
+--- configure.ac   2016-02-11 13:59:52 +
 configure.ac   2016-03-02 21:18:05 +
+@@ -443,7 +443,7 @@
+ ])
+ PKG_CHECK_MODULES([FREETYPE], [freetype2], [AC_DEFINE([HAVE_FREETYPE_H], [1], 
[Have FreeType2 include files])])
+ PKG_CHECK_MODULES([FONTCONFIG], [fontconfig >= 2.0.0])
+-PKG_CHECK_MODULES([IJS], [ijs])
++PKG_CHECK_MODULES([IJS], [ijs], [have_ijs=yes], [have_ijs=no])
+ PKG_CHECK_MODULES([POPPLER], [poppler >= 0.18])
+ PKG_CHECK_MODULES([ZLIB], [zlib])
+ AC_DEFINE([HAVE_LIBZ], [], [Define that we use zlib])
+@@ -489,6 +489,15 @@
+   [enable_ghostscript="$enableval"],
+   [enable_ghostscript=yes]
+ )
++AC_ARG_ENABLE([ijs],
++  [AS_HELP_STRING([--disable-ijs], [Disable filters using IJS.])],
++  [enable_ijs="$enableval"],
++  [enable_ijs=yes]
++)
++AS_IF([test "x$enable_ijs" = "xyes" -a "x$have_ijs" != "xyes"], [
++   AC_MSG_ERROR([IJS not found, but requested.])
++])
++AM_CONDITIONAL(ENABLE_IJS, test "x$enable_ijs" = "xyes")
+ AC_ARG_WITH([pdftops],
+   [AS_HELP_STRING([--with-pdftops=value], [Set which pdftops to use 
(gs,pdftops,pdftocairo,acroread,hybrid).])],
+   [with_pdftops="$withval"],
+
diff --git a/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb 
b/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
new file mode 100644
index 000..4eef7ef
--- /dev/null
+++ b/meta/recipes-extended/foomatic/cups-filters_1.8.3.bb
@@ -0,0 +1,34 @@
+SUMMARY = "OpenPrinting printer support - filters"
+DESCRIPTION = "CUPS is a standards-based, open source printing system \
+developed by Apple Inc. for Mac OS® X and other UNIX®-like operating systems. \
+CUPS uses the Internet Printing Protocol ("IPP") and provides System V and \
+Berkeley command-line interfaces, a web interface, and a C API to manage 
printers \
+and print jobs. \
+ \
+This package consists of filters used by the printer spoolers \
+to convert the incoming PostScript data into the printer's native \
+format using a printer-specific, but spooler-independent PPD file. \
+"
+
+DEPENDS += "cups tiff lcms freetype fontconfig poppler qpdf"
+PR = "r0"
+
+LICENSE = "GPLv2 & LGPLv2 & MIT & GPLv2+ & GPLv3"
+LIC_FILES_CHKSUM = 
"file://${WORKDIR}/cups-filters-${PV}/COPYING;md5=d420e185486344da6176553848350932"
+
+SRC_URI = 
"http://www.openprinting.org/download/cups-filters/cups-filters-${PV}.tar.gz \
+  "
+
+SRC_URI[md5sum] = "9ecda355e1f4c781784f902737df6321"
+SRC_URI[sha256sum] = 
"0ad46d15737b309fe648fe39023a4eb6a3528faadbeb97d6ecf523df40950033"
+
+UPSTREAM_CHECK_REGEX = "cups-filters-(?P((\d|\d\d)\.*)+)\.tar\.gz"
+
+inherit autotools-brokensep pkgconfig
+
+EXTRA_OECONF += "--disable-ijs"
+
+FILES_${PN} += "${datadir}"
+FILES_${PN} += "${libdir}/cups"
+
+RDEPENDS_${PN} += "bash"
diff --git 

[OE-core] [PATCH 2/2] pseudo: update git recipe to include xattr perf fix

[Joshua Lock]

Update the SRCREV to 2 commits beyond the 1.8.1 tag (to the current
HEAD) in order to include a fix for the xattr performance regression
[YOCTO #9929].

Signed-off-by: Joshua Lock 
---
 meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 9febf60..8735cf4 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,6 +1,6 @@
 require pseudo.inc
 
-SRCREV = "eb47d855a831b6dc0ad34890e84b8f6f483693df"
+SRCREV = "f4b1c752186f4d08f1fadb0ea10ebcde9b0ea251"
 PV = "1.8.1+git${SRCPV}"
 
 DEFAULT_PREFERENCE = "-1"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] Pseudo performance regression

[Joshua Lock]

The following series includes changes from upstream to mitigate a performance
regression in pseudo 1.8.x, most notable when building images which make heavy
use of extended attributes.

Regards,

Joshua

The following changes since commit b32d430c3c7dccf3a8d06ab492d648893a05950f:

  dpkg: use snapshot.debian.org for SRC_URI (2016-07-26 08:56:08 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/pseudo
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/pseudo

Joshua Lock (2):
  pseudo: backport patch to fix xattr performance
  pseudo: update git recipe to include xattr perf fix

 .../pseudo/files/Fix-xattr-performance.patch   | 117 +
 meta/recipes-devtools/pseudo/pseudo_1.8.1.bb   |   1 +
 meta/recipes-devtools/pseudo/pseudo_git.bb |   2 +-
 3 files changed, 119 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/pseudo/files/Fix-xattr-performance.patch

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] pseudo: backport patch to fix xattr performance

[Joshua Lock]

In the 1.8 series of pseudo extended attribute handling was reworked
to be a property of inodes, not paths, and as a product fixed extended
attribute semantics on hardlinks. Unfortunately this rework introduced
a slow path around file deletion.

Add a patch for use by the pseudo 1.8.1 recipe which backports a fix
for this regression from the master branch of pseudo.

[YOCTO #9929]

Signed-off-by: Joshua Lock 
---
 .../pseudo/files/Fix-xattr-performance.patch   | 117 +
 meta/recipes-devtools/pseudo/pseudo_1.8.1.bb   |   1 +
 2 files changed, 118 insertions(+)
 create mode 100644 
meta/recipes-devtools/pseudo/files/Fix-xattr-performance.patch

diff --git a/meta/recipes-devtools/pseudo/files/Fix-xattr-performance.patch 
b/meta/recipes-devtools/pseudo/files/Fix-xattr-performance.patch
new file mode 100644
index 000..4e072e6
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/Fix-xattr-performance.patch
@@ -0,0 +1,117 @@
+From 0d9071f3090bbd7880558f3b488b236ac19b44fc Mon Sep 17 00:00:00 2001
+From: seebs 
+Date: Thu, 28 Jul 2016 14:02:12 -0500
+Subject: [PATCH 1/2] Fix xattr performance
+
+When deleting files, we *do* know the inode and attribute, most of the
+time, so we pass those in whenever possible. The full purge of unmatched
+xattrs should not happen when the correct dev/ino are believed to be known.
+
+Signed-off-by: Seebs 
+
+[YOCTO #9929]
+Upstream-Status: Backport (0d9071f3090bbd7880558f3b488b236ac19b44fc)
+Signed-off-by: Joshua Lock 
+---
+ ChangeLog.txt |  3 +++
+ pseudo.c  | 11 ---
+ pseudo_db.c   | 15 +--
+ pseudo_db.h   |  2 +-
+ 4 files changed, 21 insertions(+), 10 deletions(-)
+
+diff --git a/ChangeLog.txt b/ChangeLog.txt
+index 131f163..d6359ca 100644
+--- a/ChangeLog.txt
 b/ChangeLog.txt
+@@ -1,3 +1,6 @@
++2016-07-28:
++  * (seebs) Fix performance issue on deletion with xattr changes.
++
+ 2016-07-08:
+   * (RP) release 1.8.1
+   * (joshuagl) Fix log table creation issue
+diff --git a/pseudo.c b/pseudo.c
+index 52f649f..db1c400 100644
+--- a/pseudo.c
 b/pseudo.c
+@@ -600,7 +600,12 @@ pseudo_op(pseudo_msg_t *msg, const char *program, const 
char *tag, char **respon
+   if (by_path.deleting != 0) {
+   pseudo_debug(PDBGF_FILE, "inode 
mismatch for '%s' -- old one was marked for deletion, deleting.\n",
+   msg->path);
+-  pdb_did_unlink_file(msg->path, 
by_path.deleting);
++  /* in this case, we don't trust the
++   * existing entries, so we will do the
++   * more expensive sweep for stray
++   * xattrs.
++   */
++  pdb_did_unlink_file(msg->path, NULL, 
by_path.deleting);
+   } else {
+   pseudo_diag("inode mismatch: '%s' ino 
%llu in db, %llu in request.\n",
+   msg->path,
+@@ -698,7 +703,7 @@ pseudo_op(pseudo_msg_t *msg, const char *program, const 
char *tag, char **respon
+   if (by_ino.deleting != 0) {
+   pseudo_debug(PDBGF_FILE, "inode 
mismatch for '%s' -- old one was marked for deletion, deleting.\n",
+   msg->path);
+-  pdb_did_unlink_file(path_by_ino, 
by_ino.deleting);
++  pdb_did_unlink_file(path_by_ino, 
_ino, by_ino.deleting);
+   } else {
+   pseudo_diag("path mismatch [%d link%s]: 
ino %llu db '%s' req '%s'.\n",
+   msg->nlink,
+@@ -930,7 +935,7 @@ pseudo_op(pseudo_msg_t *msg, const char *program, const 
char *tag, char **respon
+   }
+   break;
+   case OP_DID_UNLINK:
+-  pdb_did_unlink_file(msg->path, msg->client);
++  pdb_did_unlink_file(msg->path, msg, msg->client);
+   break;
+   case OP_CANCEL_UNLINK:
+   pdb_cancel_unlink_file(msg);
+diff --git a/pseudo_db.c b/pseudo_db.c
+index 289bb29..e7dd193 100644
+--- a/pseudo_db.c
 b/pseudo_db.c
+@@ -1848,7 +1848,7 @@ pdb_did_unlink_files(int deleting) {
+ 
+ /* confirm deletion of a specific file by a given client */
+ int
+-pdb_did_unlink_file(char *path, int deleting) {
++pdb_did_unlink_file(char *path, pseudo_msg_t *msg, int deleting) {
+   static sqlite3_stmt *delete_exact;
+   int rc, exact;
+   char *sql_delete_exact = "DELETE FROM files WHERE path = ? AND deleting 
= ?;";
+@@ -1878,11 +1878,14 @@ pdb_did_unlink_file(char 

Re: [OE-core] [PATCH] Replace foomatic-filters with cups-filters

[Fan Xin]

On 2016年07月31日 07:47, Stephen Arnold wrote:

No answer to this?  cups-filters would be kinda important for actual
printing, especially since the existing ghostscript/cups/poppler
packages have all been gutted of anything called *toraster.  The
current state (on krogoth at least) is completely broken; is there
something on another branch somewhere?  If so, I can't see it with
google...

Steve



Hi, Steve

I am working on this one. Actually I have created the cups-filters 
recipe file. But the cups-filters depends on qpdf.
Just now I sent the qpdf recipe file to mailing list and will send the 
cups-filters recipe files later.


Cheers,

Fan


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Robert Yang]

On 08/01/2016 04:42 PM, Seebs wrote:

On 1 Aug 2016, at 0:57, Robert Yang wrote:


Sorry, the steps were wrong, they should be:
1) Out of pseudo:
   $ umask 0022
   $ touch file1
2) Under pseudo:
   $ ln file1 file2
   $ chmod 777 file2
   $ ls -l file1 file2
   We can see that both file1 and file2's mode is 0777.
   But if we remove file2:
   $ rm -f file2
   $ ls file1
   Now file1's permission is 0755, not 0777 or 0644, it should be 0777 here.


The short answer is: If you aren't tracking a file in pseudo, we don't make
promises about its behavior. Normally, we don't touch them, but if there's hard
links to them that are being touched, well. And having a hard link that is
tracked, and another that isn't, is probably impossible to support. I definitely
don't want to keep database entries for files that have been deleted, that way
lies madness and possible database corruption; for instance, if we do that, and
you make a new file of the same type, it'll show up as having those permissions,
with only a path-mismatch warning in the database to suggest what went wrong.

I would say that the probable correct answer is either "make the original file
be tracked" or "don't use hard links in this case".


Hi Peter,

How about we track the src when hardlink, for example:

$ ln oldpath newpath

Track both oldpath and newpath. The patch for pseudo is:

diff --git a/ports/unix/guts/linkat.c b/ports/unix/guts/linkat.c
index ec27e47..521b8fa 100644
--- a/ports/unix/guts/linkat.c
+++ b/ports/unix/guts/linkat.c
@@ -62,6 +62,10 @@
  * if the thing linked is a symlink.
  */
 pseudo_client_op(OP_LINK, 0, -1, -1, newpath, );
+/*
+ * Track oldpath in case it isn't tracked.
+ */
+pseudo_client_op(OP_LINK, 0, -1, -1, oldpath, );

 errno = save_errno;

// Robert



Note that, under older pseudo, the file would have ended up 0777. The behavior
of silently masking out 022 from underlying filesystem permissions is entirely
intentional. During some debugging quite a while back, we discovered a quirk in
oe-core, plus a strange behavior of
GNU tar, which between them resulted in some sstage directories getting
unpacked with mode 0777.

And we *really* don't want the build system generating files which other users
can modify, especially not in stuff that's intended to go into a root
filesystem. So stripping out those bits in the underlying filesystem is
intentional.

If you were actually root, yes, the original file would have its mode changed to
0777. But we should never be *caring* about the mode bits on
raw files outside of pseudo, except that we want them to allow owner
write permissions and not allow group or other write permissions. If the
file's permissions matter to the build system or generated stuff, the
file should be tracked by pseudo.

-s

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 0:57, Robert Yang wrote:


Sorry, the steps were wrong, they should be:
1) Out of pseudo:
   $ umask 0022
   $ touch file1
2) Under pseudo:
   $ ln file1 file2
   $ chmod 777 file2
   $ ls -l file1 file2
   We can see that both file1 and file2's mode is 0777.
   But if we remove file2:
   $ rm -f file2
   $ ls file1
   Now file1's permission is 0755, not 0777 or 0644, it should be 0777 
here.


The short answer is: If you aren't tracking a file in pseudo, we don't 
make promises about its behavior. Normally, we don't touch them, but if 
there's hard links to them that are being touched, well. And having a 
hard link that is tracked, and another that isn't, is probably 
impossible to support. I definitely don't want to keep database entries 
for files that have been deleted, that way lies madness and possible 
database corruption; for instance, if we do that, and you make a new 
file of the same type, it'll show up as having those permissions, with 
only a path-mismatch warning in the database to suggest what went wrong.


I would say that the probable correct answer is either "make the 
original file be tracked" or "don't use hard links in this case".


Note that, under older pseudo, the file would have ended up 0777. The 
behavior of silently masking out 022 from underlying filesystem 
permissions is entirely intentional. During some debugging quite a while 
back, we discovered a quirk in oe-core, plus a strange behavior of

GNU tar, which between them resulted in some sstage directories getting
unpacked with mode 0777.

And we *really* don't want the build system generating files which other 
users can modify, especially not in stuff that's intended to go into a 
root filesystem. So stripping out those bits in the underlying 
filesystem is intentional.


If you were actually root, yes, the original file would have its mode 
changed to 0777. But we should never be *caring* about the mode bits on

raw files outside of pseudo, except that we want them to allow owner
write permissions and not allow group or other write permissions. If the
file's permissions matter to the build system or generated stuff, the
file should be tracked by pseudo.

-s
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] qpdf: add new recipe

[Richard Purdie]

On Mon, 2016-08-01 at 17:24 +0900, Fan Xin wrote:
> QPDF is a command-line program that does structural,
> content-preserving transformation on PDF files.
> 
> Signed-off-by: Fan Xin 

Why do we need this in OE-Core compared to a layer like meta
-openembedded?

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qpdf: add new recipe

[Fan Xin]

QPDF is a command-line program that does structural,
content-preserving transformation on PDF files.

Signed-off-by: Fan Xin 
---
 meta/recipes-extended/qpdf/qpdf_6.0.0.bb | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 meta/recipes-extended/qpdf/qpdf_6.0.0.bb

diff --git a/meta/recipes-extended/qpdf/qpdf_6.0.0.bb 
b/meta/recipes-extended/qpdf/qpdf_6.0.0.bb
new file mode 100644
index 000..edee741
--- /dev/null
+++ b/meta/recipes-extended/qpdf/qpdf_6.0.0.bb
@@ -0,0 +1,26 @@
+SUMMARY = "QPDF is a command-line program that does structural, 
content-preserving transformations on PDF files"
+DESCRIPTION = "QPDF is capable of creating linearized files and encrypted 
files. It is also capable of \
+converting PDF files with object streams to files with no compressed objects 
or to generate object streams \
+from files that don't have them. QPDF also supports a special mode designed to 
allow you to edit the content \
+of PDF files in a text editor."
+HOMEPAGE = "http://qpdf.sourceforge.net/;
+
+PR = "r0"
+
+RDEPENDS_${PN} = "libpcre zlib"
+
+LICENSE = "Artistic-2.0"
+LIC_FILES_CHKSUM = 
"file://${WORKDIR}/qpdf-${PV}/Artistic-2.0;md5=7806296b9fae874361e6fb10072b7ee3"
+
+SRC_URI = 
"http://nchc.dl.sourceforge.net/project/qpdf/qpdf/6.0.0/qpdf-${PV}.tar.gz;
+
+SRC_URI[md5sum] = "e014bd3ecf1c4d1a520bbc14d84ac20e"
+SRC_URI[sha256sum] = 
"a9fdc7e94d38fcd3831f37b6e0fe36492bf79aa6d54f8f66062cf7f9c4155233"
+
+inherit autotools-brokensep pkgconfig
+
+EXTRA_OECONF += "--with-random=/dev/urandom"
+
+do_configure_prepend() {
+  sh autogen.sh
+}
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core