Re: [yocto] creating images which include actively developed applications
Dell - Internal Use - Confidential We use the google android repo tool plus 'externalsrc' to great effect. 3 generations now, across now 6-ish different products and dozens of releases at this point. It checks out poky, our layer, our source mirror, and our internal sources all at once. -- Michael -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Paul Eggleton Sent: Tuesday, May 05, 2015 3:32 AM To: Trevor Woerner Cc: yocto@yoctoproject.org Subject: Re: [yocto] creating images which include actively developed applications On Friday 01 May 2015 16:25:38 Trevor Woerner wrote: On 04/22/15 13:58, Paul Eggleton wrote: On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote: Is there a way to create a recipe to build actively developed code located in an external source directory? Basically skip the fetch and unpack steps and always execute the compile and populate steps each time and image is built? Indeed there is: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html# buildi ng-software-from-an-external-source Paul, I'm surprised you suggested externalsrc instead of just mentioning devtool right from the start (doubly-surprised since you're the person who wrote devtool!). Using devtool the administration (of creating a recipe, etc) is done for you, no? http://twoerner.blogspot.ca/2015/01/the-yocto-project-introducing-devt ool.ht ml Well, I would have, except this doesn't quite seem like the same case as devtool is designed for (which is temporary switching of the source for development - AIUI Brian was looking for something more permanent.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Git clone over http broken on git.yoctoproject.org
Local cntlm proxy pointing at corporate MS proxy. I tried two git versions. One is the base git version in CentOS 6.3, the other from the yocto 1.5 buildtools tarball. It looks like the newer git version works and the older one does not. I'll just use A) the newer git version, and B) https. Base CentOS version: $ git --version git version 1.7.1 $ git clone http://git.yoctoproject.org/git/poky.git Initialized empty Git repository in /home/michael_e_brown/yocto/poky/.git/ error: RPC failed; result=52, HTTP code = 100 Yocto 1.5 buildtools version: $ git --version git version 1.8.3.4 $ git clone http://git.yoctoproject.org/git/poky.git Cloning into 'poky'... remote: Counting objects: 215358, done. remote: Compressing objects: 100% (54081/54081), done. remote: Total 215358 (delta 156744), reused 215022 (delta 156422) Receiving objects: 100% (215358/215358), 98.12 MiB | 836.00 KiB/s, done. Resolving deltas: 100% (156744/156744), done. Checking connectivity... done Looks like newer git works ok. -- Michael From: Daniel Stenberg [dan...@haxx.se] Sent: Friday, December 13, 2013 8:46 AM To: Brown, Michael E Cc: mich...@yoctoproject.org; yocto@yoctoproject.org Subject: Re: [yocto] Git clone over http broken on git.yoctoproject.org On Thu, 12 Dec 2013, michael_e_br...@dell.com wrote: HOWEVER, if I use https instead of http, it all WORKS OK. NOTE: Some repos work over http, some don't. Working: meta-selinux, yocto-autobuilder, for example. You're using a HTTP proxy, right? I suspect the http vs https difference is then simply because git will use completely different ways to go through the proxies for the different protocols. git clone --mirror http://git.yoctoproject.org/git/poky.git Initialized empty Git repository in /home/michael_e_brown/yocto/poky.git/ error: RPC failed; result=52, HTTP code = 100 I think this means that git gets a HTTP 100 continue response back but then nothing else, which indicates a problem in your network or proxy. Can you use git fine over this http+proxy against other git repos out in the wild? Which git + libcurl versions are you using? -- / daniel.haxx.se ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Git clone over http broken on git.yoctoproject.org
I'm having the same issue now with: http://git.yoctoproject.org/git/meta-intel.git http://git.yoctoproject.org/git/meta-intel-contrib.git http://git.yoctoproject.org/git/poky.git HOWEVER, if I use https instead of http, it all WORKS OK. NOTE: Some repos work over http, some don't. Working: meta-selinux, yocto-autobuilder, for example. Same configuration. Locally pulling http which is running over a CNTLM proxy and then through our corporate Microsoft Proxy. Failures all look like: git clone --mirror http://git.yoctoproject.org/git/poky.git Initialized empty Git repository in /home/michael_e_brown/yocto/poky.git/ error: RPC failed; result=52, HTTP code = 100 Success looks like: git clone --mirror https://git.yoctoproject.org/git/poky.git Initialized empty Git repository in /home/michael_e_brown/yocto/poky.git/ remote: Counting objects: 215240, done. remote: Compressing objects: 100% (54010/54010), done. Receiving objects: 28% (60268/215240), 19.96 MiB | 818 KiB/s ... cut ... -- Michael From: Michael Halstead [mhalst...@linuxfoundation.org] On Behalf Of Michael Halstead [mich...@yoctoproject.org] Sent: Tuesday, November 26, 2013 10:16 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Git clone over http broken on git.yoctoproject.org On 11/25/2013 01:32 PM, michael_e_br...@dell.com wrote: Several repositories have broken git pulls over http on git.yoctoproject.org. Working: $ git clone --mirror http://git.yoctoproject.org/git/yocto-kernel-tools Initialized empty Git repository in /home/michael_e_brown/f10/sources/f/yocto-kernel-tools.git/ remote: Counting objects: 1067, done. remote: Compressing objects: 100% (462/462), done. remote: Total 1067 (delta 711), reused 958 (delta 603) Receiving objects: 100% (1067/1067), 273.41 KiB | 251 KiB/s, done. Resolving deltas: 100% (711/711), done. Broken: $ git clone --mirror http://git.yoctoproject.org/git/linux-yocto-3.10 Initialized empty Git repository in /home/michael_e_brown/f10/sources/f/linux-yocto-3.10.git/ error: RPC failed; result=52, HTTP code = 100 Failing with an HTTP continue code is sort of odd. I wonder if you are going through a proxy which could be causing this issue only for larger repos like the kernels. I think the content length header might be wrong or undefined for large objects at the moment which could give certain proxy software trouble. I've tried to correct those headers. Can you test again? I tested with git version 1.7.9.5 and no proxy and was able to clone all the kernels. Michael Halstead Yocto Project / System Administrator All of the kernel pulls appear to be broken in the same way (3.10, 3.8, etc) URLs taken directly from the cgit HTTP url listed. -- Michael ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Git clone over http broken on git.yoctoproject.org
Yes, I am going through a proxy. Thanks for checking. It looks like whatever problem I was having yesterday has been resolved with your fixes. I am able to clone today. Thanks! Michael From: Michael Halstead [mhalst...@linuxfoundation.org] On Behalf Of Michael Halstead [mich...@yoctoproject.org] Sent: Tuesday, November 26, 2013 10:16 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Git clone over http broken on git.yoctoproject.org On 11/25/2013 01:32 PM, michael_e_br...@dell.com wrote: Several repositories have broken git pulls over http on git.yoctoproject.org. Working: $ git clone --mirror http://git.yoctoproject.org/git/yocto-kernel-tools Initialized empty Git repository in /home/michael_e_brown/f10/sources/f/yocto-kernel-tools.git/ remote: Counting objects: 1067, done. remote: Compressing objects: 100% (462/462), done. remote: Total 1067 (delta 711), reused 958 (delta 603) Receiving objects: 100% (1067/1067), 273.41 KiB | 251 KiB/s, done. Resolving deltas: 100% (711/711), done. Broken: $ git clone --mirror http://git.yoctoproject.org/git/linux-yocto-3.10 Initialized empty Git repository in /home/michael_e_brown/f10/sources/f/linux-yocto-3.10.git/ error: RPC failed; result=52, HTTP code = 100 Failing with an HTTP continue code is sort of odd. I wonder if you are going through a proxy which could be causing this issue only for larger repos like the kernels. I think the content length header might be wrong or undefined for large objects at the moment which could give certain proxy software trouble. I've tried to correct those headers. Can you test again? I tested with git version 1.7.9.5 and no proxy and was able to clone all the kernels. Michael Halstead Yocto Project / System Administrator All of the kernel pulls appear to be broken in the same way (3.10, 3.8, etc) URLs taken directly from the cgit HTTP url listed. -- Michael ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Git clone over http broken on git.yoctoproject.org
Several repositories have broken git pulls over http on git.yoctoproject.org. Working: $ git clone --mirror http://git.yoctoproject.org/git/yocto-kernel-tools Initialized empty Git repository in /home/michael_e_brown/f10/sources/f/yocto-kernel-tools.git/ remote: Counting objects: 1067, done. remote: Compressing objects: 100% (462/462), done. remote: Total 1067 (delta 711), reused 958 (delta 603) Receiving objects: 100% (1067/1067), 273.41 KiB | 251 KiB/s, done. Resolving deltas: 100% (711/711), done. Broken: $ git clone --mirror http://git.yoctoproject.org/git/linux-yocto-3.10 Initialized empty Git repository in /home/michael_e_brown/f10/sources/f/linux-yocto-3.10.git/ error: RPC failed; result=52, HTTP code = 100 All of the kernel pulls appear to be broken in the same way (3.10, 3.8, etc) URLs taken directly from the cgit HTTP url listed. -- Michael ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proxy server related package fetching issues
Dell - Internal Use - Confidential For my group, I keep a separate git repository updated with all the required sources. I update the sources offline and set bitbake to not use the network. You can usually download the required sources from the yocto project mirror. -- Michael -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Morgan Sent: Wednesday, November 20, 2013 6:54 PM To: yocto@yoctoproject.org Subject: [yocto] Proxy server related package fetching issues Hello. I've been working to build an angstrom build and have had some issues with our corporate proxy server blocking the fetching of some packages, either because of the protocol/port or because the site was for some reason flagged. In my case it took several hours to determine that the failure wasn't due to a missing file, I tried on another network connection and everything worked. I'm posting here to see if anyone has had similar experience and if so, any details you'd be willing to provide, how you detected/debugged the issue and how long it took, and how you resolved the issue. Thanks, Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Deploying Yocto build images
Thanks for posting this. It's very timely for a project I am in the initial stages of designing. I have looked over the docs and some of the code, and am interested in using this. I would make a couple suggestions: 1) As you mention, documentation is important. Unless this is very well documented, it's difficult for other people to take up and use effectively, or to advocate for its use in a group 2) Progress indications: it's going to be fairly important to build in some way to notify other process about the state of the update. A flexible framework for sharing progress would be very much appreciated. There are a couple scenarios I have, but the main one is a network notification where one device is being updated by another. The updated device should be able to signal update progress to the updater device in a flexible fashion. I haven't looked at the code hard enough to see how difficult this would be to add. -- Michael From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Diego Sueiro Sent: Thursday, November 21, 2013 6:35 AM To: Stefano Babic Cc: yocto@yoctoproject.org Subject: Re: [yocto] Deploying Yocto build images Stefano, This is a really great tool. I'm always developing a new software update tool for each new project, since there are different requirements. As I can see you are dealing with different scenarios, and this is really amazing. I'm already cloning meta-swupdate to test it. Looking at recipes I realized that swupdate is initialized in an sysVinit environment. Did you plan to use systemd too? Maybe I can contribute to this. Thanks for sharing. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ 2013/11/21 Stefano Babic sba...@denx.demailto:sba...@denx.de Hi everybody, in the last ELCE, David point out in his presentation that we should improve how to deploy Yocto images on the target. I did some work this year to provide a reliable way for some customers of us to install Yocto's images in field, and I have published last week the sources. Here the link of the announcement: http://comments.gmane.org/gmane.comp.embedded.eldk/2397 Mainly, it is a tool that can be stored in the rootfs or will be put in a separate initrd image and whose goal is only to update the system. I have tried to describe pros and cons of several different solutions (updating via bootloader ? single copy against dual copy ?) - you can find details in the doc directory in the swupdate repository. Maybe someone of you can find this helpful, and I will be happy if I could get some feedback. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53tel:%2B49-8142-66989-53 Fax: +49-8142-66989-80tel:%2B49-8142-66989-80 Email: sba...@denx.demailto:sba...@denx.de = ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proxy server related package fetching issues
Dell - Internal Use - Confidential
We have a Microsoft proxy server which requires NTLM authentication, and it is
cumbersome in most cases to retrieve sources from the cli tools. Downloading in
a browser helps here, then transferring the files to the git repo. (The 'cntlm'
package can help here). For git repositories using the 'git' protocol, there is
no way to access the files with the proxy, so I normally just download the
tarball from the yocto mirror. For extreme cases, I sometimes download at home
and bring in on a USB stick.
The main point being that the build process has no network access and I
populate everything manually:
#don't really disable all network, as we need network to do sstate
BB_NO_NETWORK = 0
INHERIT += own-mirrors
SOURCE_MIRROR_URL =
file://${TOPDIR}/../sources/file:///\\$%7bTOPDIR%7d\..\sources\
BB_GENERATE_MIRROR_TARBALLS = 1
# this disables everything except premirror
BB_FETCH_PREMIRRORONLY = 1
CONNECTIVITY_CHECK_URIS=
DISABLE_NETWORK_SANITY = 1
-Original Message-
From: Chris Morgan [mailto:cmor...@cybexintl.com]
Sent: Thursday, November 21, 2013 12:26 PM
To: Brown, Michael E; yocto@yoctoproject.org
Subject: Re: Proxy server related package fetching issues
Hi Michael.
You do that because of the same issue where something on the network is
blocking the package fetching? When you say you update the sources offline do
you mean from a home network or something?
Chris
From: michael_e_br...@dell.commailto:michael_e_br...@dell.com
michael_e_br...@dell.commailto:michael_e_br...@dell.com
Date: Thursday, November 21, 2013 at 1:22 PM
To: Chris Morgan cmor...@cybexintl.commailto:cmor...@cybexintl.com,
yocto@yoctoproject.orgmailto:yocto@yoctoproject.org
yocto@yoctoproject.orgmailto:yocto@yoctoproject.org
Subject: RE: Proxy server related package fetching issues
Dell - Internal Use - Confidential
For my group, I keep a separate git repository updated with all the required
sources. I update the sources offline and set bitbake to not use the network.
You can usually download the required sources from the yocto project mirror.
--
Michael
-Original Message-
From: yocto-boun...@yoctoproject.orgmailto:yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Morgan
Sent: Wednesday, November 20, 2013 6:54 PM
To: yocto@yoctoproject.orgmailto:yocto@yoctoproject.org
Subject: [yocto] Proxy server related package fetching issues
Hello.
I've been working to build an angstrom build and have had some issues with our
corporate proxy server blocking the fetching of some packages, either because
of the protocol/port or because the site was for some reason flagged. In my
case it took several hours to determine that the failure wasn't due to a
missing file, I tried on another network connection and everything worked.
I'm posting here to see if anyone has had similar experience and if so, any
details you'd be willing to provide, how you detected/debugged the issue and
how long it took, and how you resolved the issue.
Thanks,
Chris
___
yocto mailing list
yocto@yoctoproject.orgmailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] SH4 build failure fix
I'm presently working on porting the build environment for three existing embedded projects over to use yocto. Unfortunately, the project which has to go first is based on an SH4 chip, which isn't on the officially supported yocto architecture list. I gave the compile a go, and ran into a build error in gcc-cross-intermediate: build-edison-sh4/tmp/sysroots/i686-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-ld: cannot find crti.o: No such file or directory build-edison-sh4/tmp/sysroots/i686-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-ld: cannot find -lc build-edison-sh4/tmp/sysroots/i686-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-ld: cannot find crtn.o: No such file or directory Trying to figure out the source of this build error, I found that base openembedded does compile this package successfully, so I started focusing on the differences. I narrowed the build failure down to this line in gcc-cross4.inc, which is present in openembedded, but absent in yocto/poky: gcc-cross4.inc EXTRA_OECONF_append_sh4 = --with-multilib-list= --enable-incomplete-targets After I added this one line, I was able to sucessfully build a base yocto image for qemu sh4. Is it possible to get this added to the upstream yocto build? -- Michael Brown ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
