[OE-core] Webmin 1.7 not working

[Life Life]

Hello,

I'm trying webmin on poky 1.7 distro.  webmin user interface not show All
running process on linux.

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

[OE-core] Are we open for intrusive changes on master now

[Khem Raj]

Hi

I have few patches pending on

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master

except two commits 1. glibc and 2. gcc-5.0 upgrade

all are potential candidates I would like to propose ( as of now )

Since these are quite intrusive patches, I would like to have them in early for 
next release cycle

-Khem

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

Re: [OE-core] [PATCH 3/3] distrodata.bbclass/distro_check.py: Support buildtools PN mapping

[Flanagan, Elizabeth]

On 31 March 2015 at 23:31, Burton, Ross  wrote:
>
> On 31 March 2015 at 21:11, Beth Flanagan 
> wrote:
>>
>> We need to be able to map buildtools- to the original PN.
>
>
> What packages are prefixed buildtools-?  I can only see a buildtools-tarball
> and nativesdk-buildtools-perl-dummy, neither of which can be considered to
> have a "real PN" of tarball or perl really.
>
> Ross

Agreed. Looking at the two recipes that use this, I think it's
probably safe to just exclude packages that have buildtools- prefixes.

-b

>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] distrodata.bbclass/distro_check.py: Support buildtools PN mapping

[Burton, Ross]

On 31 March 2015 at 21:11, Beth Flanagan 
wrote:

> We need to be able to map buildtools- to the original PN.
>

What packages are prefixed buildtools-?  I can only see a
buildtools-tarball and nativesdk-buildtools-perl-dummy, neither of which
can be considered to have a "real PN" of tarball or perl really.

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

Re: [OE-core] [PATCH 1/3] distrodata.bbclass/distro_check.py: Fix splits

[Flanagan, Elizabeth]

On 31 March 2015 at 23:03, Burton, Ross  wrote:
>
> On 31 March 2015 at 21:11, Beth Flanagan 
> wrote:
>>
>> +if pnstripped.find("-native") != -1:
>
>
> Shouldn't this be .endswith() or .startswith() to prevent false-positives?
>

Not that we'd ever end up with something like foo-native-dummy (watch
someone prove that wrong), but we wouldn't want .endswith() here as
that would end up with bad data as well. I'm by no means happy with
the solution here, but for the time being it gets packagedata and
check_package working and not spitting out incorrect data.

I think we probably need to take a better look at packagedata and
check_package in 1.9, especially with how we map this to the actual
PN, but in this case, I was of the opinion that better was the enemy
of good enough.

> Ross
>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] distrodata.bbclass/distro_check.py: Fix splits

[Burton, Ross]

On 31 March 2015 at 23:03, Burton, Ross  wrote:

>
> On 31 March 2015 at 21:11, Beth Flanagan 
> wrote:
>
>> +if pnstripped.find("-native") != -1:
>>
>
> Shouldn't this be .endswith() or .startswith() to prevent false-positives?
>

Also this all clearly says "put me in a function".  But what you need is
*almost* the BPN variable but with some prefix stripping that the BPN-logic
doesn't do (BPN only has suffix stripped, oddly).

I'd argue that the BPN logic should also strip nativesdk- prefixes, so by
fixing that the distrotools class could just get PN and BPN from the data
store and be done with it.

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

Re: [OE-core] [PATCH 1/3] distrodata.bbclass/distro_check.py: Fix splits

[Burton, Ross]

On 31 March 2015 at 21:11, Beth Flanagan 
wrote:

> +if pnstripped.find("-native") != -1:
>

Shouldn't this be .endswith() or .startswith() to prevent false-positives?

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

Re: [OE-core] [PATCH] siteinfo: Add x86_64-elf support

[Richard Purdie]

On Tue, 2015-03-31 at 11:03 -0700, Khem Raj wrote:
> > On Mar 31, 2015, at 8:22 AM, Richard Purdie 
> >  wrote:
> > 
> > Teach siteinfo about x86_64-elf so that baremetal toolchains parse/build.
> > 
> > Signed-off-by: Richard Purdie 
> > 
> > diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
> > index 2c1f9d0..5fd99bf 100644
> > --- a/meta/classes/siteinfo.bbclass
> > +++ b/meta/classes/siteinfo.bbclass
> > @@ -95,6 +95,7 @@ def siteinfo_data(d):
> > "x86_64-linux": "bit-64",
> > "x86_64-linux-musl": "x86_64-linux bit-64",
> > "x86_64-linux-uclibc": "bit-64",
> > +"x86_64-elf": "bit-64”,
> 
> is 32bit bare metal already taken care of ?

As far as I can tell, yes. x86_64 is more spelt out due to the x32
issues.

Cheers,

Richard

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

Re: [OE-core] Ownership issue in package contents

[Mark Hatle]

On 3/31/15 4:21 PM, Mario Domenech Goulart wrote:
> On Tue, 31 Mar 2015 16:09:42 -0500 Mark Hatle  
> wrote:
> 
>> On 3/31/15 4:01 PM, Mario Domenech Goulart wrote:
>>> On Tue, 31 Mar 2015 15:51:50 -0500 Mark Hatle  
>>> wrote:
>>>
 On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:
>
> On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle  
> wrote:
>
>> On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
>>>
>>> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross" 
>>>  wrote:
>>>
 On 27 March 2015 at 17:31, Mario Domenech Goulart 
  wrote:

 Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
 the recipe, ./usr/lib/foo/ in the package is owned by root.
 However, its content has the right ownership.

 Looks like a bug in pseudo to me, can you file a bug for that?
>>>
>>> Sure.  Filed #7554.
>>
>> I'd suggest you look at meta/classes/package.bbclass "fixup_perms" 
>> function.
>>
>> The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
>> function.  I don't know why 'foo' would be, but if it's a standard 
>> defined
>> variable -- or if 'directory walking' is enabled it could end up doing 
>> this as well.
>>
>> The control file for this is in meta/files/fs-perms.txt (unless otherwise
>> defined by a distribution or other configuration file.)
>
> Thanks a lot.  You seem to have guided me exactly to what causes the
> issue.
>
>>
>> Format of the file is:
>>
>> # The format of this file
>> #
>> #  
> ...
>>
>> The default is:
> ...
>> libexecdir   0755 root root false - - -
> ...
>
> This variable seems to be the cause of problems:
>
> $ bitbake -e foo | grep libexecdir=
> export libexecdir="/usr/lib/foo"
>
> As far as I understand, package.bbclass may use a user-configured
> permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
> this is the right "fix" for the case in question.  I'd have to hardcode
> the owner of /usr/lib/foo to be "foo", but foo may not be available when
> packaging other recipes.

 Ok, good this answers the question as to "why" it's happening.  You can 
 easily
 fix this by adding a configuration specific fs-perms.txt file (can name it
 anything) that overrides that setting and add it to the 
 FILESYSTEM_PERMS_TABLES.
  You can do this globally in a layer, a distribution or even just a recipe.

 In your recipe you can likely do something like:

 FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt"
 FILESYSTEM_PERMS_TABLES += "${THISDIR}/files/recipe-perms.txt"

 (Do the ?= first in case it's already set by someone else, then add your 
 recipe
 specific perms later)

 Contents of the "${THISDIR}/files/recipe-perms.txt":

 ${libexecdir} 0755 myuid mygid true - myuid mygid

 Then you can even skip the chown -R, as the system will do it for you.
>>>
>>> I actually had tried that, but I got errors -- probably because the
>>> ownership will be set for each package that installs ${libexecdir}, and
>>> which is processed before the recipe that actually creates the
>>> user/group specified for ${libexecdir} in the file pointed by
>>> FILESYSTEM_PERMS_TABLES.
>>
>> This is a bug then.  The owner/group correction is supposed to be made AFTER 
>> the
>> user/groups have been added to the system (sysroot) via the adduser.  THAT 
>> is a
>> bug that IMHO should be fixed sooner, rather then later.
>>
>> It might be as simple as the install sysroot (${D}) configuration with pseudo
>> isn't pointing to the right /etc/passwd and /etc/group.  I believe it should 
>> be
>> pointing to the one in the regular sysroot repository.
> 
> I should also have mentioned that initially I set
> FILESYSTEM_PERMS_TABLES globally.
> 
> Now I set it in the foo recipe, but still get errors:
> 
> 8<-
> ERROR: Error executing a python function in .../foo.bb:
> 
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'fixup_perms', lineno: 231, function: 
>  0227:each_file = os.path.join(root, f)
>  0228:fix_perms(each_file, fs_perms_table[dir].fmode, 
> fs_perms_table[dir].fuid, fs_perms_table[dir].fgid, dir)
>  0229:
>  0230:
>  *** 0231:fixup_perms(d)
>  0232:
> File: 'fixup_perms', lineno: 173, function: fixup_perms
>  0169:if len(lsplit) != 8 and not (len(lsplit) == 3 and 
> lsplit[1].lower() == "link"):
>  0170:msg = "Fixup perms: %s invalid line: %s" % 
> (conf, line)
>  0171:package_qa_handle_error("perm-line", msg, d)
>  0172:continue
>  *** 0173:entry = fs

Re: [OE-core] [PATCH] terminal: Disable shopt errexit

[Burton, Ross]

On 31 March 2015 at 22:32, Richard Tollerton  wrote:

> What broke is devshell. If there's a bug in run.do_terminal that would
> cause a nonzero exit code during non-interactive execution -- e.g.,
>
> http://cgit.openembedded.org/bitbake/commit/?id=18cd0ce6a55c9065c3f1bf223b47d817b5efcd8f
> -- then instead of a warning appearing in the devshell, the entire
> terminal quits a few milliseconds after it loads.
>

Right, understand.  Thanks.

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

[OE-core] [PATCH] image_types: Add missing ext4 support

[Richard Purdie]

This is particularly problematic since qemu images switched to ext4 by 
default and now cannot work properly with UIs like hob.

This patch adds in ext4 to the appropriate IMAGE* variables fixing this.

[YOCTO #7426]

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 98a08bf..72c7337 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -146,6 +146,7 @@ IMAGE_TYPES = " \
 cramfs \
 ext2 ext2.gz ext2.bz2 ext2.lzma \
 ext3 ext3.gz \
+ext4 ext4.gz \
 btrfs \
 iso \
 hddimg \
@@ -171,7 +172,7 @@ COMPRESS_DEPENDS_xz = "xz-native"
 COMPRESS_DEPENDS_lz4 = "lz4-native"
 COMPRESS_DEPENDS_sum = "mtd-utils-native"
 
-RUNNABLE_IMAGE_TYPES ?= "ext2 ext3"
+RUNNABLE_IMAGE_TYPES ?= "ext2 ext3 ext4"
 RUNNABLE_MACHINE_PATTERNS ?= "qemu"
 
 DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso" 


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

Re: [OE-core] [PATCH] terminal: Disable shopt errexit

[Richard Tollerton]

"Burton, Ross"  writes:

> On 30 March 2015 at 19:11, Richard Tollerton  wrote:
>
>> Running `false` interactively doesn't test this behavior because `sh -e`
>> explicitly excludes interactive shells from consideration [1] [2].
>> You'll need to inject a `false` into run.do_terminal in order to
>> reproduce this.
>>
>
> I'm clearly not understanding how this behaviour is a problem then.  What
> broke?

What broke is devshell. If there's a bug in run.do_terminal that would
cause a nonzero exit code during non-interactive execution -- e.g.,
http://cgit.openembedded.org/bitbake/commit/?id=18cd0ce6a55c9065c3f1bf223b47d817b5efcd8f
-- then instead of a warning appearing in the devshell, the entire
terminal quits a few milliseconds after it loads.

In other words, this issue escalates other bugs that ought to be
warnings into functionality-killers. This patch de-escalates them
back to warnings.

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

Re: [OE-core] package update staging

[Burton, Ross]

On 31 March 2015 at 16:33, akuster808  wrote:

> now that fido is nearing, what is the best method for staging package
> updates meant for oe-core?
>

Send patches now if you wish, both me and Richard have started collating
patches that are good for master.

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

Re: [OE-core] [PATCH] createrepo: Implement --dbpath command line option

[Burton, Ross]

Hi Ed,

On 31 March 2015 at 00:49, Ed Bartosh  wrote:

> Upstream-Status: Pending
>

The commit log needs just a Signed-off-by; the patch needs an explanation,
Signed-off-by, and Upstream-Status.  The goal is that the patch itself is
self-explanatory, so should explain what it does and why, whether it went
upstream and why (not), and who admits creating it in the first place.

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

Re: [OE-core] Ownership issue in package contents

[Mario Domenech Goulart]

On Tue, 31 Mar 2015 16:09:42 -0500 Mark Hatle  wrote:

> On 3/31/15 4:01 PM, Mario Domenech Goulart wrote:
>> On Tue, 31 Mar 2015 15:51:50 -0500 Mark Hatle  
>> wrote:
>> 
>>> On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:

 On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle  
 wrote:

> On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
>>
>> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross" 
>>  wrote:
>>
>>> On 27 March 2015 at 17:31, Mario Domenech Goulart 
>>>  wrote:
>>>
>>> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
>>> the recipe, ./usr/lib/foo/ in the package is owned by root.
>>> However, its content has the right ownership.
>>>
>>> Looks like a bug in pseudo to me, can you file a bug for that?
>>
>> Sure.  Filed #7554.
>
> I'd suggest you look at meta/classes/package.bbclass "fixup_perms" 
> function.
>
> The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
> function.  I don't know why 'foo' would be, but if it's a standard defined
> variable -- or if 'directory walking' is enabled it could end up doing 
> this as well.
>
> The control file for this is in meta/files/fs-perms.txt (unless otherwise
> defined by a distribution or other configuration file.)

 Thanks a lot.  You seem to have guided me exactly to what causes the
 issue.

>
> Format of the file is:
>
> # The format of this file
> #
> #  
 ...
>
> The default is:
 ...
> libexecdir0755 root root false - - -
 ...

 This variable seems to be the cause of problems:

 $ bitbake -e foo | grep libexecdir=
 export libexecdir="/usr/lib/foo"

 As far as I understand, package.bbclass may use a user-configured
 permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
 this is the right "fix" for the case in question.  I'd have to hardcode
 the owner of /usr/lib/foo to be "foo", but foo may not be available when
 packaging other recipes.
>>>
>>> Ok, good this answers the question as to "why" it's happening.  You can 
>>> easily
>>> fix this by adding a configuration specific fs-perms.txt file (can name it
>>> anything) that overrides that setting and add it to the 
>>> FILESYSTEM_PERMS_TABLES.
>>>  You can do this globally in a layer, a distribution or even just a recipe.
>>>
>>> In your recipe you can likely do something like:
>>>
>>> FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt"
>>> FILESYSTEM_PERMS_TABLES += "${THISDIR}/files/recipe-perms.txt"
>>>
>>> (Do the ?= first in case it's already set by someone else, then add your 
>>> recipe
>>> specific perms later)
>>>
>>> Contents of the "${THISDIR}/files/recipe-perms.txt":
>>>
>>> ${libexecdir} 0755 myuid mygid true - myuid mygid
>>>
>>> Then you can even skip the chown -R, as the system will do it for you.
>> 
>> I actually had tried that, but I got errors -- probably because the
>> ownership will be set for each package that installs ${libexecdir}, and
>> which is processed before the recipe that actually creates the
>> user/group specified for ${libexecdir} in the file pointed by
>> FILESYSTEM_PERMS_TABLES.
>
> This is a bug then.  The owner/group correction is supposed to be made AFTER 
> the
> user/groups have been added to the system (sysroot) via the adduser.  THAT is 
> a
> bug that IMHO should be fixed sooner, rather then later.
>
> It might be as simple as the install sysroot (${D}) configuration with pseudo
> isn't pointing to the right /etc/passwd and /etc/group.  I believe it should 
> be
> pointing to the one in the regular sysroot repository.

I should also have mentioned that initially I set
FILESYSTEM_PERMS_TABLES globally.

Now I set it in the foo recipe, but still get errors:

8<-
ERROR: Error executing a python function in .../foo.bb:

The stack trace of python calls that resulted in this exception/failure was:
File: 'fixup_perms', lineno: 231, function: 
 0227:each_file = os.path.join(root, f)
 0228:fix_perms(each_file, fs_perms_table[dir].fmode, 
fs_perms_table[dir].fuid, fs_perms_table[dir].fgid, dir)
 0229:
 0230:
 *** 0231:fixup_perms(d)
 0232:
File: 'fixup_perms', lineno: 173, function: fixup_perms
 0169:if len(lsplit) != 8 and not (len(lsplit) == 3 and 
lsplit[1].lower() == "link"):
 0170:msg = "Fixup perms: %s invalid line: %s" % (conf, 
line)
 0171:package_qa_handle_error("perm-line", msg, d)
 0172:continue
 *** 0173:entry = fs_perms_entry(d.expand(line))
 0174:if entry and entry.path:
 0175:fs_perms_table[entry.path] = entry
 0176:f.close()
 0177:
File: 'fixup_perms', lineno

Re: [OE-core] [PATCH] terminal: Disable shopt errexit

[Burton, Ross]

On 30 March 2015 at 19:11, Richard Tollerton  wrote:

> Running `false` interactively doesn't test this behavior because `sh -e`
> explicitly excludes interactive shells from consideration [1] [2].
> You'll need to inject a `false` into run.do_terminal in order to
> reproduce this.
>

I'm clearly not understanding how this behaviour is a problem then.  What
broke?

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

Re: [OE-core] Ownership issue in package contents

[Mark Hatle]

On 3/31/15 4:01 PM, Mario Domenech Goulart wrote:
> On Tue, 31 Mar 2015 15:51:50 -0500 Mark Hatle  
> wrote:
> 
>> On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:
>>>
>>> On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle  
>>> wrote:
>>>
 On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
>
> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross"  
> wrote:
>
>> On 27 March 2015 at 17:31, Mario Domenech Goulart 
>>  wrote:
>>
>> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
>> the recipe, ./usr/lib/foo/ in the package is owned by root.
>> However, its content has the right ownership.
>>
>> Looks like a bug in pseudo to me, can you file a bug for that?
>
> Sure.  Filed #7554.

 I'd suggest you look at meta/classes/package.bbclass "fixup_perms" 
 function.

 The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
 function.  I don't know why 'foo' would be, but if it's a standard defined
 variable -- or if 'directory walking' is enabled it could end up doing 
 this as well.

 The control file for this is in meta/files/fs-perms.txt (unless otherwise
 defined by a distribution or other configuration file.)
>>>
>>> Thanks a lot.  You seem to have guided me exactly to what causes the
>>> issue.
>>>

 Format of the file is:

 # The format of this file
 #
 #  
>>> ...

 The default is:
>>> ...
 libexecdir 0755 root root false - - -
>>> ...
>>>
>>> This variable seems to be the cause of problems:
>>>
>>> $ bitbake -e foo | grep libexecdir=
>>> export libexecdir="/usr/lib/foo"
>>>
>>> As far as I understand, package.bbclass may use a user-configured
>>> permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
>>> this is the right "fix" for the case in question.  I'd have to hardcode
>>> the owner of /usr/lib/foo to be "foo", but foo may not be available when
>>> packaging other recipes.
>>
>> Ok, good this answers the question as to "why" it's happening.  You can 
>> easily
>> fix this by adding a configuration specific fs-perms.txt file (can name it
>> anything) that overrides that setting and add it to the 
>> FILESYSTEM_PERMS_TABLES.
>>  You can do this globally in a layer, a distribution or even just a recipe.
>>
>> In your recipe you can likely do something like:
>>
>> FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt"
>> FILESYSTEM_PERMS_TABLES += "${THISDIR}/files/recipe-perms.txt"
>>
>> (Do the ?= first in case it's already set by someone else, then add your 
>> recipe
>> specific perms later)
>>
>> Contents of the "${THISDIR}/files/recipe-perms.txt":
>>
>> ${libexecdir} 0755 myuid mygid true - myuid mygid
>>
>> Then you can even skip the chown -R, as the system will do it for you.
> 
> I actually had tried that, but I got errors -- probably because the
> ownership will be set for each package that installs ${libexecdir}, and
> which is processed before the recipe that actually creates the
> user/group specified for ${libexecdir} in the file pointed by
> FILESYSTEM_PERMS_TABLES.

This is a bug then.  The owner/group correction is supposed to be made AFTER the
user/groups have been added to the system (sysroot) via the adduser.  THAT is a
bug that IMHO should be fixed sooner, rather then later.

It might be as simple as the install sysroot (${D}) configuration with pseudo
isn't pointing to the right /etc/passwd and /etc/group.  I believe it should be
pointing to the one in the regular sysroot repository.

--Mark

>>> Should libexecdir actually be in the `target_path_vars' variable
>>> (package.bbclass)?
>>
>> That is a good question, and something likely worthy of investigating.  
>> Perhaps
>> removing it from the default set is the correct general purpose change.
>>
>> I wouldn't do it on an existing release, but its worth considering at the
>> beginning of a new release.
> 
> Best wishes.
> Mario
> 

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

Re: [OE-core] Ownership issue in package contents

[Mario Domenech Goulart]

On Tue, 31 Mar 2015 15:51:50 -0500 Mark Hatle  wrote:

> On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:
>> 
>> On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle  
>> wrote:
>> 
>>> On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:

 On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross"  
 wrote:

> On 27 March 2015 at 17:31, Mario Domenech Goulart 
>  wrote:
>
> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
> the recipe, ./usr/lib/foo/ in the package is owned by root.
> However, its content has the right ownership.
>
> Looks like a bug in pseudo to me, can you file a bug for that?

 Sure.  Filed #7554.
>>>
>>> I'd suggest you look at meta/classes/package.bbclass "fixup_perms" function.
>>>
>>> The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
>>> function.  I don't know why 'foo' would be, but if it's a standard defined
>>> variable -- or if 'directory walking' is enabled it could end up doing this 
>>> as well.
>>>
>>> The control file for this is in meta/files/fs-perms.txt (unless otherwise
>>> defined by a distribution or other configuration file.)
>> 
>> Thanks a lot.  You seem to have guided me exactly to what causes the
>> issue.
>> 
>>>
>>> Format of the file is:
>>>
>>> # The format of this file
>>> #
>>> #  
>> ...
>>>
>>> The default is:
>> ...
>>> libexecdir  0755 root root false - - -
>> ...
>> 
>> This variable seems to be the cause of problems:
>> 
>> $ bitbake -e foo | grep libexecdir=
>> export libexecdir="/usr/lib/foo"
>> 
>> As far as I understand, package.bbclass may use a user-configured
>> permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
>> this is the right "fix" for the case in question.  I'd have to hardcode
>> the owner of /usr/lib/foo to be "foo", but foo may not be available when
>> packaging other recipes.
>
> Ok, good this answers the question as to "why" it's happening.  You can easily
> fix this by adding a configuration specific fs-perms.txt file (can name it
> anything) that overrides that setting and add it to the 
> FILESYSTEM_PERMS_TABLES.
>  You can do this globally in a layer, a distribution or even just a recipe.
>
> In your recipe you can likely do something like:
>
> FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt"
> FILESYSTEM_PERMS_TABLES += "${THISDIR}/files/recipe-perms.txt"
>
> (Do the ?= first in case it's already set by someone else, then add your 
> recipe
> specific perms later)
>
> Contents of the "${THISDIR}/files/recipe-perms.txt":
>
> ${libexecdir} 0755 myuid mygid true - myuid mygid
>
> Then you can even skip the chown -R, as the system will do it for you.

I actually had tried that, but I got errors -- probably because the
ownership will be set for each package that installs ${libexecdir}, and
which is processed before the recipe that actually creates the
user/group specified for ${libexecdir} in the file pointed by
FILESYSTEM_PERMS_TABLES.

>> Should libexecdir actually be in the `target_path_vars' variable
>> (package.bbclass)?
>
> That is a good question, and something likely worthy of investigating.  
> Perhaps
> removing it from the default set is the correct general purpose change.
>
> I wouldn't do it on an existing release, but its worth considering at the
> beginning of a new release.

Best wishes.
Mario
-- 
http://www.ossystems.com.br
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Ownership issue in package contents

[Mark Hatle]

On 3/31/15 3:33 PM, Mario Domenech Goulart wrote:
> Hi Mark,
> 
> On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle  
> wrote:
> 
>> On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
>>>
>>> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross"  
>>> wrote:
>>>
 On 27 March 2015 at 17:31, Mario Domenech Goulart  
 wrote:

 Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
 the recipe, ./usr/lib/foo/ in the package is owned by root.
 However, its content has the right ownership.

 Looks like a bug in pseudo to me, can you file a bug for that?
>>>
>>> Sure.  Filed #7554.
>>
>> I'd suggest you look at meta/classes/package.bbclass "fixup_perms" function.
>>
>> The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
>> function.  I don't know why 'foo' would be, but if it's a standard defined
>> variable -- or if 'directory walking' is enabled it could end up doing this 
>> as well.
>>
>> The control file for this is in meta/files/fs-perms.txt (unless otherwise
>> defined by a distribution or other configuration file.)
> 
> Thanks a lot.  You seem to have guided me exactly to what causes the
> issue.
> 
>>
>> Format of the file is:
>>
>> # The format of this file
>> #
>> #  
> ...
>>
>> The default is:
> ...
>> libexecdir   0755 root root false - - -
> ...
> 
> This variable seems to be the cause of problems:
> 
> $ bitbake -e foo | grep libexecdir=
> export libexecdir="/usr/lib/foo"
> 
> As far as I understand, package.bbclass may use a user-configured
> permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
> this is the right "fix" for the case in question.  I'd have to hardcode
> the owner of /usr/lib/foo to be "foo", but foo may not be available when
> packaging other recipes.

Ok, good this answers the question as to "why" it's happening.  You can easily
fix this by adding a configuration specific fs-perms.txt file (can name it
anything) that overrides that setting and add it to the FILESYSTEM_PERMS_TABLES.
 You can do this globally in a layer, a distribution or even just a recipe.

In your recipe you can likely do something like:

FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt"
FILESYSTEM_PERMS_TABLES += "${THISDIR}/files/recipe-perms.txt"

(Do the ?= first in case it's already set by someone else, then add your recipe
specific perms later)

Contents of the "${THISDIR}/files/recipe-perms.txt":

${libexecdir} 0755 myuid mygid true - myuid mygid

Then you can even skip the chown -R, as the system will do it for you.

> Should libexecdir actually be in the `target_path_vars' variable
> (package.bbclass)?

That is a good question, and something likely worthy of investigating.  Perhaps
removing it from the default set is the correct general purpose change.

I wouldn't do it on an existing release, but its worth considering at the
beginning of a new release.

--Mark

> Best wishes.
> Mario
> 

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

Re: [OE-core] Ownership issue in package contents

[Mario Domenech Goulart]

Hi Mark,

On Tue, 31 Mar 2015 13:23:00 -0500 Mark Hatle  wrote:

> On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
>> 
>> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross"  
>> wrote:
>> 
>>> On 27 March 2015 at 17:31, Mario Domenech Goulart  
>>> wrote:
>>>
>>> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
>>> the recipe, ./usr/lib/foo/ in the package is owned by root.
>>> However, its content has the right ownership.
>>>
>>> Looks like a bug in pseudo to me, can you file a bug for that?
>> 
>> Sure.  Filed #7554.
>
> I'd suggest you look at meta/classes/package.bbclass "fixup_perms" function.
>
> The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
> function.  I don't know why 'foo' would be, but if it's a standard defined
> variable -- or if 'directory walking' is enabled it could end up doing this 
> as well.
>
> The control file for this is in meta/files/fs-perms.txt (unless otherwise
> defined by a distribution or other configuration file.)

Thanks a lot.  You seem to have guided me exactly to what causes the
issue.

>
> Format of the file is:
>
> # The format of this file
> #
> #  
...
>
> The default is:
...
> libexecdir0755 root root false - - -
...

This variable seems to be the cause of problems:

$ bitbake -e foo | grep libexecdir=
export libexecdir="/usr/lib/foo"

As far as I understand, package.bbclass may use a user-configured
permissions table (via FILESYSTEM_PERMS_TABLES), but I'm not sure if
this is the right "fix" for the case in question.  I'd have to hardcode
the owner of /usr/lib/foo to be "foo", but foo may not be available when
packaging other recipes.

Should libexecdir actually be in the `target_path_vars' variable
(package.bbclass)?

Best wishes.
Mario
-- 
http://www.ossystems.com.br
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] systemd: v219 with stable fixes

[Otavio Salvador]

I am not a heavy user of systemd so I prefer other people (Khem?) to
comment on this ...

On Tue, Mar 31, 2015 at 5:21 PM, Bottazzini, Bruno
 wrote:
> Ping
>
> On Seg, 2015-03-30 at 15:13 -0300, Bruno Bottazzini wrote:
>> Adding patches that fix bugs for 219 version.
>> This will get the same consistency of the stable systemd 219 version.
>>
>> More details:
>> http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v219-stable
>> ---
>>  ...remote-fix-certificate-status-memory-leak.patch |  31 +
>>  ...ournal-remote-fix-client_cert-memory-leak.patch |  35 +
>>  ...0003-tmpfiles-Fix-parse_acl-error-message.patch |  28 +
>>  ...-test-utf8-fix-utf16-tests-on-BE-machines.patch |  26 +
>>  ...iles-avoid-creating-duplicate-acl-entries.patch | 131 +++
>>  .../0006-shared-time-util-fix-gcc5-warning.patch   |  32 +
>>  ...time-test-infinity-parsing-in-nanoseconds.patch |  36 +
>>  .../0008-bootchart-fix-default-init-path.patch |  44 +
>>  ...emctl-bump-NOFILE-only-for-systemctl_main.patch |  44 +
>>  ...0-Make-root-s-home-directory-configurable.patch |  89 +-
>>  ...-util-avoid-freeing-uninitialized-pointer.patch |  37 +
>>  ...11-bootchart-svg-fix-checking-of-list-end.patch |  28 +
>>  ...md-add-getrandom-syscall-numbers-for-MIPS.patch |  38 +
>>  ...aker-dependencies-between-mount-and-devic.patch |  33 +
>>  ...topping-due-to-BindsTo-log-which-unit-cau.patch |  43 +
>>  ...grade-message-about-sysctl-overrides-to-d.patch |  30 +
>>  ...l-add-some-hints-how-to-override-settings.patch |  39 +
>>  .../0017-core-rework-device-state-logic.patch  | 912 
>> +
>>  .../0018-core-fix-return-value-on-OOM.patch|  26 +
>>  ...e-x-machine-unix-prefix-for-the-container.patch |  33 +
>>  ...0-shared-AFS-is-also-a-network-filesystem.patch |  25 +
>>  ...downgrade-unit-type-not-supported-message.patch |  31 +
>>  ...ournal-remote-fix-saving-of-binary-fields.patch |  97 +++
>>  ...ix-Inappropriate-ioctl-for-device-on-ext4.patch |  37 +
>>  ...eplace-VLA-with-alloca-to-make-llvm-happy.patch |  53 ++
>>  ...ietly-ignore-ACLs-on-unsupported-filesyst.patch |  84 ++
>>  ...-assume-ac-when-sys-class-power_supply-is.patch |  30 +
>>  meta/recipes-core/systemd/systemd_219.bb   |  33 +-
>>  28 files changed, 2050 insertions(+), 55 deletions(-)
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0001-journal-remote-fix-certificate-status-memory-leak.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0002-journal-remote-fix-client_cert-memory-leak.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0003-tmpfiles-Fix-parse_acl-error-message.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0004-test-utf8-fix-utf16-tests-on-BE-machines.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0005-tmpfiles-avoid-creating-duplicate-acl-entries.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0006-shared-time-util-fix-gcc5-warning.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0007-test-time-test-infinity-parsing-in-nanoseconds.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0008-bootchart-fix-default-init-path.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0009-systemctl-bump-NOFILE-only-for-systemctl_main.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0010-acl-util-avoid-freeing-uninitialized-pointer.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0011-bootchart-svg-fix-checking-of-list-end.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0012-systemd-add-getrandom-syscall-numbers-for-MIPS.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0013-unit-use-weaker-dependencies-between-mount-and-devic.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0014-unit-When-stopping-due-to-BindsTo-log-which-unit-cau.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0015-sysctl-downgrade-message-about-sysctl-overrides-to-d.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0016-sysctl-add-some-hints-how-to-override-settings.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0017-core-rework-device-state-logic.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0018-core-fix-return-value-on-OOM.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0019-machined-use-x-machine-unix-prefix-for-the-container.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0020-shared-AFS-is-also-a-network-filesystem.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0021-core-downgrade-unit-type-not-supported-message.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0022-journal-remote-fix-saving-of-binary-fields.patch
>>  create mode 100644 
>> meta/recipes-core/systemd/systemd/0023-journal-fix-Inappropriate-ioctl-for-device-on-ext4.patch
>>  create mode 100644 
>> meta/recipes-c

Re: [OE-core] [PATCH] systemd: v219 with stable fixes

[Bottazzini, Bruno]

Ping

On Seg, 2015-03-30 at 15:13 -0300, Bruno Bottazzini wrote:
> Adding patches that fix bugs for 219 version.
> This will get the same consistency of the stable systemd 219 version.
> 
> More details:
> http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v219-stable
> ---
>  ...remote-fix-certificate-status-memory-leak.patch |  31 +
>  ...ournal-remote-fix-client_cert-memory-leak.patch |  35 +
>  ...0003-tmpfiles-Fix-parse_acl-error-message.patch |  28 +
>  ...-test-utf8-fix-utf16-tests-on-BE-machines.patch |  26 +
>  ...iles-avoid-creating-duplicate-acl-entries.patch | 131 +++
>  .../0006-shared-time-util-fix-gcc5-warning.patch   |  32 +
>  ...time-test-infinity-parsing-in-nanoseconds.patch |  36 +
>  .../0008-bootchart-fix-default-init-path.patch |  44 +
>  ...emctl-bump-NOFILE-only-for-systemctl_main.patch |  44 +
>  ...0-Make-root-s-home-directory-configurable.patch |  89 +-
>  ...-util-avoid-freeing-uninitialized-pointer.patch |  37 +
>  ...11-bootchart-svg-fix-checking-of-list-end.patch |  28 +
>  ...md-add-getrandom-syscall-numbers-for-MIPS.patch |  38 +
>  ...aker-dependencies-between-mount-and-devic.patch |  33 +
>  ...topping-due-to-BindsTo-log-which-unit-cau.patch |  43 +
>  ...grade-message-about-sysctl-overrides-to-d.patch |  30 +
>  ...l-add-some-hints-how-to-override-settings.patch |  39 +
>  .../0017-core-rework-device-state-logic.patch  | 912 
> +
>  .../0018-core-fix-return-value-on-OOM.patch|  26 +
>  ...e-x-machine-unix-prefix-for-the-container.patch |  33 +
>  ...0-shared-AFS-is-also-a-network-filesystem.patch |  25 +
>  ...downgrade-unit-type-not-supported-message.patch |  31 +
>  ...ournal-remote-fix-saving-of-binary-fields.patch |  97 +++
>  ...ix-Inappropriate-ioctl-for-device-on-ext4.patch |  37 +
>  ...eplace-VLA-with-alloca-to-make-llvm-happy.patch |  53 ++
>  ...ietly-ignore-ACLs-on-unsupported-filesyst.patch |  84 ++
>  ...-assume-ac-when-sys-class-power_supply-is.patch |  30 +
>  meta/recipes-core/systemd/systemd_219.bb   |  33 +-
>  28 files changed, 2050 insertions(+), 55 deletions(-)
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0001-journal-remote-fix-certificate-status-memory-leak.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0002-journal-remote-fix-client_cert-memory-leak.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0003-tmpfiles-Fix-parse_acl-error-message.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0004-test-utf8-fix-utf16-tests-on-BE-machines.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0005-tmpfiles-avoid-creating-duplicate-acl-entries.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0006-shared-time-util-fix-gcc5-warning.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0007-test-time-test-infinity-parsing-in-nanoseconds.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0008-bootchart-fix-default-init-path.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0009-systemctl-bump-NOFILE-only-for-systemctl_main.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0010-acl-util-avoid-freeing-uninitialized-pointer.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0011-bootchart-svg-fix-checking-of-list-end.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0012-systemd-add-getrandom-syscall-numbers-for-MIPS.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0013-unit-use-weaker-dependencies-between-mount-and-devic.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0014-unit-When-stopping-due-to-BindsTo-log-which-unit-cau.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0015-sysctl-downgrade-message-about-sysctl-overrides-to-d.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0016-sysctl-add-some-hints-how-to-override-settings.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0017-core-rework-device-state-logic.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0018-core-fix-return-value-on-OOM.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0019-machined-use-x-machine-unix-prefix-for-the-container.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0020-shared-AFS-is-also-a-network-filesystem.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0021-core-downgrade-unit-type-not-supported-message.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0022-journal-remote-fix-saving-of-binary-fields.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0023-journal-fix-Inappropriate-ioctl-for-device-on-ext4.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0024-sd-daemon-replace-VLA-with-alloca-to-make-llvm-happy.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0025-tmpfiles-quietly-ignore-ACLs-on-unsupported-filesyst.patch
>  create mode 100644 
> meta/

Re: [OE-core] Ownership issue in package contents

[Otavio Salvador]

On Tue, Mar 31, 2015 at 5:12 PM, Burton, Ross  wrote:
>
> On 31 March 2015 at 19:23, Mark Hatle  wrote:
>>
>> The easiest way to debug all of this is to edit
>> meta/classes/package.bbclass,
>> find the following lines:
>
> Or change the files that are chowned to exist somewhere else that doesn't
> get touched by fixup, like /testing/foo/bar.

This seems to be a design flaw. I understand we ought to have
somewhere to specify a default however the useradd class should
somehow instrument the code for those recipes to be able to override
this.

-- 
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

[OE-core] [PATCH 3/3] distrodata.bbclass/distro_check.py: Support buildtools PN mapping

[Beth Flanagan]

We need to be able to map buildtools- to the original PN.

Signed-off-by: Beth Flanagan 
---
 meta/classes/distrodata.bbclass | 12 
 meta/lib/oe/distro_check.py |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index 6562c86..f540170 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -43,6 +43,10 @@ python do_distrodata_np() {
 pnstripped = pnstripped.replace("nativesdk-", "")
 bb.note("NativeSDK Split: %s" % pnstripped)
 
+if pnstripped.find("buildtools-") != -1:
+pnstripped = pnstripped.split("buildtools-")[1]
+bb.note("buildtools Split: %s" % pnstripped)
+
 if pnstripped.find("-initial") != -1:
 pnstripped = pnstripped.split("-initial")[0]
 bb.note("initial Split: %s" % pnstripped)
@@ -119,6 +123,10 @@ python do_distrodata() {
 pnstripped = pnstripped.replace("nativesdk-", "")
 bb.note("NativeSDK Split: %s" % pnstripped)
 
+if pnstripped.find("buildtools-") != -1:
+pnstripped = pnstripped.split("buildtools-")[1]
+bb.note("buildtools Split: %s" % pnstripped)
+
 if pnstripped.find("-cross") != -1:
 pnstripped = pnstripped.split("-cross")[0]
 bb.note("cross Split: %s" % pnstripped)
@@ -289,6 +297,10 @@ python do_checkpkg() {
 pnstripped = pnstripped.replace("nativesdk-", "")
 bb.note("NativeSDK Split: %s" % pnstripped)
 
+if pnstripped.find("buildtools-") != -1:
+pnstripped = pnstripped.split("buildtools-")[1]
+bb.note("buildtools Split: %s" % pnstripped)
+
 if pnstripped.find("-cross") != -1:
 pnstripped = pnstripped.split("-cross")[0]
 bb.note("cross Split: %s" % pnstripped)
diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index d13783b..88474d0 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -289,6 +289,9 @@ def compare_in_distro_packages_list(distro_check_dir, d):
 if pnstripped.startswith("nativesdk-"):
 pnstripped = pnstripped.split("nativesdk-")[1]
 
+if pnstripped.find("buildtools-") != -1:
+pnstripped = pnstripped.split("buildtools-")[1]
+
 if pnstripped.find("-cross") != -1:
 pnstripped = pnstripped.split("-cross")[0]
 
-- 
1.9.1

-
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[OE-core] [PATCH 1/3] distrodata.bbclass/distro_check.py: Fix splits

[Beth Flanagan]

When we're trying to get the name of the package for
nativesdk/cross/crosssdk this bit of code fails to do
this right for things like nativesdk-foo-cross.

This ensures that a package like nativesdk-glibc-initial
maps to glibc and not to nativesdk-glibc

Signed-off-by: Beth Flanagan 
---
 meta/classes/distrodata.bbclass | 105 ++--
 meta/lib/oe/distro_check.py |  46 --
 2 files changed, 67 insertions(+), 84 deletions(-)

diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index 83aa381..10e59d3 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -25,37 +25,30 @@ python do_distrodata_np() {
 distro_check_dir = os.path.join(tmpdir, "distro_check")
 datetime = localdata.getVar('DATETIME', True)
 dist_check.update_distro_data(distro_check_dir, datetime)
+pnstripped = pn
 
-if pn.find("-native") != -1:
-pnstripped = pn.split("-native")
+if pnstripped.find("-native") != -1:
+pnstripped = pnstripped.split("-native")[0]
 bb.note("Native Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
 
-if pn.find("-cross") != -1:
-pnstripped = pn.split("-cross")
+if pnstripped.find("-cross") != -1:
+pnstripped = pnstripped.split("-cross")[0]
 bb.note("cross Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
 
-if pn.find("-crosssdk") != -1:
-pnstripped = pn.split("-crosssdk")
-bb.note("cross Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
+if pnstripped.find("-crosssdk") != -1:
+pnstripped = pnstripped.split("-crosssdk")[0]
+bb.note("crosssdk Split: %s" % pnstripped)
 
-if pn.startswith("nativesdk-"):
-pnstripped = pn.replace("nativesdk-", "")
+if pnstripped.startswith("nativesdk-"):
+pnstripped = pnstripped.replace("nativesdk-", "")
 bb.note("NativeSDK Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
-
 
-if pn.find("-initial") != -1:
-pnstripped = pn.split("-initial")
+if pnstripped.find("-initial") != -1:
+pnstripped = pnstripped.split("-initial")[0]
 bb.note("initial Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
+
+localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
+bb.data.update_data(localdata)
 
 """generate package information from .bb file"""
 pname = localdata.getVar('PN', True)
@@ -112,36 +105,30 @@ python do_distrodata() {
 
 pn = d.getVar("PN", True)
 bb.note("Package Name: %s" % pn)
+pnstripped = pn
 
-if pn.find("-native") != -1:
-pnstripped = pn.split("-native")
+if pnstripped.find("-native") != -1:
+pnstripped = pnstripped.split("-native")[0]
 bb.note("Native Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
 
-if pn.startswith("nativesdk-"):
-pnstripped = pn.replace("nativesdk-", "")
+if pnstripped.startswith("nativesdk-"):
+pnstripped = pnstripped.replace("nativesdk-", "")
 bb.note("NativeSDK Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
 
-if pn.find("-cross") != -1:
-pnstripped = pn.split("-cross")
+if pnstripped.find("-cross") != -1:
+pnstripped = pnstripped.split("-cross")[0]
 bb.note("cross Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
 
-if pn.find("-crosssdk") != -1:
-pnstripped = pn.split("-crosssdk")
-bb.note("cross Split: %s" % pnstripped)
-localdata.setVar('OVERRIDES', "pn-" + pnstripped[0] + ":" + 
d.getVar('OVERRIDES', True))
-bb.data.update_data(localdata)
+if pnstripped.find("-crosssdk") != -1:
+pnstripped = pnstripped.split("-crosssdk")[0]
+bb.note("crosssdk Split: %s" % pnstripped)
 
- 

Re: [OE-core] Ownership issue in package contents

[Burton, Ross]

On 31 March 2015 at 19:23, Mark Hatle  wrote:

> The easiest way to debug all of this is to edit
> meta/classes/package.bbclass,
> find the following lines:
>

Or change the files that are chowned to exist somewhere else that doesn't
get touched by fixup, like /testing/foo/bar.

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

[OE-core] [PATCH 2/3] distrodata.bbclass/distro_check.py: Support -dummy mapping of PN

[Beth Flanagan]

Strip out -dummy in order to map to the base PN of dummy packages

Signed-off-by: Beth Flanagan 
---
 meta/classes/distrodata.bbclass | 12 
 meta/lib/oe/distro_check.py |  7 ++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index 10e59d3..6562c86 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -47,6 +47,10 @@ python do_distrodata_np() {
 pnstripped = pnstripped.split("-initial")[0]
 bb.note("initial Split: %s" % pnstripped)
 
+if pnstripped.find("-dummy") != -1:
+pnstripped = pnstripped.split("-dummy")
+bb.note("dummy Split: %s" % pnstripped)
+
 localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
 bb.data.update_data(localdata)
 
@@ -127,6 +131,10 @@ python do_distrodata() {
 pnstripped = pnstripped.split("-initial")[0]
 bb.note("initial Split: %s" % pnstripped)
 
+if pnstripped.find("-dummy") != -1:
+pnstripped = pnstripped.split("-dummy")[0]
+bb.note("dummy Split: %s" % pnstripped)
+
 localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
 bb.data.update_data(localdata)
 
@@ -293,6 +301,10 @@ python do_checkpkg() {
 pnstripped = pnstripped.split("-initial")[0]
 bb.note("initial Split: %s" % pnstripped)
 
+if pnstripped.find("-dummy") != -1:
+pnstripped = pnstripped.split("-dummy")[0]
+bb.note("dummy Split: %s" % pnstripped)
+
 localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
 bb.data.update_data(localdata)
 
diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index f754991..d13783b 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -279,7 +279,9 @@ def compare_in_distro_packages_list(distro_check_dir, d):
 recipe_name = d.getVar('PN', True)
 bb.note("Checking: %s" % pn)
 pnstripped = pn
-trim_dict = dict({"-native":"-native", "-cross":"-cross", 
"-crosssdk":"-crosssdk" ,"-initial":"-initial"})
+trim_dict = dict({"-native":"-native", "-cross":"-cross", \
+  "-crosssdk":"-crosssdk" ,"-initial":"-initial", \
+  "-dummy":"-dummy"})
 
 if pnstripped.find("-native") != -1:
 pnstripped = pnstripped.split("-native")[0]
@@ -296,6 +298,9 @@ def compare_in_distro_packages_list(distro_check_dir, d):
 if pnstripped.find("-initial") != -1:
 pnstripped = pnstripped.split("-initial")[0]
 
+if pnstripped.find("-dummy") != -1:
+pnstripped = pnstripped.split("-dummy")[0]
+
 localdata.setVar('OVERRIDES', "pn-" + pnstripped + ":" + 
d.getVar('OVERRIDES', True))
 
 bb.data.update_data(localdata)
-- 
1.9.1

-
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[OE-core] [PATCH 0/3] distrodata.bbclass/distro_check.py: Fix PN mapping

[Beth Flanagan]

Last night while running distrodata, I noticed some incorrect results that had
to do with how we were trying to get the mapping to the base PN name of
packages.

Part of this is due to how distrodata was splitting PNs to remove nativesdk-,
cross-, crosssdk-, etc. This occurred on packages that had the need to strip out
multiple of these strings (nativesdk-cross- for example).

The first patch ensures that in these cases we grab the distrodate from
the base PN.

The final two patches support -dummy and buildtools- packages, so that they 
also map.

Beth Flanagan (3):
  distrodata.bbclass/distro_check.py: Fix splits
  distrodata.bbclass/distro_check.py: Support -dummy mapping of PN
  distrodata.bbclass/distro_check.py: Support buildtools PN mapping

 meta/classes/distrodata.bbclass | 127 ++--
 meta/lib/oe/distro_check.py |  54 +
 2 files changed, 98 insertions(+), 83 deletions(-)

-- 
1.9.1

-
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[OE-core] [master-next][PATCH] pinentry: update to 9.1

[Armin Kuster]

Fix build problems on AIX.
Update to automake 1.14.

remove "PR"

Signed-off-by: Armin Kuster 
---
 .../pinentry/{pinentry_0.9.0.bb => pinentry_0.9.1.bb}   | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)
 rename meta/recipes-support/pinentry/{pinentry_0.9.0.bb => pinentry_0.9.1.bb} 
(86%)

diff --git a/meta/recipes-support/pinentry/pinentry_0.9.0.bb 
b/meta/recipes-support/pinentry/pinentry_0.9.1.bb
similarity index 86%
rename from meta/recipes-support/pinentry/pinentry_0.9.0.bb
rename to meta/recipes-support/pinentry/pinentry_0.9.1.bb
index 10b329b..08588dd 100644
--- a/meta/recipes-support/pinentry/pinentry_0.9.0.bb
+++ b/meta/recipes-support/pinentry/pinentry_0.9.1.bb
@@ -8,14 +8,12 @@ HOMEPAGE = 
"http://www.gnupg.org/related_software/pinentry/index.en.html";
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=cbbd794e2a0a289b9dfcc9f513d1996e"
 
-PR = "r1"
-
 inherit autotools
 
 SRC_URI = "ftp://ftp.gnupg.org/gcrypt/${BPN}/${BPN}-${PV}.tar.bz2";
 
-SRC_URI[md5sum] = "40a05856cb3accf6679987b7899b0f5a"
-SRC_URI[sha256sum] = 
"90045a07ab8e1a8e1ecf5d19b51691f195525e579fa5d71d7e92c120b05490ab"
+SRC_URI[md5sum] = "d224d031130aedb44b05164cb04ed88b"
+SRC_URI[sha256sum] = 
"9cd08e856b395df3adc7124170b53f77c6d5c8bf88e899e818648ec70d3e9695"
 
 EXTRA_OECONF = "--disable-rpath \
--disable-dependency-tracking \
-- 
1.9.1

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

Re: [OE-core] Ownership issue in package contents

[Mark Hatle]

On 3/31/15 12:20 PM, Mario Domenech Goulart wrote:
> Hi Ross,
> 
> On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross"  
> wrote:
> 
>> On 27 March 2015 at 17:31, Mario Domenech Goulart  
>> wrote:
>>
>> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
>> the recipe, ./usr/lib/foo/ in the package is owned by root.
>> However, its content has the right ownership.
>>
>> Looks like a bug in pseudo to me, can you file a bug for that?
> 
> Sure.  Filed #7554.

I'd suggest you look at meta/classes/package.bbclass "fixup_perms" function.

The ${D}${libdir} (and above) are "corrected" to be 'root:root' by this
function.  I don't know why 'foo' would be, but if it's a standard defined
variable -- or if 'directory walking' is enabled it could end up doing this as 
well.

The control file for this is in meta/files/fs-perms.txt (unless otherwise
defined by a distribution or other configuration file.)

Format of the file is:

# The format of this file
#
#  
#
# or
#
# link 
#
# : directory path
# : mode for directory
# :  uid for directory
# :  gid for directory
# : recursively walk the directory?  true or false
# : if walking, new mode for files
# :  if walking, new uid for files
# :  if walking, new gid for files
# : turn the directory into a symlink point to target

The default is:

base_prefix 0755 root root false - - -
prefix  0755 root root false - - -
exec_prefix 0755 root root false - - -
base_bindir 0755 root root false - - -
base_sbindir0755 root root false - - -
base_libdir 0755 root root false - - -
datadir 0755 root root false - - -
sysconfdir  0755 root root false - - -
servicedir  0755 root root false - - -
sharedstatedir  0755 root root false - - -
localstatedir   0755 root root false - - -
infodir 0755 root root false - - -
mandir  0755 root root false - - -
docdir  0755 root root false - - -
bindir  0755 root root false - - -
sbindir 0755 root root false - - -
libexecdir  0755 root root false - - -
libdir  0755 root root false - - -
includedir  0755 root root false - - -
oldincludedir   0755 root root false - - -

The easiest way to debug all of this is to edit meta/classes/package.bbclass,
find the following lines:

# Debug -- list out in-memory table
#for dir in fs_perms_table:
#bb.note("Fixup Perms: %s: %s" % (dir, str(fs_perms_table[dir])))

remove the '#' from the 'for' and following lines, then inspect the table from
the build logs.

Similarly, you can trace the actual fixups, by searching for def fix_perms(path,
mode, uid, gid, dir):, and removing the comment from the two bb.note entries.

This should give you an idea if this code is replacing your value with it's own.

(I give this a VERY low probability that it's a bug in pseudo.)

--Mark

> Best wishes.
> Mario
> 

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

Re: [OE-core] [PATCH] siteinfo: Add x86_64-elf support

[Khem Raj]

> On Mar 31, 2015, at 8:22 AM, Richard Purdie 
>  wrote:
> 
> Teach siteinfo about x86_64-elf so that baremetal toolchains parse/build.
> 
> Signed-off-by: Richard Purdie 
> 
> diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
> index 2c1f9d0..5fd99bf 100644
> --- a/meta/classes/siteinfo.bbclass
> +++ b/meta/classes/siteinfo.bbclass
> @@ -95,6 +95,7 @@ def siteinfo_data(d):
> "x86_64-linux": "bit-64",
> "x86_64-linux-musl": "x86_64-linux bit-64",
> "x86_64-linux-uclibc": "bit-64",
> +"x86_64-elf": "bit-64”,

is 32bit bare metal already taken care of ?

> "x86_64-linux-gnu": "bit-64 x86_64-linux",
> "x86_64-linux-gnux32": "bit-32 ix86-common x32-linux",
> "x86_64-mingw32": "bit-64",
> 
> 
> -- 
> ___
> 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] insane: Add baremetal mappings to the QA arch test

[Khem Raj]

> On Mar 31, 2015, at 8:23 AM, Richard Purdie 
>  wrote:
> 
> Add mappings for i586-elf, x86_64-elf and arm-eabi to binary lookup
> table which allows for a variety of baremetal toolchain generation.
> 
> Signed-off-by: Richard Purdie 
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 061ce5b..d0c6fea 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -53,6 +53,13 @@ def package_qa_get_machine_dict():
> "darwin9" : { 
> "arm" :   (40, 0,0,  True,
>   32),
>   },
> +"eabi" : { 
> +"arm" :   (40, 0,0,  True,   
>32),
> +  },

IIRC fsl ppc also uses eabi for baremetal

> +"elf" : { 
> +"i586" :  (3,  0,0,  True,   
>32),
> +"x86_64": (62, 0,0,  True,   
>64),
> +  },
> "linux" : { 
> "aarch64" :   (183,0,0,  True,
>   64),
> "aarch64_be" :(183,0,0,  False,   
>   64),
> 
> 
> -- 
> ___
> 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] Ownership issue in package contents

[Mario Domenech Goulart]

Hi Ross,

On Tue, 31 Mar 2015 14:50:06 +0100 "Burton, Ross"  wrote:

> On 27 March 2015 at 17:31, Mario Domenech Goulart  
> wrote:
>
> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
> the recipe, ./usr/lib/foo/ in the package is owned by root.
> However, its content has the right ownership.
>
> Looks like a bug in pseudo to me, can you file a bug for that?

Sure.  Filed #7554.

Best wishes.
Mario
-- 
http://www.ossystems.com.br
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package_manager: call createrepo with --dbpath pointing inside WORKDIR

[Mark Hatle]

On 3/30/15 7:16 PM, Ed Bartosh wrote:
> Rpm database in staging area is used only by createrepo.
> createrepo fails with the error
> "rpmdb: BDB0060 PANIC: fatal region error detected"
> if rpm database is broken during previous run of createrepo.
> 
> Made createrepo to create rpm db in $WORKDIR/rpmdb/ from scratch
> for every build. This should potentially fix the failure.
> 
> [YOCTO #6571]
> 
> Signed-off-by: Ed Bartosh 
> ---
>  meta/lib/oe/package_manager.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
> index 743c7cb..2461acd 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -110,12 +110,16 @@ class RpmIndexer(Indexer):
>  rpm_createrepo = bb.utils.which(os.getenv('PATH'), "createrepo")
>  index_cmds = []
>  rpm_dirs_found = False
> +dbpath = os.path.join(self.d.getVar('WORKDIR', True), 'rpmdb')
> +if os.path.exists(dbpath):
> +bb.utils.remove(dbpath, True)
>  for arch in archs:
>  arch_dir = os.path.join(self.deploy_dir, arch)
>  if not os.path.isdir(arch_dir):
>  continue
>  
> -index_cmds.append("%s --update -q %s" % (rpm_createrepo, 
> arch_dir))
> +index_cmds.append("%s --dbpath %s --update -q %s" % \
> + (rpm_createrepo, dbpath, arch_dir))

I'd suggest that the dbpath be made arch specific this would eliminate any
serialization that may occur with even simple DB locks.

--dbpath %s/%s 

--Mark

>  
>  rpm_dirs_found = True
>  
> 

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

[OE-core] package update staging

[akuster808]

Morning all,

now that fido is nearing, what is the best method for staging package 
updates meant for oe-core?


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

[OE-core] insane: Add baremetal mappings to the QA arch test

[Richard Purdie]

Add mappings for i586-elf, x86_64-elf and arm-eabi to binary lookup
table which allows for a variety of baremetal toolchain generation.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 061ce5b..d0c6fea 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -53,6 +53,13 @@ def package_qa_get_machine_dict():
 "darwin9" : { 
 "arm" :   (40, 0,0,  True, 
 32),
   },
+"eabi" : { 
+"arm" :   (40, 0,0,  True, 
 32),
+  },
+"elf" : { 
+"i586" :  (3,  0,0,  True, 
 32),
+"x86_64": (62, 0,0,  True, 
 64),
+  },
 "linux" : { 
 "aarch64" :   (183,0,0,  True, 
 64),
 "aarch64_be" :(183,0,0,  False,
 64),


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

[OE-core] [PATCH] siteinfo: Add x86_64-elf support

[Richard Purdie]

Teach siteinfo about x86_64-elf so that baremetal toolchains parse/build.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 2c1f9d0..5fd99bf 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -95,6 +95,7 @@ def siteinfo_data(d):
 "x86_64-linux": "bit-64",
 "x86_64-linux-musl": "x86_64-linux bit-64",
 "x86_64-linux-uclibc": "bit-64",
+"x86_64-elf": "bit-64",
 "x86_64-linux-gnu": "bit-64 x86_64-linux",
 "x86_64-linux-gnux32": "bit-32 ix86-common x32-linux",
 "x86_64-mingw32": "bit-64",


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

Re: [OE-core] Ownership issue in package contents

[Burton, Ross]

On 27 March 2015 at 17:31, Mario Domenech Goulart 
wrote:

> Note that, although I run "chown -R foo:foo ${D}${libdir}/foo" in
> the recipe, ./usr/lib/foo/ in the package is owned by root.
> However, its content has the right ownership.
>

Looks like a bug in pseudo to me, can you file a bug for that?

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

Re: [OE-core] Verification on how TARGET_CFLAGS is set

[Burton, Ross]

On 31 March 2015 at 13:28, Bryan Evenson  wrote:

> Is that all that it is?  I was under the impression that adding -g adds
> the debug symbols to the executable, not just the hooks to include the
> debug symbols.  If the -g flag really does just add a few bytes to each
> executable, then I won't worry about it.
>

At build time it adds the full debug symbols to the executable, but at
packaging time we split out the debugging information to separate files and
then separate packages.  So the difference between a binary produced
without -g and with -g but with debug info split is just the identifiers so
that GDB can find the debug symbols.

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

Re: [OE-core] Verification on how TARGET_CFLAGS is set

[Bryan Evenson]

Richard and Mark,

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Richard Purdie
> Sent: Monday, March 30, 2015 5:43 PM
> To: Mark Hatle
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] Verification on how TARGET_CFLAGS is set
> 
> On Mon, 2015-03-30 at 15:37 -0500, Mark Hatle wrote:
> > On 3/30/15 3:27 PM, Richard Purdie wrote:
> > > On Mon, 2015-03-30 at 13:09 +, Bryan Evenson wrote:
> > >> I am about to upgrade to the dizzy branch.  I have a built a bootable
> > >> image on my test build machine, and now I'm going to be applying
> > >> changes to the system I use for building production images.  I'm
> > >> planning on deleting my tmp directory to force a re-build of
> > >> everything.  Since I'm rebuilding everything anyway, I'm taking a
> > >> deeper look at the CFLAGS related settings and I'm getting a little
> > >> lost in the logic.  I'd like to verify these settings before I start
> > >> rebuilding everything.
> > >>
> > >> If I'm following the default logic correctly in bitbake.conf, by
> > >> default TARGET_CFLAGS will be set to "-O2 -pipe -g
> > >> -feliminate-unused-debug-types".  I want the default TARGET_CFLAGS
> for
> > >> my production image to be "-O2 -pipe".  What's the suggested variable
> > >> to change, and where, to get this final value?  Do I set TARGET_CFLAGS
> > >> directly, or do I set SELECTED_OPTIMIZATIONS or even
> > >> FULL_OPTIMIZATIONS?  Do I set it in local.conf or should I be setting
> > >> it somewhere else?
> > >
> > > If I remember rightly, you need the -g option there to generate the -dbg
> > > packages correctly. The target system binaries won't change since we
> > > separate out the debug data into separate files as part of the packaging
> > > process.
> > >
> > > You therefore can gain some build performance from turning that off but
> > > your runtime won't alter much (other than the debuglink ID which is a
> > > few bytes).
> >
> > I strongly caution people against removing '-g' from their production 
> > builds.
> > If you do, you will no longer have any way to do any type of 
> > production/field
> > debug.  As Richard indicated the -g will cause the symbols and debug 
> > information
> > to get separated into special -dbg packages that you generally don't 
> > distribute
> > on a production device -- but those same -dbg package (preserved) can be 
> > later
> > used for debugging of production devices.

In my situation this is kind of a moot point, as I've never been able to 
successfully get gdb to work.  It has been a while since I've tried, so I guess 
I could give it another go.

> >
> > This is why the default is what it is.
> >
> > The difference in executable size between -g (split debug) and w/o -g, is
> > usually around 15 - 30 bytes.  Roughly the length of the path to the
> executable
> > and/or library plus ".debug/" (7 characters)
> 
> Are you sure its even that? I thought it was literally just the debug ID
> code and the paths to debug were assumed by the debug tools which would
> search several locations for a matching ID?

Is that all that it is?  I was under the impression that adding -g adds the 
debug symbols to the executable, not just the hooks to include the debug 
symbols.  If the -g flag really does just add a few bytes to each executable, 
then I won't worry about it.

Regards,
Bryan

> 
> Cheers,
> 
> Richard
> 
> --
> ___
> 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] util-linux: add lastb.1 and nologin.8 to update-alternatives

[Matthieu Crapet]

/usr/share/man/man1/lastb.1
is also provided by sysvinit recipe.

/usr/share/man/man8/nologin.8
is also provided by shadow recipe.

Signed-off-by: Matthieu Crapet 
---
 meta/recipes-core/util-linux/util-linux.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 10b14b3..2d17fa2 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -186,11 +186,13 @@ ALTERNATIVE_LINK_NAME[mkfs.minix] = 
"${base_sbindir}/mkfs.minix"
 ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
 ALTERNATIVE_LINK_NAME[sulogin] = "${base_sbindir}/sulogin"
 
-ALTERNATIVE_${PN}-doc = "mountpoint.1 last.1 mesg.1 wall.1 sulogin.8 
utmpdump.1 reset.1"
+ALTERNATIVE_${PN}-doc = "mountpoint.1 last.1 lastb.1 mesg.1 wall.1 nologin.8 
sulogin.8 utmpdump.1 reset.1"
 
 ALTERNATIVE_LINK_NAME[last.1] = "${mandir}/man1/last.1"
+ALTERNATIVE_LINK_NAME[lastb.1] = "${mandir}/man1/lastb.1"
 ALTERNATIVE_LINK_NAME[mesg.1] = "${mandir}/man1/mesg.1"
 ALTERNATIVE_LINK_NAME[mountpoint.1] = "${mandir}/man1/mountpoint.1"
+ALTERNATIVE_LINK_NAME[nologin.8] = "${mandir}/man8/nologin.8"
 ALTERNATIVE_LINK_NAME[reset.1] = "${mandir}/man1/reset.1"
 ALTERNATIVE_LINK_NAME[sulogin.8] = "${mandir}/man8/sulogin.8"
 ALTERNATIVE_LINK_NAME[utmpdump.1] = "${mandir}/man1/utmpdump.1"
-- 
1.9.1

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

Re: [OE-core] [PATCH] package_manager: call createrepo with --dbpath pointing inside WORKDIR

[Richard Purdie]

On Tue, 2015-03-31 at 03:16 +0300, Ed Bartosh wrote:
> Rpm database in staging area is used only by createrepo.
> createrepo fails with the error
> "rpmdb: BDB0060 PANIC: fatal region error detected"
> if rpm database is broken during previous run of createrepo.
> 
> Made createrepo to create rpm db in $WORKDIR/rpmdb/ from scratch
> for every build. This should potentially fix the failure.
> 
> [YOCTO #6571]
> 
> Signed-off-by: Ed Bartosh 
> ---
>  meta/lib/oe/package_manager.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
> index 743c7cb..2461acd 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -110,12 +110,16 @@ class RpmIndexer(Indexer):
>  rpm_createrepo = bb.utils.which(os.getenv('PATH'), "createrepo")
>  index_cmds = []
>  rpm_dirs_found = False
> +dbpath = os.path.join(self.d.getVar('WORKDIR', True), 'rpmdb')
> +if os.path.exists(dbpath):
> +bb.utils.remove(dbpath, True)
>  for arch in archs:
>  arch_dir = os.path.join(self.deploy_dir, arch)
>  if not os.path.isdir(arch_dir):
>  continue
>  
> -index_cmds.append("%s --update -q %s" % (rpm_createrepo, 
> arch_dir))
> +index_cmds.append("%s --dbpath %s --update -q %s" % \
> + (rpm_createrepo, dbpath, arch_dir))
>  
>  rpm_dirs_found = True

Do we need to add arch to dbpath here to avoid races between the
separate createrepo processes?

Cheers,

Richard


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

Re: [OE-core] [PATCH v2] libart-lgpl: add art_config.h for armeb/aarch64be/aarch64be_32

[Burton, Ross]

This is queued in master-next and will be in fido.

Ross

On 31 March 2015 at 11:47, Krishnanjanappa, Jagadeesh <
jagadeesh.krishnanjana...@caviumnetworks.com> wrote:

> ping
>
> Regards,
> Jagadeesh
> 
> From: Krishnanjanappa, Jagadeesh
> Sent: Thursday, March 26, 2015 9:09 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Krishnanjanappa, Jagadeesh
> Subject: [OE-core][PATCH v2] libart-lgpl: add art_config.h for
> armeb/aarch64be/aarch64be_32
>
> From: "Krishnanjanappa, Jagadeesh" <
> jagadeesh.krishnanjana...@caviumnetworks.com>
>
> The preprocessor macro values present in art_config.h
> differ for individual architectures, basically libart-lgpl recipe will
> pick up correct art_config.h file based on
>
> ART_CONFIG = "${HOST_ARCH}/art_config.h"
>
> and thereby having correct preprocessor macros definition
> of each architectures.
>
> Signed-off-by: Krishnanjanappa, Jagadeesh <
> jagadeesh.krishnanjana...@caviumnetworks.com>
> ---
>  meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h| 10
> ++
>  meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h | 10
> ++
>  meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h| 10
> ++
>  3 files changed, 30 insertions(+)
>  create mode 100644
> meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
>  create mode 100644
> meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
>  create mode 100644 meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h
>
> diff --git a/meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
> b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
> new file mode 100644
> index 000..500ffc3
> --- /dev/null
> +++ b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
> @@ -0,0 +1,10 @@
> +/* Automatically generated by gen_art_config.c */
> +
> +#define ART_SIZEOF_CHAR 1
> +#define ART_SIZEOF_SHORT 2
> +#define ART_SIZEOF_INT 4
> +#define ART_SIZEOF_LONG 8
> +
> +typedef unsigned char art_u8;
> +typedef unsigned short art_u16;
> +typedef unsigned int art_u32;
> diff --git
> a/meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
> b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
> new file mode 100644
> index 000..b0e74ad
> --- /dev/null
> +++ b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
> @@ -0,0 +1,10 @@
> +/* Automatically generated by gen_art_config.c */
> +
> +#define ART_SIZEOF_CHAR 1
> +#define ART_SIZEOF_SHORT 2
> +#define ART_SIZEOF_INT 4
> +#define ART_SIZEOF_LONG 4
> +
> +typedef unsigned char art_u8;
> +typedef unsigned short art_u16;
> +typedef unsigned int art_u32;
> diff --git a/meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h
> b/meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h
> new file mode 100644
> index 000..b0e74ad
> --- /dev/null
> +++ b/meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h
> @@ -0,0 +1,10 @@
> +/* Automatically generated by gen_art_config.c */
> +
> +#define ART_SIZEOF_CHAR 1
> +#define ART_SIZEOF_SHORT 2
> +#define ART_SIZEOF_INT 4
> +#define ART_SIZEOF_LONG 4
> +
> +typedef unsigned char art_u8;
> +typedef unsigned short art_u16;
> +typedef unsigned int art_u32;
> --
> 1.8.2.3
>
> --
> ___
> 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] [PATCH v2] libart-lgpl: add art_config.h for armeb/aarch64be/aarch64be_32

[Krishnanjanappa, Jagadeesh]

ping

Regards,
Jagadeesh

From: Krishnanjanappa, Jagadeesh
Sent: Thursday, March 26, 2015 9:09 PM
To: openembedded-core@lists.openembedded.org
Cc: Krishnanjanappa, Jagadeesh
Subject: [OE-core][PATCH v2] libart-lgpl: add art_config.h for 
armeb/aarch64be/aarch64be_32

From: "Krishnanjanappa, Jagadeesh" 


The preprocessor macro values present in art_config.h
differ for individual architectures, basically libart-lgpl recipe will
pick up correct art_config.h file based on

ART_CONFIG = "${HOST_ARCH}/art_config.h"

and thereby having correct preprocessor macros definition
of each architectures.

Signed-off-by: Krishnanjanappa, Jagadeesh 

---
 meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h| 10 ++
 meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h | 10 ++
 meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h| 10 ++
 3 files changed, 30 insertions(+)
 create mode 100644 meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
 create mode 100644 
meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
 create mode 100644 meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h

diff --git a/meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h 
b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
new file mode 100644
index 000..500ffc3
--- /dev/null
+++ b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be/art_config.h
@@ -0,0 +1,10 @@
+/* Automatically generated by gen_art_config.c */
+
+#define ART_SIZEOF_CHAR 1
+#define ART_SIZEOF_SHORT 2
+#define ART_SIZEOF_INT 4
+#define ART_SIZEOF_LONG 8
+
+typedef unsigned char art_u8;
+typedef unsigned short art_u16;
+typedef unsigned int art_u32;
diff --git a/meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h 
b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
new file mode 100644
index 000..b0e74ad
--- /dev/null
+++ b/meta/recipes-gnome/gnome/libart-lgpl/aarch64be_32/art_config.h
@@ -0,0 +1,10 @@
+/* Automatically generated by gen_art_config.c */
+
+#define ART_SIZEOF_CHAR 1
+#define ART_SIZEOF_SHORT 2
+#define ART_SIZEOF_INT 4
+#define ART_SIZEOF_LONG 4
+
+typedef unsigned char art_u8;
+typedef unsigned short art_u16;
+typedef unsigned int art_u32;
diff --git a/meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h 
b/meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h
new file mode 100644
index 000..b0e74ad
--- /dev/null
+++ b/meta/recipes-gnome/gnome/libart-lgpl/armeb/art_config.h
@@ -0,0 +1,10 @@
+/* Automatically generated by gen_art_config.c */
+
+#define ART_SIZEOF_CHAR 1
+#define ART_SIZEOF_SHORT 2
+#define ART_SIZEOF_INT 4
+#define ART_SIZEOF_LONG 4
+
+typedef unsigned char art_u8;
+typedef unsigned short art_u16;
+typedef unsigned int art_u32;
--
1.8.2.3

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

Re: [OE-core] Not selecting as installing it would break existing dependencies

[Mike Looijmans]

On 30-03-15 21:16, Alejandro del Castillo wrote:

Sounds like you hit an already reported bug:

 https://code.google.com/p/opkg/issues/detail?id=142

It is currently targeted for the 0.3 release, but I am not sure if Paul is
going to be able to get to it on the 0.3 timeframe. Could you add details
to the bug report (how to reproduce steps would be great)? If Paul doesn't
get to it on the 0.3 timeframe, I'll take care of it on the next release.


It looks a lot like the problem described there, so I think it's a safe bet to 
say that they're one and the same.


As for steps to reproduce, well, it does that for some packages but not for 
others, and I haven't been able to figure out what triggers it. The common 
factor appears to be that it usually concerns libraries, i.e. packages that 
the user didn't select but where there because of dependencies. If I find a 
way to trigger it, i'll add that to the bug description.


Kind regards,
Mike.




cheers,

-Alejandro




From:   Mike Looijmans 
To: Alejandro del Castillo ,
Cc: openembedded-core@lists.openembedded.org,
openembedded-core-boun...@lists.openembedded.org
Date:   03/28/2015 08:04 AM
Subject:Re: [OE-core] Not selecting  as
installing it would break existing dependencies



On 27-03-15 22:21, Alejandro del Castillo wrote:

openembedded-core-boun...@lists.openembedded.org wrote on 03/24/2015
12:16:05 PM:


From: Mike Looijmans 
To: openembedded-core@lists.openembedded.org,
Date: 03/24/2015 12:16 PM
Subject: [OE-core] Not selecting  as
installing it would break existing dependencies
Sent by: openembedded-core-boun...@lists.openembedded.org

After upgrading a library to a newer version, for example, something
called libdvbsi++ from 0.3.6 to 0.3.7, running opkg upgrade outputs the
following cryptic error message:

Not selecting libdvbsi++1 0.3.6 as installing it would break existing
dependencies.


When opkg runs, it creates a list of all the available packages on the
configured repos + all the installed packages. During an upgrade, it

goes

through the process of finding the best upgrade match for each installed
package, searching on the master list. The process goes through a series
of checks for each candidate, like making sure the archs are compatible,
and making sure installing a candidate won't break existing installed
packages. In your case, opkg determines there are 2 candidates,
libdvbsi++0.3.6 and libdvbsi++0.3.7. While evaluating libdvbsi++0.3.6,

the

pkg_breaks_reverse_dep check fails, triggering the message shown above
(and removing the candidate).


Adding "-V2" to opkg upgrade expands that with the following message:

opkg_prepare_upgrade_pkg: Package libdvbsi++1 (0.3.7-r2.0) installed in
root is up to date.

So apparently it knows about the later version, so why complain about
the old one?


The function that returns the best candidate match correctly returns
libdvbsi++1 0.3.7. It then compares it against what's already installed.
The DEBUG message above shows that the best candidate found is already
installed on the system.



There is only one package that (r)depends on that lib (enigma2).

Nothing



else needs it.

This often happens with other packages as well. Is this a bug in opkg,
or is it trying to tell us we're doing something wrong?


It is not a bug, the message is harmless as it is only pointing to the
reason why one of the possible upgrade candidates was discarded.


But why does this message keep coming back, even months after the
upgrade that installed 0.3.7?
The 0.3.6 version is no longer installed, it is no longer in the feeds,
but opkg still keeps whining about it. A bit of searching in the
filesystem of the box reveals that it is only named in a file named
"/var/lib/opkg/status", which contains the following lines:

Package: libdvbsi++1
Version: 0.3.7-r2.0
Depends: libgcc1 (>= 4.9.1), libstdc++6 (>= 4.9.1), libc6 (>= 2.20)
Provides: libdvbsi++
Status: unknown ok installed
Architecture: mips32el
Installed-Time: 1427216569
Auto-Installed: yes

Package: libdvbsi++1
Version: 0.3.6-r1.2
Depends: libgcc1 (>= 4.9.1), libstdc++6 (>= 4.9.1), libc6 (>= 2.20)
Provides: libdvbsi++
Status: install ok not-installed
Architecture: mips32el
Installed-Time: 1423323784
Auto-Installed: yes


As you can see, 0.3.6 is mentioned here as "not-installed", but opkg
keeps reporting about it. Removing the entry from the file works around
the problem, but I would have expected opkg to remove the entry after
upgrading it. Why didn't opkg remove the obsolete entry?



Hope this helps!


It helps to know that the message is harmless.






Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

--
___
Openembedde