Openembedded Core Discussions
 help / color / mirror / Atom feed
* Re: [Pull v2 3/4] connman: create xuser
From: Saul Wold @ 2011-11-02 23:23 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKo+BrVout44UaDOLfk5mEz+dFA4qGvx3L-B6ZP0Bjakbg@mail.gmail.com>

On 11/02/2011 11:54 AM, Otavio Salvador wrote:
> On Tue, Nov 1, 2011 at 19:44, Saul Wold<sgw@linux.intel.com>  wrote:
>> We create xuser here as a backup incase that xerver-nodm-init
>> is not on the system.
>
> This is wrong. If xserver-nodm-init (btw, there's a typo on the commit
> message) is not in the image user is suppose to know what he/she is
> doing so we shouldn't add users not required to make their life
> easier.
>

Otavio,

The situation is that when xserver-nodm-init is not installed or this is 
not a ROOTLESS_X, dbus still requires the xuser be available for 
connmand to run correctly.

Sau!




^ permalink raw reply

* Re: [Pull v2 3/4] connman: create xuser
From: Otavio Salvador @ 2011-11-03  0:45 UTC (permalink / raw)
  To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4EB1D0DA.10108@intel.com>

On Wed, Nov 2, 2011 at 21:23, Saul Wold <saul.wold@intel.com> wrote:
> On 11/02/2011 11:54 AM, Otavio Salvador wrote:
>>
>> On Tue, Nov 1, 2011 at 19:44, Saul Wold<sgw@linux.intel.com>  wrote:
>>>
>>> We create xuser here as a backup incase that xerver-nodm-init
>>> is not on the system.
>>
>> This is wrong. If xserver-nodm-init (btw, there's a typo on the commit
>> message) is not in the image user is suppose to know what he/she is
>> doing so we shouldn't add users not required to make their life
>> easier.
...
> The situation is that when xserver-nodm-init is not installed or this is not
> a ROOTLESS_X, dbus still requires the xuser be available for connmand to run
> correctly.

Something is wrong here; or it is being handled on the wrong package
or the design is wrong.

Shouldn't it be in base-passwd then?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



^ permalink raw reply

* Re: how to set time zone
From: Ni Qingliang @ 2011-11-03  0:47 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <4EB196D0.5010005@windriver.com>

maybe we can do the link in system booting, use the variable "TZ" to
create the symlink /etc/localtime, just like archlinux.
e.g. providing one script in /etc/rcS.d/ to create the symlink.

On Thu, 2011-11-03 at 03:15 +0800, Mark Hatle wrote:
> On 11/2/11 12:32 PM, Andrea Adami wrote:
> > On Mon, Oct 31, 2011 at 1:44 AM, Ni Qingliang <niqingliang@insigma.com.cn
> > <mailto:niqingliang@insigma.com.cn>> wrote:
> >
> >     I'd like the 'system level configuration' solution.
> >
> >     the /etc/localtime/ link can be done when packaging rootfs (using the
> >     system level configuration).
> >
> >     On Fri, 2011-10-28 at 22:43 +0800, Mark Hatle wrote:
> >     > Setting the default TZ for the image is something that should be done in a
> >     post
> >     > install script for the tzdata package or something similar.
> >     >
> >     > Since the /etc/localtime is usually a copy/hardlink or symlink to the timezone
> >     > data we don't want to package it up.  Instead we want to perform the actions
> >     > that a program running on the target system itself would use to change the
> >     timezone.
> >     >
> >     > So I think the easiest approach is to add a system level configuration
> >     variable
> >     > (set the default).
> >     >
> >     > Then use this variable to populate the configuration file that specifies the
> >     > system timezone... and then use the post install process to check the contents
> >     > of a text file.
> >     >
> >     > Alternatively do this via an initscript -- but for folks w/ read-only
> >     > filesystems I'm not sure that will work.
> >     >
> >     > --Mark
> >
> > <cut>
> >
> > Maybe I misunderstand "system level configuration" but in the meta-oe recipe we have
> >
> > DEFAULT_TIMEZONE ?= "Europe/London"
> >
> > Maybe UTC would be better?
> 
> To me no timezone (which is UTC) is preferable as the system designer can then
> set the timezone, externally to the package(s).
> 
> > Note how the variable is weak thus can be overridden in local.conf.
> >
> > Secondly, why do it as post-install or at image do_rootfs stage when we have set
> > the variable and are therefore able to provide sane defaults in do_install?
> 
> If it's done within a do_install, then the file (/etc/timezone) itself gets
> placed into the package.  If it's in the package, then if/when someone upgrades
> the package from a feed the timezone gets reset to the previous value.  That's a
> bug IMHO.
> 
> If it's done as a post-install script, then the timezone configuration can be
> evaluated and if one isn't set -- or there is no timezone file -- then we can
> set it to UTC or a similar default timezone.. (the value in the DEFAULT_TIMEZONE
> variable is reasonable in this approach.)
> 
> > Other points before starting to write a patch:
> > -why is the recipe in oe-core doing   chown -R root:root ${D}   ?
> 
> There was an issue with the way the timezone data was extracted/constructed that
> it was have all of the build system's uid/gid preserved in the copy to the final
> install directory -- so when packaging incorrect usernames and groups were fed
> into the process causing issues.
> 
> A simple chown -R root:root ${D} ensured that all of the timezone data was owned
> by the root user (on the target).
> 
> > -the logic around   # libc is removing zoneinfo files from package
> >   Is it only eglibc?
> 
> Timezone info is updated more often then the system libc.  So the zoneinfo files
> are handled externally of the libc.  This allows for easier updates over time..
> (This is my guess, as I'm not familiar with exactly what this comment refers to.)
> 
> > Regards
> >
> > Andrea
> >
> > |
> > |
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Yi Qingliang
niqingliang@insigma.com.cn
https://niqingliang2003.wordpress.com




^ permalink raw reply

* Re: how to set time zone
From: Otavio Salvador @ 2011-11-03  1:19 UTC (permalink / raw)
  To: niqingliang, Patches and discussions about the oe-core layer
In-Reply-To: <1320281261.1504.10.camel@localhost.localdomain>

On Wed, Nov 2, 2011 at 22:47, Ni Qingliang <niqingliang@insigma.com.cn> wrote:
> maybe we can do the link in system booting, use the variable "TZ" to
> create the symlink /etc/localtime, just like archlinux.
> e.g. providing one script in /etc/rcS.d/ to create the symlink.

This ought to be done by image IMO; so a kind of post rootfs
generation hook might be use allowing it to be set per-image.

I personally have this exactly use-case here at work.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



^ permalink raw reply

* Re: how to set time zone
From: Ni Qingliang @ 2011-11-03  1:35 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKooneOYO_b8Teg=VhukHQW27acQePiO5abKX_RV3TupEw@mail.gmail.com>

what is "IMO"?

On Thu, 2011-11-03 at 09:19 +0800, Otavio Salvador wrote:
> On Wed, Nov 2, 2011 at 22:47, Ni Qingliang <niqingliang@insigma.com.cn> wrote:
> > maybe we can do the link in system booting, use the variable "TZ" to
> > create the symlink /etc/localtime, just like archlinux.
> > e.g. providing one script in /etc/rcS.d/ to create the symlink.
> 
> This ought to be done by image IMO; so a kind of post rootfs
> generation hook might be use allowing it to be set per-image.
> 
> I personally have this exactly use-case here at work.
> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

-- 
Yi Qingliang
niqingliang@insigma.com.cn
https://niqingliang2003.wordpress.com




^ permalink raw reply

* Re: [PATCH 0/1] Uprev to pseudo 1.2
From: Mark Hatle @ 2011-11-03  1:52 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <20111102224704.GI9949@jama.jama.net>

On 11/2/11 5:47 PM, Martin Jansa wrote:
> On Wed, Nov 02, 2011 at 05:31:59PM -0500, Mark Hatle wrote:
>> On 11/2/11 5:11 PM, Martin Jansa wrote:
>>> On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote:
>>>> On 11/2/11 4:22 PM, Martin Jansa wrote:
>>>>> On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote:
>>>>>> Uprev to pseudo 1.2.
>>>>>>
>>>>>> This was heavily tested by building oe-core with numerous image 
>>>>>> configurations.  Each configuration generated the same image before and 
>>>>>> after the change from the current to new version of pseudo.
>>>>>>
>>>>>> The primary purpose of this change is to enable the PSEUDO_UNLOAD 
>>>>>> functionality that may be used for performance enhancements in future 
>>>>>> versions of oe-core.
>>>>>>
>>>>>> The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755:
>>>>>>
>>>>>>   meta: glib-2.0: don't apply qsort_r test removable patch for native version (2011-11-02 09:08:21 +0000)
>>>>>>
>>>>>> are available in the git repository at:
>>>>>>   git://git.pokylinux.org/poky-contrib mhatle/pseudo
>>>>>>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo
>>>>>
>>>>> Is there branch with pseudo-1.2 for oe-core?
>>>>
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>> git://git.pokylinux.org/poky-contrib mhatle/pseudo
>>>>
>>>> Grab that -- or simply grab the top commit and add it to your oe-core checkout.
>>>
>>> Yes, but git cherry-pick would be faster and adding poky-contrib as
>>> another git remote is not very efficient as it doesn't share any git
>>> objects with oe-core repo so it checkouts "whole poky" again :/.
>>>
>>> So I'll use 2nd easiest option "pw-am.sh 14227".
>>>
>>>>> I would like to try it because we have strange errors when libstc++
>>>>> isn't found when building with pseudo, but same binaries are working
>>>>> fine without pseudo (seems related to /etc/ld.so.cache being ignored
>>>>> sometimes from pseudo env).
>>>>>
>>>>> And while I was trying to debug it I've noticed that files.db and
>>>>> pseudo.log is quite big.
>>>>> -rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db
>>>>> -rw-r--r-- 1 bitbake bitbake  91K Aug 15 13:50 logs.db
>>>>> -rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log
>>>>
>>>> The files.db is based on the number of files accessed during the time pseudo is
>>>> running.
>>>
>>> Ah ok, this was in sysroot which was created "Aug  9" so it gets pretty
>>> big fast, lets hope that sqlite3 can handle it efficiently, or is there
>>> some way to "cleanup" stale entries in files table?
>>
>> When you clean the build it will restart the pseudo DB.
>>
>>> ie I'm using eglibc-2.14, but files table is full of eglibc-2.13 entries
>>> and _none_ from eglibc-2.14, is it supposed to be like this or is it
>>> sign of some pseudo problems?
>>>
>>> sqlite> select count(*) from files where path like '%eglibc-2.13%';
>>> 20221
>>> sqlite> select count(*) from files where path like '%eglibc-2.14%';
>>> 0
>>> sqlite> select count(*) from files;
>>> 1085380
>>
>> The pseudo DB is specific to the tmp work directory.  If the work directory
>> hasn't changed (i.e. you aren't updating versions and pr) then the pseudo DB
>> will continue to grow to accommodate the new files.
>>
>> There are flags within the DB if an erase operation occurs, but entries are only
>> tagged as erased -- but not removed.  This is due to speed issues.  pseudo is
>> significantly slower on remove and replace operations if the DB entries are removed.
>>
>>>> logs.db and pseudo.log are based on the debug settings of pseudo.  If you don't
>>>> have debugging enabled (you would have to do this manually) and the logs are
>>>> that big, something is going seriously wrong with the path/inode translation...
>>>>  It's fairly normal to have a set of logs that are in the 10-20k range for
>>>> complex packages.. (These are documenting cases where pseudo has to guess about
>>>> inode to path mapping..)
>>>
>>> This was generated without debug enabled.. but maybe because of rm_work,
>>> see below...
>>>
>>>>> with pseudo.log full of errors like this
>>>>> pseudo: path mismatch [12 links]: ino 39721500 db
>>>>> '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor'
>>>>> req
>>>>> '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'.
>>>>
>>>> Are you building on a NFS filesystem?  NFS (and a few other filesystems) have a
>>>> habit of remapping inodes out from under the filesystem.  pseudo uses the inodes
>>>> as a validation that the file hasn't changed.  If these inodes are changing,
>>>> pseudo will do it's best to keep things in sync, but there is a chance it won't
>>>> always succeed.
>>>
>>> No I'm building on local ext3 filesystem, but I'm also using rm_work, so 
>>> /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor
>>> is probably long gone and inode 39721500 wasn't marked as unused in
>>> pseudo world or do I read it wrong?
>>
>> If you use rm_work, then the pseudo DB located within the work directory will
>> also be removed.  So I'm not sure why you would be having such a large DB.
> 
> But I was talking about pseudo db here:
> tmp/sysroots/x86_64-linux/var/pseudo/

I just checked my system and the logs in the sysroot isn't very large.  I'm
curious as to why things are as big on your system.

> now with pseudo-1.2 I still have quite a few warnings about inodes in
> pseudo.log now in work directory, ie python build:
> OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.1 $ 
> -rw-r--r--  1 bitbake bitbake 5.2M Nov  2 23:44 files.db
> -rw-r--r--  1 bitbake bitbake 4.0K Nov  2 23:44 logs.db
> -rw-r--r--  1 bitbake bitbake  46K Nov  2 23:44 pseudo.log
> 
> pseudo: dir err : 1240102 ['/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.1/deploy-ipks/armv4t/IPKG_BUILD.25064'] (db 'no path') db mode 0100644, header mode 040755 (unlinking db)
> pseudo: creat for '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.1/deploy-ipks/armv4t/stvITxha' replaces existing 1240107 ['no path'].
> wxr-xr-x  1 bitbake bitbake    0 Nov  2 23:44 pseudo.socket
> pseudo: path mismatch [2 links]: ino 1240673 db '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.1/sstate-build-package/package/usr/bin/python2.7' req '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.1/sstate-build-package/package/usr/bin/python'.

None of the inode processing was changed in 1.2, only code that was specific to
pseudo preloading and the clone(2) function wrapper.

The 'no path' messages.. (see the first and second ones above) are the ones
where a file and/or directory was created outside of pseudo, and then referenced
by the inode directly.  Once referenced by name and not inode it was able to
correlate them.  This is somewhat expected and a model that will be looked at in
the near? future by the pseudo maintainer.. (he and I talked about it.. and the
fact we're getting so many of those messages is surprising.)

The later one indicates that the inode 1240673 was defined as belonging to one
item, but a second item showed up instead.  This usually means that something
was renamed outside of the control of pseudo.  This is more likely to be a
problem then the first two.

--Mark



^ permalink raw reply

* Re: how to set time zone
From: Philip Balister @ 2011-11-03  1:58 UTC (permalink / raw)
  To: niqingliang, Patches and discussions about the oe-core layer
In-Reply-To: <1320284129.1504.11.camel@localhost.localdomain>

On 11/02/2011 09:35 PM, Ni Qingliang wrote:
> what is "IMO"?

"In my opinion"

See http://www.internetslang.com/

I'm not suggesting reading the entire thing and using the slang in email
though :)

Philip


> 
> On Thu, 2011-11-03 at 09:19 +0800, Otavio Salvador wrote:
>> On Wed, Nov 2, 2011 at 22:47, Ni Qingliang <niqingliang@insigma.com.cn> wrote:
>>> maybe we can do the link in system booting, use the variable "TZ" to
>>> create the symlink /etc/localtime, just like archlinux.
>>> e.g. providing one script in /etc/rcS.d/ to create the symlink.
>>
>> This ought to be done by image IMO; so a kind of post rootfs
>> generation hook might be use allowing it to be set per-image.
>>
>> I personally have this exactly use-case here at work.
>>
>> --
>> Otavio Salvador                             O.S. Systems
>> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
>> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> 



^ permalink raw reply

* Re: how to set time zone
From: Ni Qingliang @ 2011-11-03  2:14 UTC (permalink / raw)
  To: Philip Balister; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4EB1F545.6080006@balister.org>

thanks! :)

On Thu, 2011-11-03 at 09:58 +0800, Philip Balister wrote:
> On 11/02/2011 09:35 PM, Ni Qingliang wrote:
> > what is "IMO"?
> 
> "In my opinion"
> 
> See http://www.internetslang.com/
> 
> I'm not suggesting reading the entire thing and using the slang in email
> though :)
> 
> Philip
> 
> 
> >
> > On Thu, 2011-11-03 at 09:19 +0800, Otavio Salvador wrote:
> >> On Wed, Nov 2, 2011 at 22:47, Ni Qingliang <niqingliang@insigma.com.cn> wrote:
> >>> maybe we can do the link in system booting, use the variable "TZ" to
> >>> create the symlink /etc/localtime, just like archlinux.
> >>> e.g. providing one script in /etc/rcS.d/ to create the symlink.
> >>
> >> This ought to be done by image IMO; so a kind of post rootfs
> >> generation hook might be use allowing it to be set per-image.
> >>
> >> I personally have this exactly use-case here at work.
> >>
> >> --
> >> Otavio Salvador                             O.S. Systems
> >> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> >> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> >

-- 
Yi Qingliang
niqingliang@insigma.com.cn
https://niqingliang2003.wordpress.com




^ permalink raw reply

* [PATCH] connman 0.75: bump PR for iptables library change
From: Koen Kooi @ 2011-11-03  9:05 UTC (permalink / raw)
  To: openembedded-core; +Cc: Koen Kooi

connmand[180]: /usr/sbin/connmand: error while loading shared libraries: libxtables.so.5: cannot open shared object file: No such file or directory

$ dpkg-deb -c ipk/armv7a/iptables_1.4.12.1-r0_armv7a.ipk  | grep libxtables
-rwxr-xr-x root/root     35252 2011-11-01 20:16 ./usr/lib/libxtables.so.7.0.0
lrwxrwxrwx root/root         0 2011-11-01 20:16 ./usr/lib/libxtables.so.7 -> libxtables.so.7.0.0

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 meta/recipes-connectivity/connman/connman_0.75.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman_0.75.bb b/meta/recipes-connectivity/connman/connman_0.75.bb
index 78f2199..c6e911b 100644
--- a/meta/recipes-connectivity/connman/connman_0.75.bb
+++ b/meta/recipes-connectivity/connman/connman_0.75.bb
@@ -1,5 +1,5 @@
 require connman.inc
-PR = "r3"
+PR = "r4"
 
 EXTRA_OECONF += "\
   ac_cv_path_WPASUPPLICANT=/usr/sbin/wpa_supplicant \
-- 
1.7.2.5




^ permalink raw reply related

* [PATCH] rt-tests: update to 0.83
From: Koen Kooi @ 2011-11-03  9:21 UTC (permalink / raw)
  To: openembedded-core; +Cc: Koen Kooi

Fetch from github, kernel.org uri is gone

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 .../{rt-tests_0.73.bb => rt-tests_0.83.bb}         |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)
 rename meta/recipes-rt/rt-tests/{rt-tests_0.73.bb => rt-tests_0.83.bb} (68%)

diff --git a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb b/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
similarity index 68%
rename from meta/recipes-rt/rt-tests/rt-tests_0.73.bb
rename to meta/recipes-rt/rt-tests/rt-tests_0.83.bb
index a2cf6be..78d51b3 100644
--- a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
+++ b/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
@@ -6,16 +6,20 @@ LICENSE = "GPLv2 & GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
                     file://src/cyclictest/cyclictest.c;beginline=7;endline=9;md5=ce162fe491d19d2ec67dff6dbc938d50 \
                     file://src/pi_tests/pi_stress.c;beginline=6;endline=19;md5=bd426a634a43ec612e9fbf125dfcc949"
-# Version v0.73
-SRCREV = "81da016fb0f6ab0511fbec81fc8ba1a50398a20d"
-PV = "git${SRCPV}"
-PR = "r0"
+# Version v0.83
+SRCREV = "5f1e84f8b015df3ff950056494134eca3f640d70"
 
-SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git;protocol=git"
+# git -> 0.83 needs a PE bump
+PE = "1"
+
+SRC_URI = "git://github.com/clrkwllms/rt-tests.git"
 
 S = "${WORKDIR}/git"
 
-CFLAGS += "-I${S}/src/include -D_GNU_SOURCE -Wall -Wno-nonnull"
+CFLAGS += "-I${S}/src/include -D_GNU_SOURCE -Wall -Wno-nonnulli ${LDFLAGS}"
+
+# calling 'uname -m' is broken on crossbuilds
+EXTRA_OEMAKE = "NUMA=0"
 
 do_install() {
         oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
-- 
1.7.2.5




^ permalink raw reply related

* [PATCH] iproute2: update to 3.0.0 to fix build with updated iptables
From: Koen Kooi @ 2011-11-03  9:52 UTC (permalink / raw)
  To: openembedded-core; +Cc: Koen Kooi

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 .../configure-cross.patch                          |   57 +++++++++++++-------
 meta/recipes-connectivity/iproute2/iproute2.inc    |    7 ++-
 .../iproute2/iproute2_2.6.38.bb                    |    9 ---
 .../iproute2/iproute2_3.0.0.bb                     |    8 +++
 4 files changed, 51 insertions(+), 30 deletions(-)
 rename meta/recipes-connectivity/iproute2/{iproute2-2.6.38 => iproute2-3.0.0}/configure-cross.patch (50%)
 delete mode 100644 meta/recipes-connectivity/iproute2/iproute2_2.6.38.bb
 create mode 100644 meta/recipes-connectivity/iproute2/iproute2_3.0.0.bb

diff --git a/meta/recipes-connectivity/iproute2/iproute2-2.6.38/configure-cross.patch b/meta/recipes-connectivity/iproute2/iproute2-3.0.0/configure-cross.patch
similarity index 50%
rename from meta/recipes-connectivity/iproute2/iproute2-2.6.38/configure-cross.patch
rename to meta/recipes-connectivity/iproute2/iproute2-3.0.0/configure-cross.patch
index e26e8ef..92c12be 100644
--- a/meta/recipes-connectivity/iproute2/iproute2-2.6.38/configure-cross.patch
+++ b/meta/recipes-connectivity/iproute2/iproute2-3.0.0/configure-cross.patch
@@ -1,31 +1,38 @@
+From 85b0589b4843c03e8e6fd9416d71ea449a73c5c0 Mon Sep 17 00:00:00 2001
+From: Koen Kooi <koen@dominion.thruhere.net>
+Date: Thu, 3 Nov 2011 10:46:16 +0100
+Subject: [PATCH] make configure cross compile safe
+
+According to Kevin Tian:
 Upstream-Status: Pending
 
-# borrow from OE, to handle cross compile mess
-#
-# ktian1, 06/28/2010 
-Index: iproute2-2.6.34/configure
-===================================================================
---- iproute2-2.6.34.orig/configure
-+++ iproute2-2.6.34/configure
-@@ -4,7 +4,7 @@
+Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
+---
+ configure |   13 +++++++------
+ 1 files changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/configure b/configure
+index f5c3d40..bcc1948 100755
+--- a/configure
++++ b/configure
+@@ -2,6 +2,7 @@
+ # This is not an autconf generated configure
+ #
  INCLUDE=${1:-"$PWD/include"}
- 
- TABLES=
--
 +SYSROOT=$1
+ 
  check_atm()
  {
- cat >/tmp/atmtest.c <<EOF
-@@ -15,7 +15,7 @@ int main(int argc, char **argv) {
+@@ -13,7 +14,7 @@ int main(int argc, char **argv) {
  	return 0;
  }
  EOF
 -gcc -I$INCLUDE -o /tmp/atmtest /tmp/atmtest.c -latm >/dev/null 2>&1 
-+$CC -I$INCLUDE -o /tmp/atmtest /tmp/atmtest.c -latm >/dev/null 2>&1
++$CC -I$INCLUDE -o /tmp/atmtest /tmp/atmtest.c -latm >/dev/null 2>&1 
  if [ $? -eq 0 ]
  then
      echo "TC_CONFIG_ATM:=y" >>Config
-@@ -49,7 +49,7 @@ int main(int argc, char **argv)
+@@ -47,7 +48,7 @@ int main(int argc, char **argv)
  
  EOF
  
@@ -34,7 +41,7 @@ Index: iproute2-2.6.34/configure
  then
  	echo "TC_CONFIG_XT:=y" >>Config
  	echo "using xtables"
-@@ -86,7 +86,7 @@ int main(int argc, char **argv) {
+@@ -84,7 +85,7 @@ int main(int argc, char **argv) {
  }
  
  EOF
@@ -43,7 +50,7 @@ Index: iproute2-2.6.34/configure
  
  if [ $? -eq 0 ]
  then
-@@ -126,7 +126,7 @@ int main(int argc, char **argv) {
+@@ -124,7 +125,7 @@ int main(int argc, char **argv) {
  }
  
  EOF
@@ -52,12 +59,24 @@ Index: iproute2-2.6.34/configure
  
  if [ $? -eq 0 ]
  then
-@@ -150,7 +150,7 @@ check_ipt()
+@@ -145,7 +146,7 @@ check_ipt()
  check_ipt_lib_dir()
  {
  	IPT_LIB_DIR=""
 -	for dir in /lib /usr/lib /usr/local/lib
 +	for dir in $SYSROOT/lib $SYSROOT/usr/lib $SYSROOT/usr/local/lib
  	do
- 		for file in $dir/$TABLES/lib*t_*so ; do
+ 		for file in $dir/{xtables,iptables}/lib*t_*so ; do
  			if [ -f $file ]; then
+@@ -168,7 +169,7 @@ int main(int argc, char **argv)
+ 	return 0;
+ }
+ EOF
+-gcc -I$INCLUDE -o /tmp/setnstest /tmp/setnstest.c >/dev/null 2>&1
++$CC -I$INCLUDE -o /tmp/setnstest /tmp/setnstest.c >/dev/null 2>&1
+ if [ $? -eq 0 ]
+ then
+ 	echo "IP_CONFIG_SETNS:=y" >>Config
+-- 
+1.7.2.5
+
diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc b/meta/recipes-connectivity/iproute2/iproute2.inc
index 0f27a01..6fc30a0 100644
--- a/meta/recipes-connectivity/iproute2/iproute2.inc
+++ b/meta/recipes-connectivity/iproute2/iproute2.inc
@@ -23,8 +23,11 @@ do_install () {
     rm ${D}/share -rf || true
 }
 
-FILES_${PN} += "/usr/lib/tc/*"
-FILES_${PN}-dbg += "/usr/lib/tc/.debug"
+# There are only .so files in iproute2
+INSANE_SKIP_${PN} = "dev-so"
+
+FILES_${PN} += "${base_libdir}/tc/*"
+FILES_${PN}-dbg += "${base_libdir}/tc/.debug"
 
 ALTERNATIVE_NAME = "ip"
 ALTERNATIVE_PATH = "${base_sbindir}/ip.iproute2"
diff --git a/meta/recipes-connectivity/iproute2/iproute2_2.6.38.bb b/meta/recipes-connectivity/iproute2/iproute2_2.6.38.bb
deleted file mode 100644
index 7abc41f..0000000
--- a/meta/recipes-connectivity/iproute2/iproute2_2.6.38.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-require iproute2.inc
-
-PR = "r0"
-
-SRC_URI = "http://developer.osdl.org/dev/iproute2/download/${BPN}-${PV}.tar.bz2 \
-	   file://configure-cross.patch"
-
-SRC_URI[md5sum] = "a243bfea837e71824b7ca26c3bb45fa8"
-SRC_URI[sha256sum] = "47629a4f547f21d94d8e823a87dd8e13042cadecefea2e2dc433e4134fa9aec4"
diff --git a/meta/recipes-connectivity/iproute2/iproute2_3.0.0.bb b/meta/recipes-connectivity/iproute2/iproute2_3.0.0.bb
new file mode 100644
index 0000000..8d1db85
--- /dev/null
+++ b/meta/recipes-connectivity/iproute2/iproute2_3.0.0.bb
@@ -0,0 +1,8 @@
+require iproute2.inc
+
+#v3.0.0 tag
+SRCREV = "ce691fb5ce78b2c75243c60a757a3990ae09681c"
+SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git \
+           file://configure-cross.patch"
+S = "${WORKDIR}/git"
+
-- 
1.7.2.5




^ permalink raw reply related

* Clean of qt4-embedded don't cleanup sysroot and deploy
From: Hauser, Wolfgang (external) @ 2011-11-03  9:55 UTC (permalink / raw)
  To: openembedded-devel, openembedded-core

It may be hidden by the huge work that is done by the community, so I
ask it again.

Hello,

if I do a bitbake -c clean for qt4-embedded or qt4-native all libraries
and binaries of QT are left in the sysroots and all created packages are
left in deploy. This is an result of splitting qt into several sub
packages and install them.

This behavior makes problems if I change the used QT Version of the
distro.
If qt recipe builds, it first searches for the libraries in sysroot
(standard library path of OE) and then it search in its working
directory. While the sysroots contain libraries of a different QT
version now, the build will fail. 

Is there a way to clean all sub packages of qt if I clean the
qt4-embedded or qt4-native package ?

An other solution may be to switch the order of the library paths in the
linker command (-L) to search libraries in the package working path
first. But how to do this in a proper way?

Regards
Wolfgang Hauser



^ permalink raw reply

* Re: [PATCH] rt-tests: update to 0.83
From: Jason Kridner @ 2011-11-03 12:22 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <1320312113-2492-1-git-send-email-koen@dominion.thruhere.net>

On Thu, Nov 3, 2011 at 5:21 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Fetch from github, kernel.org uri is gone
>
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Acked-by: Jason Kridner <jdk@ti.com>

> ---
>  .../{rt-tests_0.73.bb => rt-tests_0.83.bb}         |   16 ++++++++++------
>  1 files changed, 10 insertions(+), 6 deletions(-)
>  rename meta/recipes-rt/rt-tests/{rt-tests_0.73.bb => rt-tests_0.83.bb} (68%)
>
> diff --git a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb b/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
> similarity index 68%
> rename from meta/recipes-rt/rt-tests/rt-tests_0.73.bb
> rename to meta/recipes-rt/rt-tests/rt-tests_0.83.bb
> index a2cf6be..78d51b3 100644
> --- a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
> +++ b/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
> @@ -6,16 +6,20 @@ LICENSE = "GPLv2 & GPLv2+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
>                     file://src/cyclictest/cyclictest.c;beginline=7;endline=9;md5=ce162fe491d19d2ec67dff6dbc938d50 \
>                     file://src/pi_tests/pi_stress.c;beginline=6;endline=19;md5=bd426a634a43ec612e9fbf125dfcc949"
> -# Version v0.73
> -SRCREV = "81da016fb0f6ab0511fbec81fc8ba1a50398a20d"
> -PV = "git${SRCPV}"
> -PR = "r0"
> +# Version v0.83
> +SRCREV = "5f1e84f8b015df3ff950056494134eca3f640d70"
>
> -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git;protocol=git"
> +# git -> 0.83 needs a PE bump
> +PE = "1"
> +
> +SRC_URI = "git://github.com/clrkwllms/rt-tests.git"
>
>  S = "${WORKDIR}/git"
>
> -CFLAGS += "-I${S}/src/include -D_GNU_SOURCE -Wall -Wno-nonnull"
> +CFLAGS += "-I${S}/src/include -D_GNU_SOURCE -Wall -Wno-nonnulli ${LDFLAGS}"
> +
> +# calling 'uname -m' is broken on crossbuilds
> +EXTRA_OEMAKE = "NUMA=0"
>
>  do_install() {
>         oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



^ permalink raw reply

* Re: [Pull v3 1/4] avahi: use useradd to create avahi user for avahi-daemon
From: Koen Kooi @ 2011-11-03 12:23 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <9ef4f9a56a7d68c636768d2a1dbfeb9d6542b5f4.1320191934.git.sgw@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]


Op 2 nov. 2011, om 01:21 heeft Saul Wold het volgende geschreven:

> DBus was failing to start correct since the avahi user was
> not setup.
> 
> Keep the dbus reload since this could still be installed
> as a package an would require a dbus restart.

This doesn't seem to work for me, I keep getting "Unknown username 'avahi' in message bus configuration file"


> 
> Fixes: [YOCTO #1699]
> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
> meta/recipes-connectivity/avahi/avahi.inc |   16 +++++++++-------
> 1 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
> index 5ad9db0..79cfd73 100644
> --- a/meta/recipes-connectivity/avahi/avahi.inc
> +++ b/meta/recipes-connectivity/avahi/avahi.inc
> @@ -14,7 +14,7 @@ SECTION = "network"
> # python scripts are under GPLv2+
> LICENSE = "GPLv2+ & LGPLv2.1+"
> 
> -INC_PR = "r8"
> +INC_PR = "r9"
> 
> DEPENDS = "expat libcap libdaemon dbus glib-2.0"
> 
> @@ -23,7 +23,12 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
>           file://99avahi-autoipd \
>           file://initscript.patch"
> 
> -inherit autotools pkgconfig update-rc.d gettext
> +USERADD_PACKAGES = "${PN}-daemon"
> +USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
> +                              --no-create-home --shell /bin/false \
> +                              --user-group avahi"
> +
> +inherit autotools pkgconfig update-rc.d gettext useradd
> 
> EXTRA_OECONF = "--with-distro=debian \
>              --disable-introspection \
> @@ -116,15 +121,12 @@ do_install_avahi-autoipd() {
> 	install ${WORKDIR}/99avahi-autoipd ${D}${sysconfdir}/udhcpc.d
> }
> 
> -# At the time the postinst runs, dbus might not be setup so only restart if running
> +# At the time the postinst runs, dbus might not be setup so only restart if running 
> 
> pkg_postinst_avahi-daemon () {
> -	# can't do this offline
> 	if [ "x$D" != "x" ]; then
> -		exit 1
> +		exit 0
> 	fi

Removing that check completely would be a better idea :)

regards,

Koen

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply

* Re: [Pull v3 1/4] avahi: use useradd to create avahi user for avahi-daemon
From: Koen Kooi @ 2011-11-03 12:38 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <22CC451F-6D62-44A0-8984-489D40859F17@dominion.thruhere.net>

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]


Op 3 nov. 2011, om 13:23 heeft Koen Kooi het volgende geschreven:

> 
> Op 2 nov. 2011, om 01:21 heeft Saul Wold het volgende geschreven:
> 
>> DBus was failing to start correct since the avahi user was
>> not setup.
>> 
>> Keep the dbus reload since this could still be installed
>> as a package an would require a dbus restart.
> 
> This doesn't seem to work for me, I keep getting "Unknown username 'avahi' in message bus configuration file"

Manually running the preinst on the target *does* work, so something isn't right during do_rootfs.

regards,

Koen


> 
> 
>> 
>> Fixes: [YOCTO #1699]
>> 
>> Signed-off-by: Saul Wold <sgw@linux.intel.com>
>> ---
>> meta/recipes-connectivity/avahi/avahi.inc |   16 +++++++++-------
>> 1 files changed, 9 insertions(+), 7 deletions(-)
>> 
>> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
>> index 5ad9db0..79cfd73 100644
>> --- a/meta/recipes-connectivity/avahi/avahi.inc
>> +++ b/meta/recipes-connectivity/avahi/avahi.inc
>> @@ -14,7 +14,7 @@ SECTION = "network"
>> # python scripts are under GPLv2+
>> LICENSE = "GPLv2+ & LGPLv2.1+"
>> 
>> -INC_PR = "r8"
>> +INC_PR = "r9"
>> 
>> DEPENDS = "expat libcap libdaemon dbus glib-2.0"
>> 
>> @@ -23,7 +23,12 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
>>          file://99avahi-autoipd \
>>          file://initscript.patch"
>> 
>> -inherit autotools pkgconfig update-rc.d gettext
>> +USERADD_PACKAGES = "${PN}-daemon"
>> +USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
>> +                              --no-create-home --shell /bin/false \
>> +                              --user-group avahi"
>> +
>> +inherit autotools pkgconfig update-rc.d gettext useradd
>> 
>> EXTRA_OECONF = "--with-distro=debian \
>>             --disable-introspection \
>> @@ -116,15 +121,12 @@ do_install_avahi-autoipd() {
>> 	install ${WORKDIR}/99avahi-autoipd ${D}${sysconfdir}/udhcpc.d
>> }
>> 
>> -# At the time the postinst runs, dbus might not be setup so only restart if running
>> +# At the time the postinst runs, dbus might not be setup so only restart if running 
>> 
>> pkg_postinst_avahi-daemon () {
>> -	# can't do this offline
>> 	if [ "x$D" != "x" ]; then
>> -		exit 1
>> +		exit 0
>> 	fi
> 
> Removing that check completely would be a better idea :)
> 
> regards,
> 
> Koen


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply

* Re: [Pull v3 1/4] avahi: use useradd to create avahi user for avahi-daemon
From: Richard Purdie @ 2011-11-03 12:39 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <22CC451F-6D62-44A0-8984-489D40859F17@dominion.thruhere.net>

On Thu, 2011-11-03 at 13:23 +0100, Koen Kooi wrote:
> Op 2 nov. 2011, om 01:21 heeft Saul Wold het volgende geschreven:
> 
> > DBus was failing to start correct since the avahi user was
> > not setup.
> > 
> > Keep the dbus reload since this could still be installed
> > as a package an would require a dbus restart.
> 
> This doesn't seem to work for me, I keep getting "Unknown username
> 'avahi' in message bus configuration file"

From where? On target device upgrade? do_rootfs? populate_sysroot? More
info would be useful here.

> > Fixes: [YOCTO #1699]
> > 
> > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> > ---
> > meta/recipes-connectivity/avahi/avahi.inc |   16 +++++++++-------
> > 1 files changed, 9 insertions(+), 7 deletions(-)
> > 
> > diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
> > index 5ad9db0..79cfd73 100644
> > --- a/meta/recipes-connectivity/avahi/avahi.inc
> > +++ b/meta/recipes-connectivity/avahi/avahi.inc
> > @@ -14,7 +14,7 @@ SECTION = "network"
> > # python scripts are under GPLv2+
> > LICENSE = "GPLv2+ & LGPLv2.1+"
> > 
> > -INC_PR = "r8"
> > +INC_PR = "r9"
> > 
> > DEPENDS = "expat libcap libdaemon dbus glib-2.0"
> > 
> > @@ -23,7 +23,12 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
> >           file://99avahi-autoipd \
> >           file://initscript.patch"
> > 
> > -inherit autotools pkgconfig update-rc.d gettext
> > +USERADD_PACKAGES = "${PN}-daemon"
> > +USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
> > +                              --no-create-home --shell /bin/false \
> > +                              --user-group avahi"
> > +
> > +inherit autotools pkgconfig update-rc.d gettext useradd
> > 
> > EXTRA_OECONF = "--with-distro=debian \
> >              --disable-introspection \
> > @@ -116,15 +121,12 @@ do_install_avahi-autoipd() {
> > 	install ${WORKDIR}/99avahi-autoipd ${D}${sysconfdir}/udhcpc.d
> > }
> > 
> > -# At the time the postinst runs, dbus might not be setup so only restart if running
> > +# At the time the postinst runs, dbus might not be setup so only restart if running 
> > 
> > pkg_postinst_avahi-daemon () {
> > -	# can't do this offline
> > 	if [ "x$D" != "x" ]; then
> > -		exit 1
> > +		exit 0
> > 	fi
> 
> Removing that check completely would be a better idea :)

No it wouldn't, if we're installing this at do_rootfs time, we can just
mark the postinstall as done.

Cheers,

Richard




^ permalink raw reply

* Re: [Pull v3 1/4] avahi: use useradd to create avahi user for avahi-daemon
From: Koen Kooi @ 2011-11-03 12:40 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <9971B226-F171-4D8E-B751-B358923CD41A@dominion.thruhere.net>

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]


Op 3 nov. 2011, om 13:38 heeft Koen Kooi het volgende geschreven:

> 
> Op 3 nov. 2011, om 13:23 heeft Koen Kooi het volgende geschreven:
> 
>> 
>> Op 2 nov. 2011, om 01:21 heeft Saul Wold het volgende geschreven:
>> 
>>> DBus was failing to start correct since the avahi user was
>>> not setup.
>>> 
>>> Keep the dbus reload since this could still be installed
>>> as a package an would require a dbus restart.
>> 
>> This doesn't seem to work for me, I keep getting "Unknown username 'avahi' in message bus configuration file"
> 
> Manually running the preinst on the target *does* work, so something isn't right during do_rootfs.

+ sh /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beaglebone-angstrom-linux-gnueabi/systemd-image-1.0-r0/rootfs/var/lib/opkg/info/avahi-daemon.preinst
Running useradd commands...
grep: /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beaglebone-angstrom-linux-gnueabi/systemd-image-1.0-r0/rootfs/etc/passwd: No such file or directory
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
useradd: user 'avahi' already exists

I think I know what's going wrong, patch coming soon!



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply

* Re: [PATCH 0/1] Uprev to pseudo 1.2
From: Richard Purdie @ 2011-11-03 12:47 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <4EB1F3E9.8070103@windriver.com>

On Wed, 2011-11-02 at 20:52 -0500, Mark Hatle wrote:
> On 11/2/11 5:47 PM, Martin Jansa wrote:
> > On Wed, Nov 02, 2011 at 05:31:59PM -0500, Mark Hatle wrote:
> >> On 11/2/11 5:11 PM, Martin Jansa wrote:
> >>> On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote:
> >>>>> with pseudo.log full of errors like this
> >>>>> pseudo: path mismatch [12 links]: ino 39721500 db
> >>>>> '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor'
> >>>>> req
> >>>>> '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'.
> >>>>
> >>>> Are you building on a NFS filesystem?  NFS (and a few other filesystems) have a
> >>>> habit of remapping inodes out from under the filesystem.  pseudo uses the inodes
> >>>> as a validation that the file hasn't changed.  If these inodes are changing,
> >>>> pseudo will do it's best to keep things in sync, but there is a chance it won't
> >>>> always succeed.
> >>>
> >>> No I'm building on local ext3 filesystem, but I'm also using rm_work, so 
> >>> /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor
> >>> is probably long gone and inode 39721500 wasn't marked as unused in
> >>> pseudo world or do I read it wrong?
> >>
> >> If you use rm_work, then the pseudo DB located within the work directory will
> >> also be removed.  So I'm not sure why you would be having such a large DB.
> > 
> > But I was talking about pseudo db here:
> > tmp/sysroots/x86_64-linux/var/pseudo/
> 
> I just checked my system and the logs in the sysroot isn't very large.  I'm
> curious as to why things are as big on your system.

We did have a problem a while back where pseudo was active when it
shouldn't have been and I noticed huge db/logs on my system too. The
environment changes that were pushed shortly before 1.1 fixed that
problem as far as I know but if this is an old build directory, it could
have those left behind.

This actually accounted for the significant load time bitbake had on one
of my systems too - it was spending the time loading the pseudo db.

Cheers,

Richard




^ permalink raw reply

* Re: [Pull v3 1/4] avahi: use useradd to create avahi user for avahi-daemon
From: Koen Kooi @ 2011-11-03 12:49 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <1320323991.20107.49.camel@ted>

[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]


Op 3 nov. 2011, om 13:39 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-11-03 at 13:23 +0100, Koen Kooi wrote:
>> Op 2 nov. 2011, om 01:21 heeft Saul Wold het volgende geschreven:
>> 
>>> DBus was failing to start correct since the avahi user was
>>> not setup.
>>> 
>>> Keep the dbus reload since this could still be installed
>>> as a package an would require a dbus restart.
>> 
>> This doesn't seem to work for me, I keep getting "Unknown username
>> 'avahi' in message bus configuration file"
> 
> From where? On target device upgrade? do_rootfs? populate_sysroot? More
> info would be useful here.

On target device boot. I've narrowed it down to an RDEPENDS problem, I'm working out the correct cycle of _append and += now

The basic problem:

Package: avahi-daemon
Version: 0.6.30-r9.0
 [..]
Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), libexpat1 (>= 2.0.1)

No 'base-passwd' in there.

> 
>>> Fixes: [YOCTO #1699]
>>> 
>>> Signed-off-by: Saul Wold <sgw@linux.intel.com>
>>> ---
>>> meta/recipes-connectivity/avahi/avahi.inc |   16 +++++++++-------
>>> 1 files changed, 9 insertions(+), 7 deletions(-)
>>> 
>>> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
>>> index 5ad9db0..79cfd73 100644
>>> --- a/meta/recipes-connectivity/avahi/avahi.inc
>>> +++ b/meta/recipes-connectivity/avahi/avahi.inc
>>> @@ -14,7 +14,7 @@ SECTION = "network"
>>> # python scripts are under GPLv2+
>>> LICENSE = "GPLv2+ & LGPLv2.1+"
>>> 
>>> -INC_PR = "r8"
>>> +INC_PR = "r9"
>>> 
>>> DEPENDS = "expat libcap libdaemon dbus glib-2.0"
>>> 
>>> @@ -23,7 +23,12 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
>>>          file://99avahi-autoipd \
>>>          file://initscript.patch"
>>> 
>>> -inherit autotools pkgconfig update-rc.d gettext
>>> +USERADD_PACKAGES = "${PN}-daemon"
>>> +USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
>>> +                              --no-create-home --shell /bin/false \
>>> +                              --user-group avahi"
>>> +
>>> +inherit autotools pkgconfig update-rc.d gettext useradd
>>> 
>>> EXTRA_OECONF = "--with-distro=debian \
>>>             --disable-introspection \
>>> @@ -116,15 +121,12 @@ do_install_avahi-autoipd() {
>>> 	install ${WORKDIR}/99avahi-autoipd ${D}${sysconfdir}/udhcpc.d
>>> }
>>> 
>>> -# At the time the postinst runs, dbus might not be setup so only restart if running
>>> +# At the time the postinst runs, dbus might not be setup so only restart if running 
>>> 
>>> pkg_postinst_avahi-daemon () {
>>> -	# can't do this offline
>>> 	if [ "x$D" != "x" ]; then
>>> -		exit 1
>>> +		exit 0
>>> 	fi
>> 
>> Removing that check completely would be a better idea :)
> 
> No it wouldn't, if we're installing this at do_rootfs time, we can just
> mark the postinstall as done.
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply

* [oe] Planned outage to move servers into new rackspace.
From: Philip Balister @ 2011-11-03 12:52 UTC (permalink / raw)
  To: openembedded-core, Yocto Project

FYI

-------- Original Message --------
Subject: [oe] Planned outage to move servers into new rackspace.
Date: Thu, 3 Nov 2011 04:35:48 -0700
From: Tom King <ka6sox@gmail.com>
Reply-To: openembedded-devel@lists.openembedded.org
To: openembedded-devel@lists.openembedded.org

today, 3NOV2011, between 1000-1200PDT (1800-2000UTC) there will be a
short 15-30Minute outage for us to migrate our servers into the final
destination at the Colo.

This will affect all services including git, cgit, wiki, patches and bugs.

ka6sox
(for the OE Infra team)

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel




^ permalink raw reply

* [PATCH] avahi: fix useradd race condition
From: Koen Kooi @ 2011-11-03 12:57 UTC (permalink / raw)
  To: openembedded-core; +Cc: Koen Kooi

Avahi doesn't work at boot because of:

+ sh /OE/../rootfs/var/lib/opkg/info/avahi-daemon.preinst
Running useradd commands...
grep: /OE/../rootfs/etc/passwd: No such file or directory

That is due to:

Package: avahi-daemon
Version: 0.6.30-r9.0
 [..]
Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), libexpat1 (>= 2.0.1)

After this patch:

 Package: avahi-daemon
 Version: 0.6.30-r10.0
 [..]
 Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), shadow, libexpat1 (>= 2.0.1), base-passwd

This also changes ${PN}-daemon to avahi-daemon to be consistent with the PACKAGES/FILES lines below

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 meta/recipes-connectivity/avahi/avahi.inc |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
index 79cfd73..728c38f 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -14,7 +14,7 @@ SECTION = "network"
 # python scripts are under GPLv2+
 LICENSE = "GPLv2+ & LGPLv2.1+"
 
-INC_PR = "r9"
+INC_PR = "r10"
 
 DEPENDS = "expat libcap libdaemon dbus glib-2.0"
 
@@ -23,8 +23,9 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
           file://99avahi-autoipd \
           file://initscript.patch"
 
-USERADD_PACKAGES = "${PN}-daemon"
-USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
+USERADDPN = "avahi-daemon"
+USERADD_PACKAGES = "avahi-daemon"
+USERADD_PARAM_avahi-daemon = "--system --home /var/run/avahi-daemon \
                               --no-create-home --shell /bin/false \
                               --user-group avahi"
 
-- 
1.7.2.5




^ permalink raw reply related

* Re: [PATCH] avahi: fix useradd race condition
From: Koen Kooi @ 2011-11-03 13:04 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <1320325020-19012-1-git-send-email-koen@dominion.thruhere.net>

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]


Op 3 nov. 2011, om 13:57 heeft Koen Kooi het volgende geschreven:

> Avahi doesn't work at boot because of:
> 
> + sh /OE/../rootfs/var/lib/opkg/info/avahi-daemon.preinst
> Running useradd commands...
> grep: /OE/../rootfs/etc/passwd: No such file or directory
> 
> That is due to:
> 
> Package: avahi-daemon
> Version: 0.6.30-r9.0
> [..]
> Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), libexpat1 (>= 2.0.1)
> 
> After this patch:
> 
> Package: avahi-daemon
> Version: 0.6.30-r10.0
> [..]
> Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), shadow, libexpat1 (>= 2.0.1), base-passwd
> 
> This also changes ${PN}-daemon to avahi-daemon to be consistent with the PACKAGES/FILES lines below
> 
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
> meta/recipes-connectivity/avahi/avahi.inc |    7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
> index 79cfd73..728c38f 100644
> --- a/meta/recipes-connectivity/avahi/avahi.inc
> +++ b/meta/recipes-connectivity/avahi/avahi.inc
> @@ -14,7 +14,7 @@ SECTION = "network"
> # python scripts are under GPLv2+
> LICENSE = "GPLv2+ & LGPLv2.1+"
> 
> -INC_PR = "r9"
> +INC_PR = "r10"
> 
> DEPENDS = "expat libcap libdaemon dbus glib-2.0"
> 
> @@ -23,8 +23,9 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
>           file://99avahi-autoipd \
>           file://initscript.patch"
> 
> -USERADD_PACKAGES = "${PN}-daemon"
> -USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
> +USERADDPN = "avahi-daemon"

My gut feeling is that useradd.bbclass should add the RDEPENDS in its pythoncode instead of relying on people to set both USERADD_PACKAGES and USERADDPN to the same value.

regards,

Koen.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

^ permalink raw reply

* Re: [PATCH] avahi: fix useradd race condition
From: Richard Purdie @ 2011-11-03 14:39 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <86762F88-8EB9-47D0-B1F7-A867ADCCFB1C@dominion.thruhere.net>

On Thu, 2011-11-03 at 14:04 +0100, Koen Kooi wrote:
> Op 3 nov. 2011, om 13:57 heeft Koen Kooi het volgende geschreven:
> 
> > Avahi doesn't work at boot because of:
> > 
> > + sh /OE/../rootfs/var/lib/opkg/info/avahi-daemon.preinst
> > Running useradd commands...
> > grep: /OE/../rootfs/etc/passwd: No such file or directory
> > 
> > That is due to:
> > 
> > Package: avahi-daemon
> > Version: 0.6.30-r9.0
> > [..]
> > Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), libexpat1 (>= 2.0.1)
> > 
> > After this patch:
> > 
> > Package: avahi-daemon
> > Version: 0.6.30-r10.0
> > [..]
> > Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), shadow, libexpat1 (>= 2.0.1), base-passwd
> > 
> > This also changes ${PN}-daemon to avahi-daemon to be consistent with the PACKAGES/FILES lines below
> > 
> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> > ---
> > meta/recipes-connectivity/avahi/avahi.inc |    7 ++++---
> > 1 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
> > index 79cfd73..728c38f 100644
> > --- a/meta/recipes-connectivity/avahi/avahi.inc
> > +++ b/meta/recipes-connectivity/avahi/avahi.inc
> > @@ -14,7 +14,7 @@ SECTION = "network"
> > # python scripts are under GPLv2+
> > LICENSE = "GPLv2+ & LGPLv2.1+"
> > 
> > -INC_PR = "r9"
> > +INC_PR = "r10"
> > 
> > DEPENDS = "expat libcap libdaemon dbus glib-2.0"
> > 
> > @@ -23,8 +23,9 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
> >           file://99avahi-autoipd \
> >           file://initscript.patch"
> > 
> > -USERADD_PACKAGES = "${PN}-daemon"
> > -USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
> > +USERADDPN = "avahi-daemon"
> 
> My gut feeling is that useradd.bbclass should add the RDEPENDS in its
> pythoncode instead of relying on people to set both USERADD_PACKAGES
> and USERADDPN to the same value.

Agreed, looking at the code I think we can make this easier on the user.
I'll take the fix to solve the short term issues but we could do with
improving this.

Cheers,

Richard




^ permalink raw reply

* Re: [PATCH 0/1] distro_tracking_fields: Update the Month to 'MMM'
From: Saul Wold @ 2011-11-03 15:44 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1320212931.git.wenzong.fan@windriver.com>

On 11/01/2011 10:52 PM, wenzong.fan@windriver.com wrote:
> From: Wenzong Fan<wenzong.fan@windriver.com>
>
> Update the format of Month to 'MMM' instead of spell it out.
>
> The following changes since commit 4a951e0433a99cd985515843f0a48fadc7050aca:
>    Robert P. J. Day (1):
>          Fix HOMEPAGE values in libzypp and sat-solver .bb files
>
> are available in the git repository at:
>
>    git://git.pokylinux.org/poky-contrib wenzong/distro_tracking_fields_update
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/distro_tracking_fields_update
>
> Wenzong Fan (1):
>    distro_tracking_fields: Update the Month to 'MMM'
>
>   .../conf/distro/include/distro_tracking_fields.inc |    8 ++++----
>   1 files changed, 4 insertions(+), 4 deletions(-)
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Merged into OE-Core

Thanks
	Sau!



^ permalink raw reply

* Re: [CONSOLIDATED PULL 12/28] libnl2: Fix a race on route/pktloc_syntax.h
From: Martin Jansa @ 2011-11-03 15:55 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer
In-Reply-To: <e4dbd916c029abca10e538f70fb06380c21bdd83.1318570250.git.sgw@linux.intel.com>

On Fri, Oct 14, 2011 at 7:33 AM, Saul Wold <sgw@linux.intel.com> wrote:
> From: Tom Rini <tom_rini@mentor.com>
>
> At issue is that route/pktloc.c (not generated) depends on
> route/pktloc_syntax.h (generated).
>
> Signed-off-by: Tom Rini <tom_rini@mentor.com>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
>  .../libnl/fix-pktloc_syntax_h-race.patch           |   26 ++++++++++++++++++++
>  meta/recipes-support/libnl/libnl_2.0.bb            |    3 +-
>  2 files changed, 28 insertions(+), 1 deletions(-)
>  create mode 100644 meta/recipes-support/libnl/fix-pktloc_syntax_h-race.patch
>
> diff --git a/meta/recipes-support/libnl/fix-pktloc_syntax_h-race.patch b/meta/recipes-support/libnl/fix-pktloc_syntax_h-race.patch
> new file mode 100644
> index 0000000..05d75db
> --- /dev/null
> +++ b/meta/recipes-support/libnl/fix-pktloc_syntax_h-race.patch
> @@ -0,0 +1,26 @@
> +Upstream-Status: Inappropriate [configuration]
> +
> +libnl has progressed to 0.3.2 and there does not appear to be any
> +"make -j" issues with this build after my limited testing on that
> +newer version so we can assume this issue is fixed upstream
> +
> +Index: libnl-2.0/lib/Makefile.am
> +===================================================================
> +--- libnl-2.0.orig/lib/Makefile.am
> ++++ libnl-2.0/lib/Makefile.am
> +@@ -27,11 +27,15 @@ CLEANFILES = \
> +       route/pktloc_grammar.c route/pktloc_grammar.h \
> +       route/pktloc_syntax.c route/pktloc_syntax.h
> +
> ++BUILT_SOURCES = route/pktloc_syntax.h route/pktloc_grammar.h
> ++
> + # Hack to avoid using ylwrap. It does not function correctly in combination
> + # with --header-file=
> ++route/pktloc_grammar.h: route/pktloc_grammar.c
> + route/pktloc_grammar.c: route/pktloc_grammar.l
> +       $(LEX) --header-file=route/pktloc_grammar.h $(LFLAGS) -o $@ $^
> +
> ++route/pktloc_syntax.h: route/pktloc_syntax.c
> + route/pktloc_syntax.c: route/pktloc_syntax.y
> +       $(YACC) -d $(YFLAGS) -o $@ $^
> +
> diff --git a/meta/recipes-support/libnl/libnl_2.0.bb b/meta/recipes-support/libnl/libnl_2.0.bb
> index 0dfcaf6..5339846 100644
> --- a/meta/recipes-support/libnl/libnl_2.0.bb
> +++ b/meta/recipes-support/libnl/libnl_2.0.bb
> @@ -6,10 +6,11 @@ LICENSE = "LGPLv2.1"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2b41e13261a330ee784153ecbb6a82bc"
>
>  DEPENDS = "flex-native bison-native"
> -PR = "r2"
> +PR = "r3"
>
>  SRC_URI= "http://www.infradead.org/~tgr/libnl/files/${BPN}-${PV}.tar.gz \
>           file://fix-makefile.patch \
> +         file://fix-pktloc_syntax_h-race.patch \
>          "
>
>  SRC_URI[md5sum] = "6aaf1e9802a17a7d702bb0638044ffa7"
> --
> 1.7.6.2

Why is this fix-pktloc_syntax_h-race.patch in
meta/recipes-support/libnl/fix-pktloc_syntax_h-race.patch
instead of more common location
meta/recipes-support/libnl/libnl-2.0/fix-pktloc_syntax_h-race.patch

and why is this separate from fix-makefile.patch when they both are
trying to fix same issue?

I'll send patch for this..



^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox