= On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker <paul@paulbarker.me.uk> wrote:

On Fri, Oct 16, 2015 at 07:38:19PM +0000, Ahsan, Noor = wrote:
> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor <Noor_Ahsan@mentor.com<mailto:Noor_Ahsan@mentor.com>> wrote= :
>
> Hello,
>
> I noticed that at the time of rootfs creation symbolic links of the ip= k files present in deploy/ipk. The problem what have it while creation of s= ymbolic link it take the full path till that ipk and remove slashes and con= vert them into underscores. Use that as the name of the symbolic link. This= make a very long file names. If we have very long path then name of the sy= mlink exceed from max filename limits. And we get following error
>
> Collected errors:
> * file_link: unable to stat `/var/jenkins/workspace/mel_cedar-main/bui= ldhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7= xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootf= s//var/cache/opkg/volatile/file:_var_jenkins_worksp= ace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra= 7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lt= tng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx= _evm.ipk': File name too long.
>
> Can anyone tell me why the addition of full path was added to the syml= ink name and can we remove it cause it is cause issues?
>
> what does
>
> getconf PATH_MAX /
>
> show ?
>
> jenkins@amd-ubu14-32-3:~$ getconf -a | grep=C2=A0 PATH_MAX
> PATH_MAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04096
> _POSIX_PATH_MAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 4096
>
>
> I think the issue is with file name not the path.
>
> Secondly the googling which I did reveals that symlink creation can= 9;t be stopped. I just wanna confirm that is my findings correct?
>

This looks like something we overlooked in opkg. When we added the caching code
we didn't think about how long the paths and filenames might get during= the
rootfs step. It's not currently possible to reduce the length of the sy= mlink
filenames, but it is possible to change the directory in which the symlinks= are
created.

Currently the opkg cache dir can only be set in the= opkg.conf file. I think we
should add a '--cache-dir' argument to opkg= . If this is added you'll be able to
set the following in your local.conf file to change the cache location. Eg.= to
use '/tmp/opkg' on the host during rootfs c= reation.

=C2=A0 =C2=A0 OPKG_ARGS =3D "--cache-dir=3D/tmp/opkg<= /span>"

I'll submit a patch to opkg to add this option.=

This will only shorten the full path, not the = filename length, so I doubt this'll solve it. That said, I can't ac= tually successfully test this today, because cache_dir is made relative to = offline_root, so setting such a path as you suggest doesn't shorten the= full path either.
--

Christopher Lar= son
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZ= aurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

--089e01176cad91cef205228c6522-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 240D5E00843; Tue, 20 Oct 2015 10:19:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.213.169 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 36E41E006D5 for ; Tue, 20 Oct 2015 10:19:55 -0700 (PDT) Received: by igbdj2 with SMTP id dj2so19414004igb.1 for ; Tue, 20 Oct 2015 10:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=w2hb7CPRtTO3pdQHwwnkUgLRdyJsBXsAjoIzzjVs43s=; b=z2SHMMMnhoCGzFKzHLN7A7dXUFkM7x7GbDxG3Rv4bmQqsty2Lr6RHX4kMDXe7pjrDz 285/Bf13t0RBxgbjelSGdJMhwowTVZwy2GRv0rpNc52lPQlYv4KEmULjREjE1xFbo2RR h8EZzEtVIdErAe5kDY+k+UyfXs2Ct9SVa0pH1SUpB+P0lIQqb8YrTDYAZ1+0TVwmQGbw ikOlTk/zsx/hVaig5WZ75uudiT1nmuAWjgx6vRtG3CmoVKecF78X7RlviaV3G2JWtdzi ZG0OJYf0+Tl4sKDpnMjTtRUM/2gP85vP45gBYQDOnBOQQYjST1U+1BjHxAD002IvfFEh UdDQ== X-Received: by 10.50.43.170 with SMTP id x10mr25230932igl.68.1445361594788; Tue, 20 Oct 2015 10:19:54 -0700 (PDT) MIME-Version: 1.0 Sender: kergoth@gmail.com Received: by 10.79.65.204 with HTTP; Tue, 20 Oct 2015 10:19:35 -0700 (PDT) In-Reply-To: References: <365E1805BC95084CBE82381A0B86999401095F873E@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E08@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E8A@EU-MBX-01.mgc.mentorg.com> <20151018095759.GA12999@bang.betafive.co.uk> From: Christopher Larson Date: Tue, 20 Oct 2015 10:19:35 -0700 X-Google-Sender-Auth: olHSKdtrziDpgagC3jLaL3kI2Kw Message-ID: To: Paul Barker Cc: "yocto@yoctoproject.org" Subject: Re: opkg 0.3.0 or rootfs task X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 17:19:59 -0000 Content-Type: multipart/alternative; boundary=089e01176cad6e094c05228c7887 --089e01176cad6e094c05228c7887 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson wrote: > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker > wrote: > >> On Fri, Oct 16, 2015 at 07:38:19PM +0000, Ahsan, Noor wrote: >> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > Noor_Ahsan@mentor.com>> wrote: >> > >> > Hello, >> > >> > I noticed that at the time of rootfs creation symbolic links of the ip= k >> files present in deploy/ipk. The problem what have it while creation of >> symbolic link it take the full path till that ipk and remove slashes and >> convert them into underscores. Use that as the name of the symbolic link= . >> This make a very long file names. If we have very long path then name of >> the symlink exceed from max filename limits. And we get following error >> > >> > Collected errors: >> > * file_link: unable to stat >> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildt= ype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm= -mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/ >> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-u= buntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_d= eploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwr= ite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': >> File name too long. >> > >> > Can anyone tell me why the addition of full path was added to the >> symlink name and can we remove it cause it is cause issues? >> > >> > what does >> > >> > getconf PATH_MAX / >> > >> > show ? >> > >> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX >> > PATH_MAX 4096 >> > _POSIX_PATH_MAX 4096 >> > >> > >> > I think the issue is with file name not the path. >> > >> > Secondly the googling which I did reveals that symlink creation can't >> be stopped. I just wanna confirm that is my findings correct? >> > >> >> This looks like something we overlooked in opkg. When we added the >> caching code >> we didn't think about how long the paths and filenames might get during >> the >> rootfs step. It's not currently possible to reduce the length of the >> symlink >> filenames, but it is possible to change the directory in which the >> symlinks are >> created. >> >> Currently the opkg cache dir can only be set in the opkg.conf file. I >> think we >> should add a '--cache-dir' argument to opkg. If this is added you'll be >> able to >> set the following in your local.conf file to change the cache location. >> Eg. to >> use '/tmp/opkg' on the host during rootfs creation. >> >> OPKG_ARGS =3D "--cache-dir=3D/tmp/opkg" >> >> I'll submit a patch to opkg to add this option. >> > > This will only shorten the full path, not the filename length, so I doubt > this'll solve it. That said, I can't actually successfully test this toda= y, > because cache_dir is made relative to offline_root, so setting such a pat= h > as you suggest doesn't shorten the full path either. Also, did a touch of just the cache filename and it gives the same filename length error, so where the cache dir is really isn't going to matter, it's the filename including the full path to a deep BUILDDIR, and therefore DEPLOY_DIR_IPK, which is the problem. --=20 Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics --089e01176cad6e094c05228c7887 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson <= clarson@kergoth.co= m> wrote:

On Sun, Oct 18, 2015 at 2:57 AM, Paul Bar= ker <paul@paulbarker.me.uk> wrote:
On Fri, Oct 16, 2015 at 07:38:19PM +0000, A= hsan, Noor wrote:
> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor <Noor_Ahsan@mentor.com<mailto= :Noor_Ahsan@ment= or.com>> wrote:
>
> Hello,
>
> I noticed that at the time of rootfs creation symbolic links of the ip= k files present in deploy/ipk. The problem what have it while creation of s= ymbolic link it take the full path till that ipk and remove slashes and con= vert them into underscores. Use that as the name of the symbolic link. This= make a very long file names. If we have very long path then name of the sy= mlink exceed from max filename limits. And we get following error
>
> Collected errors:
> * file_link: unable to stat `/var/jenkins/workspace/mel_cedar-main/bui= ldhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7= xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootf= s//var/cache/opkg/volatile/file:_var_j= enkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_ma= chine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_ker= nel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0= .0_mel_dra7xx_evm.ipk': File name too long.
>
> Can anyone tell me why the addition of full path was added to the syml= ink name and can we remove it cause it is cause issues?
>
> what does
>
> getconf PATH_MAX /
>
> show ?
>
> jenkins@amd-ubu14-32-3:~$ getconf -a | grep=C2=A0 PATH_MAX
> PATH_MAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04096
> _POSIX_PATH_MAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 4096
>
>
> I think the issue is with file name not the path.
>
> Secondly the googling which I did reveals that symlink creation can= 9;t be stopped. I just wanna confirm that is my findings correct?
>

This looks like something we overlooked in op= kg. When we added the caching code
we didn't think about how long the paths and filenames might get during= the
rootfs step. It's not currently possible to reduce the length of the sy= mlink
filenames, but it is possible to change the directory in which the symlinks= are
created.

Currently the opkg cache dir can only = be set in the opkg.conf file. I think = we
should add a '--cache-dir' argument to opkg<= /span>. If this is added you'll be able to
set the following in your local.conf file to change the cache location. Eg.= to
use '/tmp/opkg' on the host du= ring rootfs creation.

=C2=A0 =C2=A0 OPKG_ARGS =3D "--cache-dir=3D/tmp/opkg"

I'll submit a patch to opkg to add= this option.

This will only shorte= n the full path, not the filename length, so I doubt this'll solve it. = That said, I can't actually successfully test this today, because cache= _dir is made relative to offline_root, so setting such a path as you sugges= t doesn't shorten the full path either.

Also, did= a touch of just the cache filename and it gives the same filename length e= rror, so where the cache dir is really isn't going to matter, it's = the filename including the full path to a deep BUILDDIR, and therefore DEPL= OY_DIR_IPK, which is the problem.
--

= Christopher Larson
clarson at kergoth dot com
Founder - BitBake, Open= Embedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Men= tor Graphics

--089e01176cad6e094c05228c7887-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 7C03AE009BA; Wed, 21 Oct 2015 00:49:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [192.94.38.131 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 1F386E008AE for ; Wed, 21 Oct 2015 00:49:16 -0700 (PDT) Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Zoo94-0007j6-4I from Noor_Ahsan@mentor.com ; Wed, 21 Oct 2015 00:49:14 -0700 Received: from EU-MBX-01.mgc.mentorg.com ([169.254.1.18]) by SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) with mapi id 14.03.0224.002; Wed, 21 Oct 2015 08:49:13 +0100 From: "Ahsan, Noor" To: Christopher Larson , Paul Barker Thread-Topic: [yocto] opkg 0.3.0 or rootfs task Thread-Index: AdEID/YXvvJYRC9ARjGu9IDwO4ksRQAGvNuAAAZJplAAAXfmkADEZxgKAB5WqmA= Date: Wed, 21 Oct 2015 07:49:12 +0000 Message-ID: <365E1805BC95084CBE82381A0B86999401095FAD92@EU-MBX-01.mgc.mentorg.com> References: <365E1805BC95084CBE82381A0B86999401095F873E@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E08@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E8A@EU-MBX-01.mgc.mentorg.com> <20151018095759.GA12999@bang.betafive.co.uk> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.202.0.76] MIME-Version: 1.0 Cc: "yocto@yoctoproject.org" Subject: Re: opkg 0.3.0 or rootfs task X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 07:49:19 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_365E1805BC95084CBE82381A0B86999401095FAD92EUMBX01mgcmen_" --_000_365E1805BC95084CBE82381A0B86999401095FAD92EUMBX01mgcmen_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYXJlIGhpdHRpbmcgdGhpcyBpc3N1ZSBvbiBhbm90aGVyIEJTUA0KDQpmaWxlOl92YXJfamVu a2luc193b3Jrc3BhY2VfY2UtbWFpbl9idWlsZGhvc3RfU0I2NF9idWlsZHR5cGVfaW5kdXN0cmlh bF9tYWNoaW5lX3plZGJvYXJkLXp5bnE3LW1lbF9idWlsZF96ZWRib2FyZC16eW5xNy1tZWxfdG1w X2RlcGxveV9pcGtfemVkYm9hcmRfenlucTdfbWVsX2tlcm5lbC1tb2R1bGUtbHR0bmctcmluZy1i dWZmZXItY2xpZW50LW1tYXAtb3ZlcndyaXRlXzIuNi4yK2dpdDArN2E4OGY4YjUwNi1yMC4wX3pl ZGJvYXJkX3p5bnE3X21lbC5pcGsNCg0KbmVlZCBpdHMgc29sdXRpb24gcXVpY2tseQ0KDQpOb29y DQoNCkZyb206IGtlcmdvdGhAZ21haWwuY29tIFttYWlsdG86a2VyZ290aEBnbWFpbC5jb21dIE9u IEJlaGFsZiBPZiBDaHJpc3RvcGhlciBMYXJzb24NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjAs IDIwMTUgMTA6MjAgUE0NClRvOiBQYXVsIEJhcmtlcg0KQ2M6IEFoc2FuLCBOb29yOyB5b2N0b0B5 b2N0b3Byb2plY3Qub3JnDQpTdWJqZWN0OiBSZTogW3lvY3RvXSBvcGtnIDAuMy4wIG9yIHJvb3Rm cyB0YXNrDQoNCg0KT24gVHVlLCBPY3QgMjAsIDIwMTUgYXQgMTA6MTQgQU0sIENocmlzdG9waGVy IExhcnNvbiA8Y2xhcnNvbkBrZXJnb3RoLmNvbTxtYWlsdG86Y2xhcnNvbkBrZXJnb3RoLmNvbT4+ IHdyb3RlOg0KDQpPbiBTdW4sIE9jdCAxOCwgMjAxNSBhdCAyOjU3IEFNLCBQYXVsIEJhcmtlciA8 cGF1bEBwYXVsYmFya2VyLm1lLnVrPG1haWx0bzpwYXVsQHBhdWxiYXJrZXIubWUudWs+PiB3cm90 ZToNCk9uIEZyaSwgT2N0IDE2LCAyMDE1IGF0IDA3OjM4OjE5UE0gKzAwMDAsIEFoc2FuLCBOb29y IHdyb3RlOg0KPiBPbiBPY3QgMTYsIDIwMTUsIGF0IDU6NDcgQU0sIEFoc2FuLCBOb29yIDxOb29y X0Foc2FuQG1lbnRvci5jb208bWFpbHRvOk5vb3JfQWhzYW5AbWVudG9yLmNvbT48bWFpbHRvOk5v b3JfQWhzYW5AbWVudG9yLmNvbTxtYWlsdG86Tm9vcl9BaHNhbkBtZW50b3IuY29tPj4+IHdyb3Rl Og0KPg0KPiBIZWxsbywNCj4NCj4gSSBub3RpY2VkIHRoYXQgYXQgdGhlIHRpbWUgb2Ygcm9vdGZz IGNyZWF0aW9uIHN5bWJvbGljIGxpbmtzIG9mIHRoZSBpcGsgZmlsZXMgcHJlc2VudCBpbiBkZXBs b3kvaXBrLiBUaGUgcHJvYmxlbSB3aGF0IGhhdmUgaXQgd2hpbGUgY3JlYXRpb24gb2Ygc3ltYm9s aWMgbGluayBpdCB0YWtlIHRoZSBmdWxsIHBhdGggdGlsbCB0aGF0IGlwayBhbmQgcmVtb3ZlIHNs YXNoZXMgYW5kIGNvbnZlcnQgdGhlbSBpbnRvIHVuZGVyc2NvcmVzLiBVc2UgdGhhdCBhcyB0aGUg bmFtZSBvZiB0aGUgc3ltYm9saWMgbGluay4gVGhpcyBtYWtlIGEgdmVyeSBsb25nIGZpbGUgbmFt ZXMuIElmIHdlIGhhdmUgdmVyeSBsb25nIHBhdGggdGhlbiBuYW1lIG9mIHRoZSBzeW1saW5rIGV4 Y2VlZCBmcm9tIG1heCBmaWxlbmFtZSBsaW1pdHMuIEFuZCB3ZSBnZXQgZm9sbG93aW5nIGVycm9y DQo+DQo+IENvbGxlY3RlZCBlcnJvcnM6DQo+ICogZmlsZV9saW5rOiB1bmFibGUgdG8gc3RhdCBg L3Zhci9qZW5raW5zL3dvcmtzcGFjZS9tZWxfY2VkYXItbWFpbi9idWlsZGhvc3QvYW1kLXVidW50 dTE0LTMyYi9idWlsZHR5cGUvaW90L21hY2hpbmUvbWVsLWRyYTd4eC1ldm0vYnVpbGRfbWVsLWRy YTd4eC1ldm0vdG1wL3dvcmsvbWVsX2RyYTd4eF9ldm0tbWVsLWxpbnV4LWdudWVhYmkvY29uc29s ZS1pbWFnZS8xLjAtcjAvcm9vdGZzLy92YXIvY2FjaGUvb3BrZy92b2xhdGlsZS9maWxlOl92YXJf amVua2luc193b3Jrc3BhY2VfbWVsX2NlZGFyLW1haW5fYnVpbGRob3N0X2FtZC11YnVudHUxNC0z MmJfYnVpbGR0eXBlX2lvdF9tYWNoaW5lX21lbC1kcmE3eHgtZXZtX2J1aWxkX21lbC1kcmE3eHgt ZXZtX3RtcF9kZXBsb3lfaXBrX21lbF9kcmE3eHhfZXZtX2tlcm5lbC1tb2R1bGUtbHR0bmctcmlu Zy1idWZmZXItY2xpZW50LW1tYXAtb3ZlcndyaXRlXzIuNi4yK2dpdDArN2E4OGY4YjUwNi1yMC4w X21lbF9kcmE3eHhfZXZtLmlwayc6IEZpbGUgbmFtZSB0b28gbG9uZy4NCj4NCj4gQ2FuIGFueW9u ZSB0ZWxsIG1lIHdoeSB0aGUgYWRkaXRpb24gb2YgZnVsbCBwYXRoIHdhcyBhZGRlZCB0byB0aGUg c3ltbGluayBuYW1lIGFuZCBjYW4gd2UgcmVtb3ZlIGl0IGNhdXNlIGl0IGlzIGNhdXNlIGlzc3Vl cz8NCj4NCj4gd2hhdCBkb2VzDQo+DQo+IGdldGNvbmYgUEFUSF9NQVggLw0KPg0KPiBzaG93ID8N Cj4NCj4gamVua2luc0BhbWQtdWJ1MTQtMzItMzp+JCBnZXRjb25mIC1hIHwgZ3JlcCAgUEFUSF9N QVgNCj4gUEFUSF9NQVggICAgICAgICAgICAgICAgICAgICAgICAgICA0MDk2DQo+IF9QT1NJWF9Q QVRIX01BWCAgICAgICAgICAgICAgICAgICAgNDA5Ng0KPg0KPg0KPiBJIHRoaW5rIHRoZSBpc3N1 ZSBpcyB3aXRoIGZpbGUgbmFtZSBub3QgdGhlIHBhdGguDQo+DQo+IFNlY29uZGx5IHRoZSBnb29n bGluZyB3aGljaCBJIGRpZCByZXZlYWxzIHRoYXQgc3ltbGluayBjcmVhdGlvbiBjYW4ndCBiZSBz dG9wcGVkLiBJIGp1c3Qgd2FubmEgY29uZmlybSB0aGF0IGlzIG15IGZpbmRpbmdzIGNvcnJlY3Q/ DQo+DQoNClRoaXMgbG9va3MgbGlrZSBzb21ldGhpbmcgd2Ugb3Zlcmxvb2tlZCBpbiBvcGtnLiBX aGVuIHdlIGFkZGVkIHRoZSBjYWNoaW5nIGNvZGUNCndlIGRpZG4ndCB0aGluayBhYm91dCBob3cg bG9uZyB0aGUgcGF0aHMgYW5kIGZpbGVuYW1lcyBtaWdodCBnZXQgZHVyaW5nIHRoZQ0Kcm9vdGZz IHN0ZXAuIEl0J3Mgbm90IGN1cnJlbnRseSBwb3NzaWJsZSB0byByZWR1Y2UgdGhlIGxlbmd0aCBv ZiB0aGUgc3ltbGluaw0KZmlsZW5hbWVzLCBidXQgaXQgaXMgcG9zc2libGUgdG8gY2hhbmdlIHRo ZSBkaXJlY3RvcnkgaW4gd2hpY2ggdGhlIHN5bWxpbmtzIGFyZQ0KY3JlYXRlZC4NCg0KQ3VycmVu dGx5IHRoZSBvcGtnIGNhY2hlIGRpciBjYW4gb25seSBiZSBzZXQgaW4gdGhlIG9wa2cuY29uZiBm aWxlLiBJIHRoaW5rIHdlDQpzaG91bGQgYWRkIGEgJy0tY2FjaGUtZGlyJyBhcmd1bWVudCB0byBv cGtnLiBJZiB0aGlzIGlzIGFkZGVkIHlvdSdsbCBiZSBhYmxlIHRvDQpzZXQgdGhlIGZvbGxvd2lu ZyBpbiB5b3VyIGxvY2FsLmNvbmYgZmlsZSB0byBjaGFuZ2UgdGhlIGNhY2hlIGxvY2F0aW9uLiBF Zy4gdG8NCnVzZSAnL3RtcC9vcGtnJyBvbiB0aGUgaG9zdCBkdXJpbmcgcm9vdGZzIGNyZWF0aW9u Lg0KDQogICAgT1BLR19BUkdTID0gIi0tY2FjaGUtZGlyPS90bXAvb3BrZyINCg0KSSdsbCBzdWJt aXQgYSBwYXRjaCB0byBvcGtnIHRvIGFkZCB0aGlzIG9wdGlvbi4NCg0KVGhpcyB3aWxsIG9ubHkg c2hvcnRlbiB0aGUgZnVsbCBwYXRoLCBub3QgdGhlIGZpbGVuYW1lIGxlbmd0aCwgc28gSSBkb3Vi dCB0aGlzJ2xsIHNvbHZlIGl0LiBUaGF0IHNhaWQsIEkgY2FuJ3QgYWN0dWFsbHkgc3VjY2Vzc2Z1 bGx5IHRlc3QgdGhpcyB0b2RheSwgYmVjYXVzZSBjYWNoZV9kaXIgaXMgbWFkZSByZWxhdGl2ZSB0 byBvZmZsaW5lX3Jvb3QsIHNvIHNldHRpbmcgc3VjaCBhIHBhdGggYXMgeW91IHN1Z2dlc3QgZG9l c24ndCBzaG9ydGVuIHRoZSBmdWxsIHBhdGggZWl0aGVyLg0KDQpBbHNvLCBkaWQgYSB0b3VjaCBv ZiBqdXN0IHRoZSBjYWNoZSBmaWxlbmFtZSBhbmQgaXQgZ2l2ZXMgdGhlIHNhbWUgZmlsZW5hbWUg bGVuZ3RoIGVycm9yLCBzbyB3aGVyZSB0aGUgY2FjaGUgZGlyIGlzIHJlYWxseSBpc24ndCBnb2lu ZyB0byBtYXR0ZXIsIGl0J3MgdGhlIGZpbGVuYW1lIGluY2x1ZGluZyB0aGUgZnVsbCBwYXRoIHRv IGEgZGVlcCBCVUlMRERJUiwgYW5kIHRoZXJlZm9yZSBERVBMT1lfRElSX0lQSywgd2hpY2ggaXMg dGhlIHByb2JsZW0uDQotLQ0KQ2hyaXN0b3BoZXIgTGFyc29uDQpjbGFyc29uIGF0IGtlcmdvdGgg ZG90IGNvbQ0KRm91bmRlciAtIEJpdEJha2UsIE9wZW5FbWJlZGRlZCwgT3BlblphdXJ1cw0KTWFp bnRhaW5lciAtIFRzbGliDQpTZW5pb3IgU29mdHdhcmUgRW5naW5lZXIsIE1lbnRvciBHcmFwaGlj cw0K --_000_365E1805BC95084CBE82381A0B86999401095FAD92EUMBX01mgcmen_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGFyZSBo aXR0aW5nIHRoaXMgaXNzdWUgb24gYW5vdGhlciBCU1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmZpbGU6X3Zhcl9qZW5r aW5zX3dvcmtzcGFjZV9jZS1tYWluX2J1aWxkaG9zdF9TQjY0X2J1aWxkdHlwZV9pbmR1c3RyaWFs X21hY2hpbmVfemVkYm9hcmQtenlucTctbWVsX2J1aWxkX3plZGJvYXJkLXp5bnE3LW1lbF90bXBf ZGVwbG95X2lwa196ZWRib2FyZF96eW5xN19tZWxfa2VybmVsLW1vZHVsZS1sdHRuZy1yaW5nLWJ1 ZmZlci1jbGllbnQtbW1hcC1vdmVyd3JpdGVfMi42LjImIzQzO2dpdDAmIzQzOzdhODhmOGI1MDYt cjAuMF96ZWRib2FyZF96eW5xN19tZWwuaXBrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5uZWVkIGl0cyBzb2x1dGlvbiBx dWlja2x5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Ob29yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4ga2VyZ290aEBnbWFpbC5j b20gW21haWx0bzprZXJnb3RoQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0 b3BoZXIgTGFyc29uPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjAsIDIwMTUg MTA6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IFBhdWwgQmFya2VyPGJyPg0KPGI+Q2M6PC9iPiBBaHNh biwgTm9vcjsgeW9jdG9AeW9jdG9wcm9qZWN0Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3lvY3RvXSBvcGtnIDAuMy4wIG9yIHJvb3RmcyB0YXNrPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAyMCwgMjAxNSBhdCAx MDoxNCBBTSwgQ2hyaXN0b3BoZXIgTGFyc29uICZsdDs8YSBocmVmPSJtYWlsdG86Y2xhcnNvbkBr ZXJnb3RoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNsYXJzb25Aa2VyZ290aC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFN1biwgT2N0IDE4LCAyMDE1IGF0IDI6NTcgQU0sIFBhdWwgQmFya2VyICZsdDs8 YSBocmVmPSJtYWlsdG86cGF1bEBwYXVsYmFya2VyLm1lLnVrIiB0YXJnZXQ9Il9ibGFuayI+cGF1 bEBwYXVsYmFya2VyLm1lLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDE2LCAyMDE1IGF0 IDA3OjM4OjE5UE0gJiM0MzswMDAwLCBBaHNhbiwgTm9vciB3cm90ZTo8YnI+DQomZ3Q7IE9uIE9j dCAxNiwgMjAxNSwgYXQgNTo0NyBBTSwgQWhzYW4sIE5vb3IgJmx0OzxhIGhyZWY9Im1haWx0bzpO b29yX0Foc2FuQG1lbnRvci5jb20iIHRhcmdldD0iX2JsYW5rIj5Ob29yX0Foc2FuQG1lbnRvci5j b208L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Tm9vcl9BaHNhbkBtZW50b3IuY29tIiB0 YXJnZXQ9Il9ibGFuayI+Tm9vcl9BaHNhbkBtZW50b3IuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7IEhlbGxvLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgbm90aWNlZCB0 aGF0IGF0IHRoZSB0aW1lIG9mIHJvb3RmcyBjcmVhdGlvbiBzeW1ib2xpYyBsaW5rcyBvZiB0aGUg aXBrIGZpbGVzIHByZXNlbnQgaW4gZGVwbG95L2lway4gVGhlIHByb2JsZW0gd2hhdCBoYXZlIGl0 IHdoaWxlIGNyZWF0aW9uIG9mIHN5bWJvbGljIGxpbmsgaXQgdGFrZSB0aGUgZnVsbCBwYXRoIHRp bGwgdGhhdCBpcGsgYW5kIHJlbW92ZSBzbGFzaGVzIGFuZCBjb252ZXJ0IHRoZW0gaW50byB1bmRl cnNjb3Jlcy4gVXNlIHRoYXQNCiBhcyB0aGUgbmFtZSBvZiB0aGUgc3ltYm9saWMgbGluay4gVGhp cyBtYWtlIGEgdmVyeSBsb25nIGZpbGUgbmFtZXMuIElmIHdlIGhhdmUgdmVyeSBsb25nIHBhdGgg dGhlbiBuYW1lIG9mIHRoZSBzeW1saW5rIGV4Y2VlZCBmcm9tIG1heCBmaWxlbmFtZSBsaW1pdHMu IEFuZCB3ZSBnZXQgZm9sbG93aW5nIGVycm9yPGJyPg0KJmd0Ozxicj4NCiZndDsgQ29sbGVjdGVk IGVycm9yczo8YnI+DQomZ3Q7ICogZmlsZV9saW5rOiB1bmFibGUgdG8gc3RhdCBgL3Zhci9qZW5r aW5zL3dvcmtzcGFjZS9tZWxfY2VkYXItbWFpbi9idWlsZGhvc3QvYW1kLXVidW50dTE0LTMyYi9i dWlsZHR5cGUvaW90L21hY2hpbmUvbWVsLWRyYTd4eC1ldm0vYnVpbGRfbWVsLWRyYTd4eC1ldm0v dG1wL3dvcmsvbWVsX2RyYTd4eF9ldm0tbWVsLWxpbnV4LWdudWVhYmkvY29uc29sZS1pbWFnZS8x LjAtcjAvcm9vdGZzLy92YXIvY2FjaGUvb3BrZy92b2xhdGlsZS9maWxlOl92YXJfamVua2luc193 b3Jrc3BhY2VfbWVsX2NlZGFyLW1haW5fYnVpbGRob3N0X2FtZC11YnVudHUxNC0zMmJfYnVpbGR0 eXBlX2lvdF9tYWNoaW5lX21lbC1kcmE3eHgtZXZtX2J1aWxkX21lbC1kcmE3eHgtZXZtX3RtcF9k ZXBsb3lfaXBrX21lbF9kcmE3eHhfZXZtX2tlcm5lbC1tb2R1bGUtbHR0bmctcmluZy1idWZmZXIt Y2xpZW50LW1tYXAtb3ZlcndyaXRlXzIuNi4yJiM0MztnaXQwJiM0Mzs3YTg4ZjhiNTA2LXIwLjBf bWVsX2RyYTd4eF9ldm0uaXBrJzoNCiBGaWxlIG5hbWUgdG9vIGxvbmcuPGJyPg0KJmd0Ozxicj4N CiZndDsgQ2FuIGFueW9uZSB0ZWxsIG1lIHdoeSB0aGUgYWRkaXRpb24gb2YgZnVsbCBwYXRoIHdh cyBhZGRlZCB0byB0aGUgc3ltbGluayBuYW1lIGFuZCBjYW4gd2UgcmVtb3ZlIGl0IGNhdXNlIGl0 IGlzIGNhdXNlIGlzc3Vlcz88YnI+DQomZ3Q7PGJyPg0KJmd0OyB3aGF0IGRvZXM8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBnZXRjb25mIFBBVEhfTUFYIC88YnI+DQomZ3Q7PGJyPg0KJmd0OyBzaG93ID88 YnI+DQomZ3Q7PGJyPg0KJmd0OyBqZW5raW5zQGFtZC11YnUxNC0zMi0zOn4kIGdldGNvbmYgLWEg fCBncmVwJm5ic3A7IFBBVEhfTUFYPGJyPg0KJmd0OyBQQVRIX01BWCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs0MDk2PGJyPg0KJmd0OyBfUE9TSVhfUEFUSF9NQVgmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgNDA5Njxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIHRoZSBp c3N1ZSBpcyB3aXRoIGZpbGUgbmFtZSBub3QgdGhlIHBhdGguPGJyPg0KJmd0Ozxicj4NCiZndDsg U2Vjb25kbHkgdGhlIGdvb2dsaW5nIHdoaWNoIEkgZGlkIHJldmVhbHMgdGhhdCBzeW1saW5rIGNy ZWF0aW9uIGNhbid0IGJlIHN0b3BwZWQuIEkganVzdCB3YW5uYSBjb25maXJtIHRoYXQgaXMgbXkg ZmluZGluZ3MgY29ycmVjdD88YnI+DQomZ3Q7PGJyPg0KPGJyPg0KVGhpcyBsb29rcyBsaWtlIHNv bWV0aGluZyB3ZSBvdmVybG9va2VkIGluIG9wa2cuIFdoZW4gd2UgYWRkZWQgdGhlIGNhY2hpbmcg Y29kZTxicj4NCndlIGRpZG4ndCB0aGluayBhYm91dCBob3cgbG9uZyB0aGUgcGF0aHMgYW5kIGZp bGVuYW1lcyBtaWdodCBnZXQgZHVyaW5nIHRoZTxicj4NCnJvb3RmcyBzdGVwLiBJdCdzIG5vdCBj dXJyZW50bHkgcG9zc2libGUgdG8gcmVkdWNlIHRoZSBsZW5ndGggb2YgdGhlIHN5bWxpbms8YnI+ DQpmaWxlbmFtZXMsIGJ1dCBpdCBpcyBwb3NzaWJsZSB0byBjaGFuZ2UgdGhlIGRpcmVjdG9yeSBp biB3aGljaCB0aGUgc3ltbGlua3MgYXJlPGJyPg0KY3JlYXRlZC48YnI+DQo8YnI+DQpDdXJyZW50 bHkgdGhlIG9wa2cgY2FjaGUgZGlyIGNhbiBvbmx5IGJlIHNldCBpbiB0aGUgb3BrZy5jb25mIGZp bGUuIEkgdGhpbmsgd2U8YnI+DQpzaG91bGQgYWRkIGEgJy0tY2FjaGUtZGlyJyBhcmd1bWVudCB0 byBvcGtnLiBJZiB0aGlzIGlzIGFkZGVkIHlvdSdsbCBiZSBhYmxlIHRvPGJyPg0Kc2V0IHRoZSBm b2xsb3dpbmcgaW4geW91ciBsb2NhbC5jb25mIGZpbGUgdG8gY2hhbmdlIHRoZSBjYWNoZSBsb2Nh dGlvbi4gRWcuIHRvPGJyPg0KdXNlICcvdG1wL29wa2cnIG9uIHRoZSBob3N0IGR1cmluZyByb290 ZnMgY3JlYXRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPUEtHX0FSR1MgPSAmcXVvdDst LWNhY2hlLWRpcj0vdG1wL29wa2cmcXVvdDs8YnI+DQo8YnI+DQpJJ2xsIHN1Ym1pdCBhIHBhdGNo IHRvIG9wa2cgdG8gYWRkIHRoaXMgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd2lsbCBvbmx5 IHNob3J0ZW4gdGhlIGZ1bGwgcGF0aCwgbm90IHRoZSBmaWxlbmFtZSBsZW5ndGgsIHNvIEkgZG91 YnQgdGhpcydsbCBzb2x2ZSBpdC4gVGhhdCBzYWlkLCBJIGNhbid0IGFjdHVhbGx5IHN1Y2Nlc3Nm dWxseSB0ZXN0IHRoaXMgdG9kYXksIGJlY2F1c2UgY2FjaGVfZGlyIGlzIG1hZGUgcmVsYXRpdmUg dG8gb2ZmbGluZV9yb290LCBzbyBzZXR0aW5nIHN1Y2ggYSBwYXRoIGFzIHlvdSBzdWdnZXN0DQog ZG9lc24ndCBzaG9ydGVuIHRoZSBmdWxsIHBhdGggZWl0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBbHNvLCBkaWQg YSB0b3VjaCBvZiBqdXN0IHRoZSBjYWNoZSBmaWxlbmFtZSBhbmQgaXQgZ2l2ZXMgdGhlIHNhbWUg ZmlsZW5hbWUgbGVuZ3RoIGVycm9yLCBzbyB3aGVyZSB0aGUgY2FjaGUgZGlyIGlzIHJlYWxseSBp c24ndCBnb2luZyB0byBtYXR0ZXIsIGl0J3MgdGhlIGZpbGVuYW1lIGluY2x1ZGluZyB0aGUgZnVs bCBwYXRoIHRvIGEgZGVlcCBCVUlMRERJUiwgYW5kIHRoZXJlZm9yZSBERVBMT1lfRElSX0lQSywg d2hpY2ggaXMgdGhlIHByb2JsZW0uPGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0b3BoZXIgTGFyc29uPGJyPg0KY2xhcnNvbiBhdCBrZXJn b3RoIGRvdCBjb208YnI+DQpGb3VuZGVyIC0gQml0QmFrZSwgT3BlbkVtYmVkZGVkLCBPcGVuWmF1 cnVzPGJyPg0KTWFpbnRhaW5lciAtIFRzbGliPGJyPg0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVy LCBNZW50b3IgR3JhcGhpY3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_365E1805BC95084CBE82381A0B86999401095FAD92EUMBX01mgcmen_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 99F64E00B58; Sat, 24 Oct 2015 11:26:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [157.56.110.134 listed in list.dnswl.org] * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Greylist: delayed 1954 seconds by postgrey-1.32 at yocto-www; Sat, 24 Oct 2015 11:25:58 PDT Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0134.outbound.protection.outlook.com [157.56.110.134]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 04730E00473 for ; Sat, 24 Oct 2015 11:25:58 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=alejandro.delcastillo@ni.com; Received: from [192.168.1.76] (23.119.29.149) by BLUPR04MB838.namprd04.prod.outlook.com (10.255.188.150) with Microsoft SMTP Server (TLS) id 15.1.306.13; Sat, 24 Oct 2015 17:53:21 +0000 To: "Ahsan, Noor" , Christopher Larson , Paul Barker References: <365E1805BC95084CBE82381A0B86999401095F873E@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E08@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E8A@EU-MBX-01.mgc.mentorg.com> <20151018095759.GA12999@bang.betafive.co.uk> <365E1805BC95084CBE82381A0B86999401095FAD92@EU-MBX-01.mgc.mentorg.com> From: Alejandro del Castillo Message-ID: <562BC58D.4090600@ni.com> Date: Sat, 24 Oct 2015 12:53:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <365E1805BC95084CBE82381A0B86999401095FAD92@EU-MBX-01.mgc.mentorg.com> X-Originating-IP: [23.119.29.149] X-ClientProxiedBy: BLUPR08CA0069.namprd08.prod.outlook.com (10.141.200.49) To BLUPR04MB838.namprd04.prod.outlook.com (10.255.188.150) X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB838; 2:dsAf8dxqL5bh8mUCicrvaxuj1PC4amZyZyZVVyQZ27su0M8N+C4bcKyoJtWkSanjboSVrfgiO+Z078litEsDfXKaBNxZCyCaYBcKq+czKbKqSAdVHS3zuVCW6VLzkef4A8yDVtou+DjMFE3TlcaK9+D8V9n+DT9WTnzlS412dIw=; 3:yu1eYrd+VZBM/sGqP5+Q2GzqYdhAombknv6kDb8/Y5oq2Ga6Td5wLOIjj163OOsJoJddpGzatCbG/qqTjUXU1k1UmXtQWGgZ+cJQ26YA1B9vgmSShMCF2F5xhlmebpZgdJDn2h/pdXXIMidr3Yl9LQ==; 25:Fg58KZSo5MjdtNixvJrKqpL81Q/96gy+77CuzMiDHshGxdVvsN2A0duZ1VELVAsibjLoc9I/wSw4zRWVtivuUvMAHpuyxG96c2z4m1eoHWGPaxUpa6Nt7hiiFIlyj7h+Xf4WB+H1B0NXebTxeYZI0U8M1CafSq2ugkE1fEr0HPWUr99k+ft0wqzaCrd1dRjpbSEor4rduFQtY8Zx5qjyyxn5oYOq+pptdM9769w7iBBxFGDyMMam1XqpS+ymvYhLxtQ59D/5H9RSHrMudaWSpg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR04MB838; X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB838; 20:VCGiO4FGGg5XUaaPN4PrvHnvtgrgUPI5EUefx76Ruz2Giz/25aTiLlHqzMj1hOYjnM5hQqK/IA80fFnqySl529d70jpY5T/QuaLiCKJouLxpNqgVmH1L0zUgmRdQDk3f41xuxa9be4b1v7JeBhH9/5y5g6tXVtnRPkqL8SxhKcpaf5PxfDikj0+zGIm3VWrs+E8LQgJStWTtv6m+cihGtG5OaTHDHIWNt4ujyyK+NTXfMmnWO9DT3l4ns7ynExkLjKKxFONJ/USJXq3go0OYesPUu9d0OK6MUkzHTvf8sExUUeGPjc5cz8YIe2MT5VS7gNurPBu4on3TOhX3ONw3c93gNLUE4278wRGgrMt9mf6sAJOo9r8HB78SdzciiH0yO4TzjXmj66EynT1trNFx7H9jsb7COB+aEa/nYcVf/l0jftMQZR6SjjnfEEkRV85BzHS3k81nKCPiL3x5sfLlBV62Y/E1HXEks5GUxKgteJGePIIH3YXCDxKcCZOvwPZ9MZeJJtUu4tlfBKS+LyBJIEAaccGWKr+Mqa1sYv1tlnWmgYDsGKxUrgJxKnNrPKU7bggjUkZGpePOxRF9idSP0OqrToZXAy3k+UkJr2WvFOo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026); SRVR:BLUPR04MB838; BCL:0; PCL:0; RULEID:; SRVR:BLUPR04MB838; X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB838; 4:bPbWQNoG4ENN/GrWvkWVoEC2a/hnKxJPqU/QwvgcI0HAXkqv6PnCiMDF71mTVH5KRlCD3L41eidKwvm7SUz9O3qt8K3j12I0csBG0Ee65Hy26lsq/f1PEkyyj9GswCiC2xGlc2JGE0+X/bN1IIJanJEgsuHRF3QngGuUW2zSnaV/TQW+1w5qWyr0TjkG+xpky+EaLS6vnmtAZLUMRXS+iFs4L3h2NWgwEnO9RUIV3Xhj9dGxrzclQ6j0IbT+Dqs1ThasqFL/bkE4YeghJwEV/LLhe+03QgFnIh5c/gYEY+hajqzbVz1vixKOe5oxINPJ0q5FfTzJ6QziQd0LnLvVuI8V/VC9yhppTnBJG5SeedMHMSSXmavjCMaQwn5gsKth X-Forefront-PRVS: 073966E86B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(377454003)(479174004)(24454002)(189002)(199003)(92566002)(64126003)(80316001)(19580395003)(19580405001)(5008740100001)(86362001)(81156007)(4001350100001)(97736004)(83506001)(5001770100001)(87976001)(33656002)(23746002)(5007970100001)(122386002)(42186005)(15975445007)(59896002)(65816999)(189998001)(87266999)(65956001)(54356999)(2950100001)(66066001)(65806001)(77096005)(105586002)(40100003)(101416001)(93886004)(50466002)(76176999)(50986999)(117156001)(36756003)(106356001)(47776003)(5001960100002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR04MB838; H:[192.168.1.76]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ni.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR04MB838; 23:qJssO3QqYK9q8+pgmvjE9OaX2a0pajIVlTI804?= =?Windows-1252?Q?cERGPzmdSFAdjhKzl/gFHy1rRAsNTV4BOIMFsiBNJwoEtFKViKElXevw?= =?Windows-1252?Q?EJX3hqy3M+TIf7kMInxwHoPPVF2vSeL9nZjQzv9lFNecj9vwOaxISHoS?= =?Windows-1252?Q?Lx8cMg6Koi4b7CWWVmyydJqPSnqzQ0sEnSKTQZ7lLHQDfyp/1r4pjeKg?= =?Windows-1252?Q?ppicHsCeAPsoTXUttqJsDCRB9IghOUImZB51L7kq6kd4TMUNnBLf4RPv?= =?Windows-1252?Q?CmNbqFBxFKx6BopTlgSYE58ZoCWFGML/gPT6WDuSnyFHcwOVnBnv9ulR?= =?Windows-1252?Q?xXxv+8wdnVEVxDL2NlOk3QusABf6tpkzyisXyICzNcyV9R3+Xf7od9YG?= =?Windows-1252?Q?BoizvXz7auCLFzOJ3LFYWAbFP1L8IpktXwFQtQ1FNTnph/aFkwZHELUX?= =?Windows-1252?Q?9yzmOtWsZDDfVeWIAbrzqwgTlzE/jMrfsAA6TMAvJoy6E81h5KrHuksr?= =?Windows-1252?Q?572CO/SGZXebqbxVnkwRUN/pKC8EfGE1pOwVqYS7Sl6GDf7eyk62kk3g?= =?Windows-1252?Q?g+Y7hXYh69OdQKuf472cmsfRgcwXAkGiCBwdpQsqPvwuZ69U+9lwRIuA?= =?Windows-1252?Q?P9vVINYedvy2V5zFnreY+q24sCCVAov3hoMu+PtW3w9SfAePlaCbHV3j?= =?Windows-1252?Q?WTsWDjHDvdXq8cXVXiCJb2u1wb5Fa5Dpyku7EouBcxW4HxKPvE+n6iYo?= =?Windows-1252?Q?L3qWqhpMVBWJJ3l1SefCl/X0/BSlxSZN4RKMIa1hB3i5EiX/GqxgZo3f?= =?Windows-1252?Q?gOmcdREm+lixlGcho27UJgndgyWBextyy7CpZAy/eHCXxUIFSlo7Q5WA?= =?Windows-1252?Q?VjHSkcnev8K455TfSnW4Y6ZoY6sA4Pecw/eeUFfGpPTqamdAU0ltA8Od?= =?Windows-1252?Q?mfAOLuzp5pYbGI+5wzE4wA0Si5dBYFjWW1Dzy80N5HChi8oGrtGgP9J5?= =?Windows-1252?Q?VCKCTVPeDK7Fp0wM6di377boQV1usRx2GMYjDMLH984TBrzc0Qq+F9L3?= =?Windows-1252?Q?wNGeYNCN8EC85fnRlOZ7p8oow2lc4WoFd4fhaUtLWS3pgtMX3MmMBaqd?= =?Windows-1252?Q?o2b6QjQoXMtNkv2tfmIAdLZwdPFuSL2Z0vKh6UzXoYc2glE9Y3T7LGU3?= =?Windows-1252?Q?dKwMzXMfh9GX5Gm4syB+u9NVDHbK8AGwtsesD5YmtrYVq9zbn/F1zxeY?= =?Windows-1252?Q?2GxDHNxhuL8NPlLCVhfKefcs3Fkzdm+dPXFf9QeNUrb/S3jnmxlH9Wrj?= =?Windows-1252?Q?7BQqAyp+G5xDyuaGXznc2B6/CuruUCqf0mjOtgModucURTv/Ei/ziPl4?= =?Windows-1252?Q?5jIOe3Yc4b62vfsnN7x6I4bbenXCLDexe6ugLJ0kzm7B7QHGaL3+o=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB838; 5:GlKKg8pCzMIynzPLK+n3/Npk/1I8EUZ83xVY4pOVXjbHRYu/xQfyrPvhwGPq7D5cGy/mfZldyDh0lbykgtfFIUcaxWqmSz64F7TH+eL8EgX1AJn6IbfYcOv434eVwLHMN3fPdWS69q50frzDIIIyWg==; 24:SQyYeuuwSpYqEtiMZyG42E7r7856izi8k1a2Ej5I+bkAn6nPPTNSZq3tT44nTTrAT6ENmvvBp6Apa8mu12nvd8mTeZXEgRvxqL02sCgfGjg=; 20:uygqiqJ7QrK8BYFOcqsBu5Sg9KExDd+T+9ycJKOhQpejGwa94IhBgepR72JaLR4tLAUKQKm4pt8VDeJq5ahmiQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2015 17:53:21.6411 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR04MB838 Cc: "yocto@yoctoproject.org" Subject: Re: opkg 0.3.0 or rootfs task X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 18:26:03 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 10/21/2015 02:49 AM, Ahsan, Noor wrote: > We are hitting this issue on another BSP > > file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk > > need its solution quickly If you are in need of a quick workaround, try setting: option cache_local_files 0 on opkg.conf. This will make a copy of your ipk's instead of creating symlinks (haven't try it myself, but that's my understanding). Also, please open a bug report for opkg on https://bugzilla.yoctoproject.org to track the issue. > *From:*kergoth@gmail.com [mailto:kergoth@gmail.com] *On Behalf Of > *Christopher Larson > *Sent:* Tuesday, October 20, 2015 10:20 PM > *To:* Paul Barker > *Cc:* Ahsan, Noor; yocto@yoctoproject.org > *Subject:* Re: [yocto] opkg 0.3.0 or rootfs task > > On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson > > wrote: > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker > wrote: > > On Fri, Oct 16, 2015 at 07:38:19PM +0000, Ahsan, Noor wrote: > > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > >> wrote: > > > > Hello, > > > > I noticed that at the time of rootfs creation symbolic links > of the ipk files present in deploy/ipk. The problem what have it > while creation of symbolic link it take the full path till that > ipk and remove slashes and convert them into underscores. Use > that as the name of the symbolic link. This make a very long > file names. If we have very long path then name of the symlink > exceed from max filename limits. And we get following error > > > > Collected errors: > > * file_link: unable to stat > `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk': > File name too long. > > > > Can anyone tell me why the addition of full path was added to > the symlink name and can we remove it cause it is cause issues? > > > > what does > > > > getconf PATH_MAX / > > > > show ? > > > > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX > > PATH_MAX 4096 > > _POSIX_PATH_MAX 4096 > > > > > > I think the issue is with file name not the path. > > > > Secondly the googling which I did reveals that symlink > creation can't be stopped. I just wanna confirm that is my > findings correct? > > > > This looks like something we overlooked in opkg. When we added > the caching code > we didn't think about how long the paths and filenames might get > during the > rootfs step. It's not currently possible to reduce the length of > the symlink > filenames, but it is possible to change the directory in which > the symlinks are > created. > > Currently the opkg cache dir can only be set in the opkg.conf > file. I think we > should add a '--cache-dir' argument to opkg. If this is added > you'll be able to > set the following in your local.conf file to change the cache > location. Eg. to > use '/tmp/opkg' on the host during rootfs creation. > > OPKG_ARGS = "--cache-dir=/tmp/opkg" > > I'll submit a patch to opkg to add this option. > > This will only shorten the full path, not the filename length, so I > doubt this'll solve it. That said, I can't actually successfully > test this today, because cache_dir is made relative to offline_root, > so setting such a path as you suggest doesn't shorten the full path > either. > > > Also, did a touch of just the cache filename and it gives the same > filename length error, so where the cache dir is really isn't going to > matter, it's the filename including the full path to a deep BUILDDIR, > and therefore DEPLOY_DIR_IPK, which is the problem. > -- > > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 79FF7E00B58; Sat, 24 Oct 2015 11:54:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.223.174 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 38721E00473 for ; Sat, 24 Oct 2015 11:54:26 -0700 (PDT) Received: by ioll68 with SMTP id l68so153547604iol.3 for ; Sat, 24 Oct 2015 11:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kergoth_com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=N5fPPqXq1Ybn2VrbK84I5zib7USvSrZtzdT7wWKt+4c=; b=d5qwzoYAJ0A4PG/8JPt4dfsrzAKbFH3/XmUyxDtyUFokuaXgGieRcSb05wX1CtGn2E QVxWEaZaj6dchQ/We+ghGsl7Zh3+kSaZzswLV2eaF9UL5GeNybeBXMAb5a8LeFuyOfm0 JVk+zh+VRGmnKYKnux7h9XBQVFRubNvRq+VtfdSL06vrFC2v7btyTRJ0WnqVu7UW1267 G4o3+lNL/EMolVljnu9v1UKobYcgJ1SoarRQ5o+z0m8Wlr1NpsQvWoqD8AviyBzBCoH0 bYQihrpQ/J5+KniVHgrHnI1suRHJUnxxqX3ruKtlpRyCDYTGt3aUONi9kMspjDNrISC4 6RSA== X-Received: by 10.107.40.201 with SMTP id o192mr27592480ioo.83.1445712866304; Sat, 24 Oct 2015 11:54:26 -0700 (PDT) MIME-Version: 1.0 References: <365E1805BC95084CBE82381A0B86999401095F873E@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E08@EU-MBX-01.mgc.mentorg.com> <365E1805BC95084CBE82381A0B86999401095F8E8A@EU-MBX-01.mgc.mentorg.com> <20151018095759.GA12999@bang.betafive.co.uk> <365E1805BC95084CBE82381A0B86999401095FAD92@EU-MBX-01.mgc.mentorg.com> <562BC58D.4090600@ni.com> In-Reply-To: <562BC58D.4090600@ni.com> From: Christopher Larson Date: Sat, 24 Oct 2015 18:54:16 +0000 Message-ID: To: Alejandro del Castillo , "Ahsan, Noor" , Paul Barker Cc: "yocto@yoctoproject.org" Subject: Re: opkg 0.3.0 or rootfs task X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 18:54:31 -0000 Content-Type: multipart/alternative; boundary=001a1141f410d7eabb0522de4136 --001a1141f410d7eabb0522de4136 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not likely to help. The problem is the filename length, which will be the same whether it's a file or a symlink. On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo < alejandro.delcastillo@ni.com> wrote: > > > On 10/21/2015 02:49 AM, Ahsan, Noor wrote: > > We are hitting this issue on another BSP > > > > > file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_m= achine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_= zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+= 7a88f8b506-r0.0_zedboard_zynq7_mel.ipk > > > > need its solution quickly > > If you are in need of a quick workaround, try setting: > > option cache_local_files 0 > > on opkg.conf. This will make a copy of your ipk's instead of creating > symlinks (haven't try it myself, but that's my understanding). > > Also, please open a bug report for opkg on > https://bugzilla.yoctoproject.org to track the issue. > > > *From:*kergoth@gmail.com [mailto:kergoth@gmail.com] *On Behalf Of > > *Christopher Larson > > *Sent:* Tuesday, October 20, 2015 10:20 PM > > *To:* Paul Barker > > *Cc:* Ahsan, Noor; yocto@yoctoproject.org > > *Subject:* Re: [yocto] opkg 0.3.0 or rootfs task > > > > On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson > > > wrote: > > > > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker > > wrote: > > > > On Fri, Oct 16, 2015 at 07:38:19PM +0000, Ahsan, Noor wrote: > > > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > > > > >> wrote: > > > > > > Hello, > > > > > > I noticed that at the time of rootfs creation symbolic links > > of the ipk files present in deploy/ipk. The problem what have i= t > > while creation of symbolic link it take the full path till that > > ipk and remove slashes and convert them into underscores. Use > > that as the name of the symbolic link. This make a very long > > file names. If we have very long path then name of the symlink > > exceed from max filename limits. And we get following error > > > > > > Collected errors: > > > * file_link: unable to stat > > > `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildt= ype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm= -mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/fil= e:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtyp= e_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx= _evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f= 8b506-r0.0_mel_dra7xx_evm.ipk': > > File name too long. > > > > > > Can anyone tell me why the addition of full path was added t= o > > the symlink name and can we remove it cause it is cause issues? > > > > > > what does > > > > > > getconf PATH_MAX / > > > > > > show ? > > > > > > jenkins@amd-ubu14-32-3:~$ getconf -a | grep PATH_MAX > > > PATH_MAX 4096 > > > _POSIX_PATH_MAX 4096 > > > > > > > > > I think the issue is with file name not the path. > > > > > > Secondly the googling which I did reveals that symlink > > creation can't be stopped. I just wanna confirm that is my > > findings correct? > > > > > > > This looks like something we overlooked in opkg. When we added > > the caching code > > we didn't think about how long the paths and filenames might ge= t > > during the > > rootfs step. It's not currently possible to reduce the length o= f > > the symlink > > filenames, but it is possible to change the directory in which > > the symlinks are > > created. > > > > Currently the opkg cache dir can only be set in the opkg.conf > > file. I think we > > should add a '--cache-dir' argument to opkg. If this is added > > you'll be able to > > set the following in your local.conf file to change the cache > > location. Eg. to > > use '/tmp/opkg' on the host during rootfs creation. > > > > OPKG_ARGS =3D "--cache-dir=3D/tmp/opkg" > > > > I'll submit a patch to opkg to add this option. > > > > This will only shorten the full path, not the filename length, so I > > doubt this'll solve it. That said, I can't actually successfully > > test this today, because cache_dir is made relative to offline_root= , > > so setting such a path as you suggest doesn't shorten the full path > > either. > > > > > > Also, did a touch of just the cache filename and it gives the same > > filename length error, so where the cache dir is really isn't going to > > matter, it's the filename including the full path to a deep BUILDDIR, > > and therefore DEPLOY_DIR_IPK, which is the problem. > > -- > > > > Christopher Larson > > clarson at kergoth dot com > > Founder - BitBake, OpenEmbedded, OpenZaurus > > Maintainer - Tslib > > Senior Software Engineer, Mentor Graphics > > > > > > > --001a1141f410d7eabb0522de4136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not likely to help. The problem is the filename length, which will be the s= ame whether it's a file or a symlink.

On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo <<= a href=3D"mailto:alejandro.delcastillo@ni.com">alejandro.delcastillo@ni.com= > wrote:

On 10/21/2015 02:49 AM, Ahsan, Noor wrote:
> We are hitting this issue on another BSP
>
> file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industria= l_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboa= rd_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+gi= t0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk
>
> need its solution quickly

If you are in need of a quick workaround, try setting:

option cache_local_files 0

on opkg.conf. This will make a copy of your ipk's instead of creating symlinks (haven't try it myself, but that's my understanding).

Also, please open a bug report for opkg on
https://bugzilla.yoctoproject.org to track the issue.

> *From:*kergoth@= gmail.com [mailto:kergoth@gmail.com] *On Behalf Of
> *Christopher Larson
> *Sent:* Tuesday, October 20, 2015 10:20 PM
> *To:* Paul Barker
> *Cc:* Ahsan, Noor; yocto@yoctoproject.org
> *Subject:* Re: [yocto] opkg 0.3.0 or rootfs task
>
> On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson
> <clarson@k= ergoth.com <mailto:clarson@kergoth.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker <paul@paulbarker.me= .uk
>=C2=A0 =C2=A0 =C2=A0<mailto:paul@paulbarker.me.uk>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Oct 16, 2015 at 07:38:19PM +0= 000, Ahsan, Noor wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Oct 16, 2015, at 5:47 AM, Ah= san, Noor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Noor_Ahsan@mentor.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Noor_Ahsan@mentor.com><mailto:Noor_Ahsan@mentor.= com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Noor_Ahsan@mentor.com>>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Hello,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I noticed that at the time of r= ootfs creation symbolic links
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the ipk files present in deploy/ip= k. The problem what have it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0while creation of symbolic link it ta= ke the full path till that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipk and remove slashes and convert th= em into underscores. Use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that as the name of the symbolic link= . This make a very long
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file names. If we have very long path= then name of the symlink
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exceed from max filename limits. And = we get following error
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Collected errors:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > * file_link: unable to stat
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0`/var/jenkins/workspace/mel_cedar-mai= n/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel= -dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/= rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_= buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-d= ra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-cli= ent-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0File name too long.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Can anyone tell me why the addi= tion of full path was added to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the symlink name and can we remove it= cause it is cause issues?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > what does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > getconf PATH_MAX /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > show ?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > jenkins@amd-ubu14-32-3:~$ getco= nf -a | grep=C2=A0 PATH_MAX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > PATH_MAX=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A04096
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > _POSIX_PATH_MAX=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4096
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I think the issue is with file = name not the path.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Secondly the googling which I d= id reveals that symlink
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creation can't be stopped. I just= wanna confirm that is my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0findings correct?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This looks like something we overlook= ed in opkg. When we added
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the caching code
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we didn't think about how long th= e paths and filenames might get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0during the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rootfs step. It's not currently p= ossible to reduce the length of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the symlink
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filenames, but it is possible to chan= ge the directory in which
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the symlinks are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0created.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Currently the opkg cache dir can only= be set in the opkg.conf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file. I think we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should add a '--cache-dir' ar= gument to opkg. If this is added
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you'll be able to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set the following in your local.conf = file to change the cache
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0location. Eg. to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use '/tmp/opkg' on the host d= uring rootfs creation.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPKG_ARGS =3D "--= cache-dir=3D/tmp/opkg"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'll submit a patch to opkg to ad= d this option.
>
>=C2=A0 =C2=A0 =C2=A0This will only shorten the full path, not the filen= ame length, so I
>=C2=A0 =C2=A0 =C2=A0doubt this'll solve it. That said, I can't = actually successfully
>=C2=A0 =C2=A0 =C2=A0test this today, because cache_dir is made relative= to offline_root,
>=C2=A0 =C2=A0 =C2=A0so setting such a path as you suggest doesn't s= horten the full path
>=C2=A0 =C2=A0 =C2=A0either.
>
>
> Also, did a touch of just the cache filename and it gives the same
> filename length error, so where the cache dir is really isn't goin= g to
> matter, it's the filename including the full path to a deep BUILDD= IR,
> and therefore DEPLOY_DIR_IPK, which is the problem.
> --
>
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
>
>