Re: [yocto] Configuring Channels for Smart PM

2013-07-25 Thread Paul Eggleton
Hi Ash,

On Wednesday 24 July 2013 18:59:30 Ash Charles wrote:
> I'm looking to use a bbappend to add a repository/channel that the
> smart package manager can use out of the box.  For zypper, this was
> just a question of adding a configuration file to the recipe.
> 
> How might I preconfigure Smart?  The only way I've come up with so far
> is a postinst 'smart channel --add'

It does seem like Smart is geared more to configuration via the command line 
rather than editing the configuration file directly.

One approach you could take would be to add a shell function to your image 
recipe (or some class that multiple image recipes can inherit) that adds the 
feeds, and trigger that from ROOTFS_POSTPROCESS_COMMAND; this would add the 
feeds to your image when the image is generated. Something like this:


add_custom_smart_config() {
smart --data-dir=${IMAGE_ROOTFS}/var/lib/smart channel --add ... -y
}

ROOTFS_POSTPROCESS_COMMAND += "add_custom_smart_config ; "


It would be nice to have something built-in for this. I'll add it to my todo 
list.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Discovering available Perl modules OR writing recipes for your own

2013-07-25 Thread Trevor Woerner
On 24 July 2013 11:30, mulhern  wrote:
> pulledpork tries to use the module Crypt::SSLeay and in my current
> configuration it can't find it.

It looks like this module has a recipe in the meta-security layer:
http://layers.openembedded.org/layerindex/recipes/?q=perl
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] External toolchain (sourcery)

2013-07-25 Thread Laszlo Papp
I filed a bugreport against meta-sourcery:
https://github.com/MentorEmbedded/meta-sourcery/issues/9

It is very surprising to see a project without an actual documentation.
Perhaps, it has been mostly used for internal purposes where the developers
of the stuff were also the end users. That has to be fixed.


On Thu, Jul 25, 2013 at 5:53 AM, Laszlo Papp  wrote:

> So, is there any workaround in any way to get unblocked or I should just
> switch away from Yocto for now? Unfortunately, if no workaround comes, I do
> not have any other option because then it just does not work. :(
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899
>
> Note, I have no clue how to use the meta-sourcery layer, and it has no any
> proper documentation about that, nor example, like the Linaro guys nicely
> made one for their solution.
>
>
> On Wed, Jul 24, 2013 at 10:32 PM, Laszlo Papp  wrote:
>
>> Also, it seems to be a bit less lightweight than what we have in oe-core.
>> I would not like to pull unnecessary recipes in. Is it possible to work the
>> oe-core stuff around?
>>
>>
>> On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp  wrote:
>>
>>> I believe the developer story would be simpler with oe-core as opposed
>>> to meta-sourcery. Besides, some documentation would be nice to have how to
>>> use it, how it will work alongside the oe-core "example", and so forth.
>>>
>>> You know, something similar to what the Linaro people seem to have.
>>>
>>>
>>> On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson wrote:
>>>
 On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson >>> > wrote:

> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp  wrote:
>
>> is this officially supported by the Yocto project? I would not like
>> to use Yocto for my own purposes if it is something unsupported, and I
>> would need to put a significant investment into to it to make the 
>> releases
>> buildable, et cetera.
>>
>
 I'm not certain as to the official Yocto support stance on
 external-sourcery as it exists in or-core at this time, but if you do want
 to use the Sourcery G++ toolchain rather than one of the alternatives
 suggested by others in this thread, you can use the meta-sourcery layer,
 which while it isn't officially supported by Yocto, is officially supported
 by Mentor Graphics, the company which provides the aforementioned 
 toolchain.
  --
 Christopher Larson
 clarson at kergoth dot com
 Founder - BitBake, OpenEmbedded, OpenZaurus
 Maintainer - Tslib
 Senior Software Engineer, Mentor Graphics

>>>
>>>
>>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Discovering available Perl modules OR writing recipes for your own

2013-07-25 Thread mulhern
Thanks, but that specific module isn't the whole total of my problem. It's
nice of you to point out for me the location of that one but what about the
more like 15 or so others I didn't list and where they might or might not
be hiding? Should that particular module really be in the meta-security
layer just because it is meta-security that needed it first? Generally
speaking, openssl is really just a networking thing, I think.

My real problem is not that particular module it's that
1) I don't know a good way to find out if all those modules that I need
haven't already been packaged up by someone somewhere.
2) I'm not certain that writing a separate recipe for each and every one of
those little modules is the correct way to go about getting them all if
they aren't already available somewhere.

I guess my third question regarding naming conventions is sort of answered
by examples.

- mulhern




On Thu, Jul 25, 2013 at 7:52 AM, Trevor Woerner
wrote:

> On 24 July 2013 11:30, mulhern  wrote:
> > pulledpork tries to use the module Crypt::SSLeay and in my current
> > configuration it can't find it.
>
> It looks like this module has a recipe in the meta-security layer:
> http://layers.openembedded.org/layerindex/recipes/?q=perl
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Discovering available Perl modules OR writing recipes for your own

2013-07-25 Thread Paul Eggleton
Hi mulhern,

On Thursday 25 July 2013 09:25:04 mulhern wrote:
> Thanks, but that specific module isn't the whole total of my problem. It's
> nice of you to point out for me the location of that one but what about the
> more like 15 or so others I didn't list and where they might or might not
> be hiding? Should that particular module really be in the meta-security
> layer just because it is meta-security that needed it first? 

I think the problem is we still don't have a good home for perl recipes not 
needed by anything in OE-Core but that are still useful. I am aware that a 
community member is working on a large number of perl recipes for CPAN modules 
(Stygia on IRC) but I'm not sure what the current status of that work is.

> My real problem is not that particular module it's that
> 1) I don't know a good way to find out if all those modules that I need
> haven't already been packaged up by someone somewhere.

The best way we have for finding these is the recipe search function in the OE 
layer index:

http://layers.openembedded.org/layerindex/recipes/

> 2) I'm not certain that writing a separate recipe for each and every one of
> those little modules is the correct way to go about getting them all if
> they aren't already available somewhere.

This is the convention we have established. Hopefully with what's in OE-Core, 
meta-security and what's coming in the new layer I referred to above we'll on 
our way to a sizable portion of the packages available. It might be worth 
pinging Stygia to find out how work is going on that layer.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] FW: Regarding offline build

2013-07-25 Thread Amit Kumar
Hi,
 I am still struggling to build the yocto project offline. Please find 
below the details of DL_DIR after the "bitbake -c fetchall core-image-minimal" 
step.
If anyone have idea about this, please guide me.

Thanks & Regards
Amit K


From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] On Behalf 
Of Amit Kumar [amit.ku...@lntinfotech.com]
Sent: Wednesday, July 24, 2013 10:05 PM
To: Gary Thomas; yocto@yoctoproject.org
Subject: Re: [yocto] FW:  Regarding offline build

> Hi,
>   I have tried the steps suggested by Mr. Paul.
> But still i am facing an error to build yocto project offline.
> First - I use the machine that have full Internet access and execute the  - 
> bitbake -c fetchall core-image-minimal Before that i have enabled the DL_DIR 
> in conf/local.conf file.
>
> One the fetching done, i remove the internet and build the image - bitbake -k 
> core-image-minimal But still i am facing an error, some packages still 
> required internet access during build.
>
> Please find the attached error log with this mail.
> Please let me know if i missed out any step.

This process should have worked.  What files were in your DL_DIR at
the end of the fetchall step?



  After the end of fetchall step.. the files avaliable under the download 
is -

amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build$ cd downloads/
backport/debian/  eglibc-2.17/ etc/ git2/licenses/
share/
amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build$
///

Check again after the build error -


amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build/downloads$ ls
0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch.done  
host.conf.done
0001-eglibc-menuconfig-support.patch.done 
hostname.sh.done
0001-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch.donehosts.done
0001-Fixing-keyboard_force_release.sh-shell-script-path.patch.done
hwclock.sh.done
0001-libffi-update-for-3.0.11.patch.done  
improve_auto_header_gen.patch.done
0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch.done  
inetd.conf.done
0001-man-disable-man-page-generation-because-we-don-t-hav.patch.done  inetd.done
0001-R_ARM_TLS_DTPOFF32.patch.doneinit.done
0002-eglibc-menuconfig-hex-string-options.patch.done  
initgroups_keys.patch.done
0003-eglibc-menuconfig-build-instructions.patch.done  
inittab.done
04-default-is-optimized.patch.done
input.patch.done
05-enable-ctypes-cross-build.patch.done   
inputrc.done
06-ctypes-libffi-fix-configure.patch.done 
install.patch.done
100-uclibc-conf.patch.done
interfaces.done
10-distutils-fix-swig-parameter.patch.done
int-is-not-the-same-size-as-size_t.patch.done
11-distutils-never-modify-shebang-line.patch.done 
IO-acquire-lock-fix.patch.done
12-distutils-prefix-is-inside-staging-area.patch.done issue.done
187b7b1646ee.patch.done   
issue.net.done
200-uclibc-locale.patch.done  
kconfig-frontends-3.8.0.0.tar.xz
203-uclibc-locale-no__x.patch.done
kconfig-frontends-3.8.0.0.tar.xz.done
204-uclibc-locale-wchar_fix.patch.done
ldflags.patch.done
205-uclibc-locale-update.patch.done   
lib-build-fix.patch.done
301-missing-execinfo_h.patch.done 
libcap2_2.22.orig.tar.gz
302-c99-snprintf.patch.done   
libcap2_2.22.orig.tar.gz.done
303-c99-complex-ugly-hack.patch.done  
libffi-3.0.11.tar.gz
304-index_macro.patch.done
libffi-3.0.11.tar.gz.done
305-libmudflap-susv3-legacy.patch.done
libgcc-sjlj-check.patch.done
306-libstdc++-namespace.patch.done
libgcrypt-1.5.0.tar.gz
64bithack.patch.done  
libgcrypt-1.5.0.tar.gz.done
740-sh-pr24836.patch.done 
libgpg-error-1.11.tar.bz2
800-arm-bigendian.patch.done  
libgpg-error-1.11.tar.bz2.done
aarch64-adding-build-support.patch.done   
libiberty_path_fix.patch.done
ac_config_links.patch.done
libmpc_fix_for_automake-1.12.patch.done
acinclude.m4.done  

Re: [yocto] Discovering available Perl modules OR writing recipes for your own

2013-07-25 Thread Trevor Woerner
On 25 July 2013 09:25, mulhern  wrote:
> It's
> nice of you to point out for me the location of that one but what about the
> more like 15 or so others I didn't list and where they might or might not be
> hiding?

I was hoping you'd notice that there is a web-based search tool you
can use to try to find various already-written recipes:
http://layers.openembedded.org/layerindex/

If you can't find a module you're interested in through that interface
then you'll have to write it yourself (and hopefully contribute it
back to the community) :-)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] External toolchain (sourcery)

2013-07-25 Thread Laszlo Papp
TCMODE = "external-csl"
EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"
TARGET_PREFIX = "arm-none-linux-gnueabi-"

INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags"

PREFERRED_PROVIDER_linux-libc-headers = "external-sourcery-toolchain"
PREFERRED_PROVIDER_linux-libc-headers-dev = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_libgcc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_eglibc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libintl = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libiconv = "external-sourcery-toolchain"
PREFERRED_PROVIDER_glibc-thread-db = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/linux-libc-headers =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/linux-libc-headers-dev =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_gdbserver = "external-sourcery-toolchain"

For the setup above, I am getting the error below:

bitbake core-image-minimal
Pseudo is not present but is required, building this first before the main
build
Parsing recipes: 100%
|##|
Time: 00:00:27
Parsing of 831 .bb files complete (0 cached, 831 parsed). 1140 targets, 51
skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "arch-rolling"
TARGET_SYS= "arm-foo-linux-gnueabi"
MACHINE   = "foo"
DISTRO= "foo"
DISTRO_VERSION= "0.1"
TUNE_FEATURES = "armv5 thumb dsp"
TARGET_FPU= "soft"
meta
meta-yocto
meta-yocto-bsp= "master:3d4147a43126a7b031ac583221012442dde7beab"
meta-sourcery = "master:832ce1937780bbb508050f02ac8a8bf309045fef"
meta-foo  = "master:3d4147a43126a7b031ac583221012442dde7beab"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be rerun
and all succeeded.
Loading cache: 100%
||
ETA:  00:00:00
Loaded 1141 entries from dependency cache.

Build Configuration:
BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "arch-rolling"
TARGET_SYS= "arm-foo-linux-gnueabi"
MACHINE   = "foo"
DISTRO= "foo"
DISTRO_VERSION= "0.1"
TUNE_FEATURES = "armv5 thumb dsp"
TARGET_FPU= "soft"
meta
meta-yocto
meta-yocto-bsp= "master:3d4147a43126a7b031ac583221012442dde7beab"
meta-sourcery = "master:832ce1937780bbb508050f02ac8a8bf309045fef"
meta-foo  = "master:3d4147a43126a7b031ac583221012442dde7beab"

NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 141 of udev not available (for item udev)
NOTE: versions of udev available: 182
NOTE: preferred version 141 of udev not available (for item udev-dev)
NOTE: versions of udev available: 182
NOTE: preferred version 141 of udev not available (for item udev-utils)
NOTE: versions of udev available: 182
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.7.tar.bz2,
attempting MIRRORS if available
No currently running tasks (83 of 1366)
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
ERROR: Function failed: do_install (see
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.25593
for further information)
ERROR: Logfile of failure stored in:
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.25593
Log data follows:
| ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
| DEBUG: Executing shell function do_install
| cp: target
'/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0

Re: [yocto] Discovering available Perl modules OR writing recipes for your own

2013-07-25 Thread mulhern
On Thu, Jul 25, 2013 at 10:22 AM, Trevor Woerner
wrote:

> On 25 July 2013 09:25, mulhern  wrote:
> > It's
> > nice of you to point out for me the location of that one but what about
> the
> > more like 15 or so others I didn't list and where they might or might
> not be
> > hiding?
>
> I was hoping you'd notice that there is a web-based search tool you
> can use to try to find various already-written recipes:
> http://layers.openembedded.org/layerindex/


I did. It's only as good as the occasionally inaccurate description
strings, though. I was hoping for something more programmatic and less
susceptible to programmer error.

>
> If you can't find a module you're interested in through that interface
> then you'll have to write it yourself (and hopefully contribute it
> back to the community) :-)
>

I'm interning for Yocto this summer, so I think that withholding isn't an
option ;) But I don't want to litter the project with unnecessary and
redundant recipe files.

- mulhern
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] FW: Regarding offline build

2013-07-25 Thread Paul Eggleton
Hi Amit,

On Thursday 25 July 2013 19:46:27 Amit Kumar wrote:
>  I am still struggling to build the yocto project offline. Please find
> below the details of DL_DIR after the "bitbake -c fetchall
> core-image-minimal" step. If anyone have idea about this, please guide me.

I can see at least xz-5.1.2alpha.tar.gz is missing from your downloads 
directory. I think I know why this might be happening, but for the moment 
you'll just need to run this on the download machine and then copy over the 
downloads directory again:

  bitbake -c fetch xz-native unzip-native

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-intel] Boot failure when using meta-intel and meta-ivi

2013-07-25 Thread Tom Zanussi
On Thu, 2013-07-25 at 11:00 +0200, Felix01 Fischer wrote:
> Hi, 
> I haven written regarding this issues before. So maybe it sounds
> familiar :-)
> 
> I'm unable to produce a booting image when combining a machine from
> the meta-intel layer with "DISTRO ?= "poky-ivi-systemd" from the
> meta-ivi layer.
> You will find a photograph of my screen attached, but I will describe
> the error anyway. 
> 
> 
> Which error do I get? 
> 
> When I'm booting my image the machine fails to boot. The relevant
> information (IMHO) are the lines:
>/init: line 98: mount: not found 
> /init: line 98: mount: not found 
> /init: line 98: mount: not found 
> and 
> cat: can't open '/proc/cmdline': No such file or directory 
> Waiting for removable media... 
> 
> 
> When does the error occur?
> 
> Every image built with the local.conf options 
> MACHINE ?= "crownbay"ORMACHINE ?= "chiefriver" 
> AND 
> DISTRO ?= "poky-ivi-systemd" 
> 
> failed to boot. 
> 
I guess more information is needed to even build this.  Using the poky
commit id in the README, using either meta-intel/master or
meta-intel/dylan gives errors like this:

trz@elmorro:/usr/local/dev/yocto/ivi-test/build$ bitbake foton-image
Pseudo is not present but is required, building this first before the
main build
Loading cache: 100% |###| ETA:
00:00:00
Loaded 1162 entries from dependency cache.
ERROR: No recipes available for:
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-extended/common-api/dbus_1.6.10.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/dbus/dbus_1.6.10.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-connectivity/connman/connman_1.15.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-graphics/xorg-xserver/xserver-xorg_1.14.0.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/busybox/busybox_1.21.1.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/eglibc/eglibc_2.18.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-qt/qt4/qt4-embedded_4.8.5.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-intel/common/recipes-graphics/mesa/mesa_9.0.2.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/netbase/netbase_5.1.bbappend
ERROR: Command execution failed: Exited with 1

So, please supply the relevant commits for all layers used..

> I have tried builds with meta-ivi excalibur (not 100% sure) and foton
> releases and the master branch aswell 
> Similar applies to poky and meta-intel. I tried the danny and dylan
> releases and the master branch. 
> 
> The boot happens from an USB stick on which I dd'ed
> "foton-image-$MACHINE-$BUILDDATE.hddimg" 
> 
> All other builds are booting fine.
> 
> Addind "EXTRA_IMAGE_FEATURE = "udev-extraconf" did not change this
> behauviour. 
> 
> Building only with meta-intel OR meta-ivi results in a booting image.
> 
Not sure what this means - if using only meta-ivi, which machine are you
building?

Tom


> So, any ideas?
> 
> regards,
> 
> Viele Grüße
> 
> Felix Fischer
> 
> Studentischer Mitarbeiter (VC-D1)
> Vehicle Cockpit Electronics Devices
> 
> IAV GmbH
> Carnotstr. 1
> 10587 BERLIN
> GERMANY
> 
> Phone: +49 30 39978-9540
> Fax:  +49 30 39978-9411
> E-Mail:  
> Internet: http://www.iav.com
> 
> Sitz/Registered Office: Berlin, 
> Registergericht/Registration Court: Amtsgericht Charlottenburg, 
> Registernummer/Company Registration Number: HRB 21 280, 
> Geschäftsführer/Managing Directors: Kurt Blumenröder, Michael
> Schubert, Dr. Rüdiger Goyk
> ___
> meta-intel mailing list
> meta-in...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] How to enable UDHCP?

2013-07-25 Thread Paul D. DeRocco
My build is an Intel Cedartrail system based on Dylan, using systemd. It
appears to have udhcp available from busybox, but it's not running. systemd
reports that it is "masked", because
/etc/systemd/system/busybox-udhcpc.service is linked to /dev/null. What
creates this link, and how do I get the DHCP client enabled in my build? Is
there something else I need to include?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
 

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Detecting build type within recipe (target, native or nativesdk)

2013-07-25 Thread Christian Gagneraud

Hi there,

Is there a way to detect what kind of build is going on (target, native 
or nativesdk) from within a recipe or a class?


Basically when using 'BBCLASSEXTEND = "native nativesdk"', how can I 
tweak the build behaviour depending of the build type?


Does anyone know an example recipe I could use as a reference for doing 
these kind of things?


Regards,
Chris
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Detecting build type within recipe (target, native or nativesdk)

2013-07-25 Thread ChenQi

On 07/26/2013 07:57 AM, Christian Gagneraud wrote:

Hi there,

Is there a way to detect what kind of build is going on (target, 
native or nativesdk) from within a recipe or a class?


Basically when using 'BBCLASSEXTEND = "native nativesdk"', how can I 
tweak the build behaviour depending of the build type?


Does anyone know an example recipe I could use as a reference for 
doing these kind of things?


Regards,
Chris
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



1. Use suffixes such as _class-native, _class-target, etc.
I think this is the preferred way.
Please grep the repo for more info.

2. Use ${PN} value.
e.g. (from dpkg.inc)
do_install_append () {
if [ "${PN}" = "dpkg-native" ]; then
# update-alternatives doesn't have an offline mode
rm ${D}${bindir}/update-alternatives
sed -i -e 
's|^#!.*${bindir}/perl-native.*/perl|#!/usr/bin/env nativeperl|' 
${D}${bindir}/dpkg-*

else
mv ${D}${bindir}/update-alternatives ${D}${sbindir}
sed -i -e 
's|^#!.*${bindir}/perl-native.*/perl|#!/usr/bin/env perl|' 
${D}${bindir}/dpkg-*

fi
}

Best Regards,
Chen Qi

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto