If the problems is permission denied, you can try to that all developers change downloaded file's permission (chmod -R g+rw DL_DIR or chmod -R g+r DL_DIR)
If break build, sometimes the downloaded file's permissions to be 0600. Wily Taekhyun Shin ============================================================================= Shin, Taekhyun Associate Research Engineer R&D Center Telechips Inc. Tel : + 82-2-3443-6792(Ext.390) Fax : + 82-2-6424-7793 Mobile : + 82-10-4376-5530 E-mail : [email protected] ============================================================================= This mail and attachments contain confidential information of Telechips Inc. which has its own authority. It is not allowed to disclose,transmit or use this confidential information to the third parties without the prior written consent of Telechips Inc. by any form or means. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents and destroy all copies of the original message. ============================================================================= -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, May 06, 2014 4:00 AM To: [email protected] Subject: yocto Digest, Vol 44, Issue 18 Send yocto mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.yoctoproject.org/listinfo/yocto or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of yocto digest..." Today's Topics: 1. DL_DIR problems (Bollinger, Seth) 2. Re: Migrating LDAT fs_final.sh to Yocto (Khem Raj) 3. Re: Migrating LDAT fs_final.sh to Yocto (Vuille, Martin (Martin)) 4. Re: [AB] PublishLayerTarballs "git archives" the wrong directory (Flanagan, Elizabeth) 5. Re: DL_DIR problems (Christopher Larson) 6. Re: DL_DIR problems (Flanagan, Elizabeth) ---------------------------------------------------------------------- Message: 1 Date: Mon, 5 May 2014 11:40:00 +0000 From: "Bollinger, Seth" <[email protected]> To: "[email protected]" <[email protected]> Subject: [yocto] DL_DIR problems Message-ID: <cf8ce2c0.8c7e%[email protected]> Content-Type: text/plain; charset="Windows-1252" Hello All, We?re trying to share a DL_DIR over NFS so all developers don?t have to re-download source files every time they want to do a clean build. Unfortunately we?re running into problems with lock files that are left behind by (sometimes) terminated processes. This will block users who are trying subsequent builds. How are others approaching this problem? Thanks, Seth ------------------------------ Message: 2 Date: Mon, 5 May 2014 09:34:13 -0700 From: Khem Raj <[email protected]> To: "Vuille, Martin (Martin)" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [yocto] Migrating LDAT fs_final.sh to Yocto Message-ID: <CAMKF1sqYj4=8o3zzmgtdn3111-krx3jb-ohp2q9odfuxjrc...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Mon, May 5, 2014 at 6:34 AM, Vuille, Martin (Martin) <[email protected]> wrote: > Migrating from LDAT to Yocto, and wondering whether > > there is an equivalent to LDAT?s fs_final.sh script? > Don't know what that is but you can use image post processing hooks in yocto to do tweaks to images. see IMAGE_POSTPROCESS_COMMAND > > > The objective is to do some post-processing on the > > rootfs ?tree? before it is packaged into the UBIFS image. > > > > MV > > > -- > _______________________________________________ > yocto mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/yocto > ------------------------------ Message: 3 Date: Mon, 5 May 2014 16:36:01 +0000 From: "Vuille, Martin (Martin)" <[email protected]> To: Khem Raj <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [yocto] Migrating LDAT fs_final.sh to Yocto Message-ID: <30c2d590d16a5c46adfe65219103779820b84...@az-us1exmb03.global.avaya.com> Content-Type: text/plain; charset="utf-8" Exactly what I am looking for. Thanks! MV > -----Original Message----- > From: Khem Raj [mailto:[email protected]] > Sent: May 05, 2014 12:34 PM > To: Vuille, Martin (Martin) > Cc: [email protected] > Subject: Re: [yocto] Migrating LDAT fs_final.sh to Yocto > > On Mon, May 5, 2014 at 6:34 AM, Vuille, Martin (Martin) > <[email protected]> wrote: > > Migrating from LDAT to Yocto, and wondering whether > > > > there is an equivalent to LDAT?s fs_final.sh script? > > > > Don't know what that is but you can use image post processing hooks in > yocto to do tweaks to images. see IMAGE_POSTPROCESS_COMMAND > > > > > > > The objective is to do some post-processing on the > > > > rootfs ?tree? before it is packaged into the UBIFS image. > > > > > > > > MV > > > > > > -- > > _______________________________________________ > > yocto mailing list > > [email protected] > > https://lists.yoctoproject.org/listinfo/yocto > > ------------------------------ Message: 4 Date: Mon, 5 May 2014 09:50:01 -0700 From: "Flanagan, Elizabeth" <[email protected]> To: Jate S <[email protected]> Cc: Yocto Project <[email protected]> Subject: Re: [yocto] [AB] PublishLayerTarballs "git archives" the wrong directory Message-ID: <caphnlpdrt_xynm_jcrauy7x2qt8gvgc_smr0mu-9fnfjbyd...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Fri, May 2, 2014 at 1:16 PM, Jate S <[email protected]> wrote: > I am running off of the master branch. > > I hope this log message is readable. The key is to know that I have a > meta-oe repo in the build directory and that the last line shows it's > running in build instead of build/meta-oe. > > git archive --format=tar HEAD > --prefix=meta-oe-40e0f371f3eb1628655c484feac0cebf810737b4/ | bzip2 -c >> meta-oe-40e0f371f3eb1628655c484feac0cebf810737b4.tar.bz2; md5sum > meta-oe-40e0f371f3eb1628655c484feac0cebf810737b4.tar.bz2 >> > meta-oe-40e0f371f3eb1628655c484feac0cebf810737b4.tar.bz2.md5sum; mkdir > -p /home/jate/tmp/yab/publish/builds/qemux86/20140501-1; rsync -av > meta-oe-40e0f371f3eb1628655c484feac0cebf810737b4.tar.bz2* > /home/jate/tmp/yab/publish/builds/qemux86/20140501-1 > in dir /home/jate/yocto-autobuilder/yocto-slave/qemux86/build > (timeout 100000 secs) > > I think that it should be changing directory to meta-oe, but the code > is just missing that. This happens with all the other repourl's in my > config too. The generated tarballs are of the same size (of poky). You are correct. Patch in the works. -b > > > Cheers > > > - Jate S. -- Elizabeth Flanagan Yocto Project Build and Release ------------------------------ Message: 5 Date: Mon, 5 May 2014 10:41:22 -0700 From: Christopher Larson <[email protected]> To: "Bollinger, Seth" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [yocto] DL_DIR problems Message-ID: <CABcZANm6aOq19bag-1oWNs_88BhaN-dq6hS=pz8eqpvjqve...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Mon, May 5, 2014 at 4:40 AM, Bollinger, Seth <[email protected]>wrote: > We?re trying to share a DL_DIR over NFS so all developers don?t have to > re-download source files every time they want to do a clean build. > Unfortunately we?re running into problems with lock files that are left > behind by (sometimes) terminated processes. This will block users who are > trying subsequent builds. How are others approaching this problem? One option would be to maintain an internal downloads mirror, either populated by an autobuilder or by an rsync after engineer builds to the server hosting it. There'd be duplication in local disk space, but you'd avoid the NFS locking issues. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140505/74c59200/attachment-0001.html> ------------------------------ Message: 6 Date: Mon, 5 May 2014 10:50:35 -0700 From: "Flanagan, Elizabeth" <[email protected]> To: Christopher Larson <[email protected]> Cc: "[email protected]" <[email protected]>, "Bollinger, Seth" <[email protected]> Subject: Re: [yocto] DL_DIR problems Message-ID: <caphnlpdcn6-stkbr2rsvynqbgg6z7+ijmzlfhkijhuxs8wl...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Mon, May 5, 2014 at 10:41 AM, Christopher Larson <[email protected]> wrote: > On Mon, May 5, 2014 at 4:40 AM, Bollinger, Seth <[email protected]> > wrote: >> >> We?re trying to share a DL_DIR over NFS so all developers don?t have to >> re-download source files every time they want to do a clean build. >> Unfortunately we?re running into problems with lock files that are left >> behind by (sometimes) terminated processes. This will block users who are >> trying subsequent builds. How are others approaching this problem? > > > One option would be to maintain an internal downloads mirror, either > populated by an autobuilder or by an rsync after engineer builds to the > server hosting it. There'd be duplication in local disk space, but you'd > avoid the NFS locking issues. This is similar how the project infrastructure works. nfs:/dl_dir nfs:/rsynced_dl_dir autobuilder uses the nfs:/dl_dir and a period rsync syncs to rsync_dl_dir. We can then use the rsync dir as our mirror. It ends up solving a few issues. If you don't want to run a full autobuilder, just a bitbake universe -c fetch on a cron job with all your layers would do it. -b > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > > -- > _______________________________________________ > yocto mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/yocto > -- Elizabeth Flanagan Yocto Project Build and Release ------------------------------ -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto End of yocto Digest, Vol 44, Issue 18 ************************************* -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
