* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Martin Jansa @ 2011-10-23 6:28 UTC (permalink / raw)
To: Kamble, Nitin A; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <9DA5872FEF993D41B7173F58FCF6BE94E33A6D8D@orsmsx504.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3746 bytes --]
On Sat, Oct 22, 2011 at 04:54:00PM -0700, Kamble, Nitin A wrote:
> Hi Martin,
> I have kept my python work at nitin/python branch on poky contrib. the 2.7.2 python is working for all arches except arm. And I am going on vacation for few days, and I could not finish the python arm issue arm, so if you get a chance you can look into the arm issue, if you have not resolved it already then I will look into it again once I am back from my vacation on 13th Nov.
Hi Nitin,
I've tried already and failed, but I'll try again and I guess qemux86-64
(linking to host libc and failing if it's not same version as the one in
sysroot) is also still broken and should be taken care of too, right?
Regards,
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Martin Jansa
> > Sent: Friday, October 14, 2011 2:12 AM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> > from 2.6.6 to 2.7.2
> >
> > On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > > On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kamble@intel.com
> > wrote:
> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > >
> > >
> > > This patch does not apply after
> > > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> > >
> > > can you rebase on top of oe-core?
> > >
> > > Also please drop
> > > DEFAULT_PREFERENCE = "-27"
> > >
> > > we have only one python version so I guess it's not usefull at all
> > > anymore
> > >
> > > I'll apply it manually, test it here.. and report if those modules
> > are
> > > build later..
> >
> > seems the same as with previous version..
> >
> > log.do_compile full of
> > /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> > not recognized: File format not recognized
> > collect2: ld returned 1 exit status
> >
> > and only built module is sqlite
> > OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> > Python-2.7.2/build/lib.linux-x86_64-2.7/
> > _sqlite3.so
> >
> > while with 2.6 we had a lot of modules
> > $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> > _bisect.so _codecs_jp.so _ctypes.so _fileio.so
> > _json.so _random.so _testcapi.so bz2.so
> > datetime.so itertools.so parser.so spwd.so
> > unicodedata.so
> > _bytesio.so _codecs_kr.so _ctypes_test.so _functools.so
> > _locale.so _socket.so _weakref.so cPickle.so fcntl.so
> > math.so pyexpat.so strop.so zlib.so
> > _codecs_cn.so _codecs_tw.so _curses.so _hashlib.so
> > _lsprof.so _sqlite3.so array.so cStringIO.so
> > future_builtins.so mmap.so readline.so syslog.so
> > _codecs_hk.so _collections.so _curses_panel.so _heapq.so
> > _multibytecodec.so _ssl.so audioop.so cmath.so gdbm.so
> > nis.so resource.so termios.so
> > _codecs_iso2022.so _csv.so _elementtree.so _hotshot.so
> > _multiprocessing.so _struct.so binascii.so crypt.so grp.so
> > operator.so select.so time.so
> >
> > Can you please test that you have non-empty python-syslog python-
> > resource python-elementtree python-fcntl python-zlib?
> > And test build for qemuarm, because I guess that it links to -native
> > libpython2.7 when you're building qemux86 on x86 host.
> >
> > But it seems that python runtime works now, thanks!
> >
> > Regards,
> > --
> > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Kamble, Nitin A @ 2011-10-22 23:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014091136.GE3542@jama.jama.net>
Hi Martin,
I have kept my python work at nitin/python branch on poky contrib. the 2.7.2 python is working for all arches except arm. And I am going on vacation for few days, and I could not finish the python arm issue arm, so if you get a chance you can look into the arm issue, if you have not resolved it already then I will look into it again once I am back from my vacation on 13th Nov.
Thanks & Regards,
Nitin
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Friday, October 14, 2011 2:12 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
>
> On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kamble@intel.com
> wrote:
> > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > >
> >
> > This patch does not apply after
> > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> >
> > can you rebase on top of oe-core?
> >
> > Also please drop
> > DEFAULT_PREFERENCE = "-27"
> >
> > we have only one python version so I guess it's not usefull at all
> > anymore
> >
> > I'll apply it manually, test it here.. and report if those modules
> are
> > build later..
>
> seems the same as with previous version..
>
> log.do_compile full of
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> not recognized: File format not recognized
> collect2: ld returned 1 exit status
>
> and only built module is sqlite
> OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> Python-2.7.2/build/lib.linux-x86_64-2.7/
> _sqlite3.so
>
> while with 2.6 we had a lot of modules
> $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> _bisect.so _codecs_jp.so _ctypes.so _fileio.so
> _json.so _random.so _testcapi.so bz2.so
> datetime.so itertools.so parser.so spwd.so
> unicodedata.so
> _bytesio.so _codecs_kr.so _ctypes_test.so _functools.so
> _locale.so _socket.so _weakref.so cPickle.so fcntl.so
> math.so pyexpat.so strop.so zlib.so
> _codecs_cn.so _codecs_tw.so _curses.so _hashlib.so
> _lsprof.so _sqlite3.so array.so cStringIO.so
> future_builtins.so mmap.so readline.so syslog.so
> _codecs_hk.so _collections.so _curses_panel.so _heapq.so
> _multibytecodec.so _ssl.so audioop.so cmath.so gdbm.so
> nis.so resource.so termios.so
> _codecs_iso2022.so _csv.so _elementtree.so _hotshot.so
> _multiprocessing.so _struct.so binascii.so crypt.so grp.so
> operator.so select.so time.so
>
> Can you please test that you have non-empty python-syslog python-
> resource python-elementtree python-fcntl python-zlib?
> And test build for qemuarm, because I guess that it links to -native
> libpython2.7 when you're building qemux86 on x86 host.
>
> But it seems that python runtime works now, thanks!
>
> Regards,
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
^ permalink raw reply
* Re: [PATCH] squashfs-tools: add recipe (2nd try)
From: Cliff Brake @ 2011-10-22 17:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA19B3E.2020302@intel.com>
On Fri, Oct 21, 2011 at 12:18 PM, Saul Wold <saul.wold@intel.com> wrote:
> This one is on hold pending an update from Cliff based on Khem's comments.
v3 posted. Thanks for all the feedback.
Cliff
^ permalink raw reply
* Re: [PATCH] base.bbclass: add subversion-native to DEPENDS if there is svn:// in SRC_URI
From: Saul Wold @ 2011-10-22 17:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <1319190483-5637-1-git-send-email-Martin.Jansa@gmail.com>
On 10/21/2011 02:48 AM, Martin Jansa wrote:
> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> ---
> meta/classes/base.bbclass | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index f539744..bced226 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -401,6 +401,13 @@ python () {
> bb.note("SKIPPING %s because it's %s" % (pn, this_license))
> raise bb.parse.SkipPackage("incompatible with license %s" % this_license)
>
> + # Svn packages should DEPEND on subversion-native
> + srcuri = bb.data.getVar('SRC_URI', d, 1)
> + if "svn://" in srcuri:
> + depends = bb.data.getVarFlag('do_fetch', 'depends', d) or ""
> + depends = depends + " subversion-native:do_populate_sysroot"
> + bb.data.setVarFlag('do_fetch', 'depends', depends, d)
> +
> # Git packages should DEPEND on git-native
> srcuri = bb.data.getVar('SRC_URI', d, 1)
> if "git://" in srcuri:
This change introduces a circular dependency when I tried to build.
Sau!
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Phil Blundell @ 2011-10-22 12:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111021161620.GS3522@jama.jama.net>
On Fri, 2011-10-21 at 18:16 +0200, Martin Jansa wrote:
> On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
> > On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > > .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > index 4ac2418..2f872b8 100644
> > > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > @@ -23,3 +23,4 @@ do_compile_prepend() {
> > > cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
> > > }
> > >
> > > +ARM_INSTRUCTION_SET = "arm"
> >
> > not averse to patch but it would be nice to know what fails in thumb mode.
>
> selected processor does not support Thumb mode `swp r1,r2,[r3]'
If it's only that one error (presumably some kind of home-grown atomic
operation) then let's just fix the code in question rather than forcing
the whole thing to build in ARM-state. Or if the code is hard to fix,
patch the makefile so that only the particular source files with the
assembly in are built for ARM and let the rest stay as Thumb. Making
the whole package be ARM is a bit of a heavyweight fix for that issue.
p.
^ permalink raw reply
* Keeping patch status uptodate in patchwork
From: Khem Raj @ 2011-10-21 17:20 UTC (permalink / raw)
To: openembeded-devel,
Patches and discussions about the oe-core layer
Hi
I would like to request the patch submitter to change the status of
patches appropriately particularly case where manual intervention will
be needed
1. When you send pull request the cover letter is not marked accepted
automatically so when pull request is merged please mark it so.
2. When multiple versions of patches V1, V2, V3 are sent then the
versions that don't get applied should be marked as superseded.
It will greatly help in keeping the patchwork clean and layer
maintainers and the data it represents will be lot more relevant.
Thanks for you help
-Khem
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Saul Wold @ 2011-10-21 17:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <20111021161620.GS3522@jama.jama.net>
On 10/21/2011 09:16 AM, Martin Jansa wrote:
> On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
>> On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa<martin.jansa@gmail.com> wrote:
>>> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
>>> ---
>>> .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>>> index 4ac2418..2f872b8 100644
>>> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>>> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>>> @@ -23,3 +23,4 @@ do_compile_prepend() {
>>> cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
>>> }
>>>
>>> +ARM_INSTRUCTION_SET = "arm"
>>
>> not averse to patch but it would be nice to know what fails in thumb mode.
>
> selected processor does not support Thumb mode `swp r1,r2,[r3]'
>
As already asked, can you upgrade to 1.1 and verify if this problem
still exists. Also if it does, it would be good to have this info in
the commit message.
Thanks
Sau!
> Regards,
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH 4/4] dbus: use useradd class to allow use in read-only filesystems
From: Koen Kooi @ 2011-10-21 17:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA1A5E1.8080508@intel.com>
Op 21 okt. 2011, om 19:03 heeft Saul Wold het volgende geschreven:
> On 10/21/2011 07:10 AM, Otavio Salvador wrote:
>> Move creation of required user/groups to useradd class thus allowing
>> use with read-only filesystems and booting the initial boot.
>>
>> Signed-off-by: Otavio Salvador<otavio@ossystems.com.br>
>> ---
>> meta/recipes-core/dbus/dbus.inc | 48 +++++++++++++++++----------------------
>> 1 files changed, 21 insertions(+), 27 deletions(-)
>>
>> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
>> index a8ecda8..2a97c02 100644
>> --- a/meta/recipes-core/dbus/dbus.inc
>> +++ b/meta/recipes-core/dbus/dbus.inc
>> @@ -10,15 +10,22 @@ DEPENDS = "expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', '${X
>> DEPENDS_virtclass-native = "expat-native virtual/libintl-native"
>> DEPENDS_virtclass-nativesdk = "expat-nativesdk virtual/libintl-nativesdk virtual/libx11"
>>
>> +PR = "r1"
>> +
>> SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
>> file://tmpdir.patch; \
>> file://dbus-1.init"
>>
>> -inherit autotools pkgconfig gettext update-rc.d
>> +inherit useradd autotools pkgconfig gettext update-rc.d
>>
>> INITSCRIPT_NAME = "dbus-1"
>> INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
>>
>> +USERADD_PACKAGES = "${PN}"
>> +GROUPADD_PARAM_${PN} = "-r netdev"
>
> I thought netdev was going to be removed from this recipe?
let's do that as follow up so it bisects cleanly. Changing 2 things at once never works for me :)
regards,
Koen
^ permalink raw reply
* Re: [PATCH 4/4] dbus: use useradd class to allow use in read-only filesystems
From: Saul Wold @ 2011-10-21 17:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <889826463264f3a2aeb5062afb5b2f24b5dc75a0.1319206126.git.otavio@ossystems.com.br>
On 10/21/2011 07:10 AM, Otavio Salvador wrote:
> Move creation of required user/groups to useradd class thus allowing
> use with read-only filesystems and booting the initial boot.
>
> Signed-off-by: Otavio Salvador<otavio@ossystems.com.br>
> ---
> meta/recipes-core/dbus/dbus.inc | 48 +++++++++++++++++----------------------
> 1 files changed, 21 insertions(+), 27 deletions(-)
>
> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
> index a8ecda8..2a97c02 100644
> --- a/meta/recipes-core/dbus/dbus.inc
> +++ b/meta/recipes-core/dbus/dbus.inc
> @@ -10,15 +10,22 @@ DEPENDS = "expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', '${X
> DEPENDS_virtclass-native = "expat-native virtual/libintl-native"
> DEPENDS_virtclass-nativesdk = "expat-nativesdk virtual/libintl-nativesdk virtual/libx11"
>
> +PR = "r1"
> +
> SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
> file://tmpdir.patch; \
> file://dbus-1.init"
>
> -inherit autotools pkgconfig gettext update-rc.d
> +inherit useradd autotools pkgconfig gettext update-rc.d
>
> INITSCRIPT_NAME = "dbus-1"
> INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
>
> +USERADD_PACKAGES = "${PN}"
> +GROUPADD_PARAM_${PN} = "-r netdev"
I thought netdev was going to be removed from this recipe?
Sau!
> +USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
> + --no-create-home --user-group messagebus"
> +
> CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session.conf"
>
> DEBIANNAME_${PN} = "dbus-1"
> @@ -44,32 +51,7 @@ RRECOMMENDS_${PN}-lib = "${PN}"
> FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool"
>
> pkg_postinst_dbus() {
> - # can't do adduser stuff offline
> - if [ "x$D" != "x" ]; then
> - exit 1
> - fi
> -
> - MESSAGEUSER=messagebus
> - MESSAGEHOME=/var/run/dbus
> - UUIDDIR=/var/lib/dbus
> -
> - mkdir -p $MESSAGEHOME
> - mkdir -p $UUIDDIR
> - chgrp "$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || addgroup "$MESSAGEUSER"
> - chown "$MESSAGEUSER":"$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || \
> - adduser --system --home "$MESSAGEHOME" --no-create-home --disabled-password \
> - --ingroup "$MESSAGEUSER" "$MESSAGEUSER"
> -
> - chown "$MESSAGEUSER":"$MESSAGEUSER" "$UUIDDIR"
> -
> - grep -q netdev: /etc/group || addgroup netdev
> -
> - chown root:"$MESSAGEUSER" /usr/libexec/dbus-daemon-launch-helper
> - chmod 4754 /usr/libexec/dbus-daemon-launch-helper
> -
> - # add volatile after new user/grp are created
> - echo "d messagebus messagebus 0755 /var/run/dbus none"> /etc/default/volatiles/99_dbus
> - if [ -e /etc/init.d/populate-volatile.sh ] ; then
> + if [ -z "${D}" ]&& [ -e /etc/init.d/populate-volatile.sh ] ; then
> /etc/init.d/populate-volatile.sh update
> fi
> }
> @@ -92,6 +74,18 @@ do_install() {
> install -d ${D}${sysconfdir}/init.d
> install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1
>
> + install -d ${D}${sysconfdir}/default/volatiles
> + echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none" \
> + > ${D}${sysconfdir}/default/volatiles/99_dbus
> +
> +
> + mkdir -p ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus
> +
> + chown messagebus:messagebus ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus
> +
> + chown root:messagebus ${D}${libexecdir}/dbus-daemon-launch-helper
> + chmod 4754 ${D}${libexecdir}/dbus-daemon-launch-helper
> +
> # disable dbus-1 sysv script on systemd installs
> # nearly all distros call the initscript plain 'dbus', but OE-core is different
> ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
^ permalink raw reply
* Re: [PATCH 2/6] gmp: also generate the libgmpcxx library
From: Kamble, Nitin A @ 2011-10-21 16:54 UTC (permalink / raw)
To: Wold, Saul; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4EA12540.9020002@intel.com>
> -----Original Message-----
> From: Saul Wold [mailto:saul.wold@intel.com]
> Sent: Friday, October 21, 2011 12:55 AM
> To: Kamble, Nitin A
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> library
>
> On 10/20/2011 11:04 PM, Kamble, Nitin A wrote:
> >
> >
> >> -----Original Message-----
> >> From: Saul Wold [mailto:saul.wold@intel.com]
> >> Sent: Thursday, October 20, 2011 12:50 AM
> >> To: Patches and discussions about the oe-core layer
> >> Cc: Kamble, Nitin A
> >> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> >> library
> >>
> >> On 10/18/2011 05:30 PM, nitin.a.kamble@intel.com wrote:
> >>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>>
> >>> configure runs few checks to make sure c++ compiler and runtime are
> >> working as expected
> >>> with the --enable-cxx=detect option.
> >>>
> >> Somehow this change has also changed what the gmp package provides,
> >> before this change the package provided libgmp10 via PKG_gmp:
> libgmp10,
> >> after this change, the libgmp10 is no longer provided and causes
> other
> >> breakage.
> >>
> >> The example case I found was a coreutils package that was built
> prior
> >> to
> >> this change failed to fulfill it's dependencies after this change
> when
> >> creating an image. If I rebuild coreutils with the newer gmp build,
> >> then all is well, I think we need to understand this better before
> >> making this change.
> >>
> >> Did something else change in the packaging that would cause use to
> look
> >> the mapping above?
> >>
> > Saul,
> > In my testing I did not get any of these issues you mentioned
> above.
> >
> > Also I tried to reproduce the issue with coreutils as mentioned
> above, and I can not reproduce the issue for creations of an image. Can
> you verify the issue one more time?
> >
> Just to confirm, did you have a build of coreutils prior to your gmp
> changes? Which image did you build? Be sure you build an image that
> includes coreutils, such at an -sdk image.
>
> I can easily reproduce this issue.
>
> Sau!
>
I am able to reproduce the issue with sdk image, The packages(rpms) generated are different in r0 vs r1 version of gmp. Hence you are seeing that issue. Earlier libgmp.so.10 was the only library need packaging, so I guest package name was chosen aslibgmp10. now libgmpxx.so is also part of the package, hence recipe name which is gmp is chosen as the package name.
$ ls gmp-5.0.2-r0/deploy-rpms/i586/
libgmp10-5.0.2-r0.i586.rpm libgmp-dev-5.0.2-r0.i586.rpm libgmp-staticdev-5.0.2-r0.i586.rpm
libgmp-dbg-5.0.2-r0.i586.rpm libgmp-doc-5.0.2-r0.i586.rpm
$ ls gmp-5.0.2-r1/deploy-rpms/i586/
gmp-5.0.2-r1.i586.rpm gmp-dev-5.0.2-r1.i586.rpm gmp-staticdev-5.0.2-r1.i586.rpm
gmp-dbg-5.0.2-r1.i586.rpm gmp-doc-5.0.2-r1.i586.rpm
Thanks,
Nitin
> > Thanks,
> > Nitin
> >
> >>
> >> Sau!
> >>
> >>
> >>> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>> ---
> >>> meta/recipes-support/gmp/gmp.inc | 2 ++
> >>> meta/recipes-support/gmp/gmp_4.2.1.bb | 2 +-
> >>> meta/recipes-support/gmp/gmp_5.0.2.bb | 2 +-
> >>> 3 files changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
> >> support/gmp/gmp.inc
> >>> index 66349e6..3c662a0 100644
> >>> --- a/meta/recipes-support/gmp/gmp.inc
> >>> +++ b/meta/recipes-support/gmp/gmp.inc
> >>> @@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
> >>> acpaths = ""
> >>>
> >>> BBCLASSEXTEND = "native nativesdk"
> >>> +
> >>> +EXTRA_OECONF += " --enable-cxx=detect"
> >>> diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb b/meta/recipes-
> >> support/gmp/gmp_4.2.1.bb
> >>> index 74da6b8..97ac4b2 100644
> >>> --- a/meta/recipes-support/gmp/gmp_4.2.1.bb
> >>> +++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
> >>> @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
> >>> LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
> >>>
> >> file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
> >>> file://gmp-
> >> h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"
> >>> -PR = "r0"
> >>> +PR = "r1"
> >>>
> >>> SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
> >>> file://disable-stdc.patch"
> >>> diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb b/meta/recipes-
> >> support/gmp/gmp_5.0.2.bb
> >>> index 03fef45..f80971e 100644
> >>> --- a/meta/recipes-support/gmp/gmp_5.0.2.bb
> >>> +++ b/meta/recipes-support/gmp/gmp_5.0.2.bb
> >>> @@ -2,7 +2,7 @@ require gmp.inc
> >>> LICENSE="LGPLv3&GPLv3"
> >>> LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> >>>
> >> file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"
> >>> -PR = "r0"
> >>> +PR = "r1"
> >>>
> >>> SRC_URI_append += "file://sh4-asmfix.patch \
> >>> file://use-includedir.patch "
> >
^ permalink raw reply
* [PATCHv3] squashfs-tools: add recipe
From: Cliff Brake @ 2011-10-21 16:39 UTC (permalink / raw)
To: openembedded-core; +Cc: Cliff Brake
In-Reply-To: <20111019212659.GA30050@sakrah.homelinux.org>
From: Cliff Brake <cbrake@bec-systems.com>
added xz compression option, general cleanup
---
.../squashfs-tools/squashfs-tools_4.2.bb | 40 ++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
new file mode 100644
index 0000000..6691797
--- /dev/null
+++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
@@ -0,0 +1,40 @@
+# Note, we can probably remove the lzma option as it has be replaced with xz,
+# and I don't think the kernel supports it any more.
+DESCRIPTION = "Tools to manipulate Squashfs filesystems."
+SECTION = "base"
+LICENSE = "GPLv2 & Public Domain"
+LIC_FILES_CHKSUM = "file://../COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+ file://../../7zC.txt;beginline=12;endline=16;md5=2056cd6d919ebc3807602143c7449a7c \
+ "
+DEPENDS = "attr zlib xz"
+PR = "0"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/squashfs/squashfs${PV}.tar.gz;name=squashfs \
+ http://downloads.sourceforge.net/sevenzip/lzma465.tar.bz2;name=lzma \
+ "
+SRC_URI[squashfs.md5sum] = "1b7a781fb4cf8938842279bd3e8ee852"
+SRC_URI[squashfs.sha256sum] = "d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96"
+SRC_URI[lzma.md5sum] = "29d5ffd03a5a3e51aef6a74e9eafb759"
+SRC_URI[lzma.sha256sum] = "c935fd04dd8e0e8c688a3078f3675d699679a90be81c12686837e0880aa0fa1e"
+
+S = "${WORKDIR}/squashfs${PV}/squashfs-tools"
+
+# EXTRA_OEMAKE is typically: -e MAKEFLAGS=
+# the -e causes problems as CFLAGS is modified in the Makefile, so
+# we redefine EXTRA_OEMAKE here
+EXTRA_OEMAKE = "MAKEFLAGS= LZMA_SUPPORT=1 LZMA_DIR=../.. XZ_SUPPORT=1"
+
+do_compile() {
+ oe_runmake mksquashfs
+}
+do_install () {
+ install -d ${D}${sbindir}
+ install -m 0755 mksquashfs ${D}${sbindir}/
+}
+
+# required to share same place with -lzma specific packages
+FILESPATHPKG =. "squashfs-tools-${PV}:"
+
+ARM_INSTRUCTION_SET = "arm"
+
+BBCLASSEXTEND = "native"
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/8] libatomics-ops: force ARM mode
From: Martin Jansa @ 2011-10-21 16:21 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soEYSZvnDKPTT+63r759mKV753wgXY2PuYU2rtii8KZLg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
On Fri, Oct 21, 2011 at 09:06:34AM -0700, Khem Raj wrote:
> On Fri, Oct 21, 2011 at 1:48 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Fri, Oct 21, 2011 at 10:43:46AM +0200, Henning Heinold wrote:
> >> Hi,
> >>
> >> hm we should think of reworking this recipe now. Because since gcc 4.5
> >> pulseaudio for arm can use the gcc internal atomicstuff and in oe-core
> >> and meta-oe we have 4.5 or 4.6 only. The lib is
> >> only needed for mips and it is still the old release, on cvs
> >> is a much better version, which supports thumb too, if
> >> remember correctly.
> >
> > Agreed, I've added this only because pulseaudio is now needed for
> > gst-plugins and I wasn't able to build any armv[45]t images.
> >
> > But because I don't know much about pulseaudio or libatomics-ops I was
> > hoping that someone who maintains them will fix it properly and this
> > work around will be needed only temporary.
>
> Would you have cycles to create a git recipe for it the git tree is here
> https://github.com/ivmai/libatomic_ops/
Sorry, I'm not going to spend more of my free time on stuff I've never
used on my phones at least as long as we have broken stuff which we're
using almost daily.
But I can keep this work around or .bbappend dropping whole pulseaudio
in SHR until someone fixes it properly or until I fix all other issues
we have.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* MINUTES: OE-TSC meeting 20-Oct-2011
From: Jeff Osier-Mixon @ 2011-10-21 16:19 UTC (permalink / raw)
To: openembedded-core, openembedded-devel, tsc
[-- Attachment #1: Type: text/plain, Size: 27063 bytes --]
MINUTES: OE-TSC meeting 20-Oct-2011
Attending: Mark, Richard, Khem, Koen, Tom
Notes: Jefro
________________________________________________________
Agenda & Results
(0) GA
- discussion about candidacy, maintainership & what to bring up & answer
at GA
- ACTION: tsc introspection in next meeting
(1) distro fields
- Saul planning to think about it & write proposal
(2) bugzilla
- ACTION: Khem to shut down bugzilla, create a landing page
(4) oe-core status
- ACTION: Khem & RP to drive tarball release to github
- ACTION: Koen to look into git push hooks for mirroring
(6) PR stuff
- ACTION: RP to refresh discussion on ML
(7) infrastructure status
- server changes in process, no ETA on completion
Agendized but not discussed:
(3) oe-core with selinux, other security
(5) review tools
________________________________________________________
Raw Transcript:
(1:04:49 PM) Jefro: I think everyone is here
(1:05:54 PM) khem: topics I would like to bring up two things. Distro fields
and bring down bugzilla
(1:06:01 PM) RP__: Jefro: I think so
(1:06:02 PM) fray: ok.. so I have a potential agenda item.. oe-core with
things like selinux support... or other "security" infrastructure changes..
(1:06:15 PM) fray: (I'm happy to table that to the future as well)
(1:06:21 PM) RP__: OE-Core release (and Bitbake)
(1:06:45 PM) khem: review tools
(1:06:56 PM) RP__: There are also calls for the TSC to talk about the PR
stuff
(1:08:06 PM) Jefro: topics: (1) distro fields (2) bugzilla (3) oe-core with
selinux, other security (4) oe-core status (5) review tools (6) PR stuff
(1:09:27 PM) khem: RP__: oh lastly some infra updates too
(1:09:50 PM) Jefro: topics contd (7) infrastructure status
(1:11:20 PM) RP__: As a group is there anything we want to represent the GA?
(1:11:52 PM) khem: RP__: a short update I guess
(1:11:52 PM) fray: RP__ I have the opposite.. is there anything we want to
ask of the members at the GA?
(1:11:55 PM) khem: would be nice
(1:12:15 PM) RP__: fray: indeed, that is where I was going next :)
(1:12:33 PM) RP__: We've seen some feedback from Frans and he has some valid
questions
(1:12:50 PM) Jefro: topics (0) GA
(1:13:03 PM) RP__: Jefro: sorry ;-)
(1:13:11 PM) Jefro: :) no prob
(1:13:41 PM) RP__: So anything specific to take to the GA other than general
updates and what was said on the members list?
(1:14:04 PM) RP__: Did anyone disagree with anything said on the members
list re: the TSC?
(1:14:24 PM) Tartarus: nope
(1:14:37 PM) fray: RP__ are your eferring to the call for candidates?
(1:14:39 PM) khem: was ok. I think
(1:14:47 PM) RP__: fray: the discussion that followed, yes
(1:15:10 PM) koen: RP__: I disagree, fwiw
(1:15:20 PM) RP__: I think the summary was that there are things we are
doing well, there are some things that are less well. We're only human but
its useful to keep people's feedback in mind
(1:15:20 PM) fray: yup.. ok..
(1:15:35 PM) fray: I think many of the points there are valid..
(1:15:49 PM) koen: I still think the TSC should *NOT* have taken away
maintainership of meta-oe
(1:15:56 PM) RP__: Some things are inevitable even with the resources Yocto
brings etc, we can't do everything
(1:16:55 PM) fray: I always come back to.. maintainership of any OE project
is up to the member(s) contributing to it..
(1:17:19 PM) fray: if people want to be maintainers they need to step up and
say that.. otherwise the TSC needs to do whatever is necessary to further
the layers..
(1:17:34 PM) khem: I think we should do a TSC introspection in next meeting
(1:17:47 PM) khem: where we talk about where we lack and where we are ok
(1:17:51 PM) RP__: I think there will be further discussion at the GA - I
agree we should revisit the topic after the GA
(1:19:16 PM) RP__: Jefro: Might I suggest topic 1 unless there is more
discussion?
(1:20:34 PM) khem: I think pb's point on incubating new developers was what
stuck with me
(1:23:03 PM) RP__: khem: agreed, I think we do need to incubate new
developers
(1:30:52 PM) Jefro: ok to move to next topic? 6 to go
(1:31:19 PM) RP__: I'd suggest we do
(1:32:01 PM) RP__: For distro fields, I don't think its clear cut. I think
Saul is going to think about it and give a proposal
(1:32:19 PM) RP__: and since he uses those most heavily I'd like to hear
that feedback before we go further on that
(1:32:39 PM) RP__: so its probably fine to continue on the mailing list for
now unless anyone has any pressing comments to add?
(1:32:43 PM) koen: I have no strong opinion on the fields except that
monolithic files suck in general
(1:32:52 PM) RP__: I agree with that and I hear you
(1:33:30 PM) fray: are we talking the maintainer fields or?
(1:33:44 PM) khem: distro tracking fields file
(1:34:09 PM) RP__: fray: that and the other distro tracking data (manual
update data, other distro equivalence fields etc.)
(1:34:11 PM) fray: ok.. ya, agree.. I prefer them in the recipes (or at
least the recipes directory...) but that can get messy
(1:34:17 PM) RP__: For bugzilla, I thought we'd agreed to shut it down?
(1:34:35 PM) fray: (oe bugzilla right?) and yes, we had.. since it was more
or less abandoned
(1:34:58 PM) RP__: yes
(1:34:58 PM) koen: the question is about killing the instance
(1:35:05 PM) koen: it has been RO for months now
(1:35:27 PM) fray: do we have any analytics that show if people are using it
(in a RO capability) still?
(1:35:30 PM) Tartarus: Time for a little more ngix redirect magic?
(1:35:50 PM) ***koen needs to finish the ngix recipe
(1:36:04 PM) RP__: So the con of taking it down is the lack of the data
being public anymore?
(1:36:08 PM) RP__: Is anyone using it?
(1:36:22 PM) khem: RP__: there are links on mails and if people use them
then we should have a page where it gives the information
(1:36:24 PM) RP__: Is any of the data there still relevant? Are people
accessing it?
(1:36:29 PM) fray: ya.. if nobody is using it.. then I'm not concerned.. if
it's still getting used.. is it relevant?
(1:36:48 PM) khem: RP__: I have no idea, no one adds data to it but access
wise I dont know if people do
(1:37:00 PM) fray: I'm not against removing it entirely.. I just hate
historical items disappearing. especially if there may be useful data in it
to explain why something happened in the past
(1:37:29 PM) RP__: is keeping it alive read only a problem?
(1:37:35 PM) khem: fray: there are links that people used in mails and if
someone searches such mails thats the only thing that we should care since
we can not edit those links
(1:37:43 PM) khem: RP__: that server is going away
(1:37:58 PM) khem: and we need to set it up again on new server
(1:37:58 PM) RP__: khem: hard to migrate?
(1:38:07 PM) khem: RP__: I guess not
(1:38:09 PM) khem: but its work
(1:38:19 PM) RP__: khem: it might be worth the effort and easier than a
landing page for the email links?
(1:38:24 PM) khem: I personally would not want to do it
(1:38:33 PM) khem: RP__: yes a landing page
(1:38:35 PM) khem: is good
(1:38:51 PM) RP__: what I mean is its probably just as much work to
transition the data?
(1:38:57 PM) RP__: The data should be saved anyway?
(1:39:08 PM) khem: yes its there
(1:39:09 PM) fray: ya, at a minimum we should have a landing page explaining
it went away... but I do prefer saving the data
(1:40:00 PM) khem: the databases are saved
(1:40:07 PM) khem: so it will be there
(1:40:14 PM) khem: just not visible
(1:40:27 PM) RP__: Perhaps ask on the mailing lists, see if anyone has
strong views?
(1:40:35 PM) khem: I already did
(1:40:42 PM) RP__: any response?
(1:40:53 PM) khem: most of responders were ok with it going away
(1:41:03 PM) khem: provided we have a landing page
(1:41:12 PM) fray: I'd say bring this up at the GA... but assuming we have a
landing page.. it'll go away
(1:41:27 PM) RP__: fray: not really a GA topic tbh
(1:41:43 PM) fray: I would have thought the members would be the ones to
care if it exists (or not)
(1:41:52 PM) fray: I'm not asking for a vote, just feedback
(1:42:02 PM) RP__: khem: I'm marginally in favour of setting up bugzilla to
share the data but only just if you see what I mean
(1:42:09 PM) khem: bugzilla was used by new user more often than seasoned
developes in my experience
(1:42:27 PM) khem: RP__: ok.
(1:42:40 PM) ***RP__ notes a timecheck
(1:42:55 PM) koen: I'd say a landing page is good enough
(1:43:02 PM) RP__: 5 items to go, 15 mins
(1:43:09 PM) koen: either we have a bugzilla or we don't, halfway sucks
(1:43:16 PM) ***Jefro notes the data can always be resurrected if the
complaints are loud
(1:43:38 PM) khem: I agree with koen
(1:44:03 PM) khem: and maintaining it is also some work plus the internet
traffic that comes from web crawlers
(1:44:21 PM) Jefro: if there is general agreement /me notes action item:
landing page, bugzilla removed
(1:44:32 PM) fray: no objection
(1:44:41 PM) Tartarus: no objection
(1:44:57 PM) RP__: (3) oe-core with selinux, other security (4) oe-core
status (5) review tools (6) PR stuff (7) infrastructure status
(1:45:14 PM) koen: can we move 6 up?
(1:45:17 PM) fray: we can table the discussion and move on or I can briefly
explain
(1:45:24 PM) fray: (and I'm happy to move it to the end)
(1:45:32 PM) RP__: We need to touch on 4 and 6 IMO
(1:45:53 PM) Tartarus: With 15min? maybe just 4 and 7?
(1:46:01 PM) RP__: Do we want to release OE-Core/Bitbake? Assuming the
answer is yes, who is going to which pieces of it?
(1:46:03 PM) Tartarus: Lets start 4 tho :)
(1:46:28 PM) khem: yes release is needed
(1:46:34 PM) RP__: I have the trees in a position we could do it
(1:46:58 PM) RP__: I'd kind of like to do it in their current states since
that was was was heavily tested for Yocto 1.1
(1:47:21 PM) RP__: but I have no place to put the tarballs and I think the
release annoucement would look better coming from someone other than me?
(1:47:41 PM) khem: I think both release at same time but other layers
(1:48:06 PM) khem: RP__: I have opened the ticket to get
downloads.openembedded.org back
(1:48:12 PM) fray: yes release
(1:48:13 PM) khem: but its still pending
(1:48:19 PM) RP__: khem: ETA?
(1:48:25 PM) khem: no
(1:48:25 PM) koen: we can start with a tag in the repo
(1:48:28 PM) khem: I will ask
(1:48:30 PM) fray: can we tag now, prepare the release.. and sit on it?
(1:48:36 PM) fray: (until downloads.... is ready?)
(1:48:38 PM) koen: and put tarballs on github temporary
(1:48:41 PM) fray: what about github?
(1:48:46 PM) RP__: Call this bitbake 1.14.0 ?
(1:48:48 PM) fray: koen, ya..
(1:48:53 PM) fray: RP__ I would think so
(1:48:58 PM) khem: yes tars can be put any time
(1:48:59 PM) RP__: Its probably more than a point release at this point
(1:49:19 PM) koen: no opinion on bitbake versioning here
(1:49:28 PM) RP__: it sucks to have to use github for tarballs :/
(1:49:38 PM) RP__: khem: the problem is the DNS?
(1:49:49 PM) koen: at least github is fast
(1:50:04 PM) khem: I think yes. I thought Tom K will figure it
(1:50:19 PM) RP__: khem: Can you take the AR to drive that?
(1:50:25 PM) khem: ok
(1:50:32 PM) khem: however I am gone for next 3 weeks
(1:50:37 PM) khem: starting sunday
(1:50:53 PM) RP__: khem: hmm, will you have time before you go to ping him?
(1:51:10 PM) khem: yes surely
(1:51:20 PM) khem: hopefully we can set it us as well
(1:51:32 PM) RP__: So given no other volunteers, I guess I'll have to drive
the announcement and work through this?
(1:51:32 PM) ***Jefro notes action item for khem to drive tarball release to
github this week
(1:51:55 PM) koen: with a oe-core tag in place I can drive the meta-oe part
(1:52:05 PM) RP__: koen: ok, thanks
(1:52:09 PM) koen: (and meta-angstrom, meta-ti, setup-scripts, etc, but
that's not OE)
(1:52:31 PM) khem: RP__: I can help with announcement if you need and if its
planned before I leave
(1:53:00 PM) RP__: khem: with me moving atm, I'm not sure when/how i'm going
ot manage this :/
(1:53:10 PM) khem: sure ok
(1:53:11 PM) RP__: but I know our users are not happy and it needs to get
done
(1:53:31 PM) RP__: so, probably best to cover 7
(1:53:42 PM) koen: infra status
(1:53:43 PM) RP__: particularly if khem is missing
(1:53:50 PM) fray: I'm happy to help with the release... tell me what needs
to be done (announcements, wiki, etc).. but I don't have the git perms to do
the actual release work
(1:54:34 PM) RP__: Is the TSC happy for me to handle the announcement, I
guess that is the question. I'd not like to presume :)
(1:54:40 PM) koen: I am
(1:54:55 PM) fray: i am
(1:55:00 PM) khem: on 7 we have moved all services to new VM
(1:55:03 PM) khem: I am ok
(1:55:03 PM) RP__: fray: I'll see how we can work this out and pull you in
if/as needed
(1:55:07 PM) fray: ok
(1:55:29 PM) RP__: khem: cool, thanks for the work you/Tom and anyone else
involved have put in!
(1:55:40 PM) ***Jefro 5 minute warning
(1:55:59 PM) khem: Tom also has build box installed and we should have
access to it soon
(1:56:05 PM) khem: but no ETA
(1:56:29 PM) RP__: khem: ok, cool :)
(1:56:51 PM) RP__: Do we want to extend the meeting to cover some of the
other topics?
(1:56:53 PM) khem: on old VM we have github mirroring crob tasks
(1:56:55 PM) RP__: or leave until next time?
(1:57:01 PM) Tartarus: next time for me
(1:57:04 PM) khem: that pb runs should move to new VM
(1:57:08 PM) khem: when he has time
(1:57:39 PM) koen: s/crob/cron/
(1:57:49 PM) koen: we should make them git push hooks
(1:58:07 PM) Jefro: any other high-priority items to discuss before GA next
week?
(1:58:07 PM) khem: yes its possible to make them hooks
(1:58:08 PM) koen: (I can look into that after ELC-E, we're going to do that
for meta-ti)
(1:58:25 PM) khem: I looked into them briefly
(1:58:50 PM) RP__: The push hooks would delay people's pushes though
wouldn't they?
(1:59:19 PM) koen: no idea, but I can look into that
(1:59:29 PM) khem: RP__: yes a bit
(1:59:33 PM) koen: Jefro: can you make that an AR for me?
(1:59:46 PM) ***Jefro notes action item for koen to look into push hooks
(2:00:03 PM) RP__: It is annoying if you have a raft of things to push out
and each one has time lag :/
(2:00:43 PM) koen: you'll be one of the 2 people affected, the other one is
me for meta-oe
(2:00:53 PM) khem: you mean multiple push ?
(2:00:57 PM) koen: and our bus factor reducers, saul, khem, etc
(2:01:06 PM) RP__: koen: right
(2:01:26 PM) RP__: It was "fun" watching the patchwork hooks slow things
down today
(2:03:04 PM) RP__: So that brings us past time :/
(2:03:05 PM) Jefro: remaining issues? I remember that Tartarus had to flee
at 2pm
(2:03:20 PM) koen: ironically the pw hooks refused to update the patch khem
sent :)
(2:03:46 PM) khem: koen: what was error ?
(2:04:02 PM) khem: was it generic error
(2:04:03 PM) koen: it couldn't correlate the patch I pushed with the one in
pw
(2:04:13 PM) khem: hmmm
(2:04:25 PM) khem: did it happen only for 1 patch or others too
(2:04:37 PM) RP__: The PR issues probably does need addressing and is a TSC
centric issue
(2:04:53 PM) RP__: We need to do that when we're all here thoug
(2:05:37 PM) khem: RP__: PR = problem report ?
(2:05:45 PM) khem: or the publicity
(2:05:55 PM) fray: package release
(2:06:06 PM) RP__: khem: The PR bumping discussion on the mailing list
(2:06:10 PM) koen: Package Revision
(2:06:12 PM) khem: oh I see
(2:07:40 PM) RP__: Are we closing the meeting?
(2:07:48 PM) koen: I still have time
(2:07:54 PM) fray: we can.. or we can discuss other things.. I have time
(2:08:07 PM) khem: I can spend some more mins
(2:08:28 PM) ***Jefro can stick around
(2:09:04 PM) fray: ok, next topic then? PR (or is Tartarus gone?)
(2:09:24 PM) koen: I bet Tartarus is screaming at uboot
(2:09:34 PM) Tartarus: I'm semi here still
(2:09:36 PM) ***fray does that every now and then
(2:09:40 PM) Tartarus: Need to put Daughter down for a nap then run errands
(2:10:44 PM) RP__: So I think our future direction from an architecture
point of view needsto be to automate the PR bumps
(2:11:11 PM) RP__: Why? Currently its unclear which bumps are needed to
which packages and when. It also totally breaks down with layers
(2:11:28 PM) khem: RP__: I agree
(2:11:34 PM) RP__: The values would be better maintained alongside the
distro feeds that contain the used values
(2:11:38 PM) khem: so do we maintain a database or how
(2:11:44 PM) khem: ah
(2:12:00 PM) RP__: The trouble is this change will be a bit painful
(2:12:13 PM) RP__: We've put off enabling the BasicHash handler for a long
time now
(2:12:56 PM) RP__: I'd really like to see people thinking and working
towards addressing these issues. As such I refused a patch to OE core adding
manual PR increment functionality
(2:13:00 PM) khem: RP__: so if I dont have any feeds where do the initial
values come from
(2:13:19 PM) RP__: khem: We need some tools to handle some of these things
(2:13:26 PM) Tartarus: I think day 1 after a release is about when we need
to turn on the solution, or at least the current proposal
(2:13:33 PM) RP__: khem: they'd default to starting at 0
(2:13:34 PM) koen: the issue otavio raised is that the kernel.bbclass line
RP draws is arbitrary
(2:13:42 PM) Tartarus: So if basic hash should be able to get us most of the
way, time to switch
(2:13:49 PM) khem: RP__: so distro's then cant share feeds ?
(2:13:51 PM) RP__: Tartarus: I'd love to throw the BasicHash switch now
(2:13:54 PM) fray: ya.. this is something that is going to take time for
people to ome to terms with -- or object so strongly we revert..
(2:14:01 PM) Tartarus: I vote now, and am mostly afk, now
(2:14:04 PM) fray: the hash thing needs to be done ASAP.. the PR thing is
what may or may not work
(2:14:05 PM) koen: Tartarus: you will kill rebuilding from (old) tags
(2:14:08 PM) RP__: khem: only if they sync up PR data
(2:14:11 PM) fray: but I vote as soon as we tag and release
(2:14:36 PM) koen: this auto-pr things needs to be done in a branch and
merged when it works good enough
(2:14:38 PM) RP__: We do have the network PR service that we created a while
back
(2:14:57 PM) fray: I assume the auto-pr stuff is the network PR service, w/o
the network
(2:15:05 PM) koen: I think I've already shown that that network PR thingy is
worthless for any real work?
(2:15:08 PM) RP__: I think that with some not so difficult improvements to
save the data to metadata and back we can address the reproducibility issues
(2:15:28 PM) RP__: koen: Its not worthless, you've just found a usecase it
doesn't cover
(2:15:35 PM) RP__: koen: the world isn't black/white
(2:15:42 PM) RP__: fray: yes
(2:16:07 PM) koen: I'm trying to make it more black and white so that it
will go in a branch first
(2:16:09 PM) fray: ya, in that case, I'm fairly comfortable with it.. enough
to explain to the world the possible pain and to turn it on
(2:16:33 PM) RP__: fray: I do understand this will cause koen and anyone
else with distro feeds some problems
(2:16:34 PM) fray: but geting the updated hashing first is key IMHO..
(2:16:44 PM) koen: if the changes are really "not so diffucult" the branch
will be short lived
(2:16:53 PM) fray: we SHOULD be able to seed the data though with the feed
info, right?
(2:17:09 PM) RP__: fray: the feed info is the current set of PR values
(2:17:21 PM) RP__: which I guess we need to "export" to an include
(2:17:26 PM) khem: I see
(2:17:28 PM) fray: ya, current PR's which can be tied back to specific hash
values right?
(2:17:41 PM) RP__: once we can import/export the data from the PR service to
an include we should be good to go IMO
(2:17:53 PM) fray: that was my thought as well..
(2:17:54 PM) RP__: fray: hash value is distro specific
(2:18:20 PM) khem: RP__: do I assume its going to be a file or some such
that will be updated after build ?
(2:18:21 PM) RP__: So my vote is not for now instantly but very soon
(2:18:22 PM) koen: I still say it should live in a branch at first
(2:18:28 PM) RP__: once we have the import/export script
(2:18:46 PM) koen: I've seen the eglibc fallout from a recent experiment
(2:18:49 PM) RP__: and since this will happen soon, we shouldn't be taking
PR bump type features into OE-Core at this point
(2:18:55 PM) fray: koen, my only problem with "branches" is getting people
to use them
(2:19:19 PM) koen: my problem is with people knowingly breaking master using
that excuse
(2:19:50 PM) fray: well, the goal is to not knowingly break master with this
change.. but to expect (and react) to the unknown issues
(2:20:04 PM) koen: I know I'm not going to live test it in master, I'll roll
back to the release
(2:20:30 PM) koen: testing a branch is no problem
(2:20:38 PM) koen: since this will be messy
(2:20:44 PM) khem: put it in master-next
(2:20:56 PM) khem: and we can test it out
(2:20:58 PM) ***RP__ will make no comment about how long the feedback for
the network PR service took
(2:21:31 PM) koen: it was too hard to test for me, being based on poky and
all
(2:21:39 PM) koen: </lame excuse>
(2:21:56 PM) ***RP__ tries not to choke ;-)
(2:22:25 PM) RP__: So, I'm suggesting that we so look to do this stuff soon
once we have the import/export scripting working and hopefully once koen is
happy we have some kind of solution in place than can work for his usecases
(2:22:42 PM) fray: seems reasonable
(2:22:45 PM) RP__: this will rely on some mailing list discussions, testing
and some help
(2:22:53 PM) koen: and in the meantime can we apply that kernel.bbclass
path?
(2:22:57 PM) RP__: and it will be with some of the Yocto PRC team doing some
of this
(2:23:00 PM) RP__: koen: no
(2:23:02 PM) koen: I really want to remove it from meta-oe
(2:23:44 PM) koen: OTOH, I can ignore any hatemail about meta-oe overrides
now
(2:24:29 PM) RP__: koen: How many more patches will I get if I take that
one?
(2:24:58 PM) koen: to sync meta-oe classes involving PR? none
(2:25:08 PM) RP__: koen: For PR in general
(2:25:25 PM) koen: you're saying any patch touching PR will get
rejected??!?!
(2:25:53 PM) RP__: For bulk PR handling with new variables I'll reject
(2:26:07 PM) koen: there's only INC_PR and MACHINE_KERNEL_PR
(2:26:11 PM) RP__: I'll continue to grudgingly tolerate the PR bumps for now
(2:26:15 PM) koen: in classic OE
(2:26:23 PM) RP__: koen: but people want to add more
(2:26:36 PM) koen: since only otavio and I could be arsed to 'fix' PR
problems there
(2:26:58 PM) koen: RP__: 'people' don't get PR anyway
(2:27:12 PM) koen: so I wouldn't worry about magic PR helpers appearing
(2:27:30 PM) RP__: koen: so we need to start educating them and the
MACHINE_KERNEL_PR sends totally the wrong message :/
(2:27:45 PM) RP__: I know you understand the issue, others will not
(2:27:48 PM) koen: it does, but it will remove a bbclass overlay
(2:27:49 PM) khem: RP__: take it for now and then drop it when Auto PR is in
(2:28:05 PM) RP__: Then I'll be accused of breaking existing functionality
(2:28:08 PM) koen: I'm getting too much crap about it being overlayed
(2:28:31 PM) koen: (which I can now say is not my fault, pesky OE core
maintainer ;)
(2:28:38 PM) ***RP__ gets too much crap about PR values in general
(2:29:09 PM) RP__: koen: you can blame me for now, this isn't going to be
for long
(2:29:13 PM) fray: PR is one of those things you need a distribution
maintainer and policy for.. otherwise inconsistencies easily creep in.. :(
(2:29:14 PM) koen: RP__: consider that I silently 'repair' feeds a few times
a week due to oe-core messing up upgrade paths
(2:29:35 PM) RP__: koen: I have really tried to help with this
(2:29:39 PM) koen: I know
(2:29:48 PM) koen: that's why I don't report every incident
(2:29:51 PM) RP__: koen: This is also why I want to get something automated
(2:29:57 PM) khem: RP__: OK so the network PR stuff is what we want to use
here
(2:30:30 PM) koen: but please realize that in general oe-core is a huge pain
for people with a binary distro feed
(2:30:39 PM) koen: we all try hard, but we are failing
(2:30:57 PM) RP__: koen: This is why we need a change in approach
(2:31:00 PM) koen: exactly
(2:31:22 PM) khem: koen: I think having PR controlled by distro's is sane I
guess ?
(2:31:36 PM) koen: doesn't really matter where
(2:32:08 PM) fray: PR is a distribution "issue".. and we need to provide the
tools (and data) to make it easier to manager
(2:32:08 PM) koen: ideally a recipe maintainer knows best
(2:32:20 PM) koen: e.g. xorg changed abi
(2:32:32 PM) koen: so things like xf86-video-fbdev need rebuilding
(2:32:48 PM) koen: (I 'repaired' the feeds for that yesterday)
(2:33:11 PM) fray: yup these are the things that hashing and auto PR should
help with
(2:33:14 PM) fray: (I hope)
(2:33:14 PM) koen: the fs-perms.txt change in angstrom is another
(2:33:20 PM) RP__: koen: Are false positives a problem?
(2:33:26 PM) koen: RP__: not for me
(2:33:38 PM) khem: koen: I think if we rebuild more its suboptimal but ok I
think
(2:33:44 PM) RP__: koen: ok
(2:34:03 PM) koen: PR is really a "better safe than sorry" type of thing
(2:34:04 PM) RP__: We'll obviously look to not rebuild more than we need but
its going to take a little experimentation
(2:34:18 PM) khem: agree
(2:34:28 PM) RP__: the checksum code does er on the side of false positives
(2:34:54 PM) khem: RP__: why not send a proposal
(2:34:55 PM) khem: to ml
(2:35:34 PM) RP__: khem: It has been discussed before, just a while ago.
Refreshing people's memory is probably good I guess
(2:35:39 PM) RP__: but release takes priority
(2:36:04 PM) khem: ok yes I think release should happen before this change
for sure
(2:36:27 PM) koen: I'd still like it to sit in master-next for a while
(2:36:55 PM) RP__: koen: Lets see how this goes
(2:37:10 PM) ***RP__ next needs to explain what the problem is to the Yocto
PRC people
(2:37:18 PM) khem: koen: RP__ yes master-next should have it for a while so
distro maintainers can adapt to it in background
(2:37:21 PM) ***RP__ might as well give up on a day off tomorrow
(2:37:32 PM) RP__: and the house moving thing
(2:37:48 PM) khem: RP__: you need 25th hour
(2:37:58 PM) RP__: khem: and the rest :/
(2:38:18 PM) khem: thats what it is for sleep 1 hr :)
(2:38:23 PM) khem: and work 24
(2:38:55 PM) khem: I need to make a move
(2:39:12 PM) khem: bye see u in 3 weeks
(2:39:25 PM) RP__: khem: safe travels!
(2:39:31 PM) fray: sounds good! have a good time
(2:39:40 PM) khem: I will
(2:39:55 PM) khem: watch out me flying over eu on 26th :)
(2:40:07 PM) khem: I will wave when I am over Germany :)
(2:40:30 PM) Jefro: safe travels khem
(2:40:37 PM) khem: thx
(2:40:44 PM) khem left the room.
(2:41:02 PM) ***koen also needs to zzz soon
(2:41:36 PM) Jefro: meeting adjourned?
(2:43:12 PM) RP__: Jefro: yes! :)
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
[-- Attachment #2: Type: text/html, Size: 31599 bytes --]
^ permalink raw reply
* Re: [PATCH] squashfs-tools: add recipe (2nd try)
From: Saul Wold @ 2011-10-21 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Cliff Brake
In-Reply-To: <20111019212659.GA30050@sakrah.homelinux.org>
On 10/19/2011 02:26 PM, Khem Raj wrote:
> On (19/10/11 08:43), Cliff Brake wrote:
>> From: Cliff Brake<cbrake@bec-systems.com>
>>
>> added xz compression option, general cleanup
>> ---
>> .../squashfs-tools/squashfs-tools_4.2.bb | 38 ++++++++++++++++++++
>> 1 files changed, 38 insertions(+), 0 deletions(-)
>> create mode 100644 meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
>>
>
> IIRC they did not work with thumb mode so you might have to add option
> to always build for arm mode when building for arm architectures.
> Add ARM_INSTRUCTION_SET = "arm" to the recipe
>
>> diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
>> new file mode 100644
>> index 0000000..3a9f12a
>> --- /dev/null
>> +++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
>> @@ -0,0 +1,38 @@
>> +# Note, we can probably remove the lzma option as it has be replaced with xz,
>> +# and I don't think the kernel supports it any more.
>> +DESCRIPTION = "Squashfs is a highly compressed read-only filesystem for Linux."
>
> I think this description is for the filesystem but the recipe is for
> tools. So probably saying something like "Tools for manipulate squashfs,
> ..." would be nice.
>
>> +SECTION = "base"
>> +LICENSE = "GPLv2& Public Domain"
>> +LIC_FILES_CHKSUM = "file://../COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
>> + file://../../7zC.txt;beginline=12;endline=16;md5=2056cd6d919ebc3807602143c7449a7c \
>> + "
>> +DEPENDS = "attr zlib xz"
>> +PR = "0"
>> +
>> +SRC_URI = "${SOURCEFORGE_MIRROR}/squashfs/squashfs${PV}.tar.gz;name=squashfs \
>> + http://downloads.sourceforge.net/sevenzip/lzma465.tar.bz2;name=lzma \
>> + "
>> +SRC_URI[squashfs.md5sum] = "1b7a781fb4cf8938842279bd3e8ee852"
>> +SRC_URI[squashfs.sha256sum] = "d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96"
>> +SRC_URI[lzma.md5sum] = "29d5ffd03a5a3e51aef6a74e9eafb759"
>> +SRC_URI[lzma.sha256sum] = "c935fd04dd8e0e8c688a3078f3675d699679a90be81c12686837e0880aa0fa1e"
>> +
>> +S = "${WORKDIR}/squashfs${PV}/squashfs-tools"
>> +
>> +# EXTRA_OEMAKE is typically: -e MAKEFLAGS=
>> +# the -e causes problems as CFLAGS is modified in the Makefile, so
>> +# we redefine EXTRA_OEMAKE here
>> +EXTRA_OEMAKE = "MAKEFLAGS= LZMA_SUPPORT=1 LZMA_DIR=../.. XZ_SUPPORT=1"
>> +
>> +do_compile() {
>> + oe_runmake mksquashfs
>> +}
>> +do_install () {
>> + install -d ${D}${sbindir}
>> + install -m 0755 mksquashfs ${D}${sbindir}/
>> +}
>> +
>> +# required to share same place with -lzma specific packages
>> +FILESPATHPKG =. "squashfs-tools-${PV}:"
>> +
>> +BBCLASSEXTEND = "native"
>> --
>> 1.7.1
>>
>>
This one is on hold pending an update from Cliff based on Khem's comments.
Sau!
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Martin Jansa @ 2011-10-21 16:16 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soRAhf065VCJqZsQMUct1a0Ob5S2rJzN9QpE0A0R0SZ6g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
> On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > index 4ac2418..2f872b8 100644
> > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > @@ -23,3 +23,4 @@ do_compile_prepend() {
> > cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
> > }
> >
> > +ARM_INSTRUCTION_SET = "arm"
>
> not averse to patch but it would be nice to know what fails in thumb mode.
selected processor does not support Thumb mode `swp r1,r2,[r3]'
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] libatomics-ops: force ARM mode
From: Khem Raj @ 2011-10-21 16:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111021084840.GP3522@jama.jama.net>
On Fri, Oct 21, 2011 at 1:48 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Oct 21, 2011 at 10:43:46AM +0200, Henning Heinold wrote:
>> Hi,
>>
>> hm we should think of reworking this recipe now. Because since gcc 4.5
>> pulseaudio for arm can use the gcc internal atomicstuff and in oe-core
>> and meta-oe we have 4.5 or 4.6 only. The lib is
>> only needed for mips and it is still the old release, on cvs
>> is a much better version, which supports thumb too, if
>> remember correctly.
>
> Agreed, I've added this only because pulseaudio is now needed for
> gst-plugins and I wasn't able to build any armv[45]t images.
>
> But because I don't know much about pulseaudio or libatomics-ops I was
> hoping that someone who maintains them will fix it properly and this
> work around will be needed only temporary.
Would you have cycles to create a git recipe for it the git tree is here
https://github.com/ivmai/libatomic_ops/
>
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
^ permalink raw reply
* Re: [PATCH 3/4] base-passwd: move initial criation of group and passwd to preinst
From: Otavio Salvador @ 2011-10-21 16:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA18712.4050904@windriver.com>
On Fri, Oct 21, 2011 at 12:52, Mark Hatle <mark.hatle@windriver.com> wrote:
...
> Any opinions from folks if this is even halfway reasonable for us to consider?
>
> (I'm guessing with some anon python code we could probably load in the
> passwd/group files, place them into a variable and use the variable to embed
> them within the preinst -- keeping the contents out of the recipe.)
I like this idea but I'd prefer to have this merged before it.
--
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: [PATCH 1/4] bootimg.bbclass: add support to disable HDD image building
From: Khem Raj @ 2011-10-21 15:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKqYn0WY2qsCttbdvCvJJnQpuKvmH79u4aAXs-XbQfCMYQ@mail.gmail.com>
On Fri, Oct 21, 2011 at 5:27 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Fri, Oct 21, 2011 at 04:07, Khem Raj <raj.khem@gmail.com> wrote:
>> On Thu, Oct 20, 2011 at 8:31 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>> ---
>>> meta/classes/bootimg.bbclass | 44 +++++++++++++++++++++--------------------
>>> 1 files changed, 23 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
>>> index a5ba3cf..eecc2bf 100644
>>> --- a/meta/classes/bootimg.bbclass
>>> +++ b/meta/classes/bootimg.bbclass
>>> @@ -48,34 +48,36 @@ SYSLINUXMENU = "${HDDDIR}/menu"
>>> inherit syslinux
>>>
>>> build_boot_bin() {
>>> - install -d ${HDDDIR}
>>> - install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage \
>>> - ${HDDDIR}/vmlinuz
>>> + # Create an HDD image
>>> + if [ "${NOHDD}" != "1" ] ; then
>>
>> please document this new variable NOHDD somewhere so people know how
>> and when to use it
>
> What do you suggests.
Either OE manual or local.conf.sample.extended may be
>
> --
> 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
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH] mesa-dri: move extra DRIMODULES to EXTRA_DRIMODULES
From: Khem Raj @ 2011-10-21 15:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CA+chaQdAQm1jLLJxC1dSUSu+kgo-JqMffVDur=JNxpe-HGczMg@mail.gmail.com>
On Fri, Oct 21, 2011 at 12:34 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> So I've to change it to
> DRIDRIVERS_append_arm
> or is it TRANSLATED_TARGET_ARCH fault?
>
Yes I think that's what changed it. I think it makes sense to have arm
subfamily in overrides from oe-core
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Koen Kooi @ 2011-10-21 15:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soRAhf065VCJqZsQMUct1a0Ob5S2rJzN9QpE0A0R0SZ6g@mail.gmail.com>
Op 21 okt. 2011, om 17:40 heeft Khem Raj het volgende geschreven:
> On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>> ---
>> .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>> index 4ac2418..2f872b8 100644
>> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>> @@ -23,3 +23,4 @@ do_compile_prepend() {
>> cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
>> }
>>
>> +ARM_INSTRUCTION_SET = "arm"
>
> not averse to patch but it would be nice to know what fails in thumb mode.
And pulse is at 1.1 now, maybe upstream has fixed this issue.
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Khem Raj @ 2011-10-21 15:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <9e9f9e73e7bfa4a5184196b874cfb1dfe179be24.1319184832.git.Martin.Jansa@gmail.com>
On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> index 4ac2418..2f872b8 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> @@ -23,3 +23,4 @@ do_compile_prepend() {
> cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
> }
>
> +ARM_INSTRUCTION_SET = "arm"
not averse to patch but it would be nice to know what fails in thumb mode.
> --
> 1.7.7
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH 4/8] webkit-gtk: force arm mode to work around binutils segfault
From: Khem Raj @ 2011-10-21 15:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <9136b0cb351d0b7fee119739e669130906c1747a.1319184832.git.Martin.Jansa@gmail.com>
On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> meta/recipes-sato/webkit/webkit-gtk_svn.bb | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/meta/recipes-sato/webkit/webkit-gtk_svn.bb b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
> index 2862ad4..0a1f8b6 100644
> --- a/meta/recipes-sato/webkit/webkit-gtk_svn.bb
> +++ b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
> @@ -45,6 +45,23 @@ EXTRA_OECONF = "\
>
> EXTRA_AUTORECONF = " -I Source/autotools "
>
> +
> +#| ./Source/JavaScriptCore/heap/HandleTypes.h: In static member function 'static T* JSC::HandleTypes<T>::getFromSlot(JSC::HandleSlot) [with T = JSC::Structure, JSC::HandleTypes<T>::ExternalType = JSC::Structure*, JSC::HandleSlot = JSC::JSValue*]':
> +#| ./Source/JavaScriptCore/heap/Handle.h:141:79: instantiated from 'JSC::Handle<T>::ExternalType JSC::Handle<T>::get() const [with T = JSC::Structure, JSC::Handle<T>::ExternalType = JSC::Structure*]'
> +#| ./Source/JavaScriptCore/runtime/ScopeChain.h:39:75: instantiated from here
> +#| ./Source/JavaScriptCore/heap/HandleTypes.h:38:130: warning: cast from 'JSC::JSCell*' to 'JSC::HandleTypes<JSC::Structure>::ExternalType {aka JSC::Structure*}' increases required alignment of target type [-Wcast-align]
> +#| {standard input}: Assembler messages:
> +#| {standard input}:28873: Error: invalid immediate: 983040 is out of range
> +#| {standard input}:28873: Error: value of 983040 too large for field of 2 bytes at 15110
> +#| /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv4t-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.2/as: BFD (GNU Binutils) 2.21.1 assertion fail /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/binutils-cross-2.21.1a-r0/binutils-2.21.1/bfd/elf.c:2819
> +#| arm-oe-linux-gnueabi-g++: internal compiler error: Segmentation fault (program as)
What it seems is that tables are growing pretty large for thumb to
handle. Did you try to use -O1 or -Os with thumb mode ?
> +#| Please submit a full bug report,
> +#| with preprocessed source if appropriate.
> +#| See <http://gcc.gnu.org/bugs.html> for instructions.
> +#| make[1]: *** [Source/JavaScriptCore/jit/libjavascriptcoregtk_1_0_la-JIT.lo] Error 1
> +#| make[1]: Leaving directory `/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0'
> +ARM_INSTRUCTION_SET = "arm"
> +
> CONFIGUREOPT_DEPTRACK = ""
>
> do_configure_append() {
> --
> 1.7.7
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH 3/4] base-passwd: move initial criation of group and passwd to preinst
From: Mark Hatle @ 2011-10-21 14:52 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <908ef7747e3391af158b7edb9f2b420b0016a7af.1319206126.git.otavio@ossystems.com.br>
I've seen other distributions solve this doing this by creating the passwd/group
files based on the contents of the recipe and not some external file.
So you would have a list of users/groups that need to be created with their
attributes. In the do_install these items would be dumped into the
passwd/group.master file(s). But also in the preinst, it would check for the
existence of the files -- if they didn't exist yet.. it would simply write out
the passwd/group files at that point.
By embedding the data in the recipe, it keeps things in sync and resolves the
chicken/egg problem.
Any opinions from folks if this is even halfway reasonable for us to consider?
(I'm guessing with some anon python code we could probably load in the
passwd/group files, place them into a variable and use the variable to embed
them within the preinst -- keeping the contents out of the recipe.)
--Mark
On 10/21/11 9:10 AM, Otavio Salvador wrote:
> To allow use and manipulation of users and groups at rootfs building
> time, the '/etc/passwd' and '/etc/group' needs to be available as soon
> as possible.
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
> .../recipes-core/base-passwd/base-passwd_3.5.22.bb | 19 ++++++++++++++++++-
> 1 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb b/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
> index 137512d..aa90a6d 100644
> --- a/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
> +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb
> @@ -1,7 +1,7 @@
> SUMMARY = "Base system master password/group files."
> DESCRIPTION = "The master copies of the user database files (/etc/passwd and /etc/group). The update-passwd tool is also provided to keep the system databases synchronized with these master files."
> SECTION = "base"
> -PR = "r3"
> +PR = "r4"
> LICENSE = "GPLv2+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a"
>
> @@ -37,6 +37,23 @@ do_install () {
> install -p -m 644 debian/copyright ${D}${docdir}/${BPN}/
> }
>
> +pkg_preinst_${PN} () {
> + set -e
> +
> + # Used for rootfs generation. On in-target install this will be run
> + # before the unpack so the files won't be available
> +
> + if [ ! -e $D${sysconfdir}/passwd ] && [ -e $D${datadir}/base-passwd/passwd.master ]; then
> + cp $D${datadir}/base-passwd/passwd.master $D${sysconfdir}/passwd
> + fi
> +
> + if [ ! -e $D${sysconfdir}/group ] && [ -e $D${datadir}/base-passwd/group.master ]; then
> + cp $D${datadir}/base-passwd/group.master $D${sysconfdir}/group
> + fi
> +
> + exit 0
> +}
> +
> pkg_postinst_${PN} () {
> set -e
>
^ permalink raw reply
* Re: [PATCH 2/8] libatomics-ops: force ARM mode
From: Mark Hatle @ 2011-10-21 14:45 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <22ed6acc0a44d9bc0d6f7a2e800c039d77d75477.1319184832.git.Martin.Jansa@gmail.com>
On 10/21/11 3:17 AM, Martin Jansa wrote:
> * otherwise ie spitz (armv5te) build fails with:
> | make[3]: Entering directory `/OE/shr-core/tmp/work/armv5te-oe-linux-gnueabi/libatomics-ops-1.2-r5/libatomic_ops-1.2/src'
> | arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -mthumb-interwork -mtune=xscale --sysroot=/OE/shr-core/tmp/sysroots/spitz -DHAVE_CONFIG_H -I. -fPIC -O
> 2 -pipe -g -feliminate-unused-debug-types -DNDEBUG -c atomic_ops.c
> | arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -mthumb-interwork -mtune=xscale --sysroot=/OE/shr-core/tmp/sysroots/spitz -DHAVE_CONFIG_H -I. -fPIC -O
> 2 -pipe -g -feliminate-unused-debug-types -DNDEBUG -c atomic_ops_stack.c
> | arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -mthumb-interwork -mtune=xscale --sysroot=/OE/shr-core/tmp/sysroots/spitz -DHAVE_CONFIG_H -I. -fPIC -O
> 2 -pipe -g -feliminate-unused-debug-types -DNDEBUG -c atomic_ops_malloc.c
> | atomic_ops_malloc.c: In function 'msb':
> | atomic_ops_malloc.c:223:2: warning: right shift count >= width of type [enabled by default]
> | rm -f libatomic_ops_gpl.a
> | ar cru libatomic_ops_gpl.a atomic_ops_stack.o atomic_ops_malloc.o
> | arm-oe-linux-gnueabi-ranlib libatomic_ops_gpl.a
> | {standard input}: Assembler messages:
> | {standard input}:286: Error: selected processor does not support Thumb mode `swp r1,r2,[r3]'
> | {standard input}:329: Error: selected processor does not support Thumb mode `swp r0,r1,[r3]'
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> .../pulseaudio/libatomics-ops_1.2.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
> index 05b22e8..4d9ca0d 100644
> --- a/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
> +++ b/meta/recipes-multimedia/pulseaudio/libatomics-ops_1.2.bb
> @@ -20,4 +20,6 @@ S = "${WORKDIR}/libatomic_ops-${PV}"
>
> ALLOW_EMPTY_${PN} = "1"
>
> +ARM_INSTRUCTION_SET = "arm"
> +
> inherit autotools pkgconfig
Wouldn't it be better to fix libatomic-ops to have proper thumb mode assembly,
then fall back to non-thumb assembly?
I swear I had a patch to do this in the past, but I'm currently not able to find it.
--Mark
^ permalink raw reply
* [PATCH 4/4] dbus: use useradd class to allow use in read-only filesystems
From: Otavio Salvador @ 2011-10-21 14:10 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319206126.git.otavio@ossystems.com.br>
Move creation of required user/groups to useradd class thus allowing
use with read-only filesystems and booting the initial boot.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
meta/recipes-core/dbus/dbus.inc | 48 +++++++++++++++++----------------------
1 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index a8ecda8..2a97c02 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -10,15 +10,22 @@ DEPENDS = "expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', '${X
DEPENDS_virtclass-native = "expat-native virtual/libintl-native"
DEPENDS_virtclass-nativesdk = "expat-nativesdk virtual/libintl-nativesdk virtual/libx11"
+PR = "r1"
+
SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://tmpdir.patch; \
file://dbus-1.init"
-inherit autotools pkgconfig gettext update-rc.d
+inherit useradd autotools pkgconfig gettext update-rc.d
INITSCRIPT_NAME = "dbus-1"
INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
+USERADD_PACKAGES = "${PN}"
+GROUPADD_PARAM_${PN} = "-r netdev"
+USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
+ --no-create-home --user-group messagebus"
+
CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session.conf"
DEBIANNAME_${PN} = "dbus-1"
@@ -44,32 +51,7 @@ RRECOMMENDS_${PN}-lib = "${PN}"
FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool"
pkg_postinst_dbus() {
- # can't do adduser stuff offline
- if [ "x$D" != "x" ]; then
- exit 1
- fi
-
- MESSAGEUSER=messagebus
- MESSAGEHOME=/var/run/dbus
- UUIDDIR=/var/lib/dbus
-
- mkdir -p $MESSAGEHOME
- mkdir -p $UUIDDIR
- chgrp "$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || addgroup "$MESSAGEUSER"
- chown "$MESSAGEUSER":"$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || \
- adduser --system --home "$MESSAGEHOME" --no-create-home --disabled-password \
- --ingroup "$MESSAGEUSER" "$MESSAGEUSER"
-
- chown "$MESSAGEUSER":"$MESSAGEUSER" "$UUIDDIR"
-
- grep -q netdev: /etc/group || addgroup netdev
-
- chown root:"$MESSAGEUSER" /usr/libexec/dbus-daemon-launch-helper
- chmod 4754 /usr/libexec/dbus-daemon-launch-helper
-
- # add volatile after new user/grp are created
- echo "d messagebus messagebus 0755 /var/run/dbus none" > /etc/default/volatiles/99_dbus
- if [ -e /etc/init.d/populate-volatile.sh ] ; then
+ if [ -z "${D}" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
/etc/init.d/populate-volatile.sh update
fi
}
@@ -92,6 +74,18 @@ do_install() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1
+ install -d ${D}${sysconfdir}/default/volatiles
+ echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none" \
+ > ${D}${sysconfdir}/default/volatiles/99_dbus
+
+
+ mkdir -p ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus
+
+ chown messagebus:messagebus ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus
+
+ chown root:messagebus ${D}${libexecdir}/dbus-daemon-launch-helper
+ chmod 4754 ${D}${libexecdir}/dbus-daemon-launch-helper
+
# disable dbus-1 sysv script on systemd installs
# nearly all distros call the initscript plain 'dbus', but OE-core is different
ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
--
1.7.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox