Re: [yocto] How to suppress error: canonicalization unexpectedly shrank by one character
Hi, This should help I guess, http://lists.openembedded.org/pipermail/openembedded-core/2013-April/077607.html Also just a thought, can you please check in your package that you are building, whether there is instances of double forward slash which may cause split_and_strip_files to fail in do_package?? -JC On Thu, Sep 25, 2014 at 12:49 AM, wrote: > Hi Guys, > > I keep getting an error at do_package stage regarding the debug edit > function: > > ERROR: canonicalization unexpectedly shrank by one character > > I removed the rpaths inclusion in my libs but the error is still there. > Is there a way to suppress this check? > > Thanks > > If you are not the addressee, please inform us immediately that you have > received this e-mail by mistake, and delete it. We thank you for your > support. > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- JCP -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Herp-a-Derp Alert: Changes to SRCREV Unpack Wrong Version
On Wed, Sep 24, 2014 at 03:04:46PM -0700, Leo Schwab wrote:
> I suspect this is a common issue, but my Google-fu has gotten me no closer
> to understanding what I might be doing wrong, so here goes:
>
> We have written recipes for various goodies -- both .bb and .bbappend forms
> -- where SRC_URI points to a Git repository, and SRCREV names a commit ID
> (not a tag or a branch name). When we update the SRCREV to something
> newer, 'bitbake' goes through the motions of rebuilding the recipe but,
> when we look at the result, the thing it built is still the old revision.
> This is confirmed when we look at the file 'log.do_unpack' in the build
> directory, where it is clearly checking out the wrong commit ID.
>
> I've tried fiddling around various ways with SRC_URI and SRCREV, but the
> problem persists. All our SRC_URIs have a 'branch=' parameter, and the
> SRCREV points to a commit ID on that branch. I've tried adding a
> 'name=blah' parameter to the SRC_URI, and then declaring SRCREV_blah, but
> that doesn't seem to help, either. We do not do anything with ${PV} or
> ${PR} in our recipes.
>
> In short, from where is the do_unpack step getting the SRCREV it's passing
> to 'git checkout'? How can I trigger a rebuild using the value named in
> the recipe when SRCREV is updated? We are using Yocto 1.6.1 (Dora).
Include SRCPV in your PV, otherwise do_fetch signature won't be changed
when you change just SRCREV so it won't update it for you.
You can also add it explicitly
do_fetch[vardeps] += "SRCREV"
but having +git${SRCPV} in PV has the advantage that you'll also see
from package name what revision was used to build it and
package management could be used to do upgrades on target.
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Herp-a-Derp Alert: Changes to SRCREV Unpack Wrong Version
On 24 September 2014 23:04, Leo Schwab wrote: > We have written recipes for various goodies -- both .bb and .bbappend forms > -- where SRC_URI points to a Git repository, and SRCREV names a commit ID > (not a tag or a branch name). When we update the SRCREV to something newer, > 'bitbake' goes through the motions of rebuilding the recipe but, when we > look at the result, the thing it built is still the old revision. This is > confirmed when we look at the file 'log.do_unpack' in the build directory, > where it is clearly checking out the wrong commit ID. I've never seen this before and there's many git-based recipes in oe-core that the fetcher appears to be working for. Can you replicate this behaviour with a minimal recipe that you could share? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Herp-a-Derp Alert: Changes to SRCREV Unpack Wrong Version
I suspect this is a common issue, but my Google-fu has gotten me no closer
to understanding what I might be doing wrong, so here goes:
We have written recipes for various goodies -- both .bb and .bbappend forms
-- where SRC_URI points to a Git repository, and SRCREV names a commit ID
(not a tag or a branch name). When we update the SRCREV to something
newer, 'bitbake' goes through the motions of rebuilding the recipe but,
when we look at the result, the thing it built is still the old revision.
This is confirmed when we look at the file 'log.do_unpack' in the build
directory, where it is clearly checking out the wrong commit ID.
I've tried fiddling around various ways with SRC_URI and SRCREV, but the
problem persists. All our SRC_URIs have a 'branch=' parameter, and the
SRCREV points to a commit ID on that branch. I've tried adding a
'name=blah' parameter to the SRC_URI, and then declaring SRCREV_blah, but
that doesn't seem to help, either. We do not do anything with ${PV} or
${PR} in our recipes.
In short, from where is the do_unpack step getting the SRCREV it's passing
to 'git checkout'? How can I trigger a rebuild using the value named in
the recipe when SRCREV is updated? We are using Yocto 1.6.1 (Dora).
Thanks,
Schwab
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Configure Issue
I'm tyring to make an updated version of the postgresql recipe, and I'm getting a pretty stubborn error. The build machine is running Ubuntu 12.04, and I'm using the scripts from https://git.congatec.com/yocto/bsp-scripts.git I have altered the postgresql_9.2.4.bb recipe to postgresql_9.3.5.bb. I updated the remove.autoconf.version.check.patch, so I don't get the autoconf version warning anymore. Now do_configure is failing with a perl related error autoreconf: running: gnu-configize Perl lib version (5.14.3) doesn't match executable '/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/bin/autom4te' version (v5.14.2) at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.14.3/Config.pm line 60. Compilation failed in require at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.14.3/File/Copy.pm line 14. BEGIN failed--compilation aborted at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.14.3/File/Copy.pm line 14. Compilation failed in require at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/share/autoconf/Autom4te/FileUtils.pm line 167. BEGIN failed--compilation aborted at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/share/autoconf/Autom4te/FileUtils.pm line 167. Compilation failed in require at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/bin/autom4te line 40. BEGIN failed--compilation aborted at /home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/bin/autom4te line 40. autoreconf: Leaving directory `.' Further down, this stands out | perl_embed_ldflags=' -L/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib -L/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/lib -Wl,-rpath-link,/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/lib -Wl,-rpath,/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/lib -Wl,-O1 -fstack-protector -L/home/yocto-user/yocto/bsp-scripts/build-qmx6/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.14.3/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc' because it contains -L/usr/local/lib I've been trying to figure out how to stop the local system directories from being included, but I'm not sure where to start. Any help is appreciated, thanks in advance. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 9, 2014 8:00 AM US Pacific Time
On 24 September 2014 12:44, Sona Sarmadi wrote: >> As well as security fixes for the kernel, do you also cover security fixes >> for the >> userspace (i.e. everything else in oe-core)? Help keeping the rest of the >> system safe, and relevant fixes backported to the stable releases, is always >> welcome. > > Yes, we monitor oss-security public mailing list, as soon a new vulnerability > (CVE) in the Linux kernel or userspace is announced in that list, we try to > catch them and backport all which are relevant. We look for other sources as > well but oss-securiy (oss-secur...@lists.openwall.com) is a good > source/mailing list/ to detect vulnerabilities in open source products > (kernel & userspace). Well this is convenient timing... I'm sure you've noticed the CVE in bash, will your team be able to submit patches for the releases we are supporting (1.4 onwards)? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
ok, i changed "bootz" to "bootm" and i kept S2 swith pressed.
Yocto not booting, two leds D2, D3 is shining.
Serial console output:
U-Boot SPL 2013.04-dirty (Sep 09 2014 - 21:38:22)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.04-dirty (Sep 09 2014 - 21:38:22)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
527 bytes read in 4 ms (127.9 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading uImage
4368264 bytes read in 499 ms (8.3 MiB/s)
reading /dtbs/am335x-boneblack.dtb
29192 bytes read in 10 ms (2.8 MiB/s)
## Booting kernel from Legacy Image at 8020 ...
Image Name: Linux-3.8.13
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:4368200 Bytes = 4.2 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
OK
Using Device Tree in place at 80f8, end 80f8a207
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
2014-09-13 11:26 GMT+02:00 Diego Sueiro :
>
> On Fri, Sep 12, 2014 at 6:59 PM, TakkTakk wrote:
>>
>> i build core-image-base
>> My uEnv.txt content :
>>
>> kernel_file=uImage
>> console=ttyO0,115200n8
>> mmcroot=/dev/mmcblk0p2 rw
>> mmcrootfstype=ext4 rootwait
>>
>> loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
>> loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
>>
>> mmcargs=setenv bootargs console=${console} root=${mmcroot}
>> rootfstype=${mmcrootfstype} ${optargs}
>> uenvcmd=run loaduimage; run loadfdt; run mmcargs; bootz ${loadaddr} -
>> ${fdtaddr}
>
>
> I think that the problem is the "bootz" command. This command is used to
> boot zImage kernel. Change it to "bootm" and don't forget to keep the S2
> switch pressed.
> But again. With a console serial cable is easier to find what is going
> wrong.
>
>>
>>
>> optargs=quiet drm.debug=7 capemgr.enable_partno=BB-UART4
>> --
>>
>> files inside the FAT partition:
>> uEnv.txt
>> uImage
>> u-boot.img
>> MLO
>> dtbs/am335x-boneblack.dtb
>
>
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> Administrador do Embarcados
> www.embarcados.com.br
>
> /*long live rock 'n roll*/
--
TakTak
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to suppress error: canonicalization unexpectedly shrank by one character
Hi Guys, I keep getting an error at do_package stage regarding the debug edit function: ERROR: canonicalization unexpectedly shrank by one character I removed the rpaths inclusion in my libs but the error is still there. Is there a way to suppress this check? Thanks If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Daisy 1.6.1 - matchbox-keyboard doesn't "pop up" automatically any more
Hi all, with the old Dylan 1.4 the matchbox-keyboard works perfectly and pops up automatically when I open a terminal window, or a web browser, or the notes application, etc. But now, with Daisy 1.6.1 I can start the matchbox-keyboard __ONLY__ if I click manually on the keyboard icon on the matchbox-panel title-bar. It is a big problem in full screen applications (as a web browser in a "kiosk mode", for example). Any idea to solve this issue? Regards, Flavio -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH][meta-selinux] dhcp: remove the unrecognised without-selinux configuration warning
Merged, thanks Roy.
-J.
[[yocto] [PATCH][meta-selinux] dhcp: remove the unrecognised without-selinux
configuration warning] On 14.09.24 (Wed 09:33) rongqing...@windriver.com wrote:
> From: "Roy.Li"
>
> dhcp 4.3 has no selinux related configuration options, but it needs the
> correct initscript when SELinux is enabled, so inherit selinux, not
> inherit with-selinux
>
> Signed-off-by: Roy.Li
> ---
> recipes-connectivity/dhcp/dhcp_4.3.0.bbappend |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
> b/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
> index 900c2aa..2d2232c 100644
> --- a/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
> +++ b/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
> @@ -1,3 +1,3 @@
> -inherit with-selinux
> +inherit selinux
>
> FILESEXTRAPATHS_prepend := "${@target_selinux(d, '${THISDIR}/files:')}"
> --
> 1.7.10.4
>
--
-Joe MacDonald.
:wq
signature.asc
Description: Digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRC_URI parameter: "subdir" does not work for local files
On 24 September 2014 13:50, Vuille, Martin (Martin) wrote: > We have run into the problem fixed by this patch > > http://patchwork.openembedded.org/patch/77027/ > > Will this fix be included in 1.7/Dizzy? This is my fault, I reviewed the patch but failed to follow it up, and then Roxana's internship finished... Except a rewritten patch to hit the list shortly and be merged. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-1.7.rc1 now available.
Hi All, Please let me know whether the release candidate mentioned below with commit is for 1.7M4? Regards, Atul A release candidate build for yocto-1.7.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-intel : a369fa8f2d76528cb296ef9314e613e26585d54d meta-fsl-arm : 2680f54d02fa6efe4cd2aaef7bda9e46cf3e9672 meta-minnow : 238a45e9da8bbfff7a6af220b48c11cabd31e01c meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 meta-fsl-ppc : 478f29c3e97760f2ff443227950ce21d9510a280 poky : 8ac8eca2e3bd8c78e2b31ea974930ed0243258a3 This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder Email: elizabeth.flanagan at intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] tools-sdk with gcc-runtime
Hello. Currently I am trying to build the core-image-full-cmdline with crystalforest-server machine from meta-intel/meta-crystalforest and using Yocto Project 1.6 (daisy) release. I am quite new to yocto so this might be a beginner's mistake. When I install the image-feature "tools-sdk" on my image to use gcc amongst others, it seems like some libs are missing, e.g. libssp.so. I found those in the gcc-runtime package. Unfortunately adding gcc-runtime to IMAGE_INSTALL does not work and displays during bitbake the error: "ERROR: gcc-runtime not found in the base feeds (crystalforest_server corei7-64-intel-common corei7-64 core2-64 x86_64 noarch any all)" Followed by a quite long list of packages. I added those two lines to conf/local.conf EXTRA_IMAGE_FEATURES = "debug-tweaks dev-pkgs tools-sdk ssh-server-openssh package-management" IMAGE_INSTALL_append = " git gcc-runtime " I hope anybody can help me. Best regards Tim Ohliger -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SRC_URI parameter: "subdir" does not work for local files
We have run into the problem fixed by this patch http://patchwork.openembedded.org/patch/77027/ Will this fix be included in 1.7/Dizzy? MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Integration of custom recipe with SDK
Removing integration of meta-toolchain-qte from my image helped in building
qjson as a part of SDK when running bitbake -c populate_sdk -v or
bitbake .
Integration of meta-toolchain-qte might need some more modifications.
Still as a requirement, I need to integrate my custom recipe with
meta-toolchain-qte to generate SDK having custom recipe as a tool. I have
created nativesdk bb file for custom recipe to integrate it via
nativesdk-packagegroup-qte-toolchain-host.bb but no luck..
On Wed, Sep 24, 2014 at 1:14 PM, Navani Srivastava <
navani.srivast...@gmail.com> wrote:
> Yes.. i did...
> On 24 Sep 2014 12:56, "Paul Eggleton"
> wrote:
>
>> On Wednesday 24 September 2014 10:26:41 Navani Srivastava wrote:
>> > I corrected FILES_${PN} and added following in my image recipe-
>> > QTNAME = "qte"
>> > QT_DIR_NAME = "qtopia"
>> > require recipes-qt/meta/meta-toolchain-qt.bb
>> >
>> > but that didn't make any difference related to SDK integration. On
>> > executing 'bitbake -v ', it is generating rootfs and sdk,
>> in
>> > which contains rootfs contains qjson libraries but sdk doesn't integrate
>> > anything.
>>
>> To generate the SDK you'd need to also do bitbake -c populate_sdk
>>
>> - you did do that as well after making the changes to the recipe, right ?
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 9, 2014 8:00 AM US Pacific Time
> As well as security fixes for the kernel, do you also cover security fixes > for the > userspace (i.e. everything else in oe-core)? Help keeping the rest of the > system safe, and relevant fixes backported to the stable releases, is always > welcome. Yes, we monitor oss-security public mailing list, as soon a new vulnerability (CVE) in the Linux kernel or userspace is announced in that list, we try to catch them and backport all which are relevant. We look for other sources as well but oss-securiy (oss-secur...@lists.openwall.com) is a good source/mailing list/ to detect vulnerabilities in open source products (kernel & userspace). /Sona -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Support to install TUN/TAP kernel-module-tun
On 24 September 2014 10:48, Simon Andrieu wrote: > Thanks for your various helpful answers that enable me to understand better > the possible solutions to connect a cellular modem. > > I am first trying the Ofono solution, and came to this message error (dmesg): > Jun 11 09:11:13 igep00x0 daemon.info ofonod[1261]: Modem support (CDC > support: unknown) > Jun 11 09:11:14 igep00x0 daemon.err ofonod[1261]: Missing support for TUN/TAP > devices > > From my search, I have to install the kernel-module-tun module. > Could you help me to know the repository to configure for using zipper and > installing it please? > (Could you also confirm me that installing kernel-module-tun is the right > solution please?) An easier way would be to add it to your image recipe: http://www.yoctoproject.org/docs/1.6.1/mega-manual/mega-manual.html#usingpoky-extend-customimage Although maybe we should be adding a rrecommends on kernel-module-tun to ofono (patch welcome). Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Support to install TUN/TAP kernel-module-tun
Hi, Thanks for your various helpful answers that enable me to understand better the possible solutions to connect a cellular modem. I am first trying the Ofono solution, and came to this message error (dmesg): Jun 11 09:11:13 igep00x0 daemon.info ofonod[1261]: Modem support (CDC support: unknown) Jun 11 09:11:14 igep00x0 daemon.err ofonod[1261]: Missing support for TUN/TAP devices From my search, I have to install the kernel-module-tun module. Could you help me to know the repository to configure for using zipper and installing it please? (Could you also confirm me that installing kernel-module-tun is the right solution please?) Thanks for your help. Regards, Simon Andrieu -Message d'origine- De : Burton, Ross [mailto:ross.bur...@intel.com] Envoyé : vendredi 19 septembre 2014 23:33 À : Simon Andrieu Cc : yocto@yoctoproject.org Objet : Re: [yocto] Poky/Yocto drivers for cellular modem On 18 September 2014 17:39, Simon Andrieu wrote: > Using some Linux distribution, it exists drivers that help recognizing > a cellular modem USB stick and to raise a corresponding network interface. > > Would you know please if such a generic cellular modem driver exists > in Poky/Yocto distribution please? Would connman + ofono be suitable? Ross -Message d'origine- De : Maciej Borzecki [mailto:maciej.borze...@open-rnd.pl] Envoyé : samedi 20 septembre 2014 15:36 À : Simon Andrieu Cc : yocto@yoctoproject.org Objet : Re: [yocto] Poky/Yocto drivers for cellular modem On Thursday 18 of September 2014 16:39:33 Simon Andrieu wrote: > Hi, > > I work for a company that develops telemetry boxes, and that uses a > Poky/Yocto distribution running on the main board. It is planned to > integrate a cellular module connected via USB or serial link to the > main board. > > Using some Linux distribution, it exists drivers that help recognizing > a cellular modem USB stick and to raise a corresponding network interface. > Would you know please if such a generic cellular modem driver exists > in Poky/Yocto distribution please? More further, It could be helpful > to have some tutorial notes to integrate it please. I'm working a similar applications. Most USB devices seem to implement CDC ACM that works quite well with kernel drivers. Basically you end up with one of /dev/ttyACM devices that pppd can talk to. In past, due to image size constraints, we had custom code that looked at these devices (used libudev to correlated /dev entries with usb devices) and started pppd, thus skipping ofono/connman and their deps. The current setups are mostly systemd/systemd-networkd + pppd glue. Without much trouble it's possible to get ~20MB ext3 rootfs image with all the stuff you need. There were also some dongles that came up as CDC Ether, but I've only seen this for some WiMAX modules that I'm not sure are even available on the market anymore. For transport, you can find rabbitmq-c in meta-oe. I'll also be sending some patches for Paho MQTT libraries and mosquitto next week or so. -- Maciej Borzęcki Senior Software Engineer Open-RnD Sp. z o.o. www.open-rnd.pl, Facebook, Twitter mobile: +48 telefon, fax: +48 42 657 9079 Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem lub poufne informacje i została wysłana wyłącznie do wiadomości i użytku osób, do których została zaadresowana. Jeśli wiadomość została otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do osób trzecich. W takim przypadku uprasza się o natychmiastowe zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej sytuacji za pomocą wiadomości zwrotnej. Dziękujemy. This message, including any attachments hereto, may contain privileged or confidential information and is sent solely for the attention and use of the intended addressee(s). If you are not an intended addressee, you may neither use this message nor copy or deliver it to anyone. In such case, you should immediately destroy this message and kindly notify the sender by reply email. Thank you. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Waylandsink creating new video window and not destroying previous open window.
On 24 September 2014 07:44, Meenakumari Shedole wrote: > Gstreamer constructed Video Pipe is working with waylandsink but every time > waylandsink is creating new video window also waylandsink is not destroying > the existing video windows. It's probably beset to speak to the wayland and/or gstreamer community about this. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 9, 2014 8:00 AM US Pacific Time
Hi Sona, On 24 September 2014 08:30, Sona Sarmadi wrote: > My name is Sona Sarmadi, and I am responsible for security for the Enea Linux > & related opens source products which is based on Yocto. Together with some > other colleagues (Maxin John, Daniel Bornaz ..) we take care of security > patches (i.e. backport them from stable kernels to our kernels if they have > not already fixed by Yocto or meta-vendors maintainers (such as meta-fsl-ppc, > meta-fsl-arm, meta-ti, meta xilinx …). As well as security fixes for the kernel, do you also cover security fixes for the userspace (i.e. everything else in oe-core)? Help keeping the rest of the system safe, and relevant fixes backported to the stable releases, is always welcome. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Difference of i586-poky and i686-pokysdk in SDK sysroots
Good day Yocto Community, I would like to ask a very simple question, what is the difference of i586-poky and i686-pokysdk in SDK sysroots? Does a BBCLASSEXTEND="native" install the package in SDK i586-poky and BBCLASSEXTEND="nativesdk" on the other? Sorry for such a dumb question. But would just want to know the best practice on where is a package most appropriate to put into in SDK. Looking forward to your responses. Thanks, Joseph -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-1.7.rc1 now available.
A release candidate build for yocto-1.7.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-intel : a369fa8f2d76528cb296ef9314e613e26585d54d meta-fsl-arm : 2680f54d02fa6efe4cd2aaef7bda9e46cf3e9672 meta-minnow : 238a45e9da8bbfff7a6af220b48c11cabd31e01c meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 meta-fsl-ppc : 478f29c3e97760f2ff443227950ce21d9510a280 poky : 8ac8eca2e3bd8c78e2b31ea974930ed0243258a3 This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder Email: elizabeth.flana...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Integration of custom recipe with SDK
Yes.. i did...
On 24 Sep 2014 12:56, "Paul Eggleton" wrote:
> On Wednesday 24 September 2014 10:26:41 Navani Srivastava wrote:
> > I corrected FILES_${PN} and added following in my image recipe-
> > QTNAME = "qte"
> > QT_DIR_NAME = "qtopia"
> > require recipes-qt/meta/meta-toolchain-qt.bb
> >
> > but that didn't make any difference related to SDK integration. On
> > executing 'bitbake -v ', it is generating rootfs and sdk, in
> > which contains rootfs contains qjson libraries but sdk doesn't integrate
> > anything.
>
> To generate the SDK you'd need to also do bitbake -c populate_sdk
>
> - you did do that as well after making the changes to the recipe, right ?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 9, 2014 8:00 AM US Pacific Time
Nice to meet you guys in the meeting ☺ Short background: My name is Sona Sarmadi, and I am responsible for security for the Enea Linux & related opens source products which is based on Yocto. Together with some other colleagues (Maxin John, Daniel Bornaz ..) we take care of security patches (i.e. backport them from stable kernels to our kernels if they have not already fixed by Yocto or meta-vendors maintainers (such as meta-fsl-ppc, meta-fsl-arm, meta-ti, meta xilinx …). We prefer help yocto community and backport securtiy patches from stable kernels to Yocto rather than doing this work inside Enea repo in the meta-enea layer. I know that Yocto has well defined process for backporting security patches from stable kernels to Yocto kernels which is good, but I haven’t figured out if there is well defined process as well for vendor kernels such as meta-xilinx or meta-ti (meta-xil...@yoctoproject.org, meta...@yoctoproject.org, etc ..)? I see that sometimes security patches have been backported to these kernels but not always. I just wonder if there is anything we can help here. Any suggestion for helping Yocto community within security are welcome. Cheers /Sona From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Jolley, Stephen K Sent: den 23 september 2014 17:25 To: yocto@yoctoproject.org Subject: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 9, 2014 8:00 AM US Pacific Time Attendees: Armin, Stephen, Joe, Alex V., Paul, Tom, Belen, Ross, Matthew, Bruce, Michael, Alex, Richard, Saul, Benjamin, Anibal, Sona, * Opens collection - 5 min (Stephen) * Yocto Project status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.7_Status https://wiki.yoctoproject.org/wiki/Yocto_1.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.7_Features YP 1.7 M3 rc2 is ready for release – to be released this week. We are in m4 the stabilization milestone for 1.7. 1.7 is on track for October release. YP 1.6.2 will be release shortly after 1.7 is completed YP 1.5.4 will be release shortly after 1.7 is completed Beginning planning for 1.8 – If there are features you would like to have or contribute, get enhancement bug requests into bugzilla for them. * SWAT team rotation: Nitin -> Beth https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team * Opens - 10 min Richard - There have been changes to the tool chain/SDK/ADT environment scripts to fix bugs, testing in that area would be appreciated * Team Sharing - 10 min Michael – Doing some server work today. It shouldn’t interfere with anything. Sona – Willing to help on Security for Yocto. Would like to contribute Yocto. Suggestions are welcome on where to help. Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 I Work Telephone: (503) 712-0534 ( Cell: (208) 244-4460 ((Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Integration of custom recipe with SDK
On Wednesday 24 September 2014 10:26:41 Navani Srivastava wrote:
> I corrected FILES_${PN} and added following in my image recipe-
> QTNAME = "qte"
> QT_DIR_NAME = "qtopia"
> require recipes-qt/meta/meta-toolchain-qt.bb
>
> but that didn't make any difference related to SDK integration. On
> executing 'bitbake -v ', it is generating rootfs and sdk, in
> which contains rootfs contains qjson libraries but sdk doesn't integrate
> anything.
To generate the SDK you'd need to also do bitbake -c populate_sdk
- you did do that as well after making the changes to the recipe, right ?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
