Re: [OE-core] Bitbake distro packages: kill them with fire
On Wed, Aug 29, 2012 at 8:49 AM, Koen Kooi wrote: > These might not be the appropiate lists, but I might reach a few of the > culprits. Over the years people have been doing 'apt get install bitbake' or > 'make install' to put bitbake into /usr/bin and after a few minutes to get on > irc/email/etc to complain that everything is suddenly broken. There are > checks for bitbake versions in the metadata, but it can (and will!) still > break with due to python path nastiness. > > So to every person packaging bitbake for their distro: stop doing that! > > If someone has a better suggestion to avoid this problem (more documentation > doesn't work), please speak up. I certainly agree that documentation doesn't work (for the most part). But maybe it wouldn't hurt to put in a small note about this issue in the quick start guide(s)? Perhaps in the section where it is telling you what packages you need installed before starting, it could include a note to make sure to not have bitbake installed from your distro? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] local.conf.sample: Have comments ready to go for quad-core (4 -> 8).
All of these "solutions" assume the user wants to use all of their entire computing resources to do nothing other than their Yocto build. This isn't _always_ the case, is it? :-) Personally, I know this build is going to take time. So I start it, then go off and do other things with my computer. In my case, I don't like it when the other things I'm trying to do on the computer are bogged down due to this all-consuming, background build task. I would much rather that whatever else I'm doing remain responsive to me. Whether the build finishes in 20 minutes or 25 is irrelevant because I'll only notice it's done 30 minutes from now :-) As such I never set my settings to "full power"... knowingly and purposefully. This being said, I think what is currently in the sample config file (which are roughly half of full power) are good defaults. If you're new to this kind of stuff, these settings will suit just fine. If you're a power user, you'll know how to set them to 8 or 16 or any other setting which suits your needs. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
Would contrib/jansa/test still be the most up-to-date choice for building against meta-openembedded? I just want to make sure I'm not duplicating existing effort. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
On Thu, May 2, 2013 at 11:57 AM, Paul Barker wrote: > The recipe also has dependencies > outside meta-oe (fluidsynth in meta-multimedia IIRC) but that's a > separate issue. I've noticed that too. Shouldn't dependencies be contained within the same layer? Is it normal from these dependencies to be spread out over various layers? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
On Thu, May 2, 2013 at 1:22 PM, Martin Jansa wrote: > See: > http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-April/045090.html Ah yes... openembedded-devel... that magic list to which I can't seem to subscribe myself ;-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
On Mon, May 6, 2013 at 3:15 PM, Paul Barker wrote: > lzip: fetch failure This is an easy one to fix: version 1.13 is no longer available, update the recipe (filename/hashes) to use version 1.14 instead. I have a patch waiting to submit, but until I can register for the openembedded-devel mailing list I don't have anywhere to send it. > Let me know if this is useful. Yes! Thank you. I find it particularly interesting to see what others do in their local.conf files. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Status Update
On Tue, May 7, 2013 at 8:45 AM, Richard Purdie wrote: > 1.3.2 > = > > I've merged a lot of queued changes that Ross prepared for 1.3.2 and > this is now undergoing testing. I have a patch for Danny to allow qemu-native of qemu-1.2.0 to compile on openSuSE 12.3 (which, apparently, is also affected by the same (or a similar) DSO linking change that affects fedora). Are the queued changes available somewhere so I can check this hasn't already been applied? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] SDK meta-toolchain
On Tue, May 7, 2013 at 12:36 PM, Mark Hatle wrote: > There are two ways to generate an SDK. > > * targeted SDK -- This is a meta-toolchain* recipe that lists -exactly- what > is going to be in the SDK. This is great if you want to limit your SDK to > specific libraries for your application developers. Is this the one created using: $ bitbake meta-toolchain ? > * implied / image based SDK -- This type of SDK bases off of what is in the > image to generate an SDK that contains all of the libraries that are > runnable inside of the image. This is a very simple way to generate an SDK > for application developers that -will- match the run-time image. Is this the one created by: $ bitbake -c populate_sdk ? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Status Update
On Tue, May 7, 2013 at 1:13 PM, Burton, Ross wrote: >> I have a patch for Danny to allow qemu-native of qemu-1.2.0 to compile >> on openSuSE 12.3 (which, apparently, is also affected by the same (or >> a similar) DSO linking change that affects fedora). Are the queued >> changes available somewhere so I can check this hasn't already been >> applied? > > The merged changes are in the "danny" branch of the oe-core and poky, > and there's a ross/danny-next branch in openembedded-core-contrib that > is my staging area for submissions to danny. I've looked through the list of patches and don't seem to find anything that will do what my patch needs to do in order to build qemu-1.2.0 on openSuSE 12.3. Would you consider adding the attached patch for Danny? (normally I'd send it in-line but I'm behind a firewall at the moment that won't allow "git send-email" to succeed, otherwise I could submit it this evening) 0001-qemu-native-fix-DSO-linking.patch Description: Binary data ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] SDK meta-toolchain
On Tue, May 7, 2013 at 1:41 PM, Mark Hatle wrote: > - nativesdk -- runs on the 'sdkhost' (variant called 'crosssdk') Is this related to the SDKMACHINE setting? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Status Update
On Wed, May 8, 2013 at 6:35 AM, Burton, Ross wrote: > On 7 May 2013 18:57, Trevor Woerner wrote: >> I've looked through the list of patches and don't seem to find >> anything that will do what my patch needs to do in order to build >> qemu-1.2.0 on openSuSE 12.3. Would you consider adding the attached >> patch for Danny? (normally I'd send it in-line but I'm behind a >> firewall at the moment that won't allow "git send-email" to succeed, >> otherwise I could submit it this evening) > > Merged to my danny-next branch, after confirming that this isn't > needed in Dylan/master as qemu 1.4 has the -lrt linkages declared. Whoops, sorry. I guess I should have mentioned that (since I was aware that qemu-native works fine with the latest Yocto HEAD). ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] runqemu: Replace use of ifconfig with ip
On Wed, May 8, 2013 at 3:40 PM, Khem Raj wrote:
> ifconfig and its ilk (net-tools package) is deprecated in favour of iproute2
> package
> and is now removed by many distro's e.g. Archlinux. So we replace ifconfig
> with ip utility
>
> Signed-off-by: Khem Raj
> ---
> scripts/runqemu-gen-tapdevs | 6 +++---
> scripts/runqemu-ifup| 6 +++---
> scripts/runqemu-internal| 6 +++---
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/scripts/runqemu-gen-tapdevs b/scripts/runqemu-gen-tapdevs
> index f5be30a..d3b27be 100755
> --- a/scripts/runqemu-gen-tapdevs
> +++ b/scripts/runqemu-gen-tapdevs
> @@ -59,10 +59,10 @@ if [ ! -x "$RUNQEMU_IFUP" ]; then
> exit 1
> fi
>
> -IFCONFIG=`which ifconfig 2> /dev/null`
> +IFCONFIG=`which ip 2> /dev/null`
> if [ -z "$IFCONFIG" ]; then
> # Is it ever anywhere else?
> - IFCONFIG=/sbin/ifconfig
> + IFCONFIG=/sbin/ip
Is the "command" command a Bourne shell builtin? If so, using
IFCONFIG=$(command -pv ip)
might be better? (same applies to the other, following instances)
> fi
> if [ ! -x "$IFCONFIG" ]; then
> echo "$IFCONFIG cannot be executed"
> @@ -70,7 +70,7 @@ if [ ! -x "$IFCONFIG" ]; then
> fi
>
> # Ensure we start with a clean slate
> -for tap in `$IFCONFIG | grep ^tap | awk '{ print \$1 }' | sed s/://`; do
> +for tap in `$IFCONFIG link | grep tap | awk '{ print \$2 }' | sed s/://`; do
> echo "Note: Destroying pre-existing tap interface $tap..."
> $TUNCTL -d $tap
> done
> diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
> index 0926faf..8948153 100755
> --- a/scripts/runqemu-ifup
> +++ b/scripts/runqemu-ifup
> @@ -70,10 +70,10 @@ if [ $STATUS -ne 0 ]; then
> fi
> fi
>
> -IFCONFIG=`which ifconfig 2> /dev/null`
> +IFCONFIG=`which ip 2> /dev/null`
> if [ "x$IFCONFIG" = "x" ]; then
> # better than nothing...
> - IFCONFIG=/sbin/ifconfig
> + IFCONFIG=/sbin/ip
> fi
> if [ ! -x "$IFCONFIG" ]; then
> echo "$IFCONFIG cannot be executed"
> @@ -100,7 +100,7 @@ if [ ! -x "$IPTABLES" ]; then
> fi
>
> n=$[ (`echo $TAP | sed 's/tap//'` * 2) + 1 ]
> -$IFCONFIG $TAP 192.168.7.$n netmask 255.255.255.255
> +$IFCONFIG addr add 192.168.7.$n/32 dev $TAP
>
> dest=$[ (`echo $TAP | sed 's/tap//'` * 2) + 2 ]
> $ROUTE add -host 192.168.7.$dest $TAP
> diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
> index f11706d..d295013 100755
> --- a/scripts/runqemu-internal
> +++ b/scripts/runqemu-internal
> @@ -139,16 +139,16 @@ if [ ! -d "$LOCKDIR" ]; then
> chmod 777 $LOCKDIR
> fi
>
> -IFCONFIG=`which ifconfig 2> /dev/null`
> +IFCONFIG=`which ip 2> /dev/null`
> if [ -z "$IFCONFIG" ]; then
> -IFCONFIG=/sbin/ifconfig
> +IFCONFIG=/sbin/ip
> fi
> if [ ! -x "$IFCONFIG" ]; then
> echo "$IFCONFIG cannot be executed"
> exit 1
> fi
>
> -POSSIBLE=`$IFCONFIG -a | grep '^tap' | awk '{print $1}' | sed s/://`
> +POSSIBLE=`$IFCONFIG link | grep 'tap' | awk '{print $2}' | sed s/://`
> TAP=""
> LOCKFILE=""
> for tap in $POSSIBLE; do
It does seem a little silly to continue to use a variable named
IFCONFIG now that you're switching away from "ifconfig" :-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Changes in Linaro layers for OpenEmbedded
On Thu, May 9, 2013 at 12:57 PM, Marcin Juszkiewicz wrote: > Who will maintain those layers after my leave? This was not decided yet. > There are few guys at Linaro who know how to use OpenEmbedded but most > of them is outside of Builds and Baselines team. To me this implies that these layers and this effort of yours isn't part of any "official" Linaro build process/procedure. Would this assumption be correct? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 1:41 AM, Khem Raj wrote:
> This patchset adds a new qemu based machine target for mips64 Big-endian
> linux-yocto recipe is modified to have it in tree to support qemumips64
> machine
My machine seems to build fine, but I can't seem to fully boot the
resulting image properly.
Build Configuration:
BB_VERSION= "1.19.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "openSUSE-project-12.3"
TARGET_SYS= "mips64-poky-linux"
MACHINE = "qemumips64"
DISTRO= "poky"
DISTRO_VERSION= "1.3+snapshot-20130513"
TUNE_FEATURES = "n64 bigendian fpu-hard"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:f7afeeb75993b159bb8959e0309bc5eb3978a8fb"
meta =
"kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03"
layers:
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
/home/trevor/devel/yocto/git/meta-poky/meta \
/home/trevor/devel/yocto/git/meta-poky/meta-yocto \
/home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \
/home/trevor/devel/yocto/git/openembedded-core/meta \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/trevor/devel/yocto/git/meta-poky/meta \
/home/trevor/devel/yocto/git/meta-poky/meta-yocto \
config:
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "qemumips64"
DL_DIR = "/home/trevor/devel/Downloads"
SSTATE_DIR = "/home/trevor/devel/yocto/sstate-cache"
TMPDIR = "${TOPDIR}/tmp"
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_rpm"
#SDKMACHINE ?= "i686"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
#IMAGETEST = "qemu"
#TEST_SCEN = "sanity bat sanity:boot toolchain"
#TEST_SERIALIZE = "1"
#OE_TERMINAL = "auto"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"
When I run:
$ runqemu qemumips64
the virtual machine doens't appear to throw any errors (perhaps "hda:
unknown partition table"?),
however the boot simply stops without ever getting to a cmdline (see
attached image).
<>___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 2:33 PM, Khem Raj wrote: > On May 13, 2013, at 9:45 AM, Trevor Woerner wrote: > try runqemu qemumips64 bootparams="root=/dev/sda" > > does that boot ? It gets a little further but doesn't succeed. I have now tried booting a number of times using various combinations of "serial" and "bootparams". Currently I'm using: $ runqemu qemumips64 serial bootparams="root=/dev/sda probe_mask=0x3f" How far the boot gets seems random, but sometimes I'll get the following panic: [...snip...] Creating 3 MTD partitions on "physmap-flash.0": 0x-0x0010 : "YAMON" 0x0010-0x003e : "User FS" 0x003e-0x0040 : "Board Config" pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbog...@alpha.franken.de PCI: Enabling device :00:0b.0 ( -> 0003) pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10 pcnet32: eth0: registered as PCnet/PCI II 79C970A pcnet32: 1 cards_found ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice usbcore: registered new interface driver wacom input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input1 md: raid10 personality registered for level 10 md: multipath personality registered for level -4 md: faulty personality registered for level -5 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-de...@redhat.com usbcore: registered new interface driver usbhid usbhid: USB HID core driver Reserved instruction in kernel code[#1]: Cpu 0 $ 0 : 80968790 0001 $ 4 : 0001 8085 $ 8 : 90001010 $12 : 0488 000f 0007 $16 : 0006 0001 808f $20 : 809b 808e 008b 809b $24 : $28 : 980007c8 980007c83cd0 980007c83cd0 80968790 Hi: Lo: epc : 80635910 reset_counters+0x60/0x90 Not tainted ra: 80968790 mipsxx_init+0x1d4/0x2d8 Status: 1400a4e2KX SX UX KERNEL EXL Cause : 00800028 PrId : 000182a0 (MIPS 20Kc) Modules linked in: Process swapper (pid: 1, threadinfo=980007c8, task=980007c38000, tls=) Stack : 980007c83ce0 980007c83ce0 008b 809b 980007c83d00 0006 80a778a0 80936930 980007c83d20 80968528 8093 0006 80a7 80a7 980007c83d60 809683ec 980007c83d70 0006 809b 809683bc 980007c83d90 80100530 809b 0006 0030 809b 809b1578 8097d960 980007c83dd0 80948c98 ... Call Trace: [] reset_counters+0x60/0x90 [] mipsxx_init+0x1d4/0x2d8 [] oprofile_arch_init+0x84/0x118 [] oprofile_init+0x30/0xb8 [] do_one_initcall+0x120/0x1a0 [] kernel_init+0x194/0x258 [] kernel_thread_helper+0x24/0x30 Code: 4080c802 4080c803 4080c800 <4080c801> 03c0e82d dfbe0008 03e8 67bd0010 ---[ end trace 340dd7de1cdea432 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 3:02 PM, Khem Raj wrote: > you must be using systemd. I am seeing same failure with systemd but only > when my build host is archlinux Are you referring to the build host or target? My build host is openSuSE 12.3 which does use systemd. For the target I'm just building core-image-minimal which, as is my understanding, uses sysvinit by default (i.e. I'm not doing anything explicit (that I'm aware) to request systemd in my target). ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
There's something else that's going on that is strange. When I do a "qemumips" build from the master repositories and run it, the qemu-system-mips that is used is the one built as part of OE (i.e. the one from the build sysroot). But when I build and run the "qemumips64" image using this branch, the runqemu script is using my computer's native qemu-system-mips64. Did I configure something incorrectly? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 3:38 PM, Robert P. J. Day wrote: > having unwisely wandered into this MIPS64 minefield a couple weeks > back, i might as well see if i can get a build. in short: > > * switch to kraj/qemumips64 branch of openembedded-core-contrib > * add that as another layer along with oe-core I believe you only need to add this oe-core/meta layer once. My bblayers.conf contains: BBLAYERS ?= " \ /home/trevor/devel/yocto/git/meta-poky/meta-yocto \ /home/trevor/devel/yocto/git/meta-poky/meta-yocto-bsp \ /home/trevor/devel/yocto/git/openembedded-core/meta \ " BBLAYERS_NON_REMOVABLE ?= " \ /home/trevor/devel/yocto/git/openembedded-core/meta \ /home/trevor/devel/yocto/git/meta-poky/meta-yocto \ " > * MACHINE = "qemumips64" > * bitbake a core-image-minimal > > is there anything critical i'm forgetting? what's the safest simple > image to try to build? fetching is now underway ... That's exactly what I tried. I also removed the (default) poky/meta layer since (as I understand it) the openembedded-core/meta layer replaces it. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
Bruce, you said you were building 3.8.11, but I'm not. When I run my image, my banner includes: Linux version 3.4.43-yocto-standard (trevor@zzz) (gcc version 4.7.2 (GCC) ) #1 PREEMPT Mon May 13 12:14:42 EDT 2013 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
I'm building core-image-minimal, I assume that's what everyone else is doing. When I run the "bitbake -s" as Robert is, I get the following: $ bitbake -s | grep linux linux-dummy :1.0-r1 linux-firmware 1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0 linux-libc-headers:3.8-r0 linux-libc-headers-yocto :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6 linux-yocto :3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1 :3.4.43+gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r4.4 linuxdoc-tools-native :0.9.66-r3 nativesdk-linux-libc-headers :3.8-r0 nativesdk-linux-libc-headers-yocto :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6 nativesdk-ocf-linux:20120127-r3.0 ocf-linux :20120127-r3.0 ocf-linux-native :20120127-r3.0 syslinux-native :4.03-r9 util-linux :2.22.2-r3 util-linux-native :2.22.2-r3 As you can see, I do have a 3.8.11 in my list too, but when I run "runqemu qemumips64" my banner (from the VM) says my image is running 3.4.43. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day wrote: > On Mon, 13 May 2013, Trevor Woerner wrote: > > > I'm building core-image-minimal, I assume that's what everyone else is > doing. > > When I run the "bitbake -s" as Robert is, I get the following: > > > > $ bitbake -s | grep linux > > linux-dummy :1.0-r1 > > > linux-firmware > 1:0.0+gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r0 > > > > > linux-libc-headers:3.8-r0 > > > linux-libc-headers-yocto > > > > :3.4+git-AUTOINC+a1cdb60720c452c3965eaec3ec2cd10f06261cc5_a1cdb60720c452c3965eaec3ec2cd10f06261cc5-r6 > > > > > linux-yocto > > > :3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_dd089cb5ba37ea14e8f90a884bf2a5be64ed817d-r4.1 > > > :3.4.43+gitAUTOINC+1bab5bd090948b4cc4c4ed57c834603a3cf9f235_fff57da7886cf5e99c07adf6649610cb1cd89330-r4.4 > > i'm confused ... why would you be building two versions of the > kernel? > I'm not explicitly trying to build two versions of the kernel :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
Okay, I'm going to start over :-) I have a layer, meta-poky, which is: $ git remote -v contrib git://git.pokylinux.org/poky-contrib (fetch) contrib git://git.pokylinux.org/poky-contrib (push) origin git://git.yoctoproject.org/poky (fetch) origin git://git.yoctoproject.org/poky (push) Currently I have the master branch checked out from origin: f7afeeb75993b159bb8959e0309bc5eb3978a8fb I also have openembedded-core, which is: $ git remote -v contrib git://git.openembedded.org/openembedded-core-contrib (fetch) contrib git://git.openembedded.org/openembedded-core-contrib (push) origin git://git.openembedded.org/openembedded-core (fetch) origin git://git.openembedded.org/openembedded-core (push) Currently I have Khem's branch checked out: b0592ab08273e17cb1511384ad189281f88c8b03 For my layers I'm only using: meta-poky/meta-yocto (which I need so I can build an image with poky) openembedded-core/meta (which I need for Khem's work, including the qemumips64 MACHINE) My understanding is that the things in openembedded-core/meta are meant to replace the corresponding directories from meta-poky/meta, which is why I'm not including meta-poky as a layer. I am very confused by Robert's ability to build successfully with only the following two layers: BBLAYERS ?= " \ /home/rpjday/oe/dist/layers/oe-core/meta \ /home/rpjday/oe/dist/layers/openembedded-core-contrib/meta \ " Since, as far as I can tell, neither of them includes what is required to build a poky image. But I'll be trying out what Robert has done to see if I can get what he's getting :-) Maybe I'm still confused over all this meta-openembedded/openembedded-core stuff. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day wrote: > i'm confused ... why would you be building two versions of the > kernel? Maybe I just need to provide a PREFERRED_PROVIDER_virtual/kernel? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 6:19 PM, Khem Raj wrote: > sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc > -v angstrom??! angstrom -> poky? sysroots/x86_64-linux/usr/bin/mips64-poky-linux/mips64-poky-linux-gcc --version mips64-poky-linux-gcc (GCC) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
By adding: PREFERRED_VERSION_linux-yocto := "3.8%" to my conf/local.conf I was able to get the image to build/use 3.8.11; but I too am still seeing the kernel panic as described before (i.e. in reset_counters()). ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Mon, May 13, 2013 at 10:03 PM, Bruce Ashfield wrote: > On Mon, May 13, 2013 at 10:01 PM, Trevor Woerner wrote: >> By adding: >> >> PREFERRED_VERSION_linux-yocto := "3.8%" > > Yep. This is what I was about to recommend, but did you apply Khem's patches, > or > use his contrib branch ? His contrib branch: Build Configuration: BB_VERSION= "1.19.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "openSUSE-project-12.3" TARGET_SYS= "mips64-poky-linux" MACHINE = "qemumips64" DISTRO= "poky" DISTRO_VERSION= "1.3+snapshot-20130514" TUNE_FEATURES = "n64 bigendian fpu-hard" TARGET_FPU= "" meta-yocto= "master:a9f5bf0ed398bf9cb861feaa8b6fefd8645b1d09" meta = "kraj/qemumips64:b0592ab08273e17cb1511384ad189281f88c8b03" Are there patches to apply too? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Tue, May 14, 2013 at 4:28 AM, Robert P. J. Day wrote: > On Mon, 13 May 2013, Khem Raj wrote: >> can you try this >> >> add >> >> SRCREV_machine_qemumips64 = "bbefde394205a1b317eae31942bfc13afce0b0ac" >> >> to linux-yocto_3.8.bb >> >> and rebuild the kernel and see if that boots > > ok, that gives me a successful boot (tried it twice, success both > times) but i'm now at a boot prompt: > > qemumips64 login: > > that's not accepting any keyboard input. tried a couple more times, > same result -- boot to login prompt, but no keyboard input. thoughts? Me too. If I use the "serial" option on the "runqemu" cmdline I can log in via the serial console. There was a time when I would get an unresponsive qemumips console (via SDL) but could log in on console... 3? or 4? That isn't the case with qemumips64. By the way, my build is still wanting to use linux-yocto_3.4.43. What's interesting is: without the change described by Khem above if I put: PREFERRED_VERSION_linux-yocto := "3.8%" in my local.conf I would get 3.8.11. When I add the change as described above, this line in local.conf gives me linux-yocto_3.8.4! With Khem's suggestion above: - linux-yocto_3.8.4 boots but the SDL console doesn't accept input - linux-yocto_3.4.43 doesn't fully boot (as before) > p.s. i can ping the VM (192.168.7.2) but can't ssh into it, FWIW. I don't have any issue ssh'ing into the VM (with the 3.8.4 kernel) when I add "ssh-server-openssh" to "EXTRA_IMAGE_FEATURES". ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
What really confuses me about the attempts I was making is that in my local.conf file I have explicitly asked for kernel version 3.8.11: PREFERRED_VERSION_linux-yocto := "3.8.11%" When I watch the build messages fly by I see that linux-yocto_3.8.11 is being built. In my work directory there is a directory called: tmp/work/qemumips64-poky-linux/linux-yocto/3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_bbefde394205a1b317eae31942bfc13afce0b0ac-r4.1/ but when I got into the tmp/work/qemumips64-poky-linux/linux-yocto/3.8.11+gitAUTOINC+8482dcdf68f9f7501118f4c01fdcb8f851882997_bbefde394205a1b317eae31942bfc13afce0b0ac-r4.1/linux directory and have a look at the Makefile, I see: VERSION = 3 PATCHLEVEL = 8 SUBLEVEL = 4 EXTRAVERSION = NAME = Unicycling Gorilla and when I boot the image the kernel banner says: Linux version 3.8.4-yocto-standard (trevor@zzz) (gcc version 4.7.2 (GCC) ) #1 PREEMPT Tue May 14 11:10:07 EDT 2013 Can anyone explain the discrepancy? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Wed, May 15, 2013 at 1:24 PM, Bruce Ashfield wrote: > You set the SRCREV that Khem sent. That was my 3.8.4. commit. The version > number in the directories is coming coming from the PV of the package, which > you > didn't tweak. Ahh... yes. Thank you. Makes perfect sense now :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add qemumips64 machine support
On Wed, May 15, 2013 at 5:58 PM, Robert P. J. Day wrote:
> On Wed, 15 May 2013, Bruce Ashfield wrote:
>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> index b79fa4e..d458212 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
>> @@ -5,6 +5,7 @@ KBRANCH = "${KBRANCH_DEFAULT}"
>>
>> SRCREV_machine_qemuarm ?= "8fb1a478c9a05362e2e4e62fc30f5ef5d6c21f49"
>> SRCREV_machine_qemumips ?= "b8870f2b11f4c948ae90a19886335fa8b7fca487"
>> +SRCREV_machine_qemumips64 ?= "49041e56a3c4ff552bf9f8195809b8040e2e2723"
>> SRCREV_machine_qemuppc ?= "e4c12f12e61a29b6605c4fcbcfd6dbe18bd7b4e4"
>> SRCREV_machine_qemux86 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>> SRCREV_machine_qemux86-64 ?= "dd089cb5ba37ea14e8f90a884bf2a5be64ed817d"
>
> so just to be painfully clear, if i have current oe-core and
> openembedded-core-contrib repoes, i need make only the above change in
> the latter to get a working qemumips64 build that will boot to the
> command line and let me log in?
I just built and ran it using plain meta-poky/meta and
meta-poky/meta-yocto (applying the above change to meta-poky/meta/...,
and using a very recent pull to master) and am quite happy to report
that it works for me (as I understand it Saul pushed the various parts
required for the toolchain earlier today). The linux kernel banner,
sources, and "uname -a" are all linux-yocto_3.8.11 and I can log in
using the qemu SDL interface.
Now I just have to remove the kernel version preference line in my
config and verify that works okay too.
Does this mean we now have something that can work on the EdgeRouter Lite?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-firmware: Package some iwlwifi firmware separately
On 24 June 2013 10:27, Richard Purdie
wrote:
> PACKAGES =+ "${PN}-ralink ${PN}-sd8686 ${PN}-wl12xx ${PN}-vt6656 \
> ${PN}-rtl-license ${PN}-rtl8192cu ${PN}-rtl8192ce
> ${PN}-rtl8192su \
> ${PN}-broadcom-license ${PN}-bcm4329 ${PN}-bcm4330
> ${PN}-bcm4334 \
> - ${PN}-atheros-license ${PN}-ar9170 ${PN}-ar3k ${PN}-ath6k
> ${PN}-ath9k"
> + ${PN}-atheros-license ${PN}-ar9170 ${PN}-ar3k ${PN}-ath6k
> ${PN}-ath9k \
> + ${PN}-iwlwifi-licence ${PN}-iwlwifi-6000g2a-5
> ${PN}-iwlwifi-6000g2b-6"
Does it matter whether you use "licence" or "license"?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3 v2] sanity.bbclass: Check for the known broken version of make
On 27 June 2013 10:08, Mark Hatle wrote: > See GNU Savannah bug 30612 -- make 3.82 is known to be broken. > > A number of vendors are providing a modified version, so checking > for just the version string is not enough. We also need to check > if the patch for the issue has been applied. We use a modified > version of the reproduced to check for the issue. > > Signed-off-by: Mark Hatle > --- > + > +if status != 0: > +return "Your version of make 3.82 is broken. Please revert to > 3.81 or install a patched version.\n" Instead of returning an error and asking the user to manually update their own 'make', wouldn't it be better if bitbake simply built its own known-to-be-working -native version instead? In this way a good, working version of 'make' could be installed in a potential SDK's sysroot as well? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3 v2] sanity.bbclass: Check for the known broken version of make
On 30 June 2013 12:02, Philip Balister wrote: > On 06/30/2013 11:56 AM, Trevor Woerner wrote: >> On 27 June 2013 10:08, Mark Hatle wrote: >>> See GNU Savannah bug 30612 -- make 3.82 is known to be broken. >>> >>> A number of vendors are providing a modified version, so checking >>> for just the version string is not enough. We also need to check >>> if the patch for the issue has been applied. We use a modified >>> version of the reproduced to check for the issue. >>> >>> Signed-off-by: Mark Hatle >>> --- >>> + >>> +if status != 0: >>> +return "Your version of make 3.82 is broken. Please revert to >>> 3.81 or install a patched version.\n" >> >> >> Instead of returning an error and asking the user to manually update >> their own 'make', wouldn't it be better if bitbake simply built its >> own known-to-be-working -native version instead? In this way a good, >> working version of 'make' could be installed in a potential SDK's >> sysroot as well? > > Is the broken version good enough to build a working version? In my case that's what I did (i.e. I used make-3.82 to build and install early in my $PATH make-3.81). I was then able to bitbake again which went to completion successfully. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3 v2] sanity.bbclass: Check for the known broken version of make
On 8 July 2013 17:55, Mark Hatle wrote: > For anyone with an old or > broken system, they will need to download (or build) the buildtools.. > install it and have it in their path prior to running oe-core. Does a download location already exist with downloads available for people who receive this error when building? If so, could it be made part of the error message? Or maybe instead of asking people to use a working version of "make" the error message could instruct them to use one of these buildtools-tarball SDKs (and provide instructions for doing so)? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] nss: fix incorrect shebang line of perl script
On 10 July 2013 09:03, Hongxu Jia wrote: > Replace incorrect shebang line with `#!/usr/bin/perl'. I thought using 'env' was the preferred method? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] docbook-sgml-dtd-3.1-native.bb: Add real PV inside the recipe
On 10 July 2013 16:07, Emilia Ciobanu
wrote:
> PR = "${INC_PR}.0"
> +PV = "31"
I thought the general trend was to move away from real PVs to the
autoincrementer? I'm just curious to know what issue prompted the move
back to real PVs?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] docbook-sgml-dtd-3.1-native.bb: Add real PV inside the recipe
On 11 July 2013 10:55, Ciobanu, Emilia Maria Silvia wrote: > I think this is a misunderstanding. We are currently using the > autoincrementation > mechanism for the PR of the packages and not for the PV. In this case the PV > variable > was missing from the recipe. Whoops! Yes I see. Sorry about that :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3 v2] sanity.bbclass: Check for the known broken version of make
On 19 July 2013 05:41, Paul Eggleton wrote: > On Tuesday 09 July 2013 16:14:55 Trevor Woerner wrote: >> On 8 July 2013 17:55, Mark Hatle wrote: >> > For anyone with an old or broken system, they will need to download (or >> > build) the buildtools.. >> > install it and have it in their path prior to running oe-core. >> >> Does a download location already exist with downloads available for >> people who receive this error when building? If so, could it be made >> part of the error message? Or maybe instead of asking people to use a >> working version of "make" the error message could instruct them to use >> one of these buildtools-tarball SDKs (and provide instructions for >> doing so)? > > According to Beth, the current (nightly build) can be found here: > > http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/buildtools/ > > Location for the upcoming 1.5 release when that is available: > > http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/buildtools/ > > The tricky part is we don't have a solid location yet, only one being built > from master. Perhaps we could link to an intermediary page with explanatory > text that can link to the appropriate location. That would be quite helpful, and maybe even help people to help themselves should they come across this problem when trying to build. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH v3] chrpath.bbclass: strip common parent directories from rpath
On 30 July 2013 14:47, Andreas Oberritter wrote: > AFAIR, the reasoning against patchelf was the bad availability across > distributions and it being a prerequisite for native builds. Today, > there's still no patchelf package in current releases of Debian or Ubuntu. pseudo isn't part of most distributions either; but that doesn't mean it can't be an important part of OE/Yocto :-) Couldn't patchelf-native be built as part of the "getting your system ready to build" phase? Khem, don't forget to add it to buildtools-tarball, the SDKs, and the build applicance(s). ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] 'wic'- OpenEmbedded Image Creator
On 26 September 2013 22:17, Tom Zanussi wrote: > This patchset implements a new command named 'wic' (for OpenEmbedded > Image Creator). Please see [YOCTO #3847] for extensive background on > what's implemented here. Wow Tom, this is really AWESOME work! And thanks for the excellent detailed description of the current system which you documented in [YOCTO #3847]! One question comes to mind: if I have a package which installs files to two (or more) different directories and I have decided (for whatever reason) that those directories should be on separate partitions, is this supported? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] runtime package management: ipk/opk
Place the on-target feed configuration into the "base-feeds.conf" file instead
of the "opkg.conf" file.
Signed-off-by: Trevor Woerner
---
meta/classes/rootfs_ipk.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index b0805dc..1537af4 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -159,7 +159,7 @@ ipk_insert_feed_uris () {
echo "Added $feed_name feed with URL $feed_uri"
# insert new feed-sources
- echo "src/gz $feed_name $feed_uri" >> ${IPKGCONF_TARGET}
+ echo "src/gz $feed_name $feed_uri" >>
${IMAGE_ROOTFS}/${sysconfdir}/opkg/base-feeds.conf
done
# Allow to use package deploy directory contents as quick devel-testing
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] runtime package management: ipk/opk
Hi Saul, On 1 November 2013 12:35, Saul Wold wrote: > This says what you are doing, but the question is why is the change needed? > It might be obvious to you, but not to others. The base-feeds.conf file is > provided via the a distro configuration, so it's not guarenteed to be there > for every distro, so I am not sure this change is correct. > > Also for future referece the commit message should follow the commit > guidelines: You're right, this patch is messed up. Thank you for the feedback :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
I'm curious to know if anyone (I certainly wouldn't be able to!) can
take a guess whether this would "play nicely" with external
toolchains?
In other words, if some recipe is already PROVIDES'ing
virtual/${TARGET_PREFIX}gcc etc would the correct toolchain be used
for the special packages needing the secondary toolchain?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] runqemu: change terminal's INTR key in 'serial' mode
If you are using an image in '-serial stdio' mode, temporarily change the
terminal's interrupt character to 'Ctrl-]' for the duration of the image
run. In this way, hitting 'Ctrl-C' for something running in the image
doesn't accidentally abort the entire qemu session.
Signed-off-by: Trevor Woerner
---
scripts/runqemu | 2 ++
scripts/runqemu-internal | 7 +++
2 files changed, 9 insertions(+)
diff --git a/scripts/runqemu b/scripts/runqemu
index 190e3b4..9418ebd 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -64,6 +64,7 @@ LAZY_ROOTFS=""
SCRIPT_QEMU_OPT=""
SCRIPT_QEMU_EXTRA_OPT=""
SCRIPT_KERNEL_OPT=""
+SERIALSTDIO=""
# Determine whether the file is a kernel or QEMU image, and set the
# appropriate variables
@@ -138,6 +139,7 @@ while true; do
"serial")
SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -serial stdio"
SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0"
+SERIALSTDIO="1"
;;
"qemuparams="*)
SCRIPT_QEMU_EXTRA_OPT="${arg##qemuparams=}"
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 7fbe0a0..10d5a5f 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -444,6 +444,7 @@ if [ "$MACHINE" = "qemush4" ]; then
#KERNCMDLINE="root=/dev/hda console=ttyS0 console=tty0
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
KERNCMDLINE="root=/dev/hda rw console=ttySC1 noiotrap
earlyprintk=sh-sci.1 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD -M $MACHINE_SUBTYPE -hda $ROOTFS
-no-reboot $QEMU_UI_OPTIONS -monitor null -serial vc -serial stdio"
+SERIALSTDIO="1"
fi
if [ "$FSTYPE" = "nfs" ]; then
if [ "$NFS_SERVER" = "192.168.7.1" -a ! -d "$NFS_DIR" ]; then
@@ -453,6 +454,7 @@ if [ "$MACHINE" = "qemush4" ]; then
fi
KERNCMDLINE="root=/dev/nfs console=ttySC1 noiotrap
earlyprintk=sh-sci.1 console=tty nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD -M $MACHINE_SUBTYPE -no-reboot
$QEMU_UI_OPTIONS -monitor null -serial vc -serial stdio"
+SERIALSTDIO="1"
fi
fi
@@ -565,6 +567,11 @@ then
fi
fi
+if [ "x$SERIALSTDIO" = "x1" ]; then
+echo "Escape character is '^]'"
+stty intr ^]
+fi
+
echo "Running $QEMU..."
# -no-reboot is a mandatory option - see bug #100
if [ "$FSTYPE" = "vmdk" ]; then
--
1.8.0
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] runqemu: change terminal's INTR key in 'serial' mode
On Fri, Dec 21, 2012 at 8:00 AM, Trevor Woerner wrote: > +if [ "x$SERIALSTDIO" = "x1" ]; then > +echo "Escape character is '^]'" > +stty intr ^] > +fi Hold on. This should be "Interrupt charater". ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] runqemu: change terminal's INTR key in 'serial' mode
If you are using an image in '-serial stdio' mode, temporarily change the
terminal's interrupt character to 'Ctrl-]' for the duration of the image
run. In this way, hitting 'Ctrl-C' for something running in the image
doesn't accidentally abort the entire qemu session.
Signed-off-by: Trevor Woerner
---
scripts/runqemu | 2 ++
scripts/runqemu-internal | 7 +++
2 files changed, 9 insertions(+)
diff --git a/scripts/runqemu b/scripts/runqemu
index 190e3b4..9418ebd 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -64,6 +64,7 @@ LAZY_ROOTFS=""
SCRIPT_QEMU_OPT=""
SCRIPT_QEMU_EXTRA_OPT=""
SCRIPT_KERNEL_OPT=""
+SERIALSTDIO=""
# Determine whether the file is a kernel or QEMU image, and set the
# appropriate variables
@@ -138,6 +139,7 @@ while true; do
"serial")
SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -serial stdio"
SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0"
+SERIALSTDIO="1"
;;
"qemuparams="*)
SCRIPT_QEMU_EXTRA_OPT="${arg##qemuparams=}"
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 7fbe0a0..a11220d 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -444,6 +444,7 @@ if [ "$MACHINE" = "qemush4" ]; then
#KERNCMDLINE="root=/dev/hda console=ttyS0 console=tty0
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
KERNCMDLINE="root=/dev/hda rw console=ttySC1 noiotrap
earlyprintk=sh-sci.1 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD -M $MACHINE_SUBTYPE -hda $ROOTFS
-no-reboot $QEMU_UI_OPTIONS -monitor null -serial vc -serial stdio"
+SERIALSTDIO="1"
fi
if [ "$FSTYPE" = "nfs" ]; then
if [ "$NFS_SERVER" = "192.168.7.1" -a ! -d "$NFS_DIR" ]; then
@@ -453,6 +454,7 @@ if [ "$MACHINE" = "qemush4" ]; then
fi
KERNCMDLINE="root=/dev/nfs console=ttySC1 noiotrap
earlyprintk=sh-sci.1 console=tty nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD -M $MACHINE_SUBTYPE -no-reboot
$QEMU_UI_OPTIONS -monitor null -serial vc -serial stdio"
+SERIALSTDIO="1"
fi
fi
@@ -565,6 +567,11 @@ then
fi
fi
+if [ "x$SERIALSTDIO" = "x1" ]; then
+echo "Interrupt character is '^]'"
+stty intr ^]
+fi
+
echo "Running $QEMU..."
# -no-reboot is a mandatory option - see bug #100
if [ "$FSTYPE" = "vmdk" ]; then
--
1.8.0
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] libmatchbox: use PACKAGECONFIG
Hi Ross, Your commit message and your commit don't seem to agree. I.e. you say you've removed 2 dependencies, but it looks like you've actually removed more than just 2. On 12/10/13 07:13, Ross Burton wrote: > Use PACKAGECONFIG to offer some flexibility to the libmatchbox configuration, > and remove two spurious build dependencies (expat and > libstartup-notification). [snip] > -DEPENDS = "virtual/libx11 libxext expat libxft jpeg libpng zlib > libxsettings-client startup-notification" > +DEPENDS = "virtual/libx11 libxext" ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/38] Cleanup series
On 12/28/13 17:28, Paul Eggleton wrote: > I got a bit tired of seeing poor SUMMARY and DESCRIPTION values in our > recipes, so I went on a bit of a quest to clean them up, and ended up > tidying up a few other things in the process. This might be a good time to remind people of the meta-openembedded/contrib/oe-stylize.py script (which was recently pointed out to me). Unfortunately the style guide to which it points http://openembedded.org/wiki/StyleGuide doesn't appear to exist anymore. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Qt in OE-core
Hello everyone, question: Should some version of Qt be included in openembedded-core, or should all recipes to add Qt be part of their own version-specific Qt layer? background: openembedded-core[1] used to include recipes for Qt3, but as Qt3 became old these recipes were replaced with Qt4 and the Qt3 support was broken out into its own layer[2]. We're now at a point where Qt4 is getting old and Qt5 is "current". At some point we'll have to replace the Qt4 support in [1] with support for Qt5. But we expect users will still want to use Qt4, so if the Qt4 support in [1] is replaced by support for Qt5, the Qt4 support will need to be broken out into its own layer. Qt5 support is currently being developed on it's own layer[3]. This email thread is *not* to discuss when we should replace Qt4 with Qt5, then question is: should [1] include *any* Qt support, or should Qt be always in its own layer to be added as required by the distribution? If we decide [1] should provide some Qt support, then we can discuss when we should replace the Qt4 support with Qt5 in [1]. But for now it would be nice to reach a consensus on whether or not [1] should include any Qt support at all or if it wouldn't just be easier to always have Qt support in its own version-specific layers to be added as required (if needed) by the distribution configuration. Thanks for your feedback. [1] http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/ [2] http://layers.openembedded.org/layerindex/branch/master/layer/meta-qt3/ [3] http://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libxfont: upgrade to 1.4.7
A security advisory, CVE-2013-6462, has been issued for libXfont so bump to
version 1.4.7 which fixes this issue.
http://lists.x.org/archives/xorg/2014-January/056265.html
"Stack buffer overflow in parsing of BDF font files in libXfont"
Trevor Woerner (1):
libxfont: upgrade to 1.4.7
.../xorg-lib/{libxfont_1.4.6.bb => libxfont_1.4.7.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-lib/{libxfont_1.4.6.bb => libxfont_1.4.7.bb}
(77%)
--
1.8.5.2.227.g53f3478
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libxfont: upgrade to 1.4.7
This release includes the fix for CVE-2013-6462, as well as other security
hardening and code cleanups.
Signed-off-by: Trevor Woerner
---
.../xorg-lib/{libxfont_1.4.6.bb => libxfont_1.4.7.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-lib/{libxfont_1.4.6.bb => libxfont_1.4.7.bb}
(77%)
diff --git a/meta/recipes-graphics/xorg-lib/libxfont_1.4.6.bb
b/meta/recipes-graphics/xorg-lib/libxfont_1.4.7.bb
similarity index 77%
rename from meta/recipes-graphics/xorg-lib/libxfont_1.4.6.bb
rename to meta/recipes-graphics/xorg-lib/libxfont_1.4.7.bb
index 4f8a6a5..d587ba8 100644
--- a/meta/recipes-graphics/xorg-lib/libxfont_1.4.6.bb
+++ b/meta/recipes-graphics/xorg-lib/libxfont_1.4.7.bb
@@ -18,5 +18,5 @@ XORG_PN = "libXfont"
BBCLASSEXTEND = "native"
-SRC_URI[md5sum] = "351a9b7348d165029bda52c9fdcb5c7a"
-SRC_URI[sha256sum] =
"d0cbfe4554dc17ceea413cdad5601d35ed8d05d5b880e60931a8775fd1157e9f"
+SRC_URI[md5sum] = "b21ee5739d5d2e5028b302fbf9fe630b"
+SRC_URI[sha256sum] =
"d16ea3541835d296b19cfb05d7e64fc62173d8e7eb93284402ec761b951d1543"
--
1.8.5.2.227.g53f3478
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libxfont: upgrade to 1.4.7
Whoops! I thought the "[OE-core]" part was added automatically by the mailing list software. Should I send a V2? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On 01/08/14 10:56, Paul Eggleton wrote: > However, one concern I have always had with Qt being moved out of > OE-Core though is that I very much doubt the same will happen with > GTK+ and GNOME UI components that we carry, which I think will lead to > the (perhaps erroneous, but logical) assumption in new users' minds > that we support or recommend these more than we do Qt. Given Qt's > popularity in the embedded space I don't think this would be the right > message to be sending out. Any concrete ideas on how we would address > this perception issue? Would it be worthwhile to ask that the OE TSC take on the task of defining what is "core" and what is not? Does this definition already exist? >From the moment OE chose to adopt a layered strategy, people started questioning how to define a layer and what recipes should be part of one layer versus another. But it doesn't seem as though there's been much interest in setting any definite rules or definitions in this regard. Maybe it would be worth the effort to at least try? In my opinion... Personally I would be in favour of removing GTK+ and the GNOME UI from the core and putting them in their own layer for all the same reasons I think Qt should be in its own layer: - a "basic" image doesn't need them - we can have different layers to track separate major releases (as with qt3, qt4, and qt5) There are so many ways to do GUI "things" on top of a Linux system. Frankly I'm not even in a position where I could enumerate all of them, or even sort them out: - x11, wayland, mir, (directfb) (http://en.wikipedia.org/wiki/Display_server) - qt, gtk+, wxwidgets, tcl/tk, fltk (http://en.wikipedia.org/wiki/List_of_widget_toolkits) - xlib, xcb (client libraries implementing x11 protocol) - weston, mutter, kwin, clayland (display servers implementing the wayland display server protocol) - opengl, opengles, egl, ... (I can't even begin to figure out how to draw a diagram that shows how all these projects fit together!) Maybe if there are significant competing projects which do the same thing, then they should be implemented in their own layer: - meta-python - meta-perl And if there are completing projects which do the same thing but which aren't significantly large projects on their own (e.g. http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers) then they should form a layer together of their own: - meta-apache-httpd - meta-http-servers - boa - cherokee - lighttpd - nginx Or maybe all projects which do the same thing different ways should be in their own layer? That way we don't have to distinguish between "significant" and "lightweight" projects" - meta-scripting-languages - python - perl - ruby - meta-http-servers - apache - boa - cherokee - lighttpd - nginx And maybe "core" should be just enough to get a console-based image working? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] bug scrub - RFC
Hi everyone, This is a "Request For Comments" email regarding a "bug scrub" party the OE TSC would like to hold. background: It has been noticed that the number of bugs in the bugzilla[1] has been climbing; it would be nice to hold a "bug scrub" event to raise awareness of the bugzilla and hopefully get some issues resolved. questions: 1) Currently it has been suggested this should be a 2-day event, should these two days be during the week or over a weekend? In either case, which 2 days? 2) Since this is an OE event, should it focus only on OE bugs[2], or should it be generalized for any bug? 3) Should we create a sign-up sheet (wiki) to keep track of who is participating, and which issues are being looked at by whom? (anything else?) notes: 1) If you or the company for which you work uses OE/Yocto, please consider making this a company event and having/allowing the engineers (to) participate. 2) Even if you're not a recipe-, or a build-, or a python-wizard there are still many things you can do to contribute. Being able to reproduce a bug or reporting that a bug can't be reproduced can sometimes be quite helpful (sometimes this points to a host issue or to a bug's description not being descriptive enough). Sometimes a bug is stuck in the "needs info" stage which maybe you can provide. 3) Can anyone think of way to help "get the word out"? 4) It would be cool to be able to provide incentives to help people get interested and contributing to knocking some bugs around. So if anyone (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they could offer as an incentive (or, conversely, if there's a board you'd like to see Yocto target) please see about making that happen. Thanks and best regards, Trevor [1] https://bugzilla.yoctoproject.org [2] https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&classification=Build%20System%20%26%20Metadata&list_id=156074&product=OE-Core&query_format=advanced&resolution=---&order=bug_id%20DESC&query_based_on= ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On 01/08/14 05:28, Richard Purdie wrote: > On Tue, 2014-01-07 at 20:23 +0100, Martin Jansa wrote: >> With PACKAGECONFIGs which can list optional dependencies which aren't >> included in the the layer itself it's now easier to have recipe with >> optional qt5 support in oe-core, but qt5 itself in separate meta-qt5. > What dependencies on other layers does meta-qt5 have? > > If the policy is all qt5 things into meta-qt5, the risk is a fairly > large set of layer dependencies for meta-qt5. > > There is some perception I don't like external layers which isn't true. > > What I do dislike is "dependency creep". If the meta-qt5 isn't usable > without pulling in chunks of meta-oe for example, I'd think that rather > sad and it might as well move to meta-oe at that point. Theoretically, which dependencies a given usage of qt5 has depends on which PACKAGECONFIGs are used. In other words, one OE image or one OE distribution might want to use OpenGL, while another might decide against it. http://qt-project.org/doc/qt-5/linux-requirements.html If we did move to breaking more things out into more layers, would the resulting increase in the number of layers be easier to manage if we didn't have to depend on the user correctly setting up their conf/bblayers.conf? I admit I'm not familiar with a large number of applications of OE/Yocto, but of the 3 of which I am aware (gumstix, imx53qsb, and internally at Linaro) all have moved to using repo (an external tool) and custom initialization scripts to better handle setting up a user's layers and configuration.[1][2] What if a distro configuration file, an image.bb, a MACHINE specification, or a layer could specify its dependencies itself? Would this lead to "DLL hell"[3] or would this be the missing ingredient which keeps some projects from having to resort to using external tools? If a distro has the power to decide which UI library to use on which backend, should it then be up to the distro configuration to specify which layer(s) to add, and maybe even which branch/commit to use, and maybe also specify these layers' priority and ordering? Maybe in a different scenario this decision wants to be handled by the image configuration instead. In either case, we wouldn't have to rely on external tools (repo) and manual intervention (hoping the user updates conf/bblayers.conf correctly) to get our layers right before we can build. Same goes for meta-qt5. If meta-qt5 has dependencies on specific other layers, maybe those dependencies could be part of the meta-qt5 definition such that these other layers are pulled in automatically? Or maybe a specific choice of PACKAGECONFIG would trigger the required dependency? Would it be possible to add a step in the build process that uses bitbake's fetcher to get or sync a project's layers before starting the process of fetching a recipe's sources based on information collected from hints in the various configuration files? [1] https://github.com/gumstix/Gumstix-YoctoProject-Repo/blob/master/README.md [2] https://github.com/Freescale/fsl-community-bsp-platform [3] http://en.wikipedia.org/wiki/DLL_Hell ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] bug scrub - RFC
On 01/09/14 05:56, Jack Mitchell wrote: > On 08/01/14 23:20, Trevor Woerner wrote: >> questions: >> 1) Currently it has been suggested this should be a 2-day event, should >> these two days be during the week or over a weekend? In either case, >> which 2 days? >> > If it's two days long then why don't you do the best of both worlds and > have a Friday/Saturday or Sunday/Monday combination? I was thinking of doing it either fully during the week, or fully on a weekend since my feeling is that most people either work with OE/Yocto during the weekdays or on the weekend. There's nothing to say we couldn't run this "bug scrub" during the week, then run a second "bug scrub" 2 months from now on a weekend (or visa versa). >> 2) Since this is an OE event, should it focus only on OE bugs[2], or >> should it be generalized for any bug? > I don't think we should be limiting people to what they can work on > while "participating". Since this is an OE TSC event I didn't want any hard feelings ;-) I also thought that maybe it would be easier to get people interested if this "bug scrub" was targeted at a specific project. I thought there's a chance it might help get people interested if we said "let's have a bug event where we target these 30 bugs" instead of saying "there are 1000's of bugs in the bugzilla, pick one and try to do something about it". >> 4) It would be cool to be able to provide incentives to help people get >> interested and contributing to knocking some bugs around. So if anyone >> (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they >> could offer as an incentive (or, conversely, if there's a board you'd >> like to see Yocto target) please see about making that happen. >> > A unified effort towards a "new trendy" board would be a fun goal, but I > worry that hardware teething issues would then eat up run of the mill > bug fixing time, handouts for participation however, (bug fixed/reviewed > by/tested by) would be a great idea. > Sorry, yes, this is what I meant. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] bug scrub - RFC
On 01/09/14 10:34, Otavio Salvador wrote: > > On Thu, Jan 9, 2014 at 1:07 PM, Trevor Woerner > mailto:trevor.woer...@linaro.org>> wrote: > > On 01/09/14 05:56, Jack Mitchell wrote: > > On 08/01/14 23:20, Trevor Woerner wrote: > >> questions: > >> 1) Currently it has been suggested this should be a 2-day > event, should > >> these two days be during the week or over a weekend? In either > case, > >> which 2 days? > >> > > If it's two days long then why don't you do the best of both > worlds and > > have a Friday/Saturday or Sunday/Monday combination? > > I was thinking of doing it either fully during the week, or fully on a > weekend since my feeling is that most people either work with OE/Yocto > during the weekdays or on the weekend. There's nothing to say we > couldn't run this "bug scrub" during the week, then run a second "bug > scrub" 2 months from now on a weekend (or visa versa). > > > Maybe mix it, Friday, Saturday, Sunday, Monday. > > So we give in a single 'event' opportunity to both. > Okay, I can agree to that. How about targeting next weekend (Jan 17-18 2014). Would that be too soon? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] unmaintained layers
Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? meta-aarch64 meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev meta-kirkwood meta-linaro meta-linaro-toolchain meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 01/09/14 17:43, Mark Hatle wrote: > On 1/9/14, 3:45 PM, Bruce Ashfield wrote: >> On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner >> wrote: >>> Hi everyone, >>> >>> At the last TSC meeting the topic of unmaintained layers came up. Here >>> is the sorted list of master layers from the layer index [1], would it >>> be possible for those in the know to indicate which layers are, or are >>> suspected of being, unmaintained? >> >> Wouldn't it be easier to do an initial sort based on commit activity >> ? Versus an >> opt-in query ? > > I agree.. see below for mine.. To be honest, I had asked people to indicate which layers they thought were *un*maintained (since I assumed that list would be small), but this way works too. Interestingly enough, had I sorted the list on commit activity, according to http://git.yoctoproject.org/cgit/cgit.cgi/?s=idle meta-realtime hasn't been touched in 10 months which would make me suspect it was abandoned. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
Hi Paul,
On 01/10/14 09:01, Paul Eggleton wrote:
> This is all very interesting with people piping up that their layers
> are maintained, but I'm not sure it helps solve the overall problem.
> Also, if it does appear that a layer has gone "unmaintained" by
> popular consensus, what should actually be done about it?
I was hoping I could put together a list of the layers which are no
longer maintained to see if we could find people who might be interested
in stepping up and taking on their maintenance. Or at the very least,
clarifying a given layers' maintenance status.
At the last OE TSC meeting the issue of unmaintained layers was brought
up, I asked several times if people could specify to which layers they
were referring, but nobody replied. So people are concerned about layers
that have no maintainer, but nobody can say which ones (?). In my
opinion I thought it would be easier to solve this problem if we could
at least start by defining it.
As to what can be done about it: if a layer is not maintained, and
nobody cares for the layer, we should drop it from the list or at least
mark it as such ("buyer beware"). If a layer is not maintained, and
people do care, then we'll need to try to find someone to take
responsibility for it (we should, at the very least, make the attempt).
Also I think we should identify layers that people do care about, whose
maintenance is questionable, which are not hosted in a way where the
community can apply necessary patches to easily.
Best regards,
Trevor
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 01/10/14 11:02, Philip Balister wrote: > BTW, I maintain meta-sdr. ...and meta-ettus and meta-zynq? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
Hi Mike, On 01/12/14 15:28, Mike Looijmans wrote: > Worse than unmaintained - this one was taken out of existence last > Friday. I've already notified Paul Eggleton, so it should removed from > the list soon. Excellent, thanks for the update :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Cortex M3 tune fixes
Since OE is generally used to build Linux distributions, I'm rather curious to know why OE would include tunes for CortexM3? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Cortex M3 tune fixes
On 01/13/14 13:25, Phil Blundell wrote: > On Mon, 2014-01-13 at 13:16 -0500, Trevor Woerner wrote: >> Since OE is generally used to build Linux distributions, I'm rather >> curious to know why OE would include tunes for CortexM3? > Well, Cortex-M can run uClinux. Is there an OE layer that adds support for building u-boot and uClinux for Cortex-M3/4 [1]? I've been searching, and seem to be coming up empty. If there isn't, then I'm back to my original question :-) [1] https://github.com/EmcraftSystems ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ** bug squashing weekend - Jan 17 to 20, 2014
Hello all OE/Yocto enthusiasts! https://bugzilla.yoctoproject.org/ It has been noted that the number of unresolved issues in our bugzilla has been rising which, if left unchecked, will lead to an ever-increasing bug count. In an effort to raise awareness of the number of unresolved bugs and work to reduce them, we'd like to plan a "bug squashing weekend" for this upcoming Friday to Monday (January 17th to 20th, 2014). If you work with OE/Yocto during the week then you'll have two days to look at issues, or if you have more time on weekends you'll also have two potential days for this activity. It would be nice if anyone involved in OE/Yocto could take some time between now and Monday to have a look at the bugzilla database and consider contributing towards reducing the number of opened issues. Obviously if you're a maintainer or some sort of a developer there are, most likely, obvious issues you could consider addressing. But there are also lots of issues an OE/Yocto "user" could investigate as well -- for example there are documentation issues, there are several issues in the "NEEDINFO" state, and sometimes just being able to reproduce a bug (or not) and confirm (or not) that an issue can be demonstrated on more than one host can be valuable information for the person who does eventually get assigned to solve the problem. Please take the opportunity to have a look at the opened issues in the bugzilla database. If you don't have an account, please consider signing up. Play with the "Search" capability (you'll probably want to try an advanced search, https://bugzilla.yoctoproject.org/query.cgi?format=advanced) and see if there are issues to which you might want to contribute. In an effort to keep multiple people from working on the same issues during this sprint, please let the community know on which bugs you'd like to work. You could reply to this email (keeping all the mailing lists CC'ed), and/or you could re-assign a bug to yourself. There are usually plenty of friendly, knowledgeable people around who can help. You can use the mailing lists, IRC channels, or bugzilla itself to communicate. https://www.yoctoproject.org/tools-resources/community Thanks for your participation! :-) https://bugzilla.yoctoproject.org/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ** bug squashing weekend - Jan 17 to 20, 2014
Hopefully some of you have had the time to peruse the bugzilla database and have chosen a bug or two you'd like to quash this weekend. The bug hunt starts Friday Jan 16 and runs until Monday. If you're looking for more ideas there are some janitorial tasks outlined here: https://wiki.yoctoproject.org/wiki/Janitors ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] scripts: add get_maintainer script
This patch imports the Linux kernel's "get_maintainer.pl" script for use with OE/Yocto layers. The purpose of this script is to make it easy for people submitting patches to determine a sensible list of people to CC. Ideally all layers include valid MAINTAINERS files, in which case a valid MAINTAINERS file will be parsed for a list of potential people to include. But even if such a file does not exist, the "get_maintainer.pl" script is able to use the git history to create a sensilble list of relevant people who might be interested in changes to parts of various files a given patch touches. Invoke this script with "-h" or "--help" to get a detailed description of the various things this script can do. This script was modified in a couple minor ways to fit in with the OE/Yocto ecosystem. For example, the original script assumes the presence of a MAINTAINERS file; unfortunately not all layers (very few, in fact) include such a file. Also, it is not possible to assume all layers include a known file at a given location (i.e. to make sure the script is invoked from a valid OE/Yocto layer). For example most layers include a "conf/layer.conf" file, but some "layers" (such as openembedded-core) are containers for further sub-layers. Therefore this "location checking" logic had to be left out. If you would like to automate the processes of adding relevant CC's to your "git email"'s, simply add a "cccmd = get_maintainer.pl" line to your ".gitconfig" file and the CC's will be added to your emails automatically. Trevor Woerner (1): scripts: add get_maintainer script scripts/get_maintainer.pl | 2140 + 1 file changed, 2140 insertions(+) create mode 100755 scripts/get_maintainer.pl -- 1.8.5.2.227.g53f3478 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] scripts: add get_maintainer script
Hi Otavio, Thanks for taking a look at my patch. On 02/02/14 19:23, Otavio Salvador wrote: > I like to idea and I second this pull request, the only thing I would > like to see added is the possibility of grabing the maintainers for > boards from the machine .conf file. This is the way we're using at > meta-fsl-arm and meta-fsl-arm-extra. What do you think? To be honest I don't have much experience with perl, this script is in perl simply because that's the way it comes to us from the Linux kernel (although I was able to understand enough of it to be able to make the changes required so it would fit into this project). I'm quite sure, with StackOverflow by my side, I'd be more than able to make these changes :-) However... the MAINTAINERS syntax[1] does allow for "F", "N", "X", and "K" clauses, to wit: F: Files and directories with wildcard patterns. A trailing slash includes all files and subdirectory files. F: drivers/net/all files in and below drivers/net F: drivers/net/* all files in drivers/net, but not below F: */net/* all files in "any top level directory"/net One pattern per line. Multiple F: lines acceptable. N: Files and directories with regex patterns. N: [^a-z]tegra all files whose path contains the word tegra One pattern per line. Multiple N: lines acceptable. scripts/get_maintainer.pl has different behavior for files that match F: pattern and matches of N: patterns. By default, get_maintainer will not look at git log history when an F: pattern match occurs. When an N: match occurs, git log history is used to also notify the people that have git commit signatures. X: Files and directories that are NOT maintained, same rules as F: Files exclusions are tested before file matches. Can be useful for excluding a specific subdirectory, for instance: F: net/ X: net/ipv6/ matches all files in and below net excluding net/ipv6/ K: Keyword perl extended regex pattern to match content in a patch or file. For instance: K: of_get_profile matches patches or files that contain "of_get_profile" K: \b(printk|pr_(info|err))\b matches patches or files that contain one or more of the words printk, pr_info or pr_err One regex pattern per line. Multiple K: lines acceptable. As you can see, use of these clauses would cover your use case. What I was hoping for is that this script would be added to the project, then I could go about creating MAINTAINERS files for the various layers which would incorporate the information to which you referred above in a more standard, cross-project way. If you feel strongly about keeping the maintainers information in these files and this is the only thing holding up the script's inclusion I'd be happy to make the necessary modifications. But personally I'd prefer to use the existing MAINTAINERS syntax instead. Would moving that information into a standard top-level MAINTAINERS file suffice? Is there a reason it needs to be in those files (perhaps some other tool is processing them that couldn't be switched to process a MAINTAINERS file instead)? Best regards, Trevor [1] https://www.kernel.org/doc/linux/MAINTAINERS ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Upcoming Bug blitz weekend ( Feb 21 - Feb 24)
On 02/05/14 12:21, Khem Raj wrote: > I would like to invite everyone to the bug fixing weekend which is > coming in 3 weeks from Feb 21 to Feb 24 Maybe this notice should be posted to the blog? https://www.yoctoproject.org/new ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] do_rootfs: Added PACKAGE_FEED_URIS functionality
Does this resolve issue 5407? https://bugzilla.yoctoproject.org/show_bug.cgi?id=5407 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] image creation and deployment
(sorry I don't have the original email around to which to reply...) For the past many years I have been accumulating various scripts which I have used to create the root filesystems for various embedded systems. These scripts create updates, generate artifacts for creating bootable CF cards, and produce complete VMDK images in one VMDK file. This script allows the user on the cmdline to specify things such as the size, number, and filesystem for a flexible number of partitions. These scripts work on systems that are both 8 years old, as well as the latest distributions, they work with systems that have a little memory, to ones with lots. They can use any of lilo, extlinux, or u-boot (specified on the cmdline). I want to begin integrating this work with OE/YP in order to provide a demonstration so others can evaluate it and decide if this is something along the lines of what they'd find useful. http://lists.linuxtogo.org/pipermail/openembedded-core/2012-June/023484.html http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026938.html Although I'm quite familiar with my scripts... with OE/YP, not so much. So I was hoping to find some pointers for how I might proceed with this integration. Currently my scripts still require various privileges. So in the same way that a build runs to completion and then the user might run "runqemu" from the poky/scripts directory (and be required to give the root user's password to setup the tap networking), I would like to create a script in poky/scripts that would be run after a successful build which also might require root's password. I would like to ignore any images that are created as part of the build and rely solely on a package feed. So, provided a package feed is available, what would be the easiest way, in a shell script (run after a successful build), to say: "populate this random (specified) with all the packages the user wishes in their image". In other words I don't want to have to care whether the user has selected RPM or DEB, or IPK, and (preferably) I don't want to have to care what packages the user has selected (through various means) to be installed. I want to setup and create beforehand, I want OE/YP to populate it (without deleting or changing it in any way other than to populate it), then I want OE/YP to leave it alone for me to post-process. Is that possible? I was thinking that, as a kludge, I could use bitbake-env if I needed to get bitbake variables into the script. Any suggestions? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] OE TSC Minutes 4 Dec 2012
I think it would be nice (for us non-inner-circle members) if you could link the various IRC handles to the people behind them :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] state of systemd in oe
Just out of curiosity: - will systemd be the default? - will it be possible to still use/choose sysvinit (i.e. is sysvinit going away)? How does systemd fit in with busybox? My understanding is that busybox has its own init system. If someone enables/chooses systemd, does it disable busybox's init from being built? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
FYI On Tue, Feb 26, 2013 at 2:52 AM, Saul Wold wrote: >>> Just curious, what's your build host arch? and what does gcc >>> -print-multi-os-directory return on your host? on openSUSE 12.2 $ uname -a Linux codei7 3.4.28-2.20-desktop #1 SMP PREEMPT Tue Jan 29 16:51:37 UTC 2013 (143156b) x86_64 x86_64 x86_64 GNU/Linux $ gcc -print-multi-os-directory ../lib64 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/7] mkdebugfs.sh: several fixes
On Tue, Feb 26, 2013 at 4:24 AM, Robert Yang wrote: > Fix mkdebugfs.sh: > > *) > echo "Unknown file $FILE" 1>&2 > ;; > esac I know this doesn't come from your work, but since you're making changes, I think it would make for a better error message if the above said something along the lines of: echo "Unknown/unhandled file type '$(stat -c "%F" $FILE)' file:$FILE" ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/7] Create ext* filesystems using debugfs
On Tue, Feb 26, 2013 at 4:24 AM, Robert Yang wrote: > * Summary: > [...]now we use the mkfs.ext3/ext4 to create the image, and use mkdebugfs.sh > to copy the files to the image. For a while this had me confused because I somehow thought you were proposing using the Linux kernel's debugfs to create filesystems (i.e. mount -t debugfs none /sys/kernel/debug). Maybe I'm still confused, but if not I think, perhaps, it would be nice to come up with a better name for this script since the name clash will probably trip others up too. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/7] Create ext* filesystems using debugfs
On Tue, Feb 26, 2013 at 4:52 PM, Darren Hart wrote: > On 02/26/2013 09:53 AM, Trevor Woerner wrote: >> On Tue, Feb 26, 2013 at 4:24 AM, Robert Yang >> wrote: >>> * Summary: >>> [...]now we use the mkfs.ext3/ext4 to create the image, and use >>> mkdebugfs.sh >>> to copy the files to the image. >> >> For a while this had me confused because I somehow thought you were >> proposing using the Linux kernel's debugfs to create filesystems (i.e. >> mount -t debugfs none /sys/kernel/debug). > > It is confusing, unfortunately, debugfs is provided by e2fsprogs, not > something of our making. If you would prefer another name for > mkdebugfs.sh, that's fine. What would you propose? mkextXfs.sh ? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/7] Create ext* filesystems using debugfs
On Tue, Feb 26, 2013 at 6:00 PM, Darren Hart wrote: >> mkextXfs.sh ? > > Likely to be confused with mke2fs itself. Perhaps: > > populate-extfs.sh ? Sounds great. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] syslinux.bbclass: Add a default serial console option and real boot menu support
On Tue, Feb 26, 2013 at 9:04 PM, Jason Wessel wrote: > You can see the screen shots attached to the bugzilla. > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3944 > > [ YOCTO #3944 ] Is the "Windriver" logo on the VGA example optional? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] add libaudit and enable 'perf trace'
On Wed, Feb 27, 2013 at 10:00 AM, wrote: > From: Tom Zanussi > > 'perf-trace' is a new perf subcommand available in the 3.8 kernel - > this patchset enables it. 'perf trace' requires libaudit, which > is added as a new recipe. (I'm just getting used to this workflow, so sorry if I've messed something up on my end) When I try to build with just the following added to my conf/local.conf IMAGE_INSTALL_append = " perf" I get the following error: Build Configuration: BB_VERSION= "1.17.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "SUSE-LINUX-12.2" TARGET_SYS= "i586-poky-linux" MACHINE = "qemux86" DISTRO= "poky" DISTRO_VERSION= "1.3+snapshot-20130227" TUNE_FEATURES = "m32 i586" TARGET_FPU= "" meta meta-yocto meta-yocto-bsp= "tzanussi/perf-trace-v1:9f91a3a29701218dd756380ebcd2a1a32ad40615" Computing transaction...error: Can't install perf-3.4-r9@qemux86: no package provides /bin/bash ERROR: Function failed: do_rootfs ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] add libaudit and enable 'perf trace'
On Wed, Feb 27, 2013 at 10:00 AM, wrote: > 'perf-trace' is a new perf subcommand available in the 3.8 kernel - > this patchset enables it. Out of curiosity, from where can I find the recipe(s) for a 3.8 kernel? My meta/recipes-kernel/linux/ only includes: linux-dummy.bb linux-yocto-dev.bb linux-yocto-rt_3.0.bb linux-yocto-rt_3.2.bb linux-yocto-rt_3.4.bb linux-yocto-tiny_3.2.bb linux-yocto-tiny_3.4.bb linux-yocto_3.0.bb linux-yocto_3.2.bb linux-yocto_3.4.bb ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] add libaudit and enable 'perf trace'
On Wed, Feb 27, 2013 at 1:12 PM, Tom Zanussi wrote: > Which image are you building? I'm guessing core-image-minimal? Yes. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] gcc-4.7: Fix build with texinfo 5.0+
Maybe we should wait until the person who reported this issue has had the time to test this fix and confirms it works before submitting it for inclusion? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/40] Post-ELC Patches and Updates
On Fri, Mar 1, 2013 at 4:18 AM, Martin Jansa wrote: > I'm sure about Ubuntu where it's easy: > Ubuntu-10.04 \n \ > Ubuntu-11.10 \n \ > Ubuntu-12.04 \n \ > Ubuntu-12.10 \n \ > but with others I'll need some help. I can help with openSUSE, what do you need me to do? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu.inc: Non deterministic compile of qemu
On Fri, Mar 1, 2013 at 9:26 AM, Jason Wessel wrote:
> When you using a qemuppc target and sstate you might end up with
> the problem:
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index 6c44b31..eb60d43 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -2,8 +2,8 @@ DESCRIPTION = "open source processor emulator"
> HOMEPAGE = "http://qemu.org";
> LICENSE = "GPLv2 & LGPLv2.1"
> DEPENDS = "glib-2.0 zlib alsa-lib virtual/libx11 pixman"
> -DEPENDS_class-native = "zlib-native alsa-lib-native glib-2.0-native
> pixman-native"
> -DEPENDS_class-nativesdk = "nativesdk-zlib nativesdk-libsdl
> nativesdk-glib-2.0 nativesdk-pixman"
> +DEPENDS_class-native = "zlib-native alsa-lib-native glib-2.0-native
> pixman-native dtc-native"
> +DEPENDS_class-nativesdk = "nativesdk-zlib nativesdk-libsdl
> nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc"
> RDEPENDS_${PN}_class-nativesdk = "nativesdk-libsdl"
Is there a way to instrument this in such a way that these depends are
included only when the target machine is qemuppc? Some sort of
@machine_depends or something?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/40] Post-ELC Patches and Updates
On Fri, Mar 1, 2013 at 11:01 AM, Martin Jansa wrote: > send lsb_release -a output openSUSE 12.2: $ lsb_release -a LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch Distributor ID: SUSE LINUX Description:openSUSE 12.2 (x86_64) Release:12.2 Codename: Mantis ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Perf using host system includes
On Fri, Mar 1, 2013 at 7:00 AM, Jack Mitchell wrote: > It seems Perf is managing to have some system includes slip into the build. > Attached is the log file with details. Strange... I can't reproduce this. I just performed a build from master adding: IMAGE_INSTALL_append = " perf" to my conf/local.conf. It is strange that, about a dozen lines down, your log says: PERF_VERSION = 3.8.0 mine says: PERF_VERSION = 3.4.28 log.do_compile Description: Binary data ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption
Is this a proposed fix for bug 3898? https://bugzilla.yoctoproject.org/show_bug.cgi?id=3898 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-tools: Update autotools.patch
I'm seeing this exact same error when I perform a "bitbake world", and have been for the last couple days On Wed, Mar 13, 2013 at 9:43 PM, Nobuhiro Iwamatsu wrote: > > checking for i586-oe-linux-pkg-config... no > checking for pkg-config... > /home/iwamatsu/yocto/alsa/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config > configure: WARNING: using cross tools not prefixed with host triplet > checking pkg-config is at least version 0.9.0... yes > checking for ENVY24CONTROL... no > configure: error: Package requirements (gtk+-2.0 alsa >= 0.9.0) were not met: > > No package 'gtk+-2.0' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > > Alternatively, you may set the environment variables ENVY24CONTROL_CFLAGS > and ENVY24CONTROL_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > make: *** [all] Error 1 Is the proposed patch from this email suitable for merging to master? It allows my build of alsa-tools to complete without error. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] alsa-tools: fix build when x11 and gtk+ not available
With a rather recent HEAD Build Configuration: BB_VERSION= "1.17.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "openSUSE-project-12.3" TARGET_SYS= "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO= "poky" DISTRO_VERSION= "1.3+snapshot-20130407" TUNE_FEATURES = "m64" TARGET_FPU= "" meta meta-yocto meta-yocto-bsp= "master:813127247a1100b1abe179dfba25795560eac864" I am able to successfully perform a "bitbake world" on a number of different targets: - qemux86 - qemuarm - qemumips - qemux86-64 Unfortunately qemuppc fails when building alsa-tools. Is anyone else seeing the same thing? | make[1]: Entering directory `/home/trevor/build/yocto/fullbuild/qemuppc/work/ppc603e-poky-linux/alsa-tools/1.0.26.1-r1/alsa-tools-1.0.26.1/hda-verb' | make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=603e --sysroot=/home/trevor/build/yocto/fullbuild/qemuppc/sysroots/qemuppc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"hda-verb\" -DVERSION=\"0.4\" -DSTDC_HEADERS=1 -I. -O2 -Wall -pipe -g -MT hda-verb.o -MD -MP -MF .deps/hda-verb.Tpo -c -o hda-verb.o hda-verb.c | hda-verb.c:17:20: fatal error: sys/io.h: No such file or directory | compilation terminated. | make[1]: *** [hda-verb.o] Error 1 | make[1]: Leaving directory `/home/trevor/build/yocto/fullbuild/qemuppc/work/ppc603e-poky-linux/alsa-tools/1.0.26.1-r1/alsa-tools-1.0.26.1/hda-verb' | make: *** [all] Error 1 | ERROR: oe_runmake failed ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] local.conf.sample: Add info about -ptest package group
On Fri, Apr 5, 2013 at 11:35 AM, wrote: > +# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages > +# (useful if you want to run the package test suites) Is there a simple way to discover which packages are ptest-enabled? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] oe-buildenv-internal: Only add to $PATH if needed
On Fri, Apr 5, 2013 at 12:59 PM, Peter Kjellerstedt
wrote:
> +[ "${PATH#$NEWPATHS}" != "$PATH" ] || PATH="$NEWPATHS$PATH"
This is certainly a welcome addition in functionality, but it relies
on the pattern remaining at the start of the PATH (i.e. the user
hasn't played with PATH in any way). Could we not use the
${parameter/pattern/string} parameter expansion instead (e.g.
"${PATH/$NEWPATHS/}") so it doesn't matter whether the user has
further modified the PATH?
Best regards,
Trevor
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-tools: Fix sys/io.h patch
Excellent. Now all my qemu* "bitbake world"s succeed :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] meta-*/conf/layer.conf: tweak BBFILES comment
On Tue, Apr 9, 2013 at 10:19 AM, Paul Eggleton wrote: > -# We have a packages directory, add to BBFILES > +# We have recipes-* directories, add to BBFILES [etc] Thank you :-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] oe-buildenv-internal: Only add to $PATH if needed
On Mon, Apr 8, 2013 at 1:48 PM, Paul Eggleton wrote: > Unfortunately I think this is specific to bash, so it may not be portable. > Maybe the equivalent can be achieved with sed however. Under which shells do we expect a Yocto build to succeed? The latest version of this change wouldn't work under tcsh, for example. (Not that I'm suggesting it should!) Isn't there already an inherent Bourne-ish expectation? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] oe-buildenv-internal: Only add to $PATH if needed
On Tue, Apr 9, 2013 at 1:29 PM, Trevor Woerner wrote: > Under which shells do we expect a Yocto build to succeed? Whoops! My bad. sh -> yes bash -> not so much Let me rephrase: are bash-specific features to be so feared? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Minor comment/doc fixes
On Tue, Apr 9, 2013 at 10:19 AM, Paul Eggleton wrote: > git://git.openembedded.org/openembedded-core-contrib paule/layer-tweaks-core This is odd... I perform a: $ git fetch --all But I can only find a paule/layer-tweaks and not paule/layer-tweaks-core. Yet the http:// link works fine. Did I set something up wrong? $ git remote -v contrib git://git.pokylinux.org/poky-contrib (fetch) contrib git://git.pokylinux.org/poky-contrib (push) origin git://git.yoctoproject.org/poky (fetch) origin git://git.yoctoproject.org/poky (push) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Minor comment/doc fixes
On Tue, Apr 9, 2013 at 2:02 PM, Paul Eggleton wrote: > The openembedded-core-contrib and poky-contrib repos are entirely separate. D'oh! Retrying: $ git remote add contrib git://git.openembedded.org/meta-openembedded-contrib $ git remote -v contrib git://git.openembedded.org/meta-openembedded-contrib (fetch) contrib git://git.openembedded.org/meta-openembedded-contrib (push) origin git://git.openembedded.org/meta-openembedded (fetch) origin git://git.openembedded.org/meta-openembedded (push) $ git fetch contrib remote: Counting objects: 1288, done. remote: Compressing objects: 100% (554/554), done. remote: Total 903 (delta 491), reused 592 (delta 296) Receiving objects: 100% (903/903), 155.45 KiB | 55 KiB/s, done. Resolving deltas: 100% (491/491), completed with 119 local objects. >From git://git.openembedded.org/meta-openembedded-contrib * [new branch] gnutoo/gpsd-3.4 -> contrib/gnutoo/gpsd-3.4 * [new branch] gnutoo/gpsd-3.7 -> contrib/gnutoo/gpsd-3.7 * [new branch] gnutoo/libsdl -> contrib/gnutoo/libsdl * [new branch] gnutoo/vala-0.16.0 -> contrib/gnutoo/vala-0.16.0 * [new branch] hrw/aarch64-support -> contrib/hrw/aarch64-support * [new branch] hrw/world-cleanups -> contrib/hrw/world-cleanups * [new branch] jansa/for-danny -> contrib/jansa/for-danny * [new branch] jansa/for-danny2 -> contrib/jansa/for-danny2 * [new branch] jansa/for-danny3 -> contrib/jansa/for-danny3 * [new branch] jansa/in-test -> contrib/jansa/in-test * [new branch] jansa/in-test-cbrake -> contrib/jansa/in-test-cbrake * [new branch] jansa/in-test-felipe -> contrib/jansa/in-test-felipe * [new branch] jansa/in-test-hrw -> contrib/jansa/in-test-hrw * [new branch] jansa/in-test-khem -> contrib/jansa/in-test-khem * [new branch] jansa/in-test-koen -> contrib/jansa/in-test-koen * [new branch] jansa/in-test-ross -> contrib/jansa/in-test-ross * [new branch] jansa/test -> contrib/jansa/test * [new branch] jansa/world -> contrib/jansa/world * [new branch] kraj/updates -> contrib/kraj/updates * [new branch] master -> contrib/master * [new branch] obi/denzil -> contrib/obi/denzil * [new branch] obi/master -> contrib/obi/master * [new branch] paule/ajenti -> contrib/paule/ajenti * [new branch] paule/cleanup6 -> contrib/paule/cleanup6 * [new branch] paule/collectd -> contrib/paule/collectd * [new branch] ross/danny -> contrib/ross/danny * [new branch] ross/gtk -> contrib/ross/gtk * [new branch] ross/master -> contrib/ross/master * [new branch] ross/piglit -> contrib/ross/piglit * [new branch] ross/pinpoint -> contrib/ross/pinpoint * [new branch] ross/xorg -> contrib/ross/xorg * [new branch] shr-> contrib/shr * [new branch] trini/misc-v2 -> contrib/trini/misc-v2 I still don't see a paule/layer-tweaks-core :-( ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Minor comment/doc fixes
On Tue, Apr 9, 2013 at 2:49 PM, Paul Eggleton wrote: > Now you're looking at meta-openembedded-contrib as opposed to openembedded- > core-contrib. So... it has come to this, eh? http://xkcd.com/1022/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe][meta-oe][PATCH 2/4] xterm: add latest version of xterm
This whole thread has me thoroughly confused. Isn't xterm_277.bb already part of meta-openembedded? $ find . -name "*xterm*" -print ./meta-openembedded/meta-oe/recipes-graphics/xorg-app/xterm_277.bb And from what I can tell, it was added over a year ago by Koen: $ git log meta-oe/recipes-graphics/xorg-app/xterm_277.bb commit a38efd953c0bfef80fd6819c8339c1d1e79364b3 Author: Marcin Juszkiewicz Date: Thu Dec 13 10:35:26 2012 + xterm: added gnu-configize for AArch64 support Signed-off-by: Marcin Juszkiewicz Signed-off-by: Martin Jansa commit 253b1d7bc35c5a2a12dd6a7f2f0c034a34bfae18 Author: Koen Kooi Date: Fri Jan 13 09:41:51 2012 +0100 xterm: update to 277 License checksum changed due to date changes Signed-off-by: Koen Kooi ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
