* Re: [PATCH] Allow user mode NFS server to run without rpcbind / portmap
From: Richard Purdie @ 2011-10-10 9:14 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E927CD9.2040505@intel.com>
On Sun, 2011-10-09 at 22:04 -0700, Saul Wold wrote:
> On 10/05/2011 11:43 AM, Jason Wessel wrote:
> >> From the 2.6.39 linux kernel and up it is possible to use
> > and nfsroot mount without the need to talk to an RPC info
> > server as long as the port numbers for mountd and nfsd
> > are known in advance.
> >
> > This patch updates the qemu startup scripts and the
> > user mode NFS server to have the ability to start
> > without the need to use rpcbind or portmap services.
> >
> Jason,
>
> I have not fully tested this yet, but if someone has rpcbind and/or
> portmap services are running, what affect will this patch have?
It shouldn't have any effect, the system is just no longer requiring to
look up the port numbers through rpcbind/portmap but can use the values
directly.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH v3 0/2] Fix useradd class to accept useradd long options
From: Richard Purdie @ 2011-10-10 9:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: julian.pidancet
In-Reply-To: <cover.1317946258.git.julian.pidancet@gmail.com>
On Fri, 2011-10-07 at 01:13 +0100, Julian Pidancet wrote:
> This first patch fixes the --root option for programs in shadow-native and
> allow one to specify useradd long options when using the useradd class
> in a recipe.
>
> The second patch demonstrates usage of the useradd class and ability to
> specify long options in the USERADD_PARAM variable by converting the OpenSSH
> recipe to useradd.
>
> v2: Fixed a typo in add_root_cmd_options.patch, --root is equivalent to -Q
> instead of -R.
>
> v3: Comment modifications and add Signed-off-by line in the modified patch
> directly.
>
> Julian Pidancet (2):
> Fix the --root option in shadow-native programs
> Use useradd and update-rc.d classes in the OpenSSH recipe
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH v3 1/6] Fix mdadm for powerpc64
From: Richard Purdie @ 2011-10-10 9:08 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317852788-16690-1-git-send-email-msm@freescale.com>
On Wed, 2011-10-05 at 17:13 -0500, Matthew McClintock wrote:
> This takes an upstream fix for compiling on powerpc64
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> .../0001-mdadm-fix-build-failures-ppc64.patch | 50 ++++++++++++++++++++
> meta/recipes-extended/mdadm/mdadm_3.2.2.bb | 6 ++-
> 2 files changed, 54 insertions(+), 2 deletions(-)
> create mode 100644 meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH] shared-mime-info: Upgrade recipes from 0.90 -> 0.91
From: Richard Purdie @ 2011-10-10 9:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317843972-4213-1-git-send-email-raj.khem@gmail.com>
On Wed, 2011-10-05 at 12:46 -0700, Khem Raj wrote:
> The parallel build problems are solved upstream therefore removed
>
> License file has been corrected to use 'GNU Lesser GPL' instead of
> 'GNU library GPL' and some indentation changes
>
> The license is LGPLv2+ therefore mark it so
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH v2 5/6] Fix sysprof for powerpc64
From: Richard Purdie @ 2011-10-10 9:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317850009-7714-2-git-send-email-msm@freescale.com>
On Wed, 2011-10-05 at 16:26 -0500, Matthew McClintock wrote:
> __ppc64__ is not defined on powerpc64, rather __powerpc64__ is, this
> uses a patch that is already upstream to fix builds for powerpc64
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> ...PowerPC-checks-for-__NR_perf_counter_open.patch | 35 ++++++++++++++++++++
> meta/recipes-kernel/sysprof/sysprof_git.bb | 1 +
> 2 files changed, 36 insertions(+), 0 deletions(-)
> create mode 100644 meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH v2 5/6] Fix sysprof for powerpc64
From: Richard Purdie @ 2011-10-10 9:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317850009-7714-2-git-send-email-msm@freescale.com>
On Wed, 2011-10-05 at 16:26 -0500, Matthew McClintock wrote:
> __ppc64__ is not defined on powerpc64, rather __powerpc64__ is, this
> uses a patch that is already upstream to fix builds for powerpc64
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> ...PowerPC-checks-for-__NR_perf_counter_open.patch | 35 ++++++++++++++++++++
> meta/recipes-kernel/sysprof/sysprof_git.bb | 1 +
> 2 files changed, 36 insertions(+), 0 deletions(-)
> create mode 100644 meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [RFC][PATCH] linux-firmware: update, merge in OE classic updates, fix packaging
From: Koen Kooi @ 2011-10-10 7:27 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKoiKeOMs1bJLcmOQeSR4XDL8Wi_oa=a7jANS78Ouwx-Bw@mail.gmail.com>
Op 10 okt. 2011, om 03:03 heeft Otavio Salvador het volgende geschreven:
> On Sun, Oct 9, 2011 at 07:06, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Update: move to latest SRCREV, use non-kernel.org URI
>> Merge: wl12xx symlink + packaging, install all firmwares
>> Fix: * all entries in PACKAGES are in PROVIDES already
>> * A package always RPROVIDES itself
>> * A file can only get packaged *once* so only one rtlwifi package will get the license
>
> I dislike the idea of one single package with all firmwares. I prefer
> to have many small packages but one meta that depends on it.
I'm not going to make a patch to subpackage *all* the firmwares. If you can give me a list of the ones you use I'll make a patch to split those out.
regards,
Koen
^ permalink raw reply
* Re: [PATCH 3/3] oe.patch: drop bb.msg.domain reference
From: Samuel Stirtzel @ 2011-10-10 7:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <702d65b93492008812ac8778fc010f30e904383e.1318021323.git.kergoth@gmail.com>
Hi,
there was already a patch for this [1] (Yes I know, I should have
added more descriptions), according to the patch from Richard [2] the
message domain can be constructed dynamical now.
Since your patch seems a little bit different (dropping the message
domain completely) I can't tell if my resolution was inadequate.
For this patch I think it wouldn't make a big difference for the user,
feel free to apply the one that best suits in resolving the problem.
[1] http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/009474.html
[2] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a6c48298b17e6a5844b3638b422fe226e3b67b89
2011/10/7 Christopher Larson <kergoth@gmail.com>:
> Signed-off-by: Christopher Larson <kergoth@gmail.com>
> ---
> meta/lib/oe/patch.py | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
> index 1406e19..9b0ff37 100644
> --- a/meta/lib/oe/patch.py
> +++ b/meta/lib/oe/patch.py
> @@ -376,8 +376,8 @@ class UserResolver(Resolver):
> os.environ['SHELLCMDS'] = "bash --rcfile " + rcfile
> rc = os.system(bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
> if os.WIFEXITED(rc) and os.WEXITSTATUS(rc) != 0:
> - bb.msg.fatal(bb.msg.domain.Build, ("Cannot proceed with manual patch resolution - '%s' not found. " \
> - + "Check TERMCMDRUN variable.") % bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
> + bb.fatal(("Cannot proceed with manual patch resolution - '%s' not found. "
> + + "Check TERMCMDRUN variable.") % bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
>
> # Construct a new PatchSet after the user's changes, compare the
> # sets, checking patches for modifications, and doing a remote
> --
> 1.7.4.1
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
--
Regards
Samuel
^ permalink raw reply
* Re: [PATCH] Allow user mode NFS server to run without rpcbind / portmap
From: Saul Wold @ 2011-10-10 5:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317840239-5290-1-git-send-email-jason.wessel@windriver.com>
On 10/05/2011 11:43 AM, Jason Wessel wrote:
>> From the 2.6.39 linux kernel and up it is possible to use
> and nfsroot mount without the need to talk to an RPC info
> server as long as the port numbers for mountd and nfsd
> are known in advance.
>
> This patch updates the qemu startup scripts and the
> user mode NFS server to have the ability to start
> without the need to use rpcbind or portmap services.
>
Jason,
I have not fully tested this yet, but if someone has rpcbind and/or
portmap services are running, what affect will this patch have?
Sau!
> Signed-off-by: Jason Wessel<jason.wessel@windriver.com>
> ---
> .../023-no-rpc-register.patch | 34 ++++++++++++++++++++
> .../unfs-server/unfs-server_2.1+2.2beta47.bb | 3 +-
> scripts/runqemu-export-rootfs | 4 ++-
> scripts/runqemu-internal | 16 +++------
> 4 files changed, 44 insertions(+), 13 deletions(-)
> create mode 100644 meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch
>
> diff --git a/meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch b/meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch
> new file mode 100644
> index 0000000..50f23fc
> --- /dev/null
> +++ b/meta/recipes-devtools/unfs-server/unfs-server-2.1+2.2beta47/023-no-rpc-register.patch
> @@ -0,0 +1,34 @@
> +Upstream-Status: Inappropriate [other]
> +Upstream is not making further releases of this software.
> +
> +Signed-off-by: Jason Wessel<jason.wessel@windriver.com>
> +
> +# Allow user mode NFS to work without rpcbind / portmap
> +# Patch origin: Wind River
> +
> +---
> + rpcmisc.c | 6 ++++--
> + 1 file changed, 4 insertions(+), 2 deletions(-)
> +
> +--- a/rpcmisc.c
> ++++ b/rpcmisc.c
> +@@ -91,7 +91,8 @@ not_inetd:
> + if (transp == NULL)
> + Dprintf(L_FATAL, "cannot create udp service.");
> + for (i = 0; (vers = verstbl[i]) != 0; i++) {
> +- if (!svc_register(transp, prog, vers, dispatch, IPPROTO_UDP)) {
> ++ if (!(svc_register(transp, prog, vers, dispatch, IPPROTO_UDP) ||
> ++ svc_register(transp, prog, vers, dispatch, 0))) {
> + Dprintf(L_FATAL,
> + "unable to register (%s, %d, udp).",
> + name, vers);
> +@@ -110,7 +111,8 @@ not_inetd:
> + transp->xp_ops->xp_recv = auth_rendevouser;
> + #endif
> + for (i = 0; (vers = verstbl[i]) != 0; i++) {
> +- if (!svc_register(transp, prog, vers, dispatch, IPPROTO_TCP)) {
> ++ if (!(svc_register(transp, prog, vers, dispatch, IPPROTO_TCP) ||
> ++ svc_register(transp, prog, vers, dispatch, 0))) {
> + Dprintf(L_FATAL,
> + "unable to register (%s, %d, tcp).",
> + name, vers);
> diff --git a/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb b/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb
> index 8ed2e33..29c7052 100644
> --- a/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb
> +++ b/meta/recipes-devtools/unfs-server/unfs-server_2.1+2.2beta47.bb
> @@ -7,7 +7,7 @@ RDEPENDS_${PN} = "pseudo"
> RDEPENDS_${PN}_virtclass-native = "pseudo-native"
> RDEPENDS_${PN}_virtclass-nativesdk = "pseudo-nativesdk"
> BASEPV = "2.2beta47"
> -PR = "r0"
> +PR = "r1"
>
> SRC_URI = "ftp://linux.mathematik.tu-darmstadt.de/pub/linux/oldstuff/people/okir/nfs-server-${BASEPV}.tar.gz \
> file://001-2.2b47-2.2b51.patch \
> @@ -32,6 +32,7 @@ SRC_URI = "ftp://linux.mathematik.tu-darmstadt.de/pub/linux/oldstuff/people/okir
> file://020-undefined-chmod-fix.patch \
> file://021-nolibwrap.patch \
> file://022-add-close-on-exec-descriptors.patch \
> + file://023-no-rpc-register.patch \
> "
>
> SRC_URI[md5sum] = "79a29fe9f79b2f3241d4915767b8c511"
> diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
> index 3ee3112..5cb4bf2 100755
> --- a/scripts/runqemu-export-rootfs
> +++ b/scripts/runqemu-export-rootfs
> @@ -83,10 +83,12 @@ NFS_MOUNTPROG=$[ 21111 + $NFS_INSTANCE ]
> NFS_NFSPROG=$[ 11111 + $NFS_INSTANCE ]
> # NFS port number
> NFS_PORT=$[ 3049 + $NFS_INSTANCE ]
> +# mountd port number
> +MOUNT_PORT=$[ 3048 + $NFS_INSTANCE ]
>
> ## For debugging you would additionally add
> ## --debug all
> -MOUNTD_OPTS="--allow-non-root --mount-pid $MOUNTPID -f $EXPORTS --rmtab $RMTAB --prog $NFS_MOUNTPROG -r"
> +MOUNTD_OPTS="--allow-non-root --mount-pid $MOUNTPID -f $EXPORTS --rmtab $RMTAB --prog $NFS_MOUNTPROG -r -P $MOUNT_PORT"
> NFSD_OPTS="--allow-non-root --nfs-pid $NFSPID -f $EXPORTS --prog $NFS_NFSPROG -P $NFS_PORT -r"
>
> # Setup the exports file
> diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
> index ce3291f..2968ed9 100755
> --- a/scripts/runqemu-internal
> +++ b/scripts/runqemu-internal
> @@ -258,21 +258,15 @@ fi
> if [ "$FSTYPE" = "nfs" ]; then
> NFS_SERVER="192.168.7.1"
> NFS_DIR=`echo $ROOTFS | sed 's/^[^:]*:\(.*\)/\1/'`
> - MOUNTD_PORT=$[ 21111 + $NFS_INSTANCE ]
> - NFSD_PORT=$[ 11111 + $NFS_INSTANCE ]
> - UNFS_OPTS="nfsvers=2,mountprog=$MOUNTD_PORT,nfsprog=$NFSD_PORT,udp"
> + MOUNTD_RPCPORT=$[ 21111 + $NFS_INSTANCE ]
> + NFSD_RPCPORT=$[ 11111 + $NFS_INSTANCE ]
> + NFSD_PORT=$[ 3049 + $NFS_INSTANCE ]
> + MOUNTD_PORT=$[ 3048 + $NFS_INSTANCE ]
> + UNFS_OPTS="nfsvers=2,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,port=$NFSD_PORT,mountport=$MOUNTD_PORT"
>
> PSEUDO_LOCALSTATEDIR=~/.runqemu-sdk/pseudo
> export PSEUDO_LOCALSTATEDIR
>
> - rpcbind_running=`ps ax | grep rpcbind | grep -v grep | wc -l`
> - portmap_running=`ps ax | grep portmap | grep -v grep | wc -l`
> - if [[ $rpcbind_running == 0&& $portmap_running == 0 ]]; then
> - echo "You need to be running either rpcbind or portmap to continue"
> - cleanup
> - return
> - fi
> -
> # Start the userspace NFS server
> echo "runqemu-export-rootfs restart $ROOTFS"
> runqemu-export-rootfs restart $ROOTFS
^ permalink raw reply
* Re: [PATCH 0/1] QEMU 0.15 update please test
From: Saul Wold @ 2011-10-10 4:59 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1317843784.git.raj.khem@gmail.com>
On 10/05/2011 12:45 PM, Khem Raj wrote:
> This brings in qemu-0.15 into OE-core I have had limited testing
> on it and mainly on qemuarm. Please help testing it on other architectures
> I will also work on getting it more solidified and bring some backports
> as needed.
>
Khem,
Did you do any kind of non-native build, I know it may not make sense,
but we can support qemu within the target image with 0.14.
My initial testing on the autobuilder seems to imply some dependency on
glib-2.0.
Thanks
Sau!
> The following changes since commit abde9f65b1617ec61e964c4b3502fd4ad2215dcf:
>
> shared-mime-info: Upgrade recipes from 0.90 -> 0.91 (2011-10-05 12:39:47 -0700)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib kraj/qemu-update
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/qemu-update
>
> Khem Raj (1):
> qemu-0.15: Add recipe and forward port patches from 0.14
>
> .../qemu/qemu-0.15.0/arm-bgr.patch | 30 +
> .../qemu/qemu-0.15.0/enable-i386-linux-user.patch | 55 +
> .../fallback-to-safe-mmap_min_addr.patch | 39 +
> .../qemu/qemu-0.15.0/fix-configure-checks.patch | 22 +
> .../qemu/qemu-0.15.0/fix-nogl.patch | 127 +
> .../qemu/qemu-0.15.0/glflags.patch | 15 +
> .../qemu/qemu-0.15.0/init-info.patch | 18 +
> .../qemu/qemu-0.15.0/larger_default_ram_size.patch | 22 +
> .../qemu/qemu-0.15.0/linker-flags.patch | 25 +
> .../qemu/qemu-0.15.0/no-strip.patch | 15 +
> .../qemu/qemu-0.15.0/opengl-sdl-fix.patch | 43 +
> .../qemu/qemu-0.15.0/powerpc_rom.bin | Bin 0 -> 4096 bytes
> .../qemu/qemu-0.15.0/qemu-git-qemugl-host.patch |34368 ++++++++++++++++++++
> .../qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch | 118 +
> .../qemugl-allow-glxcontext-release.patch | 65 +
> .../qemu/qemu-0.15.0/qemugl-fix.patch | 74 +
> meta/recipes-devtools/qemu/qemu_0.15.0.bb | 45 +
> 17 files changed, 35081 insertions(+), 0 deletions(-)
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/arm-bgr.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/enable-i386-linux-user.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/fallback-to-safe-mmap_min_addr.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/fix-configure-checks.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/fix-nogl.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/glflags.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/init-info.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/larger_default_ram_size.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/linker-flags.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/no-strip.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/opengl-sdl-fix.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/powerpc_rom.bin
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/qemu-git-qemugl-host.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-allow-glxcontext-release.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-fix.patch
> create mode 100644 meta/recipes-devtools/qemu/qemu_0.15.0.bb
>
^ permalink raw reply
* Re: [RFC][PATCH] linux-firmware: update, merge in OE classic updates, fix packaging
From: Otavio Salvador @ 2011-10-10 1:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <1318154801-28945-1-git-send-email-koen@dominion.thruhere.net>
On Sun, Oct 9, 2011 at 07:06, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Update: move to latest SRCREV, use non-kernel.org URI
> Merge: wl12xx symlink + packaging, install all firmwares
> Fix: * all entries in PACKAGES are in PROVIDES already
> * A package always RPROVIDES itself
> * A file can only get packaged *once* so only one rtlwifi package will get the license
I dislike the idea of one single package with all firmwares. I prefer
to have many small packages but one meta that depends on 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] alsa-utils 0.10.24.2: fix systemd units when there's no asound.state
From: Koen Kooi @ 2011-10-09 19:12 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318184003-19108-1-git-send-email-koen@dominion.thruhere.net>
Op 9 okt. 2011, om 20:13 heeft Koen Kooi het volgende geschreven:
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
> ...-t-let-systemd-unit-restore-the-volume-wh.patch | 44 ++++++++++++++++++++
> .../recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb | 3 +-
> 2 files changed, 46 insertions(+), 1 deletions(-)
> create mode 100644 meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
>
> diff --git a/meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch b/meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
> new file mode 100644
> index 0000000..3b5d969
> --- /dev/null
> +++ b/meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
> @@ -0,0 +1,44 @@
> +From 37c99a3cbff36915b56a5703eeaed3c70796f80f Mon Sep 17 00:00:00 2001
> +From: Koen Kooi <koen@dominion.thruhere.net>
> +Date: Sun, 9 Oct 2011 20:06:35 +0200
> +Subject: [PATCH] alsactl: don't let systemd unit restore the volume when asound.state is missing
> +
> +This avoids an error on bootup
> +
> +Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> +---
> +
> +Upstream-status: Pending
Filed as https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5459
^ permalink raw reply
* Re: [yocto] MACHINE_EXTRA_* and MACHINE_ESSENTIAL_* documentation
From: Koen Kooi @ 2011-10-09 18:26 UTC (permalink / raw)
To: Richard Purdie, Patches and discussions about the oe-core layer
Cc: Darren Hart, Paul Eggleton, Wold, Saul, Yocto Project
In-Reply-To: <1317146705.26109.215.camel@ted>
Op 27 sep. 2011, om 20:04 heeft Richard Purdie het volgende geschreven:
[..]
> So if you change MACHINE_EXTRA* you need to rebuild task-base, if you
> change MACHINE_ESSENTIAL_EXTRA* you need to rebuild task-core-boot.
> Confusing and the checksum code we'll enable soon should make this
> automatic.
>
> The task-core-boot is included into task-base by task-distro-base
> through DISTRO_EXTRA_RDEPENDS which in meta-yocto is set to
> task-core-boot. Both sets of variables should therefore appear in most
> images except minimal and basic which should only get the essential
> ones.
>
> I hope that at least clarifies what should happen...
To combat the confusion I did it slightly different in task-basic:
https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-core/tasks/task-basic.bb
Any var besides *_FEATURES you can poke is prefixed with TASK_BASIC:
TASK_BASIC_SSHDAEMON
I would propose that if the EXTRA and ESSENTIAL stuff is only used a single recipe that they should be prefixed to give people a better chance at finding out what it impacts.
Right now you'd need to call it BUMP_PR_OF_TASK_CORE_RECIPE_IF_YOU_CHANGE_ME_MACHINE_ESSENTIAL_*, but that's a different discussion :)
regards,
Koen
^ permalink raw reply
* [PATCH] alsa-utils 0.10.24.2: fix systemd units when there's no asound.state
From: Koen Kooi @ 2011-10-09 18:13 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
...-t-let-systemd-unit-restore-the-volume-wh.patch | 44 ++++++++++++++++++++
.../recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb | 3 +-
2 files changed, 46 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
diff --git a/meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch b/meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
new file mode 100644
index 0000000..3b5d969
--- /dev/null
+++ b/meta/recipes-multimedia/alsa/alsa-utils-1.0.24.2/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
@@ -0,0 +1,44 @@
+From 37c99a3cbff36915b56a5703eeaed3c70796f80f Mon Sep 17 00:00:00 2001
+From: Koen Kooi <koen@dominion.thruhere.net>
+Date: Sun, 9 Oct 2011 20:06:35 +0200
+Subject: [PATCH] alsactl: don't let systemd unit restore the volume when asound.state is missing
+
+This avoids an error on bootup
+
+Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
+---
+
+Upstream-status: Pending
+
+ alsactl/Makefile.am | 2 +-
+ alsactl/alsa-restore.service.in | 1 +
+ 2 files changed, 2 insertions(+), 1 deletions(-)
+
+diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am
+index 5cfc415..c3768c4 100644
+--- a/alsactl/Makefile.am
++++ b/alsactl/Makefile.am
+@@ -34,7 +34,7 @@ install-data-hook:
+ endif
+
+ edit = \
+- sed $(SED) -r 's,@sbindir\@,$(sbindir),g' < $< > $@ || rm $@
++ sed $(SED) -e 's,@localstatedir\@,$(localstatedir),g' -e 's,@sbindir\@,$(sbindir),g' < $< > $@ || rm $@
+
+ alsa-store.service: alsa-store.service.in
+ $(edit)
+diff --git a/alsactl/alsa-restore.service.in b/alsactl/alsa-restore.service.in
+index e97d196..3b76710 100644
+--- a/alsactl/alsa-restore.service.in
++++ b/alsactl/alsa-restore.service.in
+@@ -4,6 +4,7 @@ DefaultDependencies=no
+ After=sysinit.target
+ Before=shutdown.target
+ Conflicts=shutdown.target
++ConditionPathExists=@localstatedir@/lib/alsa/asound.state
+
+ [Service]
+ Type=oneshot
+--
+1.6.6.1
+
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb b/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
index 1b3ffe1..9eee60a 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.0.24.2.bb
@@ -6,11 +6,12 @@ LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \
file://alsactl/utils.c;beginline=1;endline=20;md5=fe9526b055e246b5558809a5ae25c0b9"
DEPENDS = "alsa-lib ncurses"
-PR = "r2"
+PR = "r3"
SRC_URI = "ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \
file://ncursesfix.patch \
file://uclibc-exp10-replacement.patch \
+ file://0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch \
"
SRC_URI[md5sum] = "8238cd57cb301d1c36bcf0ecb59ce6b2"
--
1.6.6.1
^ permalink raw reply related
* Re: sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
From: Koen Kooi @ 2011-10-09 18:11 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111009181016.GB3847@jama.jama.net>
Op 9 okt. 2011, om 20:10 heeft Martin Jansa het volgende geschreven:
> On Sun, Oct 09, 2011 at 01:25:09PM +0200, Koen Kooi wrote:
>>
>> Op 6 okt. 2011, om 16:19 heeft Richard Purdie het volgende geschreven:
>>
>>> sstate was being a little too ethusiastic about removing stamp files and
>>> was removing stamp files for other machines when it shouldn't have been.
>>>
>>> This patch teaches sstate about machine specific stamp extensions and
>>> allows it to only remove the current task's stampfiles.
>>
>> Not sure if it's related to this problem or not but sstate is still not working as intented for me when switching machines, it keeps rebuilding the toolchain when switching machine. What I did this morning:
>>
>> 1) wipe out tmp, sstate-cache, pseudodone
>> 2) MACHINE=beagleboard bitbake u-boot
>> 3) cp conf/machine/beagleboard.conf conf/machine/brokensstate.conf
>> 4) MACHINE=brokensstate bitbake u-boot
>
> Same here.. :/ (building 3 armv7 machines.. always "from scratch").
To eliminate varables: Angstrom/shr/aurora/micro/other/all of the above?
>
>> And behold:
>>
>> NOTE: Resolving any missing task queue dependencies
>> NOTE: Preparing runqueue
>> NOTE: Executing SetScene Tasks
>> NOTE: package gcc-cross-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
>> NOTE: package mtd-utils-1.4.6-r0: task do_populate_sysroot_setscene: Started
>> NOTE: package gcc-runtime-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
>> NOTE: package eglibc-2.12-r27: task do_populate_sysroot_setscene: Started
>> NOTE: package mtd-utils-1.4.6-r0: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package bash-4.1-r2: task do_populate_sysroot_setscene: Started
>> NOTE: package bash-4.1-r2: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package gcc-cross-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package binutils-cross-2.20.1-r7: task do_populate_sysroot_setscene: Started
>> NOTE: package linux-libc-headers-2.6.39-r2: task do_populate_sysroot_setscene: Started
>> NOTE: package eglibc-2.12-r27: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package binutils-cross-2.20.1-r7: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package linux-libc-headers-2.6.39-r2: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package libgcc-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
>> NOTE: package gcc-runtime-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package gcc-cross-intermediate-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
>> NOTE: package zlib-1.2.5-r0: task do_populate_sysroot_setscene: Started
>> NOTE: package libgcc-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package lzo-2.05-r0: task do_populate_sysroot_setscene: Started
>> NOTE: package zlib-1.2.5-r0: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package e2fsprogs-1.41.14-r2: task do_populate_sysroot_setscene: Started
>> NOTE: package util-linux-2.19.1-r7: task do_populate_sysroot_setscene: Started
>> NOTE: package lzo-2.05-r0: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package e2fsprogs-1.41.14-r2: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package libtool-cross-2.4-r4: task do_populate_sysroot_setscene: Started
>> NOTE: package gettext-0.18.1.1-r4: task do_populate_sysroot_setscene: Started
>> NOTE: package libtool-cross-2.4-r4: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package util-linux-2.19.1-r7: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package gcc-cross-intermediate-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package ncurses-5.9-r1.1: task do_populate_sysroot_setscene: Started
>> NOTE: package perl-5.12.3-r5: task do_populate_sysroot_setscene: Started
>> NOTE: package eglibc-initial-2.12-r27: task do_populate_sysroot_setscene: Started
>> NOTE: package eglibc-initial-2.12-r27: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package ncurses-5.9-r1.1: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package db-5.1.19-r3: task do_populate_sysroot_setscene: Started
>> NOTE: package expat-2.0.1-r0: task do_populate_sysroot_setscene: Started
>> NOTE: package expat-2.0.1-r0: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package perl-5.12.3-r5: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package gettext-0.18.1.1-r4: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package gdbm-1.8.3-r4: task do_populate_sysroot_setscene: Started
>> NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
>> NOTE: package gdbm-1.8.3-r4: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package db-5.1.19-r3: task do_populate_sysroot_setscene: Succeeded
>> NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
>> NOTE: Executing RunQueue Tasks
>> NOTE: Running task 536 of 920 (ID: 918, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb, do_populate_lic)
>> NOTE: Running task 549 of 920 (ID: 452, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/binutils/binutils-cross_2.20.1.bb, do_fetch)
>> NOTE: Running task 553 of 920 (ID: 504, /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb, do_fetch)
>> NOTE: Running task 558 of 920 (ID: 538, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-intermediate_4.5.bb, do_populate_lic)
>> NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_lic: Started
>> NOTE: package binutils-cross-2.20.1-r7: task do_fetch: Started
>> [..]
>> NOTE: package eglibc-2.12-r27: task do_compile: Started
>>
>>
>> What I suspect is happing is that angstrom is somehow putting $MACHINE in a var that upsets the sstate logic and/or rm_work upsets sstate and/or something else is broken. The problem is that I have no idea how to debug this except to ping Richard and get the magic diffsigs incantation.
>>
>> regards,
>>
>> Koen
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> --
> 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: sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
From: Martin Jansa @ 2011-10-09 18:10 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <37FC7DDC-D175-45B4-AF8A-F4D5AF384750@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 6216 bytes --]
On Sun, Oct 09, 2011 at 01:25:09PM +0200, Koen Kooi wrote:
>
> Op 6 okt. 2011, om 16:19 heeft Richard Purdie het volgende geschreven:
>
> > sstate was being a little too ethusiastic about removing stamp files and
> > was removing stamp files for other machines when it shouldn't have been.
> >
> > This patch teaches sstate about machine specific stamp extensions and
> > allows it to only remove the current task's stampfiles.
>
> Not sure if it's related to this problem or not but sstate is still not working as intented for me when switching machines, it keeps rebuilding the toolchain when switching machine. What I did this morning:
>
> 1) wipe out tmp, sstate-cache, pseudodone
> 2) MACHINE=beagleboard bitbake u-boot
> 3) cp conf/machine/beagleboard.conf conf/machine/brokensstate.conf
> 4) MACHINE=brokensstate bitbake u-boot
Same here.. :/ (building 3 armv7 machines.. always "from scratch").
> And behold:
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: package gcc-cross-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
> NOTE: package mtd-utils-1.4.6-r0: task do_populate_sysroot_setscene: Started
> NOTE: package gcc-runtime-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
> NOTE: package eglibc-2.12-r27: task do_populate_sysroot_setscene: Started
> NOTE: package mtd-utils-1.4.6-r0: task do_populate_sysroot_setscene: Succeeded
> NOTE: package bash-4.1-r2: task do_populate_sysroot_setscene: Started
> NOTE: package bash-4.1-r2: task do_populate_sysroot_setscene: Succeeded
> NOTE: package gcc-cross-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
> NOTE: package binutils-cross-2.20.1-r7: task do_populate_sysroot_setscene: Started
> NOTE: package linux-libc-headers-2.6.39-r2: task do_populate_sysroot_setscene: Started
> NOTE: package eglibc-2.12-r27: task do_populate_sysroot_setscene: Succeeded
> NOTE: package binutils-cross-2.20.1-r7: task do_populate_sysroot_setscene: Succeeded
> NOTE: package linux-libc-headers-2.6.39-r2: task do_populate_sysroot_setscene: Succeeded
> NOTE: package libgcc-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
> NOTE: package gcc-runtime-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
> NOTE: package gcc-cross-intermediate-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
> NOTE: package zlib-1.2.5-r0: task do_populate_sysroot_setscene: Started
> NOTE: package libgcc-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
> NOTE: package lzo-2.05-r0: task do_populate_sysroot_setscene: Started
> NOTE: package zlib-1.2.5-r0: task do_populate_sysroot_setscene: Succeeded
> NOTE: package e2fsprogs-1.41.14-r2: task do_populate_sysroot_setscene: Started
> NOTE: package util-linux-2.19.1-r7: task do_populate_sysroot_setscene: Started
> NOTE: package lzo-2.05-r0: task do_populate_sysroot_setscene: Succeeded
> NOTE: package e2fsprogs-1.41.14-r2: task do_populate_sysroot_setscene: Succeeded
> NOTE: package libtool-cross-2.4-r4: task do_populate_sysroot_setscene: Started
> NOTE: package gettext-0.18.1.1-r4: task do_populate_sysroot_setscene: Started
> NOTE: package libtool-cross-2.4-r4: task do_populate_sysroot_setscene: Succeeded
> NOTE: package util-linux-2.19.1-r7: task do_populate_sysroot_setscene: Succeeded
> NOTE: package gcc-cross-intermediate-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
> NOTE: package ncurses-5.9-r1.1: task do_populate_sysroot_setscene: Started
> NOTE: package perl-5.12.3-r5: task do_populate_sysroot_setscene: Started
> NOTE: package eglibc-initial-2.12-r27: task do_populate_sysroot_setscene: Started
> NOTE: package eglibc-initial-2.12-r27: task do_populate_sysroot_setscene: Succeeded
> NOTE: package ncurses-5.9-r1.1: task do_populate_sysroot_setscene: Succeeded
> NOTE: package db-5.1.19-r3: task do_populate_sysroot_setscene: Started
> NOTE: package expat-2.0.1-r0: task do_populate_sysroot_setscene: Started
> NOTE: package expat-2.0.1-r0: task do_populate_sysroot_setscene: Succeeded
> NOTE: package perl-5.12.3-r5: task do_populate_sysroot_setscene: Succeeded
> NOTE: package gettext-0.18.1.1-r4: task do_populate_sysroot_setscene: Succeeded
> NOTE: package gdbm-1.8.3-r4: task do_populate_sysroot_setscene: Started
> NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
> NOTE: package gdbm-1.8.3-r4: task do_populate_sysroot_setscene: Succeeded
> NOTE: package db-5.1.19-r3: task do_populate_sysroot_setscene: Succeeded
> NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 536 of 920 (ID: 918, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb, do_populate_lic)
> NOTE: Running task 549 of 920 (ID: 452, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/binutils/binutils-cross_2.20.1.bb, do_fetch)
> NOTE: Running task 553 of 920 (ID: 504, /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb, do_fetch)
> NOTE: Running task 558 of 920 (ID: 538, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-intermediate_4.5.bb, do_populate_lic)
> NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_lic: Started
> NOTE: package binutils-cross-2.20.1-r7: task do_fetch: Started
> [..]
> NOTE: package eglibc-2.12-r27: task do_compile: Started
>
>
> What I suspect is happing is that angstrom is somehow putting $MACHINE in a var that upsets the sstate logic and/or rm_work upsets sstate and/or something else is broken. The problem is that I have no idea how to debug this except to ping Richard and get the magic diffsigs incantation.
>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* shared-mime-info fails to build if intltool-native is present
From: Koen Kooi @ 2011-10-09 14:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi,
I finally tracked down the cause of the intermittent shared-mime-info build failures I was seeing. No patch yet, but now you all know what's causing it :)
regards,
Koen
^ permalink raw reply
* Re: binutils from meta-oe does build build
From: Philip Balister @ 2011-10-09 13:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soz1FCyCZwA2Oe14q2e=RrxVZmJ3iVjQ=-P+fUghRYP3g@mail.gmail.com>
On 10/08/2011 09:01 PM, Khem Raj wrote:
> On Sat, Oct 8, 2011 at 9:08 AM, Philip Balister <philip@balister.org> wrote:
>> http://pastebin.com/M0Gw0Db2
>>
>> Basically, warnings are being treated as errors and the compile fails.
>
> you might add --disable-werror to EXTRA_OECONF
> in meta-oe/recipes-devtools/binutils/binutils.inc
That worked. There are a number of CFLAGS in the .inc file and it is was
not obvious the proper place to insert Martin's suggestion.
I'll submit a patch later. RL intrudes.
Philip
>
>>
>> Philip
>>
>> _______________________________________________
>> 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
>
^ permalink raw reply
* Re: sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
From: Koen Kooi @ 2011-10-09 11:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317910796.6398.86.camel@ted>
Op 6 okt. 2011, om 16:19 heeft Richard Purdie het volgende geschreven:
> sstate was being a little too ethusiastic about removing stamp files and
> was removing stamp files for other machines when it shouldn't have been.
>
> This patch teaches sstate about machine specific stamp extensions and
> allows it to only remove the current task's stampfiles.
Not sure if it's related to this problem or not but sstate is still not working as intented for me when switching machines, it keeps rebuilding the toolchain when switching machine. What I did this morning:
1) wipe out tmp, sstate-cache, pseudodone
2) MACHINE=beagleboard bitbake u-boot
3) cp conf/machine/beagleboard.conf conf/machine/brokensstate.conf
4) MACHINE=brokensstate bitbake u-boot
And behold:
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: package gcc-cross-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
NOTE: package mtd-utils-1.4.6-r0: task do_populate_sysroot_setscene: Started
NOTE: package gcc-runtime-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
NOTE: package eglibc-2.12-r27: task do_populate_sysroot_setscene: Started
NOTE: package mtd-utils-1.4.6-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: package bash-4.1-r2: task do_populate_sysroot_setscene: Started
NOTE: package bash-4.1-r2: task do_populate_sysroot_setscene: Succeeded
NOTE: package gcc-cross-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
NOTE: package binutils-cross-2.20.1-r7: task do_populate_sysroot_setscene: Started
NOTE: package linux-libc-headers-2.6.39-r2: task do_populate_sysroot_setscene: Started
NOTE: package eglibc-2.12-r27: task do_populate_sysroot_setscene: Succeeded
NOTE: package binutils-cross-2.20.1-r7: task do_populate_sysroot_setscene: Succeeded
NOTE: package linux-libc-headers-2.6.39-r2: task do_populate_sysroot_setscene: Succeeded
NOTE: package libgcc-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
NOTE: package gcc-runtime-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
NOTE: package gcc-cross-intermediate-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
NOTE: package zlib-1.2.5-r0: task do_populate_sysroot_setscene: Started
NOTE: package libgcc-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
NOTE: package lzo-2.05-r0: task do_populate_sysroot_setscene: Started
NOTE: package zlib-1.2.5-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: package e2fsprogs-1.41.14-r2: task do_populate_sysroot_setscene: Started
NOTE: package util-linux-2.19.1-r7: task do_populate_sysroot_setscene: Started
NOTE: package lzo-2.05-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: package e2fsprogs-1.41.14-r2: task do_populate_sysroot_setscene: Succeeded
NOTE: package libtool-cross-2.4-r4: task do_populate_sysroot_setscene: Started
NOTE: package gettext-0.18.1.1-r4: task do_populate_sysroot_setscene: Started
NOTE: package libtool-cross-2.4-r4: task do_populate_sysroot_setscene: Succeeded
NOTE: package util-linux-2.19.1-r7: task do_populate_sysroot_setscene: Succeeded
NOTE: package gcc-cross-intermediate-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
NOTE: package ncurses-5.9-r1.1: task do_populate_sysroot_setscene: Started
NOTE: package perl-5.12.3-r5: task do_populate_sysroot_setscene: Started
NOTE: package eglibc-initial-2.12-r27: task do_populate_sysroot_setscene: Started
NOTE: package eglibc-initial-2.12-r27: task do_populate_sysroot_setscene: Succeeded
NOTE: package ncurses-5.9-r1.1: task do_populate_sysroot_setscene: Succeeded
NOTE: package db-5.1.19-r3: task do_populate_sysroot_setscene: Started
NOTE: package expat-2.0.1-r0: task do_populate_sysroot_setscene: Started
NOTE: package expat-2.0.1-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: package perl-5.12.3-r5: task do_populate_sysroot_setscene: Succeeded
NOTE: package gettext-0.18.1.1-r4: task do_populate_sysroot_setscene: Succeeded
NOTE: package gdbm-1.8.3-r4: task do_populate_sysroot_setscene: Started
NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Started
NOTE: package gdbm-1.8.3-r4: task do_populate_sysroot_setscene: Succeeded
NOTE: package db-5.1.19-r3: task do_populate_sysroot_setscene: Succeeded
NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_sysroot_setscene: Succeeded
NOTE: Executing RunQueue Tasks
NOTE: Running task 536 of 920 (ID: 918, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb, do_populate_lic)
NOTE: Running task 549 of 920 (ID: 452, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/binutils/binutils-cross_2.20.1.bb, do_fetch)
NOTE: Running task 553 of 920 (ID: 504, /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.39.bb, do_fetch)
NOTE: Running task 558 of 920 (ID: 538, /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-intermediate_4.5.bb, do_populate_lic)
NOTE: package gcc-cross-initial-4.5-r43+svnr178923: task do_populate_lic: Started
NOTE: package binutils-cross-2.20.1-r7: task do_fetch: Started
[..]
NOTE: package eglibc-2.12-r27: task do_compile: Started
What I suspect is happing is that angstrom is somehow putting $MACHINE in a var that upsets the sstate logic and/or rm_work upsets sstate and/or something else is broken. The problem is that I have no idea how to debug this except to ping Richard and get the magic diffsigs incantation.
regards,
Koen
^ permalink raw reply
* [RFC][PATCH] linux-firmware: update, merge in OE classic updates, fix packaging
From: Koen Kooi @ 2011-10-09 10:06 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Update: move to latest SRCREV, use non-kernel.org URI
Merge: wl12xx symlink + packaging, install all firmwares
Fix: * all entries in PACKAGES are in PROVIDES already
* A package always RPROVIDES itself
* A file can only get packaged *once* so only one rtlwifi package will get the license
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
Both this and the OE classic version give the me "there must be another way" feeling. Anyway, this patch gives me what I want, namely the wilink files. If people want other firmware files subpackaged, respond to the RFC and I'll have a look.
I'd really like the wl12xx packaging (and associated SRCREV bump) to go into the 1.1 release. But as it is with ponies and world peace, we might not all get what we want :)
.../linux-firmware/linux-firmware_git.bb | 54 ++++++++-----------
1 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 660877e..e64ee92 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -1,32 +1,24 @@
DESCRIPTION = "Firmware files for use with Linux kernel"
SECTION = "kernel"
LICENSE = "Proprietary"
-LICENSE_${PN}-sd8686 = "Firmware:LICENSE.libertas"
-LICENSE_${PN}-rtl8192cu = "Firmware:LICENCE.rtlwifi_firmware"
-LICENSE_${PN}-rtl8192ce = "Firmware:LICENCE.rtlwifi_firmware"
-LICENSE_${PN}-rtl8192su = "Firmware:LICENCE.rtlwifi_firmware"
LIC_FILES_CHKSUM = "file://LICENSE.radeon_rlc;md5=4c243f7854d2884b483abda991adef43 \
file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 \
file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
file://LICENCE.qla2xxx;md5=4005328a134054f0fa077bdc37aa64f2 \
- file://LICENCE.mwl8k;md5=9ddea1734a4baf3c78d845151f42a37a \
- file://LICENCE.libertas;md5=2d2127d203ac000f1afabfce593659ce \
file://LICENCE.iwlwifi_firmware;md5=311cc823df5b1be4f00fbf0f17d96a6b \
file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \
- file://LICENCE.atheros_firmware;md5=62748c8fecfa12010fd76409db4b5459 \
+ file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \
file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
file://LICENCE.rtlwifi_firmware.txt;md5=00d06cfd3eddd5a2698948ead2ad54a5 \
"
-PROVIDES += "linux-firmware-sd8686 linux-firmware-rtl8192cu linux-firmware-rtl8192ce linux-firmware-rtl8192su"
-
-SRCREV = "40c0f950be7040614dc45df54e25e54d00e3b73b"
+SRCREV = "d543c1d98fc240267ee59fff93f7a0f36d9e2fc3"
PV = "0.0+git${SRCPV}"
-PR = "r1"
+PR = "r2"
-SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git;protocol=git"
+SRC_URI = "git://git.infradead.org/users/dwmw2/linux-firmware.git;protocol=git"
S = "${WORKDIR}/git"
@@ -36,46 +28,46 @@ do_compile() {
do_install() {
install -d ${D}/lib/firmware/
+ cp -RpP * ${D}/lib/firmware/
+
# Libertas sd8686
install -m 0644 libertas/sd8686_v9.bin ${D}/lib/firmware/sd8686.bin
install -m 0644 libertas/sd8686_v9_helper.bin ${D}/lib/firmware/sd8686_helper.bin
- install -m 0644 LICENCE.libertas ${D}/lib/firmware/
+
# Realtek rtl8192*
- install -d ${D}/lib/firmware/rtlwifi/
- install -m 0644 rtlwifi/rtl8192cufw.bin ${D}/lib/firmware/rtlwifi/rtl8192cufw.bin
- install -m 0644 rtlwifi/rtl8192cfw.bin ${D}/lib/firmware/rtlwifi/rtl8192cfw.bin
- install -m 0644 rtlwifi/rtl8712u.bin ${D}/lib/firmware/rtlwifi/rtl8712u.bin
install -m 0644 LICENCE.rtlwifi_firmware.txt ${D}/lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt
+
+ # fixup wl12xx location, after 2.6.37 the kernel searches a different location for it
+ ( cd ${D}/lib/firmware ; ln -sf ti-connectivity/* . )
}
-PACKAGES = "${PN}-sd8686 ${PN}-rtl8192cu linux-firmware-rtl8192ce linux-firmware-rtl8192su"
+PACKAGES =+ "${PN}-sd8686 ${PN}-rtl8192cu linux-firmware-rtl8192ce linux-firmware-rtl8192su ${PN}-wl12xx"
+LICENSE_${PN}-sd8686 = "Firmware:LICENSE.libertas"
FILES_${PN}-sd8686 = "/lib/firmware/sd8686* /lib/firmware/LICENCE.libertas"
-RPROVIDES_${PN}-sd8686 = "${PN}-sd8686"
-
-FILES_${PN}-rtl8192cu = " \
- /lib/firmware/rtlwifi/rtl8192cufw.bin \
- /lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt \
-"
-RPROVIDES_${PN}-rtl8192cu = "${PN}-rtl8192cu"
-
+LICENSE_${PN}-rtl8192cu = "Firmware:LICENCE.rtlwifi_firmware"
FILES_${PN}-rtl8192cu = " \
/lib/firmware/rtlwifi/rtl8192cufw.bin \
/lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt \
"
-RPROVIDES_${PN}-rtl8192cu = "${PN}-rtl8192cu"
+LICENSE_${PN}-rtl8192ce = "Firmware:LICENCE.rtlwifi_firmware"
FILES_${PN}-rtl8192ce = " \
/lib/firmware/rtlwifi/rtl8192cfw.bin \
- /lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt \
"
-RPROVIDES_${PN}-rtl8192ce = "${PN}-rtl8192ce"
+LICENSE_${PN}-rtl8192su = "Firmware:LICENCE.rtlwifi_firmware"
FILES_${PN}-rtl8192su = " \
/lib/firmware/rtlwifi/rtl8712u.bin \
- /lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt \
"
-RPROVIDES_${PN}-rtl8192su = "${PN}-rtl8192su"
+
+FILES_${PN}-wl12xx = " \
+ /lib/firmware/wl12* \
+ /lib/firmware/TI* \
+ /lib/firmware/ti-connectivity \
+"
+
+FILES_${PN} += "/lib/firmware/*"
PACKAGE_ARCH = "all"
--
1.6.6.1
^ permalink raw reply related
* Re: binutils from meta-oe does build build
From: Martin Jansa @ 2011-10-09 7:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soz1FCyCZwA2Oe14q2e=RrxVZmJ3iVjQ=-P+fUghRYP3g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On Sat, Oct 08, 2011 at 06:01:36PM -0700, Khem Raj wrote:
> On Sat, Oct 8, 2011 at 9:08 AM, Philip Balister <philip@balister.org> wrote:
> > http://pastebin.com/M0Gw0Db2
> >
> > Basically, warnings are being treated as errors and the compile fails.
>
> you might add --disable-werror to EXTRA_OECONF
> in meta-oe/recipes-devtools/binutils/binutils.inc
what about adding
-Wno-error=uninitialized
only to CFLAGS?
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH 1/1] lsb: Change link of ${baselib} to lib64 for 64bits system
From: Xiaofeng Yan @ 2011-10-09 7:11 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1317030097.git.xiaofeng.yan@windriver.com>
From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Binaries of lsb test suite need ld-linux.so* in /lib64.
for example:
Target$ ./lsbcmdchk
-sh: ./lsbcmdchk: No such file or directory
Target$ strings lsbcmdchk | grep "ld-"
/lib64/ld-lsb-x86-64.so.3
"lsbcmdchk" from lsb test suite is a binary program.
A new modification to lsb_1.4.bb caused that binaries from lsb test suite can't run
because binaries of lsb test suite need ld-linux.so* in /lib64.
But the link is changed due to adding multilib. I changed this link again.
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
---
meta/recipes-extended/lsb/lsb_1.4.bb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-extended/lsb/lsb_1.4.bb b/meta/recipes-extended/lsb/lsb_1.4.bb
index d472012..5df08b8 100644
--- a/meta/recipes-extended/lsb/lsb_1.4.bb
+++ b/meta/recipes-extended/lsb/lsb_1.4.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "LSB support for Poky Linux"
SECTION = "console/utils"
HOMEPAGE = "http://prdownloads.sourceforge.net/lsb"
LICENSE = "GPLv2+"
-PR = "r1"
+PR = "r2"
LIC_FILES_CHKSUM = "file://README;md5=12da544b1a3a5a1795a21160b49471cf"
@@ -69,7 +69,7 @@ do_install_append(){
install -m 0755 ${WORKDIR}/init-functions ${D}/${baselib}/lsb
if [ "${TARGET_ARCH}" == "x86_64" ];then
cd ${D}
- ln -sf ${baselib} lib
+ ln -sf ${baselib} lib64
cd ${D}/${baselib}
ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.2
ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3
@@ -82,7 +82,7 @@ do_install_append(){
if [ "${TARGET_ARCH}" == "powerpc64" ];then
cd ${D}
- ln -sf ${baselib} lib
+ ln -sf ${baselib} lib64
cd ${D}/${baselib}
ln -sf ld64.so.1 ld-lsb-ppc64.so.2
ln -sf ld64.so.1 ld-lsb-ppc64.so.3
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/1] lsb: Change link of ${baselib} to lib64 for 64bits system
From: Xiaofeng Yan @ 2011-10-09 7:11 UTC (permalink / raw)
To: openembedded-core
From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Binaries of lsb test suite need ld-linux.so* in /lib64.
for example:
Target$ ./lsbcmdchk
-sh: ./lsbcmdchk: No such file or directory
Target$ strings lsbcmdchk | grep "ld-"
/lib64/ld-lsb-x86-64.so.3
"lsbcmdchk" from lsb test suite is a binary program.
A new modification to lsb_1.4.bb caused that binaries from lsb test suite can't run because binaries of lsb test suite need ld-linux.so* in /lib64. But the link is changed due to adding multilib. I changed this link again
Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: xiaofeng/lsb64
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/lsb64
Thanks,
Xiaofeng Yan <xiaofeng.yan@windriver.com>
---
Xiaofeng Yan (1):
lsb: Change link of ${baselib} to lib64 for 64bits system
meta/recipes-extended/lsb/lsb_1.4.bb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: binutils from meta-oe does build build
From: Khem Raj @ 2011-10-09 1:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E907597.3090507@balister.org>
On Sat, Oct 8, 2011 at 9:08 AM, Philip Balister <philip@balister.org> wrote:
> http://pastebin.com/M0Gw0Db2
>
> Basically, warnings are being treated as errors and the compile fails.
you might add --disable-werror to EXTRA_OECONF
in meta-oe/recipes-devtools/binutils/binutils.inc
>
> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* binutils from meta-oe does build build
From: Philip Balister @ 2011-10-08 16:08 UTC (permalink / raw)
To: openembedded-core
http://pastebin.com/M0Gw0Db2
Basically, warnings are being treated as errors and the compile fails.
Philip
^ permalink raw reply
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